1928 lines
64 KiB
Plaintext
1928 lines
64 KiB
Plaintext
head 1.66;
|
||
access;
|
||
symbols;
|
||
locks; strict;
|
||
comment @# @;
|
||
|
||
|
||
1.66
|
||
date 2007.03.13.12.50.53; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.65;
|
||
|
||
1.65
|
||
date 2007.01.29.14.24.13; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.64;
|
||
|
||
1.64
|
||
date 2007.01.19.00.00.00; author ChuckMiller; state Exp;
|
||
branches;
|
||
next 1.63;
|
||
|
||
1.63
|
||
date 2007.01.19.00.00.00; author DonaldHobern; state Exp;
|
||
branches;
|
||
next 1.62;
|
||
|
||
1.62
|
||
date 2007.01.19.00.00.00; author BobMorris; state Exp;
|
||
branches;
|
||
next 1.61;
|
||
|
||
1.61
|
||
date 2007.01.19.00.00.00; author BobMorris; state Exp;
|
||
branches;
|
||
next 1.60;
|
||
|
||
1.60
|
||
date 2007.01.19.00.00.00; author BobMorris; state Exp;
|
||
branches;
|
||
next 1.59;
|
||
|
||
1.59
|
||
date 2006.09.04.13.03.11; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.58;
|
||
|
||
1.58
|
||
date 2006.07.05.20.48.11; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.57;
|
||
|
||
1.57
|
||
date 2006.06.22.13.40.36; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.56;
|
||
|
||
1.56
|
||
date 2006.06.21.03.54.06; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.55;
|
||
|
||
1.55
|
||
date 2006.06.21.03.44.32; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.54;
|
||
|
||
1.54
|
||
date 2006.06.19.07.29.03; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.53;
|
||
|
||
1.53
|
||
date 2006.06.19.07.25.06; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.52;
|
||
|
||
1.52
|
||
date 2006.06.16.08.39.15; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.51;
|
||
|
||
1.51
|
||
date 2006.06.15.19.16.54; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.50;
|
||
|
||
1.50
|
||
date 2006.06.15.13.16.39; author DonaldHobern; state Exp;
|
||
branches;
|
||
next 1.49;
|
||
|
||
1.49
|
||
date 2006.06.14.16.59.07; author DonaldHobern; state Exp;
|
||
branches;
|
||
next 1.48;
|
||
|
||
1.48
|
||
date 2006.06.14.11.30.52; author BobMorris; state Exp;
|
||
branches;
|
||
next 1.47;
|
||
|
||
1.47
|
||
date 2006.06.14.11.02.29; author DonaldHobern; state Exp;
|
||
branches;
|
||
next 1.46;
|
||
|
||
1.46
|
||
date 2006.06.14.08.27.53; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.45;
|
||
|
||
1.45
|
||
date 2006.06.13.18.03.12; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.44;
|
||
|
||
1.44
|
||
date 2006.06.13.16.57.46; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.43;
|
||
|
||
1.43
|
||
date 2006.06.13.16.35.44; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.42;
|
||
|
||
1.42
|
||
date 2006.06.13.14.23.00; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.41;
|
||
|
||
1.41
|
||
date 2006.06.13.14.20.40; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.40;
|
||
|
||
1.40
|
||
date 2006.06.13.14.20.05; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.39;
|
||
|
||
1.39
|
||
date 2006.06.13.14.13.02; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.38;
|
||
|
||
1.38
|
||
date 2006.06.13.14.09.26; author RogerHyam; state Exp;
|
||
branches;
|
||
next 1.37;
|
||
|
||
1.37
|
||
date 2006.06.13.14.07.40; author RogerHyam; state Exp;
|
||
branches;
|
||
next 1.36;
|
||
|
||
1.36
|
||
date 2006.06.13.14.06.46; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.35;
|
||
|
||
1.35
|
||
date 2006.06.13.14.06.11; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.34;
|
||
|
||
1.34
|
||
date 2006.06.13.13.40.44; author DonaldHobern; state Exp;
|
||
branches;
|
||
next 1.33;
|
||
|
||
1.33
|
||
date 2006.06.13.13.39.24; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.32;
|
||
|
||
1.32
|
||
date 2006.06.13.13.37.52; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.31;
|
||
|
||
1.31
|
||
date 2006.06.13.13.24.53; author RogerHyam; state Exp;
|
||
branches;
|
||
next 1.30;
|
||
|
||
1.30
|
||
date 2006.06.13.13.13.14; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.29;
|
||
|
||
1.29
|
||
date 2006.06.13.13.12.34; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.28;
|
||
|
||
1.28
|
||
date 2006.06.13.13.09.33; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.27;
|
||
|
||
1.27
|
||
date 2006.06.13.13.04.55; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.26;
|
||
|
||
1.26
|
||
date 2006.06.13.13.02.53; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.25;
|
||
|
||
1.25
|
||
date 2006.06.13.12.54.28; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.24;
|
||
|
||
1.24
|
||
date 2006.06.13.12.14.02; author RogerHyam; state Exp;
|
||
branches;
|
||
next 1.23;
|
||
|
||
1.23
|
||
date 2006.06.13.12.12.26; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.22;
|
||
|
||
1.22
|
||
date 2006.06.13.12.09.07; author DonaldHobern; state Exp;
|
||
branches;
|
||
next 1.21;
|
||
|
||
1.21
|
||
date 2006.06.13.11.57.53; author DonaldHobern; state Exp;
|
||
branches;
|
||
next 1.20;
|
||
|
||
1.20
|
||
date 2006.06.13.11.52.03; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.19;
|
||
|
||
1.19
|
||
date 2006.06.13.11.37.55; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.18;
|
||
|
||
1.18
|
||
date 2006.06.13.11.37.00; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.17;
|
||
|
||
1.17
|
||
date 2006.06.13.11.36.04; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.16;
|
||
|
||
1.16
|
||
date 2006.06.13.11.35.07; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.15;
|
||
|
||
1.15
|
||
date 2006.06.13.11.32.51; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.14;
|
||
|
||
1.14
|
||
date 2006.06.13.11.30.02; author DonaldHobern; state Exp;
|
||
branches;
|
||
next 1.13;
|
||
|
||
1.13
|
||
date 2006.06.13.11.28.44; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.12;
|
||
|
||
1.12
|
||
date 2006.06.13.11.27.54; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.11;
|
||
|
||
1.11
|
||
date 2006.06.13.11.16.40; author CharlesCopp; state Exp;
|
||
branches;
|
||
next 1.10;
|
||
|
||
1.10
|
||
date 2006.06.13.11.11.16; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.9;
|
||
|
||
1.9
|
||
date 2006.06.13.11.09.19; author LeeBelbin; state Exp;
|
||
branches;
|
||
next 1.8;
|
||
|
||
1.8
|
||
date 2006.06.13.11.05.59; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.7;
|
||
|
||
1.7
|
||
date 2006.06.13.11.01.19; author RogerHyam; state Exp;
|
||
branches;
|
||
next 1.6;
|
||
|
||
1.6
|
||
date 2006.06.13.10.51.18; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.5;
|
||
|
||
1.5
|
||
date 2006.06.13.10.50.25; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.4;
|
||
|
||
1.4
|
||
date 2006.06.13.10.47.25; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.3;
|
||
|
||
1.3
|
||
date 2006.06.13.10.46.46; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.2;
|
||
|
||
1.2
|
||
date 2006.06.13.10.46.14; author RicardoPereira; state Exp;
|
||
branches;
|
||
next 1.1;
|
||
|
||
1.1
|
||
date 2006.06.13.10.42.18; author CharlesCopp; state Exp;
|
||
branches;
|
||
next ;
|
||
|
||
|
||
desc
|
||
@
|
||
.
|
||
@
|
||
|
||
|
||
1.66
|
||
log
|
||
@none
|
||
@
|
||
text
|
||
@%META:TOPICINFO{author="RicardoPereira" date="1173790253" format="1.1" version="1.66"}%
|
||
---+ GUID-2 Report
|
||
|
||
---++++ *Second International Workshop on Globally Unique Identifiers for Biodiversity Informatics (GUID-2)*
|
||
_10th - 12th June 2006_
|
||
_e-Science Institute, Edinburgh_
|
||
----
|
||
---++++ 1. Background
|
||
|
||
The Taxonomic Databases Working Group (TDWG, http://www.tdwg.org/) and the Global Biodiversity Information Facility (GBIF, http://www.gbif.org) held the second of two workshops to address the need for a system of globally unique identifiers (GUIDs) for use in biodiversity informatics. The first workshop was held at NESCent in North Carolina in February 2006 and recommended the adoption of Life Science Identifiers (LSIDs) for this purpose (see: [[GUID1Report]]). Subsequent activity has focussed on the development of prototypes, integrating LSIDs with a key data sets and on-line discussion of key infrastructure and policy implications of using LSIDs.
|
||
----
|
||
---++++ 2. Summary
|
||
|
||
The second GUID workshop was held at the e-Science Institute (e-SI) in Edinburgh, Scotland, 10-12 June 2006. The meeting re-iterated the conclusions from the first workshop and developed the following recommendations and priorities for the use of LSIDs, including:
|
||
|
||
* Work first with the nomenclators, particularly IPNI, Index Fungorum and ZooBank, to associate LSIDs with these reference lists of scientific names, recognising their foundational place in biodiversity informatics.
|
||
* Update software tools for LSID resolution and develop packaged installers.
|
||
* Support integration of LSID functionality into TDWG data provider packages.
|
||
* Develop documentation and publicity materials for managers, biologists and IT specialists.
|
||
* Approach external software projects to encourage the support of LSIDs.
|
||
----
|
||
---++++ 3. Goals
|
||
|
||
1. To review the outcomes of the first GUID meeting and subsequent developments.
|
||
1. To confirm the choice of LSIDs as persistent identifiers (GUIDs) for TDWG functional data types as will be defined in the TDWG Core Ontology (currently under development, [[http://wiki.tdwg.org/twiki/bin/view/TAG/TDWGOntology]]).
|
||
1. To discuss the governance of GUID allocation.
|
||
1. To identify issues and discuss the options for ensuring long term availability and archival strategy for GUID objects (or their data sets).
|
||
1. To identify gaps and weaknesses in current GUID server and resolving software and to list the actions required to address them.
|
||
1. To ways to promote the benefits of using GUIDs to the taxonomic, biological research and biodiversity information communities.
|
||
1. To identify the technical and â<>�<3B><>�sociological' support required to assist potential users to start serving GUIDs.
|
||
1. To review and make recommendations on the incorporation of GUIDs and RDF into TDWG standards.
|
||
----
|
||
---++++ 4. Discussion
|
||
|
||
* The meeting identified the importance of promoting the use of LSIDs to the broader community. This goal evolved into the formation of an outreach group [[GUIDOutreach]] to identify priorities for accelerating the update of LSIDs within the broader community associated with TDWG.
|
||
|
||
* A discussion on the relative merits of using HTTP URI (e.g. PURL or URL) rather than LSIDs was motivated by the current lack of support for LSID resolution in client software and browsers versus the ability to resolve ubiquitous URLs. The use of DNS as the current resolution mechisms for LSID makes them appear similar to regular URLs but with this clientside impediment. Having considered these issues, the meeting concluded that the selection of LSIDs made at the GUID 1 meeting remained sound because:
|
||
* URLs are bound to a single transport protocol (http). It would not, therefore, be possible to separate the resolution mechanism from the identification mechamism in future.
|
||
* LSIDs are names and abstract the resolution mechanism, and that mechanism may change in the future.
|
||
* LSIDs provide a mechanism for binding data and metadata that would have to be invented for the use with URLs.
|
||
* The LSID specification recommends RDF as a metadata format. This would have to be mandated with the use of URLs.
|
||
* Socially, people do not trust URLs to be permanent because of the 'link rot' they have encountered on the hypertext web. LSIDs are more likely to gain acceptance for use in publications etc (as is the case with DOI).
|
||
|
||
* Software development - Discussion of the availability and functionality of both provider and client software resulted in a 'break-out' group that produced prioritised recommendations for filling the gaps, improving usability and extending functionality including how to get client software to resolve URNs (see [[GUID2WgSoftwareDevelopment]])
|
||
|
||
* What gets an LSID? - The recommendation is that the architecture requires that an object identified by an LSID should be 'typed'. Therefore anything that can be explicitly typed, preferably with the TDWG ontology, could be named with an LSID. The depth of granularity is subject to what the provider wishes to manage. We recognised that we needed an explicit policy statement about LSIDs being attributed to abstract vs descriptive objects.
|
||
|
||
* Metadata annotation and linkout. FAN can be useful for notification but cannot be effectively used to create back-links to external annotations, because of management issues. A possible solution would be to create a central service where agents could register any annotations that would be available to anyone in the community. If providers are willing to expose their systems to web crawlers, normal discovery methods (e.g. through Google) would also locate distributed references to GUIDs.
|
||
|
||
* There was insufficient evidence from case studies to provide definitive rules about versioning. There is a need for a TDWG policy statement backed with examples. See: VersioningOfLSIDs
|
||
|
||
----
|
||
---++++ 5. Outcomes
|
||
|
||
---+++++ Recommendations
|
||
A number of specific, mainly technical recommendations were made by the end of the conference:
|
||
|
||
1. LSIDs will be used as unique identifiers.
|
||
1. HTTP GET will be the default binding for getMetadata calls.
|
||
1. RDF will be the default metadata response format.
|
||
1. The TDWG ontology (and other well-known vocabularies) should be used wherever possible.
|
||
1. The use of non-RDF as an accepted_types for metadata is deferred.
|
||
1. There should be a central SRV hosting service (see CentralSrvService).
|
||
|
||
---+++++ Actions
|
||
In addition to technical recommendations a number of actions were identified and allocated, with a commitment to reporting back on progress at the TDWG annual meeting in October 2006.
|
||
|
||
* Lee to write a 1-page document on the case for LSIDs aimed at senior administrators/managers by the end of June 2006
|
||
* Rich to develop a document/presentation on the case for LSIDs to biologists for presentation at TDWG 2006 (August 2006)
|
||
* Ricardo, with assistance from Rod and Ben to evaluate software resources collected during GUID-2 and identify gaps in requirements and in the associated documentation (August 2006)
|
||
* Roger to evaluate the status of the documentation necessary to promote the uptake of LSIDs within our community (August 2006)
|
||
* A narrative explanation for the use of LSIDs and RDF in the biodiveristy infrastructure to be written by Roger (July 2006).
|
||
* Stable informative material is to be loaded from the Wiki to the new TDWG website
|
||
* The need for applicability statement and guidelines for biodiversity organisations serving LSIDs
|
||
* Ricardo and Roger to attempt to produce a packaged installer and improved documentation for setting up LSID server software (October 2006).
|
||
* Ben to approach IBM to improve access to and use of their LSID resolver plugins (with support from Ricardo)
|
||
* Encourage development of â<>�<3B><>�good news' demonstrations through ant and fish communities
|
||
* Review tasks involved and costs of setting up the host for a central DNS server service for LSIDs
|
||
----
|
||
---++++ 6. Conclusions
|
||
* There has been considerable discussion about the utility of a URN vs URL strategy. The meeting concluded that our community should implement LSIDs. Experience of the prototypers suggest that implementaiton of LSID Authorities has been straight-forward.
|
||
* Priority actions identified by the meeting should be completed within the next three months to achieve significant progress that must be reported to TDWG 2006.
|
||
* The server and client software and associated documentation must be improved to encourage uptake of LSIDs. Key improvements are: i) simplified installation of LSID server software ii) native or 'plug-in' support for LSIDs in semantic web tools, ontology software and browsers.
|
||
* Promotional documentation targeted separately at managers, biologists and IT specialists is urgently required.
|
||
* Implementation of LSID Authorities at a few key nomenclators and two operational examples with a few associated collections is a priority.
|
||
* There is a sound case for establishing a central DNS server service for LSIDs, which will be further assessed and costed.
|
||
|
||
----
|
||
---+++ Annexes
|
||
|
||
---+++++ Presentations
|
||
The meeting included presentations, break-out group discussions and plenary discussions. The presentations given were:
|
||
|
||
1. [[%ATTACHURL%/hobern_GUID2Day1Goals.ppt][Introduction and overview]] _Donald Hobern_
|
||
1. [[%ATTACHURL%/Hyam_TDWG_GUID-2_arch_03.ppt][Summary of architectural recommendations from TAG]] _Roger Hyam_
|
||
1. [[%ATTACHURL%/Rod-Page-TDWG-GUID2.ppt][LSID Tester]] _Roderic Page_
|
||
1. [[%ATTACHURL%/Perry_LSIDAndDiGIR2.ppt][LSID resolver for specimens in DiGIR2]] _Steve Perry_
|
||
1. [[%ATTACHURL%/GUID2Morris.ppt][Image LSID resolver prototypes]] _Bob Morris_
|
||
1. [[%ATTACHURL%/Richards_IndexFungorumSetup.ppt][Index Fungorum LSID authority setup]] _Kevin Richards_
|
||
1. [[%ATTACHURL%/Richards_LSIDFrameworkPort.ppt][Port of LSID framework to .NET]] _Kevin Richards_
|
||
1. [[http://www.nesc.ac.uk/talks/682/guid-2.ppt][LSID resolution in SEEK]] _Jessie Kennedy_
|
||
1. [[%ATTACHURL%/Pereira_GUID2_LSID_SW_Analysis_v3.ppt][Existing software components and gap analysis]] _Ricardo Pereira_
|
||
1. [[http://www.nesc.ac.uk/talks/682/Core%20Ontology.ppt][Core Ontology]] _Jessie Kennedy_
|
||
1. [[%ATTACHURL%/hobern_AdditionalComponentsOfAnLSIDNetwork.ppt][Additional components of an LSID network]] _Donald Hobern_
|
||
1. [[%ATTACHURL%/PublicationBank.ppt][Publication Bank]] _Robert Huber_
|
||
|
||
See also the [[http://www.nesc.ac.uk/action/esi/contribution.cfm?Title=682][list of presentations]] at the eSI website.
|
||
|
||
----
|
||
---++++ Attendees
|
||
|
||
* Damian Barnier (University of Queensland)
|
||
* Lee Belbin (TDWG)
|
||
* Stan Blum (California Academy of Sciences)
|
||
* Charles Copp (EIM, Technical Writer
|
||
* Simon Coppard (NHM, London)
|
||
* Rob Gales (University of Kansas)
|
||
* Sally Hinchcliffe (RBG, Kew)
|
||
* Donald Hobern (GBIF)
|
||
* Robert Huber (Marum - Zentrum fur marine Umweltwissenschaften)
|
||
* Roger Hyam (TDWG)
|
||
* Jessie Kennedy (Napier University, Edinburgh)
|
||
* Chuck Miller (Missouri Botanical Garden)
|
||
* Bob Morris (University of Massachusetts, Boston)
|
||
* Tom Orrell (ITIS, Smithsonian Institution)
|
||
* Roderic Page (University of Glagow)
|
||
* Ricardo Pereira (TDWG)
|
||
* Steve Perry (University of Kansas)
|
||
* Andrew Polaszek (NHM, London)
|
||
* Rich Pyle (Bishop Museum, Hawaii)
|
||
* Kevin Richards (Landcare Research NZ Ltd)
|
||
* Tim Robertson (GBIF)
|
||
* Vince Smith (NHM)
|
||
* Ben Szekeley (IBM)
|
||
* Dave Vieglais (University of Kansas)
|
||
|
||
|
||
---++ Comments
|
||
Use the space below to make comments about this page.
|
||
|
||
------
|
||
|
||
%ICON{bubble}% Posted by Main.BobMorris - 2006-06-14 10:47:49
|
||
|
||
Unless I misread the spec, the statement in the report "The LSID specification recommends RDF as a metadata format." appears to me to be somewhere between wrong and wishful thinking. The specification provides for the accepted metadata format(s) to be passed as an argument to getMetadata(...). By virtue of mentioning only these two, the spec seems to identify RDF and XMI as popular metadata formats. ("At the time of writing, there are no formally standardized media types for the more popular metadata formats.<br />
|
||
Specifically, RDF and XMI do not have media types registered with IANA."). By virtue of the fact that all examples are in RDF, one might conclude that the specification recommends this, but that is an inference, not a fact as best I can see.<br />
|
||
<br />
|
||
A more accurate report of the GUID2 meeting might be "Despite the fact that unfamiliarity with RDF and lack of browser support were identified as impediments to adoption, TDWG will recommend it as the default metadata format because [whatever]".<br />
|
||
<br />
|
||
In any case, whether or not RDF is a good metadata format for LSID metadata, even concluding that the spec means to suggest that RDF and XMI are popular for LSID is probably disingenuous, since there is in fact very little deployment of LSIDs to date. <br />
|
||
<br />
|
||
My own reading of the meeting is that eaxactly three attendees---Roger, Rod, and Donald, were wildly enthusiastic about RDF and that everybody else was basically merely accepting of it as at least worth a try. Comments here may dispute that reading.
|
||
|
||
------
|
||
|
||
%ICON{bubble}% Posted by Main.BobMorris - 2006-06-14 11:28:05
|
||
|
||
[The following might be considered a whole new direction and so be taken as irrelevant noise, but ...]. XMI, also mentioned in the LSID spec as a popular metadata expression, is, roughly, a standardized XML serialization of UML. As a consequence, the (IMO appropriate) TAG decision to represent the TDWG ontology in UML (rather than RDF) would, with readily(?) available(?) UML tools provide an XMI expression of the TWG ontology. Consequently, many of the GUID goals that mean to relate the GUID metadata to the TDWG ontology would actually be better served if TDWG LSID metadata had XMI as the preferred representation.
|
||
|
||
------
|
||
|
||
%ICON{bubble}% Posted by Main.BobMorris - 2006-06-14 12:13:47
|
||
|
||
Other than the previous, I find the report a complete, accurate, and useful summary of a successful and well-organized meeting. Also, it is \extremely/ helpful to have it appear so quickly. Thanks.
|
||
|
||
------
|
||
|
||
%ICON{bubble}% Posted by Main.DonaldHobern - 2006-06-14 17:28:12
|
||
|
||
Thanks, Bob, for the comments. My only counter-comment would be that there were a few more people beyond those you list who expressed (at least to me) that they did like RDF as a representation of TDWG (meta-)data.
|
||
|
||
------
|
||
|
||
%ICON{bubble}% Posted by Main.ChuckMiller - 2006-06-20 07:03:43
|
||
|
||
Although I see some of the positive attributes of RDF, I remain unclear as to exactly what it would be used for other than a formatted metadata response. If the intent is to actually append multiple RDF responses from a multi-LSID query result and then query/infer over those combined RDF triples, then I see the benefit of RDF. But, if not, then it just sounds like yet another formatted XML document to me, perhaps with a richer vocabulary. So, I remain in the "accepting as worth a try" camp that Bob describes. <br />
|
||
<br />
|
||
Before we can sell the RDF format, I think we need better real-world prototype solutions that involve the RDF part, not just the LSID locator. The word I got from the BHL meeting was that everyone was aghast when they heard that RDF was being chosen as the metadata format. I expect that to be a common reaction until some plain and clear examples are shown.
|
||
|
||
------
|
||
|
||
%ICON{bubble}%
|
||
@
|
||
|
||
|
||
1.65
|
||
log
|
||
@none
|
||
@
|
||
text
|
||
@d1 1
|
||
a1 1
|
||
%META:TOPICINFO{author="RicardoPereira" date="1170080653" format="1.1" version="1.65"}%
|
||
d35 1
|
||
a35 1
|
||
* The meeting identified the importance of promoting the use of LSIDs to the broader community. This goal evolved into the formation of an outreach group [GuidOutreach] to identify priorities for accelerating the update of LSIDs within the broader community associated with TDWG.
|
||
d182 1
|
||
a182 1
|
||
%ICON{bubble}% @
|
||
|
||
|
||
1.64
|
||
log
|
||
@Comment added
|
||
.
|
||
@
|
||
text
|
||
@d1 1
|
||
d30 1
|
||
a30 1
|
||
1. To identify the technical and ‘sociological' support required to assist potential users to start serving GUIDs.
|
||
d77 1
|
||
a77 1
|
||
* Encourage development of ‘good news' demonstrations through ant and fish communities
|
||
d112 24
|
||
a135 25
|
||
Damian Barnier (University of Queensland)
|
||
Lee Belbin (TDWG)
|
||
Stan Blum (California Academy of Sciences)
|
||
Charles Copp (EIM, Technical Writer
|
||
Simon Coppard (NHM, London)
|
||
Rob Gales (University of Kansas)
|
||
Sally Hinchcliffe (RBG, Kew)
|
||
Donald Hobern (GBIF)
|
||
Robert Huber (Marum - Zentrum fur marine Umweltwissenschaften)
|
||
Roger Hyam (TDWG)
|
||
Jessie Kennedy (Napier University, Edinburgh)
|
||
Chuck Miller (Missouri Botanical Garden)
|
||
Bob Morris (University of Massachusetts, Boston)
|
||
Tom Orrell (ITIS, Smithsonian Institution)
|
||
Roderic Page (University of Glagow)
|
||
Ricardo Pereira (TDWG)
|
||
Steve Perry (University of Kansas)
|
||
Andrew Polaszek (NHM, London)
|
||
Rich Pyle (Bishop Museum, Hawaii)
|
||
Kevin Richards (Landcare Research NZ Ltd)
|
||
Tim Robertson (GBIF)
|
||
Vince Smith (NHM)
|
||
Ben Szekeley (IBM)
|
||
Dave Vieglais (University of Kansas)
|
||
|
||
d145 7
|
||
a151 7
|
||
Unless I misread the spec, the statement in the report "The LSID specification recommends RDF as a metadata format." appears to me to be somewhere between wrong and wishful thinking. The specification provides for the accepted metadata format(s) to be passed as an argument to getMetadata(...). By virtue of mentioning only these two, the spec seems to identify RDF and XMI as popular metadata formats. ("At the time of writing, there are no formally standardized media types for the more popular metadata formats.<br />
|
||
Specifically, RDF and XMI do not have media types registered with IANA."). By virtue of the fact that all examples are in RDF, one might conclude that the specification recommends this, but that is an inference, not a fact as best I can see.<br />
|
||
<br />
|
||
A more accurate report of the GUID2 meeting might be "Despite the fact that unfamiliarity with RDF and lack of browser support were identified as impediments to adoption, TDWG will recommend it as the default metadata format because [whatever]".<br />
|
||
<br />
|
||
In any case, whether or not RDF is a good metadata format for LSID metadata, even concluding that the spec means to suggest that RDF and XMI are popular for LSID is probably disingenuous, since there is in fact very little deployment of LSIDs to date. <br />
|
||
<br />
|
||
d176 2
|
||
a177 2
|
||
Although I see some of the positive attributes of RDF, I remain unclear as to exactly what it would be used for other than a formatted metadata response. If the intent is to actually append multiple RDF responses from a multi-LSID query result and then query/infer over those combined RDF triples, then I see the benefit of RDF. But, if not, then it just sounds like yet another formatted XML document to me, perhaps with a richer vocabulary. So, I remain in the "accepting as worth a try" camp that Bob describes. <br />
|
||
<br />
|
||
@
|
||
|
||
|
||
1.63
|
||
log
|
||
@Comment added
|
||
.
|
||
@
|
||
text
|
||
@d174 8
|
||
@
|
||
|
||
|
||
1.62
|
||
log
|
||
@Comment added
|
||
.
|
||
@
|
||
text
|
||
@d168 6
|
||
@
|
||
|
||
|
||
1.61
|
||
log
|
||
@Comment added
|
||
.
|
||
@
|
||
text
|
||
@d162 6
|
||
@
|
||
|
||
|
||
1.60
|
||
log
|
||
@Comment added
|
||
.
|
||
@
|
||
text
|
||
@d156 6
|
||
@
|
||
|
||
|
||
1.59
|
||
log
|
||
@Fixed typo.
|
||
.
|
||
@
|
||
text
|
||
@d135 22
|
||
a156 1
|
||
@
|
||
|
||
|
||
1.58
|
||
log
|
||
@Fixed typo.
|
||
.
|
||
@
|
||
text
|
||
@d80 1
|
||
a80 1
|
||
* There has been considerable discussion about the utility of a URN vs URL strategy. The meeting concluded that our community should implement LSIDs. Experience of the protypers suggest that implementaiton of LSID Authorities has been straight-forward.
|
||
@
|
||
|
||
|
||
1.57
|
||
log
|
||
@Added mention to GBIF in the beginning.
|
||
.
|
||
@
|
||
text
|
||
@d72 1
|
||
a72 1
|
||
* Stable informative material is to be loaded fromt he Wiki to the new TDWG website
|
||
@
|
||
|
||
|
||
1.56
|
||
log
|
||
@Added Jessie's presentations.
|
||
.
|
||
@
|
||
text
|
||
@d9 1
|
||
a9 1
|
||
The Taxonomic Databases Working Group (TDWG, http://www.tdwg.org/) held the second of two workshops to address the need for a system of globally unique identifiers (GUIDs) for use in biodiversity informatics. The first workshop was held at NESCent in North Carolina in February 2006 and recommended the adoption of Life Science Identifiers (LSIDs) for this purpose (see: [[GUID1Report]]). Subsequent activity has focussed on the development of prototypes, integrating LSIDs with a key data sets and on-line discussion of key infrastructure and policy implications of using LSIDs.
|
||
@
|
||
|
||
|
||
1.55
|
||
log
|
||
@Typo
|
||
.
|
||
@
|
||
text
|
||
@d86 1
|
||
a86 1
|
||
*
|
||
d100 1
|
||
a100 1
|
||
1. LSID resolution in SEEK _Jessie Kennedy_
|
||
d102 1
|
||
a102 1
|
||
1. Core Ontology _Jessie Kennedy_
|
||
d105 3
|
||
@
|
||
|
||
|
||
1.54
|
||
log
|
||
@Ricardo's point about LSIDs as names
|
||
.
|
||
@
|
||
text
|
||
@d39 1
|
||
a39 1
|
||
* LSIDs provide a mechanism for binding data and metadata that would have to be invented for the use if URLs.
|
||
@
|
||
|
||
|
||
1.53
|
||
log
|
||
@General tidyup after a few sleeps
|
||
.
|
||
@
|
||
text
|
||
@d38 1
|
||
a38 1
|
||
* LSIDs are names and abstract the resolution mechanism - that may change in the future.
|
||
@
|
||
|
||
|
||
1.52
|
||
log
|
||
@Lee responding to Rich's comments
|
||
.
|
||
@
|
||
text
|
||
@d17 1
|
||
d19 1
|
||
a19 2
|
||
* Support integration of LSID functionality into TDWG data provider packages.
|
||
* Approach external software projects to encourage addition of support for LSIDs.
|
||
d27 3
|
||
a29 3
|
||
1. To identify gaps and weaknesses in current GUID server and resolving software and to list the actions required.
|
||
1. To seek actions that will promote the benefits of using GUIDs to the taxonomic, biological research and biodiversity information communities.
|
||
1. To identify the technical and ‘sociological' actions required to assist potential users to start serving GUIDs.
|
||
d36 1
|
||
a36 1
|
||
* There was discussion on the relative benefits and costs of using HTTP URI (e.g. PURL or URL) rather than LSIDs. This was motivated by the current lack of support for LSID resolution in client software and browsers, whilst the ability to resolve URLs is ubiquitous. The use of DNS as the current resolution mechisms for LSID makes them appear similar to regular URLs but with this clientside impediment. Having considered these issues, the meeting concluded that the selection of LSIDs made at the GUID 1 meeting was sound because:
|
||
d45 1
|
||
a45 1
|
||
* What gets an LSID? - The recommendation is that the architecture requires that an object identified by an LSID should be 'typed'. Therefore anything that can be explicitly typed, preferably with the TDWG ontology, could be named with an LSID. The depth of granularity is subject to what the provider wishes to manage. We do need a more explicit policy statement about LSIDs being attributed to abstract vs descriptive objects.
|
||
d49 1
|
||
a49 1
|
||
* The case for using Versions in GUIDs (LSIDs) - It was decided that there was not yet enough evidence from case analysis to provide definitive rules. There is a need for a TDWG policy statement backed with examples. See: VersioningOfLSIDs
|
||
d55 1
|
||
a55 1
|
||
A number of specific, mainly technical, recommendations were made at the end of the conference:
|
||
d60 2
|
||
a61 2
|
||
1. Well known vocabularies or the TDWG ontology should be used where ever possible.
|
||
1. The discussion of accepted_types for metadata (other than RDF) is deferred to a later date.
|
||
d67 1
|
||
a67 1
|
||
* Lee to write a 1-page document on the case for GUIDs/LSIDs aimed at senior administrators/managers by the end of June 2006
|
||
d72 4
|
||
a75 4
|
||
* More useful and informative material to be placed on the website
|
||
* Applicability statement and guidelines for biodiversity organisations serving LSIDs
|
||
* Ricardo and Roger to attempt to produce a packaged installer and improved documentation for setting up LSID server software.
|
||
* Ben to approach IBM to improve access to and use of their LSID resolver plugins
|
||
d80 1
|
||
a80 1
|
||
* There has been considerable discussion about the utility of a URN vs URL strategy. The meeting concluded that our community should implement LSIDs. Experience of the protypers suggest that implementaiton of LSID Authorities has been easy.
|
||
d83 1
|
||
a83 1
|
||
* Promotional documentation targeted separately at managers, biologists and IT specialists will be developed and distributed.
|
||
d86 1
|
||
d108 24
|
||
a131 30
|
||
Mr. Damian Barnier (University of Queensland)
|
||
Dr. Lee Belbin (TDWG)
|
||
Dr. Stan Blum (California Academy of Sciences)
|
||
Mr. Charles Copp (EIM, Technical Writer
|
||
Dr. Simon Coppard (NHM, London)
|
||
Mr. Rob Gales (University of Kansas)
|
||
Mrs. Sally Hinchcliffe (RBG, Kew)
|
||
Mr. Donald Hobern (GBIF)
|
||
Dr. Robert Huber (Marum - Zentrum fur marine Umweltwissenschaften)
|
||
Dr. Roger Hyam (TDWG)
|
||
Prof. Jessie Kennedy (Napier University, Edinburgh)
|
||
Mr. Chuck Miller (Missouri Botanical Garden)
|
||
Prof. Bob Morris (University of Massachusetts, Boston)
|
||
Dr. Tom Orrell (ITIS, Smithsonian Institution)
|
||
Dr. Roderic Page (University of Glagow)
|
||
Mr. Ricardo Pereira (TDWG)
|
||
Mr. Steve Perry (University of Kansas)
|
||
Dr. Andrew Polaszek (NHM, London)
|
||
Dr. Rich Pyle (Bishop Museum, Hawaii)
|
||
Mr. Kevin Richards (Landcare Research NZ Ltd)
|
||
Mr. Tim Robertson (GBIF)
|
||
Dr. Vince Smith (NHM)
|
||
Mr. Ben Szekeley (IBM)
|
||
Dr. Dave Vieglais (University of Kansas)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
@
|
||
|
||
|
||
1.51
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d23 1
|
||
a23 1
|
||
1. To review the outcomes of the first Guid meeting and subsequent developments.
|
||
d45 1
|
||
a45 1
|
||
* What gets a GUID? - This topic of GUID 'granularity' was referred to throughout the meeting. The guidance given is that, the architecture requires that an object identified by an LSID should be 'typed', therefore anything that can be explicitly typed, preferably with the TDWG ontology, could be named with an LSID. The depth of granularity is subject to what the provider wishes to manage.
|
||
@
|
||
|
||
|
||
1.50
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d38 1
|
||
a38 1
|
||
* LSIDs are names (although they may look like URLs) and abstract the resolution mechanism - that may change in the future.
|
||
a58 1
|
||
1. The SRV DNS record should be used with the A Record as back-up where possible.
|
||
@
|
||
|
||
|
||
1.49
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d104 1
|
||
a104 1
|
||
1. Publication Bank _Robert Huber_
|
||
@
|
||
|
||
|
||
1.48
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d97 1
|
||
a97 1
|
||
1. Image LSID resolver prototypes _Bob Morris_
|
||
@
|
||
|
||
|
||
1.47
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d3 1
|
||
a3 1
|
||
---++++ *Second International Workshop on Globally Unique Identifiers for Biodiversity Infromatics (GUID-2)*
|
||
@
|
||
|
||
|
||
1.46
|
||
log
|
||
@Released version - Lee
|
||
.
|
||
@
|
||
text
|
||
@d75 2
|
||
a76 2
|
||
* Ricardo and roger to attempt to produce a packaged installer and improved documentation for setting up LSID server software.
|
||
* Ben to approach IBM to improve acces to and use of their LSID resolver plugins
|
||
d81 1
|
||
a81 1
|
||
* There has been considerable discussion about the utility of a URN vs URL stretagey. The meeting concluded that our community should implement LSIDs. Experience of the protypers suggest that implementaiton of LSID Authorities has been easy.
|
||
@
|
||
|
||
|
||
1.45
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d13 1
|
||
a13 1
|
||
The second workshop was held at the e-Science Institute (e-SI) in Edinburgh, Scotland, 10-12 June 2006. The meeting re-iterated the conclusions from the first workshop and developed the following recommendations and priorities for the use of LSIDs, including:
|
||
d27 2
|
||
a28 2
|
||
1. To discuss any gaps and weaknesses in current GUID server and resolving software and to identify the actions required to address these issues.
|
||
1. To identify the actions required to promote the benefits of using GUIDs to the taxonomic, biological research and biodiversity information communities.
|
||
d30 1
|
||
a30 1
|
||
1. To review and make recommendations on the incorporation of GUIDs and RDF into TDWG standards.
|
||
d36 1
|
||
a36 1
|
||
* There was much discussion on the relative benefits and costs of using HTTP URI (e.g. PURL or URL) rather than LSIDs. This was motivated by the current lack of support for LSID resolution in client software and browsers, whilst the ability to resolve URLs is ubiquitous. The use of DNS as the current resolution mechisms for LSID makes them appear similar to regular URLs but with this clientside impediment. Having considered these issues, the meeting concluded that the selection of LSIDs made at the GUID 1 meeting was sound because:
|
||
d43 1
|
||
a43 1
|
||
* Software development - A considerable amount of time was given over to discussing the current availability and functionality of both provider and client softwar. One of the 'break-out' groups produced a prioritised recommendation for filling the gaps, improving usability and extending functionality including how to get client software to resolve URNs (see [[GUID2WgSoftwareDevelopment]])
|
||
d45 1
|
||
a45 1
|
||
* What gets a GUID? - The topic of what objects or concepts should be allocated GUIDs and the depth of 'granularity' was referred to throughout the meeting. The guidance given is that, the architecture requires that an object identified by an LSID should be 'typed', therefore anything that can be explicitly typed, preferably with the TDWG ontology, could be named with an LSID. The depth of granularity is subject to what the provider wishes to manage.
|
||
d47 1
|
||
a47 1
|
||
* The group discussed mechanisms for metadata annotation and linkout. FAN can be useful for notification but cannot be effectively used to create back-links to external annotations, because of management issues. A possible solution would be to create a central service where agents could register any annotations that would be available to anyone in the community. If providers are willing to expose their systems to web crawlers, normal discovery methods (e.g. through Google) would also locate distributed references to GUIDs.
|
||
d49 1
|
||
a49 1
|
||
* The case for using Versions in GUIDs (LSIDs) - There was much discussionon whether the facility for identifying versions in GUIDs should be used or not, but it was decided that there was not yet enough evidence from case analysis to provide definitive rules. There is a need for a TDWG policy statement backed with examples. See: VersioningOfLSIDs
|
||
@
|
||
|
||
|
||
1.44
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d9 1
|
||
a9 1
|
||
The Taxonomic Databases Working Group (TDWG, http://www.tdwg.org/) held the second of two workshops to address the need for a system of globally unique identifiers (GUIDs) for use in biodiversity informatics. The first workshop was held at NESCent in North Carolina in February 2006 and recommended the adoption of Life Science Identifiers (LSIDs) for this purpose. Subsequent activity has focussed on the development of prototypes, integrating LSIDs with a key data sets and on-line discussion of key infrastructure and policy implications of using LSIDs.
|
||
d23 4
|
||
a26 4
|
||
1. To review the outcomes of the first Guid meeting and subsequent developments
|
||
1. To confirm the choice of LSIDs as persistent identifiers (GUIDs) for TDWG functional data types as will be defined in the TDWG Core Ontology (currently under development)
|
||
1. To discuss the governance of GUID allocation
|
||
1. To identify issues and discuss the options for ensuring long term availability and archival strategy for GUID objects (or their data sets)
|
||
d28 3
|
||
a30 3
|
||
1. To identify actions required to promote the benefits of using GUIDs to the taxonomic, biological research and biodiversity information communities
|
||
1. To identify the technical and ‘sociological' actions required to assist potential users to start serving GUIDs
|
||
1. To review and make recommendations on the incorporation of GUIDs and RDF into TDWG standards
|
||
d34 1
|
||
a34 1
|
||
* The meeting identified the importance of promotion of LSIDs into the broader community. This goal evolved into the formation of an outreach group [GuidOutreach] to identify priorities for accellerating the update of LSIDs within the broader community associated with TDWG.
|
||
d36 3
|
||
a38 3
|
||
* There was discussion on the possible use of HTTP URI (e.g. PURL or URL) rather than LSID. This was motivated by the clientside impediment to adoption of LSIDs - few clients support LSID resolution whilst the ability to resolve URLs is ubiquitous. The use of DNS as the current resolution mechisms for LSID makes them appear similar to regular URLs but with this clientside impediment. The result of this discussion was in favour of LSIDs because:
|
||
* URLs are bound to a single transport protocol (http). It would not be possible to separate the resolution mechanism from the identification mechamism in future.
|
||
* LSIDs are names and abstract the resolution mechanism - that may change in the future.
|
||
d41 1
|
||
a41 1
|
||
* Socially people do not trust URLs to be permanent because of the 'link rot' they have encountered on the hypertext web. LSIDs are more likely to gain acceptance for use in publications etc (as is the case with DOI).
|
||
d43 1
|
||
a43 1
|
||
* Software development - filling the gaps, improving usability and extending functionality including how to get client software to resolve URNs (see [[GUID2WgSoftwareDevelopment]])
|
||
d45 1
|
||
a45 1
|
||
* What gets a GUID? - The architecture requires that the object identified by an LSID should be 'typed' therefore anything that can be explicitly typed, preferably with the TDWG ontology, could be named with an LSID.
|
||
d47 1
|
||
a47 1
|
||
* The group discussed mechanisms for metadata annotation and linkout. FAN can be useful for notification but cannot be effectively used to create backlinks to external annotations because of management issues. A possible solution would be to create a central service where agents could register any annotations that would be available to anyone in the community.
|
||
d49 1
|
||
a49 1
|
||
* The case for using Versions in GUIDs (LSIDs) - much discussion but not enough evidence from case analysis. Needs a TDWG policy statement backed with examples. See: VersioningOfLSIDs
|
||
a50 1
|
||
* Discussion of external annotations and how these could be harvested
|
||
d55 2
|
||
d66 2
|
||
d74 2
|
||
a75 1
|
||
* Ricardo and roger to review software gaps and attempt to at least produce a packaged installer and improved documentation for setting up LSID server software.
|
||
d78 1
|
||
a78 1
|
||
* Review tasks involved and host for setting up a central DNS server service for LSIDs
|
||
d83 1
|
||
a83 1
|
||
* The server and client software and associated documentation must be improved to encourage uptake of LSIDs.
|
||
d86 1
|
||
d91 2
|
||
@
|
||
|
||
|
||
1.43
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d1 1
|
||
a1 1
|
||
---++ GUID-2 Report
|
||
d3 1
|
||
a3 1
|
||
*Second International Workshop on Globally Unique Identifiers for Biodiversity Infromatics (GUID-2)*
|
||
d24 1
|
||
a24 1
|
||
1. To confirm the choice of LSIDs as persistent identifiers (GUIDs) for TDWG functional data types as defined in the imminent ontology
|
||
d83 1
|
||
a83 1
|
||
---++++ Annexes
|
||
d98 1
|
||
a98 1
|
||
|
||
d101 24
|
||
a124 24
|
||
Mr. Damian Barnier (University of Queensland)
|
||
Dr. Lee Belbin (TDWG)
|
||
Dr. Stan Blum (California Academy of Sciences)
|
||
Mr. Charles Copp (EIM, Technical Writer
|
||
Dr. Simon Coppard (NHM, London)
|
||
Mr. Rob Gales (University of Kansas)
|
||
Mrs. Sally Hinchcliffe (RBG, Kew)
|
||
Mr. Donald Hobern (GBIF)
|
||
Dr. Robert Huber (Marum - Zentrum fur marine Umweltwissenschaften)
|
||
Dr. Roger Hyam (TDWG)
|
||
Prof. Jessie Kennedy (Napier University, Edinburgh)
|
||
Mr. Chuck Miller (Missouri Botanical Garden)
|
||
Prof. Bob Morris (University of Massachusetts, Boston)
|
||
Dr. Tom Orrell (ITIS, Smithsonian Institution)
|
||
Dr. Roderic Page (University of Glagow)
|
||
Mr. Ricardo Pereira (TDWG)
|
||
Mr. Steve Perry (University of Kansas)
|
||
Dr. Andrew Polaszek (NHM, London)
|
||
Dr. Rich Pyle (Bishop Museum, Hawaii)
|
||
Mr. Kevin Richards (Landcare Research NZ Ltd)
|
||
Mr. Tim Robertson (GBIF)
|
||
Dr. Vince Smith (NHM)
|
||
Mr. Ben Szekeley (IBM)
|
||
Dr. Dave Vieglais (University of Kansas)
|
||
@
|
||
|
||
|
||
1.42
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d6 1
|
||
a6 1
|
||
|
||
d9 2
|
||
a10 2
|
||
The Taxonomic Databases Working Group (TDWG, http://www.tdwg.org/) held the second of two workshops to address the need for a system of globally unique identifiers (GUIDs) for use in biodiversity informatics. The first workshop was held at NESCent in North Carolina in February 2006 and recommended the adoption of Life Science Identifiers (LSIDs) for this purpose. Subsequent activity focussed on the development of prototypes integrating LSIDs with a key data sets and online discussion of key infrastructure and policy implications of using LSIDs.
|
||
|
||
d13 1
|
||
a13 1
|
||
The second workshop was held at the e-Science Institute (e-SI) in Edinburgh, Scotland, 10-12 June 2006. The meeting reiterated the conclusions from the first workshop and developed the following recommendations and priorities for the use of LSIDs, including:
|
||
d20 1
|
||
a20 1
|
||
|
||
d31 1
|
||
a31 1
|
||
|
||
d52 1
|
||
a52 1
|
||
|
||
d75 1
|
||
a75 1
|
||
|
||
d82 1
|
||
a82 1
|
||
|
||
d86 12
|
||
a97 12
|
||
1. [[%ATTACHURL%/hobern_GUID2Day1Goals.ppt][Introduction and overview]] Donald Hobern
|
||
1. [[%ATTACHURL%/Hyam_TDWG_GUID-2_arch_03.ppt][Summary of architectural recommendations from TAG]] Roger Hyam
|
||
1. [[%ATTACHURL%/Rod-Page-TDWG-GUID2.ppt][LSID Tester]] Roderic Page
|
||
1. [[%ATTACHURL%/Perry_LSIDAndDiGIR2.ppt][LSID resolver for specimens in DiGIR2]] Steve Perry
|
||
1. Image LSID resolver prototypes Bob Morris
|
||
1. [[%ATTACHURL%/Richards_IndexFungorumSetup.ppt][Index Fungorum LSID authority setup]] Kevin Richards
|
||
1. [[%ATTACHURL%/Richards_LSIDFrameworkPort.ppt][Port of LSID framework to .NET]] Kevin Richards
|
||
1. LSID resolution in SEEK Jessie Kennedy
|
||
1. [[%ATTACHURL%/Pereira_GUID2_LSID_SW_Analysis_v3.ppt][Existing software components and gap analysis]] Ricardo Pereira
|
||
1. Core Ontology Jessie Kennedy
|
||
1. [[%ATTACHURL%/hobern_AdditionalComponentsOfAnLSIDNetwork.ppt][Additional components of an LSID network]] Donald Hobern
|
||
1. Publication Bank Robert Huber
|
||
d101 29
|
||
a129 24
|
||
Andrew Polaszek (NHM, London)
|
||
Ben Szekeley (IBM)
|
||
Bob Morris (University of Massachusetts, Boston)
|
||
Charles Copp (EIM, Technical Writer)
|
||
Chuck Miller (Missouri Botanical Garden)
|
||
Damian Barnier (University of Queensland)
|
||
Dave Vieglais (University of Kansas)
|
||
Donald Hobern (GBIF)
|
||
Jessie Kennedy (Napier University, Edinburgh)
|
||
Kevin Richards (Landcare Research NZ Ltd)
|
||
Lee Belbin (TDWG)
|
||
Ricardo Pereira (TDWG)
|
||
Rich Pyle (Bishop Museum, Hawaii)
|
||
Rob Gales (University of Kansas)
|
||
Robert Huber (Marum - Zentrum fur marine Umweltwissenschaften)
|
||
Rod Page (University of Glagow)
|
||
Roger Hyam (TDWG)
|
||
Sally Hinchcliffe (RBG, Kew)
|
||
Simon Coppard (NHM, London)
|
||
Stan Blum (California Academy of Sciences)
|
||
Steve Perry (University of Kansas)
|
||
Tim Robertson (GBIF)
|
||
Tom Orrell (ITIS, Smithsonian Institution)
|
||
Vince Smith (NHM)
|
||
@
|
||
|
||
|
||
1.41
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d34 1
|
||
a34 1
|
||
The meeting identified the importance of promotion of LSIDs into the broader community. This goal evolved into the formation of an outreach group [GuidOutreach] to identify priorities for accellerating the update of LSIDs within the broader community associated with TDWG.
|
||
d36 6
|
||
a41 6
|
||
There was discussion on the possible use of HTTP URI (e.g. PURL or URL) rather than LSID. This was motivated by the clientside impediment to adoption of LSIDs - few clients support LSID resolution whilst the ability to resolve URLs is ubiquitous. The use of DNS as the current resolution mechisms for LSID makes them appear similar to regular URLs but with this clientside impediment. The result of this discussion was in favour of LSIDs because:
|
||
1. URLs are bound to a single transport protocol (http). It would not be possible to separate the resolution mechanism from the identification mechamism in future.
|
||
2. LSIDs are names and abstract the resolution mechanism - that may change in the future.
|
||
3. LSIDs provide a mechanism for binding data and metadata that would have to be invented for the use if URLs.
|
||
4. The LSID specification recommends RDF as a metadata format. This would have to be mandated with the use of URLs.
|
||
5. Socially people do not trust URLs to be permanent because of the 'link rot' they have encountered on the hypertext web. LSIDs are more likely to gain acceptance for use in publications etc (as is the case with DOI).
|
||
d43 1
|
||
a43 1
|
||
Software development - filling the gaps, improving usability and extending functionality including how to get client software to resolve URNs (see [[GUID2WgSoftwareDevelopment]])
|
||
d45 1
|
||
a45 1
|
||
What gets a GUID? - The architecture requires that the object identified by an LSID should be 'typed' therefore anything that can be explicitly typed, preferably with the TDWG ontology, could be named with an LSID.
|
||
d47 1
|
||
a47 1
|
||
The group discussed mechanisms for metadata annotation and linkout. FAN can be useful for notification but cannot be effectively used to create backlinks to external annotations because of management issues. A possible solution would be to create a central service where agents could register any annotations that would be available to anyone in the community.
|
||
d49 1
|
||
a49 1
|
||
The case for using Versions in GUIDs (LSIDs) - much discussion but not enough evidence from case analysis. Needs a TDWG policy statement backed with examples. See: VersioningOfLSIDs
|
||
d51 1
|
||
a51 1
|
||
Discussion of external annotations and how these could be harvested
|
||
@
|
||
|
||
|
||
1.40
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@a98 1
|
||
|
||
@
|
||
|
||
|
||
1.39
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d7 2
|
||
a8 1
|
||
---++++ 1. Summary
|
||
d11 2
|
||
d21 1
|
||
a21 1
|
||
---++++ 2. Goals
|
||
d32 1
|
||
a32 2
|
||
|
||
---++++ 3. Discussions
|
||
d53 1
|
||
a53 1
|
||
---++++ 4. Outcomes
|
||
d76 1
|
||
a76 1
|
||
---++++ 5. Conclusions
|
||
d100 1
|
||
a100 1
|
||
---++++ Attendees
|
||
@
|
||
|
||
|
||
1.38
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d32 1
|
||
a32 1
|
||
---+++++ General
|
||
a33 8
|
||
Outreach - value of using GUIDs and RDF
|
||
To discuss how TDWG promotion of LSIDs would affect relationships with other communities
|
||
|
||
This goal evolved into the formation of an outreach group [GuidOutreach] to identify priorities for accellerating the update of LSIDs within the broader community associated with TDWG.
|
||
|
||
---+++++ Technical
|
||
|
||
|
||
a40 1
|
||
|
||
a50 1
|
||
|
||
@
|
||
|
||
|
||
1.37
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d42 6
|
||
a47 18
|
||
There was discussion on the possible use of HTTP URI (e.g. PURL or URL)
|
||
rather than LSID. This was motivated by the clientside impediment to adoption of LSIDs.
|
||
* few clients support LSID resolution whilst the ability to resolve URLs is ubiquitous.
|
||
The use of DNS as the current resolution mechisms for LSID makes them appear similar to regular URLs but
|
||
with this clientside impediment. The result of this discussion was in favour of
|
||
LSIDs because:
|
||
1. URLs are bound to a single transport protocol (http). It would not be
|
||
possible to separate the resolution mechanism from the identification mechamism
|
||
in future.
|
||
2. LSIDs are names and abstract the resolution mechanism - that may change in the
|
||
future.
|
||
3. LSIDs provide a mechanism for binding data and metadata that would have to
|
||
be invented for the use if URLs.
|
||
4. The LSID specification recommends RDF as a metadata format. This would
|
||
have to be mandated with the use of URLs.
|
||
5. Socially people do not trust URLs to be permanent because of the 'link rot'
|
||
they have encountered on the hypertext web. LSIDs are more likely to gain
|
||
acceptance for use in publications etc (as is the case with DOI).
|
||
@
|
||
|
||
|
||
1.36
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d41 21
|
||
@
|
||
|
||
|
||
1.35
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d12 5
|
||
a16 5
|
||
1. Work first with the nomenclators, particularly IPNI, Index Fungorum and ZooBank, to associate LSIDs with these reference lists of scientific names, recognising their foundational place in biodiversity informatics.
|
||
1. Update software tools for LSID resolution and develop packaged installers.
|
||
1. Develop documentation and publicity materials for managers, biologists and IT specialists.
|
||
1. Support integration of LSID functionality into TDWG data provider packages.
|
||
1. Approach external software projects to encourage addition of support for LSIDs.
|
||
@
|
||
|
||
|
||
1.34
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d8 1
|
||
a8 1
|
||
The Taxonomic Databases Working Group (TDWG, http://www.tdwg.org/) has held the second of two workshops to address the need for a system of globally unique identifiers (GUIDs) for use in biodiversity informatics. The first workshop was held at NESCent in North Carolina in February 2006 and recommended the adoption of Life Science Identifiers (LSIDs) for this purpose. Subsequent activity has focussed on development of prototypes integrating LSIDs with a variety of data sets and online discussions of some of the technial and policy implications of using LSIDs.
|
||
d10 1
|
||
a10 1
|
||
The second workshop was held at the e-Science Institute (e-SI) in Edinburgh, Scotland, 10-12 June 2006. The meeting reviewed and reiterated the conclusions from the first workshop and developed a set of recommendations and priorities for the use of LSIDs, including:
|
||
d14 1
|
||
a14 1
|
||
1. Develop documentation and publicity materials for a range of audiences.
|
||
d52 1
|
||
a52 1
|
||
---++++ 4. Out Comes
|
||
d66 1
|
||
a66 1
|
||
* Ricardo to evaluate software resources collected during GUID-2 and identify gaps in requirements and in the associated documentation (August 2006)
|
||
d68 1
|
||
a68 1
|
||
* RDF to senior managers
|
||
@
|
||
|
||
|
||
1.33
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d8 9
|
||
@
|
||
|
||
|
||
1.32
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d67 5
|
||
a71 9
|
||
There has been considerable discussion about the utility of a URN vs URL stretagey. The meeting concluded that our community should implement LSIDs. Experience of the protypers suggest that implementaiton of LSID Authorities has been easy.
|
||
|
||
Priority actions identified by the meeting should be completed within the next three months to achieve significant progress that must be reported to TDWG 2006.
|
||
|
||
The server and client software and associated documentation must be improved to encourage uptake of LSIDs.
|
||
|
||
Promotional documentation targeted separately at managers, biologists and IT specialists will be developed and distributed.
|
||
|
||
Implementation of LSID Authorities at a few key nomenclators and two operational examples with a few associated collections is a priority.
|
||
@
|
||
|
||
|
||
1.31
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d67 9
|
||
a75 1
|
||
A short paragraph highlighting the main conclusions from the meeting and indicating what might happen next.
|
||
@
|
||
|
||
|
||
1.30
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d46 6
|
||
a51 5
|
||
1. LSIDs will be used as unique identifiers
|
||
1. HTTP GET will be the default binding for getMetadata calls
|
||
1. The SRV DNS record should be used with the A Record as back-up
|
||
1. RDF will be the default metadata response format
|
||
1. The discussion of accepted types for metadata to be deferred
|
||
@
|
||
|
||
|
||
1.29
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d68 1
|
||
a68 2
|
||
=Annexes=
|
||
|
||
@
|
||
|
||
|
||
1.28
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d26 1
|
||
d28 1
|
||
a28 1
|
||
To discuss how TDWG promotion of LSIDs would affect relationships with other communities: This goal evolved into the formation of an outreach group [GuidOutreach] to identify priorities for accellerating the update of LSIDs within the broader community associated with TDWG.
|
||
@
|
||
|
||
|
||
1.27
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d21 1
|
||
a21 1
|
||
---+++++ 3. Discussions
|
||
d23 1
|
||
a23 1
|
||
---++++ General
|
||
d29 1
|
||
a29 1
|
||
The group discussed mechanisms for metadata annotation and linkout. FAN can be useful for notification but cannot be effectively used to create backlinks to external annotations because of management issues. A possible solution would be to create a central service where agents could register any annotations that would be available to anyone in the community.
|
||
d31 1
|
||
a31 2
|
||
---++++ Technical
|
||
Software development - filling the gaps, improving usability and extending functionality (see [[GUID2WgSoftwareDevelopment]])
|
||
d33 1
|
||
a33 1
|
||
Software development requirements including how to get client software to resolve URNs (see [[GUID2WgSoftwareDevelopment]])
|
||
d35 1
|
||
a35 1
|
||
What gets a GUID? - The architecture requires that the object identified by an LSID should be 'typed' therefore anything that can be explicitly typed, preferably with the TDWG ontology, could be named with an LSID.
|
||
d47 1
|
||
a47 1
|
||
1. The SVR DNS record should be used with the A Record as back-up
|
||
d49 1
|
||
a49 1
|
||
1. The discussion of accepted types for metadata is deferred
|
||
@
|
||
|
||
|
||
1.26
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@a41 7
|
||
---++++ General
|
||
|
||
Outreach - value of using GUIDs and RDF
|
||
|
||
To discuss how TDWG promotion of LSIDs would affect relationships with other communities: This goal evolved into the formation of an outreach group [GuidOutreach] to identify priorities for accellerating the update of LSIDs within the broader community associated with TDWG.
|
||
|
||
The group discussed mechanisms for metadata annotation and linkout. FAN can be useful for notification but cannot be effectively used to create backlinks to external annotations because of management issues. A possible solution would be to create a central service where agents could register any annotations that would be available to anyone in the community.
|
||
@
|
||
|
||
|
||
1.25
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@a19 16
|
||
---+++++ Break-out group discussions
|
||
1. Outreach
|
||
1. Institutional ownership and partitioning of data
|
||
1. The case for using RDF
|
||
1. Software development - filling the gaps, improving usability and extending functionality (see [[GUID2WgSoftwareDevelopment]])
|
||
1. How to deal with compound objects
|
||
|
||
---+++++ Plenary discussions
|
||
1. What gets a GUID? - The architecture requires that the object identified by an LSID should be
|
||
'typed' therefore anything that can be explicitly typed, preferably with the TDWG ontology, could be named with an LSID.
|
||
1. The case for using Versions in GUIDs (LSIDs) - much discussion but not enough evidence from case analysis. Needs a TDWG policy statement backed with examples. See: VersioningOfLSIDs
|
||
1. Discussion of external annotations and how these could be harvested
|
||
1. To discuss how TDWG promotion of LSIDs would affect relationships with other communities
|
||
1. This goal evolved into the formation of an outreach group [GuidOutreach] to identify priorities for accellerating the update of LSIDs within the broader community associated with TDWG.
|
||
1. Software development requirements including how to get client software to resolve URNs (see [[GUID2WgSoftwareDevelopment]])
|
||
1. The group discussed mechanisms for metadata annotation and linkout. FAN can be useful for notification but cannot be effectively used to create backlinks to external annotations because of management issues. A possible solution would be to create a central service where agents could register any annotations that would be available to anyone in the community.
|
||
d21 30
|
||
a50 1
|
||
---++++ 3. Out Comes
|
||
d72 1
|
||
a72 1
|
||
---++++ 4. Conclusions
|
||
d75 1
|
||
a75 1
|
||
---+++++ Annexes
|
||
@
|
||
|
||
|
||
1.24
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@a19 14
|
||
---+++++ Presentations
|
||
1. [[%ATTACHURL%/hobern_GUID2Day1Goals.ppt][Introduction and overview]] Donald Hobern
|
||
1. [[%ATTACHURL%/Hyam_TDWG_GUID-2_arch_03.ppt][Summary of architectural recommendations from TAG]] Roger Hyam
|
||
1. [[%ATTACHURL%/Rod-Page-TDWG-GUID2.ppt][LSID Tester]] Roderic Page
|
||
1. [[%ATTACHURL%/Perry_LSIDAndDiGIR2.ppt][LSID resolver for specimens in DiGIR2]] Steve Perry
|
||
1. Image LSID resolver prototypes Bob Morris
|
||
1. [[%ATTACHURL%/Richards_IndexFungorumSetup.ppt][Index Fungorum LSID authority setup]] Kevin Richards
|
||
1. [[%ATTACHURL%/Richards_LSIDFrameworkPort.ppt][Port of LSID framework to .NET]] Kevin Richards
|
||
1. LSID resolution in SEEK Jessie Kennedy
|
||
1. [[%ATTACHURL%/Pereira_GUID2_LSID_SW_Analysis_v3.ppt][Existing software components and gap analysis]] Ricardo Pereira
|
||
1. Core Ontology Jessie Kennedy
|
||
1. [[%ATTACHURL%/hobern_AdditionalComponentsOfAnLSIDNetwork.ppt][Additional components of an LSID network]] Donald Hobern
|
||
1. Publication Bank Robert Huber
|
||
|
||
d62 18
|
||
@
|
||
|
||
|
||
1.23
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d59 1
|
||
a59 1
|
||
1. There should be a central DNS service for LSIDs within the community. This service should optionally allocate LSIDs for those data providers who needed the service
|
||
@
|
||
|
||
|
||
1.22
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@a50 4
|
||
|
||
* A link to where more details about the meeting (such as PowerPoint presentations and minutes) can be found e.g. a wiki or website.
|
||
* A primary contact for the meeting e.g. "For more information contact xyz@@example.com
|
||
|
||
@
|
||
|
||
|
||
1.21
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d22 3
|
||
a24 3
|
||
1. Summary of architectural recommendations from TAG Roger Hyam
|
||
1. LSID Tester Roderic Page
|
||
1. LSID resolver for specimens in DiGIR2 Steve Perry
|
||
d26 2
|
||
a27 1
|
||
1. Index Fungorum LSID authority setup Kevin Richards
|
||
d29 1
|
||
a29 1
|
||
1. Existing software components and gap analysis Ricardo Pereira
|
||
d31 1
|
||
a31 1
|
||
1. Additional components of an LSID network Donald Hobern
|
||
@
|
||
|
||
|
||
1.20
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d21 1
|
||
a21 1
|
||
1. Introduction and overview Donald Hobern
|
||
@
|
||
|
||
|
||
1.19
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d65 5
|
||
a69 1
|
||
* Lee will write a short document promoting use of LSIDs and RDF to senior managers
|
||
d72 1
|
||
a72 1
|
||
* Ben will approach IBM over LSID resolver plugins
|
||
@
|
||
|
||
|
||
1.18
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d9 11
|
||
d54 1
|
||
a54 13
|
||
|
||
---++++ 2. Goals
|
||
|
||
1. To review the outcomes of the first Guid meeting and subsequent developments
|
||
1. To confirm the choice of LSIDs as persistent identifiers (GUIDs) for TDWG functional data types as defined in the imminent ontology
|
||
1. To discuss the governance of GUID allocation
|
||
1. To identify issues and discuss the options for ensuring long term availability and archival strategy for GUID objects (or their data sets)
|
||
1. To discuss any gaps and weaknesses in current GUID server and resolving software and to identify the actions required to address these issues.
|
||
1. To identify actions required to promote the benefits of using GUIDs to the taxonomic, biological research and biodiversity information communities
|
||
1. To identify the technical and ‘sociological' actions required to assist potential users to start serving GUIDs
|
||
1. To review and make recommendations on the incorporation of GUIDs and RDF into TDWG standards
|
||
|
||
---++++ 3. Out Come
|
||
@
|
||
|
||
|
||
1.17
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d26 1
|
||
a26 1
|
||
1. Software development - filling the gaps, improving usability and extending functionality (see GUID2WgSoftwareDevelopment)
|
||
d36 1
|
||
a36 1
|
||
1. Software development requirements including how to get client software to resolve URNs (see GUID2WgSoftwareDevelopment)
|
||
@
|
||
|
||
|
||
1.16
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d36 1
|
||
a36 1
|
||
1. Software development requirements including how to get client software to resolve URNs
|
||
@
|
||
|
||
|
||
1.15
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d26 1
|
||
a26 1
|
||
1. Software development - filling the gaps, improving usability and extending functionality
|
||
@
|
||
|
||
|
||
1.14
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d35 1
|
||
a35 1
|
||
1. This goal evolved into the formation of an outreach group to identify priorities for accellerating the update of LSIDs within the broader community associated with TDWG.
|
||
@
|
||
|
||
|
||
1.13
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d32 1
|
||
a32 1
|
||
1. The case for using Versions in GUIDs (LSIDs) - much discussion but not enough evidence from case analysis. Needs a TDWG policy statement backed with examples
|
||
@
|
||
|
||
|
||
1.12
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d76 1
|
||
a76 1
|
||
---++++ attendees
|
||
@
|
||
|
||
|
||
1.11
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d78 21
|
||
a98 21
|
||
Andrew Polaszek (ICZN: Sunday: Chair Day 2)
|
||
Ben Szekeley
|
||
Bob Morris
|
||
Charles Copp (Technical Writer)
|
||
Chuck Miller (Tropicos: Chair Day 1)
|
||
Damian Barnier
|
||
Dave Vieglais
|
||
Donald Hobern
|
||
Jessie Kennedy
|
||
Kevin Richards
|
||
Lee Belbin
|
||
Ricardo Pereira
|
||
Rich Pyle
|
||
Rob Gales
|
||
Robert Hubert
|
||
Rod Page
|
||
Roger Hyam
|
||
Sally Hinchcliffe (RBG)
|
||
Simon Coppard (ICZN)
|
||
Stan Blum
|
||
Steve Perry
|
||
d100 1
|
||
a100 1
|
||
Tom Orrell (ITIS: Chair Day 3)
|
||
@
|
||
|
||
|
||
1.10
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d74 30
|
||
a103 1
|
||
A short paragraph highlighting the main conclusions from the meeting and indicating what might happen next.@
|
||
|
||
|
||
1.9
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d74 1
|
||
a74 1
|
||
A short paragraph highlighting the main conclusions from the meeting and indicating what might happen next.
|
||
@
|
||
|
||
|
||
1.8
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d35 1
|
||
@
|
||
|
||
|
||
1.7
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d36 1
|
||
@
|
||
|
||
|
||
1.6
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d30 2
|
||
a31 1
|
||
1. What gets a GUID? meaningful data objects in the core ontology or anything that the provider wishes to share. How to decide on levels of granularity
|
||
@
|
||
|
||
|
||
1.5
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d51 2
|
||
a52 1
|
||
1. Out Come
|
||
@
|
||
|
||
|
||
1.4
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d10 11
|
||
a20 11
|
||
1. Introduction and overview Donald Hobern
|
||
2. Summary of architectural recommendations from TAG Roger Hyam
|
||
3. LSID Tester Roderic Page
|
||
4. LSID resolver for specimens in DiGIR2 Steve Perry
|
||
5. Image LSID resolver prototypes Bob Morris
|
||
6. Index Fungorum LSID authority setup Kevin Richards
|
||
7. LSID resolution in SEEK Jessie Kennedy
|
||
8. Existing software components and gap analysis Ricardo Pereira
|
||
9. Core Ontology Jessie Kennedy
|
||
10. Additional components of an LSID network Donald Hobern
|
||
11. Publication Bank Robert Huber
|
||
d23 5
|
||
a27 5
|
||
1. Outreach
|
||
2. Institutional ownership and partitioning of data
|
||
3. The case for using RDF
|
||
4. Software development - filling the gaps, improving usability and extending functionality
|
||
5. How to deal with compound objects
|
||
d30 5
|
||
a34 5
|
||
1. What gets a GUID? meaningful data objects in the core ontology or anything that the provider wishes to share. How to decide on levels of granularity
|
||
2. The case for using Versions in GUIDs (LSIDs) - much discussion but not enough evidence from case analysis. Needs a TDWG policy statement backed with examples
|
||
3. Discussion of external annotations and how these could be harvested
|
||
4. To discuss how TDWG promotion of LSIDs would affect relationships with other communities
|
||
5. Software development requirements including how to get client software to resolve URNs
|
||
d37 2
|
||
a38 2
|
||
• A link to where more details about the meeting (such as PowerPoint presentations and minutes) can be found e.g. a wiki or website.
|
||
• A primary contact for the meeting e.g. "For more information contact xyz@@example.com
|
||
d43 9
|
||
a51 9
|
||
1. To review the outcomes of the first Guid meeting and subsequent developments
|
||
2. To confirm the choice of LSIDs as persistent identifiers (GUIDs) for TDWG functional data types as defined in the imminent ontology
|
||
3. To discuss the governance of GUID allocation
|
||
4. To identify issues and discuss the options for ensuring long term availability and archival strategy for GUID objects (or their data sets)
|
||
5. To discuss any gaps and weaknesses in current GUID server and resolving software and to identify the actions required to address these issues.
|
||
6. To identify actions required to promote the benefits of using GUIDs to the taxonomic, biological research and biodiversity information communities
|
||
7. To identify the technical and ‘sociological' actions required to assist potential users to start serving GUIDs
|
||
8. To review and make recommendations on the incorporation of GUIDs and RDF into TDWG standards
|
||
3. Out Come
|
||
d54 6
|
||
a59 6
|
||
1. LSIDs will be used as unique identifiers
|
||
2. HTTP GET will be the default binding for getMetadata calls
|
||
3. The SVR DNS record should be used with the A Record as back-up
|
||
4. RDF will be the default metadata response format
|
||
5. The discussion of accepted types for metadata is deferred
|
||
6. There should be a central DNS service for LSIDs within the community. This service should optionally allocate LSIDs for those data providers who needed the service
|
||
d62 6
|
||
a67 6
|
||
1. Lee will write a short document promoting use of LSIDs and RDF to senior managers
|
||
2. More useful and informative material to be placed on the website
|
||
3. Ricardo and roger to review software gaps and attempt to at least produce a packaged installer and improved documentation for setting up LSID server software.
|
||
4. Ben will approach IBM over LSID resolver plugins
|
||
5. Encourage development of ‘good news' demonstrations through ant and fish communities
|
||
6. Review tasks involved and host for setting up a central DNS server service for LSIDs
|
||
@
|
||
|
||
|
||
1.3
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d1 1
|
||
a1 1
|
||
---+++++ =GUID-2 Report
|
||
d3 3
|
||
a5 3
|
||
Second International Workshop on Globally Unique Identifiers (GUIDs) for Biodiversity Infromatics (GUID-2)
|
||
10th - 12th June 2006
|
||
e-Science Institute, Edinburgh
|
||
@
|
||
|
||
|
||
1.2
|
||
log
|
||
@
|
||
.
|
||
@
|
||
text
|
||
@d7 1
|
||
a7 1
|
||
===1. Summary
|
||
d9 1
|
||
a9 1
|
||
==Presentations
|
||
d22 1
|
||
a22 1
|
||
==Break-out group discussions
|
||
d29 1
|
||
a29 1
|
||
==Plenary discussions
|
||
d41 1
|
||
a41 1
|
||
===2. Goals
|
||
d53 1
|
||
a53 1
|
||
==Recommendations
|
||
d61 1
|
||
a61 1
|
||
==Actions
|
||
d69 1
|
||
a69 1
|
||
===4. Conclusions
|
||
@
|
||
|
||
|
||
1.1
|
||
log
|
||
@Initial revision
|
||
@
|
||
text
|
||
@d1 2
|
||
a5 1
|
||
1. Summary
|
||
d7 3
|
||
a9 1
|
||
Presentations
|
||
d22 1
|
||
a22 1
|
||
Break-out group discussions
|
||
d29 1
|
||
a29 1
|
||
Plenary discussions
|
||
d39 3
|
||
a41 1
|
||
2. Goals
|
||
a51 1
|
||
Recommendations
|
||
d53 1
|
||
d61 1
|
||
a61 1
|
||
Actions
|
||
d69 1
|
||
a69 1
|
||
4. Conclusions
|
||
a70 5
|
||
|
||
Appendix A: Attendees
|
||
Name Email Institution
|
||
Mike Example mike@@example.com Example institution, Example Country.
|
||
|
||
@
|