Prototype design

From Filtered Push Wiki
Jump to: navigation, search

Web interface demo

Main search page

This may not be the same as the home page for FP.

Top navigation bar

In a top navigation bar, we will have a login link, an "about" link, a "perspective" link, a "help" link, and a search box.

  • The "about" link should take the user to a page that describes the project.
  • The "login" link should take the user to a login page with fields for username, password, and maybe domain.
  • The "perspective" link will be a drop-down menu whose items are links to the four searches available on the main search area of the page: collections manager data capture search, coll. mgr. view annotations search, researcher taxon search, and researcher geography search. Maybe "My perspective" could be an option for users who have logged in.
  • The "help" link will take the user to a page that describes how to use the search funtion, maybe FAQs, maybe examples...
  • The search box is a "search this website" function.

Main search area

  • In a left navigation box, a simple search box that does a google-like search of our indexed data across all records and fields. Under the simple search box, a list of the top-level facets. For example, facet names may include "Institution Name", "Discipline", and "Record Type". Clicking on a facet name would take the user to a search results/facet browse page (yet to be determined) for results.

For example, clicking "Institution Name" would take the user to a search results/facet browse page that represents means of navigating all records that have a value in the InstitutionName field. (See this discussion for some meeting notes on facets and browsing). An example of a Discipline is "Botany". Two examples of RecordTypes are "Observation" and "Annotation".

Another way to do facet browsing is to have a list of values that appear in records for that facet. This way, we might have a heading "Institution Name" and underneath the heading a list of values, e.g. "HUH", "UMB", "UF", and the values would be links to search results/facet browse pages that navigate all records that have the particular value ("HUH") in the InstitutionName field.

  • In the remaining area to the right, four links to perspective-based searches that also appear in the "perspectives" link in the top navigation bar.


To be determined, but reserved for future use.

Perspective search page

The user arrives at this page after selecting from the "perspectives" menu in the top navigation bar or from one of the links in the main search area.

  • Under thetop navigation bar is a text area describing the chosen perspective (e.g. "view annotations search").
  • Under that are search boxes for a set of fields related the the chosen perspective.
  • Under that are other facets related to the chosen perspective.
  • Under that is box on the left that displays a view of the message queues-- perhaps a ticker that shows the latest . On the right is a box that displays a representation of a list of pending long-running searches.
  • Under that, possibly as the footer, is a a horizontal list of widgets shown as icons for adding elements to the page that are not in the currently configured in the current perspective. Configuration is only available for logged-in users. The model here is the "yahoo" build-your-own home page idea.

A sample widget: the facets list. Another: a search form.

Components and interfaces

In this prototype, we plan to separate the whole system into three parts:

Client API: it will be invoked by client program and include three interfaces: query, update and annotation publish

Mapper: it will translate operations(data records) described in local schema into operations(data records) in a common schema, and vice versa.

Network layer: it will dispatch messages and control operations

(the client API, network communication module, schema translation module, network node adapter,storage module.)

The attached is a primitive design of the interface and its component view written in [Bouml]. (screenshots below are from A screenshot of the tree in this file is to the right, and the diagrams in it are below.

Screenshot of component.prj in BOUML

Issues need to discuss:

  1. The common vocabulary
    1. Is it fair to assume that the whole network only concerns collection records and their annotations? If it is the case, we could define the common vocabulary as the set of field names appearing in them. <PJM:Comment>Probably true for the prototype. Potential descriptions of concepts include the DarwinCore, the ABCD schema, and the taxon concept schema </PJM>
    2. The possible object of a query: collection data, annotation, geo-reference, anything else? <PJM:Comment>Work in Progress, taxonomic concept. Lower priority, but perhaps worth thinking about generalization is Use_Case_Scenarios#Scenarios_for_NLP_training_sets</PJM>
    3. Collection GUID
    4. table reference: Different data node may use different table names, so we may need a representation layer to unify them.<PJM:Question>Isn't this a external issue where clients would need to worry about how to map transported concepts onto their own database schemas?</PJM>
    5. duplication representation and its storage and control: centralized, localized or mixed
  2. The priority of those use cases <PJM>1. Finding duplicates. 2. Making annotations. 3. Others</PJM>
  3. test database

Proposal: We may want to follow a exciting story line to implement the prototype

Message passing and use of the MapperInterface

Revisiting the design

Here's an alternate look at components trying to untangle local storage, the local command and control interface, and network storage. These are images from the 2008 Sept 25 version of

Components alternate view.png
Components and interfaces used in creating an annotation
Components and interfaces used in receiving and responding to an annotation
Components and interfaces used in finding duplicates
Components and interfaces used in creating an annotation that adds a new duplicate.
Or does the API just need to implement a single Inject FP message interface?
Components and interfaces finding what specimens might be duplicates

Or, another more generic component diagram that doesn't reference Hadoop directly (from

Another, more generic view of components and interfaces

Add a dispatcher?

Revision suggested in 2009Mar26 meeting. Messages handled by API for parsing (communicating with the mapper if needed), then passed to Triage, with switchboard, planning, and execution components.

Component diagram with triage.png


Further clean up of the component diagram following the 2009Apr3 meeting.

Components3 revised components 2009Apr4.png

Client API

  • Provided as a library for Java based implementations of a client.
  • Client API should provide means to separate client UI programmer from xml message construction, network communication, queue visiting and result parsing.
  • Allows clear separation of concerns.
    • Client is concerned with parameters for message and format of results.
    • ClientAPI library is concerned with message construction, network communication, and handling synchronous/asynchronous messages on the network.
    • The FPMessageAPI - the network API is concerned with receiving messages and passing them on to Triage and the network components, and with providing results from queries to the network.
    • The ClientAPI and the FPMessageAPI together are concerned with securing communication between clients and network entry points.
  • Non-Java clients would need to implement the functionality of the ClientAPI library on their own (or wrap it in a way that makes it accessible to their code), Java based clients could just use the ClientAPI library.