ID体系とコードリスト

2016年11月18日公開
2016年11月18日最終更新

1. IDとコード

共通語彙基盤において、IDは識別子(Identifier)を意味し、その適用範囲の中で、対象を特定し他のものと曖昧さなく区別できるようにするための情報(符号)です。コードはある範囲の情報を、機械処理しやすく簡潔に示すために付与する符号です。

1.1 IDおよびID体系

IDは対象を曖昧さなく識別することを目的とします[1]。ID体系は、

  • 適用範囲(スコープ)とするグループを定め、
  • そのグループに属するメンバー各々に一意の符号を割り当てる

ことによって構成されるものです。たとえば社員番号(会社を適用範囲とし、その社員を識別)、利用者ID(サービスを適用範囲とし、その利用者を識別)などをID体系の例として挙げることができます。表形式のデータを作成する場合は、少なくともその表を適用範囲としたIDを用意し、レコードを識別できるようにすることがとても重要です。

図1

図1: IDは適用範囲の中でのみ意味をもつ。コア語彙では適用範囲をID体系として定義し、IDからic:体系で関連付ける。体系、IDともにURIとして扱えることが望ましい。
IDの機能と設計
IDはその適用範囲の中でのみ意味をもちます(社員番号は音楽サービスのユーザIDとしては使えません)。逆にいえば、IDは適用範囲が示されないとその識別機能を果たすことができません。
IDは識別が基本機能であり、並べ替えや分類などのための構造は一般には意識されません。大規模なID体系では階層的な識別子が用いられることもありますが、多くの場合は割り当ての権限委譲を目的としています(たとえばISBNやURI)。
IDの識別値に組織名(の略号)などを含めると、組織変更があった場合に支障が出る可能性があります。IDは可能な限り恒久的に利用できるように付与してください。
IDの指すもの
ある対象について語るとき、IDによってその対象自身(主語)を指し示すことができます。「ID●●●であるメンバーの所属は□□□だ」という形です。IDが目的語の位置に用いられるのは、対象(主語)とそのIDが指し示すものとの関係を記述するときです。「○○○の作者はID■■■だ」という形です。同じIDを、異なる対象を指し示すために用いることはできません[2]
ID体系の全体像
適用範囲グループのメンバーは随時変化することがあり(社員や利用者は増えることも減ることもあります)、またそれにともなってIDは自動的に生成・付与される場合もあります。そのため、ID体系に含まれる全IDの一括提供は、一般には想定されません。

1.2 コードおよびコードリスト

コードは的確で効率的な機械処理を目的とする符号です。コードリストは、

  • 処理対象のもつある情報属性を(必要に応じていくつかに区分し)、
  • 漏れなく、簡潔に表現できるようにした符号(コード)の集合

ということができます。国コード、文字コード、都道府県コードなどがその例です。区分、種別といったカテゴリもしばしばコードとして表現されます。たとえば土地利用種別、日本標準産業分類などのコードがそれにあたります。

図2
図2: コードは処理対象の属性情報を機械処理しやすい符号(識別値)で示す。コードの定義(一覧)をic:コード種別で示す。空白の円の部分にURIを付与すれば、簡単に一貫してコードを利用できる。
コードの機能と設計
コードを用いることによって誤字や表記の揺れ(たとえば「東京」と「東京都」)によるエラーを防ぐことができます。また「年代コード」のように、便宜的な区分を設けて符号を与えることで、分類や統計的な処理を可能にします。
コードはしばしば並べ替えや絞り込みに用いられるため、規則的な識別値を付与するのが一般的です。
大きなコードリストでは、コードに階層関係をもたせることがあります。コードの識別値自体で階層を表現する(たとえば日本十進分類法)場合もありますが、そうでない識別値でも階層をもつコードリストもあります(たとえば日本標準産業分類はE=製造業の下位に09=食料品製造業などが置かれます)。識別値の構造を用いた階層表現は一見して分かりやすい一方で、拡張や変更が難しくなることがあるので注意してください。階層構造は、後述する「個別コードの定義」によって表現できます。
コードの指すもの
コードは一般に、対象のもつある属性値(目的語)を表すために用いられます。「○○○の産業分類コードは■■■だ」という形です。同じ識別値(コード)を、複数の対象の属性値として用いることができます。
個体型コードとカテゴリ型コード
コードには、都道府県コードのように概ね明確な実体に符号を与えるもの(仮に個体型コードと呼びます)と、年代コードのように連続的に変化したり捉え方に幅があったりする属性をいくつかの区分によって符号化するもの(カテゴリ型コード)とがあります。
個体型コードの場合、視点によってはそのコードをIDとして捉えることも可能です。上記「コードの指すもの」で示したように、符号の主たる目的がある対象の属性値(目的語)を表すことであれば、コードリストとして定義するのが妥当といえます[3]
カテゴリ型コードの場合、区分の基準が自明でないときは、その説明が欠かせません(識別値「01」に「若年層」という表記を割り当てるだけでは、何歳までを01と区分するのかが不明です)。またどの区分にも入れ難いなど「その他」に相当する識別値が必要になることがあります。
コードリストの全体像
コードリストは一定期間安定しているものと考えられ、一覧表やダウンロード可能なリストなど、通常何らかの方法でその全体(コード一覧)が提供されます[4]

2. ID体系の定義と利用

前述の通り、IDは適用範囲が明示されないと識別機能を果たすことができません。コア語彙のID型では、ID体系を用いてその値の適用範囲を明確に指し示します。

2.1 ID体系の定義

ID体系は次の4つのプロパティを用いて定義します。定義した体系の型(クラス)はic:ID体系型となります。

表1
プロパティ 役割 値の型
ic:名称 ID体系の名称 ic:名称型
ic:発行者 ID体系を作成、発行、維持する主体 ic:実体型
ic:バージョン 定義しているID体系のバージョン xsd:string
ic:URI このID体系をURIで参照する場合の値(XML定義で用いる) xsd:anyURI

 

  • 名称と発行者によって、何を対象としたID体系かが分かり、他と区別できるようにします。
  • ID体系はURI[5]で参照可能にすることが望まれます。ID体系定義を直接データに記述すると、名称などの定義更新に対応することが難しく、また複数実体がある場合は同じ記述を何度も反復することになるからです。RDFの場合は、ID体系定義記述の主語をこのURIとし、URIにアクセスするとID体系の定義が得られるようにします。
  • ID体系に含まれるIDは随時変化し得るので、その違いをバージョンで示すのは一般的ではありません。バージョンの利用は、たとえばIDの桁数の変更など、識別値が変わるものの基本的な体系は同じというケースが考えられます(ISBNの10桁と13桁など)。ただしその場合は、URIだけで体系を参照しているデータで混乱が生じないようにしなければなりません。バージョン間で一意性が失われるとき(同じ識別値がバージョンによって異なるものを指すなど)は、URIや名称も変更してください。
例1
<http://mojikiban.ipa.go.jp/data/MJ/> a ic:ID体系型 ;
    ic:名称 [ ic:表記 "MJ文字情報" ] ;
    ic:発行者 [
        ic:名称 [ ic:表記 "独立行政法人情報処理推進機構" ]
    ] .

発行者をURIで識別可能ならば、ic:発行者の値にそのURIを用いることができます。

例2
<http://mojikiban.ipa.go.jp/data/MJ/> a ic:ID体系型 ;
    ic:名称 [ ic:表記 "MJ文字情報" ] ;
    ic:発行者 <http://ja.dbpedia.org/resource/情報処理推進機構> .

2.2 IDの記述とID体系

IDの識別値とID体系を組み合わせることで、一意な識別が可能になります[6]

たとえば「MJ文字情報」で「MJ014245」という識別値をもっている文字は、前項で定義したURI「http://mojikiban.ipa.go.jp/data/MJ/」を用いて次のように記述できます。

例3
<#楽>
    ic:ID [
        ic:体系 <http://mojikiban.ipa.go.jp/data/MJ/> ;
        ic:識別値 "MJ014245"
    ] ;
    ic:表記 "楽" .

何らかの理由でID体系をURIで参照できない場合は、ic:体系の値としてID体系の定義を直接記述します[7]

例4
<#楽>
    ic:ID [
        ic:体系 [
            ic:名称 [ ic:表記 "MJ文字情報" ] ;
            ic:発行者 [
                ic:名称 [ ic:表記 "独立行政法人情報処理推進機構" ]
            ]
        ];
        ic:識別値 "MJ014245"
    ] ;
    ic:表記 "楽" .

(スキーマからic:IDの値はic:ID型と分かるので、RDFでは型の記述を省略できます。)

2.3 ID体系と識別値を組合せたURIとしてのID付与

ID体系のURIに識別値を連結するなどして一つのURIを構成することができれば、IDの参照はよりシンプルになります。

例5
<#楽>
    ic:ID <http://mojikiban.ipa.go.jp/data/MJ/MJ014245> ;
    ic:表記 "楽" .

ここでic:IDは対象を識別するために用いられる情報ですから、このURIを対象の主語として記述できます。

例6
<http://mojikiban.ipa.go.jp/data/MJ/MJ014245>
    ic:表記 "楽" .

RDFでのic:IDプロパティは、対象の識別子がID体系と識別値の組合せでしか表現できない(URIがない)場合に用います。URIがあるならば、それを主語として記述することで、他の情報からその対象をURIで参照し、データをリンクさせることが可能になります。

3. コードリスト、コードの定義と利用

コードは、IDとは異なり、識別値が何を表すのかを明示する個別コード定義も必要です[8]。コード定義においてコード種別を示すことで、個々のコードとコードリストを結びつけます。コードリストと個別コードをセットで定義して、コードリスト定義からもリストに含まれるコードの全体が把握できるようにします。

3.1 コードリストの定義

コードリストも、ID体系と同じ次の4つのプロパティを用いて定義します。定義したリストの型(クラス)はic:コードリスト型となります。

表2
プロパティ 役割 値の型
ic:名称 コードリストの名称 ic:名称型
ic:発行者 コードリストを作成、発行、維持する主体 ic:実体型
ic:バージョン 定義しているコードリストのバージョン xsd:string
ic:URI このコードリストをURIで参照する場合の値(XML定義で用いる) xsd:anyURI

  • ・名称と発行者によって何を表すためのコードであるかが分かるようにします。ID体系と同様、コード体系自身をURIで参照可能にすることが望まれます。
  • ・コードリストは一定期間安定したものと考えられるので、コードの追加などによるリスト構成の変更があればバージョンで違いを示すのが適切です。URIは、既存のコードが変更されるのでなければ、同じままで構いません。
  • ・桁数を変更するなど既存コードがそのまま使えなくなる場合は、URIも合わせて変更します。構成のみの変更はマイナーバージョン、コード自体の変更はメジャーバージョンの変更としてもよいでしょう。
例7
<http://example.org/code/landusage/> a ic:コードリスト型 ;
    ic:名称 [ ic:表記 "土地利用種別" ] ;
    ic:発行者 [
        ic:名称 [ ic:表記 "国土交通省国土政策局国土情報課" ]
    ] ;
    ic:バージョン "平成3年度,9年度,18年度版" .

3.2 個別コードの定義

コードリストに含まれる個別コードは、一覧表の形で定義・提供されることもありますが、これらのコードをコア語彙を用いて定義しておけば、それを利用した機械処理が可能になります。定義したコードの型(クラス)はic:コード型となります。

コードは、次の6つのプロパティを用いて定義します。

表3
プロパティ 役割 値の型
ic:コード種別 そのコードが含まれるコードリスト ic:コードリスト型
ic:識別値 情報属性を機械処理しやすく表す符号 xsd:string
ic:表記 識別値が表す情報属性を人が理解できるように示すラベル xsd:string
ic:上位コード 階層型コードリストにおける上位コード ic:コード型
ic:下位コード 階層型コードリストにおける下位コード ic:コード型
ic:関連コード 関連のあるコード ic:コード型
ic:参照 追加情報を参照するための情報を記述 ic:参照型

※カテゴリ型コードの場合など、ic:表記に加えて説明を添えるときは、コア語彙2.4で適用対象を拡大するic:参照を用いることができます。

 

たとえば「土地利用種別」におけるコード「7」が「建物用地」を表すという定義は、次のように記述します。

例8
<http://example.org/code/landusage/7> a ic:コード型 ;
    ic:コード種別 <http://example.org/code/landusage/> ;
    ic:識別値 "7" ;
    ic:表記 "建物用地" ;
    ic:参照 "住宅地・市街地等で建物が密集しているところとする。" .

コードリストと同様に、コード自身もURIで参照できるようにします。多くの語彙定義で、用語のURIは、語彙全体を指し示すURI(名前空間URI)と用語名(ローカル名)を連結して構成され、名前空間URIにアクセスすると語彙全体の情報が得られるようになっています。コードのURIも同様に、コード種別のURIに識別値を連結する形にしておくと、利用しやすいコードとなります。

 

都道府県コードと市区町村コードという階層をもつ全国地方公共団体コードの場合は、次のようにしてコード間の階層を示すことができます。

例9
#コードリストの定義
<http://example.org/code/localgov/> a ic:コードリスト型 ;
    ic:名称 [ ic:表記 "全国地方公共団体コード" ] ;
    ic:発行者 [
        ic:名称 [ ic:表記 "総務省" ]
    ] .

#個別コード定義の一部
<http://example.org/code/localgov/130001> a ic:コード型 ;
    ic:コード種別 <http://example.org/code/localgov/> ;
    ic:識別値 "130001" ;
    ic:表記 "東京都" .

<http://example.org/code/localgov/131016> a ic:コード型 ;
    ic:コード種別 <http://example.org/code/localgov/> ;
    ic:識別値 "131016" ;
    ic:表記 "東京都千代田区" ;
    ic:上位コード <http://example.org/code/localgov/130001> .

3.3 コードの利用

コード定義にURIが付与されていれば、コードプロパティ(ic:都道府県コードなど)の値にそのURIを利用できます。

例10
<http://example.org/organization/5010005007126>
    a ic:組織型 ;
    ic:名称 [ ic:表記 "独立行政法人情報処理推進機構" ]
    ic:住所 [
        ic:表記 "東京都文京区本駒込2丁目28番8号" ;
        ic:都道府県コード <http://example.org/code/localgov/130001> ;
    ] .

個別コードが表などでしか提供されずURIがない場合は、コード定義をプロパティの値として記述します[9]

例11
<http://example.org/organization/5010005007126>
    a ic:組織型 ;
    ic:名称 [ ic:表記 "独立行政法人情報処理推進機構" ]
    ic:住所 [
        ic:表記 "東京都文京区本駒込2丁目28番8号" ;
        ic:都道府県コード [
            ic:コード種別 <http://example.org/code/localgov/> ;
            ic:識別値 "130001" ;
            ic:表記 "東京都" 
        ]
    ] .

コードをURIで示すとき、表記はURIを辿って調べなければなりませんが、その処理の効率化はアプリケーションに委ねるのが原則です[10]。コード定義を同じデータ(ファイル)中に含めておくこともできるものの、ID体系の場合と同様、定義情報の埋め込みはオリジナルの変更への対応が困難になるので、注意して扱う必要があります。


  1. たとえば住民票コードのように、対象を一意に特定するための識別子が「コード」と呼ばれることがあります。識別子の符号という意味合いで「コード」と呼ぶわけですが、共通語彙基盤の用語においては「住民基本台帳ネットワークシステムというID体系でのID」に相当します。
  2. 「情報処理推進機構」と「IPA」のIDがいずれも5010005007126であれば、両者は同一の対象(実体)ということを意味します。
  3. たとえば都道府県コード130001は、ある人の勤務地を表す属性情報としては「コード」になりますが、47都道府県を適用範囲として東京都を表す「ID」ともいえます。基本的な用途が前者と考えられるので、これはコードリストとして定義します。
  4. コードの合成(たとえば「日本」と「歴史」のコードを連結して「日本史」を表す)が許されると、全体像の提示は困難です。これは機械処理も著しく複雑になるので、合成規則は用いない、もしくは合成済みコードをリストとすべきです。
  5. ここではURIを、ASCII以外の文字も認められるIRI(Internationalized Resource Identifier)の意味で用います。以降も同様です。
  6. プロパティをISBNなど特定のID体系を前提としたものにすれば、識別値だけでもIDの機能を果たしますが、ID体系ごとにプロパティを定義するは、汎用性の低い方法です。
  7. 前述のとおり、これは望ましい方法ではありません。
  8. IDの場合もその識別値が何を指すのか分からなければ利用できませんが、IDは対象の様々な情報を記述するときの主語となるもので、対象の記述自体がIDの定義に相当します。たとえば法人番号は、法人基本情報の記述を調べて得ることができます。Linked DataはこのIDをhttp:スキームのURIとし、URIにアクセスすることで記述情報を得られるようにするものです。
  9. プロパティとの組み合わせによっては、識別値だけあるいは識別値と表記で間に合うものもありますが、相互運用性のためには、デフォルトのコード種別を示すなど何らかの方法でコードリスト定義に遡れるようにしておくことが望まれます。
  10. 利用するコードリストが分かっていればあらかじめコード定義をロードしておいたり、参照した定義はキャッシュしておくなどの方法で、毎回URIを辿らなくても処理が可能になります。