Kevin writes
- ie they cannot be resolved using default HTTP resolution. The idea of
using the http proxy version of the LSIDs is a good way to get around this, but this does have some drawbacks:
- 1st you really need everyone to agree to use it everywhere, which is a
bit difficult considering it is not at all part of the LSID standard, and we struggle to get "everyone" to do anything
- 2nd, it seems very much like a hack - you might as well just use permanent
http urls - ie the main advantage of LSIDs in this case is the "encouraging a degree of thought before making URIs publically available". But we don't really need to pick up the whole LSID overhead just to achieve this.
3rd: the system is complicated and it is difficult to guarantee that the sequence of reciprocal references is correct and in the right order and place. I believe you would need special validator tools to find errors in the system.
And, most relevantly, I believe it will exclude many from participation, because the complexity is a bit scary.
So it seems to me like good old Plain Old URLs are just great! : -) Or at least the suggestion of REST styled, permanent HTTP URLs as GUIDs ???
I fully agree. I believe LSIDs never were meant to be a technical solution, but rather a technical wedge to hammer in to achieve social change. All the LSIDs really promise are different management practices.
As argued in http://wiki.tdwg.org/twiki/bin/view/GUID/CommunityPracticesForHttp-basedGUID... I think it is sensible to agree on a community agreed mechanism to keep some URLs more stable than others. That could be URLs containing UUIDs, but I would argue for a social convention to agree on a recognizable string marking URLs that should be kept stable as long as possible and at least not re-assigned. There would be little harm to have a couple of such naming conventions, including e.g. non-english localizations, but one could be:
x.y.net/stable-id/something/12317982
Gregor