Difference: VOResource12RFC (1 vs. 22)

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:

• 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):

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

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

That's still waiting for actual records, but that's only a minor technical matter: VizieR will push out records having these RSN.

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

• Sample comment by WikiName
  • Response (by WikiName)

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

• Pierre Le Sidaner, 2025-01-30: I've always found that VOResource didn't have the dedicated field to express the citation of the collection or service. The right way to declare DOIs, the ORCID, is really an important advance.

Data Access Layer Working Group

Excellent document. I also appreciate the addition of DOIs and ORCID, although this does not affect directly DAL protocols.

No blocking comment from the DAL Working Group. But some minor comments anyway (and few typos).

• Some typos:
• Sec. 2, p.8: typcially -> typically
• Sec. 2.2.1, p.10:
  • For all types and element names that are made up of multiple words, such as shortName, upper-case letters are used to demarcate the start
  • This is intended to allow simple markup
• Sec. 2.2.4, p.11: remove the trailing comma: 2008-02-22T12:22:34Z,
• Sec. 2.2.5, p.12: strongly urges the use of http URIs
• Sec. 3.1, p.19: Applications may use it to refer to this resource in a compact display.
  • Thanks indeed for catching these; most of them have been in there for more than a decade. Fixed in the PR (except for the comma thing; there needs to be a comma there for syntax reasons, but at least it's outside of the literal now). -- MarkusDemleitner - 2025-01-31

p.46: The DOI points toward the ADS page. And the link in the ADS page points to itself In any case, there is no way to read this document with such link (although the Endorsed Note can be read very easily in the IVOA Document page). It may be useful to fix this link....which is, of course, out of scope for this RFC. It just wanted to share this comment.

Harrison, P., Demleitner, M., Major, B. and Dowler, P. (2018), ‘XML Schema Versioning Policies Version 1.0’, IVOA Endorsed Note 29 May

doi:10.5479/ADS/bib/2018ivoa.spec.0529H, https://ui.adsabs.harvard.edu/ abs/2018ivoa.spec.0529H.

• • Oh, ouch. I'll talk to ADS about it. They shouldn't use the DOI as the link here, clearly. But it's nothing I can fix here -- MarkusDemleitner - 2025-01-31
  • I indeed expected you can not directly fix this. It is ADS content after all. -- GregoryMantelet - 2025-01-31

• Sec. 2.2.4, p.11: vr:UTCDateTime : it should be an xs:date or xs:dateTime. I am no XMLSchema expert, but the union in the VOResource XML schema defines it only as the union of xs:date and vr:UTCTimestamp. Is xs:dateTime missing in there?
  • Ummm, no, I don't think so; the intention is that you can skip giving a time when it would be silly to give it (e.g., a release date). We don't want the full horrors (timezones!) of xs:datetime in there if you do want to give a time, though. If you still think this is a problem, let's chat. -- MarkusDemleitner - 2025-01-31
  • I agree about the full horrors your mentioned. I just wanted to point out that the text being: "A date stamp that can be given to a precision of either a day (type xs:date) or seconds (type xs:dateTime).", I would expect to see the same in the XML Schema snippet just below. But only xs:date appears. It is just a bit confusing, but since it is there for years, I guess it is not really a problem. -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.23-24:

  The IVO-ID of a Creator can be provided in two ways: 1/ by using the attribute 'ivo-id' of vr:Creator, 2/ by using the 'ivo-id' of the mandatory element 'name' of vr:Creator. What's the difference between both? What happens if both are provided but different? Should we deprecate the attribute 'ivo-id' of vr:Creator and set the IVO-ID only in the element 'name'?

• Sec. 3.1.2, p.26-27: same comment for vr:Contact
  • Good catches again. This is bad in VOResource 1.1 already, and probably nobody noticed because nobody registers as a person (and I'm happy about that). Since this hasn't caused harm so far and I don't want to rush a resolution, can I ask you to file a bug agains VOResource? We should of course fix it, but I don't think we should delay 1.2 to fix something that's been broken in VOResource from day 1. -- MarkusDemleitner - 2025-01-31
  • I've just reported this bug in https://github.com/ivoa-std/VOResource/issues/15 -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.24-25:

  The Date's 'role' attribute is set by default to 'representative'. However, this term is now deprecative. Should we use this new minor release of VOResource to update it, from 'representative' to 'Collected'? If so, it should be updated in the text (p.25), in the XML snippet (p.24) and in the XML schema.

  • Uh. This one I'd consider more serious, and I think it should be fixed for version 1.2. I'll post to the Registry list about it. -- MarkusDemleitner - 2025-01-31

• Sec. 3.1.3-4, p.31:

  It is strange to see a note about 'validationLevel' so far from the first definition of 'validationLevel' (p.19) and right in the middle 'relationship'. I assume it is a LaTeX side effect and, after reading few paragraphs after, this note is actually part of sec. 3.1.4. For the reader, it would however be more comfortable and understandable to force this note to be close to the 'validationLevel' definition (p.19) or inside the sec. 3.1.4 and not at the end of sec. 3.1.3.

  • Well, as you guessed, admonitions are floats in ivoatex, and this note floated to the top of p. 31. Hm. Since it's deeply technical, I'm quite sure it should remain lexically within 3.1.4. So, I'd suggest that ivoatex ought to prefer here-positioning for these floats (which IMHO works well here). If you want, try https://github.com/ivoa-std/ivoatex/pull/149 (and perhaps even review it?). -- MarkusDemleitner - 2025-01-31
  • I've just tried this solution. It looks OK now with VOResource-1.2 document. -- GregoryMantelet - 2025-01-31

• Changes mentioned above are in https://github.com/ivoa-std/VOResource/pull/14 -- MarkusDemleitner - 2025-01-31

Data Model Working Group

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
  • Good point. Updated to 4.6, which is from late 2024. -- MarkusDemleitner - 2025-01-20
• MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)
  • See below -- MarkusDemleitner - 2025-01-20

Grid & Web Services Working Group

Changes on 1.2 provide value to the standard and have been added clearly— nothing impacting GWS WG activities.

One minor comment: As the document does not have an acronyms section, it is recommended to expand the acronyms in the text whenever they are introduced the first time, like in the case of UAT and SPDX.

• I am now expanding these two acronyms, although I freely admit I had to research SPDX's expansion and had to resort to the Wikipedia for that; I think in this day and age acronyms are often a lot better known than their expansions (I wonder how many people would know what you're talking about when you ask them how much random access memory their telephones have...). That's https://github.com/ivoa-std/VOResource/pull/17 -- MarkusDemleitner - 2025-02-04

Are there plans to allow similar identifiers for other external machine-readable identifiers like, e.g. RORs for organisations?

• ROR is in post-RFC (see the link to the current builds above). I have briefly considered putting in some way to admit more schemes without having to touch the spec, but figured that we'll fist have to gather experience with the schemes we have (which aren't used terribly much up to now). -- MarkusDemleitner - 2025-02-04

The GWS approve the document -- JesusSalgado - 2025-01-31

Registry Working Group

We've been part of the document evolution and fully support it

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"?
  • This would immediately make a good deal of the resource records out there invalid, which is probably more than we intend to do, and one might argue we're not allowed to do such a thing in a minor update at all. My take on this is to convince data publishers one by one (for most of them it's probably not horribly hard to migrate) and make this a MUST when we don't break any (maintained) records any more. -- MarkusDemleitner - 2025-01-20
• 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.
  • We probably could do such a thing using RDFa on VOResource. Note that that would only do something for what we push out through OAI-PMH, while most people interact with the Registry using RegTAP, and there things can't be fixed as easily, as the prefix mapping would somehow have to cover VOTable data content, and XML processors often won't even see them. If we expected the outside world to start looking at VOResource, I'd say the RDFa way might be a good investiment of our creativity. As long as nobody external actually does look at VOResource, I'd consider it a bad deal in terms of bang for the (effort) buck. -- MarkusDemleitner - 2025-01-20
• 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.
  • It would be nice if we could be consistent here, but regrettably practicies change over time and will keep changing. Practices in VOResources will to some degree reflect the zeitgeist of when they were added. For RightsURI, we have to deal with legacy URIs and possibly all kinds of other things, and we have to way but either an https URL or a URI scheme to tell clients what it is. I don't think SPDX has asked for a URI scheme, and so it'll have to be the https URI, I'm afraid. Don't like it much myself, as you may guess. -- MarkusDemleitner - 2025-01-20"
• 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.
  • Right. I've put something in, and again, since it seems they're not interested in a URI scheme of their own, I'm asking for full URIs. -- MarkusDemleitner - 2025-01-19

Changes are in VOResource PR #13.

Data Curation & Preservation Interest Group

• Gilles Landais, 2024-12-20: congratulate this version that allows DOI, SPDX Licences, UAT
• Gilles Landais, 2024-12-20: as semantic, we propose also to include the RoR for organization
  • See above -- MarkusDemleitner - 2025-01-20
• 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

As in other reviews, I focused on the cchange log.

There is a bit of a problem with the UAT reference: "The content of subject SHOULD be the fragment identifier of the URI of a concept in the IVOA UAT (http://www.ivoa.net/rdf/uat/), that is, a string like “virtual-observatories”. Severla things to note:

• Not sure what is meant by "fragment". If the intent is to mean "part of a URL usually preceded by the '#' character", then I don't know that the UAT uses them. UAT terms are identified by value codes. The string(s) assiociated with a value code are NOT guaranteed to be permanent.
• The sample string given, "virtual-observatories" does not resolve to anything in the UAT.
• The string "virtual observatories" entered into the search function at the UAT returns this URI: http://astrothesaurus.org/uat/1774 with the associated name string "Virtual Observatories".
• Consequently, if you want resolvability forever, the answer is "1774". If you want resolvability for now that a human might understand, you want "Virtual Observatories".
• The Change Log entry seems to imply the number should be used, but the number is not even mentioned in the body of the document.
• As far as I can determine, there is no URL involving "virtual0observatories" in any form that will work with the UAT URL root.
  • The annotation of the vr:Content/subject element (PDF p. 28) should make this clear: "fragment identifier of the URI of a concept in the IVOA UAT (http://www.ivoa.net/rdf/uat/)" (emphasis mine). The IVOA is using an IVOA-ised version of the UAT for reasons discussed in the pertinent endorsed note, Demleitner, M. and Frey, K. (2022), https://ui.adsabs.harvard.edu/abs/2012ivoa.spec.0827D -- MarkusDemleitner - 2025-02-11

• • This refers to the format attribute of the source element, which so far only had "bibcode" as a defined value. I'd argue that is reasonably clear in the running text. If you would like the changelog to be more explicit, I'm happy to fix the language, but I'd then be grateful for suggestions what to write -- MarkusDemleitner - 2025-02-11

- AnneRaugh 2025-02-05.

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.

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

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:

• 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):

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

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

That's still waiting for actual records, but that's only a minor technical matter: VizieR will push out records having these RSN.

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

• Sample comment by WikiName
  • Response (by WikiName)

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

• Pierre Le Sidaner, 2025-01-30: I've always found that VOResource didn't have the dedicated field to express the citation of the collection or service. The right way to declare DOIs, the ORCID, is really an important advance.

Data Access Layer Working Group

Excellent document. I also appreciate the addition of DOIs and ORCID, although this does not affect directly DAL protocols.

No blocking comment from the DAL Working Group. But some minor comments anyway (and few typos).

• Some typos:
• Sec. 2, p.8: typcially -> typically
• Sec. 2.2.1, p.10:
  • For all types and element names that are made up of multiple words, such as shortName, upper-case letters are used to demarcate the start
  • This is intended to allow simple markup
• Sec. 2.2.4, p.11: remove the trailing comma: 2008-02-22T12:22:34Z,
• Sec. 2.2.5, p.12: strongly urges the use of http URIs
• Sec. 3.1, p.19: Applications may use it to refer to this resource in a compact display.
  • Thanks indeed for catching these; most of them have been in there for more than a decade. Fixed in the PR (except for the comma thing; there needs to be a comma there for syntax reasons, but at least it's outside of the literal now). -- MarkusDemleitner - 2025-01-31

p.46: The DOI points toward the ADS page. And the link in the ADS page points to itself In any case, there is no way to read this document with such link (although the Endorsed Note can be read very easily in the IVOA Document page). It may be useful to fix this link....which is, of course, out of scope for this RFC. It just wanted to share this comment.

Harrison, P., Demleitner, M., Major, B. and Dowler, P. (2018), ‘XML Schema Versioning Policies Version 1.0’, IVOA Endorsed Note 29 May

doi:10.5479/ADS/bib/2018ivoa.spec.0529H, https://ui.adsabs.harvard.edu/ abs/2018ivoa.spec.0529H.

• • Oh, ouch. I'll talk to ADS about it. They shouldn't use the DOI as the link here, clearly. But it's nothing I can fix here -- MarkusDemleitner - 2025-01-31
  • I indeed expected you can not directly fix this. It is ADS content after all. -- GregoryMantelet - 2025-01-31

• Sec. 2.2.4, p.11: vr:UTCDateTime : it should be an xs:date or xs:dateTime. I am no XMLSchema expert, but the union in the VOResource XML schema defines it only as the union of xs:date and vr:UTCTimestamp. Is xs:dateTime missing in there?
  • Ummm, no, I don't think so; the intention is that you can skip giving a time when it would be silly to give it (e.g., a release date). We don't want the full horrors (timezones!) of xs:datetime in there if you do want to give a time, though. If you still think this is a problem, let's chat. -- MarkusDemleitner - 2025-01-31
  • I agree about the full horrors your mentioned. I just wanted to point out that the text being: "A date stamp that can be given to a precision of either a day (type xs:date) or seconds (type xs:dateTime).", I would expect to see the same in the XML Schema snippet just below. But only xs:date appears. It is just a bit confusing, but since it is there for years, I guess it is not really a problem. -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.23-24:

  The IVO-ID of a Creator can be provided in two ways: 1/ by using the attribute 'ivo-id' of vr:Creator, 2/ by using the 'ivo-id' of the mandatory element 'name' of vr:Creator. What's the difference between both? What happens if both are provided but different? Should we deprecate the attribute 'ivo-id' of vr:Creator and set the IVO-ID only in the element 'name'?

• Sec. 3.1.2, p.26-27: same comment for vr:Contact
  • Good catches again. This is bad in VOResource 1.1 already, and probably nobody noticed because nobody registers as a person (and I'm happy about that). Since this hasn't caused harm so far and I don't want to rush a resolution, can I ask you to file a bug agains VOResource? We should of course fix it, but I don't think we should delay 1.2 to fix something that's been broken in VOResource from day 1. -- MarkusDemleitner - 2025-01-31
  • I've just reported this bug in https://github.com/ivoa-std/VOResource/issues/15 -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.24-25:

  The Date's 'role' attribute is set by default to 'representative'. However, this term is now deprecative. Should we use this new minor release of VOResource to update it, from 'representative' to 'Collected'? If so, it should be updated in the text (p.25), in the XML snippet (p.24) and in the XML schema.

  • Uh. This one I'd consider more serious, and I think it should be fixed for version 1.2. I'll post to the Registry list about it. -- MarkusDemleitner - 2025-01-31

• Sec. 3.1.3-4, p.31:

  It is strange to see a note about 'validationLevel' so far from the first definition of 'validationLevel' (p.19) and right in the middle 'relationship'. I assume it is a LaTeX side effect and, after reading few paragraphs after, this note is actually part of sec. 3.1.4. For the reader, it would however be more comfortable and understandable to force this note to be close to the 'validationLevel' definition (p.19) or inside the sec. 3.1.4 and not at the end of sec. 3.1.3.

  • Well, as you guessed, admonitions are floats in ivoatex, and this note floated to the top of p. 31. Hm. Since it's deeply technical, I'm quite sure it should remain lexically within 3.1.4. So, I'd suggest that ivoatex ought to prefer here-positioning for these floats (which IMHO works well here). If you want, try https://github.com/ivoa-std/ivoatex/pull/149 (and perhaps even review it?). -- MarkusDemleitner - 2025-01-31
  • I've just tried this solution. It looks OK now with VOResource-1.2 document. -- GregoryMantelet - 2025-01-31

• Changes mentioned above are in https://github.com/ivoa-std/VOResource/pull/14 -- MarkusDemleitner - 2025-01-31

Data Model Working Group

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
  • Good point. Updated to 4.6, which is from late 2024. -- MarkusDemleitner - 2025-01-20
• MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)
  • See below -- MarkusDemleitner - 2025-01-20

Grid & Web Services Working Group

Changes on 1.2 provide value to the standard and have been added clearly— nothing impacting GWS WG activities.

One minor comment: As the document does not have an acronyms section, it is recommended to expand the acronyms in the text whenever they are introduced the first time, like in the case of UAT and SPDX.

• I am now expanding these two acronyms, although I freely admit I had to research SPDX's expansion and had to resort to the Wikipedia for that; I think in this day and age acronyms are often a lot better known than their expansions (I wonder how many people would know what you're talking about when you ask them how much random access memory their telephones have...). That's https://github.com/ivoa-std/VOResource/pull/17 -- MarkusDemleitner - 2025-02-04

Are there plans to allow similar identifiers for other external machine-readable identifiers like, e.g. RORs for organisations?

• ROR is in post-RFC (see the link to the current builds above). I have briefly considered putting in some way to admit more schemes without having to touch the spec, but figured that we'll fist have to gather experience with the schemes we have (which aren't used terribly much up to now). -- MarkusDemleitner - 2025-02-04

The GWS approve the document -- JesusSalgado - 2025-01-31

Registry Working Group

We've been part of the document evolution and fully support it

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"?
  • This would immediately make a good deal of the resource records out there invalid, which is probably more than we intend to do, and one might argue we're not allowed to do such a thing in a minor update at all. My take on this is to convince data publishers one by one (for most of them it's probably not horribly hard to migrate) and make this a MUST when we don't break any (maintained) records any more. -- MarkusDemleitner - 2025-01-20
• 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.
  • We probably could do such a thing using RDFa on VOResource. Note that that would only do something for what we push out through OAI-PMH, while most people interact with the Registry using RegTAP, and there things can't be fixed as easily, as the prefix mapping would somehow have to cover VOTable data content, and XML processors often won't even see them. If we expected the outside world to start looking at VOResource, I'd say the RDFa way might be a good investiment of our creativity. As long as nobody external actually does look at VOResource, I'd consider it a bad deal in terms of bang for the (effort) buck. -- MarkusDemleitner - 2025-01-20
• 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.
  • It would be nice if we could be consistent here, but regrettably practicies change over time and will keep changing. Practices in VOResources will to some degree reflect the zeitgeist of when they were added. For RightsURI, we have to deal with legacy URIs and possibly all kinds of other things, and we have to way but either an https URL or a URI scheme to tell clients what it is. I don't think SPDX has asked for a URI scheme, and so it'll have to be the https URI, I'm afraid. Don't like it much myself, as you may guess. -- MarkusDemleitner - 2025-01-20"
• 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.
  • Right. I've put something in, and again, since it seems they're not interested in a URI scheme of their own, I'm asking for full URIs. -- MarkusDemleitner - 2025-01-19

Changes are in VOResource PR #13.

Data Curation & Preservation Interest Group

• Gilles Landais, 2024-12-20: congratulate this version that allows DOI, SPDX Licences, UAT
• Gilles Landais, 2024-12-20: as semantic, we propose also to include the RoR for organization
  • See above -- MarkusDemleitner - 2025-01-20
• 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

As in other reviews, I focused on the cchange log.

There is a bit of a problem with the UAT reference: "The content of subject SHOULD be the fragment identifier of the URI of a concept in the IVOA UAT (http://www.ivoa.net/rdf/uat/), that is, a string like “virtual-observatories”. Severla things to note:

• Not sure what is meant by "fragment". If the intent is to mean "part of a URL usually preceded by the '#' character", then I don't know that the UAT uses them. UAT terms are identified by value codes. The string(s) assiociated with a value code are NOT guaranteed to be permanent.
• The sample string given, "virtual-observatories" does not resolve to anything in the UAT.
• The string "virtual observatories" entered into the search function at the UAT returns this URI: http://astrothesaurus.org/uat/1774 with the associated name string "Virtual Observatories".
• Consequently, if you want resolvability forever, the answer is "1774". If you want resolvability for now that a human might understand, you want "Virtual Observatories".
• The Change Log entry seems to imply the number should be used, but the number is not even mentioned in the body of the document.
• As far as I can determine, there is no URL involving "virtual0observatories" in any form that will work with the UAT URL root.

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.

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

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:

• 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):

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

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

That's still waiting for actual records, but that's only a minor technical matter: VizieR will push out records having these RSN.

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

• Sample comment by WikiName
  • Response (by WikiName)

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

• Pierre Le Sidaner, 2025-01-30: I've always found that VOResource didn't have the dedicated field to express the citation of the collection or service. The right way to declare DOIs, the ORCID, is really an important advance.

Data Access Layer Working Group

Excellent document. I also appreciate the addition of DOIs and ORCID, although this does not affect directly DAL protocols.

No blocking comment from the DAL Working Group. But some minor comments anyway (and few typos).

• Some typos:
• Sec. 2, p.8: typcially -> typically
• Sec. 2.2.1, p.10:
  • For all types and element names that are made up of multiple words, such as shortName, upper-case letters are used to demarcate the start
  • This is intended to allow simple markup
• Sec. 2.2.4, p.11: remove the trailing comma: 2008-02-22T12:22:34Z,
• Sec. 2.2.5, p.12: strongly urges the use of http URIs
• Sec. 3.1, p.19: Applications may use it to refer to this resource in a compact display.
  • Thanks indeed for catching these; most of them have been in there for more than a decade. Fixed in the PR (except for the comma thing; there needs to be a comma there for syntax reasons, but at least it's outside of the literal now). -- MarkusDemleitner - 2025-01-31

p.46: The DOI points toward the ADS page. And the link in the ADS page points to itself In any case, there is no way to read this document with such link (although the Endorsed Note can be read very easily in the IVOA Document page). It may be useful to fix this link....which is, of course, out of scope for this RFC. It just wanted to share this comment.

Harrison, P., Demleitner, M., Major, B. and Dowler, P. (2018), ‘XML Schema Versioning Policies Version 1.0’, IVOA Endorsed Note 29 May

doi:10.5479/ADS/bib/2018ivoa.spec.0529H, https://ui.adsabs.harvard.edu/ abs/2018ivoa.spec.0529H.

• • Oh, ouch. I'll talk to ADS about it. They shouldn't use the DOI as the link here, clearly. But it's nothing I can fix here -- MarkusDemleitner - 2025-01-31
  • I indeed expected you can not directly fix this. It is ADS content after all. -- GregoryMantelet - 2025-01-31

• Sec. 2.2.4, p.11: vr:UTCDateTime : it should be an xs:date or xs:dateTime. I am no XMLSchema expert, but the union in the VOResource XML schema defines it only as the union of xs:date and vr:UTCTimestamp. Is xs:dateTime missing in there?
  • Ummm, no, I don't think so; the intention is that you can skip giving a time when it would be silly to give it (e.g., a release date). We don't want the full horrors (timezones!) of xs:datetime in there if you do want to give a time, though. If you still think this is a problem, let's chat. -- MarkusDemleitner - 2025-01-31
  • I agree about the full horrors your mentioned. I just wanted to point out that the text being: "A date stamp that can be given to a precision of either a day (type xs:date) or seconds (type xs:dateTime).", I would expect to see the same in the XML Schema snippet just below. But only xs:date appears. It is just a bit confusing, but since it is there for years, I guess it is not really a problem. -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.23-24:

  The IVO-ID of a Creator can be provided in two ways: 1/ by using the attribute 'ivo-id' of vr:Creator, 2/ by using the 'ivo-id' of the mandatory element 'name' of vr:Creator. What's the difference between both? What happens if both are provided but different? Should we deprecate the attribute 'ivo-id' of vr:Creator and set the IVO-ID only in the element 'name'?

• Sec. 3.1.2, p.26-27: same comment for vr:Contact
  • Good catches again. This is bad in VOResource 1.1 already, and probably nobody noticed because nobody registers as a person (and I'm happy about that). Since this hasn't caused harm so far and I don't want to rush a resolution, can I ask you to file a bug agains VOResource? We should of course fix it, but I don't think we should delay 1.2 to fix something that's been broken in VOResource from day 1. -- MarkusDemleitner - 2025-01-31
  • I've just reported this bug in https://github.com/ivoa-std/VOResource/issues/15 -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.24-25:

  The Date's 'role' attribute is set by default to 'representative'. However, this term is now deprecative. Should we use this new minor release of VOResource to update it, from 'representative' to 'Collected'? If so, it should be updated in the text (p.25), in the XML snippet (p.24) and in the XML schema.

  • Uh. This one I'd consider more serious, and I think it should be fixed for version 1.2. I'll post to the Registry list about it. -- MarkusDemleitner - 2025-01-31

• Sec. 3.1.3-4, p.31:

  It is strange to see a note about 'validationLevel' so far from the first definition of 'validationLevel' (p.19) and right in the middle 'relationship'. I assume it is a LaTeX side effect and, after reading few paragraphs after, this note is actually part of sec. 3.1.4. For the reader, it would however be more comfortable and understandable to force this note to be close to the 'validationLevel' definition (p.19) or inside the sec. 3.1.4 and not at the end of sec. 3.1.3.

  • Well, as you guessed, admonitions are floats in ivoatex, and this note floated to the top of p. 31. Hm. Since it's deeply technical, I'm quite sure it should remain lexically within 3.1.4. So, I'd suggest that ivoatex ought to prefer here-positioning for these floats (which IMHO works well here). If you want, try https://github.com/ivoa-std/ivoatex/pull/149 (and perhaps even review it?). -- MarkusDemleitner - 2025-01-31
  • I've just tried this solution. It looks OK now with VOResource-1.2 document. -- GregoryMantelet - 2025-01-31

• Changes mentioned above are in https://github.com/ivoa-std/VOResource/pull/14 -- MarkusDemleitner - 2025-01-31

Data Model Working Group

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
  • Good point. Updated to 4.6, which is from late 2024. -- MarkusDemleitner - 2025-01-20
• MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)
  • See below -- MarkusDemleitner - 2025-01-20

Grid & Web Services Working Group

Changes on 1.2 provide value to the standard and have been added clearly— nothing impacting GWS WG activities.

One minor comment: As the document does not have an acronyms section, it is recommended to expand the acronyms in the text whenever they are introduced the first time, like in the case of UAT and SPDX.

• I am now expanding these two acronyms, although I freely admit I had to research SPDX's expansion and had to resort to the Wikipedia for that; I think in this day and age acronyms are often a lot better known than their expansions (I wonder how many people would know what you're talking about when you ask them how much random access memory their telephones have...). That's https://github.com/ivoa-std/VOResource/pull/17 -- MarkusDemleitner - 2025-02-04

Are there plans to allow similar identifiers for other external machine-readable identifiers like, e.g. RORs for organisations?

• ROR is in post-RFC (see the link to the current builds above). I have briefly considered putting in some way to admit more schemes without having to touch the spec, but figured that we'll fist have to gather experience with the schemes we have (which aren't used terribly much up to now). -- MarkusDemleitner - 2025-02-04

The GWS approve the document -- JesusSalgado - 2025-01-31

Registry Working Group

We've been part of the document evolution and fully support it

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"?
  • This would immediately make a good deal of the resource records out there invalid, which is probably more than we intend to do, and one might argue we're not allowed to do such a thing in a minor update at all. My take on this is to convince data publishers one by one (for most of them it's probably not horribly hard to migrate) and make this a MUST when we don't break any (maintained) records any more. -- MarkusDemleitner - 2025-01-20
• 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.
  • We probably could do such a thing using RDFa on VOResource. Note that that would only do something for what we push out through OAI-PMH, while most people interact with the Registry using RegTAP, and there things can't be fixed as easily, as the prefix mapping would somehow have to cover VOTable data content, and XML processors often won't even see them. If we expected the outside world to start looking at VOResource, I'd say the RDFa way might be a good investiment of our creativity. As long as nobody external actually does look at VOResource, I'd consider it a bad deal in terms of bang for the (effort) buck. -- MarkusDemleitner - 2025-01-20
• 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.
  • It would be nice if we could be consistent here, but regrettably practicies change over time and will keep changing. Practices in VOResources will to some degree reflect the zeitgeist of when they were added. For RightsURI, we have to deal with legacy URIs and possibly all kinds of other things, and we have to way but either an https URL or a URI scheme to tell clients what it is. I don't think SPDX has asked for a URI scheme, and so it'll have to be the https URI, I'm afraid. Don't like it much myself, as you may guess. -- MarkusDemleitner - 2025-01-20"
• 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.
  • Right. I've put something in, and again, since it seems they're not interested in a URI scheme of their own, I'm asking for full URIs. -- MarkusDemleitner - 2025-01-19

Changes are in VOResource PR #13.

Data Curation & Preservation Interest Group

• Gilles Landais, 2024-12-20: congratulate this version that allows DOI, SPDX Licences, UAT
• Gilles Landais, 2024-12-20: as semantic, we propose also to include the RoR for organization
  • See above -- MarkusDemleitner - 2025-01-20
• 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.

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

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:

• 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):

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

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

That's still waiting for actual records, but that's only a minor technical matter: VizieR will push out records having these RSN.

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

• Sample comment by WikiName
  • Response (by WikiName)

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

• Pierre Le Sidaner, 2025-01-30: I've always found that VOResource didn't have the dedicated field to express the citation of the collection or service. The right way to declare DOIs, the ORCID, is really an important advance.

Data Access Layer Working Group

Excellent document. I also appreciate the addition of DOIs and ORCID, although this does not affect directly DAL protocols.

No blocking comment from the DAL Working Group. But some minor comments anyway (and few typos).

• Some typos:
• Sec. 2, p.8: typcially -> typically
• Sec. 2.2.1, p.10:
  • For all types and element names that are made up of multiple words, such as shortName, upper-case letters are used to demarcate the start
  • This is intended to allow simple markup
• Sec. 2.2.4, p.11: remove the trailing comma: 2008-02-22T12:22:34Z,
• Sec. 2.2.5, p.12: strongly urges the use of http URIs
• Sec. 3.1, p.19: Applications may use it to refer to this resource in a compact display.
  • Thanks indeed for catching these; most of them have been in there for more than a decade. Fixed in the PR (except for the comma thing; there needs to be a comma there for syntax reasons, but at least it's outside of the literal now). -- MarkusDemleitner - 2025-01-31

p.46: The DOI points toward the ADS page. And the link in the ADS page points to itself In any case, there is no way to read this document with such link (although the Endorsed Note can be read very easily in the IVOA Document page). It may be useful to fix this link....which is, of course, out of scope for this RFC. It just wanted to share this comment.

Harrison, P., Demleitner, M., Major, B. and Dowler, P. (2018), ‘XML Schema Versioning Policies Version 1.0’, IVOA Endorsed Note 29 May

doi:10.5479/ADS/bib/2018ivoa.spec.0529H, https://ui.adsabs.harvard.edu/ abs/2018ivoa.spec.0529H.

• • Oh, ouch. I'll talk to ADS about it. They shouldn't use the DOI as the link here, clearly. But it's nothing I can fix here -- MarkusDemleitner - 2025-01-31
  • I indeed expected you can not directly fix this. It is ADS content after all. -- GregoryMantelet - 2025-01-31

• Sec. 2.2.4, p.11: vr:UTCDateTime : it should be an xs:date or xs:dateTime. I am no XMLSchema expert, but the union in the VOResource XML schema defines it only as the union of xs:date and vr:UTCTimestamp. Is xs:dateTime missing in there?
  • Ummm, no, I don't think so; the intention is that you can skip giving a time when it would be silly to give it (e.g., a release date). We don't want the full horrors (timezones!) of xs:datetime in there if you do want to give a time, though. If you still think this is a problem, let's chat. -- MarkusDemleitner - 2025-01-31
  • I agree about the full horrors your mentioned. I just wanted to point out that the text being: "A date stamp that can be given to a precision of either a day (type xs:date) or seconds (type xs:dateTime).", I would expect to see the same in the XML Schema snippet just below. But only xs:date appears. It is just a bit confusing, but since it is there for years, I guess it is not really a problem. -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.23-24:

  The IVO-ID of a Creator can be provided in two ways: 1/ by using the attribute 'ivo-id' of vr:Creator, 2/ by using the 'ivo-id' of the mandatory element 'name' of vr:Creator. What's the difference between both? What happens if both are provided but different? Should we deprecate the attribute 'ivo-id' of vr:Creator and set the IVO-ID only in the element 'name'?

• Sec. 3.1.2, p.26-27: same comment for vr:Contact
  • Good catches again. This is bad in VOResource 1.1 already, and probably nobody noticed because nobody registers as a person (and I'm happy about that). Since this hasn't caused harm so far and I don't want to rush a resolution, can I ask you to file a bug agains VOResource? We should of course fix it, but I don't think we should delay 1.2 to fix something that's been broken in VOResource from day 1. -- MarkusDemleitner - 2025-01-31
  • I've just reported this bug in https://github.com/ivoa-std/VOResource/issues/15 -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.24-25:

  The Date's 'role' attribute is set by default to 'representative'. However, this term is now deprecative. Should we use this new minor release of VOResource to update it, from 'representative' to 'Collected'? If so, it should be updated in the text (p.25), in the XML snippet (p.24) and in the XML schema.

  • Uh. This one I'd consider more serious, and I think it should be fixed for version 1.2. I'll post to the Registry list about it. -- MarkusDemleitner - 2025-01-31

• Sec. 3.1.3-4, p.31:

  It is strange to see a note about 'validationLevel' so far from the first definition of 'validationLevel' (p.19) and right in the middle 'relationship'. I assume it is a LaTeX side effect and, after reading few paragraphs after, this note is actually part of sec. 3.1.4. For the reader, it would however be more comfortable and understandable to force this note to be close to the 'validationLevel' definition (p.19) or inside the sec. 3.1.4 and not at the end of sec. 3.1.3.

  • Well, as you guessed, admonitions are floats in ivoatex, and this note floated to the top of p. 31. Hm. Since it's deeply technical, I'm quite sure it should remain lexically within 3.1.4. So, I'd suggest that ivoatex ought to prefer here-positioning for these floats (which IMHO works well here). If you want, try https://github.com/ivoa-std/ivoatex/pull/149 (and perhaps even review it?). -- MarkusDemleitner - 2025-01-31
  • I've just tried this solution. It looks OK now with VOResource-1.2 document. -- GregoryMantelet - 2025-01-31

• Changes mentioned above are in https://github.com/ivoa-std/VOResource/pull/14 -- MarkusDemleitner - 2025-01-31

Data Model Working Group

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
  • Good point. Updated to 4.6, which is from late 2024. -- MarkusDemleitner - 2025-01-20
• MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)
  • See below -- MarkusDemleitner - 2025-01-20

Grid & Web Services Working Group

Changes on 1.2 provide value to the standard and have been added clearly— nothing impacting GWS WG activities.

One minor comment: As the document does not have an acronyms section, it is recommended to expand the acronyms in the text whenever they are introduced the first time, like in the case of UAT and SPDX.

• I am now expanding these two acronyms, although I freely admit I had to research SPDX's expansion and had to resort to the Wikipedia for that; I think in this day and age acronyms are often a lot better known than their expansions (I wonder how many people would know what you're talking about when you ask them how much random access memory their telephones have...). That's https://github.com/ivoa-std/VOResource/pull/17 -- MarkusDemleitner - 2025-02-04

Are there plans to allow similar identifiers for other external machine-readable identifiers like, e.g. RORs for organisations?

• ROR is in post-RFC (see the link to the current builds above). I have briefly considered putting in some way to admit more schemes without having to touch the spec, but figured that we'll fist have to gather experience with the schemes we have (which aren't used terribly much up to now). -- MarkusDemleitner - 2025-02-04

The GWS approve the document -- JesusSalgado - 2025-01-31

Registry Working Group

We've been part of the document evolution and fully support it

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"?
  • This would immediately make a good deal of the resource records out there invalid, which is probably more than we intend to do, and one might argue we're not allowed to do such a thing in a minor update at all. My take on this is to convince data publishers one by one (for most of them it's probably not horribly hard to migrate) and make this a MUST when we don't break any (maintained) records any more. -- MarkusDemleitner - 2025-01-20
• 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.
  • We probably could do such a thing using RDFa on VOResource. Note that that would only do something for what we push out through OAI-PMH, while most people interact with the Registry using RegTAP, and there things can't be fixed as easily, as the prefix mapping would somehow have to cover VOTable data content, and XML processors often won't even see them. If we expected the outside world to start looking at VOResource, I'd say the RDFa way might be a good investiment of our creativity. As long as nobody external actually does look at VOResource, I'd consider it a bad deal in terms of bang for the (effort) buck. -- MarkusDemleitner - 2025-01-20
• 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.
  • It would be nice if we could be consistent here, but regrettably practicies change over time and will keep changing. Practices in VOResources will to some degree reflect the zeitgeist of when they were added. For RightsURI, we have to deal with legacy URIs and possibly all kinds of other things, and we have to way but either an https URL or a URI scheme to tell clients what it is. I don't think SPDX has asked for a URI scheme, and so it'll have to be the https URI, I'm afraid. Don't like it much myself, as you may guess. -- MarkusDemleitner - 2025-01-20"
• 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.
  • Right. I've put something in, and again, since it seems they're not interested in a URI scheme of their own, I'm asking for full URIs. -- MarkusDemleitner - 2025-01-19

Changes are in VOResource PR #13.

Data Curation & Preservation Interest Group

• Gilles Landais, 2024-12-20: congratulate this version that allows DOI, SPDX Licences, UAT
• Gilles Landais, 2024-12-20: as semantic, we propose also to include the RoR for organization
  • See above -- MarkusDemleitner - 2025-01-20
• 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

• The first change note refers to a "contributor element". The only reference in the document to a "contributor element" is in section 3.2.1, which is actually describing the <Author> element. There is no reference to a <contributor> or content format of such an element anywhere in this document.

• Section 3.2.1 says, "We propose to use here the list of contributorType from the Datacite Metadata Schema v4.3 (DataCite Metadata Working Group, 2019)." The wording here is odd - is this a requirement or not? On top of that, the DataCite contributor list is regularly expanded and the current version 4.6 list is significantly different rom the version 4.3 list. It is not easy to find the historical 4.3 list. Tying this to a volatile source may not be the best solution, but it's not clear to my why, if this is not a requirement, the DataCite list would be mentioned at all. And given that there appears to be no real <contributor> element, it's not clear why you need a list of contributor roles.

• "STC-1.33" is IVOA jargon that only appears in the change notes and is undefined.
• The change note says that TimeInterval contains StartTime and StopTime, but the text says it contains ISOTimeStart and ISOTimeStop. Which is it?

• I do not understand what the last change note, "Each individual positional value are now associated with their own UCD and Unit" is saying. I have no context to search for to check.

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.

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

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:

• 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):

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

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

That's still waiting for actual records, but that's only a minor technical matter: VizieR will push out records having these RSN.

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

• Sample comment by WikiName
  • Response (by WikiName)

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

• Pierre Le Sidaner, 2025-01-30: I've always found that VOResource didn't have the dedicated field to express the citation of the collection or service. The right way to declare DOIs, the ORCID, is really an important advance.

Data Access Layer Working Group

Excellent document. I also appreciate the addition of DOIs and ORCID, although this does not affect directly DAL protocols.

No blocking comment from the DAL Working Group. But some minor comments anyway (and few typos).

• Some typos:
• Sec. 2, p.8: typcially -> typically
• Sec. 2.2.1, p.10:
  • For all types and element names that are made up of multiple words, such as shortName, upper-case letters are used to demarcate the start
  • This is intended to allow simple markup
• Sec. 2.2.4, p.11: remove the trailing comma: 2008-02-22T12:22:34Z,
• Sec. 2.2.5, p.12: strongly urges the use of http URIs
• Sec. 3.1, p.19: Applications may use it to refer to this resource in a compact display.
  • Thanks indeed for catching these; most of them have been in there for more than a decade. Fixed in the PR (except for the comma thing; there needs to be a comma there for syntax reasons, but at least it's outside of the literal now). -- MarkusDemleitner - 2025-01-31

p.46: The DOI points toward the ADS page. And the link in the ADS page points to itself In any case, there is no way to read this document with such link (although the Endorsed Note can be read very easily in the IVOA Document page). It may be useful to fix this link....which is, of course, out of scope for this RFC. It just wanted to share this comment.

Harrison, P., Demleitner, M., Major, B. and Dowler, P. (2018), ‘XML Schema Versioning Policies Version 1.0’, IVOA Endorsed Note 29 May

doi:10.5479/ADS/bib/2018ivoa.spec.0529H, https://ui.adsabs.harvard.edu/ abs/2018ivoa.spec.0529H.

• • Oh, ouch. I'll talk to ADS about it. They shouldn't use the DOI as the link here, clearly. But it's nothing I can fix here -- MarkusDemleitner - 2025-01-31
  • I indeed expected you can not directly fix this. It is ADS content after all. -- GregoryMantelet - 2025-01-31

• Sec. 2.2.4, p.11: vr:UTCDateTime : it should be an xs:date or xs:dateTime. I am no XMLSchema expert, but the union in the VOResource XML schema defines it only as the union of xs:date and vr:UTCTimestamp. Is xs:dateTime missing in there?
  • Ummm, no, I don't think so; the intention is that you can skip giving a time when it would be silly to give it (e.g., a release date). We don't want the full horrors (timezones!) of xs:datetime in there if you do want to give a time, though. If you still think this is a problem, let's chat. -- MarkusDemleitner - 2025-01-31
  • I agree about the full horrors your mentioned. I just wanted to point out that the text being: "A date stamp that can be given to a precision of either a day (type xs:date) or seconds (type xs:dateTime).", I would expect to see the same in the XML Schema snippet just below. But only xs:date appears. It is just a bit confusing, but since it is there for years, I guess it is not really a problem. -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.23-24:

  The IVO-ID of a Creator can be provided in two ways: 1/ by using the attribute 'ivo-id' of vr:Creator, 2/ by using the 'ivo-id' of the mandatory element 'name' of vr:Creator. What's the difference between both? What happens if both are provided but different? Should we deprecate the attribute 'ivo-id' of vr:Creator and set the IVO-ID only in the element 'name'?

• Sec. 3.1.2, p.26-27: same comment for vr:Contact
  • Good catches again. This is bad in VOResource 1.1 already, and probably nobody noticed because nobody registers as a person (and I'm happy about that). Since this hasn't caused harm so far and I don't want to rush a resolution, can I ask you to file a bug agains VOResource? We should of course fix it, but I don't think we should delay 1.2 to fix something that's been broken in VOResource from day 1. -- MarkusDemleitner - 2025-01-31
  • I've just reported this bug in https://github.com/ivoa-std/VOResource/issues/15 -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.24-25:

  The Date's 'role' attribute is set by default to 'representative'. However, this term is now deprecative. Should we use this new minor release of VOResource to update it, from 'representative' to 'Collected'? If so, it should be updated in the text (p.25), in the XML snippet (p.24) and in the XML schema.

  • Uh. This one I'd consider more serious, and I think it should be fixed for version 1.2. I'll post to the Registry list about it. -- MarkusDemleitner - 2025-01-31

• Sec. 3.1.3-4, p.31:

  It is strange to see a note about 'validationLevel' so far from the first definition of 'validationLevel' (p.19) and right in the middle 'relationship'. I assume it is a LaTeX side effect and, after reading few paragraphs after, this note is actually part of sec. 3.1.4. For the reader, it would however be more comfortable and understandable to force this note to be close to the 'validationLevel' definition (p.19) or inside the sec. 3.1.4 and not at the end of sec. 3.1.3.

  • Well, as you guessed, admonitions are floats in ivoatex, and this note floated to the top of p. 31. Hm. Since it's deeply technical, I'm quite sure it should remain lexically within 3.1.4. So, I'd suggest that ivoatex ought to prefer here-positioning for these floats (which IMHO works well here). If you want, try https://github.com/ivoa-std/ivoatex/pull/149 (and perhaps even review it?). -- MarkusDemleitner - 2025-01-31
  • I've just tried this solution. It looks OK now with VOResource-1.2 document. -- GregoryMantelet - 2025-01-31

• Changes mentioned above are in https://github.com/ivoa-std/VOResource/pull/14 -- MarkusDemleitner - 2025-01-31

Data Model Working Group

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
  • Good point. Updated to 4.6, which is from late 2024. -- MarkusDemleitner - 2025-01-20
• MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)
  • See below -- MarkusDemleitner - 2025-01-20

Grid & Web Services Working Group

Changes on 1.2 provide value to the standard and have been added clearly— nothing impacting GWS WG activities.

One minor comment: As the document does not have an acronyms section, it is recommended to expand the acronyms in the text whenever they are introduced the first time, like in the case of UAT and SPDX.

• I am now expanding these two acronyms, although I freely admit I had to research SPDX's expansion and had to resort to the Wikipedia for that; I think in this day and age acronyms are often a lot better known than their expansions (I wonder how many people would know what you're talking about when you ask them how much random access memory their telephones have...). That's https://github.com/ivoa-std/VOResource/pull/17 -- MarkusDemleitner - 2025-02-04

Are there plans to allow similar identifiers for other external machine-readable identifiers like, e.g. RORs for organisations?

• ROR is in post-RFC (see the link to the current builds above). I have briefly considered putting in some way to admit more schemes without having to touch the spec, but figured that we'll fist have to gather experience with the schemes we have (which aren't used terribly much up to now). -- MarkusDemleitner - 2025-02-04

The GWS approve the document -- JesusSalgado - 2025-01-31

Registry Working Group

We've been part of the document evolution and fully support it

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"?
  • This would immediately make a good deal of the resource records out there invalid, which is probably more than we intend to do, and one might argue we're not allowed to do such a thing in a minor update at all. My take on this is to convince data publishers one by one (for most of them it's probably not horribly hard to migrate) and make this a MUST when we don't break any (maintained) records any more. -- MarkusDemleitner - 2025-01-20
• 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.
  • We probably could do such a thing using RDFa on VOResource. Note that that would only do something for what we push out through OAI-PMH, while most people interact with the Registry using RegTAP, and there things can't be fixed as easily, as the prefix mapping would somehow have to cover VOTable data content, and XML processors often won't even see them. If we expected the outside world to start looking at VOResource, I'd say the RDFa way might be a good investiment of our creativity. As long as nobody external actually does look at VOResource, I'd consider it a bad deal in terms of bang for the (effort) buck. -- MarkusDemleitner - 2025-01-20
• 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.
  • It would be nice if we could be consistent here, but regrettably practicies change over time and will keep changing. Practices in VOResources will to some degree reflect the zeitgeist of when they were added. For RightsURI, we have to deal with legacy URIs and possibly all kinds of other things, and we have to way but either an https URL or a URI scheme to tell clients what it is. I don't think SPDX has asked for a URI scheme, and so it'll have to be the https URI, I'm afraid. Don't like it much myself, as you may guess. -- MarkusDemleitner - 2025-01-20"
• 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.
  • Right. I've put something in, and again, since it seems they're not interested in a URI scheme of their own, I'm asking for full URIs. -- MarkusDemleitner - 2025-01-19

Changes are in VOResource PR #13.

Data Curation & Preservation Interest Group

• Gilles Landais, 2024-12-20: congratulate this version that allows DOI, SPDX Licences, UAT
• Gilles Landais, 2024-12-20: as semantic, we propose also to include the RoR for organization
  • See above -- MarkusDemleitner - 2025-01-20
• 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.

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

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:

• 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):

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

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

That's still waiting for actual records, but that's only a minor technical matter: VizieR will push out records having these RSN.

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

• Sample comment by WikiName
  • Response (by WikiName)

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

• Pierre Le Sidaner, 2025-01-30: I've always found that VOResource didn't have the dedicated field to express the citation of the collection or service. The right way to declare DOIs, the ORCID, is really an important advance.

Data Access Layer Working Group

Excellent document. I also appreciate the addition of DOIs and ORCID, although this does not affect directly DAL protocols.

No blocking comment from the DAL Working Group. But some minor comments anyway (and few typos).

• Some typos:
• Sec. 2, p.8: typcially -> typically
• Sec. 2.2.1, p.10:
  • For all types and element names that are made up of multiple words, such as shortName, upper-case letters are used to demarcate the start
  • This is intended to allow simple markup
• Sec. 2.2.4, p.11: remove the trailing comma: 2008-02-22T12:22:34Z,
• Sec. 2.2.5, p.12: strongly urges the use of http URIs
• Sec. 3.1, p.19: Applications may use it to refer to this resource in a compact display.
  • Thanks indeed for catching these; most of them have been in there for more than a decade. Fixed in the PR (except for the comma thing; there needs to be a comma there for syntax reasons, but at least it's outside of the literal now). -- MarkusDemleitner - 2025-01-31

p.46: The DOI points toward the ADS page. And the link in the ADS page points to itself In any case, there is no way to read this document with such link (although the Endorsed Note can be read very easily in the IVOA Document page). It may be useful to fix this link....which is, of course, out of scope for this RFC. It just wanted to share this comment.

Harrison, P., Demleitner, M., Major, B. and Dowler, P. (2018), ‘XML Schema Versioning Policies Version 1.0’, IVOA Endorsed Note 29 May

doi:10.5479/ADS/bib/2018ivoa.spec.0529H, https://ui.adsabs.harvard.edu/ abs/2018ivoa.spec.0529H.

• • Oh, ouch. I'll talk to ADS about it. They shouldn't use the DOI as the link here, clearly. But it's nothing I can fix here -- MarkusDemleitner - 2025-01-31
  • I indeed expected you can not directly fix this. It is ADS content after all. -- GregoryMantelet - 2025-01-31

• Sec. 2.2.4, p.11: vr:UTCDateTime : it should be an xs:date or xs:dateTime. I am no XMLSchema expert, but the union in the VOResource XML schema defines it only as the union of xs:date and vr:UTCTimestamp. Is xs:dateTime missing in there?
  • Ummm, no, I don't think so; the intention is that you can skip giving a time when it would be silly to give it (e.g., a release date). We don't want the full horrors (timezones!) of xs:datetime in there if you do want to give a time, though. If you still think this is a problem, let's chat. -- MarkusDemleitner - 2025-01-31
  • I agree about the full horrors your mentioned. I just wanted to point out that the text being: "A date stamp that can be given to a precision of either a day (type xs:date) or seconds (type xs:dateTime).", I would expect to see the same in the XML Schema snippet just below. But only xs:date appears. It is just a bit confusing, but since it is there for years, I guess it is not really a problem. -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.23-24:

  The IVO-ID of a Creator can be provided in two ways: 1/ by using the attribute 'ivo-id' of vr:Creator, 2/ by using the 'ivo-id' of the mandatory element 'name' of vr:Creator. What's the difference between both? What happens if both are provided but different? Should we deprecate the attribute 'ivo-id' of vr:Creator and set the IVO-ID only in the element 'name'?

• Sec. 3.1.2, p.26-27: same comment for vr:Contact
  • Good catches again. This is bad in VOResource 1.1 already, and probably nobody noticed because nobody registers as a person (and I'm happy about that). Since this hasn't caused harm so far and I don't want to rush a resolution, can I ask you to file a bug agains VOResource? We should of course fix it, but I don't think we should delay 1.2 to fix something that's been broken in VOResource from day 1. -- MarkusDemleitner - 2025-01-31
  • I've just reported this bug in https://github.com/ivoa-std/VOResource/issues/15 -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.24-25:

  The Date's 'role' attribute is set by default to 'representative'. However, this term is now deprecative. Should we use this new minor release of VOResource to update it, from 'representative' to 'Collected'? If so, it should be updated in the text (p.25), in the XML snippet (p.24) and in the XML schema.

  • Uh. This one I'd consider more serious, and I think it should be fixed for version 1.2. I'll post to the Registry list about it. -- MarkusDemleitner - 2025-01-31

• Sec. 3.1.3-4, p.31:

  It is strange to see a note about 'validationLevel' so far from the first definition of 'validationLevel' (p.19) and right in the middle 'relationship'. I assume it is a LaTeX side effect and, after reading few paragraphs after, this note is actually part of sec. 3.1.4. For the reader, it would however be more comfortable and understandable to force this note to be close to the 'validationLevel' definition (p.19) or inside the sec. 3.1.4 and not at the end of sec. 3.1.3.

  • Well, as you guessed, admonitions are floats in ivoatex, and this note floated to the top of p. 31. Hm. Since it's deeply technical, I'm quite sure it should remain lexically within 3.1.4. So, I'd suggest that ivoatex ought to prefer here-positioning for these floats (which IMHO works well here). If you want, try https://github.com/ivoa-std/ivoatex/pull/149 (and perhaps even review it?). -- MarkusDemleitner - 2025-01-31
  • I've just tried this solution. It looks OK now with VOResource-1.2 document. -- GregoryMantelet - 2025-01-31

• Changes mentioned above are in https://github.com/ivoa-std/VOResource/pull/14 -- MarkusDemleitner - 2025-01-31

Data Model Working Group

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
  • Good point. Updated to 4.6, which is from late 2024. -- MarkusDemleitner - 2025-01-20
• MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)
  • See below -- MarkusDemleitner - 2025-01-20

Grid & Web Services Working Group

Changes on 1.2 provide value to the standard and have been added clearly— nothing impacting GWS WG activities.

One minor comment: As the document does not have an acronyms section, it is recommended to expand the acronyms in the text whenever they are introduced the first time, like in the case of UAT and SPDX.

• I am now expanding these two acronyms, although I freely admit I had to research SPDX's expansion and had to resort to the Wikipedia for that; I think in this day and age acronyms are often a lot better known than their expansions (I wonder how many people would know what you're talking about when you ask them how much random access memory their telephones have...). That's https://github.com/ivoa-std/VOResource/pull/17 -- MarkusDemleitner - 2025-02-04

Are there plans to allow similar identifiers for other external machine-readable identifiers like, e.g. RORs for organisations?

• ROR is in post-RFC (see the link to the current builds above). I have briefly considered putting in some way to admit more schemes without having to touch the spec, but figured that we'll fist have to gather experience with the schemes we have (which aren't used terribly much up to now). -- MarkusDemleitner - 2025-02-04

The GWS approve the document -- JesusSalgado - 2025-01-31

Registry Working Group

We've been part of the document evolution and fully support it

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"?
  • This would immediately make a good deal of the resource records out there invalid, which is probably more than we intend to do, and one might argue we're not allowed to do such a thing in a minor update at all. My take on this is to convince data publishers one by one (for most of them it's probably not horribly hard to migrate) and make this a MUST when we don't break any (maintained) records any more. -- MarkusDemleitner - 2025-01-20
• 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.
  • We probably could do such a thing using RDFa on VOResource. Note that that would only do something for what we push out through OAI-PMH, while most people interact with the Registry using RegTAP, and there things can't be fixed as easily, as the prefix mapping would somehow have to cover VOTable data content, and XML processors often won't even see them. If we expected the outside world to start looking at VOResource, I'd say the RDFa way might be a good investiment of our creativity. As long as nobody external actually does look at VOResource, I'd consider it a bad deal in terms of bang for the (effort) buck. -- MarkusDemleitner - 2025-01-20
• 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.
  • It would be nice if we could be consistent here, but regrettably practicies change over time and will keep changing. Practices in VOResources will to some degree reflect the zeitgeist of when they were added. For RightsURI, we have to deal with legacy URIs and possibly all kinds of other things, and we have to way but either an https URL or a URI scheme to tell clients what it is. I don't think SPDX has asked for a URI scheme, and so it'll have to be the https URI, I'm afraid. Don't like it much myself, as you may guess. -- MarkusDemleitner - 2025-01-20"
• 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.
  • Right. I've put something in, and again, since it seems they're not interested in a URI scheme of their own, I'm asking for full URIs. -- MarkusDemleitner - 2025-01-19

Changes are in VOResource PR #13.

Data Curation & Preservation Interest Group

• Gilles Landais, 2024-12-20: congratulate this version that allows DOI, SPDX Licences, UAT
• Gilles Landais, 2024-12-20: as semantic, we propose also to include the RoR for organization
  • See above -- MarkusDemleitner - 2025-01-20
• 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.

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

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:

• 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):

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

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

That's still waiting for actual records, but that's only a minor technical matter: VizieR will push out records having these RSN.

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

• Sample comment by WikiName
  • Response (by WikiName)

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

• Pierre Le Sidaner, 2025-01-30: I've always found that VOResource didn't have the dedicated field to express the citation of the collection or service. The right way to declare DOIs, the ORCID, is really an important advance.

Data Access Layer Working Group

Excellent document. I also appreciate the addition of DOIs and ORCID, although this does not affect directly DAL protocols.

No blocking comment from the DAL Working Group. But some minor comments anyway (and few typos).

• Some typos:
• Sec. 2, p.8: typcially -> typically
• Sec. 2.2.1, p.10:
  • For all types and element names that are made up of multiple words, such as shortName, upper-case letters are used to demarcate the start
  • This is intended to allow simple markup
• Sec. 2.2.4, p.11: remove the trailing comma: 2008-02-22T12:22:34Z,
• Sec. 2.2.5, p.12: strongly urges the use of http URIs
• Sec. 3.1, p.19: Applications may use it to refer to this resource in a compact display.
  • Thanks indeed for catching these; most of them have been in there for more than a decade. Fixed in the PR (except for the comma thing; there needs to be a comma there for syntax reasons, but at least it's outside of the literal now). -- MarkusDemleitner - 2025-01-31

p.46: The DOI points toward the ADS page. And the link in the ADS page points to itself In any case, there is no way to read this document with such link (although the Endorsed Note can be read very easily in the IVOA Document page). It may be useful to fix this link....which is, of course, out of scope for this RFC. It just wanted to share this comment.

Harrison, P., Demleitner, M., Major, B. and Dowler, P. (2018), ‘XML Schema Versioning Policies Version 1.0’, IVOA Endorsed Note 29 May

doi:10.5479/ADS/bib/2018ivoa.spec.0529H, https://ui.adsabs.harvard.edu/ abs/2018ivoa.spec.0529H.

• • Oh, ouch. I'll talk to ADS about it. They shouldn't use the DOI as the link here, clearly. But it's nothing I can fix here -- MarkusDemleitner - 2025-01-31
  • I indeed expected you can not directly fix this. It is ADS content after all. -- GregoryMantelet - 2025-01-31

• Sec. 2.2.4, p.11: vr:UTCDateTime : it should be an xs:date or xs:dateTime. I am no XMLSchema expert, but the union in the VOResource XML schema defines it only as the union of xs:date and vr:UTCTimestamp. Is xs:dateTime missing in there?
  • Ummm, no, I don't think so; the intention is that you can skip giving a time when it would be silly to give it (e.g., a release date). We don't want the full horrors (timezones!) of xs:datetime in there if you do want to give a time, though. If you still think this is a problem, let's chat. -- MarkusDemleitner - 2025-01-31
  • I agree about the full horrors your mentioned. I just wanted to point out that the text being: "A date stamp that can be given to a precision of either a day (type xs:date) or seconds (type xs:dateTime).", I would expect to see the same in the XML Schema snippet just below. But only xs:date appears. It is just a bit confusing, but since it is there for years, I guess it is not really a problem. -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.23-24:

  The IVO-ID of a Creator can be provided in two ways: 1/ by using the attribute 'ivo-id' of vr:Creator, 2/ by using the 'ivo-id' of the mandatory element 'name' of vr:Creator. What's the difference between both? What happens if both are provided but different? Should we deprecate the attribute 'ivo-id' of vr:Creator and set the IVO-ID only in the element 'name'?

• Sec. 3.1.2, p.26-27: same comment for vr:Contact
  • Good catches again. This is bad in VOResource 1.1 already, and probably nobody noticed because nobody registers as a person (and I'm happy about that). Since this hasn't caused harm so far and I don't want to rush a resolution, can I ask you to file a bug agains VOResource? We should of course fix it, but I don't think we should delay 1.2 to fix something that's been broken in VOResource from day 1. -- MarkusDemleitner - 2025-01-31
  • I've just reported this bug in https://github.com/ivoa-std/VOResource/issues/15 -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.24-25:

  The Date's 'role' attribute is set by default to 'representative'. However, this term is now deprecative. Should we use this new minor release of VOResource to update it, from 'representative' to 'Collected'? If so, it should be updated in the text (p.25), in the XML snippet (p.24) and in the XML schema.

  • Uh. This one I'd consider more serious, and I think it should be fixed for version 1.2. I'll post to the Registry list about it. -- MarkusDemleitner - 2025-01-31

• Sec. 3.1.3-4, p.31:

  It is strange to see a note about 'validationLevel' so far from the first definition of 'validationLevel' (p.19) and right in the middle 'relationship'. I assume it is a LaTeX side effect and, after reading few paragraphs after, this note is actually part of sec. 3.1.4. For the reader, it would however be more comfortable and understandable to force this note to be close to the 'validationLevel' definition (p.19) or inside the sec. 3.1.4 and not at the end of sec. 3.1.3.

  • Well, as you guessed, admonitions are floats in ivoatex, and this note floated to the top of p. 31. Hm. Since it's deeply technical, I'm quite sure it should remain lexically within 3.1.4. So, I'd suggest that ivoatex ought to prefer here-positioning for these floats (which IMHO works well here). If you want, try https://github.com/ivoa-std/ivoatex/pull/149 (and perhaps even review it?). -- MarkusDemleitner - 2025-01-31
  • I've just tried this solution. It looks OK now with VOResource-1.2 document. -- GregoryMantelet - 2025-01-31

• Changes mentioned above are in https://github.com/ivoa-std/VOResource/pull/14 -- MarkusDemleitner - 2025-01-31

Data Model Working Group

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
  • Good point. Updated to 4.6, which is from late 2024. -- MarkusDemleitner - 2025-01-20
• MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)
  • See below -- MarkusDemleitner - 2025-01-20

Grid & Web Services Working Group

Changes on 1.2 provide value to the standard and have been added clearly— nothing impacting GWS WG activities.

One minor comment: As the document does not have an acronyms section, it is recommended to expand the acronyms in the text whenever they are introduced the first time, like in the case of UAT and SPDX.

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"?
  • This would immediately make a good deal of the resource records out there invalid, which is probably more than we intend to do, and one might argue we're not allowed to do such a thing in a minor update at all. My take on this is to convince data publishers one by one (for most of them it's probably not horribly hard to migrate) and make this a MUST when we don't break any (maintained) records any more. -- MarkusDemleitner - 2025-01-20
• 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.
  • We probably could do such a thing using RDFa on VOResource. Note that that would only do something for what we push out through OAI-PMH, while most people interact with the Registry using RegTAP, and there things can't be fixed as easily, as the prefix mapping would somehow have to cover VOTable data content, and XML processors often won't even see them. If we expected the outside world to start looking at VOResource, I'd say the RDFa way might be a good investiment of our creativity. As long as nobody external actually does look at VOResource, I'd consider it a bad deal in terms of bang for the (effort) buck. -- MarkusDemleitner - 2025-01-20
• 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.
  • It would be nice if we could be consistent here, but regrettably practicies change over time and will keep changing. Practices in VOResources will to some degree reflect the zeitgeist of when they were added. For RightsURI, we have to deal with legacy URIs and possibly all kinds of other things, and we have to way but either an https URL or a URI scheme to tell clients what it is. I don't think SPDX has asked for a URI scheme, and so it'll have to be the https URI, I'm afraid. Don't like it much myself, as you may guess. -- MarkusDemleitner - 2025-01-20"
• 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.
  • Right. I've put something in, and again, since it seems they're not interested in a URI scheme of their own, I'm asking for full URIs. -- MarkusDemleitner - 2025-01-19

Changes are in VOResource PR #13.

Data Curation & Preservation Interest Group

• Gilles Landais, 2024-12-20: congratulate this version that allows DOI, SPDX Licences, UAT
• Gilles Landais, 2024-12-20: as semantic, we propose also to include the RoR for organization
  • See above -- MarkusDemleitner - 2025-01-20
• 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.

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

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:

• 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):

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

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

That's still waiting for actual records, but that's only a minor technical matter: VizieR will push out records having these RSN.

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

• Sample comment by WikiName
  • Response (by WikiName)

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

• Pierre Le Sidaner, 2025-01-30: I've always found that VOResource didn't have the dedicated field to express the citation of the collection or service. The right way to declare DOIs, the ORCID, is really an important advance.

Data Access Layer Working Group

Excellent document. I also appreciate the addition of DOIs and ORCID, although this does not affect directly DAL protocols.

No blocking comment from the DAL Working Group. But some minor comments anyway (and few typos).

• Some typos:
• Sec. 2, p.8: typcially -> typically
• Sec. 2.2.1, p.10:
  • For all types and element names that are made up of multiple words, such as shortName, upper-case letters are used to demarcate the start
  • This is intended to allow simple markup
• Sec. 2.2.4, p.11: remove the trailing comma: 2008-02-22T12:22:34Z,
• Sec. 2.2.5, p.12: strongly urges the use of http URIs
• Sec. 3.1, p.19: Applications may use it to refer to this resource in a compact display.
  • Thanks indeed for catching these; most of them have been in there for more than a decade. Fixed in the PR (except for the comma thing; there needs to be a comma there for syntax reasons, but at least it's outside of the literal now). -- MarkusDemleitner - 2025-01-31

p.46: The DOI points toward the ADS page. And the link in the ADS page points to itself In any case, there is no way to read this document with such link (although the Endorsed Note can be read very easily in the IVOA Document page). It may be useful to fix this link....which is, of course, out of scope for this RFC. It just wanted to share this comment.

Harrison, P., Demleitner, M., Major, B. and Dowler, P. (2018), ‘XML Schema Versioning Policies Version 1.0’, IVOA Endorsed Note 29 May

doi:10.5479/ADS/bib/2018ivoa.spec.0529H, https://ui.adsabs.harvard.edu/ abs/2018ivoa.spec.0529H.

• • Oh, ouch. I'll talk to ADS about it. They shouldn't use the DOI as the link here, clearly. But it's nothing I can fix here -- MarkusDemleitner - 2025-01-31
  • I indeed expected you can not directly fix this. It is ADS content after all. -- GregoryMantelet - 2025-01-31

• Sec. 2.2.4, p.11: vr:UTCDateTime : it should be an xs:date or xs:dateTime. I am no XMLSchema expert, but the union in the VOResource XML schema defines it only as the union of xs:date and vr:UTCTimestamp. Is xs:dateTime missing in there?
  • Ummm, no, I don't think so; the intention is that you can skip giving a time when it would be silly to give it (e.g., a release date). We don't want the full horrors (timezones!) of xs:datetime in there if you do want to give a time, though. If you still think this is a problem, let's chat. -- MarkusDemleitner - 2025-01-31
  • I agree about the full horrors your mentioned. I just wanted to point out that the text being: "A date stamp that can be given to a precision of either a day (type xs:date) or seconds (type xs:dateTime).", I would expect to see the same in the XML Schema snippet just below. But only xs:date appears. It is just a bit confusing, but since it is there for years, I guess it is not really a problem. -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.23-24:

  The IVO-ID of a Creator can be provided in two ways: 1/ by using the attribute 'ivo-id' of vr:Creator, 2/ by using the 'ivo-id' of the mandatory element 'name' of vr:Creator. What's the difference between both? What happens if both are provided but different? Should we deprecate the attribute 'ivo-id' of vr:Creator and set the IVO-ID only in the element 'name'?

• Sec. 3.1.2, p.26-27: same comment for vr:Contact
  • Good catches again. This is bad in VOResource 1.1 already, and probably nobody noticed because nobody registers as a person (and I'm happy about that). Since this hasn't caused harm so far and I don't want to rush a resolution, can I ask you to file a bug agains VOResource? We should of course fix it, but I don't think we should delay 1.2 to fix something that's been broken in VOResource from day 1. -- MarkusDemleitner - 2025-01-31
  • I've just reported this bug in https://github.com/ivoa-std/VOResource/issues/15 -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.24-25:

  The Date's 'role' attribute is set by default to 'representative'. However, this term is now deprecative. Should we use this new minor release of VOResource to update it, from 'representative' to 'Collected'? If so, it should be updated in the text (p.25), in the XML snippet (p.24) and in the XML schema.

  • Uh. This one I'd consider more serious, and I think it should be fixed for version 1.2. I'll post to the Registry list about it. -- MarkusDemleitner - 2025-01-31

• Sec. 3.1.3-4, p.31:

  It is strange to see a note about 'validationLevel' so far from the first definition of 'validationLevel' (p.19) and right in the middle 'relationship'. I assume it is a LaTeX side effect and, after reading few paragraphs after, this note is actually part of sec. 3.1.4. For the reader, it would however be more comfortable and understandable to force this note to be close to the 'validationLevel' definition (p.19) or inside the sec. 3.1.4 and not at the end of sec. 3.1.3.

  • Well, as you guessed, admonitions are floats in ivoatex, and this note floated to the top of p. 31. Hm. Since it's deeply technical, I'm quite sure it should remain lexically within 3.1.4. So, I'd suggest that ivoatex ought to prefer here-positioning for these floats (which IMHO works well here). If you want, try https://github.com/ivoa-std/ivoatex/pull/149 (and perhaps even review it?). -- MarkusDemleitner - 2025-01-31
  • I've just tried this solution. It looks OK now with VOResource-1.2 document. -- GregoryMantelet - 2025-01-31

• Changes mentioned above are in https://github.com/ivoa-std/VOResource/pull/14 -- MarkusDemleitner - 2025-01-31

Data Model Working Group

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
  • Good point. Updated to 4.6, which is from late 2024. -- MarkusDemleitner - 2025-01-20
• MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)
  • See below -- MarkusDemleitner - 2025-01-20

Grid & Web Services Working Group

Changes on 1.2 provide value to the standard and have been added clearly— nothing impacting GWS WG activities.

One minor comment: As the document does not have an acronyms section, it is recommended to expand the acronyms in the text whenever they are introduced the first time, like in the case of UAT and SPDX.

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"?
  • This would immediately make a good deal of the resource records out there invalid, which is probably more than we intend to do, and one might argue we're not allowed to do such a thing in a minor update at all. My take on this is to convince data publishers one by one (for most of them it's probably not horribly hard to migrate) and make this a MUST when we don't break any (maintained) records any more. -- MarkusDemleitner - 2025-01-20
• 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.
  • We probably could do such a thing using RDFa on VOResource. Note that that would only do something for what we push out through OAI-PMH, while most people interact with the Registry using RegTAP, and there things can't be fixed as easily, as the prefix mapping would somehow have to cover VOTable data content, and XML processors often won't even see them. If we expected the outside world to start looking at VOResource, I'd say the RDFa way might be a good investiment of our creativity. As long as nobody external actually does look at VOResource, I'd consider it a bad deal in terms of bang for the (effort) buck. -- MarkusDemleitner - 2025-01-20
• 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.
  • It would be nice if we could be consistent here, but regrettably practicies change over time and will keep changing. Practices in VOResources will to some degree reflect the zeitgeist of when they were added. For RightsURI, we have to deal with legacy URIs and possibly all kinds of other things, and we have to way but either an https URL or a URI scheme to tell clients what it is. I don't think SPDX has asked for a URI scheme, and so it'll have to be the https URI, I'm afraid. Don't like it much myself, as you may guess. -- MarkusDemleitner - 2025-01-20"
• 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.
  • Right. I've put something in, and again, since it seems they're not interested in a URI scheme of their own, I'm asking for full URIs. -- MarkusDemleitner - 2025-01-19

Changes are in VOResource PR #13.

Data Curation & Preservation Interest Group

• Gilles Landais, 2024-12-20: congratulate this version that allows DOI, SPDX Licences, UAT
• Gilles Landais, 2024-12-20: as semantic, we propose also to include the RoR for organization
  • See above -- MarkusDemleitner - 2025-01-20
• 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.

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

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):

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

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

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

• Sample comment by WikiName
  • Response (by WikiName)

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

• Pierre Le Sidaner, 2025-01-30: I've always found that VOResource didn't have the dedicated field to express the citation of the collection or service. The right way to declare DOIs, the ORCID, is really an important advance.

Data Access Layer Working Group

Excellent document. I also appreciate the addition of DOIs and ORCID, although this does not affect directly DAL protocols.

No blocking comment from the DAL Working Group. But some minor comments anyway (and few typos).

• Some typos:
• Sec. 2, p.8: typcially -> typically
• Sec. 2.2.1, p.10:
  • For all types and element names that are made up of multiple words, such as shortName, upper-case letters are used to demarcate the start
  • This is intended to allow simple markup
• Sec. 2.2.4, p.11: remove the trailing comma: 2008-02-22T12:22:34Z,
• Sec. 2.2.5, p.12: strongly urges the use of http URIs
• Sec. 3.1, p.19: Applications may use it to refer to this resource in a compact display.
  • Thanks indeed for catching these; most of them have been in there for more than a decade. Fixed in the PR (except for the comma thing; there needs to be a comma there for syntax reasons, but at least it's outside of the literal now). -- MarkusDemleitner - 2025-01-31

p.46: The DOI points toward the ADS page. And the link in the ADS page points to itself In any case, there is no way to read this document with such link (although the Endorsed Note can be read very easily in the IVOA Document page). It may be useful to fix this link....which is, of course, out of scope for this RFC. It just wanted to share this comment.

Harrison, P., Demleitner, M., Major, B. and Dowler, P. (2018), ‘XML Schema Versioning Policies Version 1.0’, IVOA Endorsed Note 29 May

• • Oh, ouch. I'll talk to ADS about it. They shouldn't use the DOI as the link here, clearly. But it's nothing I can fix here -- MarkusDemleitner - 2025-01-31
  • I indeed expected you can not directly fix this. It is ADS content after all. -- GregoryMantelet - 2025-01-31

• Sec. 2.2.4, p.11: vr:UTCDateTime : it should be an xs:date or xs:dateTime. I am no XMLSchema expert, but the union in the VOResource XML schema defines it only as the union of xs:date and vr:UTCTimestamp. Is xs:dateTime missing in there?
  • Ummm, no, I don't think so; the intention is that you can skip giving a time when it would be silly to give it (e.g., a release date). We don't want the full horrors (timezones!) of xs:datetime in there if you do want to give a time, though. If you still think this is a problem, let's chat. -- MarkusDemleitner - 2025-01-31
  • I agree about the full horrors your mentioned. I just wanted to point out that the text being: "A date stamp that can be given to a precision of either a day (type xs:date) or seconds (type xs:dateTime).", I would expect to see the same in the XML Schema snippet just below. But only xs:date appears. It is just a bit confusing, but since it is there for years, I guess it is not really a problem. -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.23-24:

  The IVO-ID of a Creator can be provided in two ways: 1/ by using the attribute 'ivo-id' of vr:Creator, 2/ by using the 'ivo-id' of the mandatory element 'name' of vr:Creator. What's the difference between both? What happens if both are provided but different? Should we deprecate the attribute 'ivo-id' of vr:Creator and set the IVO-ID only in the element 'name'?

• Sec. 3.1.2, p.26-27: same comment for vr:Contact
  • Good catches again. This is bad in VOResource 1.1 already, and probably nobody noticed because nobody registers as a person (and I'm happy about that). Since this hasn't caused harm so far and I don't want to rush a resolution, can I ask you to file a bug agains VOResource? We should of course fix it, but I don't think we should delay 1.2 to fix something that's been broken in VOResource from day 1. -- MarkusDemleitner - 2025-01-31
  • I've just reported this bug in https://github.com/ivoa-std/VOResource/issues/15 -- GregoryMantelet - 2025-01-31

• Sec. 3.1.2, p.24-25:

  The Date's 'role' attribute is set by default to 'representative'. However, this term is now deprecative. Should we use this new minor release of VOResource to update it, from 'representative' to 'Collected'? If so, it should be updated in the text (p.25), in the XML snippet (p.24) and in the XML schema.

  • Uh. This one I'd consider more serious, and I think it should be fixed for version 1.2. I'll post to the Registry list about it. -- MarkusDemleitner - 2025-01-31

• Sec. 3.1.3-4, p.31:

  It is strange to see a note about 'validationLevel' so far from the first definition of 'validationLevel' (p.19) and right in the middle 'relationship'. I assume it is a LaTeX side effect and, after reading few paragraphs after, this note is actually part of sec. 3.1.4. For the reader, it would however be more comfortable and understandable to force this note to be close to the 'validationLevel' definition (p.19) or inside the sec. 3.1.4 and not at the end of sec. 3.1.3.

• • I've just tried this solution. It looks OK now with VOResource-1.2 document. -- GregoryMantelet - 2025-01-31

Data Model Working Group

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
  • Good point. Updated to 4.6, which is from late 2024. -- MarkusDemleitner - 2025-01-20
• MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)
  • See below -- MarkusDemleitner - 2025-01-20

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"?
  • This would immediately make a good deal of the resource records out there invalid, which is probably more than we intend to do, and one might argue we're not allowed to do such a thing in a minor update at all. My take on this is to convince data publishers one by one (for most of them it's probably not horribly hard to migrate) and make this a MUST when we don't break any (maintained) records any more. -- MarkusDemleitner - 2025-01-20

• • We probably could do such a thing using RDFa on VOResource. Note that that would only do something for what we push out through OAI-PMH, while most people interact with the Registry using RegTAP, and there things can't be fixed as easily, as the prefix mapping would somehow have to cover VOTable data content, and XML processors often won't even see them. If we expected the outside world to start looking at VOResource, I'd say the RDFa way might be a good investiment of our creativity. As long as nobody external actually does look at VOResource, I'd consider it a bad deal in terms of bang for the (effort) buck. -- MarkusDemleitner - 2025-01-20
• 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.
  • It would be nice if we could be consistent here, but regrettably practicies change over time and will keep changing. Practices in VOResources will to some degree reflect the zeitgeist of when they were added. For RightsURI, we have to deal with legacy URIs and possibly all kinds of other things, and we have to way but either an https URL or a URI scheme to tell clients what it is. I don't think SPDX has asked for a URI scheme, and so it'll have to be the https URI, I'm afraid. Don't like it much myself, as you may guess. -- MarkusDemleitner - 2025-01-20"

• • Right. I've put something in, and again, since it seems they're not interested in a URI scheme of their own, I'm asking for full URIs. -- MarkusDemleitner - 2025-01-19

Changes are in VOResource PR #13.

Data Curation & Preservation Interest Group

• Gilles Landais, 2024-12-20: congratulate this version that allows DOI, SPDX Licences, UAT
• Gilles Landais, 2024-12-20: as semantic, we propose also to include the RoR for organization
  • See above -- MarkusDemleitner - 2025-01-20
• 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.

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

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:

• 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):

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

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

That's still waiting for actual records, but that's only a minor technical matter: VizieR will push out records having these RSN.

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

• Sample comment by WikiName
  • Response (by WikiName)

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

• Pierre Le Sidaner, 2025-01-30: I've always found that VOResource didn't have the dedicated field to express the citation of the collection or service. The right way to declare DOIs, the ORCID, is really an important advance.

Data Access Layer Working Group

Excellent document. I also appreciate the addition of DOIs and ORCID, although this does not affect directly DAL protocols.

No blocking comment from the DAL Working Group. But some minor comments anyway (and few typos).

• Some typos:
• Sec. 2, p.8: typcially -> typically
• Sec. 2.2.1, p.10:
  • For all types and element names that are made up of multiple words, such as shortName, upper-case letters are used to demarcate the start
  • This is intended to allow simple markup
• Sec. 2.2.4, p.11: remove the trailing comma: 2008-02-22T12:22:34Z,
• Sec. 2.2.5, p.12: strongly urges the use of http URIs
• Sec. 3.1, p.19: Applications may use it to refer to this resource in a compact display.

Harrison, P., Demleitner, M., Major, B. and Dowler, P. (2018), ‘XML Schema Versioning Policies Version 1.0’, IVOA Endorsed Note 29 May

• Sec. 3.1.2, p.26-27: same comment for vr:Contact

• Sec. 3.1.3-4, p.31:

  It is strange to see a note about 'validationLevel' so far from the first definition of 'validationLevel' (p.19) and right in the middle 'relationship'. I assume it is a LaTeX side effect and, after reading few paragraphs after, this note is actually part of sec. 3.1.4. For the reader, it would however be more comfortable and understandable to force this note to be close to the 'validationLevel' definition (p.19) or inside the sec. 3.1.4 and not at the end of sec. 3.1.3.

Data Model Working Group

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
  • Good point. Updated to 4.6, which is from late 2024. -- MarkusDemleitner - 2025-01-20
• MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)
  • See below -- MarkusDemleitner - 2025-01-20

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"?
  • This would immediately make a good deal of the resource records out there invalid, which is probably more than we intend to do, and one might argue we're not allowed to do such a thing in a minor update at all. My take on this is to convince data publishers one by one (for most of them it's probably not horribly hard to migrate) and make this a MUST when we don't break any (maintained) records any more. -- MarkusDemleitner - 2025-01-20
• 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.
  • We probably could do such a thing using RDFa on VOResource. Note that that would only do something for what we push out through OAI-PMH, while most people interact with the Registry using RegTAP, and there things can't be fixed as easily, as the prefix mapping would somehow have to cover VOTable data content, and XML processors often won't even see them. If we expected the outside world to start looking at VOResource, I'd say the RDFa way might be a good investiment of our creativity. As long as nobody external actually does look at VOResource, I'd consider it a bad deal in terms of bang for the (effort) buck. -- MarkusDemleitner - 2025-01-20
• 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.
  • It would be nice if we could be consistent here, but regrettably practicies change over time and will keep changing. Practices in VOResources will to some degree reflect the zeitgeist of when they were added. For RightsURI, we have to deal with legacy URIs and possibly all kinds of other things, and we have to way but either an https URL or a URI scheme to tell clients what it is. I don't think SPDX has asked for a URI scheme, and so it'll have to be the https URI, I'm afraid. Don't like it much myself, as you may guess. -- MarkusDemleitner - 2025-01-20"
• 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.
  • Right. I've put something in, and again, since it seems they're not interested in a URI scheme of their own, I'm asking for full URIs. -- MarkusDemleitner - 2025-01-19

Changes are in VOResource PR #13.

Data Curation & Preservation Interest Group

• Gilles Landais, 2024-12-20: congratulate this version that allows DOI, SPDX Licences, UAT
• Gilles Landais, 2024-12-20: as semantic, we propose also to include the RoR for organization
  • See above -- MarkusDemleitner - 2025-01-20
• 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.

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

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:

• 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):

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

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

That's still waiting for actual records, but that's only a minor technical matter: VizieR will push out records having these RSN.

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

• Sample comment by WikiName
  • Response (by WikiName)

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

• Pierre Le Sidaner, 2025-01-30: I've always found that VOResource didn't have the dedicated field to express the citation of the collection or service. The right way to declare DOIs, the ORCID, is really an important advance.

Data Access Layer Working Group

Excellent document. I also appreciate the addition of DOIs and ORCID, although this does not affect directly DAL protocols.

No blocking comment from the DAL Working Group. But some minor comments anyway (and few typos).

• Sec. 2, p.8: typcially -> typically
• Sec. 2.2.1, p.10:

• • This is intended to allow simple markup
• Sec. 2.2.4, p.11: remove the trailing comma: 2008-02-22T12:22:34Z,

Harrison, P., Demleitner, M., Major, B. and Dowler, P. (2018), ‘XML Schema Versioning Policies Version 1.0’, IVOA Endorsed Note 29 May

• Sec. 2.2.4, p.11: vr:UTCDateTime : it should be an xs:date or xs:dateTime. I am no XMLSchema expert, but the union in the VOResource XML schema defines it only as the union of xs:date and vr:UTCTimestamp. Is xs:dateTime missing in there

• Sec. 3.1.3-4, p.31:

  It is strange to see a note about 'validationLevel' so far from the first definition of 'validationLevel' (p.19) and right in the middle 'relationship'. I assume it is a LaTeX side effect and, after reading few paragraphs after, this note is actually part of sec. 3.1.4. For the reader, it would however be more comfortable and understandable to force this note to be close to the 'validationLevel' definition (p.19) or inside the sec. 3.1.4 and not at the end of sec. 3.1.3.

Data Model Working Group

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
  • Good point. Updated to 4.6, which is from late 2024. -- MarkusDemleitner - 2025-01-20
• MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)
  • See below -- MarkusDemleitner - 2025-01-20

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"?
  • This would immediately make a good deal of the resource records out there invalid, which is probably more than we intend to do, and one might argue we're not allowed to do such a thing in a minor update at all. My take on this is to convince data publishers one by one (for most of them it's probably not horribly hard to migrate) and make this a MUST when we don't break any (maintained) records any more. -- MarkusDemleitner - 2025-01-20
• 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.
  • We probably could do such a thing using RDFa on VOResource. Note that that would only do something for what we push out through OAI-PMH, while most people interact with the Registry using RegTAP, and there things can't be fixed as easily, as the prefix mapping would somehow have to cover VOTable data content, and XML processors often won't even see them. If we expected the outside world to start looking at VOResource, I'd say the RDFa way might be a good investiment of our creativity. As long as nobody external actually does look at VOResource, I'd consider it a bad deal in terms of bang for the (effort) buck. -- MarkusDemleitner - 2025-01-20
• 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.
  • It would be nice if we could be consistent here, but regrettably practicies change over time and will keep changing. Practices in VOResources will to some degree reflect the zeitgeist of when they were added. For RightsURI, we have to deal with legacy URIs and possibly all kinds of other things, and we have to way but either an https URL or a URI scheme to tell clients what it is. I don't think SPDX has asked for a URI scheme, and so it'll have to be the https URI, I'm afraid. Don't like it much myself, as you may guess. -- MarkusDemleitner - 2025-01-20"
• 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.
  • Right. I've put something in, and again, since it seems they're not interested in a URI scheme of their own, I'm asking for full URIs. -- MarkusDemleitner - 2025-01-19

Changes are in VOResource PR #13.

Data Curation & Preservation Interest Group

• Gilles Landais, 2024-12-20: congratulate this version that allows DOI, SPDX Licences, UAT
• Gilles Landais, 2024-12-20: as semantic, we propose also to include the RoR for organization
  • See above -- MarkusDemleitner - 2025-01-20
• 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.

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

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:

• 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):

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

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

That's still waiting for actual records, but that's only a minor technical matter: VizieR will push out records having these RSN.

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

• Sample comment by WikiName
  • Response (by WikiName)

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

• Pierre Le Sidaner, 2025-01-30: I've always found that VOResource didn't have the dedicated field to express the citation of the collection or service. The right way to declare DOIs, the ORCID, is really an important advance.

Data Access Layer Working Group

Data Model Working Group

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
  • Good point. Updated to 4.6, which is from late 2024. -- MarkusDemleitner - 2025-01-20
• MathieuServillat, 2024-12-18: the addition of ROR, along with DOI, ORCID... seems necessary (see Semantics WG comments)
  • See below -- MarkusDemleitner - 2025-01-20

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"?
  • This would immediately make a good deal of the resource records out there invalid, which is probably more than we intend to do, and one might argue we're not allowed to do such a thing in a minor update at all. My take on this is to convince data publishers one by one (for most of them it's probably not horribly hard to migrate) and make this a MUST when we don't break any (maintained) records any more. -- MarkusDemleitner - 2025-01-20
• 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.
  • We probably could do such a thing using RDFa on VOResource. Note that that would only do something for what we push out through OAI-PMH, while most people interact with the Registry using RegTAP, and there things can't be fixed as easily, as the prefix mapping would somehow have to cover VOTable data content, and XML processors often won't even see them. If we expected the outside world to start looking at VOResource, I'd say the RDFa way might be a good investiment of our creativity. As long as nobody external actually does look at VOResource, I'd consider it a bad deal in terms of bang for the (effort) buck. -- MarkusDemleitner - 2025-01-20
• 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.
  • It would be nice if we could be consistent here, but regrettably practicies change over time and will keep changing. Practices in VOResources will to some degree reflect the zeitgeist of when they were added. For RightsURI, we have to deal with legacy URIs and possibly all kinds of other things, and we have to way but either an https URL or a URI scheme to tell clients what it is. I don't think SPDX has asked for a URI scheme, and so it'll have to be the https URI, I'm afraid. Don't like it much myself, as you may guess. -- MarkusDemleitner - 2025-01-20"
• 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.
  • Right. I've put something in, and again, since it seems they're not interested in a URI scheme of their own, I'm asking for full URIs. -- MarkusDemleitner - 2025-01-19

Changes are in VOResource PR #13.

Data Curation & Preservation Interest Group

• Gilles Landais, 2024-12-20: congratulate this version that allows DOI, SPDX Licences, UAT
• Gilles Landais, 2024-12-20: as semantic, we propose also to include the RoR for organization
  • See above -- MarkusDemleitner - 2025-01-20
• 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.

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