Re: [CF-metadata] proposed standard names for Enterococcus and Clostridium perfringens
On 03/21/2013 02:12 PM, John Maurer wrote: I believe the canonical units in UDUNITS parlance would translate to m-3, which is what I find in the standard name table for other number_concentration_* quantities. Yup. If the dimension of the physical quantity is number per volume, then the SI unit would be m-3. (The problem with the atmospheric surface density quantities is that they need to be convertable with areic amount of substance; consequently, moles and molecules creep in). --Steve ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New standard name: datetime_iso8601
On Thu, Mar 21, 2013 at 1:14 PM, John Caron ca...@unidata.ucar.edu wrote: On 3/21/2013 11:17 AM, Chris Barker - NOAA Federal wrote: On Tue, Mar 19, 2013 at 5:21 PM, Dave Allured - NOAA Affiliate dave.allu...@noaa.gov wrote: You are making a set of technical use specifications, with significant departures from the reference standard ISO 8601. If we do anything with this -- PLEASE, PLEASE, PLEASE simply use the ISO standard! Ive a bit lost track of where folks are proposing to deviate, but what I have seen ( a different default time zone) seems to be a case of my particular application currently uses this standard, so I want CF to match that, which is a really bad idea. If we really need to deviate, I'd say only do it by supporting a subset of ISO (like requiring a TZ spec, for instance), but having the exact same string mean something different in CF than ISO strikes me as a really bad idea! Hi all: Ive always just worked with the W3C profile of ISO8601 http://www.w3.org/TR/NOTE-datetime So theres the question of supporting full ISO8601, or just a profile. In fact, I really just rely on specialized libraries to deal with the subtleties. Unidata is not very interested in spending resources on a problem that has already general solutions but is complex in the corners. Its mostly the non-standard calendars to support models that prevents adopting general libraries. If someone knows what the departures from the reference standard ISO 8601 that CF has already made, please post. the only cases i know of where this might be true is: 1) default timezone 2) filling in non-specified fields with zeroes. John, My remark significant departures from the reference standard ISO 8601 was not in reference to CF, as you implied above. It was referring to Aleksandar's standard name proposal, specifically the current version posted on January 11. This is a very limited subset of all ISO 8601 syntax and functionality: http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056085.html In effect I am saying that if the intent of datetime_iso8601 is to describe something other than the full ISO 8601 standard, then the details need to be agreed on and formally recorded somewhere for CF reference. Does that answer your question, or were you asking about something else? --Dave ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New standard name: datetime_iso8601
On Thu, Mar 21, 2013 at 12:14 PM, John Caron ca...@unidata.ucar.edu wrote: Ive always just worked with the W3C profile of ISO8601 http://www.w3.org/TR/NOTE-datetime So theres the question of supporting full ISO8601, or just a profile. That looks like a good profile to me -- and documented, and well accepted and broadly used? If someone knows what the departures from the reference standard ISO 8601 that CF has already made, please post. Well, I've seen a lot of datetime without the T in between the data and time, which is valid ISO, but not valid in the profile you referenced. This isn't a deviation I know is in use, but I also noticed that in profile referenced, the timezone is specified in hours offset. That could be awkward for local time datasets with Daylight savings time -- no way to express US Pacific time zone, such that DST is accounted for. Granted, DST is a huge pain in the %^#*, so maybe that's a good thing! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New Standard Names for Satellite Data
Hi Aleksandar, I don't think anyone has responded to your email below, so I am responding, in part, so it doesn't get lost in the recent blizzard of emails on other topics :-). I still much prefer the alternative that was proposed: time_sample_interval_due_to_collocation I think this is less ambiguous, will be easier to understand for someone who doesn't know what you are trying to represent, and easier to generalize in the future. I suggest that we tweak the description to improve clarity: The difference in time between two events that are collocated. Two events are deemed to be collocated based on some set of spatial, temporal, and viewing geometry criteria. I also checked on the spelling of 'collocation'.Unfortunately, different dictionaries seem to disagree, with varying support given to: collocation, colocation, and co-location. In the dictionaries I looked at, collocation was often described as a literary term (for two words appearing next to each other), with colocation and co-location often being more clearly defined in the way that we want. But it was not clear cut. Is there consensus in the fields relevant to CF? Best wishes, Philip --- Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab. --- -Original Message- From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Aleksandar Jelenak - NOAA Affiliate Sent: Tuesday, March 19, 2013 8:56 AM To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New Standard Names for Satellite Data Does anyone wants to comment further on the standard name below? It's been almost three weeks since I provided the definition. Standard name: collocation_time_interval Definition: The temporal difference between two measurement events being collocated. Collocation is a process in remote sensing of grouping two independent measurements based on a set of spatial, temporal, and viewing geometry criteria. Units: s -Aleksandar On Wed, Feb 27, 2013 at 1:16 PM, Aleksandar Jelenak - NOAA Affiliate aleksandar.jele...@noaa.gov wrote: On Wed, Jan 16, 2013 at 3:10 PM, Cameron-smith, Philip cameronsmi...@llnl.gov wrote: Hi, Edward, _sample_ seems a good alternative. I still like the idea of _due_to_collocation, since that defines what the interval is about. So how about the following? time_sample_interval_due_to_collocation Philip Philip, Ed -- I apologize for the delay in my reply. It is time to wrap up this discussion. I really like the name collocation_time_interval but if that is not to be my second choice is time_sample_interval_due_to_collocation. Here's the definition I propose: The temporal difference between two measurement events being collocated. Collocation is a process in remote sensing of grouping two independent measurements based on a set of spatial, temporal, and viewing geometry criteria. -Aleksandar ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] proposed standard names for Enterococcus and Clostridium perfringens
Dear All, I see Pandora's Box opening before us. I have been down the road of setting up my equivalent to Standard Names (the BODC Parameter Usage Vocabulary) with concepts that include specification of the biological entity, which is why I have a vocabulary with getting on for 30,000 concepts. So I have things like 'Abundance of species X','Carbon biomass of species X', 'Nitrogen biomass of species X', 'Average specimen length of species X' and so on. In recent discussions within SeaDataNet and the EU ODIP project I have been persuaded that this approach is unsustainable and that what we should be aiming for in these projects is an approach where the Standard Name equivalent is something like 'Abundance of biological entity' and then have a separate metadata element (i.e. variable attribute) for the biological entity that should be related an established taxonomic standard such as WoRMS (http://www.marinespecies.org/). So, which path should CF follow? An additional point is that I would prefer not to have the semantics of what was measured encoded into the units of measure. The way I've approached CFU is through concepts phrased like ' Abundance (colony-forming units) of Vibrio cholerae (WoRMS 395085) per unit volume of the water body' where colony-forming units is a qualifying semantic on abundance (the term I prefer to number_concentration, but I appreciate the precedent in existing Standard Names). So, IF we choose the path of naming the beasties in the standard name my preferred syntax would be: cfu_number_concentration_of enterococcus _in_sea_water with canonical units of m-3 as John suggested. I have copied this response to the SeaDataNet Technical Task Team so they are aware that this issue is being discussed in CF. Cheers, Roy. Please note that I now work part-time from Tuesday to Thursday. E-mail response on other days is possible but not guaranteed! From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Maurer Sent: 21 March 2013 20:12 To: cf-metadata@cgd.ucar.edu Subject: [CF-metadata] proposed standard names for Enterococcus and Clostridium perfringens Aloha CF group, I would like to propose the following standard names related to water quality measurements of the bacteria Enterococcus and Clostridium perfringens: number_concentration_of_enterococcus_in_sea_water number_concentration_of_clostridium_perfringens_in_sea_water These are normally measured with units of CFU/100 mL, where CFU stands for Colony-Forming Unitshttp://en.wikipedia.org/wiki/Colony-forming_unit. I believe the canonical units in UDUNITS parlance would translate to m-3, which is what I find in the standard name table for other number_concentration_* quantities. For descriptions of each, I would propose: number_concentration_of_enterococcus_in_sea_water: Number concentration means the number of particles or other specified objects per unit volume. In this context, it represents the number of colony-forming units (CFU) of bacteria belonging to the genus Enterococcus. This indicator bacteria has been correlated with the presence of human pathogens (disease-causing organisms) and therefore with human illnesses such as gastroenteritis, diarrhea, and various infections in epidemiological studies. As such, it is commonly measured in beach water quality monitoring programs. number_concentration_of_clostridium_perfringens_in_sea_water: Number concentration means the number of particles or other specified objects per unit volume. In this context, it represents the number of colony-forming units (CFU) of bacteria belonging to the species Clostridium perfringens. Because this bacteria is a normal component of the human intestinal tract, its presence in samples of sea water can be used as a tracer of sewage contamination. As such, it is commonly measured in beach water quality monitoring programs. Thanks, John Maurer Pacific Islands Ocean Observing System (PacIOOS) University of Hawaii at Manoa This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] proposed standard names for Enterococcus and Clostridium perfringens
On 03/22/2013 03:57 AM, Lowry, Roy K. wrote: An additional point is that I would prefer not to have the semantics of what was measured encoded into the units of measure. I couldn't agree more. The NIST also agrees. See sections 7.4 and 7.5 of http://physics.nist.gov/Pubs/SP811/sec07.html. --Steve ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] [sdn2-tech] RE: proposed standard names for Enterococcus and Clostridium perfringens
Hi Roy, First off, i thought ICES tried to persuade you way before SDN that this was perhaps not the right approach ;) Anyway, I would agree that the species entity needs to be separated from the 'standard name'. I think discussions in SDN tech about the draft biological format for ODV would also highlight this as a 'must have'. We did however struggle to understand entirely what you mean by having a separate metadata element related to species. What does the metadata element hang-off? If this was to be an attribute of the standard name, then I don't really understand how this decouples the relationship. But if you mean that you would have a variable 'Gadus morhua' that had an attribute 'aphiaID = xxx' then that would be logical. Look forward to hearing what the intention is. Best, Neil From: sdn2-tech-requ...@listes.seadatanet.org [mailto:sdn2-tech-requ...@listes.seadatanet.org] On Behalf Of Lowry, Roy K. Sent: 22. marts 2013 10:58 To: John Maurer; cf-metadata@cgd.ucar.edu Cc: sdn2-t...@listes.seadatanet.org Subject: [sdn2-tech] RE: [CF-metadata] proposed standard names for Enterococcus and Clostridium perfringens Dear All, I see Pandora's Box opening before us. I have been down the road of setting up my equivalent to Standard Names (the BODC Parameter Usage Vocabulary) with concepts that include specification of the biological entity, which is why I have a vocabulary with getting on for 30,000 concepts. So I have things like 'Abundance of species X','Carbon biomass of species X', 'Nitrogen biomass of species X', 'Average specimen length of species X' and so on. In recent discussions within SeaDataNet and the EU ODIP project I have been persuaded that this approach is unsustainable and that what we should be aiming for in these projects is an approach where the Standard Name equivalent is something like 'Abundance of biological entity' and then have a separate metadata element (i.e. variable attribute) for the biological entity that should be related an established taxonomic standard such as WoRMS (http://www.marinespecies.org/). So, which path should CF follow? An additional point is that I would prefer not to have the semantics of what was measured encoded into the units of measure. The way I've approached CFU is through concepts phrased like ' Abundance (colony-forming units) of Vibrio cholerae (WoRMS 395085) per unit volume of the water body' where colony-forming units is a qualifying semantic on abundance (the term I prefer to number_concentration, but I appreciate the precedent in existing Standard Names). So, IF we choose the path of naming the beasties in the standard name my preferred syntax would be: cfu_number_concentration_of enterococcus _in_sea_water with canonical units of m-3 as John suggested. I have copied this response to the SeaDataNet Technical Task Team so they are aware that this issue is being discussed in CF. Cheers, Roy. Please note that I now work part-time from Tuesday to Thursday. E-mail response on other days is possible but not guaranteed! From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Maurer Sent: 21 March 2013 20:12 To: cf-metadata@cgd.ucar.edu Subject: [CF-metadata] proposed standard names for Enterococcus and Clostridium perfringens Aloha CF group, I would like to propose the following standard names related to water quality measurements of the bacteria Enterococcus and Clostridium perfringens: number_concentration_of_enterococcus_in_sea_water number_concentration_of_clostridium_perfringens_in_sea_water These are normally measured with units of CFU/100 mL, where CFU stands for Colony-Forming Unitshttp://en.wikipedia.org/wiki/Colony-forming_unit. I believe the canonical units in UDUNITS parlance would translate to m-3, which is what I find in the standard name table for other number_concentration_* quantities. For descriptions of each, I would propose: number_concentration_of_enterococcus_in_sea_water: Number concentration means the number of particles or other specified objects per unit volume. In this context, it represents the number of colony-forming units (CFU) of bacteria belonging to the genus Enterococcus. This indicator bacteria has been correlated with the presence of human pathogens (disease-causing organisms) and therefore with human illnesses such as gastroenteritis, diarrhea, and various infections in epidemiological studies. As such, it is commonly measured in beach water quality monitoring programs. number_concentration_of_clostridium_perfringens_in_sea_water: Number concentration means the number of particles or other specified objects per unit volume. In this context, it represents the number of colony-forming units (CFU) of bacteria belonging to the species Clostridium perfringens. Because this bacteria is a normal component of the human intestinal tract, its presence in samples of sea water can be used as a tracer of sewage contamination. As
Re: [CF-metadata] [sdn2-tech] RE: proposed standard names for Enterococcus and Clostridium perfringens
Hi, since my knowledge on standard name conventions is limited I am not well placed to give input on the raised request for a new item in the list. However I share the concern to include the biological entity in the Standard Name. Am I wrong If I say that the suggested cfu_number_concentration_of enterococcus _in_sea_water seems to do just that? best regards, Klaas. From: sdn2-tech-requ...@listes.seadatanet.org [mailto:sdn2-tech-requ...@listes.seadatanet.org] On Behalf Of Neil Holdsworth Sent: 22 March 2013 11:42 To: sdn2-t...@listes.seadatanet.org; John Maurer; cf-metadata@cgd.ucar.edu Subject: RE: [sdn2-tech] RE: [CF-metadata] proposed standard names for Enterococcus and Clostridium perfringens Hi Roy, First off, i thought ICES tried to persuade you way before SDN that this was perhaps not the right approach ;) Anyway, I would agree that the species entity needs to be separated from the 'standard name'. I think discussions in SDN tech about the draft biological format for ODV would also highlight this as a 'must have'. We did however struggle to understand entirely what you mean by having a separate metadata element related to species. What does the metadata element hang-off? If this was to be an attribute of the standard name, then I don't really understand how this decouples the relationship. But if you mean that you would have a variable 'Gadus morhua' that had an attribute 'aphiaID = xxx' then that would be logical. Look forward to hearing what the intention is. Best, Neil From: sdn2-tech-requ...@listes.seadatanet.org [mailto:sdn2-tech-requ...@listes.seadatanet.org] On Behalf Of Lowry, Roy K. Sent: 22. marts 2013 10:58 To: John Maurer; cf-metadata@cgd.ucar.edu Cc: sdn2-t...@listes.seadatanet.org Subject: [sdn2-tech] RE: [CF-metadata] proposed standard names for Enterococcus and Clostridium perfringens Dear All, I see Pandora's Box opening before us. I have been down the road of setting up my equivalent to Standard Names (the BODC Parameter Usage Vocabulary) with concepts that include specification of the biological entity, which is why I have a vocabulary with getting on for 30,000 concepts. So I have things like 'Abundance of species X','Carbon biomass of species X', 'Nitrogen biomass of species X', 'Average specimen length of species X' and so on. In recent discussions within SeaDataNet and the EU ODIP project I have been persuaded that this approach is unsustainable and that what we should be aiming for in these projects is an approach where the Standard Name equivalent is something like 'Abundance of biological entity' and then have a separate metadata element (i.e. variable attribute) for the biological entity that should be related an established taxonomic standard such as WoRMS (http://www.marinespecies.org/). So, which path should CF follow? An additional point is that I would prefer not to have the semantics of what was measured encoded into the units of measure. The way I've approached CFU is through concepts phrased like ' Abundance (colony-forming units) of Vibrio cholerae (WoRMS 395085) per unit volume of the water body' where colony-forming units is a qualifying semantic on abundance (the term I prefer to number_concentration, but I appreciate the precedent in existing Standard Names). So, IF we choose the path of naming the beasties in the standard name my preferred syntax would be: cfu_number_concentration_of enterococcus _in_sea_water with canonical units of m-3 as John suggested. I have copied this response to the SeaDataNet Technical Task Team so they are aware that this issue is being discussed in CF. Cheers, Roy. Please note that I now work part-time from Tuesday to Thursday. E-mail response on other days is possible but not guaranteed! From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Maurer Sent: 21 March 2013 20:12 To: cf-metadata@cgd.ucar.edu Subject: [CF-metadata] proposed standard names for Enterococcus and Clostridium perfringens Aloha CF group, I would like to propose the following standard names related to water quality measurements of the bacteria Enterococcus and Clostridium perfringens: number_concentration_of_enterococcus_in_sea_water number_concentration_of_clostridium_perfringens_in_sea_water These are normally measured with units of CFU/100 mL, where CFU stands for Colony-Forming Units. I believe the canonical units in UDUNITS parlance would translate to m-3, which is what I find in the standard name table for other number_concentration_* quantities. For descriptions of each, I would propose: number_concentration_of_enterococcus_in_sea_water: Number concentration means the number of particles or other specified objects per unit volume. In this context, it represents the number of colony-forming units (CFU) of bacteria belonging to the genus Enterococcus. This indicator bacteria has been correlated with the presence of human pathogens
[CF-metadata] Question from NODC about interplay of standard name modifiers, cell_methods, etc.
Dear Ken The cell_methods would indicate standard deviation. This allows you to say whether you mean standard deviation over time, latitude, longitude or whatever dimension, so it's more precise - which one do you mean, in fact? By the way, in cell_methods there should be a space after : e.g. area: mean. Best wishes Jonathan - Forwarded message from Kenneth S. Casey - NOAA Federal kenneth.ca...@noaa.gov - From: Kenneth S. Casey - NOAA Federal kenneth.ca...@noaa.gov Date: Fri, 22 Mar 2013 13:29:11 -0400 To: cf-metadata@cgd.ucar.edu X-Mailer: Apple Mail (2.1499) CC: Tim Boyer tim.bo...@noaa.gov, Ajay Krishnan ajay.kr...@gmail.com Subject: [CF-metadata] Question from NODC about interplay of standard name modifiers, cell_methods, etc. Hi Everyone, At US NODC we are trying to sort out how to best document a gridded dataset that contains a number of variables. For example, we have a sea water temperature gridded dataset, and it contains 6 variables: objectively analyzed mean statistical mean number of observations standard deviation standard error of the mean 'grid points' We are currently documenting, for example, the objective analyzed mean temperature variable in this netCDF file like this: float t_an(time, depth, lat, lon) ; t_an:standard_name = sea_water_temperature ; t_an:long_name = Objectively Analyzed Mean ; t_an:comment = Objectively analyzed climatologies are the objectively interpolated mean fields for an oceanographic variable at standard depth levels for the World Ocean. ; t_an:cell_methods = area:mean depth:mean time:mean ; t_an:grid_mapping = crs ; t_an:units = degrees_celsius ; t_an:FillValue = 9.96921e+36f ; That makes reasonable sense to an application client because the variable contains a temperature value, so the standard_name makes sense. Also, cell methods here represent how the data in the cells are compiled. They do not directly describe the thing in those cells but what kinds of procedures where used (in this case, the grid cell, with time, lat, lon, and depth dimensions, is a computed by calculating mean).We think this is the correct way to represent this particular variable. But what we should do for the statistical variables is less clear. We can use standard name modifiers to provide reasonable standard names, but only four are defined currently: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/apc.html detection_minimum, number_of_observations, standard_error, and status_flag How would we handle the variables like standard deviation? Right now, we could not provide a standard name with a modifier, so we'd have to rely on long_name and comment attributes which is not very satisfactory. We wouldn't want to use t_standard_deviation:standard_name = sea_water_temperature ; because the values in the variable are not sea water temperature, they are the standard deviation of sea water temperature. Is the solution to propose some new standard name modifiers, or are we missing something? This issue seems like it should be a fairly common problem. Thanks, Ken Kenneth S. Casey, Ph.D. Technical Director NOAA National Oceanographic Data Center 1315 East-West Highway Silver Spring MD 20910 301-713-3272 x133 http://www.nodc.noaa.gov ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata - End forwarded message - ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Question from NODC about interplay of standard name modifiers, cell_methods, etc.
Hi Ken, As hoped, Jonathan, has already responded. I'm off on a tangent here ... I want here to comment on a *wee* (and admittedly debatable) side metadata issue -- the proper use of the long_name attribute. The long_name is typically used as the source of a title string for plots and listings. My view is that a long name such as Objectively Analyzed Mean, which names a statistic, but does not name the underlying parameter, creates a bit of a documentation risk. No doubt the global 'title' attribute is expected to fill in the missing context -- stating in this example that this is a Sea Surface Temperature data set. That is probably sufficient for most basic plotting situations. But when one wants to offer automated products, like computed differences between fields (as LAS does), it can become impractical to carry along the title string of each dataset used in a calculation. The number of annotations needed just grows and grows. As Jonathan's answer has implied, annotations about cell_methods are also required. I guess I am lobbying a viewpoint that the long_name attached to each variable should represent a best effort to have each variable self-document who she is. Thus Objectively Analyzed Mean SST would be preferable to Objectively Analyzed Mean. Does this seem reasonable? - Steve === On 3/22/2013 10:29 AM, Kenneth S. Casey - NOAA Federal wrote: Hi Everyone, At US NODC we are trying to sort out how to best document a gridded dataset that contains a number of variables. For example, we have a sea water temperature gridded dataset, and it contains 6 variables: objectively analyzed mean statistical mean number of observations standard deviation standard error of the mean 'grid points' We are currently documenting, for example, the objective analyzed mean temperature variable in this netCDF file like this: float t_an(time, depth, lat, lon) ; t_an:standard_name = sea_water_temperature ; t_an:long_name = Objectively Analyzed Mean ; t_an:comment = Objectively analyzed climatologies are the objectively interpolated mean fields for an oceanographic variable at standard depth levels for the World Ocean. ; t_an:cell_methods = area:mean depth:mean time:mean ; t_an:grid_mapping = crs ; t_an:units = degrees_celsius ; t_an:FillValue = 9.96921e+36f ; That makes reasonable sense to an application client because the variable contains a temperature value, so the standard_name makes sense. Also, cell methods here represent how the data in the cells are compiled. They do not directly describe the thing in those cells but what kinds of procedures where used (in this case, the grid cell, with time, lat, lon, and depth dimensions, is a computed by calculating mean).We think this is the correct way to represent this particular variable. But what we should do for the statistical variables is less clear. We can use standard name modifiers to provide reasonable standard names, but only four are defined currently: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/apc.html detection_minimum, number_of_observations, standard_error, and status_flag How would we handle the variables like standard deviation? Right now, we could not provide a standard name with a modifier, so we'd have to rely on long_name and comment attributes which is not very satisfactory. We wouldn't want to use t_standard_deviation:standard_name = sea_water_temperature ; because the values in the variable are not sea water temperature, they are the standard deviation of sea water temperature. Is the solution to propose some new standard name modifiers, or are we missing something? This issue seems like it should be a fairly common problem. Thanks, Ken Kenneth S. Casey, Ph.D. Technical Director NOAA National Oceanographic Data Center 1315 East-West Highway Silver Spring MD 20910 301-713-3272 x133 http://www.nodc.noaa.gov http://www.nodc.noaa.gov/ https://www.facebook.com/noaa.nodc http://www.facebook.com/feeds/page.php?id=178512945559611format=rss20 http://www.facebook.com/feeds/page.php?id=178512945559611format=rss20 ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Question from NODC about interplay of standard name modifiers, cell_methods, etc.
On Fri, Mar 22, 2013 at 11:05 AM, Jonathan Gregory j.m.greg...@reading.ac.uk wrote: The cell_methods would indicate standard deviation. This allows you to say whether you mean standard deviation over time, latitude, longitude or whatever dimension, so it's more precise - which one do you mean, in fact? I think you need a definition of the cell boundaries also: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#cell-boundaries float t_an(time, depth, lat, lon) ; t_an:standard_name = sea_water_temperature ; t_an:long_name = Objectively Analyzed Mean ; t_an:comment = Objectively analyzed climatologies are the objectively interpolated mean fields for an oceanographic variable at standard depth levels for the World Ocean. ; t_an:cell_methods = area:mean depth:mean time:mean ; t_an:grid_mapping = crs ; t_an:units = degrees_celsius ; t_an:FillValue = 9.96921e+36f ; from this, I can tell that the value is a mean over area, depth and time -- but what area? what depths? what time? I'd probably assume the area of a single grid box (though that's not totaly defined here, and probaly the full water depth, but I'm not at all sure about time: mean over one time step? monthly mean? yearly? this brings u sa question for me: how would one define a cell bounds that was the full water depth. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Question from NODC about interplay of standard name modifiers, cell_methods, etc.
Steve,It is a good point you make and we can revisit our long_names used in this product (our netCDF files are still in development). I think the parameter like sea water temperature (it is not actually SST) was left out since there are many of these files, each with a different parameter (Salinity, dissolved oxygen, etc.) and the code used to write the attributes probably didn't account for that. Jonathan,Thanks for your response too (copied here… is it bad form in a listserv to consolidate responses like this?)Dear Ken The cell_methods would indicate standard deviation. This allows you to say whether you mean standard deviation over time, latitude, longitude or whatever dimension, so it's more precise - which one do you mean, in fact? By the way, in cell_methods there should be a space after ":" e.g. "area: mean". Best wishes JonathanThat answer seems so easy and obvious that I wonder if I asked the question properly! I'll have to ask Tim to be sure, but I think the standard deviation is the standard deviation over time, of means generated in each time-area-depth cell. Thanks also for noticing the missing space. But I think the question still remains about being able to use a standard name, which we would like to do of course… I am pretty sure in this example for this standard deviation variable we should NOT use sea_water_temperature for standard_name, and that it would be good if there were more standard name modifiers to choose from. If there were, perhaps we could set standard name to something like "sea_water_temperature standard_deviation".KenOn Mar 22, 2013, at 2:22 PM, Steve Hankin steven.c.han...@noaa.gov wrote: Hi Ken, As hoped, Jonathan, has already responded. I'm off on a tangent here ... I want here to comment on a wee (and admittedly debatable) side metadata issue -- the proper use of the "long_name" attribute. The long_name is typically used as the source of a title string for plots and listings. My view is that a long name such as "Objectively Analyzed Mean", which names a statistic, but does not name the underlying parameter, creates a bit of a documentation risk. No doubt the global 'title' attribute is expected to fill in the missing context -- stating in this example that this is a Sea Surface Temperature data set. That is probably sufficient for most basic plotting situations. But when one wants to offer automated products, like computed differences between fields (as LAS does), it can become impractical to carry along the title string of each dataset used in a calculation. The number of annotations needed just grows and grows. As Jonathan's answer has implied, annotations about cell_methods are also required. I guess I am lobbying a viewpoint that the long_name attached to each variable should represent a best effort to have each variable self-document who she is. Thus "Objectively Analyzed Mean SST" would be preferable to "Objectively Analyzed Mean". Does this seem reasonable? - Steve === On 3/22/2013 10:29 AM, Kenneth S. Casey - NOAA Federal wrote: Hi Everyone, At US NODC we are trying to sort out how to best document a gridded dataset that contains a number of variables. For example, we have a sea water temperature gridded dataset, and it contains 6 variables: objectively analyzed mean statistical mean number of observations standard deviation standard error of the mean 'grid points' We are currently documenting, for example, the objective analyzed mean temperature variable in this netCDF file like this: float t_an(time, depth, lat, lon) ; t_an:standard_name = "sea_water_temperature" ; t_an:long_name = "Objectively Analyzed Mean" ; t_an:comment = "Objectively analyzed climatologies are the objectively interpolated mean fieldsfor an oceanographic variable at standard depth levels for the World Ocean." ; t_an:cell_methods = "area:mean depth:mean time:mean" ; t_an:grid_mapping = "crs" ; t_an:units = "degrees_celsius" ; t_an:FillValue = 9.96921e+36f ; That makes reasonable sense to an application client because the variable contains a temperature value, so the standard_name makes sense. Also,cell methods here represent how the data in the cells are compiled. They do notdirectly describe the "thing" in those cells but what kinds of procedures where used (in this case, the grid cell, with time, lat, lon, and depth dimensions, is a computed by calculating mean). We think this is the correct way to representthis particular variable. But what we
Re: [CF-metadata] Question from NODC about interplay of standard name modifiers, cell_methods, etc.
Chris,On Mar 22, 2013, at 3:38 PM, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote:On Fri, Mar 22, 2013 at 11:05 AM, Jonathan Gregoryj.m.greg...@reading.ac.uk wrote:The cell_methods would indicate standard deviation. This allows you to saywhether you mean standard deviation over time, latitude, longitude or whateverdimension, so it's more precise - which one do you mean, in fact?I think you need a definition of the cell boundaries also:http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#cell-boundariesThanks… I think we have those in the actual files already and I was only copying and pasting a subset of the info. We'll double check to make sure they are in there. I know we include in our NODC netCDF templates the recommendation to include the bounds attribute pointing to the variables containing the bounds (seehttp://www.nodc.noaa.gov/data/formats/netcdf/, for grids here is the NODC CDL template:http://www.nodc.noaa.gov/data/formats/netcdf/grid.cdl) and we are following our own templates :-) float t_an(time, depth, lat, lon) ; t_an:standard_name = "sea_water_temperature" ; t_an:long_name = "Objectively Analyzed Mean" ; t_an:comment = "Objectively analyzed climatologies are the objectively interpolated mean fields for an oceanographic variable at standard depth levels for the World Ocean." ; t_an:cell_methods = "area:mean depth:mean time:mean" ; t_an:grid_mapping = "crs" ; t_an:units = "degrees_celsius" ; t_an:FillValue = 9.96921e+36f ;from this, I can tell that the value is a mean over area, depth andtime -- but what area? what depths? what time?I'd probably assume the area of a single grid box (though that's nottotaly defined here, and probaly the full water depth, but I'm not atall sure about time: mean over one time step? monthly mean? yearly?As I mentioned we do (I think) already include the specific bounds, but note that each of these files contains data for a specific temporal period either monthly, seasonally, or annually. this brings u sa question for me: how would one define a cell boundsthat was "the full water depth".Good question… if you had a variable that was for example the mean temperature in 1 deg by 1 deg by full water depth cell, you would have a two-D gridded data variable (dims of lat and lon). I think you would then have a bounds attribute that would point to your lat- and lon- bounds (easy enough) variables, and then a z-bounds variable that would specify the depth of the water column in each grid cell? Hmmm… but something seems off with that because depth is not a coordinate variable in the case of a two-dimensional grid. Ken-Chris-- Christopher Barker, Ph.D.OceanographerEmergency Response DivisionNOAA/NOS/ORR (206) 526-6959 voice7600 Sand Point Way NE (206) 526-6329 faxSeattle, WA 98115 (206) 526-6317 main receptionchris.bar...@noaa.gov___CF-metadata mailing listCF-metadata@cgd.ucar.eduhttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata Kenneth S. Casey, Ph.D.Technical DirectorNOAA National Oceanographic Data Center1315 East-West HighwaySilver Spring MD 20910301-713-3272 x133http://www.nodc.noaa.gov ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New standard name: datetime_iso8601
Hi all, I'm a bit late to the discussion, but I just want to go on the record as being (fairly strongly) opposed to allowing *anything* to be expressed as a string if there's a reasonable numeric representation we can use instead. Maybe I'll change my mind after the community has made the jump to netcdf4, but dealing with string data as arrays of chars under netcdf classic is a gigantic pain, and I want to minimize the amount of data that I might ever have to interact with that does that. And with regard to coordinate variables in particular, if I'm writing a script to analyze some data, I'll often want to do something (e.g., select data) that involves dealing with the coordinate as a numeric value. And in most of the processing environments I can think of, parsing a string to convert it into a number is a lot more effort than printing a date string based on a numeric representation. I'd much prefer only needing to do the latter. Cheers, --Seth Im proposing that time coordinates may be expressed as strings, in addition to the current way of using time offsets from a base date expressed as a string in the unit attribute. The two date string syntaxes (standalone and in the unit attribute) c/should be the same. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New Standard Names for Satellite Data
Hi Philip, On Fri, Mar 22, 2013 at 3:48 AM, Cameron-smith, Philip cameronsmi...@llnl.gov wrote: I don't think anyone has responded to your email below, so I am responding, in part, so it doesn't get lost in the recent blizzard of emails on other topics :-). Thank you very much! I was getting worried the other standard names I proposed will not get much attention. Perhaps that is a good thing? ;-) I still much prefer the alternative that was proposed: time_sample_interval_due_to_collocation Fine with me. I suggest that we tweak the description to improve clarity: The difference in time between two events that are collocated. Two events are deemed to be collocated based on some set of spatial, temporal, and viewing geometry criteria. Fine. I also checked on the spelling of 'collocation'.Unfortunately, different dictionaries seem to disagree, with varying support given to: collocation, colocation, and co-location. In the dictionaries I looked at, collocation was often described as a literary term (for two words appearing next to each other), with colocation and co-location often being more clearly defined in the way that we want. But it was not clear cut. Is there consensus in the fields relevant to CF? collocation is used in satellite remote sensing. For example,: http://en.wikipedia.org/wiki/Collocation_(remote_sensing) With this all issues about this standard name are resolved. Can I assume this name is accepted? -Aleksandar ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New Standard Names for Satellite Data
Agree 'collocation' is dominant in my experience as well. Note the name says interval, but the definition says difference. To me the term 'difference' is more appropriate, as 'interval' has a connotation of recurrence. That said, if no one else finds this worth emphasizing, I'll concur with the alternative, time_sample_interval_due_to_collocation. John On Mar 22, 2013, at 13:55, Aleksandar Jelenak - NOAA Affiliate aleksandar.jele...@noaa.gov wrote: Hi Philip, On Fri, Mar 22, 2013 at 3:48 AM, Cameron-smith, Philip cameronsmi...@llnl.gov wrote: I don't think anyone has responded to your email below, so I am responding, in part, so it doesn't get lost in the recent blizzard of emails on other topics :-). Thank you very much! I was getting worried the other standard names I proposed will not get much attention. Perhaps that is a good thing? ;-) I still much prefer the alternative that was proposed: time_sample_interval_due_to_collocation Fine with me. I suggest that we tweak the description to improve clarity: The difference in time between two events that are collocated. Two events are deemed to be collocated based on some set of spatial, temporal, and viewing geometry criteria. Fine. I also checked on the spelling of 'collocation'.Unfortunately, different dictionaries seem to disagree, with varying support given to: collocation, colocation, and co-location. In the dictionaries I looked at, collocation was often described as a literary term (for two words appearing next to each other), with colocation and co-location often being more clearly defined in the way that we want. But it was not clear cut. Is there consensus in the fields relevant to CF? collocation is used in satellite remote sensing. For example,: http://en.wikipedia.org/wiki/Collocation_(remote_sensing) With this all issues about this standard name are resolved. Can I assume this name is accepted? -Aleksandar ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata John Graybealmailto:jgrayb...@ucsd.edu phone: 858-534-2162 Product Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New Standard Names for Satellite Data
On Fri, Mar 22, 2013 at 5:03 PM, John Graybeal jgrayb...@ucsd.edu wrote: Note the name says interval, but the definition says difference. To me the term 'difference' is more appropriate, as 'interval' has a connotation of recurrence. Nice catch! Yes, difference sounds better to me, too. So: time_sample_difference_due_to_collocation ? -Aleksandar ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New standard name: datetime_iso8601 (Seth McGinnis)
Dear Seth, I believe your concerns nicely confirm Michael's and my viewpoint that the real issue is a lack of functionality in the underlying netcdf library. If done properly, the datetime representation in the file would of course be numerical (python and certainly most other languages will do this also). Tools like ncdump or ncgen (and of course the library APIs) would then be used to obtain the string representation. Best regards, Martin Message: 2 Date: Fri, 22 Mar 2013 14:31:47 -0600 From: Seth McGinnis mcgin...@ucar.edu To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard name: datetime_iso8601 Message-ID: web-45204...@mail.ucar.edu Content-Type: text/plain;charset=utf-8 Hi all, I'm a bit late to the discussion, but I just want to go on the record as being (fairly strongly) opposed to allowing *anything* to be expressed as a string if there's a reasonable numeric representation we can use instead. Maybe I'll change my mind after the community has made the jump to netcdf4, but dealing with string data as arrays of chars under netcdf classic is a gigantic pain, and I want to minimize the amount of data that I might ever have to interact with that does that. And with regard to coordinate variables in particular, if I'm writing a script to analyze some data, I'll often want to do something (e.g., select data) that involves dealing with the coordinate as a numeric value. And in most of the processing environments I can think of, parsing a string to convert it into a number is a lot more effort than printing a date string based on a numeric representation. I'd much prefer only needing to do the latter. Cheers, --Seth Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New Standard Names for Satellite Data
-Original Message- From: Aleksandar Jelenak - NOAA Affiliate [mailto:aleksandar.jele...@noaa.gov] Sent: Friday, March 22, 2013 2:06 PM To: John Graybeal Cc: Cameron-smith, Philip; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New Standard Names for Satellite Data On Fri, Mar 22, 2013 at 5:03 PM, John Graybeal jgrayb...@ucsd.edu wrote: Note the name says interval, but the definition says difference. To me the term 'difference' is more appropriate, as 'interval' has a connotation of recurrence. Nice catch! Yes, difference sounds better to me, too. So: time_sample_difference_due_to_collocation ? -Aleksandar Fine with me. In practice, I consider a standard name to be 'accepted' once Alison says so (it should show up on the CF website shortly afterwards). However, if several weeks have passed, and there are no outstanding concerns, then it usually ends up being accepted. Best wishes, Philip --- Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab. --- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] [sdn2-tech] RE: proposed standard names for Enterococcus and Clostridium perfringens
I think the other obvious concern is that you could no longer use the standard name as the be-all and end-all of searching for comparable data. If the entity of interest, say the species, is in an auxiliary term, the search has to magically connect the standard name with the auxiliary term, which requires more custom search capabilities than are currently widespread. On Mar 22, 2013, at 16:36, Cameron-smith, Philip cameronsmi...@llnl.gov wrote: Hi, I would have no idea of what CFU was, so I suggest it be spelled out if it is used in a std_name. We had a very similar discussion when atmospheric chemicals started to be included in CF std_names. In that case it was decided to include them one-by-one, and defer the discussion until the current system stopped working. In defense of that decision it has worked OK: once the pattern has been established, new std_names with different species get approved fairly quickly. There were complications with doing it as you suggest. I think those objections could have been overcome, but it would have required work and changes to CF. I have a dream that this capability will become part of CF2.0 someday :-). The two main problems that I recall were 'green dogs', ie names that would be allowed but nonsensical (eg mass of CO2 expressed as nitrogen, or surface area of O3), and the CF convention would need to be formally altered (and the discussion eventually ran out of steam). I believe that 'green dogs' are 'red herrings', ie even if a 'green dog' is allowed, no user would ever actually use it. Hence this is not a problem. Changes to the CF convention seem to be going faster now, but they still take time and effort. Good luck, Philip --- Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab. --- -Original Message- From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Alessandra Giorgetti Sent: Friday, March 22, 2013 8:42 AM To: sdn2-t...@listes.seadatanet.org Cc: cf-metadata@cgd.ucar.edu; Klaas Deneudt; 'John Maurer' Subject: Re: [CF-metadata] [sdn2-tech] RE: proposed standard names for Enterococcus and Clostridium perfringens Dear all, I want to underline that also in the chemical lot, for contaminants in biota as an example, we have a similar issue like the biological one. We would like to keep Standard Name from the species name separated. So, I agree with Neil when saying 'Anyway, I would agree that the species entity needs to be separated from the ‘standard name’. I think discussions in SDN tech about the draft biological format for ODV would also highlight this as a ‘must have’.' We look forward in the discussion. With kind regards, Alessandra and Matteo -- Alessandra Giorgetti Istituto Nazionale di Oceanografia e di Geofisica Sperimentale-OGS Sezione di Oceanografia - OCE National Oceanographic Data Center/IOC - NODC Borgo Grotta Gigante 42/c, 34010 Sgonico, Trieste (ITALY) Phone: +39 040 2140391 Mobile: +39 320 4644653 Fax: +39 040 2140266 E-mail: agiorge...@ogs.trieste.it The NODC site with free data access http://nodc.ogs.trieste.it/ Il 22/03/2013 16:15, Lowry, Roy K. ha scritto: Hi Klaas, What I was trying to say in my e-mail to CF was that I strongly suggest that CF decouples the Standard Name from the species name. However, should they choose not to then the cfu semantics should be removed from the units of measure into the Standard Name. The example you quote is what I would suggest should - unfortunately in my current view - CF choose to include species names in Standard Names. Apologies if I didn't make this clear. Cheers, Roy. From: Klaas Deneudt [klaas.dene...@vliz.be] Sent: 22 March 2013 15:06 To: sdn2-t...@listes.seadatanet.org; 'John Maurer'; cf-metadata@cgd.ucar.edu Subject: RE: [sdn2-tech] RE: [CF-metadata] proposed standard names for Enterococcus and Clostridium perfringens Hi, since my knowledge on standard name conventions is limited I am not well placed to give input on the raised request for a new item in the list. However I share the concern to include the biological entity in the Standard Name. Am I wrong If I say that the suggested cfu_number_concentration_of enterococcus _in_sea_water seems to do just that? best regards, Klaas. From: sdn2-tech-requ...@listes.seadatanet.org [mailto:sdn2-tech-requ...@listes.seadatanet.org] On Behalf Of Neil Holdsworth Sent: 22 March 2013 11:42 To: sdn2-t...@listes.seadatanet.org; John Maurer; cf-metadata@cgd.ucar.edu Subject: RE: [sdn2-tech] RE: [CF-metadata] proposed standard names for Enterococcus and Clostridium perfringens Hi Roy, First off, i thought ICES tried to
