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
