> 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.
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.
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.
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'.
The one special property that identifiers have (well, probably should have - I
can see there may be situations where this isn't true) is that they are unique
to a given entity. Does that warrant being handled specifically as an
identifier, or is that functionality that can / should be part of a more
generically useful 'metadata quality service'? I lean towards the latter.
And yes, there does need to be provider of the data (where the identifier needs
to be automatically assigned), but that can / should be a generic 'metadata
provider' (because there is metadata that can be automatically assigned that is
not an identifier).
I've not been convinced that having specific 'identifier' services is not just
a case of doing the same (possibly more) work to produce a solution that
doesn't fully realise the potential flexibility and power of the system.
>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.
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?
G
------------------------------------------------------------------------------
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
