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

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

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)

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.

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 versionning. I think that building an VR extension from the doc wouln't be easy t all.

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

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"

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

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.

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

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.

Section 3:

P17 (bottom) see vr:ValidationLevel
P18: identifier: a ref to http://www.ivoa.net/documents/IVOAIdentifiers/index.html might recall how important is this point
after the table:"they describe the resource metadata Description contained"
"XML Schema VersioningPolicies" missing ref
P19: identifierURI: Here is nothing saying to the reader how to set the value of that ID.
P20: "Element creator": useless comment about logos which are introduced later
P23: 1st date comment: URL not readable
P23: 1st date comment: "This includes the the traditional and deprecated"

-- LaurentMichel - 2017-08-21

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

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.