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 <tdono...@duraspace.org > 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. 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. Some folks still do backups of the database & files separately -- as noted, this would retain database IDs. However, others are using the AIP Backup & Restore tools for backup (namely to services like DuraCloud or similar, or for some of the other benefits of AIPs, e.g. single object restoration). AIPs WILL NOT retain database IDs when recovering content. So, a simple recovery would cause your Database ID to change. They will however retain global identifiers like Handles. > > 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! Fair point. I was just noting that Handles are more persistent than a simple Database ID, in that they can be retained via the AIP Backup and Restore functionality. > 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. Great point. It's rather difficult (is it even possible?) for anyone to figure out the database ID without having Admin rights in DSpace. > > 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. Oh yes, I totally agree with this. I'd rather have DSpace assign its own instance-unique PIDs. I'd just argue that a Database ID cannot be that PID, as it's an auto-incrementing sequence (and hard to "reuse" in cases of restoring/recovering deleted content, which is why AIPs have a hard time retaining Database IDs) - Tim ------------------------------------------------------------------------------ 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
