<div dir="ltr">For my part, at least, I do not have a deep enough understanding of IVOA implementations to argue from that perspective. Similarly for past experience with modifying IVOA vocabularies already in use. So if the majority of those who do have that understanding and experience tell me that it is better to omit the #metadata level until there is a larger collection of concrete use cases, then I can happily (for now, at least) accept that wisdom.<div><br></div><div>If it is not such a clear majority, then I'm a bit more worried about it...<br><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-Anne.</div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 15, 2021 at 4:09 PM BONNAREL FRANCOIS <<a href="mailto:francois.bonnarel@astro.unistra.fr">francois.bonnarel@astro.unistra.fr</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">
<div>
<div>Dear Markus, all,<br>
</div>
<div>Le 15/09/2021 à 16:50, Markus
Demleitner a écrit :<br>
</div>
<blockquote type="cite"><br>
<pre></pre>
<blockquote type="cite">
<pre>We cannot rule out the discussion of a specific term just because
we don't have a working example yet if it is obviously related to
the term which was first proposed.
</pre>
</blockquote>
<pre>...can we at least try it here? You see, I've built VocInVO2
specifically so we can hopefully move without too much speculative
specification, and move quick on top.
</pre>
</blockquote>
<p>Well as you will see below this is not speculation but actual use
cases.</p>
<p>VocInVO2 reads "</p>
<p>
</p><blockquote type="cite"><a id="gmail-m_4873136572526583198tth_sEc5.2.1">To add one or more
terms to a vocabulary, to introduce deprecations or
to change term labels, descriptions, or relationships,
an interested party - not necessarily affiliated with the
Working Group
that has 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 the former pair are rather
analogous</a><a href="https://ivoa.net/documents/Vocabularies/20210525/REC-Vocabularies-2.0.html#tthFtNtAAF" id="gmail-m_4873136572526583198tthFrefAAF" target="_blank"><sup>5</sup></a>.
In the latter case, two very different rationales would have
to be put forward, which is a clear sign that two VEPs are in
order.
<p><span></span></p>
<p><span></span></p>
</blockquote>
<p></p>
<p>So this let open that several terms may be discussed together or
at the same time as long as they are related.<br>
</p>
<p><br>
</p>
<blockquote type="cite"><br>
<blockquote type="cite">
<pre>So that sounds like an argument for creating #metadata specifically
to be the supertype of #header. If so, what non-#header type might
there also be under #metadata? I don't object to having the
occasional platypus in a taxonomy, but no more than are strictly
necessary...
</pre>
</blockquote>
<pre>Exactly: For vocabularies, size matters: The smaller it is, the more
likely it is that people will pick the right concept and that
machines will understand them.
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.
</pre>
</blockquote>
<p>But I indeed gave those examples !!!!</p>
<p> - 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. <br>
</p>
<p> - 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.</p>
<p>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</p>
<p>Cheers</p>
<p>François<br>
</p>
<blockquote type="cite">
<pre> to
Nothing will break just because this extra *#metadata will show up
between #documentation and #detached-header: Users will still fold it
out when they look for documentation, and machines will still find
the #detached-header they're looking for. It's just the other
machines that need the (yet unclear) pragmatics for #metadata will
then pick up #detached-header and all its future siblings.
And all that without committing to any specific definition or
position of #metadata at this point; that's good because as I said
the odds of us regretting such a commitment later are high.
So... Deal on VEP-007?
-- Markus
</pre>
</blockquote>
<p><br>
</p>
</div>
</blockquote></div>