<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>Hey Martin,</div>
<div><br>
</div>
<div>This makes a lot of sense.</div>
<div><br>
</div>
<div>Maybe Apache Tika could help in building such an API?</div>
<div><br>
</div>
<div><a href="http://tika.apache.org">http://tika.apache.org</a>/</div>
<div><br>
</div>
<div>It's main goal is to be a "Babel Fish" for extracting useful text and metadata from any kind of file, starting with IANA's set of 1200+ rich file types, and including basic support for HDF5, NetCDF and some other relevant science data formats. There are
efforts underway to try and integrate GDAL into Tika as well to understand GIS formats, so it may be of use here.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Chris</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>"<a href="mailto:martin.juckes@stfc.ac.uk">martin.juckes@stfc.ac.uk</a>" <<a href="mailto:martin.juckes@stfc.ac.uk">martin.juckes@stfc.ac.uk</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, March 6, 2013 5:56 AM<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:sebastien.denvil@ipsl.jussieu.fr">sebastien.denvil@ipsl.jussieu.fr</a>" <<a href="mailto:sebastien.denvil@ipsl.jussieu.fr">sebastien.denvil@ipsl.jussieu.fr</a>>, "<a href="mailto:go-essp-tech@ucar.edu">go-essp-tech@ucar.edu</a>"
<<a href="mailto:go-essp-tech@ucar.edu">go-essp-tech@ucar.edu</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Go-essp-tech] Towards versioning in ESG<br>
</div>
<div><br>
</div>
<div 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">
<meta name="Generator" content="Microsoft Word 14 (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: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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 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;}
p
{mso-style-priority:99;
margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle22
{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]-->
<div bgcolor="white" lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Hello All,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Some more thoughts on version control etc.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">I was included in a recent exchange between a user (Urs Beyerle of ETH) and Karl, and on interesting aspect of that conversation was that Urs was
comparing ESGF with systems such as git. For ESGF a lot of effort has been put into creating robust and useful metadata in the files. Git and systems like it have nothing to do with in-file metadata, instead they provide a system of tracking metadata about
the files, and keep the structure in which this metadata is stored hidden from the users. Git does version control at the repository level, and users are happy with his because they have the tools to extract the kind of information they want. They do not have
to navigate a directory structure to find out about versions. What we have at present, which is a great step forward, is a system of keeping multiple versions in the archive. What we need are tools to allow users (and archive managers) to extract useful information
about their files from the archive metadata. Synchro-data (from IPSL) does some of this.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">One of the problems is that users like in-file metadata in their data files, because it is accessible to data processing software, but want to have
features which can only be supported by external meta-data about how the file has been published, moved into later versions, replaced etc. Creating an API which allows data processing software to access external metadata will be important.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Martin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b><span lang="EN-US" style="font-size: 10pt; font-family: Tahoma, sans-serif; color: windowtext; ">From:</span></b><span lang="EN-US" style="font-size: 10pt; font-family: Tahoma, sans-serif; color: windowtext; ">
<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>Sébastien Denvil<br>
<b>Sent:</b> 06 March 2013 10:14<br>
<b>To:</b> <a href="mailto:go-essp-tech@ucar.edu">go-essp-tech@ucar.edu</a><br>
<b>Subject:</b> Re: [Go-essp-tech] Towards versioning in ESG<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Hi folks,<br>
<br>
to add to this important topic I would like to raise a few comments and highlight possible guidance we could made, from a data producer and provider perspective.<br>
<br>
Sorry for this long email but it was not easy to pack it more than this.<br>
<br>
1. Version as we have now are too high level (dataset level) to be useful to the users. They are in some sense useful to data provider but it's clearly not enough in this context as well.<br>
2. tracking_id are very useful. As things stands now this is the most robust we have to build version information system for users.<br>
3. checksum are useful but not at all error prone and they are costly. Few months back it was not a good idea to build on top of it a version information system for users.<br>
<br>
We developed a prototype version information system for users. It highlights the methodological approach and only cover IPSL results.<br>
<br>
1. we need list of problems<br>
2. we need list of files affected by a given problem<br>
3. we need list of (files, problem) status ie (corrected, not corrected)<br>
<br>
This page provide errata related to our IPSL-CM results only.<br>
<a href="http://icmc.ipsl.fr/research/international-projects/cmip5/errata-ipsl">http://icmc.ipsl.fr/research/international-projects/cmip5/errata-ipsl</a><br>
<br>
The interesting part is that you can provide a list of tracking_id (example netcdf_tracking_id.txt attached).
<br>
The system will tell you:<br>
- whether the file is from the latest dataset version or not. (Not so useful information I agree)<br>
- if not has the file really changed compared to previous dataset version. (This is useful : the dataset version changed but not the file I'm interested in)<br>
- history of correction made on those files (example : <a href="http://icmc.ipsl.fr/research/international-projects/cmip5/87-research/international-projects/cmip5/errata/227">
http://icmc.ipsl.fr/research/international-projects/cmip5/87-research/international-projects/cmip5/errata/227</a>)
<br>
- if you don't have the latest version of a given file you have access to the list of problems that has been solved.<br>
- if you have the latest version of a given file BUT a problem still need to be solved you can make a proper decision.<br>
<br>
I agree it needs some formal thinking. The attached pdf provides a few steps towards this.<br>
<br>
We suggest that part of this information can be captured during publication and after the fact (new published version = comments and list of issues (tickets)).<br>
<br>
We suggest to leverage the ESGF search system as a place holder and the entry point for this information.<br>
<br>
File level versioning is what the users want.<br>
<br>
thanks.<br>
Sébastien<br>
<br>
Le 06/03/2013 10:38, Kettleborough, Jamie a écrit :<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:36.0pt">Hello,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">is there a straw man document (or anything like that) around thoughts/proposals on versioning in ESG? I think it would be great to get some user review (both data providers and data consumers) of this if possible.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">Thanks,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">Jamie<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<blockquote style="border:none;border-left:solid black 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" style="margin-left:36.0pt"><o:p> </o:p></p>
<div class="MsoNormal" align="center" style="margin-left:36.0pt;text-align:center">
<span lang="EN-US">
<hr size="2" width="100%" align="center">
</span></div>
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt">
<b><span lang="EN-US" style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span lang="EN-US" style="font-size: 10pt; font-family: Tahoma, sans-serif; "><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>Christensen, Sigurd W.<br>
<b>Sent:</b> 05 March 2013 19:57<br>
<b>To:</b> <a href="mailto:go-essp-tech@ucar.edu">go-essp-tech@ucar.edu</a><br>
<b>Subject:</b> [Go-essp-tech] Towards versioning in ESG</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:36.0pt"><span style="font-family: Arial, sans-serif; ">Folks,</span><o:p></o:p></p>
<p style="margin-left:36.0pt"><span style="font-family: Arial, sans-serif; ">Thanks for the opportunity to discuss versioning on today's call.</span><o:p></o:p></p>
<p style="margin-left:36.0pt"> <o:p></o:p></p>
<p style="margin-left:36.0pt"><span style="font-family: Arial, sans-serif; ">As others have expressed, in the December 21 and March 4 postings on this topic, my main concern is that versioning serve the needs of the end user. We should provide an easy way for
the end user to determine whether data and metadata the user has previously retrieved and used in an analysis is still current, or has been revised in a way that might affect the analysis. </span><o:p></o:p></p>
<p style="margin-left:36.0pt"> <o:p></o:p></p>
<p style="margin-left:36.0pt"><span style="font-family: Arial, sans-serif; ">I agreed to post to this list a consideration I mentioned on today's call: observational datasets that routinely are extended through time as current data become available. This situation
was also raised on this list by George Huffman on December 21, 2012. I agree with his thought that provoking a new version each time a new data increment is added is unwieldy both for the data producers and for the users.</span><o:p></o:p></p>
<p style="margin-left:36.0pt"> <o:p></o:p></p>
<p style="margin-left:36.0pt"><span style="font-family: Arial, sans-serif; ">I also support George's notion that we consider the standards for DOIs (Digital Object Identifiers) in conjunction with the discussion of versioning.</span><o:p></o:p></p>
<p style="margin-left:36.0pt"> <o:p></o:p></p>
<p style="margin-left:36.0pt"><span style="font-family: Arial, sans-serif; ">A final thought for now: I feel that we should make information available to the users about what changed with a new version.</span><o:p></o:p></p>
<p style="margin-left:36.0pt"> <o:p></o:p></p>
<p style="margin-left:36.0pt"><span style="font-family: Arial, sans-serif; "> - Sig Christensen</span><o:p></o:p></p>
<p style="margin-left:36.0pt"> <o:p></o:p></p>
<p style="margin-left:36.0pt"> <o:p></o:p></p>
<div class="MsoNormal" align="center" style="margin-left:36.0pt;text-align:center">
<hr size="2" width="100%" align="center">
</div>
<p style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt">
<b><span style="font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-family: Tahoma, sans-serif; "><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>Drach, Bob<br>
<b>Sent:</b> Monday, March 04, 2013 21:26<br>
<b>To:</b> Taylor, Karl Taylor<br>
<b>Cc:</b> <a href="mailto:go-essp-tech@ucar.edu">go-essp-tech@ucar.edu</a><br>
<b>Subject:</b> Re: [Go-essp-tech] definition of dataset version</span><o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt">
<span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">Hi Karl,<br>
<br>
As you suggest, the broader question is what guidance we should give to data providers and users on usage of the dataset version, file tracking ID, and file checksum.<br>
<br>
It's true that the dataset version may not be of much use to data users if they don't record when the data was downloaded. But since the version indicates the date of publication, it still might give some indication when a dataset has gone out of date. The
tracking ID is a random UUID generated by CMOR, and is meant as a 'bar code' to track the data through ESGF. Since it's a global attribute that is visible on the data portal, it is relatively easy for a user to discover and compare with the file value. However
its usage and purpose haven't been well defined, and in some cases data providers have probably modified data in place without changing the tracking ID (hopefully not too often). Checksums are definitive, but trivial modifications can't be made without changing
the checksum.<br>
<br>
To answer your question, the timestamp in the ESGF SOLR index is associated with the dataset as a whole, and indicates the publication time.<br>
<br>
I'm opening the discussion to the GO-ESSP list for comments.<br>
<br>
--Bob<o:p></o:p></span></p>
<div>
<div class="MsoNormal" align="center" style="margin-left:36.0pt;text-align:center">
<hr size="2" width="100%" align="center">
</div>
<div id="divRpF600567">
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt">
<b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "> Karl Taylor [<a href="mailto:taylor13@llnl.gov">taylor13@llnl.gov</a>]<br>
<b>Sent:</b> Monday, March 04, 2013 3:45 PM<br>
<b>To:</b> Drach, Bob<br>
<b>Cc:</b> Williams, Dean N.; Painter, Jeff; Ganzberger, Michael<br>
<b>Subject:</b> Re: definition of dataset version</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt">
Hi Bob,<br>
<br>
I think the "version numbers" assigned datasets are pretty unhelpful to most users. Most users won't record or remember what version they have downloaded. Perhaps some users will know what *date* they downloaded data, and all users can determine the tracking_id's
and chksums for their files, so we should provide support for determining whether files are current based on this information.<br>
<br>
Is the date recorded by ESGF assigned to a dataset or to each file? If it's assigned to a dataset, then I'm not sure that will be much use either.<br>
<br>
I think when a user asks us whether a file is current or not, based on the checksum or tracking_id, we should return the following information:<br>
<br>
"You have the latest version of this file" -- if the checksum provided by the user is identical to the latest file version in the CMIP archive.<br>
"A newer variant of the file exists, but differences are unlikely to affect your analysis" -- if the only changes made have been to some subset of the file's global attributes that we think will not lead to misinterpretation of the data itself.<br>
"A new version of the file exists and should be used in place of the one you downloaded" -- otherwise<br>
<br>
We would list the set of global attributes that could be wrong in case 2.<br>
<br>
We could use tracking_id's rather than chksums, but we would have to weed out the cases where a critically important global attribute had been modified, but the tracking_id hadn't. [I'd guess that there aren't any cases where the data itself has been modified
without changing the chksum, but there might be quite a few cases where important global attributes have been changed.]<br>
<br>
Would the above be practical?<br>
<br>
Karl<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">On 3/4/13 1:21 PM, Drach, Bob wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">Hi Karl,<br>
<br>
Dean requested that we have a conversation about dataset versioning on the GO-ESSP telecon tomorrow. I'm curious about your views on the subject.
<br>
<br>
Specifically, the question arose for the case where a modeling group has regenerated data through CMOR, to replace data lost in a disk crash. The data providers assert that the data is identical to the published version. However, because it has been regenerated
the checksums and tracking IDs differ. The question is whether the data should be published with the previous version number or should be considered a new version.<br>
<br>
At the moment we leave the choice to the data publishers, and the publishing client by default generates a new version number when any file in a dataset has been added, deleted, or modified. However, this leaves some ambiguous cases, such as when:<br>
<br>
- the metadata has been modified, but the actual data is unchanged;<br>
- the data has been regenerated through CMOR, such that all data and metadata fields are unchanged, with the sole exception of the tracking ID (and therefore the checksum has changed as well).<br>
<br>
My opinion is that an updated version number should be a signal to the end users that something significant has changed that is worth their attention. If nothing has changed except the tracking ID and history attributes, the dataset should be republished with
the original version number. There may be similar cases where minor metadata modifications don't warrant a new version number. On the other hand, modification of metadata that guides processing - axis definitions, units, dataset identification fields, etc.,
should trigger a new version number.<br>
<br>
This approach has the implication that the tracking ID and checksum of a file could change even though the parent dataset version stays the same.<br>
<br>
Any thoughts on the matter?<br>
<br>
--Bob<o:p></o:p></span></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:36.0pt"><br>
<br>
<br>
<o:p></o:p></p>
<pre style="margin-left:36.0pt">_______________________________________________<o:p></o:p></pre>
<pre style="margin-left:36.0pt">GO-ESSP-TECH mailing list<o:p></o:p></pre>
<pre style="margin-left:36.0pt"><a href="mailto:GO-ESSP-TECH@ucar.edu">GO-ESSP-TECH@ucar.edu</a><o:p></o:p></pre>
<pre style="margin-left:36.0pt"><a href="http://mailman.ucar.edu/mailman/listinfo/go-essp-tech">http://mailman.ucar.edu/mailman/listinfo/go-essp-tech</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal" style="margin-left:36.0pt"><br>
<br>
<br>
<o:p></o:p></p>
<pre style="margin-left:36.0pt">-- <o:p></o:p></pre>
<pre style="margin-left:36.0pt">Sébastien Denvil<o:p></o:p></pre>
<pre style="margin-left:36.0pt">IPSL, Pôle de modélisation du climat<o:p></o:p></pre>
<pre style="margin-left:36.0pt">UPMC, Case 101, 4 place Jussieu,<o:p></o:p></pre>
<pre style="margin-left:36.0pt">75252 Paris Cedex 5<o:p></o:p></pre>
<pre style="margin-left:36.0pt"><o:p> </o:p></pre>
<pre style="margin-left:36.0pt">Tour 45-55 2ème étage Bureau 209<o:p></o:p></pre>
<pre style="margin-left:36.0pt">Tel: 33 1 44 27 21 10<o:p></o:p></pre>
<pre style="margin-left:36.0pt">Fax: 33 1 44 27 39 02<o:p></o:p></pre>
</div>
<br>
<p>-- <br>
Scanned by iCritical. </p>
<br>
</div>
</div>
</span>
</body>
</html>