準拠規格の解釈

「半角」という用語

本来「半角」という表現は、等幅フォントの内、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にも合致している

曜日

曜日、開始時刻、終了時刻を独立な別項目としている。また、曜日によって時刻が異なる場合は、補足の項目に自然文で書き込む事になっており、マシンリーダブルではない。尚、Smart Data Modelsやschema.orgの形式とも異なる

schema.orgのOpeningHoursSpecificationに準拠する事とする

3階層モデル

NGSI V2はMetadataを含めて3階層のモデルとなっている。これに対し、国内で普及している表形式(CSV等)はモデルとしては二階層であり、変換が困難。また、NGSI V2の後継であるNGSI-LDではMetadatataが廃止されている

出来る限り2階層でデータ仕様を策定する事とする

識別子の”@”

各種識別子の規定はJSONに準拠しているため”@”を使用できる。一方、NGSI V2の後継であるNGSI-LDはJSON-LDに準拠しているため、識別子の先頭の”@”は特別な意味を持つ。また、JSON-LDでは将来の拡張に備えて識別子の先頭の文字に”@”を使う事は避ける様に求めている

JSON-LDは先頭の文字以外は”@”の仕様を許しているが、規格を単純化するために識別子の文字列に”@”を使わない事とする

識別子の文字

“?”、”/”、”&”、”#”以外の任意の文字が利用できる。一方、Fiwareではエラーとしている文字もある。また、URL内に記述すべきでない文字も含まれている

URNの規定に合わせて、英数字以外の記号では、”-“、”~”、”_”、”.”だけを使用可能とする

構造を持つ項目

構造の持つ項目(Attribute)の構造はJSONに合致していれば良く、自由な記述を許している。但し、Smart Data Modelsの例示では、全てのSub-attributeはkeyValuesの形式となっている

optionsにkeyValuesの指定があるかどうかの関わらず、全てのSub-attributeはkeyValues形式で記述する事とする。但し、座標についてはGeoJSONの規定に従う

リンクのタイプ

NGSI V2にはリンクの規定はない。但し、Fiwareの開発元は他のEntityへのリンクは”type”を”Relationship”とする事を推奨している

他のEntityへのリンクを表すAttributeは”type”を”Relationship”とする