UTYPEs for SIAP
Jonathan McDowell
jcm at head.cfa.harvard.edu
Wed Mar 31 16:35:22 PST 2004
SIAP UTYPES
Here I propose possible UTYPE values for SIAP, as a first attempt
to address how one might represent data model information in VOTABLE
using the proposed UTYPE mechanism.
SIAP is the Simple Image Access Protocol http://www.us-vo.org/news/simspec.html
This discussion arose out of evaluation in the NVO metadata telecon
of proposed UCD1+ assignments to SIAP, which I mostly liked but
threw a monkey wrench by insisting that not all 'wcs' came under
'pos' and that not all SIAP returns necessarily would have only
RA/Dec axes. I emphasize that the UTYPE discussion here is NOT
meant to replace the UCD1+. However I think that in the particular
case of SIAP some of the metadata (WCS values, etc) make more
sense as UTYPEs, and some (time.epoch, etc.) are most usefully
described by UCDs - which is just to say that some of the SIAP
metadata describes the structure of the data, and some describes
the physics. I think the fact that SIAP is *mostly* (and unusually
compared to many VO applications) describing purely structural
dataset stuff and not astronomy stuff somewhat obscures the
distinction in roles between UCD and UTYPE in this example,
leading to Roy's concern expressed at the bottom of this message.
An SIAP VOTABLE represents a set of observations - specifically
n-dimensional images. In the DM this is represented by the Observation
data model. While this model is still under construction, its current
version (obs.v0.2.pdf at http://www.ivoa.net/twiki/bin/view/IVOA/IvoaDataModel)
is sufficiently developed that we can easily map SIAP to it.
In the UTYPE column below, I use a path syntax to
fully identify an attribute within a class instance in the model.
It's possible that we might implement the VOTABLE using <GROUP>
so that only the last element of the path is actually needed
in the UTYPE. I emphasize that while the DM group has discussed
the elements of the Observation model used here, we have not
discussed the syntax for UTYPE entries and what I've done here
is a placeholder.
One comment that I have is that the DM mapping makes clear
a few things that are missing, or at least assumed, in the SIAP
scheme, for example:
- obs/data/ucd What is the observable in the image?
- obs/data/axes/mapping/name ) What are the axes of the image?
- obs/data/axes/mapping/ucd )
It also makes clear that some things are missing in the current
Observation data model, specifically things to do with
the actual computer encoding of the bytes. I have added 'dataset'
UTYPEs as placeholders. I think it's nice that we separate
the physical dataset representation from the logical scientific
content.
UCD1 UCD1+ UTYPE?
VOX:Image_Title meta.title obs/name
INST_ID meta.id;instr obs/provenance/obsconfig/instrument/name
VOX_Image_MJDateObs time.epoch obs/coverage/time/location
POS_EQ_RA_MAIN pos.eq.ra obs/coverage/pos/location[0]
POS_EQ_DEC_MAIN pos.eq.dec obs/coverage/pos/location[1]
VOX:Image_Naxes wcs.naxes? obs/data/naxes
VOX:Image_Naxis wcs.naxis? obs/data/naxis
VOX:Image_Scale wcs.scale? obs/data/axes/mapping/wcs/scale
VOX:Image_Format meta.code.mime dataset/mime
VOX:STC_CoordRefFrame pos.frame obs/data/axes/frame/coordsys/type
VOX:STC_CoordEquinox time.equinox obs/data/axes/frame/coordsys/equinox
VOX:WCS_CoordProjection wcs.ctype? obs/data/axes/mapping/wcs/type
VOX:WCS_CoordRefPixel wcs.crpix? obs/data/axes/mapping/wcs/crpix
pos.pixel?
VOX:WCS_CoordRefValue wcs.crval? obs/data/axes/mapping/wcs/crval
pos.eq?
VOX:WCS_CDMatrix wcs.cdmatrix? obs/data/axes/mapping/wcs/cd
VOX:BandPass_ID instr.bandpass obs/coverage/wavelength/ucd?
and/or obs/provenance/obsconfig/filter/name
VOX:BandPass_Unit meta.unit obs/coverage/wavelength/unit
VOX:BandPass_RefValue em.wl obs/coverage/wavelength/location
VOX:BandPass_HiLimit em.wl;stat.max obs/coverage/wavelength/bounds/min
VOX:BandPass_LoLimit em.wl;stat.min obs/coverage/wavelength/bounds/max
VOX:Image_PixFlags meta.code dataset/?
VOX:Image_AccessReference meta.ref.url dataset/url
VOX:Image_AccessRefTTL time.interval;stat.min dataset/persistence
VOX:Image_FileSize phys.size;meta.file dataset/size
The 'mapping/wcs' can probably be shortened to 'wcs', with wcs considered
as a subclass of Mapping.
Also note that 'obs/coverage/wavelength' is not a fundamental element of the
data model; it's a shorthand for (or derived class from)
'obs/coverage/axis', together with the restriction
'obs/coverage/axis/ucd = em.wl'. A more robust way of handling this
might be to add new metadata to the table, and render the UTYPEs as follows:
UCD1 UCD1+ UTYPE?
VOX:Image_Title meta.title obs/name
INST_ID meta.id;instr obs/provenance/obsconfig/instrument/name
- - obs/data/axis[0]/ucd = pos.eq
- - obs/coverage/axis[0]/ucd = pos.eq
- - obs/coverage/axis[1]/ucd = time
- - obs/coverage/axis[2]/ucd = em.wl
VOX_Image_MJDateObs time.epoch obs/coverage/axis[1]/location
POS_EQ_RA_MAIN pos.eq.ra obs/coverage/axis[0]/location[0]
POS_EQ_DEC_MAIN pos.eq.dec obs/coverage/axis[0]/location[1]
VOX:Image_Naxes wcs.naxes? obs/data/naxes
VOX:Image_Naxis wcs.naxis? obs/data/naxis
VOX:Image_Scale wcs.scale? obs/data/axes/wcs/scale
VOX:Image_Format meta.code.mime dataset/mime
VOX:STC_CoordRefFrame pos.frame obs/data/axes/frame/coordsys/type
VOX:STC_CoordEquinox time.equinox obs/data/axes/frame/coordsys/equinox
VOX:WCS_CoordProjection wcs.ctype? obs/data/axes/wcs/type
VOX:WCS_CoordRefPixel wcs.crpix? obs/data/axes/wcs/crpix
VOX:WCS_CoordRefValue wcs.crval? obs/data/axes/wcs/crval
VOX:WCS_CDMatrix wcs.cdmatrix? obs/data/axes/wcs/cd
VOX:BandPass_ID instr.bandpass obs/coverage/axis[2]/ucd?
and/or obs/provenance/obsconfig/filter/name
VOX:BandPass_Unit meta.unit obs/coverage/axis[2]/unit
VOX:BandPass_RefValue em.wl obs/coverage/axis[2]/location
VOX:BandPass_HiLimit em.wl;stat.max obs/coverage/axis[2]/bounds/min
VOX:BandPass_LoLimit em.wl;stat.min obs/coverage/axis[2]/bounds/max
VOX:Image_PixFlags meta.code dataset/?
VOX:Image_AccessReference meta.ref.url dataset/url
VOX:Image_AccessRefTTL time.interval;stat.min dataset/persistence
VOX:Image_FileSize phys.size;meta.file dataset/size
This isn't so intuitive: perhaps we need to use the first version and
add something like
<parameter name="coverage" utype="obs/coverage" size=3>pos, time, wavelength</parameter>
to let the code recognize that "wavelength" is to be understood as
"axis[2]" of the coverage object when parsing later utypes.
--
This generated from Roy:
> Haven't you just made an alternative set of UCD?
No, I don't think so. They do different things.
A UCD will tell you "This is a wavelength".
A UTYPE will tell you "This is the 2nd axis of an array, and if you
look over here I will tell you its UCD, which in this case happens
to be wavelength".
One is about what physics it is, and the other is about what role
it is playing.
Having done this and similar exercises recently
has convinced me much more strongly that we need both.
The fact that the data models need UCDs in various places,
such as my example of "is this spectrum <luminosity vs frequency>
or <surface brightness vs wavelength>" says to me that UCDs and
data models are not the same thing, but in fact desperately
need each other in a very interrelated way. The UCDs distinguish
between identical data model instances representing different
physics, and the data models say whether a particular UCD is
being used as a value, an array axis, a table column, etc. as
well as (once we define the models down to that level) saying
what properties are associated with a UCD (a quantity whose
UCD is phot.flux better have some kind of em.{wl,freq,energy}
associated with it).
I think the latter use case is much closer to having a danger
of reinventing UCDs, but as I argue in the previous message,
the way to serialize such models is exactly to use the UCD,
rather than have separate UTYPEs.
Bottom line: once we have a good set of data models and corresponding
UTYPEs, if we did not also have UCDs we would have to invent them.
- Jonathan
More information about the dm
mailing list