Hi Mark,
On 11/13/2013 12:06 PM, Mark H. Wood wrote:
I had missed that we were hurrying to do something in 4.0. I had
assumed that there wasn't time.
To clarify, I was not recommending we change identifier schemes in 4.0.
As Graham mentions, all I was recommending is that we stay
It is very easy to make the REST API understand handles. I have done it
for items locally already. At the moment it is in addition to database
ids, but I would be happy for DB ids to disappear from view completely.
Best regards,
Anja
On 15/11/2013 16:08, Tim Donohue wrote:
Hi Mark,
On
Sorry, but the current REST API does support lookup by handles.
https://github.com/DSpace/DSpace/tree/master/dspace-rest#handles
https://github.com/DSpace/DSpace/blob/master/dspace-rest/src/main/java/org/dspace/rest/HandleResource.java#L32
@Path(/handle)
public class HandleResource {
@GET
Example: http://demo.dspace.org/rest/handle/10673/1?expand=all
Peter Dietz
On Fri, Nov 15, 2013 at 12:00 PM, Peter Dietz pdiet...@gmail.com wrote:
Sorry, but the current REST API does support lookup by handles.
https://github.com/DSpace/DSpace/tree/master/dspace-rest#handles
Hi Peter,
Thanks for clarifying! I must have overlooked that feature (I think most
of the examples I had seen before were all DB ID based, and so that's
how I was using REST).
In that case, I think we are good enough for 4.0. For 5.0 we can work
on improvements to our local identifiers
On Wed, Nov 13, 2013 at 10:07:40PM +, Graham Triggs wrote:
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
Hi Graham,
In all honesty, I agree with your points (in this email and others)
about our assumptions about IDs and that we aren't necessarily providing
all the proper guarantees needed for persistent IDs.
My main point here is that we need to find something that is still
*achievable* for 4.0.
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
I had missed that we were hurrying to do something in 4.0. I had
assumed that there wasn't time.
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
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
I like that. It fits in very well with how we locally operate our web
application (using only the suffix of the handle) and we don't have to
expose database ids.
If the DSpace community can agree on this method, it would not be
difficult to modify the REST code to use the handle suffix as ID.
On Tue, Nov 12, 2013 at 08:12:27AM +, Anja Le Blanc wrote:
I like that. It fits in very well with how we locally operate our web
application (using only the suffix of the handle) and we don't have to
expose database ids.
If the DSpace community can agree on this method, it would not be
I've created a Jira issue to gather all the threads related to local
object identifiers:
https://jira.duraspace.org/browse/DS-1782
I found another place where we need something like this, and it wants
globally unique identifiers. That seems to point to something like a UUID.
--
Mark H.
On 11/11/2013 1:28 PM, Mark H. Wood wrote:
OK, if others see a use for persistent local identifiers then they had
better be persistent. I wasn't thrilled with the idea of overloading
database record IDs either, especially since we'd have to compound
(ID, type) tuples into some string
On 12 November 2013 16:50, Tim Donohue tdono...@duraspace.org wrote:
Therefore, I'm hesitant to limit the locally-unique ID to suffix only
-- as I believe that may cause ID collisions in some DSpace instances.
I think it needs to remain [prefix]/[suffix] until we have something
better, like
OK, if others see a use for persistent local identifiers then they had
better be persistent. I wasn't thrilled with the idea of overloading
database record IDs either, especially since we'd have to compound
(ID, type) tuples into some string representation, to uniquely
identify an object.
So, it
16 matches
Mail list logo
