about #calibration (VEP-006) : ----> IMPORTANT for DataLInk EXTENDED USAGE

[Markus Demleitner]

Hi Pat,

[side note: I'll take the parallel thread with François to the
semantics list, as it really isn't DAL material any more -- but
interesting semantics stuff, so if you're not on that list yet:
subscribe!]

On Wed, Oct 13, 2021 at 11:26:44AM -0700, Patrick Dowler wrote:
> I agree with the intent of VEP-006 that #calibration and it's child
> properties should cover the "use this raw data" use case
> and that the current ambiguity will become an issue of not resolved.
> 
> I understand the "already applied" use case and that some providers will
> want to provide links with the product. If that use case is "debugging" or
> "QA" by a human, then the existing #auxiliary and a decent description
> should suffice to support that. Providers can start there and see what

Just a correction: #auxilliary is the "use" concept, #progenitor (or
perhaps something else in the future) is for "debugging".

> shortcomings they run into... I completely agree with Markus that when
> someone actually tries to do this that we'll find out whether the use case
> really is QA or something else and we can't solve it until we find out what
> something else is. So, is
> 
> #auxiliary description="flat field used to calibrate this image"
> 
> sufficient to prototype the other use case(s)?

Except it'd be #progenitor (or, depending on VEP-009, perhaps
something else in the future): Yes, that's been my point: Debugging
is not an activity particularly straightforward to automate, so the
human-readable description in addition to #progenitor (telling the
computer: show this when debugging) ought to be enough.  The
computer's role in this probably can't go much further than just
filtering the links and showing them in some pretty way and with proper
descriptions[1]. 

Well... of course unless there's also a ProvDM serialisation
somewhere; then the computer could organise the links in a nice tree
(or, gasp, graph).  But we have ProvDM for that and shouldn't abuse
datalink semantics for some sort of ProvDM-lite[2].

        -- Markus

[1] For which of course datalink providers need to do a good job
filling these in, and from what datalink I've seen in the wild,
there's much room for improvement in that department.  Ahem.

[2] Not that I'd be against a ProvDM-lite; it's just that datalink
semantics is the wrong place for it.