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