JP6636631B2 - セマンティックｉｏｔのためのｒｅｓｔｆｕｌ動作 - Google Patents

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／２４９，１１２号（２０１５年１０月３０日出願、名称「Ｒｅｓｔｆｕｌ Ｏｐｅｒａｔｉｏｎｓ Ｆｏｒ Ｓｅｍａｎｔｉｃ ＩＯＴ」）および米国仮特許出願第６２／２５２，９４０号（２０１５年１１月９日出願、名称「Ｒｅｓｔｆｕｌ Ｏｐｅｒａｔｉｏｎｓ Ｆｏｒ Ｓｅｍａｎｔｉｃ ＩＯＴ」）の利益を主張する。上記出願の各々の内容は、それらの全体が参照により本明細書に引用される。

（背景）
（セマンティックウェブ）
セマンティックウェブは、ワールドワイドウェブコンソーシアム（Ｗ３Ｃ）による規格を通したウェブの拡張である。この規格は、ウェブ上での共通データフォーマットおよび交換プロトコル、最も基本には、リソース記述フレームワーク（ＲＤＦ）を促進する。セマンティックウェブは、データのために特に設計された言語：リソース記述フレームワーク（ＲＤＦ）、ウェブオントロジー言語（ＯＷＬ）、および拡張マークアップ言語（ＸＭＬ）でパブリッシュすることを伴う。これらの技術は、リンクされたデータのウェブを介してウェブドキュメントのコンテンツを補足または置換する記述を提供するために組み合わせられる。したがって、コンテンツは、ウェブアクセス可能データベース内に記憶される記述データとして、またはドキュメント内のマークアップ、特に、ＸＭＬが点在する拡張ＨＴＭＬ（ＸＨＴＭＬ）、もしくはより多くの場合、単純にＸＭＬにおけるドキュメント内のマークアップとして現れ得、レイアウトまたはレンダリングキューは、別個に記憶される。

（セマンティックウェブスタック）
セマンティックウェブスタック（Ｄｅｓｃｒｉｐｔｉｏｎ ｏｆ Ｗ３Ｃ Ｔｅｃｈｎｏｌｏｇｙ Ｓｔａｃｋ Ｉｌｌｕｓｔｒａｔｉｏｎ，ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／Ｃｏｎｓｏｒｔｉｕｍ／ｔｅｃｈｓｔａｃｋ−ｄｅｓｃ．ｈｔｍｌ参照）は、図１に示されるように、Ｗ３Ｃによって規定されたセマンティックウェブのアーキテクチャを例証する。コンポーネントの機能および関係は、以下のように要約されることができる。

ＸＭＬは、ドキュメント内のコンテンツ構造のための基本的シンタックスを提供するが、セマンティクスをドキュメント内に含まれるコンテンツの意味に関連付けしない。ＸＭＬは、現在、タートル等の代替シンタックスが存在するので、大抵の場合、セマンティックウェブ技術の必要コンポーネントではない。タートルは、事実上標準的であるが、正式な標準化プロセスを経ていない。

ＸＭＬスキーマは、ＸＭＬドキュメント内に含まれる要素の構造およびコンテンツを提供および制限するための言語である。

Ｗ３Ｃ技術スタック例証のＲＤＦ記述は、データモデルを表すための言語であり、データモデルは、主語−述語−目的語、例えば、Ｓ−Ｐ−ＯトリプルまたはＲＤＦトリプルの形態でオブジェクト（「ウェブリソース」）およびその関係を参照する。ＲＤＦベースのモデルは、種々のシンタックス、例えば、ＲＤＦ／ＸＭＬ、Ｎ３、タートル、およびＲＤＦで表されることができる。ＲＤＦは、セマンティックウェブの基本規格である。

ＲＤＦスキーマは、ＲＤＦを拡張し、ＲＤＦスキーマは、プロパティおよびクラスの一般化された階層のためのセマンティクスを用いてそのようなＲＤＦベースのリソースのプロパティおよびクラスを記述するための語彙である。

ＯＷＬは、プロパティおよびクラス：とりわけ、クラス間の関係（例えば、離接）、基数（例えば、「正確に１つ」）、相等性、より豊富なタイプのプロパティ、プロパティの特性（例えば、対称）、およびリストアップされたクラスを記述するために、より多くの語彙を追加する。

ＳＰＡＲＱＬは、ウェブ上またはＲＤＦストア（例えば、セマンティックグラフストア）においてＲＤＦグラフコンテンツ（例えば、ＲＤＦトリプル）をクエリおよび操作するための、セマンティックウェブデータソースのためのプロトコルおよびクエリ言語である。

ＳＰＡＲＱＬ１．１クエリは、ＲＤＦグラフのためのクエリ言語であり、データがＲＤＦとしてネイティブに記憶されているか、またはミドルウェアを介してＲＤＦとして見なされるかにかかわらず、多様なデータソースにわたるクエリを表すために使用されることができる。ＳＰＡＲＱＬは、その連言および選言とともに、必要とされるグラフパターン、および随意のグラフパターンをクエリするための能力を含む。ＳＰＡＲＱＬは、集約、サブクエリ、否定、表現による値の作成、拡張値試験、およびソースＲＤＦグラフによるクエリの制約もサポートする。ＳＰＡＲＱＬクエリの結果は、結果組またはＲＤＦグラフであり得る。

ＳＰＡＲＱＬ１．１更新は、ＲＤＦグラフのための更新言語である。それは、ＲＤＦのためにＳＰＡＲＱＬクエリ言語由来のシンタックスを使用する。更新動作は、セマンティックグラフストアにおけるグラフの集合に対して行われる。動作は、セマンティックグラフストア内のＲＤＦグラフを更新、作成、および除去するために提供される。

ＲＩＦは、Ｗ３Ｃルールインターチェンジフォーマットである。それは、コンピュータが実行し得る、ウェブルールを表すためのＸＭＬ言語である。ＲＩＦは、ダイアレクトと呼ばれる複数のバージョンを提供する。それは、ＲＩＦ基本論理ダイアレクト（ＲＩＦ−ＢＬＤ）およびＲＩＦ生成ルールダイアレクト（ＲＩＦ ＰＲＤ）を含む。

（セマンティック検索およびセマンティッククエリ）
関係データベースは、暗示的様式のみにおいて、データ間の全ての関係を含む。例えば、顧客と製品との間の関係（２つのコンテンツテーブル内に記憶され、追加のリンクテーブルと接続される）は、開発者によって書き込まれるクエリ文（例えば、ＳＱＬが、関係データベースの場合に使用される）においてのみ発生する。クエリを書き込むことは、データベーススキーマの正確な知識を要求する。多くの関係データベースは、データがツリー状構造の中に編成される階層データベースにおけるようにモデル化される。データは、リンクを通して互いに接続される記録として記憶される。階層データベースモデルにおける記録は、関係データベースモデルにおける行（またはタプル）に対応し、エンティティタイプは、テーブル（または関係−親および子）に対応する。記録の検索またはクエリは、ＳＱＬまたは非ＳＱＬ検索エンジンによって実施され得る。

図２に示されるように、従来の階層データベースモデルは、各子記録が、１つのみの親を有する一方、各親記録が、１つ以上の子記録を有し得ることを要求する。データを階層データベースから読み出すために、ツリー全体がルートノードから開始してトラバースされる必要がある。この構造は、単純であるが、関係が１対多の関係に制限されるので、非柔軟である。

リンクされたデータは、明示的様式でデータ間の全ての関係を含む。関係データベースにおいて説明される前述の例では、クエリコードは、書き込まれる必要がない。各顧客のための正しい製品が、自動的にフェッチされることができる。この単純例は、ささいなものであるが、リンクされたデータの真の力は、情報のネットワーク（都市、州、および国のようなそれらのジオスペース情報を伴う顧客、サブおよびスーパーカテゴリ内のそれらのカテゴリを伴う製品）が作成されるとき、有用になる。ここで、システムは、特定の場所の製品カテゴリとの接続を探すより複雑なクエリおよび分析に自動的に回答することができる。このクエリのための開発努力は、省略される。セマンティッククエリの実行は、情報のネットワークをウォーキングし、一致を見出すことによって実施される（データグラフトラバーサルとも呼ばれる）。

セマンティック検索は、検索者の意図と、（ウェブ上か、閉鎖されたシステム内かにかかわらず）用語が検索可能データ空間内に現れるにつれての用語の文脈的意味とを理解し、より関連のある結果を生成することによって、検索正確度を改良しようとする。セマンティック検索システムは、検索のコンテキスト、場所、意図、ならびに単語、同義語、一般化されたおよび特殊クエリ、概念一致、および自然言語クエリの変形例を含む種々の点を考慮し、関連検索結果を提供する。ＧｏｏｇｌｅおよびＢｉｎｇのような主要なウェブ検索エンジンは、セマンティック検索のいくつかの要素を組み込む。セマンティック検索は、セマンティクス、すなわち、言語における意味の科学を使用して、高度に関連した検索結果を生成する。大抵の場合、目標は、ユーザに大まかに関連するキーワード結果のリストを分類せるのではなく、ユーザによってクエリされる情報をもたらすことである。例えば、セマンティクスは、階層関係データベース内の記録検索またはクエリを強化するために使用され得る。

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

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

技術的観点から、セマンティッククエリは、データベースクエリとよく似た精密な関係タイプ動作である。それらは、構造化されたデータに取り組み、したがって、演算子（例えば、＞、＜、および＝）、名前空間、パターン照合、サブクラス化、遷移関係、セマンティックルール、およびコンテキストフルテキスト検索のような包括的特徴を利用する可能性を有する。Ｗ３Ｃのセマンティックウェブ技術スタックは、セマンティッククエリをＳＱＬに類似するシンタックスで公式化するためのＳＰＡＲＱＬを提供する。セマンティッククエリは、トリプルストア、グラフデータベース、セマンティックウィキ、自然言語、および人工知能システムにおいて使用される。

セマンティッククエリの別の側面は、関係のタイプが知能をシステムの中に組み込むために使用されることができることである。顧客と製品との間の関係は、近隣とその都市との間の関係と基本的に異なる性質を有する。後者は、セマンティッククエリエンジンが、Ｍａｎｈａｔｔａｎに住んでいる顧客がＮｅｗ Ｙｏｒｋ Ｃｉｔｙにも住んでいることを推測することを可能にする一方、他の関係は、より複雑なパターンおよび「コンテキスト分析」を有し得る。このプロセスは、推測または推論と呼ばれ、所与の事実に基づいて新しい情報を導出するためのソフトウェアの能力である。

（セマンティックモノのインターネット（ＩｏＴ））
世界中に展開されるネットワーク接続デバイスおよびセンサの数の高速増加は、情報通信ネットワーク、および種々のドメインにおけるサービスまたはアプリケーションを変化させている。次の１０年以内に、数十億のデバイスが、スマートグリッド、スマートホーム、ヘルスケア、自動車、交通、物流、および環境監視等の種々のエリアにおける多くのアプリケーションおよびサービスのための大量の実世界データを生成するであろうことが予測される。モノのインターネット（ＩｏＴ）は、実世界データおよびサービスを現在の情報ネットワーキングの中に統合することを可能にする。

種々の物理的、サイバー、およびソーシャルリソースからのデータの統合は、状況およびコンテキストアウェアネスを意思決定機構の中に組み込むことができ、かつよりスマートなアプリケーションおよび強化されたサービスを作成することができるアプリケーションおよびサービスを開発することを可能にする。大量の分散型および異種ＩｏＴデータに対処することにおいて、相互運用性、自動化、およびデータ分析に関連する問題は、一般的記述およびデータ表現フレームワーク、ならびにマシン読み取り可能およびマシン解釈可能データ記述と共に使用される。セマンティック技術をＩｏＴに適用することは、種々のリソース、データプロバイダ、および消費者間の相互運用性を促進し、効果的データアクセスおよび統合、リソース発見、セマンティック推論、および知識抽出を促進する。セマンティック注釈は、ＩｏＴ内の種々のリソースに適用されることができる。オントロジー、セマンティック注釈、リンクされたデータ、およびセマンティックウェブサービス等のセマンティックウェブにおいて開発された一連の技術は、ＩｏＴを実現するための主要ソリューションとして使用されることができる。

しかしながら、セマンティック技術を実世界データに効果的に適用するために考慮されるべき特殊な設計考慮を要求するＩｏＴの従来の構成に基づくいくつかの課題が存在する。課題は、動的性および複雑性、スケーラビリティ、分散型データストレージおよびクエリ、データの品質／信用／信頼性、セキュリティおよびプライバシ、またはデータの解釈および知覚を含み得る。動的性および複雑性に関して、実世界データは、より過渡的であり、主に、時間および場所依存である。下層環境の広汎性および変動的性は、記述の連続更新および監視を要求する。スケーラビリティに関して、ＩｏＴデータは、実世界における異なる現象を参照する。したがって、データを伴うセマンティック記述および注釈は、異なるおよび動的実世界状況にスケーラブルであるように、実世界リソースおよびエンティティのドメイン知識に関連付けられる必要がある。大量のデータおよびセマンティック記述を伴う分散型データストレージ／クエリに関して、ストレージおよびデータハンドリング機構の効率は、特に、関わるスケールおよび動的性を考慮すると、有意な課題となる。データの品質、信用、および信頼性に関して、ＩｏＴデータは、ＩｏＴデータ内の不正確度および可変品質に対する懸念を提供する異なる感覚デバイスによって提供される。セキュリティおよびプライバシに関して、ＩｏＴデータは、多くの場合、個人的である。データのセキュリティおよびプライバシを提供および保証する機構は、ＩｏＴ内の有意な問題であり得る。最後に、データの解釈および知覚に関して、マシン読み取り可能かつ解釈可能フォーマットで提供されるセマンティック記述および背景知識は、マシンおよび人感センサによって作成された膨大な量の未加工観察を人間または自動化された意思決定プロセスに有意義なより高いレベルの抽象的概念に変換することをサポートする。しかしながら、ＩｏＴにおけるマシン知覚は、異なるソースからのデータの統合および融合、オブジェクトおよびイベントの記述、データ集約および融合ルール、閾値の定義、大規模なデータストリームのリアルタイム処理、ならびに品質および動的性問題等の追加の課題を従来のＡＩ方法がこれまで解決を試みていた問題に追加する。

（ｏｎｅＭ２Ｍアーキテクチャ）
開発中のｏｎｅＭ２Ｍ規格（参照することによってその全体として組み込まれる、ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ２．３．０参照）は、「共通サービスエンティティ（ＣＳＥ）」と呼ばれるサービス層を定義する。サービス層の目的は、異なる「バーティカル」Ｍ２Ｍシステムおよびアプリケーションによって利用され得る「ホリゾンタル」サービスを提供することである。

ＣＳＥは、図３に示されるように、４つの参照点をサポートする。Ｍｃａ参照点は、アプリケーションエンティティ（ＡＥ）とインターフェースをとる。Ｍｃｃ参照点は、同一サービスプロバイダドメイン内の別のＣＳＥとインターフェースをとり、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとる。Ｍｃｎ参照点は、下層ネットワークサービスエンティティ（ＮＳＥ）とインターフェースをとる。ＮＳＥは、デバイス管理、場所サービス、およびデバイストリガ等の下層ネットワークサービスをＣＳＥに提供する。

ＣＳＥは、「発見」、「データ管理およびリポジトリ」等の「共通サービス機能（ＣＳＦ）」と呼ばれる、複数の論理機能を含む。図４は、ｏｎｅＭ２Ｍにおける開発中のＣＳＦを図示する。

ｏｎｅＭ２Ｍアーキテクチャは、図３に示されるように、以下のタイプのノード、すなわち、アプリケーションサービスノード（ＡＳＮ）、アプリケーション専用ノード（ＡＤＮ）、中間ノード（ＭＮ）、インフラストラクチャノード（ＩＮ）、および非ｏｎｅＭ２Ｍノード（ＮｏＤＮ）を可能にする。ＡＳＮは、１つのＣＳＥを含み、少なくとも１つのアプリケーションエンティティ（ＡＥ）を含むノードである。例えば、物理的マッピングに関して、ＡＳＮは、Ｍ２Ｍデバイス内に常駐し得る。ＡＤＮは、少なくとも１つのＡＥを含むが、ＣＳＥを含まないノードである。ゼロ以上のＡＤＮが、ｏｎｅＭ２Ｍシステムのフィールドドメイン内に存在し得る。例えば、物理的マッピングに関して、ＡＤＮは、制約付きＭ２Ｍデバイス内に常駐し得る。ＭＮは、１つのＣＳＥを含み、ゼロ以上のＡＥを含むノードである。ゼロ以上のＭＮが、ｏｎｅＭ２Ｍシステムのフィールドドメイン内に存在し得る。例えば、物理的マッピングに関して、ＭＮは、Ｍ２Ｍゲートウェイ内に常駐し得る。ＩＮは、１つのＣＳＥを含み、ゼロ以上のＡＥを含むノードである。ＩＮは、ｏｎｅＭ２Ｍサービスプロバイダごとにインフラストラクチャドメイン内に存在する。ＩＮ内のＣＳＥは、他のノードタイプに適用可能ではないＣＳＥ機能を含み得る。例えば、物理的マッピングに関して、ＩＮは、Ｍ２Ｍサービスインフラストラクチャ内に常駐し得る。非ｏｎｅＭ２Ｍノードは、ｏｎｅＭ２Ｍエンティティ（ＡＥまたはＣＳＥのいずれでもない）を含まないノードである。そのようなノードは、管理を含む、インターワーキング目的のために、ｏｎｅＭ２Ｍシステムにアタッチされたデバイスを表す。

ｏｎｅＭ２Ｍシステム内でサポートされる種々のエンティティを相互接続する可能な構成は、図５に図示される。

（ｏｎｅＭ２Ｍアーキテクチャにおけるセマンティック記述）
＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースは、リソースおよび潜在的にサブリソースに関するセマンティック記述を記憶するために使用される。そのような記述は、オントロジーに従って提供され得る。セマンティック情報は、ｏｎｅＭ２Ｍシステムのセマンティック機能性によって使用され、アプリケーションまたはＣＳＥにも利用可能である。

従来、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースは、表１に規定される属性を含むものとする。図６は、リソースツリー内の＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースの構造を図示する。

（ｏｎｅＭ２Ｍにおけるセマンティックフィルタリング提案）
一般フィルタリングが、要求動作に規定されたフィルタ基準を有することによってサポートされる（ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ２．３．０第８．１．２節）。セマンティックフィルタリングを提供するために、要求動作フィルタ基準のための追加の値が提案されており、定義は、以下の表２に示される。複数のインスタンスが、使用され得、それは、フィルタ基準を評価するための一般的ルールに従い、「ＯＲ」セマンティクスが適用され、例えば、セマンティックフィルタのうちの１つ以上のものがセマンティック記述に一致する場合、セマンティックフィルタ基準のための全体的結果が真であることを意味する。

上記の提案は、以下の仮定を使用する：セマンティック記述は、ＲＤＦトリプル（表現、例えば、ＲＤＦ／ＸＭＬ、タートル、ｏｎｅＭ２Ｍ内にまだ完全に規定されていない記述フォーマット）として規定される；セマンティックフィルタ基準は、セマンティック記述に対して実行されるべきＳＰＡＲＱＬ要求のために使用されるであろう。

ある場合、単一検索のための関連セマンティック情報は、異なる＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソース間に分散され得る。図７に提供される例は、このケースを図示する。主語−述語−目的語関係を表すセマンティックグラフが示されており、このグラフの異なる部分（卵形によって表される）は、異なる＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソース内に記憶されている。セマンティックフィルタリングは、完全なセマンティックグラフ（その一部）に適用される必要があり、それは、グラフのいくつかの異なる部分がセマンティック動作の実行のために一緒に置かれる必要があるという問題を生じさせる。

この問題は、概して、クラスインスタンスを識別するＵＲＩが、直接、デリファレンスされ得、したがって、概念（例えば、クラス、関係）情報は、そのＵＲＩに基づいて見出され得るので、セマンティックウェブの領域ではよく分からない。ｏｎｅＭ２Ｍケースでは、アクセスされ得るリソース、およびセマンティクスのみが、リソースコンテンツとして記憶される。この場合、セマンティックインスタンスは、第１のクラスのシチズンではないので、ＵＲＩベースのアプローチは、ｏｎｅＭ２Ｍケースでは適用可能ではない。

従来のＳＰＡＲＱＬ１．１は、サービスキーワードを使用して、連合クエリをサポートし、遠隔ＳＰＡＲＱＬエンドポイントのＵＲＬが、規定され得る。このアプローチに関して、要求側がどのセマンティック記述子が検索のために要求されるセマンティックインスタンスを含むかを先験的に把握しているであろうと想定されており、それは、セマンティック記述子がリソースツリー内に分散されている場合、このアプローチを概して適用不可能にするであろう。

ｏｎｅＭ２Ｍに提示されるように、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースをまたいで記憶されているセマンティック記述に対してセマンティックフィルタリングを可能にするためのソリューションは、ｒｅｓｏｕｒｃｅＤｅｓｃｒｉｐｔｏｒＬｉｎｋ ＯＷＬ注釈プロパティの形態で注釈リンクを導入する。この注釈プロパティは、任意のクラスインスタンスのために規定されることができ、その値は、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースのＵＲＬであり、所与のクラスインスタンスのための追加のＲＤＦトリプルが、見出され得る。以下の例は、図９におけるグラフを作成するために、ｏｎｅＭ２Ｍベースオントロジー（図８）内に定義されたクラスおよび関係を使用する。

このソリューションは、受信側におけるＳＰＡＲＱＬベースのセマンティックフィルタリングエンジンのための以下の機能フローを伴う。第１に、ＳＰＡＲＱＬ要求として公式化されるセマンティックフィルタは、候補リソースのセマンティック記述子リソースのコンテンツに対して実行される。第２に、実行の過程において、１つ以上のｒｅｓｏｕｒｃｅＤｅｓｃｒｉｐｔｏｒＬｉｎｋ注釈を伴うクラスインスタンスに遭遇する場合、実行は、停止される。第３に、ｒｅｓｏｕｒｃｅＤｅｓｃｒｉｐｔｏｒＬｉｎｋが参照する、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースの各々のコンテンツが、ＳＰＡＲＱＬ要求が実行されているコンテンツに追加される（遅延評価、代替：実行前に全てをフェッチするが、不必要情報のフェッチをもたらし得る）。第４に、ＳＰＡＲＱＬ要求の実行が、拡大コンテンツにおいて継続される。

（ｏｎｅＭ２Ｍにおけるアクセス制御ポリシ）
図１０に示されるように、従来の＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースは、ｐｒｉｖｉｌｅｇｅｓおよびｓｅｌｆＰｒｉｖｉｌｅｇｅｓ属性から成り、それらは、規定されたコンテキスト（ａｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｅｘｔｓによって定義される）内のある動作（ａｃｃｅｓｓＣｏｎｔｏｌＯｐｅｒａｔｉｏｎｓによって定義される）を行うための権利を有するエンティティ（ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓによって定義される）を定義するアクセス制御ルールの組を表し、特定のリソースへのアクセス決定を行うことにおいてＣＳＥによって使用される。ｐｒｉｖｉｌｅｇｅでは、各アクセス制御ルールは、どのＡＥ／ＣＳＥがどの動作を可能にされるかを定義する。したがって、アクセス制御ルールの組に対して、動作が組内の１つ以上のアクセス制御ルールによって許可される場合、その動作が許可される。＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースタイプではないリソースに対して、そのようなリソースのための共通属性ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤは、そのリソースを＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースにリンクする識別子のリストを含む。そのようなリソースのためのＣＳＥアクセス決定は、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソース内に定義されたｐｒｉｖｉｌｅｇｅｓ属性によって表されるアクセス制御ルールの組の評価に従うものとする。ｓｅｌｆＰｒｉｖｉｌｅｇｅｓ属性は、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソース自体のためのアクセス制御ルールの組を表すものとする。＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースのためのＣＳＥアクセス決定は、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソース自体内に定義されたｓｅｌｆＰｒｉｖｉｌｅｇｅｓ属性によって表されるアクセス制御ルールの組の評価に従うものとする。

＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースは、従来、表３に規定された属性を含む。

ｐｒｉｖｉｌｅｇｅｓおよびｓｅｌｆＰｒｉｖｉｌｅｇｅｓ属性に表される従来のアクセス制御ルールの組は、以下に説明される３−タプルから成る。ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓは、ａｃｃｅｓｓ−ｃｏｎｔｒｏｌ−ｒｕｌｅ−ｔｕｐｌｅ内のパラメータである。それは、このアクセス制御ルールを使用することを可能にされる発信側の組を表す。発信側の組は、パラメータのリストとして記述され、パラメータのタイプは、リスト内で変動し得る。表４は、ａｃｃｅｓｓＣｏｎｔｒｏｌＯｒｉｇｉｎａｔｏｒｓ内のパラメータのサポートされるタイプを記述する。

ｏｒｉｇｉｎａｔｏｒＩＤが、＜ＡＥ＞または＜ｒｅｍｏｔｅＣＳＥ＞をメンバとして含む、＜ｇｒｏｕｐ＞リソースのｒｅｓｏｕｒｃｅ−ＩＤであるとき、リソースのホスト側ＣＳＥは、要求の発信側が＜ｇｒｏｕｐ＞リソースのｍｅｍｂｅｒＩＤ属性内のメンバのうちの１つに一致するかどうかを決定する（例えば、＜ｇｒｏｕｐ＞リソースを読み出すことによって）。＜ｇｒｏｕｐ＞リソースが、読み出されることができない、または存在しない場合、要求は、否認されるものとする。

ａｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｅｘｔｓは、リストを含む、ａｃｃｅｓｓ−ｃｏｎｔｒｏｌ−ｒｕｌｅ−ｔｕｐｌｅ内のパラメータであり、リストの各要素は、存在するとき、本アクセス制御ルールを使用することが許可されるコンテキストを表す。各要求コンテキストは、パラメータの組によって記述され、パラメータのタイプは、組内で変動し得る。表５は、ａｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｅｘｔｓ内でサポートされるタイプのパラメータを記述する。以下の従来の発信側ａｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｅｘｔｓは、ＣＳＥによるアクセス制御ポリシチェックのために考慮されるものとする。

ａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓは、このアクセス制御ルールを使用して認可される動作の組を表すａｃｃｅｓｓ−ｃｏｎｔｒｏｌ−ｒｕｌｅ−ｔｕｐｌｅにおけるパラメータである。表６は、ａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓによって認可される動作のサポートされる組を記述する。以下のａｃｃｅｓｓＣｏｎｔｒｏｌＯｐｅｒａｔｉｏｎｓは、ＣＳＥによるアクセス制御ポリシチェックのために考慮されるものとする。

（Ｍ２Ｍセマンティックサポートの提案される機能アーキテクチャ）
図１１は、Ｍ２Ｍセマンティックサポートのための提案される機能アーキテクチャを示し、主要コンポーネントは、リソースリポジトリ、オントロジープロセッサ、オントロジーリポジトリ、セマンティックリポジトリ、ルールリポジトリ、推論器、またはセマンティッククエリプロセッサを含み得る。リソースリポジトリは、物理的Ｍ２Ｍデバイスから収集される、全てのリソースを記憶する。Ｍ２Ｍセマンティックサポートは、それらのユニバーサル理解／解釈のためのオリジナルリソースに対するセマンティクスと、それらに対する任意の高度な処理、例えば、セマンティッククエリ、データ分析等とを可能にするために意図される。オントロジープロセッサは、Ｍ２Ｍドメインの外部および内部でパブリッシュ／生成されたオントロジーの処理、分類、記憶、および発見機能の提供を担当する。オントロジーリポジトリは、オントロジーを記憶する。それらのオントロジーは、リソースのためのセマンティクスを可能にするために使用されることができる。セマンティックリポジトリは、注釈が付けられたセマンティック情報を、ＲＤＦを利用するオプションを有し得るある表現で記憶する。セマンティック注釈は、リソースのセマンティクスをバイナリストリーム等の特定のフォーマットで表すプロセスである。ルールリポジトリは、多くの場合、リソースリポジトリ内のリソースに関連付けられた既存のセマンティクスを超える、新しい知識を表すために使用されるルールを記憶する。ルールは、典型的には、条件付き文：ｉｆ−ｔｈｅｎ節である。推論器は、ルールリポジトリからの入力およびセマンティックリポジトリ内の既存のリソースセマンティック情報をとり、ルール内の条件が満たされる場合、新しいリソースセマンティック情報を生成する。新しいリソースセマンティック情報は、セマンティックリポジトリに追加される。セマンティッククエリプロセッサは、クライアントからのクエリをハンドリングし、セマンティックリポジトリ内に記憶されるリソースセマンティック情報を検索し、結果をクライアントに返す。

（要約）
本明細書に開示されるのは、集中管理セマンティックグラフストアへのＲＥＳＴｆｕｌ動作のためのアクセス制御を提供し、リソースツリーデータベース内に分散されたセマンティックＲＤＦトリプルに関する動作を提供する方法である。

ある例では、セマンティック記述子が、集中管理セマンティックグラフストア内に存在し得る。本明細書に提供されるのは、とりわけ、集中管理セマンティックグラフストア内にセマンティック記述子を伴うアーキテクチャ、集中管理セマンティックグラフストア内のセマンティックトリプルまたはグラフを用いたｒｅｓｔｆｕｌ動作、アクセス制御ポリシによって規定されたアクセス制御ルールを用いた集中管理セマンティックグラフストアのためのアクセス制御、ならびにセマンティッククエリを用いたリソース発見に関する詳細である。

別の例では、セマンティック記述子が、階層リソースツリー内に存在し得る。本明細書に提供されるのは、とりわけ、階層リソースツリー内に分散されたセマンティック記述子を伴うアーキテクチャ、階層リソースツリー内に分散されたセマンティック記述子を用いたセマンティッククエリ、および一時的セマンティックグラフストアに関する詳細である。

別の例では、セマンティック記述子が、集中管理セマンティックグラフストアおよびリソースツリー内に存在し得る。本明細書に提供されるのは、集中管理セマンティックグラフストアおよびリソースツリー内にセマンティック記述子を伴うアーキテクチャ、ならびに集中管理セマンティックグラフストアおよびリソースツリー内のセマンティック記述子を用いたセマンティッククエリに関する詳細である。

セマンティック記述子関係情報を維持するための階層リソースツリー機構内に分散されたセマンティック記述子を使用する、アーキテクチャが、開示される。機構は、セマンティック記述子の特定の組を一緒に使用することによって、セマンティッククエリが、特定のグラフのコンテキスト内で行われることを可能にする。セマンティック動作目的のためのグループの形成を使用する機構は、異なるサービスエンティティ上に位置するメンバを含むグループのメンバにセマンティック要求をファンアウトするために、グループリソースの使用も可能にする。

有効にされる追加の機能性は、集中管理様式においてグループ全体に関連付けられた合成グラフを維持することによる、クエリ最適化を含む。ローカルトリプルストアストレージ、キャッシュ等は、グループ方法を使用するとき、クエリ処理をさらに最適化し得る。機能性は、グループをグラフ命名ルールと共に使用することによって、セマンティック動作を標的化し、可能な限り具体的または広範にすることにおけるより優れた粒度も含む。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の一連の概念を導入するように提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図せず、請求される主題の範囲を限定するために使用されることも意図していない。請求される主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本願明細書は、例えば、以下の項目も提供する。
（項目１）
セマンティックリソース発見のための装置であって、前記装置は、
プロセッサと、
前記プロセッサと結合されているメモリと
を備え、
前記メモリは、実行可能命令を含み、前記命令は、前記プロセッサによって実行されると、
セマンティックリソース発見を含むメッセージを受信することと、
読み出されるべきセマンティック記述子の組を決定することであって、前記セマンティック記述子の組は、前記メッセージの標的に関連している、ことと、
前記セマンティック記述子の組に基づいて、セマンティック記述子のリストのそれぞれの記述子属性のコンテンツを読み出すことと
を含む動作を前記プロセッサにもたらさせる、装置。
（項目２）
前記動作は、
前記それぞれの記述子属性の前記コンテンツに基づいて、セマンティックグラフを生成することと、
セマンティックリソース発見を前記セマンティックグラフに対して実施するための命令を提供することと
をさらに含む、項目１に記載の装置。
（項目３）
前記それぞれの記述子属性のうちの少なくとも１つは、異なる装置上に記憶されている、項目１〜２のいずれか１項に記載の装置。
（項目４）
前記セマンティック記述子の組は、グループリソースを介して提供される、項目１〜３のいずれか１項に記載の装置。
（項目５）
前記読み出されるべきセマンティック記述子の組は、前記セマンティック記述子に対するユニフォームリソース識別子のリストを含む、項目１〜４のいずれか１項に記載の装置。
（項目６）
前記セマンティック記述子は、リソースである、項目１〜５のいずれか１項に記載の装置。
（項目７）
前記動作は、発信側装置が前記メッセージの前記標的のためのアクセス権を有することを検証することをさらに含み、前記メッセージの前記標的は、第１のセマンティック記述子である、項目１〜６のいずれか１項に記載の装置。
（項目８）
前記動作は、前記セマンティック記述子の組のうちの各セマンティック記述子に対して、発信側装置がアクセス権を有することを検証することをさらに含む、項目１〜７のいずれか１項に記載の装置。
（項目９）
前記動作は、前記メッセージの前記標的の属性の前記コンテンツをドキュメントとして保存することをさらに含み、前記メッセージの前記標的は、第１のセマンティック記述子である、項目１〜８のいずれか１項に記載の装置。
（項目１０）
前記動作は、前記生成されたセマンティックグラフを一時的グラフストア内に保存することをさらに含む、項目１〜９のいずれか１項に記載の装置。
（項目１１）
前記動作は、前記メッセージ内で受信されたセマンティックトリプルおよびリソースアクセス制御情報に関連付けられたアクセス制御トリプルを生成することをさらに含み、前記アクセス制御トリプルは、その後、前記セマンティックグラフ内に記憶される、項目１〜１０のいずれか１項に記載の装置。
（項目１２）
セマンティックリソース発見のための方法であって、前記方法は、
セマンティックリソース発見を含むメッセージを受信することと、
読み出されるべきセマンティック記述子の組を決定することであって、前記セマンティック記述子の組は、前記メッセージの標的に関連している、ことと、
前記セマンティック記述子の組に基づいて、前記セマンティック記述子のリストのそれぞれの記述子属性のコンテンツを読み出すことと
を含む、方法。
（項目１３）
前記動作は、
前記それぞれの記述子属性の前記コンテンツに基づいて、セマンティックグラフを生成することと、
セマンティックリソース発見を前記セマンティックグラフに実施するための命令を提供することと
をさらに含む、項目１２に記載の方法。
（項目１４）
前記セマンティック記述子の組は、グループリソースを介して提供される、項目１２〜１３のいずれか１項に記載の方法。
（項目１５）
前記読み出されるべきセマンティック記述子の組は、前記セマンティック記述子に対するユニフォームリソース識別子のリストを含む、項目１２〜１４のいずれか１項に記載の方法。
（項目１６）
前記セマンティック記述子は、リソースである、項目１２〜１５のいずれか１項に記載の方法。
（項目１７）
発信側装置が前記メッセージの前記標的のためのアクセス権を有することを検証することをさらに含み、前記メッセージの前記標的は、第１のセマンティック記述子である、項目１２〜１６のいずれか１項に記載の方法。
（項目１８）
前記生成されたセマンティックグラフを一時的グラフストア内に保存することをさらに含む、項目１２〜１７のいずれか１項に記載の方法。
（項目１９）
前記メッセージ内で受信されたセマンティックトリプルおよびリソースアクセス制御情報に関連付けられたアクセス制御トリプルを生成することをさらに含み、前記アクセス制御トリプルは、その後、前記セマンティックグラフ内に記憶される、項目１２〜１８のいずれか１項に記載の方法。
（項目２０）
コンピュータ読み取り可能な媒体を備えているコンピュータプログラム製品であって、前記コンピュータ読み取り可能な媒体は、プログラム命令を含むコンピュータプログラムを有し、前記コンピュータプログラムは、データ処理ユニットの中にロード可能であり、前記コンピュータプログラムは、前記コンピュータプログラムが前記データ処理ユニットによって起動されると、項目１２から１９のいずれかに記載の方法ステップを前記データ処理ユニットに実行させるように適合されている、コンピュータプログラム製品。

図１は、セマンティックウェブの例示的アーキテクチャを図示する。 図２は、例示的階層データベースを図示する。 図３は、例示的ｏｎｅＭ２Ｍアーキテクチャを図示する。 図４は、例示的ｏｎｅＭ２Ｍ共通サービス機能を図示する。 図５は、ｏｎｅＭ２Ｍアーキテクチャによってサポートされる例示的構成を図示する。 図６は、リソースツリー内の＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースの例示的構造を図示する。 図７は、異なるリソース内に記憶されるセマンティック情報をまたぐセマンティックフィルタの例示的範囲を図示する。 図８は、例示的ｏｎｅＭ２Ｍベースオントロジーを図示する。 図９は、例示的ｒｅｓｏｕｒｃｅＤｅｓｃｒｉｐｔｏｒＬｉｎｋを図示する。 図１０は、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースの例示的構造を図示する。 図１１は、Ｍ２Ｍセマンティックサポートの例示的機能アーキテクチャを図示する。 図１２は、集中管理セマンティックグラフストア内の例示的セマンティック記述子を図示する。 図１３は、階層リソースツリー内に分散された例示的セマンティック記述子を図示する。 図１４Ａは、集中管理セマンティックグラフストア内のセマンティック記述子のための例示的アーキテクチャを図示する。 図１４Ｂは、複数のセマンティックグラフストア内のセマンティック記述子のための例示的アーキテクチャを図示する。 図１５は、２つのセマンティックトリプル間の例示的リンクを図示する。 図１６は、集中管理セマンティックグラフストアのための例示的一般的動作フローを図示する。 図１７は、トランジットＳＥを伴う集中管理セマンティックグラフストアのための例示的一般的動作フローを図示する。 図１８は、ＣＲＥＡＴＥセマンティックトリプルのための例示的動作フローを図示する。 図１９は、ＲＥＴＲＩＥＶＥセマンティックトリプル−セマンティッククエリのための例示的動作フローを図示する。 図２０は、ＵＰＤＡＴＥセマンティックトリプルのための例示的動作フローを図示する。 図２１は、ＤＥＬＥＴＥセマンティックトリプルのための例示的動作フローを図示する。 図２２は、セマンティックグラフストア内のアクセス制御のための＜ＡｃｃｅｓｓＣｏｎｔｒｏｌＴｒｉｐｌｅｓ＞を使用した例を図示する。 図２３は、例示的ｅヘルスオントロジー基準モデルを図示する。 図２４は、例示的アクセス制御オントロジーモデルを図示する。 図２５は、セマンティックグラフストア内の例示的ｅヘルストリプルを図示する。 図２６は、アクセス制御を用いた例示的ｅヘルスセマンティッククエリを図示する。 図２７は、階層リソースツリー内に分散されたセマンティック記述子の例示的アーキテクチャを図示する。 図２８は、リソースツリー内の分散型セマンティック記述子を用いた例示的セマンティッククエリを図示する。 図２９は、セマンティックグラフストアおよび階層リソースツリー内のセマンティック記述子のための例示的アーキテクチャを図示する。 図３０は、リソースツリー内のセマンティック記述子およびセマンティックグラフストア内のセマンティックトリプルを用いたセマンティッククエリのための例示的方法を図示する。 図３１は、同一記述子間の複数のリソース記述リンクの例示的問題を図示する。 図３２は、例示的ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性を図示する。 図３３は、異なるセマンティック記述子をまたいで分散された例示的グラフを図示する。 図３４は、別個の記述子内に分散されたサブグラフからの例示的合成グラフを図示する。 図３５は、リンクのリストを用いた例示的使用またはｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性を図示する。 図３６は、例示的＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースを図示する。 図３７は、＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞を用いた例示的使用またはｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性を図示する。 図３８は、図３１に表される合成グラフの例示的ＲＤＦ記述を図示する。 図３９は、＜Ｄｅｖｉｃｅ１２＞のためのｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ記述子属性の例示的コンテンツを図示する。 図４０は、リンクの方法リストが使用されるときの例示的ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性を図示する。 図４１は、リンクのグループ方法が使用されるときの例示的ｓｅｍａｎｔｉｃＧｒｏｕｐＬｉｎｋｓ属性を図示する。 図４２は、恣意的グラフベースのスキームにおける＜Ｄｅｖｉｃｅ１２＞のための例示的セマンティック注釈を図示する。 図４３は、恣意的グラフベースのスキームにおける例示的＜ＯｐｅｒａｔｉｏｎＡ＞注釈を図示する。 図４４は、リンクのグループ方法が使用されるときの例示的ｓｅｍａｎｔｉｃＧｒｏｕｐＬｉｎｋｓ属性を図示する。 図４５は、ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓリンクアプローチを使用した例示的セマンティッククエリを図示する。 図４６は、例示的拡張＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースを図示する 図４７は、ｏｎｅＭ２Ｍを使用した開示される方法のための例示的アーキテクチャを図示する。 図４８は、ｏｎｅＭ２Ｍを使用した開示される方法のための例示的リソースツリーを図示する。 図４９Ａは、セマンティックグラフストア内の例示的図を図示する。 図４９Ｂは、セマンティックグラフストアに関連付けられた例示的方法を図示する。 図４９Ｃは、セマンティックグラフストアに関連付けられたアクセス制御のための例示的方法を図示する。 図５０は、本明細書の方法およびシステムに基づいて生成され得る、例示的ディスプレイを図示する。 図５１Ａは、開示される主題が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図５１Ｂは、図５１Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る例示的アーキテクチャの系統図である。 図５１Ｃは、図５１Ａに図示される通信システム内で使用され得る例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図５１Ｄは、図５１Ａの通信システムの側面が具現化され得る例示的コンピューティングシステムのブロック図である。 図５２は、セマンティックグラフストア内のアクセス制御ポリシの例を図示する。 図５３Ａは、アクセス制御を用いたｅヘルスセマンティッククエリのための例１を図示する。 図５３Ｂは、アクセス制御を用いたｅヘルスセマンティッククエリのための例２を図示する。 図５３Ｃは、アクセス制御を用いたｅヘルスセマンティッククエリのための例３を図示する。 図５４は、セマンティッククエリを介してリソース発見を実施するための例示的方法を図示する。

（例示的実施形態の詳細な説明）
「セマンティックモノのインターネット」に関して本明細書に説明されるように、セマンティックウェブと比較して、セマンティックＩｏＴに関する多くの課題が存在する。第１の課題は、特に、図１２に関連付けられたユースケースＩに図示されるシナリオのようなセキュリティおよびプライバシであり、集中管理セマンティックグラフストアへのアクセスを制御する方法、およびセマンティックグラフストアのためのアクセス制御ポリシを効率的に管理するための方法が、対処されるべきである。別の課題は、図１３に関連付けられたユースケースＩＩに図示されるシナリオのように、ＲＤＦトリプルであるかどうかにかかわらず、データベース内に分散された大量のセマンティック記述子であり、セマンティックＲＤＦトリプルを階層リソースツリーから抽出し、ＲＤＦトリプルに対して動作を実施する方法が、対処されるべきである。ユースケースＩＩにおける分散型セマンティック記述子に関して、別のクエリ関連問題は、クエリの範囲であり、クエリの範囲は、検索されるグラフのスパン、または記述子から生じる対応するＲＤＦ記述のスパンとして見なされ得る。この検索は、クエリ動作標的として使用されるリソースに関連付けられるが、デフォルトスパンは、容易に非最適化検索につながり得る。

セマンティックＩｏＴサービスまたはアプリケーションのためのセマンティック記述子に適用されるＲＥＳＴｆｕｌ動作のための複数のアプローチが、本明細書において開示される。集中管理セマンティックグラフストア内のセマンティック記述子のための機構、階層リソースツリー内に分散されたセマンティック記述子のための機構、および集中管理グラフストアおよび階層リソースツリーの両方に位置するセマンティック記述子のためのハイブリッド機構の詳細が、本明細書に提供され。サービスエンティティ内に分散されるセマンティック記述子のための代替も、議論される。本明細書において、用語「グラフ」の使用は、「セマンティックグラフ」等と同義的であることを理解されたい。

ユースケースＩは、図１２の図に議論される。図１２に示されるように、ＲＤＦトリプル（例えば、セマンティック記述子）の形態におけるセマンティック記述が、集中管理ＲＤＦトリプルデータベース、例えば、セマンティックグラフストアに置かれる。例えば、医師−Ｄおよび医師−Ｄの患者Ａ、Ｂは、それらのセマンティック記述子を集中管理ＲＤＦトリプルストアまたはセマンティックグラフストアの中に記憶し、次いで、医師−Ｄは、患者が許可を医師−Ｄに付与する場合、全ての彼の患者のセマンティック記述子に対するセマンティッククエリを実施し得、患者も、それら自身のセマンティック記述子と、医師−Ｄが許可をその患者に付与する場合、医師−Ｄのセマンティック記述子の一部とに対するセマンティッククエリを実施し得る。しかし、患者は、許可が付与されない場合、互いのセマンティック記述子に対するセマンティッククエリを実施することはできない。さらに、医師−Ｄは、彼のセマンティック記述子と、おそらく、許可が彼の患者によって付与される場合、彼の患者のセマンティック記述子の一部を更新または削除し得、同様に、患者は、それら自身のセマンティック記述子と、おそらく、許可が医師−Ｄによって付与される場合、医師−Ｄのセマンティック記述子の一部とを更新または削除し得る。

ユースケースＩＩは、図１３の図に議論される。図１３に示されるように、データと、ＲＤＦトリプル（例えば、セマンティック記述子）の形態におけるかどうかにかかわらず、セマンティック記述との両方が、関係データベース、例えば、階層リソースツリーに置かれる。例えば、医師−Ｄおよび医師−Ｄの患者Ａ、Ｂは、それらのデータおよびセマンティック記述子を関係データベースまたは階層リソースツリーの中に記憶する。セマンティック記述子１は、関連ｅヘルスアプリケーションに関連するセマンティック情報を記述し、セマンティック記述子２は、データコンテナのためのものであり、セマンティック記述子３は、特定のデータインスタンスのためのものである。後に、医師−Ｄは、患者が許可を医師−Ｄに付与する場合、リソースツリー内の全ての彼の患者のセマンティック記述子に対してセマンティック記述を用いたセマンティック検索またはセマンティッククエリを実施し得、患者は、リソースツリー内のそれら自身のセマンティック記述子と、医師−Ｄが許可をその患者に付与する場合、医師−Ｄのセマンティック記述子の一部とにセマンティック記述を用いたセマンティック検索またはセマンティッククエリを実施し得る。しかし、患者は、許可が付与されない場合、互いのセマンティック記述子に対するセマンティッククエリを実施することはできない。さらに、医師−Ｄは、彼のセマンティック記述子と、おそらく、許可が彼の患者によって付与される場合、その患者のセマンティック記述子の一部とを更新または削除し得、患者は、それら自身のセマンティック記述子と、おそらく、許可が医師−Ｄによって付与される場合、医師−Ｄのセマンティック記述子の一部とを更新または削除し得る。

いくつかの一般的考慮点が、以下に開示される。セマンティック記述は、ＲＤＦトリプルのようなフォーマットであることも、そうではないこともある。一般的フォーマットにおける、例えば、具体的には、ＲＤＦトリプルのようなＳ−Ｐ−Ｏ関係説明ではないセマンティック記述は、リソースツリー内のメタデータまたはコンテキスト情報等の他のリソースと同じである。本明細書では、関係、例えば、ＲＤＦトリプルＳ−Ｐ−Ｏにおいてセマンティック記述に関して議論され、したがって、用語「セマンティック記述子」または「セマンティックトリプル」は、ＲＤＦトリプルのようなフォーマットにおけるセマンティック記述のために使用される。ＳＰＡＲＱＬは、例証目的のためにのみ、ＲＤＦトリプルのために使用される。ソリューションは、リンクされたデータのための他のタイプのセマンティック表現およびセマンティッククエリ言語に一般的である。データは、リソースツリー内の記録のために本明細書で使用される一般的用語であり、記録は、データサンプルまたはコンテキスト情報（例えば、メタデータ）であり得る。セマンティックトリプルにおける要素またはノード（例えば、トリプルＳ−Ｐ−ＯのＳ、Ｐ、またはＯ）は、セマンティックトリプル命令文において、一意の識別子、例えば、国際リソース識別子（ＩＲＩ）またはユニフォームリソース識別子（ＵＲＩ）によってアドレスされる。ＵＲＩが、使用されるが、ＩＲＩまたは他の識別子（例えば、ＵＲＬ）も、開示される機構内で適用可能である。ＲＤＦトリプルＳ−Ｐ−Ｏにおける要素またはノードは、ＵＲＩ、ブランクノードラベル、またはユニコード文字列リテラルによって表され得る。命令文を簡略化するために、基数または名前空間は、いくつかの例では、セマンティックトリプルのために使用されない。セマンティックトリプルは、ＲＥＳＴｆｕｌ動作議論のために使用されるが、機構は、例えば、ＳＰＡＲＱＬ Ｕｐｄａｔｅ１．１によってサポートされるセマンティックグラフ（例えば、リンクされたトリプルまたはリンクされたデータ）動作にも適用され得る。１つのセクションまたは例の動作が別のセクションまたは例に適用され得ることも本明細書で想定されていることを理解されたい。例えば、集中管理アーキテクチャのための集中管理セマンティックグラフストアのためのＲＥＳＴｆｕｌ動作に関する本明細書に開示される動作メッセージ（例えば、要求および応答）は、階層リソースツリー内に分散されたセマンティック記述子、および、セマンティックグラフストアおよび階層リソースツリー内のセマンティック記述子等、本明細書に開示される他のアーキテクチャのための動作にも適用可能である。

図１４Ａに示されるように（以下の図１４Ａおよび１４Ｂ議論の追加のコンテキストに関するユースケースＩ、ＩＩおよび図２９参照）、集中管理アーキテクチャは、以下の特徴を有する。セマンティックグラフストアは、セマンティックトリプルを含み得、セマンティックトリプルは、サービスエンティティ（ＳＥ）、例えば、ｏｎｅＭ２ＭにおけるＣＳＥ上に常駐し、その個々のＵＲＩを介して、異なるリソースツリー内の異なるリソースを指し示す。ＵＲＩは、ＵＲＩがＩｏＴシステム内で到達可能またはアクセス可能である場合、ＵＲＬと同一である。ＵＲＩを介してセマンティックトリプルによってアドレス指定または指し示されたリソース（図１４Ｂに図示される）は、サービスエンティティ上の同一階層リソースツリーに位置するか、例えば、全ての医師−Ｄのリソースが、ＳＥ１上のリソースツリー１に位置するか、または、複数のサービスエンティティ上の異なる階層リソースツリー上に置かれ、例えば、患者−Ａのリソースは、ＳＥ２上のリソースツリー２に位置し、患者−Ｂのリソースは、ＳＥ３上のリソースツリー３に位置するが、対応するセマンティックトリプルは、ＳＥ１に位置する。アプリケーションエンティティ（ＡＥ）、例えば、ｏｎｅＭ２ＭにおけるＡＥは、リソースツリー内のリソースまたはセマンティックグラフストア内のセマンティックトリプルのいずれかに対するＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ等のＲＥＳＴｆｕｌ動作のために、インターフェースＡＳ、例えば、ｏｎｅＭ２ＭにおけるＭｃａインターフェースを介して、サービスエンティティと通信し得る。サービスエンティティ（ＳＥ）は、リソースツリー内のリソースまたはセマンティックグラフストア内のセマンティックトリプルのいずれかに対するＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ等のＲＥＳＴｆｕｌ動作のために、ｏｎｅＭ２ＭにおけるインターフェースＳＳ、例えば、ＭｃｃまたはＭｃｃ’インターフェースを介して、別のサービスエンティティ（ＳＥ）と通信し得る。データ保管マネージャは、ＡＥおよび／またはＳＥ等の他の外部エンティティ、ならびにセマンティック保管マネージャおよび／または他の共通機能エンティティ等の内部エンティティとのデータ交換；ＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ等のためのコマンドを介したリソースツリーデータベース動作および管理に責任がある。セマンティック保管マネージャは、ＡＥおよび／またはＳＥ等の他の外部エンティティならびデータ保管マネージャおよび／または他の共通機能エンティティ等の内部エンティティとのセマンティックトリプル交換；もしくはＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ等のためのコマンドを介したセマンティックグラフストア動作および管理に責任がある。

図１４Ａでは、医師−Ｄのトリプルおよびデータの両方が、同一ＳＥ上に位置するように示されるが、それらは、異なるＳＥに位置することも可能である。図１４Ａに示される集中管理セマンティックグラフストアは、別のサービスドメイン、例えば、別のサービスプロバイダ内のＳＥに位置することも可能である。この場合、ＲＥＳＴｆｕｌ動作は、サービスドメインをまたぎ、例えば、ｏｎｅＭ２ＭにおけるインターフェースＭｃｃ’を介する。

ＩｏＴシステム内に複数の集中管理セマンティックグラフストアを伴う別のアーキテクチャは、図１４Ｂに例示される。このアーキテクチャでは、セマンティックグラフストア１は、ＳＥ１に位置し、セマンティックグラフストア２は、ＳＥ２に位置する。セマンティックグラフストア１とセマンティックグラフストア２との間の動作は、ＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ等のためのコマンドを介して、インターフェースＳＳ１、例えば、ｏｎｅＭ２ＭにおけるＭｃｃ／Ｍｃｃ’インターフェースで実施され得る。

図１４Ａに例示されるように、トリプルは、セマンティックグラフストア内で接続またはリンクされる。例えば、図１５に示されるように、トリプル１「医師Ｄは、患者Ａを有する」は、ＰａｔｉｅｎｔＡ＿ＵＲＩを介して、トリプル２「患者Ａは、心臓データＸを有する」とリンクされる。

＜Ｄｏｃｔｏｒ Ｄ＞等のリソースは、リソースツリー１内のＤｏｃｔｏｒ＿ＵＲＩに記憶され、＜Ｐａｔｉｅｎｔ Ａ＞および＜Ｈｅａｒｔ−Ｄａｔａ Ｘ＞等のリソース（図１４Ａには図示せず）は、それぞれ、リソースツリー２内のＰａｔｉｅｎｔＡ＿ＵＲＩおよびＨｅａｒｔＤａｔａ＿ＵＲＩ（図１４Ａには図示せず）に記憶される。

医師−Ｄのｅヘルスアプリケーション（例えば、アプリケーションエンティティ１）は、インターフェースＡＳ１を介するサービスエンティティ１におけるリソースツリー１における医師−Ｄの患者のリソース（許可が付与される場合）に対するＲＥＳＦＴｆｕｌ動作、インターフェースＳＳ１を介するサービスエンティティ１を通したサービスエンティティ２におけるリソースツリー２における医師−Ｄの患者のリソース（許可が付与される場合）に対するＲＥＳＦＴｆｕｌ動作、およびインターフェースＳＳ２を介するサービスエンティティ１を通したサービスエンティティ３におけるリソースツリー３における医師−Ｄの患者のリソース（許可が付与される場合）に対するＲＥＳＦＴｆｕｌ動作のために、インターフェースＡＳ１を介してサービスエンティティ１と通信し得る。医師−Ｄのｅヘルスアプリケーションは、インターフェースＡＳ１を介して、サービスエンティティ１におけるセマンティックグラフストア内の医師−Ｄの患者のセマンティックトリプル（許可が付与される場合）にＲＥＳＴｆｕｌ動作を適用し得る。

患者−Ａの心臓モニタｅヘルスアプリケーション（例えば、アプリケーションエンティティ２）は、インターフェースＡＳ２を介したサービスエンティティ２におけるリソースツリー２における患者−Ａまたは医師−Ｄのリソース（許可が付与される場合）に対するＲＥＳＦＴｆｕｌ動作、およびインターフェースＳＳ１を介したサービスエンティティ２を通したサービスエンティティ１におけるリソースツリー１における患者−Ａまたは医師−Ｄのリソース（許可が付与される場合）に対するＲＥＳＦＴｆｕｌ動作のために、インターフェースＡＳ２を介して、サービスエンティティ２と通信し得る。患者−Ａの心臓モニタｅヘルスアプリケーションは、インターフェースＳＳ１を介して、サービスエンティティ２を通して、サービスエンティティ１におけるセマンティックグラフストア内の患者−Ａまたは医師−Ｄのセマンティックトリプル（許可が付与される場合）にもＲＥＳＴｆｕｌ動作を適用し得る。

図１６−図２１等に図示されるステップを行うエンティティは、図５１Ｃまたは図５１Ｄに図示されるもの等のデバイス、サーバ、またはコンピューティングシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１６−図２２、図２７−図３０、図４５−図４９等に図示される方法は、図５１Ｃまたは図５１Ｄに図示されるデバイスまたはコンピューティングシステム等のコンピューティングデバイスのメモリ内に記憶されるソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピューティングデバイスのプロセッサによって実行されると、図１６−図２２、図２７−図３０、図４５−図４９等に図示されるステップを行う。ある例では、Ｍ２Ｍデバイスの相互作用に関して以下のさらなる詳細を伴って、図２９のＡＥ３７３は、図５１ＡのＭ２Ｍ端末デバイス１８上に常駐し得る一方、図２９のＳＥ３６１は、図５１ＡのＭ２Ｍゲートウェイデバイス１４上に常駐し得る。

図１６は、図１４Ａに図示されるアーキテクチャのための例示的一般的ＲＥＳＴｆｕｌセマンティックトリプル動作フローを図示する（例えば、医師−ＤのｅヘルスアプリケーションＡＥ１は、セマンティックトリプルまたはセマンティックグラフストア内のトリプルへのグラフ動作を要求する）。図１７は、図１４Ａに図示されるアーキテクチャのための例示的一般的ＲＥＳＴｆｕｌセマンティックトリプル動作フローを図示する（例えば、患者−Ａの心臓モニタｅヘルスアプリケーションＡＥ２は、セマンティックトリプルまたはセマンティックグラフストア内のトリプルへのグラフ動作を要求する）。図１６および図１７は、ＡＳインターフェース（例えば、ｏｎｅＭ２ＭにおけるＭｃａインターフェース）を介して、ＡＥとＳＥとの間、またはＳＳインターフェース（例えば、ｏｎｅＭ２ＭにおけるＭｃｃまたはＭｃｃ’インターフェース）を介して、ＳＥ間のＲＥＳＴｆｕｌ要求および応答メッセージに基づき得る。本明細書に説明される例示的機構は、ＳＥ１におけるセマンティックグラフストア１とＳＥ２におけるセマンティックグラフストア２との間のグラフ動作等、図１４Ｂに図示されるアーキテクチャのためのセマンティックグラフ動作にも適用可能である。要求メッセージは、異なるセマンティックトリプルまたはグラフ動作に基づいて、必須、動作依存、または随意のパラメータを含み得る。要求メッセージは、例であり、必ずしも、オプション、必須等ではない、以下のパラメータを含み得る。それは、実装依存である。

一般的ＲＥＳＴｆｕｌセマンティックトリプル動作フロー（例えば、図１６および図１７）を継続して参照すると、第１のパラメータの組は、リソース発見における試行に関連付けられた以下を含み得る。「Ｔｏ」フィールドは、＜ＳｅｍａｎｔｉｃＧｒａｐｈＳｔｏｒｅ＞リソースのアドレスまたはＩＤを含み得る。＜ＳｅｍａｎｔｉｃＧｒａｐｈＳｔｏｒｅ＞リソースは、事前プロビジョニングまたはリソース発見によって既知であり得る。「Ｆｒｏｍ」フィールドは、発信側１５１のＩＤ（例えば、ＡＥ ＩＤまたはＳＥ ＩＤ）を含み得る。これは、受信側１５２（例えば、ＳＥ）によって、セマンティックグラフストア内のセマンティックトリプル動作のための発信側のアクセス権をチェックするために使用され得る。動作フィールドは、ＣＲＥＡＴＥ（Ｃ），ＲＥＴＲＩＥＶＥ（Ｒ），ＵＰＤＡＴＥ（Ｕ），ＤＥＬＥＴＥ（Ｄ）等の実施されるべき動作を含み得る。動作タイプは、リソースツリー内のリソース動作のための「リソース」、セマンティックグラフストア内のトリプル動作のための「トリプル」、および／またはセマンティックグラフストアにおけるグラフ動作のための「グラフ」であり得る値を含み得る。デフォルトは、「リソース」である。本明細書に与えられる例の多くは、トリプルおよびグラフ動作に関する。要求識別子は、要求と応答との間で相関させるために使用されるべき要求識別子を含み得る。

一般的ＲＥＳＴｆｕｌセマンティックトリプル動作フロー（例えば、図１６および図１７）を継続して参照すると、第２のパラメータの組は、トリプルまたはグラフ動作のための動作依存パラメータと見なされ得る。以下により詳細に議論されるようなコンテンツおよびコンテンツフォーマットが存在し得る。コンテンツは、転送されるべきセマンティックコンテンツ（例えば、トリプルまたはグラフ）を含み得、セマンティックコンテンツは、セマンティックトリプルまたはグラフ動作の点から見て、異なって提示され得る。ある例では、ＣＲＥＡＴＥに関して、コンテンツは、「トリプル」または「グラフ」として＜ＯｐｅｒａｔｉｏｎＴｙｐｅ＞を伴う新しいセマンティックトリプルのコンテンツであり得る。例えば、「Ｄｏｃｔｏｒ−Ｄ＿ＵＲＩは、ＰａｔｉｅｎｔＡ＿ＵＲＩを有する」等のトリプル。ある例では、ＵＰＤＡＴＥに関して、コンテンツは、既存のセマンティックトリプルまたはグラフと置換されるべきコンテンツを含み得る。例えば、図１５に示されるトリプル１１０に対して、「Ｄｏｃｔｏｒ−Ｄ＿ＵＲＩは、ＰａｔｉｅｎｔＡ＿ＵＲＩ１を有する」を置換するための「Ｄｏｃｔｏｒ−Ｄ＿ＵＲＩは、ＰａｔｉｅｎｔＡ＿ＵＲＩ２を有する」。更新または置換されるべき既存のセマンティックトリプルまたはグラフは、＜ＳｅｍａｎｔｉｃＴｒｉｐｌｅＧｒａｐｈＩＤ＞（例えば、グラフのための一意の名前）によって明示的にアドレス指定されるか、またはセマンティックグラフストア内のトリプルまたはグラフ関係ネットワークに一致するようにこの新しいコンテンツを使用することを介して、セマンティッククエリエンジンによって推測され得る。ある例では、ＲＥＴＲＩＥＶＥに関して、コンテンツは、クエリセマンティックトリプルを含み得る。例えば、「？医師は、患者−Ａを有する」（？医師は、クエリのための変数である）は、患者−Ａの医師をクエリするためのものである。ある例では、ＤＥＬＥＴＥに関して、コンテンツは、削除されるべき既存のセマンティックトリプルまたはグラフのコンテンツを含み得る。既存のセマンティックトリプルまたはグラフは、削除するための＜ＳｅｍａｎｔｉｃＴｒｉｐｌｅＧｒａｐｈＩＤ＞（例えば、グラフのための一意の名前）によって明示的にアドレス指定されるか、またはセマンティックグラフストア内のトリプルまたはグラフに一致するようにこのコンテンツを使用することによって、セマンティッククエリエンジンによって推測され得る。

前述のコンテンツフォーマットに関し、コンテンツフォーマットは、トリプルのためのＮ−Ｔｒｉｐｌｅ、ＪＳＯＮ、ＲＤＦ／ＸＭＬ、もしくはタートル、クエリのためのＳＰＡＲＱＬもしくはＳＱＬ、または他の構造化されたテキストもしくはリテラル等のセマンティックトリプルまたはグラフ動作コンテンツのフォーマットと見なされ得る。

一般的ＲＥＳＴｆｕｌセマンティックトリプル動作フロー（例えば、図１６および図１７）を継続して参照すると、第３のパラメータの組が、考慮され得る。ｃｒｅａｔｏｒパラメータが存在し得、それは、転送されるべきセマンティックコンテンツの作成者、例えば、ＡＥ ＩＤまたはＳＥ ＩＤを示す。ＳｅｍａｎｔｉｃＴｒｉｐｌｅＧｒａｐｈＩＤｓパラメータも存在し得、それは、発信側１５１によって提示されないか、またはセマンティックグラフストア内の既存のトリプルと矛盾する場合、受信側１５２によって作成され得る。ＳｅｍａｎｔｉｃＴｒｉｐｌｅＧｒａｐｈＩＤｓパラメータは、セマンティックトリプルグラフのＩＤであり、絶対的または相対的であるが、セマンティックグラフストア内で一意であり得る。アクセス制御ポリシＩＤパラメータも存在し得、発信側１５１によって提示されない場合、受信側１５２が、発信側１５１のＩＤおよびサービスプロファイルに基づいて作成し得る。このパラメータは、受信側１５２によって、発信側のアクセス制御権をチェックし、適宜、動作を確証するために使用され得る。ＯｎｔｏｌｏｇｙＲｅｆパラメータも存在し得、発信側１５２によって提示されない場合、受信側１５２が、発信側１５１のＩＤおよびサービスプロファイルに基づいて、＜ｏｎｔｏｌｏｇｙＲｅｆ＞を作成し得る。

第３のパラメータの組を継続して参照すると、ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅｔｙｐｅパラメータ、ｒｅｓｕｌｔ ｃｏｎｔｅｎｔパラメータ、またはｆｉｌｔｅｒ ｃｒｉｔｅｒｉａパラメータも存在し得る。ｒｅｓｐｏｎｓｅ ｍｅｓｓａｇｅ ｔｙｐｅパラメータは、発行された要求に送信され得る応答のタイプおよび応答が発信側１５１に送信され得る時を示し得る。異なる応答タイプは、発信側１５１によって、とりわけ、通信、トリプル動作待ち時間、システム能力、現在の処理、または負荷状態に基づいて、要求され得る。応答メッセージタイプは、とりわけ、ＡＣＫ ｓｙｎｃ、ＡＣＫ ａｓｙｎｃ、ＮｏＡＣＫ ｓｙｎｃ、またはＡＣＫｎｏＡＣＫを含み得る。ＡＣＫ ｓｙｎｃに関して、承認後、受信側１５２は、受信側１５２がさらに要求を処理するであろうことを確認する肯定応答で応答し得る。要求される動作の実行の成功または失敗が、後に伝達されることになる。ＡＣＫ ａｓｙｎｃ｛ｌｉｓｔ ｏｆ ｎｏｔｉｆｉｃａｔｉｏｎ ｔａｒｇｅｔｓ｝に関して、承認後、受信側１５２は、受信側がさらに要求を処理するであろうことを確認する肯定応答で応答し得る。要求される動作の結果は、通知標的への通知として送信されるべきである。通知標的は、エンティティのリストとしてこのパラメータ内に、または通知標的リストが提供されないとき、発信側１５１に提供され得る。空通知標的リストが発信側１５１によって提供されるとき、要求される動作の結果を伴う通知は、全く送信され得ない。ＮｏＡＣＫ ｓｙｎｃに関して、承認後、受信側１５２は、要求される動作の完了後、要求される動作の結果で応答し得る。それは、ｒｅｓｐｏｎｓｅ ｔｙｐｅパラメータが要求に与えられないときのデフォルト挙動であり得る。ＡＣＫｎｏＡＣＫ｛ｌｉｓｔ ｏｆ ｎｏｔｉｆｉｃａｔｉｏｎ ｔａｒｇｅｔｓ｝に関して、承認後、受信側１５２は、そのステータスまたは他のサービスポリシに基づいて、応答する方法（上で説明されるＡＣＫまたはＮｏＡＣＫのいずれか）を決定し得る。

ｒｅｓｕｌｔ ｃｏｎｔｅｎｔパラメータも存在し得、ｒｅｓｕｌｔ ｃｏｎｔｅｎｔは、要求される動作の結果の期待されるコンポーネントを示す。セマンティックトリプルグラフＩＤ：要求セマンティックトリプルの＜ＳｅｍａｎｔｉｃＴｒｉｐｌｅＧｒａｐｈＩＤ＞。セマンティックトリプルまたはグラフは、コンテンツとして返される要求されるセマンティックトリプルまたはグラフの表現である。セマンティックトリプルノードは、要求セマンティックトリプルのトリプルノードのためのＵＲＩ、バンクノードラベル、または「リテラル」であり得る。これは、ＵＲＩが返される場合、＜ＵＲＩＴｙｐｅ＞によって示され得る。ＵＲＩタイプは、絶対的または相対的ＵＲＩを示す。相対的ＵＲＩが使用される場合、＜ＮａｍｅＳｐａｃｅ＞またはオントロジー参照が、相対的ＵＲＩ内に含まれ得る。真／偽は、要求される動作、例えば、ＳＰＡＲＱＬクエリ「ＡＳＫ」動作のブール論理結果である。

ｆｉｌｔｅｒ ｃｒｉｔｅｒｉａパラメータも存在し得、それは、セマンティックグラフストア内のフィルタリングされるセマンティックトリプルまたはグラフ動作のためのフィルタ基準を示す。ＳＰＡＲＱＬクエリのためのフィルタリングの例は、以下に示される。
ＰＲＥＦＩＸｒｄｆｓ：＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０１／ｒｄｆ−ｓｃｈｅｍａ＃＞
ＰＲＥＦＩＸｔｙｐｅ：＜ｈｔｔｐ：／／ｄｂｐｅｄｉａ．ｏｒｇ／ｃｌａｓｓ／ｙａｇｏ／＞
ＰＲＥＦＩＸｐｒｏｐ：＜ｈｔｔｐ：／／ｄｂｐｅｄｉａ．ｏｒｇ／ｐｒｏｐｅｒｔｙ／＞
ＳＥＬＥＣＴ？ｃｏｕｎｔｒｙ＿ｎａｍｅ？ｐｏｐｕｌａｔｉｏｎ
ＷＨＥＲＥ｛
？ｃｏｕｎｔｒｙａｔｙｐｅ：ＬａｎｄｌｏｃｋｅｄＣｏｕｎｔｒｉｅｓ；
ｒｄｆｓ：ｌａｂｅｌ？ｃｏｕｎｔｒｙ＿ｎａｍｅ；
ｐｒｏｐ：ｐｏｐｕｌａｔｉｏｎＥｓｔｉｍａｔｅ？ｐｏｐｕｌａｔｉｏｎ．
ＦＩＬＴＥＲ（？ｐｏｐｕｌａｔｉｏｎ＞１５００００００）．
｝

ＳＰＡＲＱＬ組み込みフィルタ機能は、以下にリストアップされる。
・ Ｌｏｇｉｃａｌ：！，＆＆，｜｜
・ Ｍａｔｈ：＋，−，＊，／
・ Ｃｏｍｐａｒｉｓｏｎ：＝，！＝，＞，＜，．．．
・ ＳＰＡＲＱＬ ｔｅｓｔｓ：ｉｓＵＲＩ，ｉｓＢｌａｎｋ，ｉｓＬｉｔｅｒａｌ，ｂｏｕｎｄ
・ ＳＰＡＲＱＬ ａｃｃｅｓｓｏｒｓ：ｓｔｒ，ｌａｎｇ，ｄａｔａｔｙｐｅ
・ Ｏｔｈｅｒ：ｓａｍｅＴｅｒｍ，ｌａｎｇＭａｔｃｈｅｓ，ｒｅｇｅｘ

応答メッセージは、異なるセマンティックトリプル動作に基づいて、全てのタイプのパラメータを含み得る。パラメータは、異なる方法で提供され得るが、以下は、例である。実装に応じて、いくつかのパラメータは、随意もしくは必須と見なされることも、そうでないこともある。例示的パラメータは、以下である。第１のパラメータの組は、応答ステータスまたは要求識別子を含み得る。応答ステータスは、要求される動作の結果が、成功、不成功、肯定応答（例えば、後に伝達されるべき結果）、または認可タイムアウト等の処理のステータスであることを示し得る。ｒｅｑｕｅｓｔ ｉｄｅｎｔｉｆｉｅｒ（ＩＤ）パラメータは、対応する要求を識別し得る。

動作依存と見なさ得る、第２のパラメータの組は、以下の例を含み得る：コンテンツまたはコンテンツステータス。コンテンツは、応答ステータスが成功である場合、１）ＣＲＥＡＴＥ（コンテンツがセマンティックグラフストア内の＜ＳｅｍａｎｔｉｃＴｒｉｐｌｅＧｒａｐｈＩＤ＞である）、２）ＵＰＤＡＴＥ（コンテンツがセマンティックグラフストア内で置換されるセマンティックトリプルもしくはグラフである）、３）ＤＥＬＥＴＥ（コンテンツが削除されるセマンティックトリプルもしくはグラフである）、または、４）ＲＥＴＲＩＥＶＥ（コンテンツは、セマンティッククエリ結果であり、それは、要求メッセージ内の＜ＲｅｓｕｌｔＣｏｎｔｅｎｔ＞によって示されるような＜ＳｅｍａｎｔｉｃＴｒｉｐｌｅＧｒａｐｈＩＤ＞、＜ＳｅｍａｎｔｉｃＴｒｉｐｌｅｓ／Ｇｒａｐｈ＞、＜ＳｅｍａｎｔｉｃＴｒｉｐｌｅＮｏｄｅｓ＞、もしくは＜Ｔｒｕｅ／Ｆａｌｓｅ＞ブール論理結果を含み得る）。応答ステータスが不成功である場合、応答内のｃｏｎｔｅｎｔパラメータは、エラー情報を含み得る。応答ステータスが肯定応答である場合、ｃｏｎｔｅｎｔパラメータは、＜ＲｅｓｐｏｎｓｅＴｙｐｅ＞が要求内に規定されるようなＡＣＫベースである場合は、＜ＳｅｍａｎｔｉｃＴｒｉｐｌｅＧｒａｐｈＩＤ＞を含み得る。ｃｏｎｔｅｎｔ ｓｔａｔｕｓパラメータは、応答ステータスが成功である場合にセマンティッククエリが返したコンテンツが部分的であるとき、それに応答して、ＲＥＴＲＩＥＶＥ動作を示し得る。

第３のパラメータの組は、以下の例であり得る：「Ｔｏ」または「Ｆｒｏｍ」。「ｔｏ」パラメータは、発信側１５１またはトランジットＳＥ１５０のアドレスまたはＩＤを示し得る。「ｆｒｏｍ」パラメータは、受信側１５２のＩＤを示し得る。

前述の動作のいくつかのいくつかの追加の詳細が、以下の図に「トリプル」とともに図示される。図１８は、ＣＲＥＡＴＥセマンティックトリプルのための動作フローを提供する。図１９は、ＲＥＴＲＩＥＶＥセマンティックトリプル−セマンティッククエリのための動作フローを提供する。図２０は、ＵＰＤＡＴＥセマンティックトリプルのための動作フローを提供する。図２１は、ＤＥＬＥＴＥセマンティックトリプルのための動作フローを提供する。

図１８から図２１に詳述される機構はまた、セマンティックグラフストアのためのセマンティックグラフ動作、またはセマンティックグラフストア間のセマンティックグラフ動作にも適用可能である。図１８は、ＣＲＥＡＴＥセマンティックトリプルのための例示的動作フローを図示する。ステップ２０１では、セマンティックトリプルＣＲＥＡＴＥ動作要求が、送信される。ステップ２０１の要求は、１）Ｔｏ：ＳｅｍａｎｔｉｃＧｒａｐｈＳｔｏｒｅおよびＦｒｏｍ：発信側ＩＤ（例えば、ＡＥ ＩＤまたはＳＥ ＩＤ）、２）動作：ＣＲＥＡＴＥ、３）パラメータ：ＲｅｑｕｅｓｔＩＤ、ＣｏｎｔｅｎｔＦｏｒｍａｔ（例えば、ＲＤＦ ＸＭＬ）、ＡｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤｓ、ＯｎｔｏｌｏｇｙＲｅｆ、Ｃｒｅａｔｏｒ、ＲｅｓｐｏｎｓｅＴｙｐｅ、ＲｅｓｕｌｔＣｏｎｔｅｎｔ（ＳｅｍａｎｔｉｃＴｒｉｐｌｅＩＤｓ）、および、４）コンテンツ：ＳｅｍａｎｔｉｃＴｒｉｐｌｅｓを含み得る。

図１８を継続して参照すると、ステップ２０２では、セマンティックトリプルＣＲＥＡＴＥ動作処理が、例えば、受信側１５２で生じる。セマンティックグラフストア１５４におけるセマンティックトリプルＣＲＥＡＴＥ動作の確証が存在し得る。確証は、以下を含み得る。発信側１５１が、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤ＞によって規定された標的セマンティックトリプルを作成するための権利を有するかどうか決定すること、または、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤ＞が存在しない場合、＜ＳｅｒｖｉｃｅＳｕｂｓｃｒｉｐｔｉｏｎＰｏｌｉｃｙ＞および他のサービスポリシに基づいて、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤ＞を作成し、割り当てること。＜ｏｎｔｏｌｏｇｙＲｅｆ＞を確証することもあり得、発信側１５１によって提供されない場合、＜ｏｎｔｏｌｏｇｙＲｅｆ＞を割り当て得る。加えて、発信側１５１によって、ステップ２０１のＣＲＥＡＴＥ要求内に提供される場合、＜ＳｅｍａｎｔｉｃＴｒｉｐｌｅＩＤｓ＞がセマンティックグラフストア１５４内にまだ存在していないことが検証され得る。存在していない場合、発信側１５１によって示唆される＜ＳｅｍａｎｔｉｃＴｒｉｐｌｅＩＤｓ＞が、使用され得、そうでなければ、一意の＜ＳｅｍａｎｔｉｃＴｒｉｐｌｅＩＤｓ＞が、作成されるべきセマンティックトリプルと共に使用される。「ＡｃｃｅｓｓＣｏｎｔｒｏｌＴｒｉｐｌｅｓ」（例えば、Ｗｈｏ−Ｗｈａｔ−Ｈｏｗを定義するアクセス制御ルールタプル）も、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤ＞によって識別される＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞下の＜ｐｒｉｖｉｌｅｇｅｓ＞によって規定されたアクセス制御ポリシルールに基づいて、作成されるべきセマンティックトリプルに関連付けられ得る。＜ｃｒｅａｔｏｒ＞が、ステップ２０１の要求内に含まれる場合、「ＣｒｅａｔｏｒＴｒｉｐｌｅ」が、作成されるべきセマンティックトリプルに関連付けられ得る。最後に、ステップ２０１のＣＲＥＡＴＥ要求の確証成功時、ステップ２０１の要求内に提供されない場合、セマンティックトリプルＣＲＥＡＴＥ動作コマンドを作成する。例えば、ＳＰＡＲＱＬ更新言語では、セマンティックグラフストア１５４におけるトリプル「ｉｎｓｅｒｔ」またはグラフ「ａｄｄ」。

図１８を継続して参照すると、ステップ２０３では、セマンティックＣＲＥＡＴＥ動作が、セマンティックグラフストア１５４内で実施される。例は、図１８に示される。例えば、ＣＲＥＡＴＥ動作をマッピングするために使用され得るこれらのグラフ管理動作を提供するために、ＳＰＡＲＱＬ１．１更新を介して、また、１）ＣＲＥＡＴＥ（空グラフをサポートするストア内に新しいグラフを作成する）、２）ＣＯＰＹ（別のコピーを含むようにグラフを修正する）、３）ＭＯＶＥ（１つのグラフからのデータを全て別のグラフの中に移動させる）、または、４）ＡＤＤ（全てのデータを１つのグラフから別のグラフの中に複製する）も可能である。ステップ２０４では、応答をＣＲＥＡＴＥ動作結果で構成する。ステップ２０５では、セマンティックトリプルＣＲＥＡＴＥ動作応答がある。応答は、１）Ｔｏ：発信側ＩＤ（例えば、ＡＥ ＩＤまたはＳＥ ＩＤ）およびＦｒｏｍ：受信側ＩＤ（例えば、ＳＥ ＩＤ）、２）パラメータ：ＲｅｑｕｅｓｔＳｔａｔｕｓ（成功）、ＲｅｑｕｅｓｔＩＤ、および、３）コンテンツ：ＳｅｍａｎｔｉｃＴｒｉｐｌｅＩＤｓ（ＲｅｓｐｏｎｓｅＴｙｐｅがＮｏＡＣＫｓｙｎｃである場合）を含み得る。

図１９は、ＲＥＴＲＩＥＶＥセマンティックトリプル−セマンティッククエリのための例示的動作フローを図示する。ステップ２１１では、セマンティックトリプルＲＥＴＲＩＥＶＥ動作要求が、送信される。ステップ２１１の要求は、１）Ｔｏ：ＳｅｍａｎｔｉｃＧｒａｐｈＳｔｏｒｅおよびＦｒｏｍ：発信側ＩＤ（例えば、ＡＥ ＩＤまたはＳＥ ＩＤ）、２）動作：ＲＥＴＲＩＥＶＥ、３）パラメータ：ＲｅｑｕｅｓｔＩＤ、ＣｏｎｔｅｎｔＦｏｒｍａｔ（例えば、ＳＰＡＲＱＬ）、ＦｉｌｔｅｒＣｒｉｔｅｒｉａ、またはＲｅｓｕｌｔＣｏｎｔｅｎｔ、および、４）コンテンツ：ＳｅｍａｎｔｉｃＴｒｉｐｌｅｓを含み得る。

図１９を継続して参照すると、ステップ２１２では、セマンティックトリプルＲＥＴＲＩＥＶＥ動作処理が、例えば、受信側１５２で生じる。セマンティックグラフストア１５４におけるセマンティックトリプルＲＥＴＲＩＥＶＥ動作の確証が存在し得る。確証は、以下を含み得る。発信側１５１（ＡＥ ＩＤまたはＳＥ ＩＤを使用する）がトリプルに関連付けられた＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞に基づいて、セマンティックトリプルまたはそのクエリセマンティックトリプルによって規定された他の情報を読み出す権利を有するかどうか決定する。＜ｏｎｔｏｌｏｇｙＲｅｆ＞も、必要とされる場合、確証され得る。加えて、ＦｉｌｔｅｒＣｒｉｔｅｒｉａが有効であるかどうか決定され得る。最後に、ステップ２１１のＲＥＴＲＩＥＶＥ要求の確証成功時、セマンティッククエリコマンドが、作成され得る。例えば、ＳＰＡＲＱＬクエリ言語では、結果値のテーブルに対する「ＳＥＬＥＣＴ」、ＲＤＦグラフに対する「ＣＯＮＳＴＲＵＣＴ」、「Ｔｒｕｅ／Ｆａｌｓｅ」ブール演算結果に対する「ＡＳＫ」、またはセマンティックグラフストア１５４が返すどんなものにも対する「ＤＥＳＣＲＩＢＥ」である。

図１９を継続して参照すると、ステップ２１３では、セマンティッククエリ動作が、セマンティックグラフストア１５４内で実施される。例は、図１９に示される。ステップ２１４では、ＲＥＴＲＩＥＶＥ動作結果を伴う応答を構成する。ステップ２１５では、セマンティックトリプルＲＥＴＲＩＥＶＥ動作応答が存在する。応答は、１）Ｔｏ：発信側ＩＤ（例えば、ＡＥ ＩＤまたはＳＥ ＩＤ）およびＦｒｏｍ：受信側ＩＤ（例えば、ＳＥ ＩＤ）、２）パラメータ：ＲｅｑｕｅｓｔＳｔａｔｕｓ（成功）、ＲｅｑｕｅｓｔＩＤ、および、３）コンテンツ：ＳｅｍａｎｔｉｃＴｒｉｐｌｅｓ（ＲｅｓｐｏｎｓｅＴｙｐｅがＮｏＡＣＫｓｙｎｃである場合）を含み得る。

図２０は、ＵＰＤＡＴＥセマンティックトリプルのための例示的動作フローを図示する。ステップ２２１では、セマンティックトリプルＵＰＤＡＴＥ動作要求が、送信される。ステップ２２１の要求は、１）Ｔｏ：ＳｅｍａｎｔｉｃＧｒａｐｈＳｔｏｒｅおよびＦｒｏｍ：発信側ＩＤ（例えば、ＡＥ ＩＤまたはＳＥ ＩＤ）、２）動作：ＵＰＤＡＴＥ、３）パラメータ：ＲｅｑｕｅｓｔＩＤ、ＳｅｍａｎｔｉｃＴｒｉｐｌｅＩＤｓ、ＣｏｎｔｅｎｔＦｏｒｍａｔ（例えば、ＲＤＦ ＸＭＬ）、ＦｉｌｔｅｒＣｒｉｔｅｒｉａ、ＲｅｓｕｌｔａｎｔＣｏｎｔｅｎｔ、および４）コンテンツ：ＳｅｍａｎｔｉｃＴｒｉｐｌｅｓを含み得る。

図２０を継続して参照すると、ステップ２２２では、セマンティックトリプルＵＰＤＡＴＥ動作処理が、例えば、受信側１５２で生じる。セマンティックグラフストア１５４内のセマンティックトリプルＵＰＤＡＴＥ動作の確証が存在し得る。確証は、以下を含み得る。発信側１５１が、トリプルに関連付けられた＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞によって規定された標的セマンティックトリプルを更新するための権利を有するかどうかを決定する。＜ｏｎｔｏｌｏｇｙＲｅｆ＞の確証およびＦｉｌｔｅｒＣｒｉｔｅｒｉａが有効であるかどうの決定も存在し得る。最後に、ステップ２２１のＵＰＤＡＴＥ要求確証成功時、ステップ２２１のＵＰＤＡＴＥ要求内に提供されない場合、セマンティックトリプルＵＰＤＡＴＥ動作コマンドを作成する。例えば、ＳＰＡＲＱＬ更新言語では、トリプルを更新するための「ＤＥＬＥＴＥ」および「ＩＮＳＥＲＴ」。

図２０を継続して参照すると、ステップ２２３では、セマンティックＵＰＤＡＴＥ動作が、セマンティックグラフストア１５４内で実施される。例えば、ＵＰＤＡＴＥ動作をマッピングために使用され得るこれらのグラフ管理動作を提供するために、ＳＰＡＲＱＬ１．１更新を介して、また、１）ＣＲＥＡＴＥ（新しいグラフを空グラフをサポートするストア内に作成する）、２）ＣＯＰＹ（別のコピーを含むようにグラフを修正する）、３）ＭＯＶＥ：データの全てを１つのグラフから別のグラフの中に移動させる）、４）ＡＤＤ（全てのデータを１つのグラフから別のグラフの中に複製する）、または、５）ＤＲＯＰ（グラフおよびそのコンテンツの全てを除去する）も可能である。ステップ２２４では、ＵＰＤＡＴＥ動作結果を伴う応答を構成する。ステップ２２５では、セマンティックトリプルＵＰＤＡＴＥ動作応答が存在する。応答は、１）Ｔｏ：発信側ＩＤ（例えば、ＡＥ ＩＤまたはＳＥ ＩＤ）およびＦｒｏｍ：受信側ＩＤ（例えば、ＳＥ ＩＤ）、２）パラメータ：ＲｅｑｕｅｓｔＳｔａｔｕｓ（成功）、ＲｅｑｕｅｓｔＩＤ、および、３）コンテンツ：ＳｅｍａｎｔｉｃＴｒｉｐｌｅｓ（ＲｅｓｐｏｎｓｅＴｙｐｅがＮｏＡＣＫｓｙｎｃである場合）を含み得る。

図２１は、ＤＥＬＥＴＥセマンティックトリプルのための例示的動作フローを図示する。ステップ２３１では、セマンティックトリプルＤＥＬＥＴＥ動作要求が、送信される。ステップ２３１の要求は、１）Ｔｏ：ＳｅｍａｎｔｉｃＧｒａｐｈＳｔｏｒｅおよびＦｒｏｍ：発信側ＩＤ（例えば、ＡＥ ＩＤまたはＳＥ ＩＤ）、２）動作：ＤＥＬＥＴＥ、３）パラメータ：ＲｅｑｕｅｓｔＩＤ、ＳｅｍａｎｔｉｃＴｒｉｐｌｅＩＤｓ、ＣｏｎｔｅｎｔＦｏｒｍａｔ（例えば、ＲＤＦ ＸＭＬ）、ＦｉｌｔｅｒＣｒｉｔｅｒｉａ、ＲｅｓｕｌｔａｎｔＣｏｎｔｅｎｔ、および、４）コンテンツ：ＳｅｍａｎｔｉｃＴｒｉｐｌｅｓを含み得る。

図２１を継続して参照すると、ステップ２３２では、セマンティックトリプルＤＥＬＥＴＥ動作処理が、例えば、受信側１５２で生じる。セマンティック受信側１５２（例えば、セマンティックグラフストア１５４）内のセマンティックトリプルＤＥＬＥＴＥ動作の確証が存在し得る。確証は、以下を含み得る。発信側１５１が、トリプルに関連付けられた＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞によって規定された標的セマンティックトリプルを削除するための権利を有するかどうか決定する。ＦｉｌｔｅｒＣｒｉｔｅｒｉａが有効であるかどうも決定され得る。最後に、ステップ２３１のＤＥＬＥＴＥ要求の確証成功時、ステップ２３１の要求内に提供されない場合、セマンティックトリプルＤＥＬＥＴＥ動作コマンドを作成する。例えば、ＳＰＡＲＱＬ更新言語では、特定のグラフ内の全てのトリプルを除去するための「ＤＥＬＥＴＥ」および「ＣＬＥＡＲ」である。

図２１を継続して参照すると、ステップ２３３では、セマンティックＤＥＬＥＴＥ動作が、セマンティックグラフストア１５４内で実施される。例えば、ＤＥＬＥＴＥ動作をマッピングするために使用され得るこれらのグラフ管理動作を提供するためのＳＰＡＲＱＬ１．１更新を介して、また、１）ＭＯＶＥ：データの全てを１つのグラフから別のグラフの中に移動させる）または、２）ＤＲＯＰ（グラフおよびそのコンテンツの全てを除去する）も可能である。ステップ２３４では、ＤＥＬＥＴＥ動作結果を伴う応答を構成する。ステップ２３５では、セマンティックトリプルＤＥＬＥＴＥ動作応答がある。応答は、１）Ｔｏ：発信側ＩＤ（例えば、ＡＥ ＩＤまたはＳＥ ＩＤ）およびＦｒｏｍ：受信側ＩＤ（例えば、ＳＥ ＩＤ）、２）パラメータ：ＲｅｑｕｅｓｔＳｔａｔｕｓ（成功）、ＲｅｑｕｅｓｔＩＤ、および、３）コンテンツ：ＳｅｍａｎｔｉｃＴｒｉｐｌｅｓ（ＲｅｓｐｏｎｓｅＴｙｐｅがＮｏＡＣＫｓｙｎｃである場合）を含み得る。

本明細書に議論されるように、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤ＞によって規定される＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞が、グラフ図を用いたアクセス制御または＜ＡｃｃｅｓｓＣｏｎｔｒｏｌＴｒｉｐｌｅｓ＞を用いたアクセス制御等の方法に基づいて、セマンティックグラフストア内のアクセス制御のために使用され得る。グラフ図を用いたアクセス制御を参照して、セマンティックグラフストアのグラフ図（図４９Ａに示される例）は、ベースグラフストア上に構築されたサブグラフであり、それは、アプリケーションに関連するデータへの特に構成されたアクセスを提供することによってデータの有用性を強化するか、または付与されたアクセス権に応じてデータへのアクセスを与えることによって、データへのアクセス制御を可能にし得る。グラフ図アプローチは、図４９Ｂに示されるように、以下のステップを含み得る。ステップ３１１では、異なるグラフ図（例えば、患者−Ａのためのグラフ図３０４、患者−Ｂのためのグラフ図３０６、または医師−Ｄのためのグラフ図３０８）が、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞によって規定されたアクセス制御ルール毎に作成され得る。グラフ図３０４は、患者−Ａのアクセス可能トリプルを伴う患者−Ａのサブグラフであり得る。グラフ図３０６は、患者−Ｂのアクセス可能トリプルを伴う患者−Ｂのサブグラフであり得る。グラフ図３０８は、患者によってアクセス可能ではない医師−Ｄのトリプルであり得る。円形３０９は、医師−Ｄグラフ図（例えば、医師−Ｄのトリプル、患者−Ａのトリプル、および患者−Ｂのトリプルの合体である医師’Ｄのアクセス可能トリプルを伴う医師−Ｄのサブグラフ）であり得る。

ステップ３１１を継続して参照すると、アクセス制御ポリシに基づいてグラフ図を作成するためのいくつかの複数の方法が存在する。第１の方法では、サブオントロジー参照モデルを伴うグラフ図のサブグラフが、構築され得る。このサブグラフは、アクセス制御ポリシに基づいて構成され得、次いで、セマンティッククエリが、サブグラフ内で実施され得る。第２の方法では、セマンティッククエリによるグラフ図のためのサブグラフが、以下の例に示されるように構築され得る。
グラフ図３０４（例えば、患者−Ａのグラフ図）：
ＣＯＮＳＴＲＵＣＴ｛
？ｄｏｃｔｏｒ＿：ｔａｋｅＣａｒｅＯｆ？ｐａｔｉｅｎｔ
？ｄｏｃｔｏｒ＿：ｎａｍｅ？ｎａｍｅ
？ｓａｍｐｌｅ＿：ｍｅａｓｕｒｅＦｏｒ？ｐａｔｉｅｎｔ
？ｓａｍｐｌｅ＿：ｓＶａｌｕｅ？ｓＶａｌｕｅ
？ｓａｍｐｌｅ＿：ｄＶａｌｕｅ？ｄＶａｌｕｅ
？ｓａｍｐｌｅ＿：ｍｅａｓｕｒｅｄＯｎ？ｄａｔｅ
｝
ＷＨＥＲＥ｛
？ｐａｔｉｅｎｔｅｘ：ｎａｍｅ“Ｐａｔｉｅｎｔ−Ａ”
？ｐａｔｉｅｎｔｅｘ：ｄａｔｅＯｆＢｉｒｔｈ“２００−０８−３”＾＾ｘｓｄ：ｄａｔｅ．
？ｄｏｃｔｏｒｅｘ：ｔａｋｅＣａｒｅＯｆ？ｐａｔｉｅｎｔ
？ｄｏｃｔｏｒｅｘ：ｎａｍｅ？ｎａｍｅ
？ｓａｍｐｌｅｅｘ：ｍｅａｓｕｒｅＦｏｒ？ｐａｔｉｅｎｔ
？ｓａｍｐｌｅｅｘ：ｓＶａｌｕｅ？ｓＶａｌｕｅ
？ｓａｍｐｌｅｅｘ：ｄＶａｌｕｅ？ｄＶａｌｕｅ
？ｓａｍｐｌｅｅｘ：ｍｅａｓｕｒｅｄＯｎ？ｄａｔｅ｝

図４９Ｂを継続して参照すると、ステップ３１２では、ＡＥまたはＳＥの各セマンティックトリプル動作要求に対して、図は、標的セマンティックトリプルの＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞によって定義された発信側の権利に基づいて選択され得る。ステップ３１３では、セマンティックトリプル動作が、選択された図内で実施され、選択された図は、発信側が要求されるセマンティックトリプル動作に対して、可能にされた、セマンティックグラフストアからのそれらのセマンティックトリプルのみを含む。

図４９Ｃは、＜ＡｃｃｅｓｓＣｏｎｔｒｏｌＴｒｉｐｌｅｓ＞を伴うアクセス制御に基づいて、セマンティックグラフストア内のアクセス制御のために使用される＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤ＞によって規定された＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞のための例示的方法の概要を図示する。ステップ３１６では、セマンティックグラフストア内の＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞によって規定されたアクセス制御ルールが、構築され得る。ステップ３１７では、標的セマンティックトリプルは、それらの＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤ＞または関連アクセス制御ルールを伴う＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞に関連付けられ得る。ステップ３１８では、セマンティックトリプル動作が、発信側が動作することを可能にするアクセス制御ルールに関連付けられた選択されたセマンティックトリプルを用いて実施され得る。

図５２は、セマンティックグラフストアに関連付けられた例示的アクセス制御ポリシを図示する。図２２は、（図５２におけるような）セマンティックグラフストア内のアクセス制御ポリシの例のための例示的コールフロー（方法）を図示する。図２２の方法は、アクセス制御情報を標的トリプルと共に使用し、それらを一緒にセマンティックグラフストアの中に挿入する方法の例を図示する。図２２のステップ２４０では、（図２３に示されるような）ｅヘルスオントロジー参照モデルが、事前に構成され得、（図２４に示されるような）アクセス制御オントロジーモデルが、事前に構成され得る。ステップ２４１では、発信側１６２は、アクセス制御ポリシをホストするＳＥ１６３において＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースを作成することを要求する。ステップ２４２では、ＳＥ１６３は、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞リソースをリソースツリー内に作成する。ステップ２４３では、ＳＥ１６３は、成功結果の指示で発信側１６２に応答する。ステップ２４４では、ＳＥ１６３は、この＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞をセマンティックグラフストア内に挿入することをＳＥ１６４に要求する。ステップ２４５では、ＳＥ１６４は、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞をセマンティックグラフストア内に作成する。これは、アクセス制御オントロジー（図２４に示される）を使用して、この＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞下にアクセス制御ルールを表すための＜ＡｃｃｅｓｓＣｏｎｔｒｏｌＴｒｉｐｌｅｓ＞を作成し、＜ＡｃｃｅｓｓＣｏｎｔｒｏｌＴｒｉｐｌｅｓ＞をセマンティックグラフストア内に挿入することを含み得る。

図２２を継続して参照すると、ステップ２４６では、ＳＥ１６４は、成功結果の指示でＳＥ１６３に応答する。ステップ２４７では、発信側１６２は、＜ＳｅｍａｎｔｉｃＴｒｉｐｌｅｓ＞をセマンティックグラフストア内に作成することを要求する。ステップ２４８では、ＳＥ１６３は、ステップ２４７の要求をセマンティックグラフストアをホストするＳＥ１６４に転送する。ステップ２４９では、ＳＥ１６４は、セマンティックトリプルＣＲＥＡＴＥ動作を実施する。ＳＥ１６４は、発信側１６２のＩＤおよび関連＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞を使用することによって、セマンティックグラフストア内のＣＲＥＡＴＥ動作を確証し得る。＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞は、それがない場合、作成され得る。ＳＥ１６４は、図２５に示されるように、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞を作成されるべきトリプルとセマンティックグラフストア内で結合し得る。ＳＥ１６４は、＜ＡｃｃｅｓｓＣｏｎｔｒｏｌＴｒｉｐｌｅｓ＞に関連付けられたトリプルをセマンティックグラフストア内に挿入し得る。ステップ２５０では、ＳＥ１６４は、成功結果とともに、メッセージをＳＥ１６３に送信し得る。ステップ２５１では、ＳＥ１６３は、成功結果で発信側１６２に応答し得る。

図２２を参照すると、ステップ２５２では、発信側１６１は、セマンティックトリプルＲＥＴＲＩＥＶＥ動作を要求する。ステップ２５３では、ＳＥ１６３は、ステップ２５２の要求をＳＥ１６４に送信する。ステップ２５４では、ＳＥ１６４は、セマンティックトリプルＲＥＴＲＩＥＶＥ動作を実施する。ＳＥ１６４は、図２６に示されるように、発信側１６１のＩＤを使用することによって、ｒｅｔｒｉｅｖｅ動作を確証し、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞を用いてセマンティッククエリコマンドを構成し得る。ＳＥ１６４は、＜ＡｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞を用いてクエリを実施し得る。ステップ２５５では、ＳＥ１６４は、成功結果とともに、メッセージをＳＥ１６３に送信する。ステップ２５６では、ＳＥ１１６３は、成功結果とともに、メッセージを発信側１６１に送信する。

概して、アプリケーションが、発信側１６１によって提供されるトリプルに関してセマンティッククエリを開始する場合、ＳＥ１６４内のクエリエンジンが、クエリ検索を行い、それは、自動的に、セマンティックグラフストア内に挿入されているＡｃｃｅｓｓＣｏｎｔｒｏｌＴｒｉｐｌｅｓを使用する。それは、＜ＡｃｃｅｓｓＣｏｎｔｒｏｌＴｒｉｐｌｅｓ＞と発信側１６１によって作成されたトリプルとの間の結合のせいであり得る。クエリＡＥまたはＳＥのみ、図２６に示されるように、アクセス制御ルールを識別するために、その識別（例えば、ＡＥ ＩＤまたはＳＥ ＩＤ）を提供する必要があることに留意されたい。

セマンティックグラフストア内のアクセス制御のための例示的ファイルは、図２３、図２４、図２５、図２６、および図５３Ａから図５３Ｃに示される。機構は、集中管理セマンティックグラフストアを用いた例であるが、一般的プロシージャが、全ての種類のセマンティックグラフストアに適用可能であり得る。

セマンティッククエリを介したリソース発見が、以下に議論される。図５４は、セマンティッククエリを含むリソース発見を実施するための例示的方法を図示する。ステップ３２１では、発信側１６１（例えば、ＡＥまたはＳＥ）は、セマンティッククエリを、セマンティックグラフストアをホストする、ＳＥ１６４に送信し得る。要求に応答して、ＳＥ１６４は、セマンティッククエリをセマンティックグラフストアにおいて実施し得る。ステップ３２２では、発信側１６１は、ＳＥ１６４から、ステップ３２１における成功クエリに応答して、トリプルまたはトリプルノードを受信し得る。ステップ３２２のトリプルの受信に続き得るステップ３２３では、発信側１６１は、リソースからのＲＥＴＲＩＥＶＥ要求を、リソースツリーをホストする、ＳＥ１６４に送信し得る。リソースは、ＳＥ１６４のリソースツリー内にあり、ステップ３２２において受信されたトリプルまたはトリプルノードに指定された、または関連付けられたＵＲＩまたはＵＲＬ（ユニフォームリソースロケータ）によってアドレス指定され得る。ＳＥ１６４は、ＲＥＴＲＩＥＶＥ動作をリソースツリー内で実施する。ステップ３２３に応答し得るステップ３２４では、発信側１６１は、成功ｒｅｔｒｉｅｖｅ動作からトリプルまたはトリプルノードを受信する。

図２７は、階層リソースツリー内に分散されたセマンティック記述子の例示的アーキテクチャを図示する。この分散型アーキテクチャは、複数の特徴を有する。セマンティッククエリのために使用される一時的セマンティックグラフストア（例えば、一時的セマンティックグラフストア３３０または一時的セマンティックグラフストア３３８）が、ｏｎｅＭ２ＭにおけるＣＳＥ等のサービスエンティティ（例えば、ＳＥ３３１またはＳＥ３３２）上にローカルに常駐し、階層リソースツリー内に分散されたセマンティック記述子（例えば、セマンティック記述子３３３またはセマンティック記述子３３４）から抽出されるセマンティックトリプルを含み得る。セマンティックトリプルを含むセマンティック記述子は、複数のサービスエンティティ上の異なる階層リソースツリーに位置し得る。例えば、セマンティック記述子３３４は、ＳＥ３３２上のリソースツリー３３７内に位置し、ＳＥ３３１上のリソースツリー３３９内に位置し得る。ｏｎｅＭ２ＭにおけるＡＥ等のアプリケーションエンティティ（例えば、ＡＥ３３５）は、リソースツリー内のセマンティック記述子リソースに関するＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ等のＲＥＳＴｆｕｌ動作のために、ｏｎｅＭ２ＭにおけるＭｃａインターフェース等のインターフェースＡＳ３４０を介して、ＳＥ３３２と通信し得る。ＳＥ３３２は、リソースツリー内のセマンティック記述子リソースに関するＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ等のＲＥＳＴｆｕｌ動作のために、ｏｎｅＭ２ＭにおけるＭｃｃまたはＭｃｃ’インターフェース等のインターフェースＳＳ３３６を介して、別のＳＥ３３１と通信し得る。

階層リソースツリー内のセマンティック記述子に関するＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、およびＤＥＬＥＴＥ等のＲＥＳＴｆｕｌ動作は、他のリソースツリー内のリソースに対する動作と類似する。背景に述べられたように、セマンティッククエリは、セマンティック検索と異なり、セマンティッククエリは、セマンティックグラフストア内でリンクされた全てのセマンティックトリプルを用いて実施されるべきである。したがって、ローカル一時的セマンティックグラフストアは、本明細書では、セマンティッククエリ目的のために開示される。

図２８は、リソースツリー内に分散型セマンティック記述子を伴う例示的セマンティッククエリを図示する。ステップ３５１では、セマンティックトリプルＲＥＴＲＩＥＶＥ動作を含む要求が、受信側３３２（すなわち、ＳＥ３３２）によって受信され得る。要求は、１）標的リソースのアドレスまたはＩＤ（例えば、Ｔｏアドレス）、２）発信側ＩＤ（例えば、ＡＥ ＩＤまたはＳＥ ＩＤ）、３）動作（例えば、ＲＥＴＲＩＥＶＥ）、４）パラメータ（例えば、ＲｅｑｕｅｓｔＩＤ，ＣｏｎｔｅｎｔＦｏｒｍａｔ（例えば、ＳＰＡＲＱＬ），ＦｉｌｔｅｒＣｒｉｔｅｒｉａ（Ｓｅｍａｎｔｉｃ）、ＲｅｓｕｌｔＣｏｎｔｅｎｔ）、または、５）コンテンツ（例えば、ＱｕｅｒｙＳｅｍａｎｔｉｃＴｒｉｐｌｅｓ）を含み得る。ステップ３５２では、ステップ３５１の要求に基づいて、受信側３３２は、セマンティックトリプルＲＥＴＲＩＥＶＥ動作に関連付けられた処理を行い得る。受信側３３２は、リソースツリー間でセマンティック記述子発見を実施し得る。受信側３３２は、リソースツリー内のセマンティックトリプルＲＥＴＲＩＥＶＥ動作を確証し得る。例えば、各セマンティック記述子のための＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞によって規定されたアクセス制御ポリシルールに基づいて、発信側３３５がリソースツリー内のセマンティック記述子を読み出すための権利を有することを決定する。受信側３３２は、ＦｉｌｔｅｒＣｒｉｔｅｒｉａが有効であるかどうかを決定し得る。ＲＥＴＲＩＥＶＥ要求の確証成功に基づいて、受信側３３２は、発見されたセマンティック記述子を読み出し得る。受信側３３２は、読み出されたセマンティック記述子からセマンティックトリプルを抽出し、それらをローカル一時的セマンティックグラフストアの中に置き得る。ＳＰＡＲＱＬ更新動作が、一時的セマンティックグラフストアをロードするために使用され得る。受信側３３２は、要求内に提供されない場合、セマンティッククエリコマンドを構築し得る（例えば、ＳＰＡＲＱＬクエリ言語で）。受信側３３２は、セマンティッククエリを標的クエリセマンティックトリプルおよびＦｉｌｔｅｒＣｒｉｔｅｒｉａを用いて一時的セマンティックグラフストアにおいて実施し得る。受信側３３２は、一時的セマンティックグラフストア内のセマンティックトリプル（例えば、全て）を除去し得る。ステップ３５３では、受信側３３２は、メッセージを構成し、セマンティッククエリ結果とともに、発信側３３５に送信し得る。

本明細書では、一時的セマンティックグラフストアは、リソースツリーから発見されたセマンティック記述子から抽出されるセマンティックトリプルをリンクし、例えば、セマンティッククエリのための関係グラフを形成するために使用され得ることが想定される。この一時的セマンティックグラフストアは、各セマンティッククエリ後クリアされ、次いで、別のセマンティッククエリのために発見されたセマンティック記述子から抽出されるセマンティックトリプルの別のグループがロードされ得る。したがって、一時的セマンティックグラフストアは、各クエリ後、セマンティックトリプルを保持せず、クエリグラフを形成するセマンティックトリプルが、発信側がこの一時的セマンティックグラフストアと動作を有することが可能にされるトリプルのみであることを確実にし得る。

セマンティックグラフストアおよび階層リソースツリーの両方内にセマンティック記述子を伴うハイブリッドアーキテクチャが、本明細書において開示される。図２９は、セマンティックグラフストアおよび階層リソースツリー内のセマンティック記述子のための例示的アーキテクチャを図示する。ハイブリッドアーキテクチャは、以下の特徴を有し得る。セマンティッククエリのために使用される集中管理セマンティックグラフストア３６０が、存在し得、それは、ＳＥ３６１（例えば、ｏｎｅＭ２ＭにおけるＣＳＥ）上に常駐し得る。集中管理セマンティックグラフストア３６０は、リソースツリー３６４、リソースツリー３６５、またはリソースツリー３６６等の階層リソースツリー内に分散されたセマンティック記述子からのセマンティックトリプルを含み得る。リソースツリー３６４のセマンティック記述子３６８、リソースツリー３６５のセマンティック記述子３６９、またはリソースツリー３６６のセマンティック記述子３７０が、存在し得る。示されるように、セマンティックトリプルを含むセマンティック記述子は、複数のサービスエンティティ上の異なる階層リソースツリーに位置し得る。

図２９を継続して参照すると、以下は、セマンティック記述子のための例示的オプションである。第１のオプションでは、リソースツリー内のセマンティック記述子は、セマンティックトリプルを含む実際リソースである。ＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、またはＤＥＬＥＴＥの動作が、リソースツリー内の任意の他のタイプリソースに対する動作のように、リソースツリー内のセマンティック記述子に関して実施され得る。しかし、集中管理セマンティックグラフストア３６０内のセマンティックグラフは、リソースツリー内のセマンティック記述子に関して動作が実施される度に、それらのセマンティック記述子と同期させられ得る。集中管理セマンティックグラフストア３６０は、セマンティッククエリおよび他のセマンティック分析動作のために使用され得る。この第１のオプションは、分散型アプローチに近いと考えられ得る。

図２９を継続して参照すると、第２のオプションでは、リソースツリー内のセマンティック記述子は、セマンティックトリプルを含まない仮想リソースであり得る。リソースツリー内の仮想リソースセマンティック記述子に関して実施されるＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、またはＤＥＬＥＴＥの動作は、集中管理セマンティックグラフストア３６０内での実際の動作をトリガし得る。集中管理セマンティックグラフストア３６０は、セマンティッククエリのためだけではなく、それは、セマンティックトリプルを記憶するためにも使用され得る。この第２のオプションは、集中管理アプローチに近いと考えられ得る。

図２９を参照すると、アプリケーションエンティティ（例えば、ＡＥ３６７）は、リソースツリー（例えば、３６５）内のセマンティック記述子リソース（例えば、セマンティック記述子３６９）に関するＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ等のＲＥＳＴｆｕｌ動作、ならびに集中管理セマンティックグラフストア３６０内のセマンティックトリプルに関するセマンティッククエリのために、インターフェースＡＳ３７１、例えば、ｏｎｅＭ２ＭにおけるＭｃａインターフェースを介して、サービスエンティティ（例えば、ＳＥ３６２）と通信し得る。ある例では、ＳＥ３６２は、リソースツリー（例えば、リソースツリー３６４）内のセマンティック記述子リソースに関するＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ等のＲＥＳＴｆｕｌ動作、ならびに集中管理セマンティックグラフストア内のセマンティックトリプルに関するセマンティッククエリのために、インターフェースＳＳ３７２、例えば、ｏｎｅＭ２ＭにおけるＭｃｃまたはＭｃｃ’インターフェースを介して、別のＳＥ３６３と通信し得る。第１のオプションでは、階層リソースツリー内のセマンティック記述子に関するＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、およびＤＥＬＥＴＥ等のＲＥＳＴｆｕｌ動作は、他のリソースツリー内のリソースに対する動作に類似する。第２のオプションに関して、集中管理セマンティックグラフストア３６０内のセマンティックトリプルに関するＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、およびＤＥＬＥＴＥ等の動作は、集中管理アプローチに関して説明されるものに類似し、リソースツリー内の他のリソースに対する動作に類似する。

図３０は、リソースツリー内のセマンティック記述子を用いたセマンティッククエリのための例示的方法を図示する。ステップ３７５では、受信側３６１（例えば、ＳＥ３６１）は、セマンティックトリプルＲＥＴＲＩＥＶＥ動作のための要求を受信し得る。ステップ３７６では、ステップ３７５の要求に基づいて、受信側３６１は、セマンティックトリプルＲＥＴＲＩＥＶＥ動作を処理し得る。受信側３６１は、セマンティック記述子発見を実施し得る。受信側３６１は、リソースツリー内のセマンティックトリプルＲＥＴＲＩＥＶＥ動作を確証し得る。これは、各セマンティック記述子のための＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞によって規定されたアクセス制御ポリシルールに基づいて、発信側３７３がリソースツリー内で発見されたセマンティック記述子を読み出すための権利を有することを決定することを含み得る。加えて、ＦｉｌｔｅｒＣｒｉｔｅｒｉａが有効であるかどうか決定され得る。第１のオプションでは、ＲＥＴＲＩＥＶＥ動作の確証成功に基づいて、受信側３６１は、リソースツリー内で発見されセマンティック記述子を読み出し得る。受信側３６１は、ＲＥＴＲＩＥＶＥ動作の確証成功後、セマンティックトリプルのリストを用いてグラフ図を構築し得る。第１のオプションでは、受信側３６１は、読み出されるセマンティック記述子からセマンティックトリプルを抽出し、構築されたグラフ図とともに、それらをセマンティックグラフストア３６０の中に置き得る。受信側３６１は、要求内に提供されない場合、セマンティッククエリコマンドを構築し得る（例えば、ＳＰＡＲＱＬクエリ言語で）。受信側３６１は、セマンティックグラフストア内に構築された図において標的クエリセマンティックトリプルおよびＦｉｌｔｅｒＣｒｉｔｅｒｉａを用いてセマンティッククエリを実施し得る。

ステップ３７７では、受信側３６１は、メッセージ（例えば、応答）を構築し、ＡＥ３７３に送信し得る。「グラフ図を用いたアクセス制御」スキームが、図３０および本明細書の他の場所に例として示されるが、「＜ＡｃｃｅｓｓＣｏｎｔｒｏｌＴｒｉｐｌｅｓ＞を用いたアクセス制御」スキームも、第１のオプションまたは第２のオプションのために適用可能であり得ることに留意されたい。

分散型セマンティック記述子間の関係を可能にすることを可能にする代替アプローチが、本明細書において開示される。分散型記述をまたいだフィルタリングまたはクエリは、ｏｎｅＭ２Ｍにおける従来のセマンティックフィルタリング提案に関して本明細書に説明される他のアプローチの代替を提供する。セマンティック記述がＲＤＦトリプルフォーマットであっても、なくてもよいように、本明細書で議論される集中管理アプローチに行われる一般的仮定が適用されることに留意されたい。ここでは、セマンティックインスタンスによって作成されるグラフ全体に焦点が置かれ、したがって、トリプルの形態におけるセマンティックインスタンスの例示的使用が、開示される。用語「セマンティック記述子」または「セマンティックトリプル」（複数）は、任意のフォーマット（例えば、ＲＤＦ）におけるセマンティック記述のために使用され得る。単一文、例えば、ＲＤＦ−トリプルのための用語「セマンティックインスタンス」が、使用され得る。クエリは、例えば、ＳＰＡＲＱＬを介したＲＤＦトリプルのために例示され得る。

このアプローチにおいて対処される分散型アーキテクチャは、以下の特徴を有し得る。セマンティック記述子は、単一サービスエンティティ上の異なる階層リソースツリー上のリソースをまたいで位置し得る。いくつかのサービスエンティティをまたいだセマンティック動作のための要求は、個々のサービスエンティティにルーティングされる要求に分割され得、ここで対処されるセマンティック動作は、アドレスされるサービスエンティティ内に分散された記述子を標的化する。アプリケーションエンティティ（ＡＥ）、例えば、ｏｎｅＭ２ＭにおけるＡＥは、リソースツリー内のセマンティック記述子リソースに関するＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ等のＲＥＳＴｆｕｌ動作のために、インターフェースＡＳ、例えば、ｏｎｅＭ２ＭにおけるＭｃａインターフェースを介して、ＳＥと通信し得る。ＳＥは、リソースツリー内のセマンティック記述子リソースに関するＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ等のＲＥＳＴｆｕｌ動作のために、インターフェースＳＳ、例えば、ｏｎｅＭ２ＭにおけるＭｃｃまたはＭｃｃ’インターフェースを介して、別のＳＥと通信し得る。セマンティッククエリのために使用される一時的セマンティックグラフストアは、サービスエンティティ（ＳＥ）、例えば、ｏｎｅＭ２ＭにおけるＣＳＥ上に常駐し、階層リソースツリー内に分散されたセマンティック記述子から抽出されるセマンティックトリプルを含み得る。このアーキテクチャでは、ｏｎｅＭ２Ｍにおける従来のアクセス制御ポリシに関して説明されるようなセキュリティおよびプライバシの問題が、アクセス制御ポリシを介して解決され得ることに留意されたい。セマンティック記述子は、各ＣＲＵＤ動作に対してそれらにアクセスし得るエンティティをそれが決定するリソースレベルのポリシを有する。

重要な問題は、サービスエンティティ内で利用可能な可能性として大量のリソースのセマンティック記述子をクリエすることにあり得る。以下に議論されるもの等のいくつかの選択肢が存在する。第１の選択肢は、ＳＥツリー全体にわたって（例えば、リソースツリーのベース（例えば、ｏｎｅＭ２ＭにおけるＣＳＥＢａｓｅ）を標的化するかのように各クエリを処理する）、ＳＥ内の全てのセマンティック記述子が各クエリに関連するかのように、各クエリを処理することを含み得る。これは、非効率的検索方法と考えられ得る。第２の選択肢は、動作標的のセマンティック記述子を考慮して、各クエリを処理することを含み得る。ｏｎｅＭ２Ｍにおける従来のセマンティックフィルタリング提案に関して説明されるケースに対して。これは、＜ｄｅｖｉｃｅ１２＞に向けられるクエリが＜ｏｐｅｒａｔｉｏｎＸ＞において利用可能なセマンティック記述子情報を全く使用しないことにつながり得る。第３の選択肢は、本明細書で議論されるｏｎｅＭ２Ｍにおける従来のセマンティックフィルタリング提案に説明されるｒｅｓｏｕｒｃｅＤｅｓｃｒｉｐｔｉｏｎＬｉｎｋ方法を使用して、各クエリを処理することを含み得る。この場合、２つ以上の共通概念を含む２つの（またはそれを上回る）記述子が、同一２つの記述子間に確立されるいくつかのリンクにつながり得る。手続型記述に基づいて、新しいリンクが遭遇されるであろう度に、クエリ動作を処理するエンティティは、対応するセマンティック記述子（この場合、ｏｐｅｒａｔｉｏｎ Ｘ）をフェッチするであろう。これは、同一記述子の複数の読み出しをもたらすであろう。加えて、読み出しは、記述子コンテンツのセマンティック理解に基づいて処理され得る。第４の選択肢は、意味上関連する記述子の組にわたって各クエリを処理することを含み得る。組は、クエリ効率と正確度を引き換えにするであろうポリシに基づいて、より大きくまたはより小さくされ得る。以下に説明される方法は、このカテゴリに属する。それは、インスタンスまたは記述を置くべき場所（リソースツリーレベル）を把握しているので、セマンティックインスタンスまたはサブグラフとその他との関連に関する、注釈時に利用可能な知識を使用する利点を有する。

図３１は、従来行われるような同じ記述子間の複数のｒｅｓｏｕｒｃｅＤｅｓｃｒｉｐｔｉｏｎＬｉｎｋの問題を図示する。本開示では、関連コンテンツを伴うセマンティック記述子は、提供されるリンクがセマンティック記述子のセマンティックインスタンス内に埋め込まれた関連概念間にある、「ｏｎｅＭ２Ｍにおけるセマンティックフィルタリング提案」の節で議論されるようなソリューションとは対照的に、互いへのリンクを提供され得る。具体的には、関連セマンティック記述子へのリンクを提供するために、新しい属性（例えば、ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ）が、セマンティック記述子リソースに追加されることが開示される。

ｏｎｅＭ２Ｍコンテキストにおけるセマンティック記述子リソースの例を使用すると、ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性を図示する図３２に示されるように、属性ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓが、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースに追加される。

本明細書で議論されるリンクのリストおよびリンクのグループに関して説明されるようなｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性のために想定され得る複数の実装が存在する。第１の実装では、ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性は、関連セマンティック記述子への個々のリンクのリストを含み得る。第２の実装では、ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性は、グループを指し示す。このオプションに対して、＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースが、本明細書に開示されるが、しかしながら、汎用＜ｇｒｏｕｐ＞リソースも、この目的のために使用され得る。

このコンテキストでは、「関連」セマンティック記述子の概念が、以下の意味を有し得ることに留意されたい：セマンティッククエリの目的のために、より大きいグラフを形成するためにそれらが一緒に使用されるべき場合、２つ以上のセマンティック記述子が関連させられる。本明細書では、初期主語ベースのスキームに基づく第１の例と、恣意的グラフベースのスキームを使用する第２の例とが提供され、恣意的グラフベースのスキームは、関連セマンティック記述子を生成するためのスキーム、例えば、セマンティック記述子が関連させられることを決定し、対応するリンクを提供するためのスキームを提供する。本明細書に導入される記述子間リンクを提供する方法は、特定のステムが、２つ以上のセマンティック記述子が関連することを最終的に決定するアルゴリズムを実装するために選定する方法から独立して考慮され得ることに留意されたい。

ｏｎｅＭ２Ｍ分散型グラフの以下の例（同様に、本明細書で議論されるｏｎｅＭ２Ｍにおける従来のセマンティックフィルタリング提案に関連付けられる）が、以下で使用されるであろう。この例では、独立したリソース内に記憶されるグラフは、互いに関連する情報を含む：第１のグラフからのＯｐｅｒａｔｉｏｎＡは、第２の記述子にさらに記述され、関係ｅｘｐｏｓｅｓＣｏｍｍａｎｄおよび目的語ｃｏｍｍａｎｄＫが、両方内に含まれる。さらなるグラフ記述（第１のグラフ内の主語ｃｏｍｍａｎｄＫを伴い、リソースＯｐｅｒａｔｉｏｎＡ記述子に関連する追加の潜在的トリプル等）が、この場合、グラフ間の追加の依存性を作成し得る。

図３３は、異なるセマンティック記述子をまたいで分散される例示的グラフを図示する。ある例では、以下のフィルタ要求が存在し得る：「その出力が温度側面を定量化する動作を有するサービスを有する全てのデバイスを見つけ、出力＝ＯｕｔｐｕｔＸおよびコマンド＝ｃｏｍｍａｎｄＫを伴うそれらに対して、それをフィルタリングする」。

以下は、要求の対応するＳＰＡＲＱＬ表現である。
ＳＥＬＥＣＴ？ｄｅｖｉｃｅ
ＷＨＥＲＥ｛ ？ｄｅｖｉｃｅｒｄｆ：ｔｙｐｅｂａｓｅ：Ｄｅｖｉｃｅ．
？ｄｅｖｉｃｅｂａｓｅ：ｈａｓＳｅｒｖｉｃｅ？ｓｅｒｖｉｃｅ．
？ｓｅｒｖｉｃｅｂａｓｅ：ｈａｓＯｐｅｒａｔｉｏｎ？ｏｐｅｒａｔｉｏｎ．
？ｏｐｅｒａｔｉｏｎｂａｓｅ：ｈａｓＯｕｔｐｕｔ？ｏｕｔｐｕｔ．
？ｏｕｔｐｕｔｂａｓｅ：ｑｕａｎｔｉｆｉｅｓｔｅｍｐ：ＴｅｍｐｅｒａｔｕｒｅＡｓｐｅｃｔ．
？ｄｅｖｉｃｅｂａｓｅ：ｅｘｐｏｓｅｓＣｏｍｍａｎｄ？ｃｏｍｍａｎｄ．
ＦＩＬＴＥＲ（？ｏｕｔｐｕｔ＝＝ＯｕｔｐｕｔＸ＆＆？ｃｏｍｍａｎｄ＝＝ｃｏｍｍａｎｄＫ）
｝

目標は、図３４に示されるように、ＳＰＡＲＱＬクエリを評価するために提示されるべきより大きい結果として生じるグラフの作成を可能にすることである。

この実装では、ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性は、セマンティッククエリを行うために、所与の＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソース内の記述子とともに使用されるべき他のリソースに関連付けられた記述子を指し示すリンクのリストを含む。

図３５は、リンクのリストを伴うｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性の例示的使用である。これは、より限定数のセマンティック記述子が関連し、リンクリストを短くするときに提示されるもののようなケースにおいて有用である。このオプションをさらに簡略化するために、標準化ルールが、子リソースの全てのセマンティック記述子が、デフォルトで関連すると見なされことを規定し得ることが想定され得、それは、全ての子リソース記述子（存在する場合）が、クエリが親に向けられる場合、親に自動的に追加されるべきことを意味する。このように、親のｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性は、子の全ての記述子へのリンクを含む必要はない。

この実装では、ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性は、図３６におけるように、新しく開示されるリソース＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞を指し示すリンクを含む。ｓｅｍａｎｔｉｃＧｒｏｕｐＬｉｎｋｓは、セマンティッククエリを行うとき、一緒に使用されるべき記述子を識別するために使用される。個々のセマンティックリソースのｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性は、直接、＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソース、ｓｅｍａｎｔｉｃＧｒｏｕｐＬｉｎｋｓ属性のいずれかを指し示すか、または関連付けられたｓｅｍａｎｔｉｃＧｒｏｕｐＩＤを示し得る。上記例では、＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースは、合成グラフを＜Ｄｅｖｉｃｅ１２＞および＜動作Ａ＞リソースをまたいで分散させるときに形成され得る。このリソースに対して、ｓｅｍａｎｔｉｃＧｒｏｕｐＩＤ、例えば、５６が、配分され得、ｓｅｍａｎｔｉｃＧｒｏｕｐＬｉｎｋｓ属性は、関連セマンティック記述へのリンクのリストを含み得、例えば、リンクは、＜Ｄｅｖｉｃｅ１２＞および＜動作Ａ＞を指し示す。他の実装では、リンクは、代わりに、それぞれの＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースの記述子属性の各々に、または子＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソース自体を指し示し得る。図３７は、＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞を用いた例示的使用またはｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性である。

分散型セマンティック記述子間の関係リンクを生成および維持する。分散型セマンティック記述子アーキテクチャは、セマンティック技術を利用するプラットフォーム機能性の可用性に依拠し得る。これは、ＣＲＵＤ動作を使用してセマンティック記述子を提供するセマンティック対応プラットフォーム機能性が存在することを意味する。同様に、ＣＲＵＤ動作は、セマンティックインスタンスの更新を行うことを含む、これらの記述子を管理するために使用され得る。これらの注釈機能性の総合したものは、セマンティック注釈機能と見なされ得る。

リソースを生成する機能が、本明細書で議論され、リソースを生成する機能において、注釈機能性が、生成されたリソースが記憶されるべき場所、アクセス制御属性が設定されるべき方法等についてルールおよびポリシを有し得る。

以下は、関係維持スキームの例であり、それは、セマンティック記述子リンクの提案される方法が使用され得る方法を例示するために、注釈生成プロセスにおいて使用され得る。

前節における例は、リソース＜Ｄｅｖｉｃｅ１２＞および＜動作Ａ＞に注釈を付けるために、図３３に示されるように、図３４におけるより大きいグラフを使用したセマンティック注釈機能に依拠している。これは、グラフの処理の論理表現である。具体的実装では、このグラフの処理は、ローカル一時的または恒久的トリプルストアを利用し得る。これは、トリプルストアが、ローカルにあり、サービスエンティティ間で共有される必要がないので、本明細書で議論されるハイブリッドアプローチと異なり得る。

しかしながら、セマンティック注釈機能は、作成された種々のセマンティック記述子間にリンクを生成し、同時に、それがサブグラフおよび注釈を生成する、ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性を追加するためにも使用され得る。

以下の説明は、例として、ｏｎｅＭ２Ｍベースオントロジー（図８）を使用する。セマンティック注釈エンジンは、このオントロジーを使用して、ＲＤＦで表される図３４におけるグラフを作成する。示されるテキストは、記述子内の正確なＲＤＦシンタックスのためにフォーマットされておらず、むしろ、全体的グラフの概念表現であることに留意されたい。

初期主語ベースのスキームに基づく例が、以下に提供される。このスキームでは、各ｒｄｆ：記述は、対応するリソースのセマンティック記述子内に記憶され、故に、「主語ベースのスキーム」として指定される。このアプローチを用いて、その目的語が別のリソースであるトリプルを形成または更新するとき、注釈エンジンは、同様に、同じ＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソース内のｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性の中にエントリを作成する。

図３７の例示的グラフを使用すると、リソース＜Ｄｅｖｉｃｅ１２＞に関連付けられた＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞子リソースの記述子およびｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性は、図３９に示されるようになるであろう。この場合、グラフは、＜Ｄｅｖｉｃｅ１２＞、＜動作Ａ＞リソース、ならびに＜Ｓｅｒｖｉｃｅ２３＞および＜動作Ｘ＞をまたいで分散されることに留意されたい。最後の３つのリソースのための対応するＲＤＦは、対応する記述を隔離することによって、図３８から容易に抽出されることができる。

ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性を＜Ｄｅｖｉｃｅ１２＞の＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソース内に追加するためのリンクの方法リストを採用する場合、図４０に示されるような以下のリストが、生成されるであろう。図４０は、リンクの方法リストが使用されるときのｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性の例である。

リンクのグループ方法を採用する場合、＜Ｄｅｖｉｃｅ１２＞のｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒリソース内のｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性は、対応する＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースを指し示し得る。実際、＜Ｓｅｒｖｉｃｅ２３＞、＜動作Ａ＞、および＜ｏｕｔｐｕｔ＞のｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒリソース内のｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性は、同一対応する＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースを指し示す。＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソース内では、ｓｅｍａｎｔｉｃＧｒｏｕｐＬｉｎｋｓ属性は、図４１に示されるように、リンクのリストを含み得る。図４１は、リンクのグループ方法が使用されるときのｓｅｍａｎｔｉｃＧｒｏｕｐＬｉｎｋｓ属性の例である。

恣意的グラフベースのスキームを使用する例。恣意的グラフベースのスキームを使用することは、恣意的グラフがリソースのセマンティック記述子内に記憶されることを可能にし、それは、ｏｎｅＭ２Ｍ仕様における現在の仮定である。このアプローチは、全体的グラフの個々の部分が記憶されるべき場所の決定に関して、任意の論理が注釈エンジンの実装において使用されることを可能にする。

これは、分散型セマンティック記述子間の関係を可能にするための議論に関連付けられた例と大まかに関連付けられ、各＜Ｄｅｖｉｃｅ１２＞および＜動作Ａ＞内に記憶されるグラフは、２つのリソースと異なる主語を伴うトリプルを含む。しかしながら、この例では、各リソースは、それ自体の記述内のそれ自体に関連するトリプルを含み得、したがって、グラフ選択肢は、完全に恣意的ではないことに留意されたい。

この例に対して、図３８におけるＲＤＦで記述される合成グラフは、色、数、またはある他の機構を使用して、それぞれ、＜Ｄｅｖｉｃｅ１２＞および＜動作Ａ＞の記述子内に記憶されることが決定される情報を表し得る。括弧１０１におけるラインは、両場所内に記憶されるトリプルを示す。示されるテキストは、記述子内の正確なＲＤＦシンタックスのためにフォーマットされておらず、むしろ、全体的グラフならびに各記述子内に捕捉されたトリプルの概念表現であることに留意されたい。

この例では、リソース＜Ｄｅｖｉｃｅ１２＞および＜動作Ａ＞に関連付けられたセマンティック記述子は、図４２および図４３に示されるようになるであろう。図４２は、恣意的グラフベースのスキーム内の＜Ｄｅｖｉｃｅ１２＞のための例示的セマンティック注釈である。図４３は、恣意的グラフベースのスキーム内の例示的＜動作Ａ＞注釈である。

このケースにおいて、リンクの方法リストを採用する場合、＜Ｄｅｖｉｃｅ１２＞および＜動作Ａ＞のｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性は、互いを指し示すであろう。これは、セマンティッククエリが記述子のうちの１つにわたって行われるとき、その他も、クエリ目的のためにグラフを完成するために読み出されるべきであることを示すであろう。

リンクのグループ方法を採用する場合、＜Ｄｅｖｉｃｅ１２＞および＜動作Ａ＞の両方のｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性は、同一＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースを指し示し、ｓｅｍａｎｔｉｃＧｒｏｕｐＬｉｎｋｓ属性は、図４４に示されるリンクのリストを含むであろう。図４４は、リンクのグループ方法が使用されるときの例示的ｓｅｍａｎｔｉｃＧｒｏｕｐＬｉｎｋｓ属性である。

セマンティック記述子間の関係の維持は同様に、スキームを生成する注釈エンジンによって行われ、それは、同様に、記述子間の「関連」関係が確立された方法から独立する。ここでは、「主語ベースのスキーム」および「恣意的グラフベースのスキーム」等の例示的スキームが存在する。主語ベースのスキームに関し、同じ記述子内のトリプルは、同じ主語を有し、主語は、親リソースである。恣意的スキームでは、トリプルは、主語によってではなく、恣意的に記憶されることができる。

維持方法は、グループアプローチに対してより単純である。記述子が作成、更新、または削除され、それによって、関係が変化するとき、特に、関連記述子のより大きいグループに対して、主に、＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソース内で更新が生じるからである。対照的に、リンクのリスト実装における関係の維持は、いくつかの記述子のみが関連するときに最適である。

ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性によって接続されるいくつかのリソースをまたいで記憶されるセマンティック記述におけるセマンティックフィルタリングを可能にするために、＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースの使用にかかわらず、セマンティッククエリエンジンは、図４５のステップを使用し得る。図４５は、ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓアプローチを使用したセマンティッククエリのための例示的方法を図示する。ステップ３８１では、受信側１５２は、ｒｅｑｕｅｓｔパラメータを確証することによって、受信されたＲＥＴＲＩＥＶＥ要求を処理する（ステップ３８０）。このインスタンスでは、ステップ３８０から開始するＲＥＴＲＩＥＶＥ要求が、ここでは議論されるが、他のセマンティックリソース発見も、概して、適用可能である。ステップ３８２では、受信側１５２は、対応するフィールド内のアドレス指定されたリソースに関連付けられたセマンティック記述子を発見する。ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ自体は、ｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓと呼ばれる属性を有し得、それは、得るべき他の記述子を識別する。ステップ３８３では、受信側１５２は、発信側１５１がメッセージ標的（例えば、セマンティック記述子）のＲＥＴＲＩＥＶＥ権利を有することを検証し、次いで、記述子およびｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性を抽出する。メッセージ標的の権利が存在しない場合、対応するリターンコードが、生成される。セマンティック記述子のコンテンツは、ローカルに保存され得、それは、ドキュメントとして、またはローカルもしくは一時的グラフストア内にあり得る。ドキュメントは、図４２におけるように、セマンティック記述子の表現である。グラフストアは、図２５のようなものである。関連セマンティクスが、読み出されるべき他のセマンティック記述子のリスト（すなわち、組）を生成するために使用され得る。このリストは、直接、またはｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性によって指し示された＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースにアクセスすることによって、提供され得る。発信側１５１が、＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞にＲＥＴＲＩＥＶＥ権利を有していない場合、他の記述子は、集められない。

図４５を継続して参照すると、ステップ３８４では、受信側１５２は、前のステップにおいて生成された関連記述子のリストを使用し得る。受信側１５２は、アクセス制御ルールに従って、それぞれの記述子属性の各々のコンテンツを読み出す。アクセスされることが可能にされる場合、リンクされた＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースの記述子属性の各々のコンテンツが、ＳＰＡＲＱＬ要求が実行されているコンテンツに追加される。ＳＰＡＲＱＬ要求に従う完全または拡大コンテンツが、処理のためにＳＰＡＲＱＬエンジンに提供される。ステップ３８５では、受信側１５２は、提供されたセマンティッククエリコマンド（または他のセマンティックリソース発見）を結果として生じるグラフに対して実施する。ステップ３８６では、受信側１５２は、セマンティッククエリに対する応答を構成する。ステップ３８７では、ローカルグラフストアが使用されている場合、受信側は、ローカルルールおよびポリシに基づいて、生成されたグラフを維持または削除し得る。

セマンティックフィルタリングまたは発見のための開示されるアプローチの技術的効果は、以下を含み得る：１）要求されるセマンティック情報が、見出され得る。２）リソースベースのアクセス制御が、いくつかのインスタンスでは、より容易に施行され得る。情報が動作の実行時にアクセスされ、要求側のアクセス権が適用され得るからである。３）ＳＰＡＲＱＬエンジンによって処理されるべきコンテンツが、処理に先立って収集され、それは、外部の非ｏｎｅＭ２Ｍ規定セマンティッククエリエンジンの使用を可能にし得る。または、４）２つ以上の共通概念を含む記述子が、１つのみのリンクによってリンクされ、それは、重複コンテンツが要求処理のために考慮されることのより容易な回避を可能にし得る。

「分散型セマンティック記述子間の関係の有効化」に関連付けられた例を使用して、合成グラフ（図３４）が、上記のステップ（例えば、図４５）を使用して構築され、処理のために、ＳＰＡＲＱＬエンジンに提供される。ＳＰＡＲＱＬエンジンは、グラフを一時的に記憶するために、ローカルトリプルストアを使用し得、その場合、それは、ハイブリッドアプローチにつながり得る。

以下に議論されるのは、＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞に基づく例である。分散型セマンティック記述子の実装を前提として、以下に導入されるような拡張＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースが、記述子間の関係の維持だけではなく、それは、セマンティックフィルタリング動作のさらなる効率化も提供し得る。

図４６は、拡張＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースの例を図示する。拡張は、リソース＜ｓｅｍａｎｔｉｃＦａｎＯｕｔＰｏｉｎｔ＞の導入を含み、それは、仮想リソースであり、＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースが個々のリソースの代わりに、セマンティッククエリの標的となることを可能にし得る。これは、クエリ発信側（例えば、発信側１５１）が、前の発見に基づいて、リソースツリーの理解を有するとき、有用となる層を追加し得る。クエリを＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースの＜ｓｅｍａｎｔｉｃＦａｎＯｕｔＰｏｉｎｔ＞にアドレス指定することによって、技術的効果は、受信側１５２におけるセマンティックエンジンが、グループ全体に関連付けられた合成グラフをより容易に維持および検索し得る結果をもたらし得ることである。ローカルトリプルストアストレージ、キャッシュ等は、より高速結果のために、受信側におけるセマンティックエンジン内のクエリの処理をより効率的にさらにし得る。加えて、＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースは、異なるＳＥに属するリソースに対するクエリを標的化するために使用され得る。第１のＳＥ上に常駐する＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースが、第２のＳＥおよび第３のＳＥ上のメンバリソースを含む場合、ＲＥＴＲＩＥＶＥ動作は、第２のＳＥおよび第３のＳＥ上の対応するリソースにファンアウトされ得る。次いで、クエリは、上で説明されるように、個々のＳＥ内で処理され得る。

＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞リソースを使用するときの別の拡張は、セマンティック記述子内に含まれる各グラフのためのグラフ名の使用のための命令を提供することによって行われ得、例えば、作成された各セマンティック記述子は、名前が付けられ得、一意の名前が、それに割り当てられるべきである。加えて、グラフ名が記述子の場所に関連付けられることも提供され得る。命名は、階層であり得、それによって、グループ内の全てのグラフが一緒にアドレス指定され得るか、または、割り当てられた名前は、互いに独立し得る。いずれの場合も、新しい属性グループグラフ名が、リストまたはルート名のいずれかを介して、グループ内のグラフのための名前を提供するために使用され得る。

この方法の技術的効果は、それらを可能な限り具体的または広範にすることによって、セマンティック動作の発信側により優れた粒度を提供することであり得る。受信側では、セマンティックエンジンは、より効率的であり得、それによって、＜ｓｅｍａｎｔｉｃＦａｎＯｕｔＰｏｉｎｔ＞にアドレス指定されるがＳＰＡＲＱＬペイロードが特定のグラフを示すクエリ要求を受信する場合、エンジンは、グラフ名とｓｅｍａｎｔｉｃＧｒｏｕｐＬｉｎｋｓ内に提供されるリンクとの間の関係を使用して、所与のグラフに関連付けられた記述子のみにアドレスする。

図４に示されるｏｎｅＭ２Ｍアーキテクチャを想定すると、セマンティックグラフストアおよびセマンティック保管マネージャは、ＣＳＦセマンティック内に常駐し得、リソースツリーおよびデータ保管マネージャは、ＣＳＦデータ管理およびリポジトリ内に常駐し得る。図４７は、ｏｎｅＭ２Ｍを考慮したセマンティックグラフストアを伴う例示的アーキテクチャを図示する。図４８は、ｏｎｅＭ２Ｍを使用した開示される方法のための例示的リソースツリーを図示する。図４８に示されるように、新しいリソース＜ＳｅｍａｎｔｉｃＧｒａｐｈＳｔｏｒｅ＞が、＜ＣＳＥｂａｓｅ＞下に追加される。ある例では、異なるｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒリソースのｒｅｌａｔｅｄＳｅｍａｎｔｉｃｓ属性は、＜ｓｅｍａｎｔｉｃＧｒｏｕｐ＞を指し示し、関連する記述子を示し得る。それが行われると、グループのｓｅｍａｎｔｉｃＦａｎＯｕｔＰｏｉｎｔが、全ての関連記述子に関するセマンティック動作を送信するために使用され得る。

図５０は、本明細書で議論される方法およびシステムに基づいて生成され得る、例示的ディスプレイ（例えば、グラフィカルユーザインターフェース）を図示する。ディスプレイインターフェース９０１（例えば、タッチスクリーンディスプレイ）は、ブロック９０２に、本明細書に議論されるようなアクセス制御を用いたｅヘルスセマンティッククエリ等のセマンティックＩｏＴのためのＲＥＳＴｆｕｌ動作に関連付けられたテキストを提供し得る。別の例では、本明細書で議論されるステップのいずれかの進行度（例えば、送信されたメッセージまたはステップの成功）が、ブロック９０２に表示され得る。加えて、グラフィカル出力９０３が、ディスプレイインターフェース９０１上に表示され得る。グラフィカル出力９０３は、セマンティックグラフィックストアのトポロジ、本明細書で議論される任意の方法またはシステム（例えば、とりわけ、図１８−図２１）の進行度のグラフィカル出力等であり得る。図５３Ａから図５３Ｃは、ディスプレイインターフェース９０１上に存在し得る、出力を図示する。ダウンロードフォーマットを選定するためのオプションとともに、クエリ結果が存在し得る。示されるように、Ｓｖａｌｕｅ、Ｄｖａｌｕｅ、セマンティック記述子、およびサンプルが、例に提供され、対応する結果が、図５３Ａから図５３Ｃに示され得る。

図５１Ａは、セマンティックＩｏＴのためのＲＥＳＴｆｕｌ動作に関連付けられた１つ以上の開示される概念（例えば、図１６−図４９Ｃおよび図５４）が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であり得る。

図５１Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｆｉｂｅｒ、ＩＳＤＮ、ＰＬＣ等）または無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）、もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する複数のアクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。

図５１Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインとは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインとは、通常はＭ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含む。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイデバイス１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービスプラットフォーム２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。

図５１Ｂを参照すると、フィールドドメイン内に例証されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０（例えば、ｅヘルスケアアプリ）、Ｍ２Ｍゲートウェイデバイス１４、ならびにＭ２Ｍ端末デバイス１８および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービスプラットフォーム２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。

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

図５１Ｂをさらに参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用することができるサービス配信能力のコア組を提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。

いくつかの例では、Ｍ２Ｍアプリケーション２０および２０’は、本明細書に議論されるようなセマンティックＩｏＴのためのＲＥＳＴｆｕｌ動作を使用して通信する所望のアプリケーションを含み得る。Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、システムのデバイス、ゲートウェイ、および他のサーバを経由して作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

本願のセマンティックＩｏＴのためのＲＥＳＴｆｕｌ動作は、サービス層の一部として実装され得る。サービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。Ｍ２Ｍエンティティ（例えば、ハードウェアおよびソフトウェアの組み合わせによって実装され得るデバイス、ゲートウェイ、またはサービス／プラットフォーム等のＭ２Ｍ機能エンティティ）は、アプリケーションまたはサービスを提供し得る。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、本願のセマンティックＩｏＴのためのＲＥＳＴｆｕｌ動作を含み得るサービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上でホストすることができる共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願のセマンティックＩｏＴのためのＲＥＳＴｆｕｌ動作は、本願のセマンティックＩｏＴのためのＲＥＳＴｆｕｌ動作等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

本明細書に議論されるように、サービス層は、ネットワークサービスアーキテクチャ内の機能的層であり得る。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰ、またはＭＱＴＴ等のアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層はまた、インターフェースを、例えば、制御層およびトランスポート／アクセス層等の下位リソース層におけるコアネットワークに提供する。サービス層は、サービス定義、サービスランタイム有効化、ポリシ管理、アクセス制御、およびサービスクラスタリングを含む（サービス）能力または機能性の複数のカテゴリをサポートする。最近、いくつかの産業規格団体、例えば、ｏｎｅＭ２Ｍが、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開へのＭ２Ｍタイプのデバイスならびにアプリケーションの統合に関連付けられた課題に対処するためのＭ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、アプリケーションおよび／または種々のデバイスに、ＣＳＥもしくはＳＣＬと称され得るサービス層によってサポートされる前述の能力または機能性の集合もしくは組へのアクセスを提供することができる。いくつかの例として、限定ではないが、種々のアプリケーションによって一般に使用され得るセキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理が挙げられる。これらの能力または機能性は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、そのような種々のアプリケーションに利用可能となる。ＣＳＥまたはＳＣＬは、それらにそのような能力もしくは機能性を使用するために、ハードウェアおよび／もしくはソフトウェアによって実装され得、種々のアプリケーションならびに／もしくはデバイスにエクスポーズされる（サービス）能力または機能性を提供する、機能エンティティ（すなわち、そのような機能エンティティ間の機能インターフェース）である。

図５１Ｃは、例えば、Ｍ２Ｍ端末デバイス１８（例えば、ＡＥ３６７、ＡＥ３３５、または発信側１５１）またはＭ２Ｍゲートウェイデバイス１４４（例えば、ＳＥ３６１または受信側１５２）等の例示的Ｍ２Ｍデバイス３０の系統図である。図５１Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、開示される主題と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。Ｍ２Ｍデバイス３０（例えば、サービスエンティティ１６３、図２２の受信側および図２２の発信側１６１、図４７のＭＮ−ＣＳＥ、図２９のアプリケーションエンティティ３７３、図４７のＩＮ−ＣＳＥ、およびその他）は、セマンティックＩｏＴのためのＲＥＳＴｆｕｌ動作のための開示されるシステムおよび方法を行う、例示的実装であり得る。

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍデバイス３０が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、伝送／受信要素３６に結合され得る送受信機３４に結合され得る。図５１Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップに一緒に組み込まれ得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムおよび／または通信を実施し得る。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、および／または暗号化動作等のセキュリティ動作を実施し得る。

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

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

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、Ｍ２Ｍデバイス３０は、マルチモード能力を有し得る。したがって、送受信機３４は、Ｍ２Ｍデバイス３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、サブスクライバ識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の例では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、本明細書に説明される例のうちのいくつかにおけるステップが成功もしくは不成功である（例えば、セマンティックｔｒｉｐｌｅＣＲＥＡＴＥ動作要求またはセマンティックｔｒｉｐｌｅＲＥＴＲＩＥＶＥ動作要求等）に応答して、ディスプレイもしくはインジケータ４２上の照明パターン、画像、または色を制御する、または別様に、本明細書に議論される、セマンティックＩｏＴのためのＲＥＳＴｆｕｌ動作のステータスおよび関連付けられたコンポーネントを示すように構成され得る。ディスプレイまたはインジケータ４２上の照明パターン、画像、もしくは色の制御は、図に図示される、または本明細書で議論される（例えば、図１６−図４９Ｃおよび図５２−図５４ならびに本明細書の同等物）方法フローもしくはコンポーネントのいずれかのステータスを反映し得る。本明細書に開示されるのは、セマンティックＩｏＴのためのＲＥＳＴｆｕｌ動作のメッセージおよびプロシージャである。メッセージおよびプロシージャは、インターフェース／ＡＰＩを提供するように拡張され、ユーザが、入力ソース（例えば、スピーカ／マイクロホン３８、キーパッド４０、またはディスプレイ／タッチパッド４２）を介して、リソース関連リソースを要求し、とりわけ、ディスプレイ４２上に表示され得る、セマンティックＩｏＴのためのＲＥＳＴｆｕｌ動作を要求、構成、またはクエリすることができる。

プロセッサ３２は、電源４８から電力を受け取り得、Ｍ２Ｍデバイス３０内の他のコンポーネントへの電力を分配および／または制御するように構成され得る。電源４８は、Ｍ２Ｍデバイス３０に電力供給するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

プロセッサ３２はまた、Ｍ２Ｍデバイス３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成されるＧＰＳチップセット５０に結合され得る。Ｍ２Ｍデバイス３０は、本明細書に開示される情報と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。

プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線接続を提供する１つ以上のソフトウェアおよび／またはハードウェアモジュールを含み得る他の周辺機器５２に結合され得る。例えば、周辺機器５２は、種々のセンサ、例えば、加速度計、バイオメトリック（例えば、指紋）センサ、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、または他の相互接続インターフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）(R)モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。

伝送／受信要素３６は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはｅ−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の他の装置もしくはデバイスで具現化され得る。伝送／受信要素３６は、周辺機器５２のうちの１つを備え得る相互接続インターフェース等の１つ以上の相互接続インターフェースを介して、そのような装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続し得る。

図５１Ｄは、例えば、図５１Ａおよび図５１ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る例示的なコンピューティングシステム９０のブロック図である。コンピューティングシステム９０（例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４）は、コンピュータまたはサーバを備え得、主に、そのようなソフトウェアが記憶またはアクセスされる場所もしくは手段にかかわらず、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を起動させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なるプロセッサである。ＣＰＵ９１またはコプロセッサ８１は、図１８のステップ２０２におけるようなＣＲＥＡＴＥに対する要求の処理等のセマンティックＩｏＴのためのＲＥＳＴｆｕｌ動作のための開示されたシステムおよび方法に関係付けられるデータを受信、生成、ならびに処理し得る。

動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピューティングシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびに割込を送信するため、およびシステムバスを動作するための制御ラインを含む。そのようなシステムバス８０の例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。

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

加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ８３を含み得る。

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる電子コンポーネントを含む。

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

本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、命令が、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイス等のマシンによって実行されると、本明細書で説明されるシステム、方法、およびプロセスを行うおよび／または実装される、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得ることが理解される。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。本明細書の説明から明白なように、記憶媒体は、米国特許法第１０１条（３５Ｕ．Ｓ．Ｃ．§１０１）の法的保護対象と解釈されるべきである。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理的媒体を含む。

図に例証されるように、本開示の主題（セマンティックＩｏＴのためのＲＥＳＴｆｕｌ動作）の好ましい方法、システム、または装置を説明する際に、明確にするために、特有の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法をもたらすように、単独で、または相互と組み合わせて動作し得る。本明細書で使用されるように、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」または同等物は、同義的に使用され得る。加えて、単語「または」の使用は、概して、本明細書に別様に提供されない限り、包含的に使用される。

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

Claims (13)

1. 装置であって、
   プロセッサと、
   前記プロセッサと結合されたメモリと
   を備え、
   前記メモリは、実行可能命令を含み、前記命令は、前記プロセッサによって実行されると、
   セマンティック発見のためのメッセージを受信することであって、前記メッセージの標的リソースは、仮想ファンアウトリソースを備え、前記仮想ファンアウトリソースは、グループリソースの子リソースである、ことと、
   前記メッセージに基づいて、前記グループリソースのメンバリソースのセマンティック記述子の属性からコンテンツを読み出すことであって、複数の前記メンバリソースは、通信ネットワークの複数の共通サービスエンティティにわたって分散される、ことと、
   前記読み出されたコンテンツに基づいてセマンティックグラフを生成することと、
   前記セマンティックグラフ上にセマンティック発見を実施するための命令を提供することと
   を含む動作を前記プロセッサにもたらさせる、装置。
2. 前記動作は、前記生成されたセマンティックグラフを一時的グラフストア内に保存することをさらに含む、請求項１に記載の装置。
3. 前記動作は、前記セマンティックグラフに対して名前を割り当てることをさらに含む、請求項１に記載の装置。
4. 前記動作は、前記セマンティックグラフに対して名前を割り当てることをさらに含み、前記セマンティックグラフの名前は、前記セマンティック記述子の第１のセマンティック記述子の場所に関連付けられる、請求項１に記載の装置。
5. 前記動作は、前記セマンティックグラフに対して階層名前を割り当てることをさらに含む、請求項１に記載の装置。
6. 前記動作は、
   前記セマンティックグラフに対して名前を割り当てることと、
   前記名前を、グループ内のセマンティックグラフに名前を提供するために使用される属性に挿入することと
   をさらに含む、請求項１に記載の装置。
7. 複数の共通サービスエンティティを含むシステムにおけるプロセッサが実行する情報処理方法であって、
   セマンティック発見のためのメッセージを受信することであって、前記メッセージの標的リソースは、仮想ファンアウトリソースであり、前記仮想ファンアウトリソースは、グループリソースの子リソースである、ことと、
   前記メッセージに基づいて、前記グループリソースのメンバリソースのセマンティック記述子のコンテンツを読み出すことであって、複数の前記メンバリソースは、複数の共通サービスエンティティにわたって分散される、ことと、
   前記読み出されたコンテンツに基づいてセマンティックグラフを生成することと、
   前記セマンティックグラフ上にセマンティック発見を実施するための命令を提供することと
   を含む、情報処理方法。
8. 前記生成されたセマンティックグラフを一時的グラフストア内に保存することをさらに含む、請求項７に記載の情報処理方法。
9. 前記セマンティックグラフに対して名前を割り当てることをさらに含む、請求項７に記載の情報処理方法。
10. 前記セマンティックグラフに対して名前を割り当てることをさらに含み、前記セマンティックグラフの名前は、前記セマンティック記述子の第１のセマンティック記述子の場所に関連付けられる、請求項７に記載の情報処理方法。
11. 前記セマンティックグラフに対して階層名前を割り当てることをさらに含む、請求項７に記載の情報処理方法。
12. 前記セマンティックグラフに対して名前を割り当てることと、
    前記名前を、グループ内のセマンティックグラフに名前を提供するために使用される属性に挿入することと
    をさらに含む、請求項７に記載の情報処理方法。
13. その中に記憶されたコンピュータプログラムを有するコンピュータ読み取り可能なストレージ媒体であって、前記コンピュータプログラムは、データ処理ユニットの中にロード可能であり、前記コンピュータプログラムは、前記コンピュータプログラムが前記データ処理ユニットによって起動されると、請求項７〜１２のいずれか１項に記載の方法ステップを前記データ処理ユニットに実行させるように適合されている、コンピュータ読み取り可能なストレージ媒体。