[tcs-lc] Names as Objects

[Kennedy, Jessie]

Rich said:

>
>Right now, TCS is structure like something this (highly simplified):
yes this was ok

>Obviously I've simplified and/or omitted a bunch of stuff, but the main
>point is that the "Nomenclatural schema" (ABCD Names in v085a; 
>possibly to
>be replaced by LC) is embedded within the TaxonConcept 
>instances, such that
>the name elements amount to properties of a TaxonConcept, 
>rather than as
>separate objects by themselves. 
yes

> This is in contrast to Vouchers and
>Publications, which are objects that exist separately from 
>TaxonConcepts,
>but are referenced (via UIDs, preumably) from within TaxonConcepts.

yes

>
>I have been championing the perspective that "Name Objects" exist as
>distinct entities from "Concept Objects".  If my perspective 
>bears out, then
>we should be able to rearrange the above schema into something 
>like this:
>
yes you could do this....but see below....

>
>The only difference is that the entire nomenclatural schema 
>has been pulled
>out from within TaxonConcepts, and given its own top-level 
>structure just
>like Publications and Vouchers.  
structurally you are correct but the semantic changes that can result to the meaning of data represented by this structural change are more pervasive.

> Also, the scope of "type" of 
>Relationships
>would be more restrictive in the latter scenario -- excluding 
>those that
>involve concept-less nomenclatural relationships between names.

but as we've sen from Nico's work it's difficult to really separate these out.

>rejected, I would appreciate it if someone could explain to me 
>why it was
>rejected.

it's not so much it was rejected but rather we tried to come up with a model that would possibly address the needs of a wider range of users. 
>
>I think this approach would be more appealing from the LC prespective,
>because it would allow a "clean" package of name-only data 
>along the lines
>of:
>
><DataSet>
>  <Vouchers>
>    [Type specimens]
>  </Vouchers>
>  <Publications>
>    [Nomenclaturally relevant publications]
>  </Publications>
>  <TaxonNames>
>    [Full-blown Name data, with references to publications and 
>type specimen
>vouchers]
>  </TaxonNames>
></DataSet>
>

Note: 
  <TaxonNames>
    [Full-blown Name data, with references to publications and type specimen vouchers]
  </TaxonNames>

is *very* much simplified - so don't be fooled.......
we could've put 
  <TaxonConcepts>
    [Full-blown Concept data, with references to publications, descriptions  and specimen vouchers]
  </TaxonNames>

which looks equally simple ;-)


However the name-only package could be represented in TCS as:

<DataSet>
  <Vouchers>
    [Type specimens]
  </Vouchers>
  <Publications>
    [Nomenclaturally relevant publications]
  </Publications>
  <TaxonConcepts> [Full-blown Name data, with references to publications and type specimen vouchers]
    <TaxonConcept> [original or nominal concepts]
	<Name>
	  <NameSimple>
	    [simple rendering of name]
	  </NameSimple>
        <NameDetailed>
	    [...entire embeded Nomenclatural schema - minus relationships, publications etc. as we already have this at the TCS level]
        </NameDetailed>
	</Name>
	<Relationships>
	  [...nomenclatural references to other TaxonConcept objects with relevant names ]
	</Relationships>
	<SpecimenCircumscription>
	  [...references to Voucher objects (read Type specimen)]
	</SpecimenCircumscription>
    <TaxonConcept>
    [...more instances of TaxonConcept objects  containing names of interest]
  </TaxonConcepts>
  </DataSet>

>I can immediately see several concerns from the TCS 
>perspective, such as the
>possible encouragement of attaching specimen identifications 
>directly to
>Names (without passing through a concept), and perhaps some 
>confusion about
>what sorts or information appropriately belongs within
>TaxonConcept/Relationshops, vs. within the Names.  
yes these are the main issues and not easily dismissed but others are:

If a concept has a name object as one of its components and that object has its own independence and is shared by many concepts (which is also what James is advocating) then if the name is changed (for whatever reason) it is changed in every concept that includes it. You might say great!! but then you would not be able to record cocnepts as they were actually defined and you would start to lose the history - this menas you can't store and maintain the equivlaent of hte "published" record of the concept unless you duplicate this information and then you start to wonder what the gain was.

Also it means that you can introduce names without any concept - and this then becomes a problem for users of taxonomic information. They are told by someone this is the "correct" name but not told what the name means. So if several users use that name with their own meaning we then have the problem of potentially tagging different concepts with the same name and not being able to spearate this out.
  
So again we're not saying the TCS is an exact represetation of the best way for either taxonomists or nomenclators or biologists refering to taxa to model their data but a way that tries to allow all of them to be modelled in the same framework. It also reduces ambiguity and could reduce the enormous duplication of effort currently taking place in trying to capture and improve on the amount and quality of electronic taxonomic data available.

>On a sort of related question, would it be worth considering 
>an "<Agents>"
>top-level element & simple schema?  That would allow UID 
>reference to Agent
>objects from within Vouchers (as collectors, etc.), from 
>within Publications
>(as authors), from within LC (as name authors, when different 
>from authors
>of original description publications), from within 
>TaxonConcept/AccordingTo
>(as AccordingTo source), and from within 
>RelationshipAssertion/AccordingTo
>(same).
>

we considered this but were told on many occasions that it was too complicated to resolve for legacy data and that even in botany where they tried to have approved author teams it hadn't worked - so decided to leave it.

Jessie