adanebot / timeseries Goto Github PK

The document does not propose any association between columns (e.g. magnitude and its error)

• Cons: an application cannot know a priori which are the errors of a given measurement

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.

Information on the metadata of a filter can be assigned by archive curators rather than authors of the original data. The proposed annotation does not include information on the origin of the metadata. Therefore it is not possible to know where the metadata comes from.

• Action: Identify possible solutions and limitations

It is not clear how name="timeseries" on TABLE helps. Also there could be multiple time series in one file, so then multiple tables with the same name in a VOTable, which violates a SHOULD in VOTable.

Starting from use cases will help defining the scope of the note. In particular:

• What kind of thing do we want to enable with this?
• What operations should clients be able to perform based on this without further user intervention?

Time series of tabular data is not clear. Proposal Simple time series where a set of measures are gathered in a 1D vector for each time stamp, typically light curves or radial velocity curves. Time series of images or arrays with wider dimensions are not covered.

The GROUP with information on metadata of the filter system could be replaced by a new VOTable element called FILTERSYS. This element would be defined in line with COOSYS and TIMESYS.

• Status: alternative to a group is currently proposed in the document
• Pros: compact and possible re-use for SED-like information
• Cons: units would need to be fixed in the specification. Less flexibility that a GROUP. Need to modify VOTable.
• Conclusion: there is no consensus to have this as an element in future versions of VOTable.

Should we keep the text at the end of Section 3.1 explaining this alternative or should we remove it? @Zarquan

In Section 3.2, "TABLE must include... ref, ref, ref": this should be rewritten to say "columns having ref attributes" or so, because the TABLE can't have ref (and there's no reason for it to have it).

In some cases data is in the form:

How to annotate this in VOTable? In the current document we propose separating the information in different tables, one per filter.

• Cons: These time series are difficult to be interpreted as spectral data.

Alternative: according to VOTable Section 10.4 it is possible to use a ForeignKey to reference rows as an alternative to several TABLES.

• Status: alternative mentioned in the text
• Pros: allows to reference rows
• Cons: applications (Aladin, Topcat) need extra code to understand the relationship. De/serialisation of such tables would be difficult. Complications in forwarding via SAMP to other clients with metadata intact would be hard.

The next step to investigate this as an alternative solution would be to expose an example.

Including descriptive DESCRIPTION elements is good practice, but ones that just contain boilerplate are not much use.

Sec 3.2 says:

The TABLE must include:

• A human-readable DESCRIPTION that ideally conveys enough human-readable information that basic scientific use of the time series is possible without referring to literature.

I don't think this should be a MUST: authors who have no good description will just have to write something uninformative in here, which is not helpful. So I'd make that a SHOULD.

On a similar topic, the DESCRIPTIONs in the examples in sections 3.1 (photcal_PARAM.xml) and 4.1 (vot-ex1-GROUP.xml) read:

<DESCRIPTION>Photometric system description</DESCRIPTION>

which doesn't say anything additional to the name="PHOTCAL" label. Can something more informative be put in there?

We could add a controlled vocabulary for the magnitude System (Vega, ...).

Tagging the VOTABLE Document the note is specifying ...... as being consistent with the Note

The document limits to light curves and does not propose a solution for other type time series.

• Cons: automatic identification of the principal quantity measured as a function of time is not possible.

Applications would have to limit to read TIMESYS and ask the user for further information.

This note is inspired by a previous annotation strategy developed for SED (Derrière et al. ...) [14] Derriere, S (2010) Providing Photometric Data Measurements Description in VOTables, IVOA Note, https://wiki.ivoa.net/internal/IVOA/PhotometryDataModel/NOTE-PPDMDesc-0.1-20101202.pdf

Change the title to better state the scope of the document.
Proposed alternative title:

• Lightcurve data representation in VOTable: The skinny profile for data and metadata.

The text mentions few UCDs and for further needs, that is other columns not mentioned in this document, it refers to the UCD document.

• Pros: Flexibility to add as many columns as needed
• Cons: As is, it gives the impression that time series can only have the few columns explicitly mentioned in the text

This point needs more clarification, the text should be worked a bit to avoid confusion.

In the abstract we should mention that this proposal applies to light curves, the 1D table time series use-cases. Time series of higher dimensions time series for images, spectra, cubes, etc. will be covered by the TimeSeries general data model based on the Cube DM.

There is no proposed annotation for radial velocity curves, despite this type of time series being the second mayor existing type.
The document could also propose the structure and minimum metadata for a GROUP for radial velocity curves.