VOEvent References (fwd)

[Douglas Tody]

Note there is a discussion of classifying/describing science data
products currently underway on the voevent list, which is similar to
what we are currently looking at for ObsTAP.  I am forwarding the
response I just posted (I didn't want to start a thread copied to all
three lists!).  - Doug


---------- Forwarded message ----------
Date: Mon, 21 Mar 2011 13:53:52 -0600 (MDT)
From: Douglas Tody <dtody at nrao.edu>
To: Steve Allen <sla at ucolick.org>
Cc: IVOA semantics <semantics at ivoa.net>, IVOA VOEvent List <voevent at ivoa.net>
Subject: Re: VOEvent References

Hi All -

I'll just note that we are discussing much the same thing currently in
connection with ObsTAP, used to index science data products in an
archive.  The solution we are currently looking at is similar to what
has been described here, i.e., there are separate science types and file
format types used to describe each data product (reference in the case
of voevent).  In our case the science type is broken into two levels,
one of which (the data product type) is a controlled vocabulary and the
other (subtype) is, for now at least, left up to the data provider since
we can't hope to classify all the data in science archives any time
soon.  If someday there were a more comprehensive vocabulary of science
types then the value of subtype could for example get an "ivoat:" prefix
without changing the scheme or the ability of data providers to define
their own custom values until the formal vocabulary gets expanded.

I do think we should get a formal MIME type for VOTable, however this
would not solve the problem of describing the science type.

There is a gray area where the file format is tied up with the science
type.  For example the same radio visibility dataset could be in ASDM
format, SDFITS format, or others.  We are still looking at what to do
about this, e.g., do we fold this into the science type, or further
qualify the file format.

 	- Doug


On Mon, 21 Mar 2011, Steve Allen wrote:

> On Mon 2011-03-21T18:32:04 +0000, Norman Gray hath writ:
>> That perhaps indicates where the boundary is between @mimetype and
>> @sciencetype -- it's at some boundary between the details of the
>> interaction, and the meat-and-potatoes of the application.  In your
>> example of a CelestiaObjectDescriptionFile, the important thing for
>> the application is that this is a CelestiaObjectDescriptionFile.  It's
>> not a simulation which just happens to be encoded in that format,
>> which can therefore be abstracted away in the way that GIF vs PNG can
>> be abstracted away -- the fact it's in that format is of significance
>> to the meat-and-potatoes level of the application.
> 
> In the production of the FITS MIME RFC it became clear that we were
> only able to document syntax and not semantics.
> 
> Type image/fits only says that there should be a data array, not
> whether the data are from X-ray, radio, optical, simulation, or a
> pocket camera which took a family portrait.
> 
> Type application/fits does not say, e.g., that the content might be a
> bunch of tables in third-normal-form which describe the manufacture of
> a slitmask that was used to acquire the spectra in the IMAGE extensions.
> 
> It became clear that the MIME media type could not advise on what sort
> of things were to be done with the images and/or tables; it could not
> say what was intended to be communicated by the file.  If that is to
> be generally described by a FITS file then more conventions for
> keywords are needed.  If specific cases are to be described by MIME
> then a standards document defining those conventions can be used to
> register a new MIME media type with semantics as well as syntax.
> 
> --
> Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
> UCO/Lick Observatory--ISB   Natural Sciences II, Room 165    Lat  +36.99855
> 1156 High Street            Voice: +1 831 459 3046           Lng -122.06015
> Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m
>