-Different systems across the government, as well as in the private sector, use different country names or country codes to represent the notion of a “country” within a particular problem domain. These systems may choose to represent countries using a particular standard for county names and country codes. Often times these systems find themselves interacting with other systems that may use another standard for country representation. This makes it difficult to compare and link country-related data in a consistent fashion. We describe our work on the Constellation system using the ISO/IEC 11179 metadata standard to register the various country code sets in a common metamodel. This facilitates management, querying, updating and mapping the elements within the code sets.
INTRODUCTION
There exist numerous international and national standards
for country and country code representations. Some are
designed to represent countries within a certain domain, such as
the ITU-T e.164 [
Unfortunately, there is no unambiguous, standard definition
of the term ―country‖ [
To further complicate matters, these country lists are not static. Dependent territories may become independent, civil wars may split countries, two countries can unify, or a country may simply decide to change its official name. To keep up with changing realities, many of these code sets or standards organizations publish updates to their lists from time to time. This adds a chronological dimension to the maintenance of county code sets.
All of the above factors make it necessary to maintain these code sets together in one registry that can facilitate the
The complex nature of country data poses several challenges for its management in a registry:
A country/geopolitical entity may have an official name and several alternate names, and some of these names may be in multiple languages.
In some country code standards, there may be multiple code formats for each country. For example, in ISO 3166-1, each country has trigraphs, digraphs, and numeric codes, whereas other standards may have only one code format per country.
One country may have multiple codes in one format, such as in the ICAO Nationality Marks code set. In that code set, South African aircraft can bear the nationality marks ―ZS‖, ―ZT‖, or ―ZU‖.
Multiple countries in a single code set may share the same code, such as in ITU-T e.164, where 25 countries share the country dialing code ―1‖.
A geopolitical entity may be a dependency of another country, like a state, territory, province, or outlying area. In ISO 3166, these entities are listed in a separate code set for dependencies, ISO 3166-2. The code set ISO 3166-1 is used for what it considers to be ―toplevel‖ (usually independent) countries. In ITU-T e.164, the dependency may be explicitly written out as part of the country name in parenthesis, as in the case of ―Greenland (Denmark)‖. In other code sets, the administrator is ignored.
Some code sets may have entries for regions (such as Europe or Asia) or transnational groups (such as EU, UN, or NATO) which are not traditionally thought of as countries.
Code sets change over time. New versions of code sets might be released, and updates to individual entities in the code set, like code or name changes or even spelling corrections, might be issued.
Using an ontology can be the first step toward managing
some of the above complexities. The UN FAO (Food and
Agriculture Organization) ontology [
Additionally, SKOS [
Methods of supplying the country code for a SKOS country
concept have also been proposed in [
SKOS-XL [
Using these ontologies are a good start toward registering country code metadata in a way that manages many of the complexities listed above. However, we cannot expect that each country code set we want to register will provide their data in this fashion. Some existing code sets are provided as CSV files, with columns mapping country names to country codes, without any schema at all. Many other code sets are available only as tabular data embedded in web pages or text documents that we converted to CSV. Therefore, it is important that we allow any vocabulary or data format to be used in each particular code set, and rely on our own internal metamodel to accommodate all of these diverse data models in a uniform fashion.
Furthermore, it is important that whatever internal
metamodel we use not be proprietary, and be able to handle
updates to the data without losing the data contained in earlier
versions. Using a standard metamodel would enable a more
widespread use and understanding of our system, and would
also enable it to be used by other kinds of data besides country
codes, to facilitate integration with a wider range of problem
domains. Maintaining a version history of the data would be of
great use if the system were to integrate with other systems that
contain data from an earlier point in time. To accommodate all
these issues, we chose to develop the Constellation system
using the ISO/IEC 11179 metamodel standard [
III. IMPLEMENTING THE ISO/IEC 11179 METAMODEL IN
OWL FOR CONSTELLATION
The goals of the Constellation country code metadata registry are to represent the metadata using a consistent terminology, provide a uniform way of querying the data, manage updates without disrupting previous versions of the data, and facilitate storing relationships between data elements.
The ISO/IEC 11179 metamodel describes a variety of classes, attributes, and associations between classes useful for representing metadata about country objects. In Constellation, we implemented these classes and attributes in an OWL ontology. We represent the set of all countries in a code set as an instance of the Conceptual_Domain class, and the set of country codes in that code set as a Value_Domain. Each Value_Domain can represent one country code format (e.g., digraph or numeric). In most code sets we registered, there is only one code format for each country, so there would be one Value_Domain. In other code sets, for example ISO 3166-1, there are three code formats for each country – the trigraph, digraph, and numeric codes. Each of these formats would be a separate Value_Domain within the Conceptual_Domain for ISO 3166-1. The Value_Domain is made up of a set of Permissible_Values that contain the code (known as the ―permitted value‖) for a country.
Each country entry is modeled as a Value_Meaning within a Conceptual_Domain. The Conceptual_Domain is thus made up of a set of Value_Meanings. Each country can contain several names (official names or other forms of the name), in multiple languages. In order to separate the concept of ―country‖ from that of its name, we use the 11179 Designation class to represent a label or name for a country Value_Meaning. This Designation contains a ―sign‖ property containing the actual country name, and a language identifier property to represent the language used for that name. We use a Designation_Context to describe the ―acceptability‖ of a Designation within the context of a Conceptual_Domain. The acceptability ratings are described in ISO/IEC 11179 as being on a scale of: preferred, admitted, deprecated, obsolete and superseded. Only one Designation per language is ―preferred‖ in a given Context; we use ―admitted‖ to represent the other forms of the name.
Value_Meanings and Permissible_Values each contain a property for begin_date and optional end_date. This is used to represent the time period when the code set considers that value to be part of its official list. Instances of these classes without an end_date are considered to be the latest valid entry. We extended the 11179 standard to add these date fields to the Designation_Context as well. If a code set has several versions (such as when new countries are added, names or codes change, etc.) we can represent this with multiple instances of the class, each with a different date range. A diagram depicting an example of some instances of these classes can be found in Fig. 1.
The 11179 standard also provides a way to depict
relationships among concepts. We use this feature to represent
relationships among countries, such as when an entity is part of
another country or is administered by another country. We also
use this feature to represent relationships among countries that
are likely to be close matches (i.e. the country named ―United
States‖ in the different code sets). These matches can be
generated manually or by machine. Constellation’s
semiautomated country matching algorithm [
The Constellation system can thus be used to keep track of countries, country names, country codes, relationships among countries, and different versions of all of these pieces of information. This system has been successfully applied to over 15 different code sets, and it is easy to add additional ones. Table 1 shows some of the code sets we’ve used along with a brief description of how the code set is used.
IV.
DATA INGESTION AND UPDATES
In order to facilitate the easy ingestion of data of all types, we have two main ingestion workflows: ingesting CSV files and RDF files. For CSV, we require some basic columns such as country name (with separate columns for preferred names, and other languages), columns for dates, and columns for country codes. The column headers need to be one of several that we have pre-defined. In order to ensure that all data is ingested into the system in a uniform fashion, we first convert the CSV into a general-purpose RDF format suited for easy conversion to our OWL representation of the 11179 format. We also take RDF country data in any format (such as UN FAO data, Library of Congress MARC codes, and country currency data, each of which uses a different ontology) and convert that to the general-purpose RDF format using SPARQL 1.1 scripts custom written for each of these RDF ontologies. Once this data is in the general-purpose RDF format, it is then ingested
or one of its specialized agencies and parties to the Statute of the International Court of Justice, or registered by the UN Statistics Division. Part 2 of the standard includes dependencies of the entities in Part 1.
data files on international portfolio capital movements reported to the US Treasury Department via the Treasury International Capital reporting system.
Census Schedule C Used by the US Census Bureau as well
as the Army Corps of Engineers International Union Standard numerical country coding for of Railways use in railway traffic. Used as the owner’s code (3rd and 4th position) of a 12-digit wagon identification number. using another SPARQL 1.1 script to convert the generalpurpose RDF to RDF conforming to our OWL implementation of the 11179 metamodel. begin_date = "1980-01-01" end_date us_pv1: Permissible_Value permitted_value = "US" begin_date = "1980-01-01" end_date
us_des1: Designation sign = "United States" language = "en"
us_des_ctx1:
Designation_Context acceptability = "preferred" begin_date = "1980-01-01" end_date label = "ISO 3166-1" digraph_vd: Value_Domain label = "digraph"
UML object diagram showing an example of Constellation’s use of ISO/IEC 11179 metamodel, edited for clarity Updates to the country code sets are performed in a purely additive fashion. No statements are actually removed from the RDF store when performing update operations on country, country code, or country name data. Each of these entities may be updated separately, allowing for incremental updating of code sets. In the case of ISO 3166-1, updates are issued on an irregular basis every few months as update newsletters. The last full version of ISO 3166-1 was published in 2006, and keeping that code set current requires implementing the updates described in the newsletters. These newsletters might correct a spelling mistake in a name, change one numeric code to another, add a new country, or describe other changes. As stored in the Constellation metadata registry, country entities, codes, and country names each have begin_dates and optional end_dates associated with them. In the case of country names, the dates are associated with the acceptability of its usage in a particular Designation_Context. If a code set removes an entry, it is not actually deleted from our database, but it is marked with an end_date reflecting the date this entry was removed from the code set. Any data that has an end_date is not considered part of the current set of values but as part of an earlier version of the code set.
This use of dates on Designation_Contexts is an extension to the ISO/IEC 11179 metamodel being used in Constellation.
With this extension we can record a country name change in a particular standard. For example, Libya in ISO 3166-1 has changed its name. In 2006, the country was identified in ISO 3166-1 by its official long-form English name, ―the Socialist People's Libyan Arab Jamahiriya‖, in addition to a short form of the name. Following that country’s civil war in 2011, the ISO 3166 Maintenance Agency issued an update to the country’s name in a November, 2011 newsletter, which removed the long-form English name from the entry for the country.
To reflect this change in Constellation, an end_date value is added to the Designation_Context relating the former name to the code set. A new Designation_Context reflecting the name’s new status (in this case, ―deprecated‖) is added and given a begin_date. The RDF statements express the fact that a given country name ceased to be accepted and began to be deprecated on a particular date. If, rather than simply being removed, the name was changed, new statements would be added to relate the new name to the existing country and describe its usage acceptability, context, and the dates when it was used. Fig. 2 shows an RDF diagram using date fields to deprecate the old long-form name of Libya.
11179
When choosing a metamodel, there are many ways to
model the relationships between countries across code sets. Our
first approach was a country-centric approach, where we would
define a unique URI for each country. Constellation’s
semiautomated country matching algorithm [
However, that approach proved problematic for many reasons. First and foremost, two different code sets may not have the same complement of values, so a given URI might not have statements in each code set. Additionally, we don’t know that each standard refers to the exact same country, even if the same name is used. For example, one code set may have an entry for United States, which would include all states and dependent territories. Another code set may have separate entries for the United States, excluding territories, and separate entries for each of the territories. A code set may even include the territories as part of its definition of United States yet still have separate entries for some of these territories. For these reasons, having one URI for United States that would be shared across code sets clearly would not be appropriate, since each code set may have a slightly different interpretation of what is indicated by the country name.
:Designation rdf:type :sign “2011-11-08” “2006-11-20”
:begin_date rdf:type
:end_date http://example.org/dc_libya_0001 :Conceptual_Domain :Context :Designation_Context-scope :acceptability :Designation_Context-scope rdf:type rdf:type http://example.org/des_libya “preferred” :Designation_Context http://example.org/iso3166-1 :Designation_Context-scope rdf:type :Designation_Context-scope “the Socialist People's Libyan Arab Jamahiriya” http://example.org/dc_libya_0002 :acceptability
:begin_date “deprecated” “2011-11-08” Another example of this problem is that in some standards the country China includes Hong Kong and Macau, whereas in other standards each one has its own disjoint representation. If we had one URI for China, there would be ambiguity as to what is meant by that URI—is that the URI of all of China and its dependencies, or of just mainland China? Another example is Sudan and South Sudan—one code set might have a separate entry for South Sudan (which recently became independent from Sudan), as well as for Sudan itself. However, another code set may contain one entry for Sudan, meaning both Sudan and South Sudan. This may be based on the different dates of the code set, if one code set wasn’t yet updated after South Sudan’s independence, or the code set may not recognize South Sudan’s independence.
Another issue with using a unique URI for each country is that two code sets may use completely different names for the same country. The reason that different names may be used in a given code set may be politically motivated. The country identified in the international ISO 3166 standard as ―Myanmar‖ is referred to by the name ―Burma‖ in official U.S. Government documents. The entity identified as ―Taiwan, Province of China‖ in ISO 3166 is called ―Chinese Taipei‖ by the International Olympic Committee. Although these entries have different names, technically they are referring to the same entity.
In all of the above cases, it is debatable whether it makes
sense to use the same URI for the notional country across all
code sets. Since each code set has its own idea of what an entry
actually refers to, it is very difficult to determine if two code
sets are using a country name in exactly the same way [
VI.
QUERYING CHALLENGES USING THE ISO/IEC 11179
The generic nature of the 11179 metamodel adds a great deal of complexity and abstraction to the representation of the data. This poses a challenge for querying, since even a simple query getting all country codes for a given country name can involve traversing a large amount of RDF, resulting in a lengthy and difficult to read SPARQL query. The 11179 Relations which we used to link related concepts to each other also adds a great deal of complexity and extra statements. This is because the 11179 relations model is best suited to scale to ternary, quaternary, and higher-order relations, but it adds additional overhead when dealing with simpler binary relations, as will be explained below.
We attempted to provide shortcuts in the data we ingested, but this resulted in losing some of the benefits of 11179, particularly when it came to updates. We were able to simplify querying using shortcuts such as adding an rdfs:label directly to a Value_Meaning, instead of using Designations with a ―sign‖ property, eliminating an extra statement traversal. However, this did not allow for dates to be provided for the label itself. Eliminating Designation_Context and adding alternate name forms directly in the Designation posed a similar problem managing the acceptability ratings. Since we don’t want to actually delete any data from our system, in order to keep previous versions of data we needed these abstractions of Designation and Designation_Context, so we can maintain dates and acceptability ratings on the Value_Meaning and Designation_Context objects independently.
We experienced similar problems using shortcuts for 11179 Relations. In the 11179 metamodel, traversing the graph from one Concept to another Concept related by a Relation requires stepping through three intermediate objects rather than just a single predicate. We attempted to add convenience predicates (such as skos:broader) for these Relations to provide only one statement linking the two Concepts. As a result of this simplification, the SPARQL queries using the convenience predicates were much shorter and easier to read, but the convenience predicates lacked much of the descriptive power of the 11179 Relations. Fig. 3 shows a simple example of the way that relationships are represented in the 11179 metamodel, compared to how they are represented in SKOS.
Due to our issues with shortcuts, we determined that they
were not a suitable approach for Constellation, and as a result
we have some long, complex queries. We are exploring the use
of SPIN [
CONCLUSION
We have shown how the 11179 metamodel can be used to register, query, and track updates to country code data. We have also demonstrated how 11179 can be used to track relationships among countries, such as country group memberships and administration. We have also shown how we can link similar countries together using 11179 relationships.
Applications of our work extend beyond just country code mapping. We have used it to model country currencies, and even to store thesaurus information, including taxonomies (such as the FAA Aviation Safety Thesaurus and the ETDE/INIS Joint Thesaurus of nuclear energy terminology). broader-role hierarchical-relation broader-end cat feline
We are currently experimenting with applying this research to automated compliance challenges. The 11179 metamodel is useful for registering the metadata related to system policies and rules. We can then track changes to these rules, and relationships between different rules, in the same way we track changes and relationships in country code data. The Constellation registry, using the 11179 metamodel, can thus be used to address these challenges across a variety of metadata.