- From: Seaborne, Andy <Andy_Seaborne@hplb.hpl.hp.com>
- Date: Fri, 23 Jan 2004 18:01:34 -0000
- To: "'karger@theory.lcs.mit.edu'" <karger@theory.lcs.mit.edu>
- Cc: www-rdf-dspace@w3.org
-------- Original Message -------- > From: David R. Karger <mailto:karger@theory.lcs.mit.edu> > Date: 22 January 2004 23:13 > . . . . > > > Identifiers: section 3.2 > ======================== > > It would be valuable to decide on the SIMILE policy for naming things > (including the allocation of URIs) outside of the History Store work > as well so that a common policy applies throughout the system. > > > Allocating URIs > --------------- > > The history system has to work with URIs external to the history > system and also to allocate URIs for information it creates. It > will have to cope with external resources in any (legal) form : > handles, http URLs, URNs, bNodes with identifying properties. Some > of these may well not have been allocated by SIMILE at all and were > previously allocated. The History Store (and elsewhere in SIMILE) > needs distinctly identify each concept as objects are created and > changed. > > When the History Store does create "objects" it would be good if > they were GETtable. If there is a metadata record > http://thisInstallation/collection/1711/101 for an object > http://example.org/aBook then having "GET > http://thisInstallation/collection/1711/101" working would be > appropriate returning RDF if asked for application/rdf+xml. This > would need pulling the RDF out of the database for a plain GET if > there is no data duplication and hence chance for inconsistency. > > I would like to recommend that each URL minted by simile contain some > large random string (either truly random, or an MD5 hash of the bits > if possible) in addition to whatever else we put there. I think this > will maximize the possibility that our URLs can be unambiguously > interpreted regardless of future evolutions in RDF, domain names, or > the simile project. [ Odd echo from www-rdf-interest discussion at the same time ] This is one for Eric really but ... The value of a URL is that it is resolvable with GET. Adding a uniquely identifying bit pattern as protection against some future issue over resolution or control and still leaving it resolvable seems to me to be at odds. One way to get the effect of uniquely identifying bit pattern without any direct resolvability so it is independent of location might be to mint two names for the same resource. Allocate a URN to name the resource for that purpose, allocate a URL for its (current) web location. The two names don't have to be allocated at the same time. Use owl:sameAs to related them. Does allocating a URN (UUID scheme? MD5 hash of content? other?), or some such, achieve this maximisation of unambiguously interpretation? How strong does the uniqueness need to be? [[Or create a statement which assigns a "simile id" property/value but that is much the same as having a URN subject as the property is an owl:inverseFunctionalProperty to be useful]]. Andy
Received on Friday, 23 January 2004 13:09:18 UTC