On Wed, May 30, 2007 at 10:43:12AM +0100, Graham Triggs wrote: > On Tue, 2007-05-29 at 14:58 +0100, James Rutherford wrote: > > Using UUIDs (as suggested earlier) would *work*, but would produce > > horrid URLs. > > Note that I never suggested using UUIDs as part of a URL. What I said is > that UUIDs would give you a robust scheme of internal unique identifiers > - and in having that, the use of all other identifier schemes are > reduced simply to a matter of how you map to/from the UUIDs.
That's fine, but then whether or not we assign UUIDs is a separate issue. The immediate problem I'm trying to solve is how we construct consistent, concise URLs that point to DSpace objects (communities, collections, items, and bitstreams). > But even if UUIDs where exposed in the URLs (in a default installation), > is that necessarily a problem? The ugliness of it would at least > encourage people to think about the issues of id persistence / > assignment in relation to that repository. I don't think this is true. I think it would (as with the placement of bistreams in the assetstore) make people ask "why on earth did you do it like that?" ;) > By assigning UUIDs as the primary / internal id of all persistent > objects in DSpace, we can use tried and tested, well understood > algorithms to generate IDs that are virtually guaranteed to be unique, > which would open up potential usage / installation scenarios that could > otherwise be impractical. It would also have some consistency with the > JCR specification, and you've got the potential to make them public, > persistent identifiers if that is deemed suitable for a given > installation. I don't disagree that maybe DSpace should use UUIDs, I just believe that it is a separate issue, and one that is beyond the scope of what I'm currently trying to do. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
