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

On 17 Jul 2008, at 10:56, Ivan Herman wrote:
[snip]
> 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

This is wrong. There's no reason why a tableau algorithm per se  
couldn't handle this or, indeed, any algorithm (esp. if we are  
allowed to be a bit weird about it).

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

Yes there is. The algorithm for the current OWL-R includes checking  
that a graph is legal. We only provide certain promises based on the  
action of the rules *on a set of wffs* (i.e., graphs). Applying some  
rules on other graphs is definitely an extension.

You may not want it to be, but at the moment it is :)

> (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,

Uhm, those seem like random praise terms. I think we think that they  
will be sound but incomplete.

> 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.
[snip]

Not at all. First, we don't say that implementations need to reject  
*anything*. But there's a great deal of value in being clear to the  
user when they are going beyond OWL-R (if only for interop reasons).

Here's why. Consider the case where you've used a constructor of OWL- 
R in a forbidden way (say an existential in the head of a rule).  
Presumably, running the rules will just be silent there. But this  
will trigger certain entailments from e.g., an OWL DL reasoner.    
This seems very confusing to me. I'll have *lots* of graphs with  
*radically* different, easily triggered, differences in meaning,  
which are not tied to the *presence* of vocabulary but to the  
*patterns* of vocabulary use.

This seems like a user nightmare to me.

Note that this hits people who extend OWL-R in a "ruley" way as well  
because there'll be nothing to indicate that they are doing more or  
how much more or extract what, where, how.

You can *sorta* get away with this in RDF, RDFS land, but even there,  
I think people expect using subclass of to do something.

So, this really seems only to be a benefit, if that, to implementors.  
I think it's much healthier from a marketing and user persepective to  
make OWL-R extremely clear and detectable and let implementors do  
more. It's pretty clear that some will do the minimum more (i.e.,  
just handle the additional graphs with the same rules). But some will  
do even more. I think we want to encourage that.

We can probably separate two cases: The builtin vocabulary and  
extended use of logical vocabulary. I think we should default to *no*  
graphs outside the current OWL-R until a coherent proposal which  
separates out these cases and makes clear what implementations should  
do or expect is given.

IOW, there may be graphs that are harmless and unconfusing (though  
still a pita if you ever migrate to owl dl) but there are clearly  
graphs that *are* confusing with silent semantics. Wretchedly so, in  
fact.

> 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.
[snip]

This isn't clear to me at all, since I don't think the extended  
handling *is* correct or necessarily worth while. You've given a case  
where it seems ok; I think I've given a case where it isn't.  
Implementations that blindly apply to rules to arbitrary graphs are,  
in my opinion, not serving their users well. Plus, it makes extending  
OWL-R to cover more of the *semantics* of those graphs harder, plus  
complicates the profile picture in OWL.

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

I think as a standards body, we have more impetus to clear labeling  
for the user/

> 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 pointed out already that HP does exactly that.

> (I would come up with a name, some sort of characterization of what  
> it does, etc).

And that's up to the marketers to do. HP went with "incomplete but  
useful" which stemmed from how the webont cr report read, if I'm not  
mimstaken.

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

We need to establish what helping messaging and interoperability *is*  
in this case. I feel that the unification proposal does a better job;  
you don't. So we need to figure out what evidence will help us figure  
out who's more right. (I don't think there is a clear, unchallangable  
"right" here, but many factors to be weighed. At the moment, we don't  
even seem to agree on some basic technical facts :()

Cheers,
Bijan.

Received on Thursday, 17 July 2008 11:03:55 UTC