| |
| META TOPICPARENT |
name="IvoaResReg" |
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: |
|
<
< | Incremental updates (possibly referenced by revision numbers below) will be made available through the Volute document directory. |
>
> | 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
|
|
<
< |
- 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
|
>
> |
- 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
(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 versionning. I think that building an VR extension from the doc wouln't be easy t all. |
>
> | 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" |
|
<
< | P8:
S2.2:The element elementFormDefault is not in the example, is unqualified the default value? |
>
> |
- 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
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" |
>
> | 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
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 |
|
|
|
|
| G&WS |
|
|
|
|
| RoR |
|
|
|
|
| Semantics |
|
|
|
|
| DataCP |
|
|
|
|
| KDD |
|
|
|
|
| Theory |
|
|
|
|
| TD |
|
|
|
|
| Ops |
|
|
|
|
| StdProc |
|
|
|
|
<--
-->
<--
--> |
