deepreef
commented
5 years ago Ha! Maybe your initial reaction was the correct one? :-) Seriously, though -- that's not exactly how I would phrase it. We can think of a "Taxonomic Name" as either a literal text string (sequence of UTF-8 encoded characters), or we can think of it as a "data object" (class) with properties. We've pretty-much worked the literal string angle to death. The problem comes when people try to use the literal text string as a proxy for the data object. That's when we get into problems -- for a number of key issues (which I can elaborate on if needed). What I think your referring to is my assertion that a subset of all TNUs are what I call "Protonyms" (i.e., TNUs that happen to also establish new Taxonomic Names), and that these Protonyms (subclass of TNUs) serve is extremely powerful proxies for Taxonomic Names as "data objects". In other words, Protonyms represent an elegant way of building links between and among other TNUs in ways that allow us to magical informatic tricks (inferences). Over several decades of working with real data (through ZooBank and far beyond), I've concluded that all of the properties and inferences about nomenclature and taxonomy can be represented through TNUs, their core properties, and their relationships to each other. The two most important properties of a TNU are the literal text-string for the name-label (only the uninomial component, as literal text strings representing combinations are derived from sets of related TNUs), and the link to a Reference. The three most important relationships between TNUs are the link to the Protonym (self-referential for TNUs that are themselves Protonyms), the link to the Valid TNU (self-referential for names treated as valid/accepted), and the link to the Parent TNU (e.g., a species TNU linked to a parent TNU). Implicit in all three kinds of TNU-TNU relationships are that all are connctions between TNUs anchored to the same reference. These five components (two properties and three intra-Reference TNU-TNU relationships) form the kernel around which almost everything we do or care about in taxonomy and nomenclature can either be directly inferred, or captured in additional layers that cross-link inter-reference TNUs to each other. As David Remsen has described it, TNUs are the root "currency" of taxonomic information.
More generally, think about it this way: Taxon names and taxon concepts do not exist by themselves -- they only exist through the existence of individual usages. A name does not exist until some one establishes it (Protonym). Synonymies and classifications do not exist until someone asserts them. Almost everything we do nomenclaturally (typification, emendation, etc.) or taxonomically (synonymies, classifications, circumscription definitions, etc.) all happen through References, and thus TNUs.
This is why I see one class of taxonomic entities (TNUs). ANYTHING nomenclatural or taxonomic can be anchored to a TNU, and thus TNUs can serve as proxies for noemclatural actions and taxonomic circumscription assertions. Therefore, we really need only one class of object, and one set of properties and defined relationships, to track almost everything we're interested in.
My only suggestion would be to replace the term "primary taxonomic name usage" with "Protonym", and then I think we're in a really good place.
I do need to clarify something, however... dwc:scientificname refers to a literal text string (full combination), and so the associated dwc:scientificNameID is NOT the same thing as a Protonym (or "primary taxonomic name usage"). The dwc term that represents the Protonym is dwc:originalNameUsageID. In fact, all the terms we need for representing and mapping TNUs is already included in dwc (Taxon class). I will illustrate this when I put my examples together.
nielsklazenga
mdoering
In the discussion around the Darwin Core RDF Guide that @baskaufs summarised, @deepreef stated that a Taxonomic Name is a special form of a Taxonomic Name Usage (using slightly different terms). At the time I read this (only a few months ago) my first thought was 'Oh, rubbish!', but with all the discussions we have had in the TNC in the last six month, I have slowly moved to @deepreef's position.
We have had difficulty deciding which property goes in which class (or I have, as we haven't had any strong disagreements) and there is the outstanding issue of defining the classes and deciding where one class ends and the other begins.
I think (at the moment...) that we can do with one class what we can do with the two classes, by adding a 'primary taxonomic name usage' property (cf. #32), which would then replace the
taxonomicNameproperty (and be equivalent withdwc:scientificNameID). I think we could even keep calling the propertytaxonomicName.