See the arch review notes (I think
http://wiki.dspace.org/index.php/ArchReviewNotesThur was the day we
really hammered on it) for decisions made about identifiers and
versions. We spent a lot of time on that! (Basically there's an
identifier for the 'latest version' of each item and sub-part, and
each version also gets a separate ID).
One reason you might not want to assign context-free external
identifiers like Handles to bitstreams is that Handles are not free,
they require maintenance over time. (Contextual or 'hierarchical'
identifiers like info:item_handle/bitstream_id are 'cheaper' in this
regard -- you don't have to maintain the context and relationships ad
infinitum as they're implicit in the identifier.)
Another point is that in assigning an identifier, you need to be very
clear on exactly what you're identifying. It sounds like there's an
assumption here that (say) a Handle assigned to a bitstream is
identifying that exact sequence of 1s and 0s, rather than 'chapter 2
of the book'. Giving symmetrical identifiers to both logical
constructs ('item', FRBR work etc) and 'physical' constructs (an exact
sequence of 1s and 0s) could get confusing -- what is identified by
one may change over time to reflect changes in technology etc. but the
other is set in stone.
This was the thinking behind the original decision to have Handles
assigned to Items but not Bitstreams: The Item is what is
'persistent', the particular (potentially numerous) files within may
change. So giving out apparently identical identifiers that actually
have different levels of persistence guarantee (or, maintaining all
those file identifiers and their relationships for items forever) was
something we wanted to avoid. We regarded access to bitstreams as a
'service' on the item.
So in short flexibility is the key! Definitely good to be able to
assign external IDs to files, but people need to be clear on what
they're identifying, and free to give out contextual identifiers or
differently-schemed identifiers to other elements like bitstreams or
metadata records.
On 20/07/07, James Rutherford <[EMAIL PROTECTED]> wrote:
> I definitely don't want to turn this into a
> discussion about identification systems more generally otherwise we'll
> be here until next year
See you in 2008...
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
