2009/3/20 Beach, James H beach@ku.edu:

We're about to release a new version of Specify, and we are looking to the broader community for some LSID architecture leadership.  We could use some interdisciplinary research use cases involving integration and resolution on specimen IDs, and implementation best practice type docs for guidance. So there is interest here.  Is there still the underlying community angst about LSIDs or DOIs?

I have a feeling there is either angst, or at least uninterest about them, as I haven't seen them discussed in a long time on the sem web mailing lists I am on, and the idea of HTTP URI's has been implemented by enough people to give (at least me) the impression of a critical mass of linked HTTP databases.

Interestingly, I think my project, Bio2RDF, still maintain an LSID authority/endpoint, but I have a feeling that internally we don't support LSID's very well as we haven't had anyone enquire about them for a long time.

Cheers,

Peter Ansell

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

-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org ] On Behalf Of Beach, James H Sent: Friday, 20 March 2009 11:32 a.m. To: Garry.Jolley-Rogers@csiro.au; hlapp@duke.edu; tdwg-tag@lists.tdwg.org Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG?

We're about to release a new version of Specify, and we are looking to the broader community for some LSID architecture leadership. We could use some interdisciplinary research use cases involving integration and resolution on specimen IDs, and implementation best practice type docs for guidance. So there is interest here. Is there still the underlying community angst about LSIDs or DOIs?

---

James H. Beach Biodiversity Institute University of Kansas 1345 Jayhawk Boulevard Lawrence, KS 66045, USA T 785 864-4645, F 785 864-5335

No engagement = No commitment.

-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org ] On Behalf Of Garry.Jolley-Rogers@csiro.au Sent: Thursday, March 19, 2009 5:15 PM To: hlapp@duke.edu; tdwg-tag@lists.tdwg.org Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG?

Hi Hilmar, Struggling with exactly these issues as I implement LSID's here.

It is a concern (especially given the underlying principles of permanence embodied in LSIDS) that the LSID project itself lacks resilience. Code can still be obtained tho' the documentation I can find is out of date and dependencies may be too. I'll know very soon - by the end of today. Like many things out there.. It seems to be withering now that the initial enthusiasm has died. While the collections community may think in centuries, permanence in LSIDS seems to mean a few years. Perhaps my google-fu has failed me.. If so please tell me.

My questions.... Is there sufficient interest and community involvement to keep it alive .... Even it is no more than an update documentation & co. Perhaps it should be brought into the TDWG fold? Any comments? Happy to contribute what I can.

GarryJR

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

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
.·'¯`·.¸ ><((((o> .·'¯`·.¸¸.·'¯`·.¸ .·'¯`·.¸¸.·'¯`·.¸ >=}}}}}}/o>
> <((((o>        ><((((o>


-----Original Message-----
From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org 
] On Behalf Of Hilmar Lapp
Sent: Friday, 20 March 2009 5:07 AM
To: Technical Architecture Group mailing list
Subject: [tdwg-tag] SourceForge LSID project websites broken

The websites for the two LSID projects on SourceForge are broken:

http://lsids.sourceforge.net/
http://lsid.sourceforge.net/

I believe the latter project is defunct (can someone confirm this?)  
but the first should be alive, right (and this URL is in fact linked  
to on the TDWG website).

Does anyone know what's going on?

       -hilmar

--
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:- hlapp at duke dot edu :
===========================================================




_______________________________________________
tdwg-tag mailing list
tdwg-tag@lists.tdwg.org
http://lists.tdwg.org/mailman/listinfo/tdwg-tag
_______________________________________________
tdwg-tag mailing list
tdwg-tag@lists.tdwg.org
http://lists.tdwg.org/mailman/listinfo/tdwg-tag
_______________________________________________
tdwg-tag mailing list
tdwg-tag@lists.tdwg.org
http://lists.tdwg.org/mailman/listinfo/tdwg-tag

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
_______________________________________________
tdwg-tag mailing list
tdwg-tag@lists.tdwg.org
http://lists.tdwg.org/mailman/listinfo/tdwg-tag

In fungi we have MycoBank and citing MB510023 (for Quambalaria coyrecup T. Paap 2008, for humans to read) and having a true GUID (not yet implemented) or LSID (implemented: http://lsid.tdwg.org/urn:lsid:indexfungorum.org:names:510023) 'underneath' is closer to the GenBank model which everyone accepts.

Paul

-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Gregor Hagedorn Sent: 23 March 2009 13:16 To: Roger Hyam Cc: Garry.Jolley-Rogers@csiro.au; Kevin Richards; Technical Architecture Group mailing list Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role forTDWG?

I agree with Roger about the technical side. LSIDs are largely for insiders with good IT support, preferably building their software themselves. In a way, there is a social business model associated with LSIDs: keep it a small and thus perhaps better manageable community. However this comes at the cost of excluding many initiatives, especially those relying on unmodified or only slightly modified standard software.

...

...

From biologists-social standpoint I would argue that:

urn:lsid:zoobank.org:act:8BDC0735-FEA4-4298-83FA-D04F67C3FBEC

is far harder than this:

http://purl.zoobank.org/8BDC0735-FEA4-4298-83FA-D04F67C3FBEC

which, socially, and for people who might want to cite identifiers in paper or PDF form, is harder than this:

http://persistent-id.zoobank.org/8BDC0735-FEA4-4298-83FA-D04F67C3FBEC or

http://persistent-identifier.zoobank.org/8BDC0735-FEA4-4298-83FA-D04F67C 3FBEC

I just try argue to speak to the communities outside of the inner technological circle, rather than saving a few characters.

These people may also be the managers, making it clear that this class of URLs need to be managed over longer time periods.

Gregor _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag ************************************************************************ The information contained in this e-mail and any files transmitted with it is confidential and is for the exclusive use of the intended recipient. If you are not the intended recipient please note that any distribution, copying or use of this communication or the information in it is prohibited.

Whilst CAB International trading as CABI takes steps to prevent the transmission of viruses via e-mail, we cannot guarantee that any e-mail or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions.

If you have received this communication in error, please notify us by e-mail at cabi@cabi.org or by telephone on +44 (0)1491 829199 and then delete the e-mail and any copies of it.

CABI is an International Organization recognised by the UK Government under Statutory Instrument 1982 No. 1071.

**************************************************************************

2009/3/31 Gregor Hagedorn g.m.hagedorn@gmail.com:

2009/3/23 Paul Kirk p.kirk@cabi.org:

...

In fungi we have MycoBank and citing MB510023 (for Quambalaria coyrecup T. Paap 2008, for humans to read) and having a true GUID (not yet implemented) or LSID (implemented: http://lsid.tdwg.org/urn:lsid:indexfungorum.org:names:510023) 'underneath' is closer to the GenBank model which everyone accepts.

Paul

Paul,

Who will educate all biologists about the difference between the lsids and their use? And I specifically mean the non-taxonomists that use species names. In "normal" resources like PDF published articles, html species pages, Drupal or Wiki-based information, urn:lsid:indexfungorum.org:names:510023 is useful only for human display. But it will be used.

http://lsid.tdwg.org/urn:lsid:indexfungorum.org:names:510023 will work as a clickable link to a web resource and can be read by semantic web machine reasoners. But to create this, external knowledge about resolution mechanism is expected from every biologist in the world. Some help material to be found somewhere may instruct them: if in your publication you want to create a link that is usable by humans or semantic web machine reasoners, you have to convert the lsid by prefixing it with http://lsid.tdwg.org/, http://lsid.gbif.org/, or perhaps lsid.ncbi.nlm.nih.gov/.

The mistrust in http current URL management practices is certainly valid. But this is a social issue, not a technical. The mistrust into http as a protocol I consider invalid: who is willing to bet that http will disappear before urn:lsid? And we would simply introduce resolver THEN (p2k5://http.tdwg.org/http://persistent-identifier.indexfungorum.org/names/510023).

I agree. The current Bio2RDF URI's, which look like mini-lsid's by design, could be resolved using a similar process, ie, p2k5://http://bio2rdf.org/names:510023 would be just as good a way to resolve http://bio2rdf.org/names:510023 as http://bio2rdf.org/urn:lsid:bio2rdf.org:names:510023 would be with the lsid urn:lsid:bio2rdf.org:names:510023

I have been doing some work on the Bio2RDF LSID resolution process today and it should be operating properly soon for the http://bio2rdf.org/urn:lsid:bio2rdf.org:* LSID URI resolutions. They were a bit neglected, as noone has been using them as far as I know and hence there were no bug reports to trigger my attention, but since there is still some interest we should have an alternative interface for use with LSID systems

Cheers,

Peter Ansell PhD Student Queensland University of Technology

I think it's one of the major failings of our community that we haven't dealt with the issue (both technically and socially) of providing stable, resolvable GUIDs for the things we care about, and that each major initiative that comes along (e.g., GBIF, EOL) says it's not their problem to solve. Creating shiny new web sites is obviously more fun, but by comparison with what the publishing industry has achieved with DOIs and CrossRef, we are a bunch of amateurs.

Regards

Rod

On 31 Mar 2009, at 14:33, Hilmar Lapp wrote:

On Mar 31, 2009, at 12:55 AM, Gregor Hagedorn wrote:

...

http://lsid.tdwg.org/urn:lsid:indexfungorum.org:names:510023 will work as a clickable link to a web resource and can be read by semantic web machine reasoners.

Incidentally, it doesn't because apparently the lsid.tdwg.org server is down.

If we imagine a biodiversity semantic web where all LSIDs are proxied through http://lsid.tdwg.org that server better be set up in a way that it won't easily take down everything with it whenever it has a hiccup. Is TDWG committed to creating and supporting that infrastructure?

-hilmar

=========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : ===========================================================

---

tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

--------------------------------------------------------- Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK

Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html

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, -- Renato

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

I certainly hope there is gain for the pain.

The crusty LSID code base is making me very grumpy. But I'd be even grumpier if TDWG were to switch to another GUID instead, so soon. Three years may count for as forever for some. Change management! Sure there are alternatives and some will be better... But at some point the cost of prior commitments trumps the benefits of change.

Rgds -- GarryJR

-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Kevin Richards Sent: Tuesday, 31 March 2009 12:46 PM To: renato@cria.org.br; tdwg-tag@lists.tdwg.org Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG?

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 :-)

Kevin

-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of renato@cria.org.br Sent: Tuesday, 31 March 2009 2:29 p.m. To: tdwg-tag@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, -- Renato

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@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

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 _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

I liked the '... wasn't ...' on the linkeddata.org page ... ;-)

You all have a good weekend,

Paul

________________________________

From: tdwg-tag-bounces@lists.tdwg.org on behalf of Peter DeVries Sent: Fri 03/04/2009 18:23 To: Garry.Jolley-Rogers@csiro.au; tdwg-tag@lists.tdwg.org Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role forTDWG?

I have several issues with LSIDs

1) I don't agree that life science data is "different" than geological, meteorological, or chemical data.

2) The persistence of LSID identifiers is as problematic as URL based identifiers. In fact, it is worse because

the system adds an additional layer of poorly supported standards that few people understand and

even fewer implement correctly.

3) LSIDs increase the implementation costs significantly beyond the costs required for domain registration and

a web server. For most implementations you will need a additional machine (virtual or otherwise) and someone

who understands the intricacies of LSIDs.

4) Tim Berners-Lee feels that LSIDs are unnecessary, and after spending several years looking at this issue I

think he is right. Even if TBL is wrong, you have positioned yourself for an uphill battle for adoption.

5) There is a well developed and widely adopted standard for integrating data sets developed by the

TBL and the linked data community that addresses the needs of the TDWG community.

For those who are not familiar with this initiative, check out the linked data site at: http://linkeddata.org/

and Tim Berners-Lee recent talk at TED http://www.ted.com/index.php/talks/tim_berners_lee_on_the_next_web.html

Respectfully,

- Pete

--------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 GeoSpecies Knowledge Base http://species.geospecies.org/ ------------------------------------------------------------

On Thu, Mar 19, 2009 at 5:14 PM, Garry.Jolley-Rogers@csiro.au wrote:

Hi Hilmar, Struggling with exactly these issues as I implement LSID's here. It is a concern (especially given the underlying principles of permanence embodied in LSIDS) that the LSID project itself lacks resilience. Code can still be obtained tho' the documentation I can find is out of date and dependencies may be too. I'll know very soon - by the end of today. Like many things out there.. It seems to be withering now that the initial enthusiasm has died. While the collections community may think in centuries, permanence in LSIDS seems to mean a few years. Perhaps my google-fu has failed me.. If so please tell me. My questions.... Is there sufficient interest and community involvement to keep it alive .... Even it is no more than an update documentation & co. Perhaps it should be brought into the TDWG fold? Any comments? Happy to contribute what I can. GarryJR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 .·'¯`·.¸ ><((((o> .·'¯`·.¸¸.·'¯`·.¸ .·'¯`·.¸¸.·'¯`·.¸ >=}}}}}}/o> ><((((o> ><((((o> -----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Hilmar Lapp Sent: Friday, 20 March 2009 5:07 AM To: Technical Architecture Group mailing list Subject: [tdwg-tag] SourceForge LSID project websites broken The websites for the two LSID projects on SourceForge are broken: http://lsids.sourceforge.net/ http://lsid.sourceforge.net/ I believe the latter project is defunct (can someone confirm this?) but the first should be alive, right (and this URL is in fact linked to on the TDWG website). Does anyone know what's going on? -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : =========================================================== _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

Find out about CABI's global summit on 'Food security in a climate of change' at www.cabiglobalsummit.com 19 - 21 October 2009, London, UK.

************************************************************************ The information contained in this e-mail and any files transmitted with it is confidential and is for the exclusive use of the intended recipient. If you are not the intended recipient please note that any distribution, copying or use of this communication or the information in it is prohibited.

Whilst CAB International trading as CABI takes steps to prevent the transmission of viruses via e-mail, we cannot guarantee that any e-mail or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions.

If you have received this communication in error, please notify us by e-mail at cabi@cabi.org or by telephone on +44 (0)1491 829199 and then delete the e-mail and any copies of it.

CABI is an International Organization recognised by the UK Government under Statutory Instrument 1982 No. 1071.

**************************************************************************

On Apr 3, 2009, at 1:23 PM, Peter DeVries wrote:

[...] 3) LSIDs increase the implementation costs significantly beyond the costs required for domain registration and a web server.

I think you'll find plenty of people who will argue that the cost of minting persistent GUIDs is much higher than the cost of a web server and domain registration in any event, and that it might be a Good Thing(tm) if an identifier system doesn't pretend otherwise.

[...] 4) Tim Berners-Lee feels that LSIDs are unnecessary, and after spending several years looking at this issue I think he is right. Even if TBL is wrong, you have positioned yourself for an uphill battle for adoption.

He has been wrong before. More to the point, I don't think this has to matter. In 1998 he would have probably said that DOIs are unnecessary. They may indeed be, from a technological standpoint, but from a social and business (sustainability) standpoint they've clearly been hugely successful. So I think the question that matters much more is, is there (or will there be) a similar ecosystem and environment for LSIDs that will make them equally useful. That's what I'm less sure about.

Also, I think we ought not to confuse one use-case for GUIDs (such as linked data) with the requirements for an identifier system for biodiversity.

-hilmar

BTW if anyone feels this is a long discussion that has been had before, check out the thread that begins with "registering info: uris" on the Code4Lib list (http://www.mail-archive.com/code4lib% 40listserv.nd.edu/) It turns out they struggle with similar questions (and also not for the first time), except in a library context, which might be much closer to a museum context than a semweb research community.

If LSIDs are to succeed for the biodiversity community they need a service with long term support from large organisations and projects.

DOIs have a business model. LSIDs currently do not. Without a business model (read funding) we should stick to something that doesn't have the implementation/adoption impediment of LSIDs and make the best of it (i.e. just have a usage policy for HTTP URIs).

The up coming e-Biosphere conference (June) is billed as an opportunity for the heads of the bigger projects to get together and decide what will happen for the next 10 years. If we are going to be using LSIDs in the future those heads need to agree to fund a DOI-like infrastructure for LSIDs or come out and say they are not prepared to do it.

TDWG can act as a forum for these projects/organisations to coordinate their actions but doesn't have its own resources.

I believe this is largely a political problem not a technical one. It needs to be resolved quickly.

Personally I hope that whatever we end up with is fully interoperable with the linked data movement as they are trying to do more or less exactly what we are trying to do . It may be worth reflecting on the fact that TBL et al are not telling us how to do biology they are telling us how to link data up. That doesn't make them right and us wrong but it is their field and not ours so maybe we should listen.

All the best,

Roger

On 3 Apr 2009, at 20:04, Peter DeVries wrote:

I think that the two initial comments are more about poking fun at the messenger than addressing the message, yes web pages have typo's and links between sites can be down. The connection problem seems to be on the University of Berlin end, not linked data.

My point is that this initiative has momentum and a number of enthusiastic followers, where is the momentum and where are the enthusiastic followers behind LSID's?

One of the standards in linked data is that URI's should not change and they have a number of good recommendations on how to mint them and persist them over time. Some of these would apply to minting LSID's.

It is one thing to design a standard or technology, it is quite another to get others to adopt and use it.

You might want to consider who has had more success in developing widely adopted standards Tim Berners-Lee or TDWG?

I may be relatively new to TDWG and Entomology but I am not new to biocomputing or the issues involved in developing tools or techniques that are widely adopted.

My assumption is that you want to develop a standard that is widely adopted, and that will involve addressing the concerns of potential adopters. My main needs involve tying species concepts to observations, environmental and other data. The TWDG standards have not been very helpful to me and the reliance on LSID's is one problem. Those implementations that are available do not really work. Does uBio deliver properly encoded data? No, at least not always.

• Pete

On Fri, Apr 3, 2009 at 12:54 PM, Hilmar Lapp hlapp@duke.edu wrote:

On Apr 3, 2009, at 1:23 PM, Peter DeVries wrote:

[...]

3. LSIDs increase the implementation costs significantly beyond the

costs required for domain registration and a web server.

I think you'll find plenty of people who will argue that the cost of minting persistent GUIDs is much higher than the cost of a web server and domain registration in any event, and that it might be a Good Thing(tm) if an identifier system doesn't pretend otherwise.

[...] 4) Tim Berners-Lee feels that LSIDs are unnecessary, and after spending several years looking at this issue I think he is right. Even if TBL is wrong, you have positioned yourself for an uphill battle for adoption.

He has been wrong before. More to the point, I don't think this has to matter. In 1998 he would have probably said that DOIs are unnecessary. They may indeed be, from a technological standpoint, but from a social and business (sustainability) standpoint they've clearly been hugely successful. So I think the question that matters much more is, is there (or will there be) a similar ecosystem and environment for LSIDs that will make them equally useful. That's what I'm less sure about.

Also, I think we ought not to confuse one use-case for GUIDs (such as linked data) with the requirements for an identifier system for biodiversity.

   -hilmar

BTW if anyone feels this is a long discussion that has been had before, check out the thread that begins with "registering info: uris" on the Code4Lib list (http://www.mail-archive.com/code4lib%40listserv.nd.edu/ ) It turns out they struggle with similar questions (and also not for the first time), except in a library context, which might be much closer to a museum context than a semweb research community.

--

: Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu :

--

Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706

---

---

tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

Persistence is much more than a domain name! Most data providers have a poor track record of being online (http://bioguid.info/status ), so it's going to need more than, say, €1000.

CrossRef works in part because there is a commitment to ensure the online content is available (i.e., the DOI when resolved actually delivers content). At present in our community nobody seems willing (or able) to make this commitment.

As Roger said

The up coming e-Biosphere conference (June) is billed as an opportunity for the heads of the bigger projects to get together and decide what will happen for the next 10 years. If we are going to be using LSIDs in the future those heads need to agree to fund a DOI- like infrastructure for LSIDs or come out and say they are not prepared to do it.

I wonder whether they are listening to / aware of this discussion?

Regards

Rod

On 6 Apr 2009, at 09:15, Schleidt Katharina wrote:

Hi all,

I admit I’m glad that this topic does seem to be back in discussion. I’ve been worried about LSIDs from the outset, but did not have the time or resources at the time of decision to do anything about it. Most of this discussion reflects what we’ve been discussing here in Vienna ever since the topic came up. Here an excerpt from a recent mail of mine:

· I have never been a proponent of LSIDs. More to the point, I have been against their adoption from the onset. The reasons for this are: o It’s misusing a technical solution as an answer for a social problem. Just because LSIDs entail a list of (quite necessary) requirements such as persistent IDs, dependability of availability of online references, it can in no way guarantee this, it just nicely covers the problem up o I do not see the technology being supported. IBM dropped it, and Cambridge Semantics Inc. also seems to have gone other ways o An example of the lack of dependability of LSID servers seems to me to be the eternal problem with the TDWG LSID Server o I’m worried about a group such as TDWG, which doesn’t have the backup to push through technology development, is going towards requiring all adopters to implement non-mainstream technology in order to maintain compatibility

We’ve come to the conclusion, as mentioned several times in this thread, that what we really need is the commitment to persistence, and no technology will support us in that. Why waste nonexistent funds sorting out an esoteric technology nobodies supporting; why not just buy a domain, pass a hat and set up a trust fund with 1000€ (or $), and agree to have this domain available over some institution (i.e. university) for the next 100 years. After that, my non-existent great-grandchildren can sort out the rest!

@Matt: http://www4.wiwiss.fu-berlin.de/bizer/pub/lod-datasets_2009-03-05.html is online again! And a short absence/down-time will happen in all distributed technologies. If anything, I believe that we should worry more about intelligent caching and harvesting mechanisms!

:)

kathi

Von: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org ] Im Auftrag von Roger Hyam Gesendet: Freitag, 03. April 2009 21:40 An: Peter DeVries Cc: tdwg-tag@lists.tdwg.org Betreff: Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG?

If LSIDs are to succeed for the biodiversity community they need a service with long term support from large organisations and projects.

DOIs have a business model. LSIDs currently do not. Without a business model (read funding) we should stick to something that doesn't have the implementation/adoption impediment of LSIDs and make the best of it (i.e. just have a usage policy for HTTP URIs).

The up coming e-Biosphere conference (June) is billed as an opportunity for the heads of the bigger projects to get together and decide what will happen for the next 10 years. If we are going to be using LSIDs in the future those heads need to agree to fund a DOI- like infrastructure for LSIDs or come out and say they are not prepared to do it.

TDWG can act as a forum for these projects/organisations to coordinate their actions but doesn't have its own resources.

I believe this is largely a political problem not a technical one. It needs to be resolved quickly.

Personally I hope that whatever we end up with is fully interoperable with the linked data movement as they are trying to do more or less exactly what we are trying to do . It may be worth reflecting on the fact that TBL et al are not telling us how to do biology they are telling us how to link data up. That doesn't make them right and us wrong but it is their field and not ours so maybe we should listen.

All the best,

Roger

On 3 Apr 2009, at 20:04, Peter DeVries wrote:

I think that the two initial comments are more about poking fun at the messenger than addressing the message, yes web pages have typo's and links between sites can be down. The connection problem seems to be on the University of Berlin end, not linked data.

My point is that this initiative has momentum and a number of enthusiastic followers, where is the momentum and where are the enthusiastic followers behind LSID's?

One of the standards in linked data is that URI's should not change and they have a number of good recommendations on how to mint them and persist them over time. Some of these would apply to minting LSID's.

It is one thing to design a standard or technology, it is quite another to get others to adopt and use it.

You might want to consider who has had more success in developing widely adopted standards Tim Berners-Lee or TDWG?

I may be relatively new to TDWG and Entomology but I am not new to biocomputing or the issues involved in developing tools or techniques that are widely adopted.

My assumption is that you want to develop a standard that is widely adopted, and that will involve addressing the concerns of potential adopters. My main needs involve tying species concepts to observations, environmental and other data. The TWDG standards have not been very helpful to me and the reliance on LSID's is one problem. Those implementations that are available do not really work. Does uBio deliver properly encoded data? No, at least not always.

• Pete

On Fri, Apr 3, 2009 at 12:54 PM, Hilmar Lapp hlapp@duke.edu wrote:

On Apr 3, 2009, at 1:23 PM, Peter DeVries wrote: [...]

3. LSIDs increase the implementation costs significantly beyond the

costs required for domain registration and a web server.

I think you'll find plenty of people who will argue that the cost of minting persistent GUIDs is much higher than the cost of a web server and domain registration in any event, and that it might be a Good Thing(tm) if an identifier system doesn't pretend otherwise. [...] 4) Tim Berners-Lee feels that LSIDs are unnecessary, and after spending several years looking at this issue I think he is right. Even if TBL is wrong, you have positioned yourself for an uphill battle for adoption.

He has been wrong before. More to the point, I don't think this has to matter. In 1998 he would have probably said that DOIs are unnecessary. They may indeed be, from a technological standpoint, but from a social and business (sustainability) standpoint they've clearly been hugely successful. So I think the question that matters much more is, is there (or will there be) a similar ecosystem and environment for LSIDs that will make them equally useful. That's what I'm less sure about.

Also, I think we ought not to confuse one use-case for GUIDs (such as linked data) with the requirements for an identifier system for biodiversity.

   -hilmar

BTW if anyone feels this is a long discussion that has been had before, check out the thread that begins with "registering info: uris" on the Code4Lib list (http://www.mail-archive.com/code4lib%40listserv.nd.edu/ ) It turns out they struggle with similar questions (and also not for the first time), except in a library context, which might be much closer to a museum context than a semweb research community.

--

: Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu :

--

Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706

---

---

tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

---

tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

--------------------------------------------------------- Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK

Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html

I've tried to stay out of this discussion out of respect for the large amount of work the TDWG has already put into this issue, and the sentiment I've heard expressed that everyone is sick of the argument and revisiting it would be fatiguing and unpleasant. I only pipe in now because... well, forgive me.

My opinion is that while the TimBL / linked data vision may be a plausible one for the "living web" made from web sites, databases, and services that are continuously maintained and corrected, it is not so good for the archival use case, where a document is stored for ten or twenty years and then needs to be understood. Both use cases occur in the practice of science but it's important to understand that they're different and lead to different requirements. In the "living" case it does not matter so much what the identifier system (domain name, etc.) is since it can be changed if it stops working. (Persistence is not a big part of the linked data story.) In the archival case you need to be much more careful in placing your bets.

But don't let the existence of flakey http: URIs make you throw *all* of them away. http: URIs are neither more nor less viable as persistent identifiers than any other kind of identifier. The syntax of the string is not the issue; what's important is the level of commitment behind the identifier system. urn:lsid:, http: , and doi: all show extreme variability as far as that goes - in each syntactic category, some identifiers have a good chance of being understandable in the future, and some don't.

In our work at Science Commons we're using http: mainly because its resolution protocol is so widely deployed, leading to lovely unintended consequences such as the Internet Archive and Google. But persistence is hard regardless of the identifier scheme. For an example of an attempt to arrange for http: persistence for one particular application see http://sharedname.org/.

Whether the choice is urn:lsid: or http:, the important thing for persistence is to make sure some supporting infrastructure exists for the long haul. (Yes, that is a tautology.) That is not really a syntactic or technical problem.

Jonathan

On Apr 3, 2009, at 1:23 PM, Peter DeVries wrote:

I have several issues with LSIDs

1. I don't agree that life science data is "different" than

geological, meteorological, or chemical data.

2. The persistence of LSID identifiers is as problematic as URL

based identifiers. In fact, it is worse because the system adds an additional layer of poorly supported standards that few people understand and even fewer implement correctly.

3. LSIDs increase the implementation costs significantly beyond the

costs required for domain registration and a web server. For most implementations you will need a additional machine (virtual or otherwise) and someone who understands the intricacies of LSIDs.

4. Tim Berners-Lee feels that LSIDs are unnecessary, and after

spending several years looking at this issue I think he is right. Even if TBL is wrong, you have positioned yourself for an uphill battle for adoption.

5. There is a well developed and widely adopted standard for

integrating data sets developed by the TBL and the linked data community that addresses the needs of the TDWG community.

For those who are not familiar with this initiative, check out the linked data site at: http://linkeddata.org/

and Tim Berners-Lee recent talk at TED http://www.ted.com/index.php/talks/tim_berners_lee_on_the_next_web.html

Respectfully,

• Pete

---

Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 GeoSpecies Knowledge Base

---

On Thu, Mar 19, 2009 at 5:14 PM, Garry.Jolley-Rogers@csiro.au wrote: Hi Hilmar, Struggling with exactly these issues as I implement LSID's here.

It is a concern (especially given the underlying principles of permanence embodied in LSIDS) that the LSID project itself lacks resilience. Code can still be obtained tho' the documentation I can find is out of date and dependencies may be too. I'll know very soon - by the end of today. Like many things out there.. It seems to be withering now that the initial enthusiasm has died. While the collections community may think in centuries, permanence in LSIDS seems to mean a few years. Perhaps my google-fu has failed me.. If so please tell me.

My questions.... Is there sufficient interest and community involvement to keep it alive .... Even it is no more than an update documentation & co. Perhaps it should be brought into the TDWG fold? Any comments? Happy to contribute what I can.

GarryJR

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

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
.·'¯`·.¸ ><((((o> .·'¯`·.¸¸.·'¯`·.¸ .·'¯`·.¸¸.·'¯`·.¸ >=}}}}}}/o>
             ><((((o>        ><((((o>


-----Original Message-----
From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org 
] On Behalf Of Hilmar Lapp
Sent: Friday, 20 March 2009 5:07 AM
To: Technical Architecture Group mailing list
Subject: [tdwg-tag] SourceForge LSID project websites broken

The websites for the two LSID projects on SourceForge are broken:

http://lsids.sourceforge.net/
http://lsid.sourceforge.net/

I believe the latter project is defunct (can someone confirm this?)
but the first should be alive, right (and this URL is in fact linked
to on the TDWG website).

Does anyone know what's going on?

       -hilmar

--
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:- hlapp at duke dot edu :
===========================================================




_______________________________________________
tdwg-tag mailing list
tdwg-tag@lists.tdwg.org
http://lists.tdwg.org/mailman/listinfo/tdwg-tag
_______________________________________________
tdwg-tag mailing list
tdwg-tag@lists.tdwg.org
http://lists.tdwg.org/mailman/listinfo/tdwg-tag

_______________________________________________
tdwg-tag mailing list
tdwg-tag@lists.tdwg.org
http://lists.tdwg.org/mailman/listinfo/tdwg-tag