content, format, ctype, or xtype ?

[Mark Taylor]

On Mon, 4 May 2009, Rob Seaman wrote:

> On Mon, 4 May 2009, Patrick Dowler wrote:
> 
> > > This is not intended to be a metadata concept at all, just an indication
> > > of the format a value is expressed in.
> 
> This is an instance of "data about data" - the very definition of metadata.  I
> presume the distinction here is between something like science-metadata and
> ordinary-metadata.
> 
> On May 4, 2009, at 11:14 AM, Doug Tody wrote:
> 
> > If we want a simple way to specify the format of a field, without having to
> > understand a complex external data model, then a separate mechanism is
> > required.
> 
> Again - use cases?  What we want doesn't matter; what do VO users need?

The use case which I have in mind (and I think Doug is thinking along
similar lines) is this: a user acquires a VOTable from some source - 
perhaps TAP, perhaps not.  It contains a column X whose contents 
is a string in iso-8601 format - this is perhaps identified by 
utype with part of the STC data model, or with some other data model, 
or perhaps is not.  The user loads the table into TOPCAT
(or some other generic table handling software) and wants to make a 
plot with column X as one of the axes.

As far as TOPCAT can tell, the column contains a string, and so it is
unable to make a plot with it, or otherwise do anything much apart
from display the string contents.  If it understood that the column 
contained a string with the semantics of an iso-8601 date/time, 
it could make this plot.  Yes it may be possible to glean this 
information by inspecting the utype, but in order to do that it needs
to have an understanding of the data model in question - a lot of work
for the developer, and needs to be updated every time a new data model
appears or is modified.  Moreover, the additional, probably rather 
detailed, information supplied by the utype is not relevant for this 
kind of processing.

You can think of similar stories for 'ctype' (or whatever) values of
stc-s, stc-x, sexagesimal, and other possibilities of your own device,
including domain-specific ones.  It should not be necessary to invent
a data model in order to flag this kind of thing, partly for practical
reasons (you need to reach agreement about a data model and update
software each time), and partly because use of a data model is orthogonal 
to this issue.

This use case is what I had in mind when I first made this suggestion
in 2006 (http://www.ivoa.net/forum/votable/0604/0815.htm), prompted, 
in fact, by users who were crying out for this functionality.
The usefulness of the proposal is not specific to TAP, but I believe 
it can address some of the data type flagging issues which have 
been raised in relation to TAP, which is why I brought it up in the
context of this discussion (http://www.ivoa.net/forum/dal/0903/1073.htm).
It does not preclude using utypes appropriately, though I agree with 
earlier posters that pass-through is the main thing that TAP should 
be aiming for with utypes.

Mark
(away last week)

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/