use ontologically meaningful classes about spec-jsonld HOT 11 OPEN

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?

from spec-jsonld.

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.

from spec-jsonld.

@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

from spec-jsonld.

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

from spec-jsonld.

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?

from spec-jsonld.

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?

from spec-jsonld.

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

from spec-jsonld.

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 ! :)

from spec-jsonld.

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.

from spec-jsonld.

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

from spec-jsonld.

@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

from spec-jsonld.