Re: Best practices using URIs

On Mon, 3 Nov 2003, Butler, Mark wrote:

> However I am not clear on the best approach to use for surrogates or
> metadata objects. For example when we transform the Artstor data to
> RDF/XML from XML, we use URIs that look like URLs for both these
> situations e.g.

In the past there has been much debate on this issue over the rdf-interest
email list of the w3c.  There were two sides on the debate, where one side
said that using http URIs for real world objects was desirable while the
other side found it unacceptible.  I'm not sure what the current consensus
is, but it seem to me that one can make no assumptions about what a uri
starting with 'http://' means. Personally, I prefer the strategy of using
random numbers for any item (either metadata or surrogate objects) that
cannot be given a canonical URI by a centralize authority.  Nonetheless,
any URI beginning with 'http://web.mit.edu/simile...' is ours to do with
as we please.

> identifying a metadata object:
> <http://web.mit.edu/simile/metadata/artstor/mediafile#3-41822000125995.jpg>
>       a       art:MediaFile ;

What is this item?  If it is indeed a file in the JPEG format, than I
would suggest using an MD5-hash of the file as as URN.  If it is a record
relating to a jpeg file, than I would suggest it be given some URN
that might be stable. That is, if the XML->RDF transform were run a second
time, it would be nice for the same URI to be given to the same entity,
even if extraneous parts of the XML were modified.

As for surrogate objects, that is a can of worms.  However, I think the
same principles apply as before.  When 'minting' new URIs, _my opinion_
is that the following principles should be upheld:

1. Every effort must be taken to prevent new URIs from clashing with
   existing ones, regardless of who minted them.

2. New URIs should be choosen such that repeatedly assigning a URI to the
   same entity will result in the same URI, unless this conflicts with
   rule 1.

3. Items that are not network-retrievable, such as people, should not be
   given URLs, provided this doesn't conflict with rules 1 & 2.

Nick

Received on Monday, 10 November 2003 13:45:25 UTC