UCD for SIAP

[Doug Tody]

Roy -

I don't think we are actually very far apart on this.  The main thing I
am trying to do is determine how to deal with data models in DAL headers
such as for SIA.

An SIA contains two types of information all collected together in a flat
votable:

    - Attributes which are part of the SIA interface (e.g., AccessReference).

    - Attributes which are part of formal data models which are mapped
      into the columns of the table, e.g., BandPass, WCS.  The current
      SIA defines these as part of the interface but in principle what
      you see represents formally defined data models which are defined
      external to SIA.

The SIA interface attributes could use standard UCDs (e.g., DATA_LINK)
since the SIA interface is a controlled namespace and we can precisely
defined what UCDs mean when present in an SIA votable.

The data model attributes are something different.  In general we might
want to use any set of data models to define the attributes of a dataset
described by a DAL service.  A data model like BandPass or WCS should stand
on its own, and be reusable in various contexts, e.g., any DAL service,
or any VOTable (or VO-in-FITS) representation of a dataset.  If we map
the attributes of a data model into the columns of a VOtable (or the
keywords of a FITS header) then the attributes need to be uniquely named
so that they don't get confused with one another, so that we can verify
data model integrity (no missing required attributes), and so forth.

Some mechanism is needed to uniquely and unambiguously identify the
attributes of a data model in such a context.  It doesn't have to be the
UCD, but this seems to be a natural extension of the UCD concept and usage.

Your suggested UCDs for BandPass are close to what is needed, since they
are basically direct one-to-one mappings of the data model attributes.
We just need to go one step further and define a formal relationship between
such UCDs and data model attributes.

I went back and looked at your slides from the IVOA workshop again to see
what I could learn.  The summary slide goes like this:

    UCD is inherently fuzzy
    UCD is a description, not a unique name
	...
    UCD will be eventually replaced by
	"pointers into data model"

It seems to me this is exactly what we have been talking about.
Conventional UCDs are fuzzy tags used to associate similar data elements.
If we use a UCD to tag an attribute of a data model this UCD is a **pointer
into a data model**.  If we then go and look up the definition of this
data model, it may state that the pointed-to DM attribute in turn has a
UCD defining its "type", allowing it to be associated with other similar
data elements in the more conventional UCD way.

It is not clear if UCDs really need to be replaced by a new scheme
providing pointers into data models - they come pretty close to this
already.  This is what SIA is trying to do; some such scheme is needed
to represent data models in DAL protocols like SIA, even for these early
versions.

Well that's it for me for a while as I am about to leave on travel.
I do think we are close to resolving this, and maybe even taking a
step forward towards integrating data models and metadata via UCDs.
We would like to do something more standard for these new "data model"
UCDs in the upcoming DAL interfaces.

	- Doug






On Tue, 17 Jun 2003, Roy Williams wrote:

> One of my actions as part of the UCD steering committee is to work with the
> "VOX" new UCDs that were created for the SIAP protocol.
> 
> Below, I have listed all of the VOX UCDs that could find in the SIAP
> definition, with a little bit of the description. I have tried to find an
> equivalent in the standard UCD set, and in many cases was successful. For
> example is there a reason for VOX:Image_AccessReference as a new UCD, why
> can't we simply use DATA_LINK from the existing set? This is why it says
> "**existing: DATA_LINK" for that entry.
> 
> Of course, there will a revision when we steel on the "base+modifier" scheme
> for UCD that we decided in Cambridge.
> 
> Please can some of you look at the suggested equivalents fron the exisiting
> set, and the suggested new UCDs in the listing below? We gain
> interoperability from reusing and following the existing tree -- but do we
> lose anything?
> 
> Thenk You
> Roy
> 
> --------
> Caltech Center for Advanced Computing Research
> roy at cacr.caltech.edu
> 626 395 3670
> 
> VOX:Image_Title
> ** existing: ID_IMAGE
> containing a short (usually one line) description of the image.
> 
> VOX:Image_MJDateObs
> ** existing: TIME_DATE
> with datatype="double", representing the mean modified Julian date of the
> observation.
> 
> VOX:Image_Naxes
> ** new: POS_TRANSF_WCS_NAXES
> specifying the number of image axes.
> 
> VOX:Image_Naxis
> ** new: POS_TRANSF_WCS_NAXIS
> NOTE: Can a UCD refer to an array like this?
> with the array value giving the length in pixels of each image axis.
> 
> VOX:Image_Scale
> ** new: POS_TRANSF_WCS_CDELT
> NOTE: Can a UCD refer to an array like this?
> with the array value giving the scale in degrees per pixel of each image
> axis.
> 
> VOX:Image_Format
> ** new: DATA_TYPE_MIME
> specifying the MIME-type of the object associated with the image acref,
> e.g.,  image/fits", "text/html", and so forth.
> 
> VOX:STC_CoordRefFrame
> ** existing: ID_FRAME
> representing the coordinate system reference frame, selected from "ICRS",
> "FK5", "FK4", "ECL", "GAL", and "SGAL".
> 
> VOX:STC_CoordEquinox
> ** existing: TIME_EQUINOX
> representing the Equinox (not required for ICRS) of the coordinate system
> used for the image world coordinate system (WCS).
> 
> VOX:WCS_CoordProjection
> ** new: POS_TRANSF_WCS_CTYPE
> with the array value being the three-character code ("TAN", "ARC", "SIN",
> etc.)
> 
> VOX:WCS_CoordRefPixel
> ** new: POS_TRANSF_WCS_CRPIX
> with the array value specifying the image pixel coordinates of the WCS
> 
> reference pixel. This is identical to "CRPIX" in FITS WCS.
> 
> VOX:WCS_CoordRefValue
> ** new: POS_TRANSF_WCS_CRVAL
> with the array value specifying the world coordinates of the WCS reference
> pixel. This is identical to "CRVAL" in FITS WCS.
> 
> VOX:WCS_CDMatrix
> ** new: POS_TRANSF_WCS_CD
> with the array (matrix) value specifying the WCS CD matrix.
> 
> VOX:BandPass_ID
> ** existing: INST_FILTER_CODE
> identifying the bandpass by name (e.g., "V", "SDSS_U", "K", "K-Band", etc.).
> 
> VOX:BandPass_Unit
> ** existing: UNITS -- but should be GROUPED with Bandpass
> identifying the units used to represent spectral values, selected from
> "meters", "hertz", and "keV".
> 
> VOX:BandPass_RefValue
> ** new: INST_FILTER_REF
> specifying the characteristic (reference) frequency, wavelength, or energy
> for the bandpass model.
> 
> VOX:BandPass_HiLimit
> ** new: INST_FILTER_MAX
> specifying the upper limit of the bandpass.
> 
> VOX:BandPass_LoLimit
> ** new: INST_FILTER_MIN
> specifying the lower limit of the bandpass.
> 
> VOX:Image_PixFlags
> ** existing: CODE_MISC
> specifying the type of processing done by the image service to produce an
> output image pixel. The string value should be formed from some
> 
> combination of the following character codes: C, F, X, Z, V
> 
> VOX:Image_AccessReference
> ** existing: DATA_LINK
> specifying the URL to be used to access or retrieve the image.
> 
> VOX:Image_AccessRefTTL
> ** existing: TIME_DELAY
> specifying the minimum time to live in seconds of the access reference.
> 
> VOX:Image_FileSize
> ** new: DATA_SIZE
> representing the actual or estimated size of the encoded image in bytes (not
> pixels!).
> 
>