Hi Nan,
In the version of Standard Names I serve, I would certainly include a mapping:
sea_water_practical_salinity has broadMatch sea_water_salinity
However, the Standard Names are served in different ways so I thoroughly endorse your suggestion for describing the semantic relationship between the two in the definition field.
Cheers, Roy.
-----Original Message-----
From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Nan Galbraith
Sent: 27 July 2011 14:46
To: Jonathan Gregory; CF-metadata at cgd.ucar.edu
Cc: Trevor.Mcdougall at csiro.au
Subject: Re: [CF-metadata] new TEOS-10 standard names
If we're going to add a standard name sea_water_practical_salinity,
and retain the name sea_water_salinity as a separate entity,
don't we need to specify some distinction or relationship between
them?
If we're not going to make practical salinity an alias for salinity, we
should at least take this opportunity to add something meaningful
to the sea_water_salinity definition.
Would 'Salt content of seawater on the Practical Salinity Scale' be a
general enough definition that would accommodate legacy data sets,
while still serving to distinguish 'salinity' from 'absolute salinity'?
There's already a reference to PSU in the definition, but it's not as
direct as it could be.
Cheers - Nan
On 7/26/11 11:45 AM, Jonathan Gregory wrote:
> Dear all
>
> I understand the need to be clear, with new standard names, which observational
> quantity is being collected in future. I do not agree, however, that we should
> make the plain "salinity" name an alias for something more precise. This is
> partly because that might change the meaning of existing data, possibly
> incorrectly as Trevor points out. Partly it is also because I think it is
> quite possible that models, perhaps idealised, may be used in which it would
> not be meaningful to be more precise than just "salinity".
>
> Trevor argues that existing ocean models use practical salinity because (a)
> they are initialised with observations of that and (b) they assume so in their
> equation of state. I don't think (a) is necessarily so. In some cases, they
> might not be initialised with observations, for instance in idealised
> investigations of spin-up. Even when initialised from obs,
> they will almost certainly drift to a less realistic state. I don't know enough
> about it to be sure about (b). Unless we could be certain this is always the
> case, I think plain "salinity" should be retained for possible use in models.
> However, we could certainly recommend that models should use one of the new
> more precise terms if definitely appropriate. This recommendation could be
> included in the standard_name definition of plain "salinity".
>
> I understand the existing standard name sea_water_temperature to mean in-situ
> temperature, as it does for air temperature. This could be stated in the
> definition.
>
> The purpose of standard names themselves is not to prescribe or recommend what
> quantities people should store in netCDF files. It is to allow them to describe
> with sufficient precision the quantities they have chosen to store, in order
> to make it possible to decide which quantities from different datasets should
> be regarded as comparable.
>
> Standard names are all in lower case, regardless of what case is used in
> ordinary writing. This is for simplicity in matching strings. Case-sensitive
> matching would inevitably trip people up and cause a nuisance when they got
> it wrong.
>
> Best wishes
>
> Jonathan
>
--
*******************************************************
* Nan Galbraith (508) 289-2444 *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 *
*******************************************************
_______________________________________________
CF-metadata mailing list
CF-metadata at 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.
Received on Wed Jul 27 2011 - 07:51:08 BST
