TRADE/CEFACT/1997/CRP.24 15 September 1997 INTERIM REPORT TO CEFACT FROM THE AD HOC WORKING GROUP ON THE UN/LOCODE The CEFACT Steering Group, at its meeting on 22 May 1997, established an ad hoc working group on the UN/LOCODE. The overall objective of this working group was to propose amendments to UN/ECE Recommendation 16 so that the UN/LOCODE will be able to meet the requirements of its users. The working group was tasked with delivering the following key deliverables: An interim report to the September 1997 session of CEFACT - analysing the problems which users are experiencing with the UN/LOCODE and identifying areas where changes may be required to meet the needs identified by users; A final report to the March 1998 session of CEFACT - proposing a revised version of Recommendation 16 for adoption by CEFACT; To make proposals for long term maintenance and proper dissemination of codes. The working group's interim report, which analyses the problems which users are experiencing with the UN/LOCODE and identifies areas where changes may be required to meet the needs of users, is attached hereto. The working group's initial thoughts on its third deliverable, proposals for long term maintenance and proper dissemination of codes, are set out at the end of this interim report. UN/LOCODE CEFACT AD HOC WORKING GROUP INTERIM REPORT TO CEFACT INTRODUCTION UN/LOCODE - USER REQUIREMENT The over-riding user requirement with respect to the UN/LOCODE may be defined as: a high-quality international standard code set, encompassing all locations served by users' operations and featuring in their systems, successive versions of which are fully upwardly compatible. In its present state, the UN/LOCODE does not meet this user requirement in a number of important aspects. Such shortcomings and the consequent difficulties for users of the UN/LOCODE are set out and analysed below. AREAS OF DIFFICULTIES FOR USERS 1. Upward compatibility i) Deletions and Alterations As noted above, it is a key user requirement that successive versions of the UN/LOCODE should be upwardly compatible - ie, that old versions of the code set can remain in use when new versions are introduced. The deletion or alteration of large numbers of locations from one version of the LOCODE to the next causes particular problems. It is virtually impossible and, at the very least, time-consuming and frustrating for users to have to go back and change codes already in use within their systems. Furthermore, it is difficult to be sure that all users of the LOCODE will be aware of changes that have been made - if they are not aware of the changes, there is scope for obvious compatibility problems. In order to ensure upward compatibility, it is imperative to ensure that existing entries in the UN/LOCODE are never deleted or altered except in truly exceptional circumstances - and in these cases deletions or alterations must be widely publicised. Examples of such circumstances would be where a location has ceased to exist (a military installation that has been closed down) or where the entry listing is demonstrably incorrect (mis-spelt or listed in the wrong country). In all other circumstances, however, existing codes should never be deleted or changed. ii) Provisional Codes The concept of each entry in the UN/LOCODE having an "approval status" contributes significantly to the problem of lack of upward compatibility. Only those entries which have received positive approval (status A*) can be considered to be permanent. Entries requested by users to meet their business needs are included on a conditional basis only (status RQ), pending review by the authorities of the countries concerned which will result in their being confirmed, altered or deleted. In effect therefore, these are merely "provisional" codes although they are not officially called such. The fact that recent versions of the UN/LOCODE have seen the deletion of many of such entries demonstrates their lack of permanence. This process whereby entries requested by users are submitted to review prior to official "approval" may possess conceptual logic but in practice it gives rise to very considerable difficulties. Provisional or otherwise, codes enter into use immediately after they appear in the UN/LOCODE. The deletion or amendment of a provisional code therefore gives rise to identical problems as any other deletion or amendment. In order to satisfy the requirement to avoid all deletions and amendments to codes in the UN/LOCODE, the concept of provisional codes needs to be abolished. All codes need to be permanent as soon as they are published in the UN/LOCODE. The solution appears to rest in the concept of an authoritative gazetteer of locations which could act as the fundamental point of reference for the UN/LOCODE. CEFACT would nominate an authoritative gazetteer of locations (for example, a widely-available and respected world atlas) and all locations listed within it would, ipso facto, qualify for inclusion in the UN/LOCODE. This would provide for pre-approval of a large body of locations which could then be included in the UN/LOCODE immediately on request from a user. The actual trigger for the inclusion of one of these locations would be a request from a user stating a business requirement for it, stemming from its use in trade or transport. Large though this body of pre-approved locations would be, it is likely that any international gazetteer would need to be supplemented by individual national gazetteers (eg, national road atlases) for some countries. The competent authorities in these countries could be asked to nominate an appropriate national gazetteer, showing locations in Roman script. These would provide a further set of pre-approved locations to supplement the core in the international gazetteer where necessary. There would thus exist a very substantial number of pre-approved locations which could be included in the UN/LOCODE immediately on request from a user. Other benefits would accrue too: greater efficiency in the process of code assignment and spelling verification for example (see below for more details). Only in truly exceptional cases should it be necessary to refer individual requests for national authorities for confirmation - the negligible number of such referrals should enable them to be handled speedily and efficiently. iii) Provision of additional capacity A number of suggestions have been made in the last couple of years for providing extra capacity in the event that all 17,576 3-alpha permutations for a particular country are exhausted. These have included the addition of an extra character, the use of "overspill" country codes, the use of 3-alphanumeric codes, the use of the Column 3 (district) code as an integral part of each entry in the UN/LOCODE. Users' preferences in this regard are dictated by the same requirement for upward compatibility. It is therefore vital not to alter the present code structure of a single 2-alpha country code followed by a basic 3-character location code, which is "hard coded" and therefore effectively unchangeable in most users' systems. At the same time, many users have already incorporated the Column 3 (district) code into their systems, particularly with respect to larger and more populous countries. Two possible solutions are therefore apparent for meeting users' requirements for additional capacity in the UN/LOCODE within the inherent constraints of the systems in which the codes are used. Firstly, alphanumeric codes could be used within the existing basic 3-character code structure where all 3-alpha permutations have been exhausted. This would provide capacity for 39,304 locations in each country (assuming that the number 0 and 1 were not used). It should be compatible with all existing systems. Secondly, the Column 3 (district) code could be incorporated as an integral part of each entry, as many users have already done. This would provide, in a 3-alpha scenario for example, for 17,576 locations in each district (US State, UK county, etc) - thus providing sufficient capacity to meet all conceivable demand. It would also help to address the problem of distinguishing between different locations of the same name within one country. At the same time, it would probably require a prescription for use of Column 3 codes in a standard manner; it would also create difficulties for users whose systems are not configured to accommodate more than 3 code characters for each location in each country. 2. Assignment of new codes i) Definition of eligible location It was noted above that it is a key requirement of users of the UN/LOCODE that it should encompass all locations served by their operations and featured in their systems. However, the criteria for inclusion set out in the UN/LOCODE manual (section 6.1) make no reference to the business needs of users. At the moment, the inclusion criteria prevent users' needs from being met. They restrict the coverage of the UN/LOCODE by arbitrarily specifying that, in order to qualify for inclusion, inland locations must be used at least once weekly. This takes no account of a user's business need for a particular code and is profoundly problematic, not least because there is no way to measure the number of times any particular city, town or trading estate receives a goods movement associated with international trade over any given period. Its direct result is that codes requested by users for business reasons have been refused. The inclusion criteria also make no provision for offshore installations, such as FPSOs (Floating, Production, Storage, and Offloading vessels), which are involved in international trade. These factors force users to develop their own in-house codes to cover those locations excluded from the UN/LOCODE. This is inconvenient and troublesome for users. It is also profoundly worrying, in conceptual terms, since the UN/LOCODE can be seen to be giving rise to the very situation which it was designed to prevent, namely the proliferation of various non-standard code sets for locations. Users need to be able to obtain a code for any location which exists and is used in connection with trade or transport. The UN/LOCODE must meet that need. A definition of an eligible "location" needs to be devised which is focused on the UN/LOCODE's function as a business tool. Accordingly, it must accommodate all locations (wherever they are and however often they are used) for which users have a business need for a code. The key elements of such a definition would be that the location demonstrably exists (for example, that it appears in the authoritative gazetteers) and that a business need exists for it to be included in the UN/LOCODE (which may be inferred from a user's request for a code to be assigned to it). In view of the very different prevailing circumstances in the 239 countries featured in the UN/LOCODE, there would appear to be little mileage in seeking to develop detailed rules on the characteristics of all locations therein. In any case, an element of flexibility is important to enable the UN/LOCODE to cater for users' varying business needs, for example by providing codes both for a city and for a harbour within that city. Nonetheless, some guidance on the treatment of sub-locations (railway stations within towns, terminals within ports, etc) could be of benefit to users. It is of note in this regard that implementation guides for transport EDI messages now contain guidance on encoding locations. A tiered approach is taken, with the UN/LOCODE being recommended for the port or location, and other code sets being recommended for more detailed identification of areas within the port or location, such as particular berths, wharves, or warehouses. ii) Allocation process The present process for assigning codes attracts much adverse comment, for being protracted and slow. Users tend to request a new code as and when the need arises for a code to represent a particular location which does not already feature in the UN/LOCODE. There is thus a degree of urgency to most requests with a response being needed within one or two working days, notifying the user of the code which has been assigned. As noted above, this code needs to be permanent, not provisional. The protracted nature of the present process can be seen to derive from the requirement to seek approval for each individual request from the respective national authority. For so long as this cumbersome process continues to be required, delays appear inevitable. The proposal outlined above to consider each request against an authoritative gazetteer of locations, nominated in advance, would obviate the need for this process - responses to users' requests could be generated within a timescale which reflected users' own requirements. 3. Code quality i) Spelling The spelling of location names is a touchstone for the quality of the UN/LOCODE. Incorrect spellings undermine its credibility in the eyes of users. It is therefore very important that the spelling of the names of these locations is always correct. The use of an authoritative gazetteer of locations would be invaluable in this regard. It would provide a definitive reference tool against which the spelling of all locations could be verified, at the time the request was made. This would have clear value, both in the avoidance of simple errors and in the transliteration into the Roman alphabet of placenames which originally exist in other character sets. This would provide an important assurance of quality. The use of such a gazetteer of locations as the fundamental point of reference for the UN/LOCODE would also help to address the difficulties which users presently encounter in trying to cope with location names for which multiple spellings exist. Without expressing any opinion as to the correctness or otherwise of any particular spelling, the gazetteer would lay down a standard spelling of the names of all locations for the purposes of the UN/LOCODE. The opening disclaimer of the UN/LOCODE manual at present states that the UN/LOCODE is provided as a service to users and that no opinion should be inferred about the legal status of any of its listings. This could be expanded to state that no opinion was being expressed as to the legal status of the spelling of the name of any location but that, as a service to users in the framework of trade facilitation, the UN/LOCODE standard spelling should be acceptable for the purposes of trade and transport. The nomination of the supplementary national gazetteers by national authorities would of course provide the favoured spelling of the names of locations in the countries concerned. ii) Diacritic characters Recent versions of the UN/LOCODE have seen the introduction of diacritic characters to supplement the standard Roman alphabet and permit a more accurate rendering of the names of locations in some countries. However, this has given rise to problems for users outside those countries whose systems are incapable of supporting such characters. Both in its coverage and in its use, the UN/LOCODE is essentially international - indeed its importance is as the one standard international set of codes for locations. It must therefore be readily usable in all countries and must be suitable for use in EDI transmissions between systems in different countries. Its contents should therefore conform to the pertinent international EDI standards: the level B character set of ISO 9735 (EDIFACT application level syntax rules), set out in paper TRADE/WP4/R782. This would provide for all letters A-Z (in both upper and lower case), numerals, spaces and some punctuation marks and other symbols - all of which are in common use internationally. Diacritic characters would not thereby be included although users using the UN/LOCODE for purely domestic applications in those countries where such characters is in use could of course add them to meet their own business requirements. iii) Format The existing format of the UN/LOCODE, as an ASCII file, is not user-friendly. The combination of the file's large size and the absence of any tabs or commas make it impossible for users to import it directly into a speadsheet or database within their own systems. On receipt of each new version of the UN/LOCODE, users are obliged to undertake extensive reformatting. Users would find it more useful if the UN/LOCODE were made available in a format which could be imported directly into databases or spreadsheets within their own systems. It should therefore be made available in this format. iv) Code Maintenance and Management It is apparent that the principal factor which has prevented the UN/LOCODE from being managed and maintained like most other code sets is the overly complex and protracted procedures which govern the processing of requests for additional entries. The suggestions above would greatly simplify the process of the day-to-day running of the UN/LOCODE. When this has been done, two distinct ongoing functions of management and maintenance would appear to be required to ensure that the UN/LOCODE is able to meet the needs of its users: maintaining and disseminating the UN/LOCODE database, processing requests for additional entries, etc.strategic management issues, such as promoting the use of the UN/LOCODE among statistical agencies and securing acceptance of the standard spelling of location names in the context of trade and transport. There is little overlap between these two functions and it might well therefore be appropriate to handle them separately. The handling of the strategic management function is probably best considered with reference to CEFACT's proposed methods of overseeing its other code sets. With regard to the day-to-day maintenance and dissemination of the UN/LOCODE, there is a strong feeling that users would receive a better service if this function were performed under a contract between CEFACT and a chosen service provider (perhaps a commercial organisation), in which clearly defined standards of service were laid down. The present arrangements whereby the UN/LOCODE is issued only once annually, the timing of each issue is unpredictable, and for months after each issue the previous version continues to be displayed on the Website are not reflective of users' needs. An arrangement whereby the maintenance and dissemination were undertaken according to a binding contract between CEFACT and a professional service provider would provide assurances that users' requirements for an efficient and certain service whereby all code requests are processed within one or two working days and updated versions of the code set are available on a more frequent and regular basis would be met, while the UN/LOCODE would continue to be published with the imprimatur of CEFACT and the UN, so imbuing it with important international authority. -------------------------------------------------------------------------------------------------------------