Ontology Data Service API

Overview

Data services have been implemented as part of the Phenoscape application to retrieve data about evolutionary and model organism phenotypes. Ancillary services function in the auto completion of partially entered search terms by retrieving matching terms from the database, query relevant summary information on search terms, and retrieve any stored homology information about the search terms. This page details the functioning of each of these services, which make up the very first implementation of the Phenoscape application.

Service definitions

Data Services

1. Auto completion service
   • Function: Obtain matching term names for a partial term name string
   • Input: partial term name string, a list of ontology IDs, search parameters (search names only or synonyms only or both)
   • Output: matches as records of term name or synonym that was hit, and how the term was hit (name or synonym)
2. Term info service
   • Function: Obtain the full term information for a given term
   • Input: a term ID
   • Output: the definition and synonyms for the term. In addition, all the parent and child terms of this term are returned. For terms from the Teleost Taxonomy Ontology, their rank and extant/extinct information are returned as well.

Phenotype Data Service

1. Login
   • Function: Given a username and secret, obtain an authentication token
   • Input:
   • Output:
2. Save EQ statements
   • Function: Save an array of EQ statements to the data store
   • Input: a list of EQ statements on OBD-xml or pheno-xml format
   • Output: success/failure indicator
3. Load EQ statements
   • Function: Load an array of EQ statements from the data store
   • Input: author, or list of taxa,
   • Output: matching EQ statements in pheno-xml or pheno-syntax format
   • Notes: do we need parameter of list of entities to obtain EQs for?

Query languages

• SPARQL

Data exchange formats

• Plain text over HTTP:
  • OBO format
  • YAML
  • JSON

• XML over HTTP:
  • OBO-XML format
  • OBD-XML format

• RDF over HTTP:
  • RDF/XML
  • RDF/N-triples

Other ontology service definitions

• Ontology Lookup Service (OLS) at the EBI. cote2006 According to the website, the OLS can integrate any ontology available in OBO format. OLS is implemented as a web-service. The website has documentation on
  • web-service API (representing the WSDL) with JavaDoc for the interface contract, and
  • implementation overview (architecture)
  • OLS also provides 3 ReST-style services, similar to some of the lookups described above. These queries return a simple key-value XML format.
    • Term info: http://www.ebi.ac.uk/ontology-lookup/ajax.view?q=termmetadata&termid=ID&ontologyname=LABEL
    • Completion list: http://www.ebi.ac.uk/ontology-lookup/ajax.view?q=termautocomplete&termname=NAME&ontologyname=LABEL
    • Term name for ID: http://www.ebi.ac.uk/ontology-lookup/ajax.view?q=termname&termid=ID&ontologyname=LABEL
• The NCBO BioPortal supports a SOAP-based web-service API:
  • WSDL: http://www.bioontology.org/ncboservicebeans/NCBOWebserviceBean?wsdl
  • Java JUnit test: test.webservice.NCBOServiceTest
• The Zthes profile for SRU is a specification for navigating and querying remote thesauri
  • SRU is a Library of Congress-sponsored standard for query interoperability between digital repositories
  • The Zthes profile for SRU is based on an abstract model for thesaurus representation, which is also available as an XML Schema implementation.

Next Steps

1. Finalize list of services for the ontology data service API.
   • This will be an initial revision 1.0 - we'll surely have iterations later down the road.
   • We'll need an acronym - anyone had a flash of creativity? What about OBODS
2. Define which services are mandatory, and which are optional.
3. Decide on protocol and query syntax.
   • What about using REST, e.g., http://onto.myorg.edu/obods?q=list_ontology&category=anatomy, or using paths http://onto.myorg.edu/obods/ontology/list?category=anatomy)
4. Create a reference implementation for the server.
   • A very generic reference implementation would be a wrapper over a SPARQL endpoint, i.e., translating API calls into SPARQL queries and transforming returned RDF into the required format.
5. Create a reference implementation for a web-application client (using JavaScript) and for, e.g., a Java client (for servlets or Java stand-alone apps).

References

<biblio>

1. cote2006 pmid=16507094

</biblio>