On Thu, Apr 30, 2009 at 8:33 AM, Graham Triggs <gra...@biomedcentral.com> wrote: >> 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. > > Whilst I completely agree with the need to not 'enforce' the use of handles, > I've always stated - and will continue to do so - putting in explicit > support for something determined an 'identifier' is probably the wrong way > to go.
I think we agree that we are seeking something akin to a MetadataRegistryService that may provide validation/minting of values for metadata fields, of which some may be considered identifiers. > When you look at certain identifiers that are or can be attached to an > entity / item, then you have some that are unlikely to be automatically > assigned or generated by the system, such as PubMed IDs, publisher DOIs, > etc. Certainly... > > Those are generally going to be entered and/or edited manually by operators > (if automatic matching is attempted, there WILL be cases where subsequent > manual editing is required!). I don't see that as being tied to an > ExternalIdentifier object or service - it's just going to be metadata / > properties assigned against an entity. So a serve that populates fields, but the ability to customize or add your own field are requirements. > > Yes, we need to index those properties, and be able to search and retrieve > against those properties. And scope those lookups accordingly. But that is a > generic issue that we have to apply to any metadata/property (and > combinations of!), not just values that are tied to an 'ExternalIdentifier'. Your preaching to the choir.... >>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. I think the 1.6 solution is either to assign handles first on items not yet archived or to use the internal db id as the return value (which would then just be the uuid by the time we get to 2.0) > > OK, let's just take a trip down the work that's already been done in the > prototype. This assigns an internal (UUID) identifier to an item, and allows > a number of other external identifiers to be attached. Of which, the default > implementation is to provide a Handle. > > But making that distinction doesn't (shouldn't) enforce when you might > choose to assign the external identifier(s), and wouldn't enforce what is > available for returning as a an identifier for the sword deposit. > > So, what would you envisage passing back as the identifier in the sword > deposit? A specific local identifier that was either the dsid in 1.6 or the uuid in 2.0 -- Mark R. Diggory @mire NV USA http://www.atmire.com ------------------------------------------------------------------------------ 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
