Ontological term broker/Prototype

= Broker 1.0 =

''JAR: This needs to be moved to a different web page. It's not of interest here.''

The initial version of the broker, outlined in February 2010 and implemented through April 2010, described a simple HTTP interface for both document annotator and ontology maintainer to interact with the broker through HTTP requests.

The document annotator:
 * 1) POSTs a request, consisting of 'name' and 'definition', along with zero or more identifiers indicating is_a relationships between terms.  The POST is responded to with a provisional identifier, an extant identifier, or an error indicating more information is required (if a field is missing).
 * 2) For each identifier, the text annotator may GET a URL associated with that identifer, and receives a response indicating that the request is filled, pending, or an error (cannot be filled).  If the response indicates that the request has been filled, then the new identifier for the request is also given.
 * 3) A top-level GET returns a complete list of all requests, pending or filled, about which metadata may be requested.

The ontology maintainer:
 * 1) does a GET request to retrieve a list of all pending requests.
 * 2) may GET a URL corresponding to each request, retrieving a collection of metadata (name and definition) required for term request fulfillment.
 * 3) may POST to each request URL, indicating a response to the request: filled (along with the final identifier and any edits to either the name or definition of the term), or cannot-be-filled (indicating that the request as given cannot be satisified).

PC: Is it possible to attach some examples/screenshots on how the ontologist curation process looks like?
 * TWD: no, it was all HTTP, there was very little UI.

Early implementation prototypes
The original interface to the broker was implemented in two versions:
 * a Python web application (written using Django, a web application framework) used to build and test the original interfaces.




 * Re-adapted as a Java web application, run as a Google Web App


 * A Lucene indexing strategy and search interface for matching protein terms to PRO identifiers was implemented for the Antibody project.

SVN Source

TODO: insert SVN links to these two versions?

Future work
Experience with the early implementation revealed that several new features would be required for more effective use of the broker in situations of the kind encountered in Alzheimer-related protein variant annotation.


 * 1) Our original implementation only received "structured" queries for new requests.   It was determined that we needed to support a "text query" style of interface, where "search term + context" queries could be used to either retrieve existing terms or to create new requests.
 * 2) Our requirements, as discovered while annotating antibodies, demanded more from the PRO ontology than simple requests for proteins by name.
 * 3) PRO worked to support new types of terms beyond proteins: isoforms, sequence variants, modified sites (phosphorylation), and cleavage-products.
 * 4) Requests should be able to be optionally tagged with their "type."
 * 5) We need to implement a user system, for tracking requests, responses, and acknowledgement of successful substitutions of real identifiers for provisional identifiers.