TWiki
>
IVOA Web
>
IvoaDAL
>
AccessData
>
SODA
>
SODARFC
(revision 3) (raw view)
Edit
Attach
---++ %RED% SODA %ENDCOLOR% RFC This document will act as *RFC* centre for the %RED% SODA http://www.ivoa.net/documents/SODA/index.html %ENDCOLOR%. Review period: %RED% 12th October to 24th November 2016 %ENDCOLOR% 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 TWiki.WikiName so 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. Discussion about any of the comments or responses should be conducted on the %RED% DAL WG mailing list, dal@ivoa.net %ENDCOLOR%. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document. ---++ Implementations %RED% Links and description of existing interoperable implementations %ENDCOLOR% * CADC SODA service descriptors. see http://mail.ivoa.net/pipermail/dal/2016-March/007370.html ++ SODA sync service resourceIdentifier : ivo://cadc.nrc.ca/soda#sync standardID : ivo://ivoa.net/std/SODA#sync-1.0 accessURL : http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/caom2ops/sync ++ SODA async resourceIdentifier : ivo://cadc.nrc.ca/soda#async standardID ivo://ivoa.net/std/SODA#async-1.0 accessURL http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/caom2ops/async" * GAVO SODA half client and ... server see : http://mail.ivoa.net/pipermail/dal/2016-March/007414.html * CASDA home page. Restricted access https://casda.csiro.au/casda_data_access/ * CASDA validator https://github.com/csiro-rds/sodalint ---++ Comments from the Community --- * Sample comment (by IVOA.BrunoRino): ... * Response (by _authorname_): ... --- ---++ Comments from Pierre Fernique <br />1) This document is clearly technical and requires the knowledge of several other IVOA documents. The section 4 is a great help to understand the associated relations. But the addition of a dedicated schema showing the SODA interactions with the other IVOA protocols directly connected to SODA (TAP, SIAv2, DATALINK) just after the general usual global IVOA protocol schema could help a little bit more.<br /><br />2) <strong>Document factoring suggestions:</strong><br />- The usage of very small subsections (page 6 and follows) describing usecases could be refactored in a list of items and sub-items.<br />- The multiple repetition of bibliographic reference should be avoid (ex: page 12)<br /><br />3) <strong>Coherence:</strong><br />- Some utype uses domain prefix (obscore:) and some others forget de domain prefix (exemple page 15 3.2.7)<br />- The font for Obscore label is not always homogeneized (ex: 4.3 "content-type", "access_format", "access_url").<br /><br />4) <strong>Missing definition:</strong><br />- The three-Factor semantic should be described a little bit more. It is difficult to see the relation with the way to express the parameter (page 15)<br />- The "resourceIdentifier" parameter is not described in the document => "If the service is registered, the provider can include a resourceIdentifier parameter" (page 18)<br /><br />7)<strong> Questions/suggestions:</strong><br />- It appears quite strange to express a MAX value for structured objects (CIRCLE, POLYGON, ...) thanks to the VOTable VALUES element. What MAX mean in such case ? I suppose that the idea is to provide the limit of the query region. In the text, it is said that it should be taken as a suggested values. I am a quite uncomfortable with this VOTable usage.<br />- May be, emphasis the fact that the HTTP error code must be properly set (4xx or 5xx)<br />- Page 22, it is said: "<em>For example, if an {async} job included two CIRCLE and two BAND values, there must be four results</em>" => is it really reasonnable to let open this possibility difficult to understand/manage both for the client and the server ? I see this sentence more as an illustration of the lack of boolean contraints on multiple parameters. I would suggest to adopt the AND implicite rule rather to provide all the possible combinations<br /><br />8 ) <strong>Typos:</strong><br />p5 - "SODA servces" => "i" missing<br />p5 - 1.1.2 "descibed" => described<br />p13 - "of ther data" -> remove "r"<br />p13 - "SODA Filtering" => F should be in lowercase<br />p15 - 3.2.7 => simple quote => double quote (utype 'obscore...)<br />p16 ""Wthin" => "Within"<br />p16 ""servces" => "services"<br />page 17 "descrbes" => "describes"<br />page 18 - "obs_puclishder_did" => "obs_publisher_did"<br />page 18 - "obs_publishder_did" -> "obs_publisher_did"<br />page 19 "data-" => "data"<br />page 22 "nomative" => "normative"<br />page 22 - "re-organised" => "R" uppercase<br />page 22 - "patameters" => "parameters" -- IVOA.PierreFernique - 2016-10-20 ---++ Comments from TCG members during the TCG Review Period: 2016-10-12 to 2016-11-24 WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory. ---+++ TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler_ ) ---+++ Applications Working Group ( _Pierre Fernique, Tom Donaldson_ ) ---+++ Data Access Layer Working Group ( _François Bonnarel, Marco Molinaro_ ) ---+++ Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel_ ) ---+++ Grid & Web Services Working Group ( _Brian Major, Giuliano Taffoni_ ) ---+++ Registry Working Group ( _Markus Demleitner, Theresa Dower_ ) Though this may be odd coming from Registry, and though I'm usually totally in favour of standards regulating their Registry aspects, in this particular case my feeling is that the standard has very little relationship to the Registry, and it would benefit from removing most of the references to it. This would mean: (1) p.5, "First, a SODA service could be found in the IVOA Registry and used directly." -- since it is impossible to know a dataset identifier (or the parameters supported by a SODA service) in this scenario, and even if (e.g., from an examples document) you had that it's hard to imagine what useful purpose could be served by such a thing, I think this sentence should be taken out. (2) p.5, "Since the discovery of SODA services ... make use of a registry extension" -- I'd strike that sentence, too. The consequence implied here is tenuous at best (parameters are actually declared within the interface, whereas capability metadata will typically cover things that aren't in the Datalink descriptor), and we don't have to apologise for not defining a registry extension anyway. This also lets us drop 1.1.1, together with the "see also" to 4.1, which in turns largely repeats 1.1.1 only adding that it "is not expected to be a common usage pattern". So, 4.1 could go, too. Since the sections are not wrong as such, I'm not insisting, but the document certainly would be shorter and clearer without them. Actually, I *can* see two use cases for having SODA services registred: (a) Users might at some point search for "resources with associated SODA service"; the scenario here could be that a user has located a service but wants a SODA-enabled version of it. How likely that is I can't say. (b) Infrastructure might look for SODA services to validate. Together with an examples page that might even be possible. In both cases I think the story isn't terribly strong, so I'm not suggesting even mentioning either in the document. Having said that, Registry approves. -- IVOA.MarkusDemleitner - 2016-11-23 ---+++ Semantics Working Group ( _Mireille Louys, Alberto Accomazzi_ ) ---+++ Education Interest Group ( _Massimo Ramella, Sudhanshu Barway_ ) ---+++ Time Domain Interest Group ( _John Swinbank, Dave Morris_ ) ---+++ Data Curation & Preservation Interest Group ( _Françoise Genova_ ) ---+++ Operations Interest Group ( _Tom !McGlynn, Mark Taylor_ ) ---+++ Knowledge Discovery Interest Group ( _Kaï Polsterer_ ) ---+++ Theory Interest Group ( _Carlos Rodrigo_ ) ---+++ Standards and Processes Committee ( _Françoise Genova_) <br /> <!-- * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup -->
Edit
|
Attach
|
Watch
|
P
rint version
|
H
istory
:
r25
|
r5
<
r4
<
r3
<
r2
|
B
acklinks
|
V
iew topic
|
Raw edit
|
More topic actions...
Topic revision: r3 - 2016-11-23
-
MarkusDemleitner
IVOA
Log in
or
Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Applications
Data Access Layer
Data Model
Grid & Web Services
Registry
Semantics
Interest Groups
Data Curation
Education
Knowledge Discovery
Operations
Radio Astronomy
Solar System
Theory
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema
Copyright © 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