- tdwg-content - lists.tdwg.org

[Fwd: Re: most GUIDs/URIs for names/taxon stuff not ready for prime time]
by Donat Agosti 10 Jan '11

10 Jan '11

Rod's point that "they offer no added value" reflects pretty much the discussion we have on names. Nobody asks the question "name of what?". Names are linked to observations ie specimens. Any identifier, or indeed the underlying treatment, that does not deliver this data is up in the air and thus meaningless. Not just for the publisher who wants to use the name, but also the taxonomists, who can not discuss the meaning of names. Discussions are done through publications and they don't allow this either at the very moment, not for the machine (or at best with a considerable, prohibitive effort), nor people. A simple solution would be that in future to each usage of a name in taxonomic literature, at least for treatments, the name has to be explicitly linked to the underlying specimen or observation data. Since this is part of a treatment, the identifier should allow to retrieve the treatment and through it the specimen data or at least the observation data and the author who used it in this specific selection. Donat > Why aren't identifiers reused? > ---------------------------------------- > > Because in most cases they offer no added value. If I have a ITIS TSN > there's not much I can do with it. I can get a name from ITIS (with > some vague assurance that thus name is accepted - or not - with no > evidence for this assertion). I can think of only two taxonomic > identifiers that have real value and get much reuse, NCBI taxonomy ids > and uBio NameBankIDs. NCBI ids are reused because they underpin the > genomics databases, and genomics does real computational biology, and > makes extensive reuse of data (as exemplified by the annual Nucleic > Acids Research database issue). uBio NameBankIDs get reused because > uBio has lots of names, and provides services for discovering those > names in text (see, e.g., their use by BHL). > > Few taxonomic name databases provide a compelling reason for anyone to > use their identifiers, most being digital sinks (you go there, get an > identifier for a name, and nothing else). > > > Why UUIDS? > ---------------- > > UUIDs are ugly, and solve a problem that for the most part we don't > have. They are ideal for minting globally unique identifiers in a > distributed system, but we don't have distributed systems. Catalogue > of Life uses UUIDs, but these are centrally created (I suspect using > MySQL's UUID function, given how similar the UUIDs are to each other). > ZooBank uses them, but it is not (yet) a distributed system. If the > Catalogue of Life were genuinely a distributed system UUIDs would make > sense, but that's not actually how it works. > > I think users would cope with UUIDs if the databases using them > provides clear value. For example, MusicBrainz uses UUIDs > http://musicbrainz.org/artist/563201cb-721c-4cfb-acca-c1ba69e3d1fb.html > , as does Mendeley, the latter hiding them from users via human- > readable URLs. Given that we have obvious user-friendly candidates for > URLs (taxonomic names), it would be trivial to hide UUIDs in names > (making homonyms distinct by adding authorship, or whatever it took to > make them unique as strings). > > What, if anything, is a taxonomic name? > ---------------------------------------------------- > > In my experience, when non-taxonomists meet taxonomists things get > ugly. For example, a publisher wanting to mark up taxonomic names in > text might ask taxonomists how to do this,and within minutes the > taxonomists are off into discussions of namestrings versus usages > versus concepts and pretty soon the publisher deeply regrets ever > asking the question. I've been at meetings where the look in > publishers' eyes said "run away, run away". > > Part of the reason we have multiple databases is because different > projects are capturing different things (roughly speaking, uBio is > mostly about namestrings, Catalogue of Life is about concepts, IPNI > and ZooBank are about first usage of a name, etc.) > > Most users outside our field won't give a damn about the niceties of > these distinctions, yet we persist in discussing them ad nauseam. > Until we provide a single, very simple service that takes a name > string and hides all this complexity (unless the user chooses to see > the gory details) while still providing useful information, we will be > stuck in multiple identifier hell. The tragedy is we've never had > more people genuinely interested in linking to names than at present > -- publishers are desperately trying to add "semantic value" to their > content, and we are spectacularly ill-equipped to deliver this (and > it's our own fault). > > I rather suspect we're rapidly approaching the point where users > outside taxonomy will simply say "to hell with these taxonomists, > let's just use Wikipedia and be done with it." > > Regards > > Rod > > --------------------------------------------------------- > Roderic Page > Professor of Taxonomy > Institute of Biodiversity, Animal Health and Comparative Medicine > College of Medical, Veterinary and Life Sciences > Graham Kerr Building > University of Glasgow > Glasgow G12 8QQ, UK > > Email: r.page(a)bio.gla.ac.uk > Tel: +44 141 330 4778 > Fax: +44 141 330 2792 > AIM: rodpage1962(a)aim.com > Facebook: http://www.facebook.com/profile.php?id=1112517192 > Twitter: http://twitter.com/rdmpage > Blog: http://iphylo.blogspot.com > Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html > > > > > > > > _______________________________________________ > tdwg-content mailing list > tdwg-content(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-content > -- Dr. Donat Agosti Research Associate, American Museum of Natural History and Smithsonian Institution Email: agosti(a)amnh.org Web: http://antbase.org CV: http://research.amnh.org/entomology/social_insects/agosticv_2003.html Swiss Residence Elahieh Ave. Khazer no. 74 19649 Teheran Iran +98-21-2200 8765 (office) +98-21-2260 6160 (home) +98-919-489 2744 (mobile) +1-202-558 0330 (skype-in US) +41-44-5862911 (skype-in Switzerland) -- Dr. Donat Agosti Research Associate, American Museum of Natural History and Smithsonian Institution Email: agosti(a)amnh.org Web: http://antbase.org CV: http://research.amnh.org/entomology/social_insects/agosticv_2003.html Swiss Residence Elahieh Ave. Khazer no. 74 19649 Teheran Iran +98-21-2200 8765 (office) +98-21-2260 6160 (home) +98-919-489 2744 (mobile) +1-202-558 0330 (skype-in US) +41-44-5862911 (skype-in Switzerland)

3 3

Re: [tdwg-content] most GUIDs/URIs for names/taxon stuff not ready for prime time
by Tony.Rees＠csiro.au 09 Jan '11

09 Jan '11

Dear all, >From where I sit (very much on the sideline of this debate, waiting to see what happens), the main trouble I see is that (1) anyone and his dog can mint yet another unique identifier for the same taxon name, leading to uncontrolled proliferation and never ending ID reconciliation issues, and (2) there are always some names not on any particular external "identifier assigning" list which therefore lack an identifier (however have a scientific name) just when you want one. No problem, just mint your own, however that feeds back into (1) again... Just curious - ITIS TSNs would have to be one of the longest established and promoted systems of "non-name" identifiers for taxon names - have they been successful in anyone's view, or if not, why not... Any comments appreciated. Regards - Tony

4 8

Fwd: Tim Berners-Lee .. Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
by Peter DeVries 08 Jan '11

08 Jan '11

---------- Forwarded message ---------- From: Tim Berners-Lee <timbl(a)w3.org> Date: Fri, Jan 7, 2011 at 10:47 AM Subject: Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF? To: Peter DeVries <pete.devries(a)gmail.com> Cc: public-lod(a)w3.org Certainly. the tabulator follows rdfs:seeAlso and expects some terse RDF. and so would be crippled by any large file, and PDF would not of course help it at all. I take seeAlso as a fairly strong request to see the other thing, like an HTTP redirect. Not a generic "this is vaguely related" link at all, and not in general to point to human-readable stuff. Tim On 2011-01 -06, at 14:40, Peter DeVries wrote: I was wondering if there is an existing predicate for linking to a PDF file? I would like to incorporate a link between bibliographic reference description and a URL to the location of a PDF of that document. I had minted a predicate txn:hasPDFVersion, as demonstrated in this RDF snippet. (Part of http://lod.taxonconcept.org/ses/v6n7p.rdf ) <txn:SpeciesOriginalDescription rdf:about=" http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription">  <dcterms:title>Original Published Description relating to Species Concept Puma concolor se:v6n7p</dcterms:title> <dcterms:identifier> http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription </dcterms:identifier> <dcterms:description>LOD metadata about the original species description relating to Species Concept Puma concolor se:v6n7p</dcterms:description> <dcterms:isPartOf rdf:resource=" http://lod.taxonconcept.org/ses/v6n7p#Species"/> <txn:hasAuthorURI rdf:resource=" http://dbpedia.org/resource/Carl_Linnaeus"/> <txn:hasBasionymName>Felis concolor Linnaeus 1771</txn:hasBasionymName> <txn:year>1771</txn:year> <txn:hasPDFVersion rdf:resource=" http://assets.geospecies.org/spec_concept_uuid/603bebac-cc44-4168-bbf7-b11b… "/> <txn:speciesOriginalDescriptionHasSpeciesConcept rdf:resource=" http://lod.taxonconcept.org/ses/v6n7p#Species"/>  <wdrs:describedBy rdf:resource=" http://lod.taxonconcept.org/ses/v6n7p.rdf"/> </txn:SpeciesOriginalDescription> Some have suggested using rdfs:seeAlso to link to what could be a multimegabyte PDF, but I think this would cause problems for a number of RDF crawlers like Elmo. In summary, I think it would be useful to have a predicate that can be used for linking specifically to a PDF document. Is there an existing predicate for this? What do people think about the suggestion to use rdfs:seeAlso to link to a PDF? I would also like to know of others thoughts or suggestions regarding this issue, 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/> ------------------------------------------------------------ -- --------------------------------------------------------------- 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

most GUIDs/URIs for names/taxon stuff not ready for prime time
by Steve Baskauf 07 Jan '11

07 Jan '11

Well, I have continued my quest for resolvable, RDF-producing GUIDs for taxon/name-related stuff. I have gotten a lot of good information from reading Rod Page's BMC Bioinformatics paper (http://dx.doi.org/10.1186/1471-2105-10-S14-S5) and from investigating his http://bioguid.info/ site. From the standpoint of the "sec./sensu" part of a TNU/taxon concept, based on the recent discussion, it sounds like the DIO solution for publications is a good direction to go IF resolution services producing RDF comes into existence and IF it becomes possible to actually search for the DIOs of more obscure publications. I tried using Rod's site to look up a journal article using the ISSN, volume, and page and the web interface found the DOI and generated RDF just fine. However, an attempt to use the web to find the DIO of Gleason and Cronquist's Manual of vascular plants of Northeastern United States and adjacent Canada failed despite a half hour of effort (I found the UPC, the LOC call number, and the ISBN, but no DOI). Maybe there just isn't a DOI for it but there should be a way for me to know that. So DOIs for books and old journal articles are not really ready for prime time. From the standpoint of the "scientific name" part of a TNU/taxon concept, I had better luck (sort of). Rod's "Status of biodiversity services" page (http://www.bioguid.info/status/) was really cool. I saw resources I hadn't known about before. I tried out several of the services that claimed to issue LSIDs. Catalog of Life's LSIDs didn't work with either the http://www.bioguid.info/ or http://lsid.tdwg.org/ proxies with either a web browser or the OpenLink RDF browser. I only got an empty RDF element in response. Index Fungorum was down. IPNI seemed to work. However, I was somewhat appalled to observe that they seem to change the revision identifier any time that they change any part of the metadata. That renders the LSID useless as a permanent GUID for the name and I believe is inconsistent with the design of LSIDs where the revision is only supposed to change if the underlying data itself (NOT metadata) changes. (Catalog of Life says that they change the revision identifier EACH YEAR for all of their records! That's even worse!) If I'm remembering the TDWG LSID recommendations, it is not even recommended to use the revision part of an LSID at all in the biodiversity informatics context. ubio.org's LSIDs seemed to work properly. [sorry - didn't try zoobank since I was looking for plants] I don't know which (if any) of the Web sites listed on Rod's status page use generic HTTP URI guids (rather than LSIDs) to refer to taxon names. I tried out the Global Names index that Pete was mentioning. The URI version of the UUIDs (e.g. http://gni.globalnames.org/name_strings/3a70f04d-fd29-5570-ba91-52dae0c3d07f) do resolve under content negotiation, but the only useful information that the RDF representation seems to provide is the actual name string that was used to generate the UUID. Until some other useful linked information is added to the RDF, there doesn't seem to be much advantage in pointing a semantic client to the URI over just using a string literal for the name. So the bottom line is that of the LSID services for names that I've tried so far, only ubio.org seems to have LSIDs for names that are unchanging, can work as a proxied URI, and that produce actual useful RDF. That's pretty disappointing given the apparently huge amount of work that's been put into building these various systems. Steve -- Steven J. Baskauf, Ph.D., Senior Lecturer Vanderbilt University Dept. of Biological Sciences postal mail address: VU Station B 351634 Nashville, TN 37235-1634, U.S.A. delivery address: 2125 Stevenson Center 1161 21st Ave., S. Nashville, TN 37235 office: 2128 Stevenson Center phone: (615) 343-4582, fax: (615) 343-6707 http://bioimages.vanderbilt.edu

5 14

More LOD on Linking to PDF's
by Peter DeVries 06 Jan '11

06 Jan '11

I should note that followed that Christopher Gutteridge <cjg(a)ecs.soton.ac.uk> followed that response with a note " *But that's me making a reasonable guess and getting on with it. The EPrints document is a URI which represents a conceptual document which consists of a number of actual files, eg. HTML+JPG+CSS, so the dct:hasPart makes sense there. The main issue is how to relate the document to the metadata record, and you rapidly decend into FRBR hell. Until a few people have consumed my data I consider it very much a work in progress! *" I will summarize the future messages on this thread. -- 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

Fwd: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
by Peter DeVries 06 Jan '11

06 Jan '11

I thought that I would run the PDF question past the some lod experts. Here is the first reply - Pete ---------- Forwarded message ---------- From: Hugh Glaser <hg(a)ecs.soton.ac.uk> Date: Thu, Jan 6, 2011 at 2:44 PM Subject: Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF? To: Peter DeVries <pete.devries(a)gmail.com> Cc: "<public-lod(a)w3.org>" <public-lod(a)w3.org> I see that Chris Gutteridge uses dc:hasPart for the ePrints RDF (eprints.org ). Eg: <http://eprints.ecs.soton.ac.uk/21681/> dc:format "text/html"; dc:title "HTML Summary of #21681 Consuming multiple linked data sources: Challenges and Experiences"; foaf:primaryTopic <http://eprints.ecs.soton.ac.uk/id/eprint/21681> . ... <http://eprints.ecs.soton.ac.uk/id/eprint/21681> ep:hasDocument <http://eprints.ecs.soton.ac.uk/id/document/36430>, ... <http://eprints.ecs.soton.ac.uk/id/document/36430> dct:hasPart < http://eprints.ecs.soton.ac.uk/21681/1/cold2010%2Dpaper16%2Dcamera%2Dready.… >; ... Cheers Hugh On 6 Jan 2011, at 19:40, Peter DeVries wrote: > I was wondering if there is an existing predicate for linking to a PDF file? > > I would like to incorporate a link between bibliographic reference description and a URL to the location of a PDF of that document. > > I had minted a predicate txn:hasPDFVersion, as demonstrated in this RDF snippet. (Part of http://lod.taxonconcept.org/ses/v6n7p.rdf ) > > <txn:SpeciesOriginalDescription rdf:about=" http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription"> >  > <dcterms:title>Original Published Description relating to Species Concept Puma concolor se:v6n7p</dcterms:title> > <dcterms:identifier> http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription </dcterms:identifier> > <dcterms:description>LOD metadata about the original species description relating to Species Concept Puma concolor se:v6n7p</dcterms:description> > <dcterms:isPartOf rdf:resource=" http://lod.taxonconcept.org/ses/v6n7p#Species"/> > <txn:hasAuthorURI rdf:resource=" http://dbpedia.org/resource/Carl_Linnaeus"/> > <txn:hasBasionymName>Felis concolor Linnaeus 1771</txn:hasBasionymName> > <txn:year>1771</txn:year> > <txn:hasPDFVersion rdf:resource=" http://assets.geospecies.org/spec_concept_uuid/603bebac-cc44-4168-bbf7-b11b… "/> > <txn:speciesOriginalDescriptionHasSpeciesConcept rdf:resource=" http://lod.taxonconcept.org/ses/v6n7p#Species"/> >  > <wdrs:describedBy rdf:resource=" http://lod.taxonconcept.org/ses/v6n7p.rdf"/> > </txn:SpeciesOriginalDescription> > > Some have suggested using rdfs:seeAlso to link to what could be a multimegabyte PDF, but I think this would cause problems for a number of RDF crawlers like Elmo. > > In summary, I think it would be useful to have a predicate that can be used for linking specifically to a PDF document. > > Is there an existing predicate for this? > > What do people think about the suggestion to use rdfs:seeAlso to link to a PDF? > > I would also like to know of others thoughts or suggestions regarding this issue, > > Respectfully, > > - Pete > > > > --------------------------------------------------------------- > Pete DeVries > Department of Entomology > University of Wisconsin - Madison > 445 Russell Laboratories > 1630 Linden Drive > Madison, WI 53706 > TaxonConcept Knowledge Base / GeoSpecies Knowledge Base > About the GeoSpecies Knowledge Base > ------------------------------------------------------------ -- Hugh Glaser, Intelligence, Agents, Multimedia School of Electronics and Computer Science, University of Southampton, Southampton SO17 1BJ Work: +44 23 8059 3670, Fax: +44 23 8059 3045 Mobile: +44 78 9422 3822, Home: +44 23 8061 5652 http://www.ecs.soton.ac.uk/~hg/ -- --------------------------------------------------------------- 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

Can all DwC be Simple DwC?
by joel sachs 06 Jan '11

06 Jan '11

It may be worth teasing out the boundary of what can/cannot be represented via simple (i.e. flat) Darwin Core. Auxilliary terms (which comprise the classes "MeasurementOrFact" and "ResourceRelationship") are currently left out of Simple Darwin Core. The DwC Terms Quick Reference Guide [1] states: "The terms found under the Auxiliary Terms section can only be meaningfully implemented in an application that supports relational structures". The Simple Darwin Core reference [2] explains "Every field in the Simple Darwin Core may appear either once or not at all in a single record - otherwise how could you distinguish one 'scientificName' field from another one?" Couldn't this be addressed using subscripts? E.g. MeasurementID_1="tail length" MeasurementID_2="brain volume" MeasurementUnit_1="cm" MeasurementUnit_2="cubic cm" MeasurementValue_1="9" MeasurementValue_2="8" (There is precedent for subscripting rdf properties: http://www.w3.org/TR/rdf-schema/#ch_containermembershipproperty) Allowing this would increase the types of data that can be exchanged via spreadsheet. It would also have the virtue of permitting a single DwC standard, which would help to lesssen confusion amongst potential adopters. (The existence of a "Simple Darwin Core" seems to imply that "regular Darwin Core" is not simple.) Are there reasons not to do this? Thanks - Joel. 1. http://rs.tdwg.org/dwc/terms/ 2. http://rs.tdwg.org/dwc/terms/simple/index.htm

3 4

GUIDs for publications (usages and names)
by Steve Baskauf 06 Jan '11

06 Jan '11

I was reviewing some of the previous posts on taxon name usages in an attempt to understand them better. I have learned that the Global Names Index is an attempt to catalog taxon names and that it is possible to generate a URI that points to a name there. Is there a parallel effort to do the same thing for literature references? In other words, if I want to describe the TNU: Andropogon virginicus L. sec. Radford et al. (1968) I think I could find a URI GUID for the name Andropogon virginicus . But is there some place where I could find a unique identifier, or better a URL, or best a URI providing RDF/XML for Linnaeus 1753 (the author and publication for the name) and for Radford et al.1968 (the author and publication that expresses the usage I'm intending). I suppose that this question has previously been answered in the in the many posts on taxon names, concepts, etc. However, since usually my brain goes numb and my eyes glaze over in those threads, I probably missed it. Steve -- Steven J. Baskauf, Ph.D., Senior Lecturer Vanderbilt University Dept. of Biological Sciences postal mail address: VU Station B 351634 Nashville, TN 37235-1634, U.S.A. delivery address: 2125 Stevenson Center 1161 21st Ave., S. Nashville, TN 37235 office: 2128 Stevenson Center phone: (615) 343-4582, fax: (615) 343-6707 http://bioimages.vanderbilt.edu

8 26

Animal Camera Trap data and Darwin Core: Thoughts?
by Pilsk, Suzanne 23 Dec '10

23 Dec '10

Dear TDWG group, I am working with some folks on building an animal camera trap data repository. We are seriously looking at Darwin Core as the basis of the metadata model for the information regarding these images and animals caught on camera. Do you know of any Camera Trapping or other similar style data collection program that is using Darwin Core? Do you have any suggestions on the pro's and con's of using Darwin Core for such a project? Feel free to email me directly. Thank you, Suzanne Suzanne C. Pilsk Head, Metadata Unit Smithsonian Institution Libraries Connecting. Ideas. Information. You. 10th & Constitution Avenues, NW, NH2207 MRC 154, P.O. Box 37012 Washington, DC 20013-7012 v. 202.633.1646 PilskS(a)si.edu<mailto:PilskS@si.edu> P Please consider the environment before printing this email.

3 2

proposed term: dwc:verbatimScientificName
by David Remsen (GBIF) 13 Dec '10

13 Dec '10

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

14 51