Hi Tim,
On 11 November 2013 18:09, Tim Donohue wrote:
> Actually, this is a big deal, as whether an ID in the REST API was
> persistent would now *depend* how you are backing up your DSpace
>
Well, it depends on the guarantees that you want to provide. If you are
expecting to manually enter an
Hi Graham,
One quibble..and a few comments
On 11/11/2013 10:24 AM, Graham Triggs wrote:
> On 11 November 2013 15:26, Tim Donohue It's worth also pointing out that the AIP system does
> NOT persist database IDs (and says that explicitly). So, even restoring
> content from AIPs will of
On a side note about digital object persistence. Would this work:
http://hdl.handle.net/10019.1/3161?
On 11 November 2013 18:24, Graham Triggs wrote:
> On 11 November 2013 15:26, Tim Donohue wrote:
>
>> Whatever we use, I think the IDs surfaced by the REST API do need to be
>> persistent. They
On 11 November 2013 15:26, Tim Donohue wrote:
> Whatever we use, I think the IDs surfaced by the REST API do need to be
> persistent. They need not necessarily be globally unique/persistent
> (like a handle or DOI), but they should be persistent within DSpace,
>
> Database IDs are definitely *not
A few notes to add to this discussion.
Whatever we use, I think the IDs surfaced by the REST API do need to be
persistent. They need not necessarily be globally unique/persistent
(like a handle or DOI), but they should be persistent within DSpace,
obviously. Without a persistent identifier in p
Hi,
about the identifiers, I guess one must agree on what we expect from them.
We cannot forget that there is already the OAI interface which is meant to
guarantee some persistency and uniqueness over the identifiers.
Thinking about Rest APIs in general, they emerged as a simple way to access
dat
Thinking about this a bit more, I've come round to the position that I
don't see why database record IDs are a problem in this context. All
we need to do is to inform people that we explicitly deny long-term
meaning to these identifiers; they should be assumed to have session
scope. If you store
I don't think I'm able to see too far into the future on this (or any) API.
I see it as more a means to an end. This new machine interface will be a
pleasant way to get data out of your repository, repurposed into other
systems. Clients of the API should expect a stable interface for a period
of ti
Hi Mark:
Thanks for the thoughtful response.
The point about handles was not intended to enshrine that particular ID system;
I meant it as illustrative ("persistent IDs, _such as_ handles"). I certainly
agree that
a REST API should not enforce any particular scheme, and we have made some
headway
I want to look over this posting more carefully, but I did want to get
one thought out quickly. Please, let's not overload Handles even
more. There are sites, I've heard, that would like to do away with
Handles and use something else for durable universally-unique external
identifiers. That's har
First, I wanted to thank (especially) Peter, Anja, Kostas, and several others
for reinvigorating the work around a REST API.
Even though I've been too busy to comment until now, I'm interested and did
note the progress. I do have some observations/impressions, which follow in no
particular ord
11 matches
Mail list logo
