3.1. Overview of Administrative Codes in Korea

An administrative code refers to a code system that can be classified in the administrative work of each level of government agency so that they can be handled easily according to a certain code (Ministry of the Interior and Safety [MOIS], 2017). In Korea, the administrative standard code is a set of administrative codes established and published according to the prescribed procedure by standardizing the administrative code required for the administrative work of each level of agency. Note that an administrative code is designed with the goal of classifying and simplifying public agency administrative tasks. The administrative standard code in Korea is a particular type of administrative code that establishes a set of codes necessary for standardizing each agency’s administrative work. The term ‘standard’ refers to code that is the product of government legislation, and is semantically different from general standards in the ICT field. Therefore, this study refers to administrative code rather than administrative standard code.

The Electronic Government Act (MOIS, 2017) provides the legal basis of the administrative code for operating and managing administrative code sets. The purpose of this act is to implement e-government effectively by prescribing basic principles, procedures, and methods for the electronic processing of administrative affairs. According to Article 50, the Korean MOIS may establish a set of administrative codes as needed for sharing administrative information across government agencies. In addition, it may publish them in the official gazette (Article 59, Paragraph 1 of the enforcement decree of the Act) and the head of the administrative agency should comply with the codes established in accordance with Article 59, Paragraph 3. The administrative code covers central administrative agencies (including agencies reporting directly to the president and prime minister), agencies affiliated with central administrative agencies, and local government agencies. The Korean government recommends the use of the administrative code in general administrative affairs via specific guidelines: (1) all agencies should use up-to-date administrative code from the administrative code management system,³ (2) a new informatization project should use the administrative code; if the existing codes cannot be applied, the institution must consult with MOIS in advance to derive application plans, and (3) if the administrative code has not yet been applied in the existing information system, the organization should discuss applying the code and improving interoperability between systems with MOIS.

Eleven types of administrative code were enacted in 1990 to promote e-government. These have been expanded to 314 types through several additional enactments and supplements. All currently established administrative codes are managed through the administrative code management system. The administrative code is classified into 26 subjects as administrative tasks. Note that the administrative codes represent individual subjects as strings, but there is no consistent method for identifying individual subjects. To identify them, all subjects and codes were defined by an ‘S’ and ‘AC’ (Administrative Code) and an arbitrarily assigned number. By subject (Fig. 1), S15 (personal administration) and S21 (local tax payment) were the most numerous with 29 codes (9.24%) each, whereas S2 (construction), S20 (local taxation), and S4 (transportation and logistics) had 25 (7.96%), 24 (7.64%), and 19 (6.05%) administrative codes, respectively.

Fig. 1

Statuses of data by subject.

Each code has a 1:1 match between code value and its meaning. The code value is detailed according to a specific subject as a simple number or blended with other characters, whereas its meaning is a name expressed in natural language. By default, each code consists of a value, a code name, and a comment as a column. The number of columns ranged from a minimum of three (97% of codes) to a maximum of 25. Note that eight administrative codes have more than three columns; as shown in Fig. 2, AC56 (national license), AC17 (construction classification), AC243 (functional category), AC192 (postal code), AC247 (job position), AC61 (international currency), and AC211 (type of disability) have more than four columns, while AC67 (organization), AC83 (road name), AC246 (job classification), AC164 (raw food material), AC298 (university major), AC162 (qualification test), AC79 (standard item), AC163 (food safety classification item), and AC242 (job class) have more than 10 columns. The number of rows in the datasets varied from a minimum of two to a maximum of 391,377. The number of rows is 10 or less for 43% and between 11 and 100 for 41%; approximately six (2% of code types) contain 10,000 or more codes. In particular, AC67 and AC83 have the largest number of columns and rows (25×391,377 and 20×381,415, respectively) because they contain detailed specifications of items in addition to the code values, as shown in Fig. 2. Although AC192 (postal code) and AC115 (administrative district) contain four and three columns respectively, they contain 52,284 and 46,215 codes, respectively. These datasets define all postal codes and administrative districts in the Republic of Korea. These codes are commonly used in government and national information systems.

Fig. 2

Data status by the number of rows and columns. AC67 (391,377), AC83 (381,415), AC164 (28,337), AC246 (6,690, job classification), AC162 (6,690, qualification test), and AC298 (2,592, university major) have a relatively large number of codes and values.

3.2. Knowledge Model

Some existing vocabularies are repurposed to represent the administrative codes at a semantic level, namely schema.org (Guha et al., 2015), RDF (Brickley et al., 2004), and SKOS (Miles & Brickley, 2005). For example, a set of descriptive information is represented by RDF, while the relationship between concepts is described using SKOS. New terms are defined only if they do not correspond to the existing vocabulary. In schema.org, the CategoryCodeSet class describes a set of category code values. CategoryCode expresses a short textual code that uniquely identifies the value using the codeValue property. The two classes can be linked with the hasCategoryCode property, which aims to represent a code contained in a code set. To represent a set of administrative codes, the AdministrativeCodeSet and AdministrativeCode classes are defined as subclasses of the CategoryCodeSet and CategoryCode, respectively. These classes inherit the relationships defined in schema.org. Thus, the hasCategoryCode property of schema.org is reused to connect to both AdministrativeCodeSet and AdministrativeCode. In addition, each code set has one subject and one category; the Subject and Category are subclasses of skos:Concept. The category and subject properties are linked to the corresponding code set.

As shown in Fig. 3, several classes are defined to represent the characteristics of administrative codes. Each code set is maintained by at least one government body. The organization property describes an agency that creates or operates a specific code set. The expected value of this property is a type of Organization within schema.org. A management of organizational codes is classified into four types: general, competent, application, and consignment. The general organization manages overall tasks such as the designation of the competent agency (department) of the administrative code, management of enactments/revisions, and notifications. Competent organizations manage the establishment and revision of sets of administrative codes. Application organizations are responsible for applying administrative codes to an internal information system. Thus, these types are defined as types of Organization classes. Table 1 lists four types. The administrative codes are classified into four management types according to the characteristics of the competent organization. The management type is defined by the ManagementType class. The AdministrativeCodeSet class can be linked to a specific management type with the managementType property.

Fig. 3

Abstract model of administrative code representation. The prefix of the namespace is ‘kasc’ (Korean Administrative Standard Code).

The URI (Universal Resource Identifier) pattern is designed to be consistent and predictable. The experiences and recommendations of linked data communities, including data publishers and consumers, are used to develop common patterns and practices (Juty et al., 2020). A vocabulary URI includes ontology, vocabulary, concept schemes, and code sets. The pattern, combining a domain address and a reference item, is an important resource. The reference item contains the reference data. In this case, a reference item is a government agency, and the reference data are the administrative codes provided by the agency. This relationship is represented by the URI pattern ‘gov’ and ‘code,’ listed in a specific order. Furthermore, the vocabulary and instances of the subject are defined by classifying them into ‘def’ and ‘id,’ respectively. Therefore, the vocabulary URI is provided at http://{domain}/gov/code/def. Note that the individual ontology vocabulary is expressed in CamelCase notation such as ‘http://{domain}/gov/code/def/AdministrativeCodeSet’ and ‘http://{domain}/gov/code/def/AdministrativeCode.’ The URI for representing the dataset is defined as ‘http://{domain}/gov/code/id.’ However, because administrative code values have a relatively simple composition (e.g., ‘01,’ ‘02,’ and ‘03’), it is difficult to ensure the uniqueness of the code URI using only the code value. Therefore, a code identifier is defined by combining code set numbers and code values. For example, instances of the AdministrativeCodeSet and AdministrativeCode classes are defined by combining the individual code value (AC) of the administrative code with the serial number assigned to the code data. The AC creates combinations of administrative code data and code values (e.g. ‘http://{domain}/gov/code/id/AdministrativeCodeSet/AC/{code set number}).

All code datasets, containing 1,011,438 individual codes, were downloaded individually as Excel files. The knowledge graph conversion was done using Python and RDFLib,⁴ and the linking of the government code contained in the open data was done using OpenRefine’s reconciliation service. These codes are transformed into graph-structured data by adopting the proposed knowledge model and the URI model. The administrative code as constructed by the knowledge graph contains approximately 1,011,812 entities and 20,481,472 statements. Table 2 summarizes the entities and statements for each subject in the knowledge graph.

4.1. Data Collection

A small-scale evaluation was conducted to verify the use of knowledge graphs for public data. On the public data portal,⁵ a search for the keyword ‘public’ was conducted and the top five datasets were selected from the results. As shown in Table 3, Dataset D₁ contains types, addresses, and phone numbers of administrative agencies such as post offices, public health centers, and administrative division offices. Dataset D₂ contains information about medical institutions, including the type, number of beds, and addresses. Dataset D₃ is composed of details of individually prescribed medicines (e.g., date of commencement of treatment, appropriate dosage, daily dose, and total dose) on one million patients per year. Dataset D₄ provides the names of businesses in the city of Icheon in Gyeonggi Province such as hair, makeup, and nail art studios, as well as licensing dates and business status. Dataset D₅ provides information on the addresses, locations, types, operating times, and fees for parking lots nationwide. D₃ is a very large dataset (approximately 3.27 GB) with the maximum number of rows, whereas D₄ is relatively small because its data are limited to a specific region. The ‘Views’ and ‘Downloads’ columns represent the numbers of users who previewed or downloaded the file contents via the portal. The portal does not indicate the number of views and downloads of D₅. D₃ has high numbers of downloads, but the other datasets have low numbers compared to the number of views. This suggests that users discover and review these datasets but generally do not download them for actual use.

Individual datasets use administrative codes ranging from 11% to 75% of the total. In D₁, for example, six out of eight columns use administrative codes, while in D₅, only 4 columns out of 36 are used. Table 4 summarizes the column to which the administrative code was applied, the matching administrative code, and the results of data quality improvement in the dataset. Matching with administrative codes proceeds in two steps. First, the column value of the dataset determines selection of the category type and comparison with the administrative code. Since the Korean column names are used as different character strings, whether or not they are semantically equivalent to the administrative code names can be determined. In fact, although the column names of the datasets are different, the same administration code is applied. For example, ‘Organization type’ in D₁ and ‘name of management institution’ in D₅ can apply the same administrative code. There are 108 columns in the collected dataset and 22 (20%) of them have administrative codes. Ten administrative codes were used in the collected datasets by applying semantic matching: AC41 (public health industry), AC67 (public organization), AC115 (administration division), AC117 (healthcare institution), AC136 (sex), AC166 (type of food hygiene business), AC192 (postal code), AC227 (type of parking lot), AC241 (job position), and AC314 (closed status of business). Ordinarily, one code value or name was applied to each dataset. Most matched columns tend to use code names rather than code values. However, C20 and C21 of D5 (provider of name and code, respectively) are the only exceptions in which both values are used together. Note that the percentage of matches across all columns in the dataset was approximately 20%, whereas 36,409,722 rows had administrative code values.

4.2. Data Quality

Individual data sets can use codes or code names as column values. The values in the combined data set, on the other hand, may include a string whose code value is unknown, or a portion of the extracted value rather than the entire code. For example, Seoul Metropolitan City’s administrative code is ‘1100000000’; however, depending on the institution, only two (‘11’) or five (‘11000’) digits may be indicated in front. These values reduce the data’s accuracy. Two metrics (C_mc and A_mc) were used to assess the quality of each dataset: the completeness index (C_mc) refers to the proportion of rows in a specific column that are non-empty and have meaningful values compatible with the domain of the column, while the accuracy index (A_mc) indicates the percentage of cells for a specific column that have values consistent with the administrative code. The evaluation was conducted in two steps: (1) Determine whether the column value of the collected dataset corresponds to the administrative code value; and (2) re-evaluate the match by correcting some of the column values that did not correspond in step 1. Using the results of the secondary evaluation to ascertain the accuracy, all matched values were converted to the URI of the knowledge graph.

The completeness scores C_mc are 0.99 and 1 in the first and second evaluations, respectively, as shown in Table 4. That is, most column values do not have null values or empty strings. Column C16 of D₄ has 181 blanks, however, with a completeness score of 0.85. It includes a zip code, and the correct value can be added in the second evaluation through the address column. By contrast, the average accuracy score A_mc for the first evaluation was 0.65. This score was relatively low compared with the completeness score. In other words, the column value to which the administrative code is applied does not exactly match the administrative code. Accuracy is verified by applying fingerprints provided by OpenRefine’s Key Collision methods to verify code values (Carlson & Seely, 2017). The Key Collision approaches are predicated on the concept of constructing an alternate representation of a value (“key”) that contains just the most valuable information. The following inaccuracies can be found in columns with low accuracy:

Data cleaning can be approached in a variety of ways depending on the type of inaccuracy. Quality improvement is difficult for Type I due to codes that do not exist in the administrative code, so that data refinement does not significantly increase accuracy. For example, the accuracy of C1 and C2 is relatively poor, at 0.25 and 0.31 respectively. In the event of such an issue, it is preferable to register the newly produced or extended code in the administrative code management system and update the open data. Types II and III were improved by separating data values into minimum semantic units and implementing reconciliation services with administrative code provided by knowledge graphs. For example, all C4 values are separated by spaces, and values that match the organization name represented by the knowledge graph are searched. The knowledge graph depicts the hierarchical structures and relationships between organizations in AC67. Through the reconciliation, the separated value finds a matching value and is linked to the knowledge graph’s entities. By deleting embedded special characters and whitespaces, Type IV errors can be significantly reduced. Finally, for Type V, the value is either blank or contains the preceding address system’s value associated to the address. First, blanked fields in C11 received the address value by searching for and entering the hospital name in the address API.⁶ C16 addresses include a postal code, a road name, and a lot number. Cells with no postal code were added by utilizing the address API to look for the value of the record’s street name or lot number address. The second matching result refers to the refined data. The completeness score increased from 0.99 to 1, while the accuracy score increased from 0.62 to 0.88. However, because administrative codes and other codes and categories exist in separate datasets, perfect accuracy cannot be guaranteed.

4.3. Data Interlinking

Public data can be combined or integrated with other publicly available data. However, various datasets necessitate the use of common values or standards for integration. The administrative code knowledge graph is a graph structure that gives the structure and value of administrative codes as a standard vocabulary, and it may be used to connect data based on administrative codes included in public data.

In the five datasets studied here, 22 columns were mapped to the administrative codes. Seven codes were used only in individual datasets, and three codes were commonly used across datasets. Fig. 4 illustrates the relationships among the five datasets based on administrative codes. The established knowledge graph provides a consistent identifier of individual codes, allowing each code to be used to interlink datasets. Although the column names (in Korean) defined in datasets are different, the columns that use the same administrative code are semantically interlinked by the knowledge graph. Codes commonly used between different datasets can be used as reference points for linking them. In particular, AC67 (organization) is commonly applied to 11 columns. This code can be widely used for public data. The administrative division code for C13 of D₃ and C14 of D₄ are the same. Additionally, D₁, D₂, and D₄ commonly use AC192. For example, if relevant datasets exist with the administrative codes, use cases would be extensible.

Fig. 4

Interlinking between datasets with the administrative codes.

There is a limit to generalization of the proposed method based on only five datasets. In the aforementioned example, not all datasets can be linked by an administrative code. However, independently used codes can be used to link different datasets. By constructing the administrative code as a knowledge graph, the task of individually verifying and evaluating the values of a dataset can be significantly reduced, and this can be a starting point for discovering opportunities for linking datasets. In other words, the knowledge graph provides a common criterion for linking various datasets and can present relationships between datasets in a way that computational algorithms can understand.