[Esip-documentation] ACDD date attributes question

Mon Oct 6 08:50:13 EDT 2014

John,

See the ISO codelist from this link:
https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries

including CI_DateTypeCode and CI_RoleCode

--- Peng

On Sun, Oct 5, 2014 at 8:41 PM, John Graybeal via Esip-documentation <
esip-documentation at lists.esipfed.org> wrote:

> 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> <http://www.cicsnc.org/>Visit us on
> Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
> *Research Scholar*
> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
> North Carolina State University <http://ncsu.edu/>
> NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
> 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
>
>
>
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation
>
>

-- 
*Ge Peng, Ph.D*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
ge.peng at noaa.gov
o: +1 828 257 3009
f:  +1 828 257 3002

Following CICS-NC on Facebook <http://www.facebook.com/cicsnc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141006/4899a9c3/attachment.html>