VOTable 1.4 Proposed Recommendation: Request for Comments

Summary

Latest Draft: VOTable 1.4 (Proposed Recommendation)

The main purpose of VOTable 1.4 is to support the new TIMESYS element.

VOTable 1.4 is a backward-compatible revision whose primary purpose is to support a new TIMESYS element. For more information on TIMESYS, see this note: A Proposal for a TIMESYS Element in VOTable

The other main differences between version 1.4 of VOTable and the preceding version 1.3 are:

Changes made during the Working Draft phase are noted here: VOTable 1.4 Working Draft Notes

Update (2019-06-11): New PR Document uploaded to correct document date and status.

Future

The VOTableInfo page contains a list of proposed changes that, during the WD phase, were agreed to defer to a future version. When the document maintenance is transitioned to GitHub, those item will be converted to GitHub issues.

Reference Interoperable Implementations

• AladinProto: TIMESYS and COOSYS full support
• DaCHS 1.2.6 (beta) produces TIMESYS. Deployed services serving time series with TIMESYS include ivo://org.gavo.dc/gaia/q2/dr2epochflux, ivo://org.gavo.dc/bgds/l/ssa, and ivo://org.gavo.dc/k2c9vst/q/ssa, as well as the datalink-linked datasets from the gaia.dr2epochflux, bgds.ssa_time_series, and k2c9vst.timeseries tables in http://dc.g-vo.org/tap
• STIL v3.3-3/STILTS v3.1-6/TOPCAT v4.6-3 support VOTable 1.4 (PR-VOTable-1.4-20190604): COOSYS and TIMESYS elements are ingested and the relevant properties are attached to columns in the internal table data model, and can be seen in the library/application column metadata. The same attributes are written out, though currently for TIMESYS only if output VOTable version is set to "1.4" ( -Dvotable.version=1.4). These applications don't do much with the information beyond making it visible, though (experimental) time plots use the timeorigin and (in most cases) time units to offset temporal coordinates.

Implementations Validators

• votlint from STILTS v3.1-6 validates VOTable 1.4, corresponding to PR-VOTable-1.4-20190604.

Comments Prior to Official RFC Period

Closed on 2019-06-04 with no comments -- TomDonaldson - 2019-06-04

Comments from the IVOA Community during RFC/TCG review period: 2019-06-05 - 2019-07-19

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

• Comment by ThomasBoch : request for clarification about COOSYS allowed system values
  Among the list of possible values for the system attribute of the COOSYS element, two of them "ecl_FK4" and "ecl_FK5" are quite obscure to me and it would make life simpler for implementors if there was a definition attached to each of these values. The XML schema also mentions 3 other possible values: "xy", "barycentric" and "geo_app" ...

• Comments by -- MarkCresitelloDittmar - 2019-07-05: just a quick 'official' comment regarding the COOSYS and TIMESYS element mappings to the Coords data model.
  • COOSYS
    • system => coords:SpaceFrame.spaceRefFrame which is a vocabulary (https://www.ivoa.net/rdf/refframe) that includes the terms listed in the COOSYS documentation (section 3.4) plus terms from the Coords model draft (trimmed set).
    • equinox => coords:SpaceFrame.equinox, with same definition
    • epoch => not currently included, need concrete use-case thread/implementation to see where best to fit in (coords or meas).

• • TIMESYS
    • refposition => coords:TimeFrame.refPosition with value from StdRefLocation vocabulary at (https://www.ivoa.net/rdf/refposition). same
    • timescale => coords:TimeFrame.timescale with value from vocabulary at (https://www.ivoa.net/rdf/timescale). same
    • timeorigin => coords:TimeOffset.time0. This is not part of the TimeFrame in the coords model, but rather on the Time coordinate type which requires it. The descriptive restrictions in TIMESYS regarding when it MUST/MUST_NOT exist are compatible with the various TimeStamp types in the coords model. Note: that the type is restricted to JD here, which is more restrictive than the model allows, but appropriate for this usage.
  • In short; both elements are compatible with the coords model, except for the omission of COOSYS.refposition which would be needed to generate a valid SpaceFrame instance.
• Sample comment by WikiName
  • Response (by WikiName)

Comments from TCG member during the RFC/TCG Review Period: 2019-06-05 - 2019-07-19

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Document looks fine; TIMESYS addition a useful one at current stage. I see a small discrepancy (document heritage driven, I suppose) in asking COOSYS and TIMESYS elements to be placed before the elements that refer to them: COOSYS has this as a SHOULD, TIMESYS as a MUST. I get it cannot be aligned for back compatibility reasons. -- MarcoMolinaro - 2019-07-11

Data Model Working Group

Grid & Web Services Working Group

The document is well written, and addesses the important topic os TIMESYS. No particular comments from me. -- GiulianoTaffoni - 2019-08-12

Registry Working Group

Approved from Registry standpoint. I don't have the background to comment deeply on TIMESYS details, but it looks straightforward to implement if needed and the parallel with COOSYS fits nicely. A note on the arraysize=1 clarification: since we're no longer working in the confines of smallest possible text changes for errata, there might be places elsewhere in the text where arraysize is discussed where it would be helpful to mention. Not strictly necessary to address this, just a thought. -- TheresaDower - 2019-06-04

Semantics Working Group

We would like to caution against at this point that the representations of the resources you get when you dereference the vocabulary URL given in the specification will probably change in the course of our work on Vocabularies in the VO 2.0. This does not impact the usability of the present specification where the vocabularies are used as simple word lists. Validators based on the current representations might need (reasonable) adaptations later, though. It's probably ok if this caveat remains here; we don't think this merits mentioning the the spec.

Also, we remark that the example in 3.7, where a LINK element is used to reference a SKOS concept, is using an outdated and abandoned vocabulary (on purl.org). Since this is content taken over from a previous version, and a new-style physical quantities vocabulary is not yet finalised, we do not object to leaving things as they are, though.

Although it's arguably out of scope for this update, as the responsible WG we're happy to see that VOTable now references VOUnits. Stylistically, we would prefer the text "VOTable documents SHOULD write unit attributes as defined by Units in the VO [3]" so it's clear that validators can issue warnings when they don't. We would also suggest to mention this adoption of VOUnits in the changelog.

One important thing, though: VOUnits does not admit the asterics as a multiplication symbol. Thus, "where the symbols . or * indicate a multiplication" must become "where the symbol . indicates a multiplication". (A)

Apart from this one point, Semantics is fine with the PR as it stands.

Editorial miscellanea: the @version attribute in the schema should be set to 1.4 before uploading the REC; the \ivoatype still says "Working Draft" in the PR and should be turned into "IVOA Recommendation" before upload; also, the status text needs to be fixed (the official wording is in DocStd) before the REC upload.

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Operations

Looks good to go from my point of view. -- MarkTaylor - 2019-06-26

Standards and Processes Committee

TCG Vote : 2019-06-05 - 2019-07-19

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.

<--
 
 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup 
 
 
-->