Open stevenchong opened 4 years ago
Sounds good. What's the most common pattern for term deprecation in ontologies? Since we haven't hit 1.0 on this ontology, maybe we don't need to be as careful about this and maybe we can just remove them and act like they were never minted. Should talk to @mpsaloha (when he's back in) and @mobb.
I would argue that once a URI is minted, it should never go away, but could be marked as deprecated so that people know not to use it, and what URI to use in its stead.
After some Googling, it looks like an annotation property is a common and recommended pattern to deprecate a term. https://www.w3.org/TR/owl2-syntax/ makes it look like you'd use an annotation property of owl:deprecated "true"^^xsd:boolean .
Another option I see is to move the term within the class hierarchy under a "Deprecated Terms" class which is annotated accordingly and would act like a term graveyard for deprecated terms.
Any preferences?
https://www.w3.org/TR/owl2-syntax/ makes it look like you'd use an annotation property of owl:deprecated "true"^^xsd:boolean .
The OBO Foundry ontologies follow this practice. We should also remove the relationships to other terms and add comments about possible replacement terms and a reason for obsoleting, as described for the Gene Ontology (last section): http://geneontology.org/docs/GO-term-elements
I like the idea of organizing deprecated terms under a single class.
Using owl:deprecated
sounds great, and adding other properties that link to replacement classes is also good. I would not be supportive of moving it to another class tree or removing relationships, as those would potentially break existing usages. In my mind, the goal should be that any document that references the existing class would still resolve with identical semantics after deprecation occurred. Classes should be treated a permanent and immutable as there will be references to them in annotations in many potential places.
Thanks @mbjones and @stevenchong. Re: @mbjones 's last, I think I also wouldn't want us to change any semantics by changing class relationships for deprecated terms if we can avoid it. That's different than what the Gene ontology suggests there.
For an example to see what this would like like, if we want to deprecate http://purl.dataone.org/odo/ECSO_#PAR
(above) in favor of a term with that follows our URI pattern, we could retail all properties (label, definition, creator, synonym, etc) and add an owl:sameAs
and owl:deprecated
.
I definitely wanna involve the rest of the group. Whatever we decide, I'd like it to get codified in the README in the ECSO folder so we and others know the plan.
@amoeba, in your example would the deprecated version of PAR still show up as a suggestion in a user's search? If it does, is there a way to display that a term has been obsoleted in the Bioportal widget?
Some ontologies (like ENVO), add the word "obsolete" to the beginning of a deprecated term's label: http://www.ontobee.org/ontology/ENVO?iri=http://purl.obolibrary.org/obo/ENVO_00000095 .
It looks like Ontobee shows deprecated terms in the hierarchy, but BioPortal does not... I can't find obsolete lava field
in BioPortal, even though the term is in the OWL file: http://bioportal.bioontology.org/ontologies/ENVO/?p=summary.
@amoeba, in your example would the deprecated version of PAR still show up as a suggestion in a user's search? If it does, is there a way to display that a term has been obsoleted in the Bioportal widget?
We have control over this, though it defaults to not including obsolete terms. So I think we're good here. I don't love the idea of encoding the semantics of deprecation in the label.
Post discussion with @mpsaloha and @stevenchong , the process that makes most sense is:
owl:deprecated
TRUE
term replaced by
NEW_TERM_ID
That sounds great. Thanks for adding the note here, @mobb. I'll update the docs so it's written down for later.
@amoeba - thanks. what doc are you updating? THBOMK, we have only a google doc of "ECSO practices" in the ADC drive. I tagged myself as the one to update that. Part of that would be If you have a markdown version already, I didn't find it. If you want to take that on, great.
I updated observation/README.md
, see https://github.com/DataONEorg/sem-prov-ontologies/commit/e9b7fedf0b1f222d24d04251c88e6e37c1b402cc. It'd be great to migrate info out of Drive since it effectively doesn't exist if it's in there. I can migrate stuff out if you share it with me.
ECSO:00000324 and ECSO:00000327 don't have any information associated with them, not even labels. I say these URIs should be deprecated.
There's also a handful of URIs that don't fit the standard ECSO URI naming pattern (http://purl.dataone.org/odo/ECSO_00000001):
http://purl.dataone.org/odo/ECSO_#KilogramPerMeterSquaredPerSecond http://purl.dataone.org/odo/ECSO_#Leaf_Area_Index http://purl.dataone.org/odo/ECSO_#PAR http://purl.dataone.org/odo/ECSO_#infrared http://purl.dataone.org/odo/ECSO_#ocean_surface http://purl.dataone.org/odo/ECSO_#ultraviolet http://purl.dataone.org/odo/ECSO_#http://purl.obolibrary.org/obo/ENVO_01000406
I think these terms should be deprecated and new URIs should be issued -- unless the concept is already present in another vocabulary, then we can just import it.