[tcs-lc] Names as Objects

[Richard Pyle]

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

Agreed (it's those pervasive semantic changes that lie at the heart of our
alternate perspectives).

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

I don't think it is that difficult to separate out (certainly much less
difficult to separate out than the question of which "potential" concepts
rise to the level of "defined" concepts) .  I've attached Nico's list with a
new column called "Applies To", in which I indicate whether I think the
relationship applies to Names, Concepts, or something else.  I did this very
quickly, so I may have made some errors.  A few of them I was not
comfortable about assigning in such haste, because I wasn't sure what they
meant.  Some of these are botanical, so I left those for someone more
familiar with ICBN to assign.  Others I just left blank because I didn't
know what they meant.  Others could go either way, depending on the specific
context (but would be unambiguous if given the context).  Ones I flagged as
"Determination" necessarily involve the identification of a specimen. For
the most part, they are of greater importance to concept definition than to
name objects; the main exceptions being Type, Holotype, Lectotype, Neotype,
Syntype, "primary type", and possibly some others that relate to botanical
typification.  Most of the others (Paratype, etc.) have no nomenclatural
standing (in Zoology), so are really concept-related issues.

I should point out that when I made these assignments, I was only looking at
the "Full" column and the "Definition" column.  Only after I assigned them
did I notice a pretty good correlation between Nico's
"Objective"/"Subjective" indicators and whether it was likely to be a
Concept or a Name assignment.

In doing this exercise, it became more clear to me what the fundamental
basis for our different perspectives seems to be for two of the major issues
we've been discussing. You tend to see a clear distinction between
"Identifications" and "Voucher assignments for Concept Definitions", whereas
in my mind, these are more or less the same thing that differ in degree,
rather than in kind.  But for the idea of "Relationships", we swap roles.  I
see a very clear difference between "Relationships between two names" and
"Relationships between two concepts", whereas the TCS structure lumps them
together in one place (Relationships element of TaxonConcept).

We've already discussed the Identifications/Voucher distinction, so let me
present my atomized view of the name/concept relationship distinction.

I see three kinds of relationships:

1) Between one Name object and another Name object
	Examples:
	Name "A" is the type species of the genus Name "B"
	Name "A" is a primary homonym of Name "B"
	Name "A" is the basionym for Name "B"
	Name "A" is a replacement name for Name "B"
	etc...

2) Between one Concept object and another Concept object
	Examples:
	Concept 1 includes Concept 2
	Concept 1 is congruent with Concept 2
	Concept 1 overlaps with Concept 2
	etc...

3) Between a Name object and a Concept object
	Examples:
	Concept 1 is the concept represented in the original description of Name
"A"
	Name-only Identification events
	Typification events

In the straw-man/Ytow-inspired alternate structure I sent, there would be a
"Relationships" substructure within the "TaxonNames" object structure --
except it would be closer to what is now within RelationshipAssertions part
of TCS (i.e., there would be an embedded "AccordingTo", but there would not
be a "FromTaxonName", as this would be the containing TaxonName instance
itself).  All of the relationships that fall into category 1 above would go
in that structure (within "TaxonNames").  All the stuff relating to category
2 above would go into the existing "Relationships" structure (within
TaxonConcepts).  I would still see a need for "Nominal" Concept instances
(which might even share the same GUID with the corresponding TaxonName
object ID).  My consistent use of the word "would" in this paragraph is
intended to emphasize that I am not (yet) advocating this "TaxonName as
distinct root-level object" approach for the schema -- but I think that
discussing it has helped me understand the alternative perspectives, and the
differences between them.

As for Category 3 -- some of those would be a function of the identification
event, and others might be either within Names, within Concepts, or both.

I think it really boils down to a "tail wagging the dog" sort of
perspective -- except I think in this case it's more like conjoined twin
dogs, joined at the butt, each wagging each other. (Sorry about the visual
imagery that comment no-doubt conjured...)  In other words, I think we both
have a legitimate perspective; one name-centric, and the other
concept-centric.  And I am of growing confidence that either approach will
satisfy both sets of needs.  But the distinction in terms of data structure
is nevertheless fundamental, and we will (soon) need to commit to one
approach or the other.

To summarize the above lumper/splitter perspective:

TCS is a splitter and I am a lumper when it comes to deciding what is, or is
not, something that could be considered as a "concept" (vs. an
"Identification").

TCS is a lumper and I am a splitter when it comes to distinguishing, or not
distinguishing, the difference between relationships among name objects, and
relationships among concept objects.

Is that a fair characterization?

> >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 believe either approach will be able to serve the needs of an equally wide
audience.  The main question is really more about the value of modularizing
names data as distinct from concept data, vs. acknowledging/embracing the
inevitable and unavoidable entanglement between the two. To be honest, both
philosophies appeal to me.  Taxonomer embraces the latter (the TCS
approach), but I nevertheless tend to favor the former in terms of a
standard data schema (but my opinions are shifting as a result of this
conversation).

> Note:
>   <TaxonNames>
>     [Full-blown Name data, with references to publications and
> type specimen vouchers]
>   </TaxonNames>
>
> is *very* much simplified - so don't be fooled.......

Agreed!!! But I'm taking this in baby-steps.  There already exists a
detailed TCS schema.  The draft LC schema was not necessarily constructed
with this perspective in mind, so can't really be used in this context.

>   <TaxonConcepts>
>     [Full-blown Concept data, with references to publications,
> descriptions  and specimen vouchers]
>   </TaxonNames>
>
> which looks equally simple ;-)

Agreed!  It wasn't my intent to try to make it look "simple". I was just
trying to be unambiguous about representing a "Name object" as a top-level
element, rather than a property of Concepts.

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

Agreed -- it could be represented that way.  I'm just not sure it's optimal
(in the grand scheme of things) to represent it that way.  Incidentally,
if/when I finally abandon my "crusade" (which I will do sooner, rather than
later, if I remain the only vocal advocate....ahem....), I will shift my
focus to trying to convince you why Nominal concepts should contain the
name-only data (with an embedded pointer to an Original concept)...but let's
first see where this "thought experiment" leads us.

> 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

Not exactly.  Within the Concept object there would be an element something
along the lines of "NameVerbatim" -- which would be the literal string as
used in the Concept definition.  The reference back to the name object would
be to the basionym/protonym (if zoological perspective prevails), or to the
"Combination" (inclusive of basionyms/protonyms; if the botanical
perspective prevails).  So, the literal text string used in the concept will
always remain with the concept.  There might also be a "NameSimple" that is
an algorithmic concatenation of the NameObject -- which may be different
from the "NameVerbatim" element (NameVerbatim would be "name as actually
represented", and "NameSimple" would be "name as it should have been
represented, according to nomenclatural correctness").

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

The only real duplication would be the duplication that already exists in
TCS as "NameSimple".

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

Wouldn't it default to the Nominal Concept equivalent?  Also, this depends
on whether people access the name directly, or always through its Nominal
Concept equivalent.  If they share the same GUID (and I believe there is a
logical case to be made for why they should), then it may not be an issue.

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

Reduction of ambiguity is in the eye of the beholder... :-)

Both approaches seek to reduce redundant duplication of effort, so I don't
think you can claim that for the TCS perspective.

> >On a sort of related question, would it be worth considering
> >an "<Agents>"
> >top-level element & simple schema?
>
> 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.

O.K., just asking.  I think if it were treated as "AgentName" rather than
"Agent", a lot of the complexity disappears...but nevertheless, perhaps this
should await a later version.  Lord knows we have enough to discuss as it
is, without adding more stuff!

Aloha,
Rich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TCSCodePrescribedRelationships2.xls
Type: application/vnd.ms-excel
Size: 85504 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050304/96803363/TCSCodePrescribedRelationships2.xls