<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 "machine-readable" 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'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 <<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>
Le 15/09/2021 à 12:00, Markus Demleitner a écrit :<br>
> Hi François,<br>
><br>
> On Wed, Sep 15, 2021 at 11:25:14AM +0200, BONNAREL FRANCOIS wrote:<br>
>> I know that VEP-007 will be discussed today and I will not<br>
>> participate.<br>
> Oh, dang. So, what about VEP-006? François, you seemed to still<br>
> have concerns with that, too -- or can that go on now?<br>
><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 in<br>
>> "<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 either<br>
>> in the same VEP or as another VEP with the small modification of head-term<br>
>> in VEP-007 itself<br>
> First, I'm strongly against introducing terms on, effectively, a whim<br>
> -- experience has shown many times it's almost certain that'll be<br>
> trouble once we actually need a related concept.<br>
><br>
> Instead, we should rather<br>
><br>
> (a) have a clear need for the term, which for datalink/core means<br>
> (for now): A link that either doesn't fit any of the existing<br>
> concepts at all or requires splitting an existing concept because the<br>
> link needs a different treatment (by a machine) from other members of<br>
> that existing concept.<br>
><br>
> (b) have a clear and plausible ("digital") *pragmatics* for that<br>
> concept. What we're doing here is machine-readable semantics, so to<br>
> make a term worthwhile, there must be at least an idea (even better:<br>
> implementation) of what a machine should do with the information that<br>
> 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'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'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 "pragmatics" should be contextualised.<br>
<br>
Cheers<br>
<br>
François<br>
<br>
<br>
> Having said that, François has a point in that documentation's<br>
> definition currently says "Extra information on the item in<br>
> *human-readable* text form" (emphasis mine). I think what we're<br>
> learning with this item is that "human-readable" was an error here;<br>
> the examples "processing logs" or "weather reports" already make that<br>
> clear: These are a lot more useful when they come in a structured<br>
> format, which very often will not have "text form" (unless you have a<br>
> very liberal idea of text).<br>
><br>
> Hence, I'd say we need to fix the definition #documentation to read<br>
><br>
> Extra information aiding in understanding or interpreting the item.<br>
> Such information can range from processing logs to weather reports<br>
> to technical documents on instruments to related publications.<br>
><br>
> I give you that one of these days separating "human-readable" and<br>
> "machine-readable" (or structured, as for #detached-header)<br>
> documentation might be useful (so users could hide away stuff that'll<br>
> only give gobbledigook unless they have a matching client); that<br>
> could then approach what I think your *#metadata would comprise.<br>
><br>
> But let's wait until we have cases where there's so much<br>
> #documentation that that's actually worth it. For now, I'm sure<br>
> even in interactive use most people would actually like to see a FITS<br>
> header when they open #documentation.<br>
><br>
> François (and, of course, everyone else), would you be ok with a VEP<br>
> fixing #documentation's definition as above? Since it just widens<br>
> the extension and probably won't conflict strongly with other<br>
> concepts in datalink/core, I'd be rather confident it's technically<br>
> sane.<br>
><br>
> -- Markus<br>
><br>
> PS: talking about discussions that petered out over the holiday season,<br>
> I'd like to use this opportunity to remind everyone of<br>
> <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>
> I'm raising several points that I'm rather sure need to be addressed<br>
> before VEP-009 can go on.<br>
<br>
<br>
</blockquote></div>