I agree with Stephen and Bryan here. I'm really worried about the
current state of standard names for many reasons but one very
practical reason in particular. If the standard name is meant to be
exposed to the user (which presumably it is) then it must logically
appear in user interfaces. Many of the current names are far too long
for this to be sensible because more and more things have been pushed
into the standard name.
Speaking as a tool developer, the only way to support this is to keep
standard names short and sacrifice some precision. Standard names can
then be linked trivially to a more wordy and precise definition via a
simple URL as Stephen describes. Yes, this means an extra step of
indirection but it's an easy one for tool developers to implement.
If you really want a NetCDF file to stand alone and contain all
relevant information then the precise definition of a term can still
appear as a text field in the file.
This proposition is entirely analogous to the OGC concept of having a
Title for a thing (which is human-readable, reasonably short,
imprecise but "good enough") and an Abstract for the same thing (which
allows more space for a wordier and more precise description).
> I completely agree with Bryan's observation that self describing files
> are a mirage.
Agreed. Nothing is ever self-describing *and* standalone. Everything
is described relative to some (implicit or explicit) external set of
conventions or frames of reference.
Jon
On Wed, Apr 9, 2008 at 9:51 AM, Pascoe, S (Stephen) <S.Pascoe at rl.ac.uk> wrote:
>
> > I think we differ on this because I don't want to depend so much on
> the availability
> > of powerful software, as in practice it may not exist. It certainly
> will not exist
> > (experience shows) and be widely available until quite a long time
> (maybe years)
> > after we agree conventions.
>
> Just an idea. If the unique identifiers we were using were URLs, some
> part of the "powerful" software already does exist. Resolve the URL and
> get the definition. This can be done by a human user without specialist
> software of a software agent. This is the approach taken by the
> Semantic Web and the concept of Linked Data (http://linkeddata.org/).
>
> I completely agree with Bryan's observation that self describing files
> are a mirage. The traffic on this list is the best illustration of
> that.
>
> Cheers,
> Stephen.
>
> ---
> Stephen Pascoe +44 (0)1235 445980
> British Atmospheric Data Centre
> Rutherford Appleton Laboratory
>
> -----Original Message-----
> From: cf-metadata-bounces at cgd.ucar.edu
> [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory
> Sent: 09 April 2008 08:51
> To: Lawrence, BN (Bryan)
> Cc: cf-metadata at cgd.ucar.edu; Dave Poulter; jfpiolle at ifremer.fr;
> Jean-Francois PIOLLE; Kenneth Casey; Pierre LeBorgne
> Subject: Re: [CF-metadata] what standard names are for
>
> Dear Bryan (again!)
>
> > I don't buy the argument that CF is self-describing. CF metafiles +
> > the conventions document + software that can interpret the convention
> > and the file lead to something that is "self-describing". If I can
> > write software that pulls out standard names, I can write software
> > that pulls the definition out as an option at the same time. Not only
> can. Should.
>
> I think we differ on this because I don't want to depend so much on the
> availability of powerful software, as in practice it may not exist. It
> certainly will not exist (experience shows) and be widely available
> until quite a long time (maybe years) after we agree conventions. Hence,
> I think CF files should be self-describing as far as that can be
> "reasonably" achieved, so that users can work successfully with them if
> they have at their disposal only the netCDF library. That is, as you
> correctly anticipated, why I don't like the idea of opaque URNs in CF
> files. Opaque URNs would be fine as identifiers in some external tables,
> in which we set up equivalences between alternative names or
> conventions.
>
> But of course I welcome powerful software and convenient tools as well.
> So it is a compromise, like many things in CF, and I don't take the
> "self-describing"
> argument to the ultimate extreme of demanding definitions for everything
> in the file, and so on. I would just rather use reasonably
> self-explanatory terms instead of more opaque "jargon" terms as standard
> names.
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
--------------------------------------------------------------
Dr Jon Blower Tel: +44 118 378 5213 (direct line)
Technical Director Tel: +44 118 378 8741 (ESSC)
Reading e-Science Centre Fax: +44 118 378 6413
ESSC Email: jdb at mail.nerc-essc.ac.uk
University of Reading
3 Earley Gate
Reading RG6 6AL, UK
--------------------------------------------------------------
Received on Wed Apr 09 2008 - 03:50:34 BST
