(関連出願の引用)
本願は、米国仮特許出願第62/249,112号(2015年10月30日出願、名称「Restful Operations For Semantic IOT」)および米国仮特許出願第62/252,940号(2015年11月9日出願、名称「Restful Operations For Semantic IOT」)の利益を主張する。上記出願の各々の内容は、それらの全体が参照により本明細書に引用される。
(背景)
(セマンティックウェブ)
セマンティックウェブは、ワールドワイドウェブコンソーシアム(W3C)による規格を通したウェブの拡張である。この規格は、ウェブ上での共通データフォーマットおよび交換プロトコル、最も基本には、リソース記述フレームワーク(RDF)を促進する。セマンティックウェブは、データのために特に設計された言語:リソース記述フレームワーク(RDF)、ウェブオントロジー言語(OWL)、および拡張マークアップ言語(XML)でパブリッシュすることを伴う。これらの技術は、リンクされたデータのウェブを介してウェブドキュメントのコンテンツを補足または置換する記述を提供するために組み合わせられる。したがって、コンテンツは、ウェブアクセス可能データベース内に記憶される記述データとして、またはドキュメント内のマークアップ、特に、XMLが点在する拡張HTML(XHTML)、もしくはより多くの場合、単純にXMLにおけるドキュメント内のマークアップとして現れ得、レイアウトまたはレンダリングキューは、別個に記憶される。
(セマンティックウェブスタック)
セマンティックウェブスタック(Description of W3C Technology Stack Illustration,http://www.w3.org/Consortium/techstack−desc.html参照)は、図1に示されるように、W3Cによって規定されたセマンティックウェブのアーキテクチャを例証する。コンポーネントの機能および関係は、以下のように要約されることができる。
XMLは、ドキュメント内のコンテンツ構造のための基本的シンタックスを提供するが、セマンティクスをドキュメント内に含まれるコンテンツの意味に関連付けしない。XMLは、現在、タートル等の代替シンタックスが存在するので、大抵の場合、セマンティックウェブ技術の必要コンポーネントではない。タートルは、事実上標準的であるが、正式な標準化プロセスを経ていない。
XMLスキーマは、XMLドキュメント内に含まれる要素の構造およびコンテンツを提供および制限するための言語である。
W3C技術スタック例証のRDF記述は、データモデルを表すための言語であり、データモデルは、主語−述語−目的語、例えば、S−P−OトリプルまたはRDFトリプルの形態でオブジェクト(「ウェブリソース」)およびその関係を参照する。RDFベースのモデルは、種々のシンタックス、例えば、RDF/XML、N3、タートル、およびRDFで表されることができる。RDFは、セマンティックウェブの基本規格である。
RDFスキーマは、RDFを拡張し、RDFスキーマは、プロパティおよびクラスの一般化された階層のためのセマンティクスを用いてそのようなRDFベースのリソースのプロパティおよびクラスを記述するための語彙である。
OWLは、プロパティおよびクラス:とりわけ、クラス間の関係(例えば、離接)、基数(例えば、「正確に1つ」)、相等性、より豊富なタイプのプロパティ、プロパティの特性(例えば、対称)、およびリストアップされたクラスを記述するために、より多くの語彙を追加する。
SPARQLは、ウェブ上またはRDFストア(例えば、セマンティックグラフストア)においてRDFグラフコンテンツ(例えば、RDFトリプル)をクエリおよび操作するための、セマンティックウェブデータソースのためのプロトコルおよびクエリ言語である。
SPARQL1.1クエリは、RDFグラフのためのクエリ言語であり、データがRDFとしてネイティブに記憶されているか、またはミドルウェアを介してRDFとして見なされるかにかかわらず、多様なデータソースにわたるクエリを表すために使用されることができる。SPARQLは、その連言および選言とともに、必要とされるグラフパターン、および随意のグラフパターンをクエリするための能力を含む。SPARQLは、集約、サブクエリ、否定、表現による値の作成、拡張値試験、およびソースRDFグラフによるクエリの制約もサポートする。SPARQLクエリの結果は、結果組またはRDFグラフであり得る。
SPARQL1.1更新は、RDFグラフのための更新言語である。それは、RDFのためにSPARQLクエリ言語由来のシンタックスを使用する。更新動作は、セマンティックグラフストアにおけるグラフの集合に対して行われる。動作は、セマンティックグラフストア内のRDFグラフを更新、作成、および除去するために提供される。
RIFは、W3Cルールインターチェンジフォーマットである。それは、コンピュータが実行し得る、ウェブルールを表すためのXML言語である。RIFは、ダイアレクトと呼ばれる複数のバージョンを提供する。それは、RIF基本論理ダイアレクト(RIF−BLD)およびRIF生成ルールダイアレクト(RIF PRD)を含む。
(セマンティック検索およびセマンティッククエリ)
関係データベースは、暗示的様式のみにおいて、データ間の全ての関係を含む。例えば、顧客と製品との間の関係(2つのコンテンツテーブル内に記憶され、追加のリンクテーブルと接続される)は、開発者によって書き込まれるクエリ文(例えば、SQLが、関係データベースの場合に使用される)においてのみ発生する。クエリを書き込むことは、データベーススキーマの正確な知識を要求する。多くの関係データベースは、データがツリー状構造の中に編成される階層データベースにおけるようにモデル化される。データは、リンクを通して互いに接続される記録として記憶される。階層データベースモデルにおける記録は、関係データベースモデルにおける行(またはタプル)に対応し、エンティティタイプは、テーブル(または関係−親および子)に対応する。記録の検索またはクエリは、SQLまたは非SQL検索エンジンによって実施され得る。
図2に示されるように、従来の階層データベースモデルは、各子記録が、1つのみの親を有する一方、各親記録が、1つ以上の子記録を有し得ることを要求する。データを階層データベースから読み出すために、ツリー全体がルートノードから開始してトラバースされる必要がある。この構造は、単純であるが、関係が1対多の関係に制限されるので、非柔軟である。
リンクされたデータは、明示的様式でデータ間の全ての関係を含む。関係データベースにおいて説明される前述の例では、クエリコードは、書き込まれる必要がない。各顧客のための正しい製品が、自動的にフェッチされることができる。この単純例は、ささいなものであるが、リンクされたデータの真の力は、情報のネットワーク(都市、州、および国のようなそれらのジオスペース情報を伴う顧客、サブおよびスーパーカテゴリ内のそれらのカテゴリを伴う製品)が作成されるとき、有用になる。ここで、システムは、特定の場所の製品カテゴリとの接続を探すより複雑なクエリおよび分析に自動的に回答することができる。このクエリのための開発努力は、省略される。セマンティッククエリの実行は、情報のネットワークをウォーキングし、一致を見出すことによって実施される(データグラフトラバーサルとも呼ばれる)。
セマンティック検索は、検索者の意図と、(ウェブ上か、閉鎖されたシステム内かにかかわらず)用語が検索可能データ空間内に現れるにつれての用語の文脈的意味とを理解し、より関連のある結果を生成することによって、検索正確度を改良しようとする。セマンティック検索システムは、検索のコンテキスト、場所、意図、ならびに単語、同義語、一般化されたおよび特殊クエリ、概念一致、および自然言語クエリの変形例を含む種々の点を考慮し、関連検索結果を提供する。GoogleおよびBingのような主要なウェブ検索エンジンは、セマンティック検索のいくつかの要素を組み込む。セマンティック検索は、セマンティクス、すなわち、言語における意味の科学を使用して、高度に関連した検索結果を生成する。大抵の場合、目標は、ユーザに大まかに関連するキーワード結果のリストを分類せるのではなく、ユーザによってクエリされる情報をもたらすことである。例えば、セマンティクスは、階層関係データベース内の記録検索またはクエリを強化するために使用され得る。
セマンティッククエリは、連想的および文脈的性質のクエリおよび分析を可能にする。セマンティッククエリは、データ内に含まれるシンタックスの情報、セマンティック情報、および構造情報に基づいて、明示的に導出される情報および暗示的に導出される情報の両方の読み出しを可能にする。それらは、精密な結果(おそらく、1つの単一情報の独特の選択)をもたらすように、またはパターン照合およびデジタル推論を通してよりファジーかつ広く開いた質問に回答するように設計される。
セマンティッククエリは、名前が付けられたグラフ、リンクされたデータ、またはトリプルに取り組む。これは、クエリが、情報間の実際の関係を処理し、データのネットワークからの回答を推測することを可能にする。これは、セマンティック検索とは対照的であり、セマンティック検索は、セマンティック(意味の科学)を非構造化されたテキストにおいて使用し、より良好な検索結果を生成する(例えば、自然言語処理)。
技術的観点から、セマンティッククエリは、データベースクエリとよく似た精密な関係タイプ動作である。それらは、構造化されたデータに取り組み、したがって、演算子(例えば、>、<、および=)、名前空間、パターン照合、サブクラス化、遷移関係、セマンティックルール、およびコンテキストフルテキスト検索のような包括的特徴を利用する可能性を有する。W3Cのセマンティックウェブ技術スタックは、セマンティッククエリをSQLに類似するシンタックスで公式化するためのSPARQLを提供する。セマンティッククエリは、トリプルストア、グラフデータベース、セマンティックウィキ、自然言語、および人工知能システムにおいて使用される。
セマンティッククエリの別の側面は、関係のタイプが知能をシステムの中に組み込むために使用されることができることである。顧客と製品との間の関係は、近隣とその都市との間の関係と基本的に異なる性質を有する。後者は、セマンティッククエリエンジンが、Manhattanに住んでいる顧客がNew York Cityにも住んでいることを推測することを可能にする一方、他の関係は、より複雑なパターンおよび「コンテキスト分析」を有し得る。このプロセスは、推測または推論と呼ばれ、所与の事実に基づいて新しい情報を導出するためのソフトウェアの能力である。
(セマンティックモノのインターネット(IoT))
世界中に展開されるネットワーク接続デバイスおよびセンサの数の高速増加は、情報通信ネットワーク、および種々のドメインにおけるサービスまたはアプリケーションを変化させている。次の10年以内に、数十億のデバイスが、スマートグリッド、スマートホーム、ヘルスケア、自動車、交通、物流、および環境監視等の種々のエリアにおける多くのアプリケーションおよびサービスのための大量の実世界データを生成するであろうことが予測される。モノのインターネット(IoT)は、実世界データおよびサービスを現在の情報ネットワーキングの中に統合することを可能にする。
種々の物理的、サイバー、およびソーシャルリソースからのデータの統合は、状況およびコンテキストアウェアネスを意思決定機構の中に組み込むことができ、かつよりスマートなアプリケーションおよび強化されたサービスを作成することができるアプリケーションおよびサービスを開発することを可能にする。大量の分散型および異種IoTデータに対処することにおいて、相互運用性、自動化、およびデータ分析に関連する問題は、一般的記述およびデータ表現フレームワーク、ならびにマシン読み取り可能およびマシン解釈可能データ記述と共に使用される。セマンティック技術をIoTに適用することは、種々のリソース、データプロバイダ、および消費者間の相互運用性を促進し、効果的データアクセスおよび統合、リソース発見、セマンティック推論、および知識抽出を促進する。セマンティック注釈は、IoT内の種々のリソースに適用されることができる。オントロジー、セマンティック注釈、リンクされたデータ、およびセマンティックウェブサービス等のセマンティックウェブにおいて開発された一連の技術は、IoTを実現するための主要ソリューションとして使用されることができる。
しかしながら、セマンティック技術を実世界データに効果的に適用するために考慮されるべき特殊な設計考慮を要求するIoTの従来の構成に基づくいくつかの課題が存在する。課題は、動的性および複雑性、スケーラビリティ、分散型データストレージおよびクエリ、データの品質/信用/信頼性、セキュリティおよびプライバシ、またはデータの解釈および知覚を含み得る。動的性および複雑性に関して、実世界データは、より過渡的であり、主に、時間および場所依存である。下層環境の広汎性および変動的性は、記述の連続更新および監視を要求する。スケーラビリティに関して、IoTデータは、実世界における異なる現象を参照する。したがって、データを伴うセマンティック記述および注釈は、異なるおよび動的実世界状況にスケーラブルであるように、実世界リソースおよびエンティティのドメイン知識に関連付けられる必要がある。大量のデータおよびセマンティック記述を伴う分散型データストレージ/クエリに関して、ストレージおよびデータハンドリング機構の効率は、特に、関わるスケールおよび動的性を考慮すると、有意な課題となる。データの品質、信用、および信頼性に関して、IoTデータは、IoTデータ内の不正確度および可変品質に対する懸念を提供する異なる感覚デバイスによって提供される。セキュリティおよびプライバシに関して、IoTデータは、多くの場合、個人的である。データのセキュリティおよびプライバシを提供および保証する機構は、IoT内の有意な問題であり得る。最後に、データの解釈および知覚に関して、マシン読み取り可能かつ解釈可能フォーマットで提供されるセマンティック記述および背景知識は、マシンおよび人感センサによって作成された膨大な量の未加工観察を人間または自動化された意思決定プロセスに有意義なより高いレベルの抽象的概念に変換することをサポートする。しかしながら、IoTにおけるマシン知覚は、異なるソースからのデータの統合および融合、オブジェクトおよびイベントの記述、データ集約および融合ルール、閾値の定義、大規模なデータストリームのリアルタイム処理、ならびに品質および動的性問題等の追加の課題を従来のAI方法がこれまで解決を試みていた問題に追加する。
(oneM2Mアーキテクチャ)
開発中のoneM2M規格(参照することによってその全体として組み込まれる、oneM2M−TS−0001 oneM2M Functional Architecture−V2.3.0参照)は、「共通サービスエンティティ(CSE)」と呼ばれるサービス層を定義する。サービス層の目的は、異なる「バーティカル」M2Mシステムおよびアプリケーションによって利用され得る「ホリゾンタル」サービスを提供することである。
CSEは、図3に示されるように、4つの参照点をサポートする。Mca参照点は、アプリケーションエンティティ(AE)とインターフェースをとる。Mcc参照点は、同一サービスプロバイダドメイン内の別のCSEとインターフェースをとり、Mcc’参照点は、異なるサービスプロバイダドメイン内の別のCSEとインターフェースをとる。Mcn参照点は、下層ネットワークサービスエンティティ(NSE)とインターフェースをとる。NSEは、デバイス管理、場所サービス、およびデバイストリガ等の下層ネットワークサービスをCSEに提供する。
CSEは、「発見」、「データ管理およびリポジトリ」等の「共通サービス機能(CSF)」と呼ばれる、複数の論理機能を含む。図4は、oneM2Mにおける開発中のCSFを図示する。
oneM2Mアーキテクチャは、図3に示されるように、以下のタイプのノード、すなわち、アプリケーションサービスノード(ASN)、アプリケーション専用ノード(ADN)、中間ノード(MN)、インフラストラクチャノード(IN)、および非oneM2Mノード(NoDN)を可能にする。ASNは、1つのCSEを含み、少なくとも1つのアプリケーションエンティティ(AE)を含むノードである。例えば、物理的マッピングに関して、ASNは、M2Mデバイス内に常駐し得る。ADNは、少なくとも1つのAEを含むが、CSEを含まないノードである。ゼロ以上のADNが、oneM2Mシステムのフィールドドメイン内に存在し得る。例えば、物理的マッピングに関して、ADNは、制約付きM2Mデバイス内に常駐し得る。MNは、1つのCSEを含み、ゼロ以上のAEを含むノードである。ゼロ以上のMNが、oneM2Mシステムのフィールドドメイン内に存在し得る。例えば、物理的マッピングに関して、MNは、M2Mゲートウェイ内に常駐し得る。INは、1つのCSEを含み、ゼロ以上のAEを含むノードである。INは、oneM2Mサービスプロバイダごとにインフラストラクチャドメイン内に存在する。IN内のCSEは、他のノードタイプに適用可能ではないCSE機能を含み得る。例えば、物理的マッピングに関して、INは、M2Mサービスインフラストラクチャ内に常駐し得る。非oneM2Mノードは、oneM2Mエンティティ(AEまたはCSEのいずれでもない)を含まないノードである。そのようなノードは、管理を含む、インターワーキング目的のために、oneM2Mシステムにアタッチされたデバイスを表す。
oneM2Mシステム内でサポートされる種々のエンティティを相互接続する可能な構成は、図5に図示される。
(oneM2Mアーキテクチャにおけるセマンティック記述)
<semanticDescriptor>リソースは、リソースおよび潜在的にサブリソースに関するセマンティック記述を記憶するために使用される。そのような記述は、オントロジーに従って提供され得る。セマンティック情報は、oneM2Mシステムのセマンティック機能性によって使用され、アプリケーションまたはCSEにも利用可能である。
従来、<semanticDescriptor>リソースは、表1に規定される属性を含むものとする。図6は、リソースツリー内の<semanticDescriptor>リソースの構造を図示する。
(oneM2Mにおけるセマンティックフィルタリング提案)
一般フィルタリングが、要求動作に規定されたフィルタ基準を有することによってサポートされる(oneM2M−TS−0001 oneM2M Functional Architecture−V2.3.0第8.1.2節)。セマンティックフィルタリングを提供するために、要求動作フィルタ基準のための追加の値が提案されており、定義は、以下の表2に示される。複数のインスタンスが、使用され得、それは、フィルタ基準を評価するための一般的ルールに従い、「OR」セマンティクスが適用され、例えば、セマンティックフィルタのうちの1つ以上のものがセマンティック記述に一致する場合、セマンティックフィルタ基準のための全体的結果が真であることを意味する。
上記の提案は、以下の仮定を使用する:セマンティック記述は、RDFトリプル(表現、例えば、RDF/XML、タートル、oneM2M内にまだ完全に規定されていない記述フォーマット)として規定される;セマンティックフィルタ基準は、セマンティック記述に対して実行されるべきSPARQL要求のために使用されるであろう。
ある場合、単一検索のための関連セマンティック情報は、異なる<semanticDescriptor>リソース間に分散され得る。図7に提供される例は、このケースを図示する。主語−述語−目的語関係を表すセマンティックグラフが示されており、このグラフの異なる部分(卵形によって表される)は、異なる<semanticDescriptor>リソース内に記憶されている。セマンティックフィルタリングは、完全なセマンティックグラフ(その一部)に適用される必要があり、それは、グラフのいくつかの異なる部分がセマンティック動作の実行のために一緒に置かれる必要があるという問題を生じさせる。
この問題は、概して、クラスインスタンスを識別するURIが、直接、デリファレンスされ得、したがって、概念(例えば、クラス、関係)情報は、そのURIに基づいて見出され得るので、セマンティックウェブの領域ではよく分からない。oneM2Mケースでは、アクセスされ得るリソース、およびセマンティクスのみが、リソースコンテンツとして記憶される。この場合、セマンティックインスタンスは、第1のクラスのシチズンではないので、URIベースのアプローチは、oneM2Mケースでは適用可能ではない。
従来のSPARQL1.1は、サービスキーワードを使用して、連合クエリをサポートし、遠隔SPARQLエンドポイントのURLが、規定され得る。このアプローチに関して、要求側がどのセマンティック記述子が検索のために要求されるセマンティックインスタンスを含むかを先験的に把握しているであろうと想定されており、それは、セマンティック記述子がリソースツリー内に分散されている場合、このアプローチを概して適用不可能にするであろう。
oneM2Mに提示されるように、<semanticDescriptor>リソースをまたいで記憶されているセマンティック記述に対してセマンティックフィルタリングを可能にするためのソリューションは、resourceDescriptorLink OWL注釈プロパティの形態で注釈リンクを導入する。この注釈プロパティは、任意のクラスインスタンスのために規定されることができ、その値は、<semanticDescriptor>リソースのURLであり、所与のクラスインスタンスのための追加のRDFトリプルが、見出され得る。以下の例は、図9におけるグラフを作成するために、oneM2Mベースオントロジー(図8)内に定義されたクラスおよび関係を使用する。
このソリューションは、受信側におけるSPARQLベースのセマンティックフィルタリングエンジンのための以下の機能フローを伴う。第1に、SPARQL要求として公式化されるセマンティックフィルタは、候補リソースのセマンティック記述子リソースのコンテンツに対して実行される。第2に、実行の過程において、1つ以上のresourceDescriptorLink注釈を伴うクラスインスタンスに遭遇する場合、実行は、停止される。第3に、resourceDescriptorLinkが参照する、<semanticDescriptor>リソースの各々のコンテンツが、SPARQL要求が実行されているコンテンツに追加される(遅延評価、代替:実行前に全てをフェッチするが、不必要情報のフェッチをもたらし得る)。第4に、SPARQL要求の実行が、拡大コンテンツにおいて継続される。
(oneM2Mにおけるアクセス制御ポリシ)
図10に示されるように、従来の<accessControlPolicy>リソースは、privilegesおよびselfPrivileges属性から成り、それらは、規定されたコンテキスト(accessControlContextsによって定義される)内のある動作(accessContolOperationsによって定義される)を行うための権利を有するエンティティ(accessControlOriginatorsによって定義される)を定義するアクセス制御ルールの組を表し、特定のリソースへのアクセス決定を行うことにおいてCSEによって使用される。privilegeでは、各アクセス制御ルールは、どのAE/CSEがどの動作を可能にされるかを定義する。したがって、アクセス制御ルールの組に対して、動作が組内の1つ以上のアクセス制御ルールによって許可される場合、その動作が許可される。<accessControlPolicy>リソースタイプではないリソースに対して、そのようなリソースのための共通属性accessControlPolicyIDは、そのリソースを<accessControlPolicy>リソースにリンクする識別子のリストを含む。そのようなリソースのためのCSEアクセス決定は、<accessControlPolicy>リソース内に定義されたprivileges属性によって表されるアクセス制御ルールの組の評価に従うものとする。selfPrivileges属性は、<accessControlPolicy>リソース自体のためのアクセス制御ルールの組を表すものとする。<accessControlPolicy>リソースのためのCSEアクセス決定は、<accessControlPolicy>リソース自体内に定義されたselfPrivileges属性によって表されるアクセス制御ルールの組の評価に従うものとする。
<accessControlPolicy>リソースは、従来、表3に規定された属性を含む。
privilegesおよびselfPrivileges属性に表される従来のアクセス制御ルールの組は、以下に説明される3−タプルから成る。accessControlOriginatorsは、access−control−rule−tuple内のパラメータである。それは、このアクセス制御ルールを使用することを可能にされる発信側の組を表す。発信側の組は、パラメータのリストとして記述され、パラメータのタイプは、リスト内で変動し得る。表4は、accessControlOriginators内のパラメータのサポートされるタイプを記述する。
originatorIDが、<AE>または<remoteCSE>をメンバとして含む、<group>リソースのresource−IDであるとき、リソースのホスト側CSEは、要求の発信側が<group>リソースのmemberID属性内のメンバのうちの1つに一致するかどうかを決定する(例えば、<group>リソースを読み出すことによって)。<group>リソースが、読み出されることができない、または存在しない場合、要求は、否認されるものとする。
accessControlContextsは、リストを含む、access−control−rule−tuple内のパラメータであり、リストの各要素は、存在するとき、本アクセス制御ルールを使用することが許可されるコンテキストを表す。各要求コンテキストは、パラメータの組によって記述され、パラメータのタイプは、組内で変動し得る。表5は、accessControlContexts内でサポートされるタイプのパラメータを記述する。以下の従来の発信側accessControlContextsは、CSEによるアクセス制御ポリシチェックのために考慮されるものとする。
accessControlOperationsは、このアクセス制御ルールを使用して認可される動作の組を表すaccess−control−rule−tupleにおけるパラメータである。表6は、accessControlOperationsによって認可される動作のサポートされる組を記述する。以下のaccessControlOperationsは、CSEによるアクセス制御ポリシチェックのために考慮されるものとする。
(M2Mセマンティックサポートの提案される機能アーキテクチャ)
図11は、M2Mセマンティックサポートのための提案される機能アーキテクチャを示し、主要コンポーネントは、リソースリポジトリ、オントロジープロセッサ、オントロジーリポジトリ、セマンティックリポジトリ、ルールリポジトリ、推論器、またはセマンティッククエリプロセッサを含み得る。リソースリポジトリは、物理的M2Mデバイスから収集される、全てのリソースを記憶する。M2Mセマンティックサポートは、それらのユニバーサル理解/解釈のためのオリジナルリソースに対するセマンティクスと、それらに対する任意の高度な処理、例えば、セマンティッククエリ、データ分析等とを可能にするために意図される。オントロジープロセッサは、M2Mドメインの外部および内部でパブリッシュ/生成されたオントロジーの処理、分類、記憶、および発見機能の提供を担当する。オントロジーリポジトリは、オントロジーを記憶する。それらのオントロジーは、リソースのためのセマンティクスを可能にするために使用されることができる。セマンティックリポジトリは、注釈が付けられたセマンティック情報を、RDFを利用するオプションを有し得るある表現で記憶する。セマンティック注釈は、リソースのセマンティクスをバイナリストリーム等の特定のフォーマットで表すプロセスである。ルールリポジトリは、多くの場合、リソースリポジトリ内のリソースに関連付けられた既存のセマンティクスを超える、新しい知識を表すために使用されるルールを記憶する。ルールは、典型的には、条件付き文:if−then節である。推論器は、ルールリポジトリからの入力およびセマンティックリポジトリ内の既存のリソースセマンティック情報をとり、ルール内の条件が満たされる場合、新しいリソースセマンティック情報を生成する。新しいリソースセマンティック情報は、セマンティックリポジトリに追加される。セマンティッククエリプロセッサは、クライアントからのクエリをハンドリングし、セマンティックリポジトリ内に記憶されるリソースセマンティック情報を検索し、結果をクライアントに返す。
(例示的実施形態の詳細な説明)
「セマンティックモノのインターネット」に関して本明細書に説明されるように、セマンティックウェブと比較して、セマンティックIoTに関する多くの課題が存在する。第1の課題は、特に、図12に関連付けられたユースケースIに図示されるシナリオのようなセキュリティおよびプライバシであり、集中管理セマンティックグラフストアへのアクセスを制御する方法、およびセマンティックグラフストアのためのアクセス制御ポリシを効率的に管理するための方法が、対処されるべきである。別の課題は、図13に関連付けられたユースケースIIに図示されるシナリオのように、RDFトリプルであるかどうかにかかわらず、データベース内に分散された大量のセマンティック記述子であり、セマンティックRDFトリプルを階層リソースツリーから抽出し、RDFトリプルに対して動作を実施する方法が、対処されるべきである。ユースケースIIにおける分散型セマンティック記述子に関して、別のクエリ関連問題は、クエリの範囲であり、クエリの範囲は、検索されるグラフのスパン、または記述子から生じる対応するRDF記述のスパンとして見なされ得る。この検索は、クエリ動作標的として使用されるリソースに関連付けられるが、デフォルトスパンは、容易に非最適化検索につながり得る。
セマンティックIoTサービスまたはアプリケーションのためのセマンティック記述子に適用されるRESTful動作のための複数のアプローチが、本明細書において開示される。集中管理セマンティックグラフストア内のセマンティック記述子のための機構、階層リソースツリー内に分散されたセマンティック記述子のための機構、および集中管理グラフストアおよび階層リソースツリーの両方に位置するセマンティック記述子のためのハイブリッド機構の詳細が、本明細書に提供され。サービスエンティティ内に分散されるセマンティック記述子のための代替も、議論される。本明細書において、用語「グラフ」の使用は、「セマンティックグラフ」等と同義的であることを理解されたい。
ユースケースIは、図12の図に議論される。図12に示されるように、RDFトリプル(例えば、セマンティック記述子)の形態におけるセマンティック記述が、集中管理RDFトリプルデータベース、例えば、セマンティックグラフストアに置かれる。例えば、医師−Dおよび医師−Dの患者A、Bは、それらのセマンティック記述子を集中管理RDFトリプルストアまたはセマンティックグラフストアの中に記憶し、次いで、医師−Dは、患者が許可を医師−Dに付与する場合、全ての彼の患者のセマンティック記述子に対するセマンティッククエリを実施し得、患者も、それら自身のセマンティック記述子と、医師−Dが許可をその患者に付与する場合、医師−Dのセマンティック記述子の一部とに対するセマンティッククエリを実施し得る。しかし、患者は、許可が付与されない場合、互いのセマンティック記述子に対するセマンティッククエリを実施することはできない。さらに、医師−Dは、彼のセマンティック記述子と、おそらく、許可が彼の患者によって付与される場合、彼の患者のセマンティック記述子の一部を更新または削除し得、同様に、患者は、それら自身のセマンティック記述子と、おそらく、許可が医師−Dによって付与される場合、医師−Dのセマンティック記述子の一部とを更新または削除し得る。
ユースケースIIは、図13の図に議論される。図13に示されるように、データと、RDFトリプル(例えば、セマンティック記述子)の形態におけるかどうかにかかわらず、セマンティック記述との両方が、関係データベース、例えば、階層リソースツリーに置かれる。例えば、医師−Dおよび医師−Dの患者A、Bは、それらのデータおよびセマンティック記述子を関係データベースまたは階層リソースツリーの中に記憶する。セマンティック記述子1は、関連eヘルスアプリケーションに関連するセマンティック情報を記述し、セマンティック記述子2は、データコンテナのためのものであり、セマンティック記述子3は、特定のデータインスタンスのためのものである。後に、医師−Dは、患者が許可を医師−Dに付与する場合、リソースツリー内の全ての彼の患者のセマンティック記述子に対してセマンティック記述を用いたセマンティック検索またはセマンティッククエリを実施し得、患者は、リソースツリー内のそれら自身のセマンティック記述子と、医師−Dが許可をその患者に付与する場合、医師−Dのセマンティック記述子の一部とにセマンティック記述を用いたセマンティック検索またはセマンティッククエリを実施し得る。しかし、患者は、許可が付与されない場合、互いのセマンティック記述子に対するセマンティッククエリを実施することはできない。さらに、医師−Dは、彼のセマンティック記述子と、おそらく、許可が彼の患者によって付与される場合、その患者のセマンティック記述子の一部とを更新または削除し得、患者は、それら自身のセマンティック記述子と、おそらく、許可が医師−Dによって付与される場合、医師−Dのセマンティック記述子の一部とを更新または削除し得る。
いくつかの一般的考慮点が、以下に開示される。セマンティック記述は、RDFトリプルのようなフォーマットであることも、そうではないこともある。一般的フォーマットにおける、例えば、具体的には、RDFトリプルのようなS−P−O関係説明ではないセマンティック記述は、リソースツリー内のメタデータまたはコンテキスト情報等の他のリソースと同じである。本明細書では、関係、例えば、RDFトリプルS−P−Oにおいてセマンティック記述に関して議論され、したがって、用語「セマンティック記述子」または「セマンティックトリプル」は、RDFトリプルのようなフォーマットにおけるセマンティック記述のために使用される。SPARQLは、例証目的のためにのみ、RDFトリプルのために使用される。ソリューションは、リンクされたデータのための他のタイプのセマンティック表現およびセマンティッククエリ言語に一般的である。データは、リソースツリー内の記録のために本明細書で使用される一般的用語であり、記録は、データサンプルまたはコンテキスト情報(例えば、メタデータ)であり得る。セマンティックトリプルにおける要素またはノード(例えば、トリプルS−P−OのS、P、またはO)は、セマンティックトリプル命令文において、一意の識別子、例えば、国際リソース識別子(IRI)またはユニフォームリソース識別子(URI)によってアドレスされる。URIが、使用されるが、IRIまたは他の識別子(例えば、URL)も、開示される機構内で適用可能である。RDFトリプルS−P−Oにおける要素またはノードは、URI、ブランクノードラベル、またはユニコード文字列リテラルによって表され得る。命令文を簡略化するために、基数または名前空間は、いくつかの例では、セマンティックトリプルのために使用されない。セマンティックトリプルは、RESTful動作議論のために使用されるが、機構は、例えば、SPARQL Update1.1によってサポートされるセマンティックグラフ(例えば、リンクされたトリプルまたはリンクされたデータ)動作にも適用され得る。1つのセクションまたは例の動作が別のセクションまたは例に適用され得ることも本明細書で想定されていることを理解されたい。例えば、集中管理アーキテクチャのための集中管理セマンティックグラフストアのためのRESTful動作に関する本明細書に開示される動作メッセージ(例えば、要求および応答)は、階層リソースツリー内に分散されたセマンティック記述子、および、セマンティックグラフストアおよび階層リソースツリー内のセマンティック記述子等、本明細書に開示される他のアーキテクチャのための動作にも適用可能である。
図14Aに示されるように(以下の図14Aおよび14B議論の追加のコンテキストに関するユースケースI、IIおよび図29参照)、集中管理アーキテクチャは、以下の特徴を有する。セマンティックグラフストアは、セマンティックトリプルを含み得、セマンティックトリプルは、サービスエンティティ(SE)、例えば、oneM2MにおけるCSE上に常駐し、その個々のURIを介して、異なるリソースツリー内の異なるリソースを指し示す。URIは、URIがIoTシステム内で到達可能またはアクセス可能である場合、URLと同一である。URIを介してセマンティックトリプルによってアドレス指定または指し示されたリソース(図14Bに図示される)は、サービスエンティティ上の同一階層リソースツリーに位置するか、例えば、全ての医師−Dのリソースが、SE1上のリソースツリー1に位置するか、または、複数のサービスエンティティ上の異なる階層リソースツリー上に置かれ、例えば、患者−Aのリソースは、SE2上のリソースツリー2に位置し、患者−Bのリソースは、SE3上のリソースツリー3に位置するが、対応するセマンティックトリプルは、SE1に位置する。アプリケーションエンティティ(AE)、例えば、oneM2MにおけるAEは、リソースツリー内のリソースまたはセマンティックグラフストア内のセマンティックトリプルのいずれかに対するCREATE、RETRIEVE、UPDATE、DELETE等のRESTful動作のために、インターフェースAS、例えば、oneM2MにおけるMcaインターフェースを介して、サービスエンティティと通信し得る。サービスエンティティ(SE)は、リソースツリー内のリソースまたはセマンティックグラフストア内のセマンティックトリプルのいずれかに対するCREATE、RETRIEVE、UPDATE、DELETE等のRESTful動作のために、oneM2MにおけるインターフェースSS、例えば、MccまたはMcc’インターフェースを介して、別のサービスエンティティ(SE)と通信し得る。データ保管マネージャは、AEおよび/またはSE等の他の外部エンティティ、ならびにセマンティック保管マネージャおよび/または他の共通機能エンティティ等の内部エンティティとのデータ交換;CREATE、RETRIEVE、UPDATE、DELETE等のためのコマンドを介したリソースツリーデータベース動作および管理に責任がある。セマンティック保管マネージャは、AEおよび/またはSE等の他の外部エンティティならびデータ保管マネージャおよび/または他の共通機能エンティティ等の内部エンティティとのセマンティックトリプル交換;もしくはCREATE、RETRIEVE、UPDATE、DELETE等のためのコマンドを介したセマンティックグラフストア動作および管理に責任がある。
図14Aでは、医師−Dのトリプルおよびデータの両方が、同一SE上に位置するように示されるが、それらは、異なるSEに位置することも可能である。図14Aに示される集中管理セマンティックグラフストアは、別のサービスドメイン、例えば、別のサービスプロバイダ内のSEに位置することも可能である。この場合、RESTful動作は、サービスドメインをまたぎ、例えば、oneM2MにおけるインターフェースMcc’を介する。
IoTシステム内に複数の集中管理セマンティックグラフストアを伴う別のアーキテクチャは、図14Bに例示される。このアーキテクチャでは、セマンティックグラフストア1は、SE1に位置し、セマンティックグラフストア2は、SE2に位置する。セマンティックグラフストア1とセマンティックグラフストア2との間の動作は、CREATE、RETRIEVE、UPDATE、DELETE等のためのコマンドを介して、インターフェースSS1、例えば、oneM2MにおけるMcc/Mcc’インターフェースで実施され得る。
図14Aに例示されるように、トリプルは、セマンティックグラフストア内で接続またはリンクされる。例えば、図15に示されるように、トリプル1「医師Dは、患者Aを有する」は、PatientA_URIを介して、トリプル2「患者Aは、心臓データXを有する」とリンクされる。
<Doctor D>等のリソースは、リソースツリー1内のDoctor_URIに記憶され、<Patient A>および<Heart−Data X>等のリソース(図14Aには図示せず)は、それぞれ、リソースツリー2内のPatientA_URIおよびHeartData_URI(図14Aには図示せず)に記憶される。
医師−Dのeヘルスアプリケーション(例えば、アプリケーションエンティティ1)は、インターフェースAS1を介するサービスエンティティ1におけるリソースツリー1における医師−Dの患者のリソース(許可が付与される場合)に対するRESFTful動作、インターフェースSS1を介するサービスエンティティ1を通したサービスエンティティ2におけるリソースツリー2における医師−Dの患者のリソース(許可が付与される場合)に対するRESFTful動作、およびインターフェースSS2を介するサービスエンティティ1を通したサービスエンティティ3におけるリソースツリー3における医師−Dの患者のリソース(許可が付与される場合)に対するRESFTful動作のために、インターフェースAS1を介してサービスエンティティ1と通信し得る。医師−Dのeヘルスアプリケーションは、インターフェースAS1を介して、サービスエンティティ1におけるセマンティックグラフストア内の医師−Dの患者のセマンティックトリプル(許可が付与される場合)にRESTful動作を適用し得る。
患者−Aの心臓モニタeヘルスアプリケーション(例えば、アプリケーションエンティティ2)は、インターフェースAS2を介したサービスエンティティ2におけるリソースツリー2における患者−Aまたは医師−Dのリソース(許可が付与される場合)に対するRESFTful動作、およびインターフェースSS1を介したサービスエンティティ2を通したサービスエンティティ1におけるリソースツリー1における患者−Aまたは医師−Dのリソース(許可が付与される場合)に対するRESFTful動作のために、インターフェースAS2を介して、サービスエンティティ2と通信し得る。患者−Aの心臓モニタeヘルスアプリケーションは、インターフェースSS1を介して、サービスエンティティ2を通して、サービスエンティティ1におけるセマンティックグラフストア内の患者−Aまたは医師−Dのセマンティックトリプル(許可が付与される場合)にもRESTful動作を適用し得る。
図16−図21等に図示されるステップを行うエンティティは、図51Cまたは図51Dに図示されるもの等のデバイス、サーバ、またはコンピューティングシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア(例えば、コンピュータ実行可能命令)の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図16−図22、図27−図30、図45−図49等に図示される方法は、図51Cまたは図51Dに図示されるデバイスまたはコンピューティングシステム等のコンピューティングデバイスのメモリ内に記憶されるソフトウェア(例えば、コンピュータ実行可能命令)の形態で実装され得、そのコンピュータ実行可能命令は、コンピューティングデバイスのプロセッサによって実行されると、図16−図22、図27−図30、図45−図49等に図示されるステップを行う。ある例では、M2Mデバイスの相互作用に関して以下のさらなる詳細を伴って、図29のAE373は、図51AのM2M端末デバイス18上に常駐し得る一方、図29のSE361は、図51AのM2Mゲートウェイデバイス14上に常駐し得る。
図16は、図14Aに図示されるアーキテクチャのための例示的一般的RESTfulセマンティックトリプル動作フローを図示する(例えば、医師−DのeヘルスアプリケーションAE1は、セマンティックトリプルまたはセマンティックグラフストア内のトリプルへのグラフ動作を要求する)。図17は、図14Aに図示されるアーキテクチャのための例示的一般的RESTfulセマンティックトリプル動作フローを図示する(例えば、患者−Aの心臓モニタeヘルスアプリケーションAE2は、セマンティックトリプルまたはセマンティックグラフストア内のトリプルへのグラフ動作を要求する)。図16および図17は、ASインターフェース(例えば、oneM2MにおけるMcaインターフェース)を介して、AEとSEとの間、またはSSインターフェース(例えば、oneM2MにおけるMccまたはMcc’インターフェース)を介して、SE間のRESTful要求および応答メッセージに基づき得る。本明細書に説明される例示的機構は、SE1におけるセマンティックグラフストア1とSE2におけるセマンティックグラフストア2との間のグラフ動作等、図14Bに図示されるアーキテクチャのためのセマンティックグラフ動作にも適用可能である。要求メッセージは、異なるセマンティックトリプルまたはグラフ動作に基づいて、必須、動作依存、または随意のパラメータを含み得る。要求メッセージは、例であり、必ずしも、オプション、必須等ではない、以下のパラメータを含み得る。それは、実装依存である。
一般的RESTfulセマンティックトリプル動作フロー(例えば、図16および図17)を継続して参照すると、第1のパラメータの組は、リソース発見における試行に関連付けられた以下を含み得る。「To」フィールドは、<SemanticGraphStore>リソースのアドレスまたはIDを含み得る。<SemanticGraphStore>リソースは、事前プロビジョニングまたはリソース発見によって既知であり得る。「From」フィールドは、発信側151のID(例えば、AE IDまたはSE ID)を含み得る。これは、受信側152(例えば、SE)によって、セマンティックグラフストア内のセマンティックトリプル動作のための発信側のアクセス権をチェックするために使用され得る。動作フィールドは、CREATE(C),RETRIEVE(R),UPDATE(U),DELETE(D)等の実施されるべき動作を含み得る。動作タイプは、リソースツリー内のリソース動作のための「リソース」、セマンティックグラフストア内のトリプル動作のための「トリプル」、および/またはセマンティックグラフストアにおけるグラフ動作のための「グラフ」であり得る値を含み得る。デフォルトは、「リソース」である。本明細書に与えられる例の多くは、トリプルおよびグラフ動作に関する。要求識別子は、要求と応答との間で相関させるために使用されるべき要求識別子を含み得る。
一般的RESTfulセマンティックトリプル動作フロー(例えば、図16および図17)を継続して参照すると、第2のパラメータの組は、トリプルまたはグラフ動作のための動作依存パラメータと見なされ得る。以下により詳細に議論されるようなコンテンツおよびコンテンツフォーマットが存在し得る。コンテンツは、転送されるべきセマンティックコンテンツ(例えば、トリプルまたはグラフ)を含み得、セマンティックコンテンツは、セマンティックトリプルまたはグラフ動作の点から見て、異なって提示され得る。ある例では、CREATEに関して、コンテンツは、「トリプル」または「グラフ」として<OperationType>を伴う新しいセマンティックトリプルのコンテンツであり得る。例えば、「Doctor−D_URIは、PatientA_URIを有する」等のトリプル。ある例では、UPDATEに関して、コンテンツは、既存のセマンティックトリプルまたはグラフと置換されるべきコンテンツを含み得る。例えば、図15に示されるトリプル110に対して、「Doctor−D_URIは、PatientA_URI1を有する」を置換するための「Doctor−D_URIは、PatientA_URI2を有する」。更新または置換されるべき既存のセマンティックトリプルまたはグラフは、<SemanticTripleGraphID>(例えば、グラフのための一意の名前)によって明示的にアドレス指定されるか、またはセマンティックグラフストア内のトリプルまたはグラフ関係ネットワークに一致するようにこの新しいコンテンツを使用することを介して、セマンティッククエリエンジンによって推測され得る。ある例では、RETRIEVEに関して、コンテンツは、クエリセマンティックトリプルを含み得る。例えば、「?医師は、患者−Aを有する」(?医師は、クエリのための変数である)は、患者−Aの医師をクエリするためのものである。ある例では、DELETEに関して、コンテンツは、削除されるべき既存のセマンティックトリプルまたはグラフのコンテンツを含み得る。既存のセマンティックトリプルまたはグラフは、削除するための<SemanticTripleGraphID>(例えば、グラフのための一意の名前)によって明示的にアドレス指定されるか、またはセマンティックグラフストア内のトリプルまたはグラフに一致するようにこのコンテンツを使用することによって、セマンティッククエリエンジンによって推測され得る。
前述のコンテンツフォーマットに関し、コンテンツフォーマットは、トリプルのためのN−Triple、JSON、RDF/XML、もしくはタートル、クエリのためのSPARQLもしくはSQL、または他の構造化されたテキストもしくはリテラル等のセマンティックトリプルまたはグラフ動作コンテンツのフォーマットと見なされ得る。
一般的RESTfulセマンティックトリプル動作フロー(例えば、図16および図17)を継続して参照すると、第3のパラメータの組が、考慮され得る。creatorパラメータが存在し得、それは、転送されるべきセマンティックコンテンツの作成者、例えば、AE IDまたはSE IDを示す。SemanticTripleGraphIDsパラメータも存在し得、それは、発信側151によって提示されないか、またはセマンティックグラフストア内の既存のトリプルと矛盾する場合、受信側152によって作成され得る。SemanticTripleGraphIDsパラメータは、セマンティックトリプルグラフのIDであり、絶対的または相対的であるが、セマンティックグラフストア内で一意であり得る。アクセス制御ポリシIDパラメータも存在し得、発信側151によって提示されない場合、受信側152が、発信側151のIDおよびサービスプロファイルに基づいて作成し得る。このパラメータは、受信側152によって、発信側のアクセス制御権をチェックし、適宜、動作を確証するために使用され得る。OntologyRefパラメータも存在し得、発信側152によって提示されない場合、受信側152が、発信側151のIDおよびサービスプロファイルに基づいて、<ontologyRef>を作成し得る。
第3のパラメータの組を継続して参照すると、response messagetypeパラメータ、result contentパラメータ、またはfilter criteriaパラメータも存在し得る。response message typeパラメータは、発行された要求に送信され得る応答のタイプおよび応答が発信側151に送信され得る時を示し得る。異なる応答タイプは、発信側151によって、とりわけ、通信、トリプル動作待ち時間、システム能力、現在の処理、または負荷状態に基づいて、要求され得る。応答メッセージタイプは、とりわけ、ACK sync、ACK async、NoACK sync、またはACKnoACKを含み得る。ACK syncに関して、承認後、受信側152は、受信側152がさらに要求を処理するであろうことを確認する肯定応答で応答し得る。要求される動作の実行の成功または失敗が、後に伝達されることになる。ACK async{list of notification targets}に関して、承認後、受信側152は、受信側がさらに要求を処理するであろうことを確認する肯定応答で応答し得る。要求される動作の結果は、通知標的への通知として送信されるべきである。通知標的は、エンティティのリストとしてこのパラメータ内に、または通知標的リストが提供されないとき、発信側151に提供され得る。空通知標的リストが発信側151によって提供されるとき、要求される動作の結果を伴う通知は、全く送信され得ない。NoACK syncに関して、承認後、受信側152は、要求される動作の完了後、要求される動作の結果で応答し得る。それは、response typeパラメータが要求に与えられないときのデフォルト挙動であり得る。ACKnoACK{list of notification targets}に関して、承認後、受信側152は、そのステータスまたは他のサービスポリシに基づいて、応答する方法(上で説明されるACKまたはNoACKのいずれか)を決定し得る。
result contentパラメータも存在し得、result contentは、要求される動作の結果の期待されるコンポーネントを示す。セマンティックトリプルグラフID:要求セマンティックトリプルの<SemanticTripleGraphID>。セマンティックトリプルまたはグラフは、コンテンツとして返される要求されるセマンティックトリプルまたはグラフの表現である。セマンティックトリプルノードは、要求セマンティックトリプルのトリプルノードのためのURI、バンクノードラベル、または「リテラル」であり得る。これは、URIが返される場合、<URIType>によって示され得る。URIタイプは、絶対的または相対的URIを示す。相対的URIが使用される場合、<NameSpace>またはオントロジー参照が、相対的URI内に含まれ得る。真/偽は、要求される動作、例えば、SPARQLクエリ「ASK」動作のブール論理結果である。
filter criteriaパラメータも存在し得、それは、セマンティックグラフストア内のフィルタリングされるセマンティックトリプルまたはグラフ動作のためのフィルタ基準を示す。SPARQLクエリのためのフィルタリングの例は、以下に示される。
PREFIXrdfs:<http://www.w3.org/2000/01/rdf−schema#>
PREFIXtype:<http://dbpedia.org/class/yago/>
PREFIXprop:<http://dbpedia.org/property/>
SELECT?country_name?population
WHERE{
?countryatype:LandlockedCountries;
rdfs:label?country_name;
prop:populationEstimate?population.
FILTER(?population>15000000).
}
SPARQL組み込みフィルタ機能は、以下にリストアップされる。
・ Logical:!,&&,||
・ Math:+,−,*,/
・ Comparison:=,!=,>,<,...
・ SPARQL tests:isURI,isBlank,isLiteral,bound
・ SPARQL accessors:str,lang,datatype
・ Other:sameTerm,langMatches,regex
応答メッセージは、異なるセマンティックトリプル動作に基づいて、全てのタイプのパラメータを含み得る。パラメータは、異なる方法で提供され得るが、以下は、例である。実装に応じて、いくつかのパラメータは、随意もしくは必須と見なされることも、そうでないこともある。例示的パラメータは、以下である。第1のパラメータの組は、応答ステータスまたは要求識別子を含み得る。応答ステータスは、要求される動作の結果が、成功、不成功、肯定応答(例えば、後に伝達されるべき結果)、または認可タイムアウト等の処理のステータスであることを示し得る。request identifier(ID)パラメータは、対応する要求を識別し得る。
動作依存と見なさ得る、第2のパラメータの組は、以下の例を含み得る:コンテンツまたはコンテンツステータス。コンテンツは、応答ステータスが成功である場合、1)CREATE(コンテンツがセマンティックグラフストア内の<SemanticTripleGraphID>である)、2)UPDATE(コンテンツがセマンティックグラフストア内で置換されるセマンティックトリプルもしくはグラフである)、3)DELETE(コンテンツが削除されるセマンティックトリプルもしくはグラフである)、または、4)RETRIEVE(コンテンツは、セマンティッククエリ結果であり、それは、要求メッセージ内の<ResultContent>によって示されるような<SemanticTripleGraphID>、<SemanticTriples/Graph>、<SemanticTripleNodes>、もしくは<True/False>ブール論理結果を含み得る)。応答ステータスが不成功である場合、応答内のcontentパラメータは、エラー情報を含み得る。応答ステータスが肯定応答である場合、contentパラメータは、<ResponseType>が要求内に規定されるようなACKベースである場合は、<SemanticTripleGraphID>を含み得る。content statusパラメータは、応答ステータスが成功である場合にセマンティッククエリが返したコンテンツが部分的であるとき、それに応答して、RETRIEVE動作を示し得る。
第3のパラメータの組は、以下の例であり得る:「To」または「From」。「to」パラメータは、発信側151またはトランジットSE150のアドレスまたはIDを示し得る。「from」パラメータは、受信側152のIDを示し得る。
前述の動作のいくつかのいくつかの追加の詳細が、以下の図に「トリプル」とともに図示される。図18は、CREATEセマンティックトリプルのための動作フローを提供する。図19は、RETRIEVEセマンティックトリプル−セマンティッククエリのための動作フローを提供する。図20は、UPDATEセマンティックトリプルのための動作フローを提供する。図21は、DELETEセマンティックトリプルのための動作フローを提供する。
図18から図21に詳述される機構はまた、セマンティックグラフストアのためのセマンティックグラフ動作、またはセマンティックグラフストア間のセマンティックグラフ動作にも適用可能である。図18は、CREATEセマンティックトリプルのための例示的動作フローを図示する。ステップ201では、セマンティックトリプルCREATE動作要求が、送信される。ステップ201の要求は、1)To:SemanticGraphStoreおよびFrom:発信側ID(例えば、AE IDまたはSE ID)、2)動作:CREATE、3)パラメータ:RequestID、ContentFormat(例えば、RDF XML)、AccessControlPolicyIDs、OntologyRef、Creator、ResponseType、ResultContent(SemanticTripleIDs)、および、4)コンテンツ:SemanticTriplesを含み得る。
図18を継続して参照すると、ステップ202では、セマンティックトリプルCREATE動作処理が、例えば、受信側152で生じる。セマンティックグラフストア154におけるセマンティックトリプルCREATE動作の確証が存在し得る。確証は、以下を含み得る。発信側151が、<accessControlPolicyID>によって規定された標的セマンティックトリプルを作成するための権利を有するかどうか決定すること、または、<accessControlPolicyID>が存在しない場合、<ServiceSubscriptionPolicy>および他のサービスポリシに基づいて、<accessControlPolicyID>を作成し、割り当てること。<ontologyRef>を確証することもあり得、発信側151によって提供されない場合、<ontologyRef>を割り当て得る。加えて、発信側151によって、ステップ201のCREATE要求内に提供される場合、<SemanticTripleIDs>がセマンティックグラフストア154内にまだ存在していないことが検証され得る。存在していない場合、発信側151によって示唆される<SemanticTripleIDs>が、使用され得、そうでなければ、一意の<SemanticTripleIDs>が、作成されるべきセマンティックトリプルと共に使用される。「AccessControlTriples」(例えば、Who−What−Howを定義するアクセス制御ルールタプル)も、<accessControlPolicyID>によって識別される<accessControlPolicy>下の<privileges>によって規定されたアクセス制御ポリシルールに基づいて、作成されるべきセマンティックトリプルに関連付けられ得る。<creator>が、ステップ201の要求内に含まれる場合、「CreatorTriple」が、作成されるべきセマンティックトリプルに関連付けられ得る。最後に、ステップ201のCREATE要求の確証成功時、ステップ201の要求内に提供されない場合、セマンティックトリプルCREATE動作コマンドを作成する。例えば、SPARQL更新言語では、セマンティックグラフストア154におけるトリプル「insert」またはグラフ「add」。
図18を継続して参照すると、ステップ203では、セマンティックCREATE動作が、セマンティックグラフストア154内で実施される。例は、図18に示される。例えば、CREATE動作をマッピングするために使用され得るこれらのグラフ管理動作を提供するために、SPARQL1.1更新を介して、また、1)CREATE(空グラフをサポートするストア内に新しいグラフを作成する)、2)COPY(別のコピーを含むようにグラフを修正する)、3)MOVE(1つのグラフからのデータを全て別のグラフの中に移動させる)、または、4)ADD(全てのデータを1つのグラフから別のグラフの中に複製する)も可能である。ステップ204では、応答をCREATE動作結果で構成する。ステップ205では、セマンティックトリプルCREATE動作応答がある。応答は、1)To:発信側ID(例えば、AE IDまたはSE ID)およびFrom:受信側ID(例えば、SE ID)、2)パラメータ:RequestStatus(成功)、RequestID、および、3)コンテンツ:SemanticTripleIDs(ResponseTypeがNoACKsyncである場合)を含み得る。
図19は、RETRIEVEセマンティックトリプル−セマンティッククエリのための例示的動作フローを図示する。ステップ211では、セマンティックトリプルRETRIEVE動作要求が、送信される。ステップ211の要求は、1)To:SemanticGraphStoreおよびFrom:発信側ID(例えば、AE IDまたはSE ID)、2)動作:RETRIEVE、3)パラメータ:RequestID、ContentFormat(例えば、SPARQL)、FilterCriteria、またはResultContent、および、4)コンテンツ:SemanticTriplesを含み得る。
図19を継続して参照すると、ステップ212では、セマンティックトリプルRETRIEVE動作処理が、例えば、受信側152で生じる。セマンティックグラフストア154におけるセマンティックトリプルRETRIEVE動作の確証が存在し得る。確証は、以下を含み得る。発信側151(AE IDまたはSE IDを使用する)がトリプルに関連付けられた<accessControlPolicy>に基づいて、セマンティックトリプルまたはそのクエリセマンティックトリプルによって規定された他の情報を読み出す権利を有するかどうか決定する。<ontologyRef>も、必要とされる場合、確証され得る。加えて、FilterCriteriaが有効であるかどうか決定され得る。最後に、ステップ211のRETRIEVE要求の確証成功時、セマンティッククエリコマンドが、作成され得る。例えば、SPARQLクエリ言語では、結果値のテーブルに対する「SELECT」、RDFグラフに対する「CONSTRUCT」、「True/False」ブール演算結果に対する「ASK」、またはセマンティックグラフストア154が返すどんなものにも対する「DESCRIBE」である。
図19を継続して参照すると、ステップ213では、セマンティッククエリ動作が、セマンティックグラフストア154内で実施される。例は、図19に示される。ステップ214では、RETRIEVE動作結果を伴う応答を構成する。ステップ215では、セマンティックトリプルRETRIEVE動作応答が存在する。応答は、1)To:発信側ID(例えば、AE IDまたはSE ID)およびFrom:受信側ID(例えば、SE ID)、2)パラメータ:RequestStatus(成功)、RequestID、および、3)コンテンツ:SemanticTriples(ResponseTypeがNoACKsyncである場合)を含み得る。
図20は、UPDATEセマンティックトリプルのための例示的動作フローを図示する。ステップ221では、セマンティックトリプルUPDATE動作要求が、送信される。ステップ221の要求は、1)To:SemanticGraphStoreおよびFrom:発信側ID(例えば、AE IDまたはSE ID)、2)動作:UPDATE、3)パラメータ:RequestID、SemanticTripleIDs、ContentFormat(例えば、RDF XML)、FilterCriteria、ResultantContent、および4)コンテンツ:SemanticTriplesを含み得る。
図20を継続して参照すると、ステップ222では、セマンティックトリプルUPDATE動作処理が、例えば、受信側152で生じる。セマンティックグラフストア154内のセマンティックトリプルUPDATE動作の確証が存在し得る。確証は、以下を含み得る。発信側151が、トリプルに関連付けられた<accessControlPolicy>によって規定された標的セマンティックトリプルを更新するための権利を有するかどうかを決定する。<ontologyRef>の確証およびFilterCriteriaが有効であるかどうの決定も存在し得る。最後に、ステップ221のUPDATE要求確証成功時、ステップ221のUPDATE要求内に提供されない場合、セマンティックトリプルUPDATE動作コマンドを作成する。例えば、SPARQL更新言語では、トリプルを更新するための「DELETE」および「INSERT」。
図20を継続して参照すると、ステップ223では、セマンティックUPDATE動作が、セマンティックグラフストア154内で実施される。例えば、UPDATE動作をマッピングために使用され得るこれらのグラフ管理動作を提供するために、SPARQL1.1更新を介して、また、1)CREATE(新しいグラフを空グラフをサポートするストア内に作成する)、2)COPY(別のコピーを含むようにグラフを修正する)、3)MOVE:データの全てを1つのグラフから別のグラフの中に移動させる)、4)ADD(全てのデータを1つのグラフから別のグラフの中に複製する)、または、5)DROP(グラフおよびそのコンテンツの全てを除去する)も可能である。ステップ224では、UPDATE動作結果を伴う応答を構成する。ステップ225では、セマンティックトリプルUPDATE動作応答が存在する。応答は、1)To:発信側ID(例えば、AE IDまたはSE ID)およびFrom:受信側ID(例えば、SE ID)、2)パラメータ:RequestStatus(成功)、RequestID、および、3)コンテンツ:SemanticTriples(ResponseTypeがNoACKsyncである場合)を含み得る。
図21は、DELETEセマンティックトリプルのための例示的動作フローを図示する。ステップ231では、セマンティックトリプルDELETE動作要求が、送信される。ステップ231の要求は、1)To:SemanticGraphStoreおよびFrom:発信側ID(例えば、AE IDまたはSE ID)、2)動作:DELETE、3)パラメータ:RequestID、SemanticTripleIDs、ContentFormat(例えば、RDF XML)、FilterCriteria、ResultantContent、および、4)コンテンツ:SemanticTriplesを含み得る。
図21を継続して参照すると、ステップ232では、セマンティックトリプルDELETE動作処理が、例えば、受信側152で生じる。セマンティック受信側152(例えば、セマンティックグラフストア154)内のセマンティックトリプルDELETE動作の確証が存在し得る。確証は、以下を含み得る。発信側151が、トリプルに関連付けられた<accessControlPolicy>によって規定された標的セマンティックトリプルを削除するための権利を有するかどうか決定する。FilterCriteriaが有効であるかどうも決定され得る。最後に、ステップ231のDELETE要求の確証成功時、ステップ231の要求内に提供されない場合、セマンティックトリプルDELETE動作コマンドを作成する。例えば、SPARQL更新言語では、特定のグラフ内の全てのトリプルを除去するための「DELETE」および「CLEAR」である。
図21を継続して参照すると、ステップ233では、セマンティックDELETE動作が、セマンティックグラフストア154内で実施される。例えば、DELETE動作をマッピングするために使用され得るこれらのグラフ管理動作を提供するためのSPARQL1.1更新を介して、また、1)MOVE:データの全てを1つのグラフから別のグラフの中に移動させる)または、2)DROP(グラフおよびそのコンテンツの全てを除去する)も可能である。ステップ234では、DELETE動作結果を伴う応答を構成する。ステップ235では、セマンティックトリプルDELETE動作応答がある。応答は、1)To:発信側ID(例えば、AE IDまたはSE ID)およびFrom:受信側ID(例えば、SE ID)、2)パラメータ:RequestStatus(成功)、RequestID、および、3)コンテンツ:SemanticTriples(ResponseTypeがNoACKsyncである場合)を含み得る。
本明細書に議論されるように、<accessControlPolicyID>によって規定される<accessControlPolicy>が、グラフ図を用いたアクセス制御または<AccessControlTriples>を用いたアクセス制御等の方法に基づいて、セマンティックグラフストア内のアクセス制御のために使用され得る。グラフ図を用いたアクセス制御を参照して、セマンティックグラフストアのグラフ図(図49Aに示される例)は、ベースグラフストア上に構築されたサブグラフであり、それは、アプリケーションに関連するデータへの特に構成されたアクセスを提供することによってデータの有用性を強化するか、または付与されたアクセス権に応じてデータへのアクセスを与えることによって、データへのアクセス制御を可能にし得る。グラフ図アプローチは、図49Bに示されるように、以下のステップを含み得る。ステップ311では、異なるグラフ図(例えば、患者−Aのためのグラフ図304、患者−Bのためのグラフ図306、または医師−Dのためのグラフ図308)が、<accessControlPolicy>によって規定されたアクセス制御ルール毎に作成され得る。グラフ図304は、患者−Aのアクセス可能トリプルを伴う患者−Aのサブグラフであり得る。グラフ図306は、患者−Bのアクセス可能トリプルを伴う患者−Bのサブグラフであり得る。グラフ図308は、患者によってアクセス可能ではない医師−Dのトリプルであり得る。円形309は、医師−Dグラフ図(例えば、医師−Dのトリプル、患者−Aのトリプル、および患者−Bのトリプルの合体である医師’Dのアクセス可能トリプルを伴う医師−Dのサブグラフ)であり得る。
ステップ311を継続して参照すると、アクセス制御ポリシに基づいてグラフ図を作成するためのいくつかの複数の方法が存在する。第1の方法では、サブオントロジー参照モデルを伴うグラフ図のサブグラフが、構築され得る。このサブグラフは、アクセス制御ポリシに基づいて構成され得、次いで、セマンティッククエリが、サブグラフ内で実施され得る。第2の方法では、セマンティッククエリによるグラフ図のためのサブグラフが、以下の例に示されるように構築され得る。
グラフ図304(例えば、患者−Aのグラフ図):
CONSTRUCT{
?doctor_:takeCareOf?patient
?doctor_:name?name
?sample_:measureFor?patient
?sample_:sValue?sValue
?sample_:dValue?dValue
?sample_:measuredOn?date
}
WHERE{
?patientex:name“Patient−A”
?patientex:dateOfBirth“200−08−3”^^xsd:date.
?doctorex:takeCareOf?patient
?doctorex:name?name
?sampleex:measureFor?patient
?sampleex:sValue?sValue
?sampleex:dValue?dValue
?sampleex:measuredOn?date}
図49Bを継続して参照すると、ステップ312では、AEまたはSEの各セマンティックトリプル動作要求に対して、図は、標的セマンティックトリプルの<accessControlPolicy>によって定義された発信側の権利に基づいて選択され得る。ステップ313では、セマンティックトリプル動作が、選択された図内で実施され、選択された図は、発信側が要求されるセマンティックトリプル動作に対して、可能にされた、セマンティックグラフストアからのそれらのセマンティックトリプルのみを含む。
図49Cは、<AccessControlTriples>を伴うアクセス制御に基づいて、セマンティックグラフストア内のアクセス制御のために使用される<accessControlPolicyID>によって規定された<accessControlPolicy>のための例示的方法の概要を図示する。ステップ316では、セマンティックグラフストア内の<accessControlPolicy>によって規定されたアクセス制御ルールが、構築され得る。ステップ317では、標的セマンティックトリプルは、それらの<accessControlPolicyID>または関連アクセス制御ルールを伴う<accessControlPolicy>に関連付けられ得る。ステップ318では、セマンティックトリプル動作が、発信側が動作することを可能にするアクセス制御ルールに関連付けられた選択されたセマンティックトリプルを用いて実施され得る。
図52は、セマンティックグラフストアに関連付けられた例示的アクセス制御ポリシを図示する。図22は、(図52におけるような)セマンティックグラフストア内のアクセス制御ポリシの例のための例示的コールフロー(方法)を図示する。図22の方法は、アクセス制御情報を標的トリプルと共に使用し、それらを一緒にセマンティックグラフストアの中に挿入する方法の例を図示する。図22のステップ240では、(図23に示されるような)eヘルスオントロジー参照モデルが、事前に構成され得、(図24に示されるような)アクセス制御オントロジーモデルが、事前に構成され得る。ステップ241では、発信側162は、アクセス制御ポリシをホストするSE163において<accessControlPolicy>リソースを作成することを要求する。ステップ242では、SE163は、<accessControlPolicy>リソースをリソースツリー内に作成する。ステップ243では、SE163は、成功結果の指示で発信側162に応答する。ステップ244では、SE163は、この<accessControlPolicy>をセマンティックグラフストア内に挿入することをSE164に要求する。ステップ245では、SE164は、<accessControlPolicy>をセマンティックグラフストア内に作成する。これは、アクセス制御オントロジー(図24に示される)を使用して、この<accessControlPolicy>下にアクセス制御ルールを表すための<AccessControlTriples>を作成し、<AccessControlTriples>をセマンティックグラフストア内に挿入することを含み得る。
図22を継続して参照すると、ステップ246では、SE164は、成功結果の指示でSE163に応答する。ステップ247では、発信側162は、<SemanticTriples>をセマンティックグラフストア内に作成することを要求する。ステップ248では、SE163は、ステップ247の要求をセマンティックグラフストアをホストするSE164に転送する。ステップ249では、SE164は、セマンティックトリプルCREATE動作を実施する。SE164は、発信側162のIDおよび関連<accessControlPolicy>を使用することによって、セマンティックグラフストア内のCREATE動作を確証し得る。<accessControlPolicy>は、それがない場合、作成され得る。SE164は、図25に示されるように、<accessControlPolicy>を作成されるべきトリプルとセマンティックグラフストア内で結合し得る。SE164は、<AccessControlTriples>に関連付けられたトリプルをセマンティックグラフストア内に挿入し得る。ステップ250では、SE164は、成功結果とともに、メッセージをSE163に送信し得る。ステップ251では、SE163は、成功結果で発信側162に応答し得る。
図22を参照すると、ステップ252では、発信側161は、セマンティックトリプルRETRIEVE動作を要求する。ステップ253では、SE163は、ステップ252の要求をSE164に送信する。ステップ254では、SE164は、セマンティックトリプルRETRIEVE動作を実施する。SE164は、図26に示されるように、発信側161のIDを使用することによって、retrieve動作を確証し、<accessControlPolicy>を用いてセマンティッククエリコマンドを構成し得る。SE164は、<AccessControlPolicy>を用いてクエリを実施し得る。ステップ255では、SE164は、成功結果とともに、メッセージをSE163に送信する。ステップ256では、SE1163は、成功結果とともに、メッセージを発信側161に送信する。
概して、アプリケーションが、発信側161によって提供されるトリプルに関してセマンティッククエリを開始する場合、SE164内のクエリエンジンが、クエリ検索を行い、それは、自動的に、セマンティックグラフストア内に挿入されているAccessControlTriplesを使用する。それは、<AccessControlTriples>と発信側161によって作成されたトリプルとの間の結合のせいであり得る。クエリAEまたはSEのみ、図26に示されるように、アクセス制御ルールを識別するために、その識別(例えば、AE IDまたはSE ID)を提供する必要があることに留意されたい。
セマンティックグラフストア内のアクセス制御のための例示的ファイルは、図23、図24、図25、図26、および図53Aから図53Cに示される。機構は、集中管理セマンティックグラフストアを用いた例であるが、一般的プロシージャが、全ての種類のセマンティックグラフストアに適用可能であり得る。
セマンティッククエリを介したリソース発見が、以下に議論される。図54は、セマンティッククエリを含むリソース発見を実施するための例示的方法を図示する。ステップ321では、発信側161(例えば、AEまたはSE)は、セマンティッククエリを、セマンティックグラフストアをホストする、SE164に送信し得る。要求に応答して、SE164は、セマンティッククエリをセマンティックグラフストアにおいて実施し得る。ステップ322では、発信側161は、SE164から、ステップ321における成功クエリに応答して、トリプルまたはトリプルノードを受信し得る。ステップ322のトリプルの受信に続き得るステップ323では、発信側161は、リソースからのRETRIEVE要求を、リソースツリーをホストする、SE164に送信し得る。リソースは、SE164のリソースツリー内にあり、ステップ322において受信されたトリプルまたはトリプルノードに指定された、または関連付けられたURIまたはURL(ユニフォームリソースロケータ)によってアドレス指定され得る。SE164は、RETRIEVE動作をリソースツリー内で実施する。ステップ323に応答し得るステップ324では、発信側161は、成功retrieve動作からトリプルまたはトリプルノードを受信する。
図27は、階層リソースツリー内に分散されたセマンティック記述子の例示的アーキテクチャを図示する。この分散型アーキテクチャは、複数の特徴を有する。セマンティッククエリのために使用される一時的セマンティックグラフストア(例えば、一時的セマンティックグラフストア330または一時的セマンティックグラフストア338)が、oneM2MにおけるCSE等のサービスエンティティ(例えば、SE331またはSE332)上にローカルに常駐し、階層リソースツリー内に分散されたセマンティック記述子(例えば、セマンティック記述子333またはセマンティック記述子334)から抽出されるセマンティックトリプルを含み得る。セマンティックトリプルを含むセマンティック記述子は、複数のサービスエンティティ上の異なる階層リソースツリーに位置し得る。例えば、セマンティック記述子334は、SE332上のリソースツリー337内に位置し、SE331上のリソースツリー339内に位置し得る。oneM2MにおけるAE等のアプリケーションエンティティ(例えば、AE335)は、リソースツリー内のセマンティック記述子リソースに関するCREATE、RETRIEVE、UPDATE、DELETE等のRESTful動作のために、oneM2MにおけるMcaインターフェース等のインターフェースAS340を介して、SE332と通信し得る。SE332は、リソースツリー内のセマンティック記述子リソースに関するCREATE、RETRIEVE、UPDATE、DELETE等のRESTful動作のために、oneM2MにおけるMccまたはMcc’インターフェース等のインターフェースSS336を介して、別のSE331と通信し得る。
階層リソースツリー内のセマンティック記述子に関するCREATE、RETRIEVE、UPDATE、およびDELETE等のRESTful動作は、他のリソースツリー内のリソースに対する動作と類似する。背景に述べられたように、セマンティッククエリは、セマンティック検索と異なり、セマンティッククエリは、セマンティックグラフストア内でリンクされた全てのセマンティックトリプルを用いて実施されるべきである。したがって、ローカル一時的セマンティックグラフストアは、本明細書では、セマンティッククエリ目的のために開示される。
図28は、リソースツリー内に分散型セマンティック記述子を伴う例示的セマンティッククエリを図示する。ステップ351では、セマンティックトリプルRETRIEVE動作を含む要求が、受信側332(すなわち、SE332)によって受信され得る。要求は、1)標的リソースのアドレスまたはID(例えば、Toアドレス)、2)発信側ID(例えば、AE IDまたはSE ID)、3)動作(例えば、RETRIEVE)、4)パラメータ(例えば、RequestID,ContentFormat(例えば、SPARQL),FilterCriteria(Semantic)、ResultContent)、または、5)コンテンツ(例えば、QuerySemanticTriples)を含み得る。ステップ352では、ステップ351の要求に基づいて、受信側332は、セマンティックトリプルRETRIEVE動作に関連付けられた処理を行い得る。受信側332は、リソースツリー間でセマンティック記述子発見を実施し得る。受信側332は、リソースツリー内のセマンティックトリプルRETRIEVE動作を確証し得る。例えば、各セマンティック記述子のための<accessControlPolicy>によって規定されたアクセス制御ポリシルールに基づいて、発信側335がリソースツリー内のセマンティック記述子を読み出すための権利を有することを決定する。受信側332は、FilterCriteriaが有効であるかどうかを決定し得る。RETRIEVE要求の確証成功に基づいて、受信側332は、発見されたセマンティック記述子を読み出し得る。受信側332は、読み出されたセマンティック記述子からセマンティックトリプルを抽出し、それらをローカル一時的セマンティックグラフストアの中に置き得る。SPARQL更新動作が、一時的セマンティックグラフストアをロードするために使用され得る。受信側332は、要求内に提供されない場合、セマンティッククエリコマンドを構築し得る(例えば、SPARQLクエリ言語で)。受信側332は、セマンティッククエリを標的クエリセマンティックトリプルおよびFilterCriteriaを用いて一時的セマンティックグラフストアにおいて実施し得る。受信側332は、一時的セマンティックグラフストア内のセマンティックトリプル(例えば、全て)を除去し得る。ステップ353では、受信側332は、メッセージを構成し、セマンティッククエリ結果とともに、発信側335に送信し得る。
本明細書では、一時的セマンティックグラフストアは、リソースツリーから発見されたセマンティック記述子から抽出されるセマンティックトリプルをリンクし、例えば、セマンティッククエリのための関係グラフを形成するために使用され得ることが想定される。この一時的セマンティックグラフストアは、各セマンティッククエリ後クリアされ、次いで、別のセマンティッククエリのために発見されたセマンティック記述子から抽出されるセマンティックトリプルの別のグループがロードされ得る。したがって、一時的セマンティックグラフストアは、各クエリ後、セマンティックトリプルを保持せず、クエリグラフを形成するセマンティックトリプルが、発信側がこの一時的セマンティックグラフストアと動作を有することが可能にされるトリプルのみであることを確実にし得る。
セマンティックグラフストアおよび階層リソースツリーの両方内にセマンティック記述子を伴うハイブリッドアーキテクチャが、本明細書において開示される。図29は、セマンティックグラフストアおよび階層リソースツリー内のセマンティック記述子のための例示的アーキテクチャを図示する。ハイブリッドアーキテクチャは、以下の特徴を有し得る。セマンティッククエリのために使用される集中管理セマンティックグラフストア360が、存在し得、それは、SE361(例えば、oneM2MにおけるCSE)上に常駐し得る。集中管理セマンティックグラフストア360は、リソースツリー364、リソースツリー365、またはリソースツリー366等の階層リソースツリー内に分散されたセマンティック記述子からのセマンティックトリプルを含み得る。リソースツリー364のセマンティック記述子368、リソースツリー365のセマンティック記述子369、またはリソースツリー366のセマンティック記述子370が、存在し得る。示されるように、セマンティックトリプルを含むセマンティック記述子は、複数のサービスエンティティ上の異なる階層リソースツリーに位置し得る。
図29を継続して参照すると、以下は、セマンティック記述子のための例示的オプションである。第1のオプションでは、リソースツリー内のセマンティック記述子は、セマンティックトリプルを含む実際リソースである。CREATE、RETRIEVE、UPDATE、またはDELETEの動作が、リソースツリー内の任意の他のタイプリソースに対する動作のように、リソースツリー内のセマンティック記述子に関して実施され得る。しかし、集中管理セマンティックグラフストア360内のセマンティックグラフは、リソースツリー内のセマンティック記述子に関して動作が実施される度に、それらのセマンティック記述子と同期させられ得る。集中管理セマンティックグラフストア360は、セマンティッククエリおよび他のセマンティック分析動作のために使用され得る。この第1のオプションは、分散型アプローチに近いと考えられ得る。
図29を継続して参照すると、第2のオプションでは、リソースツリー内のセマンティック記述子は、セマンティックトリプルを含まない仮想リソースであり得る。リソースツリー内の仮想リソースセマンティック記述子に関して実施されるCREATE、RETRIEVE、UPDATE、またはDELETEの動作は、集中管理セマンティックグラフストア360内での実際の動作をトリガし得る。集中管理セマンティックグラフストア360は、セマンティッククエリのためだけではなく、それは、セマンティックトリプルを記憶するためにも使用され得る。この第2のオプションは、集中管理アプローチに近いと考えられ得る。
図29を参照すると、アプリケーションエンティティ(例えば、AE367)は、リソースツリー(例えば、365)内のセマンティック記述子リソース(例えば、セマンティック記述子369)に関するCREATE、RETRIEVE、UPDATE、DELETE等のRESTful動作、ならびに集中管理セマンティックグラフストア360内のセマンティックトリプルに関するセマンティッククエリのために、インターフェースAS371、例えば、oneM2MにおけるMcaインターフェースを介して、サービスエンティティ(例えば、SE362)と通信し得る。ある例では、SE362は、リソースツリー(例えば、リソースツリー364)内のセマンティック記述子リソースに関するCREATE、RETRIEVE、UPDATE、DELETE等のRESTful動作、ならびに集中管理セマンティックグラフストア内のセマンティックトリプルに関するセマンティッククエリのために、インターフェースSS372、例えば、oneM2MにおけるMccまたはMcc’インターフェースを介して、別のSE363と通信し得る。第1のオプションでは、階層リソースツリー内のセマンティック記述子に関するCREATE、RETRIEVE、UPDATE、およびDELETE等のRESTful動作は、他のリソースツリー内のリソースに対する動作に類似する。第2のオプションに関して、集中管理セマンティックグラフストア360内のセマンティックトリプルに関するCREATE、RETRIEVE、UPDATE、およびDELETE等の動作は、集中管理アプローチに関して説明されるものに類似し、リソースツリー内の他のリソースに対する動作に類似する。
図30は、リソースツリー内のセマンティック記述子を用いたセマンティッククエリのための例示的方法を図示する。ステップ375では、受信側361(例えば、SE361)は、セマンティックトリプルRETRIEVE動作のための要求を受信し得る。ステップ376では、ステップ375の要求に基づいて、受信側361は、セマンティックトリプルRETRIEVE動作を処理し得る。受信側361は、セマンティック記述子発見を実施し得る。受信側361は、リソースツリー内のセマンティックトリプルRETRIEVE動作を確証し得る。これは、各セマンティック記述子のための<accessControlPolicy>によって規定されたアクセス制御ポリシルールに基づいて、発信側373がリソースツリー内で発見されたセマンティック記述子を読み出すための権利を有することを決定することを含み得る。加えて、FilterCriteriaが有効であるかどうか決定され得る。第1のオプションでは、RETRIEVE動作の確証成功に基づいて、受信側361は、リソースツリー内で発見されセマンティック記述子を読み出し得る。受信側361は、RETRIEVE動作の確証成功後、セマンティックトリプルのリストを用いてグラフ図を構築し得る。第1のオプションでは、受信側361は、読み出されるセマンティック記述子からセマンティックトリプルを抽出し、構築されたグラフ図とともに、それらをセマンティックグラフストア360の中に置き得る。受信側361は、要求内に提供されない場合、セマンティッククエリコマンドを構築し得る(例えば、SPARQLクエリ言語で)。受信側361は、セマンティックグラフストア内に構築された図において標的クエリセマンティックトリプルおよびFilterCriteriaを用いてセマンティッククエリを実施し得る。
ステップ377では、受信側361は、メッセージ(例えば、応答)を構築し、AE373に送信し得る。「グラフ図を用いたアクセス制御」スキームが、図30および本明細書の他の場所に例として示されるが、「<AccessControlTriples>を用いたアクセス制御」スキームも、第1のオプションまたは第2のオプションのために適用可能であり得ることに留意されたい。
分散型セマンティック記述子間の関係を可能にすることを可能にする代替アプローチが、本明細書において開示される。分散型記述をまたいだフィルタリングまたはクエリは、oneM2Mにおける従来のセマンティックフィルタリング提案に関して本明細書に説明される他のアプローチの代替を提供する。セマンティック記述がRDFトリプルフォーマットであっても、なくてもよいように、本明細書で議論される集中管理アプローチに行われる一般的仮定が適用されることに留意されたい。ここでは、セマンティックインスタンスによって作成されるグラフ全体に焦点が置かれ、したがって、トリプルの形態におけるセマンティックインスタンスの例示的使用が、開示される。用語「セマンティック記述子」または「セマンティックトリプル」(複数)は、任意のフォーマット(例えば、RDF)におけるセマンティック記述のために使用され得る。単一文、例えば、RDF−トリプルのための用語「セマンティックインスタンス」が、使用され得る。クエリは、例えば、SPARQLを介したRDFトリプルのために例示され得る。
このアプローチにおいて対処される分散型アーキテクチャは、以下の特徴を有し得る。セマンティック記述子は、単一サービスエンティティ上の異なる階層リソースツリー上のリソースをまたいで位置し得る。いくつかのサービスエンティティをまたいだセマンティック動作のための要求は、個々のサービスエンティティにルーティングされる要求に分割され得、ここで対処されるセマンティック動作は、アドレスされるサービスエンティティ内に分散された記述子を標的化する。アプリケーションエンティティ(AE)、例えば、oneM2MにおけるAEは、リソースツリー内のセマンティック記述子リソースに関するCREATE、RETRIEVE、UPDATE、DELETE等のRESTful動作のために、インターフェースAS、例えば、oneM2MにおけるMcaインターフェースを介して、SEと通信し得る。SEは、リソースツリー内のセマンティック記述子リソースに関するCREATE、RETRIEVE、UPDATE、DELETE等のRESTful動作のために、インターフェースSS、例えば、oneM2MにおけるMccまたはMcc’インターフェースを介して、別のSEと通信し得る。セマンティッククエリのために使用される一時的セマンティックグラフストアは、サービスエンティティ(SE)、例えば、oneM2MにおけるCSE上に常駐し、階層リソースツリー内に分散されたセマンティック記述子から抽出されるセマンティックトリプルを含み得る。このアーキテクチャでは、oneM2Mにおける従来のアクセス制御ポリシに関して説明されるようなセキュリティおよびプライバシの問題が、アクセス制御ポリシを介して解決され得ることに留意されたい。セマンティック記述子は、各CRUD動作に対してそれらにアクセスし得るエンティティをそれが決定するリソースレベルのポリシを有する。
重要な問題は、サービスエンティティ内で利用可能な可能性として大量のリソースのセマンティック記述子をクリエすることにあり得る。以下に議論されるもの等のいくつかの選択肢が存在する。第1の選択肢は、SEツリー全体にわたって(例えば、リソースツリーのベース(例えば、oneM2MにおけるCSEBase)を標的化するかのように各クエリを処理する)、SE内の全てのセマンティック記述子が各クエリに関連するかのように、各クエリを処理することを含み得る。これは、非効率的検索方法と考えられ得る。第2の選択肢は、動作標的のセマンティック記述子を考慮して、各クエリを処理することを含み得る。oneM2Mにおける従来のセマンティックフィルタリング提案に関して説明されるケースに対して。これは、<device12>に向けられるクエリが<operationX>において利用可能なセマンティック記述子情報を全く使用しないことにつながり得る。第3の選択肢は、本明細書で議論されるoneM2Mにおける従来のセマンティックフィルタリング提案に説明されるresourceDescriptionLink方法を使用して、各クエリを処理することを含み得る。この場合、2つ以上の共通概念を含む2つの(またはそれを上回る)記述子が、同一2つの記述子間に確立されるいくつかのリンクにつながり得る。手続型記述に基づいて、新しいリンクが遭遇されるであろう度に、クエリ動作を処理するエンティティは、対応するセマンティック記述子(この場合、operation X)をフェッチするであろう。これは、同一記述子の複数の読み出しをもたらすであろう。加えて、読み出しは、記述子コンテンツのセマンティック理解に基づいて処理され得る。第4の選択肢は、意味上関連する記述子の組にわたって各クエリを処理することを含み得る。組は、クエリ効率と正確度を引き換えにするであろうポリシに基づいて、より大きくまたはより小さくされ得る。以下に説明される方法は、このカテゴリに属する。それは、インスタンスまたは記述を置くべき場所(リソースツリーレベル)を把握しているので、セマンティックインスタンスまたはサブグラフとその他との関連に関する、注釈時に利用可能な知識を使用する利点を有する。
図31は、従来行われるような同じ記述子間の複数のresourceDescriptionLinkの問題を図示する。本開示では、関連コンテンツを伴うセマンティック記述子は、提供されるリンクがセマンティック記述子のセマンティックインスタンス内に埋め込まれた関連概念間にある、「oneM2Mにおけるセマンティックフィルタリング提案」の節で議論されるようなソリューションとは対照的に、互いへのリンクを提供され得る。具体的には、関連セマンティック記述子へのリンクを提供するために、新しい属性(例えば、relatedSemantics)が、セマンティック記述子リソースに追加されることが開示される。
oneM2Mコンテキストにおけるセマンティック記述子リソースの例を使用すると、relatedSemantics属性を図示する図32に示されるように、属性relatedSemanticsが、<semanticDescriptor>リソースに追加される。
本明細書で議論されるリンクのリストおよびリンクのグループに関して説明されるようなrelatedSemantics属性のために想定され得る複数の実装が存在する。第1の実装では、relatedSemantics属性は、関連セマンティック記述子への個々のリンクのリストを含み得る。第2の実装では、relatedSemantics属性は、グループを指し示す。このオプションに対して、<semanticGroup>リソースが、本明細書に開示されるが、しかしながら、汎用<group>リソースも、この目的のために使用され得る。
このコンテキストでは、「関連」セマンティック記述子の概念が、以下の意味を有し得ることに留意されたい:セマンティッククエリの目的のために、より大きいグラフを形成するためにそれらが一緒に使用されるべき場合、2つ以上のセマンティック記述子が関連させられる。本明細書では、初期主語ベースのスキームに基づく第1の例と、恣意的グラフベースのスキームを使用する第2の例とが提供され、恣意的グラフベースのスキームは、関連セマンティック記述子を生成するためのスキーム、例えば、セマンティック記述子が関連させられることを決定し、対応するリンクを提供するためのスキームを提供する。本明細書に導入される記述子間リンクを提供する方法は、特定のステムが、2つ以上のセマンティック記述子が関連することを最終的に決定するアルゴリズムを実装するために選定する方法から独立して考慮され得ることに留意されたい。
oneM2M分散型グラフの以下の例(同様に、本明細書で議論されるoneM2Mにおける従来のセマンティックフィルタリング提案に関連付けられる)が、以下で使用されるであろう。この例では、独立したリソース内に記憶されるグラフは、互いに関連する情報を含む:第1のグラフからのOperationAは、第2の記述子にさらに記述され、関係exposesCommandおよび目的語commandKが、両方内に含まれる。さらなるグラフ記述(第1のグラフ内の主語commandKを伴い、リソースOperationA記述子に関連する追加の潜在的トリプル等)が、この場合、グラフ間の追加の依存性を作成し得る。
図33は、異なるセマンティック記述子をまたいで分散される例示的グラフを図示する。ある例では、以下のフィルタ要求が存在し得る:「その出力が温度側面を定量化する動作を有するサービスを有する全てのデバイスを見つけ、出力=OutputXおよびコマンド=commandKを伴うそれらに対して、それをフィルタリングする」。
以下は、要求の対応するSPARQL表現である。
SELECT?device
WHERE{ ?devicerdf:typebase:Device.
?devicebase:hasService?service.
?servicebase:hasOperation?operation.
?operationbase:hasOutput?output.
?outputbase:quantifiestemp:TemperatureAspect.
?devicebase:exposesCommand?command.
FILTER(?output==OutputX&&?command==commandK)
}
目標は、図34に示されるように、SPARQLクエリを評価するために提示されるべきより大きい結果として生じるグラフの作成を可能にすることである。
この実装では、relatedSemantics属性は、セマンティッククエリを行うために、所与の<semanticDescriptor>リソース内の記述子とともに使用されるべき他のリソースに関連付けられた記述子を指し示すリンクのリストを含む。
図35は、リンクのリストを伴うrelatedSemantics属性の例示的使用である。これは、より限定数のセマンティック記述子が関連し、リンクリストを短くするときに提示されるもののようなケースにおいて有用である。このオプションをさらに簡略化するために、標準化ルールが、子リソースの全てのセマンティック記述子が、デフォルトで関連すると見なされことを規定し得ることが想定され得、それは、全ての子リソース記述子(存在する場合)が、クエリが親に向けられる場合、親に自動的に追加されるべきことを意味する。このように、親のrelatedSemantics属性は、子の全ての記述子へのリンクを含む必要はない。
この実装では、relatedSemantics属性は、図36におけるように、新しく開示されるリソース<semanticGroup>を指し示すリンクを含む。semanticGroupLinksは、セマンティッククエリを行うとき、一緒に使用されるべき記述子を識別するために使用される。個々のセマンティックリソースのrelatedSemantics属性は、直接、<semanticGroup>リソース、semanticGroupLinks属性のいずれかを指し示すか、または関連付けられたsemanticGroupIDを示し得る。上記例では、<semanticGroup>リソースは、合成グラフを<Device12>および<動作A>リソースをまたいで分散させるときに形成され得る。このリソースに対して、semanticGroupID、例えば、56が、配分され得、semanticGroupLinks属性は、関連セマンティック記述へのリンクのリストを含み得、例えば、リンクは、<Device12>および<動作A>を指し示す。他の実装では、リンクは、代わりに、それぞれの<semanticDescriptor>リソースの記述子属性の各々に、または子<semanticDescriptor>リソース自体を指し示し得る。図37は、<semanticGroup>を用いた例示的使用またはrelatedSemantics属性である。
分散型セマンティック記述子間の関係リンクを生成および維持する。分散型セマンティック記述子アーキテクチャは、セマンティック技術を利用するプラットフォーム機能性の可用性に依拠し得る。これは、CRUD動作を使用してセマンティック記述子を提供するセマンティック対応プラットフォーム機能性が存在することを意味する。同様に、CRUD動作は、セマンティックインスタンスの更新を行うことを含む、これらの記述子を管理するために使用され得る。これらの注釈機能性の総合したものは、セマンティック注釈機能と見なされ得る。
リソースを生成する機能が、本明細書で議論され、リソースを生成する機能において、注釈機能性が、生成されたリソースが記憶されるべき場所、アクセス制御属性が設定されるべき方法等についてルールおよびポリシを有し得る。
以下は、関係維持スキームの例であり、それは、セマンティック記述子リンクの提案される方法が使用され得る方法を例示するために、注釈生成プロセスにおいて使用され得る。
前節における例は、リソース<Device12>および<動作A>に注釈を付けるために、図33に示されるように、図34におけるより大きいグラフを使用したセマンティック注釈機能に依拠している。これは、グラフの処理の論理表現である。具体的実装では、このグラフの処理は、ローカル一時的または恒久的トリプルストアを利用し得る。これは、トリプルストアが、ローカルにあり、サービスエンティティ間で共有される必要がないので、本明細書で議論されるハイブリッドアプローチと異なり得る。
しかしながら、セマンティック注釈機能は、作成された種々のセマンティック記述子間にリンクを生成し、同時に、それがサブグラフおよび注釈を生成する、relatedSemantics属性を追加するためにも使用され得る。
以下の説明は、例として、oneM2Mベースオントロジー(図8)を使用する。セマンティック注釈エンジンは、このオントロジーを使用して、RDFで表される図34におけるグラフを作成する。示されるテキストは、記述子内の正確なRDFシンタックスのためにフォーマットされておらず、むしろ、全体的グラフの概念表現であることに留意されたい。
初期主語ベースのスキームに基づく例が、以下に提供される。このスキームでは、各rdf:記述は、対応するリソースのセマンティック記述子内に記憶され、故に、「主語ベースのスキーム」として指定される。このアプローチを用いて、その目的語が別のリソースであるトリプルを形成または更新するとき、注釈エンジンは、同様に、同じ<semanticDescriptor>リソース内のrelatedSemantics属性の中にエントリを作成する。
図37の例示的グラフを使用すると、リソース<Device12>に関連付けられた<semanticDescriptor>子リソースの記述子およびrelatedSemantics属性は、図39に示されるようになるであろう。この場合、グラフは、<Device12>、<動作A>リソース、ならびに<Service23>および<動作X>をまたいで分散されることに留意されたい。最後の3つのリソースのための対応するRDFは、対応する記述を隔離することによって、図38から容易に抽出されることができる。
relatedSemantics属性を<Device12>の<semanticDescriptor>リソース内に追加するためのリンクの方法リストを採用する場合、図40に示されるような以下のリストが、生成されるであろう。図40は、リンクの方法リストが使用されるときのrelatedSemantics属性の例である。
リンクのグループ方法を採用する場合、<Device12>のsemanticDescriptorリソース内のrelatedSemantics属性は、対応する<semanticGroup>リソースを指し示し得る。実際、<Service23>、<動作A>、および<output>のsemanticDescriptorリソース内のrelatedSemantics属性は、同一対応する<semanticGroup>リソースを指し示す。<semanticGroup>リソース内では、semanticGroupLinks属性は、図41に示されるように、リンクのリストを含み得る。図41は、リンクのグループ方法が使用されるときのsemanticGroupLinks属性の例である。
恣意的グラフベースのスキームを使用する例。恣意的グラフベースのスキームを使用することは、恣意的グラフがリソースのセマンティック記述子内に記憶されることを可能にし、それは、oneM2M仕様における現在の仮定である。このアプローチは、全体的グラフの個々の部分が記憶されるべき場所の決定に関して、任意の論理が注釈エンジンの実装において使用されることを可能にする。
これは、分散型セマンティック記述子間の関係を可能にするための議論に関連付けられた例と大まかに関連付けられ、各<Device12>および<動作A>内に記憶されるグラフは、2つのリソースと異なる主語を伴うトリプルを含む。しかしながら、この例では、各リソースは、それ自体の記述内のそれ自体に関連するトリプルを含み得、したがって、グラフ選択肢は、完全に恣意的ではないことに留意されたい。
この例に対して、図38におけるRDFで記述される合成グラフは、色、数、またはある他の機構を使用して、それぞれ、<Device12>および<動作A>の記述子内に記憶されることが決定される情報を表し得る。括弧101におけるラインは、両場所内に記憶されるトリプルを示す。示されるテキストは、記述子内の正確なRDFシンタックスのためにフォーマットされておらず、むしろ、全体的グラフならびに各記述子内に捕捉されたトリプルの概念表現であることに留意されたい。
この例では、リソース<Device12>および<動作A>に関連付けられたセマンティック記述子は、図42および図43に示されるようになるであろう。図42は、恣意的グラフベースのスキーム内の<Device12>のための例示的セマンティック注釈である。図43は、恣意的グラフベースのスキーム内の例示的<動作A>注釈である。
このケースにおいて、リンクの方法リストを採用する場合、<Device12>および<動作A>のrelatedSemantics属性は、互いを指し示すであろう。これは、セマンティッククエリが記述子のうちの1つにわたって行われるとき、その他も、クエリ目的のためにグラフを完成するために読み出されるべきであることを示すであろう。
リンクのグループ方法を採用する場合、<Device12>および<動作A>の両方のrelatedSemantics属性は、同一<semanticGroup>リソースを指し示し、semanticGroupLinks属性は、図44に示されるリンクのリストを含むであろう。図44は、リンクのグループ方法が使用されるときの例示的semanticGroupLinks属性である。
セマンティック記述子間の関係の維持は同様に、スキームを生成する注釈エンジンによって行われ、それは、同様に、記述子間の「関連」関係が確立された方法から独立する。ここでは、「主語ベースのスキーム」および「恣意的グラフベースのスキーム」等の例示的スキームが存在する。主語ベースのスキームに関し、同じ記述子内のトリプルは、同じ主語を有し、主語は、親リソースである。恣意的スキームでは、トリプルは、主語によってではなく、恣意的に記憶されることができる。
維持方法は、グループアプローチに対してより単純である。記述子が作成、更新、または削除され、それによって、関係が変化するとき、特に、関連記述子のより大きいグループに対して、主に、<semanticGroup>リソース内で更新が生じるからである。対照的に、リンクのリスト実装における関係の維持は、いくつかの記述子のみが関連するときに最適である。
relatedSemantics属性によって接続されるいくつかのリソースをまたいで記憶されるセマンティック記述におけるセマンティックフィルタリングを可能にするために、<semanticGroup>リソースの使用にかかわらず、セマンティッククエリエンジンは、図45のステップを使用し得る。図45は、relatedSemanticsアプローチを使用したセマンティッククエリのための例示的方法を図示する。ステップ381では、受信側152は、requestパラメータを確証することによって、受信されたRETRIEVE要求を処理する(ステップ380)。このインスタンスでは、ステップ380から開始するRETRIEVE要求が、ここでは議論されるが、他のセマンティックリソース発見も、概して、適用可能である。ステップ382では、受信側152は、対応するフィールド内のアドレス指定されたリソースに関連付けられたセマンティック記述子を発見する。semanticDescriptor自体は、relatedSemanticsと呼ばれる属性を有し得、それは、得るべき他の記述子を識別する。ステップ383では、受信側152は、発信側151がメッセージ標的(例えば、セマンティック記述子)のRETRIEVE権利を有することを検証し、次いで、記述子およびrelatedSemantics属性を抽出する。メッセージ標的の権利が存在しない場合、対応するリターンコードが、生成される。セマンティック記述子のコンテンツは、ローカルに保存され得、それは、ドキュメントとして、またはローカルもしくは一時的グラフストア内にあり得る。ドキュメントは、図42におけるように、セマンティック記述子の表現である。グラフストアは、図25のようなものである。関連セマンティクスが、読み出されるべき他のセマンティック記述子のリスト(すなわち、組)を生成するために使用され得る。このリストは、直接、またはrelatedSemantics属性によって指し示された<semanticGroup>リソースにアクセスすることによって、提供され得る。発信側151が、<semanticGroup>にRETRIEVE権利を有していない場合、他の記述子は、集められない。
図45を継続して参照すると、ステップ384では、受信側152は、前のステップにおいて生成された関連記述子のリストを使用し得る。受信側152は、アクセス制御ルールに従って、それぞれの記述子属性の各々のコンテンツを読み出す。アクセスされることが可能にされる場合、リンクされた<semanticDescriptor>リソースの記述子属性の各々のコンテンツが、SPARQL要求が実行されているコンテンツに追加される。SPARQL要求に従う完全または拡大コンテンツが、処理のためにSPARQLエンジンに提供される。ステップ385では、受信側152は、提供されたセマンティッククエリコマンド(または他のセマンティックリソース発見)を結果として生じるグラフに対して実施する。ステップ386では、受信側152は、セマンティッククエリに対する応答を構成する。ステップ387では、ローカルグラフストアが使用されている場合、受信側は、ローカルルールおよびポリシに基づいて、生成されたグラフを維持または削除し得る。
セマンティックフィルタリングまたは発見のための開示されるアプローチの技術的効果は、以下を含み得る:1)要求されるセマンティック情報が、見出され得る。2)リソースベースのアクセス制御が、いくつかのインスタンスでは、より容易に施行され得る。情報が動作の実行時にアクセスされ、要求側のアクセス権が適用され得るからである。3)SPARQLエンジンによって処理されるべきコンテンツが、処理に先立って収集され、それは、外部の非oneM2M規定セマンティッククエリエンジンの使用を可能にし得る。または、4)2つ以上の共通概念を含む記述子が、1つのみのリンクによってリンクされ、それは、重複コンテンツが要求処理のために考慮されることのより容易な回避を可能にし得る。
「分散型セマンティック記述子間の関係の有効化」に関連付けられた例を使用して、合成グラフ(図34)が、上記のステップ(例えば、図45)を使用して構築され、処理のために、SPARQLエンジンに提供される。SPARQLエンジンは、グラフを一時的に記憶するために、ローカルトリプルストアを使用し得、その場合、それは、ハイブリッドアプローチにつながり得る。
以下に議論されるのは、<semanticGroup>に基づく例である。分散型セマンティック記述子の実装を前提として、以下に導入されるような拡張<semanticGroup>リソースが、記述子間の関係の維持だけではなく、それは、セマンティックフィルタリング動作のさらなる効率化も提供し得る。
図46は、拡張<semanticGroup>リソースの例を図示する。拡張は、リソース<semanticFanOutPoint>の導入を含み、それは、仮想リソースであり、<semanticGroup>リソースが個々のリソースの代わりに、セマンティッククエリの標的となることを可能にし得る。これは、クエリ発信側(例えば、発信側151)が、前の発見に基づいて、リソースツリーの理解を有するとき、有用となる層を追加し得る。クエリを<semanticGroup>リソースの<semanticFanOutPoint>にアドレス指定することによって、技術的効果は、受信側152におけるセマンティックエンジンが、グループ全体に関連付けられた合成グラフをより容易に維持および検索し得る結果をもたらし得ることである。ローカルトリプルストアストレージ、キャッシュ等は、より高速結果のために、受信側におけるセマンティックエンジン内のクエリの処理をより効率的にさらにし得る。加えて、<semanticGroup>リソースは、異なるSEに属するリソースに対するクエリを標的化するために使用され得る。第1のSE上に常駐する<semanticGroup>リソースが、第2のSEおよび第3のSE上のメンバリソースを含む場合、RETRIEVE動作は、第2のSEおよび第3のSE上の対応するリソースにファンアウトされ得る。次いで、クエリは、上で説明されるように、個々のSE内で処理され得る。
<semanticGroup>リソースを使用するときの別の拡張は、セマンティック記述子内に含まれる各グラフのためのグラフ名の使用のための命令を提供することによって行われ得、例えば、作成された各セマンティック記述子は、名前が付けられ得、一意の名前が、それに割り当てられるべきである。加えて、グラフ名が記述子の場所に関連付けられることも提供され得る。命名は、階層であり得、それによって、グループ内の全てのグラフが一緒にアドレス指定され得るか、または、割り当てられた名前は、互いに独立し得る。いずれの場合も、新しい属性グループグラフ名が、リストまたはルート名のいずれかを介して、グループ内のグラフのための名前を提供するために使用され得る。
この方法の技術的効果は、それらを可能な限り具体的または広範にすることによって、セマンティック動作の発信側により優れた粒度を提供することであり得る。受信側では、セマンティックエンジンは、より効率的であり得、それによって、<semanticFanOutPoint>にアドレス指定されるがSPARQLペイロードが特定のグラフを示すクエリ要求を受信する場合、エンジンは、グラフ名とsemanticGroupLinks内に提供されるリンクとの間の関係を使用して、所与のグラフに関連付けられた記述子のみにアドレスする。
図4に示されるoneM2Mアーキテクチャを想定すると、セマンティックグラフストアおよびセマンティック保管マネージャは、CSFセマンティック内に常駐し得、リソースツリーおよびデータ保管マネージャは、CSFデータ管理およびリポジトリ内に常駐し得る。図47は、oneM2Mを考慮したセマンティックグラフストアを伴う例示的アーキテクチャを図示する。図48は、oneM2Mを使用した開示される方法のための例示的リソースツリーを図示する。図48に示されるように、新しいリソース<SemanticGraphStore>が、<CSEbase>下に追加される。ある例では、異なるsemanticDescriptorリソースのrelatedSemantics属性は、<semanticGroup>を指し示し、関連する記述子を示し得る。それが行われると、グループのsemanticFanOutPointが、全ての関連記述子に関するセマンティック動作を送信するために使用され得る。
図50は、本明細書で議論される方法およびシステムに基づいて生成され得る、例示的ディスプレイ(例えば、グラフィカルユーザインターフェース)を図示する。ディスプレイインターフェース901(例えば、タッチスクリーンディスプレイ)は、ブロック902に、本明細書に議論されるようなアクセス制御を用いたeヘルスセマンティッククエリ等のセマンティックIoTのためのRESTful動作に関連付けられたテキストを提供し得る。別の例では、本明細書で議論されるステップのいずれかの進行度(例えば、送信されたメッセージまたはステップの成功)が、ブロック902に表示され得る。加えて、グラフィカル出力903が、ディスプレイインターフェース901上に表示され得る。グラフィカル出力903は、セマンティックグラフィックストアのトポロジ、本明細書で議論される任意の方法またはシステム(例えば、とりわけ、図18−図21)の進行度のグラフィカル出力等であり得る。図53Aから図53Cは、ディスプレイインターフェース901上に存在し得る、出力を図示する。ダウンロードフォーマットを選定するためのオプションとともに、クエリ結果が存在し得る。示されるように、Svalue、Dvalue、セマンティック記述子、およびサンプルが、例に提供され、対応する結果が、図53Aから図53Cに示され得る。
図51Aは、セマンティックIoTのためのRESTful動作に関連付けられた1つ以上の開示される概念(例えば、図16−図49Cおよび図54)が実装され得る例示的マシンツーマシン(M2M)、モノのインターネット(IoT)、またはモノのウェブ(WoT)通信システム10の略図である。概して、M2M技術は、IoT/WoTのための構築ブロックを提供し、任意のM2Mデバイス、M2Mゲートウェイ、またはM2Mサービスプラットフォームは、IoT/WoTのコンポーネントならびにIoT/WoTサービス層等であり得る。
図51Aに示されるように、M2M/IoT/WoT通信システム10は、通信ネットワーク12を含む。通信ネットワーク12は、固定ネットワーク(例えば、Ethernet(登録商標)、Fiber、ISDN、PLC等)または無線ネットワーク(例えば、WLAN、セルラー等)、もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク12は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する複数のアクセスネットワークから成り得る。例えば、通信ネットワーク12は、符号分割多重アクセス(CDMA)、時分割多重アクセス(TDMA)、周波数分割多重アクセス(FDMA)、直交FDMA(OFDMA)、単一キャリアFDMA(SC−FDMA)等の1つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク12は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。
図51Aに示されるように、M2M/IoT/WoT通信システム10は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインとは、エンドツーエンドM2M展開のネットワーク側を指し、フィールドドメインとは、通常はM2Mゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインは、M2Mゲートウェイ14と、端末デバイス18とを含む。任意の数のM2Mゲートウェイデバイス14およびM2M端末デバイス18が、所望に応じてM2M/IoT/WoT通信システム10に含まれ得ることが理解されるであろう。M2Mゲートウェイデバイス14およびM2M端末デバイス18の各々は、通信ネットワーク12または直接無線リンクを介して、信号を伝送および受信するように構成される。M2Mゲートウェイデバイス14は、無線M2Mデバイス(例えば、セルラーおよび非セルラー)ならびに固定ネットワークM2Mデバイス(例えば、PLC)が、通信ネットワーク12等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、M2Mデバイス18は、データを収集し、通信ネットワーク12または直接無線リンクを介して、データをM2Mアプリケーション20またはM2Mデバイス18に送信し得る。M2Mデバイス18はまた、M2Mアプリケーション20またはM2Mデバイス18からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、M2Mサービスプラットフォーム22を介して、M2Mアプリケーション20に送信され、そこから受信され得る。M2Mデバイス18およびゲートウェイ14は、例えば、セルラー、WLAN、WPAN(例えば、Zigbee(登録商標)、6LoWPAN、Bluetooth(登録商標))、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。
図51Bを参照すると、フィールドドメイン内に例証されるM2Mサービス層22は、M2Mアプリケーション20(例えば、eヘルスケアアプリ)、M2Mゲートウェイデバイス14、ならびにM2M端末デバイス18および通信ネットワーク12のためのサービスを提供する。M2Mサービスプラットフォーム22は、所望に応じて、任意の数のM2Mアプリケーション、M2Mゲートウェイデバイス14、M2M端末デバイス18、および通信ネットワーク12と通信し得ることが理解されるであろう。M2Mサービス層22は、1つ以上のサーバ、コンピュータ等によって実装され得る。M2Mサービス層22は、M2M端末デバイス18、M2Mゲートウェイデバイス14、およびM2Mアプリケーション20に適用されるサービス能力を提供する。M2Mサービス層22の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。
図示したM2Mサービス層22と同様に、インフラストラクチャドメイン内にM2Mサービス層22’がある。M2Mサービス層22’は、インフラストラクチャドメイン内のM2Mアプリケーション20’および下層通信ネットワーク12’のためのサービスを提供する。M2Mサービス層22’はまた、フィールドドメイン内のM2Mゲートウェイデバイス14およびM2M端末デバイス18のためのサービスも提供する。M2Mサービス層22’は、任意の数のM2Mアプリケーション、M2Mゲートウェイデバイス、およびM2M端末デバイスと通信し得ることが理解されるであろう。M2Mサービス層22’は、異なるサービスプロバイダによってサービス層と相互作用し得る。M2Mサービス層22’は、1つ以上のサーバ、コンピュータ、仮想マシン(例えば、クラウド/計算/記憶ファーム等)等によって実装され得る。
図51Bをさらに参照すると、M2Mサービス層22および22’は、多様なアプリケーションおよびバーティカルが活用することができるサービス配信能力のコア組を提供する。これらのサービス能力は、M2Mアプリケーション20および20’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス/デバイス発見等の機能を果たすことを可能にする。これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層22および22’はまた、M2Mアプリケーション20および20’が、サービス層22および22’が提供するサービスと関連して、種々のネットワーク12および12’を通して通信することも可能にする。
いくつかの例では、M2Mアプリケーション20および20’は、本明細書に議論されるようなセマンティックIoTのためのRESTful動作を使用して通信する所望のアプリケーションを含み得る。M2Mアプリケーション20および20’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、システムのデバイス、ゲートウェイ、および他のサーバを経由して作動するM2Mサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡/ジオフェンシング、デバイス/サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をM2Mアプリケーション20および20’に提供する。
本願のセマンティックIoTのためのRESTful動作は、サービス層の一部として実装され得る。サービス層は、アプリケーションプログラミングインターフェース(API)および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。M2Mエンティティ(例えば、ハードウェアおよびソフトウェアの組み合わせによって実装され得るデバイス、ゲートウェイ、またはサービス/プラットフォーム等のM2M機能エンティティ)は、アプリケーションまたはサービスを提供し得る。ETSI M2MおよびoneM2Mは両方とも、本願のセマンティックIoTのためのRESTful動作を含み得るサービス層を使用する。ETSI M2Mのサービス層は、サービス能力層(SCL)と称される。SCLは、M2Mデバイス(デバイスSCL(DSCL)と称される)、ゲートウェイ(ゲートウェイSCL(GSCL)と称される)、またはネットワークノード(ネットワークSCL(NSCL)と称される)内で実装され得る。oneM2Mサービス層は、共通サービス機能(CSF)(すなわち、サービス能力)の組をサポートする。1つ以上の特定のタイプのCSFの組のインスタンス化は、異なるタイプのネットワークノード(例えば、インフラストラクチャノード、中間ノード、特定用途向けノード)上でホストすることができる共通サービスエンティティ(CSE)と称される。さらに、本願のセマンティックIoTのためのRESTful動作は、本願のセマンティックIoTのためのRESTful動作等のサービスにアクセスするために、サービス指向アーキテクチャ(SOA)および/またはリソース指向アーキテクチャ(ROA)を使用する、M2Mネットワークの一部として実装されることができる。
本明細書に議論されるように、サービス層は、ネットワークサービスアーキテクチャ内の機能的層であり得る。サービス層は、典型的には、HTTP、CoAP、またはMQTT等のアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層はまた、インターフェースを、例えば、制御層およびトランスポート/アクセス層等の下位リソース層におけるコアネットワークに提供する。サービス層は、サービス定義、サービスランタイム有効化、ポリシ管理、アクセス制御、およびサービスクラスタリングを含む(サービス)能力または機能性の複数のカテゴリをサポートする。最近、いくつかの産業規格団体、例えば、oneM2Mが、インターネット/ウェブ、セルラー、企業、およびホームネットワーク等の展開へのM2Mタイプのデバイスならびにアプリケーションの統合に関連付けられた課題に対処するためのM2Mサービス層を開発している。M2Mサービス層は、アプリケーションおよび/または種々のデバイスに、CSEもしくはSCLと称され得るサービス層によってサポートされる前述の能力または機能性の集合もしくは組へのアクセスを提供することができる。いくつかの例として、限定ではないが、種々のアプリケーションによって一般に使用され得るセキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理が挙げられる。これらの能力または機能性は、M2Mサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用するAPIを介して、そのような種々のアプリケーションに利用可能となる。CSEまたはSCLは、それらにそのような能力もしくは機能性を使用するために、ハードウェアおよび/もしくはソフトウェアによって実装され得、種々のアプリケーションならびに/もしくはデバイスにエクスポーズされる(サービス)能力または機能性を提供する、機能エンティティ(すなわち、そのような機能エンティティ間の機能インターフェース)である。
図51Cは、例えば、M2M端末デバイス18(例えば、AE367、AE335、または発信側151)またはM2Mゲートウェイデバイス144(例えば、SE361または受信側152)等の例示的M2Mデバイス30の系統図である。図51Cに示されるように、M2Mデバイス30は、プロセッサ32と、送受信機34と、伝送/受信要素36と、スピーカ/マイクロホン38と、キーパッド40と、ディスプレイ/タッチパッド42と、非取り外し可能メモリ44と、取り外し可能メモリ46と、電源48と、全地球測位システム(GPS)チップセット50と、他の周辺機器52とを含み得る。M2Mデバイス30は、開示される主題と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。M2Mデバイス30(例えば、サービスエンティティ163、図22の受信側および図22の発信側161、図47のMN−CSE、図29のアプリケーションエンティティ373、図47のIN−CSE、およびその他)は、セマンティックIoTのためのRESTful動作のための開示されるシステムおよび方法を行う、例示的実装であり得る。
プロセッサ32は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアと関連する1つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、任意の他のタイプの集積回路(IC)、状態マシン等であり得る。プロセッサ32は、信号符号化、データ処理、電力制御、入出力処理、および/またはM2Mデバイス30が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ32は、伝送/受信要素36に結合され得る送受信機34に結合され得る。図51Cは、プロセッサ32および送受信機34を別個のコンポーネントとして描写するが、プロセッサ32および送受信機34は、電子パッケージまたはチップに一緒に組み込まれ得ることが理解されるであろう。プロセッサ32は、アプリケーション層プログラム(例えば、ブラウザ)および/または無線アクセス層(RAN)プログラムおよび/または通信を実施し得る。プロセッサ32は、例えば、アクセス層および/またはアプリケーション層等で、認証、セキュリティキー一致、および/または暗号化動作等のセキュリティ動作を実施し得る。
伝送/受信要素36は、信号をM2Mサービスプラットフォーム22に伝送し、またはM2Mサービスプラットフォーム22から信号を受信するように構成され得る。例えば、伝送/受信要素36は、RF信号を伝送および/または受信するように構成されるアンテナであり得る。伝送/受信要素36は、WLAN、WPAN、セルラー等の種々のネットワークおよびエアインターフェースをサポートし得る。例では、伝送/受信要素36は、例えば、IR、UV、または可視光信号を伝送および/または受信するように構成されるエミッタ/検出器であり得る。さらに別の例では、伝送/受信要素36は、RFおよび光信号の両方を伝送および受信するように構成され得る。伝送/受信要素36は、無線または有線信号の任意の組み合わせを伝送および/または受信するように構成され得ることが理解されるであろう。
加えて、伝送/受信要素36は、単一の要素として図51Cで描写されているが、M2Mデバイス30は、任意の数の伝送/受信要素36を含み得る。より具体的には、M2Mデバイス30は、MIMO技術を採用し得る。したがって、例では、M2Mデバイス30は、無線信号を伝送および受信するための2つ以上の伝送/受信要素36(例えば、複数のアンテナ)を含み得る。
送受信機34は、伝送/受信要素36によって伝送される信号を変調するように、および伝送/受信要素36によって受信される信号を復調するように構成され得る。上記のように、M2Mデバイス30は、マルチモード能力を有し得る。したがって、送受信機34は、M2Mデバイス30が、例えば、UTRAおよびIEEE802.11等の複数のRATを介して通信することを可能にするための複数の送受信機を含み得る。
プロセッサ32は、非取り外し可能メモリ44および/または取り外し可能メモリ46等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ44は、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ46は、サブスクライバ識別モジュール(SIM)カード、メモリスティック、セキュアデジタル(SD)メモリカード等を含み得る。他の例では、プロセッサ32は、サーバまたはホームコンピュータ上等のM2Mデバイス30上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ32は、本明細書に説明される例のうちのいくつかにおけるステップが成功もしくは不成功である(例えば、セマンティックtripleCREATE動作要求またはセマンティックtripleRETRIEVE動作要求等)に応答して、ディスプレイもしくはインジケータ42上の照明パターン、画像、または色を制御する、または別様に、本明細書に議論される、セマンティックIoTのためのRESTful動作のステータスおよび関連付けられたコンポーネントを示すように構成され得る。ディスプレイまたはインジケータ42上の照明パターン、画像、もしくは色の制御は、図に図示される、または本明細書で議論される(例えば、図16−図49Cおよび図52−図54ならびに本明細書の同等物)方法フローもしくはコンポーネントのいずれかのステータスを反映し得る。本明細書に開示されるのは、セマンティックIoTのためのRESTful動作のメッセージおよびプロシージャである。メッセージおよびプロシージャは、インターフェース/APIを提供するように拡張され、ユーザが、入力ソース(例えば、スピーカ/マイクロホン38、キーパッド40、またはディスプレイ/タッチパッド42)を介して、リソース関連リソースを要求し、とりわけ、ディスプレイ42上に表示され得る、セマンティックIoTのためのRESTful動作を要求、構成、またはクエリすることができる。
プロセッサ32は、電源48から電力を受け取り得、M2Mデバイス30内の他のコンポーネントへの電力を分配および/または制御するように構成され得る。電源48は、M2Mデバイス30に電力供給するための任意の好適なデバイスであり得る。例えば、電源48は、1つ以上の乾電池バッテリ(例えば、ニッケルカドミウム(NiCd)、ニッケル亜鉛(NiZn)、ニッケル水素(NiMH)、リチウムイオン(Li−ion)等)、太陽電池、燃料電池等を含み得る。
プロセッサ32はまた、M2Mデバイス30の現在の場所に関する場所情報(例えば、経度および緯度)を提供するように構成されるGPSチップセット50に結合され得る。M2Mデバイス30は、本明細書に開示される情報と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。
プロセッサ32はさらに、追加の特徴、機能性、および/または有線もしくは無線接続を提供する1つ以上のソフトウェアおよび/またはハードウェアモジュールを含み得る他の周辺機器52に結合され得る。例えば、周辺機器52は、種々のセンサ、例えば、加速度計、バイオメトリック(例えば、指紋)センサ、e−コンパス、衛星送受信機、センサ、デジタルカメラ(写真またはビデオ用)、ユニバーサルシリアルバス(USB)ポート、または他の相互接続インターフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Bluetooth(登録商標)(R)モジュール、周波数変調(FM)ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。
伝送/受信要素36は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはe−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の他の装置もしくはデバイスで具現化され得る。伝送/受信要素36は、周辺機器52のうちの1つを備え得る相互接続インターフェース等の1つ以上の相互接続インターフェースを介して、そのような装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続し得る。
図51Dは、例えば、図51Aおよび図51BのM2Mサービスプラットフォーム22が実装され得る例示的なコンピューティングシステム90のブロック図である。コンピューティングシステム90(例えば、M2M端末デバイス18またはM2Mゲートウェイデバイス14)は、コンピュータまたはサーバを備え得、主に、そのようなソフトウェアが記憶またはアクセスされる場所もしくは手段にかかわらず、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム90を起動させるように、中央処理装置(CPU)91内で実行され得る。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置91は、マイクロプロセッサと呼ばれる単一チップCPUによって実装される。他のマシンでは、中央処理装置91は、複数のプロセッサを備え得る。コプロセッサ81は、追加の機能を果たすか、またはCPU91を支援する、主要CPU91とは異なるプロセッサである。CPU91またはコプロセッサ81は、図18のステップ202におけるようなCREATEに対する要求の処理等のセマンティックIoTのためのRESTful動作のための開示されたシステムおよび方法に関係付けられるデータを受信、生成、ならびに処理し得る。
動作時、CPU91は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス80を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピューティングシステム90内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス80は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびに割込を送信するため、およびシステムバスを動作するための制御ラインを含む。そのようなシステムバス80の例は、PCI(周辺コンポーネント相互接続)バスである。
システムバス80に結合されるメモリデバイスは、ランダムアクセスメモリ(RAM)82および読取専用メモリ(ROM)93を含む。そのようなメモリは、情報が記憶されて読み出されることを可能にする回路を含む。ROM93は、概して、容易に修正することができない、記憶されたデータを含む。RAM82に記憶されたデータは、CPU91または他のハードウェアデバイスによって読み取られ、または変更されることができる。RAM82および/またはROM93へのアクセスは、メモリコントローラ92によって制御され得る。メモリコントローラ92は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供し得る。メモリコントローラ92はまた、システム内のプロセスを分離し、ユーザプロセスからシステムプロセスを分離する、メモリ保護機能を提供し得る。したがって、第1のモードで作動するプログラムは、独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。
加えて、コンピューティングシステム90は、CPU91からプリンタ94、キーボード84、マウス95、およびディスクドライブ85等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ83を含み得る。
ディスプレイコントローラ96によって制御されるディスプレイ86は、コンピューティングシステム90によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ86は、CRTベースのビデオディスプレイ、LCDベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ96は、ディスプレイ86に送信されるビデオ信号を生成するために必要とされる電子コンポーネントを含む。
さらに、コンピューティングシステム90は、図51Aおよび51Bのネットワーク12等の外部通信ネットワークにコンピューティングシステム90を接続するために使用され得る、ネットワークアダプタ97を含み得る。
本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、命令が、コンピュータ、サーバ、M2M端末デバイス、M2Mゲートウェイデバイス等のマシンによって実行されると、本明細書で説明されるシステム、方法、およびプロセスを行うおよび/または実装される、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令(すなわち、プログラムコード)の形態で具現化され得ることが理解される。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。本明細書の説明から明白なように、記憶媒体は、米国特許法第101条(35U.S.C.§101)の法的保護対象と解釈されるべきである。コンピュータ読み取り可能な記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD−ROM、デジタル多用途ディスク(DVD)または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理的媒体を含む。
図に例証されるように、本開示の主題(セマンティックIoTのためのRESTful動作)の好ましい方法、システム、または装置を説明する際に、明確にするために、特有の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。
本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法をもたらすように、単独で、または相互と組み合わせて動作し得る。本明細書で使用されるように、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」または同等物は、同義的に使用され得る。加えて、単語「または」の使用は、概して、本明細書に別様に提供されない限り、包含的に使用される。
本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用すること、任意の組み込まれた方法を行うことを含む、本発明を実践することを可能にするために、例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の例を含み得る(例えば、本明細書に開示される例示的方法間のステップのスキップ、組み合わせステップ、または追加ステップ)。そのような他の例は、請求項の文字通りの言葉とは異ならない構造要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の構造要素を含む場合に、請求項の範囲内であることを目的としている。
本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の一連の概念を導入するように提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図せず、請求される主題の範囲を限定するために使用されることも意図していない。請求される主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本願明細書は、例えば、以下の項目も提供する。
(項目1)
セマンティックリソース発見のための装置であって、前記装置は、
プロセッサと、
前記プロセッサと結合されているメモリと
を備え、
前記メモリは、実行可能命令を含み、前記命令は、前記プロセッサによって実行されると、
セマンティックリソース発見を含むメッセージを受信することと、
読み出されるべきセマンティック記述子の組を決定することであって、前記セマンティック記述子の組は、前記メッセージの標的に関連している、ことと、
前記セマンティック記述子の組に基づいて、セマンティック記述子のリストのそれぞれの記述子属性のコンテンツを読み出すことと
を含む動作を前記プロセッサにもたらさせる、装置。
(項目2)
前記動作は、
前記それぞれの記述子属性の前記コンテンツに基づいて、セマンティックグラフを生成することと、
セマンティックリソース発見を前記セマンティックグラフに対して実施するための命令を提供することと
をさらに含む、項目1に記載の装置。
(項目3)
前記それぞれの記述子属性のうちの少なくとも1つは、異なる装置上に記憶されている、項目1〜2のいずれか1項に記載の装置。
(項目4)
前記セマンティック記述子の組は、グループリソースを介して提供される、項目1〜3のいずれか1項に記載の装置。
(項目5)
前記読み出されるべきセマンティック記述子の組は、前記セマンティック記述子に対するユニフォームリソース識別子のリストを含む、項目1〜4のいずれか1項に記載の装置。
(項目6)
前記セマンティック記述子は、リソースである、項目1〜5のいずれか1項に記載の装置。
(項目7)
前記動作は、発信側装置が前記メッセージの前記標的のためのアクセス権を有することを検証することをさらに含み、前記メッセージの前記標的は、第1のセマンティック記述子である、項目1〜6のいずれか1項に記載の装置。
(項目8)
前記動作は、前記セマンティック記述子の組のうちの各セマンティック記述子に対して、発信側装置がアクセス権を有することを検証することをさらに含む、項目1〜7のいずれか1項に記載の装置。
(項目9)
前記動作は、前記メッセージの前記標的の属性の前記コンテンツをドキュメントとして保存することをさらに含み、前記メッセージの前記標的は、第1のセマンティック記述子である、項目1〜8のいずれか1項に記載の装置。
(項目10)
前記動作は、前記生成されたセマンティックグラフを一時的グラフストア内に保存することをさらに含む、項目1〜9のいずれか1項に記載の装置。
(項目11)
前記動作は、前記メッセージ内で受信されたセマンティックトリプルおよびリソースアクセス制御情報に関連付けられたアクセス制御トリプルを生成することをさらに含み、前記アクセス制御トリプルは、その後、前記セマンティックグラフ内に記憶される、項目1〜10のいずれか1項に記載の装置。
(項目12)
セマンティックリソース発見のための方法であって、前記方法は、
セマンティックリソース発見を含むメッセージを受信することと、
読み出されるべきセマンティック記述子の組を決定することであって、前記セマンティック記述子の組は、前記メッセージの標的に関連している、ことと、
前記セマンティック記述子の組に基づいて、前記セマンティック記述子のリストのそれぞれの記述子属性のコンテンツを読み出すことと
を含む、方法。
(項目13)
前記動作は、
前記それぞれの記述子属性の前記コンテンツに基づいて、セマンティックグラフを生成することと、
セマンティックリソース発見を前記セマンティックグラフに実施するための命令を提供することと
をさらに含む、項目12に記載の方法。
(項目14)
前記セマンティック記述子の組は、グループリソースを介して提供される、項目12〜13のいずれか1項に記載の方法。
(項目15)
前記読み出されるべきセマンティック記述子の組は、前記セマンティック記述子に対するユニフォームリソース識別子のリストを含む、項目12〜14のいずれか1項に記載の方法。
(項目16)
前記セマンティック記述子は、リソースである、項目12〜15のいずれか1項に記載の方法。
(項目17)
発信側装置が前記メッセージの前記標的のためのアクセス権を有することを検証することをさらに含み、前記メッセージの前記標的は、第1のセマンティック記述子である、項目12〜16のいずれか1項に記載の方法。
(項目18)
前記生成されたセマンティックグラフを一時的グラフストア内に保存することをさらに含む、項目12〜17のいずれか1項に記載の方法。
(項目19)
前記メッセージ内で受信されたセマンティックトリプルおよびリソースアクセス制御情報に関連付けられたアクセス制御トリプルを生成することをさらに含み、前記アクセス制御トリプルは、その後、前記セマンティックグラフ内に記憶される、項目12〜18のいずれか1項に記載の方法。
(項目20)
コンピュータ読み取り可能な媒体を備えているコンピュータプログラム製品であって、前記コンピュータ読み取り可能な媒体は、プログラム命令を含むコンピュータプログラムを有し、前記コンピュータプログラムは、データ処理ユニットの中にロード可能であり、前記コンピュータプログラムは、前記コンピュータプログラムが前記データ処理ユニットによって起動されると、項目12から19のいずれかに記載の方法ステップを前記データ処理ユニットに実行させるように適合されている、コンピュータプログラム製品。