<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hello<div><br></div><div>My two cents: </div><div><br></div><div>A usual split, as far as data is concerned, is between:</div><div><br></div><div>1) observational </div><div><span class="Apple-tab-span" style="white-space:pre"> </span>either ground based or space borne (plus possibly field observations on Earth)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>with space borne being either in-situ or remote sensing (field obs also)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>in-situ covering e.g., either rovers/landers or plasma instruments. The instrument is literally in contact with the target; this hardly applies to stars and galaxies ;)</div><div><br></div><div>2) experimental (lab)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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.</div><div><br></div><div>3) modelling</div><div>I could live with the distinction between abstract/concrete simulations, but I'm not sure about the examples provided:</div><div>"<span style="font-family: -webkit-standard; font-size: medium;">Examples would include common cosmological simulations or model spectra of atmospheres.</span>"</div><div>— 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).</div><div>Same thing with surface spectra or global circulation models.</div><div>"<span style="font-family: -webkit-standard; font-size: medium;">An example would be images generated from catalogues for exercising pipelines or reduction software.</span>"</div><div>— to me that would fall under abstract. You're just producing reasonably credible data to train a software, no need to be exact.</div><div><br></div><div>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.</div><div>The same distinction could in fact apply to experimental data (reference measurements vs exploratory ones), with similarly little benefit.</div><div><br></div><div>Stéphane</div><div><br></div><div><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>Le 15 sept. 2026 à 14:15, Gregory MANTELET via semantics <semantics@ivoa.net> a écrit :</div><br class="Apple-interchange-newline"><div><div>Dear Markus, Semantics and DAL members,<br><br>I do not feel competent regarding this question, but I completely understand<br>the need for such vocabulary, especially in the context of SLAP(2).<br><br>As Markus said, there is currently no existing SLAP1 service, hence the amazing<br>possibility to change the vocabulary introduced in v1 into a much better one in<br>v2. Even not being an astronomer, I agree that the distinction between<br>"observational/astrophysical" and "observational/laboratory" is not clear.<br><br>Has anybody in the Semantics WG or anyone having observational or theoretical<br>data (whatever kind they are) an opinion?<br><br>SLAP2 will be very soon a Proposed Recommendation. It would be really great to<br>have its vocabulary ready before it becomes a REC.<br><br>Thank you for your help,<br>Grégory M.<br><br><br>Le 27/08/2026 à 15:34, Markus Demleitner via dal a écrit :<br><blockquote type="cite">Dear Semantics, dear DAL,<br><br>You may remember the data-source vocabulary that we're currently<br>trying to introduce with VODataService 1.3:<br><https://www.ivoa.net/rdf/data-source/>.<br><br>When last discussed in Strasbourg (rather lively), it was about<br>telling #abstract-model from #concrete-model. Now, my hopes that<br>#observation is less tricky (for now) turn out to be unjustified.<br>This is because on the way to SLAP2, I would like to replace the<br>dataSource element in its registry extension with something using<br>with the vocabulary (and then probably drop it in favour of the<br>VODataService 1.3 dataSource, but that's a minor matter).<br><br>The SimpleDALRegExt 1.2 ("SLAP1") content model is<br><br>"observational/astrophysical", "observational/laboratory", "theoretical"<br><br>-- and I really think we can't tell the line community to disregard<br>the difference between the first two concepts. Since there are<br>(essentially) no live SLAP1 services left, we are free to rename<br>them, but I think we have to keep the concepts.<br><br>In a first stab, I've created #in-situ and #laboratory concepts,<br>What do people think? In particular look at the definitions. I'm<br>aware that you can construct things that violate the principle that<br>something should be within one leaf concept only (think of robolabs<br>onboard of spacecraft ), but at least I can't make the definitions<br>such that these aren't ambiguous (for the record, I think the<br>definitions should be written such that robolabs count as in-situ).<br><br>Comments welcome, more welcome actually if they come early.<br><br>I'd suggest followups should go to semantics.<br><br>Thanks,<br><br> Markus<br></blockquote><br><br><br><br><br></div></div></blockquote></div><br></div></body></html>