March 2009 - tdwg-tag - lists.tdwg.org

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

Cyberinfrastructure Summer Traineeships for data repository interoperability
by Hilmar Lapp 29 Mar '09

29 Mar '09

*** Please disseminate widely to students at your institution *** CYBERINFRASTRUCTURE SUMMER TRAINEESHIPS 2009 VIRTUAL DATA CENTER FOR BIODIVERSITY, EARTH, ECOLOGICAL, AND EVOLUTIONARY SCIENCE DATA http://hackathon.nescent.org/Cyberinfrastructure_Summer_Traineeships_2009 Summer traineeships are available for up to four students and postdocs interested in informatics as applied to scientific data ranging from the fields of 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. 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 traineeships are 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 opens on Monday March 30th and runs through 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 2009 NESCent Phyloinformatics Summer of Code (NESCent's participation in the Google Summer of Code; managed separately; postdocs not eligible; ***student application period ends April 3rd***) http://hackathon.nescent.net/Phyloinformatics_Summer_of_Code_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

Thoughts on TDWG hackathon after NESCent Hackathon
by Roger Hyam 24 Mar '09

24 Mar '09

Hi Everyone, I had the pleasure of attending the NESCent Hackathon on Evolutionary Database Interoperability the week before last https://www.nescent.org/wg_evoinfo/Database_Interop_Hackathon and I said before hand that I would report back on my thoughts for holding similar hackathons within TDWG. This is a very quick summary of those thoughts. My overriding impression was that the success of the event was based on the preparation that went in before hand. * Firstly the NESCent team did a really good job of organising the hackathon and dedicated considerable resources to it. * The hackathon was focussed on three technologies; CDAO, NeXML and PhyloWS. * There was a pre-meeting for the core team and there were two conference calls which most of the participants were involved in. * The wiki was used to work up some test cases and various documentation before the hackathon started. * There were mailing list discussions. Personally I had a great time and learned a great deal. I had the impression that others had a similar experience. I think we pushed things forward a great deal and came up with some code that may be useful. If we were to do a similar TDWG hackathon I think it would be a good idea to focus down on one or two technologies. Perhaps identify a single challenge that faces us - an obstacle that needs to be crossed. We would have to find resources to pay not only for getting everyone in the same room with the right level of IT support but also to pay for some one to administer the run up and wind down to the whole thing. These are critical. Without them I believe we'd be wasting our time. Getting the balance right between letting people follow their own ideas and pushing everyone in the same direction is also very important. The open question of "How do you integrate what you are working on at the moment with the subject of the hackathon?" might be a good place to start. I think the TDWG developer community could really benefit from a similar hackathon provided it was well funded and run. All the best, Roger ----------------------------------------------------- Roger Hyam - Project Officer WP4 Pan European Species Infrastructure +44 75 90 60 80 16 -----------------------------------------------------

1 0

Some Comments on implementing LSID's
by Garry.Jolley-Rogers＠csiro.au 23 Mar '09

23 Mar '09

Hi Kevin, Thanks. I'm very glad to hear that tdwg support for LSID's is active and look forward to learning more at Montpellier (** please Jim? ;) ). If I had known then I was to be implementing LSIDs now, I would have grabbed you in Perth @ the conference. I don't agree that the technical issues are all minor (though they may seem so in retrospect) - especially not minor in the context of variable institutional I.T. infrastructure. However, in Australia we have committed to following the TDWG standard i.e. using LSIDs, so it would be more helpful for us if we could solve the problems associated with LSIDs instead of continuing to revisit other options which would seem to have already been ruled out by TDWG's own endorsement of LSIDs. GUID's are supposed to be things that have some permanence. Implicit in this is the need for stability and support. I am happy to contribute as I well as I can. #1 DNS implementation ... A trivial change not necessarily trivial to implement. If you have control your own DNS then no problem but for LSID's to be adopted broadly they need to be used by institutions. It took a lot of effort to get our network people to make the appropriate changes to the CSIRO DNS. This surprised me (it was such a simple small change) but in retrospect it's no surprise at all. After all, corporate network admins are necessarily conservative in outlook as they are managing risk. In their eye, all nonstandard things are suspicious and require a full business case (= months of delay). I had to work hard to convince them to make a one line change (with only minor delay). If the network geeks don't get it then .... #2 Old code base. My google-fu may have foiled me in this. But the code base (perl/java for my platform) & instructions are > 2-3 years is old. This adds more potential points of failure for the novice implementer to worry over (versions of dependencies & co.). If left untended this will be a growing problem as versions and dependencies change further or are deprecated (as they eventually will be). GarryJR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Garry.Jolley-Rogers(a)csiro.au <mailto:Garry.Jolley-Rogers@csiro.au> Biodiversity Informatics, Taxonomy Research & Information Network Centre for Plant Biodiversity Research, CSIRO Plant Industry, GPO Box 1600, Canberra ACT 2601 AUSTRALIA w:(02) 62465501 http://www.cpbr.gov.au/cpbr/staff/jolley-rogers-staff.html <http://www.cpbr.gov.au/cpbr/staff/jolley-rogers-staff.html> .·'¯`·.¸ ><((((o> .·'¯`·.¸¸.·'¯`·.¸ .·'¯`·.¸¸.·'¯`·.¸ >=}}}}}}/o> ><((((o> ><((((o>

2 1

Re: [tdwg-tag] SourceForge LSID project websites broken
by Hilmar Lapp 19 Mar '09

19 Mar '09

What I was looking for was the nice overview, historical context etc information that used to be there on the homepage: http://web.archive.org/web/20080124135843/http://lsids.sourceforge.net/ My guess is that it's all still there, except that some configuration bit now upsets the sf.net software or something similar. -hilmar On Mar 19, 2009, at 4:41 PM, phil cryer wrote: > I think the site can still be found here: > http://sourceforge.net/projects/lsids > > With text from the page available on IA: > http://web.archive.org/web/20080116013106rn_1/sourceforge.net/project/showf… > > > From that we can put together the following dowloads links: > > Download LSID Browser for Firefox > LSID Perl Toolkit - 1.1.7 > Last Update: Nov 12 2007 > http://downloads.sourceforge.net/lsids/lsid-1.0.1.xpi?use_mirror=superb-eas… > http://sourceforge.net/project/downloading.php?group_id=198923&filesize=472… > > > LSID Perl Toolkit > Latest 1.1.7 Notes (2007-11-12 05:27) > lsid-perl-1.1.7.tar.gz Mirror 180925 5 Platform-Independent .gz > http://downloads.sourceforge.net/lsids/lsid-perl-1.1.7.tar.gz?modtime=11948… > > > On Thu, Mar 19, 2009 at 3:15 PM, Kevin Richards > <RichardsK(a)landcareresearch.co.nz> wrote: >> Hilmar >> The main developer of the lsids web site is no longer concentrating >> on that task, and the site has therefore been down for a while. >> We are in the process of moving the site to a TDWG server, which >> will solve the issue. This task is relying on the volunteer work >> of a few individuals that need to jump technical hurdles, and so >> make take a little while. Bear with us. >> >> Kevin Richards >> >> >> -----Original Message----- >> From: tdwg-tag-bounces(a)lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org >> ] On Behalf Of Hilmar Lapp >> Sent: Friday, 20 March 2009 7:07 a.m. >> 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(a)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(a)lists.tdwg.org >> http://lists.tdwg.org/mailman/listinfo/tdwg-tag >> -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : ===========================================================

1 0

Fwd: OGC Spec [SEC=UNCLASSIFIED]
by greg whitbread 19 Mar '09

19 Mar '09

Brought to my attention by Stan & Lee: http://www.opengeospatial.org/standards/requests/55 This RFC for a standard standard has direct relevance for this group. Comments on the relationship between this RFC and DCMI Singapore framework ( http://dublincore.org/documents/singapore-framework ) would be appreciated. greg ---------- Forwarded message ---------- From: Lee Belbin <leebel(a)netspace.net.au> Date: 2009/3/18 Subject: OGC Spec [SEC=UNCLASSIFIED] To: ghw(a)anbg.gov.au Hi Greg Stan just told me about this http://xml.coverpages.org/OGC-ModularSpecifications.html. Do you want to post anything about this to the TAG? It certainly looks interesting. They are still big on UML. Lee Lee Belbin TDWG Secretariat ------ If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. Please consider the environment before printing this email. ------ -- Greg Whitbread Australian National Botanic Gardens Australian National Herbarium +61 2 62509482 ghw(a)anbg.gov.au

1 0