[tcs-lc] Names as Objects

[Richard Pyle]

In response to Jessie:

> the designers of TCS separated out the relationships and
> relationship assertions because we tried to separate out the
> definition of concepts which should be used (certainly primarily
> if not exclusively) for matching to labels used in
> identifications and therefore for relating concepts, from
> general assertions by someone about (mostly always) someone
> else's concept - which doesn't affect the original definition.

Right -- that's essentially what I meant.

> The reason names have been treated as concepts is because they
> become concepts because people are encouraged to use "correct"
> names

I think that what really happens is that they become "Nominal" concepts as
you folks have definied it (and, if I understand the definition correctly,
it is an extremely valuable way of linking name-only data to concepts). As
for "correct" -- there are two kinds of corrections -- those related to name
objects, and those related to concept circumscriptions.  The former are
about "name" corrections as governed by Codes, and the latter are about
corrections in order to adhere to more modern concept definitions.

> so they inherit a meaning therefore we want them to be
> concepts even if in the original publication of that name there
> is no concept described as such there will be reference to the
> original concept (in your terms the original name embedded in the
> original concept) that this is a correction for.

That's where we disagree, I think.  If I read you correctly, you suggest
that a name without an elaborated concept should default to the "Original"
concept.  I say it should default to the corresponding "Nominal" concept.
That's why I think the "Nominal" concept is such a powerful tool -- it says
"we don't know what concept was asserted, but we know that it likely falls
within the set of possible concepts for which this name has been assigned".
That's exactly the sort of "concept" we want name-only data to default to.

> The Relationships within a Taxonomic concept have one target,
> that pointed to from the current taxonomic concept being defined,
> and it is implied that these relationships were by the person in
> the AcccordingTo and in the Publication where the concept was
> defined. The RelationshipAssertions allows us to relate 2
> concepts both of which have to be specified by a different Author
> in a different publication. (can also be used to make a statement
> about 1 concept)

Yes, but you agree that the schema *structure* of RelationshipAssertions
could be used for both purposes -- right?  I mean, the elements are all
there -- right?  You could put the "AccordingTo" of the TaxonConcept
instance in the "AccordingTo" of RelationshipAssertions, and you could put a
pointer to the defined TaxonConcept instance in the "FromTaxonConcept" of
RelationshipAssertions.  You could even distinguish RelationshipAssertions
that form part of the definition from RelationshipAssertions that are
secondary interpretations by simply testing whether the
/RelationshipAssertion/AccordingTo equaled the /TaxonConcept/AccordingTo for
the TaxonConcept instance indicated in
/RelationshipAssertion/AccordingTo/FromTaxonConcept.  Doing it this way
would allow you to dump the /TaxonConcept/Relationships elements altogether.

My point is, there is structural "elegance" in separating the "definition"
relationships from the "interpreted" relationships -- which is why I do NOT
think you should combine them both under RelationshipAssertions (i.e., leave
them as they are now).


> >> Rich proposes that there could be a brief summary of a name in the
> >> TaxonConcept element as well as a pointer the to full
> >scientific name.
> >
> >...as currently exists with "NameSimple" and "NameDetailed".
> >The only other
> >element to consider is "NameVerbatim", which is neccesary if
> >you are going
> >to decouple "literal string of characters as appears in the concept
> >definition" from "name".  I get the sense from Jessie's recent
> >posts that
> >TCS assumes that "unique string of characters" *defines* "new
> >name".
>
> only if that unique string of characters was published in a
> taxonomic publication such as a monograph or as a result of a
> name change to satisfy one of the codes and therefore to be
> intended to be used by people in the future - not just any name
> string - I thought I made that quite clear.....

O.K., then let me ask this:  If someone defines a new concept in a way that
doesn't conform to the taxonomic publication/monograph/etc. as you scope it
in the quoted text above, and uses a name-string that is not identical to
the corresponding name (i.e., a misspelling), then where in TCS is the "Name
as spelled in this concept definition"?  I gather that NameSimple is
calculated from NameDetailed, and therfore does not store the "verbatim"
name as used in the concept definition.

> > If
> >that's true, and if the TCS schema is designed around that
> >premise, then it
> >is of limited use to nomenclators, and thus encourages the
> >nomenclators to
> >abandon TCS as a mechanism for exchanging name (sensu nomenclaturalist)
> >data.  I can't imagine a scenario where anyone benefits from such a
> >separation.
> >
>
> so does this still mean it is unsuitable for nomeclaturalists?

I don't know.  I think it may be "suitable" -- but not "optimal".  I think
we would all benefit if the schema approached optimality for both camps,
provided that the breadth of the user base is not impacted.  My point is, I
think we can get a bit closer to "optimal" for nomenclaturalist (and, I
believe, actually *increase* the optimality for concept users), without
causing harm to the user base.  In other words, I think we have the
potential for a win-win situation here, if we could only get past the
communication barriers.

> Funny I don't think of you as a nomenclaturalist, Rich, but it's
> your view on what nomenclaturalists need that we're getting
> rather than their view - would seem that email isn't getting the
> responses we hoped for.....

As I said several times, I am agruing against myself in several ways.  As I
also said, if I remained the only voice much longer, I would shift gears.
Driving in to work this morning, I've pretty-much decided that the time has
come to shift gears.

> can't see how the TCS approach would affect any future
> taxon-name-registration efforts - it might even encourage it!

It's not an issue of affecting it, as much as anticipating it.

Jessie later wrote:

> can't really see the benefits.....or difference from having a
> name objects separated out ....

These are some of the benefits I see:

- Nomenclaturalists have an unambiguous way to package the information
they're interested in (i.e., Nominal concepts)
- The same set of Name elements can be re-used and referenced by more than
one concept object, and hence, smaller data package size for datasets
involving multiple concepts attached to the same name
- Structurally-enforced consistency of name-data elements
- Minimal impact to overall TCS schema (relative to more radical,
hither-to-fore hypothetical, alternative approaches).
- Name-only data are automatically attached to a concept instance that best
represents what we can and cannot infer about the concept that went along
with the use of that name.

> >Also, you seem to share my view that name data should be
> >attached to Nominal
> >concept instances, rather than Original concept instances (as
> >Jessie seems
> >to favor).  Is this correct?
>
> no I'm not saying and didn't say that all name information goes
> in a nominal concept.

Sorry -- bad communication skills on my part. I know that you (Jessie) are
not saying this -- the text you quote above from me was in response to
Roger's email, and I was asking the question of Roger. When I said "as
Jessie seems to favor" in the quoted text above, I meant that you favor
treating the "Original" concepts as the name-data-bearers.

> So it depends on what you mean by name data
> - if you mean the bare string information required to display a
> name then fine but if you mean all the relationships too then I
> think I disagree.

As I tried to explain in earlier email, I think there are unambiguous cases
of relationships that involve two names (e.g., "Is basionym of", "Is type
species of", etc.), which are distinct from relationships that involve two
concepts (e.g., "Includes", "Is Congruent", etc.)  And I think it is a
mistake to blend these two kinds of relationships together in the same data
structure.

Aloha,
Rich