- From: Hammond, Tony (ELSLON) <T.Hammond@elsevier.com>
- Date: Tue, 11 Nov 2003 09:45:33 -0000
- To: 'Nick Matsakis' <matsakis@mit.edu>, "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>
- Cc: SIMILE public list <www-rdf-dspace@w3.org>
Hi: Not sure how appropriate (or relevant) this is to SIMILE, but thought I would just mention the "info" URI scheme: http://www.ietf.org/internet-drafts/draft-vandesompel-info-uri-00.txt #### Internet-Draft Herbert Document: draft-vandesompel-info-uri-00.txt Van de Sompel Expires: March 2004 Los Alamos National Laboratory Tony Hammond Elsevier Eamonn Neylon Manifest Solutions Stuart L. Weibel OCLC Online Computer Library Center September 2003 The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces #### This is currently being revised specifically to exclude dereference, and to include general hierarchy. From the FAQ we're also preparing: * Why create the INFO URI scheme? The INFO URI scheme has been developed from within the library and publishing communities to expedite the referencing by URIs of information assets that have identifiers in public namespaces but have no representation within the URI allocation. * What are the key properties of INFO URIs? INFO URIs are not dereferenceable. Moreover, INFO URIs are designed to be simple to deploy, both in terms of namespace registration and in the minting and general usage of these identifiers. These simplifications are fully in line with the INFO URI remit of providing a halfway house for recognition of legacy information assets under the URI allocation. As I said, I don't know if this is of any interest, but thought I should take the opportunity to at least point it out. Regards, Tony Tony Hammond Advanced Technology Group, Elsevier 32 Jamestown Road, London NW1 7BY, UK <tel:+44-20-7424-4445> <mailto:t.hammond@elsevier.com> -----Original Message----- From: Nick Matsakis [mailto:matsakis@mit.edu] Sent: 10 November 2003 18:46 To: Butler, Mark Cc: SIMILE public list Subject: 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 Tuesday, 11 November 2003 05:46:12 UTC