W3C home > Mailing lists > Public > public-owl-wg@w3.org > July 2008

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

From: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>
Date: Fri, 18 Jul 2008 18:07:26 +0100
Message-Id: <6715EC4B-56D4-45D3-82A5-4DD4D2399292@comlab.ox.ac.uk>
Cc: "OWL 1.1" <public-owl-wg@w3.org>
To: Ivan Herman <ivan@w3.org>

On 18 Jul 2008, at 15:26, Ivan Herman wrote:

> Ian,
>
> thanks for this. It indeed helps to clarify the issues.
>
> Ian Horrocks wrote:
>> 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.
>
> You are right in saying that this is one of the central questions  
> of the issue. But I am not 100% sure that your characterization of  
> conformance has indeed group consensus (eg, this is not the way I  
> read Bijan's mail yesterday). I must admit that, until now, this  
> was not my view either, ie, for me conformant systems would be  
> supposed to reject graphs that are not in their 'domain'. This is,  
> actually, not an OWL-R issue, isn't it? I mean, the same issue  
> arises with a DL-Lite and EL++ profile or with DL as a whole.

Yes, it is an issue for all profiles -- Issue-130 in fact :-)

We haven't really discussed it yet, so we don't have consensus. The  
characterisation I have given is, however, consistent with the OWL 1  
spec (see http://www.w3.org/TR/owl-test/#consistencyChecker), and I  
don't see any reason why we would want to impose something much  
stricter for OWL 2.


>
> I could feel some ratholes here in terms of interoperability. If I  
> have a graph accepted by implementation (A), can I be sure that it  
> will be accepted by (B)?

It depends on the graph and the implementation. For any value of ?x,  
an OWL-?x implementation *must* accept graphs that match the OWL-?x  
syntactic profile. I can use a Syntax Checker (see http://www.w3.org/ 
TR/owl-test/#syntaxChecker) to determine the profile of my graph; I  
can then be sure (modulo bugs) that my graph will be accepted by any  
conformant implementation of the relevant profile.


>
> It is certainly true, at least in my view, that consensus on this  
> issue should be found before moving ahead with Boris' proposal.

That seems reasonable. Hopefully it won't be too difficult, as *no  
change* seems a sensible way to go (and would maintain backwards  
compatibility).


>
> In what follows I try to react on your point with _your_ definition  
> of conformance in mind.
>
>> 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.
>
> I agree.
>
>> 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.
>
> I agree
>
>> 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.
>
> O.k. This was one of my issues from the start. Do you agree that we  
> should have a clear and referencable 'name' for those rules not  
> just buried in the text somewhere along the lines...
>
> Note that, in my feeling, non-DL (ie, RDF only) users will hardly  
> look at the OWL-R functional specification (which may not be very  
> readable to them). For that crowd, the rule set will be the _only_  
> point of reference. That is why I keep saying that a clear  
> reference to those should be present.

Of course there will be some editorial issues if we go ahead with  
Boris's proposal, but AFAICT it would result in the rules being more  
prominent and much easier to refer to: Currently, you would have to  
refer to Section 4.3.2, the OWL-R Full Axiomatization Using First- 
Order Implications; in Boris's proposal you would refer to Section  
4.3, Reasoning in OWL-R and RDF Graphs using Rules. I have no doubt  
that we can improve on this title, but it is at a higher level in the  
document and does at least refer to Rules -- how about something like  
"Reasoning with RDF Graphs using OWL-R Rules"?


>
> I have a sense that the only point of contention (if your approach  
> to conformance is accepted) is that the proposal would  
> (artificially) remove the name OWL-R-Full altogether...

It is true that under this approach the name OWL-R Full would  
disappear, but so would the name OWL-R DL. I'm not sure what you mean  
by "artificially".


>
> (I do not care at the moment what the name is, after all, afaik,  
> the names of all profiles are still in flux).

You are right in saying that the names are still to be determined,  
but it seemed to me that it would be much easier and better to  
present a single OWL-X profile (whatever X turns out to be), and to  
characterise it as the profile for implementers who want to use rule- 
based systems and for users who want scalable reasoning for very  
large volumes of RDF data while still using most of OWL's features.  
(I'm not proposing this text, just trying to give the general idea.)


>
>> 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.
>
> I would certainly not use those terms for a possible customer of  
> mine, in spite of Bijan's and Peter's repeated reference to the HP  
> approach (which is only a single example). But o.k., tastes differ.  
> However, if I do have a clear reference to say 'I implement OWL-R/ 
> RDF' (or whatever name we may decide on, that one was Boris'), that  
> is o.k. and fine for non-experts (in my view).

I agree that I probably wouldn't use these terms with customers  
either, but I think that this is a separate and irrelevant issue  
(nothing changes in the two cases, and it is just a matter of taste  
as to how you want to present it).

Regarding a clear reference, this seems to me to be one of the big  
advantages of Boris's proposal: vendors can simply say "we implement  
OWL-R", "our implementation is OWL-R conformant", or whatever.  
Currently, no-one can claim to implement OWL-R, because OWL-R is only  
a heading under which you can find the OWL-R DL profile and the OWL-R  
Full "thing" (I think we all agreed that OWL-R Full isn't really a  
profile).


>
> Of course, experts can and will find out the exact  
> characterization. But that is a different crowd.
>
>> 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.
>
> That is probably true
>
>> * OWL-R is a well defined profile, and as such a "first class  
>> citizen".
>
> That was the case before, too.

No, it wasn't, because as I explained above OWL-R isn't really a  
profile at the moment, it is heading under which you can find the OWL- 
R DL profile and the OWL-R Full "thing".


>
>> * 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.
>
> I would _not_ discuss those 'extra' features here, because that was  
> never our issue...

I agree that this is not the main issue, but only the "icing on the  
cake". Even so, it does seem to be a very attractive features of OWL- 
R under Boris's proposal, and one that I think would be very  
appealing to vendors and users alike.


>
>> * 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.
>
> Yes there was, OWL-R-DL is already part of the document and OWL-R- 
> Full implementation did have the possibility to check a graph  
> against that if they wanted. In this sense nothing will change,  
> will it?

Yes, implementations could do that, although there is no clear  
justification for an OWL-R Full implementation to check its input  
against the OWL-R DL syntax.


>
>
>> * 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.
>
> That I would like to understand, and I don't (I know that OWL-R- 
> Full will be incomplete, I would like to understand the  
> 'incorrect'). And I do not even understand why this situation would  
> change because, after all, nobody planned to change any of the  
> rules that are currently in the document! Ie, if I have a rule- 
> based implementation that is a conformant OWL-R implementation in  
> your definition, it will have the same issue, won't it?

Of course if I implement *exactly* the specified rules, then nothing  
changes and I have a conformant implementation under the current spec  
and under Boris's proposal. Imagine, though, that I want to use one  
of the many existing rule-based OWL reasoners with my OWL-R ontology.  
This reasoner probably already implements the OWL-R rules (because  
these rules correspond to basic OWL entailments), but probably also  
implements additional rules that derive more OWL-Full consequences.  
For example, it may include rules that derive at least *some* of the  
consequences due to existentials occurring on the rhs of subClass  
axioms.

Under the existing spec, this reasoner is *not* OWL-R compliant  
because of the way the existing spec defines the OWL-R Full semantics  
(roughly speaking, OWL-R full consequences are all and *only* those  
that follow from the rules). Under Boris's proposal, this reasoner  
*is* OWL-R compliant, because for the syntactically defined subset of  
graphs it will derive all and only the consequences that follow from  
the OWL-R rules.


>
>> * 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.
>
> I am not sure there is such a difference. If I say OWL-R but I  
> implement them with the rules, I have the same situation vs  
> completeness as before, don't I? Or would my answer be: use only  
> those OWL-R Graphs that can be checked against the official profile  
> definition? I do not find that answer any less complex than the old  
> answer.

What I *could* say with respect to rules, completeness and so on is  
much the same as before. The advantage is that I don't *have* to say  
anything, because I don't need to explain the difference between OWL- 
R DL and OWL-R Full.


>
>> ====
>> 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.
>
> Provided the reasoner implements the check. In your definition I  
> can be a proper OWL-R reasoner that does not do that. In the old  
> case the very same answer is possible.

It isn't quite the same, because OWL-R Full has no syntactic  
specification (of course I could warn users that the input isn't an  
OWL-R DL graph, but this seems a strange thing for an OWL-R Full  
reasoner to do). So, under the current spec, the answer really is No.  
The new answer could have been Yes, but as a super fair and honest  
vendor I explained to my (potential) customer exactly what caveats  
should be applied to this answer. This is why I am so poor :-)


>
>> ====
>> 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.
>
> As I said, I do not understand that. If I am based on the rules and  
> I do not do check, isn't the situation exactly the same?

I hope I succeeded in explaining this above -- if the OWL Full  
reasoner derives any additional OWL Full consequences, then it is  
really *incorrect* (unsound) according to the existing spec.


>
>> ====
>> 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.
>
> Again, I do not think the difference is so clear. Checking against  
> the OWL-R-DL syntax was a possibility in the 'old' setting as well.

The same thing applies for an OWL-DL reasoner as for an OWL Full  
reasoner -- if it derives additional consequences (say from an  
existential on the rhs of a subClass axiom), then it is really  
*incorrect* (unsound) according to the existing spec.


>
>> ====
>> 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 :-)
>
> Sorry, I do not understand that. First of all, extension of the  
> rule set was never the question and issue. If your definition of  
> conformance is applied to the current setup, then the 'old answer'  
> is actually wrong. But I do not think this question is relevant for  
> our discussion in the first place...

As above: this is just "icing on the cake".


I hope that I managed to clarify everything and to address all of  
your concerns. I honestly believe that Boris's proposal is better for  
OWL 2 and *much better* for the rule based profile (whatever we end  
up calling it) than the current spec.

Ian



>
> Ivan
>
> P.S. I will be on vacations for 3 weeks starting Monday and  
> completely off-line starting Thursday. That explains my possible  
> non-participation in the further discussions...
>
>
>
>> ====
>
> -- 
>
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Friday, 18 July 2008 17:08:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 18 July 2008 17:08:27 GMT