Hi Tim,
On 13 November 2013 14:53, Tim Donohue <tdono...@duraspace.org> wrote:
> My main point here is that we need to find something that is still
> *achievable* for 4.0.
>
> Brainstorming a longer term resolution (which you see to be), is also a
> great exercise.
My main point is actually to highlight what may well be false assumptions
in what exists in DSpace, in order to frame our decisions correctly.
> But it's not realistic in terms of fixing/improving the REST API in time
> for 4.0 (unless we were to delay 4.0, which I don't think anyone wants to
> do). It's great for figuring out what we may want to change in 5.0, however.
>
> So, I agree with your points. We aren't doing a 100% perfect job of
> persistent IDs anyhow, and a lot is reliant on the DSpace installation (and
> whether they've purchased a handle prefix or not).
>
> But, based on what we have in place currently, I don't see any other short
> term fix for 4.0 other than to allow the REST API to work with
> [prefix]/[suffix] (even if we cannot guarantee that the [prefix] is a
> unique registered prefix).
I tend to agree - the 'handle' is the only identifier that we make clearly
and consistently available, and as such will have to be used in the current
scenario.
I think we should start taking steps to signal a future intention here
though - i.e. document clearly the implications of using an unregistered a
prefix, recommend strongly that a prefix is registered, and that in a
future version (maybe the following release?) we will look to make having a
handle prefix entirely optional, transferring primary identification to a
local, "non-persistent" identifier.
Looking ahead, we also have to bite the bullet that any local id - unless
we go entirely for UUIDs (ugly) - will likely be an auto-incrementing
sequence, and deal with it accordingly. For the purposes of straightforward
backup / restore, this should not be a problem. Obviously, if we move a
package from one instance to another, then we may have to assign those IDs,
but in general I don't see that as a problem - and if it is, that's what
you use externally registered persistent identifiers for!
I'm not expecting us to make a decision on that right now, I'm just stating
it for the record and so that we can start thinking about it in the
background.
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
