Dear All,
I think the nature of Standard Names is changing as CF moves from the model domain into the observational domain. OceanSites made the Standard Name mandatory and from there it is a short step to the Standard Name taking on significance in the discrimination between parameters. Whether this change is good or bad is a moot point, but it has built up considerable momentum.
The discomfort with multiple parameters having the same standard name in a CF file only arises when there is no other attribute available that may be used as a discriminator in combination with the Standard Name.
In the case of John G's family of time channels there seems to be no suitable discriminatory attribute in base CF, hence the desire to address discrimination through Standard Name development. It's possible a suitable attribute exists in one of the observational extensions or could be included into a development of one of these extensions. However, some formalisation mapping concept labels like name for each 'time' to the combination of attributes in the file is needed, which is exactly what Common Concepts is aimed at addressing. If we don't do something only community-cogniscent applications will know what to do with the duplicate Standard Names, which screams 'stovepipe under construction' to me.
One other point concerning this thread is that I'm a little worried about the confusion developing between a 'sensor' and a 'sampler' - to me the latter collects something physical for subsequent laboratory analysis.
Cheers, Roy.
>>> Steve Hankin <Steven.C.Hankin at noaa.gov> 10/27/2008 3:44:32 pm >>>
Hi all,
Please forgive me for butting in late in a discussion. As an listener,
but not a participant, I find that I am not clear on the ground rules
for making decisions. Should CF standard names convey:
* how a measurement was made?
* for what purpose a parameter was measured?
Underlying this discussion is a discomfort with the notion that there
could be more than one variable in a CF file bearing the standard_name
"time". Is this a valid discomfort?
I'd note that observation communities such as OceanSites, Argo and GOSUD
that have adopted CF have regarded CF only as the basis for their
community standard. CF is not presumed to be sufficient as-is. They
have extended CF with many additional attributes and variables that
convey the subtler levels of semantics their community requires to
capture all of the details of a measurement type.
- Steve
P.S. Regarding the question below -- "which is the true time?" -- can
this be addressed through the use of the CF "coordinate = " attribute?
================================================================
Jonathan Gregory wrote:
> Dear John
>
>
>> Uh, to an observing systems/cyberinfrastructure person, ALL time
>> values have errors, _especially_ those from devices.
>>
>
> I think the point is, as Nan says, that the data user will want there to be one
> "time" which is to be regarded as coordinated, as the "true" time, in the sense
> that data values with the same coordinate of time are to be regarded as truly
> simultaneous. It is up to the data-writer to provide this coordinate if
> possible as they are typically better able to do it than the user. This one has
> the standard_name of "time".
>
> Regarding time_from_device, I would say that is not clear to me, because *all*
> times come from some device, even if it is an atomic clock determining the UTC
> standard! What about time_from_instrument. Would that be clearer than sensor?
> I think a sensor is a sampler in the existing name
> temperature_of_sensor_for_oxygen_in_sea_water
> but perhaps Nan or Roy could comment.
>
>
>> mission_elapsed_time is fine.
>>
> OK.
>
> My point about redundancy refers particularly to the time within year and day.
> Do you mean the device is giving you both the time (elapsed since some
> reference) and its components (time within year and day etc.). The time and
> its components are related by well-defined arithmetic. Do you want to record
> them all separately? If so, why? Perhaps for completeness, to be on the safe
> side?
>
> Thanks for the discussion. Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
"The only thing necessary for the triumph of evil is for good men
to do nothing." -- Edmund Burke
--
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 Tue Oct 28 2008 - 05:44:32 GMT
