Re: ISSUE: OWL-DL compatibility

Unless anyone else has an opinion, Jos are you willing to make that change?

On a different but related note, Ian Horrocks posted a public comment that the 
new terminology for that-formerly-known-as-OWL-DL is "OWL Direct Semantics", and 
for that-formerly-known-as-OWL-Full is "OWL RDF-based Semantics" (see 
[http://lists.w3.org/Archives/Public/public-rif-comments/2009Nov/0001.html])

I think a quick fix would be to replace "OWL Full" with "OWL RDF-based 
Semantics" and replace "OWL-DL" with "OWL Direct Semantics".  This isn't 
precisely correct in general, but I think based on the way we use the difference 
(between OWL Full and OWL DL), it works.

This doesn't change anything fundamental so its clearly just a bug fix, if you 
are willing to make the change.  Are you?

-Chris


Michael Kifer wrote:
> Yes, I agree that 3a is a reasonable fix. 3b is too big of a change, and I was
> not suggesting it for this round.
> 
> michael
> 
> 
> On Tue, 10 Nov 2009 10:53:32 -0500
> Chris Welty <cawelty@gmail.com> wrote:
> 
>> I read this a little more carefully.
>>
>> Basically, the issue is whether to add some correspondence between rif:subclass 
>> and rdf:subclass and between rif:type and rdf:type *in the OWL compatibility 
>> section* of SWC.  Such a correspondence is already there for RDF compatibility, 
>> but Michael noted that it is not "inherited" by the "OWL-DL" (now know as OWL 
>> Direct Semantics) section.  So, currently in SWC, the OWL-DL compatibility has 
>> no correspondence between the rather obvious type/subclass relations in the two 
>> languages.
>>
>> I agree this is a problem and should be fixed, and option #1 in Michael's 
>> analysis, copied below (to leave it as is) is unacceptable.
>>
>> Option #2 is to just add a sentence to the text saying there is no 
>> correspondence between owl and rif type/subclass.  This is less than satisfactory.
>>
>> Option #3 is to "fix" it somehow, and there are two variations there, I'll call 
>> them 3a (just repeat the correspondences from RDFS in OWL-DL) and 3b (do the 
>> best possible job mapping between owl and rif subclass).
>>
>> </chair>I prefer option 3a.  I agree with Jos' analysis of option 3b and think 
>> it is too big a change.<chair>
>>
>> As chair, I am also willing to accept 2 or 3a as an oversight and bug fix (I 
>> personally thought the correspondence between type and subclass were "inherited" 
>> from the RDF correspondence, so 3a would just make it the way I thought it was), 
>> however 3b seems to me, procedurally, to be much more significant and requires a 
>> new last call for SWC.
>>
>> -Chris
>>
>> Jos de Bruijn wrote:
>>>> In today's telecon I was asked to reanimate the issue of OWL compatibility,
>>>> which was discussed 1 month ago.
>>>>
>>>> Here is the relevant message:
>>>>
>>>> http://lists.w3.org/Archives/Public/public-rif-wg/2009Sep/0017.html
>>>>
>>>> The current situation is a bug, IMO. If it isn't a bug then at least that part
>>>> of the document is very unsatisfactory and obscure. Jos proposed 3 solutions:
>>>>
>>>> 1- leave things as they are, assuming that # and ## are not of interest
>>>>    to users of RIF-OWL DL combinations
>>>> 2- explain the use of # and ## in the document (this would certainly not
>>>>    be a substantive change, so we should not run into procedural problems)
>>>> 3- define the semantics of # and ## in RIF-OWL DL combinations in a
>>>>    similar fashion as in RIF-RDF combinations: a one-to-one correspondence
>>>>    between # and OWL class membership statements and implication between ##
>>>>    and OWL subclassing.
>>>>
>>>> The easiest for him would be to do nothing (1), thus leaving things
>>>> unsatisfactory and obscure. His next choice is (3), which is also my choice and
>>>> the "right thing to do."  (3) stretches things a little, but it can be argued
>>>> that it is a simple fix.
>>> In my earlier e-mail to Michael referred to I did not say what my
>>> preference is among the mentioned options.  I guess arguments can be
>>> made for all three options, so in fact I do not have a strong
>>> preference, but I do have a concern about option (3): implementation
>>> might be harder.  If, for example, implementation is done through
>>> embedding in other rules system, like the embedding of RIF-OWL2RL
>>> combination in the appendix of the document, quite a few rules need to
>>> be added for the ## construct.
>>> In particular, for every pair of distinct class names (A,B), we need to
>>> add the rule:
>>>
>>> Forall ?x (?x[rdf:type -> B] :- And(?x[rdf:type -> A] A##B))
>>>
>>> This means adding a quadratic number of rules.
>>>
>>> Dealing with # is easy: in the mapping of RIF DL-document formulas to
>>> RIF documents [1] we simply map a#b to tr'(b)(a). Clearly, we would
>>> restrict b in formulas a#b to constant symbols.
>>>
>>>
>>> [1]
>>> http://www.w3.org/TR/rif-rdf-owl/#Embedding_RIF_DL-document_formulas_into_RIF_BLD
>>>
>>>
>>>> Solution (2) is more work. It fixes the obscurity aspect, not the
>>>> unsatisfactory aspect of the definitions. So, (3) seems like the best way to
>>>> proceed.
>>>>
>>>> Solution (3) still leaves some problems, which are unrelated to the above
>>>> issues. In the current semantics, subclassing in RIF implies subclassing in
>>>> OWL/RDF, but not vice versa.
>>>>
>>>> In this regard, I would like to point to my follow-up message
>>>> http://lists.w3.org/Archives/Public/public-rif-wg/2009Sep/0019.html
>>>> Here I proposed a stronger semantics, which fixes this non-entailment problem.
>>> Michael proposed the following semantics:
>>>
>>> {(A,B) | A rdfs:subclassOf B and A != B on the RDF side}
>>>                 = {(A,B) | A##B on the RIF side}
>>>
>>> I feel that this would take us out of Horn, even when considering Simple
>>> entailment, because implementation would require (classical) negation.
>>> At least, that is the only way I current see how this could be
>>> implemented. As we know, classical negation in the body amounts to
>>> disjunction in the head, so we would end up adding the following rule to
>>> the embedding of RDF-RDF combinations:
>>>
>>> Forall ?x, ?y (Or(?x##?y ?x=?y) :- ?x[rdfs:subClassOf -> ?y])
>>>
>>> For RIF-OWL DL combinations such a semantics is even more problematic,
>>> because subclass in OWL DL means subset relation between class
>>> extensions, so the condition would look something like (X^C is the class
>>> extension of X):
>>>
>>> {(A,B) | A^C subset B^C and A^C != B^C on the RDF side}
>>>                 = {(A,B) | A##B on the RIF side}
>>>
>>> (Actually, we will need to apply some tricks here, since A and B are not
>>> constants on the OWL side, but I guess we can come up with a definition
>>> that kind-of achieves this semantics)
>>>
>>> A formula implementing the => direction of the condition for a pair of
>>> class names A,B would look something like (again, negation in the body
>>> becomes disjunction in the head):
>>>
>>> Forall ?x (
>>>   Or(A##B
>>>      And(Forall ?x(?x[rdf:type -> B] :- ?x[rdf:type -> A])
>>>          Forall ?x(?x[rdf:type -> A] :- ?x[rdf:type -> B])))
>>>   :-
>>>   Forall ?x(?x[rdf:type -> B] :- ?x[rdf:type -> A]))
>>>
>>>
>>> So, I would not be in favor of extending either the semantics of RDF or
>>> the semantics of OWL DL combinations with such a condition.
>>>
>>>
>>> Best, Jos
>>>> This would certainly be a substantive change semantically (although not
>>>> significant textually). If we don't have the energy to do it this time,
>>>> maybe for RIF 1.1.
>>>>
>>>> michael
>>>>
> 

-- 
Dr. Christopher A. Welty                    IBM Watson Research Center
+1.914.784.7055                             19 Skyline Dr.
cawelty@gmail.com                           Hawthorne, NY 10532
http://www.research.ibm.com/people/w/welty

Received on Tuesday, 10 November 2009 22:59:36 UTC