ART: Overview

From GO Wiki
Jump to: navigation, search

The Problem

Ontology users frequently need to use a term that is currently unavailable. While ontology curators may quickly provide feedback, correction, or the requested term, there may be barriers to a solution (such as back-and-forth time between the user and curator, processing turnaround time, and knowledge gaps) that may prevent an appropriate resolution from being reached in a timely manner.

The Problem In a Nutshell

People are waiting for a synchronous process to complete without really knowing when or how to expect a resolution.

What to Do?

Basically, make the process asynchronous.

It would be better for the users to be able to continue work while using a temporary term (or terms) which the curators can deal with as they can. The resolution is then pushed back out to the users and (optionally) integrated with their current work. Both sides can continue work without waiting for the other.

A Solution Would...

Requirements

An implementation should have the following things in some fashion.

  • Allow the user to easily request a new term (or terms) from a "central service"
  • Be able to let user know of the resolution to the term request
    • (via email for human?, API check for programs)
  • As much as possible, allow the easy integration of upstream with the local
  • Be able to easily integrate with both humans and programs
    • (possibly through a universally unique id)
    • (possibly a web-based interface for humans)
    • (possibly a web-based API for programs)
  • Become part of the workflow of curators

Optionals

It might be nice if an implementation had the following things.

  • Users should be able to share their temporary terms with others
    • Reduce redundancy
  • Should allow for customized local ontologies that automatically track the upstream ontology
  • Eventually replace kludgy SourceForge.net system

Implementation History

Although it has been some time since there was last much progress or thought on ART (previously known as ORB), there were several software tests on how the problems might be tackled. While some of them were very short lived for one reason or another (such as a TWiki implementation), a couple progressed to the point of being able to meet some of the requirements listed above. Unfortunately, even the more promising tests have succumb to bitrot at this point.

OTRS

One test was done with the OTRS (Open Ticket Request System) framework. In a nutshell, the OTRS is a framework for being able to create, from the ground up using perl, a SourceForge.net-like website and database system (in this, it had a somewhat Drupal-like character).

While it never got very far along, it did demonstrate the possibility of a complete end-to-end redo of the workflow in a relatively intuitive way that would support users, curators, and programs. It was also nice in that things like email notification and incoming email parsing and processing were part of the package as well.

Advantages

  • Written in local perl
    • Making extension and customizations easy
    • Possible to reuse code from other local sources, such as AmiGO
  • Could possibly replace SourceForge.net for other uses
  • Total control over entire workflow

Disadvantages

  • Expensive in developer time
  • Uses more in the way of computer and hardware/maintenance resources
  • Learning/retraining curve for curators

AmiGO

Another attempt was made using a custom wrapper around SourceForge.net along with a RESTful API and an AmiGO frontend. This method used specially crafted ticket items in OBO format that curators could manipulate to meet several of the abive requirements. Results were reported to the user through a web interface.

This attempt also had some automatic integration with OBO-Edit via the RESTful API for automatic resolution of requested terms.

Advantages

  • Relatively cheap in development time and resources
  • Would attach to a known frontend
  • Simple testing and deployment
  • Uses the already known curator workflow of SourceForge.net

Disadvantages

  • Not a general solution to the problem
  • As wrapper to a third-party site (without an API), likely to be brittle and in need of frequent maintenance
  • No clear way to meet all goals and future needs

Current Thoughts

Considering the mistakes of the past, there has been some thought on better ways to achieve the above requirements.

GONUTS (Mediawiki)

At first glance, they seem to be very different, but they provide a lot of the same necessary information and functionality below the surface.

Considering that AmiGO already uses GONUTS as an external RESTful resource (demonstrating the avenue to hit a couple of requirements), it seems like the addition of non-existent terms would not be much of a stretch. By adding the automatic notification of curators (or the tracking system) of changes, several of the above requirements could be met without to much hassle.

Possible advantages: likely to be a relatively low-energy solution to several of the requirements.

Possible disadvantages: some of the more difficult requirements may be harder to reach using mediawiki as an engine.

CouchDB

Another thought has been to implement a system using a CouchDB as the basis for the "central service". Advantages of this approach could be:

Possible advantages: merging, conflict resolution, rollbacks, and versioning provided within the main engine; web-based functionality and API from the start; may be able to reach a wider range of goals easier in the long run.

Possible disadvantages: still need to built up a website and tracking system over it; more developer time and resource would be required.