VODataService 1.3: productTypeServed

[Markus Demleitner]

Hi Paul,

On Mon, Nov 25, 2024 at 12:00:35PM +0000, Paul Harrison wrote:
> However, this (along with the 'stay of execution’ on
> DataCollection) does remind me that is was not originally meant to
> be this way. The original design of the registry schema did have as

Perhaps, before the major protagonists retire, we should write a
history of the first 25 years of the VO Registry and dig up what
memories and documents there still are?  I'd say we certainly could
collect a fair number of lessons learnt...

> If this normalisation had been done in the early days as new
> DataServices were created, then the registry name for things like
> DataCollections, Instruments, Facilities would have been the name

While I do agree that data and services need to be separated -- and I
think DDC <https://ivoa.net/documents/discovercollections/> and the
new VODataService 1.2 types DataResource and CatalogResource let
people do this without breaking much --, I think for instruments and
facilities this has been a lost cause; we still don't have enough
buy-in or even tooling to make the operators of facilities and
instruments register themselves, and we don't have the staff to
curate such registrations from within the VO.

I give you it's a charming idea, though.  With the caveat that we'd
have to introduce some persistence tech (presumably an ivoa-managed
publishing registry of instruments and facilities) in order to make
that properly work.  But never mind: This is now clearly outside of
the Registry.

> While it might be too late to save DataCollection, and in any case
> if the actual number of registrations has become vanishingly small,
> perhaps rather ineffectual - it should be remembered that the
> majority registry entries are dominated by rather a small number of
> of providers so a change of direction is not entirely unfeasible.

It's certainly not, and it's been going on for a long time already.
Still, VizieR will most definitely not create an extra 25'000 records
to separate their cone searches from their data collection records.
But if there could be a single cone search service for all of
VizieR's tables and we could have that as an auxiliary capability,
I'd like that a lot for so many reasons.  But that needs work on
both SCS and a minor registry extension for auxiliary capabilities,
and hence it's probably not for VODataService 1.2.

Thanks,

           Markus