[CF-metadata] what standard names are for

From: Pascoe, S <S.Pascoe>
Date: Wed, 9 Apr 2008 17:04:29 +0100

 
Roy,

I'm not advocating any old URLs such as
http://mylaptop.badc.rl.ac.uk:8035/temp_service. There would need to be
some level of trust in the longevity of the domain. However, I see this
as separate to the URL/URN debate which I've never really understood.
To my mind URNs rely on authorities (and their associated resolver
service) to turn URNs into URLs. The idea being that we need URNs to
make our identifiers "location independent". How does a URN resolver
differ from sites such as purl.org that provide a persistent URL
relocation service? What is to stop the CF community setting up
cf-namespace.org or whatever? Think of DOIs where you can resolve them
via http://dx.doi.org. We might as well be using
"http://dx.doi.org/..." as our DOI encoding and then it would play
nicely with other Web technologies.

I don't know much about the history of URN resolvers but it strikes me
as odd that URN advocates argue URL domain names aren't stable enough to
serve persistent identifiers and yet URN resolvers clearly haven't
stayed around either (I don't even know if they ever existed). The
possibility of services disappearing isn't completely removed by being
sanctioned by the IANA.

The problem is one of trust in the longevity of domain names and
servers, perhaps because of the youthfulness of the web. This is
separate from how you actually resolve an identifier -- HTTP would work
perfectly well for this and it's here now.

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 Roy Lowry
Sent: 09 April 2008 15:48
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] what standard names are for
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.
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Received on Wed Apr 09 2008 - 10:04:29 BST