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

Ian,

I hope it is all right if I do not go to the usual inline reply style in 
this case. The main reason is that, I think, we are in agreement for the 
essential problems, and what is then important is to have the essential 
points pinned down for further reference. How we got there has only a 
historical interest...

Thanks again for having stated the conformance question clearly. It is 
indeed at the heart of the issue.

1. The conformance issue. Actually, I think that the issue as we 
discussed is slightly more than Issue-130[1]. Indeed [1] only asks 'how 
to handle conformance and nonconformance', whereas I think our question 
is '_what_ is conformance?'. (Having thought of it a bit more, I do not 
have, personally, any objection to the formulation you propose.)

Actually, as an aside concerning our core discussion, I could see an 
additional editorial issue, too. Indeed, while the old consistency 
checker clause[2] does go in this direction, I have not found any 
explicit conformance clause in the old OWL documents (I may have missed 
it, in which case my apologies...). It may be worth considering an 
explicit conformance clause in, say, the Profile document (maybe also 
somewhere else where DL vs Full are discussed) describing, in essence, 
the core of this discussion. It may help some other hotheaded readers 
like me:-). Not all W3C recs have something like that, but some do (eg, 
though in a different area, ITS has something like that[3], so does 
WSDL[4] or RDFa[5]), and I think it would improve the quality of the 
documents.

2. I guess the editorial structure in the profile doc will be something like

- OWL R
   (general descr)
   - precise spec in terms of grammar, more or less like the current 
OWL-R-DL
   - "Reasoning in OWL-R and RDF Graphs using Rules" as you put it below

and that could then work indeed. There will be some question on the 
details coming up, but let us cross the bridge when we get there.

Two (minor) procedural questions/issues:

- Would it be important to raise a separate issue on what conformance 
means, just to leave a better paper trail than this long discussion? As 
I said, I feel that this is more than Issue-130... On the other hand, it 
might be unnecessary administration...

- If the issue on conformance is decided in direction of what you 
propose and then Boris' proposal is accepted, I guess that makes 
Issue-116[6] moot, ie, CLOSED. One open issue less;-)

Thanks again

Have a nice week-end

Ivan

[1] http://www.w3.org/2007/OWL/tracker/issues/130
[2] http://www.w3.org/TR/owl-test/#consistencyChecker
[3] http://www.w3.org/TR/2007/REC-its-20070403/#conformance
[4] http://www.w3.org/TR/2007/REC-wsdl20-20070626/#markup
[5] http://www.w3.org/TR/rdfa-syntax/#s_conformance
[6] http://www.w3.org/2007/OWL/tracker/issues/116


Ian Horrocks wrote:
> 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
> 

-- 

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