[eml-dev] taxonRankValue for species names

Tue Sep 4 09:15:27 PDT 2012

I agree on this one too -- the binomial is the appropriate value for the
species rank.  The confusion with the docs came in because we were trying
to be compatible with FGDC, which explicitly stated that the species rank
should contain just the monomial.  Thinking on this has come around now, so
we can probably change it without significant repercussions.  The other
recommendation, that people fill in as many levels of the hierarchy as
possible, is also probably a bad idea, as other levels of the taxon
hierarchy can change.  Searching up and down the taxonomic tree should
really occur via an external classification service like ITIS, rather than
hardcoding the classification in the metadata documents. This does put more
of a burden on search engine providers (in that they have to search the
external service), but it will also be significantly more accurate and
complete.

Matt

On Tue, Sep 4, 2012 at 7:46 AM, Margaret O'Brien <mob at msi.ucsb.edu> wrote:

> Hi Wade -
> I agree with James.
> For your code (and assuming it is for use with LTER datasets), I would
> assume that the input conforms to our Best Practices. Code that can detect
> the difference between the species binomial and the species fragment is a
> friendly touch, but I think that looking for a space character might be a
> little unreliable. One could also argue that accommodating bad practice is
> not a particularly good idea (despite what's in the normative docs), but
> that is a somewhat unpopular point of view.
>
> There are many areas where the normative docs are not quite in line with
> best practices. I will enter your email in as a bug so that it can be fixed
> in some future release.
>
> Margaret
>
> -----------
> Margaret O'Brien
> Information Management
> Santa Barbara Coastal LTER
> Marine Science Institute, UCSB
> Santa Barbara, CA 93106
> 805-893-2071 (voice)
> http://sbc.lternet.edu
>
>
> On 9/3/12 8:47 PM, James Brunt wrote:
>
>> I was taught - admittedly long ago - that, taxonomically speaking, the
>> 'species name' must include the genus and the specific epithet. While
>> looking at it from a strictly hierarchical node structure the specific
>> epithet looks and acts like the other nodes. However, taxonomically the
>> node 'alterniflora' has no taxon rank by itself. I guess I'd prefer to
>> see the binomial 'species name' concept retained in our metadata if
>> there is no confounding reason why it shouldn't be so.
>>
>> The is also a mistake in the normative docs if they are referring to
>> Acer rubrum as the 'common name' of Red Maple.
>>
>> My two bits.
>>
>> James
>>
>> James W. Brunt
>> Chief Information Officer
>> Long Term Ecological Research Network
>> LTER Network Office
>> Department of Biology MSC03 2020
>> 1 University of New Mexico
>> Albuquerque, NM 87131-0001
>> 505 277 2535
>> jbrunt at LTERnet.edu
>> OpenPGP-Id: 1024D/4E657C39
>>
>> On 9/3/2012 10:51 AM, Wade Sheldon wrote:
>>
>>> Hi folks,
>>>
>>> I've been working on an XSL that extracts selected content from an EML
>>> document to annotate parsed data sets in MATLAB, and I came across some
>>> inconsistencies in encoding of taxonomicCoverage elements for species
>>> names from different EML implementers. Specifically, some authors use
>>> the species binomial, and some do not, i.e.
>>>
>>> with binomial:
>>>
>>> <taxonomicClassification>
>>>     <taxonRankName>Genus</**taxonRankName>
>>>     <taxonRankValue>Spartina</**taxonRankValue>
>>>     <taxonomicClassification>
>>>        <taxonRankName>Species</**taxonRankName>
>>>        <taxonRankValue>Spartina alterniflora</taxonRankValue>
>>>     </taxonomicClassification>
>>> </taxonomicClassification>
>>>
>>> vs.
>>>
>>> without binomial:
>>>
>>> <taxonomicClassification>
>>>     <taxonRankName>Genus</**taxonRankName>
>>>     <taxonRankValue>Spartina</**taxonRankValue>
>>>     <taxonomicClassification>
>>>        <taxonRankName>Species</**taxonRankName>
>>>        <taxonRankValue>alterniflora</**taxonRankValue>
>>>     </taxonomicClassification>
>>> </taxonomicClassification>
>>>
>>>
>>> When I first started producing EML back in 2003 I used the species name
>>> without genus, but Matt Jones and Dan Higgins suggested I use the
>>> species binomial instead. We also included that recommendation in the
>>> LTER EML best practices
>>> (http://im.lternet.edu/sites/**im.lternet.edu/files/**
>>> emlbestpractices-2.0-FINAL-**20110801_0.pdf<http://im.lternet.edu/sites/im.lternet.edu/files/emlbestpractices-2.0-FINAL-20110801_0.pdf>
>>> ).
>>>
>>>
>>> However, the normative docs for EML 2.1.1
>>> (http://knb.ecoinformatics.**org/software/eml/eml-2.1.1/**
>>> eml-coverage.html<http://knb.ecoinformatics.org/software/eml/eml-2.1.1/eml-coverage.html>
>>> )
>>> seem to suggest the opposite approach:
>>>
>>> "The name representing the taxonomic rank of the taxon being described.
>>> The values included may be referenced from an authoritative source such
>>> as the Integrated Taxonomic Information System (ITIS)in the U.S.
>>> (http://www/itis.usda.gov) and in Canada
>>> (http://sis.agr.gc.ca/pls/**itisca/taxaget<http://sis.agr.gc.ca/pls/itisca/taxaget>).
>>> Also, Species2000 is another
>>> source of taxonomic information, found at (http://www.sp2000.org)
>>> Example(s):
>>> Acer would be an example of a genus rank value, and rubrum would be an
>>> example of a species rank value, together indicating the common name of
>>> red maple. It is recommended to start with Kingdom and include ranks
>>> down to the most detailed level possible."
>>>
>>> For now I'm revising the XSL to check for species-only using a contains
>>> node test on a space character, but handling both cases is a pain
>>> considering the nesting, so it would be better to standardize on one
>>> approach.
>>>
>>> Thoughts?
>>>
>>> Wade Sheldon
>>> GCE-LTER
>>>
>>>
>>> ______________________________**_________________
>>> Eml-dev mailing list
>>> Eml-dev at ecoinformatics.org
>>> http://lists.nceas.ucsb.edu/**ecoinformatics/mailman/**listinfo/eml-dev<http://lists.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev>
>>>
>> ______________________________**_________________
>> Eml-dev mailing list
>> Eml-dev at ecoinformatics.org
>> http://lists.nceas.ucsb.edu/**ecoinformatics/mailman/**listinfo/eml-dev<http://lists.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev>
>>
>
> ______________________________**_________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org
> http://lists.nceas.ucsb.edu/**ecoinformatics/mailman/**listinfo/eml-dev<http://lists.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20120904/4b47a412/attachment-0001.html>