Request For Comment: VODataService v1.1

VOResource Proposed Recommendation: Request for Comments

This document will act as RFC center for the Proposed Recommendation entitled "VODataService: a VOResource Schema Extension for Describing Collections and Services version 1.1". The specification has been revised as a result of the RFC review and can be found at http://www.ivoa.net/Documents/VODataService/20100412/PR-VODataService-1.1-20100412.html.

RFC Review period: 30 Sept 2009 - 30 Oct 2009.
TCG Review period: 15 April 2010 - 15 May 2010

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 WikiName 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 Resource Registry mailing list, registry@ivoa.net. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

Notes on Implementations and Validaters

The VODataService page includes five compliant sample VOResource instances that use the VODataService extension. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes).


Comments from the community

These comments below were based on the 20090903 version.

Comments from TCG members during the normal RFC period

Applications (Tom McGlynn, Mark Taylor)

Data Access Layer (Keith Noddle, Jesus Salgado)

Data Model (Mireille Louys, AnitaRichards)

MireilleLouys section 3.2 Coverage

Coverage.RegionOfRegard : The "Semantic meaning" described and the "Comments" attached to this piece of metadata do not match. One might think this value can contain anything, and then will not be used. What is the exact purpose of such a value?

RayPlante responds: This text is lifted from the RM standard definition for this text (see 1st paragraph of VODataService spec, section 3). The purpose is given by the semantic meaning. The idea, in other words, is that it is a (smallest) representative size that has informational meaning in the dataset. This size can be characterized by different measures, depending on the type of dataset. Yes, we know its a bit fuzzy, but it is this is from the RM and at least one application has used it.

Grid&Web Sevices (Matthew Graham, Paul Harrison)

Registry (Ray Plante, Aurelien Stebe)

The VOSI spec highlights our current lack of an Interface type that (semantically) represents a simple web resource represented by a static URL that returns the underlying data (i.e. a GET on a REST-ful resource). Without this, we don't have a good way to describe VOSI capabilities without breaking the semantics of the existing Interface types.

I propose, therefore, that we add a new Interface type to cover this called "WebResource" that, in addition to the service URL, allows an optional element "resultType" that gives the MIME type of the response.

-- RayPlante - 27 Oct 2009

RayPlante replies: In an email discussion on the list (registry/0910/2080.htm, see also grid/0910/0736.htm), Guy recommended a use of "!ParamHTTP" that represents a simple web resource as a degenerate form. I'm happy to accept this interpretation and avoid this addition. (I mean what was the above commenter thinking?! wink )

Semantics (Sebastien Derriere, Norman Gray)

VOEvent (Rob Seaman, Alasdair Allan)

VO Query Language (Pedro Osuna, Yuji Shirasaki)

VOTable (Francois Ochsenbein)

Standard and Processes (Francoise Genova)

Astro RG (Masatoshi Ohishi)

Data Curation & Preservation (Bob Hanisch)

I read through the main body of the document fairly carefully, and found a number of typos and many non-working links. I will send a list to the editor. The only more general comment is that the section "Syntax Notation Using XML Schema" that precedes the TOC seems to belong in the main Introduction, in particular because specific recommendations are being made. This seems out of place in the preamble.

RayPlante responds: The intent of this paragraph is really to explain the notational convention for qualified names and tries to point out the consistency with the recommendation given elsewhere (RI). Thus, I would rather reword this to better reflect its purpose than to suggest that it is giving a specific recommendation.

Theory (Herve Wozniak, Claudio Gheller)

TCG (ChristopheArviset, Severin Gaudet)


Comments from TCG during TCG Review (15 Apr 2010 to 15 May 2010)

Applications (Tom McGlynn, Mark Taylor)

Approved (Mark, for Tom)

Data Access Layer (Patrick Dowler, Mike Fitzpatrick)

In the table on vs:Coverage in section 3.2, I think the bounds for the UV are wrong. The upper bound should be 300nm or 3000A, not 3000nm or 30,000A.

With this typo fixed, I approve this document. --PatrickDowler 2010-07-02

RayPlante responds: Fixed. thanks!

Data Model (Mireille Louys, AnitaRichards)

MireilleLouys -2010 July 14-

I approve the document. It follows a didactic approach and provides all necessary details in a clear and easy to read manner. It touches concepts that other groups like Data Model can reuse, like for instance data types, waveband names definition, etc.

I found a few typos I sent directly to the editor and to the registry list. Here below are the main comments I think should be considered/discussed prior to final approval.

section 2.2

Coverage is mentionned through out the document as representing the extent of the resource on sky, time, frequency space... At one place or another , I think it would help to mention the spectral domain covered by the resource as a whole, can be expressed in the STCResource Profile, with wavelentgh or Energy and the corresponding units. To realise that , the reader will have to point to the STC doc and check the example section.

section 3.2 Coverage

A comment or question here:

The STC Resource profile is based on various coordinates frames. Would it be relevant for some data collection to use the RedshiftFrame too as it is available in the STC AstroCoord system definition? Any example?

section 3.3.3

Comment : this section is very technical . I would find my way easier with an example of an XML document including Table elements. It was effective with the foreignkey example.

section 3.5

If possible rephrase and simplify : 'The content of a data type element of this type is the name of the data type for the current parameter.' This DataType section is very interesting for other models to define basic types and derive new ones from them .

Could we add examples here too to encourage re-usability?

section 'References'

use instead http://www.ivoa.net/Documents/RegistryInterface/

Grid&Web Sevices (Matthew Graham, Paul Harrison)

Registry (Ray Plante, Gretchen Greene)

I approve this document.

Semantics (Sebastien Derriere, Norman Gray)

I approve this document. SD.

VOEvent (Rob Seaman, Alasdair Allan)

Approved.

VO Query Language (Pedro Osuna, Yuji Shirasaki)

VOTable (Francois Ochsenbein)

Standard and Processes (Francoise Genova)

Data Curation & Preservation (Bob Hanisch, 16 April 2010)

In the list of revisions since the previous version it would be helpful to have section numbers for where the changes occur.

I found a few more usage errors...

In the opening paragraph on Conformance-related definitions, last sentence, "goes" should be "go".

Under Syntax Notation Using XML Schema, first sentence, "is document syntax" should be "is a document syntax".

First and second sentences, third paragraph of the same section, should both start with "References" instead of "Reference".

Introduction, first paragraph, I think "modular" might be a better word than "piecemeal".

Second paragraph, "contains" --> "contain".

In 2.2, vs:StandardSTC, last sentence, "Coordinate system" -> "Coordinate systems".

Last paragraph of 2.2, "and a textual description the argument" -> "and a textual description of the argument".

In 3.1.1, "is a logical group of data composed of one or more accessible datasets" -> "is a logical group of data comprising one or more accessible datasets".

Otherwise things look ok to me, although I did not recheck links or any text in the examples.

Theory (Herve Wozniak, Claudio Gheller)

Approved.

TCG (ChristopheArviset, 26 April 2010)

I approve the document. Thanks to the explanation in Appendix B, explaining why we go "directly" to REC VODataService 1.1.

The following changes should probably be made in the next version:

  • Please use the agreed naming nomenclature, ie : PR-VODataService-1.1-20100412

  • In the Acknowledgments, there is a typo "European" (missing "o"). In general, I'm not sure if we should make reference to these old FP6 and OPTICON funding. I'll ask Francoise about this.

  • In the References section, please update RI (now REC 1.0 20091104), TAP (now REC 1.0) and VOTable (now REC 1.2)


Edit | Attach | Watch | Print version | History: r24 < r23 < r22 < r21 < r20 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r22 - 2010-07-14 - MireilleLouys
 
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