April 2009 - tdwg-tag - lists.tdwg.org

FYI: SharedNames
by Roger Hyam 10 Apr '09

10 Apr '09

You may be interested in this project to set up PURLs for biomedical resources http://sharedname.org/page/Main_Page

1 0

Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG?
by Donald.Hobern＠csiro.au 09 Apr '09

09 Apr '09

Thanks, Kathi. I appreciate your comments and understand your concerns. This certainly is a social problem - no technology solution will take it away. A large proportion (though certainly not all) of the issues surrounding LSIDs will arise with any technology which tries to address the problem. I seem to be in the minority in believing that we can use LSIDs as one part of a strategy to develop a community infrastructure for our data. However we do need to start from somewhere if we want to do anything about the persistence of our data. We need some foundations before we can properly worry about "intelligent caching and harvesting mechanisms" (which I agree we need). So - here is my outline for how I think we could move forward from these discussions: 1. An identifier scheme which aims to provide some long term persistence probably needs to embody at least three key facts: who generated/published the data object, what data collection this object belongs to, which data object from the specified data collection this one is. These correspond roughly to the Darwin Core InstitutionCode/CollectionCode/CatalogueNumber triple and to the three main substitutable elements in an LSID. Some systems such as DOI may obscure the whoGeneratedTheData part somewhat. Some systems such as DOI and PURL may not always have an explicit whatCollectionItBelongsTo part, but dealing with collections promises to be an organisational simplification for most purposes. 2. TDWG should recommend the LSID as one suitable model for constructing GUIDs (i.e. "urn:lsid:<whoGeneratedTheDataObject>:<whatCollectionItBelongsTo>:<whichItemInTheCollectionItIs>"). We could propose (or adopt) some other syntax for this, but this gives us a neat enough way to encapsulate what we need to know. The "urn:lsid:" part can be seen as a useful flag that this is indeed to be considered as an identifier. 3. Where feasible, TDWG should recommend that these LSIDs should be associated with a resolver implementing the standard LSID mechanism. Frankly I am a lot less bothered by the resolvability of most identifiers than I am about their consistent use, so I have no problem with the idea of assigning LSIDs to things which do not currently resolve. 4. TDWG requires that a path must exist to retrieve the associated data using an HTTP resolver to proxy the LSID (i.e. http://whoGeneratedTheDataObject.org/<optional_path_elements>/<lsid>) and that our practice is to consider this proxified version to be identical for comparison purposes with the bare LSID. For LSIDs resolvable using the standard LSID mechanism, this path can be http://lsid.tdwg.org/<lsid>. In cases in which the data are only accessible via HTTP, we have broken the LSID specification - although it seems there may be nobody other than us to care about that fact. 5. All references to LSIDs within RDF documents should use the proxified form. 6. TDWG and its partners should establish a PURL-like service which makes it easy to register data sets to be associated with identifiers of this form. In other words, a service should exist (around a domain secured for this purpose into the future) which associates data providers with an appropriate whoGeneratedTheDataObject element and associates their data collections with an appropriate whatCollectionItBelongsTo element and associated URL pattern for retrieving RDF data for the individual data objects. The exact details could vary, but assume that TDWG sets up this service at http://lsid.tdwg.org/ and that CSIRO wishes to register the ANIC data collection and to have individual specimen records associated with LSID-based identifiers. Assume further that ANIC has a script on its servers which can return the RDF data for these specimens, say at http://www.csiro.au/anic/specimens/<catalogueNumber>. The registration process could result in the LSID urn:lsid:tdwg.org:csiro.anic:12345 and the HTTP URI http://lsid.tdwg.org/urn:lsid:tdwg.org:csiro.anic:12345 both being mapped through to http://www.csiro.au/anic/specimens/12345. It would probably be preferable for the LSID in this case to be urn:lsid:csiro.tdwg.org:anic:12345 (which would make relocation of all LSID services for a single data provider easy, but could require large numbers of SRV records to be managed by TDWG). (I would note that it would be easy for the infrastructure to allow the data provider to choose whether the whole LSID or just the final ID element should be passed to the final URL.) 7. TDWG and its partners should use this same infrastructure to handle alternative resolution paths as required in the future - if alternative identifier schemes become the preferred option. This infrastructure could also add significant other functions, including e.g. 1) intelligent caching of data, 2) validation of RDF data, and 3) simultaneous registration of DOIs associated with metadata for each data collection to make it easier for them to be cited by journal articles. 8. Any provider may opt at any time to use alternative HTTP-resolvable identifiers in place of LSIDs (e.g. DOIs, handles, PURLs), but must consider the technological and social implications of keeping these identifiers alive into the future. As far as I can see, this approach allows us to develop a community-based approach to managing identifiers in a way which builds on LSIDs for those who have already minted them. It would be easy for us to reinvent this as a PURL-based approach in the future. The costs should not be great and it gives us a better chance of avoiding the confusion of random-URLs-pointing-at-random-data-formats being offered as semantically useful GUIDs. Whatever happens, TDWG needs to finalise an applicability statement for how LSIDs should be used by those providers who have chosen or who will choose to use them for biodiversity data. This does not mandate that everyone MUST use LSIDs. Does this seem worth pursuing? Donald Donald Hobern, Director, Atlas of Living Australia CSIRO Entomology, GPO Box 1700, Canberra, ACT 2601 Phone: (02) 62464352 Mobile: 0437990208 Email: Donald.Hobern(a)csiro.au Web: http://www.ala.org.au/ -----Original Message----- Date: Mon, 6 Apr 2009 10:15:00 +0200 From: Schleidt Katharina <katharina.schleidt(a)umweltbundesamt.at> Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG? To: Roger Hyam <rogerhyam(a)mac.com>, Peter DeVries <pete.devries(a)gmail.com> Cc: "tdwg-tag(a)lists.tdwg.org" <tdwg-tag(a)lists.tdwg.org> Message-ID: <8638F29270898544933A7663226809E5EAAA6060(a)PCMAIL3.umweltbundesamt.at> Content-Type: text/plain; charset="utf-8" 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

10 16

Cyberinfrastructure Summer Internships for data repository interoperability: application deadline reminder
by Hilmar Lapp 07 Apr '09

07 Apr '09

*** Please disseminate widely to students at your institution *** CYBERINFRASTRUCTURE SUMMER INTERNSHIPS 2009 - REMINDER: Student Application Deadline is April 13, 2009 http://hackathon.nescent.org/ Cyberinfrastructure_Summer_Traineeships_2009 Summer training internships are available for up to four students and postdocs interested in informatics as applied to scientific data in such fields as biodiversity, ecology, and evolutionary biology. The program provides a unique opportunity for undergraduate, masters, and PhD students as well as postdocs to obtain hands-on experience writing and extending open-source software as part of a distributed collaborative software development team building a Virtual Data Center (VDC) that includes major data and metadata repositories in those fields. The application deadline for students (April 13, 2009) is approaching rapidly. Trainees accepted into the program will receive a stipend ($4,500), and with the exception of attending one meeting near the beginning and one near the end of the 3-month program period may work from their home, or home institution. Travel costs incurred in connection with the meetings will be reimbursed. Each student will have at least one dedicated mentor to show them the ropes and help them complete their project. Initial project ideas are listed on the website. These range from validation of metadata and identifier resolution, to supporting LSID and semantic-web compliant PURLs for digital data objects, to implementing modern web-service APIs, to cataloging the diversity of metadata schemas. The project ideas are flexible and can be adjusted in scope to match the skills of the student. We also welcome novel project ideas that dovetail with student interests. The program is supported by a National Science Foundation (NSF) grant to a consortium of major repositories for biodiversity, earth and environmental, ecological, and evolutionary science. The consortium includes the LTER Network Office, the U.S. Geological Survey, NASA and Oak Ridge National Laboratory, the Global Biodiversity Information Facility (GBIF), the National Evolutionary Synthesis Center(NESCent), and the National Center for Ecological Analysis and Synthesis (NCEAS). It aims to develop the cyberinfrastructure and technologies necessary to build a Virtual Data Center (VDC) based on a network of existing and new physical repositories ("nodes") that interoperate using open standards and protocols. The network will enable discovery of as well as open, stable, and secure access to data in any of its member nodes. TO APPLY: Students apply online. Instructions for applying are at the website (see "When you apply"), along with program rules and eligibility requirements. The 15-day application period for students end on Monday, April 13th, 2009. INQUIRIES: vdc-twg {at} ecoinformatics {dot} org. We strongly encourage all interested students to get in touch with us with their ideas as early as possible. Cyberinfrastructure Traineeships Website: http://hackathon.nescent.org/ Cyberinfrastructure_Summer_Traineeships_2009 To sign up for quarterly NESCent newsletters: http://www.nescent.org/ about/contact.php --------- Todd Vision and Hilmar Lapp National Evolutionary Synthesis Center http://nescent.org

1 0

Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG?
by Eamonn O Tuama (GBIF) 07 Apr '09

07 Apr '09

Dear All, GBIF recognises the need for a system of persistent, unique identifiers for biodiversity objects. Its strategic work plan (2007-2011) defines an activity to develop a system of globally unique identifiers and encourage their use throughout biodiversity informatics, and within the IDA (Inventory Discovery Access) work area for the 2009-2011 work programme, the stated aims include convening an LSID Task Group to review the status of LSID uptake and devise a strategy for wide deployment of LSIDs or other GUIDs. The related functions of inventory, discovery and access are being brought together by GBIF through its Global Biodiversity Resources Discovery System (GBRDS) at the heart of which lies an extended UDDI registry linked to a metadata cataloguing system. We have some immediate needs for GUIDs/LSIDs in the implementation of the GBRDS. In addition, the ECAT work area sees a role for GBIF in the global resolution of LSIDs that refer to taxon names and the DIGIT work area has identified several facets of data mobilisation and use where GUIDs are essential, e.g., as a key element in data publication, and in attribution, citation and tracking of data use. Moreover, several GBIF Participants have expressed a commitment in moving ahead with deployment of LSIDs and are looking to the GBIF Secretariat to provide leadership and essential services. To that end, we have already begun to explore internally a role for GBIF as an LSID hosting/proxy service along the lines being advocated by Donald (Hobern). Now, because of the perceived urgency and confusion/uncertainty around the future of LSIDs, and more generally, the social/institutional challenges of providing stable and persistent GUIDs, GBIF is fast-forwarding the convening of an LSID Task Group to explore the issues and offer recommendations on the way forward, with particular reference to the GBIF network. A call for participation will be issued later this month and we expect the task group to be convened and operational within about four weeks. Best regards, Éamonn _______________________________________________ Éamonn Ó Tuama, M.Sc., Ph.D. (eotuama(a)gbif.org), Senior Programme Officer, Inventory, Discovery, Access (IDA), Global Biodiversity Information Facility Secretariat, Universitetsparken 15, DK-2100 Copenhagen Ø, DENMARK Phone: +45 3532 1494; Fax: +45 3532 1480 -----Original Message----- From: tdwg-tag-bounces(a)lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of tdwg-tag-request(a)lists.tdwg.org Sent: 07 April 2009 10:39 To: tdwg-tag(a)lists.tdwg.org Subject: tdwg-tag Digest, Vol 36, Issue 9 Send tdwg-tag mailing list submissions to tdwg-tag(a)lists.tdwg.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.tdwg.org/mailman/listinfo/tdwg-tag or, via email, send a message with subject or body 'help' to tdwg-tag-request(a)lists.tdwg.org You can reach the person managing the list at tdwg-tag-owner(a)lists.tdwg.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tdwg-tag digest..." Today's Topics: 1. Re: SourceForge LSID project websites broken - role for TDWG? (Donald.Hobern(a)csiro.au) 2. Re: SourceForge LSID project websites broken - role for TDWG? (Hilmar Lapp) 3. Re: SourceForge LSID project websites broken - role for TDWG? (Donald.Hobern(a)csiro.au) 4. Re: SourceForge LSID project websites broken - role for TDWG? (Roger Hyam) ---------------------------------------------------------------------- Message: 1 Date: Tue, 7 Apr 2009 15:55:04 +1000 From: <Donald.Hobern(a)csiro.au> Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG? To: <tdwg-tag(a)lists.tdwg.org> Message-ID: <FF7DEDBD2B38B34F94139214D371B9C4290872EC(a)exvic-mbx05.nexus.csiro.au> Content-Type: text/plain; charset="us-ascii" Thanks, Kathi. I appreciate your comments and understand your concerns. This certainly is a social problem - no technology solution will take it away. A large proportion (though certainly not all) of the issues surrounding LSIDs will arise with any technology which tries to address the problem. I seem to be in the minority in believing that we can use LSIDs as one part of a strategy to develop a community infrastructure for our data. However we do need to start from somewhere if we want to do anything about the persistence of our data. We need some foundations before we can properly worry about "intelligent caching and harvesting mechanisms" (which I agree we need). So - here is my outline for how I think we could move forward from these discussions: 1. An identifier scheme which aims to provide some long term persistence probably needs to embody at least three key facts: who generated/published the data object, what data collection this object belongs to, which data object from the specified data collection this one is. These correspond roughly to the Darwin Core InstitutionCode/CollectionCode/CatalogueNumber triple and to the three main substitutable elements in an LSID. Some systems such as DOI may obscure the whoGeneratedTheData part somewhat. Some systems such as DOI and PURL may not always have an explicit whatCollectionItBelongsTo part, but dealing with collections promises to be an organisational simplification for most purposes. 2. TDWG should recommend the LSID as one suitable model for constructing GUIDs (i.e. "urn:lsid:<whoGeneratedTheDataObject>:<whatCollectionItBelongsTo>:<whichItem InTheCollectionItIs>"). We could propose (or adopt) some other syntax for this, but this gives us a neat enough way to encapsulate what we need to know. The "urn:lsid:" part can be seen as a useful flag that this is indeed to be considered as an identifier. 3. Where feasible, TDWG should recommend that these LSIDs should be associated with a resolver implementing the standard LSID mechanism. Frankly I am a lot less bothered by the resolvability of most identifiers than I am about their consistent use, so I have no problem with the idea of assigning LSIDs to things which do not currently resolve. 4. TDWG requires that a path must exist to retrieve the associated data using an HTTP resolver to proxy the LSID (i.e. http://whoGeneratedTheDataObject.org/<optional_path_elements>/<lsid>) and that our practice is to consider this proxified version to be identical for comparison purposes with the bare LSID. For LSIDs resolvable using the standard LSID mechanism, this path can be http://lsid.tdwg.org/<lsid>. In cases in which the data are only accessible via HTTP, we have broken the LSID specification - although it seems there may be nobody other than us to care about that fact. 5. All references to LSIDs within RDF documents should use the proxified form. 6. TDWG and its partners should establish a PURL-like service which makes it easy to register data sets to be associated with identifiers of this form. In other words, a service should exist (around a domain secured for this purpose into the future) which associates data providers with an appropriate whoGeneratedTheDataObject element and associates their data collections with an appropriate whatCollectionItBelongsTo element and associated URL pattern for retrieving RDF data for the individual data objects. The exact details could vary, but assume that TDWG sets up this service at http://lsid.tdwg.org/ and that CSIRO wishes to register the ANIC data collection and to have individual specimen records associated with LSID-based identifiers. Assume further that ANIC has a script on its servers which can return the RDF data for these specimens, say at http://www.csiro.au/anic/specimens/<catalogueNumber>. The registration process could result in the LSID urn:lsid:tdwg.org:csiro .anic:12345 and the HTTP URI http://lsid.tdwg.org/urn:lsid:tdwg.org:csiro.anic:12345 both being mapped through to http://www.csiro.au/anic/specimens/12345. It would probably be preferable for the LSID in this case to be urn:lsid:csiro.tdwg.org:anic:12345 (which would make relocation of all LSID services for a single data provider easy, but could require large numbers of SRV records to be managed by TDWG). (I would note that it would be easy for the infrastructure to allow the data provider to choose whether the whole LSID or just the final ID element should be passed to the final URL.) 7. TDWG and its partners should use this same infrastructure to handle alternative resolution paths as required in the future - if alternative identifier schemes become the preferred option. This infrastructure could also add significant other functions, including e.g. 1) intelligent caching of data, 2) validation of RDF data, and 3) simultaneous registration of DOIs associated with metadata for each data collection to make it easier for them to be cited by journal articles. 8. Any provider may opt at any time to use alternative HTTP-resolvable identifiers in place of LSIDs (e.g. DOIs, handles, PURLs), but must consider the technological and social implications of keeping these identifiers alive into the future. As far as I can see, this approach allows us to develop a community-based approach to managing identifiers in a way which builds on LSIDs for those who have already minted them. It would be easy for us to reinvent this as a PURL-based approach in the future. The costs should not be great and it gives us a better chance of avoiding the confusion of random-URLs-pointing-at-random-data-formats being offered as semantically useful GUIDs. Whatever happens, TDWG needs to finalise an applicability statement for how LSIDs should be used by those providers who have chosen or who will choose to use them for biodiversity data. This does not mandate that everyone MUST use LSIDs. Does this seem worth pursuing? Donald Donald Hobern, Director, Atlas of Living Australia CSIRO Entomology, GPO Box 1700, Canberra, ACT 2601 Phone: (02) 62464352 Mobile: 0437990208 Email: Donald.Hobern(a)csiro.au Web: http://www.ala.org.au/ -----Original Message----- Date: Mon, 6 Apr 2009 10:15:00 +0200 From: Schleidt Katharina <katharina.schleidt(a)umweltbundesamt.at> Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG? To: Roger Hyam <rogerhyam(a)mac.com>, Peter DeVries <pete.devries(a)gmail.com> Cc: "tdwg-tag(a)lists.tdwg.org" <tdwg-tag(a)lists.tdwg.org> Message-ID: <8638F29270898544933A7663226809E5EAAA6060(a)PCMAIL3.umweltbundesamt.at> Content-Type: text/plain; charset="utf-8" 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 ------------------------------ Message: 2 Date: Tue, 7 Apr 2009 02:54:15 -0400 From: Hilmar Lapp <hlapp(a)duke.edu> Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG? To: Donald.Hobern(a)csiro.au Cc: tdwg-tag(a)lists.tdwg.org Message-ID: <0FEBAE72-265D-4499-ABBA-D2D8D7B2F839(a)duke.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On Apr 7, 2009, at 1:55 AM, Donald.Hobern(a)csiro.au wrote: > Assume further that ANIC has a script on its servers which can > return the RDF data for these specimens, say at http://www.csiro.au/anic/specimens/ > <catalogueNumber>. The registration process could result in the > LSID urn:lsid:tdwg.org:csiro.anic:12345 Wouldn't that say according to your proposed usage guideline that tdwg.org is whoGeneratedTheData and csiro.anic is whatCollectionItBelongsTo, when in reality CSIRO generated the data and ANIC is the collection it belongs to? I understand why you're suggesting the LSID formatted as you do, and you might say that the name-mangling isn't too drastic. But don't have data owners a strong sense of ownership in their data objects and in their collections? And more importantly, don't you think that a usage guideline that contradicts itself (or that is bound to be internally inconsistent) will continue to raise debate and be in the way of broader adoption? > and the HTTP URI http://lsid.tdwg.org/urn:lsid:tdwg.org:csiro.anic:12345 > both being mapped through to http://www.csiro.au/anic/specimens/ > 12345. Wouldn't http://purl.tdwg.org/CSIRO/ANIC/12345 be shorter, do more justice to the names of whoGeneratedTheData and whatCollectionItBelongsTo, be easier to implement, and have the same possibilities to implement caching etc, in fact using standard software such as mod_proxy for apache? Just some thoughts. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : =========================================================== ------------------------------ Message: 3 Date: Tue, 7 Apr 2009 17:17:59 +1000 From: <Donald.Hobern(a)csiro.au> Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG? To: <hlapp(a)duke.edu> Cc: tdwg-tag(a)lists.tdwg.org Message-ID: <FF7DEDBD2B38B34F94139214D371B9C4290872EF(a)exvic-mbx05.nexus.csiro.au> Content-Type: text/plain; charset="us-ascii" Thanks, Hilmar. I agree that using tdwg.org as the authority for the LSID is less than ideal - hence my recommendation later that we should consider instead using e.g. csiro.tdwg.org (and I don't think it should be tdwg.org - perhaps something more neutral like csiro.bio-id.org. My concern there was the proliferation of SRV records if we support the LSID protocol. You are also correct that the big issue with this is the question of ownership. Quite frankly, if we had believed in 2006 that institutions would be prepared to cede responsibility for handling their identifiers to a third party, the recommendations from the TDWG workshops would probably have been rather different. Part of the reason for adopting LSIDs was because institutions did not seem to want to use an identifier which might imply that a third-party was responsible for the data. The PURL form would have some benefits and would be a perfectly consistent alternative. I seem to be the only person who wants to avoid an outright capitulation to using HTTP URIs to identify objects in our domain. However, in case anyone cares, here again are my reasons why I prefer HTTP-wrapped non-HTTP identifiers over plain HTTP URIs: 1. The "urn:lsid:" part of the identifier serves as a clear statement of intent which is not present with an HTTP URI. We could mandate that ONLY http://purl.tdwg.org/ URIs count as GUIDs in our domain and that e.g. http://www.csiro.au/ URIs cannot do so, but that seems an arrogant and arbitrary rule. However, if we simply encourage everyone to use PURL URIs from any domain, what separates such a URI from any HTTP URL with no planned persistence? I see this as a short cut to casual assignment of volatile identifiers based on web application structures and hence to rapid identifier rot. 2. I still feel intense discomfort (pace the W3C) over adopting identifiers prefixed HTTP:// for objects such as type specimens which have had an important place in the literature for decades and which can expect still to be referenced in 50 years time. Even though the HTTP protocol feels like the air we breathe right now, it seems certain to be superseded at some point. Do we want to use identifiers which will seem totally "retro" in the future? The usual objection is that HTTP is certain to outlast the LSID protocol. I agree fully, but the urn: prefix is making a statement about naming, not about technology. If I am alone in these feelings, the suggested PURL route may be simpler, but we should consider what can be done to maximise the robustness of their use. Best wishes, Donald Donald Hobern, Director, Atlas of Living Australia CSIRO Entomology, GPO Box 1700, Canberra, ACT 2601 Phone: (02) 62464352 Mobile: 0437990208 Email: Donald.Hobern(a)csiro.au Web: http://www.ala.org.au/ -----Original Message----- From: Hilmar Lapp [mailto:hlapp@duke.edu] Sent: Tuesday, 7 April 2009 4:54 PM To: Hobern, Donald (Entomology, Black Mountain) Cc: tdwg-tag(a)lists.tdwg.org Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG? On Apr 7, 2009, at 1:55 AM, Donald.Hobern(a)csiro.au wrote: > Assume further that ANIC has a script on its servers which can > return the RDF data for these specimens, say at http://www.csiro.au/anic/specimens/ > <catalogueNumber>. The registration process could result in the > LSID urn:lsid:tdwg.org:csiro.anic:12345 Wouldn't that say according to your proposed usage guideline that tdwg.org is whoGeneratedTheData and csiro.anic is whatCollectionItBelongsTo, when in reality CSIRO generated the data and ANIC is the collection it belongs to? I understand why you're suggesting the LSID formatted as you do, and you might say that the name-mangling isn't too drastic. But don't have data owners a strong sense of ownership in their data objects and in their collections? And more importantly, don't you think that a usage guideline that contradicts itself (or that is bound to be internally inconsistent) will continue to raise debate and be in the way of broader adoption? > and the HTTP URI http://lsid.tdwg.org/urn:lsid:tdwg.org:csiro.anic:12345 > both being mapped through to http://www.csiro.au/anic/specimens/ > 12345. Wouldn't http://purl.tdwg.org/CSIRO/ANIC/12345 be shorter, do more justice to the names of whoGeneratedTheData and whatCollectionItBelongsTo, be easier to implement, and have the same possibilities to implement caching etc, in fact using standard software such as mod_proxy for apache? Just some thoughts. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : =========================================================== ------------------------------ Message: 4 Date: Tue, 07 Apr 2009 09:38:44 +0100 From: Roger Hyam <rogerhyam(a)mac.com> Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG? To: Donald.Hobern(a)csiro.au Cc: tdwg-tag(a)lists.tdwg.org Message-ID: <98A9FFDD-FCEF-47BF-83C2-146E21EF51AB(a)mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Just hosting SRV records or supplying a redirect service does not actually provide any persistence at all to the data/metadata. Persistence of a GUID to 500 error rather than a not found is not helpful. I have said in the past "If persistence is important to you then keep your own copy." This is how it has worked for 100s of years in the library community. If the reason for having a centralised resolution mechanism is to try and support persistence then the centralised service should actually cache metadata (not data). I would imagine a scalable infrastructure would be quite simple to implement. Data could be stored in a Lucene index or Hadoop cluster or something. It would only be a very large hash table and only keep the latest version of the RDF. Without some kind of persistence mechanism the only advantage of LSIDs is that they *look* like they are supposed to be persistent. Unfortunately, because many people are using UUIDs as their object identifiers LSIDs actually look like something you wouldn't want to look at let alone expose to a user! CoL actually hide them because they look like this: urn:lsid:catalogueoflife.org:taxon:d755ba3e-29c1-102b-9a4a-00304854f820:ac20 09 No normal person is going to read this or type it in. I am afraid that when people started using UUIDs in LSIDs it blew the sociological argument for LSIDs out of the water for me. I had carefully designed BCI identifiers to be human readable and writable like this: urn:lsid:biocol.org:col:15670 Which would work as a foot note in a paper but only way a UUID can work in that context is if it is hyperlinked and to be hyperlinked it will have to be an HTTP URL underneath which begs the question of why we are displaying a non human readable string as the human readable part of a hyperlink! So we hide the LSID completely and have no sociological advantage. I understand why people used UUIDs. There are good technical reasons especially in distributed systems. If LSIDs are a brand then they need a "unique selling proposition" and that implies something behind them beyond what can be had for free from other brands. You must use LSIDs because.... "We recommend them" is not an adequate answer. Another point that worries me is that all discussion of LSIDs is about how to publish them not how to consume them. LSIDs are better than HTTP URIs for the client because... (I still can't answer this question) Currently the reason for me tagging my data with GUIDs has to be because it enables users to access and exploit my data in cost effective ways they couldn't before whilst crediting me with producing it so that I can attract funding to my organisation to curate and collect more data. The reason for clients using GUIDs is that it enables them to mix and match data in ways they couldn't before so as to produce more, higher quality scientific publications and so attract funding and kudo. These are the selling points for GUIDs. How well do LSIDs enable them? To summarise this overlong post we have to have a service that adds *real value* (of an order of magnitude that crossref adds to DOIs) to LSID usage. Without this we are better off sticking with todays standard web technologies. Sorry for so many words. I don't have time to write less today. Roger On 7 Apr 2009, at 08:17, Donald.Hobern(a)csiro.au wrote: > Thanks, Hilmar. > > I agree that using tdwg.org as the authority for the LSID is less > than ideal - hence my recommendation later that we should consider > instead using e.g. csiro.tdwg.org (and I don't think it should be > tdwg.org - perhaps something more neutral like csiro.bio-id.org. My > concern there was the proliferation of SRV records if we support the > LSID protocol. > > You are also correct that the big issue with this is the question of > ownership. Quite frankly, if we had believed in 2006 that > institutions would be prepared to cede responsibility for handling > their identifiers to a third party, the recommendations from the > TDWG workshops would probably have been rather different. Part of > the reason for adopting LSIDs was because institutions did not seem > to want to use an identifier which might imply that a third-party > was responsible for the data. > > The PURL form would have some benefits and would be a perfectly > consistent alternative. I seem to be the only person who wants to > avoid an outright capitulation to using HTTP URIs to identify > objects in our domain. However, in case anyone cares, here again > are my reasons why I prefer HTTP-wrapped non-HTTP identifiers over > plain HTTP URIs: > > 1. The "urn:lsid:" part of the identifier serves as a clear > statement of intent which is not present with an HTTP URI. We could > mandate that ONLY http://purl.tdwg.org/ URIs count as GUIDs in our > domain and that e.g. http://www.csiro.au/ URIs cannot do so, but > that seems an arrogant and arbitrary rule. However, if we simply > encourage everyone to use PURL URIs from any domain, what separates > such a URI from any HTTP URL with no planned persistence? I see > this as a short cut to casual assignment of volatile identifiers > based on web application structures and hence to rapid identifier rot. > > 2. I still feel intense discomfort (pace the W3C) over adopting > identifiers prefixed HTTP:// for objects such as type specimens > which have had an important place in the literature for decades and > which can expect still to be referenced in 50 years time. Even > though the HTTP protocol feels like the air we breathe right now, it > seems certain to be superseded at some point. Do we want to use > identifiers which will seem totally "retro" in the future? The > usual objection is that HTTP is certain to outlast the LSID > protocol. I agree fully, but the urn: prefix is making a statement > about naming, not about technology. > > If I am alone in these feelings, the suggested PURL route may be > simpler, but we should consider what can be done to maximise the > robustness of their use. > > Best wishes, > > Donald > > > Donald Hobern, Director, Atlas of Living Australia > CSIRO Entomology, GPO Box 1700, Canberra, ACT 2601 > Phone: (02) 62464352 Mobile: 0437990208 > Email: Donald.Hobern(a)csiro.au > Web: http://www.ala.org.au/ > > > -----Original Message----- > From: Hilmar Lapp [mailto:hlapp@duke.edu] > Sent: Tuesday, 7 April 2009 4:54 PM > To: Hobern, Donald (Entomology, Black Mountain) > Cc: tdwg-tag(a)lists.tdwg.org > Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - > role for TDWG? > > > On Apr 7, 2009, at 1:55 AM, Donald.Hobern(a)csiro.au wrote: > >> Assume further that ANIC has a script on its servers which can >> return the RDF data for these specimens, say at http://www.csiro.au/anic/specimens/ >> <catalogueNumber>. The registration process could result in the >> LSID urn:lsid:tdwg.org:csiro.anic:12345 > > Wouldn't that say according to your proposed usage guideline that > tdwg.org is whoGeneratedTheData and csiro.anic is > whatCollectionItBelongsTo, when in reality CSIRO generated the data > and ANIC is the collection it belongs to? > > I understand why you're suggesting the LSID formatted as you do, and > you might say that the name-mangling isn't too drastic. But don't have > data owners a strong sense of ownership in their data objects and in > their collections? And more importantly, don't you think that a usage > guideline that contradicts itself (or that is bound to be internally > inconsistent) will continue to raise debate and be in the way of > broader adoption? > >> and the HTTP URI http://lsid.tdwg.org/urn:lsid:tdwg.org:csiro.anic:12345 >> both being mapped through to http://www.csiro.au/anic/specimens/ >> 12345. > > > Wouldn't http://purl.tdwg.org/CSIRO/ANIC/12345 be shorter, do more > justice to the names of whoGeneratedTheData and > whatCollectionItBelongsTo, be easier to implement, and have the same > possibilities to implement caching etc, in fact using standard > software such as mod_proxy for apache? > > Just some thoughts. > > -hilmar > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : > =========================================================== > > > > > _______________________________________________ > tdwg-tag mailing list > tdwg-tag(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-tag ------------------------------ _______________________________________________ tdwg-tag mailing list tdwg-tag(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag End of tdwg-tag Digest, Vol 36, Issue 9 ***************************************

1 0

SourceForge LSID project websites broken
by Hilmar Lapp 06 Apr '09

06 Apr '09

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

14 27

Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG?
by Donald.Hobern＠csiro.au 01 Apr '09

01 Apr '09

Some thoughts on where I think we should be going with LSIDs... My take is still that having something that is a standard identifier scheme is a major benefit and it is not a big stretch for us to recognise that <ResolverURL><Identifier> should be considered the same as <Identifier> for purposes of inferring identity. I still believe that it would be a total disaster for us simply to say that we advocate the use of PURL-style identifiers, since this is a slippery slope with no separation between a good identifier and a web-server-du-jour URL with no planned persistence. Vince Smith's blog is a reminder that relying even on institutional domain names is risky. I believe that we need to get behind providing solid infrastructure for LSIDs. This should be aimed at making it as easy as possible for any provider to set up LSIDs without touching their own DNS records unless they want to do so. We should have a central service which does the central registration part of what DOI.org does for DOIs, BUT NOT AT THE LEVEL OF INDIVIDUAL LSIDs. We are trying to establish something like this here in Australia under the taxonomy.org.au domain. This could be done at a global, national or community level. What is needed is simply the following: 1. A trusted party (TDWG, GBIF, EOL, ALA, etc.) commits to handle the DNS resolution side of LSIDs for any data providers wishing to use its services. 2. Any provider can register a dataset with the trusted party and will receive a corresponding LSID namespace to use in their identifiers. To register the dataset they need to be able to provide a parameterised URL which takes a single parameter - either the full LSID for the record, or just the final record-id part of the LSID (this could be a configuration choice when registering the data set) - and which returns the corresponding data record as RDF (if we don't drive the use of structured data with GUIDs, we are not solving anything, but there could be an option to return the records to the trusted party in some simpler format and for the trusted party to generate the RDF). 3. The trusted party registers itself in DNS as the resolver for LSIDs for its domain and hosts a resolver implementation which extracts the LSID namespace from LSIDs and forwards the request to the appropriate data provider with either the record-id or the whole LSID as a parameter. The trusted party also hosts an HTTP LSID proxy and prepends the proxy URL to all identifiers in RDF documents. A working example with TDWG as the trusted party and an NHM Sphingidae data set as the data set to be shared. A. TDWG registers lsid.tdwg.org in DNS as an LSID service. B. NHM registers a TAPIR database (or whatever CGI interface they like) for their Sphingidae database using the namespace "nhm.sphingidae" and the endpoint "http://nhm.ac.uk/tapir/sphingidae?op=s&...&darwin:GUID=%S" (where %S is to be replaced with the actual request GUID). C. NHM populates its records with GUID values of the pattern "urn:lsid:lsid.tdwg.org:nhm.sphingidae:<record-id>" D. A user follows a link http://lsid.tdwg.org/urn:lsid:lsid.tdwg.org:nhm.sphingidae:12345 and hits the LSID resolver. The LSID resolver maps "nhm.sphingidae" to the NHM endpoint and requests the record, which it then returns to the user. This could be enhanced in many different ways to make it more robust and flexible: 1. As mentioned, the trusted party could map other formats to RDF (indeed it could have templates for embedding data in Darwin Core, etc.). 2. The trusted party could automatically prepend LSIDs in response data with references to its own proxy so that early 21st century WWW technology works as expected. 3. The trusted party could add additional services around hosted copies of the data and could manage a metadata record for the resource. 4. The trusted party could in fact use DOIs for the namespace part (in other words the NHM example would end up using something like urn:lsid.tdwg.org:10.1000/987:12345 as the identifier. If the 10.1000/987 DOI served as a citable identifier for the dataset and could be resolved to get the metadata for the dataset, it could be elegant on several different levels. This is really all so easy. As mentioned, taxonomy.org.au has been going through the teething pains of doing this for an Australian therevid data set held in Mandala in Illinois. I would hope that we could quickly roll this out as a service for any Australian data providers and then try deploying a similar set-up with TDWG, GBIF or EOL. At least that's what I think... One other basic point is that, if we abandon LSIDs and still want a GUID solution with some promise that the data could be relocated, we need a system which somewhere embeds the concepts of provider, dataset and record and can use these to track down the record. This means we can't allow a total free-for-all on identifiers and need either a robust heavy central registry of records like DOI or need to have a standard place for these three elements in the GUID. Once we get that far, we may as well adopt LSIDs even if we choose (as the major party using the model) to extend or even replace the models for resolving them. Donald Donald Hobern, Director, Atlas of Living Australia CSIRO Entomology, GPO Box 1700, Canberra, ACT 2601 Phone: (02) 62464352 Mobile: 0437990208 Email: Donald.Hobern(a)csiro.au Web: http://www.ala.org.au/ -----Original Message----- From: tdwg-tag-bounces(a)lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of renato(a)cria.org.br Sent: Tuesday, 31 March 2009 12:29 PM To: tdwg-tag(a)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(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag

7 8