VODataService 1.2

[Markus Demleitner]

Dear Registry,

Time for an update on this:

On Thu, Aug 23, 2018 at 01:41:59PM +0200, Markus Demleitner wrote:
> In Victoria, I had promised to start a review of VODataService 1.2.
> My strongest itch in that department is the new STC coverage scheme
> (http://ivoa.net/documents/Notes/Regstc), but there are several more
> points to review.

If you're watching the Volute commits [1] , you've
seen that I've done some edits now and then;  I'm now at a point
where I'd really appreciate some feedback.

I've put a PDF of the current state of affairs to
http://docs.g-vo.org/VODataService.pdf (not different from what you'd
get from Volute).  If you can spare a few minutes, please page
through it and look at

(a) the new use cases in Sect 1.3 -- do you agree with them,
disagree, or have additional ones?  I'd like to avoid sinking
significant amounts of time into things neither I nor someone else
actually care about a lot.

(b) all the little Todo-boxes shown in orange in the left margin.  If
you have opinions on (or, gasp, an urge to do something about) any of
them, again let me or this list know.


What I'd be particularly grateful for: A name for the new data
collection class (sounds like bikeshedding, but I'd say it's not).

Brief background: For Discovering Data Collections, we need a type
that works like CatalogService (can have capabilities) but says "I'm
a Data Collection" (like DataCollection).  Just extending
DataCollection with capabilities isn't great because then
DataCollection and CatalogService have (essentially) the same
children but in a different order, which is at least ugly and
unnecessarily painful in implementation[2].

To evolve things compatibly, our plan in Victoria was to essentially
deprecate DataCollection and entangle a new type with CatalogService,
with the precise semantics of: "A data collection exposed as a part
of another service" ("entangle" as in "probably derive CatalogService
from that other new type).

But now I can't think of a good name for that type.  Just Data?  Try
to be funny and call it ServicedCatalog?  Be boring and a bit ugly
and say it's DataCollection2?

If you have a good idea -- you know where to find me.

Bonus points if you came up with names all the way up to
vr:Resource, somewhat like:

vr:Resource
 |
vs:DataResource ------- vs:DataService
 |
vs:CatalogResource ---- vs:CatalogService

But no, I don't like CatalogResource as DataCollection successor
much, because it's going to be used for things like "Spectra from the
X instrument on the Y telescope", and few people would call that a
Catalogue.  Ah well.


Plan for now: When the new type name/inheritance tree is in, I'd
like to go WD, ideally safely before College Park (where there's
going to be a talk on what's happened since Victoria in
VODataService).  Which, of course, we're only supposed to do if we've
reached WG-internal consensus.  Fortunately, this consensus can be
"We need input from other WGs", so I'd say the presence of Todos
isn't necessarily an indication we're not there yet.

        -- Markus

PS: As always, Help Wanted!


[1] You can subscribe at
http://lists.g-vo.org/cgi-bin/mailman/listinfo/volutecommits)

[2] If you're interested in the details, here's the content models:

DataCollection:

[common] facility*, instrument*, rights*, format*, coverage?, tableset?, accessURL?

CatalogService:

[common] rights*, capability*, facility*, instrument*, coverage?, tableset?

-- so, it's mainly rights and format that keep us from just
inheriting DataCollection from CatalogService in a sound way.  It's a
bit ironic that two items that haven't really been used (properly) in
1.1 rain on our parade here, but there you go.