Transition to OWL 2013-2014: Difference between revisions

From GO Wiki
Jump to navigation Jump to search
(Created page with " == Background == * In 2010 we drew up the Transition_to_OWL plan. The software group worked on migrating software to java/OWLAPI/OWLTools in 2010-2012 * In Jan 2012 we ...")
 
No edit summary
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
 
[[Category:OBO-Edit]]
== Background ==
== Background ==


Line 12: Line 12:
* We have OWL reasoning as part of a continuous integration service - [[Jenkins]]
* We have OWL reasoning as part of a continuous integration service - [[Jenkins]]
* GO software group (Heiko) and collaborators have written plugins to help approximate OE behavior - [[Ontology_editor_plugins]] - thanks particularly to Jim Balhoff
* GO software group (Heiko) and collaborators have written plugins to help approximate OE behavior - [[Ontology_editor_plugins]] - thanks particularly to Jim Balhoff
* Ontology editors are confident in using Protege to debug the ontology (e.g. explanation facility)
* Ontology editors are confident in using Protege
** to debug the ontology (e.g. explanation facility)
** to edit [[Ontology_extensions|extension bridge ontologies]] (e.g. x-disjoints.owl and x-plant.owl)
* Ontology engineering has become more like software engineering
* Ontology engineering has become more like software engineering
* CL has switched to using OWL for the edit version, and GO editors participate in development
* CL has switched to using OWL for the edit version, and GO editors participate in development
Line 22: Line 24:
** This necessitates cacheing entailments using is_inferred="true" axiom annotation
** This necessitates cacheing entailments using is_inferred="true" axiom annotation
** Additional complexity in workflow as cached entailments are re-checked, takes time to investigate
** Additional complexity in workflow as cached entailments are re-checked, takes time to investigate
* New terms still come in through OE and non-template TG necessitating retrospective axiomatization; delaying this ultimately means more refactoring and debugging


The weakpoints come down to lack of OWL support in OBO-Edit - particularly: working with >1 ontology, fast reasoning
The weakpoints come down to lack of OWL support in OBO-Edit - particularly: working with >1 ontology, fast reasoning


The consensus is that Protege in its current state would lead to a loss of productivity in other areas
The consensus is that Protege in its current state would lead to a loss of productivity in other areas - hence the existing hybrid solution, with Protege used for extension ontologies and debugging, TG for new terms, and OE as the workhorse.


== Plan ==
== Plan ==
Line 34: Line 37:


* Adding more plugins to Protege to better approximate OBO-Edit? Can this be approximated with plugins or is the foundation flawed? Would more training help?
* Adding more plugins to Protege to better approximate OBO-Edit? Can this be approximated with plugins or is the foundation flawed? Would more training help?
* Adding
* Releasing feature freeze on OBO-Edit, adding integration with Elk (remove need for cacheing entailments), support for multiple ontologies (no need for separate gene_ontology_xp_write)
* Modifying workflow to suit existing hybrid environment. E.g. adding MIREOT of external ontologies directly into gene_ontology_write
* Adding more web-based editing capabilities

Latest revision as of 18:55, 15 July 2014

Background

Successes

  • All software developed in GO now consumes the OWL as primary - obo is converted to OWL behind the scenes
  • We have many TermGenie templates, equivalence axioms are created prospectively rather than retrospectively
  • We have OWL reasoning as part of a continuous integration service - Jenkins
  • GO software group (Heiko) and collaborators have written plugins to help approximate OE behavior - Ontology_editor_plugins - thanks particularly to Jim Balhoff
  • Ontology editors are confident in using Protege
  • Ontology engineering has become more like software engineering
  • CL has switched to using OWL for the edit version, and GO editors participate in development

Weak points

  • Many OWL axioms are not visible or editable during normal ontology editing workflow in OBO-Edit
  • Entailments of those axioms are not visible
    • This necessitates cacheing entailments using is_inferred="true" axiom annotation
    • Additional complexity in workflow as cached entailments are re-checked, takes time to investigate
  • New terms still come in through OE and non-template TG necessitating retrospective axiomatization; delaying this ultimately means more refactoring and debugging

The weakpoints come down to lack of OWL support in OBO-Edit - particularly: working with >1 ontology, fast reasoning

The consensus is that Protege in its current state would lead to a loss of productivity in other areas - hence the existing hybrid solution, with Protege used for extension ontologies and debugging, TG for new terms, and OE as the workhorse.

Plan

The ontology group will come up with recommendations before the Bar Harbor meeting (Oct 2013) and provide these to the software group.

We need to decide on where to spend resources

  • Adding more plugins to Protege to better approximate OBO-Edit? Can this be approximated with plugins or is the foundation flawed? Would more training help?
  • Releasing feature freeze on OBO-Edit, adding integration with Elk (remove need for cacheing entailments), support for multiple ontologies (no need for separate gene_ontology_xp_write)
  • Modifying workflow to suit existing hybrid environment. E.g. adding MIREOT of external ontologies directly into gene_ontology_write
  • Adding more web-based editing capabilities