Software Interface for Ontological Term Requests/Old Notes

The text annotator should be able to request:
 * 1) new PROTEINs, by name, definition, and Uniprot accession
 * 2) annotate a PROTEIN request as requiring a SPECIES
 * 3) request an ISOFORM of a PROTEIN
 * 4) create an EXON for a PROTEIN
 * 5) add a SITE to an EXON
 * 6) add a part to a SITE: either MODIFIED RESIDUE or RESIDUE
 * 7) indicate that a PROTEIN has or lacks a SITE
 * 8) indicate that a PROTEIN lacks an EXON

Furthermore, the text annotator requires the ability to search, by text matching (again implemented using Lucene) the complete set of parts: PROTEIN, ISOFORM, EXON, SITE, MODIFIED RESIDUE, RESIDUE.

Finally, the relationships of these individual types of terms are constrained by the ontology. (Example: it doesn't make sense to say that an EXON has a part that is a PROTEIN, as "proteins have parts that are exons, not the other way around.") Where the original broker only did minimal consistency checking of requests to ensure that the name and definition fields were filled in, now the broker must also ensure that a system of requests for a PROTEIN and its subsidiary terms do not result in an incoherent structure to be submitted to PRO. This requirement suggests that the broker should have rudimentary reasoning capability built in to it.

The goal for Broker 2.0 is a Java web application, including the Lucene framework that,
 * 1) supports the requests outlined above, in place of the single term request interface in Broker 1.0,
 * 2) supports some form of user identity and authentication, to track provenance and manage permissions,
 * 3) includes a text search interface which handles all term types simultaneously, and can work with separate web-based Annotation tools, and
 * 4) produces OBO output (instead of flat-files, which are no longer sufficient to represent these structured requests) for submission to PRO,
 * 5) and processes edited OBO from PRO through a single POST endpoint, as an alternate means to individual web-calls from the ontologist, for receiving responses to requests.


 * 1) Make sure that the "ontologist" isn't described as a user.
 * 2) make the "software" tool part of the "curator" role more explicit
 * 3) Change the "curator" role into "curation agent" or "assistant."
 * 4) Make it clear that annotator and knowledge enginner are low-throughput, the curation agent is high throughput.
 * 5) make it clear that "the annotator is not a biologist."
 * 6) call it "text annotator" or "document annotator"
 * 7) give more details about examples of who could be a text annotator.
 * 8) make it clear that  the knowledge engineer has no source text to work from.
 * 9) text annotator, knowledge engineer, curation agent
 * 10) Remove RESTful interface reference "for the annotator"  -- it's the api through which the interface is built.
 * 11) separately, say what the annotator does.
 * 12) Expand the "implementation" section.
 * 13) What do I "take advantage" of Lucene *for*?