VEP-007: datalink-core#detached-header

[Markus Demleitner]

Hi François,

On Wed, Sep 15, 2021 at 10:09:25PM +0200, BONNAREL FRANCOIS wrote:
> > originally introduced the vocabulary - prepares a Vocabulary Enhancement
> > Proposal (VEP). In the interest of thorough review and topical
> > discussion, a single VEP should only cover directly related terms. For
> > instance, in a vocabulary of reference frames, it would be reasonable to
> > add old-style and new-style galactic frames in one VEP, but not, say,
> > azimuthal and supergalactic coordinates. The arguments for both terms in
> > 
> So this let open that several terms may be discussed together or at the same
> time as long as they are related.

Sure, but I'm not arguing against *#metadata because it's unrelated,
but because we don't have a used-by for it (not to mention an actual
definition).

> > My point about VocInVO2's proposed workflow above here means that
> > once a second subconcept of this *#metadata comes up, we can just
> > introduce it, and we'll probably then be able to figure out what
> > special properties make a piece of #documentation a *#metadata.
> 
> But I indeed gave those examples !!!!

Well, you said what you'd like to annotate:

>     - if you want to use DataLink to attach an ivoa-provenance record to a
> dataset in the initial service response then I find this strange to call
> that "documentation" and not #metadata.
> 
>     - and if I discover a dataset with SIA1, SSA or HiPS progenitor
> functionality I may want to attach an actual Obscore record to that previous
> discovery record. These also like metdata to me and not documentation.

...but not how *a computer* should use the distinction you are
making.  You see, we all feel different about what words mean.  If we
all argue "I think X means A", and someone else says "But I think X
means B" what should I, as a chair, do?  There's no way to foster
consensus in these cases, as both parties are right, and there are no
arguments to decide one way or the other.  

Hence, let's avoid such discussions.  The good news is that there's a
rather workable alternative in the grand tradition of rough consensus
and running code.

Let's instead write clear definitions enabling well-defined
functionality for computer programmes.  

And let's be minimal.  As this example shows, discussions derail
quickly in semantics as soon as you're trying to solve more than the
problem just at hand.  Let's all go for minimal claims, one term at a
time, figuring out the domain as we go.

> And I think it's not because nobody tried to do that yet that it should
> forbid us to consider such use-cases or similar

That's perhaps the most important point: Just because we don't
introduce the term now doesn't mean we're forbidding anything.
On the contrary.

If someone serving provenance records one day finds that a computer
needs to be told that it's not just plain #documentation (and I'm
quite sure they will, but that's just a gut feeling), they can
quickly introduce *#structured-provenance as a narrower term and
*immediately* see if that fixes their problem.

And if it then turns out that some sort of common behaviour of
*#structured-provenance and #detached-header is desirable (and I
frankly doubt that, but that's again a gut feeling), *then* it's a
good idea to introduce *#metadata (or something like that) and write
its definition based on that common behaviour.

Let me again plead: Please try to find it in yourself to indulge me
on this mode of incremental development for a while.  In a community
like ours, I suspect we'll never get vocabularies built otherwise.

Thanks,

              Markus