W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2002

Re: bNodes wanted

From: Dan Brickley <danbri@w3.org>
Date: Sat, 25 May 2002 13:38:39 -0400 (EDT)
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
cc: <sandro@w3.org>, <www-rdf-interest@w3.org>
Message-ID: <Pine.LNX.4.30.0205251330440.23212-100000@tux.w3.org>
On Sat, 25 May 2002, Peter F. Patel-Schneider wrote:

> From: Dan Brickley <danbri@w3.org>
> Subject: Re: bNodes wanted
> Date: Sat, 25 May 2002 06:09:29 -0400 (EDT)
>
> > On Fri, 24 May 2002, Peter F. Patel-Schneider wrote:
> >
> > > > It seems like the question is whether I can properly generate a Skolem
> > > > constant.  There are several ways to generate URIs that no one else
> > > > will ever generate; you can pick one that meets your needs:
> > > >
> > > >     - the tag: URI algorithm for human-readable ones [1]
> > > >     - the UUID algorithm for easy machine generation
> > > >     - a cryptographicaly secure random number if you're
> > > >       seriously concerned about duplicate generation
> > > >       (such as by malicious 3rd parties)
> > >
> > > None of these work.  As soon as any other agent sees the skolem URIrefs
> > > then it can use the URIrefs, resulting in them possibly being used in other
> > > doucuments.
> >
> > Hey we agree on something :) Absolutely right.
> >
> >
> > > > If you also want to make sure no one can use it after the fact, then
> > > > you certainly need bNodes.  But I don't know why you'd want that.  Use
> > > > cases?
> > >
> > > Lets see:
> > >
> > > 1/ containers that cannot be added to by other parties
> > > 2/ resources that cannot be referred to by name, only in terms of their
> > > relationships to other resources
> >
> > I guess for 1/, you'd need to be careful not to describe your container
> > with enough information (such as a daml:UnambiguousProperty, in the
> > simplest case) to allow others to easily say things about it afterwards.
> > I'm not sure that's always achievable. You might have some container and
> > not want anyone to talk about it afterwards; yet others might start
> > describing it (in RDF+WebOnt/etc) as 'the rdf:Seq that Peter mentioned in
> > his message of 2002-05-25'. I don't think this can be avoided. Instead,
> > we'd want strategies to avoid believing things claimed in such a matter,
> > perhaps?
>
> Well, RDF has no mechanisms for creating statements in one RDF graph use a bnode
> from another RDF, so even being able to talk about the container, does not
> allow one to, for example, add new elements to it.

I was careful to say RDF+WebOnt/etc this time, to avoid our disagreement
there.

We're not, as I said to Aaron, talking about the second document _using_
or _describing_ a bNode in the graph from the first document. The concern
is with a second document further describing the thing-that-the-bNode-denotes.
In this case the container that the bNode denotes. My
understanding is that WebOnt provides facilities (like unambig-property)
that make such descriptions possible, based on reference-by-description.
This is easiest if the first document ascribes lots of unambiguous
properties to the container-denoting-bNode. But mighht be possible through
other tricks. That-seq-container-mentioned-in-doc-xyz, or subtler
variants on this theme.

One reaction to this might be "well, RDF shouldn't put so much abstract
syntax in the domain of discourse, then"...

Dan
Received on Saturday, 25 May 2002 13:38:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:54 GMT