[Tcs-lc] Human Readable - the thread formally known as 'Name of NomenCode'

Sally Hinchcliffe S.Hinchcliffe at rbgkew.org.uk
Tue Mar 29 05:49:42 PST 2005


Roger wrote:

> I am working with Jessie and Robert on the schema at the moment and hope 
> to get fancier pointers in there. They make sense to me.  I hope we can 
> have something to throw open for discussion in the next couple of days.
> 
> I am just trying to generate an instance document for a couple of 
> species by hand at the moment and I am getting very confused.
> 
> What is the relationship type between a species and it's genus? Is it 
> 'included in' or 'child of' and would the user agent expect the 
> reciprocal relationships to be marked up i.e. 'includes' and 'is parent 
> of'?

This is why we started talking about fancy pointers into LC in the 
first place - to handle linking a species to its genus. I'm attaching 
a (very old version) example of LC which shows (an old format) fancy 
pants pointers to handle the relationship between genus and species 
in LC. The actual schema is out of date but it gives the idea (this 
example file is also included in the 
http://wiki.cs.umb.edu/twiki/bin/view/UBIF/LinneanCoreCurrentVersion  
LinnaeanCoreV01_3.zip  -see spec_Caesia_spiralis.xml)

> Would all software agents:
> 
>    1. expect only up pointing links.
>    2. expect only down pointing links.
>    3. expect both to be present for the link to be valid.
>    4. allow the use of a mixture of the two, relationship sometime shown
>       with 'includes' and sometimes with 'included in'.
> 
Argh, this is where it gets difficult, and each data provider will 
have different preferences (as well as each data consumer). For IPNI, 
it's dead easy to get the parent (e.g. genus for a species) for any 
given name, but another big hit of the database to get the children. 
Presumably working downwards is going to be tidier than working 
upwards, but if you want to hit a data provider for a low level name 
(such as species) you may want it to provide you with the higher 
level classification as well? 

> I define relationships between a species concept and it's genus concept 
> but what about the subgenus and sectional stuff?
> I could:
> 
>    1. mark the species as belonging to the section and section to
>       subgenus and subgenus to genus and not specify any other relationships

Nomenclaturally, (and in IPNI, for example) the species only knows 
about its genus, because that's part of its name.It's TCS's job 
(because it's a TaxonConcept) to put a species in a section, and from 
there to link to the genus. So you are always going to have to relate 
the species to its genus, in order to get the binomial validly. LC 
should only allow you to build the binomial which is why we 
structured the CanonicalName the way we did. i.e. you can use LC to 
encode a genus on its own, an infrageneric within a genus, a species 
within a genus, or an infraspecific within a species, but _not_ a 
species within an infrageneric, or an infraspecific at two ranks (Aus 
bus var. cus f. dus - nomenclaturaly equivalent to Aus bus f. dus)

>    2.  join the species to section, subgenus and genus as well as
>       joining up the section to subgenus and genus and subgenus to
>       genus. i.e. all the includes relationships.
 .. and all the other infrageneric ranks, which can be increased at 
any time.
>    3. do a mixture of the two. Species always in genus but other things not.
> 
This would be a mixture of nomenclatural (Aus bus is in Aus) and 
taxonomic (Aus bus is in sect. C) information. In my opinion LC 
should handle the former and TCS the latter. Therefore two LC objects 
(Aus bus and Aus sect. C) related by the TCS relationship Aus sect. C 
is the parent of Aus bus OR Aus bus has the parent Aus sect. C

for me, we _can't_ do 1. it would have to be 3.

> Confused? I am and I am just doing this manually! I find the thought of 
> writing software to consume this more scary than handling the links to 
> the publications and specimens. Even if we define how these 
> relationships should be encoded there is no way for the schema to 
> validate it so we will have to write checking code and try and handle 
> graceful degradation etc. I think we need to nail this thing down a bit 
> - there should only really be one way of encoding a basic taxonomic 
> hierarchy and that should be enforced by the schema I think. What do you 
> all think?
> 
> Has anyone generated instances of recent versions of the TCS (0.9+) 
> using real data? If so could they send me one.

I think Napier put some examples together. Not sure how far they got 
with them (http://wiki.cs.umb.edu/twiki/bin/view/UBIF/TcsNameExamples 
)

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

-------------- next part --------------
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  spec_Caesia_spiralis.xml
     Date:  5 Nov 2004, 16:46
     Size:  861 bytes.
     Type:  Unknown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spec_Caesia_spiralis.xml
Type: application/octet-stream
Size: 861 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050329/4d5d324f/spec_Caesia_spiralis.obj


More information about the Tcs-lc mailing list