本協議会の共通データ仕様はNGSI V2とGIFに準拠しますが、GIFは必ずしもNGSI V2を前提に検討されたものではありません。また、自治体共通オープンデータセットなどの広く利用されているデータモデルは、多くはGIFを継承しているものの、当然ながら必要な項目を追加したり、既存の項目を詳細化するなどの仕様を追加しています。また、GIFの各種規定が策定された後で、schema.orgやSmart Data Models等のグローバルスタンダードが策定された部分があるため、これも当然のことながらGIFの規定がグローバルスタンダードからズレてしまう事態が発生します。
本節では、そのようなズレ等の各種問題をPPP共通データ仕様協議会ではどの様に解釈し、共通データ仕様に反映しているのかについて列挙しています。
余談ですが、使用しているツールの制約で下表のカラムの幅がバラバラで見づらいですが、ご容赦下さいませ。
政府相互運用性フレームワークGIF（Government Interoperability Framework）
■コア・データモデル
全般
| 解釈対象 | 解釈対象の課題 | 本協議会の解釈 |
|---|---|---|
| 「半角」という用語 | 本来「半角」という表現は、等幅フォントの内、1/2の幅をもつ文字を指す | ディスプレイやプリント出力時の文字の幅とは関係なく、ASCII文字を指す。従って、7ビットで表現できる文字だけを指している。ASCIIを8ビットに拡張し、例えば日本語環境では半角カナなどもあるが、それらは含めずにあくまでもバイナリで0x00から0x7Fまでの文字を指す |
法人
| 解釈対象 | 解釈対象の課題 | 本協議会の解釈 |
|---|---|---|
| 創業年の記入例 | 記入例が”1990年”となっており、YYYYの形式ではない | GIFの規定やISOでは、年はYYYYの4桁の数字となっている。従って、文字列の中に”年”は含めない。つまり、加入例が誤っていると解釈する |
住所
| 解釈対象 | 解釈対象の課題 | 本協議会の解釈 |
|---|---|---|
| 解説書の番地以下の例 | 番地以下の例が”１番２号”になっており、コア・データパーツ/住所の規定に合っていない | 番地以下の例に関わらす、コア・データパーツ/住所の規定に準拠し、”1-2″と記載するルールとする |
| 政令市の区の全国地方公共団体コード | 都道府県と市区町村まで含む6桁との記載があるが、政令市の場合は区なのか市なのかの記載が無い | アドレスベースレジストリでは政令市は区まで細分化したコードを記載している事から、住所を表現する場合には区まで細分化したコードを用いる |
| 町字の記入例 | コア・データモデルは住所を都道府県・市区町村・町字・番地以下の4項目で管理している。4項目の内、町字の記入例が”永田町１丁目”と数字で記載しているが、コア・データパーツ/住所の4個のデータ項目で管理する場合の例では”霞が関二丁目”と漢数字になっている | 4個のデータ項目で管理する方式は採用せず、3個の項目で管理する方式を採用する事で、丁目を含めてASCII文字で記載するルールとする。尚、3個の項目で管理する方式はデファクトスタンダードのschema.orgにも合致している |
| 番地以下の記入例 | 前項同様4項目の内、番地以下の記入例が”７ー１”と全角文字になっている | コア・データパーツ/住所の規定に準拠し、”7-1″とASCII文字で記載するルールとする |
| 建物名等(方書) | 方書が必須項目になっている | 現実には方書が無い住所もある事から、必須項目とはしないルールとする |
| 国の記入例 | コード情報型となっており、その記入例が{“種別”: “JPN”,”種別関連情報”: “日本”}となっている | 正しくは、例えば{“種別”: “ISO 3166-1 alpha-2″,”種別関連情報”: “JP”}が正しい例とする。尚、同様の誤りは複数個所に記載されている |
| 必須項目 | 都道府県、市区町村(群)、町字を必須項目としているが、コア・データパーツ/住所では、全国地方公共団体コードと町字IDを使用して管理する事を推奨している | 全国地方公共団体コードと町字IDを使用して管理する場合には必須とはしないルールとする |
アクセシビリティ
| 解釈対象 | 解釈対象の課題 | 本協議会の解釈 |
|---|---|---|
| 「スロープ、エレベータ、エスカレータ」の項目 | 市自治体共通オープンデータセットのデータモデルでは、これらは別の項目として定義されている。このため、コア・データモデルをそのまま継承したデータベースが存在しても、オープンデータセットは導出できない | 自治体共通オープンデータセットを踏襲し、別の項目として定義しておく |
■コア・データパーツ
電話番号
| 解釈対象の課題 | 本協議会の解釈 | |
|---|---|---|
| 国際電話番号の表現 | 表現が”+国番号 (09)9999-9999”となっており、国番号の後ろの市外局番が省略可能であり、また先頭の”0″が必要となっている | 本文の記載通り、国番号があるときには市街局版は先頭のゼロを削除すると共に、市外局番は省略出来ないルールとする。つまり”+国番号 9-9999-9999”とする |
| 国際電話番号の例 | 例が”+81 (03)5253-5111″となっており、国番号の後ろの市外局番が省略可能であり、また先頭の”0″が必要となっている | 本文の記載通り、国番号があるときには市街局版は先頭のゼロを削除すると共に、市外局番は省略出来ないルールとし、”+81 3-5253-5111″とする |
住所
| 解釈対象の課題 | 本協議会の解釈 | |
|---|---|---|
| 10種類の表現方法 | コア・データパーツ/住所は多様な住所表現を可能としている。データ交換の視点では、表現が多様である事はコスト増や品質の低下の原因となる | 3個の項目で管理する方式を採用する。尚、3個の項目で管理する方式はデファクトスタンダードのschema.orgにも合致している |
| コードによる表現 | コードによる表現は表記の揺れが抑えられる等の大きな利点があるため推奨されているが、一方で海外の住所が表現できず、人間による視認性も悪く、スマホアプリなどの実装も当面は難しい | 前項の3項目で管理する方法とコードによる方法の2つの方法を定義する。この2つの方法は国内であれば相互に変換は容易と思われる |
| 3個の項目で管理する方式 | 町名を「市区町村」の項目に入れるのか、それとも「丁目以下」の項目に入れるのかの記載が無い。尚、例では町名は市区町村に入っている。 同様に、政令市の区は「市区町村」に入れるのか、それとも「丁目以下」の項目に入れるのかの記載が無い | 政令市の区名、および町名は「丁目以下」に入れるルールとする。尚、このルールはグローバルスタンダードであるschema.orgのPostalAddressにも合致しているため |