[FEATURE] deprecation policy/practice for SWEET

[graybeal]

Per the comment in https://github.com/ESIPFed/sweet/pull/190#discussion_r418722921, I want to suggest formalizing the deprecation policy/practice for SWEET.

I'd like to propose adopting the OBO policy Charles cites:

OBO foundry has a procedure (http://www.obofoundry.org/principles/checks/fp_003)

The last three in the list below (just copying from his list, don't have time to do the complete research at this moment) are appropriate only if there is a new term. If the term is being obsoleted, or is already covered by another term, somewhat different steps are called for, and can be developed now or then.

• Add an owl:deprecated annotation with a boolean value of true to the problematic term
• Add obsolete to the beginning of the term’s label to prevent duplicating labels
• Create a new term with a valid IRI to replace this old term
• Copy the old annotations (label, definition, etc., excluding the owl:deprecated) over to the new term
• Add a IAO:0100001 (term replaced by) annotation to the old term with a value of the new term’s IRI

We don't need to have our own annotation property to replace IAO:0100001, we can use that one. If someone feels strongly the need for a different one or one of own, it should clearly have the same meaning as 'term replaced by'.

[rrovetto]

Recommend using our own term to avoid potentially being forced to use any ontologies (or other terms) that iao imports or uses. We can alternatively using a more neutral term from elsewhere (w3c, dubclin core, etc.). In any case, declaring equivalences is often done and is not problematic. For our own, I propose using an annotation such as: 'is replaced by'. For a more specialized annotations: 'class is replaced by', 'relation is replaced by', etc.

[lewismc]

@graybeal @rrovetto

This is the first and only time I've done it.

https://github.com/ESIPFed/sweet/blob/b61fe3183444fded13aad7251ecc77abf11b4bfb/src/matrMineral.ttl#L104-L109

That was tracked through the following issues/pull requests

[lewismc]

@graybeal here's another example https://github.com/ESIPFed/sweet/blob/025c2f722938e639fbac9e02a8c21f24de957b12/src/phenCryo.ttl#L42-L47

[lewismc]

Use of owl:deprecated is consistent. Use of rdfs:seeAlso and rdfs:comment is inconsistent. I think that this issue should be brought to the Semantic Harmonization group to decide on standardizing the approach and documenting it in the wiki. This is a trivial piece of work to implement but important non-the-less.

[rduerr]

@rrovetto Have you looked at IAO:0100001. I would like to find out what other ontologies are implicated with the use of this term. I really hate the idea of multiple terms with the same meaning as it just leads to more confusion, so want to know what the exact issues are with that annotation.

[rrovetto]

@rrovetto Have you looked at IAO:0100001. I would like to find out what other ontologies are implicated with the use of this term. I really hate the idea of multiple terms with the same meaning as it just leads to more confusion, so want to know what the exact issues are with that annotation.

That ontology makes commitments to other resources that we should not assume or impose on SWEET. It would be a short order to make a neutral set of metadata elements for SWEET, by SWEET.

[charlesvardeman]

So we already use the dcterms prefix. How about using dcterms:isReplacedBy to point to the new term and inverse property dcterms:replaces for new terms? We should probably also require a skos:changeNote with documentation on why the term was replaced. In general, now that skos is becoming a deeper part of the SWEET infrastructure, we should probably consider using the skos note terms (historyNote, editorialNote, etc) to document the harmonization and evolution of SWEET terms.

[lewismc]

I like this Chuck.

[pbuttigieg]

I suppose the IAO term is more specific to ontologies, but I don't think the dcterms:isReplacedBy is really substantively different when it points from a term, to a term, in an ontology-like resource. I'd go for the latter as it has broader interoperability.

[brandonnodnarb]

On further discussion for #223 @dr-shorthair @pbuttigieg @brandonnodnarb and @rduerr decided dcterms:replaces is not needed.