- 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