content, format, ctype, or xtype ?

Mark Taylor m.b.taylor at bristol.ac.uk
Tue May 12 05:14:06 PDT 2009


Norman,

On Tue, 12 May 2009, Norman Gray wrote:

> On 2009 May 11, at 13:48, Mark Taylor wrote:
> 
> > 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.
> 
> Earlier, Rob pointed towards the utype suggestions I made a while ago
> <http://www.ivoa.net/Documents/latest/utype-uri.html>.  These suggestions
> address this, in the sense that they describe how, if an application comes
> across an element annoted with a utype it does not recognise (perhaps as a
> result of an update to a data model far away), it only has to dereference a
> URL to discover a plain text list of utypes that the new one is 'like', and it
> can process the element as any one of those that it recognises, such as a
> previous version, or a very generic notion such as 'date'.  That doesn't
> require any updating on the part of the developer -- only some bookkeeping on
> the part of the organisation which has updated its data model and associated
> utypes.
> 
> 
> 
> I didn't see the beginning of this thread (and the archive at
> <http://www.ivoa.net/forum/dal/> only goes up to 21 April), but if utypes
> (already sitting above UCDs and still not even defined) are sufficiently
> incomplete that we require 'ctype' and 'xtype', too,

nobody is suggesting both ctype and xtype, this thread started by 
attempting to come up with a name for a single new item.

>                                                      then I think that has to
> be regarded as a defect of utypes.

I don't, any more than I think the fact that we require units as well
as utypes should be regarded as a defect.  What I'm talking about is
orthogonal to what utypes are for, which I take to be some kind of
semantic characterisation.  In fact, it's more like what you've 
characterised as "lexical types" in your utype discussion
(http://nxg.me.uk/note/2009/utype-questions/):

   ... lexical types which indicate how a sequence of bytes is to 
   be parsed (is 123 intended to be the string ‘123’ or the 
   number 123 or possibly even a julian day number?)

Two columns could have the same utype (indicating an observation time)
but different [content/format/xtype/ctype/whatever-it's-called]; 
one could be supplied as an ISO-8601 string, and another as an MJD.
If I attempt your dereferencing trick and find out that the field 
I'm looking at is "like a date", it doesn't get me very far with that
(even apart from the fact that I now need a network connection to
make sense of an otherwise self-contained data file).
Yes I can look at the datatype and have a guess, but this is messy, 
and it still doesn't help me distinguish between JD and MJD.

Mark

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


More information about the dal mailing list