NGSI-LDにも挑戦


データ仕様の現状と課題
スマートシティの標準規格(案)
データモデルのユースケース
ツール


Column
Link
用語集

Coppell

Technologies

2. NGSI-LD概要



2. NGSI-LD概要
2022年8月5日
 NGSI-LDはNGSI V2の後継の最新の規格です。NGSI V2はJSONのサブセットとして定義されていましたが、NGSI-LDは、Linked Dataの考え方を実装したJSON-LDのサブセットとして定義されています。このため、JSON-LDの規格を参照しています。また、既に見てきたようにJSON-LDはIRIを使うので、IRIがインタネット空間上に沢山定義済みである必要があります。以下、その関係を見ていきます。


2.1. NGSI-LD規格の参照規格
 NGSI-LDの規格が参照している規格の関係を調べてみました。沢山ありましたが、以下主要なものだけです。インタネットの世界では、規格がひとまとまりにはなっておらず、グローバルな各種コミュニティーの中で発生し、改版され、淘汰されていきます。従って、何かひとつ読み込めば理解できるというものではありません。本書では、実際にFiware/Orion-ldを動かしながら確認したいと思っています。
規格 説明
NGSi-LD ETSI GS CIM 009 V1.5.1
   RDF Schema W3CR Recommendation 25 February 2014:
JSON-LD W3CR Recommendation 16 July 2020
   JSON IETF RFC 8259
GeoJSON IETF RFC 7946
HTTP 1.1 IETF RFC 7230、IETF RFC 7231、IETF RFC 7232
IETF RFC 7240
URI IETF RFC 3986
URN IETF RFC 8141:
IRI IETF RFC 3987
HTTP Over TLS IETF RFC 2818。httpsの事です。
Unicode Unicode.org


2.2. NGSI-LD実行時に参照するURI
2022年8月5日
 NGSI-LDを実際に運用するためには、IRIで参照する先や@Contextで参照する先がインタネット上に存在する必要があります。また、データモデルもデータの送りてと受け手で共通している必要があります。この様な活動はNGSI V2でも必要でしたが、NGSI-LDでは明に参照されるので、実体としてインタネット上に存在する必要があります。以下、主要なものを探してみました。詳しくはこちらをご覧ください。

Core Context @Contextが暗黙に参照する@Context定義
schema.org グローバル標準である、語彙、データモデル、列挙型メンバなど規定とIRI
SAREF IoTデバイスの入出力に関する規定とIRI

この様に、データ交換はどこかの組織や機関が独自に何かの規約を定義したからできるものではなく、ひとつのエコシステムとしてデータ交換の「環境」を整えていく事により初めて実現されます。この点は非常に大事で、例えば政府が構築しようとしているベースレジストリですが、現在公開されている試行版ではcsvでデータセットとして実装しようとしています。csvはデータ全体を一括して転送する際には便利なデータ形式ですが、本書で紹介する様なデータ交換には向きません。まだ試行中との事ですので、今後の検討に期待しましょう。


2.3 NGSI-LDの情報モデル
2022年8月9日
 NGSI V2ではContextはAttribbuteを持ち、AttributeはMetadataをもつかもしれないという三階層の構造でした。


NGSI V2の情報モデル


これに対し、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も情報モデルの観点からは大きく違わない事が分かります。図が随分複雑になっただけですね。

 次に、各ノードの中身を見ていきましょう。

  ■Entity
  • Entityは、モノやコト、或いは仮想的なモノやコトに対応します。 -- V2とおなじ
  • EntityにはEntity typeがひとつだけ含まれます。 -- V2とおなじ
  • 但し、Entity TypeはURIでなけれぎなりません
  • Entity にはidがひとつだけ含まれます。idはURIでなければなりません
  • Entityには0個以上のAttributeが含まれます。 -- V2とおなじ
  ■Attribute
  • Attributeには、V2にあったPropertyとLDで追加されたRelationshpの二種類があります
  ■Property
  • PropertyはEntityの静的な、或いは動的な属性を表します -- V2と同じ
  • Propertyのtypeは基本的に"Property"ですが、地理空間的な属性を表すGeoPropertyと時間的な属性を表すTemporalPropertyというtypeもあります。 -- V2ではそれぞれgeo:jsonとDateTimeと言っていました。
  • PropertyにはURIで示されるPropertyIDを含まれます
  • Propertyには、Value、Property、またはRelationshipを含まれます。ValueにはdataTypeがあり、dataTypeはURIで示されます。
  • Valueとしては、Number、String、booleanといった単一のものと、配列やStruntured Valueの複雑なものがあります -- V2と同じ
  ■Relationship
  • Relationshipには、URIで示されるRelationshipIDが含まれます
  • Relationshipは、PropertyのValueに相当するObjectを含みます。Object別のEntityを指すURIです。
  • Relationshipには、RelationshipやPropertyを含むことができます。
 この様に、IRI(URI)が各所に出てくることが分かります。つまり、定義がデータの送りてと受けての間で同一であることを、IRIを使って保証している訳です。
 さて、IRIを使う事で曖昧さを減らす事が出来ますが、その代わり困ったことが起きます。JSON記述の中身がえらく見づらいものになってしまいます。また、v2では定義されていないAttributeをいきなり格納する事が出来ましたが、LDではどのIRIに基づくPropertyやRelationshipなのか定義する手段が必要です。そこで、次節の@Contextの出番となります。


2.4 @Contextの定義
2022年8月9日
 "@Contest"というキーワードはJSON-LDでは短縮形を定義するという意味がありましたが、NGSI-LDでも同じです。゛@Context"は定義する際と参照する際の両方に用いますが、この節では定義について記載します。
■IRIの短縮形の定義
 NGSI-LDではJSON-LDを踏襲し、長いIRIを短くする方法を定義しています。
 例えば、"abc": "https://x.y.z/abc"と定義すれば、abcという用語は、https://x.y.z/abcと書かれたものと同じとして解釈されます。このabcを短縮形、またはshorthandと呼びます。
 具体的には以下の様に記述します。

{
   "@context": {
       "ngsi-ld": "https://uri.etsi.org/ngsi-ld/",
       "fiware": "https://uri.fiware.org/ns/data-models#",
       "schema": "https://schema.org/"
   }
}

そうすれば、例えば、"https://schema,org/address"は"schema;address"と書くだけで済みます。この"schema;address"の様な形式は、コンパクトIRIと呼ばれます。

■コンパクトIRIの短縮形の定義
 Property等の定義が多くなると、コンパクトIRIでもまだ煩雑です。そこで、コンパクトIRIを更に短くします。
 具体的には、以下の様に記述します。

{
   "@context": {
       "ngsi-ld": "https://uri.etsi.org/ngsi-ld/",
       "fiware": "https://uri.fiware.org/ns/data-models#",
       "schema": "https://schema.org/",
       "address": "schema:address",
       "streetAddress": "schema:streetAddress",
       "addressRegion": "schema:addressRegion",
       "addressLocality": "schema:addressLocality",
       "postalCode": "schema:postalCode"
   }
}
この様に短縮形を予め定義しておくと、個々のEntityの操作の時にはIRIiは気にせずにaddressなどの指定ができますから、v2の時と同じようにProperty名や値を取り扱う事が出来ます。後で例を示します。

■キーワードに対するAliasの定義
 この定義があればJSON-lDはほぼJSONと同じ様に見えますが、更に@で始まるキーワードにもAliasを付けると、更にJSONと同じように見えます。

{
   "@context": {
       "id": "@id",
       "type": "@type",
       "ngsi-ld": "https://uri.etsi.org/ngsi-ld/",
       "fiware": "https://uri.fiware.org/ns/data-models#",
       "schema": "https://schema.org/",
       "address": "schema:address",
       "streetAddress": "schema:streetAddress",
       "addressRegion": "schema:addressRegion",
       "addressLocality": "schema:addressLocality",
       "postalCode": "schema:postalCode"
   }
}


2.5 Core NGSI-LD @Context
2022年8月12日
 この定義は暗黙に参照されるContextの定義です。実際の定義はここにあります。本日時点では、Version1.5が最新の様です。この定義では、基本的な各種用語の定義がなされています。
 Core NGSI-LD @Contextは書き換える事は出来ません。また、各種処理系(Orionなどのプログラム)には最後に読み込まれますから、ここにある定義と同じ語句の定義をしていても、このCore NGSI-LD @Contextが優先されます。
 ちょっと中身を見てみましょう。

{
 "@context": {

   "ngsi-ld": "https://uri.etsi.org/ngsi-ld/",
   "geojson": "https://purl.org/geojson/vocab#",
   "id": "@id",
   "type": "@type",

   "Attribute": "ngsi-ld:Attribute",
   "AttributeList": "ngsi-ld:AttributeList",
   "ContextSourceNotification": "ngsi-ld:ContextSourceNotification",
   "ContextSourceRegistration": "ngsi-ld:ContextSourceRegistration",
   "Date": "ngsi-ld:Date",
   "DateTime": "ngsi-ld:DateTime",
   "EntityType": "ngsi-ld:EntityType",
   "EntityTypeInfo": "ngsi-ld:EntityTypeInfo",
   "EntityTypeList": "ngsi-ld:EntityTypeList",
   "Feature": "geojson:Feature",
   "FeatureCollection": "geojson:FeatureCollection",
   "GeoProperty": "ngsi-ld:GeoProperty",
   "GeometryCollection": "geojson:GeometryCollection",

 }
}
 上から順に見ていくと、"ngsi-ld"とは"https://uri.etsi.org/ngsi-ld/"の事だよと書いてあります。つまり、ngsi-ldと書かれていたら、https://uri.etsi.org/ngsi-ld/と読み替えて欲しいという意味となります。ちょっと後ろにAttributeの定義があり、"ngsi-ld:Attribute"と書かれています。読み替えますから、"https://uri.etsi.org/ngsi-ld/Attribute"となります。