⇐ ⇒

[CF-metadata] what standard names are for

From: Roy Lowry <rkl>
Date: Wed, 09 Apr 2008 15:48:14 +0100

Hi Stephen,

Whether markup inside data files should be URL or URN is something I've considered long and hard. Making use of URLs is simpler, but I worry about having to update thousands of files should a server namespace change. What we really need are stable, standardised URL resolvers accessible to CF.

I also think it's time we resolved the fundamental disagreement on embedding URIs in CF files once and for all. I somehow don't think we're going to get anywhere changing opinions!

Cheers, Roy.

>>> "Pascoe, S (Stephen)" <S.Pascoe at rl.ac.uk> 4/9/2008 9:51 am >>>
 
> 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
-- 
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
Received on Wed Apr 09 2008 - 08:48:14 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒