registering data collections

[Markus Demleitner]

Hi Pat, Hi Registry,

On Tue, Apr 17, 2018 at 02:12:28PM -0700, Patrick Dowler wrote:
> (context: CADC already has a separate DataCollection record in the
> registry for each collection we serve, ~20 iirc)

Excellent!

> In trying to configure the ivo://cadc.nrc.ca/IRIS data collection with
> related service relationships and aux capabilities I ran into a
> problem: the capability child element is not allowed (schema
> validation exception) and when I looked in the relevant xsd I see that
> it is only allowed in a resource of type Service. The example A.1 is
> actually a resource of type CatalogService (extends DataService
> extends Service) whereas ivo://cadc.nrc.ca/IRIS is a resource of type
> DataCollection (extends Resource). The end of page 6 covers this issue
> and promises that VOResource-1.1 will allow capabilities in
> DataCollection... so at this point I cannot implement aux capablities
> since we used DataCollection.
> 
> The recommendation to use CatalogService in place of DataCollection as
> a stop gap seems to force clients back into service-oriented
> discovery. I have a feeling we would regret making that
> recommendation. Is it sensible to put this note on hold until we have
> VOResource-1.1 and can describe DataCollection resources properly?

The recommendation to use records of type CatalogService is indeed a
stopgap measure -- but I'd argue it's a harmless one.  If you look at
the RegTAP sample queries,
http://ivoa.net/documents/RegTAP/20141208/REC-RegTAP-1.0.html#tth_sEc10,
as well as what actual clients do, the resource type actually is not
used in data discovery queries (which is for the better, as users
even now will not care if something comes from a DataService or a
CatalogService, say).

That is not to say that the resource type isn't important in other
circumstances, e.g., when looking for Authorities, or when VOTT
(http://dc.g-vo.org/VOTT) looks for educational material.  It's just
data discovery in the VO actually means "finding endpoints that let
me use the data", and that translates in talking about capabilities,
not resources as such.

Hence, while I give you that there is an aesthitic advantage to using
DataCollection records, operationally for the forseeable future there
is no difference to using CatalogService records even for data
collections.

On the other hand, VODataService 1.2 (which will introduce
capabilities on DataCollection if all goes to plan) is probably two
years in the future.  By that time, I'd already like to phase out
GloTS (the maintenance of which is a significant effort on my side),
and that obviously can only happen if we have had a stable
alternative for... well, as long as possible.

So -- to me, the tradeoff has been between an operationally
irrelevant aesthetic defect versus allowing as much time as possible
for client writers to migrate to a new, standard infrastructure (as
opposed to the proprietary GloTS).

I ended up on the latter side -- could I persuade you to follow that
assessment?

      -- Markus