- From: Sandro Hawke <sandro@w3.org>
- Date: Mon, 30 Apr 2007 13:26:21 -0400
- To: kifer@cs.sunysb.edu (Michael Kifer)
- Cc: RIF <public-rif-wg@w3.org>
> > > If you use symbols from the sort iri then you have a global constant. If > > > you use constants from some other sort (e.g., string or we might introduc > e > > > a separate sort for that) then they are local names. > > > Where do you see a problem? > > > > > > Actually, I'm inclined to put this subject on hold until we're farther > > > > along with concrete examples of RIF usage. Once we have some working > > > > RIF examples, it should be easy enough to see what difference it makes > > > > to toggle some names between global and local. > > > > Just that -- what differences will users see? Imagine someone > > developing a ruleset, and for the sake or argument assume they are > > writing directly in RIF Core. Now, there are some situations in which > > they have to decide whether to use an IRI, a local name, or (perhaps) an > > existentially quantified variable. What factors should they take into > > account in making their decision? What possible impact might their > > decision have? > > > > Or, to approach that a little differently, give me two small example > > rulesets -- one which uses local names and one which use global names > > (IRIs) -- which are good examples of when one should use one vs the > > other. (A third one, with exivars in it, assuming we added them at the > > ruleset scope, might be good, too.) > > > > I guess use whatever syntax you like (if you want to get into this now). > > > > My sense is that one uses local names and exivars much like pronouns in > > natural language, but that doesn't fit with the claim that local names > > are rigid designators. > > A bNode is something like (an unknown) father of Mary: > > Exists ?F father(?F,Mary). > > A local name is used in a situation like the following. I may have a > database of all kinds of people with their relationships like brother, sister > , > parent, etc. I might want to export only the facts that tell the outsiders > whether someone is a relative of somebody else, but not the specifics. > So, then I could have these rules: > > "http://mysite.com/foo#relative"^^rif:iri(?X,?Y) :- parent(?X,?Y). > "http://mysite.com/foo#relative"^^rif:iri(?X,?Y) :- sibling(?X,?Y). > .... > "http://mysite.com/foo#relative"^^iri(?X,?Y) :- > "http://mysite.com/foo#relative"^^iri(?Y,?X). > ... > > For parent, sibling, etc., I chose local names. They are not iris and I > don't have to worry about their names being globally unique (or even unique > within my organization). I don't need to worry that in some language that > name might be an indecent or offensive word, etc. These names are simply > invisible outside of my program and I don't need to waste time on naming > these items. Let me paraphrase that to make sure I understand: - Using a global name involved one in external, social issues - So, unless there's some expected benefit from doing so (which outweighs the costs), just use local names. - So it's a complex, high-level, human-process decision. I think that makes sense. 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 } I believe the answer here is that it's harder to manage the "some rel/3 facts" -- and other things we might want to say involving parents and siblings -- in the existential approach. Is there some other difference? -- Sandro
Received on Monday, 30 April 2007 17:27:24 UTC