<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">DaliNext <a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/DaliNext">http://wiki.ivoa.net/twiki/bin/view/IVOA/DaliNext</a> 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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 24 Oct 2018 at 05:09, Gregory MANTELET <<a href="mailto:gregory.mantelet@astro.unistra.fr">gregory.mantelet@astro.unistra.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Dear Markus and Apps folks,<br>
<br>
That reminds me a lot a talk I gave at the Interop in Shanghai about
MOC and TAP - <a href="http://wiki.ivoa.net/internal/IVOA/InterOpMay2017-DAL/mantelet_tap-moc.pdf" target="_blank">http://wiki.ivoa.net/internal/IVOA/InterOpMay2017-DAL/mantelet_tap-moc.pdf</a>.<br>
<br>
We had the same issue: having a string/ASCII serialisation of a MOC.
The idea was to write something like:<br>
<pre> WHERE 1= CONTAINS(POINT(’’, ra, dec), <b>REGION(’MOC 2/12-20 5/60’)</b>)</pre>
or<br>
<pre> WHERE 1= CONTAINS(POINT(’’, ra, dec), <b>MOC(’2/12-20 5/60’)</b>)</pre>
<br>
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 (<a href="http://www.ivoa.net/documents/MOC/20140602/REC-MOC-1.0-20140602.pdf" target="_blank">http://www.ivoa.net/documents/MOC/20140602/REC-MOC-1.0-20140602.pdf</a>),
is the prefix "MOC". In such case, it would allow to write in ADQL
something like the first example above (with REGION).<br>
<br>
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.<br>
<br>
<i>Note:</i><i> 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 (</i><i><a href="https://pegjs.org/online" target="_blank">https://pegjs.org/online</a></i><i>)
; just copy-paste the grammar on the left part and then test some
expressions on the right part.</i><br>
<br>
Grégory<br>
<br>
<br>
<br>
<div class="m_-6611291080092945982moz-cite-prefix">On 24/10/2018 10:38, Markus Demleitner
wrote:<br>
</div>
<blockquote type="cite">
<pre>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 at
<a class="m_-6611291080092945982moz-txt-link-freetext" href="http://ivoa.net/documents/Notes/Regstc/index.html" target="_blank">http://ivoa.net/documents/Notes/Regstc/index.html</a> 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
</pre>
</blockquote>
<br>
</div>
</blockquote></div>