Coppell Technologies

スマートシティの標準規格

Menu

Coppell Technologies (Top)
Fiwareで都市OSを動かしてみよう
NGSI-LDにも挑戦
データ仕様の現状と課題

スマートシティの標準規格

データモデルのユースケース

Column
Link集
用語集

Coppell

Technologies

 6. 情報モデル


5.1 NGSI V2 の情報モデル
2022年8月15日
 NGSI V2 の情報モデル(Entityの形式)は、以下の様に3階層になっています。

ひとつのEntityにはid、type、およびひとつ以上のAttributeが含まれ、各Attributeにはゼロ個以上のMetadataが含まれます。各AttributeはAttribute name、Attribute type。およびAttribute valueを持ちます。Metadataも同様にMetaddata毎にMetadata name、Metadata type。およびMetadata valueを持ちます。以降、混乱しない場合にはイチイチAttributeやMetadataは付けず、単にtypeやvalueと記述するばあIがあります。
 本書ではEntityと記述しますが、Fiware Foundationの公式なWebサイト含めて色々な表現が混在しており、Context、Context Element、Entity、Dataなどと別の表現をしている場合があります。Dataは一般的な名称なので、本書では混同を避けるため、Entityと記載しています。また、同様にAttributeもPropertyや属性と記載している場合がありますが、本書ではV2ではAttributeで統一します。
 各Attributeは構造を持つことも出来ます。このため、Attributeが階層を持っている様にも見えます。例えば、住所という項目にはは国、都道府県、市区町村、それ以下、郵便番号、私書箱の6つの項目が定義されており、項目の中に項目がある構造になります。


5.2 NGSI-LDの情報モデル
2022年8月12日
 NGSI-LDでは、以下の様な不定の階層構造を持ちます。


NGSI-LDの情報モデル


 Entityはデータを格納したり伝達したりする単位で、モノやコトを表します。この点は変わりません。Metadataを廃止する代わりに、Attributeを多階層にする事になりました。AttributeはPropertyとRelationshipの二つに分類されました。PropertyとValueのペアは、v2のAttributeと変わらないと思ってください。新たに、Relationshipというものが出てきました。Relationshipは、Objectとペアになっていますが、Objectの実体は他のEntityのid(IRI)です。つまり、V2では慣例的に"refAbcdefg"などと書いていた他のEntityを指し示すAttributeと同じ役割を示します。Attributeが多階層になりましたから、PropertyはEntityの下にあることも、Propertyの下にあることも、Relationshipの下にあることも出来ます。全く同じく、Relationshipは、Entityの下にあることも、Propertyの下にあることも、Relationshipの下にあることも出来ます。
 こうしてみると、V2もLDも情報モデルの観点からは大きく違わない事が分かります。図が随分複雑になっただけですね。


5.3 当面の実装で用いる情報モデル (案)
2022-08-13/2023-11-21
 現在、最新のNGSIの規格はNGSI-LDであり、例えばマイクロソフトAzureもNGSI-LDの準拠を謳っている事から、本来であれば新たに構築するスマートシティにおいてはNGSI-LDを採用すべきと考えます。一方、7月に一般社団法人データ社会推進協議会 (DSA; Data Society Alliance) が発表したデジタル庁の推奨モジュールはNGSI V2を実装するFiwre/Orionだけであり、NGSI-LDを実装するFiware/Orion-ldは記述されていません。このことから、日本国の自治体が関与するスマートシティにおいては、NGSI-LDの利用は制約を受けざるを得ないと思われます。そこで、NGSI V2を使いつつ、将来的にNGSI-LDへの移行が必要となったときに、出来る限り機械的な移植や、何らかの連携基盤経由でNGSI-LDのインタフェースも受け付けられるように工夫する事を提案します。
 具体的には、以下の方策で進めてはどうかと考えます。
  • 可能であれば、Metadataはなるべく使わない。これは、問い合わせ時のフィルタリングの指定が異なる事と、GETで返されるJSON文が異なるためです。
  • 他のEntityを指し示すAttributeの名称は"ref"で始まる文字列とする。typeは"Relationship"とする
  • idはNGSI-LDに準拠する
  • 識別子に"@"を使用しない