OBOEdit Working Group Working Group Accomplishments About to

OBO-Edit Working Group

Working Group Accomplishments • About to release OBO-Edit 2. 000 -beta 14 • Tracker records 89 bugs fixed (but lots more were • • actually fixed) Twice monthly working group meetings on webex Introduced office hours, now held 6 times per month

Wiki as development roundtable • We’ve had a lot of success using Wiki pages as • • feature discussion forums We developed the new searching interface by creating a wiki page with mockup interfaces, and then working group members posted their comments. This process led directly to the new searching interface We’re now also using the Wiki: Talk features to record group members priority rankings for various new features

OBO-Edit 2. 0 Features • • • Graph-based dag viewer Graph-based ontology editing Spell checking Fast incremental reasoning (Reasoner is 3 x faster when run from scratch, and over 100 x faster when incrementally reasoning) New search interface Docking panels OBO-Edit now supports the OBO annotation format The OBO-Edit code is being spun off as the OBO software toolkit, now in use in Phenote and some other small OBO parsing projects External developers (by which I mean Chris) have begun to contribute code to OBO-Edit

Praise for the Working Group • The OBO-Edit Working Group members are amazing. Their patience and tenacity through the often frustrating process of beta-testing OBO-Edit brings tears of gratitude and joy to this otherwise deeply embittered man.

One possible solution: give users an ID with their request • We could give a user a temporary id to use for annotation when they request a new term. We could provide a mechanism for mapping those temporary ids onto real term ids when the term request is closed by a curator.

Unfortunately… • Many term requests are rejected, so what • happens to those annotations? Term requests tend to be rejected for 2 reasons: § The term they want already exists § The term they want is inappropriate • How do we communicate that information back to the requester automatically?

Other Difficulties • Every annotation database is different! • How would we provide a mechanism to map temporary ids to real ids that would work with every annotation database?

Observation • Every annotation database is different, but • every annotation database (that doesn’t totally suck) provides some means of dealing with term obsoletion. Hmm…

Our Brilliant Idea: Private Ontologies • When a user requests a new term, they are • • given a URL where they can download a private mini-ontology The private ontology contains all the terms that they’ve requested through sourceforge The terms in the private ontology have special temporary ids

Private Ontologies: The Lifecycle of a Requested Term • When a term request is closed, the user receives an • • email from sourceforge announcing that the term request is closed, so the user redownloads their mini-ontology The terms in the mini-ontology that correspond to the resolved request are now obsolete, but contain “consider” and “replaced_by” tags indicating which real ontology term to use instead The user’s annotation database should be able to use the existing “obsolete term fixer” software to update the annotations automatically!

Example: From the annotators point of view • An annotator decides he needs the term • “heart muscle growth”, and he can’t find it in the ontology He enters a request with our system, and is given a URL for a mini-ontology. The miniontology looks like this:

Example: From the annotators point of view [Term] id: GOTEMP: 084651321866 name: heart muscle growth

Example: From the annotators point of view • The annotator loads this file along with the • GO to populate his database, and his new term is now available for annotations! (Note: Any fully compliant OBO parser should be able to load multiple files at once, but if the database doesn’t support this, he can use OBO-Edit’s obo 2 obo tool to merge the two files into one)

Example: From the annotators point of view • A few days later, his term request is • resolved, and he receives an email telling him to redownload his mini-ontology It now looks like this:

Example: From the annotators point of view [Term] id: GOTEMP: 084651321866 is_obsolete: true name: heart muscle growth comment: This term is already available under the name “cardiac muscle growth”. Always search synonyms, loser. replaced_by: GO: 0055017

Example: From the annotators point of view • The user now loads the new ontology into • the annotation database, which uses the replaced_by tag to automatically update annotations to the temporary term. Hooray!

Same example: From Jen’s point of view • Jen works her way through the term • • requests, silent tears of exhaustion streaming down her face She comes across a moronic request for “heart muscle growth”. Jen adds a comment to the sourceforge tracker that looks like this:

Same example: From Jen’s point of view This term is already available under the name “cardiac muscle growth”. Always search synonyms, loser. replaced_by: GO: 0055017

Same example: From Jen’s point of view • She then closes the sourceforge request • and moves on with her life Such as it is

How does it work? • Take it away, Seth…