<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19328"></HEAD>
<BODY bgColor=#ffffff text=#000000>
<DIV dir=ltr align=left><SPAN class=659040309-21122012><FONT color=#0000ff 
size=2 face=Arial>Hello Karl,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=659040309-21122012><FONT color=#0000ff 
size=2 face=Arial></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=659040309-21122012><FONT color=#0000ff 
size=2 face=Arial>Is there any documentation anywhere on what changes should or 
shouldn't trigger new versions?&nbsp; Is it worth adding this advice to that 
documentation?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=659040309-21122012><FONT color=#0000ff 
size=2 face=Arial></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=659040309-21122012><FONT color=#0000ff 
size=2 face=Arial>Thanks,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=659040309-21122012><FONT color=#0000ff 
size=2 face=Arial></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=659040309-21122012><FONT color=#0000ff 
size=2 face=Arial>Jamie</FONT></SPAN></DIV><BR>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
  <DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
  <HR tabIndex=-1>
  <FONT size=2 face=Tahoma><B>From:</B> go-essp-tech-bounces@ucar.edu 
  [mailto:go-essp-tech-bounces@ucar.edu] <B>On Behalf Of </B>Karl 
  Taylor<BR><B>Sent:</B> 20 December 2012 17:51<BR><B>To:</B> 
  stephen.pascoe@stfc.ac.uk<BR><B>Cc:</B> esgf-devel@lists.llnl.gov; 
  go-essp-tech@ucar.edu<BR><B>Subject:</B> Re: [Go-essp-tech] [esgf-devel] 
  Changing checksums without changing version number ?<BR></FONT><BR></DIV>
  <DIV></DIV><FONT face="Times New Roman">Hi Stephane and Stephen,<BR><BR>I 
  agree with Stephen that what you should do is not obvious, but I think least 
  confusing is to indeed publish as a new version.&nbsp; We'll need to work to 
  make easily accessible information about how versions differ (or don't) so as 
  to avoid folks reanalyzing output when it is unnecessary.&nbsp;&nbsp; 
  <BR><BR>Karl<BR><BR></FONT>
  <DIV class=moz-cite-prefix>On 12/20/12 2:42 AM, <A 
  class=moz-txt-link-abbreviated 
  href="mailto:stephen.pascoe@stfc.ac.uk">stephen.pascoe@stfc.ac.uk</A> 
  wrote:<BR></DIV>
  <BLOCKQUOTE 
  cite=mid:4C353E6E4A08AE4792B350DAA392B5213BBDDC5C@EXCHMBX01.fed.cclrc.ac.uk 
  type="cite"><PRE wrap="">Hi Stephane,

This is a difficult use case to resolve.  I have broadened the thread to go-essp-tech because it affects the whole plan of how we keep track of changing data.

My opinion is that you should publish this data as a new version.  We have been assuming that each dataset version has a stable set of checksums.  We'd like to build tools around this assumption that checks the integrity of the archive (admittedly we haven't got there yet).

If you republish files as the same versions but with different checksums we cannot tell that only the metadata has changed.  Thinking about the archive as a whole, we have to assume that any file-versions that change checksum could be different data and flag it as such.  It would be better to create a new version and document that this version is a trivial change.

Unfortunately we don't have a good system for documenting these version transitions.  BADC did produce a web-app for this some months ago but it didn't catch on [1].  Also there is a wiki page [2] where you can note down data provider issues but I doubt any users know it exists.  If you record what you've done in one of those places the knowledge will not be lost.

[1] <A class=moz-txt-link-freetext href="http://cmip-ingest1.badc.rl.ac.uk/drscomm/search/">http://cmip-ingest1.badc.rl.ac.uk/drscomm/search/</A> (Contact Ag Stephens for details: CC'd above)
[2] <A class=moz-txt-link-freetext href="http://esgf.org/wiki/CMIP5ProviderFAQ">http://esgf.org/wiki/CMIP5ProviderFAQ</A>

Cheers,
Stephen.

---
Stephen Pascoe  +44 (0)1235 445980
Centre of Environmental Data Archival
STFC Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX, UK


-----Original Message-----
From: <A class=moz-txt-link-abbreviated href="mailto:owner-esgf-devel@lists.llnl.gov">owner-esgf-devel@lists.llnl.gov</A> [<A class=moz-txt-link-freetext href="mailto:owner-esgf-devel@lists.llnl.gov">mailto:owner-esgf-devel@lists.llnl.gov</A>] On Behalf Of Stéphane Senesi
Sent: 19 December 2012 16:58
To: <A class=moz-txt-link-abbreviated href="mailto:esgf-devel@lists.llnl.gov">esgf-devel@lists.llnl.gov</A>
Subject: [esgf-devel] Changing checksums without changing version number ?

Dear all,

We experienced a failure of a disk array for our CMIP5 data's ESG datanode. We are able to produce again the same data and metadata, except that, in each NetCDF file, a small part of the "history" metadata is changed (namely the date of the last setting for some metadata). 
Hence, the cheksum does change, and we have no way to avoid it.

We can either re-publish the affected datasets with a new version number or with the same version number.

In the first case, all users may think that the data is new, and will have to consider if they want to download it again, and, if they do, may eventually complain that we generate additional non-sensical work

In the second one, meticulous users will complain that the checksums in our thredds catalog are not the same as the checksums for the files they have already downloaded

What is the best way forward ? I suspect it is the second one, because checksums are not supposed to be data identifiers but only used for check of data corruption immediately after the transfer. But does everybody agree with that ?

Regards


--
Stéphane Sénési
Ingénieur - équipe Assemblage du Système Terre Centre National de Recherches Météorologiques Groupe de Météorologie à Grande Echelle et Climat

CNRM/GMGEC/ASTER
42 Av Coriolis
F-31057 Toulouse Cedex 1

+33.5.61.07.99.31 (Fax :....9610)


</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>