Server-side Operations for Data Access version 1.0 Proposed Erratum 1: ID parameter UCD amendmentAuthor: Marco Molinaro Date last changed: 2019-04-18 | ||||||||
Changed: | ||||||||
< < | <-- Date accepted|rejected: 20NN-MM-DD --> | |||||||
> > | Date accepted: 2019-05-12 | |||||||
RationaleThe 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 mainly thought for interpretation of custom parameters in service descriptors. In the case of a parameter that is 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 asmeta.ref.url;meta.curation.SODAThis 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:
Erratum ContentThis Erratum proposes the following changes.ID descriptionIn §3.2.1 "*ID*" of SODA-1.0, update the UCD in the sentenceThe UCD describing the ID parameter is meta.ref.url;meta.curation.SODAfrom meta.ref.url;meta.curation.SODAto meta.id;meta.dataset Three-factor tablesIn §3.5 "*Three-Factor Semantics*" change the UCD value for the ID parameter in Tables 3 & 4 from frommeta.ref.url;meta.curationto meta.id;meta.dataset SODA sync service descriptor exampleIn 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 AssessmentBeing the UCD is only used in SODA to uniquely describe 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.<--
|
Server-side Operations for Data Access version 1.0 Proposed Erratum 1: ID parameter UCD amendmentAuthor: Marco Molinaro Date last changed: 2019-04-18<-- Date accepted|rejected: 20NN-MM-DD --> RationaleThe SODA (version 1.0) protocol uses the ID parameter to specify opaque identifiers to the dataset or file to be accessed. | ||||||||
Changed: | ||||||||
< < | 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. | |||||||
> > | Three-factor semantics (Name, UCD, Unit) was mainly thought for interpretation of custom parameters in service descriptors. In the case of a parameter that is 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.SODAThis 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:
Erratum ContentThis Erratum proposes the following changes.ID descriptionIn §3.2.1 "*ID*" of SODA-1.0, update the UCD in the sentenceThe UCD describing the ID parameter is meta.ref.url;meta.curation.SODAfrom meta.ref.url;meta.curation.SODAto meta.id;meta.dataset Three-factor tablesIn §3.5 "*Three-Factor Semantics*" change the UCD value for the ID parameter in Tables 3 & 4 from frommeta.ref.url;meta.curationto meta.id;meta.dataset SODA sync service descriptor exampleIn 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 | ||||||||
Changed: | ||||||||
< < | 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). | |||||||
> > | Being the UCD is only used in SODA to uniquely describe 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.
<--
|
| ||||||||
Changed: | ||||||||
< < | Server-side Opertaion for Data Access version 1.0 Proposed Erratum 1: ID parameter UCD amendment | |||||||
> > | Server-side Operations for Data Access version 1.0 Proposed Erratum 1: ID parameter UCD amendment | |||||||
Author: Marco Molinaro
Date last changed: 2019-04-18
<-- Date accepted|rejected: 20NN-MM-DD --> Rationale | ||||||||
Changed: | ||||||||
< < | The SODA (version 1.0) protocol uses the ID parameter to specify opaque identifiers to the dataset or file to be accessed. | |||||||
> > | The SODA (version 1.0) protocol uses the ID parameter to specify opaque identifiers to the dataset or file to be accessed. | |||||||
Changed: | ||||||||
< < | Three-factor semantics (Name, UCD, Unit) was meanly thought for interpretation of custom parameters in service descriptors. | |||||||
> > | 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. | |||||||
Deleted: | ||||||||
< < | 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.SODAThis 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:
Erratum ContentThis Erratum proposes the following changes.ID description | ||||||||
Added: | ||||||||
> > | ||||||||
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 | ||||||||
Added: | ||||||||
> > | ||||||||
from
meta.ref.url;meta.curation.SODA | ||||||||
Added: | ||||||||
> > | ||||||||
to
meta.id;meta.dataset Three-factor tables | ||||||||
Changed: | ||||||||
< < | In §3.5 "*Three-Factor Semantics*" change the UCD value for the ID parameter in Tables 3 & 4 from from | |||||||
> > | 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 | ||||||||
Added: | ||||||||
> > | ||||||||
to
meta.id;meta.dataset SODA sync service descriptor example | ||||||||
Added: | ||||||||
> > | ||||||||
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> | ||||||||
Added: | ||||||||
> > | ||||||||
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 | ||||||||
Changed: | ||||||||
< < | 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). | |||||||
> > | 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). | |||||||
Changed: | ||||||||
< < | On the client side, changing a UCD will break clients using 3-factor | |||||||
> > | 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. | |||||||
Deleted: | ||||||||
< < | 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. | |||||||
Changed: | ||||||||
< < | The safety of changing this UCD is also plausible in view of the | |||||||
> > | 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. | |||||||
Deleted: | ||||||||
< < | 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. | |||||||
<--
|
Server-side Opertaion for Data Access version 1.0 Proposed Erratum 1: ID parameter UCD amendmentAuthor: Marco Molinaro | ||||||||
Changed: | ||||||||
< < | Date last changed: 2019-04-17 | |||||||
> > | Date last changed: 2019-04-18 | |||||||
<-- Date accepted|rejected: 20NN-MM-DD --> Rationale | ||||||||
Changed: | ||||||||
< < | 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 | |||||||
> > | The SODA (version 1.0) protocol uses the ID parameter to specify opaque identifiers to the dataset or file to be accessed. | |||||||
Added: | ||||||||
> > | 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.SODAThis 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:
Erratum Content | ||||||||
Changed: | ||||||||
< < | This Erratum proposes to change, in §3.2.1 "*ID*" of SODA - Version 1.0, the UCD in the sentence | |||||||
> > | This Erratum proposes the following changes. | |||||||
Deleted: | ||||||||
< < | The UCD describing the ID parameter is meta.ref.url;meta.curation.SODA | |||||||
Added: | ||||||||
> > | ID descriptionIn §3.2.1 "*ID*" of SODA-1.0, update the UCD in the sentenceThe UCD describing the ID parameter is meta.ref.url;meta.curation.SODA | |||||||
from | ||||||||
Deleted: | ||||||||
< < | ||||||||
meta.ref.url;meta.curation.SODA | ||||||||
Added: | ||||||||
> > | to
meta.id;meta.dataset | |||||||
Added: | ||||||||
> > | Three-factor tablesIn §3.5 "*Three-Factor Semantics*" change the UCD value for the ID parameter in Tables 3 & 4 from frommeta.ref.url;meta.curation | |||||||
to | ||||||||
Added: | ||||||||
> > | meta.id;meta.dataset | |||||||
Changed: | ||||||||
< < | meta.id;meta.dataset. | |||||||
> > | SODA sync service descriptor example | |||||||
Added: | ||||||||
> > | 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 AssessmentBeing 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.<--
|
Server-side Opertaion for Data Access version 1.0 Proposed Erratum 1: ID parameter UCD amendmentAuthor: Marco Molinaro | ||||||||
Changed: | ||||||||
< < | Date last changed: 2019-04-16 | |||||||
> > | Date last changed: 2019-04-17 | |||||||
<-- Date accepted|rejected: 20NN-MM-DD --> RationaleSODA 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 asmeta.ref.url;meta.curation.SODAThis 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. | ||||||||
Added: | ||||||||
> > | To remedy the situation we propose here to use meta.id;meta.dataset instead. This achieves:
| |||||||
Erratum Content | ||||||||
Changed: | ||||||||
< < | 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.SODAfrom meta.ref.url;meta.curation.SODAto | ||||||||
Changed: | ||||||||
< < | meta.id;meta.dataset | |||||||
> > | meta.id;meta.dataset. | |||||||
Deleted: | ||||||||
< < | thus achieving:
| |||||||
Impact Assessment | ||||||||
Changed: | ||||||||
< < | 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). | |||||||
Added: | ||||||||
> > | 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. | |||||||
<--
|
Server-side Opertaion for Data Access version 1.0 Proposed Erratum 1: ID parameter UCD amendmentAuthor: Marco Molinaro Date last changed: 2019-04-16<-- Date accepted|rejected: 20NN-MM-DD --> Rationale | ||||||||
Changed: | ||||||||
< < | SODA protocol uses the ID parameter to specify opaque identifiers to the dataset or file to be accessed. | |||||||
> > | 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 | |||||||
Deleted: | ||||||||
< < | The UCD specified in the SODA-embedded 3-factor semantics is reported in the REC text as | |||||||
meta.ref.url;meta.curation.SODA | ||||||||
Deleted: | ||||||||
< < | 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. | |||||||
Added: | ||||||||
> > | 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. | |||||||
Erratum Content | ||||||||
Changed: | ||||||||
< < | This Erratum proposes to change, in §3.2.1 "*ID*" of SODA - Version 1.0 | |||||||
> > | This Erratum proposes to change, in §3.2.1 "*ID*" of SODA - Version 1.0 the UCD in the sentence | |||||||
Deleted: | ||||||||
< < | the UCD in the sentence | |||||||
The UCD describing the ID parameter is meta.ref.url;meta.curation.SODAfrom meta.ref.url;meta.curation.SODAto meta.id;meta.datasetthus achieving:
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Impact Assessment | ||||||||
Changed: | ||||||||
< < | 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 | |||||||
> > | 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). | |||||||
Deleted: | ||||||||
< < | on the service provider's side (requiring the UCD amendment a releasing it). On the client side it has o be evaluated whether applications need changes. However it has to be noticed that there are few SODA service currently in place (and none registered). | |||||||
<--
|
Server-side Opertaion for Data Access version 1.0 Proposed Erratum 1: ID parameter UCD amendmentAuthor: Marco Molinaro | ||||||||
Changed: | ||||||||
< < | Date last changed: 2019-04-12 | |||||||
> > | Date last changed: 2019-04-16 | |||||||
<-- Date accepted|rejected: 20NN-MM-DD --> RationaleSODA 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 asmeta.ref.url;meta.curation.SODAThis 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. Erratum ContentThis Erratum proposes to change, in §3.2.1 "*ID*" of SODA - Version 1.0 the UCD in the sentenceThe UCD describing the ID parameter is meta.ref.url;meta.curation.SODAfrom meta.ref.url;meta.curation.SODAto | ||||||||
Changed: | ||||||||
< < | meta.ref.uri;meta.dataset | |||||||
> > | meta.id;meta.dataset | |||||||
Changed: | ||||||||
< < | amending so the typo, the reference to a dataset rather than an organization and using a UCD referring to an identifier rather than a resource locator. Using meta.id won't work together with meta.ref.uri being both P UCD words. | |||||||
> > | thus achieving:
| |||||||
Added: | ||||||||
> > |
| |||||||
Impact Assessment | ||||||||
Changed: | ||||||||
< < | Being the UCD only used in SODA to describe uniquely the ID parameter using the 3-factor semantics, this change won't probably have any impact on the service provider's side (requiring only a change in the service description). On the client side it has o be evaluated whether applications need | |||||||
> > | 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 a releasing it). On the client side it has o be evaluated whether applications need | |||||||
changes. However it has to be noticed that there are few SODA service currently in place (and none registered).
<--
|
Server-side Opertaion for Data Access version 1.0 Proposed Erratum 1: ID parameter UCD amendmentAuthor: Marco Molinaro Date last changed: 2019-04-12<-- Date accepted|rejected: 20NN-MM-DD --> RationaleSODA 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 asmeta.ref.url;meta.curation.SODAThis 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. Erratum ContentThis Erratum proposes to change, in §3.2.1 "*ID*" of SODA - Version 1.0 the UCD in the sentenceThe UCD describing the ID parameter is meta.ref.url;meta.curation.SODAfrom meta.ref.url;meta.curation.SODAto meta.ref.uri;meta.datasetamending so the typo, the reference to a dataset rather than an organization and using a UCD referring to an identifier rather than a resource locator. Using meta.id won't work together with meta.ref.uri being both P UCD words. Impact AssessmentBeing the UCD only used in SODA to describe uniquely the ID parameter using the 3-factor semantics, this change won't probably have any impact on the service provider's side (requiring only a change in the service description). On the client side it has o be evaluated whether applications need changes. However it has to be noticed that there are few SODA service currently in place (and none registered).<--
|