On Thu, Jul 4, 2013 at 3:28 AM, Ian Dickinson <[email protected]> wrote:
> On 03/07/13 18:51, Joshua TAYLOR wrote:
>>
>> HI all, A recent StackOverflow question [1] mentioned that OWL2's
>> owl:NamedIndividual couldn't be converted to an OntClass (presumably
>> for an OntModel with a OntModelSpec with an OWL profile). Ian
>> Dickinson pointed out that this arises from the fact that Jena's
>> reasoners don't yet support OWL2, so owl:NamedIndividual isn't known
>> to be an rdfs:Class. (I know OWL2 support isn't currently planned,
>> but that contributions are welcome. :) This isn't the question here.)
>> I was surprised to learn that things which are rdfs:Classes can be
>> converted to OntClasses, even if they are not owl:Classes.
>
> There are two reasons for this. The first is that OntClass is not a semantic
> commitment: none of the Ont* Java classes add any representation or state to
> the resources in the underlying model. It's just a convenience API. In
> principle, all of the API on the Ont* classes is available to non-OntAPI
> code, you just have to work a bit harder to get the underlying triples out.
> The second reason to be permissive is the open-world assumption. Not knowing
> something (this resource is an owl:Class) is not the same as it being false.
> The corollary of this observation is that any resource should be able to
> .as() any Ont* facet class, without checking. I do wonder, in hindsight, if
> this should have been the default (ie that strictMode would be false by
> default). It's a change we can still make, if there's support for doing
> that.
>
> Parenthetically, as you note from the code the .as() checking does not
> assume that the model has an inference engine attached. Some of the .as()
> checks would be much easier if we could presume the presence of a reasoner,
> but the conservative case is to assume not.
>
>> I understand that Jena is being rather permissive here, and that the
>> implementation is intentional. The code that checks whether something
>> can be converted to an OntClass for the OWLDLProfile clearly checks
>> for RDFS.Class, RDFS.Datatype, and also anything that has been used as
>> the RDFS.domain or RDFS.range of a property (from OWLDLProfile.java):
>>
>> [...]
>>
>> This leads to some surprising results in some situations that are
>> surprising to me.
>
> You've cited one "surprising result". Do you have others?
Well, I'd say that there's at least one per rdfs:Class of things used
to serialize OWL in RDF/XML. E.g., similar things happen for
RDFS.Property, whose instances can't be converted to Individuals, and
so on. :) But no, this isn't something that's affected me, although
it does mean that I might be more cautious in using some of the .as()
methods in the future.
>> For instance, it means that a Resource can be
>> viewed as an OntClass, but that trying to listInstances of the
>> OntClass results in more conversion errors. For instance, the
>> following code gets an OntClass for OWL.Class, and then throws an
>> error when owl:Thing can't be converted to an Individual:
>
> I think that's just a bug, related to a case that's not currently covered by
> the "let's assume we don't have a reasoner" conditional. If you'd like to
> log it as a Jira item, I will fix it as soon as I have a moment.
I'm not sure I follow you here. What's the bug? The OWLDLProfile has
the following for converting to OntClass and to Individual:
{ OntClass.class, new SupportsCheck() {
@Override
public boolean doCheck( Node n, EnhGraph eg ) {
Graph g = eg.asGraph();
return hasType( n, eg, new Resource[] {OWL.Class,
OWL.Restriction, RDFS.Class, RDFS.Datatype} ) ||
// These are common cases that we should support
n.equals( OWL.Thing.asNode() ) ||
n.equals( OWL.Nothing.asNode() ) ||
g.contains( Node.ANY, RDFS.domain.asNode(), n ) ||
g.contains( Node.ANY, RDFS.range.asNode(), n ) ||
g.contains( n, OWL.intersectionOf.asNode(),
Node.ANY ) ||
g.contains( n, OWL.unionOf.asNode(), Node.ANY ) ||
g.contains( n, OWL.complementOf.asNode(), Node.ANY )
;
}
}
{ Individual.class, new SupportsCheck() {
@Override
public boolean doCheck( Node n, EnhGraph g ) {
if (n instanceof Node_URI || n instanceof Node_Blank) {
return !hasType( n, g, new Resource[]
{RDFS.Class, RDF.Property, OWL.Class,
OWL.ObjectProperty, OWL.DatatypeProperty, OWL.TransitiveProperty,
OWL.FunctionalProperty, OWL.InverseFunctionalProperty} );
}
else {
return false;
}
}
}
Since RDFS is much more loosely structured than OWL, there's no issue
with the instances of an RDFS Class also being RDFS Classes or
Properties, so it seems like as long as an RDFS Classes can be
converted to OntClasses, there will be instances of those classes that
can't be converted to Individuals. Furthermore, it seems like the
number of instances that can't be converted would tend to *increase*
in the presence of a reasoner as more triples of the form [?x a
rdfs:Class] and [?x a rdfs:Property] appear.
>> This seems to be by design, but now I'm curious whether allowing
>> rdfs:Classes to be converted to OntClasses in OWLDL OntModels is
>> useful in practice and, if so, for what purposes?
>
> I think in practice relatively few Jena users are strictly in DL. Most
> ontologies that I see are effectively in OWL Full, or at least, the
> developer doesn't care one way or the other (e.g. it's a linked data project
> rather than an ontology project per se). If I was going to propose a change
> at this point, based on the bug reports or help requests we've received over
> the years that Jena has been in use, I would make strict mode checking more
> rather than less permissive. Or, indeed, turn strict mode off by default as
> I mention above.
I see; I guess I'm one of those users that (for ontological
reasoning) tends to stay in DL. For non-ontological linked data stuff,
I usually end up working with it as plain RDF, not trying to treat it
as OWL Full, but I can see lots of different use cases out there.
Coming from that angle, if I had to suggest a change, it would be to
make checking _for the DL profile_ *more strict* (so that at OntClass
from an OntModel with a OWL DL profile is something that can actually
be an OWL DL class). For the Full profile, things could be permissive
as anyone likes. Maybe people working with OWL Full but trying to use
OWL DL OntModelSpecs would be forced to switch to OWL Full
OntModelSpecs, but that doesn't seem like a terrible thing, in my
opinion.
(I'll point out too that I was completely unaware of this until the
recent StackOverflow post, and that, to my knowledge, it hasn't
affected me to date, and probably won't affect me in the future one
way or the other. If I'm voicing strong or non-backwards-compatible
positions, it's only that I can because I have so little stake in
this. :) )
Joshua
--
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
