Ontology meeting 2015-10-22

From GO Wiki
Revision as of 10:55, 29 October 2015 by David os (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Attendees:

Minutes: David OS

Managing inference

  • Aims:
    • Use Protege + elk to track automated classification during editing - without instantiated inferences getting in the way
    • Track and manage global changes in inference. e.g. - if a change to an external ontology means 50 inferences are justifiably no longer valid, we can find them all and delete them easily.
  • Strategy:
    • Axiom annotations distinguish valid and stale annotations
    • Axioms sorted into separate files. After inference and sorting, OBO diffs give report of global changes.
  • What we can easily do:
    • Flag stale inferences (Requires some code from Heiko)
    • A system to sort the ontology into 3 files: ontology with no inference; valid inferred axioms only, stale inferred axioms only (Requires some code, trivial in OBO)
    • Set up an import system for Protege that allows the ontology to be viewed with no inferences, just with stale inference or with all inferences.
    • Run inference instantiation pipeline locally (?)

With this in place we can run an

Key question: Where does splitting happen?

  • Option 1: maintain 3 master files.
    • Requires: New filter on OE for stale inferences.
    • Advantages:
      • Sorting and inference don't need to be run locally
      • (OBO) diffs with current SVN setup allow tracking of all new inferences & (newly) stale inferences.
    • Disadvantage: """No longer a single diff to give a complete picture of changes on each term."""
  • Option 2: Split locally as a step in OBO to OWL conversion
    • Requires:
      • local inference instantiation and sorting system
      • local VC of split (OBO) files required to keep track of changes from inference
      • files need to be merged before committing
    • Advantages:
      • One big OBO file for diffs.
    • Disadvantages:
      • Complicated for Eds to set up and run. DOS would do this - would anyone else?


Discussion

Why keep stale inferences anyway. Can we just throw them away?

Two issues: Need to clean up current set first. There are lots. We need to be certain that the mechanism for flagging stale inferences is sage In the past it has not been.

-> Review of ETINE flags finds many that are unsage.

-> discussion of how ETINES are flagged

1. Is the classification inferred when the instantiated classification alone is removed? 2. Is the classification inferred when all currently true instantiated inferences are removed? 3. Is the classification inferred when all instantiated inferences, including stale ones, are removed?

Removal of redundancy should NOT happen before instantiation of inference.  This is what is causing unsafe flagging.

AI: Write spec for how ETINE flagging happens. AI: Once we have a new report: Editors review again.


'cell proliferation' terms

Most have logical def, e.g. 'epithelial cell proliferation' is_a 'cell proliferation' that acts_on_population_of 'epithelial cell'. Did we have plans for a TG template? (Not in Jira.)

Note: this is a case where we have a semi-random distribution of terms in the ontology vs annotation extensions. Should we just make terms for all AE usage and retrofit AEs?

Adding logical defs to cellular response terms

DOS has started to do this. What's the syntax, and should we look into filling all gaps.

MAYBE: cell to cell mobile

Follow-up on Design Patterns

Next steps