Uh, to an observing systems/cyberinfrastructure person, ALL time
values have errors, _especially_ those from devices. (As if the system
time isn't originally from a device, for that matter. But I
digress.) So actually, I find reported_time to be more suggestive of
absolute real-world time than device_time. Indicated_time is better,
but also less specific/to the point -- really doesn't say anything
more than 'time'.
Is a sampler a sensor? If so then I don't have any problem with
sensor_time. If not then I suggest device_time or time_from_device.
If you really prefer indicated_time, I can go with it.
mission_elapsed_time is fine.
Regarding redundancy, I want to go back to the original stated goal:
to be able to record and document the observed data from sensors. To
do this with maximum fidelity and confidence, I'd rather not be
putting computations all over the place to eliminate or recast the
redundancies that the manufacturer of the systems have carefully (or
not) installed. Yes it means possible inconsistency, but it is the
possible inconsistency that the device/system manufacturer left in
their system, for whatever reason. On what basis shall we decide which
way the inconsistency should be resolved? Given a 50/50 chance, I'd
rather leave the inconsistency in and just report what the instrument
reported.
I realize this operational measurements view may represent a phase
change (right phrase?) for CF, which maybe deals more with values that
were created 'with clear intent'. And maybe what I'm suggesting just
isn't a desirable philosophy for that reason. But in terms of
accurately capturing what sensors in a system are reporting, I think
we should expect lots of small "that doesn't make sense" moments in
coming up with effective standard names.
John
On Oct 24, 2008, at 12:52 PM, Jonathan Gregory wrote:
Dear John
time_from_device: time reported by some device (data source)
Somehow this seems a bit unsatisfying to me. It doesn't really
suggest that
this time might not be true time. Given your definition, why not
call it
reported_time, or maybe indicated_time. Your original sensor_time
has the
different advantage that we have another stdname mentioning "sensor".
(I just changed the form of this name so that it is collocated
with the other time variables)
I sympathise, but I think we should deal with that problem by having
better
tools for displaying and searching the table. There are many groups of
related stdnames that are not adjacent in alphabetical order.
The following three can each have an attribute pointing to the
variable that determines the time sequence; for example, the
attribute
could name another source of time values, and the current year is
established by those values. The units in all 3 are the same as the
units for time.
time_since_start_of_year: amount of time elapsed since the current
year began
time_since_start_of_day: amount of time elapsed since the current day
began
If you have other time variables which indicate the day and year,
these
would be redundant, wouldn't they? You can deduce them from the time
variable,
especially if it is in days since midnight on 1 Jan in some year.
I'm always
worried about redundancy meaning possible inconsistency.
time_since_start_of_mission: amount of time elapsed since the current
mission began
If the time variable has the start of the mission as the reference
in its
units, it serves both purposes. That would be an informal extra
convention.
To deduce the time since the start of the mission from a time
variable, you
need to know when the mission started. So perhaps you could store a
variable
for mission_start_time. That would be analogous to
forecast_reference_time,
and would be scalar. I feel more comfortable with that than with
time since
start of mission, because the latter is an array with a constant
offset from
the actual time, so again this would be redundant. However if the
actual time
itself is not stored in a variable, the time since the start of the
mission
would be independent, and I'd be happy with it. As a slightly
snappier but I
think equally clear name, what about mission_elapsed_time, which is
what NASA
call it?
Best wishes
Jonathan
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
John
--------------
John Graybeal <mailto:[EMAIL PROTECTED]> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project: http://marinemetadata.org
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
