[Platforms] ROMANIA - MULTIPLE SHIPS OF ROMANIA

[Lowry, Roy K]

Hi Neil,

Best practice for legacy data is of course to upgrade it to the latest standards/structures.  However, there is always a balance to maintain between aspirations and reality as I know all too well with work on our cruise metadata repository.  After five years I think we have just about purged multiple-ship “cruises” from the system, in one case spawning no fewer than 20 new cruise records for a week-long MAFF young fish survey.  This is painstaking, time-consuming work that not everybody has the will or resources to undertake.

We have to support legacy.  Therefore I would never suggest cleaning out the ICES ship code list.  The whole idea of the C174 list was to subdivide the full ICES list into codes that passed quality scrutiny for inclusion in SeaDataNet CSRs and codes needed to support legacy data.   However, I would question the wisdom of expanding the latter.

The case that  triggered this discussion was a request from a SeaDataNet partner for a new ‘multiple ships of a nation’ code, which I presume is to support the creation of a CSR for SeaDataNet.  This rang my alarm bells.  Not only is it setting up data model extension through vocabulary population, but it is leading to a CSR covering many “cruises” by many vessels.  We are working hard to eliminate these and the last thing I want to see is new ones being created.  Hence my reaction to the new code proposal.

In my opinion, ‘cruise’ is a specialisation of a ‘data collection activity’ class and the CSR is a metadata model designed to describe that specialisation. Now it is perfectly possible to have oceanographic data collection activities that are not a good fit into the  ‘cruise’ model such as a Ferrybox route (would require one CSR per sailing: possible but inelegant).  These represent a different specialisation and what we should be doing is profiling our metadata model to accommodate their attributes (e.g. fields like sailing duration and sailing frequency) rather than redefining what is meant by a ‘cruise’.

Cheers, Roy.

From: Neil Holdsworth [mailto:NeilH at ices.dk]
Sent: 03 November 2010 08:57
To: Lowry, Roy K; Dick M.A. Schaap
Cc: Accessions; platforms at biwebs1.nerc-liv.ac.uk; sdn-tech at seadatanet.org
Subject: RE: [Platforms] ROMANIA - MULTIPLE SHIPS OF ROMANIA

Dear Roy,

You are right that fixing limitations in data models by other means is not the best thing to do. However, i think we need to make a distinction between what we can agree will be
A) best practice for new and future data and the use of vocabularies and what we need to have in place to deal with
B) existing historical data in our systems and historical data that will need to be processed through our systems.
Certainly the latter does not conform to an ideal data model, and never will so we need to do something to handle this without losing information.

The situation is we have 150 or so platform codes of the type “unknown” in one form or another in the platform management system, but assigned to a country. These platforms are linked to data and it is therefore not possible to switch them to “ZZ99”. Furthermore, not all of these data are related to a CSR and never will be (historical biological sampling, multiple ship samples etc.), therefore we would not be able to retain this information about country unless we make dummy CSR’s, which i think is even more of a stretch of the data model principles. It should always be possible to reevaluate historical data using the available meta-data to provide clues as to sources of information, and while this may not be the focus for SeaDataNet it is an important part of the data stewardship that ICES and other organisations provide.

So i think to expand the CSR model, even if it was agreed by the SDN TTT is not the solution, certainly not to the whole problem and will not mean that these 150 codes will cease to exist. I therefore think we need to proceed on the idea of a split in historical recording and current and future recording, there are of course a number of ways we could do this and i think that’s what we should be discussing as although it is important to agree what is desirable, we also need to deal with what is practical and workable.

Sorry for delay in between responses, trying to juggle a few tasks but realise this discussion is important to keep alive.

Neil

From: Lowry, Roy K [mailto:rkl at bodc.ac.uk]
Sent: 01 November 2010 16:12
To: Neil Holdsworth; Dick M.A. Schaap
Cc: Accessions; platforms at biwebs1.nerc-liv.ac.uk; sdn-tech at seadatanet.org
Subject: RE: [Platforms] ROMANIA - MULTIPLE SHIPS OF ROMANIA

Hello Neil,

This discussion hinges on whether vocabulary population should be used in imaginative ways to patch limitations in data models, such as having a vocabulary entry that is a list to implement a one-to-many relationship where the data model dictates one-to-one. I have argued vociferously over the past ten years that this is vocabulary abuse and should be avoided and have put a lot of effort into rebuilding metadata where that practice has been used in the past.

In an ideal world any platform code database should have a hull or equivalent as its fundamental entity to which are attached a series of time-limited attributes such as name, platform class, callsign and flag.  The attributes considered important for cruise reporting may be determined from the original ROSCOP form section A02 as ship name (now represented by a ship code) and the platform type.  Callsign was added as an attribute when the ROSCOP was revised into the CSR. My thinking is that if the ship name cannot be elucidated then we need an unambiguous way of expressing that fact, which is what ZZ99 delivers. This is not bucket term usage.

The question you now raise is whether the flag of the platform is an attribute excluded from the original ROSCOP/CSR that we now feel has sufficient significance for it to be included in the CSR data model.  My vote would be ‘no’, but if the majority feel the answer is ‘yes’ then we should be looking to extend the CSR data model rather than implementing a vocabulary quick fix.

Cheers, Roy.

From: Neil Holdsworth [mailto:NeilH at ices.dk]
Sent: 01 November 2010 13:58
To: Dick M.A. Schaap; Lowry, Roy K
Cc: Accessions; platforms at biwebs1.nerc-liv.ac.uk; sdn-tech at seadatanet.org
Subject: RE: [Platforms] ROMANIA - MULTIPLE SHIPS OF ROMANIA

Hi Dick, Roy,

I disagree with your approach, i know this discussion has surfaced in the past and we seem to be at the same sticking point. The ‘unknown’ term is fine if it is in fact the case that no information is known about the vessel, but in these cases something is known and being deliberately overlooked in order to keep from adding new entries. I don’t like using ZZ99 as a ‘bucket code’ to place everything in that doesn’t meet with the simple model approach. This will cause us some headaches in the future with CSR’s if we simply use ZZ99, as the country listed in the CSR is not necessarily the country where the vessel was chartered from – and we will lose this information.

So before you agree to lose this information, i want you to think about whether this is valuable information for someone looking at the historical data to have access to.

Thanks, Neil.



From: Dick M.A. Schaap [mailto:dick at maris.nl]
Sent: 01 November 2010 13:10
To: Lowry, Roy K
Cc: Accessions; platforms at biwebs1.nerc-liv.ac.uk; sdn-tech at seadatanet.org
Subject: Re: [Platforms] ROMANIA - MULTIPLE SHIPS OF ROMANIA

Dear Roy,

I rather go for a general 'Unknown' term in the Vessel vocabulary than starting a whole list of:
MULTIPLE SHIPS OF ROMANIA
MULTIPLE SHIPS OF BULGARIA
etc
etc
etc

So I encourage using the ZZ99 term and not diluting the Vessel directory with all new entries.

Hope all colleagues agree.

Greetings,

Dick M.A. Schaap
SeaDataNet Technical Coordinator


On 01/11/2010 11:44, Lowry, Roy K wrote:
Dear All,

In cases such as these we should simply use the generic ‘unknown’ ship code (ZZ99).  What guarantee do we have that the flags of these ships were Romanian?

I’ve copied this message to the SeaDataNet TTT list so discussion of this issue doesn’t need to wait until December.

Cheers, Roy.

From: platforms-bounces at biwebs1.nerc-liv.ac.uk<mailto:platforms-bounces at biwebs1.nerc-liv.ac.uk> [mailto:platforms-bounces at biwebs1.nerc-liv.ac.uk] On Behalf Of accessions at ices.dk<mailto:accessions at ices.dk>
Sent: 01 November 2010 10:32
To: platforms at biwebs1.nerc-liv.ac.uk<mailto:platforms at biwebs1.nerc-liv.ac.uk>
Subject: [Platforms] ROMANIA - MULTIPLE SHIPS OF ROMANIA


Dear Platform Group,

The code MULTIPLE SHIPS OF ROMANIA from ROMANIA has been added according to the old definitions of "90" and "99" codes for unknown vessels. The topic of handling "unknown" codes has to be resolved by discussions at SeaDataNet at their next technical meeting.

Original Requester : Gabriel Ion (gion at geoecomar.ro<mailto:gion at geoecomar.ro>)

Code : 7390
Name : MULTIPLE SHIPS OF ROMANIA
Flag : ROMANIA - RO (ISO Country Code)
Platform Class : Vessel of opportunity

General Comments:
We named UVOO_1 for any Unknown Vessel Of Opportunity used by GeoEcoMar prior to year 2002
(added by: Gabriel Ion - 20/10/2010 00:00:00)


Kind regards,
The ICES Data Centre

International Council for the Exploration of the Sea
Email: accessions at ices.dk<mailto:accessions at ices.dk>
Web: http://www.ices.dk

Tel: +45 3338 6718 Fax: +45 3393 4215
H.C. Andersens Boulevard 44-46
1553 Copenhagen V. Denmark

ICES Platform Code Requests Application<http://www.ices.dk/datacentre/requests>
Read the latest ICES Data Centre e-News online<http://www.ices.dk/datacentre/updates/DC_update.htm>

________________________________

This email has been generated by the ICES Platform Code Requests Application

--
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.

________________________________
Denne mail er blevet scannet af http://www.comendo.com og indeholder ikke virus!
________________________________
________________________________
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/20101103/21b5e36d/attachment-0001.html