<div dir="ltr">Here I am just playing with words to see where it takes us...<div><br></div><div>I can imagine this as two hierarchies:</div><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">documentation - information formatted for human reading and interpretation, possibly digitized from an analog source (paper, microfilm, etc.)</blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px">readme - a brief overview of a data product, collection, or resource</blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px">manual - document describing procedures for performing one or more specific actions </blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px">description - metadata presented in a non-machine-readable form</blockquote></blockquote><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>metadata - information about data products, formatted for programmatic processing according to a published standard</div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>header - metadata that is associated with a specific data product but provided in a separate file. It may include metadata unique to the product.</div></blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>supplemental - metadata that is applicable to a range of data products (observing logs, index files, etc.)</div></blockquote></blockquote><div>Or:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>documentation - information about one or more data products</div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>text - documentation formatted specifically for human reading and interpretation, possibly digitized from an analog source</div></blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">readme - a brief overview of a data product, collection, or resource</blockquote></div></blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">manual - document describing procedures for performing one or more specific actions</blockquote></div></blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">description - metadata presented in a non-machine-readable form</blockquote></div></blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>metadata - information about data products, formatted for programmatic processing according to a published standard</div></blockquote></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>header - metadata that is associated with a specific data product but provided in a separate file. It may include metadata unique to the product.</div></blockquote></blockquote></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>supplemental - metadata that is applicable to a range of data products (observing logs, index files, etc.)</div></blockquote></blockquote></div></blockquote><div><br></div><div>You could remove the middle layer in the second example, but then your definitions would (I assume) need to indicate which are machine-readable and which are not. The &quot;machine-readable&quot; attribute is, of course, highly desirable and needs to be well-defined if the ultimate goal is meeting FAIR principles.</div><div><br></div><div>But if you&#39;re encoding essential attributes into the (human-readable) descriptions, then your taxonomy is likely not sufficiently specific.</div><div><br></div><div><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 8:20 AM BONNAREL FRANCOIS &lt;<a href="mailto:francois.bonnarel@astro.unistra.fr">francois.bonnarel@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">Hi all,<br>
Le 15/09/2021 à 12:00, Markus Demleitner a écrit :<br>
&gt; Hi François,<br>
&gt;<br>
&gt; On Wed, Sep 15, 2021 at 11:25:14AM +0200, BONNAREL FRANCOIS wrote:<br>
&gt;&gt;         I know that VEP-007 will be discussed today and I will not<br>
&gt;&gt; participate.<br>
&gt; Oh, dang.  So, what about VEP-006?  François, you seemed to still<br>
&gt; have concerns with that, too -- or can that go on now?<br>
&gt;<br>
&gt;&gt;         I am strongly in favor of the new term itself.<br>
&gt;&gt;         My small concern (with a proposal) is that as it is stated now in<br>
&gt;&gt; &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>&quot;<br>
&gt;&gt;         The head-term of #detached-header is &quot;documentation&quot;.<br>
&gt;&gt;         I think that a head term like #metadata would be better.<br>
&gt;&gt;         This term doesn&#39;t exist  up to now and I think it is  lacking.<br>
&gt;&gt;         #metadata is different from #documentation in the sense that the<br>
&gt;&gt; first one is machine readable while the other one is human readable<br>
&gt;&gt;         So usage by clients would be very different. Other example for<br>
&gt;&gt; #metadata would be #ivoa-provenance-metadata and #ivoa-obscore<br>
&gt;&gt;         If you think this is a good idea I would like to add this term either<br>
&gt;&gt; in the same VEP or as another VEP with the small modification of head-term<br>
&gt;&gt; in VEP-007 itself<br>
&gt; First, I&#39;m strongly against introducing terms on, effectively, a whim<br>
&gt; -- experience has shown many times it&#39;s almost certain that&#39;ll be<br>
&gt; trouble once we actually need a related concept.<br>
&gt;<br>
&gt; Instead, we should rather<br>
&gt;<br>
&gt; (a) have a clear need for the term, which for datalink/core means<br>
&gt; (for now): A link that either doesn&#39;t fit any of the existing<br>
&gt; concepts at all or requires splitting an existing concept because the<br>
&gt; link needs a different treatment (by a machine) from other members of<br>
&gt; that existing concept.<br>
&gt;<br>
&gt; (b) have a clear and plausible (&quot;digital&quot;) *pragmatics* for that<br>
&gt; concept.  What we&#39;re doing here is machine-readable semantics, so to<br>
&gt; make a term worthwhile, there must be at least an idea (even better:<br>
&gt; implementation) of what a machine should do with the information that<br>
&gt; the link belongs to the new concept (rather than an old one).<br>
<br>
This is a point where I have a major disagreement with Markus I&#39;m afraid.<br>
<br>
If we want to build a consistent vocabulary we have to think a little <br>
bit ahead and also around the<br>
<br>
specific use case we are dealing with.<br>
<br>
We cannot rule out the discussion of a specific term just because we <br>
don&#39;t  have a working example yet if it is obviously related to the term <br>
which was first proposed.<br>
<br>
In other words the &quot;pragmatics&quot; should be contextualised.<br>
<br>
Cheers<br>
<br>
François<br>
<br>
<br>
&gt; Having said that, François has a point in that documentation&#39;s<br>
&gt; definition currently says &quot;Extra information on the item in<br>
&gt; *human-readable* text form&quot; (emphasis mine).  I think what we&#39;re<br>
&gt; learning with this item is that &quot;human-readable&quot; was an error here;<br>
&gt; the examples &quot;processing logs&quot; or &quot;weather reports&quot; already make that<br>
&gt; clear: These are a lot more useful when they come in a structured<br>
&gt; format, which very often will not have &quot;text form&quot; (unless you have a<br>
&gt; very liberal idea of text).<br>
&gt;<br>
&gt; Hence, I&#39;d say we need to fix the definition #documentation to read<br>
&gt;<br>
&gt;    Extra information aiding in understanding or interpreting the item.<br>
&gt;    Such information can range from processing logs to weather reports<br>
&gt;    to technical documents on instruments to related publications.<br>
&gt;<br>
&gt; I give you that one of these days separating &quot;human-readable&quot; and<br>
&gt; &quot;machine-readable&quot; (or structured, as for #detached-header)<br>
&gt; documentation might be useful (so users could hide away stuff that&#39;ll<br>
&gt; only give gobbledigook unless they have a matching client); that<br>
&gt; could then approach what I think your *#metadata would comprise.<br>
&gt;<br>
&gt; But let&#39;s wait until we have cases where there&#39;s so much<br>
&gt; #documentation that that&#39;s actually worth it.  For now, I&#39;m sure<br>
&gt; even in interactive use most people would actually like to see a FITS<br>
&gt; header when they open #documentation.<br>
&gt;<br>
&gt; François (and, of course, everyone else), would you be ok with a VEP<br>
&gt; fixing #documentation&#39;s definition as above?  Since it just widens<br>
&gt; the extension and probably won&#39;t conflict strongly with other<br>
&gt; concepts in datalink/core, I&#39;d be rather confident it&#39;s technically<br>
&gt; sane.<br>
&gt;<br>
&gt;             -- Markus<br>
&gt;<br>
&gt; PS: talking about discussions that petered out over the holiday season,<br>
&gt; I&#39;d like to use this opportunity to remind everyone of<br>
&gt; <a href="http://mail.ivoa.net/pipermail/semantics/2021-July/002829.html" rel="noreferrer" target="_blank">http://mail.ivoa.net/pipermail/semantics/2021-July/002829.html</a>, where<br>
&gt; I&#39;m raising several points that I&#39;m rather sure need to be addressed<br>
&gt; before VEP-009 can go on.<br>
<br>
<br>
</blockquote></div>