Server-side Opertaion for Data Access version 1.0 Proposed Erratum 1: ID parameter UCD amendment
Author: Marco Molinaro
Date last changed: 2019-04-18
Rationale
The
SODA (version 1.0) protocol uses the
ID parameter to specify opaque identifiers to the dataset or file to be accessed.
Three-factor semantics (Name, UCD, Unit) was meanly thought for interpretation of custom parameters in service descriptors.
In the case of a parameter part of a standard, like the above SODA
ID, the definition of the parameter
is unambiguous. However a 3-factor description is still useful for homegeneity and comparison to
other parameters.
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 the following changes.
ID description
In
§3.2.1 "*ID*" of SODA-1.0, update 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
Three-factor tables
In
§3.5 "*Three-Factor Semantics*" change the UCD value for the ID parameter in
Tables 3 & 4 from
from
meta.ref.url;meta.curation
to
meta.id;meta.dataset
SODA sync service descriptor example
In the
example in
§4 "*Integration of Service Capabilities*" change the ID PARAM from
<PARAM name="ID"
ucd="meta.ref.url;meta.curation"
ref="idcolumn-ref"
datatype="char" arraysize="*" value="" >
<DESCRIPTION>The publisher DID of the dataset of interest</DESCRIPTION>
</PARAM>
to
<PARAM name="ID"
ucd="meta.id;meta.dataset"
ref="idcolumn-ref"
datatype="char" arraysize="*" value="" >
<DESCRIPTION>The publisher DID of the dataset of interest</DESCRIPTION>
</PARAM>
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, 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.