John Graybeal wrote:
> All Steve's questions seem good to me. The last paragraph, about just
> being a "basis for their community standard", raises another: Is that
> the model CF intends to follow?
>
> My assumption, having understood that CF wants to be capable of
> representing observational data, was that CF would want to go 'all the
> way', and be capable of representing any of the observational data
> that the community collects and exchanges for oceanographic science
> reasons. This can include strange new concepts, many raw (not yet in
> science units, or not yet calibrated) data items, and diagnostic and
> engineering data.
Hi John,
Good question to raise. And points out that we need to pin down what we
mean by "capable of representing"? I'd argue that the successes (lets
presume) of OceanSites, Argo and GOSUD at using CF with extensions
demonstrates that CF is _capable of representing_ specialized time
series, profiles and trajectories, respectively. It does not seem like
an achievable goal to suggest that the text of the CF standards document
(or even the standard_names list) can 'go all the way' in explicitly
spelling out all the needs of all possible oceanographic measurement
types. That does not seem like a scalable approach to the problem.
> Steve's cited examples perhaps reflect the distance that has to be
> covered. In our research environment, CF standard_names are only
> occasionally applicable to the collected raw data.
>
> So *I'm hoping the question of intended CF scope is answered*, or at
> least addressed, in the course of resolving this specific instance.
Thanks. We're both expressing the same basic concern. Standard_name
discussions should be built on a shared (and written) understanding of
the desired scope of the CF semantics. Admittedly a hard thing to
express .... (Do we already this, Jon? It seems a different aspect of
the question than we see discussed in the guidelines:
http://cf-pcmdi.llnl.gov/documents/cf-standard-names/guidelines)
- Steve
Philosophical PS: <onMySoapBox> The above question goes to the heart of
the philosophical difference between CF and OGC/SOS (or WFS) -- at least
as I see it playing out recently. The marine community is hoping to use
the OGC standards process to develop XML schemas that capture the full
semantic richness of all measurements that the community may want to
interchange. A laudable goal. And I hope we'll achieve it ... no later
than 20 years from now =-O . The flaw that I see this approach is that
it seems to ignore the nature of the word "standard". You can only
standardize the things that you understand thoroughly. Through the OGC
process the marine community is trying to model very complex semantics
for the first time ever and hope (by some miracle) that the first-ever
efforts will be good enough to standardize. Good luck. I'd lobby that
we all crack open our history books and study which approaches have
worked and which have not when creating standards. The OGC process is
potentially a powerful glue for the community ... but only if it is
approached with appropriately modest expectations. <\onMySoapBox>
>
>
> john
>
>
>
>
> On Oct 27, 2008, at 8:44 AM, Steve Hankin wrote:
>
>> 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 <mailto: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 <mailto: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
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu <mailto: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
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20081027/f1fedd7e/attachment-0002.html>
Received on Mon Oct 27 2008 - 11:00:41 GMT
