OBO-Edit: Long Term Goals

From GO Wiki
Jump to: navigation, search

With my departure imminent, I thought I would lay out some of the long term goals I had hoped to pursue for OBO-Edit. Perhaps my successor will find some of these ideas worth taking up...

  1. OWL Roundtripping - OBO-Edit needs to be able to load and save OWL files without any loss of data. I believe Chris Mungall is already making important advances in this direction
  2. Code refactor: Greater use of the query system - Right now, many, many pieces of OBO-Edit and Phenote code examine the contents of an ontology by looping over the results of OBOSession.getObjects() (or LinkDatabase.getObjects()). This is fine for the moment, but these operations should eventually be achieved through the OBO-Edit query system (although library methods like TermUtil.getTerms(OBOSession) might be implemented for convenience). If these calls are routed through the query system, it makes it possible to efficiently implement non-in-memory OBOSessions - for example, OBOSessions that have live communication with a database. In the current paradigm, many operations on a database-backed OBOSession would require every object in the database to be fetched - for example, every term in the database would have to be examined to figure out the ontology roots. If the query system were used to discover ontology roots, our database-backed OBOSession could provide a special-purpose query resolver that could find the roots without having to fetch every record in the database and deliver it to the client application logic.
  3. More Wizards - OBO-Edit has libraries in place for the creation of step-by-step Wizards to guide users through difficult operations. At present, there is only one in place (for creating multiple terms at once). OBO-Edit should include additional wizards for:
    • Namespace-filtered ontology saves
    • Category-based ontology saves
    • Complex searches
  4. More granularity in filtered saves - Right now, OBO-Edit can only filter ontologies down to the level of links and terms. There's no way to filter out a collection of dbxrefs or synonyms, for example. OBO-Edit should be able - at minimum - to place collections of synonyms and dbxrefs in an external file. This will allow users to safely load external dbxref files and then remove those extra dbxrefs when they save.
  5. Read-only objects - Right now, any object that is loaded by OBO-Edit is editable. OBO-Edit should be able to mark a namespace as "read-only", and objects from that namespace would then by uneditable.
  6. Expression-based filtering - A context-free grammar and parser should be developed to represent OBO-Edit filters. This grammar should become part of the OBO 1.3 specification to allow dynamic, file-based filtering
  7. General-purpose command-line filtering/transformation tool - obo2obo should be expanded to become oboconvert (or something), a tool which can convert between any of the file formats supported by OBO-Edit, and would support ontology filtering on the command line. Most of the pieces for this tool are already in place - the org.bbop.commandline package contains a context-free command-line parser, and it is already possible to use the data adapter system to specify a parameter-based user interface in addition to the existing gui-based user interfaces.
  8. Direct database access - Chris's generic SQL libraries in org.bbop should be used to create OBD and Chado database adapters with full support for history tracking.
  9. Ontology versioning - See my proposal on the front page of this wiki - OBO-Edit:_Versioning_Proposal