VEP-007: datalink-core#detached-header

[Anne Catherine Raugh]

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.

If it is not such a clear majority, then I'm a bit more worried about it...

-Anne.


On Wed, Sep 15, 2021 at 4:09 PM BONNAREL FRANCOIS <
francois.bonnarel at astro.unistra.fr> wrote:

> Dear Markus, all,
> Le 15/09/2021 à 16:50, Markus Demleitner a écrit :
>
>
> 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.
>
> ...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.
>
> Well as you will see below this is not speculation but actual use cases.
>
> VocInVO2 reads "
>
> 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
> analogous5
> <https://ivoa.net/documents/Vocabularies/20210525/REC-Vocabularies-2.0.html#tthFtNtAAF>.
> 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.
>
> So this let open that several terms may be discussed together or at the
> same time as long as they are related.
>
>
>
> 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...
>
> 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.
>
> But I indeed gave those examples !!!!
>
>     - 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.
>
> 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
>
> Cheers
>
> François
>
>  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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20210915/ccd797c8/attachment.html>