<div dir="ltr"><div class="gmail_default" style="font-size:small">This has been an interesting discussion to follow and as the sort-of proponent of VEP-006 I should add a comment. <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I was always thinking about the use of #calibration in the practical sense that Markus' mentioned a while back: actionable information for someone deciding if they needed to use a link or not. Assuming you are downloading the #this links, do you also need these other things? If the other things are #preview with content_type image/png you have enough information to make that decision because the client can tell exactly what they are for:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">{link} ... #preview ... #this</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">You can make the above ~sentence without worrying about the extra words a natural language uses and everyone knows what it means. Specifically, everyone naturally assumes that the first first ... means "is a" (present). However, with calibration it isn't so clear:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">{link} ... #calibration ... #this</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The debate here is whether that ~sentence means "is a" (not yet applied) or "was a" (applied). The relationship is #calibration in both cases and while it is tempting to restrict the meaning to the actionable "is a" (present tense) I think that kind of approach means we more or less double the number of terms: isCalibration and wasCalibration? ugh.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I have been convinced that the terms in a vocabulary shouldn't worry about present or past tense. The definition should be flexible enough to convey the calibration relationship and not the tense. I think the current "resource used to calibrate the primary data" is very close - "used" only weakly implies past tense (already applied) and if anyone thinks it specifies past tense then we should tweak that.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I think other commenters generally agreed that tense doesn't apply because we are not trying to reproduce the provenance. Can we modify VEP-006 to remove any sense of a tense restriction? I would propose a minor clarification, 2 options:<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">#calibration : resource to calibrate the primary data</div><div class="gmail_default" style="font-size:small">#calibration: resource that has or can be used to calibrate the primary data<br></div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Datalink semantics is about the relationship between two things so this logic may apply to other terms. I would support removing "used" from child definitions as well (bias, dark, flat).<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">PS-not a fan of the circular definition but trying to define without using "calibrate" seems to make it too restrictive and cumbersome<br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 5 May 2021 at 06:34, Paul Harrison <<a href="mailto:paul.harrison@manchester.ac.uk">paul.harrison@manchester.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Here are my pain scale rankings.<br>
<br>
> On 2021-04 -29, at 13:31, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br>
> <br>
> (a) We keep things as they are and we just forget about datalink<br>
> semantics being a tree. You'll understand that I'd be seriously<br>
> unhappy with that outcome.<br>
<br>
4<br>
<br>
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.<br>
<br>
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 <a href="https://www.ivoa.net/documents/DataLink/20150617/REC-DataLink-1.0-20150617.html" rel="noreferrer" target="_blank">https://www.ivoa.net/documents/DataLink/20150617/REC-DataLink-1.0-20150617.html</a> that makes this interpretation invalid.<br>
<br>
pros * not changing anything in standards!<br>
<br>
cons * no way to distinguish if “#calibration” was actually used in the production of #this or is just a possible calibrator<br>
* the #progenitor interpretation above is not how some implementations have interpreted #progenitor.<br>
> <br>
> (b) We make #calibration a child of #progenitor ("#calibration<br>
> ⊂ #progenitor"). That's a fine solution, except I'd ask the<br>
> proponents of that to convince Pat, who has, in effect, proposed<br>
> VEP-006.<br>
<br>
4<br>
<br>
I think that this should also have <br>
<br>
pros * progenitor more clearly takes on the wider “involved in the production” meaning that some prefer.<br>
<br>
cons * no ability to tag “alternative calibrator”<br>
* data provider might just tag everything #progenitor anyway and we lose the distinction between calibration and science data<br>
> <br>
> (c) We accept VEP-006, perhaps with some fixes to labels or<br>
> definitions (I'm totally open to suggestions); we can then have<br>
> additional terms to tell apart "science data" and "calibration files"<br>
> below #progenitor.<br>
<br>
6<br>
> <br>
> (d) We deprecate #calibration and children, saying the concepts<br>
> cannot be properly defined (and it'd take quite a bit of reasoning to<br>
> wear down my resistance against that).<br>
<br>
10<br>
<br>
> <br>
<br>
<br>
<br>
</blockquote></div>