Peter, Ethan etc.
I think it is misleading to talk about everything other than the
coverage range values ("pixels") as metadata. Metadata only makes sense
when you say what you mean by Data. Then metadata can be ABOUT the
data. In the case of Coverages - we create a kind of object (i.e. data)
called coverage and then we can have information ABOUT that coverage
object - and this (creator, owner) is metadata.
Also, I don't like to think of XML encoding as a format since this
usually implies binding to a file organization/structure.
Ron
-----Original Message-----
From: galeon-bounces@xxxxxxxxxxxxxxxx
[mailto:galeon-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ethan Davis
Sent: October 8, 2008 11:37 AM
To: Unidata GALEON
Subject: Re: [galeon] WCS core + extensions
Hi Peter, all,
Peter Baumann wrote:
looks like we "wildly agree" (nice term I learnt recently): in a
GetCoverage response there is the coverage payload + metadata. I do
like the idea of having a canonical + complete metadata set in XML
(ok, GML) I also have advocated that, in case the server erroneously
puts divergent metadata into format header and XML, the XML data prevail.
Quite some folks alternatively want to have a "stripped" response
without XML and MIME encapsulation (or whatever), though. That's where
we have to live with incomplete metadata then - but IMHO this is a
user's informed decision then. Va bene.
I don't see that the "stripped" or "single file" response necessitates
incomplete coverage metadata. It depends on how well (and complete) a
particular coverage format encoding document maps the coverage metadata
into that format. Which of course, also depends on the capabilities of
that format for capturing all the coverage metadata.
A complete mapping may not be an easy goal for many formats. But it
seems an important goal for the format encoding documents to map as
completely as possible both the payload and the metadata into the target
format in a way that is natural to that format. Having the metadata fit
naturally into a format means that the tools that already deal with that
format will have an easier time accessing (and hopefully understanding)
the metadata.
Ethan
