JP2018503905A - Ｍ２ｍシステムのためのセマンティクス注釈およびセマンティクスリポジトリ - Google Patents

Abstract

方法、システム、およびデバイスが、「通常リソースのセマンティクス」（以降、リソースセマンティクス）に注釈を付け、それを記憶するために使用され得る。これらの方法、システム、およびデバイスは、セマンティクスサポートのための機能アーキテクチャの一部であり、セマンティクスベースのクエリを可能にし得る。セマンティクス子リソースに関連付けられた方法、システム、およびデバイスも、セマンティクス情報を表すために、リソース内に作成され得る。一実施形態において、セマンティクス注釈のための方法は、リソースのセマンティクス注釈インスタンスを自動的に生成することと、リソースを反映する階層様式でセマンティクス注釈インスタンスを記憶することと、要求に基づいて、どのセマンティクス注釈インスタンスがリソースに関連するかの通知を提供することとを含む。

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／０９８０１１号（２０１４年１２月３０日出願、名称「Ｓｅｍａｎｔｉｃｓ Ａｎｎｏｔａｔｉｏｎ ａｎｄ Ｓｅｍａｎｔｉｃｓ Ｒｅｐｏｓｉｔｏｒｙ ｆｏｒ Ｍ２Ｍ Ｓｙｓｔｅｍｓ」）および米国仮特許出願第６２／１３６，１９８号（２０１５年３月２０日出願、名称「Ｓｅｍａｎｔｉｃｓ Ａｎｎｏｔａｔｉｏｎ ａｎｄ Ｓｅｍａｎｔｉｃｓ Ｒｅｐｏｓｉｔｏｒｙ ｆｏｒ Ｍ２Ｍ Ｓｙｓｔｅｍｓ」）の利益を主張し、両出願の内容は、参照により本明細書に引用される。

物理的環境で展開されるネットワーク対応デバイスおよびセンサの数の急速な増加が、通信ネットワークを変化させている。次の１０年以内に、何十億ものデバイスが、スマートグリッド、スマートホーム、ｅ−ヘルス、自動車、輸送、物流、および環境監視等の種々の分野で、多くのアプリケーションおよびサービスプロバイダによるサービスのための無数の実環境データを生成するであろうと予測される。現在の情報ネットワーキング技術への実環境データおよびサービスの統合を可能にする関連技術および解決策は、多くの場合、モノのインターネット（ＩｏＴ）またはマシンツーマシン（Ｍ２Ｍ）通信の包括的用語の下で説明される。デバイスによって作成される大量のデータにより、このデータを識別およびクエリする効率的な方法の必要性がある。

一例は、集約点としてアクチュエータを使用する小型生物医学無線センサを使用した患者の病院またはリハビリテーションセンタによって提供され得る患者監視アプリケーションである。アクチュエータは、データをネットワークに伝送する。これらの小型装着型リソース制約デバイスは、とりわけ、血圧および血流、中核体温、酸素飽和度、運動、心拍数、聴覚、および視覚等のバイタルサインを連続的に監視するために患者上に展開され得るＭ２Ｍデバイスの例である。Ｍ２Ｍデバイスによって収集される種々の種類のＭ２Ｍデータは、とりわけ、患者の医師、個人トレーナ（例えば、２４時間フィットネスのため）、または救急車サービスによって使用され得る。医師、個人トレーナ、および救急車サービスがこれらのＭ２Ｍデバイスから生成されたデータを使用することを可能にするために、これらのリソースのセマンティクスも利用可能であるべきである。セマンティクスは、データの形式および構造を理解することができるように、データの記述的定義を提供する（すなわち、セマンティクスは、データの意味を提供する）。

Ｍ２Ｍセマンティックサポートは、それらの普遍的理解／解釈だけではなく、それらに対する任意の高度な処理（例えば、セマンティッククエリ、データ分析等）のために、リソースに対するセマンティクスを有効にするように意図される。以下の背景の節で紹介されるのは、セマンティクスウェブにおいて開発されている既存の技術ならびに例示的Ｍ２Ｍアーキテクチャ（例えば、ｏｎｅＭ２Ｍアーキテクチャ）である。

開発中のｏｎｅＭ２Ｍ規格（ｏｎｅＭ２Ｍ−ＴＳ−０００１ｏｎｅＭ２Ｍ機能アーキテクチャ−Ｖ−１．１．０）は、図３に図示されるように、共通サービスエンティティ（ＣＳＥ）と呼ばれるサービス層を定義する。Ｍｃａ参照点は、アプリケーションエンティティ（ＡＥ）とインターフェースをとる。Ｍｃｃ参照点は、同一サービスプロバイダドメイン内の別のＣＳＥとインターフェースをとり、Ｍｃｃ’参照点は、異なるサービスプロバイダドメインにおける別のＣＳＥとインターフェースをとる。Ｍｃｎ参照点は、下層ネットワークサービスエンティティ（ＮＳＥ）とインターフェースをとる。ＮＳＥは、下層ネットワークサービスをＣＳＥ（デバイス管理、場所サービス、およびデバイストリガリング等）に提供する。ＣＳＥは、「共通サービス機能（ＣＳＦ）」（「発見」または「データ管理およびリポジトリ」等）と呼ばれる複数の論理機能を含む。図４は、ｏｎｅＭ２Ｍのための例示的ＣＳＦを図示する。

ｏｎｅＭ２Ｍアーキテクチャは、アプリケーションサービスノード（ＡＳＮ）、アプリケーション専用ノード（ＡＤＮ）、ミドルノード（ＭＮ）、およびインフラストラクチャノード（ＩＮ）をイネーブルにする。ＡＳＮは、１つのＣＳＥを含み、少なくとも１つのＡＥを含むノードである。物理的マッピングの例は、Ｍ２Ｍデバイス内に常駐するＡＳＮである。ＡＤＮは、少なくとも１つのＡＥを含み、ＣＳＥを含まないノードである。物理的マッピングの例は、制約付きＭ２Ｍデバイス内に常駐するＡＤＮである。ＭＮは、１つのＣＳＥを含み、ゼロ以上のＡＥを含むノードである。ＭＮのための物理的マッピングの例は、Ｍ２Ｍゲートウェイ内に常駐するＭＮである。ＩＮは、１つのＣＳＥを含み、ゼロ以上のＡＥを含むノードである。ＩＮのための物理的マッピングの例は、Ｍ２Ｍサービスインフラストラクチャ内に常駐するＩＮである。

（サービスコンポーネントアーキテクチャ、ＴＳ−０００７サービスコンポーネントアーキテクチャ−Ｖ−１．１．０）に説明されるＭ２Ｍサービスアーキテクチャは、Ｍ２ＭアプリケーションおよびＭ２Ｍサービスプロバイダに提供されるＭ２Ｍサービスを規定することによって、ｏｎｅＭ２Ｍ機能アーキテクチャを拡張させる。図５に示されるコンポーネントは、サービスエクスポージャコンポーネント、ネットワークサービス利用コンポーネント、および遠隔サービスエクスポージャコンポーネントである。サービスエクスポージャコンポーネントは、サービスをＡＥにエクスポーズする。ネットワークサービス利用コンポーネントは、サービスをＮＳＥから消費する。遠隔サービスエクスポージャコンポーネントは、異なるＭ２Ｍ環境からのサービスを接続する。

セマンティクスウェブは、以下に論じられる。セマンティクスウェブは、スキーマ言語とオントロジ言語との組み合わせを使用して、オントロジの能力を提供する。オントロジは、所定の指定された語彙を使用して、特定の着目エリアに対するクラスおよびクラス間の関係、またはそれ以上を定義する。ワールドワイドウェブコンソーシアム（Ｗ３Ｃ）によって定義されるようなリソース記述フレームワークスキーマ（ＲＤＦＳ）（例えば、ＲＤＦ語彙記述言語１．０：ＲＤＦスキーマ）は、クラスおよびプロパティを定義するために使用され得る、リソース記述フレームワーク（ＲＤＦ）のための特定の語彙を提供する。ウェブオントロジ言語（ＯＷＬ）は、ウェブのためのより表現的オントロジを構築するために使用され得る追加のリソースを用いてＲＤＦＳ語彙を拡張する。プロパティが、リソース間の関係を確立する。それは、本明細書に論じられる関係と同一と見なされ得る。プロパティは、ＵＲＩ／ＵＲＬによって識別されることができる。それは、オントロジを構成する基礎のうちの１つである。

ＲＤＦは、ウェブで情報を表すためのフレームワークである。ＲＤＦは、本質的に、データモデルである。その基礎的構築ブロックは、ステートメントと呼ばれる、リソース・プロパティ・値トリプルである。ＲＤＦは、ＸＭＬ、ＪＳＯＮ等で構文を与えられている。

図１は、セマンティクスの例を図示し、それは、ＲＤＦを使用し得る。ＲＤＦグラフは、情報を表すためのツールである。グラフは、ヒト分析のために良好であるが、アプリケーションのやりとりのためにはそうでもない抽象化である。ＲＤＦステートメントはまた、ファイルまたは他のバイトストリーム等の特定のフォーマットで表され得る。最も一般的に使用される表現フォーマットは、ＲＤＦ／ＸＭＬ（ＲＤＦ言語８０２）および簡潔なＲＤＦトリプル言語（Ｔｕｒｔｌｅ）８０４である。ＲＤＦは、３つのコンポーネント、すなわち、主語、述語、および目的語を有する。主語は、説明されているリソースである。ＲＤＦでは、リソースは、ユニフォームリソース識別子（ＵＲＩ）を介して固有に識別可能な任意のものであることができる。ステートメントの目的語は、主語によって作用されている標的である。主語と同様に、ＵＲＩによって識別されるリソースであることができるが、代替として、文字列または数字のような文字値であることもできる。ステートメントの述語は、どんな種類の関係が主語と目的語との間に適用されるかを決定する。これもまた、ＵＲＩによって識別される。

一例では、図１に示されるように、ステートメント８０１は、Ｊｏｈｎ Ｓｍｉｔｈの肩書が教授であることを示し、それは、ＲＤＦ言語８０２で表され得る。ｘｍｌｎｓ：ｕｎｉ８０３は、自己定義されたドメイン名であり、そこでは、プロパティ（名前および肩書）は、ＲＤＦＳの一部として定義される。ＲＤＦは、特定の使用のドメインについての仮定が実施されないドメイン独立型である。ＲＤＦスキーマ（ＲＤＦＳ）と呼ばれるスキーマ言語でユーザ自身の用語を定義することは、ユーザ次第である。ＲＤＦＳは、ＲＤＦデータモデルで使用される語彙を定義する。ＲＤＦＳでは、語彙が定義され得、オブジェクト間の関係が記述され得、プロパティが特定の種類のオブジェクトに適用されるように規定され得、プロパティは、オブジェクトがとり得る値を含み得る。

ウェブオントロジ言語（ＯＷＬ）は、ウェブのためのより表現的オントロジを構築するために使用され得る追加のリソースを用いて、ＲＤＦＳ語彙を拡張する。ＯＷＬは、処理および推論をより計算上実行可能にするために、ＲＤＦドキュメントの構造およびコンテンツに関する追加の制限を導入する。例えば、ＯＷＬは、標準的な組の演算子、すなわち、共通集合、和集合、および補集合に対応するプロパティを定義し、クラスのブール結合を定義する。図２は、共通集合を使用して、概念「父親」を定義する例を図示する。「父親」は、正にクラス「親」と「男性」との共通集合である。言い換えると、「父親」である人は誰でも、「親」であり、かつ「男性」でもあり、「親」であり、かつ「男性」でもある人は誰でも、「父親」である。一見すると、ＯＷＬが、「Ｆａｔｈｅｒ ｉｓ ｒｄｆｓ：ｓｕｂＣｌａｓｓＯｆ Ｐａｒｅｎｔ」および「Ｆａｔｈｅｒ ｉｓ ｒｄｆｓ：ｓｕｂｃｌａｓｓＯｆ Ｍａｌｅ」と言うことと同等であると考えられ得る。しかしながら、これらの２つのｓｕｂＣｌａｓｓＯｆｓｔａｔｅｍｅｎｔｓは、全ての「父親」は、「親」でありかつ「男性」でなければならないということを述べているにすぎない。それらは、ｏｗｌ：ｉｎｔｅｒｓｅｃｔｉｏｎＯｆを使用して行われることができるように、それらの性別と親であるということとのみから、ある人が「父親」であることを推測するために使用されることはできない。

ＯＷＬは、ＲＤＦおよびＲＤＦＳと、ＸＭＬスキーマデータタイプと、ＯＷＬ名前空間とを使用する。ＯＷＬ語彙自体は、名前空間ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００２／０７／ｏｗｌ＃において定義され、一般に、プレフィックスｏｗｌによって参照される。データタイプは、ＵＲＩを使用して識別されるデータ値の範囲を表す。ＯＷＬは、いくつかの所定のデータタイプを使用することを可能にし、その大部分は、ＸＭＬスキーマ定義（ＸＳＤ）名前空間において定義される。ＯＷＬは、ユーザが、ＸＳＤを拡張することによって、ユーザ自身のデータタイプを定義することを可能にする。

ＲＤＦデータは、トリプルストアフレームワークを使用して、記憶およびクエリされ得る。トリプルストアは、ＲＤＦグラフの持続的記憶およびアクセスのための機構を提供する。既存のトリプルストア実装のいくつかの例は、ＪｅｎａおよびＳｅｓａｍｅである。Ｊｅｎａ（ｈｔｔｐｓ：／／ｊｅｎａ．ａｐａｃｈｅ．ｏｒｇ／）は、セマンティックウェブアプリケーションを構築するためのｊａｖａフレームワークである。Ｊｅｎａは、ＲＤＦおよびＯＷＬ等のセマンティックスウェブ構築ブロックに対処するためのアプリケーションプログラミングインターフェース（ＡＰＩ）を実装する。ユーザのためのＪｅｎａの基礎クラスは、ＲＤＦトリプルの組に対処するためのＡＰＩであるモデルである。モデルは、ファイルシステムまたは遠隔ファイルから作成されることができる。Ｓｅｓａｍｅ（ｈｔｔｐ：／／ｒｄｆ４ｊ．ｏｒｇ／）は、ＲＤＦデータの記憶、推測、およびクエリのためのオープンソースフレームワークである。Ｓｅｓａｍｅは、Ｊｅｎａの特徴を接続ＡＰＩの可用性、推測サポート、ウェブサーバの可用性、およびＳＰＡＲＱＬエンドポイントと一致させる。

セマンティクスおよびＭ２Ｍアーキテクチャのこの背景から、セマンティクスがＭ２Ｍアーキテクチャ内で機能することができる方法を決定する必要性がある。

セマンティック認識の欠如は、異なるアプリケーションがデータが発信されたアプリケーションの任意の以前の知識を有していない場合でも、Ｍ２Ｍアプリケーションによって生成されたデータが異なるアプリケーションによって発見されること、アクセスされること、解釈される、および共有されることができるように、Ｍ２Ｍサービス層によって効果的に抽象化または仮想化されることを可能にするサービスをＭ２Ｍサービス層がもたらすことを妨げる。

「通常リソースのセマンティクス」（以降、リソースセマンティクス）に注釈を付け、それを記憶するために使用され得る方法、システム、およびデバイスが、本明細書において開示される。これらの方法、システム、およびデバイスは、セマンティクスサポートのための機能アーキテクチャの一部であり、セマンティクスベースのクエリを可能にし得る。複数のリソースのための単一注釈の使用および注釈主語から離れた注釈の記憶を促進する方法が、開示される。とりわけ、セマンティクス子リソースを使用して、セマンティクス情報を表すことに役立つための方法、システム、およびデバイスも、本明細書において論じられる。

実施例では、デバイスは、プロセッサと、プロセッサと結合されるメモリとを含み得る。メモリは、プロセッサによって実行されると、プロセッサに、リソースのセマンティクス注釈インスタンスを自動的に生成することと、要求に基づいて、セマンティクス注釈インスタンスをクライアントに提供することとを含む動作を達成させる実行可能命令を含む。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に制約されない。

添付の図面と併せて一例として挙げられる、以下の説明から、より詳細に理解され得る。

図１は、ＲＤＦの使用を伴う、セマンティクス例を図示する。 図２は、ｏｗｌ：ｉｎｔｅｒｓｅｃｔｉｏｎの例を図示する。 図３は、例示的ｏｎｅＭ２Ｍアーキテクチャを図示する。 図４は、例示的ｏｎｅＭ２Ｍ共通サービス機能を図示する。 図５は、例示的ｏｎｅＭ２Ｍサービスアーキテクチャを図示する。 図６は、ジムの状況における使用ケースを図示する。 図７は、ジム使用ケースのためのグラフで表されるセマンティクス情報を図示する。 図８は、Ｍ２Ｍセマンティクスサポートの例示的機能アーキテクチャを図示する。 図９は、セマンティクスリポジトリの例示的アーキテクチャを図示する。 図１０は、例示的Ｍ２Ｍリソース階層を図示する。 図１１は、ジム使用ケースにおけるセマンティクス子リソースの例を図示する。 図１２は、セマンティクス注釈インスタンス生成の例示的メッセージフローを図示する。 図１３は、ＢＳＲ内のセマンティクス注釈インスタンスの例示的階層を図示する。 図１４は、クライアントの要求によってトリガされるセマンティクス注釈の例示的メッセージフローを図示する。 図１５は、クライアントの要求によってトリガされるセマンティクス注釈の例示的方法を図示する。 図１６は、例示的メッセージフローセマンティクス注釈インスタンス更新−ケース１を図示する。 図１７は、例示的メッセージフローセマンティクス注釈インスタンス更新−ケース２を図示する。 図１８は、例示的メッセージフローセマンティクス注釈インスタンス更新−ケース３を図示する。 図１９は、セマンティクス注釈インスタンス移行のための例示的方法を図示する。 図２０は、セマンティクス注釈インスタンス発見要求のメッセージフローを図示する。 図２１は、＜ｓｅｍａｎｔｉｃｓ＞の例示的リソース構造を図示する。 図２２は、ジム使用ケースにおけるセマンティクス子リソースの例を図示する。 図２３は、＜ｓｅｍａｎｔｉｃｓ＞の例示的代替リソース構造を図示する。 図２４は、＜ｒｅｌａｔｉｏｎＤｏｕｂｌｅ＞の例示的リソース構造を図示する。 図２５は、ジム使用ケースにおけるセマンティクス子リソースの例を図示する。 図２６は、＜ＳＤ＞リソースの例示的子リソースを図示する。 図２７は、例示的＜ａｎｎｏｔａｔｉｏｎ＞リソースを図示する。 図２８は、セマンティクス注釈インスタンス表現の例を図示する。 図２９は、例示的ｏｎｅＭ２Ｍセマンティクス注釈ＣＳＦを図示する。 図３０は、例示的ｏｎｅＭ２Ｍサービスコンポーネントアーキテクチャを図示する。 図３１は、セマンティクス注釈インスタンスとリソース（例えば、注釈主語）との間の例示的関係または関連付けを図示する。 図３２Ａは、１つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図３２Ｂは、図３２Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図３２Ｃは、図３２Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図３２Ｄは、図３２Ａの通信システムの側面が具現化され得る、例示的コンピュータシステムのブロック図である。

従来のマシンツーマシン（Ｍ２Ｍ）システムでは、（エンドデバイスならびにバックエンドネットワークサーバ上でホストされる）Ｍ２Ｍアプリケーションは、交換されるデータの共通定義について事前に合意する必要がある。これは、主に、アプリケーションの代わりにＭ２Ｍデータを解析、解釈、または処理することができる、セマンティック認識Ｍ２Ｍサービス層がないことによるものである。従来のＭ２Ｍシステムでは、Ｍ２Ｍサービス層は、セマンティック認識能力を欠いており、したがって、Ｍ２Ｍサービス層を通ってフローするデータ、またはＭ２Ｍサービス層内に記憶されるデータは、不透明な情報として扱われる。

このセマンティック認識の欠如は、たとえサービス層がデータが起源であったアプリケーションのいかなる予備知識を有しなくても、それが異なるアプリケーションによって発見、アクセス、解釈、および共有することができるように、Ｍ２Ｍアプリケーションによって生成されるデータがＭ２Ｍサービス層によって効果的に抽象化または仮想化されることを可能にするサービスを、Ｍ２Ｍサービス層が提供することを妨げる。結果として、感知および作用される物理的エンティティ（例えば、アプライアンス、人、車、建築物の部屋等）は、Ｍ２Ｍサービス層によって効果的に仮想化／抽象化されない場合があり、物理的エンティティは、環境に固有であり、特定のＭ２Ｍアプリケーションに関係しない一般的エンティティとして扱われる。この制限を克服するために、Ｍ２Ｍシステムにおいて伝送されるデータは、セマンティック認識Ｍ２Ｍサービス層がＭ２Ｍアプリケーションと同一のデータの知識を有することができるように、セマンティクス情報に関連付けられ、統合され得る。そうすることで、Ｍ２Ｍサービス層は、アプリケーションにわたるデータの共有をより良好に促進し、付加価値のあるセマンティック認識サービスをＭ２Ｍアプリケーションに提供することができる（例えば、データ集約、異なるアプリケーション間のデータ共有等）。

例えば、患者監視アプリケーションでは、患者のバイタルサイン（例えば、血圧、温度、酸素、心拍数等）を監視する無線センサデバイスの各々の上でホストされる、別個のアプリケーションがあり得る。同様に、この情報を利用することができるネットワーク内でホストされる別個のアプリケーション（例えば、患者の医師、個人トレーナ、家族、救急車の救急医療隊員等に関連付けられたアプリケーション）があり得る。しかしながら、無線センサデバイスの各々からのＭ２Ｍセマンティック認識サービスデータがないと、ネットワークアプリケーションは、ネットワークアプリケーションが無線センサデバイス上でホストされるアプリケーションの予備知識、およびそれらが生成する情報のタイプ（例えば、場所／アドレス、データの単位、データのコンテキスト等）を有しない限り、デバイスアプリケーションからの情報を発見、共有、および理解することに困難を有し得る。

本明細書に開示されるのは、「通常リソースのセマンティクス」（以降、リソースセマンティクス）に注釈を付け、それを記憶するために使用され得る方法、システム、およびデバイスである。これらの方法、システム、およびデバイスは、セマンティクスサポートのための機能アーキテクチャの一部であり、セマンティクスベースのクエリを可能にし得る。さらに、本明細書で論じられるのは、セマンティクス子リソースを使用して、セマンティクス情報を表すことに役立つための方法、システム、およびデバイスである。記述形容詞を伴わない、「リソース」は、本明細書に論じられるような「通常リソース」と同一である。「通常リソース」または「リソース」は、以下の表１の列１におけるリソースタイプ（例えば、ＡＥ、コンテナ、コンテンツインスタンス等）下に示されるようなｏｎｅＭ２Ｍにおけるリソースツリー等のリソースリポジトリ内に記憶される、リソースである。

以下は、ｏｎｅＭ２Ｍ ＲＥＳＴｆｕｌアーキテクチャに従う追加の背景である。能力サービス機能（ＣＳＦ）は、「リソース」の組として表される。リソースは、ｏｎｅＭ２Ｍアーキテクチャ内で固有にアドレス可能なエンティティである。リソースは、Ｃｒｅａｔｅ、Ｒｅｔｒｉｅｖｅ、Ｕｐｄａｔｅ、およびＤｅｌｅｔｅ（ＣＲＵＤ）等のＲＥＳＴｆｕｌ方法を介して操作および転送され、ユニフォームリソース識別子（ＵＲＩ）を使用してアドレスされ得る表現を有する。リソースは、子リソースおよび属性を含み得る。子リソースは、親リソースと包含関係を有する、リソースである。親リソース表現は、その子リソースへの参照を含む。子リソースの寿命は、親のリソース寿命によって限定され得る。各リソースは、リソースの情報を記憶する、「属性」の組をサポートし得る。

表１は、ｏｎｅＭ２Ｍ−ＴＳ−０００１ｏｎｅＭ２Ｍ機能アーキテクチャ−Ｖ−１．１．０に論じられるように定義される、リソースタイプおよび関連の子または親リソースタイプの例を提供する。

リソース発見プロシージャは、ＣＳＥ上に常駐するリソースの発見を可能にする。ｆｉｌｔｅｒＣｒｉｔｅｒｉａパラメータの使用は、結果のスコープの限定を可能にする。リソース発見は、発信側によって、発見が開始する場所のルーツ（例えば、＜ＣＳＥＢａｓｅ＞）もまた含む、ＲＥＴＲＩＥＶＥ方法を使用して遂行され得る。リソース発見プロシージャの未フィルタ処理結果は、発信側（例えば、発見要求送信側）が発見アクセス権を有する、発見が開始した場所のルーツ下の子リソースを含む。発見アクセス権は、要求側／要求送信側が、そのＣＳＥ上でリソースを発見するためのアクセス権を有することである。

フィルタ基準条件が、パラメータとしてＲＥＴＲＩＥＶＥ方法に提供され得る。フィルタ基準条件は、リソース発見のためのルール（例えば、リソースタイプ、作成時間、または一致するストリング）を記述する。フィルタ基準はまた、回答の最大サイズ（上限）を規定するためのパラメータおよび／または検索結果が編成されるべき順序を規定するためのソート基準を含むことができる。表２は、セマンティクス注釈に関して以下により詳細に論じられる、ｆｉｌｔｅｒＣｒｉｔｅｒｉａパラメータを記述する。

リソースが構成されるフィルタ基準条件に一致し、発信側が、リソースに対する発見アクセス権を有するとき、一致が生じる。応答成功は、一致されたリソースのリストを含むことができる。

図６は、ジムの状況における使用ケースを図示する。図６に示されるようなジムの使用ケースでは、ジムの両階上で展開される異なるデバイスが存在し、例えば、周囲温度／湿度等を感知するための周囲センサ７３４、ジムユーザが運動するためのトレッドミル７３７、体重計７３６、およびジムユーザがそのバイタルを記録するための血圧モニタ７３５である。いくつかの展開では、各デバイスは、同一階上に位置するゲートウェイ（例えば、ゲートウェイ７３１またはゲートウェイ７３３）に登録するか、またはある他のタイプの関連付けに登録し得る。各デバイスに関連するリソース（例えば、アプリケーションリソース）および各デバイスによって生成および報告されるデータリソースは、リソースリポジトリ内に記憶され得る。セマンティクスサポートの機能は、ゲートウェイ７３１またはゲートウェイ７３３等の１つ以上のゲートウェイ上にホストされることができる。

従来のＭ２Ｍサービス層機構（例えば、ｏｎｅＭ２Ｍ−ＴＳ−０００１ｏｎｅＭ２Ｍ機能アーキテクチャ−Ｖ−１．１．０に定義される）は、表２に説明されるフィルタ基準に基づいて、リソース発見を可能にする。しかしながら、より高度なリソースクエリが、所望され得る。ジム使用ケースでは、ジムユーザは、特定のメーカ、年式、およびある時間フレーム内における可用性を伴うトレッドミル７３７を発見することを望み得る。従来の発見機構は、そのような高度なリソースクエリを達成することができないこともある。しかし、本明細書に開示されるようなセマンティクスベースのクエリは、そのスキーマがデータの一部であるデータのための解析クエリ動作の組を提供することができる。セマンティクスベースのクエリを実現するために、リソースセマンティクスは、注釈を付けられる。本開示の文脈では、セマンティクス注釈は、クエリおよび他の高度な動作のために利用可能にされ得る、リソースのセマンティクスの追加および表現として定義されることができる。セマンティクスリポジトリは、必ずしも、リソースではなく、特に、セマンティクスのための中央場所と見なされ得る。関係および値情報が、そのセマンティクス子リソース内にリソースとともに記憶され得、したがって、この情報も、抽出され、セマンティクスリポジトリ内に置かれ得る。セマンティクス注釈インスタンスが、セマンティクスリポジトリ内に記憶され、それは、トリプルの組を含む。リソースセマンティクスは、リソースのセマンティクス子リソース内に記憶される。

図７は、図６のジム使用ケースに関連付けられた例示的抽象化を図示する。リソースのセマンティクスは、リソース、関係、および値から成る、リソース−関係−値トリプルによって記述されることができる。値は、クラスまたは他のリソースであることができる。クラスは、通常リソースの組を表す。クラスは、ＵＲＩ／ＵＲＬによって識別されることができる。クラスは、オントロジを構成する。関係は、例えば、「〜によって作成される」、「寿命」、「〜によってサブスクライブさせられる」等、リソース間の関係を記述する。関係は、ＵＲＩ／ＵＲＬによって識別されることができる。それは、オントロジを構成する基礎のうちの１つである。図７に示されるジム使用ケースにおけるリソース−関係−値トリプルの例は、表３に列挙される。例えば、表３から、リソース＝＜ｔｒｅａｄｍｉｌｌＡＥ＞、関係＝ｌｏｃａｔｅｄＩｎ、および値＝ｔｒｅａｄｍｉｌｌである。ｔｒｅａｄｍｉｌｌＡＥは、トレッドミルデバイスからＣＳＥに登録される。このトリプルは、登録において示され、セマンティクス子リソースにおいて表されない。したがって、図２２は、このトリプルを含まない。物理的エンティティは、人、ジム、または展開されるデバイス（例えば、ゲートウェイ、トレッドミル、周囲センサ、血圧モニタ、または体重計）である。ジムでは、ゲートウェイ７３１およびゲートウェイ７３２が、ジム共通サービスエンティティ（ＣＳＥ）をホストし得る。言い換えると、ゲートウェイは、ジムＣＳＥに抽象化される。同様に、トレッドミルは、ｔｒｅａｄｍｉｌｌＡＥに抽象化される。図７におけるエンティティは、ｏｎｅＭ２Ｍ内で定義されたリソースタイプを利用し得る。

以下は、Ｍ２Ｍセマンティクスサポートのための機能アーキテクチャの概観ならびにセマンティクス注釈の実装に関する詳細である。図８は、Ｍ２Ｍセマンティクスサポートのための例示的機能アーキテクチャを図示する。以下により詳細に論じられる、ブロック７０１における例示的セマンティックアーキテクチャのコンポーネントは、リソースリポジトリ７１０、オントロジプロセッサ７０５、オントロジリポジトリ７０６、セマンティクスリポジトリ７２０、ルールリポジトリ７０７、推論器７０４、またはセマンティッククエリプロセッサ７０２を機能的に含み得る。ブロック７０１またはそのコンポーネントは、独立型デバイス（例えば、一次セマンティック機能を有するデバイス）であるか、または別のデバイス（例えば、ゲートウェイ７３１）の中に統合され得る。ブロック７０１は、クライアントデバイス７０３、オントロジパブリッシュ（または要求）デバイス７００、またはＭ２Ｍアプリケーションを有するか、もしくは別様にそれと相互作用する別のデバイス７０８と通信可能に接続され得る。

リソースリポジトリ７１０は、Ｍ２Ｍデバイスから収集されるリソースと、Ｍ２Ｍアプリケーションに関連する任意のリソース（Ｍ２Ｍアプリケーション（通常リソース）に関わる人、デバイス等に関連付けられたプロファイル等）とを記憶する。Ｍ２Ｍセマンティクスサポートは、リソースの包括的理解／解釈と、リソースにおける任意の高度な処理（例えば、セマンティッククエリ、データ解析等）とのために、リソースに対するセマンティクスをイネーブルにし得る。

オントロジプロセッサ７０５は、Ｍ２Ｍドメインの内外でパブリッシュまたは生成されたオントロジを処理すること、分類すること、記憶すること、およびその発見機能を提供することを担当する。オントロジリポジトリ７０６は、クラスおよび関係の基礎から成るオントロジを記憶する。それらのオントロジは、通常リソースがセマンティクスをイネーブルにするために使用されることができる。オントロジリポジトリは、セマンティクスノードのための別の用語と見なされ得る。ドメインは、識別をスコープする識別空間と見なされ得る。識別子は、異なる空間において同じように見える場合でも、固有であり得る。本開示の文脈では、ドメインは、異なるバーティカル、アプリケーション等の異なるエンティティによって定義されるクラスおよび関係をスコープするために使用され得、それによって、それらの名前は、異なるドメインにおいて同じように見え得る場合でも、それらの定義が同一ドメインにおいて固有となるであろう。

セマンティクスリポジトリ７２０は、ある表現において注釈を付けられたセマンティクス情報を記憶し、それは、ＲＤＦを利用するオプションを有し得る。

ルールリポジトリ７０７は、多くの場合、リソースリポジトリ７１０内のリソースに関連付けられた既存のセマンティクスの範囲を超えた新しい知識を表すために使用されるルールを記憶する。ルールは、典型的には、条件ステートメント（例えば、ｉｆ−ｔｈｅｎ節）である。

推論器７０４は、ルールリポジトリ７１０と、セマンティクスリポジトリ７２０内の既存のリソースセマンティクス情報とから入力をとり、ルール内の条件が満たされる場合、新しいリソースセマンティクス情報を生成する。新しいリソースセマンティクス情報は、セマンティクスリポジトリ７２０に追加される。

セマンティッククエリプロセッサ７０２は、クライアントからのクエリをハンドリングし、セマンティクスリポジトリ７２０内に記憶されるリソースセマンティクス情報を検索し、結果をクライアントデバイス７０３に返し得る。クライアントは、本開示の文脈では、セマンティクス注釈要求またはセマンティクス注釈インスタンス発見要求をＳＡＰに送信し得る。

図９は、セマンティクス注釈のための例示的機能アーキテクチャを図示する。セマンティクス注釈は、例では、リソースリポジトリ（ＲＲ）７１０のリソースのＵＲＩと、その対応するセマンティクス子リソースにおける関係−値ダブルとから成るトリプルをもたらし得る。トリプルの組は、セマンティクスリポジトリ７２０内に記憶され、それは、セマンティクス注釈インスタンスと呼ばれる。図９に示されるように、セマンティクスリポジトリ７２０は、セマンティクス注釈プロセッサ（ＳＡＰ）７２１、ベースセマンティクスリポジトリ（ＢＳＲ）７２２、および遷移セマンティクスリポジトリ（ＴＳＲ）７２３から成り得、それは、本明細書により詳細に論じられるであろう。各セマンティクス注釈インスタンスは、リソースのリストに対応し、リソースのセマンティクス情報は、セマンティクス注釈インスタンス内に含まれる。各セマンティクス注釈インスタンスは、それに関連付けられた識別子（例えば、英字、数字、または英数字であり得る、コード）を有し得る。

セマンティクスリポジトリ７２０およびリソースリポジトリ７１０は、物理的に別個である必要はない。それらは、異なる情報を記憶することができるので、機能的に異なり得る。リソースリポジトリ７１０は、リソースを記憶する一方、セマンティクスリポジトリ７２０は、リソースリポジトリ７１０内に含まれるリソースに関連付けられたトリプルを記憶し得る。実装の観点から、リソースリポジトリ７１０は、関係データベースとして実装され得る。セマンティクスリポジトリ７２０は、とりわけ、トリプルストアまたはグラフストアとして実装され得る。セマンティクスリポジトリ７２０は、ＪｅｎａまたはＳｅｓａｍｅ等の従来のトリプルストア実装を活用して、セマンティクス注釈インスタンスを記憶することができる。

ＳＡＰ７２１は、セマンティクス注釈インスタンスを生成または更新することを含む複数の責任を有し得る。第１のシナリオでは、ＳＡＰ７２１は、リソースリポジトリ７１０内の各リソースのためにセマンティクス注釈インスタンスを自動的に生成し得る。第２のシナリオでは、ＳＡＰ７２１は、クライアント７０３（図８）または別のデバイスからのセマンティクス注釈要求に基づいて、セマンティクス注釈インスタンスを生成し得る。ＳＡＰ７２１は、とりわけ、それが注釈を行うリソース階層内の層（階層は、以下により詳細に論じられる）に基づいて、クライアント７０３からの要求内の命令もしくは要求のタイプに基づいて、または要求が発生したデバイスのタイプに基づいて、リソースリポジトリ７１０から注釈を付けるべきリソースを決定し得る。

セマンティクス注釈インスタンスは、リソースに関連付けられ、リソース−関係−値トリプルにおけるそのセマンティクスは、このセマンティクス注釈インスタンス内に含まれる。ＳＡＰ７２１は、表４に示されるように、セマンティクス注釈インスタンスからリソースへの関連付け形態に維持する。したがって、各セマンティクス注釈インスタンスは、リソースリポジトリ７１０のリソースのＵＲＩにマップされる。リソースリポジトリ７１０は、図１０に示されるように、Ｍ２Ｍリソースを階層様式で記憶し得、それは、表１に関して論じられるように、親および子リソースに関連付けられ得る。この階層構造は、表４の「含まれるリソース」フィールドが、そのリソース−関係−値トリプル等がセマンティクス注釈インスタンス内に含まれる全リソースのＵＲＩを列挙する必要はない状況を可能にし得る。リソースのうちのいくつかが、同一階層下にあり、それらが、その階層下の唯一のリソースである場合、その階層の親ＵＲＩが、それらのリソースを表すために使用されることができる。言い換えると、親ＵＲＩは、全てのその子リソースが同一インスタンスにおいて注釈を付けられている場合、セマンティクス注釈インスタンスに関連付けられるように規定され得る。例として、コンテナが、コンテンツインスタンスを有し、それが２つのみである場合、例えば、／＜ｃｏｎｔａｉｎｅｒ＞／＜ｉｎｓｔ１＞、／＜ｃｏｎｔａｉｎｅｒ＞／＜ｉｎｓｔ２＞のＵＲＩを伴う場合を検討する。それらの２つのリソースが、セマンティクス注釈インスタンス内に記述される場合、その対応する含まれるリソースフィールドは、２つの個々のＵＲＩの代わりに、／＜ｃｏｎｔａｉｎｅｒ＞／として書かれることができる。

ＳＡＰ７２１はまた、表５に示されるように、逆関連付け形態（リソースからセマンティクス注釈インスタンスへの関連付け形態）を維持し得る。表５の形態の使用は、ＳＡＰ７２１が、リソースのセマンティクス情報が変化した場合、関連セマンティクス注釈インスタンスを見つけ、関連セマンティクス注釈インスタンスを周期的に更新することを可能にし得る。変化の通知が直ちに送信される代わりに、１つ以上の変化に関する情報（例えば、累積更新）が、周期的に送信され得る。例えば、ＳＡＰ７２１は、周期的に（例えば、実装のタイプに応じて、１分、１日、または１週間毎）、リソースリポジトリ７１０に、リソースからセマンティクス注釈インスタンスへの関連付けを通知することができる。ＳＡＰ７２１は、関連付け関係が、作成、更新、または削除された場合にも、リソースリポジトリ７１０に、リソースからセマンティクス注釈インスタンスへの関連付けを通知することができる。例では、リソースリポジトリ７１０は、ａｎｎｏｔａｔｉｏｎＩｎｓｔ属性（本明細書により詳細に論じられる）等のセマンティクス注釈を伴うｏｎｅＭ２Ｍ内のリソースのための属性を介して、リソース自体とともに記憶された前述の関連付け関係を有し得る。

表４および表５の使用をさらに図示するために、図１１が、ここで参照される。ここでは、セマンティクス注釈インスタンスの識別子は、以下のリソースのトリプルを含む、ｔｒｅａｄｍｉｌｌＡｎｎｏｔａｔｉｏｎであると仮定する。
／ｇｙｍＣＳＥ１Ｆ／ｔｒｅａｄｍｉｌｌＡＥ／ｔｒａｉｎｉｎｇＣｏｎｔａｉｎｅｒ／ｃｏｎｔＩｎｓｔ１
／ｇｙｍＣＳＥ１Ｆ／ｔｒｅａｄｍｉｌｌＡＥ／ｔｒａｉｎｉｎｇＣｏｎｔａｉｎｅｒ／ｃｏｎｔＩｎｓｔ２
そして、セマンティクス注釈インスタンスからリソースへの関連付け形態は、表６（表４に関連する）に示されるように、追加されるセマンティクス注釈インスタンスエントリを有するであろう。リソースからセマンティクス注釈インスタンスへの関連付け形態は、表７（表５に関連する）に示されるように、リソースの各々に対して追加される２つのエントリを有するであろう。表６は、リソースが、図１１に示されるように同一のセマンティクスダブルを有するので、簡略化され得る。表６は、表８に見られるものに対して簡略化されている。表７は、同一のままである。

図１２は、セマンティクス注釈インスタンス生成の例示的メッセージフローである。ブロック７４１では、ＳＡＰ７２１は、注釈を付けられるべきＲＲ７１０内のリソースを決定する。リソースは、とりわけ、それが注釈を行うリソース階層内の層に基づいて、またはクライアント要求に基づいて決定され得る。ブロック７４２では、ＳＡＰ７２１は、対応するリソースのセマンティクス子リソース表現を読み出す。ブロック７４３では、ＳＡＰ７２１は、セマンティクス子リソースからトリプルを生成し、それは、本明細書に説明されるセマンティクス注釈のための方法によって行われ得る。加えて、ＳＡＰ７２１は、生成されたトリプルをセマンティクス注釈インスタンスに組み合わせる。ブロック７４４では、ＳＡＰ７２１は、セマンティクス注釈インスタンスからリソースへの関連付け記録を生成し、表４に示される形態に追加する。ＳＡＰ７２１はまた、表５に示されるリソースからセマンティクス注釈インスタンスへの関連付け記録を生成または更新する。ブロック７４５では、ＳＡＰ７２１は、セマンティクス注釈インスタンスとリソースとの関連付けの記録を表４に示されるようなフォーマットでＲＲ７１０に送信する。ブロック７４６では、ＲＲ７１０は、関連付け情報を記録から抽出し、セマンティクス注釈インスタンス識別子を関連リソースとともに、例えば、リソースの属性内に記憶する。

以下に論じられるのは、リソースリポジトリ７１０の各リソースに対して１つ以上のセマンティクス注釈インスタンスを自動的に生成するＳＡＰ７２１に関する（前述のような）第１のシナリオである。この例では、リソースリポジトリ７１０が、ＳＡＰ７２１に、リソース階層内に作成された新しい層が存在すること通知する場合、ＳＡＰ７２１は、新しい層下の全リソースのセマンティクスに注釈を付け得る。リソースが、既存の層内に追加、削除、または更新される場合、対応するセマンティクス注釈インスタンスが、ＳＡＰ７２１によって、同様に更新され得る。この第１のシナリオでは、リソースリポジトリ７１０は、ｏｎｅＭ２Ｍが定義するような階層構造を有し得る（例えば、表１および図１０）。ＳＡＰ７２１は、各層に対してセマンティクス注釈インスタンスを生成することができる。本明細書に論じられるようなｏｎｅＭ２Ｍリソース構造実装では、ＳＡＰは、＜ＣＳＥＢａｓｅ＞、＜ＡＥ＞、＜ｃｏｎｔａｉｎｅｒ＞等のリソースのセマンティクスに注釈を付け得る。以下は、セマンティクス子リソースがそれらに追加される場合、セマンティクス情報をイネーブルにし得るリソースの例示的リストである：＜ＣＳＥＢａｓｅ＞、＜ｒｅｍｏｔｅＣＳＥ＞、＜ＡＥ＞、＜ｃｏｎｔａｉｎｅｒ＞、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞、＜ｇｒｏｕｐ＞、および＜ｎｏｄｅ＞。

この第１のシナリオでは、生成されたセマンティクス注釈インスタンスは、ＢＳＲ７２２内に記憶され得る。ここで、ＢＳＲ７２２内のセマンティクス注釈インスタンスは、表１に提供されるように、対応するリソースと同様の階層関係を継承する。図１３は、第１のシナリオに関するＢＳＲ７２２上のセマンティクス注釈インスタンスの階層の例示的例証である。各セマンティクス注釈インスタンスは、セマンティクスリポジトリ７２０内で固有の識別子を有し得る。ＢＳＲ７２２内のセマンティクス注釈インスタンスに対して、識別子は、何らかのランダムなドネーションを伴う、層の親リソースの名前のように見え得る。図１３に示されるように、ＣＳＥＢａｓｅ層のセマンティクス注釈インスタンスは、ＣＳＥｂａｓｅＳＡＩ ７５１である。ＣＳＥｂａｓｅＳＡＩ ７５１は、ＣＳＥＢａｓｅ層のセマンティクス注釈インスタンスを表し、同様に、ｒｅｍｏｔｅＣＳＥＡＩ ７５２は、ｒｅｍｏｔｅＣＳＥ層を、ＡＥＡＩ ７５３は、ＡＥを、ｃｏｎｔａｉｎｅｒＳＡＩ ７５７は、ｃｏｎｔａｉｎｅｒを、ｃｏｎｔｅｎｔｉｎｓｔａｎｃｅＳＡＩ ７５８は、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅを、ｃｏｎｔａｉｎｅｒＳＡＩ ７５４は、ｃｏｎｔａｉｎｅｒを、ｇｒｏｕｐＳＡＩ ７５５は、ｇｒｏｕｐを、ｎｏｄｅＡＩ ７５６は、ｎｏｄｅを表す等。注釈インスタンス内に記憶される冗長トリプルの可能性が、存在し得る。例えば、ＣＳＥＢａｓｅＳＡＩは、ＣＳＥＢａｓｅ下のリソースのための全トリプルを含み得、ＡＥＡＩは、ＡＥ下のリソースのための全トリプルを含み得、それは、ＣＳＥＢａｓｅＳＡＩ内に記憶されるトリプルの一部に対する冗長であり得る。ＣＳＥＢａｓｅＳＡＩを全てのそのサブ注釈インスタンスにリンクさせることは、ＳＲ７２０上の記憶空間を節約し得る。例えば、セマンティクスベースのクエリが、ＣＳＥＢａｓｅＳＡＩにスコープされる場合、ＣＳＥＢａｓｅＳＡＩ下の全トリプルは、ＣＳＥＢａｓｅＳＡＩのそれらのトリプルと、この階層内のＣＳＥＢａｓｅＳＡＩ層下の全トリプルとをプラスしたものであり、それが、検索されるであろう。図２８を使用して、前述の例をさらに図示すると、ＣＳＥｂａｓｅＳＡＩ ７５１は、図２８に示されるように、全情報（トリプル）を含み得る。この情報は、それぞれのＡＥＡＩ内で再び繰り返されることができる（例えば、図２８のｔｒｅａｄｍｉｌｌ １、ｔｒｅａｄｍｉｌｌ ２等）。代替として、ＡＥＡＩへのリンクが、ＣＳＥｂａｓｅＳＡＩ ７５１内に記憶され得、詳述される情報（トリプル）は、それぞれのＡＥＡＩ内に含まれ得る。

図１３および第１のシナリオを継続して参照すると、リーフセマンティクス注釈インスタンスに対して、それは、リソースがセマンティクス情報を伴うどんな子リソースも有していないので、リソース自体のセマンティクス注釈を含む。例として、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースのセマンティクス注釈インスタンス（例えば、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅＳＡＩ ７５８）は、リソース自体のトリプルを含み得る。

非リーフセマンティクス注釈インスタンスに対して、それは、リソース自体のトリプルと、その子リソースのためのセマンティクス注釈インスタンスとから成り得る。例えば、図１３に関して、＜ＡＥ＞のセマンティクス注釈インスタンスは、＜ＡＥ＞のトリプルと、＜ｃｏｎｔａｉｎｅｒ＞および＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞のためのセマンティクス注釈インスタンスとから成る。加えて、さらなる観点から、＜ｃｏｎｔａｉｎｅｒ＞のセマンティクス注釈インスタンスは、＜ｃｏｎｔａｉｎｅｒ＞のトリプルと、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞のためのセマンティクス注釈インスタンスとから成る。

図１２ならびに図１４および図１６から図２０に図示されるステップを行うエンティティは、論理エンティティであり得ることを理解されたい。ステップは、図３２Ｃまたは図３２Ｄに図示されるもの等のデバイス、サーバ、またはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行し得る。例では、Ｍ２Ｍデバイスの相互作用に関し以下にさらに詳述されるが、図８のクライアント７０３は、図３２ＡのＭ２Ｍ端末デバイス１８上に常駐し得る一方、図８のセマンティクスリポジトリ７２０は、図３２ＡのＭ２Ｍゲートウェイデバイス１４上に常駐し得る。

図１４は、クライアントの要求によってトリガされるセマンティクス注釈生成の例示的メッセージフローを図示する。図１４は、ＳＡＰ７２１が、クライアント７０３等のクライアントからの注釈要求を受信し得る第２のシナリオに関連付けられる。セマンティクス注釈要求メッセージ内の例示的フィールドは、表９に示される。

図１４は、クライアント要求によってトリガされるセマンティクス注釈生成の例示的メッセージフローを図示する。ステップ７６１では、クライアント７０３が、セマンティクス注釈要求メッセージをＳＡＰ７２１に送信する。セマンティクス注釈要求メッセージは、表９に示される情報を含み得る。ステップ７６２では、ＳＡＰ７２１は、要求を処理し、要求メッセージのスコープフィールド内のコンテンツが、注釈を付けられるべきリソースのＵＲＩのリストを含むか、または注釈を付けられるべきリソースをフィルタ処理するフィルタ基準を含むかを検証する。ステップ７６３では、ＳＡＰ７２１は、フィルタ基準がスコープ内に含まれることを検証する。それは、リソース発見要求をフィルタ基準とともに、リソースリポジトリ７１０内のリソース発見を担当するリソース発見機能７７２に送信する。ステップ７６４では、リソース発見機能７７２は、フィルタ基準に一致するリソースのＵＲＩのリストを返す。

ステップ７６５では、ＳＡＰ７２１は、セマンティクス注釈インスタンスからリソースへの関連付け記録を検索し、リソースの同一リストを関連付ける既存のセマンティクス注釈インスタンスが存在するかどうかを見つけ得る。一致が存在しない場合、ステップ７６６に進む。そうでなければ、セマンティクス注釈要求応答は、対応するセマンティクス注釈インスタンスであり、ステップ７６７に進む。ＳＡＰ７２１は、セマンティクス注釈インスタンスからリソースへの関連付け形態における異なるエントリの組み合わせを行うことによって、リソースを一致させることにおいてより多くの知能を有し得る。セマンティクス注釈要求応答は、一致するセマンティクス注釈インスタンスの組み合わせを含むはずである。ステップ７６６では、ＳＡＰ７２１は、着目リソースに関連付ける新しいセマンティクス注釈インスタンスを生成する。各セマンティクス注釈インスタンスは、ＳＡＰ７２１内で固有の識別子を有する。ＴＳＲ７２３内のセマンティクス注釈インスタンスに対して、識別子は、リソースのＵＲＩのキーワードから成り得る。ステップ７６７では、ＳＡＰ７２１は、セマンティクス注釈インスタンスの表現（着目リソースのトリプルのリスト）とともに、セマンティクス注釈要求応答をクライアント７０３に送信する。クライアント７０３は、独自にセマンティクスベースのクエリをセマンティクス注釈インスタンスに対して実行するために、セマンティクス注釈インスタンスの表現を所望し得るか、またはクライアント７０３は、着目リソースのセマンティクス情報をトリプルのフォーマットで所望し得る。言い換えると、クライアント７０３は、セマンティクス注釈インスタンスの表現を読み出し、自らセマンティクスベースのクエリをそれらのトリプルに対して実行することができる。例えば、図２８におけるトリプルは、クライアント７０３によって読み出されることができ、クライアント７０３は、サービス層がそれを行うことなしに、「１９：００−１９：３０の間に利用可能なトレッドミル」等のそれらのトリプルに対してクエリを実行し得る。

ステップ７６８では、ＳＡＰ７２１が背景に維持するクライアント注釈要求履歴に基づいて、ＳＡＰ７２１は、新しく生成されたセマンティクス注釈インスタンスが、ＴＳＲ７２３内に記憶するためのあるポリシを満たすことを決定する。ＴＳＲ７２３は、より迅速なアクセスのために設計され得る。それは、ＢＳＲのような階層を有していないこともある。例えば、ＴＳＲ７２３は、いくつかの最近アクセスされたセマンティクス注釈インスタンスを含み得る。このタイプの記憶ポリシは、セマンティクス注釈要求のスコープ内に示されるリソースの頻度に基づくか、またはセマンティクス注釈インスタンスを生成することにおけるオーバーヘッド（例えば、いくつかのリソースは、ローカルで記憶されず、それは、リソースのセマンティクス情報の遠隔読み出しを要求する）に基づき得る。ＴＳＲ７２３内に記憶されるセマンティクス注釈インスタンスは、有効期間を有し、それは、満了時間後に無効になり得る。図６のジム使用ケースからの例では、要求は、全トレッドミルアプリケーションに注釈を付けることであり得る。この注釈を要求する多くのクライアントが存在する場合、ＳＡＰ７２１は、将来の同じ要求のために、注釈インスタンスをＴＳＲ７２３に記憶することを決定することができる。ステップ７６９では、ＳＡＰ７２１は、新しく生成されたセマンティクス注釈インスタンスを記憶されるべきＴＳＲ７２３に送信し得る。ステップ７７０では、ＴＳＲ７２３は、ＳＡＰ７２１に、セマンティクス注釈インスタンスの記憶成功を確認する。ステップ７７１では、ＳＡＰ７２１は、表４および表５に示されるように、リソースとセマンティクス注釈インスタンスとの関連付け関係を両表に追加する。図１５は、図１３の例示的メッセージフローと密接に整合する、方法の例示的例証である。

ＳＡＰ７２１は、関与リソースセマンティクスが更新された場合、セマンティクス注釈インスタンスを更新する。ＳＡＰ７２１はまた、スコープ下のリソースが作成／削除されると、セマンティクス注釈インスタンスを更新する。セマンティクス注釈インスタンスへの更新を行うためにＳＡＰ７２１をトリガする複数の方法が、存在する。第１の例では、ＳＡＰ７２１が、ＲＲ７１０内のリソースおよびそのセマンティクス子リソースにサブスクライブする（例えば、リソースリポジトリに追加されている新しいリソースまたは更新されているリソースのセマンティクス子リソースは、ＳＡＰに通知されるであろう）。第２の例では、ＲＲ７１０が、リソース自体に所属させられた関連付け情報を維持する（例えば、本明細書で論じられるａｎｎｏｔａｔｉｏｎＩｎｓｔ属性は、この属性におけるセマンティクス注釈インスタンスがリソースに関連付けられていることを示す）。以下では、この方法を詳細に論じる。第２の例では、サブスクリプションは、存在しない。ａｎｎｏｔａｔｉｏｎＩｎｓｔ属性が、このリソースに関連付けられた注釈インスタンスを維持する。リソースセマンティクスが変化すると、ＲＲ７１０は、要求をセマンティクスリポジトリ７２０に送信し、関連付けられたセマンティクス注釈インスタンスを更新するであろう。

図１６から図１８は、セマンティクス注釈インスタンス更新に関わるケースのための例示的方法である。要するに、本明細書に論じられるように、ケース１（図１６）は、リソースのセマンティクス情報が変更されるケースであり、ケース２（図１７）は、リソースがリソースリポジトリに追加される例であり、ケース３（図１８）は、リソースがリソースリポジトリから削除されるケースである。ケース番号は、表１０に示されるように、セマンティクス注釈インスタンス更新要求メッセージ内のフィールドに挿入され得る。表１０に示されるようなケース番号は、必須ではなく、リソースの追加、削除、または更新を示す別のインジケータも許容可能であることを理解されたい。

図１６は、リソースのためのセマンティクス情報の更新に関連付けられたセマンティクス注釈インスタンス更新のための例示的方法７７４を図示する（例えば、セマンティクス子リソースが更新される）。ステップ７８０では、セマンティクス子リソースが、更新される。ステップ７８１では、ＲＲ７１０が、セマンティクス注釈インスタンス更新要求メッセージを１のケース値とともにＳＲ７２０に送信する。セマンティクス注釈インスタンス更新要求メッセージはまた、リソースのＵＲＩを示すＵＲＩフィールドと、リソースの新しいセマンティクス情報を含むセマンティクスリソースフィールドと、影響されるセマンティクス注釈インスタンスを示す識別子フィールドとを含み得る。ＳＲ７２０は、ＲＲ７１０内のリソースおよびそのセマンティクス子リソースにサブスクライブさせられ得る（例えば、リソースリポジトリに追加されている新しいリソースまたは更新されているリソースのセマンティクス子リソースは、通知をＳＲ７２０にトリガするであろう）。ステップ７８２では、ＳＲ７２０は、影響されるセマンティクス注釈インスタンスに対して、リソースのトリプルを新しいもので置き換える。ステップ７８３では、ＳＲ７２０が、セマンティクス注釈インスタンス更新確認をＲＲ７１０に返す。

ケース２は、ＲＲに追加されているリソースに関する（図１７）。これは、多くの場合、親リソースのセマンティクス注釈インスタンスがその子から成るので、ＢＳＲ内のセマンティクス注釈インスタンスに影響を及ぼす。したがって、リソースが層に追加されると、それは、その上層リソースに対するＢＳＲ内のセマンティクス注釈インスタンスに影響を及ぼすであろう。例えば、新しいコンテンツインスタンスが、セマンティクス情報とともに追加される場合、新しいセマンティクス注釈インスタンスが、このコンテンツインスタンスに対して作成されるであろう。その親コンテナリソースのセマンティクス注釈インスタンスは、この新しいセマンティクス注釈インスタンスを含み、それは、順に、例えば、ＡＥ、ＣＳＥＢａｓｅのセマンティクス注釈インスタンスに影響を及ぼす。

図１７は、ＲＲ７１０へのリソースの追加に関連付けられたセマンティクス注釈インスタンス更新のための例示的方法７７６を図示する。ステップ７８４では、ＲＲ７１０が、セマンティクス注釈インスタンス更新要求メッセージをＳＡＰ７２１を追加されるリソースに関する２のケース値とともにＲＲ７１０に送信する。加えて、ＵＲＩフィールドは、新しいリソースのＵＲＩを示し、セマンティクスリソースフィールドは、リソースのセマンティクス情報を含む。ステップ７８５では、ＳＡＰ７２１が、ＲＲ７１０における新しいリソースのために、ＢＳＲ７２２内に新しいセマンティクス注釈インスタンスを作成する。ＳＡＰ７２１は、このセマンティクス注釈インスタンスを階層下に追加すること、または新しいリソースのトリプルを全てのその親セマンティクス注釈インスタンスに追加することによって、全ての親セマンティクス注釈インスタンスを更新し得る。ステップ７８６では、ＳＡＰ７２１が、新しいセマンティクス注釈インスタンスからリソースへの関連付けエントリと、新しいリソースからセマンティクス注釈インスタンスへの関連付けエントリとを作成する。セマンティクス注釈インスタンスからリソースへの関連付けエントリは、新しいセマンティクス注釈インスタンスの識別子と、リソースのＵＲＩとを含む。リソースからセマンティクス注釈インスタンスへの関連付けエントリは、リソースのＵＲＩと、新しいセマンティクス注釈インスタンスの識別子と、全てのその親セマンティクス注釈インスタンスの識別子とを含む。ステップ７８７では、ＳＡＰ７２１は、セマンティクス注釈インスタンス更新確認をＲＲ７１０に送信し、セマンティクス注釈インスタンスからリソースへの関連付け記録を添付する。ステップ７８８では、ＲＲ７１０はセマンティクス注釈インスタンス識別子をリソースとともに記憶し得る（例えば、追加されるリソースの属性内に）。

図１８は、ＲＲ７１０からのリソースの削除に関連付けられたセマンティクス注釈インスタンス更新のための例示的方法７７８を図示する。ステップ７９１では、ＲＲ７１０は、ＳＡＰ７２１に、セマンティクス注釈インスタンス更新要求メッセージとともにＲＲ７１０からのリソースの削除に関する３のケース値を送信する。セマンティクス注釈インスタンス更新要求メッセージはまた、削除されたリソースのＵＲＩを示すＵＲＩフィールドと、影響されるセマンティクス注釈インスタンスを示す識別子フィールドとを含み得る。ステップ７９２では、ＳＡＰ７２１が、リソースのトリプルを影響されるセマンティクス注釈インスタンスから削除する。削除されたリソースのトリプルのみを含む、１つのセマンティクス注釈インスタンスは、空となるであろう。ステップ７９３では、ＳＡＰ７２１が、リソースからセマンティクス注釈インスタンスへの関連付け形態におけるリソースの記録を削除する。ＳＡＰ７２１は、ステップ７９２において識別されたセマンティクス注釈インスタンスのエントリをセマンティクス注釈インスタンスからリソースへの関連付け形態から削除する。ＳＡＰ７２１は、リソースのＵＲＩをセマンティクス注釈インスタンスからリソースへの関連付け形態における他の影響されるエントリから削除する。ステップ７９４では、ＳＡＰ７２１が、セマンティクス注釈インスタンス更新確認をＲＲ７２１に返し得る。

ＲＲ７１０からのリソースの削除に関して、削除されたリソースが通常子リソースを有する場合、例えば、＜ｃｏｎｔａｉｎｅｒ＞が＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞子リソースを有する場合、方法７７８に関して説明されるような前述のステップは、削除されたリソースの最下層の子からリソース自体まで再帰的に実施され得る。例えば、＜ｃｏｎｔａｉｎｅｒ＞を削除すると、ＲＲ７１０は、最初に、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞が削除されるであろうと仮定し、方法７７８に関して示されるステップを開始し、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞の削除をハンドリングする。コンテナ下の全＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースがハンドリングされると、＜ｃｏｎｔａｉｎｅｒ＞リソースは、方法７７８の適切なステップによってハンドリングされ得る。

セマンティクス注釈インスタンス移行が、以下に論じられる。ＳＡＰ７２１は、関わるリソースが新しい場所に移動させられると（物理的または論理的に）、セマンティクス注釈インスタンスを別のセマンティクスリポジトリに移動させることができる。ＳＡＰ７２１は、関わるリソースの一部が新しい場所に移動させられると、影響されるセマンティクス注釈インスタンスを更新することができる。例えば、図６のトレッドミル７３７が、２階から１階に移動させられ、したがって、トレッドミルＡＥは、２階のゲートウェイ７３１から登録解除され、１階のゲートウェイ７３３に登録される。その結果、トレッドミルＡＥは、２階ゲートウェイ７３１ ＣＳＥ内に常駐する現在のＲＲ７１０から削除され、１階ゲートウェイ７３３ ＣＳＥ内に常駐する新しいＲＲ内に作成される。セマンティクス注釈インスタンス移行は、実際には、それぞれ、ケース３（方法７７８）およびケース２（方法７７６）のセマンティクス注釈インスタンス更新の組み合わせによって達成されることができる。図１９は、図６、図１７、および図１８を参照して、セマンティクス注釈インスタンス移行のための例示的方法を図示する。ステップ７９６では、２階のゲートウェイ上のＳＡＰ７２１が、トレッドミルＡＥリソースが２階のゲートウェイ上のＣＳＥＢａｓｅから削除されるので、ケース３（方法７７８）に従って、セマンティクス注釈インスタンスを更新するであろう。ステップ７９７では、１階のゲートウェイ上のＳＡＰが、新しいトレッドミルＡＥリソースが１階のゲートウェイ上のＣＳＥＢａｓｅ下に作成されるであろうため、ケース２（方法７７６）に従って、セマンティクス注釈インスタンスを更新するであろう。

以下は、セマンティクス注釈インスタンス発見の議論である。ＳＡＰ（例えば、ＳＡＰ７２１）は、クライアントクエリに基づいて、ローカルＳＲ内のセマンティクス注釈インスタンスを発見し、返すか、またはクエリを転送することによって、他のＭ２Ｍエンティティ内の他のＳＲと協働することができる。図２０は、セマンティクス注釈インスタンス発見の例示的メッセージフローを図示する。ステップ８１４では、クライアント８１１は、セマンティクス注釈インスタンス発見要求を送信する。ステップ８１４のセマンティクス注釈インスタンス発見要求は、表１１に示されるようなフォーマットであり得る。表１１に示されるようなオプション番号は、必須形態ではなく、オプションに関する同一または類似情報を中継する別のインジケータが、使用され得ることを理解されたい。

図２０を継続して参照すると、ステップ８１５では、被要求側ＳＡＰ８１２が、ステップ８１４の要求を処理し、要求を協働するＳＡＰ８１３に影響することを決定し得る。被要求側ＳＡＰ８１２と協働側ＳＡＰ８１３とは、互いに認知するか、互いに物理的に近いか、または取り引き関係を有し得る。オプション１に対して、リソースのＵＲＩは、リソースが協働するＲＲ（図示せず）内に記憶されていることを示し得る。対応するセマンティクス注釈インスタンスを発見するために、被要求側ＳＡＰ８１２は、ステップ８１４の要求を協働側ＳＡＰ８１３に提供することを決定する。オプション２に対して、協働するＲＲ（図示せず）は、フィルタ基準に一致するリソースを有し得る可能性が高い。したがって、被要求側ＳＡＰ８１２は、ステップ８１４の要求を協働側ＳＡＰ８１３に提供することを決定する。

ステップ８１６では、セマンティクス注釈インスタンス発見要求メッセージが、協働側ＳＡＰ８１３に提供される。ステップ８１７では、協働側ＳＡＰ８１３は、要求を処理し、一致するセマンティクス注釈インスタンス識別子および／または表現を返す。ステップ８１８では、被要求側ＳＡＰ８１２は、発見結果を組み合わせる。ステップ８１９では、被要求側ＳＡＰは、クライアント８１１に、セマンティクス注釈インスタンス発見結果で返信する。

方法８１０に関する例示的状況は、図６のジム使用ケースを参照して見られ得る。例えば、クライアント８１１は、図６のジム内の全トレッドミルに対するセマンティクス注釈インスタンスの発見を所望し得る。１階のゲートウェイ７３３上のＳＡＰ７２１は、そのような要求を受信する。すなわち、要求を転送し、発見結果を組み合わせることによって、２階のゲートウェイ７３１と協働するであろう。

以下に論じられるのは、ｏｎｅＭ２Ｍに関連付けられた追加の例である。本明細書に論じられるように、リソースのセマンティクスは、リソース、関係、および値から成るリソース−関係−値トリプルによって説明されることができる。値は、クラスまたは他のリソースであることができる。以下は、いくつかの例である。
・ Ａ ｃｏｎｔｅｎｔ ｉｎｓｔａｎｃｅ（リソース）ｈａｓＴｙｐｅ（関係）ｔｅｍｐｅｒａｔｕｒｅＲｅａｄｉｎｇ（クラス）
・ Ａ ｃｏｎｔｅｎｔ ｉｎｓｔａｎｃｅ（リソース）ｇｅｎｅｒａｔｅｄＢｙＳａｍｅＡｐｐｌｉｃａｔｉｏｎＡｓ（関係）ａｎｏｔｈｅｒ ｃｏｎｔｅｎｔ ｉｎｓｔａｎｃｅ（リソース）

通常リソース（例えば、＜ＡＥ＞、＜ｃｏｎｔａｉｎｅｒ＞）に対して、リソース−関係−値トリプルにおいて、リソース自体は、固定であり、既知であるので、欠けているのは、関係−値ダブルの集合である。新しい＜ｓｅｍａｎｔｉｃｓ＞子リソースが、追加され、セマンティクス記述をリソースに提供することができる。リソースの＜ｓｅｍａｎｔｉｃｓ＞子リソースは、リソースのセマンティクスを記述するその記述属性に関係−値ダブルを含む。

図２１は、＜ｓｅｍａｎｔｉｃｓ＞リソースのリソース構造を図示する。＜ｓｅｍａｎｔｉｃｓ＞リソースの記述属性は、複合データタイプである、関係−値ダブルのリストを含む。複合データタイプは、表１７に示されるフォーマットを伴う関係−値ダブルのリストである。表１２および表１３は、それぞれ、＜ｓｅｍａｎｔｉｃｓ＞リソースの子リソースおよび属性を示す。表１２、表１３、および本明細書で論じられる他の表は、例である。以下は、＜ｓｅｍａｎｔｉｃｓ＞子リソースがそれらに追加される場合、セマンティクス情報をイネーブルにし得る、リソースの例示的リストである：＜ＣＳＥＢａｓｅ＞、＜ｒｅｍｏｔｅＣＳＥ＞、＜ＡＥ＞、＜ｃｏｎｔａｉｎｅｒ＞、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞、＜ｇｒｏｕｐ＞、および＜ｎｏｄｅ＞。

図２２は、図７に表されるトレッドミルＡＥのセマンティクス情報を反映する、セマンティクス子リソース記述を図示する。代替として、記述属性のコンテンツは、図２３に示されるように、＜ｓｅｍａｎｔｉｃｓ＞リソースの子リソースに移動させられ得る。表１４は、＜ｓｅｍａｎｔｉｃｓ＞リソースが新しい子リソース＜ｒｅｌａｔｉｏｎＤｏｕｂｌｅ＞を有することを示す。

図２３および表１４を継続して参照すると、ＳＡＰ７２１は、単一セマンティクス注釈インスタンスを作成および使用して、複数のリソースおよび注釈インスタンスを記述し得、それは、主語リソースから離れて記憶され、記憶最適化および柔軟性を提供する。ＳＡＰ７２１は、遠隔で記憶される場合、リソースとその注釈との間の関連付けを維持し、発見機能性を保存し得る。例えば、＜ｓｅｍａｎｔｉｃｓ＞リソースによって提供される記述は、追加の柔軟性を提供するために拡張され得る。主語属性は、複数のリソースを記述するための単一セマンティクス注釈インスタンスをイネーブルにし、記憶場所のための柔軟性を提供する。同時に、それは、＜ｒｅｌａｔｉｏｎＤｏｕｂｌｅ＞の単一主語が親リソースである場合、便宜かつ記憶最適化のために、省略され得る。リソースとその注釈との間の関連付けは、遠隔で記憶されるとき、遠隔注釈を伴う＜ｓｅｍａｎｔｉｃｓ＞リソースを指すリンク属性の使用を通して保存される。

＜ｒｅｌａｔｉｏｎＤｏｕｂｌｅ＞のリソースツリー構造は、図２４に示される。表１５は、子リソースを示す。表１６は、＜ｒｅｌａｔｉｏｎＤｏｕｂｌｅ＞リソースの属性を示す。ここに適用され得る共通属性は、表１３に列挙される。

＜ｒｅｌａｔｉｏｎＤｏｕｂｌｅ＞の記述属性は、表１７に示されるような複合データタイプを有する。記述属性は、フィールド「関係」および「値」を含む。関係フィールドは、オントロジリポジトリ内に記憶される関係リソースを指す、任意のＵＲＩのデータタイプを有する。値は、任意のデータタイプであり得る。したがって、いずれも、ＸＳＤ内に定義されたクラスまたはそれらのプリミティブデータタイプ（例えば、ｄｕｒａｔｉｏｎ、ｄａｔｅＴｉｍｅ等）等の任意の可能なデータタイプの列挙から成り得る。図２５は、トレッドミルＡＥに対する関係−値ダブルを含む、＜ＡＥ＞リソースおよび＜ｃｏｎｔａｉｎｅｒ＞リソースのセマンティクス子リソースの例を示す。

新しいａｎｎｏｔａｔｉｏｎＩｎｓｔ属性が、開示される。ａｎｎｏｔａｔｉｏｎＩｎｓｔ属性は、セマンティクス注釈インスタンスにおいて注釈を付けられたリソースに追加され得る。ａｎｎｏｔａｔｉｏｎＩｎｓｔ属性は、セマンティクス注釈インスタンスの識別子を記憶する。このａｎｎｏｔａｔｉｏｎＩｎｓｔ属性を用いることで、リソースとセマンティクス注釈インスタンスとは、関連付けられることができる。リソースのセマンティクスに更新があると、セマンティクス注釈インスタンスも同様に、更新されることができる。＜ｓｅｍａｎｔｉｃｓ＞子リソースを有するリソースも、ａｎｎｏｔａｔｉｏｎＩｎｓｔ属性とともに追加されるであろう。

以下に論じられるのは、セマンティクスデータベース（例えば、セマンティクスリポジトリ７２０）である。＜ＳＤ＞は、図２６に示されるように、セマンティクスデータベース内のセマンティクス注釈のＲＥＳＴＦＵＬ動作のためのリソースを記憶する。＜ＳＤ＞リソースは、ＣＳＥＢａｓｅ下に位置することができる。＜ＳＤ＞のフォーマット属性は、任意の数のトリプル（Ｎ−トリプル）であり得る、セマンティクスデータベース内のセマンティクス情報のフォーマットを示す。表１８は、＜ＳＤ＞の子リソースを示す。表１９は、＜ＳＤ＞の属性を示し、表１３は、ここで適用可能であり得るさらなる属性を示す。代替として、＜ＳＤ＞リソースは、セマンティクスデータベースにアクセスするためのＲＥＳＴＦＵＬインターフェースの役割を果たす仮想リソースであり得る。したがって、＜ＳＤ＞リソースは、どんな子リソースまたは属性も有していないこともある。注釈子リソースは、ＣＳＥＢａｓｅ下に位置することができる。「仮想リソース」は、ＥＴＳＩ ｍ２ｍおよびｏｎｅＭ２Ｍにおいて使用される。仮想リソースは、インターフェースの役割を果たすと見なされ得、通常、任意の子リソースまたは属性を有していない。

＜ａｎｎｏｔａｔｉｏｎ＞リソースは、セマンティクス注釈要求が送信されるときに標的化される。＜ａｎｎｏｔａｔｉｏｎ＞のリソースツリー構造は、図２７に示される。表２０は、＜ａｎｎｏｔａｔｉｏｎ＞の子リソースを示す。＜ａｎｎｏｔａｔｉｏｎ＞リソースの属性は、表２１に示され、表１３は、ここで適用可能であり得るさらなる属性を示す。代替として、＜ａｎｎｏｔａｔｉｏｎ＞リソースは、ＲＥＳＴＦＵＬインターフェースとしての役割を果たし、セマンティクス注釈をリソースに対して行い得る仮想リソースであり得る。

図２２におけるトレッドミルＡＥのセマンティクスは、図２８に示されるように、Ｔｕｒｔｌｅフォーマットでセマンティクス注釈インスタンスに注釈を付けられる。

以下は、セマンティクス注釈に関するＲＯＡおよびＳＯＡの議論である。前述のように、ｏｎｅＭ２Ｍは、ｏｎｅＭ２Ｍサービス層によってサポートされる能力を定義する。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）の組を備えている共通サービスエンティティ（ＣＳＥ）としてインスタンス化される。一例として、開示されるＳＡＰ７２１は、図２９に示されるように、セマンティクス注釈下において、ＣＳＥ内にｏｎｅＭ２Ｍ ＣＳＦとしてホストされ得る。別の例では、ＳＡＰ７２１は、Ｍ２Ｍセマンティクスサポート（例えば、図８）の機能性をサポートするセマンティクスＣＳＦまたはデータ管理およびリポジトリＣＳＦの一部であり得る。ｏｎｅＭ２Ｍバーティカル（例えば、Ｍｃａ参照点を介して、セマンティクス注釈ＣＳＦと通信し、リソースのセマンティクス注釈を要求するＡＥ）は、セマンティクス注釈インスタンスを発見する。他のＣＳＥは、Ｍｃｃ参照点を介して、セマンティクス注釈ＣＳＦにトークし、リソースのセマンティクス注釈を要求するか、またはセマンティクス注釈インスタンスを発見し得る。

図３０は、ｏｎｅＭ２Ｍサービスコンポーネントアーキテクチャ（ＴＳ−０００７サービスコンポーネントアーキテクチャ−Ｖ−０．４．０）内のセマンティクス注釈の実装アーキテクチャを図示する。ｏｎｅＭ２Ｍバーティカル（例えば、Ｍｃａ参照点を介して、セマンティクス注釈サービスコンポーネントと通信し、リソースのセマンティクス注釈を要求するＡＥ）は、セマンティクス注釈インスタンスを発見する。本明細書に開示されるメッセージおよびプロシージャは、参照点に適用される。

図３１は、本明細書で論じられる方法およびシステムに基づいて生成され得る例示的ディスプレイ（例えば、グラフィカルユーザインターフェース）を図示する。ディスプレイインターフェース９１０（例えば、タッチスクリーンディスプレイ）は、ブロック９１１において、表１から表２１のパラメータ等のセマンティクス注釈またはセマンティクスリポジトリに関連付けられたテキストを提供し得る。別の例では、本明細書で論じられるステップのいずれかの進捗度（例えば、送信されるメッセージまたはステップの成功）は、ブロック９１１に表示され得る。加えて、グラフィカル出力９１２が、ディスプレイインターフェース９１０上に表示され得る。グラフィカル出力９１２は、セマンティクス注釈またはセマンティクスリポジトリに関連付けられたデバイスまたはリソースのトポロジ（例えば、図６、図１１、図１３等）、本明細書で論じられる任意の方法またはシステムの進捗度のグラフィカル出力（例えば、図１２、図１４等）等であり得る。

本明細書に現れる請求項の範囲、解釈、または用途をいかようにも限定するわけではないが、本明細書に開示される実施例のうちの１つ以上のものの技術的効果は、効率的セマンティクスベースのクエリを促進する（例えば、クエリ処理時間を短縮する）方法でリソースセマンティクス情報を記憶および構築する方法に対する調節を提供することである。

従来のＥＴＳＩ Ｍ２Ｍシステムでは、Ｍ２Ｍリソースのセマンティクス注釈は、一貫したデータ移行およびデータ相互運用性を異種Ｍ２Ｍアプリケーションに提供するように、セマンティクス情報をＭ２Ｍリソースに追加する方法である。セマンティックに注釈を付けられたＭ２Ｍリソースは、リソースによって提供されるデータおよび提供されるデータの意味を理解するＭ２Ｍアプリケーションによってコンタクトされることができる。これらの注釈は、従来のＭ２Ｍシステム単独より有意義な記述を提供し、Ｍ２Ｍデータをエクスポーズする。とりわけ、リソース間の関係を記述するために、それは、別のＥＴＳＩ Ｍ２Ｍリソースを指すＵＲＩを有する関係属性を定義する。

ｏｎｅＭ２Ｍアーキテクチャが、本明細書に説明される主題を図示するために、本明細書で背景として説明され、使用され得るが、本明細書に説明される主題の実装は、本開示の範囲内にとどまりながら、変動し得ることを理解されたい。当業者はまた、開示される主題が、前述のｏｎｅＭ２Ｍアーキテクチャを使用する実装に限定されず、むしろ、ＥＴＳＩ Ｍ２Ｍならびに他のＭ２Ｍシステムおよびアーキテクチャ等の他のアーキテクチャおよびシステム内に実装され得ることを認識するであろう。

図３２Ａは、セマンティクスアーキテクチャ７０１およびその中のコンポーネント等の１つ以上の開示される概念が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であり得る。

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

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

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

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

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

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

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

図３２Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。図３２Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、開示される主題と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このデバイス（ゲートウェイ７３３、周囲センサ７３４、体重計７３６、トレッドミル７３７、血圧モニタ７３５、クライアント７１０、セマンティクスリポジトリ７２０、およびその他に類似する）は、セマンティクス注釈のための開示されるシステムおよび方法を使用する、デバイスであり得る。

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

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

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

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

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

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

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

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

図３２Ｄは、例えば、図３２Ａおよび３２ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る、例示的なコンピュータシステム９０のブロック図である。コンピュータシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶あるいはアクセスされる。そのようなコンピュータ読み取り可能な命令は、コンピュータシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セマンティクス注釈インスタンスの生成等、セマンティクス注釈のための開示されたシステムおよび方法に関係付けられるデータを受信、生成、および処理し得る。

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

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

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

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

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

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

図で図示されるような本開示の主題の方法、システム、または装置は、好ましい実施例を説明する際に、明確にするために、特定の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

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

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に制約されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
デバイスであって、
プロセッサと、
前記プロセッサと結合されたメモリと
を備え、
前記メモリは、実行可能命令を含み、前記命令は、前記プロセッサによって実行されると、
クライアントデバイスの要求に基づいて、リソースのセマンティクス注釈インスタンスを生成することであって、前記セマンティクス注釈インスタンスは、前記リソースを反映する様式で階層的に記憶され、前記セマンティクス注釈インスタンスは、前記クライアントデバイスからの要求の履歴に関連付けられたポリシに基づいて記憶される、ことと、
前記要求に基づいて、前記セマンティクス注釈インスタンスを前記クライアントデバイスに提供することと
を含む動作を前記プロセッサに達成させる、
デバイス。
（項目２）
前記要求は、セマンティクス注釈要求である、項目１に記載のデバイス。
（項目３）
前記ポリシは、前記要求のスコープ内に示される前記リソースの頻度に基づく、項目１に記載のデバイス。
（項目４）
前記ポリシは、前記セマンティクス注釈インスタンスを生成することにおけるオーバーヘッドに基づく、項目１に記載のデバイス。
（項目５）
前記ポリシは、遠隔読み出しが前記リソースセマンティクス情報の読み出しのために使用されるかどうかに基づく、項目１に記載のデバイス。
（項目６）
前記リソースは、前記リソースのセマンティクス情報を表すセマンティクス子リソースを有する、項目１に記載のデバイス。
（項目７）
前記要求は、前記リソースの前記セマンティクス注釈インスタンスのユニフォームリソースインジケータを含む、項目１に記載のデバイス。
（項目８）
前記動作は、どのセマンティクス注釈インスタンスが前記リソースに関連するかの通知を提供することをさらに含む、項目１に記載のデバイス。
（項目９）
前記動作は、前記リソースの関連付けられたセマンティクスが更新された場合、前記リソースの前記セマンティクス注釈インスタンスを更新することをさらに含む、項目１に記載のデバイス。
（項目１０）
前記動作は、所定のスコープ下の前記リソースが作成または削除された場合、前記リソースの前記セマンティクス注釈インスタンスを更新することをさらに含む、項目１に記載のデバイス。
（項目１１）
前記動作は、前記リソースが第１の場所から第２の場所に移動させられたことに応答して、前記セマンティクス注釈インスタンスを別のデバイスに移動させるための命令を提供することをさらに含む、項目１に記載のデバイス。
（項目１２）
前記動作は、前記要求に基づいて、前記セマンティクス注釈インスタンスを発見することをさらに含む、項目１に記載のデバイス。
（項目１３）
前記要求は、前記リソースのユニフォームリソースインジケータを含み、前記ユニフォームリソースインジケータは、前記リソースの対応するセマンティクス注釈インスタンスを発見するために使用される、項目１に記載のデバイス。
（項目１４）
前記要求は、前記リソースの対応するセマンティクス注釈インスタンスを発見するために、前記リソースに関連付けられたフィルタ基準を含む、項目１に記載のデバイス。
（項目１５）
前記フィルタ基準は、関係−値の値を含む、項目１４に記載のデバイス。
（項目１６）
セマンティクス注釈のための方法であって、前記方法は、
リソースのセマンティクス注釈インスタンスを自動的に生成することと、
前記リソースを反映する階層様式でセマンティクス注釈インスタンスを記憶することと、
要求に基づいて、どのセマンティクス注釈インスタンスが前記リソースに関連するかの通知を提供することと
を含む、方法。
（項目１７）
前記リソースの関与セマンティクスが更新された場合、前記リソースの前記セマンティクス注釈インスタンスを更新することをさらに含む、項目１６に記載の方法。
（項目１８）
所定のスコープ下の前記リソースが作成または削除された場合、前記リソースの前記セマンティクス注釈インスタンスを更新することをさらに含む、項目１６に記載の方法。
（項目１９）
前記リソースが、第１の場所から第２の場所に移動させられた場合、前記セマンティクス注釈インスタンスを別のデバイスに移動させるための命令を提供することをさらに含む、項目１６に記載の方法。
（項目２０）
前記要求は、前記リソースの対応するセマンティクス注釈インスタンスを発見するために、前記リソースに関連付けられたフィルタ基準を含む、項目１６に記載の方法。

Claims (20)

1. デバイスであって、
   プロセッサと、
   前記プロセッサと結合されたメモリと
   を備え、
   前記メモリは、実行可能命令を含み、前記命令は、前記プロセッサによって実行されると、
   クライアントデバイスの要求に基づいて、リソースのセマンティクス注釈インスタンスを生成することであって、前記セマンティクス注釈インスタンスは、前記リソースを反映する様式で階層的に記憶され、前記セマンティクス注釈インスタンスは、前記クライアントデバイスからの要求の履歴に関連付けられたポリシに基づいて記憶される、ことと、
   前記要求に基づいて、前記セマンティクス注釈インスタンスを前記クライアントデバイスに提供することと
   を含む動作を前記プロセッサに達成させる、
   デバイス。
2. 前記要求は、セマンティクス注釈要求である、請求項１に記載のデバイス。
3. 前記ポリシは、前記要求のスコープ内に示される前記リソースの頻度に基づく、請求項１に記載のデバイス。
4. 前記ポリシは、前記セマンティクス注釈インスタンスを生成することにおけるオーバーヘッドに基づく、請求項１に記載のデバイス。
5. 前記ポリシは、遠隔読み出しが前記リソースセマンティクス情報の読み出しのために使用されるかどうかに基づく、請求項１に記載のデバイス。
6. 前記リソースは、前記リソースのセマンティクス情報を表すセマンティクス子リソースを有する、請求項１に記載のデバイス。
7. 前記要求は、前記リソースの前記セマンティクス注釈インスタンスのユニフォームリソースインジケータを含む、請求項１に記載のデバイス。
8. 前記動作は、どのセマンティクス注釈インスタンスが前記リソースに関連するかの通知を提供することをさらに含む、請求項１に記載のデバイス。
9. 前記動作は、前記リソースの関連付けられたセマンティクスが更新された場合、前記リソースの前記セマンティクス注釈インスタンスを更新することをさらに含む、請求項１に記載のデバイス。
10. 前記動作は、所定のスコープ下の前記リソースが作成または削除された場合、前記リソースの前記セマンティクス注釈インスタンスを更新することをさらに含む、請求項１に記載のデバイス。
11. 前記動作は、前記リソースが第１の場所から第２の場所に移動させられたことに応答して、前記セマンティクス注釈インスタンスを別のデバイスに移動させるための命令を提供することをさらに含む、請求項１に記載のデバイス。
12. 前記動作は、前記要求に基づいて、前記セマンティクス注釈インスタンスを発見することをさらに含む、請求項１に記載のデバイス。
13. 前記要求は、前記リソースのユニフォームリソースインジケータを含み、前記ユニフォームリソースインジケータは、前記リソースの対応するセマンティクス注釈インスタンスを発見するために使用される、請求項１に記載のデバイス。
14. 前記要求は、前記リソースの対応するセマンティクス注釈インスタンスを発見するために、前記リソースに関連付けられたフィルタ基準を含む、請求項１に記載のデバイス。
15. 前記フィルタ基準は、関係−値の値を含む、請求項１４に記載のデバイス。
16. セマンティクス注釈のための方法であって、前記方法は、
    リソースのセマンティクス注釈インスタンスを自動的に生成することと、
    前記リソースを反映する階層様式でセマンティクス注釈インスタンスを記憶することと、
    要求に基づいて、どのセマンティクス注釈インスタンスが前記リソースに関連するかの通知を提供することと
    を含む、方法。
17. 前記リソースの関与セマンティクスが更新された場合、前記リソースの前記セマンティクス注釈インスタンスを更新することをさらに含む、請求項１６に記載の方法。
18. 所定のスコープ下の前記リソースが作成または削除された場合、前記リソースの前記セマンティクス注釈インスタンスを更新することをさらに含む、請求項１６に記載の方法。
19. 前記リソースが、第１の場所から第２の場所に移動させられた場合、前記セマンティクス注釈インスタンスを別のデバイスに移動させるための命令を提供することをさらに含む、請求項１６に記載の方法。
20. 前記要求は、前記リソースの対応するセマンティクス注釈インスタンスを発見するために、前記リソースに関連付けられたフィルタ基準を含む、請求項１６に記載の方法。