<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Hello Registry,</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>Namely:</p>
<p><br>
</p>
<p>* 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. <a href="http://vaotest.stsci.edu/directory/getRecord.aspx?id=ivo://mast.stsci/clash" class="x_OWAAutoLink" id="LPlnk152762"></a></p>
<p><br>
</p>
<p>* 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.
<span>Modifying our pretty-print resource browsing page to print it was trivial: again, important inasmuch as it does some validation.</span><span></span><span></span><span></span></p>
<p><span><br>
</span></p>
<p><span>* 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.</span></p>
<p><span><br>
</span></p>
<p><span>* We don't have any great candidates for interface/mirrorURL either. <span>If no one with a real use case steps up I can fudge it in test.</span></span></p>
<p><span><br>
</span></p>
<p><span>* 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.</span></p>
<p><span><br>
</span></p>
<p><span>Cheers,<br>
</span></p>
<p><span>--Theresa<br>
</span></p>
<p><span><br>
</span></p>
<p><span><br>
</span></p>
<p><span><br>
</span></p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> registry-bounces@ivoa.net <registry-bounces@ivoa.net> on behalf of Markus Demleitner <msdemlei@ari.uni-heidelberg.de><br>
<b>Sent:</b> Tuesday, February 27, 2018 9:16:28 AM<br>
<b>To:</b> registry@ivoa.net<br>
<b>Subject:</b> VOResource 1.1 implementation</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Dear Registry,<br>
<br>
Good news: All the reviews for VOResource 1.1 are now in:<br>
<br>
<a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/VOResource11RFC">http://wiki.ivoa.net/twiki/bin/view/IVOA/VOResource11RFC</a><br>
<br>
Now, we should all be good citizens and actually show additional<br>
implementation expericence before asking the TCG chairs and exec to<br>
finally turn this into a REC; it's not always straightforward to say<br>
what "implementation" actually means for an XML schema like<br>
VOResource, but I'd say registry records using this stuff and RegTAP<br>
(in this case, the 1.1 draft) making it discoverable count.<br>
<br>
Looking at the Changelog and comparing this to what practice I'm<br>
aware of, I'd come up with the following list of things I'd like to<br>
see in some resource record out there (ideally being used for<br>
something) before I'm confident we've not messed up:<br>
<br>
* creator/altIdentifier (i.e., ORCIDs -- come on, your data providers<br>
have been waiting for this, haven't they?)<br>
* date/@role (see if you have terms to add to the vocabulary -- it's<br>
never again going to be as easy as now!)<br>
* service/rights/@rightsURI -- try to declare your data licenses<br>
machine-readably. I'm reasonably sure we can cover the normal use<br>
cases because we're copying DataCite's content model here, but it<br>
sure would be great to have a bit more experience<br>
* interface/mirrorURL -- do you have mirror services? VizieR, could<br>
you perhaps try this for a few of your resources? Or perhaps for<br>
Simbad?<br>
* interface/securityMethod -- folks, the time to register your<br>
access-restricted resources is *now*. We really want to get this<br>
right just about now.<br>
<br>
Any implementation feedback on this (or, of course, anything else in<br>
VOResource) would be highly welcome. It'd be great if we could get<br>
VOResource 1.1 approved in Victoria, and having an additional pair of<br>
eyes have a look at at least each of the five points above before<br>
that would be excellent.<br>
<br>
Thanks,<br>
<br>
Markus<br>
</div>
</span></font>
</body>
</html>