VEP-007: datalink-core#detached-header
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Wed Sep 15 17:00:11 CEST 2021
Dear Anne,
On Wed, Sep 15, 2021 at 07:03:59AM -0400, Anne Catherine Raugh wrote:
> 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
Well... I'd say in general that takes some (sometimes a generous
helping of) human intervention to scrape a table from a PDF file in a
way that, say, TOPCAT can plot it.
> 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.)
Me, I'd try the word "structured" rather than machine-readable to
make that difference.
But I still doubt a computer needs to know that difference
generically. Sure, it needs to know that something is a
detached-header, but then, for instance, an open document spreadsheet
with the weather conditions is structured, too, and I claim for
datalink that makes exactly zero difference vs., for instance,
rendered weather tables in PDF: A Datalink client should show it in
the #documentation tree.
> 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
I agree with that for now. But as I said in the parallel post, I'd
much rather wait until we understand what else than #detached-header
might go under *#metadata before introducing such a concept.
> 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.
Oh, and of course there's no need for that distinction if datalink
clients were to treat them identically (which for now I think they'll
do).
Thanks for your insights (at that ungodly hour on top!),
Markus
More information about the semantics
mailing list