October 2008 - tdwg-tag - lists.tdwg.org

Future management of the TAG
by Roger Hyam 02 Nov '08

02 Nov '08

Dear All, As mentioned in an earlier email I intend to stand down as convener of the TAG this year. The TDWG constitution does not specify how subgroups should select their conveners though it is presumed by most people I consulted that all such decisions should be made on the basis of consensus. During TDWG 2008 we had a number of discussions concerning how we should move forward and have come up with the suggestion below. We were very aware that not everyone in the TAG was present at TDWG 2008 and so this is just a suggestion to be put to the wider group through the mailing list with an opportunity for people to feed back. If you agree or disagree please make your comments as soon as possible. Either write to the list or to me personally. If no major disagreement is found the changes below will take effect as of 21 November 2008 The new convener of the TAG will be Greg Whitbread (ANBG). Greg will take a high level coordinating roll and will be assisted by volunteers who take particular responsibility for areas in which their projects have a vested interest. Markus Döring (GBIF) will lead development of the ontology with a focus on the needs for occurrence data and checklist integration by GBIF. Patrick Leary (EoL) will feed in requirements from the Encyclopedia of Life species pages perspective. Kevin Richards (Landcare NZ) will head up development of GUIDs and Tim Robertson (GBIF) will help with the DNS infrastructure for the SRV records associated with LSID roll out. Renato De Giovanni (CRIA) will continue to head up protocols in the form of his work on TAPIR although he may be limited to the amount of time he can spend because of other commitments. Personally I still intend to be involved in TDWG and will contribute as time permits. All the best, Roger ------------------------------------------------------------- Roger Hyam Roger(a)BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ -------------------------------------------------------------

2 1

Re: [tdwg-tapir] Updates and plans
by "Markus Döring (GBIF)" 16 Oct '08

16 Oct '08

Dear all, I would like to discuss the optional bits of TAPIR capabilities again in the light of service interoperability, especially when dealing with TAPIR lite. Do we really need to have so many optional capabilities for TAPIR? I do firmly think this is causing more problems than benefits and would prefer more mandatory capabilities. In particular I think TAPIR model support should be the lowest common denominator and not only templates as it is currently for TAPIR lite. Do the following capabilities really need to optional? - the inventory and search operation is optional. Is there a need for services not supporting them? - any need for inventory operations not to support anyConcept? - search operation should mandate at least 1 output model support - cant concept, literal and parameter expressions in filters be mandatory? - likewise cant logical operators and equals comparisons be mandatory filter parts? what about greaterThan and lessThan? regards, Markus On Oct 6, 2008, at 16:14, Markus Döring (GBIF) wrote: > Renato, > all proposals sound valuable and good to me. Working on my new TAPIR > implementation I would like to propose another change. > What do you think of removing the TAPIR lite option altogether and > mandate tapir model support via KVP as the lowest option for > compliant TAPIR services? > I would at least have a discussion around this subject, as it > effects TAPIR interoperability in networks a lot. And I think you > didn't feel too comfortable when I said GBIF will implement > TAPIRlite only. I am thinking of implementing model based TAPIR now > because I see too many interoperability problems. > > what do you think? can we put this on the agenda for discussion at > least? > Markus > > > > On Oct 6, 2008, at 15:14, Renato De Giovanni wrote: > >> Dear all, >> >> As mentioned in the last message, I created a new page in the Wiki to >> document possible changes in the protocol: >> >> http://wiki.tdwg.org/twiki/bin/view/TAPIR/PossibleChanges >> >> Please feel free to add your comments or suggest other changes. Use >> the >> Wiki or the mailing list. >> >> If we decide to make any changes, they will be the last ones before >> submitting TAPIR to the TDWG standards track. I would also like to >> suggest >> October 31st as the deadline to decide about this. >> >> Best Regards, >> -- >> Renato >> >> >>> Dear all, >>> >>> I finally managed to update the TAPIR specification to reflect the >>> last >>> issues discussed in this mailing list: >>> >>> http://www.tdwg.org/dav/subgroups/tapir/1.0/docs/TAPIRSpecification_2008-09… >>> >>> I also updated the network builders' guide to include references >>> to the >>> new resources (TapirTester and TapirBuilder) and to recommend the >>> new CNS >>> encoding in XML instead of the old text file: >>> >>> http://www.tdwg.org/dav/subgroups/tapir/1.0/docs/TAPIRNetworkBuildersGuide_… >>> >>> The official links are already redirecting to these documents. >>> >>> I think it's time to consider submitting TAPIR to the TDWG standards >>> track, but my feeling is that we should first wait for the annual >>> meeting >>> since we're close to it anyway. There's no subgroup meeting >>> planned for >>> TAPIR this year, but the TDWG annual meeting is always an >>> opportunity for >>> most people here to interact and to see if there are any specific >>> improvements we should still make in the protocol. >>> >>> I've been taking notes of additional changes that we could >>> possibly make >>> before finishing version 1.0. I'll try to organize this in the >>> Wiki during >>> the next days and I'll give you the link. We can then revise the >>> list of >>> possible changes and decide together what we should do. >>> >>> Please let me know if you have any ideas about this. I think we >>> should >>> definitely finish TAPIR 1.0 this year and try to make it a TDWG >>> standard. >>> >>> Best Regards, >>> -- >>> Renato >> >> >> _______________________________________________ >> tdwg-tapir mailing list >> tdwg-tapir(a)lists.tdwg.org >> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir >> >

4 5

TDWG TAG Roadmap final plus meeting agenda
by Roger Hyam 15 Oct '08

15 Oct '08

I have now PDFerated the TAG Roadmap 2008. It is linked to from the wiki page here: http://wiki.tdwg.org/twiki/bin/view/TAG/RoadMap2008 The direct link to the PDF is here: http://wiki.tdwg.org/twiki/pub/TAG/RoadMap2008/TDWG_TAG_Roadmap_2008.pdf Please circulate this document widely. I have turned the wiki page into an agenda for the Fremantle meeting and kicked it off with some contentious (or not) agenda items. Please add/modify the agenda and add your name to the attendees list if you intend coming along. I look forward to seeing those of you who can make it. All the best, Roger ------------------------------------------------------------- Roger Hyam Roger(a)BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ -------------------------------------------------------------

1 0

RESTful TAG meeting in Fremantle?
by Roger Hyam 13 Oct '08

13 Oct '08

My attention finally comes back round to preparing the TAG Roadmap. Following our discussions on REST I have added a short section to the Roadmap. You can read it here: http://wiki.tdwg.org/twiki/bin/view/TAG/RoadMap2008#REST_Services This may be seen as controversial so please read it. Notably I say "HTTP should be thought of as the universal syntax for addressable resources. " I will convert this page to PDF in about 24 hours time so please speak now if you have issues. Markus has pointed out that we don't have a formal meeting of the TAG booked for Fremantle. There is a free slot on Sunday 19th 0900-1300 (Notre Dame University Education Centre room 36.103) and I have requested the room. If we get the room we it will give us a venue to meet up but it is unfortunately parallel to several other meetings: http://www.tdwg.org/conference2008/program/ It might also be worth having a brief meeting at the end of the conference to round up whether anything that has been presented affects the TAG position. Any thoughts? Roger ------------------------------------------------------------- Roger Hyam Roger(a)BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ -------------------------------------------------------------

1 0

Recent DiGIR service disruption
by Dave Vieglais 08 Oct '08

08 Oct '08

Apologies for cross posting. Hopefully, most of you did not notice this, but if you did, here's what happened. A problem with resolving the digir.net domain was recently identified by John Wieczorek and possibly others. This problem would have affected most, if not all DiGIR providers currently operating. Once identified, the issue was promptly resolved, and ongoing problems are unlikely. This message provides further information about the problem, how it was resolved, and how recurrence will be avoided to ensure continued operation of the DiGIR infrastructure. = Problem = The DNS entry "digir.net" is an A record that must point to an IP address. For several years digir.net resolved to the ip address of "66.35.250.210" which is a Source Forge machine that is configured as a VHOST for digir.net. At some point in the last 48hrs, 66.35.250.210 ceased to respond as a VHOST for digir.net. This meant that any web service that was expecting to retrieve content from digir.net (e.g. http://digir.net/schema/protocol/2003/1.0/digir.xsd ) failed, with significant operational repercussions. For technical reasons, most other digir.net DNS entries were unaffected (e.g. www.digir.net ). = Resolution = The new Source Forge VHOST servicing www.digir.net was identified as "216.34.181.97", and the DNS entry for digir.net was updated appropriately. Since the TTL on that DNS record was set relatively short (600 seconds), the DNS infrastructure picked up the new information fairly quickly, and testing indicates that digir.net URLs are now being correctly resolved from several locations around the world. = What You Need To Do = Nothing. You should not notice any ongoing disruption. = Ensuring Continued Operation = There are three major issues that lead to this malfunction (#2 and #3 are informational only for developers of new services and tools): 1. We have no control over Source Forge, and nor should digir.net infrastructure be dependent on them 2. Much of the existing installed DiGIR infrastructure references "digir.net" directly and so DNS level indirection is not practical. 3. HTTP redirects need to be supported in service implementations and their clients. I suspect that a lot of DiGIR software services and clients do not follow redirects properly. == Issue #1 == A DNS monitoring service is now in place that will update the DNS entries if the source forge machine changes again. Also, a replica of the DiGIR web material currently hosted by Source Forge is being created on a machine that we have complete control over and is located on a fast internet backbone. The replica machine will be monitored with a system that will provide automatic notification to appropriate contacts in the event of failure. This machine will be located at the University of Kansas at least initially. Once operational, the DNS entry for digir.net will be modified to point to this machine. DNS services are handled by dyndns.org. Since their inception they have provided a 100% uptime for their clients which includes domains such as CNN, Mozilla, and Twitter. Since digir.net was an early adopter of their services, the DNS service provided by DynDNS does not expire. DNS registration does expire however, and this relatively minor expense is covered by the University of Kansas with assistance from the National Science Foundation. == Issue #2 == In retrospect, something like "http://schema.digir.net" rather than "http://digir.net " should have been used. This would have provided a low level (DNS) mechanism for indirection that would have been unaffected by this unanticipated hardware change. Altering these entries in DiGIR providers and tools is really not practical at this stage, so it is unlikely that this issue can be directly addressed. == Issue #3 == HTTP offers a mechanism for temporary and permanent redirection. In order to take advantage of this functionality, it is necessary for HTTP clients to properly interpret the HTTP 301 and 307 status codes and the respective response headers to determine the new location of the resource being resolved. This is the mechanism employed by PURLs and TinyURL for example. Unfortunately, many developers take short cuts when building tools to retrieve content from URLs and avoid the additional small amount of work necessary to handle redirect messages. Where ever possible, developers of services and clients should use libraries that at least properly handle HTTP redirects which will allow the use of PURLs and other mechanisms for providing an additional level of indirection in URL resolution where necessary. regards, Dave Vieglais --- Biodiversity Research Center University of Kansas

3 2

State of biodiversity services
by Roderic Page 07 Oct '08

07 Oct '08

The rather frail nature of biodiversity services (some of the major players have had service breaks in the last few weeks) has prompted me to revisit Dave Vieglais's BigDig and extend it to other services, such as uBio, EOL, and TreeBASE, as well as DSpace repositories and tools such as Connotea. The result is at http://bioguid.info/status/ . The idea is to poll each service once an hour to see if it is online. Eventually I hope to draw some graphs for each service, to get some idea of how reliable it is. Much of my own work depends on using web sites and services, and I'm constantly frustrated when they go offline (some times for months at a time). My aim is to be constructive. I well aware that reliability is not easy, and some tools that I've developed have disappeared. But I think as a community we need to do a lot better if biodiversity informatics is to deliver on its promise. The list of service is biased by what I use. I'm also aware that some of the DiGIR provider information is out of date (I basically lifted the list from the BigDig, I'll try and edit this as time allows). Comments (and requests for services to be added) are welcome. There is a comment box at the bottom of the web page. Regards Rod --------------------------------------------------------- Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK Email: r.page(a)bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962(a)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

1 0

Where to put LSIDs on tdwg ontology objects
by Bob Morris 06 Oct '08

06 Oct '08

In our GBIF/EOL/Plazi SPM project, Terry Catapano and I have formed the conclusion (I hope wrong...) that there is not any place on several lsidvoc objects to hang an lsid (or any other GUID) asserted to identify that object. For example, we don't see any place to put one on a TaxonConcept or on a PublicationCitation. In the October 1 example at http://wiki.tdwg.org/twiki/bin/view/SPM/PlaziEOLProject we have a placeholder hack using <tc:TaxonConcept rdf:ID="_tc2"> <tc:nameString xml:lang="en">Dodous bispinosus</tc:nameString> <tc:hasInformation rdf:resource="urn:lsid:biosci.ohio-state.edu:osuc_concepts:143647"/> ... </tc:TaxonConcept> but this is not valid in the tdwg ontology because hasInformation requires an InfoItem as its object. We use other objects that face this problem, e.g. TaxonName, and I guess it is quite a broad issue (or not an issue at all if we are wrong). Can someone recommend a valid way to address this, either for these three objects, or preferably, in general? If so, thanks in advance. If we are right, how about adding an InfoItem class named GUID, that includes an enumeration of the usual suspects, suitably typed. Bob - Robert A. Morris Professor of Computer Science UMASS-Boston ram(a)cs.umb.edu http://bdei.cs.umb.edu/ http://www.cs.umb.edu/~ram http://www.cs.umb.edu/~ram/calendar.html phone (+1)617 287 6466

3 8

[tdwg-tapir] Updates and plans
by Renato De Giovanni 06 Oct '08

06 Oct '08

Dear all, I finally managed to update the TAPIR specification to reflect the last issues discussed in this mailing list: http://www.tdwg.org/dav/subgroups/tapir/1.0/docs/TAPIRSpecification_2008-09… I also updated the network builders' guide to include references to the new resources (TapirTester and TapirBuilder) and to recommend the new CNS encoding in XML instead of the old text file: http://www.tdwg.org/dav/subgroups/tapir/1.0/docs/TAPIRNetworkBuildersGuide_… The official links are already redirecting to these documents. I think it's time to consider submitting TAPIR to the TDWG standards track, but my feeling is that we should first wait for the annual meeting since we're close to it anyway. There's no subgroup meeting planned for TAPIR this year, but the TDWG annual meeting is always an opportunity for most people here to interact and to see if there are any specific improvements we should still make in the protocol. I've been taking notes of additional changes that we could possibly make before finishing version 1.0. I'll try to organize this in the Wiki during the next days and I'll give you the link. We can then revise the list of possible changes and decide together what we should do. Please let me know if you have any ideas about this. I think we should definitely finish TAPIR 1.0 this year and try to make it a TDWG standard. Best Regards, -- Renato

2 3

TAG Roadmap for 2008 - Job vacancy!
by Roger Hyam 03 Oct '08

03 Oct '08

Dear TAG Member, With kind support from others I have now pulled together what I believe is the text for the 2008 Roadmap. I will polish this some more but do not plan to change it radically. This will be presented to the conference in Fremantle next month as the output of the TAG. http://wiki.tdwg.org/twiki/bin/view/TAG/RoadMap2008 Please take a few moments to read this through and edit or comment on the list if you don't agree with it or think anything is missing. I will take silence as assent! On or around the 8th October I will convert the wiki page into a PDF and start distributing it. I would like to take this opportunity to announce that I wish to stand down as convener of the TAG as of the Fremantle conference. I believe it would be good for the TAG and TDWG to have some fresh blood in this position. I still hope to continue contributing to TDWG but perhaps in different ways. The procedure for choosing a new convener is somewhat vague but I believe it should be done through group consensus. Perhaps we could start a discussion on this list and those who are coming to Fremantle could discuss it further. Who do you think should take this forward? Would you like to take this forward? All the best, Roger ------------------------------------------------------------- Roger Hyam Roger(a)BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ -------------------------------------------------------------

6 6