Use case: use DSA with the help of VOSpace

This is a possible way of working that makes it easier to construct queries on conventional (static, registered, read-only archive) DSA installations. it came out of discussions with KonaAndrews and DaveMorris at the VOTech "hackathon" in Strasbourg, September 2006.

Context

Building and sending queries to DSA via the workbench works, but it's not easy. The discovery process is not ideal, since the data-changing applications and the query-applications are mixed together. With RegistryScope, the process will become more complicated, since the user will have to relocate something found in the RS sweep via the task launcher. Further, users will need a way to remember things found by RS for later work.

Story

Researcher is interested in selecting archive data via ADQL but doesn't have a specific data-set in mind (or, equivalently, chooses a data-set but doesn't know how it's named in the registry). Researcher runs RegistryScope (RS). Various suitable archive resources should up in the RS results and Researcher notices these. For each such "find" researcher selects the item in the RS results, right-clicks and chooses "remember in VOSpace" from the right-click menu. This raises a "save-as" dialogue and Researcher chooses a directory in VOSpace in which to save.

Each saved item is a "bookmark" for the registered, archive data-set. It doesn't contain the data for the archive, but does (logically) contain the resource's metadata. They are a special type of VOSpace node and they have a distinctive icon in the VOSpace explorer.

For one of the bookmarked archives, Researcher right-clicks the node in the VOSpace explorer and selects "ADQL query" from the list of data-views. Workbench then runs the workbench task-launcher pre-loaded with the metadata for the archive; i.e. the table and column details are pre-loaded in the query pane and the science description is visible in the chooser pane. Researcher constructs the query. Researcher either runs the query directly or stores it elsewhere in VOSpace.

Later, researcher wants to run different queries against the same set of archives found in the RS sweep. The bookmarks in VOSpace are persistent, so Researcher builds the queries starting from the VOSpace nodes; Researcher doesn't need to repeat the RS operation.

Notes

DSA, the registry, the task launcher and the query builder don't change to support this. They don't know that anything special is happening.

The "magic" all happens in VOSpace and in the VOSpace browser. The space in which the bookmarks are stored needs to understand the bookmark node-type for DSA. The browser needs to understand it too. The VOSpace browser needs the code to invoke the launcher with pre-loaded resource data.

It's an open design choice whether the metadata passed to the launcher are stored (cached) in the VOSpace node, or whether the node looks them up by IVORN in the registry when triggered.

-- GuyRixon - 06 Sep 2006

Some followup thoughts re implementation

Stilts has basic functionality for ingesting VOTable via JDBC into a DBMS which we could use for a prototype (with OGSA-DAI as an alternative ingestion mechanism). I see two scenarios that might work (this is based on my assumption that we still have a FileManager^? that keeps track of where everything actually is):

Case 1 (simplest case)

• FileManager^? is configured with the location of a writable DSA (WDSA) to use for temporary tables

• VOSpace user interface provides means to trigger ingestion of VOTable into FileManager^?'s default WDSA

• WDSA provides interface to accept the VOTable, uses Stilts to ingest it. It tells the FileManager^? the name of the table it has created (or gives it some other unique identifier for that table in the DBMS), so that subsequent methods can be invoked upon that table.

• WDSA can use pre-existing "get template metadoc" functionality to auto-generate metadoc from the table, and then use pre-existing functionality to auto-generate TabularDB^? (and maybe CEA) resources from the metadoc. Then the QB can use these resources to build a query for that table (NB: this approach will provide only rudimentary metadata based on JDBC data types, and won't include original UCDs etc from the source VOTable).

• VOSpace user interface provides means to launch QB with resource entries extracted directly from WDSA rather than Registry (maybe small amount of QB work needed here); WDSA tables won't ever be registered in the formal sense as they are like filestore files, not "real" DSA permanent tables.

• Querying can then proceed as normal

Case 2 (slightly better case)

• As case 1, except that the VOTable header XML is stored in the WDSA in a second table linked by naming convention to the main data table for that ingested VOTable. The VOTable header is then used to provide the input for generating VOResource TabularDB^? entries so that the metadata is preserved (I hope this can be achieved by XSLT).

-- KonaAndrews - 13 Sep 2006