- From: Seaborne, Andy <Andy_Seaborne@hplb.hpl.hp.com>
- Date: Wed, 12 Nov 2003 17:25:04 -0000
- To: "'Nick Matsakis'" <matsakis@mit.edu>, "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>
- Cc: SIMILE public list <www-rdf-dspace@w3.org>
-------- Original Message -------- > From: Nick Matsakis <mailto:matsakis@mit.edu> > Date: 10 November 2003 18:46 > ... Good principles. > > 1. Every effort must be taken to prevent new URIs from clashing with > existing ones, regardless of who minted them. +1 > > 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. Need to be a bit careful here - a case of emphasising the last sentenance and saying that the same URI should not be used unless the process is absolutely sure it is the same thing. This should say something like allocate the same URI where possible if the same process is run in the same situation. Someone somewhere else should allocate different URIs by default unless it is strongly known to be the same - this is the significance of the naming authority in hierarchical schemes. Getting this wrong, and allocating the same URI to different things is disasterous - an association that two names refer to the same thing can be done later. A sort of zeroth principle (a reminder to us all) is that we can have multiple names for the same thing. > > 3. Items that are not network-retrievable, such as people, should not be > given URLs, provided this doesn't conflict with rules 1 & 2. I would go further on 3 and advocate issuing URNs from the UUID scheme - unresolvable but now there is the possibility of passing them around and talk about the same concept. Where possible, there should be a retrievable representation (i.e. don't over use URNs). > > Nick Andy urn:uuid:3cf57e30-278a-11b2-8000-dac8fc3cc968
Received on Wednesday, 12 November 2003 12:36:10 UTC