On 13 November 2013 18:06, Mark H. Wood <mw...@iupui.edu> wrote:
> Please let us keep DS-220 in mind. SWORD needs a *globally unique*
> identifier to begin deposit, before we will have created a Handle or
> DOI or whatnot -- that happens when the Item is installed. So
> we are sort of being forced toward UUIDs or something like them.
>
> https://jira.duraspace.org/browse/DS-220
As far as I can see it, SWORD does not demand a *globally* unique
identifier. It expects an identifier, and it expects that it "should"
persist.
The definition of persistence can be considered vague, and I would take it
to mean persistent for that instance - not that it should have some kind of
persistence for migration to a different instance ( / SWORD endpoint).
Basically, if I return back that this a SWORD deposit creates item "1",
then it should remain item "1" when the deposit is complete - not that it
gets reassigned as item "2" once accepted (or it increments as changes are
made in a versioning scenario, etc.).
Trouble is, there is a lot of weight to the words we use, a lot of baggage
tied up to concepts, and indeed the problems that we've noted in this
discussion about what identifiers that we have are public, which was
leading us to preferring to return a handle as that identifier for SWORD
(which is problematic, due to the timing of when it is assigned).
But it doesn't mean that it couldn't be the database identifier, or
anything else that we choose to be the public identifier. And even if it
needed to be globally unique, that doesn't mean the globally unique value
has be our primary / public identifier - we can register a UUID against the
primary / public identifier, just as we register handles against the
database identifiers.
o Durable across backup/restore. Destroyed and reassigned when
> transporting objects between instances.
>
Which the database ID does accomplish. It's very important to remember that
although these identifiers originate from sequences, and are assigned into
the primary key, this is not a property of the database as we've defined it.
We *manually* select the next sequence number, and *manually* insert it
into the primary key column when we create a row in the database. We can
choose to ignore the sequence and insert any arbitrary integer in it's
place - providing the integer does not already exist in the table.
Which it shouldn't in the backup / restore scenario. Complete restore in an
empty instance - no ID has been used. Selective restore after an item has
been destroyed - the previous row will be gone, and the sequence will be
past this point, ID won't be present in the table. You just need to ensure
after restore that the sequence is set to assign IDs from a reasonable
arbitrary point.
The only time you run into trouble is migrating an item to a different
instance, or trying to restore a deleted item after you've migrated another
item with the same ID into the instance. But actually, those kind of
clashes can exist with handles in the way that they have been used, we can
provide reasonable options for reassigning IDs - it needs to be catered for
anyway, and it's not (imho) a problem.
It would just need AIPs updated to also track the database (or other local
object) identifiers.
o And we want *something* for 4.0.
>
The only thing we can do for 4.0 is be consistent about our only "public"
identifiers, and make clear statements that we will make handles properly
optional for the next release, with a local object identifier taking over
the primary, mandatory non-global public identifier (which really could
just be the database identifier).
G
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
