Re: A possible way of going forward with OWL-R unification (ISSUE-131)

I have been reading all the emails (!), and it seems to me that there  
is a lot of miscommunication going on. I will try to summarise some  
of what has been said and (I hope) clarify a few points.

First, a point of clarification. I think that we need to distinguish  
between the *language specification* and what it would mean to be  
*conformant*. A language specification (usually) consists of two  
parts: a syntax and a semantics. The syntax part defines a set of  
possible inputs (RDF graphs in the case of OWL-R); the semantics part  
defines the "meaning" of the inputs in this set. Conformance is  
mainly related to the behaviour of a system when presented with one  
of these graphs; there is no particular reason why it has to say  
anything about what the system does when presented with a graph that  
is *not* in this set. I.e., we could define conforming OWL-R  
reasoners as those that, when presented with an RDF graph that can be  
parsed into the relevant structural spec, will satisfy the semantic  
conditions set out in Section 4.4 (http://www.w3.org/2007/OWL/wiki/ 
Profiles#Relationship_between_OWL-R_DL_and_OWL-R_Full). Note that  
this says nothing about what the system should do if presented with a  
graph that isn't a member of the set defined by the syntax spec -- it  
may choose to reject it, or to carry on and "do its best" (with or  
without some warning).

Bearing this in mind, what I understood from Boris's proposal is that  
the "unified" OWL-R would define a syntax -- i.e., a set of graphs --  
such that for any graph in this set it is possible to provide very  
precise guarantees about the behaviour of an implementation based on  
the rule set. There is no reason (or intention I hope) to specify  
conformance such that conformant systems would be obliged to reject  
all other graphs. On the contrary, I would expect rule-based OWL-R  
reasoners to process arbitrary RDF graphs (they may or may not choose  
to issue a warning that the precise guarantees can no longer be  
made). Such a system would be *fully conformant* with the spec.

If we now consider some of the (reasonable) concerns that have been  
addressed, we can hopefully see that things are not so bad as has  
been feared (and perhaps even quite good):

Concern 1: Won't I have to implement a complicated check in order to  
be a conformant OWL-R implementation?

Answer: Not at all -- you will just have to "do the right thing" for  
graphs that would satisfy such a check. An implementation based on  
the given rule set will do this, and so will be conformant. An  
implementation *may* choose to implement the check, and *may* use it  
to warn users when it can't guarantee to derive all consequences, but  
this isn't required.

Concern 2: Aren't we losing something because we can no longer  
process as many RDF graphs?

Answer: Not at all -- conformant implementations can (and I assume  
will) continue to process all RDF graphs.

Concern 3: What will we call the fragment and/or the rules?

Answer: The fragment is called OWL-R and the rule set the OWL-R rules.

Concern 4: Won't I scare off users/customers by telling them that my  
OWL-R system is sound but not complete for OWL Full?

Answer: Maybe, but this was already true for OWL-R Full, so nothing  
changed there. It seems reasonable to imagine that anyone interested  
in this kind of technical information will understand that it is the  
best that *any* reasoner can do for an undecidable language.


Perhaps I can now also state a little more clearly some of the  
attractive features of Boris's proposal:

* OWL-R can be promoted as the profile targeted at scalable rule- 
based implementation without the potential confusion of the DL/Full  
distinction. The potential for confusion seems to be even worse if we  
have to explain that OWL-R DL is a profile, but that OWL-R Full is  
something else.

* OWL-R is a well defined profile, and as such a "first class citizen".

* OWL-R implementations can provide additional functionality while  
still being fully OWL-R compliant because the extra functionality  
won't affect those graphs for which a guarantee of completeness is  
being made.

* OWL-R implementations *can* warn users when they are processing RDF  
graphs for which they can no longer guarantee to derive all  
consequences; this was not possible before, because there was no  
syntactic specification of any kind.

* Existing OWL Full implementations can double as OWL-R  
implementations, and will be fully conformant provided they implement  
at least the rules in the OWL-R spec (which I guess is the case for  
most such implementations); a particularly nasty feature of the  
existing spec is that OWL Full reasoners that derive more  
consequences than those called for in the OWL-R spec are actually  
*incorrect* for OWL-R.

* There would be no need for owl:intendedProfile, and  
interoperability between systems implementing different profiles  
would be much improved.


Finally, regarding "messaging", I imagined a conversation between an  
OWL-R implementer/vendor and a potential user/customer of OWL 2:

====
User: I need scalability up to very large volumes of RDF data, but I  
also need most of OWL's features; which profile should I use?

Old Answer: Either OWL-R DL or OWL-R Full depending on the kinds of  
guarantee you need w.r.t. completeness.

New Answer: OWL-R.
====
User: An OWL-DL vendor told me that their reasoner guarantees to  
return all and only correct answers; is your reasoner like that?

Old Answer: No.

New answer: Yes -- provided that your RDF graph satisfies certain  
conditions; our reasoner can warn you when these conditions are not  
satisfied.
====
User: I may also want to use my ontologies with an OWL Full reasoner;  
can I do that?

Old Answer: No -- you might get incorrect answers.

New Answer: Yes.
====
User: I may also want to use my ontologies with an OWL DL reasoner;  
can I do that?

Old Answer: No -- you might get incorrect answers.

New Answer: Yes -- provided that the DL reasoner accepts your ontology.
====
User: Can you extend your system with feature X which I absolutely  
need in my application.

Old Answer: No, because it would then no longer be standards conformant.

New Answer: Yes -- for a small fee :-)
====

Received on Friday, 18 July 2008 10:16:14 UTC