REC for ASCII MOCs

[Patrick Dowler]

DaliNext http://wiki.ivoa.net/twiki/bin/view/IVOA/DaliNext has a
placeholder for MOC and the intent is that DALI would be updated to define
the xtype primarily so that a MOC could be serialised in a single VOTable
cell in an interoperable way. DALI could be the place to define the syntax
or it could refer to a MOC standard directly if a syntax was normative.

Once you can serialise MOCs, they can be used as input (upload) and output
(select) in TAP... but using them elsewhere in the query requires some
support in ADQL-2.x: you have to be able to put a moc (column ref) into the
INTERSECTS function. I think that's really the minimum for use in RegTAP.
You don't really need a MOC function (constructor) -- would someone query
with a single MOC or enter one by hand? -- but for symmetry and
completeness it could be a stretch goal.

In TAPRegExt, support for specific geometry types generally is expressed by
saying the service supports POLYGON (eg) and it doesn't really
differentiate between the POLYGON function and supporting xtype="polygon"
columns in an uploaded table... so to add interoperable MOC support to TAP
the registry extension would need an update and we might need the
constructor function to do that.


--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Wed, 24 Oct 2018 at 05:09, Gregory MANTELET <
gregory.mantelet at astro.unistra.fr> wrote:

> Dear Markus and Apps folks,
>
> That reminds me a lot a talk I gave at the Interop in Shanghai about MOC
> and TAP -
> http://wiki.ivoa.net/internal/IVOA/InterOpMay2017-DAL/mantelet_tap-moc.pdf
> .
>
> We had the same issue: having a string/ASCII serialisation of a MOC. The
> idea was to write something like:
>
> 	WHERE  1= CONTAINS(POINT(’’, ra, dec), *REGION(’MOC 2/12-20 5/60’)*)
>
> or
>
> 	WHERE  1= CONTAINS(POINT(’’, ra, dec), *MOC(’2/12-20 5/60’)*)
>
>
> For that, a standard ASCII syntax for MOC is needed. At the end of my
> talk, in the Appendices, I proposed a syntax as a proposal for a standard
> ASCII serialisation. The only difference with the one proposed in the
> section 3.1.2 of the MOC-REC document (
> http://www.ivoa.net/documents/MOC/20140602/REC-MOC-1.0-20140602.pdf), is
> the prefix "MOC". In such case, it would allow to write in ADQL something
> like the first example above (with REGION).
>
> Anyway, in my talk, I proposed a specification for this syntax (especially
> some rules about what is allowed or not). I also gave a PEG grammar for
> this small syntax.
>
> *Note:** I just noticed a small error in the PEG grammar in these slides.
> So I attach to this email a corrected syntax. You can test this latter
> online with PegJS (**https://pegjs.org/online <https://pegjs.org/online>**)
> ; just copy-paste the grammar on the left part and then test some
> expressions on the right part.*
>
> Grégory
>
>
>
> On 24/10/2018 10:38, Markus Demleitner wrote:
>
> Dear Apps folks,
>
> In the context of adding information on the STC coverage of resources
> (that's VODataService 1.2), we in Registry need an ASCII
> serialisation of MOCs, because the things should come embedded in
> Registry records (see the Registry-STC roadmap athttp://ivoa.net/documents/Notes/Regstc/index.html for our rationale).
>
> Now, we like a lot the proposed syntax in 3.1.2 of the current MOC
> REC -- it's reasonably compact and readable.  But it's not a
> standard, just a suggested syntax.
>
> Since we'd like to use in in a REC, the ASCII MOC needs to be
> specified in a REC, too.  So -- how do you feel about a small update
> to MOC that takes 3.1.2 and promotes it to a normative section 2.3.3?
>
> An alternative would be to take ASCII MOCs to DALI.  In the end, DALI
> will probably have to say something about MOCs anyway, as we'll need
> an xtype=MOC if we want to (interoperably) exchange MOCs in VOTable
> columns (which I want pretty much).  If we touch DALI, it might be a
> little less work if DALI described the format itself (we'd touch only
> one standard, not two of them).
>
> Opinions?
>
>          -- Markus
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20181025/bf87da5e/attachment.html>