I recently described how to execute Federated SPARQL queries that use Jena extensions that we'll hopefully see added to the SPARQL 1.1 standard. I showed a sample query and suggested that you try it at the sparql.org RDF Query Demo page.

For local, command-line use of SPARQL, I've used the Jena ARQ query engine for years, but my sample federated query didn't work with it, and now I know why: the sparql.bat file that comes with the distribution invokes the processor in a strictly standards-compliant mode without the extensions enabled. I thought I'd have to write and compile some Java code to use the extensions, but my co-worker Jeremy Carroll pointed out that the sparql.bat file in ARQ's bat subdirectory calls the arq.sparql library, like this,

java -cp %CP% arq.sparql %*

and that calling the arq.arq library instead enables the extensions. Then, I noticed the arq.bat file in the same directory as sparql.bat, and this is exactly what it does. There are more batch files in there, and a web search on their names led me to an ARQ - Command Line Applications documentation page, which will be handy.

Using arq.bat instead of sparql.bat, the sample federated query works as written (tested with ARQ 2.8.2), and so does LET assignment and extension functions, making it possible to use ARQ in real semantic web application development with no need to do Java coding around the Jena API.

(Thanks again, Jeremy!)

I've played with finance.yahoo.com's feed of CSV stock ticker data before and recently had an idea that was so simple that I'm surprised that no one's done it before: why not write a script that passes along a request for this data but converts the result to RDF before returning it? So I did.

I supposed it might count as a semantic web service.

A URL like http://www.rdfdata.org/cgi/stockquotes.cgi?symbols=BUD,IBM,SNE asks for recent ticker information about the stock symbols listed in the comma-separated value list. The stockquotes.cgi script adds the parameters to the appropriate stub to create a URL like http://download.finance.yahoo.com/d/quotes.csv?f=sl1d1t1ohgv&e=.csv&s=BUD,IBM,SNE, uses this URL to retrieve the CSV results, converts them to RDF/XML, and sends that back to the original requester with a MIME type of application/rdf+xml. The whole script, with white space and comments, wasn't even 100 lines. You can click the first link in this paragraph to see an example of it in action.

I haven't done anything with the rdfdata.org domain name in a while, so I thought that would be a nice place for this. I've already used this little web service in a work-related demo that combines and cross-references RDF data from multiple sources, because after all, that's one of the things that RDF is so good at.

Is this a "semantic web service"? All it does is convert the data returned by a Yahoo feed into a different syntax and pass it along. I did throw together a little ontology to name the properties, but it doesn't add a lot of semantics. On the other hand, my script's output syntax is based on a semantic web standard, and it makes the data easier to use in semantic web applications, so I suppose it might count as a semantic web service.

I hope this is useful to others, and I hope that more people look for opportunities to convert live feeds of useful data in simple formats into live feeds of RDF.

Much of the promise of RDF and Linked Data is the ease of pulling data from multiple sources and combining it. I recently discovered the SERVICE extension that Jena adds to SPARQL, letting you send subqueries off to multiple SPARQL endpoints and then combine the results. Because a given SPARQL endpoint may be an interface to a triplestore or a relational data store or something else, the ability to query several endpoints with one query is very nice.

The ability to query several endpoints with one query is very nice.

The Jena project's ARQ - Basic Federated SPARQL Query describes the use of this keyword. Before I start quoting from that page, I wanted to jump right in with an example that worked for me to pull birthday and spouse information about Arnold Schwarzenegger from DBpedia and a list of his movies and their release dates from Linked Movie Database in one query:

PREFIX imdb: <http://data.linkedmdb.org/resource/movie/>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX dbpo: <http://dbpedia.org/ontology/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?birthDate ?spouseName ?movieTitle ?movieDate {
  { SERVICE <http://dbpedia.org/sparql>
    { SELECT ?birthDate ?spouseName WHERE {
        ?actor rdfs:label "Arnold Schwarzenegger"@en ;
               dbpo:birthDate ?birthDate ;
               dbpo:spouse ?spouseURI .
        ?spouseURI rdfs:label ?spouseName .
        FILTER ( lang(?spouseName) = "en" )
      }
    }
  }
  { SERVICE <http://data.linkedmdb.org/sparql>
    { SELECT ?actor ?movieTitle ?movieDate WHERE {
      ?actor imdb:actor_name "Arnold Schwarzenegger".
      ?movie imdb:actor ?actor ;
             dcterms:title ?movieTitle ;
             dcterms:date ?movieDate .
      }
    }
  }
}

You can run this query yourself at the sparql.org RDF Query Demo page.

Before you start modeling your own queries on this, it's worth reading the Jena documentation page mentioned above, especially the "Performance Considerations" part:

This feature is a basic building block to allow remote access in the middle of a query, not a general solution to the issues in distributed query evaluation. The algebra operation is executed without regard to how selective the pattern is. So the order of the query will affect the speed of execution. Because it involves HTTP operations, asking the query in the right order matters a lot. Don't ask for the whole of a bookstore just to find book whose title comes from a local RDF file - ask the bookshop a query with the title already bound from earlier in the query.

As an example, both subqueries above specifically ask for information about Schwarzenegger instead of trying to scan the complete databases looking for matches.

Two parts of this trick are non-standard SPARQL, but may become part of SPARQL 1.1: subqueries and the SERVICE keyword. As the latter Lee Feigenbaum slide points out, the SPARQL Working Group is using ARQ's SERVICE keyword as a starting point in thinking about how a query can target multiple endpoints.

My query above of the two different SPARQL endpoints also works from within TopQuadrant's TopBraid Suite of products, so I'm sure I'll be using this on work-related projects more and more.

About two years ago I wondered if RDF Schema had become merely a layer of OWL or if anyone used RDFS by itself without OWL. My theory was that because tools such as TopBraidComposer, Protege, and SWOOP that let you design RDFS vocabularies also let you assign OWL properties to your classes, people used those because they were there, and we ended up with few pure RDFS vocabularies.

I heartily recommend that you read the first 11 or 18 page of the RDFS spec and skim the rest.

Lately, though, it seems that a lot of people who had been using the terms vocabulary/taxonomy/ontology interchangeably have started to understand better when OWL is too much. As they review the issues surrounding the choice between OWL 1 Lite, DL, and Full, around OWL 2 EL, QL, and RL, and the implications of open vs. closed world assumptions, more attitudes can be summarized as "sounds interesting, but pretty complicated; maybe later." This makes good sense for people whose main interest is defining a standardized vocabulary.

SKOS looks pretty good to more and more of them, but here I want to focus on RDFS. As I thought more about it recently, I realized that I had never read the RDF Schema Recommendation, so about five years late I sat down to do so. It's nice to remember, when you're wondering about the true meaning of some term or the relationship between some concepts, that a spec is available where you can just read the official explanation of what's what. (Of course, some specs are less enlightening than others when you're confused about what they describe.)

I found the RDFS Recommendation to be an interesting mix of simple things that are commonly used and complex things that are rarely used. When I printed it out, it was 27 pages, but the summaries and references start on page 18, and the appropriately titled Other Vocabulary section on pages 12 through 17 describes the rarely used features. Let's look at some interesting parts that lead up to that. From the Abstract:

This specification describes how to use RDF to describe RDF vocabularies.

Maybe that's obvious to some, but it's reassuring when confusion over vocabularies, taxonomies, and ontologies comes up. From the introduction:

The Resource Description Framework (RDF) is a general-purpose language for representing information in the Web.

As opposed to being a data model. (It's certainly not a syntax!)

Why do we need this schema language?

RDF properties may be thought of as attributes of resources and in this sense correspond to traditional attribute-value pairs. RDF properties also represent relationships between resources.

RDF however, provides no mechanisms for describing these properties, nor does it provide any mechanisms for describing the relationships between these properties and other resources. That is the role of the RDF vocabulary description language, RDF Schema. RDF Schema defines classes and properties that may be used to describe classes, properties and other resources.

The following is interesting for two reasons: first, because it describes a member of a class as an "instance," reminding me that "individual" is definitely an an OWL term that has no particular role in RDFS. (A little later the document tells us that "the members of a class are known as instances [their emphasis] of the class".) It's also interesting as a nice summary of an issue that often confuses people with an object-oriented background.

The RDF vocabulary description language class and property system is similar to the type systems of object-oriented programming languages such as Java. RDF differs from many such systems in that instead of defining a class in terms of the properties its instances may have, the RDF vocabulary description language describes properties in terms of the classes of resource to which they apply. This is the role of the domain and range mechanisms described in this specification. For example, we could define the eg:author property to have a domain of eg:Document and a range of eg:Person, whereas a classical object oriented system might typically define a class eg:Book with an attribute called eg:author of type eg:Person. Using the RDF approach, it is easy for others to subsequently define additional properties with a domain of eg:Document or a range of eg:Person. This can be done without the need to re-define the original description of these classes. One benefit of the RDF property-centric approach is that it allows anyone to extend the description of existing resources, one of the architectural principles of the Web.

The role and relationship of the rdfs:domain and rdfs:range properties have confused me and many others. The spec's description of their use is rather technical (nothing wrong with that; it's a spec) but there's this nice passage after that:

...an RDF vocabulary might describe limitations on the types of values that are appropriate for some property, or on the classes to which it makes sense to ascribe such properties.

The RDF Vocabulary Description language provides a mechanism for describing this information, but does not say whether or how an application should use it...

For example, data checking tools might use this to help discover errors in some data set, an interactive editor might suggest appropriate values, and a reasoning application might use it to infer additional information from instance data.

RDF vocabularies can describe relationships between vocabulary items from multiple independently developed vocabularies. Since URI-References are used to identify classes and properties in the Web, it is possible to create new properties that have a domain or range whose value is a class defined in another namespace.

I think that makes some basic issues clearer.

I have mixed feelings about the "Other vocabulary" section on features that, from what I've seen, never got much traction: container classes and properties, RDF collections, and reification. On the one hand, usage of these can appear so complex that I think it scared a lot of people away from RDF in the early days, obscuring the simplicity of the triple as the fundamental concept of RDF. On the other hand, as I read about these options now, they looked like they could be fun to play with, in a geeky sort of way. (I also realize that the whole concept of reification—the ability to refer to triples as resources themselves so that properties can be assigned to them—is an important bit of RDF foundational architecture for other good RDF-related ideas to build on.)

So, whether you're new to the whole idea of a standardized definition of a vocabulary or you've been using OWL and RDFS together for years, I heartily recommend that you read the first 11 or 18 page of the RDFS spec and skim the rest, which includes some handy reference material.

I recently had to convert a few Microsoft Word documents to DITA XML and thought it would be worth sharing my notes on the steps I took. To summarize, I opened each Word document with OpenOffice 3.1, saved it as a DocBook XML document, and then converted that to DITA with the XSLT stylesheet from a DITA plugin that I found. Images were a little more trouble, but at least I was able to eventually automate that part as well, dispelling my worries that I'd have to add all the image references to the DITA files by hand.

Word to DocBook

When you open a Word file with OpenOffice and do a Save As DocBook, it assumes that the document uses default Word styles, because that's how OpenOffice knows what's what in the document's structure. The conversion does an impressive job of adding wrappers in the appropriate places considering that it's using an XSLT 1.0 stylesheet. This kind of stylesheet would be much easier to write with XSLT 2, but that reduces the choice of XSLT processors that you can use. It doesn't matter much from the user's perspective, because it's all under the covers anyway. The key thing is the convenience of creating the DocBook version from OpenOffice with a simple Save As.

On the down side, some nested bulleted lists in the original content did not show up in the DocBook version. I found this after converting the eventual DITA version of one of these documents to a PDF file with the DITA Open Toolkit and skimming through the original Word file and the new PDF to do a block-by-block comparison. (I strongly recommend this QA step if you're doing this conversion with important content.) Many bulleted lists got converted to numbered lists as well, although I'm not sure if this was the fault of the Word to DocBook conversion or of a later stage described below. Another small issue is that when the original had more than one space character in a row, all but one got converted to hard spaces to maintain the spacing in XML. I just deleted all the hard spaces from the DITA version with a global replace, but you may want to keep them, depending on how the documents use them.

Typical Word users add space between paragraphs by inserting an extra carriage return, instead of adjusting the styles included with document, so your output from this conversion step might have a lot of empty para elements. You can delete this with a simple XSLT stylesheet or even a global replace in a text editor.

<draw:frame draw:style-name="fr1" draw:name="graphics63" 
  text:anchor-type="as-char" svg:width="6.8972in" svg:height="2.6264in" 
  draw:z-index="49"><draw:image 
  xlink:href="Pictures/10000000000003430000013EC16739CA.png"
  xlink:type="simple" xlink:show="embed" 
  xlink:actuate="onLoad"/></draw:frame>

<inlinegraphic fileref="embedded:graphics63" 
    width="6.8972inch" depth="2.6264inch"/>

<draw:image draw:style-name="fr1" draw:name="graphics63"
            text:anchor-type="as-char" svg:width="6.8972inch"
            svg:height="2.6264inch" draw:z-index="49">
  <office:binary-data>iVBORw0KGgoAAAANSUhEUgAAA0MAAAE+CAIAAADAgVy 
   <!-- lots more data here--></office:binary-data>
</draw:image>

When most people want to take notes on a collection of things, and they know that the notes will have some structure but they're not sure about the nature of that structure just yet, they use a spreadsheet. For each thing that they take notes on, they add a new row; for each attribute of the things under review, they add a column. From an investment banker comparing potential investments to a scout leader planning a camping trip, the grid makes it easy for you to compare similar attributes of different things without forcing to you to specify all of your attributes before starting your data entry like a more serious database application would.

In theory, RDF is ideal for this, because you can assign any attribute name/value pair to any resource that you can identify with no requirement to plan it all in advance, but in practice, it's rarely as easy as pouring names and numbers into a spreadsheet. I've often thought that it would be fun to build a freeform database program that lets people do data entry and make up new fields as they go along, all with RDF underneath. I even wrote some Python code for this a few years ago, but never followed through. Since joining TopQuadrant, I've wondered about assembling something like this with the company's application development tools, but then I realized that the Free Edition of TopBraid Composer pretty much already does this.

Here's a use case that's happened to most people in the modern workforce: you're told that you'll be joining a particular project, and to get you started someone emails a zip file of relevant files for you to review. For my notes on these files, I might create a text file or a spreadsheet, but I'd probably assemble an XML file where I made up element names as I went along. These elements would track the filename, document title, author, age, comments, and probably some project-specific fields. When the big picture starting coming into focus, I'd write a little XSLT to convert this XML to presentable HTML to show to others if necessary.

A key reason that this would be easy for me is that the Emacs nxml mode automates much of the work of entering tags and keeping everything well-formed. How would doing it in RDF be better? I could do the same steps as above using RDF-Friendly XML and nxml's excellent handling of RDF/XML, but I'd rather use a form-based interface instead of Emacs. This is where the free edition of TopBraid Composer comes in.

The first step is creating an RDF data file with all the easily available file metadata: the name, size, and last modification date for each file. I wrote a simple perl script called dir2rdf.pl to do this; it's simple because it declares a File class and all the properties for that class in the namespace declared for the file. (I also created a slightly more complex perl script called dir2nfordf.pl which does the same thing but uses existing classes and properties from the NEPOMUK File Ontology. It's more complex because this ontology has properties based on properties from other vocabularies such as Dublin Core, so editing data with this ontology means pulling in a few layers of other ones.)

When you pipe the result of the Windows dir command into the simpler perl script, it outputs the property and class definitions for the files and an entry like this for each file:

  <File rdf:ID='file11' sd:lastModified='2009-10-30T17:05:00'
        sd:fileName='teams.csv' sd:fileSize='164' rdfs:comment=''/>

Loaded into the free edition of TopBraid Composer, the editing of that "record" looks like this (I've rearranged the combination of screen sections a bit from the default TopBraid "perspective", to use the Eclipse parlance):

I can edit the values on this form, although there's no reason to edit the file name, size, or last modified values. What I'm really going to do is add notes to the rdfs:comment property, as I've already done above, and perhaps add more comment properties for this resource. The really nice part is that I can define new properties in the Properties view on the right—for example, some project-specific subproperties of rdfs:comment—drag them onto the form for any of my File resources, and then add values to them, giving me the functional equivalent of adding new columns to a spreadsheet.

It's actually better than that, because if I wanted to add three contactWithQuestions names to one of these File resources on a spreadsheet grid, I'd have to either add three columns or string together three values in one spreadsheet cell as if they were one. With RDF, though, I can define a contactWithQuestions property and then add three separate values for this property to the same resource. Moving beyond the use of simple string data for the values here, I could create object properties (properties where the value is another resource—in this case, to define relationships between File objects such as mentionedIn or basedOn) by defining them in the Properties view on the right with a range of File. When I want to assign one of these properties to a particular File object, I would drag it from the property list on the right onto the Resource form for that File and then pick out the appropriate file it refers to from a drop-down list. For example, after creating a mentionedIn property, if teams.csv was mentioned in index.html and I wanted to record this in my notes on teams.csv, I'd drag the mentionedIn property onto the Resource Form for teams.csv and select index.html as the value for that property.

Because this is a GUI editing interface, I can also add and delete new File resources (the equivalent of inserting and deleting rows on a spreadsheet) by clicking icons on the Instances view at the bottom. (Another nice bonus with TopBraid Composer is the SPARQL tab next to that, where you can enter and run SPARQL queries about the data.)

So, I've got my form-driven interface that I can use with any RDF data. I've kept my address book in RDF for a long time; maybe I should try maintaining it like this instead of with Emacs.

I've used the cvs and svn version control systems for both work-related and personal projects. For personal work, I used svn in particular more as a backup program, with the added benefit of the version control. Keeping my repository on a thumb drive made it easy to perform the backups when traveling, but perhaps because of sloppiness in removing the thumb drive without clicking the right icons first, my repository got corrupted too often, so I gave up.

I decided to try again with Mercurial and was shocked at how quickly I was able to learn it and get it to do everything I wanted—about an hour. This blog posting convinced me to try it before git, which sounds fascinating but a bit more complicated. By keeping my repository on the local drive and using the clone feature to keep backup copies of the repository elsewhere, I can redo a backup if a thumb drive version gets messed up.

The Mercurial Quick Start lives up to its name, and I kept some notes as I went along to provide my own Mercurial quick reference:

One other note: an .hgignore file tells hg files which to ignore, and putting separate .htignore files in subdirectories of your main project directory works fine.

I once had grand ideas about hooking up a version control system that can assign arbitrary metadata with an RDF triplestore to form the basis of some sort of CMS demo. Mercurial isn't much help here, but when I prioritize the tasks "back up my stuff" and "build a demo CMS around a version control system" the former is clearly much more important. Maybe someday...

Last May, in Adding semantics to make data more valuable: the secret revealed, I showed how storing a little bit of semantics about the word "spouse"—the fact that it's a symmetric property (that is, that if A is the spouse of B, then B is the spouse of A)—let me look up someone's home phone number in my address book even if my entry for him there lacks his home phone number. I like this story because unlike biotech and some of the other popular domains for Semantic Web technology, everyone has an address book and understands the basic properties of an entry: first name, last name, email address, and so forth. (Because so many people have lived through the annoyances of moving their contact information from one email client or phone to another, address books also provide nice use cases for data integration issues.)

Back then, I wrote:

With software that understands an OWL expression stating that spouse is a symmetric property and a rule I define to say that spouses have the same home phone number, I can retrieve Leroy's home phone number...

OWL is great for defining the symmetry, but I glossed over the part about defining the fact that spouses have the same phone number. How do you define such a rule? n3 has a rules language, but I haven't seen it used much as the n3 subset known as Turtle (which leaves out such things) becomes more popular. Instead of defining a Semantic Web rules language, the W3C has decided to have the Rules Interchange Format Working Group standardize an interchange format between the many rules languages out there. (The W3C Rules Interchange Format Basic Logic Dialect PowerPoint presentation by WG co-chair Chris Welty provides good historical background.)

I can write a query that generates the triples I want to infer and call this query a "rule", but what do I do with it?

I've used a proprietary RDF rules language before, and was wondering if a standard one would come along. Some colleagues at TopQuadrant have shown me that we all have a straightforward, standardized RDF rules language right under our noses: SPARQL. I've been appreciating SPARQL's CONSTRUCT form more lately, and CONSTRUCT is the key here: like a SELECT statement, a CONSTRUCT statement defines conditions about which pieces of which triples to retrieve, but unlike SELECT, a CONSTRUCT statement assembles these into new triples. If we view a CONSTRUCT statement as the definition of a rule and the resulting new triples as the result of the execution of the rule, then we have a rules language and plenty of implementations of it available.

For example, the following SPARQL "rule" says that if ?person1 has the spouse ?person2 and the home telephone number ?phoneNum, then ?person2 also has the home telephone number ?phoneNum:

PREFIX  : <http://www.snee.com/ns/demo#>
PREFIX v: <http://www.w3.org/2006/vcard/ns#>

CONSTRUCT { ?person2 v:homeTel ?phoneNum . }
WHERE {
  ?person1 :spouse   ?person2 ;
           v:homeTel ?phoneNum .
}

When run with the following data (for the purposes of this demo, assume that the {:leroy :spouse :loretta} triple was generated by an OWL reasoner that saw {:loretta :spouse :leroy} and knew that :spouse was symmetrical),

@prefix  : <http://www.snee.com/ns/demo#> .
@prefix v: <http://www.w3.org/2006/vcard/ns#> .
:loretta :spouse   :leroy ;
         v:homeTel "434-923-9321" .
:leroy   v:workTel "434-932-5329" ;
         :spouse   :loretta .

It generates the triple {:leroy v:homeTel "434-923-9321"}.

OK, so I can write a query that generates the triples I want to infer and call this query a "rule", but what do I do with it? What makes it a rule about a particular set of data?

Holger Knublauch, a co-worker of mine who designed and developed the OWL plugin for Protégé before coming to TopQuadrant, recently wrote an RDF vocabulary called SPIN ("SPARQL Inferencing Notation"), which—among other things—can express associations between these rules and classes. So, for example, if the blank node rdf:_1 pointed to the query above, the following triple would associate this query rule to the v:Address class:

  v:Address spin:rule rdf:_1

To make the storage of the SPARQL rule in a triplestore even cleaner, Holger has implemented a way to store SPARQL queries as triples, and he's written the code to roundtrip between this and the standard text version. (See the SPARQL Text to SPIN RDF Syntax Converter for an online converter, and see spinrdf.org for more about what else the SPIN vocabulary can do, especially his blog entries as he developed it. I'm now finishing up a tutorial for the use of SPIN features in TopQuadrant products, and except for one optional step of the tutorial, it all works with the free version of TopBraid Composer.)

When you take it a little further, symmetrical properties and many other parts of OWL can also be implemented with SPARQL queries, and there's a lot going on among those who are doing this to find a sweet spot between RDFS and OWL Full that meets typical business needs without using a lot of processing power or dollars.

As with SQL, SPARQL's most popular verb is SELECT. It lets you request the data you want from a collection, whether you're asking for a single phone number or you want a list of first and last names and phone numbers of all employees hired after January 1st, sorted by last name.

CONSTRUCT provides a nice example of how SPARQL is more than a query language; along with extracting data using queries, you can create useful new data as well.

In SPARQL, SELECT is actually known as a query form, and another is CONSTRUCT. According to the SPARQL Query Language for RDF W3C Recommendation, CONSTRUCT returns a graph—a set of triples. I had thought of CONSTRUCT as a way of pulling a set of triples out of a triplestore, especially a remote triplestore, but while reviewing some TopQuadrant training material I realized how handy CONSTRUCT can be to create useful new triples.

For example, let's say you have the following triples written in Turtle syntax to identify the gender and parent/child relationships of a few people:

@prefix : <http://www.snee.com/ns/demo#> .

:jane :hasParent :gene .
:gene :hasParent :pat ;
      :gender    :female .
:joan :hasParent :pat ;
      :gender    :female . 
:pat  :gender    :male .
:mike :hasParent :joan .

The following CONSTRUCT statement creates new triples based on the ones above to specify who is who's grandfather:

PREFIX : <http://www.snee.com/ns/demo#> 

CONSTRUCT { ?p :hasGrandfather ?g . }

WHERE {?p      :hasParent ?parent .
       ?parent :hasParent ?g .
       ?g      :gender    :male .
}

When I ran this query with the data above, ARQ returned the newly constructed triples in Turtle format:

@prefix :        <http://www.snee.com/ns/demo#> .

:jane
      :hasGrandfather  :pat .

:mike
      :hasGrandfather  :pat .

From the same little data file, we can generate triples about who is who's aunt:

PREFIX : <http://www.snee.com/ns/demo#> 

CONSTRUCT { ?p :hasAunt ?aunt . }

WHERE {?p      :hasParent ?parent .
       ?parent :hasParent ?g .
       ?aunt   :hasParent ?g ;
               :gender    :female .

FILTER (?parent != ?aunt)  
}

With this query, ARQ constructs these triples:

@prefix :        <http://www.snee.com/ns/demo#> .

:jane
      :hasAunt      :joan .

:mike
      :hasAunt      :gene .

This isn't really creating new information, but the ability to make implicit information explicit can certainly add value to a system, especially when the rules necessary to assemble the pieces are more complicated than the ones shown above for identifying grandfathers and aunts.

How you use your newly constructed triples depends on how your SPARQL engine gives them to you. As we saw above, ARQ writes them out in Turtle syntax. TopQuadrant's TopBraid Composer displays them in the window used for SPARQL query output, and after you select one or more of them, the "Assert selected constructed triples" menu choice adds them to the graph of triples that you're currently working with. (This works in the free edition as well.)

CONSTRUCT provides a nice example of how SPARQL is more than a query language; along with extracting data using queries, you can create useful new data as well.

While preparing slides for the Semantic Web Overview talk I'll be giving at the beginning of the Semantic Technologies course of the Oxford XML Summer School, I was adding a few slides on Linked Data. (Leigh Dodds is presenting a more detailed class on Linked Data later in the day.) Of course I had to include a slide of Richard Cyganiak's interactive diagram of the Linked Data cloud, and as with many of my slides, I was tempted to re-use a slide from a presentation I'd given before. I found the following image in a talk I gave in February of last year:

I decided to be conscientious and update the image, so I went to Richard's page to get an updated version, and found this:

It looks like the world of linked data is growing at quite a rate! And, if you look closely, you'll see that his latest image says "As of July 2009", so I imagine that there are even more nodes to add to this image by now.