Obsolete - see VoExplorer

---

RegistryScope

A multipurpose registry explorer - used both as a main application, and also as a dialogue for selecting registry entries within other applications.

Could even be the main entry point for AstroGrid - i.e. the first thing the user experiences, and which launches apps such as workflow builder, application launcher on resources the user selects.

Scope vs Google

Problem with the current registry google is that you only see stuff you've searched for - there's little accidental discovery. (and experimentation in searches is discouraged by the slow search times)

RegistryScope should allow the user to discover resources that they didn't even know existed - and minimize the amount of time waiting for queries to round-trip to the registry.

Not much point in aping Google anyhow - as the collection we search is much smaller, and has a more rigid structure.

Presentation

Draw spidergrams / concept trees of registry entries, and allow the user to browse through them. The vizualizations used might be the same as AstroScope, or might be different. (We'll use the same vizualiation toolkit - prefuse - either way).

Have a separate pane for displaying information about individual registry records, and a third pane that allows users to invoke or use the registry record.

Usage as an Application.

User enters a search term or query, or selects a predefined query (e.g. list all data collections). User then selects or defines a hierarchy in which to arrange the results.

RegistryScope performs the query and displays a vizualization of the results. Maybe multiple tabs, displaying alternate vizualizations of the same result set.

User navigates around the result set. Each leaf node summarizes a single registry record. Inner nodes collect together individual records into categories. Additional information may be conveyed using color of nodes, additional links between nodes, tooltips, etc.

A small form allows the user to enter a few words for searching within the result set. Nodes that don't match the search fade to gray.

On selecting a single leaf node, the record display pane shows the details of this record.

Sets of registry records can be create by selecting an inner-node (which selects the children), and/or by shift-clicking on other nodes to add or remove them from the set..

On selecting a set of nodes, the record display pane shows a summary of what it contains (e.g. all siap services from Caltech (a single inner node), or a user selection) and a list of the set contents (i.e. the titles of individual registry entries). The individual details of each record in the set are shown in separate tabs.

When nodes are selected / unselected they change color in the vizualization - as with astroscope.

Also on selecting a node, a task pane displays all the possible operations on this registry entry (or set of registry entries).

Usage as a Dialogue

Essentially the same as when it's being used as an application.

Differences:

• A custom pre-defined query may be supplied by the application to display only resources suitable to that context.
• An additional filter is added to any user-entered query to 'gray-out' and make unselectable any resources that are unsuitable to that context.
• Most of the operations would be unavailable. (so not listed in the task pane)

The user is required to build a selection set, which is displayed in the record display pane. Application can control whether multiple selections are permitted.

User then hits 'ok' or 'cancel'

Search Terms

A single, small text-entry field for free-text search. Accepts AND, OR, NOT, quotes, parenthesis. For advanced users, will also accept snippets of xpath, adql, etc. Later, maybe allow very advanced users to provide their own xquery.

KevinBenson has accepted the task of building the keyword query parser that this requires. This will translate the keyword query into an XQuery that will return all matching registry entries. (see Bugzilla Ticket 1469, KeywordQueryLanguageDesignIdeas )

Hierarchy

The search terms define what registry records are to be displayed. The other thing that needs to be defined is the hierarchy these records should be ordered into.

E.g. group by organization, then service type, or group by wavelength, followed by coverage, etc, etc.

For novice users, we can define a few pre-canned hierarchies, and let them get on with things. However, advanced users will want to be able to control how results are grouped.

This can be done using a standard 2-list dialog window. Left hand list contains all possible grouping strategies (e.g Organization, service type, capability), and right-hand-list contains the selected strategies, in the order they're to be applied.

Buttons allow user to copy items between left and right windows, and to reorder the strategies up and down. We should probably provide a history menubar to name, store and retrive favorite / recent hierarchies.

Implementation-wise, each strategy maps onto an XPath that points into a registry entry - either returning the value directly (in the case of an enumeration-like element in the registry record), or computing some value from it (in the case of coverage, for example).

And as each strategy is essentially just a string, we can allow the expert user to define their own.

Vizualization

Display a tree of nodes. Can use the vizualiations from Astroscope, although the latest version of the prefuse toolkit provides new vizualizations, more suited to registry-like data. See http://prefuse.org/gallery/treeview for a demonstration.

We should upgrade to the new version of the prefuse toolkit as a first step - as it will lead to usability and stabiltiy improvmenets for AstroScope and HelioScope too.

Record Display Pane

Displays a human-readable summary of selected registry entry. We need to take care to use terminology and headings that are meaningful to scientists - and omit large parts of the registry entry if they're too confusing.

This summary can be produced using an xquery that returns just the registry information required. We may provide custom xqueries for some classes of registry entry which display additional data (e.g. paramters of a cea query).

Simplest implementation method may be to have the xquery generate html, which is then displayed using a HTML widget in the record display pane. The xquery can provide all the styling as part of the transformation. HTML widget should have hyperlink listeners setup - so that the application can catch when a link within the summary (say, to another resouce) has been clicked.

This approach also allows the expert user to define their own xqueries for summarizing registry entries.

Full xml text of a registry entry can be accesed as an operation in the 'advanced' part of the task pane.

Task Pane

This is a context-sensitve list of operations - like windows explorer left-bar (or as used in myspace). Here we can display operations applicable to the current selection. Probably subdivide the operations into three headings - Inspect, Activate, and Advanced. Clicking on an operation launches it - which may result in other dialogues or applications appearing.

Some of the operations may only be applicable ot single selections, while others may operate only on multiple selections. Others may be fine with both.

Operations

Here's some propsed operations - each takes the currently selected set of resources as it's parameter.

• display record in separate window. (any)
• save to disk as xml (any)
• email curator of record (single)
• invoke application launcher (single service)
• build a workflow (any number of applications)
• invoke astroscope (any number of cone/siap/ssap services)
• Broadcast to Plastic Applications (any)
• Add to Favorite Resources (single)
• Add as Folder to Favorite Resources (multiple)
• Add as Smart Folder to Favorite Resource (single internal node)
• Build a Query (single TabularDataService ), or multiple to do a join.
• Build a re-usable query (multiple TabularDataService ) - build a query on the commonality of different catalogues

We'll implement yet another plugin structure to make this list easily extensible.

Later: It might be useful to allow advanced users / customizers to add their own actions. We've already got the basic groovy interpreter embedded (used within workflow builder) - so can allow new operations to be specified using groovy scripts that call ACR. This could also be used to call out to external programs.

this would allow the user to define, say, an operation that queried a siap server and saved the images to myspace.

Search History

Menubar, containing a 'recent searches' section, which records search terms and hierarchy used - so they can be replayed. Also contains a 'favorite searches' section, which comes pre-populated with some searches. Users can add their own searches here - and organize them into folders, etc.

Favourite Resources

If we allow the user to store previous selections of resources as bookmarks, the user can build up a series of 'shortcuts' to their most commonly used applications. These remove the need to query and navigate to find resources they've previously used - and allows them to build up sets of services (e.g. to apply astroscope to a subset of services - more useful cataogues, etc.).

Selections can either be stored as a list of resources - which are static and unchanging, or as a 'smart folder' - whose contents are dynamcially found using a registry query. For any internal-node selection, the query to use for the corresponding smart folder should be quite straightforward to deduce (it's based on the xquery first used to produce that node)

Feasability.

This is all quite ambitious, but nothing that we haven't done before - just all drawn together into one applicaiton. There's a bit of infrastructure that needs to be implemented - but this will benefit the rest of the workbench too. Later some of these improvements can be rolled back into astroscope and helioscope.

We can keep it simpler by limiting the UI ..

UI Limits.

No Drag and Drop - doesn't work reliably, and isn't clear what to do. No Right-click menus - not clear. fiddly to operate. Use the task pane instead.

Querying Implementation.

The xquery genertated from the search terms will list all matching registry records. This is combined within a larger xquery which uses the hierarchy strategies to create a nested document of registry record summaries. Optional filters and formatting of the results may also be included in this xquery.

This query is passed to the registry, where it is executed. The document returned to the client is in a fixed schema - the xml node format defined by prefuse. The document summarizes all the matching records, and contains hierarchy and formatting information on how to display the results. Such a result document can be streamed directly into the vizualization component, where the display will update incrementally as results are received.

As it's a document, it's also possible to save it to local disk, for later use.

Performance

Caching.

XQuery-generated views of the registry can take a long time to run - as they may contain complex conditions that require some processing effort and may be returning a lot of data. Lucky, then, that registries don't update their contents very often. Which means that once a query is run once, we can save the result document in a local file cache, and just reload it when this query is re-run.

For further performance improvements, we can specify that the pre-canned queries get pre-fetched at startup - so that they're available as soon as the user opens them the first time.

Maybe the search history menu can provide information on the 'age' of the cached results - and allow a query to be refreshed (maybe by shift-clicking the search button??)

The alternative to using cached results would be to do some kind of incremental query - fetching results as branches are traversed by the user. However, this reduces the responsiveness of the system, would make bandwith limitations more noticable, and would place a greater load on the server.

Once the view has been generated, navigation around the result set requires no further registry access. However, the registry does need to be queried again when a resource is selected to display that resource record. At moment, we've got an in-memory cache of these records - maybe later we should persist this to a file too? (or at least for the favorite resources, etc). Again, shift-clicking on a node could force retrieval of that record from the registry. Maybe we have a 'expires after n days' option in the preferences.

The leaf nodes should provide a subtle some visual cue that there's a cached copy of them available - maybe a bolder border or something.

One of the operations on any inner node should be 'fetch all records' - this allows the expert user to do one larger registry access, rather than many small ones.

Streaming

Another bottleneck is the current registry delegate, which uses a DOM model to retrieve whole registry entries. This limits speed, and means that we can exhaust memory when running large queries.

Using XQuery, we are able to retrieve summaries of entries if needed - however, when retrieving large results, an interfvace that returned results incrementally (e.g. as an iterator) would be faster, and give better memory consumption.

Noel is going to take a look at using XFire soap library to query registry - this uses a streaming XML interface, with a pull model. If this works, it can be integrated later - interface changes shouldn't be huge.

Prerequisites.

• Keyword query parser
• Upgrade to new prefuse release (means we need to upgrade astroscope and helioscope)
• Streaming Registry client