Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change term - move typeStatus from Identification to MaterialEntity #525

Open
nielsklazenga opened this issue Sep 23, 2024 · 4 comments
Open

Comments

@nielsklazenga
Copy link
Member

nielsklazenga commented Sep 23, 2024

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 New term - typifiedName #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
Copy link
Member

@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
Copy link
Member Author

@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
Copy link
Member

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
Copy link
Member Author

nielsklazenga commented Sep 24, 2024

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:MaterialEntitydwc: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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants