These changes tend to be details in most cases, corrections, and additions, although a few are more substantive

Process latest ISO XML file with revised XSL

ISO file was downloaded 10/30/2021 and has version identifier ="72".
Note that the sequence of names has changed in several cases: this does not make a semantic difference to the result.
The XSL is updated as per other issues for this RTF, for example to reflect the processing of names.

The domain of hasTag is constrained to be an Identifier. So if it is used to provide a text symbol or code string associated with a code, the code is inferred to be an identifier, which is not always the case. The domain declaration should be eliminated.

Loosen the domain of hasTag and the constraint on Identifier for how many things an identifier can identify

This resolution affects Section 8.2, Languages, in the specification as well as the machine-readable files for the Language Representation ontology.

The metadata in the header of the country representation ontology should be revised to correspond to the revisions in other ontologies.

Update the metadata in the country representation ontology

Update the revise the metadata, including copyrights and owl:versionIRI in the country representation ontology to align with the rest of the LCC 1.2 release

The current about files refer explicitly to version 1.1 and should be revised accordingly for the 1.2 version. These changes are in metadata only, not substantive.

Revise the metadata for languages and for the specification as a whole in about files

This resolution makes changes to informative ontologies only, and has minimal on the specification document. The metadata files are updated to reflect LCC 1.2 rather than 1.1, with minor adjustments to elements such as copyrights and so forth. No substantive changes are addressed in this issue.

1. Revise Table 7.2: Prefix and Namespaces for Languages, Countries and Codes (LCC) to replace the prefix and URI for the 1.1 versions of the about files to be
lcc-spc-1.2 https://www.omg.org/spec/LCC/1.2/AboutLCC-1.2/
lcc-spc-1.2-reg https://www.omg.org/spec/LCC/1.2/AboutLCC-1.2-Regions/

2. Revise Table 8.1: Languages Module Metadata to replace the owl:versionIRI for the AboutLanguages file with https://www.omg.org/spec/LCC/20211101/Languages/AboutLanguages/

3. Revise Table 9.1: Countries Module Metadata to replace the owl:versionIRI for the AboutCountries file with https://www.omg.org/spec/LCC/20211101/Countries/AboutCountries/

The changes are dated 25Nov2021 and summarized as follows:
CN
Change of spelling of CN-NX; Update List Source

ET
Addition of regional state ET-SI; Update List Source

FR
Addition of category European collectivity in eng & fra; Addition of European collectivity FR-6AE; Addition of metropolitan collectivity with special status FR-69M; Change of category name from metropolitan department to metropolitan collectivity with special status for FR-75; Change of subdivision code from FR-75 to FR-75C; Addition of category overseas departemental collectivity in eng & fra; Change of category name from overseas department to overseas departemental collectivity for FR-971, FR-974, FR-976; Addition of category overseas unique territorial collectivity in eng & fra; Change of category name from overseas department to overseas unique territorial collectivity for FR-972, FR-973; Deletion of category name overseas department; Deletion of overseas region FR-GF, FR-GP, FR-MQ, FR-RE, FR-YT; Deletion of category name overseas region; Change of parent subdivision of FR-67, FR-68; Deletion of parent subdivion of FR-971, FR-972, FR-973, FR-974, FR-976; Modification of Remark part 2; Update List Source and Code Source

GB
Addition of subdivision categories country and province in eng & fra; Modification of remark part 2; Addition of country GB-ENG, GB-WLS, GB-SCT; Addition of province GB-NIR; Addition of parent subdivisions

GT
Change of subdivision code from GT-AV to GT-16, GT-BV to GT-15, GT-CM to GT-04, GT-CQ to GT-20, GT-ES to GT-05, GT-GU to GT-01, GT-HU to GT-13, GT-IZ to GT-18, GT-JA to GT-21, GT-JU to GT-22, GT-PE to GT-17, GT-PR to GT-02, GT-QC to GT-14, GT-QZ to GT-09, GT-RE to GT-11, GT-SA to GT-03, GT-SM to GT-12, GT-SO to GT-07, GT-SR to GT-06, GT-SU to GT-10, GT-TO to GT-08, GT-ZA to GT-19; Update Code Source

HU
Change of name of HU-CS; Update List Source

IS
Deletion of municipality IS-BFJ, IS-DJU, IS-FLD, IS-SEY; Addition of municipality IS-MUL; Update List Source

KH
Change of spelling of KH-1

LT
Change of spelling of LT-05, LT-14, LT-39; Assign parent subdivision to LT-01 through LT-60; Update List Source

LV
Deletion of republican city LV-JKB, LV-VMR; Deletion of municipality LV-001, LV-003, LV-004, LV-005, LV-006, LV-008, LV-009, LV-010, LV-012, LV-013, LV-014, LV-017, LV-018, LV-019, LV-020, LV-021, LV-023, LV-024, LV-025, LV-027, LV-028, LV-029, LV-030, LV-031, LV-032, LV-034, LV-035, LV-036, LV-037, LV-038, LV-039, LV-040, LV-043, LV-044, LV-045, LV-046, LV-048, LV-049, LV-051, LV-053, LV-055, LV-057, LV-060, LV-061, LV-063, LV-064, LV-065, LV-066, LV-069, LV-070, LV-071, LV-072, LV-074, LV-075, LV-076, LV-078, LV-079, LV-081, LV-082, LV-083, LV-084, LV-085, LV-086, LV-090, LV-092, LV-093, LV-095, LV-096, LV-098, LV-100, LV-103, LV-104, LV-105, LV-107, LV-108, LV-109, LV-110; Change of category name from republican city to state city for LV-DGV, LV-JEL, LV-JUR, LV-LPX, LV-REZ, LV-RIX, LV-VEN; Addition of municipality LV-111, LV-112, LV-113; Update List Source

NP
Change of spelling of NP-P5; Modification of remark part 2; Update List Source

PA
Addition of indigenous region PA-NT; Update List Source

RU
Correction of language from ‘urd’ to ‘rus’ for RU-PSK, RU-ROS, RU-PRI

SI
Addition of remark part 2

SS
Typographical correction of SS-BW (deletion of the extra space between el and Ghazal)

Regenerate Regions files for the changed regions

Applied the XSL to the complete ISO download and confirmed the regions changed were the ones expected.

There are minor differences in naming for various natural languages that should be updated, and the LoC has now published linked data codes for the ISO 639-1 languages that can be added to augment what we currently have for consistency. These changes mainly impact the language codes ontology for ISO 639-1 with minimal impact on the specification document itself.

Include Library of Congress links in the ISO 639-1 language codes

The correction for this issue is to add owl:sameAs axioms to each of the language individuals to point to the relevant links on the Library of Congress web site, and modify references to the language names expressed in English, French and/or German to match what the LoC publishes in a handful of cases where there were differences.

This resolution reflects a change to the machine readable file for the ISO 639-1 Language Codes. It also requires a change to the specification, in Section 8.4 Ontology: ISO 639-1 Language Codes.

These two individuals defined in the country codes ontology are missing axioms for the denotes property

L001 and L002 are missing axioms

This error, detected through the use of an OWL RL rule engine, is due to lack of proper recognition of owl:sameAs axioms and is therefore a red herring. The issue should be closed with no change as a consequence.

<https://www.omg.org/spec/LCC/Countries/ISO3166-1-CountryCodes/SeselwaCreoleFrench>, which is defined in the country codes ontology, is missing a value for the french language name

Add axiom for French name in the XSL

<lcc-lr:hasFrenchName xml:lang="fr">créole seselwa</lcc-lr:hasFrenchName>

<https://www.omg.org/spec/LCC/Languages/ISO639-2-LanguageCodes/chi> is missing an identifies Chinese axiom in the ontology

The Alpha-3 code for Chinese is missing an axiom

The correction for this issue is to add a single axiom to the individual for the code 'chi' stating that it identifies the Chinese language.

This resolution reflects a change to the machine readable file for the ISO 639-2 Language Codes. It also requires a change to the specification, in Section 8.5 Ontology: ISO 639-2 Language Codes, as given below.

The names and, unfortunately, its URI, need to be updated.
The old element should be marked as deprecated.

Reflect name changes and the URI change for MK

The name changes are handled by the XSL applied to the latest ISO XML file.
The URI change is additionally addressed as follows:
1) retain the deprecated individual
<owl:NamedIndividual rdf:about="&lcc-3166-1;Macedonia">
<owl:sameAs rdf:resource="&lcc-3166-1;NorthMacedonia"/>
<owl:deprecated rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</owl:deprecated>
<rdfs:isDefinedBy rdf:resource="&lcc-3166-1;"/>
</owl:NamedIndividual>

2) use the new URI in the UN-M49-RegionCodes file:
<rdf:Description rdf:about="&lcc-3166-1;NorthMacedonia">
<lcc-cr:isSubregionOf rdf:resource="&lcc-m49;SouthernEurope"/>
</rdf:Description>

3) use the URI in the CountryCodes-Adjunct mapping file:
<lcc-cr:Country rdf:about="&lcc-3166-1-adj;MK">
<owl:sameAs rdf:resource="https://www.omg.org/spec/LCC/Countries/ISO3166-1-CountryCodes/NorthMacedonia"/>
</lcc-cr:Country>

The language code, defined in the country codes ontology, is missing an isMemberOf <code set> axiom

Add the code set and axiom as proposed

This is added in the XSL for country code processing.

At the moment they default to the English name if that's present

Create a label for each admin language; use codes not names for subdivision URIs

The current algorithm is at the mercy of the sequence of names in the XML, which as we've seen can vary between releases of the ISO XML file.
This also affects the URI for the subdivisions, which currently uses the same name.
The resolution then is to update the algorithm used for the subdivisions as follows:

• for URI, use the official code followed by "-Subdivision". For example:
  &lcc-3166-2-za;ZA-EC-Subdivision"
• For backward compatibility use the previous algorithm to create a sameAs triple:
  <owl:NamedIndividual rdf:about="&lcc-3166-2-za;Oos-Kaap">
  <owl:sameAs rdf:resource="&lcc-3166-2-za;ZA-EC-Subdivision"/>
  </owl:NamedIndividual>

For regionkinds the ISO XML has only a numeric id attribute, so that is used used with the country code and suffix -RegionKind.
For example:
rdf:about="&lcc-3166-2-za;ZA-428-RegionKind"
<owl:NamedIndividual rdf:about="&lcc-3166-2-za;Provinsie">
<owl:sameAs rdf:resource="&lcc-3166-2-za;ZA-428-RegionKind"/>
</owl:NamedIndividual>

Likewise territories only have a numeric id attribute so that is used in the URI with the coutnry code, suffixed -Territory. For example:
&lcc-3166-2-za;ZA-1120-Territory"
<owl:NamedIndividual rdf:about="&lcc-3166-2-za;MarionIsland">
<owl:sameAs rdf:resource="&lcc-3166-2-za;ZA-1120-Territory"/>
</owl:NamedIndividual>

• For names create a rdfs:label for each name with a language code which is an administrative language. For example South Africa has:
  <lcc-cr:usesAdministrativeLanguage rdf:resource="&lcc-639-1;Afrikaans"/>
  <lcc-cr:usesAdministrativeLanguage rdf:resource="&lcc-639-1;English"/>
  <lcc-cr:usesAdministrativeLanguage rdf:resource="&lcc-639-1;SouthNdebele"/>
  <lcc-cr:usesAdministrativeLanguage rdf:resource="&lcc-639-2;Pedi"/>
  <lcc-cr:usesAdministrativeLanguage rdf:resource="&lcc-639-1;SouthernSotho"/>
  <lcc-cr:usesAdministrativeLanguage rdf:resource="&lcc-639-1;Swati"/>
  <lcc-cr:usesAdministrativeLanguage rdf:resource="&lcc-639-1;Tswana"/>
  <lcc-cr:usesAdministrativeLanguage rdf:resource="&lcc-639-1;Tsonga"/>
  <lcc-cr:usesAdministrativeLanguage rdf:resource="&lcc-639-1;Venda"/>
  <lcc-cr:usesAdministrativeLanguage rdf:resource="&lcc-639-1;Xhosa"/>
  <lcc-cr:usesAdministrativeLanguage rdf:resource="&lcc-639-1;Zulu"/>

For countries generate rdfs:label applied to the short-name.
Using South Africa this gives:
<rdfs:label xml:lang="af">Suid-Afrika</rdfs:label>
<rdfs:label xml:lang="en">South Africa</rdfs:label>
<rdfs:label xml:lang="nr">Sewula Afrika</rdfs:label>
<rdfs:label xml:lang="st">Afrika-Borwa</rdfs:label>
<rdfs:label xml:lang="ss">Ningizimu Afrika</rdfs:label>
<rdfs:label xml:lang="tn">Afrika-Borwa</rdfs:label>
<rdfs:label xml:lang="ts">Afrika-Dzonga</rdfs:label>
<rdfs:label xml:lang="ve">Afrika Tshipembe</rdfs:label>
<rdfs:label xml:lang="xh">Mzantsi Afrika</rdfs:label>
<rdfs:label xml:lang="zu">Ningizimu Afrika</rdfs:label>

And for the subdivision ZA-EC
<rdfs:label xml:lang="af">Oos-Kaap</rdfs:label>
<rdfs:label xml:lang="en">Eastern Cape</rdfs:label>
<rdfs:label xml:lang="nr">iPumalanga-Kapa</rdfs:label>
<rdfs:label xml:lang="st">Kapa Botjhabela</rdfs:label>
<rdfs:label xml:lang="tn">Kapa Botlhaba</rdfs:label>
<rdfs:label xml:lang="ts">Kapa-Vuxa</rdfs:label>
<rdfs:label xml:lang="ve">Kapa Vhubvaḓuvha</rdfs:label>
<rdfs:label xml:lang="xh">Mpuma-Koloni</rdfs:label>
<rdfs:label xml:lang="zu">Mpumalanga-Kapa</rdfs:label>
(these are in addition to the hasLocalShortName triples)

The name(s) used in the skos:definition arbitrarily use the first name. For example for region kind and subdivision name.
<skos:definition>the provinsie of Oos-Kaap in the country of South Africa</skos:definition>

This resolution also removes the redundant "individual representing" from the skos:definition text.

with the name-based URI as an alternative using sameAs.
The name-based URIs are unstable (we have had several countries changing name but not ISO code) and the algorithm (e.g. for replacing spaces and punctuation) makes them unpredictable. Most external datasets use the code not the name, requiring an expensive lookup to create a link using the name-based URI.

Defer to next major version

Despite the fact that use of sameAs should reduce the impact of churn based on the ISO names for countries, this is considered too large a change to make at this minor version 1.2 release/revision.

It is also controversial with many users, including some FIBO users, that believe the country-based URI is more appropriate for a semantic standard that is used by business analysts.

The Shikomor language, defined in the country codes ontology, is missing an axiom for its French name

Update entry in the XSL to add the french name

<lcc-lr:hasFrenchName xml:lang="fr">comorien</lcc-lr:hasFrenchName>

This changes the set of canonical URIs in Table 7.2 and elsewhere in the text of the standard as well as in the machine-readable files.

Replace http:// in all URIs with https:// except for specific references to LCC 1.0

In both the specification and machine readable files.
Note that this resolution was applied after all resolutions up to and including LCC11-19

The current version of the specification breaks the country codes for regions up into individual ontologies by region, and includes the U.N. M49 macro region codes, which are quite useful for implementations that only need a subset of the region codes. This should be reflected in the specification.

In addition, a sentence should be added at the end of the overview that states that there is no need, based on feedback from the user community, to provide the ODM XMI or UML XMI for the ontologies containing individuals for regions, only for the primary ontologies and country codes. Thus, the LCC 1.1 specification no longer includes those artifacts.

Minor language issues, such as the use of the term 'trigraph' and wrong reference to '630-4' rather than '639-4' in that section should also be corrected.

Update section 1.2, Overview to fix language and coverage issues

This update affects text only, and provides a more accurate representation of the contents of the specification and related artifacts than the LCC 1.0 version of the document.

The region/type has URI of &lcc-3166-2-sb;CapitalTerritory.
Since the full namefor the subdivision is "Capital Territory (Honiara)" the proposal is to make the URI into &lcc-3166-2-sb;CapitalTerritoryHoniara.

Make the URI into CapitalTerritoryHoniara

Since the full name for the subdivision is "Capital Territory (Honiara)" the proposal is to make the URI into &lcc-3166-2-sb;CapitalTerritoryHoniara.

In the specification, add a row to the table C-2 as follows, after the row for MZ-MPM:
SB-CT CapitalTerritoryHoniara

The definitions for ALL the Languages in 639-2 say "Language code for X language", rather than "X language". The question is what to do when it's a family. We don't want to say "Batak languages language". The proposal is to say X family if it's of class LanguageFamily e.g. Batak languages family".

Update skos:definitions for language individuals in 639-2

The skos:definition will depend on the class of the language individual. Assuming the label is X then the definition will be:
class IndividualLanguage: X language
class LanguageFamily: X family
class RemainderGroup: X remainder group
class SpecialPurposeLanguageConcept: X special purpose language concept

There are 7 gaps where the ontology is missing sameAs links where a subdivision of one country has a country code in its own right. The comments in the ISO XML file make clear that these should be linked but the XML file is missing the <subdivision-related-country> elements that normally (in the 22 other cases) accompany such comments, and which the automated processing relied on.
The gaps are for:
CN/TaiwanSheng
CN-HongKongSAR
CN/MacaoSAR
FR/Guyane
FR/Martinique
NO/JanMayen
NO/Svalbard

Add the missing sameAs links

Three OWL Regions files are affected: for CN, FR, NO.
Note that, as for the existing sameAs regions, the labels on the subdivision are suppressed in order to avoid failing restrictions when combined with those on the Country.

The Specification file AboutLCC should link to the module files AboutLanguages and About Countries and each should link to their ontologies, all using dct:hasPart (as per FIBO)

Create hierarchical structure and update metadata files for 1.1

The hierarchical structure uses dct:hasPart. A new file AboutRegions is needed.

Adding the language tags to the individuals created an inconsistency when running a reasoner over the set of ontologies that include the reference data. This is due to the fact that one cannot use a language tag with a datatype property whose range is xsd:string in OWL 2 / RDF 1.1. Rather, the range must be either rdfs:Literal or rdf:langString in order to tag individuals with a particular language.

The language tags are quite useful, and were requested by the LCC user community, so the correction needs to be made to the LanguageRepresentation and CountryRepresentation ontologies to enable use of the tags.

Revise the base language and country representation ontologies to use rdfs:Literal rather than xsd:string in properties for names

The RDF 1.1 specification introduced a new type for inclusion of language tagged strings in vocabularies, called rdf:langString. This datatype is not compatible with xsd:string. In the case of properties for language and country names, the original ontologies used xsd:string in the range and in class restrictions on Language and Country that became logically inconsistent when the language tags were introduced in the individuals.

This resolution changes the property range(s) and related restrictions from using xsd:string to rdfs:Literal, which is the common parent of xsd:string and rdf:langString, thus eliminating the inconsistency.

This constitutes a 1.1 directory and About files.

Create the 1.1 metadata files

Update the references in the specification.

According to the RDF specification, a string can be typed as xsd:string if it does not contain a language tag, but must be typed rdf:langString if it includes a language tag. See https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_langstring for details.

Currently, our country codes ontologies (those including the named individuals) have both a language tag and are typed as xsd:string, for various hasName properties, which should be corrected.

This applies strictly to the machine readable files, with no impact on the specification document itself.

Remove rdf:type=&xsd;string where there is a xml:lang language tag

Make the change in the ISO-3166 ontologies.

Many external datasets reference countries using their 2 character code. These can be very large sets (e.g. the GLEIF dataset which covers more than a million legal entities, each with a jurisdiction and up to 5 addresses).
To transform them to RDF referencing the Country in LCC requires a reverse lookup of the code to find the LCC URI which is based on the country name. For conversion of large sets this could be very expensive. It would be far more convenient to have a URI based on the code which could be used in the dataset with no lookup needed. I have already generated such a set of URIs with sameAs triples linking them to the normative LCC URIs.
The problem is worse for region codes where the reverse lookup would need to be in one of 200 different ontologies (one per country). I have generated a single file of sameAs triples covering all the regions.

Rather than people such as myself independently doing this on an ad hoc basis, these 2 files should be officially published by OMG as an optional part of LCC.

Create new Informative adjunct ontologies and document in the spec

The adjunct ontologies are simply created by processing the RDF files for ISO3166-1, and all the ISO3166-2 SUbdivisions and for each Country/Subdivision creating a sameAs triple linking its URI with one based on the code.
For example :
<lcc-cr:CountrySubdivision rdf:about="&lcc-3166-2-adj;US-DE">
<owl:sameAs rdf:resource="http://www.omg.org/spec/LCC/Countries/Regions/ISO3166-2-SubdivisionCodes-US/Delaware"/>
</lcc-cr:CountrySubdivision>

The set of URIs and country names should be updated to reflect the latest set of countries and related region ontologies per the U.N. revisions (e.g., Eswatini, formerly Swaziland) in Annex B; the reference to the ODM XMI and UML XMI at the end of the annex should be updated per the decision not to include these artifacts as a part of the specification, though they can be generated from the RDF/XML as needed for any implementation.

Change name of Swaziland to Eswatini in Annex B

Change the country name.
(Note that the rows are ordered by country code which has not changed, so the entry does not need to be moved).

The LCC language codes should be maintained on a regular basis when such changes are made by the Library of Congress (the registration authority for the language codes for ISO 639-2).

The country codes should also be maintained on a regular basis when revised by the UN / ISO working group.

This applies strictly to the machine readable files.

Update the individuals based on the latest files from ISO

For ISO-3166, the latest ISO XML file dated Feb 14th, 2019 was automatically processed (using XSLT, checked into GitHub) to create regenerated ISO3166-1-CountryCodes and Regions/ISO3166-2-SubdivisionCodes-CC files which included updated metadata such as new versionIRIs.

For M49 the latest spreadsheet was diffed with the previously used one: the only change needed was renaming of Swaziland to Eswatini. The change to North Macedonia was not applied due to it not yet being recognized by ISO.

For ISO-639 the list of changes https://www.loc.gov/standards/iso639-2/php/code_changes.php from the official Library of Congress site was manually processed.

Revised text:
1. In Table 7.2, on page 12, revise the 3rd line in the table (a) from 'lcc-spc-1.0-reg' to 'lcc-spc-1.1-reg', and (b) from 'http://www.omg.org/spec/LCC/1.0/AboutLCC-1.0/' to 'http://www.omg.org/spec/LCC/1.0/AboutLCC-1.1/'.

2. In paragraph 8.2, Module:Languages, first bullet, change '630-4' to '639-4'

3. In Table 8.4: ISO 639-1 Language Codes Ontology Metadata, (a) change the owl:versionIRI from 'http://www.omg.org/spec/LCC/20170801/Languages/ISO639-1-LanguageCodes/' to 'http://www.omg.org/spec/LCC/20190201/Languages/ISO639-1-LanguageCodes', and (b) add the following change note at the end of the table, under the existing change note: ' skos:changeNote The http://www.omg.org/spec/LCC/20190201/Languages/ISO639-1-LanguageCodes.rdf version of this ontology is current as of 14 February 2019, based on the US Library of Congress site.'

4. In Table 8.5: ISO 639-2 Language Codes Ontology Metadata, (a) change the owl:versionIRI from 'http://www.omg.org/spec/LCC/20170801/Languages/ISO639-2-LanguageCodes/' to 'http://www.omg.org/spec/LCC/20190201/Languages/ISO639-2-LanguageCodes', and (b) add the following change note at the end of the table, under the existing change note: ' skos:changeNote The http://www.omg.org/spec/LCC/20190201/Languages/ISO639-2-LanguageCodes.rdf version of this ontology has been revised to reflect addition of the languages Standard Moroccan Tamazight (code zgh) and Montenegrin (code cnr). The codes themselves are current as of 14 February 2019, based on the US Library of Congress site.'

5. In Table 9.4: ISO 3166-1 Country Codes Ontology Metadata, (a) change the owl:versionIRI from 'http://www.omg.org/spec/LCC/20170801/Countries/ISO3166-1-CountryCodes/' to 'http://www.omg.org/spec/LCC/20190201/Countries/ISO3166-1-CountryCodes/', (b) add the following change note at the end of the table, under the existing change note: 'skos:changeNote The http://www.omg.org/spec/LCC/20190201/Countries/ISO3166-1-CountryCodes.rdf version of this ontology has been revised to reflect the issues addressed by the LCC 1.1 FTF report. The country codes and related metadata contained herein are current as of the February 2019 revision to the online code set.', and (c) change 'dct:issues' to 'dct:issued' and '2017-07-20T22:26:02.631805+02:00' to '2019-02-14T00:48:51.124818+01:00'.

6. In Table 9.6: M49 Region Codes Ontology Metadata, (a) change the owl:versionIRI from 'http://www.omg.org/spec/LCC/20170801/Countries/UN-M49-RegionCodes/' to 'http://www.omg.org/spec/LCC/20190201/Countries/UN-M49-RegionCodes/', (b) add the following change note to the table: 'skos:changeNote The http://www.omg.org/spec/LCC/20190201/Countries/UN-M49-RegionCodes/ version of this ontology has been revised to reflect the issues addressed by the LCC 1.1 FTF report. The country codes and related metadata contained herein are current as of the February 2019 revision to the online code set.', and (c) add the following issuance date after the new change note: 'dct:issued 2019-02-14T22:26:02.631805+02:00'

ISO639-1-LanguageCodes.rdf: add lang tags to
lcc-lr:hasEnglishName
lcc-lr:hasFrenchName
lcc-lr:hasGermanName

Note: this applies to the machine readable files primarily.

Add the language tags to the Languages

In ISO639-1-LanguageCodes.rdf and ISO639-2-LanguageCodes.rdf: add xml:lang tags to
lcc-lr:hasEnglishName
lcc-lr:hasFrenchName
lcc-lr:hasGermanName

And remove the rdf:datatype=&xsd;string.

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”.

Update the Conformance Clause

In Clause 2, Conformance

• In the first paragraph replace “These fall into the following categories” by “These are as follows:”
• remove 2nd paragraph starting (1) which duplicates the bullet beneath labelled 1.
• in bullet 1, add the following after "formally imports": “all the LCC ontologies” and add the following at the end: “with no resulting logical inconsistencies”
• in bullet 2, replace “but may not import all of them” by “with no resulting logical inconsistencies”
• in bullet 3, replace “, but may not formally import, one or more of the LCC ontologies” by “one or more of the LCC ontologies or individuals”
• delete bullet 4
• in the last paragraph replace “In all four (4) cases, implementers” by “For any conformance point, any references to individuals must use, or provide a mapping to, the standard LCC URI, and any properties accessed or stored within the scope of LCC must use or provide a mapping to the standard LCC URI. Implementers ”