VEP-007: datalink-core#detached-header

[BONNAREL FRANCOIS]

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 analogous^5 
> <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/e64800a5/attachment.html>