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

From: Ivan Herman <ivan@w3.org>
Subject: Re: A possible way of going forward with OWL-R unification (ISSUE-131)
Date: Thu, 17 Jul 2008 11:56:39 +0200

> Michael,
> 
> instead of answering each of the points separately, I try to summarize
> again my problems; sorry for the long mail. I actually believe that the
> issue is really to understand one another's position because, again in
> my belief, the solution is not that complicated...
> 
> Let us say we implement Boris' proposal and that we have a graph G that
> includes the following:
> 
> my:List rdfs:subClassOf rdf:List.
> my:inst my:prop [
>    a my:List;
>    rdf:first "Something";
>    rdf:rest [
>      a my:List;
>      rdf:first "Something else";
>      rdf:rest rdf:nil;
>    ] []].
> 
> Let us also say we have an implementation (A) of OWL-R that implements
> the profile using some sort of a tableaux algorithm. That implementation
> has no other choice that to reject graph G because it cannot convert
> this graph into valid functional syntax or, if it does that, it will be
> invalid due to the first triple. So it will reject G, and this behaviour
> will be perfectly fine and conform to the OWL-R Standard Profile.

I don't see this.   The implementation could, if it wants, have some
sort of heuristic mechanism that recognizes safe uses of lists and
performs some sort of special-purpose processing on the above fragment.
This would be an extension to our specs, but that isn't forbidden for
conformant implementations, as far as I know.

> Let us also say that we have an implementation (B) of OWL-R that
> implements the profile using forward chaining, using the rules that are
> also precisely described in the profile document on OWL-R. (Note that,
> in contrast to what was said at the meeting, there is no issue of _any_
> extension here; (B) implements those rules and _only_ those rules
> following exactly what is in the Standard) 

I don't see this either.  The proposed OWL-R is a language and this
example falls outside of the language.  Any implementation that handles
inputs that fall outside of OWL-R is implementing an extension to OWL-R.

Suppose, for example, that we had defined the character set of OWL to be
7-bit ASCII.  An implementation that treated octets with the high-order
bits as letters would be implementing an extension of OWL.  However, it
could be the case that the implementation was actually written for 7-bit
ASCII and the treatment of the extra "characters" was just an
unidentified feature of the implementation that was never
envisioned. Would you deny that this was an extension?

> Seeing G, (B) has two
> choices:
> 
>   1. reject G as invalid for OWL-R, according to the official profile
> definition
>   2. apply the rules that are perfectly o.k., valid, sound, etc, for
> that case and infer:
> 
> my:inst my:prop ("Something" "Something else").

Well, (B) could do lots of other things, including, maybe, run forever,
but these seem to be two interesting behaviours.

> If the (B) chooses #1, it abides to the requirement of the standard,
> ensures interoperability with (A), but rejects an RDF Graph that is
> perfectly clear, clean for RDF applications for no good reasons except
> for standard compliance. 

Yep, isn't interoperability a pain!

> Alternatively, it [could choose to] do #2, which is (in my
> view) the sound choice both for the users and the implementers. 

Why?  #2 changes the guarantees that the implementation provides.  Is
this a complete no-brander?  I don't think so.  Some applications appear
to want to work in an environment where the answers they work with
are known to cover all the answers.

> (B.t.w.,
> [#1?] forces the implementation to implement the not-so-trivial conversion
> of RDF to the functional syntax for no other reasons than to check
> against a not-so-trivial specification of conformance. I would expect
> implementations based on rules to decide not to do that.)

Perhaps.

> If (B) implementer chooses #2, can it announce that it is an OWL-R
> implementation? In my view that is not the case, because it cannot
> ensure interoperability with (A). What it implements is OWL-R plus
> something, so to say. It of course correctly handles all bona fide OWL-R
> graphs, but slightly more than that.

I believe the sentiment of many in the working groups was that
implementations that provide #2 can be labelled as OWL-R reasoners.

> My claim is that we have to have a clear reference to what this OWL-R
> plus something is, with a clear identification in the standard
> document. If we do not want to call it a 'profile' but something else,
> that is fine with me. We can refer to it as a semantic subset of
> OWL-Full. We can call it 'OWL-R++', 'OWL-R Full', 'OWL-R/RDF', whatever
> (the latter was the name proposed by Boris).  But there has to be a
> clear, undisputable reference to the 'thing' that this implementation
> does and my claim is that the name 'OWL-R' does not properly cut
> it. Note that, editorially, it can be as simple as giving a clear
> identification in the document for the rule set (it will be part of the
> document anyway) and call it a decent name that one can clearly refer to
> without looking at anything else.

I hereby propose "the rule set for OWL-R". 

> The characterization in the document of what this Rule set does should
> also be more positive than 'incomplete OWL-Full implementation' (even if
> that is technically correct). 

OK, if you object to calling this spade a spade, then lets just keep
silent about what the rule set for OWL-R does for arbitrary RDF graphs.

> If I had a company selling, say, an OWL-DL
> like reasoner, I do not think I would want to put on my selling brochure
> 'my product is an incomplete OWL-DL implementation' even that was
> technically correct

Bijan has already found evidence to the contrary.

> http://jena.sourceforge.net/inference/#overview
> 
> """RDFS rule reasoner
> Implements a configurable subset of the RDFS entailments.
> OWL, OWL Mini, OWL Micro Reasoners
> A set of useful but incomplete implementation of the OWL/Lite subset of the OWL/Full language.
> DAML micro reasoner"""

 (I would come up with a name, some sort of
> characterization of what it does, etc). The same holds here. Maybe the
> only thing we can do is to add some text to the ruleset saying something
> like 'This rule set will actually accept more RDF graphs than OWL-R' and
> give some examples like mine (It would be good to be able to
> characterize those Graphs a bit better but that may not be possible,
> technically. I do not know. You tell me). I can even live with not
> saying anything in the text of the Profile document and add something in
> the Primer instead: there are several possibilities. But we have to have
> something for the community to help its messaging and interoperability.
> 
> Michael, is this a little bit clearer?
> 
> Ivan

peter

Received on Thursday, 17 July 2008 10:58:18 UTC