[EXTERNAL] [BULK] Re: VODataService 1.3: productTypeServed

[Jaffe, Tess {she, they} (GSFC-6601)]

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...

I think this is an excellent idea to add to the Registry road map.  Not likely for the Spring interop but for the not too distant future.  In fact, I think it might be a good idea more broadly, and the 25 year mark is as good an excuse as any.


- - - -
Dr. Tess Jaffe (she/her)
NASA Goddard Space Flight Center, Greenbelt, MD, USA


________________________________
From: registry <registry-bounces at ivoa.net> on behalf of Markus Demleitner via registry <registry at ivoa.net>
Sent: Tuesday, November 26, 2024 2:07 AM
To: WG Registry IVOA <registry at ivoa.net>
Subject: [EXTERNAL] [BULK] Re: VODataService 1.3: productTypeServed

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.




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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fivoa.net%2Fdocuments%2Fdiscovercollections%2F&data=05%7C02%7Ctess.jaffe%40nasa.gov%7Cf7a688c2a5904de2a9ab08dd0df4f5b6%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638682067938873765%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jgmFoNxAtC5B764I5Kxw3%2FR1YcLCfbVY599d049awkw%3D&reserved=0<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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20241126/d251783e/attachment.htm>