VODataService 1.3: productTypeServed

[Markus Demleitner]

Dear Registry folks,

I have recently uploaded a working draft for VODataService 1.3; I
have talked about that at the Sydney interop
<https://wiki.ivoa.net/internal/IVOA/202404InteropRegistry/product-type-served.pdf}>,
and since no further requests for changes to VODataService have come
up since then, Renaud and I thought it's time for a WD.  Here it is:

https://ivoa.net/documents/VODataService/20241113/

The change in there is relatively straightforward: There is a new
element for our service resources that declares that a data
collection (or service) has datasets of a certain type, denoted as
per <http://www.ivoa.net/rdf/product-type>.  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.

Meanwhile, at the Interop the old topic of telling theory from
observation data came up again
<https://wiki.ivoa.net/internal/IVOA/InterOpNov2024DAL/DAL_at_IRSA_Laity.pdf>.
I think it would be straightforward to add another element,
dataSource perhaps, that would declare that, re-using the terms
introduced in SSAP:

survey
  A survey dataset, which typically covers some region of
  observational parameter space in a uniform fashion, with as
  complete as possible coverage in the region of parameter space
  observed.

pointed
  A pointed observation of a particular astronomical object or field.
  Typically these are instrumental observations taken as part of some
  PI observing program.

  The data quality and characteristics may be variable, but the
  observations of a particular object or field may be more extensive
  than for a survey.

custom
  Data which has been custom processed, e.g., as part of a specific
  research project.

theory
  Theory data, or any data generated from a theoretical model, for
  example a synthetic spectrum.

artificial
  Artificial or simulated data. This is similar to theory data but
  need not be based on a physical model, and is often used for
  testing purposes.

We could push these into a vocabulary that then could be re-used
by, say, DAP when a service is foolhardy enough to mix datasets of
different data sources.  But I'd say handling this on the registry
level ought to be good enough for >90% of the cases.

Thoughts?

Me, I can't say I like the term "data source" for this kind of thing
too much.  But then I don't have a good alternative either.

Anyway: Please have a look at productTypeServed, and if you have,
say, Obscore services, please consider adding the declaration right
now.

        -- Markus