The following are some use cases for interportlet communication in searching. I'm very tempted to try and us RSS/Atom as much as possible (or expose it via RSS/Atom), because this encourages reuse.

Search Query Feedback

User uses a search query and gets back list of hits as normal. The search portlet also broadcasts the query and another portlet listens to the broadcast and suggests improvements. Improvements could be spelling corrections, stemming, etc.

The information flow is a flow of queries from the search portlet to the search feedback portlet every time the user searches and a flow of rewritten searches from the feedback portlet to the search portlet if the user chooses a different query. The feedback portlet knows (a) the natural language being used (for stemming, spelling, etc); (b) the syntax of the search query (for building composite queries); and (c) the preceding search queries (for spotting patterns etc).

Query

Suggestions

standardise

standardi[sz]e

pselling

spelling

stemming

stem*

a b

a AND b, a OR b, "a b"

Search Query Templates

User uses a search query and gets back list of hits as normal. The search portlet also broadcasts the query and another portlet listens to the broadcast and suggests a subset of set of predefined templates which could be populated by the terms in the search query. Templates could include running the same search across a wider range of resources, wildcarding/stemming long terms and even complex sequences of co-location and query-reformation. (Thanks to GrahamKlyne for this idea.)

This is an elaboration of the previous situation, with the feedback portlet having knowledge of the datasources being aware not only (a), (b) and (c) but also (d) the domain of the datasources (for domain-specific search construction) and (e) domain-specific search constructs (for example decomposing chemical nomenclature).

Search Hit Scavenger

User searches for and examines documents using the search portlet, as usual. The search portlet also broadcasts the queries and bibliography details of the documents reviewed. Another portal consumes this feed and displays a list of documents, possibly annotated with keywords derived from the search terms used to find them, for addition to the users bibliography. All documents might be saved into a default bibliography rather like the "collected addresses" address book, for later searching.

The information flow is a series of document references form the search portlet to the scavenger portlet when the user indicates interest in a document and from the scavenger portlet to a bibliography portlet after standardisation of the reference.

Search Hit Formatter

User searches for and examines documents using the search portlet, as usual. The search portlet also broadcasts the queries used, so that when a HTML document is viewed, the viewer is able to highlight the selected terms. Obviously this example only works with textual documents.

The information flow is a series of queries from the search portlet to the formatter portlet every time the user searches and then a document reference when a user displays a document. When the user displays a document the formatter customises the document display request before passing it to the document viewer, so as to highlight the pertinent material.


IPC seems to mean many things to many people. There are a number of vendor specific IPC APIs and two methods using standard JSR168[1], one of which is used by a dedicated library[2]. Some of these are covered in a discussion within the uPortal community[3].

RSS/Atom is a very appealing format for passing information in our case, because both searching and examining of discovered documents is an essentially sequential process and there is already good support for RSS/Atom. Unfortunately most of the IPC mechanisms (except perhaps the library) appear to be better adapted to passing name,value pairs than full XML documents.

At the very least communication should be in a form that is readily re-packaged as an <item> in RSS/ATOM. This implies:

I'll ask around for suggestions.


References:

OSSWatchWiki: InterPortletCommunicationUseCases (last edited 2013-04-15 13:56:17 by localhost)

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.