#calibration as child of #progenitor

[Markus Demleitner]

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