- 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