[tdwg-content] Taxon and Name [SEC=UNCLASSIFIED]

[Paul Murray]

> The problem with treating "name" as a distinct entity (independent of a
> particular usage of the name) is problematic, because there are several
> different interpretations of what a "name" is. Is it a simple text string?
> Or, is it a nomenclatural "object" with properties beyond the text string?

I believe that the position around these parts (which position I believe I have absorbed mainly by osmosis) is that a name is that thing comes into being with a nomenclatural act. Which I can't help picturing with the image of someone being knighted: "I dub thee Apus apus! Arise, Sir Taxon!". A text string refers to the abstract thing created by the act ... by the act that the writer of that text string *intended* it to refer. Of course, a number of things can go wrong at that point.

> Are all orthographic variants and misspellings different representations of
> the same "name" (object perspective);

Drat. Quite right - by what I have said above, orth vars refer to the same name as the correct spelling does. But the fact is that we have them in separate records with separate ids - what else can we do? Does this mean that our "name" records are not "name" records at all? Or that some are, some are not, and that some synonym types indicate not synonymy, but something different? Shall we distinguish between *taxonomic* synonymy (two names meaning the same taxon) and *foo* synonymy (two name strings meaning the same name)? "Nomenclatural synonymy" already means "two names having the same type specimen", so we can't call it that. But whatever we call it, it does seem that there's another layer of mapping. But what if the writer of a string had no specific idea they were using a homonym? Do we have "nominal name" as well as "nominal taxon"?

>> With respect to holding name parts, there seems to be no 
>> property in which to put - for instance - a subfamily name. 
> 
> The idea is that for a record representing the subfamily name itself, the
> text-string subfamily name goes in dwc:scientificName.

Thanks. Will do.

> I don't think I understand the difference in normalisation between records
> representing names, and records representing concepts.  They both seem
> equally denormalised to me.  Either the name *is* the object being
> described, or the name elements are labels for the element being described,
> but in both cases, the same amount of denormalisation seems to be happening.

For our data, a name record only contains elements that are part of the name. A record for a generic name will not contain a family name - the family that a genus is in is taxonomy. A taxon record has a name by way of a name id. In principle, it doesn't have any name strings in it at all. In practise, it contains data drawn from its name and from the names of its supertaxa. However, this data is not "primary" - it's a copy. 

I suppose ... In saying that a name record has its name parts "not denormalised", I am saying that the strings representing the parts of the name (including its author and year) are a key - the combination of those parts uniquely identify the name. A taxon has-a set of name parts, by virtue of it having a name and some supertaxa, whereas a name is-a particular combination of name parts. It seems I'm rather more wedded to this "a name is a set of part tuples" than I thought.

> I'm not sure I understand the value of a numeric surrogate for rank in DwC
> in place of (or in addition to) a controlled vocabulary for taxonRank.

I suppose what I was suggesting is that the semantic web (etc) needs another primitive datatype, alongside xs:string and xs:int, to represent a position in an abstract ordering. Dotted decimals - used in jar file manifests, for instance - fit the bill. It has even less chance of becoming a standard than my other bright idea: that "schema URI" and "element name" should be standard facets for the XML datatype, but I can dream.



------
If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. 



Please consider the environment before printing this email.

------