Semantic resources project/Term Broker

Initial Design Ideas
PRO-specific Broker Design Sketch

Use Case Outlines

 * Ontology Authority A
 * Broker B
 * Client C

#1: Sufficient Information for an Existing Term
C uses HTTP to POST a request to B: “protein identified by string ‘XXX’ with modifier ‘YYY’”.

B matches “XXX + YYY” to term ZZZ previously granted by A; B then responds to C with response “USE ZZZ”.

#2: Sufficient Information for a New Request
C POSTs a request to B, “identifier for string XXX with modifier YYY”.

#3: Insufficient Information for an Existing Term
C POSTs a request to B: “identifier for XXX.” B determines that “XXX” is insufficient to determine whether an existing identifier is available, or whether a new request is required. B responds to C with an error, indicating that more information is required. C POSTs to B, “identifier for XXX with qualifier YYY”.

Broker API
/request-list POST: add a request

GET: retrieve list of all requests •	used by Authority •	retrieves list of requests queued on the broker, which can be satisfied by authority.

/request/# GET: request # information POST: add a response

/broker GET: format information from the broker


 * Response Deletion should be deprecated. ***

DELETE: remove a request

/requestdelete/# POST: redirects to a DELETE to /request/#