Good to have your input Garry.
As I mentioned in my previous email, we are in the process of creating some services and software that will aid with LSID adoption. Hopefully, one of these services is a hosting service that will allow people to create LSIDs and attach them to existing http resources, and have the hosting party (eg TDWG) handle the LSID resolution process. This should overcome this technical barrier and help a lot of people in this situation.
And yes, some of the code base is aging now (as is the case with the majority of software in the world). However, more recent code bases have been developed, and you could even use your own very simple custom service to handle LSID resolution (it does not have to be the full blown service as is provided by the java code base). See the tdwg page http://wiki.tdwg.org/twiki/bin/view/GUID/LsidSoftwareInventory for code options. On that page you will find an example of the simplest LSID service I know - the "lean PHP Resolver", which demonstrates the simplest way to implement LSIDs.
Kevin
-----Original Message----- From: Garry.Jolley-Rogers@csiro.au [mailto:Garry.Jolley-Rogers@csiro.au] Sent: Tuesday, 24 March 2009 3:17 p.m. To: Kevin Richards Cc: hlapp@duke.edu; beach@ku.edu; tdwg-tag@lists.tdwg.org; jim.croft@gmail.com; Margaret.Cawsey@csiro.au Subject: Some Comments on implementing LSID's
Hi Kevin,
Thanks. I'm very glad to hear that tdwg support for LSID's is active and look forward to learning more at Montpellier (** please Jim? ;) ). If I had known then I was to be implementing LSIDs now, I would have grabbed you in Perth @ the conference.
I don't agree that the technical issues are all minor (though they may seem so in retrospect) - especially not minor in the context of variable institutional I.T. infrastructure.
However, in Australia we have committed to following the TDWG standard i.e. using LSIDs, so it would be more helpful for us if we could solve the problems associated with LSIDs instead of continuing to revisit other options which would seem to have already been ruled out by TDWG's own endorsement of LSIDs. GUID's are supposed to be things that have some permanence. Implicit in this is the need for stability and support. I am happy to contribute as I well as I can.
#1 DNS implementation ... A trivial change not necessarily trivial to implement.
If you have control your own DNS then no problem but for LSID's to be adopted broadly they need to be used by institutions. It took a lot of effort to get our network people to make the appropriate changes to the CSIRO DNS.
This surprised me (it was such a simple small change) but in retrospect it's no surprise at all. After all, corporate network admins are necessarily conservative in outlook as they are managing risk. In their eye, all nonstandard things are suspicious and require a full business case (= months of delay). I had to work hard to convince them to make a one line change (with only minor delay).
If the network geeks don't get it then ....
#2 Old code base.
My google-fu may have foiled me in this. But the code base (perl/java for my platform) & instructions are > 2-3 years is old. This adds more potential points of failure for the novice implementer to worry over (versions of dependencies & co.). If left untended this will be a growing problem as versions and dependencies change further or are deprecated (as they eventually will be).
GarryJR
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Garry.Jolley-Rogers@csiro.au mailto:Garry.Jolley-Rogers@csiro.au Biodiversity Informatics, Taxonomy Research & Information Network Centre for Plant Biodiversity Research, CSIRO Plant Industry, GPO Box 1600, Canberra ACT 2601 AUSTRALIA w:(02) 62465501 http://www.cpbr.gov.au/cpbr/staff/jolley-rogers-staff.html http://www.cpbr.gov.au/cpbr/staff/jolley-rogers-staff.html
.·'¯`·.¸ ><((((o> .·'¯`·.¸¸.·'¯`·.¸ .·'¯`·.¸¸.·'¯`·.¸ >=}}}}}}/o>
><((((o> ><((((o>
Please consider the environment before printing this email Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails. The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz