Re: [CF-metadata] new standard name request for pH

[Lowry, Roy K]

Hi Christiane,

Please check out the previous postings.  There are in fact 3 pH scales covering 
pH based on a concentration per kg: one based on H+, a second on H+ and 
bisulphate and a third on H+, bisulphate and HF.  We did consider having 4 
Standard names but I was arguing for just 2 based on H+ alone to try and match 
the level of specialism covered with other areas.

The negative log transform between the appropriate concentration term and 'pH' 
has always been taken as read by all involved in the discussion, but maybe we 
should be more explicit when it comes to term definitions.

Oceanographers are moving towards expressing chemical data in the dimension 
moles/kg rather than moles/litre.  We need a standardised convention to 
distinguish these as they have different canonical units and therefore need 
different Standard Names.  I think the approach Jonathan is taking is the most 
sensible way to do this without large scale deprecation of existing names.  We 
must always remember to include definitions and to read them: they are the key 
to eliminating confusion.

Cheers, Roy.


From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Christiane Textor [christiane.tex...@lsce.ipsl.fr]
Sent: 30 April 2009 17:13
To: Lowry, Roy K; Jonathan Gregory
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] new standard name request for pH

Dear all,

I am not an expert ocean acidification at all, but there are some
general questions I have concerning these names for the pH of sea water:

1) large scale medium
Why not use sea_water (or ocean_) as a prefix as we have agreed on?

2) definded_by
For the atmospheric chemistry names we have used expressed_as, why not
use this here as well?

3) definition of pH  (-log(H+))

As far as I know the pH is defined as the negative logarithm of the
concentration of H+ (or whatever else), this is missing in the suggested
names. I would suggest to use expressed_as instead of defined_by to
circumvent this problem.

4) definition of pH (N.B.S or free)

I have checked the different definitions of the pH in sea water and it
seems to me that the NBS and the free pH do not all refer to the
concentration of H+ alone but consider also other ions, please see
http://en.wikipedia.org/wiki?title=Talk:Ocean_acidification#cite_note-zeebe-0
(rather bad page, but still..)

Am I confused?

5) concentration
For the atmospheric chemistry names we have mass_concentration and
mole_concentration which is mass or mole per volume. This means that
concentration always means per unit volume, and not per unit mass.
If you say now concentration per unit mass, this is confusing.

Best regards,
Christiane




___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] new standard name request for pH

[Lowry, Roy K]

Hi Again,

Like it or not the oceanograpghic domain is using:

mass of solute per volume of solvent
mass of solute per unit mass of solvent
moles of solute per unit volume of solvent
moles of solute per unit mass of solute
volume of solute per unit mass of solvent
volume of solute per unit volume of solvent

depending on community within the domain.  Following my understanding of CF 
each of these needs to be addressed by the Standard Name system through a 
consistent syntax.  What we need to do is establish a convention for this, 
which is what I see Jonathan's efforts addressing.  Any advances on his 
conventions obviously need consideration.

Cheers, Roy.

From: Christiane Textor [christiane.tex...@lsce.ipsl.fr]
Sent: 30 April 2009 20:41
To: Lowry, Roy K; Lowry, Roy K
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] new standard name request for pH

Hi Roy,

Concerning my question 4) I am sorry for not having more carefully read
previous postings.

You write about concentration per mass. However, I think this is not
correct as concentration is generally related to volume in CF as far as
I know, see my 5) below. There is mass_concentration and
mole_concentration, but both is per unit volume.

I have checked old postings and I have found that this has been
previously discussed:
 From godin at mbari.org  Wed Jan  3 17:09:34 2007
Date: Wed Jan  3 17:11:17 2007
Subject: [CF-metadata] Proposed standard names for biological model outputs

In text books mole/mass is referred to as molality, but this is not a
commonly used expression. Anyway, I think if we use concentration in
different ways than previously defined, this will lead to confusion.

Best regards,
Christiane

Lowry, Roy K a écrit :
 Hi Christiane,

 Please check out the previous postings.  There are in fact 3 pH
 scales covering pH based on a concentration per kg: one based on H+,
 a second on H+ and bisulphate and a third on H+, bisulphate and HF.
 We did consider having 4 Standard names but I was arguing for just 2
 based on H+ alone to try and match the level of specialism covered
 with other areas.

 The negative log transform between the appropriate concentration term
 and 'pH' has always been taken as read by all involved in the
 discussion, but maybe we should be more explicit when it comes to
 term definitions.

 Oceanographers are moving towards expressing chemical data in the
 dimension moles/kg rather than moles/litre.  We need a standardised
 convention to distinguish these as they have different canonical
 units and therefore need different Standard Names.  I think the
 approach Jonathan is taking is the most sensible way to do this
 without large scale deprecation of existing names.  We must always
 remember to include definitions and to read them: they are the key to
 eliminating confusion.

 Cheers, Roy.

  From:
 cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu]
 On Behalf Of Christiane Textor [christiane.tex...@lsce.ipsl.fr] Sent:
 30 April 2009 17:13 To: Lowry, Roy K; Jonathan Gregory Cc:
 cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] new standard name
 request for pH

 Dear all,

 I am not an expert ocean acidification at all, but there are some
 general questions I have concerning these names for the pH of sea
 water:

 1) large scale medium Why not use sea_water (or ocean_) as a prefix
 as we have agreed on?

 2) definded_by For the atmospheric chemistry names we have used
 expressed_as, why not use this here as well?

 3) definition of pH  (-log(H+))

 As far as I know the pH is defined as the negative logarithm of the
 concentration of H+ (or whatever else), this is missing in the
 suggested names. I would suggest to use expressed_as instead of
 defined_by to circumvent this problem.

 4) definition of pH (N.B.S or free)

 I have checked the different definitions of the pH in sea water and
 it seems to me that the NBS and the free pH do not all refer to the
 concentration of H+ alone but consider also other ions, please see
 http://en.wikipedia.org/wiki?title=Talk:Ocean_acidification#cite_note-zeebe-0
  (rather bad page, but still..)

 Am I confused?

 5) concentration For the atmospheric chemistry names we have
 mass_concentration and mole_concentration which is mass or mole per
 volume. This means that concentration always means per unit volume,
 and not per unit mass. If you say now concentration per unit mass,
 this is confusing.

 Best regards, Christiane




 ___ CF-metadata mailing
 list CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
==
Christiane Textor
Laboratoire des Sciences du Climat et de l'Environnement
Unite Mixte de Recherche CEA-CNRS-UVSQ

LSCE/IPSL laboratoire CEA/CNRS/UVSQ
Saclay, Orme des Merisiers,
Bat. 701, Piece 3b, Point Courrier 129
F-91191

Re: [CF-metadata] new standard name request for pH

[Lowry, Roy K]

Hi John,

Your suggestion that we disallow storage of NBS scale pH in CF by not creating 
a Standard Name for it worries me.  We have significant quantities of NBS-scale 
pH in BODC (from estuarine systems and the days before ocean chemists 
discovered the kilogram) that we may wish to put into CF in the future.  Whilst 
conversion based on approximation to free_scale is possible in some (but not 
all) cases (need additional data), it's something I'd rather not do.  I would 
much rather label precisely and leave any manipulations up to the user who is 
aware of the proposed usage and what is fit for that purpose.

My attraction to Jonathan's simple 'pH_in sea_water' is that it gives us a way 
of handling data in CF where 0.1 pH units don't matter.  We have one dataset 
monitoring waters off a chrome plating plant where pH varies between 2 and 6. 
At the same time I am acutely aware of the effects errors of that magnitude 
have on deep ocean carbon budget calculations.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Graybeal
Sent: 02 May 2009 01:28
To: CF Metadata List; Lowry, Roy K
Subject: Re: [CF-metadata] new standard name request for pH

Hi everyone,

Thanks very much for considering and responding to the pH terms
proposal.  To respond, I spent considerable time being educated by our
in-house pH expert, even reading pages myself from the referenced book
[1], and reviewed this email with him. So I claim this email
represents a high level of expertise in this scientific field. I
apologize for the length, but it seemed necessary to present
justifying details.

To recap, the original proposal as revised was for 4 names related to
pH:
A)  sea_water_pH_NBS_scale  (moles/liter)
B)  sea_water_pH_free_scale (moles/kg)
C)  sea_water_pH_total_scale  (moles/kg)-- the one we care about
D)  sea_water_pH_seawater_scale  (moles/kg)

Through this thread we have had several suggestions for replacements
[5], most recently arriving at
a) pH_of_sea_water_defined_by_moles_of_hydrogen_ion_per_unit_mass
b) pH_of_sea_water_defined_by_mole_concentration_of_hydrogen_ion
c)
mole_concentration_of_H_and_HSO4_per_unit_mass_in_sea_water_expressed_as_pH
d) mole_concentration_of_H_and_HSO4_and_HF_per_unit_mass
in_sea_water_expressed_as_pH
e) (added) pH_of_sea_water

I believe the focus of these responses was on the concentration of the
solution, but this mis-states the actual chemical definition of this
particular concept. (Unfortunately we incorrectly presented this in
the original definitions for B, C, and D.)  In the reference[1]  it is
made clear that:
(a) pH is strongly affected by abundance of hydrogen (actually
hydrate) ions, but is not defined by their quantity; it is determined
according to the *activity* of those ions, and this is not a linear
relationship (though it is close to 1 in some regimes)[2].   We will
change the proposed definitions to replace 'concentration' with
'activity'; my apologies for this error.
(b) The use of the NBS scale is not recommended for sea water[3], as
errors will be induced (up to at least 0.1 units in situ); in this
light we propose to simply withdraw [A] from consideration, especially
as we don't need it.
(c) There are significant differences in the values obtained for these
different quantitiies, up to .12 units; thus to say just
'pH_of_sea_water' is to have a very loose concern about the accurate
meaning of the so-labelled pH values[4]. For comparison, measurements
are often made, and needed, at the level of 0.0005 units.
(d) All 3 of {B, C, D} above are in regular use, but (C) is the most
promising for the common reference[4].

Additionally, the units are expressed as noted above by common
convention (see for example UCUM units section on pH [5]), in order to
make certain conversions handy for the enlightened.  Yet the second
sentence of the following statement does not hold true for pH, given
the depths at which these measurements are being made:

On Apr 30, 2009, at 9:22 AM, Jonathan Gregory wrote:
 Boussinesq models (most ocean climate models are Boussinesq) treat
 density
 as constant 1000 kg m-3 except in the computation of pressure
 gradients, where
 it matters to the dynamics. Therefore in dealing with concentrations
 of
 tracers, per kg and per litre are identical and to choose one or the
 other
 would be arbitrary and hence unhelpful for data exchange.

We therefore do not believe a substitution of moles/liter or moles/
m**3 is appropriate for the canonical moles/kg, as this would force
most practitioners to convert their data before naming it with this
name. [7] Obviously if there is a set of practitioners that are
working with seawater pH using a different canonical unit, that would
be another matter to consider; we think it is unlikely that any
observationalists are doing so.

So, in summary, the longer, explicit terms being proposed are so
approximate (for the reasons descrX

[CF-metadata] Salinity units

[Lowry, Roy K]

Dear All,

During an exercise with Alison mapping the CF Standard Names to a units 
vocabulary in the BODC vocabulary server I noticed that the units for salinity 
were '1.00E-03', i.e. parts per thousand.  My understanding in that since the 
introduction of the Practical Salinity Scale that salinity is dimensionless 
with units of '1'.  Is there agreement for our changing the units in the 
Standard Name table?

Cheers, Roy.


-- 
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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Standard name definitions ... are these formal or flexible

[Lowry, Roy K]

Hi Bryan,

Steve's query presents something of a Standard Names crossroads. 'Chlorophyll' 
is a very generic word covering a group of pigments (chlorophyll-a, 
chlorophyll-b, divinyl chlorophyll-a, etc.) that some analytical techniques can 
resolve whilst others cannot. 'Chlorophyll' is also a proxy for 'phytoplankton' 
biomass, which brings us into the semantics of the word 'phytoplankton': for 
some methodologies it is anything small and green, but other methodologies are 
quite selective about the plankton community for which chlorophyll is a proxy 
(e.g. chlorophyll extracted from a 20um filter is dominantly from diatoms).

As I see it we can either keep the Standard Name very generic (as you suggest 
and my gut tells me you're right) and use the long name to spell out the gory 
details or go down the road I have taken with the BODC PUV which currently has 
176 'chlorophyll' parameters.  The only problem with the simple (feasible?) 
approach is that some communities are moving towards using the Standard Name as 
the parameter identifier and it's inevitable that somebody somewhere will 
produce a file containing two types of 'chlorophyll' with the expectation that 
the Standard Name will identify and distinguish them.  Do we need some 
expectation management to discourage this?

Incidentally, I'm wondering where Steve got his definition of 
'concentration_of_suspended_matter_in_sea_water' (which incidentally was 
deprecated in version 12 and replaced by 
mass_concentration_of_suspended_matter_in_sea_water) from. The definition I 
have (and I checked it's the same in the HTML version on the CF site) for 
mass_concentration_of_suspended_matter_in_sea_water is 'Mass concentration 
means mass per unit volume and is used in the construction 
mass_concentration_of_X_in_Y, where X is a material constituent of Y. A 
chemical species denoted by X may be described by a single term such as 
'nitrogen' or a phrase such as 'nox_expressed_as_nitrogen', which makes no 
mention of ''Determined by filtration, drying and then weighing'.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Bryan Lawrence
Sent: 28 July 2009 19:17
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Standard name definitions ... are these formal or 
flexible

Hi Stephen

Alison is buried with CMIP5 problems at the moment, so may not get to this 
query for a wihle. For my tuppence worth, the method by which something is 
measured should not be in the definition, since the standard name is supposed 
to be a geophysical quantity, however measured. We've been over this ground 
other times.

So, I think there is a case to fix the definition here ... (he says, knowing 
nothing about the ins and outs of this specific example).

Bryan

On Tuesday 28 July 2009 12:01:20 Stephen Emsley wrote:
 Hi all



 I am currently sifting through the Standard Name table for potential 
 candidates for naming geophysical products for a remote sensing satellite 
 (ESA/GMES Sentinel 3). One of our data products is the concentration of 
 suspended matter in sea water (TSM). I note that there is a standard name for 
 the same. However, on examining the description for this standard name I 
 discover the phrase 'Determined by filtration, drying and then weighing'.



 My question is: How formally defined are the standard names? Could a  
 satellite derived TSM concentration have a standard name 
 concentration_of_suspended_matter_in_sea_water or must a new standard name be 
 devised and proposed that, for instance, includes _from_satellite. Or, rather 
 than proposing a new standard name, would our proposal be to widen the 
 definition of the standard name currently within the table by removing the 
 phrase concerning its measurement.



 Similarly, the concentration_of_chlorophyll_in_seawater description targets 
 in vitro assay using HPLC or fluorimetry and specifies Chlorophyll-a rather 
 than the assemblage of pigments that would be detected using spectrometry 
 from satellite.



 Any advice appreciated. Are there any satellite ocean colour people on the 
 list pondering the same questions vis-à-vis naming data products?



 Many thanks

 Steve



 -

 Dr Stephen Emsley

   ARGANS Limited  
   Tel: +44 (0)1752 764 289

 Unit 3 Drake Building
 Mobile: +44 (0)7912 515 418

Tamar Science Park 
   Fax: +44 (0)1752 772 227

   Derriford, Plymouth, PL6 8BY
   sems...@argans.co.uk mailto:sems...@argans.co.uk

   
Skype(tm): archonsme

 

Re: [CF-metadata] Standard name definitions ... are these formal or flexible

[Lowry, Roy K]

Hi Bryan,

We have the technology and some of the content.  I have been maintaining a 
mapping between the Parameter Discovery Vocabulary (PDV) used by SeaDataNet and 
Standard Names to allow us to automatically populate SeaDataNet metadata 
documents from CF data files. (I do have to confess that doing this for the 
version 12 new term explosion is currently in my 'pending' tray).

The PDV is populated with grouping terms like 'Metal concentrations in the 
atmosphere', which is represented by the URL 
http://vocab.ndg.nerc.ac.uk/term/P021/current/MTAT The resulting document gives 
matches to about 25 Standard Names (the URLs with 'P071' in them) as well as 
GCMD (P041), SeaDataNet parameter groups (P031) ISO topic categories (P051) and 
BODC usage vocabulary terms (P011).

The grouping terms and mappings have been done by me and are therefore limited 
by my knowledge of the atmospheric science domain.  Suggestions for additional 
grouping terms (together with the Standard Names that should be included) or 
suggestions for modifications to what I've already done from the CF community 
would be welcomed.

Cheers, Roy.


-Original Message-
From: Bryan Lawrence [mailto:bryan.lawre...@stfc.ac.uk]
Sent: 29 July 2009 09:56
To: Lowry, Roy K
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Standard name definitions ... are these formal or 
flexible

Hi Roy

Glad that it looks like Steve's specfiic problem isn't a problem given the name 
change and definition you found.

However:

You've opened Pandora's box a bit (we've been hammering around the edges for a 
while).
I can feel the o-word coming on ...

It's been incoming in the family chemistry sense, and in clouds, and anywhere 
where we have a geophysical quantity that has a generic type and specific 
sub-types. In the chemistry case it's about what equations the model can 
support, and in the observation cases it can be about distinguishing between 
what can be observed - some things can only observe/simulate at the generic 
level, others at more specific levels.

My feeling is that people should mark up their data with standard names that 
most accurate define what has been measured (but not how). However, to compare 
things in this situation we need the relationships between the standard names 
... so folk wanting to compare apples and oranges can do so at the fruit level.

 containing two types of 'chlorophyll' with the expectation that the Standard 
 Name will identify and distinguish them.  Do we need some expectation 
 management to discourage this?

Well, no, if they are two different types of chlorophyll then there should be 
two different standard names (or 176), but it should also be clear that they 
are types of chlorophyll ... and we should have a standard name for that, but 
the data wouldn't neeed to be marked up with it, that'd be implicit in the 
relationships that we standardise.

That seems like an obvious goal ...

Bryan

--
Bryan Lawrence
Director of Environmental Archival and Associated Research
(NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC)
STFC, Rutherford Appleton Laboratory
Phone +44 1235 445012; Fax ... 5848;
Web: home.badc.rl.ac.uk/lawrence

-- 
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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Dealing with large numbers of flag values innetcdf cf

[Lowry, Roy K]

Hello Martin,

There is another possible solution to your problem, which we are looking at for 
dealing with a data source flag to be used with the GEBCO bathymetric grid.  
This is to put a URI base into an attribute that when concatenated with a flag 
values gives the flag definition from a vocabulary server.  For example, having 
a flag_definition attribute like:

URI_base='http://vocab.ndg.nerc.ac.uk/term/GGS1/current/'

For a flag value of 1, the resulting URL is:

http://vocab.ndg.nerc.ac.uk/term/GGS1/current/1

which is a live NERC Vocabulary Server URL returning the flag definition 
attributes in a SKOS document.

I appreciate that this moves away from fully self-contained CF files and that a 
standardised syntax for the URI base encoding is required, but I think this 
provides a scalable solution to the flag definition problem.

Cheers, Roy. 


-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of martin.juc...@stfc.ac.uk
Sent: 27 October 2009 10:45
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Dealing with large numbers of flag values innetcdf cf

Thanks for the responses.

Seth is right, I was looking for an alternative to having a gigantic 
flag_meanings attribute. 

I have tried Seth's approach, but can’t get it past the cf-checker. There 
appears to be a character set restriction: I can get the first 547 flag_meaning 
strings accepted if I remove all the -, . and , characters. I'm 
reasonably sure there are no control characters in the following strings which 
could be responsible for the error message that I get (ERROR (3.5): Invalid 
syntax for 'flag_meanings' attribute) when I increase the number of 
flag_meanings to 550. Could it be something to do with the string length (16472 
characters)?

I could try abbreviating the flag_meanings, but this would either be tedious 
work by hand or liable to create confusion if done automatically. If you could 
point me to some information about exactly what string format is acceptable, 
that would be very helpful.
 
To answer John's question: I'm currently using netcdf 3, in IDL -- I'm not sure 
what the options for upgrading to netcdf 4 are.

Cheers,
Matin

 -Original Message-
 From: Seth McGinnis [mailto:mcgin...@ucar.edu]
 Sent: 26 October 2009 23:13
 To: John Graybeal; Juckes, Martin (STFC,RAL,SSTD)
 Cc: cf-metadata@cgd.ucar.edu
 Subject: Re: [CF-metadata] Dealing with large numbers of flag values
 innetcdf cf
 
 On Mon, 26 Oct 2009 12:16:17 -0700
  John Graybeal grayb...@marinemetadata.org wrote:
 Love the question! :-
 
 Are you saying every map location has one index value, which is one of
 the
 numbers from 1 to 827?  So these are mutually exclusive?  Or are
 there 827
 flag values assigned independently for each map location?
 
 It sounds to me like it's the former case, and the problem is that
 concatenating 827 flag values into a single string attribute makes
 something that is easy for a machine to interpret, but impenetrable to
 the human reader.
 
 As I read section 3.5, there are no other options for encoding the
 information according to spec; a gigantic flag_meanings attribute is
 the right answer.
 
 But if the issue is really usability, I think the answer is not to do
 it differently, but just to add an extra attribute that presents the
 same information in a more user-friendly format.  You could add an
 attribute named something descriptive, like category_legend, and
 pair the values  meanings up, one per line.  Then you'd end up with
 something that looks like this:
 
 
 float landtype(yc, xc) ;
 landtype:long_name =Land cover type ;
 landtype:standard_name =land_cover ;
 landtype:flag_values = 1.f, 2.f, 3.f, 4.f, 5.f, 6.f, 7.f, 8.f,
 9.f,
 10.f, 11.f, 12.f, 13.f, 14.f, 15.f, 16.f, 17.f, 18.f, 19.f, 20.f, 21.f,
 22.f,
 23.f, 24 .f;
 landtype:flag_meanings =Urban_and_Built-up_Land
 Dryland_Cropland_and_Pasture Irrigated_Cropland_and_Pasture
 Mixed_Dryland/Irrigated_Cropland_and_Pasture Cropland/Grassland_Mosaic
 Cropland/Woodland_Mosaic Grassland Shrubland Mixed_Shrubland/Grassland
 Savanna
 Deciduous_Broadleaf_Forest Deciduous_Needleleaf_Forest
 Evergreen_Broadleaf
 Evergreen_Needleleaf Mixed_Forest Water_Bodies Herbaceous_Wetland
 Wooden_Wetland Barren_or_Sparsely_Vegetated Herbaceous_Tundra
 Wooded_Tundra
 Mixed_Tundra Bare_Ground_Tundra Snow_or_Ice ;
 landtype:category_legend =\n,
1: Urban and Built-up Land \n,
2: Dryland Cropland and Pasture \n,
3: Irrigated Cropland and Pasture \n,
4: Mixed Dryland/Irrigated Cropland and Pasture \n,
5: Cropland/Grassland Mosaic \n,
6: Cropland/Woodland Mosaic \n,
7: Grassland \n,
8: Shrubland \n,
9: Mixed Shrubland/Grassland \n,
10: Savanna \n,
11: Deciduous Broadleaf Forest \n,

Re: [CF-metadata] Dealing with large numbers of flag values innetcdf cf

[Lowry, Roy K]

Hi John,

Yes, there is a URL of the form:

http://vocab.ndg.nerc.ac.uk/list/GGS1/current/

that returns all the flags (currently only three as we have yet to fully 
populate the vocabulary).

Note the term 'current' in the URL.  This specifies that the current version 
should be served.  However, if you want to be absolutely sure the external 
definitions and the internal reference match, then you can explicitly specify 
the version number.  

Compare and contrast two version of the GEBCO flag list using:

http://vocab.ndg.nerc.ac.uk/list/GGS1/1/
and
http://vocab.ndg.nerc.ac.uk/list/GGS1/2/

Cheers, Roy.

-Original Message-
From: John Caron [mailto:ca...@unidata.ucar.edu] 
Sent: 27 October 2009 13:17
To: Lowry, Roy K
Cc: martin.juc...@stfc.ac.uk; cf-metadata@cgd.ucar.edu; Weatherall, Pauline
Subject: Re: [CF-metadata] Dealing with large numbers of flag values innetcdf cf

Lowry, Roy K wrote:
 Hello Martin,
 
 There is another possible solution to your problem, which we are looking at 
 for dealing with a data source flag to be used with the GEBCO bathymetric 
 grid.  This is to put a URI base into an attribute that when concatenated 
 with a flag values gives the flag definition from a vocabulary server.  For 
 example, having a flag_definition attribute like:
 
 URI_base='http://vocab.ndg.nerc.ac.uk/term/GGS1/current/'
 
 For a flag value of 1, the resulting URL is:
 
 http://vocab.ndg.nerc.ac.uk/term/GGS1/current/1
 
 which is a live NERC Vocabulary Server URL returning the flag definition 
 attributes in a SKOS document.
 
 I appreciate that this moves away from fully self-contained CF files and that 
 a standardised syntax for the URI base encoding is required, but I think this 
 provides a scalable solution to the flag definition problem.
 
 Cheers, Roy. 

Hi Roy:

If I was an application trying to use this feature, i would like to be able to 
download all the possible values for this flag enumeration with one call to 
your server. Is that possible?

I guess the other concern with external tables is ensuring that the writer and 
the reader really have the same table. Is there some way to ensure that?


-- 
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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] CF point observation Conventions ready for review

[Lowry, Roy K]

Thanks Rich,

(1) Perils of copy and paste after travel hell.  Definitely meant variable z. 
Thanks for picking it up.

(2) It's not that we don't distinguish, it's that measurements at fixed t,z 
with variable x,y is something we've never encountered and therefore have never 
given it a name.  The closest we come is grab samples or surface water samples 
from a cruise, but we consider that as a 2-D trajectory - it's just lower 
frequency sampling than a TSG.  If I did handle data like you describe I would 
ceratinly be looking for a different feature type label for them.

Cheers, Roy.


From: Richard Signell [rsign...@gmail.com]
Sent: 15 November 2009 15:00
To: Lowry, Roy K
Cc: ngalbra...@whoi.edu; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] CF point observation Conventions ready for review

Roy,

I come from this community also and agree that the feature types you
mention need be representable as feature types in the CF Data Model to
be effective for the oceangraphic community.

Two minor clarifications:

1.  3D-trajectory - set of measurements with variable x, y, t and a
single spatial z.  Example is the thermosalinograph record from an AUV
mission.  It is also applicable to a yo-yo CTD station, mirroring
Chris's comments on atmospheric profiles with variant x,y.

Did you mean variable z here?

2. So you don't distinguish between time series as a point and just
scattered x,y,z points with no specific time, or each with single
time?

-Rich

On Sun, Nov 15, 2009 at 7:23 AM, Lowry, Roy K r...@bodc.ac.uk wrote:
 Dear All,

 I come from Nan's community with the added complication of exposure to CSML 
 through working with NDG.  From this position in BODC we have developed a 
 collection of feature type names that my intention is to map to the CF 
 feature type names once John's work is complete.  As I watch the development 
 of the proposal I'm starting to get uneasy feelings that this mapping is 
 getting harder as the feature type definitions become more fluid, which 
 echoes Nan's feelings that the proposal is drifting away from her domain.

 The feature terms we use for observational data in BODC are:

 Profile - single set of measurements with single (by assumption) x, y, t 
 values but varying spatial z.  An example is a single, fully processed (i.e. 
 binned) CTD cast.

 Profile collection - an aggregation of profiles into a single data object.  
 An example is all the CTDs from a section or a cruise.

 Profile series - a set of measurements with single x,y a fixed set of spatial 
 z values and progessing t. An example is a single moored ADCP deployment 
 record.

 Point - a set of measurements with single x, y, and z and progressing t.  
 Example is a single moored recording current meter record.

 Point collection - an aggregation of point features in a single container.  
 Example is all the records from all the current meters on a mooring or 
 deployed on a cruise.

 Spectrum series -  a set of measurements with single x,y a fixed set of 
 non-spatial z values and progessing t. An example is a power spectrum time 
 series from a wave recorder.

 2D-trajectory - a set of measurements with variable x, y, t and a single  
 spatial z.  Example is the thermosalinograph record from a cruise.

 3D-trajectory - set of measurements with variable x, y, t and a single 
 spatial z.  Example is the thermosalinograph record from an AUV mission.  It 
 is also applicable to a yo-yo CTD station, mirroring Chris's comments on 
 atmospheric profiles with variant x,y.

 I think that Nan and most of the observational oceanographic community 
 recognise these concepts and consequently, if a mapping to them to your 
 feature definitions is maintained then it will help keep us on board.

 Note that the difference between 'point' and 'point collection' is important 
 to me as on observational data manager, which is a different perspective to 
 an observational data ingestor.

 Cheers, Roy.

 
 From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
 Behalf Of Nan Galbraith [ngalbra...@whoi.edu]
 Sent: 13 November 2009 17:42
 To: cf-metadata@cgd.ucar.edu
 Subject: Re: [CF-metadata] CF point observation Conventions ready for review

 Hmm, I think this is an unfortunate choice of terms - we make a fairly
 clear distinction between profile data and station data - but I don't think
 it's just a local semantic problem.

 While I realize that the storage for multiple profiles and multiple-depth
 time series data are similar,  I still don't think this is a workable system
 for us.  If we are to treat each time stamp as a profile, then
 float alt(profile, z)
 indicates that we need a T-dimensioned depth, which is not just
 inefficient,
 but misleading - our depth variable is not measured and we don't KNOW
 how it varies with time, for the most part.

 Going back to the semantics, moored station data are different from

Re: [CF-metadata] CF point observation Conventions

[Lowry, Roy K]

Hi Nan,

It's a terminology issue. The feature type terms were coined for local use 
under pressure (so much pressure that I even failed to consult the CSML feature 
type names!) to describe data in one of our data schemas, which doesn't include 
single instantaneous measurements.

It's the concepts that are the important thing, which we identify by neutral 
keys.  I'm quite happy to use different terms to describe the concepts 
providing the concept definitions match exactly. The only reason I exposed them 
was to ensure CF didn't head off into concepts that didn't map. Getting a set 
of terms for these concepts that are universally agreed would be worthwhile.  
Bringing our local terms into line with CSML would be an obvious first step, 
which I'll try and do next week (currently on travel) in conjunction with 
checking through John Caron's mappings to the proposed CF feature types

Meanwhile if you've any further suggestions for change (or additional 
observational feature types you'd like to see) let me know and I'll do my best 
to fall into line.

Cheers, Roy.

From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Nan Galbraith [ngalbra...@whoi.edu]
Sent: 20 November 2009 16:26
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] CF point observation Conventions

Thanks, Roy.

There's something not quite symmetrical in this, either - maybe it's
just terminology, maybe not.

A time series is conceptually identical to a profile, just turned on its side
so time is the single incrementing dimension, instead of depth.  The difference
turns out to be important in the proposal mainly because of the way we'd
aggregate profiles vs time series.

A point, in my lexicon, is an atomic unit, a single measurement at a single
x,y,z,t. Is there a single point in your feature types? Why assign the term
point to a set of measurements with single x, y, and z and progressing t, as
opposed to a set of measurements with single x, y, t values but varying z?

Cheers -
Nan


Lowry, Roy K wrote:

..

The feature terms we use for observational data in BODC are:

Profile - single set of measurements with single (by assumption) x, y, t values 
but varying spatial z.  An example is a single, fully processed (i.e. binned) 
CTD cast.

Profile collection - an aggregation of profiles into a single data object.  An 
example is all the CTDs from a section or a cruise.

Profile series - a set of measurements with single x,y a fixed set of spatial z 
values and progessing t. An example is a single moored ADCP deployment record.

Point - a set of measurements with single x, y, and z and progressing t.  
Example is a single moored recording current meter record.

Point collection - an aggregation of point features in a single container.  
Example is all the records from all the current meters on a mooring or deployed 
on a cruise.

Spectrum series -  a set of measurements with single x,y a fixed set of 
non-spatial z values and progessing t. An example is a power spectrum time 
series from a wave recorder.

2D-trajectory - a set of measurements with variable x, y, t and a single  
spatial z.  Example is the thermosalinograph record from a cruise.

3D-trajectory - set of measurements with variable x, y, t and a single spatial 
z.  Example is the thermosalinograph record from an AUV mission.  It is also 
applicable to a yo-yo CTD station, mirroring Chris's comments on atmospheric 
profiles with variant x,y.

I think that Nan and most of the observational oceanographic community 
recognise these concepts and consequently, if a mapping to them to your feature 
definitions is maintained then it will help keep us on board.

Note that the difference between 'point' and 'point collection' is important to 
me as on observational data manager, which is a different perspective to an 
observational data ingestor.

Cheers, Roy.




--
***
* Nan Galbraith(508) 289-2444 *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543*
***




--
***
* Nan Galbraith(508) 289-2444 *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543*
***




-- 
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.

___
CF

Re: [CF-metadata] seeking CF name for total water column height

[Lowry, Roy K]

Dear All,

I think a new Standard Name 'sea_floor_depth_below_sea_surface' is what's 
needed here.  My definition for this would be 'The vertical distance between 
the sea surface and the seabed at a given point in space and at a given instant 
in time or averaged over a time interval that is significantly less than a 
tidal cycle (1 hour or less).' This may seem complicated, but is needed to 
cover BPRs which do some averaging to smooth out waves.  My take on 
'height_above_sea_floor' would be as the z co-ordinate for something inside a 
water body. 

May be worth pointing out to Jeff that there is already 
'sea_water_pressure_at_sea_floor' for BPR data that haven't been converted to 
depth.

I've expressed this as a depth rather than as a height to be consistent with 
'sea_floor_depth_below_sea_level' and so we don't end up with different terms 
for the same quantity depending upon whether one is looking upwards or 
downwards.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jeff deLaBeaujardiere
Sent: 26 January 2010 22:22
To: cf-metadata@cgd.ucar.edu
Cc: Mike Garcia
Subject: [CF-metadata] seeking CF name for total water column height

Hello-

I am a new subscriber. We are hoping to adopt CF names wherever possible in the 
context of the Integrated Ocean Observing System (IOOS) Sensor Observation 
Services (SOS). Not all phenomena we measure have immediately apparent CF 
names, however. We are using this URL as a reference:
http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/cf-standard-name-table.html

The first example is total water column height as derived from a bottom 
pressure recorder associated with a tsunami warning buoy. This is not 
sea_surface_height_above_reference_ellipsoid or _above_sea_level. It might be 
height_above_sea_floor but we're not really sure what that refers to (height of 
what?).

Is there a standard name present or planned that is equivalent to 
total_water_column_height?

Thanks for any information,
Jeff DLB

-- 
Jeff de La Beaujardière, PhD
Senior Systems Architect, Data Integration Framework
Integrated Ocean Observing System (IOOS) Program Office
National Oceanic and Atmospheric Administration
1100 Wayne Ave #1225, Silver Spring MD 20910 USA
+1 301 427 2427
jeff.delabeaujardi...@noaa.gov 
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] seeking CF name for total water column height

[Lowry, Roy K]

Hi Jeff,

My motives for 'looking down' rather than 'looking up' were that we already had 
a 'sea_floor_depth_below_mean_sea_level' and established practice with CF name 
development has been to be as consistent as possible with name structure.  
Jonathan Gregory has led this development in the past - let's see what his take 
is on the best name syntax.

The issue of encoding sea level measurements relative to reference datums other 
than MSL has been discussed on the list at length previously and I don't recall 
our ever reaching a satisfactory resolution.  It might be worth your having a 
trawl around the archives or waiting for somebody with a better memory than me 
to summarise where the discussion had reached.

Incidentally, I have seen the 'datum' for streams without a datum described as 
'tide gauge zero', which often has a physical manifestation such as a metal peg 
driven into a wall.

Cheers, Roy.  

-Original Message-
From: Jeff deLaBeaujardiere [mailto:jeff.delabeaujardi...@noaa.gov] 
Sent: 28 January 2010 14:06
To: Lowry, Roy K
Cc: John Graybeal; cf-metadata@cgd.ucar.edu; Mike Garcia
Subject: Re: [CF-metadata] seeking CF name for total water column height

I should mention that there are other types of water level measurements for 
which we will want names. These are instruments such as tide gauges that 
measure water relative to a reference datum (such as mean lower low water, or 
highest astronomical tide), or stream gauges that measure relative to the 
station itself but not a formal datum.

I spoke about this yesterday afternoon with some water-level experts at NOAA 
CO-OPS, and we felt that three new CF names like the following might suffice:

sea_floor_depth_below_sea_surface[*]
water_level_with_reference datum (or above instead of with)
water_level_without_reference datum

[*] Looking at this one again, I wonder whether 
sea_surface_height_above_sea_floor would be more appropriate. NDBC had 
suggested total_water_column_height.

-Jeff DLB

Lowry, Roy K wrote:
 Hi John,
 
 Ah, I thought you were objecting to having different names for different 
 averaging intervals.  Let's see if I can improve the definition.  
 
 There are three varieties of water depth (sea_floor_depth_below_sea_surface) 
 that I've encountered.
 
 1 Instantaneous measurements collected at high frequency over a short time 
 interval designed to quantify waves.  These are normally reduced to a raft of 
 wave statistics by processing on board the instrument and I've certainly 
 never seen them as a stream and so didn't see any point in setting up a 
 separate standard name.
 
 2 Measurements averaged over a sampling interval (an hour or shorter) to 
 filter out variance caused by normal waves but not tide (or unusually long 
 period waves).  This is Jeff's stream, and also pretty much what is measured 
 by an echosounder mounted on all but the smallest ship.
 
 3 Long-term averages or nominal calculations by models that filter out (or 
 ignore in the case of models) the variances caused by waves and tide - which 
 are covered by the existing Standard Name 
 'sea_floor_depth_below_mean_sea_level'.
 
 How about 'The vertical distance between the sea surface and the seabed as 
 measured at a given point in space including the variance caused by tides and 
 possibly waves'? Or can you do better?
 
 Cheers, Roy. 
 
 -Original Message-
 From: John Graybeal [mailto:jbgrayb...@mindspring.com] 
 Sent: 27 January 2010 23:01
 To: Lowry, Roy K
 Cc: cf-metadata@cgd.ucar.edu; Mike Garcia
 Subject: Re: [CF-metadata] seeking CF name for total water column height
 
 I have no concern about whether this stream needs labeling. My concern  
 is whether you are defining something in the definition which is in no  
 way described by the label, and which will prevent that label being  
 used for other variables in other streams.
 
 Put another way, what should the models that calculate the nominal  
 sea_floor_depth_below_sea_surface -- or an averaged value longer than  
 1 hour -- call their values?
 
 John
 
 
 On Jan 27, 2010, at 12:54, Lowry, Roy K wrote:
 
 Hi John,

 Simple pragmatism.  It's what a BPR data stream tends to contain and  
 so it needs labelling.

 Cheers, Roy.

 
 From: John Graybeal [jbgrayb...@mindspring.com]
 Sent: 27 January 2010 16:41
 To: Lowry, Roy K
 Cc: Jeff deLaBeaujardiere; cf-metadata@cgd.ucar.edu; Mike Garcia
 Subject: Re: [CF-metadata] seeking CF name for total water column  
 height

 Any particular reason that you are biased for this name representing
 only a short-term value?  Seems to me there is equally the need for a
 (measured or modeled) value that would be defined exactly the same
 way, but without the time qualifiers.

 In general, when CF has a measured observable, the name makes no
 statement about whether the variable has been measured
 instantaneously, or for 1 hour, or for one month.  It's time-neutral.
 This has several advantages.

 I

Re: [CF-metadata] seeking CF name for total water column height

[Lowry, Roy K]

Dear Jonathan,

The alias structure has developed into a deprecation mechanism and some of the 
more recent corrections have changed the meanings of the terms, so that the 
term and its alias are no longer synonyms.  Using the alias mechanism to 
establish synonyms between undeprecated terms invites confusion - it's like 
building RDF triples with no predicate.

Should the decision be taken to develop the Standard Names into a semantic 
network (which has been advocated at GO-ESSP meetings) then a more robust 
mechanism for specifying the relationship between terms is needed.  I can 
support this, but the infrastructure on the CF site would need a minor upgrade.

Cheers, Roy.


From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Jonathan Gregory [j.m.greg...@reading.ac.uk]
Sent: 02 February 2010 18:43
To: John Graybeal
Cc: CF Metadata List
Subject: Re: [CF-metadata] seeking CF name for total water column height

Dear John

Yes, good suggestion, we could adopt a new pattern vertical_distance_between_X
and_Y for cases where thickness sounds peculiar.

Aliases are really intended for cases where we make mistakes or change our
minds, rather than to provide synonyms deliberately. We've preferred to force
ourselves to agree where possible on a minimal vocabulary.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] seeking CF name for total water column height

[Lowry, Roy K]

Hello Nan,

I was arguing at the start of this thread that an instantaneous single-beam 
echosounder measurement is the so close to being the same thing as a BPR 
measurement in tidal mode with waves filtered out (ever looked at echosounder 
data from an anchored ship?) that they should be called the same thing on the 
basis that the Standard Name represents the phenomenon and should not describe 
how it was measured. 

Cheers, Roy.


From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Nan Galbraith [ngalbra...@whoi.edu]
Sent: 04 February 2010 17:29
To: Jonathan Gregory
Cc: cf-metadata@cgd.ucar.edu; Mike Garcia
Subject: Re: [CF-metadata] seeking CF name for total water column height

Sea_floor_depth_below_sea_surface seems very appropriate when
the water depth is measured from the surface.

Some communities need to distinguish this measurement from one
made from the sea floor.  Shipboard water depth measurements in the
open ocean generally ignore tides and other variations in sea surface
height, while bottom pressure recorders or other instruments used in
transport studies are monitoring these differences.

The oceansites project is looking for a way to identify this distinction -
maybe having 2 water depth terms in CF will be the solution, although
it may not be clear enough (especially since most people seem to think
these terms are synonyms).

If this has been mentioned, please excuse; I've been on a ship with
terrible network throughput, and I'm slowly trying to catch up with
email discussions.

Cheers - Nan

 I agree, it is arbitrary whether it is called
 sea_floor_depth_below_sea_surface
 or
 sea_surface_height_above_sea_floor
 and I agree with Roy that consistency with existing names would suggest
 the former.

 It's interesting that this kind of ambiguity hasn't arisen before. What you
 want to name is the distance between two named surfaces. In other names, we
 call the vertical distance between two surfaces a thickness e.g.
 ocean_mixed_layer_thickness. That doesn't have an associated direction
 (upward or downward) and so avoids this problem. By that analogy the quantity
 you want to name might be called thickness_of_ocean but I suspect most people
 would find that less obvious. What we are aiming at principally is clarity.

 The procedure for adding names is that Alison Pamment, the manager of standard
 names, will consider them and add them. She is dealing with CMIP5 names at
 present, I believe, so it might be a while before she gets to this. If no-one
 else objects soon or makes an alternative proposal, I'd suggest you use this
 name on the assumption that it will be added to the stdname table in due
 course.

 Best wishes

 Jonathan


--
***
* Nan Galbraith(508) 289-2444 *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543*
***



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] water level with/without datum

[Lowry, Roy K]

Hello Jonathan,

I have concerns about having separate names for river, lake and sea.  If you 
have them for height, then the logic would extend to temperature.  I have 
temperature data from a boat that started in the North Sea, went up the Humber 
and then up to the navigable limit of the Yorkshire Ouse.  I would much prefer 
a single Standard Name across the whole dataset.  

My suggestion of 'water body' as the generic term didn't get any reaction.  Was 
that acceptance or did nobody notice it?

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
Sent: 22 February 2010 19:02
To: Jeff deLaBeaujardiere
Cc: Andrea Hardy; cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] water level with/without datum

Dear Jeff et al

About
water_level_with|above_reference_datum
water_level_without_reference_datum
I'd like to make some suggestions:

* Since we don't have a convenient word for river, lake or sea, perhaps we
should have separate names for each of them i.e. sea_surface_height,
lake_surface_height and river_surface_height. All these terms are in use, often
in connection with altimetry. Obviously the same duplication (or triplication)
could occur with other sea-related names, but we have not had a great demand
for terms related to lakes and rivers up to now. Even if we did, it would
not be an unmanageable expansion of the standard name table. There are
currently 284 standard names containing the word sea.

* If the datum is an arbitrary local benchmark, then I think a name of
sea/lake/river_surface_height_above_reference_datum would be fine. If the
datum itself needs to be located, we could have standard names for that such
as sea/lake/river_surface_reference_datum_altitude.

* If the datum is a quantity which could be regarded as a continuous function
of location, I think it should be identified in the standard name, as in the
existing sea_surface_height_above_geoid. Other standard names would thus be
needed for sea_surface_height_above_mean_high_water etc. We also have an
existing name of sea_surface_height_above_reference_ellipsoid. Here, the
ellipsoid is not identified, but it can be with other CF metadata. I think
that's OK because the geophysical intention of the reference ellipsoid is
always the same, so this is in a sense a matter of measurement rather than
the quantity itself. By contrast, mean high water is a different geophysical
concept from the geoid.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] water level with/without datum

[Lowry, Roy K]

Hi Phil,

Jonathan's argument against 'water body' was that it was not as well-known as 
'sea'.  I think that the argument applies even more strongly to 'sorl'.

Cheers, Roy.

-Original Message-
From: Bentley, Philip [mailto:philip.bent...@metoffice.gov.uk] 
Sent: 23 February 2010 09:25
To: Lowry, Roy K
Cc: cf-metadata@cgd.ucar.edu
Subject: RE: [CF-metadata] water level with/without datum

Hi Roy,

Would simply inventing an artificial new term to represent
sea+lakes+rivers be an option here? Presumably, back in the day, there
was no word for a land-locked body of fresh water so someone thought, I
know, I'll call it a 'lake'. Or whatever the latin/greek equivalent was
back then!

So we might choose, say, the word 'sorl', this being an acronym for
seas, oceans, rivers and lakes. Sure that's not very pretty but no doubt
someone can think of a better word. Answers on an e-postcard...

Regards,
Phil

 -Original Message-
 From: cf-metadata-boun...@cgd.ucar.edu 
 [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K
 Sent: 23 February 2010 09:06
 To: Jonathan Gregory
 Cc: Andrea Hardy; cf-metadata@cgd.ucar.edu
 Subject: Re: [CF-metadata] water level with/without datum
 
 Hello again,
 
 I wouldn't recommend using '/' in a string, such as a 
 Standard Name, that could potentially be incorporated into a URL. 
 
 I think using 'sea' as defined shorthand for 'river/lake/sea' 
 has been suggested before.  I certainly have no problem with 
 it as long as that information is included in the definition.
 
 Cheers, Roy.
 
 -Original Message-
 From: Jonathan Gregory [mailto:jonat...@met.reading.ac.uk] On 
 Behalf Of Jonathan Gregory
 Sent: 23 February 2010 08:47
 To: Lowry, Roy K
 Cc: Jeff deLaBeaujardiere; Andrea Hardy; cf-metadata@cgd.ucar.edu
 Subject: Re: [CF-metadata] water level with/without datum
 
 Dear Roy
 
  I have concerns about having separate names for river, lake 
 and sea.  If you have them for height, then the logic would 
 extend to temperature.  I have temperature data from a boat 
 that started in the North Sea, went up the Humber and then up 
 to the navigable limit of the Yorkshire Ouse.  I would much 
 prefer a single Standard Name across the whole dataset.  
 
 I share that concern, but I didn't have a use-case where it 
 would be a problem to have separate names, so thanks for that.
 
  My suggestion of 'water body' as the generic term didn't 
 get any reaction.  Was that acceptance or did nobody notice it?
 
 I noticed it, yes, thanks! It is a correct generic term, of 
 course, but I feel it would cause a loss of clarity to 
 replace sea with water body in existing standard names 
 e.g. water_body_surface_height, water_body_water_temperature, 
 water_body_water_speed and water_body_ice_thickness are all 
 unfamiliar terms, whereas sea_surface_height, 
 sea_water_temperature, sea_water_speed and sea_ice_thickness 
 are all recognisable. In the particular case of Jeff's, 
 water body surface height is not a term that Google finds, 
 whereas sea surface height, lake surface height and 
 river surface height
 do all exist.
 
 More cumbersome than water body, but clearer I think, would 
 be to use the phrase sea/lake/river (I think / is a 
 permitted character) e.g.
 sea/lake/river_surface_height, 
 sea/lake/river_water_temperature. We could provide such names 
 of this type as are requested, for generic uses like yours, 
 but keep the sea names as well.
 
 In a case such as yours, would it be acceptable to use sea 
 all the time, even when it's a river?
 
 Best wishes
 
 Jonathan
 
 --
 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.
 
 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] water level with/without datum

[Lowry, Roy K]

Hi Nan,

Using unqualified 'water' to signify water within a water body works for me.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Nan Galbraith
Sent: 25 February 2010 16:47
To: Jonathan Gregory
Cc: John Graybeal; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] water level with/without datum

Agreed, water_surface_height_above_x is perfect.  And simple,
as Jeff pointed out earlier this week.
 I think Roy's example is a relevant use case. Although he has not made a
 proposal, his data set requires either a new name of river_water_temperature,
 or a name which can be used for both sea and river. The existing name of
 sea_water_temperature is not sufficient for the case he described.
   

Roy's example shows the need for a *single name* that can be used for
both sea and river temperature, not different names, if I understand his
description correctly.  

I'd like to extend the use of this prospective term to sub-surface water
bodies, which, like rivers, don't  always have clear boundaries. We have
ROVs that  travel from lakes and reservoirs through subsurface passages; 
I don't see any reason to (or reasonable way to) split up the measurements
made by these instruments based on which side of an invisible line they're
on at any given point.

So, I think 'water' is far better than 'sea_lake_river_water'. 

There are several names that use the modifiers 'atmosphere', 'in_air'  and
'surface' to indicate water that's not part of a water body. Does this 
imply
that the unmodified term 'water' means water that's in a water body?

The only names I can find that use plain 'water' seem to be sound_intensity
and sound_pressure terms - I assume these refer to water in a water body?
Is that enough of a precedent to suggest that water_temperature, _velocity,
_salinity, etc etc could be standard names for properties of the water in
bodies of water?

Cheers -
Nan



 water_surface_height_above_x seems to meet all the criteria.
 

   


-- 
***
* Nan Galbraith(508) 289-2444 *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543*
***



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] non-standard standard_names

[Lowry, Roy K]

Dear All,

The 'fast track' approach being discussed has promise and is pretty much in 
line with the ISO vocabulary model (in which terms have proposed, accepted, 
deprecated or deleted) used in resources like the GEMET thesaurus. However, 
there are important details to consider, such as version management (what event 
triggers the publication of a new version of the vocabulary?).

I am more uncomfortable with concept of community namespace Standard Name lists 
- I see this as the route to data ghettos (and don't truly believe that the 
Semantic Web would prevent this as nobody will bother doing the mappings)- and 
specialized standard names (in my view its either a Standard Name or it isn't 
and we have to accept that the nature of Standard Name is moving away from the 
purity of a geophysical phenomenon).

Cheers, Roy 

From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Nan Galbraith [ngalbra...@whoi.edu]
Sent: 12 May 2010 20:35
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] non-standard standard_names

The original proposal was to include names that have been rejected by
CF for being too specialized - these would be permanent parts of the
project vocabulary, not deprecated.

Many in situ instruments produce non-geophysical variables that fall
into this category; although this isn't what Martin had in mind,  his
proposal - or something along the same lines - would help us get to
a standard naming scheme for this kind of data too.

- Nan

 So my proposal was to create a vocabulary, or more precisely an RDF
 store, that lets us:
  1) declare a name that may be proposed as a CF candidate
  2) make a statement that the name has been (or even 'is being')
 submitted to CF for consideration
  3a) make a statement that the name has been accepted as a CF name,
 and therefore is deprecated as a proposed name
  3b) make a statement that the name has been rejected as a CF name,
 and therefore is deprecated as a proposed name
 In either 3a or 3b,
  4) make a statement that the replacement representation of the name
 is xyz in some other vocabulary




--
***
* Nan Galbraith(508) 289-2444 *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543*
***



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Seeking new CF standard names (9) for sea surface wave parameters

[Lowry, Roy K]

Hello Jonathan,

The term 'statistics' has a slightly different meaning for wave data.  
Essentially, what wave instrumentation does is record vertical displacement of 
the sea surface at very high frequency for a period of say ten minutes. 
Spectral analysis techniques are then used to derive 'statistics', such as the 
period and direction of the most energetic waves, the average height of the 
highest 1/3 of the displacements (one definition of significant wave height), 
from the raw spectra. This process is repeated every hour or so. 

Consequently, the usable data comprise an hourly set of 'statistics' at a given 
location.  Describing the derived values as 'parameterisations' might give a 
clearer picture of what they represent.  I therefore think that these belong in 
standard names rather than cell methods.

Cheers, Roy. 

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
Sent: 17 September 2010 16:22
To: andrew walsh
Cc: Patrick Gorringe; cf-metadata@cgd.ucar.edu; Katherine Tattersall; Mark 
Kulmar; g...@metoc.gov.au; Moninya Roughan; Roger Proctor; Paul Tildesley; 
Pauline Mak
Subject: [CF-metadata] Seeking new CF standard names (9) for sea surface wave 
parameters

Dear Andrew

Thanks for your list of wave height names. Although the standard name table
already contains some wave quantities which are defined statistically (as
you know, such as significant wave height) this larger list makes me wonder
if describing the statistics in the standard name remains the right approach.
This is not generally what we do in CF. For example, time-mean, maximum and
minimum are not indicated in standard names, but by the cell_methods attribute.
Is the idea of these quantities that they describe the statistics of wave
height observed over a long period at a given location? If so, perhaps we
could distinguish them by cell_methods rather than standard_name.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Seeking new CF standard names (9) for sea surface wave parameters

[Lowry, Roy K]

Hello Andrew and Jonathan,

First, I think this discussion is heading towards reasonable compromise 
avoiding my concerns of a massive proliferation in cell methods and the pitfall 
of concepts that are explainable in the context of their parameter, but 
meaningless in isolation (e.g. explaining moments without the concept of 
frequency).

Now for my views on 'common concepts'.  This was a very good idea that so far 
has drowned in a quagmire of over-commitment.  Bad news is that it's nearly a 
year since I left Hamburg allaying Michael and Frank's frustrations with an 
enthusiasm to make progress that was instantly swamped by day job issues when I 
returned to the office.

Good news is that I am now involved (with co-workers and support) in an EU FP7 
project and discovered at the project meeting last week that is going to need 
precise semantic interoperability between CF and SeaDataNet.  In other words an 
exact mapping between the BODC Parameter Usage Vocabulary (P011) and data 
channels in CF.  A mapping between P011 and CF Standard Names isn't going to 
cut the mustard for all the reasons that 'common concepts' were mooted to 
address.  So, if this project is to progress operational common concepts will 
have to be implemented by next summer at the latest.

So, my view on common concepts has recently become much more positive and I am 
therefore comfortable with the latest proposal.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of andrew walsh
Sent: 13 October 2010 01:00
To: Jonathan Gregory
Cc: cf-metadata@cgd.ucar.edu; Mark Kulmar
Subject: Re: [CF-metadata] Seeking new CF standard names (9) for sea surface 
wave parameters

Hi Jonathon and CF metadata list,

My responses are in-line below.

Andrew Walsh

- Original Message - 
From: Jonathan Gregory j.m.greg...@reading.ac.uk
To: andrew walsh awa...@metoc.gov.au
Cc: Patrick Gorringe patrick.gorri...@utas.edu.au; g...@metoc.gov.au; 
Mark Kulmar mark.kul...@mhl.nsw.gov.au; cf-metadata@cgd.ucar.edu; Roger 
Proctor roger.proc...@utas.edu.au
Sent: Wednesday, October 13, 2010 03:09
Subject: [CF-metadata] Seeking new CF standard names (9) for sea surface wave 
parameters


 Dear Andrew

 Thanks - this is a fruitful discussion. I think we agree on proposing these
 new names

  sea_surface_wave_height

Yes, but depends on the community (list) accepting the idea of having a common 
concept
of 'sea_surface_wave_height' modified by the cell methods to get particular 
meanings
for 4 of the 9 proposed wave parameters as follows:

CF std. name; cell_method; constructed meaning (name)

First 2 parameters would use new cell methods:

1) sea_surface_wave_height; time: root_mean_square; 
sea_surface_wave_height_root_mean_square
2) sea_surface_wave_height; time: 
mean_of_upper_decile;sea_surface_wave_height_mean_of_upper_decile

These 2 parameters would use existing cell methods:

3) sea_surface_wave_height; time: mean; sea_surface_wave_height_mean
4) sea_surface_wave_height; time: maximum; sea_surface_wave_height_maximum

List readers, I would appreciate any feedback on the idea of using
common concept + cell_method?

  sea_surface_wave_mean_crest_period
  sea_surface_wave_significant_wave_period
Yes, these 2 OK.


 You have proposed a new name
  sea_surface_wave_period_at_second_largest_peak_of_the_energy_spectrum
 (to replace an earlier proposal). Is this the second corresponding to this
 existing name being the first:
  sea_surface_wave_period_at_variance_spectral_density_maximum
 and if so, could your new quantity be
  sea_surface_wave_period_at_second_largest_peak_of_variance_spectral_density
 for consistency?

Yes, I this would be more consistent.


 Thanks for your explanation of sea_surface_wave_zeroth_spectral_moment. That
 leads me to ask whether it could be called
  sea_surface_wave_variance_spectral_density_zeroth_frequency_moment
 to correspond to the terminology used in the existing names
 
 sea_surface_wave_mean_period_from_variance_spectral_density_first|second_frequency_moment

Yes it could be called that, again fits in with existing terminology.


 Finally, you have explained that
  sea_surface_wave_root_mean_square_amplitude
 is the square root of the zeroth moment. It is liable to be confused with the
 root_mean_square sea_surface_wave_height. Would it be acceptable to call it,
 rather clumsily,
 
 sea_surface_wave_amplitude_from_variance_spectral_density_zeroth_frequency_moment
 which follows the pattern of the names of wave periods calculated from 
 moments?
 If it is always called sea_surface_wave_root_mean_square_amplitude and that
 doesn't cause any confusion in practice, we don't need to worry about it. But
 you did point out not be confused with, so I suppose it might be a problem!

I think 
'sea_surface_wave_amplitude_from_variance_spectral_density_zeroth_frequency_moment'
is longer/more clumsy than it needs to be. How about just

Re: [CF-metadata] New standard names for satellite obs data

[Lowry, Roy K]

Dear All,

I'd just like to reinforce John's last point that the semantics of 'instrument' 
and 'platform' are becoming blurred in these discussions.  From my perspective 
as one who has to map to CF datasets I would prefer it if the semantics of 
terms used in Standard Names had a universally understood meaning.

Another point that struck me from John's response is that when we do have 
multiple data streams sharing a single Standard Name, we need to ensure that 
there are objective criteria (i.e. not plaintext in the longname) that enable 
each stream to be uniquely identified.  Otherwise, even 'common concepts' 
(which incidentally will be worked during a workshop in November) won't deliver 
interoperability.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Aleksandar Jelenak
Sent: 20 October 2010 01:33
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data

Dear Evan,

Thanks for your suggestions.

Evan Manning wrote on 10/18/10 11:30 PM:
 The names below mix satellite and instrument differently than I'm
 used to.

I started with satellite_* names but then wanted to generalize since 
remote sensing instruments are not only carried on satellites. But you 
brought up an important distinction that the observation geometry of an 
instrument can be different from the generic one associated with the 
entire spacecraft.

 I recommend changing:
instrument_zenith_angle -  satellite_zenith_angle
instrument_azimuth_angle -  satellite_azimuth_angle
satellite_scan_angle -  satellite_view_angle

I think the instrument_* names are more applicable as they allow for 
either instrument-specific or spacecraft-generic geometries. I also 
think being able to distinguish between the two observation geometries 
is important and would like to have sets of standard names for both. So 
a data provider can clearly signal what is given, even for data from the 
same instrument.

To summarize:

1) Use instrument_zenith_angle, instrument_azimuth_angle, and 
instrument_scan_angle for precise, instrument-specific observation 
geometry.

2) Use platform_zenith_angle, platform_azimuth_angle, and 
platform_view_angle for generic satellite (here generalized to 
platform) observation geometry.

3) Mixing names from these two sets is allowed, whatever is more 
applicable for the zenith, azimuth, and scan/view angle data.

Too complicated?

 And add:
instrument_scan_angle
  The angle between the line of sight from an instrument and its
  reference scan position.

Agree.

-Aleksandar
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] New standard names for satellite obs data

[Lowry, Roy K]

Dear All,

As others have said, I think this debate is irrelevant as there should be no 
need for string timestamps in NetCDF. Providing a Standard Name only encourages 
what I consider to be bad practice. 

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ben Hetland
Sent: 20 October 2010 09:14
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data

On 19.10.2010 16:27, Seth McGinnis wrote:
 What about using 'date' for string-valued times?  That was my homebrew
 solution when I was considering a similar problem.

If I may butt in and contribute here, I usually prefer names like
'datetime' or 'timestamp' in cases like this, because 'date' is
potentially confusing. It may not be immediately obvious to a future
reader (or programmer) that a variable called 'date' supports points in
time down to for example seconds of accuracy.


 (Note that string data is a big pain to deal with in NetCDF-3, because
 you're limited to fixed-length character arrays.  You need to use
 NetCDF-4 / HDF5 to get Strings as a data type.)

(It may not be such a practical issue with ISO 8601 strings, as a
reasonable max. length can be determined, I presume.)

-- 
Regards,
   -+-Ben-+-
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] New standard names for satellite obs data

[Lowry, Roy K]

Hi John,

ISO-8601 allows timestamps to any resolution from year to millisecond, so 2010, 
2010-10, 2010-10-20 are all valid so the string can be any length from 4 to 27 
(e.g. 2010-10-20T14:53:00.000Z-15), unless restricted through an 8601 profile 
(as many communities do)

Cheers, Roy.



-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Caron
Sent: 20 October 2010 13:36
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data

On 10/19/2010 12:55 PM, Mike Grant wrote:
 On 19/10/10 14:21, Aleksandar Jelenak wrote:
 Actually, I don't think it is possible to use 'time' standard name in
 such cases. If I correctly interpret CF rules for using standard names,
 'time' data can be only in the physically-equivalent units to seconds.
 Strings, being dimensionless, do not qualify.

 Out of curiosity, why do you want to store time as strings?  It's easy
 to create those strings from numerical values, and numerical values are
 easier to handle in code (and in netcdf-3, as Seth said).

 Cheers,

 Mike.

I made a proposal a few years ago to allow ISO-8601 time strings to be an 
allowable form of time coordinates, which was not accepted. I would be 
interested to hear what your reasons are to use this form vs udunits (eg secs 
since reference)? ISO-8601 time strings are fixed length (21 I think?) so 
handling in netcdf-3 is not so hard.

Your proposal would amount to standardizing how to include ISO-8601 time 
strings, but the standard udunits time coordinate would still be required.

Clarification of your purpose might clarify the name. At first glance, I might 
prefer time_iso8601 over time_label_iso8601.

John
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] New standard names for satellite obs data

[Lowry, Roy K]

Hi Jon,

I prefer handling the precision issue through a format mask attribute.  I 
usually hit this problem in Oracle with the 'date' data type (in say column X), 
whose format I control by also storing an Oracle date/time format string (say 
in column Y).  Formatted date/time to the appropriate precision is then 
obtained using the function to_date (X,Y).  

Something similar should surely be possible in CF with a binary time channel, 
an ISO-8601 template (parameter attribute?) and an interface function.

Cheers, Roy.

From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Jon Blower [j.d.blo...@reading.ac.uk]
Sent: 20 October 2010 14:41
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data

Hi all,

I haven't followed this debate closely, but I've had cause to do a fair
amount of thinking (outside the CF context) on the pros and cons of
identifying date/times as strings or numbers.  I could probably write a
very boring essay on this but in summary, they are not exactly
equivalent ways of representing the same information.

One way in which they are different is precision.  A value of x seconds
since y has no implied precision - typically in programs we take the
precision to be milliseconds, but there's nothing to suggest this in the
actual metadata (anyone who tries to populate a GUI from CF metadata
struggles with this).  Semantically it's a time instant; i.e. an
infinitesimal position in a temporal coordinate reference system.
However, an ISO8601 string can have various precisions.  (The string
2009-10 is not considered equivalent to 2009-10-01T00:00:00.000Z.)

From Wikipedia (http://en.wikipedia.org/wiki/ISO_8601):

For reduced accuracy, any number of values may be dropped from any of
the date and time representations, but in the order from the least to
the most significant. For example, 2004-05 is a valid ISO 8601 date,
which indicates May (the fifth month) 2004. This format will never
represent the 5th day of an unspecified month in 2004, nor will it
represent a time-span extending from 2004 into 2005.

I've argued before in a previous thread on this list that it would be
good to be able to specify the precision of time coordinates in terms of
calendar date/time fields (which isn't the same thing as providing a
tolerance value on the numeric coordinate value of a time axis).

I'm not saying that we should definitely allow time strings in CF, just
pointing out that they have some use cases we currently can't fulfil.
I'm not sure they are definitively bad practice in all cases.

(Regarding a technical point raised below, yes, it's a pain to represent
variable length strings in NetCDF, but there is a maximum length for
ISO8601 strings.)

Hope this helps,
Jon

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K
Sent: 20 October 2010 10:00
To: Ben Hetland; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data

Dear All,

As others have said, I think this debate is irrelevant as there should
be no need for string timestamps in NetCDF. Providing a Standard Name
only encourages what I consider to be bad practice.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ben Hetland
Sent: 20 October 2010 09:14
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data

On 19.10.2010 16:27, Seth McGinnis wrote:
 What about using 'date' for string-valued times?  That was my homebrew
 solution when I was considering a similar problem.

If I may butt in and contribute here, I usually prefer names like
'datetime' or 'timestamp' in cases like this, because 'date' is
potentially confusing. It may not be immediately obvious to a future
reader (or programmer) that a variable called 'date' supports points in
time down to for example seconds of accuracy.


 (Note that string data is a big pain to deal with in NetCDF-3, because
 you're limited to fixed-length character arrays.  You need to use
 NetCDF-4 / HDF5 to get Strings as a data type.)

(It may not be such a practical issue with ISO 8601 strings, as a
reasonable max. length can be determined, I presume.)

--
Regards,
   -+-Ben-+-
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http

Re: [CF-metadata] New standard names for satellite obs data (time as ISO strings)

[Lowry, Roy K]

Hi Jon,

Full ISO8601 does carry time zone expressed in hours relative to UT in the 
syntax Zx where x is the offset from Zulu at the right-hand end of the string. 

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jon Blower
Sent: 21 October 2010 23:28
To: Benno Blumenthal
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data (time as 
ISO strings)

Hi Benno,

 No one I know beyond the age of four thinks Sep 2009 is ambiguous

Do you mean beyond the age of precisely 4.000... years or beyond the age of 
4.999... years?  Or is the ambiguous temporal metadata concept of the age of 
four sufficient?

;-)

All ISO8601 dates (year, month or day resolution) are inherently ambiguous 
because they carry no time zone information (your precise bounds are likely to 
be 5 hours different from mine, or something more complex if daylight saving is 
involved).  So with ISO8601 alone I don't think there's such a thing as the 
preciseSep2009 in your argument below, unless I've misunderstood what you 
mean, in which case apologies.

Hmm... come to think of it, this might actually argue *against* using ISO8601 
strings alone as indicators of time resolution.  If we really *do* mean that 
data are representative of a 24-hour period starting at midnight UTC on the 
first of September, we can't represent this unambiguously as 2009-01-01 
because of the time zone problem.  (I think that 2009-01-01Z is illegal.)  In 
this case we would be better off representing this period as a nominal value 
plus explicit bounds, or a nominal value plus time zone plus some additional 
information that we can discard any precision greater than 1 day.

*However*, it's still very useful to know the resolution of the time axis by 
some means other than inspecting the coordinate bounds.  An application (e.g. 
automatically generating a time selector widget in a GUI) will probably not 
want to look at all the bounds of all the time coordinates to infer the time 
resolution: apart from being generally tedious, it would be very difficult for 
monthly data (because months are different lengths, and vary between 
calendars).  Additionally, this inference would be complicated if 
floating-point numbers were used to represent time coordinates, since these are 
usually slightly inaccurate (dangerous to compare floats for equality, etc. 
etc.)


So, I'm starting to like the idea of an additional (and optional) CF attribute 
to specify time coordinate resolution.  This could be specified in precise 
numeric terms (e.g. instrument precision of 0.12 ms) or in less-precise human 
calendar terms for certain kinds of data (e.g. P1M for monthly resolution).  
It would be additional to the coordinate bounds: data providers could specify 
one or the other, or both if they are consistent (or neither if appropriate?)

This would not require or preclude the use of ISO8601 strings to represent time 
coordinate values.


Best wishes,
Jon


-Original Message-
From: bennoblument...@gmail.com [mailto:bennoblument...@gmail.com] On Behalf Of 
Benno Blumenthal
Sent: 21 October 2010 21:44
To: Jon Blower
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data (time as 
ISO strings)

Hi Jon,

Sorry, I am not buying it.

No one I know beyond the age of four thinks Sep 2009 is ambiguous, and
I don't read your examples as needing vagueness on the time
specifically.

Suppose, for a moment, that you succeed beyond your wildest dreams,
and it is possible to express in CF some relationship to a vague
notion of Sep2009, i.e.

data hasADataRelationshipWith vagueSep2009.

I would say there is another relationship

vagueSep2009 isAVagueVersionOf preciseSep2009

And you could have just as easily coded in CF

data hasADataRelationshipWithAVaugeVersionOf preciseSep2009

i.e. there is no reason why the vaugeness  cannot be coded as a
dependent data property.  Which is what CF is currently set up to do,
with a possible extension of the cell_methods vocabulary

Futhermore, you said

 You *could* modify CF so that to represent data that are representative of 
 September 2010, you specify a nominal date half-way through September and 
 set the bounds to the first and last instants of September.  And perhaps use 
 a new cell_methods of representative.  But the half-way point and the 
 bounds would be quite (very) tedious to compute in the general case (months 
 and years are of variable length for example and depend on the calendar 
 system).


That is not a modification of CF -- that is the way it is currently
encoded in CF (though there is no meaning to the nominal value, so you
can set it to whatever).  And yes, you have to generate the edges,
which you have to do anyway if you are going to sensibly handle
computations with the data.

And let me repeat my main original point, so that it does not get
completely buried  

Re: [CF-metadata] Interpretation of unspecified time zone (was: New standard names for satellite obs data (timeas ISO strings))

[Lowry, Roy K]

Hi again,

I must admit that your data is very different to the types of data I work with 
and I don't fully understand issues with composite images.  Typical data for me 
are time series where a series of parameters, including position are logged 
every 30 seconds or so as a ship sails along. Years ago I had a dataset where a 
form of local time (ship's time) was used and they switched from daylight 
saving part way through the cruise.  Result was that according to the data the 
ship was in two different places at a given time: not good. If a ship sails 
across the Atlantic, we don't want the time channel jumping around as time zone 
boundaries are crossed.  We have a lot of this type of data assembled over the 
past 30 years - not just ships but also moored instruments - with elapsed time 
channels that are assumed to be UT and have put much effort in the past into 
the conversion of any incoming local times in both data and metadata to UT.  To 
suddenly have this interpreted as local wouldn't im
 prove the accuracy of anything!

Making the default CF time local might make the standard appear more robust for 
your data world but not for mine. Alignment with ISO standards is an essential 
requirement for the development of new conventions, but I don't feel 
retrospective adoption to be a prudent path.

Cheers, Roy.

From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Julia Collins [colli...@nsidc.org]
Sent: 22 October 2010 17:32
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Interpretation of unspecified time zone (was: New 
standard names for satellite obs data (timeas ISO strings))

Hi,

On Fri, 22 Oct 2010, Lowry, Roy K wrote:
 I wonder how many existing CF data files would have the meaning of their
 time channel changed were this suggestion to be adopted.

I am sure many. In some cases it might even make them accurate. :-) At some
level, it's a tradeoff between breaking existing data descriptions and
creating a more robust standard. Whether my suggestion creates a more
robust standard or not is up for debate. It does align it more closely with
the ISO standard, and I think there's something to be said for that.

 If I were Julia I would be reworking my data so that the time channel was
 true UT.  I've had so many problems in the past with local time
 co-ordinates

It's not data I'm generating, but rather data provided by a PI who has
determined that this is how he wants to present his data. I believe the
idea is to be able to view a wide geographic area over the same effective
local time. It's a composite image. If you can tell me how to represent
these multiple UTC times for one variable using the existing CF
conventions, then I'll try to do so.  I believe CF limits me to specifying
one time zone for a particular time dimension. Re-working the data so that
it's broken up into separate time zones would, as I understand it, mean
splitting up the data variable into multiple variables, each with their own
time dimension, which is not what the data provider wants to do. Splitting
the variable would require the user to put the pieces back together in
order to see the image as the data provider intended. As far as I can tell,
following the ISO interpretation of the time zone indicator does exactly
what I need without ambiguity. I'd like to describe the data in a way
that's perfectly compliant with the CF convention, but in this case I don't
see a way to do so.

Thanks,
Julia
--
Julia Collins
National Snow and Ice Data Center
http://nsidc.org/
colli...@nsidc.org
+1 303.492.6405
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Correct name for aerosol size distributionexpressedin numbers ?

[Lowry, Roy K.]

Hi Alison,

If a community uses the term 'diameter' then I would stick with that and in our 
experience with both sediment grain-size and aerosol size spectra 'diameter' is 
the word exclusively used.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of alison.pamm...@stfc.ac.uk
Sent: 24 November 2010 13:47
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Correct name for aerosol size 
distributionexpressedin numbers ?

Dear Jonathan and Bruno,

I agree with Jonathan's point that the particle size is a geophysical
parameter, so we should not refer to 'bins' in the standard name.  I
think 'size' is too ambiguous a term so I vote for
aerosol_particle_radius or aerosol_particle_diameter.

Jonathan is correct that we do have existing standard names that refer
to the effective radius of cloud particles.  However, we also have
aerosol name explanations that refer to the particle diameters, e.g.,
the explanation of
atmosphere_optical_thickness_due_to_pm1_ambient_aerosol says Pm1
aerosol is an air pollutant with an aerodynamic diameter of less than
or equal to 1 micrometer. Personally, I don't mind whether we refer to
radius or diameter, but if diameter is the most commonly used measure of
aerosols then it makes sense to use it in the name.

Best wishes,
Alison

--
Alison Pamment  Tel: +44 1235 778065
NCAS/British Atmospheric Data CentreFax: +44 1235 446314
Rutherford Appleton Laboratory  Email: alison.pamm...@stfc.ac.uk
Chilton, Didcot, OX11 0QX, U.K.


 -Original Message-
 From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-
 boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
 Sent: 24 November 2010 12:30
 To: cf-metadata@cgd.ucar.edu
 Subject: [CF-metadata] Correct name for aerosol size
 distributionexpressedin numbers ?
 
 Dear Bruno
 
I love simple solutions.
 As physicists, we always think simplicity and elegance imply
 correctness!
 
As for the name of the coordinate variable, I would prefer
diameter
  over size.
 What about radius? There are existing names for radii of cloud
 particles,
 and these are analogous.
 
 It is usual to call the size classe bins, so we might come to
  particle_bins_mid_diameter.
 But here we are discussing the name of a geophysical quantity, which
 you happen
 to be using as an independent coordinate variable. So I think it's
 better to
 call it the aerosol particle size/radius/diameter in the standard
name.
 The
 fact that you are using it in bins is evident from the structure of
the
 data:
 
 dimensions:
   aerosol_particle_bins=30;
   two=2;
 variables:
   int size30(aerosol_particle_bins);
   size30:long_name = index values from 1 up to 30 ;
   float mic_conctab_SPP200_sync_1(time, aerosol_particle_bins);
   mic_conctab_SPP200_sync_1:units = count/cm3 ;
   mic_conctab_SPP200_sync_1:coordinates = size30;
   mic_conctab_SPP200_sync_1:standard_name =
  number_concentration_of_ambient_aerosol_in_air
;
   float aerosol_particle_bins(aerosol_particle_bins);
 aerosol_particle_bins:long_name=median diameter of size class;
 aerosol_particle_bins:units=SOMETHING;
 aerosol_particle_bins:standard_name=aerosol_particle_radius;
 aerosol_particle_bins:bounds=aerosol_particle_bin_bounds;
   float aerosol_particle_bin_bounds(aerosol_particle_bins,two);
 
 where the last variable specifies the range of size/diameter/radius
for
 each
 bin.
 
 Best wishes
 
 Jonathan
 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-- 
Scanned by iCritical.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Standard name request for ocean colour and iceberg concentration

[Lowry, Roy K.]

Yes, that's my understanding.  Cheers, Roy.

From: Lauret Olivier [mailto:olau...@cls.fr]
Sent: 03 December 2010 10:22
To: Lowry, Roy K.; Jonathan Gregory
Cc: Laurence Crosnier; cf-metadata@cgd.ucar.edu; Cristina Tronconi; Bruce 
Hackett; o.go...@met.no; Thomas LOUBRIEU; Lia Santoleri; Philippe Garnesson; 
frederic.me...@jrc.it
Subject: RE: [CF-metadata] Standard name request for ocean colour and iceberg 
concentration


Hi all,



Thanks, that's fine.

That is to say that

· number_content_of_icebergs (m-2) becomes 
number_of_icebergs_per_unit_area

Is that right?



About the other suggestions, we try to make things so that each entry is a 
combination of existing CF concepts, except the idea of 'non algal particles' 
that is now introduced.

· mass_concentration_of_inorganic_particles_in_sea_water (kg m-3)

· 
volume_absorption_coefficient_of_radiative_flux_in_sea_water_due_to_dissolved_organic_matter_and_non_algal_particles
 (m-1)

· 
volume_absorption_coefficient_of_radiative_flux_in_sea_water_due_to_phytoplankton
 (m-1)

· 
volume_backwards_scattering_coefficient_of_radiative_flux_in_sea_water_due_to_particles
 (m-1)

Comments are welcome,

Cheers,
Olivier.















-Message d'origine-
De : Lowry, Roy K. [mailto:r...@bodc.ac.uk]
Envoyé : jeudi 2 décembre 2010 17:53
À : Jonathan Gregory
Cc : Lauret Olivier; Laurence Crosnier; cf-metadata@cgd.ucar.edu; Cristina 
Tronconi; Bruce Hackett; o.go...@met.no; Thomas LOUBRIEU; Lia Santoleri; 
Philippe Garnesson
Objet : RE: [CF-metadata] Standard name request for ocean colour and iceberg 
concentration



My preference is also for natural English, so am happy with Jonathan's 
suggestion.  I was just pointing out, rather than supporting, the consistency 
issue.



Cheers, Roy.



-Original Message-

From: Jonathan Gregory [mailto:jonat...@met.reading.ac.uk] On Behalf Of 
Jonathan Gregory

Sent: 02 December 2010 15:37

To: Lowry, Roy K.

Cc: Lauret Olivier; Laurence Crosnier; cf-metadata@cgd.ucar.edu; Cristina 
Tronconi; Bruce Hackett; o.go...@met.no; Thomas LOUBRIEU; Lia Santoleri; 
Philippe Garnesson

Subject: Re: [CF-metadata] Standard name request for ocean colour and iceberg 
concentration



 I had the same gut reaction as you and almost came up with the same response 
 until I read the definition Content indicates a quantity per unit area on 
 369 Standard Names.  So, perhaps Olivier is being consistent and tha handful 
 of 'per_unit_area Standard Names are not.



I think Olivier is being consistent, but we have synonymous phrases, and in

this case I feel that such freedom is useful! We can't make standard names

completely systematic, because they also have to be reasonably natural English,

I would say. Jonathan

--



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.



   Cliquez sur l'url suivante

https://www.mailcontrol.com/sr/MKv+gOOmXGbTndxI!oX7Uue5l2axqqYZUZhEldDcvwCf31V7Uzv75MWuSjXXmfGj8hzVgSrfxsPC8dmstCo9uQ==

si ce message est indésirable (pourriel).
-- 
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.___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Web reference to a standard name?

[Lowry, Roy K.]

Hi Benno,

That's a pretty thorough overview of the current position.  One minor point is 
that the URIs you give from my system serve version 9 - not the current 
version. Replace the '9' by 'current' to get the latest version e.g. 
http://vocab.ndg.nerc.ac.uk/list/P071/9 
http://vocab.ndg.nerc.ac.uk/list/P071/http://vocab.ndg.nerc.ac.uk/list/P071/currentcurrent
 .

Cheers, Roy.


From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Benno Blumenthal [be...@iri.columbia.edu]
Sent: 13 December 2010 15:25
To: Dominic Lowe
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Web reference to a standard name?

We have tried to get standard URIs for CF concepts, but the effort bogged down.

As for standard names,  MMI established a set of URIs at

http://marinemetadata.org/cf

but has not been keeping up to date.   I have written a XSL transform at

http://iridl.ldeo.columbia.edu/ontologies/xslt/.cfsn2rdf.xsl

that can be applied to

http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/16/cf-standard-name-table.xml

to generate an up-to-date version, e.g.

xsltproc http://iridl.ldeo.columbia.edu/ontologies/xslt/.cfsn2rdf.xsl 
http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/16/cf-standard-name-table.xml

On the other hand,  Roy has created opaque URIs for standard names at

http://vocab.ndg.nerc.ac.uk/list/P07/9 contains all the Standard Names that 
have ever been published, including names that have been aliased

http://vocab.ndg.nerc.ac.uk/list/P071/9 contains the Standard Names that are 
currently valid (i.e. those that have not been deprecated through aliasing)

http://vocab.ndg.nerc.ac.uk/list/P072/9 contains the Standard Names that have 
been deprecated through aliasing

The mapping between deprecates and their replacement aliases my be obtained 
through the following API call

http://vocab.ndg.nerc.ac.uk/axis2/services/vocab/getMap?subjectList=http://vocab.ndg.nerc.ac.uk/list/P072/currentpredicate=255objectList=http://vocab.ndg.nerc.ac.uk/list/P071/currentinference=false


he changes them with each version, so it is both more definitive and harder to 
use.  It is also pure SKOS, so one needs to add structure to actually connect 
it with a CF-described dataset. I plan to write out a map between the two, so 
that I can use his relationships between CF standard_names, but I do not have 
it yet.

Additional information and ontologies describing the CF structure both as 
attributes and conceptually are available at 
http://iridl.ldeo.columbia.edu/ontologies/, including the connections between 
the standard_name ontologies and the CF structure.



Benno


On Mon, Dec 13, 2010 at 9:22 AM, Dominic Lowe 
dominic.l...@stfc.ac.ukmailto:dominic.l...@stfc.ac.uk wrote:
 Hello all,

 What's the current CF recommended scheme for referencing a standard name on
 the web? (either by URL or URN).

 I know about the vocab server and the xml/html online versions and could
 choose to use URLs to point to items in any of these but is there a
 definitive pattern that should be used?  (or at least a best practice that
 should be encouraged?).

 Much appreciated,

 Dominic
 --
 Scanned by iCritical.
 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edumailto:CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata




--
Dr. M. Benno Blumenthal  
be...@iri.columbia.edumailto:be...@iri.columbia.edu
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000   (845) 680-4450

-- 
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.___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Web reference to a standard name?

[Lowry, Roy K.]

Ditto!  Implementing what is suggested would be around 20 lines of code.  We've 
done the same for SeaDataNet to get their vocabs within their namespace such as 
http://www.seadatanet.org/urnurl/SDN:P021::TEMP 

Cheers, Roy.


From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of John Graybeal [jbgrayb...@mindspring.com]
Sent: 14 December 2010 17:56
To: Steve Hankin
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Web reference to a standard name?

In theory, MMI can support that approach (redirecting cfconventions.org, 
ideally transparently).  (That is, I worked it out in my head once. Haven't 
actually tried it in practice.  I *think* it's just a simple matter of 
programming. ;-)  I think that's the best combination to support both 
appropriate branding and the kind of support a full time dedicated repository 
can give.  Roy's server perhaps the same. (But not both at once!)

Just to be crystal clear, the places where you have '16' could also have 
'current' (if I understand correctly what Roy was saying about their server), 
and the mmisw one could also be served with a particular version ID (analogous 
to the NERC example).

If there is someone on the CF (or other) team that wants to play with us on the 
'simple matter of programming' part, that would be a collaboration we'd be 
happy to encourage.

John


On Dec 14, 2010, at 08:16, Steve Hankin wrote:

 I second that thought.

 On 12/14/2010 3:12 AM, Bryan Lawrence wrote:
 Hi Dom

 Actually, I think we really want:

 http://cfconventions.org/something

 (We own cfconventions.org, so we can point it where we want!)

 And I would like in 2011 to have settled on a permanent answer to that
 question!

 Cheers
 Bryan

 Thanks all,

 Interesting to see the new MMI ontology work.
 I take from this discussion then that there is not currently a CF
 'blessed' method to reference a term?

 E.g. for air_temperature I can choose from any of these:

 http://mmisw.org/ont/cf/parameter/air_temperature
 http://vocab.ndg.nerc.ac.uk/term/P071/16/CFSN0023
 http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-ta
 ble/16/cf-standard-name-table.html#air_temperature plus:
 http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-ta
 ble/16/cf-standard-name-table.xml


 Cheers,
 Dom

 On 14/12/10 08:18, Lowry, Roy K. wrote:
 Dear All,

 Working to find a way of harmonising the two sources of web-served
 Standard Names is on by ‘To-Do’ list for next year (part of an
 issue list fed into the NETMAR project by John G.)

 Cheers, Roy.

 *From:* cf-metadata-boun...@cgd.ucar.edu
 [mailto:cf-metadata-boun...@cgd.ucar.edu] *On Behalf Of *John
 Graybeal *Sent:* 13 December 2010 22:28
 *To:* Benno Blumenthal
 *Cc:* cf-metadata@cgd.ucar.edu
 *Subject:* Re: [CF-metadata] Web reference to a standard name?

 A minor clarification as to how MMI is doing things:

 Benno, all,

 On Dec 13, 2010, at 07:25, Benno Blumenthal wrote:
 We have tried to get standard URIs for CF concepts, but the
 effort bogged down.

 As for standard names, MMI established a set of URIs at

 http://marinemetadata.org/cf

 but has not been keeping up to date.

 Thanks for the mention. This is our older URL, sorry; we are now
 maintaining CF standard names in our ontology repository, using
 resolvable URLs. [1]

 There was a period when MMI was not keeping up to date with CF
 changes, but in the recent past we have been continuously updating
 the SKOS ontology for the parameter names at the site Carlos
 mentioned [1] (We will forward the misleading /cf URL above, or
 fix it to make clear in some other way the current status; thanks
 for calling that out.)

 As with Roy's handling, we provide URLs both for the current
 version at the reference URL, and for individual releases of the
 vocabulary.

 John

 [1] http://mmisw.org/ont/cf/parameter



 I have written a XSL transform at

 http://iridl.ldeo.columbia.edu/ontologies/xslt/.cfsn2rdf.xsl

 that can be applied to

 http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-
 table/16/cf-standard-name-table.xml

 to generate an up-to-date version, e.g.

 xsltproc
 http://iridl.ldeo.columbia.edu/ontologies/xslt/.cfsn2rdf.xsl
 http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name
 -table/16/cf-standard-name-table.xml

 On the other hand, Roy has created opaque URIs for standard names
 at

 http://vocab.ndg.nerc.ac.uk/list/P07/9 contains all the Standard
 Names that have ever been published, including names that have
 been aliased

 http://vocab.ndg.nerc.ac.uk/list/P071/9 contains the Standard Names
 that are currently valid (i.e. those that have not been deprecated
 through aliasing)

 http://vocab.ndg.nerc.ac.uk/list/P072/9 contains the Standard Names
 that have been deprecated through aliasing

 The mapping between deprecates and their replacement aliases my be
 obtained through the following API call

 http://vocab.ndg.nerc.ac.uk

Re: [CF-metadata] CF feature types and definitions

[Lowry, Roy K.]

Hi Nan,

Let's consider how you're moored instrument data are mapped into NetCDF.  If a 
given parameter is stored as a 2-D array with time as one dimension and 
instrument depth as the other then I would describe the data in that array as a 
'profile series'.   If they are stored as a set of 1-D vectors against a common 
time channel, then I would call them a 'time series'.  It is perfectly possible 
to have a mixture of 'profile series' and 'time series' in a single file - such 
as 2-D current arrays and 1-D water temperature from an ADCP.

So far I have considered the feature type as a property of individual 
variables, not the file as a whole.  Is this the CF intention (it's been a long 
time since I read the proposal)?  If so, I can't see Nan's problem. However, I 
think she is talking about file-level feature types, which we also need in our 
system to drive visualisation software. What I've done is to define our 
'profile series' equivalent as a file containing one or more 2D arrays (plotted 
as contoured parameters) with zero or more 1D vectors (plotted as time series 
plots stacked with the contour plots on a common time x-axis).  Our 'time 
series' is defined as one or more 1D vectors that are plotted as a stacked time 
series plot. In our working practice, these come from a single instrument, but 
providing all instruments have a common time channel this doesn't have to be 
so. Consequently, 'profile series' and 'time series' work for me as all I want 
to do is plot the data as discrete variables.

However, Nan, I'm guessing that you have other use cases.  It would be helpful 
for my understanding of what you need if you could give examples of the 
variables that would be in your files and the information that you expect to 
obtain from the file feature type. This should help clarify  any extensions 
required to the feature type vocabulary.

Cheers, Roy.

From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Nan Galbraith [ngalbra...@whoi.edu]
Sent: 29 December 2010 18:41
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] CF feature types and definitions

Bob's message reminds me that once these terms are agreed upon
they may be used for many purposes, across many different types
of systems, while a lot of the discussion of this convention has been
focused on just describing the shape of a chunk of data to be returned
by software queries.

For that reason, I still feel strongly that 'timeSeries' data should be
defined in a way that allows data from moored instruments at multiple
depths in a single file.  In the current version, the term 'location' in
the
definition of the timeSeries feature type is misleading; it can be taken
as x-y location, but I think you mean x-y-z. The definition needs to
be more specific, and I hope it will allow multiple depths.

A time-consuming search of the email archive didn't turn up a specific
message, but I recall that in the past I've been told that moorings with
data at different depths should be classified as a collection of profiles.
While that might be acceptable in terms of defining the shape of the
data returned in a query, it will not be useful when these terms are used
in other ways.

There's a big difference between a series of profiles at a single x-y
location
and a time series of data taken at the same x-y location by different
instruments at different depths. Not only are different variables measured
at different depths, the characteristics of the measurements can be
different -
instruments have different response times, resolution/accuracy, ranges,
etc.

As I've said before, it would be a pretty hard sell to describe our station
time series data sets as collections of profiles; a terrific 2d time series
is not likely to be seen as a good collection of profiles.

I hope we can find a better way to include data from moored buoys in
this vocabulary, without having to distort the data into something else.

Thanks -
Nan



On 12/23/10 11:06 AM, John Caron wrote:
 Attached is a message from Bob Simon at ERD/NOAA pointing out the
 inconsistencies in data type and feature type names in various
 Unidata related efforts. The almost-ready CF discrete sampling
 proposal has made a start at standardizing some of these names, and
 there is an interest, I think, between Steve, Jon and I to extend that
 to other types like grid. Essentially its a controlled vocabulary for
 classifying data.

 If this group is interested, I would propose a new ticket that would
 add probably an Appendix that would specify this vocabulary and their
 definitions. I anticipate it will be added to and clarified over time.

 John

  Original Message 
 Subject:  Re: [netcdf-java] CDM names
 Date: Thu, 23 Dec 2010 08:48:41 -0700
 From: John Caron ca...@unidata.ucar.edu
 To:   netcdf-j...@unidata.ucar.edu



 Hi Bob:

 Yes, you are right, there are too many forms of the data 

Re: [CF-metadata] Ambient light [Sec=Unclassified]

[Lowry, Roy K.]

Hi Miles,

Should there be anything in the Standard Name to specify the wavelengths of 
light detected in the measurement e.g. 
luminous_intensity_of_shortwave_radiation_in air?

Cheers, Roy.


From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Miles Jordan [miles.jor...@aad.gov.au]
Sent: 07 January 2011 00:41
To: 'Jonathan Gregory'
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Ambient light [Sec=Unclassified]

Jonathan Gregory wrote:
 Dear Miles

 Just wondering if there is a standard name that I should use for
 ambient light in air measured in candles; I can't see one for ambient
 light, luminous intensity, or anything else I can think of.

 I don't think there is at present. Is candle the same as the SI unit
 candela? Please propose a standard name if you would like to.

Yes, candela == candle. May I suggest luminous_intensity_in_air?

Regards,

Miles



___

Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not 
the
intended recipient, you are notified that use or dissemination of this 
communication is
strictly prohibited by Commonwealth law. If you have received this transmission 
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Ambient light [Sec=Unclassified]

[Lowry, Roy K.]

Hi Miles,

I would confirm with somebody who undestands the data before making any 
decisions.

Cheers, Roy.


From: Miles Jordan [miles.jor...@aad.gov.au]
Sent: 07 January 2011 12:07
To: Lowry, Roy K.
Cc: Jonathan Gregory; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Ambient light [Sec=Unclassified]

Quite possibly. I will have to take your recommendation on that as I am more on 
the software development side of things. Or shall I ask the people from my end 
that understand the data better?

Sounds ok to me though.

Regards,

Miles Jordan
mi...@milesjordan.com
+61 424 879 668

On 07/01/2011, at 8:35 PM, Lowry, Roy K. r...@bodc.ac.uk wrote:

 Hi Miles,

 Should there be anything in the Standard Name to specify the wavelengths of 
 light detected in the measurement e.g. 
 luminous_intensity_of_shortwave_radiation_in air?

 Cheers, Roy.

 
 From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
 Behalf Of Miles Jordan [miles.jor...@aad.gov.au]
 Sent: 07 January 2011 00:41
 To: 'Jonathan Gregory'
 Cc: cf-metadata@cgd.ucar.edu
 Subject: Re: [CF-metadata] Ambient light [Sec=Unclassified]

 Jonathan Gregory wrote:
 Dear Miles

 Just wondering if there is a standard name that I should use for
 ambient light in air measured in candles; I can't see one for ambient
 light, luminous intensity, or anything else I can think of.

 I don't think there is at present. Is candle the same as the SI unit
 candela? Please propose a standard name if you would like to.

 Yes, candela == candle. May I suggest luminous_intensity_in_air?

 Regards,

 Miles



 ___

Australian Antarctic Division - Commonwealth of Australia
 IMPORTANT: This transmission is intended for the addressee only. If you are 
 not the
 intended recipient, you are notified that use or dissemination of this 
 communication is
 strictly prohibited by Commonwealth law. If you have received this 
 transmission in error,
 please notify the sender immediately by e-mail or by telephoning +61 3 6232 
 3209 and
 DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
 ___
 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___

Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not 
the
intended recipient, you are notified that use or dissemination of this 
communication is
strictly prohibited by Commonwealth law. If you have received this transmission 
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___-- 
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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Ambient light [Sec=Unclassified]

[Lowry, Roy K.]

Thanks Miles,

Having read around a bit more I agree that the term luminance implies visible 
(ie wavelengths detected by the human eye) light and so 'luminance_in_air' 
would work, providing a suitable definition is included.

My straw man proposal for a definition would be 'A photometric measurement of 
the intensity of visible light that passes through or is emitted from a given 
area'. Anyone anything better?

Cheers, Roy.

-Original Message-
From: Miles Jordan [mailto:miles.jor...@aad.gov.au] 
Sent: 11 January 2011 23:56
To: Lowry, Roy K.
Cc: Jonathan Gregory; cf-metadata@cgd.ucar.edu
Subject: RE: [CF-metadata] Ambient light [Sec=Unclassified]

Thanks for your patience.

I've asked what people think, and we have come up with a couple: 
surface_diffuse_luminance_of_shortwave_radiation_in_air or just 
luminance_of_shortwave_radiation_in_air.

I don't think you can have luminance without diffuse reflection and I also 
don't think it can be a measurement of any other wavelength so it could be as 
simple as luminance_in_air. But I'll leave it up to the list to decide.

Regards,

Miles


Lowry, Roy K. wrote:
 Hi Miles,

 I would confirm with somebody who undestands the data before making
 any decisions.

 Cheers, Roy.

 
 From: Miles Jordan [miles.jor...@aad.gov.au]
 Sent: 07 January 2011 12:07
 To: Lowry, Roy K.
 Cc: Jonathan Gregory; cf-metadata@cgd.ucar.edu
 Subject: Re: [CF-metadata] Ambient light [Sec=Unclassified]

 Quite possibly. I will have to take your recommendation on that as I
 am more on the software development side of things. Or shall I ask the
 people from my end that understand the data better?

 Sounds ok to me though.

 Regards,

 Miles Jordan
 mi...@milesjordan.com
 +61 424 879 668

 On 07/01/2011, at 8:35 PM, Lowry, Roy K. r...@bodc.ac.uk wrote:

 Hi Miles,

 Should there be anything in the Standard Name to specify the
 wavelengths of light detected in the measurement e.g.
 luminous_intensity_of_shortwave_radiation_in air?

 Cheers, Roy.

 
 From: cf-metadata-boun...@cgd.ucar.edu
 [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Miles Jordan
 [miles.jor...@aad.gov.au]
 Sent: 07 January 2011 00:41
 To: 'Jonathan Gregory'
 Cc: cf-metadata@cgd.ucar.edu
 Subject: Re: [CF-metadata] Ambient light [Sec=Unclassified]

 Jonathan Gregory wrote:
 Dear Miles

 Just wondering if there is a standard name that I should use for
 ambient light in air measured in candles; I can't see one for ambient
 light, luminous intensity, or anything else I can think of.

 I don't think there is at present. Is candle the same as the SI
 unit candela? Please propose a standard name if you would like
 to.

 Yes, candela == candle. May I suggest luminous_intensity_in_air?

 Regards,

 Miles





___

Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not 
the
intended recipient, you are notified that use or dissemination of this 
communication is
strictly prohibited by Commonwealth law. If you have received this transmission 
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___

-- 
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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Ambient light [Sec=Unclassified]

[Lowry, Roy K.]

Hi John,

What about pyranometers that measure light intensity in terms of energy (by 
determining black body temperature change) as opposed to determining the 
quantity of photons?

Cheers, Roy.


From: John Graybeal [jbgrayb...@mindspring.com]
Sent: 15 January 2011 02:23
To: Lowry, Roy K.
Cc: Miles Jordan; cf-metadata@cgd.ucar.edu; Jonathan Gregory
Subject: Re: [CF-metadata] Ambient light [Sec=Unclassified]

Is ''A photometric measurement of' a critical part of the definition?  I can 
imagine another magical technology that measures the intensity of the light in 
some other way.  Well, I *can't* imagine the technology, but you know what I 
mean

john


On Jan 12, 2011, at 00:36, Lowry, Roy K. wrote:

 Thanks Miles,

 Having read around a bit more I agree that the term luminance implies visible 
 (ie wavelengths detected by the human eye) light and so 'luminance_in_air' 
 would work, providing a suitable definition is included.

 My straw man proposal for a definition would be 'A photometric measurement of 
 the intensity of visible light that passes through or is emitted from a given 
 area'. Anyone anything better?

 Cheers, Roy.

 -Original Message-
 From: Miles Jordan [mailto:miles.jor...@aad.gov.au]
 Sent: 11 January 2011 23:56
 To: Lowry, Roy K.
 Cc: Jonathan Gregory; cf-metadata@cgd.ucar.edu
 Subject: RE: [CF-metadata] Ambient light [Sec=Unclassified]

 Thanks for your patience.

 I've asked what people think, and we have come up with a couple: 
 surface_diffuse_luminance_of_shortwave_radiation_in_air or just 
 luminance_of_shortwave_radiation_in_air.

 I don't think you can have luminance without diffuse reflection and I also 
 don't think it can be a measurement of any other wavelength so it could be as 
 simple as luminance_in_air. But I'll leave it up to the list to decide.

 Regards,

 Miles


 Lowry, Roy K. wrote:
 Hi Miles,

 I would confirm with somebody who undestands the data before making
 any decisions.

 Cheers, Roy.

 
 From: Miles Jordan [miles.jor...@aad.gov.au]
 Sent: 07 January 2011 12:07
 To: Lowry, Roy K.
 Cc: Jonathan Gregory; cf-metadata@cgd.ucar.edu
 Subject: Re: [CF-metadata] Ambient light [Sec=Unclassified]

 Quite possibly. I will have to take your recommendation on that as I
 am more on the software development side of things. Or shall I ask the
 people from my end that understand the data better?

 Sounds ok to me though.

 Regards,

 Miles Jordan
 mi...@milesjordan.com
 +61 424 879 668

 On 07/01/2011, at 8:35 PM, Lowry, Roy K. r...@bodc.ac.uk wrote:

 Hi Miles,

 Should there be anything in the Standard Name to specify the
 wavelengths of light detected in the measurement e.g.
 luminous_intensity_of_shortwave_radiation_in air?

 Cheers, Roy.

 
 From: cf-metadata-boun...@cgd.ucar.edu
 [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Miles Jordan
 [miles.jor...@aad.gov.au]
 Sent: 07 January 2011 00:41
 To: 'Jonathan Gregory'
 Cc: cf-metadata@cgd.ucar.edu
 Subject: Re: [CF-metadata] Ambient light [Sec=Unclassified]

 Jonathan Gregory wrote:
 Dear Miles

 Just wondering if there is a standard name that I should use for
 ambient light in air measured in candles; I can't see one for ambient
 light, luminous intensity, or anything else I can think of.

 I don't think there is at present. Is candle the same as the SI
 unit candela? Please propose a standard name if you would like
 to.

 Yes, candela == candle. May I suggest luminous_intensity_in_air?

 Regards,

 Miles





 ___

Australian Antarctic Division - Commonwealth of Australia
 IMPORTANT: This transmission is intended for the addressee only. If you are 
 not the
 intended recipient, you are notified that use or dissemination of this 
 communication is
 strictly prohibited by Commonwealth law. If you have received this 
 transmission in error,
 please notify the sender immediately by e-mail or by telephoning +61 3 6232 
 3209 and
 DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
 ___

 --
 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.
 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



John Graybeal   mailto:jgrayb...@ucsd.edu
phone: 858-534-2162
System Development Manager
Ocean Observatories Initiative Cyberinfrastructure Project: 
http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http

Re: [CF-metadata] CF standard_name irradiation ?

[Lowry, Roy K.]

Hi Martin,

There are two Standard Names 'downwelling_shortwave_flux_in_air' and 
'downwelling_longwave_flux_in_air'.  Do either of these fit your data.  I have 
associated the former with downwelling irradiance data from PAR 
cosine-collector light meters.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz, Martin
Sent: 18 February 2011 13:28
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] CF standard_name irradiation ?

Dear colleagues,

I am trying to clean up some data files and make them CF compliant. But I 
am confused about the standard name that I could use for (measured) 
irradiation. There is an entry

downwelling_spectral_radiative_flux_in_air
Downwelling radiation is radiation from above. It does not mean net downward. 
spectral means per unit wavelength or as a function of wavelength; spectral 
quantities are sometimes called monochromatic. Radiation wavelength has 
standard name radiation_wavelength. When thought of as being incident on a 
surface, a radiative flux is sometimes called irradiance. In addition, it is 
identical with the quantity measured by a cosine-collector light-meter and 
sometimes called vector irradiance. In accordance with common usage in 
geophysical disciplines, flux implies per unit area, called flux density in 
physics.

This definition explicitly mentions irradiance, so I guess I am close to 
the solution. However, the irradiance measurement data I have are not 
spectral. I did not find a standard_name entry 
downwelling_radiative_flux_in_air which I would have expected to be the 
integral flux. There are only various variants of surface_net... or 
surface_spectral... fluxes. These don't help, or am I wrong here?

Unless I am mistaken or have overlooked something obvious, I therefore 
propose to add a standard_name tabel entry:

downwelling_radiative_flux_in_air
Downwelling radiation is radiation from above. It does not mean net downward. 
When thought of as being incident on a surface, a radiative flux is sometimes 
called irradiance. In addition, it is identical with the quantity measured by 
a cosine-collector light-meter and sometimes called vector irradiance. In 
accordance with common usage in geophysical disciplines, flux implies per 
unit area, called flux density in physics. For spectrally resolved radiative 
flux or net radiative flux see downwelling_spectral_radiative_flux_in_air
or surface_net_downward_radiative_flux, respectively.


Best regards,

Martin Schultz

= Dr. Martin G. Schultz, IEK-8, Forschungszentrum Jülich  =
= D-52425 Jülich, Germany =
= ph: +49 (0)2461 61 2831, fax: +49 (0)2461 61 8131   =
= email: m.schu...@fz-juelich.de  =
= web: http://www.fz-juelich.de/icg/icg-2/m_schultz   =



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] help

[Lowry, Roy K.]

Hi Karl,

Christina's problem is because her usage of standard name modifier is changing 
the canonical units from those of the unmodified Standard Name. Only solutions 
I can see are either to omit the Standard Name from this channel or set up a 
new Standard Name for raw chorophyll as counts.  The latter seems to me to be 
not be as easy as it sounds.  Any other opinions?

Cheers, Roy.

From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Karl Taylor [taylo...@llnl.gov]
Sent: 23 February 2011 17:54
To: cristina.tronc...@artov.isac.cnr.it
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] help

Hi Chritina,

For dimensionless variables, you can either omit the units attribute or set it 
to 1.  I don't understand why this error is raised.  Did you assign a 
standard_name to CHL_count?  If so, what did you assign?

thanks,
Karl

On 2/23/11 6:48 AM, 
cristina.tronc...@artov.isac.cnr.itmailto:cristina.tronc...@artov.isac.cnr.it 
wrote:

Hello,
I have a problem. iN MY NETCDF FILE I define the CHL_count variable.
it is a dimensionless variable.
I used the standard name modifier: COUNT for the variable CHL.

for IT I define: units=1 as indicated in the Appendix C of the
cf-conventions1_4.pdf.

but the cf checker gives me this error:

--
Checking variable: CHL_count
--
ERROR (3.1): Units are not consistent with those given in the
standard_name table.

WHAT SHOULD I PUT FOR THE ATTRIBUTE UNITS FOR THE CHL_COUNT VARIABLE?
IT IS DIMENSIONLESS!

THANKS IN ADVANCE

CRISTINA TRONCONI


---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel:  +39  06  49934342
cell: '39 349 1242954
Fax:  +39  06  20660291
e-mail:   
cristina.tronc...@artov.isac.cnr.itmailto:cristina.tronc...@artov.isac.cnr.it


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edumailto:CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Lowry, Roy K.]

Dear Christina,

As this debate unfolds I am coming to the realisation that there might be a 
significant difference between what you mean by 'chlorophyll count' (the 
unmodified reading from a fluorometer analogue-to-digital converter that is a 
function of chlorophyll concentration) and what CF understands by 'chlorophyll 
count' (the number of individual measurements used to determine a chlorophyll 
value).  Am I correct?  If so, apologies for not having realised this sooner.

Cheers, Roy. 

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
Sent: 24 February 2011 18:08
To: Schultz, Martin
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] standard_name modifiers

Dear Martin

The idea of the modifiers was to provide standard names for ancillary data,
such as count of obs, standard error, and so on. The other kinds of thing you
mention, such as means over periods and other statistics, can often be
described by cell_methods, which is more flexible because it refers to the
dimensions of the data.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Lowry, Roy K.]

Hi Martin,

' It's only replacing an underescore by a blank anyhow ;-)'

This isn't strictly true.  As the semantics infrastructure stands at the moment 
the deprecation procedure is to label the deprecated Standard Name as an 
'alias' with another Standard Name specified as its replacement. 

I don't know about you, but I would feel a little uneasy about a Standard Names 
list that has 'surface_temperature_anomaly' aliased to 'surface_temperature'.

Cheers, Roy. 


-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz, Martin
Sent: 28 February 2011 08:14
To: Jonathan Gregory
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] standard_name modifiers

Dear Jonathan et al.,

maybe I am fighting a lost battle here, but let me try to argue once more 
for a generalized solution, i.e. the addition of anomaly as a standard name 
modifier. I don't like the idea of adding a new standard name for each new 
anomaly: i) this seems illogical and new users will ask why is there an 
anomaly defined for temperature, but nor for precipitation?, ii) past 
experience has shown that it takes time to get new standard names adopted, and 
if new use cases come up (as they are bound to be for something as essential as 
anomalies) it may discourage people to even go for standard names for these 
variables. Why not try to make the system as systematic as possible? I don't 
want to argue against a pragmatic approach, but if you decide to change the 
anomalies from individual standard names to a modifier in three years, the 
effort might be much larger, the confusion will be greater and other 
operators with similar problems will come along. So, my suggestion would be 
to de
 precate the use of air_pressure_anomaly, air_temperature_anomaly, 
geopotential_height_anomaly and surface_temperature_anomaly now and introduce 
anomaly as a modifier. It's only replacing an underescore by a blank anyhow 
;-)

As we just developed some tools to compute multi-model means and model 
anomalies for the TFHTAP data sets, I would otherwise have to come up with a 
list of ~20 new _anomaly standard names. So, besides what I see a rational 
argument (above), I have a personal reason for arguing so vehemently.

Cheers,

Martin




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] udunits time unit question

[Lowry, Roy K.]

Dear All,

This debate between Chris and Benno hinges upon how one determines the sampling 
interval for a time series.  Benno depends upon semantics encoded in the units 
of measure field - something I have done in the past although I am now 
convinced that it is not best practice.  Chris advocates obtaining it by 
analysis of the time channel.  

Although I see Benno's usage as not best practice, it is established practice 
and therefore I for one feel that it should continue to be supported.

Cheers, Roy. 

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Christopher Barker
Sent: 30 March 2011 23:27
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits time unit question

On 3/29/11 12:24 PM, Benno Blumenthal wrote:
 Well I thought I was helping, but maybe not.

you certainly are helping -- we all need to know what folks' use cases 
are to determine a good solution.

  -- no one who uses months
 since date-time is using the udunits interpretation -- all of us who
 use it are using the calendar 360_day interpretation, which is part of
 the standard, and beyond udunits.

uhm, how can you be sure what all of us are doing?

 Not to pick on Chris,

You aren't picking on me, you're picking on my understanding of the 
situation -- which is fair game.

 but I think it is clear over the course of this
 conversation that many of the participants do not understand the
 calendar attribute, which is causing a great deal of pain (or at least
 conversation).

yes, i think you are right. I just went to read the CF standard about 
this again, and it helps, but I'm still confused about how Calendars 
like 360_day can be used in practice, and I don't see why anyone needs:

5 days since 1960-01-01 calendar 365_days

rather than:

days since 1960-01-01 calendar 365_days

and multiply the time variable by 5. So I think the use of units like 5 
days, and use of various calendars are orthogonal.

on to my question about calenders. Form the docs:

360_day
 All years are 360 days divided into 30 day months.

OK, so I take it that a day is 24 hours, so a year is 24 * 360 hours 
long. I can see the utility in this, but then i guess 1960-01-31 is 
illegal? And if you do years since or even months since, the meaning 
is going to get very offset after a few year from the usual calendar.

I'm also not sure what 1960-01-01 means in a 360_day calendar -- what 
is year 0? Or do you use the Gregorian calendar for the point in time 
part? Maybe that doesn't matter, as long as we aren't concerned about 
absolute dates. This does satisfy Steve's point about having a 
meaningful axis for doing math -- every month and year is the same length.

However, at the end of the day, I don't see the use -- you really can't 
talk about dates in this calendar anyway, so why not pick an arbitrary 
point in time and use hours? When if comes down to it, I can certainly 
see why one might want to do calculations and plotting, etc, in those 
calendars, but I don't see why your netcdf file has to store the data 
that way.

 And there is a lot of data out there with year being the right sense of
 things -- the fuzziness is real -- tree ring data, coral data, ice
 cores, all count years more-or-less,

yup.

  many of us are modeling
 the earth, which means that the earth-bound descriptions of time are
 what we need to concisely describe what we are doing.

right -- and I think that the calendar_year concept makes sense for this 
-- but you'd better use something like the Gregorian calendar, or your 
years won't line up with the seasons for long!

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] physical vs dimensional units

[Lowry, Roy K.]

Hi John,

We label Units of Measure with a URI (e.g. SDN:P061::ULAA represents metres), 
which represents a term in the P061 vocabulary 
(http://vocab.ndg.nerc.ac.uk/P061/list/current). The vocab (born in the late 
70s) is a work of pragmatism that contains a mixture of 'dimensional units' 
plus 'physical units' carrying semantics like 'mg/g dry sediment'.  Work in 
progress is to migrate semantics into our equivalent to Standard Names 
deprecating P061 terms as we go with the medium term objective of getting as 
close to udunits as possible. However, I feel complete harmonisation will never 
be possible.

All our current software does with the P061 URIs is to use them to create text 
labels for plots, ASCII listings and so on. The resulting consistent labelling 
is the primary objective of P061. Of course, my ambition is to develop UoM 
interconversions, probably built on udunits, but that isn't even at the 
vapourware stage yet.  So, the answer to your question is that we  use 
'physical units' as labels, but don't try and do any processing based on them.

I'm starting to wonder whether the 'labelling' and 'interconversion' use cases 
have become a little confused in the discussions of the past few weeks.

Cheers, Roy.


-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Caron
Sent: 31 March 2011 14:00
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] physical vs dimensional units

udunits is a dimensional units library, for manipulating powers of the 
fundamental dimensions (length, mass, time, charge, temperature). this 
is necessary but not complete for capturing the meaning of the physical 
units of our data.

We also need units like kg/kg, for which the udunit canonical string is 
the empty string. But even more difficult is atoms CO2 / atoms air or 
grams CO2 / grams air, or count of phytoplankton.

the simple thing is to just introduce another attribute unit labels 
(or something) for this, to be displayed to the user.  but such an 
opaque string limits the amount of automatic inferencing that can be 
done. better would be a grammar from which both the dimensional units 
and the substance we are talking about can be understood.

also, all of our space/time units arent dimensional units, they are all 
referenced to a datum. we include the datum in the udunit string for 
time, but not for vertical or horizontal coordinates. thats not a 
particular problem, but it does point out that these units are not the 
same as dimensional units. we need to include the datum in the physical 
units representation, which could be one string or several strings .

what are other solutions that are being used for physical units? Im 
wondering how Roy Lowry's software deals with this? Or the MMI or SWEET 
ontologies , etc? Is there something nice and compact like udunits 
strings, but with more semantics, without getting into the complexity of 
RDF triples?
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Proposal for new standard names: depth/bathy/topo rel to datum

[Lowry, Roy K.]

Hello Justin/Jonathan,

To me, the term or concept 'bathymetry' is the spatial variation of seafloor 
depth and should only be applied to a grouping of depth measurements with 
associated co-ordinate variables and not to just a depth parameter.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
Sent: 14 April 2011 09:33
To: Justin R. Davis
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Proposal for new standard names: depth/bathy/topo 
rel to datum

Dear Justin

   sea_floor_depth_below_reference_datum (positive down)
looks fine to me.

Isn't this the same thing:
   bathymetry_below_reference_datum (postive down)
bathymetry means sea-floor depth, doesn't it?

For consistency with other stdnames, in particular
  height_above_reference_ellipsoid
  sea_surface_height_above_reference_ellipsoid
this one
   topography_above_reference_datum (postive up)
should be
  surface_height_above_reference_datum
I think.

 Furthermore, I'd also propose that any of these 3 would be required
 to have metadata with them (e.g. NetCDF attribute) which
 specifically defines the reference datum.  This metadata would be
 called VerticalDatum (IOOS uses this) and would have a syntax like
 the following for NAVD88:
   urn:ogc:def:datum:epsg::5103

We did talk quite a lot about this when Phil Bentley proposed the extensions
which we adopted for grid_mapping to describe the ellipsoid etc. The discussion
stalled because we didn't really understand what vertical datum means! As
you and I have been discussing separately, if NAVD88 is a geoid, I think we
should call it a geoid in the standard name, and we should extend grid_mapping
so it can identify the geoid by name, perhaps also giving a URN as you say.
Unlike the ref ellipsoid, the geoid cannot be specified by metadata, as it's
too complicated!

best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] [Standard name request] property changes over time

[Lowry, Roy K.]

Hello Jonathan,

Paul's neutral density definition looked OK to me, although I'm not a physical 
oceanographer.  If it helps I used 
http://oceanworld.tamu.edu/resources/ocng_textbook/chapter06/chapter06_05.htm
As an aid to checking it out.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
Sent: 16 May 2011 15:45
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] [Standard name request] property changes over time

Dear Paul

 change_over_time_in_sea_water_salinity
 change_over_time_in_sea_water_temperature
 change_over_time_in_sea_water_potential_temperature
 change_over_time_in_sea_water_density
 change_over_time_in_sea_water_potential_density
 sea_water_neutral_density
 change_over_time_in_sea_water_neutral_density

Thanks for your time spent on this. They look fine to me. Perhaps others will
have comments e.g. on the definition of neutral density.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] WS querying cf meta data catalog

[Lowry, Roy K.]

Dear Uwe,

It exists.  A copy of the Standard Names is served through the NERC Vocabulary 
Server (http://www.bodc.ac.uk/products/web_services/vocab/).  The references to 
the Standard Names list are:

Live terms: http://vocab.ndg.nerc.ac.uk/list/P071/current/
Deprecated terms: http://vocab.ndg.nerc.ac.uk/list/P072/current/

These list addresses may be incorporated into either the SOAP or HTTP-POX APIs 
described in the URL reference above.

Individual Standard Names are addressed through BODC-assigned opaque 
identifiers such as:

http://vocab.ndg.nerc.ac.uk/term/P072/17/CFSN0012

The associated canonical units will be found in references containing 'P061' in 
the mappings section of the payload XML document, such as skos:minorMatch 
rdf:resource=http://vocab.ndg.nerc.ac.uk/term/P061/37/KMP2; /.

The Standard Name list is also maintained in the MMI Ontology Registry and 
Repository which again provides programmatic access through an API.  I'll leave 
it to the MMI folks to provide you with pointers to the detail.

Cheers, Roy.


-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Uwe Rosebrock
Sent: 26 May 2011 00:41
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] WS querying cf meta data catalog

Hi all,

is there or is there a plan to establish a web service to query the 
standard_name list and units programatically (without human interaction)?
would such a service be useful as vocabulary by anybody?

Cheers
Uwe 

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] new TEOS-10 standard names

[Lowry, Roy K.]

Dear All,

I think the point we're missing here is that the existing salinity Standard 
Name is a much broader term than the TEOS-10 recommendations, covering true 
practical salinity from conductivity measurements, other types of salinity 
measurement and salinity computed by a whole host of numerical model 
algorithms.  This has been connected with the PSU units of measure, which is 
sometimes right and sometimes wrong.  However, it is widespread in legacy data 
stock.  It is therefore something that should be recognised for what it is 
warts and all and left alone.  Renaming it 'practical salinity' would be a bad 
move because it would change the semantic labelling of some datasets from 
imprecise to precise but wrong.

I think the way forward would be to generate additional Standard Names for 
Practical Salinity and Absolute Salinity supported by TEOS-10 definitions, 
which can be semantically mapped as narrowMatches to the existing salinity, to 
give us the ability to label things properly from now on.  It would be down to 
those holding data in CF to replace 'salinity' with the appropriate more 
precise term from the TEOS-10 recommendations.

I would also support the creation of new Standard Names for the other TEOS-10 
variables (temperature plus derived parameters) under the watchful eye of 
Trevor and TEOS-10. Again these can be mapped to existing less precise terms as 
appropriate. Now is our chance to get this right.

Finally, can I draw peoples' attention to the statement on the TEOS-10 Web Site 
that data centres should continue to ingest and store salinity observations as 
Practical Salinity.  It is abundantly clear from a number of conversations I 
have had recently that this is being overlooked.

Cheers, Roy.

From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of trevor.mcdoug...@csiro.au [trevor.mcdoug...@csiro.au]
Sent: 21 July 2011 11:29
To: ngalbra...@whoi.edu; CF-metadata@cgd.ucar.edu; paul.dur...@csiro.au; 
paul.bar...@csiro.au; rainer.feis...@io-warnemuende.de; r...@eos.ubc.ca; King, 
Brian A.
Subject: [CF-metadata]  new TEOS-10 standard names

Dear Nan et al.,

   I want to weigh in to this discussion, as chair of SCOR/IAPSO Working Group 
127.

   In June 2009 the Intergovernmental Oceanographic Commission, which is 
comprised of 146 nations, adopted TEOS-10 as the formal definition of seawater 
properties (and of ice and of humid air).

   Part of TEOS-10 is the adoption of Absolute Salinity as the salinity 
variable which replaces Practical Salinity as the salinity argument for the 
algorithms that calculate density etc.

   Because of the proliferation of different types of salinity, it is 
particularly important that the single word Salinity not be used henceforth.  
Rather, Practical Salinity should be used for Practical Salinity (not 
Salinity), and Absolute Salinity should be referred to as Absolute Salinity 
(not Salinity).  The symbols S_P and S_A should be used, and the use of S 
should be discontinued immediately.

   This is outlined in the attached Announcement which will shortly appear in 
21 oceanographic journals.  This Announcement specifically requests editors and 
authors to use S_P and S_A, not S.  The aim of this recommendation is to 
minimize the potential for confusion.

   We in WG127 have met with representatives of instrument manufacturers and 
they will be providing output from their software in the above manner.  That 
is, they will discontinue the use of Salinity and of S.

  I note that a team of four people have recently installed TEOS-10 into MOM4, 
and so we now have Absolute Salinity S_A and Preformed Salinity, S_star, in 
MOM4.  So this naming convention is actually already an issue in the ocean 
modelling world.

   In the same vein, ocean models should not carry a variable called 
temperature but rather should carry either potential temperature or 
Conservative Temperature or both.

   It is clear that we are now on the cusp of a transition in oceanography, 
with the potential for confusion unless we are all very careful in correctly 
labeling our variables.

   I hope this discussion of the thinking of SCOR/IAPSO WG127 helps your 
community with the naming conventions for ocean and climate models,

   With best wishes,

   Trevor


PS. As for some definitions, I would suggest something along the lines of

sea_water_Practical_Salinity:
Definition: Salinity measured on the Practical Salinity Scale of 1978 (PSS-78),
which is based on measurements of the electrical conductivity of seawater.


sea_water_Absolute_Salinity:
Definition: The mass fraction of dissolved material in seawater as defined by 
the
Thermodynamic Equation Of Seawater - 2010 (TEOS-10).  Absolute Salinity 
incorporates the
spatial variations in the composition of seawater.  This type of absolute 
salinity
is also called Density Salinity.


Note that I think the sea 

Re: [CF-metadata] new TEOS-10 standard names:- reply to two emails.

[Lowry, Roy K.]

).  The salinity output of numerical models to date 
is Practical Salinity as well, yes?  Because these models have been initialized 
with Practical Salinity and their model equations of sate have been written in 
terms of Practical Salinity.

Going forward from now, it is important that the stored Practical Salinity be 
identified as Practical Salinity, not as just salinity.  From 1st January 
2010 (when the reign of TEOS-10 began) there are too many salinities for us to 
just call one of them salinity.

It is clear to me that the data that is stored as Salinity (psu) in national 
data bases to date should remain there as that.  But it is also equally clear 
to me that any new observed data going into such data bases that is Practical 
Salinity, should not be called Salinity but must be called Practical 
Salinity.  This is the only safe way that we can avoid confusing ourselves 
with observed data taken after 1st January 2010.

Now Paul Durack has suggested that an alias be created so that the old 
salinity data also appears as Practical Salinity.  I do not have a strong 
view on that.  If that were done, it should only be done with data collected 
since 1st January 1978, since before that date the salinity was calculated by a 
different formula (the Knudsen formula given above) and so was definitely not 
Practical Salinity.

   With best wishes,

   Trevor





-Original Message-
From: Lowry, Roy K. [mailto:r...@bodc.ac.uk]
Sent: Friday, 22 July 2011 7:10 AM
To: McDougall, Trevor (CMAR, Hobart); ngalbra...@whoi.edu; 
CF-metadata@cgd.ucar.edu; Durack, Paul (CMAR, Hobart); Barker, Paul (CMAR, 
Hobart); rainer.feis...@io-warnemuende.de; r...@eos.ubc.ca; King, Brian A.
Subject: RE: [CF-metadata] new TEOS-10 standard names

Dear All,

I think the point we're missing here is that the existing salinity Standard 
Name is a much broader term than the TEOS-10 recommendations, covering true 
practical salinity from conductivity measurements, other types of salinity 
measurement and salinity computed by a whole host of numerical model 
algorithms.  This has been connected with the PSU units of measure, which is 
sometimes right and sometimes wrong.  However, it is widespread in legacy data 
stock.  It is therefore something that should be recognised for what it is 
warts and all and left alone.  Renaming it 'practical salinity' would be a bad 
move because it would change the semantic labelling of some datasets from 
imprecise to precise but wrong.

I think the way forward would be to generate additional Standard Names for 
Practical Salinity and Absolute Salinity supported by TEOS-10 definitions, 
which can be semantically mapped as narrowMatches to the existing salinity, to 
give us the ability to label things properly from now on.  It would be down to 
those holding data in CF to replace 'salinity' with the appropriate more 
precise term from the TEOS-10 recommendations.

I would also support the creation of new Standard Names for the other TEOS-10 
variables (temperature plus derived parameters) under the watchful eye of 
Trevor and TEOS-10. Again these can be mapped to existing less precise terms as 
appropriate. Now is our chance to get this right.

Finally, can I draw peoples' attention to the statement on the TEOS-10 Web Site 
that data centres should continue to ingest and store salinity observations as 
Practical Salinity.  It is abundantly clear from a number of conversations I 
have had recently that this is being overlooked.

Cheers, Roy.




From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Karl Taylor [taylo...@llnl.gov]
Sent: Friday, 22 July 2011 3:12 AM
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] new TEOS-10 standard names

Dear Trevor,

Could you please clarify:  Are potential temperature and conservative 
temperature identical, or is conservative temperature what everyone else 
considers to be simply temperature, or what?

thanks,
Karl


-Original Message-
From: McDougall, Trevor (CMAR, Hobart)
Sent: Thursday, 21 July 2011 8:30 PM
To: 'ngalbra...@whoi.edu'; 'CF-metadata@cgd.ucar.edu'; Durack, Paul (CMAR, 
Hobart); Barker, Paul (CMAR, Hobart); 'Rainer Feistel'; Richard Pawlowicz; 
'b...@noc.soton.ac.uk'
Subject: [CF-metadata] new TEOS-10 standard names

Dear Nan et al.,

   I want to weigh in to this discussion, as chair of SCOR/IAPSO Working Group 
127.

   In June 2009 the Intergovernmental Oceanographic Commission, which is 
comprised of 146 nations, adopted TEOS-10 as the formal definition of seawater 
properties (and of ice and of humid air).

   Part of TEOS-10 is the adoption of Absolute Salinity as the salinity 
variable which replaces Practical Salinity as the salinity argument for the 
algorithms that calculate density etc.

   Because of the proliferation of different types of salinity, it is 
particularly important that the single word Salinity not be used henceforth.  
Rather, Practical Salinity should be used for Practical Salinity

Re: [CF-metadata] per-variable metadata?

[Lowry, Roy K.]

Hi Nan,

Encoding what I would regard as usage metadata into ancilliary variables is one 
solution, but I would much rather see a formalised metadata model for doing 
this.  As you say a standard way of doing this is long overdue. My hope is that 
SeadataNet II starting later this year will take on and address this challenge. 
 However, if anybody knows of anything already in existence that fits the bill 
it would be good to prevent yet another wheel being reinvented.

Cheers, Roy.

From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Nan Galbraith [ngalbra...@whoi.edu]
Sent: 04 August 2011 19:17
To: Steve Hankin; cf-metadata@cgd.ucar.edu
Cc: Jeff deLaBeaujardiere
Subject: Re: [CF-metadata] per-variable metadata?

Hi Steve -

I'm very interested in the background discussion on this -
any chance of bringing it into the foreground?

I'm using ancillary variables in 2-D in situ data files to describe
instruments and things like precision, accuracy, sample scheme,
etc.. For temperature files from moorings where different sensor
types are at different depths, I'd like to use something like

TEMP:ancillary_variables = Instrument_manufacturer Instrument_model
 Instrument_sample_scheme Instrument_serial_number TEMP_qc_procedure
 TEMP_accuracy TEMP_precision TEMP_resolution;
and then
short INST_SN(depth) ;
INST_SN:long_name = instrument_serial_number ;
... etc., etc.

If there's going to be a standard way to do this, I'd really like to
know about it - sooner rather than than later.

Thanks -
Nan

On 8/4/11 11:35 AM, Steve Hankin wrote:
Hi Jeff,

Each variable in a CF file may possess an |ancillary_variables| attribute, that 
points to variables that have relationships 
(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/cf-conventions.html#ancillary-data).
  To attach flags to a variable, use |ancillary_variables| to point to a 
variable that has |flag_values||| and |flag_meanings |attributes 
(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/cf-conventions.html#flags).

We have started a discussion in the background, whether an example that 
illustrates this should be included in the CF documentation.

- Steve

=

On 7/14/2010 6:21 AM, Jeff deLaBeaujardiere wrote:
In another discussion, Steve Hankin wrote:
 CF generally favors attributes attached to variables over attributes attached 
 to files

This reminds me of a question I wanted to ask: does CF have any conventions 
regarding how to handle data that contains multiple observed quantities with 
different quality flags, comment fields or other attributes for each quantity?

-Jeff DLB



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edumailto:CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edumailto:CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata




--
***
* Nan Galbraith(508) 289-2444 *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543*
***



-- 
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.___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] per-variable metadata?

[Lowry, Roy K.]

Hi Nan,

At the risk of being shot for herecy, I maintain the belief that in the current 
technological environonment packing everything inside the straightjacket 
container of a physical file is an anachronism.  As you've probably guessed my 
view is that metadata and its associated semantics have data structures that 
incorporate complex interrelationships, which can only be properly encoded in 
formats like XML.  So, I would have an attribute in the CF file holding a 
permanent identifier that is guaranteed to be resolvable from now until 
eternity into an XML file delivering usage metadata.

Cheers, Roy.

From: Nan Galbraith [ngalbra...@whoi.edu]
Sent: 05 August 2011 16:30
To: Lowry, Roy K.; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] per-variable metadata?

Hi Roy and all  -

Do you see a possible place for this metadata in a more
structured attribute system, or somewhere else in the NetCDF
file structure? Or are you thinking that we need metadata
outside our CF files?

Since CF has the precedent of putting other quality-related
information (flag values, uncertainty, etc.) in ancillary variables,
it seems (or seemed) reasonable to me to include more complete
provenance info there. It might blur the line between data and
metadata, but I don't see another solution without higher costs,
at the moment.

I'm looking forward to someone solving this, and I'm glad to
hear that SeadataNet may be looking at it.

Cheers -
Nan


On Aug/04/2011 4:13 PM, Lowry, Roy K. wrote:
Hi Nan,

Encoding what I would regard as usage metadata into ancilliary variables is one 
solution, but I would much rather see a formalised metadata model for doing 
this.  As you say a standard way of doing this is long overdue. My hope is that 
SeadataNet II starting later this year will take on and address this challenge. 
 However, if anybody knows of anything already in existence that fits the bill 
it would be good to prevent yet another wheel being reinvented.

Cheers, Roy.

From: cf-metadata-boun...@cgd.ucar.edumailto:cf-metadata-boun...@cgd.ucar.edu 
[cf-metadata-boun...@cgd.ucar.edumailto:cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Nan Galbraith [ngalbra...@whoi.edumailto:ngalbra...@whoi.edu]
Sent: 04 August 2011 19:17
To: Steve Hankin; cf-metadata@cgd.ucar.edumailto:cf-metadata@cgd.ucar.edu
Cc: Jeff deLaBeaujardiere
Subject: Re: [CF-metadata] per-variable metadata?

Hi Steve -

I'm very interested in the background discussion on this -
any chance of bringing it into the foreground?

I'm using ancillary variables in 2-D in situ data files to describe
instruments and things like precision, accuracy, sample scheme,
etc.. For temperature files from moorings where different sensor
types are at different depths, I'd like to use something like

TEMP:ancillary_variables = Instrument_manufacturer Instrument_model
 Instrument_sample_scheme Instrument_serial_number TEMP_qc_procedure
 TEMP_accuracy TEMP_precision TEMP_resolution;
and then
short INST_SN(depth) ;
INST_SN:long_name = instrument_serial_number ;
... etc., etc.

If there's going to be a standard way to do this, I'd really like to
know about it - sooner rather than than later.

Thanks -
Nan

On 8/4/11 11:35 AM, Steve Hankin wrote:
Hi Jeff,

Each variable in a CF file may possess an |ancillary_variables| attribute, that 
points to variables that have relationships 
(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/cf-conventions.html#ancillary-data).
  To attach flags to a variable, use |ancillary_variables| to point to a 
variable that has |flag_values||| and |flag_meanings |attributes 
(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/cf-conventions.html#flags).

We have started a discussion in the background, whether an example that 
illustrates this should be included in the CF documentation.

- Steve

=

On 7/14/2010 6:21 AM, Jeff deLaBeaujardiere wrote:
In another discussion, Steve Hankin wrote:
 CF generally favors attributes attached to variables over attributes attached 
 to files

This reminds me of a question I wanted to ask: does CF have any conventions 
regarding how to handle data that contains multiple observed quantities with 
different quality flags, comment fields or other attributes for each quantity?

-Jeff DLB



--
***
* Nan Galbraith(508) 289-2444 *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543*
***



-- 
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

Re: [CF-metadata] per-variable metadata?

[Lowry, Roy K.]

Hi John,

We seem to have a difference of perception in the fragility of Web access to 
the average scientist.  Certainly, I was assuming ships had virtually the same 
level of internet access as I have at home (if not in the lab) based on my 
experience of the NERC ships.  However, if lack of internet access becomes an 
issue then we need to look at URI resolution to physical XML files sitting with 
the NetCDF.

Cheers, Roy.


From: John Graybeal [jbgrayb...@mindspring.com]
Sent: 05 August 2011 17:57
To: Lowry, Roy K.
Cc: ngalbra...@whoi.edu; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] per-variable metadata?

On Aug 5, 2011, at 09:27, Lowry, Roy K. wrote:

 Hi Nan,

 At the risk of being shot for herecy, I maintain the belief that in the 
 current technological environonment packing everything inside the 
 straightjacket container of a physical file is an anachronism.  snip  So, I 
 would have an attribute in the CF file holding a permanent identifier that is 
 guaranteed to be resolvable from now until eternity into an XML file 
 delivering usage metadata.

I agree with the first statement, because 'everything' is a long list indeed.  
The world of linked open data agrees too, I expect.

But with respect to *usage* metadata, I wonder.  Because the storage of complex 
data for perpetual access on the web is not a solved problem, and not everyone 
has access to the entire web, or at least every metadata provider for every 
file they are working with, all the time.  So then you're stuck, until the ship 
gets back or the DSL line is up or the hosting site finishes its weekly 
maintenance, or someone goes back and resuscitates some old system that had the 
metadata years or decades before.

John-- 
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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] per-variable metadata?

[Lowry, Roy K.]

Hi Nan,

I admit that my thinking is driven by coming from a community 
(SeaDataNet/Geo-Seas) where 99% of data are currently in formats other than 
netCDF (hopefully something that will change in SeaDataNet II) and therefore 
need a usage metadata solution that will initially at least operate across all 
formats in use.  This is why I'm looking at OM/SensorML. I have real concerns 
that a scenario will develop where SDN II partners build XML usage metadata 
stock for their ODV (the ASCII format holding most SeaDataNet data) data 
holdings and then resist migration to CF netCDF if this XML stock cannot be 
utilised.

Whilst admittedly this isn't 100% relevant to a discussion on CF, I would argue 
that if a universal standard requiring XML encoding is developed CF should buy 
into that rather going its own way.  Note that a solution where a specified 
binding to external resources is defined that can sit side-by-side with 
internal encodings for a usage metadata subset would make me happy and shut me 
up (on this issue at least).

Cheers, Roy.

From: Nan Galbraith [ngalbra...@whoi.edu]
Sent: 05 August 2011 20:58
To: Lowry, Roy K.
Cc: John Graybeal; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] per-variable metadata?

I don't think the metadata structure needs to be terribly
complex, in most cases. Changes to instruments (either a
new instrument, a change to the sample scheme, or some
kind of change to calibrations, etc) partway through could
be a problem, but that's true in xml too.

John G is right, we often lose access to the network at sea;
but even without that consideration, NetCDF is supposed to
be self-documenting, and we should be able to come up with
some strategies for including fairly complex metadata in the
files.

I like the ancillary variable route because it seems straightforward
and flexible.

 *   Data variables can share one or more ancillary variables, very useful for 
something like an ADCP record.
 *   Ancillary variables can have data types.
 *   Ancillary variables can have dimensions that make them self-explanatory.

Cheers - Nan


On Aug/05/2011 2:08 PM, Lowry, Roy K. wrote:

Hi John,

We seem to have a difference of perception in the fragility of Web access to 
the average scientist.  Certainly, I was assuming ships had virtually the same 
level of internet access as I have at home (if not in the lab) based on my 
experience of the NERC ships.  However, if lack of internet access becomes an 
issue then we need to look at URI resolution to physical XML files sitting with 
the NetCDF.

Cheers, Roy.


From: John Graybeal 
[jbgrayb...@mindspring.commailto:jbgrayb...@mindspring.com]
Sent: 05 August 2011 17:57
To: Lowry, Roy K.
Cc: ngalbra...@whoi.edumailto:ngalbra...@whoi.edu; 
cf-metadata@cgd.ucar.edumailto:cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] per-variable metadata?

On Aug 5, 2011, at 09:27, Lowry, Roy K. wrote:



Hi Nan,

At the risk of being shot for herecy, I maintain the belief that in the current 
technological environonment packing everything inside the straightjacket 
container of a physical file is an anachronism.  snip  So, I would have an 
attribute in the CF file holding a permanent identifier that is guaranteed to 
be resolvable from now until eternity into an XML file delivering usage 
metadata.


I agree with the first statement, because 'everything' is a long list indeed.  
The world of linked open data agrees too, I expect.

But with respect to *usage* metadata, I wonder.  Because the storage of complex 
data for perpetual access on the web is not a solved problem, and not everyone 
has access to the entire web, or at least every metadata provider for every 
file they are working with, all the time.  So then you're stuck, until the ship 
gets back or the DSL line is up or the hosting site finishes its weekly 
maintenance, or someone goes back and resuscitates some old system that had the 
metadata years or decades before.

John--
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.




--
***
* Nan Galbraith(508) 289-2444 *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543*
***



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] A question regarding standard names

[Lowry, Roy K.]

Hi Jim,

Not the first time this has cropped up on the CF list.  The problem is that 
when the Standard Names started out they were designed as OPTIONAL terms to 
identify model fields that referred to a given geophysical phenomenon.  There 
has been a sort of mission creep since then with standard names being 
considered by some as unique standardised labels for every data channel in a CF 
file, accelerated by some communities choosing to make Standard Names 
compulsory for their CF files. This of course creates the need for more and 
more information to get hung off the Standard Name tag.

I continue to support the conclusion of these previous discussions, which is to 
keep methodologies out of Standard Names unless the methodology results in a 
significantly different phenomenon.  There was quite a debate on this issue 
involving different types of sea surface temperature that you might care to 
look up in the archive.

Cheers, Roy.  

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jim Biard
Sent: 26 August 2011 13:28
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] A question regarding standard names

Hi.

I've got a general question regarding standard names.  I have had people 
I work with asking whether it would be acceptable to have a standard 
name that included methodology, such as microwave_brightness_temperature 
as opposed to infrared_brightness_temperature.  My feeling has been that 
standard names are not supposed to have such differentiators, but I 
haven't read anything that states that directly.  Are standard names for 
measurements limited to essential descriptions, or can they include 
specification of the way the measurement was acquired?

Grace and peace,

Jim Biard

-- 
Jim Biard

Government Contractor, STG Inc.
Remote Sensing and Applications Division (RSAD)
National Climatic Data Center
151 Patton Ave.
Asheville, NC 28801-5001

jim.bi...@noaa.gov
828-271-4900

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] A question regarding standard names

[Lowry, Roy K.]

Hi Nan,

It would be really neat from my point of view if your ancillary variables were 
to include a link to a published vocabulary of instruments (in addition not 
instead of your existing fields).  As you probably know, I can offer you one 
(http://vocab.ndg.nerc.ac.uk/list/L22/)

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Nan Galbraith
Sent: 26 August 2011 14:58
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] A question regarding standard names

I agree with Roy, that as long as the values can be reasonably
compared they should share a standard name.

It would be a good next step, though, to develop or adopt some
standard way to describe the methodology, or at least the instrumentation,
so that the user can allow for any distinction between e.g. microwave and
infrared brightness_temperature.

We're using an ancillary variable for this, but there may be some
other way to do it that we haven't thought of yet. Whatever method
is adopted (when/if one is) it needs to work for files that have data
from different instruments at different depths.

float TEMP(time, depth) ;
TEMP:standard_name = sea_water_temperature ;
TEMP:ancillary_variables =
TEMP_Instrument_manufacturer, TEMP_Instrument_model
 TEMP_Instrument_reference TEMP_Instrument_mount
 TEMP_Instrument_serial_number TEMP_QC TEMP_QC_value
 TEMP_QC_procedure TEMP_Accuracy TEMP_Precision TEMP_Resolution;
char TEMP_Instrument_manufacturer(depth, 20);
char TEMP_Instrument_model(depth,6);
...

Nan

On 8/26/11 9:05 AM, Lowry, Roy K. wrote:
 Hi Jim,

 Not the first time this has cropped up on the CF list.  The problem is that 
 when the Standard Names started out they were designed as OPTIONAL terms to 
 identify model fields that referred to a given geophysical phenomenon.  There 
 has been a sort of mission creep since then with standard names being 
 considered by some as unique standardised labels for every data channel in a 
 CF file, accelerated by some communities choosing to make Standard Names 
 compulsory for their CF files. This of course creates the need for more and 
 more information to get hung off the Standard Name tag.

 I continue to support the conclusion of these previous discussions, which is 
 to keep methodologies out of Standard Names unless the methodology results in 
 a significantly different phenomenon.  There was quite a debate on this issue 
 involving different types of sea surface temperature that you might care to 
 look up in the archive.

 Cheers, Roy.

 -Original Message-
 From: cf-metadata-boun...@cgd.ucar.edu 
 [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jim Biard
 Sent: 26 August 2011 13:28
 To: cf-metadata@cgd.ucar.edu
 Subject: [CF-metadata] A question regarding standard names

 Hi.

 I've got a general question regarding standard names.  I have had people
 I work with asking whether it would be acceptable to have a standard
 name that included methodology, such as microwave_brightness_temperature
 as opposed to infrared_brightness_temperature.  My feeling has been that
 standard names are not supposed to have such differentiators, but I
 haven't read anything that states that directly.  Are standard names for
 measurements limited to essential descriptions, or can they include
 specification of the way the measurement was acquired?

 Grace and peace,

 Jim Biard



-- 
***
* Nan Galbraith(508) 289-2444 *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543*
***



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard names for stations

[Lowry, Roy K.]

Dear All,

I would suggest some fine tuning of this to:

platform_name
platform_id (note this needs to be alphanumeric to support ICES ship codes 
widely used in oceanography)
platform_id_authority (mandatory if platform_id present)
platform_description

I wonder if the concept of authority is relevant to names - who is the 
authority for a ship's name?  Even if relevant, there is no guarantee that the 
authority will be the same as the platfom_id and somebody will want to include 
both a name and an id.  If people feel that a name authority is required then I 
would label it platform_name_authority rather than having one name doing two 
jobs.

The nature of the platform dscription merits a little discussion. Controlled 
terms, particularly if accompanied by definitions, are always much more helpful 
than plaintext. There is an internationally-governed platform type vocabulary 
used in the SeaDataNet and ICES systems (http://vocab.ndg.nerc.ac.uk/list/L06). 
 There is also at least one relevant WMO vocabulary (VOS types).

If formalisation of the description is agreed then we could either keep 
'platform_description' for plaintext and add 'platform_type' plus 
'platform_type_authority' or standardise 'platform_description' by adding 
'platform_description_authority'.

Finally, I think we need to agree how an authority is represented.  My choice 
would be a namespace URL, but maybe there are other ideas.

Cheers, Roy.

From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Jeffrey F. Painter [paint...@llnl.gov]
Sent: 27 August 2011 01:27
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] standard names for stations

It seems to me that we would need four standard_names to satisfy
everyone's needs.   How does this sound?

platform_name: variable of character type containing a character ID or
name of an observing station or other platform
platform_id: variable of integer type, identifying an observing station
or other platform
platform_naming_authority: variable of character type, specifying the
naming authority or system used to choose a platform_id or platform_name
platform_description: variable of character_type which describes an
observing station or other platform

A typical station would have a platform_name or platform_id, but rarely
both.  The reason for having both is that I expect that the numerical
WMO identifiers (of various lengths) will be used very frequently, and
it can be helpful to represent numbers as numbers.  But Eiji's message
shows that we must allow for character identifiers.  A relatively short
character identifier would have a different function from the kind of
long description suggested by  Øystein. The most common
platform_naming_authority would be the originally conceived WMO, of
course.

- Jeff

On 8/26/11 12:36 AM, Øystein Godøy wrote:
 Date: Wed, 24 Aug 2011 16:26:55 -0700
 From: Jeffrey F. Painterpaint...@llnl.gov
 Subject: [CF-metadata] standard names for stations
 To: cf-metadatacf-metadata@cgd.ucar.edu
 Message-ID:4e5588bf.2090...@llnl.gov
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 The draft version 1.6 of the CF Conventions manual recommends use of
 two
 standard names which don't exist yet but are needed to describe discrete
 data such as observations from stations or other discrete points.  So
 I'd like to propose the following two standard names:

 - station_description : variable of character type containing a
 description of a time series station
 - wmo_platform_id : variable of integer type, containing the WMO
 identifier of an observing station or other platform

 - Jeff Painter
 Hi,

 I clearly see the need for this.

 Concerning station_description, I think this is useful whether it is a time
 series or not. There is a need to describe the actual location for the
 station. E.g. describe the surface, horizon, and other aspects that may affect
 the observations.

 Concerning wmo_platform_id, I think Nan Galbraiths suggestion using an id
 and a naming authority is useful and more flexible than specifying a WMO
 reference directly. Concerning my institution, all stations operated by us,
 whether being WMO stations or not, always have an internal ID. Not all
 stations have a WMO id. It may even be useful to be able to use multiple ids
 for stations to cover situations like the one I mention.

 NACCD is good but it does not have the momentum that CF has. Many other
 such discovery conventions for NetCDF files exist and are used, most of
 course differing only slightly. I believe they will merge in time, but for now
 I think NACDD is less used than CF. I certainly agree it should be promoted
 (and we will probably move towards it), but these things take time.

 Thus I would prefer put as much information as possible as CF-compliant
 variables in the dataset, even if it means duplicating them as global
 attributes for discovery purposes.

 All the best
 Øystein

Re: [CF-metadata] Branching history

[Lowry, Roy K.]

Hi All,

Something in the back of my mind from a project in which I have peripheral 
engagement (so may be a red herring or worse).  Didn't Argo put a lot of effort 
into a NetCDF history encoding for their format?

Cheers, Roy.

From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Nan Galbraith [ngalbra...@whoi.edu]
Sent: 06 September 2011 13:46
To: CF list
Subject: Re: [CF-metadata] Branching history

Hi all -

 Are there any existing practices (either established or experimental)
 for the use of the history attribute when dealing with complex,
 branching processing histories?

 Given the history attribute is only intended to be human readable, I
 suspect the answer is no. In which case, what would be more palatable:
 inventing a new syntax, or throwing away everything prior to the last
 linear sequence?

I'm not sure how many existing practices there are, but a new
syntax is *definitely* preferable to loss of this information.

The standard lets you continuously append processing 'events' to
the global history, using a timestamp; in theory you can append
all the branching histories, adding information about which
component was modified (maybe going from datestamp/action to
datestamp/component/action ?). The component identifiers would
need to include enough information to let the user know what
slice, and what variable, was modified by each action.

John's SSDS example shows an interesting way to accumulate
this information, which could be expanded for branched provenance.
It's not quite the same as the NetCDF-defined history attribute,
but it looks like a great way to make this field machine readable.

By the way, here's the definition, from the NetCDF Users' Guide:

 history

 A global attribute for an audit trail. This is a character array with
 a line for each invocation of a program that has modified the
 dataset. Well-behaved generic netCDF applications should append a
 line containing: date, time of day, user name, program name and
 command arguments.

and a snippet from the CF standard:

 2.6.2. Description of file contents

 The NUG defines title and history to be global attributes. We wish
 to allow the newly defined attributes, i.e., institution, source,
 references, and comment, to be either global or assigned to
 individual variables. When an attribute appears both globally and as
 a variable attribute, the variable's version has precedence. ...

 history

 Provides an audit trail for modifications to the original data.
 Well-behaved generic netCDF filters will automatically append their
 name and the parameters with which they were invoked to the global
 history attribute of an input netCDF file. We recommend that each
 line begin with a timestamp indicating the date and time of day that
 the program was executed.

- Nan

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard names for stations

[Lowry, Roy K.]

Hi Jonathan,

My vote would go to something that is both human and machine-readable.  There 
are standards designed for this such as JSON. Some might consider this comes 
down on the side of the machine more than the human, but I find once I get my 
in I can read JSON much easier than XML.

If this is considered to be going over the top then we need to at least specify 
the order in which the component parts of the string are included and 
preferably we should specify a delimiter to separate the components.  Even an 
ultra-light standard such as this makes the life of any programmer writing code 
to parse the string infinitely easier.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
Sent: 16 September 2011 15:32
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] standard names for stations

Dear Nan, John, Jeff

I think variable attributes are generally better than global attributes,
because it's possible or indeed likely that you might have data from different
sources in the same file. I prefer data variables to describe themselves. We
can provide global attributes as a default for the whole file, but it seems
safer to me to repeat the attributes per variable.

Following John's point, I agree that this station ID information will not be
usable by machine or guaranteed to be unique unless we standardise it in some
way. I don't know about this subject, but I am sure there are people who are
well-informed about it! If we want the station ID attribute(s) to be machine-
readable, we can propose a standard format for them. If we want an attr where
the data-writer can informally record ID information that another human could
interpret, we don't need a standard format. Which do we want - any views?

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] new TEOS-10 standard names

[Lowry, Roy K.]

Hello Trevor,

I totally agree that we should stop using 'salinity' from now on.  I also agree 
that virtually all post-1983 (not 1980: it took 5 years to get the 1978 
Equation of State published by UNESCO) data labelled 'salinity' are in fact 
'practical_salinity'.  However, as an oceanographic data centre we have 
salinity data going back to the early 1900s and other centres such as ICES have 
data going back further than that. These have been determined by a variety of 
methodologies but are mostly chemical titrations or a variety of algorithmic 
determinations from conductivity that are significantly different from the 
PSS-78 scale. Replacing 'salinity' by 'practical_salinity' re-labels these 
data, which I believe is wrong.

We certainly need to get 'practical_salinity' names in place and alter the 
definition for salinity to indicate that it means 'salt content by any method' 
with wording to strongly discourage its use for post-1983 data unless the data 
are known to be 'non-practical' (which exist: we have some).  We also need to 
explain to the community that unless they change the labels on their data that 
are practical salinity from 'salinity' to 'practical_salinity' then their data 
will be regarded as useless for many physical oceanographic applications.

Cheers, Roy.

-Original Message-
From: trevor.mcdoug...@csiro.au [mailto:trevor.mcdoug...@csiro.au] 
Sent: 05 October 2011 00:12
To: Lowry, Roy K.; j.m.greg...@reading.ac.uk; paul.dur...@csiro.au
Cc: CF-metadata@cgd.ucar.edu; r...@eos.ubc.ca; King, Brian A.; 
paul.bar...@csiro.au; rainer.feis...@io-warnemuende.de; 
stephen.griff...@noaa.gov
Subject: RE: [CF-metadata] new TEOS-10 standard names

Dear all,

   At the risk of repeating ourselves, because there are now (at least) three 
different salinities, it is now ambiguous and confusing to call any salinity 
Salinity.  The Announcement of TEOS-10 that is now appearing in all 22 
oceanographic journals specifically recommends that the use of the word 
Salinity cease immediately, and that either the words Practical Salinity or 
Absolute Salinity be used.  The reason of course is to minimise ambiguity. 

   So this is where the community (including CF-metadata) will have to end up:- 
we have been requested to do so by IOC, SCOR and IAPSO.  So we may as well do 
it now, in my view.

   Note that all ocean models run to date have used Practical Salinity as their 
Salinity variable,, and all equations of state since 1980 have been in terms 
of Practical Salinity.  So there is no slight-of-hand in calling these 
variables Practical Salinity; rather it is just being specific as to what 
this type of salinity always has been.  That is Practical Salinity is simply 
the long-hand name of what we have been calling Salinity for 30 years.  

   Trevor


-Original Message-
From: Lowry, Roy K. [mailto:r...@bodc.ac.uk] 
Sent: Wednesday, 5 October 2011 1:43 AM
To: Jonathan Gregory; Durack, Paul (CMAR, Hobart)
Cc: McDougall, Trevor (CMAR, Hobart); CF-metadata@cgd.ucar.edu; 
r...@eos.ubc.ca; King, Brian A.; Barker, Paul (CMAR, Hobart); 
rainer.feis...@io-warnemuende.de; stephen.griff...@noaa.gov
Subject: RE: [CF-metadata] new TEOS-10 standard names

Dear All,

My feelings on this were (and still are) comfort with the addition of 
'practical_salinity' names, but significant discomfort with the replacement of 
'salinity' by 'practical_salinity' through deprecation of 'salinity'.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
Sent: 04 October 2011 14:13
To: paul.dur...@csiro.au
Cc: trevor.mcdoug...@csiro.au; CF-metadata@cgd.ucar.edu; r...@eos.ubc.ca; King, 
Brian A.; paul.bar...@csiro.au; rainer.feis...@io-warnemuende.de; 
stephen.griff...@noaa.gov
Subject: Re: [CF-metadata] new TEOS-10 standard names

Dear Paul

Alison (the manager of standard names) hasn't ruled yet on their inclusion,
but I believe that the discussion concluded with no objections to adding
the practical salinity names. It seems safe to assume they will be put in the
table in due course.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] new TEOS-10 standard names

[Lowry, Roy K.]

Hello Reiner/Trevor,

I have no problem with introducing the term Knudsen salinity for salinities 
pre-dating PSS-78.  A question to Reiner is does the term just apply to 
salinity by evaporation/titration or is it equally applicable to salinity data 
obtained by the STDs and CTDs with home-grown conductivity to salinity 
algorithms in use before PSS-78 brought some order to the world?

Note, that having a term for pre-78 data doesn't necessarily allow us to 
immediately deprecate the term 'salinity'.  There's a lot of data out there 
marked up with 'salinity'. Anyone any views on how such deprecation should be 
managed?  My vote would be to set up the new terms and modify the 'salinity' 
definition in the next Standard Names update, map all the new terms as 
narrowMatches to old one and then deprecate 'salinity' in a future Standard 
Names update.

Cheers, Roy.

-Original Message-
From: Rainer Feistel [mailto:rainer.feis...@io-warnemuende.de] 
Sent: 06 October 2011 06:32
To: paul.dur...@csiro.au; j.m.greg...@reading.ac.uk; Lowry, Roy K.; 
trevor.mcdoug...@csiro.au
Cc: stephen.griff...@noaa.gov; paul.bar...@csiro.au; King, Brian A.; 
r...@eos.ubc.ca; CF-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] new TEOS-10 standard names

Since the use of any salinity was discouraged in favour of chlorinity in 
1940,
all archived pre-78 salinities should be Knudsen salinities, originally 
calculated
from chlorinity by the Knudsen formula derived from the evaporation 
experiments
of Soerensen in 1900.

Knudsen salinity is consistent with PSS-78 at about S = 35 but deviates
systematically for brackish water, see our 2008 salinity paper in DSR.

The term Knudsen salinity is well understood, I think.

Rainer

- Original Message - 
From: trevor.mcdoug...@csiro.au
To: r...@bodc.ac.uk; j.m.greg...@reading.ac.uk; paul.dur...@csiro.au
Cc: CF-metadata@cgd.ucar.edu; r...@eos.ubc.ca; b...@noc.soton.ac.uk; 
paul.bar...@csiro.au; rainer.feis...@io-warnemuende.de; 
stephen.griff...@noaa.gov
Sent: Wednesday, October 05, 2011 11:17 PM
Subject: RE: [CF-metadata] new TEOS-10 standard names


Hello Roy,

  You make a good point about the pre 1978 data.  Perhaps we need yet 
another name, such as Pre78salinity to indicate that it was probably 
obtained by chemical titration.  By introducing such a salinity will have 
the advantage of reducing the present ambiguity which calls this older data 
by the same name as Practical Salinity, namely salinity.

Trevor


-Original Message-
From: Lowry, Roy K. [mailto:r...@bodc.ac.uk]
Sent: Wednesday, 5 October 2011 6:53 PM
To: McDougall, Trevor (CMAR, Hobart); j.m.greg...@reading.ac.uk; Durack, 
Paul (CMAR, Hobart)
Cc: CF-metadata@cgd.ucar.edu; r...@eos.ubc.ca; King, Brian A.; Barker, Paul 
(CMAR, Hobart); rainer.feis...@io-warnemuende.de; stephen.griff...@noaa.gov
Subject: RE: [CF-metadata] new TEOS-10 standard names

Hello Trevor,

I totally agree that we should stop using 'salinity' from now on.  I also 
agree that virtually all post-1983 (not 1980: it took 5 years to get the 
1978 Equation of State published by UNESCO) data labelled 'salinity' are in 
fact 'practical_salinity'.  However, as an oceanographic data centre we have 
salinity data going back to the early 1900s and other centres such as ICES 
have data going back further than that. These have been determined by a 
variety of methodologies but are mostly chemical titrations or a variety of 
algorithmic determinations from conductivity that are significantly 
different from the PSS-78 scale. Replacing 'salinity' by 
'practical_salinity' re-labels these data, which I believe is wrong.

We certainly need to get 'practical_salinity' names in place and alter the 
definition for salinity to indicate that it means 'salt content by any 
method' with wording to strongly discourage its use for post-1983 data 
unless the data are known to be 'non-practical' (which exist: we have some). 
We also need to explain to the community that unless they change the labels 
on their data that are practical salinity from 'salinity' to 
'practical_salinity' then their data will be regarded as useless for many 
physical oceanographic applications.

Cheers, Roy.

-Original Message-
From: trevor.mcdoug...@csiro.au [mailto:trevor.mcdoug...@csiro.au]
Sent: 05 October 2011 00:12
To: Lowry, Roy K.; j.m.greg...@reading.ac.uk; paul.dur...@csiro.au
Cc: CF-metadata@cgd.ucar.edu; r...@eos.ubc.ca; King, Brian A.; 
paul.bar...@csiro.au; rainer.feis...@io-warnemuende.de; 
stephen.griff...@noaa.gov
Subject: RE: [CF-metadata] new TEOS-10 standard names

Dear all,

   At the risk of repeating ourselves, because there are now (at least) 
three different salinities, it is now ambiguous and confusing to call any 
salinity Salinity.  The Announcement of TEOS-10 that is now appearing in 
all 22 oceanographic journals specifically recommends that the use of the 
word Salinity cease immediately, and that either the words Practical 
Salinity or Absolute

Re: [CF-metadata] SUGGESTED WAY FORWARD FOR CF-metadata:- lets finalize this discussion.

[Lowry, Roy K.]

Hello Trevor,

We're now all saying the same thing.  The important thing is that Alison gets 
new Standard Names into the system for practical_salinity , absolute_salinity 
and Knudsen_salinity (Jonathan: should it be Knudsen or knudsen?) in the next 
update so they are available for use for new data and for re-labelling legacy 
data by those with the inclination/resources to do so.

We cannot physically stop further use of 'salinity' without causing issues for 
legacy data.  All we can do, as Jonathan stated is take steps to strongly 
discourage its use through appropriate wording in its definition.

Hopefully, case closed!

Cheers, Roy.


From: trevor.mcdoug...@csiro.au [trevor.mcdoug...@csiro.au]
Sent: 08 October 2011 02:49
To: Lowry, Roy K.; rainer.feis...@io-warnemuende.de; paul.dur...@csiro.au; 
j.m.greg...@reading.ac.uk
Cc: stephen.griff...@noaa.gov; paul.bar...@csiro.au; King, Brian A.; 
r...@eos.ubc.ca; CF-metadata@cgd.ucar.edu
Subject: RE: [CF-metadata] SUGGESTED WAY FORWARD FOR CF-metadata:- lets 
finalize this discussion.

Dear All,

I think that the reason that we are facing a dilemma is simply because the word 
salinity now stands for a variety of things.  That is, we have not been as 
careful with salinity as we now realize we should have been over the past 50 
or 100 years.

My understanding of oceanographic practice is that between the Knudsen equation 
of 1901 and the year 1978 any calculated salinity quantity would have tried 
to be Knudsen salinity, no matter if it was calculated via titration or via a 
conductivity measurement (as occurred in the 1960s and 1970s).  Hence it is 
quite valid to call such an old data point a Knudsen_Salinity.  Note that we 
do not reserve a name for a particular measurement technique.  Hence, for 
example, the salinity out of a climate model is called Practical Salinity to 
date even though the value did not result from a conductivity measurement.  
Also a value of Absolute Salinity is still absolute salinity no matter 
whether it was calculated from either of the two recommended methods.




 SUGGESTED WAY FORWARD FOR CF-metadata

So any new (=2010) data going into a data base should be labelled as either 
Knudsen Salinity, Practical Salinity or Absolute Salinity, and the name 
Salinity should most definitely not be available as an option for any new 
(=2010) data going into a data base, whether from a cruise, a mooring or from 
model output.  I think this is quite clear, yes?  I think there can be no 
argument about this, and to do otherwise would just cause confusion.  Can you 
make this happen in CF-metadata Paul?  This is essentially what we are being 
instructed to do by IOC, IAPSO and SCOR, and it makes perfect sense.

But what should we do about the data in data bases that is presently called 
salinity.  My suggestion now is that we just let this data sit there as is.  
We leave it up to the individual researcher to interpret what this data is.  
For example, in our research, Paul Barker and I get this data and interpret it 
as Knudsen Salinity if it was collected before 1st January 1978, and Practical 
Salinity if it was collected on or after 1st January 1978.




Can we all agree on the last two paragraphs, and can you, Paul Durack and Nan, 
make this happen?  Until we agree on this as a procedure, there is little point 
in worrying about the exact wording of the definitions of the variables.  Can 
we all get back to each other with what we think about the suggested way 
forward that I describe in the above two paragraphs?

Roy, I think what I wrote above is possibly the same as what you are 
suggesting, but I'm not sure what some of the technical words that you use 
mean:- deprecate, Narrowmatches, etc.

With best wishes,

  Trevor








-Original Message-
From: Lowry, Roy K. [mailto:r...@bodc.ac.uk]
Sent: Thursday, 6 October 2011 6:28 PM
To: Rainer Feistel; Durack, Paul (CMAR, Hobart); j.m.greg...@reading.ac.uk; 
McDougall, Trevor (CMAR, Hobart)
Cc: stephen.griff...@noaa.gov; Barker, Paul (CMAR, Hobart); King, Brian A.; 
r...@eos.ubc.ca; CF-metadata@cgd.ucar.edu
Subject: RE: [CF-metadata] new TEOS-10 standard names

Hello Reiner/Trevor,

I have no problem with introducing the term Knudsen salinity for salinities 
pre-dating PSS-78.  A question to Reiner is does the term just apply to 
salinity by evaporation/titration or is it equally applicable to salinity data 
obtained by the STDs and CTDs with home-grown conductivity to salinity 
algorithms in use before PSS-78 brought some order to the world?

Note, that having a term for pre-78 data doesn't necessarily allow us to 
immediately deprecate the term 'salinity'.  There's a lot of data out there 
marked up with 'salinity'. Anyone any views on how such deprecation should be 
managed?  My vote would be to set up the new terms and modify the 'salinity' 
definition in the next

Re: [CF-metadata] standards for probabilities

[Lowry, Roy K.]

Hello Vergand,

One of my jobs is running a parameter vocabulary that currently has over 27,000 
entries.  Much of its bulk is due to the assignment of multiple parameter names 
for each step in a numeric sequence - such as radiation wavelengths or sediment 
grain-size expressed as percentiles.

Consider a scenario where you start with a small group of standard percentiles 
- say 5, 25, 50, 75, 95.  You set up a parameter name for each of these in the 
first instance, which is easy. Then along comes another user who wants to 
describe data with percentiles at a resolution of 1 per cent.  So another 95 
parameter names need to be set up.  Then along comes another user who wants a 
resolution of 0.1 per cent.  I start drowning in names and nobody can find 
anything.

However, had I followed Jonathan's second solution all I would need to do as a 
vocabulary manager is set up one concept to describe the percentile axis, which 
covers every user from those who use a handful of percentiles to those whose 
percentile resolution requirements are beyond the bounds of my imagination.

I know Jonathan's first option was based on propogation of cell methods and not 
standard names.  However, these still need managing and if they become 
excessively abundant they also become difficult to navigate.

Cheers, Roy.


From: Vegard Bønes [vegard.bo...@met.no]
Sent: 15 November 2011 13:17
To: Lowry, Roy K.
Cc: cf-metadata@cgd.ucar.edu; Jonathan Gregory
Subject: Re: [CF-metadata] standards for probabilities

Dear Roy,

Can you be a bit more concrete about why you prefer the second alternative?


-- Vegard


- Original Message -
Fra: Roy K. Lowry r...@bodc.ac.uk
Til: Jonathan Gregory j.m.greg...@reading.ac.uk, Vegard B??nes 
vegard.bo...@met.no
Kopi: cf-metadata@cgd.ucar.edu
Sendt: 15. november 2011 11:17:01
Emne: RE: [CF-metadata] standards for probabilities

Dear Jonathan,

I prefer your second alternative.  It's not what I do, but it's what I wish I 
did!!

Cheers, Roy.


From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Jonathan Gregory [j.m.greg...@reading.ac.uk]
Sent: 15 November 2011 10:11
To: Vegard B??nes
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] standards for probabilities

Dear Vegard

 I want to express such things as 25th percentile precipitation amount 
 (based on ensemble data), and probability that air temperature will be within 
 2.5 degrees of the forecast. How should I do this?

You are right, this case has not yet been dealt with, although the guidelines
for construction of standard names foresee that needs like this might arise!

If the quantity is a precipitation_amount, it's fine to use that standard
name. The question is how to record that is the 25th percentile. Two possible
ways to do this would be:

* To extend the possible syntax of cell_methods so that it can describe
percentiles. It is already possible to indicate a median in cell_methods, and
that is a particular percentile. The advantage of this way of doing it would
be that you would record whether the distribution of precipitation amounts
being considered was for time-variation, or spatial variation, or some other
kind of variation. Obviously you could have a probability distribution with
percentiles for many different independent variables.

* To use a size-1 or scalar coordinate variable to record the probability,
with a new standard_name, perhaps
cumulative_distribution_function_of_precipitation_amount.
The value of this coordinate would be 0.25 for the 25th percentile. The
advantage of this method would be that you could have several different
percentiles in the same variable, by having a multivalued probability coord.
If you wanted to be specific about what the independent variable was, that
would have to be included in the standard name as well e.g.
cumulative_distribution_function_of_precipitation_amount_over_time.

What do you think?

Cheers

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] new TEOS-10 standard names

[Lowry, Roy K.]

Hi John,

I have a concern with your exclusion of the surface from the term 
sea_water_temperature.  What Standard Name would you use for the temperature 
data stream in a CTD profile that extends from the surface to depth?  I'm more 
comfortable with the idea of keeping sea_water_temperature vague so it can 
include a mixture of surface and within water body measurements, but making the 
SST terms explicitly exclude temperatures within the water body. 

Cheers, Roy.

From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of John Graybeal [jbgrayb...@mindspring.com]
Sent: 26 November 2011 03:59
To: Alison Pamment
Cc: CF Metadata List
Subject: Re: [CF-metadata] new TEOS-10 standard names

Alison,

You do impressive work.

On Nov 25, 2011, at 12:03, alison.pamm...@stfc.ac.uk 
alison.pamm...@stfc.ac.uk wrote:

 (b) sea_water_temperature
 There is agreement to retain the standard name sea_water_temperature as this 
 is useful particularly for observations. It currently has no explanatory 
 text. In response to the discussion I propose to add the following sentence: 
 'Sea temperature is the in situ (bulk) temperature of the sea water, not the 
 surface or skin temperature.'

In the proposed definition, do you mean to say 'Sea water temperature is ...' ?

Regarding the existing salinity quantities, the straightforward conclusion 
(though not implementation) is to make parallel changes to those quantities, 
and add parallel quantities at least for sea_water_practical_salinity, on the 
assumption that the users of the original quantities would need the replacement 
and practical is a likely replacement (I'm guessing here).

However, to a degree this violates the 'wait for demand' principal of CF.  A 
solution might be to put out the question, for each original quantity together 
with each new salinity (practical, absolute, preformed) Do you need this 
value, and if so, would you suggest a correction to the definition? Those with 
the needs could check the appropriate boxes, and you could backfill any others 
that are needed later.

John




John Graybeal   mailto:jgrayb...@ucsd.edu
phone: 858-534-2162
Product Manager
Ocean Observatories Initiative Cyberinfrastructure Project: 
http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http://marinemetadata.org

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] udunits corresponding to Forel-Ule, milliequivalent

[Lowry, Roy K.]

Hi Upendra,

The Forel-Ule is another example where parameter semantics have been off-loaded 
in the units of measure, such as 'milligrams per gram of dry sediment'.  I have 
been working to eliminate this by moving the semantics into the parameter 
description to leave a UDUNITS-compatible UoM.

In BODC we have an equivalent to a Standard Name of 'Colour of the water body 
by visual estimation and conversion to a number on the Forel-Ule scale' which 
has units of dimensionless. This would require a new Standard Name were this 
approach to be used in CF.

I'm guessing you want milliequivalents for total alkalinity data.  Previously 
in CF the standard name 'sea_water_alkalinity_expressed_as_mole_equivalent' has 
been used with the canonical unit 'Moles per cubic metre', which is a pragmatic 
solution to your problem that works in the oceanographic domain because 
alkalinity is the only thing we encounter in Equivalents and luckily for us the 
chemistry is such that 1 Mole = 1 Equivalent.

Cheers, Roy.

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Steve Emmerson
Sent: 08 December 2011 23:58
To: Upendra Dadi
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits corresponding to Forel-Ule, milliequivalent

Upendra,

From the perspective of the UDUNITS unit-packages, the unit Forel-Ule
is the unit Forel multiplied by the unit Ule -- neither, of which,
is known by the UDUNITS or UDUNITS2 packages. I suggest you contact the
author.

Regards,
Steve Emmerson

On 12/08/2011 09:05 AM, Upendra Dadi wrote:
 Hi,
   I have some data which has Forel-Ule for the units used. Is there a
 udunits corresponding to this? Also, what should I use for
 milliequivalent ? Thanks for the help.
 Upendra
 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard name for sea water ph without

[Lowry, Roy K.]

Hi Upendra,

It comes down to the significance of the difference between parameters 
according to tha application for which they are used.  There ae two temperature 
scales - IPTS68 and ITS90.  However, pragamatically for the period of time when 
IPTS68 was used the measurement uncertaintyfor sea temperature was 
significantly greater than the difference between the two scales.  Assuming 
that sea temperature = ITS90 worked in practice (I hope everybody remembered to 
convert their post-90 high accuracy data to IPTS68 prior to input to the PSS78 
algorithms:-)).

According to the expert carbonate system chemists, the difference between the 
pH scales is critical to their science - talk to the guys at CDIAC for more 
information.  Hence the conclusion from the 2009 discussion.

Cheers, Roy.

From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Upendra Dadi [upendra.d...@noaa.gov]
Sent: 09 December 2011 15:58
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] standard name for sea water ph without

Thank you Jonathan and John for your emails.

 I went through your earlier emails. One of the things that occurred to me is 
that these discussions that you had are as much a part of the standard as the 
names themselves.  I think it would be great if there is better connection 
between your email conversation and the standard name tables. Often the short 
summary given in the standard name table, while useful, is not sufficient to 
understand what the name stands for.

Coming to the problem of coming up with a standard name for pH accurately, I 
can see the issue here. Though I am still not sure why not all five standard 
names were included. If there is an analogy between sea water pH and sea water 
temperature, as mentioned in one of the emails, why not have sea_water_pH just 
as we have sea_water_temperature?

Upendra

On 12/8/2011 1:39 PM, John Graybeal wrote:
Hi Upendra,

The reason the reporting scale is attached to this name is that the 
fundamental measurement, or property, to which it refers produces numbers that 
are not comparable to pH derived using other techniques. (They are actually 
measuring different quantities, not just a different offset/scale value.)

From what I (not a scientist!) understand, it is often the case that pH that 
doesn't mention its scale has been measured in a way that is not an effective 
indicator of pH in sea water.  So it is very important to understand the way 
the pH was measured, in order that the values be reported compatibly with 
others.

I am not knowledgeable enough to know the right answer to your two questions, 
but the above may be useful input.

John

On Dec 8, 2011, at 08:35, Upendra Dadi wrote:

Hi All,
  The standard name table has an entry called 
sea_water_ph_reported_on_total_scale.  I have some data which does not 
mention the scale used for the measurement of ph. Should there be an another 
entry which does not mention the scale? Most of the standard names I have seen 
doesn't mention the scale used. Is it common to attach within standard name, 
the scale used for the measurement?

Upendra
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edumailto:CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard name for sea water ph without

[Lowry, Roy K.]

Hi Philip,

I like that idea.  I've always tried to label data such that future users can 
judge the applicability of that data to their requirements.  pH on an unknown 
scale might be useless to a deep-ocean carbonate chemist, but works for some 
datasets I have from the Humber where pH ranges from 4 (locally near certain 
industrial outlets) to almost 8 and the biologists want to know if the water 
will support certain kinds of life.

I also noticed in this thread the wish to search for related parameters.  Those 
interested in this might like to know that I maintain a mapping between the 
Standard Names and a SeaDataNet discovery vocabulary 
(http://vocab.nerc.ac.uk/collection/P02). See for example 
http://vocab.nerc.ac.uk/collection/P02/current/ALKY/ to see how various 
Standard Names related to carbonate chemistry can be found (the Standard Names 
are the URLs including the reference P07). 

Cheers, Roy.

P.S. the observant might notice a syntactic change in the above URLs from 
others I have posted to the list in the past.  This is due to the release of a 
new version (2.0) of the NERC Vocabulary Server.


From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Cameron-smith, Philip [cameronsmi...@llnl.gov]
Sent: 10 December 2011 09:09
To: John Graybeal; Jonathan Gregory
Cc: cf-metadata@cgd.ucar.edu; Upendra Dadi
Subject: Re: [CF-metadata] standard name for sea water ph without

Hi All,

Would it work to include an 'unknown' scale?

Best wishes,

  Philip

---
Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab.
---


 -Original Message-
 From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-
 boun...@cgd.ucar.edu] On Behalf Of John Graybeal
 Sent: Friday, December 09, 2011 4:34 PM
 To: Jonathan Gregory
 Cc: cf-metadata@cgd.ucar.edu; Upendra Dadi
 Subject: Re: [CF-metadata] standard name for sea water ph without


 On Dec 9, 2011, at 10:29, Jonathan Gregory wrote:

  Though I am still not sure why not all five standard names were
 included. If there is an analogy between sea water pH and sea water
 temperature, as mentioned in one of the emails, why not have
 sea_water_pH just as we have sea_water_temperature?
 
  I think the reason not all five were added is that only one of them
 was requested at the time. I believe that was the right decision,
 because it's generally only when we have a real use-case that the
 expertise is at hand i.e. the proposer to explain what is required.

 Ah, my previous comment was to the wrong point. Jonathan is correct in
 the CF sense of things -- we requested all 5, but it was determined we
 only really needed 1 of the 5 at that time.  Consistent with the CF
 philosophy, we elected not to cause ourselves trouble by looking
 ahead.  (By the way, I like your idea of referencing the thread
 somehow. Would be a nice contextual bit for those new to the
 discussion.)

 On Dec 9, 2011, at 11:47, Upendra Dadi wrote:

  But the semantic issues should not become operational bottlenecks. I
 work at a data center where I do come across datasets where ambiguities
 about what the data represents is not uncommon. Often, it is almost
 impossible to resolve the ambiguities. If I have dataset which has an
 accompanying document which says that the dataset represents sea water
 pH without giving any scale, there should still be a way to encode this
 information into the dataset. ... Of course, I can put this information
 as part of long name or comment which is unstructured information, but
 for deep semantic searches this is not an ideal solution.


 I like this point.

 One of the clear strengths of the CF vocabulary is that it has strong,
 conscientious community review, not to mention professional management,
 and that all of that is devoted to creating crisp terminology. I like
 your point here, and I could envision a subclass of names that are not
 so strongly constrained. (Oddly, a good name for this concept eludes
 me!)  It would be nice to be able to search data, using standard names,
 for a class of parameter -- e.g., 'anything measuring sea_water_ph'.

 This is enough of a variation on the current approach that it would
 almost certain require a TRAC ticket proposal and some discussion
 (because many of the generic terms would require different units under
 different circumstances, which is very non-CFish). So, let's see if
 there's interest

 John

 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata-- 
This message (and any attachments) is for the recipient only. NERC
is 

Re: [CF-metadata] Convention attribute

[Lowry, Roy K.]

Dear All,

One thought that this debate has brought to mind is what should the practice be 
if the file convention is a profile (in the ISO sense) of CF?  In other words, 
the file conforms to a given version of CF modified by a formally documented 
set of extensions (e.g. optional CF attributes declared as mandatory or 
additional attributes in the profile's namespace).  Should both the CF 
convention and the profile name be included?  My vote would be yes to avoid 
application software having to be aware of all CF profiles, but should there be 
any indication that it is a profile rather than an independent parallel 
standard?

Cheers, Roy.


From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Jonathan Gregory [j.m.greg...@reading.ac.uk]
Sent: 28 December 2011 22:22
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Convention attribute

Dear Mark and Dave

I agree with Dave's answers. If two conventions are used together, it is the
responsibility of the data-writer to guarantee that the metadata supplied is
consistent if there are any overlaps in meaning. A particular case of that is
if the two conventions define attributes with the same names. It has been
suggested that conventions could signal their own name-spaces e.g. CF
attributes could all be prefixed with cf_ (like the cf_role attribute, which
has been introduced in the new CF section 9). That could help with preventing
collisions of namespaces, but

* it would be cumbersome for writers of files that adhere to only one
convention, which is the usual case, and awkward for programs that read files,
since they would have to check for every attribute by two different names
(with and without the prefix, considering all the data that already exists
without prefixes).

* it doesn't help if the two conventions are inconsistent in their metadata,
whether or not they use similarly named attributes, and this is the more
serious problem, I would argue.

Therefore I don't think this is really a magic solution to get rid of the
potential difficulty. Rather, the writers of conventions have to be aware of
other netCDF conventions that might be used with theirs, and try to use ones
that already exist instead of defining new ones for a given purpose.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Convention attribute

[Lowry, Roy K.]

Thanks Mark,

It's good to have somebody reading stuff that I should read but never have the 
time! That certainly works for me. Providing there are no comments to the 
contrary that would make ''CF-1.6/SeaDataNet' or maybe 'CF-1.6/SeaDataNet-1.0' 
the value to be specified in the conventions attribute for the SeaDataNet 
NetCDF profile that will be a part of SeaDataNet II.

I feel it is essential for profile documentation to be published if data 
conforming to that profile are to be made publicly available.  Further, if the 
data are to be exposed through INSPIRE then the way in which the profile is 
documented should follow the ISO conventions (it's one of the ISO19xxx 
documents, but I forget which).

Cheers, Roy. 

From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Hedley, Mark [mark.hed...@metoffice.gov.uk]
Sent: 29 December 2011 13:27
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Convention attribute

hello Roy

I wonder if this could be captured by the notation in the Unidata documentation:

'''
Later, if another group agrees upon some additional conventions for a specific 
subset of XXX data, for example time series data, the description of the 
additional conventions might be associated with the name XXX/Time_series, and 
files that adhered to these additional conventions would use the global 
attribute

:Conventions = XXX/Time_series ;
'''
(http://www.unidata.ucar.edu/software/netcdf/conventions.html)


Does this provide a mechanism for profiling CF?:

:Conventions = CF-1.6/mark'sFruityProfile

Does the profile name mark'sFruityProfile get recorded somewhere?

Should this be published, or can I keep it to myself and my friends?

By the nature of the :Conventions declaration I have stated that 
mark'sFruityProfile is CF compliant, is that enough information?

cheers
mark

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu on behalf of Lowry, Roy K.
Sent: Thu 29/12/2011 10:08
To: Jonathan Gregory; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Convention attribute

Dear All,

One thought that this debate has brought to mind is what should the practice be 
if the file convention is a profile (in the ISO sense) of CF?  In other words, 
the file conforms to a given version of CF modified by a formally documented 
set of extensions (e.g. optional CF attributes declared as mandatory or 
additional attributes in the profile's namespace).  Should both the CF 
convention and the profile name be included?  My vote would be yes to avoid 
application software having to be aware of all CF profiles, but should there be 
any indication that it is a profile rather than an independent parallel 
standard?

Cheers, Roy.


From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Jonathan Gregory [j.m.greg...@reading.ac.uk]
Sent: 28 December 2011 22:22
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Convention attribute

Dear Mark and Dave

I agree with Dave's answers. If two conventions are used together, it is the
responsibility of the data-writer to guarantee that the metadata supplied is
consistent if there are any overlaps in meaning. A particular case of that is
if the two conventions define attributes with the same names. It has been
suggested that conventions could signal their own name-spaces e.g. CF
attributes could all be prefixed with cf_ (like the cf_role attribute, which
has been introduced in the new CF section 9). That could help with preventing
collisions of namespaces, but

* it would be cumbersome for writers of files that adhere to only one
convention, which is the usual case, and awkward for programs that read files,
since they would have to check for every attribute by two different names
(with and without the prefix, considering all the data that already exists
without prefixes).

* it doesn't help if the two conventions are inconsistent in their metadata,
whether or not they use similarly named attributes, and this is the more
serious problem, I would argue.

Therefore I don't think this is really a magic solution to get rid of the
potential difficulty. Rather, the writers of conventions have to be aware of
other netCDF conventions that might be used with theirs, and try to use ones
that already exist instead of defining new ones for a given purpose.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF

Re: [CF-metadata] Convention attribute

[Lowry, Roy K.]

Hi John,

Guess we're on the same wavelength.  99% of usage of the conventions attribute 
string will be searches using functions like INSTR (function that locates a 
substring wihin a string), which make delimiters irrelevant but as Benno 
pointed out carry a (minimal if we're aware) element of risk.  Therefore those 
of us that care are free to use delimiter conventions to convey semantics on 
the understanding that their point will be missed by the vast majority of users.

Cheers, Roy.


From: John Graybeal [jbgrayb...@mindspring.com]
Sent: 02 January 2012 18:47
To: Lowry, Roy K.
Cc: CF Metadata List; sdn2-t...@seadatanet.org
Subject: Re: [CF-metadata] Convention attribute

I wasn't sure how to parse these, I'm a little slow today I guess.  After 
trying a few ways, I decided they mostly use spaces to separate convention 
identifiers, and slashes to designate hierarchy. (Except the first two embed a 
space within OceanSITES x.x, which I think should be a hyphen.)

Then I finally got your point, that / (slash) is also a delimiter, but one with 
an explicit meaning.

 I guess the $64,000 question is whether any application program cares about 
 such subtleties and I think the answer is probably not.

As of today, certainly no application program cares about such subtleties, 
since no standard or community practice exists to make use of them. But even if 
we state the question as what is likely to be the most useful in the future, 
while being usable now? (likely what you meant), I can't find a use case where 
the computer would use the order information, other than for display -- the 
context being of some educational value to users of the data sets, as you say.

But this leads to an implementation question, using the examples (modified with 
hyphens per the above comment):

 (A) CF-x.x OceanSITES-x.x SeaDataNet-x.x -- 3 conventions are listed
 (B) CF-x.x/OceanSITES-x.x/SeaDataNet-x.x -- 1 conventions are listed,  
 with its relationship to two others
 (C) CF-x.x/SeaDataNet-x.x CF-x.x/OceanSITES-x.x-- 2 conventions are 
 listed, each with its relationship to a third

From these strings, in the first and third case we don't really know either 
way about some of the relationships -- the fact that SeaDataNet-x.x is listed 
separately from OceanSITES-x.x may mean it is truly independent, but it could 
just as well be derivative, unless we explicitly preclude that usage. Stated 
another way, do I have to list every derivative relationship in my Convention 
Attribute? That is, if SeaDataNet profiles OceanSites which profiles CF, do I 
have to use form (B) for a SeaDataNet Convention identifier, or are forms (A) 
and (C) equally acceptable?

If all agree form (B) is the only acceptable form, then the profiles can 
reflect that explicitly when they define the identifier (the SeaDataNet 
profiler ID will always be of the form (B), and every time CF or OceanSITES 
updates their profile, SeaDataNet needs to double-check that no conflicts have 
been created with their profile, and perhaps put out an updated 'version 
conformance' list each time to reflect that check being successful). Validation 
software could reasonably expect to validate appropriate sequences, and reject 
invalid ones.

If we say any of these forms is OK, then I expect slash will become an 
equivalent to space over time.  Users will start using the (B) form, but get 
things out of order (which software won't have any reason to catch), and soon 
the attribute will just be treated as a list that supports multiple separators.

John










On Dec 31, 2011, at 03:50, Lowry, Roy K. wrote:

 We therefore end up with several possibilities for the Convention Attribute:

 CF-x.x OceanSITES x.x SeaDataNet-x.x
 CF-x.x/OceanSITES x.x/SeaDataNet-x.x
 CF-x.x/SeaDataNetx.x CF-x.x/OceanSITES x.x

 These have subtly different semantics.  The first says nothing about the 
 convention relationship.  The second states SeaDataNet is a profile of 
 OceanSITES which is in turn a profile of CF.  The third states that the file 
 is conformant to two independent profiles of CF.

 I guess the $64,000 question is whether any application program cares about 
 such subtleties and I think the answer is probably not. Most will simply 
 search for the convention required by the application within the attribute 
 string.  Therefore we should be more concerned to ensure that our convention 
 designators avoid including well-known designators - like 'CF' - as 
 substrings than with delimiters. Therefore,having information about the 
 relationship between conventions recorded within the file is useful 
 provenance metadata that could be achieved at virtually no cost.



John Graybeal   mailto:jgrayb...@ucsd.edu
phone: 858-534-2162
Product Manager
Ocean Observatories Initiative Cyberinfrastructure Project: 
http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http://marinemetadata.org-- 
This message (and any

Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6

[Lowry, Roy K.]

Hi again,

The reason that I prefer depth to pressure as the dimension for CTD is that the 
information required for pressure to depth conversion is virtually always 
present in the CTD data.  However, in other oceanographic profiles - say 
nutrient bottle data - it is quite possible to have depth present without 
temperature and salinity, making the conversion to pressure impossible.  
Calculating depth from pressure at the time of standardised formatting of CTD 
data is as you say is trivial.  So, why not make the CTD data more compatible 
with bottle data for very little cost?

SeaDataNet already mandate inclusion of depth in their other data formats for 
CTD data delivery and so I can't see them switching to pressure for the 
dimension in NetCDF.

Cheers, Roy.


From: andrew walsh [awa...@metoc.gov.au]
Sent: 03 April 2012 06:15
To: Lowry, Roy K.
Cc: Jim Biard; Upendra Dadi; cf-metadata@cgd.ucar.edu; Luke Callcut; 
g...@metoc.gov.au; sdn2-t...@seadatanet.org
Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6

Hi Roy/All,

Agree totally it would be good to get this CTD netCDF done in an interoperable
way.

Regarding having pressure vs. depth. We liked to use pressure because:

1) It is the thing that is measured, let us store just that and calculate depth
if needed.

2) Depth can later be easily be calculated on the fly
using the 'Pressure to Depth' algorithm in  UNESCO (1983) Techinical
Papers in Marine Science 44, Algorithms for Computation of fundamental
properties
of Seawater. One can use the python seawater library (see
http://packages.python.org/seawater/ )
and seawater.csiro.depth(p, lat) to get depth from pressure and
seawater.csiro.pres(depth, lat)
to get pressure from depth.

3) I noted that the ARGO project (1's CTD like profiles) and others like
CSIRO Oceanography in Aust. make data available with just pressure.

4) It makes our processing and QC a whole lot simpler. We don't
have to worry about calculating and managing the extra 'depth' variable.

Is  there any problem with having the pressure as a co-ordinate which isn't
really a dimensional
quantity like depth (z) in the 4-D sense i.e x,y,z,t ?

However I note that pressure (decibar) is allowed as a vertical axis e.g see
section
4.3. Vertical (Height or Depth) Coordinate of CF v1.6 conventions document which
says:

A vertical coordinate will be identifiable by:

. units of pressure; or
. the presence of the positive attribute with a value of up or down (case
insensitive).


AND

section 4.3.1. Dimensional Vertical Coordinate which says:

The units attribute for dimensional coordinates will be a string formatted as
per the udunits.dat3 file. The
acceptable units for vertical (depth or height) coordinate variables are:

. units of pressure as listed in the file udunits.dat. For vertical axes the
most commonly used of these include
include bar, millibar, decibar, atmosphere (atm), pascal (Pa), and hPa.
...
...¶


Regards,

Andrew

- Original Message -
From: Lowry, Roy K.
To: andrew walsh
Cc: Jim Biard ; Upendra Dadi ; cf-metadata@cgd.ucar.edu ; Luke Callcut ;
g...@metoc.gov.au ; sdn2-t...@seadatanet.org
Sent: Tuesday, April 03, 2012 2:16 PM
Subject: RE: [CF-metadata] Ocean CTD data following CF Conventions v1.6


Hi Andrew,

SeaDataNet will very soon be considering how it is going to encode data,
including single CTD casts, in CF-compliant NetCDF and so I think the time is
ripe for agreeing how the significant numbers of us who indulge in this practice
for whatever reason do it.  That way we'll end up with interoperable data.

I think there are a number of people on this list who have already encoded
single CTDs into NetCDF and so it would be useful to start by asking for
descriptions (like Andrew's examples) of how this has been done and what tools
are dependent upon that encoding.

The z co-ordinate parameter (pressure/depth) is also an issue worth resolving.
Whilst interconversions are relatively straightforward, agreement would make
life much easier.  My preference leans dowards having depth as the dimension
with pressure as an optional variable. That way we interoperate with other kinds
of oceanographic profile data such as bottle data.

If we can get that far, we can then look at how to aggregate multiple CTDs into
a file according to the CF point data conventions.

Cheers, Roy.


From: andrew walsh [awa...@metoc.gov.au]
Sent: 03 April 2012 04:39
To: Lowry, Roy K.
Cc: Jim Biard; Upendra Dadi; cf-metadata@cgd.ucar.edu; Luke Callcut;
g...@metoc.gov.au
Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6


Hello Roy, Upendra, Jim and CF list,

Thanks for all your feedbacks.
My proposal relates to single CTD profile data (a vertical profile of pressure,
Temp. Salinity)
not a trajectory in x,y,z,t and I have put :featureType = profile as
recommended in the global
attributes section. As Roy has mentioned to Jim CTD data is usually processed
and QC'ed

Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6

[Lowry, Roy K.]

Hello again,

It has been pointed out to me that in the current SeaDataNet format 
specification (written and updated by me!) that the initial position of 
insisting upon depth for the z co-ordinate was relaxed to allow either pressure 
or depth. So, I guess we need to be relaxed and leave z co-ordinate 
harmonisation to the the application tools.

Yet another 'senior moment'..

Cheers, Roy.


From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On 
Behalf Of Lowry, Roy K. [r...@bodc.ac.uk]
Sent: 03 April 2012 06:46
To: andrew walsh
Cc: cf-metadata@cgd.ucar.edu; sdn2-t...@seadatanet.org; g...@metoc.gov.au; Luke 
Callcut; Upendra Dadi
Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6

Hi again,

The reason that I prefer depth to pressure as the dimension for CTD is that the 
information required for pressure to depth conversion is virtually always 
present in the CTD data.  However, in other oceanographic profiles - say 
nutrient bottle data - it is quite possible to have depth present without 
temperature and salinity, making the conversion to pressure impossible.  
Calculating depth from pressure at the time of standardised formatting of CTD 
data is as you say is trivial.  So, why not make the CTD data more compatible 
with bottle data for very little cost?

SeaDataNet already mandate inclusion of depth in their other data formats for 
CTD data delivery and so I can't see them switching to pressure for the 
dimension in NetCDF.

Cheers, Roy.


From: andrew walsh [awa...@metoc.gov.au]
Sent: 03 April 2012 06:15
To: Lowry, Roy K.
Cc: Jim Biard; Upendra Dadi; cf-metadata@cgd.ucar.edu; Luke Callcut; 
g...@metoc.gov.au; sdn2-t...@seadatanet.org
Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6

Hi Roy/All,

Agree totally it would be good to get this CTD netCDF done in an interoperable
way.

Regarding having pressure vs. depth. We liked to use pressure because:

1) It is the thing that is measured, let us store just that and calculate depth
if needed.

2) Depth can later be easily be calculated on the fly
using the 'Pressure to Depth' algorithm in  UNESCO (1983) Techinical
Papers in Marine Science 44, Algorithms for Computation of fundamental
properties
of Seawater. One can use the python seawater library (see
http://packages.python.org/seawater/ )
and seawater.csiro.depth(p, lat) to get depth from pressure and
seawater.csiro.pres(depth, lat)
to get pressure from depth.

3) I noted that the ARGO project (1's CTD like profiles) and others like
CSIRO Oceanography in Aust. make data available with just pressure.

4) It makes our processing and QC a whole lot simpler. We don't
have to worry about calculating and managing the extra 'depth' variable.

Is  there any problem with having the pressure as a co-ordinate which isn't
really a dimensional
quantity like depth (z) in the 4-D sense i.e x,y,z,t ?

However I note that pressure (decibar) is allowed as a vertical axis e.g see
section
4.3. Vertical (Height or Depth) Coordinate of CF v1.6 conventions document which
says:

A vertical coordinate will be identifiable by:

. units of pressure; or
. the presence of the positive attribute with a value of up or down (case
insensitive).


AND

section 4.3.1. Dimensional Vertical Coordinate which says:

The units attribute for dimensional coordinates will be a string formatted as
per the udunits.dat3 file. The
acceptable units for vertical (depth or height) coordinate variables are:

. units of pressure as listed in the file udunits.dat. For vertical axes the
most commonly used of these include
include bar, millibar, decibar, atmosphere (atm), pascal (Pa), and hPa.
...
...¶


Regards,

Andrew

- Original Message -
From: Lowry, Roy K.
To: andrew walsh
Cc: Jim Biard ; Upendra Dadi ; cf-metadata@cgd.ucar.edu ; Luke Callcut ;
g...@metoc.gov.au ; sdn2-t...@seadatanet.org
Sent: Tuesday, April 03, 2012 2:16 PM
Subject: RE: [CF-metadata] Ocean CTD data following CF Conventions v1.6


Hi Andrew,

SeaDataNet will very soon be considering how it is going to encode data,
including single CTD casts, in CF-compliant NetCDF and so I think the time is
ripe for agreeing how the significant numbers of us who indulge in this practice
for whatever reason do it.  That way we'll end up with interoperable data.

I think there are a number of people on this list who have already encoded
single CTDs into NetCDF and so it would be useful to start by asking for
descriptions (like Andrew's examples) of how this has been done and what tools
are dependent upon that encoding.

The z co-ordinate parameter (pressure/depth) is also an issue worth resolving.
Whilst interconversions are relatively straightforward, agreement would make
life much easier.  My preference leans dowards having depth as the dimension
with pressure as an optional variable. That way we interoperate with other kinds

Re: [CF-metadata] Quality flag values for missing data

[Lowry, Roy K.]

Hi Randy,

The practice recommended for SeaDataNet is to specify a fill value for the flag 
that is defined in the flag convention as 'missing value'.  I always feel more 
comfortable with explicit semantics.

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Randy Horne 
[rho...@excaliburlabs.com]
Sent: 23 August 2012 19:37
To: cf-metadata@cgd.ucar.edu
Cc: aschu...@harris.com; rhorn...@harris.com; ekenn...@aer.com
Subject: [CF-metadata] Quality flag values for missing data

What is the “generally accepted” approach for how a specific quality flag value 
should be assigned for a corresponding data value (in the corresponding data 
variable) that has a _FillValue ?

Is it sufficient that, because the data variable value is _FillValue, the 
corresponding quality flag value can be undefined ?



..End of Message ...--





___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] example of sea_surface_wave_directional_variance_spectral_density

[Lowry, Roy K.]

Hi Ellyn,

Encoding wave spectra in a CF-compliant manner is an issue that I plan to 
address on behalf of SeaDataNet in the next month or so.  The point I'd reached 
in thinking this through was to use the timeSeriesProfile feature type with 
frequency as the z co-ordinate.  I think this OK, but if not I'm sure somebody 
on this list will shout.

I prefer single-value vectors rather to scalars because it opens the way to 
packaging multiple instances into a single NetCDF file.

Cheers, Roy.  

-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ellyn 
Montgomery
Sent: 28 August 2012 15:04
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] example of 
sea_surface_wave_directional_variance_spectral_density

Hello folks-

We want our wave data observations to be CF compliant, with the 
dimensions and representation of time correct.  I believe the data we 
collect fits somewhere under Discrete Samples, since we end up with a 
time series of wave spectra from our stationary, bottom-mounted acoustic 
instruments.  I couldn't find how the file might look in the 1.6 
conventions document or appendices, so could someone please direct me to 
an example dataset that includes some wave spectra?  Help with which 
featureType should be used would also be appreciated.

The Standard Name table says the dimension order should be 
S(t,x,y,f,theta).  Since our data is from a point observation (lat and 
lon are size (1)), can the X,Y dimensions be dropped, or are they needed 
as place-holders?

Thanks very much for the help!
Ellyn

-- 
Ellyn T. Montgomery, Oceanographer and Data Manager
U.S. Geological Survey
Woods Hole Coastal and Marine Science Center
384 Woods Hole Road, Woods Hole, MA 02543-1598
(508)457-2356

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] example of sea_surface_wave_directional_variance_spectral_density

[Lowry, Roy K.]

Hi again,

Within BODC, we address your concerns by having a much richer set of feature 
types that include concepts like timeSeriesSpectrum to indicate that the z-axis 
is non-spatial and so give display clients a bit more help.  However, I think 
that with the right parameter attribute semantic information and the CF feature 
types we should be OK in SeaDataNet.

My thinking so far has been confined to non-directional spectra.  I can't see 
how directional spectra could be handled in CF without specification of an 
additional feature type, but (not for the first time) I might be 
misunderstanding something in John's view of feature types.

Cheers, Roy. 

-Original Message-
From: Ellyn Montgomery [mailto:emontgom...@usgs.gov] 
Sent: 29 August 2012 15:47
To: Lowry, Roy K.
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] example of 
sea_surface_wave_directional_variance_spectral_density

Roy-
I'm glad that it's on your plate!

Conceptually, I am a bit uncomfortable with having frequency as Z since 
many of us think of Z as depth/altitude.  Having frequency as Z fits the 
shapes allowed, but I wonder what confusion it would start.  Are there 
ways for clients to identify Z as a non-depth content?  Is it as simple 
as calling the Z coordinate frequency instead of depth, and then 
clients would be able to know what to do?

Then of course the direction component would need to be wedged into the 
coordinate system somehow.  Such fun!

Looking forward to the discussion!
Ellyn


On 08/29/2012 09:54 AM, Lowry, Roy K. wrote:
 Hi Ellyn,

 Encoding wave spectra in a CF-compliant manner is an issue that I plan to 
 address on behalf of SeaDataNet in the next month or so.  The point I'd 
 reached in thinking this through was to use the timeSeriesProfile feature 
 type with frequency as the z co-ordinate.  I think this OK, but if not I'm 
 sure somebody on this list will shout.

 I prefer single-value vectors rather to scalars because it opens the way to 
 packaging multiple instances into a single NetCDF file.

 Cheers, Roy.

 -Original Message-
 From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
 Ellyn Montgomery
 Sent: 28 August 2012 15:04
 To: cf-metadata@cgd.ucar.edu
 Subject: [CF-metadata] example of 
 sea_surface_wave_directional_variance_spectral_density

 Hello folks-

 We want our wave data observations to be CF compliant, with the
 dimensions and representation of time correct.  I believe the data we
 collect fits somewhere under Discrete Samples, since we end up with a
 time series of wave spectra from our stationary, bottom-mounted acoustic
 instruments.  I couldn't find how the file might look in the 1.6
 conventions document or appendices, so could someone please direct me to
 an example dataset that includes some wave spectra?  Help with which
 featureType should be used would also be appreciated.

 The Standard Name table says the dimension order should be
 S(t,x,y,f,theta).  Since our data is from a point observation (lat and
 lon are size (1)), can the X,Y dimensions be dropped, or are they needed
 as place-holders?

 Thanks very much for the help!
 Ellyn



-- 
Ellyn T. Montgomery, Oceanographer and Data Manager
U.S. Geological Survey
Woods Hole Coastal and Marine Science Center
384 Woods Hole Road, Woods Hole, MA 02543-1598
(508)457-2356

-- 
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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] example of sea_surface_wave_directional_variance_spectral_density

[Lowry, Roy K.]

Hi Richard,

I had a feeling it might.  The reason I've got frequency and profile depth 
linked together in my mind is because of the structural similarity between 
plots of moored ADCP data and 1D wave spectra (just a change of axis label).

Cheers, Roy.

-Original Message-
From: Hattersley, Richard [mailto:richard.hatters...@metoffice.gov.uk] 
Sent: 30 August 2012 16:52
To: Lowry, Roy K.; Ellyn Montgomery
Cc: cf-metadata@cgd.ucar.edu
Subject: RE: [CF-metadata] example of 
sea_surface_wave_directional_variance_spectral_density

Hi Roy,

There are some fairly explicit statements in chapter 9 that mean
treating 'z' as frequency would break the convention.

From 9.1:
profile = an ordered set of data points along a vertical line
...

The spatial coordinate z refers to vertical position.

And it's not clear that you could add an additional dimension for the
frequency. (That said, it's also not completely clear that you
shouldn't.)

Looks like CF would benefit from your BODC feature types.

Regards,

Richard Hattersley  AVD  Iris Technical Lead
Met Office  FitzRoy Road  Exeter  Devon  EX1 3PB  United Kingdom
Tel: +44 (0)1392 885702  Fax: +44 (0)1392 885681
Email: richard.hatters...@metoffice.gov.uk  Website:
www.metoffice.gov.uk
 

 -Original Message-
 From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] 
 On Behalf Of Lowry, Roy K.
 Sent: 29 August 2012 16:26
 To: Ellyn Montgomery
 Cc: cf-metadata@cgd.ucar.edu
 Subject: Re: [CF-metadata] example of 
 sea_surface_wave_directional_variance_spectral_density
 
 Hi again,
 
 Within BODC, we address your concerns by having a much richer 
 set of feature types that include concepts like 
 timeSeriesSpectrum to indicate that the z-axis is non-spatial 
 and so give display clients a bit more help.  However, I 
 think that with the right parameter attribute semantic 
 information and the CF feature types we should be OK in SeaDataNet.
 
 My thinking so far has been confined to non-directional 
 spectra.  I can't see how directional spectra could be 
 handled in CF without specification of an additional feature 
 type, but (not for the first time) I might be 
 misunderstanding something in John's view of feature types.
 
 Cheers, Roy. 
 
 -Original Message-
 From: Ellyn Montgomery [mailto:emontgom...@usgs.gov] 
 Sent: 29 August 2012 15:47
 To: Lowry, Roy K.
 Cc: cf-metadata@cgd.ucar.edu
 Subject: Re: [CF-metadata] example of 
 sea_surface_wave_directional_variance_spectral_density
 
 Roy-
 I'm glad that it's on your plate!
 
 Conceptually, I am a bit uncomfortable with having frequency 
 as Z since 
 many of us think of Z as depth/altitude.  Having frequency as 
 Z fits the 
 shapes allowed, but I wonder what confusion it would start.  
 Are there 
 ways for clients to identify Z as a non-depth content?  Is it 
 as simple 
 as calling the Z coordinate frequency instead of depth, and then 
 clients would be able to know what to do?
 
 Then of course the direction component would need to be 
 wedged into the 
 coordinate system somehow.  Such fun!
 
 Looking forward to the discussion!
 Ellyn
 
 
 On 08/29/2012 09:54 AM, Lowry, Roy K. wrote:
  Hi Ellyn,
 
  Encoding wave spectra in a CF-compliant manner is an issue 
 that I plan to address on behalf of SeaDataNet in the next 
 month or so.  The point I'd reached in thinking this through 
 was to use the timeSeriesProfile feature type with frequency 
 as the z co-ordinate.  I think this OK, but if not I'm sure 
 somebody on this list will shout.
 
  I prefer single-value vectors rather to scalars because it 
 opens the way to packaging multiple instances into a single 
 NetCDF file.
 
  Cheers, Roy.
 
  -Original Message-
  From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] 
 On Behalf Of Ellyn Montgomery
  Sent: 28 August 2012 15:04
  To: cf-metadata@cgd.ucar.edu
  Subject: [CF-metadata] example of 
 sea_surface_wave_directional_variance_spectral_density
 
  Hello folks-
 
  We want our wave data observations to be CF compliant, with the
  dimensions and representation of time correct.  I believe 
 the data we
  collect fits somewhere under Discrete Samples, since we end 
 up with a
  time series of wave spectra from our stationary, 
 bottom-mounted acoustic
  instruments.  I couldn't find how the file might look in the 1.6
  conventions document or appendices, so could someone please 
 direct me to
  an example dataset that includes some wave spectra?  Help with which
  featureType should be used would also be appreciated.
 
  The Standard Name table says the dimension order should be
  S(t,x,y,f,theta).  Since our data is from a point 
 observation (lat and
  lon are size (1)), can the X,Y dimensions be dropped, or 
 are they needed
  as place-holders?
 
  Thanks very much for the help!
  Ellyn
 
 
 
 -- 
 Ellyn T. Montgomery, Oceanographer and Data Manager
 U.S. Geological Survey
 Woods Hole Coastal and Marine Science Center
 384 Woods Hole Road, Woods Hole

Re: [CF-metadata] Proposal for standard name snow_cover_binary_mask

[Lowry, Roy K.]

Dear All,

It's becoming clear that we need a Standard Name component to cover boolean 
values whose trigger point may then be specified elsewhere as Jonathan stated.  
In the biological domain, the syntax 'presence_of_x' where x is a taxon name is 
often used.  Could this be adopted giving the Standard Name 
'presence_of_surface_snow' for Jim and opening the door for a raft of Standard 
Names to cover Ute's use case?

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ute Brönner 
[ute.broen...@sintef.no]
Sent: 05 September 2012 18:40
To: Jim Biard
Cc: Heather Brown; Raymond Nepstad; cf-metadata@cgd.ucar.edu; Alisa Young
Subject: Re: [CF-metadata] Proposal for standard name snow_cover_binary_mask

Hei,
Wouldn't that feature come in handy for other grids as well where we would like 
to mark sth. like exposed or not exposed? So I would suggest to make it 
snow independent.

Regards,
Ute


Am 05.09.2012 um 18:31 schrieb Jim Biard 
jim.bi...@noaa.govmailto:jim.bi...@noaa.gov:

Hi.

I'd like to propose the new standard name snow_cover_binary_mask.  There is a 
NOAA snow coverage extent product that is being put into netCDF format.  The 
product is derived from the IMS Daily Northern Hemisphere Snow  Ice Analysis.  
It is a grid in which cells are marked as snow-covered or not snow-covered.  
The GCMD already has the keywords Cryosphere  Snow/Ice  Snow Cover and 
Terrestrial Hydrosphere  Snow/Ice  Snow Cover, which are applied to the 
source product.

In this particular product, grid cells are marked as snow-covered when  42% of 
the cell indicates the presence of snow.

I'd appreciate any thoughts or comments.

Grace and peace,

Jim

Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites
Remote Sensing and Applications Division
National Climatic Data Center
151 Patton Ave, Asheville, NC 28801-5001

jim.bi...@noaa.govmailto:jim.bi...@noaa.gov
828-271-4900

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edumailto:CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Proposal for standard name snow_cover_binary_mask

[Lowry, Roy K.]

Suggestion 'presence_of_surface_snow' should have been 
'presence_of_surface_snow_cover' to maintain consistency

From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K. 
[r...@bodc.ac.uk]
Sent: 05 September 2012 19:49
To: Ute Brönner; Jim Biard
Cc: Heather Brown; Raymond Nepstad; cf-metadata@cgd.ucar.edu; Alisa Young
Subject: Re: [CF-metadata] Proposal for standard name snow_cover_binary_mask

Dear All,

It's becoming clear that we need a Standard Name component to cover boolean 
values whose trigger point may then be specified elsewhere as Jonathan stated.  
In the biological domain, the syntax 'presence_of_x' where x is a taxon name is 
often used.  Could this be adopted giving the Standard Name 
'presence_of_surface_snow' for Jim and opening the door for a raft of Standard 
Names to cover Ute's use case?

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ute Brönner 
[ute.broen...@sintef.no]
Sent: 05 September 2012 18:40
To: Jim Biard
Cc: Heather Brown; Raymond Nepstad; cf-metadata@cgd.ucar.edu; Alisa Young
Subject: Re: [CF-metadata] Proposal for standard name snow_cover_binary_mask

Hei,
Wouldn't that feature come in handy for other grids as well where we would like 
to mark sth. like exposed or not exposed? So I would suggest to make it 
snow independent.

Regards,
Ute


Am 05.09.2012 um 18:31 schrieb Jim Biard 
jim.bi...@noaa.govmailto:jim.bi...@noaa.gov:

Hi.

I'd like to propose the new standard name snow_cover_binary_mask.  There is a 
NOAA snow coverage extent product that is being put into netCDF format.  The 
product is derived from the IMS Daily Northern Hemisphere Snow  Ice Analysis.  
It is a grid in which cells are marked as snow-covered or not snow-covered.  
The GCMD already has the keywords Cryosphere  Snow/Ice  Snow Cover and 
Terrestrial Hydrosphere  Snow/Ice  Snow Cover, which are applied to the 
source product.

In this particular product, grid cells are marked as snow-covered when  42% of 
the cell indicates the presence of snow.

I'd appreciate any thoughts or comments.

Grace and peace,

Jim

Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites
Remote Sensing and Applications Division
National Climatic Data Center
151 Patton Ave, Asheville, NC 28801-5001

jim.bi...@noaa.govmailto:jim.bi...@noaa.gov
828-271-4900

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edumailto:CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Standard Name Serving

[Lowry, Roy K.]

Dear All,

Up until now, addressing of CF Standard Names through the NERC Vocabulary 
Server has been through opaque identifiers such as 'P07' and 'CFV8N1'.  In 
response to requests for addressing through semantically meaningful URLs we 
have introduced a system of alternative URLs using the following conventions:



To obtain a SKOS document containing a description and mappings for a given 
Standard Name use the syntax:

- http://vocab.nerc.ac.uk/standard_name/{version}/{standard_name}

 {version} can be short-circuited to current, e.g.

- http://vocab.nerc.ac.uk/standard_name/current/aerosol_angstrom_exponent/

The full Standard Names list can be accessed by 
http://vocab.nerc.ac.uk/standard_name/



Note that the URNs are unchanged and that the URLs based on opaque identifiers 
are still valid and will continue to be supported by the vocabulary server.



Regards, Roy.

-- 
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.___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] FW: CF Names vocabulary

[Lowry, Roy K.]

Dear All,

Those interested in developing the semantics of Standard Names might like to 
know about the following work.

I've directed Michael at how to join this list.

Cheers, Roy.

-Original Message-
From: Michael Piasecki [mailto:mpiase...@ccny.cuny.edu] 
Sent: 18 September 2012 21:37
To: Ben Domenico
Cc: caru...@mbari.org; nat...@imaa.cnr.it; Leadbetter, Adam; 
jgrayb...@ucsd.edu; lbermu...@opengeospatial.org; Lowry, Roy K.
Subject: Re: CF Names vocabulary

Hello All (those who I know Ben, Luiz, Stefan, John) and those who I do not 
know (Carlos Adam)

I am at the UNIDATA pol committee meeting in Boulder and had a chance to talk 
to Ben about the nectcdf CF work that is ongoing also in the context of OGC.

As a result he forwarded to me the email trail that originated on Sept 6th, 
which I read with much interest. In part because we at CCNY have been working 
on ... well yes, netcdf CF ontologizing. 

Just a short summary: we are trying to use the underlying grammar of the name 
conventions to identify a structure that is deeper and more multi layered than 
the narrowerThan. I think this is what SImon asked for, and I wholeheartedly 
support this: there certainly is more structure to the naming conventions than 
a flat one level construct with only a single layer of narrowerThan. 

We are also trying to figure out a way to restructure the underying structure 
to sort it along likely facets by which you most likely want to search. While 
putting this in OWL, we are also try to SKOSysize it, the latter with the 
desire to have an environment in which we can start building cross walks to 
other CVs such as in CUAHSI HIS or SRS (EPA and USGS). 

As I am trying to better understand what the conversation is about, I looks to 
me as if this could be of interest.

Michael 

-- 
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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Another potentially useful extension to the standard_name table

[Lowry, Roy K.]

Hello Philip/John,

As John might remember, I attempted this approach a while back (I think I 
started in 2004) on another parameter vocabulary (the BODC vocabulary 
subsequently adopted by SeaDataNet).  I have yet to succeed in implementing it 
operationally.  This was because of two issues:

1) I never managed to derive a single model that described all the parameters 
in the dictionary - things like 'Concentration of PCB118 per unit wet weight of 
Mytilus edulis flesh' were particularly troublesome.
2) I simply ran out of energy building some of the vocabularies and never 
completed them

Admittedly, the problem was on a different scale - the vocab I was working on 
is ten times the size of the Standard Names list with a lot of biology in it. 
Further there are now standard resources available - such as WoRMS for taxon 
names that weren't mature then.  This brings me to the point that any 
development of grammar element vocabularies in CF should not be done in 
isolation, but should be sure to incorporate resources such as WoRMS for taxa, 
EEA for atmospheric pollutants and CAS for organic molecules.

However, there are other grammar-related vocabularies in CF such as the words 
used to express the amount of something in a matrix that should be in 
vocabularies that are totally under CF governance.  I totally agree that 
establishing these based on Jonathan's grammar would be a valuable step forward 
and would be happy to help do this.  This would be even more valuable if done 
in a collaborative manner that allowed a Standards Name List to be built from 
distributed semantic elements - or even interoperable semantic elements (nudge 
nudge wink wink!!).

As Philip suggests, an ideal kick-off for this process would be for Jonathan to 
prepare a grammar for the recently published Version 20 of Standard Names list 
and this time let's see if those of us in CF interested in parameter semantics 
can give his work the development it deserves.

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Graybeal 
[jgrayb...@ucsd.edu]
Sent: 22 September 2012 00:09
To: Cameron-smith, Philip
Cc: cf-metadata@cgd.ucar.edu; Jonathan Gregory
Subject: Re: [CF-metadata] Another potentially useful extension to the  
standard_name table

I like this.

I may be a step behind, but given a grammar parser/generator, we will have 
identified the slots. But we will not have identified all the terms that can 
fill those slots.

I don't think this is a huge challenge.  We will have (a) a list of terms 
already filling those slots, (b) candidate vocabularies that we could mine -- 
or designate -- or create -- to supply additional terms.  I would be delighted 
to participate in construction the list of terms and vocabularies.  (Especially 
if you let me use MMI to store them. Wink wink nudge nudge. :-)

Anyway, please correct me if I'm missing the boat, or tell me if there's 
already a plan.

John

On Sep 21, 2012, at 15:52, Cameron-smith, Philip wrote:

 Hi All,

 I am just catching up on the backlog of CF emails.  My sense too is that this 
 discussion is trying to solve the problems caused by a lack of grammar with 
 alternatives and/or stopgaps.  My preference is to overcome the grammar/vocab 
 challenge, but I am well aware that an accepted solution has not yet occurred.

 In order to get us on the right track, I propose we take advantage of 
 Jonathan's suggestion in a way that doesn't require a full grammar/vocab 
 definition, and doesn't require any changes to the controlling CF documents.

 Specifically, I propose the following:

 1) We leverage Jonathan's grammar program into (a) a program that checks a 
 proposed std_name by parsing it to see whether it fits existing grammar/vocab 
 rules, and/or (b) a std_name generation program.

 2) Std_names are still proposed in the ordinary way, but if they have passed 
 the checker or been created through the generator then it will be easy for 
 people to accept them.  We might even move to a mode in which pre-approved 
 std_names are automatically accepted after a month, unless someone objects.

 This has several advantages:

 A) It will reduce time and effort by everyone to get std_names approved.
 B) Neither the parser nor the generator needs to be complete (ie, it is OK if 
 some existing names don't comply, or there are some valid new cases they 
 don't cover)
 C) Proposals that don't fit the standard construction can still be approved, 
 and will highlight ways to complete and extend the parser/generator.
 D) Any mistakes by the parser/generator should be caught by the email list.

 I see no disadvantages other than the need for someone to create the parser 
 and/or generator, which should be technically straightforward.

 Best wishes,

   Philip

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata-- 

Re: [CF-metadata] Another potentially useful extension to the standard_name table

[Lowry, Roy K.]

Hello Martin,

I understand exactly what you want - or at least I thing I do.  I think that 
you would like to enter a URL representing the concept 'carbon monoxide' and 
get back a document giving you all the Standard Names pertaining to carbon 
monoxide.  Am I right?

My vision - which I'm pretty sure John Graybeal shares - is of a grammar in 
which each element is populated from a controlled vocabulary comprising 
concepts that are included in a thesaurus or more likely a full-blown ontology.

Does that sound like what you need?

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz, 
Martin [m.schu...@fz-juelich.de]
Sent: 22 September 2012 16:26
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Another potentially useful extension to the 
standard_name table

Dear Philip, John and others,

  I take the point that indeed a grammar approach would be the solution to 
my problem. However, the grammar as it once stood based on Jonathan's python 
program (which indeed works quite nicely) unfortunately doesn't help with 
respect to the problem that I intended to solve with the addition of 
attribute tags (specifically compound). The problem is that the current 
grammar, derived from parsing the standard_name table, does not take into 
account semantic relations, but is strictly rule-based. Although I am not able 
to prove this now, the experience I gathered with Jonathan's tool and the 
associated lexicon suggests that it would require a major overhaul of the 
standard_name table in order to make it parseable in a sense that the 
relations among terms are not mere (computer) rule constructs, but make sense 
for the human reader. In essence, this is why I opened track ticket #91. 
Unfortunately, I haven't found the time yet to take this any further. ..

Personally, I am much less worried about the procedures for suggesting and 
accepting standard_names. I fully agree that a grammar-based approach would 
also help in this regard, but that is a different issue.

If I were in charge of creating a new standard_name table from scratch, I 
would go for a rigorous grammar-based syntax, where (sorry to bring this up 
again) the standard_name for air_temperature would be temperature_of_air in 
order to identify the relation propertofmedium, etc. Indeed, in this 
hypothetical standard_name table, one would define aliases and give them a more 
prominent role than now, i.e. it would be fine to use air_temperature 
(aliases should not be considered deprecated as is often the case in the 
current table). The interoperable application could then look up the real 
standard_name behind the alias and find something that can indeed be parsed - 
eh voila: you get what you need, i.e. you will know that you have a property 
and a medium, and that the property is temperature and the medium is air.

Of course, I am not in charge if creating a new standard_name table (and I 
am sure no one would like me to be in charge ;-), but I hope this illustrates 
the problem we have with the current table. Sad as it seems, I really see only 
two options: A) if most people agree that a grammar-based approach is the way 
to go, then we need to start overhauling the standard_name table (track ticket 
#91) and slowly transform it into something that makes sense (please don't 
misunderstand this phrase!). Option B): we leave things as they are, but then 
we would indeed have to further discuss the attribute idea, because this 
would provide a way of interpreting standard_names without having to parse them 
(which, as I hope to have made clear, is impossible at present).

  I agree with the precautions that were raised in that the attributes 
pose some danger of becoming uncontrolled and simply too many. However, perhaps 
it is not so bad, because the standard_names usually consist of no more than 6 
lexical tokens, and if we could agree that there should be not more than one 
attribute per lexical token (and these would anyhow be optional), then it 
appears manageable and finite.

With somewhat Quichotte'sque feelings,

Martin






Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unsere app? http://www.fz-juelich.de/app

Re: [CF-metadata] Another potentially useful extension to the standard_name table

[Lowry, Roy K.]

Hello Jonathan,

I'm finding myself in total agreement with you and hope to start demonstrate 
over the coming weeks how vocabulary server technology can cover both Martin's 
use case and the use case for whic you did your work.

Cheers, Roy.


From: Jonathan Gregory [j.m.greg...@reading.ac.uk]
Sent: 24 September 2012 17:53
To: Schultz, Martin
Cc: Lowry, Roy K.; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Another potentially useful extension to the 
standard_name table

Dear Martin, Roy et al.

 I understand exactly what you want - or at least I thing I do.  I think that 
 you would like to enter a URL representing the concept 'carbon monoxide' and 
 get back a document giving you all the Standard Names pertaining to carbon 
 monoxide.  Am I right?

I appreciate that this need is not the same one as a system for proposing
new standard names, on which I agree with the way Philip described it. But
couldn't both needs be served by a generating grammar? If we have a complete
grammar of standard_names, then we can record in the standard_name table how
each one is generated from phrases, as well as the final result. Although you
cannot always parse a standard_name unambiguously, you could look up what the
correct decomposition was, or search the table for the occurrence of a
particular species or other phrase in the decompositions.

Later we could take a step further by recognising that some names are
irregular and giving their decomposition in regular terms. Thus, for instance,
specific_humidity could be recognised as composed of the semantic elements
which would normally yield mass_fraction_of_water_vapor_in_air (which does not
occur in fact). This is somewhat like Martin's idea of aliases for irregular
names. It is like recognising that went = go + -ed. Of course, there is
plenty of linguistic theory about this kind of thing! My grammar does not
currently have such transformational rules.

Best wishes

Jonathan-- 
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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Another potentially useful extension to the standard_name table

[Lowry, Roy K.]

Hello Simon,

If you're referring to syntactic duplicates then providing the controlled 
vocabularies covering the grammar elements are well managed the issue is 
addressed.

If you're referring to semantic duplicates (i.e. multiple Standard Names built 
from synonyms) then no, but there are opinions that have me 75% convinced that 
these are of little consequence in a linked data environment.

Cheers, Roy.


From: simon@csiro.au [simon@csiro.au]
Sent: 24 September 2012 04:33
To: Lowry, Roy K.; jgrayb...@ucsd.edu; cameronsmi...@llnl.gov
Cc: cf-metadata@cgd.ucar.edu; j.m.greg...@reading.ac.uk
Subject: RE: [CF-metadata] Another potentially useful extension to the  
standard_name table

Sorry if this is an ignorant/newbie question, but can I ask if the grammar for 
CF std_names implicitly provides a check on duplicates?

Simon

-Original Message-
From: Lowry, Roy K. [mailto:r...@bodc.ac.uk]
Sent: Saturday, 22 September 2012 4:27 PM
To: John Graybeal; Cameron-smith, Philip
Cc: cf-metadata@cgd.ucar.edu; Jonathan Gregory; Cox, Simon (CESRE, Kensington)
Subject: RE: [CF-metadata] Another potentially useful extension to the 
standard_name table

Hello Philip/John,

As John might remember, I attempted this approach a while back (I think I 
started in 2004) on another parameter vocabulary (the BODC vocabulary 
subsequently adopted by SeaDataNet).  I have yet to succeed in implementing it 
operationally.  This was because of two issues:

1) I never managed to derive a single model that described all the parameters 
in the dictionary - things like 'Concentration of PCB118 per unit wet weight of 
Mytilus edulis flesh' were particularly troublesome.
2) I simply ran out of energy building some of the vocabularies and never 
completed them

Admittedly, the problem was on a different scale - the vocab I was working on 
is ten times the size of the Standard Names list with a lot of biology in it. 
Further there are now standard resources available - such as WoRMS for taxon 
names that weren't mature then.  This brings me to the point that any 
development of grammar element vocabularies in CF should not be done in 
isolation, but should be sure to incorporate resources such as WoRMS for taxa, 
EEA for atmospheric pollutants and CAS for organic molecules.

However, there are other grammar-related vocabularies in CF such as the words 
used to express the amount of something in a matrix that should be in 
vocabularies that are totally under CF governance.  I totally agree that 
establishing these based on Jonathan's grammar would be a valuable step forward 
and would be happy to help do this.  This would be even more valuable if done 
in a collaborative manner that allowed a Standards Name List to be built from 
distributed semantic elements - or even interoperable semantic elements (nudge 
nudge wink wink!!).

As Philip suggests, an ideal kick-off for this process would be for Jonathan to 
prepare a grammar for the recently published Version 20 of Standard Names list 
and this time let's see if those of us in CF interested in parameter semantics 
can give his work the development it deserves.

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Graybeal 
[jgrayb...@ucsd.edu]
Sent: 22 September 2012 00:09
To: Cameron-smith, Philip
Cc: cf-metadata@cgd.ucar.edu; Jonathan Gregory
Subject: Re: [CF-metadata] Another potentially useful extension to the  
standard_name table

I like this.

I may be a step behind, but given a grammar parser/generator, we will have 
identified the slots. But we will not have identified all the terms that can 
fill those slots.

I don't think this is a huge challenge.  We will have (a) a list of terms 
already filling those slots, (b) candidate vocabularies that we could mine -- 
or designate -- or create -- to supply additional terms.  I would be delighted 
to participate in construction the list of terms and vocabularies.  (Especially 
if you let me use MMI to store them. Wink wink nudge nudge. :-)

Anyway, please correct me if I'm missing the boat, or tell me if there's 
already a plan.

John

On Sep 21, 2012, at 15:52, Cameron-smith, Philip wrote:

 Hi All,

 I am just catching up on the backlog of CF emails.  My sense too is that this 
 discussion is trying to solve the problems caused by a lack of grammar with 
 alternatives and/or stopgaps.  My preference is to overcome the grammar/vocab 
 challenge, but I am well aware that an accepted solution has not yet occurred.

 In order to get us on the right track, I propose we take advantage of 
 Jonathan's suggestion in a way that doesn't require a full grammar/vocab 
 definition, and doesn't require any changes to the controlling CF documents.

 Specifically, I propose the following:

 1) We leverage Jonathan's grammar program into (a) a program that checks a 
 proposed std_name by parsing it to see whether it fits

[CF-metadata] Extensions to the Standard Name table

[Lowry, Roy K.]

Dear All,

Martin Schultz was proposing an extension to the Standard Name table to provide 
a means of easily identifying the Standard Names associated with a given 
atmospheric contaminant.  What follows provides an alternative way to address 
his use case.  Go to the URL http://vocab.nerc.ac.uk/sparql/ and copy the 
SPARQL query at the end of this message into the box, choose your output format 
and press 'Get Results'. If you don't want 'carbon monoxide' simply replace 
'Carbon monoxide' by another valid EEA contaminant name.

For the techies on the list, this is done by a federated SPARQL query involving 
SPARQL endpoints on vocabulary servers at BODC and the EEA. This is based on 
string matching, but could be made more robust by implementing an EEA/Standard 
Names mapping in NVS should this be requested by the CF community.

Cheers, Roy.


PREFIX skos: http://www.w3.org/2004/02/skos/core#
PREFIX j.0: http://rdfdata.eionet.europa.eu/airbase/schema/
PREFIX rdfs: http://www.w3.org/2000/01/rdf-schema#
SELECT ?urie ?labele ?urin ?labeln WHERE
{
  BIND(Carbon monoxide AS ?pollutant)
  SERVICEhttp://cr.eionet.europa.eu/sparql
  {
?urie skos:inScheme 
http://rdfdata.eionet.europa.eu/airquality/components/.
?urie skos:prefLabel ?labele.
?urie j.0:pollutant ?pollutant.
  }.
  http://vocab.nerc.ac.uk/collection/P07/current/ skos:member ?urin.
  ?urin skos:prefLabel ?labeln.
  ?urin skos:definition ?defn.
  FILTER CONTAINS (str(lcase(?defn)),str(lcase(?pollutant)))
}



Please note that I now work part-time from Tuesday to Thursday.  E-mail 
response on other days is possible but not guaranteed!



-- 
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.___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] new standard name proposal for total ozone in DU

[Lowry, Roy K.]

Hello Cristophe,

To be absolutely clear, I'm saying the data should be stored in the NetCDF in 
Dobson Units, that the units parameter attribute in the NetCDF file should be 
Dobson Units, but that the canonical unit in the Standard Names List and 
therefore the units mapped in our server should be moles per square metre.

Cheers, Roy.


From: Christophe Lerot [christophe.le...@aeronomie.be]
Sent: 04 December 2012 10:20
To: Lowry, Roy K.
Cc: alison.pamm...@stfc.ac.uk; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] new standard name proposal for total ozone in DU

Dear Roy,

Do you mean that the total ozone values should be given in moles per
square metre in the NetCDF files themselves? Or do you mean that I
should simply add a specific comment in the unit parameter attribute to
make clear that the values are provided in Dobson Unit?
The Dobson Unit is quite common for total ozone users and I'd prefer to
stay with this unit if possible.

Cheers,
Christophe

On 3/12/2012 15:39, Lowry, Roy K. wrote:
 Hello Alison,

 Surely the canonical unit for Dobson Units would be moles per square metre, 
 with Dobson Units appearing as the scaled unit in the units parameter 
 attribute. Making Dobson Units the canonical unit would be like having cm/s 
 rather than m/s as a canonical unit.

 Cheers, Roy.
 
 From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
 alison.pamm...@stfc.ac.uk [alison.pamm...@stfc.ac.uk]
 Sent: 03 December 2012 14:18
 To: cf-metadata@cgd.ucar.edu
 Subject: Re: [CF-metadata] new standard name proposal for total ozone in DU

 Dear Christophe and Jonathan,

 I also support this proposal. We don't currently have any standard names that 
 use Dobson Units - I think UDUnits1 didn't support it. However, since it is 
 defined in UDunits2 I don't see any problem with adding it.

 Best wishes,
 Alison

 --
 Alison Pamment  Tel: +44 1235 778065
 NCAS/British Atmospheric Data CentreEmail: alison.pamm...@stfc.ac.uk
 STFC Rutherford Appleton Laboratory
 R25, 2.22
 Harwell Oxford, Didcot, OX11 0QX, U.K.



 -Original Message-
 From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf
 Of Jonathan Gregory
 Sent: 27 November 2012 20:52
 To: cf-metadata@cgd.ucar.edu
 Subject: [CF-metadata] new standard name proposal for total ozone in DU

 Dear Christophe

 So I'd like to propose the following variable name for total ozone
 columns based on recommendations I was given:
 - atmosphere_mole_content_of_ozone expressed in Dobson Units.
 Dobson Unit (DU) is already defined in the UDUNIT package ans is
 equivalent to 446.2 micromoles m-2.
 This seems fine to me. It is consistent in construction with existing
 names
 for a quantity in mol m-2.

 Best wishes

 Jonathan
 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
 --
 Scanned by iCritical.
 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/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.
 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

--
-
Dr. Christophe LEROT
Belgian Institute for Space Aeronomy
Chemistry  Physics of Atmospheres
Avenue circulaire, 3
1180 Brussels
Belgium
phone:  +32/(0)2-3730-407
mobile: +32/(0)472-81.87.00
mail:   christophe.le...@aeronomie.be
url:http://uv-vis.aeronomie.be/
-

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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] new standard name proposal for total ozone in DU

[Lowry, Roy K.]

Hi Alison,

A technical solution could be found, but I would be more comfortable with a 
universally understandable canonical unit that didn't enforce a particular 
scaling.

Cheers, Roy.

Please note that I now work part-time from Tuesday to Thursday.  E-mail 
response on other days is possible but not guaranteed!


-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
alison.pamm...@stfc.ac.uk
Sent: 05 December 2012 10:30
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] new standard name proposal for total ozone in DU

Dear Roy and Christophe,

As Roy says, we usually use SI units for the canonical unit in the standard 
name table. There are a few exceptions, for example, age_of_sea_ice has units 
of year and age_of_surface_snow has units of day, whereas the SI unit for both 
quantities would be the second. Also, we allowed some of the recently added 
salinity names to have canonical units of g kg-1 which I'm not sure adheres 
strictly to SI. I think the reason for having the exceptions was simply that 
they are the units that are always used with the named quantities.

For Christophe's ozone name, atmosphere_mole_content_of_ozone, the proposed 
definition is ' Content indicates a quantity per unit area. The atmosphere 
content of a quantity refers to the vertical integral from the surface to the 
top of the atmosphere. For the content between specified levels in the 
atmosphere, standard names including content_of_atmosphere_layer are used. The 
construction atmosphere_mole_content_of_X means the vertically integrated 
number of moles of X above a unit area. The chemical formula for ozone is O3.' 
Whatever we decide about the units, I think we should add the sentence 
'atmosphere_mole_content_of_ozone is usually measured in Dobson Units which are 
equivalent to 446.2 micromoles m-2'.

Roy's proposed solution of having canonical units of mol m-2 while using Dobson 
Units in the data files is certainly consistent with the CF conventions.  As 
long as UDUNITS knows how to convert the units in the file to the canonical 
units there is no problem. Christophe, would that be acceptable to the ozone 
community?

Roy, is there any technical reason why we couldn't map to Dobson Units in the 
vocabulary server if that were the preferred solution?

Best wishes,
Alison

--
Alison Pamment  Tel: +44 1235 778065
NCAS/British Atmospheric Data CentreEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.



 -Original Message-
 From: Lowry, Roy K. [mailto:r...@bodc.ac.uk]
 Sent: 04 December 2012 10:23
 To: Christophe Lerot
 Cc: Pamment, Alison (STFC,RAL,RALSP); cf-metadata@cgd.ucar.edu
 Subject: RE: [CF-metadata] new standard name proposal for total ozone
 in DU

 Hello Cristophe,

 To be absolutely clear, I'm saying the data should be stored in the
 NetCDF in Dobson Units, that the units parameter attribute in the
 NetCDF file should be Dobson Units, but that the canonical unit in the
 Standard Names List and therefore the units mapped in our server
 should be moles per square metre.

 Cheers, Roy.

 
 From: Christophe Lerot [christophe.le...@aeronomie.be]
 Sent: 04 December 2012 10:20
 To: Lowry, Roy K.
 Cc: alison.pamm...@stfc.ac.uk; cf-metadata@cgd.ucar.edu
 Subject: Re: [CF-metadata] new standard name proposal for total ozone
 in DU

 Dear Roy,

 Do you mean that the total ozone values should be given in moles per
 square metre in the NetCDF files themselves? Or do you mean that I
 should simply add a specific comment in the unit parameter attribute
 to make clear that the values are provided in Dobson Unit?
 The Dobson Unit is quite common for total ozone users and I'd prefer
 to stay with this unit if possible.

 Cheers,
 Christophe

 On 3/12/2012 15:39, Lowry, Roy K. wrote:
  Hello Alison,
 
  Surely the canonical unit for Dobson Units would be moles per square
 metre, with Dobson Units appearing as the scaled unit in the units
 parameter attribute. Making Dobson Units the canonical unit would be
 like having cm/s rather than m/s as a canonical unit.
 
  Cheers, Roy.
  
  From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of
 alison.pamm...@stfc.ac.uk [alison.pamm...@stfc.ac.uk]
  Sent: 03 December 2012 14:18
  To: cf-metadata@cgd.ucar.edu
  Subject: Re: [CF-metadata] new standard name proposal for total
  ozone in
 DU
 
  Dear Christophe and Jonathan,
 
  I also support this proposal. We don't currently have any standard
  names
 that use Dobson Units - I think UDUnits1 didn't support it. However,
 since it is defined in UDunits2 I don't see any problem with adding it.
 
  Best wishes,
  Alison
 
  --
  Alison Pamment  Tel: +44 1235 778065
  NCAS/British Atmospheric Data CentreEmail:
 alison.pamm...@stfc.ac.uk
  STFC Rutherford Appleton

[CF-metadata] sea_water_pressure

[Lowry, Roy K.]

Dear All,

It has been pointed out to me that the SeaDataNet NetCDF specification uses 
'sea_water_pressure' as the Standard Name in cases where pressure is used as 
the z co-ordinate in observational data such as CTD profiles.  The definition 
for this Standard Name is:

the pressure that exists in the medium of sea water.  It includes the pressure 
due to overlying sea water, sea ice, air and any other medium that may be 
present.

Consequently the expected pressure z co-ordinate labelled 'sea_water_pressure' 
would be approximately 10 decibars at the sea surface.  However, it is almost 
universal practice to either calibrate or correct the pressure z co-ordinate so 
that it reads zero at the sea surface.  Consequently, I think we need a new 
Standard Name:

sea_water_pressure_due_to_sea_water defined as

the pressure that exists in the medium of sea water due to overlying sea water. 
 Excludes the pressure due to sea ice, air and any other medium that may be 
present.

Apologies to anybody else who like me had used 'sea_water_pressure' for their Z 
co-ordinate without looking at the definition.

Cheers, Roy.

Please note that I now work part-time from Tuesday to Thursday.  E-mail 
response on other days is possible but not guaranteed!




  
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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] New standard name: datetime_iso8601

[Lowry, Roy K.]

Dear All,

I totally agree with Heiko's words of caution.  In my experience (over 30 years 
of oceanographic data management) duplicated information inevitably leads to 
inconsistent information.

Cheers, Roy.

Please note that I now work part-time from Tuesday to Thursday.  E-mail 
response on other days is possible but not guaranteed!


-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Heiko 
Klein
Sent: 15 January 2013 09:09
To: Aleksandar Jelenak - NOAA Affiliate
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name: datetime_iso8601

Hello Aleksandar,

I've seen some files which did such duplication, even if they haven't been 
CF-compliant. If it doesn't need to be machine-readable, you can put that 
information where-ever you want and you don't need a standard_name for that.

But I can only give a warning for duplication: The worst file I've got had the 
time in the filename, time in an attribute and time as a
coordinate-axis: None of the three matched.

Heiko

On 2013-01-15 04:54, Aleksandar Jelenak - NOAA Affiliate wrote:
 Hello Nan, Chris:

 I am not proposing that time coordinate variables can also be ISO 8601
 datetime strings. The description for this standard name clearly
 states:

 
 Variables with this standard name cannot serve as coordinate variables.
 

 I am merely proposing a standard name for those who are willing to
 spend a few more kilobytes of their CF-netCDF files on duplicating
 time data as ISO 8601 strings.

 -Aleksandar


 On Fri, Jan 11, 2013 at 4:37 PM, Chris Barker - NOAA Federal
 chris.bar...@noaa.gov wrote:
 On Fri, Jan 11, 2013 at 9:00 AM, Aleksandar Jelenak - NOAA Affiliate
 aleksandar.jele...@noaa.gov wrote:

 Here's the modified proposal for the datetime_iso8601 standard name:
 ...
 String representing date-time information according to the ISO
 8601:2004(E) standard.

 I think we should NOT adopt a string option for datetime variables.

 To quote Jonathan Gregory:

 
 In CF we have always applied the
 principle that we only add to CF when there is a need to do so, i.e.
 there is a use-case for something which cannot already be represented
 in CF 

 We already have a way to encode datetimes in CF-netcdf.

 I believe this proposal resulted from the discussion about adding a
 more flexible approach to datetimes in the CF Data Model. I think
 that's a good idea, but separate from what encoding is used in
 CF-netcdf. ( see my recent note for more detail about the difference
 between and encoding and a data model ).

 1) Having multiple ways to encode the same data in file format adds
 complication to all client code -- client code would need a way to
 process both ISO strings and time_unit since datetime

 2) Any client code that can process ISO strings is likely to need to
 convert them to a client-specific datetime representation anyway, in
 order to plot, calculate with, etc  them.

 3) Any client library that can process ISO strings is very likely to
 be able to also work with time_unit since datetime encoded data
 anyway -- and it had better, as that encoding is part of the standard
 anyway.

 As a result, we would be complicating client code, and getting no new
 functionality.

 The one advantage I can see at the moment is that simple,
 non-CF-aware clients, like ncdump, could easily present a nice
 human-readable format. But I don't think that is worth the additional 
 complication.

 -Chris
 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
Dr. Heiko Klein  Tel. + 47 22 96 32 58
Development Section / IT Department  Fax. + 47 22 69 63 55
Norwegian Meteorological Institute   http://www.met.no
P.O. Box 43 Blindern  0313 Oslo NORWAY
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Usage of the 'Conventions' attribute

[Lowry, Roy K.]

Dear All,

Currently, the 'Conventions' attribute is restricted to be a global attribute.  
There is currently a requirement to label multiple QC flag variables following 
different conventions with their source convention and having the 'Conventions' 
attribute as a variable attribute for these non-co-ordinate variables would 
seem a convenient and consistent mechanism.  Is there any support for or 
objections to this suggestion?

Cheers, Roy.

Please note that I now work part-time from Tuesday to Thursday.  E-mail 
response on other days is possible but not guaranteed!




  
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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Usage of the 'Conventions' attribute

[Lowry, Roy K.]

Hi Nan,

I am definitely NOT trying to replace the flag_values and flag_meanings 
attributes - the Conventions attribute would be in addition.  It's more formal 
acceptance of what is becoming a de facto practice that I'm after.

Cheers, Roy.

Please note that I now work part-time from Tuesday to Thursday.  E-mail 
response on other days is possible but not guaranteed!


-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Nan 
Galbraith
Sent: 23 January 2013 15:16
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Usage of the 'Conventions' attribute

Hi Roy -

As far as I know, there is nothing to prevent you from having Conventions 
attributes other than the global one.  Only the global attribute is part of CF, 
but you could certainly implement similar syntax in Conventions attributes for 
multiple variables.

Or are you looking for more of a formal acceptance of a variable- level 
Conventions attribute?

You're not proposing to replace the flag_values and flag_meanings attributes 
with this reference to an external QC flag convention, by any chance? That 
would be a difficult step.

Cheers - Nan

On 1/23/13 3:20 AM, Lowry, Roy K. wrote:
 Dear All,
 Currently, the 'Conventions' attribute is restricted to be a global
 attribute.  There is currently a requirement to label multiple QC flag
 variables following different conventions with their source convention
 and having the 'Conventions' attribute as a variable attribute for
 these non-co-ordinate variables would seem a convenient and consistent
 mechanism.  Is there any support for or objections to this suggestion?
 Cheers, Roy.
--
***
* Nan Galbraith(508) 289-2444 *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543*
***



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Usage of the 'Conventions' attribute (Nan Galbraith)

[Lowry, Roy K.]

Dear Jonathan and Martin,

What I was trying to do here was legitimise an already established practice in 
at least two communities in the observational oceanographic domain with 
thousands of files in existence with the non-standard usage of the Conventions 
attribute. I also carried the practice over into the specification of the 
SeaDataNet NetCDF generation tool. I can see absolutely no benefit in pushing 
through a new attribute for this purpose and so will circumvent the compliance 
issue for SeaDataNet by moving the variable attribute into our namespace (i.e. 
calling it SDN_Conventions). This leaves Derrick's glider community in the 
lurch, but I suggest they either follow us or follow whatever solution the 
European GROOM glider community adopts.

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.

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz, 
Martin [m.schu...@fz-juelich.de]
Sent: 24 January 2013 18:54
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Usage of the 'Conventions' attribute (Nan
Galbraith)

Dear all,

I fully agree with Jonathan's view that it would not be a good idea to call 
this new thing Convention. On the other hand, I don't really like the term 
flag_convention_name either, because it doesn't tell me anything. If I 
understand correctly, then your desire is different from defining a pointer to 
controlled vocabulary. Should it be a similar idea, then I suggest we should 
try to follow the ideas and namings of ISO19115 (without being able to tell you 
right away what the appropriate term would be). If it's cf specific and indeed 
refers to the version of a cf document (or annex or whatever), shouldn't the 
attribute then have a name that starts with cf_? E.g. cf_attribute_convention 
?

Cheers,

Martin


Message: 4
Date: Thu, 24 Jan 2013 12:23:33 +1100
From: Jonathan Gregory j.m.greg...@reading.ac.uk
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata]  Usage of the 'Conventions' attribute
Message-ID: 20130124012333.gc22...@met.reading.ac.uk
Content-Type: text/plain; charset=us-ascii

Dear Roy

I understand the need but I tend to think this would not be an appropriate
use of the Conventions attribute, which is a general netCDF attribute, not
specific to CF, and refers to files. I do appreciate the logical similarity
but I would have thought it better to define something more specific in CF
for this purpose.

If this is a need which several users have and is required for exchange of
data, then it is reasonable to propose to add something to CF. Since it's
an extra piece of information referring to flags, maybe an attribute such as
flag_convention_name would work? We could make it a requirement that this
attribute was allowed only if the variable had flag_meanings as well, to
prevent its being used as a substitute for spelling out what the flags mean
(as is necessary for the file to be self-describing).

Best wishes

Jonathan





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list

Re: [CF-metadata] Usage of the 'Conventions' attribute

[Lowry, Roy K.]

Hi Nan,

Would the CF web site be an appropriate place for communities to post the 
attributes they have added to CF - either with or without namespace prefixes?

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Nan Galbraith 
[ngalbra...@whoi.edu]
Sent: 28 January 2013 20:25
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Usage of the 'Conventions' attribute

Any of these special characters, other than the '_', would probably
cause problems for code that deals with NetCDF files. The '.' is used
in Matlab for access to structures, and the '@' is used to identify a
variable as a function handle. There are work-arounds, but they
likely wouldn't add efficiency or elegance to our code.

I agree with Roy that CF should be the default namespace in a CF
compliant file, and that this problem belongs to groups that are writing
extensions. In OceanSITES we've mostly ignored this problem-waiting-
to-happen, but our code checks the versions of CF (and our OTS spec) in
our files, which I hope offers some protection.

Should more of these community conventions be added to CF? I'm sure
there are SDN and NCADD (data discovery) attributes that would be
helpful to some CF users; it would be awfully nice to have a list of
already-defined attributes - in one place - to choose from when putting
together a CF-based spec for a project.

Cheers - Nan



On 1/28/13 1:17 PM, Dennis Heimbigner wrote:
 With respect to netcdf (at least the C version),
 it is the case that these characters can appear
 unescaped:  _.@+-

 It should be noted however that dot in particular
 causes problems for accessing remote datasets
 through DAP because the dot character is used
 in DAP constraints to specify fields inside
 DAP Sequences or Structures or Grids.

 The problem you have is that no matter what
 choice of character(s) you make, someone may
 use the characters in a different way.
 This means that whatever choice you make, you need
 to enshrine it in a standard somewhere so that at
 least there is a chance that people will avoid it.

 Personally, I would think that a two character sequence
 is least likely to be used by others, but two underscores
 is probably not a good choice. I would think something
 like @@ ++ might be a better choice.


 =Dennis Heimbigner
  Unidata
 Bentley, Philip wrote:
 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 

Re: [CF-metadata] any convention for variables abbreviation ?

[Lowry, Roy K.]

Hi Nan,

Slight misunderstanding I fear.  The p021 vocabulary is a vocabulary that MAPS 
to the CF Standard Names, but it doesn't include the Standard Names themselves. 
 What I think Nicolas is after is something slightly different, namely a 
standardised 6-byte representation for each Standard Name.  We do maintain 
opaque codes for Standard Names in our server, but unfortunately these are 8 
bytes long, not 6 so I didn't offer them.

Cheers, Roy.

From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Nan Galbraith 
[ngalbra...@whoi.edu]
Sent: 14 February 2013 13:58
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] any convention for variables abbreviation ?

SeaDataNet has standardized short names - currently 429 names, and as
far as I know all the CF terms are included.

It's available at tinyurl.com/SDNp021  The long url for the p021 list is
seadatanet.maris2.nl/v_bodc_vocab/browse.asp?order=entrykeyformname=searchscreen=0l=P021v0_0=v1_0=entrykey%2Centryterm%2Centrytermabbr%2Centrytermdef%2Centrytermlastmodv2_0=0v0_1=v1_1=entrykeyv2_1=3v0_2=v1_2=entrytermv2_2=3v0_3=v1_3=entrytermabbrv2_3=3v0_4=v1_4=entrytermlastmodv2_4=9v0_5=v1_5=entrytermlastmodv2_5=10x=49y=12v1_6=v2_6=v1_7=v2_7=
or you can just google  SeaDataNet Parameter Discovery Vocabulary

You can export the list from that page into an xml file, or search for
individual terms.

- Nan

On 2/13/13 7:28 PM, Steve Hankin wrote:
 Hi Nicolas,

 Various organizations enforce their own standards for abbreviated
 names in CF files -- OceanSites, Argo, WMO,  CF, itself, does not.

 The reason that CF does not attempt to standardize the names of
 variables (which is how the abbreviations are used in the above
 cases), is to leave open the possibility that a single file may
 contain multiple variables representing the same quantity.   For
 example, SST as measured by satellite and as measured in situ could
 potentially be in the same file.   The long_name attribute can be used
 to differentiate how multiple representations of the same variable
 were derived.

 - Steve

 ===

 On 2/13/2013 3:00 PM, Nicolas BALDECK - OpenMeteoData wrote:
 Dear,

 I'm designing a webservice for broadcasting some meteorological data.

 I will use the CF naming convention for variables names, but I also
 have to use small ( or = 6 letters) abbreviations.

 Do you have advices about that ? Is there any abbreviation convention ?

 Regards


 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
***
* Nan Galbraith(508) 289-2444 *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543*
***



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] sea_water_turbidity?

[Lowry, Roy K.]

Hello Alison,

I had been hanging back waiting for John to respond to Jonathan's comment, 
because nephelometric turbidity is a phenomenon that I've seen described - but 
not necessarily defined - in a couple of different ways.  However, whilst both 
turbidity and secchi disk depth (and attenuance to the matter) have values 
related to the SPM load in the water body, they differ markedly for a given SPM 
load and so I think a new standard name is justified.

As a prompt, I'll give one of my understandings of turbidity in NTU, which is 
'The proportion of white light scattered back to the transceiver by the 
particulate load in a body of water, represented on an arbitrary scale 
referenced against measurements made in the laboratory on aqueous suspensions 
of formazine beads.'  Before going any further we need John to either confirm 
that this is what he means or come up with an alternative.  Others might also 
have their own ideas

Cheers, Roy.

From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
alison.pamm...@stfc.ac.uk [alison.pamm...@stfc.ac.uk]
Sent: 27 February 2013 14:04
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] sea_water_turbidity?

Dear John,

Thank you for your proposal.

We currently have one existing standard name relating to turbidity of sea 
water, secchi_depth_of_sea_water, which has units of metres and is defined as 
‘Depth is the vertical distance below the surface. A Secchi disk is a patterned 
disk that is used to measure water transparency in oceans and lakes. The disk 
is lowered into the water and the depth at which the pattern is no longer 
visible is the called the secchi depth.’

I agree with Jonathan that it would be helpful if you could provide a (fairly 
brief) definition for the new name or perhaps a suitable reference.

Best wishes,
Alison

--
Alison Pamment  Tel: +44 1235 778065
NCAS/British Atmospheric Data CentreEmail: 
alison.pamm...@stfc.ac.ukmailto:j.a.pamm...@rl.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.


From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John 
Maurer
Sent: 21 February 2013 00:52
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] sea_water_turbidity?

Dear CF-Metadata,
I would propose the addition of sea_water_turbidity to the CF Standard Names. 
This has units of NTU (Nephelometric Turbidity Units), which would be 
represented in UDUNITS as 1e-3 (similar to how sea_water_salinity is in PSS 
(or PSU) and commonly represented as 1e-3).
Thanks,
John Maurer
Data System Administrator
Pacific Islands Ocean Observing System (PacIOOS)
University of Hawaii at Manoa


--
Scanned by iCritical.


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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] proposed standard names for Enterococcus and Clostridium perfringens

[Lowry, Roy K.]

Dear All,

I see Pandora's Box opening before us.  I have been down the road of setting up 
my equivalent to Standard Names (the BODC Parameter Usage Vocabulary) with 
concepts that include specification of the biological entity, which is why I 
have a vocabulary with getting on for 30,000 concepts. So I have things like 
'Abundance of species X','Carbon biomass of species X', 'Nitrogen biomass of 
species X', 'Average specimen length of species X' and so on.

In recent discussions within SeaDataNet and the EU ODIP project I have been 
persuaded that this approach is unsustainable and that what we should be aiming 
for in these projects is an approach where the Standard Name equivalent is 
something like 'Abundance of biological entity' and then have a separate 
metadata element (i.e. variable attribute) for the biological entity that 
should be related an established taxonomic standard such as WoRMS 
(http://www.marinespecies.org/).  So, which path should CF follow?

An additional point is that I would prefer not to have the semantics of what 
was measured encoded into the units of measure.  The way I've approached CFU is 
through concepts phrased like ' Abundance (colony-forming units) of Vibrio 
cholerae (WoRMS 395085) per unit volume of the water body' where colony-forming 
units is a qualifying semantic on abundance (the term I prefer to 
number_concentration, but I appreciate the precedent in existing Standard 
Names).  So, IF we choose the path of naming the beasties in the standard name 
my preferred syntax would be:

cfu_number_concentration_of enterococcus _in_sea_water with canonical units of 
m-3 as John suggested.

I have copied this response to the SeaDataNet Technical Task Team so they are 
aware that this issue is being discussed in CF.

Cheers, Roy.

Please note that I now work part-time from Tuesday to Thursday.  E-mail 
response on other days is possible but not guaranteed!

From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John 
Maurer
Sent: 21 March 2013 20:12
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] proposed standard names for Enterococcus and Clostridium 
perfringens

Aloha CF group,
I would like to propose the following standard names related to water quality 
measurements of the bacteria Enterococcus and Clostridium perfringens:

number_concentration_of_enterococcus_in_sea_water
number_concentration_of_clostridium_perfringens_in_sea_water

These are normally measured with units of CFU/100 mL, where CFU stands for 
Colony-Forming Unitshttp://en.wikipedia.org/wiki/Colony-forming_unit. I 
believe the canonical units in UDUNITS parlance would translate to m-3, which 
is what I find in the standard name table for other number_concentration_* 
quantities.

For descriptions of each, I would propose:

number_concentration_of_enterococcus_in_sea_water:

Number concentration means the number of particles or other specified objects 
per unit volume. In this context, it represents the number of colony-forming 
units (CFU) of bacteria belonging to the genus Enterococcus. This indicator 
bacteria has been correlated with the presence of human pathogens 
(disease-causing organisms) and therefore with human illnesses such as 
gastroenteritis, diarrhea, and various infections in epidemiological studies. 
As such, it is commonly measured in beach water quality monitoring programs.

number_concentration_of_clostridium_perfringens_in_sea_water:

Number concentration means the number of particles or other specified objects 
per unit volume. In this context, it represents the number of colony-forming 
units (CFU) of bacteria belonging to the species Clostridium perfringens. 
Because this bacteria is a normal component of the human intestinal tract, its 
presence in samples of sea water can be used as a tracer of sewage 
contamination. As such, it is commonly measured in beach water quality 
monitoring programs.

Thanks,
John Maurer
Pacific Islands Ocean Observing System (PacIOOS)
University of Hawaii at Manoa


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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] [sdn2-tech] RE: proposed standard names for Enterococcus and Clostridium perfringens

[Lowry, Roy K.]

 that the species entity needs to be separated from the
 ‘standard name’. I think discussions in SDN tech about the draft biological
 format for ODV would also highlight this as a ‘must have’.'

 We look forward in the discussion.

 With kind regards,
 Alessandra and Matteo

 --
 Alessandra Giorgetti
 Istituto Nazionale di Oceanografia e di Geofisica Sperimentale-OGS Sezione di
 Oceanografia - OCE National Oceanographic Data Center/IOC - NODC Borgo
 Grotta Gigante 42/c, 34010 Sgonico, Trieste (ITALY)
 Phone: +39 040 2140391
 Mobile: +39 320 4644653
 Fax: +39 040 2140266
 E-mail: agiorge...@ogs.trieste.it
 The NODC site with free data access http://nodc.ogs.trieste.it/

 Il 22/03/2013 16:15, Lowry, Roy K. ha scritto:
  Hi Klaas,
 
  What I was trying to say in my e-mail to CF was that I strongly suggest 
  that CF
 decouples the Standard Name from the species name.  However, should they
 choose not to then the cfu semantics should be removed from the units of
 measure into the Standard Name.  The example you quote is what I would
 suggest should - unfortunately in my current view - CF choose to include 
 species
 names in Standard Names.
 
  Apologies if I didn't make this clear.
 
  Cheers, Roy.
 
  
  From: Klaas Deneudt [klaas.dene...@vliz.be]
  Sent: 22 March 2013 15:06
  To: sdn2-t...@listes.seadatanet.org; 'John Maurer';
  cf-metadata@cgd.ucar.edu
  Subject: RE: [sdn2-tech] RE: [CF-metadata] proposed standard names for
  Enterococcus and Clostridium perfringens
 
  Hi, since my knowledge on standard name conventions is limited I am
  not well placed to give input on the raised request for a new item in the 
  list.
 
  However I share the concern to include the biological entity in the Standard
 Name.
  Am I wrong If I say that the suggested cfu_number_concentration_of
 enterococcus _in_sea_water seems to do just that?
 
  best regards,
  Klaas.
 
  From: sdn2-tech-requ...@listes.seadatanet.org
  [mailto:sdn2-tech-requ...@listes.seadatanet.org] On Behalf Of Neil
  Holdsworth
  Sent: 22 March 2013 11:42
  To: sdn2-t...@listes.seadatanet.org; John Maurer;
  cf-metadata@cgd.ucar.edu
  Subject: RE: [sdn2-tech] RE: [CF-metadata] proposed standard names for
  Enterococcus and Clostridium perfringens
 
  Hi Roy,
 
  First off, i thought ICES tried to persuade you way before SDN that
  this was perhaps not the right approach ;)
 
  Anyway, I would agree that the species entity needs to be separated from the
 ‘standard name’. I think discussions in SDN tech about the draft biological
 format for ODV would also highlight this as a ‘must have’.
 
  We did however struggle to understand entirely what you mean by having a
 separate metadata element related to species. What does the metadata
 element hang-off? If this was to be an attribute of the standard name, then I
 don’t really understand how this decouples the relationship. But if you mean
 that you would have a variable ‘Gadus morhua’ that had an attribute ‘aphiaID =
 xxx’ then that would be logical.
 
  Look forward to hearing what the intention is.
 
  Best, Neil
 
  From: sdn2-tech-requ...@listes.seadatanet.orgmailto:sdn2-tech-
 requ...@listes.seadatanet.org [mailto:sdn2-tech-
 requ...@listes.seadatanet.org] On Behalf Of Lowry, Roy K.
  Sent: 22. marts 2013 10:58
  To: John Maurer;
  cf-metadata@cgd.ucar.edumailto:cf-metadata@cgd.ucar.edu
  Cc:
  sdn2-t...@listes.seadatanet.orgmailto:sdn2-t...@listes.seadatanet.org
  
  Subject: [sdn2-tech] RE: [CF-metadata] proposed standard names for
  Enterococcus and Clostridium perfringens
 
  Dear All,
 
  I see Pandora's Box opening before us.  I have been down the road of setting
 up my equivalent to Standard Names (the BODC Parameter Usage Vocabulary)
 with concepts that include specification of the biological entity, which is 
 why I
 have a vocabulary with getting on for 30,000 concepts. So I have things like
 'Abundance of species X','Carbon biomass of species X', 'Nitrogen biomass of
 species X', 'Average specimen length of species X' and so on.
 
  In recent discussions within SeaDataNet and the EU ODIP project I have been
 persuaded that this approach is unsustainable and that what we should be
 aiming for in these projects is an approach where the Standard Name equivalent
 is something like 'Abundance of biological entity' and then have a separate
 metadata element (i.e. variable attribute) for the biological entity that 
 should be
 related an established taxonomic standard such as WoRMS
 (http://www.marinespecies.org/).  So, which path should CF follow?
 
  An additional point is that I would prefer not to have the semantics of what
 was measured encoded into the units of measure.  The way I've approached CFU
 is through concepts phrased like ' Abundance (colony-forming units) of Vibrio
 cholerae (WoRMS 395085) per unit volume of the water body' where colony-
 forming units is a qualifying semantic on abundance (the term I prefer

Re: [CF-metadata] [sdn2-tech] RE: proposed standard names for Enterococcus and Clostridium perfringens

[Lowry, Roy K.]

Hi John,

Which is exactly how it is in CF for 2-m air temperature or irradiance of a 
specified wavelength.  Trac ticket 96 is aimed at providing your magical 
connection and could be used for taxon names.

Ever get the feeling that some of the CF discussions (e.g. ISO8601) are a case 
of identifying the lesser of two evils by people with different opinions on 
what constitutes evil?

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Graybeal 
[grayb...@marinemetadata.org]
Sent: 22 March 2013 23:52
To: Cameron-smith, Philip
Cc: sdn2-t...@listes.seadatanet.org; Alessandra Giorgetti; 
cf-metadata@cgd.ucar.edu; Klaas Deneudt; 'John Maurer'
Subject: Re: [CF-metadata] [sdn2-tech] RE: proposed standard names for  
Enterococcus and Clostridium perfringens

I think the other obvious concern is that you could no longer use the standard 
name as the be-all and end-all of searching for comparable data.  If the 
entity of interest, say the species, is in an auxiliary term, the search has to 
magically connect the standard name with the auxiliary term, which requires 
more custom search capabilities than are currently widespread.

On Mar 22, 2013, at 16:36, Cameron-smith, Philip cameronsmi...@llnl.gov 
wrote:

 Hi,

 I would have no idea of what CFU was, so I suggest it be spelled out if it is 
 used in a std_name.

 We had a very similar discussion when atmospheric chemicals started to be 
 included in CF std_names.   In that case it was decided to include them 
 one-by-one, and defer the discussion until the current system stopped 
 working.  In defense of that decision it has worked OK: once the pattern has 
 been established, new std_names with different species get approved fairly 
 quickly.

 There were complications with doing it as you suggest.   I think those 
 objections could have been overcome, but it would have required work and 
 changes to CF.  I have a dream that this capability will become part of CF2.0 
 someday :-).

 The two main problems that I recall were 'green dogs', ie names that would be 
 allowed but nonsensical (eg mass of CO2 expressed as nitrogen, or surface 
 area of O3), and the CF convention would need to be formally altered (and the 
 discussion eventually ran out of steam).

 I believe that 'green dogs' are 'red herrings', ie even if a 'green dog' is 
 allowed, no user would ever actually use it.  Hence this is not a problem.  
 Changes to the CF convention seem to be going faster now, but they still take 
 time and effort.

 Good luck,

Philip

 ---
 Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab.
 ---



 -Original Message-
 From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of
 Alessandra Giorgetti
 Sent: Friday, March 22, 2013 8:42 AM
 To: sdn2-t...@listes.seadatanet.org
 Cc: cf-metadata@cgd.ucar.edu; Klaas Deneudt; 'John Maurer'
 Subject: Re: [CF-metadata] [sdn2-tech] RE: proposed standard names for
 Enterococcus and Clostridium perfringens

 Dear all,
 I want to underline that also in the chemical lot, for contaminants in biota 
 as an
 example, we have a similar issue like the biological one.
 We would like to keep Standard Name from the species name separated.
 So, I agree with Neil when saying

 'Anyway, I would agree that the species entity needs to be separated from the
 ‘standard name’. I think discussions in SDN tech about the draft biological
 format for ODV would also highlight this as a ‘must have’.'

 We look forward in the discussion.

 With kind regards,
 Alessandra and Matteo

 --
 Alessandra Giorgetti
 Istituto Nazionale di Oceanografia e di Geofisica Sperimentale-OGS Sezione di
 Oceanografia - OCE National Oceanographic Data Center/IOC - NODC Borgo
 Grotta Gigante 42/c, 34010 Sgonico, Trieste (ITALY)
 Phone: +39 040 2140391
 Mobile: +39 320 4644653
 Fax: +39 040 2140266
 E-mail: agiorge...@ogs.trieste.it
 The NODC site with free data access http://nodc.ogs.trieste.it/

 Il 22/03/2013 16:15, Lowry, Roy K. ha scritto:
 Hi Klaas,

 What I was trying to say in my e-mail to CF was that I strongly suggest 
 that CF
 decouples the Standard Name from the species name.  However, should they
 choose not to then the cfu semantics should be removed from the units of
 measure into the Standard Name.  The example you quote is what I would
 suggest should - unfortunately in my current view - CF choose to include 
 species
 names in Standard Names.

 Apologies if I didn't make this clear.

 Cheers, Roy.

 
 From: Klaas Deneudt [klaas.dene...@vliz.be]
 Sent: 22 March 2013 15:06
 To: sdn2-t...@listes.seadatanet.org; 'John Maurer';
 cf-metadata@cgd.ucar.edu
 Subject: RE: [sdn2-tech] RE: [CF-metadata] proposed standard names for
 Enterococcus

[CF-metadata] Keeping taxon names out of Standard Names

[Lowry, Roy K.]

Dear All,

I am considering setting up a Trac ticket aimed at making the following changes 
to the standard

1) Addition of a section on handling biological data in CF

2) Addition of a couple of parameter attributes for taxon name and taxon 
identifier (e.g. Aphia ID)

3) Proposing a set of generic biological Standard Names

Before I take this on, I'd appreciate indications of support/opposition and a 
volunteer to moderate the ticket.  I would also like to get this either 
accepted or killed off completely before the next Standard Names update at the 
end of April so I don't end up causing the same work-blocking frustrations to 
John Maurer that have been endured by the proposer of ISO8601.

Cheers, Roy.


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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] proposed standard names for Enterococcus and?Clostridium perfringens

[Lowry, Roy K.]

Thanks Jonathan,

I was indeed responsible for introducing 'green dogs' to discussions in CF, but 
since then my experience has expanded further into biological data and, in 
particular, into the world of contaminants in biota through EMODNET and our 
work in BODC with the Sea Mammal Research Unit.  This has shown what you say 
about invalid combination possibilities for taxa being much less of an issue to 
be exactly right.  It has also shown me that protection against 'green dogs' 
can in some circumstances become an unaffordable luxury.

There are couple of points in your message where I would do things slightly 
differently.

First, I would prefer 'number_concentration_of_taxon_in_sea_water' to 
'number_concentration_of_biological_species_in_sea_water', because not all 
biological data are identified to the species level.  Often the counts are at 
the level of genus, class or even phylum.

Secondly, I think that CF setting up a controlled vocabulary for taxa is an 
unnecessary duplication that will cause us a lot of unnecessary work and take 
us out of our domain expertise comfort zone.  In the marine domain, there is an 
almost universally accepted taxonomic controlled vocabulary with lashings of 
accompanying metadata that is extremely well governed by internationally 
recognised experts in the field with high quality technical governance in the 
form of tools, including a web service API.  This is the World Register of 
Marine Species (WoRMS). I fully appreciate that CF covers more than the marine 
domain, but there is an alternative governance in the form of the International 
Taxonomic Information System (ITIS) , which is aimed more at terrestrial life 
than marine. If we say that names used in CF should be registered in at least 
one of these then we should be OK.

As you will see in a message that has just been released, I'm proposing taking 
this forward through a Trac ticket.

Cheers, Roy.




From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan 
Gregory [j.m.greg...@reading.ac.uk]
Sent: 25 March 2013 09:00
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] proposed standard names for Enterococcus 
and?Clostridium perfringens

Dear all

I agree with Philip that cfu should be spelled out. I was also going to make
the same point about Roy's proposal being different from our treatment of
chemical species, which are encoded in the standard name; this system seems to
be working. One reason for keeping this approach was the green dog problem.
That particular phrase is actually Roy's, if I remember correctly. That is, we
wish to prevent nonsensical constructions, by approving each name which makes
(chemical) sense individually.

However Roy argues that there is an order of magnitude more biological species
to deal with than chemical. I don't think that keeping the same approach
(encoding in the standard name) would break the system, but it would make the
standard name table very large. Perhaps more importantly, if there were so
many species, I expect that data-writers would simply assume that each of the
possible combinations of pattern and species did already exist in the standard
name table, without bothering to check or have them approved. That would defeat
the object of the system of individual approval.

We don't have to follow the chemical approach. For named geographical
regions and surface area types (vegetation types etc.) we use string-valued
coordinate variables, rather like Roy proposes here. To follow that approach
we would need a new table, subsidiary to the standard name table, containing
a list of controlled names of biological species. We would use the same
approval process to add names to this list as we do for the standard name
table. (This is what we do for geographical regions and area types.) We would
then have a standard_name such as
  number_concentration_of_biological_species_in_sea_water
whose definition would note that a data variable with this standard_name must
have a string-valued auxiliary coordinate variable of biological_species
containing a valid name from the biological species table. If there is just
one species, the auxiliary coordinate variable wouldn't need a dimension,
but this construction would also allow a single data variable to contain data
for several species, by having a dimension of size greater than one.

Cheers

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list

[CF-metadata] Taxa in CF. Some questions

[Lowry, Roy K.]

Dear All,

I am currently working on a Trac ticket submission for handling of taxonomic 
data in CF and thought I'd run an example past the list to make sure I've got 
it right.

Jonathan suggested using a container variable analogous to geographic regions.  
My interpretation of this would result in a simple time series (excluding 
ancillary variables and  most parameter attributes for clarity) for two taxa 
being structured as follows:

dimensions;
INSTANCE = 1 ;
MAXT = 1000 ;
STRING80 = 80;
LABEL = 2;
variables;
float abundance(INSTANCE, MAXT, LABEL);

abundance:standard_name=number_concentration_of_taxon_in_sea_water;
abundance:co-ordinates=taxon_name;
double time (INSTANCE, MAXT);
char taxon_name (INSTANCE, LABEL, STRING80);
taxon_name:standard_name=taxon_name  /*Standard Name yet to 
be proposed*/;
char taxon_identifier (INSTANCE, LABEL, STRING80);
taxon_identifier: standard_name=taxon_identifier;

Note that I have included a taxon_identifier (populated using aphiaID, ITIS 
TSN, LSID) in addition to a taxon name because homonyms do exist and this is 
the only way of distinguishing them.  It also provides some degree of 
protection against spelling errors, which are a persistent problem with 
taxonomic names.

My instinctive encoding would have been:

dimensions;
INSTANCE = 1 ;
MAXT = 1000 ;
 variables;
float abundance1(INSTANCE, MAXT);

abundance:standard_name=number_concentration_of_taxon_in_sea_water;
abundance:taxon_name=taxon#1 name;
abundance:taxon_identifier=aphiaid:taxon#1 aphia identifier;
float abundance2(INSTANCE, MAXT);

abundance:standard_name=number_concentration_of_taxon_in_sea_water;
abundance:taxon_name=taxon#2 name;
abundance:taxon_identifier=aphiaid:taxon#2 aphia identifier;
double time (INSTANCE, MAXT);

However, having thought it through I'm coming around to preferring Jonathan's 
encoding as it's much more powerful and allows different taxa lists to co-exist 
within a single NetCDF container.  Does anybody disagree with this? If not, is 
there anything that needs to be changed in my example - e.g. should 
taxon_identifier also be specified as a co-ordinate?

Cheers, Roy.

Please note that I now work part-time from Tuesday to Thursday.  E-mail 
response on other days is possible but not guaranteed!




  
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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Taxa in CF. Some questions

[Lowry, Roy K.]

Hello Jonathan,

The reason that I used MAXT rather than TIME is that I am trying to follow the 
point data conventions with the possibility of multiple time series (along the 
INSTANCE dimension) of different lengths stored as padded rather than ragged 
arrays in a single file.  Your example is restricted to a single time series, 
which might be a better idea for the example in the CF documentation as it has 
less confusing distractions.

I'm afraid that biology is a less precise domain than physics.  However. 
compared to what we had when I started with biological data management 20-odd 
years ago, resources like WoRMS and ITIS are a massive step forward.  I've been 
searching for something conforming to your expectations for 20 years, but have 
come to the conclusion it's an impossible dream as it'sorthogonal to the 
bioscience paradigm!

What WoRMS/ITIS have delivered are unique and reliable identifiers for taxa, 
but these are not self-describing - the TSN and aphiaID are in fact integers. 
Using these IDs both circumvents the homonym issue (which can be infuriating: I 
have had many battles with a marine coral misidentified as a South American 
centipede because they both have the same species name) and provides a defence 
against the habit biologist have of changing the taxon names for a given entity 
over time. They have also done a lot to standardise the spelling of taxon 
names, particularly issues such as discrepencies in Latin word endings (e.g. 
forestii versus foresti). I cannot see any alternative to imcluding taxon_names 
and taxon_identifiers in parallel and I'm relieved that you are reasonably 
comfortable with the idea.

Cheers, Roy.

From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan 
Gregory [j.m.greg...@reading.ac.uk]
Sent: 02 April 2013 17:38
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata]  Taxa in CF.  Some questions

Dear Roy

Yes, I think you are right that it is useful to have the taxon as a dimension
because it allows you to put several of them in one variable, provided it's
the same quantity, with the same generic standard name. That is just like
bundling up timeseries from different locations into one data variable. This
kind of dimension is called a discrete axis in CF 1.6, section 4.5. By
container variable CF so far means something different: that's an empty
data variable which exists to hang attributes from, to specify grid_mappings.

I assume that MAXT is the size of the time dimension, isn't it? Could we write
your example like this:

dimensions;
  time=1000;
  string80=80;
  taxon=2;
variables:
  float abundance(time,taxon);
abundance:standard_name=number_concentration_of_taxon_in_sea_water;
abundance:coordinates=taxon_identifier taxon_name;
  char taxon_name(taxon,string80);
taxon_name:standard_name=taxon_name;
  char taxon_identifier(taxon,string80);
taxon_name:standard_name=taxon_identifier;

I am not sure if I've understood your example, though. Yes, I think both the
taxon descriptions should be string-valued auxiliary coordinate variables, as
I have shown them (CF section 6.1).

If there is only one taxon, the taxon dimension could be omitted.

However, I am a bit disturbed to learn that the taxon_name might not be
reliable or unique. If CF is going to depend on an external vocabulary, I would
argue that it needs one which provides unique and reliable self-describing
identifiers.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] interplay of standard name modifiers, cell_methods -- is there a problem?

[Lowry, Roy K.]

Hi Jim,

There are a lot of nails being hit on the head at the moment.  The Standard 
Name attribute was conceived as a standardised label for the geophysical 
phenomenon - a sort of grouping term for what was being measured.  Note that 
the Standard Name isn't a mandatory attribute in CF - the rules state that 
there either needs to be a long name OR a Standard Name!

Over time there have been various attempts to turn the Standard Name into 
something different - the 'single location to gather important information 
about the kind of data contained in a variable' as you put it (I like that 
description).  For example, the OceanSites community made the Standard Name 
mandatory in their CF profile.  This caused requests to be made for new 
Standard Names appropriate to your definition, but not the original Standard 
Name concept.  Some of these got through: others didn't, which makes the entity 
definition of the Standard Name concept a little blurred.

Another strategy has been to provide a 'signpost' pointing out the location of 
all the various bits of information needed to fulfil your definition.  There 
was a proposal called Common Concept (Trac ticket 24) designed to do this.  
Unfortunately, it required a small but significant amount of effort to set up 
that was never resourced. In fact, it seemed like it was cursed - I even had to 
hand back funding allocated for the purpose because a critical staff member 
left at a time when there was a total ban on UK public service recruitment. A 
'resource light' version of this strategy - CF String Syntax (Trac ticket 94 
which I'm moderating) - is currently ready to implement once it has been 
written up as a Conventions document update.  If we get this finished do you 
think it would resolve the problems you see?

Cheers, Roy.


Because it isn't mandatory in CFPlease note that I now work part-time from 
Tuesday to Thursday.  E-mail response on other days is possible but not 
guaranteed!

From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jim 
Biard
Sent: 02 April 2013 21:19
To: cf-metadata@cgd.ucar.edu
Cc: Jonathan Gregory
Subject: Re: [CF-metadata] interplay of standard name modifiers, cell_methods 
-- is there a problem?

Jonathan,

You haven't been unclear about how we got into the state we are currently in.  
We got to now by adding bits here and there as needs arose without always 
thinking about the implications for the whole system down the road (which you 
did a great job of describing).  A lot of good work has been done to get where 
we are today, and I appreciate that.  I also think that there is room for 
improvement in how we represent values that result from operations applied to 
measurements.

Yes, we could add paragraphs to the documentation to tell users to go look in 
various places when they are trying to figure out what the contents of a 
variable are, but that is not user-friendly behavior.  I want to make it easy 
and intuitive to understand what sort of information a variable contains.  If 
we consider the standard name attribute as the location where the essence of 
the variable contents is described using a controlled vocabulary, it makes 
sense to provide a mechanism within that vocabulary for distinguishing between 
a direct measurement (air temperature) and information about a measurement 
(standard deviation of air temperature).  We provide this for some operations 
on measurements (number of observations, standard error, etc), but not for 
others (standard deviation, variance, anomaly, etc).

Expanding the list of standard name modifiers in the CF Metadata Conventions 
would allow us to make variables more self-describing and less confusing, and 
allow a user (or software) to look in a single location to gather important 
information about the kind of data contained in a variable (which I see as the 
purpose of the standard_name attribute).

Grace and peace,

Jim

Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites
Remote Sensing and Applications Division
National Climatic Data Center
151 Patton Ave, Asheville, NC 28801-5001

jim.bi...@noaa.govmailto:jim.bi...@noaa.gov
828-271-4900

On Apr 2, 2013, at 1:05 PM, Jonathan Gregory 
j.m.greg...@reading.ac.ukmailto:j.m.greg...@reading.ac.uk wrote:


Dear all

Jim asked,

As some examples of the confusing situation we have now, why do we have a
separate word modifier number_of_observations instead of a
number_of_observations_of_X transformation modifier?  Why don't we have
variance_of_X or anomaly_of_X transformations (or separate word modifiers
variance or anomaly)?  Why isn't there a cell method for standard error?  I
can't discern any logic behind the current partitioning.

I've tried to explain how this came about, but perhaps I am not being clear,
so let me try again:

* We introduced the modifiers like number_of_observations for those situations
where it was thought likely that a large number of standard names would need
them. 

Re: [CF-metadata] New CoordinateType: Spectral?

[Lowry, Roy K.]

Hello Randy,

If doing this, please make it clear that by 'Spectral' you mean 'wavelength 
spectral'.  There are other types of spectra, such as frequency (used for wave 
spectra) and size (used optical plankton counters and other particle sizers).

Cheers, Roy.

Please note that I now work part-time from Tuesday to Thursday.  E-mail 
response on other days is possible but not guaranteed!

From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
rho...@excaliburlabs.com
Sent: 10 April 2013 14:20
To: cf-satell...@unidata.ucar.edu; cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] New CoordinateType: Spectral?


Jonathan:



With the growing interest in the CF conventions around the world by the  
satellite CF data producer and user communities coupled with the ubiquitous 
nature of wavelength-based satellite CF data sets, does it make sense to add a 
paragraph to Section 4 Coordinate Types to discuss Spectral Coordinates ?



very respectfully,



randy









Dear Aleksandar



 I know this will likely end up as a trac ticket but would like first

 to gauge the community's opinion about defining a new coordinate type.

 Satellite data originates as measurements at a number of intervals of

 the electromagnetic spectrum. These intervals are commonly referred to

 as bands or channels. Deciding on how to store the band information is

 one of the key issues toward a standardized representation for

 satellite data.



 The convention seems to allow storing of band information either as a

 numerical coordinate variable or as a string auxiliary coordinate

 variable.



Yes, the CF standard could handle both of those, without any modification.

A trac ticket may not be needed. I certainly think there is no problem at

all for a numerical coordinate of band wavelength. You need only to propose

a new standard name for it, if one is needed. There is already a generic

standard name of radiation_wavelength, included for use as a coord variable

just as in your first example. If you need something more specific, I would

suggest sensor_radiation_wavelength. The coord values for this would be the

central wavelengths, and you could also supply bounds specifying the range

of wavelengths covered by the sensor.



Although string-valued auxiliary coordinate variables are possible already,

as used in your second example, I would argue they are less useful as

metadata than numerical ranges. That is because the main use of CF is to

support intercomparison of datasets, which is better-defined if numbers are

used. If there are widely used definitions of named wavelength bands,

required for intercomparison of many datasets, a standard_name could be

defined with a number of permitted string values. I think this extension

could probably be seen as a new standard_name, not requiring a change to

the conventions, although it could be explicitly mentioned in section 6 like

Roy is proposing for biological taxa.



Best wishes



Jonathan




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.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata