Re: local names

> 
> > > 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.

Not really. You had an existential in the head, but the variable was in the
body. This is the same as having universal quantification in the body. It
is a completely different beast. When people say head-existentials they
mean variables that are existentially quantified and occur *only* in the head.
bNodes are like that, not like in your example.

> > 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.....

No, this is exactly what you wrote. (At least, as far as I could understand
your syntax: I was trying to unpack your syntax into something conventional.)


> > (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?

?X^^rif:iri is a sorted variable. It can be bound only to terms of the
given sort. (Well, informally. The formal definition is that they can take
values only from the domain of that sort.) These variables are in the
current WD1.


	--michael  


>        -- Sandro
>

Received on Monday, 30 April 2007 22:14:13 UTC