Difference: VOResource12RFC (1 vs. 7)

Revision 72024-12-20 - GillesLandais

 
META TOPICPARENT name="IvoaResReg"

VOResource-1.2 Proposed Recommendation: Request for Comments

VOResource is an IVOA standard for describing astronomical resources (data collections, services, registries, tools...) within the Virtual Observatory. It provides an XML interchange format for use with registries, and lays the foundations upon which description schemes for concrete resources are built in various VOResource extensions.

Here is a brief summary of the changes from Recommendation 1.1:

  • You can now use DOIs (or other identifier schemes like orcid) wherever we have a ResourceName so far, which includes relationship, authors, and the like.

  • We now spell out what "using the UAT" for our subject keywords mean. If you publish resource records, this probably means that you will have to update them, as it is unlikely that they already have UAT keywords, let alone the with the right syntax.

  • If you machine-readably declare your licenses, you should now use SPDX URIs.

  • The bibliographic source can now be declared machine-readably with DOIs, too (before, there were only bibcodes).

Latest version of VOResource-1.2 can be found at:

Changed:
<
<
>
>
  • https://ivoa.net/documents/VOResource/20241015/index.html
 

Reference Interoperable Implementations

UAT keywords have been in use at GAVO and VizieR for a long time now; see also Sembarebro for a proof-of-concept-level interface using it.

To get an idea for why data providers should take up SPDX URIs, see a query that returns data distributed under CC0 (you should, really):

Added:
>
>
 
select ivoid from rr.resource
where rights_uri ILIKE 'https://spdx.org/licenses/CC0-1.0.html'

Relationships using altIdentifier are available from VizieR (Gilles?).

All of the previous items do not need any special software support.

The ResourceName change requires software support, mainly in RegTAP. A draft of what's needed is on the Heidelberg RegTAP node.

(a) the altIdentifier on facility and instrument is translated into res_detail. If you have an altIdentifier for a facility (ROR anyone?), please register it. It will then show up next to the instrument identifiers when you run

Added:
>
>
 
select *
from rr.res_detail
where detail_xpath like '%altIdentifier'

(b) the altIdentifier on contributor/name, publisher, and contributor are in res_role. I've put in an orcid for demo. If you have orcid fans among your data providers or want to add your own ROR in publisher, please do that and you will show up in the result of

Added:
>
>
 
select *
from rr.res_role
where alt_identifier is not NULL

(c) the altIdentifier on relationship... this will show up in

Added:
>
>
 
select *
from rr.relationship
where related_alt_identifier is not NULL

But that's still waiting for actual records.

Implementations Validators

Basic validation is through any XML schema validator. If unsure, see the Makefile from the source repository for how to use stilts to validate your instance documents.

The RofR validator should be updated soon.

Changed:
<
<

>
>

 

Comments from the IVOA Community during RFC/TCG review period: 2024-11-27 - 2025-01-07

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document



Comments from TCG member during the RFC/TCG Review Period: 2024-11-27 - 2025-01-07

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Changed:
<
<
The addition of alternate identifiers such as DOI and ORCID is a useful change in the VOResource metadata. Here are short comments on the text:
>
>
The addition of alternate identifiers such as DOI and ORCID is a useful change in the VOResource metadata. Here are short comments on the text:
 
  • MathieuServillat, 2024-12-18: "the metadata scheme employed by DataCite, which at the time of writing is at version 4.0 (DataCite Metadata Working Group, 2016)" —> I see that the last version is 4.6, maybe worth updating
  • MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

  • BaptisteCecconi, 2024-11-27: The document uses "should" for specifying which vocabulary has to be used in the VOResource elements with controlled values: "The content of <subject> should be drawn from the Unified Astronomy Thesaurus". Same for content_level and content_type. Why don't we say "MUST"?
Changed:
<
<
  • BaptisteCecconi, 2024-11-27: In the Appendix A, one can read the quoted sentence "use fragments into http://www.ivoa.net/rdf/uat/#", but that quote is found nowhere in the text. It is probably harmless, but this makes all reference to Semantics vocabularies implict in the VOResource instances as well as in the VOResource schema. For the reuse of VOResource outside the IVOA (and for the ease of building application on top of VOResource content), I would be expecting that the reference to the URI scheme (e.g., http://www.ivoa.net/rdf/uat/#) is available formally, either in the VOResource.
>
>
  • BaptisteCecconi, 2024-11-27: In the Appendix A, one can read the quoted sentence "use fragments into http://www.ivoa.net/rdf/uat/#", but that quote is found nowhere in the text. It is probably harmless, but this makes all reference to Semantics vocabularies implict in the VOResource instances as well as in the VOResource schema. For the reuse of VOResource outside the IVOA (and for the ease of building application on top of VOResource content), I would be expecting that the reference to the URI scheme (e.g., http://www.ivoa.net/rdf/uat/#) is available formally, either in the VOResource.
 
  • BaptisteCecconi, 2024-11-27: In section 3.2.2, the rightsURI can contain SPDX URIs. Is it really full URIs? as opposite from the previous comment case (IVOA-UAT, content_level, content_type), which are requiring NOT to use full URIs.
Changed:
<
<
  • BaptisteCecconi, 2024-11-27: In section 2.2.5, the DOI, ORCID and bibcodes identifiers are listed. I propose to also include ROR identifiers (Research Organization Registry: https://ror.org), to include identifiers for organizations.
>
>
  • BaptisteCecconi, 2024-11-27: In section 2.2.5, the DOI, ORCID and bibcodes identifiers are listed. I propose to also include ROR identifiers (Research Organization Registry: https://ror.org), to include identifiers for organizations.
 

Data Curation & Preservation Interest Group

Changed:
<
<
>
>
  • Gilles Landais, 2024-12-20: congratulate this version that allows DOI, SPDX Licences, UAT
Added:
>
>
  • Gilles Landais, 2024-12-20: as semantic, we propose also to include the RoR for organization

  • Gilles Landais, 2024-12-20: Implementation in VizieR
    VizieR provides already the catalogue DOI using altIdentifier.

    Possible update in VizieR:
    • extend relationships to link original dataset using DOI (possible but for a small list of catalogues)
      eg: Gaia DR3 catalogue which is available in CDS and in its original repository at ESA. We could align the registry with what we do with DataCite metadata.

      <relationshipType>isVariantFormOf</relationshipType>
      <relatedResource altIdentifier="doi:10.5270/esa-qa4lep3">Gaia DR3 at ESA</relatedResource>
      </relationship>

    • Complete the bibcode of the reference article with the article DOI

 

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Radio Astronomy Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee


TCG Vote : Vote_start_date - Vote_end_date

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.

Group Yes No Abstain Comments
TCG        
Apps        
DAL        
DM        
GWS        
Registry        
Semantics        
Changed:
<
<
DCP        
>
>
DCP x      
 
Edu        
KDIG        
Ops        
Radio        
SSIG        
Theory        
TD        
<nop>StdProc        


Changed:
<
<

<!--</p> <ul> <li> <ul> <li> Set ALLOWTOPICRENAME =<span class="WYSIWYG_PROTECTED"> TWikiAdminGroup</span> </li> </ul></li> </ul>-->
>
>

<!--</p> <ul> <li> <ul> <li> Set ALLOWTOPICRENAME =<span class="WYSIWYG_PROTECTED"> TWikiAdminGroup </span> </li> </ul></li> </ul>-->
Added:
>
>

Revision 62024-12-18 - MathieuServillat

 
META TOPICPARENT name="IvoaResReg"

VOResource-1.2 Proposed Recommendation: Request for Comments

VOResource is an IVOA standard for describing astronomical resources (data collections, services, registries, tools...) within the Virtual Observatory. It provides an XML interchange format for use with registries, and lays the foundations upon which description schemes for concrete resources are built in various VOResource extensions.

Here is a brief summary of the changes from Recommendation 1.1:

  • You can now use DOIs (or other identifier schemes like orcid) wherever we have a ResourceName so far, which includes relationship, authors, and the like.

  • We now spell out what "using the UAT" for our subject keywords mean. If you publish resource records, this probably means that you will have to update them, as it is unlikely that they already have UAT keywords, let alone the with the right syntax.

  • If you machine-readably declare your licenses, you should now use SPDX URIs.

  • The bibliographic source can now be declared machine-readably with DOIs, too (before, there were only bibcodes).

Latest version of VOResource-1.2 can be found at:

Reference Interoperable Implementations

UAT keywords have been in use at GAVO and VizieR for a long time now; see also Sembarebro for a proof-of-concept-level interface using it.

To get an idea for why data providers should take up SPDX URIs, see a query that returns data distributed under CC0 (you should, really):

Deleted:
<
<
 
select ivoid from rr.resource
where rights_uri ILIKE 'https://spdx.org/licenses/CC0-1.0.html'

Relationships using altIdentifier are available from VizieR (Gilles?).

All of the previous items do not need any special software support.

Changed:
<
<
The ResourceName change requires software support, mainly in RegTAP. A
>
>
The ResourceName change requires software support, mainly in RegTAP. A draft of what's needed is on the Heidelberg RegTAP node.
Deleted:
<
<
draft of what's needed is on the Heidelberg RegTAP node.
 
Changed:
<
<
(a) the altIdentifier on facility and instrument is translated into res_detail. If you have an altIdentifier for a facility (ROR anyone?),
>
>
(a) the altIdentifier on facility and instrument is translated into res_detail. If you have an altIdentifier for a facility (ROR anyone?), please register it. It will then show up next to the instrument identifiers when you run
select *

Deleted:
<
<
please register it. It will then show up next to the instrument identifiers when you run

select *

 from rr.res_detail where detail_xpath like '%altIdentifier'
Changed:
<
<
(b) the altIdentifier on contributor/name, publisher, and contributor are in res_role. I've put in an orcid for demo. If you have orcid
>
>
(b) the altIdentifier on contributor/name, publisher, and contributor are in res_role. I've put in an orcid for demo. If you have orcid fans among your data providers or want to add your own ROR in publisher, please do that and you will show up in the result of
select *

Deleted:
<
<
fans among your data providers or want to add your own ROR in publisher, please do that and you will show up in the result of

select *

 from rr.res_role where alt_identifier is not NULL

(c) the altIdentifier on relationship... this will show up in

Changed:
<
<
>
>
select *

Deleted:
<
<
select *

 from rr.relationship where related_alt_identifier is not NULL

But that's still waiting for actual records.

Implementations Validators

Changed:
<
<
Basic validation is through any XML schema validator. If unsure, see the Makefile from the source repository for how to use stilts to validate your instance documents.
>
>
Basic validation is through any XML schema validator. If unsure, see the Makefile from the source repository for how to use stilts to validate your instance documents.
  The RofR validator should be updated soon.
Changed:
<
<
>
>

 

Comments from the IVOA Community during RFC/TCG review period: 2024-11-27 - 2025-01-07

Changed:
<
<

The comments from the TCG members during the RFC/TCG review should be included in the next section.

>
>

The comments from the TCG members during the RFC/TCG review should be included in the next section.

  In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document



Comments from TCG member during the RFC/TCG Review Period: 2024-11-27 - 2025-01-07

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Added:
>
>
The addition of alternate identifiers such as DOI and ORCID is a useful change in the VOResource metadata. Here are short comments on the text:

  • MathieuServillat, 2024-12-18: "the metadata scheme employed by DataCite, which at the time of writing is at version 4.0 (DataCite Metadata Working Group, 2016)" —> I see that the last version is 4.6, maybe worth updating
  • MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)
 

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

  • BaptisteCecconi, 2024-11-27: The document uses "should" for specifying which vocabulary has to be used in the VOResource elements with controlled values: "The content of <subject> should be drawn from the Unified Astronomy Thesaurus". Same for content_level and content_type. Why don't we say "MUST"?
  • BaptisteCecconi, 2024-11-27: In the Appendix A, one can read the quoted sentence "use fragments into http://www.ivoa.net/rdf/uat/#", but that quote is found nowhere in the text. It is probably harmless, but this makes all reference to Semantics vocabularies implict in the VOResource instances as well as in the VOResource schema. For the reuse of VOResource outside the IVOA (and for the ease of building application on top of VOResource content), I would be expecting that the reference to the URI scheme (e.g., http://www.ivoa.net/rdf/uat/#) is available formally, either in the VOResource.
  • BaptisteCecconi, 2024-11-27: In section 3.2.2, the rightsURI can contain SPDX URIs. Is it really full URIs? as opposite from the previous comment case (IVOA-UAT, content_level, content_type), which are requiring NOT to use full URIs.
  • BaptisteCecconi, 2024-11-27: In section 2.2.5, the DOI, ORCID and bibcodes identifiers are listed. I propose to also include ROR identifiers (Research Organization Registry: https://ror.org), to include identifiers for organizations.

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Radio Astronomy Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee


Changed:
<
<

TCG Vote : Vote_start_date - Vote_end_date

>
>

TCG Vote : Vote_start_date - Vote_end_date

  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.

Group Yes No Abstain Comments
TCG        
Apps        
DAL        
DM        
GWS        
Registry        
Semantics        
DCP        
Edu        
KDIG        
Ops        
Radio        
SSIG        
Theory        
TD        
Changed:
<
<
StdProc        
>
>
<nop>StdProc        
 
Changed:
<
<

<--

-->
>
>

<!--</p> <ul> <li> <ul> <li> Set ALLOWTOPICRENAME =<span class="WYSIWYG_PROTECTED"> TWikiAdminGroup</span> </li> </ul></li> </ul>-->

Revision 52024-11-27 - MarkusDemleitner

 
META TOPICPARENT name="IvoaResReg"

VOResource-1.2 Proposed Recommendation: Request for Comments

VOResource is an IVOA standard for describing astronomical resources (data collections, services, registries, tools...) within the Virtual Observatory. It provides an XML interchange format for use with registries, and lays the foundations upon which description schemes for concrete resources are built in various VOResource extensions.

Here is a brief summary of the changes from Recommendation 1.1:

  • You can now use DOIs (or other identifier schemes like orcid) wherever we have a ResourceName so far, which includes relationship, authors, and the like.

  • We now spell out what "using the UAT" for our subject keywords mean. If you publish resource records, this probably means that you will have to update them, as it is unlikely that they already have UAT keywords, let alone the with the right syntax.

  • If you machine-readably declare your licenses, you should now use SPDX URIs.

  • The bibliographic source can now be declared machine-readably with DOIs, too (before, there were only bibcodes).

Latest version of VOResource-1.2 can be found at:

Reference Interoperable Implementations

UAT keywords have been in use at GAVO and VizieR for a long time now; see also Sembarebro for a proof-of-concept-level interface using it.

To get an idea for why data providers should take up SPDX URIs, see a query that returns data distributed under CC0 (you should, really):

Added:
>
>
 
select ivoid from rr.resource
where rights_uri ILIKE 'https://spdx.org/licenses/CC0-1.0.html'

Relationships using altIdentifier are available from VizieR (Gilles?).

All of the previous items do not need any special software support.

Changed:
<
<
For the ResourceName change, that is not the case. To make it useful, RegTAP will need an update, presumably adding alt_identifier columns to res_role and relationship, and res_details keys for facility and instrument. For the Heidelberg RegTAP server, this ought to happen during December 2025.
>
>
The ResourceName change requires software support, mainly in RegTAP. A
Added:
>
>
draft of what's needed is on the Heidelberg RegTAP node.
 
Added:
>
>
(a) the altIdentifier on facility and instrument is translated into res_detail. If you have an altIdentifier for a facility (ROR anyone?), please register it. It will then show up next to the instrument identifiers when you run

select *
from rr.res_detail
where detail_xpath like '%altIdentifier'

(b) the altIdentifier on contributor/name, publisher, and contributor are in res_role. I've put in an orcid for demo. If you have orcid fans among your data providers or want to add your own ROR in publisher, please do that and you will show up in the result of

select *
from rr.res_role
where alt_identifier is not NULL

(c) the altIdentifier on relationship... this will show up in

select *
from rr.relationship
where related_alt_identifier is not NULL

But that's still waiting for actual records.

 

Implementations Validators

Basic validation is through any XML schema validator. If unsure, see the Makefile from the source repository for how to use stilts to validate your instance documents.

The RofR validator should be updated soon.



Comments from the IVOA Community during RFC/TCG review period: 2024-11-27 - 2025-01-07

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document



Comments from TCG member during the RFC/TCG Review Period: 2024-11-27 - 2025-01-07

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Changed:
<
<
  • BaptisteCecconi, 2024-11-27: The document uses "should" for specifying which vocabulary has to be used in the VOResource elements with controlled values: "The content of <subject> should be drawn from the Unified Astronomy Thesaurus". Same for content_level and content_type. Why don't we say "MUST"?
  • BaptisteCecconi, 2024-11-27: In the Appendix A, one can read the quoted sentence "use fragments into http://www.ivoa.net/rdf/uat/#", but that quote is found nowhere in the text. It is probably harmless, but this makes all reference to Semantics vocabularies implict in the VOResource instances as well as in the VOResource schema. For the reuse of VOResource outside the IVOA (and for the ease of building application on top of VOResource content), I would be expecting that the reference to the URI scheme (e.g., http://www.ivoa.net/rdf/uat/#) is available formally, either in the VOResource.
  • BaptisteCecconi, 2024-11-27: In section 3.2.2, the rightsURI can contain SPDX URIs. Is it really full URIs? as opposite from the previous comment case (IVOA-UAT, content_level, content_type), which are requiring NOT to use full URIs.
  • BaptisteCecconi, 2024-11-27: In section 2.2.5, the DOI, ORCID and bibcodes identifiers are listed. I propose to also include ROR identifiers (Research Organization Registry: https://ror.org), to include identifiers for organizations.
>
>
  • BaptisteCecconi, 2024-11-27: The document uses "should" for specifying which vocabulary has to be used in the VOResource elements with controlled values: "The content of <subject> should be drawn from the Unified Astronomy Thesaurus". Same for content_level and content_type. Why don't we say "MUST"?
  • BaptisteCecconi, 2024-11-27: In the Appendix A, one can read the quoted sentence "use fragments into http://www.ivoa.net/rdf/uat/#", but that quote is found nowhere in the text. It is probably harmless, but this makes all reference to Semantics vocabularies implict in the VOResource instances as well as in the VOResource schema. For the reuse of VOResource outside the IVOA (and for the ease of building application on top of VOResource content), I would be expecting that the reference to the URI scheme (e.g., http://www.ivoa.net/rdf/uat/#) is available formally, either in the VOResource.
  • BaptisteCecconi, 2024-11-27: In section 3.2.2, the rightsURI can contain SPDX URIs. Is it really full URIs? as opposite from the previous comment case (IVOA-UAT, content_level, content_type), which are requiring NOT to use full URIs.
  • BaptisteCecconi, 2024-11-27: In section 2.2.5, the DOI, ORCID and bibcodes identifiers are listed. I propose to also include ROR identifiers (Research Organization Registry: https://ror.org), to include identifiers for organizations.
 

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Radio Astronomy Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee


TCG Vote : Vote_start_date - Vote_end_date

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.

Group Yes No Abstain Comments
TCG        
Apps        
DAL        
DM        
GWS        
Registry        
Semantics        
DCP        
Edu        
KDIG        
Ops        
Radio        
SSIG        
Theory        
TD        
StdProc        



<--

-->
Deleted:
<
<

Revision 42024-11-27 - BaptisteCecconi

 
META TOPICPARENT name="IvoaResReg"

VOResource-1.2 Proposed Recommendation: Request for Comments

VOResource is an IVOA standard for describing astronomical resources (data collections, services, registries, tools...) within the Virtual Observatory. It provides an XML interchange format for use with registries, and lays the foundations upon which description schemes for concrete resources are built in various VOResource extensions.

Here is a brief summary of the changes from Recommendation 1.1:

  • You can now use DOIs (or other identifier schemes like orcid) wherever we have a ResourceName so far, which includes relationship, authors, and the like.

  • We now spell out what "using the UAT" for our subject keywords mean. If you publish resource records, this probably means that you will have to update them, as it is unlikely that they already have UAT keywords, let alone the with the right syntax.

  • If you machine-readably declare your licenses, you should now use SPDX URIs.

  • The bibliographic source can now be declared machine-readably with DOIs, too (before, there were only bibcodes).

Latest version of VOResource-1.2 can be found at:

Reference Interoperable Implementations

UAT keywords have been in use at GAVO and VizieR for a long time now; see also Sembarebro for a proof-of-concept-level interface using it.

To get an idea for why data providers should take up SPDX URIs, see a query that returns data distributed under CC0 (you should, really):

Deleted:
<
<
 
select ivoid from rr.resource
where rights_uri ILIKE 'https://spdx.org/licenses/CC0-1.0.html'

Relationships using altIdentifier are available from VizieR (Gilles?).

All of the previous items do not need any special software support.

For the ResourceName change, that is not the case. To make it useful, RegTAP will need an update, presumably adding alt_identifier columns to res_role and relationship, and res_details keys for facility and instrument. For the Heidelberg RegTAP server, this ought to happen during December 2025.

Implementations Validators

Basic validation is through any XML schema validator. If unsure, see the Makefile from the source repository for how to use stilts to validate your instance documents.

The RofR validator should be updated soon.



Comments from the IVOA Community during RFC/TCG review period: 2024-11-27 - 2025-01-07

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document



Comments from TCG member during the RFC/TCG Review Period: 2024-11-27 - 2025-01-07

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Changed:
<
<
>
>
  • BaptisteCecconi, 2024-11-27: The document uses "should" for specifying which vocabulary has to be used in the VOResource elements with controlled values: "The content of <subject> should be drawn from the Unified Astronomy Thesaurus". Same for content_level and content_type. Why don't we say "MUST"?
Added:
>
>
  • BaptisteCecconi, 2024-11-27: In the Appendix A, one can read the quoted sentence "use fragments into http://www.ivoa.net/rdf/uat/#", but that quote is found nowhere in the text. It is probably harmless, but this makes all reference to Semantics vocabularies implict in the VOResource instances as well as in the VOResource schema. For the reuse of VOResource outside the IVOA (and for the ease of building application on top of VOResource content), I would be expecting that the reference to the URI scheme (e.g., http://www.ivoa.net/rdf/uat/#) is available formally, either in the VOResource.
  • BaptisteCecconi, 2024-11-27: In section 3.2.2, the rightsURI can contain SPDX URIs. Is it really full URIs? as opposite from the previous comment case (IVOA-UAT, content_level, content_type), which are requiring NOT to use full URIs.
  • BaptisteCecconi, 2024-11-27: In section 2.2.5, the DOI, ORCID and bibcodes identifiers are listed. I propose to also include ROR identifiers (Research Organization Registry: https://ror.org), to include identifiers for organizations.
 

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Radio Astronomy Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee


TCG Vote : Vote_start_date - Vote_end_date

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.

Group Yes No Abstain Comments
TCG        
Apps        
DAL        
DM        
GWS        
Registry        
Semantics        
DCP        
Edu        
KDIG        
Ops        
Radio        
SSIG        
Theory        
TD        
StdProc        



<--

-->
Added:
>
>

Revision 32024-11-26 - RenaudSavalle

 
META TOPICPARENT name="IvoaResReg"

VOResource-1.2 Proposed Recommendation: Request for Comments

VOResource is an IVOA standard for describing astronomical resources (data collections, services, registries, tools...) within the Virtual Observatory. It provides an XML interchange format for use with registries, and lays the foundations upon which description schemes for concrete resources are built in various VOResource extensions.

Here is a brief summary of the changes from Recommendation 1.1:

  • You can now use DOIs (or other identifier schemes like orcid) wherever we have a ResourceName so far, which includes relationship, authors, and the like.

  • We now spell out what "using the UAT" for our subject keywords mean. If you publish resource records, this probably means that you will have to update them, as it is unlikely that they already have UAT keywords, let alone the with the right syntax.

  • If you machine-readably declare your licenses, you should now use SPDX URIs.

  • The bibliographic source can now be declared machine-readably with DOIs, too (before, there were only bibcodes).

Latest version of VOResource-1.2 can be found at:

Reference Interoperable Implementations

UAT keywords have been in use at GAVO and VizieR for a long time now; see also Sembarebro for a proof-of-concept-level interface using it.

To get an idea for why data providers should take up SPDX URIs, see a query that returns data distributed under CC0 (you should, really):

Added:
>
>
 
select ivoid from rr.resource
where rights_uri ILIKE 'https://spdx.org/licenses/CC0-1.0.html'

Relationships using altIdentifier are available from VizieR (Gilles?).

All of the previous items do not need any special software support.

For the ResourceName change, that is not the case. To make it useful, RegTAP will need an update, presumably adding alt_identifier columns to res_role and relationship, and res_details keys for facility and instrument. For the Heidelberg RegTAP server, this ought to happen during December 2025.

Implementations Validators

Basic validation is through any XML schema validator. If unsure, see the Makefile from the source repository for how to use stilts to validate your instance documents.

The RofR validator should be updated soon.



Changed:
<
<

Comments from the IVOA Community during RFC/TCG review period: 2024-11-15 - 2024-12-31

>
>

Comments from the IVOA Community during RFC/TCG review period: 2024-11-27 - 2025-01-07

 

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document



Changed:
<
<

Comments from TCG member during the RFC/TCG Review Period: 2024-11-15 - 2024-12-31

>
>

Comments from TCG member during the RFC/TCG Review Period: 2024-11-27 - 2025-01-07

  WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Radio Astronomy Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee


TCG Vote : Vote_start_date - Vote_end_date

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.

Group Yes No Abstain Comments
TCG        
Apps        
DAL        
DM        
GWS        
Registry        
Semantics        
DCP        
Edu        
KDIG        
Ops        
Radio        
SSIG        
Theory        
TD        
StdProc        



<--

-->
Deleted:
<
<

Revision 22024-11-14 - MarkusDemleitner

 
META TOPICPARENT name="IvoaResReg"

VOResource-1.2 Proposed Recommendation: Request for Comments

VOResource is an IVOA standard for describing astronomical resources (data collections, services, registries, tools...) within the Virtual Observatory. It provides an XML interchange format for use with registries, and lays the foundations upon which description schemes for concrete resources are built in various VOResource extensions.

Here is a brief summary of the changes from Recommendation 1.1:

Changed:
<
<
  • You can now use DOIs (or other identifier schemes like orcid)
>
>
  • You can now use DOIs (or other identifier schemes like orcid) wherever we have a ResourceName so far, which includes relationship, authors, and the like.
Deleted:
<
<
wherever we have a ResourceName so far, which includes relationship, authors, and the like.
 
Changed:
<
<
  • We now spell out what "using the UAT" for our subject keywords
>
>
  • We now spell out what "using the UAT" for our subject keywords mean. If you publish resource records, this probably means that you will have to update them, as it is unlikely that they already have UAT keywords, let alone the with the right syntax.
Deleted:
<
<
mean. If you publish resource records, this probably means that you will have to update them, as it is unlikely that they already have UAT keywords, let alone the with the right syntax.
 
Changed:
<
<
  • If you machine-readably declare your licenses, you should now use
>
>
  • If you machine-readably declare your licenses, you should now use SPDX URIs.
Deleted:
<
<
SPDX URIs.
 
Changed:
<
<
  • The bibliographic source can now be declared machine-readably with
>
>
  • The bibliographic source can now be declared machine-readably with DOIs, too (before, there were only bibcodes).
Deleted:
<
<
DOIs, too (before, there were only bibcodes).
  Latest version of VOResource-1.2 can be found at:

Reference Interoperable Implementations

Changed:
<
<
(Indicate here the links to at least two Reference Interoperable Implementations)
>
>
UAT keywords have been in use at GAVO and VizieR for a long time now; see also Sembarebro for a proof-of-concept-level interface using it.
 
Added:
>
>
To get an idea for why data providers should take up SPDX URIs, see a query that returns data distributed under CC0 (you should, really):
select ivoid from rr.resource
where rights_uri ILIKE 'https://spdx.org/licenses/CC0-1.0.html'
 
Added:
>
>
Relationships using altIdentifier are available from VizieR (Gilles?).

All of the previous items do not need any special software support.

For the ResourceName change, that is not the case. To make it useful, RegTAP will need an update, presumably adding alt_identifier columns to res_role and relationship, and res_details keys for facility and instrument. For the Heidelberg RegTAP server, this ought to happen during December 2025.

 

Implementations Validators

Changed:
<
<
(If any, indicate here the links to Implementations Validators)
>
>
Basic validation is through any XML schema validator. If unsure, see the Makefile from the source repository for how to use stilts to validate your instance documents.
Added:
>
>
The RofR validator should be updated soon.
 



Comments from the IVOA Community during RFC/TCG review period: 2024-11-15 - 2024-12-31

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document



Comments from TCG member during the RFC/TCG Review Period: 2024-11-15 - 2024-12-31

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Radio Astronomy Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee


TCG Vote : Vote_start_date - Vote_end_date

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.

Group Yes No Abstain Comments
TCG        
Apps        
DAL        
DM        
GWS        
Registry        
Semantics        
DCP        
Edu        
KDIG        
Ops        
Radio        
SSIG        
Theory        
TD        
StdProc        



<--

-->

Revision 12024-11-12 - RenaudSavalle

 
META TOPICPARENT name="IvoaResReg"

VOResource-1.2 Proposed Recommendation: Request for Comments

VOResource is an IVOA standard for describing astronomical resources (data collections, services, registries, tools...) within the Virtual Observatory. It provides an XML interchange format for use with registries, and lays the foundations upon which description schemes for concrete resources are built in various VOResource extensions.

Here is a brief summary of the changes from Recommendation 1.1:

  • You can now use DOIs (or other identifier schemes like orcid) wherever we have a ResourceName so far, which includes relationship, authors, and the like.

  • We now spell out what "using the UAT" for our subject keywords mean. If you publish resource records, this probably means that you will have to update them, as it is unlikely that they already have UAT keywords, let alone the with the right syntax.

  • If you machine-readably declare your licenses, you should now use SPDX URIs.

  • The bibliographic source can now be declared machine-readably with DOIs, too (before, there were only bibcodes).

Latest version of VOResource-1.2 can be found at:

Reference Interoperable Implementations

(Indicate here the links to at least two Reference Interoperable Implementations)

Implementations Validators

(If any, indicate here the links to Implementations Validators)



Comments from the IVOA Community during RFC/TCG review period: 2024-11-15 - 2024-12-31

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document



Comments from TCG member during the RFC/TCG Review Period: 2024-11-15 - 2024-12-31

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Radio Astronomy Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee


TCG Vote : Vote_start_date - Vote_end_date

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.

Group Yes No Abstain Comments
TCG        
Apps        
DAL        
DM        
GWS        
Registry        
Semantics        
DCP        
Edu        
KDIG        
Ops        
Radio        
SSIG        
Theory        
TD        
StdProc        



<--

-->
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback