VOResource 1.1 implementation

[Theresa Dower]

Hello Registry,


In the interest of not losing momentum on this I've had a chance to play around with some of the proposed changes today, with the test ST registry running on Microsoft IIS and MSSQL server, having RegTAP, OAI, and non-standard search endpoints.


Namely:


* creator and contact/altIdentifier: adding a creator orcid was trivial and did not break ingest and related validation. Modifying our pretty-print resource browsing page to print it was trivial: this is important inasmuch as it does some xml validation separate from ingest. <http://vaotest.stsci.edu/directory/getRecord.aspx?id=ivo://mast.stsci/clash>


* rights/rightsURI: Added to a MAST HLSP service, with rightsURI link the self-hosted MAST data usage page and as the text a summarized acknowledgement text from that link. Did not break ingest. Modifying our pretty-print resource browsing page to print it was trivial: again, important inasmuch as it does some validation.


* We don't have any real restricted services to test interface/securityMethod with. If no one with a real use case steps up I can fudge it in test.


* We don't have any great candidates for interface/mirrorURL either. If no one with a real use case steps up I can fudge it in test.


* The RDF file linked in voresource doesn't exist at the given URL so I haven't looked at that yet, but freetext date/roles are fine in our architecture; we do not test against a controlled vocabulary.


Cheers,

--Theresa




________________________________
From: registry-bounces at ivoa.net <registry-bounces at ivoa.net> on behalf of Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
Sent: Tuesday, February 27, 2018 9:16:28 AM
To: registry at ivoa.net
Subject: VOResource 1.1 implementation

Dear Registry,

Good news: All the reviews for VOResource 1.1 are now in:

http://wiki.ivoa.net/twiki/bin/view/IVOA/VOResource11RFC

Now, we should all be good citizens and actually show additional
implementation expericence before asking the TCG chairs and exec to
finally turn this into a REC; it's not always straightforward to say
what "implementation" actually means for an XML schema like
VOResource, but I'd say registry records using this stuff and RegTAP
(in this case, the 1.1 draft) making it discoverable count.

Looking at the Changelog and comparing this to what practice I'm
aware of, I'd come up with the following list of things I'd like to
see in some resource record out there (ideally being used for
something) before I'm confident we've not messed up:

* creator/altIdentifier (i.e., ORCIDs -- come on, your data providers
  have been waiting for this, haven't they?)
* date/@role (see if you have terms to add to the vocabulary -- it's
  never again going to be as easy as now!)
* service/rights/@rightsURI -- try to declare your data licenses
  machine-readably.  I'm reasonably sure we can cover the normal use
  cases because we're copying DataCite's content model here, but it
  sure would be great to have a bit more experience
* interface/mirrorURL -- do you have mirror services?  VizieR, could
  you perhaps try this for a few of your resources?  Or perhaps for
  Simbad?
* interface/securityMethod -- folks, the time to register your
  access-restricted resources is *now*.  We really want to get this
  right just about now.

Any implementation feedback on this (or, of course, anything else in
VOResource) would be highly welcome.  It'd be great if we could get
VOResource 1.1 approved in Victoria, and having an additional pair of
eyes have a look at at least each of the five points above before
that would be excellent.

Thanks,

           Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20180227/13a8b535/attachment.html>