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?! )
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)
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.
RayPlante responds: I added a note in 3.2 to this effect.
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?
RayPlante responds: This would be syntacticly legal and otherwise compliant with this spec. I'm not prepared to make recommendations about whether and when to use this as I do not have a specific use case in mind for how it will get used. At the moment, we do not have many tools that can make use of this information--even for display purposes, so I'm reluctant at this time to emphasize this ability.
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.
RayPlante responds: This section summarizes four techniques that could be used to add extended metadata. These techniques were intended to address comments about additional stuff thet we might need in the future, but do not clearly see today. I'm concerned about the bulk that sufficiently useful examples would take up for this less critical part of the document. As this feature is not one that is likely to get used in most resource descriptions, I would prefer to see, if needed, a separate document that can provide such examples.
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?
RayPlante responds: I reworded the sentence a bit: 'The content of an element of type
vs:DataType
is the name
of the data type for the current parameter.'
Examples of more common use appear in the subsequent sections.
section 'References'
use instead
http://www.ivoa.net/Documents/RegistryInterface/
RayPlante responds: fixed
Grid&Web Sevices (Matthew Graham, Paul Harrison)
I approve this document.
--
MatthewGraham - 16 Jul 2010
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.
RayPlante responds: fixed
Theory (Herve Wozniak, Claudio Gheller)
Approved.
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)
RayPlante responds: fixed