[tcs-lc] Modularisation of standards - identification of names

[Sally Hinchcliffe]

Jessie wrote:

> Sally wrote:
[...]
> >One use case that springs to mind is the separation of homonyms,
> >particularly where it comes to homonym genera. >In the canonical
> names part of the Linnean Core we included (I'm >not sure if it's
> disappeared in the latest version, but I >don't think so) >scope
> for a reference attribute in the separate atoms of the names. >So
> in a binomial, the <genus> object could have a reference (id)
> >that would allow the output to unambiguously identify _which_ Aus
> >we had in mind when we said Aus bus. 
> 
> If you modelled names as concepts then there would not be any ambiguity as to which Aus you meant as each Aus woudl be a concpet and would have it's own ACCordingTo which I think is what Sally is saying they needed to put into LC??

... well, & I thought about this but it seems to mean in order to 
pass one binomial  I have to pass two TCS objects (and three for a 
trinomial), related to eachother as parent and child, is that right?
That might be intellectually consistent, but it wouldn't be very 
practical... 

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 agree with Sally that we would probably want ot have the GUID and what we've talked about - the primary key, in this case the name plus the according to. My only different take on htis would be htat you could if you really wanted have the Nameid = a taxonconceptGUID and have the label as 
Sally has. Maybe this would give the reuse that people seem to want but oif course all we would be saying is the the id in Name would be meaning the name element of the Taxonconcept referred to by the GUID.

.. that's assuming there is a guid ... The example I gave was 
deliberately ambiguous as to whether it was an id with an 
existence outside the dataset, or one generated on the fly, or one 
that could be used as a persistent, always resolvable id like a guid. 
Basically the parser could either simply note that the ids were the 
same (and hence the objects they referred to were the same) and 
then throw away the actual ids or it could retain the ids if they were 
references to something more persistent
> 
> >On a slightly related subject, Gregor and I did some thinking and 
> >discussing on ids - it's on the LC wiki somewhere - trying to come 
> >up with a structure that would allow ids to have different scopes: 
> >either transient ones (1, 2, 3 ...) that were created for the 
> >life of a 
> >document and only made sense within that context, or ones which 
> >referred to ids that were unique and immutable in the context of a 
> >dataset (e.g . IPNI ids) all the way up to full blown LSIDs. Looking 
> >at that might help futureproof any schema we do come up with so 
> >that if LSIDs or whatever do take off we're able to deal with them
> >
> do we need to model these separately or have some inbuilt meachanism (in the software)of determining what we've been passed?
> 
I think it was using attributes of the id. see 
http://bdei.cs.umb.edu/twiki/bin/view/UBIF/ObjectIdentifierPattern

for a more detailed discussion

Sally

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