Second VODataService 1.3 WD

[Markus Demleitner]

Dear Registry WG,

A new working draft for VODataService 1.3 is out at
<https://ivoa.net/documents/VODataService/20260324/>.  Please review!

Here's a brief rundown of the changes.

(1) You may remember there already was a WD in 2024, which only added
productTypeServed.  This is designed to fix our type-specific
discovery: You don't have to "look for SSAP services if you're
looking for spectra" any more, because that just doesn't work any
more with obscore around and DAP coming up.

(2) In addition to that, the current draft adds another
vocabulary-controlled item on data resources, dataSource, which lets
you declare whether your data comes from an observation or has some
other origin.  The corresponding vocabulary, lightly inspired by a
similar thing in SSAP, is this: <http://www.ivoa.net/rdf/data-source>
[yes, I've noticed the URL in the schema is wrong; that's PR#16].

This is a use case that becomes more important as more simulation and
artificial data enters the VO.  I have few doubts with the element
itself but wonder if the vocabulary actually covers the use cases out
there, as in:

* Is there actually a point to distinguish artifical (i.e., real
  source, but simulated observation) and theory (i.e., random numbers
  as input)?  To me, this seems reasonable, because people may want to
  look for, say, mock observations using instrument models or so and
  not be bothered by random numbers, but I could be swayed there.

* SSAP used to split up observation into pointed and survey.  I can
  see a point in that, beginning with "pointed observations are
  likely to go deeper (or at least take object properties into
  account)".  The items would also have a point because they would
  signal implementors that they should vocabulary-expand the terms
  on comparisons using data-source.  The extra concepts have not
  quite made my adoption threshold, though, but again I might be
  swayed.

(3) The largest and IMHO most important change are the column
statistics.  This is by and large what has been envisioned in
<https://ivoa.net/documents/Notes/colstatnote/>, and it's probably a
good idea to skim that note before reviewing this part.

It would be *wonderful* if we had more adopters of this (currently:
DaCHS and VizieR) by PR time, because these column statistics open up
quite a few discovery techniques if they are widely available.  If
you're running a registry, please try to find it in yourself to adopt
this (and if you're running a recent enough DaCHS, run dachs limits
ALL now).

At least on top of a postgres, it's a lot less hassle than you might
expect.

One discussion point here was whether the container object for the
statistics shouldn't rather be called values rather than stats.  I
have sympathies for that.  For one, VOTable has a VALUES element that
does roughly the same thing; and the stats element can (and should)
also be used in InputParams, where the stats name is a lot less
plausible than with TableParams.

Opinions on this, as on anything else related to this WD, are most
welcome, either here or in github bugs.

Thanks,

           Markus