VEP-007: datalink-core#detached-header

[Anne Catherine Raugh]

Hello,

Well, thinking about this at 6am without having had coffee yet...

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 *not* human-readable,
but I suspect they do not show up in IVOA repositories as data files.)

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.

Coffee time...

-Anne.


On Wed, Sep 15, 2021 at 5:26 AM BONNAREL FRANCOIS <
francois.bonnarel at astro.unistra.fr> wrote:

> Hi all,
>         I know that VEP-007 will be discussed today and I will not
> participate.
>         I got no answer to this email except recently from Markus in a
> private discussion.
>         I am strongly in favor of the new term itself.
>         My small concern (with a proposal) is that as it is stated now
> in "https://volute.g-vo.org/svn/trunk/projects/semantics/veps/VEP-007.txt"
>         The head-term of #detached-header is "documentation".
>         I think that a head term like #metadata would be better.
>         This term doesn't exist  up to now and I think it is  lacking.
>         #metadata is different from #documentation in the sense that the
> first one is machine readable while the other one is human readable
>         So usage by clients would be very different. Other example for
> #metadata would be #ivoa-provenance-metadata and #ivoa-obscore
>         If you think this is a good idea I would like to add this term
> either in the same VEP or as another VEP with the small modification of
> head-term in VEP-007 itself
> Cheers
> François
>
> Le 16/06/2021 à 09:20, BONNAREL FRANCOIS a écrit :
> > Hi all,
> > Very interesting proposal indeed.
> > I'm just wondering if we could take the opportunity to create a new
> > #metadata branch .
> > So that "#detached-header" would be a child of this head term #metadata
> > Other children terms in the future could be #provenance_record (to
> > attach ivoa provenance serailisation to #this), #obscore_record (to
> > attche obscore metadata to #this when the dataset was not discovered
> > via an ObsCoredelivering service) etc ....
> > Cheers
> > François
> > Le 16/06/2021 à 09:13, Baptiste Cecconi a écrit :
> >> Hi all,
> >>
> >> I received an direct comment from Anne Raugh, and have updated the
> >> Rationale of VEP-007 accordingly. I copy the new content of the
> >> Rationale section below:
> >>
> >>> Rationale:
> >>> In some formats and archives, the metadata required to decode the
> >>> content of #this is in a separate file. In the case of NASA/PDS
> >>> data products, for example, the PDS label file contains the decoding
> >>> metadata. In some archives, the FITS header may be stored separately
> >>> as a plain text file, next to a data file consisting of a binary
> >>> stream of bytes. Clients would use the content type (MIME type)
> >>> (e.g.: application/x-pds4-label+xml, or text/x-pds3-label) to enable
> >>> the processing.
> >>>
> >> Cheers
> >> Baptiste
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20210915/df7bc82b/attachment.html>