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

[Richard Pyle]

More detailed response to Sally (I was in a rush earlier this morning):

> 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
[...]

That's almost exactly how I would render it in the schema version "1" I
posted to this list.

The main differences are:

>   <TaxonConcept id="co1" type="original">

I would opt for type="nominal" as the container for name-only data -- so as
not to confuse it with the implied concept circumscription defined by H.Koba
& T.Tateoka (I assume you wanted only to provide the name bits, not the
implied concept bits).

>       <NameSimple>Poa acroleuca var. ryukyuensis H.Koba &
> T.Tateoka</NameSimple>

In my version, I re-defined "NameSimple" and added "NameComplex" to
distinguish between "properly formatted name without authorship", and
"properly formatted name with authorship", respectively.

>       <LCName>
>         <Label>Poa acroleuca var. ryukyuensis H.Koba &
> T.Tateoka</Label>

I bumped this up to NameSimple/NameComplex elements, one level up the chain.

> 	<CanonicalName>
> 	  <Text>Poa acroleuca var. ryukyuensis</Text>

What was the "Text" element here under CanonicalName, I re-defined as
"NameSimple".

> 	  <Genus id="http://www.ipni.org/...id=18760-1"
> idtype="url">Poa</Genus>

I forgot to include the full URL -- could have easily done so.

> 	  <SpecificEpithet id="http://www.ipni.org/...id=416418-1"
> idtype="url">acroleuca</SpecificEpithet>

I didn't know the IPNI id for the specific epithet name, so I could have
included it as you did.

> 	<Rank>var.</rank>

Logically, I think "Rank" only applies to a Scientific Name, but could apply
even if no NameDetailed is provided -- which explains why I moved it to
where I did.

> 	<CanonicalAuthorship>
> 	  <Text>H.Koba & T.Tateoka</Text>
> 	</CanonicalAuthorship>

According to LC, you need to include a <ProtonymAuthorship> container here,
to distinguish from <CombinationAuthorship>. Also, I used the (older?)
"AuthorSimpleYear" from my copy of LC 0.1.5, instead of the "Text" option.

>     <AccordingTo>
>       <AccordingToSimple>H.Koba &
> T.Tateoka</AccordingToSimple>
>     </AccordingTo>

Because I embed in a type="Nominal" TC instance, there is no "AccordingTo".
In this context, "AccordingTo" means (to me) "SEC." or "sensu."; whereas the
link between a name object and the publication in which it was described is
more direct.  Thus, within the NameDetailed container, I would have either:

<FirstPublication id="[GUID or LUID]"/>

..or, as in my revised version with only one TC instance:

<FirstPublication>
  <PublicationSimple>H.Koba & T.Tateoka [etc...]</PublicationSimple>
<FirstPublication>

I actually didn't include a "PublicationSimple" element in the schema
version I sent, but it could easily be added if deemed appropriate.

In any case, the data content between your version and my version are almost
identical.  The main difference is with regard to type="Nominal", and
element structure.

> (I've based this on Linnean core v.0.1.6 from the Wiki but I have

Oops!  I forgot there was an LC 0.1.6 -- that came after I dropped out of
the loop.  Sorry!

> 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.

One could change the structure of CanonicalName and CanonicalAuthorship of
the LC components to allow embedding authorship of all name "units" (of
which your example has three).  But I'm not sure I would favor that.  I
guess it's a balance between "normalization", and the complexity of
providing multiple instances when it "seems" like there should be only one.

> 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.

What pieces of information are required via the ID links to IPNI that you
include?  If you mean full name details for all three units of the name
(Genus, species, variety), then I think you are really talking about three
instances of "Name" (which would allow you to use transiet ID's).  I suppose
one could provide elements to accomodate the full embedding of name
structures for all three parts of the name within a single "Nominal" TC
instance -- but I wonder if that is really the best way to go about it.

> 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

This option makes sense to me, if you want full details for all components
of all three name units.

> B) to return a single TCS record with an ambiguous trinomial (i.e.
> no genus or specific epithet ids included)

This is not mutually exclusive with "A".

> 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

This is not mutually exclusive with "A" or "B".

> D) to return a single TCS record with three LC records using
> transient ids for the Genus and specific epithet ids

That is certainly possible, and I can almost imagine the structure of
providing it.  Basically, you would use the

> E) ?Not sure if Rich's suggested structure would help here but if it
> could, it's a fifth option

I think my approach allows any of "A", "B", or "C".  It *could* allow option
"D" in the version that I didn't send (i.e., the one with a
"NameRelationships" element within NameDetailed).  I'd be happy to work up a
version of this sort, if you think it would help.

> - D seems to me to be a non starter.

Doesn't have to be, but I'm happy to consider it so.

> 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.

I mostly agree, but don't see a problem with option "A" if someone wants to
package full details of all three units of a trinomial.

Rich