VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupI approve this document. The substance of the changes look fine. I have a couple of editorial nit picks:
Data Access Layer Working GroupWe strongly recommend this specification well designed an fully useful for DAL service implementers and applications willing to access them. However it could be interesting that authors take into account following remarks. [Content problems addressed in Volute rev. 4777, rephrasing in Volute rev. 4778 -- MarkusDemleitner - 2018-02-27]
Data Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Solar System Interest GroupA small comment on the altIdentifer element that has been added in this version. The example given proposes a syntax for ORCID, but if you go to the ORCID website, they specifically define how a valid ORCID should be formed: https://support.orcid.org/knowledgebase/articles/116780-structure-of-the-orcid-identifier Example: https://orcid.org/0000-0001-7915-5571 -- BaptisteCecconi - 2018-02-01
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : 2018-06-01 through 2018-06-30If 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: | ||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||
<--
|
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupI approve this document. The substance of the changes look fine. I have a couple of editorial nit picks:
Data Access Layer Working GroupWe strongly recommend this specification well designed an fully useful for DAL service implementers and applications willing to access them. However it could be interesting that authors take into account following remarks. [Content problems addressed in Volute rev. 4777, rephrasing in Volute rev. 4778 -- MarkusDemleitner - 2018-02-27]
Data Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Solar System Interest GroupA small comment on the altIdentifer element that has been added in this version. The example given proposes a syntax for ORCID, but if you go to the ORCID website, they specifically define how a valid ORCID should be formed: https://support.orcid.org/knowledgebase/articles/116780-structure-of-the-orcid-identifier Example: https://orcid.org/0000-0001-7915-5571 -- BaptisteCecconi - 2018-02-01
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : 2018-06-01 through 2018-06-30If 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: | |||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||
<--
|
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupI approve this document. The substance of the changes look fine. I have a couple of editorial nit picks:
Data Access Layer Working GroupWe strongly recommend this specification well designed an fully useful for DAL service implementers and applications willing to access them. However it could be interesting that authors take into account following remarks. [Content problems addressed in Volute rev. 4777, rephrasing in Volute rev. 4778 -- MarkusDemleitner - 2018-02-27]
Data Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Solar System Interest GroupA small comment on the altIdentifer element that has been added in this version. The example given proposes a syntax for ORCID, but if you go to the ORCID website, they specifically define how a valid ORCID should be formed: https://support.orcid.org/knowledgebase/articles/116780-structure-of-the-orcid-identifier Example: https://orcid.org/0000-0001-7915-5571 -- BaptisteCecconi - 2018-02-01
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes Committee | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | TCG Vote : TBD through TBD | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | TCG Vote : 2018-06-01 through 2018-06-30 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If 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.
<--
|
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupI approve this document. The substance of the changes look fine. I have a couple of editorial nit picks:
Data Access Layer Working GroupWe strongly recommend this specification well designed an fully useful for DAL service implementers and applications willing to access them. However it could be interesting that authors take into account following remarks. [Content problems addressed in Volute rev. 4777, rephrasing in Volute rev. 4778 -- MarkusDemleitner - 2018-02-27]
Data Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Solar System Interest GroupA small comment on the altIdentifer element that has been added in this version. The example given proposes a syntax for ORCID, but if you go to the ORCID website, they specifically define how a valid ORCID should be formed: https://support.orcid.org/knowledgebase/articles/116780-structure-of-the-orcid-identifier Example: https://orcid.org/0000-0001-7915-5571 -- BaptisteCecconi - 2018-02-01
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Data Curation & Preservation Interest Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Data Curation & Preservation Interest Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Education Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<--
|
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupI approve this document. The substance of the changes look fine. I have a couple of editorial nit picks:
Data Access Layer Working GroupWe strongly recommend this specification well designed an fully useful for DAL service implementers and applications willing to access them. However it could be interesting that authors take into account following remarks. [Content problems addressed in Volute rev. 4777, rephrasing in Volute rev. 4778 -- MarkusDemleitner - 2018-02-27]
Data Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Solar System Interest GroupA small comment on the altIdentifer element that has been added in this version. The example given proposes a syntax for ORCID, but if you go to the ORCID website, they specifically define how a valid ORCID should be formed: https://support.orcid.org/knowledgebase/articles/116780-structure-of-the-orcid-identifier Example: https://orcid.org/0000-0001-7915-5571 -- BaptisteCecconi - 2018-02-01
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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: | |||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
<--
|
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupI approve this document. The substance of the changes look fine. I have a couple of editorial nit picks:
Data Access Layer Working GroupWe strongly recommend this specification well designed an fully useful for DAL service implementers and applications willing to access them. However it could be interesting that authors take into account following remarks. [Content problems addressed in Volute rev. 4777, rephrasing in Volute rev. 4778 -- MarkusDemleitner - 2018-02-27]
Data Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Solar System Interest GroupA small comment on the altIdentifer element that has been added in this version. The example given proposes a syntax for ORCID, but if you go to the ORCID website, they specifically define how a valid ORCID should be formed: https://support.orcid.org/knowledgebase/articles/116780-structure-of-the-orcid-identifier Example: https://orcid.org/0000-0001-7915-5571 -- BaptisteCecconi - 2018-02-01
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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: | |||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||
<--
|
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupI approve this document. The substance of the changes look fine. I have a couple of editorial nit picks:
Data Access Layer Working GroupWe strongly recommend this specification well designed an fully useful for DAL service implementers and applications willing to access them. However it could be interesting that authors take into account following remarks. [Content problems addressed in Volute rev. 4777, rephrasing in Volute rev. 4778 -- MarkusDemleitner - 2018-02-27]
Data Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Solar System Interest GroupA small comment on the altIdentifer element that has been added in this version. The example given proposes a syntax for ORCID, but if you go to the ORCID website, they specifically define how a valid ORCID should be formed: https://support.orcid.org/knowledgebase/articles/116780-structure-of-the-orcid-identifier Example: https://orcid.org/0000-0001-7915-5571 -- BaptisteCecconi - 2018-02-01
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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: | |||||||||||||||||||||||||||||||||||||||||||||||||||
< < | <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> | ||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupI approve this document. The substance of the changes look fine. I have a couple of editorial nit picks:
Data Access Layer Working GroupWe strongly recommend this specification well designed an fully useful for DAL service implementers and applications willing to access them. However it could be interesting that authors take into account following remarks. [Content problems addressed in Volute rev. 4777, rephrasing in Volute rev. 4778 -- MarkusDemleitner - 2018-02-27]
Data Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Solar System Interest GroupA small comment on the altIdentifer element that has been added in this version. The example given proposes a syntax for ORCID, but if you go to the ORCID website, they specifically define how a valid ORCID should be formed: https://support.orcid.org/knowledgebase/articles/116780-structure-of-the-orcid-identifier Example: https://orcid.org/0000-0001-7915-5571 -- BaptisteCecconi - 2018-02-01
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.
Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupI approve this document. The substance of the changes look fine. I have a couple of editorial nit picks:
Data Access Layer Working Group | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | We strongly recommend this specification well designed an fully useful for DAL service implementers and applications willing to access them. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | We strongly recommend this specification well designed an fully useful for DAL service implementers and applications willing to access them. However it could be interesting that authors take into account following remarks. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | However it could be interesting that authors take into account following remarks. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | [Content problems addressed in Volute rev. 4777, rephrasing in Volute rev. 4778 -- MarkusDemleitner - 2018-02-27] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- FrancoisBonnarel - 2018-02-24 -- MarcoMolinaro - 2018-02-24 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Solar System Interest GroupA small comment on the altIdentifer element that has been added in this version. The example given proposes a syntax for ORCID, but if you go to the ORCID website, they specifically define how a valid ORCID should be formed: https://support.orcid.org/knowledgebase/articles/116780-structure-of-the-orcid-identifier Example: https://orcid.org/0000-0001-7915-5571 -- BaptisteCecconi - 2018-02-01 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupI approve this document. The substance of the changes look fine. I have a couple of editorial nit picks:
Data Access Layer Working Group | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
We strongly recommend this specification well designed an fully useful for DAL service implementers and applications willing to access them.
However it could be interesting that authors take into account following remarks.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Solar System Interest GroupA small comment on the altIdentifer element that has been added in this version. The example given proposes a syntax for ORCID, but if you go to the ORCID website, they specifically define how a valid ORCID should be formed: https://support.orcid.org/knowledgebase/articles/116780-structure-of-the-orcid-identifier Example: https://orcid.org/0000-0001-7915-5571 -- BaptisteCecconi - 2018-02-01
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupI approve this document. The substance of the changes look fine. I have a couple of editorial nit picks:
Data Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Solar System Interest GroupA small comment on the altIdentifer element that has been added in this version. The example given proposes a syntax for ORCID, but if you go to the ORCID website, they specifically define how a valid ORCID should be formed: https://support.orcid.org/knowledgebase/articles/116780-structure-of-the-orcid-identifier Example: https://orcid.org/0000-0001-7915-5571 -- BaptisteCecconi - 2018-02-01 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
TCG Chair & Vice ChairApplications Working GroupI approve this document. The substance of the changes look fine. I have a couple of editorial nit picks:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Solar System Interest GroupA small comment on the altIdentifer element that has been added in this version. The example given proposes a syntax for ORCID, but if you go to the ORCID website, they specifically define how a valid ORCID should be formed: https://support.orcid.org/knowledgebase/articles/116780-structure-of-the-orcid-identifier Example: https://orcid.org/0000-0001-7915-5571 -- BaptisteCecconi - 2018-02-01 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
TCG Chair & Vice ChairApplications Working Group | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | I approve this document. The substance of the changes look fine. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | I approve this document. The substance of the changes look fine. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I have a couple of editorial nit picks: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | The version attribute of an vr:Resource element gives the version of the schema it was written against, as prescribed in the IVOA Note “XML Schema Versioning Policies” (?). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- TomDonaldson - 2018-01-31 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working Group | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
I approve this document. The substance of the changes look fine.
I have a couple of editorial nit picks:
The version attribute of an vr:Resource element gives the version of the schema it was written against, as prescribed in the IVOA Note “XML Schema Versioning Policies” (?).
-- TomDonaldson - 2018-01-31
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
Registry Working GroupI approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. -- TheresaDower - 2018-01-29Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I approve this document.
-- BrianMajor - 2017-12-21
Registry Working Group | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | I approve this document on behalf of Registry, as of 2017-11-08 (volute revision 4567). These necessary changes include limiting securityMethod to 0 or 1 elements as discussed at Santiago based on issues with client discovery of TAP services with authorized/unauthorized endpoints. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | I approve this document on behalf of Registry, as of 2018-01-29 (volute revision 4720). These necessary changes include noting that TAP and other service clients may only use the first SecurityMethod element listed, if existent. Several options from service provider and client experience have been proposed during and after the review period for this document, and this one is acceptable. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | -- TheresaDower - 2017-11-08 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | -- TheresaDower - 2018-01-29 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working Group | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Registry Working GroupI approve this document on behalf of Registry, as of 2017-11-08 (volute revision 4567). These necessary changes include limiting securityMethod to 0 or 1 elements as discussed at Santiago based on issues with client discovery of TAP services with authorized/unauthorized endpoints. -- TheresaDower - 2017-11-08Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working GroupRegistry Working Group | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | I approve this document on behalf of Registry, as of 2017-11-08 (volute revision 4567). These necessary changes include limiting securityMethod to 0 or 1 elements as discussed at Santiago based on issues with client discovery of TAP services with authorized/unauthorized endpoints. -- TheresaDower - 2017-11-08 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Semantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working GroupRegistry Working GroupSemantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
errors and typos in line numbers appear as 5f , 47ff... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Fig. 1 the architecture diagram is just a Specimen. Should be updated to show the IVOA specs related to VOResource ... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Fig. 1 the architecture diagram is just a Specimen. Should be updated to show the IVOA specs related to VOResource ... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Section 2.2 defines clearly how to use vr:Interface in capability but a real example in XML would be very welcome. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subsection 2.3.2 : Footnote (3) should mention the xml schemata' page at http://ivoa.net/xml/index.html to show the xml schemata extended for VOResource in practice | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Page 18: Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Missing reference (?) for "XML schema versioning policies" | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Missing reference (?) for "XML schema versioning policies" | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
3.1.2 Curation Metadata Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
p.20 a logo need only be provided ...--> a logo needs only ... ? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Definition of VOResource vocabulary terms.
The list mentioned in the specification will be available soon under http://ivoa.net/, the current link is broken but the 3 vocabulary files can be accessed currently under http://docs.g-vo.org/vocab-test There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
By externalising the literal values expected in VOresource documents, we may allow various dialects of VOresource v1.1 to co-exist in the VO ecosystem if we do not synchronize the version of the standard ( V1.1) with the version of the vocabularies used by VOResource. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I suppose the validators for VOResource1.1 XML records operate for checking the validity of terms defined in the vocabulary and then this implies that the vocabulary is also versionned as belonguing to the VOResource 1.1 spec. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The relationship_type literals rely on the current version of the DataCite vocabulary. what kind of synchronicity do we expect with the Datacite vocabulary? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
While validating the registry records produced, it would be interesting to store the statistics for the terms used belonguing to these vocabularies. If the approved vocabulary has to stick to some version of the specification, the XML schema for these terms could also be provided in addition to RDF TTL. and then this can be checked and validated in an XML parser. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MireilleLouys - 2017-09-01
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Thanks for corrections and comments . The document in the revised version is approved for the Semantics WG point of view. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | -- MireilleLouys - 2017-10-11 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working GroupRegistry Working GroupSemantics Working Group | ||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||
< < | Comments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version: page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document. errors and typos in line numbers appear as 5f , 47ff... Fig. 1 the architecture diagram is just a Specimen. Should be updated to show the IVOA specs related to VOResource ... Section 2.2 defines clearly how to use vr:Interface in capability but a real example in XML would be very welcome. Subsection 2.3.2 : Footnote (3) should mention the xml schemata' page at http://ivoa.net/xml/index.html to show the xml schemata extended for VOResource in practice Page 18: Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading Missing reference (?) for "XML schema versioning policies" 3.1.2 Curation Metadata Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much p.20 a logo need only be provided ...--> a logo needs only ... ? | |||||||||||||||||||||||||
> > | Comments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version: page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document. | |||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||
> > |
errors and typos in line numbers appear as 5f , 47ff...
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much
| |||||||||||||||||||||||||
The list mentioned in the specification will be available soon under http://ivoa.net/, the current link is broken but the 3 vocabulary files can be accessed currently under http://docs.g-vo.org/vocab-test There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance. | ||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
By externalising the literal values expected in VOresource documents, we may allow various dialects of VOresource v1.1 to co-exist in the VO ecosystem if we do not synchronize the version of the standard ( V1.1) with the version of the vocabularies used by VOResource. | ||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
I suppose the validators for VOResource1.1 XML records operate for checking the validity of terms defined in the vocabulary and then this implies that the vocabulary is also versionned as belonguing to the VOResource 1.1 spec. | ||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
The relationship_type literals rely on the current version of the DataCite vocabulary. what kind of synchronicity do we expect with the Datacite vocabulary? | ||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
While validating the registry records produced, it would be interesting to store the statistics for the terms used belonguing to these vocabularies. If the approved vocabulary has to stick to some version of the specification, the XML schema for these terms could also be provided in addition to RDF TTL. and then this can be checked and validated in an XML parser. | ||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
-- MireilleLouys - 2017-09-01 | ||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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: | ||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
| ||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Section 2:
General remarks: It is sometime difficult to make a clear distinction between what is normative and what is general consideration on XML schemas or VO versioning. I think that building an VR extension from the doc wouln't be easy t all.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P7: S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P9: S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P14: A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P15: Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Section 3:
P17 (bottom) see vr:ValidationLevel
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P20: "Element creator": useless comment about logos which are introduced later
P23: 1st date comment: "This includes the the traditional and deprecated"
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Corrected document is fine to DM -- LaurentMichel - 2017-09-06 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Grid & Web Services Working GroupRegistry Working GroupSemantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document. errors and typos in line numbers appear as 5f , 47ff... Fig. 1 the architecture diagram is just a Specimen. Should be updated to show the IVOA specs related to VOResource ... Section 2.2 defines clearly how to use vr:Interface in capability but a real example in XML would be very welcome. Subsection 2.3.2 : Footnote (3) should mention the xml schemata' page at http://ivoa.net/xml/index.html to show the xml schemata extended for VOResource in practice Page 18: Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading Missing reference (?) for "XML schema versioning policies" 3.1.2 Curation Metadata Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much p.20 a logo need only be provided ...--> a logo needs only ... ?
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance. By externalising the literal values expected in VOresource documents, we may allow various dialects of VOresource v1.1 to co-exist in the VO ecosystem if we do not synchronize the version of the standard ( V1.1) with the version of the vocabularies used by VOResource. I suppose the validators for VOResource1.1 XML records operate for checking the validity of terms defined in the vocabulary and then this implies that the vocabulary is also versionned as belonguing to the VOResource 1.1 spec. The relationship_type literals rely on the current version of the DataCite vocabulary. what kind of synchronicity do we expect with the Datacite vocabulary? While validating the registry records produced, it would be interesting to store the statistics for the terms used belonguing to these vocabularies. If the approved vocabulary has to stick to some version of the specification, the XML schema for these terms could also be provided in addition to RDF TTL. and then this can be checked and validated in an XML parser. -- MireilleLouys - 2017-09-01 Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The schema of VR extensions can be either in the VR core or in specific XML documents. It would be nice to give a tip for getting the list of available extensions and for locating their schemas (in sec 2.2.5?).
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy" | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P8: S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P18: identifier: a ref to http://www.ivoa.net/documents/IVOAIdentifiers/index.html might recall how important is this point
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
Grid & Web Services Working GroupRegistry Working GroupSemantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document. errors and typos in line numbers appear as 5f , 47ff... Fig. 1 the architecture diagram is just a Specimen. Should be updated to show the IVOA specs related to VOResource ... Section 2.2 defines clearly how to use vr:Interface in capability but a real example in XML would be very welcome. Subsection 2.3.2 : Footnote (3) should mention the xml schemata' page at http://ivoa.net/xml/index.html to show the xml schemata extended for VOResource in practice Page 18: Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading Missing reference (?) for "XML schema versioning policies" 3.1.2 Curation Metadata Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much p.20 a logo need only be provided ...--> a logo needs only ... ?
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance. By externalising the literal values expected in VOresource documents, we may allow various dialects of VOresource v1.1 to co-exist in the VO ecosystem if we do not synchronize the version of the standard ( V1.1) with the version of the vocabularies used by VOResource. I suppose the validators for VOResource1.1 XML records operate for checking the validity of terms defined in the vocabulary and then this implies that the vocabulary is also versionned as belonguing to the VOResource 1.1 spec. The relationship_type literals rely on the current version of the DataCite vocabulary. what kind of synchronicity do we expect with the Datacite vocabulary? While validating the registry records produced, it would be interesting to store the statistics for the terms used belonguing to these vocabularies. If the approved vocabulary has to stick to some version of the specification, the XML schema for these terms could also be provided in addition to RDF TTL. and then this can be checked and validated in an XML parser. -- MireilleLouys - 2017-09-01 Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P4 after the citation it is said that VR does not "describe how the terms and values should be encode" and six lines ahead that the document "provides a concrete encoding of the resulting metadata model." The scope of what is encoded here could be clearer.
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
"XML Schema VersioningPolicies" missing ref P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P23: 1st date comment: URL not readable P23: 1st date comment: "This includes the the traditional and deprecated" | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- LaurentMichel - 2017-08-21
Grid & Web Services Working GroupRegistry Working GroupSemantics Working GroupComments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document. errors and typos in line numbers appear as 5f , 47ff... Fig. 1 the architecture diagram is just a Specimen. Should be updated to show the IVOA specs related to VOResource ... Section 2.2 defines clearly how to use vr:Interface in capability but a real example in XML would be very welcome. Subsection 2.3.2 : Footnote (3) should mention the xml schemata' page at http://ivoa.net/xml/index.html to show the xml schemata extended for VOResource in practice Page 18: Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading Missing reference (?) for "XML schema versioning policies" 3.1.2 Curation Metadata Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much p.20 a logo need only be provided ...--> a logo needs only ... ?
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | By externalising the literal values expected in VOresource documents, we may allow various dialects of VOresource v1.1 to co-exist in the VO ecosystem if we do not synchronize the version of the standard ( V1.1) with the version of the vocabularies used by VOResource. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | By externalising the literal values expected in VOresource documents, we may allow various dialects of VOresource v1.1 to co-exist in the VO ecosystem if we do not synchronize the version of the standard ( V1.1) with the version of the vocabularies used by VOResource. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I suppose the validators for VOResource1.1 XML records operate for checking the validity of terms defined in the vocabulary and then this implies that the vocabulary is also versionned as belonguing to the VOResource 1.1 spec.
The relationship_type literals rely on the current version of the DataCite vocabulary. what kind of synchronicity do we expect with the Datacite vocabulary?
While validating the registry records produced, it would be interesting to store the statistics for the terms used belonguing to these vocabularies.
If the approved vocabulary has to stick to some version of the specification, the XML schema for these terms could also be provided in addition to RDF TTL. and then this can be checked and validated in an XML parser.
-- MireilleLouys - 2017-09-01
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> <!-- * Set ALLOWTOPICRENAME = TWikiAdminGroup --> |
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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 | ||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||
> > | | |||||||||||||||||||||||||
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)
| ||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||
P4 after the citation it is said that VR does not "describe how the terms and values should be encode" and six lines ahead that the document "provides a concrete encoding of the resulting metadata model." The scope of what is encoded here could be clearer.
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy"
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help.
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well.
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
| ||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||
-- LaurentMichel - 2017-08-21
Grid & Web Services Working GroupRegistry Working GroupSemantics Working Group | ||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||
> > | Comments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version: page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document. errors and typos in line numbers appear as 5f , 47ff... Fig. 1 the architecture diagram is just a Specimen. Should be updated to show the IVOA specs related to VOResource ... Section 2.2 defines clearly how to use vr:Interface in capability but a real example in XML would be very welcome. Subsection 2.3.2 : Footnote (3) should mention the xml schemata' page at http://ivoa.net/xml/index.html to show the xml schemata extended for VOResource in practice Page 18: Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading Missing reference (?) for "XML schema versioning policies" 3.1.2 Curation Metadata Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance a) vr:Curation Metadata elements b) Vr types involved for curation b.1) vr:Resource Name type b.2) vr:Creator type etc ... this will help readers of the html version very much p.20 a logo need only be provided ...--> a logo needs only ... ?
There are several files for allocating a value to VOresource element fields : - content_level - content_type - date_role - relationship_type Theses terms are defined for the scope of the VOResource usage. Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance. By externalising the literal values expected in VOresource documents, we may allow various dialects of VOresource v1.1 to co-exist in the VO ecosystem if we do not synchronize the version of the standard ( V1.1) with the version of the vocabularies used by VOResource. I suppose the validators for VOResource1.1 XML records operate for checking the validity of terms defined in the vocabulary and then this implies that the vocabulary is also versionned as belonguing to the VOResource 1.1 spec. The relationship_type literals rely on the current version of the DataCite vocabulary. what kind of synchronicity do we expect with the Datacite vocabulary? While validating the registry records produced, it would be interesting to store the statistics for the terms used belonguing to these vocabularies. If the approved vocabulary has to stick to some version of the specification, the XML schema for these terms could also be provided in addition to RDF TTL. and then this can be checked and validated in an XML parser. -- MireilleLouys - 2017-09-01 | |||||||||||||||||||||||||
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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: | ||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
| ||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
| ||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||
< < | <--
|
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P4 after the citation it is said that VR does not "describe how the terms and values should be encode" and six lines ahead that the document "provides a concrete encoding of the resulting metadata model." The scope of what is encoded here could be clearer. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Section 2: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | General remarks: It is sometime difficult to make a clear distinction between what is normative and what is general consideration on XML schemas or VO versionning. I think that building an VR extension from the doc wouln't be easy t all. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | General remarks: It is sometime difficult to make a clear distinction between what is normative and what is general consideration on XML schemas or VO versioning. I think that building an VR extension from the doc wouln't be easy t all. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The schema of VR extensions can be either in the VR core or in specific XML documents. It would be nice to give a tip for getting the list of available extensions and for locating their schemas (in sec 2.2.5?). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P7: S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy" | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | P8: S2.2:The element elementFormDefault is not in the example, is unqualified the default value? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
S2.2:The element elementFormDefault is not in the example, is unqualified the default value? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P9: S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P14: A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P15: Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Section 3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | P17 (bottom) see vr:ValidationLevel P18: identifier: a ref to http://www.ivoa.net/documents/IVOAIdentifiers/index.html might recall how important is this point after the table:"they describe the resource metadata Description contained" "XML Schema VersioningPolicies" missing ref P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID. P20: "Element creator": useless comment about logos which are introduced later P23: 1st date comment: URL not readable P23: 1st date comment: "This includes the the traditional and deprecated" | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | P17 (bottom) see vr:ValidationLevel | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | P18: identifier: a ref to http://www.ivoa.net/documents/IVOAIdentifiers/index.html might recall how important is this point
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P23: 1st date comment: "This includes the the traditional and deprecated"
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- LaurentMichel - 2017-08-21
Grid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<--
<--
|
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML document) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P4 after the citation it is said that VR does not "describe how the terms and values should be encode" and six lines ahead that the document "provides a concrete encoding of the resulting metadata model." The scope of what is encoded here could be clearer. Section 2: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | General remarks: It is sometime difficult to make a clear distinction between what is normative and what is general consideration on XML schemas or VO versionning. It could be more comprehensive to have one section giving a raw descroption of the model components and anotherone saying how to extend VR it, even if the general considerations are gathered in an introduction (design guideline) or pushed down in an appendix. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | General remarks: It is sometime difficult to make a clear distinction between what is normative and what is general consideration on XML schemas or VO versionning. I think that building an VR extension from the doc wouln't be easy t all. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The schema of VR extensions can be either in the VR core or in specific XML documents. It would be nice to give a tip for getting the list of available extensions and for locating their schemas (in sec 2.2.5?). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | P7: S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff S2.1:last paragraph: missing reference to the "versioning policy" | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | P7: S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff (typo) S2.1:last paragraph: missing reference to the "versioning policy" | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P8: S2.2:The element elementFormDefault is not in the example, is unqualified the default value? P9: S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help. P14: A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations. P15: Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well. Section 3: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | P17 (bottom) see vr:ValidationLevel P18: identifier: a ref to http://www.ivoa.net/documents/IVOAIdentifiers/index.html might recall how important is this point after the table:"they describe the resource metadata Description contained" "XML Schema VersioningPolicies" missing ref P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID. P20: "Element creator": useless comment about logos which are introduced later P23: 1st date comment: URL not readable P23: 1st date comment: "This includes the the traditional and deprecated" | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | P17 (bottom) see vr:ValidationLevel P18: identifier: a ref to http://www.ivoa.net/documents/IVOAIdentifiers/index.html might recall how important is this point after the table:"they describe the resource metadata Description contained" "XML Schema VersioningPolicies" missing ref P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID. P20: "Element creator": useless comment about logos which are introduced later P23: 1st date comment: URL not readable P23: 1st date comment: "This includes the the traditional and deprecated" | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- LaurentMichel - 2017-08-21
Grid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<--
<--
|
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working Group(page numbers refer to the PDF) P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML document) P4 after the citation it is said that VR does not "describe how the terms and values should be encode" and six lines ahead that the document "provides a concrete encoding of the resulting metadata model." The scope of what is encoded here could be clearer. Section 2: General remarks: It is sometime difficult to make a clear distinction between what is normative and what is general consideration on XML schemas or VO versionning. It could be more comprehensive to have one section giving a raw descroption of the model components and anotherone saying how to extend VR it, even if the general considerations are gathered in an introduction (design guideline) or pushed down in an appendix. The schema of VR extensions can be either in the VR core or in specific XML documents. It would be nice to give a tip for getting the list of available extensions and for locating their schemas (in sec 2.2.5?). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | P7: S2: item 2: A pointer to the allowed vocabulary would be nice S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff S2.1:last paragraph: missing reference to the "versioning policy" | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | P7: S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?) S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff S2.1:last paragraph: missing reference to the "versioning policy" | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P8: S2.2:The element elementFormDefault is not in the example, is unqualified the default value? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | P9: S2.2: Double reference for list items ("corresponding to the section...." a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | P9: S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
P14: A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations. P15: Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | (tbc) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Section 3: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
P17 (bottom) see vr:ValidationLevel P18: identifier: a ref to http://www.ivoa.net/documents/IVOAIdentifiers/index.html might recall how important is this point after the table:"they describe the resource metadata Description contained" "XML Schema VersioningPolicies" missing ref P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID. P20: "Element creator": useless comment about logos which are introduced later P23: 1st date comment: URL not readable P23: 1st date comment: "This includes the the traditional and deprecated" | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- LaurentMichel - 2017-08-21
Grid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<--
<--
|
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working Group | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | (page numbers refer to the PDF)
P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML document)
P4 after the citation it is said that VR does not "describe how the terms and values should be encode" and six lines ahead that the document "provides a concrete encoding of the resulting metadata model." The scope of what is encoded here could be clearer.
Section 2:
General remarks: It is sometime difficult to make a clear distinction between what is normative and what is general consideration on XML schemas or VO versionning. It could be more comprehensive to have one section giving a raw descroption of the model components and anotherone saying how to extend VR it, even if the general considerations are gathered in an introduction (design guideline) or pushed down in an appendix.
The schema of VR extensions can be either in the VR core or in specific XML documents. It would be nice to give a tip for getting the list of available extensions and for locating their schemas (in sec 2.2.5?).
P7: S2: item 2: A pointer to the allowed vocabulary would be nice S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one. S2:item 7: reference to line 47ff S2.1:last paragraph: missing reference to the "versioning policy" P8: S2.2:The element elementFormDefault is not in the example, is unqualified the default value? P9: S2.2: Double reference for list items ("corresponding to the section...." a after "these documents are defined in...") S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list? S2.2: item 5: A quality flag in the example might help. P14: A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations. P15: Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help. After the item list: an example showing the 2 derivation modes would help as well. (tbc) -- LaurentMichel - 2017-08-21 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Grid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<--
<--
|
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<--
<--
|
VOResource 1.1 Proposed Recommendation: Request for CommentsVOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes). The latest edition of VOResource 1.1 can be found at: Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory.Reference Interoperable ImplementationsVOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop. Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.Implementations ValidatorsVOResource 1.1 records can be validated using standard XSD tools. Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15The 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 documentTCG 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 in Databases Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : TBD through TBDIf 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.
<--
<--
|