VODataService 1.3: productTypeServed

[Paul Harrison]

> On 19 Nov 2024, at 12:36, Markus Demleitner via registry <registry at ivoa.net> wrote:
> 
> element for our service resources that declares that a data
> collection (or service) has datasets of a certain type, denoted as
> per <https://urldefense.com/v3/__http://www.ivoa.net/rdf/product-type__;!!PDiH4ENfjr2_Jw!HtnvR-gDHdinPQRobQvLQZdNaX4LIO_hcyGlHdSIyAGULF3UdNl3wTIfeKh-BUc9TX-N9Eu6DgF6fhBjcWkpTExDjQ$ [ivoa[.]net]>.  If you have more than
> type of dataset, have more than one element.
> 
> The plan is that this should replace the proxy constraint via service
> standardIds ("spectra?  SSAP!") relatively soon, as that proxy just
> doesn't work well any more, what with obscore and of course the
> upcomping DAP.  I think we can have a fairly smooth transition by
> telling RegTAP operators to fill productTypeServed based on the
> protocol when it is missing.

It is welcome that this signals a move away from a “service-oriented” view of the registry that has, unfortunately, become the most prevalent way of thinking about registry content. 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 a principle that the DataCollections and the Services that were used to access them were registered separately with appropriate Relationships set up. This normalisation would make it easier to create searches that were looking for a particular dataset. Unfortunately in the actual schema design that evolved, the separation was not as clean as it could have been, DataCollection had an optional Catalog and an accessURL - which made seem a bit too specific for just registering the data collection - and DataService also had Facility, Instrument and Coverage, which meant that you did not have to register the DataCollection to specify those things.

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 that should be used in queries and some of the vocabularies that are being developed with the multiple synonyms for such things would not be necessary (for VO related contexts at least - they could still be useful in other contexts).

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.

Paul.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20241125/a3f6a597/attachment.p7s>