VEP-007: datalink-core#detached-header

Laurent Michel laurent.michel at astro.unistra.fr
Wed Sep 15 14:43:47 CEST 2021



Le 15/09/2021 à 14:21, Anne Catherine Raugh a écrit :
> 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...
Although very speculative yet, I've something like a model-mapping in mind.
> 
> -Anne.
> 
> 
> On Wed, Sep 15, 2021 at 7:30 AM Laurent Michel <laurent.michel at astro.unistra.fr <mailto: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>
>      > <mailto: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>
>      >     <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 <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 <http://www.unistra.fr>>
>     Observatoire Astronomique
>     11 Rue de l'Université
>     F - 67200 Strasbourg
> 

--
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


More information about the semantics mailing list