VEP-007: datalink-core#detached-header
Anne Catherine Raugh
araugh at umd.edu
Wed Sep 15 14:21:09 CEST 2021
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'd be fascinated...
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't object to having the occasional platypus in a
taxonomy, but no more than are strictly necessary...
-Anne.
On Wed, Sep 15, 2021 at 7:30 AM Laurent Michel <
laurent.michel at astro.unistra.fr> wrote:
> Hello,
>
> I agree with you Anne, except for the last sentence :-)
>
> In the Datalink context, I think it is important to keep seperate words
> for #meta-data and #documentation.
> #documentation relates to textual information on #this. A good example is
> given by the Vizier READMEs that provide the
> scientific contexte of #this.
> #metadata relates to a documentation that is required to process #this,
> e.g. WCS.
>
> One is supposed to be read by the user whereas the other is meant to by
> used for some processing.
>
> Laurent
>
>
> Le 15/09/2021 à 13:03, Anne Catherine Raugh a écrit :
> > 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
> > <mailto: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
> > <
> 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
> > >
> > >
> >
>
> --
> English version: https://www.deepl.com/translator
> --
> jesuischarlie/Tunis/Paris/Bruxelles/Berlin
>
> Laurent Michel
> SSC XMM-Newton
> Tél : +33 (0)3 68 85 24 37
> Fax : +33 (0)3 )3 68 85 24 32
> Université de Strasbourg <http://www.unistra.fr>
> Observatoire Astronomique
> 11 Rue de l'Université
> F - 67200 Strasbourg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20210915/14566b82/attachment.html>
More information about the semantics
mailing list