[tdwg-tag] SourceForge LSID project websites broken - role for TDWG?

Kevin Richards RichardsK at landcareresearch.co.nz
Tue Mar 31 03:45:34 CEST 2009

I completely agree Renato.  We should encourage the use of GUIDs in general.
One particularly useful part of LSIDs was the RDF and data modelling that was encouraged to be used, in the LSID spec.  And I agree that it is the most important issue - the models and vocabularies.

As you say, there is no perfect GUID technology, and one of the clearest issues (esp. for all HTTP bound GUIDs) is the reliance of some technologies on the HTTP protocol.  Not that this is a present issue, but it is a potential long term issue - ie it is better to have a GUID that does not include the protocol in the GUID string itself, than one that does (ie urn:lsid:...  is obviously better than http://purl.org/...  in this case).  There is no great solution for this.  But then, there is no perfect GUID technology...    But LSIDs definitely do give us this benefit, so there is gain with the pain after all  :-)


-----Original Message-----
From: tdwg-tag-bounces at lists.tdwg.org [mailto:tdwg-tag-bounces at lists.tdwg.org] On Behalf Of renato at cria.org.br
Sent: Tuesday, 31 March 2009 2:29 p.m.
To: tdwg-tag at lists.tdwg.org
Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG?

I think I would prefer to see a different solution. Dropping LSIDs
altogether seems a bit drastic after all work that was done. If we had a
perfect GUID technology, I would understand this kind of decision, but we
all know we don't have such thing. On the other hand, focusing exclusively
on LSIDs could prevent some of our data providers to serve and to maintain
GUIDs. So why not just offer an alternative?

If clients will need to deal with different types of GUIDs anyway,
especially if they will have to interact with different types of
providers, the matter of having to agree on and to adopt a single GUID
technology becomes less important. We already live on a world where
different types of GUIDs are being provided.

Personally I've always preferred PURLs for its simplicity and compliance
with existing tools and technologies, although I know it has drawbacks. If
some of our data providers can reliably serve LSIDs - great. But if LSIDs
are too complicated for other data providers, I don't see any problem for
our community to create an additional applicability statement for another
GUID technology. The most important thing, in my opinion, is to agree on
the data models/vocabularies that our GUIDs will resolve to, no matter the
resolution mechanism used. But that's another story...

Best Regards,

> Perhaps the question is whether LSIDs are a hurdle to adoption of the
> use of GUIDs or an aid to it.
> DOIs are not just a technology they are a business model plus a
> technology (they use HANDLE for the technology). It is worth the
> client overcoming technical difficulties in their use because of the
> value added by the publisher paying for the associated
> infrastructure.  I would argue that DOIs/HANDLE are, in fact, a
> complete pain because they don't integrate well with semantic web
> technologies but that they are carried along purely by the business
> model.
> In advocating the use of LSIDs we are advocating the pain without the
> benefits. Just like DOIs they are awkward and non-standard to set up.
> They need to be constantly explained. They don't work in semantic web
> technologies. They don't even integrate with XML (could you host an
> XML Schema on an LSID?). All this would be OK if they had an
> associated business model - but they don't.
> My personal belief is that we should either put together a business
> model (with the financial backing of big projects and within the next
> few months) where some core services are provided by a third party or
> we should drop LSIDs altogether. Alas I fear the big projects are more
> interested in data volume and pretty pictures than doing good science
> and providing basic services (I am being contentious for emphasis so
> don't take it personally).
>  From the technical perspective this:
> urn:lsid:zoobank.org:act:8BDC0735-FEA4-4298-83FA-D04F67C3FBEC
> is far harder than this:
> http://purl.zoobank.org/8BDC0735-FEA4-4298-83FA-D04F67C3FBEC
> so we need a good business case for doing the former. What is it?
> All the best,
> Roger
> On 23 Mar 2009, at 01:58, Kevin Richards wrote:
>> As convener of the GUID subgroup of TDWG TAG, I thought I should add
>> some comments.
>> The debate over LSIDs, their suitability, technical issues, etc, has
>> been going on for some years now in the TDWG community (and also
>> within a few other communities - especially the HCLS Health Care and
>> Life Science semantic web group).  Most issues have been raised and
>> dealt with, and as with most technologies, there is no perfect
>> solution for a GUID technology.  To review these discussions see the
>> TDWG pages at http://wiki.tdwg.org/GUID/ and
>> http://www.tdwg.org/activities/guid/documents/
>> . Documents that cover an introduction to GUIDs/LSIDs, applicability
>> statements, and technical issues can be found here.
>> I feel we are getting to a stage with LSIDs that a lot of people in
>> this community have had some sort of dealing with the technology
>> (whether it is setting up an LSID resolver, or using them/resolving
>> them as through client software) and we therefore have a good range
>> of experiences, knowledge and conclusions about the use of LSIDs.
>> As part of the TDWG meeting in Montpellier this year, we hope to
>> hold a session for "LSIDs in Practice" which should give us a good
>> indication of any LSIDs issues, and how they have been dealt with in
>> practice.
>> Also, there are several activities going on that should aid with the
>> adoption of LSIDs, such as development of software tools and
>> services, and as we speak the LSID web site is being transferred to
>> a TDWG server to be hosted there (it has been a bit of a technical
>> hurdle for some of us to get this web site moved, so you may need to
>> bear with us for a little while).
>> Generally the technical issues of LSIDs are relatively minor.  The
>> more obvious issues (such as persistence - ie that an LSID will be
>> resolvable indefinitely, and community support and technological
>> aids will always be available), tend to be community/social issues.
>> What really makes the success of any initiative is the community
>> support and drive behind the initiative, and the same is true with
>> whatever technologies we adopt in the TDWG community.  The important
>> thing therefore is that we start using the GUIDs, linking them up
>> with other GUIDs/data, distributing them, promoting "authoritative"
>> GUIDs, and then I really believe any remaining issues will be easily
>> overcome.
>> Thanks
>> Kevin

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

tdwg-tag mailing list
tdwg-tag at lists.tdwg.org

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

More information about the tdwg-tag mailing list