[tcs-lc] nameObjects, spellings, vernaculars, etc
Roger Hyam
roger at hyam.net
Fri Apr 29 12:41:02 PDT 2005
I believe all the points you raise can be addressed with the current
schema (0.95.2).
As I pointed out to Rich you can have a plain string name as a concept
name (whatever spelling you like) and you can choose to reference it to
a NameObject with a correctly specified name if you want to. (see
ReferenceType complex type and its uses).
If it is a vernacular you can put in a language attribute and then state
it's relationships to other concepts using the regular concept
relationships.
We have hardly touched the TaxonConcept side of things between 0.95 and
0.95.2 all we have done is move the nomenclatural part out so that we
*could have* name-name relationships for things like Basionym, Conserved
names, Typification etc. These name-name relationships clearly stated in
the documentation within the schema so I am a little confused as to why
people think they are not there.
Have you tried putting an instance document together yet? Where are you
having problems?
Robert K. Peet wrote:
>Hi Rich et al.,
>
>
>
>>I do have a set of related questions that might help serve as a springboard
>>for instantiating v0.95.2. Specifically, which of the following would
>>represent unique "name objects"?
>>
>> 1. Aiidae Smith
>> 2. Xiidae Jones
>> 3. Aus Smith
>> 4. Xus Jones
>> 5. Aus Brown [heterotypic junior homonym of Aus Smith]
>> 5. Aus bea Smith [incorrect gender of species epithet]
>> 6. Aus bus Smith [correct gender of species epithet]
>> 7. Aus buus Smith [lapsus of species epithet]
>> 8. Auus bus Smith [lapsus of genus name]
>> 9. Aus fus Smith
>>10. Xus bus (Smith) Jones
>>11. Xus bus subsp. bus (Smith) Jones
>>12. Xus bus subsp. fus (Smith) Jones
>>13. Xus bus var. bus (Smith) Jones
>>14. Xus bus var. fus (Smith) Jones
>>15. Xus fus subs. bus (Smith) Jones* [inappropriate prioritisation of fus
>>and bus]
>>
>>
>>
>
>We need to define what we mean by name in the sense of various uses and
>places in the TCS. I see four primary forms being important. (1) The raw
>character string, what ever it is, including vernaculars, (2) Character
>string of a supposed code-compliant name without authorities, (3)
>Character string of a supposed code-compliant name with authorities, (4) a
>code-compliant name including all spellings and variants. Each of these
>has different functions and needs to in some way be supported by a
>combination of TCS and related TDWG standards. From the perspective of
>documenting concepts, it would be most convenient to have the first of
>these be our nameObject upfront. However, Jessie has appropriately placed
>what appears to be either 3 or 4 as the nameObject to enhance
>compatibility with the Linnaean Core effort. The listserve conversation
>seems to be drifting toward #4 alone. But let me reiterate, the TCS has
>to accommodate the other types of "names" in some way. In particular, if
>we accept the fourth type for our meaning of nameObject, then we need to
>have this use of name as an optional link to a concept, and the raw string
>in the reference (#1 or #2) should be required within the concept
>definition.
>
>If a concept is a "name" as used in a reference as we have previously
>asserted, we want to be as unambiguous as possible about that name used in
>the reference. To support all forms of taxonomic concept documentation,
>the name needs to be the character string used in the source, be it Aus
>bus, or Aus buus, or some random misspelling of the original. This use of
>name is different from a code-compliant nomenclatural unit, which might
>include alternative spellings and the like. There is a many-to-one
>relationship between name and nameObject. Ultimately the nameObject might
>be stable while the name applied to it might be a moving target. To me,
>documenting spellings of the name associated with a nameObject is outside
>the scope of TCS and should not be handled by linking concepts as Roger
>had suggested yesterday.. In short, I agree with Rich that we should
>someplace allow name-name relationships, even if this is not part of TCS.
>
>The authority is not technically part of the name but only documentation
>of the name. I grant that if our goal is to document names sensu
>ICBN/ICZN, it can be helpful to include the authority, but there is no
>standardization as to how to represent these and our list of names will
>explode with the thousands of alternative abbreviations unless we stick to
>the name string per se and recognize that the authority string is a
>separate thing, albeit required for certain nomenclatural acts and often
>useful to separate the more extreme of the different concepts to which the
>name string has been applied.
>
>Having recognized that the character string is what is important for
>supporting concepts, we can take a new look at vernaculars. Should not the
>vernacular "Yellow-legged Aus" be a valid name for the purposes or
>reporting a concept? Not all datasets or publications we might wish to
>mark up use scientific names and in these cases all we have to work with
>is the vernacular. While the vernacular usually represents an
>identification to an unspecified (or unknown) concept that is in turn
>based on a code-compliant name, we often do not know what concept or
>code-compliant name was intended and the reported vernacular is the best
>we can do. An individual investigator might synonymize such a vernacular
>concept to a concept based on a code-compliant name, but that is a
>separate act and typically unrelated to the efforts of the original
>investigator who's work we are trying to document. I see acceptance of
>the concept "Yellow-legged Aus" as no better or worse than acceptance of
>"Aus aff. bus". We have previously agreed that best practice is to avoid
>these, and we might not want to clutter up taxonomic databases with weak,
>vernacular concepts, but for purposes of providing the capacity to
>document organisms referenced in a broad range of dataset types, concepts
>based on vernacular names seem essential. Of course, if you buy into this
>argument, the next logical step is to move all the vernaculars into the
>name entity of the TCS concept object The alternative is to accept
>concepts that have a null scientific name but do have a "has vernacular"
>relationship.
>
>Having moved the code-compliant nameObjects up front, why do we need rank
>to be part of the concept? As I see it, rank belongs as an attribute of
>the nameObject and not the taxonomic concept.
>
>Bob
>
> ======================================================================
> Robert K. Peet, Professor & Chair Phone: 919-962-6942
> Curriculum in Ecology, CB#3275 Fax: 919-962-6930
> University of North Carolina Cell: 919-368-4971
> Chapel Hill, NC 27599-3275 USA Email: peet at unc.edu
>
> http://www.unc.edu/depts/ecology/
> http://www.bio.unc.edu/faculty/peet/
> ======================================================================
>
>
>
>
>
>_______________________________________________
>Tcs-lc mailing list
>Tcs-lc at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/tcs-lc
>
>
>
--
==============================================
Roger Hyam
----------------------------------------------
Biodiversity Informatics
Independent Web Development
----------------------------------------------
http://www.hyam.net roger at hyam.net
----------------------------------------------
2 Janefield Rise, Lauder, TD2 6SP, UK.
T: +44 (0)1578 722782 M: +44 (0)7890 341847
==============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050429/ddf51ffe/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: roger.vcf
Type: text/x-vcard
Size: 275 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050429/ddf51ffe/roger.vcf
More information about the Tcs-lc
mailing list