W3C home > Mailing lists > Public > public-rif-wg@w3.org > January 2006

[SWC] RDF and OWL compatibility

From: Chris Welty <cawelty@frontiernet.net>
Date: Tue, 10 Jan 2006 21:24:40 -0500
Message-ID: <43C46C68.1070009@frontiernet.net>
To: public-rif-wg@w3.org


Let's pick up this thread with the new taglines.

-Chris

Michael Kifer wrote:

>Francis McCabe <fgm@fla.fujitsu.com> wrote:
>  
>
>>Please forgive my lack of arcane logic ..
>>  but it seems to me that the use of gensym here:
>>
>>    
>>
>>>kb:works-with(Z,X) :- rdf:type(X,db:employee), gensym(Z).
>>>      
>>>
>
>You are right. The above has no logical meaning. Especially since David was
>appealing to such implementational concepts as "returns some freshly minted
>bNode on each call". (We shouldn't be reinventing Prolog -- there is already
>an ISO standard for it.)
>
>
>  
>
>>is not sound.
>>Presumably, what is really meant is:
>>
>>kb:works-with(Sy,X) :- rdf:type(X,db:employee)  where Sy is some  
>>gensym().
>>    
>>
>
>No, this is not going to model Enrico's use case correctly. This was the
>whole point of Enrico's message to which David was replying.
>
>See my response
>http://lists.w3.org/Archives/Public/public-rif-wg/2006Jan/0037.html
>for a correct representation. ("Correct" should be understood loosely -- in
>terms of getting satisfactory results for the given use case, not that
>Enrico's first-order representation has the same semantics as my
>representation that relies on default negation.)
>
>
>  
>
>>I.e., the skolemization should be done once and for all, not on each  
>>use of the rule.
>>
>>However, at the moment, I can't see why you would want to skolemize  
>>at all .. what is wrong with the rule with the universal quantifier  
>>in it?
>>    
>>
>
>Because he wanted to mimic an existential variable, which Enrico has in his
>use case.
>
>	--michael  
>
>
>  
>
>>Frank McCabe
>>
>>
>>
>>On Jan 9, 2006, at 9:50 AM, Dave Reynolds wrote:
>>
>>    
>>
>>>Enrico Franconi wrote:
>>>
>>>      
>>>
>>>>On 5 Jan 2006, at 15:51, Dave Reynolds wrote:
>>>>        
>>>>
>>>>>On the question of bNodes in the head, I hear the argument that  
>>>>>it  is not sufficient to just treat these as new Skolem constants  
>>>>>but  my intuitive understanding of the issue is too weak. It  
>>>>>would be  really helpful if someone could construct a test case  
>>>>>which  demonstrates the difference in results that arise between  
>>>>>correct  treatment of bNodes in the head versus treatment as  
>>>>>Skolem  constants. In the concrete cases I've seen where bNodes  
>>>>>are used in  the head of rules they seem to be intended as a form  
>>>>>of anonymous  gensym - so the Skolem constant semantics may be  
>>>>>the more  practically useful interpretation.
>>>>>          
>>>>>
>>>>A a naive gensym would fail the use case  <http://www.w3.org/2005/  
>>>>rules/wg/wiki/Managing_incomplete_information>, where two  
>>>>examples  (in section "9.4. (Rules involving generation of  
>>>>unknown)") show how  you can make things wrong with a naive use of  
>>>>skolem constants to  implement the existential variables in the head.
>>>>        
>>>>
>>>Sorry to be slow on the uptake but I didn't follow why the examples  
>>>break with naive gensym.
>>>
>>>The example in 9.4 on that page shows the rules:
>>>
>>>[[[
>>>      rdf:type(X,db:employee) :- kb:works-with(X,Y).
>>>      kb:works-with(Z,X) :- rdf:type(X,db:employee).
>>>]]]
>>>
>>>A naive implementation of bNodes-by-gensym would rewrite the unsafe  
>>>second rule to something like:
>>>
>>>      kb:works-with(Z,X) :- rdf:type(X,db:employee), gensym(Z).
>>>
>>>where "gensym/1" returns some freshly minted bNode on each call;
>>>
>>>or, better,
>>>
>>>      kb:works-with(Z,X) :- rdf:type(X,db:employee), gensym(X, Z).
>>>
>>>where "gensym/2" binds Z to some bNode which is a (skolem-)function  
>>>of X.
>>>
>>>As far as I can see either of these would return the same answer as  
>>>the classical semantics for both of your test cases 9.4.1 and 9.4.2.
>>>
>>>Dave
>>>
>>>
>>>      
>>>
>>
>>    
>>
>
>
>
>
>
>  
>
Received on Wednesday, 11 January 2006 02:24:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:26 GMT