On Fri, May 25, 2007 at 03:39:12PM -0500, Brad Teale wrote: > How do you determine which PI system generates a PId (base it > on collection, community)? What if one PI system fails (URL > unreachable, temporarily down) and it is needed to resolve the PId? > Could it be possible to create a loop of PIds that resolve to different > PI systems while moving through the PI system stack?
Something to note is that I don't anticipate objects normally having more than one identifier. While the prototype allows this, it will still be the case that objects are only assigned one identifier (according to configuration -- the details of which are still undecided) but now we are able to associate multiople identifiers to objects (the stack is there to define what we understand), and resolve them all to the correct place. > 3) Including special characters in the URL string doesn't seem like a > good idea. While they are valid characters, it does take extra > processing to encode/decode them from layer to layer. Why not just > leave the URL alone or change /handle to something like /uri, /id, or > /pid? Why encode the PI system into the URI? As I mention on the wiki, my current idea is to have URLs of the form: http://dspace.me.ac.uk/uri/hdl:1234/56 which will resolve to the object with Handle 1234/56, etc. If the object also has a DOI with value 7890/12 then the following URL would point to the object as well: http://dspace.me.ac.uk/uri/doi:7890/12 It is necessary to include the "hdl:" and "doi:" parts so we can distinguish between different persistent identifier mechanisms. The values allowed for the persistent identifier are dependent on the mechanism we are dealing with, and as far as possible this will be kept simple. > As far as having a default PI system out of the box for Dspace, I would > recommend using a local identifier schema which used the existing URLs. > Include the Handle PI system in the release as a configurable option, > but not turned on by default. This would remove the fake handle being > assigned to all objects and clean up the default URLs out of the box. I've already experimented with a "null" identifier that can be used to resolve to objects locally. For example, in my prototype, the following url would resolve to the Item with internal id 4: http://dspace.me.ac.uk/uri/dsi:2/4 I'm still not convinced that this is a good idea, but it seems useful and it makes accessing individual bitstreams a little more predictable and consistent with the other objects. cheers, Jim -- James Rutherford | Hewlett-Packard Limited registered Office: Research Engineer | Cain Road, HP Labs | Bracknell, Bristol, UK | Berks +44 117 312 7066 | RG12 1HN. [EMAIL PROTECTED] | Registered No: 690597 England The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL". ------------------------------------------------------------------------- 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 DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
