<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br clear="all"></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<span class="gmail_default" style="font-size:small"></span><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 Mon, 8 Jun 2020 at 00:34, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</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">Dear DAL,<br>
<br>
In the datalink vocabulary (<a href="http://www.g-vo.org/rdf/datalink/core" rel="noreferrer" target="_blank">http://www.g-vo.org/rdf/datalink/core</a>),<br>
we currently have #calibration as a top-level term, on the same level<br>
as #progenitor.<br>
<br>
I've always wanted to change that, because calibration files are part<br>
of #this' provenance chain, which is what #progenitor's current<br>
definition ("data resources that were used to create this dataset<br>
(e.g. input raw data)") describes.<br>
<br>
Hence, I'd like to put in a VEP that makes #calibration a child of<br>
#progenitor.<br>
<br>
The effect would be that in, say, a collapsed tree view of a links<br>
response, calibration data would at first be hidden in a folded-in<br>
branch of #progenitor-s, which, I'd argue, is what users expect. Or,<br>
in a pyVO method get_by_semantics_transitive (which, in some form,<br>
I'll propose at some point), users would also get calibration data<br>
when they ask for #progenitor.<br>
<br>
An alternative would be that we redefine #progenitor to match<br>
ProvDM's WasDerivedFrom (i.e., something like "the original raw<br>
dataset") and then have a new top-level class encopassing both this<br>
new term and #calibration; while I *think* this would mostly reflect<br>
current use of #progenitor, I still believe this is a fairly<br>
intrusive change to the concepts of datalink/core, which I'd rather<br>
avoid.<br>
<br>
My preference therefore would be: if we find there's a case to<br>
represent ProvDM's WasDerivedFrom in datalink/core, I'd much rather<br>
have a new term for it and make that another child of #progenitor.<br>
<br>
So... should I go ahead and prepare a VEP for moving #calibration<br>
into the #progenitor branch?<br>
<br>
-- Markus<br>
</blockquote></div>