VEP6: blurry definition for the term #calibration

[Patrick Dowler]

This has been an interesting discussion to follow and as the sort-of
proponent of VEP-006 I should add a comment.

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:

{link} ... #preview ... #this

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:

{link} ... #calibration ... #this

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.

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.

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:

#calibration : resource to calibrate the primary data
#calibration: resource that has or can be used to calibrate the primary data

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).

PS-not a fan of the circular definition but trying to define without using
"calibrate" seems to make it too restrictive and cumbersome
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Wed, 5 May 2021 at 06:34, Paul Harrison <paul.harrison at manchester.ac.uk>
wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20210511/bdd0a5d1/attachment-0001.html>