STCInVOTable < IVOA

IVOA Web>STCInVOTable (2010-06-24, MarkusDemleitner) (raw view)

---+ Embedding STC in VOTable

The result of the discussions sketched below is [[http://www.ivoa.net/Documents/Notes/VOTableSTC/20100618/NOTE-VOTableSTC-2.0-20100618.pdf|Version 2.0 of the Note]].

---++ History
At the Garching Interop, [[http://wiki.ivoa.net/internal/IVOA/InterOpNov2009DM/stcvotable-demleitner.pdf][Markus has uttered some gripes]] with [[http://www.ivoa.net/Documents/Notes/VOTableSTC/NOTE-VOTableSTC-1.1-20090612.pdf][version 1.1-20090612 of the STC in VOTable Note]] specifying how to embed STC in VOTables.

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).

-- IVOA.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
I have a few residual comments:

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

p. 8, table 5:<br>
I could grumble about the IDs, but they can be reconstructed when taking the utypes and turning them into a proper STC-X document.<br>
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:<br>
I just want to register my disagreement, for the record, with this definition of epoch.

p. 10, sec. 4.1:<br>
I am not clear how that region is going to be represented in the table; wouldn't it need center and radius columns?<br>
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:<br>
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.

-- IVOA.ArnoldRots - 19 May 2010 

<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->

Attachments

Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
ext	STC-UsedinObservation	r1	manage	3.3 K	2010-04-29 - 20:20	MireilleLouys	STC Utype re-used in Obs Core Data Model

Topic revision: r25 - 2010-06-24 - MarkusDemleitner

IVOA

Log in or Register

IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics

Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki

TWiki intro
TWiki tutorial
User registration
Notify me

Working Groups

Interest Groups

Committees

Stds&Procs

www.ivoa.net
Documents
Events
Members
XML Schema