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

[FEATURE] deprecation policy/practice for SWEET #192

Open
graybeal opened this issue May 4, 2020 · 10 comments
Open

[FEATURE] deprecation policy/practice for SWEET #192

graybeal opened this issue May 4, 2020 · 10 comments
Labels
Cryosphere Issues related to cryospheric terminology documentation enhancement governance

Comments

@graybeal
Copy link
Collaborator

graybeal commented May 4, 2020

Per the comment in #190 (comment), 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
Copy link
Collaborator

rrovetto commented May 4, 2020

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.

@rduerr rduerr added Cryosphere Issues related to cryospheric terminology documentation governance labels May 20, 2020
@lewismc
Copy link
Member

lewismc commented May 29, 2020

@graybeal @rrovetto

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

sweet/src/matrMineral.ttl

Lines 104 to 109 in b61fe31

### http://sweetontology.net/matrMineral/Pyroxine
somamin:Pyroxine rdf:type owl:Class ;
rdfs:subClassOf somamin:Mineral ;
rdfs:label "pyroxine"@en ;
owl:deprecated "true"^^xsd:boolean ;
rdfs:seeAlso somamin:Pyroxene .

That was tracked through the following issues/pull requests

@lewismc
Copy link
Member

lewismc commented Jul 17, 2020

@graybeal here's another example

sweet/src/phenCryo.ttl

Lines 42 to 47 in 025c2f7

### http://sweetontology.net/phenCryo/Englacial
sophcr:Englacial rdf:type owl:Class ;
owl:equivalentClass sophcr:EnglacialProcess ;
rdfs:label "englacial"@en ;
rdfs:comment "This class is deprecated in favor of the URI EnglacialProcess"@en ;
owl:deprecated "true"^^xsd:boolean .

@lewismc
Copy link
Member

lewismc commented Jul 17, 2020

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 rduerr closed this as completed Jul 27, 2020
@rduerr rduerr reopened this Jul 27, 2020
@rduerr
Copy link
Contributor

rduerr commented Jul 27, 2020

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

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

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

lewismc commented Jul 27, 2020

I like this Chuck.

@pbuttigieg
Copy link
Collaborator

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Cryosphere Issues related to cryospheric terminology documentation enhancement governance
Projects
None yet
Development

No branches or pull requests

7 participants