-
Notifications
You must be signed in to change notification settings - Fork 34
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
Comments
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. |
This is the first and only time I've done it. Lines 104 to 109 in b61fe31
That was tracked through the following issues/pull requests |
@graybeal here's another example Lines 42 to 47 in 025c2f7
|
Use of |
@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. |
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. |
I like this Chuck. |
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. |
On further discussion for #223 @dr-shorthair @pbuttigieg @brandonnodnarb and @rduerr decided |
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:
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.
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'.
The text was updated successfully, but these errors were encountered: