obsolescence reason specification

[Melanie Courtot]

Hi,

We currently have curation status specification instances defined in
the ontology-metadata file (http://purl.obofoundry.org/obo/iao/ontology-metadata.owl
)
I would like to suggest having similarly "obsolescence reason
specification" (name coined by Alan ;) ), which instances would
enumerate reasons for deprecation.

An initial list of those instances could be (non exhaustive list based
on OBI experience)
- placeholder removed (would cover examples, tests...)
- term merged (an editor note would describe what were the merged
terms and why they have been merged)
- term imported (an editor note would indicated what is the URI of the
new class to use)
- term split (an editor note would indicate what new terms have been
created and reason for split)

Other ones could be added later on as well (cf Werner's paper at http://www.ncbi.nlm.nih.gov/pubmed/19162233?dopt=Abstract)

Immediate advantages would be:
- we could use those in OBI to create a Protege plugin, easing
curators' work and increasing homogeneity of the annotations
- we haven't been very good until now in OBI to record reason for
deprecation of our terms, and having an easy way to do so by selecting
a value in a list would probably help us

Any objection/suggestion/comment?

Melanie

---
Mélanie Courtot
TFL- BCCRC
675 West 10th Avenue
Vancouver, BC
V5Z 1L3, Canada

[Dirk Derom]

Would this also means that one is able to add/view a timestamp and a comment field? If not, I would add these since they allow to trace the terms and get more detailed information (when available).

Do these deprecated terms include renamed terms (e.g. say when data would be changed into data item)? If so, I would add 'term renamed'. If not, I would include these terms, with the possible risk of having a lengthy list. At the same time it allows for tracing back the history and reasons for renaming a term.
I would also add 'Other' or anything alike which can be further explained in the comment field.
Does this make sense?

Does this also mean that the 'history' of the ontology is stored within the ontology itself? Or will there be external docs explaining why and when terms changed? I'd prefer within the ontology.
My guess is that at a certain time when more people get involved, some terms/definitions will be questioned. You would want to avoid starting the discussions all over again, hence a short report of the history and reasons for the defintions/terms might be a good idea. Not sure whether this is an option, since it puts an additional load to the curation of the ontology.

2009/3/3 Melanie Courtot <mcou...@gmail.com>

--
Kind regards,
Dirk Derom.

--------------------------------------------------------
Check one of the following websites:
-> Neuroinformatics: http://www.metaneva.org/
-> My Favorite artist (strongly biased):
http://sarahverroken.com/
http://sarahverroken.blogspot.com/
-> Art Project: http://www.zanchyn.net

[Trish Whetzel]

You might want to review the Deprecation Policy developed for the MGED Ontology (MO), https://www.cbil.upenn.edu/magewiki/index.php/TermDeprecationPolicy. Gilberto Fragoso, from NCI and a developer of MO, provided a lot of input into the policy. For MO, these changes were done without the help of a plugin, but one certainly would be useful for an ontology that is still undergoing many changes. There may also be some Protege code available that can be used as-is or as a framework depending on what the final policy is.

Cheers,
Trish

Trish Whetzel, PhD

Outreach Coordinator

The National Center for Biomedical Ontology

Ph: 650-721-2378

whe...@stanford.edu

http://www.bioontology.org

[Bjoern Peters]

I think that would be very useful, and would also add:
'other, see editor note'
to allow for free text descriptions in editor notes, which can be mined
over time to add to the list of controlled 'obsolescence reason
specifications'.

[Melanie Courtot]

(grouping all replies into one)

The current OBI deprecation policy (which is in need of clean up) is available at http://docs.google.com/Doc?docid=dzprnmw_20cdv87mdw&hl=en

It has been based on the GO policy, but as far as I can see is very similar to the MGED policy as well. 

There is always the option to add an editor note when modifying a term (not only when deprecating, but also in other cases).

We used that when replacing the OBI classes with the IAO ones, adding an editor note "replaced by IAO_xxxxxxx"

It has been decided during the last workshop that he editor note should contain the date of addition (cf OBI minimal metadata at http://obi-ontology.org/page/OBI_Minimal_metadata)

We deprecate terms only when the meaning of the term changes, so renaming wouldn't fall under this category. One could add an editor note "2009-xx-xx: we decided to rename this term because..." but we wouldn't deprecate the original one and create a new one for a label change.

Addition of "other" makes sense, and using these new reasons to expand the list too. I expect our list would be fairly consistent after a while and the instances should cover all but the exceptional case.

I would favor storing as much as possible in the ontology itself. The only issue I can foresee is a size increase, but I think we have some margin before that happens for OBI. For the general case editor notes/obsolescence reason should be enough to explicit changes, and we could provide external documentation for major terms that resulted from a of of discussion.

Regarding the implementation itself, we use the built-in protege mechanism to create a widget for the curation status instance (more info at http://docs.google.com/Doc?docid=dzprnmw_10gk2mcpfb&hl=en, section developer, II/Curation widget), and we could reuse exactly the same mechanism for obsolescence reasons, so we wouldn't require extra Protege code or a new plugin if we were to adopt this solution.

Melanie

On 2-Mar-09, at 6:14 PM, Dirk Derom wrote:

Would this also means that one is able to add/view a timestamp and a comment field? If not, I would add these since they allow to trace the terms and get more detailed information (when available).

Do these deprecated terms include renamed terms (e.g. say when data would be changed into data item)? If so, I would add 'term renamed'. If not, I would include these terms, with the possible risk of having a lengthy list. At the same time it allows for tracing back the history and reasons for renaming a term. 
I would also add 'Other' or anything alike which can be further explained in the comment field. 
Does this make sense?

Does this also mean that the 'history' of the ontology is stored within the ontology itself? Or will there be external docs explaining why and when terms changed? I'd prefer within the ontology. 
My guess is that at a certain time when more people get involved, some terms/definitions will be questioned. You would want to avoid starting the discussions all over again, hence a short report of the history and reasons for the defintions/terms might be a good idea. Not sure whether this is an option, since it puts an additional load to the curation of the ontology. 

On 2-Mar-09, at 6:39 PM, Trish Whetzel wrote:

You might want to review the Deprecation Policy developed for the MGED Ontology (MO), https://www.cbil.upenn.edu/magewiki/index.php/TermDeprecationPolicy. Gilberto Fragoso, from NCI and a developer of MO, provided a lot of input into the policy. For MO, these changes were done without the help of a plugin, but one certainly would be useful for an ontology that is still undergoing many changes. There may also be some Protege code available that can be used as-is or as a framework depending on what the final policy is. 

Cheers,
Trish