#calibration as child of #progenitor
msdemlei at ari.uni-heidelberg.de
Mon Jun 8 09:27:20 CEST 2020
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
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
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
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?
More information about the semantics