Many users of Language, Countries, and Codes (LCC) require flexibility to change the mappings to countries and codes to comply with governmental and corporate guidance (laws, regulations, rules, etc.). The LCC specification should clearly describe how to implement such flexibility.

A potential solution would be to create an annex with an example that shows how this can be done, and that describes the kinds of patterns that the spec encourages people follow to ensure that the reasoning would work for them.

From the RFC,
"In all four (4) cases, implementers may extend any of the LCC ontologies as necessary, to add language or country codes required between releases, or to add application-specific codes needed to address various requirements. Typically such extensions will entail ontology-level conformance. We encourage implementers to submit any requirements for extension to the relevant LCC task force, as appropriate." Chapter 2, page 12.
Others occurrences of this issue in the RFC include:

Country is defined as "in the context of ISO 3166"; and some entities do not use ISO 3166 or not all of ISO 3166. Some use ISO 3166 only indirectly tailored to their own requirements. Similarly with CountryIdentifier and CountrySubdivision. Chapter 4. Terms and Definitions.

The ISO 3166 Country Representations in Section 9.2, 9.3, and elsewhere may present challenges to users that do not strictly use ISO 3166 names and codes.

Table 9-2 Country Representation Ontology Metadata is dependent on ISO 3166, esp. sm:directSource ,

UN and other names are not universally accepted. Table 9-3 Country Representation Ontology Details

This will probably ripple through the other normative and non-normative (informative) deliverables associated with this RFC including RDF/OWL and XMI.
======

Chapter/Section (additional): 9.4 Ontology: ISO 3166-1 Country Codes

Flexibility to comply with governmental & corporate guidance.

The resolution to this issue affects several clauses in the specification, including (1) clause 1, Scope, primarily in its introduction, (2) clause 4, Terms and Definitions, and (3) clause 9.3 Ontology: Country Representation. This resolution depends on the resolution to LCC-14.

Care has been taken to limit dependencies on ISO 3166, to generalize definitions, and to refactor the ontology slightly to make it easier to incorporate other code sets by combining the former country and subdivision codes into a common region identifier.

The resolution to another issue, issue LCC-7, also provides an informative annex and related source scripts that automate the process of generate the codes themselves, which users can modify to incorporate other code sets.

In fact, what this class should be called is something like GeographicArea, and then provide a means by which one can add multiple points, such as longitude and latitude to that area.

We also need to incorporate the concept of Continent, which would be a child of GeographicArea so that we can divide the subdivisions of countries into continents to support evolution and management of those subdivisions.

The class called ApproximateCoordinates is not well defined and needs properties associated with it

The resolution to this issue affects clause 9.3 Ontology: Country Representation. It depends on the resolution to LCC-14 and LCC-4.

Some of the changes requested herein were integrated in LCC-4, such as providing a class called GeographicRegion, which is used as the basis for the revisions described below. The addition of certain specific regions, such as continents, are covered by the resolution to LCC-7, but the resolution of this issue does not depend on the resolution of LCC-7 per se.

Currently, all alpha-3 language identifiers are subclasses of alpha-3 code, but are not direct subclasses of language identifier. This may be misleading for users of the ontology.

In addition, some of the definitions for kinds of language identifiers should be more tightly constrained, for example, an individual language identifier should be equivalent to something that identifies an individual language, rather than simply a subclass of that restriction.

Language identifiers for alpha-3 codes should be subclasses of language identifier

The resolution to this issue affects clause 8.3, Ontology: Language Representation, and depends on the resolution to issues LCC-14 (LCC-17).

The modification to the model includes (1) making IndividualLanguageIdentifier, MacrolanguageIdentifier, CollectiveLanguageCode, and SpecialLanguageCode direct children of LanguageIdentifier, and (2) changing the restrictions on each of these identifiers to state that the classes are equivalent to identifying the appropriate classes of languages (e.g., making IndividualLanguageIdentifier equivalent to the restriction on the identifies property such that an individual language identifier identifies an individual language).

The changes affect Figure 8.9 Definition of Individual and Macrolanguage Identifiers and Figure 8.10 Definitions of Identifiers for Language Groups and Special Purpose Concepts, on page 30, as well as Table 8-3, on pages 32-34.

The full English name was changed to "Federal Republic of Somalia" in 2013
as per newsletter VI-16 http://www.iso.org/iso/iso_3166-1_newsletter__vi-16_name_change_for_somalia_en.pdf

Outdated full name for Somalia

This issue is resolved by the automated generation of the country codes as described in the resolution of LCC-3.

See http://www.iso.org/iso/iso_3166-1_newsletter_vi-14_name_change_state_of_palestine.pdf.
Specifically:

• superfluous short local name for Bulgaria
• languages missing for Bouvet Island
• for Jersey, administrative language of French missing
• for Palestine the local short name is the old one
• wrong language (sub?)code for Seychelles

Several changes from newsletter IV-14 not reflected

The approach to addressing these revisions taken by the FTF has been to automate the process of generating the ISO 3166-1 country codes based on the material published by ISO in their online catalog. See LCC-7 for details with respect to the process for automated code generation.

The OMG has subscribed to the catalog and used the results to automatically generate the ISO3166-1-CountryCodes ontology, based on the latest version of the codes published as of July 20th, 2017, using the revised country representation ontology as defined by LCC-14, LCC-4, and LCC-1. The resolution of this issue depends on the resolution of these issues. The corresponding codes are now current as of this latest publication by ISO.

The corresponding machine readable files will be provided as a part of the overall FTF report.

It should be "Independent State of Papua New Guinea"
as per http://www.iso.org/iso/iso_3166-1_newsletter__vi-15_name_change_for_papua_new_guinea.pdf

Missing full name for Papua New Guinea

This issue is resolved to the resolution of LCC-3, based on automatic generation of the latest version of the country codes.

Writing system should be a subclass of arrangement, and should include relationships with the orthography and script for the system.

The definition of writing system in the language representation ontology is incomplete

The resolution to this issue affects clause 8.3, Ontology: Language Representation, and depends on the resolution to issue LCC-14.

The modification to the model includes adding Arrangement as the parent of WritingSystem, and augmenting it with two restrictions, (1) has someValuesFrom Orthography and (2) has someValuesFrom Script. The changes affect Figure 8.4 Systems and Processes in Language Analysis, on page 27, as well as Table 8-3, on page 35.

The Standard country or area codes for statistical use (M49) include geographic regions, such as continents, regions that are smaller than continents but larger than countries, and sub-regions, all of which are used for statistical reporting to the International Monetary Fund, among other uses. M49 codes integrate the ISO 3166 country codes and assign them to relevant regions or sub-regions (e.g., continents, sub-continents, etc.) which are needed for regulatory / statistical reporting purposes, among other uses.

The United Nations Standard country or area codes for statistical use (M49) are needed to define regions for FIBO support

The resolution to this issue affects clause 7.2, Namespace Definitions, clause 9.2, Module: Countries, and introduces a new clause 9.6 Ontology: Standard Country or Area Codes for Statistical Use (M49). The primary contribution of this resolution is embodied in the new machine-readable files associated with clause 9.6, with the other changes supporting that modification.

It depends on the resolution to issue LCC-4 and LCC-11 for revisions to the Country Representation ontology and related namespace and table updates.

The machine-readable files associated with this resolution are provided as a part of the FTF report.

The concept in the ISO 3166-2 subdivision codes ontology for the Canadian Province of Newfoundland and Labrador is misnamed as simply Newfoundland. Also, the Canadian Territory of Nunavut should be represented and is missing.

The individual representing the Canadian Province of Newfoundland and Labrador is misnamed

The resolution to this issue has been addressed in the resolution of LCC-11, which automates the process of creating ontologies for all of the subdivision codes contained within ISO 3166-2.

For ease of use in certain applications where "follow your nose" does not work, such as for ontologies loaded into a knowledge graph, it is helpful to have an rdfs:isDefinedBy statement for every first class entity. The object for the triple should be the IRI of the ontology that contains the entity (i.e., all classes, properties, and individuals).

Need to include rdfs:isDefinedBy for every first class ontology element for cases where users load the ontology into a knowledge graph

This issue resolution affects the machine readable files for LCC only, and does not change the text of the specification.

The resolution is to add an annotation to every class, property and individual in every LCC ontology that has the form:

<rdfs:isDefinedBy rdf:resource="[ontology abbreviated IRI]"/>

for example,

<rdfs:isDefinedBy rdf:resource="&lcc-lr;"/>

for the LCC Language Representation ontology.

Currently, the set of subdivision codes available in LCC (which only reflect North America) are all in one namespace and ontology. They should be split into an ontology per country containing the relevant regions for ease of use and maintenance purposes.

Including all subdivision codes in a single ontology is not workable - they should be separated into distinct namespaces / ontologies for ease of use

Based on review of the number of countries who have submitted subdivision codes to the U.N. which are codified in ISO 3166-2, the FTF has made the following changes:

1. Retained the top level ISO 3166-2 ontology, but only for the purposes of defining the code set and one necessary geographic region kind (Territory) for use in multiple region codes ontologies.

2. Created a submodule within the LCC/Countries module for Regions

3. Automated the generation of all of the region codes contained in the latest publication of ISO 3166-2 (i.e., as of July 20, 2017), with one ontology per region. The resulting URI for each ontology takes the form: http://www.omg.org/spec/LCC/Countries/Regions/ISO3166-2-SubdivisionCodes-<xx>/, where <xx> represents the alpha 2 ISO 3166-1 code for the country or other region for which subdivision codes are available.

The complete list of normative ISO3166-2 region-specific ontologies is included in a new annex B (normative) which lists the machine readable files, rather than listing them on the cover of the specification, due to the number of files. The machine readable files are attached to the report rather than to this issue resolution.

The definitions for these properties are not identical to those under development for the MVF submission, which provides better correlation to the ISO standards. If the LCC definitions are revised, then MVF can simply reuse the LCC ontologies rather than creating new, incompatible definitions.

Definition for denotes and hasDenotation should better reflect ISO 1087 / 11179

Revise the definitions for these two properties in the body of the specification, clause 8.3, Language Representation, in Table 8-3, Properties section, on page 35.

Update the metadata for the ontology, including the versionIRI in Table 8-2, and in the ontology itself, and revise the definitions as stated below.

They assume the default (or local base) URI and should include an explicit reference.

The language codes in the 639-2 ontology are missing URI references

Lack of explicit, rather than default, URIs is a problem particularly in cases where the ontologies are used in a knowledge graph / repository / triple store, whereby the header information for the ontology is not easily available for query and other application purposes. The resolution to this is to ensure that all individuals in the 639-2 ontology are fully qualified with the URI of the ontology as well as the local name.

The resolution affects the machine-readable files for LCC only, and has no impact on the text of the specification. The corrected URIs are part of the revised machine readable files for the FTF report, are available in GitHub
at https://github.com/edmcouncil/lcc.git for review. Correcting all of the individuals was accomplished using automation (xslt), thus ensuring that no individuals were missed or errors introduced that might otherwise be difficult to find.

The about files and related module descriptions in the specification should be brought in line with the rest of the changes in the FTF report (primarily with respect to version IRIs).

The about files for LCC should be brought up to date

Section 9.2 was brought up to date through the resolution of LCC-16, but the version IRI (and associated about file, which is informative) in clause 8.2 should be updated, and the about file for the overall specification (AboutLCC.rdf), machine-readable should also be revised accordingly.

Additionally, the versionIRIs for both ISO 639 language codes ontologies should be revised in sections 8.4 and 8.5, corresponding to the revisions made to the machine readable files to incorporate rdfs:isDefinedBy, etc.

The current machine-readable about files will be provided in an informative zip file as a part of the FTF report.

A modification made by LCC-24 changed certain restrictions on specific language identifiers from subclass (necessary) restrictions to equivalent class (necessary and sufficient) restrictions. While the change was semantically correct, it introduced unintended performance challenges in reasoning by blowing up the search space.

A compromise determined by the FTF is to relax those restrictions back to subclass restrictions, but retain the other changes made by the resolution to LCC-24.

Equivalent class restrictions in the language representation ontology cause performance challenges

The resolution to this issue affects clause 8.3, Ontology: Language Representation, and depends on the resolution to issues LCC-14 and LCC-24.

The modification to the model includes reversing the change to the restrictions on Individual, Macrolanguage, Language Group and Special Purpose identifiers made by LCC-24 to state that the classes are equivalent to identifying the appropriate classes of languages rather than subclasses of classes that identify the relevant languages.

There should be an annex to explain the approach to reflecting updates from ISO e.g. subscribing to ISO notifications and raising issues reflecting the changes. There should also be targets for frequency/lead time/

The spec should document the process for maintaining currency

Members of the FTF agree that maintaining currency is an issue. For the purposes of the FTF, the OMG has subscribed to the ISO Online Catalog for the ISO 3166 codes specifically, although that subscription will expire sometime in 2018. The ISO 639 language codes appear to change less frequently than the country codes, and so for the time being, and it’s not clear that one can subscribe to ISO for those, although it might be possible to subscribe to SIL for the 639-3 codes. Our current recommendation is that the OMG continue to subscribe to the ISO online catalog so that the LCC RTF can be automatically notified of changes to the ISO 3166 codes and revise the LCC specification to incorporate such changes as appropriate. The RTF should also plan to review any modifications to the language codes when planning an update to the country codes, and make any required changes as needed.

Having said this, the FTF also recognized the need to automate generation of the codes themselves to facilitate such revisions. As a part of the resolution to this issue, the FTF has produced a set of instructions and scripts to fully automate generation of the ISO 3166-1, ISO 3166-2, and corresponding U.N. M49 region codes. We recommend that these instructions and scripts be included in an informative annex to the specification for use by future RTFs. We also recommend that in the future, RTFs consider augmenting the scripts to automate generation of the language codes, possibly including other parts of the 639 standard, if requested by LCC users and given that potential intellectual property issues with SIL can be addressed. Given that the process is fully automated, it should be possible to revise the codes within a meeting cycle of notification of a change.

The resolution to this issue introduces a new Annex C, Generating Ontologies from External Code Definitions, together with four informative machine-readable files that contain the scripts used to generate the current set of normative country and region codes.

It depends on the resolution to issue LCC-16 and on the resolutions on which LCC-16 depends for revisions to the Country Representation and Language Representation ontologies that are required for automated code generation.

There are a number of issues with the conformance section of the specification, including, but not limited to:

(1). The following conformance point is not a complete sentence (if you ignore what's in parens): it ends “formally imports” without saying what.
1. Specification-level conformance with the RDF/OWL ontologies, which means that the subject application formally imports (i.e., through owl:imports statements in another ontology or via loading the full set of ontologies for reference in a knowledge base that supports RDF/OWL);

And the above duplicates the 2nd para labeled (1), so the duplication should be eliminated.

(2) The use of “may not” in points 2 and 3 is ambiguous since it could be taken as meaning “shall not”. “Might not” would be clearer. And it’s compounded by the fact that we say ontology-level conformance entails linked-data-conformance but not that specification-level entails ontology-level.

(3) Conformance point 3 seems pretty weak – could an application contain one LCC URL to be conformant? Does it even need to be derefenceable? Is this email conformant because I include http://www.omg.org/spec/LCC/Countries/ISO3166-1-CountryCodes/Albania ? Or does it need to be the ontology itself i.e. http://www.omg.org/spec/LCC/Countries/ISO3166-1-CountryCodes/ ?

(4) Maybe we should be saying something about applications that allow people to establish and follow links to LCC individuals, and continue to follow the links within LCC?

(5) We also need to define “subject application”: is it an application or another (set of) ontologies that are conformant? Is FIBO conformant? Also item 4 refers to “another UML model”.

The conformance section of the specification is weak

The LCC FTF team recognizes that the current conformance section needs to be rewritten, but also that a rewrite should be undertaken with some thoughtfulness. It should also be based on usage experience. As such, we have decided to put off addressing this until we have had time to collect input from our user community (notably, from FIBO users and some government organizations).

There should be a single hasTag property on all identifiers (that is not functional), rather than separate hasLanguageTag, hasCountryTag, and hasSubdivisionTag properties of their respective identifiers.

The tags used on identifiers in the LCC ontologies are unnecessarily complex

In the LanguageRepresentation ontology, (1) rename the hasLanguageTag property to hasTag, (2) eliminate the isFunctional constraint (since it's possible that there might be duplication across multiple code sets), (3) revise the definition of the property to be "a unique combination of alphanumeric characters corresponding to the identifier", and (4) add a skos:note that states, "Text-valued tags are included here as they may be useful for automated transformation or encoding systems, such as those used to produce IETF compliant language tags in XML."

Also, move the domain of hasTag from LanguageIdentifier to Identifier, and move restriction LCC-13 from LanguageIdentifier to Identifier, but loosen the constraint from an exact cardinality of 1 to some values from. Move the property and restriction from the Definition of Language Identifier diagram to the Definition of Identification Schemes and Identifiers diagram, and include the "has" property on the Definition of Language Identifier diagram. It was in the model as the parent property of hasDenotation but not on a diagram.

2. In the CountryRepresentation ontology, (1) eliminate the hasCountryTag data property and restriction lcc-cr-13 on that property, and (2) eliminate the hasSubdivisionTag property (no corresponding restriction).

People should be able to easily discover which updates have been incorporated already.

The spec and OWL should indicate which version of ISO specs is reflected

A. For the Language ontologies (documented in clause 8), add a statement to the metadata in the ontologies themselves, in a change note or history note in the header of the ontology, that provides an indication of the currency of the codes. For example, to the header of the LanguageRepresentation, the following statement should be included in the history note: "The LCC 1.0 version of this ontology, published in advance of the 2017 New Orleans OMG Technical Meeting, was current as of 31 July 2017 with respect to the ISO 639-1 and 639-2 codes included herein."

These notes indicating the currency should also be incorporated in the metadata sections of the specification for each ontology, and the versionIRIs corresponding to the language codes individuals (given that the actual individuals are not documented in the specification) revised as appropriate.

B. For the country representation ontology, which is intended to support multiple geographic coding systems, no currency statement is required. However, for the country codes, subdivisions, and regions, a more formal statement indicating the date that the codes were published by ISO / the U.N. is available and should be incorporated in the metadata for each of the ontologies.

The resolution to this issue depends on the resolution to LCC-14, which revises the versionIRI for the ontology.