VEP6: blurry definition for the term #calibration

[Paul Harrison]

Here are my pain scale rankings.

> On 2021-04 -29, at 13:31, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> (a) We keep things as they are and we just forget about datalink
> semantics being a tree.  You'll understand that I'd be seriously
> unhappy with that outcome.

4

I am not sure that leaving things as they are is "giving up on datalink semantics being a tree” - we are just in this fuzzy place as to what different people understand by #progenitor, and I actually think that is is a good thing that it is disjoint with #calibration.

The description of #progenitor in the RDF is just "data resources that were used to create this dataset (e.g. input raw data)”, and this combined with the disjointness of #calibration leads me to interpret #progenitor as being “science data” progenitor. I don’t see anything written in https://www.ivoa.net/documents/DataLink/20150617/REC-DataLink-1.0-20150617.html that makes this interpretation invalid.

pros * not changing anything in standards!

cons * no way to distinguish if “#calibration” was actually used in the production of #this or is just a possible calibrator
     * the #progenitor interpretation above is not how some implementations have interpreted #progenitor.
> 
> (b) We make #calibration a child of #progenitor ("#calibration
> ⊂ #progenitor").  That's a fine solution, except I'd ask the
> proponents of that to convince Pat, who has, in effect, proposed
> VEP-006.

4

I think that this should also have 

pros * progenitor more clearly takes on the wider “involved in the production” meaning that some prefer.

cons * no ability to tag “alternative calibrator”
     * data provider might just tag everything #progenitor anyway and we lose the distinction between calibration and science data
> 
> (c) We accept VEP-006, perhaps with some fixes to labels or
> definitions (I'm totally open to suggestions); we can then have
> additional terms to tell apart "science data" and "calibration files"
> below #progenitor.

6
> 
> (d) We deprecate #calibration and children, saying the concepts
> cannot be properly defined (and it'd take quite a bit of reasoning to
> wear down my resistance against that).

10

> 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20210505/25581f09/attachment.p7s>