RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working Group(Review based on the unofficial updated version at http://docs.g-vo.org/RegTAP.pdf) The changes since v1.0 seem reasonable and well-described, and the document overall seems to be in good shape. One comment/suggestion: OAI-PMH is mentioned several times, but I didn’t see a reference to official documentation on that protocol. Should we include such as reference, perhaps being specific about the protocol version if that is important?
Data Access Layer Working GroupAfter a clarification that led to the re-introduction of the ivo_nocasematch in place of the ILIKE and disentangling RegTAP from ADQL in clashing-defining query functions, we support this specification. -- MarcoMolinaro - 2019-08-16Data Model Working GroupFirst comment I have is that the specification is quite complete and detailed. However, reading it completely to have a global view I have had the feeling that the structure of sections 3-7 look more implementation details or appendixes and the real meat of the specification starts in section 8, what could be better to have it before, including the references to the implementation details of the next sections within the text whenever relevant. I imagine that there are historical reasons of this structure that was already present in version 1.0, so, for a possible future 2.0 version, this is just a suggestion of a possible re-arrange of the text so developers can discover easily what needs to be implemented (introduction->use cases description->tables->data content rules->use cases implementation solution->Implementation notes and appendixes) * In specs, it's always hard to decide whether to introduce the basic concepts first and present the interesting stuff later (which minimises forward references but has the negative effect you describe) or delay the definitions of the terms you're using in the central part until later (which keeps the boring stuff out of the way but uses lots of odd words undefined if people read sequentially). Either way: If we change it, it's material for the next iteration at the earliest. -- MarkusDemleitner - 2019-09-09 Focusing on the 1.1 changes from version 1.0, I do not see any impact data model that could block this update. I only have four comments (no changes requests) on four points that looks to me a little bit open. Section 4: In the text, it looks that there is a need to update the translations of the IVOA vocabularies at the services by the services operators with vocabularies outside the spec. The fact that there is not definition of how to treat deprecated terms or which vocabulary version is implemented could be an issue. I understand this is a more global problem that RegTAP but I wonder is something can be done to Is there minimise the impact within RegTAP, for example with a vocabulary version metadata at service level.
Grid & Web Services Working GroupSome minor comments
Registry Working GroupWith the removal of proposed ADQL 2.1 ILIKE dependency in favor of a note about the existence of the future function, I approve of the current version of the document (rev 5576) -- TheresaDower - 2019-09-10Semantics Working GroupRemarks from Carlo Maria Zwölf
Summary response* As to typos and style proposals not mentioned below: Should all be fixed in Volute rev. 5574 – thanks for the careful reading.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working Group(Review based on the unofficial updated version at http://docs.g-vo.org/RegTAP.pdf) The changes since v1.0 seem reasonable and well-described, and the document overall seems to be in good shape. One comment/suggestion: OAI-PMH is mentioned several times, but I didn’t see a reference to official documentation on that protocol. Should we include such as reference, perhaps being specific about the protocol version if that is important?
Data Access Layer Working GroupAfter a clarification that led to the re-introduction of the ivo_nocasematch in place of the ILIKE and disentangling RegTAP from ADQL in clashing-defining query functions, we support this specification. -- MarcoMolinaro - 2019-08-16Data Model Working GroupFirst comment I have is that the specification is quite complete and detailed. However, reading it completely to have a global view I have had the feeling that the structure of sections 3-7 look more implementation details or appendixes and the real meat of the specification starts in section 8, what could be better to have it before, including the references to the implementation details of the next sections within the text whenever relevant. I imagine that there are historical reasons of this structure that was already present in version 1.0, so, for a possible future 2.0 version, this is just a suggestion of a possible re-arrange of the text so developers can discover easily what needs to be implemented (introduction->use cases description->tables->data content rules->use cases implementation solution->Implementation notes and appendixes) * In specs, it's always hard to decide whether to introduce the basic concepts first and present the interesting stuff later (which minimises forward references but has the negative effect you describe) or delay the definitions of the terms you're using in the central part until later (which keeps the boring stuff out of the way but uses lots of odd words undefined if people read sequentially). Either way: If we change it, it's material for the next iteration at the earliest. -- MarkusDemleitner - 2019-09-09 Focusing on the 1.1 changes from version 1.0, I do not see any impact data model that could block this update. I only have four comments (no changes requests) on four points that looks to me a little bit open. Section 4: In the text, it looks that there is a need to update the translations of the IVOA vocabularies at the services by the services operators with vocabularies outside the spec. The fact that there is not definition of how to treat deprecated terms or which vocabulary version is implemented could be an issue. I understand this is a more global problem that RegTAP but I wonder is something can be done to Is there minimise the impact within RegTAP, for example with a vocabulary version metadata at service level.
Grid & Web Services Working GroupSome minor comments
Registry Working GroupWith the removal of proposed ADQL 2.1 ILIKE dependency in favor of a note about the existence of the future function, I approve of the current version of the document (rev 5576) -- TheresaDower - 2019-09-10Semantics Working GroupRemarks from Carlo Maria Zwölf
Summary response* As to typos and style proposals not mentioned below: Should all be fixed in Volute rev. 5574 – thanks for the careful reading.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working Group(Review based on the unofficial updated version at http://docs.g-vo.org/RegTAP.pdf) The changes since v1.0 seem reasonable and well-described, and the document overall seems to be in good shape. One comment/suggestion: OAI-PMH is mentioned several times, but I didn’t see a reference to official documentation on that protocol. Should we include such as reference, perhaps being specific about the protocol version if that is important?
Data Access Layer Working GroupAfter a clarification that led to the re-introduction of the ivo_nocasematch in place of the ILIKE and disentangling RegTAP from ADQL in clashing-defining query functions, we support this specification. -- MarcoMolinaro - 2019-08-16Data Model Working GroupFirst comment I have is that the specification is quite complete and detailed. However, reading it completely to have a global view I have had the feeling that the structure of sections 3-7 look more implementation details or appendixes and the real meat of the specification starts in section 8, what could be better to have it before, including the references to the implementation details of the next sections within the text whenever relevant. I imagine that there are historical reasons of this structure that was already present in version 1.0, so, for a possible future 2.0 version, this is just a suggestion of a possible re-arrange of the text so developers can discover easily what needs to be implemented (introduction->use cases description->tables->data content rules->use cases implementation solution->Implementation notes and appendixes) * In specs, it's always hard to decide whether to introduce the basic concepts first and present the interesting stuff later (which minimises forward references but has the negative effect you describe) or delay the definitions of the terms you're using in the central part until later (which keeps the boring stuff out of the way but uses lots of odd words undefined if people read sequentially). Either way: If we change it, it's material for the next iteration at the earliest. -- MarkusDemleitner - 2019-09-09 Focusing on the 1.1 changes from version 1.0, I do not see any impact data model that could block this update. I only have four comments (no changes requests) on four points that looks to me a little bit open. Section 4: In the text, it looks that there is a need to update the translations of the IVOA vocabularies at the services by the services operators with vocabularies outside the spec. The fact that there is not definition of how to treat deprecated terms or which vocabulary version is implemented could be an issue. I understand this is a more global problem that RegTAP but I wonder is something can be done to Is there minimise the impact within RegTAP, for example with a vocabulary version metadata at service level.
Grid & Web Services Working GroupSome minor comments
Registry Working GroupWith the removal of proposed ADQL 2.1 ILIKE dependency in favor of a note about the existence of the future function, I approve of the current version of the document (rev 5576) -- TheresaDower - 2019-09-10Semantics Working GroupRemarks from Carlo Maria Zwölf
Summary response* As to typos and style proposals not mentioned below: Should all be fixed in Volute rev. 5574 – thanks for the careful reading.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working Group(Review based on the unofficial updated version at http://docs.g-vo.org/RegTAP.pdf) The changes since v1.0 seem reasonable and well-described, and the document overall seems to be in good shape. One comment/suggestion: OAI-PMH is mentioned several times, but I didn’t see a reference to official documentation on that protocol. Should we include such as reference, perhaps being specific about the protocol version if that is important?
Data Access Layer Working GroupAfter a clarification that led to the re-introduction of the ivo_nocasematch in place of the ILIKE and disentangling RegTAP from ADQL in clashing-defining query functions, we support this specification. -- MarcoMolinaro - 2019-08-16Data Model Working GroupFirst comment I have is that the specification is quite complete and detailed. However, reading it completely to have a global view I have had the feeling that the structure of sections 3-7 look more implementation details or appendixes and the real meat of the specification starts in section 8, what could be better to have it before, including the references to the implementation details of the next sections within the text whenever relevant. I imagine that there are historical reasons of this structure that was already present in version 1.0, so, for a possible future 2.0 version, this is just a suggestion of a possible re-arrange of the text so developers can discover easily what needs to be implemented (introduction->use cases description->tables->data content rules->use cases implementation solution->Implementation notes and appendixes) * In specs, it's always hard to decide whether to introduce the basic concepts first and present the interesting stuff later (which minimises forward references but has the negative effect you describe) or delay the definitions of the terms you're using in the central part until later (which keeps the boring stuff out of the way but uses lots of odd words undefined if people read sequentially). Either way: If we change it, it's material for the next iteration at the earliest. -- MarkusDemleitner - 2019-09-09 Focusing on the 1.1 changes from version 1.0, I do not see any impact data model that could block this update. I only have four comments (no changes requests) on four points that looks to me a little bit open. Section 4: In the text, it looks that there is a need to update the translations of the IVOA vocabularies at the services by the services operators with vocabularies outside the spec. The fact that there is not definition of how to treat deprecated terms or which vocabulary version is implemented could be an issue. I understand this is a more global problem that RegTAP but I wonder is something can be done to Is there minimise the impact within RegTAP, for example with a vocabulary version metadata at service level.
| ||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||
In summary, the specification is mature and implementable so data model WG approve it
-- JesusSalgado - 2019-09-05
Grid & Web Services Working GroupSome minor comments
Registry Working GroupWith the removal of proposed ADQL 2.1 ILIKE dependency in favor of a note about the existence of the future function, I approve of the current version of the document (rev 5576) -- TheresaDower - 2019-09-10Semantics Working GroupRemarks from Carlo Maria Zwölf
Summary response* As to typos and style proposals not mentioned below: Should all be fixed in Volute rev. 5574 – thanks for the careful reading.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working Group(Review based on the unofficial updated version at http://docs.g-vo.org/RegTAP.pdf) The changes since v1.0 seem reasonable and well-described, and the document overall seems to be in good shape. One comment/suggestion: OAI-PMH is mentioned several times, but I didn’t see a reference to official documentation on that protocol. Should we include such as reference, perhaps being specific about the protocol version if that is important?
Data Access Layer Working GroupAfter a clarification that led to the re-introduction of the ivo_nocasematch in place of the ILIKE and disentangling RegTAP from ADQL in clashing-defining query functions, we support this specification. -- MarcoMolinaro - 2019-08-16Data Model Working GroupFirst comment I have is that the specification is quite complete and detailed. However, reading it completely to have a global view I have had the feeling that the structure of sections 3-7 look more implementation details or appendixes and the real meat of the specification starts in section 8, what could be better to have it before, including the references to the implementation details of the next sections within the text whenever relevant. I imagine that there are historical reasons of this structure that was already present in version 1.0, so, for a possible future 2.0 version, this is just a suggestion of a possible re-arrange of the text so developers can discover easily what needs to be implemented (introduction->use cases description->tables->data content rules->use cases implementation solution->Implementation notes and appendixes) * In specs, it's always hard to decide whether to introduce the basic concepts first and present the interesting stuff later (which minimises forward references but has the negative effect you describe) or delay the definitions of the terms you're using in the central part until later (which keeps the boring stuff out of the way but uses lots of odd words undefined if people read sequentially). Either way: If we change it, it's material for the next iteration at the earliest. -- MarkusDemleitner - 2019-09-09 Focusing on the 1.1 changes from version 1.0, I do not see any impact data model that could block this update. I only have four comments (no changes requests) on four points that looks to me a little bit open. Section 4: In the text, it looks that there is a need to update the translations of the IVOA vocabularies at the services by the services operators with vocabularies outside the spec. The fact that there is not definition of how to treat deprecated terms or which vocabulary version is implemented could be an issue. I understand this is a more global problem that RegTAP but I wonder is something can be done to Is there minimise the impact within RegTAP, for example with a vocabulary version metadata at service level.
Grid & Web Services Working GroupSome minor comments
Registry Working GroupWith the removal of proposed ADQL 2.1 ILIKE dependency in favor of a note about the existence of the future function, I approve of the current version of the document (rev 5576) -- TheresaDower - 2019-09-10Semantics Working GroupRemarks from Carlo Maria Zwölf
Summary response* As to typos and style proposals not mentioned below: Should all be fixed in Volute rev. 5574 – thanks for the careful reading.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working Group(Review based on the unofficial updated version at http://docs.g-vo.org/RegTAP.pdf) The changes since v1.0 seem reasonable and well-described, and the document overall seems to be in good shape. One comment/suggestion: OAI-PMH is mentioned several times, but I didn’t see a reference to official documentation on that protocol. Should we include such as reference, perhaps being specific about the protocol version if that is important?
Data Access Layer Working GroupAfter a clarification that led to the re-introduction of the ivo_nocasematch in place of the ILIKE and disentangling RegTAP from ADQL in clashing-defining query functions, we support this specification. -- MarcoMolinaro - 2019-08-16Data Model Working Group | |||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||
< < | First comment I have is that the specification is quite complete and detailed. | ||||||||||||||||||||||||||||||||||||||||
> > | First comment I have is that the specification is quite complete and detailed. However, reading it completely to have a global view I have had the feeling that the structure of sections 3-7 look more implementation details or appendixes and the real meat of the specification starts in section 8, what could be better to have it before, including the references to the implementation details of the next sections within the text whenever relevant. | ||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||
< < | However, reading it completely to have a global view I have had the feeling that the structure of sections 3-7 look more implementation details or appendixes and the real meat of the specification starts in section 8, what could be better to have it before, including the references to the implementation details of the next sections within the text whenever relevant. | ||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||
< < | I imagine that there are historical reasons of this structure that was already present in version 1.0, so, for a possible future 2.0 version, this is just a suggestion of a possible re-arrange of the text so developers can discover easily what needs to be implemented (introduction->use cases description->tables->data content rules->use cases implementation solution->Implementation notes and appendixes) | ||||||||||||||||||||||||||||||||||||||||
> > | I imagine that there are historical reasons of this structure that was already present in version 1.0, so, for a possible future 2.0 version, this is just a suggestion of a possible re-arrange of the text so developers can discover easily what needs to be implemented (introduction->use cases description->tables->data content rules->use cases implementation solution->Implementation notes and appendixes) | ||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||
< < | * In specs, it's always hard to decide whether to introduce the basic concepts first and present the interesting stuff later (which minimises forward references but has the negative effect you describe) or delay the definitions of the terms you're using in the central part until later (which keeps the boring stuff out of the way but uses lots of odd words undefined if people read sequentially). Either way: If we change it, it's material for the next iteration at the earliest. -- MarkusDemleitner - 2019-09-09 | ||||||||||||||||||||||||||||||||||||||||
> > | * In specs, it's always hard to decide whether to introduce the basic concepts first and present the interesting stuff later (which minimises forward references but has the negative effect you describe) or delay the definitions of the terms you're using in the central part until later (which keeps the boring stuff out of the way but uses lots of odd words undefined if people read sequentially). Either way: If we change it, it's material for the next iteration at the earliest. -- MarkusDemleitner - 2019-09-09 | ||||||||||||||||||||||||||||||||||||||||
Focusing on the 1.1 changes from version 1.0, I do not see any impact data model that could block this update. I only have four comments (no changes requests) on four points that looks to me a little bit open. Section 4: In the text, it looks that there is a need to update the translations of the IVOA vocabularies at the services by the services operators with vocabularies outside the spec. The fact that there is not definition of how to treat deprecated terms or which vocabulary version is implemented could be an issue. I understand this is a more global problem that RegTAP but I wonder is something can be done to Is there minimise the impact within RegTAP, for example with a vocabulary version metadata at service level. | |||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||
> > | Section 8.2: I checked VOResource 1.1 about the role_name format and the only reference that I find is "This should be exactly one name, preferably last name first (as in "van der Waals, Johannes Diderik")." I think this is not too strict enough to be used effectively. This is probably part of VOResource but also part of the service validator when there is a new insertion of a new record. Any suggestion on what has to be changed (and in which spec) to prevent this problem? | ||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||
< < | Section 8.2: I checked VOResource 1.1 about the role_name format and the only reference that I find is "This should be exactly one name, preferably last name first (as in "van der Waals, Johannes Diderik")." I think this is not too strict enough to be used effectively. This is probably part of VOResource but also part of the service validator when there is a new insertion of a new record. Any suggestion on what has to be changed (and in which spec) to prevent this problem? | ||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||
< < |
Section 8.8:
"Clients not prepared to authenticate to services should always include a authenticated_only=0 condition" In the future, instead of a single value (0 or 1), to point to IVOA Single-Sign-On Profile: Authentication SSO mechanisms list in some way would be even more useful (e.g. 0 for non authenticated, 1-7 for the security methods described in the SSO spec and, maybe, 8 for other). Perhaps, the security method metadata is not expected to be handled here.
| ||||||||||||||||||||||||||||||||||||||||
Finally, whenever ILIKE is part of ADQL, should we have a new version of RegTAP pointing to this new ADQL version or this ADQL deviation is going to be maintained here? I think it would be cleaner (and better) to point to the new ADQL but this could have some impact depending on the changes of the new ADQL (and implementations) | |||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||
> > | In summary, the specification is mature and implementable so data model WG approve it | ||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||
< < | In summary, the specification is mature and implementable so data model WG approve it | ||||||||||||||||||||||||||||||||||||||||
-- JesusSalgado - 2019-09-05 | |||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||
Grid & Web Services Working GroupSome minor comments
Registry Working Group | |||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||
> > | With the removal of proposed ADQL 2.1 ILIKE dependency in favor of a note about the existence of the future function, I approve of the current version of the document (rev 5576) -- TheresaDower - 2019-09-10 | ||||||||||||||||||||||||||||||||||||||||
Semantics Working GroupRemarks from Carlo Maria Zwölf
Summary response* As to typos and style proposals not mentioned below: Should all be fixed in Volute rev. 5574 – thanks for the careful reading.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working Group(Review based on the unofficial updated version at http://docs.g-vo.org/RegTAP.pdf) The changes since v1.0 seem reasonable and well-described, and the document overall seems to be in good shape. One comment/suggestion: OAI-PMH is mentioned several times, but I didn’t see a reference to official documentation on that protocol. Should we include such as reference, perhaps being specific about the protocol version if that is important? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- TomDonaldson - 2019-08-15
Data Access Layer Working GroupAfter a clarification that led to the re-introduction of the ivo_nocasematch in place of the ILIKE and disentangling RegTAP from ADQL in clashing-defining query functions, we support this specification. -- MarcoMolinaro - 2019-08-16Data Model Working GroupFirst comment I have is that the specification is quite complete and detailed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | However, reading it completely to have a global view I have had the feeling that the structure of sections 3-7 look more implementation details or appendixes and the real meat of the specification starts in section 8, what could be better to have it before, including the references to the implementation details of the next sections within the text whenever relevant. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | However, reading it completely to have a global view I have had the feeling that the structure of sections 3-7 look more implementation details or appendixes and the real meat of the specification starts in section 8, what could be better to have it before, including the references to the implementation details of the next sections within the text whenever relevant. I imagine that there are historical reasons of this structure that was already present in version 1.0, so, for a possible future 2.0 version, this is just a suggestion of a possible re-arrange of the text so developers can discover easily what needs to be implemented (introduction->use cases description->tables->data content rules->use cases implementation solution->Implementation notes and appendixes) Focusing on the 1.1 changes from version 1.0, I do not see any impact data model that could block this update. I only have four comments (no changes requests) on four points that looks to me a little bit open. Section 4: In the text, it looks that there is a need to update the translations of the IVOA vocabularies at the services by the services operators with vocabularies outside the spec. The fact that there is not definition of how to treat deprecated terms or which vocabulary version is implemented could be an issue. I understand this is a more global problem that RegTAP but I wonder is something can be done to Is there minimise the impact within RegTAP, for example with a vocabulary version metadata at service level. Section 8.2: I checked VOResource 1.1 about the role_name format and the only reference that I find is "This should be exactly one name, preferably last name first (as in "van der Waals, Johannes Diderik")." I think this is not too strict enough to be used effectively. This is probably part of VOResource but also part of the service validator when there is a new insertion of a new record. Any suggestion on what has to be changed (and in which spec) to prevent this problem? Section 8.8: "Clients not prepared to authenticate to services should always include a authenticated_only=0 condition" In the future, instead of a single value (0 or 1), to point to IVOA Single-Sign-On Profile: Authentication SSO mechanisms list in some way would be even more useful (e.g. 0 for non authenticated, 1-7 for the security methods described in the SSO spec and, maybe, 8 for other). Perhaps, the security method metadata is not expected to be handled here. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | I imagine that there are historical reasons of this structure that was already present in version 1.0, so, for a possible future 2.0 version, this is just a suggestion of a possible re-arrange of the text so developers can discover easily what needs to be implemented (introduction->use cases description->tables->data content rules->use cases implementation solution->Implementation notes and appendixes) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | * In specs, it's always hard to decide whether to introduce the basic concepts first and present the interesting stuff later (which minimises forward references but has the negative effect you describe) or delay the definitions of the terms you're using in the central part until later (which keeps the boring stuff out of the way but uses lots of odd words undefined if people read sequentially). Either way: If we change it, it's material for the next iteration at the earliest. -- MarkusDemleitner - 2019-09-09
Focusing on the 1.1 changes from version 1.0, I do not see any impact data model that could block this update. I only have four comments (no changes requests) on four points that looks to me a little bit open.
Section 4: In the text, it looks that there is a need to update the translations of the IVOA vocabularies at the services by the services operators with vocabularies outside the spec. The fact that there is not definition of how to treat deprecated terms or which vocabulary version is implemented could be an issue. I understand this is a more global problem that RegTAP but I wonder is something can be done to Is there minimise the impact within RegTAP, for example with a vocabulary version metadata at service level.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Finally, whenever ILIKE is part of ADQL, should we have a new version of RegTAP pointing to this new ADQL version or this ADQL deviation is going to be maintained here? I think it would be cleaner (and better) to point to the new ADQL but this could have some impact depending on the changes of the new ADQL (and implementations) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | In summary, the specification is mature and implementable so data model WG approve it -- JesusSalgado - 2019-09-05 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | In summary, the specification is mature and implementable so data model WG approve it -- JesusSalgado - 2019-09-05 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Grid & Web Services Working GroupSome minor comments
Registry Working GroupSemantics Working GroupRemarks from Carlo Maria Zwölf
Summary response* As to typos and style proposals not mentioned below: Should all be fixed in Volute rev. 5574 – thanks for the careful reading.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working Group(Review based on the unofficial updated version at http://docs.g-vo.org/RegTAP.pdf) The changes since v1.0 seem reasonable and well-described, and the document overall seems to be in good shape. | |||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||
< < | One comment/suggestion: | ||||||||||||||||||||||||||||||||||||||||||||||||||
> > | One comment/suggestion: | ||||||||||||||||||||||||||||||||||||||||||||||||||
OAI-PMH is mentioned several times, but I didn’t see a reference to official documentation on that protocol. Should we include such as reference, perhaps being specific about the protocol version if that is important?
-- TomDonaldson - 2019-08-15
Data Access Layer Working GroupAfter a clarification that led to the re-introduction of the ivo_nocasematch in place of the ILIKE and disentangling RegTAP from ADQL in clashing-defining query functions, we support this specification. -- MarcoMolinaro - 2019-08-16Data Model Working Group | |||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||
> > | First comment I have is that the specification is quite complete and detailed.
However, reading it completely to have a global view I have had the feeling that the structure of sections 3-7 look more implementation details or appendixes and the real meat of the specification starts in section 8, what could be better to have it before, including the references to the implementation details of the next sections within the text whenever relevant. I imagine that there are historical reasons of this structure that was already present in version 1.0, so, for a possible future 2.0 version, this is just a suggestion of a possible re-arrange of the text so developers can discover easily what needs to be implemented (introduction->use cases description->tables->data content rules->use cases implementation solution->Implementation notes and appendixes) Focusing on the 1.1 changes from version 1.0, I do not see any impact data model that could block this update. I only have four comments (no changes requests) on four points that looks to me a little bit open. Section 4: In the text, it looks that there is a need to update the translations of the IVOA vocabularies at the services by the services operators with vocabularies outside the spec. The fact that there is not definition of how to treat deprecated terms or which vocabulary version is implemented could be an issue. I understand this is a more global problem that RegTAP but I wonder is something can be done to Is there minimise the impact within RegTAP, for example with a vocabulary version metadata at service level. Section 8.2: I checked VOResource 1.1 about the role_name format and the only reference that I find is "This should be exactly one name, preferably last name first (as in "van der Waals, Johannes Diderik")." I think this is not too strict enough to be used effectively. This is probably part of VOResource but also part of the service validator when there is a new insertion of a new record. Any suggestion on what has to be changed (and in which spec) to prevent this problem? Section 8.8: "Clients not prepared to authenticate to services should always include a authenticated_only=0 condition" In the future, instead of a single value (0 or 1), to point to IVOA Single-Sign-On Profile: Authentication SSO mechanisms list in some way would be even more useful (e.g. 0 for non authenticated, 1-7 for the security methods described in the SSO spec and, maybe, 8 for other). Perhaps, the security method metadata is not expected to be handled here. Finally, whenever ILIKE is part of ADQL, should we have a new version of RegTAP pointing to this new ADQL version or this ADQL deviation is going to be maintained here? I think it would be cleaner (and better) to point to the new ADQL but this could have some impact depending on the changes of the new ADQL (and implementations) In summary, the specification is mature and implementable so data model WG approve it -- JesusSalgado - 2019-09-05 | ||||||||||||||||||||||||||||||||||||||||||||||||||
Grid & Web Services Working GroupSome minor comments
Registry Working GroupSemantics Working GroupRemarks from Carlo Maria Zwölf
Summary response* As to typos and style proposals not mentioned below: Should all be fixed in Volute rev. 5574 – thanks for the careful reading.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working Group(Review based on the unofficial updated version at http://docs.g-vo.org/RegTAP.pdf) The changes since v1.0 seem reasonable and well-described, and the document overall seems to be in good shape. One comment/suggestion: OAI-PMH is mentioned several times, but I didn’t see a reference to official documentation on that protocol. Should we include such as reference, perhaps being specific about the protocol version if that is important? -- TomDonaldson - 2019-08-15Data Access Layer Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | After a clarification that led to the re-introduction of the ivo_nocasematch in place of the ILIKE and disentangling RegTAP from ADQL in clashing-defining query functions, we support this specification. -- MarcoMolinaro - 2019-08-16 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Model Working GroupGrid & Web Services Working GroupSome minor comments
Registry Working GroupSemantics Working GroupRemarks from Carlo Maria Zwölf
Summary response* As to typos and style proposals not mentioned below: Should all be fixed in Volute rev. 5574 – thanks for the careful reading.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The latest version of RegTAP 1.1 can be found at: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A slightly updated, unofficial version including the changes made after RFC comments from Ops, GWS, and Semantics is available from http://docs.g-vo.org/RegTAP.pdf.
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | The TOPCAT client is interoperable with both reference implementations, though it does not use any of the new 1.1 features yet. Likewise, Aladin's registry bundle is being generated from a RegTAP 1.1 query. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | The TOPCAT client is interoperable with both reference implementations, though it does not use any of the new 1.1 features yet. Likewise, Aladin's registry bundle is being generated from a RegTAP 1.1 query. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | (Review based on the unofficial updated version at http://docs.g-vo.org/RegTAP.pdf) The changes since v1.0 seem reasonable and well-described, and the document overall seems to be in good shape. One comment/suggestion: OAI-PMH is mentioned several times, but I didn’t see a reference to official documentation on that protocol. Should we include such as reference, perhaps being specific about the protocol version if that is important? -- TomDonaldson - 2019-08-15 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupSome minor comments
Registry Working GroupSemantics Working GroupRemarks from Carlo Maria Zwölf
Summary response* As to typos and style proposals not mentioned below: Should all be fixed in Volute rev. 5574 – thanks for the careful reading.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Thanks for updates - all looks OK now. I will think about mirror_url implementation. -- MarkTaylor - 2019-08-14 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Thanks for updates - all looks OK now. I will think about mirror_url implementation. -- MarkTaylor - 2019-08-14 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupSome minor comments
Registry Working GroupSemantics Working GroupRemarks from Carlo Maria Zwölf
Summary response* As to typos and style proposals not mentioned below: Should all be fixed in Volute rev. 5574 – thanks for the careful reading.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Thanks for updates - all looks OK now. I will think about mirror_url implementation. -- MarkTaylor - 2019-08-14 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Latest version of RegTAP 1.1 can be found at: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | The latest version of RegTAP 1.1 can be found at: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | A slightly updated, unofficial version including the changes made after RFC comments from Ops, GWS, and Semantics is available from http://docs.g-vo.org/RegTAP.pdf. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | The TOPCAT client is aware of RegTAP 1.1 features and is interoperable with both reference implementations | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | The TOPCAT client is interoperable with both reference implementations, though it does not use any of the new 1.1 features yet. Likewise, Aladin's registry bundle is being generated from a RegTAP 1.1 query. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupSome minor comments
Registry Working GroupSemantics Working GroupRemarks from Carlo Maria Zwölf
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
Summary response* As to typos and style proposals not mentioned below: Should all be fixed in Volute rev. 5574 – thanks for the careful reading.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarkTaylor - 2019-06-13
Mark, I updated the link. Thanks and apologies.
As for the TOPCAT support, I'm unaware of specific 1.1 features and will leave that with other comments for Markus to respond to as author; possibly the intention was noting the schema additions didn't break anything, with altIdentifier queries working and no broken baked-in example queries? Those are the main points that came to my mind when testing my reference implementation with TOPCAT. -- TheresaDower - 2019-07-24
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Some minor comments | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Some minor comments | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- GiulianoTaffoni - 2019-08-12 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Registry Working GroupSemantics Working GroupRemarks from Carlo Maria Zwölf
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working Group | ||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||
> > | Some minor comments
| |||||||||||||||||||||||||||||||||||||||||||||
Registry Working GroupSemantics Working GroupRemarks from Carlo Maria Zwölf
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Remarks from Carlo Maria Zwölf
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Mark, I updated the link. Thanks and apologies. As for the TOPCAT support, I'm unaware of specific 1.1 features and will leave that with other comments for Markus to respond to as author; possibly the intention was noting the schema additions didn't break anything, with altIdentifier queries working and no broken baked-in example queries? Those are the main points that came to my mind when testing my reference implementation with TOPCAT. -- TheresaDower - 2019-07-24 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarkTaylor - 2019-06-13
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Standards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Comments from the IVOA Community during RFC/TCG review period: RFC_start_date - RFC_end_date | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Comments from the IVOA Community during RFC/TCG review period: 2019-06-15 - 2019-07-31 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The comments from the TCG members during the RFC/TCG review should be included in the next section.
In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.
Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The TOPCAT client is aware of RegTAP 1.1 features and is interoperable with both reference implementations
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): alt_identifiers – find VO resources and their titles that have DOIs:select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' Comments from the IVOA Community during RFC/TCG review period: RFC_start_date - RFC_end_dateThe comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The TOPCAT client is aware of RegTAP 1.1 features and is interoperable with both reference implementations
Implementations ValidatorsThe RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above): | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | alt_identifiers – find VO resources and their titles that have DOIs: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | alt_identifiers – find VO resources and their titles that have DOIs: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | select ivoid, res_title, alt_identifier | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | select ivoid, res_title, alt_identifier | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%' | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | rights_uri – find VO resources that have a CC license declared: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | rights_uri – find VO resources that have a CC license declared: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | select ivoid, res_title, rights_uri | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | select ivoid, res_title, rights_uri | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
from rr.resource where rights_uri like 'http://creativecommons.org/%' or find what license URIs are already in use: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | select distinct rights_uri from rr.resource | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | select distinct rights_uri from rr.resource | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | mirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | mirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | select ivoid, mirrors.mirror_url | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | select ivoid, mirrors.mirror_url | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form' | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | select distinct ivoid from rr.interface where authenticated_only=1 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | select distinct ivoid from rr.interface where authenticated_only=1 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | vocabulary mapping – use just a single term to find out services of data collections: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | vocabulary mapping – use just a single term to find out services of data collections: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | select res_title | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | select res_title | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
from rr.resource as res
natural join rr.relationship as rel
where relationship_type='isservedby'
and rel.related_id='ivo://nasa.heasarc/services/xamin'
Comments from the IVOA Community during RFC/TCG review period: RFC_start_date - RFC_end_dateThe comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | The TOPCAT client is aware of RegTAP 1.1 features and is interoperable with both reference implementations | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | The TOPCAT client is aware of RegTAP 1.1 features and is interoperable with both reference implementations | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Implementations Validators | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | (If any, indicate here the links to Implementations Validators) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | The RegTAP validator (currently at http://docs.g-vo.org/regtap-val; should this move into the VCS for the standard?) has been updated to cover the main new features. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
For reviewers, here's a set of RegTAP queries exercising the main user-visible new features (TAP access URLs above):
alt_identifiers – find VO resources and their titles that have DOIs:
select ivoid, res_title, alt_identifier from rr.resource natural join rr.alt_identifier where alt_identifier like 'doi:%'rights_uri – find VO resources that have a CC license declared: select ivoid, res_title, rights_uri from rr.resource where rights_uri like 'http://creativecommons.org/%'or find what license URIs are already in use: select distinct rights_uri from rr.resourcemirror_url – find mirrors available for a known access url (in this case, indicating that the service is available through https, too): select ivoid, mirrors.mirror_url from rr.interface as intfs join rr.interface as mirrors using (ivoid,intf_index, cap_index) where intfs.access_url='http://dc.zah.uni-heidelberg.de/antares/q/cone/form'authenticated_only – find resources unavailable without authentication (note that we do not claim that's enough to actually operate them; the use case at this point is filtering them out with a view to a VO that has more of them): select distinct ivoid from rr.interface where authenticated_only=1vocabulary mapping – use just a single term to find out services of data collections: select res_title from rr.resource as res natural join rr.relationship as rel where relationship_type='isservedby' and rel.related_id='ivo://nasa.heasarc/services/xamin' | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comments from the IVOA Community during RFC/TCG review period: RFC_start_date - RFC_end_dateThe comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|
RegTAP 1.1 Proposed Recommendation: Request for CommentsSummaryRegistries provide a mechanism with which VO applications can discover and select resources - first and foremost data and services - that are relevant for a particular scientific problem. The RegTAP specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries. RegTAP 1.1, as a minor version increment over RegTAP 1.0, is backward compatible. The main differences between 1.1 and 1.0 are as follows:
Reference Interoperable ImplementationsTwo separate reference implementations of server-side architecture exist at GAVO (and other archives using GAVO's codebase) and STScI
Implementations Validators(If any, indicate here the links to Implementations Validators)Comments from the IVOA Community during RFC/TCG review period: RFC_start_date - RFC_end_dateThe comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date - TCG_end_dateWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
|