class: TaxonConcept

[nielsklazenga]

TaxonConcept (class)

Label	Taxon Concept
Definition	The underlying meaning, or referential extension, of a scientific name as stated by a particular author in a particular publication. It represents the author’s full-blown view of how the name reaches out to observed or unobserved objects in nature (beyond statements about type specimens). It is a direct reflection of what has been written, illustrated, and deposited by a taxonomist, regardless of his or her theoretical orientation (Franz & Peet 2009).
Comments

Mapping

TCS 1	DataSet/TaxonConcepts/TaxonConcept
TDWG Ontology	http://rs.tdwg.org/ontology/voc/TaxonConcept#TaxonConcept
Darwin Core	—

[nielsklazenga]

I have adopted the text from Franz & Peet (2009) for now, but I am not sure it was intended as a definition, as it is more a description of the relationship between a taxon concept and its name. For me, defining the taxon concept by reference to a taxon name is like putting the world upside-down, so I would prefer something like this:

An hypothesis, assertion or opinion about the delimitation of a taxon.

I had 'a taxonomic group of organisms' first, but I think we should just refer to the definition in Darwin Core to indicate that our usage of the term 'taxon' also includes groups that are not normally considered taxa, such as hybrids and cultivars.

Franz and Peet's (2009) text could still very well serve as a comment.

[nfranz]

It was intended as a definition (just to clarify that). To further clarify, it makes sense to center this definition around the relationship between a label/string and its referential extension as viewed by a certain author/source and at a given time, if the intent is not to use the term "Taxon". Which is not mentioned once in Franz & Peet (2009). I understand the contextual requirement for compatibility with DwC, however. In some sense, given that the 2009 article was not really meant to be all that compatible with DwC, there might be a case here for just omitting it; or say: for an alternative conception, see...

[jar398]

It is not obvious to me that the author's full blown view of a name is going to be an extension, or a single extension. (Similarly there will be extensions, such as those hypothesized algorithmically or those for "partly blown views", that are not any author's full blown view.) For example, the full blown view might be vague or ambiguous or incomplete or inconsistent, perhaps intentionally so. A view and an extension are very different kinds of things - they have different properties and identity criteria.

I could try to invent a definition that I like better but I'd insist on starting with use cases - those should be able to dictate any missing details of the particular sense that we would like to assign to this class name. Can someone offer high-quality examples where some particular thing (hypothesis, extension, text, etc.) would be a member of class:taxonConcept? Maybe there are some in TCS ...? It is always better to build a class up from examples than to think about it in a vacuum. The latter generally just leads to a lot of unproductive philosophizing and arguing.

I'm not disagreeing with @nfranz , I'm saying that there are easier ways to hone definitions than just talking about them abstractly.

[nielsklazenga]

@nfranz, what is the rationale behind trying to avoid the term "Taxon"? As that is where I would start and that has got nothing to do with Darwin Core.

[nfranz]

Thanks, @jar398. I may, or may not, be able to rescue "full blown" by reading it narrowly to just mean: all that one (someone else) can justifiably (according to mainstream systematic criteria for acceptable practice at the time) infer from that source about the concept's extension. Agree though, ok to move forward from that.

Examples: https://doi.org/10.1080/14772000.2013.806371

[nfranz]

@nielsklazenga It is one term that has two I think very important flavors or functional domains in biology, a more realist one (referring [however imperfectly] to natural, causally sustained phenomena) and a more constructivist one (modeling human data evolution); and, as often defined and applied in DwC, it can support both or kind of either in context, but as just one term it is not well suited to keep the two flavors apart consistently and explicitly, when and where that is needed. (And this is my vote not to continue this subthread further here; I am merely answering a question I was asked.)

[nielsklazenga]

@jar398 , not sure what sort of examples you are after, but the use cases @jgerbracht and @camwebb presented at the IG meeting in September might be a good start. I have plenty of examples too, but they are mosses and I think it is better to illustrate with examples of better-known organisms.

At Biodiversity_Next, Olaf Banki had a nice example of the African Elephant (I think that came originally from David Remsen). @jliljeblad spoke at that symposium as well, so may have some insect examples.

And @nfranz just posted an example.

[jar398]

I'm looking not just for pointers to documents but designation of particular entities either in or described in documents. The point is to be able to nail down identity criteria, use vs. mention questions, and other ontological fundamentals (so as to enable interoperability). Are we talking (in an example) about the text in an article, or the meaning of the text (that is different), or the extension of the meaning of some text? Or something else? If there are distinct taxon concepts with the same extension, what is an example of that? Having more examples is not necessarily better since different examples may indicate different answers to the general questions; that is why I think a small number of "best" or "canonical" examples (one might say: "type" examples) is better. They should be relevant to some existing project like eBird, not aspirational. OBO tries to include one or more examples with every class definition, and I think that is a good idea, but again, one has to be a bit careful here or else the text describing the example will be too ambiguous. (In particular, taxonomic names are ambiguous in multiple ways.) A use case may have to not just give data, but talk a bit about how it will be used, because without that there are likely to be ambiguities. - I agree that this shouldn't be difficult, I'm just not sure I'm the right person to be putting such things forward.

You say @nfranz posted an example but even in that careful article I can't quite tell whether the given 'taxon concepts' are meant to be extensions, or entities (perhaps bibliographic or conceptual) with associated extensions. Is it possible to have two distinct taxon concepts with the same extension? That's not answered. They have 'membership compositions' - that is useful information - but do they have anything else? Talking about the inferences that happens inside of real applications is going to hone these questions more than looking at prose like Nico's article. So when I say "example" I really mean, ideally, examples of digital data (like a row of a csv file) in its natural habitat (such as Euler/X or iNaturalist). Stuff of the sort that this ontology is targeting. Prose is not so helpful as an example source (unless the entity in question is textual), and if there is no inference (such as deduplication) it is hard to know what is intended. Again, this is not a matter of speculation. We should be able to look at what our applications do and figure it out from there.

[jar398]

In TCS 1 taxon concepts are definitely textual in nature - at least, I don't see how to read it otherwise, although it doesn't come out and say so. Evidence: a TaxonConcept can have only one taxon name. (by comparison, an extension might have many taxon names, if it has many descriptions/publications.) We could say that TaxonConcept is carried over as compatibly as possible from TCS 1 to TCS 2, but I think examples would still be in order, to clarify questions like this.

[nfranz]

Thanks, @jar398. I get that. I am not sure we have that on tap and ready to be deployed. A while ago I started more of a HowTo guide; but that is semi abandoned. Two sensible outs I see. (1) Decide that that is more implementation than TNC document specification and take a pass, either pragmatically or perhaps even more profoundly (see below). (2) Yes, do that work for an existing, sufficiently structured, relevant source. eBird would be great. Avibase might be easier. Both options (two phrases back) may have downsides.

The way I have preferred to implement this, to address your questions. I have looked for maximizing intensional congruence across concepts in separate treatments, wherever I could imagine sitting in front of an audience of skeptics and hold my ground well enough. My base challenge to myself has been: at what point can I no longer claim with a straight face that intensional congruence can somehow be rescued for any subset of the concepts being aligned? Inversely: I have looked for rather unassailable evidence, textual or contextual or otherwise, of non-congruence; and in absence of that given it the benefit of the doubt. So therefore I have asserted RCC-5 articulations for meanings, more so than texts. Extension has been mostly a synonym of meaning. Because there is now a kind of pay-off by saying: two separately published concepts are congruent ("same extension") - that is the supposedly helpful integration product being offered - yes of course two concepts can be distinct minimally in the sense of: two non-identical name sec. source labels; while having congruent extensions.

In the Perelleschus paper referenced above, 54 concepts are recognized. There are numerous instances of congruent extensions among these, hence there are far fewer instances of reciprocally non-congruent sets or clusters of concepts (if that makes sense). That is further explored here: https://doi.org/10.1371/journal.pone.0118247 (which has input data files for reasoning). Look for "Alignment 1 — Voss (1954) and Günther (1936)" to dig deeper.

Hard though for anyone, I suppose, not just me, to divorce this effort then from some related political aspirations. I'd rather be vague and allow different more specific implementations of a purposefully under-specified TNC document fight for however local and temporary functional adoption, than overly constrain future application through examples that might limit someone's freedoms to actually use RCC-5 productively. The experienced truth, I think, and way out of this maybe false choice, is to ask ourselves: ok, research communities in biodiversity are often quite shy with this RCC-5 business. How, minimally and through well chosen examples, can the TNC document serve to reduce that reluctance?

[nielsklazenga]

Yes, I think it is definitely the intention to carry over the TCS 1 TaxonConcept as compatibly as possible and I agree that we need a lot more than TCS 1 has, including examples of taxon concepts (and also examples of what are not taxon concepts).

The definition in the TCS user guide, by the way, is:

A Taxon Concept is a name plus a description of a taxon.

There is some good stuff in sect. 14.1.

[jar398]

@nfranz, I think there is enough current practice that (a) we don't have to be political and (b) there is little need for underspecification. I think that if you are dealing with an existing specification or platform that is underspecified, then that underspecification needs to be preserved. DwC seems to be like this. But that is not the case here. TCS 1 is pretty well specified (if I remember correctly - would need to review it), and the TCS 2 features that are not in TCS 1 are new so we can be totally prescriptive (subject to a desire for utility). - to repeat what I said before, underspecification is a recipe for non-interoperability, chaos, and errors. The political gains of underspecification are short term and rely on debts that always have to be paid off later. There are limits to how sharply anything can or should be specified but that's not what I'm talking about here.

Looks to me like 'Taxon concept' sensu TCS 1 should be preserved, possibly under a different name, and possibly a new, separate class 'extension' added - and conceivably a third one, for 'intension', as you might be suggesting - each with different identity criteria. I'm not sure where our discussion most recently ended on that. I think I had suggested using 'extension' informally in the documentation but not turning it into an ontology term but I'm not going to voice much of a position here. - but. again, the deciding factor here should be which things we need for data exchange, and that depends mostly on what kind of reasoning our various platforms and applications are doing (also on what we consider erroneous inputs, misuse, etc of the platforms), and that's an empirical question. If having two entities (rows, etc) with the same extension is the wrong way to use a given application, then those entities are probably intended to represent extensions, not taxon concepts. If it's right then they're taxon concepts or taxon intensions (which can be distinguished by the same method), etc. We can tell the difference by looking at how the application works and what input constraints have to be observed to get good results from it.

You'll probably have a chance to be politically aspirational in the TCS 2 documentation. Or maybe your aspirations are captured well by Euler/X and the ways it's used, and targeting Euler/X as a use case could ensure that they're represented.

I understand you've voiced a nuanced view above and maybe I'm not treating it with sufficient care, let me know if any of this helps

[nfranz]

Thanks, @jar398! I don't have much to add. Yes, for the paradigm case higher-level taxonomic concept alignment, say "the oak genus of the Chinese Flora" vs. "the oak genus of the Mexican Flora", my taxonomic instincts have pointed to: intensionally congruent; extensionally overlapping (some children being widespread). But not all data worthy of alignment offer that duality, that clearly. Sometimes, a single "congruent" is the most sensible, and will do good services that way. That said, I feel your comment is pointing in the right direction.