OBIDeprecationPolicy

Contents

OBI Release Process

- Google Doc Discussing Deprecation

At release the OBI files have QC run and an inferred hierarchy produced. Each release is versioned, and is available from a specific URI using the release date as a tag. The current release is available from the download link - right.

The most up-to-date stable release file is available from

Pre-release files need to be checked out from SVN

OBI QC

Checks are made prior to release to assure compliance of the released version with OBI policies. This conforms with the GO deprecation policy that OBI has adopted.

Specifically, classes are identified that 

*do not comply with the minimal metadata policy
* have invalid OWL syntax or lead to inconsistency when reasoning using Pellet/FACT 
*Identifier format and policies are also enforced
*New classes are assigned a permanent identifier in the format OBI_0000001” at first release.
* verification that all IDs that were present in the previous release are still in use.
*Obsolete classes are removed from logical definitions

OBI Deprecation Policy

OBI terms occasionally have errors and need to be retired. The process of retiring a term is called obsolete or deprecating it. When a term is deprecated it should no longer be used in new annotation, and that annotations that use it be revised to use a more correct term.

Prior to deprecation - notice:

  • Editors will send note to relevant discussion groups, including our user mailing lists, soliciting opinions. This needs to happen minimally one week before a release is made in which that term would be obsoleted. It is okay to edit the file and obsolete it immediately, as long as the person who does the editing is willing to revert if objections are raised.

Once the decision to deprecate has been made:

  • An Editor note will be added to the OWL file explaining or pointing to a discussion of the reason why the term is being deprecated
  • a suggestion of more appropriate terms to use may be added
  • Class "obsolescence reason specification" similar to the curation status specification is also used, values are term imported, term split, placeholder removed, terms merged, failed exploratory term, other.
  • Deleted classes are moved under the ObsoleteClass in the OBI hierarchy and stored in a separate file. Identifiers are not re-used so classes can be tracked.
  • A deprecated annotation property is applied

MC: wrt to editor notes, I think it is very important to point to replacement or have explanation of deprecation. If we vote for removal of editor notes maybe we should skip obsolete classes? Other option is create a distinct annotation property, maybe "replaced by", or use seeAlso (which I like less as less precise)

Outstanding AI from Google doc relating to deprecation:

  • Modify reporting script to report obsolete classes or properties that are not in Obsolete.owl, or which are not a subclass of only ObsoleteClass or ObsoleteProperty. No other warnings or errors will be issued for obsolete terms.
  • Implement scripts to find obsolete classes by either: deprecatedClass/deprecatedProperty, "obsolete" curation status, or being a subclass (direct or inferred) of ObsoleteClass or ObsoleteProperty. Update all such cases to remove axioms other than the single subclassOf, to update the curation status, and, optionally, to mark as owl:deprecated.HP: done? MC: no

Allowed changes

  • RDFS labels may change e.g. to correct typos, or make a label clearer or more consistent
  • Axiomatic changes may be made, ie restrictions added or removed resulting in a change in the tree on classification
  • Classes may be moved, ie asserted parents may be removed or added
  • If text definitions and annotation properties may be added or removed
  • Some terms are imported from external ontologies - if these are obsolete in the source ontology you may still find these in OBI, please report these.

Deprecated Classes, properties and instances

  • Classes, properties and instances are deprecated when their 'meaning' in OBI changes or the class is found to be redundant. Any logical definitions which use that term will be modified so that references are removed.
  • If a term in OBI was found to be present in an OBO foundry ontology

the original OBI term may be deprecated and replaced with an imported term

  • Terms in OBI will be deprecated if they are decided to be: 
*out of scope
*badly defined
*redundant
  • Deprecation consists of 
*prefix with obsolete e.g. obsolete_digital_entity
*given a new parent 'ObsoleteClass'
*reason for deprecation e.g. 'failed exploratory term'

Release notes and changelogs

Each OBI commit into SVN has a change log. On release of OBI RC1.0 these will be provided as release notes.

Each released version of OBI *should have* release notes indicating

  • major changes e.g. re-classification of assays based on use of specified output and placeholder terms for stuture of primary sequence added to make logical definitions. These may be referenced to tracker items
  • new terms imported from an external ontology e.g. import of NCBI taxonomy terms for 330 species requested by ArrayExpress
  • List of newly deprecated terms

release notes example from EFO

Retrieved from "http://www.obi-ontology.org/page/OBIDeprecationPolicy"

Search

Tools

This page