⇐ ⇒

[CF-metadata] URNs

From: Roy Lowry <rkl>
Date: Fri, 21 Sep 2007 11:49:12 +0100

Hello Jonathan,

I've shifted off Trac onto the list because I feel that this is developing into a separate thread and didn't want to divert the coordinates debate off track. What we gain by including URNs is the ability to use tools that know about netCDF and the URN standard but not about CF. I'm thinking about areas other than CRS here - such as labelling parameters with a URN leading into an ontology. I guess where our viewpoints differ is that I am continually concerned with establishing interoperability, particularly semantic interoperability, between CF and other standards, whereas you have a more self-contained view of CF. From my position I see URNs as interoperability bridges whereas you see then as unecessary redundancy.

Plaintext name to URN conversion is an accident waiting to happen. URNs are designed to be universally unique. Names are not. The whole point of URNs is to provide a permanent, unambiguous label for the concept they represent.

Building URN verification into the CF checker is certainly possible. We've addressed a very similar issue (URI verification) in SeaDatanet using a web-service based solution. All the verifier has to worry about is a simple API call: it needs to know nothing about the URI definition.

Cheers, Roy.

>>> j.m.gregory at reading.ac.uk 9/21/2007 11:02 am >>>
#9: Extensions to CF grid mapping attributes to support coordinate reference
system properties
-----------------------------+----------------------------------------------
  Reporter: pbentley | Owner: cf-conventions at lists.llnl.gov
      Type: enhancement | Status: new
  Priority: low | Milestone:
 Component: cf-conventions | Version: 1.0
Resolution: | Keywords: coordinates datums projections
-----------------------------+----------------------------------------------
Comment (by jonathan):

 Dear Roy

 Thanks for your useful comments.

> (1) I strongly feel that duplication of labelling in both human-readable
 and machine-readable form is highly desirable. ... it should be
 permissible to enrichen CF by including hooks to external resources. URNs
 are a standardised encoding of these hooks.

 I don't like duplication. I wonder what, in fact, we gain by making a link
 to an external resource through a URN. For the netCDF file to be self-
 describing, it has to contain the definition of the projection and the
 ellipsoid. We already have ways of doing some of that, and Phil has
 supplemented them, especially for the ellipsoid. What *extra* information
 would you get by being able to look up the URN elsewhere?

 I do agree that it is useful to include a recognisable name. That is
 helpful because it means a human will know that this is a particular well-
 known case, whereas they might not recognise the array of attributes that
 define the projection or ellipsoid as being that case. But even this
 amount of redundancy is a pitfall. Will we require the cf-checker, for
 instance, to verify that the projection is really the one named, if a name
 is given? If we can't guarantee it is correct, then the name may be
 misleading, and it would not be safe to compare projections just by
 comparing their names. That suggests the names should be regarded as
 informal information. If we include a URN as well, that's definitely
 formal, and it is a necessity that it must be consistent with the name;
 but if it is consistent, why give both in the netCDF file? Software could
 look up the name in an external table to find the URN.

 Your explanation of vertical datums was helpful. Still, I don't think we
 ought to add to the CF standard without fully understanding (as I don't)
 what information is needed in practice. I think that we need a use-case
 for this. We have had requests for vertical datum definition in the past.
 If someone has a real case that we can study involving the need to tie
 data to a sea-level-related datum, that would be helpful.

 We also have to bear in mind that CF is used for model data too. That is a
 reason why I suspect that ellipsoid and projection ought to be separated.
 A model might use a projection but assume a spherical Earth, for example.
 As I've said before, I am less keen on the "combination" of projection and
 ellipsoid in a CRS. I think it should be sufficient to describe them
 separately in standardised ways.

 Best wishes

 Jonathan

-- 
Ticket URL: <http://cf-pcmdi.llnl.gov/trac/ticket/9#comment:15>
CF Metadata <http://cf-pcmdi.llnl.gov/>
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 Fri Sep 21 2007 - 04:49:12 BST

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

⇐ ⇒