[Esip-documentation] Fwd: ACDD date attributes question
Ted Habermann via Esip-documentation
esip-documentation at lists.esipfed.org
Mon Oct 6 12:40:53 EDT 2014
Woops - this went to the wrong place...
Ted
Begin forwarded message:
From: Ted Habermann <thabermann at hdfgroup.org<mailto:thabermann at hdfgroup.org>>
Subject: Re: [Esip-documentation] ACDD date attributes question
Date: October 6, 2014 at 7:29:42 AM MDT
To: Ge Peng - NOAA Affiliate <ge.peng at noaa.gov<mailto:ge.peng at noaa.gov>>
John et al.,
ISO codelist definitions are generally not a good place to look for deep meaning. Terms get added late in the process when everyone has been worn down by long discussions. Also, the ISO definition of definition is not very useful… Details of codeList definitions are really community things… driven by the kinds of discussions we have seen on the list…
The link Peng sent has only the older ones… The new terms are listed below..
Ted
1.
CI_DateTypeCode
identification of when a given event occurred
2.
creation
creation
date identifies when the resource was brought into existence
3.
publication
publication
date identifies when the resource was issued
4.
revision
revision
date identifies when the resource was examined or re-examined and improved or amended
5.
expiry
expiry
date identifies when resource expires
6.
lastUpdate
lastUpdate
date identifies when resource was last updated
7.
lastRevision
lastRevision
date identifies when resource was last reviewed
8.
nextUpdate
nextUpdate
date identifies when resource will be next updated
9.
unavailable
unavailable
date identifies when resource became not available or obtainable
10.
inForce
inForce
date identifies when resource became in force
11.
adopted
adopted
date identifies when resource was adopted
12.
deprecated
deprecated
date identifies when resource was deprecated
13.
superseded
superseded
date identifies when resource was superseded or replaced by another resource
14.
validityBegins
validityBegins
time at which the data are considered to become valid.
NOTE: There could be quite a delay between creation and validity begins
15.
validityExpires
validityExpires
time at which the data are no longer considered to be valid
16.
released
released
the date that the resource shall be released for public access
17.
distribution
distribution
date identifies when an instance of the resource was distributed
[cid:3777702D-45F4-4250-BB1C-8AFBD78174C5]
On Oct 6, 2014, at 6:50 AM, Ge Peng - NOAA Affiliate <ge.peng at noaa.gov<mailto:ge.peng at noaa.gov>> wrote:
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<mailto: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<mailto: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<mailto: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<mailto:jbiard at cicsnc.org>
o: +1 828 271 4900<tel:%2B1%20828%20271%204900>
_______________________________________________
Esip-documentation mailing list
Esip-documentation at lists.esipfed.org<mailto: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<mailto: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<mailto: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<mailto: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>
[cid:32323496-C60B-49FF-8310-11CCF46BDC72]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141006/0d859a46/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SignatureSm2.png
Type: image/png
Size: 16655 bytes
Desc: SignatureSm2.png
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141006/0d859a46/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SignatureSm.png
Type: image/png
Size: 30402 bytes
Desc: SignatureSm.png
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141006/0d859a46/attachment-0003.png>
More information about the Esip-documentation
mailing list