<div dir="ltr">Hello,<div><br></div><div>Well, thinking about this at 6am without having had coffee yet...</div><div><br></div><div>In the context of data, "documentation" and "metadata" are very nearly synonymous. The term "machine-readable" meant something quite different when I started in this business (back when dinosaurs roamed the Earth providing tech support), but now it seems to have evolved to mean what we would have called "machine-actionable". Even still that's not as clear a line as we might like.A PDF document, for example, is machine-readable: it takes a computer to turn it into something that is human-readable and it is also possible to extract text, tables, and other items from a PDF file. But I don't think anyone wants to see PDF headers for data. Machine-readable headers are often human-readable as well, by design (like FITS). (There are binary headers out there in some formats that are <i>not</i> human-readable, but I suspect they do not show up in IVOA repositories as data files.)</div><div><br></div><div>So, from my still-learning and yet aging perspective, I would expect that "documentation" would be the broadest term, that "metadata" would be a subtype of documentation with the stipulation that it is documentation provided in a format that conforms to a published standard that makes it machine-readable. "Header" would then be a subtype of "metadata" that is tightly bound to #this, with the further restriction that it provides some metadata that is unique to #this (otherwise why carry it along?). If we have a need to identify documentation that is not machine-readable (PDFs would qualify in the IVOA context), then there is probably another subtype of #documentation lurking in the wings. If we require that all documentation be machine-readable, then "documentation" and "metadata" are synonymous in the IVOA context, and there is no need for two terms.</div><div><br></div><div>Coffee time...</div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-Anne.</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 15, 2021 at 5:26 AM 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">Hi all,<br>
I know that VEP-007 will be discussed today and I will not <br>
participate.<br>
I got no answer to this email except recently from Markus in a <br>
private discussion.<br>
I am strongly in favor of the new term itself.<br>
My small concern (with a proposal) is that as it is stated now <br>
in "<a href="https://volute.g-vo.org/svn/trunk/projects/semantics/veps/VEP-007.txt" rel="noreferrer" target="_blank">https://volute.g-vo.org/svn/trunk/projects/semantics/veps/VEP-007.txt</a>"<br>
The head-term of #detached-header is "documentation".<br>
I think that a head term like #metadata would be better.<br>
This term doesn't exist up to now and I think it is lacking.<br>
#metadata is different from #documentation in the sense that the <br>
first one is machine readable while the other one is human readable<br>
So usage by clients would be very different. Other example for <br>
#metadata would be #ivoa-provenance-metadata and #ivoa-obscore<br>
If you think this is a good idea I would like to add this term <br>
either in the same VEP or as another VEP with the small modification of <br>
head-term in VEP-007 itself<br>
Cheers<br>
François<br>
<br>
Le 16/06/2021 à 09:20, BONNAREL FRANCOIS a écrit :<br>
> Hi all,<br>
> Very interesting proposal indeed.<br>
> I'm just wondering if we could take the opportunity to create a new <br>
> #metadata branch .<br>
> So that "#detached-header" would be a child of this head term #metadata<br>
> Other children terms in the future could be #provenance_record (to <br>
> attach ivoa provenance serailisation to #this), #obscore_record (to <br>
> attche obscore metadata to #this when the dataset was not discovered <br>
> via an ObsCoredelivering service) etc ....<br>
> Cheers<br>
> François<br>
> Le 16/06/2021 à 09:13, Baptiste Cecconi a écrit :<br>
>> Hi all,<br>
>><br>
>> I received an direct comment from Anne Raugh, and have updated the <br>
>> Rationale of VEP-007 accordingly. I copy the new content of the <br>
>> Rationale section below:<br>
>><br>
>>> Rationale:<br>
>>> In some formats and archives, the metadata required to decode the<br>
>>> content of #this is in a separate file. In the case of NASA/PDS<br>
>>> data products, for example, the PDS label file contains the decoding<br>
>>> metadata. In some archives, the FITS header may be stored separately<br>
>>> as a plain text file, next to a data file consisting of a binary<br>
>>> stream of bytes. Clients would use the content type (MIME type)<br>
>>> (e.g.: application/x-pds4-label+xml, or text/x-pds3-label) to enable<br>
>>> the processing.<br>
>>><br>
>> Cheers<br>
>> Baptiste<br>
><br>
><br>
<br>
</blockquote></div>