Roy,
Excellent observations. To clarify re the time standard name, I do
not need to use it as a discriminator. What I need to do is identify
the appropriate standard name to use when there are multiple
variables, and they are all representing a time. CF may have been
ambiguous about this -- can 'time' only be a standard name for one
term in a file, because it indicates the reference time for the file?
Or can I have many variables with the standard name 'time'?
I think we are leaning toward allowing multiple variables with the
standard name 'time', as well as some variants that support other
'time offset' values that are common with observing systems. And
still discussing a 'time from a sensor' term. Jonathan, please feel
free to sum up or correct that.
I didn't pick up on anything that conflicts with your sampler
definition, I agree with what you said. Of course, some of those
kinds of samplers can also generate logs (of their sampling events)
that have time values.
John
On Oct 28, 2008, at 4:44 AM, Roy Lowry wrote:
> 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.
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
John
--------------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project:
http://marinemetadata.org
Received on Tue Oct 28 2008 - 13:44:39 GMT
