What are the terms in ECSO with the text "MOV" in them?

[amoeba]

I've seen these before and this question came up yesterday. A number of terms have the string "MOV" appended to their names. This looks like an error but maybe not?

[amoeba]

Example

[amoeba]

From @mpsaloha:

IIRC, that was an acronym designed to indicate that the term was specific to our work with the MsTMIP project with Deborah Huntzinger. Chris Jones might remember?

[amoeba]

Also from @mpsaloha:

ah-- I just recalled: MOV== “MsTMIP Output Variable” (pretty sure)

So I think we have an answer to the main question in this thread. I think there are two very related things to touch on.

First, @laijasmine 's initial comment that started this:

For that particular example there is a similar term: Depth of Thaw to the example Thaw Depth MOV might be confusing when we allow researchers to annotate their own attributes. It would be helpful to explain it

The issue here is that picking the "best" term for this is hard because we essentially have two terms that a scientist could get confused over:

Second, I think we agree that there are some inconsistencies across the ontology and that addressing them would be good improvements for a future release. Things like:

• Possibly duplicate terms (Active_Layer_Thickness_MOV vs. Depth of Thaw). See above.
• Inconsistent composition of labels ie ordering of Characteristics and Entity within the label
• Terms missing definitions (eg http://purl.dataone.org/odo/ECSO_00001253)
• Inconsistent formatting (eg mass_density_MeasurementType vs Air Pressure, both are measurement types)
• Weird terms at the root of the tree that seem like they should go elsewhere

---

None of the above changes are term deprecations, for which there's some standard guidance (see geneontology, OBO Foundry), but are either changes to term labels or class relationships.

• For classes that don't have a parent class for which we add one, I think we might be able to add a subclass property without much conflict due to the open world assumption? Still, it might be good to add an annotation property indicating the change, the reason, and from which version the change was made
• For changes to labels, I couldn't find anything official from geneontology/OBOFoundry but @mpsaloha mentioned we could add a sub-annotation-property on the annotation property we're changing of owl:deprecated. I don't know if this solves the confusion @laijasmine mentioned above because I don't know how user interfaces might behave when we mix deprecated and non-deprecated labels.
• There looks to be some candidates for obsoletion like http://purl.dataone.org/odo/ECSO_#KilogramPerMeterSquaredPerSecond since it doesn't follow our URI scheme and matches another term, http://purl.dataone.org/odo/ECSO_00001156. Should probably deprecate and sameAs.

Ultimately, I think a good bit of housekeeping is in order. We don't have the cycles right now but I thought I'd write this all up for if/when we do.

[amoeba]

We already have some related issues:

• https://github.com/DataONEorg/sem-prov-ontologies/issues/42
• https://github.com/DataONEorg/sem-prov-ontologies/issues/43