productTypeServed in VODataService

[Markus Demleitner]

Dear Registry folks,

Remember Hendrik's talk in Bologna,
https://wiki.ivoa.net/internal/IVOA/InterOpMay2023Registry/hendrik_heinl.pdf?
The basic problem he ran into is that our services and data
collections don't say what sort of product types they contain.
Traditionally, people have just enumerated all SSAP services if they
wanted to find spectra (say).  With things like Obscore or Time
Series in SSAP, not to mention SIA1 vs. SIA2, that hasn't been good
enough for a long, long time now.

However, since Datalink 1.1 (i.e., Dec 15th), the product-type
vocabulary http://www.ivoa.net/rdf/product-type/ is official, and
that makes it reasonably simple for us to add an attribute
productTypeServed to our resource records to address this problem.
This is what VODataService PR #1,
https://github.com/ivoa-std/VODataService/pull/1, tries.

I'm attaching the product type at the root of the VODataService
service resource type hierachy, DataService, which means that all
(modern) VODataService resource types get a that attribute.  I think
that's perfectly reasonable and actually necessary, as our various
DAL product-delivery services use CatalogServices, too.

Of course, that's only a first step.  Let me sketch a roadmap for how
to make this useful:

(1) Once something like that is in VODataService, add a RegTAP table
(or column with a hash-separated list, but then it's harder to
operate with vocabularies) mapping product types to ivoids.

I think we need to seed that table with sia, sia2 -> image, ssap ->
spectrum at the RegTAP operator level, or it won't get off the
ground.  But the service operators can override that seeding, of
course.

(2) Then we'll have to go canvassing a bit and get the obscore
operators to register their obscore collections (I think we need a
note describing how to do that, which would then be obsoleted by the
next obscore release).  That's something we *really* want to do
anyway; the metadata on the TAP services (which we currently use for
obscore discovery) is far too poor to properly work for obscore even
without product types (just think coverage).

(3) In parallel, we ought to exploit this to help the global
discovery in pyVO along (https://github.com/astropy/pyvo/pull/470; I
really need to do a bit more work there, and help is most welocme).

Opinions?  Thoughts?  Ideas?

Thanks,

           Markus