On 06/01/2011, at 7:28 PM, Roderic Page wrote:
I suspect the failure of LSIDs is due to a combination of issues:
Another problem with LSIDs is that the specification is complex and difficult to implement, especially it's reliance on WSDL. You have to absorb a great deal of spec before you can implement it correctly. One of the goals of our implementation was to provide some software which would take care of all that: you can put any data you like into it without being bound to any particular XML schema or set of database views, and it will serve up your data according to the spec.
- Most biodiversity data providers are small, poorly resourced
operations that can't guarantee 24/7 operations
As you point out, http uris don't make this problem go away. Service-oriented software approaches must be designed at each layer with the expectation that services will go down, each layer must cope with asynchronous delays. This applies even in-house: I worked a one shop where their entire system simply stopped when the image repository jammed (which happened about twice a week, and needless to say it was 3rd party software so couldn't be tinkered with). Use of the internet makes the problem worse. The problem is simply that it's hard to do.
- There are no LSID consumers.
Partly a result of the specification being so complex - the most complex part of it being that you have to understand WSDLs. Talking to an LSID resolver is as byzantine as writing one. A java "protocol handler" that you could drop into your lib directory might go a ways to fixing this. The spec is at the OMG site, and the only support there is a single pdf. Everything else is an effort. When we started, the only code was that old IBM thing, and we gave up on it.
By contrast, just about every software platform these days will fetch an http URI - http is ubiquitous.
It's a failure of our community to create the appropriate resources (e.g., centralised, curated resources of identifiers and associated metadata for names, publications, and specimens).
"Why should we use LSIDs? No one else is, and it's really hard to do."
Another difficulty is that the community already has a system for handing out unique identifiers and extensive systems for managing them - these identifiers are scientific names, and the systems are the various nomenclatural committees. Isn't it absurd to coin unique, stable identifiers when "Ixodes tasmani" is such an identifier already? Isn't that good enough? Turns out it isn't: that it actually only uniquely identifies things when it's used in a context. Nevertheless, you don't get buy-in unless what you are proposing is clearly better than what people already have. It's difficult to persuade someone that a human-readable system that has worked just fine (more or less) for 300 years needs to be fixed, particularly when the fix is 'urn:lsid:lsid:biodiversity.org.au:afd.name:291425'.
_______________________________________________
If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments.
Please consider the environment before printing this email.