[GO-ESSP] Proposed netCDF attribute convention for dataset discovery

[Ethan Davis]

Hi Bryan,

Bryan Lawrence wrote:

>Hi Ethan
>
>I've been meaning to reply to this ... so reminding me by sending it to 
>GO-ESSP was a good thing :-)
>
>Firstly, I think this is a good idea.
>
>I only have one tiny reservation with the syntax, and that's where you use a 
>controlled vocab, I think you should indicate the domain first then the 
>vocab. So, for cdm_data_type, I think it would be better to make it
>cdm_domain: data type namespace
>cdm_data_type: from the namespace enumeration
>  
>
There are three places we do this kind of thing.
1) "keywords" and "keywords_vocabulary"
2) "standard_name" and "standard_name_vocabulary"
3) "cdm_data_type" and "cdm_domain" (OR maybe "data_type" and 
"data_type_domain")

First off, I like the use of "domain" better than "vocabulary", I think 
I'll switch to that with keywords and standard names.
Second, any thoughts on how/if to allow the use of keywords or standard 
names from multiple domains?
Third, any thoughts on enumerating the domains? (I.e., it would be great 
if everyone used the same domain ID to indicate a given domain.)

The "cdm" in "cdm_data_type" stands for the Common Data Model. So, that 
is the domain we were targeting though the enumeration is actually 
defined in the THREDDS catalog spec. Generalizing to "data_type_domain" 
would open it up to CSML feature types and such. So, I'll change these 
to "datatype" and "datatype_domain".

>A more generic issue that is not solved by dublin core (which I can see the 
>influence of in what you have), is that we need to think about authorship for 
>data (and metadata). I would like us to be able to get to a position where 
>the creator(s) of the data corresponded to authors in the traditional sense 
>with contributors perhaps being the folk who did the metadata etc ...
>(not solved in the sense that it doesn't give guidance).
>  
>
Yes, a few others have brought up metadata authorship as well.

>Anyway I plan (which means it may not happen) to write down some thoughts on 
>authorship in this context, but I'd be interested in what you think and how 
>you would play this in your proposed conventions.
>  
>
I haven't really thought about how to deal with this. Our target was 
focused on discribing the data rather than the metadata. Dublin Core is 
pretty specific that it applies to the content or the life cycle of the 
resource not the metadata. FGDC, on the other hand, has a metadata 
information section. Of course, since the proposed nc attributes are 
part of the dataset, the line gets kind of blurry.

So, currently, I don't think THREDDS or these nc attributes really deal 
with describing the metadata (and certainly weren't designed with that 
in mind). Though, you could use the contributor role to specify metadata 
authorship. But to really deal with this well we would have to extend 
this convention and the THREDDS metadata model.

Well, guess we'll have to think on this more.

Ethan

>Cheers,
>Bryan
>
>
>
>
>
>On Tuesday 21 June 2005 23:39, Ethan Davis wrote:
>  
>
>>Hi all,
>>
>>Sorry I forgot to include GO-ESSP in the original distribution of this.
>>(And sorry to those who got multiple copies for cross-posting to so many
>>lists.)
>>
>>We've been working on drafting a document for a netCDF attribute
>>convention to help facilitate dataset discovery. The attributes parallel
>>the "digital library metadata" defined in the THREDDS catalog
>>specification
>>(http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.h
>>tml).
>>
>>The attributes will be used by THREDDS tools to extract metadata from
>>datasets and export to Dublin Core, DIF, ADN, FGDC, ISO 19115, etc.
>>Here's the link to the document:
>>
>>http://www.unidata.ucar.edu/packages/netcdf-java/formats/DataDiscoveryAttCo
>>nvention.html
>>
>>We would appreciate your thoughts and comments.
>>
>>Thanks,
>>
>>Ethan
>>    
>>
>
>  
>

-- 
Ethan R. Davis                                Telephone: (303) 497-8155
Software Engineer                             Fax:       (303) 497-8690
UCAR Unidata Program Center                   E-mail:    edavis at ucar.edu
P.O. Box 3000
Boulder, CO  80307-3000                       http://www.unidata.ucar.edu/
---------------------------------------------------------------------------