Metadata tree Some documentation for a metadata-tree ====================================== Mark Allen and François Bonnarel Version 0.0
Francois Bonnarel
bonnarel at alinda.u-strasbg.fr
Fri Apr 11 16:37:04 PDT 2003
Introduction
============
Browsing and visualization of image datasets will be an
important part of Virtual Observatory operations. Such
datasets may range from a small set of images stored on
a local disk, to the terabyte collections of modern
surveys made accessible via various Web Services. Standardized
and scalable descriptions of image metadata will be required to
enable dataset browsing, selection and visualization.
The Metadata Tree that was developed for the AVO 1st year
demonstration represents a prototype implementation of a
scalable, hierarchical metadata description (in VOTABLE/XML)
of an image dataset. This component of the AVO prototype was built as
a customization of the Load feature of the Aladin sky atlas,
and was designed specifically for the GOODS dataset. Using a
VOTABLE description, it displays a tree view of the data available
within a specified region (or range of parameters), allows display
of fields-of-view outlines, and provides feedback between the tree
and visualization window. The metadata description includes the
location and retrieval parameters for the data, in the case of
GOODS this was basically a http-get template for the GOODS data server
at the CDS.
Following user feedback on the Metadata Tree component of the
AVO prototype it was decided to implement a generalized Metadata
Tree function in the public version of the Aladin sky atlas
(version 1.5 ?). This allows description of other datasets (local or
remote) in the same way as was done for the GOODS dataset, so
that they have similar functionality within Aladin.
This document outlines how to define a VOTABLE description
of a dataset for use with Aladin.
Relationship to the IDHA Data Model
===================================
The metadata description of the GOODS data used for the AVO
demo was based on a generic description of astronomical data
being developed by the IDHA data model project. The goal of the
IDHA data model project is to describe the information content
of image archives and datasets. In the IDHA data model the
metadata are coded as objects, with logical links between them.
The graph of the IDHA data model is shown at
http://alinda.u-strasbg.fr/IDHA/lastmodel.
While the use of the data model is not required to generate
the VOTABLE for a general dataset, it is instructive to see how
the general form of the VOTABLE description relates to the data
model graph. Various tree structures may be extracted from the model
graph. In general this is done by starting at a node, and following
various links, avoiding reverse and circular links. In the case of
GOODS, the tree was chosen with a hierarchy organized in terms of:
ObservingProgram - ObservingGroups - ProcessedObservations
This can be described as one "view of the data model",
but it is also possible to use the model to define trees with
different hierarchies, and different starting points. For example
by starting from ProcessedObservation one may generate a tree
that has branches describing the instrument used, and the observing
conditions etc.
VOTABLE description of a dataset
================================
Here we describe in detail how to structure a VOTABLE description
of a dataset for use with the Aladin Metadata Tree. VOTABLE has the
capability of describing not only flat table structures, but can also
describe a hierarchical tree. The Metadata Tree is expressed in VOTABLE by
recursive use of the <RESOURCE> element. Each <RESOURCE>
element represents a node of the tree. The children of the nodes appear
as new <RESOURCE> elements included in the previous one.
NODES
-----------
In this description we make use of three different kinds of nodes:
"ObservingProgram", "ObservationGroup", and "ProcessedObservation".
These relate to parts of the data model with the same name.
"ObservingProgram" nodes are intended to be the root nodes. Several root
nodes may occur in a single document.
"ObservationGroup" nodes are the children of "ObservingProgram" nodes,
or other "ObservationGroup" nodes. These nodes are intended to be the
main way of subsetting the dataset into a hierarchy.
"ProcessedObservation" nodes are children of the "ObservationGroup"
nodes and are intended to contain the description of a subset of the
image metadata that will be useful to display, for example field
centre coordinates and sizes. This is intended for information relevant
to an Astronomer.
"StorageMapping" nodes are linked to the "ProcessedObservation". They are
intended to contain detailed metadata about the images that are required
for using the images in an interface.
NODE ATTRIBUTES
-------------------------------
The attributes of a node are defined within the <TABLE> part of the
<RESOURCE> element. Each attribute of the model class is
coded as a <FIELD> in the <RESOURCE>.
The use of these attributes is necessary to enable the full functionality
of the Metadata Tree within Aladin. The tree will however minimally
function provided the main node definitions are included.
We now provide a list of the attributes we are using, and define them
as recommended or optional.
For ObservingProgram, the <FIELDS> or attributes are:
* Name (recommended), the ObservingProgram Name.
* Organisation(optional), the Name of Organisation(s) performing Observing Program
* Begin(optional), the Begin date of the survey
* End(optional), the End date of Observing program
* SpectralDomain(recommended), the General spectral domain (Optical X-ray ...)
For Observation_group, the <FIELDS> or attributes we have are:
* Selection_Criterion(recommended), for the Sampled parameter.
A sampled parameter can be any attribute of any class of the data model
considered useful. For example: Filter name (or filter range),
epoch of observation, Polarizer state, etc ...
* Selection-Range(recommended) , the Constraint on the sampled parameter
For Processed Observation, the <FIELDS> or attributes we have are:
* Observation_Name(recommended) , the name of the Observation
* ReferenceNumber (optional), an internal or reference number of the Observation
* Size_alpha (recommended), the Bounding box size including the observation
in Right Ascension
* Size_delta (recommended), the Bounding box size including the observation
in Declination
* PixelSize (recommended), the Pixel size measured in sky units.Actual unit
(arsec,arcmin,deg)is given in the FIELD definition.
* Origin (optionnal), the Organism who provided the data.
* OriginalCoding (optional), the image format provided
* AvailableCodings (optional), for the possible codings of these data in request
* alpha(recommended), the RA Position of center
* delta(recommended), the DEC Position of center
* Position Angle, the Position Angle of the Observation Y axis East of
North
The meaning of all the attributes will be clarified by an
annotated example, which will be available soon.
DATA LOCATION
----------------------------------------------------
The data location parameters are set within the StorageMapping
<RESOURCE> element. The attribute (<FIELD>) is Location,
the value of which can be a file path, an URL or a GLU mark.
The file path is intended for referring to local files only.
Each file path must be preceded by "file:"
URL and Glu Marks are intended to provide access to remote files.
Glu marks are prececed by "glu:" The Glu marks allow for inclusion
of parametrized URL templates. To enable this facility the service
needs to be registered in a GLU database.
=====================================================================
Francois Bonnarel Observatoire Astronomique de Strasbourg
CDS (Centre de donnees 11, rue de l'Universite
astronomiques de Strasbourg) F--67000 Strasbourg (France)
Tel: +33-(0)3 90 24 24 11 WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25 E-mail: bonnarel at astro.u-strasbg.fr
---------------------------------------------------------------------
More information about the dm
mailing list