DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCAT (-- MarkTaylor - 2018-06-13 )These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink -1.0, in terms of new features. Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf An attempt for a new draft is now available here These are the changes which have been discussed (the items numbers are those used in the College Park presentation): 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. The discussion on this has been moved to two github/ivoa-std/DataLink issues : https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore -ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/31 4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/17 5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1) The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/15 6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/16 7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision. The discussion occured actually in the following threads http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html 8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/20 9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/21 10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/22 11 ) - It COULD be useful to provide a human readable description of a service descriptor. This wil be done by using aLinks and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16New issues after virtual interop (gathered by -- FrancoisBonnarel - 2020-05-13)
Changes DataLink -1.1 (around May 2022)• added optional content_qualifier to describe link target content with terms from the product-type vocabulary • added optional link_auth and link_authorized to signal whether au- thentication is necessary to use the link • clarified use of multiple ID values and possible OVERFLOW • clarified use of utype for self-describing service descriptors • clarified use of semantics • generalize by adding use cases for links to content other than data files • added using LINK to convey when datalink request URL is in a table column • service descriptors can include a contentType param to describe service output and should include a name and description • service descriptors can include exampleURL param(s) with working example and description • VOSI-availability and VOSI-capabilities endpoints are now optionalRevised list of changes (January the 4th/5th/6th 2023) and implementation review* List of changes of version 1.1 with respect to version 1.0 (2015) and corresponding DataLink issues on github repository. see : https://github.com/ivoa-std/DataLink for details
| ||||||||
Added: | ||||||||
> > | List of changes following the RFC period and TCG vote | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > |
| |||||||
-- FrancoisBonnarel - 2024-03-14
* discussed, but not integrated in 1.1 yet :
<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCAT (-- MarkTaylor - 2018-06-13 )These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink -1.0, in terms of new features. Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf An attempt for a new draft is now available here These are the changes which have been discussed (the items numbers are those used in the College Park presentation): 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. The discussion on this has been moved to two github/ivoa-std/DataLink issues : https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore -ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/31 4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/17 5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1) The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/15 6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/16 7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision. The discussion occured actually in the following threads http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html 8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/20 9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/21 10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/22 11 ) - It COULD be useful to provide a human readable description of a service descriptor. This wil be done by using aLinks and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16New issues after virtual interop (gathered by -- FrancoisBonnarel - 2020-05-13)
Changes DataLink -1.1 (around May 2022)• added optional content_qualifier to describe link target content with terms from the product-type vocabulary • added optional link_auth and link_authorized to signal whether au- thentication is necessary to use the link • clarified use of multiple ID values and possible OVERFLOW • clarified use of utype for self-describing service descriptors • clarified use of semantics • generalize by adding use cases for links to content other than data files • added using LINK to convey when datalink request URL is in a table column • service descriptors can include a contentType param to describe service output and should include a name and description • service descriptors can include exampleURL param(s) with working example and description • VOSI-availability and VOSI-capabilities endpoints are now optionalRevised list of changes (January the 4th/5th/6th 2023) and implementation review* List of changes of version 1.1 with respect to version 1.0 (2015) and corresponding DataLink issues on github repository. see : https://github.com/ivoa-std/DataLink for details
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > | -- FrancoisBonnarel - 2023-01-17
| |||||||
* discussed, but not integrated in 1.1 yet :
| ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
* Implementation : server side.
GAVO implemented the following changes = content_qualifier and local_semantics, service descriptor additional features such as DESCRIPTION? name, content_type, etc....
As a matter of example, a couple of links response for various obscore/sia/ssa tables in GAVO server
rosat.images : http://dc.zah.uni-heidelberg.de/rosat/q/dl/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3frosat%2fimage_data%2frda_4%2fwg400138p_n1_p1_r2_f2_p1%2frp400138n00_im3.fits.gz where some links have content_qualifier = #image, others have content_qualifier = #event or #timeseries
lamost6.lrs : http://dc.zah.uni-heidelberg.de/lamost6/q/sdl_lrs/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3flamost6%2flrs%2f373006237 where some links have content_qualifier = #spectrum
califadr3.cubes : http://dc.zah.uni-heidelberg.de/califa/q3/dl/dlget?ID=ivo%3A//org.gavo.dc/~%3Fcalifa/datadr3/COMB/ARP220.COMB.rscube.fits where some links have content_qualifier = #cube
ppakm31.maps : http://dc.zah.uni-heidelberg.de/ppakm31/q/cdl/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3fppakm31%2fdata%2fPPAK_M31_F5_cube.fits wher some links have local_semantics filled up and content_qualifier equals #image or #cube
All these are combined with various semantics or content_type values
* implementation : client side
TopCAT prototype (http://andromeda.star.bristol.ac.uk/releases/topcat/pre/topcat-full_datalink11.jar) displays additional features in service descriptor and makes use of additional links table FIELD such as content_qualifier, authorization and local_semantics; The tool behavior is adapted to the content of these new FIELDS. For example Actions suggested by TopCat for the links not only depend on content_type but also from content_qualifier.
AladinDesktop is going to adapt to those new features too.
-- FrancoisBonnarel - 2023-01-06
DataLink11RFC
<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCAT (-- MarkTaylor - 2018-06-13 )These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink -1.0, in terms of new features. Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf An attempt for a new draft is now available here These are the changes which have been discussed (the items numbers are those used in the College Park presentation): 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. The discussion on this has been moved to two github/ivoa-std/DataLink issues : https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore -ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/31 4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/17 5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1) The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/15 6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/16 7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision. The discussion occured actually in the following threads http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html 8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/20 9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/21 10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/22 11 ) - It COULD be useful to provide a human readable description of a service descriptor. This wil be done by using aLinks and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16New issues after virtual interop (gathered by -- FrancoisBonnarel - 2020-05-13)
Changes DataLink -1.1 (around May 2022)• added optional content_qualifier to describe link target content with terms from the product-type vocabulary • added optional link_auth and link_authorized to signal whether au- thentication is necessary to use the link • clarified use of multiple ID values and possible OVERFLOW • clarified use of utype for self-describing service descriptors • clarified use of semantics • generalize by adding use cases for links to content other than data files • added using LINK to convey when datalink request URL is in a table column • service descriptors can include a contentType param to describe service output and should include a name and description • service descriptors can include exampleURL param(s) with working example and description • VOSI-availability and VOSI-capabilities endpoints are now optionalRevised list of changes (January the 4th/5th/6th 2023) and implementation review* List of changes of version 1.1 with respect to version 1.0 (2015) and corresponding DataLink issues on github repository. see : https://github.com/ivoa-std/DataLink for details
| ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
Added: | ||||||||
> > |
| |||||||
* discussed, but not integrated in 1.1 yet :
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | ||||||||
* Implementation : server side.
GAVO implemented the following changes = content_qualifier and local_semantics, service descriptor additional features such as DESCRIPTION? name, content_type, etc....
As a matter of example, a couple of links response for various obscore/sia/ssa tables in GAVO server
rosat.images : http://dc.zah.uni-heidelberg.de/rosat/q/dl/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3frosat%2fimage_data%2frda_4%2fwg400138p_n1_p1_r2_f2_p1%2frp400138n00_im3.fits.gz where some links have content_qualifier = #image, others have content_qualifier = #event or #timeseries
lamost6.lrs : http://dc.zah.uni-heidelberg.de/lamost6/q/sdl_lrs/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3flamost6%2flrs%2f373006237 where some links have content_qualifier = #spectrum
califadr3.cubes : http://dc.zah.uni-heidelberg.de/califa/q3/dl/dlget?ID=ivo%3A//org.gavo.dc/~%3Fcalifa/datadr3/COMB/ARP220.COMB.rscube.fits where some links have content_qualifier = #cube
ppakm31.maps : http://dc.zah.uni-heidelberg.de/ppakm31/q/cdl/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3fppakm31%2fdata%2fPPAK_M31_F5_cube.fits wher some links have local_semantics filled up and content_qualifier equals #image or #cube
All these are combined with various semantics or content_type values
* implementation : client side
TopCAT prototype (http://andromeda.star.bristol.ac.uk/releases/topcat/pre/topcat-full_datalink11.jar) displays additional features in service descriptor and makes use of additional links table FIELD such as content_qualifier, authorization and local_semantics; The tool behavior is adapted to the content of these new FIELDS. For example Actions suggested by TopCat for the links not only depend on content_type but also from content_qualifier.
AladinDesktop is going to adapt to those new features too.
-- FrancoisBonnarel - 2023-01-06
DataLink11RFC
<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCAT (-- MarkTaylor - 2018-06-13 )These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes. | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Proposed Features | ||||||||
Changed: | ||||||||
< < | Suggestion for revision of DataLink-1.0, in terms of new features. | |||||||
> > | Suggestion for revision of DataLink -1.0, in terms of new features. | |||||||
Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf An attempt for a new draft is now available here These are the changes which have been discussed (the items numbers are those used in the College Park presentation): 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. The discussion on this has been moved to two github/ivoa-std/DataLink issues : https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 | ||||||||
Changed: | ||||||||
< < | 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore-ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. | |||||||
> > | 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore -ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. | |||||||
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/31
4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag.
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/17
5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1)
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/15
6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table.
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/16
7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision.
The discussion occured actually in the following threads
http://mail.ivoa.net/pipermail/dal/2019-October/008191.html
http://mail.ivoa.net/pipermail/dal/2019-October/008200.html
http://mail.ivoa.net/pipermail/dal/2019-October/008202.html
8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here.
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/20
9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement.
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/21
10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion.
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/22
11 ) - It COULD be useful to provide a human readable description of a service descriptor. This wil be done by using a Links and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16New issues after virtual interop (gathered by -- FrancoisBonnarel - 2020-05-13)
| ||||||||
Changed: | ||||||||
< < | _As I see it, the things we are discussing concerning Datalink fall into 4 independent levels or categories: Level 0 - Data-format (fits, VOTable, PDF, png, …) Level 1 - Data-type (tabular, image, spectrum, cube, text, …) Level 2 - Data-information (Documentation, Calibration, Log, Preview, …) Level 3 - Data-relation (Derived from, Progenitor of, Sibling of, ...) | |||||||
> > | _As I see it, the things we are discussing concerning Datalink fall into 4 independent levels or categories: Level 0 - Data-format (fits, VOTable, PDF, png, …) Level 1 - Data-type (tabular, image, spectrum, cube, text, …) Level 2 - Data-information (Documentation, Calibration, Log, Preview, …) Level 3 - Data-relation (Derived from, Progenitor of, Sibling of, ...) | |||||||
I see these as orthogonal levels since a list of links can be of any type (level 1) with any kind of format (level 0), any kind of relation (level 3) and could have any type of associated information to describe it (level 2). Today the list of links returned by datalink is described in the columns content-type and semantics. These two columns cover the above levels only up to some degree. Content-type: covers level 0 mainly, with some exceptions such as VOTable (which is also level 1). Semantics: covers level 2 mainly (e.g. preview), but also level 3 (e.g. derivation, progenitor). | ||||||||
Changed: | ||||||||
< < | Datalink at the moment has no field properly covering level 1 and applications (—> users) would benefit from having that well covered. | |||||||
> > | Datalink at the moment has no field properly covering level 1 and applications (—> users) would benefit from having that well covered. | |||||||
Changed: | ||||||||
< < | So, in my opinion, if I had to redo Datalink I would keep these different levels separated instead of putting everything into the semantics field. But applications might have a different point of view here —> Shouldn't we add Apps to this discussion? | |||||||
> > | So, in my opinion, if I had to redo Datalink I would keep these different levels separated instead of putting everything into the semantics field. But applications might have a different point of view here —> Shouldn't we add Apps to this discussion? | |||||||
Changed: | ||||||||
< < | Timeseries would be in level 3, since it is a relation. And I don’t think we would need the use of sibling or progenitor or anything like that for timeseries. What we need is to be able to say is: | |||||||
> > | Timeseries would be in level 3, since it is a relation. And I don’t think we would need the use of sibling or progenitor or anything like that for timeseries. What we need is to be able to say is: | |||||||
"This list of links are time-series of tabular type" "This list of links are time-series of spectrum type" | ||||||||
Changed: | ||||||||
< < | … | |||||||
> > | … | |||||||
But if were to add terms such as sibling and so on, there is already an IVOA relationship vocabulary: http://ivoa.net/rdf/voresource/relationship_type/2016-08-17/relationship_type.html_
| ||||||||
Changed: | ||||||||
< < | For the record, that's not my text, that's Datalink REC-1.0, p. 10. The context is this thread on the DAL list: http://mail.ivoa.net/pipermail/dal/2020-March/008318.html. | |||||||
> > | For the record, that's not my text, that's Datalink REC-1.0, p. 10. The context is this thread on the DAL list: http://mail.ivoa.net/pipermail/dal/2020-March/008318.html. | |||||||
Control by MAXREC or by telling the client there is an overflow ? ```xml | ||||||||
Changed: | ||||||||
< < | Changes DataLink-1.1 (around May 2022) | |||||||
> > | Changes DataLink -1.1 (around May 2022) | |||||||
• added optional content_qualifier to describe link target content with terms from the product-type vocabulary • added optional link_auth and link_authorized to signal whether au- thentication is necessary to use the link • clarified use of multiple ID values and possible OVERFLOW • clarified use of utype for self-describing service descriptors • clarified use of semantics • generalize by adding use cases for links to content other than data files • added using LINK to convey when datalink request URL is in a table column • service descriptors can include a contentType param to describe service output and should include a name and description • service descriptors can include exampleURL param(s) with working example and description • VOSI-availability and VOSI-capabilities endpoints are now optional | ||||||||
Added: | ||||||||
> > | Revised list of changes (January the 4th/5th/6th 2023) and implementation review | |||||||
Deleted: | ||||||||
< < | Revised list of changes (January the 4th/5th/6th 2023) and implementation review | |||||||
* List of changes of version 1.1 with respect to version 1.0 (2015) and corresponding DataLink issues on github repository.
see : https://github.com/ivoa-std/DataLink for details
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
| ||||||||
Changed: | ||||||||
< < | * discussed, but not integrated in 1.1 yet : | |||||||
> > | * discussed, but not integrated in 1.1 yet : | |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | ||||||||
* Implementation : server side. | ||||||||
Changed: | ||||||||
< < | GAVO implemented the following changes = content_qualifier and local_semantics, service descriptor additional features such as DESCRIPTION? name, content_type, etc.... | |||||||
> > | GAVO implemented the following changes = content_qualifier and local_semantics, service descriptor additional features such as DESCRIPTION? name, content_type, etc.... | |||||||
As a matter of example, a couple of links response for various obscore/sia/ssa tables in GAVO server rosat.images : http://dc.zah.uni-heidelberg.de/rosat/q/dl/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3frosat%2fimage_data%2frda_4%2fwg400138p_n1_p1_r2_f2_p1%2frp400138n00_im3.fits.gz where some links have content_qualifier = #image, others have content_qualifier = #event or #timeseries lamost6.lrs : http://dc.zah.uni-heidelberg.de/lamost6/q/sdl_lrs/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3flamost6%2flrs%2f373006237 where some links have content_qualifier = #spectrum califadr3.cubes : http://dc.zah.uni-heidelberg.de/califa/q3/dl/dlget?ID=ivo%3A//org.gavo.dc/~%3Fcalifa/datadr3/COMB/ARP220.COMB.rscube.fits where some links have content_qualifier = #cube ppakm31.maps : http://dc.zah.uni-heidelberg.de/ppakm31/q/cdl/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3fppakm31%2fdata%2fPPAK_M31_F5_cube.fits wher some links have local_semantics filled up and content_qualifier equals #image or #cube All these are combined with various semantics or content_type values * implementation : client side TopCAT prototype (http://andromeda.star.bristol.ac.uk/releases/topcat/pre/topcat-full_datalink11.jar) displays additional features in service descriptor and makes use of additional links table FIELD such as content_qualifier, authorization and local_semantics; The tool behavior is adapted to the content of these new FIELDS. For example Actions suggested by TopCat for the links not only depend on content_type but also from content_qualifier. | ||||||||
Changed: | ||||||||
< < | AladinDesktop is going to adapt to those new features too. | |||||||
> > | AladinDesktop is going to adapt to those new features too. | |||||||
-- FrancoisBonnarel - 2023-01-06 | ||||||||
Added: | ||||||||
> > | DataLink11RFC | |||||||
<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCAT (-- MarkTaylor - 2018-06-13 )These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features. Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf An attempt for a new draft is now available here These are the changes which have been discussed (the items numbers are those used in the College Park presentation): 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. The discussion on this has been moved to two github/ivoa-std/DataLink issues : https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore-ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/31 4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/17 5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1) The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/15 6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/16 7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision. The discussion occured actually in the following threads http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html 8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/20 9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/21 10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/22 11 ) - It COULD be useful to provide a human readable description of a service descriptor. This wil be done by using aLinks and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16New issues after virtual interop (gathered by -- FrancoisBonnarel - 2020-05-13)
Changes DataLink-1.1 (around May 2022)• added optional content_qualifier to describe link target content with terms from the product-type vocabulary • added optional link_auth and link_authorized to signal whether au- thentication is necessary to use the link • clarified use of multiple ID values and possible OVERFLOW • clarified use of utype for self-describing service descriptors • clarified use of semantics • generalize by adding use cases for links to content other than data files • added using LINK to convey when datalink request URL is in a table column • service descriptors can include a contentType param to describe service output and should include a name and description • service descriptors can include exampleURL param(s) with working example and description • VOSI-availability and VOSI-capabilities endpoints are now optionalRevised list of changes (January the 4th/5th/6th 2023) and implementation review* List of changes of version 1.1 with respect to version 1.0 (2015) and corresponding DataLink issues on github repository. see : https://github.com/ivoa-std/DataLink for details
| ||||||||
Added: | ||||||||
> > |
| |||||||
* Implementation : server side.
GAVO implemented the following changes = content_qualifier and local_semantics, service descriptor additional features such as DESCRIPTION? name, content_type, etc....
As a matter of example, a couple of links response for various obscore/sia/ssa tables in GAVO server
rosat.images : http://dc.zah.uni-heidelberg.de/rosat/q/dl/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3frosat%2fimage_data%2frda_4%2fwg400138p_n1_p1_r2_f2_p1%2frp400138n00_im3.fits.gz where some links have content_qualifier = #image, others have content_qualifier = #event or #timeseries
lamost6.lrs : http://dc.zah.uni-heidelberg.de/lamost6/q/sdl_lrs/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3flamost6%2flrs%2f373006237 where some links have content_qualifier = #spectrum
califadr3.cubes : http://dc.zah.uni-heidelberg.de/califa/q3/dl/dlget?ID=ivo%3A//org.gavo.dc/~%3Fcalifa/datadr3/COMB/ARP220.COMB.rscube.fits where some links have content_qualifier = #cube
ppakm31.maps : http://dc.zah.uni-heidelberg.de/ppakm31/q/cdl/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3fppakm31%2fdata%2fPPAK_M31_F5_cube.fits wher some links have local_semantics filled up and content_qualifier equals #image or #cube
All these are combined with various semantics or content_type values
* implementation : client side
TopCAT prototype (http://andromeda.star.bristol.ac.uk/releases/topcat/pre/topcat-full_datalink11.jar) displays additional features in service descriptor and makes use of additional links table FIELD such as content_qualifier, authorization and local_semantics; The tool behavior is adapted to the content of these new FIELDS. For example Actions suggested by TopCat for the links not only depend on content_type but also from content_qualifier.
AladinDesktop is going to adapt to those new features too.
-- FrancoisBonnarel - 2023-01-06
<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCAT (-- MarkTaylor - 2018-06-13 )These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features. Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf An attempt for a new draft is now available here These are the changes which have been discussed (the items numbers are those used in the College Park presentation): 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. The discussion on this has been moved to two github/ivoa-std/DataLink issues : https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore-ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/31 4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/17 5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1) The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/15 6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/16 7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision. The discussion occured actually in the following threads http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html 8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/20 9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/21 10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/22 11 ) - It COULD be useful to provide a human readable description of a service descriptor. This wil be done by using aLinks and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16 | ||||||||
Changed: | ||||||||
< < | New issues after virtual interop (gavered by -- FrancoisBonnarel - 2020-05-13) | |||||||
> > | New issues after virtual interop (gathered by -- FrancoisBonnarel - 2020-05-13) | |||||||
Changes DataLink-1.1 (around May 2022)• added optional content_qualifier to describe link target content with terms from the product-type vocabulary • added optional link_auth and link_authorized to signal whether au- thentication is necessary to use the link • clarified use of multiple ID values and possible OVERFLOW • clarified use of utype for self-describing service descriptors • clarified use of semantics • generalize by adding use cases for links to content other than data files • added using LINK to convey when datalink request URL is in a table column • service descriptors can include a contentType param to describe service output and should include a name and description • service descriptors can include exampleURL param(s) with working example and description • VOSI-availability and VOSI-capabilities endpoints are now optional | ||||||||
Changed: | ||||||||
< < | Revised list of changes (January the 4th/5th 2023) and implementation review | |||||||
> > | Revised list of changes (January the 4th/5th/6th 2023) and implementation review | |||||||
Changed: | ||||||||
< < | * List of changes of version 1.1 with respect to version 1.0 (2015) and corresponding DataLink issues on github repository. | |||||||
> > | * List of changes of version 1.1 with respect to version 1.0 (2015) and corresponding DataLink issues on github repository. | |||||||
Added: | ||||||||
> > | see : https://github.com/ivoa-std/DataLink for details | |||||||
| ||||||||
Deleted: | ||||||||
< < | * Implementation : server side. | |||||||
Changed: | ||||||||
< < | GAVO implemented the following changes = content_qualifier and local_semantics, service descriptor additional features such as DESCRIPTION? name, content_type, etc.... | |||||||
> > | * discussed, but not integrated in 1.1 yet : | |||||||
Changed: | ||||||||
< < | * implementation : client side | |||||||
> > | ||||||||
Added: | ||||||||
> > |
| |||||||
Changed: | ||||||||
< < | TopCAT prototype (http://andromeda.star.bristol.ac.uk/releases/topcat/pre/topcat-full_datalink11.jar) displays additional features in service descriptor and makes use of additional links table FIELD such as content_qualifier, authorization and local_semantics; The tool behavior is adapted to the content of these new FIELDS. For example Actions suggested by TopCat for the links not only depnd on content_type but also from content_qualifier. | |||||||
> > | * Implementation : server side. | |||||||
Added: | ||||||||
> > | GAVO implemented the following changes = content_qualifier and local_semantics, service descriptor additional features such as DESCRIPTION? name, content_type, etc.... As a matter of example, a couple of links response for various obscore/sia/ssa tables in GAVO server rosat.images : http://dc.zah.uni-heidelberg.de/rosat/q/dl/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3frosat%2fimage_data%2frda_4%2fwg400138p_n1_p1_r2_f2_p1%2frp400138n00_im3.fits.gz where some links have content_qualifier = #image, others have content_qualifier = #event or #timeseries lamost6.lrs : http://dc.zah.uni-heidelberg.de/lamost6/q/sdl_lrs/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3flamost6%2flrs%2f373006237 where some links have content_qualifier = #spectrum califadr3.cubes : http://dc.zah.uni-heidelberg.de/califa/q3/dl/dlget?ID=ivo%3A//org.gavo.dc/~%3Fcalifa/datadr3/COMB/ARP220.COMB.rscube.fits where some links have content_qualifier = #cube ppakm31.maps : http://dc.zah.uni-heidelberg.de/ppakm31/q/cdl/dlmeta?ID=ivo%3a%2f%2forg.gavo.dc%2f~%3fppakm31%2fdata%2fPPAK_M31_F5_cube.fits wher some links have local_semantics filled up and content_qualifier equals #image or #cube All these are combined with various semantics or content_type values * implementation : client side TopCAT prototype (http://andromeda.star.bristol.ac.uk/releases/topcat/pre/topcat-full_datalink11.jar) displays additional features in service descriptor and makes use of additional links table FIELD such as content_qualifier, authorization and local_semantics; The tool behavior is adapted to the content of these new FIELDS. For example Actions suggested by TopCat for the links not only depend on content_type but also from content_qualifier. | |||||||
AladinDesktop is going to adapt to those new features too. | ||||||||
Added: | ||||||||
> > | -- FrancoisBonnarel - 2023-01-06 | |||||||
<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCAT (-- MarkTaylor - 2018-06-13 )These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features. Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf An attempt for a new draft is now available here These are the changes which have been discussed (the items numbers are those used in the College Park presentation): 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. The discussion on this has been moved to two github/ivoa-std/DataLink issues : https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore-ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/31 4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/17 5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1) The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/15 6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/16 7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision. The discussion occured actually in the following threads http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html 8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/20 9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/21 10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/22 11 ) - It COULD be useful to provide a human readable description of a service descriptor. This wil be done by using aLinks and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16New issues after virtual interop (gavered by -- FrancoisBonnarel - 2020-05-13)
Changes DataLink-1.1 (around May 2022)• added optional content_qualifier to describe link target content with terms from the product-type vocabulary • added optional link_auth and link_authorized to signal whether au- thentication is necessary to use the link • clarified use of multiple ID values and possible OVERFLOW • clarified use of utype for self-describing service descriptors • clarified use of semantics • generalize by adding use cases for links to content other than data files • added using LINK to convey when datalink request URL is in a table column • service descriptors can include a contentType param to describe service output and should include a name and description • service descriptors can include exampleURL param(s) with working example and description • VOSI-availability and VOSI-capabilities endpoints are now optionalRevised list of changes (January the 4th/5th 2023) and implementation review* List of changes of version 1.1 with respect to version 1.0 (2015) and corresponding DataLink issues on github repository.
| ||||||||
Changed: | ||||||||
< < | TopCAT displays additional features in service descriptor and makes use of additional links table FIELD such as content_qualifier, authorization and local_semantics; The tool behavior is adapted to the content of these new FIELDS | |||||||
> > | TopCAT prototype (http://andromeda.star.bristol.ac.uk/releases/topcat/pre/topcat-full_datalink11.jar) displays additional features in service descriptor and makes use of additional links table FIELD such as content_qualifier, authorization and local_semantics; The tool behavior is adapted to the content of these new FIELDS. For example Actions suggested by TopCat for the links not only depnd on content_type but also from content_qualifier. | |||||||
AladinDesktop is going to adapt to those new features too.
<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCAT (-- MarkTaylor - 2018-06-13 )These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features. Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf An attempt for a new draft is now available here These are the changes which have been discussed (the items numbers are those used in the College Park presentation): 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. The discussion on this has been moved to two github/ivoa-std/DataLink issues : https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore-ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/31 4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/17 5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1) The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/15 6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/16 7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision. The discussion occured actually in the following threads http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html 8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/20 9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/21 10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/22 11 ) - It COULD be useful to provide a human readable description of a service descriptor. This wil be done by using aLinks and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16New issues after virtual interop (gavered by -- FrancoisBonnarel - 2020-05-13)
Changes DataLink-1.1 (around May 2022)• added optional content_qualifier to describe link target content with terms from the product-type vocabulary • added optional link_auth and link_authorized to signal whether au- thentication is necessary to use the link • clarified use of multiple ID values and possible OVERFLOW • clarified use of utype for self-describing service descriptors • clarified use of semantics • generalize by adding use cases for links to content other than data files • added using LINK to convey when datalink request URL is in a table column • service descriptors can include a contentType param to describe service output and should include a name and description • service descriptors can include exampleURL param(s) with working example and description • VOSI-availability and VOSI-capabilities endpoints are now optional | ||||||||
Changed: | ||||||||
< < | Revised list of changes (January the 4th 2023) and implementation review | |||||||
> > | Revised list of changes (January the 4th/5th 2023) and implementation review | |||||||
Added: | ||||||||
> > | * List of changes of version 1.1 with respect to version 1.0 (2015) and corresponding DataLink issues on github repository.
| |||||||
* Implementation : server side. | ||||||||
Changed: | ||||||||
< < | GAVO implemented the following changes = content_qualifier and local_semantics, service descriptor additional | |||||||
> > | GAVO implemented the following changes = content_qualifier and local_semantics, service descriptor additional features such as DESCRIPTION? name, content_type, etc.... | |||||||
* implementation : client side | ||||||||
Added: | ||||||||
> > | TopCAT displays additional features in service descriptor and makes use of additional links table FIELD such as content_qualifier, authorization and local_semantics; The tool behavior is adapted to the content of these new FIELDS AladinDesktop is going to adapt to those new features too. | |||||||
<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCAT (-- MarkTaylor - 2018-06-13 )These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features. Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf An attempt for a new draft is now available here These are the changes which have been discussed (the items numbers are those used in the College Park presentation): 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. The discussion on this has been moved to two github/ivoa-std/DataLink issues : https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore-ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/31 4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/17 5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1) The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/15 6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/16 7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision. The discussion occured actually in the following threads http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html 8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/20 9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/21 10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/22 11 ) - It COULD be useful to provide a human readable description of a service descriptor. This wil be done by using aLinks and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16New issues after virtual interop (gavered by -- FrancoisBonnarel - 2020-05-13)
| ||||||||
Changed: | ||||||||
< < | Changes DataLink-1.1 | |||||||
> > | Changes DataLink-1.1 (around May 2022) | |||||||
• added optional content_qualifier to describe link target content with terms from the product-type vocabulary • added optional link_auth and link_authorized to signal whether au- thentication is necessary to use the link • clarified use of multiple ID values and possible OVERFLOW • clarified use of utype for self-describing service descriptors • clarified use of semantics • generalize by adding use cases for links to content other than data files • added using LINK to convey when datalink request URL is in a table column • service descriptors can include a contentType param to describe service output and should include a name and description • service descriptors can include exampleURL param(s) with working example and description • VOSI-availability and VOSI-capabilities endpoints are now optional | ||||||||
Added: | ||||||||
> > |
Revised list of changes (January the 4th 2023) and implementation review* Implementation : server side. GAVO implemented the following changes = content_qualifier and local_semantics, service descriptor additional * implementation : client side | |||||||
<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCAT (-- MarkTaylor - 2018-06-13 )These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features. Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf An attempt for a new draft is now available here These are the changes which have been discussed (the items numbers are those used in the College Park presentation): 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. The discussion on this has been moved to two github/ivoa-std/DataLink issues : https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore-ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/31 4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/17 5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1) The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/15 6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/16 7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision. The discussion occured actually in the following threads http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html 8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/20 9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/21 10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/22 11 ) - It COULD be useful to provide a human readable description of a service descriptor. This wil be done by using aLinks and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16New issues after virtual interop (gavered by -- FrancoisBonnarel - 2020-05-13)
| ||||||||
Added: | ||||||||
> > |
Changes DataLink-1.1• added optional content_qualifier to describe link target content with terms from the product-type vocabulary • added optional link_auth and link_authorized to signal whether au- thentication is necessary to use the link • clarified use of multiple ID values and possible OVERFLOW • clarified use of utype for self-describing service descriptors • clarified use of semantics • generalize by adding use cases for links to content other than data files • added using LINK to convey when datalink request URL is in a table column • service descriptors can include a contentType param to describe service output and should include a name and description • service descriptors can include exampleURL param(s) with working example and description • VOSI-availability and VOSI-capabilities endpoints are now optional | |||||||
<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
| ||||||||
Changed: | ||||||||
< < | Implementation feedback from TOPCAT (-- FrancoisBonnarel - 2020-05-13) | |||||||
> > | Implementation feedback from TOPCAT (-- MarkTaylor - 2018-06-13 ) | |||||||
These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features. Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf An attempt for a new draft is now available here These are the changes which have been discussed (the items numbers are those used in the College Park presentation): 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. The discussion on this has been moved to two github/ivoa-std/DataLink issues : https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore-ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/31 4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/17 5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1) The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/15 6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/16 7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision. The discussion occured actually in the following threads http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html 8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/20 9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/21 10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/22 11 ) - It COULD be useful to provide a human readable description of a service descriptor. This wil be done by using aLinks and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16 | ||||||||
Changed: | ||||||||
< < | New issues after virtual interop | |||||||
> > | New issues after virtual interop (gavered by -- FrancoisBonnarel - 2020-05-13) | |||||||
<--
| ||||||||
Added: | ||||||||
> > |
| |||||||
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
| ||||||||
Changed: | ||||||||
< < | Implementation feedback from TOPCAT | |||||||
> > | Implementation feedback from TOPCAT (-- FrancoisBonnarel - 2020-05-13) | |||||||
These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
| ||||||||
Added: | ||||||||
> > | ||||||||
They have to be treated differently in the different cases (neither is a special case of the other), since in the standalone case the service descriptor applies equally to all rows, while in the {links}-response case it only applies to those rows from which it is explicitly referenced. This makes it somewhat complicated to handle them since you need to determine the context first, but there's probably nothing that can be done about that while maintaining backward compatibility. However, it would be useful to spell out this distinction in the document; it took me quite a while to work it out. See mailing list.
Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features. | ||||||||
Changed: | ||||||||
< < | Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM | |||||||
> > | Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM | |||||||
Changed: | ||||||||
< < | Around 15 IVOA partners discussed DataLink evolution proposals | |||||||
> > | Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel | |||||||
Deleted: | ||||||||
< < | Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel | |||||||
Changed: | ||||||||
< < | Sorry for people we forgot. Please add your name above. | |||||||
> > | Sorry for people we forgot. Please add your name above. | |||||||
The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf | ||||||||
Changed: | ||||||||
< < | An attempt for a new draft is now available here | |||||||
> > | An attempt for a new draft is now available here | |||||||
Deleted: | ||||||||
< < | ||||||||
These are the changes which have been discussed (the items numbers are those used in the College Park presentation): | ||||||||
Added: | ||||||||
> > | 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. | |||||||
Changed: | ||||||||
< < | 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. | |||||||
> > | This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. | |||||||
Changed: | ||||||||
< < | This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. | |||||||
> > | The discussion on this has been moved to two github/ivoa-std/DataLink issues : https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 | |||||||
Changed: | ||||||||
< < | The discussion on this has been moved to two github/ivoa-std/DataLink issues : | |||||||
> > | 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore-ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. | |||||||
Deleted: | ||||||||
< < | https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 | |||||||
Deleted: | ||||||||
< < | 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore-ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. | |||||||
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/31 | ||||||||
Changed: | ||||||||
< < | 4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag. | |||||||
> > | 4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag. | |||||||
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/17 | ||||||||
Added: | ||||||||
> > | 5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1) | |||||||
Deleted: | ||||||||
< < | 5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1) | |||||||
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/15 | ||||||||
Changed: | ||||||||
< < | 6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table. | |||||||
> > | 6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table. | |||||||
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/16 | ||||||||
Added: | ||||||||
> > | 7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision. | |||||||
Deleted: | ||||||||
< < | 7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision. | |||||||
The discussion occured actually in the following threads http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html | ||||||||
Deleted: | ||||||||
< < | ||||||||
8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/20 | ||||||||
Added: | ||||||||
> > | 9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement. | |||||||
Deleted: | ||||||||
< < | 9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement. | |||||||
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/21 | ||||||||
Changed: | ||||||||
< < | 10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion. | |||||||
> > | 10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion. | |||||||
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/22
11 ) - It COULD be useful to provide a human readable description of a service descriptor. This wil be done by using a | ||||||||
Changed: | ||||||||
< < | 12 ) - A self describing service provides a service descriptor when queried with no input parameter. If queried with the only single identifier PARAMETER the provided service descriptor restrict parameter ranges (MIN/MAX) or OPTIONS to values adapted to the queried dataset or item. | |||||||
> > | 12 ) - A self describing service provides a service descriptor when queried with no input parameter. If queried with the only single identifier PARAMETER the provided service descriptor restrict parameter ranges (MIN/MAX) or OPTIONS to values adapted to the queried dataset or item. | |||||||
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/25 | ||||||||
Changed: | ||||||||
< < | 13 ) - ReST Interface descriptors. Could be useful for VOSPACE or any URL with variable sections/ It may be better to refer the existing Recommendation (https://tools.ietf.org/html/rfc6570 ) discussing this than to reinvent a ReST descriptor on our own. Actual implementation may be postponed to when use cases/prototypes are made available. | |||||||
> > | 13 ) - ReST Interface descriptors. Could be useful for VOSPACE or any URL with variable sections/ It may be better to refer the existing Recommendation (https://tools.ietf.org/html/rfc6570 ) discussing this than to reinvent a ReST descriptor on our own. Actual implementation may be postponed to when use cases/prototypes are made available. | |||||||
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/27 14 ) - DataLink recognition outside a response from a protocol. Some discussion on the new proposed solution from the Note (new content-type=" in the LINK element), especially when the identification of this link column (sort-of) replicates the content that can be provided by a proper service descriptor. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/29 | ||||||||
Changed: | ||||||||
< < | Extra#0 : Should we suppress the availabilty endpoint in Section 2 (which according to Markus nether works)? Should we focus on {links} capabilities attached to other services only (and not as standalone DataLink services). This point is still controversy. | |||||||
> > | Extra#0 : Should we suppress the availabilty endpoint in Section 2 (which according to Markus nether works)? Should we focus on {links} capabilities attached to other services only (and not as standalone DataLink services). This point is still controversy. | |||||||
The discussion on this has been moved to the two github/ivoa-std/DataLink issues: https://github.com/ivoa-std/DataLink/issues/13 and https://github.com/ivoa-std/DataLink/issues/14 | ||||||||
Added: | ||||||||
> > | Extra#1 : from A. Micol. Addition of a "category" column to identify diffrent offered datasets. Isn't that tackled by new semantics terms ? Reluctance to add too much columns belonging to other protocols (Obscore data_product_type). Alberto should add his proposal to the -Next page. Discussion to follow. | |||||||
Changed: | ||||||||
< < | Extra#1 : from A. Micol. Addition of a "category" column to identify diffrent offered datasets. Isn't that tackled by new semantics terms ? Reluctance to add too much columns belonging to other protocols (Obscore data_product_type). Alberto should add his proposal to the -Next page. Discussion to follow. | |||||||
> > | The discussion actually occured in the following threads | |||||||
Deleted: | ||||||||
< < | The discussion actually occured in the following threads | |||||||
http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html | ||||||||
Added: | ||||||||
> > | Extra#2 : use case for an additional boolean column to quickly identify link elements that require authorization (see below, PatrickDowler) . | |||||||
Deleted: | ||||||||
< < | Extra#2 : use case for an additional boolean column to quickly identify link elements that require authorization (see below, PatrickDowler) . | |||||||
The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/33
-- FrancoisBonnarel - 2019-07-20
Links and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16 | ||||||||
Added: | ||||||||
> > |
New issues after virtual interop
| |||||||
<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCATThese points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features. Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf An attempt for a new draft is now available here These are the changes which have been discussed (the items numbers are those used in the College Park presentation): 1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way. This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases. | ||||||||
Changed: | ||||||||
< < | 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.refrence couple of FIELDS/PARAMs which can be used in bsCore-ike contexts, the only previous propsoed genreic solution to adress this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a refrence for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = "" where the FIEL directly contains the url to the {links} endpoint/. A new section for taht seems too much. This will come in an appendix | |||||||
> > | The discussion on this has been moved to two github/ivoa-std/DataLink issues : | |||||||
Added: | ||||||||
> > | https://github.com/ivoa-std/DataLink/issues/6 and https://github.com/ivoa-std/DataLink/issues/7 | |||||||
Added: | ||||||||
> > | 3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.reference couple of FIELDS/PARAMs which can be used in ObsCore-ike contexts, the only previous proposed generic solution to address this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a reference for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = ""application/x-votable+xml;content=datalink" where the FIELD directly contains the url to the {links} endpoint/. A new section for that seems too much. This will come in an appendix. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/31 | |||||||
4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag. | ||||||||
Added: | ||||||||
> > | The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/17 | |||||||
5 ) - Allowing fragments in the access_url seems to be a sensible thing to do considering multi-extension FITS, tar files, HDF5 and other structured data available. Issues to be solved are however related to providing the client enough information to consume this solution. Prototyping on direct use cases could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1) | ||||||||
Added: | ||||||||
> > | The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/15 | |||||||
6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table. | ||||||||
Added: | ||||||||
> > | The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/16 | |||||||
7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision. | ||||||||
Added: | ||||||||
> > | The discussion occured actually in the following threads http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html | |||||||
8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here. | ||||||||
Added: | ||||||||
> > | The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/20 | |||||||
9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement. | ||||||||
Added: | ||||||||
> > | The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/21 | |||||||
10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion. | ||||||||
Changed: | ||||||||
< < | 11 ) - It SOULD be useful to provide a human readable description of a service descriptor. This wil be done by using a | |||||||
> > | The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/22 | |||||||
Added: | ||||||||
> > | 11 ) - It COULD be useful to provide a human readable description of a service descriptor. This wil be done by using a | |||||||
12 ) - A self describing service provides a service descriptor when queried with no input parameter. If queried with the only single identifier PARAMETER the provided service descriptor restrict parameter ranges (MIN/MAX) or OPTIONS to values adapted to the queried dataset or item. | ||||||||
Changed: | ||||||||
< < | 13 ) - ReST Interface descriptors. Could be useful for VOSPACE or any URL with variable sections/ It may be better to refer the existing Recopmmendation (https://tools.ietf.org/html/rfc6570 ) di scussing this than to reinvent a ReST descriptor on our own. Actual implementation may be postponed to when use cases/prototypes are made available. | |||||||
> > | The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/25 | |||||||
Added: | ||||||||
> > | 13 ) - ReST Interface descriptors. Could be useful for VOSPACE or any URL with variable sections/ It may be better to refer the existing Recommendation (https://tools.ietf.org/html/rfc6570 ) discussing this than to reinvent a ReST descriptor on our own. Actual implementation may be postponed to when use cases/prototypes are made available. The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/27 | |||||||
14 ) - DataLink recognition outside a response from a protocol. Some discussion on the new proposed solution from the Note (new content-type=" in the LINK element), especially when the identification of this link column (sort-of) replicates the content that can be provided by a proper service descriptor. | ||||||||
Added: | ||||||||
> > | The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/29 | |||||||
Extra#0 : Should we suppress the availabilty endpoint in Section 2 (which according to Markus nether works)? Should we focus on {links} capabilities attached to other services only (and not as standalone DataLink services). This point is still controversy. | ||||||||
Added: | ||||||||
> > | The discussion on this has been moved to the two github/ivoa-std/DataLink issues: https://github.com/ivoa-std/DataLink/issues/13 and https://github.com/ivoa-std/DataLink/issues/14 | |||||||
Added: | ||||||||
> > | ||||||||
Extra#1 : from A. Micol. Addition of a "category" column to identify diffrent offered datasets. Isn't that tackled by new semantics terms ? Reluctance to add too much columns belonging to other protocols (Obscore data_product_type). Alberto should add his proposal to the -Next page. Discussion to follow. | ||||||||
Added: | ||||||||
> > | The discussion actually occured in the following threads http://mail.ivoa.net/pipermail/dal/2019-October/008191.html http://mail.ivoa.net/pipermail/dal/2019-October/008200.html http://mail.ivoa.net/pipermail/dal/2019-October/008202.html | |||||||
Extra#2 : use case for an additional boolean column to quickly identify link elements that require authorization (see below, PatrickDowler) . | ||||||||
Added: | ||||||||
> > | The discussion on this has been moved to the following github/ivoa-std/DataLink issue: https://github.com/ivoa-std/DataLink/issues/33 | |||||||
-- FrancoisBonnarel - 2019-07-20
Links and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCATThese points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features. Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf | ||||||||
Changed: | ||||||||
< < | An attempt for a new draft is now available here | |||||||
> > | An attempt for a new draft is now available here | |||||||
These are the changes which have been discussed (the items numbers are those used in the College Park presentation):
1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way.
This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases.
3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.refrence couple of FIELDS/PARAMs which can be used in bsCore-ike contexts, the only previous propsoed genreic solution to adress this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a refrence for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = "" where the FIEL directly contains the url to the {links} endpoint/. A new section for taht seems too much. This will come in an appendix
4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag.
5 ) - Allowing fragments in the access_url seems to be a sensible thing to do
considering multi-extension FITS, tar files, HDF5 and other structured data
available. Issues to be solved are however related to providing the client
enough information to consume this solution. Prototyping on direct use cases
could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1)
6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table.
7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms
But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision.
8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here.
9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement.
10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion.
11 ) - It SOULD be useful to provide a human readable description of a service descriptor. This wil be done by using a | ||||||||
Added: | ||||||||
> > | Extra#0 : Should we suppress the availabilty endpoint in Section 2 (which according to Markus nether works)? Should we focus on {links} capabilities attached to other services only (and not as standalone DataLink services). This point is still controversy. | |||||||
Added: | ||||||||
> > | ||||||||
Extra#1 : from A. Micol. Addition of a "category" column to identify diffrent offered datasets. Isn't that tackled by new semantics terms ? Reluctance to add too much columns belonging to other protocols (Obscore data_product_type). Alberto should add his proposal to the -Next page. Discussion to follow.
Extra#2 : use case for an additional boolean column to quickly identify link elements that require authorization (see below, PatrickDowler) .
-- FrancoisBonnarel - 2019-07-20
Links and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16<--
| ||||||||
Added: | ||||||||
> > |
| |||||||
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCATThese points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features. | ||||||||
Added: | ||||||||
> > |
Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM
Around 15 IVOA partners discussed DataLink evolution proposals
Among those people were
Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel
Sorry for people we forgot. Please add your name above.
The starting points were the feedback discussions we had during the last years in the DAL working group.
The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html
A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf
An attempt for a new draft is now available here
These are the changes which have been discussed (the items numbers are those used in the College Park presentation):
1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way.
This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases.
3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.refrence couple of FIELDS/PARAMs which can be used in bsCore-ike contexts, the only previous propsoed genreic solution to adress this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a refrence for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = "" where the FIEL directly contains the url to the {links} endpoint/. A new section for taht seems too much. This will come in an appendix
4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag.
5 ) - Allowing fragments in the access_url seems to be a sensible thing to do
considering multi-extension FITS, tar files, HDF5 and other structured data
available. Issues to be solved are however related to providing the client
enough information to consume this solution. Prototyping on direct use cases
could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1)
6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table.
7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms
But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision.
8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here.
9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement.
10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion.
11 ) - It SOULD be useful to provide a human readable description of a service descriptor. This wil be done by using a | |||||||
Links and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. | ||||||||
Changed: | ||||||||
< < | Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page. | |||||||
> > | Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page. | |||||||
Possible Errata | ||||||||
Changed: | ||||||||
< < | The following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version. | |||||||
> > | The following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version. | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | See mailing list (at the end of that message). | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | See mailing list. | |||||||
Implementation feedback from TOPCAT | ||||||||
Changed: | ||||||||
< < | These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes. | |||||||
> > | These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes. | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | They have to be treated differently in the different cases (neither is a special case of the other), since in the standalone case the service descriptor applies equally to all rows, while in the {links}-response case it only applies to those rows from which it is explicitly referenced. This makes it somewhat complicated to handle them since you need to determine the context first, but there's probably nothing that can be done about that while maintaining backward compatibility. However, it would be useful to spell out this distinction in the document; it took me quite a while to work it out. See mailing list. | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
-- MarkTaylor - 2018-06-13 | ||||||||
Deleted: | ||||||||
< < | ||||||||
Proposed Features | ||||||||
Added: | ||||||||
> > | ||||||||
Suggestion for revision of DataLink-1.0, in terms of new features. | ||||||||
Added: | ||||||||
> > |
Links and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16 | |||||||
<--
|
| ||||||||
Changed: | ||||||||
< < | DataLink-1.0 Next | |||||||
> > | DataLink-1.0 Next | |||||||
Changed: | ||||||||
< < | This topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. | |||||||
> > | This topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. | |||||||
Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page. | ||||||||
Added: | ||||||||
> > |
Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCATThese points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
| |||||||
Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features.<--
|
DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features.<--
|