Re: Anonymous resource names -versus- variables

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 06:51:34 UTC