VEP-009

[BONNAREL FRANCOIS]

Dear Markus,
One day of work during some long vacations, and I try to have this 
discussion not suffering a too long interruption as you asked.
Le 07/07/2022 à 08:24, Markus Demleitner a écrit :
> Dear François,
>
> On Wed, Jul 06, 2022 at 06:17:55PM +0200, BONNAREL FRANCOIS wrote:
>>> What this means is that when you give or change a concept, you should
>>> be able to give something like an if clause that conceptually can be
>>> executed by a sufficiently sophisticated machine that would tell it
>>> which bin to put the link in.  Since in the end the recipe is being
>>> executed by a human, a certain amount of handwaving is permissable,
>>> but I'm sure you cannot assume "science data" as such has an
>>> interoperable meaning, and hence you just have to explain what that
>>> is and how data providers can tell whether something is that or
>>> rather "non-science data".
>> well "science data" results into source photon properties, taking into
>> account the instrument response function.
>>
>> If you don't like "science data" because you think the irf are also "science
>> data" in some sense,  can we speak of "observed response" or "sky-generated
>> response" ?
> Could you try to write the if clause(s) that would do the sorting you
> are after?  You see, something like
>
>    A thing is a *#science-data if it represents photons received from the
>    sky
In this context a thing is called a *#science data if it represents a 
"message" (photons, astroparticules or gw) from a  part of the sky 
exclusive from "messages" of part of the sky used to calibrate those.
>
> would sort the reference fields (is that the term?) in a VLBI
> observation into *#science-data (not to mention I'd like to avoid
> restring ourselves to photons).  I *think* that's not what you
> intend, is it?
>
>>> Again, I think the best way to come up with this if statement is to
>>> figure out exactly *why* you would want to put different sorts of
>>> progenitors into different bins.
>> Well; see above I think I answered that several times.
> Hm -- it may be just me, but I still cannot see why you don't like
> the current #progenitor concept, except that you are uncomfortable
> with the identifier (and at least the label could be more easily
> repaired than by changing the concept).
>
> If it's not that, can I ask you to try again to draw up a scenario of
> the form:
>
>    A researcher wants to do X, and they write a program doing Y.  That
>    program needs to tell apart different sorts of (current)
>    #progenitor-s because Z.

I am currently discussing these things with people which may appear in 
the discussion after the summer break.

This is my own use case :

A researcher facing a calibrated image wants to go back to the raw image 
and reprocess them with a new program (algorithm) and the same 
calibration data that were used before. That program needs to tell apart 
among the progenitors  which are the raw specific science data and which 
are the calibration data which obviously don't play the same role 
although they are all images.

Cheers

François

>
> It's that Z that might tell us how the current #progenitor would have
> to be split up and in particular what might be wrong with it in the
> first place.
>
>            -- Markus
>