Roy et al.,
> Martin's comments on namespace highlight a concern I
> identified whilst doing the research for the SeaDataNet
> specification. Several communities have added large numbers
> of both global and variable attributes with no indication of
> namespace. Not only does this make it difficult to tease out
> what is CF and what is a community extension, but it creates
> an accident in waiting. What happens if CF creates a new
> attribute with a name already in community usage? In my view
> it's too late to introduce a CF namespace and prefer the idea
> that for a CF-compliant file CF should be the default
> namespace, with communities taking responsibility for their
> extensions. This is what I've done for SeaDataNet.
In working up a local metadata profile of CF for use here at the Met
Office, we also spent much time thinking about the 'namespace problem'.
In an early draft of our metadata profile, and after having reviewed
previous discussions (e.g.
https://cf-pcmdi.llnl.gov/trac/ticket/27), we
elected to use the double underscore character sequence ('__') as a
namespace separator. Our namespace prefixes were then mnemonics like
'ukmo' for the Met Office, 'dc' for Dublin Core, 'cim' for the Common
Information Model, and so on. And we devised additional (fairly simple)
machinery to associate the prefixes with target namespaces, just as in
the XML world.
Thus, we envisaged using netcdf attributes along the lines of:
variables:
float myvar(t, y, x) ;
myvar:ukmo__stashcode = "m01s01i123" ;
myvar:ukmo__runid = "abcde" ;
// global attributes
:dc__rights = "Copyright (c) 2013, Acme Wind and Rain Corp." ;
:dc__created = "2013-01-01 ..." ;
In the end, driven by a practical need to release a simpler, more
digestible release 1.0 of our metadata specification, we dropped all the
aforementioned namespace stuff.
As part of some subsequent low-level netcdf work, however, I chanced
upon the fact that the '.' character is not treated in any special way
within netcdf names (or rather, it is one of netcdf's original special
characters, but not one that needs to be escaped in the way that, say,
the ':' character does).
This got me to thinking that the '.' character might be the ideal
namespace separator for use in CF/netCDF attribute names. Since '.' is
not in the set of characters currently permitted in CF attribute names,
we can be reasonably sure that it is not being used in existing
CF-compliant netcdf files.
The '.' character also has collateral appeal for python/java developers
in that it is the familiar namespace separator used by those languages.
Applied to the previous example, then, we'd now have netcdf attributes
such as ukmo.stashcode, ukmo.runid, dc.rights, dc.created, and so on.
Which looks considerably more elegant, IMO.
While in your context, Roy, you might elect to use namespace'd
attributes called sdn.conventions, sdn.foo, sdn.bar, etc. Or bodc.foo,
bodc.bar, etc. for BODC stuff.
Clearly there are several technical issues that would need to be
addressed (e.g. how/when to use the 'cf.' prefix, what would the default
namespace be, how would prefixes and their namespaces be associated, how
should software interpret namespaces, and so on).
But, assuming these could be resolved, what do people think about use of
'.' as a namespace separator? Good idea? Bad idea?
Some recent postings to this list have suggested using a 'cf_' prefix,
with the implied suggestion of a '_' namespace separator. IMHO, this
approach has the limitation that client software would not be able to
disambiguate existing names which include the '_' character. For
example, would the name 'cell_methods' refer to a property called
'cell_methods' in some default namespace, or a property called 'methods'
in the 'cell' namespace? Likewise for some possible new attribute
called, e.g. 'cf_my_new_thing', what namespace would that be in? cf?
cf_my? cf_my_new?
Regards,
Phil
Received on Mon Jan 28 2013 - 03:25:08 GMT
