Re: [CF-metadata] standard names for stations
Dear All, I would suggest some fine tuning of this to: platform_name platform_id (note this needs to be alphanumeric to support ICES ship codes widely used in oceanography) platform_id_authority (mandatory if platform_id present) platform_description I wonder if the concept of authority is relevant to names - who is the authority for a ship's name? Even if relevant, there is no guarantee that the authority will be the same as the platfom_id and somebody will want to include both a name and an id. If people feel that a name authority is required then I would label it platform_name_authority rather than having one name doing two jobs. The nature of the platform dscription merits a little discussion. Controlled terms, particularly if accompanied by definitions, are always much more helpful than plaintext. There is an internationally-governed platform type vocabulary used in the SeaDataNet and ICES systems (http://vocab.ndg.nerc.ac.uk/list/L06). There is also at least one relevant WMO vocabulary (VOS types). If formalisation of the description is agreed then we could either keep 'platform_description' for plaintext and add 'platform_type' plus 'platform_type_authority' or standardise 'platform_description' by adding 'platform_description_authority'. Finally, I think we need to agree how an authority is represented. My choice would be a namespace URL, but maybe there are other ideas. Cheers, Roy. From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jeffrey F. Painter [paint...@llnl.gov] Sent: 27 August 2011 01:27 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] standard names for stations It seems to me that we would need four standard_names to satisfy everyone's needs. How does this sound? platform_name: variable of character type containing a character ID or name of an observing station or other platform platform_id: variable of integer type, identifying an observing station or other platform platform_naming_authority: variable of character type, specifying the naming authority or system used to choose a platform_id or platform_name platform_description: variable of character_type which describes an observing station or other platform A typical station would have a platform_name or platform_id, but rarely both. The reason for having both is that I expect that the numerical WMO identifiers (of various lengths) will be used very frequently, and it can be helpful to represent numbers as numbers. But Eiji's message shows that we must allow for character identifiers. A relatively short character identifier would have a different function from the kind of long description suggested by Øystein. The most common platform_naming_authority would be the originally conceived "WMO", of course. - Jeff On 8/26/11 12:36 AM, Øystein Godøy wrote: >> Date: Wed, 24 Aug 2011 16:26:55 -0700 >> From: "Jeffrey F. Painter" >> Subject: [CF-metadata] standard names for stations >> To: cf-metadata >> Message-ID:<4e5588bf.2090...@llnl.gov> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> The draft version 1.6 of the CF Conventions manual recommends use of > two >> standard names which don't exist yet but are needed to describe discrete >> data such as observations from stations or other discrete points. So >> I'd like to propose the following two standard names: >> >> - station_description : variable of character type containing a >> description of a time series station >> - wmo_platform_id : variable of integer type, containing the WMO >> identifier of an observing station or other platform >> >> - Jeff Painter > Hi, > > I clearly see the need for this. > > Concerning station_description, I think this is useful whether it is a time > series or not. There is a need to describe the actual location for the > station. E.g. describe the surface, horizon, and other aspects that may affect > the observations. > > Concerning wmo_platform_id, I think Nan Galbraiths suggestion using an id > and a naming authority is useful and more flexible than specifying a WMO > reference directly. Concerning my institution, all stations operated by us, > whether being WMO stations or not, always have an internal ID. Not all > stations have a WMO id. It may even be useful to be able to use multiple ids > for stations to cover situations like the one I mention. > > NACCD is good but it does not have the momentum that CF has. Many other > such discovery conventions for NetCDF files exist and are used, most of > course differing only slightly. I believe they will merge in time, but for now > I think NACDD is less used than CF. I certainly agree it should be promoted > (and we will probably move towards it), but these things take time. > > Thus I would prefer put as much information as possible as CF-compliant > variables in the dataset, even if it means duplicating them as global > attributes for discovery purposes. > > All the
Re: [CF-metadata] A question regarding standard names
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. We'll be sure to take a good look at your vocabularies, Roy. I particularly recall the methodology vocabulary -- that seems closest to a pure answer to Jim's original question. (The instrument 'type' in :MBARI's SSDS was much more coupled to manufacturing practices -- "CTD" for example describing the type of configuration one can buy, and not much about methodology of a particular measurement.) We'll also have to create or use an instrument description specification like yours, Nan. Can you tell me, what is instrument_reference? 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? 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.. John 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-boun...@cgd.ucar.edu > [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Nan Galbraith > Sent: 26 August 2011 14:58 > To: cf-metadata@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. >> >> -Original Message- >> From: cf-metadata-boun...@cgd.ucar.edu >> [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jim Biard >> Sent: 26 August 2011 13:28 >> To: cf-metadata@cgd.ucar.edu >> Subject: [CF-metadata] A question regarding standard names >> >> Hi. >> >> I've got a general question regarding standard names. I have had people >> I work with asking whether it would be acceptable to have a standard >> name that included methodology, such as microwave_brightness_temperature >> as opposed to infrared_brightness_temperature. My feeling has been that >> standard names are not supposed to have such differentiators, but I >> haven't read anything that states that directly. Are standard names for >> measurements limited to "essential" descriptions, or can they include >> specification of the way the measurement was acquired? >> >> Grace and peace, >> >> Jim Biard >> > > > -- > ***
