Upendra et al.,
Great discussions... I would not however classify ACDD's bounding box elements as in conflict with the grid_mapping or even the actual dimension information... remembering its intent, those geospatial_lat_min, max, and lon min an max, are really just a convenience for those automated search tools... with those in there, a quick search of geospatial information can get you closer to the data you want... there are of course MANY limitations of the bounding box concept: satellite swaths don't follow simple boxes like this... collections of individual ocean profiles are not well described by drawing a box around them all, etc. But all that is "ok" in my mind because the use of attributes like these tends to support primarily that first level of collection discovery... not necessarily even down to a more granule level (though of course they can help there too depending on the nature of the granules). In terms of Upendra's example of a netCDF (CF) file with variables that have multiple grid mappings, I would s
imply put the bounding box around the outermost perimeter of those and move on to the next problem.
Steve pointed out that there is the potential for conflict when it comes to redundant information.. since for example the bounding box of a data set could be computed from its dimension variables. I am not worried about this - after all, the first version of GHRSST (the GDS1) used "northernmost_latitiude", etc., for years and I never heard of it causing problems for applications. Jean-Francois and others have pointed out how they built applications that rely on those attributes and that they find them essential. The question GHRSST was grappling with was simply whether to rename the old attributes to the ACDD names or not (at this point, we've decided to stick with 4 of the old attribute names - the four bounding box ones, and also use two non-ACDD time attributes, start_time and stop_time, but then include a bunch of other ACDD attributes. So GHRSST is moving forward with maybe 75% of the ACDD names, just guessing on that percentage).
Would or could CF contemplate incorporating ACDD elements into the CF standard? Does anyone think that Unidata would mind, since the ACDD is "theirs"??? CF would then evolve slightly to do both "use" metadata and "discovery" metadata.
Ken
p.s. - I cc'd some folks who were dropped off some of the earlier responses.
On Jul 14, 2010, at 10:19 AM, Upendra.Dadi at noaa.gov wrote:
> I agree with Nan. With ACDD it could sometimes be difficult to get feedback on the issues you have. We have had similar issues as those mentioned by Nan. Some attributes are ambiguous. Also, I found some minor conflicts with CF conventions. To give an example, CF requires the grid_mapping attribute to be part of the variable. This implies, I could potentially have two variables with different grid_mapping in the same file. But ACDD required the bounding box to be global attribute. Bounding box is related to grid_mapping. Of course, it is rare to find multiple grid_mappings in the same file, but then CF allows it and ACDD doesn't.
>
> ACDD is still in version 1.0, hopefully it gets better as we move
>
> Upendra
>
> ----- Original Message -----
> From: Nan Galbraith <ngalbraith at whoi.edu>
> Date: Wednesday, July 14, 2010 9:36 am
> Subject: Re: [CF-metadata] Use of ACDD metadata: dioes this break the CF convention and what are the implications
>
>>
>> It does seem that CF and ACDD don't overlap and can complement
>> each other; we're moving towards using both in the oceansites
>> project.
>> The problem is that there does not seem to be any public discussion of
>> how these work together, or who will make sure they continue to work
>> together without collisions. Is it really never going to be an issue?
>>
>> ACDD may only intend to provide guidance, but it seems it's being
>> adoptedfairly widely as a standard. Its main drawback is that it
>> has no public
>> forum,
>> like the CF list, to help users implement it or to get feedback on
>> problems.
>> I've asked several questions about the ACDD over the past 3 years,
>> usingthe email link on the web page, but have never gotten a reply.
>>
>> One example - the hard wired role of "creator" is too vague for in
>> situ
>> data;
>> is it the PI who collected the data? Someone who changed a single
>> attributein a file? Guidance on the keywords is sparse, and this
>> is listed as
>> being in
>> development - which, I would hope, would involve some public
>> discussion.
>> - Nan
>>
>>
>>>
>>>
>>> Kenneth Casey wrote:
>>>> Craig - to be absolutely clear: the ACDD attributes in no way
>>>> conflict with CF. They just provide some recommendations on
>> what
>>>> names to use for some attributes. Using a common set of
>> attribute
>>>> names enables us to build tools around those attributes that
>> work
>>>> well across different data sets. Within NOAA for example there
>> is a
>>>> project called the Unified Access Framework that has linked
>> together
>>>> dozens of disparate THREDDS Data Servers through a single
>> THREDDS
>>>> catalog. The larger number of data sets in that catalog that
>> use the
>>>> ACDD the easier it is to build and maintain a dynamic crawler to
>>>> update that catalog on a regular interval. Also, it becomes
>> possible
>>>> to extract automatically ISO "discovery level" metadata and feed
>> it
>>>> into standard search mechanisms thereby making it possible to
>> find
>>>> what you want amidst that sea of information. Other groups have
>> built
>>>> tools to automatically crawl these attributes to assess the data
>> in
>>>> terms of it's metadata robustness. That knowledge is useful for
>> a
>>>> variety of purposes.
>>>>
>>>> I will be interested to hear what folks on this list have to say
>>>> about CF "taking up" the ACDD recommendations. That might be
>> fine but
>>>> I am not sure it is necessary. ACDD is focused purely on
>> improving
>>>> discovery. CF focuses on other things like usability and
>>>> understanding, at least as far as I understand it.
>>>>
>>>> Ken
>>>>
>>>> --
>>>>
>>>>
>>>> On Jul 10, 2010, at 5:38 AM, Craig Donlon <craig.donlon at esa.int
>>>> <mailto:craig.donlon at esa.int>> wrote:
>>>>
>>>>> Dear all:
>>>>> CF is quite light on global metadata and metadata suitable for
>> data
>>>>> discovery and interoperability. Within the Group for High
>>>>> Resolution Sea Surface Temperature (GHRSST, see
>>>>> http://www.ghrsst.org) we are updating our product technical
>>>>> specifications (GDS) documentation. We want to provide more
>>>>> flexibility and interoperability with our products in a
>> 'future
>>>>> proof' manner. GHRSST is handling 25Gb data per day in an
>>>>> international context with many thousands of files in NRT.
>>>>>
>>>>> Our latest specs. have included the NetCDF Attribute Convention
>> for
>>>>> Dataset Discovery
>>>>> (ACDD http://www.unidata.ucar.edu/software/netcdf-
>> java/formats/DataDiscoveryAttConvention.html)
>>>>> and this has raised some questions about our CF compliance. I
>>>>> realise that CF allows extensions, but what I am asking for is
>> some
>>>>> guidance on the future aspirations of CF for discovery
>> metadata. I
>>>>> like the ACDD recommendations and Ideally, I would like to be
>> able
>>>>> to write in our GHRSST data products that we are fully CF
>> compliant.
>>>>> Does the CF community anticipate taking up the
>>>>> ACDD recommendations in the near future? What
>>>>> are peoples thoughts on CF and improved metadata discovery?
>>>>>
>>>>> I look forward to your comments and advice,
>>>>>
>>>>> Best regards
>>>>> Craig Donlon (Chair of the GHRSST International Science Team)
>>
>> --
>> *******************************************************
>> * Nan Galbraith (508) 289-2444 *
>> * Upper Ocean Processes Group Mail Stop 29 *
>> * Woods Hole Oceanographic Institution *
>> * Woods Hole, MA 02543 *
>> *******************************************************
>>
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
[NOTE: The opinions expressed in this email are those of the author alone and do not necessarily reflect official NOAA, Department of Commerce, or US government policy.]
Kenneth S. Casey, Ph.D.
Technical Director
NOAA National Oceanographic Data Center
1315 East-West Highway
Silver Spring MD 20910
301-713-3272 ext 133
http://www.nodc.noaa.gov/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20100714/fd783d2e/attachment-0002.html>
Received on Wed Jul 14 2010 - 09:18:53 BST
