Web interface demo
Main search page
This may not be the same as the home page for FP.
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
- Under the top navigation bar, a page title and some text describing the project.
- 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
- 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]. File:Component.zip (screenshots below are from http://mantis.cs.umb.edu/wiki/images/archive/f/f8/20080925211306%21Component.zip). A screenshot of the tree in this file is to the right, and the diagrams in it are below.
Issues need to discuss:
- The common vocabulary
- 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 http://wiki.tdwg.org/twiki/bin/view/DarwinCore/DarwinCoreVersions, the ABCD schema http://rs.tdwg.org/abcd/2.06/rddl-2007-10-18.html, and the taxon concept schema http://www.tdwg.org/uploads/media/v101.xsd </PJM>
- 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>
- Collection GUID
- 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>
- duplication representation and its storage and control: centralized, localized or mixed
- The priority of those use cases <PJM>1. Finding duplicates. 2. Making annotations. 3. Others</PJM>
- test database
Proposal: We may want to follow a exciting story line to implement the prototype
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 File:Component.zip.
Or, another more generic component diagram that doesn't reference Hadoop directly (from File:Component2.zip).
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.
Further clean up of the component diagram following the 2009Apr3 meeting.
- 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.