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
> 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 Fri Oct 24 2008 - 17:07:17 BST
