Languages, Countries And Codes Avatar
  1. OMG Specification

Languages, Countries And Codes — Closed Issues

  • Acronym: LCC
  • Issues Count: 47
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
LCC12-15 A number of details with respect to the subdivision codes for various countries have changed in the latest published version of ISO 3166-2 and should be reflected in LCC LCC 1.1b1 LCC 1.2 Resolved closed
LCC12-9 The hasTag property uses a domain of Identifier which causes inference issues for codes LCC 1.1 LCC 1.2 Resolved closed
LCC12-23 Update the metadata in the country representation ontology LCC 1.1 LCC 1.2 Resolved closed
LCC12-21 Revise the metadata for languages and for the specification as a whole in about files LCC 1.1b1 LCC 1.2 Resolved closed
LCC12-27 Incorporate latest subregion changes from ISO LCC 1.1b1 LCC 1.2 Resolved closed
LCC12-11 Clean up ISO 639-1 language codes per the latest updates on the Library of Congress web site LCC 1.1 LCC 1.2 Resolved closed
LCC12-5 L001 and L002 are missing axioms LCC 1.1b1 LCC 1.2 Closed; No Change closed
LCC12-3 SeselwaCreoleFrench is missing an axiom LCC 1.1b1 LCC 1.2 Resolved closed
LCC12-2 The Alpha-3 code for Chinese is missing an axiom LCC 1.1b1 LCC 1.2 Resolved closed
LCC12-1 Name of country with code MK has officially changed to North Macedonia LCC 1.1b1 LCC 1.2 Resolved closed
LCC12-6 The language code 'crs' for the SeselwaCreoleFrench language is missing an axiom LCC 1.1b1 LCC 1.2 Resolved closed
LCC12-13 The names preferred should reflect the admin languages of the country LCC 1.1b1 LCC 1.2 Resolved closed
LCC12-14 The primary URI for a country should be based on its ISO code LCC 1.1b1 LCC 1.2 Deferred closed
LCC12-4 Shikomor is missing an axiom LCC 1.1b1 LCC 1.2 Resolved closed
LCC11-11 URIs defined in the LCC specification need to be revised from http to https LCC 1.0 LCC 1.1 Resolved closed
LCC11-10 Revise the Overview section of the specification to support the current approach to representation of the standards LCC 1.0 LCC 1.1 Resolved closed
LCC11-9 In country SB, URI for region type clashes with that of an actual region LCC 1.0 LCC 1.1 Resolved closed
LCC11-8 Definitions of Languages in 3166-2 ontology refer to language codes LCC 1.0 LCC 1.1 Resolved closed
LCC11-29 sameAs links missing between some Subdivisions and Countries LCC 1.0 LCC 1.1 Resolved closed
LCC11-26 Specification and Module files do not link to their parts LCC 1.0 LCC 1.1 Resolved closed
LCC11-24 The addition of the language tags (LCC-2) introduced a logical inconsistency that must be corrected LCC 1.0 LCC 1.1 Resolved closed
LCC11-19 Create metadata files for LCC version 1.1 LCC 1.0 LCC 1.1 Resolved closed
LCC11-7 There are cases that are syntactically incorrect in the country codes ontology with respect to having both language tags and a datatype of xsd:string LCC 1.0 LCC 1.1 Resolved closed
LCC11-4 Provide capability to reference countries and regions using their code LCC 1.0 LCC 1.1 Resolved closed
LCC11-12 Annex B lists the country region code ontologies as normative, but a few of these have changed since the 1.0 release LCC 1.0 LCC 1.1 Resolved closed
LCC11-3 The language and country codes have been updated by ISO and should be revised accordingly in LCC LCC 1.0 LCC 1.1 Resolved closed
LCC11-2 There is a request for us to add the language tags to the natural language specific properties for language codes LCC 1.0 LCC 1.1 Resolved closed
LCC11-1 The conformance section of the specification is weak LCC 1.0b1 LCC 1.1 Resolved closed
LCC_-4 Flexibility to comply with governmental & corporate guidance. LCC 1.0b1 LCC 1.0 Resolved closed
LCC_-1 The class called ApproximateCoordinates is not well defined and needs properties associated with it LCC 1.0b1 LCC 1.0 Resolved closed
LCC_-24 Language identifiers for alpha-3 codes should be subclasses of language identifier LCC 1.0b1 LCC 1.0 Resolved closed
LCC_-6 Outdated full name for Somalia LCC 1.0b1 LCC 1.0 Duplicate or Merged closed
LCC_-3 Several changes from newsletter IV-14 not reflected LCC 1.0b1 LCC 1.0 Resolved closed
LCC_-5 Missing full name for Papua New Guinea LCC 1.0b1 LCC 1.0 Duplicate or Merged closed
LCC_-15 The definition of writing system in the language representation ontology is incomplete LCC 1.0b1 LCC 1.0 Resolved closed
LCC_-16 The United Nations Standard country or area codes for statistical use (M49) are needed to define regions for FIBO support LCC 1.0b1 LCC 1.0 Resolved closed
LCC_-8 The individual representing the Canadian Province of Newfoundland and Labrador is misnamed LCC 1.0b1 LCC 1.0 Duplicate or Merged closed
LCC_-12 Need to include rdfs:isDefinedBy for every first class ontology element for cases where users load the ontology into a knowledge graph LCC 1.0b1 LCC 1.0 Resolved closed
LCC_-11 Including all subdivision codes in a single ontology is not workable - they should be separated into distinct namespaces / ontologies for ease of use LCC 1.0b1 LCC 1.0 Resolved closed
LCC_-10 Definition for denotes and hasDenotation should better reflect ISO 1087 / 11179 LCC 1.0a1 LCC 1.0 Resolved closed
LCC_-13 The language codes in the 639-2 ontology are missing URI references LCC 1.0b1 LCC 1.0 Resolved closed
LCC_-32 The about files for LCC should be brought up to date LCC 1.0b1 LCC 1.0 Resolved closed
LCC_-31 Equivalent class restrictions in the language representation ontology cause performance challenges LCC 1.0b1 LCC 1.0 Resolved closed
LCC_-7 The spec should document the process for maintaining currency LCC 1.0b1 LCC 1.0 Resolved closed
LCC_-18 The conformance section of the specification is weak LCC 1.0b1 LCC 1.0 Deferred closed
LCC_-14 The tags used on identifiers in the LCC ontologies are unnecessarily complex LCC 1.0b1 LCC 1.0 Resolved closed
LCC_-2 The spec and OWL should indicate which version of ISO specs is reflected LCC 1.0b1 LCC 1.0 Resolved closed

Issues Descriptions

A number of details with respect to the subdivision codes for various countries have changed in the latest published version of ISO 3166-2 and should be reflected in LCC

  • Key: LCC12-15
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: LCC 1.1b1 — Tue, 2 Nov 2021 21:30 GMT
  • Disposition: Resolved — LCC 1.2
  • Disposition Summary:

    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.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

The hasTag property uses a domain of Identifier which causes inference issues for codes

  • Key: LCC12-9
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.1 — Wed, 8 Sep 2021 19:41 GMT
  • Disposition: Resolved — LCC 1.2
  • Disposition Summary:

    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.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Update the metadata in the country representation ontology

  • Key: LCC12-23
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: LCC 1.1 — Tue, 9 Nov 2021 03:37 GMT
  • Disposition: Resolved — LCC 1.2
  • Disposition Summary:

    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

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

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


Incorporate latest subregion changes from ISO

  • Key: LCC12-27
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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)

  • Reported: LCC 1.1b1 — Tue, 30 Nov 2021 01:55 GMT
  • Disposition: Resolved — LCC 1.2
  • Disposition Summary:

    Regenerate Regions files for the changed regions

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

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Clean up ISO 639-1 language codes per the latest updates on the Library of Congress web site

  • Key: LCC12-11
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.1 — Wed, 27 Oct 2021 21:11 GMT
  • Disposition: Resolved — LCC 1.2
  • Disposition Summary:

    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.

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

L001 and L002 are missing axioms

  • Key: LCC12-5
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: LCC 1.1b1 — Thu, 8 Jul 2021 18:02 GMT
  • Disposition: Closed; No Change — LCC 1.2
  • Disposition Summary:

    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.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

SeselwaCreoleFrench is missing an axiom


The Alpha-3 code for Chinese is missing an axiom

  • Key: LCC12-2
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: LCC 1.1b1 — Thu, 8 Jul 2021 17:56 GMT
  • Disposition: Resolved — LCC 1.2
  • Disposition Summary:

    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.

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

Name of country with code MK has officially changed to North Macedonia

  • Key: LCC12-1
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: LCC 1.1b1 — Fri, 16 Aug 2019 00:15 GMT
  • Disposition: Resolved — LCC 1.2
  • Disposition Summary:

    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>

  • Updated: Thu, 31 Mar 2022 19:32 GMT

The language code 'crs' for the SeselwaCreoleFrench language is missing an axiom

  • Key: LCC12-6
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: LCC 1.1b1 — Thu, 8 Jul 2021 18:06 GMT
  • Disposition: Resolved — LCC 1.2
  • Disposition Summary:

    Add the code set and axiom as proposed

    This is added in the XSL for country code processing.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

The names preferred should reflect the admin languages of the country

  • Key: LCC12-13
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: LCC 1.1b1 — Fri, 29 Oct 2021 23:03 GMT
  • Disposition: Resolved — LCC 1.2
  • Disposition Summary:

    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.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

The primary URI for a country should be based on its ISO code

  • Key: LCC12-14
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: LCC 1.1b1 — Fri, 29 Oct 2021 23:07 GMT
  • Disposition: Deferred — LCC 1.2
  • Disposition Summary:

    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.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Shikomor is missing an axiom

  • Key: LCC12-4
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: LCC 1.1b1 — Thu, 8 Jul 2021 18:01 GMT
  • Disposition: Resolved — LCC 1.2
  • Disposition Summary:

    Update entry in the XSL to add the french name

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

  • Updated: Thu, 31 Mar 2022 19:32 GMT

URIs defined in the LCC specification need to be revised from http to https

  • Key: LCC11-11
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0 — Tue, 19 Feb 2019 17:56 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

    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

  • Updated: Tue, 8 Oct 2019 17:57 GMT
  • Attachments:

Revise the Overview section of the specification to support the current approach to representation of the standards

  • Key: LCC11-10
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0 — Tue, 19 Feb 2019 17:52 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Oct 2019 17:57 GMT

In country SB, URI for region type clashes with that of an actual region

  • Key: LCC11-9
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: LCC 1.0 — Tue, 19 Feb 2019 08:03 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

    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

  • Updated: Tue, 8 Oct 2019 17:57 GMT
  • Attachments:

Definitions of Languages in 3166-2 ontology refer to language codes

  • Key: LCC11-8
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: LCC 1.0 — Tue, 19 Feb 2019 07:59 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

    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

  • Updated: Tue, 8 Oct 2019 17:57 GMT
  • Attachments:

sameAs links missing between some Subdivisions and Countries

  • Key: LCC11-29
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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

  • Reported: LCC 1.0 — Tue, 5 Mar 2019 19:57 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Oct 2019 17:57 GMT
  • Attachments:

Specification and Module files do not link to their parts

  • Key: LCC11-26
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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)

  • Reported: LCC 1.0 — Wed, 20 Feb 2019 16:15 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

    Create hierarchical structure and update metadata files for 1.1

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

  • Updated: Tue, 8 Oct 2019 17:57 GMT
  • Attachments:

The addition of the language tags (LCC-2) introduced a logical inconsistency that must be corrected

  • Key: LCC11-24
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0 — Wed, 20 Feb 2019 02:49 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Oct 2019 17:57 GMT
  • Attachments:

Create metadata files for LCC version 1.1

  • Key: LCC11-19
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This constitutes a 1.1 directory and About files.

  • Reported: LCC 1.0 — Wed, 20 Feb 2019 00:19 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

    Create the 1.1 metadata files

    Update the references in the specification.

  • Updated: Tue, 8 Oct 2019 17:57 GMT
  • Attachments:

There are cases that are syntactically incorrect in the country codes ontology with respect to having both language tags and a datatype of xsd:string

  • Key: LCC11-7
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0 — Fri, 15 Feb 2019 22:10 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

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

    Make the change in the ISO-3166 ontologies.

  • Updated: Tue, 8 Oct 2019 17:57 GMT
  • Attachments:

Provide capability to reference countries and regions using their code

  • Key: LCC11-4
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: LCC 1.0 — Wed, 6 Feb 2019 18:18 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

    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>

  • Updated: Tue, 8 Oct 2019 17:57 GMT
  • Attachments:

Annex B lists the country region code ontologies as normative, but a few of these have changed since the 1.0 release

  • Key: LCC11-12
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0 — Tue, 19 Feb 2019 18:04 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

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

  • Updated: Tue, 8 Oct 2019 17:57 GMT

The language and country codes have been updated by ISO and should be revised accordingly in LCC

  • Key: LCC11-3
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0 — Fri, 4 May 2018 23:53 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

    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'

  • Updated: Tue, 8 Oct 2019 17:57 GMT
  • Attachments:

There is a request for us to add the language tags to the natural language specific properties for language codes

  • Key: LCC11-2
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0 — Fri, 4 May 2018 23:50 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Oct 2019 17:57 GMT
  • Attachments:

The conformance section of the specification is weak

  • Key: LCC11-1
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: LCC 1.0b1 — Mon, 21 Aug 2017 17:27 GMT
  • Disposition: Resolved — LCC 1.1
  • Disposition Summary:

    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 ”
  • Updated: Tue, 8 Oct 2019 17:57 GMT

Flexibility to comply with governmental & corporate guidance.

  • Key: LCC_-4
  • Status: closed   Implementation work Blocked
  • Source: Independent ( Leonard Levine)
  • Summary:

    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

  • Reported: LCC 1.0b1 — Tue, 29 Mar 2016 18:22 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT
  • Attachments:

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

  • Key: LCC_-1
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0b1 — Thu, 2 Mar 2017 20:46 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT
  • Attachments:

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

  • Key: LCC_-24
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0b1 — Thu, 24 Aug 2017 17:42 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT
  • Attachments:

Outdated full name for Somalia


Several changes from newsletter IV-14 not reflected

  • Key: LCC_-3
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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
  • Reported: LCC 1.0b1 — Fri, 9 Sep 2016 23:01 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT

Missing full name for Papua New Guinea


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

  • Key: LCC_-15
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: LCC 1.0b1 — Thu, 10 Aug 2017 20:54 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT
  • Attachments:

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

  • Key: LCC_-16
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0b1 — Sun, 20 Aug 2017 19:31 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT
  • Attachments:

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

  • Key: LCC_-8
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0b1 — Tue, 21 Jun 2016 20:11 GMT
  • Disposition: Duplicate or Merged — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT

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

  • Key: LCC_-12
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: LCC 1.0b1 — Thu, 20 Jul 2017 01:38 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT

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

  • Key: LCC_-11
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0b1 — Thu, 20 Jul 2017 01:24 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT
  • Attachments:

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

  • Key: LCC_-10
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0a1 — Fri, 16 Jun 2017 20:58 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT

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

  • Key: LCC_-13
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: LCC 1.0b1 — Thu, 27 Jul 2017 20:58 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT

The about files for LCC should be brought up to date

  • Key: LCC_-32
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: LCC 1.0b1 — Thu, 31 Aug 2017 18:24 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT

Equivalent class restrictions in the language representation ontology cause performance challenges

  • Key: LCC_-31
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0b1 — Thu, 31 Aug 2017 18:21 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT
  • Attachments:

The spec should document the process for maintaining currency

  • Key: LCC_-7
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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/

  • Reported: LCC 1.0b1 — Fri, 11 Nov 2016 02:28 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT
  • Attachments:

The conformance section of the specification is weak

  • Key: LCC_-18
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: LCC 1.0b1 — Mon, 21 Aug 2017 17:27 GMT
  • Disposition: Deferred — LCC 1.0
  • Disposition Summary:

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

  • Updated: Tue, 19 Dec 2017 20:01 GMT

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

  • Key: LCC_-14
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    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.

  • Reported: LCC 1.0b1 — Thu, 10 Aug 2017 20:49 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

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

  • Updated: Tue, 19 Dec 2017 20:01 GMT
  • Attachments:

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

  • Key: LCC_-2
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: LCC 1.0b1 — Fri, 11 Nov 2016 02:26 GMT
  • Disposition: Resolved — LCC 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 19 Dec 2017 20:01 GMT