VOResource 1.1 Proposed Recommendation: Request for Comments

VOResource 1.1 is an update to the basic schema for resource records in the VO; the most salient rationale is improved interoperability with DataCite (but in total there's 1 1/2 pages of changes).

The latest edition of VOResource 1.1 can be found at:

• http://ivoa.net/documents/VOResource/20170425/index.html

Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory; a formatted version as of the current commit should be available at http://docs.g-vo.org/VOResource.pdf.

Reference Interoperable Implementations

VOResource 1.1 takeup until May 2017 has been discussed in a talk at the Shanghai interop.

Features relevant for discovery can be tried out in the GAVO-operated RegTAP registries, which already implement a draft version of RegTAP 1.1; TAP access URL is http://reg.g-vo.org/tap.

Implementations Validators

VOResource 1.1 records can be validated using standard XSD tools.

Support for VOResource 1.1 validation in the RofR should come soon; this will probably not yet include validation of vocabulary-constrained elements, but this should be easily addable.

---

Comments from the IVOA Community during RFC/TCG review period: 2017-06-01 through 2017-07-15

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)
• My comment is about the connections between DataCite and the new VOResource schema. Is the goal that one should be possible to map between the two standards? One limitation that I have noticed with DataCite and compatibility with astronomy data resources is with the relatedIdentifiers type. In DataCite, a relatedIdentifier must have a relatedIdentifierType associated with it, which come from a fixed list. In VOResource there is the vr:relationship type, which has a relatedResource element that appears to always be a vr:ResourceName, which as I understand it is always an IVOA identifier URI. This represents an incompatibility with DataCite in two ways. One, an IVOA identifier URI is not one of the types in the relatedIdentifierType enumeration in DataCite. Two, DataCite allows a wider range of types of identifiers that may be related to the current described resource. Has there been any thought of trying to get astronomy-specific identifier types into the allowed list for DataCite or of expanding the types of identifiers that can be specified as a relatedResource for the vr:relationship type in the VOResource schema? -- SarahWeissman - 2017-06-07

• • This was discussed and resolved on the mailing list: http://mail.ivoa.net/pipermail/registry/2017-June/005194.html -- IVOA.Markus Demleitner - 2017-08-31

---

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

(page numbers refer to the PDF)

P3 "Syntax Notation..." end of penultimate section: "the version of the document schema repository" (better to avoid confusion between standard and XML documents)

• Indeed -- IVOA.Markus Demleitner - 2017-08-31

P4 after the citation it is said that VR does not "describe how the terms and values should be encode" and six lines ahead that the document "provides a concrete encoding of the resulting metadata model." The scope of what is encoded here could be clearer.

• The language with "terms and values" refers to RM (the resource metadata document) as opposed to VOResource itself; what this is trying to say, essentially, is: "VOResource provides the technical details (terms and values) that RM has left open". I'm not quite sure how to improve this passage to perhaps make that clearer. Hints are welcome. -- IVOA.Markus Demleitner - 2017-08-31

Section 2:

General remarks: It is sometime difficult to make a clear distinction between what is normative and what is general consideration on XML schemas or VO versioning. I think that building an VR extension from the doc wouln't be easy t all.

• I'd like to avoid doing a complete rewrite of major sections of the document without a clear need in a point version of the document. So, while I'm happy to try and fix specific issues, I'm afraid a redesign to make this part more accessible is a bit beyond the scope of this undertaking. -- IVOA.Markus Demleitner - 2017-08-31

The schema of VR extensions can be either in the VR core or in specific XML documents. It would be nice to give a tip for getting the list of available extensions and for locating their schemas (in sec 2.2.5?).

• I'm not aware of any mechanism that would let you search explicitly for "VOResource extensions"; at least StandardsRegExt, which would be the obvious candidate, doesn't have that. So, if this were found an important use case, I guess we'd have to touch StandarsRegExt. The list of registry extensions endorsed by the IVOA at the time of writing is given in the list of related standards in sect. 1.1. -- IVOA.Markus Demleitner - 2017-08-31

P7:
S2: item 2: A pointer to the allowed vocabulary would be nice (ref to section 3.1.4?)
S2:item 5: The VOResource pointer seems to refer to the resource itself, not to another one.
S2:item 7: reference to line 47ff (typo)
S2.1:last paragraph: missing reference to the "versioning policy"

• ad item 2: as people can in principle define whatever types they desire, there is no closed list of xsi:types; we could say something like "try 'select distinct res_type from rr.resource' in a RegTAP service to see what's in use", but I have a feeling that's making matters even worse. Sect. 3.1.4 is on validationLevel in this copy, so you probably wanted to point somewhere else -- the xsi:type thing is somewhat explained in 2.2.6, so I've added a "as discussed in...". -- IVOA.Markus Demleitner - 2017-08-31
• ad item 5: good catch; this should have been line 17. Fixed. -- IVOA.Markus Demleitner - 2017-08-31
• ad item 7: are you objecting the ff after 47? That's supposed to mean "following lines". Now that you mention it I'm not sure any more if that's common in English-speaking literature. Native speakers, help! -- IVOA.Markus Demleitner - 2017-08-31
• Versioning policies reference: I've still not given up hopes that the versioning policies will become an endorsed note before VOResource becomes REC (hint, hint). Since I'd rather avoid referencing PENs, this will remain open so I get an error message for it. -- IVOA.Markus Demleitner - 2017-08-31

P8:
S2.2:The element elementFormDefault is not in the example, is unqualified the default value?

• Are you referencing the opening example in sect. 2? That's an instance document, but elementFormDefault="unqualified" is only (and can only be) given in the schema (it roughly says: the names I'm defining in the following are outside of any schema, and I can pull that off because the elements are local). If you're referencing another example, could you be specific what it is? -- IVOA.Markus Demleitner - 2017-08-31

P9:
S2.2: Double reference for list items ("corresponding to the section.... in RM" a after "these documents are defined in...")
S2.2: item 1: Identity meta data are not grouped in one block: why are they in a flat list?
S2.2: item 5: A quality flag in the example might help.

• I don't the the "double reference" part and can't see what's wrong here. The observation about title, shortName, and identifier sitting in different parent elements is correct. You're probably right that this is suboptimal design, but it's too late to change that now. I've added a validationLevel element to the resource itself as an example for the quality-level metadata. In actual use, these probably make a lot more sense on capabilties than on whole resources, but for the sake of example, this may do. -- IVOA.Markus Demleitner - 2017-08-31

P14:
A table listing both standard capabilities an interfaces would be appreciable, for instance in place of the WSDL considerations.

• I wouldn't miss the WSDL stuff either, but I don't think we should drop it entirely even in the text (I could be convinced otherwise, though). As to listing the capability and interface types: again, I don't think we should tie this document to a specific set of extensions, as I hope it's longer-lived than them. What I think could be possible is an extension of Theresa's effort RegistryNamespaces or Dave's one at DataTypes20170804. I don't think it would be seriously wrong to reference such a thing in a footnote and hope it'll be maintained. Should we? -- IVOA.Markus Demleitner - 2017-08-31

P15:
Top item 2: is "avoiding <choice>" a good practice or a SHOULD statement? An snippet showing how working around <choice> would help.
After the item list: an example showing the 2 derivation modes would help as well.

• "avoiding choice": By the "It is recommended" above the enumeration element I'd say it's a SHOULD statement. As to an example: VOResource doesn't do that unless I'm missing something. So I'm now tentatively pointing towards VODataService's data type system. I feel a bit bad about it because I really want to get rid of that, too. The derivations modes are discussed in the following text, and I've added some words pointing to where the techniques have been used in VOResource.

Section 3:

P17 (bottom) see vr:ValidationLevel

• Fixed in schema. Thanks. -- IVOA.Markus Demleitner - 2017-08-31

P18: identifier: a ref to http://www.ivoa.net/documents/IVOAIdentifiers/index.html might recall how important is this point

• That's technically difficult because that piece is directly generated from the schema, and I don't want to have BibTeX markup in there. I could have another reference to the doc in the opening or closing prose, but I'm not convinced that would help the document. -- IVOA.Markus Demleitner - 2017-08-31

after the table:"they describe the resource metadata Description contained"

• Gone, thanks. -- IVOA.Markus Demleitner - 2017-08-31

"XML Schema VersioningPolicies" missing ref
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.

• Well, this is the description of a type, not of a concrete element or attribute. Hence, there's little I can say except "this simply points to a registry record". Whether that's for a publisher or another service depends on what the type is used for. -- IVOA.Markus Demleitner - 2017-08-31

P20: "Element creator": useless comment about logos which are introduced later

• Fair enough; moved the language about first occurrences to the logo element rather than creator itself. -- IVOA.Markus Demleitner - 2017-08-31

P23: 1st date comment: URL not readable
P23: 1st date comment: "This includes the the traditional and deprecated"

• Fixed. -- IVOA.Markus Demleitner - 2017-08-31

-- LaurentMichel - 2017-08-21

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Comments on the PR 1.1 VOResource 1.1 2017-04-25 document PDF version and the html version:

page 7 : not sure the line numbers fit the content of the example provided. The line numbers appear in PDF, but not on the html version of the document.
errors and typos in line numbers appear as 5f , 47ff...

Fig. 1 the architecture diagram is just a Specimen. Should be updated to show the IVOA specs related to VOResource ...

Section 2.2 defines clearly how to use vr:Interface in capability but a real example in XML would be very welcome.

Subsection 2.3.2 : Footnote (3) should mention the xml schemata' page at http://ivoa.net/xml/index.html to show the xml schemata extended for VOResource in practice

Page 18:
Element identifier : use the font for types as in xs:token for vr:IdentifierURI for best reading

Missing reference (?) for "XML schema versioning policies"

3.1.2 Curation Metadata
Easier reading could be provided by grouping the elements and types descriptions in subsubsections as for instance
a) vr:Curation Metadata elements
b) Vr types involved for curation
b.1) vr:Resource Name type
b.2) vr:Creator type
etc ...
this will help readers of the html version very much

p.20 a logo need only be provided ...--> a logo needs only ... ?

• Definition of VOResource vocabulary terms.

The list mentioned in the specification will be available soon under http://ivoa.net/, the current link is broken but the 3 vocabulary files can be accessed currently under http://docs.g-vo.org/vocab-test
There are several files for allocating a value to VOresource element fields :
- content_level
- content_type
- date_role
- relationship_type

Theses terms are defined for the scope of the VOResource usage.
Having a few examples of VOresources records using the main vocabulary terms would help to figure out the relevance.

By externalising the literal values expected in VOresource documents, we may allow various dialects of VOresource v1.1 to co-exist in the VO ecosystem if we do not synchronize the version of the standard ( V1.1) with the version of the vocabularies used by VOResource.

I suppose the validators for VOResource1.1 XML records operate for checking the validity of terms defined in the vocabulary and then this implies that the vocabulary is also versionned as belonguing to the VOResource 1.1 spec.

The relationship_type literals rely on the current version of the DataCite vocabulary. what kind of synchronicity do we expect with the Datacite vocabulary?

While validating the registry records produced, it would be interesting to store the statistics for the terms used belonguing to these vocabularies.

If the approved vocabulary has to stick to some version of the specification, the XML schema for these terms could also be provided in addition to RDF TTL. and then this can be checked and validated in an XML parser.

-- MireilleLouys - 2017-09-01

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery in Databases Interest Group

Theory Interest Group

Time Domain Interest Group

Operations

Standards and Processes Committee

---

TCG Vote : TBD through TBD

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

Group	Yes	No	Abstain	Comments
TCG
Apps
DAL
DM
<nop>G&WS
<nop>RoR
Semantics
<nop>DataCP
KDD
Theory
TD
Ops
<nop>StdProc

---

<!--
* Set ALLOWTOPICRENAME = TWikiAdminGroup
-->
<!--
* Set ALLOWTOPICRENAME = TWikiAdminGroup
-->