VOResource 1.1 internal Working Draft

[Menelaus Perdikeas]

Hi Markus, 

Some initial thoughts / questions on the document. Pages refer to the PDF document you linked. 

[1] 
I noticed that the VOResource example given in pg. 7 (in the PDF file) is in fact XSD-invalid (this also applies to the previous version of the document). I attach the original version and the modified one (that's XSD valid). You may diff them to see the differences. (the date problem is related to the PDF generation which introduces an em-dash where the original *.tex file only has a hyphen, but the other issues are real). 

[2] pg 8: mangled line numbers on items 3 and 7 

[3] pg.8: I am not sure it is appropriate to offer "SQL databases" as an example of non-XML aware software. E.g., PostgreSQL is fully XML and in fact XSD-schema and namespace-aware and can resolve prefixes just fine at least as far back as 9.2. "older SQL databases" might be best. Also, in the same paragraph, and in order to clarify, I would enhance: 

"will use these prefixes rather than the full namespace URIs" 

to: 

"might be unable to properly de-reference / resolve the namespace prefixes to their namespace URIs. In XML prefixes are not significant; instead, it is only the namespace URI that matters (and not the prefix one binds it to). However, to accommodate such legacy software, certain IVOA recommendations (e.g. RegTAP) require that specific well-known prefixes be bound to well-known IVOA namespace URIs. This allows older / simpler software to just use the prefixes as an 100% reliable alias for the namespace (as opposed to just an arbitrary key that one has to cross-reference to yield the ultimate, normative namespace URI)." 

... but on second thought I am not sure whether the above clarifies or just belabors the point. 

[4] pg. 9 "a small schema that defines a global element ri:Resource of default type vr:Resource ". I am not sure "default type" exists as a concept in XML/XSD. I would change that to "base type". 

[5] you note in connection to the schema changes that: 

"I've taken care that VOResource 1.0 documents don't become invalid. 
Paul's new schema versioning scheme also helps." 

I am bit confused by this statement. Are you saying: 

[5.a] any IVOA resource that's valid against the VOResource 1.0 XSD schema should also be valid against the 1.1 XSD schema 
... or ... 
[5.b] validators should check the resource version attribute (Pauls' new schema versioning schema?) and pickup the right XSD schema to validate it against 

? 

[6] I note that a number of type definitions (e.g. vr:Type , vr:ContentLevel ) are now removed and are tracked by non-XSD controlled vocabularies. I am not sure how that's supposed to work with XSD validators in the Java ecosystem. E.g. when the vr:Type was defined in the XSD schema, validation was handled automatically, I am not sure if this is possible now. Also, in the same connection, some of the links provided are not working (e.g. http://www.ivoa.net/rdf/voresource/content_level. ) 


Cheers, 
Menelaus. 




From: "Markus Demleitner" <msdemlei at ari.uni-heidelberg.de> 
To: registry at ivoa.net 
Sent: Tuesday, April 26, 2016 3:10:14 PM 
Subject: VOResource 1.1 internal Working Draft 

Dear Colleagues, 

First a word from our sponsors: 

========================================== 
Time is running out for Cape Town. 
If you have anything Registry-related 
to report (and this includes wishlists) 
please act *now* and tell 
msdemlei at ari.uni-heidelberg.de 

Thank You. 
========================================== 

Then, I've prepared an internal working draft for VOResource 1.1, 
available from volute (trunk/projects/registry/VOResource) and in 
formatted form from 

http://docs.g-vo.org/VOResource.pdf 

I had expected this to be a short, little thing, but the list of 
changes has become fairly long, so in preparations for (hopefully 
lively) discussions in Cape Town, I offer a short Q&A here. 


Why? 
==== 

Main reason: VOResource should be able to communicate DOIs (and 
ORCIDs); also, since it's hard enough to make people provide good 
metadata in one scheme (let alone two) VOResource should be as 
aligned as possible (retaining backward compatibility) with 
DataCite's core metadata scheme. 

Secondary reason: There have been a few baked-in vocabularies (for 
dates, relationship types, content levels, content types). I'd 
rather manage these vocabularies independently of the standard, more 
like SAMP mtypes or perhaps datalink prodcut types. 


What? 
===== 

I've taken care that VOResource 1.0 documents don't become invalid. 
Paul's new schema versioning scheme also helps. There's one really 
new element: altIdentifier, currently possible in Resource and 
Creator (where it could take DOIs/bibcodes or ORCIDs, respectively). 

The second big change is conceptual: Whereas VOResource 1.0 claims 
it's just a serialisation of Resource Metadata, we adopt DataCite 
core as a second "upstream". 

A bit more minor is removing the spin towards having interfaces with 
several different versions within one capability; in VO practice, 
versioning has moved to standardIDs, as has service discovery (which 
was still envisioned to use capability/xs:type then years ago). 

Here are other changes from the changelog: 

* Adding a version attribute to vr:Resource for compliance with XML 
Schema Versioning Policies 

* The vocabulary of date/@role is now managed as a separate 
resource; DataCite terms have been added to it, and the old 1.0 terms 
deprecated. 

* The vocabulary of relationshipType is now managed as a separate 
resource; some DataCite terms have been added to it. 

* Service/rights now is free text rather than the tree-term 
enumeration. In addition, it now has a rightsURI attribute, 
DataCite-style. 

* content/type is now xs:token rather than a special restriction. 
The vocabulary is now managed as an external resource. 
Consequently, the vr:Type type vanishes from the XSD. 

* content/level is now xs:token rather than a special restriction. 
The vocabulary is now managed as an external resource. 
Consequently, the vr:ContentLevel type vanishes from the XSD. 

* Now discouraging fixing standardID in VOResource extensions. 
Also, removed indication that capability/@xsi:type should be used for 
service discovery. 

* Now allowing a Z timezone marker in UTCTimestamp, indeed 
discouraging non-timezone use. This is in line with OAI-PMH use. 
Therefore, while technically changing the schema such that legacy 
clients might be confused, we do not expect incompatibilites. 

* resource/description and capability/description are now xs:string 
to enable simple plain text markup. 

* Consequently, removing 1.0 default on interface/@version. 

* Added advice about the use of creator.name 

* Removed SOAP/WSDL example and a bit of the accompanying language. 

* Section 3 needed some refactoring since the schema documentation 
is now generated from the schema document. To accomodate this, some 
text manually embedded within the schema documentation had to be moved 
out of the generated material or removed. 

* While we still reference RM, it is now no longer informally 
authoritative for VOResource (we'd have to change RM before we change 
VOResource otherwise) 

* References to the RM terms in the metadata definition dropped 
(could add support in ivoates/schemadoc if we want them back). 

* Strongly advising the use of the vr: prefix, removing some 
duplicated advice regarding prefixes 

* Removed example for deriving a SIA capability (this is now 
in the document repository) 

Most of these changes correspond to individual commits. See 

svn log http://volute.g-vo.org/svn/trunk/projects/registry/VOResource 

if you want to dig in or check the actual textual changes. 


And that's it? 
============== 

Unfortunately, no. There's still some topics that I think we need to 
work out (assuming the proposed changes find acceptance). 

Here is a list of topics I'd like to discuss: 

* Relax IdentifierURI? There's a todonote in the text discussing 
what I think we should do. 

* Unify party-like entities (creator, contributor, publisher, contact) 
to a single type? 

* Do we want DaCiMeta contributorType? This would require defining a 
new type for contributor so we can have an @type (or @role) 
attribute. 

* What about securityMethod? Do we now have a better idea how this 
might become useful? Grid? 

* Language: Should VOResource say content must be in English? Or is 
that something Registry Interfaces should say ("if you want your 
stuff to be in the VO Registry...")? Or do we keep ignoring the 
issue? 

* Use URLs instead of terms from hardwired RDF vocabularies throughout? 

* What procedure do we adopt for vocabulary changes? 

* Should more things have altIdentifiers? 

* Recommendations on what to do with "should be drawn from the IAU 
Thesaurus"? 

* Should we define a naming convention as to US/British spelling 
(there's "Organisation", but my impression is that most tech names in 
the VO are US spelling)? 

* What about disallowing multiple accessURLs right now? Last time I 
checked, no actual Registry record used that, so technically we'd not 
even be invalidating anything existing with that schema change. 

* Have some way to mark up mirror/main site in interface so people 
can manage mirrors in the VO Registry? 


What next? 
========== 

Given this long list, I'm thinking of devoting an entire Registry 
session to the VOResource makeover (of course, if people hand in lots 
of additional requests for time in the Registry sessions, that's not 
going to work out, but right now it seems perfectly feasible). 

It would be great if as many people as possible could come there with 
opinions and ideas. If there was something you always wanted in 
VOResource, this is your chance. 

Remember: The next change to VOResource might be another then years 
away. 

After Cape Town, I'd like to quickly make this an actual Working 
Draft. It'd be great if the really big issues could be out of the 
way by then, and perhaps we can have RFC before Trieste, so we could 
already discuss RFC results there. 


You're serious? 
=============== 

Well, yes. I feel a bit bad that these lists have become so long, 
but then VOResource was, in its core, devised about 10 years ago. 
Much in the VO and beyond has changed, and I have to say Kudos to Ray 
and company that all that I think really needs attention is this 
list of relatively minor points. 

Thanks, 

Markus 

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20160427/527cdec6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example-voresource-v0.xml
Type: application/xml
Size: 1983 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20160427/527cdec6/attachment-0002.wsdl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example-voresource-v1.xml
Type: application/xml
Size: 2088 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20160427/527cdec6/attachment-0003.wsdl>