JP2019537775A - 分散されたセマンティック記述子に対するセマンティッククエリ - Google Patents

Abstract

現在、分散されたセマンティック記述子（例えば、oneM2M＜semanticDescriptor＞リソース）に対して直接的にセマンティッククエリを処理するための既存の解決策はない。本明細書では、分散されたセマンティック記述子に対するセマンティッククエリのための複数のアプリケーションについて説明する。第１の例示的な方法では、情報が単一のセマンティック記述子内に記憶されている場合のセマンティッククエリが考慮される。第２の例示的な方法では、要求されたか、またはそうでなければ必要とされる情報がセマンティック記述子内に記憶されていない場合のセマンティッククエリが考慮される。第３の例示的な方法では、異なるが関連するセマンティック記述子内に情報が分散されている場合のセマンティッククエリが考慮される。第４の例示的な方法では、異なっており関連もしないか、もしくはピアであるセマンティック記述子内に情報が分散されている場合のセマンティッククエリが考慮される。第５の方法では、既存のセマンティックリソース発見メカニズムの利用による、目標とするリソースからの情報に対する間接的なクエリがあり得る。

Description

（関連出願の相互参照）
本出願は、「分散されたセマンティック記述子に対するセマンティッククエリ処理」と題する２０１６年９月２９日出願の米国仮特許出願第６２／４０１，６４０号の利益を主張する。上記出願の内容は参照により本明細書に組み込まれる。

（セマンティックウェブ）
セマンティックウェブは、ワールドワイドウェブコンソーシアム（World Wide Web Consortium：W3C）による規格を通したウェブの拡張である。この規格は、ウェブ上での共通データフォーマットおよび交換プロトコル、最も基本には、リソース記述フレームワーク（Resource Description Framework：RDF）を促進する。

セマンティックウェブは、データのために特に設計された言語、すなわちリソース記述フレームワーク（RDF）、ウェブオントロジー言語（Web Ontology Language: OWL）、および拡張マークアップ言語（Extensible Markup Language:XML）でパブリッシュすることを伴う。これらの技術を組み合わせて、リンクされたデータのウェブを介してウェブ文書のコンテンツを補足または置換する記述を提供する。したがって、コンテンツはそれ自身を、ウェブアクセス可能データベース内に記憶される記述データとして、または特に、XMLが組み込まれた拡張HTML（Extensible HTML:XHTML）文書、もしくはより多くの場合、別個に記憶されるレイアウトまたはレンダリングの指図を伴う純粋なXML文書におけるマークアップとして現し得る。

（セマンティックウェブスタック）
セマンティックウェブスタックは、図１に示されるように、W3Cによって規定されたセマンティックウェブのアーキテクチャを例示する。コンポーネントの機能および関係は、図１に示され、以下に説明する。XMLは、文書内のコンテンツ構造のための基本的な構文を提供するが、その中に含まれるコンテンツの意味にセマンティクスを関連付けしない。Turtle等の代替構文が存在するため、XMLは現在、ほとんどの場合でセマンティックウェブ技術に必要なコンポーネントではない。Turtleは事実上の業界標準だが、正式な標準化プロセスを経ていない。XMLスキーマは、XML文書内に含まれる要素の構造およびコンテンツを提供および制限するための言語である。RDFは、データモデルを表すための単純な言語であり、主語−述語−目的語、例えば、S-P-OトリプルまたはRDFトリプルの形態でオブジェクト（「ウェブリソース」）およびその関係を参照する。RDFベースのモデルは、種々の構文、例えば、RDF/XML、N3、TurtleおよびRDFaで表され得る。RDFは、セマンティックウェブの基本的な規格である。

RDFグラフは、エッジがRDFトリプルの「述語」を表すのに対し、グラフのノードは、RDFトリプルの「主語」および／または「目的語」を表す有向グラフである。すなわち、RDFトリプルに記述されるリンク構造は、そのような有向RDFグラフを形成する。RDFスキーマ（例えば、RDF Schema 1.1）は、RDFを拡張し、プロパティおよびクラスの一般化された階層のためのセマンティクスを用いてRDFベースのリソースのプロパティおよびクラスを記述するための語彙である。OWLは、プロパティおよびクラス、とりわけ、クラス間の関係（例えば、離接）、基数（例えば、「正確に１つ」）、相等性、より豊富なタイプのプロパティ、プロパティの特性（例えば、対称性）、および列挙されたクラスを記述するために、より多くの語彙を追加する。

SPARQL（例えば、SPARQL1.1）は、ウェブ上またはRDFストア（例えば、セマンティックグラフストア）においてRDFグラフのコンテンツ（例えば、RDFトリプル）をクエリおよび操作するための、セマンティックウェブデータソースのためのプロトコルおよびクエリ言語である。SPARQL1.1クエリ（RDFグラフのためのクエリ言語）は、データがRDFとしてネイティブに記憶されているか、またはミドルウェアを介してRDFとして見なされるかに関わらず、多様なデータソースにわたるクエリを表すために使用され得る。SPARQLは、その論理積および論理和と一緒に、必要とされるグラフパターンおよび随意のグラフパターンをクエリするための機能を含む。SPARQLは、集約、サブクエリ、否定、式による値の作成、拡張値試験、およびソースRDFグラフによるクエリの制約もサポートする。SPARQLクエリの結果は、結果のセットまたはRDFグラフであり得る。SPARQL1.1更新は、RDFグラフのための更新言語である。SPARQL1.1更新は、RDFのためにSPARQLクエリ言語由来の構文を使用する。更新動作は、セマンティックグラフストアにおけるグラフの集合に対して行われる。動作は、セマンティックグラフストア内のRDFグラフを更新、作成、および除去するために提供される。RIFは、W3Cルール交換フォーマットである。RIFは、コンピュータが実行可能なウェブルールを表すためのXML言語である。RIFは、ダイアレクトと呼ばれる複数のバージョンを提供する。ダイアレクトは、RIF基本論理ダイアレクト（RIF Basic Logic Dialect: RIF-BLD）およびRIF生成ルールダイアレクト（RIF Production Rules Dialect: RIF PRD）を含む。

（セマンティック検索とセマンティッククエリ）
リレーショナルデータベースは、データ間の関係を暗示的に含む。例えば、（２つのコンテンツテーブルに記憶され、追加のリンクテーブルと連結された）顧客と製品との関係は、開発者によって書かれたクエリステートメント（例えば、リレーショナルデータベースの場合、SQLが使用される）の中でだけ発生する。クエリを書くには、データベーススキーマに関する正確な知識を必要とする。多くのリレーショナルデータベースは、データをツリー構造に構成した階層型データベースとしてモデル化される。データは、リンクを介して相互結合されたレコードとして記憶される。階層型データベースモデルにおけるレコードは、リレーショナルデータベースモデルにおける行（またはタプル）に対応し、エンティティタイプはテーブル（または関係、たとえば、親と子の関係）に対応する。レコードの検索またはクエリは、SQLまたは非SQL検索エンジンによって実行され得る。

図２に示すように、階層型データベースでは、各子レコードは１つの親レコードしか持てないが、各親レコードは１つまたは複数の子レコードを持つことができる。階層型データベースからデータを読み出すには、ルートノードから始めて、ツリー全体をトラバースする必要がある。この構造は単純であるが、関係が一対多の関係に限られるため、柔軟性に欠ける。

リンクトデータは、データ間のすべての関係を明示的に含む。リレーショナルデータベースに関して説明された上記例では、クエリコードを書く必要はない。各顧客のための正しい製品を自動的にフェッチすることができる。この簡単な例は取るに足りないものであるが、情報のネットワーク（顧客に関しては都市、州、および国家等の地理空間情報、製品に関しては下位および上位カテゴリー内のカテゴリー）が作成されると、リンクトデータは真価を発揮し始める。すると、システムは、特定の場所と製品カテゴリーの結びつきを探すさらに複雑なクエリや分析に自動的に回答することができる。このクエリに対する開発努力については省略される。セマンティッククエリは、情報のネットワークのウォークと、一致の検索（データグラフトラバーサルとも呼ばれる）をすることによって、実行される。

セマンティック検索は、検索者の意図と、ウェブ上であるかクローズドシステム内であるかに関わらず、検索可能なデータ空間内に現れるときの文脈上の意味とを理解することによって検索精度を改善して、より関連性の高い結果を生成しようとする。セマンティック検索システムは、検索の文脈、場所、意図、ならびに単語、同義語、一般化および特殊クエリ、概念一致、および自然言語クエリの変形例を含む種々の点を考慮し、関連する検索結果を提供する。GoogleおよびBingのような主要なウェブ検索エンジンは、セマンティック検索のいくつかの要素を取り込んでいる。セマンティック検索は、セマンティクスを使用して、非常に関連性の高い検索結果を生成する。ほとんどの場合、その目標は、大まかに関連したキーワード結果のリストをユーザに分類させるのではなく、ユーザがクエリした情報を届けることである。例えば、セマンティクスは、階層型リレーショナルデータベース内のレコード検索またはクエリを強化するために使用され得る。

セマンティッククエリは、連想的および文脈的性質のクエリおよび分析を可能にする。セマンティッククエリは、データ内に含まれる構文情報、セマンティック情報および構造情報に基づいて、明示的に導かれる情報および暗示的に導かれる情報の両方の読み出しを可能にする。セマンティッククエリは、正確な結果（おそらく、ただ１つの情報の独特の選択）を届けるように、またはパターン照合およびデジタル推論を通してよりファジィかつ制限のない質問に回答するように設計される。

セマンティッククエリは、名前付きグラフ、リンクされたデータまたはトリプルに働きかける。このことにより、クエリが、情報間の実際の関係を処理し、データのネットワークからの回答を推測することを可能にする。これは、セマンティック検索とは対照的であり、セマンティック検索は、セマンティックを非構造化されたテキストにおいて使用し、より良好な検索結果を生成する（例えば、自然言語処理）。

技術的観点から、セマンティッククエリは、データベースクエリとよく似た正確なリレーション型の動作である。セマンティッククエリは、構造化されたデータに働きかける。したがって、演算子（例えば、＞、＜、および＝）、名前空間、パターン照合、サブクラス化、推移関係、セマンティックルール、および文脈全文検索のような広範囲の特徴を利用する可能性を有する。W3Cのセマンティックウェブ技術スタックは、セマンティッククエリをSQLに類似した構文で公式化するためのSPARQLを提供する。セマンティッククエリは、トリプルストア、グラフデータベース、セマンティックウィキ、自然言語および人工知能システムにおいて使用される。

セマンティッククエリの別の側面は、関係のタイプをシステムへの知能の組み込みに使用し得ることである。顧客と製品との関係は、近隣地域とその都市との関係とは基本的に異なる性質を有する。後者は、セマンティッククエリエンジンが、マンハッタンに住んでいる顧客がニューヨーク市にも住んでいることを推測することを可能にする一方、他の関係は、より複雑なパターンおよび「文脈分析」を有し得る。このプロセスは、推測または推論と呼ばれ、所与の事実に基づいて新しい情報を導くためのソフトウェアの能力である。

（oneM2M機能アーキテクチャ）
開発中のoneM2M規格（oneＭ2Ｍ-TS-0001 oneＭ2Ｍ Functional Architecture-V2.9.0）は、「共通サービスエンティティ（Common Service Entity:CSE）」と呼ばれるサービス層を定義する。サービス層の目的は、異なる「垂直」M2Mシステムおよびアプリケーションによって利用可能な「水平」サービスを提供することである。CSEは、図３に示すような参照点をサポートする。Mca参照点は、アプリケーションエンティティ（Application Entity:AE）とインタフェースする。Mcc参照点は、同一サービスプロバイダドメイン内の別のCSEとインタフェースし、Mcc’参照点は、異なるサービスプロバイダドメイン内の別のCSEとインタフェースする。Mcn参照点は、下層のネットワークサービスエンティティ（Network Service Entity:NSE）とインタフェースする。NSEは、デバイス管理、ロケーションサービスおよびデバイストリガリング等の下層ネットワークサービスをCSEに提供する。

CSEは、「発見」、「データ管理およびリポジトリ」等の共通サービス機能（Common Service Function: CSF）と呼ばれる、複数の論理機能を含む。図４は、oneM2Mによって規定されるCSFをいくつか図示している。

oneM2Mアーキテクチャは、図３に示すようなタイプのノードを可能にする。アプリケーションサービスノード（Application Service Node: ASN）は、１つのCSEを含みかつ少なくとも１つのアプリケーションエンティティ（AE）を含むノードである。ASNは、M2Mエンドデバイス内に常駐し得る。アプリケーション専用ノード（Application Dedicated Node: ADN）は、少なくとも１つのAEを含むが、CSEを含まないノードである。ゼロ以上のADNが、oneM2Mシステムのフィールドドメイン内に存在し得る。物理的マッピングの例：アプリケーション専用ノードは、制約付きM2Mデバイス内に常駐し得る。中間ノード（Middle Node: MN）は、１つのCSEを含みかつゼロ以上のAEを含むノードである。ゼロ以上のMNが、oneM2Mシステムのフィールドドメイン内に存在し得る。MNは、M2Mゲートウェイ内に常駐し得る。インフラストラクチャノード（Infrastructure Node: IN）は、１つのCSEを含みかつゼロ以上のAEを含むノードである。INは、oneM2Mサービスプロバイダごとにインフラストラクチャドメイン内に１つだけ存在する。IN内のCSEは、他のノードタイプには適用できないCSE機能を含み得る。物理的マッピングの例：INは、M2Mサービスインフラストラクチャ内に常駐し得る。非oneM2Mノード（Non-oneM2M Node: NoDN）は、oneM2Mエンティティ（AEまたはCSEのいずれでもない）を含まないノードである。このようなノードは、管理を含む、インターワーク目的のために、oneM2Mシステムにアタッチされたデバイスを表す。

（oneM2Mにおけるセマンティクスの適用性検討）
図５に示す＜semanticDescriptor＞リソースは、リソースおよび場合によりサブリソースに関するセマンティック記述を記憶するために使用される。このような記述は、オントロジーに従って提供され得る。セマンティック情報は、oneM2Mシステムのセマンティック機能によって使用され、アプリケーションまたはCSEにも使用される。＜semanticDescriptor＞リソースは、表１に規定される属性を含むものとする。

（oneM2Mのセマンティックフィルタリングの提案）
一般フィルタリングは、要求動作に規定されたフィルタ基準を有することによってサポートされる（oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0 第8.1.2節）。セマンティックフィルタリングを提供するために、要求動作フィルタ基準のための追加の値がoneM2M TR-0007-Study_on_Abstraction_and_Semantics_Enablement-V2.11.0 第8.5.4節に提案されており、その定義を下表に示す。複数のインスタンスを使用することができ、これは、フィルタ基準を評価するための一般的ルールに従い、「OR」セマンティクスが適用され、例えば、セマンティックフィルタのうちの１つまたは複数がセマンティック記述に一致する場合、セマンティックフィルタ基準のための総合的な結果が真であることを意味する。下表のセマンティクスは、oneM2M TR-0007-Study_on_Abstraction_and_Semantics_Enablement-V2.11.0に定義され、oneM2M-TS-0001 oneM2M Functional Architecture-V2.9.0の要求パラメータsemanticFilterに対応することに留意されたい。semanticFilterパラメータに含まれるSPAQRLクエリが、親リソースの＜semanticDescriptor＞子リソースのうちの１つのセマンティックトリプルと一致する場合、これは、このセマンティックフィルタリングが成功しており、対応する親リソースは返されることを意味する。

上記の提案は、以下の仮定を使用する：セマンティック記述は、RDFトリプル（表現、例えば、RDF/XML、Turtle、oneM2M内にまだ完全に規定されていない記述フォーマット）として規定され、セマンティックフィルタ基準は、セマンティック記述に対して実行されるべきSPARQL要求のために使用されるであろう。

以下は、oneM2M TR-0007に示されているセマンティックフィルタリング例である。

これは、my：myDevice1によって記述されるAEリソースは結果セットに含まれるが、my：myDevice2によって記述されるAEリソースは含まれないことを意味する。

場合によっては、１回の検索のための関連セマンティック情報は、異なる＜semanticDescriptor＞リソース間に分散されている場合がある。図６で与えられる例はこの場合を示す。ボックスは、セマンティックフィルタの範囲を表し、例えば、このボックスは、それを評価するために必要な情報である。主語−述語−目的語関係を表すセマンティックグラフが図示されており、このグラフの異なる部分（楕円で表される）は異なる＜semanticDescriptor＞リソースに記憶されている。セマンティックフィルタリングは、完全なセマンティックグラフ（の一部）に適用される必要があり、このことにより、グラフのいくつかの異なる部分をセマンティック動作の実行のために一緒にする必要があるという問題が生じる。

この問題は概して、セマンティックウェブの領域では明らかではない。クラスインスタンスを識別するURIが直接デリファレンスし得ることから、概念（例えば、クラス、関係）情報をそのURIに基づいて発見し得るからである。oneM2Mの場合、アクセスされ得るリソースおよびセマンティクスのみが、リソースのコンテンツとして記憶される。

現在SPARQL1.1は、SERVICEキーワードを使用してフェデレーテッドクエリをサポートし、遠隔SPARQLエンドポイントのURLが指定され得る。このアプローチに関して、要求側は、どのセマンティック記述子が検索に要求されるセマンティックインスタンスを含むかを予め把握しているであろう。したがって、セマンティック記述子がリソースツリー内に分散されている場合、このアプローチは一般に適用できなくなる。

提示される＜semanticDescriptor＞リソースをまたいで記憶されているセマンティック記述に対してセマンティックフィルタリングを可能にするための解決策は、resourceDescriptorLink OWL注釈プロパティの形態で注釈リンクを導入する。この注釈プロパティは、任意のクラスインスタンスのために指定でき、その値は、＜semanticDescriptor＞リソースのURLであり、所与のクラスインスタンスのための追加のRDFトリプルが見出され得る。以下の例は、図８のグラフを作成するために、oneM2Mベースオントロジー（図７）に定義されたクラスおよび関係を用いる。

この解決策は、受信側におけるSPARQLベースのセマンティックフィルタリングエンジンのための以下の機能フローを伴う：
・SPARQL要求として公式化されるセマンティックフィルタは、候補リソースのセマンティック記述子リソースのコンテンツに対して実行される。
・実行の過程で、１つまたは複数のresourceDescriptorLink注釈を伴うクラスインスタンスに遭遇した場合、実行は停止される。
・resourceDescriptorLinkが参照する＜semanticDescriptor＞リソースの各々のコンテンツが、SPARQL要求が実行されているコンテンツに追加される
・SPARQL要求の実行が、拡大されたコンテンツに対して継続される。

（oneM2M文脈中のセマンティックフィルタリング／発見とセマンティッククエリ）
oneM2Mは、セマンティックフィルタを通して、セマンティックリソース発見をサポートする。一般に、セマンティッククエリは、連想的および文脈的性質のクエリおよび分析を可能にする。セマンティッククエリは、データ内に含まれる構文情報、セマンティック情報、または構造情報に基づいて、明示的に導かれる情報および暗示的に導かれる情報の両方の読み出しを可能にする。

以下は、セマンティッククエリとセマンティックリソース発見の相違点をまとめたものである。セマンティッククエリは、RDFデータインフラストラクチャに関する有用な知識を抽出するものである。セマンティックリソース発見は、リソースのセマンティックメタデータおよびセマンティックフィルタに基づいてリソースを発見してリソースURIを返すことを目標としている（セマンティッククエリは、リソースURIを返すこともでき、例えば、セマンティックリソース発見以上のことをすることができることに留意されたい）。図９は、種々のセマンティッククエリのクエリ結果の例を示す。図９に示す例として、クエリ３はホームページに対するクエリを行い、このクエリに対するリターン結果は一組のリソースURI（例えば、ホームページアドレス）である。セマンティッククエリは、トリプルストアのようなセマンティック中心のインフラストラクチャとより関連し、一方、セマンティックリソース発見は、サービス層内で定義されるoneM2Mリソースツリーのようなリソースツリーインフラストラクチャとより関連している。セマンティッククエリは、リソースのURIのみならず、「知識」の観点における任意のフォーマットのクエリ結果を返すことができる。

セマンティッククエリは、データ（例えば、RDFトリプルの観点における）内に含まれる構文情報、セマンティック情報、および構造情報に基づいて、明示的に導かれる情報／知識および暗示的に導かれる情報／知識の両方の読み出しを可能にする。現在、oneM2M文脈において、セマンティック関連の特徴をサポートするための主として２つのアーキテクチャ選択肢があるが、１つは、集中型アプローチであり、そこでは、システム中に集中的トリプルストアがあり、セマンティック処理、例えば、セマンティッククエリが集中的トリプルストアに対して実行される。もう１つは、トリプルはリソースツリー内に分散され、異なる＜semanticDescriptor＞リソース内に記憶されるという意味で、分散型アプローチである。

現時点では、分散されたセマンティック記述子（例えば、oneM2M＜semanticDescriptor＞リソース）に対して直接セマンティッククエリ処理を行うための既存の解決策は存在しない。本明細書では、分散されたセマンティック記述子に対するセマンティッククエリのための複数のアプリケーションについて説明する。第１の例示的な方法では、情報が単一のセマンティック記述子内に記憶されている場合のセマンティッククエリを考える。第２の例示的な方法では、要求または他の方法で必要とされる情報がセマンティック記述子内に記憶されていない場合のセマンティッククエリを考える。第３の例示的な方法では、異なるが関連するセマンティック記述子内に情報が分散されている場合のセマンティッククエリを考える。第４の例示的な方法では、異なっており関連もしないか、もしくはピア（peer）セマンティック記述子内に情報が分散されている場合のセマンティッククエリを考える。第５の方法では、既存のセマンティックリソース発見メカニズムの利用による、目標とするリソースからの情報に対する間接的なクエリがあり得る。

この概要は、発明を実施するための形態において以下でさらに説明される概念の選択を簡単な形式で紹介するために提供されている。この概要は、特許請求される主題の重要な特徴または本質的な特徴を特定することを意図しておらず、また特許請求される主題の範囲を限定するために用いられることを意図していない。さらに、特許請求される主題は、本開示の任意の部分に記述される任意のまたはすべての不都合を解決する制限に限定されない。

添付の図面と共に例として示される以下の説明から、より詳細な理解を得ることができる。

図１は、セマンティックウェブのアーキテクチャを示す。 図２は、例示的な階層型データベースを示す。 図３は、oneM2Mアーキテクチャを示す。 図４は、oneM2M共通サービス機能を示す。 図５は、リソースツリー中の＜semanticDescriptor＞リソースの構造を示す。 図６は、異なるリソース内に記憶されたセマンティック情報を横切るセマンティックフィルタの範囲例を示す。 図７は、例示的なoneM2Mベースオントロジーを示す。 図８は、例示的なresourceDescriptionLinkを示す。 図９は、ワールドワイドウェブコンソーシアムによって提供されるセマンティッククエリの例示的なクエリ結果を示す。 図１０は、セマンティック層によって制御される、階層化された構造内のアクセス制御を示す。 図１１は、第１シナリオに対するセマンティッククエリ処理の手順を示す。 図１２は、＜semanticDescriptor＞リソース内に記憶されていないセマンティッククエリ要求情報を示す。 図１３は、シナリオ２Ａに対する新情報のためにRDFトリプルを作成／記憶する方法に関するオプション１を示す。 図１４は、シナリオ２Ａのオプション１に対する情報クローン化手順を示す。 図１５は、シナリオ２Ａのオプション１に対するセマンティッククエリ処理手順を示す。 図１６は、シナリオ２Ａのオプション１に対する、オンデマンド情報クローン化に基づく代替的なセマンティッククエリ処理手順を示す。 図１７は、シナリオ２Ａの新情報のためにRDFトリプルを作成／記憶する方法に関するオプション２を示す。 図１８は、シナリオ２Ａのオプション２に対する情報クローン化手順を示す。 図１９は、シナリオ２Ｂを示す。 図２０は、シナリオ２Ｂに対する情報リンク手順を示す。 図２１は、シナリオ２Ｂに対するセマンティッククエリ処理手順を示す。 図２２は、異なるが関連する＜semanticDescriptor＞リソース内に分散されているセマンティッククエリ要求情報のための例示的なシナリオを示す。 図２３は、第３シナリオを示す。 図２４は、第３シナリオに対するセマンティッククエリ処理手順を示す。 図２５は、異なっており関連もしない＜semanticDescriptor＞リソース内に分散されているセマンティッククエリ要求情報を示す。 図２６は、シナリオ４に対するセマンティッククエリ処理のための関連リソースを示す。 図２７は、シナリオ４の基本解決策のためのセマンティッククエリ処理手順を示す。 図２８は、異なるクエリ範囲を示す。 図２９は、シナリオ４のより強力な解決策のアプローチ１のためのセマンティッククエリ処理手順を示す。 図３０は、シナリオ４に対する解決策Ｂにおけるアプローチ２の動作の詳細を示す。 図３１は、シナリオ４のより強力な解決策のアプローチ２のためのセマンティッククエリ処理手順を示す。 図３２は、既存のセマンティックリソース発見メカニズムの利用による、目標とするリソースからの間接的クエリ情報を示す。 図３３は、シナリオ５Ａに対するセマンティッククエリ処理手順を示す。 図３４は、シナリオ５Ｂに対するセマンティッククエリ処理手順を示す。 図３５は、oneM2Mサービス層のためのDAS CSFを示す。 図３６は、＜QueryPortal＞リソースを示す。 図３７は、＜QueryPortal＞リソースを通じた、シナリオ４に対するセマンティッククエリ処理のためのoneM2M中心の手順を示す。 図３８は、セマンティッククエリ範囲チェッカのための例示的なユーザインタフェースを示す。 図３９は、セマンティッククエリランチャのための例示的なユーザインタフェースを示す。 図４０は、セマンティッククエリ結果表示のための例示的なユーザインタフェースを示す。 図４１Ａは、本発明を実現し得る例示的なマシンツーマシン（Machine-to-Machine: M2M）またはモノのインターネット（Internet of Things: IoT）通信システムを示す。 図４１Ｂは、図４１Ａに図示されたM2M/IoT通信システム内で用い得る例示的なアーキテクチャを示す。 図４１Ｃは、図４１Ａに図示された通信システム内で使用し得る例示的なM2M/IoT端末またはゲートウェイデバイスを示す。 図４１Ｄは、図４１Ａの通信システムの態様を具現化し得る例示的なコンピューティングシステムを示す。

現在、oneM2M文脈において、セマンティック関連の特徴をサポートするための主として２つのアーキテクチャ選択肢があるが、１つは、集中型アプローチであり、そこでは、システム中に集中的トリプルストアがあり、セマンティック処理、例えば、セマンティッククエリがトリプルストアに対して実行される。言い換えれば、集中的トリプルストアがあり、この集中的トリプルストアには、セマンティック処理の大半をサポートするために、RDFトリプルが記憶されている。もう１つは、トリプルはリソースツリー内に分散され、異なる＜semanticDescriptor＞リソース内に記憶されるという意味で、分散型アプローチである。それらの＜semanticDescriptor＞リソースは、通常のoneM2Mリソースの子リソースであることが多く、主としてセマンティック注釈の目的のために役立ち、さらに、セマンティックリソース発見を可能にすることができる。特に、この分散型アプローチにおいて、各CSEは、異なる＜semanticDescriptor＞リソースから情報を集めて、それに対してセマンティック処理を施すために、局所的／一時的なトリプルストアを形成する必要がある。

開示される、分散されたセマンティック記述子に対するセマンティッククエリのための方法およびシステムに文脈を与え得る複数のシナリオがある。シナリオのうちのいくつかは、以下を含む：１）ただ１つの＜semanticDescriptor＞リソースからの情報、２）セマンティッククエリは、＜semanticDescriptor＞リソース内に記憶されていない情報を要求する、３）セマンティッククエリは、分散されているが異なる＜semanticDescriptor＞リソース内に記憶されている可能性のある情報を要求する、４）異なっており関連もしない＜semanticDescriptor＞リソース内に分散されているセマンティッククエリ要求情報、または５）既存のセマンティックリソース発見メカニズムの利用による、目標とするリソースからの情報に対する間接的なクエリ。上記シナリオ中で用いられるような、分散型セマンティッククエリのために用い得る方法、システムおよび装置を以下に説明する。シナリオについて、以下にさらに詳細に説明する。

本明細書に例示されるステップを実行する、図１０〜図３７中のエンティティのようなエンティティは論理エンティティであり得ることが理解される。ステップは、図４１Ｃまたは図４１Ｄに図示されるようなデバイス、サーバ、またはコンピュータシステムのメモリ内に記憶され、プロセッサ上で実行され得る。一例においては、M2Mデバイスの相互作用に関して以下でさらに詳述するが、図３７のAE２９５は、図４１ＡのM2M端末デバイス１８上に常駐することができ、一方、図３７のCSE２９６は、図４１ＡのM2Mゲートウェイデバイス１４上に常駐することができる。

表３は、本明細書で使用する一般的に用いられる用語の定義を提供する。

第１シナリオに関して、図１０は、部分的リソースツリー構造を示し、そこでは、＜Device＞１１１は、operation１１４、operation１１５、および、RDFトリプルの意味において関連するセマンティック記述を含む子である＜semanticDescriptor＞１１６リソースを有する温度センサを表す。＜semanticDescriptor＞１１６リソース内に記憶されているRDFトリプルは、論理的に、ブロック１１０内のグラフと見なすことができる。クエリ記述の意図は以下の通りであり得る：「デバイス＜Device＞１１１によってサポートされている動作の数を返すこと。」SPARQL表現を以下のようにすることができる：
SELECT SUM (?operation)
WHERE { ?device rdf:type base:Device.
?device base:hasService ?service.
?service base:hasOperation ?operation.
}

このクエリを処理する方法に関して詳細に規定したものは（例えば、oneM2Mの中に）従来存在しない。図１１は、第１シナリオに対するセマンティッククエリ処理のための例示的方法を示す。ステップ１３０で、SQI１２１は、RH-SLN１２２に関する何らかの情報を問い合わせたい。そこで、SQI１２１は、その質問を記述するために、上記のようなSPARQLクエリステートメントを作成する。サービス層セマンティッククエリイニシエータ（SQI）１２１は、セマンティッククエリを開始する論理エンティティであり得る。リソースホスティングサービス層ノード（RH-SLN）１２２は、RESTfulアーキテクチャで構築されるサービス層ノードであり得る。RH-SLN１２２のサービス層は、リソースツリーを操作インタフェースとして公開することができる。

ステップ１３１で、SQI１２１は、要求がセマンティッククエリに関するものであることを示す要求メッセージをRH-SLN１２２に送信する。メッセージは、さらに詳細には後述する以下のパラメータを含み得る：セマンティッククエリインジケータ（SQ）、単一リソース評価インジケータ（SE）、クエリステートメント（QS）、または結果フォーマット（RF）。SQは、ステップ１３１のSQI１２１からの要求は実行すべきセマンティッククエリであることを示し得る情報を含む。言い換えれば、SQは、要求がセマンティックリソース発見のためのものではなく、RDFトリプルに基づいている可能性がある何らかの派生情報または知識を、意味論的に問い合わせまたは読み出すためのものであることを示す。ＳＥは、このクエリが単一の＜semanticDescriptor＞リソースに適用されるべきであることを示すことができる。例えば、この要求メッセージの「To」パラメータが＜semanticDescriptor＞リソースを直接対象にしている場合、この＜semanticDescriptor＞リソースが、セマンティッククエリが実行されるリソースとなる。しかし、この要求メッセージの「To」パラメータが通常のリソースを直接対象にしている場合、そのすぐ隣または最も近い＜semanticDescriptor＞子リソースが、セマンティッククエリが実行されるリソースとなる。SQI１２１が、ただ１つの＜semanticDescriptor＞リソースに対するセマンティッククエリの実行を意図する場合、適切な値のSEパラメータを要求メッセージに含めなければならないという必要性があり得る。言い換えれば、特定の値のSEパラメータが要求メッセージに含まれていない場合、初期設定の範囲は、この要求メッセージの「To」パラメータによって示されるようなURIのすべての子リソースであり得る（この状況については第４シナリオに関する説明で触れる）。QSは、SQI１２１によって指定されたクエリステートメントを記憶する。このクエリステートメントはSPARQLクエリステートメントであり得る。あるいは、SQI１２１は、そのクエリをセマンティクスfilterCriteriaに入れて伝達することもできる。RFは、クエリ結果を、どのように表現すべきかを示す。表現は、プレーンテキスト、JSON、またはXMLフォーマットとすることができる。前述の例を用いて、SQ、SE、QS、およびRFの値の例を以下に示す：
SQ=1 //「１」は、これがセマンティッククエリの要求であることを示す。
SE=1 //「１」は、このクエリがただ１つのリソースを対象にすることを示す。
QS= SELECT SUM (?operation)
WHERE { ?device rdf:type base:Device .
?device base:hasService ?service .
?service base:hasOperation ?operation .
}
RF=JSON //クエリ結果をJSONフォーマットにすることを指示する。

図１１を引き続き参照して、ステップ１３２で、RH-SLN１２２は、SQI１２１から要求を受信し、開始点から、SQI１２１に指示されたように、セマンティッククエリ処理を実行する。「To」パラメータに基づいて、対象となる＜semanticDescriptor＞リソースがクエリを受ける。対象となる＜semanticDescriptor＞リソースが特定されると、対象となる＜semanticDescriptor＞リソース上でセマンティッククエリが実行され、クエリ結果が生成される。ステップ１３２で、RH-SLN１２２は応答メッセージをSQI１２１に送信する。応答メッセージには、SQI１２１によって示されたフォーマットを用いたクエリ結果が含まれている。

第２シナリオに関して、図１２は、部分的リソースツリー構造を示し、そこでは、＜Device＞１１１は、温度センサを表し、その子である＜semanticDescriptor＞１１６リソースは、RDFトリプルの意味において関連するセマンティック記述を含む。＜reading＞１１３は、最新の温度読取値を記憶する＜contentInstance＞リソースであり、この＜reading＞１１３のコンテンツ属性１１７には値「３２」が記憶されている。＜contentInstance＞リソースは、＜container＞リソース内のデータインスタンスを表すことができる。セマンティッククエリは、＜semanticDescriptor＞リソース内に記憶されていない情報の読み出しに関連付けることができる。例えば、情報によっては、RDFトリプルとして表され得ず、通常のリソースに記憶されているだけである可能性がある。ここで、通常リソースとは、基本的に、＜semanticDescriptor＞リソース以外のリソースのことであり、例えば、oneM2M文脈中では＜CSE＞、＜AE＞、＜container＞等のリソースであり得る。クエリ記述の意図は以下の通りであり得る：「現在の温度が２０を超えるセンサを返すこと。」
SELECT ?device
WHERE { ?device rdf:type base:Device .
?device base:hasService ?service .
?service base:hasOperation ?operatoin
?operation base:hasOutput ?output
?output hasCurrentValue ?tempValue .
FILTER (?tempValue temp:hasValue >= 20)
}

上記クエリを、＜Device＞１１１の＜semanticDescriptor＞リソースに対して直接適用した場合、従来は、SPARQL内の「FILTER (?tempValue temp:hasValue >= 20)」を満たすことができないため、結果が返されない可能性がある。その理由は、現時点では、温度値がRDFトリプルとして＜semanticDescriptor＞リソース内に記憶されていないためである。このことは、RDF形式で記憶された情報は、そのほとんどがメタデータ記述であるため、ほとんど静的であるという意味で、既存のセマンティックインフラストラクチャの典型的な特性を表している。それと比べて、動的データはリソースツリー内に記憶されることが多い。例えば、図１２に示すように、＜Device＞１１１のセマンティック記述では、OutputX１１８が温度状況を記述していると記述しているが、OutputX１１８の現在値（例えば、Device１１１の現在温度値）は、この情報は時間と共に変化するため、RDFトリプルとして直接記述されず、この＜semanticDescriptor＞リソースに記憶されていない。本明細書に開示されているように、「複数トリプル」と表示されている場合、１つの「トリプル」の場合もありうると考えられる。

第２シナリオを参照すると、それに対処するために検討すべきことは複数ある。本明細書では、第２シナリオに関して、検討すべきことはシナリオ２Ａおよびシナリオ２Ｂによって示される。本明細書で開示される複数の例示的な特徴、例えば、＜contentInstance＞リソースのコンテンツ属性内に記憶されているデータコンテンツは、RDFトリプルとして表現し直して、＜semanticDescriptor＞リソース内に記憶することもできる。さらに、新しい属性は、データコンテンツがRDFトリプルとして表現し直されているか否かを示し得る。「resourceDescriptorLink」プロパティの使用は、２つの＜semanticDescriptor＞リソースをリンクするだけでなく、＜semanticDescriptor＞リソースと通常のoneM2M contentInstanceリソース間をリンクするようにも拡張することができる。

シナリオ２Ａでは、本来は＜semanticDescriptor＞リソース内では利用できない情報、例えば、本来は＜reading＞１１３リソースのコンテンツ属性１１７だけに記憶されていた温度値を表すために、一般的により多くのRDFトリプルを追加することが検討される。言い換えれば、元々は通常のリソースに記憶されていた情報は、RDFトリプルとして表現され、特定の＜semanticDescriptor＞リソース内に記憶されることができる。注目すべきことは、シナリオ２Ａでは、クエリ処理に加えて、通常のリソースに記憶されている元の情報に対するいかなる変更（例えば、元の情報の作成、修正、削除、更新等）も、この情報がRDFトリプルとして表され、特定の＜semanticDescriptor＞リソース内に記憶されていた場合は、関連する＜semanticDescriptor＞リソースに対しても影響を及ぼすべきであるという意味で、RDFトリプルに対する保守手順もあるということである。この保守関連処理をサポートするために、いくつかの既存の解決策を使用することができる。

シナリオ２Ａの重要な問題は、トリプルをどこに記憶するかということである。代替的な実施オプションを以下に論じる。シナリオ２Ａに関連する第１オプションでは、通常のリソースからの情報（例えば、図１６中にあるような、＜reading＞１１３リソースに記憶されている現在温度値３２）については、＜reading＞１１３リソースが、現在、＜semanticDescriptor＞子リソースを有していない場合、RH-SLN１２２は、その情報を表す新しいRDFトリプルを記憶するため、新しい＜semanticDescriptor＞子リソース（例えば、＜semanticDescriptor＞１１９）を＜reading＞１１３リソースに対して作成する。一方、この新しい＜semanticDescriptor＞１１９リソースは、「resourceDescriptorLink」プロパティ、または既存の＜semanticDescriptor＞リソースの「relatedSemantics」属性を用いて、他の既存の＜semanticDescriptor＞リソース （例えば、＜semanticDescriptor＞１１６リソース）とリンクする必要がある。

図１３は、第１オプションがシナリオ２Ａに対していかに有効であるかを示すのに役立つ。ブロック１４０を参照されたい。図に見られるように、この＜reading＞１１３リソースの作成に沿って、＜reading＞１１３に対して新しい＜semanticDescriptor＞子リソースが作成される。一方、以下に論じるように、「TemperatureValue」ノード１４１を介して２つの＜semanticDescriptor＞リソースを共にリンクするために「resourceDescriptorLink」プロパティをさらに使用できるように、いくつかの新しいトリプルも＜Device＞１２１の＜semanticDescriptor＞子リソース内に作成される。

オプション１では、本来はRDFトリプルとして記憶されていない情報をクローン化することが主な作業であることに留意されたい。ここで、クローン化の意味は、以前は通常のリソースにのみ記憶されていた情報を複製し、RDFトリプルとして表すことである。特に、RH-SLN１２２がクローン化する必要のある新しい情報を受信する限り、クローン化プロセスを実行する必要がある。例示的な情報クローン化プロセスを、図１４に示すような手順として説明し、図１３に示す例を用いて、以下に詳述する。

ステップ１５０で、Device１１１はM2M温度デバイスであり、RH-SLN１２２に登録済みであり、自身の読取値をRH-SLN１２２に送信することができる。RH-SLN１２２上の＜Device＞１１１リソースは、そのセマンティック記述を含む＜semanticDescriptor＞１１６子リソースを有する。ステップ１５１で、Device１１１は新しい読取値をRH-SLN１２２に送信する。

ステップ１５２で、新しい読取値がDevice１１１から取得される（例えば、受信される）と、データは＜contentInstance＞リソース、例えば、図１３に示すように＜reading＞１１３リソースに記憶され得る。一方、この＜reading＞１１３リソースの作成に伴い、完了すべき複数のアクションがある。ステップ１５２に関する第１アクションでは、＜reading＞１１３リソースに対して、関連する＜semanticDescriptor＞リソースも作成される。例えば、現在の読取値（例えば、値３２）は、RDFトリプルとして表され、この新しく作成された＜semanticDescriptor＞１１９リソース内に記憶され得る。図１３の例に示すように、新しく作成された＜semanticDescriptor＞１１９リソースのセマンティックグラフには、２つのリンクを持つ「TemperatureValue」ノード１４２がある。１つのリンクは、このノードの値が「３２」であることを表すもので、もう１つのリンクは、温度の単位が摂氏であることを示すものである。このステップでは、RH-SLN１２２は、適切なRDFトリプルを生成するために、特定の知能を持っていることに留意されたい。例えば、Device１１１が読取値を送信するとき、読取値が摂氏の単位であることをRH-SLN１２２が認識できるように示すために、何らかのセマンティックメタデータを含むこともできる。あるいは、そのような情報が＜reading＞１１３の親である＜container＞リソース（例えば、＜OutputX＞１１８リソース）のセマンティック記述子に既に記憶されている場合、この情報もRH-SLN１２２によって参照される。別のアプローチとして、RH-SLN１２２は、このデバイスのセマンティック記述に基づいてデバイスの読取値の単位を決めるために、セマンティック推論を用いることもできる（例えば、会社Ａによって製造されたデバイスのすべてが摂氏を用いるよう初期設定されている）。セマンティック記述を、このデバイスのsemanticDescriptor子リソース内に記憶されている情報（例えば、RDFトリプル）と見なすことができる。

図１４のステップ１５２の下での第２アクションでは、resourceDescriptorLinkを利用して、この新しく作成された＜semanticDescriptor＞１１９リソースを別の＜semanticDescriptor＞リソース（例えば、＜semanticDescriptor＞１１６リソース）にリンクするために、２つの＜semanticDescriptor＞リソースを重複させる必要がある（例えば、重複ノード）。しかし、図１３に示すように、＜Device＞１１１の＜semanticDescriptor＞１１６リソースは、新しく作成された＜semanticDescriptor＞１１９リソースと重複するいかなるノードも持っていない。したがって、次のステップは、＜Device＞１１１の＜semanticDescriptor＞１１６リソースに対するフック（例えば、リンクする方法）として、いくつかの新しいトリプルを追加することである。図１３に見られるように、「hasCurrentValue」プロパティを介してOutputX１１８ノードにリンクされた「TemperatureValue」ノード１４１も追加される。「TemperatureValue」ノード１４１はトリプル内の値である。例えば、TemperatureValue（主語部分）は３２（目的語部分）をhasValue（述語部分）。TemperatureValueは主語部分にある。＜Device＞１１１の＜semanticDescriptor＞リソース内には、以前の時間単位の読取値を参照する「TemperatureValue」ノード１４１が既に存在し得るという可能性に留意されたい。その場合、新しい「TemperatureValue」ノードを＜Device＞１１１の＜semanticDescriptor＞リソース内に追加する必要はなく、その代わり、resourceDescriptorLinkを、新しく作成された＜reading＞１１３の＜semanticDescriptor＞１１９リソースを参照するように変更することができるように、「TemperatureValue」ノード１４１のresourceDescriptorLinkプロパティと関連するトリプルを単に修正する。

第２アクションを引き続き参照して、各RDFトリプル（S,P,O）では、各部分はURIを通じて参照されることを理解されたい。各oneM2Mリソースが固有のURIを持つのと同様に、与えられたトリプルの主語、述語、または目的語の部分に現れたエンティティも固有のURIを持つ。２つの＜semanticDescriptor＞リソース内の「TemperatureValue」ノード（ノード１４１およびノード１４２）のURIに値を割り当てることに関して、以下のオプションを検討することができる。第１オプションは、現在の＜reading＞１１３のURIの使用に関する。この場合、新しい読取値が受信されるたびに、＜Device＞１１１の＜semanticDescriptor＞リソース内に現れた既存「TemperatureValue」ノード１４１のURIが更新され、新しく受信した読取値を記憶しているリソースのURIを持つようになる。第２オプションは、最新の読取値を記憶する「TemperatureValue」ノード１４１を表すために＜Device＞１１１によって使用されるシステム全体の特別URIに関する。この場合、新たに作成された＜reading＞１１３の＜semanticDescriptor＞１１９リソース内であっても、その「TemperatureValue」ノード１４２は、＜reading＞１１３のURIを持つ代わりに、このシステム全体の特別URIを持つこともできる。比較すると、後者のオプションの方が、拡張性がよく、保守が容易であり得る。

ステップ１５２の下での第３アクションでは、resourceDescriptorLinkが、両方の＜semanticDescriptor＞リソース（１１６および１１９）内に現れる「TemperatureValue」ノード上で利用され、それら２つのリソースが共にリンクされることができるようにする。

ステップ１５３で、RH-SLN１２２は、Device１１１から送信された読取値の受信確認を行う。

セマンティッククエリ処理段階に関して、第２シナリオで指定されたようなセマンティッククエリがRH-SLN１２２によって受信され、＜Device＞１１１の＜semanticDescriptor＞１１６子リソース上で実行されることになっているとき、この時点で欠落している情報はない（例えば、値「３２」も、今や、RDFトリプルとして使用可能である）ため、有効なクエリ結果が生成され得る。このようなセマンティッククエリ処理は、図１５に示すような手順として形式的に記述される。図１５のセマンティッククエリ処理の一般的手順は、図１１に示すものと類似しているが、RH-SLN１２２がセマンティッククエリを処理する方法に関して、図１１のステップ１３２と図１５のステップ１５５の間には相違点があることに留意されたい。したがって、ステップ１５５では、SQI１２１からセマンティッククエリを受信すると、RH-SLN１２２におけるクエリ処理は、以下のアクションで実行される。第１アクションでは、＜Device＞１１１の子である＜semanticDescriptor＞１１６リソース上でSPARQLクエリが実行される。第２アクションでは、実行の過程で１つまたは複数のresourceDescriptorLink注釈を伴うクラスインスタンスまたはノードに遭遇した場合、実行は停止される。図１３に示す例では、「TemperatureValue」ノード１４１は、現在の温度値「３２」を記憶する新たに作成された＜semanticDescriptor＞１１９リソースを参照するresourceDescriptorLinkを有している。第３アクションでは、resourceDescriptorLinkが参照する＜semanticDescriptor＞リソースごとに、SPARQLクエリが実行されている元のコンテンツにコンテンツが追加される。例えば、Device１１１の現在の温度値が３２であるという事実を記述するRDFトリプルが追加される。第４アクションでは、拡大されたコンテンツに対してSPARQLクエリの実行が継続され、クエリ結果が生成される。

図１４は、新しい情報が利用可能になると情報クローン化プロセスが発生する場合を示すことに留意されたい。したがって、図１５に示すようなセマンティッククエリ処理は情報クローン化プロセスとは無関係である。あるいは、情報クローン化プロセスはセマンティッククエリ処理によって引き起こされるという意味で、オンデマンドアプローチが発生し得る。図１３に示す例として、＜reading＞１１３の新しい＜semanticDescriptor＞子リソースの作成は、RH-SLN１２２におけるセマンティッククエリ受信イベントによって引き起こされ得る。したがって、以下にさらに詳細に説明するように、新しいセマンティッククエリ処理手順が図１６に開示される。

図１６を参照すると、ステップ１６０では、Device１１１は温度デバイスであり、RH-SLN１２２に登録済みである。一方、RH-SLN１２２上の＜Device＞１１１リソースは、そのセマンティック記述を含む＜semanticDescriptor＞１１６子リソースも有する。Device１１１は、その読取値を定期的にRH-SLN１２２に送信し、それらの読取値は＜OutputX＞１１８リソース下の＜contentInstance＞子リソース内に記憶される。SQI１２１側では、必要性に基づいて、SQI１２１は、後ほど、RH-SLN１２２に関する何らかの情報を問い合わせる必要がある。そこで、SQI１２１は、その質問を記述するためにSPARQLクエリステートメントを作成する。例えば、図１３に示す例において論じたように、SQI１２１は、Device１１１の現在の読取値に関するクエリの実行を意図すると仮定する。ステップ１６１で、SQI１２１は、要求メッセージをRH-SLN１２２に送信し、その中で、この要求がセマンティッククエリであることを示す。

ステップ１６２で、SQI１２１からセマンティッククエリを受信すると、RH-SLN１２２は受信したセマンティッククエリを調べる。クエリが、現在はRDF形式で利用可能ではないが、他の通常のリソース内に見つかる可能性のある何らかの情報を探すものである場合、RH-SLN１２２はその情報を抽出して、RDFトリプルとして表す。このステップ１６２のために、RH-SLN１２２は特定の知能を有し得る。例えば、RH-SLN１２２は、＜OutputX＞１１８または＜Device＞１１１リソースのセマンティック記述子内に記憶された何らかの有用情報を学習済みであり得る（例えば、＜OutputX＞１１８は、Device１１１のすべての読取値を記憶する＜container＞リソースであり、読取値の単位は摂氏である）。この情報を知ることによって、RH-SLN１２２は、セマンティッククエリによって必要とされたときに、＜OutputX＞１１８リソース下の読取値情報を見つけることができる。さらに、より進んだアプローチは、RH-SLN１２２がデバイスのセマンティック記述に基づいてデバイスの測定単位を決めるためにセマンティック推論を用いるというものであり得る（例えば、会社Ａによって製造されたデバイスのすべてが摂氏を用いるよう初期設定されている）。

図１６のステップ１６２を引き続き参照して、第２シナリオ中に示された例では、＜OutputX＞１１８リソースのセマンティック記述に基づいて、RH-SLN１２２は、このリソースが＜Device＞１１１の読取値を記憶していることを理解する。したがって、クエリが＜Device＞１１１の現在の読取値を探すものであるとき、RH-SLN１２２は、＜reading＞１１３が最新の読取値を記憶しているリソースであると特定し、次に、値３２を抽出して、それをRDFトリプルとして表す。その後、関連する＜semanticDescriptor＞１１９リソースが＜reading＞１１３リソース用に作成され、このリソースにも最新の読取値情報が、ただしRDF形式で、記憶される。さらに、新しく作成された＜semanticDescriptor＞１１９リソースは、resourceDescriptorLinkプロパティを介して、他の＜semanticDescriptor＞リソース（例えば、例中の＜Device＞１１１の＜semanticDescriptor＞１１６リソース）とリンクされることもできる。したがって、それは将来のセマンティッククエリをサポートし得る。

続いて、ステップ１６３で、対応する図１５（ステップ１５５）と類似したクエリ処理がRH-SLN１２２で実行される。ステップ１６４で、RH-SLN１２２は応答メッセージをSQI１２１に送り返す。応答メッセージには、SQI１２１によって示されたような（ステップ１６１で提示されたように）フォーマットを用いて、クエリ結果が含まれている。

図１７は、第２オプションがシナリオ２Ａに対していかに有効であるかを示すのに役立つ。要約すれば（図１３および図１７を参照して）、通常のリソース（例えば、＜reading＞１１３リソース）からの情報については、＜reading＞１１３リソースが、現在、＜semanticDescriptor＞１１９子リソースを持っていない場合、RH-SLN１２２は、＜Device＞１１１リソース（親または先祖）の＜semanticDescriptor＞１１６リソースに対する情報を直接表している新しいRDFトリプルを追加する。＜reading＞１１３リソースが、現在、＜semanticDescriptor＞１１９子リソースを既に持っている場合、この＜semanticDescriptor＞１１９リソースに、新しいRDFトリプルが直接追加される。

図１７を引き続き参照して、この時点では、＜contentInstance＞リソース用に作成された＜semanticDescriptor＞リソースは存在せず、すべての新しいトリプルは、＜Device＞１１１の＜semanticDescriptor＞１１６子リソースに直接追加される。図１４と同様に、シナリオ２Ａの第２オプションのための情報クローン化プロセスは図１８に示す手順として形式的に記述される（各ステップは、ステップ１５２を除き、図１４のものと類似している）。ステップ１７０で、Device１１１は、例えば、M2M温度デバイスであり、RH-SLN１２２に登録済みである。Device１１１は、その読取値をRH-SLN１２２に送信することができる。一方、RH-SLN１２２上の＜Device＞１１１リソースは、そのセマンティック記述を含む＜semanticDescriptor＞１１６子リソースを有する。ステップ１７１で、Device１１１は新しい読取値をRH-SLN１２２に送信する。

図１７のステップ１７２で、Device１１１から新しい読取値が受信されると、データは＜contentInstance＞リソース、例えば、図１７に示すような＜reading＞１１３リソースに記憶され得る。一方、＜reading＞１１３リソースの作成に伴い、他のアクションが完了する。第１アクションでは、現在の読取値、例えば、値３２がRDFトリプルとして表される。例えば、それらのトリプルは、２つのリンクを有する「TemperatureValue」ノード１４１を持つグラフを記述し得る。１つのリンクは、このノードの値が「３２」であることを表すもので、もう１つのリンクは、温度の単位が摂氏であることを示すものである。第２アクションでは、それらの新たに作成されたRDFトリプルが、既存の関連する＜semanticDescriptor＞１１６リソースに直接追加され得る。この例では、＜Device＞１１１の＜semanticDescriptor＞１１６リソースが、それらの新たに作成されたトリプルの記憶場所となり得る。図１７に示すように、新しいトリプルが追加されると、「TemperatureValue」ノード１４１も、「hasCurrentValue」プロパティを介して、OutputX１１８ノードにリンクされる。以前の時間単位の読取値を参照する「TemperatureValue」ノード（例えば、＜Device＞１１１の＜semanticDescriptor＞リソース内の「TemperatureValue」ノード１４２）が既に存在し得るという可能性もあることに留意されたい。その場合、いかなる新しいトリプルを作成する必要もなく、その代わり、現実あるいは最新の読取値、例えば、３２を反映させるために、既存のRDFトリプルを更新して、Device１１１の最新読取値を表すために使用することができる。同様に、第２アクションのもう１つの検討事項は、「TemperatureValue」ノードのURIは＜Device＞１１１の＜semanticDescriptor＞リソース内に現れ、以下のオプションを持つ可能性があるということである。第１オプションでは、＜reading＞１１３の現在のURIを利用する。この場合、毎回、新しい読取値が受信される限り、＜Device＞１１１の＜semanticDescriptor＞１１６リソース内に現れた既存の「TemperatureValue」ノード１４１のURIは更新されて、新たに受信された読取値を記憶するリソースのURI値を持つ必要がある。第２オプションでは、システム全体の特別URIが、最新の読取値を記憶する「TemperatureValue」ノード１４１を表すために、＜Device＞１１１によって使用され得る。比較すると、後者のオプションの方が、拡張性または保守の容易性によって役立つ可能性がある。

ステップ１７３で、RH-SLN１２２は、Device１１１から送信された読取値の受信確認を行う。したがって、この＜Device＞１１１の単一＜semanticDescriptor＞１１６子リソース内には欠落している情報はなく、クエリを処理する際には、ただ１つの＜semanticDescriptor＞１１６リソースしか関与しないため、この第２シナリオにおけるクエリに対するクエリ処理はより簡便であり得る。

シナリオ２Ｂでは、本来は通常のリソースに記憶されていた情報は、RDFトリプルとして表現されていないか、＜semanticDescriptor＞リソース内に記憶されていない可能性がある。特に、通常のリソースＡ（例えば、図１９中のような＜reading＞１１３リソース）からの情報については、oneM2Mに定義されているように、＜reading＞１１３リソース自体は、＜semanticDescriptor＞１１６リソースの「resourceDescriptorLink」プロパティまたは「relatedSemantics」属性によって参照される。言い換えれば、特定の＜semanticDescriptor＞１１６リソース内のRDFトリプルが、＜reading＞１１３リソース内に記憶された情報に関連する場合、この＜semanticDescriptor＞１１６リソースは＜reading＞１１３リソースにリンクされる（＜reading＞１１３リソースは通常のoneM2Mリソースであることに留意されたい）。言い換えれば、「resourceDescriptorLink」プロパティの使用は、今や、（oneM2Mによって定義されているように）２つの＜semanticDescriptor＞リソースをリンクするだけでなく、＜semanticDescriptor＞リソースと通常のoneM2Mリソース間をリンクするようにも拡張されている。あるいは、既存のresourceDescriptorLinkプロパティをオーバーロードする代わりに、この目的をサポートするために、「informationLink」と呼ばれる新しいプロパティを提案することができる。

図１９を参照して、図に見られるように、＜Device＞１１１の＜semanticDescriptor＞子リソース内の「TemperatureValue」ノード１４１については、resourceDescriptorLinkプロパティを有し、それは、今や、＜contentInstance＞リソース、例えば、＜reading＞１１３を参照する。図２０は、シナリオ２Ｂに対する情報リンク方法を示す。ステップ１５２を除く大半のステップは図１４中のものと類似しているが、情報リンク手順を比較すると、情報クローン化プロセスはこの時点では採用されていないことに留意されたい。以下に、図１９を参照して、図２０の方法のフローを説明する。

ステップ１８０で、Device１１１はM2M温度デバイスであり、RH-SLN１２２に登録済みであり、自身の読取値をRH-SLN１２２に送信することができる。一方、RH-SLN１２２上の＜Device＞１１１リソースは、そのセマンティック記述を含む＜semanticDescriptor＞子リソースを有する。ステップ１８１で、Device１１１は新しい読取値をRH-SLN１２２に送信する。

ステップ１８３で、Device１１１から新しい読取値が受信されると、データは＜contentInstance＞リソース（例えば、図１９に示すような＜reading＞１１３リソース）に記憶され得る。シナリオ２Ｂの例において、全温度デバイスの最新の読取値がセマンティッククエリを通じて読み出し可能であるように、RH-SLN１２２が管理者によって構成されていると仮定すると、RH-SLN１２２は、それらのデバイスに対して読取値の提示を追跡する。したがって、＜reading＞１１３リソースの作成に伴い、以下のアクションが引き起こされ得る。第１アクションでは、RH-SLN１２２は、まず、＜reading＞１１３リソース内に記憶されている情報のリンクに使用可能な、＜Device＞１１１の最適な＜semanticDescriptor＞子リソースを特定する。通常、それは、利用可能であれば、直接の親の＜semanticDescriptor＞１１６子リソースであり得る。そうでなければ、この例では、＜Device＞１１１の＜semanticDescriptor＞子リソースが選択される。

ステップ１８３の下での第２アクションでは、「現在の温度読取値」、例えば、図１９に示すような「TemperatureValue」ノード１４１を表すために、＜Device＞１１１の＜semanticDescriptor＞１１６子リソース内にいくつかの新しいトリプルを追加することができる。一方、「TemperatureValue」ノード１４１も、「hasCurrentValue」プロパティを介して、OutputX１１８ノードにリンクされる。以前の時間単位の読取値を参照する＜Device＞１１１の＜semanticDescriptor＞１１６リソース内に「TemperatureValue」ノード１４１が存在し得るという可能性もあることに留意されたい。その場合、新しいトリプルを作成する必要はなく、その代わり、「TemperatureValue」ノード１４１のresourceDescriptorLinkが最新の読取値、例えば、＜reading＞１１３リソースを参照できるように、既存のRDFトリプルを更新することができる。あるいは、「TemperatureValue」ノード１４１のresourceDescriptorLinkは、＜container＞タイプのリソースで、＜reading＞１１３リソースを含む＜OutputX＞１１８の＜latest＞子リソースを参照することができる。同様に、＜Device＞１１１の＜semanticDescriptor＞１１６リソース内に現れる「TemperatureValue」ノード１４１のURIについては、この場合、システム全体の特別URIが、最新の読取値を記憶する「TemperatureValue」ノード１４１を常に表すために、＜Device＞１１１によって使用され得ることが開示される。したがって、「TemperatureValue」ノード１４１のresourceDescriptorLinkが＜reading＞１１３を参照するように、以下のトリプルを追加することができる：
「TemperatureValue」ノード１４１のURI
oneM2M:resourceDescriptorLink
＜reading＞１１３リソースのURI

ステップ１８３で、RH-SLN１２２は、Device１１１から送信された読取値の受信確認を行う。

シナリオ２Ｂのセマンティッククエリ処理段階に関して、指定されたようなセマンティッククエリがRH-SLN１２２によって受信され、＜Device＞１１１の子である＜semanticDescriptor＞１１６子リソース上で実行されることになっているとき、この時点で欠落している情報はない（例えば、「TemperatureValue」ノード１４１のresourceDescriptorLinkが、今や、＜reading＞１１３を参照しているので、値「３２」も、今や使用可能である）ため、有効なクエリ結果が生成され得る。このようなセマンティッククエリ処理は、図２１に示すような手順として形式的に記述される。図２１のセマンティッククエリ処理の一般的手順は、図１１に示すものと類似しているが、RH-SLN１２２がセマンティッククエリを処理する方法に関して、図１１のステップ１３２と図２１のステップ１８２の間には相違点があることに留意されたい。

ステップ１９２で、SQI１２１からセマンティッククエリを受信すると、RH-SLN１２２におけるクエリ処理が実行される。＜Device＞１１１の＜semanticDescriptor＞１１６リソース上でSPARQLが実行され得る。実行の過程で、１つまたは複数のresourceDescriptorLink注釈を伴うクラスインスタンスまたはノードに遭遇した場合、実行は停止される。図１９に示すこの例では、「TemperatureValue」ノード１４１は、＜contentInstance＞リソース、例えば、最新の温度値「３２」を記憶する＜reading＞１１３を参照するresourceDescriptorLinkを有している。resourceDescriptorLinkが参照するそのようなリソースごとに、SPARQLクエリが実行されている元のコンテンツにコンテンツが追加される。例えば、Device１１１の現在の温度値が３２であるという事実を表すために、新しいRDFトリプルが作成され、追加される。元のコンテンツへの前述の追加に基づいている拡大されたコンテンツに対して、SPARQLクエリの実行が継続され、クエリ結果が生成される。

あるいは、単純な「３２」を＜contentInstance＞リソース内に記憶する代わりに、＜contentInstance＞がRDFトリプルを直接記憶し得るという可能性もある。例えば、「『TemperatureValue』ノード１４１のURIは３２をhasValue」というトリプルが＜contentInstance＞リソース内に直接記憶され得る。さらに、このシナリオに関して、上記の節で論じたように、情報クローン化プロセス（すなわち、＜contentInstance＞リソース内のコンテンツをRDFトリプルに転送し、そのRDFトリプルを＜semanticDescriptor＞リソース内に記憶すること）を実行できるすべての可能なケースについて以下に説明する。以下のオプションはすべて代替的解決策である：１）データ読取値がRL-SLNによって受信されると、元の読取値がクローン化され、RDFトリプルとして表され、＜semanticDescriptor＞子リソース内に記憶される。上記の節で論じたように、これが主要なケースである。２）別のケースとして、発信元としてのデバイスが読取値をRL-SLNに送信する場合、デバイス自体がセマンティック能力を持っているなら、その読取値をRDFトリプルとしてRL-SLNに直接送信することもでき、元の読取値／コンテンツを記憶している、以前に作成された＜contentInstance＞リソースに対して、＜semanticDescriptor＞子リソースを作成する。３）デバイスがデータ読取値をRL-SLNに送信し、元の読取値を記憶するために＜contentInstance＞が作成される。このデバイスとRL-SLNの両方がセマンティック能力を持っていない場合、他のエンティティが役立つ可能性もある。例えば、後で、セマンティック能力を持つ別のエンティティ（例えば、oneM2Mの文脈における別のAEまたはCSE）が＜contentInstance＞リソース内の元のコンテンツを読み取り、そのコンテンツをRDFトリプルとして複製してから、＜semanticDescriptor＞子リソースを作成してRDFトリプルを記憶させることができる。

第３シナリオを参照して、セマンティッククエリは、複数の異なる＜semanticDescriptor＞リソース内に記憶し得る情報を要求することができる。特に、それらの＜semanticDescriptor＞リソースは、それらの異なる＜semanticDescriptor＞リソースの中にいくつかの重複したノードがある可能性があるかもしれないという意味で、互いに関連している可能性がある。＜semanticDescriptor＞リソース内のセマンティック記述は概念的にグラフ（例えば、図２２のブロック１１８とブロック１４４）およびノード（例えば、図２２のDevice１１１）を形成することに留意されたい。

以下は、第３シナリオに関するさらなる説明である。図２２は、部分的リソースツリー構造を示し、そこでは、＜Device＞１１１は、温度センサを表し、その子リソースである＜semanticDescriptor＞は、RDFトリプルの意味において関連するセマンティック記述を含む。一方、＜Device＞１１１リソースは、その動作を表す子リソース（例えば、＜Operation＞１１４）を有し、＜Operation＞１１４もそれ自身の＜semanticDescriptor＞１４３リソースを有する。＜semanticDescriptor＞１１６リソースと＜semanticDescriptor＞１４３リソースは、両方とも＜Device＞１１１のいくつかの側面を記述し、両方とも「Operation」１１４を代表する同じノードを持つため、互いに関連している。クエリ記述の意図は以下の通りであり得る：「与えられたデバイスに対するサービスの利用可能時間を返すこと、そして、このサービスには温度状況を記述する出力を出す動作がある。」SPARQL表現を以下のようにすることができる：
SELECT ?availableTime
WHERE { ?device rdf:type base:Device
?device base:hasService ?service
?service base:hasAvailableTime ?availableTime
?service base:hasOperation ?operation
?operation base:hasOutput ?output
?output base:describe temp:TemperatureAspect
}

この例では、従来の状況で上記クエリを、＜Device＞１１１の＜semanticDescriptor＞１１６子リソースに対して直接適用した場合、＜Operation＞１１４に関連するセマンティック情報の一部が＜Device＞１１１の＜semanticDescriptor＞子リソースから欠落しているため、結果が返されない可能性がある。特に、情報は＜Operation＞１１４の＜semanticDescriptor＞子リソース内に記憶されている。この状況を、セマンティッククエリ処理に照らして、以下により詳細に検討する。

第３シナリオの検討はシナリオ２Ａ（オプション１）と類似しており、そこでは、（例えば、oneM2Mの中で）定義された従来の既存のresourceDescriptorLinkが利用される。図２３に示すように、２つの＜semanticDescriptor＞リソースがOperation１１４ノードを介して共にリンクされ得るように、「resourceDescriptorLink」プロパティが使用される。

セマンティッククエリ処理段階に関して、ユースケース３で指定されたようなセマンティッククエリがRH-SLN１２２によって受信されたとき、＜Device＞１１１の子である＜semanticDescriptor＞リソース上でこのクエリが実行され、さらに、＜OperationA＞の＜semanticDescriptor＞子リソース内のトリプルを発見してアクセスすることもでき、最終的に有効なクエリ結果を生成する。図２４に示すような第３シナリオのセマンティッククエリ処理の一般的手順は図１１に示すものと類似しており、最も大きな相違点は、RH-SLN１２２がセマンティッククエリを処理する方法に関わる図２４のステップ２０２に関するものであることに留意されたい。ステップ２０２では、SQI１２１からセマンティッククエリが受信されると、RH-SLN１２２におけるクエリ処理が以下のように実行される。＜Device＞１１１の子である＜semanticDescriptor＞リソース上でSPARQLクエリが実行される。実行の過程で、１つまたは複数のresourceDescriptorLink注釈を伴うクラスインスタンスまたはノードに遭遇した場合、実行は停止される。この例では、operation１１４ノードは、＜Operation＞１１４リソースの子である＜semanticDescriptor＞リソースを参照するresourceDescriptorLinkを有している。そのような、resourceDescriptorLinkが参照するリソースごとに、SPARQLクエリが実行されている元のコンテンツにコンテンツが追加される。例えば、＜Operation＞１１４の＜semanticDescriptor＞子リソース内のRDFトリプルが追加され得る。（前述のRDFトリプルの追加に基づいて）拡大されたコンテンツに対して、SPARQLクエリの実行が継続され、クエリ結果が生成される。

第４シナリオを参照して、セマンティッククエリは、複数の異なる＜semanticDescriptor＞リソース内に記憶し得る情報を要求することができる。特に、それらの＜semanticDescriptor＞リソースは、相互関連さえもしていない可能性がある（このことは第３シナリオと異なる）。「ピア（peer）」とは、基本的に、これらの＜semanticDescriptor＞リソースは無関係であり、個々に異なるリソース（例えば、領域内の多くの＜温度センサ＞リソース）を記述するが、それらの温度センサは相互にピアであり、同種の機能を持っていることに留意されたい。例えば、２つの＜semanticDescriptor＞リソースは２つの個別温度デバイスをそれぞれ記述することができ、それら２つの温度デバイス、またはそれらのそれぞれの＜semanticDescriptor＞リソースは、例えば、同種または同領域内等であるため、ピアと見なされ得る。このことは、２つの＜semanticDescriptor＞が同一のデバイスを記述するものであり、さらに共通点を持ち得るとしている第３シナリオとは相違する。

以下は、第３シナリオに関するさらなる説明である。図２５は、部分的リソースツリー構造を示し、そこでは、＜Device＞１１１、＜Device＞１４６、および＜Device＞１４７は３つのデバイスを表し、その各々は、それぞれのセマンティック記述を記憶する＜semanticDescriptor＞子リソースを持つ。したがって、それら３つの＜semanticDescriptor＞リソースは、異なるデバイスを記述しているため、相互にピアである。さらに、それら３つのセンサは異なる会社に属している（例えば、＜Device＞１１１は＜CompanyA＞の子リソースであるが、＜Device＞１４６と＜Device＞１４７は＜CompanyB＞の子リソースである）可能性がある。クエリ記述の意図は以下の通りであり得る：「会社Ａと会社Ｂのすべてのデバイスの動作の動作モードを返すこと。」SPARQL表現を以下のようにすることができる：
SELECT ?mode
WHERE { ?device rdf:type base:Device
?device rdf:is-from CompanyA or CompanyB.
?device base:hasService ?service
?service base:hasOperation ?operation
?operation base:hasWorkingmode ?mode
}

この例では、上記クエリを、CSEノードのルートソースである＜CSEBase＞２１０に対して直接適用した場合、３つの異なる無関係の＜semanticDescriptor＞リソースを評価する必要があるが、それは、各々が異なるデバイスを表すからである。しかし、現在のところ、複数のピアまたは無関係の＜semanticDescriptor＞リソースからの情報が必要な場合に、そのようなクエリを処理する方法に関して（例えば、oneM2Mの中に）定義した従来の詳細な説明はない。

基本的な解決策においては、与えられたセマンティッククエリに関して、関与する可能性のある＜semanticDescriptor＞リソースに対するクエリ範囲を決定するために、複数のアプローチを利用し得る。第１アプローチでは、セマンティッククエリを伝達する要求メッセージに示されるように「To」パラメータが与えられると、「To」パラメータによって示されるようなURIの下のすべての＜semanticDescriptor＞リソースが関与する。 例えば、「To」パラメータによって示されるようなURIの下の子リソースが範囲に含まれる。さらに、oneM2Mは検索範囲を限定するための「level」および「offset」パラメータも定義する。したがって、これら２つのパラメータが設定されていると、それに応じてクエリ範囲も影響される。第２アプローチでは、「peerSemantics」と称する新たな属性が＜semanticDescriptor＞リソースに対して提案される。特に、第１アプローチで特定された＜semanticDescriptor＞リソースについて、それらの「peerSemantics」属性もチェックされる可能性があり、それを通じて、さらに多くの＜semanticDescriptor＞リソースが関与するリソースとして特定される可能性がある（すなわち、開示された「peerSemantics」属性によって示される＜semanticDescriptor＞リソースもクエリ範囲に含まれる）。oneM2Mによって定義された既存の「relatedSemantics」属性は、単一のSPARQL処理のために、関連する＜semanticDescriptor＞リソースを共にリンクするものであることに留意されたい。

それと比べて、提案された「peerSemantics」はピアである＜semanticDescriptor＞リソースをリンクするものであり、セマンティッククエリはそれらのピア＜semanticDescriptor＞リソースの各々に対して実行される。これが、既存の「relatedSemantics」属性に加えて、新しい「peerSemantics」を提案する主な理由である（そうしなければ、システムには、２つの＜semanticDescriptor＞リソース間の実際の関係を伝える手段を持ち得ない）。例えば、SPARQL Query-1が特定の＜semanticDescriptor-1＞リソースに適用される状況を考える：別の＜semanticDescriptor-2＞リソースにリンクする「relatedSemantics」があれば、＜semanticDescriptor-2＞リソース内のコンテンツは＜semanticDescriptor-1＞リソース内のコンテンツと統合され、次に、統合されたコンテンツに対してQuery-1が実行される。比較すると、別の＜semanticDescriptor-2＞リソースにリンクする「peerSemanticｓ」がある場合、Query-1は＜semanticDescriptor-1＞リソースと＜semanticDescriptor-2＞リソースの両方に個別に適用され、各々の実行は部分的なクエリ結果を返し得るという意味で、クエリ処理は異なる。第１のアプローチおよび第２のアプローチを通じて特定されるようなそれらの＜semanticDescriptor＞リソースは、実行されるべき特定のクエリ処理のためのリソースセットであり得る。

さらに、第４シナリオについて以下に論じる。図２６は、「peerSemantics」がクエリ範囲の問題への対処にどのように役立ち得るかを示す。ここでは、SQI１２１は、RH-SLN１２２におけるリソース構造に関して限られた知識しか持っておらず、＜CompanyB＞のURIを以前のリソース発見を通じて知っているだけであると仮定する。SQI１２１は、現在、「すべての会社のすべてのデバイスの動作の動作モードを返すこと。」という意味の新しいクエリを持っている。SQI１２１がこのクエリを送信する方法の一つは、＜CSEBase＞２１０の下のデバイスを発見できるように、＜CSEBase＞２１０をターゲットにすることである。しかし、この動作に対するオーバーヘッドはかなり大きくなり得る。提案された「peerSemantics」プロパティによれば、SQI１２１は、そのクエリをさらに＜CompanyB＞に向けて送信することができる可能性がある。したがって、＜CompanyB＞の下のデバイスの１つ（例えば、例に示すような＜Device＞１４７）が、他所の別のデバイス（例えば、異なる会社＜CompanyA＞のデバイス＜Device＞１１１）にリンクするための「relatedSemantics」を持つ場合、クエリ処理によって、「peerSemantics」プロパティの助けを借りて、すべての必要なデバイス発見することは依然として可能である。

図２６に見られるように、基本的な解決策においては、同時に使用することができる提案されたアプローチ１とアプローチ２を通じて、可能性のある関与する＜semanticDescriptor＞リソースを発見することができる。一方、クエリ要求は単一のRETRIEVEメッセージにマッピングされている可能性があり、クエリ開始点は「To」パラメータで指定されたようなURIに基づいている可能性がある。一方、アプローチ１は、「To」パラメータで指定されたようなURIの下の関与する＜semanticDescriptor＞リソースの発見を可能にするが、アプローチ２は、「To」パラメータで指定されたようなURIの下に存在しないかもしれない、例えば、リソースツリー内のどこにでもあり得る（ただし、特定のアクセス制御ポリシーに準拠する必要があり得る）他の関与する＜semanticDescriptor＞リソースの発見を可能にする。例えば、第４シナリオの中で指定されたようなセマンティッククエリがRH-SLN１２２によって受信され、「To」パラメータが＜CompanyB＞のURIに向けられているとき、欠落している情報はない（例えば、この時点で＜Device＞１１１が見逃されることはない）ため、正確なクエリ結果が生成され得る。

セマンティッククエリ処理段階については、図２７に示すような手順として形式的に記述される。図２７に示すようなセマンティッククエリ処理の一般的手順は図１１に示すものと類似しており、唯一の相違点は、RH-SLN１２２がセマンティッククエリを処理する方法に関わるステップ２２２に関するものであることに留意されたい。ステップ２２２について以下に詳述する。ステップ２２２で、SQI１２１からセマンティッククエリが受信されると、RH-SLN１２２におけるクエリ処理が以下のアクションで実行される。第１アクションでは、SQI（例えば、SQI１２１）から要求を受信すると、受信側（例えば、RH-SLN１２２）は、要求メッセージ内の「To」パラメータによって示されるような開始点から、セマンティッククエリ処理を開始することができる。特に、RH-SLN１２２は、まず、先に示したように、アプローチ１とアプローチ２を用いて、すべての可能性のある関与するリソースを特定することができる。この例では、図２６に示すように、＜Device＞１１１、＜Device＞１４６、および＜Device＞１４７が特定され得る。図２６を参照すると、第２アクションでは、RH-SLN１２２は、特定のアクセス制御ポリシーに基づいて、関与する可能性のある＜semanticDescriptor＞リソースごとに、それに対してセマンティッククエリを実行できるかどうかをさらに評価する。実行できる場合、そのようなリソースは、正式な関与するリソースとなり得る。

ステップ２２２の第３アクションでは、正式な関与する＜semanticDescriptor＞リソースごとに、それに対するセマンティッククエリが実行される。有効なクエリ結果がある場合、そのクエリ結果は最終結果セットに追加され得る。一方、これらの正式な関与するリソースに対するクエリ処理は互いに独立して実行され得る。第４アクションで、正式な関与するリソースがクエリに従って評価された後は、最終結果セットは最終クエリ結果を含み、ＳＱＩ１２１に返される。

前述の基本的な解決策においては、「To」パラメータによって示されるようなリソースURIが、クエリ処理がどこから開始するかを概ね決定する、例えば、「To」（または同様の）パラメータが既定のクエリ範囲の決定に用いられると仮定される。実際、特に、与えられたセマンティッククエリが複数の＜semanticDescriptor＞リソースを伴う場合、クエリ範囲は、セマンティッククエリ処理に影響を及ぼす可能性がある重要問題となり得る。以下に論じる機能強化によって、クエリ範囲に関連する問題への対処を試みる。

クエリ範囲に関連する重要問題は、クエリ範囲が既存のoneM2M仕様に準拠している場合、例えば、それは、特定のセマンティッククエリに対する正確な回答に成功するために必要なクエリ範囲と等しくなり得えないということである。例えば、図２８に見られるように、SQIは、＜CSEBase＞２１０をルートとするリソースツリーをホストするRH-SLN１２２に、セマンティッククエリ要求を送信し、セマンティッククエリ要求において、「To」パラメータは＜CompanyB＞２１２のURIに向けられており、セマンティッククエリは、要約すれば、「CompanyA２１１とCompanyB２１２のすべてのデバイスの動作の動作モードを返すこと。」と指示していると仮定する。そのような場合、既存のoneM2M仕様に基づいて、＜Device＞１４６と＜Device＞１４７の＜semanticDescriptor＞子リソースが関与する可能性がある。しかし、このクエリに正確に答えるためには、＜Device＞１１１の＜semanticDescriptor＞１１６子リソースも関与する必要がある（ここでは、アクセス制御は問題ではないと仮定して）。したがって、セマンティッククエリは「すべてのデバイスにわたる」結果を求めているため、＜Device＞１４６、＜Device＞１４７、およびそれらの＜semanticDescriptor＞子リソースに基づくだけの最終クエリ結果は正確であり得ない（＜Device＞１１１が見逃されているので）。

以下に論じる機能強化は、クエリ範囲の問題に対処し得る複数のアプローチを含むことができる。第１強化アプローチでは、SQI１２１は、それが望む任意の特定のセマンティッククエリを指定することが依然として可能であり、RH-SLN１２２については、関与する＜semanticDescriptor＞子リソースを特定するためにクエリ範囲を決定するために、（次に開示するように）特定の運用ポリシーに従うことができる。まず、SQI１２１とRH-SLN１２２の両方は、以下の３つのケースを含むクエリ範囲の決定方法に関して、以下の合意を交わしている。言い換えれば、SQI１２１は、クエリは合意されたクエリ範囲でのみ実行可能であることを事前に把握することができる。

第１強化アプローチのケース１では、SQI１２１は、そのセマンティッククエリ要求を、＜CSEBase＞２１０リソースの下のすべての＜semanticDescriptor＞子リソースがチェックされ得るように、＜CSEBase＞２１０リソースに向けて直接送信することができる。例えば、この場合、クエリ範囲は現在のRH-SLN１２２のリソースツリー全体である。より一般的には、前節で提案した解決策を利用することもできる。例えば、＜CSEBase＞２１０の下の＜semanticDescriptor＞子リソースも「peerSemantics」属性を持つことができ、別のCSEの他の＜semanticDescriptor＞リソースにリンクすることができる。

第１強化アプローチのケース２では、セマンティッククエリ要求を＜CSEBase＞２１０に向けて送信する代わりに、＜queryPortal＞と呼ばれる新しいリソースが開示される。したがって、SQI１２１は、そのセマンティッククエリ要求を、この＜queryPortal＞に向けて直接送信することができる。特に、この＜queryPortal＞は、それ自身のクエリ範囲を示す「queryScope」と呼ばれる属性を持つことができる（この新たなリソースに関する詳細について本明細書で論じる）。したがって、この＜queryPortal＞リソースに送信されるすべてのセマンティッククエリは、この＜queryPortal＞リソースの「queryScope」属性によって示されるようなクエリ範囲内で実行される。それはURIであってもよく、対応するクエリ範囲はこのURIの下のすべての子リソースであり得る。さらに、与えられたRH-SLN１２２は複数の＜queryPortal＞リソースを持つことができ、それらの各々はそれ自身のクエリ範囲を持つことができる可能性がある。それらの＜queryPortal＞リソースを、例えば、通常のリソース発見を通じて発見し、実行すべきクエリにとって望ましいものを選択することはSQIに委ねられる。

第１強化アプローチのケース３では、SQI１２１は、そのセマンティッククエリ要求を、（「To」パラメータによって指定されるような）任意のリソースURIに向けて直接送信することができ、そして、これは、クエリ範囲がこのURIの下のすべての＜semanticDescriptor＞子リソースであってもよいということを意味する。同様に、前節で提案した解決策を利用することもできる。例えば、「To」パラメータによって指定されたURIの下の＜semanticDescriptor＞子リソースも、このCSEのリソースツリーの任意の位置にある他の＜semanticDescriptor＞リソースにリンクするための「peerSemantics」属性を持つことができる。留意すべきことは、このケースは基本的な解決策について検討したものであるが、本節は、改良し得る追加的な変更を提供するということである。例えば、この場合、SQI１２２は、それが望む任意のクエリを提示し得るが、RH-SLN１２２によって使用されるクエリ範囲が不完全であるため正確なクエリ結果を与えられない場合、ある種の不正確性が存在する可能性がある。したがって、ここで必要なことは、RH-SLN１２２は、クエリ結果をSQIに認識させるために返すとき、クエリ結果／品質の要約を示すことができるということである。

セマンティッククエリ処理段階については、図２９に示すような手順として形式的に記述される（詳細な説明は、図２８に示す例を用いて例示されている）。ステップ２３０に、前提条件がある。必要性に基づいて、SQI１２１は、RH-SLN１２２に関する何らかの情報を問い合わせることができる。そこで、SQI１２１は、その質問を記述するために、SPARQLクエリステートメントを作成する。例えば、SQI１２１が、シナリオ４に例示するようなクエリの実行を意図すると仮定する。

図２９を参照すると、ステップ２３１で、SQI１２１は、要求メッセージをRH-SLN１２２に送信し、その中で、この要求が、処理すべきセマンティッククエリに関するものであることを示す。メッセージは、図１１のステップ２９１で開示されたようなパラメータに加えて、新たなパラメータneed_query_summary（nqｓ）を含むことができる：この情報は、RH-SLN１２２がクエリ結果をSQI１２１に返すとき、SQI１２１が、関連クエリ結果または品質の要約情報も返すことを要望するのかどうかを示す。

ステップ２３２では、SQI１２１からセマンティッククエリが受信されると、RH-SLN１２２におけるクエリ処理が以下のように実行される。第１アクションでは、「To」が＜CSEBase＞リソースに向けられている場合、可能性のある関与する＜semanticDescriptor＞リソースを特定するために、ケース１で導入されたような詳細に従って、このクエリ処理を行うことができる。あるいは、「To」が＜queryPortal＞リソースに向けられている場合、可能性のある関与する＜semanticDescriptor＞リソースを特定するために、ケース２で導入されたような詳細に従って、このクエリ処理を行うことができる。あるいは、「To」がRH-SLN１２２のリソースツリー内の任意のリソースに向けられている場合、可能性のある関与する＜semanticDescriptor＞リソースを特定するために、ケース３で導入されたような詳細に従って、このクエリ処理を行うことができる。ステップ２３２のための第２アクションでは、RH-SLN１２２は、特定のアクセス制御ポリシーに基づいて、可能性のある関与する＜semanticDescriptor＞リソースごとに、それに対してセマンティッククエリを実行できるかどうかをさらに評価する。実行できる場合、そのようなリソースは、正式な関与するリソースとなる。ステップ２３２のための第３アクションでは、正式な関与する＜semanticDescriptor＞リソースごとに、それに対するセマンティッククエリが実行される。有効なクエリ結果がある場合、そのクエリ結果は最終結果セットに追加され得る。一方、これらの正式な関与するリソースに対するクエリ処理は互いに独立して実行され得る。正式な関与するリソースがクエリに従って評価された後は、最終結果セットは最終クエリ結果を含むことができ、SQI１２１に返され得る。

ステップ２３３で、RH-SLN１２２は、SQI１２１によって示されたようなフォーマットを用いたクエリ結果を含む応答メッセージをSQI１２１に返信することができる。メッセージは、図１１のステップ２３１で提案されたようなパラメータに加えて、以下の新しいパラメータを含むことができる：query_summary（qs）。query_summaryパラメータは、クエリ結果品質または要約情報を含むことができる。それは、例えば、クエリがどの＜semanticDescriptor＞リソース上で実行されたかを示すことができる。SQI１２１は、この情報を利用することにより、返されたクエリ結果が望ましく、かつ十分に正確であるかどうかを評価することができる。その他の情報は、クエリ処理時間費用等を含み得る。

第２強化アプローチでは、RH-SLN１２２側で、既存の＜group＞および＜semanticGroup＞リソースを用いて、いくつかの関連するリソースを積極的に集約することができる。＜group＞および＜semanticGroup＞のいくつかの特徴は、既存のTS-0001およびTR-0007に定義されている通りである。要約すると、セマンティッククエリ処理を、セマンティック記述子コレクションと切り離すことができる。例えば、受信側では、セマンティッククエリを処理することなく、既存の＜group＞または＜semanticGroup＞リソースを用いて、いくつかの関連する＜semanticDescriptor＞リソースを積極的に集約することができる。したがって、SQI１２１は、まず、それらのリソースを発見して、次に、処理のために、セマンティッククエリをそれらのリソースに送信することができる。特に、そのようなアプローチでは、クエリ範囲は、それらの＜group＞または＜semanticGroup＞リソースのメンバーリソースによって決定済みであるため、SQI１２１によって提起されたセマンティッククエリは、クエリ範囲関連のステートメントを伝達する必要はない。

第２強化アプローチを引き続き参照して、例えば、RH-SLN１２２において、（例えば、既存の＜semanticGroup＞リソースの「semanticGroupLinks」属性または＜group＞リソースの「memberIDs」属性を用いることによって）、＜Device＞１１１、＜Device＞１４６、および＜Device＞１４７のすべての＜semanticDescriptor＞子リソースを含むことができる＜semanticGroup＞リソース（または＜group＞リソース）を作成することができる。図３０は、それらの２つのケースについての２つの例を示す。したがって、＜semanticGroup＞リソース内では、このグループはどのようなグループか（概要として、例えば、「全デバイス」）を示し、さらにデバイスのすべての参照を含めることができる。したがって、SQI１２１が「全デバイスの動作名を問い合わせる」というようなクエリを送信する必要があるアプローチ１とは違って、アプローチ２では、SQI１２１は、CompanyAとCompanyBのすべてのデバイスをメンバーとして含む特定の＜semanticGroup＞リソースを最初に発見することができる。この＜semanticGroup＞リソースの概要を知ることによって、SQI１２１は、この＜semanticGroup＞リソースが全デバイスの参照を持つことを理解することができる。次に、SQI１２１は、クエリ範囲を示さずに（例えば、「全デバイスの」）「動作名を問い合わせる」クエリ要求を送信するだけでよく、そのようなクエリはこの＜semanticGroup＞のすべてのメンバーリソースに自動的に適用され、＜Device＞１１１、＜Device＞１４６、および＜Device＞１４７のすべての関与する＜semanticDescriptor＞子リソースがチェックされ得る。第２強化アプローチに見られるように、クエリ範囲が積極的にRH-SLN１２２側で決定され、SQI１２１は、セマンティッククエリを送出する前に、クエリ範囲または関与する＜semanticDescriptor＞子リソースを知る。したがって、SQI１２１とRH-SLN１２２の両者は、クエリ範囲について同じ理解を有しているため、第２強化アプローチにおいては、クエリ結果は正確である。

以下は、第２強化アプローチにおいてセマンティッククエリがどのように処理され得るかに関するさらなる詳細である。ステップ２５１で、SQI１２１は、＜semanticGroup＞２４０または＜group＞２４２リソースを発見する。ステップ２５２で、SQI１２１は、このリソースに、クエリ要求を含み得るセマンティッククエリを送信することができる。特に、セマンティッククエリ要求は、この＜group＞または＜semanticGroup＞リソースの＜semanticFanOutPoint＞子リソースに向けたRETRIVE動作にマッピングされ得る。＜semanticFanOutPoint＞リソースは、表現を持たないため、仮想リソースである。それは、＜semanticDescriptor＞型のメンバーを持つ＜group＞リソースの子リソースである。セマンティッククエリ要求が＜semanticFanOutPoint＞リソースに送信されるときには、常に、ホスト（例えば、この場合、RH-SLN１２２）は、親である＜group＞リソースまたは＜semanticGroup＞リソースのmemberIDs属性を用いて、すべての関連セマンティック記述子にアクセスする。他のRH-SLNに記憶されたセマンティック記述子がある場合、外部セマンティック記述子を読み出すために、個別のRETRIVE要求が、RH-SLN１２２から他のRH-SLNの各々に送信される。セマンティック記述子は、それぞれのアクセス制御ポリシーに基づいてアクセスされる。

特に、それらのリソースに対する既存のセマンティック発見処理とは違って、セマンティッククエリ処理では、関与する＜semanticDescriptor＞リソースが＜group＞または＜semanticGroup＞リソースを通じて特定されると、それらの関与する＜semanticGroup＞リソースの各々に対して、クエリが直接かつ個別に実行され得る。一方、関与する＜semanticDescriptor＞リソースが、セマンティッククエリ処理能力を持たない別のRH-SLN上にある場合、この関与する＜semanticDescriptor＞リソースのコンテンツは、セマンティッククエリ要求を受信して、かつ、＜group＞または＜semanticGroup＞リソースをホストする、元のRH-SLNによって読み出される可能性が依然としてあり、そこからクエリが実行され得る（ただし、依然として、個別に）。最終的に、関与する＜semanticDescriptor＞リソースの各々に対する個別クエリ結果のすべてを合成することによって、最終クエリ結果を生成することができる（ステップ２５３）。

図３０は、上記の動作の詳細を示す例を示す。例えば、RH-SLN１２２側では、＜semanticGroup-1＞２４０リソースが作成され得る。＜semanticGroup-1＞２４０リソース内のsemanticGroupLinksは、全デバイスへの参照、例えば、＜Device＞１１１、＜Device＞１４６、および＜Device＞１４７の＜semanticDescriptor＞（１１６、１４８、４９）子リソース（または、単に、＜Device＞１１１、＜Device＞１４６、または＜Device＞１４７でもよい）を含む。このグループにすべての会社のすべてのデバイスが含まれていることを記述するために、この＜semanticGroup＞リソースに、新たな「Description」属性をさらに定義することもできる。パラメータは他の有益な情報をも含むことができる。例えば、この＜semanticGroup＞リソースがどの種類のクエリをサポートできるかを記述／指示することができる。この方法は、SQI１２１が、後ほどセマンティッククエリを送信するために、適正な＜semanticGroup＞リソースを発見することを容易にし、支援する。

あるいは、このグループを、＜group＞２４２リソースによって表すこともできる。特に、＜Group-1＞２４２の＜semanticDescriptor＞リソースを用いて、このリソースグループはどのようなグループかを記述することができる。手順については、SQI１２１は、まず、それらの＜semanticGroup＞２４０または＜group＞２４２リソースを発見することができる（ステップ２５１）。適切なものが選択されると、SQI１２１は、そのセマンティッククエリを、この選択された＜semanticGroup＞２４０または＜group＞２４２リソースに送信することができ（ステップ２５２）、クエリは、この選択された＜semanticGroup＞２４０または＜group＞２４２リソースによって示されたように、メンバーリソース上で実行される（ステップ２５３）。ステップ２５４で、クエリ結果がSQI１２１に返される。

セマンティッククエリ処理段階については、図３１に示すように記述される。ステップ２６１で、SQI１２１はリソース発見要求メッセージをRH-SLN１２２に送信し、その中で、この要求は、後ほどセマンティッククエリを実行する対象となる可能性のある＜semanticDescriptor＞リソースを発見するためのものであることを示す。この要求の中で、新しいパラメータresource_discovery_purpose（rdp）がこのリソース発見要求の目的を示すことができる。resource_discovery_purpose（rdp）情報は、SQI１２１が、セマンティッククエリを実行するための＜semanticDescriptor＞リソースを探していることを示す。ステップ２６２で、rdpパラメータを通じて、RH-SLN１２２は、このリソース発見が特定の＜group＞２４２または＜semanticGroup＞２４０リソースに限られているだけであることを知る。そこで、RH-SLN１２２は、通常のリソース発見プロセスを実行し、セマンティッククエリをサポートするために使用可能な＜group＞２４２または＜semanticGroup＞２４０リソースのリストを返す。ステップ２６３で、RH-SLN１２２は、＜group＞２４２または＜semanticGroup＞２４０リソースに関する記述情報と共にそれらのリソースのリストを含む応答メッセージを、SQI１２１に返信する。

ステップ２６４で、SQI１２１は、返された＜group＞２４２または＜semanticGroup＞２４０リソースの各々を評価して、所望のリソースはどれかを決定する。このプロセスの間に、SQI１２１は、より多くの情報を得るために、それらのリソースにさらにアクセスすることができる。ステップ２６５で、特定の＜group＞２４２または＜semanticGroup＞２４０リソースを決定した後、SQI１２１は、例えば、選択された＜semanticGroup＞２４０リソースの＜semanticFanOutPoint＞子リソースに向けて、新しいセマンティッククエリ要求を送信する。新しいパラメータ、クエリステートメント（QS）、結果フォーマット（RF）、またはクエリ要約要求（need query summary:NQS）を使用することができる。クエリステートメント（qs）は、SQI１２１によって指定された、SPARQLクエリステートメントであり得るクエリステートメントを記憶することを指示する情報を提供する。あるいは、SQI１２１は、そのクエリをセマンティクスfilterCriteriaに入れて伝達することもできる。結果フォーマット（rf）は、クエリ結果をどのような表現方法で記憶するかを指示する情報を提供し、プレーンテキスト、JSON、またはXMLフォーマットであり得る。need_query_summary（nqｓ）は、SQI１２１が、RH-SLN１２２がクエリ結果をSQI１２１に返すときに関連クエリ結果または品質の要約情報も返すことを要望するのかどうかを示す情報を提供する。

ステップ２６６で、RH-SLN１２２がこのセマンティッククエリ要求を受信した後、RH-SLN１２２は、親＜group＞リソースまたは＜semanticGroup＞２４０リソースのmemberIDs属性を用いて、関連セマンティック記述子にアクセスする。言い換えれば、＜semanticGroup＞２４０リソースに含まれるメンバーの＜semanticDescriptor＞子リソースが、可能性のある関与する＜semanticDescriptor＞リソースである可能性がある。特に、クエリ処理は以下のように機能し得る。第１アクションでは、RH-SLN１２２は、特定のアクセス制御ポリシーに基づいて、可能性のある関与する＜semanticDescriptor＞リソースごとに、それに対してセマンティッククエリを実行できるかどうかをさらに評価する。実行できる場合、そのようなリソースは、正式な関与するリソースとなり得る。第２アクションでは、特定の正式な関与する＜semanticDescriptor＞リソースに対して、複数のケースがあり得る。ケース１では、＜semanticDescriptor＞リソースがRH-SLN１２２によってホストされている場合、セマンティッククエリはそれに対して直接実行される。ケース２では、＜semanticDescriptor＞リソースが、別の、やはりセマンティッククエリ処理能力を持つRH-SLN-2（図示せず）にホストされている場合、RH-SLN１２２は、セマンティッククエリを別のRH-SLN-2上で直接実行するために、セマンティッククエリを別のRH-SLN-2に送信することができる。ケース３では、＜semanticDescriptor＞リソースが、別の、セマンティッククエリ処理能力を持たないRH-SLN-3（図示せず）にホストされている場合、RH-SLN１２２は、この関与する＜semanticDescriptor＞リソース内に含まれるすべてのコンテンツをRH-SLN-3から読み出した後、セマンティッククエリをRH-SLN１２２上でローカルに実行することができる。正式な関与するリソースがクエリに従って評価された後は、最終結果セットは、最終クエリ結果を含むことができ、SQI１２１に返され得る。あるいは、RH-SLNは、すべての関与する＜semanticDescriptor＞リソースを読み出すことができ、そして、それらは、統合されたRDFデータ基盤を形成する。次に、この統合されたRDFデータ基盤上でセマンティッククエリステートメントが実行され、セマンティッククエリ結果が生成され得る。ステップ２６７で、RH-SLN１２２は、SQI１２１によって示されたようなフォーマットを用いたクエリ結果を含む応答メッセージをSQI１２１に返信する。品質の要約情報も必要に応じて返すことができる。

第５シナリオを参照すると、セマンティッククエリは、＜semanticDescriptor＞リソース内に記憶されていない情報を要求する。例えば、何らかの要求された情報は、RDFトリプルとして表され得ず、通常のリソース内に記憶されているだけである可能性がある。しかし、前述の第２シナリオでは、セマンティッククエリを実行するために、どの＜semanticDescriptor＞リソースが関与することになるかは、例えば、セマンティッククエリ要求メッセージに含まれる「To」パラメータに基づいて、既に知られていると仮定される。シナリオ５では、ユーザがいくつかの「目標とするリソース」（それらの目標とするリソースは特定の制約を満たす必要がある）からの情報を必要としているが、それらの目標とするリソースは事前に特定されていないという状況を論じる。第５シナリオは、前述の第２シナリオと第４シナリオとの組み合わせと類似であり得る。ここで、この第５シナリオでは、セマンティッククエリは、任意の関与する＜semanticDescriptor＞上で実行され得るということが重要である。第１シナリオの第１ステップは、「目標とするリソース」を特定して、次に、それらの目標とするリソースから必要な情報を抽出することである。したがって、ユーザは情報を問い合わせているにもかかわらず、セマンティッククエリ処理に直接頼らず、間接的に、既存のセマンティックリソース発見処理を遂行し得ることが分かる。

以下は、第５シナリオに関するさらなる説明である。図３２は、部分的リソースツリー構造を示し、そこでは、＜Device＞１１１、＜Device＞１４６、および＜Device＞１４７は３つの温度デバイスを表し、それらの各々は、それぞれのセマンティック記述を記憶する子リソース＜semanticDescriptor＞を持つ。一方、それらの３つのデバイスの各々は「OperationA」を持ち、この動作は「現在の動作状態」と呼ばれる属性を持つ。クエリ記述の意図は以下の通りであり得る：「CompanyAとCompanyBのすべての温度デバイスの現在の動作状態を返すこと。」現在のところ、本明細書で論じるものとしては、セマンティッククエリをさらに処理するために既存のセマンティックリソース発見メカニズムを利用する方法を示す解決策はない。

セマンティッククエリ要求を処理するために既存のセマンティックリソース発見プロセスを利用する方法は複数ある。本明細書には、シナリオ５Ａやシナリオ５Ｂ等の、既存のセマンティックリソース発見プロセスを利用するいくつかの例がある。

シナリオ５Ａを参照すると、SQI１２１は、そのクエリを指定するために、依然として、既存のセマンティックフィルタインタフェースを使用する。一方、セマンティックフィルタは、目標とするリソースを特定する方法を指定することができる。SQI１２１は、目標とするリソースが特定されると、どの情報を抽出して返す必要があるかということも示す。同様に、RH-SLN１２２は、SQI１２１から要求を受信すると、まず、既存のセマンティックリソース発見によってサポートされ得るセマンティックフィルタに含まれる制約を用いて、目標とするリソースを特定する。リソースが目標とするリソースとして特定されると、RH-SLN１２２は、さらに、この目標とするリソースから情報を抽出することができる。

図３３は、図３２を考慮した例示的な方法を示す。ステップ２７０に、前提条件があり得る。前提条件。必要性に基づいて、SQIは、RL-SLNに関する何らかの情報を問い合わせる必要がある。例えば、SQIが、シナリオ５に例示するようなクエリの実行を意図すると仮定する。ステップ２７１で、SQI１２１は、要求メッセージをRH-SLN１２２に送信し、その中で、この要求が、処理すべきセマンティッククエリに関するものであることを示す。ステップ２７１のセマンティッククエリは以下を含むことができる：セマンティックフィルタ、必要情報（NI）、または結果フォーマット（RF）。既存のセマンティックフィルタを利用して、可能性のある目標となるリソースをセマンティックリソース発見を通じて特定する方法を指定することができる。第５シナリオに示される例では、セマンティックフィルタを以下のように（すなわち、すべてのOperationAリソースを発見するように）書くことができる：
SELECT ?operation
WHERE { ?device rdf:type base:Device
?device rdf:is-from CompanyA or CompanyB.
?device base:hasService ?service
?service base:hasOperation ?operation
?operation base:hasName OperationA
}

必要情報（NI）は、目標とするリソースが特定されたら抽出されるべき情報である。結果フォーマット（RF）は、クエリ結果を記憶する方法を指示する情報で、プレーンテキスト、JSON、またはXMLフォーマットであり得る。

あるいは、SQI１２１は、既存のセマンティックフィルタを使用せず、完全なセマンティッククエリを直接送信することができる。そうであれば、第１シナリオで提案されたように、完全なセマンティッククエリを、以前に提案されたクエリステートメント（QS）パラメータに含むことができる。図３２に関連付けられた第５シナリオに示される例では、完全なセマンティッククエリを以下のように書くことができる：
SELECT ?operationStatus
WHERE { ?device rdf:type base:Device
?device rdf:is-from CompanyA or CompanyB.
?device base:hasService ?service
?service base:hasOperation ?operation
?operation base:hasName OperationA
?operation base:hasStatus operationStatus
}

完全なセマンティッククエリをRH-SLN１２２に提示することもできることに留意されたい。RH-SLN１２２は、このクエリを処理するために、依然として、既存のセマンティックリソース発見を使用することができる。

ステップ２７２で、SQI１２１からセマンティッククエリを受信すると、RH-SLN１２２は、セマンティックフィルタに記憶された情報に基づいて、目標とするリソースを特定するために、既存のセマンティックリソース発見を実行する。特に、SQI１２１が完全なセマンティッククエリを送信した場合でも、RH-SLN１２２は、まず、関連するリソースを特定する。例えば、第５シナリオでは、３つの＜OperationA＞リソースが、目標とするリソースとして特定され得る。ステップ２７３で、目標とするリソースごとに、RH-SLN１２２は、このリソースから必要情報をさらに抽出して、それを最終結果セットに追加する。目標とするリソースから情報が抽出されると、それはSQI１２１に返信される。例えば、第５シナリオでは、３つの＜OperationA＞リソースの動作状態がセマンティッククエリ結果として抽出される。ステップ２７４では、RH-SLN１２２は、SQI１２１によって示されたようなフォーマットを用いたクエリ結果を含む応答メッセージをSQI１２１に返信する。あるいは、クエリ結果があまりに大量で、単一の応答メッセージで伝達できないため、RH-SLN１２２が、例えば、＜request＞リソースを用いて、クエリ結果を記憶するための新しいリソースを作成する可能性がある。次に、RH-SLN１２２は、SQI１２１に、クエリ結果を直接返さず、クエリ結果を記憶する新しく作成されたリソースのURIだけを返す。そこで、SQI１２１は、後ほど、自身でクエリ結果を読み出すことを選択することができる。

シナリオ５Ｂを参照すると、SQI１２１は、そのクエリを指定するために、依然として、既存のセマンティックフィルタインタフェースを使用することができる。一方、セマンティックフィルタは、目標とするリソースを特定する方法を指定することができる。シナリオ５Ａとは違って、SQI１２１は、目標とするリソースからどの情報を抽出する必要があるかということを指定しない。言い換えれば、ＳＱＩ１２１は、目標とするリソース発見のために、RH-SLN１２２に依存するだけである。目標とするリソースが特定され、SQI１２１に返信されると、SQI１２１は、さらに、自身で情報をそれらの目標とするリソースから抽出することができる。

図４３は、例示的なステップを示す。ステップ２８０に、前提条件があり得る。必要性に基づいて、SQIは、RH-SLNに関する何らかの情報を問い合わせる必要がある。例えば、SQIが、シナリオ５に例示するようなクエリの実行を意図すると仮定する。図３４を参照すると、ステップ２８１で、SQI１２１は、要求メッセージをRH-SLN１２２に送信し、その中で、セマンティックリソース発見を要求するだけである。セマンティックフィルタは要求メッセージに含まれ得る。セマンティックフィルタは、セマンティックリソース発見を通じて可能性のある目標となるリソースを特定する方法を指定することができる。第５シナリオに関して示される例では、セマンティックフィルタを以下のように（すなわち、すべてのOperationAリソースを発見するように）書くことができる：
SELECT ?operation
WHERE { ?device rdf:type base:Device
?device rdf:is-from CompanyA or CompanyB.
?device base:hasService ?service
?service base:hasOperation ?operation
?operation base:hasName OperationA
}

図３４を引き続き参照して、セマンティッククエリインジケータ（sq）は、SQI１２１が実行すべきセマンティッククエリを送信していること、すなわち、この要求はセマンティックリソース発見のためではなく、いくつかのRDFトリプルに基づく何らかの派生情報または知識を、意味論的に問い合わせまたは読み出すためであることを示す。oneM2Mの実施形態では、そのようなｓｑパラメータは新しい要求パラメータであり得る。あるいは、sqの効果を実現するために、filterCriteriaの既存のfilterUsageを使用することもできる。例えば、filterUsageに対して新しい値を定義して、この新しい値が出現していればセマンティッククエリ動作が引き起こされることを意味するようにすることができる。

ステップ２８２で、SQI１２１からセマンティッククエリを受信すると、RH-SLN１２２は、セマンティックフィルタに記憶された情報に基づいて、目標とするリソースを特定するために、既存のセマンティックリソース発見を実行する。ステップ２８３で、特定された目標とするリソースに対して、RH-SLN１２２は、それらの目標とするリソースを含むための＜group＞２４２リソースを作成することができる。ステップ２８４で、RH-SLN１２２は、＜group＞リソースのURIを返す応答メッセージをSQI１２１に返信する。ステップ２８５で、SQI１２１は、この＜group＞２４２リソースのfanoutPointにRETRIEVEを送信して、発見または目標とされたリソースから必要な値を読み出すことができる。

セマンティッククエリCSFおよび論理エンティティの例について、以下に論じる。oneM2Mは、現在、oneM2Mサービス層によってサポートされる能力の定義の過程にある。これらの機能は、能力サービス機能（Capability Service Function:CSF）と呼ばれる。oneM2Mサービス層は、能力サービスエンティティ（Capability Services Entity:CSE）２８７と呼ばれる。したがって、分散された＜semanticDescriptor＞リソースに対する開示されたセマンティッククエリは、図３５に示すように、サービス層における新しいCSF２８８と見なし得る。あるいは、それは、oneM2M TS-0001において定義された既存のセマンティック関連CSFの一部でもあり得る。本明細書に開示されている手順および新しいパラメータは、図３５に示すように、主としてmcaおよびmcc／mcc’参照点上で発生する。M2Mゲートウェイ、M2Mサーバ、M2Mデバイス等のような異なるタイプのM2Mノードが、セマンティッククエリサービスを実装し得る。特に、それらのノードのための異なるハードウェアまたはソフトウェア容量に応じて、それらのノードによって実装されるセマンティッククエリサービスの機能性または能力も変わる可能性がある。さらに、oneM2Mの文脈において、論理エンティティRH-SLN１２２は、物理的CSEとして具現化されてもよい。論理エンティティSQＩ１２１は、AEまたはCSEとして具現化されてもよい。

通常のoneM2Mリソースの属性について、以下に論じる。シナリオ２では、アプローチの１つは、本来はRDFフォーマットで提供されておらず、＜semanticDescriptor＞リソース内に記憶されている情報を表すために、RDFトリプルをさらに追加するというものであった。例えば、通常の通常のリソースＡからの情報Info-X（例えば、＜reading＞１１３リソースに記憶されている現在温度値３２）の場合、情報Info-Xを表すために新しいRDFトリプルが作成されたら、リソースＡのどの情報がRDFフォーマットで表されたかという事象を示すことも有益であり得る。これを行うために、新しい属性「duplicatedAsRDF」がリソースＡに対して定義され、「duplicatedAsRDF」の詳細な説明が表４に示されている。リソースＡは、＜AE＞、＜CSE＞、＜container＞、＜contentInstance＞等の、任意の既存または将来のリソースタイプであり得ることに留意されたい。

図４２は、第２シナリオおよび第４シナリオに関連する例示的な方法を示す。ステップ４２０１で、RH-SLN１２２は、センサに関連付けられた情報を取得することができる（例えば、＜reading＞１１３）。例示的なセンサは、加速度計、バイオメトリクスセンサ、または温度センサを含み得る。ステップ４２０２で、RH-SLN１２２は、センサに関連付けられた情報を＜contentInstance＞のような通常のリソースに組み込むことができる。ステップ４２０３で、RH-SLN１２２は、情報をトリプルとして表すsemanticDescriptorリソースをその情報のために作成することができる。ステップ４２０４で、RH-SLN１２２は、通常のリソース情報がトリプルとして複製されているというフラグを立てることができる。

新しい要求パラメータについて、以下に論じる。oneM２Mにおいて、SQI１２１はAE-1として具現化されることができ、RH-SLN１２２はCSE-1として具現化されることができる。第１ステップで、AE-1はCSE-1にセマンティッククエリを含む要求を送信する。第２ステップで、要求を受信すると、CSE-1はセマンティッククエリ処理を実行して、クエリ結果を出す。このステップは、本開示において最も焦点となる革新的なステップであり、このステップで行われるクエリ処理は場合によって異なることに留意されたい。第３ステップで、CSE-1はクエリ結果をAE-１に返す。oneM２Mの場合、AE-1がCSE-1に要求を送信するとき、その要求は、oneM2M RETRIEVE要求であり得る。本明細書で提示されたシナリオでは、セマンティッククエリ処理に若干の違いがあるため、例えば、新しいパラメータはRETRIEVE要求または応答メッセージに入れて伝達されてもよい。

以下は、これらのパラメータの概要であり、パラメータはoneM2Mリクエストまたは応答メッセージに含まれ得る。シナリオ１では、RETRIEVEメッセージは、とりわけ、以下の新しいパラメータを含むことができる：SQ、SE、QS、またはRF。シナリオ２およびシナリオ３では、RETRIEVEメッセージは、とりわけ、以下を含むことができる：SQ、QS、またはRF。シナリオ４に関連する基本的な解決策およびより強力な解決策の第１アプローチの場合、RETRIEVEメッセージは、とりわけ、SQ、QS、NQS、またはRFを含むことができ、一方、応答メッセージはQSを含むことができる。シナリオ４に関連するより強力な解決策の第２アプローチの場合、RETRIEVEメッセージはRDPを含むことができ、別のRETRIEVEメッセージは、とりわけ、SQ、QS、NQS、またはRFを含むことができ、一方、応答メッセージはQSを含むことができる。シナリオ５Ａの場合、RETRIEVEメッセージは、とりわけ、NIまたはSQを含むことができる。

新しいセマンティッククエリポータルリソース＜queryPortal＞。シナリオ４に対するより強力な解決策の第１アプローチのために、＜queryPortal＞２９０と呼ばれる新しいリソースが開示される（図３６参照）。＜queryPortal＞２９０は、それ自身のクエリ範囲を示す「queryScope」２９１と呼ばれる属性を持つことができる。したがって、＜queryPortal＞２９０リソースに送信されたすべてのセマンティッククエリは、その「queryScope」２９１属性によって示されるように、クエリ範囲内で実行される可能性がある。さらに、与えられたCSEが複数の＜queryPortal＞２９０リソースを含むことができ、それらの各々がそれ自身の「queryScope」２９１を持つ可能性がある。それらの＜queryPortal＞２９０リソースを通常のリソース発見等を通じて発見し、実行すべきクエリにとって望ましいものを選択することはSQI（例えば、AEまたはCSE）に委ねられる。＜queryPortal＞２９０リソースは、リソースが容易に発見されるように、＜CSEBase＞２１０の下に存することができる。＜queryPortal＞２９０リソースは、通常の作成、読み出し、更新、削除（Create, Read, Update, and Delete:CRUD）操作を通じて構成し得る。例えば、ホスティングCSEは、その知識に基づいて、＜queryPortal＞２９０リソースを管理するための自身のタスクを設定し、通常のリソース上で操作を実行することができる。その結果、セマンティッククエリが特定の＜QueryPortal＞リソースに送信されると、queryScope２９１属性に含まれるような関与する＜semanticDescriptor＞リソースが読み出され得る。その後、各＜semanticDescriptor＞リソース上でクエリが実行され、クエリ結果が返され得る。＜queryPortal＞２９０リソースは、表５に指定された属性を含むことができる。

＜queryPortal＞リソースに対する作成／読み出し／更新／削除操作を以下に開示する。表６に記載されているように、＜queryPortal＞リソースを作成するために作成＜queryPortal＞手順を用いることができる。

この＜queryPortal＞読み出し手順は、表７に記載されているように、＜QueryPortal＞リソースの属性を読み出すために使用され得る。

表８に記載されているような＜queryPortal＞更新手順は、既存の＜queryPortal＞の更新、例えば、そのqueryScopeの更新を行うために使用され得る。一般的な更新手順は［9］の10.1.3項に記載されている。

既存の＜queryPortal＞を削除するには、表９に記載されているような＜queryPortal＞削除手順を使用するものとする。一般的な削除手順は［9］の10.1.4.1項に記載されている。

＜queryPortal＞リソースを介したセマンティッククエリ処理手順。本節は、＜queryPortal＞リソースを介したセマンティッククエリ処理手順に関するoneM2Mの例を示す。図３７は、シナリオ４に対する＜queryPortal＞リソースを介したセマンティッククエリ処理のためのoneM2M中心の手順を示す。ステップ３００で、クエリポータルを作成するために、CSE２９６自身によって＜queryPortal-1＞リソースが作成された。ステップ３０１で、AE２９５は、CSE２９６によってホストされている＜queryPortal-1＞リソースを、通常のリソース発見を通じて発見する。ステップ３０２ａおよびステップ３０２ｂで、AE２９５は、クエリ範囲を示す「queryScope」属性にアクセスする。例えば、＜queryPortal-1＞リソースの「queryScope」は、＜CSE＞／＜CompanyA＞と＜CSE＞／＜CompanyB＞の２つのURIを含んでいる可能性がある。ステップ３０３で、AE２９５は、会社Ａと会社Ｂのデバイスに関する情報を問い合わせることを意図して、＜queryPortal-1＞リソースを望ましいクエリポータルとして選択する。AE２９５のクエリは、「会社Ａと会社Ｂのすべてのデバイスの動作の動作モードを返すこと。」であり得る。

ステップ３０４で、AE２９５は、（「To」パラメータによって示されるように）CSE２９６上の＜queryPortal-1＞リソースに向けたRETRIEVEを送信する。要求メッセージは、とりわけ、以下の新しいパラメータを含むことができる：SQ、QS、RF、またはNQS。ステップ３０５で、AE２９５からセマンティッククエリを受信すると、CSE２９６におけるクエリ処理が実行される。＜queryPortal-1＞リソースの「queryScope」は、＜CSE-1＞／＜CompanyA＞と＜CSE-1＞／＜CompanyB＞の２つのURIを含むため、それら２つのURIの下の＜semanticDescriptor＞リソースの特定を開始し得る。特に、すべての会社の＜Device＞１１１、＜Device＞１４６、および＜Device＞１４７の＜semanticDescriptor＞子リソースが、関与する＜semanticDescriptor＞リソースとして特定される。図２６を参照されたい。ステップ３０６で、CSE２９６は、特定のアクセス制御ポリシーに基づいて、可能性のある関与する＜semanticDescriptor＞リソースごとに、それに対してセマンティッククエリを実行できるかどうかをさらに評価する。実行できる場合、そのようなリソースは、正式な関与するリソースとなり得る。ステップ３０７で、正式な関与する＜semanticDescriptor＞リソースごとに、それに対するセマンティッククエリが実行される。有効なクエリ結果がある場合、そのクエリ結果は最終結果セットに追加され得る。一方、これらの正式な関与するリソースに対するクエリ処理は互いに独立して実行され得る。

ステップ３０８で、正式な関与するリソースがクエリに従って評価された後は、最終結果セットは、最終クエリ結果を含むことができ、AE２９５に返され得る。シナリオ４の例では、＜Device＞１１１、＜Device＞１４６、および＜Device＞１４７の動作の動作モードは、最終クエリ結果であり得る。ステップ３０９で、CSE-1は、AE２９５によって示されたような（ステップ４で示されたような）フォーマットを用いたクエリ結果を含む応答メッセージをAE２９５に返信する。さらに、メッセージはパラメータQSを含むことができる。パラメータQSはクエリ結果品質または要約情報を含む。それは、例えば、クエリがどの＜semanticDescriptor＞リソース上で実行されたかを示すことができる。AE２９５は、この情報を利用することにより、返されたクエリ結果が望ましく、かつ十分に正確であるかどうかを評価することができる。その他の情報は、クエリ処理時間費用等を含み得る。

本明細書で論じるように、分散されたセマンティック記述子に対するセマンティッククエリのための例示的なユーザインタフェースについて、以下に論じる。図３８は、セマンティッククエリ範囲チェックのための例示的なユーザインタフェースを示す。グラフィカルユーザインタフェース（Graphical User Interface:GUI）３１０は、特定の＜semanticGroup＞リソースのクエリ範囲をチェックするために使用され得る。チェックの対象となる＜semanticDescriptor＞リソースのURIをブロック３１１に入力することによって、そのメンバーリソース、例えば、関与する＜semanticDescriptor＞リソースを表示することができる。特に、メンバーリソースの中には、それに応じて受信したURIと同じノード上になり得ない。URI入力が指しているノード上のメンバーリソースのチェックするためのオプション３１２がある。

図３９は、セマンティッククエリランチャのための例示的なユーザインタフェースを示す。GUIインタフェース３２０は、セマンティッククエリを起動するために使用され得る。理解できるように、パラメータの値は、本明細書に開示されているように受信することができる。ロック３１６は＜semanticQuery＞リソース用に使用することができ、ブロック３１７はクエリステートメント入力用に使用することができ、ブロック３１８はクエリ結果のフォーマット用に使用することができ、クエリ要約が必要かどうかを示すブロック３１９があってもよい。したがって、入力に基づいて、セマンティッククエリメッセージを生成して、処理のために送信することができる。図４０は、セマンティッククエリ結果表示のための例示的なユーザインタフェースを示す。セマンティッククエリ結果が返された後、結果をブロック３２１内のセマンティッククエリ結果GUI３２０上に表示することができる。ブロック３２２はクエリ要約を表示する。例においては、図４０に示す結果は、（ユーザによって要求されたような）会社Ａと会社ＢのすべてのデバイスのOperationAの動作状態である。さらに、クエリ要約情報も返され、そこにはクエリ処理関連情報が示されている。

本明細書に記載の特許請求の範囲、解釈、または適用を決して過度に限定することなく、本明細書に開示されている１つまたは複数の例の技術的効果は、セマンティッククエリを調整することである。現在、分散されたセマンティック記述子（例えば、oneM2M＜semanticDescriptor＞リソース）に対して直接的にセマンティッククエリを処理するための既存の解決策はない。本明細書で論じた方法およびシステムは、本明細書で論じたようなセマンティッククエリを可能にする。開示された主題は、単一のリソースに対する直接的なクエリ処理を直接実行する（例えば、単一の＜semanticDescriptor＞だけからの情報のみを使用する）ことを可能にする。開示された主題は、セマンティック記述子内に記憶されていない情報を用いたセマンティッククエリを可能にする。開示された主題は、異なった無関係のセマンティック記述子に分散されたセマンティッククエリを可能にする。これは、セマンティッククエリに対する「クエリ範囲」を決定することを含み得る。開示された主題は、異なるが関連するセマンティック記述子内に分散されたセマンティッククエリを可能にする。これは、セマンティッククエリに要する十分な情報を提供するために、既存の「resourceDescriptorLink」プロパティの使用を用いて、関連する＜semanticDescriptor＞リソースを共にリンクできるようにすることを含み得る。開示されている主題は、既存のセマンティックリソース発見を利用することによって、目標とするリソースからの情報を間接的に問い合わせることを可能にする。これは、セマンティッククエリのユーザから問い合わされ、求められている、リソースツリー内に記憶された情報をさらに読み出すために、セマンティックリソース発見メカニズムを利用する手順を含み得る。

図４１Ａは、分散されたセマンティック記述子に対するセマンティッククエリに関連する１つまたは複数の開示された概念（例えば、図１０〜図３９および付随する説明）を実装することができる例示的なマシンツーマシン（M2M）、モノのインターネット（IoT）、またはモノのウェブ（Web of Things:WoT）通信システム１０の図である。一般に、M2M技術は、IoT／WoTのためのビルディングブロックを提供し、任意のM2Mデバイス、M2Mゲートウェイ、またはM2Mサービスプラットフォームは、IoT／WoTおよびIoT／WoTサービス層等の構成要素であり得る。

図４１Ａに示すように、M2M／IoT／WoT通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、Ethernet（登録商標）、ファイバ、ISDN、PLC等）または無線ネットワーク（例えばWLAN、セルラー等）または異種ネットワークからなるネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージ通信、放送等のコンテンツを複数のユーザに提供する多元接続ネットワークから構成され得る。例えば、通信ネットワーク１２は、符号分割多元接続（Code Division Multiple Access:CDMA）、時分割多元接続（Time Division Multiple Access:TDMA）、周波数分割多元接続（Frequency Division Multiple Access:FDMA）、直交FDMA（Orthogonal FDMA:OFDMA）、単一キャリアFDMA（Single-Carrier FDMA:SC−FDMA）等の１つまたは複数のチャネルアクセス方式を採用し得る。さらに、通信ネットワーク１２は、コアネットワーク、インターネット、センサネットワーク、産業用制御ネットワーク、パーソナルエリアネットワーク、融合パーソナルネットワーク、衛星ネットワーク、家庭用ネットワーク、または企業ネットワーク等の他のネットワークを含んでもよい。

図４１Ａに示すように、M2M／IoT／WoT通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含み得る。インフラストラクチャドメインとはエンドツーエンドM2M展開のネットワーク側を指し、フィールドドメインとは通常M2Mゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインは、M2Mゲートウェイ１４および端末デバイス１８を含む。必要に応じて、任意の数のM2Mゲートウェイデバイス１４およびM2M端末デバイス１８がM2M／IoT／WoT通信システム１０に含まれ得ることが理解され得る。M2Mゲートウェイデバイス１４およびM2M端末デバイス１８のそれぞれは、通信ネットワーク１２または直接無線リンクを介して信号を送受信するように構成されている。M2Mゲートウェイデバイス１４により、無線M2Mデバイス（例えばセルラーおよび非セルラー）ならびに固定ネットワークM2Mデバイス（例えばPLC）は通信ネットワーク１２または直接無線リンク等のオペレータネットワークを介して通信できる。例えば、M2Mデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介してM2Mアプリケーション２０またはM2Mデバイス１８にデータを送信し得る。M2Mデバイス１８はまた、M2Mアプリケーション２０またはM2Mデバイス１８からデータを受信し得る。さらに、以下に説明するように、データおよび信号は、M2Mサービス層２２を介してM2Mアプリケーション２０に送受信され得る。M2Mデバイス１８およびゲートウェイ１４は、例えば、セルラー、WLAN、WPAN（例えば、Zigbee、6LoWPAN、Bluetooth）、直接無線リンク、および有線を含む種々のネットワークを介して通信し得る。

図４１Ｂを参照すると、フィールドドメイン内の図示されているM2Mサービス層２２（例えば、本明細書で説明されるようなRH-SLN１２２またはCSE２９６）は、M2Mアプリケーション２０（例えば、AE295またはSQI121）、M2Mゲートウェイデバイス１４、M2M端末デバイス１８、および通信ネットワーク１２にサービスを提供する。M2Mサービス層２２は、必要に応じて、任意の数のM2Mアプリケーション、M2Mゲートウェイデバイス１４、M2M端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解され得る。M2Mサービス層２２は、１つまたは複数のサーバ、コンピュータ等によって実装され得る。M2Mサービス層２２は、M2M端末デバイス１８、M2Mゲートウェイデバイス１４およびM2Mアプリケーション２０に適用されるサービス機能を提供する。M2Mサービス層２２の機能は、例えばウェブサーバとして、セルラーコアネットワークにおいて、クラウドにおいて等、種々の方法で実装され得る。

図示されたM2Mサービス層２２と同様に、インフラストラクチャドメイン内にM2Mサービス層２２’がある。M2Mサービス層２２’は、インフラストラクチャドメインにおいてM2Mアプリケーション２０’および下層通信ネットワーク１２’にサービスを提供する。M2Mサービス層２２’はさらに、フィールドドメインにおいてM2Mゲートウェイデバイス１４およびM2M端末デバイス１８にサービスを提供する。M2Mサービス層２２’は、任意の数のM2Mアプリケーション、M2MゲートウェイデバイスおよびM2M端末デバイスと通信し得ることが理解され得る。M2Mサービス層２２’は、異なるサービスプロバイダによってサービス層と対話し得る。M2Mサービス層２２’は、１つまたは複数のサーバ、コンピュータ、仮想マシン（例えば、クラウド／コンピュータ／ストレージファーム等）等によって実装され得る。

さらに図４１Ｂを参照すると、M2Mサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用し得るサービス提供機能のコアセットを提供する。これらのサービス機能により、M2Mアプリケーション２０および２０’は、デバイスと対話し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイス発見等の機能を実行することが可能になる。基本的に、これらのサービス機能により、アプリケーションにこれらの機能を実装する負担が加わらなくなるため、アプリケーション開発を簡素化し、製品化までの費用および時間を削減する。サービス層２２および２２’によってさらに、M2Mアプリケーション２０および２０’はサービス層２２および２２’が提供するサービスに関連する種々のネットワーク１２および１２’を介して通信できる。

いくつかの例では、M2Mアプリケーション２０および２０’には、分散されたセマンティック記述子に対するセマンティッククエリに関連するメッセージを用いて通信する望ましいアプリケーションが含まれ得る。M2Mアプリケーション２０および２０’には、運輸、健康およびウェルネス、コネクテッドホーム、エネルギー管理、資産管理、セキュリティ、および監視等であるが、これらに限られない各種業界におけるアプリケーションが含まれ得る。上述のように、システムのデバイス、ゲートウェイ、および他のサーバを横断するＭ２Ｍサービス層は、データ収集、デバイス管理、セキュリティ、請求、位置追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、これらの機能をM2Mアプリケーション２０および２０’に対するサービスとして提供する。

本出願の分散されたセマンティック記述子に対するセマンティッククエリは、サービス層の一部として実装され得る。サービス層は、アプリケーションプログラミングインタフェース（Application Programming Interface:API）および下層のネットワークインタフェースのセットを介して付加価値サービス能力をサポートするミドルウェア層である。M2Mエンティティ（例えば、デバイス、ゲートウェイ、またはハードウェア上に実装されるサービス／プラットフォーム等のM2M機能エンティティ）は、アプリケーションまたはサービスを提供することができる。欧州電気通信標準化機構（European Telecommunications Standards Institute:ETSI）のM2MとoneM2Mは、両方とも、本出願の分散されたセマンティック記述子に対するセマンティッククエリを含むことができるサービス層を使用する。oneM2Mサービス層は、共通サービス機能（CSF）のセット（すなわち、サービス能力）をサポートする。１つまたは複数の特定の種類のCSFのセットのインスタンス化は、共通サービスエンティティ（CSE）と呼ばれ、異なるタイプのネットワークノード（例えば、インフラストラクチャノードや、中間ノードや、アプリケーション固有ノード）上でホストされ得る。さらに、本出願の分散されたセマンティック記述子に対するセマンティッククエリは、サービス指向アーキテクチャ（Service Oriented Architecture:SOA）またはリソース指向アーキテクチャ（Resource Oriented Architecture:ROA）を使用して本出願の分散されたセマンティック記述子に対するセマンティッククエリ等のサービスにアクセスするM2Mネットワークの一部として実装され得る。

本明細書で論じるように、サービス層は、ネットワークサービスアーキテクチャ内の機能層であり得る。サービス層は典型的には、HTTP、CoAPまたはMQTT等のアプリケーションプロトコル層上に位置し、クライアントアプリケーションに付加価値サービスを提供する。サービス層はまた、例えば制御層およびトランスポート／アクセス層等のより低いリソース層でコアネットワークへのインタフェースを提供する。サービス層は、サービス定義、サービスランタイムの有効化、ポリシー管理、アクセス制御およびサービスクラスタリングを含む、複数のカテゴリーの（サービス）能力または機能をサポートする。近年、いくつかの業界標準化団体、例えば、ｏｎｅＭ２Ｍは、インターネット／ウェブ、セルラー、企業、および家庭用ネットワーク等の展開へのM2Mタイプのデバイスおよびアプリケーションの統合に関連する課題を解決するためにM2Mサービス層を開発している。M2Mサービス層は、CSEまたはSCLと呼ばれ得るサービス層によってサポートされる上述の能力または機能の集合またはセットへのアクセスにより、種々のデバイスにおけるアプリケーションに提供し得る。いくつかの例としては、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニングおよび接続性管理（種々のアプリケーションによって共通して用いられ得る）が挙げられるが、これらに限定されない。これらの能力または機能は、M2Mサービス層によって定義されたメッセージフォーマット、リソース構造およびリソース表現を利用するAPIを介してそのような種々のアプリケーションで利用可能となる。CSEまたはSCLは、ハードウェアまたはソフトウェアによって実装され得、かつ種々のアプリケーションまたはデバイス（すなわち、機能エンティティ間の機能インタフェース）が（サービス）能力または機能を使用するために、それらに公開されるそのような能力または機能を提供する機能エンティティである。

図４１Ｃは、例えばM2M端末デバイス１８（AE２９５またはSQI１２１を含み得る）またはM2Mゲートウェイデバイス１４（図３０または図２０の１つまたは複数のコンポーネントを含み得る）等の例示的なM2Mデバイス３０のシステム図である。図４１Ｃに示されるように、M2Mデバイス３０は、プロセッサ３２、トランシーバ３４、送信／受信要素３６、スピーカ／マイクロフォン３８、キーパッド４０、ディスプレイ／タッチパッド４２、取り外し不能メモリ４４、取り外し可能メモリ４６、電源４８、全地球測位システム（Global Positioning System:GPS）チップセット５０およびその他周辺機器５２を備え得る。M2Mデバイス３０は、開示された主題との整合性を保ちながら、前述の要素の任意の副組み合わせを備え得ることが理解され得る。M2Mデバイス３０（例えば、AE２９５、SQI１２１、RH-SLN１２２、CSE２９６等）は、分散されたセマンティック記述子に対するセマンティッククエリのための開示されたシステムおよび方法を実行する例示的な実施態様であり得る。

プロセッサ３２は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（Digital Signal Processor:DSP）、複数のマイクロプロセッサ、DSPコアに関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit:ASIC）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array:FPGA）回路、任意の他のタイプの集積回路（Integrated Circuit:IC）、状態機械等であり得る。プロセッサ３２は、信号符号化、データ処理、出力制御、入力／出力処理、またはM2Mデバイス３０が無線環境で動作することを可能にする他の任意の機能を実行し得る。プロセッサ３２はトランシーバ３４と結合され得、トランシーバ３４は送信／受信要素３６と結合され得る。図４１Ｃは、プロセッサ３２およびトランシーバ３４を別個のコンポーネントとして図示しているが、プロセッサ３２およびトランシーバ３４は、電子パッケージまたはチップに一緒に統合されてもよいことが理解され得る。プロセッサ３２は、アプリケーション層プログラム（例えばブラウザ）または無線アクセス層（RAN）プログラムまたは通信を実行し得る。プロセッサ３２は、例えばアクセス層またはアプリケーション層等での認証、セキュリティ鍵合意または暗号操作等のセキュリティ操作を実行し得る。

送信／受信要素３６は、M2Mサービスプラットフォーム２２に信号を送信するか、またはM2Mサービスプラットフォーム２２から信号を受信するように構成され得る。例えば、送信／受信要素３６は、RF信号を送信または受信するように構成されたアンテナであり得る。送信／受信要素３６は、WLAN、WPAN、セルラー等の種々のネットワークおよびエアインタフェースをサポートし得る。一例では、送信／受信要素３６は、例えばIR、UVまたは可視光信号を送信または受信するように構成されたエミッタ／検出器であり得る。さらに別の例では、送信／受信要素３６は、ＲＦ信号および光信号の両方を送信および受信するように構成され得る。送信／受信要素３６は、無線信号または有線信号の任意の組み合わせを送信または受信するように構成され得ることが理解され得る。

加えて、送信／受信要素３６は図４１Ｃに単一の要素として図示されているが、M2Mデバイス３０は、任意の数の送信／受信要素３６を備え得る。より具体的には、M2Mデバイス３０は、MIMO技術を採用し得る。したがって、一例では、M2Mデバイス３０は、無線信号を送信および受信するための２つ以上の送信／受信要素３６（例えば、複数のアンテナ）を備え得る。

トランシーバ３４は、送信／受信要素３６によって送信される信号を変調し、送信／受信要素３６によって受信される信号を復調するように構成され得る。上述のように、M2Mデバイス３０はマルチモード機能を有し得る。したがって、トランシーバ３４は、M2Mデバイス３０が、例えばUTRAおよびIEEE802.11等の複数のRATを介して通信することを可能にするための複数のトランシーバを含み得る。

プロセッサ３２は、取り外し不可能なメモリ４４または取り外し可能なメモリ４６等の任意のタイプの適切なメモリからの情報にアクセスし、そこにデータを記憶させることができる。取り外し不可能なメモリ４４は、ランダムアクセスメモリ（Random-access Memory：RAM）、読み出し専用メモリ（Read-Only Memory：ROM）、ハードディスク、または他の任意のタイプのメモリ記憶装置を含み得る。取り外し可能なメモリ４６は、加入者識別モジュール（Subscriber Identity Module：SIM）カード、メモリスティック、セキュアデジタル（secure digital：SD）メモリカード等を含み得る。他の例では、プロセッサ３２は、例えば、サーバまたは家庭用コンピュータ上などの、M2Mデバイス３０上に物理的に位置していないメモリからの情報にアクセスし、そこにデータを記憶させることができる。プロセッサ３２は、本明細書に記載のいくつかの例における分散されたセマンティック記述子に対するセマンティッククエリが成功か不成功かに応じて、ディスプレイまたはインジケータ４２上の点灯パターン、画像、または色を制御するか、そうでなければ、分散されたセマンティック記述子に対するセマンティッククエリの状態を示すように構成され得る。ディスプレイまたはインジケータ４２上の点灯パターン、画像、または色の制御は、本明細書で図示されるか説明されている図中（例えば、図１０〜図３７等）の方法のフローまたは構成要素のうちのどれかの状態を反映することができる。本明細書では、分散されたセマンティック記述子と関連するコンポーネントに対するセマンティッククエリのメッセージおよび手順が開示されている。メッセージおよび手順は、ユーザが、分散されたセマンティック記述子に対するセマンティッククエリを入力源（例えば、スピーカ／マイクロフォン３８、キーパッド４０、またはディスプレイ／タッチパッド４２）を介して要求し、とりわけ、ディスプレイ４２上に表示可能なリソースの分散されたセマンティック情報を要求、構成、または問い合わせるためのインタフェース／APIを提供するように拡張され得る。

プロセッサ３２は、電源４８から電力を受け取ることができ、M2Mデバイス３０内の他のコンポーネントに電力を分配または制御するように構成され得る。電源４８は、M2Mデバイス３０に電力供給する任意の適切なデバイスであり得る。例えば、電源４８としては、１つまたは複数の乾電池（例えば、ニッケル−カドミウム（NiCd）、ニッケル−亜鉛（NiZn）、ニッケル水素化物（NiMH）、リチウムイオン（Liイオン）等）、太陽電池、燃料電池等を挙げることができる。

プロセッサ３２はさらに、M2Mデバイス３０の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成されたGPSチップセット５０と結合され得る。M2Mデバイス３０は、本明細書に開示された情報と整合性を保ちながら、任意の適切な位置決定方法によって位置情報を取得し得ることが理解され得る。

プロセッサ３２はさらに、他の周辺機器５２と結合され得、他の周辺機器５２としては、追加の特徴、機能または有線もしくは無線接続性を提供する１つまたは複数のソフトウェアまたはハードウェアモジュールを挙げることができる。例えば、周辺機器５２としては、種々のセンサ、例えば、加速度計、バイオメトリクス（例えば指紋）センサ、ｅ−コンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（Universal Serial Bus：USB）ポート、または他の相互接続インタフェース、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Bluetooth（登録商標）モジュール、周波数変調（Frequency Modulated：FM）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を挙げることができる。

送信／受信要素３６は、センサ、家庭用電化製品、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療デバイスまたはｅヘルスデバイス、ロボット、産業機器、ドローン、自動車、トラック、電車または航空機等の車両のような他の装置またはデバイスに組み込まれ得る。送信／受信要素３６は、周辺機器５２のうちの１つを備え得る相互接続インタフェース等の１つまたは複数の相互接続インタフェースを介してそのような装置またはデバイスの他のコンポーネント、モジュールまたはシステムに接続し得る。

図４１Ｄは、例えば、図４１Ａおよび図４１ＢのM2Mサービスプラットフォーム２２を実装することができる、例示的なコンピューティングシステム９０のブロック図である。コンピューティングシステム９０（例えば、M2M端末デバイス１８またはM2Mゲートウェイデバイス１４）は、コンピュータまたはサーバを備えることができ、主としてコンピュータ可読命令によって、そのような命令が記憶またはアクセスされるいかなる手段によっても制御され得る。そのようなコンピュータ可読命令は、コンピューティングシステム９０を稼働させる中央処理装置（Central Processing Unit：CPU）９１内で実行されてもよい。多くの公知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１はマイクロプロセッサと呼ばれるシングルチップCPUによって実装される。他のマシンでは、中央処理装置９１は複数のプロセッサを含むことができる。コプロセッサ８１は、メインCPU９１とは異なり、追加機能を実行したりCPU９１を支援したりするオプションのプロセッサである。CPU９１またはコプロセッサ８１は、分散されたセマンティック記述子に対するセマンティッククエリのための開示されたシステムおよび方法に関連する、queryScope、QS、NI、NQS、RF等のデータを受信、生成、および処理することができる。

動作中、CPU９１は、命令をフェッチし、復号し、実行し、コンピュータのメインデータ転送経路であるシステムバス８０を介して他のリソースとの間で情報を転送する。このようなシステムバスはコンピューティングシステム９０のコンポーネント同士を接続し、データ交換用の媒体を規定する。典型的には、システムバス８０は、データを送信するデータ回線、アドレスを送信するアドレス回線、および割込みを送信し、システムバスを動作させる制御回線を備える。そのようなシステムバス８０の例は、PCI（Peripheral Component Interconnect）バスである。

システムバス８０に結合されたメモリデバイスは、ランダムアクセスメモリ（RAM）８２および読み取り専用メモリ（ROM）９３を含む。このようなメモリは、情報を記憶および検索することを可能にする回路機構を備える。ROM９３は一般に、容易に修正できない記憶データを含む。RAM８２に記憶されたデータは、CPU９１または他のハードウェアデバイスによって読み取りまたは変更され得る。RAM８２またはROM９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されるときに仮想アドレスを物理アドレスに変換するアドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを隔離し、システムプロセスをユーザプロセスから隔離するメモリ保護機能を提供し得る。したがって、第１のモードで動作しているプログラムは、それ自身のプロセス仮想アドレス空間によってマップされたメモリのみにアクセスでき、プロセス間のメモリ共有が設定されていない限り、他のプロセスの仮想アドレス空間内のメモリにはアクセスできない。

さらに、コンピューティングシステム９０は、CPU９１からの命令をプリンタ９４、キーボード８４、マウス９５およびディスクドライブ８５等の周辺機器に伝達する役割を果たす周辺機器コントローラ８３を備え得る。

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成された視覚的出力を表示するために使用される。そのような視覚的出力としては、テキスト、グラフィックス、動画およびビデオを挙げることができる。ディスプレイ８６は、CRTベースのビデオディスプレイ、LCDベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイまたはタッチパネルを用いて実現され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するのに必要な電子部品を備える。

さらに、コンピューティングシステム９０は、コンピューティングシステム９０を図４１Ａおよび図４１Ｂのネットワーク１２等の外部通信ネットワークに接続するために使用され得るネットワークアダプタ９７を備え得る。

本明細書に記載のシステム、方法およびプロセスのいずれかまたはすべては、コンピュータ可読記憶媒体に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形で具現化され得、この命令は、コンピュータ、サーバ、M2M端末デバイス、M2Mゲートウェイデバイス等の機械により実行されたときに、本明細書に記載のシステム、方法およびプロセスを実行または実施することを理解されたい。具体的には、上記のステップ、操作または機能のいずれも、そのようなコンピュータ実行可能命令の形で実施され得る。コンピュータ可読記憶媒体は、情報を記憶するための任意の方法または技術において実装される揮発性および不揮発性、取り外し可能および取り外し不能の媒体の両方を含むことができるが、そのようなコンピュータ可読記憶媒体は信号自体を含まない。本明細書の説明から明らかなように、記憶媒体は法定で定められた主題であると解釈されるべきである。コンピュータ可読記憶媒体としては、RAM、ROM、EEPROM、フラッシュメモリもしくは他のメモリ技術、CD-ROM、デジタルバーサタイルディスク（Digital Versatile Disk：DVD）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶デバイスもしくは他の磁気記憶デバイス、または所望の情報を格納するために使用可能で、コンピュータによってアクセス可能な任意の他の物理的媒体が挙げられる。

図中に示す本開示の主題（分散されたセマンティック記述子に対するセマンティッククエリ）の好ましい方法、システムまたは装置を説明するにあたって、明確さを期して特定の用語が使用される。しかしながら、特許請求される主題は、そのように選択された特定の用語に限定されることを意図しておらず、各特定の要素は、類似の目的を果たすために同様の方法で動作するすべての技術的等価物を包含することを理解されたい。

本明細書に記載の種々の技術は、ハードウェア、ファームウェア、ソフトウェア、または適切な場合にはそれらの組み合わせと関連して実施され得る。そのようなハードウェア、ファームウェアおよびソフトウェアは、通信ネットワークのさまざまなノードに配置されている装置に常駐し得る。装置は、本明細書に記載の方法を実現するために、単独でまたは互いに組み合わせて動作し得る。本明細書で使用されるとき、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、「ネットワークノード」等は同じ意味で用いられ得る。

本明細書は、実施例を使用して、最良の形態を含む本発明を開示し、また、当業者が任意のデバイスまたはシステムを製造および使用することおよび任意の組み込まれた方法を実行することを含めて、本発明を実施することを可能にする。本発明の特許性のある範囲は特許請求の範囲によって定義されており、当業者が想起する他の例（例えば、本明細書に開示されている例示的方法のステップの省略、ステップの組み合わせ、またはステップの追加）を含み得る。そのような他の例は、それらが請求項の文字通りの言語と異ならない構造要素を有する場合、またはそれらが請求項の文字通りの言語との非実質的な相違を伴う同等の構造要素を含む場合、請求項の範囲内にあることが意図されている。

とりわけ、本明細書で説明されるような方法、システム、および装置は、分散されたセマンティック記述子に対するセマンティッククエリのための手段を提供することができる。方法、システム、コンピュータ可読記憶媒体、または装置は、セマンティック記述子リソースがリソース記述子リンク注釈を有するクラスインスタンスを含むことを決定し、そして、セマンティック記述子リソースが第１リソースへのリソース記述子リンク注釈を有するクラスインスタンスを含むとの決定に応答して、リソース記述子リンク注釈によってリンクされた第１リソースのコンテンツをセマンティック記述子リソースに追加するための手段を有する。セマンティック記述子リソースがリソース記述子リンク注釈を有するクラスインスタンスを含むとの決定は、セマンティック記述子リソースのセマンティッククエリに対する応答であり得る。第１リソースのコンテンツは、トリプルまたはリソース記述フレームワークトリプルを含む。方法、システム、コンピュータ可読記憶媒体、または装置は、第１リソースのコンテンツを追加した後にセマンティック記述子リソースに対してセマンティッククエリを実行するための手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、実行されたセマンティッククエリの結果を提供するための手段を有し、その結果は、セマンティッククエリの要求において受信されたフォーマット命令に基づき得る。セマンティッククエリの要求は、セマンティック記述子リソースがリソース記述子リンク注釈を有するクラスインスタンスを含むとの決定の前に行われる。セマンティック記述子リソースは子リソースであり得る。方法、システム、コンピュータ可読記憶媒体、または装置は、実行されたクエリに関連する結果をディスプレイに提供するための手段を有し、その結果はクエリ要約を含む。ディスプレイは携帯機器と接続され得る。いくつかの実装においては、セマンティック記述子リソースは他の代わりのリソースであり得る。本段落におけるすべての組み合わせ（ステップの削除または追加を含む）は、詳細な説明の他の部分と整合するように意図されている。

とりわけ、本明細書で説明されるような方法、システム、および装置は、分散されたセマンティック記述子に対するセマンティッククエリのための手段を提供することができる。方法、システム、コンピュータ可読記憶媒体、または装置は、センサからの、またはセンサに関連した情報（例えば、センサからの読取値）の取得と、センサに関連した情報の通常のリソースへの提供と、その情報のために第１semanticDescriptorリソースの作成、ここで第１semanticDescriptorリソースはその情報をトリプルとして表し、そして第１semanticDescriptorリソースの作成に基づいて、情報がトリプルとして複製されていることを通常のリソースの属性において示すことを実行するための手段を有する。センサを開示しているが、他のデバイス（特にM2Mデバイス）を使用してもよいと考えられる。本段落におけるすべての組み合わせ（ステップの削除または追加を含む）は、詳細な説明の他の部分と整合するように意図されている。

とりわけ、本明細書で説明されるような方法、システム、および装置は、分散されたセマンティック記述子に対するセマンティッククエリのための手段を提供することができる。方法、システム、コンピュータ可読記憶媒体、または装置は、セマンティッククエリを含む要求メッセージの受信と、要求メッセージの受信に応答した、セマンティック記述子リソースに対するセマンティッククエリの実行と、そしてセマンティック記述子リソースがリソース記述子リンク注釈を有するノードを含むとの決定に基づいた、セマンティッククエリの実行の停止を行うための手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、単一のリソースに対して直接クエリ処理を実行するための手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、セマンティッククエリによって必要とされる十分な情報を提供するために、「resourceDescriptorLink」プロパティを用いて、関連するセマンティック記述子リソースが共にリンクされるようにするための手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、どのセマンティック記述子を使用するかを決定するためにセマンティッククエリのための「クエリ範囲」を使用するための手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、セマンティッククエリに応答して、セマンティックリソース発見を使用して、リソースツリーに記憶されている情報を読み出すための手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、センサのデータ読取値の取得と、データ読取値の通常のリソース（例えば、constentInstance）への提供と、そして、データ読取値の通常のリソースへの提供に基づいて、データ読取値をトリプル（例えば、RDFトリプル）として表す、通常のリソースのための第１semanticDescriptorリソースの作成を実行するための手段を有する。第１semanticDescriptorリソースは、センサの更新されたデータ読取値を取得するために、別の装置の第２semanticDescriptorリソースとリンクされ得る。第１semanticDescriptorリソースは、統一資源識別子（Uniform Resource Identifier:URI）を介して第２semanticDescriptorリソースとリンクされ得る。方法、システム、コンピュータ可読記憶媒体、または装置は、セマンティック推論を用いてデータ読取値の測定単位を取得するための手段を有する。属性の記憶情報が既にRDFフォーマットとして表されていることを示すフラグがあり得る。方法、システム、コンピュータ可読記憶媒体、または装置は、センサに関連する情報の取得と、センサに関連する情報の通常のリソースへの提供と、そして、その情報のための第１semanticDescriptorリソースの作成を実行するための手段を有する。第１semanticDescriptorリソースは、情報をトリプルとして表すことができる。情報は、第１semanticDescriptorリソースの作成に基づいて、トリプルとして複製されたものとして示され得る。方法、システム、コンピュータ可読記憶媒体、または装置は、セマンティッククエリを含む要求メッセージを取得し、そして、第１セマンティック記述子リソースが複数ノードのうちリソース記述子リンク注釈を有する第１ノードを含むとの決定に基づいて、セマンティッククエリの実行を停止するための手段を有する。本段落におけるすべての組み合わせ（ステップの削除または追加を含む）は、詳細な説明の他の部分と整合するように意図されている。

Claims (20)

1. 分散されたセマンティック記述子に対するセマンティッククエリのための装置であって、
   プロセッサと、
   前記プロセッサに接続されたメモリと、を備え、
   前記メモリは実行可能な命令を備え、前記実行可能な命令は前記プロセッサによって実行されたとき、前記プロセッサに、
   センサに関連する情報を取得することと、
   前記センサに関連する前記情報を通常のリソースに提供することと、
   前記情報をトリプルとして表す、前記情報のための第１semanticDescriptorリソースを作成することと、
   前記第１semanticDescriptorリソースが作成されたことに基づいて、前記情報がトリプルとして複製されていることを、前記通常のリソースの属性において示すことと、を含む動作を実行させることを特徴とする装置。
2. 前記通常のリソースはcontentInstanceリソースであることを特徴とする、請求項１に記載の装置。
3. 前記第１semanticDescriptorリソースは、前記センサからの測定値である更新された情報を前記センサから取得するための、別の装置の第２semanticDescriptorリソースとリンクされることを特徴とする、請求項１に記載の装置。
4. 前記第１semanticDescriptorリソースは、更新された情報を前記センサから取得するための、別の装置の第２semanticDescriptorリソースとリンクされ、第１semanticDescriptorリソースは統一資源識別子（Uniform Resource Identifier:URI）を介して第２semanticDescriptorリソースとリンクされることを特徴とする、請求項１に記載の装置。
5. 前記動作は、前記情報の測定単位を示すセマンティックメタデータを取得することをさらに含むことを特徴とする、請求項１に記載の装置。
6. 前記動作は、セマンティック推論を用いて前記情報の測定単位を取得することをさらに含むことを特徴とする、請求項１に記載の装置。
7. 前記第１semanticDescriptorは前記通常のリソースの子リソースであることを特徴とする、請求項１に記載の装置。
8. センサに関連する情報を取得することと、
   前記センサに関連する前記情報を通常のリソースに提供することと、
   前記情報をトリプルとして表す、前記情報のための第１semanticDescriptorリソースを作成することと、
   前記第１semanticDescriptorリソースが作成されたことに基づいて、前記情報がトリプルとして複製されていることを、前記通常のリソースの属性において示すことを含むことを特徴とする方法。
9. 前記通常のリソースはcontentInstanceリソースであることを特徴とする、請求項８に記載の方法。
10. 前記第１semanticDescriptorリソースは、前記センサからの測定値である更新された情報を前記センサから取得するための、別の装置の第２semanticDescriptorリソースとリンクされることを特徴とする、請求項８に記載の方法。
11. 前記第１semanticDescriptorリソースは、更新された情報を前記センサから取得するための、別の装置の第２semanticDescriptorリソースとリンクされ、前記第１semanticDescriptorリソースは統一資源識別子（Uniform Resource Identifier:URI）を介して第２semanticDescriptorリソースとリンクされることを特徴とする、請求項８に記載の方法。
12. 前記情報の測定単位を示すセマンティックメタデータを取得することをさらに含むことを特徴とする、請求項８に記載の方法。
13. セマンティック推論を用いて前記情報の測定単位を取得することをさらに含むことを特徴とする、請求項８に記載の方法。
14. 前記第１semanticDescriptorは前記通常のリソースの子リソースであることを特徴とする、請求項８に記載の方法。
15. コンピュータ実行可能命令を記憶するコンピュータ可読記憶媒体であって、前記コンピュータ実行可能命令はコンピューティングデバイスによって実行されたとき、前記コンピューティングデバイスに、
    センサに関連する情報を取得することと、
    前記センサに関連する前記情報を通常のリソースに提供することと、
    前記情報をトリプルとして表す、前記情報のための第１semanticDescriptorリソースを作成することと、
    前記第１semanticDescriptorリソースが作成されたことに基づいて、前記情報がトリプルとして複製されていることを、前記通常のリソースの属性において示すことと、を含む動作を実行させることを特徴とするコンピュータ可読記憶媒体。
16. 前記通常のリソースはcontentInstanceリソースであることを特徴とする、請求項１５に記載のコンピュータ可読記憶媒体。
17. 前記第１semanticDescriptorリソースは、更新された情報を前記センサから取得するための、別の装置の第２semanticDescriptorリソースとリンクされ、第１semanticDescriptorリソースは統一資源識別子（Uniform Resource Identifier:URI）を介して第２semanticDescriptorリソースとリンクされることを特徴とする、請求項１５に記載のコンピュータ可読記憶媒体。
18. 前記動作は、前記情報の測定単位を示すセマンティックメタデータを取得することをさらに含むことを特徴とする、請求項１５に記載のコンピュータ可読記憶媒体。
19. 前記動作は、セマンティック推論を用いて前記情報の測定単位を取得することをさらに含むことを特徴とする、請求項１５に記載のコンピュータ可読記憶媒体。
20. 前記第１semanticDescriptorリソースは、前記センサからの測定値である更新された情報を前記センサから取得するための、別の装置の第２semanticDescriptorリソースとリンクされることを特徴とする、請求項１５に記載のコンピュータ可読記憶媒体。

Images