<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hello Karl,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Apologies for missing your earlier email.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">(1) Like Stephen, I&#8217;m concerned about the complexity of the &#8220;XXXX&#8221; section. My first suggestion would be to drop the first hyphen and &#8220;lat&#8221; and &#8220;lon&#8221;, changing
 &#8220;g-lat20S20Nlon170p5W130p5W&#8221; to &#8220;g20S20N170p5W130p5W&#8221;. I&#8217;d also be tempted to drop the &#8220;p5&#8221; terms: for some grids (e.g. Gaussian) the exact limits will have many decimal places and so there will need to be some specification of the level of truncation expected,
 and I think the most convenient would be to round to the nearest integer.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">(2) To make parsing of the overall file name easier, you could use c1_c2_..... [_&lt;time range&gt;][.&lt;spatial info&gt;].nc &#8211; using a &#8220;.&#8221; Instead of &#8220;_&#8221; makes life easier
 for file parsers. Technically this is not necessary, as the &#8220;g&#8221; already makes it unambiguous, but parsers have to deal with the special case of gridspec files and adding more variants make life more complicated. Using &#8220;.&#8221; will make it easier to separate the
 parsing of the existing components from the new ones. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">(3) As Stephen points out, in the present form, in a string &#8220;g-aaa-bbb&#8221; the term &#8220;aaa&#8221; could be either a region from an gazetteer or a designation of a type
 of surface (&#8220;ocn&#8221; or &#8220;lnd&#8221;). Having to look through multiple vocabularies is a problem for file name interpretation, even if one of them only has two elements. To get over this, I&#8217;d suggest something like: &#8220;.....[_&lt;time range&gt;][.gXXXX_pYYY-ZZZ].nc&#8221;, where
 the &#8220;gXXXX&#8221; and &#8220;pYYY-ZZZ&#8221; terms are both optional and the underscore is only present if both are present. This approach will only work if you accept the use of &#8220;.&#8221; suggested in (2) to make a clear break between the first part of the name and the new. This
 would give us a first section of the file name in which components are identified by position and a 2<sup>nd</sup> section in which components are identified by the first letter of the component.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Martin &nbsp;&nbsp;<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext"> Karl Taylor [mailto:taylor13@llnl.gov]
<br>
<b>Sent:</b> 06 June 2012 21:58<br>
<b>To:</b> Kettleborough, Jamie; V. Balaji; Steve Hankin; Juckes, Martin (STFC,RAL,RALSP); Lawrence, Bryan (STFC,RAL,RALSP); Pascoe, Stephen (STFC,RAL,RALSP); go-essp-tech@ucar.edu<br>
<b>Subject:</b> Re: [Go-essp-tech] DRS corrections and extensions<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Dear all,<br>
<br>
In February I asked for comments on my proposal to extend the DRS to&nbsp; include information about spatio-temporal subsets or means.&nbsp; I heard from Jamie, but no one else.&nbsp; I respond to Jamie below, but I also would like your input specifically about:<br>
<br>
1.&nbsp; Is this method of describing spatio-temporal subsets acceptable?<br>
2.&nbsp; Is it worth taking this step if we don't say anything about other &quot;processed&quot; output?&nbsp;&nbsp; For example how to describe &quot;regridded&quot; data or multi-model means.<br>
<br>
I've attached the proposed version of the DRS, which differs from the one I sent in January only in a couple mods made in response to Jamie.<br>
<br>
Best regards,<br>
Karl<br>
<br>
On 2/13/12 6:47 AM, Kettleborough, Jamie wrote: <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">Hello Karl,</span><o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">this will be terse as I have time to review, but not to necessarily get the words right - hope I don't say anything too bad because of this.</span><o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">1. section 2.3,&nbsp; Not sure 'output' should be mentioned under 'product'.&nbsp; I don't think 'output' ever makes it to publication level, so does not need to appear in
 a publication level id.&nbsp; I know cmor produces it, but I think that's kind of historical isn't it, rather than necessary?&nbsp; Maybe its too late for details like this?</span><o:p></o:p></p>
<p class="MsoNormal">It's true that in the end the CMIP5 output should not remain as &quot;output&quot;, but be assigned to &quot;output1&quot; or &quot;output2&quot;.&nbsp; Nevertheless, I don't think there is any harm in keeping it in the DRS.&nbsp;
<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">2. section 2.3 version number: to be consistent with what we really have in CMIP5 I think you need to note that v1, v2 are also present, though any *new* versions
 should use vYYYYMMDD.</span><o:p></o:p></p>
<p class="MsoNormal">I have modified the text to indicate that software cannot rely on the version number reflecting a date.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">3. section 2.3 version:&nbsp; I wonder if you need to say more (maybe not here, but if not where?) about what triggers a new version.&nbsp; I think its
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">&nbsp; a. anything that changes the content of a file already published and</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">&nbsp; b.&nbsp;the addition or deletion of files from any publication data set.&nbsp;</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">&nbsp;&nbsp;Pure 'data management' meta data changes (addition of checksums, move to new URL's) need not trigger a new version.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">&nbsp; Do you also need to say there is no guarantee that old versions will be kept (unless they have a DOI).</span><o:p></o:p></p>
<p class="MsoNormal">I've added some of this information now to the document.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">4. section 2.4 Temporal Subsets or means: I don't understand the 'avg' example, or if I do I don't know if its right (but the point is relatively minor).&nbsp; I think
 the example you quote as one 6 month mean field in it.&nbsp; This is based on 1 day means.&nbsp; I think its a little anomalous to keep the frequency as 'day' in this case.&nbsp; That's not quite consistent with the definition (and I think all other uses) of frequency.&nbsp;
 Strictly speaking frequency should be 6mon no?&nbsp; (I may have misunderstood).</span><o:p></o:p></p>
<p class="MsoNormal">I think you're right.&nbsp; I'm not sure why I thought this was the right way to do it.&nbsp; I've changed the example,
<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">5. section 3.5.&nbsp; Does this need clarifying?&nbsp;I think&nbsp;the current wording is&nbsp;potentially confusing, &nbsp;I think it should say something like:</span><o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">'URLs referencing the data files will have a site dependent prefix (that may change due to site-specific data management tasks) followed by the directory structure.&nbsp;
 This directory structure should (but may not) follow the recommendations of section 3.3'</span><o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">I've modified the text as suggested.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">6. I've noticed that the thredds catalogs also expose a thing called the file_id, e.g</span><o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">&lt;property name=&quot;file_id&quot; value=&quot;cmip5.output1.CNRM-CERFACS.CNRM-CM5.rcp45.mon.ocean.Omon.r1i1p1.vo_Omon_CNRM-CM5_rcp45_r1i1p1_203601-204512.nc&quot;/&gt;</span><o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">I don't know if they need a mention as being anything important (we don't use them as they don't give any version info).</span><o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">We've already given 5 use cases, which I think is enough.&nbsp; The DRS is used in a number of other ways.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">Hope this is useful,</span><o:p></o:p></p>
<p class="MsoNormal">Yes thanks very much!<br>
Karl<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:blue">Jamie</span><o:p></o:p></p>
<blockquote style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US">
<hr size="2" width="100%" align="center">
</span></div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span lang="EN-US" style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
<a href="mailto:go-essp-tech-bounces@ucar.edu">go-essp-tech-bounces@ucar.edu</a> [<a href="mailto:go-essp-tech-bounces@ucar.edu">mailto:go-essp-tech-bounces@ucar.edu</a>]
<b>On Behalf Of </b>Karl Taylor<br>
<b>Sent:</b> 10 February 2012 01:32<br>
<b>To:</b> V. Balaji; Steve Hankin; Martin Juckes; Bryan Lawrence; Stephen Pascoe;
<a href="mailto:go-essp-tech@ucar.edu">go-essp-tech@ucar.edu</a><br>
<b>Subject:</b> [Go-essp-tech] DRS corrections and extensions</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal">Dear all,<br>
<br>
Attached is my attempt to make the DRS consistent with CMIP5 (in describing the precision of &quot;time instants&quot;), but primarily to extend it to a more complete treatment of spatio-temporal subsets or means.&nbsp; I've also corrected a few typos.<br>
<br>
Comments most welcome.&nbsp; In particular could someone recheck sections 3.3-3.5 (which haven't been changed by me) to see if they remain consistent with CMIP5?<br>
<br>
thanks and best regards,<br>
Karl<o:p></o:p></p>
</blockquote>
</div>
</div>

<br><p>-- 
<BR>Scanned by iCritical.
</p>
<br></body>
</html>