Change term - move typeStatus from Identification to MaterialEntity

[nielsklazenga]

Term change

• Submitter: Niels Klazenga
• Efficacy Justification (why is this change necessary?): The placement of typeStatus in the Identification class is problematic, as discussed in #28 , but until now there was no better place to put it. The new MaterialEntity class, however, is a very good fit.
• Demand Justification (if the change is semantic in nature, name at least two organizations that independently need this term): N/A
• Stability Justification (what concerns are there that this might affect existing implementations?): N/A
• Implications for dwciri: namespace (does this change affect a dwciri term version)?: N/A

Current Term definition: https://dwc.tdwg.org/list/#dwc_typeStatus

Proposed attributes of the new term version (Please put actual changes to be implemented in bold and ~strikethrough~):

• Term name (in lowerCamelCase for properties, UpperCamelCase for classes): typeStatus
• Term label (English, not normative): Type Status
• Organized in Class (e.g., Occurrence, Event, Location, Taxon): Identification MaterialEntity
• Definition of the term (normative): A list (concatenated and separated) of nomenclatural types (type status, typified scientific name, publication) applied to the subject.

[tucotuco]

@nielsklazenga Would you also go so far as to change the definition to be explicit? "A list (concatenated and separated) of nomenclatural types (type status, typified scientific name, publication) applied to the dwc:MaterialEntity"?

[nielsklazenga]

@tucotuco , yes, that makes sense. However, if we are going to change the definition, I would make another small change:

A list (concatenated and separated) of nomenclatural types (at a minimum type status, of type and typified scientific name, publication) applied to the dwc:MaterialEntity.

I think we should leave the publication out of the definition, as nine out of ten times it is the same as the namePublishedIn publication and also in the case of lectotypes, neotypes, epitypes and conserved types, where it is different, it would normally not be provided in the typeStatus string. I would consider it metadata of the Nomenclatural Type, rather than really part of it. The publication I cite in my type status annotations on the specimen is the publication of the name.

Also, while we are at it, in the examples holotype of Pinus abies should be changed to holotype of Pinus abies L. and holotype of Picea abies should be deleted as Picea abies (L.) H.Karst. is a combination of Pinus abies L. The other one I would change to holotype of Ctenomys sociabilis Pearson & Christie, 1985. Pearson O. P., and M. I. Christie. 1985. Historia Natural, 5(37):388, but I am not a zoologist, so do not take my word for it.

[tucotuco]

There are other implications to think of going forward. It make me a bit nervous that a generic physical object should have a type status attribute. It seems too much of a specialized characteristic. Is that a characteristic inherent in the material? Or is it a designation applied to a piece of material following some process. The latter makes for a better model, I think, and allows the process to be repeated for additional type designations. None of that is inherent in the material, and it is much more problematic to model as if it were. As we seek to build a semantic layer for Darwin Core, the semantics will be crucial.

[nielsklazenga]

There was a reason I did not start tinkering with the definition immediately. Yes, it is a bit counterintuitive. In a nomenclatural type designation, the Name is the subject and the Specimen is the object. So, if things were simple and we did not want to hang more information off this relation, we could just have a isNomenclaturalTypeOf property on the dwc:MaterialEntity and a hasNomenclaturalType property on the tcs:TaxonName.

We have defined (or propose to define) a tcs:NomenclaturalType in TCS (see tcs:NomenclaturalType. dwciri:typeStatus is the inverse of the tcs:typeSpecimen.

The NomenclaturalType (or 'type status') is of course just a special case of a dwc:ResourceRelationship, where – coming from dwc:MaterialEntity – dwc:resourceID is the ID of the dwc:MaterialEntity, dwc:relatedResourceID the ID of the tcs:TaxonName and the value of tcs:relationshipOfResource is isHolotypeOf, isIsotypeOf, isSyntypeOf, etc.

So, people who are concerned about models would not use dwc:typeStatus at all, but would use dwc:ResourceRelationship. I do not think a proposal to sink dwc:typeStatus into dwc:materialEntityRemarks would go very far (I do not even support it myself), but a dwc:materialEntityRemarks is all that it really is (in this form).