TWiki> IVOA Web>IvoaResReg>VOResource12RFC (2025-02-12, AnneRaugh) EditAttach

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

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

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.
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

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

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

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
  • 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.
I am not confident that I understand what is meant by the change "Adding doi as a recognized source format." I cannot check this.
    • 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.

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


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

Edit | Attach | Watch | Print version | History: r22 < r21 < r20 < r19 < r18 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r22 - 2025-02-12 - AnneRaugh
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback