VOTable

VOTable is a standard for the interchange of data represented as a set of tables, and includes both table metadata and the data itself.

The Application Working Group assumed responsibility for VOTable with version 1.3 when the VOTable Working Group was retired.

Recommendation History

See IVOA Document Versions for the official list of all IVOA documents and versions.

Standard Release Date
VOTable 1.3 20 September 2013
VOTable 1.2 30 November 2009
VOTable 1.1 11 August 2004

In Progress

Summary

We are currently working on VOTable 1.4, which is a backward-compatible revision to support a new TIMESYS element and other miscellaneous cleanup. See also the original note: A Proposal for a TIMESYS Element in VOTable

Latest Draft

VOTable 1.4 (Working Draft)

Please add comments, concerns, and implementation notes to this RFC page: VOTable 1.4 Request For Comments

Past Drafts

See: VOTable 1.4 Working Draft Notes

Future

Consider for future version ReferenceSorted ascending Earliest Version Notes
Add a table of definitions for allowed COOSYS "system" attribute values. 1.4 RFC Comment 1.5 If uncontroversial, could be done during 1.4 RFC period.
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). Update this when a new-style physical quantities is ready (or just remove the outdated reference). 1.4 RFC Comment 1.5  

Make COOSYS and TIMESYS more consistent:

  • State that COOSYS and TIMESYS elements MUST be defined prior to their first reference. Currently COOSYS is only a SHOULD, and only for that case of a reference via "ref".
  • State that references to COOSYS and TIMESYS must be referenced via a "ref" attribute. Currently references to COOSYS are allowed to be implicit.

1.4 RFC Comment as well as previous discussions 2.0 The only reason these weren't done for 1.4 were to preserve backward compatibility.
Port the VOTable source to ivoatex. email 1.5  
DataLink recommends using a "content" parameter. Consider mentioning it in sec. 8 (MIME types) to avoid other standards reinventing the same thing with a different name. email 1.5  
Remove mention of UType in section 1.4, as it is lacking a standard. email 1.5  
Sec. 4.6: Remove paragraph "In order to avoid name collisions..." email 1.5  

People here at CDS have been playing around the TIMESYS with example taken in VizieR. This really shows that in many cases a "double"-valued (or more) ref should be a great help. The solution could be to change the definition of ref in VOTable schema from IDref to IDrefs. This was discussed at the time of the TIMESYS note was made public and Mark T said it could have consequences to be addressed. Such a mechanism could also enter in competition with "ref" set on GROUPS. So I agree this may be a too long discussion. But this should be set in the Notes as something to tackle in version 1.5

email 1.5  

decimal years representations in 3.5 : usage of besselian or julian years for timestamps apart from making timeorigin un-useful (and then forbidden) also implies some inference on the timescale used (see the TIME WCS paper for references and discussion). I suggest to add the the following sentence at the end of "timeorigin" explanation: "When using calendar epochs written in yr or Ba, note that conventionally Julian years are tied to the TDB timescale and Besselian years to ET (written here as TT) (Rots and Bunclark et al., 2015)." By the way, on a related topic I discover that in 3.4 COOSYS, we don't explicitly constrain the representation of time in equinox and epoch attributes. This however clear in the xml schema. I suggest adding after "... the epoch of the positions if necessary", the following sentence: " Both equinox and epoch MUST be expressed in the Julian or Besselian calendar".

email ??  

Add optional "refposition" attribute to COOSYS.

Or maybe "refposition" should be required?

email email2

1.4 RFC Discussion

1.5 (or 2.0 refposition is required)  

The current guidance on versioning is that the namespace URI should remain constant for all minor revs of a major version. That's fine, but I think the added feature of having that URI be a URL to the latest schema version is more confusing than convenient.

The biggest problem for VOTable is that the schema now has to allow multiple version attributes (e.g., 1.3 and 1.4) to support backward compatibility, while at the same time allowing 1.4-only features like TIMESYS. This makes the schema somewhat inaccurate as it allows version="1.3" and TIMESYS in the same document.

I would be happy to remove the convenience of having the namespace URI point to the latest schema. For VOTable writers that want to specify the schema (not required), they may as well point to the specific version. They know the version since they already must specify the version="1.x" attribute.

That discussion is outside the scope of VOTable itself, so if that remains unchanged, I propose that we recommend using the specific version schema URL instead of the namespace URI if referencing the schema.

Suggestion by Tom Donaldson 1.5  

Historical Information


This topic: IVOA > WebHome > IvoaApplications > VOTableInfo
Topic revision: r5 - 2019-10-14 - TomDonaldson
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback