Draft note on STC in the Registry

[Mark Taylor]

Markus,

I've got one comment at the moment on this, relating to representation
and serialization of MOCs outside of the MOC1.0-endorsed
FITS serialization.

You suggest in this document using the ASCII serialization mentioned
(but not presented as a normalised part of the specification) in
section 3.1 of the MOC 1.0 specification for representing MOC content
inline in (a) the proposed <spatial> element and (b) VOTable output.
That would work.

But for VOTable serialization at least, I think a
more natural serialization is as an array of integers
(e.g. <FIELD name="coverage" datatype="int" arraysize="*"/>).
Using the NUNIQ encoding described in sec 2.3.1 of MOC 1.0,
a MOC can be represented simply as a sequence of integers
(>=16-bit for order<=6, >=32-bit for order<=13, >=64-bit for order<=29).
The standardised FITS representation doesn't add much magic to that,
and the non-standard ASCII representation just makes it more
human-readable.
In VOTables, an array-valued integer-typed cell can efficiently
(for BINARY/2 serialization anyway) store MOCs in this form,
and it should(?) be more straightforward for clients to ingest.
A suitable xtype would still help with the representation here
(does that really have to be in DALI?  It seems like sense to
allow external standards to define their own xtypes, though
endorsing it in DALI when a new version is being produced would
be no bad thing).

The case for using a list of integers may not be quite so
compelling in the case of the proposed VOResource coverage/spatial
element you propose.

What do you think?

Mark

On Wed, 17 Jan 2018, Markus Demleitner wrote:

> Dear colleagues,
> 
> Those who attended our session in Shanghai may remember my talk on
> how we can finally get proper STC queries against the Registry -- 
> http://wiki.ivoa.net/internal/IVOA/InterOpMay2017-Reg/reg-stc.pdf
> 
> I've finally done the various implementation parts to try everything
> out in DaCHS and the relational registry (at this point, it's only on
> the Heidelberg mirror, since harvesting the MOCs is quite a bit of
> pain).
> 
> Based on that experience, I'd now propose a roadmap for how we could
> move towards more-or-less universal declaration of coverages in
> space, time, and spectrum for the VO Registry.  I've drafted
> a Note that I'd like to upload to the document repository -- probably
> some time next week unless you want more time for discussions.
> 
> A draft of the note is available from
> http://docs.g-vo.org/regstcnote.pdf, the sources (that you're welcome
> to work on) are in volute at 
> https://volute.g-vo.org/svn/trunk/projects/registry/regstcnote
> -- this includes a copy of the modified VODataService schema that
> will later be part of the upload.
> 
> After this, I'd be grateful if you (yes, you!) could
> 
> (a) briefly review the thing to and protest quickly if you strongly
> disagree with the main points of the note?  Ideally, I'd like the
> note to represent the "rough consensus" that's traditionally half of
> the RFC process (the other part being "running code").
> 
> (b) perhaps look a bit deeper at the stuff if you're interested a bit
> more in the registry/STC borderline.  If you still feel comfortable
> with the note then, I'd be happy to include you on the author list.
> I feel a bit odd being the only author on something fairly
> wide-reaching, and certainly some of you out there had important
> roles in shaping what's written there during the past six years or so
> (yeah: according to RegTAP WD-20121112, it removed a first version of
> this...).  So: If you can see your name on this note, just drop me a
> note, and don't be shy or overly modest.
> 
> Thanks,
> 
>             Markus
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/