Automating Term Requests
Problem
• There’s a long turnaround time between
when a new term is requested and when
that term is actually usable for annotation
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
mini-ontology 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 obo2obo 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…