VOTable 1.5 Proposed Recommendation: Request for Comments
VOTable is a standard for the interchange of data represented as a set of tables, and includes both table metadata and the data itself.
Summary
Latest Draft: VOTable 1.5 (Proposed Recommendation)
The main purpose of VOTable 1.5 is to support refposition attribute analogous to TIMESYS.
VOTable 1.5 is a backward-compatible revision.
The other main differences between version 1.5 of VOTable and the preceding version 1.4 are:
- COOSYS now has a refposition attribute analogous to TIMESYS.
- The frame identifiers (system attribute) in COOSYS are now taken from the refframe IVOA vocabulary.
- Clarifications and rewording on:
- the meaning of MIN and MAX value attributes for array types.
- removing the recommendation to use xmlns to do utype prefix binding.
- timescales for calendar epochs.
- positioning advice for ID and corresponding references.
- noting that RESOURCE elements can contain MIVOT blocks.
- unit attribute SHOULD conform to VOUnits, and correct examples accordingly.
See
GitHub for a full list of changes.
To Do Upon Approval, Prior to Upload
- Change version attribute in schema to "1.5"
- In the document, set the \ivoatype to "IVOA Recommendation" and set the status text according to the official wording is in DocStd.
My advice: Follow the submission checklist in ivoatexdoc:
https://ivoa.net/documents/Notes/IVOATexDoc/20230627/NOTE-ivoatexDoc-1.4-20230627.html#tth_sEc3.12 (or, even better, the checklist from a current checkout of
git@github.com:ivoa-std/ivoatexDoc.git) --
MarkusDemleitner - 2024-04-30
Future
The
VOTable GitHub Issues page contains a list of issues and proposed future enhancements. It is the main mechanism for contributing to the standard.
Reference Interoperable Implementations
DaCHS produces COOSYS refposition in TAP results from the gaia.dr3lite table in the
GAVO Data Center TAP service which can be read by the latest versions of STILTS and TOPCAT. For example:
- STILTS shows the metadata from the GAVO TAP results:
- stilts tapquery tapurl=http://dc.g-vo.org/tap sync=true adql='select top 1 * from gaia.dr3lite' ocmd=meta
- STILTS rewrites the VOTable from the GAVO TAP results, including the COOSYS refposition:
- stilts tapquery tapurl=http://dc.g-vo.org/tap sync=true adql='select top 1 * from gaia.dr3lite' ofmt='votable(version=V15)' | grep COOSYS
- TOPCAT's Columns Window shows that same metadata for those same GAVO TAP results.
Implementations Validators
- The latest version of STILTS (v3.4-10) validates VOTable 1.5 with the following command:
- stilts votlint my_votable_file.xml
- The validates VOTable 1.5 by following these instructions:
- Click on Load for VOTable.
- In the empty text box below "URL of the service to validate:", enter the URL of a VOTable to validate.
Comments from the IVOA Community during RFC/TCG review period: 2024-April-25 - 2024-June-06
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
Comments from Markus Demleitner, 2024-04-30
I have skimmed the diffs from commit c6575888 on (hint: git diff -b is a godsend for that). I have found some minor style issues, for which I have created PR #61 (
https://github.com/ivoa-std/VOTable/pull/61). Feel free to discard this if you think it does not improve presentatin.
I have one actual question: What about getting MIN/MAX parsing fixed in astropy? This would actually be my favourite reference implementation. Is anyone on it? I'm totally not wild on doing this myself (too much tooling in astropy for my taste), but if there are no other volunteers, I might be talked into putting it in.
--
MarkusDemleitner - 2024-04-30
This is a bug to be fixed later --
AdrianDamian - 2024-06-12
Comment from L.Michel, 2024-05-02
Is there a way to connect the XSD with the IVOA vocabulary in order to make the
system
attribute in COOSYS rule machine-readable.
This would be very usefull in other contexts (Registry, DM)
--
LaurentMichel - 2024-05-02
In short: We can't, because XML Schema does not understand RDF at all, let alone the way we are using it.
There is a longer answer: We
could define an IVOA-controlled schema extension, where a short piece of software would take a schema "template" and fill out enumerations from vocabularies. Then this thing could update the schemas when the vocabularies change.
There is a lot to be said for that. But there is the important counter argument that the schema files would change "on the fly". Whether that is something we want requires a lot of thought.
On the other hand, this is not
really much of a practical problem; VOTable validators need to check so much more than the XSD compliance, starting with whether the data content somewhat matches the FIELD-s, that doing the vocabulary validation externally is a relatively minor matter. --
MarkusDemleitner - 2024-06-12
Comments from TCG members during the RFC/TCG Review Period: 2024-April-25 - 2024-June-06
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
It seems OK.
The clarification about the COOSYS elements, especially with the use of an IVOA vocabulary is very appreciated. It will certainly help VOTable providers and validators. Similarly, mentioning MIVOT in VOTable will also be useful to VOTable providers to be aware of a possibility to bridge data with data models.
Few minor reports, though:
- Architecture diagram not visible in the HTML version (in the PDF it is OK)
- Section 3.2, 4th paragraph: "For this reason, earlier versions of VOTable recommended placing the ID attribute before any references to it, but there may be cases where the opposite is more appropriate."
- If I was a client developper, this sentence is very useful as I know I will have to not rely on the ID position. But if I was a VOTable provider, does it mean I can do whathever I want? It sounds like it does not matter anymore. Would there be some kind of good practice useful to give here, or an example that can help a VOTable provider (which is often a DAL protocol) to organise a VOTable in the best possible way?
--
GregoryMantelet - 2024-06-26
I went through the PRs in the version 1.5 milestone to review just the changes for this version. The updates are good and I don't see any major issues.
Comments:
- on this page - Validators: the second block, "The validates VOTable 1.5", appears to be describing a web-validator, but has no link to one.
- on the document
- TIMESYS: I agree with Anne's comment regarding the 'ET' timescale. The new text specifically linking Besselian years to a timescale which is not obviously supported by the following timescale value set is a bit awkward. One needs to look at the descriptions in the vocabulary to make the connection between ET and TT.
- Relative position of ID and ref: I agree with Gregory/Anne's comment on this too. The new text doesn't give direction. To me, it reads as "The relative position of these can effect performance, we used to recommend ID go first, but we don't any more because there MAY be cases where the opposite is true".
- RESOURCE: MIVOT connection. There are a couple comments on this and why its not reflected in the element hierarchy or schema.
- This is a good example of when one would use a RESOURCE with 'type="meta", and maybe that paragraph should start with "For example, a RESOURCE qualified by"...
- My recollection is that this connection, <VODML> block in the RESOURCE, is OK because clients know to ignore any unrecognized nodes in the RESOURCE. I was thinking that a reminder of that would be useful here, but doing a quick scan of the document, i don't see anything that makes this statement.
I'm OK approving this update with these points clarified.
--
MarkCresitelloDittmar - 2024-08-23
All changes are minor and justified, and not affecting GWS activities.
- There is only one minor comment about MIVOT elements inside RESOURCE type="meta". This is not reflected in the schema, so, is it considered free text? Is this OK for parsers or should it be escaped in some way?
- Also, a personal comment as I am slightly confused by the UNKNOWN valid value for COOSYS refposition (as refposition is optional). It could be better to remove it from the list as setting it as UNKNOWN is not adding info.
As said, this minor version's changes are well documented, so we approve it from the GWS WG.
--
JesusSalgado - 2024-07-17
OK, we foresee no Registry-related issue.
Ok with minor reports:
- look& feel comments: lines artefact in the HTML output (section 2 and 7). The link texts are often the section number instead of the section title.
- link to /votable-1.5.xsd is broken (section 3)
- COOSYS semantic: it is case sensititve (in VizieR, the GALACTIC is in lower case) ?
- "unit SHOULD conform to the VOUnits". It seems to be a step backwards from the previous version that said " unit string *is* defined in reference [3]"
- MIVOT is stipulated in section 3.6 but it doesn't appear neither in schemas 7.1,7.2not in xsd (appendix B) -
My review is focused on the changes listed in the change log, as this is a rather mature document. Just a couple of minor notes:
- In Section 3.5 "TIMESYS Element", the description of timeorigin notes that Besselian years are tied to the ET timescale, but "ET" is not a permitted value for timescale. Looking at the vocabulary, it seems ET is equivalent to the TT timescale. It would make sense then to note parenthetically that ET is equivalent to TT as a convenience for readers and users. For example: "...and Besselian years to the ET (equivalent to TT) timescale...".
- If the "positioning advice for ID and corresponding references" is referring to the fourth paragraph of section 3.2 "name, ID and ref attributes" (i.e., "The relative position of an ID..."), then I don't see that any advice is being provided. There is a statement that position might have an effect, and that the effect might be positive or negative depending on some unspecified circumstances, but there is no guidance and no actionable information offered. I would expect, for example, a statement along the lines of, "Typically, placing the ID first in the stream improves performance, but when [some unusual circumstance] occurs, placing the reference(s) first may decrease overall processing time." Or, if it is less certain than that, something like "The relative position of ID and ref can affect the performance of streaming parsers [in some specified way], but the direction and magnitude of the effect is context-dependent and difficult to predict."
--
AnneRaugh - 2024-06-25
TCG Vote
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.
Group |
Yes |
No |
Abstain |
Comments |
TCG |
|
|
|
|
Apps |
|
|
|
|
DAL |
|
|
|
|
DM |
|
|
|
|
GWS |
X |
|
|
|
Registry |
X |
|
|
|
Semantics |
|
|
|
|
DCP |
X |
|
|
see also reports |
Edu |
|
|
|
|
KDIG |
|
|
|
|
Ops |
|
|
|
|
Radio |
|
|
|
|
SSIG |
X |
|
|
|
Theory |
|
|
|
|
TD |
|
|
|
|
<nop>StdProc |
|
|
|
|