On Tue, 2007-07-24 at 11:12 -0400, Robert Tansley wrote: > The problem is I'm not sure how easy it is to disentangle the logic of > assigning IDs (what gets an ID of what form) and minting IDs. If the > 'Handle' piece of the implementation could be as simple as a 'mint' > method (i.e. if all identifiers were context-free) it would be easy to > abstract out. However, IDs may depend both on the object type and > related objects -- e.g. bitstream IDs may include the item ID as a > path component, or the version number etc -- and the ID scheme itself.
IDs will (? should!) always be free of the context of the process of assignment. Yes, assigning IDs will need access to the full and current state of the data model, but there should be an API for interrogating the model as necessary, which then wouldn't require the assignment and minting logic to be tied together. You would still be left with a minting implementation that would need to understand the relationships of the model, and would only be able to mint IDs for a set of pre-programmed circumstances - but for the most part if your ID is going to be minted from such information, you are going to have limitations on what it can cope with anyway. But... > You could create a flexible Handle system class that could sit behind > a couple of different implementations of the above (e.g. a > context-free one, and one that assigns contextual bitstream IDs, for > example) but I find it hard to believe that a single interface would > be sufficient for all different ID schemes (Handle, info:, PURL, UUID, > ...) ...how much are we considering for implementation now, and what needs to be left over for our idealistic system (2.0)? My answer to the above is that it should all be a problem of accessing the model / metadata - you interrogate the model, you write the ID directly into the metadata attached to the object that you are creating an ID for, etc. and a single interface would cope with all potential schemes (at least to the extent that the schemes could be applied). We aren't going to have that just yet, but any broadly similar API that could at least handle the simplistic EID cases that would be thrown at it in the short term, and could evolve along with the data model would, imho, be the way to go. G This e-mail is confidential and should not be used by anyone who is not the original intended recipient. BioMed Central Limited does not accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of BioMed Central Limited. No contracts may be concluded on behalf of BioMed Central Limited by means of e-mail communication. BioMed Central Limited Registered in England and Wales with registered number 3680030 Registered Office Middlesex House, 34-42 Cleveland Street, London W1T 4LB ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
