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