#calibration as child of #progenitor

[Patrick Dowler]

I always thought of #calibration as meaning "is a #calibration file for
#this". For example, if #this is raw data, the #calibration might be the
flat field that one could use to calibrate #this.

If that raw #this also had a #derivation link to the calibrated product,
that thing would list both the raw data and the calibration as #progenitor,
and it seems like trying to say something like "link to the calibration
progenitor" with a single semantics term is distinguishing what I think are
roles in Prov DM.

In general, I think the DataLink style terms must be thought of with "is"
and not "was" in front. "was a calibration" is equivalent to putting
calibration under progenitor... I'm feeling really pedantic here, but it
seems like putting something  under #progenitor is changing the tense and
not that calibration is really more specific (narrower). And no, I don't
like the camel-case style vocabulary where we'd have "is" and "was"
versions of every term.... #isCalibration and #wasCalibration? yuck


--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Mon, 8 Jun 2020 at 00:34, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Dear DAL,
>
> In the datalink vocabulary (http://www.g-vo.org/rdf/datalink/core),
> we currently have #calibration as a top-level term, on the same level
> as #progenitor.
>
> I've always wanted to change that, because calibration files are part
> of #this' provenance chain, which is what #progenitor's current
> definition ("data resources that were used to create this dataset
> (e.g. input raw data)") describes.
>
> Hence, I'd like to put in a VEP that makes #calibration a child of
> #progenitor.
>
> The effect would be that in, say, a collapsed tree view of a links
> response, calibration data would at first be hidden in a folded-in
> branch of #progenitor-s, which, I'd argue, is what users expect.  Or,
> in a pyVO method get_by_semantics_transitive (which, in some form,
> I'll propose at some point), users would also get calibration data
> when they ask for #progenitor.
>
> An alternative would be that we redefine #progenitor to match
> ProvDM's WasDerivedFrom (i.e., something like "the original raw
> dataset") and then have a new top-level class encopassing both this
> new term and #calibration; while I *think* this would mostly reflect
> current use of #progenitor, I still believe this is a fairly
> intrusive change to the concepts of datalink/core, which I'd rather
> avoid.
>
> My preference therefore would be: if we find there's a case to
> represent ProvDM's WasDerivedFrom in datalink/core, I'd much rather
> have a new term for it and make that another child of #progenitor.
>
> So... should I go ahead and prepare a VEP for moving #calibration
> into the #progenitor branch?
>
>          -- Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20200611/52ca2589/attachment.html>