Use case analysis for handling data cubes in VO

[François Bonnarel]

In this mail we would try to give hints of what could
be an AccessAndViews Data model for the IVOA, to be used for
example in DAL protocols.
    What is the context:
     a ) there has been discussions in the DM group, specifically
within the scope of Observation DM about the need to describe
"Missing Practical Stuff" such as Packaging of the data, physical
organisation, and various views of the same generic dataset.
This discussion remained idle since the Boston/Cambridge
interoperability meeting two years ago (see
http://www.ivoa.net/Documents/latest/DMObs.html)
After Boston this discussion stopped on that point has been delayed
as people were involved in different prioritary projects.
     b ) The discussion on such matters gets a new birth within the
scope of the discussion on 3D data handling. We (ML+FB) fully agree
with the concepts developped by Doug in his "Access to 3-D/N-D Image
Data in the VO" document. We had a little  offline discussion with
Doug on that before  posting this to both DM and DAL list.
       What we strongly support is:
       -  The idea of describing the access modes to a dataset.
       -  The concept of generic dataset discovery.
     (By the way, ideas like that were in the background of various
experimental protocols we have been working on, such as
  IDHA format and some use-cases and implementations  of the
SIA+Extension mechanism eg the CGPS archive navigator)
     c ) SSA > 0.9 describes the metadata structured in packages
which belong to various data model. It contains a small Access
package with three items (Reference, format and size).
      What we propose here is a small AccessAndViews model used in place
of the Acces  package in the case of Generic Dataset Discovery ("GDD"). 
This model
could be used in defining both new  Query response  fields of the "GDD"
and new Input parameters for DAL protocols such as SIA and SSA.
      Of course the use of this model is not restricted to the definition
of utypes in DAL/VOTABLE protocols. It could also be used in other
contexts
List of items
--------------

AccessAndViewsReference:
URL, URI, etc...
as in SSA

AccessAndViewsFormat:
mime/type image/fits image/jpeg spectrum/fits
spectrum/votable spectrum/xml text/ascii text/html text/xml
text/votable (etc ...)
as in SSA (more values)

AccessAndViewsSize:
size in bytes
as in SSA

AccessAndViewsProductType:
cube, image, spectrum, catalog, metadata
Different from the DataSetType of the DataSEt itself, because it
is the  Type of the Specific view. It includes also catalog, as a
result of source extraction and metadata to allow the retrieval of
full metadata descriptions such as characterisation ...

AccessAndViewsTransform:
FullDataSet, Cutout, Reprojection,
as developped in Doug's document

AccessAndViewsGenerationParameters:
location, bounds, wcs, sampling, resolution, kernel
  These parameters, similar to the Image Generation Parameter
  are necessary to generate a real view according to a specific
transform. The exact list is dependant on specific transforms

AccessAndViewsRoleName:
free string: eg "Full retrieval" , Preview, "Deconvoluated Image"
What the Views are intended to be used to  in the discovery/access process.

AccessAndViewsRetrieval:
true/false
True would allow direct retrieval while false would initiate a new 
"query response"


Reprojection types
_________________
We think we can distinguish between several subtypes of "projection"
including some kind of processing:
Registering/Resampling,  Mosaicing, Deconvolution, Filtering,
Segmentation ...

Can Deconvolution, filtering and Segmentation be seen as special
case of projection ?

Or should we group them in a 4th category: let say "Processing"
or "Interpretation"?

Transform /Generation Parameters dependancyFullDataSet:   none
Cutout: location, bounds
Registering: wcs
Resampling:   sampling, kernel
Mosaicing, location, bounds, wcs, sampling, kernel
Deconvolution; resolution, kernel
Filtering: kernel
Segmentation: ad hoc parameters of the dedicatec algorithm?


You can find attached a small UML diagram for this little model.


_______________________________________________________________



A little possible scenario:

       "Complex data" such as data cubes (or any kind of data where
several views of the same dataset can be retrieved) will be
installed in GenericDatasetDiscovery services.
      A request to such a service will isuue a RESPONSE where the first
RESOURCE contains the description =
curation, characterization, Dataset Type and Dataset ID,
and access method to the full dataset (at least, WCS may also
be added)

     A second table will give several rows for each
dataset describing each of the possible access modes or partial
views to this dataset (available "transform", transform parameters, etc ...
using there the attributes of our small model to define the various
views.
Each row will contain the access service URL for each specific view, 
which will be a standard SIA or SSA service.
     According to the "transform" associated to this specific access
the URL will need various transform parameters and Image(or spectrum)
Generation Parameters. All these will be standardized by the SIA and
SSA and deduced from the transform according to the model.
The range of possible values for these IGP can be inferred from the
characterization of the Generic dataset.
     Client software would be able to use these access metadata
and  generate appropriate requests to retrieve a single
dataset.
    As mentionned before 2 options could be envisionned for retrieval:
     By default (or with rerieval= false) this query will retrieve an 
SIA/SSA query response. But with a retrieval=true parameter it will 
instead retrieve directly the view.


Mireille Louys
François Bonnarel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: access3.gif
Type: image/gif
Size: 9363 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/dal/attachments/20060327/f6d4fae9/attachment-0001.gif>