Discovering Data Collections Within Services Note version 1.0

[Patrick Dowler]

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.

I am hoping to get to this soon, but to be honest it could be at least
"weeks".


On Mon, Feb 15, 2016 at 2:35 PM, Kristin Riebe <kriebe at aip.de> wrote:

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



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20160215/ead2f971/attachment-0001.html>