Use case analysis for handling data cubes in VO
bonnarel at newb6.u-strasbg.fr
Mon Mar 27 09:02:48 PST 2006
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
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").
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
List of items
URL, URI, etc...
as in SSA
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)
size in bytes
as in SSA
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 ...
FullDataSet, Cutout, Reprojection,
as developped in Doug's document
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
free string: eg "Full retrieval" , Preview, "Deconvoluated Image"
What the Views are intended to be used to in the discovery/access process.
True would allow direct retrieval while false would initiate a new
We think we can distinguish between several subtypes of "projection"
including some kind of processing:
Registering/Resampling, Mosaicing, Deconvolution, Filtering,
Can Deconvolution, filtering and Segmentation be seen as special
case of projection ?
Or should we group them in a 4th category: let say "Processing"
Transform /Generation Parameters dependancyFullDataSet: none
Cutout: location, bounds
Resampling: sampling, kernel
Mosaicing, location, bounds, wcs, sampling, kernel
Deconvolution; resolution, 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
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9363 bytes
Desc: not available
More information about the dm