utype questions

[Doug Tody]

On Tue, 12 May 2009, Roy Williams wrote:

> Here, for example, is some toy code from a VOTable application that is 
> expecting a time series, and is therefoe looking for the FIELD which is the 
> observation time:
>
>    if FIELD.ucd.containsString("time.epoch")
>    or 
> FIELD.utype.containsString("Spectrum.Char.TimeAxis.Coverage.Location.Value")
>    or FIELD.units.containsString("ISO8601")
>    or FIELD.representation.containsString("STC-S"):
>      print "Found FIELD with observation time"

This is not a utype issue, rather it merely reflects the lack of a well
defined data model in the data you are manipulating.  You are trying
to make it accept a variety of input data.  If this was instead a well
defined data model with mandatory utypes (SSA/Spectrum for example),
then you could just look for the utype and life would be simple.

A related issue is long utypes which I alluded to in my previous mail,
suggeting that in a controlled context shorter tags can be used hence
applications would rarely see the full utype string.  What one can do
for example, is something like this:

     1)	Instantiate an object instance from the external serialization.
     	Here the class code looks for the full utypes (or FITS keywords
 	etc.), setting the associated properties of the object.

     2)	The object is an example of a controlled context.  Controlled
     	means that we can use short tags to identify object properties
 	while ensuring that name collisions do not occur.  Hence we might
 	have Spectrum.Char.TimeAxis.Coverage.Location.Value as the utype
 	in the external serialization, but refer to this "TimeLocation"
 	in our client code.

Hence while the full UTYPES are used at the interoperability layer,
the client application rarely needs to see these.  In addition to being
more convenient, this helps isolate the client from any changes to
the UTYPEs, which could occur for example due to interface versioning.
Most issues with UTYPE namespaces (e.g. "ssa" vs "spectrum") can also
be hidden from the client in this fashion.

So to return to our example above, what one might do is implement
a time series class.  If this wants this to be able to ingest a
variety of different types of data that is fine.  Versioning of
formal VO data models/interfaces could also be supported.  The top
level application using this would however only see "TimeLocation"
or whatever one chooses to call the property.

 	- Doug