[Platforms] ROMANIA - MULTIPLE SHIPS OF ROMANIA

Wed Nov 3 08:56:45 GMT 2010

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] On Behalf Of accessions at ices.dk
Sent: 01 November 2010 10:32
To: 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)

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
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 <http://www.comendo.com>  og indeholder ikke virus!

________________________________

________________________________

Denne mail er blevet scannet af http://www.comendo.com <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/b0ffb481/attachment-0001.html 