Hi

I'm attaching a copy of an RDF file of IPNI data which is in RDF/TCS. (I thought it it was on the wiki but now I can't find it) which covers all ranks and various examples (records with basionyms, records with types etc.)

If you look on the wiki there is also information about our LSID server. We've not been working on it for a while so it's pretty much in the state we left it after the GUIDs workshop. Over the next few weeks we hope to get back going with it and update the wiki particularly with the details of how we handle versioning. There are also some notes on the wiki about things I had problems with with the version of TCS/RDF that Roger had circulated. I don't know if it's been changed since ...

HTH

Sally

Hi everyone,

I am in the process of putting together the LSID service component of Zoobank.org, after a few initial hiccups and difficulties I have a basic service up and running in the development environment.

Now I have arrived at the contentious issue of what data/metadata to return and in which flavour.

I have a few questions...

1. What format should I return the metadata response in? From

discussions with Roger it seems appropriate to go with RDF/TCS for the metadata reponse. Would this be a good way to go, and does anyone have any static examples of such a response?

2. If a Data service were implemented, should the response simply be the

LSID or the taxon name as we don't currently hold any holotype photos etc.

2. Is there any standard scheme for LSID discovery? i.e. Would it be a

good/bad idea to extend the LSID service to allow machine queries of LSIDs by taxon name rather than discovering them through the web interface?

Any comments and suggestions are very welcome!

Regards, Peter.

Peter Hollas MSc BSc(hons) (Peter.Hollas@thomson.com) Software Engineer / Systems Administrator Thomson Zoological Innovation Centre York Science Park Heslington York YO10 5DG

Tel: 01904-435113 Fax: 01904-435114

---

TDWG-GUID mailing list TDWG-GUID@mailman.nhm.ku.edu http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid

*** Sally Hinchcliffe *** Computer section, Royal Botanic Gardens, Kew *** tel: +44 (0)20 8332 5708 *** S.Hinchcliffe@rbgkew.org.uk

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE rdf:RDF [ <!ENTITY tn 'http://tdwg.org/2006/03/12/TaxonNames/'>]>

<rdf:RDF xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:tn="http://tdwg.org/2006/03/12/TaxonNames/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#%22%3E

<!-- example family (has an unlinked typifying name with non-standard format data)--> <tn:TaxonName rdf:about="urn:lsid:ipni.org:names:30000959-2:1.1.2.1"> <tn:nomenclaturalCode rdf:resource="&tn;#botanical" /> dc:titleAmaryllidaceae J.St.-Hil.</dc:title> dcterms:created2004-01-20 00:00:00.0</dcterms:created> dcterms:modified2005-06-23 15:45:33.0</dcterms:modified> tn:rankStringfam.</tn:rankString> tn:nameCompleteAmaryllidaceae</tn:nameComplete> tn:uninomialAmaryllidaceae</tn:uninomial> tn:authorshipJ.St.-Hil.</tn:authorship> tn:publishedInExpos. Fam. Nat. 1: 134. 1805 [Feb-Apr 1805]</tn:publishedIn> tn:year1805</tn:year> tn:typifiedBy tn:NomenclaturalType dc:titleAmaryllis Linnaeus, nom. cons.</dc:title> </tn:NomenclaturalType> </tn:typifiedBy> </tn:TaxonName>

<!-- example infra family ... has a typifying name (unlinked) ...-->

<tn:TaxonName rdf:about="urn:lsid:ipni.org:names:312219-2:1.2"> <tn:nomenclaturalCode rdf:resource="&tn;#botanical" /> dc:titlesubtrib. Baccaridinae Less.</dc:title> dcterms:created2004-01-20 00:00:00.0</dcterms:created> dcterms:modified2005-08-19 15:59:04.0</dcterms:modified> tn:rankStringsubtrib.</tn:rankString> tn:nameCompletesubtrib. Baccaridinae</tn:nameComplete> tn:uninomialBaccaridinae</tn:uninomial> tn:authorshipLess.</tn:authorship> tn:publishedInLinnaea 5: 145. 1830</tn:publishedIn> tn:year1830</tn:year> tn:typifiedBy tn:NomenclaturalType dc:titleBaccharis L.</dc:title> </tn:NomenclaturalType> </tn:typifiedBy> </tn:TaxonName>

<!-- example genus. Has ex authorship --> <tn:TaxonName rdf:about="urn:lsid:ipni.org:names:1786-1:1.1.2.1.1.1"> <tn:nomenclaturalCode rdf:resource="&tn;#botanical" /> dc:titleDodonaea Plum. ex Adans.</dc:title> dcterms:created2003-07-02 00:00:00.0</dcterms:created> dcterms:modified2005-11-29 09:12:00.0</dcterms:modified> tn:rankStringgen.</tn:rankString> tn:nameCompleteDodonaea</tn:nameComplete> tn:uninomialDodonaea</tn:uninomial> tn:authorshipPlum. ex Adans.</tn:authorship> tn:publishedInFam. ii. 342 (1763).</tn:publishedIn> </tn:TaxonName>

<!-- example genus. Has a linked type name --> <tn:TaxonName rdf:about="urn:lsid:ipni.org:names:60435733-2:1.1.2.1"> <tn:nomenclaturalCode rdf:resource="&tn;#botanical" /> dc:titleRenistipula Borhidi</dc:title> dcterms:created2004-09-07 06:46:08.0</dcterms:created> dcterms:modified2004-09-07 06:50:11.0</dcterms:modified> tn:rankStringgen.</tn:rankString> tn:nameCompleteRenistipula</tn:nameComplete> tn:uninomialRenistipula</tn:uninomial> tn:authorshipBorhidi</tn:authorship> tn:publishedInActa Bot. Hung. 46(1-2): 122 (-123). 2004</tn:publishedIn> tn:year2004</tn:year> tn:typifiedBy tn:NomenclaturalType dc:titleRenistipula galeottii (Standl.) Borhidi</dc:title> <tn:typeName rdf:resource="urn:lsid:ipni.org:Names:60435735-2"/> </tn:NomenclaturalType> </tn:typifiedBy> </tn:TaxonName>

<!-- example infra genus. Is a validation of another ipni record --> <tn:TaxonName rdf:about="urn:lsid:ipni.org:names:70029497-1:1.1"> <tn:nomenclaturalCode rdf:resource="&tn;#botanical" /> dc:titleAstrophytum subgen. Stigmatodactylus D.R.Hunt</dc:title> dcterms:created2003-10-15 08:31:34.0</dcterms:created> dcterms:modified2003-10-15 08:31:34.0</dcterms:modified> tn:rankStringsubgen.</tn:rankString> tn:nameCompleteAstrophytum subgen. Stigmatodactylus</tn:nameComplete> tn:genusPartAstrophytum</tn:genusPart> tn:infragenericEpithetStigmatodactylus</tn:infragenericEpithet> tn:authorshipD.R.Hunt</tn:authorship> tn:publishedInCactaceae Syst. Init. 16: 4 (11 Oct. 2003).</tn:publishedIn> tn:year2003</tn:year> tn:hasAnnotation tn:NomenclaturalNote <tn:noteType rdf:resource="&tn;#basedOn"/> <tn:objectTaxon rdf:resource="urn:lsid:ipni.org:names:70028178-1"/> </tn:NomenclaturalNote> </tn:hasAnnotation> </tn:TaxonName>

<!-- example species. Is a replacement name (nomen novum) --> <tn:TaxonName rdf:about="urn:lsid:ipni.org:names:907328-1:1.1.4.2.2.1"> <tn:nomenclaturalCode rdf:resource="&tn;#botanical" /> dc:titleGentlea costaricensis Lundell</dc:title> dcterms:created2003-07-02</dcterms:created> dcterms:modified2006-01-15</dcterms:modified> tn:rankStringspec.</tn:rankString> tn:nameCompleteGentlea costaricensis</tn:nameComplete> tn:genusPartGentlea</tn:genusPart> tn:specificEpithetcostaricensis</tn:specificEpithet> tn:authorshipLundell</tn:authorship> tn:publishedInWrightia 6(5): 115 (1980), nom. nov.:.</tn:publishedIn> tn:hasAnnotation tn:NomenclaturalNote <tn:noteType rdf:resource="&tn;#replacementNameFor"/> <tn:objectTaxon rdf:resource="urn:lsid:ipni.org:names:587264-1"/> </tn:NomenclaturalNote> </tn:hasAnnotation> </tn:TaxonName> <!-- example species. Has type data --> <tn:TaxonName rdf:about="urn:lsid:ipni.org:names:1002492-1:1.1.2.2"> <tn:nomenclaturalCode rdf:resource="&tn;#botanical" /> dc:titleMaxillaria machinazensis D.E.Benn. &amp; Christenson</dc:title> dcterms:created2003-07-02 00:00:00.0</dcterms:created> dcterms:modified2006-01-15 06:10:58.0</dcterms:modified> tn:rankStringspec.</tn:rankString> tn:nameCompleteMaxillaria machinazensis</tn:nameComplete> tn:genusPartMaxillaria</tn:genusPart> tn:specificEpithetmachinazensis</tn:specificEpithet> tn:authorshipD.E.Benn. &amp; Christenson</tn:authorship> tn:publishedInin Lindleyana, 13(2): 71 (1998)—.</tn:publishedIn> tn:year1998</tn:year> tn:typifiedBy tn:NomenclaturalType dc:titleM. Cavero B. et al. 1642, NY (holo)</dc:title> tn:typeSpecimenM. Cavero B. et al. 1642, NY</tn:typeSpecimen> <tn:typeOfType rdf:resource="&tn;#holo" /> </tn:NomenclaturalType> </tn:typifiedBy> tn:typifiedBy tn:NomenclaturalType dc:titleM. Cavero B. et al. 1642, USM (iso)</dc:title> tn:typeSpecimenM. Cavero B. et al. 1642, USM</tn:typeSpecimen> <tn:typeOfType rdf:resource="&tn;#iso" /> </tn:NomenclaturalType> </tn:typifiedBy> </tn:TaxonName>

<!-- example species. Has a Lectotypification --> <tn:TaxonName rdf:about="urn:lsid:ipni.org:names:199571-2:1.2"> <tn:nomenclaturalCode rdf:resource="&tn;#botanical" /> dc:titlePiper wrightii C.DC.</dc:title> dcterms:created2004-01-20 00:00:00.0</dcterms:created> dcterms:modified2004-12-23 14:43:26.0</dcterms:modified> tn:rankStringspec.</tn:rankString> tn:nameCompletePiper wrightii</tn:nameComplete> tn:genusPartPiper</tn:genusPart> tn:specificEpithetwrightii</tn:specificEpithet> tn:authorshipC.DC.</tn:authorship> tn:publishedInSymb. Antill. 3: 189. 1902</tn:publishedIn> tn:year1902</tn:year> tn:typifiedBy tn:NomenclaturalType dc:titleWright 1687, GOET (lecto)</dc:title> <tn:typeOfType rdf:resource="&tn;#lecto"/> tn:typeSpecimenWright 1687, GOET</tn:typeSpecimen> tn:lectotypePublicationSaralegui in Fl. Rep. Cuba, Ser. A. Pl. Vasc. 9(3): 80. 2004</tn:lectotypePublication> </tn:NomenclaturalType> </tn:typifiedBy> </tn:TaxonName>

<!-- example species. Has a Lectotypification with multiple isolectotypes --> <tn:TaxonName rdf:about="urn:lsid:ipni.org:names:265591-2:1.3.2.1"> <tn:nomenclaturalCode rdf:resource="&tn;#botanical" /> dc:titleVincetoxicum gentlei Lundell &amp; Standl.</dc:title> dcterms:created2004-01-20 00:00:00.0</dcterms:created> dcterms:modified2006-01-18 13:49:55.0</dcterms:modified> tn:rankStringspec.</tn:rankString> tn:nameCompleteVincetoxicum gentlei</tn:nameComplete> tn:genusPartVincetoxicum</tn:genusPart> tn:specificEpithetgentlei</tn:specificEpithet> tn:authorshipLundell &amp; Standl.</tn:authorship> tn:publishedInField Mus. Nat. Hist., Bot. Ser. 17: 269. 1937</tn:publishedIn> tn:year1937</tn:year> tn:typifiedBy tn:NomenclaturalType dc:titleP. Gentle 1779, MICH (lecto)</dc:title> <tn:typeOfType rdf:resource="&tn;#lecto"/> tn:typeSpecimenP. Gentle 1779, MICH</tn:typeSpecimen> tn:lectotypePublicationW.D.Stevens in Novon 15(4): 612. 2005 [12 Dec 2005]</tn:lectotypePublication> </tn:NomenclaturalType> </tn:typifiedBy> tn:typifiedBy tn:NomenclaturalType dc:titleP. Gentle 1779, A (isolecto)</dc:title> <tn:typeOfType rdf:resource="&tn;#iso"/> tn:typeSpecimenP. Gentle 1779, A</tn:typeSpecimen> tn:lectotypePublicationW.D.Stevens in Novon 15(4): 612. 2005 [12 Dec 2005]</tn:lectotypePublication> </tn:NomenclaturalType> </tn:typifiedBy> tn:typifiedBy tn:NomenclaturalType dc:titleP. Gentle 1779, F (isolecto)</dc:title> <tn:typeOfType rdf:resource="&tn;#iso"/> tn:typeSpecimenP. Gentle 1779, F</tn:typeSpecimen> tn:lectotypePublicationW.D.Stevens in Novon 15(4): 612. 2005 [12 Dec 2005]</tn:lectotypePublication> </tn:NomenclaturalType> </tn:typifiedBy> tn:typifiedBy tn:NomenclaturalType dc:titleP. Gentle 1779, MO (isolecto)</dc:title> <tn:typeOfType rdf:resource="&tn;#iso"/> tn:typeSpecimenP. Gentle 1779, MO</tn:typeSpecimen> tn:lectotypePublicationW.D.Stevens in Novon 15(4): 612. 2005 [12 Dec 2005]</tn:lectotypePublication> </tn:NomenclaturalType> </tn:typifiedBy> tn:typifiedBy tn:NomenclaturalType dc:titleP. Gentle 1779, P (isolecto)</dc:title> <tn:typeOfType rdf:resource="&tn;#iso"/> tn:typeSpecimenP. Gentle 1779, P</tn:typeSpecimen> tn:lectotypePublicationW.D.Stevens in Novon 15(4): 612. 2005 [12 Dec 2005]</tn:lectotypePublication> </tn:NomenclaturalType> </tn:typifiedBy> tn:typifiedBy tn:NomenclaturalType dc:titleP. Gentle 1779, US (isolecto)</dc:title> <tn:typeOfType rdf:resource="&tn;#iso"/> tn:typeSpecimenP. Gentle 1779, US</tn:typeSpecimen> tn:lectotypePublicationW.D.Stevens in Novon 15(4): 612. 2005 [12 Dec 2005]</tn:lectotypePublication> </tn:NomenclaturalType> </tn:typifiedBy> </tn:TaxonName> <!-- example infraspecific name. Has a basionym and is also a later homonym of something --> <tn:TaxonName rdf:about="urn:lsid:ipni.org:names:60433970-2:1.2"> <tn:nomenclaturalCode rdf:resource="&tn;#botanical" /> dc:titleMalus orientalis var. montana (Uglitzk.) Ponomar.</dc:title> dcterms:created2004-07-01 04:44:21.0</dcterms:created> dcterms:modified2004-11-25 11:58:58.0</dcterms:modified> tn:rankStringvar.</tn:rankString> tn:nameCompleteMalus orientalis var. montana</tn:nameComplete> tn:genusPartMalus</tn:genusPart> tn:specificEpithetorientalis</tn:specificEpithet> tn:infraspecificEpithetmontana</tn:infraspecificEpithet> tn:authorship(Uglitzk.) Ponomar.</tn:authorship> tn:basionymAuthorshipUglitzk.</tn:basionymAuthorship> tn:combinationAuthorshipPonomar.</tn:combinationAuthorship> tn:publishedInSborn. Nauchn. Trudov Prikl. Bot. Genet. Selekts. 146: 7. 1992</tn:publishedIn> tn:year1992</tn:year> <tn:hasBasionym rdf:resource="urn:lsid:ipni.org:Names:895825-1"/> tn:hasAnnotation tn:NomenclaturalNote <tn:noteType rdf:resource="&tn;#laterHomonymOf"/> <tn:objectTaxon rdf:resource="urn:lsid:ipni.org:names:985539-1"/> </tn:NomenclaturalNote> </tn:hasAnnotation> tn:hasAnnotation tn:NomenclaturalNote <tn:noteType rdf:resource="&tn;#publicationStatus"/> tn:notenom. illeg. later homonym</tn:note> </tn:NomenclaturalNote> </tn:hasAnnotation> </tn:TaxonName> </rdf:RDF>

Hi Peter,

peter.hollas@thomson.com wrote:

2. Is there any standard scheme for LSID discovery? i.e. Would it be a

good/bad idea to extend the LSID service to allow machine queries of LSIDs by taxon name rather than discovering them through the web interface?

Any comments and suggestions are very welcome!

Regards, Peter.

In my view, LSID is primarily a naming scheme. While it does allow for the resolution of data objects, it was not designed to support other common data access tasks such as discovery, search, query, or harvest. To support these additional data access tasks I feel we ought to look to other standard or well-established protocols. Some protocols, like the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) are well suited to harvesting. Others, like the W3C's SPARQL protocol are well suited to search and query. Unfortunately there's no single protocol for working with RDF data that does everything we need. The problem for data providers is that each additional protocol that they are asked to support adds an additional burden on them. At the same time, the easier a provider makes it to access their data, the more their data will be used. However, many data providing organizations wish to devote their resources to the creation and curation of data, rather than to the implementation of data access protocols.

We're hoping to provide an end-to-end solution for this problem with the wasabi project (formally known as DiGIR2). While the rest of this message is a bit of a plug, for wasabi, it also acts to illustrate the fact that different stakeholders in a data network have different requirements for data access.

The central idea behind wasabi is that data providing organizations generate RDF data objects, assign LSIDs to them, and drop them into a locally-installed wasabi server. The wasabi server makes data objects available through a variety of standard data access protocols. It supports LSID to metadata resolution through a simple HTTP-get protocol and through a plugin to the IBM LSID resolver. The wasabi server also allows data aggregators to use OAI-PMH to efficiently fetch data objects in bulk so that they can be indexed for search. One benefit of the OAI protocol, especially the implementation in the wasabi server, is that it allows for incremental harvesting. Because it only sends the data objects that have changed since the last harvest, OAI-PMH decreases the load on a provider's server and allows for fast indexing of their data. Finally the wasabi server provides direct SPARQL query access to data objects. Any time a wasabi server is queried (through OAI, SPARQL, or LSID resolution), the access is logged. This helps data providers keep track of who is using their data.

If a provider doesn't want to write a custom program that generates RDF/XML they can use the wasabi server's synchronizer program, along with a concept mapping configuration file, to periodically connect to their database, transform its contents into RDF data objects, and load them into the wasabi server. The wasabi server will keep track of which objects are newly added, deleted, or updated.

The RDF server is only one component of the wasabi project. It also includes a library that implements the client side of the supported data access protocols. This makes it easy for people to write custom software to grab data from wasabi servers. Researchers who want to gather large amounts of data for analysis can use the client library to simplify the task.

Another important part of the wasabi project is the indexer. The indexer supports harvesting from multiple distributed wasabi servers. Harvested data are then pushed into the indexer which can generate indices that are designed to support various types of queries. For example, the indexer can use a Google-style inverted index that is well suited to full-text queries, a database with geospatial extensions to support geographical queries, or even a triple store. The wasabi indexer could be used by large data aggregators like GBIF or by custom software developers. One example of the later are the developers of collections management software who might want to index and cache data from TCS providers so that their users can associate specimens with taxon concepts through an easy to use desktop software package.

Both the client library and the indexer allow computers to access and work with data. The wasabi project also provides an extensible web portal. Built over the client library and an index of data objects harvested from wasabi servers, the portal component allows data to be accessed by people through a customizable interface. It supports browsing, searching, and downloading of data objects. One use for the portal component might be as the public face of a thematic data networks like FishNet2, MaNIS, OrNIS, or HerpNet.

The wasabi project is free and open source. It is implemented in Java. The server, client library, and indexer portions of the project are now in beta and we plan to release them by the end of the year. The portal is still under active development.

I'll be presenting wasabi at the TDWG meeting in St. Louis next month.

-Steve