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

[BONNAREL FRANCOIS]

Hi all

Le 14/10/2021 à 09:26, Markus Demleitner a écrit :
> 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".
I (almost :-) ) agree with Markus there; We should not use #auxiliary 
for #used-calibration and #progenitors
>> 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].
I'l probably answer VEP-009 current criticism next week
>
> 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].

ProvDM record accessible via DataLink will have much more than 
progenitors and used_calibrations which are "entities". They will alos 
have "agents" and "activties" and maybe sometimes activity_descriptions.

If you only need entities DataLink semantics terms can be pretty enough 
(that's the "poor guy" provenance)

Regards

François

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