Coppell Technologies　データ仕様の現状と課題

Menu

Coppell Technologies
Fiwareで都市OSを動かしてみよう
NGSI-LDにも挑戦

データ仕様の現状と課題

スマートシティの標準規格
データモデルのユースケース

Column
Link集
用語集

Coppell

Technologies

7. データ交換における課題
2022-07-12
　前章までで、データ交換における課題はだいぶん抽出できたと思います。本章では、改めて課題を整理します。

7.1 文字セットと符号化方式
2022-05-08
　文字セットはUnicode、符号化方式はUTF-8で共通化する事で問題ないと考えます。
　「スーパーシティのデータ連携基盤に関する調査業務」の7-4節にも以下の記述があります。
　『文字は、スマートフォン等の一般的な機器に搭載されているJIS X 0213（JIS第4水準までの1万文字）の範囲内とする。また文字符号化は UTF-8 を使用する』。この様に、文字セットはJIS X 0213 (つまりUNICODE)、符号化方式はUTF-8となっています。
　同様に、自治体が準拠すべき「文字環境導入実践ガイドブック」でもUTF-8を推奨しています。

7.2 語彙
2022-07-14
　語彙については、以下の課題にあると考えます。
  • コア語彙の整備されているが、ドメイン語彙が公開されていない。または、ドメイン語彙を検討・公開・共有する仕組みがない
  • コア語彙は参照モデルであり標準規定ではないので、実装データモデルの策定時には多くの選択肢から項目を選択するなどの自由度が高く、語彙とは別にデータモデルを検討・公開・共有する仕組みが必要となる
これらの課題はコア語彙自身の問題というわけではありませんが、留意しておく必要があります。

7.3 呼出しインタフェース
2022-07-14
　呼出しインタフェースについては、Web APIで問題ないと考えます。W3Cの標準であるとともに、「スーパーシティのデータ連携基盤に関する調査業務」でもその様な記載があります。FiwareやMicrosoft Azure等の多くのベンダでもサポートしており、デジタル庁が配付するデータ連携基盤もサポートしています。
　但し、WebAPIに指定するエンドポイント(リソースを指すURL)については、実装ごとに異なっています。また、後述する情報モデル毎にエンドポイントの構造(つもりリソースの構造)も異なっていますので、検討が必要と考えます。

7.4 情報モデル
2022-08-22/2023-01-05
　情報モデルの課題は、以下に記述する3種類からどれを選ぶのかを検討する必要があるという点です。尚、本節では正確性よりも議論の題材としての分かりやすさを優先するため、色々と省略して書いてあります。

■NGSI V1
　V1では、データ(NGSIではContextと言います)は、基本的に二階層です。例えば、以下のイメージです。
Context type Contextの種類。例: "公共施設"
id Contextを一意に識別する文字列
Attributes
name 項目名。例: "名前"
value 項目値。例: "中央図書館"
name 項目名。例: "住所"
value 項目値。例: "広島県呉市吉浦潭鼓町1-1"
name 項目名。例: "開館時間"
value 項目値。例: "10:00-17:00"

基本的と断っているのは、メタデータを追加可能で、メタデータを含めると三階層になるためです。この形式は自治体共通オープンデータセットと親和性がよく、Excel等の表計算ソフトやcsvなど自治体で使われている形式にも親和性が良い事が特徴です。

メリットとデメリットは以下となります。
メリット
  • 推奨データセットと親和性が高い
  • 自治体で多用しているcsvファイル形式と親和性が高い
  • Excelなどの表計算ソフトと親和性が高い
  • 人間が目で見て分かりやすい
デメリット
  • 階層構造や繰返し構造を持たないため、住所の様な構造を持つ情報や開館時間の様に複雑な構造を持つ情報は表現が難しい。例えば、標準データセットの公共施設では、住所に都道府県名や市区町村名がが含まれているにもかかわらず、都道府県名の項目、市区町村名の項目を別に定義しているなどの工夫をしている。また、利用可能曜日と開館時刻が別の項目に分かれているため、曜日ごとに開館時刻が違うと表現できない。
尚、Valueに複数の値を、例えばセミコロンで区切って書き込んだり、JSON形式で構造を持つ文字列を書き込むなどにより、疑似的に階層構造や繰返し構造を表現する例もあります。

■NGSI V2
　前項のattributesを項目ごとに分解すると共に、項目値に構造を持たせることが出来る様にしたものです。イメージにすると以下の様になります。

Context type Contextの種類。例: "GovermentOffice"
id Contextを一意に識別する文字列
name 項目値。例: "中央図書館"
address addressCountry
例: 81
addressRegion 例: 広島県
addressLocality 例: 呉市
streetAddress 例: 吉浦潭鼓町１-１
openingHoursSpecification
dayOfWeek 曜日。例: "Monday"
opens 開館時刻。例: "10:00"
closes 閉館時刻。例: "17:00"

dayOfWeek 曜日。例: "Friday"
opens 開館時刻。例: "10:00"
closes 閉館時刻。例: "12:00"
・・・

メリットデメリットは以下となります。
メリット
  • 情報モデルが、構造を持つ項目や繰返し構造を表現できるため、例えば「広島県にある施設を取り出したい」など、多様な検索が可能となります。
  • 複雑な情報を表現できます。前記の開館時間などの情報がそうです。国内で利用実績も多いです
  • attributeかネスト出来るので、コア語彙の定義と親和性が高いです
デメリット
  • Excelなどの表計算ソフトと親和性が低いです
  • 人間が目で見て分かりにくくなりがちです
この情報モデルは表現力が高い事が特徴ですが、データ間の関係を表現しようとすると、Attributeの一つの項目の値に他のデータのidを格納する事になります。値として持っているidの指す先を削除したりすると、データ間で不整合が発生します。この不整合を発生させないのは、利用者の責任になってしまいます。
　尚、NGSI V2で全てのデータ仕様を策定するためのルールが規定されている訳ではありません。以下の曖昧さが残っています
  • 項目が構造化されている場合の表現方法は規定されていません
  • 各種名称に使える文字が、利用者責任になつているものや、NGSI-LDへの互換上注意が必要なものがあります
  • 各種名称に使える文字で、NGSI V2で許される文字なのに、デジタル庁の推奨モジュールであるFiware/Orionでは使えないものがあります
  • NGSI-LDへの互換性を向上するために一部NGSO-LDの規格を取り込む必要があります
これらについては、追加の規格(ローカルルール)を策定する必要があります

■NGSI-LD
　この情報モデルは、Fiware Foundationにて前記のNGSI V2の後継として作成されると共に、ESTIの標準としてもなっています。このモデルの特徴は、メタデータをやめると共に、他のデータに対する参照を情報モデルとして定義したことです。
　メリットデメリットは以下の通りです。
メリット
  • 情報モデルが、構造を持つ項目や繰返し構造を表現できるため、V2同様多様な検索が可能となります。
  • 更に、データの値に属性を記述できるなど、V2より複雑な表現も可能です
  • 最新の情報モデルで、今後もコミュニティーで各種データモデルの定義が進められると思われます
  • Microsoft Azureがサポートしています
  • V2の表現を包含します
デメリット
  • Excelなどの表計算ソフトと親和性が低い
  • 人間が目で見て分かりにくくなりがち
  • 国内で利用実績が見当たりません
  • IRIと呼ばれるユニークな語彙定義が必要ですが、日本にはその様な仕組みは存在しないと思われます
尚、NGSI V2とNGSI-LDではContextの記述やインタフェースに互換はありません。@contextの指定やデータモデルをある程度制約することで、かなり近づける事は可能と思われますが、多少の相違は残るものと思われます。

7.5 データ形式
2022-08-22

　データ形式については、JSONまたはJSON-LDで問題ないと考えます。問題は、このどちらにするかです。NGSI V2を採用した場合はJSON、NGSI-LDを採用した場合にはJSON-LDと言う事になります。
JSONとJSON-LDの比較を改めて提示します。

JSON
  • Fiwareが標準サポート(モジュールはFiware/Orion)
  • DSAが標準モジュールとして情報公開しているのは、JSONをサポートするFiware/Orion
  • 「スーパーシティのデータ連携基盤に関する調査業務」ではJSONが前提
JSON-LD
  • データ交換時の、JSONの曖昧さをリンクとデータという考え方で縮小
  • NGSIの最新規格である、NGSI-LDが採用
  • Fiwareが標準サポート(モジュールはFiware/Orion-ld)で、v2とは別モジュール
  • MS Azureがサポート
  • IRIの定義が必要だが、現時点ではIRIを公開するコミュニティーは無いと思われる
  • 日本国内に実績なし