Small question/suggestion re: ObsCore

[Gregory Dubois-Felsmann]

Hi, Mireille,

Thank you very much for your reply (and Markus and Patrick for theirs).

On Dec 5, 2018, at 8:52 , Mireille LOUYS <mireille.louys at unistra.fr> wrote:
> Hi Gregory , Hi all, 
> Sorry for this late reply.
> 
> I think we must keep the usage of UCDs to their original goal: classify the kind of metadata we use to describe our datasets . 
> they cannot be unique identifiers to designate a piece of metadata. 
> Obscore defines column names for this purpose. 
> 
> meta.main is always context dependent and up to the dataprovider to decide .

I certainly wasn’t imagining using “pos.eq.ra;meta.main” as a unique identifier for the “s_ra” member of the ObsCore data model.

I’ve thought about it a bit more since my original email, taking the feedback into account, and I think I can express it more clearly (and slightly differently) now:

(Preamble:)

* From the perspective of a tool developer (e.g., Firefly, Aladin) I would like to have my tool to have the general ability to receive any tabular data and produce a useful display, based on some heuristics.  Part of that is to recognize that a table contains spatial information, and to use that information to plot the rows of the table as points in a sky image of appropriate scale (e.g., a HiPS image).

* When the table is in VOTable format that is very nice, because we get potentially a lot of metadata to tell us what’s going on.  We won’t always know where the table came from - sometimes it comes from, say, an ObsTAP or SIAv2 query that the tool itself executed, but sometimes it just comes from an upload, or from something saved in the user’s workspace.

* Many tables have multiple sources of spatial information, and in particular, multiple pairs of (ra,dec) or other spherical coordinates.  We need to enable users to choose any of them for the overlay of a catalog table, but we also need to provide a reasonable default that will produce an immediately useful display in the majority of cases.

* “meta.main” is a perfect way for a data publisher to give a client of this kind a reliable “hint” as to which spatial data to prioritize for such a default display.

* As a publisher, when running an ObsTAP or SIAv2 service that (as is permitted) adds additional columns to the basic data model, if one were aware of client tools with this defaulting/prioritization behavior, it would be useful to be able to use “meta.main” to tag the “s_ra” and “s_dec” columns in order to indicate that they are still meant to be the primary spatial coordinates.  Or, perhaps, even to indicate in some circumstance that some other coordinate pair that’s not in the ObsCore model is meant to be primary in that context.

So what matters, I think, is in effect the “permission” to apply “meta.main” to “s_ra” and “s_dec” - and perhaps a recommendation to do so unless a publisher is deliberately trying to achieve a different effect.

In Firefly we have taught the tool to *also* recognize “s_ra” and “s_dec” as part of our heuristic for determining the default behavior for catalog-image overlays, and perhaps that’s inevitable, but it seems that we (IVOA) invented “meta.main” for this and that ObsCore shouldn’t be an obstacle to a data publisher using it to provide appropriate hints.

As Markus and Patrick noted, it may be a bit of a struggle to change/clarify the standard in this regard.  Even if that’s too difficult to tackle in this case, it seems to me to be a useful lesson for the future when we standardize data models and their VOTable representations: understanding whether we still provide flexibility to add certain secondary UCDs to whatever UCDs are prescribed by the standard.

Gregory

>  
> 
> Suppose you run an ObsTap service and discover images from one collection in one table, and got another table with a list of images from another archive service , not ObsTap.
> positions can also be given with the pos.eq.ra;meta.main  ucd  for instance recording the pointing positions. 
> 
> I think you will have to check anyway which is which from the column definitions to interpret how they can be matched ... 
> The Vizier catalog archive has the Readme file to provide this kind of information. 
> 
> I hope this helps. 
> Best, 
> -- 
> --
> Mireille Louys,  MCF (Associate Professor)  
> CDS				IPSEO, Images, Laboratoire Icube 
> Observatoire de Strasbourg	Telecom Physique Strasbourg
> 11 rue de l'Université		300, Bd Sebastien Brandt CS 10413
> F- 67000-STRASBOURG		F-67412 ILLKIRCH Cedex
> Tel: +33 3 68 85 24 34
> 
> Mireille 
> 
> Le 09/11/2018 à 21:22, Gregory Dubois-Felsmann a écrit :
>> In the context of implementing application behavior associated with ObsCore-style data tables, I noticed the following thing:
>> 
>> The ObsCore 1.1 standard, in Appendix C, Table 6, specifies the UCDs to be associated with ObsCore columns.  In particular, for s_ra and s_dec, it suggests pos.eq.ra and pos.eq.dec.  
>> 
>> Section 4.22 of the standard says "Service providers may include additional columns in the ivoa.ObsCore table to expose additional metadata. These columns must be described in the TAP_SCHEMA.columns table […]”.
>> 
>> This means that it’s possible that additional columns with UCD “pos.eq.ra”, say, might be added.
>> 
>> >From the perspective of a client application, it might still want a hint as to which “pos.eq.*” columns pair is “authoritative” or “principal” in some way.  This is what the “meta.main” secondary UCD is meant to capture.  Certainly a client application could decide to resolve the ambiguity by favoring the pair with column _names_ “s_ra”, “s_dec”.   However, if we are already building our clients to respect “meta.main” as a hint as to which columns to prioritize:
>> 
>> Was it considered, or would it be appropriate, for a service returning an ObsCore-compliant table (e.g., an SIAv2 or ObsTAP service) to be required (or strongly recommended) to include “meta.main” in the UCDs for “s_ra” and “s_dec”?
>> 
>> Thanks,
>> 
>> Gregory
>> 
>> 
> 
> -- 
> --
> Mireille Louys,  MCF (Associate Professor)  
> CDS				IPSEO, Images, Laboratoire Icube 
> Observatoire de Strasbourg	Telecom Physique Strasbourg
> 11 rue de l'Université		300, Bd Sebastien Brandt CS 10413
> F- 67000-STRASBOURG		F-67412 ILLKIRCH Cedex
> Tel: +33 3 68 85 24 34
>