Hello Mark, I think I wasn't clear in my previous post, which happens to non-native speakers, sorry about that.
I meant to say that building a flexible ExternalIdentifier service is a challenging task (as James himself has said), so I am concerned that at some point the configuration options will be dropped (because of lack of time, etc.) and the bitstream identifier assignment will be "turned on" and difficult to disable. This is less likely to happen if, instead of one ExternalIdentifier implementation, Dspace will have a mechanism to plug-in different implementations (and the default implementation will replicate current functionality) Actually, I am just re-iterating what Robert and Graham have already suggested. Regards. Kate Ekaterina Pechekhonova Digital Library Programmer/Analyst New York University Libraries email: [EMAIL PROTECTED] phone: 212-992-9993 ----- Original Message ----- From: Mark Diggory <[EMAIL PROTECTED]> Date: Wednesday, July 25, 2007 9:16 pm Subject: Re: [Dspace-tech] [vote] Do we want to assign external identifiers (Handles) to files? To: Ekaterina Pechekhonova <[EMAIL PROTECTED]> Cc: DSpace Tech <dspace-tech@lists.sourceforge.net>, Robert Tansley <[EMAIL PROTECTED]> > Hello Kate, > > On Jul 25, 2007, at 4:48 PM, Ekaterina Pechekhonova wrote: > > > > >> We need to reiterate and recognize that in the DSpace 2.0 > >> Architectural Model it was of strong interest that "Metadata" can be > >> > >> attached at any level of the Data Model (Community, Collection, Item, > >> > >> Manifestation and Content). That for all practical purposes, and > >> External Identifiers are "just Metadata" and as such should be > >> assignable across the entire model either manually or dynamically. > > > > if I understand it right, nobody has problems with "should be > > assignable" > > but some people(including myself) are concerned that it will become > > "should be assigned" at some point. I personally think that it's > > more likely > > to happen, if an attempt is made to stick to one implementation of > > ExternalIdentifier Service instead of allowing multiple > > implementations. > > No, IMO, thats exactly the opposite of the direction that the > developers such as James are seeking, we're trying to undo the > restrictions forced on the system through hardcoded logic and forced > > dependency on specific technologies (like Handle Services) in favor > of shifting it into a configurable strategy that gives a IR manager > the ability to setup the system the way they see fit. For DSpace 1.6 > > There will continue to be a default configuration and implementation > > which is handle based, but the goal is to allow for other > implementations in parallel or completely replacing the default. > > -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: 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 ------------------------------------------------------------------------- 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
