STC in VOTable"> Embedding STC in VOTable

The result of the discussions sketched below is 2.0 of the Note.

History

There's been quite a bit of work going on since then; older items have been moved to STCInVOTableArchive, which doesn't necessarily mean the issues are settled; if something discussed there still bugs you, feel free to resurrect it here. Please use add your comments in the section on the most recent draft.

Draft of 2010-06-01

I've put up a new draft at http://vo.ari.uni-heidelberg.de/docs/note_stc_20100601.pdf.

Most changes are cosmetic; in particular, the tables with STC utypes are gone. Instead, there is an appendix enumerating the more useful ones.

Change: Epoch is a float

By popular request, the value of the Epoch utype is now a simple float, and there is a stc:AstroCoords.Position2D.Epoch.yearDef utype that can be B to signify the Epoch is given in Besselian years.

No change: Area utypes

Arnold has asked below what content there would be in columns with utypes like stc:AstroCoordArea.Circle -- well, the representation of complex data is not really what data models are about; both the TAP and the ADQL document suggest some form, but others are conceivable.

It is, admittedly, somewhat unfortunate that STC-S carries its own metadata to some extent, and thus all kinds of confusion is possible when additional and potentially conflicting metadata is added from outside. I'm afraid that cannot be fixed at that point, and I'd suggest that protocol clients "should" discard one or the other (and I'd suggest they should ignore what's in STC-S, but that's a different discussion).

Let's just separate data and metadata in future protocols, shall we?

Draft of 2010-04-20

I've put up a new draft at http://vo.ari.uni-heidelberg.de/docs/note_stc_20100420.pdf. This is basically a rewrite (while, I believe, maintaining the spirit of the old note). Below, I've opened up Level 3 discussion spaces for what I believe a the most sweeping changes against the ''previous draft'' (not the current version of the note; see STCInVOTableArchive for the other changes).

-- MarkusDemleitner - 20 Apr 2010

Change: One group

MD: Rather than having one AstroCoordSystem and one AstroCoord group per system, all utypes dealing with one coordinate system is now contained in one group of (typically) utype stc:ObservationLocation. While this means you can no longer re-use coordinate system definitions within a VOTable, I believe the advantages in implementation simplicity far outweigh this drawback.

Change: AbsoluteTime substitution group gets yet another special treatment

MD: STC-X unfortunately has the AbsoluteTime substituion group that gives what in VOTable is xtype's job (and even if that weren't so, having serialization details in utypes is a pain anyway). So, a new special rule was inserted into the utype generation algorithm to divert ISOTime, JDTime and MJDTime into some special utype, and there's a recommendation to drop that particular utype. Nasty special-casing all over the place, but all alternatives (some of which are discussed in STCInVOTableArchive, search for xtype) seemed worse to me.

Change: DataModel.URI

MD: Many people want some versioning of the data models, preferably connecting data models to URLs. After some consultation with Mireille, I propose to transmit this URL in DataModel.URI. It doesn't help to make instance documents much prettier but is IMHO a rather non-invasive method of making explicit what data model was used.

Comments

p. 6, table 3:
LSR, LSRD, LSRK should only be allowed in spectral and redshift frames.

p. 8, table 5:
I could grumble about the IDs, but they can be reconstructed when taking the utypes and turning them into a proper STC-X document.
However, the units are a bit more problematic. I'll grant you that there could be conflicts arising, but banning them makes it very hard to reconstruct the STC-X version.

p. 10, top:
I just want to register my disagreement, for the record, with this definition of epoch.

p. 10, sec. 4.1:
I am not clear how that region is going to be represented in the table; wouldn't it need center and radius columns?
However, it raises another issue that we probably should have addressed: how to represent STC-S strings. The nice thing about them is that they are fully self-contained. Should they be string columns that have an xtype="stc:STCS", for instance?

p. 11, end of sec. 4.2:
I'm not enamored of the name "Ephem"; why not Time or ISOTime? And I would suggest that xtype="stc:ISOTime" might be more fitting.

-- ArnoldRots - 19 May 2010