|
|||||||||||||||||||||||||||||||||||||||
2022年8月5日 |
|||||||||||||||||||||||||||||||||||||||
NGSI-LDはNGSI V2の後継の最新の規格です。NGSI V2はJSONのサブセットとして定義されていましたが、NGSI-LDは、Linked Dataの考え方を実装したJSON-LDのサブセットとして定義されています。このため、JSON-LDの規格を参照しています。また、既に見てきたようにJSON-LDはIRIを使うので、IRIがインタネット空間上に沢山定義済みである必要があります。以下、その関係を見ていきます。 | |||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||
NGSI-LDの規格が参照している規格の関係を調べてみました。沢山ありましたが、以下主要なものだけです。インタネットの世界では、規格がひとまとまりにはなっておらず、グローバルな各種コミュニティーの中で発生し、改版され、淘汰されていきます。従って、何かひとつ読み込めば理解できるというものではありません。本書では、実際にFiware/Orion-ldを動かしながら確認したいと思っています。
|
|||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||
2022年8月5日 |
|||||||||||||||||||||||||||||||||||||||
NGSI-LDを実際に運用するためには、IRIで参照する先や@Contextで参照する先がインタネット上に存在する必要があります。また、データモデルもデータの送りてと受け手で共通している必要があります。この様な活動はNGSI V2でも必要でしたが、NGSI-LDでは明に参照されるので、実体としてインタネット上に存在する必要があります。以下、主要なものを探してみました。詳しくはこちらをご覧ください。
この様に、データ交換はどこかの組織や機関が独自に何かの規約を定義したからできるものではなく、ひとつのエコシステムとしてデータ交換の「環境」を整えていく事により初めて実現されます。この点は非常に大事で、例えば政府が構築しようとしているベースレジストリですが、現在公開されている試行版ではcsvでデータセットとして実装しようとしています。csvはデータ全体を一括して転送する際には便利なデータ形式ですが、本書で紹介する様なデータ交換には向きません。まだ試行中との事ですので、今後の検討に期待しましょう。 |
|||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||
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
さて、IRIを使う事で曖昧さを減らす事が出来ますが、その代わり困ったことが起きます。JSON記述の中身がえらく見づらいものになってしまいます。また、v2では定義されていないAttributeをいきなり格納する事が出来ましたが、LDではどのIRIに基づくPropertyやRelationshipなのか定義する手段が必要です。そこで、次節の@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" } } |
|||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||
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"となります。 |
|||||||||||||||||||||||||||||||||||||||