[Platforms] Proposal for revision of platform governance (initiated by ICES)
Anne Che-Bohnenstengel
Anne.Che-Bohnenstengel at bsh.de
Tue Feb 9 09:44:23 GMT 2016
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
---------------------------------------------------------
________________________________
Von: platforms-bounces at mailman.nerc-liv.ac.uk [platforms-bounces at mailman.nerc-liv.ac.uk]" im Auftrag von "Lowry, Roy K. [rkl at bodc.ac.uk]
Gesendet: Freitag, 29. Januar 2016 16:54
An: Neil Holdsworth; platforms at mailman.nerc-liv.ac.uk
Cc: 'param_admin at mailman.nerc-liv.ac.uk' (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. Please also use this e-mail if your requirement is urgent.
________________________________
From: platforms-bounces at mailman.nerc-liv.ac.uk <platforms-bounces at mailman.nerc-liv.ac.uk> on behalf of Neil Holdsworth <NeilH at ices.dk>
Sent: 29 January 2016 15:17
To: 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
[http://www.pogo-oceancruises.org/pictures/pogo/html_page/newlogo_seadatanet.gif]<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
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.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.nerc-liv.ac.uk/pipermail/platforms/attachments/20160209/d9c2b186/attachment-0001.html
More information about the Platforms
mailing list