[tcs-lc] Have your cake and eat it?

[Richard Pyle]

> I'm not sure of the implications of doing away with the Concept "type"
> attribute in TCS -- that's a question for Jessie.  But as for your
proposal,
> I'm not sure I understand what you mean.  Would all propertes of a name
> object (which may be spread out over multiple publications -- such as
> leptotypification, secondary homonyms, etc., etc.) be incapsulated in one
> instance?  Or would they be assumbled from a set of instances (each with
> their own AccordingTo)?
>
>
> The attribute would be in the Taxon element so would apply to that Taxon
> instance in the schema. We are talking about a transport schema not a
> database model so your question is difficult to answer. Within your db
> you may have a whole load of objects representing nomenclatural facts
> associated with a name. In response to a query you could include all
> these within a single object or not depending on the query I suppose.

Let me try to re-state the question, with better context.

A "Name" object has certain informational properties, such as:

1) Rank-group (only three of these covered by codes, but seven in Linnean
nomenclature)
2) Authorship
3) Publication instance in which it was created
4) Primary Type designation
5) Word-form (noun, adjective, etc. -- applies to species-group names only)
6) Gender (genus-group names only)
7) "Correct" orthography
8) Original combination (basionym)
9) Nomina Nova (replacement names)
etc....

These properties are independent of concept circumscriptions, and it is the
set of these properties that drives us towards treating names as objects,
distinct from concept-objects.

These properies are not necessarily all anchored the original publication
instance (#3).  For example, the authorship of a name is not always
identical to the authorship of the citable publication in which the name was
created. Type designation often happens in a later publication.  Nomina
nova/replacement names *always* happen in a different publication from the
original publication.

The TCS approach (as I understand it) is to embed these various properties
of a name within various concept instances, such that the "AccordingTo"
element represents the reference to the publication instance in which each
nomenclatural act occurs.  Thus, to fully resolve the properties of a name
object, several TaxonConcept instances need to be interrogated.  Properties
are not explicitly attached to name objects; rather, they are
derrived/inferred (via software processing) from the set of TaxonConcepts
that have a Relationship back to the Original Concept that first established
the name.

The point of "Name object modularization" (in my mind) is to more
directly/explicitly "attach" ("package") the various name object properties
to the name object itself.

You wrote "LC is embedded within a TaxonConcept element but the relationship
stuff is moved to TCS"

I interpreted this to mean that things like "relationship between a name
combination and its basionym", and "relationship between a genus-group name
and its type species" would be accomdated by the existing TCS structure,
rather than within LC.  If I'm wrong about this, then I misinterpreted your
proposal.  But the problem is, a "Name" object may have several
"AccordingTo" links to accomodate all of its various nomenclatural
properties, but TCS only accomodates one "AccordingTo" reference per
TaxonConcept instance.  So to pass the full set of nomenclatural properties
of a particular name object, there may need to be several TaxonConcept
objects, with all the embedded nomenclatural Relationships, each attached to
its respective "AccordingTo".

I recognize that this approach *will* work, and *can accomodate*
nomenclatural information transfer.  The problem I have with it is that it
mixes "Realtionships" that involve properties of names with "Relationships"
that involve properties of concept circumscriptions; and the nomenclatural
properties of a Name-object have to be "mined" via software interrogation of
potentially several TaxonConcept instances.  That seems like a highly
inelegant way of transferring information about Name objects.

I think that you and I are thinking along similar lines here, but we have
taken different approaches to tweaking TCS to acommodate our needs.  I've
spent a lot of time thinking about it these past couple of weeks, and the
more I think about it, the more and more I like the idea of defining a
Nominal Type TCS instance as the repository for the full set of name-object
properties (without in any way altering its Concept meaning that it was
originally created to represent).  It seems to solve many problems
simultaneously, and at a schema-enforcement "cost" that seems to me to be
much lower than other schema-enforcement costs already accepted within TCS.

> That is because all of these schemas are beginning to converge.
> We are nearing a singularity? "Great minds think alike - but
> fools seldom differ".

:-)

> They may be spread or not. That depends on how you use the
> schema. There will be millions of instances of these things
> moving between dbs. They are ephemeral. It is not a database model.

I understand that part, but I still am not clear on what you mean.  Could
you structure a simple example of what your proposed schema approach would
look like?  Maybe use Sally's earlier example:

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

> I don't think 'taxons' would go down well although I use
> schemas quite a bit :)

Don't get me started! (Here in Hawaii, there are all sorts of
bastardizations of plural forms!)
:-)

Here's a question for TCS folks:

How important is it to preserve the convention of:

<InstanceItems>
  <InstanceItem>
  </InstanceItem>
</InstanceItems>

that differ only in the presence of a terminal "s"? I remember reading it
somewhere in the TCS documentation.  But is there a reason for enforcing
this other than aesthetics?  How painful would it be to change:

<TaxonConcepts>
  <TaxonConcept>
  </TaxonConcept>
</TaxonConcepts>

To:

<Taxa>
  <Taxon>
  </Taxon>
</Taxa>

Doing so might make it more appealing -- especially if "Names" are treated
as objects, but not as top-level objects (i.e., within the existing <Name>
element of TCS).

Aloha,
Rich