Re: RDF and OWL compatibility

Francis McCabe <fgm@fla.fujitsu.com>:
>
> Michael:
>   I see the point.
>   Note, however, that in:
> 
> has_address(?Person,_#(?Person)) :-
> 	    traveller(?Person),
> 	    not exists ?A has_known_address(?Person,?A).
> 
> the function symbol _# is a well-known (dating at least back to Alan  
> Robinson) way of dealing with existential variables.
> 
> Frank

What is well known?  Skolemization or the actual symbol _#?
Of course, Skolemization has been known for decades. As to the symbol
itself, it is no big deal -- just a symbol.

My point was that this is all a matter of modeling to a large degree.
Correct modeling of the subtleties like existentials using LP-style rules
requires some thought, but this kind of problems (requiring the user to
think :-) are common to all logic-based languages. Some things are very
hard but expressible in DL, some in SQL, some in LP. The sets of those
things that are hard are different for different formalisms.
However, it is often possible to make hard things easier to express with
good syntactic sugar. Examples include Lloyd-Topor, F-logic, HiLog,
priorities on rules, etc.


	--michael  


> On Jan 10, 2006, at 1:03 PM, 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 00:47:08 UTC