VOTable v1.3: Request For Comments

This page contains public discussion of the VOTable v1.3 Proposed Recommendation. The RFC is announced on 29 March 2013 and will run until 29 April 2013.

Version under review

PR-VOTable-1.3-20130315

RFC Review Period

29 March 2013 - 29 April 2013

Change Overview

Changes since the previous version 1.2 are mainly in the areas of representation of null values and serialization. A detailed list of the changes is available in section 9.2 of the document.

This version of the document has been developed within the public subversion repository Volute, in directory projects/votable, where the exact changes made to the LaTeX source and XML Schema can be seen.

Implementations and Validators

VOTable 1.3 has been implemented in the following software items:

• STIL 3.0-4/STILTS 2.5/TOPCAT 4.0b (set system property votable.version=1.3 in STILTS/TOPCAT for VOTable v1.3 output)
• The GAVO TAP service at http://dc.g-vo.org/tap
• Aladin beta 7.547 is now supporting VOTable 1.3 for reading (BINARY2 + LINK + note 1.2/2.0 "STC in VOTable")

-- MarkTaylor - 2013-03-28

In order to add a comment to the document, please edit this page and add your comment to the list below. 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 may be conducted on the votable@ivoa.net mailing list. However, please enter your initial comments here for full consideration in any future revisions of this document.

IVOA Community Comments during the RFC period (29 March 2013 - 26 April 2013)

(please add comments here)

TCG Comments during the RFC period (29 Match 2013 - 26 April 2013)

(TCG members are encouraged to consider the document during the RFC stage so that any problems can be addressed before the TCG Review stage when the chair or vice chair of each WG will be required to review it).

Theory Interest Group

Comments by Franck on the 2nd April 2013

As mentionned during the discussions on the mailing list, it would be useful the document would be more precise on the way to include semantics concepts (as SKOS) in a VO-Table.

Mark suggested two solutions :

1) external communities (like Theory I.G.) could define their own conventions like content-role="skos"

2) use content-role="type"

Maybe solution 2 is better than solution 1 since somebody implementing VO-Table may not be aware of all the possibilities defined by each community.

So would it be possible to specify this in the documentation of VO-Table adding, in section 3.5, the sentence suggested by Mark during the discussions on the mailing list :

"This content-role value would for instance be appropriate to mark the LINK's href value as a SKOS concept."

Comments from NormanGray, 2013-04-04:

I agree that there is scope for external communities to define their own conventions, but I don't think there's a need for such an action here.

The language in the LINK section is intended to suggest that the content-role='type' URL suggests a type-like relationship, carefully avoiding any restriction to SKOS. This appears to create ambiguity, but doesn't really: any application which can make use of one of the values here (such as a 'type' which is a SKOS concept) will 'know' what values it can interpret, and therefore will certainly know what sort of thing (ie a SKOS concept) the value is. This implies (should it be made explicit?) that applications should ignore any types they do not recognise, and that VOTable authors should bear this in mind when writing the VOTable. Any application which wants to be generic here can retrieve the URL (presuming that the maintainers of that URL are following good practice and have made the URL dereferenceable) and that way discover what type of thing it is.

When drafting this section, Mark and I hoped to make this reasonably clear, but still concise. Clarifying edits would I'm sure be welcome.

It would also be useful (this is Franck's off-line suggestion) to have a brief example in the LINK section. Is the following too minimal?

<LINK content-role="type" href="http://purl.org/astronomy/vocab/PhysicalQuantities/Distance"/>

• I have added the suggested text and example in section 3.5 (volute revision 2139) -- MarkTaylor - 2013-04-26

Application Working Group

Comments by Pierre Fernique on the 11th April 2013

Page 14 - 4.7 VALUES Element
The example still used a ref="J2000" reference used in old COOSYS definition and in note 1.2 "STC in VOTable". But this possibility has been removed in the last note (2.0) and prefer to use FIELDref forward referencing method.
I suggest to remove it.

Pierre is absolutely right, both the ref and the utype in that example are spurious traces of Note 1.0 style metadata and should be removed (this is just a redactional change, since the example really is not about either of those, which is why the necessity for the change was not noticed in the first place). Looking for other suprious references in the text, I noticed the XMLDATA example on p. 32 also contains spurious occurrences of ref="J2000" which should be removed (even more so since the fragment doesn't contain a matching element. -- MarkusDemleitner - 2013-04-23

• both done (volute revision 2138) - thanks -- MarkTaylor - 2013-04-26