Re: local names

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

The above is syntactically incorrect, 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).

(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 rules
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).
					    


	--michael  


> 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 18:24:55 UTC