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

[Kennedy, Jessie]

Hi Rich

thanks for your comments - which have just confirmed to me that it is just about impossible to talk about any of this clearly and ensure that what is written will be interpreted the way it was meant.....this is no doubt as much my inability to communicate what I mean succinctly and clearly as it is yours to interpret what is written without adding more to it....

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

no offence to nomenclaturalists meant if any was taken.... I'm just saying that they don't necessarily have the same priorities as taxonomists undertaking monographs and revisions, nor will they have the same priorities as biologists wanting to identify organisms in a meaningful way, or biologsits trying to decide if two records recorded in different coutnries or at differnt times refer to the same taxon. The different perspectives are equally important.
>
>> 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."
>

maybe now after months of discussion.... but at first I was informed that it was because they didn't think they could represent all they needed to be able to with the Name element and were going to suggest a new Name element to be inserted.

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

really? If that's the case then I would say is an issue for the computing people who are going to implement the solutions for the biologists.....because it really is an implementation issue. 
Tools could be designed to let different user groups see the data the way they want.
What I think was intended by the schema is that people will continue to use their own systems with their preferred terminology and tools and will only use the schema for transferring data between systems.

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

right and wrong ;-)
the definition for a TaxonConcept (or Taxon as Roger is suggesting) could also include or be the rationale for the existence of the name that a nomenclator is interested in. 
 
>The so-called "nomenclaturalists" are simply saying that a 
>similarly robust
>set of elements are needed to capture the "Name" part of that equation.

you have them - if you consider name as a TaxonConcept

>
>Personally, I think TCS should have defined a TaxonConcept as 
>simply the
>"Definition" part (which I think it accommodates very elegantly).

I disagree when you take on board the perspective of someone (a normal biologsit) trying to use the output from taxonomists and nomenclators (is there a difference between nomenclators and nomenclaturalists?? sorry I keep interchanging them). They use a name to mean something they don't go around citing definitions in their survey data and citing names isn't meaningful enough for later interpretation by others.

> "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, 

so why did you just say you think TCS should only have dealt with the definition. And anyway when we started TCS there was nothing else - apart form Walter's Name element in ABCD which we took on board. I'm not really sure what you're saying now....

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

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

good

>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";
>

depends on your definition of name......
which does vary from person to person......

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

I think ABCD did a lot of work that we took on board and LC have added a lot more useful work and re-structured the Name element - which we have taken on board. The only thing is we're saying the "definitional part of a name can be captured within the TaxonConcept part.

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

I think this is an unhelpful comment - we're not trying to mis-characterize anyone - but it is very easy to be thought of as doing that - diplomacy is clearl not one of my best skills.....
>
>> 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?"

agree and I hoped we could keep it to the parts that we need to represent any name, with any rationale being kept to the definitional bits - i.e. the relationships, links to specimens and publications etc.
So more than a string but not links to other elements.
>
>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.
>
so is the information you want to capture about names, e.g. type specimen, relationships to other names, where the name was published etc. 

Jessie

This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the 
University's system is subject to routine monitoring and filtering by the University.