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.

To Do Upon Approval, Prior to Upload

• Change version attribute in schema to "1.4"
• In the document, set the \ivoatype to "IVOA Recommendation" and set the status text according to the official wording is in DocStd.

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" ...

I strongly support this suggestion. Although we've pushed a lot of requests to v1.5, I think that if a knowledgable party puts forward (very soon) a table of the values with uncontroversial definitions, that could be be added to this document.

Since this is not a new shortcoming, if we can't acheive swift consensus on a table of definitions, then it's OK to let this go until 1.5 (or even a clarifying erratum), and I've added it to the list of future items to consider.

-- TomDonaldson - 2019-08-18

• 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).
    • refposition => coords:SpaceFrame.spaceRefPosition - Back in Feb. I noticed some chatter about COOSYS adding this missing piece. Can you make a statement about the decision made on this?
  • 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.

Thank you checking the compatibility of COOSYS and TIMESYS with the relevant data models. I'm encouraged to see that the situation is not bad! The decision on adding "refposition" was to add it as an optional parameter in the next possible version. It seems like it should really be required, but that would likely break backward compatibility, so could not be done until a major version increment. This item, with pointers to some of the relevant e-mails is on the list of future items to consider.

-- TomDonaldson - 2019-08-18

• 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

Response:

Thank you for pointing our that discrepency. As you say, backward compatibility prevents it from being addressed now, but improving the consistency between COOSYS and TIMESYS has been added to the list of future items to consider.

-- TomDonaldson - 2019-08-18

Data Model Working Group

• The document update is well written and understandable.
• TIMESYS and COOSYS definitions are well described and easy to implement without breaking parsers logic and the scientific aspects of these two new fields are quite relevant.
• The only drawback I can see is the dependence on external and not accepted vocabularies for timescale, refposition, etc... but the reference by link (instead of the list of possible values inside the VOTable spec) looks to be a good approach. I wonder if a better way to document the vocabulary version (like a schema or similar to be added into the header) so the value ca n be validated but I understand this would be a question to the semantics group.

-- LaurentMichel - 2019-09-27 (on behalf of JesusSalgado)

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

Response:

It is definitely possible that we missed some opportunities to clarify the arraysize=1 situations. At this point I think it's best to collect suggestions for specific wording changes on the the list of future items to consider. It's OK for anyone to add to that list or to e-mail the apps list. Moving forward, I hope to track them as github issues instead.

-- TomDonaldson - 2019-08-18

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.

Responses:

First, the easy responses:

I agree that we will need to pay attention to the implications of evolving vocabularies as we move forward, and I'm glad it's brought up here.

For the example referencing a SKOS concept, I've added a note to revisit that on the the list of future items to consider.

I've added notes on the editorial miscellanea near the top of this page (To Do Up Approval, Prior to Upload). Now watch me forget...

The less easy response:

Regarding VOUnits, the comment about removing the asterics to indicate multiplication made me worry about backward compatibility. I'm wondering if we should make clear the distinction between the new recommended use of VOUnits syntax and the old (deprecated?), but still allowable, syntax from prior VOTable versions. In that way, we could tighten up the language as you suggested on the VOUnits style without at least implicitly invalidating some existing units values. If my concerns seem reasonable, I would definitely welcome suggestions on rewording section 4.4.

In any case, I'm definitely convinced that we should mention the adoption of VOUnits in the changelog. I will add that the next time the document is uploaded.

-- TomDonaldson - 2019-08-18

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Solar System Interest Group

About the reference frames: the list of allowed terms mustn't be set in stone. VOTable is used in many Solar System projects, so we need to be able to define or name coordinate systems, reference frames and reference positions for those applications.

So my main request would be to have a less constrained list of allowed <code>system</code> attribute values for COOSYS. We're working with Semantics to try to come up with a first list of coordinate systems / reference frames for Solar System datasets.

[update]: We have draft document (from VESPA project) listing solar system coordinates systems in used by the science community: https://voparis-wiki.obspm.fr/display/VES/Planetary+Coordinate+Systems

-- BaptisteCecconi - 2019-08-20

Theory Interest Group

Time Domain Interest Group

Metadata for the time coordinates as described by TIMESYS element looks good -- AdaNebot - 2019-08-19

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.