Ah, so you force me to explain further. I think I failed to properly
separate concerns in the first email, sorry.
Yes, the day-of-year of an observation was just time in another form.
(Some tools like to compute with day-of-year, some systems like to
provide it. Ick.) This particular example, while almost entirely real,
also represents a broad range of sensor data systems for which we
collect data. We would like to be able to put their data as is into
netCDF files; and we would like to be able to link those parameters to
standard names, even in describing the actual data coming from the
sensors. But I think we have two problem domains in this discussion:
(1) Using Standard Names for broader semantic interoperability; (2)
COARDS/CF representation in a data file.
I think it's fair to say that the Standard Name only implies a format
restriction in the context of a COARDS/CF file. So the _concept_ of
the CF standard name 'time' can be leveraged in any other context,
without suggesting a particular format.
So from your response I conclude the following:
'time' is a representation of any chronological parameter, even if
just a day or a year; typically it represents a system time.' In a
netCDF COARDS/CF file, a 'time' value must be be expressed as a
"period of time since an epoch".
'sensor_time' is any chronological parameter produced by a sensor;
with similar constraints in a netCDF COARDS/CF file. (I guess
sensor_time is a type of time.)
The following variables are not fit for COARDS/CF, and thus can not
have a CF standard name in that context:
- Any time parameter that is expressed using the Gregorian calendar
(because these are in a new format)
- Any time parameter whose reference epoch changes over the course
of the data set (e.g., yearly, or daily)
But I could use the Standard Name 'time' to reflect the _meaning_ of
these variables in some other context, like defining the sensor outputs.
If this is correct, it is very helpful. I think 'sensor_time' is a
helpful clarification and extension of what already exists; it might
be that 'device_time' is an alternative, as in many vocabularies
devices can include both sensors and samplers. But I'll go with your
preference here.
Having a definition of 'time' would also help. I took a cut at one
above; yours would likely be better.
Thoughts?
John
On Oct 23, 2008, at 1:33 PM, Jonathan Gregory wrote:
> Dear John
>
>> DateTime (ISO8601), Elapsed Mission Time (seconds), Sensor Time
>> (ISO8601), Sensor Date (ISO8601), Day-of-Year
>> Data Record:
>> 2008-08-18T18:57:55.79, 8403.33, 12:12:11,2008-08-18,262
> ...
>
> Could the third and fourth fields (sensor date and time) be combined
> and
> encoded as a single time-since-ref variable? We could give it a new
> standard
> name e.g. sensor_time. I'd prefer that to adopting ISO8601 as a
> completely
> different way of encoding time in CF.
>
>> The fifth field is at least a 'days since' format, though the
>> reference point will have discontinuities every new year. I'm a
>> little
>> at sea as to whether this can be called 'time' or not.
>
> Yes, I think it would be a time - but what is it? Is just repeating
> the
> sensor date, in effect?
>
> Cheers
>
> Jonathan
> _______________________________________________
> 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 Thu Oct 23 2008 - 17:57:54 BST
