Hi Jonathan
As usual I haven't read the entire thread. Apologies.
... To be even more of a devils advocate, the urn is completely analogous to any attribute which is self-describing if AND ONLY IF, you already know what the definition of that attribute is (say, for example, the cell method). The same argument applies to a gazeteer ... etc ... self describing only means self describing if you understand the vocabulary ...
... so I would argue that your argument is spurious :-) :-) :-) :-), except for the bit that says, what is the extra information in the external vocabulary? In that regard, I would argue that the external vocabulary is likely to be more precise than any user added information, and less likely to error. If I know that I'm using WGS1984, then I think it would be more accurate to use that information, than to put the definition of WGS1984 in the file. If I'm using BNLSpecial2007, then, yes, I suppose I have to define it.
I think a urn to a more complete description is a *very* useful addition to the self-describing metadata, and would be better than requiring an internal description (given that there is nothing existing that relies on that now ... is there?), which would of course, remain optional.
Bryan
On Wednesday 03 October 2007 15:19:41 Jonathan Gregory wrote:
> Dear Phil
>
> > I think (hope?) the day will come when all of the _standard_
> > CRS information associated with a netCDF variable will be referenced via
> > a single URN-type attribute, e.g.
> >
> > float temp(lat,lon):
> > temp:crs_id = "urn:ogc:def:crs:EPSG:6.3:4326" // OGC-defined URN
> > for WGS 1984 CRS.
> >
> > Clearly it doesn't make sense to repeatedly specify low-level CRS
> > information in thousands of netCDF files. ...
> >
> > However, not all existing netCDF-aware client software is able to
> > understand these URNs. So until these applications have been upgraded,
> > or replaced in favour of more capable solutions, we need to support both
> > the human-readable and computer-readable methods of defining CRS (and
> > indeed other) properties.
>
> I think that the description of the coord ref system in terms of
> projection, ellipsoid and vertical datum can't be dispensed with until the
> day when it is no more difficult to look it up on the net than it is to
> read it directly from the file. Until then, the information has to be in
> the file to make the file self-describing, and I would say that day is a
> long way off, when one considers all the applications, some of them simple
> user-written programs, that want to use the netCDF files.
>
> Also, existing authorities will only cater for commonly used CRSs. To have
> the flexibility to use any CRS, you need a way to describe it. More
> specifically, existing authorities are only interested in the real world,
> whereas our files have to deal with various model worlds as well.
>
> To some extent I am being devil's advocate here, but I would like to know
> what extra information you get about the CRS if you look up the URN than we
> are anyway proposing to store in netCDF attributes. If there is no extra
> information, the URN is not needed to describe the data in the file, which
> is the primary purpose of CF metadata. You could make an argument that the
> URN is useful for other applications which will understand this URN but are
> not capable of understanding our equivalent CF description of the CRS. That
> kind of interoperability would be a wider kind of purpose for CF. I'm not
> arguing against it in principle, but we should be aware that it is a
> different motive for any of the rest of the CF convention. It is then
> essential somehow to guarantee that this redundancy (between the URN and
> the description into which it can be translated) does not lead to
> inconsistency.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20071003/c4ca3f7e/attachment-0002.html>
Received on Wed Oct 03 2007 - 09:24:37 BST
