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: [email protected]
[mailto:[email protected]] On Behalf Of Nan Galbraith
Sent: 26 August 2011 14:58
To: [email protected]
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.
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
