Simple utypes

[AdaNebot]

Some minimal utypes in agreement with those from PhotDM are proposed in the document.

• Cons: Simple utypes only work for the simplest cases.

We will need to revisit this document for more complicated cases.

[AdaNebot]

A proposal, of adding some useful utypes in agreement with Obscore

<PARAM ID="123" name="dataproduct_type" ucd=“meta.code.class" utype="obscore:ObsDataset.dataProductType” datatype="char" arraysize="*" unit="" value="timeseries" />  
<PARAM ID="456" name="dataproduct_subtype" ucd="meta.code.class" utype="obscore:ObsDataset.dataProductSubtype" datatype="char" arraysize="*" unit="" value="lightcurve" />  

[AdaNebot]

I like this idea, in agreement with Obscore. Nevertheless, I'm not sure that we need the ID (and if then it should not start with a number) since there is no need of ref to it

[AdaNebot]

Would this be inside GROUP, TABLE, or RESOURCE?

[AdaNebot]

The advantage of inserting these elements in the element TABLE , is that we would be able to stock in a same VOTable document, a table for the timeseries, and for instance a second table with the response of the filter curve or something else that could be interesting to analyse the lightcurve. The GROUP would not change, but the table would look like:

<TABLE name=“mytable” > 
  <DESCRIPTION>Light curve in filter Gbp </DESCRIPTION>
  <PARAM name="dataproduct_type" ucd=“meta.code.class" utype="obscore:ObsDataset.dataProductType” datatype="char" arraysize="*"  unit="" value="timeseries" />
  <PARAM name="dataproduct_subtype" ucd="meta.code.class" utype="obscore:ObsDataset.dataProductSubtype" datatype="char" arraysize="*" unit="" value="lightcurve" />
  ...
<TABLE/>

[AdaNebot]

Solved by #22

[AdaNebot]

Apparently if these PARAMS would be in a RESOURCE it would be easier / clearer for applications.

What's your opinion ? @Zarquan @loumir

[Zarquan]

First question - have the IVOA ever done this before ? If yes, then we should follow the established practice.

If no, then no objection, but some details would need to be solved.

TL;DR; if dataproduct_type applies to the RESOURCE, then we need to add more details to the specification to describe which TABLE within the RESOURCE contains the timeseries data.

I liked this comment from @AdaNebot :

The advantage of inserting these elements in the element TABLE , is that we would be able to stock in a same VOTable document, a table for the timeseries, and for instance a second table with the response of the filter curve or something else that could be interesting to analyse the lightcurve.

So do we loose that ability, or can we add something to enable this to still happen ?

• How does an application know which TABLE within the RESOURCE contains the time series data ?
• Does this mean a set of standard names for timeseries TABLEs in the RESOURCE ?
• Are we allowed other TABLEs inside the same RESOURCE as the timeseries TABLE ?
• Are we allowed more than one timeseries TABLE inside the same RESOURCE, if so, how does an application find them ?

[loumir]

I agree that if we want to factorise the dataproduct_type to the RESOURCE we need to add the rule : A RESOURCE may contain several time series tables but of the same dataproducttype.
A VOTABLE with one time series table and one filter curve table will require 2 RESOURCE elements one for each TABLE but it is valid in VOTABLE too.

[Bonnarel]

Hi Dave

First question - have the IVOA ever done this before ? If yes, then we should follow the established practice.

If no, then no objection, but some details would need to be solved.
in VOTable section 3.4 on RESOURCE explicity allows to have PARAMs in a RESOURCE. There is an example of this in section 5.2. I am looking for a live example

TL;DR; if dataproduct_type applies to the RESOURCE, then we need to add more details to the specification to describe which TABLE within the RESOURCE contains the timeseries data.

This RESOURCE will be the TimeSeries. Tables or material which are not directly involved the TimeSeries should go in an independant RESOURCE

I liked this comment from @AdaNebot :

The advantage of inserting these elements in the element TABLE , is that we would be able to stock in a same VOTable document, a table for the timeseries, and for instance a second table with the response of the filter curve or something else that could be interesting to analyse the lightcurve.

So do we loose that ability, or can we add something to enable this to still happen ?

* How does an application know which `TABLE` within the `RESOURCE` contains the time series data ?

Every TABLE in this RESOURCE is part of the TIMESeries

* Does this mean a set of standard names for timeseries `TABLE`s in the `RESOURCE` ?

* Are we allowed other `TABLE`s inside the same `RESOURCE` as the timeseries `TABLE` ?

Several Time Tables but no different one

* Are we allowed more than one  timeseries `TABLE` inside the same `RESOURCE`, if so, how does an application find them ?

Yes All the TABLES have to be read in that case

[AdaNebot]

In some cases it might be better to add those PARAM at the RESOURCE level and in others directly in the TABLE.

We could put an example to show when it is better to choose one over the other.

[AdaNebot]

Do you have any particular thought on this one @msdemlei ?

[msdemlei]

On Wed, Apr 29, 2020 at 05:23:19AM -0700, AdaNebot wrote: Do you have any particular thought on this one @msdemlei ?

On the ID question: the PARAMs certainly do not need an ID parameter, so yes, that should go. Whether to reference them through utype or through name does not make much of a difference from an abstract point of view, as the two are linked by obscore. While name feels a bit less formal, I can't see much wrong with reserving parameter names in a protocol (we've long done this with INFO). Since, further, the names are less unwieldy than the utypes and there's less potentical to get things wrong (e.g., is ObsCore:ObsDataset.dataProductSubtype the same as obscore:obsdataset.dataproductsubtype? By SSAP's utype definitions, it is, but will people write their xpath expressions like this?), I'd say let's just require names and no utypes here. If, for some reason, we want utypes, then we should skip any requirements on names, because when you define two ways to express the same thing, in the end both won't work reliably. On the other hand, name is a mandatory attribute on PARAM in VOTable, so we'd be asking people to make up such names... hm. As I said: I'd go for names only. As to the location: If we take this from obscore, we ought to copy obscore semantics. Obscore talks about datasets, and I'm rather convinced we should identify the obscore dataset with a complete VOTable here; I'd postpone fragment references in obscore as long as we possibly can. Hence, it's the entire VOTable we describe. And hence, I'd say the params should be children of VOTABLE. That's also nice because then clients can parse until they hit the first <RESOURCE, and if they've not found the dataproduct_type until then they can be certain the file doesn't contain one. Why would clients want to do that? Well, splat, for instance, deals with time series differently from spectra. Being able to set these differences as early as possible simplifies its code. Or so I claim, never having touched Splat's code myself. The whole dataproduct_type thing collides a bit with our plans for a standardId INFO (which lets clients tell apart, for instance, SSAP responses from SIAP responses), but I think only just a bit: standardId lets clients tell apart different sorts of result lists, not data product types. You know: The more I think about it the more I like it. I'd say once we have the note out, we should propose it for DALI (where the PARAM might turn into an INFO, but that wouldn't hurt). Having looked there I remember that they put their QUERY_STATUS, and even their standardID into the the RESOURCE with "results". Which would be an argument to go for resource after all, but I'd vote against it. And as said above, having it in RESOURCE seems not easy to reconcile with what Obscore thinks these things are. And worse: Think of a poor client. if it has, for each resource or table, to redecide what sort of thing it is dealing with, it's getting hard for the author, and building a nice user interface around that becomes even harder. So: We should discourage mixing, say, time series and spectra and tell people who think of that to use datalink. And have the dataproduct type be a global property of the VOTable.