<div dir="ltr">I should have opted for tea - my attempts at coffee were oddly unsuccessful. My (freshly opened) milk kept curdling. If I were a chemist, I&#39;d be fascinated...<div><br></div><div>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&#39;t object to having the occasional platypus in a taxonomy, but no more than are strictly necessary...</div><div><br><div><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 7:30 AM Laurent Michel &lt;<a href="mailto:laurent.michel@astro.unistra.fr">laurent.michel@astro.unistra.fr</a>&gt; 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">Hello,<br>
<br>
I agree with you Anne, except for the last sentence :-)<br>
<br>
In the Datalink context, I think it is important to keep seperate words for #meta-data and #documentation.<br>
#documentation relates to textual information on #this. A good example is given by the Vizier READMEs that provide the <br>
scientific contexte of #this.<br>
#metadata relates to a documentation that is required to process #this, e.g. WCS.<br>
<br>
One is supposed to be read by the user whereas the other is meant to by used for some processing.<br>
<br>
Laurent<br>
<br>
<br>
Le 15/09/2021 à 13:03, Anne Catherine Raugh a écrit :<br>
&gt; Hello,<br>
&gt; <br>
&gt; Well, thinking about this at 6am without having had coffee yet...<br>
&gt; <br>
&gt; In the context of data, &quot;documentation&quot; and &quot;metadata&quot; are very nearly synonymous. The term &quot;machine-readable&quot; meant something <br>
&gt; quite different when I started in this business (back when dinosaurs roamed the Earth providing tech support), but now it seems <br>
&gt; to have evolved to mean what we would have called &quot;machine-actionable&quot;. Even still that&#39;s not as clear a line as we might like.A <br>
&gt; PDF document, for example, is machine-readable: it takes a computer to turn it into something that is human-readable and it is <br>
&gt; also possible to extract text, tables, and other items from a PDF file. But I don&#39;t think anyone wants to see PDF headers for <br>
&gt; data. Machine-readable headers are often human-readable as well, by design (like FITS).  (There are binary headers out there in <br>
&gt; some formats that are /not/ human-readable, but I suspect they do not show up in IVOA repositories as data files.)<br>
&gt; <br>
&gt; So, from my still-learning and yet aging perspective, I would expect that &quot;documentation&quot; would be the broadest term, that <br>
&gt; &quot;metadata&quot; would be a subtype of documentation with the stipulation that it is documentation provided in a format that conforms <br>
&gt; to a published standard that makes it machine-readable. &quot;Header&quot; would then be a subtype of &quot;metadata&quot; that is tightly bound to <br>
&gt; #this, with the further restriction that it provides some metadata that is unique to #this (otherwise why carry it along?). If <br>
&gt; we have a need to identify documentation that is not machine-readable (PDFs would qualify in the IVOA context), then there is <br>
&gt; probably another subtype of #documentation lurking in the wings. If we require that all documentation be machine-readable, then <br>
&gt; &quot;documentation&quot; and &quot;metadata&quot; are synonymous in the IVOA context, and there is no need for two terms.<br>
&gt; <br>
&gt; Coffee time...<br>
&gt; <br>
&gt; -Anne.<br>
&gt; <br>
&gt; <br>
&gt; On Wed, Sep 15, 2021 at 5:26 AM BONNAREL FRANCOIS &lt;<a href="mailto:francois.bonnarel@astro.unistra.fr" target="_blank">francois.bonnarel@astro.unistra.fr</a> <br>
&gt; &lt;mailto:<a href="mailto:francois.bonnarel@astro.unistra.fr" target="_blank">francois.bonnarel@astro.unistra.fr</a>&gt;&gt; wrote:<br>
&gt; <br>
&gt;     Hi all,<br>
&gt;              I know that VEP-007 will be discussed today and I will not<br>
&gt;     participate.<br>
&gt;              I got no answer to this email except recently from Markus in a<br>
&gt;     private discussion.<br>
&gt;              I am strongly in favor of the new term itself.<br>
&gt;              My small concern (with a proposal) is that as it is stated now<br>
&gt;     in &quot;<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>
&gt;     &lt;<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>&gt;&quot;<br>
&gt;              The head-term of #detached-header is &quot;documentation&quot;.<br>
&gt;              I think that a head term like #metadata would be better.<br>
&gt;              This term doesn&#39;t exist  up to now and I think it is  lacking.<br>
&gt;              #metadata is different from #documentation in the sense that the<br>
&gt;     first one is machine readable while the other one is human readable<br>
&gt;              So usage by clients would be very different. Other example for<br>
&gt;     #metadata would be #ivoa-provenance-metadata and #ivoa-obscore<br>
&gt;              If you think this is a good idea I would like to add this term<br>
&gt;     either in the same VEP or as another VEP with the small modification of<br>
&gt;     head-term in VEP-007 itself<br>
&gt;     Cheers<br>
&gt;     François<br>
&gt; <br>
&gt;     Le 16/06/2021 à 09:20, BONNAREL FRANCOIS a écrit :<br>
&gt;      &gt; Hi all,<br>
&gt;      &gt; Very interesting proposal indeed.<br>
&gt;      &gt; I&#39;m just wondering if we could take the opportunity to create a new<br>
&gt;      &gt; #metadata branch .<br>
&gt;      &gt; So that &quot;#detached-header&quot; would be a child of this head term #metadata<br>
&gt;      &gt; Other children terms in the future could be #provenance_record (to<br>
&gt;      &gt; attach ivoa provenance serailisation to #this), #obscore_record (to<br>
&gt;      &gt; attche obscore metadata to #this when the dataset was not discovered<br>
&gt;      &gt; via an ObsCoredelivering service) etc ....<br>
&gt;      &gt; Cheers<br>
&gt;      &gt; François<br>
&gt;      &gt; Le 16/06/2021 à 09:13, Baptiste Cecconi a écrit :<br>
&gt;      &gt;&gt; Hi all,<br>
&gt;      &gt;&gt;<br>
&gt;      &gt;&gt; I received an direct comment from Anne Raugh, and have updated the<br>
&gt;      &gt;&gt; Rationale of VEP-007 accordingly. I copy the new content of the<br>
&gt;      &gt;&gt; Rationale section below:<br>
&gt;      &gt;&gt;<br>
&gt;      &gt;&gt;&gt; Rationale:<br>
&gt;      &gt;&gt;&gt; In some formats and archives, the metadata required to decode the<br>
&gt;      &gt;&gt;&gt; content of #this is in a separate file. In the case of NASA/PDS<br>
&gt;      &gt;&gt;&gt; data products, for example, the PDS label file contains the decoding<br>
&gt;      &gt;&gt;&gt; metadata. In some archives, the FITS header may be stored separately<br>
&gt;      &gt;&gt;&gt; as a plain text file, next to a data file consisting of a binary<br>
&gt;      &gt;&gt;&gt; stream of bytes. Clients would use the content type (MIME type)<br>
&gt;      &gt;&gt;&gt; (e.g.: application/x-pds4-label+xml, or text/x-pds3-label) to enable<br>
&gt;      &gt;&gt;&gt; the processing.<br>
&gt;      &gt;&gt;&gt;<br>
&gt;      &gt;&gt; Cheers<br>
&gt;      &gt;&gt; Baptiste<br>
&gt;      &gt;<br>
&gt;      &gt;<br>
&gt; <br>
<br>
--<br>
English version: <a href="https://www.deepl.com/translator" rel="noreferrer" target="_blank">https://www.deepl.com/translator</a><br>
-- <br>
jesuischarlie/Tunis/Paris/Bruxelles/Berlin<br>
<br>
Laurent Michel<br>
SSC XMM-Newton<br>
Tél : +33 (0)3 68 85 24 37<br>
Fax : +33 (0)3 )3 68 85 24 32<br>
Université de Strasbourg &lt;<a href="http://www.unistra.fr" rel="noreferrer" target="_blank">http://www.unistra.fr</a>&gt;<br>
Observatoire Astronomique<br>
11 Rue de l&#39;Université<br>
F - 67200 Strasbourg<br>
</blockquote></div>