Difference between revisions of "ORB term request prototype"
(→Use cases) |
(→Use cases) |
||
Line 210: | Line 210: | ||
Actor: OntologyGateKeeper | Actor: OntologyGateKeeper | ||
− | Pre-condition: | + | Pre-condition: |
The user is at the specific term page | The user is at the specific term page | ||
Ideal path | Ideal path | ||
− | This case is initiated when the user,selects the "change term status" link | + | This case is initiated when the user,selects the "change term status" link |
*1. ORB presents the user login page | *1. ORB presents the user login page | ||
*2. User provides their name and password | *2. User provides their name and password | ||
Line 224: | Line 224: | ||
*9. ORB displays the term plus the updated status | *9. ORB displays the term plus the updated status | ||
+ | Alternative paths | ||
+ | Invalid OntologyGateKeeper | ||
+ | *1. Steps 1 to 3 as described in the ideal path will apply | ||
+ | *2. ORB terminates the request | ||
+ | *3. ORB informs the user that they aren't the ontology gatekeeper or they may try again in case of misspelled login information | ||
+ | *4. ORB returns to term page | ||
+ | Resolved term status: This applies when a term has already been resolved and assigned a permanent ID | ||
+ | *1. Steps 1 to 3 as described in the ideal path will apply | ||
+ | *2. ORB terminates the request | ||
+ | *3. ORB informs the user that the term has been resolved | ||
+ | *4. ORB returns to the term page | ||
+ | ---- | ||
+ | |||
+ | ---- | ||
+ | |||
+ | |||
+ | Case: DevelopOrb | ||
+ | |||
+ | Actor: Developer | ||
+ | |||
+ | Brief: This is a case for users who have skills in application development and are interested in developing ORB further | ||
+ | |||
+ | Pre-conditions: | ||
+ | |||
+ | |||
+ | Ideal path: | ||
+ | |||
+ | Alternative paths: | ||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | |||
+ | Case:IntegrateOrb | ||
+ | |||
+ | Actor : Developer | ||
+ | |||
+ | |||
+ | Brief: This is a case for users who have skills in application development and are interested in integrating ORB into existing application e.g to form a workflow. | ||
+ | |||
+ | Pre-conditions: | ||
+ | |||
+ | Ideal path: | ||
+ | |||
+ | Alternative path: | ||
---- | ---- |
Revision as of 16:46, 28 January 2010
Contents
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
Here is a documentation of ORB term request service. ORB will be accessible via an online interface and programmatically through RESTful web-services.
ORB architecture overview
Requirements
Accessibility
- ORB will have a web interface for easy access via browsers
- It will also have REST-style web service for programmatic access
- The prototype will be integrated into Phenex as a demonstration of an interfaceable API.
Actors and roles
- Requester
- Has an account or registers if it's the first time at the site
- Submits a term request
- Can edit their specific requested term's; name, definition, parent, relations, references, cross-references, synonyms and add comments.
- Ontology gatekeeper
- Has an account or registers if it’s the first time visiting the site
- Can edit all the requested term’s fields in the respective ontology(-ies)
- The only one with privileges to change a term’s status
- Developers
- Have access to the source code and an exposed API for integrating and developing ORB further
- Casual user
- May or may not have an account at the site
- Can browse , search, download and comment on terms
- Community
- Report bugs
- Submit feature requests
- Participate in term focused discussions
Note: The roles of casual users also apply to developers, requester, ontology gatekeepers and the community at large.
ORB prototype functions
Required
- New term request:
- Verifies if the requester is registered. If not, generates the registration form else, the login page for requesters
- On successful registration(for first time users) or login(for registered users), generates the term submission form
- Validates if all the required term fields are provided
- Validates if the e-mail provided is valid
- Validates if the requested term already exists in the ontology to which it's to be added
- If the request is valid:
- Assign's a temporary ID, status and generates date of submission to the term
- Informs the requester of successful submission
- Sends the term's temporary ID plus the details to the requester's e-mail account
- Persists the requested term to the ORB database
- Generates an update at the latest activity section of the site
- If the request is invalid because of missing required fields or inauthentic e-mail address, ORB rejects the request and sends a message to the requester about the failed submission and the reason
- If the request is invalid because the term already exists in the designated ontology, ORB informs the requester about the failed submission and returns the matching term from the ontology with it's permanent ID.
- Term editing
- Validates if user is a registered ontology gatekeeper for the specific ontology or the requester of the specific term
- Generates a term's editable fields
- Saves the terms altered or added information
- Sends a notification to the term's requester and ontology gatekeeper(if one exists)
- Generates an update about the action at the site's latest activity section
- Term's status change
- Verifies if the user is the authentic ontology gatekeeper for the specific ontology
- If the valid gatekeeper, generates term's page with the editable feature
- if status is set to 'resolved', a pop up field is generated for inserting the term's permanent ID
- Saves the terms edited information to the database
- Sends a notification message to the term requester's e-mail account
- Generates an update about the edited term at the latest activity section
- Discussion board
- ORB will have a term focused discussion board for all users to submit comments
Useful functions that maybe implemented in the prototype
- Validation of the submitted term's text definition
- Validation of the term's relations if matching those specified in the ontology
- Auto-completion services for relations,ontology name,parent and synonyms during term request and also in the term searching fields
- Enable a term request submission to multiple ontologies
Support
- A comprehensive documentation on ORB's functions(how to..),implementation and help pages
- Registration and extensive documentation at sourceforge, Biocatalogue and Phenoscape wiki
- Have a bug tracking and feature request mechanism
Use cases
Case:Register Brief: This is a use case for creating an account in ORB
Actor:ORB user
Pre-condition: The user is at the ORB site
Ideal path The process is initiated when the user selects the registration link
- 1. ORB presents the registration page
- 2. User provides required fields(e-mail,name, password and country)
- 3. User submits his/her information
- 4. ORB verifies the request
- 5. ORB informs the user of successful registration and provides an activation link
- 6. ORB sends the registration information to the user's e-mail account
Alternative path
Invalid request: This occurs when a user submits a request with missing required information
- 1. The steps 1 to 4 in the ideal path apply
- 2. ORB terminates the registration
- 3. ORB returns to the registration page with the missing field highlighted
Invalid e-mail address: This occurs when a user provides an invalid e-mail address
- 1. The steps 1 to 4 in the ideal path apply
- 2. ORB terminates the registration
- 3. ORB informs user the e-mail address is invalid
- 4. ORB returns the registration page
Case:SubmitTerm
Brief: This is a use case for submitting new ontology term requests.
Actor: TermRequester
Pre-conditions: The requester must be at the ORB website and has an account
Ideal path:
- 1. This use case is initiated when the requester clicks on the term submission tab
- 2. ORB presents the user login page for the requester to fill in the name and password
- 3. ORB verifies the requester
- 4. ORB displays the term submission page
- 5. Requester provides the required fields(i.e term's name, parent, textual definition,target ontology) plus any additional information related to the term (i.e other relations, references, database cross references, comments etc) and submits
- 6. ORB verifies the submission
- 7. ORB assigns a temporary ID to the term and presents it the requester
- 8. ORB sends the requested term's temporary ID and other details to requester's e-mail account
- 9. ORB returns to the term submission page
Alternative paths:
Invalid request: This occurs if the user submits a request without the required fields
- 1. Steps 1 to 6 as described in the ideal path will apply
- 2. ORB will the terminate the request
- 3. ORB will return to the term submission page with the missing required field highlighted
Matching term found: This occurs when the requested term already exists in the targetted ontology
- 1. Steps 1 to 6 as described in the ideal path will apply
- 2.ORB returns a message informing the requester that the term exists
- 3. ORB returns the matching term's id, name and parent to the requester
Case: EditTerm
Brief: This is a use case for editing requested term
Actor: TermRequester and OntologyGateKeeper
Pre-conditions
- The term exists in ORB database
- The term has not been resolved
- The term editor is at the specific term's page
Ideal path: This case is initiated when the TermRequester/OntologyGateKeeper selects the "edit term" link
- 1. ORB presents the user login page
- 2. User provides their name and password
- 3. ORB verifies the user
- 4. ORB presents the term with the editable fields
- 5. User makes any changes and submits
- 6. ORB verifies the changes made
- 7. ORB updates changes
- 8. ORB informs user of successful update
- 9. ORB displays the term plus the new changes
Alternative paths:
User not registered
- 1. Steps 1 to 3 as described in the ideal path apply
- 2. ORB terminates the process
- 3. ORB informs the user that they are not registered or need to try again in case of misspelled login details
- 4. ORB presents the ORB registration page
User neither the requester of the term nor gatekeeper for the target ontology
- 1. Steps 1 to 3 as described in the ideal path apply
- 2. ORB terminates the process
- 3. ORB informs the user that they need to be the term's requester or ontology gatekeeper to edit the term
- 4. ORB returns to the term page
Case:ChangeTermStatus
Brief: This is a use case for changing the status a term submitted
Actor: OntologyGateKeeper
Pre-condition: The user is at the specific term page
Ideal path This case is initiated when the user,selects the "change term status" link
- 1. ORB presents the user login page
- 2. User provides their name and password
- 3. ORB verifies the user
- 4. ORB presents the term with the editable status fields
- 5. User selects the new status and submits
- 7. ORB updates changes
- 8. ORB informs user of successful update
- 9. ORB displays the term plus the updated status
Alternative paths
Invalid OntologyGateKeeper
- 1. Steps 1 to 3 as described in the ideal path will apply
- 2. ORB terminates the request
- 3. ORB informs the user that they aren't the ontology gatekeeper or they may try again in case of misspelled login information
- 4. ORB returns to term page
Resolved term status: This applies when a term has already been resolved and assigned a permanent ID
- 1. Steps 1 to 3 as described in the ideal path will apply
- 2. ORB terminates the request
- 3. ORB informs the user that the term has been resolved
- 4. ORB returns to the term page
Case: DevelopOrb
Actor: Developer
Brief: This is a case for users who have skills in application development and are interested in developing ORB further
Pre-conditions:
Ideal path:
Alternative paths:
Case:IntegrateOrb
Actor : Developer
Brief: This is a case for users who have skills in application development and are interested in integrating ORB into existing application e.g to form a workflow.
Pre-conditions:
Ideal path:
Alternative path:
Specification
Activity
Database schema
REST services
Project plan
An agile approach will be used in ORB development. The sign √ indicates accomplished tasks while * indicates tasks which ought to have been implemented but haven't been
Week 1: 4 to 9 January, 2010 To review the ORB project, suggest any changes in light of existing technologies from literature review and input from the team and document the (including the changes).
- Revise the ORB project plan and milestones√
- Identify a suitable citation management tool and learn how to utilize it√
- Perform a comprehensive literature search and read the relevant papers and add to the ORB literature review√
Week 2: 10 to 16 January, 2010
Complete literature review, document and discuss with project team
- Perform further literature search, read and complete literature review√
- Document the project requirements (technologies to be used, architecture, behavior) in the project wiki√
- Hold an online meeting with NESCent team about progress and ORB implementation based on literature review and existing technologies√
Week 3: 17 to 23 January, 2010
Document ORB requirements and specification based on input from literature, discussion and research
- Revise the ORB requirements, specification and document it to the wiki
Week 4: 24 to 30 January, 2010
Revise, design and implement ORB data layer based on existing technologies, input from project team and implement the database.
- Design and implement the ORB database
- Document the ORB database schema
Week 5: 31st January to 6th February 2010
Design and implement ORB Application layer
- Identify and document the role of each server application
- Start implementing/coding the application layer
Week 6: 7 to 13 February, 2010
Continue implementing the application layer plus the unit test
- Continue implementing the application layer and unit tests
Week 7: 14 to 20 February, 2010
Continue implementing the application layer plus the unit test
- Continue implementing the application layer and unit tests
Week 8: 21 to 27 February, 2010
Continue implementing the application layer plus the unit test
- Continue implementing the application layer and unit tests
Week 9: 28th February to 6th March 2010
Continue implementing the application layer plus the unit test
- Continue implementing the application layer and unit tests
Week 10: 7th to 13th March 2010 Start working on the ORB user/client interface
- Identify and describe the user/client interface
- Begin implementing the user/client interface
Week 12: 21st to 27th March 2010
- Continue working on the user/client interface
Week 13: 28th March to 3rd April 2010
- Continue working on the user/client interface
Week 14: 4th to 10th April 2010
- Continue working on the user/client interface
Week 15: 11th to 17th April, 2010
- Continue working on the user/client interface
Week 16: 18th to 24th April, 2010
- Continue working on the user/client interface
Week 17: 25th April to 1st May 2010
Complete the ORB application
- Assemble all the ORB components and have a complete software
- Refine the code implementation and fix any bugs
Week 18: 2nd to 8th May 2010 Refinement and fix bugs
- Continue fixing bugs
Week 19: 9th to 15th May, 2010 Begin deployment
- Deploy ORB to a publicly accessible server
- Document ORB server
Week 20: 16th to 22nd May, 2010
*To be added
Week 21: 23rd to 29th May, 2010
*To be added
Week 22: 30th to 31st May, 2010
Meetings
Jan 19, 2010 (notes by Mtakai)
Present
- Paula Mabee
- Hilmar Lapp
- Wasila Dahdul
- Jim Bahloff
- Peter Midford
- Mtakai Ngara
Agenda
-
- ORB requirements
- Working modalities
Minutes
- ORB will be accessible via browsers and programmatically as REST web services.
- Term requester and Ontology gatekeepers must create an account at the site.
- A function to allow for submission of a term to multiple ontologies would useful.
- Apart from term submission, definition revision, term obsoletion and graph placement should be implemented.
- The users are categorized as:requester, ontology gatekeeper,developers, casual user and the community at large. A casual user need not register at the site.Visit requirements section for details on each of the users' role(s).
- Function for uploading a file and downloading terms to be implemented
- Have a section within ORB site for updates on latest acivities
- Integrate ORB into phenex
- Host the ORB project at sourceforge on it's page
- Have a mechanism of checking if a term already exists in an ontology
- Communication via e-mail
- ORB meetings after each use case implementation
- Code will be shared via subversion repository for team review
- Action items
- Contact the Berkley group (BBPO) on ORB trial
- Have screen shots of ORB uploaded in the wiki to demonstrate functionality
Links & Resources
- Early and incomplete ORB implementation in Perl by Seth Carbon. This interfaces directly with the SourceForge tracker.
Contacts
Name: Mtakai Ngara
E-mail: mtakai@nescent.org