On May 29, 2007, at 9:58 AM, James Rutherford wrote: > On Tue, May 29, 2007 at 08:21:47AM -0400, Mark Diggory wrote: >> PI resolvers come in all shapes and sizes, What all your talking >> about implementing is proxy/resolution. I would highly recommend NOT >> conflating the PI resolution mechanism (and why do we even have to >> have one) with the url path with which a Community, Collection, Item >> or Bitstream is referenced under in DSpace. What this means is that >> you do not have a url on with you have to worry about the identifier >> being properly escaped. You also only have to be concerned with >> resolving one path to the Item for "any" PI system. >> I.E. >> >> hdl:1234/5 --> http://dspace.me.ac.uk/item/ABCD >> >> and also >> >> doi:6789/0 --> http://dspace.me.ac.uk/item/ABCD > > OK, this is fine, but we'll need to define the form that we want > for the > URL. If we don't use the canonical form of persistent identifiers for > this, then we'll need to use another identifier that is unique across > the site (presumably, something based on the database id of the > object). > Using UUIDs (as suggested earlier) would *work*, but would produce > horrid URLs.
1.) the important point is that it is unique across the site and represents Objects only in "that site". If have objects replicated from some other dspace via some replication scheme, the local identifiers (uid) are always different for those replicated items, any global identifiers (purl, handle, doi, lsid,...) do stay the same. The current PLEDGE (AIP) work does support a unique uri scheme for DSpace objects that should meet this requirement. See details here: http://wiki.dspace.org/index.php/ObjectUri http://wiki.dspace.org/index.php/HistorySystemPrototype http://wiki.dspace.org/index.php/AipPrototype Some of these uri get "horrid" as you put it with lots of escaped chars and uri encoding required, it would be good to discuss a syntax that does not require heavy amounts of uri encoding (which is an other separate topic in this thread). 2.) All global identifiers may provide their own resolution mechanism, and these are "diverse", its probably best DSpace should not try to provide a common "resolution service" for global identifiers. Each service needs/may to provide its own via the AddOn mechanism. 3.) DSpace needs to provide a common "registration service" or API which can be implemented in AddOn's for registering new global identifiers in various services, this mechanism may be "stackable" and support the registration of various global identifiers according to the naming scheme of that naming service (handle, purl, doi, oclc, etc.) So, I think while UUID's would be sufficient, they are not necessary. The system would be robust with just unique identifiers per site. -Mark ~~~~~~~~~~~~~ Mark R. Diggory - DSpace Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology Office: E25-131 Phone: (617) 253-1096 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
