STC-S WD

[Markus Demleitner]

Dear DMers,

On Mon, Jun 04, 2012 at 06:31:17PM -0400, Arnold Rots wrote:
> Since the WD for STC-S has not been posted, yet, on the IVOA Docs
> page, I can give you a provisional link to it on my personal STC page:
> 
>       http://hea-www.harvard.edu/~arots/nvometa/STC/

I'd like to see a couple of changes in that document -- some of those
I've already discussed with Arnold over lunch.  Maybe some of you
want to chime in on them.  So, here's a list:

(1) There should be a proper BNF grammar for STC-S.  I have one at
http://docs.g-vo.org/stcsgrammar.txt, which is machine-generated and
thus quite ugly, but it should be pretty much what Arnold intended
(with the exception of the velocity subphrase, which needs fixing in
that grammar).  With a bit of sympathetic attention, it should be
rather straightforward to turn it into something actually readable.

(2) I think the preterminals in the BNF grammar should be linked to
the actual data model via utypes generated according to the recipe in
the STC-in-VOTable note,
http://www.ivoa.net/Documents/Notes/VOTableSTC/, mainly for reasons
of conceptual hygiene.  The downside of this is that these utypes are
generated via the STC-X schema, which is regarded by many, including
me, as suboptimal.  However, it seems there is no significant
initiative to come up with a better formalization of the STC data
model (or is there?), so I feel it's the best we can do.

(3) We should not prescribe the sequence of the "labeled" values
(PixSize, Error, Resolution, Size).  The restriction gains us little,
but opens up a significant source of unnecessary syntax errors when
humans write STC-S.

(4) We should allow equinoxes on FK4, FK5, and ECLIPTIC frames; these
would be of the form J1980.0 or B1875.0.  The BNF cited above already
has that built in.

(5) STC-S should have the notion of epoch, e.g., the epoch a catalog
is reduced to.  I'm already using this in my STC-S based descriptions
of catalog coordinates with a new labeled sub-phrase ("Epoch
J2000.0").  Arnold has pointed out that we could define the Time
coordinate within a time sub-phrase for that purpose, which has the
advantage that you get precise notions of the time frame used; thus

TimeInterval TT GEOCENTER MJD2345 MJD3456 Time MJD3000.22

would say that observations were performed between
1865-04-19T00:00:00 and 1868-05-05T00:00:00, with positions given for
1867-02-03T05:16:48.021, all in terrestial time or rather, given the
dates, ephemeris time, as measured in the Earth's center.  I consider
that fairly elegant, but I'm worried we're overloading time here, and
thus I'd be a bit more comfortable with the extra sub-phrase, while
acknowledging we'd be losing expressional precision with it, in
addition to adding features to something already fairly complex.

(6) We may want to let people specify the planetary ephemeris used (I
needed to do this at some point and built that into my STC-S parser);
this would let people say JPL-DE200 or JPL-DE405 after the reference
position.  From my view, that's fringy enough to forget about it, but
I freely admit I don't really know what I'm talking about here.

(7) In my application, I need column references within STC-S; that's
a can of worms, in particular when you want to refer to columns
containing full geometries (not to mention when you actually allow
delimited identifiers) -- this looks like

Circle ICRS "ra" "dec" "size"    or
Circle ICRS [coverage]

Since that's rather application-specific (I use it to note the STC
metadata for tables), it probably does not belong in the STC-S
standard, but I thought I'd mention it in case someone feels
differently here.

(8) We have all the wonderful "STC Library" systems, like
ivo://STClib/CoordSys/TT-ICRS-TOPO and friends.  In my STC-S
implementation, I support declaring them in a System sub-phrase,
which allows for nice and concise STC metadata.  Unfortunately, this
is awkward in STC-S, since by the grammar, you have to give, e.g., a
reference system in the space subphrase; if what you define there is
in conflict with your system, what then?  So, while in principle
desirable, this probably doesn't work.  Anyone with a good idea on
how to do library systems in STC-S nevertheless, please speak out.


I'd volunteer for doing the changes that we find consensus on, but
checking my to-do list and vacation calendar I'd say that's not going
to happen before August.

Any thoughts or encouragement is appreciated.

Cheers,

         Markus