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 in abstracting identification services in the platform.
If your persistent ID of choice is something else, the the REST API should
expose it.
Whether the use of Handles is appropriate (if that's your ID system) in this
context,
or whether DSpace needs a new persistent ID system with the characteristics you
outline is more debatable I think,
and raises many thorny questions (if only locally unique, how can content
stewardship be transferred without collisions?, etc)
that are quite important, but I think to some degree orthogonal to the REST API
design features I was trying to point out.
But point definitely taken, and I'll try to use more neutral descriptions (PID
maybe?), which I agree is the issue at hand here.
Richard R.
On Nov 8, 2013, at 9:51 AM, Mark H. Wood wrote:
> 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 hard to do if we wire Handles into everything.
>
> What we want, it seems to me, is an additional durable identifier
> which requires only local uniqueness and has *no meaning* in
> isolation. The last property excludes Handles and DB IDs alike. What
> this means is that we need, probably, just a simple serial number
> facility, which is used to name every object created. These names are
> not used internally by DSpace (as DB IDs are); they exist solely for
> users to identify "that object you mentioned before".
>
> This way, those names can be permanent (unlike DB IDs), don't tie us
> to specific external services (like Handles), and can't tie us down to
> specific internal organization (like either).
>
> --
> Mark H. Wood, Lead System Programmer mw...@iupui.edu
> Machines should not be friendly. Machines should be obedient.
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
