W3C home > Mailing lists > Public > www-rdf-interest@w3.org > December 1999

Re: Resources and URIs

From: Gabe Beged-Dov <begeddov@jfinity.com>
Date: Tue, 07 Dec 1999 18:58:06 -0800
Message-ID: <384DC93D.2506A92C@jfinity.com>
To: Sergey Melnik <melnik@DB.Stanford.EDU>
CC: Dan Brickley <danbri@w3.org>, RDF Interest Group <www-rdf-interest@w3.org>
Sergey Melnik wrote:

> > My inclination is to run the other way and make sure that these URIs are
> > evident as generated IDs, so that processors can always tell when the URI
> > was cooked up by some parser instead of being widely agreed.
> This is in fact not the *other* way, but just the half of the way. Using
> Gabe's proposal we could generate a URI like
> urn:rdf:noname:XYZ        (where XYZ is again based on a digest)

IMO, the  resources  (and triples) that are embedded in a particular model should be
labeled using fragment identifiers rather than standalone URI. They should be
"relative" resources  (as in not absolute).  If we can figure out a workable content
based algorithm then this could be the ID for these relative resources.

The fragment scheme for rdf would support two types of fragment identifiers for
resources, those that are explicitly named using rdf:ID and those that are generated.
The explicitly named embedded resources would have a fragment prefix of
"rdfpointer:id:" and the anonymous ones would have a fragment prefix of
"rdfpointer:anon:". You could then have something like:

 - urn:rdf:model:34d...29                for Sergey's homepage

 - urn:rdf:model:34d...29#rdfpointer:anon:XYZ           for his vcard voice resource
(where "XYZ" is the content based ID).

 - urn:rdf:model:34d...29#rdfpointer:id:Voice            if the vcard resource had
been labeled with rdf:ID="Voice".

If you wanted to deal with all the ambiguities of using XPointer (arbitrary ranges,
binding to a particular XML serialization, etc...) for your fragment identifier you
could certainly do that and have something like:

- urn:rdf:model:34d...29#xpointer(id("Voice"))

One thing that this points out is the ability to have more than one way to access
and/or label a resource  independant of whether it is standalone or embedded.  The
trick is to include the metadata needed to interpret the label as part of the label.
This is one of the strengths of URI. Why can't we use that strength to encode all the
necessary information in the URI for the model, triples and resources?  You could then
see the current syntax as a shorthand for the fully-qualified syntax that we come up
with in the same way that "somexmldoc#id("foo")" is shorthand for
"somexmldoc#xpointer(id("foo"))" and "http://www" is shorthand for
"URI:URL:http://www" (at least conceptually).

These "relative" resources would perhaps even maintain their relativity until they are
explicitly used in context other then their containing model or until the model had
been closed. If you invoked toString on them, they would print out a fragment URI.
This  stringifiedURI would be the one used to calculate the signature which would deal
with the  cyclic dependency if the resource (and triple) URI wanted to incorporate the
URI of the model which hadn't been generated yet.

Cordially from Corvallis,

Gabe Beged-Dov
Received on Tuesday, 7 December 1999 22:13:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:21 UTC