edi3 / edi3-json-ld-ndr

GNU General Public License v3.0
0 stars 2 forks source link

handling some tricky cases in UN/LOCODEs #34

Open onthebreeze opened 3 years ago

onthebreeze commented 3 years ago

We need to extend the JSON-LD code lists part of the NDR to handle some interesting cases that are highlighted by the UN/LOCODE list:

please update NDR - maybe a special section for LOCODE - and also the published example.

Fak3 commented 3 years ago

there is a "function" column in the LOCODE list with values like "1--45--- ". I think these need to be expanded to something more meaningful - so not just "locode:function":"1--45--- " but instead base it on section 3.6 of https://www.unece.org/fileadmin/DAM/cefact/locode/UNLOCODE_Manual.pdf

These numbers should be reflected in rdfs type of the location:

{
    @id: locodes-ad:ADCAN
    @type: [edi3:Location, locodes:SeaPort, locodes:RailTerminal]
    rdfs:label: "Canillo"
    rdf:value: ADCAN
}

1 = locodes:SeaPort 2 = locodes:RailTerminal 3 = locodes:RoadTerminal 4 = locodes:AirPort 5 = locodes:PostalOffice 6 = locodes:MultiModal 7 = don't know, should consult UN/LOCODE experts what does this mean - "reserved for fixed transport functions (e.g. oil platform)"

B = don't know, should consult UN/LOCODE experts what does this mean - "border crossing" 0 - ignored

Fak3 commented 3 years ago

there are cases where the same code appears twice with different names. for example FI-LPP appears twice - once called Lappeenranta (Villmanstrand) and again with description Villmanstrand (Lappeenranta). this appears to be an "also known as" relationship. It's the same physical location and so the same locode but has two sames (depending on whether you prefer to the finnish name or the swedish name for the place. another edge case for the NDR.

This can be modelled with language-strings:

{
    @id: locodes-ad:FI-LPP
    @type: [edi3:Location, locodes:Port, locodes:RailTerminal]
    rdfs:label: [
       {
         "@value": "Lappeenranta",
         "@language": "fi",
        },
       {
         "@value": "Villmanstrand",
         "@language": "sw",
        }
    ],
    rdf:value: "FI-LPP"
}
Fak3 commented 3 years ago

there are some cases where the same location appears in two country lists. For example the FR (france) list includes a location called "GP-BBR". This is really a reference to a location (Basse Terrre) in another country (Guadeloupe) that is governed by the first country (france). Kind of a colonial legacy. I think this might be best implemented as a property to the root list (ie the list of countries) where there is an indicator saying which country controls my country list. usually the same (eg AU controls the AU list) - but sometimes it would say FR controls the GP list...

Such relationships can be reflected with different properties.

{
    @id: locodes-ad:GP-BBR
    @type: [edi3:Location, locodes:SeaPort, locodes:RailTerminal]
    "rdfs:label" : "Basse Terrre",
    "locodes:managingAuthoriry": "locodes:FR",
    "rdf:value": "GP-BBR"
}
Fak3 commented 3 years ago

Since the individual coutnries locodes are managed as separate namespaces, it might be useful to reflect such namespacing in the full url, in the most familiar way, using subpath '/' sign: i.e. replace locodes-ad:ADCAN with locodes:AD/CAN

Related to #20

Fak3 commented 3 years ago

It's a huge list that is governed at country level so I think it's a candidate for a country level file granularity with a root country list to link them all. So around 200 lists, not one. nevertheless, the visual renderer needs to make it look like one - and maybe we make it easy to get the whole list when needed

I suspect that for most developers discoverability and automation it will be more convenient to grab the whole huge machine-readable list of all countries and their subordinate locodes full metadata at a single place. I.e. resolving full http url of locode:AU or locode:AU/SIG should result in the full machine-readable list of all locodes of all countries, no matter how huge it is.