W3C home > Mailing lists > Public > public-rif-wg@w3.org > April 2007

Re: local names

From: Sandro Hawke <sandro@w3.org>
Date: Mon, 30 Apr 2007 15:00:20 -0400
To: kifer@cs.sunysb.edu (Michael Kifer)
Cc: RIF <public-rif-wg@w3.org>
Message-Id: <20070430190117.0C9C34EFFF@homer.w3.org>


> > Now what about existial variables vs local
> > names?   In your example, the local name is a predicate name, which
> > complicates the analogy somewhat.    Let's imagine it was being modeled
> > instead like (using Qnames to name the IRI madness):
> > 
> >  my:relative(?X,?Y) :- rel(parent,?X,?Y).
> >  my:relative(?X,?Y) :- rel(sibling,?X,?Y).
> >  ... some rel/3 facts ...
> > 
> > Now, if my language supported arbitrary existential quantification, how
> > would I decide when to do that, instead of:
> > 
> > exists ?Parent, ?Sibling {
> >   my:relative(?X,?Y) :- rel(?Parent,?X,?Y).
> >   my:relative(?X,?Y) :- rel(?Sibling,?X,?Y).
> >   ... some rel/3 facts
> > }
> 
> The above is syntactically incorrect

Sure, according to the current version of RIF Core.  But I'm not talking
about that language, I'm talking about Option 2 -- a hypothetical
different language which allows arbitrarily scoped existential
quantification, subsuming the functionality of b-nodes.  The example I'm
giving here is, in style, similar to a typical b-node usage.  Sorry that
I wasn't more clear that I was talking about a language feature not
currently in RIF Core.

> and is furthermore an example of
> incorrect modeling.
> 
> A syntactically correct version would be
> 
> my:relative(?X,?Y) :- exists ?Parent  rel(?Parent,?X,?Y).
> my:relative(?X,?Y) :- exists ?Sibling rel(?Sibling,?X,?Y).

Which is, of course, totally different from what I wrote.   Given that
misunderstanding of my message, it's hard to understand how to reply to
your message.....

> (It makes a big difference whether you put an existential inside or outside.)
> 
> First, the above 2 rules are absolutely identical from the logical point of
> view. Second, since you model everything with triples then you also
> probably have
>     rel(supplier,...)
>     rel(product,...)
>     rel(address,....)
> and stuff like that. So, you get relatives, suppliers, and other junk.
> 
> The case for constants is just the same. One uses them as auxiliary things
> in an algorithm or specification.
> For instance, I might need that everyone has a parent in my KB.
> Of course, this is not practically possible, so  I can introduce a local
> constant, named, Eve, and then have
> 
> parent(Eve,"http://foo.com/mydb#JoeBlow"^^iri).
>
> for every person whose parent is not known. One might need to adjust the rule
> s
> to avoid returning local names as answers. 

...

> For instance, by adding sorts to
> variables:
> 
> "http://mysite.com/foo#relative"^^rif:iri(?X^^rif:iri,?Y^^rif:iri) :-
>     	    	    	    	    	    parent(?X^^rif:iri,?Y^^rif:iri).
> "http://mysite.com/foo#relative"^^rif:iri(?X^^rif:iri,?Y^^rif:iri) :-
>     	    	    	    	    	    sibling(?X^^rif:iri,?Y^^rif:iri).

I'm really surprised to see sorts used this way.  I can't put my finger
on it, but it seems like they're crossing a syntactic/semantic boundary
here.   This term "?X^^rif:iri" is a variable which can be bound only to
things for which there exists a name which is an IRI?

       -- Sandro
Received on Monday, 30 April 2007 19:01:28 GMT

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