Difference between revisions of "ORB term request prototype"

From phenoscape
(Work plan)
Line 1: Line 1:
==Vision==
+
== Introduction ==
To develop an application that will allow data curators to use new ontology terms without creating a workflow bottleneck.
 
  
===Background===
+
The vision of this project is to develop an application that will allow data curators to use new ontology terms without creating a workflow bottleneck.
 +
 
 +
=== Background ===
 
There is a need for applications that will expedite the annotation of phenotypic characters using ontologies and also promote community participation in the expansion and refinement of ontologies.  One particular need that has arisen within Phenoscape and other projects is for an Ontology Request Broker (ORB), an application that can launch new ontology term requests within existing data curation workflows, record term provenance and community discussion, enable temporary terms to be used in data annotation, and update temporary terms once a request has been resolved.
 
There is a need for applications that will expedite the annotation of phenotypic characters using ontologies and also promote community participation in the expansion and refinement of ontologies.  One particular need that has arisen within Phenoscape and other projects is for an Ontology Request Broker (ORB), an application that can launch new ontology term requests within existing data curation workflows, record term provenance and community discussion, enable temporary terms to be used in data annotation, and update temporary terms once a request has been resolved.
  
==Scope==
+
=== Scope ===
This document describes the design of a prototype ORB application involving only a term request web-service.  
+
 
 +
This document describes the design of a prototype ORB application involving only a term request web-service. ORB is envisioned to be a  web-service with an API for custom integration into multiple data curation software applications.
 +
 
 +
=== Diagrams ===
 +
 
 +
[[Image:System_diagram.jpg|Center]]
  
===ORB requirements specification===
 
  
==Introduction==
+
== ORB requirements specification ==
ORB is envisioned to be a  web-service with an API for custom integration into multiple data curation software applications.
 
  
==System behavior==
+
=== System behavior ===
 
ORB will allow users to submit (and view?) requests for new ontology terms.  In the prototype, communication between the client and server will be effected via RESTful web-services. Functionality will be demonstrated via a custom web interface and widget in [[Phenex]]. The integration in Phenex will be a demonstration of the ORB’s “integratability” with other related applications via the API.
 
ORB will allow users to submit (and view?) requests for new ontology terms.  In the prototype, communication between the client and server will be effected via RESTful web-services. Functionality will be demonstrated via a custom web interface and widget in [[Phenex]]. The integration in Phenex will be a demonstration of the ORB’s “integratability” with other related applications via the API.
==Term submission==
+
 
Via the web interface or the ORB widget in Phenex a user will have to submit a term’s:
+
=== Term submission ===
name,
+
Via the web interface or the ORB widget in Phenex a user will have to submit a term’s
definition,
+
* name,  
and parent relationship.
+
* definition, and
 +
* parent relationship.
  
 
The optional fields will be:
 
The optional fields will be:
database references,
+
* database references,
citations,
+
* citations,
other relationships,
+
* other relationships,
synonym(s),
+
* synonym(s), and
and comments.
+
* comments.
  
 
A user will be required to submit their e-mail addresses and their names (optional).
 
A user will be required to submit their e-mail addresses and their names (optional).
  
==Term processing==
+
=== Term processing ===
 
On term submission, ORB will:
 
On term submission, ORB will:
 
* Validate if the required fields are provided, send the user an invalid term request message and return to the submission interface.
 
* Validate if the required fields are provided, send the user an invalid term request message and return to the submission interface.
Line 41: Line 46:
 
*Send the term request to the community through the relevant mailing lists at source forge (http://sourceforge.net/projects/obo/support).
 
*Send the term request to the community through the relevant mailing lists at source forge (http://sourceforge.net/projects/obo/support).
  
==Term resolution==
+
=== Term resolution ===
 
If a term is resolved (i.e. a reviewer(s) either accepts a term requested or provides a more accurate term as an alternative) the ontology gatekeeper will provide the new term plus all the information provided by the expert via ORB’s web service.
 
If a term is resolved (i.e. a reviewer(s) either accepts a term requested or provides a more accurate term as an alternative) the ontology gatekeeper will provide the new term plus all the information provided by the expert via ORB’s web service.
 +
 
The application will subsequently:
 
The application will subsequently:
 
* Update the status of the new term to “Resolved”
 
* Update the status of the new term to “Resolved”
Line 51: Line 57:
 
* Send notification e-mail to the user and community.
 
* Send notification e-mail to the user and community.
  
==Implementation details==
+
== Implementation details ==
  
 +
ORB will be a platform-independent web service with an exposed API for its integration into pre-existing ontology suites such as Phenex, OBO-edit, Phenote etc. Java will be the main language of development and application will be designed in a RESTful way using Restlet, a lightweight REST framework for Java applications.
  
ORB will be a platform-independent web service with an exposed API for its integration into pre-existing ontology suites such as Phenex, OBO-edit, Phenote etc. Java will be the main language of development and application will be designed in a RESTful way using Restlet, a lightweight REST framework for Java applications.
 
 
The application will support GET, POST and PUT requests and the data will be stored in PostgreSQL, an object relational database management system. Hibernate library will be utilized to map the java persistent classes to the relational database.
 
The application will support GET, POST and PUT requests and the data will be stored in PostgreSQL, an object relational database management system. Hibernate library will be utilized to map the java persistent classes to the relational database.
 
From ORB web-service interface (or Phenex widget) and using the term ID or name, users will be able to access information provided during submission and resolution.
 
From ORB web-service interface (or Phenex widget) and using the term ID or name, users will be able to access information provided during submission and resolution.
Line 60: Line 66:
 
In this prototype, the functionality of ORB term request services and the cycle will be exemplified by working with the Teleost Anatomy and Development Ontology (TAO) gatekeeper (http://www.berkeleybop.org/ontologies/owl/TAO) and TAO mailing list at source forge.
 
In this prototype, the functionality of ORB term request services and the cycle will be exemplified by working with the Teleost Anatomy and Development Ontology (TAO) gatekeeper (http://www.berkeleybop.org/ontologies/owl/TAO) and TAO mailing list at source forge.
  
==Diagram==
+
== Project plan ==
[[Image:System_diagram.jpg|Center]]
 
 
 
==Work plan==
 
 
''[Indicate calendar dates for these weeks.]''
 
''[Indicate calendar dates for these weeks.]''
  
Line 137: Line 140:
 
To deploy the ORB new term web-service to the NESCent server
 
To deploy the ORB new term web-service to the NESCent server
  
 +
== Links & Resources ==
 +
 +
* Early and incomplete [http://geneontology.cvs.sourceforge.net/viewvc/geneontology/go-dev/amigo/amigo/cgi-bin/experimental/orb?revision=1.1&view=markup ORB implementation in Perl] by Seth Carbon. This interfaces directly with the SourceForge tracker.
  
===Contacts===
+
== Contacts ==
 
Name: Mtakai Ngara
 
Name: Mtakai Ngara
  

Revision as of 01:56, 29 October 2009

Introduction

The vision of this project is to develop an application that will allow data curators to use new ontology terms without creating a workflow bottleneck.

Background

There is a need for applications that will expedite the annotation of phenotypic characters using ontologies and also promote community participation in the expansion and refinement of ontologies. One particular need that has arisen within Phenoscape and other projects is for an Ontology Request Broker (ORB), an application that can launch new ontology term requests within existing data curation workflows, record term provenance and community discussion, enable temporary terms to be used in data annotation, and update temporary terms once a request has been resolved.

Scope

This document describes the design of a prototype ORB application involving only a term request web-service. ORB is envisioned to be a web-service with an API for custom integration into multiple data curation software applications.

Diagrams

Error creating thumbnail: Unable to save thumbnail to destination


ORB requirements specification

System behavior

ORB will allow users to submit (and view?) requests for new ontology terms. In the prototype, communication between the client and server will be effected via RESTful web-services. Functionality will be demonstrated via a custom web interface and widget in Phenex. The integration in Phenex will be a demonstration of the ORB’s “integratability” with other related applications via the API.

Term submission

Via the web interface or the ORB widget in Phenex a user will have to submit a term’s

  • name,
  • definition, and
  • parent relationship.

The optional fields will be:

  • database references,
  • citations,
  • other relationships,
  • synonym(s), and
  • comments.

A user will be required to submit their e-mail addresses and their names (optional).

Term processing

On term submission, ORB will:

  • Validate if the required fields are provided, send the user an invalid term request message and return to the submission interface.

If the user’s submission is successful, the application will:

  • Notify the user of successful submission
  • Set the status of the term to “Pending”
  • Assign a temporary ID (ORB:xxxxxx) and store in a database. The xes in the temporary ID represent the name provided to allow the user to continually annotate entities using the requested terms without having to halt their work.
  • Send the temporary ID assigned to the user
  • Automatically send notification messages to the ontology gate keeper(s)
  • Send the term request to the community through the relevant mailing lists at source forge (http://sourceforge.net/projects/obo/support).

Term resolution

If a term is resolved (i.e. a reviewer(s) either accepts a term requested or provides a more accurate term as an alternative) the ontology gatekeeper will provide the new term plus all the information provided by the expert via ORB’s web service.

The application will subsequently:

  • Update the status of the new term to “Resolved”
  • Assign the term a permanent ID as provided by the ontology gatekeeper
  • Generate a notification mail to the user and community and the resolution.

If a term is rejected (i.e. the expert(s) and community concur that the requested term is not acceptable and no alternative exists for the request), the gatekeepers will submit this feedback plus any explanations, comments etc. that may have been availed by the expert(s). In this case ORB will:

  • Set the term status to “Rejected”,
  • Send notification e-mail to the user and community.

Implementation details

ORB will be a platform-independent web service with an exposed API for its integration into pre-existing ontology suites such as Phenex, OBO-edit, Phenote etc. Java will be the main language of development and application will be designed in a RESTful way using Restlet, a lightweight REST framework for Java applications.

The application will support GET, POST and PUT requests and the data will be stored in PostgreSQL, an object relational database management system. Hibernate library will be utilized to map the java persistent classes to the relational database. From ORB web-service interface (or Phenex widget) and using the term ID or name, users will be able to access information provided during submission and resolution.

In this prototype, the functionality of ORB term request services and the cycle will be exemplified by working with the Teleost Anatomy and Development Ontology (TAO) gatekeeper (http://www.berkeleybop.org/ontologies/owl/TAO) and TAO mailing list at source forge.

Project plan

[Indicate calendar dates for these weeks.]

Week 1: 21 to 26 September Preparation

To gather all the ORB requirements and set up a working IDE with all the required libraries.

  • Design and document a work plan
  • Carry out interviews,consultation and document ORB requirements
  • Write up the ORB specification document
  • Set up java IDE,Apache—tomcat server and import the required libraries(restlet,json)

Week 2: 28 to 2 October Term request server and skeleton web services

A working skeleton term request server, which responds to new term request and status queries, but with dummy data.

  • Create Restlet server project.
  • Create a Restlet Application subclass which maps URLs to service resources.
  • Create ServerResource subclasses which respond to HTTP requests for each web service.

Week 3: 5 to 10 October Relational database for persisting term requests

Design and establish a server database for storing term requests.

  • Create ORB database schema
  • Create application subclasses that store data submitted into the database
  • Create application subclasses that retrieve and display data in the database

Week 4: 12 to 17 October New term definition and creation

To define and create more suitable ontology terms and generate informative responses on term submission.

  • Create an application function that will take up the user provided required fields plus the different combinations of the optional fields and create terms and add to the database
  • Create a function to validate if the user provided the required fields and if not generate an informative response to the user
  • Create an application function to assign status on term submission

Week 5: 19 to 23 October Term Resolution and generation informative of responses

To build application functions that will enable term updates and generate informative responses

  • Create an application function to facilitate updating a term requested in the database and change the term’s status appropriately
  • Create a function to generate auto messages to the term requester

Week 6: 26 to 31 October ORB community outreach and ontology gate-keepers notification

To build a function in ORB to facilitate the auto-generation of messages to the community mailing list at source forge and ontology gate keepers

  • Build an application function that will generate auto messages to the ontology gate-keepers when a term is submitted
  • Create a function to send automated messages to the community mailing list both on term request and resolution

Week 7 : 2 to 6 November Web-interface

To establish ORB web-interface for searching, viewing and updating the requested terms

  • Design and implement the web-interface of ORB new term services
  • Create functions to collate the user provided information from the interface and load into the ORB server database

Week 8: 9 to 14 November Displaying and downloading search results

To create function to display term search results and enable downloading .

  • Build an application function to display the term search results and provide informative response in case the term being search is not found
  • Create a function to enable downloading the searched term in different formats

Week 9: 16 to 21 November Testing

To make the web-service compartible with different technologies

  • Test and edit the programs to enable smooth and uniform functionality in different Oses
  • Test and edit the programs to enable smooth and uniform functionality in different browsers

Week 10 and 11 : 23 November to December 5 Deployment

To deploy the ORB new term web-service to the NESCent server

Links & Resources

Contacts

Name: Mtakai Ngara

E-mail: mtakai@nescent.org