[Platforms] Proposal for revision of platform governance (initiated by ICES)
Neil Holdsworth
NeilH at ices.dk
Tue Feb 23 12:16:33 GMT 2016
Dear Martin, all,
Thank you for this input and the elaborated examples. We are currently making some bilateral questions to ensure we understand the different use cases before we return to the main forum with a revised suggestion. We have however already concluded that we do not want to go down a path that makes the system(s) more complex to both manage and interrogate - so this is our guiding principle in moving forward.
Best, Neil
From: Kramp Martin (JCOMMOPS) [mailto:mkramp at jcommops.org]
Sent: 23 February 2016 12:26
To: Neil Holdsworth <NeilH at ices.dk>; Lowry, Roy K. <rkl at bodc.ac.uk>; Gilbert MAUDIRE <Gilbert.Maudire at ifremer.fr>; Anne Che-Bohnenstengel <Anne.Che-Bohnenstengel at bsh.de>; platforms at mailman.nerc-liv.ac.uk; Michèle Fichaut <michele.fichaut at ifremer.fr>; Loic Petit de la Villeon <Loic.Petit.de.la.Villeon at ifremer.fr>; Lize Anthonin (JCOMMOPS) <alize at cls.fr>; Belbeoch Mathieu (JCOMMOPS) <belbeoch at jcommops.org>
Cc: Hjalte Parner <hjalte at ices.dk>; Mehdi Abbasi <mehdi.abbasi at ices.dk>
Subject: RE: [Platforms] Proposal for revision of platform governance (initiated by ICES)
Dear all,
I was out of the office for a couple of days, my answer thus comes a bit tardy.
If all ships would have an IMO number or other unique hull identifier, we would have gone that way. As we all know, this is not the case, and it is in particular not the case for a number of ships of opportunity which play a crucial role in the observing system: we have numerous (mostly smaller) vessels which sail off the main shipping routes and help to i) deploy instruments or ii) gather data with onboard instrumentation in e.g. the Southern Ocean.
When we were tasked to design a new identifier scheme for the JCOMM Ship Observations Team, the ICES ship code seemed to be the best existing base to do it. We (plan to) take the currently valid ICES ship code, and add 3 characters to identify the different instrument packages onboard (we have some terminology issues here between the different involved groups... for us, those instrument packages are called platforms....). The maximum length of such an ID must not exceed 9 characters (given that the ICES ship code now has a max of 6 were are fine). However, it is indeed crucial for us to track the history of the hull for a number of reasons, some were mentioned below. If the ICES ship code was ABCDEF in year n and a weather station was installed in n by e.g. NOAA, the ID of that weather station could be ABCDEF001. Even if a new ICES ship codes is assigned in let's say n+1, e.g. XYZABC, we would not change that station ID ABCDEF001, as the ID gives us information on the status of the ship at the time of the instrument installation - and the installation itself or the operator NOAA has not changed. However, if NOAA de-recruits the ship, and Meteo-France would recruit it in n+1, the new Meteo-France installation would have a station ID like XYZABC001. And if Meteo-France would de-recruit the ship in n+2, and the ICES code has not changed, and e.g. DWD recruits the ship then, we would just increment the ID: XYZABC002. It would be important for DWD at the moment of the recruitment to be aware of the history with NOAA and Meteo-France (installation issues, e.g. wiring, sea valves .. all that normally does not change over the lifetime).
Multiple ICES codes over the lifetime of a ship give us the opportunity to track changes on the ship side a little easier, at the same time they make the tracking of the hull history a little bit more difficult. We had now started to implement the ICES ship code procedure the way it was, but our system is still young and we could probably still adapt to such changes. It would however be important to take a decision in the next few weeks, given that a SOT working group will meet in April to work on the ID scheme.
I'll be happy to discuss this with those of you who are on site at Ifremer in a first step - let me know how you wish to proceed.
Many thanks and best regards
Martin
--
Martin KRAMP
Ship Coordinator
JCOMMOPS (IOC-UNESCO / WMO)
Technopole / Campus Ifremer
1625 Route de Sainte Anne
Z.I. Pointe du Diable
Blaise Pascal Hall (209.S1.21)
29280 PLOUZANE (FRANCE)
E-mail: mkramp at jcommops.org<mailto:mkramp at jcommops.org>
Tel: +33 2 29 00 85 87
Web: www.jcommops.org<http://www.jcommops.org>
[JCOMMOPS_LOGO_NEW-map]
De : Neil Holdsworth [mailto:NeilH at ices.dk]
Envoyé : vendredi 12 février 2016 14:52
À : Lowry, Roy K.; Gilbert MAUDIRE; Anne Che-Bohnenstengel; platforms at mailman.nerc-liv.ac.uk<mailto:platforms at mailman.nerc-liv.ac.uk>; Michèle Fichaut; Loic Petit de la Villeon; Kramp Martin (JCOMMOPS); Lize Anthonin (JCOMMOPS); Belbeoch Mathieu (JCOMMOPS)
Cc : Hjalte Parner; Mehdi Abbasi
Objet : [Platforms] Proposal for revision of platform governance (initiated by ICES)
Dear Platform Group,
Thank you for the spirited discussion, if we achieve nothing else we can be happy that the governance network is responsive and constructive in its approach to the operational issues we face.
Following from Gilberts message, we will await further input from the colleagues at JCOMMOPS (now copied in) and NOAA before we return and try and sum up and plot a way forward with this. We are facing a unique challenge to satisfy our traditional user base, and the new (and expanding) user base from the operational oceanography community, and we need to do this without breaking the link to the legacy data or creating new legacy issues for the next generation of governance.
And with that thought I will wish you a good weekend!
Best, Neil
________________________________
From: Lowry, Roy K. [mailto:rkl at bodc.ac.uk]
Sent: 09 February 2016 17:24
To: Gilbert MAUDIRE <Gilbert.Maudire at ifremer.fr<mailto:Gilbert.Maudire at ifremer.fr>>
Cc: Anne Che-Bohnenstengel <Anne.Che-Bohnenstengel at bsh.de<mailto:Anne.Che-Bohnenstengel at bsh.de>>; Neil Holdsworth <NeilH at ices.dk<mailto:NeilH at ices.dk>>; platforms at mailman.nerc-liv.ac.uk<mailto:platforms at mailman.nerc-liv.ac.uk>; Michèle Fichaut <michele.fichaut at ifremer.fr<mailto:michele.fichaut at ifremer.fr>>; Loic Petit de la Villeon <Loic.Petit.de.la.Villeon at ifremer.fr<mailto:Loic.Petit.de.la.Villeon at ifremer.fr>>
Subject: Re: Fwd: Re: [Platforms] Proposal for revision of platform governance (initiated by ICES)
Hi Gilbert,
Just brain-dumping in search of mutually convenient solutions, not attempting to bulldoze you into any decision.
Following this 'strategy' here's another musing. You say the problem with the IMO is that not all hulls are assigned an IMO. This has been a recognised problem for a decade, which is why IMOs haven't been adopted as an identifier by the oceanographic community. So, rather than cause disruption by partially remodelling the platform code into a hull identifier, why not go down the road of having separate hull identifiers maintained by ICES to fulfill the community's needs? This would simply be another attribute on the platform code but would have the effect of turning the existing system into a multi-faceted system, with one facet being an implementation of Bob Arko's suggestion for a separate hulls vocabulary. Having at as an attribute automatically provides a hull code to platform code mapping and vice versa.
Cheers, Roy.
Please note that I partially retired on 01/11/2015. I am now only working 7.5 hours a week and can only guarantee e-mail response on Wednesdays, my day in the office. All vocabulary queries should be sent to enquiries at bodc.ac.uk<mailto:enquiries at bodc.ac.uk>. Please also use this e-mail if your requirement is urgent.
________________________________
From: Gilbert MAUDIRE <Gilbert.Maudire at ifremer.fr<mailto:Gilbert.Maudire at ifremer.fr>>
Sent: 09 February 2016 15:27
To: Lowry, Roy K.
Cc: Anne Che-Bohnenstengel; Neil Holdsworth; platforms at mailman.nerc-liv.ac.uk<mailto:platforms at mailman.nerc-liv.ac.uk>; Michele FICHAUT; Loic Petit de la Villeon
Subject: Re: Fwd: Re: [Platforms] Proposal for revision of platform governance (initiated by ICES)
Dear Roy,
Thank you for your proposal which seems to be convincing to me at least for large ships of opportunity.
However, I am not fully aware of all types of ships of opportunity to be managed. So I prefer to wait for my Ifremer and JCOMMOPS colleagues up to next week.It is winter holidays here in Brittany. We will go back to you and Neil thereafter.
Cheers
Gilbert.
Le 09/02/2016 16:11, Lowry, Roy K. a écrit :
Hello Gilbert,
I don't think that splitting vocabularies by platform type is a good idea. Inevitably, a vessel will be used in a manner that causes problems - for example, a commercial vessel that has delivered data as a 'ship of opportunity' then gets chartered for a research cruise. If we proceed as you suggest, the ship code for this vessel will get embedded in a CSR database and as this code maps to multiple names existing systems will not be able to translate it into the correct name. Significant problems could also result from confusion in legacy where some of your VOS hulls have already been assigned multiple platform codes.
Let's think a little laterally. What you require for your 'platform' field is an identifier to tag hulls of large commercial vessels. There is already a hull-specific identifier that could do this job in the form of the IMO. If ICES were to maintain the status quo then it would be perfectly possible for ICES to provide a couple of useful services that either deliver a hull history (effectively a set of platform codes with the time ranges for which they apply) in return for an IMO number or a single platform code and its associated attributes if supplied with an IMO number plus a date.
How does that sound? It would solve your problem without breaking systems based on the assumption that the platform code represents a hull+name+flag. Note that if you follow that course I feel it is essential that the work currently underway in ICES to assign platform codes for the JCOMMops list should be completed.
Cheers, Roy.
Please note that I partially retired on 01/11/2015. I am now only working 7.5 hours a week and can only guarantee e-mail response on Wednesdays, my day in the office. All vocabulary queries should be sent to enquiries at bodc.ac.uk<mailto:enquiries at bodc.ac.uk>. Please also use this e-mail if your requirement is urgent.
________________________________
From: Gilbert MAUDIRE <Gilbert.Maudire at ifremer.fr><mailto:Gilbert.Maudire at ifremer.fr>
Sent: 09 February 2016 14:29
To: Anne Che-Bohnenstengel; Lowry, Roy K.; Neil Holdsworth; platforms at mailman.nerc-liv.ac.uk<mailto:platforms at mailman.nerc-liv.ac.uk>
Cc: Michele FICHAUT; Loic Petit de la Villeon; MAUDIRE
Subject: Re: Fwd: Re: [Platforms] Proposal for revision of platform governance (initiated by ICES)
Dear Anne, Roy and Neil,
We perfectly understand Roy's and Anne's concern. However, the management of Ships of Opportunity is now really difficult.
We know that, for example, the name and flag of a vessel with a hull mounted TSG can change during the life of the instrument. However, it is of interest to know that it is the same hull and the same instrument for all measurements because potential problems like sensor drift will be estimated for the whole life of the instrument (even if the ship name has changed).
Obviously, this kind of name+flag change occurs a lot less frequently for research vessels (and probably FerryBox) than for ships of opportunity.
In addition, it is of high interest if the couple (call sign , ship code in the vocabulary) could be permanently maintained in "near real time". That could be much easier if the procedure (decision tree) was simplified.
So, it is of high interest to find out a solution. Could this solution be to set up two procedures (and vocabularies) : one for research vessels (for CSR, POGO...) which is much more stable and one for Ships of opportunity, taking in account the platform type.
An alternate solution could be to keep track of instruments such as TSG, without taking in account the platform. But, in this case, we will loose the information about the hull (and possible biases due to the mount of the instrument).
So, before answering to this question, we would like to discuss with people who manage data from Ship of Opportunity like Loïc who is responsible of GOSUD international data base and who is on leave until next week.
Best regards,
Michèle & Gilbert.
-------- Message transféré --------
Sujet :
Re: [Platforms] Proposal for revision of platform governance (initiated by ICES)
Date :
Tue, 9 Feb 2016 09:44:23 +0000
De :
Anne Che-Bohnenstengel <Anne.Che-Bohnenstengel at bsh.de><mailto:Anne.Che-Bohnenstengel at bsh.de>
Pour :
Lowry, Roy K. <rkl at bodc.ac.uk><mailto:rkl at bodc.ac.uk>, Neil Holdsworth <NeilH at ices.dk><mailto:NeilH at ices.dk>, platforms at mailman.nerc-liv.ac.uk<mailto:platforms at mailman.nerc-liv.ac.uk> <platforms at mailman.nerc-liv.ac.uk><mailto:platforms at mailman.nerc-liv.ac.uk>
Copie à :
'param_admin at mailman.nerc-liv.ac.uk<mailto:param_admin at mailman.nerc-liv.ac.uk>' (param_admin at mailman.nerc-liv.ac.uk<mailto:param_admin at mailman.nerc-liv.ac.uk>) <param_admin at mailman.nerc-liv.ac.uk><mailto:param_admin at mailman.nerc-liv.ac.uk>
Hi Neil,
Sorry for the late reply. I am out of office and could not check the emails for 2 weeks.
I support Roy's concern over your proposal. The Cruise Summary Report inventory for SeaDataNet, ODIP/POGO and Eurofleets is one of the major clients requiring the ICES platform codes. Your proposed modification would cause immense impact on the CSRs as we have been using the platform codes as an unique identifier for the "ship" involved during the described cruise. Your proposal would mean a step backwards from what SDN has been working on during the last years, aside from the labour we have to invest on our CSR applications for the proposed changes.
I am sorry that BSH cannot agree to the proposed platform code changes. I do undertstand the issue you have with the strongly increasing number of codes with the additional JCOMMOP vessels.
Best regards,
Anne
---------------------------------------------------------
Bundesamt fuer Seeschifffahrt und Hydrographie (BSH)
Anne Che-Bohnenstengel (M4201 + M4181)
Bernhard-Nocht-Str. 78 Tel: +49 (0) 40 3190-3421
20359 Hamburg Fax: +49 (0) 40 3190-5000
http://www.bsh.de/ email: anne.che-bohnenstengel at bsh.de<mailto:anne.che-bohnenstengel at bsh.de>
---------------------------------------------------------
________________________________
Von: platforms-bounces at mailman.nerc-liv.ac.uk<mailto:platforms-bounces at mailman.nerc-liv.ac.uk> [platforms-bounces at mailman.nerc-liv.ac.uk<mailto:platforms-bounces at mailman.nerc-liv.ac.uk>]" im Auftrag von "Lowry, Roy K. [rkl at bodc.ac.uk<mailto:rkl at bodc.ac.uk>]
Gesendet: Freitag, 29. Januar 2016 16:54
An: Neil Holdsworth; platforms at mailman.nerc-liv.ac.uk<mailto:platforms at mailman.nerc-liv.ac.uk>
Cc: 'param_admin at mailman.nerc-liv.ac.uk<mailto:param_admin at mailman.nerc-liv.ac.uk>' (param_admin at mailman.nerc-liv.ac.uk<mailto:param_admin at mailman.nerc-liv.ac.uk>)
Betreff: Re: [Platforms] Proposal for revision of platform governance (initiated by ICES)
Hello Neil,
This amounts to a fundamental change in the definition of entity represented by the platform code, switching it from 'hull with a given name + flag' to 'hull'. The reason for the current definition is down to legacy. Essentially a fix designed in 2004 for the issue that the entity was originally the name followed by inconsistent behaviour in various places to the issue that ships changed names and different ships shared the same name.
The implications of your suggestion are huge. Currently, the URI based on the platform code is guaranteed to resolve to the ship name through the well-known semantic linkage of 'preferredLabel'. This applies whatever the namespace of the URI. If your suggestion is adopted, then a client requiring the name will need the URI, the date, and the ability to analyse the RDF document delivered by the URI to work out which of the alternative names to use. It will also require large-scale deprecation of platform codes to reduce the valid code set to one per hull and large-scale editing of data and metadata to eliminate the deprecated codes.
Note that you can't ignore legacy without pulling the rug from the semantic interoperability infrastructure currently under construction in many arenas. The fundamental assumption of these systems is that concept entity definitions are fixed - you cannot have something sometimes meaning one thing and at other times meaning something else.
I therefore vote 'No' to your proposal and strongly urge you to widen consultation beyond the platforms group to include the user groups it will affect, particularly SeaDataNet/EMODNET, ODIP and possibly others such as SenseOcean and AtlantOS.
Cheers, Roy.
Please note that I partially retired on 01/11/2015. I am now only working 7.5 hours a week and can only guarantee e-mail response on Wednesdays, my day in the office. All vocabulary queries should be sent to enquiries at bodc.ac.uk<mailto:enquiries at bodc.ac.uk>. Please also use this e-mail if your requirement is urgent.
________________________________
From: platforms-bounces at mailman.nerc-liv.ac.uk<mailto:platforms-bounces at mailman.nerc-liv.ac.uk> <platforms-bounces at mailman.nerc-liv.ac.uk><mailto:platforms-bounces at mailman.nerc-liv.ac.uk> on behalf of Neil Holdsworth <NeilH at ices.dk><mailto:NeilH at ices.dk>
Sent: 29 January 2016 15:17
To: platforms at mailman.nerc-liv.ac.uk<mailto:platforms at mailman.nerc-liv.ac.uk>
Subject: [Platforms] Proposal for revision of platform governance (initiated by ICES)
Dear Platform Group,
Please respond to this proposal with a "Yes" to accept the proposal or "No" to reject the proposal by close of business February 12. No reply will be considered as a "Yes".
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ICES has been assigning codes for JCOMMOP vessels for the past 4 months. This has given us the opportunity to test and re-evaluate the effectiveness of the Platform code system now that the predominant platform class has moved from research vessels to ships of opportunity. We are finding that these vessels are changing name, flag, and owner much more often than research vessels and according to the current Platform Decision Tree, some vessels will need 5-6 codes in their data collecting lifetime. We believe that this is an unnecessary complication, especially for vessels which have IMO numbers since IMO numbers never change and can be used for tracking.
We would like to propose focusing on identification of a given platform which follows the hull and not the country of any governance (flag, owner or institute). We will keep track of the governance histories of the platform in the platform request system.
In order to do this, we propose:
* a new attribute for "Operational Governance". It will allow multiples and will be based on EDMO codes.
* replace the decision tree with a simplified process
* an update to vocab.ices.dk to offer a clear linking between related platform codes
* to only create codes based on a random generated unique identifier (see development history)
The decision process will be as follows:
If there is an IMO number:
* Attribute "Country", i.e. Flag of country where platform is registered, is mandatory.
* The flag and call sign will be set for the current registration of the platform.
If there is no IMO number:
* Attribute "Operational Governance" is mandatory and designated by EDMO codes.
* When the flag/call sign/MMSI/Notes etc. changes, the attributes will be updated. Name changes will be documented in the "Note" attribute as "Built as name, became name 2 in xxxx, name 3 in yyyy, name 4 in zzzz etc.". The "Previous name" attribute will have the latest previous name. The previous flag/call sign attributes will be "unaccepted" but kept on the Attribute History page to aid user searching and kept on the Action History page for tracking.
For both cases above:
* A code will be assigned as a random generated unique identifier and it will not change.
Kind regards,
Neil
Development history
When ICES first started assigning platform codes, the majority of codes were for research vessels which were collecting nationally funded monitoring data or project data. The system was based on the assumption that these national data were collected by their national vessels so the first two digits of the codes designated country.
ICES then became part of the SeaDataNet project, new attributes were added and a decision tree was developed to determine what was needed to assign a code. The decision tree was accepted by the SeaDataNet Platform Governance Group after many discussions:
* should there be a country part of the code?
* what type of governance should determine the country part of the platform code: owner of the vessel, Institute collecting the data, flag of the country where the vessel was registered?
* Should an IMO code be added for identification when most research vessels can't receive an IMO number?
Among other attributes, it was decided that the vessels' flag should determine the country part of the code and IMO codes should be added when available.
As more platform classes were added to L06 (and therefore added to the platform request system), new situations and questions came up:
* what is the country when multiple Institutes from different countries share the vessel during the year or even share during the same cruise? See the POGO initiative http://www.pogo-oceancruises.org/content/content.asp?pageid=4
[Image removed by sender.]<http://www.pogo-oceancruises.org/content/content.asp?pageid=4>
Pogo<http://www.pogo-oceancruises.org/content/content.asp?pageid=4>
www.pogo-oceancruises.org<http://www.pogo-oceancruises.org>
The recommendations of the committee were discussed at the POGO-7 meeting in January 2006 and the POGO Members endorsed the plan to assemble, distribute and maintain ...
*
* what is the country when multiple countries own the platform?
In preparation for running out of codes and removing semantics from codes, in March 2010 it was decided by the platform group that the country part of the code could be abandoned and the codes extended although in practice we have continued to use the country as the first two digits of the four digit code.
In 2015, additional changes were made to accommodate JCOMMOPs vessels. It was decided that the codes would be extended to 6 digits once the current 4 digit system ran out of codes for a particular country, additional attributes were added and the possibility to add multiple countries was incorporated into the request program. Almost 2000 platforms have since been requested by JCOMMOPs of which 98% are Vessels of Opportunity. This has changed the predominant platform class of the platform code system.
Neil Holdsworth
Head of Data and Information
International Council for the Exploration of the Sea
E: neil.holdsworth at ices.dk<mailto:neil.holdsworth at ices.dk>
W: www.ices.dk<http://www.ices.dk/>
T: +45 3338 6718
M: +45 5362 6718
H.C. Andersens Boulevard 44-46
1553 Copenhagen V. Denmark
Follow ICES on LinkedIn<http://www.linkedin.com/groups?gid=1153507>
________________________________
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
________________________________
--
________________________________________________________________________
Michele FICHAUT - +33 (0)298 22 46 43
http://annuaire.ifremer.fr/cv/16035/en
http://www.seadatanet.org
http://www.ifremer.fr/sismer/
________________________________________________________________________
________________________________
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
________________________________
________________________________
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
________________________________
Cliquez ici<https://www.mailcontrol.com/sr/g7HfnvXN7uzGX2PQPOmvUkjDae7bB5Ig9or0vhFqCAFENkiGpoy4mu8tIJzLK950ebpOo395LBWVGm43FW9a3A==> si ce message est indésirable (pourriel).
________________________________
Ce message et toutes les pièces jointes (ci-après le "message") sont établis à l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur ou s'il ne vous est pas destiné, merci de le détruire ainsi que toute copie de votre système et d'en avertir immédiatement l'expéditeur. Toute lecture non autorisée, toute utilisation de ce message qui n'est pas conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer l'intégrité de ce message électronique susceptible d'altération, l'expéditeur (et ses filiales) décline(nt) toute responsabilité au titre de ce message dans l'hypothèse où il aurait été modifié ou falsifié.
This message and any attachments (the "message") is intended solely for the intended recipient(s) and is confidential. If you receive this message in error, or are not the intended recipient(s), please delete it and any copies from your systems and immediately notify the sender. Any unauthorized view, use that does not comply with its purpose, dissemination or disclosure, either whole or partial, is prohibited. Since the internet cannot guarantee the integrity of this message which may not be reliable, the sender (and its subsidiaries) shall not be liable for the message if modified or falsified.
________________________________
Denne mail er blevet scannet af http://www.comendo.com og indeholder ikke virus!
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.nerc-liv.ac.uk/pipermail/platforms/attachments/20160223/282103c8/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 4750 bytes
Desc: image002.png
Url : http://mailman.nerc-liv.ac.uk/pipermail/platforms/attachments/20160223/282103c8/attachment-0001.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 707 bytes
Desc: image003.jpg
Url : http://mailman.nerc-liv.ac.uk/pipermail/platforms/attachments/20160223/282103c8/attachment-0001.jpg
More information about the Platforms
mailing list