[tcs-lc] Poa acroleuca var. ryukyuensis H.Koba & T.Tateoka

Sally Hinchcliffe S.Hinchcliffe at rbgkew.org.uk
Wed Mar 9 06:03:31 PST 2005


Apologies, by the way, but I'm not keeping up with all of the current 
tcs-lc emails so if I write something that seems to have missed 
what someone else has said that's the reason. I'm _trying_ to keep 
up but it's hard ... 

Jessie wrote
> Sally wrote:
> 
> >What would the TCS schema look like in order to pass the 
> >following IPNI record:
> >
> > Poa acroleuca var. ryukyuensis H.Koba & T.Tateoka
> >
> >Where the parent of the variety is Poa acroleuca Steud.
> >
> >and the parent of the species is Poa L.
> >
> >If we have to handle upward links via the TCS and not via LC?
> >
> 
> I guess there could be different answers to this question...
> the simplest would be to have taxonconcept for the variety and include references to the other realted concepts which we assume can be resolved, if not these would need to be included. I have only filled inthe name simple and AccordingTo simple but hte detailed elements could be filled out.
>  
> 
> <TaxonConcepts>
> 		<TaxonConcept id="co1" type="original">
> 			<Name type="scientific">
> 				<NameSimple>Poa acroleuca var. ryukyuensis H.Koba & T.Tateoka</NameSimple>
> 			</Name>
> 			<AccordingTo>
> 				<AccordingToSimple>H.Koba & T.Tateoka</AccordingToSimple>
> 			</AccordingTo>
> 			<Kingdom>Plant</Kingdom>
> 			<Rank>variety</Rank>
> 			<Relationships>
> 				<Relationship type="is child of">
> 					<ToTaxonConcept ref="co2"/>
> 				</Relationship>
> 			</Relationships>
> 		</TaxonConcept>
> <TaxonConcept id="co2" type="original">
> 			<Name type="scientific">
> 				<NameSimple>Poa acroleuca Steud.</NameSimple>
> 			</Name>
> 			<AccordingTo>
> 				<AccordingToSimple>Steud.</AccordingToSimple>
> 			</AccordingTo>
> 			<Kingdom>Plant</Kingdom>
> 			<Rank>variety</Rank>
> 			<Relationships>
> 				<Relationship type="is child of">
> 					<ToTaxonConcept ref="co3"/>
> 				</Relationship>
> 			</Relationships>
> 		</TaxonConcept>
> 		<TaxonConcept id="co3" type="original">
> 			<Name type="scientific">
> 				<NameSimple>Poa L.</NameSimple>
> 			</Name>
> 			<AccordingTo>
> 				<AccordingToSimple>Linnaeus</AccordingToSimple>
> 			</AccordingTo>
> 			<Kingdom>Plant</Kingdom>
> 			<Rank>variety</Rank>
> 			<Relationships>
> 				<Relationship type="has child ">
> 					<ToTaxonConcept ref="co2"/>
> 				</Relationship>
> 			</Relationships>
> 					</TaxonConcept>
> 
> 
> ok so this doesn't say much but I guess that's baecause all I've done is represent what you've said without inferring anything....hope this wasn't a trick example ;-)
> 

No, no trick question. Genuinely trying to tease out a complexity 
that has bothered me for a while.

I worry that if IPNI is asked a simple question (like what record is 
represented by the record id 965880-1) requiring a single answer, 
then it would only be able to respond with three records (as in your 
example above). Leaving it up to the person asking the question to 
guess which one was the answer.
I'm not sure that putting the parentage in Linnean core will help. 
The way I had thought LC would work given the same example was 
as follows (and I have put in the canonical name, because that is 
how it makes it work) - (Also I've probably got the join wrong 
between Linnean Core and TCS because I couldn't find the email 
where that was discussed & I might have missed vital bits out of 
the TCS part of the schema ... sorry)

<TaxonConcepts>
  <TaxonConcept id="co1" type="original">
    <Name type="scientific">
      <NameSimple>Poa acroleuca var. ryukyuensis H.Koba & 
T.Tateoka</NameSimple>
      <LCName>
        <Label>Poa acroleuca var. ryukyuensis H.Koba & 
T.Tateoka</Label>
	<CanonicalName>
	  <Text>Poa acroleuca var. ryukyuensis</Text>
	  <Genus id="http://www.ipni.org/...id=18760-1" 
idtype="url">Poa</Genus>
	  <SpecificEpithet id="http://www.ipni.org/...id=416418-1" 
idtype="url">acroleuca</SpecificEpithet>
	  <InfraspecificEpithet>ryukyuensis</InfraspecificEpithet>
	</CanonicalName>
	<Rank>var.</rank>
	<CanonicalAuthorship>
	  <Text>H.Koba & T.Tateoka</Text>
	</CanonicalAuthorship>
      </LCName>
     </Name>
    <AccordingTo>
      <AccordingToSimple>H.Koba & 
T.Tateoka</AccordingToSimple>
    </AccordingTo>
  </TaxonConcept>
</TaxonConcepts>

(I've based this on Linnean core v.0.1.6 from the Wiki but I have 
changed the ref attribute in the genus and specific epithet object so 
that they use the id model proposed in 
http://bdei.cs.umb.edu/twiki/bin/view/UBIF/ObjectIdentifierPattern)

Now, while this only returns one record, and it's unambiguous that 
is ONLY because I've assumed a link to an IPNI id which is 
resolvable - the Poa L. and Poa acroleuca Steud. would have to be 
got in second calls to IPNI. So I'm not saying it's better. And I'm 
not sure HOW we would handle trying to unambiguously serve up a 
trinomial using only transient ids which is what Jessie's example 
gives. In both cases, there would always be the option of simply 
giving the trinomial and leaving the parents ambiguous.

So my question to the group (assuming anyone's got this far) is 
which is better?

A) To return three linked TCS records for every (unambiguous) 
trinomial, and let the questioner work out which was the record 
they want
B) to return a single TCS record with an ambiguous trinomial (i.e. 
no genus or specific epithet ids included)
C) to return a single TCS record with externally referenced Genus 
and specific epithet ids in the LC element, which the questioner 
can follow up if they want to
D) to return a single TCS record with three LC records using 
transient ids for the Genus and specific epithet ids
E) ?Not sure if Rich's suggested structure would help here but if it 
could, it's a fifth option

- D seems to me to be a non starter. My preference is for C (for 
those servers which can provide resolvable ids and/or care about 
parenthood) combined with B for those servers which don't provide 
resovable ids. 

Sally


> now whether or not you point up the tree or point down I guess relaly depends on what you were doing or what you're represetning. If I'm representing names coming out of a classification then I'd probably point down but you could equally back traverse these links - or you could define things as 
having parents rather than having children.
> 
> I agree that having GUIDs makes all of this simpler though.....
> 
> So not sure I've captured what you meant but if not tell me what's missing......
> 
> Jessie
> This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
> It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
> or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the 
> University's system is subject to routine monitoring and filtering by the University. 
> _______________________________________________
> tcs-lc mailing list
> tcs-lc at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/tcs-lc


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



More information about the Tcs-lc mailing list