On Fri, 2011-10-07 at 18:00 -0400, Joshua TAYLOR wrote:
I've not followed this entire thread but the following jumped out at
me ...
> At any rate, what I think I'm supposed to take away from this is that
> RDF triples have to have URIs as their predicate, but Restrictions
> only have to have rdfs:Properties as their owl:onProperty, and there
> can be rdfs:Properties that aren't URIs (e.g., blank nodes). However,
> the only rdfs:Properties that can be used as *Jena* Properties are
> URIs. Does this sound right?
Not quite. It's more complicated than that.
OWL DL (and its many variants) impose a lot more syntactic constraints
than simply the rdfs:range of owl:onProperty implies. In particular,
there are a lot of restrictions on where you can use bNodes.
If we ignore DataProperties and just think about ObjectProperties
then ...
In OWL (1) DL the class restrictions could only apply to an
individualvaluedPropertyID which must be a URIreference (i.e. no blank
nodes). Likewise inverseOf applies only to an
individualvaluedPropertyID.
In OWL 2 DL then class restrictions apply to ObjectPropertyExpressions
and an ObjectPropertyExpression is now either an ObjectProperty (which
must be an IRI) or ObjectInverseOf(ObjectProperty). [1]
So in OWL 2 DL there is a syntactic allowance for declaring anonymous
inverses but it's a special case. You can't just go sticking arbitrary
bNodes anywhere you see a rdf:Property and expect it to still be DL.
Of course, in OWL full you can do anything you like so long as it is
syntactically legal at the RDF level.
The Jena OntAPI currently only supports OWL 1. If it gets extended to
OWL 2 then it will need some way to handle anonymous inverses.
In the meantime you can create anonymous inverses manually for use in
restrictions:
ont.setStrictMode(false);
ObjectProperty p = ont.createObjectProperty(NS + "p");
ObjectProperty ip =
ont.createResource()
.addProperty(OWL.inverseOf, p)
.as(ObjectProperty.class);
Dave
[1]
http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Inverse_Object_Properties
