On Tue, 2007-07-24 at 09:22 +0100, James Rutherford wrote: > As I see it there are > (broadly) two camps: those who believe that every meaningful tier in the > DSpace content hierarchy should get external identifiers, and those who > don't (or at least those who can't decide and so want it to be > configurable).
Do you mind if I take my tent and pitch a little further down the road? Partly because I've seen images of the swollen rivers over your way, but mostly because I can decide and that's why I want it configurable ;) > Users (and administrators) crave consistency. If we make this assignment > configurable, there is no guarantee of consistency of application > between collections, or even in a single collection over extended > periods of time. They crave accuracy as well, and consistency isn't the same thing ;) > The configurable parameters (if we are going to please > everyone) would be: > > * whether or not to assign external identifiers at all > * which external identifier system to use by default > * whether or not external identifiers are re-assignable > * whether or not new "versions" of objects get new identifiers > * which tiers in the content hierarchy get identifiers (if any) > > I'm sure I've missed a few, but does that sound like something that is > reasonable to want / implement / support? Providing the options that modify the use of an identifier system apply on a per-system basis, that sounds like a reasonable list of what should be possible. But, I think we are getting a little tied up around the idea that it may only be a single implementation that has all these possibilities available as configuration options - and that need not be the case at all. ie. a pluggable 'ExternalIdentifierManager', which supports managing a single indentifier system (configured by default to be handles), that out-of-the-box replicates the existing behaviour (EIDs for Items, not bitstreams) and can easily be configured to also assign EIDs to bitstreams. Beyond that, more advanced cases can be handled not by adding more and more configuration options, but by switching out the implementation. G This email has been scanned by Postini. For more information please visit http://www.postini.com ------------------------------------------------------------------------- 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
