[tcs-lc] Comments on Draft TCS for TDWG voting

[Richard Pyle]

The following comments pertain to specific issues in the content of this
Wiki page:
http://www.soc.napier.ac.uk/tdwg/index.php?pagename=VotingDraftIntroduction

Overall, I found this to be a good overview of the current situation with
TCS/LC.  But I do have a number of comments:

> The prime example being TaxonConcept – we meant by this a
> name+definition. Many people refused to accept this and
> continually interpreted it TaxonConcept to be their understanding
> of concept which is TCS understanding of definition.
>
> For example, nomenclaturalists, a particular type of user of
> taxonomic names decided TCS didn’t meet their needs because the
> Name element, which is the primary entity in their perspective
> was not a complex entity that allowed them to represent all
> information about names they saw as being important.

If TCS defines a TaxonConcept as "name+definition", then nomenclaturalists
(or more generally, issues related to nomenclature) can't really be
characterized as "a particular type of user" -- when nomenclature comprises
50% of the "essence" of a TCS "TaxonConcept".  It would be like
characterizing "people who invoke taxon concepts" as just another
"particular type of user".  Indeed, "people who invoke taxon concepts" *are*
the general user base, and if TCS defines "TaxonConcept" as
"name+definition", then the issues of nomenclature are much more fundamental
to TCS than simply relevant to the needs of "a particular type of user".

> They interpreted the Name element to be the only way to store
> information about names.

I think it would be fairer to re-word this as:

"They interpreted the Name element to be a more efficient way to store
information about names."

> Nomenclaturalists want to model the basic Name representation
> (similar in principal to the ABCD Name element although this
> could be modelled differently), the relationships between names,
> the type specimens for names and the publication in which the
> name was published. We believe the elements to do this are already
> in the TaxonConcept. The terminology used in TCS might not be
> equivalent to theirs, however there is no agreed terminology for
> the entities and attributes being modelled within the
> Nomenclaturalists never mind across data modellers of taxonomic
> information.

Of course, the problem is not simply one of terminology.  The terminology is
certainly an unfortunate encumberance to communication -- but our recent
discussions have moved beyond this, I think.  The real issues that we need
to resolve (soon), I believe, are the "big picture" ones.

> Additionally the modelling style adopted by TCS could be
> different. For example, references to between names or concepts
> can be modelled as attributes or relationships of a particular
> type – there are pros and cons of both mainly computational.
> If a conceptual model has several a 1:1 relationships (has_x,
> has_y, has_z) between two entities (A, B), of the same kind.
> Then this can be modelled either by giving the entity the attributes
> has_x, has_y, has_z into which identifiers for the related
> entity can be entered or by having a separate relationships table
> containing the identifiers for the 2 entities and a
> relationship_type attribute specifying if the relationship is
> of type has_x, has_y or has_z. This is purely a modelling decision
> and nothing to do with whether or not the information can be
> represented. If the domain is well understood, there is agreement
> on what attributes are required for an entity and the majority
> of entities have all of the relationships then the former approach
> is reasonable. However, when the entities in the domain are variable
> in constitution for whatever reason and it is difficult to ensure
> all relationship type are modelled explicitly then the latter approach
> is more flexible i.e. it is more of a generalist approach and is that
> take bye the TCS. It is easier to change the possible values for an
> attribute that change the schema.

This paragraph, I believe, captures the real heart (nitty-gritty) of what we
need to focus on, and where, ultimately, the fundamental dispute lies.

> If we model the schema to suit the nomenclaturalists then it will be
> biased to their view of the world and won’t necessarily suit other
> users. Therefore, we would need name/concept schemas for ecologists,
> taxonomists (working primarily on specimens who see their specimens
> as the primary definition), taxonomists (who relate existing taxa to
> each other and focus on characters without much attention to the
> specimens actually used), list providers, museum curators etc. We
> would then have the problem of mapping between these schemas and
> the potential problem of some users not being able to develop their
> data resources until other users had developed their databases.

I don't think the above is either true, or fair.  As discussed above, TCS
defines a "TaxonConcept" as Name+Definition.  There are all sorts of complex
elements that are well-suited to capture/represent the "Definition" half of
that equation (which I interpret as the circumscription part -- right?).
The so-called "nomenclaturalists" are simply saying that a similarly robust
set of elements are needed to capture the "Name" part of that equation.

Personally, I think TCS should have defined a TaxonConcept as simply the
"Definition" part (which I think it accomodates very elegantly). "Name"
should be a referenced attribute of a TaxonConcept instance, in the same way
that Publications, Vouchers, and Characters are referenced.  One way to
structure this would be to treat "Names" like these other top-level objects,
and represent them as such in the schema (i.e., outside of TaxonConcept).
I'm not (yet) of that belief, because I think Names and Concept
circumscriptions are tightly linked to each other, more-so than Concepts are
to Publications, vouchers, or characters.  But I also think it's a mistake
to entangle concept-concept and name-name Relationships in the exact same
structure.

> So the question is
 was the primary aim of TCS wrong?

I don't think so, no.

> Should we forgo a common framework and define types for
> all of the different users?

No -- we should instead recognize that if we are going to define a TCS
TaxonConcept as "name+definition", then we should:

1) Not confound the equation by creating a structure that, in some ways,
represents "name~=definition";

2) Put as much care and thought into accounting for the first half of the
equation, as has been put into the second half; and

3) Not mis-characterize the needs of "nomenclaturalists" as "a particular
type of user of taxonomic names", when, in fact, a "Name" represents 50% of
the "essence" of a TaxonConcept instance.

> Instead of trying to capture all of the data with the elements
> provided, the discussion has come down to what the names of the
> elements mean and whether or not they agree with the codes.

I'm not sure I would agree with this statement, but the points that I have
been hammering on have been "big-picture" points.  One of those "big
picture" points is what the word "name" means when you say
"name+definition". I have not seen it explicitly stated anywhere, but I
infer from the various discussions and sample instance documents that it
effectively means "string of characters as used to refer to a concept
definition".  If you want to scope it that way, that's fine -- but in that
case you need only one element: "NameString".  If you are going to elaborate
any more name-structure than that (as I suspect you would, given that a
"name" represents half of a TaxonConcept), then it really only makes sense
to do so in the context of actual scientific nomenclature.

> The decision between separate schemas or one general schema
> must be decided before agreement can be reached on what the
> schema will look like otherwise the confusions in what it
> is supposed to represent will cloud any discussions trying
> to reach agreement.

My vote would be to have one generalized *taxon concept* schema, which can
be used by anyone who captures information involving taxonomic concept
circumscriptions (rather than multiple discipline-specific schemas).

If the consensus falls in this direction (and my hunch is that it will),
then the next fundamental question is:

"If a TaxonConcept is defined as 'name+definition', then what is meant by
the 'name' part?"

I am assuming that the "definition" part means the taxonomic
circumscription -- which is accomodated very well via the "Relationships" to
other concepts, plus references to vouchers, plus references to characters.

I tried to ask this question on the TCS/LC list, and it almost seemed like
we were approaching on consensus -- but then again, I think we only heard
from the "nomenclaturalists".

I will try to find some time this weekend to look more closely at v0.95, and
try (once again) to explain how I think that only minor modifications to the
existing TCS structure, plus some fundamental understandings about
type-specific "Relationships", will achieve the goal of TCS: "to develop a
schema that dealt with taxonomic names and concepts".  Right now, I think it
deals with taxonomic concepts superbly.  I think it just needs to be a
little more robust for dealing with taxonomic names.

'nuff for now...

Aloha,
Rich

Richard L. Pyle, PhD
Database Coordinator for Natural Sciences
Department of Natural Sciences, Bishop Museum
1525 Bernice St., Honolulu, HI 96817
Ph: (808)848-4115, Fax: (808)847-8252
email: deepreef at bishopmuseum.org
http://www.bishopmuseum.org/bishop/HBS/pylerichard.html