<div dir="ltr"><div>I intend to comment on this as the aux records are something I don't grok yet but do are about... but I will wait until I can clean up our registered data collections and then try to cross-link service metadata. We do operate few services that cross many collections and that makes our services hard to find, presumably.<br><br></div>I am hoping to get to this soon, but to be honest it could be at least "weeks".<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 2:35 PM, Kristin Riebe <span dir="ltr"><<a href="mailto:kriebe@aip.de" target="_blank">kriebe@aip.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Markus & Registry,<br>
<span class=""><br>
> meaning -- there's some leeway. But really, if you change a service<br>
> to move from a single-instrument archive (with the respective metadata<br>
> like "observed at instrument", "PI is XY", and a matching<br>
> description) to a thematic archive (with the respective<br>
> metadata like "multiple instruments", "publisher is creator", and a<br>
> description of the scope of the collection archive), I'd say it's a<br>
> different resource in almost all cases, so it should get a new<br>
> registry record and hence a new identifier.<br>
<br>
</span>Okay, so in principle you are saying that service-only records<br>
(publishing multiple data sets) are usually very different from<br>
service-descriptions within a data+service record?<br>
I can see that the descriptions would be different, since the combined<br>
record would probably concentrate more on the description of the<br>
published data ("observed at instrument" is data-related metadata), and<br>
the service-only record would concentrate of course on the service<br>
descriptions. I guess I have to look at more example records to get a<br>
better impression of the big picture.<br>
<span class=""><br>
>> That second or third dataset could also be a new release/updated<br>
>> version. Or is there some other infrastructure already set up for<br>
>> versions of datasets?<br>
><br>
> Well, that's a bit orthogonal to the question here. In principle,<br>
> it's possible to register each release separately and then switch the<br>
> assoicate discovery service (the main capability) between a, say,<br>
> "current" and "known-broken-archived", so this would help flexibly<br>
> support all kinds of schemes that keep multiple versions of data<br>
> collections alive; but exactly because I think the proposed discovery<br>
> scheme can essentially accomodate almost all ways to do this, this is<br>
> the wrong place to figure out what's a good idea in that particular<br>
> business and what is not.<br>
<br>
</span>Ok, discussion on this postponed. I did not intend to start a new thread<br>
here, I was merely curious.<br>
<span class=""><br>
>> existing services or validators, but would you really want to have that<br>
>> aux-thing inside the standardId in the long run?<br>
><br>
> Yes -- I maintain this is a completely valid, and indeed intended,<br>
> use of of what StandardsRegExt introduced the standard keys for.<br>
<br>
</span>Since no one else is shouting out loud, and I haven't managed to study<br>
the StandardRegExt-Document yet, I trust that you know what you are<br>
doing. :-)<br>
<span class=""><br>
>>>> * multiple auxiliary capabilities [...]<br>
</span><span class="">> There's also a minor technical point: What we would *really* want<br>
> here is relationships between *capabilities*, i.e., not only should<br>
> the source be a capability element, so should, in order to be true to<br>
> the theory, the target. We don't really have a precendent for<br>
> referencing into resource records (except for StandardsRegExt keys,<br>
> which are in a whole different ballpark in that respect), and<br>
> building one for something that in my view is definitely among the 20%<br>
> functionality that take 80% of the work seemed unwise to me.<br>
><br>
> So, yes, collection discovery as proposed here is an 80% solution.<br>
> But it does solve these 80% with 20% of the effort, and my feeling so<br>
> far is that the 80% solved probably are all anyone is ever going to<br>
> want to use.<br>
<br>
</span>Okay, if this is something that people probably won't use, then the<br>
current version will be enough. I guess if the need arises, one can<br>
discuss again about referencing from capabilities to capabilities in<br>
other records or something like that for an updated version of the note.<br>
<span class=""><br>
> My proposal at this point is: The current Note is easy and fairly<br>
> cheap to try out, and I hope the major TAP operators will push out<br>
> such records fairly soon (I'll push out some more too, soon). If we<br>
> really see some important use case's requirements are clumsy to<br>
> satisfy with this, there's no big damage done if a (on the VOResource<br>
> level) minor correction becomes necessary later.<br>
<br>
</span>Fair enough.<br>
<span class=""><br>
>>> As to cleanliness and elegance -- well, that's for a good part in the<br>
>>> eye of the beholder. To me, cleanliness and elegance in the Registry<br>
>>> by now are largely measured in "how hard is it to get the registry<br>
>>> operators to actually do it?"<br>
>><br>
>> It's a pity that it has to be reduced to that. But if that's the case,<br>
>> then I can see no alternatives to your approach.<br>
><br>
</span><span class="">> But<br>
> well, certainly efficiency is an unashamed element of elegance, no?<br>
<br>
</span>Well, I am not very practiced in really writing something efficient -<br>
but some of the most efficient codes I have seen were really ugly in the<br>
sense of readability, and probably had some beauty in that. ;-)<br>
But, as you said, it's in the eye of the beholder, so let's not get too<br>
philosophical here.<br>
<br>
I think we discussed my main issues, so if everyone else is fine with<br>
the current state of the discovery note, I'll stop here. I think it is a<br>
very useful document, and though I have some doubts about how some<br>
things are done or have to be done, it is better to have a note<br>
explaining a way to handle data discovery than having nothing.<br>
<br>
Cheers,<br>
<br>
Kristin<br>
<br>
--<br>
-----------------------------------------------------------------<br>
| Dr. Kristin Riebe<br>
| eScience & GAVO<br>
<span class="">|<br>
| Email: <a href="mailto:kriebe@aip.de">kriebe@aip.de</a><br>
| Phone: <a href="tel:%2B49%20331%207499-377" value="+493317499377">+49 331 7499-377</a><br>
| Room: B6/25<br>
</span>-----------------------------------------------------------------<br>
<span class="">| Leibniz-Institut für Astrophysik Potsdam (AIP)<br>
| An der Sternwarte 16, D-14482 Potsdam<br>
| Vorstand: Prof. Dr. Matthias Steinmetz<br>
|<br>
</span>| Stiftungsverzeichnis Brandenburg: 26 742-00/7026<br>
-----------------------------------------------------------------<br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div>
</div>