datalink-terms

[Markus Demleitner]

Hi Pat,

Thanks for putting together this list. 

What I think is missing so far is the provenance axis.  For instance,
I'd like to express in a datalink for split-order Echelle spectrum
where the merged order is found and vice versa.  Also, without a raw
file the calibration files we already descibe aren't terribly useful.

Let me propose #derivation as a top-level label for the merged-order
file in the split-order datalink.  I can't see myself liking
#predecessor or #ancestor for the files some reduced data set is
derived from, so better ideas  are solicited.

Having #predecessor and #derivation (or whatever) would, I'd argue,
do for now.  Further details would be up to a proper provenance data
model or actual software using those wonders.

And then:

On Tue, Oct 21, 2014 at 10:46:46AM +0100, Norman Gray wrote:
> That's perfectly true -- there's no semantics attached to the
> names.  However it may be useful for debugging if nothing else, if
> the names echo the structure, thus #preview, #preview-image,
> #preview-plot and so on.

While in general I don't like giving terms structure, in *this
particular* instance (preview) I believe Norman is right.  "image"
and "plot" are very generic, and reserving them for previews doesn't
sound like a good idea to me.

There's a difference to the remaining terms, e.g., for bias, dark,
and flat -- these are terms that immediately have to do with
calibrating images.  And a cutout simply is some sort of processing
product.  However, not every sort of image is a preview, and hence it
should be preview-image, previewImage, or preview_image

$(#=% B ()%

Sorry, I have to close here, people just drilled a hole in my ceiling
to arrest me for needlessly instigating a syntax debate.  As
mitigating circumstance let me close with saying I'm for Norman's
original preview-image and preview-plot.  

And that I don't think any of the other terms need prefixes.

Cheers,

         Markus