Re: bNodes as local constants

> 
> > > I was not one of the big proponents of local names in the RIF, but I
> > > believe that the proponents (MichaelK, Hassan) share my definition, i.e.
> > > local names are not existentially quantified variables, but rigid constants
> 
> > Yes, local names have nothing to do with bNodes.
> > bNodes have logical meaning. Local names is just a twist to the naming schema
> 
> Can you give me one or more example that show this?  Like, if I were
> writing a translator from RIF Core to some FOL, how would I translate
> local names, and IRIs, and how would merging work?

I am not sure what kind of examples you are looking for.
A bNode is Exists X p(...X...). RDF has a special notation for this.

A local name is just an artifact of the naming scheme.
Global names have the form of a uri and local names do not.
They might have the form like 'foobar' or '123   %$# xyz'.


> > > (1) This would be a possible way to go, yes.
> > > (2) Another possibility would be to allow existentially quantified
> > > variables in facts which come from RDF triples, and show that
> > > skolemization can be used for reasoning.
> > > (3) Finally, we could combine the two in a more modular way.  We could
> > > define the combination of an RDF graph S with a set of rif rules P as a
> > > tuple (S,P), and define a notion of combined interpretations, similar to
> > > what is done in DL-log [1].
> > > 
> > > I think I would prefer the second option.   Compared to the first
> > > option, it has the advantage that the embedding is closer to the actual
> > > semantics of RDF.  Compared to the third option, it has the advantage
> > > that (I think) it will be easier to understand, and you can more easily
> > > be reused in extensions with nonmonotonicity and extensions towards
> > > production rules.
> > 
> > The second option is problematic. If we allow existential vars in the
> > facts, then we have to revise the whole theory of rules starting with
> > Horn. Every dialect will then need to be able to support existential facts,
> > so it means that we will possibly need to revisit stable, well-founded,
> > etc. semantics. These are possibly worthy things, but this group is not
> > chartered with doing original research. Worse, if we do it wrong the first
> > time and it becomes a W3C recommendation then future generations won't
> > forgive us :-)
> > 
> > I think option (3) is a safer way to go.
> 
> It seems to me like option (1) is the safe/cheap route, since it doesn't
> burden RIF implementors with RDF details.  Doesn't (3) mean that every
> RIF Core implementation has to implement RDF semantics -- ie bNodes?

At the implementation level these will be the same things as long as you
stick to querying. Option 3 is just a better foundation for future
extensions that dialects might want to have (e.g., a first-order dialect).


	--michael  

> 
>     - Sandro
>

Received on Sunday, 29 April 2007 20:16:36 UTC