- tdwg-content - lists.tdwg.org

ECN 2010 "Biodiversity Informatics on the Semantic Web" Talk available on SlideShare
by Peter DeVries 13 Dec '10

13 Dec '10

I just uploaded my talk to slideshare. http://www.slideshare.net/pjdwi/biodiversity-informatics-on-the-semantic-web I added some of the things I ad-libbed or were not clear from the slides themselves - so the text should be easy to follow. - Pete --------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------

1 0

Invitation to connect on LinkedIn
by Peter DeVries 13 Dec '10

13 Dec '10

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Peter Peter DeVries Ph.D. Dissertator at Department of Entomology, University of Wisconsin Madison, Wisconsin Area Confirm that you know Peter DeVries https://www.linkedin.com/e/-pnstdp-ghnv035t-1d/isd/2020277116/PfDV2eoc/ -- (c) 2010, LinkedIn Corporation

1 0

Re: [tdwg-content] proposed term: dwc:verbatimScientificName
by Peter DeVries 09 Dec '10

09 Dec '10

Ebird and NCBI have just genus and specific epithet, most publications have just the genus and specific epithet. That is what you have to match against first and then try to determine what is the most appropriate or intended authority. Essentially you have a has many relationship with scientificName hasMany authorities (authorship strings) Also what is not made clear in your earlier example is that Every scientificName: Lobelia spicata var. spicata is an instance of scientificName: Lobelia spicata In relation to occurrence records you will have specimens of Lobelia spicata var. spicata that were identified as Lobelia spicata. This should be done in away where those searching for specimens etc of Lobelia spicata also get those entries labeled Lobelia spicata var. spicata and Lobelia spicata ssp. spicata etc. Respectfully, - Pete On Thu, Dec 9, 2010 at 10:54 AM, Richard Pyle <deepreef(a)bishopmuseum.org>wrote: > They cannot provide a verbatimScientificName???? That would imply they have > no text field whatsoever. > > > > *From:* Peter DeVries [mailto:pete.devries@gmail.com] > *Sent:* Thursday, December 09, 2010 6:47 AM > *To:* Richard Pyle > *Subject:* Re: [tdwg-content] proposed term: dwc:verbatimScientificName > > > > So basically what you are saying is that the entire NCBI taxonomy database > as well as the ebird database cannot output the required format. > > > > - Pete > > On Thu, Dec 9, 2010 at 9:44 AM, Richard Pyle <deepreef(a)bishopmuseum.org> > wrote: > > I think this is **exactly** the right solution. I would go further to make > it clear that: > > > > - verbatimScientificName is the required field (with > scientificName and scientificNameAuthorship as optional) > > - When a source database maintains separate fields corresponding > to scientificName and scientificNameAuthorship, they should be concatenated > (with a single space between them) to form the required > verbatimScientificName > > > > Aloha, > > Rich > > > > *From:* tdwg-content-bounces(a)lists.tdwg.org [mailto: > tdwg-content-bounces(a)lists.tdwg.org] *On Behalf Of *David Remsen (GBIF) > *Sent:* Wednesday, December 08, 2010 6:10 AM > *To:* tdwg-content(a)lists.tdwg.org List > *Subject:* [tdwg-content] proposed term: dwc:verbatimScientificName > > > > Markus and I wanted to try to consolidate the issues related to the current > use and definition of scientificName that have been the focus of last weeks > discussion in as simple a way as we can and leave it with a simple proposal > which we will add to the issue tracking on the project site. > > > > 1. We propose that a new term, dwc:verbatimScientificName carry the > existing definition for dwc:scientificName and > > 2. dwc:scientificName follow the more accepted convention that is better > represented by the earlier proposed definition for Canonical Name > > > > The intention is to enable data publishers to distinguish unparsed, complex > scientific names from more cleanly separated scientific name data. This > will relieve consumers of these data from testing each instance of a name > for one of these two conditions. > > > > Here are the definitions for the two existing terms that have been part of > the discussion: > > > > *dwc:scientificName * - The full scientific name, with authorship and date > information if known. When forming part of an Identification, this should be > the name in lowest level taxonomic rank that can be determined. This term > should not contain identification qualifications, which should instead be > supplied in the IdentificationQualifier term. > > > > *dwc:scientificNameAuthorship* - The authorship information for the > scientificName formatted according to the conventions of the applicable > nomenclaturalCode. > > > > Here are terms and definitions used in the following 5 source data > configurations we came up with. They don't have to be exact for this > purpose. > > > > *canonical name* - The nomenclatural components of a scentific name > without authorship information. > > *authorship* - the authorship information that follows a scientific name > > *verbatim name* - the verbatim text stored in a source database when it > differs from or combines the two definitions above. This is a bit more > broad than the def for scientificName. > > > > We identified the following configurations in a source database and how > they would be mapped to the existing terms. In cases 4 and 5 we also > propose how we would map these were there a 3rd available term (called > 'mapping b:') > > > > When a source database contains: > > > > 1. canonical names only > > > > Mapping: canonical name -> dwc:scientificName > > > > 2. canonical name and authorship in two fields > > > > Mapping: canonical name -> dwc:scientificName / > authorship->dwc:scientificNameAuthorship > > > > 3. verbatim name only > > > > Mapping: verbatim name -> dwc:scientificName > > > > 4. all three: canonical name, authorship, and verbatim name in 3 diff. > columns > > > > Mapping a: verbatim name -> dwc:scientificName / > authorship->dwc:scientificNameAuthorship > > > > Mapping b: canonical name -> dwc:scientificName / > authorship->dwc:scientificNameAuthorship / verbatim name -> > dwc:verbatimScientificName > > > > 5. a mix of canonical and verbatim names in a single column > > > > Mapping a: verbatim name + canonical names -> dwc:scientificName > > > > Mapping b: verbatim name + canonical names -> dwc:verbatimScientificName > > > > Summary - with the current two terms are left with no choice but to support > both canonical and verbatim names in a single term, which makes consuming > these data difficult. > > > > We propose that a new term, dwc:verbatimScientificName carry the existing > definition for dwc:scientificName and that dwc:scientificName follow the > more accepted convention that is better represented by the definition for > Canonical Name > > > > Best, > > David Remsen / Markus Döring > > > > > > > > > _______________________________________________ > tdwg-content mailing list > tdwg-content(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-content > > > > > -- > --------------------------------------------------------------- > Pete DeVries > Department of Entomology > University of Wisconsin - Madison > 445 Russell Laboratories > 1630 Linden Drive > Madison, WI 53706 > TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies > Knowledge Base <http://lod.geospecies.org/> > About the GeoSpecies Knowledge Base <http://about.geospecies.org/> > ------------------------------------------------------------ > -- --------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------

2 1

Does a species entail a specific classification or does it have many classifications.
by Peter DeVries 29 Nov '10

29 Nov '10

This is in response to David's example here; http://code.google.com/p/gbif-ecat/wiki/Nom5ExampleMytilusedulis It demonstrates a number of issues, the main one being it is not clear what the intent of the GBIF submitter was. Mytilus edulis Linnaeus 1758 <= Appears to be the correct name Mytilus edulis Linné 1758 <= Appears to be a lexical variant of the correct name Mytilus edulis d' Orbigny <= Is this an error, a different description or a different species? Mytilus edulis Pennant <= Is this an error, a different description or a different species? Mytilus edulis <= Is this an ommission, an error, a different description or a different species? The intent of the GBIF contributor is in some cases not clear from the list above. It is unclear what species they actually mean, and it is unclear if intend on entailing a specific classification or not. Was it clear that they thought *Mytilus edulis* Linnaeus 1758 = *Mytilus edulis* Linné 1758 or not? How do you determine their intent from the simple name string? I think the intent be clearer if the submitter included a species concept URI with their submission. A URI that showed that a species has multiple often dynamic classifications, some of which are linkable via semantic web URI's. For example: Wikipedia (http://en.wikipedia.org/wiki/Blue_mussel) => http://dbpedia.org/resource/Blue_mussel Kingdom Animalia Phylum Mollusca Class Bivalvia Subclass Heterodonta Order Mytiloida Family Mytilidae Subfamily Mytilinae Genus Mytilus Species Mytilus edulis ITIS (79454) Kingdom Animalia Phylum Mollusca Class Bivalvia Subclass Pteriomorphia Order Mytiloida Family Mytilidae Genus Mytilus Species Mytilus edulis WORMS (140480) Biota Kingdom Animalia Phylum Mollusca Class Bivalvia Subclass Pteriomorphia Order Mytiloida Family Mytilidae Genus Mytilus Species Mytilus edulis CoL (6979242) Kingdom Animalia Phylum Mollusca Class Bivalvia Order Mytiloida Family Mytilidae Genus Mytilus Species Mytilus edulis NCBI (6550) => "http://purl.uniprot.org/taxonomy/6550"/ cellular organisms Eukaryota Fungi/Metazoa group Metazoa Eumetazoa Bilateria Coelomata Protostomia Mollusca Bivalvia Pteriomorphia Mytiloida Mytiloidea Mytilidae Mytilinae Mytilus Mytilus edulis EUNIS Kingdom Animalia Phylum MOLLUSCA Class Bivalvia Order Anisomyaria Family Mytilidae Genus Mytilus Mytilus edulis Linné, 1758 The example below is not the same species as above but it shows how the intent might be made clearer. Urosalpinx cinerea (Say 1822) => "by this I mean the same species concept as se:Zom2X" => http://lod.taxonconcept.org/ses/Zom2X.html * This would be better if the concept description had more data like photo's, type specimens etc, but it does link to them and DNA barcodes. The next version will also link to GBIF => http://data.gbif.org/species/13750666/ HTML http://lod.taxonconcept.org/ses/Zom2X.html RDF http://lod.taxonconcept.org/ses/Zom2X.rdf <http://lod.taxonconcept.org/ses/Zom2X.rdf>TXNburner* ( http://lsd.taxonconcept.org/describe/?url=http%3A%2F%2Flod.taxonconcept.org… ) Sindice http://sig.ma/search?pid=7a8281129fa5ae55af919c7b90e97544 * If this did not go through your email correctly you can get to it from the http://lod.taxonconcept.org/ses/Zom2X.html or http://bit.ly/hyTnXf These are not perfect but they already make it more clear what data sets relate to the same species and what data sets relate to different species. By linking to one of these, you are accepting that a species can have multiple classifications and there can be multiple names for the your intended concept. Respectfully, - Pete --------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------

6 13

First Comments on the GBIF KOS Report
by Peter DeVries 27 Nov '10

27 Nov '10

I thought that it might be useful to provide some initial comments on the GBIF KOS Report. There are several issues but I will mention only a few in this email. The first is *"There appear to be no systematic attempts to develop use cases, competency questions, or other goals for use of KOS in the biodiversity informatics community."* What about these resources and efforts that have been going on for several years? http://about.geospecies.org/ http://about.geospecies.org/sparql.xhtml http://www.taxonconcept.org/example-sparql-queries/ http://www.taxonconcept.org/ Note that this seems to be the only open SPARQL endpoint that is devoted to biodiversity informatics. http://www.taxonconcept.org/sparql-endpoint/ It is also the SPARQL endpoint for a number of the data sets that are mentioned. It also has the only examples which use the "IETF scheme for URIs for geographic locations" mentioned in the report. Also this: *"there appears to be no semantically enabled discovery of these resources. Work across subdisciplines is hampered by this, as scientists haphazardly locate resources which may or may not be the most fit for their purpose. For example, a field biologist made aware of ITIS might never become aware of its relationship to the Catalog of Life."* This RDF snippet is from this record ( http://lod.geospecies.org/ses/v6n7p.html ) one of several thousand that have been around for years. By querying one of the various LOD services a human or machine would find this interlinking. <skos:closeMatch rdf:resource="urn:lsid:ubio.org:namebank:105509"/> <skos:closeMatch rdf:resource="urn:lsid:catalogueoflife.org: taxon:24e7d624-60a7-102d-be47-00304854f810:ac2010"/> <skos:closeMatch rdf:resource="http://www.uniprot.org/taxonomy/9696"/> <skos:closeMatch rdf:resource="http://bio2rdf.org/taxon:9696"/> <rdfs:seeAlso rdf:resource="http://bio2rdf.org/taxon:9696"/> <skos:closeMatch rdf:resource="http://dbpedia.org/resource/Cougar"/> <rdfs:seeAlso rdf:resource="http://dbpedia.org/resource/Cougar"/> <skos:closeMatch rdf:resource=" http://rdf.freebase.com/ns/guid.9202a8c04000641f800000000008b5a3"/> <skos:closeMatch rdf:resource=" http://sw.opencyc.org/concept/Mx4rvVj5o5wpEbGdrcN5Y29ycA"/> <skos:closeMatch rdf:resource=" http://www.bbc.co.uk/nature/species/Cougar#species"/> <rdfs:seeAlso rdf:resource=" http://www.bbc.co.uk/nature/species/Cougar.rdf"/> <geospecies:hasGBIF>13815711</geospecies:hasGBIF> <geospecies:hasGBIFPage rdf:resource=" http://data.gbif.org/species/13815711"/> <foaf:page rdf:resource="http://data.gbif.org/species/13815711"/> <geospecies:hasITIS>552479</geospecies:hasITIS> <foaf:page rdf:resource=" http://www.itis.gov/servlet/SingleRpt/SingleRpt?search_topic=TSN&search… "/> <geospecies:hasNCBI>9696</geospecies:hasNCBI> <foaf:page rdf:resource=" http://www.ncbi.nlm.nih.gov/Taxonomy/Browser/wwwtax.cgi?id=9696&lvl=0"/> <geospecies:hasBioLib>id1995</geospecies:hasBioLib> <geospecies:hasBioLibPage rdf:resource=" http://www.biolib.cz/en/taxon/id1995"/> <foaf:page rdf:resource="http://www.biolib.cz/en/taxon/id1995"/> <geospecies:hasBBCPage rdf:resource=" http://www.bbc.co.uk/nature/species/Cougar"/> <foaf:page rdf:resource="http://www.bbc.co.uk/nature/species/Cougar"/> <geospecies:hasGNI>505310</geospecies:hasGNI> <geospecies:hasGNIPage rdf:resource=" http://globalnames.org/?search_term=id:505310"/> <geospecies:hasWikipediaArticle rdf:resource=" http://en.wikipedia.org/wiki/Cougar"/> <foaf:page rdf:resource="http://en.wikipedia.org/wiki/Cougar"/> <geospecies:hasWikispeciesArticle rdf:resource=" http://species.wikimedia.org/wiki/Puma_concolor"/> <foaf:page rdf:resource="http://species.wikimedia.org/wiki/Puma_concolor "/> <geospecies:hasToLPage rdf:resource="http://tolweb.org/Puma_concolor"/> <foaf:page rdf:resource="http://tolweb.org/Puma_concolor"/> I would also like to address this statement *"For example, at this writing, LOD statistics reveal only 42 bioscience datasets holding 2.7B triples"* The Linked Open Data set list as , are only those LOD data sets that are documented here. http://www.ckan.net/ The Bio2RDF data set is over 15 billion triples on it's own http://www.slideshare.net/micheldumontier/bio2rdf-and-beyond The authors of the report don't seem to be aware of the significance of the Linked Data movement. http://data.nytimes.com/ http://www.guardian.co.uk/open-platform/blog/linked-data-open-platform Oddly GeoSpecies/TaxonConcept seems to be visible to the New York Times and The Guardian, yet not the expert authors of the GBIF report? FaceBook's OpenGraph is also Linked Data, so all those "liked" pages are linked data. http://go-to-hellman.blogspot.com/2010/06/global-warming-of-linked-data-in.… Here is an interesting recent blog post from O'reilly Radar. http://radar.oreilly.com/2010/11/semantic-web-linked-data.html The Linked Data Community is much larger and more significant than the GBIF report has implied. Also you should look at what resources show up when you query "“Quercus alba” in the following LOD services. http://sindice.com/ http://sindice.com/search?q=Quercus+alba&qt=term http://uriburner.com/fct/ http://uriburner.com/fct/facet.vsp?cmd=text&sid=9244 http://lsd.taxonconcept.org/fct/ http://lsd.taxonconcept.org/fct/facet.vsp?cmd=text&sid=71 Would seem that this would have been a little hard to miss? I was originally somewhat skeptical about Gregor Hagedorn's earlier statement. "*I fully believe you and all who are doing it do it with careful consideration of the needs as they see it. I just believe that those taking these decisions have a specific perspective and use case scenarios, that involves biologists only after the perfect software user interface system is finished. I challenge the last assumption ...*" But after reading through the GBIF report, I think he make a good point. Reasoning will only work everyone has a common conceptualization of what each of this things are, and how they relate to other things. What is a species? What is a species relationship to a particular classification hierarchy? Can there be be more than one hierarchy? The report authors have experience in creating highly engineered systems where each entity is modelled in a formal strict way. It is not clear to me that we have agreement on some of the fundamental entities, let alone how the relate to each other. In my own work I have been thinking that the model of a species for occurrences etc. might not be the best model for addressing phylogenetic questions. This is because you might want to have one standard agreed on classification so you can search for species in a given family that are potential pathogen vectors. Others might want a different kind of entity that is not tied to one particular classification so they can address phylogenetic questions. What you don't want is to prevent people from asking questions that relate to subfamilies etc. because the model does not support them. It might be best to have separate, but loosely linked models for these different kinds of "perspectives" This is similar to the way I model relationships between various LOD species entities. For some uses you could interpret <Puma concolor se:v6n7p <http://lod.taxonconcept.org/ses/v6n7p#Species>> as being the same thing as <http://purl.uniprot.org/taxonomy/9696> For other uses, they are not the same thing. (The later is in a nested set of NCBI classification subclasses) Because of this, I tie them together loosely with a skos:closeMatch. This keeps them "findable" without entailing the other entities potentially incompatible conceptualization. This allows the end user of the data to determine if they want to convert these to a owl:sameAs relationship or not. My guess is that this is exactly the kind of thing that at least some of the authors of the GBIF report might not like. For reasoning etc. they would probably prefer that these species concepts fall under some highly constrained classification hierarchy - probably the one produced by the Catalog of Life. Regarding issues like this that I think Gregor has made an interesting point. Respectfully, - Pete --------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------

1 0

Call for Small Awards for Evaluating the GBIF Checklist Publication Format
by David Remsen (GBIF) 26 Nov '10

26 Nov '10

Dear TDWG Content subscribers, The GBIF Secretariat is pleased to offer a limited number of small awards of up to €5,000 to GBIF Participants to evaluate the current DarwinCore Archive taxonomic data exchange format in order to stimulate the process of sharing species-level taxonomic data. Please refer to the link below for more information on this call: http://www.gbif.org/communications/news-and-events/showsingle/article/gbif-… The GBIF network is evaluating the means to support the publication of species-level data in the form of annotated species checklists and taxonomic catalogues. Facilitating this capacity has been a long- standing request from participants and a target capacity for the GBIF network. Annotated checklists and taxonomic catalogues are not only highly-valued resources in their own right, they also provide a means to improve the quality of primary biodiversity data mobilised through GBIF and the contexts in which it can be organised and delivered. We would like to open up the draft checklist exchange format for review and testing by providing small awards to facilitate the publication of existing species checklist and taxonomic catalogue data and information. Deadline for applications is 20 December 2010. We look forward to your participation and contributions to this process. Please make contact by email at dremsen(a)gbif.org with any questions or information requests. With best regards, David Remsen ---------------------------------------------------------------------------- David Remsen, Senior Programme Officer Electronic Catalog of Names of Known Organisms Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321472 Fax: +45-35321480 Mobile +45 28751472 Skype: dremsen ----------------------------------------------------------------------------

1 0

Re: [tdwg-content] [tdwg-tag] Inclusion of authorship in DwC scientificName: good or bad?
by Chuck Miller 26 Nov '10

26 Nov '10

What is the specific objection to adding canonicalName to DwC as an optional element, other than the fact it makes DwC one thing larger? There are databases which do not have their names parsed and provide whatever they have recorded as ScientificName. But, there are also databases which do have parsed names and could provide this more narrowly defined element, in addition to the ScientificName. Those databases could make use of a dwc:canonicalName element in their data exchange or query response. What we don't have and I think never will have is perfectly consistent names data from every database in the world. One reason is a mountain of inconsistently recorded legacy data from decades past that stands in the way of perfection. Another is variation in convention or tradition for a variety of reasons that have been explored in these recent threads. So, I think the pragmatic approach is to accept the inconsistencies and work around them. Chuck -----Original Message----- From: tdwg-content-bounces(a)lists.tdwg.org [mailto:tdwg-content-bounces@lists.tdwg.org] On Behalf Of Tony.Rees(a)csiro.au Sent: Tuesday, November 23, 2010 1:40 PM To: dremsen(a)gbif.org Cc: tdwg-content(a)lists.tdwg.org; dmozzherin(a)eol.org Subject: Re: [tdwg-content] [tdwg-tag] Inclusion of authorship in DwC scientificName: good or bad? Hi David, It seems to me that your suggestion is still not quite ideal, in that sometimes just the dwc:scientificName element will be picked up and passed around and the content will not be consistent between those suppliers who concatenate the available authority info and those who do not. That suggests to me that an extra field for known canonicalName if this can be supplied is still desirable - but I am not sure if I am alone in thinking this... Regards - Tony ________________________________________ From: David Remsen (GBIF) [dremsen(a)gbif.org] Sent: Tuesday, 23 November 2010 11:15 PM To: Rees, Tony (CMAR, Hobart) Cc: David Remsen (GBIF); deepreef(a)bishopmuseum.org; m.doering(a)mac.com; tdwg-content(a)lists.tdwg.org; dmozzherin(a)eol.org Subject: Re: [tdwg-content] [tdwg-tag] Inclusion of authorship in DwC scientificName: good or bad? Tony I did indeed mean that scientificName and authorship could be used in the following way 1. "Agalinis purpurea" -> scientificName ("Agalinis purpurea") - where a canonical form of the name with no authorship in the source data 2. "Agalinis purpurea (L.) Pennell" -> scientificName ("Agalinis purpurea (L.) Pennell" ) - where a unparsed name+author is in the source data 3. "Agalinis purpurea" AND "(L.) Pennell" -> scientificName ("Agalinis purpurea") + scientificNameAuthorship ("(L.) Pennell") - where a semi-parsed name + author is in the source data 4. "Agalinis" AND purpurea" AND "(L.) Pennell" > scientificName ("Agalinis purpurea") + scientificNameAuthorship ("(L.) - where a fully atomised name is in the source data and the 'name' parts concatenated to make a proper canonical name. Cases 3 and 4 require modification of the definition at http://rs.tdwg.org/dwc/terms/index.htm#scientificName to be something like "The full scientific name, which may include authorship and date information if known..." with the implicit intention that it is not REQUIRED to parse or semi-parse an unparsed name in order to properly share it. David On Nov 23, 2010, at 12:35 PM, <Tony.Rees(a)csiro.au> wrote: > David Remsen wrote: > >> Maybe we shouldnt add canonical name but rather something more >> specific to the concatenated form like >> dwc:scientificNameWithAuthorshipAndOtherBits >> dwc:scientificName >> dwc:scientificNameAuthorship > > If by "dwc:scientificName" you mean with authorship omitted, that is > fine, however it would need the dwc definition to be altered... > > Then at least folk would/should know which field to populate. > However the mandatory yes/no issue would also have to be addressed - > at present I think dwc:scientificName is the only taxonomy related > element that is mandatory, all others are optional. Under your > scenario it would then maybe be one of either of the first 2 fields, > or both as available, I guess? > > Regards - Tony > > ________________________________________ > From: David Remsen (GBIF) [dremsen(a)gbif.org] > Sent: Tuesday, 23 November 2010 7:47 PM > To: Rees, Tony (CMAR, Hobart) > Cc: David Remsen (GBIF); deepreef(a)bishopmuseum.org; m.doering(a)mac.com; > tdwg-content(a)lists.tdwg.org; dmozzherin(a)eol.org > Subject: Re: [tdwg-content] [tdwg-tag] Inclusion of authorship in DwC > scientificName: good or bad? > > While I haven't seen them all, I have seen and had to understand a > good number of biodiversity databases including many focused on > managing species lists in one form or another. Names are represented > in these three forms. > > 1. Completely unparsed where the entire verbose name text is in a > single field corresponding to dwc:scientificName. In some databases > this means just a scientific name as many databases don't hold > authorship information. > > 2. Semi-parsed where the canonical name is separated from the > authorship information corresponding to the proposed canonicalName and > dwc:scientificNameAuthorship > > 3. Fully parsed into atoms (genus, specific epithet, infraspecific > rank, infraspecies, authorship) corresponding to the incomplete set of > dwc atomic elements already in existence. This form is the most > problematic because 1) it isn't always clear from the parts how the > actual complete name is intended to be represented and 2) there are so > many structural exceptions and complexities that many more 'atoms' > need to be described to effectively enable it to be used. 3) there is > the problematic definition of the use of Genus as described by Markus > that conflicts with atomising synonyms. > > It makes sense to maintain the separation of name and authorship in > data sources that already do this but Im not convinced a canonicalName > element is required. It seems that it is suggested so that it makes > it easier to consume the data but it also means its more confusing for > a typical data manager or biologist to produce it. I have a database > with binomials alone. How many data managers or biologists will map > them to canonicalName before scientificName? I know we want to avoid > testing different conditions when we use the data but we will have to > in either case. > > Maybe we shouldnt add canonical name but rather something more > specific to the concatenated form like > > dwc:scientificNameWithAuthorshipAndOtherBits > dwc:scientificName > dwc:scientificNameAuthorship > > I'd know what to do then > > DR > > On Nov 22, 2010, at 11:18 PM, <Tony.Rees(a)csiro.au> > <Tony.Rees(a)csiro.au> wrote: > >> Hi Rich, all, >> >> You wrote: >> . >>> Otherwise, we could argue forever about which of the dozen possible >>> forms we think DwC needs a term for. >> >> No, I think that is muddying the waters (with respect of course...) I >> simply made the case for "canonicalName" - aka scientific name >> without authorship - as a valuable adjunct to "scientificName", for >> users who can supply both, and consumers who would otherwise have to >> generate the former from the latter algorithmically. Markus, Dima >> probably represent the main "consumers" here and I if you like can >> represent a "provider" (although I wear other "consumer" hats on >> occasion as well). Basically if a "canonicalName" field does not >> exist, I will just omit to provide this information, which seems sub- >> optimal since it all exists pre-parsed and manually verified in my >> system, and someone else will then have to do the job again... >> >> Regards - Tony >> >> >>> -----Original Message----- >>> From: Richard Pyle [mailto:deepreef@bishopmuseum.org] >>> Sent: Tuesday, 23 November 2010 7:06 AM >>> To: Rees, Tony (CMAR, Hobart); m.doering(a)mac.com >>> Cc: tdwg-content(a)lists.tdwg.org; dmozzherin(a)eol.org >>> Subject: RE: [tdwg-content] [tdwg-tag] Inclusion of authorship in >>> DwC >>> scientificName: good or bad? >>> >>>> "unininomial" would equal "canonicalName" for ranks subgenus and >>>> above, but not for species and below, while canonicalName (or >>>> scientificNameCanonical if you prefer) covers all cases, which is >>>> why I thik it is preferable, especially as the majority of names in >>>> circulation are at species level and below I think... >>>> >>>> Atomising further i.e. a binomial or poynomial into genus, species, >>>> infaspecies is actually a separate activity with its own rationale, >>>> I would say. >>>> >>>> Just my personal view, of course... >>> >>> The cleanest way to do it is to simply have Rank, NameElement and >>> parentNameUsageID, and be done with it (maybe with the addition of >>> verbatimNameString for purists). But that assumes that providers >>> have parsed data, which they often do not. Maybe with services like >>> those associated with GNI, the time of databases with unparsed names >>> data are drawing to a close. Or, maybe if GNUB gets a foot-hold, >>> we'll solve all the problems via a simply actionable persistent >>> identifier. >>> >>> But until that time, dwc needs to find a balance between users who >>> want pre-parsed data, and providers who do not have pre-parsed data. >>> >>> I think dwc *almost* accomodates both worlds, as long as >>> scientificName is defined as "the complete set of textual elements >>> useful for recognizing a unique scientific name"; which is either >>> concatenated by the provider with parsed data, or simply "provided" >>> by the provider with unparsed data. >>> >>> What we seem to be arguing about now is how many different forms of >>> a "formatted" name do we want? >>> >>> With or without authorship? >>> >>> With or without year? >>> >>> With or without infraspecific prefixes ("var.", "f." etc.)? >>> >>> With or without infrageneric name(s)? >>> >>> With or without italics codes? >>> >>> With or without qualifiers like "cf.", "aff.", etc.? >>> >>> Etc. >>> >>> Etc. >>> >>> Etc. >>> >>> There are potentially dozens of different terms we could define to >>> accommodate every particular niche-need. >>> >>> Personally, I think that the existing "scientificName" should be >>> split into two different terms: >>> >>> fullScientificNameStringWithAuthorship >>> And >>> verbatimNameString >>> >>> The first would be a concatenated text string assembled from parsed >>> bits, according to a community standard concatenation form. >>> >>> The second would be the literal text string as it appeared in the >>> original source. >>> >>> Otherwise, we could argue forever about which of the dozen possible >>> forms we think DwC needs a term for. >>> >>> Rich >>> >> >> _______________________________________________ >> tdwg-content mailing list >> tdwg-content(a)lists.tdwg.org >> http://lists.tdwg.org/mailman/listinfo/tdwg-content >> _______________________________________________ tdwg-content mailing list tdwg-content(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content

12 53

Re: [tdwg-content] [tdwg-tag] Inclusion of authorship in DwC scientificName: good or bad? [SEC=UNCLASSIFIED]
by Paul Murray 23 Nov '10

23 Nov '10

(I'll send this to tdwg-content rather than tdwg-tag) We are sorting through this issue now. The TDWG vocabulary defines a property "nameComplete" which is the name without authority. It states that the name with authority belongs in a dcterms:title field "The complete uninomial, binomial or trinomial name without any authority or year components. Every TaxonName should have a DublinCore:title property that contains the complete name string including authors and year (where appropriate)." I'm a tad uneasy about this: a vocabulary expressing an opinion on fields that are outside of its own uri namespace. What if my name objects are more than simply names, and I want the dcterms:title to reflect data that the tdwg vocabulary doesn't know about? I might want my title, for instance, to announce that a record is a draft or test record. In particular, our titles will be including the nomenclatural status ("nom. cons." etc) - does that mean that we are not conforming to the standard? On 18/11/2010, at 2:31 PM, <Tony.Rees(a)csiro.au> wrote: > Dear TDWG-persons, > > I note that DwC "scientificName" as defined at http://rs.tdwg.org/dwc/terms/#scientificName is supposed to include authorship, however this can also be supplied separately in the field "scientificNameAuthorship". Under that scenario, should authorship be also included in the scientificName field, or omitted? > > I can see arguments either way for this - if the authorship is included in the same field as the rest of the scientific name, then that single value is more meaningful and better for e.g. homonym disambiguation. On the other hand, it then requires parsing to get the scientific name without the authority, which if done incorrectly could introduce errors. > > Any advice from the persons designing or using this field for data exchange would be appreciated. > > Regards - Tony > > Tony Rees > Manager, Divisional Data Centre, > CSIRO Marine and Atmospheric Research, > GPO Box 1538, > Hobart, Tasmania 7001, Australia > Ph: 0362 325318 (Int: +61 362 325318) > Fax: 0362 325000 (Int: +61 362 325000) > e-mail: Tony.Rees(a)csiro.au > Manager, OBIS Australia regional node, http://www.obis.org.au/ > Biodiversity informatics research activities: http://www.cmar.csiro.au/datacentre/biodiversity.htm > Personal info: http://www.fishbase.org/collaborators/collaboratorsummary.cfm?id=1566 > > > _______________________________________________ > tdwg-tag mailing list > tdwg-tag(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-tag ------ If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. Please consider the environment before printing this email. ------

13 34

Proposal to Add a GeoSpatial "Area" to the DarwinCore
by Peter DeVries 22 Nov '10

22 Nov '10

I wrote about this earlier but I never heard anything back. I have made something that uses the geo vocabulary but also allows pointRadiusSpatial fit measure that I call radius. The advantage is that this adds a standard way to deal use something like an extent or pointRadiusSpatial while still benefiting from the widely used geo vocabulary. It also allows these "Areas" to be referenced in a commonly understood urn way that using a ietf standard. For example: "geo:44.86528100,-87.23147800;u=10" There are still some things I need to fix and check with this vocabulary but I am wondering if there is any interest in incorporating this into the DarwinCore. If not I will probably change the name of the ontology. There are also things in the example below that are not part of my proposal. I have what I call "Areas" that look like this: <dwc_area:Area rdf:about="geo:44.86528100,-87.23147800;u=10"> <dcterms:title>44.86528100, -87.23147800 Radius 10 meters</dcterms:title> <dcterms:isPartOf rdf:resource=" http://lod.taxonconcept.org/ontology/void#this"/> <dcterms:identifier>geo:44.86528100,-87.23147800;u=10</dcterms:identifier> <dcterms:created>2010-10-28T00:00:00-0500</dcterms:created> <dcterms:modified>2010-11-09T16:33:34-0600</dcterms:modified> <geo:lat>44.86528100</geo:lat> <geo:long>-87.23147800</geo:long> <dwc_area:radius>10</dwc_area:radius> <txn:elevation>186.54</txn:elevation> <txn:continent>North America</txn:continent> <txn:countryCode>US</txn:countryCode> <txn:country>United States</txn:country> <txn:stateProvince>Wisconsin</txn:stateProvince> <txn:county>Door</txn:county> <txn:localityText>Town of Sevastopol</txn:localityText> <txn:locationName>Shivering Sands Natural Area Woods</txn:locationName> <txn:areaHasOccurrence rdf:resource=" http://ocs.taxonconcept.org/ocs/f522444a-2dd9-400e-be59-47213ef38cb9#Occurr… "/> <txn:areaHasObservedSpeciesConcept rdf:resource=" http://lod.taxonconcept.org/ses/ICmLC#Species"/> <txn:areaHasIndividual rdf:resource=" http://ocs.taxonconcept.org/ocs/f522444a-2dd9-400e-be59-47213ef38cb9#Indivi… "/> <txn:areaInStateProvince rdf:resource="http://sws.geonames.org/5279468/ "/> <txn:areaInCounty rdf:resource="http://sws.geonames.org/5250768/"/> <wdrs:describedBy rdf:resource=" http://ocs.taxonconcept.org/ocs/f522444a-2dd9-400e-be59-47213ef38cb9.rdf"/> </dwc_area:Area> I recently added the following predicates, but have not altered my RDF examples. #featureContainsArea #areaWithInFeature http://lod.taxonconcept.org/ontology/dwc_area.owl OWL Doc http://lod.taxonconcept.org/ontology/dwc_area_doc/index.html The predicates are a bit awkward, but I wanted to be clear that this was to link an "Area" like "geo:44.86528100,-87.23147800;u=10" to a Geonames "Feature". I thought a different set of predicates could be created to deal with some other class of "SpatialThing" if needed. Respectfully, - Pete --------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------

5 11

Re: [tdwg-content] [tdwg-tag] Inclusion of authorship in DwC scientificName: good or bad?
by Tony.Rees＠csiro.au 21 Nov '10

21 Nov '10

Just re-sending the message below because it bounced the first time... Markus/all, I guess my point is that (as I understand it) scientificName is a required field in DwC, so the question is what it should be populated with. If it is (e.g.) genus + species epithet + authority, then is it beneficial to supply these fields individually / atomised as well, maybe with other qualifiers as needed? Just looking for an example "best practice" here - or maybe it exists somewhere and you can just point to it. in other words: (a) <scientificName>Homo sapiens</scientificName> <scientificNameAuthorship>Linnaeus, 1758</a> or (b): <scientificName>Homo sapiens Linnaeus, 1758</scientificName> <genus>Homo</genus> <specificEpithet>sapiens</specificEpithet> <scientificNameAuthorship>Linnaeus, 1758</a> if you get my drift... Regards - Tony Tony Rees Manager, Divisional Data Centre, CSIRO Marine and Atmospheric Research, GPO Box 1538, Hobart, Tasmania 7001, Australia Ph: 0362 325318 (Int: +61 362 325318) Fax: 0362 325000 (Int: +61 362 325000) e-mail: Tony.Rees(a)csiro.au<mailto:Tony.Rees@csiro.au> Manager, OBIS Australia regional node, http://www.obis.org.au/ Biodiversity informatics research activities: http://www.cmar.csiro.au/datacentre/biodiversity.htm Personal info: http://www.fishbase.org/collaborators/collaboratorsummary.cfm?id=1566

12 18