- From: Sergey Melnik <melnik@db.stanford.edu>
- Date: Thu, 04 May 2000 09:54:29 -0700
- To: Dan Brickley <danbri@w3.org>
- CC: Jan Wielemaker <jan@swi.psy.uva.nl>, Dave Reynolds <der@hplb.hpl.hp.com>, www-rdf-interest@w3.org
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