On Wed, Nov 13, 2013 at 10:07:40PM +, Graham Triggs wrote:
> On 13 November 2013 18:06, Mark H. Wood 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 whe
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 (DS-1
Example: http://demo.dspace.org/rest/handle/10673/1?expand=all
Peter Dietz
On Fri, Nov 15, 2013 at 12:00 PM, Peter Dietz wrote:
> 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/D
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
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 11/
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 *consisten
On 13 November 2013 18:06, Mark H. Wood 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 o
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
Hi Tim,
On 13 November 2013 14:53, Tim Donohue 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
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
On 12 November 2013 16:50, Tim Donohue 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 a UUID or simi
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 rep
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. Wood,
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 no
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.
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