Hi Mark, >> I should add that the identifier stuff is actually complete, or at least >> at an alpha/beta stage. I'd hate to see this code lost, and it is >> fairly self contained, so would be interested in porting it to 1.6. I'd >> have to do that on my own time, though, as it's not /directly/ relevant >> to my current work, so it might take a bit of time. Anyone who wants to >> help out would be very welcome; it includes support for other identifier >> schemes (such as purl), and assignes identifiers to objects when they >> arrive, rather than when they are archived, which would solve a lot of >> niggling problems for people (particularly with regard to sword) >> > I'd actually be more interested in targeting 2.0, I don't think we are > far off from having the ExternalIdentifier portion be an > ExternalIdentifier service in 2.0 that would be utilized to add > appropriately generated ExternalIdentifiers to Entities. Since 2.0 > already abandons the usage of handles as the canonical identifier, > theres an opportunity to actually let go of the internal identifier > portion of the work and focus instead on providing a solid independent > service. > > We will certainly be needing support for handles, doi, lsid, etc, and > this seems like its the correct fit. >
Sounds interesting, yes I think the ExternalIdentifier stuff could fit nicely here, then. I'd still argue for its utility in 1.6, because certainly it's the case that sword in DSpace is broken in at least one way because there is no identifier available for an item which is in the workflow*, and alleviating that would be a good thing. * - sword deposits require an identifier for the deposited item to be returned on completion. Since there's no externalisable identifier for an item in the DSpace workflow, any deposit which does go into that workflow causes the sword response to be technically invalid (DSpace returns the base url of the service as the item identifier). Possible solutions would be an identifier which allows an appropriately authenticated user to access the item in the workflow, or the provision of an identifier which /will be/ accessible at some point in the future, neither of which are viable with the current code. It is also possible that we could quick-fix identifiers for 1.6 to sort this problem out. I think which way we went would depend on the overall timescale of 1.6 and then 2.0. Cheers, Richard -- Richard Jones Head Repository Systems Architect, Symplectic Limited e: rich...@symplectic.co.uk t: 0845 026 4755 t: +44 (0)207 7334036 w: http://www.symplectic.co.uk/ ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
