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

Bijan (et al),

I do not think we should get into details on whether a tableau algorithm
can have some extra heuristics or not. Let us concentrate on what, at 
least in my opinion, is the central issues from our mails. Ie, lots of 
skips below, I hope it is o.k.:-)

Bijan Parsia wrote:
[SKIP]
> 
 >
> 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.t.w., what I meant by extension at that point was whether _other_
rules were used than the ones defined by the standard.

However. Such details put aside, we seem to agree that for an 
implementation to accept and handle the graph G that I described, it 
should actually be the implementation of an extension to the standard 
(in the new setup, that is). That is what I tried to say myself, so we 
do agree on that.

Put it another way: we have in our current Profile document 4 standard 
components that one can refer to; if we accept Boris' proposal this is 
reduced to three but, through this reduction, we do 'loose' (in contrast 
to what the original claim was when the issue was raised) standard 
functionality. In other words, this proposal is not only an editorial 
change but a major functional change.

[SKIP]
> 
> 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. [skip] At the moment, we don't 
> even seem to agree on some basic technical facts :()

Actually, I do not think we disagree on the basic technical facts but
only on details, although I would not dare going into any discussion
with you on the details of a tableau:-). But yes, we seem to disagree on
the appreciation of the changes induced by Boris' proposal...

The OWL-R Full component is well defined as a _standard_ set of rules
that can be applied on RDF graphs. Yes, it can go wrong in some cases,
yes, it is a partial OWL-Full implementation. As it is today, its close 
relationship to DLP (well, OWL-R-DL) is a great thing: in some cases 
applications using OWL-R-Full might move easily towards more complex DLs 
if they wish to, ie, it is an easy first step in that direction. But it 
is, at the same time, a perfectly appropriate user and implementation 
platform for a community that may not wish to do so, that only knows and 
uses RDF.

I must admit none of the reasons put forward by Boris are compelling 
enough for me to loose that.

(To make it clear: if it makes things cleaner, I do not mind renaming
things, calling EL++, DL-Lite and OWL-R-DL profiles and OWL-R-Full
something else... that is not the issue. I agree that OWL-R-Full is
_different_ than the other three. What I object to is its removal as a
separate entity.)

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

We may decide to leave things as they are, put an editor's note into the 
  document about the possible change and publish a new Working Draft 
with that additional note, asking for explicit feedback from the 
community. That is what the public review process is made for...

Ivan

B.t.w, there seems to be a side issue of Boris' proposal that affects
implementations, too. If I want to be really compliant OWL-R in the
proposed new approach, I am supposed to implement the check, just as you
describe above. While I could (and I did) implement OWL-R-Full easily
and quickly on top of an existing RDF environment, doing the backward
mapping to functional syntax and check the result against OWL-R-DL is a
non-trivial extra work on implementers...


-- 

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