UCD for SIAP

[Doug Tody]

Roy -

Certainly we can replace the VOX: namespace UCDs with global UCDs, so
long as we are willing to make up new UCDs where needed.  This might be
a good short-term solution.

The key problem I see with trying to use existing UCDs is that historically
UCDs have been used primarily as fuzzy tags to link similar fields in
catalogs.  In data access metadata such as is introduced in SIA we are
using UCDs to identify the fields of a formal data model.  Here the tag
is not fuzzy at all, linking similar fields of unrelated catalogs, rather
it is a link to a field of a formally defined data model.  Precision is
important for these data models - we are precisely defining attributes
of the data model.

We should formally define data models such as spectralBandpass or WCS
and define, as part of the data model, the UCD tag used to identify an
attribute of the data model.  When we represent a data model as a set of
related columns in a table, or as an entity struct in XML (as in IDHA or
HDX), we will use the UCDs to formally type the data model attributes so
that programs can use them unambiguously, so that we can use XML Schemas
for automated validation, and so forth.

This one-to-one mapping of UCDs to formal data models is a concept that
does not currently exist in UCDs.  If we try to take a more classical
UCD-like approach and use UCDs to associate "similar" fields of different
data models, then we no longer have a precisely defined data model.
This association of "similar" fields of different data models should occur
in the data model definitions, where data models may define attributes
in terms of more fundamental data models or quantities.

Some more specific comments based on your proposed UCDs.  I haven't tried
to be complete, these are only examples.

> 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 would work if we have only one DATA_LINK in an interface such as
SIA, and we define that within this particular interface, DATA_LINK means
the formally defined SIA Image_AccessReference.  If for some reason we
have two DATA_LINK attributes then we are in trouble, as the type is
then overloaded and the meaning is ambiguous.  The problem with what you
suggest is that we are inherently overloading the type.  It might work
for a while, but will cause a problem in the future if we apply the same
logic to a similar attribute.  Since the attribute is precisely defined
we gain nothing by using a fuzzy tag.

> 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.

This sort of mapping of the WCS data model onto "standard" UCDs (if
newly defined) is certainly possible, so long as we define these tags as
part of the WCS data model.

However, the geometry of an image (NAXES, NAXIS) is not really part of
the WCS - these are image attributes (in FITS they existed long before WCS).
A WCS is associated with an image.  CDELT, FRAME, etc., are part of the WCS.

Do we need an image geometry data model?  A general image attributes
data model?  NAXES, NAXIS are clearly (or shall we say, clearly should be)
precisely defined terms of some formal image data model.

> VOX:BandPass_ID
> ** existing: INST_FILTER_CODE
> identifying the bandpass by name (e.g., "V", "SDSS_U", "K", "K-Band", etc.).

BandPass is a more general concept that "instrument" or "filter".  Filters
and instruments are examples of specific entities that have a bandpass.
"bandpass" should be a formal data model with "bandpass"-specific attributes
(UCDs).

> 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".

What do you do once there are two data models both of which need to define
their units?  GROUPED above, whatever that is, may address this, but it
is better to have an explicit, unambiguous attribute.  The units have to be
precisely defined.  The data model could define a default if this parameter
is absent.

> 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

What do you do as soon as there are two fields with UCD=CODE_MISC in the
metadata?  In the current SIA, the implication is that Image_PixFlags is
an attribute of some sort of "image" data model used in SIA, hence it has
a precise definition.

Similar comments apply to other UCDs where we confuse UCD associations
with data model terms.

I think it would help a lot if we just took one of these simple data
models, e.g., spectralBandpass, and formally defined it, with UCDs
assigned to identify attributes.  Then we could use the same approach
to define all the other SIA image attributes, grouped by data model.
Later perhaps we can show how to define data models in terms of other
data models or ultimately Quantities, to fully define complex data objects
via a hierarchy of formal definitions.

	- Doug