VOResource12RFC < IVOA

---++ 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:
   * <span data-mce-mark="1">https://ivoa.net/documents/VOResource/20241015/index.html</span>

---+++ Reference Interoperable Implementations

UAT keywords have been in use at GAVO and VizieR for a long time now; see also [[http://dc.zah.uni-heidelberg.de/sembarebro/q/ui/fixed][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):

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

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

<pre>select *
from rr.res_detail
where detail_xpath like '%altIdentifier'
</pre>

(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

<pre>select *
from rr.res_role
where alt_identifier is not NULL
</pre>

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

<pre>select *
from rr.relationship
where related_alt_identifier is not NULL
</pre>

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 [[https://github.com/ivoa-std/VOResource][the source repository]] for how to use stilts to validate your instance documents.

The RofR validator should be updated soon.

<br /><span data-mce-mark="1"><span data-mce-mark="1"><span data-mce-mark="1"><span data-mce-mark="1">%TOC{depth="2"}%</span></span></span></span>

---
---

---++ 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 TWiki.WikiName
      * Response (by TWiki.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

---+++ [[IvoaApplications][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.
The rapprochement with Semantic should also make it possible to improve the content of the subject field in the ROR, as well as fairization.
The document is very clear and easy to read
Very good initiative

---+++ [[IvoaDAL][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 -&gt; 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 inte<strong style="background-color: transparent;">n</strong>ded to allow simple markup
   * Sec. 2.2.4, p.11: remove the trailing comma: 2008-02-22T12:22:34Z<strong style="background-color: transparent;">,</strong>
   * 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/%20abs/2018ivoa.spec.0529H][<span data-mce-mark="1">https://ui.adsabs.harvard.edu/</span> 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: <p>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'?</p>
   * 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: <p>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.</p>
      * 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
   * <p>Sec. 3.1.3-4, p.31:</p> <p>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.</p>
      * 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][<span data-mce-mark="1">https://github.com/ivoa-std/ivoatex/pull/149</span>]] (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][<span data-mce-mark="1">https://github.com/ivoa-std/VOResource/pull/14</span>]] -- MarkusDemleitner - 2025-01-31
-- GregoryMantelet, 2025-01-31
---+++ [[IvoaDataModel][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)" —&gt; 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

---+++ [[IvoaGridAndWebServices][Grid & Web Services Working Group]]

---+++ [[IvoaResReg][Registry Working Group]]

---+++ [[IvoaSemantics][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 &lt;subject&gt; 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 <span data-mce-mark="1">http://www.ivoa.net/rdf/uat/#"</span>, 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., <span data-mce-mark="1">http://www.ivoa.net/rdf/uat/#</span>) 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: <span data-mce-mark="1">https://ror.org</span>), 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.

---+++ [[IvoaDCP][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 <br />VizieR provides already the catalogue DOI using altIdentifier.<br /><br />Possible update in VizieR:
      * extend relationships to link original dataset using DOI (possible but for a small list of catalogues)<br />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.<br /> <p>&lt;relationshipType&gt;isVariantFormOf&lt;/relationshipType&gt;<br /> &lt;relatedResource altIdentifier="doi:10.5270/esa-qa4lep3"&gt;Gaia DR3 at ESA&lt;/relatedResource&gt;<br /> &lt;/relationship&gt;</p>
      * <p>Complete the bibcode of the reference article with the article DOI</p>
---+++ [[IvoaEducation][Education Interest Group]]

---+++ [[IvoaKDD][Knowledge Discovery Interest Group]]

---+++ [[IvoaOps][Operations Interest Group]]

---+++ [[IvoaRadio][Radio Astronomy Interest Group]]

---+++ [[IvoaSS][Solar System Interest Group]]

---+++ [[IvoaTheory][Theory Interest Group]]

---+++ [[IvoaVOEvent][Time Domain Interest Group]]

---+++ [[IvoaStdsDocsProc][Standards and Processes Committee]]

---

---++ TCG Vote : Vote_start_date - Vote_end_date

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.

| Group | Yes | No | Abstain | Comments |
| TCG | | | | |
| Apps | x | | | |
| DAL | x | | | |
| DM | | | | |
| GWS | | | | |
| Registry | | | | |
| Semantics | | | | |
| DCP | x | | | |
| Edu | | | | |
| KDIG | | | | |
| Ops | | | | |
| Radio | | | | |
| SSIG | | | | |
| Theory | | | | |
| TD | | | | |
| &lt;nop&gt;StdProc | | | | |

---

<br /> &lt;!--&lt;/p&gt; &lt;ul&gt; &lt;li&gt; &lt;ul&gt; &lt;li&gt; Set ALLOWTOPICRENAME =&lt;span class="WYSIWYG_PROTECTED"&gt; IVOA.TWikiAdminGroup &lt;/span&gt; &lt;/li&gt; &lt;/ul&gt;&lt;/li&gt; &lt;/ul&gt;--&gt;
This topic: IVOA > WebHome > IvoaResReg > VOResource12RFC
Topic revision: r13 - 2025-01-31 - GregoryMantelet