On 8/27/11 6:51 PM, John Graybeal wrote:
> OOI will be adopting and/or developing some standard vocabularies for
> many facets of instruments (manufacturer, model, 'type' (ick),
> possibly mount, likely a few other things.
That's good news, at least minus the 'type' vocabulary; I'd
be especially interested in the eventual list of types though,
if only out of morbid curiosity.
> We'll also have to create or use an instrument description
> specification like yours, Nan. Can you tell me, what is
> instrument_reference?
Instrument_reference is a URL (etc) that contains a description of
the instrument. I was actually hoping this would point to a record
in the MMI device ontology server, but that seems unlikely at this
point.
As I told Roy, possibly off the list, this field isn't very
well implemented; it can point to a PDF of a spec sheet, an
html page describing the instrument, or an entry in Roy's
vocabulary server. Not interoperable, but the only thing I
could come up with when I wanted it.
> And (this may be a question showing off my
> ignorance) do I correctly understand that (time, depth) means you are
> identifying the instrument for every measurement, not just every
> depth?
The dimensions for the descriptive variables are (depth,
string_lenth) because there's one entry for every depth;
these are not on a time-varying basis in my data sets.
> So getting back to the original question, for automated sampling
> methodologies, I recall seeing at least one vocabulary that was
> particularly well suited, in addition to Roy's for a wide range of
> techniques. Nan, if your spec included TEMP_sensing_methodology for
> each variable, it would go a long way to a good answer, seems to
> me..
Yes, that would be a reasonable piece of information, at
least for temperature, but I'm not aware of any vocabulary
that's available - especially one that covers the wide range
of sensors we use. We've got 20 or so observational data variables,
and some have complex sensing methodology (long wave radiation's
a good example of that). Then there are so many other factors,
like time constants, that are as important as the methodology...
An ontology would be REALLY useful here.
Nan
> On Aug 26, 2011, at 07:06, Lowry, Roy K. wrote:
>
>> Hi Nan,
>>
>> It would be really neat from my point of view if your ancillary variables were to include a link to a published vocabulary of instruments (in addition not instead of your existing fields). As you probably know, I can offer you one (http://vocab.ndg.nerc.ac.uk/list/L22/)........
>>
>> Cheers, Roy.
>>
>> -----Original Message-----
>> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Nan Galbraith
>> Sent: 26 August 2011 14:58
>> To: cf-metadata at cgd.ucar.edu
>> Subject: Re: [CF-metadata] A question regarding standard names
>>
>> I agree with Roy, that as long as the values can be reasonably
>> compared they should share a standard name.
>>
>> It would be a good next step, though, to develop or adopt some
>> standard way to describe the methodology, or at least the instrumentation,
>> so that the user can allow for any distinction between e.g. microwave and
>> infrared brightness_temperature.
>>
>> We're using an ancillary variable for this, but there may be some
>> other way to do it that we haven't thought of yet. Whatever method
>> is adopted (when/if one is) it needs to work for files that have data
>> from different instruments at different depths.
>>
>> float TEMP(time, depth) ;
>> TEMP:standard_name = "sea_water_temperature" ;
>> TEMP:ancillary_variables =
>> "TEMP_Instrument_manufacturer, TEMP_Instrument_model
>> TEMP_Instrument_reference TEMP_Instrument_mount
>> TEMP_Instrument_serial_number TEMP_QC TEMP_QC_value
>> TEMP_QC_procedure TEMP_Accuracy TEMP_Precision TEMP_Resolution";
>> char TEMP_Instrument_manufacturer(depth, 20);
>> char TEMP_Instrument_model(depth,6);
>> ...
>>
>> Nan
>>
>> On 8/26/11 9:05 AM, Lowry, Roy K. wrote:
>>> Hi Jim,
>>>
>>> Not the first time this has cropped up on the CF list. The problem is that when the Standard Names started out they were designed as OPTIONAL terms to identify model fields that referred to a given geophysical phenomenon. There has been a sort of mission creep since then with standard names being considered by some as unique standardised labels for every data channel in a CF file, accelerated by some communities choosing to make Standard Names compulsory for their CF files. This of course creates the need for more and more information to get hung off the Standard Name tag.
>>>
>>> I continue to support the conclusion of these previous discussions, which is to keep methodologies out of Standard Names unless the methodology results in a significantly different phenomenon. There was quite a debate on this issue involving different types of sea surface temperature that you might care to look up in the archive.
>>>
>>> Cheers, Roy.
Received on Sun Aug 28 2011 - 12:20:08 BST
