The worry about having to update thousands of files should a server namespace change has an interesting corollary with URNs as well. A key point is that stability, and the option of resolvability, is needed (and I would argue, nominally achievable) in either case.
But perhaps we shouldn't address that broad topic extensively on this list, which is only about CF. I wonder if there is an upcoming venue in which the oceanographic (and other?) communities could address URI specification issues as thoroughly as currently possible? And if not, should we create such a venue? Probably discussion of this topic is not right for the CF list either. I will discuss the possibility with Roy off-line (other participation welcome, send us an email and I can create a list if necessary) and post any conclusions to the list.
I do agree that whether the URI is a URL or a URN, CF should either have, or use, a system to resolve these terms and provide the appropriate metadata. So it should be a strong participant in any attempt to resolve the issue.
John
At 3:48 PM +0100 4/9/08, Roy Lowry wrote:
>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
--
----------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Initiative: http://marinemetadata.org || Shore Side Data System: http://www.mbari.org/ssds
Received on Wed Apr 09 2008 - 10:10:32 BST
