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 <grahamtri...@gmail.com> wrote:
> On 11 November 2013 15:26, Tim Donohue <tdono...@duraspace.org> 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* persistent. They are just an
>> incrementing ID, and that ID changes if you move an object from one
>> DSpace to another.
>
>
> But if we are saying that it does not need to be globally unique or
> globally persistent, then the ID changing when you move an object to
> another DSpace instance is not really an issue.
>
>
>> 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 often not provide the same Database ID. It'd be
>> unfortunate if upon restoring content to your DSpace (from an AIP), it's
>> no longer available at the same location from the REST API.
>>
>
> Unfortunate, but I don't see it as a deal breaker. The primary disaster
> recovery strategy would be to backup and restore the database (and file) -
> which would retain the same ID.
>
> We can't guarantee that database IDs will persist across DSpace versions
> (i.e. during an upgrade) - and we should explicitly state that.
>
> External systems integrating via REST need to be able to cope with content
> being removed, and added. As long as they do this, then they should cope
> with content being selectively deleted and subsequently re-imported via an
> AIP.
>
>
>> Currently our only DSpace persistent IDs to choose from are Handles and
>> now DOIs (in 4.0). I see no reason why we shouldn't use either (or both)
>> of these in the REST API, especially since we have no other DSpace PID
>> or UUID to work from (at least not yet).
>>
>
> Bear in mind, that they aren't necessarily persistent either - we ship out
> of the box with a fake handle prefix, and tools to be able to reset the
> prefix - i.e. in the case that a prefix gets registered later.
>
> Therefore, a persistent ID is only as persistent as the implementing
> institution chooses for it to be!
>
> So, for the purposes of a REST API, I believe that the database ID is
> "persistent enough". External systems have to cope with variation over
> time, and can always be flushed during a major upgrade of DSpace, if
> necessary.
>
> However...
>
> We don't necessarily need to identify what the persistent ID "means" via
>> REST API. But, it should be persistent.
>>
>> Therefore an identifier:
>>
>> http://localhost:8080/webapi/content/collection/12.34/56
>>
>> could be either a Handle (hdl:12.34/56) or a DOI (doi:12.34/56) or some
>> other sort of PID.
>
>
> What's more important here is that the REST API uses a *public*
> identifier, which is consistent with the UI.
>
> The primary instance URL of an item is based on it's handle, rightly or
> wrongly (mostly wrongly!). You should be able to take something that is
> used to identify an object in DSpace, and use it in the REST API.
>
> You know the "handle" (fake or real) for an item. You don't necessarily
> know it's database ID. And that's what makes using database ID in REST a
> problem.
>
> Ideally, I would like to see a primary object URL using an
> instance-persistent public ID - which is not the handle or DOI - and that
> would be the primary ID that you use in the REST API. But, on top of that,
> if you configure a real persistent identifier, you could get to the object
> - both in the UI and the API, using that identifier.
>
>
>> We don't necessarily need to specify which it is (at
>> least not on the URI). But we do need to ensure it is unique and
>> persistent within DSpace. That way if someone requests 12.34/56 today,
>> and also requests it a year from now, they should be getting the same
>> object from that particular DSpace. Unfortunately, that's not a
>> guarantee we can make with Database IDs, as nothing in DSpace ensures
>> their persistence after upgrades or data migrations or restorations from
>> backup.
>>
>
> Which brings us to the question of what representation you get back. Is it
> necessarily the same as the representation you got a year ago? What about
> if you kept the object / identifier and replaced all of the metadata and
> the files? I realise it's a rather bizarre example, that isn't likely to
> occur in real life, but in general, a little too much stock is invested in
> persistent identifiers. They are important in the overall scheme of things,
> but when it comes to the API, and the situations it is meant to support,
> being consistent is far more important that being persistent.
>
> In reality, we are rather limited in what we call public identifiers in
> DSpace, but we're possibly causing problems by having a formal contract of
> persistence on REST API identifiers.
>
> G
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Dspace-devel mailing list
> Dspace-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
>
--
*Hilton Gibson*
Ubuntu Linux Systems Administrator
JS Gericke Library
Room 1025D
Stellenbosch University
Private Bag X5036
Stellenbosch
7599
South Africa
Tel: +27 21 808 4100 | Cell: +27 84 646 4758
http://library.sun.ac.za
http://za.linkedin.com/in/hiltongibson
http://staff.lib.sun.ac.za/~hgibson/docs/cv/cv.html
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
