Hi Sylvie,
Looking through your list everything is covered by the BODC parameter usage vocabulary. There may need to be a bit of fine tuning to provide things like method-neutral codes, but that can be accomplished without problem.
My guess is that your statement that there aren't the codes you need is because you can't find them. The vocabulary is large and the navigation tooling is not very well developed so finding things isn't as easy as it could be. However, I offer my services as a guide. To take this forward all I need is an OTS contact to work one-to-one with me to get the code set most suited to your needs. Who should this be - Nan, Thierry or yourself?
This leaves the issue of how to embed the BODC terms into your OTS standard. The vocabulary term in full (the BODC parameter table full_title field) could be mapped into the CF long name, but I think that it's also important to get the key (ie the code) in there somewhere as the text syntax (but NOT semantics) is subject to change. Could you take that forward and agree the syntax with the CF community?
Cheers, Roy.
>>> Sylvie POULIQUEN <Sylvie.Pouliquen at ifremer.fr> 06/20/05 8:48 AM >>>
Dear Colleagues
I'm Sylvie Pouliquen and I started 2 years ago, together with Nan
Galbraith and Thierry Carval, to chair the Data Management activities
within the OceanSites community.
As Nan said we DO need to have a UNIQUE vocabulary within the OTS
community and it should be feasible as the number of parameters that we
want to address is limited.
We would like to be compatible with international standards but up to
now we have not found any on-the-shelf standard that fulfill our needs.
Some of our needs are fulfilled by BODC vocabulary and others by CF one.
It's normal because we are probably one of the first international
project, involving USA and European teams, that want to standardize
vocabulary on a field that cover both oceanographic and atmospheric
variables and who don't want to re-invent the wheel
We would also like to be coherent with Argo and GOSUD program choices as
we want OTS realtime data to be more used by the GODAE community.
As we want to issue our data in a standardized manner this SUMMER, we
need to get advice from BODC&CF in a coordinated manner very rapidly.
I thought from the discussion I had with Roy at IMDIS conference that it
was the purpose of a meeting you had beginning of June. The parameters
that we are dealing with are mentioned page 17 of the attached manual.
Without clear coordinated advice from your groups before end of June we
will have to take decisions among ourselves and probably issue our own
OTS standards with will be , to my point of view a pity...
So I'm looking forward to your help to make a small step towards a
better standardization
Best regards
Sylvie
Roy Lowry a ?crit:
> 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
--
----------------------------------------------------------------
Sylvie POULIQUEN
Responsable Coriolis / Head of Coriolis
IFREMER
BP70
29280 Plouzane
FRANCE
Tel.: (+33) 2 98 22 44 92 email: sylvie.pouliquen at ifremer.fr
Fax: (+33) 2 98 22 45 33 WWW: http://www.coriolis.eu.org/
----------------------------------------------------------------
Received on Mon Jun 20 2005 - 08:49:18 BST
