[VO-semantics- UCD updates ]VEP-UCD-003.txt - "pos.moc" proposal and discussion

[Markus Demleitner]

Hi all,

On Tue, Mar 29, 2022 at 01:05:37PM +0200, Mireille LOUYS wrote:
> I guess we need to distinguish 2 uses-cases :
> 1- an encoding of the MOC as a string as expressed in the MOC specification
> : https://www.ivoa.net/documents/MOC/20191007/REC-MOC-1.1-20191007.pdf
> subsection 2.3.2 String serialization
> 
> This can be inserted as a table column with one ucd like :
> /meta.multiordercoverage/ or shorter /meta.moc/
> then the kind of coverage axes included in the tessellation encoding should
> depend on an xtype to be defined as :
> S_MOC, ST_MOC, T_MOC, E_MOC if there is one definition for energy coverage
> in the future.

If we already have this information in the xtype: why would we (ab-)
use the UCD to repeat it?

Me, I'd say it would be a lot more useful if we kept the UCD free to
say *what* the MOC describes: A field of view, an area where some
likelihood function is larger than something, a resource coverage,
the shape of a nebula, or whatever else.

> 2- data product type
> When we deal with a HiPS Survey , or a HiPS observation, the data product
> type  tells more about  which axes the data vary along.
> a data product is needed to describe the collection of tiles, described in
> the MOC string that contain data .
> This can be an image survey  with S_MOC or ST_MOC, a time series (with T_MOC
> or ST_MOC ), a cube survey (with ST_MOC or only S_MOC) etc.
> The measurements belong to the data products , the tesselated coverage
> belongs to the string encoded MOC.

If I'm not mistaken, in this context you have an http content-type
that would inform the client what sort of thing comes back.  If that
is true, then we really should use the https header field for
communicating what comes back.  That's what it's for.

Talking about that: Let's not repeat the mistake of VOTable where we,
to this day, live with an x- media type.  Let's register a MOC media
type right now.  I'd help out with that.

But on pos.moc I'm still unconvinced there is a problem it would
solve.

        -- Markus