Re: Anonymous resource names -versus- variables

Instead of associating semantics with URIs one could state it
explicitly:

	book1 --author--> var:....

would become

	book1        --author-->   whatever_URI
	whatever_URI --rdf:type--> rdf:Anonymous

Sergey

Dan Brickley wrote:
> 
> On Thu, 4 May 2000, Jan Wielemaker wrote:
> 
> > On Thu, 04 May 2000, Dave Reynolds wrote:
> > >Dan Brickley wrote:
> > >
> > >> My strawman suggestion is (a) that we adopt a convention of using URIs of
> > >> the form var:2342534647647476456456 for such situations, and (b) that such
> > >> identifiers are serving as named placeholders much like variables, and
> > >> that this analogy might be worth exploring further.
> > >
> > >One question is the scoping of such variables.
> > >
> > >If the binding is done purely within a single client than any convention would work (var:...
> > >anon:...  skolem:... etc).
> > >
> > >However, if you want the ability to later establish cross-application bindings to these anon ids
> > >(when some "real" uri is discovered) then more infrastructure is needed. It that case you may
> > >want to consider using CNRI handles  (http://www.handle.net/). These handles can be expressed in
> > >URI syntax (hdl:name-authority/foo) and the Handle system provides an infrastructure for
> > >dynamically resolving them into URLs (or indeed other handles or URIs). Thus if you assumed some
> > >name authority say "rdf.skolem" then you could label anonymous nodes
> > >"hdl:ref.skolem/1287987430984398743" using some presumed collision free digest or random number
> > >generator. These could be treated as arbitrary labels most of the time but a given application
> > >could check with the handle resolver whether a concrete binding to the anonymous label has been
> > >established.
> > >
> > >Having said all that I'm not convinced it's needed and simply have a labeling convention for
> > >anonymous resources sounds sufficient. Just thought it might be fun to point out the possible
> > >existence of a global variable binder!
> >
> > General collisions are already dealt with, just as they are for
> >
> >       <rdf:Description ID="foobar">
> >
> > expands to
> >
> >       <uri-of-document>#foobar
> >
> > My original problem was as simple as avoiding a clash if I write
> >
> >       <rdf:Description ID="Description__10">
> >
> > My parser does not validate whether its implicitly generated ids
> > conflict with explicit document ids.  This would make the parser
> > needlessly complex and force it to store the entire RDF document
> > before generating the result.
> >
> > As RDF documents are frequently generated too, such a collision cannot
> > be excluded.
> >
> > So, basically all I'm asking for is a statement like
> >
> >       "Local resource identifiers cannot start with an underscore,
> >        such identifiers are reserved for RDF processors"
> >
> > Even this would tell me from the triple notation that the ID is
> > implicit.
> 
> I don't think we can quite do this, as we'll want to scrape RDF models
> from all kinds of documents whose local identification conventions
> aren't policed by the RDF specs, eg. see various threads in the RDF IG
> archive on using XSLT for this,
> eg. http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103.html
> http://search.w3.org/Public/cgi-bin/query?mss=simple&pg=q&what=web&filter=all&fmt=.&q=%2Bwww-rdf-interest+%2BXSLT+
> 
> Instead, we can avoid clashes by not putting our generated placeholder
> IDs (for anonymously mentioned resources) into the URI space of the
> local document.
> 
> My proposal was for a "var:" URI scheme. Handles, DOIs, UUIDs or others
> would do equally well. The value I see in doing something like "var:" is
> it provides a lightweight way of tracking, for anyone encountering that
> RDF model (via any syntax, API, protocol - to partially answer
> Brian's point) that the var: identifier was assigned as a placeholder
> due to ignorance, and isn't considered to be a stable well-known Web
> identifier for that resource.
> 
> Dan

Received on Thursday, 4 May 2000 12:43:55 UTC