JP2021515317A

JP2021515317A - 分散しているセマンティックデータに対するセマンティック操作および推論サポート

Info

Publication number: JP2021515317A
Application number: JP2020545114A
Authority: JP
Inventors: リ，シュウ; ワン，チョンガン; リ，クァン
Original assignee: コンヴィーダワイヤレス，エルエルシー
Priority date: 2018-02-27
Filing date: 2019-02-27
Publication date: 2021-06-17
Also published as: KR20200124267A; WO2019168912A1; CN111788565A; US20210042635A1; EP3759614A1

Abstract

【課題】セマンティック推論操作に関する問題を解決する方法、システムおよび装置。【解決手段】異なるカスタマイズされた規則またはユーザ定義規則が、アプリケーションの必要性に基づいて定義される場合があり、これにより、事実が同じ初期事実に基づいているとしても、異なる推測事実を導き出すことができる。

Description

関連出願の相互参照
本出願は、２０１８年２月２７日に出願の米国特許仮出願番号第６２／６３５，８２７号、表題「分散しているセマンティックデータに対するセマンティック操作および推論サポート」の利点を請求し、その内容は、参考として本明細書に組み込まれる。

セマンティックウェブは、ワールドワイドウェブコンソーシアム（World Wide Web Consortium：Ｗ３Ｃ）による標準化を通したウェブの拡張である。標準化では、ウェブ上の共通データフォーマットおよび交換プロトコル、最も、基本的には、リソースディスクリプションフレームワーク（Resource Description Framework：ＲＤＦ）を促進している。
セマンティックウェブは、リソースディスクリプションフレームワーク（ＲＤＦ）、ウェブオントロジー言語（Web Ontology Language：ＯＷＬ）、およびエクステンシブルマークアップランゲージ（Extensible Markup Language：ＸＭＬ）のようなデータ向けに特別に設計される言語で公開することを伴う。これらの技術は、組み合わされて、リンクトデータのウェブを介してウェブ文書のコンテンツを補充または置き換えるディスクリプションを提供する。したがって、コンテンツは、ウェブのアクセス可能なデータベースに格納された記述データとして、または文書内のマークアップとして、特に、ＸＭＬで点在させたエクステンシブルＨＴＭＬ（EXtensible HTML：ＸＨＴＭＬ）、もしくは、より多くの場合、レイアウトまたはレンダリングキューが別々に格納されたＸＭＬで純粋にそれ自体を表示させている場合がある。

セマンティックウェブスタックは、図１に示すように、Ｗ３Ｃによって規定されたセマンティックウェブのアーキテクチャを示す。構成要素の機能および関係性は、下記のように要約することができる。ＸＭＬは、文書内でコンテンツ構造に基本的なシンタックスを提供するが、その中に含まれるコンテンツの意味とセマンティクスを関連するものではない。ＸＭＬは、Ｔｕｒｔｌｅなどの他のシンタックスが存在するので、今のところ、多くの場合、セマンティックウェブ技術の必要な構成要素ではない。Ｔｕｒｔｌｅは、事実上の標準ではあるが、正式な標準化プロセスを通したものではない。

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

ＲＤＦは、オブジェクト（「ウェブリソース」）および主語・述語・目的語、例えば、Ｓ−Ｐ−ＯトリプルまたはＲＤＦトリプルの形態でその関係性を指すデータモデルを表すための簡易言語である。ＲＤＦベースのモデルは、種々のシンタックス、例えば、ＲＤＦ／ＸＭＬ、Ｎ３、Ｔｕｒｔｌｅ、およびＲＤＦａによって表すことが可能である。ＲＤＦは、セマンティックウェブの基本的な標準である。

ＲＤＦグラフは、エッジが、ＲＤＦトリプルの「述語」を表し、その一方で、グラフノードがＲＤＦトリプルの「主語」または「述語」を表す有向グラフである。言い換えると、ＲＤＦトリプルで説明されているリンク構造は、このような有向ＲＤＦグラフを形成する。

ＲＤＦスキーマ（RDF Schema：ＲＤＦＳ）は、ＲＤＦを拡張するものであり、かつＲＤＦベースのリソースのプロパティおよびクラスを記述するためのボキャブラリであり、このようなプロパティおよびクラスの一般化階層に対するセマンティクスを伴う。

ＯＷＬは、プロパティおよびクラスの記述に対してより多くのボキャブラリ、特に、クラス間の関係（例えば、独立性）、基数（例えば、「正確に１」）、等価、リッチタイプのプロパティ、プロパティの特性（例えば、対称性）、列挙型クラスなどを加える。

ＳＰＡＲＱＬは、ウェブ上またはＲＤＦストア（例えば、セマンティックグラフストア）内のＲＤＦグラフコンテンツ（例えば、ＲＤＦトリプル）を問い合わせて、操作するセマンティックウェブデータソース向けのプロトコルおよび問い合わせ言語である。
・ＳＰＡＲＱＬ１．１問い合わせ、ＲＤＦグラフの問い合わせ言語は、データがＲＤＦとして元々格納されているか、またはミドルウェアを介してＲＤＦとして表示されるか、いずれにせよ、多様なデータソース全体にわたる問い合わせを表すために使用される場合がある。ＳＰＡＲＱＬには、それらの論理積と論理和と共に、所要および任意選択のグラフパターンを問い合わせする１つまたは複数のケイパビリティを含む場合がある。ＳＰＡＲＱＬはまた、集約、サブ問い合わせ、否定、式による値の作成、拡張可能な値のテスト、および、ソースＲＤＦグラフによる問い合わせの制約もサポートする。ＳＰＡＲＱＬ問い合わせの結果は、結果セットまたはＲＤＦグラフである場合がある。
・ＳＰＡＲＱＬ１．１更新は、ＲＤＦグラフの更新言語である。これは、ＲＤＦに対するＳＰＡＲＱＬ問い合わせ言語に由来するシンタックスを使用する。更新操作は、セマンティックグラフストア内のグラフの集合に実施される。各操作が、セマンティックグラフストア内の、ＲＤＦグラフを、更新、作成、および削除するために行われる。

規則は、コンピュータ科学における概念であり、ＩＦ−ＴＨＥＮ構文である。一部のデータセット内で確認可能な一部の条件（ＩＦ部分）が適用される場合、結論（ＴＨＥＮ部分）が処理される。オントロジーは、ドメイン知識を記述する場合があるが、規則は特定の知識または関係を記述する別のアプローチであり、場合によっては、ＯＷＬで使用されるディスクリプション論理を用いても、難しいか、または直接記述することができないものである。規則はまた、セマンティック推測／推論に使用される場合がある（例えば、ユーザは、自身の推論規則を規定することができる）。

ＲＩＦは、規則交換形式である。コンピュータ科学および論理プログラミングコミュニティでは、２者は異なるものであるが、規則を理解するには密接に関連している。１つは、コンピュータプログラムにおける命令の着想に密接に関連している。一定の条件が適用される場合、いくつかのアクションが実行される。このような規則は、生成規則と称されることが多い。生成規則の一例は、「お客様が１００，０００マイル以上飛行した場合、そのお客様を、ゴールドメンバーステータスにアップグレードする」である。

あるいは、規則は、あらゆる事柄についての事実を述べるものとして見なされる場合がある。しばしば、宣言型規則として称されるこれらの規則は、「ＰならばＱである」といった形式の文になると理解される。宣言型規則の一例は、「ある人物が現在アメリカ合衆国の大統領である場合、その人物の現在の住居は、ホワイトハウスである」である。

ＳＩＬＫ、ＯｎｔｏＢｒｏｋｅｒ、Ｅｙｅ、ＶａｍｐｉｒｅＰｒｉｍｅ、Ｎ３−論理、およびＳＷＲＬ（宣言型規則言語）、ならびに、Ｊｅｓｓ、Ｄｒｏｏｌｓ、ＩＢＭＩＬｏｇ、およびＯｒａｃｌｅＢｕｓｉｎｅｓｓＲｕｌｅｓ（生成規則言語）など、多くの規則言語が存在する。多くの言語には、宣言型規則言語および生成規則言語の両方の特性が取り入れられている。規則セットを統合したい場合、または１つの規則セットから別の規則セットに情報をインポートしたい場合に、さまざまな言語の規則セットが大量にあるために困難が生じる場合がある。異なる言語の規則セットを用いて、規則エンジンを動作させる方法が、本明細書で考慮される。

Ｗ３Ｃ規則交換形式（Rule Interchange Format：ＲＩＦ）は、規則セット統合および合成を促進するために開発された標準である。ＲＩＦは、さまざまな特性の規則言語を表すＲＩＦコア、ＲＩＦ基本論理方言（Basic Logic Dialect：ＢＬＤ）、ＲＩＦ生成規則方言（Production Rule Dialect：ＰＲＤ）などの相互連結した方言のセットを含む。例えば、下記で論じる例は、ＲＩＦコア（最も基本的な１つである）に基づくものである。ＲＩＦ方言ＢＬＤは、論理的定義機能を可能にすることによってＲＩＦコアを拡張する。ＲＩＦ方言ＰＲＤは、規則の優先順位付け、否定、および知識ベース修正の明確なステートメントを可能にすることによってＲＩＦコアを拡張する。

下記は、ＲＩＦの例である。この例は、セマンティックウェブ全体にわたる映画および演劇に関するデータの統合に関する。例えば、ＩＭＤｂ、インターネット・ムービー・データベース（http://imdb.com）からと、ＤＢペディア（http://dbpedia.org）からの映画に関するデータを統合したい場合を想定する。両方のリソースは、映画のキャストの中の役者に関する事実を含むが、ＤＢペディアは、これらの事実を２項関係（述語またはＲＤＦプロパティとも呼ばれる）として表す。

ＤＢペディアでは、例えば、データが、ある役者がある映画のキャストであるという事実を表す場合がある。
・ starring(?Film ?Actor)
この場合、プレースホルダとして、接頭辞付き変数「？」を用いる。この例で使用される変数名は、マシンではなく、人間の読者に意味がある。これらの変数名は、ＤＢペディアｓｔａｒｒｉｎｇリレーションの１つ目の引数は映画、２つ目の引数は誰がこの映画に出演した役者なのかを読み手に伝えることを意図している。
しかし、ＩＭＤｂでは、データは、類似のリレーションを有していない。代わりに、データは、役を演じる役者に関して下記の形式の事実を記述する場合がある。
・ playsRole(?Actor ?Role)
また、１つは、映画の中での役（キャラクタ）に関して下記の形式の事実を記述する場合がある。
・ roleInFilm(?Role ?Film)
したがって、例えば、ＤＢペディアでは、データは、事実としてVivien LeighがStreetcar Named Desireのキャストであったという情報を表す。
・ starring(Streetcar VivienLeigh)
ＩＭＤｂでは、データは、Vivien Leighは、Blanche DuBoisの役を演じたという、２つの要素の情報を表す。
・ playsRole(VivienLeigh BlancheDubois)
また、Blanche DuBoisは、Streetcar Named Desireのキャラクタである。
・ roleInFilm(BlancheDubois Streetcar)

このデータを組み合わせるには課題がある。２つのデータソース（ＩＭＤｂとＤＢペディア）が、異なるボキャブラリ（リレーション名、ｓｔａｒｒｉｎｇ，ｐｌａｙｓＲｏｌｅ，ｒｏｌｅＩｎＦｉｌｍ）を使用するだけでなく、構造も異なる。このデータを組み合わせるためには、下記の規則のようなものが基本的に必要であるといえる。「ＩＭＤｂデータベースに、ある役者がある役／キャラクタを演じ、そのキャラクタはある映画の中のものであるという２つの事実がある場合、ＤＢペディアデータベースにはその役者は、その映画の中にいるという１つの事実がある」。この上述の規則は、下記のように、ＲＩＦ規則として記述することができる（太字の文字は、ＲＩＦによって定められたキーワードであり、ＲＩＦの仕様に関する詳細は、ＲＩＦＰｒｉｍｅｒ、https://www.w3.org/2005/rules/wiki/Primerで確認することができる）。
Document(
Prefix(rdf <http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
Prefix(rdfs <http://www.w3.org/2000/01/rdf-schema#>)
Prefix(imdbrel <http://example.com/imdbrelations#>)
Prefix(dbpedia <http://dbpedia.org/ontology/>)
Group(
Forall ?Actor ?Film ?Role (
If And(?Actor # imdbrel:Actor
?Film # imdbrel:Film
?Role # imdbrel:Character
imdbrel:playsRole(?Actor ?Role)
imdbrel:roleInFilm(?Role ?Film))
Then dbpedia:starring(?Film ?Actor)
)
)
)

セマンティック推論。概してセマンティック推論または推測は、知識ベースで明示的に表されていない事実を導き出すことを意味する。言い換えると、それは、既存の知識ベースから新しい暗黙の知識を導き出すメカニズムである。例えば、考慮されるデータセット（初期事実／知識）は、関係性（Flipper is-a Dolphin（フリッパはイルカである）−インスタンスに関する事実）を含む場合がある。事実および知識は、本明細書で同じ意味で用いられる場合があることに留意されたい。オントロジーは、「every Dolphin is also a Mammal（どのイルカもまた哺乳類である）−概念に関する事実」と宣言する場合がある。推論規則が「IF A is an instance of class B and B is a subclass of class C, THEN A is also an instance of class C（ＡはクラスＢのインスタンスであり、Ｂは、クラスＣのサブクラスである場合、Ａはまた、クラスＣのインスタンスである）」と、述べる場合、推論処理によって規則を初期事実に適用することで、新しいステートメント「Flipper is-a Mammal（フリッパは哺乳類である）」を推測することができ、これは初期事実の要素ではなかったが、推論に基づいて導き出された暗黙の知識／事実である（参考、Ｗ３ＣＳｅｍａｎｔｉｃＩｎｆｅｒｅｎｃｅ，www.w3.org/standards/semanticweb/inference）。
上記の例から、下記のセマンティック推論と関係するいくつかの主要概念があることが分かる。
1. 知識／事実ベース（事実および知識は、本出願では同じ意味で用いられる）
2. セマンティック推論規則
3. 推測事実

下記のセクションでは、知識ベースおよびセマンティック規則に関する詳細を提示する。上記の例に対してセマンティック推論処理を実装するために、セマンティック推論器が使用される場合がある（ＳｅｍａｎｔｉｃＲｅａｓｏｎｅｒ、https://en.wikipedia.org/wiki/Semantic_reasoner）。典型的には、セマンティック推論器（推論エンジン、規則エンジン、または単に推論器）は、ソフトウェアの一部であり、推論規則のセットを使用して表明される事実のセットから論理的帰結を推測することができるものである。いくつかのオープンソースセマンティック推論器があり、次のセクションでは、ＡｐａｃｈｅＪｅｎａ（https://jena.apache.org/documentation/inference/）によって提供される例示的推論器について詳細を提示する。加えて、セマンティック推論または推測は、通常、追加の情報を導き出す抽出処理を意味し、一方で、セマンティック推論器は、推論タスクを実施する特定のコードオブジェクトを指す。

知識ベース（Knowledge Base：ＫＢ）は、コンピュータシステムによって使用される複雑な構造化および非構造化情報を格納するために使用される技術である（https://en.wikipedia.org/wiki/Abox）（ＴＢｏｘ、https://en.wikipedia.org/wiki/Tbox）。ＫＢの構成は、下記の形式を有する。
知識ベース＝ＡＢｏｘ＋ＴＢｏｘ

用語、ＡＢｏｘおよびＴＢｏｘは、ステートメント／事実の異なる２つのタイプを説明するのに用いられる。Ｔｂｏｘステートメントは、制御されるボキャブラリ、例えば、クラスおよびプロパティ（例えば、スキームまたはオントロジー定義）のセットを基準にしてシステムを説明する。ＡＢｏｘは、そのボキャブラリに関するＴＢｏｘ対応ステートメントである。
例えば、ＡＢｏｘステートメントは、通常、下記の形式を有する。
A is an instance of B（Ａは、Ｂのインスタンスである）または
John is a Person（ジョンは人である）
これに対して、ＴＢｏｘステートメントは、通常、次の形式を有する。
All Students are Persons or（全ての生徒は人である）または
There are two types of Persons: Students and Teachers（２種類の人が存在する：生徒および教師）（例えば、Ｓｔｕｄｅｎｔｓ（生徒）およびＴｅａｃｈｅｒｓ（教師）は、Ｐｅｒｓｏｎｓ（人）のサブクラスである）

要約すると、ＴＢｏｘステートメントは、オブジェクト指向クラス（例えば、スキームまたはオントロジー定義）に関連し、ＡＢｏｘステートメントはそれらのクラスのインスタンスに関連する。先の例では、事実ステートメント「Flipper isA Dolphin（フリッパはイルカである）」は、ＡＢｏｘステートメントであり、一方、「every Dolphin is also a Mammal（全てのイルカはまた哺乳類である）」は、ＴＢｏｘステートメントである。

含意は、一定の条件下で、１つのステートメントの真実が、２つ目のステートメントの真実を確実にするという原理である。例えば、ＲＤＦ含意、ＲＤＦスキーマ含意、ＯＷＬ２ＲＤＦベースセマンティクス含意など、Ｗ３Ｃによって定義された異なる標準含意レジームがある。特に、各含意レジームは、含意規則のセットを定義する（https://www.w3.org/TR/sparql11-entailment/）。また、下記は、ＲＤＦＳ含意レジームによって定義された２つの推論規則（規則７および規則１１）である（https://www.w3.org/TR/rdf-mt/#rules）。
規則７：IF aaa rdfs:subPropertyof bbb && uuu aaa yyy, THEN uuu bbb yyy
これは、ａａａが、ｂｂｂのサブプロパティであり、かつｕｕｕが、そのａａａプロパティのｙｙｙの値を有する場合、ｕｕｕも、そのｂｂｂプロパティのｙｙｙの値を有することを意味する（ここで、「ａａａ」、「ｕｕｕ」、「ｂｂｂ」は、単に変数名である）。
規則１１：IF uuu rdfs:subClassOf vvv and vvv rdfs:subClassOf x, THEN uuu rdfs:subClassOf x

これは、ｕｕｕが、ｖｖｖのサブクラスであり、かつｖｖｖが、ｘのサブクラスである場合、ｕｕｕも、ｘのサブクラスである、を意味する。

セマンティック推論ツールで、セマンティック推論器が開始されると、どの含意レジームが実現されるべきかを指定する必要がある。例えば、セマンティック推論器インスタンスＡは、ＲＤＦＳ含意レジームによって定義される推論規則をサポートする「ＲＤＦＳ推論器」である場合がある。ＲＤＦＳ含意レジームによって定義される推論規則をサポートする。一例として、次の初期事実（ＲＤＦトリプルで記述される）があると仮定する。
・ ex:dog rdf:type rdfs:Class
・ ex:mammal rdf:type rdfs:Class
・ ex:animal rdf:type rdfs:Class
・ ex:dog rdfs:subClassOf ex:mammal
・ ex:mammal rdfs:subClassOf ex:animal

これらの事実をセマンティック推論器インスタンスＡに入力することによって、上記で提示したようにＲＤＦＳ規則１１を使用して下記の推測事実を導き出すことができる。
・ ex:dog rdfs:subClassOf ex: animal

セマンティック推論ツールの例は、Ｊｅｎａ推測サポートである。Ｊｅｎａ推測は、推測エンジンまたは推論器の範囲がＪｅｎａに接続することを可能にするように設計されている。このようなエンジンは、いずれかの任意のオントロジー情報および推論器に関連する規則と共にいくつかの既存の／ベースの事実から引き起こされる追加のＲＤＦ表明／事実を導き出すために使用される。

Ｊｅｎａ分散は、（先のセクションでそれぞれ提示した、対応する含意レジームによって定義されるような推論規則のセットを実装する）ＲＤＦＳ推論器、またはＯＷＬ推論器、ならびに、「ユーザ定義規則」をサポートするジェネリック規則ベースの推論器であるジェネリック規則推論器などのいくつかの所定の推論器をサポートする。

下記のコード例は、セマンティック推論タスクのためにＪｅｎａＡＰＩをどのように使用するかを示す。まず、プロパティ「ｐ」は、別のプロパティ「ｑ」のｓｕｂＰｒｏｐｅｒｔｙであり（６行目で定義される）、かつ、「ｐ」用の値「ｆｏｏ」と共にリソース「ａ」を有する（７行目で定義される）というステートメントを含むＪｅｎａモデルを作成する（３行目のｒｄｆｓＥｘａｍｐｌｅは、この例では、実際には、「初期事実」である）。
1. String NS = "urn:x-hp-jena:eg/";
2. // Build a trivial example data set
3. Model rdfsExample = ModelFactory.createDefaultModel();
4. Property p = rdfsExample.createProperty(NS, "p");
5. Property q = rdfsExample.createProperty(NS, "q");
6. rdfsExample.add(p, RDFS.subPropertyOf, q);
7. rdfsExample.createResource(NS+"a").addProperty(p, "foo");

ここで、全ての初期事実が、変数ｒｄｆｓＥｘａｍｐｌｅに入れられる。次に、下記のコードで初期事実に対してＲＤＦＳ推測を実施する推測モデルを作成する。
8. InfModel inf = ModelFactory.createRDFSModel(rdfsExample);

８行目に示すように、ＲＤＦＳ推論器は、ｃｒｅａｔｅＲＤＦＳＭｏｄｅｌ（）ＡＰＩを使用して、作成され、入力は、変数ｒｄｆｓＥｘａｍｐｌｅに格納されられた初期事実である。したがって、セマンティック推論処理は、ｒｄｆｓＥｘａｍｐｌｅに入れられた事実に（部分的な）ＲＤＦＳ規則セットを適用することによって実行されて、推測事実が変数ｉｎｆに格納される。

変数ｉｎｆに格納された推測事実を、ここで確認することができる。例えば、下記のコードで実装される場合があるリソースａのプロパティｑの値を知りたいと仮定する。
9. Resource a = inf.getResource(NS+"a");
10. System.out.println("Statement: " + a.getProperty(q));
出力は、次のようになる。
11. Statement: [urn:x-hp-jena:eg/a, urn:x-hp-jena:eg/q, Literal<foo>]

１１行目に示すように、リソースａのプロパティｑの値は、「ｆｏｏ」であり、これは、ＲＤＦＳ推論規則のうちの１つに基づいた推測事実、「IF aaa rdfs:subPropertyof bbb && uuu aaa yyy, THEN uuu bbb yyy（ＲＤＦＳ含意規則の規則７）」である。推論処理は、「リソースａに関して、そのプロパティｐの値が「ｆｏｏ」であり、ｐはｑのサブプロパティであるので、リソースａのプロパティｑの値は「ｆｏｏ」である」である。

ｏｎｅＭ２Ｍ。開発中のｏｎｅＭ２Ｍ規格は、「共通サービスエンティティ（Common Service Entity：ＣＳＥ）」と呼ばれるサービス層を定義している。サービス層の目的は、さまざまな「バーティカル」Ｍ２Ｍシステムおよびアプリケーションが利用することができる「ホリゾンタル」サービスを提供することである。ＣＳＥは、図２に示すように４つの参照点をサポートする。Ｍｃａ参照点は、アプリケーションエンティティ（Application Entity：ＡＥ）とインターフェースをとる。Ｍｃｃ参照点は、同一サービスプロバイダドメイン内の別のＣＳＥとインターフェースをとり、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとる。Ｍｃｎ参照点は、下位ネットワークサービスエンティティ（Network Service Entity：ＮＳＥ）とインターフェースをとる。ＮＳＥは、デバイス管理、位置サービス、およびデバイストリガなどの下位ネットワークサービスをＣＳＥに提供する。

ＣＳＥは、「発見」、および「データ管理およびリポジトリ」などの「共通サービス機能（Common Service Functions：ＣＳＦ）」、と呼ばれる複数の論理機能のうち１つまたは複数を含む場合がある。図３はｏｎｅＭ２Ｍによってサポートされる一部のＣＳＦを示す。

ｏｎｅＭ２Ｍアーキテクチャは、下記のタイプのノードを使用可能にする。

アプリケーションサービスノード（Application Service Node：ＡＳＮ）：ＡＳＮは、１つのＣＳＥを含み、かつ少なくとも１つのアプリケーションエンティティ（ＡＥ）を含むノードである。物理的マッピングの例は、ＡＳＮがＭ２Ｍデバイス内に常駐する場合があることである。

アプリケーション専用ノード（Application Dedicated Node：ＡＤＮ）：ＡＤＮは、少なくとも１つのＡＥを含むが、ＣＳＥは含まないノードである。ｏｎｅＭ２Ｍシステムのフィールドドメイン内に、ゼロまたは１つ以上のＡＤＮがある場合がある。物理的マッピングの例は、アプリケーション専用ノードが、制約されたＭ２Ｍデバイスに常駐する場合があることである。

ミドルノード（Middle Node：ＭＮ）：ＭＮは、１つのＣＳＥを含み、かつゼロまたは１つ以上のＡＥを含むノードである。ｏｎｅＭ２Ｍシステムのフィールドドメイン内に、ゼロまたは１つ以上のＭＮがある場合がある。物理的マッピングの例は、ＭＮはＭ２Ｍゲートウェイ内に常駐する場合があることである。

インフラストラクチャノード（Infrastructure Node：ＩＮ）：ＩＮは、１つのＣＳＥを含み、かつゼロまたは１つ以上のＡＥを含むノードである。ｏｎｅＭ２Ｍサービスプロバイダごとにインフラストラクチャドメインに正確に１つのＩＮがある。ＩＮ内のＣＳＥは、他のノードタイプには適用されないＣＳＥ機能を含む場合がある。物理的マッピングの例は、ＩＮはＭ２Ｍサービスインフラストラクチャ内に常駐する場合があることである。

非ｏｎｅＭ２Ｍノード（Non-oneM2M Node：ＮｏＤＮ）：非ｏｎｅＭ２Ｍノードは、ｏｎｅＭ２Ｍエンティティを（ＡＥもＣＳＥもどちらも）含まないノードである。このようなノードは、管理を含むインターワーキング目的のためにｏｎｅＭ２Ｍシステムに接続されたデバイスを意味する。

セマンティックアノテーション。ｏｎｅＭ２Ｍでは、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースは、リソースに関連するセマンティックディスクリプションを格納するために使用される。このようなディスクリプションは、オントロジーに従って提供される。セマンティック情報は、ｏｎｅＭ２Ｍシステムのセマンティック機能によって使用され、かつアプリケーションまたはＣＳＥにとって利用可能なものである。概して、（図４に示すように）＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースは、＜ＡＥ＞、＜ｃｏｎｔａｉｎｅｒ＞、＜ＣＳＥ＞、＜ｇｒｏｕｐ＞リソースなど、その親リソースのセマンティックアノテーションである。

セマンティックフィルタリングおよびリソース発見。セマンティックアノテーション（例えば、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソース内のコンテンツが、その親リソースのセマンティックアノテーションである）が、一旦、可能になると、セマンティックリソース発見またはセマンティックフィルタリングがサポートされる場合がある。セマンティックリソース発見は、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースの記述子属性に含まれるセマンティックディスクリプションに基づいてＣＳＥ内のリソースを見つけるために使用される。そのことを行うために、要求操作フィルタ基準の追加の値（例えば、「ｓｅｍａｎｔｉｃｓＦｉｌｔｅｒ」フィルタ）が、下記の表１に示すような定義と共に開示される。セマンティクスフィルタは、関連するセマンティックディスクリプションに対して実行されるＳＰＡＲＱＬステートメント（必要性に基づいて発見基準／制約を定義する）を格納する。「必要性」（例えば、要求または要件）は、多くの場合、アプリケーション発動のものである。例えば、地理的エリア内の製造元Ａによって製造されるデバイスの全てを見つけるための要求がある場合があり、対応するＳＰＡＲＱＬステートメントは、この必要性に対して記述される場合がある。セマンティックリソース発見の動作メカニズムは下記のようなものである。セマンティックリソース発見は、ｓｅｍａｎｔｉｃｓＦｉｌｔｅｒパラメータと共に読み出し要求を送信することによって開始される。全体的なセマンティックディスクリプション（グラフを形成する）は、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースのセット全体にわたって分散されているので、関連するセマンティックディスクリプションの全てが、まず、読み出される必要がある。セマンティックフィルタに含まれるようなＳＰＡＲＱＬ問い合わせステートメントは、次に、それらの関連するセマンティックディスクリプションで実行される。一定のリソースＵＲＩが、ＳＰＡＲＱＬ処理の間に識別される場合、それらのリソースＵＲＩは、発見結果として戻される。表１は、［oneM2M-TS-0001 oneM2M Functional Architecture -V3.8.0］から引用したものである。

セマンティック問い合わせ。概して、セマンティック問い合わせは、シンタックスに基づく明確および暗黙な導出情報、データ（ＲＤＦデータなど）内のセマンティックおよび構造的情報の両方の読み出しを可能にする。セマンティック問い合わせの結果は、問い合わせに対する返答／整合に関するセマンティック情報／知識である。これに対して、セマンティックリソース発見の結果は、識別されたリソースＵＲＩのリストである。一例として、セマンティックリソース発見は、「建物Ａ内の温度センサを示す全てのリソースＵＲＩ」を見つけることであり（例えば、発見結果は、＜ｓｅｎｓｏｒ−１＞と＜ｓｅｎｓｏｒ−２＞のＵＲＩを含む場合がある）、その一方で、セマンティック問い合わせは、「建物Ａには、何個の温度センサがあるか？」という質問をすることである（例えば、建物Ａの中に２つのセンサ、例えば、＜ｓｅｎｓｏｒ−１＞と＜ｓｅｎｓｏｒ−２＞がある場合、問い合わせ結果は、「２」となる）。

所定のセマンティック問い合わせに関して、これは、ＲＤＦトリプル（「ＲＤＦデータベース」と呼ばれる）のセットで実行される場合があり、異なるセマンティックリソース（＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースなど）間で分散される場合がある。セマンティック問い合わせに関連する「問い合わせ範囲」は、どのセマンティックリソースが、この問い合わせのＲＤＦデータベースに含まれる必要があるかを決定することである。

セマンティックリソース発見およびセマンティック問い合わせの両方は、同じセマンティクスフィルタを使用して、ＳＰＡＲＱＬ問い合わせ言語で定められる問い合わせステートメントを特定する。ＣＳＥが、セマンティクスフィルタを含む読み出し要求を受信するときに、セマンティック問い合わせインジケータパラメータも、その要求の中に存在する場合、その要求は、セマンティック問い合わせとして処理されるか、そうでない場合は、その要求は、セマンティックリソース発見として処理される。セマンティック問い合わせ処理では、受信されたセマンティック問い合わせ要求およびその問い合わせ範囲が与えられると、ＳＰＡＲＱＬ問い合わせステートメントは、問い合わせ範囲内のセマンティックリソースから収集される集約されたセマンティック情報に対して実行されて、生成された出力が、このセマンティック問い合わせの結果となる。

従来のセマンティック推論は、事実（通常、事実は、セマンティックトリプルとして表される）の観点から、および推論規則の観点から、新しい問題が原因で、ＳＬベースのプラットフォームのコンテキストでは直接使用されない可能性がある。事実の観点から、データまたは事実は、異なる場所（例えば、既存のｏｎｅＭ２Ｍ＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソース内のＲＤＦトリプル）で細分化または分散されていることが多い。関連する「事実サイロ」を構成または統合して、入力（例えば、事実セット）を推論処理向けに準備することができる方法、システムおよび装置を、本明細書にて開示する。推論規則の観点から、サービス層（ＳＬ）ベースプラットフォームは、しばしば、異なるセクションにわたってアプリケーションを動作可能にするホリゾンタルなプラットフォームとなることが想定される。したがって、異なるカスタマイズされた規則またはユーザ定義規則が、アプリケーションの必要性に基づいて定義される場合があり、これにより、異なる推測事実を（これらの事実が、同じ初期事実に基づいているとしても）導き出すことができる。

より詳細な理解は、添付図面と併せて、例として挙げられる下記の説明から得ることが可能である。

セマンティックウェブの例示的アーキテクチャを示す図である。例示的ｏｎｅＭ２Ｍアーキテクチャを示す図である。例示的ｏｎｅＭ２Ｍ共通サービス機能を示す図である。＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースの例示的構造を示す図である。例示的インテリジェント医療施設管理ユースケースを示す図である。他のセマンティック操作を用いる例示的セマンティック推論コンポーネントおよび最適化を示す図である。ＦＳ発行向けの例示的作成操作を示す図である。ＦＳ読み出し向けの例示的読み出し操作を示す図である。ＦＳ更新／削除向けの例示的更新／削除操作を示す図である。ＲＳ発行向けの例示的作成操作を示す図である。ＲＳ読み出し向けの例示的読み出し操作を示す図である。ＲＳ更新／削除向けの例示的更新／削除操作を示す図である。ＲＩによってトリガされる例示的１回限りの推論を示す図である。ＲＩによってトリガされる例示的連続的な推論を示す図である。推論によってサポートされる例示的ＩＤＢ強化を示す図である。ｏｎｅＭ２Ｍサービス層の例示的な新しいセマンティック推論サービスＣＳＦを示す図である。ＦＳ使用可能性向けに定義されるエンティティに関する例示的ｏｎｅＭ２Ｍモデルを示す図である。ＲＳ使用可能性向けに定義されるエンティティの例示的ｏｎｅＭ２Ｍモデルを示す図である。個別のセマンティック推論操作で関与するエンティティの例示的ｏｎｅＭ２Ｍモデルを示す図である。個別のセマンティック推論操作で関与するエンティティの例示的代替策モデルを示す図である。推論サポートを伴うセマンティック操作最適化向けに定義されるエンティティの例示的ｏｎｅＭ２Ｍモデルを示す図である。推論サポートを伴うセマンティック操作最適化向けに定義されるエンティティの例示的代替策モデルを示す図である。ＥＴＳＩＣＩＭとｏｎｅＭ２Ｍとの間の推論サポートを伴うセマンティック問い合わせ向けの例示的代替策モデルを示す図である。＜ｆａｃｔｓ＞リソースの例示的構造を示す図である。＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞リソースの例示的構造を示す図である。＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞リソースの例示的構造を示す図である。＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞リソースの例示的構造を示す図である。＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースの例示的構造を示す図である。＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞リソースの例示的構造を示す図である。＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞リソースの例示的構造を示す図である。図１３で開示されているＲＩによってトリガされる１回限りの推論の例示的ｏｎｅＭ２Ｍモデルを示す図である。図１４で開示されているＲＩによってトリガされる連続的な推論の例示的ｏｎｅＭ２Ｍモデルを示す図である。図１５の推論によってサポートされるＩＤＢ強化の例示的ｏｎｅＭ２Ｍモデルを示す図である。図１５の推論によってサポートされるＩＤＢ強化の例示的ｏｎｅＭ２Ｍモデルを示す図である。例示的ユーザインターフェースを示す図である。セマンティック推論機能（Semantic Reasoning Function：ＳＲＦ）の例示的特性を示す図である。セマンティック推論機能の例示的特性を示す図である。開示される主題が実装される可能性のある、例示的マシンツーマシン（Machine-To-Machine：Ｍ２Ｍ）またはモノのインターネット（Internet of Things：ＩｏＴ）通信システムの系統図である。図３７Ａに示されているＭ２Ｍ／ＩｏＴ通信システム内で使用される可能性のある、例示的アーキテクチャを示す図である。図３７Ａに示されている通信システム内で使用される可能性がある、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスを示す図である。図３７Ａの通信システムの態様内の例示的コンピューティングシステムを示す図である。

図５に示すようなスマートシティシナリオにおけるインテリジェント医療施設管理ユースケースについて考察する。大規模な病院は、長い年月の間に多くの建物を建ててきた。監視および施設管理用途を実施するために、病院はまた、それらの建物の部屋に監視カメラを設置している。特に、病院はＳＬベースプラットフォーム（例えば、ｏｎｅＭ２Ｍ）を採用している。例えば、各建物（例えば、建物１、建物２、建物３）は、ＭＮ−ＣＳＥ（例えば、ＭＮ−ＣＳＥ１０５、ＭＮ−ＣＳＥ１０６およびＭＮ−ＣＳＥ１０７）をホストし、建物の部屋に配備されたカメラのそれぞれは、建物の対応するＭＮ−ＣＳＥに登録され、ＳＬリソース表現を有する。例えば、建物１の部屋１０９に配備されたカメラ１１１は、建物１のＭＮ−ＣＳＥ１０５で＜Ｃａｍｅｒａ−１１１＞リソース表現を有し、例えば、これは、ｏｎｅＭ２Ｍで定義されているような＜ＡＥ＞タイプのリソースである場合がある。セマンティクスをサポートするために、＜Ｃａｍｅｒａ−１１１＞リソースは、セマンティックアノテーションとして一部のメタデータでアノテートされる場合がある。例えば、いくつかの事実は、そのデバイスタイプおよびその位置情報を記述するために使用される場合があり、これらは、例えば、下記の２つのＲＤＦトリプルのように記述される。
事実１： Camera-111 is-a Camera（「Ｃａｍｅｒａ」は、オントロジーによって定義された概念／クラスである）
事実２：Camera-111 is-located-in Room-109-of-Building-1

ドメイン内の各概念は、そのドメインオントロジー内のクラスに対応する。例えば、大学のコンテキストでは、教師は概念であり、かつ「教師」は、大学オントロジー内のクラスとして定義される。各カメラは、セマンティック子リソース（例えば、ｏｎｅＭ２Ｍ＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソース）に格納されたセマンティックアノテーションを有する場合がある。したがって、異なるｏｎｅＭ２Ｍリソースが、それら独自のセマンティックアノテーションを有する場合があるので、セマンティックタイプのデータは、ＭＮ−ＣＳＥのリソースツリーで分散している可能性がある。

病院は、外部ユーザ（例えば、消防局、市保健局など）も、病院の施設またはデバイスを管理、問い合わせ、操作および監視できるように、それ自体の施設をシティインフラストラクチャに（例えば、スマートシティを実現させるための第一歩として）統合する。

各病院の建物では、部屋は異なる目的で使用される。例えば、いくつかの部屋（例えば、部屋１０９）は、血液検査サンプルを保管し、その一方で、他のいくつかの部屋は、医用酸素ボンベを保管する。各部屋の異なる用途に基づいて、病院はいくつかの「管理ゾーン（Management Zones：ＭＺ）」を画定しており、各ゾーンはいくつかの部屋を含む。ＭＺの分割は、地理的位置に必ずしも基づくというわけではなく、とりわけ用途目的に基づくものである場合があることに留意されたい。例えば、ＭＺ−１は、血液検査サンプルを保管する部屋を含む。したがって、それらの部屋は、市保健局によってより関心をもたれるものである。言い換えると、市保健局は、ＭＺ−１に属する部屋に配備されたカメラにアクセスすることを要求する場合がある。同様に、ＭＺ−２は、医用酸素ボンベを保管する部屋を含む。したがって、市消防局が、それらの部屋により関心がある可能性がある。そのため、市消防局は、ＭＺ−２に属する部屋に配備されたカメラにアクセスする場合がある。各ＭＺ内の部屋は、病院施設チームによる部屋の再構成または再割り当てにより、時間の経過とともに変更される場合がある。例えば、部屋１０９が医用酸素ボンベを保管するために使用されるようになる場合、例えば、血液検査サンプルを今後、保管しない場合、ＭＺ−２に属する場合がある。

潜在的なユーザが、ＭＺ−１に属する部屋からリアルタイムで画像を読み出すことを望むシナリオを考察する。そのことを行うために、ユーザはまず、下記のＳＰＡＲＱＬステートメント１を使用して、それらのカメラを識別するためにセマンティックリソース発見を行う。
SELECT ?device
WHERE ｛
?device is-a Camera
?device monitors-room-inMZ-1
｝

上記のことを鑑みて、潜在的な問題が本開示により解決される。＜Ｃａｍｅｒａ−１１１＞リソースは、発見結果に含まれているはずであるが、従来通りの仕方では、リソース発見処理の間に所望のリソースとしては識別されない。この理由は、カメラ１１１は、ＭＺ−１に属する部屋に実際に配備されているのにもかかわらず、事実「Device-1 is-located-in Room-109-of-Building-1」（これは、＜Ｃａｍｅｒａ−１１１＞のセマンティックアノテーションである）は、ＳＰＡＲＱＬステートメント１のパターン「?device monitors-room-in MZ-1」と一致しない場合があるからである。この問題は、デバイスの従来のセマンティックアノテーションが、多くの場合、物理的位置などの低水準メタデータを含むが、ＭＺについての高水準メタデータを含まないという事実から起こるものである。しかし、ユーザは、特定のＭＺ（例えば、ＭＺ−１）の部屋だけに関心があり、それらの部屋の物理的位置には関心がない場合がある。上記の例を参照すると、ユーザは、ＭＺ−１に属する部屋に配備されたカメラからの画像にのみ関心があり、ユーザは、物理的部屋または建物の番号に関心が必ずしもあるというわけではない。実際に、（例えば、どの部屋がどの目的なのかなど、この情報が病院施設チームだけによって管理される内部情報である場合があるため）ユーザは、部屋の割り当て情報を認識していないことさえある場合もある。そう考えると、例えば、下記の推論規則の知識を用いて、推論または推測メカニズムをこれらの問題を解決するために使用することができる。
規則１．IF A is-located-in B && B is-managed-under C, THEN A monitors-room-in C
事実１、事実２、および規則１を使用することにより、下記の新しい事実を推測することが可能である。
・ Camera-111 monitors-room-in MZ-1

このような新しい事実は、上記のＳＰＡＲＱＬステートメント１に示されている問い合わせに答えるために有用である場合がある。

高水準問い合わせは、低水準メタデータに直接一致しない場合があり、上位層ユーザからの問い合わせが、高水準概念（例えば、専門用語または測定）に基づくものであり、一方で、下位層の物理リソースは、低水準メタデータでアノテートされているという点で、多くのコンピュータ科学分野では「抽象概念」を用いるために、このような現象は非常に一般的であることに留意されたい。一例として、ユーザが、ラップトップ上のＣ：ディスク内のファイルを問い合わせする場合、オペレーティングシステムは、ハードドライブ上のこのファイルの物理ブロックの位置を見つける必要があるが、これはユーザにとって完全に透過的なものである。

一部の既存のセマンティック推論ツールが利用可能ではあるが、それらは、事実の観点から、および推論規則の観点から、新しい問題が原因で、ＳＬベースプラットフォームのコンテキストでは直接使用することができない。事実の観点から、データまたは事実は、異なる場所（例えば、既存のｏｎｅＭ２Ｍ＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソース内のＲＤＦトリプル）で細分化または分散されていることが多い。このため、関連する「事実サイロ」を構成または統合して、入力（例えば、事実セット）を推論処理向けに準備する効率的な方法を本明細書で開示する。推論規則の観点から、サービス層（Service Layer：ＳＬ）ベースプラットフォームは、しばしば、異なるセクションにわたるアプリケーションを動作可能にするホリゾンタルなプラットフォームとなることが想定される。したがって、異なるカスタマイズされた規則またはユーザ定義規則が、アプリケーションの要件または要求に基づいて定義される場合があり、これにより、異なる推測事実を（これらの事実が、同じ初期事実に基づいているとしても）導き出すことができる。

下記は、この問題のより詳しい説明である。第１の問題は、事実の観点から、多くの場合、初期入力事実が充分でない場合があり、推論操作が実行される前に追加の事実が入力としてさらに識別される場合があることである。事実が異なる場所に「分散されている」場合があり収集が困難なために、実際にサービス層のコンテキストではこの問題は悪化する。第２の問題は、推論規則の観点から、従来通りでは、種々のアプリケーションに対する推論のサポート向けのユーザ定義推論規則を、ＳＬエンティティが定義、発行する（例えば、他のものと共有するために、規則または事実を発行することができる）方法がないことである。

第３の問題は、従来通りでは、事実および規則を入力として特定することによって、ＳＬエンティティが「個別の」推論処理をトリガする方法がないことである。しかし、多くのアプリケーションが、暗黙の事実を識別するためにセマンティック推論を必要とすることがあるので、推論は必要とされるか、または要求される場合がある。例えば、セマンティック推論処理は、公園の現在の屋外の気温、湿度、または風と、屋外活動助言関連推論規則とを、２つの入力として取り込む場合がある。推論処理の実行の後に、現在、屋外スポーツに最適な時間であるかどうかについて、「高水準推測事実」を、得る場合がある。このような高水準推測事実は、ユーザが、低水準入力事実の詳細（例えば、気温、湿度、または風の数値）を認識する必要がないという点で、ユーザにとって直接的な利益となる場合がある。別の用途のシナリオでは、推測事実はまた、同様に元の事実を強化するために使用される場合がある。例えば、カメラ１１１のセマンティックアノテーションは、最初にCamera-111 is-a A:digitalCameraという１つのトリプル（例えば、事実）を含む。この際、A:digitalCameraは、オントロジーＡによって定義されるクラスまたは概念である。推論処理を通して、推測事実が、Camera-111 is-a B:highResolutionCameraなどのカメラ１１１のセマンティックアノテーションにさらに追加される場合がある。この際、B:highResolutionCameraは、別のオントロジーＢによって定義されたクラス／概念である。この強化により、カメラ１１１のセマンティックアノテーションは、より豊富な情報を持つことになる。

第４の問題は、従来通りでは、他のセマンティック操作（例えば、セマンティック問い合わせ、セマンティックリソース発見など）を最適化する「バックグラウンドサポート」としてセマンティック推論を活用するために限られたサポートしかないことである。この場合、ユーザは、特定のセマンティック操作（例えば、セマンティック問い合わせまたはセマンティックリソース発見など）を開始したということだけを認識する場合がある。しかし、この操作の処理の間に、セマンティック推論は、バックグラウンドでトリガされる場合があり、これはユーザにとって透過的なものである。例えば、ユーザは、現在の公園で推奨される屋外スポーツに関して、セマンティック問い合わせを開始する場合がある。処理エンジンが、公園の現在の屋外の気温、湿度、または風のデータなど未処理の事実のみを有する場合、ＳＰＡＲＱＬ問い合わせ処理が、パターン整合に基づく（例えば、通常、整合は正確でなければならない）ために、問い合わせに対する答えを得られない場合がある。これに対して、それらの未処理事実を推論を通して高水準事実（例えば、現在、スポーツに最適な時間であるかどうか）を推測するために使用することができる場合、この推測事実は、ユーザ問い合わせの直接的な答えになる可能性がある。

既存のサービス層は、セマンティック推論を可能にする能力を持っておらず、それなしでは種々のセマンティックベース操作を効率的に動作させることができない。セマンティック推論が、より効率的かつ効果的にサポートされるためには、本明細書に開示される方法およびシステムに関連するセマンティック推論のうち１つまたは複数が、実装される必要がある。要約すると、図６を参照すると、方法およびシステムは、下記の３つの部分を伴う場合がある。１）ブロック１１５−セマンティック推論データ（例えば、事実および規則を指す）の管理を可能にする。２）ブロック１２０−個別のセマンティック推論処理を可能にする。３）ブロック１２５−バックグラウンド推論サポートを伴う他のセマンティック操作を最適化する。ブロック１１５（部分１）は、事実セットおよび規則セットがサービス層で利用可能となるように、セマンティック推論をどのように動作可能にするかに焦点を合わせている。事実セット（Fact Set：ＦＳ）および規則セット（Rule Set：ＲＳ）が使用可能であり、かつセマンティック推論器（Semantic Reasoner：ＳＲ）も動作可能である場合、個別のセマンティック推論処理をブロック１２０（部分２）で開始することができ、その際、推測結果は、次の推論操作での入力に再び使用される場合がある。最後に、ブロック１２５（部分３）で、セマンティック操作（例えば、セマンティック問い合わせ、セマンティックリソース発見、セマンティックマッシュアップなど）をより効率的かつ効果的に実行するために、開示されるセマンティック推論を使用することができる。上述の方法およびシステムのそれぞれは、本明細書でより詳細に開示される。

例えば図７から図１５に示すような、本明細書で示すステップを実施するエンティティは、論理エンティティである場合があることを理解されたい。これらのステップは、図３７Ｃまたは図３７Ｄに示すような、デバイス、サーバ、またはコンピュータシステムの、メモリに記憶されてよく、また、それらのプロセッサで実行されてよい。一例では、Ｍ２Ｍデバイスの相互作用に関して下記のさらなる詳細により、図３３ＡのＡＥ３３１は、図３７ＡのＭ２Ｍ端末デバイス１８に常駐する場合があり、一方で、図３３ＡのＣＳＥ３３２およびＣＳＥ３３３は、図３７ＡのＭ２Ｍゲートウェイデバイス１４に常駐する場合がある。本明細書で開示される各例示的方法（例えば、図７から図１５）間で、ステップの省略、ステップの組み合わせ、またはステップの追加が想定される。

ＳＬ（ブロック１１５−部分１）での、事実および推論規則を発行、更新および共有する方法を下記にて開示する。下記のデータエンティティは、事実セット（ＦＳ）および規則セット（ＲＳ）と、定義される。事実セット（ＦＳ）は事実のセットである。ＦＳが、セマンティック推論に含まれる場合、ＦＳは、ＩｎｐｕｔＦＳまたはＩｎｆｅｒｒｅｄＦＳに、さらに分類される場合がある。特に、ＩｎｐｕｔＦＳ（ブロック１１６）は、特定の推論操作への入力として使用されるＦＳであり、また、ＩｎｆｅｒｒｅｄＦＳ（ブロック１２２）は、セマンティック推論結果である（例えば、ＩｎｆｅｒｒｅｄＦＳは推測事実を含む）。推論操作Ａによって生成されるＩｎｆｅｒｒｅｄＦＳ（ブロック１２２）は、（図６に示すように）後の／次の推論操作でＩｎｐｕｔＦＳとして使用することができる。ＩｎｐｕｔＦＳは、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳとＡｄｄｉ＿ＩｎｐｕｔＦＳにさらに分類される場合がある（例えば、図１３を参照）。セマンティック推論操作をトリガするために、推論イニシエータ（Reasoning Initiator：ＲＩ）がセマンティック推論器（ＳＲ）に要求を送信するときに、推論イニシエータによってＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳが提供される場合がある。さらに、Ａｄｄｉ＿ＩｎｐｕｔＦＳは、追加の事実がセマンティック推論操作で使用される必要がある場合に、ＳＲによって提供または決定される。下記の説明では、基本的な用語ＦＳが、複数のタイプの事実セットを対象として使用されることがある。規則セット（ＲＳ）（例えば、ＲＳ１１７）は、推論規則のセットである。ＲＳは、Ｉｎｉｔｉａｌ＿ＲＳとＡｄｄｉ＿ＲＳにさらに分類される場合がある。例えば、セマンティック推論操作をトリガするために、ＲＩがＳＲに要求を送信するときに、ＲＩによってＩｎｉｔｉａｌ＿ＲＳが提供される。さらに、追加の規則が、セマンティック推論操作で使用される必要がある場合に、ＳＲによってＡｄｄｉ＿ＲＳが提供または決定される。Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳは、推論イニシエータ（ＲＩ）によって提供されるＦＳを指す。例えば、ＲＩがＳＲに推論要求を送信するときに、ＲＩは推論入力となる事実を示す場合があるが、このような事実は、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳと見なされる。次に、ＳＲは、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳが充分ではないことを見つけて、入力としてより多くの事実を含める場合があり、それは、Ａｄｄｉ＿ＩｎｐｕｔＦＳと見なされる。

ＦＳの観点から、サービス層では、データは通常リソースとして発現され、事実は異なる場所で細分化または分散されている。事実は、通常のＳＬリソースのセマンティックアノテーション（例えば、異なる＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースのＲＤＦトリプル）に限られず、事実は、サービス層で（例えば、発行されて）利用できるようにされ、その他のものによって格納またはアクセスされる場合がある任意の情報または知識を指す場合がある。例えば、ＦＳの特殊ケースが、ｏｎｅＭ２Ｍで定義された＜ｏｎｔｏｌｏｇｙ＞リソースに格納される場合があるオントロジーである場合がある。

ＲＳの観点から、ＳＬベースプラットフォームは、しばしば、異なるドメインにわたるアプリケーションを動作可能にするホリゾンタルなプラットフォームとなることが想定される。したがって、異なるＲＳが、サービス層で（例えば、発行されて）利用できるようにされ、かつ異なるアプリケーションをサポートするために他のものによって格納またはアクセスされる場合がある。例えば、公園の現在の屋外気温、湿度、または風を記述するＩｎｐｕｔＦＳに関しては、屋外活動助言関連推論規則が、現在、屋外スポーツに最適な時間であるかどうかといった高水準事実を推測するために使用される場合がある（これは、直接処理することができるものである）。これに対して、スマート芝生散水関連規則が、現在の散水スケジュールが望ましいかどうかといった事実を推測するために使用される場合がある。全体的に、ブロック１１５−部分１は、サービス層およびそれらの関連ＣＲＵＤ（作成、読み取り、更新、および削除）操作でＦＳまたはＲＳをどのように利用できるようにするかといった観点からセマンティック推論データを使用可能にする方法に関連する。

このセクションでは、所定のＦＳ（ＩｎｐｕｔＦＳとＩｎｆｅｒｒｅｄＦＳとを対象とするケース）を発行、アクセス、更新、または削除する場合があるような、ＦＳ使用可能性に対するＣＲＵＤ操作について提示する。

下記のプロシージャでは、いくつかの「論理エンティティ」が関与し、それらのそれぞれが対応する役割を有する。それら論理エンティティについて以下に記載する。
・事実プロバイダ（Fact Provider：ＦＰ）：これは、所定のＦＳを作成し、かつそのＦＳをＳＬで利用できるようにするエンティティ（例えば、ｏｎｅＭ２ＭＡＥまたはＣＳＥ）である。
・事実ホスト（Fact Host：ＦＨ）：これは、所定のＦＳをホストする場合があるエンティティ（例えば、ｏｎｅＭ２ＭＣＳＥ）である。
・事実モディファイア（Fact Modifier：ＦＭ）：これは、既存のＦＳに変更または更新を行うエンティティ（例えば、ｏｎｅＭ２ＭＡＥまたはＣＳＥ）である。
・事実コンシューマ（Fact Consumer：ＦＣ）：これは、ＳＬで、利用可能な所定のＦＳを読み出すエンティティ（例えば、ｏｎｅＭ２ＭＡＥまたはＣＳＥ）である。

したがって、異なる物理エンティティが、上記のように異なる論理的役割を担う場合がある。例えば、ＡＥがＦＰであり、ＣＳＥがＦＨである場合がある。ｏｎｅＭ２ＭＣＳＥなどの１つの物理エンティティが、上記のような複数の役割を担う場合がある。例えば、ＣＳＥは、ＦＰであり、同様にＦＨである場合がある。ＡＥがＦＰである場合があり、後にＦＭになる場合もある。

図７は、ＦＳ発行向けの作成操作の例示的方法を示す。図７に示すように、ＦＳ−１の発行に関与するＦＰ１３１およびＦＨ１３２がある場合がある。ステップ１４０は、発行方法の前提条件である場合がある。ステップ１４０で、ＦＰ１３１は、ＦＳ−１と表される事実のセットを有している。ＦＰ１３１は、システム内でＦＳ−１を利用できるようにする（例えば、トリガに基づいて決定する）ことを目的としている。例えば、考えられるトリガは、ＦＳ−１が外部エンティティにとって利用できるようになる場合、このことが、ＦＰ１３１をトリガして、サービス層に対してＦＳ−１を発行させる場合があることである。ステップ１４１で、ＦＰ１３１は、発行のためにＦＨ１３２にＦＳ−１を送信する。ＦＳは、概して、いくつかの形態を有する場合があることに留意されたい。例えば、ＦＳ−１は、所定のユースケース（例えば、病院、市消防局、建物、部屋など、多くのドメイン概念およびそれらの関係が定義されている、本明細書に開示のスマートシティユースケースなど）でのドメイン知識を記述するオントロジーを指す場合がある。別の例では、ＦＳ−１は、特定のインスタンスに関連する事実を指す場合がある。図５の先の例を再度用いて、ＦＳは、病院の現在の管理ゾーン定義、例えば、その建物、部屋構成、割り当て情報（例えば、管理ゾーンＭＺ−１は、血液検査サンプルを保管するために使用される部屋、例えば、建物１の部屋１０９、建物３の部屋１１７を含むなど）を記述する場合がある。これらのタイプの事実に関して、これらはシステム内で個別に存在する場合がある（例えば、必ずしも、他のリソースに対するセマンティックアノテーションであるわけではない）。加えて、ＦＳは、システム内のリソース、エンティティ、または他のものについてのセマンティックアノテーションを指す場合もある。図５を引き続き参照すると、ＦＳは建物１の部屋１０９に配備されたカメラ１１１のセマンティックアノテーションである場合がある。

図７を引き続き参照すると、ステップ１４２で、ＦＨ１３２は、ＦＳ−１をＦＨ１３２に格納することができるかどうかを判断する。例えば、ＦＨ１３２は、ＦＰ１３１が、それを行うために適切なアクセス権を有しているかを確認する場合がある。ＦＳ−１をＦＨ１３２に格納できる場合、ＦＨ１３２は、ＦＳ−１を格納するが、このＦＳ−１は、システム内の他のエンティティが利用できるものである。例えば、その後のセマンティック推論処理が、入力としてＦＳ−１を使用する場合があり、この場合、ＦＳ−１は処理のために読み出されてＳＲに入力される。所定のＦＳに関しては、有用な情報を示すために、一定の情報がこのＦＳに格納されるか、またはこのＦＳに関連付けられる場合がある（この情報は、ステップ１４１でＦＰ１３１によって、または他のものによって提供される場合がある）。例えば、情報は、関連するオントロジーまたは関連する規則を含む場合がある。

関連するオントロジーについて、ＦＳ−１に格納されている事実は、一定のオントロジーによって定義された概念または用語を使用する場合があるため、どのオントロジーがそれらの事実と関係しているのかを示す（それにより、それらのＲＤＦトリプルの主語／述語／目的語の意味を正確に解釈することができる）ことは有用である。例えば、ＦＳ−１に格納される下記の事実が考えられる。
事実１：Camera-111 is-located-in Room-109-of-Building-1
事実２： Room-109-of-Building-1 is-managed-under MZ-1

ＦＳ−１内の事実は、特定のオントロジーによって定義されるボキャブラリまたはプロパティである場合がある「is-located-in」または「is-managed-by」などのいくつかの用語を使用することが観察できる。

関連する規則について、ＦＳ−１に格納されている事実は、一定の推論規則を用いる推論のために潜在的に使用される場合があることも考えられるので、どの潜在的ＲＳを推論のためにこのＦＳ−１に適用することができるかを示すことも有用である。他の規則もまた、それが意味をなす限りこのＦＳ−１に適用される場合があるという点で、これらの規則は、単に提案であることに留意されたい。ＲＳ−１に格納される下記の推論規則が考えられる。
規則１：IF A is-located-in B && B is-managed-under C, THEN A monitors-room-in C

ＲＳ−１（規則１）内の規則は、ＦＳ−１に格納されている事実（事実１および事実２）に適用される場合がある。ステップ１４３で、ＦＨ１３２は、ＦＳ−１が、ＦＨ１３２に新しく格納されたことを肯定応答する。

図８は、ＦＳ読み出し向けの読み出し操作の例示的方法を示す。図８に示すように、ＦＨ１３２に格納されているＦＳ−１を読み出すことがあるＦＣ１３３がある場合がある。ステップ１５０では、読み出し方法の前提条件が存在する場合がある。ステップ１５０で、ＦＣ１３３は、既にＦＨ１３２に対してリソース発見操作を行って関心のあるＦＳ（例えば、ＦＳ−１）を識別している。図５の先の例を再度用いて、ＦＳ−１が病院の現在の管理ゾーン定義、例えば、その部屋割り当て情報を記述する場合、ＦＳ−１は推論処理の間にＳＲによって使用される場合がある。例えば、物理的位置情報（例えば、部屋および建物の番号）を用いるが、管理ゾーン関連情報は用いずにアノテートされている、関心のあるカメラを識別するために、ＦＳ−１は有用である場合がある。ユーザが、ＭＺ−１に属する部屋に配備されたカメラを探している場合、かかるＦＳ−１は推論処理を通して関連するカメラを識別するのに有用である。ステップ１５１で、ＦＣ１３３は、ＦＳ−１を読み出すためにＦＨ１３２に要求を送信する。ステップ１５２で、ＦＨ１３２は、ＦＣ１３３がＦＳ−１の読み出しを許可されるかどうか判断する。許可される場合、ＦＨ１３２は、ＦＣ１３３にＦＳ−１のコンテンツを返す。ステップ１５３で、ＦＳ−１のコンテンツは、ＦＣ１３３に返される。

更新または削除操作に関して、ＦＭ１３４は、図９に示す、下記のプロシージャを使用してＦＨ１３２に格納されているＦＳ−１を更新または削除することができる。ステップ１６０で、あらかじめ、事実のセット（ＦＳ−１）が発行されているか、またはＦＨ１３２によってローカルに生成されている。ここで、ＦＭ１３４はＦＳ−１のコンテンツを更新する（例えば、トリガに基づいて決定する）か、またはＦＳ−１を削除することを目的としている。例えば、ＦＳ−１は有効期限切れであるという通知をＦＭが既に受信しており、次に、更新または削除がトリガされる。図５の先の例を再度用いて、ＦＳ−１が病院の管理ゾーン定義、例えば、その部屋割り当て情報を記述すると仮定すると、病院が部屋割り当てを再編成した場合（例えば、現在、建物１の部屋１０９は、血液サンプルを保管するためではなく、他の目的で使用されているので、もはやＭＺ−１に属していない）、ＦＳ−１は、更新することを必要とされるか、または要求される場合がある。ステップ１６１で、ＦＭ１３４は、ＦＳ−１に格納されたコンテンツを修正するためにＦＨ１３２に更新要求を送信するか、またはＦＳ−１を削除するために削除要求を送信する。ステップ１６２で、ＦＨ１３２は、（例えば、一定のアクセス権に基づいて）この更新または削除要求が許可されてよいかどうか判断する。許可される場合、ＦＭ１３４から送信された要求に基づいてＦＳ−１は更新または削除される。ステップ１６３で、ＦＨ１３２は、ＦＳ−１が更新または削除されたことを肯定応答する。代わりのアプローチとして、ＦＳに格納されている事実が、ＲＤＦトリプルの形態である場合、ＦＳはＳＰＡＲＱＬ問い合わせステートメントを使用して更新されてもよい。そのことを行うために、ステップ１６１で、更新要求は、ＦＳがどのように更新される必要があるかを記述するＳＰＡＲＱＬ問い合わせステートメントを含んでもよい。特に、このアプローチでは、ＳＰＡＲＱＬ問い合わせステートメントがどのように記述されているかによってＦＳは完全に更新されるか、または部分的に更新される場合がある。例えば、代わりのアプローチの例としては、ＦＭが完全なセマンティック対応ユーザであり、かつＳＰＡＲＱＬ問い合わせ言語を認識している場合、ＦＭはその更新要件または要求をＳＰＡＲＱＬ問い合わせ言語の形態で直接記述できることが挙げられる。

このセクションでは、所定のＲＳを発行、アクセス、更新および削除する場合があるような、ＲＳ使用可能性に対するＣＲＵＤ操作について提示する。ＲＳ使用可能性は、概して、カスタマイズされた規則またはユーザ定義規則を指す。下記のプロシージャでは、いくつかの「論理エンティティ」が関与し、それらのそれぞれが対応する役割を有する。それら論理エンティティを以下に記載する。
・規則プロバイダ（Rule Provider：ＲＰ）：これは、所定のＲＳを作成し、かつそのＲＳをＳＬで利用できるようにするエンティティ（例えば、ｏｎｅＭ２ＭＡＥまたはＣＳＥ）である。
・規則ホスト（Rule Host：ＲＨ）：これは、所定のＲＳをホストする場合があるエンティティ（例えば、ｏｎｅＭ２ＭＣＳＥ）である。
・規則モディファイア（Rule Modifier：ＲＭ）：これは、既存のＲＳに変更（例えば、更新）を行うエンティティ（例えば、ｏｎｅＭ２ＭＡＥまたはＣＳＥ）である。
・規則コンシューマ（Rule Consumer：ＲＣ）：これは、ＳＬで利用可能な所定のＲＳを読み出すエンティティ（例えば、ｏｎｅＭ２ＭＡＥまたはＣＳＥ）である。

したがって、異なる物理エンティティが、上記のように異なる論理的役割を担う場合がある。例えば、ＡＥがＲＰであり、ＣＳＥがＲＨである場合がある。ｏｎｅＭ２ＭＣＳＥなどの１つの物理エンティティが、上記のような複数の役割を担う場合がある。例えば、ＣＳＥは、ＲＰであり、同様にＲＨである場合がある。ＡＥがＲＰである場合があり、後にＲＭになる場合もある。

作成操作に関しては、ＲＰ１３５は、図１０に示す、下記のプロシージャを使用してＲＳ−１を発行して、それをＲＨ１３６に格納させることができる。前提条件として、ステップ１７０で、ＲＰ１３５は、ＲＳ−１と表される規則のセットを有している。ＲＰ１３５は、システム内でＲＳ−１を利用できるようにすることを目的としている。考えられるトリガは、ＲＳ−１が外部エンティティにとって利用できるようになる場合、このことが、ＲＰ１３５をトリガして、サービス層に対してＦＳ−１を発行させる場合があることである。ステップ１７１で、ＲＰ１３５は、発行のためにＲＨ１３６にＲＳ−１を送信する。図５の先の例を再度用いて、ＲＳ−１は、「IF A（例えば、カメラ１１１） is-located-in B（例えば、建物１の部屋１０９）,and B is-managed-under C（例えば、ＭＺ−１）, THEN A monitors-room-in C」という規則を含む場合がある。このような規則は、特定のＭＺにカメラを関連付ける新しい事実を推測するのに有用である場合がある。ステップ１７２で、ＲＨ１３６は、一定のアクセス権に基づいて、ＲＳ−１がＲＨ１３６に格納されてよいかどうかを判断する。ＲＳ−１が、ＲＨ１３６に格納されてよい場合、ＲＨ１３６は、ＲＳ−１を格納することができるが、このＲＳ−１は、システム内の他のエンティティが利用できるものである。例えば、その後のセマンティック推論処理が、入力としてＲＳ−１を使用する場合があり、この場合、ＲＳ−１は処理のために読み出されてＳＲに入力される場合がある。有用な情報を示すために、一定の情報がこのＲＳに格納されるか、またはこのＲＳに関連付けられる場合がある。この情報は、ステップ１７１でＲＰ１３５によって、または他のものによって提供される場合がある。例えば、情報は、関連するオントロジーまたは関連する事実を含む場合がある。関連するオントロジーについて、ＲＳに格納された規則は、一定のオントロジーによって定義された概念または用語を使用する場合があることが考えられ、したがって、どのオントロジーがそれらの規則に関係しているのかを示すことは有用である。例えば、ＲＳ−１に格納される下記のユーザ定義推論規則が考えられる。
規則１：IF A is-located-in B && B is-managed-under C, THEN A monitors-room-in C

規則１は、特定のオントロジーによって定義されるボキャブラリ／プロパティである場合がある「is-located-in」または「is-managed-by」などいくつかの用語を使用する。

関連する事実について、ＲＳに格納される規則は、一定のタイプの事実に適用される場合があることが考えられ、したがって、推論のために、このＲＳがどの潜在的ＦＳに適用されるかを示すことも有用である。ＦＳで使用される用語と、ＲＳで使用される用語とが重複する場合に、このＲＳが他の事実に適用される場合があるという点で、これらの事実は、単に提案であることに留意されたい。例えば、ＲＤＦトリプルとして記述される、下記の２つの事実がＦＳ−１に格納されることが考えられる。
事実１：Camera-111 is-located-in Room-109-of-Building-1
事実２：Room-109-of-Building-1 is-managed-under MZ-1

「is-located-in」または「is-managed-by」のような用語など、事実で使用されるオントロジーと、規則で使用されるオントロジーとが重複するので、ＲＳ−１（規則１）の規則は、ＦＳ−１に格納されている事実（事実１および事実２）に適用される場合がある。ステップ１７３で、ＲＨ１３６は、ＲＳ−１がＵＲＩと共にＲＨ１３６に新しく格納されたことを肯定応答する。

このセクションでは、推論規則をどのように作成することができるかを示す。まず、種々のアプリケーションシナリオまたは要件に基づいて、先に論じたインテリジェント医療施設管理ユースケースにおいて定義される規則などの種々のアプリケーションによる推論規則が、定義される場合がある。
規則１：IF A is-located-in B && B isEquippedWith BackupPower, THEN A isEquippedWith BackupPower

次に、推論規則が生成される場合がある別のケースは、オントロジーアライメントまたはマッピングが行われる場合である。オントロジーアライメントまたはオントロジーマッチングは、オントロジー内の概念間の相関関係を決定する処理である。一例として、所定のオントロジーＡおよびオントロジーＢに関して、オントロジーマッピングが行われない場合があり、識別されるマッピングのうち１つは、オントロジーＡの概念またはクラス「ｒｅｃｏｒｄ」が、オントロジーＢの概念／クラス「ｌｏｇｒｅｃｏｒｄ」に相当するか、または同じであることである場合がある。概念は、通常、オントロジーで定義されたクラスに対応する。そのため、通常、概念およびクラスは、同じものを指す。ここで、「ｒｅｃｏｒｄ」と呼ばれるクラスが、オントロジーＡで定義され、「ｌｏｇｒｅｃｏｒｄ」と呼ばれるクラスが、オントロジーＢで定義される。したがって、このマッピングは、下記のトリプルなどの（ＯＷＬで定義された述語「ｓａｍｅＡｓ」を使用する）ＲＤＦトリプルとして記述される。
・ＲＤＦトリプルＡ：ontologyA:Record owl:sameAs ontologyB:LogRecord

下記で提示するように、このＲＤＦトリプルＡをさらにどう利用するかに関する複数の方法がある。言い換えると、ＲＤＦ−Ａのトリプルは、既に２つのオントロジー間でマップされている結果である。ここで、このマッピング結果をさらに利用することができる例示的方法の説明を以下に示す。第１の方法では、ＲＤＦトリプルＡは、ｒｅｃｏｒｄ（例えば、Ｒｅｃｏｒｄ−Ｘ）のセマンティックアノテーションに追加される場合がある。例えば、所定のＲｅｃｏｒｄ−Ｘに関して、まずそのセマンティックアノテーションは、（Ｒｅｃｏｒｄ−Ｘが、オントロジーＢのＬｏｇＲｅｃｏｒｄ概念／クラスのインスタンスであることを示す）下記のＲＤＦトリプルだけを含む。
・ＲＤＦトリプルＢ：Record-X is-a ontologyB:LogRecord

それに応じて、ユーザが望む場合、下記のＳＰＡＲＱＬ問い合わせステートメントを用いてセマンティック発見を行う。
・ SELECT ?rec WHERE ｛ ?rec is-a ontologyA:Record ｝

上記のＳＰＡＲＱＬ問い合わせステートメントが、Ｒｅｃｏｒｄ−Ｘのセマンティックアノテーションと一致しないので（Ｒｅｃｏｒｄ−Ｘは、ｏｎｔｏｌｏｇｙＢ：ＬｏｇＲｅｃｏｒｄのタイプであるが、ユーザが探しているｒｅｃｏｒｄは、ｏｎｔｏｌｏｇｙＡ：Ｒｅｃｏｒｄのタイプであるので）、ユーザは、発見結果でＲｅｃｏｒｄ−Ｘを得ることはできない。この問題を解決するために、ＲＤＦトリプルＡをＲｅｃｏｒｄ−Ｘのセマンティックアノテーションに追加してもよい。次に、セマンティック発見操作の間に上記のＳＰＡＲＱＬステートメントを処理するときに、例えば、一定の推論規則をＲｅｃｏｒｄ−Ｘのセマンティックアノテーションに適用することによって推論がトリガされる場合がある。
規則２：If uuu owl:sameAs vvv and Y is-a uuu, Then Y is-a vvv（ここで、「ｕｕｕ」、「ｖｖｖ」、「Ｙ」は、全て置換されるワイルドカードである）

その結果、推論結果は、下記のトリプルである。
ＲＤＦトリプルＣ：Record-X is-a ontologyA:Record

次に、かかるＲＤＦトリプルＣが、元のＳＰＡＲＱＬステートメント（例えば、パターンWHERE ｛ ?rec is-a ontologyA:Record ｝）と一致でき、このセマンティック発見操作の間に、最終的にＲｅｃｏｒｄ−Ｘが識別される。

第２の方法は、ＲＤＦトリプルＡを、さらに使用するために推論規則に変換する。例えば、ＲＤＦトリプルＡは下記の推論規則として表される場合がある。
規則３： If Y is-a ontologyB:LogRecord, Then Y is-a ontologyA:Record.

このようにして、本開示で記載されるＲＳ使用可能性プロシージャを使用してサービス層にこのような推論規則を格納することができる（例えば、作成操作を使用して、ホスト上にＲＳを作成する。ｏｎｅＭ２Ｍでは、作成操作を使用して、＜ｒｅａｓｏｎｉｎｇＲｕｌｅ＞リソースを作成し、規則３を格納する場合がある）。

先の例（前述のＲｅｃｏｒｄ−ＸおよびＳＰＡＲＱＬステートメント）を再度用いる。このアプローチでは、ＲＤＦトリプルＡを、Ｒｅｃｏｒｄ−Ｘのセマンティックアノテーションに追加しない。代わりに、セマンティック発見操作の間に上記のＳＰＡＲＱＬステートメントを処理するときに、セマンティック推論が、規則３を使用してトリガされてもよい。結果として、推論結果は、ＲＤＦトリプルＣと同じになることが可能である。最終的に、Ｒｅｃｏｒｄ−Ｘはまた、このセマンティック発見操作の間に識別可能になる。

読み出し操作に関しては、ＲＣ１３７は、図１１に示す下記のプロシージャを使用して、ＲＨ１３６に格納されているＲＳ−１を読み出すことができる。前提条件として、ステップ１８０で、ＲＣ１３７は、既にＲＨ１３６に対してリソース発見操作を行って関心のあるＲＳ−１を識別している。例えば、ＲＣ１３７はＳＲであり、ＲＳ−１を使用して推論操作をすることを目的としている（例えば、この場合、ＳＲは、ＲＣの論理的役割を担う）。ステップ１８１で、ＲＣ１３７は、ＲＳ−１読み出しのためにＲＨ１３６に要求を送信する。ステップ１８２で、ＲＨ１３６は、ＲＣ１３７がＲＳ−１の読み出しを許可されるかどうか判断する。許可される場合、ＲＨ１３６は、ＲＣ１３７にＲＳ−１のコンテンツを返す。ステップ１８３で、ＲＳ−１のコンテンツは、ＦＣ１３３に返される。

更新／削除操作に関しては、ＲＭ１３８は、図１２に示す下記のプロシージャを使用して、ＲＨ１３６に格納されているＲＳ−１を更新または削除することができる。前提条件として、ステップ１９０で、事前に、規則のセット（ＲＳ−１）が、ＲＨ１３６に発行されている。ここで、ＲＭ１３８は、ＲＳ−１のコンテンツを更新する（例えば、トリガに基づいて決定する）か、またはＲＳ−１を削除することを目的としている。例えば、ＲＳ−１が有効期限切れであるという通知をＲＭ１３８が受信して、そのＲＳ−１が更新または削除の必要があることが、トリガである場合がある。図５の先の例を再度用いて、ＲＳ−１には初めから１つの推論規則のみが含まれている。しかし、デバイスのアクセス権についてより多くの事実を推測するために、新しい推論規則が追加される場合がある。例えば、新しい規則は、「IF A（例えば、カメラ１１１）is-managed-under B（例えば、血液検査サンプルを保管する部屋のＭＺ−１）,and B is-exposed-to C（例えば、市保健局がＭＺ−１を認識している）、THEN C is-allowed-to-access A（例えば、カメラ１１１は市保健局によってアクセスされてよい）」である場合がある。推論のためにこの新しい規則を使用するときに、どのデバイスが市保健局によってアクセスされてよいかといった問い合わせに答えるために、推測事実が使用されてよい。ステップ１９１で、ＲＭ１３８は、ＲＳ−１に格納されたコンテンツを修正するためにＲＨ１３６に更新要求を送信するか、またはＲＳ−１を削除するために削除要求を送信する。ステップ１９２で、ＲＨ１３６は、一定のアクセス権に基づいて、この更新／削除要求が許可されてよいかどうかを判断する。許可される場合、ＲＭ１３８から送信された要求に基づいてＲＳ−１は更新／削除される。ステップ１９３で、ＲＨ１３６は、ＲＳ−１が更新／削除されたことを肯定応答する。

本パートでは、個別のセマンティック推論処理を可能にするいくつかの方法およびシステムを提示する。第１の例示的方法は、１回限りの推論操作に関連する場合がある。この操作の場合、推論イニシエータ（ＲＩ）は関心のあるいくつかのＩｎｐｕｔＦＳおよびＲＳを既に識別しており、いくつかの新しい事実（例えば、知識）を識別するために、ＳＲで推論操作を開始することを望んでいる。第２の例示的方法は、連続的な推論操作に関連する場合がある。このシステムでは、ＲＩは、関連するＩｎｐｕｔＦＳおよびＲＳに対して連続的な推論操作を開始することを必要とされるか、または要求される場合がある。この理由としては、ＩｎｐｕｔＦＳおよびＲＳが時間とともに変更（例えば、更新）されることで、以前の推測事実がそれ以上有効ではなくなる場合があることが考えられる。したがって、新しい推論操作が最新のＩｎｐｕｔＦＳおよびＲＳに対して実行されて、より新しい推測事実を得る必要がある。

先の例を使用して、セマンティック推論処理は、（ＩｎｐｕｔＦＳとして）公園の現在の屋外の気温／湿度／風と、（ＲＳとして）屋外活動助言関連推論規則とを、２つの入力として取り込む場合がある。推論処理実行後、（ＩｎｆｅｒｒｅｄＦＳとして）高水準事実が、例えば、現在がスポーツに最適な時間であるかどうかについて推測される場合がある。ここで、用語「個別の」は、セマンティック推論処理が、他のセマンティック操作（例えば、セマンティックリソース発見セマンティック問い合わせなど）と必ずしも関連するわけではないことを意味する。セマンティック推論処理を可能にするためには、以下のいくつかの問題が伴う。
1. 使用すべきＩｎｐｕｔＦＳが何で、それをどこから収集するのか？
2. 使用すべきＲＳが何で、それをどこから収集するのか？
3. ＩｎｐｕｔＦＳおよびＲＳを収集することをどの部分が担当するのか？例えば、それはセマンティック処理を開始するアプリケーションエンティティであるか、またはＳＲがこれを取り扱う場合がある。
4. ＩｎｆｅｒｒｅｄＦＳが、ＲＳによって得られたときに、それをどこに配信または保存するのか？

以下に開示する方法およびシステムは、上述の問題を解決する。いくつかの先に定義した「論理エンティティ」には、ＦＨおよびＲＨなどが依然として含まれる。加えて、ＳＲは、このシステムで利用可能であり、推論イニシエータ（ＲＩ）と呼ばれる新しい論理エンティティは、推論操作をトリガするためにＳＲに要求を送信することのあるものである。

１回限りの推論に関するこのシナリオでは、ＲＩは、いくつかの関心のあるＩｎｐｕｔＦＳおよびＲＳを既に識別しており、いくつかの新しい知識／事実を発見するために、ＳＲで推論操作を開始することを望んでいる。サービス層での１回限りの推論操作をトリガする方法を提供するシステム、方法または装置を、本明細書にて開示する。図１３は、１回限りの推論操作の例示的方法を示し、かつ詳細を以下に記載する。ステップ２００では、前提条件として、ＲＩ２３１は、ＳＲ２３２の存在を認識している。ＲＩ２３１は、ＡＥまたはＣＳＥである場合がある。発見を通して、ＲＩ２３１は、ＦＨ１３２上の関心のある事実のセット（この事実セットは、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳと表される）、およびＲＨ１３６上のいくつかの推論規則（この規則セットはＩｎｉｔｉａｌ＿ＲＳと表される）を既に識別している。ＲＩ２３１は、まずＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳ部分を識別して、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳについてのより多い情報も利用可能である場合（例えば、推論のために、どの潜在的ＲＳが、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳに適用されるかを示す「関連する規則」情報も利用可能である場合）、ＲＩ２３１は、それらの提案からいくつかの関心のある規則を直接選択する場合があることも考えられる。本開示を通して議論する識別される「関心のある」事実および規則に関して、推論イニシエータ（ＲＩ）は、既存のセマンティックリソース発見を使用して、事実または推論規則を格納しているｏｎｅＭ２Ｍリソースを識別することができる。概して、セマンティック発見要求の際に、セマンティクスフィルタおよびこのフィルタは、ＳＰＡＲＱＬステートメントを通過させる場合がある。このＳＰＡＲＱＬステートメントは、ＲＩが関心のある事実または規則のタイプを示す場合がある（すなわち、要求メッセージは、一定のデータについてのより多い情報に対する要求を含む）。例えば、ＲＩは、「この街の街灯についての事実、例えば、製造年、ブランド、位置などを全て知りたい」と述べる場合があり、これが、ＲＩが関心のある事実である。ＲＩはまた、「街灯の保守計画を表す推論規則を知りたい」と述べる場合もある。例えば、規則は、「街灯がブランドＸであり、それが特定の道路に設けられている場合、この街灯は、直ちに、改善する必要がある」と記述される場合があり、これが、ＲＩが関心のある規則である。次に、ＲＩ（例えば、市の街灯保守計画アプリケーション）が、どの街灯が改善される必要があるかを知りたい（これは、ＲＩが「〜を目的としている」というときの例である場合がある）場合、このＲＩは、識別された事実および規則を使用して、図１３に示すような推論操作をトリガすることができ、推論結果は、改善される必要がある街灯のリストである。すなわち、要約すると、ＲＩが関心のある事実または規則のタイプは、アプリケーションの実務ニーズによって決まる場合がある。

一例として、ＲＩ２３１は、２つのカメラ（例えば、カメラ１１１、カメラ１１２）に関心があり、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳが、下記のような、２つのカメラについてのいくつかの事実を有する。
事実１：Camera-111 hasBrandName “XYZ”
事実２：Camera-112 is-located-in Building-1

ＲＩ２３１はまた、（Ｉｎｉｔｉａｌ＿ＲＳとして）下記の規則を識別して、推論にそれを使用して、関心のあるカメラについてのより多い暗黙の知識／事実を発見することを目的としている。
規則１： IF A hasBrandName “XYZ”, THEN A isEquippedWith BackupPower

これらのＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳを用いることで、電源が切れたとしても、常にモニタリング用途をサポートできるように、これらのカメラがバックアップ電源を有しているかどうかに関するいくつかの新しい知識を推測することが可能である。ステップ２０１で、ＲＩ２３１は、新しい知識を発見するために、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳを入力として使用して（例えば、トリガに基づいて決定して）、ＳＲ２３２での推論操作／ジョブをトリガすることを目的としている。ＲＩ２３１に共振要求を送信させるトリガは、ＲＩ２３１が、先の発見操作の間に事実および規則の「空でない」セットを受信し、このことがＲＩをトリガして推論要求を送信させることである場合がある。言い換えると、Ｉｎｉｔｉａｌ＿ＲＳおよびＩｎｉｔｉａｌ＿ＦＳが空でなければ、ＲＩ２３１をトリガして、推論要求を送信することができる。ステップ２０２で、ＲＩ２３１は、ＳＲ２３２にＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳ（例えば、これらのＵＲＩ）についての情報と共に推論要求を送信する。例えば、情報は、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳを格納している対応するＦＨ１３２のＵＲＩ、およびＩｎｉｔｉａｌ＿ＲＳを格納している対応するＲＨ１３６のＵＲＩを含む。ステップ２０３で、ＲＩ２３１から送信された情報に基づいて、ＳＲ２３２は、ＦＨ１３２からＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳ−１、およびＲＨ１３６からＩｎｉｔｉａｌ＿ＲＳを読み出す。

ステップ２０４で、ＲＩ２３１によって提供された入力に加えて、追加のＦＳまたはＲＳがこのセマンティック推論操作で使用されてよいかどうかを、ＳＲ２３２が決定する場合がある。ＳＲ２３２が代わりのＦＨおよびＲＨを認識する場合、ＳＲ２３２は追加のＦＳまたはＲＳを取得するために該代わりのＦＨおよびＲＨに問い合わせする場合がある。

例えば、ＲＩ２３１が、部分的な事実および規則しか識別していない可能性があり（例えば、ＲＩ２３１がＦＨ２３４およびＲＳ−２に対して発見を行わなかったが、ＲＩ２３１が関心があり、ＦＨ２３４およびＲＳ−２上に有用なＦＳおよびＲＳが存在する）、つまりは、新しい知識を推測するＳＲの能力に限度がある可能性がある。例えば、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳだけを用いると、ＳＲ２３２は、下記のような新しい事実の一部しか得られない場合がある。
推測事実１：Camera-111 isEquippedWith BackupPower

概して、ステップ２０４では、ＳＲ２３２が追加の事実または追加の規則を使用するかについて、異なる実装選択を有する場合がある。例えば、最初のアプローチでは、ステップ２０２で、ＳＲ２３２が追加の事実または規則を追加してもよいかどうかをＲＩ２３１が示す場合がある。２つ目のアプローチでは、ステップ２０２で、ＳＲ２３２が追加の事実または規則を追加してもよいかどうかをＲＩ２３１が示さない場合がある。代わりに、ＳＲ２３２のローカルポリシーが、このような決定を行う場合がある。

ステップ２０４について引き続き言及すると、概して、どの追加のＦＳおよびＲＳを利用することができるかをＳＲ２３２が決定するために下記の方法が考えられる。これは、ＳＲ２３２にいくつかのローカルポリシーまたは構成を設定することによって達成することができる。例えば、
・Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳに含まれる所定のＦＳ（例えば、ＦＳ−１）に関して、ＳＲ２３２は、ＦＳ−１に関連する（例えば、格納されている）有用な情報があるかどうかをさらに確認してもよい。例えば、情報は、「関連する規則」を含む場合があり、これは、どの潜在的ＲＳが、推論のためにＦＳ−１に適用されてよいかを示すものである。これらの関連する規則のどの部分もＩｎｉｔｉａｌ＿ＲＳに含まれていない場合、ＲＩ２３１はさらに、追加の規則として、それらの関連する規則の一部を加えるかどうかを判断してもよい。
・Ｉｎｉｔｉａｌ＿ＲＳに含まれている所定のＲＳ（例えば、ＲＳ−１）に関して、ＲＳ２３２は、ＲＳ−１に関連する／格納されている有用な情報があるかどうかをさらに確認してもよい。例えば、情報の１つは、「関連する事実」である場合があり、これは、どの潜在的ＦＳが、ＲＳ−１に適用されてよいかどうかを示すものである。これらの関連する事実のどの部分もＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳに含まれていない場合、ＲＩ２３１はさらに、追加の事実として、それらの事実の一部を加えるかどうかを判断してもよい。
・ＳＲ２３２が、上述のようなＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳから有用な情報を得ることができない場合、ＳＲ２３２は、そのローカル構成またはポリシーに基づいて動作してもよい。例えば、ＳＲ２３２は、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳまたはＩｎｉｔｉａｌ＿ＲＳで使用される一定のオントロジーまたは関心のある用語／概念／述語を認識する限り、より多くの事実または規則をさらに読み出しできるように構成されてもよい。言い換えると、ＳＲ２３２は、ローカル構成テーブルにその関心のあるキーワードを記録し、かつ各キーワードはいくつかの関連するＦＳおよびＲＳに関連付けられてもよい。したがって、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳで現れる任意のキーワード（用語、概念、または述語）に対して、ＳＲ２３２はその構成テーブルを確認し、このキーワードの関連付けられたＦＳまたはＲＳを探し出してもよい。これらの関連付けられたＦＳおよびＲＳは、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳに含まれていない場合、利用される可能性のある潜在的な追加のＦＳおよびＲＳである場合がある。例えば、ＳＲ２３２が、事実２を受信して、用語「Ｂｕｉｌｄｉｎｇ−１」が事実２で現れたことを見つける（例えば、「Ｂｕｉｌｄｉｎｇ−１」は、関心のある用語またはその構成テーブル内のキーワードである）場合、ＳＲ２３２は、下記の事実３のような、建物１についての追加の事実を（例えば、その構成テーブル内の情報に基づいて）加えることを選択してもよい。同様に、ＳＲ２３２は、関心のある述語「is-located-in」が事実２で現れ、関心のある述語「isEquippedWith」が事実３で現れることを見つけると、下記の規則など、追加の／さらに多くの規則を加える。
事実３：Building-1 isEquippedWith BackupPower
規則２：IF A is-located-in B && B isEquippedWith BackupPower, THEN A isEquippedWith BackupPower
・ＳＲ２３２はまた、ＲＩ２３１のタイプが与えられると、追加のＦＳおよびＲＳが利用されるように構成されてもよい（ＲＩのタイプに応じて、例えば、ＲＩがＶＩＰユーザである場合、さらに多くのＦＳを推論処理に含むことができ、そうすることで、高品質推論結果を生成することができる）。

このステップ２０４でのアプローチは、図１４のステップ２１４および図１５のステップ２２５などの、この後のセクションの方法で使用される場合がある。

ステップ２０５で、ＳＲ２３２は、ＦＨ２３４から追加のＦＳ（Ａｄｄｉ＿ＩｎｐｕｔＦＳと表される）、およびＲＨ２３５からの追加のＲＳ（Ａｄｄｉ＿ＲＳと表される）を読み出す。例えば、Ａｄｄｉ＿ＩｎｐｕｔＦＳは、建物１について先に示した事実３を有し、Ａｄｄｉ＿ＲＳは先に示した規則２を有する。追加のＦＳおよびＲＳ、ならびに事実２を用いて、ＳＲ２３２は、推測事実２を得ることができる。
推測事実２： Camera-112 isEquippedWith BackupPower

ステップ２０６で、全てのＩｎｐｕｔＦＳ（例えば、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＡｄｄｉ＿ＩｎｐｕｔＦＳ）およびＲＳ（例えば、Ｉｎｉｔｉａｌ＿ＲＳおよびＡｄｄｉ＿ＲＳ）を用いて、ＳＲ２３２は、推論処理を実行して、ＩｎｆｅｒｒｅｄＦＳを得る。先に述べたように、２つの推測事実（推測事実１および推測事実２）が、ＩｎｆｅｒｒｅｄＦＳに含まれることになる。ステップ２０７で、ＳＲ２３２は、ＲＩ２３１にＩｎｆｅｒｒｅｄＦＳを返信する。

要約すると、オントロジー内で教師、生徒、教科などの概念はクラスと等しく、それら全ては、大学オントロジー内の概念である。述語は、例えば、ある教師がある教科を「教える」など、クラス間の「関係」を説明する。用語は、例えば、「フルタイム」など全員が理解しているドメイン内のキーワードであることが多い。下記のＲＤＦトリプル（主語・述語・目的語で表される）が考えられる。

ＲＤＦトリプル１：Jack is-a Teacher（ここで、Ｔｅａｃｈｅｒはクラス、ＪａｃｋはクラスＴｅａｃｈｅｒのインスタンスである。）

ＲＤＦトリプル２：Jack teaches Course-232（ここで、このＲＤＦトリプルのｔｅａｃｈｅｓは述語である。）

ＲＤＦトリプル３：Jack has-the-work-status“Full-time”（ここで「ｆｕｌｌ−ｔｉｍｅ」は全員が知っている用語である。）

図１３に示すプロシージャのいくつかの代替策もまた、下記のように定義される（代替策は、別々に考慮される場合がある）。ステップ２０１の代替策１では、ＲＩ２３１は、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳを識別するために発見を行う必要がない。その代わりに、ＲＩ２３１それ自体が、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳを生成して、ＳＲ２３２にそれらを送信してもよい（この場合、ステップ２０３は、必要ではない）。

ステップ２０１の代替策２では、ＲＩ２３１は、ユーザ定義推論規則セットを使用する必要がない。その代わりに、既存の標準的な推論規則を利用してもよい。例えば、ＳＲ２３２は、ＲＤＦＳ含意、ＯＷＬ含意などの、特定のＷ３Ｃ含意レジームによって定義された推論規則の全てまたは部分に基づいて推論をサポートしてもよい（例えば、この場合、Ｉｎｉｔｉａｌ＿ＲＳは、それらの標準推論規則を指すことがある）。そのことを行うために、ＲＩ２３１は、最初にＲＩ２３１がＳＲ２３２を発見するときに、どの標準推論規則または含意レジームが、サポートされてよいかをＳＲ２３２に尋ねる場合がある。

ステップ２０２の代替となる代替策３では、ＲＩ２３１は、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳについての位置情報だけを送信する場合がある。次に、ＳＲ２３２は、ＲＩ２３１の代わりに、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳを読み出す場合がある。

代替策４では、セマンティック推論操作は時間がかかることがあるという事実を考慮して、セマンティック操作をトリガするために、非ブロックベースアプローチがサポートされてよい。例えば、ステップ２０３の前に、ＳＲ２３２はまず、ＲＩ２３１からの要求の承諾についてクイック肯定応答を送信してもよい。ＳＲ２３２は、推論結果（例えば、ＩｎｆｅｒｒｅｄＦＳ）を導き出した後に、ステップ２０７に示すように、ＲＩ２３１にＩｎｆｅｒｒｅｄＦＳを返信する。ブロックベースアプローチでは、ＲＩがＳＲに要求を送信するときに、ＳＲが推論結果を導き出す前に、ＳＲは、ＲＩにいずれの応答も送信しないことに留意されたい。これに対して、非ブロックアプローチでは、ＳＲは推論要求を受信すると、ＲＩにクイック肯定応答を返す場合がある。その場合、その後、ＳＲは推論結果を導き出すと、ＲＩに推論結果をさらに送信する場合がある。

ステップ２０７の別の代替である代替策５では、ＩｎｆｅｒｒｅｄＦＳは、ＲＩ２３１に返される必要がない。その代わりに、要件または計画的利用に基づいて一定のＦＨに格納されてもよい。例えば、
1. ＳＲ２３２は、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳが、以前よりも「強化される」ように、ＩｎｆｅｒｒｅｄＦＳとＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳを統合してもよい。このことは、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳが、デバイスのセマティックアノテーションである場合に有用である。ＩｎｆｅｒｒｅｄＦＳを用いて、セマティックアノテーションは、より豊富な情報を有することができる。例えば、初めに、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳが、「Camera-111 is-a OntologyA: VideoCamera」という事実だけを記述する場合がある。推論が行われた後に、カメラ１１１のセマンティックアノテーションとして加えることができる推測事実（Camera-111 is-a OntologyB:DigitalCamera）が生成される。このようにして、カメラ１１１は、（推論サポートがなかったとしても）その後の発見操作で正常に識別される可能性が高くなり、それにより、オントロジーＡで定義される概念「ＶｉｄｅｏＣａｍｅｒａ」か、またはオントロジーＢで定義される概念「ＤｉｇｉｔａｌＣａｍｅｒａ」のどちらかを使用する。
2. ＳＲ２３２は、新しいリソースを作成して、ＦＨ１３２にまたはローカルでＳＲ２３２にＩｎｆｅｒｒｅｄＦＳを格納して、ＦＨ１３２上のＩｎｆｅｒｒｅｄＦＳのリソースＵＲＩまたは位置だけを返してもよい。これは、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳがデバイスのいくつかの低水準セマティック情報を記述し、一方で、ＩｎｆｅｒｒｅｄＦＳが、いくつかの高水準セマティック情報を記述する場合に有用である。例えば、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳは、「Camera-113 is-located-in Room 147」という事実だけを記述し、ＩｎｆｅｒｒｅｄＦＳが、「Camera-113 monitors Patient-Mary」という事実を記述する場合がある。このような高水準知識は、カメラ１１３の低水準セマンティックアノテーションと統合されるべきではない。

代替策６では、開示される方法で、特定の規則セットまたは事実セット（例えば、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳ、Ａｄｄｉ＿ＩｎｐｕｔＦＳ、Ｉｎｉｔｉａｌ＿ＲＳ、Ａｄｄｉ＿ＲＳ）が、１つのＦＨ１３２または１つのＲＨ１３６から読み出される場合を考察することは注目に値するが、これは、簡単な提示のためだけのものである。概して、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳ（および同様にＡｄｄｉ＿ＩｎｐｕｔＦＳ）は、複数のＦＨでホストされている複数のＦＳによって構成される場合がある。Ｉｎｉｔｉａｌ＿ＲＳ（および同様にＡｄｄｉ＿ＲＳ）は、複数のＲＨでホストされている複数のＲＳによって構成される場合がある。上記の代替策の全てが、本明細書で開示する他の類似の方法（例えば、図１４の方法）にも適用されてよいことに留意されたい。

連続的な推論操作について、このシナリオでは、ＲＩ２３１は、関連するＦＳおよびＲＳに対して連続的な推論操作を開始する場合がある。この理由としては、時々、ＩｎｐｕｔＦＳおよびＲＳが時間とともに変更／更新されることで、以前の推測事実がそれ以上有効ではなくなる場合があるためである。したがって、新しい推論操作が最新のＩｎｐｕｔＦＳおよびＲＳに対して実行されて、より新しい推測事実が得られる場合がある。図１４は、連続的な推論操作の例示的方法を示し、かつ詳細を以下に記載する。ステップ２１０では、前提条件として、ＲＩ２３１はＳＲ２３２の存在を認識している。発見を通して、ＲＩ２３１は、ＦＨ１３２上の関心のある事実のセット（この事実セットは、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳと表される）、およびＲＨ１３６上のいくつかの推論規則（この規則セットはＩｎｉｔｉａｌ＿ＲＳと表される）を既に識別している。ステップ２１１で、ＲＩ２３１は、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳを使用して、「連続的な」セマンティック推論操作を開始する（例えば、トリガに基づいて決定する）ことを目的としている。一例では、ＲＩ２３１に推論要求を送信させるトリガは、ＲＩ２３１が、先の発見操作の間に事実および規則の「空でない」セットを受信することである場合がある。一方、識別された事実または規則は、時間とともに変更される場合があり、このことが、ＲＩ２３１をトリガして、連続的な推論操作の要求を送信させる場合がある。ステップ２１２で、ＲＩ２３１は、ＳＲ２３２にＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳについての情報と共に推論要求を送信する。要求メッセージは、新しいパラメータ推論タイプ（ｒｓ＿ｔｙ）を含む場合があることに留意されたい。推論タイプ（ｒｓ＿ｔｙ）は、ＲＩ２３１が必要とする推論操作のタイプを示す。例えば、ｒｓ＿ｔｙ＝０は、１回限りの推論操作（先のセクションで説明したような）を意味し、ｒｓ＿ｔｙ＝１は連続的な推論操作を意味する。あるいは、ｒｓ＿ｔｙが要求メッセージに存在しない場合、それは１回限りの推論要求として扱われる。

ステップ２１３で、ＲＩ２３１から送信された情報に基づいて、ＳＲ２３２は、ＦＨ１３２からＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳ、およびＲＨ１３６からＩｎｉｔｉａｌ＿ＲＳを読み出す。ＳＲ２３２はまた、変更を通知するために、それらをサブスクリプションする。ステップ２１４で、ＲＩ２３１によって提供された入力に加えて、追加のＦＳまたはＲＳがこのセマンティック推論操作に使用されてよいかどうかを、ＳＲ２３２が決定する場合がある。ステップ２１５で、ＳＲ２３２は、ＦＨ２３４から追加のＦＳ（Ａｄｄｉ＿ＩｎｐｕｔＦＳと表される）、およびＲＨ２３５からの追加のＲＳ（Ａｄｄｉ＿ＲＳと表される）を読み出し、またそれらをサブスクリプションする。

ステップ２１６で、ＳＲ２３２は、全てのＩｎｐｕｔＦＳ（例えば、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＡｄｄｉ＿ＩｎｐｕｔＦＳ）、およびＲＳ（例えば、Ｉｎｉｔｉａｌ＿ＲＳおよびＡｄｄｉ＿ＲＳ）を含む、推論ジョブ（ＲＪ−１と表される）を作成する。次に、ＲＪ−１が実行されて、ＩｎｆｅｒｒｅｄＦＳを得る。その後、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳ、Ａｄｄｉ＿ＩｎｐｕｔＦＳ、Ｉｎｉｔｉａｌ＿ＲＳ、およびＡｄｄｉ＿ＲＳのいずれかが変更される限り、実行すべきＲＪ−１が繰り返しトリガされる。あるいは、ＳＲ２３２は、それらのリソースを定期的に確認することを選択して、更新があるかどうかを確かめることもできる。他の代替策では、ＲＪ−１の最新の推論結果を得るために、ＲＩ２３１が能動的に、かつパロディ的に要求を送信する場合もあり、この場合、毎回、ＳＲ２３２はＲＩ２３１から要求を受信し、ＳＲ２３２はそれらのリソースを確認することを選択して、更新があるかどうかを確かめる場合がある（更新がある場合、新しい推論がトリガされる）。

ステップ２１７で、ＦＨ１３２は、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳの変更についての通知を送信する。ステップ２１８で、ＳＲ２３２は、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳの最新のデータを読み出し、次いで、ＲＪ−１に対して新しい推論処理を実行し、新しいＩｎｆｅｒｒｅｄＦＳを得る。関連するＦＳおよびＲＳ（例えば、この例で示すＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳ）の変更に対処するために、最初のセマンティック推論処理後、ステップ２１７からステップ２１８が連続的に行われてよいことに留意されたい。ＳＲ２３２は、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳの変更についての通知を受信するときはいつでも、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳの最新のデータを読み出して、新たに推論処理を実施し、新しいＩｎｆｅｒｒｅｄＦＳを生成する。ステップ２１９で、ＳＲ２３２は、ＲＩ２３１にＲＪ−１のジョブＩＤと共に新しいＩｎｆｅｒｒｅｄＦＳを返信する。ＲＪ−１に関連するこの全体的なセマンティック推論処理は、ＲＪ−１がＳＲ２３２で動作する有効なセマンティック推論ジョブである限り続けられてよい。加えて、ＲＪ−１の期限が切れるか、ＳＲ２３２またはＲＩ２３１がＲＪ−１の終了を選択する場合、ＳＲ２３２は、ＲＪ−１に関連する推論の処理を中止し、かつ関連するＦＳおよびＲＳからのサブスクライブを取り消してもよい。図１３に示す代替策は、図１４に示す方法にも適用することができる。

本パートは、他のセマンティック操作（例えば、セマンティック問い合わせ、セマンティックリソース発見、セマンティックマッシュアップなど）が、セマンティック推論からどのように利益を得るかに関する方法およびシステムを提示する。セマンティック推論器だけでなく、上記のセマンティック操作向けの処理エンジンであるセマンティックエンジン（Semantic Engine：ＳＥ）も、システムにおいて利用可能である。基本的な処理は、下記のようなものである。セマンティックユーザ（Semantic User：ＳＵ）が、ＳＥにＳＰＡＲＱＬ問い合わせステートメントを含むことがある要求を送信することによってセマンティック操作を開始する場合がある。特に、ＳＵは、ＳＥの背後で支援することがあるＳＲを認識していない。ＳＥに関しては、ＳＥはまず、対応するＳＰＡＲＱＬ問い合わせステートメントの関係データベース（Involved Data Basis：ＩＤＢ）を決定する場合がある。概して、ＩＤＢは、ＳＰＡＲＱＬ問い合わせステートメントが実行される必要がある事実のセット（例えば、ＲＤＦトリプル）を指す。しかし、用意できているＩＤＢが、要求に対して望ましい応答を提供するために完璧ではない場合がある。したがって、ＳＥは、セマンティック推論サポートのためにさらにＳＲとコンタクトして、ＳＥでのセマンティック操作の処理を促進する。特に、ＩＤＢ強化について開示する。ＩＤＢ強化に関して、推論能力を利用することで（推論を支援するためにいくつかの新しい推測事実を初期事実と統合することによって）元のＩＤＢが強化されるが、元の問い合わせステートメントは修正されない。それに応じて、ＳＥは元の問い合わせステートメントを「強化ＩＤＢ」に適用して、処理結果を生成する（例えば、ＳＥがセマンティック問い合わせを処理すると、処理結果は、セマンティック問い合わせ結果となる。ＳＥがセマンティックリソース発見を処理する場合、処理結果は、セマンティック発見結果となる）。

部分３（ブロック１２５）で、セマンティック推論が、「バックグラウンドサポート」のように動作して、他のセマンティック操作の効率をあげるが、この場合、推論は、フロントエンドユーザにとっては透過的なものである場合がある。言い換えると、部分３（ブロック１２５）では、ユーザは、特定のセマンティック操作（例えば、セマンティック問い合わせ、またはセマンティックリソース発見、セマンティックマッシュアップなど）を開始したことだけを認識する場合がある。しかし、ＳＥ２３３によるこの操作の処理の間、ＳＥ２３３は、さらに、ＳＲ２３２にサポートするように求める場合がある（この動作では、用語ＳＥは、セマンティック推論以外のセマンティック操作を処理するエンジンとして使用される。言い換えると、推論処理は、特にＳＲによって取り扱われる）。先の例を考慮に入れて、ユーザはＳＥに対してセマンティック問い合わせを開始して、現在行っている屋外スポーツに関する推奨を問い合わせすることがある。ＳＥが、公園の現在の屋外の気温／湿度／風のデータなど未処理の事実だけを有する場合（ＳＰＡＲＱＬ問い合わせ処理が、主に、パターン整合に基づくことを思い出すと）、問い合わせに対する答えを得られない場合がある。実際に、それらの（ＩｎｐｕｔＦＳのような）未処理の事実は、関連する推論規則を使用する推論のためにさらにＳＲに送信されて、（ＩｎｆｅｒｒｅｄＦＳのような）高水準推測事実が推断され、それを用いてＳＥはユーザ問い合わせに答える。

このセクションでは、既存のセマンティック操作（例えば、セマンティック問い合わせまたはセマンティックリソース発見）が、セマンティック推論からどのように利益を得るかを提示する。以下に開示のプロシージャでは、先に定義した「論理エンティティ」の一部には、ＦＨおよびＲＨなどが依然として含まれる。ＳＲだけでなく、上記のセマンティック操作向けの処理エンジンであるＳＥも、システムにおいて利用可能である。論理エンティティは、セマンティックユーザ（ＳＵ）と呼ばれ、セマンティック操作を開始するためにＳＥに要求を送信するエンティティである。

概して、ＳＵ２３０は、ＳＥ２３３にＳＰＡＲＱＬ問い合わせステートメントを含むことがある要求を送信することによって、セマンティック操作を開始する場合がある。特に、ＳＵは、ＳＥの背後で支援するセマンティック推論機能を認識していない。ＳＥ２３３に関して、ＳＥ２３３はまず、例えば、ＳＵによって示された問い合わせ範囲情報に基づいて、対応するＳＰＡＲＱＬ問い合わせステートメントの関係データベース（ＩＤＢ）を収集する。ＩＤＢに関するさらなる例を、以下に提示する。セマンティック問い合わせの場合、受信されたＳＰＡＲＱＬ問い合わせステートメントが与えられるときに、収集されることになる関連するセマンティックデータは、通常、問い合わせ範囲によって定義される。一例としてｏｎｅＭ２Ｍを用いる場合、一定のリソースの下の子孫＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースが、ＩＤＢを構成し、問い合わせがこのＩＤＢに対して実行される。セマンティック発見の場合、そのセマンティックアノテーション（例えば、その＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞子リソース）を確認することによって、所定のリソースが、発見結果に含まれる必要があるかどうかを評価する場合、この＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞子リソースが、ＩＤＢである。しかし、用意できているＩＤＢが、要求に対して望ましい応答を提供するために完璧ではない場合がある（例えば、ＩＤＢ内の事実が、ＳＵ２３０からのＳＰＡＲＱＬ問い合わせステートメントで使用されるオントロジーとは異なるオントロジーを使用して記述されている）。したがって、このケースでは、セマンティック推論がある種の支援を行うことで、ＳＥ２３３でのセマンティック操作処理の処理を促進する場合がある。

ＳＥ２３０がＳＲ２３２に支援を要請することを決定するときに、ＳＥ２３０またはＳＲ２３２それ自体が、追加の事実および規則が活用されてよいかどうかを決定する場合がある。活用されてよいと決定される場合、それらの追加の事実および規則が（ＩＤＢと共に）推論のためにＳＲによって使用されて、推測事実が識別される場合があり、これにより、ＳＵからの元の要求の処理を支援することができる。下記のプロシージャ設計の例示的セマンティック操作として、セマンティックリソース発見が使用され、これは簡単な提示のためだけのものであるが、開示する方法は、他のセマンティック操作（例えば、セマンティック問い合わせ、セマンティックマッシュアップなど）にも適用することができる。

再度、強化ＩＤＢについて、主要の着想は、推論能力を利用して（推論の支援によって、いくつかの新しい推測事実を初期事実と統合することによって）、ＩＤＢを強化することである。よって、元の問い合わせステートメントが「強化ＩＤＢ」に適用されて、発見結果が生成される。図１５の詳細な説明を、以下に提示する。ステップ２２１で、ＳＵ２３０は、セマンティック操作を開始することを目的としており、例えば、それは、セマンティックリソース発見操作である。例えば、ＳＵ２３０は、ＭＺ−１に属する部屋を監視するカメラを探している。発見要求内のＳＰＡＲＱＬ問い合わせステートメントは、以下のように記述される場合がある。
SELECT ?device
WHERE ｛
?device is-a Camera
?device monitors-room-in MZ-1
｝

ステップ２２２で、ＳＵ２３０は、ＳＥ２３３にＳＰＡＲＱＬ問い合わせステートメント、および（必要とされるか、または計画されている場合）どのＩＢＤが含まれる必要があるかについての情報と共に要求を送信して、セマンティック発見操作を開始する。ｏｎｅＭ２Ｍモデルを用いて、セマンティック発見の場合、ＳＵ２３０は、（ＳＥを実装する）ＣＳＥに発見要求を送信する場合があり、かつ発見が開始される必要がある場所、例えば、このＣＳＥのリソースツリー上の特定のリソース＜ｒｅｓｏｕｒｃｅ−１＞を示す。したがって、＜ｒｅｓｏｕｒｃｅ−１＞の全ての子リソースは、これらが、発見結果に含まれる必要があるかどうかを確認するために、それぞれ評価される。特に、評価されることになる所定の子リソース（例えば、＜ｒｅｓｏｕｒｃｅ−２＞）に関して、ＳＰＡＲＱＬ問い合わせが、＜ｒｅｓｏｕｒｃｅ−２＞の＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞子リソースに格納されているセマンティックデータに対して適用されて、一致があるかどうかが確認される（一致がある場合、＜ｒｅｓｏｕｒｃｅ−２＞は発見結果に含まれる）。したがって、この場合、＜ｒｅｓｏｕｒｃｅ−２＞を評価するときに、＜ｒｅｓｏｕｒｃｅ−２＞の＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞子リソースに格納されたセマンティックデータが、ＩＢＤである。

同様に、セマンティック問い合わせの場合、ＳＵ２３０は、（ＳＥを実装する）ＣＳＥにセマティック問い合わせ要求を送信する場合があり、かつ関連するセマンティックデータ（例えば、問い合わせ範囲）をどのように収集するかを示す（例えば、特定のｏｎｅＭ２Ｍリソース＜ｒｅｓｏｕｒｃｅ−１＞の下のセマンティック関連リソースが収集される必要がある）。したがって、＜ｒｅｓｏｕｒｃｅ−１＞の子孫セマンティック関連リソース（例えば、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソース）が、まとめて収集される場合があり、またＳＰＡＲＱＬ問い合わせが、上記のセマンティック関連リソースからの集約されたセマンティックデータに適用されて、セマンティック問い合わせ結果が生成されることになる。したがって、この場合、＜ｒｅｓｏｕｒｃｅ−１＞の全ての子孫セマンティック関連リソースに格納されたデータが、ＩＤＢである。

ステップ２２２で、ＳＵ２３０から送信された要求に基づいて、ＳＥ２３３は、セマンティックリソース発見処理を行うことを開始する。図５に関連する例を用いて、＜Ｃａｍｅｒａ−１１１＞は、候補リソースの１つであり、ＳＵ２３０は、その＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞子リソース内のセマンティックデータを調査することによって、発見結果に＜Ｃａｍｅｒａ−１１１＞が含まれる必要があるかどうかを評価する場合がある。言い換えると、ここで、＜Ｃａｍｅｒａ−１１１＞の＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞子リソースに格納されたデータは、ＩＤＢ（ＩＤＢ−１として表される）である。例えば、セマンティック発見のケースに関して、１つの特定のリソースの評価を開始するときは、毎回、新しいＩＤＢが決定され、それは、この特定のリソースを評価するためだけに使用される場合がある。例えば、ＩＤＢ−１は、下記の事実だけを含む場合がある。
事実１：Camera-111 is-a Camera
事実２：Camera-111 is-located-in Room-109-of-Building-1

ＳＥ２３３はまた、この要求を処理するために推論が行われる必要があるかどうかを決定する。

概して、限定はされないが、推論が行われる必要があるかどうかをＳＥ２３３が決定する下記の方法が考えられる（これは、ＳＥ２３３にいくつかのローカルポリシーまたは構成を設定することによって達成することができる）。
・元のＩＤＢ−１に基づいてＳＥ２３３によって結果を生成することができない場合、ＳＥ２３３は、推論を活用してＩＤＢ−１を強化することを決定してもよい。
・ＳＵ２３０が、高品質発見を必要または要求する優先ユーザである場合、ＳＥ２３３は、（ＳＵのタイプ次第で）推論を活用してＩＤＢ−１を強化することを決定してもよい。
・ＳＥ２３３は、一定のオントロジーまたはＩＤＢ−１で使用される関心のある用語／概念／プロパティを確認する限り、推論を活用してＩＤＢ−１を強化することを決定できるように構成されてよい。例えば、ＳＥ２３３が、事実２を確認して、事実２で現れる建物番号および部屋番号（例えば、「建物１」および「部屋１０９」）に関連する用語を見つける場合、ＳＥ２３３は、推論を活用してＩＤＢ−１を強化することを決定してもよい。

ＳＥ２３３が、推論を活用してＩＤＢ−１を強化することを決定する場合、ＳＥ２３３は、ＳＲ２３２とさらにコンタクトする場合がある。ステップ２２４で、ＳＥ２３３は、推論処理のために、ＳＲ２３２にＩＤＢ−１と関連する情報と共に要求を送信するが、この情報は、ＳＲ２３２での推論処理向けのＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳとなるものである。実際には、ＳＥ２３３およびＳＲ２３２は、一緒に統合され、かつ同じエンティティ、例えば、ｏｎｅＭ２Ｍコンテキストでの同じＣＳＥによって実装される可能性があることに留意されたい。ＳＲ２３２はさらに、（Ａｄｄｉ＿ＩｎｐｕｔＦＳのような）追加のＦＳまたは（Ｉｎｉｔｉａｌ＿ＲＳのような）ＲＳが、推論のために使用される必要があるかどうかを判断する。どの追加のＦＳおよびＲＳが、利用される必要があるかを決定する方法に関して図１３でも示されているように、ステップ２２４は、ここで、再度、使用されてよい。１つの拡張は、ＳＲ２３２がＩＤＢ−１に現れるキーワードまたは関心のある用語だけでなく、ステップ２２１で示されたＳＰＡＲＱＬステートメントに現れるキーワードまたは関心のある用語も確認する場合があることである。決定後、ＳＲ２３２は、これらのＦＳおよびＲＳを読み出す。例えば、ＳＲ２３２は、ＦＨ１３２からＡｄｄｉ＿ＩｎｐｕｔＦＳ、およびＲＨ１３６からＩｎｉｔｉａｌ＿ＲＳをそれぞれ読み出す。この例では、ＳＲ２３２は、事実２に現れるキーワード「is-located-in」、およびステップ２２１でＳＵ２３０から送信されたＳＰＡＲＱＬ問い合わせステートメントに現れたキーワード「monitors-room-in」を見つけ、次に、ＳＲ２３２は、ＭＺ定義についてのいくつかの有用な情報および部屋割り当てが、推論に利用されてよいことを判断する場合がある。したがって、Ａｄｄｉ＿ＩｎｐｕｔＦＳは下記の事実を含む場合がある。
事実３：Room-109-of-Building-1 is-managed-under “MZ-1”

ＳＥ２３３はまた、Ｉｎｉｔｉａｌ＿ＲＳが２つのキーワード「is-located-in」および「is-managed-under」を含むので、Ｉｎｉｔｉａｌ＿ＲＳが下記の規則を含む場合があると判断する。
規則１：IF A is-located-in B && B is-managed-under C, THEN A monitors-room-in C

ステップ２２６で、ＩＤＢ−１ならびに収集したＡｄｄｉ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳに基づいて、ＳＲ２３２は、推論処理を実行して、推測事実（ＩｎｆｅｒｒｅｄＦＳ−１と表される）を得る。例えば、ＳＲ２３２は、下記のことを見つける。
・事実２は、規則１のＩＦ部分内で部分的なパターンが一致している：A is-located-in B
・事実３は、規則１のＩＦ部分で、部分的なパターンが一致している：B is-managed-under C

それに応じて、例えば、Camera-111 monitors-room-in MZ-1といった新しい事実を推測することができ、これは、ＩｎｆｅｒｒｅｄＦＳ−１として表される。ステップ２２７で、ＳＲ２３２は、ＳＥ２３３にＩｎｆｅｒｒｅｄＦＳ−１を返信する。ステップ２２８で、ＳＥ２３３は、ＩｎｆｅｒｒｅｄＦＳ−１をＩＤＢ−１と（新しいＩＤＢ−２として）統合し、元のＳＰＡＲＱＬステートメントをＩＤＢ−２に適用して対応する結果を得る。この例では、ＳＰＡＲＱＬステートメントがＩＢＤ−２に適用されるときに、（ここで、新しい推測事実ＩｎｆｅｒｒｅｄＦＳ−１が、ＩＤＢ−２にあり、それが、ＳＰＡＲＱＬステートメント内のパターン「?device monitors-room-in MZ-1」と一致するので）一致があることを意味し、これにより、＜Ｃａｍｅｒａ−１１１＞のＵＲＩが、発見結果に含まれることになる。この後、ＳＥ２３３は、＜Ｃａｍｅｒａ−１１１＞の評価を完了し、評価されることになる次のリソースの確認を続ける場合がある。ステップ２２９で、ＳＥ２３３によって全ての発見処理が完了された後に、ＳＥ２３３は、ＳＵ２３０に処理結果（この場合、発見結果）を返信する。例えば、＜Ｃａｍｅｒａ−１１１＞のＵＲＩが、（処理結果である）発見結果に含まれて、ＳＵ２３０に返信されてよい。

セマンティック推論ＣＳＦに関して、セマンティック推論ＣＳＦは、図１６に示すように、ｏｎｅＭ２Ｍサービス層の新しいＣＳＦと見なすことができる（あるいは、oneM2M TS-0001で規定された既存のセマンティクスＣＳＦの一部である場合がある）。異なるタイプのＭ２Ｍノード、例えば、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバなどが、セマンティック推論サービスを実装してもよいことを理解すべきである。特に、それらのノードの種々の／異なるハードウェア／ソフトウェア能力に応じて、ノードによって実装されるセマンティック推論サービスの能力が、変更されてもよい。

ＦＳ使用可能性に関して定義されるエンティティのｏｎｅＭ２Ｍモデルを図１７に示す。例えば、事実ホストは、ｏｎｅＭ２ＭシステムのＣＳＥである場合があり、またＡＥ／ＣＳＥは、事実プロバイダ、事実コンシューマ、または事実モディファイアである場合がある。

ＲＳ使用可能性に関して定義されるエンティティのｏｎｅＭ２Ｍモデルを図１８に示す。例えば、規則ホストは、ｏｎｅＭ２ＭシステムのＣＳＥである場合があり、またＡＥ／ＣＳＥは、規則プロバイダ、規則コンシューマ、または規則モディファイアである場合がある。

個別のセマンティック推論操作に関与するエンティティのｏｎｅＭ２Ｍモデルを図１９に示す。例えば、ＣＳＥは、セマンティック推論器を搭載している場合、セマンティック推論サービスを提供する場合がある。加えて、ＡＥ／ＣＳＥは、推論イニシエータである場合がある。前述のように、本開示で定義される関与するエンティティの大部分は、論理的役割である。したがって、１つの物理エンティティが、複数の論理的役割を担う場合がある。例えば、ＣＳＥがセマンティック推論能力（例えば、図１９に示すＳＲのような）を有し、かつ推論操作に対する入力として一定のＦＳおよびＲＳを読み出すことを必要とされるか、またはそれらを読み出すことを要求するときに、このＣＳＥは、図１７および図１８に示すようなＦＣおよびＲＣの役割も有する。

個別のセマンティック推論操作に関与するエンティティの別のタイプの例を図２０に示す。このアーキテクチャでは、ｏｎｅＭ２Ｍシステムは、主として事実および規則を提供する。例えば、ｏｎｅＭ２ＭＣＳＥは、事実ホストまたは規則ホストと見なされる場合がある。別の層（例えば、ＥＴＳＩコンテキストインフォメーションマネジメント（Context Information Management：ＣＩＭ）、Ｗ３Ｃモノのウェブ（Web of Things：ＷｏＴ）、またはオープンコネクティビティファンデーション（Open Connectivity Foundation：ＯＣＦ））が、ｏｎｅＭ２Ｍシステムの上層にある場合があり、この場合、ユーザのセマンティック推論要求は、上位層からのものである場合がある。したがって、外部ＣＩＭ／Ｗ３ＣＷｏＴ／ＯＣＦエンティティが、セマンティック推論器を搭載している場合があり、また推論イニシエータは、主としてＣＩＭ／Ｗ３ＣＷｏＴ／ＯＣＦシステムのエンティティである場合がある。言い換えると、これらのＲＩは、セマンティック推論器に推論要求を送信し、そのセマンティック推論器は、インターワーキングエンティティとさらにコンタクトし、かつインターワーキングエンティティは、ｏｎｅＭ２Ｍインターフェースを通して、ｏｎｅＭ２Ｍエンティティから関連するＦＳおよびＲＳを収集する（ｏｎｅＭ２Ｍが相互作用する限り、ＦＳは、他の非ｏｎｅＭ２Ｍエンティティによって提供される場合があることに留意されたい。例えば、ＦＳは、トリプルストアによって提供される場合もある）。ｏｎｅＭ２Ｍシステムでは、インターワーキング、例えば、ＩＰＥベースインターワーキングおよびＣＳＥベースインターワーキングを取り扱うことができる２つのタイプのエンティティが存在する場合がある。したがって、インターワーキングエンティティは、２つのタイプのインターワーキングをサポートするＣＳＥまたは（専用ＡＥである）ＩＰＥのどちらかを指す場合がある。

推論サポートを伴うセマンティック操作の最適化に関与するエンティティのｏｎｅＭ２Ｍモデルを図２１に示す。例えば、ＣＳＥは、セマンティック推論器を搭載している場合、セマンティック推論能力を提供する場合があり、また、ＣＳＥは、セマンティックエンジンを搭載している場合、他のセマンティック操作（例えば、セマンティックリソース発見、セマンティック問い合わせなど）を処理する場合がある。加えて、ＡＥ／ＣＳＥは、セマンティック操作をトリガするセマンティックユーザである場合がある。このセクションの全ての例を通して、所定の論理エンティティは、単一のＡＥまたはＣＳＥによって採用されるが、これは簡単な提示のためだけのものであることに留意されたい。実際に、基本的なケースでは、ＡＥまたはＣＳＥが、複数の後方業務エンティティの役割を担う場合がある。例えば、ＣＳＥは、ＦＨであり、同様にＲＨである場合がある。別の例では、ＣＳＥは、セマンティック推論器およびセマンティックエンジンの両方をホストする場合がある。別の例では、ＣＳＥは、推論イニシエータである場合があり、かつＣＳＥ自体が、セマンティック推論器を搭載している場合もある。

推論サポートを伴うセマンティック操作の最適化に関与するエンティティの別のタイプの例を図２２に示す。このアーキテクチャでは、ｏｎｅＭ２Ｍシステムは、主として事実および規則を提供する。例えば、ｏｎｅＭ２ＭＣＳＥは、事実ホストまたは規則ホストである場合がある。別の層（例えば、ＣＩＭ、ＷｏＴ、またはＯＣＦ）が、ｏｎｅＭ２Ｍシステムの上層にある場合があり、この場合、ユーザのセマンティック推論要求は、上位層からのものである場合がある。したがって、外部ＣＩＭ／ＷｏＴ／ＯＣＦエンティティが、セマンティックエンジンを搭載している場合があり、またセマンティックユーザは、主としてＣＩＭ／ＷｏＴ／ＯＣＦシステムのエンティティである場合がある。同様に、外部ＣＩＭ／ＷｏＴ／ＯＣＦエンティティが、セマンティック推論器を搭載している場合がある。概して、一定のセマンティック操作をトリガするために、セマンティックユーザはセマンティックエンジンに要求を送信する。セマンティックエンジンは、推論サポートのためにセマンティック推論器とさらにコンタクトし、また、その推論器は、インターワーキングエンティティをさらに通して、ｏｎｅＭ２Ｍインターフェースを介してｏｎｅＭ２Ｍエンティティから関連するＦＳおよびＲＳを収集する。ｏｎｅＭ２Ｍが相互作用する限り、ＦＳは、他の非ｏｎｅＭ２Ｍエンティティによって提供される場合があることに留意されたい。例えば、ＦＳは、トリプルストアによって提供される場合もある。

下記は、ＥＴＳＩＣＩＭとｏｎｅＭ２Ｍシステムとの間の推論サポートを伴うセマンティック問い合わせの図２２のより具体的な例である。図２３は、そのプロシージャを示し、かつ詳細を以下に記載する。

前提条件０（ステップ３０７）では、街灯１に設置されたカメラがＣＳＥ−１に登録されており、かつ＜ｓｔｒｅｅｔＣａｍｅｒａ−１＞はそのｏｎｅＭ２Ｍリソース表現であり、さらにいくつかのセマンティックメタデータがこのリソースに関連付けられている。例えば、セマンティックメタデータのうち１つは、下記のものである場合がある。
事実１：<streetCamera-1> is-installed-on streetLamp-1

前提条件１（ステップ３０８）では、ＩＰＥが、セマンティックリソース発見を既に行っており、例えば、街灯１を含むカメラリソースがＣＩＭシステムに登録されている。

前提条件２（ステップ３０９）では、ＩＰＥは、ＣＩＭレジストリサーバに発見されたｏｎｅＭ２Ｍカメラを既に登録している。同様に、＜ｓｔｒｅｅｔＣａｍｅｒａ−１＞のコンテキスト情報の１つは、街灯１に設置されている（例えば、事実１）ということである。

ステップ３１１で、ＣＩＭアプリケーションＡＰＰ−１（市道監視部門）は、事故１が発生したことを認識しており、例えば、この事故の場所など、事故１についての事実または知識を有している。
事実２：Accident-1 has-incident-location “40.079136, -75.288823”

ＡＰＰ−１は、街灯に設置されているカメラ（事故１を記録している）から画像を収集することを目的としており、カメラが壊れていなかったかどうかを確かめる。それに応じて、問い合わせステートメントが、下記のように記述される場合がある（ここで、ステートメントは、ＳＰＡＲＱＬ言語を使用して記述されるが、これは簡単な提示のためだけのものであることに留意されたい。言い換えると、問い合わせステートメントは、ＣＩＭによってサポートされる任意の形態で記述される場合がある）。
SELECT ?camera
WHERE ｛
?device is-a Camera
?device is-involved-in Accident-1
｝

ステップ３１２では、ＡＰＰ−１は、ＣＩＭ発見サービスに事故１についての事実２（例えば、その位置）と共にどのカメラが事故１に関与しているかについて発見要求を送信する。

ステップ３１３では、ＣＩＭ発見サービスは、発見要求に直接答えることはできず、さらにセマンティック推論器に支援を要請する。

ステップ３１４では、発見サービスは、セマンティック推論器に事実２および（＜ｓｔｒｅｅｔＣａｍｅｒａ−１＞についての事実１を含む）カメラのセマンティック情報と共に要求を送信する。言い換えると、事実１および事実２は、「Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳ」と見なすことができる。

ステップ３１５では、セマンティック推論器は、街灯位置マップについての追加の事実を使用することを決定する。例えば、事実２は事故の地理的位置だけを含むので、セマンティック推論器は、街灯についてのより多くの情報を必要または要求し、どの街灯が関与したかを判断する場合がある。例えば、事実３は、街灯１についての追加の情報である。
事実３：streetLamp-1 has-incident-location “40.079236, -75.288623”

ステップ３１６では、セマンティック推論器は、さらにセマンティック推論を行って、いくつかの新しい事実（＜ｓｔｒｅｅｔＣａｍｅｒａ−１＞は、事故１に関与していた）を生成する。例えば、以下に示す規則１は、街灯１は事故１に関与したという新しい事実（推測事実１）を推断するために使用することができる。
規則１：IF A has-location Coordination-1 and B has-location Coordination-2 and distance(Coordination-1, Coordination-2) < 20 meters, THEN A is-involved-in B
推測事実１：streetlamp-1 is-involved-in Accident-1

さらに、推測事実１および事実１を用いて、別の推論が、下記の規則（規則２）を使用することによって実行されて、別の推測事実（例えば、推測事実２）が、推断されてもよい。
規則１：IF A is-involved-in B and C is-installed-on A THEN C is-involved-in B
推測事実２：<streetCamera-1> is-involved-in Accident-1

ステップ３１７では、新しい事実が、ＣＩＭ発見サービスに返信される。ステップ３１８では、新しい事実を使用して、推測事実２が、＜ｓｔｒｅｅｔＣａｍｅｒａ−１＞は事故１に関与したカメラであることを示すので、ここでは、ＣＩＭ発見サービスはＡＰＰ−１からの問い合わせに答えることができる。ステップ３１９では、ＡＰＰ−１は、＜ｓｔｒｅｅｔＣａｍｅｒａ−１＞が事故１に関与したことを通知される。ステップ３２０では、ＡＰＰ−１は、＜ｓｔｒｅｅｔＣａｍｅｒａ−１＞の画像を読み出すようにＣＩＭレジストリサーバとコンタクトし、さらにレジストリサーバは、ｏｎｅＭ２Ｍシステム内の＜ｓｔｒｅｅｔＣａｍｅｒａ−１＞リソースから画像を読み出すことをｏｎｅＭ２ＭＩＰＥに要請する。

＜ｆａｃｔｓ＞リソース定義に関して、所定のＦＳは、異なるタイプの知識を指す場合がある。まず、ＦＳは、所定のユースケース（例えば、病院、市消防局、建物、部屋など、多くのドメイン概念／クラスおよびそれらの関係が定義されている、図５に関連するスマートシティユースケース）でのドメイン知識を記述するオントロジーを指す場合がある。したがって、このようなタイプのＦＳは、ｏｎｅＭ２Ｍ＜ｏｎｔｏｌｏｇｙ＞リソースとして具現化される可能性がある。次に、ＦＳは、システム内のリソース／エンティティ／モノについてのセマンティックアノテーションを指す場合がある。図５に関連する先の例を再度用いて、ＦＳは、建物１の部屋１０９に配備されたカメラ１１１のセマンティックアノテーションである場合がある。したがって、このタイプのＦＳは、ｏｎｅＭ２Ｍ＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースとして具現化される可能性がある。

ＦＳは、特定のインスタンスに関連する事実を指す場合がある。図５に関連する先の例を再度用いて、ＦＳは、病院の現在の管理ゾーン定義、例えば、その建物／部屋構成／割り当て情報（例えば、管理ゾーンＭＺ−１は、血液検査サンプルを保管するために使用される部屋、例えば、建物１の部屋１０９、建物３の部屋１１７を含むなど）を記述する場合がある。このタイプの事実に関して、これはシステム内で個別に存在する場合があり、例えば、必ずしも、他のリソース／エンティティ／モノに対するセマンティックアノテーションであるわけではないことに留意されたい。したがって、新しいタイプのｏｎｅＭ２Ｍリソース（いわゆる＜ｆａｃｔｓ＞）が定義されて、このようなタイプのＦＳに格納される。同じ目的を有する限り、それは異なる名前がつけられてもよいことに留意されたい。＜ｆａｃｔｓ＞のリソース構造を図２４に示す。ＦＳは、このリソースがセマンティックタイプのデータを格納するために使用されてよい場合、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞リソースを指す場合がある。加えて、より一般的には、セマンティックタイプのデータが格納されている場合がある限り、ＦＳは、ｏｎｅＭ２Ｍによって定義される何らかの将来的な新しいリソースタイプを指す場合がある。

上記の＜ｆａｃｔｓ＞リソースは、表２で定められる子リソースのうち１つまたは複数を含む場合がある。

上記の＜ｆａｃｔｓ＞リソースは、表３（表３−１〜表３−３）で定められる属性のうち１つまたは複数を含む場合がある。

以下に提示する＜ｆａｃｔｓ＞リソースでのＣＲＵＤ操作は、セマンティック推論データを使用可能にすることに関して本明細書で提示する関連するプロシージャのｏｎｅＭ２Ｍモデルであることに留意されたい。＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースが、（例えば、「記述子」属性を使用して）事実を格納するために使用される場合があるので、ｆａｃｔＴｙｐｅ、ｒｕｌｅｓＣａｎＢｅＵｓｅｄ、ｕｓｅｄＲｕｌｅｓ、ｏｒｉｇｉｎａｌＦａｃｔｓなどの属性は、セマンティック推論目的をサポートするために、既存の＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースに対する新しい属性となる場合があることに留意されたい。例えば、＜ＳＤ−１＞および＜ＳＤ−２＞は、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースのタイプであり、かつ＜ＣＳＥ−１＞のセマンティックアノテーションであると仮定する。＜ＳＤ−１＞は、＜ＣＳＥ−１＞の元のセマンティックアノテーションである場合がある。これに対して、＜ＳＤ−２＞は、＜ＣＳＥ−１＞の追加のセマンティックアノテーションである。例えば、＜ＳＤ−２＞の「ｆａｃｔＴｙｐｅ」は、＜ＳＤ−２＞リソースの「記述子」属性に格納されたトリプル／事実がセマンティック推論操作に基づいた推論結果（例えば、推測事実）であることを示す場合がある。言い換えると、＜ＳＤ−２＞に格納されているセマンティックアノテーションは、セマンティック推論を通して生成されたものである。同様に、＜ＳＤ−２＞のｒｕｌｅｓＣａｎＢｅＵｓｅｄ、ｕｓｅｄＲｕｌｅｓ、ｏｒｉｇｉｎａｌＦａｃｔｓ属性は、さらに、＜ＳＤ−２＞に格納されている事実が（どのｉｎｐｕｔＦＳおよび推論規則に基づいて）どのように生成されたか、および、＜ＳＤ−２＞に格納されている事実が、他の推論操作のためにどのように使用されてよいかについての詳細な情報を示す場合がある。

＜ｆａｃｔｓ＞の作成：＜ｆａｃｔｓ＞リソースを作成するために用いられるプロシージャ。

＜ｆａｃｔｓ＞の読み出し：＜ｆａｃｔｓ＞リソースの属性を読み出すために用いられるプロシージャ。

＜ｆａｃｔｓ＞の更新：＜ｆａｃｔｓ＞リソースの属性を更新するために用いられるプロシージャ。

＜ｆａｃｔｓ＞の削除：＜ｆａｃｔｓ＞リソースを削除するために用いられるプロシージャ。

＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞リソース定義：概して、＜ｆａｃｔｓ＞リソースは、例えば、＜ＡＥ＞または＜ＣＳＥＢａｓｅ＞リソースの子リソースとしていずれかの場所に格納されている場合がある。あるいは、新しい＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞が、新しいｏｎｅＭ２Ｍリソースタイプとして定義されてもよく、これは、必要とされるか、または要求される事実を見つけることを容易にするように、複数の＜ｆａｃｔｓ＞を格納しているハブであってもよい。＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞リソースは、＜ＣＳＥＢａｓｅ＞または＜ＡＥ＞リソースの子リソースであってもよい。＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞のリソース構造を図２５に示す。

＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞リソースは、表８で定められるような子リソースを含む。

上記の＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞リソースは、表９で定められる属性のうち１つまたは複数を含む場合がある。

＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞の作成：＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞リソースを作成するために用いられるプロシージャ。

＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞の読み出し：＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞リソースを読み出すために用いられるプロシージャ。

＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞の更新：既存の＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞リソースを更新するために用いられるプロシージャ。

＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞の削除：既存の＜ｆａｃｔＲｅｐｏｓｉｔｏｒｙ＞リソースを削除するために用いられるプロシージャ。

＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞リソース定義：新しいタイプのｏｎｅＭ２Ｍリソース（＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞と呼ばれる）が、ＲＳを格納するために定義され、これは、（ユーザ定義）推論規則を格納するために使用されるものである。同じ目的を有する限り、それは異なる名前がつけられてもよいことに留意されたい。＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞のリソース構造を図２６に示す。

上記の＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞リソースは、表１４で定められる子リソースのうち１つまたは複数を含む場合がある。

上記の＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞リソースは、表１５（表１５−１〜表１５−３）で定められる属性のうち１つまたは複数を含む場合がある。

推論規則を表すためにＲＩＦを使用する方法の例を以下に示す。本開示で用いられる下記の推論規則を考慮に入れる。
規則１：IF A is-located-in B && B is-managed-under C, THEN A monitors-room-in C

規則１は、下記のＲＩＦ規則のように記述される場合がある（ＲＩＦシンタックスによって定義されるキーワードは太字の文字であり、ＲＩＦ仕様のより詳細は、ＲＩＦＰｒｉｍｅｒ、https://www.w3.org/2005/rules/wiki/Primer［１２］で確認することができる）。
Document(
Prefix(rdf <http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
Prefix(rdfs <http://www.w3.org/2000/01/rdf-schema#>)
Prefix(exA <http://example.com/#>)
Prefix(exB <http://example.com/#>)

Group(
Forall ?Camera ?Room ?MZ (
If And(
?Camera # exA:Camera
?Room # exA:Room
?MZ # exB:ManagementZone
exA:is-located-in (?Camera ?Room)
exB:is-managed-under (?Room ?MZ)
)
Then exC: monitors-room-in (?Camera ?MZ)
)
)
)

上記規則についての説明は、下記の５つの説明である場合がある。説明１：上記規則は、Ｉｆ…Ｔｈｅｎ形式で表される抽象シンタックスに基本的に従う。説明２：２つの演算子、ＧｒｏｕｐおよびＤｏｃｕｍｅｎｔは、ＲＩＦの規則を記述するために使用される場合がある。Ｇｒｏｕｐは、ＲＩＦ文書内の規則のセットの範囲を定めるか、またはまとめてグループにするために使用される。文書は、多数のグループまたは、１つだけのグループを含む場合がある。同様に、グループは、複数の規則をまとめてグループにすることを通常目的としているが、単一の規則で構成される場合がある。ＲＩＦ文書が、他の文書を読み込み、それによりそれ自体がマルチ文書オブジェクトとなる場合があるので、明確なＤｏｃｕｍｅｎｔ演算子を有する必要がある。実用的な目的としては、通常、Ｄｏｃｕｍｅｎｔ演算子は文書の先頭で使用され、その後に接頭辞宣言および規則の１つまたは複数のグループが続くことを認識していれば充分である。

説明３：「is-located-in」のような述語定数は、「現状のまま」だけでは使用することができないが、曖昧さをなくすことが可能である。この曖昧性除去は、この規則で使用される定数が２つ以上のソースから起こり、かつ異なるセマンティック意味を有する場合があるという問題を解決する。ＲＩＦでは、曖昧性除去は、ＩＲＩ、および接頭辞宣言Ｐｒｅｆｉｘ（ｎｓ＜ＴｈｉｓＩＲＩ＞）を記述することによる接頭辞宣言の一般形を用いて行われる。次に、定数名は、文字列ｎｓ：ｎａｍｅを用いる規則で曖昧性除去される場合がある。例えば、述語「is-located-in」は、（接頭辞「ｅｘＡ」を伴う）例示的オントロジーＡによって定義される述語であり、一方で、述語「is-managed-under」は、（接頭辞「ｅｘＢ」を伴う）別の例示的オントロジーＢによって定義される述語であり、かつ述語「monitors-room-in」は、（接頭辞「ｅｘＣ」を伴う）別の例示的オントロジーＣによって定義される述語である。

説明４：同様に、「？」（例えば、？Ｃａｍｅｒａ）で始まる変数については、特別な記号「＃」（ＲＤＦスキーマで定義される述語「is-type-of」に等しい）を用いることによって、どのタイプのインスタンスが、その変数に対する入力となり得るかが定義される必要がある。例えば、「?Camera # exA:Camera」は、オントロジーＡで定義されたクラス「Ｃａｍｅｒａ」のインスタンスだけ、変数「？Ｃａｍｅｒａ」に対する入力として使用することができることを意味する。説明５：上記の規則は、論理積を含む場合があり、ＲＩＦでは、論理積は、接頭表記法で再記述され、例えば、ＡとＢの２値は、Ａｎｄ（ＡＢ）と記述される。

以下に提示する＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞リソースでのＣＲＵＤ操作は、ＲＳ使用可能性に関して本明細書で提示する関連するプロシージャのｏｎｅＭ２Ｍモデルであることに留意されたい。

＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞の作成：＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞リソースを作成するために用いられるプロシージャ。

＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞の読み出し：＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞リソースの属性を読み出すために用いられるプロシージャ。

＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞の更新：＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞リソースの属性を更新するために用いられるプロシージャ。

＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞の削除：＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞リソースを削除するために用いられるプロシージャ。

＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞リソース定義：概して、＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞リソースは、例えば、＜ＡＥ＞または＜ＣＳＥＢａｓｅ＞リソースの子リソースとしていずれかの場所に格納されている場合がある。あるいは、新しい＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞が、新しいｏｎｅＭ２Ｍリソースタイプとして定義されてもよく、これは、必要とされるか、または要求される規則を見つけることを容易にするように、複数の＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞を格納しているハブであってもよい。＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞リソースは、＜ＣＳＥＢａｓｅ＞または＜ＡＥ＞リソースの子リソースであってもよい。＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞のリソース構造を図２７に示す。

＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞リソースは、表８で定められる子リソースのうち１つまたは複数を含む場合がある。

＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞リソースは、表９で定められる属性のうち１つまたは複数を含む場合がある。

＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞の作成：＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞リソースを作成するために用いられるプロシージャ。

＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞の読み出し：＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞リソースを読み出すために用いられるプロシージャ。

＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞の更新：既存の＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞リソースを更新するために用いられるプロシージャ。

＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞の削除：既存の＜ｒｕｌｅＲｅｐｏｓｉｔｏｒｙ＞リソースを削除するために用いられるプロシージャ。

＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソース定義：＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞と呼ばれる新しいリソースについて記載するが、これは、セマンティック推論サービスを発現させるためのものである。＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞のリソース構造を図２８に示す。

ＣＳＥがセマンティック推論能力を有する場合、ＣＳＥはセマンティック推論処理をサポートするために、それ自体に（例えば、＜ＣＳＥＢａｓｅ＞の下に）、＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースを作成することができる。

上記の＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースは、表２６（表２６−１〜表２６−２）で定められる子リソースのうち１つまたは複数を含む場合がある。

上記の＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースは、表２７（表２７−１〜表２７−２）で定められる属性のうち１つまたは複数を含む場合がある。

あるいは、セマンティック推論を発現させる別の方法は、既存の＜ＣＳＥＢａｓｅ＞または＜ｒｅｍｏｔｅＣＳＥ＞リソースを使用する。したがって、表２７に示す属性は、＜ＣＳＥＢａｓｅ＞または＜ｒｅｍｏｔｅＣＳＥ＞リソースに対する新しい属性である場合がある。セマンティック推論要求を取得する（例えば、受信する）＜ＣＳＥＢａｓｅ＞向けのいくつかの方法がある場合がある。１）＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞リソースは、この動作で定義されるセマンティック推論操作のトリガに関する要求を受信する＜ＣＳＥＢａｓｅ＞または＜ｒｅｍｏｔｅＣＳＥ＞リソースの新しい仮想子リソースであってもよい。２）新しいリソースを定義する代わりに、トリガが要求メッセージで定義される場合がある＜ＣＳＥＢａｓｅ＞に、ＲＩからの要求が直接送信されてもよい（例えば、「ｒｅａｓｏｎｉｎｇＩｎｄｉｃａｔｏｒ」と呼ばれる新しいパラメータが、要求メッセージに含まれるように定義されてもよい）。

＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞の作成：＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースを作成するために用いられるプロシージャ。

＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞の読み出し：＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースを読み出すために用いられるプロシージャ。

＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞の更新：既存の＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースを更新するために用いられるプロシージャ。

＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞の削除：既存の＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースを削除するために用いられるプロシージャ。

＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞リソース定義：＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞は、それ自体が表現を有していないので仮想リソースである。それは、＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースの子リソースである。更新操作が＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞リソースに送信されるときに、セマンティック推論操作がトリガされる。

概して、以下に開示される下記の目的のために、発信元は、この＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞リソースに要求を送信する場合がある。第１の例では、要求は、１回限りの推論操作をトリガすることである場合がある。この例では、次の各情報が要求内で運ばれてよい。ａ）推論操作で求められるべき事実、ｂ）推論操作で使用すべき推論規則、ｃ）この要求が１回限りの推論操作に対するものであることを示す推論タイプ、またはｄ）前述のセクションのリストに記載の任意の他の情報。第２の例では、要求は、連続的な推論操作をトリガすることである場合がある。第２の例では、次の各情報が要求内で運ばれてよい。ａ）推論操作で使用すべき事実、ｂ）推論操作で使用すべき推論規則、ｃ）この要求が連続的な推論操作に対するものであることを示す推論タイプ、ｄ）＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソース作成向けの任意の他の情報。例えば、ｃｏｎｔｉｎｕｏｕｓＥｘｅｃｕｔｉｏｎＭｏｄｅは、＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソース内の属性の１つである。したがって、要求は、この属性を設定するために使用されてもよい関連する情報を運んでもよい。第３の例では、要求は、既存の推論ジョブに対する新しい推論操作をトリガすることである場合がある。この第３の例では、ｊｏｂＩＤ、すなわち既存の＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソースのＵＲＩの情報が、要求内で運ばれてよい。

加えて、要求内で運ばれる情報、例えば、使用すべき事実および推論規則に関して、要求内でそれらを運ぶ複数の方法がある。１）事実および推論規則は、要求のコンテンツパラメータ内で運ばれる場合があるか、または２）事実および推論規則は、要求の新しいパラメータ内で運ばれる場合がある。新しいパラメータの例は、事実パラメータおよび規則パラメータである。事実パラメータに関して、事実パラメータは推論操作で使用すべき事実を運ぶ場合がある。規則パラメータに関して、規則パラメータは推論操作で使用すべき推論規則を運ぶ場合がある。

「事実」パラメータに関して、それは下記の方法を使用して、事実についての情報を含む場合がある。
ケース１：事実パラメータは、ＲＤＦトリプルなど事実データを直接含む場合がある。
ケース２：事実パラメータはまた、使用すべき事実が格納されている１つまたは複数のＵＲＩを含む場合がある。

「規則」パラメータに関して、それは、下記の方法を使用して、事実についての情報を含む場合がある。
ケース１：規則パラメータは、使用すべき規則が格納されている１つまたは複数のＵＲＩを含む場合がある。
ケース２：規則パラメータは、使用すべき推論規則のリストを直接運ぶ場合がある。
ケース３：規則パラメータは、特定の標準ＳＰＡＲＱＬ含意レジームを示す文字列値である場合がある（ＳＰＡＲＱＬ含意は、異なる含意レジームによって定義されるような標準推論規則を使用するセマンティック推論の１タイプであることに留意されたい）。例えば、Ｒｕｌｅｓ＝“ＲＤＦＳ”の場合、ＲＤＦＳ含意レジームによって定義された推論規則が使用されることを意味する。

実装形態選択に関して、上記のケースのうち１つだけを実装するか、これらのケースを同時に実装してもよい。後者のケースでは、ｔｙｐｅｏｆＦａｃｔｓＲｅｐｒｅｓｅｎｔａｔｉｏｎと、ｔｙｐｅｏｆＵｓｅＲｅａｓｏｎｉｎｇと呼ばれる２つの新しいパラメータが定義され、これらは、要求内に含まれ、かつ以下に示すインジケータである場合がある例示的値を有することがあるパラメータである。
・ｔｙｐｅｏｆＦａｃｔｓＲｅｐｒｅｓｅｎｔａｔｉｏｎ＝１、事実パラメータは、ＵＲＩを格納している。
・ｔｙｐｅｏｆＦａｃｔｓＲｅｐｒｅｓｅｎｔａｔｉｏｎ＝２、事実パラメータは、事実のリスト、例えば、使用すべきＲＤＦトリプルを格納している。
・ｔｙｐｅｏｆＲｕｌｅｓＲｅｐｒｅｓｅｎｔａｔｉｏｎ＝１、規則パラメータは、ＵＲＩのリストを格納している。
・ｔｙｐｅｏｆＲｕｌｅｓＲｅｐｒｅｓｅｎｔａｔｉｏｎ＝２、規則パラメータは、推論規則のリストを格納している。
・ｔｙｐｅｏｆＲｕｌｅｓＲｅｐｒｅｓｅｎｔａｔｉｏｎ＝３、規則パラメータは、標準含意レジームを示す文字列値を格納している。

＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞リソースは、＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞親リソースが、ホストＣＳＥによって作成されるときに作成される。Ｍｃａ、ＭｃｃまたはＭｃｃ’を介する作成操作は適用されない。

読み出し操作は、＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞に対して適用不可ではない。

＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞の更新：更新操作は、セマンティック推論操作をトリガするために使用される。連続的な推論操作のために、下記の方法で＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞を利用してもよい。第１の方法では、＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞更新操作を使用する。この第１の方法では、推論タイプパラメータが、要求内で運ばれ、この要求が連続的な推論操作を作成することを必要としていることを示す場合がある。第２の方法では、＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞作成操作を使用する。

下記は、表３２Ａ（表３２Ａ−１〜表３２Ａ−３）に示す＜ｒｅａｓｏｎｇｉｎｇＰｏｒｔａｌ＞更新操作の処理の代替バージョンである。例えば、このバージョンでは、事実および推論規則は、要求内の事実パラメータおよび規則パラメータで運ばれる。一方、簡略化のために、追加の事実および規則を加えることを考慮しない。

＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞の削除：＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞リソースは、＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞親リソースが、ホストＣＳＥによって削除されるときに削除される。Ｍｃａ、ＭｃｃまたはＭｃｃ’を介する削除操作は適用されない。

＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソース定義：（＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞と呼ばれる）新しいタイプのｏｎｅＭ２Ｍリソースが、特定の推論ジョブインスタンスを記述するために定義される（それは、１回限りの推論操作または連続的な推論操作である場合がある）。同じ目的を有する限り、それは異なる名前がつけられてもよいことに留意されたい。

下記は、連続的推論ジョブを行う代替方法である場合があることに留意されたい。第１の方法では、発信者は、ＣＳＥがセマンティック推論能力をサポートできる場合、このＣＳＥの＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞（または＜ＣＳＥＢａｓｅ＞リソース）に要求を送信して、＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソースを作成してもよい。第２の方法では、発信元は、＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースの＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞に作成要求を送信して、＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソースを作成してもよい（または、＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞に更新要求を送信してもよいが、要求に含まれる推論タイプパラメータが、これが連続的な推論操作を生じさせるためのものであることを示してもよい）。

＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞のリソース構造を図２９に示す。＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソースは、表３３（表３３−１〜表３３−２）で定められる子リソースのうち１つまたは複数を含む場合がある。

上記の＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソースは、表３４（表３４−１〜表３４−３）で定められる属性のうち１つまたは複数を含む場合がある。

＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソースを作成するために用いられるプロシージャ。

＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞の読み出し：＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソースの属性を読み出すために用いられるプロシージャ。

＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞の更新：＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソースの属性を更新するために用いられるプロシージャ。

＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞の削除：＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソースを削除するために用いられるプロシージャ。

＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞リソース定義：（＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞と呼ばれる）新しいタイプのｏｎｅＭ２Ｍリソースが、推論結果を格納するために定義される。同じ目的を有する限り、それは異なる名前がつけられてもよいことに留意されたい。＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞のリソース構造を図３０に示す。

上記の＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞リソースは、表３９で定められる子リソースのうち１つまたは複数を含む場合がある。

上記の＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞リソースは、表４０で定められる属性のうち１つまたは複数を含む場合がある。

作成操作は、＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞に対して適用されない。セマンティック推論器能力を有するホストＣＳＥが、＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞親リソースによって表される推論ジョブのセマンティック推論処理を実行するときに、＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞リソースは、そのホストＣＳＥによって自動的に生成される。

＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞の読み出し：＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞リソースの属性を読み出すために用いられるプロシージャ。

読み出し操作は、＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞に対して適用されない。

＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞の削除：＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞リソースを削除するために用いられるプロシージャ。

＜ｊｏｂＥｘｅｃｕｔｉｏｎＰｏｒｔａｌ＞リソース定義：それ自体が表現を有しておらず、かつ先に定義した＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞リソースと類似の機能を有するので、＜ｊｏｂＥｘｅｃｕｔｉｏｎＰｏｒｔａｌ＞は仮想リソースである。それは、＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソースの子リソースである。属性ｃｏｎｔｉｎｕｏｕｓＥｘｅｃｕｔｉｏｎＭｏｄｅの値が「ＲＩがジョブ実行をトリガするとき」に設定され、かつ更新操作が＜ｊｏｂＥｘｅｃｕｔｉｏｎＰｏｒｔａｌ＞リソースに送信されると、＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞親リソースに対応するセマンティック推論実行がトリガされる。

＜ｊｏｂＥｘｅｃｕｔｉｏｎＰｏｒｔａｌ＞の作成：＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞親リソースが作成されると、＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞リソースが作成される。

＜ｊｏｂＥｘｅｃｕｔｉｏｎＰｏｒｔａｌ＞の読み出し：読み出し操作は、＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞に対して適用されない。

＜ｊｏｂＥｘｅｃｕｔｉｏｎＰｏｒｔａｌ＞の更新：更新操作は、セマンティック推論実行をトリガするために使用される。これは、＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞リソースにｊｏｂＩＤと共に更新要求を送信することに対する代替策である。

下記は、表４３Ａ（表４３Ａ−１〜表４３Ａ−２）に示す＜ｊｏｂＥｘｅｃｕｔｉｏｎＰｏｒｔａｌ＞更新操作の処理の簡略化または代替バージョンである。例えば、簡略化のために、追加の事実および規則を提供することを考慮しない。

＜ｊｏｂＥｘｅｃｕｔｉｏｎＰｏｒｔａｌ＞の削除：＜ｊｏｂＥｘｅｃｕｔｉｏｎＰｏｒｔａｌ＞リソースは、＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞親リソースが、ホストＣＳＥによって削除されるときに、削除される。Ｍｃａ、ＭｃｃまたはＭｃｃ’を介する削除操作は適用されない。

個別のセマンティック推論処理を可能にすること、および他の有効性を向上させることに関するセマンティック推論関連プロシージャ向けのｏｎｅＭ２Ｍモデルを提示する。このセクションは、本明細書で開示される方法に関するいくつかのｏｎｅＭ２Ｍモデルを提示する。

図１３に開示される１回限りの推論操作のｏｎｅＭ２Ｍモデル。このシナリオでは、（ＲＩのような）ＡＥ−１は、いくつかの関心のあるＩｎｐｕｔＦＳ（＜ｆａｃｔｓ−１＞）およびＲＳ（＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞）を既に識別しており、いくつかの新しい知識／事実を発見するために、（ＳＲのような）ＣＳＥ−１で１回限りの推論操作を開始することを望んでいる。図３１は、１回限りの推論操作に関するｏｎｅＭ２Ｍプロシージャを示し、かつ詳細を以下に記載する。

前提条件（ステップ３４０）：ＡＥ−１は、（ＳＲとして動作する）ＣＳＥ−１の存在、および、ＣＳＥ−１で作成された＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースを認識している。発見を通して、ＡＥ−１は、ＣＳＥ−２上の関心のある＜ｆａｃｔｓ−１＞リソースのセット（＜ｆａｃｔｓ−１＞はＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳになる）、およびＣＳＥ−３上のいくつかの＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞（＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞はＩｎｉｔｉａｌ＿ＲＳになる）を既に識別している。

ステップ３４１：ＡＥ−１は、いくつかの新しい知識を発見するために、＜ｆａｃｔｓ−１＞および＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞を入力として使用して、ＣＳＥ−１での推論をトリガすることを目的としている。

ステップ３４２：ＡＥ−１は、ＣＳＥ−１上の＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞仮想リソースにＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳについての情報と共に推論要求を送信する。例えば、使用すべき事実および規則は、新たに開示する要求内の事実および規則パラメータによって記述される場合がある。

ステップ３４３：ＡＥ−１から送信された情報に基づいて、ＣＳＥ−１は、ＣＳＥ−２から＜ｆａｃｔｓ−１＞、およびＣＳＥ−３から＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞を読み出す。

ステップ３４４：ＡＥ−１によって提供された入力に加えて、任意選択で、ＣＳＥ−１は、ＣＳＥ−２上の＜ｆａｃｔｓ−２＞およびＣＳＥ−３上の＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−２＞が同様に利用される必要があると判断してもよい。

ステップ３４５：ＣＳＥ−１は、ＣＳＥ−２から追加のＦＳ（例えば、＜ｆａｃｔｓ−２＞）、およびＣＳＥ−３から追加のＲＳ（例えば、＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−２＞）を読み出す。

ステップ３４６：全てのＩｎｐｕｔＦＳ（例えば、＜ｆａｃｔｓ−１＞および＜ｆａｃｔｓ−２＞）およびＲＳ（例えば、＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞および＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−２＞）を用いて、ＣＳＥ−１は、推論処理を実行して推論結果を得る。

ステップ３４７：ＳＲ２３２は、ＡＥ−１に推論結果を返信する。さらに、本明細書で提示するように、ＳＲ２３２は、＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞リソースを作成して推論結果を格納してもよい。

図１４に開示される連続的な推論操作のｏｎｅＭ２Ｍモデル。このシナリオでは、（ＲＩのような）ＡＥ−１は、いくつかの関心のあるＩｎｐｕｔＦＳ（＜ｆａｃｔｓ−１＞）およびＲＳ（＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞）を既に識別しており、いくつかの新しい知識（本明細書では、事実および知識といった用語が同じ意味で使用される場合がある）を発見するために、（ＳＲのような）ＣＳＥ−１で連続的な推論操作を開始することを望んでいる。図３２は、連続的な推論操作に関するｏｎｅＭ２Ｍモデルのプロシージャを示し、かつ詳細を以下に記載する。

前提条件（ステップ３５０）：ＡＥ−１は、（ＳＲとして動作する）ＣＳＥ−１の存在、および、ＣＳＥ−１で作成された＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースを認識している。発見を通して、ＡＥ−１は、ＣＳＥ−２上の関心のある＜ｆａｃｔｓ−１＞リソースのセット（＜ｆａｃｔｓ−１＞はＩｎｉｔｉａｌ＿ＩｎｐｕｔＦＳになる）、およびＣＳＥ−３上のいくつかの＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞（＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞はＩｎｉｔｉａｌ＿ＲＳになる）を既に識別している。

ステップ３５１：ＡＥ−１は、＜ｆａｃｔｓ−１＞および＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞を入力として使用して、ＣＳＥ−１での連続的な推論操作をトリガすることを目的としている。

ステップ３５２：ＡＥ−１は、＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースの＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞子リソースに、Ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳおよびＩｎｉｔｉａｌ＿ＲＳについての情報、ならびに作成されることになる＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞に関するいくつかのその他の情報と共に作成要求を送信して、＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ＞リソースを作成する。あるいは、別の可能な実装形態としては、ＡＥ−１が、＜ＣＳＥＢａｓｅ＞または＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソースに作成要求を送信してもよい。

ステップ３５３：ＡＥ−１から送信された情報に基づいて、ＣＳＥ−１は、ＣＳＥ−２から＜ｆａｃｔｓ−１＞、およびＣＳＥ−３から＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞を読み出す。ＣＳＥ−１はまた、それらの２つのリソースをサブスクリプションする。

ステップ３５４：ＡＥ−１によって提供された入力に加えて、任意選択で、ＣＳＥ−１は、ＣＳＥ−２上の＜ｆａｃｔｓ−２＞およびＣＳＥ−３上の＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−２＞が同様に利用される必要があると判断してもよい。

ステップ３５５：ＣＳＥ−１は、ＣＳＥ−２から追加のＦＳ（例えば、＜ｆａｃｔｓ−２＞）、およびＣＳＥ−３から追加のＲＳ（例えば、＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−２＞）を読み出す。ＣＳＥ−１はまた、それらの２つのリソースをサブスクリプションする。

ステップ３５６：全てのＩｎｐｕｔＦＳ（例えば、＜ｆａｃｔｓ−１＞および＜ｆａｃｔｓ−２＞）およびＲＳ（例えば、＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞および＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−２＞）を用いて、ＣＳＥ−１は、＜ｓｅｍａｎｔｉｃＲｅａｓｏｎｅｒ＞リソース（または他の好ましい位置）の下に＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ−１＞リソースを作成する。例えば、ｒｅａｓｏｎｉｎｇＴｙｐｅ属性が、「連続的な推論操作」に設定され、かつｃｏｎｔｉｎｕｏｕｓＥｘｅｃｕｔｉｏｎＭｏｄｅ属性が、「関連するＦＳ／ＲＳが変更されるとき」に設定される。次いで、ＣＳＥ−１は推論処理を実行して推論結果を得る。結果は、＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ−１＞のｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ属性か、または新しい＜ｒｅａｓｏｎｉｎｇＲｅｓｕｌｔ＞タイプの子リソースに格納されてよい。

ステップ３５７：ＳＲ２３２は、ＡＥ−１に推論結果を返信する。

ステップ３５８：ステップ３で先に行われたサブスクリプションに基づいて、＜ｆａｃｔｓ−１＞、＜ｆａｃｔ−２＞、＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞および＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−２＞のいずれの変更も、ＣＳＥ−１への通知をトリガする。

ステップ３５９：ＣＳＥ−１が、通知を受信する限り、関連するＦＳおよびＲＳの最新の値を使用して＜ｒｅａｓｏｎｉｎｇＪｏｂＩｎｓｔａｎｃｅ−１＞の新しい推論処理を実行する。新しい推論結果が、ＡＥ−１に送信される。

図１５に開示されるプロシージャのｏｎｅＭ２Ｍモデル。このシナリオでは、（ＳＵのような）ＡＥ−１は、（ＳＥのような）ＣＳＥ−１でのセマンティックリソース発見を行うことを目的としている。リソース発見処理の間、ＣＳＥ−１は、最適化された発見結果を得るために、ＣＳＥ−２による推論サポートをさらに利用してもよい。図３３Ａは、推論によってサポートされるＩＤＢ強化に関するｏｎｅＭ２Ｍプロシージャの例を示し、かつ詳細を以下に記載する。

ステップ３６１：ＡＥ−１は、セマンティックリソース発見操作を開始することを目的としている。

ステップ３６２：ＡＥ−１は、ＣＳＥ−１の＜ＣＳＥＢａｓｅ＞にＳＰＡＲＱＬ問い合わせステートメントが含まれている要求を送信して、セマンティック発見操作を開始する。

ステップ３６３：ＡＥ−１からの要求に基づいて、ＣＳＥ−１は、セマンティックリソース発見処理を行うことを開始する。特に、ＣＳＥ−１は、ここで、＜ＡＥ−２＞の＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ−１＞子リソースを調査することによって、発見結果に＜ＡＥ−２＞リソースが含まれる必要があるかどうかの評価を開始する。しかし、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ−１＞内の現在のデータは、ＡＥ−１から送信されたＳＰＡＲＱＬ問い合わせステートメントと一致しない場合がある。このため、ＣＳＥ−１は、この要求を処理するために、推論がさらに行われる必要があると判断する。

ステップ３６４：ＣＳＥ−１は、（セマンティック推論能力を有する）ＣＳＥ−２上の＜ｒｅａｓｏｎｉｎｇＰｏｒｔａｌ＞リソースに＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ−１＞に格納された情報と共に要求を送信して、推論処理を要求する。

ステップ３６５：ＣＳＥ−２はさらに、追加のＦＳおよびＲＳがこの推論処理に加えられる必要があると判断する。例えば、ＣＳＥ−１は、ＣＳＥ−３から＜ｆａｃｔｓ−１＞、およびＣＳＥ−４から＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞をそれぞれ読み出す。

ステップ３６６：（ＩＤＢのような）＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ−１＞、ならびに追加の＜ｆａｃｔｓ−１＞および＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ−１＞に格納された情報に基づいて、ＣＳＥ−１は、推論処理を実行して（ＩｎｆｅｒｒｅｄＦＳ−１と表される）推測事実を得る。

ステップ３６７：ＣＳＥ−２は、ＣＳＥ−１にＩｎｆｅｒｒｅｄＦＳ−１を返信する。

ステップ３６８：ＣＳＥ−１は、ＩｎｆｅｒｒｅｄＦＳ−１を＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ−１＞に格納されているデータと統合し、かつ元のＳＰＡＲＱＬステートメントを統合されたデータに適用して整合を得る。その結果、＜ＡＥ−２＞は発見結果に含まれることになる。ＣＳＥ−１は、全てのリソース発見処理が完了するまで、＜ＣＳＥＢａｓｅ＞の下の次のリソースの評価を続ける。

ステップ３６９：ＣＳＥ−１は、ＡＥ−１に最終の発見結果を返信する。

図３３Ａの代替プロシージャについて以下で論じるが、ここで、図３３Ａに示すものの簡略化されたバージョンを考慮に入れる場合がある。このシナリオでは、（ＳＵのような）ＡＥ−１は、ＣＳＥ−１に要求を送信してセマンティックリソース発見を行うことを目的とする場合がある。ここで、セマティック発見は、単に例であり、また別のセマンティック操作、例えば、セマンティック問い合わせなどであってもよいことに留意されたい。特に、このプロシージャでは、セマティックエンジン（ＳＥ）およびセマンティック推論器（ＳＲ）は、ＣＳＥ−１によって認識されている場合がある。それに応じて、リソース発見処理の間、ＣＳＥ−１はさらに、最適化された発見結果を得るために、推論サポートを利用する場合がある。

図３３Ｂは、図３３Ａの代替的なプロシージャを示し、かつ詳細を以下に記載する。ステップ３７１で、ＡＥ−１は、セマンティックリソース発見操作を開始することを目的としている。ステップ３７２で、ＡＥ−１は、ＣＳＥ−１の＜ＣＳＥＢａｓｅ＞にＳＰＡＲＱＬ問い合わせステートメントが含まれている要求を送信して、セマンティック発見操作を開始してもよい。ＡＥ−１はまた、セマンティック推論が使用されてよいかどうかを示す場合がある。例えば、ｕｓｅＲｅａｓｏｎｉｎｇと呼ばれる新しいパラメータが、この要求で運ばれてよい。下記のケースなど、このｕｓｅＲｅａｓｏｎｉｎｇパラメータの使用について複数の異なる方法がある。
ケース１：第１の実装形態は、ｕｓｅＲｅａｓｏｎｉｎｇが０または１である場合があるといったものである。ｕｓｅＲｅａｓｏｎｉｎｇ＝１の場合、これは、ＡＥ−１がＣＳＥ−１に、ＳＰＡＲＱＬ処理の間にセマンティック推論を適用することを要請することを意味し、その一方で、ｕｓｅＲｅａｓｏｎｉｎｇ＝０（またはｕｓｅＲｅａｓｏｎｉｎｇパラメータが、要求内に存在しない場合）は、ＡＥ−１がＣＳＥ−１に、セマンティック推論を適用することを要請しないことを意味する。この場合、どの推論規則を使用するかは、セマンティックエンジンまたはセマンティック推論器（例えば、このケースではＣＳＥ−１）によって完全に決定される。
ケース２：第２の実装形態は、ｕｓｅＲｅａｓｏｎｉｎｇが、使用すべき推論規則を格納している１つまたは複数の特定の＜ｒｅａｓｏｎｉｎｇＲｕｌｅ＞リソースを表すＵＲＩ（またはＵＲＩのリスト）である場合があるといったものである。
ケース３：第３の実装形態は、ＡＥ−１がＣＳＥ−１に、ＳＰＡＲＱＬ処理の間に使用することを望む推論規則のリストを、ｕｓｅＲｅａｓｏｎｉｎｇに直接格納する場合があるといったものである。
ケース４：第４の実装形態は、ｕｓｅＲｅａｓｏｎｉｎｇが、特定の標準ＳＰＡＲＱＬ含意レジームを示す文字列値である場合があるといったものである（ＳＰＡＲＱＬ含意は、異なる含意レジームによって定義されるような標準推論規則を使用するセマンティック推論の１タイプであることに留意されたい）。例えば、ｕｓｅＲｅａｓｏｎｉｎｇ＝“ＲＤＦＳ”の場合、これは、処理中にＲＤＦＳ含意レジームによって定義される推論（本明細書で含意として呼ばれる場合がある）規則を適用することを、ＡＥ−１がＣＳＥ−１に要請することを意味する。

実装形態選択に関して、上記の４つのケースのうち１つだけを実装するか、これらの４つのケースを同時に実装してもよい。後者のケースでは、ｔｙｐｅｏｆＲｕｌｅｓＲｅｐｒｅｓｅｎｔａｔｉｏｎと呼ばれる新しいパラメータが定義される場合があり、これは、要求内に含まれ、かつ下記の値または意味を有することがあるパラメータである。
・ｔｙｐｅｏｆＲｕｌｅｓＲｅｐｒｅｓｅｎｔａｔｉｏｎ＝１、ｕｓｅＲｅａｓｏｎｉｎｇパラメータは０または１である場合がある。
・ｔｙｐｅｏｆＲｕｌｅｓＲｅｐｒｅｓｅｎｔａｔｉｏｎ＝２、ｕｓｅＲｅａｓｏｎｉｎｇパラメータは、１つまたは複数のＵＲＩを格納する。
・ｔｙｐｅｏｆＲｕｌｅｓＲｅｐｒｅｓｅｎｔａｔｉｏｎ＝３、ｕｓｅＲｅａｓｏｎｉｎｇは、推論規則のリストを格納する。
・ｔｙｐｅｏｆＲｕｌｅｓＲｅｐｒｅｓｅｎｔａｔｉｏｎ＝４、ｕｓｅＲｅａｓｏｎｉｎｇは、標準ＳＰＡＲＱＬ含意レジームを示す文字列値を格納する。

ステップ３７３では、ＡＥ−１からの要求に基づいて、ＣＳＥ−１は、セマンティックリソース発見処理を行うことを開始する。例えば、ＣＳＥ−１は、ここで、＜ＡＥ−２＞の＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ−１＞子リソースを調査することによって、発見結果に＜ＡＥ−２＞リソースが含まれる必要があるかどうかの評価を開始する。特に、ＣＳＥ−１が、セマンティック推論を適用する能力を有する場合、ＣＳＥ−１は、まず、セマンティック推論が適用される必要があるかどうかを判断してもよい。したがって、ＣＳＥ−１はまた、ステップ３７２で定義されたような異なるケースに基づいて下記の操作を行ってもよい。
ケース１：ｕｓｅＲｅａｓｏｎｉｎｇ＝１である場合、ＣＳＥ−１は、使用すべき推論規則の適切なセットを決定してもよい。
ケース２：ｕｓｅＲｅａｓｏｎｉｎｇが１つまたは複数のＵＲＩを含んでいる場合、ＣＳＥ−１は、このパラメータによって示される関連する＜ｒｅａｓｏｎｉｎｇＲｕｌｅ＞リソースに格納される推論規則を読み出してもよい。
ケース３：ｕｓｅＲｅａｓｏｎｉｎｇが、推論規則のリストを直接格納している場合、ＣＳＥ−１は、推論のためにそれらの推論規則を使用してもよい。
ケース４：ｕｓｅＲｅａｓｏｎｉｎｇが、特定の標準ＳＰＡＲＱＬ含意レジームを示すことがある文字列値の場合、ＣＳＥ−１は、処理の間に対応する標準含意レジームによって定義される推論規則を使用してもよい。

ＡＥ−１が、一定のタイプの推論を要請するが、ＣＳＥ−１がこのような能力を有していないケースでは、セマンティック推論操作は適用されない場合がある。例えば、ＡＥ−１がＣＳＥ−１に間違ったＵＲＩを提供する場合、ＣＳＥ−１はこの間違ったＵＲＩに基づいて推論規則を読み出すことができないので、ＣＳＥ−１は、推論を適用しない場合がある。

ステップ３７４では、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ−１＞に格納されている情報および適用された推論規則に基づいて、ＣＳＥ−１は、推論処理をまず実行して推測事実を得ることができる。次に、ＣＳＥ−１は、推測事実を＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ−１＞に格納されている元のデータと統合し、次いで、元のＳＰＡＲＱＬステートメントをその統合されたデータに適用してもよい。その結果、＜ＡＥ−２＞は発見結果に含まれることになる。次に、ＣＳＥ−１は、発見操作が完了するまで、次の候補リソースの評価を続けてもよい。ステップ３７５では、ＣＳＥ−１は、ＡＥ−１に最終の発見結果を返信してもよい。

ＧＵＩインターフェースを図３４に提示するが、これは、ユーザが、セマンティック推論操作を閲覧、構成またはトリガするために使用することができるものである。例えば、図３４で考案されているようなＵＩを使用することによって、ユーザが推論操作のために使用を所望する事実および規則を、ユーザが指定することを可能にする。例えば、それらの事実および規則は、先に定義した＜ｆａｃｔｓ＞および＜ｒｅａｓｏｎｉｎｇＲｕｌｅｓ＞リソースに格納することができる。ユーザはまた、セマンティック推論規則（例えば、推測事実）を配信する場所を指定してもよい。デフォルト値を伴うそれらのパラメータを構成またはプログラムするために、ユーザインターフェースが実装されてよく、また、セマンティック推論サポートのある種の特性を有効または無効にする制御スイッチも実装されてよい。

下記の表４４（表４４−１〜表４４−３）は、本明細書で用いる用語の説明を提示する。

開示する主題は、他のサービス層に適用可能である場合があることに留意されたい。加えて、本開示は、ユーザの要件／制約を特定するために、例示的言語としてＳＰＡＲＱＬを使用する。しかし、開示する主題は、ユーザの要件または制約がＳＰＡＲＱＬ以外の異なる言語を使用して記述される他のケースにも適用することができる。本明細書にて開示するような「ユーザ」は、サーバまたはモバイルデバイスなどの別のデバイスであってもよい。

本明細書に添付の特許請求の範囲の適用範囲、解釈または応用はいかなる形であれ、過度に制限することなく、本明細書にて開示する例の１つまたは複数の技術的効果は、セマンティック推論サポート操作の調整を提供することである。概して、サービス層での推論操作をトリガする方法を提供するシステム、方法または装置を本明細書にて開示する。セマンティック操作（例えば、セマンティックリソース発見またはセマンティック問い合わせ）の処理の間に、セマンティック操作（セマンティックリソース発見またはセマンティック問い合わせ）がトリガされると、セマンティック推論は、ユーザデバイスの認識なしに（例えば、ＡＥまたはＣＳＥなどのユーザデバイスに知らせることなく）、バックグラウンドサポートとして活用することができる（図１５参照）。言い換えると、所定の受信側（例えば、ＣＳＥ）に関して、セマンティック操作（セマティック発見問い合わせなど）に対するクライアントからの要求を受信するときに、その受信側はそれらの要求を処理することができる。特に、処理の間に、受信側は、（例えば、より精度が高い発見結果のために）処理を最適化するためにセマンティック推論能力をさらに活用する場合がある。

図３５は、図６のｏｎｅＭ２Ｍモデルを示す。それにより、ｏｎｅＭ２Ｍの新しいセマンティック推論機能（ＳＲＦ）が定義されることが分かる。また、下記はＳＲＦの主な特性およびＳＲＦがサポートする可能性のある異なるタイプの機能性の詳細な説明である。図３６は、図３５の代替策を示す。図３６は、図３５の代替図である。（＜ｆａｃｔｓ＞＜ｒｕｌｅｓ＞がリソースであるのに対し、ＳＲＦは機能であるので）＜ｆａｃｔｓ＞リソースおよび＜ｒｕｌｅｓ＞リソースはＳＲＦのボックスの外にある。

特性１：セマンティック推論関連データの有効化について以下で論じる。特性１の機能性は、ｏｎｅＭ２Ｍシステム内の異なるエンティティにわたって、それらのデータを（図３５の、矢印３８１で示されている）発見可能、発行可能（例えば、共有可能）にさせることによって、セマンティック推論関連データ（事実および推論規則を指す）を使用可能にすることができる。セマンティック推論関連データは、事実セット（ＦＳ）または規則セット（ＲＳ）である場合がある。ＦＳは、事実のセットを指す。例えば、各ＲＤＦトリプルは事実を記述できるので、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースに格納されているＲＤＦトリプルのセットは、ＦＳとして見なされる。概して、ＦＳは、セマンティック推論処理の入力（例えば、ｉｎｐｕｔＦＳ）として使用される場合があるか、またはセマンティック推論処理の結果としての推測事実のセット（例えば、ｉｎｆｅｒｒｅｄＦＳ）である場合がある。ＲＳは、セマンティック推論規則のセットを指す。

特定のセマンティック推論処理Ａを実行するために、１）入力ＦＳ（ｉｎｐｕｔＦＳと表される）および、２）ＲＳの２つのタイプのデータ入力が使用されてよい。

セマンティック推論処理Ａの出力は、推論処理Ａのセマンティック推論結果である推測ＦＳ（ｉｎｆｅｒｒｅｄＦＳと表される）を含む場合がある。

推論処理Ａによって生成されたｉｎｆｅｒｒｅｄＦＳは、次の別のセマンティック推論処理ＢでｉｎｐｕｔＦＳとしてさらに使用される場合がある。したがって、下記の記載では、基本的に用語ＦＳが適切な場合に使用される。

事実は、通常のｏｎｅＭ２Ｍリソースのセマンティックアノテーション（例えば＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースに格納されるＲＤＦトリプル）に限られない。事実は、ｏｎｅＭ２Ｍシステムで利用できるようにされ、かつ他のものによってアクセスされる場合がある任意の有用な情報または知識を指す場合がある。例えば、ｏｎｅＭ２Ｍ＜ｏｎｔｏｌｏｇｙ＞リソースに格納されるオントロジーディスクリプションが、ＦＳである場合がある。別のケースでは、ＦＳはまた、情報の個別の部分（先の図５のユースケースで論じた、ＲＤＦトリプルで記述する病室割り当て記録など）であり、このようなＦＳは、オントロジーを記述しないか、または別のリソースのセマンティックアノテーションを記述しない場合がある（例えば、ＦＳ記述の病室割り当て記録は、個別に存在する場合があり、また必ずしも他のリソースのセマンティックアノテーションというわけではない）。

ＲＳに関して、ｏｎｅＭ２Ｍシステムは、異なるドメインにわたるアプリケーションを可能にするホリゾンタルなプラットフォームとなるように設計されるので、種々のアプリケーションをサポートするために、ユーザは多くのカスタマイズされた（またはユーザ定義の）セマンティック推論規則を設計する必要がある。したがって、種々のユーザ定義ＲＳが、ｏｎｅＭ２Ｍシステムで利用できるようにされる場合があるが、他のものによってアクセスまたは共有はされない。多くの場合、オントロジー定義を修正する必要がない（例えば、オントロジー内の２つのクラス間で新しいまたは一時的な関係を定義する）ユーザ定義推論規則だけがローカルでまたは一時的に使用される場合があるので、このようなユーザ定義セマンティック推論規則は、柔軟にシステムを向上させることができることに留意されたい。

全体的に、特性１は、適切なｏｎｅＭ２Ｍリソースを通して、セマンティック推論関連データ（ＦＳおよびＲＳの両方を含む）の発行、発見または共有を可能にすることを含む。特性１の基本的な流れは、対応するＣＲＵＤ操作を通してＦＳ関連リソースまたはＲＳ関連リソースを発行、発見、更新、削除するために、（発信元のような）ｏｎｅＭ２Ｍユーザが、一定の受信側ＣＳＥに要求を送信する場合があるといったものである。一旦、処理が完了すると、受信側ＣＳＥは、発信元に応答を送信することができる。

特性２に関して、バックグラウンドセマンティック推論サポートを伴う他のセマンティック操作最適化について、下記に開示する。特性１に関連して先のセクションで提示したように、ｏｎｅＭ２Ｍシステムでサポートされている既存のセマンティック操作（例えば、セマンティックリソース発見およびセマンティック問い合わせ）は、セマンティック推論サポートなしでは、所望の結果を得ることができない場合がある。ＳＲＦの特性２の機能は、他のセマンティック操作（図３５の矢印３８２によって示されている）を最適化するために、セマンティック推論を「バックグラウンドサポート」として活用することである。この場合、ユーザが、特定のセマンティック操作（例えば、セマンティック問い合わせ）をトリガまたは開始する。この操作の処理の間に、さらに、セマンティック推論がバックグラウンドでトリガされる場合があるが、これは、ユーザによって完全に透過的なものである。例えば、ユーザは、ＳＰＡＲＱＬ問い合わせを、ＳＰＡＲＱＬ問い合わせエンジンに送ることによってセマンティック問い合わせを開始する場合がある。関係するＲＤＦトリプル（ＦＳ−１と表される）は、ＳＰＡＲＱＬ問い合わせに直接答えることができない可能性がある。それに応じて、ＳＰＡＲＱＬエンジンはさらに、ＳＲにセマンティック推論処理を行うことを求める場合がある。（ｉｎｐｕｔＦＳのような）ＦＳ−１が充分でない場合、例えば、ＳＲは、一定のアクセス権に基づいて、適切な（ＲＳのような）推論規則セットおよび任意の追加のＦＳを決定および選択する。最後に、ｉｎｆｅｒｒｅｄＦＳで表されるセマンティック推論結果は、ＳＰＡＲＱＬエンジンに配信され、これは、ユーザのＳＰＡＲＱＬ問い合わせステートメントに回答／整合するためにさらに使用される場合があるものである。

図５に示されるユースケースを再度用いて、以下に２つの例を説明するが、これらはｏｎｅＭ２Ｍシステム内のそれら２つの例で示される問題をＳＲＦがどう解決できるかを説明するものである。対象の＜Ｃａｍｅｒａ−１１＞リソースは、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞リソースをその子リソースとして加えることによって、いくつかのメタデータでアノテートされる。特に、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞子リソースは、（既存の事実として）２つのＲＤＦトリプルを格納する。
・ＲＤＦトリプル番号１（例えば、事実ａ）：Camera-11 is-a ontologyA:VideoCamera（ここで、「ＶｉｄｅｏＣａｍｅｒａ」は、オントロジーＡによって定義されるクラスである。）
・ＲＦＣトリプル番号２（例えば、事実ｂ）：Camera-11 is-located-in Room-109-of-Building-1

例１：ユーザが、全ての部屋からリアルタイムの画像を読み出す必要がある場合を考察する。そのことを行うために、ユーザは、まず、下記のＳＰＡＲＱＬステートメントＩを使用して、カメラを識別するために、セマンティックリソース発見を最初に実施する必要がある。
SELECT ?device
WHERE ｛
?device is-a ontologyB:VideoRecorder
｝

実際には、＜Ｃａｍｅｒａ−１１＞のセマンティックアノテーションおよびＳＰＡＲＱＬステートメントＩは、異なるグループによって提供される場合があるので、それらは異なるオントロジーを使用する場合がある可能性が非常に高い。例えば、＜Ｃａｍｅｒａ−１１＞のセマンティックアノテーションに関して、事実ａで使用されるオントロジークラス「ＶｉｄｅｏＣａｍｅｒａ」はオントロジーＡからのものである。それに対して、ＳＰＡＲＱＬステートメントＩで使用されるオントロジークラス「ＶｉｄｅｏＲｅｃｏｒｄｅｒ」は、別の異なるオントロジーＢからのものである。セマンティック推論能力が存在しないので、システムは、ontologyA:VideoCameraが、ontologyB:VideoRecorderと実は同じであるということを理解することができない。結果として、ＳＰＡＲＱＬ処理は、正確なパターン整合に基づいている（しかし、この例では、事実ａは、ＳＰＡＲＱＬステートメントＩのパターン「?device is-a ontologyB:VideoRecorder」と一致しない場合がある）ので、＜Ｃａｍｅｒａ−１１＞リソースは、セマンティックリソース発見処理の間に、所望のリソースとして識別されない場合がある。

例２：ユーザが、「特定の管理ゾーン（例えば、ＭＺ−１）に属する」部屋からのリアルタイムの画像を読み出すことだけを望んでいるような、より複雑なケースが、この例では示される。その場合、ユーザは、まず、下記のＳＰＡＲＱＬステートメントＩＩを使用してセマンティックリソース発見を実施してもよい。
SELECT ?device
WHERE ｛
?device is-a ontologyA:VideoCamera
?device monitors-room-in MZ-1
｝

（例１と類似の）例２では、セマンティック推論サポートがないために、＜Ｃａｍｅｒａ−１１＞リソースが、所望のリソースとして識別されない場合もある（この時点で、事実ａは、ＳＰＡＲＱＬステートメントＩＩ内のパターン「?device is-a ontologyA:VideoCamera」と一致するが、事実ｂは、パターン「?device monitors-room-in MZ-1」とは一致しない場合がある）。

例２はまた、推論処理に対して、事実入力が充分でないために起こる、クリティカルなセマンティック推論問題も例示する。例えば、セマンティック推論が可能であると考えられる場合であっても、下記の推論規則（例えば、ＲＲ−１）が利用される場合がある。
・ＲＲ−１： IF X is-located-in Y && Y is-managed-under Z, THEN X monitors-room-in Z

しかし、セマンティック推論処理を通して、ＲＲ−１を事実Ｙに適用しても、推測事実は導き出すことはできない。これは、事実ｂが、ＲＲ−１の「X is-located-in Y」の部分とだけ一致する場合があることが理由である（例えば、Ｘを＜Ｃａｍｅｒａ−１１＞に置き換えて、Ｙを「Room-109-of-Building-1」に置き換える）。しかし、事実ａおよび事実ｂに加えて、ＲＲ−１の「Y is-managed-under Z」の部分と一致させるために利用することができる別の事実がない（ＲＲ−１を使用するために充分な事実がない）。実際に、ここで欠落している事実は、病室割り当てについてである。病室割り当て記録は、どの部屋がどのＭＺに属するかを定義するＲＤＦトリプルのセットである場合があり、例えば、下記のＲＤＦトリプルは、建物１の部屋１０９がＭＺ−１に属することを記述している。
事実ｃ：Room-109-of-Building-1 is-managed-under MZ-1
…
事実ｃを用いなければ、推論処理の入力として充分な事実がないために、この例では依然としてセマンティック推論は助力することができない。

特性２を活用することによって、ここで、ＳＲＦは例１に示した問題を解決することができる。例えば、推論規則（Reasoning Rule：ＲＲ−２）は、下記のように定義することができる。
ＲＲ−２：IF X is an instance of ontologyA:VideoCamera, THEN X is also an instance of ontologyB:VideoRecorder.

ここで、Ｘは変数であり、推論処理の間に特定のインスタンス（例えば、例１の＜Ｃａｍｅｒａ−１１＞）によって置き換えられる。ＳＰＡＲＱＬエンジンがＳＰＡＲＱＬステートメントＩを処理するときに、ＳＰＡＲＱＬエンジンは、さらに、（ＲＳのような）ＲＲ−２を（ｉｎｐｕｔＦＳのような）事実ａに適用するセマンティック推論器（ＳＲ）でのセマンティック推論処理をトリガする場合がある。下記の新しい事実を含む、ｉｎｆｅｒｒｅｄＦＳを生成することができる。
推測事実ａ：Camera-11 is-a ontologyB:VideoRecorder

ここで、ＳＰＡＲＱＬエンジンは、推測事実ａを使用してＳＰＡＲＱＬステートメントＩのパターン「?device is-a ontologyB:VideoRecorder」と一致させることができる。その結果、ＳＲＦの助力を用いて、ここで、セマンティックリソース発見の間に、＜Ｃａｍｅｒａ−１１＞リソースは、所望のリソースとして識別されることが可能になる。

ＳＲＦの特性２はまた、例２に示したような問題を解決することもできる。例えば、ＳＰＡＲＱＬエンジンがＳＰＡＲＱＬステートメントＩＩを処理するときに、ＳＰＡＲＱＬエンジンは、さらに、ＳＲでのセマンティック推論処理をトリガする場合がある。特に、ＳＲは、（ＲＳのような）ＲＲ−１が活用される必要があるかどうかを決定する。一方、ＲＲ−１を正常に適用するために、既存の事実ｂが充分ではなく、追加の事実ｃ（例えば、事実ｃは、「建物１の部屋１０９は、ＭＺ−１に属すると」定義する病室割り当て記録である）も推論処理の入力として使用される必要があるというように、ＳＲのローカルポリシーを設定することもできる。この場合、ｉｎｐｕｔＦＳは、さらに２つの部分、すなわち、ｉｎｉｔｉａｌ＿ＩｎｐｕｔＦＳ（例えば、事実ｂ）と、ａｄｄｉｔｉｏｎａｌ＿ＩｎｐｕｔＦＳ（例えば、事実ｃ）とに分類される。その結果、ＲＲ−１を「組み合わされたｉｎｐｕｔＦＳ」（例えば、事実ｂおよび事実ｃ）に適用することによって、下記の新しい事実を含むｉｎｆｅｒｒｅｄＦＳを生成することができる。
推測事実ｂ：Camera-11 monitors-room-in MZ-1

ここで、ＳＰＡＲＱＬエンジンは、さらに、推測事実ｃを使用して、ＳＰＡＲＱＬステートメントＩＩの問い合わせパターン「?device monitors-room-in MZ-1」と一致させることができる。その結果、ここで、＜Ｃａｍｅｒａ−１１＞は例２のセマンティックリソース発見操作で正常に識別され得る。

全体的に、特性２の基本的な流れは、所望のセマンティック操作（例えば、セマンティックリソース発見、セマンティック問い合わせなど）のために、（発信元のような）ｏｎｅＭ２Ｍユーザが、一定の受信側ＣＳＥに要求を送信する場合があるといったものである。要求処理の間に、受信側ＣＳＥは、推論能力をさらに活用することができる。推論結果を使用することによって、受信側ＣＳＥは、さらに、発信元によって要求されたセマンティック操作に対する最終結果（例えば、セマンティック問い合わせ結果またはセマンティック発見結果）を生成し、次いで、発信元に応答を返す。

特性３：個別のセマンティック推論処理の有効化について、以下に開示する。特性２によってサポートされるユースケースに加えて、（図３５の矢印３８３で示されている）セマンティック推論処理が、ｏｎｅＭ２Ｍユーザによって個別にトリガされてよい。言い換えると、セマンティック推論処理は、必ずしも特性２で考慮される他のセマンティック操作と組み合わされる必要はない。特性３を用いて、ｏｎｅＭ２Ｍユーザは、セマンティック推論処理をトリガすることによって、ＳＲＦと直接相互作用する場合がある。そのことを行うために、ｏｎｅＭ２Ｍユーザは、まず、（ｉｎｉｔｉａｌ＿ｉｎｐｕｔＦＳのような）関心のある事実、および、それらのアプリケーションの必要性に基づく所望の（ＲＳのような）推論規則を識別する。ｉｎｐｕｔＦＳおよびＲＳが識別されるときに、ｏｎｅＭ２Ｍユーザは、推論入力（例えば、識別されたｉｎｉｔｉａｌ＿ｉｎｐｕｔＦＳおよびＲＳ）を指定することによって、特定のセマンティック推論処理をトリガするために、ＳＲに要求を送信する。ＳＲは、ユーザによって示された入力に基づいて、セマンティック推論処理を開始する場合がある。特性２に類似して、ユーザからの入力が充分でない場合、ＳＲは活用される必要がある追加のＦＳまたはＲＳを決定する場合もある。一旦、ＳＲがセマンティック推論結果を導き出すと、その推論結果はそれを必要としているｏｎｅＭ２Ｍユーザに戻される。概して、下記のケースが、特性３によってサポートされる場合がある。

第１のケース（ケース１）では、ｏｎｅＭ２Ｍユーザは、ＳＲＦを使用して、低水準データにセマンティック推論を行って、高水準知識を得ることができる。例えば、ある会社が、顧客に健康監視製品を販売しており、かつこの製品が実際に、セマンティック推論能力を活用する。この製品では、部品の１つが、（ｏｎｅＭ２Ｍユーザとして動作する）健康監視アプリケーションである。このアプリケーションは、心臓発作診断／予測推論規則を使用して、特定の患者Ａから収集したリアルタイムのバイタルデータ（例えば、血圧、心拍など）に対してセマンティック推論処理を実施することをＳＲＦに要請する。この処理では、心臓発作診断／予測推論規則は、患者Ａ自身の健康プロファイルおよびその患者の過去の心臓発作病歴に基づいて高度にカスタマイズすることができるユーザ定義規則である。このようにして、健康監視アプリケーションは、低水準バイタルデータ（例えば、血圧、心拍など）に対処する必要がなく、（全ての診断／予測業務論理が、ＳＲＦによって使用される推論規則で既に定義されているので）患者Ａの心臓発作リスクの判断から遠ざかることができる。その結果、健康監視アプリケーションは、推論結果（例えば、「すぐに利用可能な」または「高水準の」知識である患者Ａの現在の心臓発作リスク）を活用して、必要であれば、医師に警告を送信するか、または救急車用の９１１に電話をすることだけを必要とする。

第２のケース（ケース２）では、ｏｎｅＭ２Ｍユーザは、ＳＲＦを使用して、既存のデータを拡張するセマンティック推論を行うことができる。例として例１を再度用いて、ｏｎｅＭ２Ｍユーザ（例えば、カメラ１１の所有者）は、特性３およびＲＲ−２を使用して、＜Ｃａｍｅｒａ−１１＞のセマンティックアノテーション（例えば、既存の事実である事実ａおよび事実ｂ）に対してセマンティック推論処理を能動的にトリガする場合がある。セマンティック推論結果（例えば、推測事実ａ）はまた、＜Ｃａｍｅｒａ−１１＞についての低水準セマンティックメタデータであり、かつ長期間有効な事実である。したがって、このような新しい／推測された事実は、さらに、＜Ｃａｍｅｒａ−１１＞のセマンティックアノテーションに追加／統合される場合がある。言い換えると、既存の事実は、ここで、推測事実によって「拡張または強化される」。その結果、＜Ｃａｍｅｒａ−１１＞は、次のセマンティックリソース発見操作によってより多く発見される機会を得ることができる。このような拡張による別の利点は、次のセマンティックリソース発見操作が、特性２によってサポートされて、毎回バックグラウンドでセマンティック推論をさらにトリガする必要がなく、これにより、処理オーバーヘッドおよび応答遅延を減らすことを助力することである。しかし、全てのユースケースにおいて、推測事実を既存の事実と統合することが適用できるわけではないことは、注目に値する。例として例２を用いて、推測事実ｂ（例えば、「Camera-11 monitors-room-in MZ-1」）は、比較的高水準の知識であり、これは、低水準セマンティックメタデータ（例えば、事実ａおよび事実ｂ）と統合するのには適切でない場合もある。一方、病室割り当てが、時々再構成される場合があるので、推測事実ｂは、短期間だけ有効な事実である場合がある。例えば、現在の部屋再割り当ての後に、カメラ１１は建物１の部屋１０９に依然として設置されている（例えば、事実ａおよび事実ｂは依然として有効である）ものの、カメラ１１はＭＺ−１に属する部屋を監視せず、また現在、この部屋は別の目的に使用されていて、異なるＭＺに属している（例えば、推測事実ｂは、もはやそれ以上有効ではなく、削除される必要がある）。そのため、このようなタイプの推測事実または知識を大量のカメラのセマンティックアノテーションに直接統合する意味がなく、さもなければ、場合によっては、オーバーヘッドを更新する考慮すべきアノテーションとなる可能性がある。特性２および特性３の両方はＳＲＦの必要な特性であり、各々がそれぞれ、異なるユーザケースをサポートすることが分かるであろう。

全体的に、特性３の基本的な流れは、（発信元のような）ｏｎｅＭ２Ｍユーザが、推論能力を有する一定の受信側（ＣＳＥ）に要求を送信する場合があるといったものである。したがって、受信側ＣＳＥは、所望の入力（例えば、ｉｎｐｕｔＦＳおよびＲＳ）を使用して推論処理を行って推論結果を生成して、最終的に発信元に応答を送信する。

本開示に関連する追加の考察が、本明細書にて開示される。多くの概念、用語、名称が、同等の名称を有する場合がある。このため、例示的リストを表４５に示す。

図３７Ａは、セマンティクス推論サポート操作を可能にすることに関連する１つまたは複数の開示される構想（例えば、図７から図１５および付随する説明）が実装される場合がある、マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の例の図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴに構築ブロックを提供し、かつ任意のＭ２Ｍデバイス、Ｍ２ＭゲートウェイまたはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネント、ならびにＩｏＴ／ＷｏＴサービス層である場合がある。

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

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

図３７Ｂを参照すると、フィールドドメイン内の図示されているＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２にサービスを提供する。Ｍ２Ｍサービス層２２は、所望により、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信できることが理解されよう。Ｍ２Ｍサービス層２２は、１つまたは複数のサーバ、コンピュータなどによって実装される場合がある。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍアプリケーション２０に適用するサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで、などさまざまな方法で実装されてよい。

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

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

一部の例では、Ｍ２Ｍアプリケーション２０および２０’は、本明細書にて開示するようなセマンティクス推論サポート操作を使用して通信する所望のアプリケーションを含む場合がある。Ｍ２Ｍアプリケーション２０および２０’は、限定されるものではないが輸送、保健および健康、コネクテッドホーム、エネルギー管理、資産追跡、ならびにセキュリティおよび監視などの種々の業界でのアプリケーションを含む場合がある。前述のように、デバイス、ゲートウェイ、およびシステムの他のサーバを動作させるＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、位置追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合などの機能をサポートし、かつサービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

本出願のセマンティクス推論サポート操作は、サービス層の一部として実装することができる。サービス層は、アプリケーションプログラミングインターフェース（Application Programming Interfaces：ＡＰＩ）と下位ネットワークインターフェースとのセットを介して付加価値サービス能力をサポートするミドルウェア層である。Ｍ２Ｍエンティティ（例えば、ハードウェアに実装されるデバイス、ゲートウェイ、またはサービス／プラットフォームなどのＭ２Ｍ機能エンティティ）は、アプリケーションまたはサービスを提供する場合がある。ＥＴＳＩＭ２ＭおよびｏｎｅＭ２Ｍの両方は、本出願のセマンティクス推論サポート操作を含むことができるサービス層を使用する。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（例えば、サービス能力）のセットをサポートする。１つまたは複数の特定のタイプのＣＳＦのセットのインスタンス化は、種々のタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、アプリケーション固有ノード）でホストされる場合がある共通サービスエンティティ（ＣＳＥ）のことを指す。さらに、本願のセマンティクス推論サポート操作は、本願のセマンティクス推論サポート操作などのサービスにアクセスするサービス指向アーキテクチャ（Service Oriented Architecture：ＳＯＡ）またはリソース指向アーキテクチャ（Resource-Oriented Architecture：ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装されてよい。

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

図３７Ｃは、Ｍ２Ｍ端末デバイス１８（ＡＥ３３１を含む場合がある）またはＭ２Ｍゲートウェイデバイス１４（図１３から図１５の１つまたは複数のコンポーネントを含む場合がある）などのＭ２Ｍデバイス３０の例のシステム図である。図３７Ｃに示すように、Ｍ２Ｍデバイス３０は、プロセッサ３２、送受信機３４、伝送／受信要素３６、スピーカ／マイクロホン３８、キーパッド４０、ディスプレイ／タッチパッド４２、非取り外し可能メモリ４４、取り外し可能メモリ４６、電源４８、全地球測位システム（Global Positioning System：ＧＰＳ）チップセット５０、および他の周辺機器５２を備える場合がある。Ｍ２Ｍデバイス３０は、開示される主題と一致したままで、上述の要素の任意の副次的組み合わせを含んでもよいことを理解されたい。Ｍ２Ｍデバイス３０（例えば、ＣＳＥ３３２、ＡＥ３３１、ＣＳＥ３３３、ＣＳＥ３３４、ＣＳＥ３３５、その他）は、セマンティクス推論サポート操作の開示されるシステムおよび方法を実施する例示的実装形態であってよい。

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（Digital Signal Processor：ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuits：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array：ＦＰＧＡ）回路、任意の他のタイプの集積回路（Integrated Circuits：ＩＣ）、状態マシンなどであってよい。プロセッサ３２は、信号コーディング、データ処理、電力制御、入力／出力処理、またはＭ２Ｍデバイス３０が無線環境で動作することを可能にする任意の他の機能性を実施してもよい。プロセッサ３２は、伝送／受信要素３６に連結されることがある、送受信機３４に連結されてもよい。図３７Ｃでは、別個のコンポーネントとしてプロセッサ３２と送受信機３４とを示しているが、プロセッサ３２と送受信機３４とが、電子パッケージまたはチップ内に一緒に統合されてもよいことを理解されよう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）または無線アクセス層（Radio Access-Layer：ＲＡＮ）プログラムまたは通信を実施してもよい。プロセッサ３２は、例えば、アクセス層またはアプリケーション層などで、認証、セキュリティキー一致または暗号化動作などのセキュリティ動作を実施してよい。

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４または取り外し可能メモリ４６などの任意のタイプの好適なメモリからの情報にアクセスし、かつそこにデータを記憶してもよい。非取り外し可能メモリ４４としては、ランダムアクセスメモリ（Random-Access Memory：ＲＡＭ）、読み取り専用メモリ（Read-Only Memory：ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを挙げてもよい。取り外し可能メモリ４６としては、加入者識別モジュール（Subscriber Identity Module：ＳＩＭ）カード、メモリスティック、セキュアデジタル（Secure Digital：ＳＤ）メモリカードなどを挙げてもよい。別の例では、プロセッサ３２は、サーバまたはホームコンピュータなどのＭ２Ｍデバイス３０上に物理的に位置しないメモリからの情報にアクセスし、かつそこにデータを記憶してもよい。プロセッサ３２は、本明細書に記載される例の一部でのセマンティクス推論サポート操作（例えば、セマンティック推論リソースを取得するなど）が、成功したか、失敗したかに応じて、ディスプレイまたはインジケータ４２の点灯パターン、画像、または色を制御するように、または、セマンティクス推論サポート操作および関連するコンポーネントの状態を示すように構成されてよい。ディスプレイまたはインジケータ４２の点灯パターン、画像または色の制御は、本明細書で示すまたは論じる各図（例えば、図６から図３６など）の方法のフローまたはコンポーネントのいずれかの状態が反映される場合がある。セマンティクス推論サポート操作のメッセージおよびプロシージャが、本明細書にて開示される。ユーザが入力ソース（例えば、スピーカ／マイクロホン３８、キーパッド４０、またはディスプレイ／タッチパッド４２）を介してサービス層関連情報を要求するためのインターフェース／ＡＰＩを提供するために、メッセージおよびプロシージャは、拡張されてよい。追加の例では、特に、ディスプレイ４２で表示される場合がある、セマンティクス推論サポートの要求、構成、または問い合わせが挙げられる。

プロセッサ３２は、電源４８から電力を得てもよく、Ｍ２Ｍデバイス３０内のその他のコンポーネントへの電力を分配または制御するように構成されてよい。電源４８は、Ｍ２Ｍデバイス３０に給電するための任意の好適なデバイスであってよい。例えば、電源４８としては、１つまたは複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを挙げてもよい。

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

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

伝送／受信要素３６は、センサ、大衆消費電子製品、スマートウォッチまたはスマート衣類などのウェアラブルデバイス、医療またはｅ健康デバイス、ロボット、産業機器、ドローン、車、トラック、電車または飛行機などの乗物などの他の装置もしくはデバイス内で具現化されてもよい。伝送／受信要素３６は、周辺機器５２のうちの１つを含むことがある相互接続インターフェースなどの１つまたは複数の相互接続インターフェースを介して、そのような装置またはデバイスの他のコンポーネント、モジュール、またはシステムに接続してもよい。

図３７Ｄは、例えば、図３７Ａおよび図３７ＢのＭ２Ｍサービスプラットフォーム２２が実装される場合がある例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０（例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４）は、コンピュータまたはサーバを含んでもよく、主に、コンピュータ可読命令によって、かかる命令が記憶されるまたはアクセスされる手段が何であっても制御される場合がある。かかるコンピュータ可読命令は、コンピューティングシステム９０を稼働させるように中央演算処理装置（Central Processing Unit：ＣＰＵ）９１内で実行されてよい。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央演算処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央演算処理装置９１は、複数のプロセッサを含むことがある。コプロセッサ８１は、主要ＣＰＵ９１とは異なる、追加の機能を実施するか、またはＣＰＵ９１を支援する任意選択のプロセッサである。ＣＰＵ９１またはコプロセッサ８１は、セマンティック推論リソースを取得するなどの、セマンティクス推論サポート操作向けの開示のシステムおよび方法に関連するデータを受信、生成、および処理する場合がある。

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

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

加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５などの周辺機器に命令を伝達する役割を担う、周辺機器コントローラ８３を含んでもよい。

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

さらに、コンピューティングシステム９０は、コンピューティングシステム９０を、図３７Ａおよび図３７Ｂのネットワーク１２などの外部通信ネットワークに接続するために使用されることがあるネットワークアダプタ９７を含んでもよい。

本明細書に記載されるシステム、方法およびプロセスのいずれかまたは全ては、コンピュータ可読記憶媒体に記憶されるコンピュータ実行可能命令（例えば、プログラムコード）の形態で具現化される場合があり、この命令は、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイスなどのマシンによって実行されると、本明細書に記載されるシステム、方法、およびプロセスを実施または実装するものであることが理解される。具体的には、前述のいずれのステップ、操作、または機能も、このようなコンピュータ実行可能命令の形態で実装される場合がある。コンピュータ可読記憶媒体は、情報を記憶するための任意の方法もしくは技術で実装される揮発性および不揮発性媒体、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ可読記憶媒体は本質的に信号を含まない。本明細書の記載から明らかなように、記憶媒体は、法的な主題であるものとして解釈されるべきである。コンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（Digital Versatile Disks：ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用され、かつコンピュータによってアクセスされることがある任意の他の物理的媒体を含む。コンピュータ可読記憶媒体は、コンピュータプログラムを有する場合があり、該コンピュータプログラムは、データ処理ユニットにロード可能なものであり、かつ、コンピュータプログラムのセマンティクス推論サポート操作がデータ処理ユニットによって実行されると、そのデータ処理ユニットに方法ステップを実行させるように適応されるものである場合がある。

各図に示すような、セマンティクス推論サポート操作を可能にする、本開示の主題の好ましい方法、システムまたは装置を説明する際に、明確にする目的で特定の用語が用いられる。しかし、請求される主題は、そのような選択された特定の用語に限定されることを意図するものではなく、また各特定の要素は、類似の目的を達成するために類似の方式で動作する全ての技術的等価物を含むことを理解されたい。

本明細書に記載されている種々の技術は、ハードウェア、ファームウェア、ソフトウェア、または適切な場合は、これらの組み合わせと連携して実装されてもよい。このようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードで配置される装置に常駐してもよい。本明細書に記載の方法を実施するために、装置は単独でまたは互いに連携して動作してもよい。本明細書で用いられる用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、「ネットワークノード」、などは、同じ意味で用いられる場合がある。加えて、単語「または」は、別段の定めがある場合を除き包括的に本明細書で全般的に使用される。

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

本明細書に記載される、方法、システムおよび装置は、特に、推論サポートを用いるサービス層セマンティクスを提供または管理するための方法を提供することができる。方法、システム、コンピュータ可読記憶媒体または装置は、セマンティック推論要求、ならびに第１事実セットについての情報および第１規則セットについての情報を含むメッセージを取得する方法を有し、そのメッセージに基づいて第１事実セットおよび第１規則セットを読み出し、その第１事実セットおよび第１規則セットに基づいて推測事実を推測し、かつ次のセマンティック操作のために、推測事実セットを装置に格納させる命令を出す。第１事実セットについての情報は、第１事実セットに対するユニフォームリソース識別子を含む場合がある。第１事実セットについての情報は、第１事実セットに関連付けられたオントロジーを含む場合がある。第２事実セットまたは第２規則セットを使用するかどうかを決定することは、第１規則セットに関連付けられたオントロジーと一致する第１事実セットについての情報にさらに基づく場合がある。第２事実セットまたは第２規則セットを使用するかどうかを決定することは、装置の構成テーブル内のキーワードと一致する第１事実セットについての情報にさらに基づく場合がある。操作は、第１事実セットおよび第１規則セットに基づく推測事実を推測することをさらに含む場合がある。次のセマンティック操作は、セマンティックリソース発見を含む場合がある。次のセマンティック操作は、セマンティック問い合わせを含む場合がある。装置は、セマンティック推論器（例えば、共通サービスエンティティ）である場合がある。この段落の全ての組み合わせ（ステップの省略または追加を含む）は、発明を実施するための形態の他の部分と一致する手段で考えられるものである。

Claims

サービス層におけるセマンティクス推論向けの装置であって、
プロセッサと、
前記プロセッサに連結されたメモリであって、前記プロセッサによって実行されると、前記プロセッサに、
セマンティック推論要求、ならびに第１事実セットについての情報および第１規則セットについての情報を含むメッセージを取得することと、
前記メッセージに基づいて、前記第１事実セットおよび前記第１規則セットを読み出すことと、
前記第１事実セットおよび前記第１規則セットに基づいて、推測事実を推測することと、
次のセマンティック操作のために、前記推測事実セットを前記装置に格納させる命令を出すことと、
を含む操作を実行させる実行可能命令がそれに記憶されているメモリと、
を備える装置。
前記第１事実セットについての情報は、前記第１事実セットへのユニフォームリソース識別子を含む、請求項１に記載の装置。
前記第１事実セットについての情報は、前記第１事実セットに関連付けられたオントロジーを含む、請求項１に記載の装置。
前記操作は、前記読み出された第１事実セットおよび前記第１規則セットに基づいて、第２事実セットまたは第２規則セットを使用するかどうかを決定することをさらに含む、請求項１に記載の装置。
前記操作は、前記第１規則セットに関連付けられたオントロジーと一致する前記第１事実セットについての情報に基づいて、第２事実セットまたは第２規則セットを使用するかどうかを決定することをさらに含む、請求項１に記載の装置。
前記操作は、前記装置の構成テーブル内のキーワードと一致する前記第１事実セットについての情報に基づいて、第２事実セットまたは第２規則セットを使用するかどうかを決定することをさらに含む、請求項１に記載の装置。
前記次のセマンティック操作は、セマンティックリソース発見を含む、請求項１に記載の装置。
前記次のセマンティック操作は、セマンティック問い合わせを含む、請求項１に記載の装置。
前記装置はセマンティック推論器である、請求項１に記載の装置。
サービス層におけるセマンティック推論の方法であって、
共通サービスエンティティによって、セマンティック推論要求、ならびに第１事実セットについての情報および第１規則セットについての情報を含むメッセージを取得することと、
前記メッセージに基づいて、前記第１事実セットおよび前記第１規則セットを読み出すことと、
前記第１事実セットおよび前記第１規則セットに基づいて、推測事実を推測することと、
次のセマンティック操作のために、前記推測事実セットを前記共通サービスエンティティに格納させる命令を出すことと、
を含む方法。
前記第１事実セットについての情報は、前記第１事実セットに関連付けられたオントロジーを含む、請求項１０に記載の方法。
前記読み出された第１事実セットおよび前記第１規則セットに基づいて、第２事実セットまたは第２規則セットを使用するかどうかを決定することをさらに含む、請求項１０に記載の方法。
前記第１規則セットに関連付けられたオントロジーと一致する前記第１事実セットについての情報に基づいて、第２事実セットまたは第２規則セットを使用するかどうかを決定することをさらに含む、請求項１０に記載の方法。
前記共通サービスエンティティの構成テーブル内のキーワードと一致する前記第１事実セットについての情報に基づいて、第２事実セットまたは第２規則セットを使用するかどうかを決定することをさらに含む、請求項１０に記載の方法。
コンピュータプログラムがそれに記憶されているコンピュータ読み取り可能記憶媒体であって、前記コンピュータプログラムは、データ処理ユニットにロード可能であり、かつ前記データ処理ユニットによって実行されると、前記データ処理ユニットに請求項１１から１４のいずれか１項に記載の方法ステップを実行させるように適応されている、コンピュータ読み取り可能記憶媒体。