Semantic resources project/PRO/Broker

In order for our modeling processes and (ultimately) SCF-based sites to quickly get identifiers for new terms that are discovered or entered into the system by users or curators, we need a "broker" which sits between the user and a "provider" of identifiers (such as PRO) and provides temporary identifiers which can later be updated after curation, editing, and resolution of duplicate or redundant references.

= Outline =



We think that there are at least seven distinct messages to be passed between the three parts of this system.

The first four messages are interactions between the "broker" and a "user" of the system -- some automatic or semi-automatic modeling or annotation system.
 * ASSIGN-ID : The user provides a minimal set of information, and asks the broker for a (temporary) identifier. If the minimal information is sufficient, then the broker responds with a USE-ID message containing the temporary identifier to be used.
 * FIND-ID : The user provides the broker with an identifier, and asks for the broker to respond with the "current" identifier that should be used in place of this identifier. The broker typically responds with a USE-ID message including either (a) the same identifier (indicating that the identifier is correct, or has not been remapped), or (b) a new identifier that should be substituted for the submitted identifier by the user. Alternately, the broker can also respond with ID-HAS-FLAG, indicating an error flagged by the provider and requiring a new identifier submission (using ASSIGN-ID).
 * USE-ID : This response from the broker contains an identifier, which should be used by the User in place of the submitted information.
 * ID-HAS-FLAG : There are two flags that a broker can return: INCOMPLETE and INCOHERENT. An INCOMPLETE flag indicates that the submitted information for the given identifier needs to be updated  (Do we need to add a new message, UPDATE-ID?).  An INCOHERENT flag indicates that there is no possibility of the identifier ever being remapped or usable, and should be deleted by the user.

The next three messages define a protocol between the provider and the broker:
 * NEW-IDS : asks for a list of identifiers, and associated submitted information, which are "pending" in the broker -- that have been submitted, and require review.
 * REMAP-ID : assigns a new identifier to be used for an older identifier. The older identifier is removed from the broker's "NEW" list.
 * FLAG-ID : associates an identifier with a flag, either INCOMPLETE or INCOHERENT. The identifier is not removed from the NEW list, however it will (until the flag is removed using REMAP-ID) be marked with an ID-HAS-FLAG message to the User.

= HTTP Protocol =

We should render the protocol into HTTP in some straightforward way. For example, the Broker could provide a single "NEW IDS" resource available at a well-defined URL : "http://some.broker.org/new-identifiers"

A GET of 'new-identifiers' will return a list of un-mapped identifiers and their associated information. A POST to 'new-identifiers' will submit a request for a new identifier to the system, and will be answered by a redirect to a URL that encodes the identifier: 'http://some.broker.org/identifier/'.

A GET on the URL of an identifier will return a document containing either the new identifier or a list of flags.

The Provider can use a POST to an identifier's URL to either remap the identifier, or mark it with one or more flags.

= Implementation =

We're working on a prototype implementation in Python.