Mark Taylor writes:
> - VOTable doesn't allow you to mark columns which are essentially
> numeric but are formatted as strings (e.g. sexagesimal angles)
> as such
> - For some purposes such a facility would be useful
> - We should modify the VOTable standard accordingly
This is, of course, a much broader issue than VOTable or even VO.
> 1. Sexagesimal angle as hours:minutes:seconds (e.g. "23:04:46.5")
> 2. Sexagesimal angle as degrees:minutes:seconds (e.g. "+15:12:19")
> 3. Epoch as ISO-8601 (e.g. "2001-08-16T21:16:51.5")
Note that IRAF (for instance) already treats a sexagesimal string literal as equivalent to a real number.
On the other hand ISO-8601 represents a whole family of formats and is not limited to scalar timestamps, but may itself include ranges and such.
Without further comment one might also ponder overlap with STC issues.
> I therefore think that we need some way of expressing in a
> datatype="char"/"unicodeChar" FIELD element that a certain value
> representation format is being used. As usual, the same applies to
> PARAMs.
VOEvent is relying on VOTable style PARAMs. Suggest this is not solely a VOTable issue.
> P1. Introduce a new attribute "representation" (or some other name)
> for FIELD/PARAM to contain a special string indicating how
> values
> in that column are to be interpreted. The special values
> "hms", "dms" and "iso8601" (any more?) would be initially noted
> along with rules for what counts as valid instances of those
> representations.
Have to wonder if this is really a step forward. Have certainly seen examples of mixed representation columns in the past. These may even be more frequent in the VO as users assemble tables as intermediate products resulting from multiple archives. A column might include both sexagesimal and decimal representations - potentially even mixed datatypes (floats versus strings, for instance) in some more quixotic applications.
The list of representations is certainly longer than this - for just one example, add:
"simple" numeric strings: "1.23456"
I put that in quotes since you would have to distinguish not just integer versus floating point representations, but also fixed precision versus the family of scientific/engineering notations. There is also the issue of preserving precision. Projects and individuals often choose a string representation precisely because the values won't fit into a single precision float or long integer value.
Presumably VOTable won't benefit from recasting the entirety of Unix/
C STDIO.
> P2. Modify the definition of the "units" attribute so that it is
> permitted to contain either a catstd-format unit string as at
> present, or a special representation string as in P1.
> We could possibly say that for numeric-valued columns it works
> as at present, but for string-valued columns it has the new
> sense.
> However one could conceive of a case where you want both
> representation and units (though I can't think of any actual
> examples), which would be problematic for this scheme.
The issue of units is complicated enough - and the current mechanism is working well enough - that this seems unwise.
Rob Seaman
NOAO
Received on 2006-04-20Z19:13:42