SLAP2 and the data-source vocabulary

[Stéphane Erard]

Hello Markus


propositions:

Lab: — this is usually called Experimental
Doing measurements using [artificial — no] samples in laboratory-like environments.
(think of meteorites, lunar samples.... : not artificial at all)
— my point was it is important to keep it separated from observations, so this is _not_ a child of Observation
The specific point is controlled environment & conditions

Observation 
I agree this is difficult to describe...
In our field this is always related to telescopes or space missions I think. The mention of the actual world is unusual

in-situ
A subset of Observation of observation indeed
Close range observation in contact with the target

And again, distinguishing abstract and concrete models is new to me - I don't think this is really used anywhere, and I can imagine cases which would be classified arbitrarily. What may be more relevant is evolving systems (iterative computations) vs reproduction of a final state (ie: finding the proper parameter values)

Here is what an AI says to me:
Observational data: measurements of real astronomical objects or phenomena. [acquired with telescopes, spacecraft instruments, or detectors]
Experimental data: measurements from laboratory or field experiments designed to study relevant physical processes.
Simulation data: outputs of numerical simulations reproducing the evolution of astronomical systems.

This had to be refined a bit, but it sounds like a good starting point.
I would insist on controlled conditions for experimental data


Let me know
Stéphane

> Le 16 sept. 2026 à 11:26, Markus Demleitner via semantics <semantics at ivoa.net> a écrit :
> 
> Hi Stéphane,
> 
> [I took the liberty of removing DAL from the recipient list, as this isn't
> actually about SLAP2 as such any more]
> 
> On Tue, Sep 15, 2026 at 03:15:51PM +0200, Stéphane Erard via semantics wrote:
>> 2) experimental (lab)
>> this is very different from observations, e.g. in terms of data
>> volume, instrumentation, capacities, etc, and can be described as
>> "measurements" rather than observations. It often applies to
>> isolated samples and provides ground truth, in contrast with
>> usual observations. And this is the usual source of computational
>> models.
> 
> The question is how to express this in a definition; I still wonder
> how to improve on my current:
> 
>  Doing measurements using artificial samples in laboratory-like
>  environments.
> 
>> 3) modelling
>> I could live with the distinction between abstract/concrete simulations, but I'm not sure about the examples provided:
>> "Examples would include common cosmological simulations or model spectra of atmospheres."
>> — atmospheric modeling is not an abstract thing: you tweak the
>> parameters to reproduce the observations, so as to explain them
>> (unless you think of ab-initio computations).
> 
> Which is of course what I do here; I was thinking of grids of stellar
> spectra where you systematically input abundances, temperatures and
> logg without regard to actually existing stars.  Perhaps saying
> "spectral grids" rather than "model spectra" is better?
> 
>> So, as discussed in Strasbourg, my feeling is that the distinction
>> between abstract / concrete modeling / simulations is jesuitic and
>> can only result in misclassifications, for very little added value
>> - this may be different in some fields of course, but I can find no
>> counterexample.
> 
> I'm fairly convinced that there is benefit to saying "This is
> supposed to be in this particular universe" versus "This ought to be
> this way in any universe".  This has concrete consequences: In the
> first case, you can do direct comparisons to observations, in the
> second, any comparisons have to go through statistics.
> 
>> The same distinction could in fact apply to experimental data
>> (reference measurements vs exploratory ones), with similarly little
>> benefit.
> 
> Hm... I think it would be "experiment in this universe" vs.
> "experiment in any universe".  This feels like something causing
> headaches when one thinks about this for too long...
> 
> Thanks,
> 
>         Markus
> 
> 
> 
> 
>