<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Hi Markus,</div><div><br data-mce-bogus="1"></div><div>Is there an XSD schema&nbsp;for this VOResource 1.1 draft uploaded somewhere that one might be able to `diff` against: </div><div><br data-mce-bogus="1"></div><div>http://www.ivoa.net/xml/VOResource/VOResource-v1.0.xsd</div><div><br data-mce-bogus="1"></div><div>?</div><div><br data-mce-bogus="1"></div><div>Doing a quick&nbsp;scan of the document I&nbsp;failed to identify&nbsp;any URL for the XSD. </div><div><br data-mce-bogus="1"></div><div>Cheers,</div><div>Menelaus.</div><div> </div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__">From: "Markus Demleitner" &lt;msdemlei@ari.uni-heidelberg.de&gt; To: registry@ivoa.net Sent: Tuesday, April 26, 2016 3:10:14 PM Subject: VOResource 1.1 internal Working Draft </div><div> </div><div data-marker="__QUOTED_TEXT__">Dear Colleagues, First a word from our sponsors: &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ========================================== &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Time is running out for Cape Town. &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;If you have anything Registry-related &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;to report (and this includes wishlists) &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;please act *now* and tell  &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;msdemlei@ari.uni-heidelberg.de &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Thank You. &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ========================================== 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&amp;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). &nbsp;I'd rather manage these vocabularies &nbsp;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. &nbsp;There's one really new element: altIdentifier, currently possible &nbsp;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. &nbsp;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. &nbsp;This is in line with OAI-PMH use. Therefore, while technically changing the schema such that legacy clients &nbsp;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. &nbsp;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. &nbsp;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. &nbsp;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? &nbsp;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? &nbsp;This would require defining a new type for contributor so we can have an @type (or @role) attribute. * What about securityMethod? &nbsp;Do we now have a better idea how this might become useful? &nbsp;Grid? * Language: Should VOResource say content must be in English? &nbsp;Or is that something Registry Interfaces should say ("if you want your stuff to be in the VO Registry...")? &nbsp;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? &nbsp;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. &nbsp;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. &nbsp;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. &nbsp;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, &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Markus </div></div><PRE>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.

</PRE></body></html>