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

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.

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

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. Alternatively, it will do #2, which is (in my 
view) the sound choice both for the users and the implementers. (B.t.w., 
#2 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.)

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.

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.

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


Michael Schneider wrote:
> Bijan Parsia wrote:
> 
>> On 16 Jul 2008, at 18:01, Ivan Herman wrote:
>>
>>> Peter F. Patel-Schneider wrote:
>> [snip]
>>>> 4.4
>>>>  The rules from Section 4.3 can be applied to arbitrary RDF
>>>>  graphs, in which case the produced consequences are sound but
>>>>  not necessarily complete.
>>> I have already objected to this type of description elsewhere
>>>
>>> HTTP://www.w3.org/mid/487A187C.4070509@w3.org
>>>
>>> this type of slightly derogatory description
>> How is it derogatory? 
> 
> It doesn't sound derogatory to me, but...
> 
>> It's an accurate description and I think it's a
>> more useful conceptualization for users. Certainly better than
>> "semantic subset" which, frankly, I often don't understand :)
> 
> ... would be confusing to me if I was a potential implementer. The message
> would probably be to me: Even if I implement the whole set of official OWL R
> triple rules, I cannot safely assume to have a complete OWL R reasoner at
> the end. This may technically really be the case, but it's certainly hard to
> communicate.  
> 
>>> is certainly not what vendors would put as part of their product
>>> announcement
>> 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 think this misses the point. In the case of the Jena reasoner, I, as a
> user of that reasoner, understand this reference to OWL/Lite more as a means
> for getting some coarse idea about the semantic expressivity of the Jena
> reasoner. Jena/OWL was never intended to be an *exact* implementation of
> OWL/Lite-Full, and that's pretty clear from the feature list (see the same
> document): For example, Jena supports class disjointness, and unionOf to
> some degree, two features which are not in OWL/Lite.
> 
> However, if a vendor is willing to implement OWL-R exactly, then such a
> statement as the above one about soundness but not guaranteed completeness
> is not at all useful: A simple RDFS implementation (or even less) will have
> the same properties.
> 
> So let's better drop this statement (as Peter proposed)! This doesn't change
> the situation from a technical pov, but as long as no one asks... ;-)
>  
>>> let alone the fact that they would not even have a clear name and
>>> standard to refer to. I regard that as a major problem.
>> I'm confused. It seems like there is.
> 
> I didn't get this argument either.
> 
> @Ivan, can you please elaborate on this?
> 
>> Cheers,
>> Bijan.
> 
> Cheers,
> Michael
> 
> --
> Dipl.-Inform. Michael Schneider
> FZI Forschungszentrum Informatik Karlsruhe
> Abtl. Information Process Engineering (IPE)
> Tel  : +49-721-9654-726
> Fax  : +49-721-9654-727
> Email: Michael.Schneider@fzi.de
> Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555
> 
> FZI Forschungszentrum Informatik an der Universität Karlsruhe
> Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
> Tel.: +49-721-9654-0, Fax: +49-721-9654-959
> Stiftung des bürgerlichen Rechts
> Az: 14-0563.1 Regierungspräsidium Karlsruhe
> Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
> Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
> 

-- 

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