[Esip-documentation] ACDD date attributes question

Sun Oct 5 20:41:44 EDT 2014

Jim, thanks for introducing these use case questions, very helpful now with the context of some responses.

I really appreciate seeing the ISO DateTypeCodes, Ted. Can you provide definitions for each of the DateTypeCodes? I find the names difficult to distinguish (revision, lastUpdate, lastRevision; creation, inForce, validityBegins; publication, distribution). I'm hoping there are some meaningful definitions that help flesh out Jim's 'uses' collection.

The other axis along which we have a similar 'type' challenge is the 'what' axis. Nan, Jim, and Bob have all suggested different entities worthy of timestamps; sometimes the differences are nuanced and sometimes pretty big. FWIIW, to me the most critical entity is 'whole file/product', followed by 'values/data', followed (much further back) by 'attributes/metadata'. I want the terms to apply to both file and product; and I don't want to get down to the size of a 'granule value' or up to the size of a'collection' (Jim's definitions).

I'm not excited about trying to invent a solution that mimics ISO, partly because it is too different from existing ACDD, and partly because I'm looking forward to Ted more comprehensive solution. So my bias for 1.3 is for sticking with a bare minimal list of attribute names (because that's most likely to get approval); if that's just whole file/product, I can live with that.

Finally, I may regret opening this can of worms, but as a backup for those of us who want to report more detail: It seems to me we could offer cookie cutter guidance -- if we provide a list of entity names (a) and a list of DateTypeCodes (b), at least the latter from ISO, people could make up their own attribute name as a_b, but we don't have to list all the names ourselves. And obviously, they don't have to use those names; it is auxiliary guidance (just like the Suggested attributes). If we can agree on list (a) and use the ISO codes for list (b), this bit of guidance would be easy to write, easy to follow, and easy to translate results into ISO metadata (and OCDD).

John

On Oct 5, 2014, at 16:29, Ted Habermann via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:

> Jim,
> 
> Just wanted to let you know that the approach that you are recommending is essentially the approach that ISO takes to standards development (the models are conceptual models in UML) and to separate an international standard from a community profile. 
> 
> For example, on the date thing, the ISO standard says that things that need dates (say citations) can have any number of them and each of those dates has a type. The types are governed by a code list (a set of date types) which is connected to the standard, but not a part of the standard. Communities can agree on their own set of types appropriate for their data. 
> 
> One of the big improvements in ISO 19115-1 was the conversion of a single metadata date stamp (created or revised)  into a full CI_Date with a type. This allows tracking of all kinds of metadata events in addition to data events (something that the ACDD community clearly wants). The attached slide (from http://www.slideshare.net/tedhabermann/19115-questionsandanswers) describes this improvement and shows the "standard" set of date types (can be easily modified by a community).
> 
> The problem with the attribute implementation of ACDD is that the types are part of the attribute names and, because the attribute names are THE STANDARD, the types become part of the standard. This makes it very hard to agree on a standard, and, more insidious, it makes it very difficult for communities other than the one that created the standard (agreed on a set of names) to use it. This is why ACDD, in its current form, is so limited and inherently stove-piped.
> 
> These problems are described in a bit of detail at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata and they are addressed in the OCDD which is really a discovery recommendation for ISO implemented in HDF (and NcML). I have some test implementations of this in hand and will be writing them up next week...
> 
> Ted
> 
> <MetadataLifeCycle.png>
> 
> 
> On Oct 3, 2014, at 12:06 PM, Jim Biard via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:
> 
>> Hi.
>> 
>> I was wondering if it would be useful to back the whole date attribute question up a bit.
>> 
>> Without using any existing or proposed attribute name, can each stakeholder describe what kinds of date stamps they need and want?
>> 
>> When describing these date stamps, I see three different entities (sort of) that they might relate to - and there are probably more. The ones that I see are:
>> Granule - An atom of data that is bounded in space and/or time. One granule can include multiple variables, and has variable- and granule-level metadata. A granule is not a netCDF file. It is data and metadata floating free in "the cloud".
>> Collection - A group of granules that are treated as a consistent whole. A collection may be static, or it may grow over time. As with a granule, a collection is a conceptual object in "the cloud".
>> Granule Instance - A granule expressed as one or more netCDF files.
>> 
>> Using these terms, here are date stamps that I find useful/needed. Most all of these should have accompanying annotations in history metadata.
>> 
>> Date a granule's data was first produced/acquired. This can get tricky for a granule consisting of a long time series.
>> Date a granule's metadata was first associated with the data.
>> Date a granule's data was last modified.
>> Date a granule's metadata was last modified.
>> Date a granule instance was created.
>> Date a granule instance was last modified.
>> Date a collection was established. (I say it this way on account of growing collections.) I guess this amounts to a version/edition time stamp.
>> 
>> There are other entities and date stamps that I have left out because I didn't see them as being relevant to a particular granule instance in a netCDF file.
>> Do these make sense? Are there others that you can think of?
>> Grace and peace,
>> Jim
>> <Mail Attachment.png> Visit us on 
>> Facebook	Jim Biard 
>> Research Scholar 
>> Cooperative Institute for Climate and Satellites NC 
>> North Carolina State University 
>> NOAA's National Climatic Data Center 
>> 151 Patton Ave, Asheville, NC 28801 
>> e: jbiard at cicsnc.org 
>> o: +1 828 271 4900 
>> 
>> 
>> 
>> _______________________________________________
>> Esip-documentation mailing list
>> Esip-documentation at lists.esipfed.org
>> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation
> 
> <SignatureSm.png>
> 
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141005/b216dbde/attachment.html>