Nan/Jonathan,
Following our discussions at IMDIS/GO-ESSP I think the OTS is an area
where we need to look carefully at the role of the BODC Parameter Usage
Vocabulary in the CF standard.
I think Jonathan's suggestion of extending the Standard Names to cover
the requirements of OTS goes against the idea we had at GO-ESSP to avoid
increasing the area of overlap between the two vocabularies.
What I think we need in OTS is a mechanism to link to either vocabulary
or perferably both. My suggestion would be for a field somewhere in the
standard to locate the 8-byte BODC parameter code with an option to use
the full_title term from the vocabulary for the CF long name. This
would allow the data originators - ie those who know their data best -
to establish the vocabulary mapping.
The weakness with this is that the structure implies the relationship:
BODC Parameter Usage Vocabulary term = (ie is exactly the same as) CF
Standard Name term
It is glaringly obvious to anyone who has looked at the vocabularies in
any detail that this such perfect correspondance is far from universal.
What we really need if we have terms from the two vocabularies
describing the same variable is a standardised statement of how these
descriptions relate to each other based on OWL or something more
restrictive (but specifically targetted at the problem) like SKOS.
Cheers, Roy.
Nancy Galbraith <ngalbraith at whoi.edu> 6/16/2005 3:35:12 pm >>>
Thanks for bringing OTS into the discussion, Steve, and thanks for your
comments
Jonathan.
Our operational data is so much simpler than that of some other CF
users
that it
sometimes seems we don't exactly fit here, but the CF community and
resources
have been really helpful, and your standard was the obvious choice for
our data.
> But instead they could be CF-compliant by dimensioning
> the data variable as (time,depth) and giving it a coordinates
> attribute to point to auxiliary coordinate variables of lat(time)
> and lon(time).... These are what CF calls "scalar coordinate
> variables" and they avoid introducing a size-one dimension
> just to attach coordinate info.
Maybe I didn't think this through well enough, or I completely missed
one of
the basic CF concepts. I somehow missed that CF files should "avoid
introducing
a size-one dimension just to attach coordinate info" and thought that 4
dimensions was
a reasonable way to go, as it gives you the overall size of the dataset
in one query.
For mooring data, this seems to make perfect sense, or maybe I just
expect it because
it was standard in our old NetCDF implementation, EPIC.
We have not ruled out files containing data from more than one platform
- as we
sometimes deploy arrays of sensors. Such a file would have lat/lon
dimensions > 1,
in all other files these dimensions would be 1. This does lead to a
problem with drifters,
where the X and Y dimensions of the measured parameters are 1 but lat
and long are
of dimension T.
> CF provides a method to attach quality-control info to data
> variables, which OTS could extend to meet their needs in this
> area (CF 3.4).
The CF scheme for QC might help us give the different data providers
more flexibility
than having a defined table as we currently do. The down side is that
if
the flag_meanings
are not defined as part of the standard, they can't be interpreted by
software; I'm not
sure how CF users implement this.
We also have some data sets (mine, for instance) where QC information
is
more
logically supplied as an attribute, because the data is interpolated
over time to correct
clock drift after initial QC procedures. The original individual points
are gone,
and point-specific QC becomes meaningless.
> They probably would like some additions to the standard
> name table.
I haven't had a problem finding standard names for our parameters yet.
I'm
still hoping the udunits system will at some point include conductivity
and
salinity units other than 1, though. Meanwhile I'm dealing with this
by
specifying CF-compliant "units" and "text_units" that are useful for
labels
and don't have to be accepted by udunits.
Cheers - Nan
*************************************************************
*Nan Galbraith Upper Ocean Processes Group *
*Woods Hole Oceanographic Institution Woods Hole, MA 02540 *
*************************************************************
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Fri Jun 17 2005 - 01:52:58 BST
