[Seavox] CDI Library 3 (Sampling interval code)

Roy Lowry rkl at bodc.ac.uk
Mon Dec 18 17:05:46 GMT 2006


Thanks John,

An interesting wider issue of controlled semantic extensions to controlled vocabulary entries. This certainly deserves some thought and I may well bring it up as a SeaVox issue once I've mulled it over - instantly I can see some interesting possibilities.

As far as our immediate SeaDataNet problem is concerned, we don't have that option at the moment (formats and systems in place), but it should go on our list of changes to consider in the next development cycle.  A lot of the data we (and other SeaDataNet centres) handle have been processed to some degree by the originators before submission to the data centre and so have guaranteed intervals in either time or distance (in which case time sampling interval is inappropriate, such as binned CTD data). Something like 75% of BODC's data fall into this category - hence the way the vocabulary was initially populated.

Having thought about it for most of the day, I am now coming to the opinion that the 'white lie' approach I initially proposed was maybe not the best and suggest we follow the approach suggested by our French colleagues.  So, unless there are specific objections I will add the following 'null' terms to the L031 Controlled Vocabulary in the server.

Code - 0 
Term - indeterminate
Definition - No regular sampling interval exists because measurements are made at irregular and unpredictable intervals

Code - 99
Term - unknown
Definition - A regular sampling interval exists but is not known to, or computable by, the information provider

Code - 98
Term - not applicable
Definition - There is no meaningful sampling interval, which includes measurements not repeated  in time (e.g. sediment core measurements) or measurements averaged into intervals along a spatial co-ordinate (e.g. binned CTD data).

Cheers, Roy.



>>> John Graybeal <graybeal at mbari.org> 12/18/2006 3:27 pm >>>
A third approach is to offer an additional flag indicating the consistency of the specified sampling interval, for example: guaranteed; dominant; nominal ('best fit'); or 'at will' (whenever circumstances warrant, so ignore the sampling interval field).

In my experience so far (not vast!), the great majority of ocean observations are either nominal or at will, or in the burst pattern you described; only when data is processed and interpolated do I see guaranteed intervals. And then the intervals are often not one of the available options.  So a constrained list of timings is only rarely useful for our data sets, but the additional flag would be very descriptive.

There do appear to be two communities, one of which finds sampling interval a critical discovery metric, and the other of which ignores it.  The principle fallback seems to be to examine the textual metadata or the data itself, neither job delegated to computers (yet).

John

At 8:09 AM +0000 12/18/06, Roy Lowry wrote:
>Hello Michele,
>
>Your e-mail just missed me.  I was in work Friday morning, but not the afternoon so I have just got to look at what you are saying, and what you are saying raises a number of issues.  I will start by giving my views and then see if there are any other viewpoints on the Tech or SeaVox lists - apologies for cross-postings.
>
>To me, the primary purpose of the CDI is for discovery metadata not usage metadata.  It therefore has to provide the user with information to decide whether the data described are of use or not.  It is not meant to fully describe the data in detail.  In the case you describe I can see two possibilities.  One would be to use the existing code that best describe the data (probably '7' in this case).  The other would be to set up a new code for 'variable sampling'.  From the user's viewpoint I would find the approximate approach useful, but the more accurate term useless as it could cover anything from 1Hz burst sampling several times an hour to the kind of scenario you describe with the sediment trap. I am pretty sure that data simply labelled 'variable sampling' would tend not to get forgotten in searches.
>
>Another possible approach would be to start setting up new set of codes to quantify various sampling patterns.  My feelings on this are that we could end up with so many codes that search becomes difficult.  My other worry about this is that it could be considered to be using a vocabulary to overcome limitations in a data model.  The CDI data model specifies a one-to-one relationship between entity and sampling interval.
>
>So, my preference would not be to create an additional code, but to use the 'best fit' existing code.  Any other opinions?
>
>Cheers, Roy.
>
>>>> Michele FICHAUT <Michele.Fichaut at ifremer.fr> 12/15/2006 11:12 am >>>
>Dear Roy,
>
>I am working on the new export of the CDI and checcking the
>compatibility with the libraries.
>IConcerning library 3 I would like to add a code for specifica data that
>we add and
>for which the sampling interval is not constant for the time serie
>duration :
>we have that for sediment traps for example where we can have one week
>between the 2 first
>measuremnets and then one month and then .....
>
>Is it possible to do so?
>
>Regards,
>
>Michèle
>
>--
>                                _
>                              _| |_
>                              (o o)
>___________________________oOO-( )-OOo__________________________________
>Michele FICHAUT - IFREMER/BREST - SISMER - B.P. 70 - 29280 PLOUZANE
>TEL:(33)02.98.22.46.43/(33)02.98.22.49.16 (secr.) FAX:(33)02.98.22.46.44
>Email: Michele.Fichaut at ifremer.fr  WWW : http://www.ifremer.fr/sismer/ 
>________________________________________________________________________
>
>
>
>
>_______________________________________________
>Seavox mailing list
>Seavox at mailman.nerc-liv.ac.uk 
>http://mailman.nerc-liv.ac.uk/mailman/listinfo/seavox 


--
----------
John Graybeal   <mailto:graybeal at mbari.org>  -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Initiative: http://marinemetadata.org   ||  Shore Side Data System: http://www.mbari.org/ssds



More information about the Seavox mailing list