I promised in an earlier
blog post to talk about how to create queries over OWL in
RDF. Â So here it is.
As Ivan alluded in his comment, there are some syntax issues
with talking about OWL restrictions in RDF. Â What is he
referring to? Â Well, let's take the same example in the last
blog post, a datatype restriction about things with age>=21.
 We could write this in Manchester Syntax asÂ
hasAge only xsd:integer [>=21]
But the OWL/RDF rendition of this is where the 'arcane' syntax
comes in. We can see it just by looking at the source code in
turtle, where it looks like this:
[] a owl:Restriction ;
owl:allValuesFrom
[ a rdfs:Datatype ;
owl:onDatatype xsd:integer ;
owl:withRestrictions
([ xsd:minInclusive 21])
] ;
owl:onProperty :hasAge .
In the last blog entry, we saw a rule that would match this sort
of definition, so that we could classify persons of appropriate
ages as Adults. That rule looked like this:
CONSTRUCT {
   ?x a ?restriction .
}
WHERE {
   ?datatype owl:onDatatype xsd:integer .
   ?datatype owl:withRestrictions ?var .
   ?datatype a rdfs:Datatype .
   ?restriction owl:allValuesFrom ?datatype .
   ?restriction a owl:Restriction .
   ?restriction owl:onProperty ?datatypeproperty
.
   ?var rdf:first ?var1 .
   ?var1 xsd:minInclusive ?mval .
   ?x ?datatypeproperty ?val .
   FILTER (?val >= ?mval) .
}
How do you write a rule like that? By looking up in the
standard how to express datatype restrictions, and how to link
those to restricted value sets, and . . . . if that seems labor
intensive and error-prone to you, then you're right. It
is.
But we can use a power-tool to help make this happen. The power
tools aren't included in the free version of TopBraid Composer, so
if you want to follow along here, you'll need the Maestro
Edition; a 30-day trial is available for free.
Start by loading http://workingontologist.org/Examples/adult.rdf into
Composer, just as shown before,
and open it. We're going to use the model itself as a prototype to
create a query. Let's start by looking at an example of the
restriction we want to match - look at the definition of Adult in
the model:
Â
You can type it in just like that. Â But that doesn't help
us write a SPARQL query to match any restriction of this form.
 How can we do that?  If you click on "Graph" at the
bottom of the pane, you can explore this definition, in RDF.
 If you drill down to the Datatype Restriction itself, you get
a view like the top of this figure:
Â
This is just a graphic representation of triples in the model -
you can see all the structure of the RDF representation of the
restriction.Â
Now comes the fun part - let's turn this image into a query
(which, to avoid suspense, is already shown at the bottom of the
figure). Â We want a query that will match "things like this"
restriction. Â What does "like this" mean? Â That's what we
have to specify - there are some aspects of this example that
should be included in the match (like the fact that it is a
owl:Restriction, on a rdfs:Datatype xsd:integer, and that it is a
owl:minInclusive restriction), and others should not be included in
the match (that the property is :hasAge; after all, we this to
match for restrictions on any property). Â So, we select the
things that we want to keep in the query, marked with a small "x"
(you can set/reset the "x" by clicking on the small box in each
node in the graph). Â
Once you have selected the aspects that specify what you mean by
"like this" (a Datatype Restriction, on some property, with
minInclusive over xsd:integers), you can generate the query
automatically by clicking the 
button. Â You can see the generated query at
the bottom of the figure.Â
All the generator did was to take the triples shown in the
figure, and render them in the query. Â Selected nodes (with
"x") appear in the query as themselves; unselected nodes (no "x")
become variables. Properties always show up as themselves.
 Best guesses are made for meaningful variable names; it uses
type information for the guesses. Â
There are a few differences between the generated query and the
WHERE clause of the rule:
WHERE {
?datatype owl:onDatatype xsd:integer .
?datatype owl:withRestrictions ?var .
?datatype a rdfs:Datatype .
?restriction owl:allValuesFrom ?datatype .
?restriction a owl:Restriction .
?restriction owl:onProperty ?datatypeproperty .
?var rdf:first ?var1 .
?var1 xsd:minInclusive ?mval .
?x ?datatypeproperty ?val .
FILTER (?val >= ?mval) .
}
The first difference is ordering of triples - the generator
isn't very fussy about the order in which triples are generated, so
it is different each time (if you are following along at home, your
generated query will probably be different from the one shown here,
and also from the rule). Â
The second difference is the inclusion of a triple to match
data, to wit:
?x ?datatypeproperty ?val .
After all, in a rule, we want to say "when some data satisfies
this restriction, ..." This clause uses the same variable for the
property (?datatypeproperty) as used in the rest of the
query.Â
The final difference has to do with the constant "21". Â The
generated query includes the constant, whereas the rule
turns it into a variable (?mval) and adds a filter to compare it to
the actual data (?val). Â After all, the value "21" comes from
the model, and shouldn't be built in to the rule.Â
So yes, these modifications have to be made by hand (using the
SPARQL editor, where the generator put the query). Â The query
generator should be seen as a power tool; you still need an
operator who knows how to use it, but it simplifies a lot of the
heavy lifting for query writing. Â In this case, we have a rule
with 10 clauses (9 triples and a filter). Â The generator
created seven of the triples, and most of the eighth one; the human
only had to write the last two clauses. Â That is, the power
tool took care of the "arcane syntax" that Ivan referred to,
leaving the human to figure out what they really want the rule to
mean.
I use this feature of TopBraid Composer all the time, in this
pattern. I want to write a query that matches some 'arcane'
bit of RDF (e.g., from dbpedia, the OWL in RDF standard, the XML
DOM, SKOS, etc.). Instead of trying to write a query from scratch,
I find (or even build) an example of the thing I want to
match. Then I generate the query - automatically guaranteeing
that I didn't leave out any triples, that I got all the namespaces
and property names correct, that I didn't accidentally collide
bnodes by giving them the same variable name, etc. Then I
beat up the result to create the query that I really want - in
which I define what I want to do with the match.Â
So when you see an elaborate query with dozens of triples in it,
and you wonder what sort of geek can write or maintain such a
thing, keep in mind that it might not have been written at all; it
might have been generated from an example.
since 2005.
The Semantic Web Science Association (
Imagine the
following: A car full of Semantic Web Experts is on it’s way back
from Graz. They hand around an iPhone to record some first
impressions about the just ended 
If Sir Tim Berners-Lee can 
shot of him doing his imploring
whilst stood in front of a shot of the LOD cloud. -Â
Simple really, just publish your data as Linked
Open Data and all will be
wonderful as we move towards the sunlit Semantic Web uplands.Â
Unfortunately life is never that simple – LOD is not a single
identifiable thing. As 
Take a 
My guests on this Talking with Talis
podcast are Wernher Behrendt and John Pereira of Salzburg
Research. They are part of the team behind