Re: [WDB-Development] WDB parameter names and the cf metadata standard

[Michael A. <mic...@me...>]

Heiko wrote:
> that looks good. I would suggest an additional function:
> 
> wci.findParametersByCFStandardName(input text)
> 
> which might return several of wdb parameters.

Yes.

> It seems like you use and extend
> http://cf-pcmdi.llnl.gov/documents/cf-standard-names/guidelines to
> construct new standard-names (+ cell method). CF-standard_names are
> not thought to be unique. So maybe you need an an additional ID.

No, the idea is not to produce new standard names (though I have seen one institution/project that argued for adding functions like max/min to the CF standard). I think the CF-standard is fine as is; it is well suited to it's purpose. The proposal here is to ensure that the WDB parameter name (in use by met.no) stays close/"compatible" to the CF standard name.

Standard name + cell method would seem to be unique enough for our purposes.
 
> standard_names will never be complete. Adding new items to CF takes
> weeks to month (much faster than WMO Volume C (grib)) You should open
> for names not in the standard yet.

Not a problem. The only issue would be if the standard is extended by additional qualifications, but that is not likely to occur very often.
 
> CF specifies clearly how to distinguish all parts, i.e. 'at',
> 'assuming', 'in', 'due to' + restricted vocabulary for [component] and
> [surface]. How do you distinguish your additions [cell method] and
> [function]? (Do you mean two brackets means you have to write at least
> one, while one bracket means 'this is optional'?)

Sorry - not very clear in that. Yes - the two brackets is supposed to indicate that one is written.

So: 
air temperature
air temperature [time: maximum within days]

And so on.

> I don't like the [function]: maybe everybody at met.no understands
> 'max air temperature' is the same as 'air temperature [time: maximum]', but
> don't show this to a sensor developer, who will think [xy: maximum]

Note WDB has multiple namespaces (namespaces are distinct domains with different names for the same parameters).

The canonical namespace (namespace 0) would contain the "standard name [cell methods]" form of parameter names. This will be ideally suited for applications that translate to/from NetCDF/cf-metadata names, since it is possible to programmatically generate the cf-metadata standard name from the canonical WDB parameter names and vice versa.

The met.no namespace (namespace 88) has parameters built on the form "function standard name"; e.g.,

air temperature
max air temperature (could be "maximum air temperature", but since the function designations are non-standard, we might as well stick to those we already use in WDB).

The met.no namespace will be the default usage namespace (previously the canonical namespace was default for data provider and parameter, but not for places, where we use a similar system of canonical = machine usage, met.no namespace = human readable). The key to making this work from a WDB point of view is the approach requires minimum maintenance - both the canonical and met.no namespace can be maintained easily based on the cf-metadata standard (the met.no namespace will require a smallish table mapping the function names we use to cell methods). The majority of the maintenance can be handled programmatically. The main weakness of the approach (other than having to rename parameters again) from the database point of view is that people may use the names inconsistently (e.g., use "specific gravitational potential energy" in one case and "specific potential energy" in another in the same database) and that some cf-metadata parameters seem to mix level into the parameter name (which is frowned upon in WDB context). The cf-metadata standard name aliases can be handled if we wish, though.
 
> I have understanding for your approach: "put all metadata into one
> string", but it conflicts with: "make that string easily human
> readable". Question to the developers of graphical applications: How
> many characters will a user accept for a string?
> 
> A used standard name at met.no (LF) which still might be extended by
> due_to_..._assuming_... (excluding your extensions) is:
> 
> atmosphere_mass_content_of_secondary_particulate_organic_matter_dry_aerosol
> 
> We give it the long_name (= display name according to netcdf-user
> guide): SOA

IMO, descriptive names are always better - then I can at least pretend to understand what I'm reading, rather than being completely clueless. ;-)

I think I've mentioned this before in the context of Diana; from WDB's point of view, it is not a problem to implement a separate diana namespace containing all the abbreviations that one wishes. We (as in the WDB group) just do not want any part in having to maintain it, which is another way of saying that I think it would be a bad idea.

Long names are (should) not be a problem from an application developer's point of view; after all, it is just a string. For a user in WDB, longer names should also not be too problematical since WDB supports extensive use of wild cards (e.g., "%atmosphere%" would retrieve all parameters with "atmosphere" in it).

Hope that cleared up some of issues.

Regards,

Michael A.

> On 2010-09-24 15:01, Michael Akinde wrote:
> > Hi all,
> >
> > There is a lot of interest for making the WDB parameter names work
> > better together with the CF metdata standard. This would have many
> > benefits, not least the ability to interface much more easily with
> > other open source projects such as FIMEX, et al. CF Metadata is also
> > increasingly being adopted by many projects as the parameter name
> > standard, so making it easy to use CF metadata would improve the
> > general usability of WDB.
> >
> > There are issues with CF metadata wrt to WDB's use of parameters
> > however. I have summarized the problems, and a proposed solution,
> > here:
> >
> > https://sourceforge.net/apps/trac/wdb/wiki/DevCfParameters
> >
> > The solution requires some significant changes in the WDB data
> > model, which means that it would be best to get these changes done
> > before v1.0.0 if they are to be done at all. At the moment, I think
> > this would probably be worthwhile (it is much easier to discuss
> > metadata based on a standard than having to explain and document the
> > current design).
> >
> > For users of WDB, the main difference will be:
> > - users should shift to a different parameter name space.
> > - the names of some parameters will change (again).
> >
> > Thoughts and comments?
> >
> > Regards,
> >
> > Michael A.
> >