[QUANTIT] Use-cases, role in larger scheme (Was: Re: [QUANTITY] Quantity "arguments")

[Doug Tody]

Brian -

Indeed top level applications like this are where we should start with
VO use-case analysis.  A first iteration on this has already been done:
case 1 below is one of the NVO use cases which led to the cone search and
SIA services (to get catalog and image data) and to what is now called
the 'DIS' (data inventory) service from HEASARC.  The GRB use case is
not really a use case for quantity, but if we descend far enough into
the VO we will eventually get to concepts like UCD and quantity which
should provide a means to define the fundamental physical attributes of
the data we are dealing with.

Much of the top level use-case analysis has already been done and we are to
the point now where we have a service architecture and are looking at the
details of data queries, data modeling, data representation and mediation
to external data.  What is needed is to work out and document the data
model-based data access architecture at this level, showing how we model
actual datasets down to the level of abstract component data models and
representations in XML or other formats.  This is hard and will take time,
so we have been working at it both top down (by refining our distributed
VO application prototypes and demos) and bottom up (by trying to define
component data models and data representation technology like VOTable).

Probably it will be difficult to make any real progress on 'quantity'
until the architecture it fits into has been clarified so that we know
how it will be used.  To continue with this now the best strategy might
be a simple prototype of some sort that is usable as a component (i.e.,
the bottom-up approach).

	- Doug


> > Component-level requirements are needed, but we need to back up one
> > step further and define an architecture which lays out what the data
> > model components (such as quantity) are, and what their role is in some
> > larger scheme. 
> 
> Ok, towards that end, I present 2 use-cases, with starting thoughts on
> how these produce requirements which indicate a need for a quantity.
> 
> The following 2 use-cases were taken from the NVO SWG list.
> 
> I have put comments following each use-case indicating as to how this
> pertains to quantity.
> 
> 2-use cases for "quantity", based on search scenarios:
> 
> -----------------------------------------
> 1. GRB follow-up service
> 
> - Upon a receipt of a GRB detection message (from GCN, SAX, HETE,
> Swift...):
> 
> - Grab the image and catalog data from all linked archives covering the GRB
> error box
> 
> - Cross-match any sources in this set
> 
> - Identify possible permanent-but-variable sources (i.e., not 1-time
> transients) in this area from multiple observations at the same (+-)
> wavelengths (e.g., optical, others if available)
> 
> - Prepare the finding charts with all the sources labeled, links to the
> pertinent info
> 
> - Have it all on a website
> 
> - Email to the subscriber list that this is available
> 
> - Update as more data come in
> -----------------------------------------
> 
>     [Brian] :
> 
>     In this use-case, there is a requirement to be able to search for,
>     and aggregate, information across different archives that have data
>     within the GRB error box. Each archive may have differing means
>     of holding the information, (as mentioned "image" or "catalog")
>     and we want to cross-correlate any "sources" that match our search.
> 
>     This use-case, taken strictly, at a minimum, this means that there
>     must be well-described 'catalog' and 'image' structures out of
>     which the search may pull 'data'. In order to do the cross-match
>     scientifically, (by a central service, or the user) we will need to
>     insure that in matching data the units are kept correct, that errors
>     are propagated correctly, and that we can read this data. It would
>     be desirable that the 'catalog' and 'image' formats share the same
>     standard for describing this basic data (e.g. units/accuracy/type)
>     in order to facilitate the cross-match fusion.