CyberLibrarian

【注意】 このドキュメントは、W3CのWeb of Things (WoT) Thing Description W3C Recommendation 9 April 2020の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

First Update: 2020年06月19日


モノのウェブ(WoT)モノの記述

W3C勧告

本バージョン:
https://www.w3.org/TR/2020/REC-wot-thing-description-20200409/
最新公開バージョン:
https://www.w3.org/TR/wot-thing-description/
最新編集者草案:
https://w3c.github.io/wot-thing-description/
実装報告書:
https://w3c.github.io/wot-thing-description/testing/report.html
旧バージョン:
https://www.w3.org/TR/2020/PR-wot-thing-description-20200130/
編集者:
Sebastian Kaebisch (Siemens AG)
Takuki Kamiya (Fujitsu Laboratories of America)
Michael McCool (Intel)
Victor Charpenay (Siemens AG)
Matthias Kovatsch (Huawei)
参加可能:
GitHub w3c/wot-thing-description
File a bug
Commit history
Pull requests
貢献者:
In the GitHub repository
リポジトリ:
We are on GitHub
File a bug

公開以後に報告されたエラーや問題がないか正誤表を確認してください

翻訳版も参照してください。


要約

このドキュメントでは、モノのウェブ(WoT;Web of Things)モノの記述(Thing Description)の形式モデルと共通表現について記述しています。モノの記述では、モノのメタデータとインターフェースを記述します。このとき、モノとは、モノのウェブに対して対話を提供し、モノのウェブに加えられる、物理的または仮想的なエンティティーを抽象化したものです。モノの記述は、様々なデバイスを統合し、様々なアプリケーションの相互運用を可能にする小さな語彙に基づく一連の対話を提供します。デフォルトでは、モノの記述はJSON形式でエンコードされ、JSON-LDの処理も可能です。後者は、機械が理解できる方法でモノに関する知識を表現するための強力な基盤を提供します。モノの記述のインスタンスは、モノ自身が提供できます。あるいは、モノに資源上の制限がある場合(例えば、メモリ空間が限られている場合)や、モノのウェブと互換性のある旧式デバイスがモノの記述で改造されている場合には外部で提供できます。

このドキュメントのステータス

この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、https://www.w3.org/TR/のW3C技術報告インデックスにあります。

このドキュメントは、Web of Thingsワーキンググループによって勧告として公開されました。

この仕様の議論にはGitHubの課題をお勧めします。または、メーリング・リストにコメントを送信することもできます。コメントはpublic-wot-wg@w3.org(アーカイブ)に送信してください。

ワーキンググループの実装報告書を参照してください。

このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。

このドキュメントは、W3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

このドキュメントは、2019年3月1日のW3Cプロセス・ドキュメントによって管理されています。

1. はじめに

この項は非規範的です。

WoTモノの記述(TD)は、W3Cのモノのウェブ(WoT)の中心的な構成要素であり、モノのエントリ・ポイントと考えることができます(ウェブサイトのindex.htmlとよく似ています)。TDのインスタンスには4つの主要コンポーネントがあります。それらは、モノ自身に関するテキスト形式のメタデータ、モノの使用方法を示す一連の対話アフォーダンス、機械による理解のためにモノと交換されるデータのスキーマ、そして最後に、ウェブ上の他のモノやドキュメントとの形式的または非形式的な関係を表すためのウェブ・リンクです。

W3C WoTの対話モデルでは、3種類の対話アフォーダンスを定義しています。プロパティー(PropertyAffordanceクラス)は、現在の値の取得や操作状態の設定などのパラメータの検知と制御に使用できます。アクション(ActionAffordanceクラス)は、物理的な(したがって、時間のかかる)プロセスの呼び出しをモデル化しますが、既存のプラットフォームのRPCのような呼び出しを抽象化するためにも使用できます。イベント(EventAffordanceクラス)は、通知、個別のイベント、または値のストリームが受信者に非同期で送信される通信のプッシュ・モデルに用いられます。詳細に関しては、[WOT-ARCHITECTURE]を参照してください。

一般的に、TDは、URIスキーム[RFC3986](例えば、httpcoapなど。[IANA-URI-SCHEMES])で識別される様々なプロトコル・バインディングに関するメタデータ、メディア・タイプ[RFC2046]に基づくコンテンツ・タイプ(例えば、application/jsonapplication/xmlapplication/cborapplication/exiなど。[IANA-MEDIA-TYPES])、およびセキュリティのメカニズム(認証、許可、機密性など)を提供します。TDのインスタンスのシリアル化は、JSON[RFC8259]に基づいており、JSON名は、この仕様書で定義しているTD語彙の用語を指します。さらに、TDのJSONシリアル化は、JSON-LD 1.1[JSON-LD11]の構文に従い、拡張機能と豊かなセマンティックの処理を可能にします。

例1は、TDのインスタンスです。MyLampThingというタイトルの照明であるモノを記述することにより、プロパティー、アクション、イベントの対話モデルを示しています。

このTDの例から、タイトルの状態を持つ1つのプロパティー・アフォーダンスが存在することが分かります。さらに、(forms 構造内でhrefのメンバーによってアナウンスされる)https://mylamp.example.com/statusというURIでGETメソッドを用いて(セキュアな形式の)HTTPプロトコルを介してこのプロパティーにアクセスでき、文字列ベースの状態の値を返すということを示す情報が提供されています。GETメソッドの使用については明示的に述べられていませんが、それは、このドキュメントで定義しているデフォルト時の解釈(default assumption)の1つです。

同様に、https://mylamp.example.com/toggleという資源でPOSTメソッドを用いてスイッチの状態を切り替えるアクション・アフォーダンスが指定されており、この場合も、POSTはアクションを呼び出すためのデフォルト時の解釈です。

イベント・アフォーダンスにより、モノが非同期メッセージを送信するメカニズムが有効になります。ここでは、https://mylamp.example.com/ohのロング・ポーリングのサブプロトコル(long polling subprotocol)でHTTPを用いて、照明が過熱するイベントの可能性があるときに通知される購読を取得できます。

この例では、アクセスにユーザ名とパスワードを求めるbasicなセキュリティ・スキームも指定しています。セキュリティ・スキームは、まずsecurityDefinitionsで名前が与えられ、次にsecurityの部分でその名前を指定することでアクティブ化されることに注意してください。この例では、HTTPプロトコルの使用と組み合わせて、HTTP基本認証の使用方法を示しています。少なくとも1つのセキュリティ・スキームを最上位レベルで指定することは必須であり、それが、すべての資源に対するデフォルトのアクセス要件となります。しかし、セキュリティ・スキームはフォームごとに指定することもできます。フォームのレベルで指定した設定は、Thingレベルで指定した設定を上書きするため、きめ細かいアクセス制御の指定が可能です。nosecという特殊なセキュリティ・スキームを用いて、アクセス制御メカニズムが用いられていないことを示すこともできます。後ほど、追加の例を示します。

モノの記述は、名前空間にコンテキストの定義を追加する可能性を提供します。特定のアプリケーション領域の論理規則などの正式な知識が特定の名前空間にある場合は、このメカニズムを用いて、モノの記述のインスタンスの内容に追加のセマンティクスを組み込むことができます。コンテキスト情報は、formsフィールドで宣言されている基礎となる通信プロトコルの一部の設定と動作を指定するのにも役立ちます。例2では、@contextに2番目の定義を導入して、SAREF(Smart Appliance Reference Ontology)[SMARTM2M]への参照として接頭辞sarefを宣言することにより、例1のTDサンプルを拡張しています。このIoTオントロジーには、@typeフィールドの値として設定できるセマンティック・ラベルとして解釈される用語が含まれており、モノのセマンティクスとその対話アフォーダンスを提供します。下記の例では、モノsaref:LightSwitchstatusプロパティーsaref:OnOffStatetoggleアクションsaref:ToggleCommandでラベル付けしています。

一部の@context内の宣言メカニズムは、JSON-LDで指定されます。TDのインスタンスは、その仕様のバージョン1.1[json-ld11]に準拠しています。したがって、TDのインスタンスはRDFドキュメントとして処理することもできます(セマンティックな処理の詳細に関しては、付録§ D. SON-LDコンテキストの使用法https://www.w3.org/2019/wot/tdなどの名前空間IRI下のドキュメントを参照)。

2. 適合性

非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。

このドキュメントの「することができる/してもよい(MAY)」、「しなければならない(MUST)」、「してはならない(MUST NOT)」、「推奨される(RECOMMENDED)」、「すべきである/する必要がある(SHOULD)」、「すべきでない/する必要がない(SHOULD NOT)」というキーワードは、ここで示しているように、すべて大文字で表示されている場合にのみ、BCP 14[RFC2119] [RFC8174]で記述されているように解釈されるべきです。

モノの記述のインスタンスは、モノの記述のシリアル化に関する§ 5. TD情報モデル§ 6. TD表現形式の規範的なステートメントに従っていれば、この仕様に準拠します。

モノの記述のインスタンスを検証するためのJSONスキーマ[JSON-SCHEMA]は、付録§ B. TDのインスタンス検証用JSONスキーマで提供しています。

3. 用語

この項は非規範的です。

モノ(Thing)、利用者(Consumer)、モノの記述(Thing Description)(TD)、対話モデル(Interaction Model)、対話アフォーダンス(Interaction Affordance)、プロパティー(Property)、アクション(Action)、イベント(Event)、プロトコル・バインディング(Protocol Binding)、サービエント(Servient)、WoTインターフェース(WoT Interface)、WoTランタイム(WoT Runtime)などの基本的なWoT用語は、WoTアーキテクチャ仕様[WOT-ARCHITECTURE]の3項で定義しています。

さらに、この仕様では次の定義を導入しています。

TDコンテキスト拡張(TD Context Extension)
語彙用語の追加により、モノの記述を拡張するメカニズム。これは、プロトコル・バインディング、セキュリティ・スキーム、データ・スキーマなどのコアなメカニズムに対するセマンティック・アノテーションと拡張の基礎です。
TD情報モデル(TD Information Model)
制約が適用される定義済み語彙で構築されるクラス定義の集合。したがって、その語彙のセマンティクスを定義します。クラス定義は通常、シグネチャ(一組の語彙用語)と、そのシグネチャに関する機能で表現されます。TD情報モデルには、クラスのグローバル関数として定義されているデフォルト値も含まれています。
TDプロセッサ(TD Processor)
特定の形式でモノの記述の内部表現をシリアル化する、および/または、その形式から逆シリアル化することができるシステム。TDプロセッサは、セマンティック的に矛盾するモノの記述、つまり、Thingクラスのインスタンス関係の制約を満たすことができないモノの記述を検出しなければなりません。その目的のために、TDプロセッサは、すべての可能なデフォルト値が割り当てられている正規形のモノの記述を計算できます。TDプロセッサは通常、WoTランタイムのサブシステムです。TDプロセッサの実装は、TDの作成者のみ(TDドキュメントへのシリアル化が可能)またはTDの利用者のみ(TDドキュメントからの逆シリアル化が可能)です。
TDシリアル化(TD Serialization)またはTDドキュメント(TD Document)
サービエント間で保存および交換できるモノの記述のテキストまたはバイナリ表現。TDシリアル化は特定の表現形式に従い、ネットワーク上で交換される際にメディア・タイプによって識別されます。モノの記述のデフォルト表現形式は、この仕様で定義しているJSONベースです。
語彙(Vocabulary)
名前空間IRIで識別される語彙用語のコレクション。
用語(Term)および語彙用語(Vocabulary Term)
文字列。用語語彙の一部である場合、つまり、名前空間IRIが接頭辞として付与されている場合は、語彙用語と呼ばれます。読みやすくするために、このドキュメントで示している語彙用語は、完全なIRIとしてではなく、常にコンパクトな形式で記述しています。

これらの定義については、§ 5.2 予備事項でさらに展開します。

4. 名前空間

この仕様の§ 5. TD情報モデルで定義しているTD情報モデルのバージョンは、次のIRIで識別されます。

https://www.w3.org/2019/wot/td/v1

URI[RFC3986]でもあるこのIRI[RFC3987]は、JSON-LDコンテキスト・ファイル[json-ld11]を取得するために逆参照でき、TDドキュメントのコンパクトな文字列をIRIベースの完全な語彙用語に展開できます。しかし、この処理は、JSONベースのTDドキュメントを、TDプロセッサ実装のオプション機能であるRDFに変換する場合にのみ必要です。

現在の仕様では、語彙用語は常にコンパクトな形式で示されます。その展開形式には、それが属している語彙の名前空間IRI下でアクセスできます。この名前空間は、§ 5.3 クラスの定義の構造に従います。TD情報モデルで用いられる個々の語彙は、次のような独自の名前空間IRIを持っています。

語彙 名前空間IRI
コア https://www.w3.org/2019/wot/td#
データ・スキーマ https://www.w3.org/2019/wot/json-schema#
セキュリティ https://www.w3.org/2019/wot/security#
ハイパーメディア制御 https://www.w3.org/2019/wot/hypermedia#

語彙は互いに独立しています。これらは、他のW3C仕様で再利用したり、拡張したりすることができます。語彙の設計に互換性のない(breaking)変更を加えるたびに、年ベースの新しい名前空間URIの割り当てが必要になります。TD情報モデルの全般的な一貫性を維持するために、互換性のある(non-breaking)変更(特に新しい用語の追加)も識別するように、関連するJSON-LDコンテキスト・ファイルは、すべてのバージョンが独自のURI(v1v1.1v2、...)を持つようにバージョン付けされていることに注意してください。

ある名前空間IRI下の語彙は、互換性のある変更しか行えないため、その内容を安全にキャッシュしたりアプリケーションに埋め込んだりすることができます。名前空間IRI下で比較的静的な内容を公開する利点の1つは、制約のあるデバイス間で交換されるメッセージのペイロード・サイズの最適化です。これにより、プライベート・ネットワークから公開されている語彙にアクセスするデバイスに起因するプライバシーの漏えいも回避されます(§ 9.1 プライバシーのリスクを逆参照するコンテキストも参照)。

5. TD情報モデル

この項では、TD情報モデルについて紹介します。TD情報モデルは、「§ 6. TD表現形式」で別個に説明している、モノの記述の処理とそのシリアル化の概念的な基盤として機能します。

5.1 概要

TD情報モデルは、次の独立した語彙に基づいて構築されます。

これらの語彙はそれぞれ、基本的にデータ構造の構築に使用できる用語の集合であり、従来のオブジェクト指向の意味のオブジェクトとして解釈されます。オブジェクトはクラスのインスタンスであり、プロパティーを持ちます。W3C WoTのコンテキストでは、モノとその対話アフォーダンスを示します。オブジェクトの正式な定義を§ 5.2 予備事項で示しています。TD情報モデルの主要な要素は、§ 5.3 クラスの定義で示しています。デフォルト値が存在している場合は、特定のオブジェクト・プロパティーをTDで省略できます。デフォルトのリストは、§ 5.4 デフォルト値の定義で示しています。

次に示すUML図は、TD情報モデルの概要を示しています。すべてのクラスを表として表しており、Thingというクラスから始まる、クラス間に存在する関連付けを有向の矢印として表しています。読みやすくするために、図は、4つの基本語彙ごとに1つずつの、4つの部分に分割しています。

TDコア語彙のTD情報モデルのUML図
1 TDコア語彙

データ・スキーマ語彙のTD情報モデルのUML図
2 データ・スキーマ語彙

WoTセキュリティ語彙のTD情報モデルのUML図
3 WoTセキュリティ語彙

ハイパーメディア制御語彙のTD情報モデルのUML図
4 ハイパーメディア制御語彙

5.2 予備事項

ツリー・ベースのドキュメントに関するシンプルな規則(つまり、未加工のJSONの処理)と、豊かなセマンティック・ウェブ・ツール(つまり、JSON-LD処理)の両方で容易に処理できるモデルを提供するために、このドキュメントでは、次の形式的な予備事項を定義し、それに応じてTD情報モデルを構築します。

この項のすべての定義は集合を意味しており、それは直感的に、それ自身が集合になり得る要素のコレクションです。任意の複雑なデータ構造はすべて集合として定義できます。特に、オブジェクトは、次のとおりに帰納的に定義されたデータ構造です。

この定義はオブジェクトが同じ名前の複数の名前-値のペアを含むことを妨げませんが、これは一般的にこの仕様では検討しません。要素の名前が数字のみであるオブジェクト配列と呼びます。同様に、要素が用語(いかなる語彙にも属さない)のみを名前として持つオブジェクトマップと呼びます。マップ内の名前-値のペアに現れるすべての名前は、そのマップの範囲内で一意であると見なされます。

さらに、オブジェクトクラスのインスタンスになりえます。語彙用語で示されるクラスは、シグネチャと呼ばれる一組の語彙用語で最初に定義されます。シグネチャが空のクラスは、単純型と呼ばれます。

クラスシグネチャにより、クラスを詳細に定義した2つの関数(割り当て関数型関数)を構築できます。クラス割り当て関数は、クラスシグネチャ語彙用語を入力として取り、trueまたはfalseを出力として返します。直感的には、割り当て関数は、クラスをインスタンス化するときにシグネチャの要素が必須かオプションかを示します。クラス型関数は、クラスシグネチャ語彙用語を入力として取り、別のクラスを出力として返します。これらの関数は部分的です。それらの定義域は定義されているクラスシグネチャに制限されます。

これらの2つの関数に基づいて、オブジェクトクラスで構成されるペアに対してインスタンス関係を定義できます。この関係は、満たすべき制約と定義されています。つまり、次の2つの制約が両方とも満たされる場合、オブジェクトクラスのインスタンスになります。

上記の定義によれば、オブジェクトは、その構造に関係なく、すべての単純型のインスタンスになります。代わりに、インスタンス関係の別の定義が単純型に導入されています。オブジェクトは、特定の字句形式を持つ用語である場合、単純型のインスタンスです(例えば、boolean型の場合はtruefalseで、unsignedInt型の場合は123...など)。

さらに、パラメータ化されたクラスと呼ばれる追加のクラスを、汎用的なマップ配列の構造から派生させることができます。オブジェクトは、含んでいるすべての名前-値のペアの値がこのクラスのインスタンスであるようなマップである場合、何らかのクラスマップ、つまり、何らかのクラスパラメータ化されたマップ型のインスタンスです。同じことが配列にも当てはまります。

最後に、前者のすべてのインスタンスが後者のインスタンスでもある場合、クラスは他のクラスサブクラスになります。

上記のすべての定義を前提とすると、TD情報モデルは、クラス名(語彙用語)、シグネチャ(語彙用語の集合)、割り当て関数、および型関数を含む、クラス定義の集合と理解されます。これらのクラスの定義は、§ 5.3 クラスの定義の表として提供しています。各表では、割り当ての列の「必須」の値(または「オプション」)は、割り当て関数が対応する語彙用語に対してtrue(またはfalse)を返すことを示しています。

慣例により、単純型は小文字で始まる名前で示されます。TD情報モデルは、XMLスキーマ[XMLSCHEMA11-2-20120405]で定義されている、stringanyURIdateTime, integerunsignedInt, doublebooleanという単純型を参照します。それらの定義(つまり、字句形式の仕様)は、TD情報モデルの範囲外です。

さらに、TD情報モデルは、語彙用語のペアにおけるグローバル関数を定義します。この関数は、クラス名と別の語彙用語を入力として取り、オブジェクトを返します。返されたオブジェクトnullではない場合、それは入力クラスのインスタンスの入力語彙用語の割り当てに対するデフォルト値を表します。この関数により、上記の割り当て関数で定義している制約を緩和できます。すべての必須の割り当てが含まれている場合、または欠落している割り当てにデフォルト値が存在する場合、オブジェクトクラスのインスタンスです。すべてのデフォルト値§ 5.4 デフォルト値の定義の表で示しています。§ 5.3 クラスの定義の各表には、TD情報モデルクラス語彙用語の対応する組み合わせにデフォルト値が使用可能な場合に、割り当て列に「デフォルトあり」という値が含まれています。

ここで紹介している形式化では、抽象的なデータ構造としてのオブジェクトと、モノなどの物理世界のオブジェクトとの、ありえる関係を考慮していません。しかし、TD情報モデルに含まれるすべての語彙用語をRDF資源として再解釈し、物理世界のより大きなモデル(オントロジー)に統合する可能性には注意を払いました。セマンティックな処理の詳細に関しては、§ D. JSON-LDコンテキストの使用法や、https://www.w3.org/2019/wot/tdなどの名前空間IRI下にあるドキュメントを参照してください。

5.3 クラスの定義

TDプロセッサは、§ 5.3.1 コア語彙の定義§ 5.3.2 データ・スキーマ語彙の定義§ 5.3.3 セキュリティ語彙の定義、および§ 5.3.4 ハイパーメディア制御語彙の定義で定義しているすべてのクラスクラス・インスタンス化の制約を満たさなければなりません(MUST)。

5.3.1 コア語彙の定義

5.3.1.1 Thing(モノ)

WoTモノの記述でメタデータとインターフェースが記述されている物理エンティティーまたは仮想エンティティーの抽象化。それに対し、仮想エンティティーは1つ以上のモノの合成物です。

語彙用語 説明 割り当て
@context TDドキュメント全体で用いる用語と呼ばれる省略名を定義するためのJSON-LDキーワード。 必須 anyURIまたは配列
@type セマンティック・タグ(または型)でオブジェクトをラベル付けするJSON-LDキーワード。 オプション stringまたはstring配列
id URI[RFC3986]形式のモノの識別子(例えば、安定したURI、一時的かつ可変なURI、ローカルなIPアドレスを持つURI、URNなど)。 オプション anyURI
title デフォルトの言語に基づいて、人間が読めるタイトルを提供します(例えば、UI表現用のテキストを表示)。 必須 string
titles 多言語の人間が読めるタイトルを提供します(例えば、様々な言語でUI表現のテキストを表示)。 オプション MultiLanguage
description デフォルト言語に基づいて、追加の(人間が読める)情報を提供します。 オプション string
descriptions 様々な言語の(人間が読める)情報をサポートするために使用できます。 オプション MultiLanguage
version バージョン情報を提供します。 オプション VersionInfo
created TDのインスタンスがいつ作成されたかの情報を提供します。 オプション dateTime
modified TDのインスタンスがいつ最終的に変更されたかの情報を提供します。 オプション dateTime
support TDの管理者に関する情報をURIスキーム(例えば、mailto[RFC6068]、tel[RFC3966]、https)として提供します。 オプション anyURI
base TDドキュメント全体のすべての相対URI参照に用いる基底URIを定義します。TDのインスタンス内では、[RFC3986]で定義されているアルゴリズムを用いて、すべての相対URIが基底URIに対して相対的に解決されます。

baseは、@context内で用いられるURIと、TDのインスタンスにセマンティックな処理が適用されるときに関連があるリンクト・データ[LINKED-DATA]のグラフ内で用いられるIRIには影響を与えません。
オプション anyURI
properties モノのすべてのプロパティー・ベースの対話アフォーダンス オプション PropertyAffordanceマップ
actions モノのすべてのアクション・ベースの対話アフォーダンス オプション ActionAffordanceマップ
events モノのすべてのイベント・ベースの対話アフォーダンス オプション EventAffordanceマップ
forms 操作の実行方法を記述する、フォームのハイパーメディア制御の集合。フォームは、プロトコル・バインディングのシリアル化です。このバージョンのTDでは、モノのレベルで記述できるすべての操作は、モノのプロパティーと一度にまとめて対話する方法に関するものです。 オプション Form配列
security セキュリティ定義名の集合。securityDefinitionsで定義されているものから選定します。資源にアクセスするためには、これらすべてが満たされていなければなりません。 必須 stringまたはstring配列
securityDefinitions 名前付きセキュリティ設定(定義のみ)の集合。securityの名前-値のペアで名前が用いられていなければ、実際には適用されません。 必須 SecuritySchemeマップ

@contextの名前-値のペアには、anyURI型の場合は直接、配列型の場合は最初の要素として、anyURIであるhttps://www.w3.org/2019/wot/td/v1を含めなければなりません(MUST)。@context配列である場合は、anyURIであるhttps://www.w3.org/2019/wot/td/v1の後にanyURI型またはマップ型の要素を任意の順序で置くことができますが(MAY)、@context配列内には、すべての名前-値のペアを持つマップを1つだけ含めることをお勧めします(RECOMMENDED)。値がanyURI型の名前空間識別子であり、名前がその名前空間を示す用語または接頭辞である場合、@context配列に含まれるマップには、名前-値のペアを含めることができます(MAY)。名前が@languageという用語で、値が[BCP47]で定義されている整形式の言語タグである場合(例えば、ende-ATgsw-CHzh-Hanszh-Hant-HKsl-nedis)、@context配列に含まれる1つのマップには、モノの記述のデフォルト言語を定義する名前-値のペアを含めるべきです(SHOULD)。

人間が読めるすべてのテキスト文字列の基本書字方向の計算は、次の一連の規則によって定義されます。

  • 言語タグが指定されていない場合は、基本書字方向は、最初の強い文字(first-strong)のヒューリスティクスまたはCLDR Likely Subtags[LDML]などの検出アルゴリズムによって推測されるべきである(SHOULD)。
  • MultiLanguageマップの外部では、基本書字方向は、デフォルト言語の言語タグから推測できる(MAY)。
  • MultiLanguageマップの内部では、名前-値のペアの各値の基本書字方向は、対応する名前で指定されている言語タグから推測できる(MAY)。
  • 異なる基本書字方向を持つ複数のスクリプトで言語を記述できる場合、@languageまたはMultiLanguageマップで指定されている対応する言語タグには、適切な基本書字方向を推測できるように、文字のサブタグを含めなければならない(MUST)。例は、アゼルバイジャン語(Azeri)で、ラテン文字を用いる場合(az-Latnを用いて指定)はLTRで、アラビア文字を用いる場合(az-Arabを用いて指定)はRTLで記述される。

TDプロセッサは、双方向テキストを処理する際に、特定の特殊なケースに注意すべきです。ユーザに文字列を提示する際に、特に周囲のテキストに埋め込むときには(例えば、ウェブ・ユーザ・インターフェース用に)、bidi分離(bidi isolation)を用いるように注意すべきです。言語が正しく識別されたとしても、方向が混在する文はどの言語においても発生しえます。

TDの作成者は、未熟なユーザ・エージェントが正常に表示できる方法で、方向が混合する文字列を提供するように努めるべきです。例えば、RTLの文字列がLTR進行で始まる場合(ラテン文字の数字、ブランド名や商号など)、文字列の先頭にRLMの文字を含めるか、逆方向の進行をbidi制御でラップすることで適切な表示をサポートできます。

ウェブの文字列: 言語と方向のメタデータ[string-meta]は、ガイダンスを提供し、双方向テキストを用いる場合のいくつかの落とし穴を例示しています。

properties(プロパティー)、actions(アクション)、およびevents(イベント)の配列で明示的に提供される対話アフォーダンスに加えて、モノは、オプションのforms配列Formインスタンスによって示されるメタ対話も提供できます。モノのインスタンスのforms配列Formインスタンスが含まれている場合、opという名前に直接的に、または配列内で割り当てられている文字列の値は、readallpropertieswriteallpropertiesreadmultipleproperties、またはwritemultiplepropertiesのいずれかの操作型の1つでなければなりません(MUST)。(モノのインスタンス内のformの使用を参照してください。)

ObjectSchemaインスタンスのpropertiesマップに、対応するPropertyAffordancesインスタンスの名前で識別されるPropertyAffordancesの各データ・スキーマが含まれている場合、これらのメタ対話ごとのデータ・スキーマは、各PropertyAffordanceインスタンスのデータ・スキーマを1つのObjectSchemaインスタンスに結合することで構築されます。

(例えば、TDコンテキスト拡張などにより)特に指定されていない場合、readmultipleproperties操作のリクエスト・データは、Formインスタンスで指定されているコンテンツ・タイプにシリアル化されている、意図されたPropertyAffordancesインスタンス名を含む配列です。

5.3.1.2 InteractionAffordance(対話アフォーダンス)

可能な選択肢を利用者に提示するモノのメタデータで、これにより、利用者がモノと対話を行える方法を提案します。潜在的なアフォーダンスには多くの種類がありますが、W3C WoTでは、プロパティー、アクション、イベントという3種類の対話アフォーダンスを定義しています。

語彙用語 説明 割り当て
@type セマンティック・タグ(または型)でオブジェクトをラベル付けするJSON-LDキーワード。 オプション stringまたはstring配列
title デフォルトの言語に基づいて、人間が読めるタイトルを提供します(例えば、UI表現用のテキストを表示)。 オプション string
titles 多言語の人間が読めるタイトルを提供します(例えば、様々な言語でUI表現のテキストを表示)。 オプション MultiLanguage
description デフォルト言語に基づいて、追加の(人間が読める)情報を提供します。 オプション string
descriptions 様々な言語の(人間が読める)情報をサポートするために使用できます。 オプション MultiLanguage
forms 操作の実行方法を記述する、フォームのハイパーメディア制御の集合。フォームは、プロトコル・バインディングのシリアル化です。 必須 Form配列
uriVariables DataSchema宣言に基づいて、URIテンプレート変数をコレクションとして定義します。 オプション DataSchemaマップ

InteractionAffordanceというクラスには、次のサブクラスがあります。

5.3.1.3 PropertyAffordance(プロパティー・アフォーダンス)

モノの状態を公開する対話アフォーダンス。この状態は、後で取得(読み取り)し、オプションで更新(書き込み)できます。モノは、変更後の新しい状態をプッシュすることにより、プロパティーを監視可能にすることも選択できます。

語彙用語 説明 割り当て
observable モノと仲介を提供するサービエントが、このプロパティーのobserveproperty操作をサポートするプロトコル・バインディングを提供すべきかどうかを示すヒント。 オプション boolean

プロパティー・インスタンスは、DataSchemaというクラスのインスタンスでもあります。したがって、typeunitreadOnlywriteOnlyなどのメンバーを含めることができます。

PropertyAffordanceは、InteractionAffordanceクラスDataSchemaクラスサブクラスです。FormインスタンスがPropertyAffordanceインスタンス内にある場合、opに割り当てられている値は、readpropertywritepropertyobservepropertyunobserveproperty、またはこれらの用語の組み合わせを含でいる配列のいずれかでなければなりません(MUST)。

5.3.1.4 ActionAffordance(アクション・アフォーダンス)

状態を操作したり(例えば、照明のオン/オフを切り替える)、モノにおけるプロセスを始動させる(例えば、時間の経過とともに照明を暗くする)といった、モノの機能の呼び出しを可能にする対話アフォーダンス。

語彙用語 説明 割り当て
input アクションの入力データ・スキーマを定義するために用います。 オプション DataSchema
output アクションの出力データ・スキーマを定義するために用います。 オプション DataSchema
safe アクションが安全か(=true)否かを通知します。アクションを呼び出す際に、内部状態(資源の状態を参照)が変更されていないかを通知するために用います。その場合、例として応答をキャッシュできます。 デフォルトあり boolean
idempotent アクションが冪等か(=true)否かを示します。同じ入力に基づいて、結果が同じであるアクション(存在している場合)を繰り返し呼び出すことができるかどうかを通知します。 デフォルトあり boolean

ActionAffordanceは、InteractionAffordanceクラスサブクラスです。FormインスタンスがActionAffordanceインスタンス内にある場合、opに割り当てられている値は、invokeactionでなければなりません(MUST)。

5.3.1.5 EventAffordance(イベント・アフォーダンス)

イベント(例えば、オーバーヒートの警報)の情報源を記述している対話アフォーダンスで、イベント・データを利用者に非同期でプッシュします。

語彙用語 説明 割り当て
subscription 購読時に渡す必要があるデータ(例えば、Webhookを設定するためのフィルターやメッセージ形式)を定義します。 オプション DataSchema
data モノがプッシュするイベントのインスタンス・メッセージのデータ・スキーマを定義します。 オプション DataSchema
cancellation 購読を中止するために渡す必要があるデータ(例えば、Webhookを削除するための特定のメッセージ)を定義します。 オプション DataSchema

EventAffordanceは、InteractionAffordanceクラスサブクラスです。FormインスタンスがEventAffordanceインスタンス内にある場合、opに割り当てられている値は、subscribeeventunsubscribeevent、または配列内の両方の用語のいずれかでなければなりません(MUST)。

5.3.1.6 VersionInfo(バージョン情報)

TDドキュメントに関するバージョン情報を提供するモノのメタデータ。必要に応じて、ファームウェアやハードウェアのバージョン(TD名前空間外の用語定義)などの付加的なバージョン情報をTDコンテキスト拡張のメカニズムを介して拡張できます。

語彙用語 説明 割り当て
instance このTDのインスタンスのバージョン表示を提供します。 必須 string

VersionInfoクラスのインスタンス内の値は、ドットで区切られた3つの数字の列がそれぞれメジャー・バージョン、マイナー・バージョン、パッチ・バージョンを示す、セマンティック・バージョニングのパターンに従うことをお勧めします。詳細に関しては、[SEMVER]を参照してください。

5.3.1.7 MultiLanguage(多言語)

[BCP47]で記述されている言語タグによって識別される様々な言語の人間が読めるテキストの集合を提供するマップ。モノの記述のインスタンスにおけるこのコンテナの使用例については、§ 6.3.2 人間が読めるメタデータを参照してください。

MultiLanguageマップのそれぞれの名前は、[BCP47]で定義されている言語タグでなければなりません(MUST)。MultiLanguageマップのそれぞれの値は、string型でなければなりません(MUST)。

5.3.2 データ・スキーマ語彙の定義

データ・スキーマ語彙定義は、JSONスキーマ[JSON-SCHEMA]で定義されている用語の非常に一般的なサブセットを反映したものです。モノの記述のインスタンス内のデータ・スキーマ定義はこの定義済みのサブセットに限定されず、§ 7. TDコンテキスト拡張で記述しているとおり、追加の用語にTDコンテンツ拡張を用いて、JSONスキーマにある追加の用語を使用でき、そうでない場合は、これらの用語は、TDプロセッサによってセマンティック的に無視されることに注意が必要です。(セマンティックな処理の詳細に関しては、§ D. JSON-LDコンテキストの使用法や、https://www.w3.org/2019/wot/tdなどの名前空間IRI下のドキュメントを参照してください)。

データ・スキーマは、データ形式に含まれるデータの抽象的な表記法です。TDでは、具体的なデータ形式は、コンテンツ・タイプを用いてForm(§ 5.3.4.2 Form(フォーム)を参照)で指定されます。Formのインスタンス内のコンテンツ・タイプの値がapplication/jsonであれば、JSONスキーマ・プロセッサでデータ・スキーマを直接処理できます。そうでない場合は、モノのウェブ(WoT)バインディング・テンプレート[WOT-BINDING-TEMPLATES]は、XML[xml]などの他のコンテンツ・タイプへのデータ・スキーマの利用可能なマッピングを定義します。フォームのインスタンス内のコンテンツ・タイプがapplication/jsonでなく、コンテンツ・タイプにマッピングが定義されていない場合は、データ・スキーマを指定してもコンテンツ・タイプには意味がありません。

5.3.2.1 DataSchema(データ・スキーマ)

用いているデータ形式を記述するメタデータ。検証に使用できます。

語彙用語 説明 割り当て
@type セマンティック・タグ(または型)でオブジェクトをラベル付けするJSON-LDキーワード。 オプション stringまたはstring配列
title デフォルトの言語に基づいて、人間が読めるタイトルを提供します(例えば、UI表現用のテキストを表示)。 オプション string
titles 多言語の人間が読めるタイトルを提供します(例えば、様々な言語でUI表現のテキストを表示)。 オプション MultiLanguage
description デフォルト言語に基づいて、追加の(人間が読める)情報を提供します。 オプション string
descriptions 様々な言語の(人間が読める)情報をサポートするために使用できます。 オプション MultiLanguage
type JSONスキーマと互換性のあるJSONベースのデータ型の割り当て(ブール、整数、数値、文字列、オブジェクト、配列、ヌル(null)のうちの1つ)。 オプション string(objectarraystringnumberinteger, booleannullのうちの1つ)
const 定数値を提供します。 オプション 任意の型
unit 例えば、国際的な科学、工学、ビジネスなどで用いられている単位情報を提供します。 オプション string
oneOf 配列内の指定されたスキーマの1つに対してデータが有効であることを保証するために用います。 オプション DataSchema配列
enum 配列として提供される制限のある値の集合。 オプション 任意の型の配列
readOnly プロパティーの対話/値が読み取り専用か(=true)否か(=false)を示すヒントであるブール値。 デフォルトあり boolean
writeOnly プロパティーの対話/値が書き込み専用か(=true)否か(=false)を示すヒントであるブール値。 デフォルトあり boolean
format 「date-time」、「email」、「uri」などの形式パターンに基づく検証を可能にします(以下も参照)。 オプション string

DataSchemaというクラスには、次のサブクラスがあります。

formatの文字列の値は、[JSON-SCHEMA](特に、7.3 定義フォーマット)で定義されている固定値の集合とその対応するフォーマットの規則から判別されます。サービエントは、formatの値を用いて、それに応じた追加の検証を実行できます(MAY)既知の値の集合にない値がformatに割り当てられていれば、そのような検証は成功すべきです(SHOULD)。

5.3.2.2 ArraySchema(配列スキーマ)

配列型のデータを記述するメタデータ。このサブクラスは、DataSchemaインスタンスのtypeに割り当てられているarrayという値で示されます。

語彙用語 説明 割り当て
items 配列の特性を定義するために用います。 オプション DataSchemaまたはDataSchema配列
minItems 配列内になくてはならないアイテムの最小の数を定義します。 オプション unsignedInt
maxItems 配列内になくてはならないアイテムの最大の数を定義します。 オプション unsignedInt
5.3.2.3 BooleanSchema(ブール・スキーマ)

boolean型のデータを記述するメタデータ。このサブクラスは、DataSchemaインスタンスのtypeに割り当てられているbooleanという値で示されます。

5.3.2.4 NumberSchema(数値スキーマ)

number型のデータを記述するメタデータ。このサブクラスは、DataSchemaインスタンスのtypeに割り当てられているnumberという値で示されます。

語彙用語 説明 割り当て
minimum 最小の数の値を指定します。関連する数値または整数の型にのみ適用されます。 オプション double
maximum 最大の数の値を指定します。関連する数値または整数の型にのみ適用されます。 オプション double
5.3.2.5 IntegerSchema(整数スキーマ)

integer型のデータを記述するメタデータ。このサブクラスは、DataSchemaインスタンスのtypeに割り当てられているintegerという値で示されます。

語彙用語 説明 割り当て
minimum 最小の数の値を指定します。関連する数値または整数の型にのみ適用されます。 オプション integer
maximum 最大の数の値を指定します。関連する数値または整数の型にのみ適用されます。 オプション integer
5.3.2.6 ObjectSchema(オブジェクト・スキーマ)

object型のデータを記述するメタデータ。このサブクラスは、DataSchemaインスタンスのtypeに割り当てられているobjectという値で示されます。

語彙用語 説明 割り当て
properties データ・スキーマの入れ子の定義。 オプション DataSchemaマップ
required オブジェクト型のどのメンバーが必須かを定義します。 オプション string配列
5.3.2.7 StringSchema(文字列スキーマ)

string型のデータを記述するメタデータ。このサブクラスは、DataSchemaインスタンスのtypeに割り当てられているstringという値で示されます。

5.3.2.8 NullSchema(ヌル(Null)スキーマ)

null型のデータを記述するメタデータ。このサブクラスは、DataSchemaインスタンスのtypeに割り当てられているnullという値で示されます。このサブクラスは、1つの許容値、つまりnullのみを記述します。これはoneOf宣言の一部として使用でき、その場合、データがnullにもなりえることを示すために用います。

5.3.3 セキュリティ語彙の定義

この仕様は、W3C WoTのプロトコル・バインディングとして適しているプロトコルに直接組み込まれる、またはそのプロトコルで広く用いられる、確立されたセキュリティ・メカニズムの選択について規定しています。現在のHTTPセキュリティ・スキームは、部分的にOpenAPI 3.0.1に基づいています([OPENAPI]も参照)。しかし、この仕様で示しているHTTPセキュリティ・スキーム、語彙、および構文は、OpenAPIと多くの類似点を共有しているものの、互換性はありません。

5.3.3.1 SecurityScheme(セキュリティ・スキーム)

セキュリティ・メカニズムの設定を記述するメタデータ。schemeという名前に割り当てられる値は、§ 5. TD情報モデルで定義している標準的な語彙TDコンテキスト拡張のいずれかで、モノの記述に含まれている語彙内で定義しなければなりません(MUST)。

語彙用語 説明 割り当て
@type セマンティック・タグ(または型)でオブジェクトをラベル付けするJSON-LDキーワード。 オプション stringまたはstring配列
scheme 設定されているセキュリティ・メカニズムの識別。 必須 string(例えば、nosecbasicdigestbearerpsk, oauth2、またはapikey)
description デフォルト言語に基づいて、追加の(人間が読める)情報を提供します。 オプション string
descriptions 様々な言語の(人間が読める)情報をサポートするために使用できます。 オプション MultiLanguage
proxy このセキュリティ設定がアクセスを提供するプロキシ・サーバーのURI。指定されていない場合、対応するセキュリティ設定はエンドポイント用です。 オプション anyURI

SecuritySchemeというクラスには次のサブクラスがあります。

5.3.3.2 NoSecurityScheme(セキュリティ・スキームなし)

nosecという語彙用語で識別されるセキュリティ設定(つまり、"scheme": "nosec")で、資源へのアクセスに認証やその他のメカニズムが必要ないことを示します。

5.3.3.3 BasicSecurityScheme(基本セキュリティ・スキーム)

basicという語彙用語で識別される基本認証[RFC7617]セキュリティ設定(つまり、"scheme": "basic")で、暗号化されていないユーザ名とパスワードを用います。このスキームは、例えば、TLSなどの機密性を提供する他のセキュリティ・メカニズムとともに用いるべきです。

語彙用語 説明 割り当て
in セキュリティ認証情報の場所を指定します。 デフォルトあり string(headerquerybodycookieのうちの1つ)
name クエリ、ヘッダー、またはクッキーのパラメータの名前。 オプション string
5.3.3.4 DigestSecurityScheme(ダイジェスト・セキュリティ・スキーム)

digestという語彙用語で識別されるダイジェスト・アクセス認証[RFC7616]セキュリティ設定(つまり、"scheme": "digest")。このスキームは基本認証に似ていますが、中間者攻撃(man-in-the-middle attack)を回避する機能が追加されています。

語彙用語 説明 割り当て
qop 保護の品質。 デフォルトあり string(authauth-intのうちの1つ)
in セキュリティ認証情報の場所を指定します。 デフォルトあり string(headerquerybodycookieのうちの1つ)
name クエリ、ヘッダー、またはクッキーのパラメータの名前。 オプション string
5.3.3.5 APIKeySecurityScheme(APIキー・セキュリティ・スキーム)

apikeyという語彙用語で識別されるAPIキー認証セキュリティ設定(つまり、"scheme": "apikey")。これは、アクセス・トークンが不透明で、標準的なトークン形式を用いていない場合です。

語彙用語 説明 割り当て
in セキュリティ認証情報の場所を指定します。 デフォルトあり string(headerquerybodycookieのうちの1つ)
name クエリ、ヘッダー、またはクッキーのパラメータの名前。 オプション string
5.3.3.6 BearerSecurityScheme(ベアラー・セキュリティー・スキーム)

ベアラー・トークンがOAuth2と関わりなく用いられる状況のために、bearerという語彙用語で識別されるベアラー・トークン[RFC6750]セキュリティ設定(つまり、"scheme": "bearer")。oauth2スキームが指定されている場合は、一般的に、このスキームを指定する必要はなく、暗黙的に指定されています。formatでは、jwtという値は[RFC7519]との適合性を示し、jwsは[RFC7797]との適合性を示し、cwtは[RFC8392]との適合性を示し、jweは[RFC7516]との適合性を示し、algの値をこれらの標準と整合的に解釈します。ベアラー・トークンのその他の形式とアルゴリズムは、語彙拡張で指定できます(MAY)。

語彙用語 説明 割り当て
authorization 承認サーバーのURI。 オプション anyURI
alg エンコーディング、暗号化、またはダイジェスト・アルゴリズム。 デフォルトあり string(例えば、MD5ES256、またはES512-256)
format セキュリティ認証情報の形式を指定します。 デフォルトあり string(例えば、jwtcwtjwe、またはjws)
in セキュリティ認証情報の場所を指定します。 デフォルトあり string(headerquerybodycookieのうちの1つ)
name クエリ、ヘッダー、またはクッキーのパラメータの名前。 オプション string
5.3.3.7 PSKSecurityScheme(PSKセキュリティ・スキーム)

pskという語彙用語で識別される事前共有キー認証セキュリティ設定(つまり、"scheme": "psk")。

語彙用語 説明 割り当て
identity 選択や確認に使用できる情報を提供する識別子。 オプション string
5.3.3.8 OAuth2SecurityScheme(OAuth2セキュリティ・スキーム)

oauth2という語彙用語で識別される、[RFC6749]と[RFC8252]に適合するシステムのためのOAuth2認証セキュリティ設定です(つまり、"scheme": "oauth2")。codeのフローでは、authorizationtokenの両方が含まれていなければなりません(MUST)。SecuritySchemescopesが定義されていなければ、それは空と見なされます。

語彙用語 説明 割り当て
authorization 承認サーバーのURI。 オプション anyURI
token トークン・サーバーのURI。 オプション anyURI
refresh 更新サーバーのURI。 オプション anyURI
scopes 配列として提供される承認範囲識別子の集合。これらは、クライアントがアクセスできる資源とその方法を識別するために、承認サーバーによって返されたトークンで提供され、フォームに関連付けられます。フォームに関連付けられる値は、そのフォームでアクティブなOAuth2SecuritySchemeで定義されているものから選択すべきです。 オプション stringまたはstring配列
flow 承認フロー。 必須 string(例えば、code)

5.3.4 ハイパーメディア制御語彙の定義

現在のモデルは、モノが公開する(型付きの)ウェブ・リンクとウェブ・フォームの表現を提供します。Linkクラスの定義は、ウェブ・リンク[RFC8288]で定義されている用語の非常に一般的なサブセットを反映したものです。定義された用語は、例えば、照明というモノスイッチというモノによって制御されるなど、別のモノとの関係を記述するために使用できます。Formクラスは、モノ(および、その他のウェブ資源)の状態を操作するために新たに導入されたハイパーメディア制御のフォームに対応しています。

5.3.4.2 Form(フォーム)

フォームは、「フォーム・コンテキスト操作型の操作を実行するために、送信ターゲットリクエスト・メソッドのリクエストを行う」というステートメントとして見ることができ、オプションのフォーム・フィールドで、必要なリクエストを詳細に記述できます。モノの記述では、フォーム・コンテキストは、プロパティー、アクション、イベントなどの周囲のオブジェクト、またはメタ対話のモノ自体です。

語彙用語 説明 割り当て
op フォームで記述された操作を実行するセマンティックな意図を示します。例えば、プロパティーの対話では、getとsetの操作が可能です。プロトコル・バインディングには、get操作用のフォームと、別のset操作用フォームを含むことができます。op属性は、フォームの対象を示し、必要な操作に適したフォームをクライアントが選択できるようにします。opには、それぞれに操作のセマンティックな意図を表す1つ以上の対話の動詞を割り当てることができます。 デフォルトあり stringまたはstring配列(readpropertywritepropertyobservepropertyunobservepropertyinvokeactionsubscribeeventunsubscribeeventreadallpropertieswriteallpropertiesreadmultiplepropertieswritemultiplepropertiesのうちの1つ)
href リンクのターゲットIRIまたはフォームの送信ターゲット。 必須 anyURI
contentType メディア・タイプ(例えば、text/plain)と、そのメディア・タイプの潜在的なパラメータ(例えば、charset=utf-8)[RFC2046]に基づいてコンテンツ・タイプを割り当てます。 デフォルトあり string
contentCoding コンテンツ・コーディングの値は、表現に適用された、または適用できるエンコーディング変換を示します。コンテンツ・コーディングは、その基礎となるメディア・タイプが同一のままで、かつ、情報を失うことなく、表現を圧縮したり、そうでない場合は便利に変換したりするために主に用います。コンテンツ・コーディングの例には、「gzip」、「deflate」などがあります。 オプション string
subprotocol 複数のオプションがある場合に、特定のプロトコルで対話が達成される厳密なメカニズムを示します。例えば、HTTPやイベントの場合、ロング・ポーリング(longpoll)、WebSub[websub](websub)、サーバー送信イベント(sse)[html](EventSourceとしても知られている)などの非同期通知に使用可能ないくつかのメカニズムのどれを用いるかを示します。サブプロトコルの選択に制限はなく、このサブプロトコル用語で他のメカニズムも告知できることに注意してください。 オプション string(例えば、longpollwebsub、またはsse)
security セキュリティ定義名の集合。securityDefinitionsで定義されているものから選定します。資源にアクセスするためには、これらすべてが満たされていなければなりません。 オプション stringまたはstring配列
scopes 配列として提供される承認範囲識別子の集合。これらは、クライアントがアクセスできる資源とその方法を識別するために、承認サーバーによって返されたトークンで提供され、フォームに関連付けられます。フォームに関連付けられる値は、そのフォームでアクティブなOAuth2SecuritySchemeで定義されているものから選択すべきです。 オプション stringまたはstring配列
response このオプションの用語は、例えば、出力の通信メタデータが入力のメタデータと異なる場合(例えば、出力コンテンツ・タイプが入力コンテンツ・タイプと異なる場合)に使用できます。応答の名前には、応答メッセージにのみ有効なメタデータが含まれます。 オプション ExpectedResponse

contentCodingプロパティーの可能な値は、例えば、IANA HTTPコンテンツ・コーディング・レジストリにあります。

フォームの可能な操作型のリストは固定されています。このバージョンの仕様の時点では、[WOT-ARCHITECTURE]で記述されているWoT対話モデルを実装するために必要な既知の型のみが含まれています。この標準の将来のバージョンでは、このリストは拡張される可能性がありますが、操作型は、サービエントが任意に設定すべきではありません(SHOULD NOT)。

オプションのresponseの名前-値のペアを用いて、予期される応答メッセージのメタデータを提供できます。コア語彙では、コンテンツ・タイプ情報のみが含まれていますが、TDコンテキスト拡張を適用できます。responseの名前-値のペアが提供されていない場合は、応答のコンテンツ・タイプがFormインスタンスに割り当てられているコンテンツ・タイプと等しいと想定しなければなりません(MUST)。ExpectedResponseクラス内のcontentTypeにはデフォルト値がないことに注意してください。例えば、フォームのコンテンツ・タイプの値がapplication/xmlの場合、想定される応答のコンテンツ・タイプの値もapplication/xmlになります。

ユースケースによっては、例えば、JSONを受け入れるけれども画像を返すアクションなど、入力と出力のデータが異なる形式で表される場合があります。そのようなケースでは、オプションのresponseの名前-値のペアで、予期される応答のコンテンツ・タイプを記述することができます。予期される応答のコンテンツ・タイプがフォームのコンテンツ・タイプと異なる場合には、Formインスタンスにresponseという名前を持つ名前-値のペアを含めなければなりません(MUST)。例えば、ActionAffordanceは、入力データではapplication/jsonのみを受け入れ、出力データではimage/jpegというコンテンツ・タイプで応答する可能性があります。その場合、コンテンツ・タイプが異なり、responseの名前-値のペアを用いて、応答コンテンツ・タイプ(image/jpeg)の情報を利用者に提供しなければなりません。

5.3.4.3 ExpectedResponse(予期される応答)

予期される応答メッセージを記述する通信メタデータ。

語彙用語 説明 割り当て
contentType メディア・タイプ(例えば、text/plain)と、そのメディア・タイプの潜在的なパラメータ(例えば、charset=utf-8)[RFC2046]に基づいてコンテンツ・タイプを割り当てます。 必須 string

5.4 デフォルト値の定義

TDの割り当てが欠落している場合、TDプロセッサは、§ 5.4 デフォルト値の定義の表で表されているデフォルト値の割り当てに従わなければなりません(MUST)。

次の表で、TD情報モデルで定義しているすべてのデフォルト値を示します。

クラス 語彙用語 デフォルト値 説明
Form contentType application/json
DataSchema readOnly false
DataSchema writeOnly false
ActionAffordance safe false
ActionAffordance idempotent false
Form op readpropertywritepropertyの要素を持つstring配列
PropertyAffordanceのインスタンス内で定義されている場合
Form op invokeaction ActionAffordanceのインスタンス内で定義されている場合
Form op subscribeevent EventAffordanceのインスタンス内で定義されている場合
BasicSecurityScheme in header
DigestSecurityScheme in header
BearerSecurityScheme in header
APIKeySecurityScheme in query
DigestSecurityScheme qop auth
BearerSecurityScheme alg ES256
BearerSecurityScheme format jwt

6. TD表現形式

WoTモノの記述はモノを表し、§ 5. TD情報モデルに基づいてモデル化され構造化されます。この項では、TD情報モデルで定義しているThingというクラスのインスタンスのシリアル化である、モノのJSONベースの表現形式を定義します。

TDプロセッサは、§ 6.1 JSONの型へのマッピング§ 6.3 情報モデルのシリアル化で記述している規則に従って、モノの記述のJSON形式[RFC8259]へのシリアル化および/またはその形式からのモノの記述の逆シリアル化ができなければなりません(MUST)。

TD情報モデルのJSONシリアル化は、セマンティックの評価を合理化するために、JSON-LD 1.1[json-ld11]の構文との整合化を図っています。したがって、TD表現形式は未加工のJSONとして処理するか、JSON-LD 1.1プロセッサで処理するかのいずれかが可能です(セマンティックな処理の詳細に関しては、§ D. JSON-LDコンテキストの使用法や、https://www.w3.org/2019/wot/tdなどの名前空間IRI下のドキュメントを参照してください)。

相互運用可能な国際化をサポートするには、オープン・エコシステムに関するRFC8259[RFC8259]の8.1項で定義されている要件に従ってTDをシリアル化しなければなりません(MUST)。要約すると、これには次が必要です。

6.1 の型へのマッピング

TD情報モデルは、モデルのオブジェクトとJSONの型の間に簡単なマッピングが存在するように構築されます。すべてのクラスのインスタンスはJSONオブジェクトにマッピングされ、クラスのインスタンスの個々の名前-値のペアは、JSONオブジェクトのメンバーです。

§ 5.3 クラス定義で言及しているすべての単純型(つまり、stringanyURIdateTimeintegerunsignedIntdouble、およびboolean)は、以下に列挙している規則に従って、プリミティブなJSONの型(文字列、数値、ブール値)にマッピングされます。これらの規則は、名前-値のペアの値に適用されます。

TD情報モデルのすべての複合型(つまり、配列マップ、およびクラスのインスタンス)は、以下に列挙している規則に従って、構造化されたJSONの型(配列およびオブジェクト)にマッピングされます。

6.2 デフォルト値の省略

モノの記述のシリアル化では、§ 5.4 デフォルト値の定義の表で列挙している、デフォルト値が定義されている語彙用語を省略できます。

次の例は、例1のTDのインスタンスに、デフォルト値でメンバーも含めるチェック・ボックスを付けたものです(チェック・ボックスにチェックあり)。これらのメンバーは、TDシリアル化を簡素化するために省略できます(チェック・ボックスにチェックなし)。TDプロセッサは、これらの省略されたメンバーを、特定のデフォルト値で明示的に存在しているのと完く同じように解釈することに注意してください。

用いられているプロトコル・バインディングに応じて、追加のプロトコル固有の語彙用語が適用されている場合があることに注意してください。デフォルト値が関連付けられている場合もあるため、この小項目で説明しているように省略することができます。詳細な情報は、§ 8.3 プロトコル・バインディングにあります。

6.3 情報モデルのシリアル化

6.3.1 モノのルート・オブジェクト

モノの記述は、Thing型のオブジェクトをルートとするデータ構造です。次に、モノの記述のJSONシリアル化はJSONオブジェクトであり、それは、TD情報モデルから構築された構文ツリーのルートです。

TDシリアル化のルート要素は、@contextという名前を持つメンバーと、https://www.w3.org/2019/wot/td/v1と等しいか、それぞれに含む文字列型または配列型の値を持つメンバーを含むJSONオブジェクトでなければなりません(MUST)。

一般的に、このURIは、この仕様で定義しているTD表現形式のバージョンを識別するために用います。JSON-LD処理[json-ld11]の場合、このURIはモノの記述のコンテキスト・ファイルを指定します。配列型の@contextは、TDコンテキスト拡張を示します(詳細に関しては、§ 7. TDコンテキスト拡張を参照してください)。

{  
    "@context": "https://www.w3.org/2019/wot/td/v1",
    ...
}

Thingのインスタンスの名前-値のペアはすべて、名前がThingシグネチャ内の語彙用語である場合、ルート・オブジェクトのJSONメンバーとしてシリアル化しなければなりません(MUST)。

すべての必須およびオプションのメンバーを含むシリアル化されたルート・オブジェクトのTDの断片を以下に示します。

5: モノのシリアル化のサンプル
{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "@type": "Thing",
    "id": "urn:dev:ops:32473-Thing-1234",
    "title": "MyThing",
    "titles": {...},
    "description": "Human readable information.",
    "descriptions": {...},
    "support": "mailto:support@example.com",
    "version" : {...},
    "created" : "2018-11-14T19:10:23.824Z",
    "modified" : "2019-06-01T09:12:43.124Z",
    "securityDefinitions": {...},
    "security": ...,
    "base": "https://servient.example.com/",
    "properties": {...},
    "actions": {...},
    "events": {...},
    "links": [...],
    "forms": [...]
}

Thingというクラスのインスタンス内のversionsecurityDefinitionspropertiesactions、およびeventsに割り当てられているすべての値は、JSONオブジェクトとしてシリアル化しなければなりません(MUST)。

linksに割り当てられているすべての値、およびThingというクラスのインスタンス内のformsは、それぞれ§ 6.3.8 links(リンク)§ 6.3.9 forms(フォーム)で定義しているJSONオブジェクトを含むJSON配列としてシリアル化しなければなりません(MUST)。

Thingというクラスのインスタンス内のsecurityに割り当てられている値は、JSON文字列またはJSON文字列を要素とするJSON配列としてシリアル化しなければなりません(MUST)。

6.3.2 人間が読めるメタデータ

titleおよびdescriptionという名前のJSONメンバーは、人間が読めるメタデータを提供するためにTDドキュメント内で用います。これらは、TDドキュメントの検査を行う開発者用のコメントとして、またはユーザ・インターフェース用の表示テキストとして使用できます。

§ 5.3.1.1 Thing(モノ)で定義しているように、人間が読めるメタデータを表示するために用いられるテキストの基本書字方向は、最初の強い文字(first-strong)の規則などのヒューリスティクスを用いて推定するか、言語情報から推測することができます。TDドキュメントでは、デフォルトの言語は@context内の@languageに割り当てられている値によって定義され、これは、必要に応じてスクリプト・サブタグとともに、テキストの基本書字方向を決定するために使用できます。しかし、人間が読めるテキストを解釈するときは、人間が読める各文字列値を個別に処理しなければなりません(MUST)。言い換えれば、TDプロセッサは、ある文字列から別の文字列へと方向の変更を繰り越したり、ある文字の方向をTD内の他の場所から推測したりすることはできません。

ウェブ上の文字列[STRING-META]は、テキストの基本書字方向を決定する手段として、最初の強い文字(strong-first)と言語ベースの両方の推論を提案しています。モノの記述の形式がJSON-LD 1.1[json-ld11]に基づいていて、現在のところ明示的な方向のメタデータが欠落していることを考えると、これらのアプローチはこの公開時点では適切であると考えられます。しかし、JSON-LD 1.1が[STRING-META]で推奨されている明示的な基本書字方向のメタデータのサポートを採用した場合、その機能を利用するためにモノの記述の形式を更新すべきです。

titleおよびdescriptionを用いたTDの断片を以下に示します。デフォルト言語は、@context配列のJSONオブジェクト内の@languageメンバーの定義によりenに設定されます。

{
    "@context": [
        "https://www.w3.org/2019/wot/td/v1",
        { "@language" : "en" }
    ],
    "title": "MyThing",
    "description": "Human readable information.",
    ...
    "properties": {
        "on": {
            "title" : "On/Off",
            "type": "boolean",
            "forms": [...]
        },
        "status": {
            "title" : "Status",
            "type": "object",
            ...
            "forms": [...]
        }
    },
    ...
}

titlesおよびdescriptionsという名前のJSONメンバーは、1つのTDドキュメント内で複数の言語で人間が読めるメタデータを提供するためにTDドキュメント内で用います。MultiLanguageマップのすべての名前-値のペアは、JSONオブジェクトのメンバーとしてシリアル化しなければならず(MUST)、その名前は[BCP47]で定義されている整形式の言語タグであり、値はタグで示されている言語の人間が読める文字列です。詳細に関しては、§ 5.3.1.7 MultiLanguage(多言語)を参照してください。TDドキュメント内のすべてのMultiLanguageオブジェクトには、同じ言語メンバーの集合が含まれているべきです(SHOULD)。

様々なレベルでtitlesdescriptionsを用いたTDの断片を以下に示します。

{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "title": "MyThing",
    "titles": {
        "en":"MyThing",
        "de": "MeinDing",
        "ja" : "私の物",
        "zh-Hans" : "我的东西", 
        "zh-Hant" : "我的東西"
    },
    "descriptions": {
        "en":"Human readable information.",
        "de": "Menschenlesbare Informationen.",
        "ja" : "人間が読むことができる情報",
        "zh-Hans" : "人们可阅读的信息", 
        "zh-Hant" : "人們可閱讀的資訊"
    },
    ...
    "properties": {
        "on": {
            "titles": {
                "en": "On/Off",
                "de": "An/Aus",
                "ja": "オンオフ",
                "zh-Hans": "开关",
                "zh-Hant": "開關" },
            "type": "boolean",
            "forms": [...]
        },
        "status": {
            "titles": {
                "en": "Status",
                "de": "Zustand",
                "ja": "状態",
                "zh-Hans": "状态",
                "zh-Hant": "狀態" },
            "type": "object",
            ...
            "forms": [...]
        }
    },
    ...
}

TDのインスタンスは、titledescriptionの使用をtitlesdescriptionsと組み合わせることもできます。titleおよびtitlesまたはdescriptionおよびdescriptionsが同じJSONオブジェクト内に存在している場合、titledescriptionの値はデフォルトのテキストとして表示されるかもしれません(MAY)。titleおよびtitlesまたはdescriptionおよびdescriptionsがTDドキュメント内に存在する場合、個々のtitledescriptionのメンバーは、それぞれ対応するtitlesdescriptionsのメンバーを持っているべきです(SHOULD)。デフォルトのテキストの言語は、デフォルトの言語で示されます。これは通常、モノの記述のインスタンスの作成者が設定します。

{
    "@context": [
        "https://www.w3.org/2019/wot/td/v1",
        { "@language" : "de" }
    ],
    "title": "MyThing",
    "titles": {
        "en":"MyThing",
        "de": "MeinDing",
        "ja" : "私の物",
        "zh-Hans" : "我的东西", 
        "zh-Hant" : "我的東西"
    },
    "description": "Menschenlesbare Informationen.",
    "descriptions": {
        "en":"Human readable information.",
        "de": "Menschenlesbare Informationen.",
        "ja" : "人間が読むことができる情報",
        "zh-Hans" : "人们可阅读的信息", 
        "zh-Hant" : "人們可閱讀的資訊"
    },
    ...
    "properties": {
        "on": {
            "title" : "An/Aus",
            "titles": {
                "en": "On/Off",
                "de": "An/Aus",
                "ja": "オンオフ",
                "zh-Hans": "开关",
                "zh-Hant": "開關" },
            "type": "boolean",
            "forms": [...]
        },
        "status": {
            "title" : "Zustand",
            "titles": {
                "en": "Status",
                "de": "Zustand",
                "ja": "状態",
                "zh-Hans": "状态",
                "zh-Hant": "狀態" },
            "type": "object",
            ...
            "forms": [...]
        }
    },
    ...
}

デフォルト言語を設定する別の可能性は、HTTPのAccept-Languageヘッダー・フィールドなどの言語交渉メカニズムを用いることです。デフォルト言語の交渉が行われた場合、交渉の結果と、返されるコンテンツの対応するデフォルト言語を示す@languageメンバーが存在しなければなりません(MUST)。デフォルト言語の交渉が正常に行われた場合は、TDドキュメントはtitlesdescriptionsのメンバーのMultiLanguageオブジェクトよりも優先して、メンバーであるtitledescriptionに適切な一致する値を含めるべきです(SHOULD)。しかし、モノは、そのような動的に生成されるTDのサポートも、言語交渉のサポートも行わないことを選択できる(MAY)(例えば、資源の制約のために)ことに注意してください。

6.3.3 version(バージョン)

名前が、VersionInfoシグネチャに含まれている語彙用語であるVersionInfoのインスタンスのすべての名前-値のペアは、語彙用語を名前として持つJSONメンバーとしてシリアル化しなければなりません(MUST)。

バージョン情報オブジェクトのTDの断片を以下に示します。

{
    ...
    "version": { "instance": "1.2.1" },
    ...
}

versionのメンバーは、TDコンテキスト拡張に基づく追加のアプリケーション固有および/またはデバイス固有のバージョン情報用のコンテナとして意図されています。詳細に関しては、§ 7.1 セマンティックなアノテーションを参照してください。

6.3.4 securityDefinitions(セキュリティ定義)とsecurity(セキュリティ)

Thingのインスタンスでは、securityDefinitionsに割り当てられている値は、SecuritySchemeのインスタンスのマップです。SecuritySchemeインスタンスのマップのすべての名前-値のペアは、マップのシリアル化から生じるJSONオブジェクトのメンバーとしてシリアル化しなければなりません(MUST)。ペアの名前はJSON文字列としてシリアル化しなければならず(MUST)、ペアの値(SecuritySchemeのインスタンス)は、JSONオブジェクトとしてシリアル化しなければなりません(MUST)。

SecuritySchemeサブクラスのうちの1つのインスタンスのすべての名前-値のペアは、名前がそのサブクラスシグネチャまたはSecuritySchemeシグネチャに含まれている語彙用語である場合、語彙用語を名前として用いて、SecuritySchemeサブクラスのインスタンスのシリアル化から生じるJSONオブジェクトのメンバーとしてシリアル化しなければなりません(MUST)。

次のTDの断片は、ヘッダーで基本的なユーザ名/パスワード認証を指定するシンプルなセキュリティ設定を示しています。inに指定される値は、実際にはデフォルト値(header)であり、省略できます。名前付きセキュリティ設定はsecurityDefinitionsマップで指定しなければなりません。その定義は、securityメンバーのそのJSON名によってアクティブ化しなければならず、それは、1つの定義のみがアクティブ化される場合には文字列型でありえます。

...
"securityDefinitions": {
    "basic_sc": {
        "scheme": "basic",
        "in": "header"
    }
},
"security": "basic_sc",
...

ここで、より複雑な例として、モノにおけるベアラー・トークン認証と組み合わせたプロキシにおけるダイジェスト認証を示すTDの断片を示します。digestスキームでは、inデフォルト値(つまり、header)は省略されますが、適用はされます。正常な対話を行うためには、利用者内で、ユーザ名/パスワードやトークンなどの対応する非公開のセキュリティ設定を設定しなければならないことに注意してください。複数のセキュリティ定義をアクティブ化すると、securityメンバーは配列になります。

...
"securityDefinitions": {
    "proxy_sc": {
        "scheme": "digest",
        "proxy": "https://portal.example.com/"
    },
    "bearer_sc": {
        "in":"header",
        "scheme": "bearer",
        "format": "jwt",
        "alg": "ES256",
        "authorization": "https://servient.example.com:8443/"
    }
},
"security": ["proxy_sc", "bearer_sc"],
...

TDのセキュリティ設定は必須です。モノのレベル(つまり、TDルート・オブジェクト)のsecurity配列を介して少なくとも1つのセキュリティ定義をアクティブ化しなければなりません(MUST)。この設定は、モノとの対話に必要なデフォルトのセキュリティ・メカニズムと見ることができます。セキュリティ定義は、フォーム・オブジェクトにsecurityメンバーを含めることにより、フォームのレベルでアクティブ化することもでき(MAY)、これは、モノのレベルでアクティブ化されるすべての定義を上書き(つまり、完全に置き換え)します。

セキュリティが必要ない場合、nosecセキュリティ・スキームが提供されます。モノの最小限のセキュリティ設定は、次の例に示すように、モノのレベルでのnosecセキュリティ・スキームのアクティブ化です。

{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "id": "urn:dev:ops:32473-Thing-1234",
    "title": "MyThing",
    "description": "Human readable information.",
    "support": "https://servient.example.com/contact",
    "securityDefinitions": { "nosec_sc": { "scheme": "nosec" }},
    "security": "nosec_sc",
    "properties": {...},
    "actions": {...},
    "events": {...},
    "links": [...]
}

より複雑な例を示すために、認証が不要なものを除き、すべての対話アフォーダンスで基本認証を必要なモノがあると仮定します。statusプロパティーとtoggleアクションの場合、basic認証が必要であり、モノのレベルで定義されます。しかし、overheatingイベントの場合は、認証は必要ないため、セキュリティ設定はフォームのレベルで上書きされます。

{
    ...
    "securityDefinitions": {
        "basic_sc": {"scheme": "basic"},
        "nosec_sc": {"scheme": "nosec"}
    },
    "security": ["basic_sc"],
    ...
    "properties": {
        "status": {
            ...
            "forms": [{
                "href": "https://mylamp.example.com/status"
            }]
        }
    },
    "actions": {
        "toggle": {
            ...
            "forms": [{
                "href": "https://mylamp.example.com/toggle"
            }]
        }
    },
    "events": {
        "overheating": {
            ...
            "forms": [{
                "href": "https://mylamp.example.com/oh",
                "security": ["nosec_sc"]
            }]
        }
    }
}

セキュリティ設定は、同じ対話アフォーダンス内の様々なフォーム用に指定することもできます。これは、様々なセキュリティ・メカニズムをサポートする、HTTPやCoAP[RFC7252]などの、複数のプロトコルをサポートするデバイスに必要でありえます。これは、代替認証メカニズムが許されている場合にも役立ちます。ここでは、基本認証を用いたHTTPS経由、ダイジェスト認証、ベアラー・トークン認証という、プロパティー・アフォーダンスをアクティブ化する3つの可能な方法を示すTDの断片を示します。言い換えると、複数のフォーム内で様々なセキュリティ設定を用いると、セキュリティ・メカニズムを「OR」方式で組み合わせることができます。対照的に、同じsecurityメンバーに複数のセキュリティ設定を配置すると、それらは「AND」方式で結合されます。これは、その場合には、対話アフォーダンスのアクティブ化を可能にするために、それらすべてを満たす必要があるためです。モノのレベルで1つの(デフォルトの)構成をアクティブ化することは依然として必須であることに注意してください。

{
    ...
    "securityDefinitions": {
        "basic_sc": { "scheme": "basic" },
        "digest_sc": { "scheme": "digest" },
        "bearer_sc": { "scheme": "bearer" }
    },
    "security": ["basic_sc"],
    ...
    "properties": {
        "status": {
            ...
            "forms": [{
                "href": "https://mylamp.example.com/status"
            }, {
                "href": "https://mylamp.example.com/status",
                "security": ["digest_sc"]
            }, {
                "href": "https://mylamp.example.com/status",
                "security": ["bearer_sc"]
            }]
        }
    },
    ...
}

別のより複雑な例として、OAuth2は範囲を用います。これはトークンに現れる識別子であり、その資源(または、W3C WoTの場合は対話アフォーダンス)へのアクセスを可能にするために、資源内の対応する識別子と一致しなければなりません。例えば、下記では、limitedという範囲を含むベアラー・トークンを用いて利用者statusプロパティーを読むことができますが、configureアクションは、specialの範囲を含むトークンでのみ呼び出すことができます。範囲は役割と同一ではありませんが、多くの場合それに関連付けられています。例えば、おそらく管理的な役割を持つもののみが「特別な」対話を実行する承認を与えられます。トークンは複数のスコープを持つことができます。この例では、管理者にはおそらくlimitedspecialの両方の範囲を持つトークンが発行されますが、通常のユーザにはlimitedの範囲のトークンのみが発行されます。

{
    ...
    "securityDefinitions": {
        "oauth2_sc": {
            "scheme": "oauth2",
            ...
            "flow": "code",
            "authorization": "https://example.com/authorization",
            "token": "https://example.com/token",
            "scopes": ["limited", "special"]
        }
    },
    "security": ["oauth2_sc"],
    ...
    "properties": {
        "status": {
            ...
            "forms": [{
                "href": "https://scopes.example.com/status",
                "scopes": ["limited"]
            }]
        }
    },
    "actions": {
        "configure": {
            ...
            "forms": [{
                "href": "https://scopes.example.com/configure",
                "scopes": ["special"]
            }]
        }
    },
    ...
}

6.3.5 properties(プロパティー)

Thingのインスタンスのpropertiesに割り当てられる値は、PropertyAffordanceのインスタンスのマップです。PropertyAffordanceインスタンスのマップのすべての名前-値のペアは、マップのシリアル化から生じるJSONオブジェクトのメンバーとしてシリアル化しなければなりません(MUST)。ペアの名前はJSON文字列としてシリアル化しなければならず(MUST)、ペアの値(PropertyAffordanceのインスタンス)はJSONオブジェクトとしてシリアル化しなければなりません(MUST)。

PropertyAffordanceのインスタンスのすべての名前-値のペアは、名前がPropertyAffordanceInteractionAffordance、またはDataSchemaシグネチャ(の1つ)に含まれている語彙用語である場合、語彙用語を名前として用いて、PropertyAffordanceインスタンスのシリアル化から生じるJSONオブジェクトのメンバーとしてシリアル化しなければなりません(MUST)。DataSchemaインスタンスのシリアル化の詳細に関しては、§ 6.3.10 データ・スキーマを参照してください。

PropertyAffordanceのインスタンスのformsに割り当てられている値は、§ 6.3.9 forms(フォーム)で定義している1つ以上のJSONオブジェクトのシリアル化を含むJSON配列としてシリアル化しなければなりません(MUST)。

2つのプロパティー・アフォーダンスの断片を以下に示します。

6.3.6 actions(アクション)

Thingのインスタンスでは、actionsに割り当てられる値はActionAffordanceのインスタンスのマップです。ActionAffordanceインスタンスのマップのすべての名前-値のペアは、マップのシリアル化から生じるJSONオブジェクトのメンバーとしてシリアル化しなければなりません(MUST)。ペアの名前はJSON文字列としてシリアル化しなければならず(MUST)、ペアの値(ActionAffordanceのインスタンス)はJSONオブジェクトとしてシリアル化しなければなりません(MUST)。

ActionAffordanceのインスタンスのすべての名前-値のペアは、名前がActionAffordanceまたはInteractionAffordanceシグネチャ(の1つ)に含まれている語彙用語である場合、語彙用語を名前として用いて、ActionAffordanceインスタンスのシリアル化から生じるJSONオブジェクトのメンバーとしてシリアル化しなければなりません(MUST)。

ActionAffordanceのインスタンス内でinputおよびoutputに割り当てられている値は、JSONオブジェクトとしてシリアル化しなければなりません(MUST)。それらは、クラスDataSchemaに依拠しており、そのシリアル化は§ 6.3.10 データ・スキーマで定義しています。

ActionAffordanceのインスタンス内のformsに割り当てられている値は、§ 6.3.9 forms(フォーム)で定義している1つ以上のJSONオブジェクトのシリアル化を含むJSON配列としてシリアル化しなければなりません(MUST)。

アクション・アフォーダンスのTDの断片を以下に示します。

6.3.7 events(イベント)

Thingのインスタンスでは、eventsに割り当てられる値は、EventAffordanceのインスタンスのマップです。EventAffordanceインスタンスのマップのすべての名前-値のペアは、マップのシリアル化から生じるJSONオブジェクトのメンバーとしてシリアル化しなければなりません(MUST)。ペアの名前はJSON文字列としてシリアル化しなければならず(MUST)、ペアの値(EventAffordanceのインスタンス)はJSONオブジェクトとしてシリアル化しなければなりません(MUST)。

EventAffordanceのインスタンスのすべての名前-値のペアは、名前がEventAffordanceまたはInteractionAffordanceシグネチャ(の1つ)に含まれている語彙用語である場合、語彙用語を名前として用いて、EventAffordanceインスタンスのシリアル化から生じるJSONオブジェクトのメンバーとしてシリアル化しなければなりません(MUST)。

EventAffordanceのインスタンス内でsubscriptiondata、そしてcancellationに割り当てられている値は、JSONオブジェクトとしてシリアル化しなければなりません(MUST)。それらは、クラスDataSchemaに依拠しており、そのシリアル化は§ 6.3.10 データ・スキーマで定義しています。

EventAffordanceのインスタンス内のformsに割り当てられている値は、§ 6.3.9 forms(フォーム)で定義している1つ以上のJSONオブジェクトのシリアル化を含むJSON配列としてシリアル化しなければなりません(MUST)。

イベント・オブジェクトのTDの断片を以下に示します。

既存の(例えば、WebSub[websub])または顧客指向のイベント・メカニズム(例えば、Webhooks)を採用するために、イベント・アフォーダンスは柔軟な方法で定義されています。このため、subscriptioncancellationは、望ましいメカニズムに従って定義できます。詳細に関しては、[WOT-BINDING-TEMPLATES]をご覧ください。§ A.3 Webhookイベントの例の例は、イベントがsubscriptioncancellationを用いてWebhookを記述する方法を示しています。

6.3.9 forms(フォーム)

Formのインスタンスのすべての名前-値のペアは、名前がFormシグネチャに含まれている語彙用語である場合、語彙用語を名前として用いて、Formインスタンスのシリアル化から生じるJSONオブジェクトのメンバーとしてシリアル化しなければなりません(MUST)。

必要に応じて、フォーム・オブジェクトは、接頭辞で識別されるプロトコル固有の語彙用語で補完できます(MAY)。§ 8.3 プロトコル・バインディングも参照してください。

forms配列内のフォーム・オブジェクトのTDの断片を以下に示します。

hrefには、http://192.168.1.25/left?p=2&d=1のpやdなどの動的変数を含むURIを含めることもできます。その場合、URIは[RFC6570]で定義されているテンプレート(http://192.168.1.25/left{?p,d})として定義できます。

このようなケースでは、URIテンプレート変数は、関連する(一意な)変数名をJSON名として持つJSONオブジェクト・ベースのuriVariablesメンバーで収集されなければなりません(MUST)。

Formのインスタンス内のuriVariablesに割り当てられているマップの各値のシリアル化は、クラスDataSchemaに依拠しなければならず(MUST)、そのシリアル化は§ 6.3.10 データ・スキーマで定義しています。

URIテンプレートとuriVariablesを用いたTDの断片を以下に示します。

{
    "@context": [
        "https://www.w3.org/2019/wot/td/v1",
        { "eg": "http://www.example.org/iot#" }
    ],
    ...
    "actions": {
        "LeftDown": {
            ...
            "uriVariables": {
                "p" : { "type": "integer", "minimum": 0, "maximum": 16, "@type": "eg:SomeKindOfAngle" },
                "d" : { "type": "integer", "minimum": 0, "maximum": 1, "@type": "eg:Direction" }
            },
            "forms": [{
              "href" : "http://192.168.1.25/left{?p,d}",
              "htv:methodName": "GET"
            }]
        },
        ...
    },
    ...
}

contentTypeメンバーは、;という文字で区切られた属性-値のペアとしてメディア・タイプ・パラメータを含む、メディア・タイプ[RFC2046]を割り当てるために用います。例は次のとおり。

...
"contentType" : "text/plain; charset=utf-8",
...

ユースケースによっては、対話アフォーダンスのフォーム・メタデータはリクエストを記述するだけでなく、予期される応答に関するメタデータも提供します。例えば、アクションtakePhotoは、リクエスト・ペイロードにJSONを用いて(つまり、"contentType": "application/json")、カメラのパラメータ設定(絞り優先、タイマーなど)を送信するinputスキーマを定義します。このアクションの出力は、撮影された写真であり、例えば、JPEG形式で利用可能です。このような場合、応答ペイロードの表現形式を示すためにresponseメンバーが用いられます(例えば、"contentType": "image/jpeg")。ここでは、コンテンツ・タイプで表現形式が完全に指定されるため、outputスキーマは必要ありません。

Formのインスタンス内のresponseに割り当てられている値は、存在している場合、JSONオブジェクトでなければなりません(MUST)。応答オブジェクトには、存在している場合、ExpectedResponseクラス定義で定義されているcontentTypeメンバーが含まれていなければなりません(MUST)。

上記のtakePhotoアクションに基づいて、responseメンバーを持つformの断片を以下に示します。

{
    ...
    "actions": {
        "takePhoto": {
            ...
            "forms": [{
                "op": "invokeaction",
                "href": "http://camera.example.com/api/snapshot",
                "contentType": "application/json",
                "response": {
                    "contentType": "image/jpeg"
                }
            }]
        }
    },
    ...
}

formsが最上レベルに存在している場合は、モノが提供するメタ対話を記述するために使用できます。例えば、「readallproperties」および「writeallproperties」という操作型は、利用者がすべてのプロパティーを一度に読み書きできるモノとのメタ対話のためのものです。下記の例では、formsメンバーがTDのルート・オブジェクトに含まれており、利用者は、送信ターゲットhttps://mylamp.example.com/allpropertiesを用いて、1回のプロトコル・トランザクションでモノのすべてのプロパティー(つまり、onbrightnesstimer)の読み書きの両方を行うことができます。

{
    ...
    "properties": {
        "on": {
            "type": "boolean",
            "forms": [...]
        },
        "brightness": {
            "type": "number",
            "forms": [...]
        },
        "timer": {
            "type": "integer",
            "forms": [...]
        }
    },
    ...
    "forms": [{
        "op": "readallproperties",
        "href": "https://mylamp.example.com/allproperties",
        "contentType": "application/json",
        "htv:methodName": "GET"
    }, {
        "op": "writeallproperties",
        "href": "https://mylamp.example.com/allproperties",
        "contentType": "application/json",
        "htv:methodName": "PUT"
    }]
}
操作型writeallpropertiesの場合、利用者がすべての書き込み可能な(readOnlyでない)プロパティーと(新しい)割り当てられた値(例えば、ペイロード内)を提供することが予期されます。同様に、writemultipleproperties操作型では、利用者が書き込み可能な(readOnlyではない)プロパティーを提供することが予期されます。モノ側では、readmultiplepropertiesおよびreadallpropertiesの操作型の場合に、モノは読み取り可能な(writeOnlyではない)プロパティーを返すことが予期されます。

6.3.10 データ・スキーマ

DataSchemaクラスを通じて定義されるWoT モノの記述のデータ・スキーマは、JSONスキーマ用語[JSON-SCHEMA]のサブセットに基づいています。したがって、TDデータ・スキーマのシリアル化をJSONスキーマ検証ソフトの実装に直接フィードして、モノと交換されるデータを検証できます。

データ・スキーマのシリアル化は、PropertyAffordanceインスタンス、ActionAffordanceインスタンス内のinputおよびoutputに割り当てられている値、EventAffordanceインスタンス内のsubscriptiondatacancellationに割り当てられている値、InteractionAffordanceサブクラスのインスタンス内のuriVariablesに割り当てられている値(フォーム・オブジェクトがURIテンプレートを用いる場合)に適用されます。

DataSchemaサブクラスのうちの1つのインスタンスのすべての名前-値のペアは、名前がそのサブクラスシグネチャまたはDataSchemaシグネチャに含まれている語彙用語である場合、語彙用語を名前として用いて、DataSchemaサブクラスのインスタンスのシリアル化から生じるJSONオブジェクトのメンバーとしてシリアル化しなければなりません(MUST)。

ObjectSchemaのインスタンス内のpropertiesに割り当てられている値は、JSONオブジェクトとしてシリアル化しなければなりません(MUST)。

DataSchemaのインスタンス内のenumrequiredoneOfに割り当てられている値は、JSON配列としてシリアル化しなければなりません(MUST)。

ArraySchemaのインスタンス内のitemsに割り当てられている値は、JSONオブジェクトまたはJSONオブジェクトを含んだJSON配列としてシリアル化しなければなりません(MUST)。

TDの断片のデータ・スキーマ・メンバーを以下に示します。周囲のオブジェクトは、データ・スキーマ・オブジェクト(例えば、inputおよびoutput用)またはプロパティー・オブジェクトであり、追加のメンバーが含まれていることに注意してください。

readOnlyおよびwriteOnlyという用語は、読み取り対話(つまり、プロパティーの読み取り時)で交換されるデータ項目と、書き込み対話(つまり、プロパティーの書き込み時)で交換されるデータ項目を示すために使用できます。これは、規定的ではないモノのプロパティーが読み取りと書き込みで異なるデータを示す場合の回避策として使用でき、それは、モノの記述で既存のデバイスまたはサービスを拡張する場合に当てはまります。

readOnlywriteOnlyを用いたTDの断片を以下に示します。

...
"properties": {
    "status": {
        "description": "Read or write On/Off status.",
        "type": "object",
        "properties": {
            "latestStatus": {
                "type": "string",
                "enum": ["On", "Off"],
                "readOnly": true
            },
            "newStatusValue": {
                "type": "string",
                "enum": ["On", "Off"],
                "writeOnly": true
            }
        },
        forms: [...]
    }
}
...

statusプロパティーが読み取られると、ペイロードのlatestStatusメンバーを用いて状態のデータが返されます。statusプロパティーを更新するには、ペイロードのnewStatusValueメンバーを通じて新しい値を提供しなければなりません。

追加機能として、モノの記述インスタンスにより、データ・スキーマ内でunitメンバーを使用できるようになります。これを使用して、測定単位をデータ項目に関連付けることができます。その文字列の値は自由に選択できます。しかし、よく知られている語彙で定義されている単位を選択することをお勧めします。例に関しては、§ 7. TDコンテキスト拡張を参照してください。

6.4 識別

モノの記述のJSONベースのシリアル化は、application/td+jsonというメディア・タイプまたは432というCoAPコンテンツ形式IDによって識別されます(§ 10. IANAに関する留意点を参照)。

7. TDコンテキスト拡張

この項は非規範的です。

§ 5. TD情報モデルの標準的な語彙の定義に加えて、WoTモノの記述は追加の名前空間からコンテキストの知識を追加する可能性を提供します。このメカニズムを用いて、追加の(例えば、ドメイン固有の)セマンティクスでモノの記述のインスタンスを充実させることができます。また、将来的に追加のプロトコル・バインディングや新しいセキュリティ・スキームをインポートするためにも使用できます。

そのようなTDコンテキスト拡張の場合、モノの記述はJSON-LD[json-ld11]で知られている@contextメカニズムを用います。TDコンテキスト拡張を用いる場合、Thingというクラス@contextの値は、JSON-LDコンテキスト・ファイルを識別するanyURI型の追加要素を持つ配列か、§ 5.3.1.1 Thing(モノ)で定義している名前空間IRIを含んでいるマップです。

§ 6.1 JSONの型へのマッピングの複合型のシリアル化規則は、拡張された@context名前-値のペアのシリアル化を定義します。TDコンテキスト拡張の断片を以下に示します。

{
    "@context": [
        "https://www.w3.org/2019/wot/td/v1",
        {
            "eg": "http://example.org/iot#",
            "cov": "http://www.example.org/coap-binding#"
        },
        "https://schema.org/"
    ],
    ...
}

7.1 セマンティックなアノテーション

TDコンテキスト拡張により、モノの記述インスタンスに語彙用語を追加できます。含まれている名前空間が、RDFスキーマやOWLによって提供されるものなどのクラス定義に基づいている場合、インスタンスをそのような外部のクラス定義に関連付けることにより、モノの記述の任意のクラスのインスタンスにセマンティックにアノテーションを付与するためにそれを使用できます。これは、@typeの名前-値のペアにクラス名を割り当てるか、複数の関連付け/アノテーションの配列の値にクラス名を含めることによって行われます。§ 6.1 JSONの型へのマッピングのシリアル化規則に従って、@typeはJSON文字列かJSON配列としてシリアル化されます。 @typeは、ノードの型を設定するために用いられるJSON-LDキーワード[json-ld11]です。

TDコンテキスト拡張により、モノの記述のクラスのインスタンス内に追加の名前-値のペアと明確に定義された値を含めることもできます。このペアと値は、含まれている語彙用語を通じて定義され、それぞれ対応するJSONオブジェクトの追加メンバーまたは既存のメンバーの値としてシリアル化されます。例は、モノの追加バージョンのメタデータまたはデータ・アイテムの測定単位です。

例として、以下に示すTDの断片は、モノのハードウェアとファームウェアのバージョン番号を追加することでバージョン情報のコンテナを拡張し、モノとデータ・スキーマの単位に外部語彙の値を用いています。SAREF2でも用いており、OMは測定単位のオントロジー[RIJGERSBERG]です。これらの語彙は例として用いています。 — 特にホーム・オートメーションの領域には他の語彙が存在している場合があります。

{
    "@context": [
        "https://www.w3.org/2019/wot/td/v1",
        {
            "v": "http://www.example.org/versioningTerms#",
            "saref": "https://w3id.org/saref#",
            "om": "http://www.ontology-of-units-of-measure.org/resource/om-2/"
        }
    ],
    "version": {
        "instance": "1.2.1",
        "v:firmware": "0.9.1",
        "v:hardware": "1.0"
    },
    ...
    "@type": "saref:TemperatureSensor",
    "properties": {
        "temperature": {
            "description": "Temperature value of the weather station",
            "type": "number",
            "minimum": -32.5,
            "maximum": 55.2,
            "unit": "om:degree_Celsius",
            "forms": [...]
        },
        ...
    },
    ...
}

多くの場合、TDコンテキスト拡張を用いて、データ・スキーマの一部にアノテーションを付与し、物理世界のオブジェクトの状態情報をセマンティックに処理できます。これは、対話中に交換されるデータによって表されます(例えば、応答のペイロードで)。例えば、RDFのこの状態情報のセマンティックな記述は、TDドキュメントに埋め込むことができ、データ・スキーマの部分は、物理世界のオブジェクトのRDFでモデル化された状態の特定の部分を参照するように個々にアノテーションを付与することができます。

以下のTDの断片では、SAREFを用いて照明の状態を記述しています。SSN(セマンティック・センサー・ネットワーク・オントロジー[VOCAB-SSN])から取得した外部の語彙用語であるssn:forPropertyは、statusプロパティーのデータ・スキーマを物理世界のオブジェクトの実際のオン/オフ状態にリンクするために用いられています。

{
    "@context": [
        "https://www.w3.org/2019/wot/td/v1",
        {
            "saref": "https://w3id.org/saref#",
            "ssn": "http://www.w3.org/ns/ssn/"
        }
    ],
    "id": "urn:dev:ops:32473-WoTLamp-1234",
    "@type": "saref:LightSwitch",
    "saref:hasState": {
        "@id": "urn:dev:ops:32473-WoTLamp-1234/state",
        "@type": "saref:OnOffState"
    },
    ...
    "properties": {
        "status": {
            "ssn:forProperty": "urn:dev:ops:32473-WoTLamp-1234/state",
            "type": "string",
            "forms": [{"href": "https://mylamp.example.com/status"}]
        },
        "fullStatus": {
            "ssn:forProperty": "urn:dev:ops:32473-WoTLamp-1234/state",
            "type": "object",
            "properties": {
                "statusString": { "type": "string" },
                "statusCode": { "type": "number" },
                "statusDescription": { "type": "string" }
            },
            "forms": [{"href": "https://mylamp.example.com/status?full=true"}]
        },
        ...
    },
    ...
}

2では、モノの状態は、statusアフォーダンス自体によって示され、可能な状態の変化はtoggleアフォーダンスによって示されています。言い換えれば、物理世界のオブジェクトの状態は、モノ対話アフォーダンスを直接提供します。この設計は、シンプルな場合には満足のいくものです。しかし、より複雑なケースでは、同じ物理的な状態に対していくつかのアフォーダンスが利用できる場合があります。上記の例では、fullStatusプロパティーで、照明の状態のより詳細な別の表現を提供しています。

7.2 プロトコル・バインディングの追加

モノの記述でTDコンテキスト拡張を用いると、通信メタデータを補完したり、Formインスタンスを表すJSONオブジェクトにシリアル化された追加の語彙用語を通じて新しいプロトコル・バインディングを追加することができます。(§ 8.3 プロトコル・バインディングも参照)。

この仕様の執筆時点では、そのようなプロトコル・バインディングは利用できないため、次のTDの例では、架空のCoAPのプロトコル・バインディングを用いています。このTDコンテキスト拡張は、例の名前空間http://www.example.org/coap-binding#からアクセスできるRDF 1.0のHTTP語彙[HTTP-in-RDF10]に似たRDF語彙のCoAPがあると仮定しています。補足されたcov:methodNameメンバーは、どのCoAPメソッドを適用しなければならないかを利用者に指示します(例えば、CoAPメソッド・コード0.01にはGET、CoAPメソッド・コード0.02にはPOST、またはCoAPメソッド・コード0.07にはiPATCH)。

7.3 セキュリティ・スキームの追加

最後に、§ 5.3.3 セキュリティ語彙の定義に含まれていない新しいセキュリティ・スキームは、TDコンテキスト拡張のメカニズムを用いてインポートできます。この例では、[ACE]に基づく架空のACEセキュリティ・スキームを用いており、それは、この例では、http://www.example.org/ace-security#の名前空間で定義されています。このような追加のセキュリティ・スキームは、SecuritySchemeというクラスサブクラスでなければならないことに注意してください。

{
    @context: [
        "https://www.w3.org/2019/wot/td/v1",
        {
            "cov": "http://www.example.org/coap-binding#",
            "ace": "http://www.example.org/ace-security#"
        }
    ],
    ...
    "securityDefinitions": {
        "ace_sc": {
            "scheme": "ace:ACESecurityScheme",
            ...
            "ace:as": "coaps://as.example.com/token",
            "ace:audience": "coaps://rs.example.com",
            "ace:scopes": ["limited", "special"],
            "ace:cnonce": true
        }
    },
    "security": ["ace_sc"],
    "properties": {
        "status": {
            ...
            "forms": [{
                "op": "readproperty",
                "href": "coaps://rs.example.com/status",
                "contentType": "application/cbor",
                "cov:methodName": "GET",
                "ace:scopes": ["limited"]
            }]
        }
    },
    "actions": {
        "configure": {
            ...
            "forms": [{
                "op": "invokeaction",
                "href": "coaps://rs.example.com/configure",
                "contentType": "application/cbor",
                "cov:methodName": "POST",
                "ace:scopes": ["special"]
            }]
        }
    },
    ...
}

§ 5.3.3 セキュリティ語彙の定義で定義しているすべてのセキュリティ・スキームは既にTDコンテキストの一部であり、TDコンテキスト拡張を介して含める必要はありません。

8. 動作の言明

以下の言明は、TDの表現や情報モデルとは対照的に、WoTシステムの構成要素の動作に関連しています。しかし、TDは記述的であり、特に既存のネットワーク・インターフェースを記述するために用いられる場合があることに注意してください。これらの場合、そのような既存のインターフェースの動作を制限する言明を作成することはできません。代わりに、言明は、そのようなインターフェースを正確に表すためのTDの制約と解釈されなければなりません。

8.1 セキュリティの設定

安全な相互運用を可能にするために、セキュリティ設定はモノの要件を正確に反映しなければなりません。

一部のセキュリティ・プロトコルでは、必要なエンコーディングや暗号化スキームなど、認証情報を動的に要求する場合があります。上記の結果の1つは、プロトコルが、モノの記述で宣言されていないセキュリティ認証情報の形式、またはエンコーディングや暗号化スキームを要求する場合、モノの記述は無効と見なされるということです。

8.2データ・スキーマ

TDで提供されるデータ・スキーマは、TDで指定されている対話で記述されているモノによって返され、受け入れられるデータ・ペイロードを正確に表すべきです。一般的に、利用者はWoTモノの記述で示されていないものは生成せず、データ・スキーマに厳密に従うべきですが、WoTモノの記述で明示的に指定されていないモノからの追加データは受け入れるべきです。一般的に、モノはWoTモノの記述によって記述されますが、利用者モノと対話するときにWoTモノの記述に従うように制約されます。

8.3 プロトコル・バインディング

プロトコル・バインディングは、対話アフォーダンスから、HTTP[RFC7231]、CoAP[RFC7252]、MQTT[MQTT]などの特定のプロトコルの具体的なメッセージへのマッピングです。対話アフォーダンスプロトコル・バインディングは、§ 6.3.9 forms(フォーム)で定義しているformsとしてシリアル化されます。

WoTモノの記述のすべてのフォームには、hrefメンバーで示される送信ターゲットがなければなりません。この送信ターゲットのURIスキームは、モノがどのようなプロトコル・バインディングを実装しているかを示します[WOT-ARCHITECTURE]。例えば、ターゲットがhttpまたはhttpsで始まっていれば、利用者は、モノがHTTPに基づくプロトコル・バインディングを実装していることを推測でき、フォームのインスタンスにおいてHTTP固有の用語を予期すべきです(次の項、§ 8.3.1 HTTPに基づくプロトコル・バインディングを参照してください)。

8.3.1 HTTPに基づくプロトコル・バインディング

デフォルトでは、モノの記述は、RDF 1.0のHTTP語彙[HTTP-in-RDF10]からのHTTP RDF語彙の定義を含めることにより、HTTPに基づくプロトコル・バインディングをサポートします。この語彙は、http://www.w3.org/2011/http#を指し示す接頭辞であるhtvを用いることで、TDのインスタンス内で直接使用できます。HTTPに基づくプロトコル・バインディングの詳細は、[WOT-BINDING-TEMPLATES]にあります。

HTTPに基づくプロトコル・バインディングを実装するモノと対話するために、利用者は、フォームを送信するときにどのHTTPメソッドを用いるべきかを知る必要があります。一般的なケースでは、モノの記述には、メソッドを示す用語、つまりhtv:methodNameを明示的に含めることができます。簡潔にするために、HTTPに基づくプロトコル・バインディングは、下記の操作型のデフォルト値を定義し、これは、モノが期待するメソッド(例えば、読み取りにGET、書き込みにPUT)の収束を目的としています。HTTPに基づくプロトコル・バインディングを表している形式でメソッドが示されていない場合、次の表で示しているデフォルト値を想定しなければなりません(MUST)。

語彙用語 デフォルト値 コンテキスト
htv:methodName GET 操作型がreadpropertyreadallpropertiesreadmultiplepropertiesForm
htv:methodName PUT 操作型がwritepropertywriteallpropertieswritemultiplepropertiesForm
htv:methodName POST 操作型がinvokeactionForm

例えば、§ 1. はじめに例1では、フォームに操作型とHTTPメソッドが含まれていません。例1のフォームでは、次のデフォルト値を想定すべきです。

8.3.2 その他のプロトコル・バインディング

モノが実装できるプロトコル・バインディングの数には制限はありません。その他のプロトコル・バインディング(例えば、CoAP、MQTT、またはOPC UAなどの)は、RDF 1.0のHTTP語彙[HTTP-in-RDF10]に似たプロトコル語彙デフォルト値の定義が含まれている仕様などの別のドキュメントで標準化される予定です。このようなプロトコルは、TDコンテキスト拡張のメカニズムを用いることで、簡単にTDに統合できます(§ 7. TDコンテキスト拡張を参照)。

IoTプラットフォームとエコシステムを記述する方法については、[WOT-BINDING-TEMPLATES]を参照してください。

9. セキュリティとプライバシーに関する留意点

この項は非規範的です。

一般的に、WoTシステムを保護するために講じられるセキュリティ対策は、システムが直面する可能性のある脅威と攻撃者、および保護する必要がある資産の価値に依存します。さらに、プライバシーのリスクは、モノと特定可能な人物との関連性、および直接的な情報とそのような関連性から入手可能な推測される情報の両方に依存します。様々な状況に適応できる脅威モデルを含む、モノのウェブのセキュリティとプライバシーに関する留意点の詳細な議論は、参考情報のドキュメント[WOT-SECURITY-GUIDELINES]に記載されています。この項では、WoTモノの記述に直接関連するセキュリティとプライバシーのリスクおよび可能な軽減策についてのみ論じます。

WoTモノの記述は、安全なネットワーク・インターフェースと安全でないネットワーク・インターフェースの両方を記述することができます。モノの記述を既存のネットワーク・インターフェースに後付けする場合、ネットワーク・インターフェースのセキュリティ・ステータスは変わらないと予期されます。

WoTモノの記述を用いると、次の項で示しているセキュリティとプライバシーのリスクが生じます。個々のリスクの後で、いくつかの可能な軽減策を提案します。

9.1 プライバシーのリスクをフェッチするコンテキスト

JSON-LD[json-ld11]ドキュメントの@contextメンバーで指定されている語彙ファイルをフェッチすると、プライバシーのリスクになりえます。WoTの場合、攻撃者はそのようなフェッチによって生成されるネットワーク・トラフィックを観察することができ、特にドメイン固有の語彙が用いられている場合に、デバイスに関する情報を推測するために、宛先IPアドレスなどのフェッチのメタデータを使用できます。これは、接続が暗号化されていてもリスクであり、DNSプライバシーのリークに関連しています。

軽減策:
語彙ファイルの実際のフェッチを回避してください。語彙ファイルは可能な限りキャッシュすべきです。@contextメンバーのURIが(既知の)語彙の識別子としてのみ機能するようにして、をれを変更不可能にして、解釈デバイスに組み込み、完全にフェッチされなくするのが理想的です。そのためには、既存のURIで変更不可能なデータを参照できるように更新時に新しいURIを用いるべきであるため、厳密なバージョン管理を用いる必要があります。モノの記述のメタデータを解釈するシステムがコンテキスト・ファイルをローカルで利用できる可能性を高めるために、可能な限り有名な標準語彙ファイルを用いてください。

9.2 不変な識別子に関するプライバシーのリスク

識別子(id)を含んでいるモノの記述は、特定可能な人物に関連付けられているモノを記述することができます。このような識別子は、追跡を含む様々なリスクをもたらします。しかし、識別子も変更不可能である場合、デバイスが別の人に販売または譲渡され、その人を追跡するために既知のIDが用いられるため、追跡のリスクが増幅されます。

軽減策:
すべての識別子は変更可能であるべきであり、モノidを更新するメカニズムがあるべきです。具体的には、モノidはハードウェア内で固定されるべきではありません。しかし、これは、識別子が固定URIであるというリンクト・データの理想と矛盾します。多くの場合、モノが再初期化された場合にのみ識別子の更新を認めることは許容されるでしょう。このケースでは、ソフトウェア・エンティティーとしての古いモノは存在しなくなり、新しいモノが作成されます。これは、例えば、デバイスが新しい所有者に販売されたときに追跡の連鎖を断ち切るのに十分でありえます。あるいは、デバイスの運用段階の間により頻繁な変更が必要な場合は、変更時に、承認を与えられたユーザのみに識別子の変更を通知するメカニズムを導入できます。しかし、一部のクラスのデバイス、例えば、医療デバイスでは、一部の法的管轄区域において法律によって変更不可能なIDが求められる場合があります。この場合、そのような変更不可能な識別子を含むモノの記述などのファイルへのアクセスを保護するために特別な注意を払うべきです。このような場合、可能な限り、TDで「真の」変更不可能な識別子を共有しないことが望ましいかもしれません。

9.3 指紋に関するプライバシーのリスク

上記のように、TDのidメンバーはプライバシーのリスクを引き起こす可能性があります。しかし、前述のようにidを更新して追跡のリスクを軽減しても、TDを特定の物理デバイスに関連付け、そこから指紋採取により特定可能な人物に関連付けることができる場合があります。

指紋採取では特定のデバイスのインスタンスを特定できない場合でも、対話の集合など、TDの情報からデバイスの類型を推測し、この類型を用いて、病状などの特定可能な人物に関する個人情報を推測することができます。

軽減策:
モノに対するモノの記述へのアクセスは、承認されたユーザのみに提供すべきであり、承認のレベルとユースケースに必要な量の情報のみを提供すべきです。例えば、認証が必要なディレクトリ・サービスなどの安全で機密性のあるチャネルを介して、TDが承認されたユーザにのみ配信されていれば、外部の承認されていない当事者がTDにアクセスして指紋を取得することはできません。このリスクをさらに軽減するためには、TDの特定のユースケースに不要な情報は可能な限り除外すべきです。例えば、利用者がモノに関する状態を保存しない場合のデバイスへのアドホックな接続では、idは除外できます。利用者がユースケースで特定の対話を必要としない場合、それは除外できます。利用者が特定の対話の使用を承認されていなければ、同様に除外できます。タイトルや内容記述などの人間が読める情報を表示する機能を利用者が持っていなければ、それらを除外したり、長さがゼロの文字列に置き換えることができます。

9.4 グローバルに一意な識別子に関するプライバシーのリスク

グローバルに一意な識別子は、その作成と配信に中央機関が必要な場合、第三者が識別子を知っているため、プライバシーのリスクをもたらします。

軽減策:
TDのidフィールドは、意図的にグローバルに一意であることを求めていません。中央での登録を必要としない分散方式で適切なIDを生成するために利用可能な暗号化のメカニズムがいくつかあります。通常、これらのメカニズムで重複する識別子が生成される可能性は非常に低いためシステム設計ではこれを考慮する必要があります(例えば、必要に応じて重複を検出し、IDを再生成する)。IDの範囲もグローバルである必要はありません。家内や工場内などの特定のコンテキストでのみモノを区別する識別子を用いることもできます。

9.5 TDの傍受と改ざんに関するセキュリティのリスク

例えば、TD内のURLを書き換えて、データをキャプチャまたは操作できる悪意のある仲介者にアクセスをリダイレクトすることにより、TDの傍受と改ざんは、中間者攻撃を開始するために使用できます。

軽減策:
相互に認証されたチャネルを通じてのみモノの記述を取得してください。これにより、利用者とサーバーの両方が通信相手の身元を確実に把握できます。これは、承認されたユーザにのみTDを配信するためにも必要です。

9.6 コンテキストの傍受と改ざんに関するセキュリティのリスク

コンテキスト・ファイルの傍受および改ざんは、語彙の解釈を変更することにより攻撃を容易にするために使用できます。

軽減策:
コンテキスト・ファイルは認証されたチャネルを介してのみ取得されるのが理想的ですが、逆参照された場合に傍受と変更に対して脆弱であるHTTP URLを用いて多くのコンテキストが示されることは注意に値します(そして残念です)。しかし、コンテキスト・ファイルが変更不可能かつキャッシュされ、可能な限り逆参照が回避されれば、このリスクは低減できます。

9.7 個人を特定できる情報の推測に関するプライバシーのリスク

多くの場所では、ユーザのプライバシーを保護するために、個人を特定できる情報、つまり特定の人物に関連付けることができる情報の取り扱いに法的要件があります。もちろん、そのような情報はIoTデバイスによって直接生成される可能性があります。しかし、IoTデバイスの存在とメタデータ(モノの記述に保存される種類のデータ)は、個人を特定できる情報を含めたり、推測するために利用されたりする可能性もあります。この情報は、特定の人が特定の種類のデバイスを所有しているという事実と同じくらい単純である場合がありますが、それがその人物に関する追加の推論につながる可能性があります。

軽減策:
個人のデバイスに関連付けられたモノの記述を、個人を特定できる情報が含まれているかのように扱ってください。この原則の適用事例として、ユーザの同意を得る方法を検討してください。モノが生成する個人を特定できるデータの使用に対する同意は、モノとデータを利用するシステムとを組み合わせる際にしばしば得られます。これは、デバイスにアクセスするために、モノの記述がローカル・ディレクトリやモノの記述を利用するシステムに登録される際にも多いです。このケースでは、モノのデータの利用に対する同意は、モノのモノの記述へのアクセスに関する同意と組み合わせることができます。2番目の例として、TDに個人を特定できる情報を含むことを検討する場合には、TDを無期限に保持したり、同意を得られた以外の目的で使用したりすべきではありません。

10. IANAに関する留意点

10.1 application/td+jsonメディア・タイプの登録

タイプ名:
application
サブタイプ名:
td+json
必須パラメータ:
なし
任意のパラメータ:
なし
コード化に関する留意点:
RFC 6839の3.1項を参照。
セキュリティに関する留意点:
RFC 8259の12項を参照。

WoTモノの記述はモノのメタデータの純粋なデータ交換形式であることを目指しているため、そのシリアル化は、解析されるJavaScriptのeval()関数などのコード実行メカニズムを介して渡されるべきではありません(SHOULD NOT)。(不正な)ドキュメントには、実行時にシステムのセキュリティを危険にさらす予期しない副作用を引き起こす可能性のあるコードが含まれている場合があります。

WoTモノの記述はJSON-LD 1.1プロセッサで評価できます。これは通常、遠隔のコンテキスト(つまり、TDコンテキスト拡張。W3C WoTモノの記述の7項を参照)へのリンクを自動的にたどり、その結果、個々に対する利用者の明示的なリクエストがなくてもファイルが転送されます。第三者が遠隔のコンテキストを提供している場合、それによって彼らがプライバシー上の懸念につながる使用パターンや同様の情報を収集できる場合があります。資源に制約のあるデバイスでの実装では、(JSON-LD処理とは対照的に)未加工のJSONの処理を実行すると思われますが、一般的に実装は、サポートしているコンテキスト拡張の検査済みのバージョンを静的にキャッシュし、遠隔のコンテキストへのリンクをたどらないようにすべきです(SHOULD)。代わりに、サポートしているコンテキスト拡張は、安全なソフトウェア更新メカニズムにより管理できます。

HTTPなどの安全でない接続を通じてウェブから読み込まれたコンテキスト拡張(W3C WoTモノの記述の7項を参照)には、セキュリティを侵害しえる方法でTD情報モデルを変更するといった、攻撃者による変更が行われるリスクがあります。このため、利用者は、システムによる利用を許可する前に、遠隔のコンテキストを再検査してキャッシュすべきです(SHOULD)。

JSON-LD処理には通常、長いIRI[RFC3987]の短い用語への置換えが含まれることを考慮すると、JSON-LD 1.1プロセッサを用いて処理するとWoTモノの記述が大幅に拡張され、最悪の場合、結果のデータによって受信者の資源がすべて消費される可能性があります。利用者は、TDメタデータを懐疑的に扱うべきです(SHOULD)。

互換性に関する留意点:
RFC 8259を参照。

適合と不適合の両方のコンテンツを処理するための規則は、この仕様で定義しています。

公開済み仕様書:
https://w3c.github.io/wot-thing-description
このメディア・タイプを使用するアプリケーション:
W3Cモノのウェブに関与しているすべてのエンティティー、つまり、モノのウェブ(WoT)アーキテクチャで定義されているモノ利用者、および仲介。
フラグメント識別子に関する留意点:
RFC 6839の3.1項を参照。
追加情報:
マジック・ナンバー:
該当しない
ファイル拡張子:
.jsontd
マッキントッシュ・ファイル・タイプ・コード:
TEXT
詳細情報に関する連絡先:
Matthias Kovatsch <w3c@kovatsch.net>
意図する使途:
COMMON
使用上の制限:
なし
著者:
WoTモノの記述の仕様は、Web of Thingsワーキンググループの成果です。
改版管理者:
W3C

10.2 CoAPコンテンツ形式の登録

IANAは、Constrained RESTful Environments(CoRE)パラメータのレジストリ[RFC7252]内のCoAPコンテンツ形式サブレジストリのメディア・タイプにコンパクトなCoAPコンテンツ形式IDを割り当てています。WoTモノの記述のコンテンツ形式IDは、432です。

メディア・タイプ:
application/td+json
コード化:
-
ID:
432
参考文献:
["モノのウェブ(WoT)モノの記述", 2019年5月]

A. モノの記述のインスタンスの例

この項は非規範的です。

A.1 CoAPプロトコル・バインディングを用いたMyLampThingの例

モノの機能リスト

33: CoAPプロトコル・バインディングを用いたMyLampThing
{
   "@context": [
      "https://www.w3.org/2019/wot/td/v1",
      {
      "cov": "http://www.example.org/coap-binding#"
      }
    ],
    "id": "urn:dev:ops:32473-WoTLamp-1234",
    "title": "MyLampThing",
    "description" : "MyLampThing uses JSON serialization",
    "securityDefinitions": {"psk_sc":{"scheme": "psk"}},
    "security": ["psk_sc"],
    "properties": {
        "status": {
            "description" : "Shows the current status of the lamp",
            "type": "string",
            "forms": [{
                "op": "readproperty",
                "href": "coaps://mylamp.example.com/status",
                "cov:methodName" : "GET" 
            }]
        }
    },
    "actions": {
        "toggle": {
            "description" : "Turn on or off the lamp",
            "forms": [{
                "href": "coaps://mylamp.example.com/toggle",
                "cov:methodName" : "POST" 
            }]
        }
    },
    "events": {
        "overheating": {
            "description" : "Lamp reaches a critical temperature (overheating)",
            "data": {"type": "string"},
            "forms": [{
                "href": "coaps://mylamp.example.com/oh",
                "cov:methodName" : "GET",
                "subprotocol" : "cov:observe" 
            }]
        }
    }
}

A.2 MQTTプロトコル・バインディングを用いたMyIlluminanceSensorの例

モノの機能リスト:

34: MQTTプロトコル・バインディングを用いたMyIlluminanceSensor
{   
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "title": "MyIlluminanceSensor",
    "id": "urn:dev:ops:32473-WoTIlluminanceSensor-1234",
    "securityDefinitions": {"nosec_sc": {"scheme": "nosec"}},
    "security": ["nosec_sc"],
    "events": {
        "illuminance": {
            "data":{"type": "integer"},
            "forms": [
                {
                    "href": "mqtt://192.168.1.187:1883/illuminance",
                    "contentType" : "text/plain",
                    "op" : "subscribeevent"
                }
            ]
        }
    } 
}

A.3 Webhookイベントの例

モノの機能リスト:

35: 購読と中止を伴う温度イベント
{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "id": "urn:dev:ops:32473-Thing-1234",
    "title": "WebhookThing",
    "description": "Webhook-based Event with subscription and unsubscribe form.",
    "securityDefinitions": {"nosec_sc": {"scheme": "nosec"}},
    "security": ["nosec_sc"],
    "events": {
        "temperature": {
            "description": "Provides periodic temperature value updates.",
            "subscription": {
                "type": "object",
                "properties": {
                    "callbackURL": {
                        "type": "string",
                        "format": "uri",
                        "description": "Callback URL provided by subscriber for Webhook notifications.",
                        "writeOnly": true
                    },
                    "subscriptionID": {
                        "type": "string",
                        "description": "Unique subscription ID for cancellation provided by WebhookThing.",
                        "readOnly": true
                    }
                }
            },
            "data": {
                "type": "number",
                "description": "Latest temperature value that is sent to the callback URL."
            },
            "cancellation": {
                "type": "object",
                "properties": {
                    "subscriptionID": {
                        "type": "integer",
                        "description": "Required subscription ID to cancel subscription.",
                        "writeOnly": true
                    }
                }
            },
            "uriVariables": {
                "subscriptionID": { "type": "string" }
            },
            "forms": [
                {
                    "op": "subscribeevent",
                    "href": "http://192.168.0.124:8080/events/temp/subscribe",
                    "contentType": "application/json",
                    "htv:methodName": "POST"
                },
                {
                    "op": "unsubscribeevent",
                    "href": "http://192.168.0.124:8080/events/temp/{subscriptionID}",
                    "htv:methodName": "DELETE"
                }
            ]
        }
    }
}

B. TDのインスタンス検証用JSONスキーマ

この項は非規範的です。

下記は、JSONベースの形式でシリアル化されたモノの記述のインスタンスを構文的に検証するためのJSONスキーマ[JSON-SCHEMA]ドキュメントです。

このドキュメントで定義しているモノの記述では、JSON-LD[json-ld11]で知られている@contextメカニズムを用いて外部語彙を追加でき、これらの外部語彙の用語は、§ 5. TD情報モデルで定義している用語に加えて使用できます。そのため、下記のJSONスキーマはその点で意図的に厳密ではありません。外部語彙が用いられていない場合には、より厳密な検証を行うために、異なる範囲/レベルでadditionalPropertiesスキーマ・プロパティーの値であるtruefalseに置き換えることができます。

一部のJSONスキーマ検証ツールは、iriの文字列形式をサポートしていないことに注意してください。

TDのインスタンスを検証するための次のJSONスキーマでは、デフォルト値を持つ用語が存在している必要はありません。したがって、デフォルト値を持つ用語はオプションです。(§ 5.4 デフォルト値の定義も参照)

    {
    "title": "WoT TD Schema - 16 October 2019",
    "description": "JSON Schema for validating TD instances against the TD model. TD instances can be with or without terms that have default values",
    "$schema ": "http://json-schema.org/draft-07/schema#",
    "definitions": {
        "anyUri": {
            "type": "string",
            "format": "iri-reference"
        },
        "description": {
            "type": "string"
        },
        "descriptions": {
            "type": "object",
            "additionalProperties": {
                "type": "string"
            }
        },
        "title": {
            "type": "string"
        },
        "titles": {
            "type": "object",
            "additionalProperties": {
                "type": "string"
            }
        },
        "security": {
            "oneOf": [{
                    "type": "array",
                    "items": {
                        "type": "string"
                    }
                },
                {
                    "type": "string"
                }
            ]
        },
        "scopes": {
            "oneOf": [{
                    "type": "array",
                    "items": {
                        "type": "string"
                    }
                },
                {
                    "type": "string"
                }
            ]
        },
        "subprotocol": {
            "type": "string",
            "enum": [
                "longpoll",
                "websub",
                "sse"
            ]
        },
        "thing-context-w3c-uri": {
            "type": "string",
            "enum": [
                "https://www.w3.org/2019/wot/td/v1"
            ]
        },
        "thing-context": {
            "oneOf": [{
                    "type": "array",
                    "items": [{
                        "$ref": "#/definitions/thing-context-w3c-uri"
                    }],
                    "additionalItems": {
                        "anyOf": [{
                                "$ref": "#/definitions/anyUri"
                            },
                            {
                                "type": "object"
                            }
                        ]
                    }
                },
                {
                    "$ref": "#/definitions/thing-context-w3c-uri"
                }
            ]
        },
        "type_declaration": {
            "oneOf": [{
                    "type": "string"
                },
                {
                    "type": "array",
                    "items": {
                        "type": "string"
                    }
                }
            ]
        },
        "dataSchema": {
            "type": "object",
            "properties": {
                "@type": {
                    "$ref": "#/definitions/type_declaration"
                },
                "description": {
                    "$ref": "#/definitions/description"
                },
                "title": {
                    "$ref": "#/definitions/title"
                },
                "descriptions": {
                    "$ref": "#/definitions/descriptions"
                },
                "titles": {
                    "$ref": "#/definitions/titles"
                },
                "writeOnly": {
                    "type": "boolean"
                },
                "readOnly": {
                    "type": "boolean"
                },
                "oneOf": {
                    "type": "array",
                    "items": {
                        "$ref": "#/definitions/dataSchema"
                    }
                },
                "unit": {
                    "type": "string"
                },
                "enum": {
                    "type": "array",
                    "minItems": 1,
                    "uniqueItems": true
                },
                "format": {
                    "type": "string"
                },
                "const": {},
                "type": {
                    "type": "string",
                    "enum": [
                        "boolean",
                        "integer",
                        "number",
                        "string",
                        "object",
                        "array",
                        "null"
                    ]
                },
                "items": {
                    "oneOf": [{
                            "$ref": "#/definitions/dataSchema"
                        },
                        {
                            "type": "array",
                            "items": {
                                "$ref": "#/definitions/dataSchema"
                            }
                        }
                    ]
                },
                "maxItems": {
                    "type": "integer",
                    "minimum": 0
                },
                "minItems": {
                    "type": "integer",
                    "minimum": 0
                },
                "minimum": {
                    "type": "number"
                },
                "maximum": {
                    "type": "number"
                },
                "properties": {
                    "additionalProperties": {
                        "$ref": "#/definitions/dataSchema"
                    }
                },
                "required": {
                    "type": "array",
                    "items": {
                        "type": "string"
                    }
                }
            }
        },
        "form_element_property": {
            "type": "object",
            "properties": {
                "op": {
                    "oneOf": [{
                            "type": "string",
                            "enum": [
                                "readproperty",
                                "writeproperty",
                                "observeproperty",
                                "unobserveproperty"
                            ]
                        },
                        {
                            "type": "array",
                            "items": {
                                "type": "string",
                                "enum": [
                                    "readproperty",
                                    "writeproperty",
                                    "observeproperty",
                                    "unobserveproperty"
                                ]
                            }
                        }
                    ]
                },
                "href": {
                    "$ref": "#/definitions/anyUri"
                },
                "contentType": {
                    "type": "string"
                },
                "contentCoding": {
                    "type": "string"
                },
                "subprotocol": {
                    "$ref": "#/definitions/subprotocol"
                },
                "security": {
                    "$ref": "#/definitions/security"
                },
                "scopes": {
                    "$ref": "#/definitions/scopes"
                },
                "response": {
                    "type": "object",
                    "properties": {
                        "contentType": {
                            "type": "string"
                        }
                    }
                }
            },
            "required": [
                "href"
            ],
            "additionalProperties": true
        },
        "form_element_action": {
            "type": "object",
            "properties": {
                "op": {
                    "oneOf": [{
                            "type": "string",
                            "enum": [
                                "invokeaction"
                            ]
                        },
                        {
                            "type": "array",
                            "items": {
                                "type": "string",
                                "enum": [
                                    "invokeaction"
                                ]
                            }
                        }
                    ]
                },
                "href": {
                    "$ref": "#/definitions/anyUri"
                },
                "contentType": {
                    "type": "string"
                },
                "contentCoding": {
                    "type": "string"
                },
                "subprotocol": {
                    "$ref": "#/definitions/subprotocol"
                },
                "security": {
                    "$ref": "#/definitions/security"
                },
                "scopes": {
                    "$ref": "#/definitions/scopes"
                },
                "response": {
                    "type": "object",
                    "properties": {
                        "contentType": {
                            "type": "string"
                        }
                    }
                }
            },
            "required": [
                "href"
            ],
            "additionalProperties": true
        },
        "form_element_event": {
            "type": "object",
            "properties": {
                "op": {
                    "oneOf": [{
                            "type": "string",
                            "enum": [
                                "subscribeevent",
                                "unsubscribeevent"
                            ]
                        },
                        {
                            "type": "array",
                            "items": {
                                "type": "string",
                                "enum": [
                                    "subscribeevent",
                                    "unsubscribeevent"
                                ]
                            }
                        }
                    ]
                },
                "href": {
                    "$ref": "#/definitions/anyUri"
                },
                "contentType": {
                    "type": "string"
                },
                "contentCoding": {
                    "type": "string"
                },
                "subprotocol": {
                    "$ref": "#/definitions/subprotocol"
                },
                "security": {
                    "$ref": "#/definitions/security"
                },
                "scopes": {
                    "$ref": "#/definitions/scopes"
                },
                "response": {
                    "type": "object",
                    "properties": {
                        "contentType": {
                            "type": "string"
                        }
                    }
                }
            },
            "required": [
                "href"
            ],
            "additionalProperties": true
        },
        "form_element_root": {
            "type": "object",
            "properties": {
                "op": {
                    "oneOf": [{
                            "type": "string",
                            "enum": [
                                "readallproperties",
                                "writeallproperties",
                                "readmultipleproperties",
                                "writemultipleproperties"
                            ]
                        },
                        {
                            "type": "array",
                            "items": {
                                "type": "string",
                                "enum": [
                                    "readallproperties",
                                    "writeallproperties",
                                    "readmultipleproperties",
                                    "writemultipleproperties"
                                ]
                            }
                        }
                    ]
                },
                "href": {
                    "$ref": "#/definitions/anyUri"
                },
                "contentType": {
                    "type": "string"
                },
                "contentCoding": {
                    "type": "string"
                },
                "subprotocol": {
                    "$ref": "#/definitions/subprotocol"
                },
                "security": {
                    "$ref": "#/definitions/security"
                },
                "scopes": {
                    "$ref": "#/definitions/scopes"
                },
                "response": {
                    "type": "object",
                    "properties": {
                        "contentType": {
                            "type": "string"
                        }
                    }
                }
            },
            "required": [
                "href"
            ],
            "additionalProperties": true
        },
        "property_element": {
            "type": "object",
            "properties": {
                "@type": {
                    "$ref": "#/definitions/type_declaration"
                },
                "description": {
                    "$ref": "#/definitions/description"
                },
                "descriptions": {
                    "$ref": "#/definitions/descriptions"
                },
                "title": {
                    "$ref": "#/definitions/title"
                },
                "titles": {
                    "$ref": "#/definitions/titles"
                },
                "forms": {
                    "type": "array",
                    "minItems": 1,
                    "items": {
                        "$ref": "#/definitions/form_element_property"
                    }
                },
                "uriVariables": {
                    "type": "object",
                    "additionalProperties": {
                        "$ref": "#/definitions/dataSchema"
                    }
                },
                "observable": {
                    "type": "boolean"
                },
                "writeOnly": {
                    "type": "boolean"
                },
                "readOnly": {
                    "type": "boolean"
                },
                "oneOf": {
                    "type": "array",
                    "items": {
                        "$ref": "#/definitions/dataSchema"
                    }
                },
                "unit": {
                    "type": "string"
                },
                "enum": {
                    "type": "array",
                    "minItems": 1,
                    "uniqueItems": true
                },
                "format": {
                    "type": "string"
                },
                "const": {},
                "type": {
                    "type": "string",
                    "enum": [
                        "boolean",
                        "integer",
                        "number",
                        "string",
                        "object",
                        "array",
                        "null"
                    ]
                },
                "items": {
                    "oneOf": [{
                            "$ref": "#/definitions/dataSchema"
                        },
                        {
                            "type": "array",
                            "items": {
                                "$ref": "#/definitions/dataSchema"
                            }
                        }
                    ]
                },
                "maxItems": {
                    "type": "integer",
                    "minimum": 0
                },
                "minItems": {
                    "type": "integer",
                    "minimum": 0
                },
                "minimum": {
                    "type": "number"
                },
                "maximum": {
                    "type": "number"
                },
                "properties": {
                    "additionalProperties": {
                        "$ref": "#/definitions/dataSchema"
                    }
                },
                "required": {
                    "type": "array",
                    "items": {
                        "type": "string"
                    }
                }
            },
            "required": [
                "forms"
            ],
            "additionalProperties": true
        },
        "action_element": {
            "type": "object",
            "properties": {
                "@type": {
                    "$ref": "#/definitions/type_declaration"
                },
                "description": {
                    "$ref": "#/definitions/description"
                },
                "descriptions": {
                    "$ref": "#/definitions/descriptions"
                },
                "title": {
                    "$ref": "#/definitions/title"
                },
                "titles": {
                    "$ref": "#/definitions/titles"
                },
                "forms": {
                    "type": "array",
                    "minItems": 1,
                    "items": {
                        "$ref": "#/definitions/form_element_action"
                    }
                },
                "uriVariables": {
                    "type": "object",
                    "additionalProperties": {
                        "$ref": "#/definitions/dataSchema"
                    }
                },
                "input": {
                    "$ref": "#/definitions/dataSchema"
                },
                "output": {
                    "$ref": "#/definitions/dataSchema"
                },
                "safe": {
                    "type": "boolean"
                },
                "idempotent": {
                    "type": "boolean"
                }
            },
            "required": [
                "forms"
            ],
            "additionalProperties": true
        },
        "event_element": {
            "type": "object",
            "properties": {
                "@type": {
                    "$ref": "#/definitions/type_declaration"
                },
                "description": {
                    "$ref": "#/definitions/description"
                },
                "descriptions": {
                    "$ref": "#/definitions/descriptions"
                },
                "title": {
                    "$ref": "#/definitions/title"
                },
                "titles": {
                    "$ref": "#/definitions/titles"
                },
                "forms": {
                    "type": "array",
                    "minItems": 1,
                    "items": {
                        "$ref": "#/definitions/form_element_event"
                    }
                },
                "uriVariables": {
                    "type": "object",
                    "additionalProperties": {
                        "$ref": "#/definitions/dataSchema"
                    }
                },
                "subscription": {
                    "$ref": "#/definitions/dataSchema"
                },
                "data": {
                    "$ref": "#/definitions/dataSchema"
                },
                "cancellation": {
                    "$ref": "#/definitions/dataSchema"
                }
            },
            "required": [
                "forms"
            ],
            "additionalProperties": true
        },
        "link_element": {
            "type": "object",
            "properties": {
                "href": {
                    "$ref": "#/definitions/anyUri"
                },
                "type": {
                    "type": "string"
                },
                "rel": {
                    "type": "string"
                },
                "anchor": {
                    "$ref": "#/definitions/anyUri"
                }
            },
            "required": [
                "href"
            ],
            "additionalProperties": true
        },
        "securityScheme": {
            "oneOf": [{
                    "type": "object",
                    "properties": {
                        "@type": {
                            "$ref": "#/definitions/type_declaration"
                        },
                        "description": {
                            "$ref": "#/definitions/description"
                        },
                        "descriptions": {
                            "$ref": "#/definitions/descriptions"
                        },
                        "proxy": {
                            "$ref": "#/definitions/anyUri"
                        },
                        "scheme": {
                            "type": "string",
                            "enum": [
                                "nosec"
                            ]
                        }
                    },
                    "required": [
                        "scheme"
                    ]
                },
                {
                    "type": "object",
                    "properties": {
                        "@type": {
                            "$ref": "#/definitions/type_declaration"
                        },
                        "description": {
                            "$ref": "#/definitions/description"
                        },
                        "descriptions": {
                            "$ref": "#/definitions/descriptions"
                        },
                        "proxy": {
                            "$ref": "#/definitions/anyUri"
                        },
                        "scheme": {
                            "type": "string",
                            "enum": [
                                "basic"
                            ]
                        },
                        "in": {
                            "type": "string",
                            "enum": [
                                "header",
                                "query",
                                "body",
                                "cookie"
                            ]
                        },
                        "name": {
                            "type": "string"
                        }
                    },
                    "required": [
                        "scheme"
                    ]
                },
                {
                    "type": "object",
                    "properties": {
                        "@type": {
                            "$ref": "#/definitions/type_declaration"
                        },
                        "description": {
                            "$ref": "#/definitions/description"
                        },
                        "descriptions": {
                            "$ref": "#/definitions/descriptions"
                        },
                        "proxy": {
                            "$ref": "#/definitions/anyUri"
                        },
                        "scheme": {
                            "type": "string",
                            "enum": [
                                "digest"
                            ]
                        },
                        "qop": {
                            "type": "string",
                            "enum": [
                                "auth",
                                "auth-int"
                            ]
                        },
                        "in": {
                            "type": "string",
                            "enum": [
                                "header",
                                "query",
                                "body",
                                "cookie"
                            ]
                        },
                        "name": {
                            "type": "string"
                        }
                    },
                    "required": [
                        "scheme"
                    ]
                },
                {
                    "type": "object",
                    "properties": {
                        "@type": {
                            "$ref": "#/definitions/type_declaration"
                        },
                        "description": {
                            "$ref": "#/definitions/description"
                        },
                        "descriptions": {
                            "$ref": "#/definitions/descriptions"
                        },
                        "proxy": {
                            "$ref": "#/definitions/anyUri"
                        },
                        "scheme": {
                            "type": "string",
                            "enum": [
                                "apikey"
                            ]
                        },
                        "in": {
                            "type": "string",
                            "enum": [
                                "header",
                                "query",
                                "body",
                                "cookie"
                            ]
                        },
                        "name": {
                            "type": "string"
                        }
                    },
                    "required": [
                        "scheme"
                    ]
                },
                {
                    "type": "object",
                    "properties": {
                        "@type": {
                            "$ref": "#/definitions/type_declaration"
                        },
                        "description": {
                            "$ref": "#/definitions/description"
                        },
                        "descriptions": {
                            "$ref": "#/definitions/descriptions"
                        },
                        "proxy": {
                            "$ref": "#/definitions/anyUri"
                        },
                        "scheme": {
                            "type": "string",
                            "enum": [
                                "bearer"
                            ]
                        },
                        "authorization": {
                            "$ref": "#/definitions/anyUri"
                        },
                        "alg": {
                            "type": "string"
                        },
                        "format": {
                            "type": "string"
                        },
                        "in": {
                            "type": "string",
                            "enum": [
                                "header",
                                "query",
                                "body",
                                "cookie"
                            ]
                        },
                        "name": {
                            "type": "string"
                        }
                    },
                    "required": [
                        "scheme"
                    ]
                },
                {
                    "type": "object",
                    "properties": {
                        "@type": {
                            "$ref": "#/definitions/type_declaration"
                        },
                        "description": {
                            "$ref": "#/definitions/description"
                        },
                        "descriptions": {
                            "$ref": "#/definitions/descriptions"
                        },
                        "proxy": {
                            "$ref": "#/definitions/anyUri"
                        },
                        "scheme": {
                            "type": "string",
                            "enum": [
                                "psk"
                            ]
                        },
                        "identity": {
                            "type": "string"
                        }
                    },
                    "required": [
                        "scheme"
                    ]
                },
                {
                    "type": "object",
                    "properties": {
                        "@type": {
                            "$ref": "#/definitions/type_declaration"
                        },
                        "description": {
                            "$ref": "#/definitions/description"
                        },
                        "descriptions": {
                            "$ref": "#/definitions/descriptions"
                        },
                        "proxy": {
                            "$ref": "#/definitions/anyUri"
                        },
                        "scheme": {
                            "type": "string",
                            "enum": [
                                "oauth2"
                            ]
                        },
                        "authorization": {
                            "$ref": "#/definitions/anyUri"
                        },
                        "token": {
                            "$ref": "#/definitions/anyUri"
                        },
                        "refresh": {
                            "$ref": "#/definitions/anyUri"
                        },
                        "scopes": {
                            "oneOf": [{
                                    "type": "array",
                                    "items": {
                                        "type": "string"
                                    }
                                },
                                {
                                    "type": "string"
                                }
                            ]
                        },
                        "flow": {
                            "type": "string",
                            "enum": [
                                "code"
                            ]
                        }
                    },
                    "required": [
                        "scheme"
                    ]
                }
            ]
        }
    },
    "type": "object",
    "properties": {
        "id": {
            "type": "string",
            "format": "uri"
        },
        "title": {
            "$ref": "#/definitions/title"
        },
        "titles": {
            "$ref": "#/definitions/titles"
        },
        "properties": {
            "type": "object",
            "additionalProperties": {
                "$ref": "#/definitions/property_element"
            }
        },
        "actions": {
            "type": "object",
            "additionalProperties": {
                "$ref": "#/definitions/action_element"
            }
        },
        "events": {
            "type": "object",
            "additionalProperties": {
                "$ref": "#/definitions/event_element"
            }
        },
        "description": {
            "$ref": "#/definitions/description"
        },
        "descriptions": {
            "$ref": "#/definitions/descriptions"
        },
        "version": {
            "type": "object",
            "properties": {
                "instance": {
                    "type": "string"
                }
            },
            "required": [
                "instance"
            ]
        },
        "links": {
            "type": "array",
            "items": {
                "$ref": "#/definitions/link_element"
            }
        },
        "forms": {
            "type": "array",
            "minItems": 1,
            "items": {
                "$ref": "#/definitions/form_element_root"
            }
        },
        "base": {
            "$ref": "#/definitions/anyUri"
        },
        "securityDefinitions": {
            "type": "object",
            "minProperties": 1,
            "additionalProperties": {
                "$ref": "#/definitions/securityScheme"
            }
        },
        "support": {
            "$ref": "#/definitions/anyUri"
        },
        "created": {
            "type": "string",
            "format": "date-time"
        },
        "modified": {
            "type": "string",
            "format": "date-time"
        },
        "security": {
            "oneOf": [{
                    "type": "string"
                },
                {
                    "type": "array",
                    "minItems": 1,
                    "items": {
                        "type": "string"
                    }
                }
            ]
        },
        "@type": {
            "$ref": "#/definitions/type_declaration"
        },
        "@context": {
            "$ref": "#/definitions/thing-context"
        }
    },
    "required": [
        "title",
        "security",
        "securityDefinitions",
        "@context"
    ],
    "additionalProperties": true
}

C. モノの記述テンプレート

この項は非規範的です。

モノの記述テンプレートは、モノクラスの記述です。これは、モノのグループ全体で共有されるプロパティー、アクション、イベント、および共通のメタデータを記述し、それにより、クラウド・サーバーが、モノごとに行うのは現実的ではない、何千ものデバイスの共通処理を行うことができます。モノの記述テンプレートは、§ 5. TD情報モデルと同じコア語彙と情報モデルを用います。

モノの記述テンプレートにより、次のことが可能になります。

モノの記述テンプレートは、インターフェースとデバイスとの可能な対話(プロパティー、アクション、イベント)の論理的な記述ですが、シリアル番号、GPS上の位置、セキュリティ情報、具体的なプロトコル・エンドポイントなどのデバイス固有の情報は含まれていません。

モノの記述テンプレートは、特定のエンドポイントに対するプロトコル・バインディングを含まず、特定のセキュリティ・メカニズムを定義しないため、フォームsecurityDefinitions(セキュリティ定義)およびセキュリティのキーが存在してはなりません。

同じモノの記述テンプレートを複数のベンダーのモノに実装できます。モノは複数のモノの記述テンプレートを実装し、追加のメタデータ(ベンダー、場所、セキュリティ)を定義し、具体的なプロトコルへのバインディングを定義できます。共通するモノに結合される様々なモノの記述テンプレートのプロパティー、アクション、およびイベント間の衝突を避けるために、これらすべての識別子はモノの中で一意でなければなりません。

あるクラスのデバイスに共通するモノの記述テンプレートを用いると、ベンダーにまたがるアプリケーションを記述でき、アプリケーション開発者にとってより魅力的な市場が作られます。具体的なモノの記述は、複数のモノの記述テンプレートを実装できるため、機能ブロックを1つの結合デバイスに統合することができます。

クラウド・ベンダーのビジネス・モデルは通常、何千もの同じデバイスの管理に基づいて構築されています。同じモノの記述テンプレートを持つすべてのデバイスは、クラウド・アプリケーションが同じ方法で管理できます。インターフェースとインスタンスを別々に扱うと、多数のシミュレートされたデバイスを簡単に作成できます。

モノの記述テンプレートは、一部のオプションと必須の語彙用語が存在しないモノの記述のサブセットであるため、モノの記述と同じ方法、同じ形式でシリアル化できます。モノのテンプレートのインスタンスは、必須の用語が欠けているため、モノの記述インスタンスと同じ方法で検証することはできないことに注意してください。

C.1 モノの記述テンプレートの例

この項では、照明のモノの記述テンプレートとブザーのモノの記述テンプレートを示します。

C.1.1 モノの記述テンプレート: 照明

36: JSONでシリアル化されたMyLampThingTemplate
{
    "@context": ["https://www.w3.org/2019/wot/td/v1"], 
    "@type" : "ThingTemplate",
    "title": "Lamp Thing Description Template",
    "description" : "Lamp Thing Description Template",
    "properties": {
        "status": {
            "description" : "current status of the lamp (on|off)",
            "type": "string",
            "readOnly": true
        }
    },
    "actions": {
        "toggle": {
            "description" : "Turn the lamp on or off"
        }
    },
    "events": {
        "overheating": {
            "description" : "Lamp reaches a critical temperature (overheating)",
            "data": {"type": "string"}
        }
    }
}

C.1.2 モノの記述テンプレート: ブザー

37: JSONでシリアル化されたMyBuzzerThingTemplate
{
    "@context": ["https://www.w3.org/2019/wot/td/v1"], 
    "@type" : "ThingTemplate",
    "title": "Buzzer Thing Description Template",
    "description" : "Thing Description Template of a buzzer that makes noise for 10 seconds",
     "actions": {
        "buzz": {
            "description" : "buzz for 10 seconds"
        }
     }
}

D. JSON-LDコンテキストの使用法

この項は非規範的です。

現在の仕様では、TD情報モデルを様々な語彙に対する制約の集合、つまり語彙用語の集合として導入しています。この項では、TDドキュメントの必須の@contextを用いて、これらの制約の機械可読な定義をクライアント・アプリケーションに統合する方法について簡単に説明します。

TDドキュメントからTD情報モデルへのアクセスは、2つのステップで実行されます。最初に、クライアントはJSON文字列からIRIへのマッピングを取得する必要があります。このマッピングは、後で説明するとおり、JSON-LDコンテキストとして定義されます。次に、クライアントは、このIRIを逆参照することにより、これらのIRIで定義されている制約にアクセスできます。制約は、RDF形式の論理公理として定義され、クライアント・プログラムが容易に解釈できます。

§ 5. TD情報モデルで参照しているすべての語彙用語は、TDドキュメント内の(コンパクトな)JSON文字列としてシリアル化されています。しかし、これらの各用語は、最初のリンクト・データ原則[LINKED-DATA]に従って、完全なIRIによって明確に識別されます。JSONキーからIRIへのマッピングは、TDの@context値が指し示すものです。例えば、次のファイル

https://www.w3.org/2019/wot/td/v1

には、次(抜粋)のマッピングが含まれています。

properties https://www.w3.org/2019/wot/td#hasPropertyAffordance
object https://www.w3.org/2019/wot/json-schema#ObjectSchema
basic https://www.w3.org/2019/wot/security#BasicSecurityScheme
href https://www.w3.org/2019/wot/hypermedia#hasTarget
...

このJSONファイルは、JSON-LD 1.1構文[JSON-LD11]に従います。多数のJSON-LDライブラリがTDの@contextを自動的に処理し、それに含まれているすべてのJSON文字列を展開できます。

TDのすべての語彙用語がIRIに展開されると、次のステップは、このIRIを逆参照して、その語彙用語を参照するTD情報モデルのフラグメントを取得することです。例えば、次のIRIを逆参照すると、

https://www.w3.org/2019/wot/json-schema#ObjectSchema

ObjectSchemaという用語はクラスであり、より正確にはDataSchemaのサブクラスであると述べるRDFドキュメントが作成されます。このような論理公理は、様々な複雑さの形式を用いてRDFで表されます。ここでは、サブクラス関係はRDFスキーマ公理[RDF-SCHEMA]として表しています。さらに、これらの公理は様々な形式でシリアル化できます。ここでは、それらはTurtle形式[TURTLE]でシリアル化しています。

<https://www.w3.org/2019/wot/json-schema#ObjectSchema>
    a rdfs:Class .
<https://www.w3.org/2019/wot/json-schema#ObjectSchema>
    rdfs:subClassOf <https://www.w3.org/2019/wot/json-schema#DataSchema> .

デフォルトでは、ユーザ・エージェントが内容交渉を実行しない場合は、RDFドキュメントの代わりに人間が読めるHTMLドキュメントが返されます。内容交渉を行うためには、クライアントはリクエストにHTTPヘッダーAccept: text/turtleを含めなければなりません。

E. 最近の仕様変更

E.1 勧告案からの変更

E.2 第2勧告候補からの変更

E.3 最初の勧告候補からの変更

最初の勧告候補からの変更点は、2番目の勧告候補で記述しています

F. 謝辞

編集者は、貢献、助言、専門知識の提供に対し、Michael Koster、Michael Lagally、Kazuyuki Ashimura、Ege Korkan、Daniel Peintner、Toru Kawaguchi、Maria Poveda、Dave Raggett、Kunihiko Toumura、Takeshi Yamada、Ben Francis、Manu Sporny、Klaus Hartke、Addison Phillips、Jose M. Cantera、Tomoaki Mizushima、Soumya Kanti Datta、Benjamin Klotzに謝意を表します。

また、このドキュメントの改善につながったサポート、技術情報、提案に対し、W3Cのスタッフ、およびW3C Web of Things利害団体(WoT IG)とワーキンググループ(WoT WG)の現在および以前のすべての関係者にも感謝申し上げます。

最後に、WoT IGの創設から2年にわたってリードし、モノの記述を含むWoT構成要素の概念にグループを導いてくれたJoerg Heuerに特に感謝申し上げます。

G. 参考文献

G.1 規範的な参考文献

[BCP47]
Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47
[html]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jagenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[RFC2046]
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed; N. Borenstein. IETF. November 1996. Draft Standard. URL: https://tools.ietf.org/html/rfc2046
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3339]
Date and Time on the Internet: Timestamps. G. Klyne; C. Newman. IETF. July 2002. Proposed Standard. URL: https://tools.ietf.org/html/rfc3339
[RFC3629]
UTF-8, a transformation format of ISO 10646. F. Yergeau. IETF. November 2003. Internet Standard. URL: https://tools.ietf.org/html/rfc3629
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987
[RFC6570]
URI Template. J. Gregorio; R. Fielding; M. Hadley; M. Nottingham; D. Orchard. IETF. March 2012. Proposed Standard. URL: https://tools.ietf.org/html/rfc6570
[RFC6749]
The OAuth 2.0 Authorization Framework. D. Hardt, Ed.. IETF. October 2012. Proposed Standard. URL: https://tools.ietf.org/html/rfc6749
[RFC6750]
The OAuth 2.0 Authorization Framework: Bearer Token Usage. M. Jones; D. Hardt. IETF. October 2012. Proposed Standard. URL: https://tools.ietf.org/html/rfc6750
[RFC7252]
The Constrained Application Protocol (CoAP). Z. Shelby; K. Hartke; C. Bormann. IETF. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7252
[RFC7516]
JSON Web Encryption (JWE). M. Jones; J. Hildebrand. IETF. May 2015. Proposed Standard. URL: https://tools.ietf.org/html/rfc7516
[RFC7519]
JSON Web Token (JWT). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://tools.ietf.org/html/rfc7519
[RFC7616]
HTTP Digest Access Authentication. R. Shekh-Yusef, Ed.; D. Ahrens; S. Bremer. IETF. September 2015. Proposed Standard. URL: https://httpwg.org/specs/rfc7616.html
[RFC7617]
The 'Basic' HTTP Authentication Scheme. J. Reschke. IETF. September 2015. Proposed Standard. URL: https://httpwg.org/specs/rfc7617.html
[RFC7797]
JSON Web Signature (JWS) Unencoded Payload Option. M. Jones. IETF. February 2016. Proposed Standard. URL: https://tools.ietf.org/html/rfc7797
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://tools.ietf.org/html/rfc8174
[RFC8252]
OAuth 2.0 for Native Apps. W. Denniss; J. Bradley. IETF. October 2017. Best Current Practice. URL: https://tools.ietf.org/html/rfc8252
[RFC8259]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. December 2017. Internet Standard. URL: https://tools.ietf.org/html/rfc8259
[RFC8288]
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
[RFC8392]
CBOR Web Token (CWT). M. Jones; E. Wahlstroem; S. Erdtman; H. Tschofenig. IETF. May 2018. Proposed Standard. URL: https://tools.ietf.org/html/rfc8392
[websub]
WebSub. Julien Genestoux; Aaron Parecki. W3C. 23 January 2018. W3C Recommendation. URL: https://www.w3.org/TR/2018/REC-websub-20180123/
[XMLSCHEMA11-2-20120405]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/

G.2 参考情報の参考文献

[ACE]
Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth). L. Seitz; G. Selander; E. Wahlstroem; S. Erdtman; H. Tschofenig. IETF. 27 March 2019. Internet-Draft. URL: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-24
[HTTP-in-RDF10]
HTTP Vocabulary in RDF 1.0. Johannes Koch; Carlos A. Velasco; Philip Ackermann. W3C. 2 February 2017. W3C Note. URL: https://www.w3.org/TR/2017/NOTE-HTTP-in-RDF10-20170202/
[IANA-MEDIA-TYPES]
Media Types. IANA. URL: https://www.iana.org/assignments/media-types/
[IANA-URI-SCHEMES]
Uniform Resource Identifier (URI) Schemes. IANA. URL: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
[JSON-LD11]
JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 March 2020. W3C Candidate Recommendation. URL: https://www.w3.org/TR/2020/CR-json-ld11-20200316/
[JSON-SCHEMA]
JSON Schema Validation: A Vocabulary for Structural Validation of JSON. Austin Wright; Henry Andrews; Geraint Luff. IETF. 19 March 2018. Internet-Draft. URL: https://tools.ietf.org/html/draft-handrews-json-schema-validation-01
[LDML]
Unicode Technical Standard #35: Unicode Locale Data Markup Language (LDML). Mark Davis; CLDR Contributors. URL: https://unicode.org/reports/tr35/
[LINKED-DATA]
Linked Data Design Issues. Tim Berners-Lee. W3C. 27 July 2006. W3C-Internal Document. URL: https://www.w3.org/DesignIssues/LinkedData.html
[MQTT]
MQTT Version 3.1.1. Andrew Banks; Rahul Gupta. OASIS. 10 December 2015. OASIS Standard Incorporating Approved Errata 01. URL: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
[OPENAPI]
OpenAPI Specification: Version 3.0.1. Darrel Miller; Jason Harmon; Jeremy Whitlock; Kris Hahn; Marsh Gardiner; Mike Ralphson; Rob Dolin; Ron Ratovsky; Tony Tam. OpenAPI Initiative, Linux Foundation. 7 December 2017. URL: https://swagger.io/specification/
[RDF-SCHEMA]
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
[RFC3966]
The tel URI for Telephone Numbers. H. Schulzrinne. IETF. December 2004. Proposed Standard. URL: https://tools.ietf.org/html/rfc3966
[RFC6068]
The 'mailto' URI Scheme. M. Duerst; L. Masinter; J. Zawinski. IETF. October 2010. Proposed Standard. URL: https://tools.ietf.org/html/rfc6068
[RFC7231]
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
[RIJGERSBERG]
Ontology of Units of Measure and Related Concepts. Hajo Rijgersberg; Mark van Assem; Jan Top. Semantic Web journal, IOS Press. 2013. URL: http://www.semantic-web-journal.net/content/ontology-units-measure-and-related-concepts
[SEMVER]
Semantic Versioning 2.0.0. Tom Preston-Werner. 26 December 2017. URL: https://semver.org/
[SMARTM2M]
ETSI TS 103 264 V2.1.1 (2017-03): SmartM2M; Smart Appliances; Reference Ontology and oneM2M Mapping. ETSI. March 2017. Published. URL: http://www.etsi.org/deliver/etsi_ts/103200_103299/103264/02.01.01_60/ts_103264v020101p.pdf
[string-meta]
Strings on the Web: Language and Direction Metadata. Addison Phillips; Richard Ishida. W3C. 11 June 2019. W3C Working Draft. URL: https://www.w3.org/TR/2019/WD-string-meta-20190611/
[TURTLE]
RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: http://www.w3.org/TR/2014/REC-turtle-20140225/
[VOCAB-SSN]
Semantic Sensor Network Ontology. Armin Haller; Krzysztof Janowicz; Simon Cox; Danh Le Phuoc; Kerry Taylor; Maxime Lefrancois. W3C. 19 October 2017. W3C Recommendation. URL: https://www.w3.org/TR/2017/REC-vocab-ssn-20171019/
[WOT-ARCHITECTURE]
Web of Things (WoT) Architecture. Matthias Kovatsch; Ryuichi Matsukura; Michael Lagally; Toru Kawaguchi; Kunihiko Toumura; Kazuo Kajimoto. W3C. 9 April 2020. URL: https://www.w3.org/TR/2020/REC-wot-architecture-20200409/
[WOT-BINDING-TEMPLATES]
Web of Things (WoT) Binding Templates. Michael Koster; Ege Korkan. W3C. 30 January 2020. W3C Note. URL: https://www.w3.org/TR/2020/NOTE-wot-binding-templates-20200130/
[WOT-SECURITY-GUIDELINES]
Web of Things (WoT) Security and Privacy Guidelines. Elena Reshetova; Michael McCool. W3C. 6 November 2019. URL: https://www.w3.org/TR/2019/NOTE-wot-security-20191106/
[xml]
Extensible Markup Language (XML) 1.0 (Fifth Edition). Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; Francois Yergeau et al. W3C. 26 November 2008. W3C Recommendation. URL: http://www.w3.org/TR/2008/REC-xml-20081126/