前回の記事　　　　　　　　　　　　　　　　　　　　　　　　次回の記事

はじめに

今回は、2023/7/10 に正式公開になった、DTDL Version 3 をメインに詳しく見ていく事にします。

DTDL：Digital Twins Definition Language とは

DTDL：Digital Twin Definition Language は、Digital Twins を実現するためのサービス Azure Digital Twins のスキーマを定義する為の言語です。使い方は、この定期購読マガジンの ”8. Azure Digital Twins を試す” から何回かに分けて詳しく説明しているので、そちらを参考にしてください。
…もう一年以上経つのね、この記事書いてから…
この当時は、DTDL V2 でした。
そもそも DTDL というのは、Microsoft Learn によれば、

ということで、Azure IoT Hub がサポートする IoT Plug & Play の定義でも使われています。というか、歴史的には、IoT Plug & Play の方が先行していた様な印象が私にはあります。

DTDL については、
DTDL モデル - Azure Digital Twins | Microsoft Learn
に一番詳しく書いてあるので、「そもそも DTDL って何なん？」という方は、このページを熟読するとよいでしょう。DTDL がどう使われるかについては、

に書いてあって、要するに

• Digital Twins ＝現実世界に存在する様々なモノ、コトの写しをデジタル空間上に構築し、活用する

• デジタル空間上に構築した、現実世界に存在する様々なモノ、コトの写し ＝ Twin Graph

• Twin Graph のスキーマ定義 = DTDL

という事ですね。

DTDL の定義

DTDL は、JSON-LD 形式を採用して定義された言語です。JSON-LD とは、JSON for Linking Data というもので、
JSON-LD - JSON for Linking Data
が正式なサイトのようです。Semantic Web を実現するための手段の一つだそうです。DTDL は、

{
  "@context": "dtmi:dtdl:context;3",
  "@id": "dtmi:com:example:Thermostat;1",
  "@type": "Interface",
  "displayName": "Thermostat",
  "contents": [
    {
      "@type": "Telemetry",
      "name": "temp",
      "schema": "double"
    },
    {
      "@type": "Property",
      "name": "setPointTemp",
      "writable": true,
      "schema": "double"
    }
  ]
}

こんな感じで描きますが、この ”key:value” のキーで、”@context”等、”@”で始まるものが JSON-LD に従った記述です。

オントロジ

Microsoft Learn の Azure Digital Twins に関するコンテンツには、”オントロジ”という用語が頻出します。色々見てみたのですが、”オントロジ”とは何ぞやという説明は Microsoft Learn の中には無いようです。Wikipedia では、
オントロジー - Wikipedia
に書かれていて、”哲学用語で存在論のこと”とか、”概念化の明示的な仕様”などと書かれています。要するに、写しを作りたい現実世界に存在するモノやコト・役割等を扱うための考え方という事です。
オントロジを記述する方法としては、OWL、RDF、RDFS 等が W3Cで標準化されており、一般的に使われているようです。

業界標準オントロジを DTDL に変換する

オントロジの変換 - Azure Digital Twins | Microsoft Learn によれば、OWL と RDF で書かれた既存のオントロジを DTDL にコンバートできるそうです。

• RDF コンバーター

  • OWL/RDFS にも対応している

• OWL2DTDL コンバーター

現在、以下の4つの業界オントロジが、Microsoft によって DTDL に変換されて github から公開されています。

• スマートビルディング（RealEstateCore）

• スマートシティ（Open Agile Smart Cities など）

• エネルギーグリッド（CIM）

• 製造（OPC UA、ISA95、Asset Administration Shell）

図表現の必要性

DTDL、OWL、RDF、RDFA なんでも良いのですが、これらは全てテキストで記述されるものです。コンピュータにインプットするならそれでも良いのですが、それらを人間が理解するのも記述するのも、記述量も多いので、実質的に不可能ではないでしょうか。
例えば、スマートビルディング 用の DTDL が公開されている github には、

の様な図が使われています。ネット上を探すと、OWL を Visualize するツールで、WebVOWL - Web-based Visualization of Ontologies (visualdataweb.org) というツールがあって、

こんな図がサンプルとして表示されています。
Azure Digital Twins にも DTDL のモデルスキーマを図示化する機能はありますが、やってみた人ならわかるように、3、4個の interface を含むだけで、まぁ蜘蛛の巣？！的な表示がされるだけで、作成や理解にはかなり厳しいのかなと。
ということで、お勧めは、"Art of Conceptual Modeling”で解説している概念モデリングによる図表示です。このモデリング体系の概念情報モデルは、OWL にしろ、RDF、RDFS、DTDL で記述された内容を正確に図表示を行事が出来、かつ、記述した概念情報モデルから、DTDL を生成する事が出来ます。記法は UML に則って書かれるものなので、特殊なモデリング体系というわけでもありません。
オントロジ的なモデルとは何かを深く理解する為にも、"Art of Conceptual Modeling” は有用ですので、是非読み込んでください。

DTDL のバージョン

現時点で Azure Digital Twins で使える DTDL は、

• DTDL Version 2

• DTDL Version 3

の二つです。Version 2 はずいぶん前に流し読みしたぐらいなので、今回は、両方を敢えて印刷して内容を比較してみました。
V2 と V3 の違いは、基本的には、

https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v3/DTDL.v3.md#changes-from-version-2ｎ

に書いてある通りですが、

• 全ての要素の name と displayName が 512 byte まで可能になっている

• interface の contents について、定義可能な要素が拡張されている

  • max 100,000 elements in hierarchy, includeing those imporetd via extens

• interface で extends が可能な数が max 1024 に拡張されている

  • これは朗報。V2 は max 2 だったので、概念情報モデルの木構造やリスト構造が DTDL で定義できなかったのができるようになった。

• command の request と response の schema が ComandRequest、CommandResponse と明確になった

• relationship の maxMultiplicity の500までの制限がなくなった

• enum の enumValues の数の制限がなくなった

• object の fields の数の制限がなくなった

• V2 で定義されていた primitive schema が、V3 は quantitive type で切り出された

辺りが変わったポイントという事になります。元々、言語の定義に数の制約がついているのは珍しいなぁ…等と思っていたのですが、制約が緩められるのは朗報です。多分、Azure Digital Twins の既存の大口ユーザーの Twin Graph が日々育っているのでしょうね。

他にも、Microsoft Learn の ”DTDL v3 機能拡張” にも記載があります。
結構便利そうな機能が追加されているので、列記しておきます。

• Annotation Extention

  • カスタムメタデータ追加

• Historization Extention

  • Property または Telemetry を履歴化 ‐ 便利そうだ

• Override Extention

  • Property のオーバーライド

• QAuantitative Types Extention

  • semantic type, unit type, unit を有効にする

これらを使うには、

"@context": [
      "dtmi:dtdl:context;3",
      "dtmi:dtdl:extension:quantitativeTypes;1",
      "dtmi:dtdl:extension:historization;1",
      "dtmi:dtdl:extension:annotation;1",
      "dtmi:dtdl:extension:overriding;1"
]

と書く必要があります。

DTDL に対する私見を少々

DTDL の interface は、OWL 系では、class にあたり、”Art of Conceptual Modeling”では、概念クラスにあたります。
何故、”interface” というキーワードにしたのか、疑問です。素直に class でよかったのでは？
IoT Plung & Play や、component というエレメントの下位での利用については、interface というキーワード、それほど、違和感を感じないのですが、オントロジとしてのキーワードとしてはいかがなものか。
まぁ、モノの値を読み取るシグネチャとしての interface 、と言われてしまえばそれまでなのですが。

他に、relationship の定義方法にも違和感があります。DTDLでは、relationship が、interface の下位のエレメントとして定義されます。
最近の私のモデリングに対する哲学的、かつ、数学的な考察

• 3. モデリングとは ～ 現象学からの考察｜Knowledge & Experience (note.com)

• 5. 概念モデリングに関する圏論的考察 ‐ 議論のとっかかりとして｜Knowledge & Experience (note.com)

を経ての現時点での私の結論は、概念クラスと、関係（Relationship）は同列だという事です。OWL も含め DTDL は、relationship は有向であるという思い込みがあるようです。有向の場合は、twin 間の relationship を矢印で書くと、矢印の始端の twin から見て矢印の終端の twin に対してしか、主題領域の”意味”がないことになります。しかし実際には、終端側の twin から見た始端側の twin も、主題領域的には必ず何らかの意味を持つはずです。という事は、Digital Twins の世界のオントロジ定義において、ある interface（OWL の場合は class）に従属した relationship 定義は、しっくりこないし、正しい世界観を定義できないのではないかなと、思っています。
こういう感じを持っている、この手の専門家って、いないのかしら…

最後に

久しぶりの Digital Twins ネタでした。