use ontologically meaningful classes

[VladimirAlexiev]

Linked Data should describe real-world entities, not data records, data structures, messages...

I'd argue that a class like uncefact:LOCODE is not good.

• LOCODEs are assigned to ADM1 country subdivisions, right?
• Schema.org has such a class: http://schema.org/State
  • It's named with abhorring US arrogance (why not Oblast or Land?) but otherwise is very much ok (see its definition).
  • So I think LOCODEs should better be represented as schema:State (see example https://github.com/uncefact/vocab/issues/28#issuecomment-1023343591)
• A class uncefact:LOCODE would be appropriate to describe that identifier (when was it assigned, who assigned it, what did they use for validation), as opposed to the real world entity that it signifies
• LEI has stuff like this, see the distinction between a Legal Entity and its LEI and its national ID (nodes marked (I) in the graph below)
• But I don't think you have such needs for LOCODE codes

[VladimirAlexiev]

This is just an example. If we look through all the vocabs, we'll probably find more examples. If you follow through with #5 and reuse already established vocabs, that will probably make us use more meaningful classes.

[VladimirAlexiev]

@nissimsan commented that LOCODE is not limited to ADM1. Eg Edmonton is a city (Alberta is the province). So schema:State is not appropriate.

However, there is uncefact:CountrySubDivision.

• It has props uncefact:subordinateCountrySubDivision, uncefact:superordinateCountrySubDivision that allow to place it at any level

[nissimsan]

@VladimirAlexiev , we are dismissing this point. LOCODEs are very widely used. @cmsdroff, please add more background.

[VladimirAlexiev]

Of course LOCODEs are very widely used. The issue is whether it's appropriate to have a class of that name.

I think that instead, uncefact:CountrySubDivision should have a field uncefact:locode. @cmsdroff what do you think?

[nissimsan]

I see, @VladimirAlexiev. We didn't understand this was your point when discussing it - reopening. This connection must already exist in the CEFACT model - which classes make use of LOCODEs?

[nissimsan]

Discussion on today's call: Here are Australia's subdivisions: https://service.unece.org/trade/locode/au.htm Here's what we have: https://service.unece.org/trade/uncefact/vocabulary/unlocode-au/

@vladimir, we interpret your request is to add these extra fields (like subdivision) into the vocab classes?

[VladimirAlexiev]

Extra fields are certainly useful.

But my point is to rename this class to Place or merge it to CountrySubDivision, with a data prop locode for the code

[cmsdroff]

Im not sure merging locode into the CountrySubDivision is correct unless i'm missing something (apologies if so)

So were all on same page with what a UNLOCODE is and how its constructed

Example: If we take GBSOU as an example. GB is the ISO Country Code i.e. United Kingdom SOU is the code assigned to Southampton a City in the UK and also a Port (defined by the function)

If we look at the listing in the UNECE site https://service.unece.org/trade/locode/gb.htm

We can see the sub division is HAM which relates to Hampshire this is a county within the UK which houses multiple cities / towns. This can be found at https://github.com/datasets/un-locode/blob/master/data/subdivision-codes.csv as the UNECE see returns a 404 today..

I know looking at this im coming from a place where the starting point is generally the code (UNLOCODE) and I then identify the Country, City and if needed sub division. In EDI messages we typically just see the place name i.e. Southampton.

I guess the other way to look at this is Location > Country > SubDivision > City/Town and then see the UNLOCODE for that location. Then in that case maybe it makes sense in regards to @VladimirAlexiev comment above,

Im not sure if this helps I'm just trying to understand this request better with my freight blinkers fully on ! :)

[nissimsan]

We're discussing this on the call.

The suggestion is to have LOCODE identify a class such as "Geographical Area".

Now, it seems like that area is actually only defined for LOCODEs. So there isn't any better class name we can think of.

Also, note that we are not surfacing this class any longer. I suggest we close this issue.

[cmsdroff]

Here's how DCSA represent as Location for reference https://app.swaggerhub.com/domains/dcsaorg/LOCATION_DOMAIN/2.0.2#/components/schemas/unLocationLocation

[VladimirAlexiev]

@cmsdroff DSCA have it better:

• the object is called "location" not "code" (but why do they duplicate the word in unLocationLocation???)
• then it has locationName, UNLocationCode
• in RDF, it also needs to have a type (class), eg UNLocation