International Virtual Observatory Alliance

Difference: SODA-1_0-Err-1 (3 vs. 4)

Revision 42019-04-17 - MarcoMolinaro

  META TOPICPARENT 
  name="SODA-1_0-Errata"  

 Server-side Opertaion for Data Access version 1.0 Proposed Erratum 1: ID parameter UCD amendment 

Author: Marco Molinaro
- META TOPICPARENT
+  name="SODA-1_0-Errata"
-<
<
+Date last changed: 2019-04-16
->
>
+Date last changed: 2019-04-17
 <-- Date accepted|rejected: 20NN-MM-DD -->

 Rationale 

SODA protocol uses the ID parameter to specify opaque identifiers to the dataset or file to be accessed. The UCD specified in the SODA-embedded 3-factor semantics is reported in the REC text as
meta.ref.url;meta.curation.SODA

This is not a valid UCD both for the, probably, typo of the added .SODA part and the fact that meta.curation identifies a man/organization responsible for the data as per the UCD vocabulary.
->
>
+To remedy the situation we propose here to use meta.id;meta.dataset instead. This achieves: 
 typo amendment;
  reference to a dataset rather than an organization;
  using a UCD referring to an identifier rather than a resource locator;
  keeping the identifier opaque as required by the specification.
  Erratum Content
-<
<
+This Erratum proposes to change, in §3.2.1 "*ID*" of SODA - Version 1.0 the UCD in the sentence
->
>
+This Erratum proposes to change, in §3.2.1 "*ID*" of SODA - Version 1.0, the UCD in the sentence
 The UCD describing the ID parameter is meta.ref.url;meta.curation.SODA


from

meta.ref.url;meta.curation.SODA

to
-<
<
+meta.id;meta.dataset
->
>
+meta.id;meta.dataset
.
-<
<
+thus achieving: 
 typo amendment
  reference to a dataset rather than an organization
  using a UCD referring to an identifier rather than a resource locator
  keeping the identifier opaque as required by the specification
  Impact Assessment
-<
<
+Being the UCD only used in SODA to describe uniquely the ID parameter using the 3-factor semantics, this change will have a minimal impact on the service provider's side (requiring the UCD amendment and releasing it). On the client side it has to be evaluated whether applications need changes. However it has to be noticed that there are few SODA service currently in place (and none registered).
->
>
+Being the UCD only used in SODA to describe uniquely the ID parameter using the 3-factor semantics, this change will have a minimal impact on the service provider's side (requiring the UCD amendment and releasing it).
->
>
+On the client side, changing a UCD will break clients using 3-factor
semantics to find the parameter to pass the identifier in.
However, as ID is defined by both Datalink and SODA and no
competing definition ever existed, no known client actually uses
3-factor semantics to locate the ID parameter and instead just uses
the hard-coded name ID.  Hence, to our knowledge the UCD changed
here is ignored by clients, and no breakage will occur.  

The safety of changing this UCD is also plausible in view of the
fact that several data centers (e.g., GAVO's Heidelberg data
center; example here)
have been successfully operating SODA services that used
meta.id;meta.main as a UCD for ID without interoperabilty issues.
 <-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

View topic | History: r8 < r7 < r6 < r5 | More topic actions...