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

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.

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 is certainly true, at least in my view, that consensus on this issue 
should be found before moving ahead with Boris' proposal.

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.

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...

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

> 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).

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.

> * 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...

> * 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?


> * 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?

> * 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.

> ====
> 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.

> ====
> 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?

> ====
> 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.

> ====
> 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...

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