gs1:Country and "country subdivision" are broken

[VladimirAlexiev]

After https://github.com/gs1/WebVoc/issues/24#issuecomment-866684134 by @mgh128 I took a close look at this class and I think it's broken:

https://www.gs1.org/voc/Country "Country is a complex data type that indicates a country and a country subdivision... see values defined in ISO 3166 and ISO 3166_2":

• a Country is not a data type, it's a political entity!
• gs1:Country should not be defined in reference to some standard, be it ISO 3166. ISO 3166 is not the only (and is a poor) gazetteer of the world.
• gs1:Country should not mention "in which an activity is performed, for example processing, bottling, manufacturing".
  • before a Country has any associated Orgs that perform such activities (recorded in a database), is it not a Country?
  • Can't I use geography to record orgs unrelated to strictly logistics or commercial activities? Eg an Organization that is certified, or that is a law firm, or an advertising firm, etc?
• How many gs1:Country would you have for the US? 47 (or whatever the number of states)? Then the class name makes no sense
• How will you express that each state is part of the US? Link between gs1:Country and gs1:Country? Which link?

Actually I'm not sure what do you mean by "country subdivision"?

• Country.countrySubdivisionCode or PostalAddress.addressRegion?
• Surely in the US the states are the subdivisions, and states are mentioned in https://www.gs1.org/voc/addressRegion?

[mgh128]

gs1:Country is a class that represents a country or subdivision of a country (as defined in https://unece.org/trade/uncefact/unlocode-country-subdivisions-iso-3166-2 ).

Most of these definitions were imported from the GDSN data model and expressions such as 'complex data type' are probably the result of an XML-centric approach to data modelling.

It's correct that gs1:addressRegion is intended to indicate a US state or a UK county or a Bundesland within Germany or a canton within Switzerland or a département in France.

As you'll notice at for example https://unece.org/DAM/cefact/locode/Subdivision/frSub.htm there is overlap between gs1:addressRegion and gs1:countrySubdivisionCode for many countries. Possibly as a result of working in silos.

You're very welcome to submit GS1 work requests to propose improved definitions and justification for these improvements.

[justin2004]

a Country is not a data type, it's a political entity!

classic "representation" vs "actual thing in the world"

Most of these definitions were imported from the GDSN data model and expressions such as 'complex data type' are probably the result of an XML-centric approach to data modelling.

i don't see how XML thinking leads to confusion between representations (data types, record types) and things referred to by representations (actual things in the world like countries). XML is just about tree data structures with schema systems.

this recent blog also highlights the continual confusion between "representations" and "actual things in the world." the writer and the writer's customers are used to talking about and validating representations and they think SHACL is a good tool for that. while OWL is good for talking about things in the world.

[VladimirAlexiev]

Most of these definitions were imported from the GDSN data model

That's no excuse not to make proper classes. Is WebVoc then merely GDSN in "LOD clothes"? cc @philarcher

there is overlap between gs1:addressRegion and gs1:countrySubdivisionCode for many countries. Possibly as a result of working in silos.

Very possibly. Such problems can be avoided, if you describe things for what they are, not for what they appear to be when viewed from piecemeal data integration efforts burdened by backward compatibility considerations. See https://github.com/gs1/EPCIS/issues/207 for guidance ("Ontological Realism").

Another example in #28