JP2006522388A - 意味論的知識の取得、管理、取り込み、共有、発見、伝達および提示用のシステムおよび方法 - Google Patents

意味論的知識の取得、管理、取り込み、共有、発見、伝達および提示用のシステムおよび方法 Download PDF

Info

Publication number
JP2006522388A
JP2006522388A JP2006503648A JP2006503648A JP2006522388A JP 2006522388 A JP2006522388 A JP 2006522388A JP 2006503648 A JP2006503648 A JP 2006503648A JP 2006503648 A JP2006503648 A JP 2006503648A JP 2006522388 A JP2006522388 A JP 2006522388A
Authority
JP
Japan
Prior art keywords
semantic
user
request
information
knowledge
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2006503648A
Other languages
English (en)
Inventor
オモイグイ、ノサ
Original Assignee
ナーバナ、インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ナーバナ、インコーポレイテッド filed Critical ナーバナ、インコーポレイテッド
Publication of JP2006522388A publication Critical patent/JP2006522388A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/40—Data acquisition and logging

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • User Interface Of Digital Computer (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

意味論的知識の取得、管理、取り込み、共有、発見、伝達および提示用のシステムおよび方法。本発明は、知識の取得、管理、取り込み、共有、発見、伝達および提示用に統合された実装の枠組み、及びその結果生じるメディアに関するものである。システムは意味論的情報を管理する役割を担う。

Description

発明者
オモイグイ・ノサ
優先権の主張
本出願は、米国仮出願番号第６０／３６０，６１０号（２００２年２月２８日出願)と米国仮出願番号第６０／３００，３８５号（２００１年６月２２日出願)より優先権を主張する米国特許出願通し番号 １０／１７９，６５１号（２００２年６月２４日出願）の継続出願である米国特許出願通し番号１０／７８１，０５３号（２００４年２月１７日出願)に対する優先権を主張する。本出願はまた、２００３年２月１４日出願の米国仮出願６０／４４７，７３６号より優先権を主張する。本出願はまた、２００２年６月２４日出願のＰＣＴ／ＵＳ０２／２０２４９に対する優先権も主張する。本出願はまた、２００４年２月１４日出願のＰＣＴ／ＵＳ２００４／００４３８０（弁護士参照番号ＮＥＲＶ−１１−１０１２）および同日付出願の米国特許出願通し番号１０／７７９，５３３（弁護士参照番号ＮＥＲＶ−１−１００５）に対する優先権を主張する。前記の全出願は、参照することによりその全体が以下に含まれる。
著作権表示
本開示は米国および国際著作権法により保護される。著作権２００２ − ２００４ オモイグイ・ノサ。著作権保留。本特許文書開示の一部には、著作権保護の対象となる内容が含まれる。著作権の所有者は、特許および商標庁の特許ファイルまたは記録に表示されるものを特許文書または特許開示を何者かがファックスにて複製することに異議はないが、それ以外の全著作権を保留するものとする。
発明の分野
本発明は、一般にコンピュータと、さらに詳しくは情報管理および研究システムに関する。
発明の背景
本発明の一般的背景は、参照することによりここに組み込まれる同時継続の特許出願（２００２年６月２４日出願の米国出願通し番号１０／１７９，６５１号）に説明されており、本出願はその一部継続特許である。
発明の概要
本発明は、意味論的に統合された知識の取得、管理、伝達および提示システムを部分的に対象としており、当発明者の同時継続特許出願（２００２年６月２４日出願の米国出願通し番号１０／１７９，６５１号）により詳しく説明されている。本発明とシステムにはいくつかの追加改良機能、強化および／または特性が含まれており、それにはエンティティ、プロフィールや意味論的スレッドが含まれるがそれに限定されることはなく、以下の「詳細な説明」でより詳しく説明する。
好ましい実施例の詳細な説明
目 次
A. 補足的説明のシナリオ
1. 特許審査官の先行技術検索ツール
2. バイオテック企業の研究シナリオ
B. インフォメーションナーバスシステムの現在の好ましい実施例の内容 1. スマート選択レンズの概要
2. 人物オブジェクトのペーストの概要
3. スマートリクエストの保存と共有の概要
4. スマートスナップショットの保存と共有の概要
5. 仮想知識コミュニティ
6. 時間に敏感な意味論的クエリの実行
7. 音声変換スキンの概要
8. 言語翻訳スキン
9. ユーザ経験でのファーストクラスのオブジェクトとしてのカテゴリ
10. 分類された注釈
11. 補助的文脈テンプレート
12. ユーザ状態のインポートとエクスポート
13. ローカルスマートリクエスト
14. 統合ナビゲーション
15. 探訪結果のヒント
16. 知識連合
17. 匿名の注釈および発行物
18. 意味論的ブラウザでのオフラインサポート
19. 意味論的ブラウザでの保証付きクロスプラットフォームサポート
20. 知識モデル化
21. ＫＩＳハウスキーピングの規則
22. クライアントのコンポーネント統合およびワークフローの相互作用
23. カテゴリ・ダイアログボックスのユーザインタフェース仕様
24. クライアント支援によるサーバデータの整合性チェック
25. クライアント側の重複検出
26. クライアント側の仮想結果カーソル
27. 仮想単一サインオン
28. ネームスペースオブジェクトのアクションマトリックス
29. 動的エンド−ツー−エンドオントロジー／分類化の更新および同期化
30. ドシェ（ガイド）クエリの呼出し
31. 知識コミュニティ（エージェンシー）の意味論
32. 動的オントロジーと分類法のマッピング
33. 意味論的警告の最適化
34. 意味論的「ニュース」画像
35. 意味論的画像の動的選択
36. 動的知識コミュニティ（エージェンシー）の連絡先メンバーシップ
37. 統合されたフルテキストのキーワードとフレーズのインデックシング
38. 意味論的な「オブジェクトを既読としてマークする」
39. マルチ選択のオブジェクトレンズ
40. オントロジーベースのフィルタリングおよびスパム管理
41. 結果の精度を高める
42. 情報格納の意味論的管理
43. 計算尺フィルタのユーザインタフェース
C. サーバ側の意味論的クエリプロセッサの仕様
1. 概要
2. 意味論的関連性の評点
3. 意味論的関連性フィルタ
4. 時間に敏感なフィルタ
5. 知識タイプの意味論的クエリの実装
D. インフォメーションナーバスシステム用の拡張可能なクライアント側のユーザプロフィール仕様
E. インフォメーションナーバスシステム用のスマートスタイルの仕様
1. スマートスタイルの概要
2. 潜在的で動的なスマートスタイル特性
F. インフォメーションナーバスシステム用のスマートリクエスト警戒の仕様
1. 概要
2. リクエスト警戒リスト（ＲＷＬ）およびリクエスト警戒グループ（ＲＷＧ）
3. 通知マネージャ（ＮＭ）
4. 警戒グループのモニター
5. 警戒ペイン
6. 警戒ウィンドウ
7. 警戒リストの付録
G. インフォメーションナーバスシステム用のエンティティ仕様
1．概要
2．ポートフォリオ（またはエンティティ集合）
3．シナリオの例
H. インフォメーションナーバスシステム用の知識コミュニティ閲覧と登録の仕様
I. インフォメーションナーバスシステム用のクライアント側の意味論的クエリ文書仕様
1. 意味論的クエリマークアップ言語（Ｓｅｍａｎｔｉｃ Ｑｕｅｒｙ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ、ＳＱＭＬ）の概要
2. ＳＱＭＬの生成
3. ＳＱＭＬの構文解析
J. インフォメーションナーバスシステム用の意味論的クライアント側のランタイム制御ＡＰＩの仕様
1. ナバナ意味論的ランタイム制御の導入 − 概要
2. ナバナ意味論的ランタイム制御ＡＰＩ
3. 電子メール制御のＡＰＩ
4. 人物制御ＡＰＩ
5. システム制御イベント
K. インフォメーションナーバスシステム用セキュリティの仕様
1. 権限
2. 人々のグループ
3. 識別情報のメタデータ連合
4. アクセス制御
L. インフォメーションナーバスシステム用のディープインフォメーションの仕様
M. インフォメーションナーバスシステム用のリクエスト作成ウィザードの仕様
N. インフォメーションナーバスシステム用のプロフィール作成ウィザードの仕様
O. インフォメーションナーバスシステム用のブックマーク作成ウィザードの仕様
1. ブックマーク作成ウィザードについて
2. シナリオ
3. 知的な発行ツールのメタデータ提案とメンテナンス
P. インフォメーションナーバスシステム（登録商標）用の意味論的スレッドの仕様
1. 意味論的スレッド
2. 意味論的スレッドの会話
3. 意味論的スレッドの管理
Q. スクリーンショットの例
R. インフォメーションナーバスシステムの意味論的クエリ定義および視覚化の仕様
1. 意味論的画像と動画
2. スマート砂時計
3. 視覚化 − 文脈テンプレート
本発明の好ましい実施例において、システムは当発明者の親出願で説明する特性や機能以外にもこのＣＩＰが盛り込まれる。
A. 補足的説明のシナリオ
次のシナリオでは、後続の詳細な説明をわかりやすくするため、システムのユーティリティや操作について説明する。
1. 特許審査官の先行技術検索ツール
主にＰＴＯ料金転用のため、米国特許審査官は骨の折れる先行技術の検索をほんのわずかな時間で行うことを余儀なくされる。審査官が利用できる調査ツールが過去数年の間に劇的に向上したとはいえ、これらのツールにはまだ多くの欠点がある。中でもほとんどの調査ツールは意味ベースではなくテキストベースである。従って、例えばＰＴＯウェブサイトの検索ツールは特定の用語を文書内の特定のフィールドで検索する。同様に、Ｇｏｏｇｌｅでの高度検索ツールを使うと、審査官は特定の用語または特定の用語列を含む文書、または特定の用語（単数か複数）を含まない文書を検索することができる。ただし、どの場合でも、検索エンジンでは審査官が意味ベースで文書を検索することはできない。従って、例えば本質的に同じアイディアを伝える関連文献であっても、クエリと全く異なる用語（同義語、またはさらに悪いのは類句）を使うと、予想できても発見できない可能性がある。審査官が思いつく限りの同義語、または発明に重要なキーワードの類句を検索する時間があったとしても、同じアイディアが全く同じ用語を使わずとも表現できるので、文献が見落とされる可能性があり、また時には同意語を持つアイディアは熟語としてきちんと圧縮されておらず、いくつかの文章や節に分散されることもある。
この理由としては、用語は、例えば数字がもつように、意味を一対一で表したり暗示したりしないからである。別の言い方をすれば、一定の意味合いはいくつかの異なる用語または本質的に無限の用語組合せによって表したり暗示したりできる。逆に一定の用語や用語組合せは、いくつかの異なる意味を表したり暗示したりできる。この無限大の多数対多数の可能性のネットワークにも関わらず、人間は（文脈、経験、論理、推論、演繹法、判断、学習などにより）少なくとも大抵の場合効果的に、可能な意味合いを分離させることができる。現在の先行技術のコンピュータ化された検索ツールは（ＰＴＯウェブサイト、またはＧｏｏｇｌｅかレキシスなど）これができない。当発明者の本発明の好ましい実施例は、意味合いをベースに検索できるため、このギャップを大幅に埋めることができる。
例えば、本発明の好ましい実施例の検索機能をいくつか使って、審査官は検索を行うことができ、現在以上の努力や時間を費やさずに、たとえ審査官が選ぶキーワードと共通の単語が１つも含まれていなくても、特許性に関連する検索結果を得ることができる。従って、意味ベースで文献を見つけるため、現行システムでは通常見つけられない審査官の課題に関連する結果を本システムでは入手できる。
また意味をベースにした場合、要求する検索と共通のキーワード（単数か複数）を共有するとしても、関係のない文献は排除できる。言い換えると、先行技術検索の問題の１つはフォールスポジティブ、つまり共通のキーワードが含まれるという理由だけで検察エンジンが関連すると「思い込んだ」結果であり、キーワードは文脈をより注意深く調べてみると、関連性のない意味合いを表したり暗示したりするために全く無関係である。従って、審査官は干し草の山から一本の針を探すようなもので時間の無駄が多い。
それに比べて、本発明の好ましい実施例にある検索機能をいくつか使うと、関連する検索結果の密度は劇的に増加する。というのは、システムには共通キーワードにも関わらず、関連性のない検索結果を除外するだけの「知性」があるからである。もちろんこれに関しては、人間が完璧であり得ないのと同様に、システムも完璧ではありえない。しかし、無関係な結果をふるいにかける上で現在のシステムよりははるかに効果的であり、この意味では単なるキーワードベースの検索エンジンというよりは、機能的または実践的に知的な調査アシスタントに似通っている。従って、本システムを使用して、審査官はよりすぐれた検索をより少ない時間内に完了できる。本システムをこのように使う具体的な仕組みの一例を次に挙げる。
より正確な磁気共鳴データ解析方法とその結果より正確な診断画像が生成できる、コンピュータソフトウェアに関する出願の審査を審査官が担当するとする。本発明の好ましい実施例の検索機能を使って関連する先行技術を検索するには、審査官は次を行う。
ａ. エンティティ作成ウィザードを使用して、「磁気共鳴画像化」が発生する様々な文脈内の関連カテゴリで「主題」エンティティを作成する。図示例として、図１と２は医薬品分類法で発生する「磁気共鳴画像化」を示す。ここで留意すべきは、カテゴリが発生する文脈がいくつかあることである。関連カテゴリをエンティティに追加して、「ＯＲ」演算を適用する。本質的にこれは、（自分の具体的なタスクに関連する）「磁気共鳴画像化」のエンティティを、審査する特許出願に基づく正しい文脈において発生するすべての磁気共鳴画像化と等しいとして定義するということになる。
ｂ. 新しいエンティティを「磁気共鳴画像化」で、おそらく「画像化」や「診断」、あるいはそのバリエーションや組合せで指名する。
ｃ. 「磁気共鳴画像化」のトピックエンティティを、好みのプロフィール（プロフィールには「特許データベース」の知識コミュニティを入れて設定するのが好ましい）のドシェ（特別エージェントまたはデフォルト知識リクエスト）のアイコンにドラッグ＆ドロップする。こうしてそれぞれの特別エージェント（文脈テンプレート）を表示する新しいドシェリクエスト／エージェントを開始する。それぞれの特別エージェントは次のような適切なデフォルトの述語と共に表示される。
・磁気共鳴画像化の全可能性
・磁気共鳴画像化の最も高い可能性
・磁気共鳴画像化のニュース速報
・磁気共鳴画像化の見出し
・磁気共鳴画像化の任意の可能性
・磁気共鳴画像化の専門家
・磁気共鳴画像化の新聞ダネになる人
・磁気共鳴画像化の関心を持つグループ
・磁気共鳴画像化に関する会話
・磁気共鳴画像化に関する注釈
・磁気共鳴画像化に関する注釈付き項目
・磁気共鳴画像化に関する来るべきイベント
・磁気共鳴画像化に関する人気のある項目
・磁気共鳴画像化に関する名著
ｄ． あるいはリクエスト作成ウィザードを使ってリクエストを作成することもできる。これを行うには、ドシェ文脈テンプレートを選択し、「特許データベース」知識コミュニティをリクエストの知識ソースとして選択する。あるいは、「特許データベース」知識コミュニティを入れてプロフィールを設定し、単に新規リクエストに選択したプロフィールを使うこともできる。次へを押すと、ウィザードはリクエストの意味を基にして名前を提案する。ウィザードはまた、「磁気共鳴画像化」「主題」エンティティの意味を基に適切なデフォルトの述語を選択する。ウィザードはエンティティが「主題」であることを知っているので、適切な文脈内で意味をなす適切なエンティティを選択する。終了を押す。ウィザードはクエリをコンパイルし、ＳＱＭＬを選択したプロフィールのＫＩＳへ送り、結果を表示する。
前記例では、結果は究極的にはどのソースからでも引き出すことができる。結果のいくつかはウェブ、ＰＴＯイントラネット、または場合によっては独自仕様のエクストラネットが出所であるのが好ましい。元の文書の範囲または出所に関わらず、本システムを使うことで、結果は自動的に処理され、また本システムにより自動的に「読み取り」と「理解」されるので、審査官のクエリが開始されると、本システムは同様に、意味論的と文脈ごとに「読み取り」と「理解」し、すべての関連結果でかつ関連する結果だけを見つけ出す。この場合も完璧にではないが、どの先行システムよりはるかに正確に行う。ここで留意すべきは、本システムが事前の文書のマニュアルタギングまたは分類に依存しないことである。正確性という点では助けになるものの、あまりにも労力がかかり、オンライン検索の利点を完全に失うだけでなく、新規文書の増化率からいっても全く非実用的である。
このシナリオにおいて、審査官は本発明の好ましい実施例の追加機能を使うことも望むかもしれない。例えば、審査官は以下のようにＰＴＯ内の専門家、またはＰＴＯ外の専門家による文献を参照することを望む場合もあろう（磁気共鳴画面化の専門家はそのドシェに含まれることに注意。ただし審査官はそれを別に追跡するために、専門家の別のリクエストを作成し、「リクエスト文書」として保存し、同僚などに電子メールで送付することを所望する場合もある）。磁気共鳴画面化の専門家をすべて以下のように検索する。
ａ. 上記の手順１−４に従う。
ｂ. 「磁気共鳴画像化」エンティティを、所望するプロフィールの専門家（特別エージェントまたはデフォルト知識リクエスト）のアイコンにドラッグ＆ドロップする。これにより「磁気共鳴画像化の専門家」と適切に題された新規リクエスト／エージェントが自動的に開始される。意味論的ブラウザは、エンティティが「主題」エンティティであり、文脈テンプレートが「人々」テンプレート（専門家）であることを「知っている」ため、適切なデフォルトの述語「ｉｎ」を選択する。このように、デフォルトの述語は２つの引数の共通部分（「ｉｎ」）を基にして選択される。そうすることで意味が通るからである。
2. バイオテック企業の研究シナリオ
バイオテック企業は研究集約的であり、ラボ研究だけでなく他社による研究の結果の調査というように、自社内外の研究を行う。残念ながら、係る企業が使用できる研究ツールには欠点がある。独自のサービスは、文脈依存で有用な結果を提供するが、このようなサービス自体のツールは劣悪であり、従ってインデックシングや人間の労力、高額な専門ジャーナルの購読に大きく依存し、その結果、高価で本システムのように正確ではない。他方で、バイオテックの研究者はＧｏｏｇｌｅを使って費用をかけることなく検索を行えるが、これは上述したキーワードに基づいた限界がある。
それとは対照的に、本発明の好ましい実施例の検索機能を使うと、バイオテク研究者はより多くの関連結果をより効率的に検索できる。具体的に言うと、研究者は次のようにシステムを使うことができる。例えば、研究者がマーケティングまたは研究部門の何者かが書いたゲノミクスおよび解剖学に関する見出しを検索する場合、以下のように行う。
ａ. ウィザードを使って、「マーケティング研究」のキーワードで配布リスト用の情報タイプのリクエスト／エージェントを開始する。
ｂ. マーケティング配布リストの結果を選択し、「エンティティとして保存」をクリックすると、オブジェクトは「チーム」エンティティとして保存される（意味論的ブラウザが、元のオブジェクトが配布リストであることを「知っている」からで、「チーム」エンティティがこの文脈では意味をなす）。
ｃ. 研究配布リスト結果を選択し「エンティティとして保存」をクリックすることにより、オブジェクトは「チーム」エンティティとして保存される（意味論的ブラウザは元のオブジェクトが配布リストであることを「知っている」ためである）。
ｄ. エンティティ作成ウィザードを使って、新しい「チーム」エンティティを作成し、「マーケティング」と「研究」チームエンティティをメンバーとして選択する。新規エンティティ「マーケティングまたは研究」を指名する。
ｅ. リクエスト作成ウィザードを使って、見出し文脈のテンプレートを選択し、次に「マーケティングまたは研究」エンティティをフィルタとして選択する。また、ゲノミクスカテゴリと解剖学カテゴリも選択する。次に、ＡＮＤ演算子を選択する。次へを押すと、ウィザードがリクエストの意味に基づき知的に名前を提案する。ウィザードは、「マーケティングまたは研究」チームエンティティ（「〜の誰か」）の意味に基づき適切なデフォルトの述語も選択する。ウィザードはエンティティが「チーム」であることを知っているため、意味が通るので「〜の誰か」をデフォルトに選択する。終了を押す。ウィザードはクエリをコンパイルし、ＳＱＭＬを選択プロフィールのＫＩＳに送信すると、結果が表示される。
また、研究者はマーケティングまたは研究のすべての専門家の検索を希望する場合は以下を行う。
ａ. 上記１−４の手順に従う。
ｂ. 「マーケティングまたは研究」エンティティを、所望するプロフィールの専門家（特別エージェントまたはデフォルトの知識リクエスト）アイコンにドラッグ＆ドロップする。こうして「マーケティングまたは研究の専門家」と題する新規リクエスト／エージェントを適切に開始する。意味論的ブラウザは、エンティティが「チーム」エンティティであり、文脈テンプレートが「人」のテンプレート（専門家）であることを「知っている」ため、適切なデフォルトの述語「ｉｎ」を選択する。デフォルトの述語は２つの引数の共通部分（「ｉｎ」）に基づいて選択することが意味を成すので、そのように選択される。
研究者がこの研究に戻る、補足する、または後に結果を分析する必要があると予想する場合、マーケティングまたは研究に関するドシェを次のように開くことができる。
ａ. 上記の手順１−４に従う。
ｂ. 「マーケティングまたは研究」エンティティを、所望のプロフィールのドシェ（特別エージェントまたはデフォルトの知識リクエスト）のアイコンにドラッグ＆ドロップする。こうしてそれぞれの特別エージェント（文脈テンプレート）を表示する新規ドシェリクエスト／エージェントを開始する。それぞれの特別エージェントは、次のような適切なデフォルトの述語で表示される。
・マーケティングまたは研究の誰かによる全可能性
・マーケティングまたは研究の誰かによる最も高い可能性
・マーケティングまたは研究の誰かによるニュース速報
・マーケティングまたは研究の誰かによる見出し
・マーケティングまたは研究の誰かによる任意の可能性
・マーケティングまたは研究の専門家
・マーケティングまたは研究の新聞ダネになる人
・マーケティングまたは研究の関心を持つグループ
・マーケティングまたは研究の誰かが関わる会話
・マーケティングまたは研究の誰かによる注釈
・マーケティングまたは研究の誰かによる注釈付き項目
・マーケティングまたは研究の誰かによる来るべきイベント
・マーケティングまたは研究の誰かによる人気のある項目
・マーケティングまたは研究の誰かによる名著
研究者が「私の競争相手に関するニュース速報」の検索に関心があるとすると、次のように行う。
ａ. 各競争相手に対して、エンティティ作成ウィザードを使って（「企業」の下で）新規の「競争相手」エンティティを作成する。必要に応じて適切なフィルタを選択する。例えば、（「Ｇｒｏｏｖｅ」等の）有名な英語名を持つ競争相手は、その会社の参入事業のカテゴリを含むエンティティとキーワードを持つことができる。
ｂ. エンティティ作成ウィザードを使って、ポートフォリオ（エンティティ集合）を作成し、手順ａで作成した全競争相手エンティティを追加する。エンティティの集合を「私の競争相手」と命名する。
ｃ. リクエスト作成ウィザードを使って、ニュース速報の文脈テンプレートを選択し、手順ｂで作成したポートフォリオ（エンティティ集合）をフィルタとして追加する。デフォルトの述語の選択をそのまま保つ。「次へ」を押すと、ウィザードはデフォルトの述語（「私の競争相手に関するニュース速報」）を使って知的にリクエスト名を提案する。終了を押す。ウィザードは「私の競争相手に関するニュース速報」と題する新規リクエスト／エージェントを開始する。
あるいは、研究者は通知を受けることを望むかもしれない。「私たちの競争相手に関するニュース速報」に関して、次のようにシステムに警告を発するよう指示できる。
ａ. 上述のように「私の競争相手に関するニュース速報」リクエストを作成する。
ｂ. そのリクエストをリクエスト監視リストに追加する。意味論的ブラウザは「私の競争相手に関するニュース速報」を流す警戒ペイン（チッカーなど）を表示する。リクエスト／エージェントから新しい結果がある際には、通知マネージャ（Ｎｏｔｉｆｉｃａｔｉｏｎ Ｍａｎａｇｅｒ、ＮＭ）を使って、意味論的ブラウザが電子メール、インスタントメッセージ、テキストメッセージなどを通じて警告を送信するよう示すこともできる。
また、研究者は将来の参考のために競争相手の記録を維持し、常時更新することを望むかもしれない。研究者が各競争相手に関してドシェの集合を示すようシステムに支持することにより、システムは次のように係る記録を作成し更新する。
ａ. 上記４ａで説明するように、各競争相手のエンティティを作成する。
ｂ. 各競争相手のエンティティに対して、所望のプロフィールのドシェアイコンにエンティティをドラッグして、その競争相手の新規ドシェを作成する。
ｃ. リクエスト作成ウィザードを使って、新規リクエスト集合（ブレンダー）を作成し、上記手順ｂで作成したドシェリクエストのそれぞれを集合に追加する（集合をさらにポピュレートするため、作成した集合にリクエストをドラッグ＆ドロップすることもできる）。次へを押すと、ウィザードはリクエスト集合に名前を提案する。終了を押す。ウィザードは個別ドシェを含むリクエスト集合を開始する。その後にリクエスト集合をお気に入りとして追加し、毎日開いて豊かで文脈上競争力のある情報を得ることができる。
研究者が特定のドシェを見直したい場合は、ＣＥＯ（名前の例としてジョン・スミス）に関するドシェを示すようシステムに指示できる。
ａ. ウィザードを使って、キーワード「ジョン・スミス」を持つ人々の情報タイプリクエスト／エージェントを開始する。
ｂ. 結果を選択し「エンティティとして保存」をクリックすると、オブジェクトは「人物」として保存される（意味論的ブラウザは元のオブジェクトが人物であることを「知っている」ため、「人物」エンティティがこの文脈では意味を成す）。
ｃ. リクエスト作成ウィザードを使って、ドシェ文脈テンプレートを選択し、次に「ジョン・スミス」エンティティをフィルタとして選択する。次へを押すと、ウィザードはリクエストの意味に基づいて知的に名前を提案する。ウィザードはまた、「ジョン・スミス」という人物エンティティの意味に基づき、適切なデフォルトの述語も選択する。終了を押す。ウィザードはクエリをコンパイルし、ＳＱＭＬを選択したプロフィールのＫＩＳに送信し、（サブクエリ／エージェントとしての）結果を次のように表示する。
・ジョン・スミスによる全可能性
・ジョン・スミスによる最も高い可能性
・ジョン・スミスによるニュース速報
・ジョン・スミスによる見出し
・ジョン・スミスによる任意の可能性
・ジョン・スミスのような専門家（この場合、ジョン・スミスと同じようなカテゴリにおいて専門知識を持つ専門家を表示する）
・ジョン・スミスのような新聞ダネになる人（この場合、ジョン・スミスが最近「新聞ダネになった」のと同じカテゴリで最近「新聞ダネになった」新聞ダネの人が表示される）
・ジョン・スミスのような関心を持つグループ（この場合、ある時間以内（好ましい実施例では２，３ヶ月である）にジョン・スミスが示したのと同じカテゴリで関心を示した人が表示される）
・ジョン・スミスが関わる会話
・ジョン・スミスによる注釈
・ジョン・スミスによる注釈付き項目
・ジョン・スミスによる来るべきイベント
・ジョン・スミスによる人気のある項目
・ジョン・スミスによる名著
前記のシナリオは、システムの操作を示したものである。システム自体は、以下でさらに詳しく説明する。
B. インフォメーションナーバスシステムの現在の好ましい実施例の内容
上記に参照した当発明者の同時係属中の特許出願および先行の仮出願を申請して以来、いくつかの改良、強化や変更が行われた。その内の一部は前回の特許出願に含まれた機能への改良または解明のみであり、また一部はシステムの全く新しい機能である。これらを以下に挙げ説明する。これらは重要度またはその他の順序に従って挙ているわけではない。本発明の好ましい実施例では、ユーザは以下に説明する機能や改良の一部または全部を使えるが、本発明を実行するためにいずれか１つの機能または任意の特別な組合せが必要なわけではない。
また本出願では、当発明者の特許出願通し番号１０／１７９，６５１号での定義と同じ用語が使われており、本出願全体における説明は、本出願の内容においてそれと異なると明示されていない限り、当発明者の親出願の定義、専門用語、命名法および図と併せて読むことを意図している。
1. スマート選択レンズの概要
スマート選択レンズは、インフォメーションナーバスシステム情報媒体のスマートレンズ機能に類似する。この場合、ユーザはオブジェクト内のテキストを選択でき、レンズは選択テキストをオブジェクトとして適用される（選択が変わるに従って動的に新規「画像」が生成される）。この方法ではユーザは、オブジェクト全体か何もなしかのどちらかに「レンズ」を当てることを制約されるのでなく、オブジェクトメタデータの設定可能なサブセットに「レンズ」を当てることができる。この機能は文脈で過負荷したカーソル／動詞の選択と似通っている。例えば、ユーザはプレゼンターのテキストを１つ選択し、テキストが表示されるオブジェクト上で「レンズとしてペーストする」アイコンを押すことができる。プレゼンターは次に、以下のようなメソッド呼出しを使って、クライアントランタイムコンポーネント（ＡｃｔｉｖｅＸのオブジェクトなど）にテキストを送る。
bstrSRML = GetSRMLForText( bstrText );
この呼出しによって引数テキストをカプセル化する一時的なＳＲＭＬバッファを返す。プレゼンターは次のようなメソッドを呼び出す。
bstrSQML = GetQueryForSmartLensOnObject( bstrSRMLObject );
このメソッドによってＳＱＭＬをクリップボードから取り、オブジェクト用の引数ＳＲＭＬを取得し、（「関連する」のデフォルトの述語で）ＳＱＭＬのリンクとしてＳＲＭＬの中のリソースを含む新規ＳＱＭＬを動的に作成する。メソッドは次に新規ＳＱＭＬを返す。プレゼンターは次のようにメソッドを呼び出す。
ProcessSemanticQuery( bstrSQML);
このメソッドによって生成レンズのＳＱＭＬを渡し、結果およびＳＲＭＬ結果の項目数を、好ましくは非同期で取得する。この呼出しに関する詳細は、仕様「インフォメーションナーバスシステムの意味論的ランタイムＯＣＳ」を参照されたい。プレゼンターは次のようなプレビューウィンドウ（または今使っているスキンによる相当物）を表示する。
［レンズエージェントタイトル］
２３項目見つかりました
［プレビューオブジェクト１］
［プレビューウィンドウ制御］
「レンズエージェントタイトル」は、クリップボード上のエージェントの題名である。プレビューウィンドウ（およびプレビューウィンドウ制御）に関する詳細は、当発明者の親出願通し番号１０／１７９，６５１号を参照されたい。
好ましい実施例では、プレビューウィンドウは次を行う。
・タイマーが切れたあと（５００ｍｓ程度で）非表示となる。マウスの動きによって、タイマーがリセットされるのが好ましい（これでユーザが同じ場所の周辺でマウスを動かすときに、ウィンドウの点滅を回避する）。
・（最終的に）ゆっくりとフェードアウトする。
好ましい実施例は次の機能も含む。
1. オブジェクトごとに１つの選択範囲であるが、結果の組につき複数の選択ができるのが最適なオプションである。そうでないと、システムは（オブジェクトごとではなく）オブジェクトごと選択ごとのレンズアイコンを表示するために、ユーザにとってわかりにくい経験となり、複雑なＵＩを作り出してしまう。
2. （エージェントレンズと一致させて動的に生成されたＳＱＭＬにもかかわらず、通常のＳＱＭＬクエリである）未解決のレンズクエリのリクエストは、プレゼンターがもはや必要としなくなった時点で取り消されるべきである（例えば、プレゼンターが新しいページをナビゲートしたり、オブジェクトの新しいレンズをリクエストしたりする場合）。いずれにしても、レンズクエリはおそらく一度に数個のオブジェクトを求めるだけであろうから、係る取消しは性能的（または帯域幅）にも重大ではない。たとえクエリが取り消されなくても、プレゼンターは結果を無視することができる。（レンズクエリが取り消されるかどうかに関係なく）いずれにしても、プレゼンターは処分するなどして廃れてしまった結果を始末しないといけないので同じことである。プレゼンターがリクエスト取消しリクエストを出すのと、取消しが実際に完了する間になんらかの遅延が生じる。結果の一部がこの間に漏れる可能性があるので、これらは廃棄する必要がある。従って好ましい実施例には非同期取消し実施が含まれ、ソフトウェアコンポーネントは、常に不良または廃れた結果を無視するよう設計されている。
3. プレゼンターは（現在のレンズのリクエスト状態を示す）アイコンとツールヒントの両方を持っていることが好ましい。ユーザがオブジェクトにマウスカーソルを合わせる、またはクリックすると、プレゼンターはフレーズ「レンズ情報をリクエストする」（またはそれと同じ効果のフレーズ）のようなツールヒントを掲げることができる。情報が戻ってくると、マウスカーソルを合わせることで「２３件のオブジェクトを発見」のヒントが表示され、クリックすると結果が表示される。この割込みツールヒントは、結果が戻ってくるときにまだ表示されている場合には、プレビューウィンドウに移行させることができる。
また、ここで留意すべきは、スマートレンズのようなスマート選択レンズは、テキストメタデータ以外のオブジェクトにも適用できることである。例えば、スマート選択レンズは、画像、ビデオ、オーディオストリームの一部またはその他メタデータに適用できる。これらの場合、プレゼンターはデータタイプと「選択区域」と一致する適切なＳＲＭＬを返す。この区域とは、画像、ビデオ、オーディオストリーム内の時間の間隔などがあり得る。スマートレンズ機能性の残りの部分は、（レンズの下でデータタイプのスキーマに基づくことになる）ＳＲＭＬに基づいて生成される適切なＳＱＭＬに、上述のように適用される。
2. 人物オブジェクトのペーストの概要
インフォメーションナーバスシステム（これもこの本出願の好ましい実施例のある側面に対する現在の略名の１つである）は、（人、ユーザ、顧客など）の「人物」オブジェクトのドラッグ＆ドロップ、コピー＆ペーストもサポートする。この場合、好ましい実施例の操作を示す少なくとも２つのシナリオが存在する。
1. 人物の出所の知識コミュニティ（またはエージェンシー）を代表するスマートリクエストに人物オブジェクトをペーストする。この場合、サーバの意味論的クエリプロセッサは、人物を引数として使ったクライアントからのＳＱＭＬを単に解決するに過ぎない。例えば、ユーザが人物「ジョー」をスマートリクエストの「ロイターの見出し」の上にペースト（またはドラッグ＆ドロップ）すると、クライアントは追加引数を使って新しいスマートリクエストを作成する。ロイターのインフォメーションナーバスシステムのウェブサービスは次に、「ジョー」によって注釈、あるいは公開された見出しすべてを返すことで、このリクエストを解決する。この場合、サーバは、本シナリオに対して意味をなす（「〜によって公開か注釈された」）の適切なデフォルトの述語を本質的に適用する。
2. 人物の出所でない知識コミュニティ（またはエージェンシー）を代表するスマートリクエストに人物オブジェクトをペーストする。この場合、人物オブジェクトは（ＳＭＳ上）の送信先の知識コミュニティの意味ネットワークにないため、サーバの意味論的クエリプロセッサは、人物引数の意味が通らない。従って、例えば人物が（好ましい実施例において）専門家または新聞ダネになる人のカテゴリを使うなど、サーバは別の方法で人物引数を解決する必要がある。例えば、上記の例をとると、ユーザが人物「ジョー」をスマートリクエストの「ロイターの見出し」上にペースト（またはドラッグ＆ドロップ）して、ジョーがロイターの知識コミュニティ上の人物でない場合、（好ましい実施例では）ロイターウェブサービスが、「ジョーの専門に関連する」見出しを返さなければならない。この実施例は次に、クライアントがＳＱＭＬを送信先のウェブサービスに送る前に、２つのパスの方法を取る必要がある。まず、その人物が所属する知識コミュニティにその人物の専門を代表する「代表データ（ＳＲＭＬ）」を問い合わせる。ウェブサービスはこのリクエストを次のように解決する。
a. その人物のオブジェクトがペーストあるいはドロップされた知識コミュニティ（ロイターなど）のクエリを行い、そのコミュニティの意味論的ドメインの情報はそのコミュニティの特定の分類法またはオントロジーを構成するおよび／または代表する。ここで留意すべきは、いくつかの意味論的ドメインが存在し得ることである。
b. その人物オブジェクトの出所である知識コミュニティにその人物の意味論的ドメイン情報のクエリを行う。
c. 意味論的ドメインが同一であるか、最低１つの共通する意味論的ドメインが存在する場合、クライアントはその人物オブジェクトの出所である知識コミュニティにその人物の意味論的ドメイン情報のクエリを行う。クライアントは次に、これらのカテゴリを引数としてＳＱＭＬを構築し、その人物がペーストまたはドロップされた知識コミュニティにこのＳＱＭＬを送る。
意味論的ドメインが同一でないか、少なくとも１つの共通意味論的ドメインが存在しない場合、その人物オブジェクトの出所である知識コミュニティにその人物が専門家としてカテゴリに属するいくつかのオブジェクトにクエリを行う。好ましい実施例では、この実行では、専門のカテゴリを正確に表すのに充分な高いオブジェクト数が選ばれるはずである（この数字は実験に基づき選ぶのが好ましい）。この場合のオブジェクトを選択する理由は、送信先ウェブサービスは人物の出所である知識コミュニティのカテゴリを理解せず、よって特有のカテゴリにそれらをマッピングできないことによる。その代わりに、異なる知識コミュニティの間でカテゴリをマッピングする、（インターネットの集中ウェブサービスを通じて）カテゴリのマッパーを採用できる。この場合、送信先の知識コミュニティは、たとえそれらのカテゴリを理解しないとしても、常にカテゴリをＳＱＭＬの一部として受け取り、知識コミュニティはその後に、カテゴリマッパーウェブサービスを使って、これらのカテゴリを内部カテゴリにマッピングする。カテゴリマッパーウェブサービスは、カテゴリの解決法およびカテゴリマッピングを公開する方法を有する。
3. スマートリクエストの保存と共有の概要
インフォメーションナーバスシステムの意味論的ブラウザ（インフォメーションエージェントまたはライブラリアン）のユーザは、スマートリクエストをディスクに保存、添付書類として電子メールで送付またはインスタントメッセンジャー（これも添付書類として）で共有またはその他の手段も使える。クライアントアプリケーションは、スマートリクエストを共有可能文書として保存する方法を公開する。クライアントアプリケーションはまた、スマートリクエスト文書を電子メールまたはインスタントメッセンジャーの添付書類として共有する方法も公開する。
共有可能なスマートリクエスト文書は、（バイナリフォーマットで安全なストリームを通じて）ＳＱＭＬをカプセル化するバイナリ文書である。数ある機能の中でも、仕様の保全性を維持し知的所有権を保護できる、意味論的クエリの安全で連続化した表現を提供する。例えば、クエリ自体が研究者の雇用主の企業秘密を具現化している可能性があり、それが公開された場合は、重要で競争力ある情報を競争相手が逆エンジニアして会社に損失をもたらすこともあり得る。これを保護するには、意味論的クエリのＸＭＬバージョン（ＳＱＭＬ）の強力な暗号化または強力な一方向性ハッシュ法など、いくつかの方法がある。共有可能文書には、リクエストを表す拡張子（．ＲＥＱ）が付いている。クライアントオペレーティングシステムの拡張子ハンドラは、この拡張子を表すためにインストールされる。その拡張子の付いた文書を開ける際には、文書をオープンするために拡張子ハンドラが呼び出される。拡張子ハンドラは、安全なストリームからＳＱＭＬを抽出して文書を開け、意味ネームスペースにＳＱＭＬでスマートリクエストを作成する。ハンドラは次に、意味ネームスペースでスマートリクエストをオープンする。
意味ネームスペースのスマートリクエストを保存するか、ユーザが電子メールの添付書類として送信したい場合、クライアントはスマートリクエストを表すＳＱＭＬをバイナリ．ＲＥＱフォーマットでシリアル化し、リクエストされたディレクトリパスで保存するか、または．ＲＥＱ文書が添付書類として付いた電子メールクライアントを開く。
図３は、スマートリクエストでＳＱＭＬバッファをカプセル化するバイナリ文書フォーマットを示し、拡張子ハンドラの文書の開き方も図示する。同様のモデルを結果共有のために（ＳＲＭＬ経由にて）用いることもできる。この場合、バイナリ文書は、上記のＳＱＭＬの代わりにＳＲＭＬをカプセル化する。
図４Ａと４Ｂは、ウィンドウズ（登録商標）シェルで登録関連付けされた２つの．ＲＥＱ文書（右端の「私の研究レポート（ライブ）に関連するロイターの見出し」および「ロイターの見出し（２００３年１月２１日０８ １７ＡＭ現在）」の表題）を図示する。最初のリクエスト文書は、「ライブ」で、二番目の文書は特定時間のスナップショットである（どちらも時間に敏感なリクエストである）。ここで留意すべきは、オペレーティングシステムが意味論的ブラウザ・アプリケーション（ナバナライブラリアン（Ｎｅｒｎａｖａ Ｌｉｂｒａｒｉａｎ））を文書と関連付けたことである。
・エンティティの保存と共有 − エンティティを表す．ＥＮＴ拡張子が付く以外は、上記と同じプロセスが適用される。エンティティ文書が呼び出されると、ナバナライブラリアンは、エンティティＳＱＭＬをブラウザに開く。
・拡張子特性シート − 一時的なスマートリクエストまたはエンティティ（文書の種類によって）を意味論環境に作成し、スマートリクエストまたはエンティティに関する特性シートを表示する。
・拡張子ツールヒント − ユーザがライブラリアン文書（リクエスト、．ＲＥＱまたはエンティティ、．ＥＮＴ）にマウスを合わせた際に、役立つツールヒントを表示する。
4. スマートスナップショットの保存と共有の概要
インフォメーションナーバスシステムは、当発明者が「スマートスナップショット」と呼ぶ物の共有もサポートする。スマートスナップショットは、スマートリクエストをある時点で凍結したものである。これでユーザがスマートリクエストを共有したいが、「ライブ」である必要はない場合に役立つ。例えば、デフォルト設定でユーザが、「この文書に関連するロイターのニュース速報」というスマートリクエストを同僚と共有する場合、同僚は（「現在の時間」を基にして）スマートリクエストのライブ結果を見られる。ただし、ユーザが「この文書に関連するロイターの［現在の時間の］ニュース速報」を共有したい場合は、スマートスナップショットが用いられる。
スマートスナップショットは、ＳＱＭＬ文書の「属性」部分にスナップショット（フラグＱＵＥＲＹＡＴＴＲＩＢＵＴＥＳ＿ＳＮＡＰＳＨＯＴ）であることを印す属性が含まれることを除けば、スマートリクエストと同じである（ＳＱＭＬクエリ文書によって表される）。ＳＱＭＬ文書の作成日／時間もＳＱＭＬに保存される（前と同様に、ＳＱＭＬスキーマには作成日／時間のフィールドが含まれる）。ユーザがスマートリクエストを共有する意向を示すとき、ユーザインタフェース（意味論的ブラウザ、インフォメーションエージェントまたはライブラリアン）は、スマートリクエスト（ライブ）かスマートスナップショットのどちらを共有したいのかを尋ねる。ユーザがスマートリクエストを指定する場合、上記で説明したプロセス（パート３）が用いられる。ユーザがスマートスナップショットを指定すると、バイナリ文書は編集済みのＳＱＭＬ（スナップショット属性を含む）をポピュレートして、残りのプロセスに上記のように従う。
バイナリ文書を（電子メール、インスタントメッセージングなどで）受信者が受け取り開くと、拡張子ハンドラが文書を開き、エントリをスマートリクエストとして意味ネームスペースへ追加する（上記で説明の通り）。受信者がスマートリクエストを開くと、クライアントの意味論的クエリプロセッサが処理済みのＳＱＭＬを（前回説明の通り）サーバのＸＭＬウェブサービスへ送信する。サーバの意味論的クエリプロセッサは次に、ＳＱＭＬを処理し、ＳＱＭＬの作成日／時間に関連する意味論的クエリを呼び出して、スナップショット属性を受け入れる。このように結果は元の日／時間に関連させることにより、送信者の意向が尊重される。
5. 仮想知識コミュニティ
仮想知識コミュニティ（エージェンシー）とは、サーバ群が１つのサーバであるかのように見せて発行することを知識コミュニティの発行者に許可するインフォメーションナーバスシステムの一機能である。例えば、ロイターは業界ごとのロイター知識コミュニティ（医薬品、石油とガス、製造業、金融サービスなど）を持つことができるが、１つの「ロイター」の知識コミュニティに公開することを選択する場合がある。これを行うには、ロイターは（ＸＭＬウェブサービスのＷＳＤＬのＵＲＬの代わりに）仮想知識コミュニティに対するＳＱＭＬを発行および発表する。ＳＱＭＬには、実際の知識コミュニティのＷＳＤＬブレンダー（または集合）が含まれる。意味論的ブラウザは次に、ＳＱＭＬを取り込み（単一サーバであるかのように）知識コミュニティのアイコンを表示する。知識コミュニティに関するいかなるアクションも、ＳＱＭＬの各サーバに広められる。ユーザが係るアクションへのアクセスを持たない場合、ウェブサービス呼出しはそれに従って不成功に終わるが、そうでなければアクションが行われる（ユーザが知識コミュニティを含むブレンダーをマニュアルで作成するのと変わらない）。
6. 時間に敏感な意味論的クエリの実行
時間に敏感な意味論的クエリは、問題となる知識コミュニティ（エージェンシー）での知識生成率にあった知的な方法で実行するのが好ましい。例えば、毎秒１０の文書入手するサーバの「ニュース速報」は、毎月１０の文書を入手するサーバの「ニュース速報」とは同じではない、同様に、サーバ側の意味論的クエリプロセッサは、時間に敏感な意味論的クエリ扱いを、情報のサーバでの累積率に従って調節するのが好ましい。これを実行するには、例えば、一般的な規則の目安は次のようである。
・毎分の新規オブジェクト数に基づいてＮが調節される、最も最近のＮオブジェクト
・オブジェクト数に上限をつけた、最後のＮ分間に入手した全オブジェクト数（最小値（上限、過去Ｎ分間に入手した全オブジェクト数））
クエリが見出しかニュース速報かに基づき、Ｎを調節することができる。好ましい実施例では、新聞ダネになる人のクエリは、見出しと同じ時間に敏感なパラメータで実施することが好ましい。
7. 音声変換スキンの概要
音声変換はオブジェクトレベルおよびリクエストレベルで実装される。オブジェクトレベルでは、オブジェクトスキンはオブジェクトのＳＲＭＬを取るためのスクリプトを実行し、ＳＲＭＬを解釈し、次に（ＳＲＭＬフィールド内の）テキストが選択した部分を（マイクロソフトウィンドウズのスピーチＳＤＫなどを使って）音声変換エンジンに渡して音声出力を生成する。
図５は、音声変換オブジェクトスキンの図を示す。実行されると、図５で示すパイプラインは、次のような音声出力として表示される。
1. 電子メールメッセージの読込み
2. 適切な遅延
3. ノサ・オモイグイからのメッセージ
4. 適切な遅延
5. ジョン・スミス宛に送られたメッセージ
6. 適切な遅延
7. ジョー・サムボディにコピーしたメッセージ
8. 適切な遅延
9. 「メッセージ主題はウェブサービス」は、分散コンピューティングに使われるソフトウェア構築ブロックである
10. 適切な遅延
11. 「メッセージ要約」はウェブサービス
12. 適切な遅延
13. 「［オプションの］メッセージ本文はウェブサービス」は、分散コンピューティングに使われるソフトウェア構築ブロックである。
この例は、次のような音声スキンテンプレートを想定する。
1. 電子メッセージの読込み
2. 適切な遅延
3. ＜メッセージ作者名＞からのメッセージ
4. 適切な遅延
5. ＜宛先： 受信者＞へ送信されたメッセージ
6. 適切な遅延
7. ＜メッセージｃｃ：受信者名＞
8. 適切な遅延
9. メッセージの主題は＜メッセージ主題テキスト＞
10. 適切な遅延
11. メッセージ要約は＜メッセージ本文要約＞
12. 適切な遅延
13.［オプションの］メッセージ本文は＜メッセージ本文＞
音声を演出するのに、理解しやすく、提供するオブジェクトの意味を伝えるその他のテンプレートも使用できる。上記に示す例（電子メール用）のように、オブジェクトタイプの意味を捉えるには、実装には、すべての情報オブジェクトタイプに対して適切な音声変換テンプレートを使うべきである。
リクエストレベルでは、意味論的ブラウザの表示エンジン（プレゼンター）が（ユーザ選択のカーソル位置に基づいて）演出されるすべての最新オブジェクトに対してＳＲＭＬを取るスキンを読み込み、次に各オブジェクトに対して音声変換オブジェクトスキンを呼び出す。これは基本的には、演出される各ＸＭＬオブジェクトに対して音声変換アクションを次々に繰り返す。
電子メールオブジェクト（ＳＲＭＬ）
オブジェクト解釈エンジン（オブジェクトスキン）
音声変換エンジン
送信者：ノサ・オモイグイ
宛先：ジョン・スミス
コピー先：ジョー・サムボディ
主題：ウェブサービス
概要：ウェブサービスは、分散コンピューティングに使われるソフトウェアの構築ブロックである
本文：ウェブサービス…
音声出力
電子メールメッセージの読込み
遅延
音声出力
ノサ・オモイグイからのメッセージ
遅延
音声出力
ジョン・スミス宛に送信したメッセージ
遅延
音声出力
ジョー・サムボディにコピー送信したメッセージ
遅延
「メッセージ主題はウェブサービス」は、分散コンピューティングに使われたソフトウェア構築ブロックである
音声出力
遅延
音声出力
メッセージ要約はウェブサービス
遅延
音声出力
メッセージ要約はウェブサービス
図６は、リクエストスキンを通して意味論的ブラウザに表示される、いくつかの電子メールオブジェクトの図示である。
送信者：ノサ・オモイグイ
宛先：ジョン・スミス
コピー先：ジョー・サムボディ
主題：ウェブサービス
要約：ウェブサービスは、分散コンピューティングに使われるソフトウェア構築ブロックである
本文：ウェブサービス…
電子メールオブジェクト１
オブジェクトスキン（オブジェクト１）
電子メールオブジェクト２
電子メールオブジェクト３
電子メールオブジェクトＮ
8. 言語翻訳スキン
言語翻訳スキンは、変換が言語軸上であることを除けば、音声変換スキンと同じように実装される。ＸＳＬＴスキン（スマートスタイル）は、言語翻訳をリアルタイムで自動的に行うためのソフトウェアエンジンを呼び出すことができ、その後世界各国の言語を表すためにユニコード（文字当り１６ビット）でコード化されたＸＭＬを生成する。最終的な表示出力を生成するＸＳＬＴ変換は、翻訳されたＸＭＬの内容を基に適当な文字セットを使って出力を処理する。
言語にとらわれない意味論的クエリ
意味論的クエリは、言語にとらわれない方法で呼び出すこともできる。これは、意味論的ブラウザによって生成されるＳＱＭＬを翻訳する翻訳層（ＳＱＭＬ言語翻訳ルーチン）を、ＫＤＳ（またはＫＢＳ）による解釈に適した形式にすることで実装される。ＫＤＳ（またはＫＢＳ）はその結果１つ以上の言語用に準備した知識ドメインオントロジーを有す。ＳＱＭＬ言語翻訳ルーチンは、（キーワード、テキスト、概念、カテゴリなどの）述語で参照されたオブジェクトを翻訳し、それをサーバ側の意味論的クエリプロセッサに解釈のため送信する。その結果は、言語翻訳スキンによって元の言語に戻される。
9. ユーザ経験でのファーストクラスのオブジェクトとしてのカテゴリ
これは、知識コミュニティのカテゴリがエンドユーザに公表される機能のことである。エンドユーザは情報タイプ（「ウェブサービス」など）としてカテゴリに対してクエリを発行できる。次にメタデータが任意のファーストクラス情報のオブジェクトタイプの場合と同様に、意味論的ブラウザに表示される。視覚化、動的リンク、文脈パレットなども、カテゴリオブジェクトをピボットとして使って使用できる。この機能は、カテゴリをパラメータとして持つスマートリクエスト（スマートエージェント）で開始するのではなく、ユーザがカテゴリで開始して、そのカテゴリを動的ナビゲーションのピボットとして使いたい場合に役に立つ。
10. 分類された注釈
分類された注釈は、ファーストクラスのオブジェクトであるカテゴリから得られる。ユーザはカテゴリに直接注釈を付けることができ、従ってカテゴリにマッピングされた電子メールリストをシミュレートする。ただし、（例えば医薬品など）カテゴリが多くある場合、情報が多数のカテゴリに属する場合があり、ユーザがどのカテゴリに注釈を付けるかを考える必要があるべきではないので、この方法は薦められない。ユーザは注釈を自動的に分類される知識コミュニティ（エージェンシー）に直接発行する、あるいはカテゴリよりも文脈的である文書または電子メッセージのようなオブジェクトに注釈を付けるべきである。
11. 補助的文脈テンプレート
１. 専門家 − 専門家の機能は、当発明者の親出願通し番号１０／１７９，６５１号で特別エージェントとして示した。同出願から明らかなように、専門家の機能は文脈テンプレートの部分と連結させて運用することもできる。専門家は文脈テンプレートであり、その名称が示唆するように、１つ以上の主題または文脈に専門知識を有する人々を示す（ＰＲＥＤＩＣＡＴＥＴＹＰＥＩＤ＿ＥＸＰＥＲＴＯＮ属性で示す）。
２. 関心を持つグループ − 名前が示唆するとおり、１つ以上の主題または文脈に関心を持つ（ただし必ずしも専門家ではない）人々を示す文脈テンプレートのことである（ＰＲＥＤＩＣＡＴＥＴＹＰＥＩＤ＿ＩＮＴＥＲＥＳＴＩＮ属性で示す）。この文脈テンプレートは、意味論的ネットワークの中で任意の意味カテゴリに関心を示した人々を返す。実際に現実的なシナリオでは、答を持つ人々を返す専門家と、質問（または答）がある人々の結果を返す関心を持つグループからなる。好ましい実施例では、ＫＩＳ用に構成された知識ドメインで意味ネットワークに結果として分類された情報を作成した人々の結果を返すことにより実装される。本質的に、この文脈テンプレートはユーザに、動的で関心のある意味コミュニティを提示する。大変強力な文脈テンプレートである。現在、ほとんどの機関では、関心を持つグループのコミュニティを示すために電子メール配布リスト（またはそのようなもの）を使う。ただし、これらのリストは維持が難しく、管理者は機関内のどの人々がリストに属するのが好ましいかを手動で追跡（または推測）する必要がある。関心を持つグループの文脈テンプレートを使えば、「リスト」は知的かつ意味を持つようになる（「スマート配布リスト」と同類）。これらは文脈的でもあり、手動の電子メール配布リストに欠けている機能である。
その他の文脈テンプレートと同様に、関心を持つグループの文脈の述語は次に、サーバ側の意味論的クエリプロセッサによって解釈される。これによって、「ＸＭＬに関心を持つグループ」または「バイオインフォマティックスに関心を持つグループ」のような強力なクエリが可能になる。同様に、これによって「私のローカル文書に関心を持つグループ」や「私の競争相手（エンティティ）に関心を持つグループ」のようなクエリが（ドラッグ＆ドロップおよび／またはスマートコピー＆ペーストを通して）可能になる。関心を持つグループの文脈テンプレートは、ドシェ（またはガイド）文脈テンプレートの一部にもなる（そして各文脈テンプレートの特別エージェントすべてを表示し、それらを主要エージェント／リクエストのサブクエリとしてロードする）。
好ましい実施例では、文脈テンプレートは「関心のある分野」を検出する時間制限を与えられるべきである。この例は３ヶ月である。この論理としては、ユーザがＳＱＭＬフィルタ（可能な場合）に意味論的に関連する情報（最も一般的なのは電子メール）を３ヶ月間にまったく作成していない場合、ユーザはそのカテゴリ（単数か複数）に関心がないか、以前あったが今は関心がなくなったということである。
３. 私の項目の注釈 − これは注釈の変形である文脈テンプレートであるが、呼び出すユーザによって発行された項目でさらにフィルタリングされている。これによってユーザが掲載したか注釈を付けた項目に関して特別にフィードバックを監視できる。
12. ユーザ状態のインポートとエクスポート
意味論的ブラウザは、ユーザ状態のインポートとエクスポートをサポートする。ユーザは各自の個人的な状態を文書に保存でき、それを別のマシンにエクスポートしたり、その逆をしたりすることも可能である。この状態には次のような情報（およびメタデータ）が含まれる。
・デフォルトのユーザ状態（コンピュータ高度化レベル、関心分野のデフォルト、ジョブ役割デフォルト、スマートスタイルのデフォルトなど）
・プロフィール
・エンティティ（プロフィールごと）
・スマートリクエスト（プロフィールごと）
・ローカルリクエスト（プロフィールごと）
・登録する知識コミュニティ（プロフィールごと）
意味論的ブラウザは、ユーザにどちらのユーザ状態タイプをインポートまたはエクスポートするかを選択させるＵＩ（ウィザードの可能性あり）を示す。ＵＩはまた、ユーザに識別／ログオン情報を含めるかどうかを尋ねる。ＵＩが呼び出されると、意味論的ブラウザはユーザ状態を、全ユーザ状態タイプのメタデータと一致するフィールドを持つＸＭＬ文書にシリアル化する。ＸＭＬ文書がインポートされると、意味論的ブラウザはＸＭＬ文書ノードをナビゲートし、ＸＭＬ文書のノードと一致するクライアント環境のユーザ状態タイプを追加または設定する。
13. ローカルスマートリクエスト
ローカルスマートリクエストは、ユーザが知識コミュニティ（エージェンシー）からのカテゴリを使ってローカル情報をブラウズすることを可能にする。分類されたローカルリクエストの場合、意味クライアントはローカルハードドライブ、電子メール格納などをクロールし、（概要を含む）メタデータを抽出し、メタデータを意味論的メタデータ格納（ｓｅｍａｎｔｉｃ ｍｅｔａｄａｔａ ｓｔｏｒｅ、ＳＭＳ）のローカルバージョンに保存する。クライアントはＸＭＬメタデータを（オブジェクトごとに）分類のために知識コミュニティに送る（そのコミュニティのＸＭＬウェブサービスを経由）。知識コミュニティは次にカテゴリ割当てメタデータで対応する。クライアントは次に、（ローカルＳＭＳ経由で）ローカル意味ネットワークを更新し、サーバが行うのと同様に意味論的クエリに対応する。本質的に、この機能はローカルサーバを必要とせず、ローカルサーバに等しい機能性を提供できる。
14. 統合ナビゲーション
統合ナビゲーションは、ユーザが（右側の主な結果ウィンドウペイン内の）プレゼンター内で動的にナビゲートすることを可能にし、ナビゲーションを左側のシェル拡張子ナビゲーションと統合化させる。実質的にこれによって両方のスタックが統合される。好ましい実施例では、これはイベントシグナル伝達を通して達成される。プレゼンターが新しいリクエストに動的にナビゲートしたい場合、現在のブラウザビューを識別するＧＵＩＤに何らかの状態を引き起こす。ＧＵＩＤは、「ナビゲーションイベント」、「次のネームスペースオブジェクトＩＤ」および「次のパス」と呼ばれるフィールドも持つレジストリにキーにマッピングする。「ナビゲーションイベント」フィールドは、ロードされると現在のブラウザビューで作成されるイベントハンドルを指すＤＷＡＲＤ値を有す。プレゼンターが新規リクエストへのナビゲートを希望する際には、意味論環境にリクエストを作成しリクエストの返されたＩＤをキャシュに入れる。次に（リクエストの情報／文脈タイプ次第で）リクエストの適切なネームスペースパスを動的に取り込み、それもキャシュに入れる。その後２つのフィールド（「次のネームスペースオブジェクトＩＤ」および「次のパス」をこの２つの値で）を設定する。次に、「ナビゲーションイベント」（ウィンドウズでは、「ＳｅｔＥｖｅｎｔ」という名のＷｉｎ３２ＡＰＩを呼び出して行う）を設定する。
ナビゲーションイベントを取り込むには、ブラウザビューは最初に開始されたときにワーカースレッドを開始する。このスレッドはナビゲーションイベント上で待機し（同時にブラウザビューが終了する際にシグナル伝達されるシャットダウンイベント上で待機する − ウィンドウズでは「ＷａｉｔＦｏｒＭｕｌｔｉｐｌｅＯｂｊｅｃｔｓ」という名のＷｉｎ３２ ＡＰＩ経由で行われる）。ナビゲーションイベントがシグナル伝達されると、ナビゲーションイベントがシグナル伝達されたことを示す「待ち」ＡＰＩを返す。ワーカースレッドは次にレジストリを調べて、（オブジェクトのＩＤとパスの）ナビゲーション状態を取得する。次にシェルブラウザを呼び出し、このオブジェクトＩＤとパスにナビゲートする（ウィンドウズでは、これは「ＰＩＤＬ」を取得し、次にＩｓｈｅｌｌＶｉｅｗを実装するシェルビューインスタンスからＩｓｈｅｌｌＢｒｏｗｓｅｒ：：ＢｒｏｗｓｅＴｏを呼び出すことで行われる）。
15. 探訪結果のヒント
ナバナ（Ｎｅｒｖａｎａ）意味論的ブラウザは、ユーザが思考速度で知識スペースを動的にナビゲートする力を与える。ユーザは文脈、情報または時間軸に沿ってナビゲートできる。ただし、ユーザがナビゲートするに従い、重複した情報が提示される可能性がある。例えば、ユーザがローカル文書から「ニュース速報」にナビゲートでき、「ニュース速報」の結果オブジェクトの１つから「見出し」へナビゲートできる。しかし、意味論的には、見出しの一部はニュース速報と重複する場合がある（特に充分な時間が経過していない場合）。これはウェブをブラウズして同じページを何度も繰り返し別の「角度」から参照するのと同じである。
ナバナ意味論的ブラウザは、最近提示された結果のローカルキャシュを設けることによって、この重複問題を処理する。プレゼンターは次に、結果を別の色または別のＵＩ機構で示して、重複結果をユーザに示す。ローカルキャシュは時間を経ている（数時間、あるいは一般的な「ブラウジングの経験」の測定時間を経た後が好ましい）。古いエントリは消去され、キャシュは充分な時間が経過した後で最終的にリセットされる。
その代わりに、ユーザのオプションによって、重複結果を破棄し一切提示しないこともできる。詳しくは、意味論的ブラウザは、例えば、同じメタデータを持つ複数オブジェクトが異なる知識コミュニティ（エージェンシー）にレンダリングされる場合に、プレゼンターで提供する前に重複分を削除することで重複結果を処理する。意味論的ブラウザは、メタデータの比較を行ってこれを検出する。文書、電子メールなどのような体系化されていないデータに関しては、意味論的ブラウザは概要を比較する。概要が同一の場合、文書も同一である可能性が高い（絶対的な保証はできないが、長文の場合は特にそうである）。
16. 知識連合
クライアント側の知識連合
クライアント側の知識連合は、ユーザが知識コミュニティを連合させて、あたかもそれらが一箇所で発生したかのように結果を操作する（この連合機能は、当発明者の親出願通し番号１０／１７９，６５１号に説明してある）。好ましい実施例では、係るクライアント側の知識連合は、異なる（連合された）ＫＩＳからのＳＲＭＬ結果を到着する順にマージさせる意味論的ブラウザにより達成される。
サーバ側の知識連合
サーバ側の知識連合とは、知識コミュニティの範囲内で外部知識を連合させることができる技術である。例えば、多くの会社は情報を提供するロイターのような外部コンテンツプロバイダに依存する。ただし、インフォメーションナーバスシステムでは、注釈、個人発行物などに関連するセキュリティおよびプライバシーの問題が発生する。多くのエンタープライズ顧客は、外部コンテンツプロバイダがホストし管理する遠隔サーバに機密情報の注釈が格納されることを望まない。
これに対処するには、外部コンテンツプロバイダがＫＩＳメタデータキャシュのコンテンツを提供し、それを会社がホストし管理する。例えば、ロイターはインテルのようなクライアントにコンテンツを提供するが、インテルがＫＩＳをホストし管理する。インテルのＫＩＳはロイターのＫＩＳ（これによってＫＩＳサーバをつなぐ）またはロイターのＤＳＡをクロールする。こうすることにより、インテルの機密情報の注釈は、インテルが機密情報データへのコントロールを維持しながら、ロイターのコンテンツを文脈として使って、「ポストイット」として発行できる。
連合注釈
連合注釈は、ユーザが一件のエージェンシー／サーバ（ＫＩＳ）からのオブジェクトに注釈をつけ、別のサーバの「ポストイット」のようなコメント（および／または添付ファイルで）をコメント付きでそのオブジェクトを注釈することを可能にする、大変強力な機能である。例えば、サーバ（サーバＡと呼ぶ）は注釈をサポートしないかもしれない（これは管理者によって設定され、信用と検証可能な識別情報をドメインが持たないインターネットベースのサーバに共通なことかもしれない）。ユーザは文書（またはその他の意味論的結果）をサーバＡから得るが、注釈をサポートする１つ以上エージェンシー（ＫＩＳ）（一般的なのは、信用および検証可能な識別情報のドメインを持つイントラネットまたはエクストラネットベースのエージェンシー）に、そのオブジェクトの注釈を付けることを希望するかもしれない。このようなケースでは、注釈電子メールメッセージには、注釈されるオブジェクトのＵＲＩが含まれる（電子メールメッセージおよび添付ファイルは注釈そのものを含む）。サーバがシステムインボックスをクロールし、電子メール注釈を取得すると、注釈のコード化された宛先または主題フィールドをスキャンし、注釈されるオブジェクトのＵＲＩを抽出する。ＵＲＩが異なるサーバを参照する場合、サーバは次にＸＭＬウェブサービス呼出し（アクセスがある場合）をそのサーバに対して行い、そのオブジェクトのそのＳＲＭＬメタデータを得る。サーバは次にＳＲＭＬメタデータを意味メタデータ格納（ＳＭＳ）に追加し、電子メール注釈からの適切な意味論的リンクをＳＲＭＬオブジェクトに追加する。これはエージェンシーのユーザが注釈を参照し、そのオブジェクトが別のサーバから来たとしても、注釈を付けたオブジェクトに意味論的にナビゲートすることができるため、大変効果的である。
（注釈用の）送信先サーバが、注釈されるオブジェクトが存在するサーバへのアクセスを持たない場合、送信先サーバはクライアントにこれを連絡し、クライアントは次に（オブジェクトが存在する）サーバからのＳＲＭＬを得て、完全なＳＲＭＬを（注釈用の）送信先サーバに戻す。この実施例は、本質的にはクライアントは、送信先サーバにＵＲＩ自体の「逆参照」を試行させる代わりに、まずＵＲＩを「逆参照」しＳＲＭＬを送信先サーバに送らなければならない。この方法は、ＣＰＵおよびＩ／Ｏのロードをクライアント全体に広げるので、（ダウンロードを行いＵＲＩのをＳＲＭＬに「逆解除」を行わなくてはならないのであるから）処理能力上の理由からもより優れている可能性がある。
連合注釈用の意味論的警告
意味論的ブラウザが、（毎分などの）定期的なベースで現在表示されている各オブジェクトと関連ある「ニュース速報」に対して、現在表示されているユーザプロフィールの各ＫＩＳをポーリングするのと同じやり方で、注釈に対しても同じことが行われる。実質的には、これは現在表示されている各オブジェクトが「注釈されたばかり」かどうかのポーリングと似通っている。（注釈するオブジェクトへの強力な意味論的リンクを持つ注釈などの）連合されない注釈に関しては、これは注釈オブジェクトの出所からのＫＩＳへの直接的なＳＱＭＬコールバックである。ただし、連合注釈に関しては、オブジェクトの出所であるＫＩＳは注釈をサポートしないか、特定のオブジェクトに対する注釈を含まないとしても、オブジェクトのコピーは別のＫＩＳ上に注釈されているので、プロセスはもう少し複雑である。
この場合、表示される各オブジェクトに対して、意味論的ブラウザは選択したプロフィールで各ＫＩＳをポーリングし、オブジェクトがＫＩＳに注釈されたかどうかをそのＫＩＳに「訊ねる」ためにオブジェクトのＵＲＩを渡す。これによって、連合注釈に対しても意味論的警告が生成される。
注釈のヒント
これは、ＫＩＳがオブジェクトに注釈が付けられたことを示す文脈属性を返す機能を指す。注釈のヒントは、ＫＩＳが注釈を検出し（一般的にはシステムインボックスから）、意味ネットワークを更新中にキャシュされることができる。属性セットを持つオブジェクトに関しては、クライアントはオブジェクトが注釈されたかどうかをチェックするためＫＩＳを再クエリする必要がないため、この文脈属性はパフォーマンスを最適化させることができる。これは、ＫＩＳへの余分な（そして不要な）往復呼出しを避けるためのオブジェクトの状態のキャッシングを意味する。
注釈に関するもう１つの見方
インフォメーションナーバスシステムの簡単で意味論的な注釈機能の興味深い見方としては、ユーザの知識世界のいかなるオブジェクト／項目／結果にも、各自専用の文脈インボックスを有することである。これで、ユーザがオブジェクトを表示する場合、オブジェクトの文脈に関連するインボックスをいつでも表示できる。つまりは次のようになる。
連合知識コミュニティのカテゴリ命名および識別（ＵＲＩ）
これはカテゴリが連合知識コミュニティ上でどのように命名されるかを指す。例えば、インテルで導入されるロイターの知識コミュニティ（エージェンシー）は、Reuters@Intelのように命名され、そのカテゴリは「Reuters@Intel/InformationTechnology /Wireless/80211」のように命名される。好ましい実施例では、各カテゴリは少なくとも次の特性で修飾される。
・知識ドメインＩＤ − これはカテゴリの出所の知識ドメインを一意に識別する世界的に一意の識別子である
・名前 − カテゴリ名である
・パス − カテゴリの完全な分類法パスである
好ましい実施例では、カテゴリの知識ドメインＩＤ（名前ではない）は、（識別子はそのまま同じものを維持するべきであるが）カテゴリは知識ドメインで発達するに従い名前をつけ直すことができるので、カテゴリＵＲＩの中で使われるのが好ましい。好ましい実施例でのカテゴリＵＲＩの例は次の通りである。
nerv://c9554bce-aedf-4564-81f7-48432bf8e5a0?type=category&path= Information
Technology/Wireless/80211
この例では、知識ドメインのＩＤは、c9554bce-aedf-4564-81f7-48432bf8e5a0
で、ＵＲＩタイプは「カテゴリ」でそのカテゴリのパスは「Information Technology/Wireless/80211」である。
17. 匿名の注釈および発行物
意味論的ブラウザはまた、ユーザが知識コミュニティ（エージェンシー）に匿名で注釈を付け発行することを可能にする。このモードでは、メタデータは（ユーザ識別情報と共に）完全に保存されるが、発行者が匿名のままでいることを希望することを示すフラグが付けられる。こうすることにより、推論エンジンは、完全なメタデータを使って推論できるが、発行者は身元を明かさないように要求できる。逆に管理者は、推論エンジンが匿名の注釈または発行物を使って推論できないよう、知識コミュニティ（エージェンシー）を設定することもできる。
18. 意味論的ブラウザでのオフラインサポート
意味論的ブラウザはオフラインサポートも有する。ブラウザは遠隔呼出しすべてに対してキャシュを有する。キャシュはＸＭＬデータへのエントリを含む。これはＳＲＭＬ、またはＸＭＬウェブサービスへの呼び出しから返ってくるその他データでもあり得る。各呼出しは、意味論的ブラウザによって固有の署名が与えられ、この署名はＸＭＬデータにハッシュするのに使用される。例えば、意味論的クエリはＳＱＭＬによってハッシュされる。その他の遠隔呼出しは、方法名、引数の名前およびタイプ、引数データの組合せを使ってハッシュされる。
ＸＭＬウェブサービスへのすべての呼出しに対して、意味ランタイムクライアントは呼出しの署名を抽出してローカルキャシュのエントリへにマッピングする。ブラウザ（またはシステム）が現在オフラインの場合、クライアントはＸＭＬデータを（存在する場合は）キャシュに戻す。キャシュが存在しない場合、クライアントは呼出し側（プレゼンターの可能性が高い）にエラーを返す。ブラウザがオンラインの場合、クライアントはＸＭＬウェブサービスからＸＭＬデータを取り出して、署名ハッシュが示すファイルパスで、ファイルエントリの以前のコンテンツを上書きしてキャシュを更新する。これは遠隔呼出しが実際に可能であることを想定する。ネットワークの混雑やその他の条件によりシステム/ブラウザがオンラインの場合でもできない可能性がある。そのような場合、キャシュは上書きされない（新しいデータが存在する際にのみ上書きされ、最初に消去されない）。
19. 意味論的ブラウザでの保証付きクロスプラットフォームサポート
概要
当発明者の親出願（通し番号１０／１７９，６５１号）で説明したように、インフォメーションナーバスシステムはクロスプラットフォームで実装することができる。標準プロトコルは可能な場所で用いることが好ましく、ウェブサービス層には相互操作が可能なウェブサービス基準を使い、独自仕様の実装は避けるべきである。本質的には、ウェブサービスが対話中の知識コミュニティ（またはエージェンシー）が特定のプラットフォームで実行中かどうかを「知る」必要はないということである。例えば、意味論的ブラウザは対話中のウェブサービスが（専有のアプリケーションサーバの２つの例である）マイクロソフトの．ＮＥＴ（登録商標）プラットフォームかサンのＪ２ＥＥ（登録商標）プラットフォーム、リナックスまたはその他の「オープンソース」サーバで実行中かを知る必要はない。知識コミュニティのウェブサービスおよびクライアントサーバのプロトコルは、．ＮＥＴ（登録商標）やＪ２ＥＥ（登録商標）などの異なるウェブサービスの実装で一般にサポートされるウェブサービス基準を採用すべきである。
あえて言えば、ウェブサービスのベンダー実装全体で支持され適切に実装される共通した基準一式が存在することが理想である。ただし、現実には難しく、少なくとも今はまだ可能ではない。意味論的ブラウザが異なるウェブサービスの実装における独自の機能性を扱わなくてはならない場合、知識コミュニティのスキーマは、ウェブサービスプラットフォームの実装を示すフィールドを含むよう、拡張されていることが好ましい。例えば、知識コミュニティの．ＮＥＴ（登録商標）実装は、プラットフォームが．ＮＥＴ（登録商標）であることを示すフィールド付きで発行されるのが好ましい。同じことがＪ２ＥＥ（登録商標）にも当てはまる。そうすれば、意味論的ブラウザが、（ＷＳＤＬ ＵＲＬ経由で直接知識コミュニティへ、マルチキャスト、エンタープライズディレクトリ（ＬＤＡＰなど）、グローバル知識コミュニティなど通じて通知を受けることによって）知識コミュニティのメタデータを取得する際に、このフィールドにアクセスすることができる。
意味論的ブラウザはその後に、知識コミュニティが実行中のプラットフォームによって、プラットフォーム固有の呼出しを発することができる。プラットフォーム固有の呼び出しを行うことが絶対に必要である場合以外ではこれは薦められる方法ではない。このモデルは好ましい実施例で用いられることが好ましい。
20. 知識モデル化
知識モデル化とは、エンタープライズがインフォメーションナーバスシステムを導入する上で薦める方法を指す。これには（高度の知識ドメインごとに）いくつかのＫＩＳサーバと、関連するオントロジーおよび分類化をホストする１つ（または多くて数個）のＫＤＳ（旧ＫＢＳ）のサーバの導入が関係する。狭すぎるためにネットワークでのナビゲーションと推論の充分な知識共有の可能性がないのと、高すぎるために（データベースおよび／または推論エンジンが必要とする格納とＣＰＵの馬力における）スケーラビリティが問題となる場合の間のバランスを取るよう、ＫＩＳサーバはドメインごとに導入することが好ましい。もちろん、具体的なバランスポイントは、ハードウェアとソフトウェア技術の発達に伴い経時変動するが、好ましい実施例では特定のバランスに依存するものではない。また、ＫＩＳサーバは、複数のグループが同じＫＩＳを共有するグループレベルでアクセス制御を強いるのではなく、（より高度のセキュリティのために）サーバレベルでアクセス制御が必要になるポイントで実装されることが好ましい。例えば、大手の医薬品会社は、会社全体のオンコロジーに知識コミュニティのＫＩＳを有し、別のＫＩＳを先端のＲ＆Ｄに従事する研究者や戦力的特許出願用意有することができる。これら２つのＫＩＳは、同じ情報ソースをクロールするかもしれないが、Ｒ＆Ｄのグループからのユーザのみにアクセスを提供するため、後者のＫＩＳのほうがより安全である。また、オプションとしては、これらの研究者の発行物や注釈を企業のＫＩＳでは参照不可能にできる。
図７は、医薬品会社用に考えられる知識アーキテクチャの実施例を示す。図７で示すように、ＫＤＳは次のようにいくつかの付属ＫＩＳを扱える。
クライアント
知識統合サーバ１（オンコロジー）
知識統合サーバ２（薬理学）
知識統合サーバ３（バイオテクノロジー）
知識統合サーバ４（心臓学）
知識ドメインサーバ（医薬品）
21. ＫＩＳハウスキーピングの規則
知識統合サーバ（Ｋｎｏｗｌｅｄｇｅ Ｉｎｔｅｇｒａｔｉｏｎ Ｓｅｒｖｅｒ、ＫＩＳ）は、管理者が「ハウスキーピング」規則を設定して、古いか廃れたメタデータを消去することを可能にする。これによってＫＩＳ上のＳＭＳが無限に大きくなることを防ぐ。この規則は一定の年数（会社の旧データ保管方針によって２−５年の間）よりも古いく、注釈がなく、お気に入りとしてマークされない（または格付けされない）メタデータを消去するという簡単なものでもよい。
22. クライアントのコンポーネント統合およびワークフローの相互作用
システムのクライアントコンポーネントは、ワークフローの相互作用または使用パターンが統合できるように、いくつかの異なる手順または順序で統合できる。本発明の好ましい実施例では、ワークフローおよびコンポーネントの統合は次のように行われる。
1) シェル：ユーザはＵＩナビゲーションまたはウィザードを通じて、潜在的にＳＱＭＬクエリ（エージェントなど）を作成する。
2) シェル：ユーザが（ツリーまたはフォルダの参照経由で）エージェントをオープンする。
3) クエリバッファはファイルとして保存され、作成されたレジストリのエントリはエージェント用に作成される。
a) レジストリのエントリには次が含まれる：エージェント名、作成日、エージェント（リクエスト）− ＧＵＩＤ、ＳＱＭＬパス、コメント、ネームスペースオブジェクトタイプ（エージェンシー、エージェント、ブレンダーなど）および属性
4) シェル：リクエストはプレゼンターに渡される。
a) レジストリリクエストのＧＵＩＤエントリは、(リクエストを生成したネームスペースパス、ＳＱＭＬファイルＵＲＬ)を含めて作成される。
b) ブラウザを初期化し、http://PresenterPage.html#RequestGUID http://presenterpage.html/のコマンドラインとともに開く。プレゼンターは、ページに含まれるデフォルトのクロムをロードする。
c) プレゼンターページはプレゼンターのバイナリ動作と意味論的ランタイムＯＣＸをロードする。
5) プレゼンター：ＳＱＭＬをロードし、クエリマネージャを通じてリクエストを発行する。
a) ＳＱＭＬファイルパスを得るために、リクエストＧＵＩＤを解決する。
b) ＳＱＭＬファイルをバッファにロードし、リソースハンドラのリクエストを作成し、それらをリソースハンドラに渡し、結果を待ち収集する。ローカルリソースの要約はここで発生する。すべての要約は次の２つのパスのうち１つに従う。このファイルパスが示すｄｏｃを要約するか、（クリップボード、アウトルック、エクスチェンジなどから抽出された）そのテキストを要約する。両方のパスは、意味サーバＸＭＬウェブサービスへのリクエストに含むのに適するように、同じ形式で要約を作成する。
c) 上記の任意のリソース要約など、ＳＱＭＬファイルを個別のサーバリクエストバッファにコンパイルする。
d) 意味論的ランタイムクライアントのクエリマネージャを呼び出してサーバリクエストを開始する。
6) クエリマネージャ：サーバリクエストを監視し、データのコールバックを行う。また、要求があり次第イベントの完了またはタイムアウトを伝達する。コールバックはプレゼンターへ入るが、これはＸＭＬを渡すプロセス間のメッセージ伝達を意味する。
7) プレゼンター：データを受信し適切なスキンをロードする。
a) ＳＲＭＬデータをバッファで受け取る。これはインクリメントで行われる。
b) このエージェントに関連する好ましいスキン（スマートスタイル）があるかどうかを判断し、なければデフォルトのスキンを選択する。
c) ＸＳＬＴを通じてＳＲＭＬを好ましいスキンフォーマットに変換する。これは結果が出るに従い、結果のツリーは多段式である（ルートはリストで、次にオブジェクトでディープ／レンズ／ＢＮ情報）。
d) 結果をターゲットＤＩＶでページに表示する。ターゲットは動作自体への引数であり、ルートページにより定義される。
8) プレゼンター：意味論的ランタイムを呼出して、（文脈テンプレートごとの）文脈パネル、ディープインフォメーション、スマートコピー＆ペーストその他意味論的コマンドで埋める。プレゼンターはまた、スマートスタイルをロードし、次にリクエストの意味と一致する意味論的画像、動きなどをロードする。
図８は、上記で説明した本発明の好まれるクライアントコンポーネント統合およびワークフローの相互作用を示す。
23. カテゴリ・ダイアログボックスのユーザインタフェース仕様
ａ. 概要
カテゴリ・ダイアログボックスで、ユーザは知識ドメインに属するカテゴリフォルダ（または分類法）から、１つ以上のカテゴリを選択することができる。状況によっては実施できる数に多少の違いはあるが、好ましい実施例では、ダイアログボックスは以下のユーザインタフェース制御の全てを備える。
１. プロフィール − ユーザは設定された関心のある分野に基づき、カテゴリ・フォルダ（または分類法）をフィルタリングするためのプロフィールを選択できる。例えば、プロフィールに関心のある分野が「健康と医療」と設定してある場合、そのプロフィールを選択することによって「健康と医療」の関心分野に属するカテゴリフォルダ（例えば、医薬品、ヘルスケアおよび遺伝子）が表示される。この制御によって、ほかのドメインの分類法を見ることなく、ユーザの知識ドメインに関連する分類法に焦点を置くことができる。
２. 関心のある分野 − これによってユーザは関心のある特定の分野を選択できる。デフォルト設定では、コンボボックスは「私の関心のある分野」と設定され、プロフィールのコンボボックスは「全プロフィール」と設定されている。これによって、ダイアログボックスは全プロフィールの全関心のある分野のカテゴリフォルダを表示する。ただし、「関心のある分野」コンボボックスを使うことにより、ユーザは、自分のプロフィールに設定されている関心のある分野に関係なく、関心のある分野を直接指定し、それによってカテゴリフォルダをフィルタリングすることができる。
３. 発行者のドメインゾーン／名称 − これによってユーザは、分類法発行者のドメインゾーンと名称を選択できる。名称が不一致の可能性がある発行者を区別するのに有益である。好ましい実施例では、発行者のドメイン名には、ＤＮＳ命名スキームを使う（例えば、ＩＥＥＥ．ｏｒｇ、Ｒｅｕｔｅｒｓ．ｃｏｍ）。ドメインゾーンで、ユーザはドメイン名の範囲を選択することができる。好ましい実施例では、その選択はインターネット、イントラネットおよびエクストラネットである。ゾーン選択は、発行されたカテゴリ・フォルダ（または分類法）をさらに区別する。かなり一般的なケースは、大手企業の一部門で専用の社内分類法を有する場合である。この際、その部門はイントラネット・ドメイン・ゾーンが割り当てられ、（例えば、Intranet＼Marketing、 Intranet＼Salesといった）独自のドメイン名を持つ。
４. カテゴリフォルダ − これによってユーザは、カテゴリフォルダあるいは分類法の選択をすることができる。この選択が行われると、選択したカテゴリフォルダのカテゴリが、カテゴリのツリービューに表示される。
５. 検索カテゴリ − これによってユーザは、現在表示されているカテゴリをフィルタリングするため、１つ以上のキーワードを入力することができる。例えば、医薬品研究者は医薬品分類法を選択でき、次にキーワード「解剖学」を入力してキーワード「解剖学」を含む分類学内のエントリのみを表示できる。
６. 「記憶」チェック・ボックス − これでユーザは、ダイアログボックスを終了する際に最後の検索を「記憶「」するべきかどうかを指定できる。ユーザが多くの同類のカテゴリベースの検索／リクエストを同じカテゴリフォルダから同じキーワードのフィルタリングで行いたい場合に役立つ。
７. 検索オプション − これは、ダイアログボックスがキーワードをどう解釈するべきかをユーザに指定させることができる。このオプションでは、分類法ツリーの各エントリの全階層にキーワードを適用させるべきか、またはキーワードをエントリの［末端］名称のみに適用するべきかをユーザに選択させる。例えば、階層に「解剖学」という単語が含まれるため、分類法のエントリ「解剖学＼細胞＼クロム親和＼細胞」は階層フィルタリングに含まれる。ただし、末端名（「クロム親和細胞」）には「解剖学」という単語が含まれないため、名称フィルタリングからは排除される。
また、検索オプションによって、ユーザはダイアログボックスのすべてのキーワード、任意のキーワード、または全く同じフレーズのどれをチェックするべきかを選択することができる。
８. カテゴリのツリービュー − ツリービューは、分類法階層を表示し、ユーザが１つ以上の項目を選択してリクエスト作成ウィザードに追加するか、新規ドシェ（ガイド）リクエスト／エージェントとして開くことを可能にする。ユーザインタフェースは、パフォーマンス上の理由から、カテゴリ階層を「カテゴリページ」に分割する。ＵＩはユーザに、ボタンとスライド制御を通じてページをナビゲートすることを可能にする。また、現在選択された分類法項目をすべて非選択状態にする「すべてを選択解除」のボタンがある。
９. 探索ボタン − これはダイアログボックスの主要呼出しボタンである。ダイアログボックスがリクエスト作成ウィザードで起動されると、このボタンは「追加」に変わり、選択項目をウィザードの「フィルタリング」特性ページに追加する。ダイアログボックスがアプリケーションから直接起動されると、ボタンは「探索」と称され、そのボタンをクリックすると、選択したカテゴリ上でドシェリクエストが起動する。ユーザが複数のプロフィールを持つ場合、または複数の分類法カテゴリが選択される場合、ダイアログボックスは別のダイアログボックス「探索カテゴリのオプション」を起動し、そこでドシェを起動させるプロフィールおよび／またはドシェへのフィルタ（ＡＮＤまたはＯＲ）としてカテゴリを適用する際に使用する演算子を選択するようにユーザに促す。
上記に説明した機能を図９−１１で、探索カテゴリのダイアログボックスの三つの異なるビューで示す。
24. クライアント支援によるサーバデータの整合性チェック
サーバ（ＫＩＳ）が知識ソースをクロールするにつれて、サーバのメタデータのキャシュがソース自体と非同期になる場合がある。例えば、ウェブを定期的にクロールするＫＩＳ上のウェブクローラが、エントリを期限の切れたメタデータ格納（ＳＭＳ）に追加する場合がある。この場合、クライアントはソースＵＲＩを呼び出そうとする際にエラー４０４番を受け取る。監視能力（例えば、変更を監視できるファイル共有用）を有するデータソースアダプタ（ＤＳＡ）に関しては、ＫＩＳは知識ソースと同期である可能性が高いため、それほど問題とはならない。ただし、監視／変更通知サービスを持たないウェブサイトなどのソースに関しては、これが問題となる可能性がある。
当発明者の親出願（通し番号１０／１７９，６５１号）には、ＫＩＳがどのように整合性チェッカー（ｃｏｎｓｉｓｔｅｎｃｙ ｃｈｅｃｋｅｒ 、ＣＣ）を使って廃れたエントリを定期的にＳＭＳから消去できるかを説明している。ただし、ＣＣは定期的にＳＭＳ全体をスキャンし、インデックス付きオブジェクトがまだ存在するかどうかを確認しなくてはならないため、状況によっては処理能力に障害を生じる可能性がある。この発明の機能の代替実施例では、クライアント（意味論的ブラウザ）は、エラー４０４番を受け取るとクライアント（意味論的ブラウザ）に通知する。これを行うには、意味論的ブラウザはユーザが「開く」各結果に対して、いつエラー４０４番を受け取るかを追跡しなければならない。ウェブ文書に関しては、ユーザが結果を開く前でも、クライアントが結果を表示する際にＨＴＴＰヘッダのポーリングをすることができる。この場合、ソースウェブサーバがエラー４０４番（オブジェクト不明）を報告すると、クライアントはこれをＫＩＳに報告する。
ＫＩＳは「４０４番報告」をクライアントから受けると、オブジェクトがこれ以上使用できないのかどうかを知的に決定する。４０４番のエラーが断続的なウェブサーバの故障によるものである可能性があるため（例えば、ウェウサーバ上のディレクトリが一時的に不能になる場合がある）、ＫＩＳはオブジェクトを独断で削除することはできない。ＫＩＳ自体は、オブジェクト（または最低、ウェブオブジェクトの場合のＨＴＴＰヘッダ）を非同期的に数回（５回など）ダウンロードする試みをすべきである。各試行が失敗すると、ＫＩＳはオブジェクトがもはや入手できないと結論付け、ＳＭＳからそのオブジェクトを削除する。別のクライアントが、ＫＩＳがダウンロードを処理中に同じオブジェクトに対してエラー４０４番を報告する場合、ＫＩＳはそのレポートを（重複しているため）無視すべきである。
この代用技法は、遅延整合性チェックとしておおよそ特徴付けられる。状況によっては、有利で好まれる場合がある。
25. クライアント側の重複検出
サーバ（ＫＩＳ）は、新規オブジェクトを意味論的メタデータ格納（ＳＭＳ）に追加する前に、ソースＵＲＩをチェックすることにより重複検出を行う。ただし、処理能力上の理由から、サーバが厳格な重複検出を行わないほうが有利なことがある。そのような場合には、重複検出はクライアント側で行われることが好ましい。さらには、クライアントはいくつかのＫＩＳからの結果を連合させるため、クライアントが重複部分を異なるＫＩＳから得る可能性がある。このように、クライアントにとっても重複検出を行うことは有益である。
好ましい実施例では、クライアントは確実に重複しているものを除去し、重複している可能性があるオブジェクトをフラグで警告を出す。確実な重複とは、ＵＲＩ、最後に変更した時間のスタンプ、要約／概念およびサイズが同じオブジェクトである。重複の可能性があるとは、同じ要約／概念を有するが、ＵＲＩ、最後に変更した時間およびサイズが異なる場合である。要約抽出が難しいオブジェクトに対しては、タイトルを使って重複の可能性を使ってチェックすることを薦める（要約はオブジェクトの内容の信頼できる指標ではない場合があるため、要約は同じだがタイトルが異なるオブジェクトは重複の可能性があるとは考えられない）。また、（意味論的重複／余剰を検出するための）要約／概念の抽出が難しい場合、意味論的ブラウザはファイルサイズのチェックを、±Ｎ％（±５％など）に限定できる。例えば、同じ要約／概念と、異なるＵＲＩ、最後に変更した時間を持つオブジェクトは、ファイルのサイズが重複チェック用に比較されるオブジェクトのそれの５％範囲内であれば、重複の可能性ありとして不適格になる可能性がある。
26. クライアント側の仮想結果カーソル
クライアント（意味論的ブラウザ）は、ユーザプロフィールに登録された複数の知識コミュニティ（エージェンシー）が存在する場合、ユーザにシームレスな経験を提供する。意味論的ブラウザは、一箇所のソースで発生したかのように結果を提示することが好ましい。同様に、ブラウザはユーザに１つのナビゲーションカーソルを提示することが好ましく、ユーザがスクロールすると、意味論的ブラウザがさらに多くの結果を得るためにＫＩＳをクエリし直す。好ましい実施例では、意味論的ブラウザは再クエリが頻繁に行われることを防ぐのに充分な大きさの結果キャシュを維持する。例えば、キャシュは５−１０スクロール（ページ）の結果を扱えるように初期化できる。キャシュサイズは、メモリを考慮に入れて上限を決めることが好ましい。カーソルが前進（または後進）するに従い、ブラウザは現在のページがキャシュヒット、あるいはミスを生成するかどうかをチェックする。キャシュヒットを生成する場合、ブラウザはキャシュからの結果を提示するが、そうでなければ、追加の結果を得るためにＫＩＳを再クエリし、それをキャシュに追加する。
キャシュは無限大に増化する、またはスライドウィンドウに実装することができる。前者のオプションには実装の簡潔さという利点と、大量メモリ消費の可能性という欠点がある。後者のオプションは好ましい実施例であるが、少量メモリ消費と高いキャシュ整合性という利点があるが、さらに複雑な実装を要するという代償を伴う。スライドウィンドウでは、意味論的ブラウザはウィンドウ内に収まらないページの結果を消去する（その他の実施例での全ページに対して、最後のＮページ（５−１０ページなど）。
27. 仮想単一サインオン
クライアント（意味論的ブラウザ）はまた、登録した知識コミュニティ（エージェンンシー）へのユーザ認証の際に、シームレスなユーザ体験を提供する。発明者が呼ぶところの「仮想単一サインオン」を経由してこれを行う。このモデルでは、ユーザが知識コミュニティごとに自分のユーザネームやパスワードを入力する必要なく、意味論的ブラウザは知識コミュニティへのユーザ認証を行うことができる。一般には、ユーザは数個のユーザネームおよびパスワードを有するが、（特に部門またはグループアクセスに基づく社内の場合や、インターネットベースの知識コミュニティ上で）属する知識コミュニティが多くある可能性がある。このように、（ユーザごとの）認証の資格情報数に対する知識コミュニティ数の比率は大変高くなりやすい。
仮想単一サインオンでは、ユーザは、サーバ（知識コミュニティ）から独立した方法で意味論的ブラウザへの自分のログオン資格情報を指定する。意味論的ブラウザは資格情報を資格キャシュテーブル（クレデンシャルキャッシュテーブル、ＣＣＴ）に保存する。ＣＣＴは以下に示すコラムを有する。
アカウント名 ユーザ名 パスワード 知識コミュニティのエントリリスト
・アカウント名 − アカウントの親しみやすい名称である
・ユーザ名 − ログオンのユーザ名である（電子メールアドレスなど）
・パスワード − 安全なプライベートキーを使って暗号化して保存したパスワードである。
・知識コミュニティエントリリスト（Ｋｎｏｗｌｅｄｇｅ Ｃｏｍｍｕｎｉｔｙ Ｅｎｔｒｙ Ｌｉｓｔ、ＫＣＥＬ） − このアカウントの資格情報を使ってユーザを認証する、知識コミュニティのリスト
ユーザがまず知識コミュニティに登録を試みる（またはコミュニティの特性を得るために、ほかの方法で知識コミュニティにアクセスする）と、意味論的ブラウザはユーザにパスワードを入力するよう促し、入力された資格情報を使ってサーバにログオンを試みる。ログオンに成功すると、意味論的ブラウザは入力された資格情報を使って新規ＣＣＴエントリ（ＣＣＴＥ）を作成し、新規ＣＣＴエントリに対するＫＣを知識コミュニティエントリリスト（ＫＣＥＬ）に追加する。
その後の登録試行に関しては、意味論的ブラウザはＣＣＴをチェックして、ユーザが登録しようとしているＫＣが任意のＣＣＴＥのＫＣＥＬに存在するかどうかを調べる。存在する場合、意味論的ブラウザはＣＣＴＥへの資格情報を取得し、それらの資格情報でユーザをログオンさせる。こうすることによって、ユーザは自分のログオン資格情報を重複して入力する必要がない。
ここで留意すべきは、オペレーティングシステムがすでにドメインにログオンされている際には、意味論的ブラウザはパススルー認証もサポートする点である。例えば、ウィンドウズのマシンがすでにＮＴ（またはアクティブディレクトリ）ドメインにログオンされている場合、クライアント側のウェブサービスプロキシにも、ＫＣへのログオンを試行するための既定の資格情報が含まれている。好ましい実施例では、ユーザが入力した追加の資格情報は、（ウェブサービスセキュリティ（ＷＳセキュリティ）または同類のスキーム経由で）ＳＯＡＰセキュリティヘッダを経由して渡されるのが好ましい。ＷＳセキュリティおよびＳＯＡＰヘッダに認証情報を渡すことに関しては、http://www.oasis-open.org/committees/download.php/3281/WSS-SOAPMessageSecurity-17-082703-merged.pdfを参照されたい。
意味論的ブラウザは、ＣＣＴＥ用のＫＣＥＬが空のときにＣＣＴＥ用の資格情報を消去するのが好ましいか、保存するべきかをユーザに示させるための特性を公開する。好ましい実施例では、ユーザがその反対を示さない限り、資格情報はデフォルト設定で保存することが好ましい。ユーザが資格情報を消去したい場合、意味論的ブラウザは、ＫＣがブラウザのどのプロフィールにも登録されていないときにＣＣＴＥ内に存在するそのＫＣをＣＣＴＥから削除する。ＫＣをＣＣＴＥのＫＣＥＬから削除した後でＣＣＴＥが空になると、ＣＣＴＥはＣＣＴから除去されることが好ましい。
仮想単一サインオン機能は、本出願の多くの特性と同様、当発明者のインフォメーションナーバスシステムまたは仮想ライブラリアン以外のアプリケーションでも使える。例えば、１つ以上のドメインにログインする必要のあるコンピュータユーザによる使用のために適応させることができる。
28. ネームスペースオブジェクトのアクションマトリックス
以下のテーブルは、ネームスペースオブジェクトがコピーされその他のネームスペースオブジェクトにペーストされる際に、意味論的ブラウザが呼び出すアクションを示す。
Figure 2006522388
29. 動的エンド−ツー−エンドオントロジー／分類化の更新および同期化
インフォメーションナーバスシステム（登録商標）は、オントロジーおよび分類化の動的更新をサポートする。ナバナが発行する（またはサードパーティオントロジー発行者によってナバナに提供される）知識ドメインのプラグインは、ナバナウェブドメイン（Ｎｅｒｖａｎａ．ｃｏｍ）上の中央ウェブサービス（オントロジーデポ）でホストされる。各ＫＤＳは次に、ウェブサービス呼出しを通じて中央ウェブサービスを（ＵＲＩが参照するそれぞれの知識ドメインプラグイン、またはプラグインの全体的に固有な識別子に対して）定期的にポーリングし、プラグインが更新されたかどうかをウェブサービスに「訊ねる」。ウェブサービスは、最後に変更されたオントロジーファイルの時間スタンプを使って、プラグインが更新されたかどうかを判断する。プラグインが更新された場合、ウェブサービスは、呼び出しているＫＤＳに新しいオントロジーファイルを返す。ＫＤＳは次にそれを持っているオントロジーファイルと置き換える。
更新中にＫＤＳが稼動している場合、ファイル変更通知をサポートしオントロジーを再ロードする（これが推奨する実装である）ことをしない限り、ファイルを置換する前に、通常はサービスを一時的に停止する。
また、各ＫＩＳは接続先の各ＫＤＳをチェックして、各ＫＤＳのオントロジーが変更されたかどうかをＫＤＳに「訊ねる」必要がある。好ましい実施例では、ＫＤＳが別のオントロジーバージョンを有する場合を考えて、ＫＩＳは中央ウェブサービスでなく、ＫＤＳをポーリングすべきである。ＫＤＳはまた、知識ドメインプラグイン（オントロジー）の最後の変更時間スタンプを使って、オントロジーが変更されたかどうかを決定する。次にその決定をＫＩＳに示す。オントロジーが変更された場合、ＫＩＳは意味論的ネットワークをそれに従って更新する必要がある。好ましい実施例では、オントロジーの新バージョンにないカテゴリを参照する意味論的リンクを削除し、オントロジーの新バージョンに基づき意味論的リンクを追加／変更することによりこれを行う。代替実施例では、意味ネットワークを消去し、インデックスを再作成する。
クライアントは次に、登録されている分類法が（中央ウェブサービスまたはＫＩＳ経由で直接）変更されたかどうかを決定するために、登録先の各ＫＩＳをポーリングする。ＫＩＳは、分類法が（分類法／オントロジープラグインファイルの最後の変更時間スタンプ経由で）変更されたかどうかクライアントが決めるＸＭＬウェブサービス経由で、メソッドを公開する。分類法が変更された場合、クライアントは新規分類法を示すために、カテゴリのダイアログユーザインタフェース（およびその他ＵＩベースの分類法依存物）を更新する必要がある。
中央発行される分類法に関しては（ナバナ経由など）、クライアントは分類法を更新するために、中央ウェブサービスをポーリングする必要がある。
このモデルによって、クライアント、ＫＩＳ、ＫＤＳおよび中央分類法／オントロジーデポは同期化され維持される。
30. ドシェ（ガイド）クエリの呼出し
ドシェ意味論的クエリの処理
ドシェ（ガイド）クエリは、リクエスト／エージェントのＳＱＭＬを構文解析し、ドシェ文脈述語を各特別エージェントの（文脈テンプレート）文脈述語（全可能性、最も高い可能性、ニュース速報、見出し、任意の可能性、新聞ダネになる人など）によって置き換えることにより、クライアント側の意味論的クエリプロセッサから呼び出すのが好ましい。（文脈テンプレートごとの）各クエリは次に、クエリプロセッサ経由で個別クエリと同様に呼び出される。こうして、ユーザはドシェのレベルで操作するが、意味論的ブラウザは裏でドシェを個別クエリにマッピングする。
例えば、「カテゴリＣに関するドシェ」のＳＱＭＬは構文解析され、新しいＳＱＭＬクエリが次のように生成される。
・カテゴリＣに関する全可能性
・カテゴリＣに関する最も高い可能性
・カテゴリＣに関するニュース速報
・カテゴリＣに関する見出し
・カテゴリＣに関する任意の可能性
・カテゴリＣに関する新聞ダネになる人
・その他
クライアント側の意味論的クエリプロセッサは、文脈述語を除くすべての述語を維持する。こうして上記の例で示すように、フィルタは一貫性を維持する。
ドシェスマートレンズ
インフォメーションナーバスシステム（登録商標）のその他のリクエスト／エージェントのように、ドシェ（ガイド）はスマートレンズとして使える（ドラッグ＆ドロップ、スマートコピー＆ペーストなどの対象になるのと同じである）。この場合、スマートレンズは各文脈テンプレート（特別エージェント）の部分／タブ／フレームで「ドシェ・プレビューウィンドウ」を表示する。ドシェスマートレンズのＵＩを示す、ドシェのスクリーンショット例を図１２と１３に示す。
ドシェスクリーンショット例
31. 知識コミュニティ（エージェンシー）の意味論
以下で、意味論的ブラウザの意味ネームスペース／環境の文脈内での知識コミュニティ（エージェンシー）の意味論を説明する。
1. 知識コミュニティの選択 − これでＫＣからのドシェリクエストを開く。本質的に、ドシェはＫＣの「ホームページ」に相当する。
2. ＫＣにドラッグ＆ドロップ（文書、テキスト、エンティティ、キーワードなど）する − ＫＣからの（デフォルトの述語を使って）オブジェクトに関するドシェリクエスト／エージェントを開く。
3. ＫＣをクリップボードにコピーする − これでＫＣをスマートレンズとして選択する。ユーザが結果またはエンティティ上にマウスを合わせると、意味論的ブラウザはカーソルの下でＫＣ名とＫＣのプロフィール名を示すことでスマートレンズを表示し、レンズプレビューペイン内のレンズの下のオブジェクトに関してＫＣからのドシェを開く。
4. ＫＣに登録する − ＫＣが初めて登録される際、意味論的ブラウザはＫＣの電子メールアドレスをローカル電子メール連絡先（マイクロソフトアウトルックまたはアウトルックエクスプレスなど）へ追加する。これはユーザが統合連絡先リスト経由で）電子メールで送ることで知識をＫＣに発行するのが簡単になる。同様に、ＫＣが全プロフィールより登録解除されると、意味論的ブラウザはＫＣをローカル電子メール連絡先リストから削除するべきかどうかをユーザに入力を促す。
32. 動的オントロジーと分類法のマッピング
分類法およびオントロジーの使用に際しての課題の１つは、１つの分類法／オントロジーから別の分類法／オントロジーへ意味をどうマッピングするかである。インフォメーションナーバスシステム（登録商標）はこれを以下のアルゴリズムによって達成する。
各ＫＤＳは（オントロジーマッパー（ＯＭ）経由で）オントロジーマッピングを担当し、オントロジーマッピングテーブル（ＯＭＴ）で中央ウェブサービス（オントロジーデポ）を定期的に更新する。更新は双方向性である。ＫＤＳは中央ウェブサービスからオントロジーと分類法を定期的に更新し、ＯＭＴの更新を中央ウェブサービスへ送信する。各ＯＭＴは異なるが、中央オントロジーデポは全ＯＭＴをマスタＯＭＴに統合する。ユーザは関連性があるが重複する包括的な分類法の全項目を選択する必要がないめ、オントロジーマッパーは、一貫性のあるユーザ経験を作成する。意味論的ブラウザは自動的にこれを扱う。ＫＩＳはマッパーの概念がまったくないが、ＫＤＳからのマッピングされた結果を取り込み、これを使って意味ネットワークを更新する。
ＫＤＳとＫＩＳの管理者は依然として、各オントロジー／分類法の質に基づいて正しいＫＤＳオントロジープラグインを選択する責任がある（オントロジーマッピングはオントロジーを改善するのではなくマッピングするに過ぎない）。
33. 意味論的警告の最適化
意味論的ブラウザの意味論的警告は、以下の規則を用いると（この順で）最適化できる。
任意のフィルタに対して（結果、文書、テキスト、キーワード、エンティティなど）次を行う。
1. 見出しをまずチェックする。
2. 見出しがある場合は、ニュース速報および新聞ダネになる人をチェックする。
これは好ましい実施例では、より大きな時間の枠がある以外は、ニュース速報は見出しと同じように実装されるからである。その結果、見出しがない場合は（好ましい実施例ではそうであるが）、ニュース速報は存在しない。また、好ましい実施例では、新聞ダネになる人は見出しの作成者を返すことで行われる。このように見出しがない場合は、ニュース速報も存在しない。
34. 意味論的「ニュース」画像
コービス（Ｃｏｒｂｉｓ、ｈｔｔｐ：／／ｗｗｗ．ｃｏｒｂｉｓ．ｃｏｍ）とゲティイメージス（Ｇｅｔｔｙ Ｉｍａｇｅｓ、ｈｔｔｐ：／／ｗｗｗ．ｇｅｔｔｙｉｍａｇｅｓ．ｃｏｍ）の両方には、常に新鮮さを保つ「ニュース」画像が含まれる。インフォメーションナーバスシステム（登録商標）は、このような種類の画像を文脈依存的だけでなく「新鮮な」意味論的画像として使用することができる。これはユーザのインタフェースを興味深く「新鮮に」保つ上で都合が良い。例えば、「ＳＡＲＳに関するニュース速報」は、医薬品画像だけでなく最近のＳＡＲＳ発生に対応する医者の画像も示すことができる。
35. 意味論的画像の動的選択
意味論的画像を以下の規則を使って動的かつ知的に選択できる。
１．現在表示されているネームスペースのオブジェクトがリクエストである場合、カテゴリ用のオブジェクトのＳＱＭＬを構文解析する。カテゴリが存在する場合、カテゴリを（意味論的画像キャシュをホストする）中央ウェブサービスに送信し、カテゴリに関連する画像を取得する。また、（全ての可能性および見出しなどの知識タイプ、またはプレゼンテーションなどの情報タイプなどの）リクエストタイプを中央ウェブサービスへ送信して、リクエストタイプと一致する画像を返す。
２．ネームスペースのオブジェクトがリクエストでない場合、現在のプロフィール（利用可能であれば）の関心のある分野を中央ウェブサービスに送信する。ウェブサービスは次に、プロフィールの関心のある分野と一致する意味画像を返す。プロフィールに関心のある分野の設定がない場合、アプリケーション（意味論的ブラウザ）の関心のある分野を送信する。アプリケーションに関心のある分野の設定がない場合、空の文字列を中央ウェブサービスへ送信する。この場合、中央ウェブサービスは汎用の画像（ブランド商標画像など）を返す。
36. 動的知識コミュニティ（エージェンシー）の連絡先メンバーシップ
知識コミュニティ（エージェンシー）にはメンバー（コミュニティへ読込み、書込みをしたことがあるか、読込み−書込みアクセスを持つユーザ）と連絡先が含まれる。連絡先はコミュニティに関連するユーザであるが、必ずしもメンバーではない。例えば、大企業の一部門の知識コミュニティでは、部門の所属社員をＫＣのメンバーとして有する可能性があるが、企業の全社員を連絡先としている可能性もある。連絡先は、ＫＣのメンバーにＫＣに意味論的に関連していてもメンバーでないかもしれないユーザをナビゲートさせることができるので有利である。ＫＣは連絡先からの送信を意味論的にインデックス付けする可能性がある。この場合のインデックスには、ＫＣのメンバーでなくても連絡先が含まれる。
これを他の角度から見ると、現実の知識コミュニティには中核メンバーと周辺メンバーが含まれる傾向がある。中核メンバーはコミュニティで大変活発なユーザであり、周辺メンバーには知識愛好家、たまの寄稿者、メンバーになる可能性がある者およびその他関係コミュニティのメンバーなどの「その他」ユーザが含まれる。
インフォメーションナーバスシステム（登録商標）での動的ＫＣ連絡先を使って、ＫＩＳは意味論的メタデータ格納（ＳＭＳ）の連絡先テーブルと意味ネットワークに「見つけた時にそのまま」ユーザを追加する（つまり、メンバーでない新規ユーザを有する電子メールメッセージがあるごとにインデックスを付ける）。これによってコミュニティは連絡先を動的拡張できるが、メンバーと単なる連絡先を区別し、（検索の実行などの）システム運用の際にその区別の重要性を意味論的に「理解」している。
37. 統合されたフルテキストのキーワードとフレーズのインデックシング
ＫＩＳはまた、概念（キーフレーズ）とキーワードを意味ネットワークのファーストクラスメンバーとしてインデックス付けする。これは以下のようなドメインから独立した方法で行うことができる。
意味ネットワークに追加されるそれぞれの新規オブジェクト（文書など）に対して次を行う。
1. オブジェクトの本文から概念（キーフレーズ）を抽出する。
2. 各概念に対して、オブジェクトタイプＩＤをOBJECTTYPEID_CONCEPTで概念を意味ネットワークに追加する。新規オブジェクトを主題として、および新規概念オブジェクトをその主題として「意味論的リンク」テーブルに意味論的リンクに述語PREDICATETYPEID_CONTAINSCONCEPTで追加する。
3. 現在の概念に関しては、概念キーフレーズからキーワードを抽出し、各キーワードをオブジェクトタイプIDOBJECTTYPEID_KEYWORDで意味ネットワークに追加する。新規オブジェクトを主題として、および新規概念オブジェクトをその主題として「意味論的リンク」テーブルに意味論的リンクに述語PREDICATETYPE_CONTAINSKEYWORDで追加する。
上記の手順をオブジェクトのタイトルとオブジェクトのスキーマに適切なその他メタタグ用に繰り返す。
一部の実施例では統合されたフルテキストのインデックシングを必要としないが、現在の好ましい実施例では、次のようないくつかの有用な利点を提供するため含まれている。
1. （ＳＱＭＬで）意味フィルタリングを実装するための一貫性あるモデルを可能にする。ユーザはカテゴリ、文書、エンティティおよびキーワードをフィルタとして追加でき、フィルタは（サブクエリとして）意味ネットワークに常に適用される。
2. 特にエンティティの意味論的クエリ処理をサポートする。エンティティはカテゴリで定義でき、（キーワードが異なる文脈では異なる意味となりえる場合に、キーワードを明確化するために）キーワードでさらに絞られる。統合されたフルテキストのインデックシングは、カテゴリとキーワード／概念の付いた必要なサブクエリを意味ネットワークに適用することにより、ＫＩＳ意味論的クエリプロセッサ（ｓｅｍａｎｔｉｃ ｑｕｅｒｙ ｐｒｏｃｅｓｓｏｒ、ＳＱＰ）にエンティティをシームレスに解釈させることができる。
3. 一般に、統合されたフルテキストのインデックシングにより、シームレスで一貫したデータとクエリモデルが得られる。
38. 意味論的な「オブジェクトを既読としてマークする」
一部の場合では、ＫＩＳは各オブジェクベースで人々とオブジェクトの間の意味論的リンクを格納するためのリソースがない場合がある。また、意味ベースの重複は、電子メールのようなオブジェクトごとの重複とは同じではない。例をとると、電子メールのクライアントは、ユーザに電子メールメッセージを既読か未読かの選択させることができる。これは一般的には電子メールメッセージでメールサーバに格納されたフラグとして実施される。ただし、電子メールは意味システムではないため、サーバ上の意味論的に似通っているか同一のメッセージはこのようにフラグされない。よってユーザは、意味論的重複に関わらず各メッセージを別々にフラグしなくてはならない。
インフォメーションナーバスシステム（登録商標）では、ユーザはオブジェクトを電子メールのように既読としてフラグできる。ただしこの場合、意味論的ブラウザはオブジェクトから概念を抽出し、リクエストプロフィールの全ＫＩＳに、「概念」が読み込まれたことを通知する。ＫＩＳは次にその概念を、設定されたＫＤＳ経由でカテゴリに動的にマッピングし、これらのカテゴリに属するオブジェクトにフラグを追加し（好ましい実施例にて）および／または、概念と一致するカテゴリとそのカテゴリにリンクされたすべてのオブジェクトとの間を、述語PREDICATETYPEID_VIEWDCATEGORYで意味論的リンクでフラグを意味ネットワークに追加する。好ましい実施例では、ＫＩＳは（ソース概念用の）リンク強度しきい値以上のカテゴリにのみフラグすべきである。こうして、意味論的に元のオブジェクトに近い（好ましい実施例での）そのようなオブジェクトおよび／またはカテゴリのみがフラグされることを確実にする。
意味論的ブラウザがＫＩＳ経由でオブジェクトをフラグする際には、ＫＩＳはネットワークが更新されたかどうかを示すフラグを表示する（オブジェクトに「強力な」カテゴリがない場合、または同じ「強力な」カテゴリを共有するほかのオブジェクトが存在しない場合は、変更されないこともあり得る）。リクエストプロフィールの少なくとも１つのＫＩＳでネットワークが更新されたことを示す場合、意味論的ブラウザはリクエスト／エージェントを更新する。意味論的ブラウザは特性を公表し、ユーザがＫＩＳに未読のオブジェクトのみか全オブジェクト（既読か未読か）のどちらを表示させたいのかを示させることができ、その場合、ブラウザは（電子メールクライアントが未読のメッセージをボールド体のフォントで表示するように）未読のオブジェクトを異なる方法で表示する。意味論的ブラウザの表示層は、明確な視覚的区別をつけるために、既読および未読のオブジェクトを適切なフォントおよび／または色で表示する。
39. マルチ選択のオブジェクトレンズ
マルチ選択のオブジェクトレンズは、当発明者の親出願で説明したオブジェクトレンズの代替の実装である。親出願の実施例では、オブジェクトレンズはスマートコピー＆ペースト経由で呼び出され、１つのオブジェクトを別のオブジェクト上にペーストすることによって、適切なデフォルトの述語を持つオブジェクトレンズが呼び出された。これは、ユーザが意味論的ブラウザのインスタンスをにわたって、プロフィールにわたっておよび（ファイルシステム、ワードプロセッサ、電子メールクライアントなど）別の環境からのオブジェクトをコピーできるという利点がある。
本出願の好ましい実施例では、オブジェクトレンズはドシェレンズ（文脈述語はドシェ、フィルタはソースと目標オブジェクトで、プロフィールはソースオブジェクトが表示されたプロフィール）である。
マルチ選択はまた、オブジェクトレンズを呼び出すために、コピー＆ペーストの代わりに使える。意味論的ブラウザはユーザに複数のオブジェクト（結果）を選択させることができる。ユーザは次に、ボタン（または代替のユーザインタフェースオブジェクト）を押して、選択オブジェクト上にオブジェクトレンズを呼び出すことができる。この場合ドシェレンズは、ドシェ文脈述語と、選択オブジェクトとしてのフィルタと、リクエストプロフィールとしての現在のプロフィールと共に（プレビューペイン内に）表示される。
40. オントロジーベースのフィルタリングおよびスパム管理
（好ましい実施例での）ＫＩＳは、オブジェクトが（１つ以上のＫＤＳ経由で）ＫＩＳ設定先の知識ドメインのうち最低１つからの最低１つのカテゴリに属する場合、これらのオブジェクトのみを意味メタデータ格納（ＳＭＳ）に追加する。これは本質的には、ＫＩＳが「理解しない」オブジェクトにはインデックスを付けないことを意味する。この例外としては、ＫＩＳはシステムインボックスからのオブジェクトにはすべてインデックスを付ける。というのは、必ずしも意味論的に関連しないが、関連する個人的なコミュニティ固有の発行物や注釈を時には含む場合があるからである。
このオントロジーベースのフィルタリングモデルの副作用には、スパム管理がある。オントロジーベースのインデックシングは、スパムがインデックス付けされたり格納されたりするのを防ぐのに効果的である。ユーザが、インボックスでなく意味ブラウズを使って電子メールにアクセスする場合、意味論的にフィルタリングされた電子メールのみが通過する。
41. 結果の精度を高める
リクエスト／エージェントの結果は、追加フィルタリングおよび述語を通じてさらに精度を高めることができる。
例えば、バイオインフォマティックスに関するリクエスト／エージェントの見出しは、バイオインフォマティックスの一定の分野固有のキーワードでさらに精度を高めることができる。こうしてエンドユーザは、リクエスト／エージェントをベースとして使って結果をさらに絞ることができる。また、時間に敏感なリクエストに関しては、ユーザはデフォルトの時間の枠を無効にするために、時間の枠を指定できる。例えば、ニュース速報のデフォルトの時間のリクエストを３時間と設定することができる。ユーザは、適切なＵＩメカニズムで（プロフィールごとまたはアプリケーション全体ベースのデフォルト設定変更に加えて）特定のリクエスト／エージェントに対しては（１時間から２４時間までのスライダー制御など）これを無効にすることができる。見出しや新聞ダネになる人にも同様に適用できる（１日から１週間までのスライダー制御など）。
ユーザがフィルタの無効を指定すると、意味論的ブラウザはリクエストプロフィールの各ＫＩＳに対してＸＭＬウェブサービスを呼び出し、無効引数を呼出しの一部として渡す。無効引数が存在すると、ウェブサービスはデフォルトのフィルタリング値の代わりにこれらの値を使う。同じことが（キーワードなどの）追加フィルタにも適用される。これらは追加引数としてウェブサービスに渡され、ウェブサービスはエージェント／リクエストＳＱＭＬで指定したクエリをさらにフィルタリングするために追加サブクエリを適切に適用する（つまり、ＳＱＭＬは通常通りに渡されるが、それに加えてフィルタが無効になり、追加フィルタも渡される）。
フィルタ無効の良い例は、「最も高い可能性」であろう。最も高い可能性のデフォルトの意味関連強度は（好ましい実施例でそうであるが）９０％に設定することができる。ただし、任意のリクエスト／エージェントに関して、ユーザは意味論的な関連性の範囲全体を通して「可能性」を参照したいかもしれない。（例えば、０％から１００％までの範囲のスライダー制御の）関連性ＵＩ制御を公表することによってこれが可能になる。これは実質的にはユーザに、「全ての可能性」（０％）から「完璧な可能性」（１００％）まで、最も高い可能性を即座に変更できるようにする。
複数のフィルタリング軸が関わる文脈テンプレート（特別エージェント）の実装の実施例には、混合型のモデルも採用されるべきである。例えば、ニュース速報も２５％の関連性フィルタを課すことがあるが、見出しや新聞ダネになる人も５０％の関連フィルタを課すことができる（ニュース速報は時間に敏感な閾値が高いため、関連性閾値が低いというように、関連性閾値は緩められる）。この場合、意味論的ブラウザは、ユーザが両方の軸（時間に敏感なスライダー制御と関連性用のスライダー制御）全体の特別エージェントの精度を高めることができるように、ＵＩ制御を公表するべきである。
ドシェでは、意味論的ブラウザはドシェに表示される各特別エージェントに対してＵＩ制御を表示できる。主要なドシェペインには、すべてのＵＩ制御を表示できる（任意のＵＩ制御の変更によって、その特別エージェントのドシェサブリクエストを更新できる）。また、ドシェは各特別エージェントに対してタブが付いている場合、各タブはそのタブ用の特別エージェントに固有のＵＩ制御を有することができる。
42. 情報格納の意味論的管理
インフォメーションナーバスシステム（登録商標）は、個人電子メールのインボックス、個人連絡先リスト、個人イベントカレンダー、（マイクロソフトウィンドウズ・エクスプロラーのローカルおよびネットワークベースのファイル管理システム等の）デスクトップのファイルシステム、ファイル共有、コンテンツ管理システムやウェブサイトのようなその他格納などの情報格納を管理するのに使える。
クライアントベースの格納（電子メールのインボックスやファイルシステムなど）に関しては、意味論的ブラウザのクライアントのランタイムは、重複、廃れた、または無益になった項目をチェックするためのプログラマティックインターフェイス経由で、格納を定期的にポーリングすべきである。これは電子メールのインボックスが増え続け、「価値や関連性を失った」かもしれない廃れたメッセージが増大するという今日の問題に対応する。ただし、ユーザが処理しなければならない膨大な情報量のため、多数のコンピュータユーザは電子メールのインボックスを自分で管理する能力を失いつつあり、その結果、格納スペースを取り、関連メッセージや項目の検索を難しくしている、古くて関連性がないであろうメッセージの山となる。
クライアントのランタイムはユーザの情報ソース格納内の項目を列挙し、項目から概念を抽出し（電子メールメッセージの本文およびローカル文書からなど）、概念をユーザプロフィールのＫＩＳへ送信する。代替実施例では、デフォルトのプロフィールのみを使う。クライアントは次にユーザの登録ＫＩＳに対して、項目が大事かどうかを「訊ねる」。好ましい実施例では、クライアントは次のヒューリスティクスを用いる。
1. まず重複性をチェックする − 重複する電子メール項目、概念や要約を共有する（ただし異なるタイトルまたはファイルサイズを使う可能性のある）重複文書をフラグ（または削除）する。クライアントは重複項目（ユーザ設定可能）を削除するか、それらを電子メールクライアントまたはデスクトップの特別フォルダ（ユーザ設定可能）に移動して項目をフラグする。
2. 次に非重複項目に関しては、クライアントは無益性または非関連性をチェックする。まずクライアントは、電子メール項目、文書またはその他オブジェクトの最後の変更時間を調べて、Ｎ日数（３０日など）「以上経過した」項目のみをチェックする。基準を満たす項目のみに対し、概念を抽出しすべてのユーザプロフィール（または代替実施例ではデフォルトのプロフィール）において各ＫＩＳのＸＭＬウェブサービスを呼び出す。
3. 大変古い項目（例えば１８０日以上）に関しては、クライアントは保存のための重要度の非常に低い閾値（例えば２５％）をＸＭＬウェブサービスに指定する。実質的には、これはかなり古く重要度も低い項目を削除（またはフラグ）することに近い。
4. 比較的古い項目（例えば９０日以上１８０日未満）に関しては、クライアントは保存のための非常に低い閾値（例えば１０％）を指定する。これはかなり古く重要度も低い項目を削除（またはフラグ）することに近い。
5. 古い項目（ただしそれほど古くなく、例えば１日以上３０日未満）に関しては、クライアントは保存のために非常に低い閾値（例えば０％）を指定する。これはユーザのプロフィールに基づき、時間が経過しており（ただしそれほどではない）重要ではない項目を削除（またはフラグ）するのに近い。
本質的に、好ましい実施例のこの側面または機能のモデルは、より新しい項目により高い意味論的閾値を課することにより、意味論的依存性と時間の敏感性とのバランスを取るものである（従ってそれほど時間が経過していないと、たとえ完全ではなくてもかなり無益な項目を保存する）。例えば、比較的最近の電子メールのスレッドは重要度においてかなり低いかもしれない。「時間的に若い」ということは関連性のしるしでもあるので、クライアントは当面はこれらを保存すべきである。しかし、「時間が経つ」につれ、クライアントはそれらを安全に削除できる（または削除のためフラグする）。
このモデルはまた、ローカルのファイルシステムで文書を管理するために適用できる。このモデルは、コンテンツ管理システム、文書レポジトリなどのシステムを（インフォメーションナーバスシステム（登録商標）ＸＭＬウェブサービスへの呼出し経由で）監視するために情報格納モニター（ＩＳＭ）を設定し、意味論的に管理されるレポジトリのドメインと一致するオントロジーを有するＫＤＳで設定されるＫＩＳでＩＳＭを設定することで、そのようなシステムに拡張できる。この機能は、コンテンツ管理システムを意味論的に管理し、関連する項目のみを経時的にこれらのシステムに保存されることを確実にするので、格納スペースやストレージ／維持費を節約する。
43. 計算尺フィルタのユーザインタフェース
意味論的ブラウザの精度を高めるペインで、ユーザは「結果の範囲内で検索」することができる。ユーザは追加のキーワードを補足したり、日付範囲を指定したりできる。日付範囲制御は、計算尺のように実施できる。計算尺で一パネルをずらすと、別のパネルで日付境界が上方に移動する一方で、そのパネルの日付境界が下方に移動する。ほかのパネルも時間境界用に追加でき、時間と日付の両方のパネルを移動させることにより、日付と時間の両方の制約を加える。パネルはまたその他のフィルタ軸にも追加できる。
C. サーバ側の意味論的クエリプロセッサの仕様
1. 概要
この項では、本出願の好ましい実施例でいかにサーバ側の意味論的クエリプロセッサ（ＳＱＰ）がＳＱＭＬクエリを解決するかを説明する。任意のサーバ上では、クエリは次のようないくつかのコンポーネントに分割される。
a. 文脈（文書、キーワード、エンティティ、ポートフォリオ（またはエンティティ集合））。
b. 文脈／知識テンプレート（または特別エージェント）または情報テンプレート − リクエストが知識タイプ（ニュース速報、対話、新聞ダネになる人または人気のある項目など）用か特定の情報タイプ（文書、電子メールなど）用かを説明する。
クライアント上では、意味論的クエリは文脈、リクエスト（またはエージェント）タイプおよび知識コミュニティ（またはエージェンシー）の三角形で構成される。クライアントは、意味論的クエリを表すＳＱＭＬをリクエストが存在するプロフィール内の全ての知識コミュニティへに送信する。クライアントは一度にいくつかの結果を求め、１つ以上のサーバからの結果を統合する。
サーバ側の意味論的クエリプロセッサは、意味論的クエリをいくつかのサブクエリに再分割し、次に（好ましい実施例でのＳＱＬ内部結合またはサブクエリ経由で）それを適用させる。これらのサブクエリは次の通りである。
1. リクエストタイプのサブクエリ − リクエストタイプによってサブクエリ（意味論的または非意味論的）を表す。例としては、文脈（知識）タイプ（全ての可能性、最も高い可能性、見出し、専門家など）および情報タイプ（一般の文書、プレゼンテーション、ウェブページ、表計算など）。
2. 意味論的文脈のサブクエリ − クライアントから渡された文脈（フィルタ）から派生した意味論的サブクエリを表す（この一例は、クライアントから送られた、あるいは意味論的ステムを経由してキーワード／テキストからマッピングされたカテゴリである）。
3. 非意味論的文脈のサブクエリ − クライアントから渡された文脈（フィルタ）から派生した非意味論的サブクエリを表す（例としては意味論的ステミムなしのキーワード−オントロジーベースのカテゴリへのマッピングである）。
4. アクセス制御のサブクエリ − 呼び出すユーザがアクセスを持たない意味論的メタデータ格納（ＳＭＳ）内の項目を除去するサブクエリを表す。詳しくは、「セキュリティ」仕様を参照のこと。
前記手順を図１４に図示する（サーバ側の意味論的クエリプロセッサのコンポーネント）。図１４は、サーバ側の意味論的クエリプロセッサが入ってくる意味論的クエリ（ＳＱＭＬとして表示）を処理する様子を示す。
2. 意味論的関連性の評点
意味関連性の評点は、概念抽出エンジンが返す正規化評点を定義する。テキストの任意の用語「ブラブ」を任意のオントロジーに関する１つ以上のカテゴリにマッピングする。評点は項目が意味ネットワークに追加される際に、意味ネットワークに追加される（「意味論的リンク」テーブルの「リンク強度」フィールド）。
3. 意味論的関連性フィルタ
関連性フィルタは関連性評点とは異なる（事実、両方は一般に組み合わされる）。関連性フィルタは、ＳＱＰが文脈をどのように意味論的に解釈するかを示す（注意：本出願の好ましい実施例では、フィルタリングはこの場合常に意味論的である）。高低二種類の関連性フィルタが存在する。高い関連性フィルタでは、ＳＱＰはカテゴリと用語が交差するサブクエリを含む。例えば、キーワード「ＸＭＬ」の文脈は次のように解釈される。ＸＭＬと同じカテゴリを共有する項目で、キーワード「ＸＭＬ」を含む。これは発生し得る最も高いレベルのオントロジーベースの意味論的フィルタリングである。ただし、意味論的に文脈と同義だが、キーワードまたは用語を共有しない意味論的ネットワーク（または意味論的メタデータ格納（ＳＭＳ））にオブジェクトが存在する場合は、情報喪失につながる可能性がある。例えば、上述するクエリはＸＭＬと同じカテゴリを共有するが、その代わりに用語「拡張マークアップ言語」を含む項目を失う。低い関連性フィルタは文脈と同じカテゴリを共有するオブジェクトのみを含むが、高い関連性フィルタとは異なり、キーワード同義性の追加制約を含まない。
この理由のため、関連性フィルタはサブクエリ「バケツ」を作成するためにのみ使われ、それで結果を要求するのに使われるのが好ましい。例えば、ＳＱＰは意味ネットワークをフィルタする際には、低い関連性フィルタの前に高い関連性フィルタを優先させる可能性があるが、その場合でも最終的な意味論的フィルタリングのプロセス中に同意語が拒否されないことを確実にするため、両方が（重複分は削除されて）返される。
4. 時間に敏感なフィルタ
時間に敏感なフィルタは、意味論的サブクエリがいかにタイムクリティカルかを決定する。高低２つのレベルがある。高いレベルのフィルタは、極端にタイムクリティカルである。デフォルト設定は３時間である（これは昼休憩など、オフィス／机から離れる時間等からなる）。低いレベルのフィルタは、適度にタイムクリティカルである。デフォルト設定は１２時間である。
5. 知識タイプの意味論的クエリの実装
このアプリケーション全体において、一定の固有の知識タイプは適切な省略名によって参照され、その一部を本申請者が使用する、あるいは商標として使う、あるいは使う可能性がある。この項では、その性質や機能についてさらに詳しく説明する。
a. 全ての可能性
「全ての可能性」クエリに関しては、サーバは単に全項目を意味論的メタデータ格納に返す。ＳＱＭＬにフィルタが含まれる場合、フィルタは意味論的リンク強度閾値なしで内部サブクエリ経由にて課せられる。たとえば、トピックＡに関する全ての可能性は、トピックＡに関連する全項目を（強弱どちらも）返す。
b. 任意の可能性
好ましい実施例では、「任意の可能性」クエリに関しては、サーバは単に意味メタデータ格納の全項目を返すが（「全ての可能性」クエリと同様に）、結果を無作為に要求する。ＳＱＭＬにフィルタが含まれる場合、フィルタは意味論的リンク強度閾値なしで内部サブクエリを通じて課せられる。例えば、トピックＡに関する任意の可能性は、トピックＡに関連する（強弱に関わらず）全項目（無作為に要求した）を返す。
c. ニュース速報
サーバがユーザ状態を有する場合、ニュース速報は大変知的な方法で実施できる。以下のテーブルは、ユーザがどの項目（および／またはカテゴリ）を既読したかをサーバが追跡する際に、ニュース速報の本出願の好ましい格付けおよび優先度を示す。
Figure 2006522388
好ましい実施例では、サーバはニュース速報用のＳＱＭＬを（ニュース速報文脈述語を通じて）次のように処理する。
1. 全ニュース速報は、返されたニュースがＮ時間（または日数、月数、設定可能）より「時間的に若く」なければならないサブクエリでフィルタリングされる。これによって主な時間に敏感な度合いの制約が課せられる。
2. ニュース速報は常に意義的である。
3. 好ましい実施例では、意味ネットワークマネージャ（ＳＮＭ）は、各ユーザの「最後に読んだ時間」を各カテゴリに示すため、意味ネットワークを更新する。これはニュースが「既読」かどうかをチェックするために、サブクエリで使われる（カテゴリまたはオブジェクトごと − オブジェクトごとは増減しないため好まれる実施例である）。
4. 優先度は、ユーザが「未読」のニュース項目に与えられる（意味論的リンクのテーブルで最後に読んだ時間と「ユーザ」を「カテゴリ」にリンクする意味論的リンクタイプとを比較して実施される）。
5. 意味論的優先度スキームで黙示しているのは、ニュースの意味論的関連性が高いため、ユーザは「時間的に古い」ニュース速報を最初に得て、ニュースの意味論的な関連性が低いため、「時間的に若い」ニュースを「後で」得ることができるということである。これで混合型の関連性−時間に敏感な優先度スキームとなる。
6. 一次要求軸（作成時間）は、結果が新鮮度によってフィルタされることを確実にする。二次要求軸（関連性評点）は、同点決勝の役割をし、同等に新鮮な結果が、主に関連性に基づいて区別されることを確実にする。
7. ニュース速報の組み込み警告を、ニュース速報の優先度を優先度２に限定し、優先度１と優先度の時間に敏感なフィルタを高いに変更することで、クライアント側で行うことができる。こうすると、（意味関連性フィルタの高い低い両方の）非常に新鮮な未読の意味論的なニュース速報のみが返される。明示的でなく黙示的であるため、警告はニュース速報リクエスト（またはエージェント）よりも高い秩序を破壊する閾値を有するため有利である。
8. 未読のニュース速報は、ユーザが未読の物により関心を持つであろうから、既読のニュース速報よりも優先度が高い。
9. 未読のニュース速報は既読のニュース速報より、時間に敏感な度合いが低い。なぜなら、ユーザは目新しい時間的に古いニュースの方が、目新しくない時間的に若いニュースよりも許容度があるからである。
一部の場合では、サーバはユーザ状態（および「既読」情報）がない場合がある。この場合、ニュース速報の簡単な実装が以下のように示される。
1. デフォルト設定により（フィルタなし）、ニュース速報はＮ時間（デフォルトでは３時間）より時間的に若い項目のみを返す。
2. ＳＱＭＬに最低１つのフィルタがある場合、ニュース速報は時間に敏感なフィルタ（３時間）を外的サブクエリに適用し、適度な強度の関連性フィルタを（意味論的リンクのテーブルから）内的サブクエリに適用する。好ましい実施例では、５０％の関連性評点（およびリンク強度）に相当する。例えば、トピックＡに関するニュース速報は、過去３時間の間に掲示された項目で、最低関連性評点５０％を有するトピックＡが表すカテゴリ（単数または複数）に属する項目を返す。こうして、トピックＡにほとんど関連性のないニュース速報項目のようなフォールスポジティブを回避する。
d. 見出し
ニュース速報と同様である（ただし、時間に敏感な制約はもっと緩い − 高いフィルタは３時間の代わりに１２時間であり、低いフィルタは１２時間の代わりに１日である）。簡単な実装では、時間に敏感な制約は１日である。これはまた週末を動的に扱うため、月曜日は３日に設定できる（こうして日数を「就労日数」にする）。
e. 新聞ダネになる人
新聞ダネになる人は、ＳＱＰが見出しの項目そのものでなく、見出し項目の著者を返すこと以外は、見出しと同じように扱われる。
f. 最も高い可能性
当発明者の親出願（通し番号１０／１７９，６５１号）で説明したように、最も高い可能性は「カテゴリに所属」の述語で意味論的リンクの強度にフィルタを課することで実施される。好ましいデフォルト設定は９０％であるが、（ユーザのオプションによって）クライアントは、ＸＭＬウェブサービス経由で渡される引数によりこれを即座に変更できる。最も高い可能性は、オブジェクトテーブルと意味論的リンクテーブル間のＳＱＬ内的結合で実装され、「カテゴリに所属」の述語を有しリンク強度が９０％以上（デフォルト設定）の意味論的リンクテーブルの行のみを結合する。処理中のＳＱＭＬが（キーワード、テキスト、エンティティなど）フィルタを含む場合、サーバ側の意味論的クエリプロセッサも、希望するフィルタにマッピングされるＳＱＬ内的結合であるサブクエリを呼び出す必要がある。好ましい実施例では、このサブクエリには「最も高い可能性」フィルタも含まれる。
好ましい実施例では、ほとんどのユーザにとって、外的サブクエリ用、そして内的サブクエリ用にも、最も高い可能性を使うのが有利で多分好ましい。これを説明すると、「トピックＡに関する最も高い可能性」は、「トピックＡにも関連する最も高い可能性」とは意義的に異なる。前者の例では、トピックＡ「に関して」最も高い可能性である最も高い可能性のみを（内的サブクエリに「最も高い可能性」の意味フィルタを適用することで）返す。反対に後者の例では、トピックＡとなんらかの関連があるかもしれないすべてに関する最も高い可能性をすべて返す。例えば、トピックＢに関する最も高い可能性であるが、トピックＢに関する「低い可能性」である文書が返され、クエリの意義または恐らく望まれる結果と一致しないことから、後者の例はフォールスポジティブを返す可能性がある。「最も高い可能性」フィルタを外的サブクエリだけでなく、すべての内的サブクエリにも拡張することにより、この発生を防ぐ。その他のクエリの実装もまた、ＳＱＭＬにフィルタが含まれれば、（主要クエリの意義に基づいて適用される適切なサブクエリによって）この規則に従うことが可能である。
g. その他の知識タイプ用のクエリの実装
その他の知識タイプは、上記と似通った方法で（適切な述語経由で）実施される。いくつかの例を次で説明する。
情報タイプの意味論的クエリの実装
すべての情報タイプ意味論的クエリの実装は、同じパターンに従うことができ、（ただし必要というわけではないが）従うことが好ましい。ＳＱＰはリクエストした情報タイプと一致するオブジェクトタイプＩＤを有するオブジェクトのみを返す。一例は「情報タイプ＼プレゼンテーション」である。ＳＱＰがクライアントから受信するＳＱＭＬを構文解析する際に、ＳＱＭＬからこの属性を抽出し、オブジェクトタイプＩＤにマッピングする。次にそのオブジェクトタイプＩＤ用の追加フィルタで、ＳＱＬクエリを呼び出す。いくつかの個別情報タイプ（「情報タイプ＼全ての文書」など）に及ぶ可能性のある特別な情報タイプに関しては、ＳＱＰはリクエストを一組のオブジェクトタイプＩＤにマッピングし、この追加フィルタと共にＳＱＬクエリを呼び出す。
文脈意味論的クエリの実装
クライアントが（クライアントでテキストか文書から抽出される）概念を含むＳＱＭＬを送ると、サーバ側のＳＱＰはまずそれと一致するサブクエリを生成する前に、文脈を意味論的に解釈する。これを行うためには、サーバは概念を意味論的分類のために（所望の知識コミュニティまたはエージェンシー用に）設定された全てのＫＤＳ（ＫＢＳ）に送る。サーバにカテゴリが戻される際に、適切なサブクエリを生成する前にそのうちのどのカテゴリが、フィルタとして使うのに充分な「強度」を持つかを判断することが好ましい。
この「フィルタ強度」の判断は有益である。例えば、文脈が比較的長い文書で、文書に何千という概念やカテゴリが含まれる可能性があるからである。その結果、文書の「代表的意義」は、文書内のすべての概念／カテゴリのサブセットにのみ含まれるかもしれない。全カテゴリをサブクエリにマッピングすると、ユーザには紛らわしい結果を返す場合がある。ユーザは文書に何が含まれているかを「察する」可能性があり、文書内の一部の弱い概念に関連する結果をユーザが見る場合、ユーザは結果を文書の文脈で調停できない可能性がある。従って、好ましい実施例では、サーバ側のＳＱＰは、サブクエリに適用するために「強いカテゴリ」のみを選択することが好ましい。カテゴリが最低５０％の意義的強度を持つことが好ましい。そうすることにより、意味文脈で強い値を記録したカテゴリのみがサブクエリに適用される。サブクエリの実装は、クエリが文脈述語を含むかどうかによって、知識タイプ、情報タイプなどに基づき上記のルールに従う。
意義的ステミングの実装
当発明者の親出願で説明したとおり、サーバ側の意味論的クエリプロセッサは、１つ以上のドメインオントロジーに基づき、キーワード、テキストおよび概念をカテゴリにマッピングするため、意義的ステミングを行う。その方法の１つは、カテゴリを入手するために設定先のＫＤＳ／ＫＢＳ（または複数のＫＤＳ／ＫＢＳ）にＸＭＬウェブサービスコールを呼び出して行う。次に、そのカテゴリを意味ネットワークにマッピングする。このステミング形式は、単にキーワード形式に基づくステミングではなく、意義に基づきステミングするドメイン固有の意義的マッピングも関わるため、（単数と複数の変化、時制の変化などの）キーワードのバリエーションに基づく通常のステミングより優れている。
本出願の好ましい実施例では、ＫＩＳは更なる意義的解釈を必要とするＳＱＭＬを受信するたびに、ＫＩＳはＫＤＳ／ＫＢＳを呼び出す。ただし、ＫＤＳ／ＫＢＳが異なるサーバに存在する、ネットワーク接続が敏速でない、またはＫＤＳ／ＫＢＳが多くのリクエストの処理で混雑している場合などは遅延の原因になることがある。この場合、ＫＩＳは意義的ステミングのキャシュも実装できる。このキャシュは、ＵＲＩで完全修飾のカテゴリにキーワードや概念をマッピングする（ので世界的に固有になる）。サーバ側の意味論的クエリプロセッサが、（クライアント側の意味論的クエリプロセッサによりクライアント上の、例えば文書から抽出された）キーワード、テキストまたは概念を含むＳＱＭＬを受け取ると、まずキャシュをチェックして、キーワードがすでに意義的にステミングされたかどうかをチェックする。キャシュヒットがある場合、ＳＱＰは単にカテゴリをキャシュから取得し、これらのカテゴリをＳＱＬクエリ経由で意味ネットワークへマッピングする。（その文脈がキャシュにない場合など）キャシュミスがある場合、意義的分類を行うためにＫＤＳ／ＫＢＳを呼び出す。次に結果を得て、それらを固有のカテゴリＵＲＩへマッピングし、エントリを（ハッシュコードとして文脈で）キャシュへ追加する。ここで留意すべきは、文脈がどのカテゴリへマッピングされなくても、「カテゴリの欠如」はキャシュされることが好ましいことである。つまり、文脈はカテゴリなしでキャシュエントリとして追加される。こうすると、サーバはその都度ＫＤＳ／ＫＢＳを呼び出して調べることなく、任意の文脈がカテゴリを持たないことを即座に判断することができる。
キャシュ管理
ＳＱＰはまた、意義的ステミングのキャシュを管理できる。これは次の２つの理由のために行わなくてはならない。１つはキャシュが制御できなくなるくらい増大し、システムリソースを多量に消費しすぎてしまうことを防ぎ（ヒープベースのハッシュテーブルでのメモリは特にである）、２つ目は（知識ドメインが追加／削除された場合など）ＫＩＳ設定が変更された場合、エントリが廃れた可能性があるため、キャシュを消却することが好ましい。１番目のシナリオでは、最大数のエントリをキャシュに割り当てることで行える。好ましい実施例では、ＳＱＰはキャシュによって消費された現在のメモリ量をキャッシュし、キャシュ制限はメモリの使用により変化する。例えば、管理者が最大キャシュサイズを６４ＭＢに設定するとする。実装を簡潔化するためには、これを（最大メモリ使用量を各キャシュエントリのサイズの概算で割るなどによって）おおよその項目数へマッピングできる。
各新規エントリに対しては、キャシュが制限に達していない場合、ＳＱＰは単にエントリをキャシュに追加する。しかし、キャシュが制限に達すると、（好ましい実施例では）ＳＱＰは古い順番に追加された項目をキャシュから消去する。好ましい実施例では、これは（文脈をキーとして使うクイックルックアップ用の）キャシュそのものを実装するハッシュテーブルと同期化される項目の待ち行列を維持することによって実装できる。ＳＱＰがスペースを解放するためにキャシュから項目を消去する必要がある場合は、古い順番に追加された待ち行列からの項目を待機解除し、（文脈をキーとして使って）ハッシュテーブルから相当する項目を削除する。こうすると、新鮮な項目が古い項目よりもキャシュで見つかる可能性が高い。その結果、ユーザがエージェント／リクエスト／クエリを開けるたびに、保存したエージェント／リクエスト／クエリ用の文脈は、クイックルックアップでキャシュされることになるため、より敏速なユーザ経験が得られる。同じことが、同じ文脈（で異なる知識タイプ）を有するドシェ（ガイド）クエリにも言える。文脈はキャシュされるため、クライアントは同じ文脈用の各知識タイプをリクエストし、各サブクエリはより早く実行される。
D. インフォメーションナーバスシステム用の拡張可能なクライアント側のユーザプロフィール仕様
概要
拡張可能なクライアント側のプロフィールは、意味論的ブラウザのユーザに、異なるジョブの役割、知識ソース、身元情報、人格、仕事のスタイルその他に対して別の状態を有することを可能にする。これは実質的には、ユーザが異なるシナリオに対して、異なる「知識世界」を作成することを可能にさせる。例えば医薬品の研究者は、自分の仕事に関連するあらゆるソースからの知識を含むデフォルトのプロフィールを有するとする。当発明者の親出願通し番号１０／１７９，６５１号で説明するとおり、そのようなソースの各々からのＳＲＭＬはクライアントでマージされ、ユーザは１つのソースから発生したかのように結果をシームレスに調べることができる。しかしながら、研究者は他のすべてとは別に特許を追跡することを望むかもしれない。そのような場合には、研究者は別の「特許」プロフィールを作成し、特許と関連する知識コミュニティ（エージェンシー）も含むこともできる（米国特許庁のデータベース、ＥＵ特許データベースなど）。
また別な例を挙げれば、例えばユーザは「仕事」と「家庭」に関するプロフィールをそれぞれ作成するとする。多くの出資アナリストは、様々な業界を横切って会社を追跡する。意味論的ブラウザを使うと、追跡する各業界に対してプロフィールを作成する。コンサルタントはプロジェクトからプロジェクト（および業界から業界）へと移行して、各プロジェクトで作成したリクエストやエンティティを保存したいかもしれない。プロフィールがはこのようなシナリオを扱うためにも使われる。
プロフィールには次のユーザ状態が含まれる。
・名前／詳細 − プロフィールの詳細名
・リクエスト（エージェント）が呼び出される（ＫＩＳ上で実行される）知識のソースを示す１つ以上の知識コミュニティ（エージェンシー）
・身元情報 − （現在ユーザの電子メールアドレスにタグされている）ユーザ名およびパスワード
・関心のある分野またはお気に入りのカテゴリ − 情報コミュニティ（エージェンシー）を（同一または類似カテゴリの情報コミュニティと比較することで）ユーザに提案し、プロフィールで作成されたリクエスト用のデフォルト・クエリフィルタとして使われる。
・スマートスタイル − スマートスタイルはプロフィールで作成されたリクエストやエンティティ用にデフォルトとして使われる。
・デフォルトのフラグ − プロフィールがデフォルトプロフィールであるかどうかを示す。デフォルトのプロフィールは、ユーザがリクエストやエンティティを作成する、あるいは情報コミュニティなどを参照したいときに、デフォルト設定で開始される。ユーザが明確に異なるプロフィールを選択するのでない限り、デフォルトのプロフィールが使われる。
プロフィールは作成、削除、変更および改名できる。ただし、好ましい実施例では、最低１つのプロフィールが常にシステムになければならないので、デフォルトのプロフィールは削除できない。代替実施例では、最低限のプロフィールは必要とされない。
好ましくは、意味論的ブラウザの全オブジェクトはプロフィールの文脈内で開かれる。例えば、スマートリクエストはプロフィールで作成され、実行時には、クライアント意味論的クエリプロセッサは、リクエストを呼び出すため、プロフィールの特性（特に、そのプロフィール内で登録された知識コミュニティ（エージェンシー））を使用する。これによって、ユーザはリクエストの知識の特徴（より一般的には、リクエスト用にユーザが使いたい知識のソース）に基づいて、リクエストを具体的なプロフィールに関連付ける、またはスコープすることができる。
図１５は、２つのプロフィール（１５Ａの「私のプロフィール」と名づけられたデフォルトプロフィールと１５Ｂの「特許」と名づけられたプロフィール）を示す意味論的ブラウザを図示する。ユーザが干渉されずに、両方のプロフィールを経由して自分の知識世界をナビゲートできるかに注目されたい。
図１６Ａ−Ｃでは、ユーザがどのようにプロフィールを設定するかを図示する（プロフィールを作成するには、ユーザは「プロフィール作成ウィザード」を使用し、プロフィールはその後、示すように特性シート経由で変更できる）。
図１７は、「リクエスト作成ウィザード」でリクエストを作成する際に、ユーザがどのようにプロフィールを選択するかを示す。
E. インフォメーションナーバスシステム用のスマートスタイルの仕様
1. スマートスタイルの概要
スタイルのテーマに適用される色のテーマとアニメーションのテーマが、「スマートスタイル」を生みだす。この文脈での「スマート」とは、スタイルはリクエスト、文脈ペイン、プレビューモード、携帯モード、ライブモード、スライドショーモード、スクリーンセーバーモード、ブレンダー／集合モード、アクセスのしやすさ、ユーザ設定の認識、および（以下の）他のシステム内の可能な変数のムードに対して適応し反応することを意味する。可能なスタイルは無限で無数の種類または「クラス」がある。好ましい実施例は、少なくとも以下のスタイルクラスで構成される。
1. 微妙 − タスク指向の生産性用
2. 適度 − ある程度のプレゼンテーション効果でタスク指向の生産性用
3. 刺激的 − 刺激的効果（一次および二次の両方のマシン、不活発なナバナ・ウィンドウズに適している − 背景のナバナクライアントウィンドウまたはタスクバーに結合）
4. 超刺激的（生産性のあるスマートスクリーンセーバーに最適 − ユーザが自分の一次マシンを使用中の二次マシンなど）
5. ＳＦ （マトリックスファン用、生産性に特別必要性がないスマートスクリーンセーバーに最適 − ユーザが席を外しているときなど）
スタイル、色およびアニメーションのテーマ − 変数、無制限 − ナバナで作成、可能性としてはユーザおよび／またはサードパーティのスキン作成者
2. 潜在的で動的なスマートスタイル特性
ａ. ムード − スマートスタイルは、リクエストのムードを伝えなくてはならない（リクエストはスマートスタイルに渡されるパラメータである）。これにはスマートリクエストの意義的に伝えられる、または意義的に判断される（文脈テンプレートまたは情報タイプ、カテゴリ、フィルタが存在するかどうか（例えばローカル文書など）、そのフィルタの情報タイプなどの）特性を伝える意味論的画像、意味論的動画、視覚化などが関わる。
ｂ. 文脈ペイン − ディープインフォメーションのペイン（オブジェクトごと）、ドックすることが可能なプレビューペイン、ドックすることが可能な文脈ＰＩＰ警戒グループ／ペインなど。
ｃ. プレビューモード − 各スマートスタイルは、プレビューのために（小ウィンドウで）その結果を表示できなければならない。
ｄ. 携帯モード − 各スマートスタイルは、携帯デバイス用に結果を最適化して表示できなければならない。
ｅ. ライブモード − 各スマートスタイルは、（オブジェクトごとの）意味論的視覚化をリアルタイムで表示できる「ライブ」モードを有することが必要である。これは、（ユーザが意義的視覚化をリアルタイムで望まない場合、またはオブジェクトごとのリアルタイム・ウェブサービスコールの結果としての帯域幅を保存するためなど）トグルでオンかオフに切り替えられる。
ｆ. スライドショーモード − 各スマートスタイルは、好ましくはライブストリームのようにリクエスト結果を「再生」できなければならない。
ｇ. スクリーンセーバーモード −各スマートスタイルは、好ましくはリクエストの結果をスクリーンセーバーとして「再生」できなくてはならない。これは、フルスクリーン／シアターモード以外では、スライドショーモードの変形である。
ｈ. ブレンダー／集合モード − 各スマートスタイルは、好ましくは表示しているリクエストがブレンダー／集合である場合、ＵＩを適切に変更しなければならない。
ｉ. アクセスのしやすさ −各スマートスタイルは、好ましくはアクセスのしやすさをサポートしなくてはならない。
ｊ. ユーザ設定の認識 −− ナバナライブラリアンは、ユーザに初心者、中級ユーザまたはパワーユーザのどれか、および各人のジョブ機能（Ｒ＆Ｄ、セールス、マーケティング、エグゼクティブなど）を示させることができる。各スマートスタイルは適宜これらの機能を考慮する（または影響を受ける）ことが好ましい。
・各スマートスタイルは、リクエストの意義と一致した、認識（または識別か感知）することを担当し、次に視覚化（またはユーザの注目に値する方法で提示、描写または図示する）を担うことが好ましい。
・現在のリクエストのムード（意義的画像、動画、クロムなど）
・現在のリクエストの項目数の変更
・各オブジェクトのムード（組み込み的）
・各オブジェクトの文脈のムード（見出し、ニュース速報、専門家など）
・程度問題、またはグラデーションか連続体の問題とは区別される（ニュース速報が存在するのか否か？何人の専門家がいるのか？見出しはいくつ？など）バイナリ／絶対値の問題または特徴
・特徴がグラデーションまたは連続体に関するものである場合、それに沿った相対的な配置の知覚（ニュース速報はどの位の速報なのか？見出しはどれほど重要なのか？専門家の専門知識レベルはどのくらい？など）
・各オブジェクトの文脈変更（新しいニュース速報がある、新しい注釈ある、など）
・表示される各オブジェクトの相対的重要性（異なるサイズのビューポート、異なるフォント、異なるクロムなど）
・リクエストナビゲーションおよび「ローディング」の状態（ロード中の新しいリクエストのムードを導入する割り込み）
・任意の個別ＰＩＰウィンドウの全特性（アニメーション制御で描き出される）
・新しいＰＩＰウィンドウの追加（ＰＩＰウィンドウパレットへ）
・ＰＩＰウィンドウのサイズ変更／移動／ドッキング
・任意のプレビューウィンドウ（文脈パレット、各オブジェクトの「視覚化ＵＩ」、時系列など）
・前記ムードおよび通知の視覚化のすべてと一致するサウンド（全体的）
図１８は、前記操作と機能の一部を図示する「スマートスタイル」のダイアログボックスのスクリーンショット例を示す。ここで示すとおり、ダイアログボックスでユーザは、スタイルクラス、スタイルテーマ、色テーマおよびアニメーションテーマ全体をピボットすることでスマートスタイルを参照することができる。プレビューウィンドウは、現在選択されているスマートスタイルのプレビューをユーザに示す。
F. インフォメーションナーバスシステム用のスマートリクエスト警戒の仕様
1. 概要
スマートリクエスト警戒とは、意味論的ブラウザのユーザ（インフォメーションエージェントまたはライブラリアン）に、スマートリクエストを平行して監視（または「警戒」）させることができる機能を指す。これは、ユーザにいくつかのリクエストを同時に追跡させて生産性を高めることができる点で、大変有益な機能である。
この機能は、クライアント側の意義的ランタイム、意味論的ブラウザおよび（ＴＶセットの「ピクチャーインピクチャー」（ＰＩＰ）の機能性に似たメカニズムを通して）スマートリクエストを警戒する設定可能な方法を可能にするスキンで実装される。以下のソフトウェアのコンポーネントのうちの１つ以上が使われることが好ましい。
1. リクエスト警戒リスト（Ｒｅｑｕｅｓｔ Ｗａｔｃｈ Ｌｉｓｔ、ＲＷＬ）
2. リクエスト警戒グループ
3. 通知マネージャ（ＮＭ）
4. 警戒グループモニター（Ｗａｔｃｈ Ｇｒｏｕｐ Ｍｏｎｉｔｏｒｓ、ＷＬＭ）
5. 警戒ペイン
6. 警戒ウィンドウ
2. リクエスト警戒リスト（ＲＷＬ）およびリクエスト警戒グループ（ＲＷＧ）
リクエスト警戒リストは、クライアントのランタイムが管理するスマートリクエスト（またはスマートエージェント）の一覧である。このリストは実質的には、ユーザが監視したいスマートリクエストで構成される。リクエスト警戒リストは、エントリのリストからなり、次のデータ構造を持つリクエスト警戒リストエントリ（Ｒｅｑｕｅｓｔ Ｗａｔｃｈ Ｌｉｓｔ Ｅｎｔｒｙ、 ＲＷＬＥ）である。
Figure 2006522388
リクエスト警戒リスト（ＲＷＬ）には、ＲＷＬＥ構造の配列またはベクトルが含まれる。リクエスト警戒リストマネージャで、ＲＷＬを管理する。意味論的ブラウザはユーザにスマートリクエストをＲＷＬに追加できるインタフェースを提供する。ＵＩはＲＷＬＭと対話し、ＲＷＬＥをＲＷＬに追加したりＲＷＬから削除したりする。ＲＷＬは、クライアント側の意味ランタイム（ＸＭＬファイルベースの表現かウィンドウズレジストリのような格納のどちらかとして）によって中央で格納（および存続）する。
ＲＷＬはまた、リクエスト警戒グループ（Ｒｅｑｕｅｓｔ Ｗａｔｃｈ Ｇｒｏｕｐｓ、ＲＷＧ）の手段によってポピュレートすることができる。リクエスト警戒グループは、ユーザにスマートリクエストの集合を監視する手段を提供する。また、設定可能な基準に基づいて意味論的ブラウザにＲＷＬを自動的にポピュレートさせる簡単な方法をユーザに提供する。自動リクエスト警戒グループと手動リクエスト警戒グループという、最低２つのタイプのＲＷＧが存在する。自動リクエスト警戒グループは、選択したプロフィール、現在表示されているリクエストのプロフィールなどによって、意味論的ブラウザによって動的にポピュレートされるグループである。手動リクエスト警戒グループでは、ユーザはスマートリクエストのグループ（通常のスマートリクエストまたはブレンダー）を集合として監視するため、手動でポピュレートができる。手動リクエスト警戒グループはまた、ユーザに（文書、カテゴリ、テキスト、キーワード、エンティティなど）サポート文脈のタイプを追加させることができる。この場合、システムは意味論的クエリ（ＳＱＭＬ）をフィルタから動的に生成し、結果として得られるクエリを手動リクエスト警戒グループに追加する。これは、フィルタを警戒グループに追加する前に、１つ以上のフィルタを基にまず時間に敏感なリクエストを作成させることでユーザの手間を省く。ユーザは単にフィルタに焦点を当て、システムが残りを行う。
ユーザは以下のタイプの自動ＲＷＧを追加できる（図１９のスマートリクエストダイアログボックスに示す「全てのプロフィール」を含む１つ以上の設定可能プロフィール用）。
1. ニュース速報 − 意味論的ブラウザに対し、ニュース速報のスマートリクエストを自動的にＲＷＬに追加するよう指示する（選択するプロフィール用）。
2. 見出し − 意味論的ブラウザに対し、見出しのスマートリクエストを自動的に（選択したプロフィール用に）ＲＷＬに追加するよう指示する。
3. 新聞ダネになる人 − 意味論的ブラウザに対し、新聞ダネになる人のスマートリクエストを自動的に（選択したプロフィール用に）ＲＷＬに追加するよう指示する。
4. 分類されたニュース速報 − 意味論的ブラウザに対し、分類されたニュース速報を自動的に（文脈プロフィール用に）ＲＷＬへ追加するよう指示する。意味論的ブラウザは、現在表示されているスマートリクエストにカテゴリが含まれている場合、現在表示されているスマートリクエスト（および文脈または現在のプロフィール用）の各サブカテゴリと一致するカテゴリフィルタで、スマートリクエストを動的に追加する。例えば、「技術に関するニュース速報」のスマートリクエストが現在意味論的ブラウザのインスタンスに表示される場合で、カテゴリ「技術」に（例えばワイヤレス、半導体、ナノテクノロジー、ソフトウェア、エレクトロニクスの）５つのサブカテゴリがある場合、以下のスマートリクエストが、現在のスマートリクエストがロードされる際に動的にＲＷＬに追加される。
・技術．ワイヤレス［＜文脈のプロフィール名＞］に関するニュース速報
・技術．半導体［＜文脈のプロフィール名＞］に関するニュース速報
・技術．ナノテクノロジーに関するニュース速報［＜文脈のプロフィール名＞］
・技術．ソフトウェア［＜文脈のプロフィール名＞］に関するニュース速報
・技術．エレクトロニクス［＜文脈のプロフィール名＞］に関するニュース速報
また、このようなエントリのＲＷＬＥは、現在の意味論的ブラウザインスタンスのリクエストビューインスタンスＩＤで初期化される。ユーザが新しいスマートリクエストにナビゲートする場合、以前にロードされたスマートリクエスト用に分類されたニュース速報はＲＷＬから削除され、分類されたニュース速報の新しいリストが新しいスマートリクエスト用に追加され（カテゴリを有する場合）、新しいスマートリクエストビューと一致する新しいリクエストビューインスタンスＩＤで初期化される。こうして、（サブカテゴリ用の）関連する分類済みニュース速報が、現在表示されるリクエストに基づいて動的に表示される、スマートユーザ経験を作成する。ユーザは次に、分類されたニュース速報のスマートリクエストを警戒グループまたは集合として監視できる。
5. 分類された見出し − これによって、自動的に分類された見出しスマートリクエストを（文脈プロフィール用に）ＲＷＬに追加するよう意味論的ブラウザに指示する。これは、見出しがこの場合に使われている以外は、分類されたニュース速報と似通っている。ユーザは次に、分類された見出しのスマートリクエストを警戒グループまたは集合として監視できる。
6. 分類された新聞ダネになる人 − これは、分類された新聞ダネになる人のスマートリクエストを（文脈プロフィール用に）ＲＷＬに自動的に追加するよう意味論的ブラウザに指示する。新聞ダネになる人がこの場合に使われている以外は、これは分類されたニュース速報と似通っている。ユーザは次に、分類された新聞ダネになる人のスマートリクエストを警戒グループまたは集合として監視できる。
7. 私のお気に入りのリクエスト − これは、全てのお気に入りのスマートリクエストを（選択したプロフィール用に）ＲＷＬに自動的に追加するよう意味論的ブラウザに指示する。こうしてユーザは全ての自分のお気に入りのスマートリクエストをグループとして警戒または監視できる。
8. 私のお気に入りのニュース速報 − これは、全てのお気に入りニュース速報のスマートリクエストを（選択したプロフィール用に）ＲＷＬに自動的に追加するよう、意味論的ブラウザに指示できる。これによってユーザは、すべての自分のお気に入りニュース速報のスマートリクエストを、グループとして警戒または監視できる。
9. 私のお気に入りの見出し − これは、全てのお気に入りの見出しのスマートリクエストを（選択したプロフィール用に）ＲＷＬに自動的に追加するよう、意味論的ブラウザに指示できる。こうして、ユーザは自分のお気に入りの見出しのスマートリクエストを、グループとして警戒または監視できる。
10. 私のお気に入りの新聞ダネになる人 − これは、全てのお気に入りの新聞ダネになる人のスマートリクエストを（選択したプロフィール用に）ＲＷＬに自動的に追加するよう、意味論的ブラウザに指示できる。こうしてユーザは自分のお気に入りの新聞ダネになる人のスマートリクエストを、グループとして警戒または監視できる。
リクエスト警戒グループマネージャのユーザインタフェース
図１９は、好ましい実施例の意味論的ブラウザの「スマートリクエスト警戒」ダイアログボックスを図示する。ダイアログボックスの上半分は、自動警戒グループを追加するのに使われる。ユーザは自動警戒グループタイプとプロフィールタイプ（「全てのプロフィール」、「文脈プロフィール」および実際のプロフィール名）を選択し、それらを自動警戒グループリストに追加する。ユーザはまた、自動警戒グループの削除もできる。ダイアログボックスの下半分は、スマートリクエストを手動警戒グループに追加したり、手動警戒グループから削除したりするのに使われる。
3. 通知マネージャ（ＮＭ）
好ましい実施例では、通知マネージャ（ＮＭ）は、ＲＷＬのスマートリクエストを監視する意味ランタイムクライアントのコンポーネントである。ＮＭは（クライアントの意味論的クエリプロセッサ経由で）ＲＷＬの各スマートリクエストを定期的に呼び出すスレッドを持ち、「結果カウント」および「最終更新時間」でＲＷＬＥを更新する。好ましい実施例では、ＮＭは５−３０秒ごとにスマートリクエストを呼び出すのが好ましい。ＮＭは、（ウェブサービスでの帯域幅使用とスケーラビリティの影響を最小限に抑えるため）ＲＷＬのサイズによって、リクエストチェックの周期性または頻度を知的に調節できる。
（ニュース速報、見出しおよび新聞ダネになる人など）時間に敏感なスマートリクエストに関しては、ＮＭは追加の時間フィルタなしに、スマートリクエストを呼び出すのが好ましい。ただし、（文脈タイプではなく情報として、またはお気に入りや推奨のような時間に非敏感な文脈テンプレート用など）時間に非敏感なリクエストに関しては、ＮＭは（過去１０分間など）時間フィルタでスマートリクエスト用クエリを呼び出すことが好ましい。
4. 警戒グループのモニター
好ましい実施例では、意味論的ランタイムのクライアントは、本発明者が呼ぶところの警戒グループモニター（Ｗａｔｃｈ Ｇｒｏｕｐ Ｍｏｎｉｔｏｒｓ、ＷＧＭ）を管理する。ユーザが警戒グループリストに追加した各警戒グループに対し、クライアントは警戒グループモニターを作成する。警戒グループモニターは、警戒グループ内の各リクエストの新しいリクエストの数を追跡する。警戒グループモニターは、新しい結果を有する警戒グループのＲＷＬＥに待ち行列を作成する。ＷＧＭは、結果の新鮮さを最大限にするために待ち行列を管理する。ＷＧＭは、警戒グループの各リクエストに新しい結果が存在するかを調べるために定期的にＮＭをポーリングする。もし存在する場合、そのリクエストの「最終結果時間」によって、それを待ち行列に追加する。最も新鮮な結果を有するリクエストをまず優先するため、これを行う。プレゼンターで実行されている現在表示されている視的スタイル（スキン）は、次にＷＧＭの待ち行列内のリクエストを待機解除するため、意味ランタイムＯＣＸを呼び出す。こうすると、リクエスト警戒ユーザインタフェースは、新しい結果の存在と結果の鮮度とが一致する。現在表示中のリクエストに新しい結果がもはや存在しないと、スマートスタイルは次のリクエストをＷＧＭの待ち行列から待機解除する。
5. 警戒ペイン
警戒ペイン（Ｗａｔｃｈ Ｐａｎｅ、 ＷＰ）とは、（主な結果ペインの隣の）プレゼンターに表示されるパネルを指し、ユーザ警戒グループの視的表現を保持する。ＷＰはユーザに、リクエスト内に新しい結果があるかどうかが各警戒グループを一目みてわかるようにする。ＷＰはまた、各警戒グループのリアルタイムの状態の表示で現在のビューをユーザに変更させる。次のビューが現在定義されている。
・タイルビュー − すべてのスマートリクエスト内の新しい結果の合計数で警戒グループのタイトルを表示する。
・チッカービュー − すべての警戒グループのスマートリクエスト内の新しい結果の合計数を表示するが、（チッカーとして）各スマートリクエスト内の新しい結果数を連続的に表示するアニメーションを示す。
・プレビューのビュー − チッカービューと似ているが、スマートリクエストごとの最も最近の結果も、チッカーの新しい結果数の横に表示される。
・ディープビュー − このビューでは、ＷＰはすべての警戒グループのスマートリクエスト内の新しい結果の合計数を、各スマートリクエスト内の新しい結果の合計数を示すチッカーと、スマートリクエストごとの全ての新しい結果のスライドショーと共に表示する。
6. 警戒ウィンドウ
ＷＰはまた、ユーザに警戒グループを観察させることができる。ユーザは、ＷＰの警戒グループの１つを選び、それを主な結果のペインにドラッグ（またはそれと同様のテクニックで）して行う。これによって警戒ウィンドウ（Ｗａｔｃｈ Ｗｉｎｄｏｗ、ＷＷ）が形成される。このＷＷは、外観またはレイアウトの点でＴＶのピクチャーインピクチャーの機能に似ているが、いくつかの点で異なっている。その最も顕著なのは、ＴＶのチャンネルが「観られる」のに対し、この場合は、表示されるコンテンツは意味リクエストと結果で構成されていることである。もちろん、根本的なコンテンツ生成技術も異なる。ＷＷは前記ビューのどれにでも表示できる。ただし、ＷＷがディープビューの場合、ＷＷのビュー制御が表示される。以下の制御が現在定義されている。
・リクエストのピン留め − ユーザに、警戒グループの特定のリクエストをピン留めさせることができる。ＷＷはピン留めされたリクエストのみ新しい結果が（周期的に）表示し続け、現在のリクエストがピン留めされている限り、警戒グループのその他のリクエストへ進まない。
・リクエストの交換 − ユーザに、現在表示されているリクエストを意味論的ブラウザで示す主なリクエストと交換させることができる。スマートスタイルは、ＯＣＸ上のメソッドを呼び出し、（ＳＱＭＬバッファでハッシュした）交換したリクエストで一時的なリクエストを作成し、次にプレゼンターに主なリクエストを（ＷＷ内の）の場所に表示するよう連絡する一方で、その一時的なリクエストへとナビゲートする。
・停止、再生、シーク、ＦＦ、ＲＷ、加速化 − ユーザに「警戒グループのリクエストストリーム」を停止、再生、シーク、早送り、巻き戻しまたは加速化させることができる。例えば早送りは、現在表示されているリクエストよりいくつか先のリクエストに進む。
・結果の制御 − ユーザが、警戒グループの各リクエストの結果を制御することができる。実質的には、結果はストリーム内のストリームであり、これによってユーザは、現在の警戒グループの現在のリクエストの結果を制御することができる。
・自動表示モード − 表示する結果がない場合、自動的にＷＷを隠し、新しい結果があるときには、次第に明るくなる。こうして、ユーザは新しい意味論的結果が存在すると警戒ウィンドウが次第に明るくなることを知っているので、画面の占有面積を最大限に活用できる。この機能はまた、個人的および意義的な方法で情報の相互作用を行う間に、ユーザは各自の注意の対象を管理することができる。
・ドッキング、閉じる、最小化、最大化− これらの機能は、その名前の通り、ユーザに警戒ウィンドウをドッキング、閉じる、最小化、最大化にさせることができる。図２０は、フィルタされたスマートリクエストを表示する観察ウィンドウを示す（ワイヤレスに関する見出しなど）。図２０は、フィルタリングされたスマートリクエスト（携帯での「見出し」など）を表示する警戒ウィンドウの図示である。図２０は現在のスマートリクエストのタイトル（「ニュース速報」など）で警戒ウィンドウを図示したものである。
7. 警戒リストの付録
ユーザインタフェースでは、警戒リストは「ニュースの見張り」と命名できる。ユーザは「ニュースの見張り」へ／からリクエスト、オブジェクト、キーワード、テキスト、エンティティなどを追加／削除するのかを問われる。「ニュースの見張り」は、ニューススタンドの警戒ペインで表示することができる。これはユーザのリクエストや（警戒リストに追加されたオブジェクトを経由して、そのオブジェクトをフィルタとして使い、ランタイムによって動的に作成された）動的に作成されたリクエストの空間指向のビューを提供する。ちょうど図書館や本屋に足を踏み入れたときのニュースや雑誌が並んだ棚と光景と同じである。
G. インフォメーションナーバスシステム用のエンティティ仕様
１．概要
エンティティは、インフォメーションナーバスシステムの好ましい実施例の大変強力な機能である。エンティティはユーザに、いかに標準基盤で動作するかをマッピングする文脈定義を作成させる。エンティティの例には次が含まれる。
Figure 2006522388
業界固有のエンティティも存在する。例えば、医薬品では、エンティティには薬品、薬物相互作用問題、特許、ＦＤＡ臨床検査などが含まれる。実質的には、エンティティはスマート文脈オブジェクトである意義的なエンベロープである。エンティティは他の任意のスマートオブジェクトのように、ドラッグ＆ドロップできる。ただし、エンティティはＳＱＭＬとして表されるが、ＳＲＭＬでは表されない（はるかに豊かな意義を持つため、クエリオブジェクトである）。エンティティは、スマートリクエストへのパラメータとして含むことができる。
ユーザは、自分のタスクに基づきエンティティを作成する。好ましい実施例のエンティティは、最低でも以下の情報を包括する（代替実施例では、それ以上それ以下の情報を包括できる）。
１．名前／説明 − エンティティの親しみやすく記述的な名前
２．エンティティのカテゴリ −産業間共通の標準分類法または縦型／会社固有の分類法
３．文脈リソース − キーワード、ローカル文書、インターネット文書または（人々などの）スマートオブジェクトが含まれる。
エンティティは意味論的ブラウザで開くことができ、ナビゲーションのピボットとして、（私のプロジェクトに関する見出しなど）スマートリクエストのパラメータとして使うことができ、ドラッグ＆ドロップ、コピー＆ペースができ、スマートレンズと一緒に使うことができ、スマートスタイルで視覚化でき、組み込み警告の基盤として使え、．ＥＮＴ文書として保存でき、電子メールで送信、共有などができる。つまりエンティティは、ファーストクラススマートオブジェクトである。
意味論的ランタイムのクライアントは、エンティティを参照する新しくて表現力豊かなＳＱＭＬを作成するため、エンティティの充実したメタデータを相関的なリクエストの主題に加えることにより、ＳＱＭＬを動的に作成する。
エンティティは、次のようなその他の強力な特徴を有することが望ましい。
１．トピックに関しては、エンティティはユーザに、自分の私的分類法を作成できる（厳格に定義された公共分類法に翻弄されたり制約を受けたりすることがないので、その結果、リクエストに対しユーザ固有の文脈の通りにマッピングされないかもしれない）。分類法の問題点は、全員のニーズを満たす分類法は存在しないということである。例え同じ組織内であってもである。文脈は大変個人的なもので、エンティティでユーザは個人的な分類法を作成することができる。例えば、スティーブが飼っているカシミールという名の犬（ボクサー犬）の例を取ってみる。（スティーブ以外の）他のみんなにとっては、カシミールは（分類的に）次のように表現される。
生き物
動物
哺乳類
犬
ボクサー
カシミール
しかしスティーブにとっては、カシミールはそれ以外に：
自分の愛する相手
自分のペット
カシミール
しかし、スティーブの獣医にとってカシミールは：
自分のクライアント
自分の犬
健康な自分の犬
カシミール
カシミールを「定義する」のに、（スタンドアロンで）分類法が使われるとすれば、３つの分類法のどれも一般大衆、スティーブ、スティーブの獣医を満足させることはできないであろう。一方エンティティでは、スティーブは「カシミールが自分にとって持つ意味」を基に、「カシミール」のエンティティを作成できる。他の皆も同じことができる。スティーブの獣医もそうである。従ってエンティティは、幅広い分類法の拡張の可能性のある私的トピックを作成させる能力を、ユーザに与える。
別の例では、大手薬品会社の医薬品研究者が、ゲノミクスに関する新しい極秘プロジェクト（「遺伝子プロジェクト」と命名）に取り組むとする。「遺伝子プロジェクト」は社内プロジェクトであるため、当発明者の発明の好ましい実施例の意味論的ブラウザで使える、公的分類法には存在しない可能性が高い。ただし、研究者は「遺伝子プロジェクト」と名づけたエンティティを作成し、プロジェクトとしてタイプし、それを（幅広い分類法で存在する）ゲノミクスに範囲を定めることでエンティティを初期化し、次に（ＡＮＤ演算子を使って）キーワードフレーズの「遺伝子プロジェクト」で修飾する。本質的には、「遺伝子プロジェクト」のフレーズを有するゲノミクス関連事項すべてとして「遺伝子プロジェクト」を定義することに似ている。これは単にキーワード「遺伝子プロジェクト」（単語「プロジェクト」を含む結果でゲノミクスとは何の関係もないを返す可能性がある）を使うよりもはるかに厳密な文脈を課す。ゲノミクスをスコープするが特定の修飾子で「遺伝子プロジェクト」にも拡張する個人的なトピックを定義することにより、研究者ははるかに厳密で個人的な文脈を有する。エンティティは次に（「遺伝子プロジェクトに関する専門家」などの）リクエストを作成するためにドラッグ＆ドロップ、コピー＆ペーストなどができる。ランタイムでは、サーバ側の意味論的クエリプロセッサは、これを（ＳＱＭＬを意味ネットワークにマッピングして）「カテゴリ、ゲノミクスに属するなんらかの情報に関する専門家ＡＮＤフレーズ「遺伝子プロジェクト」も包括する」として解釈する。
２．エンティティで、ユーザは動的分類法も作成できる − 公共分類法は大変静的であり定期的に更新されない。エンティティで、ユーザは自分の私的分類法を動的で考える速度で「拡張」できる。知識は思考速度で転送される。エンティティは、ユーザに自分の心や思考の流れと同じ速度および活力で文脈を作成させることができる。これは著しい飛躍である。例えば、ユーザは新しく計画されたミーティング、発見したばかりの会議、新規顧客、新しく発見した競争相手などのエンティティを、すべてを思考速度で作成できる。分類法ではこれは可能ではない。
３．分類法は、トピックが文脈の唯一のソースであると推定する。エンティティでは、ユーザは抽象的な文脈定義を作成でき、それにはトピックを含むがそれに限定されない。例として、人々、チーム、イベント、会社などが含まれる。エンティティは最終的に、分類法内でトピックに「進化」するかもしれないが（経時的、およびこれらのエンティティが「名声」または「悪評」を取り込むにつれ）、「短時間」では、エンティティはユーザにまだ本格的な分類法エントリに進化していない（または絶対に進化しない可能性もある）文脈を作成させることができる。例えば、ナバナ（我が社）は、当初は（当社とその少数の社員のみに知られた）エンティティであったが、成長し一般の関心を引くようになると、エンティティとして我が社は公共分類法のトピックに進化しつつある。エンティティだと、ユーザは（ナバナのような）文脈が「最終的に」トピックになるのを待つ必要がない。
４．エンティティはユーザに、発明者が呼ぶところの「複合文脈」を作成させることができる。この例はミーティングである。ミーティングは一般に、何人かの出席者と文書、プレゼンテーション用スライドおよび／または議題に関連する配布資料が関与する。インフォメーションナーバスシステムのエンティティを使えば、ユーザはミーティングの意義を捉えた「ミーティング」文脈を作成できる。エンティティ作成ウィザードを使って、ユーザはエンティティがミーティングであることを指定し、次に意味フィルタを指定することができる。５人の出席者と２種類の配布文書と一件のプレゼンテーションスライドのあるプロジェクトミーティングを例として考える。ミーティングのプレゼンターは、ミーティングに具体的に関連する知識を追跡するためのエンティティ作成を希望するかもしれない。例えば、フォローアップミーティングの予定をいつにするかを決める、またはミーティングに関連した特定の活動項目を追跡するため、プレゼンターはこれを行いたいかもしれない。エンティティを作成するため、ユーザは参加者の電子メールアドレス、配布文書およびプレゼンテーションをエンティティのフィルタ定義に追加する。ユーザは次にエンティティを保存すると、それは意味論的ネームスペース／環境を作成する。ユーザは例えば、ミーティングに関連したであろう新しい文書を発見した場合、次にエンティティを新規または削除されたフィルタで（および／または新規名称／説明）を後の日付／時間で編集できる。ユーザがエンティティをドラッグ＆ドロップするか、それをリクエスト／エージェントに包括する際に、意味論的ブラウザはそのエンティティをコンパイルし、同じく解釈用にＸＭＬウェブサービスに送られたサブクエリでそれをマスタＳＱＭＬに包含する。サーバ側の意味論的クエリプロセッサは次に、一連のＳＱＬサブクエリ（または同等のもの）を構築し、これらのクエリを、ＳＱＬサブクエリを使って次に生成されるエンティティのサブクエリと連結して、複合ＳＱＭＬを処理する。
ユーザはＡＮＤまたはＯＲ（またはその他）演算子を使って、エンティティフィルタの適用方法を示す。例えば、ユーザはミーティング（意義的に）とは、ミーティングの参加者および（ＡＮＤ）会議中に配布された文書／スライドであることを示すことができる。エントリがクライアントおよびサーバでコンパイルされると、ＳＱＭＬの同等物を使ってエンティティを（望む演算子で）解釈する。これは大変強力である。つまり、ユーザは「プロジェクトミーティング」と命名されたエンティティを定義でき、そのエンティティを「ニュース速報」と命名された特別エージェントにドラッグ＆ドロップできる。次に（エンティティの識別子を参照する適切なＳＱＭＬで）「プロジェクトミーティングに関するニュース速報」と命名されたリクエストを作成し、それが解釈のためにサーバに送られる前に、サブＳＱＭＬにコンパイルされる。サーバは次に（そのオブジェクトに対して「意味を成す」ことに基づいて）デフォルトの述語をエンティティ内のエントリに適用する。この例では、エンティティの定義のため、サーバは次のみを返す。
全ての（ＡＬＬ）参加者によるニュース速報であり（ＡＮＤ）、意味論的にも（ＡＬＳＯ）全ての（ＴＯ ＡＬＬ）文書／スライドに関連する
例えばこの場合、ミーティングの全参加者が関係しておりかつ会議中に配布される全資料に意味論的に関連する会話／スレッドだけを返す。これが（この場合）ちょうどユーザが望んだことで、意味論的ブラウザは本質的にかなり複雑なクエリを構築する力をユーザに与えたはずである。
それよりもっと複雑なクエリも可能である。エンティティは複合エンティティを可能にするため、その他のエンティティを包含することもできる。例えば、人々のチーム全体がミーティングに関わる場合、プレゼンターはこれらの人々の電子メール配布リストを含むエンティティを作成したいかもしれない。この場合、ユーザは配布リストを求めてインフォメーションナーバスシステムを検索し、結果をエンティティとして保存するかもしれない。ブラウザで、ユーザは結果をエンティティとして保存でき、結果のタイプを基に、「意味を成す」デフォルトのエンティティタイプでエンティティを自動的に作成する。例えば、ユーザが文書の結果をエンティティとして保存する場合、意味論的ブラウザは「トピック」エンティティを作成する。ユーザが人物結果をエンティティとして保存する場合、意味論的ブラウザは「人物」エンティティを作成する。ユーザが電子メール配布リストをエンティティとして保存する場合、意味論的ブラウザは「チーム」エンティティを作成する。
この例では、ユーザは人物結果を人物エンティティとして保存でき、次にそのエンティティをプロジェクトミーティングのエンティティにドラッグ＆ドロップする。ミーティング参加者の電子メール配布リストにマッピングするチームエンティティは、プロジェクトミーティングのエンティティにドラッグ＆ドロップすることができる。ユーザは次に、そのエンティティを含む「プロジェクトミーティングに関する見出し」と呼ばれるリクエストを作成できる。意味論的クエリプロセッサは次に、電子メール配布リストの任意の人物による（ＢＹ）見出しを（適切なデフォルトの述語を使って）返すが、それはミーティングの間に配布された全ての（ＡＬＬ）配布資料に意味論的に関連する。同様に、プロジェクトミーティングに関するドシェ（ガイド）は、ミーティングに関する全ての可能性、ミーティングに関する最も高い可能性、ミーティングに関する専門家などを返す。
ここで留意すべきは、その他のエンティティを含むそのような複合エンティティは、参照整合性がクライアント側の意味整合性チェッカーでチェックされることである。つまり、エンティティＡがエンティティＢを参照し、ユーザがエンティティＢの削除を試みると、意味論的ブラウザはこれを検出し、エンティティＢに未処理の参照があることをフラグする。それでもユーザがエンティティＢを削除する場合、エンティティＡ内の参照（およびエンティティＢへのその他参照）は削除される。代わりに一部の実施例では、エンティティに関連する組織内のその他の許可に基づき、ユーザが同じ状況でエンティティＢを削除するのを（通知されていたか否かに関わらず）禁止される場合がある。例えば雇用主は、一部の会社では電子メールで行うように、ただしもっと潜在的で効果的に、危機管理のために社員の活動を監視する場合がある（もちろん、適切な方針やプライバシーを考慮に入れなくてはならない）。同じ過程がリクエスト集合（ブレンダー）、ポートフォリオ（エンティティ集合−以下を参照）および意味ネームスペース／環境の（ネームスペース／環境でその他の項目を参照する）その他の複合項目にも適用される。
５．人気のあるエンティティも、知識コミュニティのメンバー間で共有できる。（リクエストまたは知識コミュニティ（エージェンシー）のように）意味論的ブラウザのほかの項目のように、エンティティはファイルとして保存できる（のでユーザがあとで開いたり、同僚に電子メールで送信したり、中央ファイル共有などで保存できる）。よくあるシナリオとしては、事業での企業ライブラリアンが、社内プロジェクト、ミーティング、セミナー、タスクおよびその他の関心のある重要な企業知識項目にマッピングするエンティティを作成する。これらのエンティティは次に、ファイル共有または（ポータルまたはウェブサイトなど）その他の共有メカニズムまたは知識コミュニティ（エージェンシー）に保存される。そうすると組織内の知識労働者がエンティティを使うことができる。エンティティが更新されるに従い、好ましい実施例では、ライブラリアンは自動的に自分の文脈を編集でき、また編集して、ユーザは更新または新しいエンティティに同期化することができる。エンティティはまた、個別のユーザによってピア・ツー・ピアベースで交代で共有できる。これは、音楽を共有する合法的なピア・ツー・ピアのファイル共有に似ているが、音楽の代わりに、共有するのは意味、あるいはもっと意義あるコミュニケーションを円滑にするための文脈である。
２．ポートフォリオ（またはエンティティ集合）
ポートフォリオはエンティティの集合を含む、特別なタイプのエンティティである。エンティティは任意のサイズまたは構成が可能で、ポートフォリオは任意の種類または数のエンティティを含むことが可能であるが、好ましい実施例では、（少なくとも命名法または用語の）複雑性や混乱を最小限に押さえるため、ポートフォリオはその他のポートフォリオを包含しない。ポートフォリオはユーザに、ファーストクラスのエンティティを一単位として管理させることができる。ポートフォリオはファーストクラスのエンティティであり、従って前記のエンティティとしての機能全てを備えている。ポートフォリオがスマートリクエストでパラメータとして使われる場合は、ＯＲ修飾子がその包括されるエンティティに（デフォルト設定で）適用される。つまり、もしポートフォリオＰがエンティティＥ１とＥ２を包含する場合、「Ｐに関する見出し」と題されたスマートリクエストは、「Ｅ１またはＥ２に関する見出し」として処理される。ユーザはこの設定を個別のスマートリクエストに対して（ＡＮＤ修飾子に）変更できる。
３．シナリオの例
再度以下のシナリオを検討して行く上で、本システムは、１つには誰が情報を求めているかを「知って」おり、その人物またはグループが誰であるか、およびどのような情報に関心がありそうかを「理解している」ために、概念的により関連した情報を収集できるということを再確認することが役に立つ。もちろん厳密に言えば、本システムは完全な人間の意味では認識または自己認識を持たないし前文で使われた操作を表す動詞は、概念的な暗喩または直喩である。しかしながら、操作と結果において、１つには、本システムの根底にある意味論的情報を与えられたアーキテクチャと実行のため、理解と知識を前例にない度合いまで模倣する。
この点は、単純な対照によって説明できる。二人のまったく別な人間が、Ｇｏｏｇｌｅのような検索エンジンに全く同じ検索を同時に行った場合、全く同じ結果を得る。それと対照的に、本出願のシステムの好ましい実施例では、この二人の人物がエンティティ経由で同じリクエストを行った場合、それぞれに合わせた関連のある別の結果が得られる。
この機能のいくつかの潜在能力を正当に評価するには、システムまたはエンティティは、誰がクエリを投稿しているのかを「知っている」一方で、エンティティは情報に通じており常に更新および情報を持っていることを、（ユーザ情報はいつでも供給および考慮の対象になるが）ユーザに関するその知識に依存していないことに注目すべきである。。もしユーザに依存するならば、システムは多くの状況で効率的かつ有益な結果を得るには、あまりにも大きな労働力を必要するので、労力がかかり過ぎる。その代わりに、エンティティは、本出願や親出願を通して説明するように、誰が要求しているのかを、推論と時には他から提供された特徴から、またあるときは派生または演繹、時には他からのリクエストや同類物によって収集した特性からの意義によって、「知っている」のである。
操作中のエンティティのシナリオ例は次の通りである。
1. 医薬品「特許」エンティティは、特許のカテゴリ、関連キーワードおよび関連文書を包含することができる。
2. ＣＩＡエージェントは、テロリストを追跡するために「テロリスト」エンティティを作成することができる。これにはテロリズムに関するカテゴリ、不審な電信送金、不審な武器販売、機密文書、キーワードおよび情報コミュニティにおけるテロリズムの専門家が含まれる。
3. 昨日のミーティングに関する全てのニュース速報を検索する。
4. 私の任意の競争相手に関する見出しを検索する。（これは、競争相手エンティティを作成し、次に各述語につきＯＲ修飾子を使ってエンティティでスマートリクエストをパラメータとして作成して行う）。
5. 私の投資ポートフォリオ会社に関する専門家を検索する（個別エンティティを作成し、これらのエンティティを含むポートフォリオを作成して、次に「専門家」文脈テンプレートを有し、そのポートフォリオを引数として使うスマートリクエストを作成する）。
6. 私の競争相手に関するドシェ（ガイド）を開く。（個別の競争相手エンティティを作成し、これらエンティティを含むポートフォリオを作成し、次に「ドシェ」（または「ガイド」）文脈テンプレートを有し、そのポートフォリオを引数として使うスマートリクエストを作成する）。図２１は、意味論的ブラウザに表示されたエンティティのビューを表示する（左側）。
H. インフォメーションナーバスシステム用の知識コミュニティ閲覧と登録の仕様
概要
ナバナ意味論的ブラウザにより、ユーザは任意のプロフィールに対し、知識コミュニティ（エージェンシー）を登録および登録解除することができる。これらの知識コミュニティは、意味論環境でのプロフィールエントリの下でユーザがいつでも利用できる。またこれらの知識コミュニティは、同じプロフィールを使って作成された任意のリクエストに対して結果が表示される際にはいつでも、組み込み警告、文脈パネルなど用にデフォルト設定で検索要求される。
意味論環境は、各プロフィールに対し登録された知識コミュニティを示す状態を包含する。クライアント側の意味論的クエリプロセッサ（ＳＱＰ）は、任意プロフィールのリクエストに対する結果から開始される動的リクエスト用に、この情報を利用する（ＳＱＰは意味ランタイムクライアントにプロフィールに対する知識コミュニティを訊ね、次に必要に応じてＸＭＬウェブサービス呼出しを、それらの知識コミュニティに発行する）。
図２２Ａと２２Ｂは、知識コミュニティの登録および登録解除用のユーザインタフェースを示す。ダイアログボックスにはコンボボックスが含まれ、ユーザはプロフィールごとにフィルタリングをしたり、全て、新規、登録済み、推奨するおよび登録解除されたコミュニティを、産業および関心分野別、キーワード別、（全ての発行地点、ローカルエリアネットワーク、エンタープライズディレクトリ、グローバル知識コミュニティのディレクトリの）発行地点別、および（任意時間、今日、昨日、今週、先週の）作成時間別に、表示したりすることができる。意味論的ランタイムクライアントは、これらのフィルタを使って（各発行ポイントに対して）発行地点終点リスナーを検索要求する。次に結果を収集し、それらを結果ペインに表示する。ユーザはまた、各知識コミュニティのカテゴリを、コンボボックス経由の結果ペインで表示できる。図２０Ｂは、知識コミュニティダイアログボックスの一番下の部分を示す。
I. インフォメーションナーバスシステム用のクライアント側の意味論的クエリ文書仕様
１．意味論的クエリマークアップ言語（Ｓｅｍａｎｔｉｃ Ｑｕｅｒｙ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ、ＳＱＭＬ）の概要
本出願の好ましい実施例では、ナバナ意味論的ＤＨＴＭＬの動作は、インターネットエクスプロラＤＨＴＭＬの動作であり、クライアントからの観点では、すべてをクエリ文書として理解する。ワードプロセッサが「テキストおよび複合文書」を開くのと似通った方法で、クライアントは「クエリ文書」を開く。ナバナクライアントは、主にナバナ意味論的クエリ文書を処理し、結果を表示する役目を持つ。ナバナ意味論的クエリ文書は、ナバナ意味論的クエリマークアップ言語（ＳＱＭＬ）の形式で表現され保存される。これは、「意味ファイル形式」と類似している。
好ましい実施例では、ＳＱＭＬの意味ファイル形式は以下で構成される。
・Head − ＨＴＭＬの場合のように、「ヘッド」タグには文書を説明するタグが含まれる。
・Title − 文書のタイトル
・Comments − 文書のコメント
・UserName − 文書作者のユーザ名
・SystemName − 文書が作成されるデバイスのシステム名
・Subject − 文書の主題
・Creator − 文書の作者
・Company − 文書が作成された会社
・RequestType − リクエストのタイプを示す。「smart request」（１つ以上の情報コミュニティウェブサービスへのリクエストを示す）または「dumb request」」（１つ以上のローカルかネットワークリソースへのリクエストを示す）があり得る。
・ObjectType − クエリが返すオブジェクトのタイプを完全修飾する。
・URI − 文書の場所
・CreationTime − 文書の作成時間
・LastModifiedTime − 文書が最後に変更された時間
・LastAccessedTime − 文書が最後にアクセスされた時間
・Attributes − 文書の属性（存在する場合）
・RevisionNumber − 文書の改定番号
・Language − 文書の言語
・Version − クエリのバージョンを示す。ウェブサービスの意味論的クエリプロセッサに、バージョン化した結果を返すことができる。例えば、ブラウザの１つバージョンは、クエリのＶ１を使うことができ、別のバージョンはＶ２を使える。こうしてウェブサービスは、（エージェント用など）リソースレベルとリンクレベルの両方で、逆互換性を提供することができる。
・Targets − クエリ文書が目標とする情報コミュニティウェブサービスの名前とＵＲＬを示す。
・Type − ターゲットタイプを示す。これは、タグが実際のウェブサービスターゲットを示すサブタグを含む「targetentries」とクエリプロセッサがすべての登録情報コミュニティを使う「allsubscribedtargets」がある。
・Categories − クエリ文書が参照する、カテゴリＵＲＬのリストを示す。各「category」エントリには、名前属性およびカテゴリの出所である知識ドメインサーバ（Ｋｎｏｗｌｅｄｇｅ Ｄｏｍａｉｎ Ｓｅｒｖｅｒ、ＫＤＳ）のＵＲＬを示すＵＲＩ属性が含まれる。
・Type − カテゴリのタイプを示す。これは、サブタグがカテゴリエントリのリストを参照する「categoryentries」か、全カテゴリが情報コミュニティウェブサービスからリクエストされる「allcategories」か、クエリプロセッサがユーザのお気に入りカテゴリを得て、これらのカテゴリを含むコンパイルされたＳＱＭＬを生成する「myfavoritecategories」のいずれかである（コンパイルされたＳＱＭＬは次にサーバに送られる）。
・Query − クエリ文書の全ての主なクエリエントリ用の親タグである。
・Resource − クエリされる「ダム」リソースへの参照である。例としてはファイルパス、ＵＲＬ、キャシュエントリ識別子などが含まれる。これらは、解釈プログラムにより、実際のリソースマネージャコンポーネントにマッピングされる。
・Type − ネームスペースで修飾されたリソース参照のタイプである。定義されたリソース参照のタイプの例として、nervana: url（これは、リソース参照が完全形成された標準インターネットＵＲＬであるか、「agent://...」のような特別仕様のナバナＵＲＬであるかを示す）、nervana:filepath（これは、リソース参照が、ファイルシステム上のファイルまたはディレクトリへのパスであることを示す）、nervana:namespaceref （これは、リソースがクライアントの意味ネームスペースから発していることを示す）がある。
・Uri − リソースのユニバーサル リソース識別子を示す。パスとインターネットＵＲＬの場合、これはＵＲＬそのものを指す。ネームスペースのエントリの場合、これはエントリのＧＵＩＤ識別子を示す。
・Mid − メタデータ識別子を示し、ＳＱＭＬ解釈プログラムにより、リソースを文書のメタデータ部分にマッピングするのに使われる。メタデータ識別子は、メタデータ部分内の同じ識別子にマッピングされる。
・Args − リソース識別子の引数を示す。
・Links − 意味論的リンクへの参照を示す（「ターゲット」用のみ）
・Type − リンクのタイプを示す。リンクが明示的なエントリであることを示す「linkentries」であり得る。
・LinkEntries − リンクエントリの詳細を示す。
・Predicate − リンク用の述語タイプを示す。例えば「nervana:relevantto」は、クエリが「オブジェクトＯと関連するリソースＲからの全オブジェクトを返す」であることを示し、ここでＲとＯはそれぞれ指定されたリソースとオブジェクトである。そのほかの述語として、nervana:reportsto, nirvana:teammateof, nervana:from, nervana:to, nervana:cc, nervana:bcc, nervana:attachedto, nervana:sentby, nervana:sentto, nervana:postedon, nervana:containstextなどがある。
・Type − 「リンク」タグで示すオブジェクト参照のタイプを示す。例としては、xml:string, xml:integerのような標準ＸＭＬデータタイプ、同等のナバナ版、nervana:datetimerefのような特別仕様のナバナのタイプ（これは「今日」や「明日」のようなオブジェクトの参照を参照する）、およびナバナが意味論的ＸＭＬオブジェクトとして処理できる１つのオブジェクトを参照する、任意の標準インターネットＵＲＬ（ＨＴＴＰ， ＦＴＰなど）またはナバナＵＲＬ（objects://など）がある。
・Metadata − メタデータエントリの参照を含む。
・MetadataEntry − メタデータのエントリの参照を示す。
・Mid − メタデータの識別子（ＧＵＩＤ）を示す。
・Value − メタデータそのものを示す。
例：文書（情報または文脈ベース）
<?xml version="1.0" encoding="utf-8"?>
<sqml>
<head
requesttype="smart request"
objecttype="context＼headlines"
uri="c:＼foo's＼bar.pdf"
creationtime="foo"
lastmodifiedtime="foo"
lastaccessedtime="foo"
attributes="0"
revisionnumber="0"
language="foo"
version="foo" />
<title>foo</title>
<comments>foo</comments>
<username>foo</username>
<systemname>foo</systemname>
<subject>foo</subject>
<creator>foo</creator>
<company>foo</company>
<targets>
<target
name="Marketing"
reftype="uri"
ref="kisp://marketing/default.wsdl"
/>
<target
name="Research"
reftype="uri"
ref="kisp://research/default.wsdl"
/>
</targets>
<categories>
<category
name="reuters＼pharmaceuticals＼biotechnology"
reftype="uri"
ref="kdsp://reuters.com/categories.wsdl?id=45"
/>
<category
name="reuters＼pharmaceuticals＼life_sciences"
reftype="uri"
ref="kdsp://reuters.com/categories.wsdl?id=57"
/>
</categories>
/>
<resources>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:filepath"
ref="file://c:＼bar.doc"
mid="7886e4a0-55d9-45ac-a084-97adc6fffd0f"
args=""
/>
<resource
name="foo"
type="information＼all information"
reftype="nervana:url"
ref="file://c:＼bar.doc"
mid="01fc64a3-c068-4339-bc97-17e5ff37e93f"
args=""
/>
<resource
name="foo"
type="information＼all information"
reftype="nervana:folderpath"
ref="file://c:＼"
mid="f8cc39c3-e4f0-4a29-be2a-d2faf36eb3a0"
args="includesubfolders=true"
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:url"
ref="http://www.bar.com/doc.htm"
mid="f8cc39c3-e4f0-4a29-be2a-d2faf36eb3a0"
args=""
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:url"
ref="ftp://gate.com/doc.txt"
mid="f8cc39c3-e4f0-4a29-be2a-d2faf36eb3a0"
args=""
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:filepath"
ref="file://＼＼servers＼server＼file.pdf"
mid="1b870a25-4e98-45d8-a444-f0283a495357"
args=""
/>
<resource
name="foo"
type="information＼documents＼text document"
reftype="nervana:text"
ref=""
mid="7886e4a0-55d9-45ac-a084-97adc6fffd0f"
args=""
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:cacheentry"
ref="ef9c90ea-282d-46d6-b355-ac8a4fc2f3e5"
mid=""
args=""
/>
<resource
name="foo"
type="information＼email＼email message"
reftype="nervana:url"
ref="request://email.all@ibm.com"
mid=""
args=""
/>
<resource
name="foo"
type="information＼email＼email annotation"
reftype="nervana:url"
ref="objects://rad.com/agency.asp"
mid=""
args=""
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:url"
ref="objects://rad.com/agency.asp"
mid=""
args=""
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:url"
ref="objects://rad.com/agency.asp"
mid=""
args=""
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:url"
ref="request://documents.all@intel.com"
mid=""
args=""
/>
</resources>
<links>
<link
operator="and"
predicate="nervana:relatedto"
name="foo"
type="information＼documents＼general document"
reftype="nervana:filepath"
ref="file://c:＼foo.doc"
mid="7886e4a0-55d9-45ac-a084-97adc6fffd0f"
args=""
/>
<link
operator="and"
predicate="nervana:contains"
name="foo"
type="information＼documents＼general document"
reftype="nervana:text"
ref=""
mid="46ea76cb-1383-4885-af6f-0e0fc6a66896"
args=""
/>
<link
operator="and"
predicate="nervana:postedon"
name="foo"
type="types＼datetime"
reftype="nervana:datetimeref"
ref=""
mid="3fa64c3c-4754-4380-91b5-521299036c62"
args=""
/>
<link
operator="and"
predicate="nervana:relatedto"
name="foo"
type="information＼documents＼general document"
reftype="nervana:url"
ref="kisp://98@in.com/m.asp"
mid="c2649c39-a1c3-4ca8-ae8d-c85c04372e9a"
args=""
/>
<link
operator="and"
predicate="nervana:isofpriority"
name="foo"
type="types＼priority"
reftype="nervana:priority"
ref=""
mid="69bbc048-98c8-4f76-8edf-5a00ce91c183"
args=""
/>
</links>
<metadata>
<metadataentry
mid="7886e4a0-55d9-45ac-a084-97adc6fffd0f"
reftype="uri"
ref="file://c:＼foo＼bar.pdf" />
<value>
<document>
<title>scenario modelling</title>
<type>text</type>
<format>application/pdf</format>
<filepath>c:＼foo＼bar.pdf</filepath>
<shortfilename>bar.pdf</shortfilename>
<creationtime>foo</creationtime>
<lastmodifiedtime>foo</lastmodifiedtime>
<lastaccessedtime>foo</lastaccessedtime>
<attributes>0</attributes>
<size>0</size>
<subject>foo</subject>
<creator>foo</creator>
<manager>foo</manager>
<company>foo</company>
<category>foo</category>
<keywords>foo</keywords>
<comments>foo</comments>
<hlinkbase>foo</hlinkbase>
<template>foo</template>
<lastsavedby>foo</lastsavedby>
<revisionnumber>0</revisionnumber>
<totaleditingtime>foo</totaleditingtime>
<numpages>0</numpages>
<numparagraphs>0</numparagraphs>
<numlines>0</numlines>
<numwords>0</numwords>
<numcharacters>0</numcharacters>

<numcharacterswithspaces>0</numcharacterswithspaces>
<numbytes>0</numbytes>
<language>foo</language>
<version>foo</version>
<abstract>foo</abstract>
</document>
</value>
/>
<metadataentry
mid="bfcb12b4-70bb-473a-847c-ebffe187828f"
reftype="uri"
ref="file://c:＼foo＼bar.pdf" />
<value>
<email>
<title>scenario modelling</title>
<type>text</type>
<format>application/pdf</format>
<filepath>c:＼foo＼bar.pdf</filepath>
<shortfilename>bar.pdf</shortfilename>
<creationtime>foo</creationtime>
<lastmodifiedtime>foo</lastmodifiedtime>
<lastaccessedtime>foo</lastaccessedtime>
<attributes>0</attributes>
<size>0</size>
<subject>foo</subject>
<creator>foo</creator>
<manager>foo</manager>
<company>foo</company>
<category>foo</category>
<keywords>foo</keywords>
<comments>foo</comments>
<hlinkbase>foo</hlinkbase>
<template>foo</template>
<lastsavedby>foo</lastsavedby>
<revisionnumber>0</revisionnumber>
<totaleditingtime>foo</totaleditingtime>
<numpages>0</numpages>
<numparagraphs>0</numparagraphs>
<numlines>0</numlines>
<numwords>0</numwords>
<numcharacters>0</numcharacters>

<numcharacterswithspaces>0</numcharacterswithspaces>
<numbytes>0</numbytes>
<language>foo</language>
<version>foo</version>
<abstract>foo</abstract>
</email>
</value>
/>
</metadata>
</sqml>
２．ＳＱＭＬの生成
次のようないくつかの方法のうち、１つ以上の方法でＳＱＭＬが生成されることが好ましい。
・スマートリクエストを作成する
・ローカルリクエストを作成する
・エンティティを作成する
・１つ以上のローカル文書を意味論的ブラウザに開く
・クライアントによって（動的に）− ドラッグ＆ドロップ、スマートコピー＆ペースト、組み込み警告、文脈パネル／リンク呼出しなどに呼応して
３．ＳＱＭＬの構文解析
ある状況下の実施例によっては、クライアント上で作成されるＳＱＭＬは、サーバのＸＭＬウェブサービスによって、または別のマシンサイトで、（リアルタイムでの）遠隔利用を受け入れる準備ができていない可能性がある。ＳＱＭＬが文書、エンティティ、または（意味論環境で固有の識別子によって識別される）スマートリクエストのようなローカル文脈を参照する際には、特にこれが当てはまる傾向にある（ブレンダー（または集合）にはスマートリクエストへの参照が含まれる。）。好ましい実施例では、クライアントは一般に遠隔利用を受け入れる準備ができているＳＱＭＬを作成する。文書のメタデータ部分における全ての参照に対して、メタデータをキャシュすることによってこれを行うことが好ましい。クエリが呼び出される際に、参照が示すリソースまたはオブジェクトがもはや存在しない場合があるためにこうすることが好ましい。例えば、ユーザは新しい関係リクエストを生成するために、インターネットからの文書をドラッグ＆ドロップするとする。クライアントはリンクから（要約を含む）メタデータを抽出し、メタデータをＳＱＭＬに挿入する。クエリの解決はメタデータのみを使うため、一旦メタデータがＳＱＭＬ文書に挿入されると、クエリは利用する準備ができる。ただし、オブジェクトが参照するリンクは、ユーザが発見した次の日には存在しないかもしれない。そのような場合、リンクが存在しなくなった後で、ユーザが関係リクエストを呼び出しても、メタデータはすでにＳＱＭＬにキャシュされているため、リクエストは依然として有効である。
クライアントのＳＱＭＬパーサは、ＳＱＭＬでメタデータの「遅延」更新を行う。リクエストが呼び出されると、オブジェクトは関係リクエストを作成するのに使われて以来、オブジェクトが変更された可能性がある場合に対処するために、全パラメータのメタデータ（リソースなど）をＳＱＭＬで更新しようとする。オブジェクトが存在しない場合、クライアントは既に存在するメタデータを使用する。さもなければ、クライアントはそのメタデータを更新し、更新されたメタデータを使用する。こうして、オブジェクトが削除された場合でも、ユーザが実際にメタデータの出所のオブジェクトを開こうと試みるまで、ユーザ経験は中断されない。
J. インフォメーションナーバスシステム用の意味論的クライアント側のランタイム制御ＡＰＩの仕様
１．ナバナ意味論的ランタイム制御の導入 − 概要
好ましい実施例では、ナバナの意味論的ランタイム制御は、ナバナの意味論的ユーザ経験を使って、意味論的データを表示するのに使用する特性およびメソッドを公開するアクティブＸ制御である。この制御は、ナバナ意味論的ユーザ経験の必要条件と一致するように、（ＳＲＭＬスキーマを使って）ＸＭＬデータを取り込み、ＤＨＴＭＬ＋ＴＩＭＥまたはＳＶＧアウトプットを生成するＸＳＬＴスキンから主に呼ばれる。原則的にこの実施例では、ナバナ制御は、意味論的なコンテンツ駆動のユーザ経験を生み出すためにＸＳＬＴスキンが位置する上部に「ＳＤＫ」をカプセル化する。以下に挙げるＡＰＩは、好ましい実施例において最終ＡＰＩによって公開されるか使用可能になる機能性を示す。
２．ナバナ意味論的ランタイム制御ＡＰＩ
a. EnumObjectsInNamespacePath
概要
EnumObjectsInNamespacePathメソッドは、ネームスペースパスのオブジェクトを返す。
使用のシナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、ユーザが意味論的ブラウザ内からネームスペースをナビゲートできるように、ネームスペースパスを開くためにこのメソッドを呼び出す。
PROTOTYPE
SCODE
EnumObjectsInNamespacePath(
[in] BSTR Path,
[in] LongQueryMask,
[out] BSTR *pQueryRequestGuid );
b. CompileSemanticQueryFromBuffer
概要
CompileSemanticQueryFromBufferメソッドは、ＳＱＭＬバッファを開いて、それを１つ以上の実行準備ができたＳＱＭＬバッファ内にコンパイルする。例えば、ブレンダーを含有するＳＱＭＬファイルは、各ブレンダーエントリを表わすＳＱＭＬバッファ内にコンパイルされる。ブレンダーにブレンダーが含まれる場合、それらのブレンダーはアンラップされ、ＳＱＭＬバッファがそれぞれの包含されたブレンダーに対して返される。コンパイル済みか「実施準備ができた」ＳＱＭＬバッファは、エージェンシーによって意味論的に処理できるものである。つまり、複数のエージェンシーからのエージェントを有するブレンダーは、ＳＱＭＬを各エージェンシーからの適切なＳＱＭＬで、バッファにコンパイルさせることを示唆する。
注意：バッファが既にコンパイルされている場合、メソッドはＳ＿ＦＡＬＳＥを返し、戻し引数は無視される。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、ＳＱＭＬバッファをコンパイルし、実行準備ができた生成済みの「コンパイル済みコード」を取得するため、このメソッドを呼び出す。典型的なシナリオでは、アプリケーションまたはスキンは、ＳＱＭＬバッファをコンパイルし、次にそれぞれ個別のＳＱＭＬクエリを位置させたいフレームウィンドウを準備する。次にOpenSemanticQueryFromBufferを呼び出して個別のＳＱＭＬ意味論的呼出しを発行し、その結果を個別のフレームに表示することができる。
PROTOTYPE
SCODE
CompileSemanticQueryFromBuffer(
[in] BSTR SQMLBuffer,
[in] DWORD Flags,
[out] DWORD *pdwNumCompiledBuffers,
[out] BSTR *pbstrCompiledBuffers );
c. OpenSemanticQueryFromBuffer
概要
OpenSemanticQueryFromBufferメソッドは、ＳＱＭＬバッファを開いて、非同期的に（ＳＲＭＬ内の）ＸＭＬの結果をＤＯＭの上で発生させ、そこからナバナスキンはイベントをシンクすることができる。ここで留意すべきは、この実施例では、ＳＱＭＬは「コンパイル」され、実行の準備ができていることである。ＳＱＭＬは実行の準備ができていない場合、呼出しは失敗する。ＳＱＭＬバッファをコンパイルするため、CompileSemanticQueryFromBufferを呼び出す。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、コンパイル済みＳＱＭＬバッファを開くためにこのメソッドを呼び出す。
PROTOTYPE
SCODE
OpenSemanticQueryFromBuffer(
[in] BSTR SQMLBuffer,
[in] DWORD Flags,
[out] GUID *pQueryID );
d. GetSemanticQueryBufferFromFile
概要
GetSemanticQueryBufferFromFileメソッドは、ＳＱＭＬファイルを開き、バッファのコンテンツを返す。バッファはその後コンパイルされる／または開かれる。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、処理前にＳＱＭＬファイルをバッファに変換するために、このメソッドを呼び出す。
PROTOTYPE
SCODE
GetSemanticQueryBufferFromFile (
[in] BSTR SQMLFilePath,
[in] DWORD FileOpenFlags,
[out] BSTR *pbstrSQMLBuffer );
e. GetSemanticQueryBufferFromNamespace
概要
GetSemanticQueryBufferFromNamespaceメソッドは、ネームスペースオブジェクトを開き、そのＳＱＭＬバッファを取得する。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、ネームスペースオブジェクトのｉｄおよびパスへのアクセスを既に有する際に、ＳＱＭＬバッファを開くため、このメソッドを呼び出す。
PROTOTYPE
SCODE
GetSemanticQueryBufferFromNamespace(
[in] GUID ObjectID,
[in] BSTR Path,
[out] BSTR *pbstrSQMLBuffer );
f. GetSemanticQueryBufferFromURL
概要
GetSemanticQueryBufferFromURLメソッドは、ＳＱＭＬバッファのＵＲＬをラップし、バッファを返す。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、任意タイプのＵＲＬをＳＱＭＬに変換するため、このメソッドを呼び出す。これにはファイルパス、ＨＴＴＰ ＵＲＬ、ＦＴＰ ＵＲＬ、ナバナエージェンシーのオブジェクトＵＲＬ（「wsobject://」が前置）またはナバナエージェンシーＵＲＬ（「wsagency://」が前置）が含まれる。
PROTOTYPE
SCODE
GetSemanticQueryBufferFromURL(
[in] BSTR URL,
[out] BSTR *pBuffer );
g. GetSemanticQueryBufferFromClipboard
概要
GetSemanticQueryBufferFromClipboardメソッドは、クリップボードのコンテンツをＳＱＭＬに変換し、バッファを返す。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、クリップボードから意味論的クエリを取得するため、このメソッドを呼び出す。アプリケーションはその後、クエリバッファをロードすることができる。
PROTOTYPE
SCODE GetSemanticQueryBufferFromClipboard( [out] BSTR *pBuffer );
h. Stop
概要
Stopメソッドは、現在開かれているリクエストを停止する。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、発行されたばかりのリクエストのロードを停止するため、このメソッドを呼び出す。
PROTOTYPE
SCODE Stop( [in] GUID QueryID );
i. Reflesh
概要
Reflesh メソッドで、現在開かれているリクエストをリフレッシュする。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、現在ロードされているリクエストを更新するため、このメソッドを呼び出す。
PROTOTYPE
SCODE Refresh( [in] GUID QueryID );
j. CreateNamespaceObject
概要
CreateNamespaceObjectメソッドは、ネームスペースオブジェクトを作成し、そのＧＵＩＤを返す。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは通常、新規クエリ文書が開かれたときに、一時的なネームスペースオブジェクトを作成するために、このメソッドを呼び出す。
PROTOTYPE
SCODE
CreateNamespaceObject(
[in] BSTR Name,
[in] BSTR Description,
[in] BSTR QueryBuffer,
[in] LONG AgentObjectType,
[in] LONG Attributes,
[in] LONG NamespaceObjectType,
[out] GUID *pObjectID );
k. DeleteNamespaceObject
概要
DeleteNamespaceObjectメソッドは、ネームスペースのオブジェクトを削除する。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは通常、一時的なネームスペースのオブジェクトを削除するため、このメソッドを呼び出す。
PROTOTYPE
SCODE DeleteNamespaceObject( [in] GUID ObjectID );
l. CopyObject
概要
CopyObjectメソッドは、専用のSQMLクリップボードのフォーマットを使って、意味論的オブジェクトをSQMLバッファとしてクリップボードにコピーする。オブジェクトはその後、関係意味論的クエリ用にエージェントに「ペースト」されるか、その他のオブジェクトまたはエージェント上のレンズとして使われる。
使用シナリオ
ナバナスキンは通常、ユーザがオブジェクトのポップアップメニューから「コピー」メニューオプションをクリックすると、CopyObjectを呼び出す。
PROTOTYPE
SCODE CopyObject( [in] BSTR ObjectSRML );
m. CanObjectBeAnnotated
概要
CanObjectBeAnnotatedメソッドは、任意のオブジェクトに注釈を付けられるかどうかをチェックする。
使用シナリオ
ナバナスキンは通常、「注釈を付ける」コマンドを示すUIを表示するかどうかを決定するため、CanObjectBeAnnotatedメソッドを呼び出す。
PROTOTYPE
SCODE CanObjectBeAnnotated( [in] BSTR bstrObjectSRML );
n. AnnotateObject
概要
AnnotateObjectメソッドは、オブジェクトの電子メール注釈をオブジェクトの出所のエージェンシーの電子メールエージェントへ送信するため、現在インストールされている電子メールのクライアントを呼び出し、それを初期化する。
使用シナリオ
ナバナスキンは通常、ユーザがオブジェクトのポップアップメニューから「注釈を付ける」メニューオプションをクリックすると、AnnotateObjectメソッドを呼び出す。
PROTOTYPE
SCODE AnnotateObject( [in] BSTR bstrObjectSRML );
o. CanObjectBePublished
概要
CanObjectBePublishedメソッドは、任意のオブジェクトが発行できるかどうかをチェックする。
使用シナリオ
ナバナスキンは通常、「発行する」コマンドを示すUIを表示するかどうか決定するために、CanObjectBePublishedメソッドを呼び出す。
PROTOTYPE
SCODE CanObjectBePublished ( [in] BSTR bstrObjectSRML );
p. PublishObject
概要
PublishObjectメソッドは、オブジェクトの電子メール発行物を、オブジェクトの出所のエージェンシーの電子メールエージェントに送信するために、現在インストールされている電子メールクライアントを呼び出し、それを初期化する。
使用シナリオ
ナバナスキンは通常、ユーザがオブジェクトのポップアップメニューから「発行する」メニューオプションをクリックすると、PublishObjectメソッドを呼び出す。
PROTOTYPE
SCODE AnnotateObject( [in] BSTR bstrObjectSRML );
q. OpenObjectContents
概要
OpenObjectContentsメソッドは、適切なビューアーを使ってオブジェクトを開く。例えば、電子メールオブジェクトは電子メールクライアントで開かれ、文書はブラウザで開かれる。
使用シナリオ
ナバナスキンは通常、ユーザがオブジェクトのポップアップメニューから「開く」のメニューオプションをクリックすると、OpenObjectContentsを呼び出す。
PROTOTYPE
SCODE OpenObjectContents ( [in] BSTR ObjectSRML );
r. SendEmailToPersonObject
概要
SendEmailToObjectメソッドは、電子メールを人物または顧客のオブジェクトに送信するために呼び出される。このメソッドは、その人物または顧客のオブジェクトの電子メールアドレスで、電子メールクライアントを開き初期化する。
使用シナリオ
ナバナスキンは一般に、ユーザが人物または顧客のオブジェクトのポップアップメニューから「電子メールを送信」メニューオプションをクリックすると、SendEmailToObjectメソッドを呼び出す。
PROTOTYPE
SCODE SendEmailToObject( [in] BSTR ObjectSRML );
s. GetObjectAnnotations
概要
GetObjectAnnotationsメソッドは、オブジェクトの出所のエージェンシーに関する注釈を取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、オブジェクトが有する注釈のタイトルを表示したいときに、GetObjectAnnotationsメソッドを呼び出す。例えば、ポップアップメニューで、または注釈メタデータをウィンドウに表示したいときなどである。
PROTOTYPE
SCODE
GetObjectAnnotations(
[in] BSTR ObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );
t. IsObjectMarkedAsFavorite
概要
IsObjectMarkedAsFavoriteメソッドは、オブジェクトの出所のエージェンシーでお気に入りとしてマークされたかどうかをチェックするために呼び出される。
使用シナリオ
ナバナスキンは通常、「お気に入りとしてマークする」または「お気に入りとしてのマークを解除する」コマンドのどちらかのＵＩを表示するかを決定するために、IsObjectMarkedAs Favoriteメソッドを呼び出す。オブジェクトが（例えば、エージェンシーから出ていない場合）お気に入りとしてマークできない場合、エラーコードE_INVALIDARGを返す。
PROTOTYPE
SCODE
IsObjectMarkedAsFavorite( in) BSTR ObjectSRML );
u. MarkObjectAsFavorite
概要
MarkObjectAsFavoriteメソッドは、オブジェクトの出所のエージェンシーでお気に入りとしてマークするために呼び出される。
使用シナリオ
ナバナスキンは通常、ユーザが「お気に入りとしてマークする」コマンドをクリックすると、MarkObjectAsFavoriteメソッドを呼び出す。
PROTOTYPE
SCODE
MarkAsFavorite( in) BSTR ObjectSRML );
v. UnmarkObjectAsFavorte
概要
UnmarkObjectAsFavoriteメソッドは、出所のエージェンシーで、オブジェクトをお気に入りのマークを解除するために呼び出される。
使用シナリオ
ナバナスキンは通常、ユーザが「お気に入りのマークを解除する」をクリックすると、UnmarkObjectAsFavoriteメソッドを呼び出す。
PROTOTYPE
SCODE
UnmarkAsFavorite( in) BSTR ObjectSRML );
w. IsSmartAgentOnClipboard
概要
IsSmartAgentOnClipboardメソッドは、スマートエージェントがクリップボードにコピーされたかどうかをチェックするために呼び出される。
使用シナリオ
ナバナスキンは通常、「ペーストする」アイコンを表示するためにユーザインタフェースをトグルするか、「ペーストする」コマンドが呼び出したいときに、IsSmartAgentOnClipboardメソッドを呼び出す。
PROTOTYPE
SCODE
IsSmartAgentOnClipboard();
x. GetSmartLensQueryBuffer
概要
GetSmartLensQueryBufferメソッドは、スマートレンズのクエリバッファを取得するために呼び出される。これによってクリップボード上のスマートエージェントにあり、任意のオブジェクトに意味論的に関連するオブジェクトを表すクエリのSQMLを返す。
使用シナリオ
ナバナスキンは通常、ユーザがクリップボード上のスマートエージェントからスマートレンズを呼び出すために、「スマートレンズとしてペーストする」を押すと、GetSmartLensQueryBufferを呼び出す。
PROTOTYPE
SCODE
GetSmartLensQueryBuffer(
[in] BSTR ObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );
y. OpenObjectContents
概要
OpenObjectContentsメソッドは、適切なビューアーを使ってオブジェクトを開く。例えば、電子メールオブジェクトは電子メールクライアントで開き、文書はブラウザで開く。
使用シナリオ
ナバナスキンは通常、ユーザがオブジェクトのポップアップメニューから「開く」メニューオプションをクリックすると、OpenObjectContentsメソッドを呼び出す。
PROTOTYPE
SCODE OpenObjectContents( [in] BSTR ObjectSRML );
Part
３．電子メール制御のＡＰＩ
a. Email_GetFromLinkObjects
概要
Email_GetFromLinkObjectsメソッドは、電子メールオブジェクトの出所であるエージェンシーから、電子メールオブジェクトに関する「送信者」リンク用のメタデータを取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、電子メールオブジェクトから「送信者」リストにナビゲートするか、「送信者」リストの人物の名前でポップアップメニューを表示したいときに、Email_GetFromLnikObjectsを呼び出す。
PROTOTYPE
SCODE
Email_GetFromLinkObjects(
[in] BSTR EmailObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );
b. Email_GetToLinkObjects
概要
Email_GetFromLinkObjectsメソッドは、メタデータの出所のエージェンシーから電子メールオブジェクトに関する「宛先」リンク用のメタデータを取得する際に呼び出される。
使用シナリオ
ナバナスキンは通常、電子メールオブジェクトから「宛先」リストにナビゲートするか、「宛先」リストの人物の名前でポップアップメニューを表示したいときに、Email_GetToLinkObjectsメソッドを呼び出す。
PROTOTYPE
SCODE
Email_GetToLinkObjects(
[in] BSTR EmailObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );
c. Email_GetCcLinkObjects
概要
Email_GetCcLinkObjectsメソッドは、メタデータ出所のエージェンシーから電子メールオブジェクトに関する「ＣＣ」リンク用メタデータを取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、電子メールオブジェクトから「ＣＣ」リストにナビゲートするか、「ＣＣ」リストの人物の名前でポップアップメニューを表示したいときに、Email_GetCcLinkObjectsメソッドを呼び出す。
PROTOTYPE
SCODE
Email_GetCcLinkObjects(
[in] BSTR EmailObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );
d. Email_GetBccLinkObjects
概要
Email_GetBccLinkObjectsメソッドは、メタデータの出所のエージェンシーから電子メールオブジェクトに関する「ＢＣＣ」リンク用メタデータを取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、電子メールオブジェクトからの「BCC」リストにナビゲートするか、「BCC」リストの人物の名前でポップアップメニューを表示したいときに、Email_GetBccLinkObjectsメソッドを呼び出す。
PROTOTYPE
SCODE
Email_GetBccLinkObjects(
[in] BSTR EmailObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );
e. Email_GetAttachmentLinkObjects
概要
Email_GetAttachmentLinkObjectsメソッドは、メタデータの出所のエージェンシーから電子メールオブジェクトに関する「添付書類」リンク用メタデータを取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、電子メールオブジェクトから「添付書類」リンクへナビゲートするか、「添付書類」リストの添付書類のタイトルでポップアップメニューを表示したいときに、Email_GetAttachmentLinkObjectsメソッドを呼び出す。
PROTOTYPE
SCODE
Email_GetAttachmentLinkObjects(
[in] BSTR EmailObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );
４．人物制御ＡＰＩ
a. Person_GetDirectReports
概要
Person_GetDirectReportsメソッドは、メタデータの出所のエージェンシーから人物オブジェクトに関する「直属の部下」リンク用メタデータを取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、人物オブジェクトから「直属の部下」リンクにナビゲートするか、「直属の部下」リストの直属の部下の名前でポップアップメニューを表示したいときに、Person_GetDirectReportsメソッドを呼び出す。
PROTOTYPE
SCODE
Person_GetDirectReports(
[in] BSTR EmailObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );
b. Person_GetDistributionLists
概要
Person_GetDistributionListsメソッドは、メタデータの出所のエージェンシーから人物オブジェクトに関する「配布リストのメンバー」リンク用メタデータを取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、人物オブジェクトから「配布リストのメンバー」リンクへナビゲートするか、人物が属する配布リストの名前でポップアップメニューを表示したいときに、Person_GetDistributionListsメソッドを呼び出す。
PROTOTYPE
SCODE
Person_GetDistributionLists(
[in] BSTR PersonObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );
c. Person_GetInfoAuthored
概要
Person_GetInfoAuthoredメソッドは、メタデータの出所のエージェンシーからの人物オブジェクトに関する「人物の著作情報」用メタデータを呼び出す。
使用シナリオ
ナバナスキンは通常、人物オブジェクトから「人物の著作情報」リンクへナビゲートするか、その人物が著作したタイムクリティカルまたは最近の情報の付いたプレビューウィンドウを表示するため、Person_GetInfoAuthoredメソッドを呼び出す。
PROTOTYPE
SCODE
Person_GetInfoAuthored(
[in] BSTR PersonObjectSRML,
[in] BOOL SemanticQuery,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );
d. Person_GetInfoAnnotated
概要
出所のエージェンシーから人物オブジェクトに関する「人物が注釈を付けた情報」リンク用メタデータを取得するため、Person_GetInfoAnnotatedメソッドが呼び出される。
使用シナリオ
ナバナスキンは通常、人物オブジェクトからの「人物が注釈を付けた情報」リンクへナビゲートしたいか、人物が注釈を付けたタイムクリティカルな情報、または最近の情報でプレビューウィンドウを表示したいときにPerson_GetInfoAnnotatedメソッドを呼び出す。
PROTOTYPE
SCODE
Person_GetInfoAnnotated(
[in] BSTR PersonObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );
e. Person_GetAnnotationsPosted
概要
Person_GetAnnotationsPostedメソッドは、メタデータの出所のエージェンシーからの人物オブジェクトに関する「人物が掲載した注釈」リンク用メタデータを取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、人物オブジェクトから「人物が掲載した注釈」リンクにナビゲートするか、人物が掲載したタイムクリティカルな注釈、または最近の注釈でプレビューウィンドウを表示したいときに、Person_GetAnnotationsPostedメソッドを呼び出す。
PROTOTYPE
SCODE
Person_GetAnnotationsPosted(
[in] BSTR PersonObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );
f. Person_SendEmailTo
概要
Person_SendEmailToメソッドは、電子メールを人物または顧客のオブジェクトに送信するために呼び出す。メソッドは、電子メールクライアントを開き、その人物または顧客のオブジェクトの電子メールアドレスで初期化する。
使用シナリオ
ナバナスキンは通常、ユーザが人物または顧客のオブジェクトのポップアップメニューから、「電子メールを送る」メニューオプションをクリックすると、Person_SendEmailToメソッドを呼び出す。
PROTOTYPE
SCODE Person_SendEmailTo( [in] BSTR ObjectSRML );
５． システム制御イベント
a. イベント: OnBeforeQuery
概要
OnBeforeQueryイベントは、制御がクエリを現在の意味論的リクエストと一致するリソースに発行する前に送出される。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、クエリが発行される前にクエリまたはキャシュ状態を取り消したい際に、このイベントをシンクする。
PROTOTYPE
VOID
OnBeforeQuery(
[in] GUID QueryID,
[in] BSTR QueryBuffer,
[in] DWORD QueryMask,
[in] DWORD Flags,
[out] BOOL *Cancel );
b. イベント: OnQueryBegin
概要
OnQueryBeginイベントは、制御が最初のクエリを現在の意味論的リクエストと一致するリソースに発行する際に送出される。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、クエリが進行中に状態をキャシュするか、状態情報を表示したいときにこのイベントをシンクする。
PROTOTYPE
VOID
OnQueryBegin( [in] GUID ObjectID );
c. イベント: OnQueryComplete
概要
OnQueryCompleteイベントは、制御がクエリを現在の意味リクエストと一致するリソースに発行する前に送出される。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、クエリが発行される前にクエリまたはキャシュ状態を取り消したいときに、このイベントをシンクする。
PROTOTYPE
VOID
OnQueryComplete( [in] GUID QueryID );
d. イベント: OnQueryResultsAvailable
概要
OnQueryResultsAvailableイベントは、非同期メソッド呼出しの使用可能な結果が存在するときに送出される。イベントはリクエストGUIDを示し、それを通して、呼び出した側は返答を生成した特定のメソッド呼出しを一意に識別できる。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、制御のメソッド呼出しへの返答を得るために、このイベントをシンクする。
PROTOTYPE
VOID
OnQueryResultsAvailable(
[in] GUID QueryID,
[in] SCODE QueryResult,
[in] BSTR Results,
[in] DWORD NumResults,
[in] DWORD QueryMask,
[in] VARIANT ResultsParam );
e. 付録 A
QUERY MASK VALUES
#define QM_RESULTS 0x01
#define QM_RESULTCOUNT 0x02
#define QM_NEWRESULTS 0x04
#define QM_NEWRESULTCOUNT 0x08
#define QM_DEFAULT ( QM_RESULTS )
例:
Person_GetInfoAuthored(
PersonObjectSRML,
QM_RESULTS | QM_RESULTCOUNT,
&QueryRequestGuid );
K. インフォメーションナーバスシステム用セキュリティの仕様
１． 権限
概要
「人々」ＤＳＡは、ＬＤＡＰディレクトリＵＲＬおよびグループ名で初期化される。「ユーザ」ＤＳＡもまた、ＬＤＡＰディレクトリＵＲＬおよびグループ名で初期化される。一般的に、「ユーザ」は「人々」のサブセットである。例えば、医薬品会社は、異なる大型の医薬品カテゴリ（バイオテク、ライフサイエンス、薬理学など）用にＫＩＳをインストールする可能性がある。これらカテゴリのそれぞれは、そのカテゴリに関して知識があるか、関心のあるユーザグループを有する。ただし、ＫＩＳはまた、その会社の全社員をポピュレートした「人々」グループも有する。これはＫＩＳのユーザが、全社員の母集団のメンバーをＫＩＳのユーザでなくてもナビゲートすることができる。また推論エンジンは、必ずしもＫＩＳのユーザだけでなく、会社内の人々から意味論的リンクで専門知識を推論できる。
これはまた、ＫＩＳレベルのアクセス制御にも有益である。つまり、ウェブサービス層でアプリケーションサーバが提供するアクセス制御を相補または補足する。ユーザグループは、ＫＩＳ知識へのアクセスを有する人々を包括する。ただし人々のグループは、ＫＩＳへのアクセスを有しなくても、ＫＩＳ知識に関連のある人々を包括する。
人々とユーザＤＳＡの両方が、意味論的メタデータ格納（ＳＭＳ）内の人々のテーブルにポピュレートされ、適切にオブジェクトタイプＩＤを示す。ここで留意すべきは、パスワードはＳＭＳの人々のテーブルに格納されないほうが好ましいことである。
ユーザＤＳＡはまた、ユーザ認証テーブル（Ｕｓｅｒ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｔａｂｌｅ 、ＵＡＴ）にもポピュレートされる。これは、ユーザ名をパスワードにマッピングするメモリ内のハッシュテーブルである。サーバのウェブサービスは、ＩＰａｓｓｗｏｒｄＰｒｏｖｉｄｅｒインタフェースまたはその同等物を実装する。ＰａｓｓｗｏｒｄＰｒｏｖｉｄｅｒの実装で、特定のユーザ名にマッピングするパスワードを返す。以下のC#の例は、これを説明する。
namespace WSDK_Security
{
public class PasswordProvider : Microsoft.WSDK.Security.IpasswordProvider
{
public string GetPassword( string username )
{
return "opensezme";
}
}
次のC#コードは、ユーザが認証された後でウェブサービスがどのようにユーザ情報を取得するかを示す。
using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Web;
using System.Web.Services;
using Microsoft.WSDK.Security;
using Microsoft.WSDK;
namespace WSDK_Security
{
public class Service1 : System.Web.Services.WebService
{
[WebMethod]
public string PersonalHello()
{
string response = "";
SoapContext requestContext = HttpSoapContext.RequestContext;
if (requestContext == null)
{
throw new ApplicationException("Non-SOAP request.");
}
foreach (SecurityToken tok in requestContext.Security.Tokens)
{
if (tok is UsernameToken)
{
response += "Hello " + ((UsernameToken)tok).Username;
}
}
return response;
}
}
}
ナバナウェブサービスはその後、呼出しユーザネームでサーバ意味ランタイムを呼び出すことができる。ランタイムは次に、これをＳＱＬにマッピングし、意味論的クエリを発行するために適切なフィルタを使用する。
ナバナＡＳＰ．ＮＥＴアプリケーションに関しては、親構成コンポーネントの子として、以下のエントリがＷｅｂ．ｃｏｎｆｉｇファイルに追加される。
<microsoft.wsdk>
<security>
<passwordProvider
type="WSDK_Security.PasswordProvider, WSDK-Security" />
</security>
</microsoft.wsdk>
a. クライアント側の認証リクエスト
ＵｓｅｒｎａｍｅＴｏｋｅｎをリクエスト用に作成するため、ナバナクライアントは、ユーザネームとパスワードをＳＯＡＰリクエストの一部として渡す必要がある。ナバナクライアントは、複数のトークンをリクエストの一部として送ることができるが、これはユーザの識別情報が複数の認証プロバイダ全体で連合されている場合にこれは好ましい。ナバナクライアントは、ユーザが供給したすべてのユーザアカウント情報（ユーザネームおよびパスワード情報を含む）を収集し、これらをＷＳ−セキュリティトークンに変換し、次にＳＯＡＰリクエストを発行する。クライアントコードは、以下のように表示される（参照：http://www.msdn.microsoft.com）。
localhost.Service1 proxy = new localhost.Service1();
UsernameToken clearTextToken
= new UsernameToken("Joe",
"opensezme",
PasswordOption.SendHashed);
proxy.RequestSoapContext.Security.Tokens.Add(clearTextToken);
label1.Text = proxy.PersonalHello();
b. サーバ上でのＵｓｅｒｎａｍｅＴｏｋｅｎの検証
(http://msdn.microsoft.com/library/default.asp?url=/library/enus/
dnwssecur/html/wssecwithwsdk.asp)
ＷＳＤＫはセキュリティのヘッダ構文を検証し、パスワードハッシュをパスワードプロバイダからのパスワードと照らしてチェックするが、要請に基づいて行われることが望ましい追加的な検証がある。例えば、パスワード要素を包含しないＵｓｅｒｎａｍｅＴｏｋｅｎを受信した場合、ＷＳＤＫはパスワードプロバイダを呼び出さない。チェックするパスワードが存在しない場合、パスワードプロバイダを呼び出す理由はない。つまり、ＵｓｅｒｎａｍｅＴｏｋｅｎのフォーマットを自分たちで検証する必要があるということである。
もう１つの可能性として、リクエストに１つ以上のＵｓｅｒｎａｍｅＴｏｋｅｎ要素が含まれていることである。ＷＳ−セキュリティは、別々の目的に使える任意数のトークンをリクエストに含めるためのサポートを提供する。
ＵｓｅｒｎａｍｅＴｏｋｅｎにハッシュパスワードが含まれていることを検証し、単一のＵｓｅｒｎａｍｅＴｏｋｅｎを持つ着信リクエストのみを受け入れるように、ナバナウェブメソッド用に上記のコードを変更できる。変更したコードは次のとおりである。
[WebMethod]
public string ProcessSemanticQuery( string Query )
{
SoapContext requestContext = HttpSoapContext.RequestContext;
if (requestContext == null)
{
throw new ApplicationException("Non-SOAP request.");
}
if (requestContext.Security.Tokens.Count == 1)
{
foreach (SecurityToken tok in requestContext.Security.Tokens)
{
if (tok is UsernameToken)
{
UsernameToken UserToken = (UsernameToken)tok;
if (UserToken.PasswordOption
== PasswordOption.SendHashed)
{
return ProcessSemanticQueryInternal( Query, UserToken.Username );
}
else
{
throw new SoapException(
"Invalid UsernameToken password type.",
SoapException.ClientFaultCode);
}
}
else
{
throw new SoapException(
"UsernameToken security token required.",
SoapException.ClientFaultCode);
}
}
}
else
{
throw new SoapException(
"Request must have exactly one security token.",
SoapException.ClientFaultCode);
}
return null;
}
２． 人々のグループ
ＫＩＳは人々のグループ用のメタデータを包含する。これらは現代のオペレーティングシステムのユーザグループのようである。人々のグループはナバナのファーストクラスのオブジェクトである（つまりオブジェクトクラスから受け継ぐ）。また、人々のグループのスキーマは次の通りである。
Figure 2006522388
大抵の場合、人々のグループはディレクトリシステムの（ＬＤＡＰのような）ユーザグループをマッピングする。例えば、ＫＩＳサーバの管理者は、ＫＩＳを設定可能なユーザグループの組をクロールさせる。ユーザグループをクロールし、人々のグループとＳＭＳのユーザテーブルをにポピュレートする人々ＤＳＡが存在する。人々ＤＳＡは次の行動を行う。
・（ＳＭＳに存在しない場合）グループを作成する、あるいは（存在する場合は）グループのメタデータを更新する。
・グループの全ユーザを列挙する（ソースにて、好ましい実施例ではＬＤＡＰディレクトリである）。
・グループの全ユーザに対して、人々オブジェクトを作成する（またはオブジェクトがＳＭＳに既に存在する場合には、メタデータを更新する）。
・（ＢＥＬＯＮＧＳ＿ＴＯ＿ＧＲＯＵＰ意味論的リンクタイプを使って）人々オブジェクトをグループオブジェクトにマッピングして、（ＳＭＳの「ＳｅｍａｎｔｉｃＬｉｎｋｓ」テーブル経由で）意味ネットワークを更新する。これによって、ＳＭＳはグループのメンバーシップ情報を取り込む意味論的リンクを（グループおよびユーザ自身に加えて）有することを確実にする。
３． 識別情報のメタデータ連合
識別情報のメタデータ連合（Ｉｄｅｎｔｉｔｙ Ｍｅｔａｄａｔａ Ｆｅｄｅｒａｔｉｏｎ、ＩＭＦ）とは、情報コミュニティ（エージェンシー）がインターネット上に配置されるが、企業または個人顧客に情報を提供するのに使われる機能を指す。例えば、ロイターは専有コンテンツに依存する企業顧客すべて用の情報コミュニティを設定できる。複数の顧客が情報コミュニティを共有する様な場合（同業界で起こりやすい）には、ロイターは各顧客用に、ＳＭＳ上にグループを持つ。ただし、人々メタデータを使用可能にするには、各顧客は企業ディレクトリをロイターにミラー化させる必要がある。これは、特にセキュリティやプライバシーの観点において問題を生じる可能性がある。企業は、外部のコンテンツプロバイダが、自社社員のメタデータのアクセスを持つことを快く思わないであろう。ＩＭＦは、インターネットがホストする情報コミュニティ（エージェンシー）に、ユーザ認証に充分なメタデータのみをホストさせることで、この問題を解決する。例えば、ロイターは企業顧客のユーザ用ログオン情報のみをＳＭＳに格納する。意味論的ブラウザが、このような不完全なメタデータを含むＳＲＭＬを受信すると、クライアントはユーザの完全なメタデータをフェッチするため、もう１つのクエリを（ＬＤＡＰアクセス、またはエンタープライズディレクトリのメタデータがウェブサービス・ディレクトリ経由で提供される場合はＵＤＤＩ経由で）エンタープライズディレクトリに発行する。外部に格納されたメタデータは、残りのメタデータをフェッチできる識別情報を有するため、これが可能である。クライアントはエンタープライズのファイアウォール内の残りのメタデータをフェッチするため、企業の機密のメタデータは外界とは共有されない。
４． アクセス制御
a. アクセス制御ポリシー
好ましい実施例では、ＫＩＳはアクセス制御意味論を包括し強制実行する。ＫＩＳは「デフォルト設定アクセス」ポリシーを採用する。ここで言うデフォルト設定アクセスは、アクセスが拒否される場合を除いては、ＫＩＳは呼出しユーザに、ＳＭＳの任意メタデータへのアクセスを容認することを意味する。このように、システムは新しい形式のアクセスではなく、新しい形式の拒否が提供できるように拡張することができる。また、拒否する根拠が存在しない場合、ユーザはアクセスを容認されることを示唆する（これはより簡単で欠点のないアクセス制御モデルにつながる）。
ＫＩＳはアクセス制御マネージャ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｍａｎａｇｅｒ、ＡＣＭ）を有する。ＡＣＭは主に拒否意味論的クエリ（Ｄｅｎｉａｌ Ｓｅｍａｎｔｉｃ Ｑｕｅｒｙ、ＤＳＱ）生成の役割を担い、ＳＱＰはそれをクライアントからの任意の意味リクエスト用のクエリに加える。ＡＣＭは以下のメソッドを公開する（C#サンプル）。
String GetDenialSemanticQuery( String CallingUserName )
メソッドは呼出しユーザネームを取り入れ、例外オブジェクトをカプセル化するＳＱＬクエリ（またはその同等物）を返すことが好ましい。例外オブジェクトはＳＱＰによって呼出しユーザに返してはいけないオブジェクトである（つまり、ユーザがアクセスを持たないオブジェクトである）。
次にＳＱＰは、次のような拒否クエリを含む最終的な未加工クエリを構築する。
Aggregate Raw Query AND NOT IN (Denial Query)
例えば、統合未加工クエリが次の場合で：
SELECT OBJECTID FROM OBJECTS WHERE OBJECTTYPEID = 5,
拒否クエリが次のような場合：
SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME <>
'JOHNDOE',
最終的な未加工クエリ（つまりＳＱＰは呼出しユーザに返すために、最終的に実行しＳＲＭＬにシリアル化する）は次のようになる。
SELECT OBJECTID FROM OBJECTS WHERE OBJECTTYPEID = 5 AND NOT IN (SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME <>
'JOHNDOE')
意味論的に、これはおそらく次と同等である。
「５のオブジェクトタイプｉｄを有するが、ＪＯＨＮ ＤＯＥが所有しないオブジェクトリストに含まれない、全オブジェクトを選択する。」
これはたぶん意味論的に次と同等である。
「ＪＯＨＮ ＤＯＥが所有する、オブジェクトタイプＩＤが５である全オブジェクトを選択する。」
b. 一般的なアクセス制御規則
意味論的クエリプロセッサ（ＳＱＰ）が処理した各意味論的クエリには、アクセス制御チェックが含まれる。これによって、呼出しユーザはユーザがアクセスを持つメタデータのみを受信することを確実にする。ＳＱＰは、意味論的クエリを処理する際に、以下のアクセス制御規則を採用する。
1. 好ましくは、クエリが「人々」オブジェクトに対するものである場合（人々、ユーザ、顧客、専門家、新聞ダネになる人など）、戻ってくる「人々」オブジェクトは次のいずれかでなければならない。
・呼出しユーザを含む、あるいは
・呼出しユーザと最低１つの人々のグループを共有し、かつ呼出しユーザ、あるいはシステムによって所有される人々を包含する。
対応する拒否クエリは、次の規則をマッピングするのが好ましい。戻されたオブジェクトは、次の条件を満さなければならない。
・呼出しユーザではない +
・呼出しユーザまたはシステムによって所有されない ＋
・呼出しユーザと任意の人々のグループを共有しない人々を有する
拒否クエリＳＱＬ例
以下のＳＱＬは、アクセス制御ポリシーを強制実行するために、ＡＣＭが生成しＳＱＰが付け加えるアクセス制御拒否クエリを示す。この例では、呼出しユーザの名前は「JOHNDOE」である。
SELECT OBJECTID FROM OBJECTS WHERE
OWNERUSERNAME <> 'JOHNDOE' OR
OWNERUSERNAME <> 'SYSTEM' OR
WHERE OBJECTID NOT IN (SELECT OBJECTID FROM PEOPLE WHERE
NAME='JOHNDOE') OR
WHERE OBJECTID NOT IN
(SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID = ''PERSON AND
PREDICATETYPEID='BELONGS_TO_GROUP' AND SUBJECTID IN (SELECT
SUBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN (SELECT OBJECTID
FROM PEOPLE WHERE NAME='JOHNDOE' ) )
2. 好ましくは、クエリが（文書、電子メール、イベントなど）人々のオブジェクト用でない場合、戻ってくるオブジェクトは次でなければならない。
・呼出しユーザまたはシステムユーザが所有し、かつ
・呼出しユーザがオブジェクトである意味論的リンクのサブジェクトである、あるいは
・呼出しユーザがサブジェクトである意味論的リンクのオブジェクトである、あるいは
・オブジェクトが、最低１つの人々のグループを呼出しユーザと共有する人物である意味論的リンクのサブジェクトである、あるいは
・サブジェクトが最低１つの人々のグループを呼出しユーザと共有する人物である、意味論的リンクのオブジェクトである。
対応する拒否クエリは、次の規則をマッピングするのが好ましい。戻ってくるオブジェクトは次の条件を満たさなくてはならない。
・呼出しユーザが所有しない +
・システムユーザが所有しない +
・呼出しユーザがオブジェクトである意味論的リンクのサブジェクトではない +
・呼出しユーザがサブジェクトである意味論的リンクのオブジェクトではない +
・オブジェクトが、最低１つの人々のグループを呼出しユーザと共有する人物である意味論的リンクのサブジェクトではない +
・サブジェクトが、最低１つの人々のグループを呼出しユーザと共有する人物である意味論的リンクのオブジェクトではない。
拒否クエリＳＱＬサンプル
以下のＳＱＬは、アクセス制御ポリシーを強制実行するため、ＡＣＭが生成しＳＱＰが付け加えるアクセス制御拒否クエリを示す。この例では、呼出しユーザの名前は「JOHNDOE」である。
SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME <>
'JOHNDOE' OR
OWNERUSERNAME <> 'SYSTEM' OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID = ''PERSON' AND OBJECTID IN (SELECT OBJECTID FROM
PEOPLE WHERE NAME='JOHNDOE') OR
WHERE OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS
INNER JOIN PEOPLE WHERE SEMANTICLINKS.SUBJECTTYPEID='PERSON' AND SEMANTICLINKS.SUBJECTID = PEOPLE.OBJECTID) OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID='PERSON' AND PREDICATETYPEID='BELONGS_TO_GROUP' AND SUBJECTID IN (SELECT SUBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE')) OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID='PERSON' AND PREDICATETYPEID='BELONGS_TO_GROUP' AND OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE'))
統合拒否クエリＳＱＬの例
これら２つの規則を統合させることにより、ＡＣＭはアクセス拒否のため、次のような統合クエリをＳＱＰに返す。
SELECT OBJECTID FROM OBJECTS WHERE
OWNERUSERNAME <> 'JOHNDOE' OR
OWNERUSERNAME <> 'SYSTEM' OR
OBJECTID NOT IN (SELECT OBJECTID FROM PEOPLE WHERE
NAME='JOHNDOE') OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID = ''PERSON AND
PREDICATETYPEID='BELONGS_TO_GROUP' AND SUBJECTID IN (SELECT
SUBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN (SELECT OBJECTID
FROM PEOPLE WHERE NAME='JOHNDOE')) OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID = ''PERSON' AND OBJECTID IN (SELECT OBJECTID FROM PEOPLE
WHERE NAME='JOHNDOE') OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS INNER JOIN
PEOPLE ON SEMANTICLINKS.SUBJECTTYPEID='PERSON' AND
SEMANTICLINKS.SUBJECTID = PEOPLE.OBJECTID) OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID='PERSON' AND PREDICATETYPEID='BELONGS_TO_GROUP' AND SUBJECTID IN (SELECT SUBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN
(SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE')) OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID='PERSON' AND PREDICATETYPEID='BELONGS_TO_GROUP' AND OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE'))
シナリオ例
例えば、１つのロイターのエージェンシー（ＫＩＳ）は、ロイターが情報を提供する各エンタープライズ顧客に対して、人々のグループを有する場合がある。エージェンシーは共通の情報ベース（ロイターのコンテンツ）を有するが、エンタープライズ顧客ごとに人々のグループを有する。これらのグループには、競争相手を含む場合もある。このような場合、知識フロー、生成および推論が、競争相手の境界を越えないことを確実にするのが好ましい。例えば、Ａ社の社員はＡ社の競争相手であるＢ社の社員から直接知識を得るべきでなく、（推論経由で）間接的に得るべきでもない。Ａ社の社員は、Ｂ社の社員が注釈を付けた項目への提言を得るべきではない。または、Ａ社の社員は、Ｂ社で働く専門家を検索できるべきではない。もちろんこの場合、Ａ社とＢ社は何らかの意味でパートナーではないと仮定する（もしそうであれば、知識の共有を希望する可能性がある）。知識パートナーの場合、ロイターはＡ社とＢ社の人々のグループを含む人々のグループを（おそらくＬＤＡＰ経由で）作成する。するとロイターＫＩＳは、Ａ社、Ｂ社、およびＡ＆Ｂ社の人々のグループを持つことになる。ＳＭＳはまた、Ａ社とＢ社の人々がこれらのグループに属することを示すメタデータ（「グループに所属」意味論的リンクタイプ経由で）を包含する。このプロセスを設定すると、前記の規則は、Ａ社とＢ社間で知識が共有されることを確実にする。
c. 注釈用のアクセス制御規則
注釈の場合、クエリを行うのとは対照的に、呼出しユーザは意味ネットワークを編集する。この場合、以下の規則が適用される。
１． 好ましくは、注釈が付けられるオブジェクトが人物オブジェクトである場合、そのオブジェクトは次のいずれかでなければならない。
・呼出しユーザか
・最低１つの人々のグループを呼出しユーザと共有し、呼出しユーザまたはシステムが所有する人物
２． 好ましくは、注釈が付けられるオブジェクトが人物でないオブジェクト（文書、電子メール、イベントなど）である場合、オブジェクトは次のいずれかでなければならない。
・呼出しユーザが所有する
・システムが所有する
拒否クエリＳＱＬ例
以下のＳＱＬは、アクセス制御ポリシーを強制実行するため、（注釈用にアクセス制御チェックするために）ＡＣＭが生成しＳＱＰが付加するアクセス制御拒否クエリを示す。この例では、呼出しユーザの名前は「ＪＯＨＮＤＯＥ」である。
SELECT OBJECTID FROM OBJECTS WHERE
OWNERUSERNAME <> 'JOHNDOE' OR
OWNERUSERNAME <> 'SYSTEM' OR
OBJECTID NOT IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE') OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE OBJECTTYPEID='PERSON' AND PREDICATETYPEID='BELONGS_TO_GROUP' AND OBJECTID IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE'))
アクセス制御強制実行
ＡＣＭは、ＫＩＳ上の注釈およびその他書込み演算用のアクセス制御を強制実行する。ＫＩＳ ＸＭＬウェブサービスは、以下のように注釈メソッドを公表する（C#サンプル）。
AnnotateObject( String CallingUserName, String ObjectID );
このメソッドは、拒否クエリを得るためにACMを呼び出す。その後、次のような最終クエリを作成する。
Annotation Object Query AND NOT IN (Denial Query)
好ましい実施例では、注釈のオブジェクトクエリは、常に次のような形式である。
SELECT OBJECTID FROM OBJECTS WHERE OBJECTID=ObjectID,
ここでＯｂｊｅｃｔＩＤは、ＡｎｎｏｔａｔｅＯｂｊｅｃｔメソッドへの引数である。
ＡＣＭはその後、最終アクセス制御クエリＳＱＬを構築し、このＳＱＬを使ってアクセス制御をチェックする。ＡＣＭはそのＳＱＬを返す必要がないため、アクセス制御をチェックするために単に直接呼び出す。また、これは（アクセスか非アクセスかの）バイナリチェックのため、ＡＣＭは拒否クエリが最低一行返すかどうかをチェックするだけである。例えば、最終クエリは次のように表示される可能性がある。
SELECT OBJECTID FROM OBJECTS WHERE OBJECTID = ObjectID AND NOT IN (SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME <> 'JOHNDOE')
ＡＣＭは次に、（ＳＱＬクエリプロセッサ経由で）このクエリを実行し、結果セットにある行数を訊ねる。一行の場合、アクセスは許可されるが、それ以外ではアクセスは拒否される。このモデルは、拒否クエリモデルとの整合性を持たせるためこのように実装される（ＡＣＭは常に拒否クエリを構築し、これをすべてのアクセス制御チェックの基盤として使う）。
L. インフォメーションナーバスシステム用のディープインフォメーションの仕様
ディープインフォメーションメーションの概略
概要
好ましい実施例では、ナバナの「ディープインフォ」ツールは、ナバナ情報オブジェクトに対して、文脈依存の物語風の情報を提供することを目的とする。ディープインフォは本質的に、ナバナのユーザに、特定の文脈において本来なら失われるはずの情報を提供する。おおよその例えでは、ディープインフォは、（現在のアーティスト、流行歌や場合によっては、歌の中の楽器に関する情報を示すＭＴＶのミュージックビデオに表示される文脈情報のようなものである）。
「ディープインフォ」の「ディープ」とは、オブジェクトの出所であるエージェンシーの意味ネットワークで、文脈情報がしばしば複数の「ホップ」に渡ることを指す。「ディープインフォ」は、計画テキストメタデータまたは（ＳＱＭＬ経由での）意味論的クエリリンクでのメタデータのどちらかであり得る「ディープインフォナゲッツ」から成る。
好ましい実施例では、最低５種類のディープインフォナゲッツが存在する。
１． 基本的な意味論的リンクのナゲッツ
２． 文脈テンプレートのナゲッツ
３． 雑学ナゲッツ
４． 仲介役ナゲッツ
５． 再帰ナゲッツ
a. 基本的な意味論的リンクのナゲッツ
基本的な意味論的リンクの真理では、ディープインフォナゲッツは、現在のオブジェクトの意味論的リンクを伝えるのみである。これらのナゲッツは、意味論的リンクの距離１に関与する。この場合、「リンク」文脈／タスクペインに表示されるものとの重複が存在する。それらの例は次の通りである。
・パトリック・シュミッツは、ノサ・オモイグイに直属する
・パトリック・シュミッツは、５つの直接部下を持つ
・パトリック・シュミッツは、４７件のオブジェクトに注釈を付けた
・パトリック・シュミッツは、１３件のオブジェクトを著作した
・パトリック・シュミッツは、５６件の電子メールオブジェクトにコピーされた
b. 文脈テンプレートのナゲッツ
文脈テンプレートのナゲッツは、手許にある情報を基に、各関連文脈テンプレートの文脈情報を表示する。これらのナゲッツは、各文脈テンプレートのタイプに対して、文脈バーまたは文脈パネルに表示されるものと同一である。次はその例である。
・パトリック・シュミッツは、３件のニュース速報項目を掲載した
・パトリック・シュミッツは、１４件の名著を掲載した
・パトリック・シュミッツは、１７件の見出しを著作した
・パトリック・シュミッツは、１３件の会話に参加する
・パトリック・シュミッツは、３５６件のオブジェクトに関する新聞ダネになる人である
c. 雑学ナゲッツ
エージェンシー上のすべての電子メールオブジェクト用の例
・スティーブ・ジュドキンスは、そのうちの全ての「宛先」リストに登場する
・スティーブ・ジュドキンスは、そのうちの２３％に返答した
・パトリック・シュミッツは、そのうちの５０％に注釈を付けた
・そのうちの３件のみが、２より大きいスレッド深度を有する
エージェンシー上のすべての人々オブジェクト用の例
・パトリック・シュミッツは、電子メールをそのうち４７％に送信した
・そのうち１４％は、ノサ・オモイグイに直属する
・サリー・スミスは、そのうちの８５％と会話を持った
・そのうちの１２％は、最低一件のトピックに関する新聞ダネになる人である
・そのうちの全ては、今週最低一件の会話に関わっている
・そのうちの３３％は、最低１つのトピックに関して専門家である
・そのうちの８％は、三つ以上のトピックに関して専門家である
エージェンシー上の任意の配布リスト用の例
・スティーブン・ジュドキンスは、このリストに最多の電子メールを掲載した
・サラ・トレントは、このリストに最多の電子メールに返答した
・ノサ・オモイグイは、このリストに掲載したことがない
・パトリック・シュミッツは、今月このリストに８７件のメッセージを掲載した
・リチャード・ノボトニーは、今年このリストに３４５件のメッセージを掲載した
エージェンシー上のすべての配布リスト用の例
・スティーブン・ジュドキンスは、すべてのリストに最多の電子メールを掲載した
・リサ・ヘイブロンは、すべてのリストのたったの２％にしか電子メールに返答していない
・ノサ・オモイグイは、どのリストにも掲載したことがない
・パトリック・シュミッツは、すべてのリストに最低週に一度は掲載した
・リチャード・ノボトニーは、３つのリストにメッセージを掲載した
エージェンシー上のすべての情報オブジェクト用の例
・スティーブン・ジュドキンスは、最も多作の発行者である（そのうちの５％を発行した）
・サリー・スミスは、最も多作の注釈者である（そのうちの２％に注釈を付けた）
・ノサ・オモイグイは、最も活発な新聞ダネになる人である
・パトリック・シュミッツは、最も統合的な専門知識を持つ
・スティーブ・ジュドキンスは、今年発行された情報に関して最多の専門知識を有する
・ガヴィン・シュミッツは、最も多く会話に参加している（そのうちの１２％）
・リチャード・ノボトニーは、今月最も多く会話に参加した（そのうちの１８％）
d. 仲介役ナゲッツ
人物から人物へ
意味論的リンクベース
・パトリック・シュミッツは、電子メールを１３人に送信した
・４７人がパトリック・シュミッツと同じ「宛先」リストに登場した
・４７人がパトリック・シュミッツと同じＣＣリストに登場した
・合計８９人が、パトリック・シュミッツが送信した電子メールで参照された
・２４人が、パトリック・シュミッツと同じ情報を注釈付けた
・３人が、パトリック・シュミッツと同じ全配布リストに載っている
・２９人が、パトリック・シュミッツの配布リストの最低一件に載っている
文脈テンプレートベース
・１２人が、パトリック・シュミッツと同じ情報カテゴリに関する専門知識を有する
・１４人とパトリック・シュミッツは、同じ情報項目に関する新聞ダネになる人である
・２７人がパトリック・シュミッツと会話している
人物への情報
意味論的リンクベース
・パトリック・シュミッツは、この情報項目を掲載した
・スティーブ・ジュンキンスは、この情報項目を著作した
・この情報項目は、二人にコピーされた
・３人がこの情報項目に注釈を付けた
文脈テンプレートベース（文脈テンプレートのナゲッツと類似）
・この情報項目に関して４人の専門家が存在する
・この情報項目に関して２７人の新聞ダネになる人が存在する
情報から情報へ
文脈テンプレートベース（文脈テンプレートのナゲッツと類似）
・５７８件の関連する「全ての可能性」が存在する
・２３５件の関連する「最も高い可能性」が存在する
・４件の関連するニュース速報項目が存在する
・４６件の関連する見出しが存在する
意味論的リンクベース（人々を経由）
・これと同じ専門家を有する２１件の情報項目が存在する
・これと同じ新聞ダネになる人を有する２３件の情報項目が存在する
・これを掲載したのと同じ人物によって掲載された３４件の情報項目が存在する
・これを著作した同じ人物によって著作された３４件の情報項目が存在する
・これを注釈した人々によって注釈された４４件の情報項目が存在する
e. 再帰ナゲッツ
再帰ナゲッツで、現在の情報ナゲッツのサブジェクトに関するディープインフォメーションを表示することで、文脈階層を形成する。システムは次に、サブジェクトのオブジェクトタイプを基に、ナゲッツを再帰的に表示する。再帰ナゲッツで、システムはソースオブジェクトから開始し、ネットワークパスに沿ってナゲッツを表示するまで、実質的に意味ネットワークを探査する。リソースの制限と一致する深度で、およびユーザフィードバックを基に、探査を停止することが好ましい。
再帰ナゲッツを検討するもう１つの方法は、事業組織チャートの文脈バージョンのようなものである。ただし、インフォメーションナーバスシステムでのディープ情報では、情報［ＩＮＦＯＲＭＡＴＩＯＮ］ツリーとは対照的に、ユーザは知識［ＫＮＯＷＬＥＤＧＥ］ツリーをブラウズできる。例を挙げると、ユーザがオブジェクトを選択すると、ツリービューは次のように表示される。
文書を文脈とする例：
[+]「文書のタイトル」に関する新聞ダネの人
[+] ガヴィン・シュミッツ
[+] 報告先 ->
[+] スティーブ・ジュドキンス
[+] スティーブ・ジュドキンスのような専門家 ->
[+] ノサ・オモイグイ
[+] パトリック・シュミッツ
[+] スティーブ・ジュドキンスのような関心のあるグループ ->
[+] パトリック・シュミッツ
...
[+] チャック・ジョンソン
...
[+]直属部下 ->
[+]ジョー・ウィリアムス
[+] 直属部下 _
[+] ジョー・ウィリアムスのような関心のあるグループ ->
[+] リチャード・ノボトニー
...
[+] ノサ・オモイグイ
...
[+] 関心のあるグループ
[+] 専門家
電子メールを文脈とする例：
[+] 電子メールの送信者:
[+] ノサ・オモイグイ
[+] ノサ・オモイグイのような専門家
...
[+] 電子メールの送信先:
[+] チャック・ジョンソン
[+] チャック・ジョンソンのような専門家
...
[+] 電子メールのコピー先:
[+] リチャード・ノボトニー
[+] リチャード・ノボトニーのような専門家
...
[+] 電子メールの添付物:
foo.doc
[+] foo.docに関する専門家
[+] ガヴィン・シュミッツ
[+] ガヴィン・シュミッツのような新聞ダネになる人
...
[+] 「電子メールのタイトル」に関する新聞ダネになる人
...
会話オブジェクトを文脈とする例：
[+]会話の参加者
[+]スティーブ・ジュドキンス
[+] スティーブ・ジュドキンスのような関心のあるグループ...
...
[+]ノサ・オモイグイ
[+] ノサ・オモイグイのような関心のあるグループ
...
[+] 「会話のタイトル」に関する専門家
[+] リチャード・ノボトニー
[+] リチャード・ノボトニーのような関心のあるグループ
...
上記例で留意すべきは、デフォルトの述語が、人々オブジェクトに人々サブジェクトでリンクされて、（例：リチャード・ノボトニーのような（ＬＩＫＥ） 関心のあるグループ）のＬＩＫＥ 述語が使われていることである。
もう１つの再帰ナゲッツ例を以下に示す。
[+] パトリック・シュミッツがこの電子メールを著作した
[+] パトリック・シュミッツはノサ・オモイグイに直属する
[+] ノサ・オモイグイは６直属部下を有する
[+] スティーブ・ジュドキンス ...
[+] スティーブ・ジュドキンスは...を掲載した
[+] スティーブ・ジュドキンスは...に関する専門家である
[+] スティーブ・ジュドキンスは...の新聞ダネの人である
[+] スティーブ・ジュドキンスは、6件の会話に関わった
[etc.]
[+] リチャード・ノボトニー...
[+] [残りの６直属部下]
[+] ノサ・オモイグイは１３件のオブジェクトに注釈を付けた...
[+] [１３件のオブジェクトに関するさらに多くの文脈テンプレートナゲッツ]
[+] ノサ・オモイグイは２７８件のオブジェクトを著作した
[+] ノサ・オモイグイは２３項目に注釈を付けた [...]
[+] パトリック・シュミッツは、５直属部下を有する
[+] ジョン・ドー ...
[+] 直属部下に関するさらに多くのネイティブナゲッツ
[+] パトリック・シュミッツは４７件のオブジェクトに注釈を付けた
好ましい実施例では、再帰ナゲッツは意味論的ブラウザの各結果オブジェクトの横にあるドリルダウンペイン経由で最も一般的に表示される。これによってユーザは、結果オブジェクトを選択でき、次に（上記に示すとおり）オブジェクトを再帰的かつ意味論的に「探索」できる。
また、ディープインフォのドリルダウンツリービューの各ヘッダ項目は、リクエストへのリンク（例：スティーブ・ジュドキンスのような専門家）になり、各結果はエンティティへのリンクとなる。例えばユーザは、ディープインフォメーションツリービューのどこからでも、（意味論的に）パトリック・シュミッツという「人物」に「ナビゲート」することができる。ユーザは次に、パトリック・シュミッツに関するドシェを表示でき、パトリック・シュミッツをコピーして、それを例えば、パトリック・シュミッツによるニュース速報と呼ばれるリクエストを開くために、ニュース速報にペーストできる。ここでまた留意すべきは、人物サブジェクト（「による」［ＢＹ］）に基づくデフォルトの述語の使用である。
好ましい実施例のプレゼンターのディープインフォのツリービューは（意味論的ブラウザの意味ランタイムＡＰＩからのサポートで）、リクエストであるこれらのリンクや結果オブジェクトであるリンクを追跡する。そうすることにより、ユーザがリンクのツリービューをクリックすると、ユーザの意図を知的に解釈する（リクエストにナビゲート、またはエンティティにナビゲートする）。
M. インフォメーションナーバスシステム用のリクエスト作成ウィザードの仕様
リクエスト作成ウィザードについて
概要
好ましい実施例のリクエスト作成（またはスマートエージェント）ウィザードで、ユーザは（知識統合サーバ上で実行している）１つ以上の知識ソースに発行するべき意味論的クエリを表す、新しいリクエストを、簡単にかつ直感的に作成できる。
ウィザードページ１： プロフィールおよびリクエストタイプの選択：このページはユーザに、どのプロフィールでリクエストを作成するかを選択させることができる。このページはまた、ユーザに作成したいリクエストのタイプを選択させることができる。このタイプには、（リクエストに示されるフィルタに基づいた）各文脈テンプレート、（最も高い可能性、見出し、専門家、新聞ダネになる人など文脈テンプレートに相当する）知識タイプ、（プレゼンテーション、一般文書などタイプに相当する）情報タイプ、およびブレンダーであるリクエストの集合のサブリクエストを含むリクエストを作成し、ユーザにいくつかのリクエストをまとまりのある単位として表示させることができるドシェ（ガイド）であってもよい。図１７Ａを参照のこと。
ウィザードページ２： 知識コミュニティ（エージェンシー）の選択：このページでユーザは、（複数の知識統合サーバ上で実行している）どの知識コミュニティ（知識統合サービス（ＫＩＳ）で実行中）からリクエストが知識を得るべきかを選択できる。ユーザは、リクエストが選択したプロフィールで設定されたのと同じ知識コミュニティを使うべきであることを示すことができる。ユーザはその代わりに、特定の知識コミュニティを選択することもできる。図１７Ｂを参照のこと。
ウィザードページ３： フィルタの選択：このページでは、ユーザはどのフィルタをリクエストに包含するかを選択することができる。フィルタは、キーワード、テキスト、カテゴリ、ローカル文書、ウェブ文書、（人々フィルタ用の）電子メールアドレス、およびエンティティのうちの１つ以上を包含できる。代替実施例では、その他のフィルタのタイプがサポートされる。特性のページはまた、ユーザに特定のフィルタに適用する述語を選択させることができる。公開される最も一般的な述語は「関連する」であることが好ましい。フィルタのタイプと一致するその他の述語（例えば、電子メールアドレスまたはエンティティ経由で人物を参照するフィルタは、リクエストされたタイプが「人々」でない場合、デフォルトの述語「によって［ＢＹ］」（例：ジョン・スミスによる［ＢＹ］見出しを使う）で、リクエストタイプが「人々」の場合、デフォルトの述語「のような［ＬＩＫＥ］」（例：ジョン・スミスのような［ＬＩＫＥ］専門家など）を使う）を公表することができる。特性ページはまた、ユーザにフィルタを適用する演算を選択させる。最も一般的な２つの演算子はＡＮＤ（この場合、全フィルタを満足する結果のみを返す）およびＯＲ（この場合、どれか１つのフィルタを満足する結果を返す）である。図１７Ｃ参照のこと。
ウィザードページ４： このリクエストの命名と説明：このページはユーザに、リクエスト用の名前および説明を入力させる。ウィザードは自動的に、リクエストの意味論を基に、リクエストの名前と説明を提案する。例には次が含まれる。
1. セキュリティおよび［ＡＮＤ］アプリケーション開発および［ＡＮＤ］ウェブサービスに関する見出し。
2. 暗号技法または［ＯＲ］ユーザインタフェースデザインなどに関するＲ＆Ｄからの専門家。
3. 人工知能に関するプレゼンテーション。
4. データマイニングおよび［ＡＮＤ］ウェブ開発に関するドシェ。図１７Ｄを参照のこと。
ユーザは提案される名前／説明を無効にできる。提案は名前および説明の最大長に基づき、必要に応じて切り捨てられる。
意味論的ブラウザもまた、特性シート経由で既存のリクエストの特性を公表する。これによってユーザは、リクエストを「編集」できる。リクエストの意味論に基づきフィールドが初期化されること以外は、特性シートはウィザードと同じユーザインタフェースを公表する（リクエストのＳＱＭＬ表示を連続化解除することによる）。図１７Ｅを参照のこと。
N. インフォメーションナーバスシステム用のプロフィール作成ウィザードの仕様
プロフィール作成ウィザードについて
概要
プロフィール作成ウィザードによって、ユーザは新しいユーザプロフィールを簡単かつ直感的に作成できる。
ウィザードページ１： 関心ある分野の選択：このページでユーザは、自分が関心のある分野を選択できる。これによって意味論的ブラウザは、（ユーザが勤務する業界など）ユーザの知識的関心についての高度な情報を得ることができる。この情報は次に、カテゴリダイアログのカテゴリ選択を絞り、ユーザの関心分野などと一致する知識ドメインで設定した新しい知識コミュニティ（エージェンシー）を推奨するのに使われる。図４５Ａを参照のこと。
ウィザードページ２： 知識コミュニティの選択：このページでユーザはプロフィール用の知識コミュニティを登録できる。これによって意味論的ブラウザは、リクエストがプロフィール用に作成された際に、どの知識ソースにリクエストを発行するかを「知る」ことができる。意味論的ブラウザはまた、視覚化、意味論的警告、（レンズが任意プロフィールのリクエスト／エージェントである際の）スマートレンズ、（目標オブジェクトが任意プロフィールからの結果である際の）オブジェクトレンズを呼び出し、ユーザがオブジェクトを任意プロフィールのリクエスト／エージェントなどにドラッグ＆ドロップ（またはコピー＆ペースト）する際に、プロフィールで知識コミュニティを使う。図４５Ｂを参照のこと。
ウィザードページ３： このプロフィールの命名と説明：このページでユーザは、プロフィールの名前と詳細を入力できる。このページでユーザは、プロフィールをデフォルトプロフィールにするのが好ましいかどうかを示すことができる。意味論的ブラウザの任意操作において、ユーザがプロフィールを明確に示さない場合、デフォルト設定のプロフィールが使われる（例えば、特定のプロフィールを表すアイコンに文書をドラッグ＆ドロップすると、そのプロフィールでブックマークが開くが、ファイルシステムからの文書を意味論的ブラウザが表すアイコンにドラッグ＆ドロップすると、デフォルトプロフィールからの文書でブックマークが開く）。図４５Ｃを参照のこと。
O. インフォメーションナーバスシステム用のブックマーク作成ウィザードの仕様
１．ブックマーク作成ウィザードについて
概要
ブックマーク作成（またはローカル／ダムリクエストエージェント）ウィザードでユーザは、意味論的ブラウザでローカル／ウェブ文書、エンティティなどを表示するための新しいブックマーク（ローカル／ダムリクエスト）を簡単かつ直感的に作成できる。それを経由して、ユーザは（ドラッグ＆ドロップ、スマートコピー＆ペースト、スマートレンズ、スマート警告、視覚化など）のシステムのツールボックスにアクセスできる。
ウィザードページ１：プロフィールとリクエストタイプの選択：このページでユーザは、何のプロフィールにブックマークを作成するかを選択できる。このページでユーザは、ブックマークに／から項目を追加／削除することができる。図４６Ａを参照のこと。
ウィザードページ２：このブックマークの命名と説明：このページでユーザは、ブックマークの名前と詳細を入力できる。ウィザードはブックマークの項目に基づき、ブックマークの名前と詳細を自動的に提案する。例は次の通りである。
・文書１、文書２および文書３
・「暗号」と一致する文書
・フォルダ「マイドキュメント」とサブフォルダ内の文書
・ナバナのプレゼンテーション（２００３年７月）．ｐｐｔおよび［ＡＮＤ］フォルダ「マイドキュメント」とサブフォルダの文書内の「セキュリティ」と一致する文書
ユーザは提案された名前／説明を無効にできる。提案は名前および説明の最大長に基づき、必要に応じて切り捨てられる。図４６Ｂを参照のこと。
２．シナリオ
蛋白質工学に関する全てのプレゼンテーションを表示
リクエスト作成ウィザードを使って、（文書＼プレゼンテーションで）プレゼンテーション情報タイプを選択し、次に蛋白質工学カテゴリをフィルタとして選択する。次へを押すと、リクエストの意味論に基づき、ウィザードはリクエスト名を知的に提案する（蛋白質工学に関するプレゼンテーション）。ウィザードはまた、適切なデフォルト述語を選択する。終了を押す。ウィザードはクエリをコンパイルし、ＳＱＭＬを選択したプロフィールのＫＩＳへ送り、その後結果を表示する。
３．知的な発行ツールのメタデータ提案とメンテナンス
インフォメーションナーバスシステムは、発行ツール（文書の著者など）によって格納されるメタデータに依存しないが、このようなメタデータが使用でき依存できることは有益である。先行技術の問題点の１つは、発行ツール（Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄ、Ａｄｏｂｅ Ａｃｒｏｂａｔなど）が、メタデータの作成およびメンテナンスの過程を知的に管理しないことである。本発明の好ましい実施例が、メタデータ作成およびメンテナンス過程の向上に使用できる方法を次に示す。
a. ユーザは新規文書を作成する際に、著者の電子メールアドレス（ユーザの電子メールクライアントからプログラムによって取得でき、ユーザが数件のアドレスを有する場合、発行ツールはユーザにどちらのアドレスを使うかを訊ねる）を（著者名のみの代わりに）文書のメタデータヘッダに追加する。これは電子メールアドレスのほうが、はるかに一意性を提供するからである（例えば、「ジョン・スミス」という名前は何百万という人々のうちの一人を指すため、文書のメタデータ内の係るデータはそれほど有用ではない）。ここで留意すべきは、メタデータヘッダ内で使う電子メールアドレスの可能性としては、例えばログオンユーザの単一サインオンアカウント（Ｍｉｃｒｏｓｏｆｔ Ｐａｓｓｐｏｒｔ（登録商標）など）から取得できることである。
b. 文書が編集され、（メタデータヘッダで表示するように）現在のユーザが文書の著者と異なる場合、ユーザはメタデータヘッダをそれに応じて変更するかどうかの入力を促される。こうして知的メタデータメンテナンスの一定の基本形式を提供する。
このモデルは、（現在ログオンされているユーザの名前および電子メールアドレスのように）発行ツールがフィールドを認証できる場合に、異なるオブジェクトタイプやメタデータフィールド全体に適用できる。
P. インフォメーションナーバスシステム（登録商標）用の意味論的スレッドの仕様
１． 意味論的スレッド
概要
好ましい実施例では、意味論的スレッドは注釈または会話のスレッドを表すＫＩＳ意味ネットワークのオブジェクトである。通常の電子メールスレッドも意味論的であるが、意味論的スレッドはそれとは異なる。意味論的スレッドはオブジェクト識別子およびタイプ識別子（ＯＢＪＥＣＴＴＹＰＥＩＤ＿ＴＨＲＥＡＤ識別子）のスレッド固有の意味論的リンクを有し、１つ以上のオントロジーベースの知識ドメインを通じて意味を伝達し、動的リンクをサポートする。また、インフォメーションナーバスシステムにおいてファーストクラスのオブジェクトであるため、クエリ、コピー、ペースト、ドラッグ、ドロップすることができ、スマートおよびオブジェクトレンズで使用できる。図２３は、意味論的スレッドオブジェクトとその意味論的リンクを図示する。
意味論的スレッドオブジェクトは、意味ネットワークとインフォメーションナーバスシステム全体のファーストクラスのメンバーであるため、システムのその他のオブジェクトのように、巧みな操作、プレゼンテーションやクエリの影響を受ける。例えば、意味論的ブラウザはユーザに、人物オブジェクトから人物が参加した全スレッドに（「参加者」述語を経由して − ＰＲＥＤＩＣＡＴＥＴＹＰＥＩＤ＿ＰＡＲＴＩＣＩＰＡＮＴＯＦＴＨＲＥＡＤの述語タイプＩＤにより）ナビゲートすることができる。ユーザは次に、スレッドから全スレッドの参加者（人々）にナビゲートでき、そこから続けて動的にナビゲートできる。別の例をとると、スレッドオブジェクトは任意文脈でも、最も高い可能性（または「なし」が指定されている場合は「なし」）になり得る。
好ましい実施例では、意味論的スレッドオブジェクトは意味も伝達する。スレッドはシステムの意味論的クエリ経由で返すことができるということを意味するため、これは有益である。例えば、「トピックＡとトピックＢに関する全スレッドを検索」である。ＫＩＳは、文書のようなその他オブジェクトで行うのと同様に、意味論的スレッド用の意味論的リンクを維持する。ただし、意味論的スレッドは複数のオブジェクトに参照できるため、スレッドの意味論はスレッドが包含するオブジェクトと共に進化する。例えば、スレッドは１つのトピックで開始して、すばやくその他トピックを包含するように進化できる。電子メールスレッドは、開始した場所から大変異なる「意味論的ドメイン」で終わることができる。参加者が新しい観点を紹介し、新しい情報がスレッドに追加され、電子メールの添付ファイルがスレッドに追加されるなど、すべてが意味を基盤に行われる。
ＫＩＳは意味論的スレッドの「意味論的進化」を管理する。スレッドのコンテンツを「追跡」するために、意味論的リンクをスレッドに追加することによってこれを行う。例えば、スレッドが１つの文書と注釈で始まる場合、ＫＩＳは文書と注釈が所属するカテゴリのそれぞれに、意味論的リンクをそのスレッドに追加する、つまり、スレッドは包含する文書と注釈と同じ意味論を持つようにアサートされる。（ユーザが最初の注釈に注釈を付ける場合など）別の注釈がスレッドに追加される場合、ＫＩＳは既にスレッドからリンクされている新しい注釈のカテゴリの新リンク強度を計算する。新しい注釈は全体のスレッドの意味論を特定の観点から弱化または強化できるため、これをするのは好ましい。ただし、スレッドからすでに存在するカテゴリの意味論的リンクの強度を変更することは、カテゴリごとのベースで行うのが好ましく、その他のオブジェクトと同様に、スレッドは異なる強度で複数のカテゴリに属することができる。新しいリンクの強度は、少なくとも２種類の方法で計算できる。簡単な実施例では、スレッドにリンクされるカテゴリの全リンク強度の平均が使われる。ただし、強度が弱いスレッドにある項目が多すぎると、全体のスレッドの（ＫＩＳ意味論的クエリプロセッサに関する限りでは）「知覚」意味論を侵食し得るというマイナスである。代替実施例は、最大のリンク強度を使うことである。ただし、スレッドが新しいドメイン／カテゴリに「移行した」としても、スレッドの意味論がドメイン／カテゴリに固定される可能性があるため、これも不利な点がある。加重平均の観点から、スレッドのサイズが大きくなるに従い、紛らわしい結果を表示する可能性がある。
好ましい実施例では、ＫＩＳがスレッドにリンクされるカテゴリに対し、全リンク強度の加重平均を計算するのが好ましい。この新しい加重平均は、リンク強度となる。加重平均は、スレッドの各オブジェクトにある概念の数を使って計算するのが好ましい。これは「意味論的に軽量な」オブジェクト（短い掲載文など）が、スレッドの「意味論的に密度の高い」オブジェクト（電子メールの添付物や長い掲載物など）に対して、スレッドの意味論を侵食しないことを確実にするという利点がある。オブジェクトのサイズは、オブジェクトの概念的重量のそれほど確実なインジケータではないため、概念のサイズでなく数が好ましい実施例では使われる。例えば、文書には画像を包含するか、またはキーフレーズまたは概念にうまくマッピングされない情報を包含することができる。
計算した重量には、エントリが追加された時間も包含することが好ましい（従って比較的新しいものに対して、古い項目の意味論の「エージング（ａｇｉｎｇ）」を行う）。この重量は次にカテゴリのリンク強度で乗じ、その倍数を追加し、エントリ数で割る。その他の計量スキームも適用できる。
以下の規則は、新規項目が意味ネットワークに追加され、それがさらに意味論的スレッドに追加される際に適用される。
1. スレッドに追加する新規項目を分類する。
2. 意味論的スレッドに既存の、戻されたカテゴリリストの各カテゴリに対して次を行う
｛
・新しい加重平均リンク強度を計算する
・意味論的スレッドオブジェクトから、カテゴリの意味論的リンクを更新する
｝
3. 意味論的スレッドに既存でない、戻されたカテゴリリストの各カテゴリに対して次を行う
｛
・リンク強度を割り当てる
・意味論的スレッドオブジェクトから、カテゴリの意味論的リンクを追加する
｝
加重平均リンク強度は、次のように計算される。
Figure 2006522388
Ｃｉがオブジェクトｉの概念の正規化数（０から１）である場合、Ｌｉはオブジェクトｉのリンク強度であり、Ｎはそのスレッドのオブジェクト数（新規オブジェクトを含む）である。概念の正規化数は、各オブジェクトの概念数（知識ドメインマネージャ（Ｋｎｏｗｌｅｄｇｅ Ｄｏｍａｉｎ Ｍａｎａｇｅｒ、ＫＤＭ）から抽出）をスレッドの最大オブジェクト（新規オブジェクトを含む）の概念数で割って計算する。
意味論的スレッドが標準、組み込み（および未編集の）の電子メールスレッドから成る場合、ＫＩＳは意味ネットワークを別の方法で変更する。これは大半の電子メールクライアントには、最新の電子メールメッセージにスレッドを形成する全ての前電子メールメッセージが含まれるからである。このような場合、ＫＩＳは最新の電子メールメッセージを全スレッドの代表として単に利用することが好ましい。これを達成するには、ＫＩＳは最新の電子メールメッセージを分類し、スレッドオブジェクトから（カテゴリに関連の）以前の意味論的リンクをすべて、新しいカテゴリとリンク強度と一致する新しい意味論的リンクと交換することが好ましい。
非電子メールスレッド（例えば、意味ネットワーク内の既存オブジェクトの注釈に基づいて形成されるスレッド）に関しては、上記で説明したモデルが用いられるべきである。その代わりに、ＫＩＳは統合スレッド文書（Ａｇｇｒｅｇａｔｅ Ｔｈｒｅａｄ Ｄｏｃｕｍｅｎｔ、ＡＴＤ）を維持でき、それを分類する。この文書はオブジェクトのテキストをスレッドに包含するが、それは電子メールメッセージが同じスレッドに以前のメッセージを包含するのとおおよそ似通っている。
新しいオブジェクトがスレッドに追加されると、ＫＩＳは意味メタデータ格納（ＳＭＳ）のスレッドオブジェクトを最後に変更した時間を更新することが好ましい。
２．意味論的スレッドの会話
インフォメーションナーバスシステムの意味論的スレッド会話は、意味論的スレッドの特別な形式である。実質的に、会話は一人以上の参加者を有する意味論的スレッドである。意味論的スレッドの会話は、オブジェクトタイプｉｄ、ＯＢＪＥＣＴＴＹＰＥＩＤ＿ＴＨＲＥＡＤＣＯＮＶＥＲＳＡＴＩＯＮを有する。
ＫＩＳは、そのスレッドの参加者数に基づきスレッドを作成し、そのスレッドをスレッド会話として速やかに作成できる。その代わりに、ＫＩＳは追加の参加者が検出されると、スレッドを会話に「アップグレード」できる。
３．意味論的スレッドの管理
以下の擬似コードは、ＫＩＳが好ましいスレッドと会話をどのように意味ネットワークに追加するかを示す。
1. 個別の電子メールメッセージが検出され、それが既存スレッドオブジェクトのメンバーである場合
｛
・新しい電子メールオブジェクトをスレッドに追加し、意味ネットワークを更新する
・スレッドに一人以上の参加者がいる場合、スレッドのオブジェクトタイプ識別子をＯＢＪＥＣＴＴＹＰＥＩＤ＿ＴＨＲＥＡＤＣＯＮＶＥＲＳＡＴＩＯＮに変更する
｝
２. 電子メールスレッドが検出された場合
｛
・新しいスレッドオブジェクトを作成し、意味ネットワークを更新する
・スレッドに一人以上の参加者がいる場合、スレッドのオブジェクトタイプ識別子をＯＢＪＥＣＴＴＹＰＥＩＤ＿ＴＨＲＥＡＤＣＯＮＶＥＲＳＡＴＩＯＮに変更する
｝
３. 既存オブジェクトの電子メール注釈が検出された場合
｛
・注釈を意味ネットワークに追加する
・注釈を付けたオブジェクトそのものが注釈でない場合
｛
・新しいスレッドオブジェクトを作成し、意味ネットワークを更新する
｝
さもなければ
｛
・新しい注釈を注釈付きオブジェクト（すなわち既存注釈）を含むスレッドに追加し、意味ネットワークを更新する
・更新されたスレッドに一人以上の参加者がいる場合、スレッドのオブジェクトタイプ識別子をＯＢＪＥＣＴＴＹＰＥＩＤ＿ＴＨＲＥＡＤＣＯＮＶＥＲＳＡＴＩＯＮに変更する
｝
｝
Q. スクリーンショットの例
図２４−４４Ｂは、上記で説明した機能、オプションや操作をさらに詳しく図示する追加のスクリーンショットの例である。
R. インフォメーションナーバスシステムの意味論的クエリ定義および視覚化の仕様
１．意味論的画像と動画
a. 概要
意味論的画像と動画は、ナバナの意味論的ユーザ経験という点では、好ましい実施例の有益なコンポーネントになり得る。つまり、本システムでのユーザ経験は、ナバナエージェンシー（情報コミュニティ）に格納されナバナＸＭＬウェブサービス経由でアクセスした意味論的画像／動画メタデータを有する実施例によって強化される。この実施例では、ナバナを経由して、エンドユーザは画像への文脈および時間に敏感な意味論的アクセスを有する。例えば、ゲティイメージス（またはコービス）のエージェントを電子メール上のスマートレンズとして使うと、呼び出されると、メッセージに意味論的に関連する画像を開く。あるいは、意味論的に関連する画像を表示するために、文書を自分のハードドライブからゲティエージェントへドラッグ＆ドロップすることを想像していただきたい。これで（画像スキーマと一致する）画像メタデータが持てる。ナバナのツールボックスは同じ状態であり、画像用の新しい情報オブジェクトタイプを追加したに過ぎない。また、異なるビュー、サムネール、スライドショー、フィルタリング、統合など、意味論的画像用の意味論的スキンも存在する。意味論的画像の例は、次で閲覧できる。
http://creative.gettyimages.com/source/search/resultsmain.asp?source=advSearch&hdnSync=Medicine%7E0%2C12%2C449%2C3%2C15%2C1%2C0%2C0%2C0%2C12287%2C0%2C7%2C14%2C6%2C3%2C3%2C0%2C12%2C449%2Cen%2Dus&UQR=tfxfwz
ごく一般的には、意味論的視覚化の特性は、いくつかの異なる変数によって変化する。システムの機能または特性が呼び出されている対象の文脈をふくむ文脈がその変数である場合が多くある。次のいくつかの項では、意味論的決定を左右する文脈変数の一部をリストする／または説明する。多くの場合、意味論的視覚化の変数または決定要因には重複または共通性が存在するが、場合によっては、考慮または考慮の組合せが具体的な状況にとって一意的である。
b. 業界固有の意味論的画像と動画
業界固有の意味論的画像／動画は、（業界にマッピングされる）１つ以上のカテゴリに対する意味論的結果の表示雰囲気の一部として使うことができる（そして好ましい実施例では使われている）。例えば、ｈｔｔｐ：／／ｗｗｗ．ｃｏｒｂｉｓ．ｃｏｍおよびｈｔｔｐ：／／ｗｗｗ．ｇｅｔｔｙｉｍａｇｅｓ．ｃｏｍを閲覧し、以下にリストされたするキーワードで検索をかける（統合では、業界標準分類法に基づき、目標業界にマッピングされる）。このような画像／動画は、文脈および（文脈テンプレートおよびカテゴリにマッピングされる）カテゴリスキン用の背景、フィルタ効果、変換および動画としても使える。また、これらの画像／動画は、優れたスクリーンセーバー用にこれらの画像の一部から抽出した動画パス用のビジュアルにも使える。例えば、これらの意味論的画像（「電力」業界用に電球の中で回転するメタデータなど）の１つから抽出した動画パスに沿って、その他の周辺画像や動画などのクロムと併せて、メタデータおよび視覚化を表示するスキンを想像していただきたい。業界固有の画像と動画を持つ他の業界として次が挙げられる。
Figure 2006522388
例えば、ユーザがバイオインフォマティックスまたは蛋白質工学に関する見出しというリクエスト／エージェントを開始する場合、意味論的ブラウザはＳＱＭＬからのバイオテク関連カテゴリをバイオテク業界の一組の画像にマッピングする。次に１つ以上の画像を、そのリクエスト／エージェントの結果用のスキンの一部として表示する（その結果、リクエスト／エージェントの視覚的な「雰囲気」を伝えると共に、心地よいユーザ経験となる）。
図１０１は医薬品／バイオテク業界用の意味論的画像の例である（コービスウェブサイトから許可を得たもので、左側には人間の顔に芸術的ＤＮＡへリックスが重ね合わせたもの、および右側には有機的化学チャートがある）。
同じことが情報タイプおよび文脈テンプレートに対しても適用される。スキンは文脈／情報タイプとカテゴリ／オントロジーに基づいて気の利いた（スマートな）ことを行い、これらの特性全体で意味論的画像／動画を知的方法で組み合わせる。例えば、「ワイヤレス技術に関する見出し」と題するエージェントは、「見出し」画像／動画と「ワイヤレス」画像／動画の間でトグルできる画像／動画ベースのアニメーションを見せる、クロム（および／またはスマート砂時計、以下を参照）を包含することができる。「ワイヤレスに関する見出しおよび半導体に関するニュース速報、および製品仕様に関連して私のグループの誰かが書いた電子メール」と題するブレンダーは、「見出し」、「ニュース」、「ワイヤレス」、「半導体」および「電子メール」用の画像／動画間で「トグルする」クロム（および／またはスマート砂時計）を包含することができる。
プレゼンターのクエリプロセッサは、全文脈テンプレートと情報タイプおよび（エージェント／ブレンダーＳＱＭＬからの）全カテゴリを列挙し、それに応じてクロムアニメーションを設定することができる。
情報タイプに関しては、（コービスやゲティなどで）次の検索を入力する。
Figure 2006522388
また、文脈テンプレートに関しては、次の検索を入力する。
Figure 2006522388
また、意味論的画像／動画は、全く無作為でないほうが好ましい。ただし、決まった組からでないほうが好ましい。注意深く選択したもので、スキンは選択した組から無作為に選択できるのが望ましい。しかし、例えばコービスまたはゲティイメージスなどの全体の組から無作為に選ばないほうが好ましい。そうしないと、くだらない画像、漫画および場合によっては攻撃的か不適切な画像がある可能性がある。また、これらのガイドラインの一部は、スキンの主題が微妙、適度、刺激的または超刺激的なモードのいずれかによって、変化するのが好ましい。微妙モードでは、スキンは視覚化ピボットごとに１つの画像／動画の選択を決定するかもしれない。その他のモードでは、これは退屈なユーザ経験になる可能性がある。
あまり派手でないモードでは、スキンは意味論的画像／動画を、パワーポイントのスライドデック背景（アルファ・ブレンドされたものなど）のようなクロムの一部として使うことができる。意味論的画像／動画はまた、（文脈バー、パネルまたはパレット上で）視覚化の一部として、およびスマート砂時計（以下を参照）でも使える。文脈および情報タイプの視覚化用に、意味論的画像／動画は、情報タイプまたは文脈を明確に示すよう慎重に選択することが望ましい。また、選択モードはスキン特性でも良い。
また、スキンごとに使える意味論的画像／動画の数は、画像／動画がどこに表示されるかによって、上限を定める必要が生じる場合がある。ただし、シナリオによっては、その必要はないかもしれない。例えば、ブレンダーのスキンは、ユーザがブレンダーの結果を（ページからページまたはエージェントからエージェントの）ナビゲートするに従い、ブレンダーから現在表示されているものとの一貫性を持たせるために、クロム背景間で循環させる可能性がある。これはまたスキン特性でも良い。
c. クライアント側の意味論的画像と動画のキャシュ
プレゼンターは、クライアントに（インストール時に）ダウンロードされ格納される意味論的画像と動画で、気の利いた（スマートな）拡張可能なクライアント側キャシュを有する。スキンは次に、この事前にキャシュされた画像と動画から選択できる。画像／動画は、ユーザのお気に入りのカテゴリと（その人物が選択する）関心のある分野に基づいて事前にキャシュでき、それは目標とする業界にマッピングされる。スキンは次に、（ナバナ、またはコービス、ゲティイメージスのようなサードパーティサーバが提供するサーバ側の画像／動画を公表するＸＭＬウェブサービスで）画像サーバへのオンデマンド画像クエリで、事前にキャシュした意味論的画像／動画を補完することができる。
プレゼンターはまた、気の利いた（スマートな）ことを行い、バイアス機能を使って、最近ダウンロードされた画像／動画が（タイブレーカーとして）それより古いものより先に選択される。「使用数」もまた各画像／動画と共にキャシュされ、プレゼンターは、どの画像／動画をいつ表示するかをフィルタする際にこの数を使う。このような「ロード平衡」は、より新鮮で繰り返しのないユーザ経験をもたらす。
キャシュは（ユーザの意味論的クエリに基づき）要求に応じてポピュレートされるのが好ましい。例えば、ボーイング社においてユーザのマシンに医療品画像／動画を事前にキャシュしても意味がない。キャシュサイズにも上限を決め、画像キャシュマネージャが「古い」および「未使用」画像を、ＬＲＵアルゴリズムまたはその同等物を使って消去することが好ましい。こうすれば、キャシュは、ユーザのエージェントの使用パターンおよびお気に入りのエージェントリストと「意味論的に同期」にできる。
２．スマート砂時計
「意味論的ユーザ経験」を提供するために、ナバナのプレゼンターが行う呼出しの過半数は、ＸＭＬウェブサービスへの遠隔呼出しであろう。このような場合、予測不可能で潜在的に無限の遅延がＵＩに発生する可能性がある。エンタープライズ内ではかなりの量の帯域幅およびサーバ馬力が期待できるものの、ナバナユーザインタフェースは、メソッド呼出しに未知数の待ち時間を「予定」しておかなくてはならない。
今日のオペレーティングシステムは、ディスクまたはネットワークへの無限のＩ／Ｏ呼出しに関連するこの問題を有する。一部のＣＰＵ集中演算も、かなりの遅延を有する。Ｗｉｎｄｏｗｓ（登録商標）およびＭａｃのＵＩでユーザは、通常「砂時計」の形をした「待ち」カーソル経由で遅延を知覚させられる。
好ましい実施例では、プレゼンターは（ＳＱＭＬ「メソッド呼出し」への直接的なアクセス経由で）意味論的ヒントを得て、それによって「スマートまたは意味論的砂時計」の同等物を表示する。これが「ローディング中」またはその他の効果を表示する、中間ページの形式であり得る。追加としてプレゼンターは、クエリが代表するカテゴリおよび情報タイプまたは文脈テンプレートに関するヒントを得るため、ＳＱＭＬを読み込むことにより、クエリの意味論を伝えることができる。プレゼンターは次に、結果をまだ受信していなくても、これらのヒントを使ってクエリと一致する意味論的画像およびテキストを表示することができる。より多くのヒントをクエリが得るほど、砂時計はより賢く（スマートに）なる。ウェブサービスから実際の結果が到着し、（必要であれば）最終結果を発生させるためにプレゼンターにより統合される前であっても、「ローディング中」のページは次に、「次に来るもの」の雰囲気を伝えることができる。
「スマート砂時計」は、主な結果ペインだけでなく、スマートレンズの吹き出しポップアップウィンドウおよびインラインのプレビューウィンドウ（実質的には、ウェブサービスへのすべての呼出しサイトおよび「焦点」がある場所）にも表示できる。プレゼンターは、「砂時計」を表示する前にクエリをタイムアウトすることにより、気の利いた（スマートな）ことができる（たぶん数百ミリ秒後で、このための数字に到達するために、実装は有用性テストを行うべきである）。
３．視覚化 − 文脈テンプレート
概要
文脈テンプレートは、情報アクセスおよび取得のために特定の意味論的モデルにマッピングされるシナリオ主導型の情報クエリのテンプレートである。本質的に文脈テンプレートは、事前定義された意味テンプレートを用いて情報をユーザに伝達する、個人的で、デジタル意味論的な情報取得「経路」として考えることができる。文脈テンプレートは、１つ以上エージェンシー全体で情報を統合することが好ましい。
以下で説明する文脈テンプレートは、定義済みである。各種の意味論的情報の統合および流布向けの補足的な文脈テンプレートが予期される（その例には、感情（「怒り」、「悲しみ」などに関連する文脈テンプレート、場所、移動性、周囲の条件、ユーザタスクなどのための文脈テンプレートが含まれる）。
ニュース速報
ニュース速報の文脈テンプレートは、どのように意味論的情報を伝達するかという点で、ＣＮＮの「ブレイキングニュース」プログラム挿入部分の個人的なデジタル版に 類推によって説明することができる。文脈テンプレートでユーザは、情報作成または発行時間、および情報の重要性を定義する設定可能な時間数に従って並べ替えられた、非常にタイムクリティカルな情報に、１つ以上のエージェンシーからアクセスできる。
図１０２は、ニュース速報文脈テンプレート用の意味論的に適切な画像の視覚化を図示したものである。
ニュース速報 − オブジェクトおよび文脈バーの視覚化の例
以下は、ニュース速報文脈に適切な視覚化の例または代表的要素のリストである。好ましい実施例の全ての視覚化（またはそのコンポーネント）と同様に、「雰囲気」または意味論的感覚または含意が、特定の文脈には適切である。大変大まかな類推をすると、１つの「舞台セット」が映画の脚本の特定の場面に適切でなければならないのと同様に、視覚化はアプリケーション内の文脈に適している。これはこの特定のオブジェクトや文脈バーの視覚化だけでなく、好ましい実施例の全ての視覚化にも当てはまる。
1. 来るべきニュース速報項目の合計数の背景の上に、最も最近または保留中のニュース速報項目の発行または予定時間を示す時を刻む時計
2. 意味論的画像の上に、最も最近または保留中のニュース速報項目の発行または予定時間を示す時を刻む時計
3. 意味論的画像とニュース速報項目の合計数の上に、最も最近または保留中のニュース速報項目の発行または予定時間を示す時を刻む時計
4. 無地の背景の上に、最も最近または保留中のニュース速報項目の発行または予定時間を示す時を刻む時計
5. 様々な背景の上に、全てのニュース速報項目の（順に）発行または予定時間を示す時を刻まない時計
6. 様々な背景の上に、最も最近または保留中のニュース速報項目の発行または予定時間を示すカレンダービュー
7. 様々な背景の上に、全てのニュース速報項目の（順に）発行または予定時間を示すカレンダービュー
8. 最も最近または保留中のニュース速報項目の発行または予定時間によって、フォントサイズを拡大／縮小
9. ニュース速報の項目数によって、フォントサイズを拡大／縮小
10. 最も最近または保留中のニュース速報項目の発行または予定時間によって、動画レートで描くフォント（光るテキスト、回転テキスト、動画パス上のテキストなど）
11. ニュース速報の項目数によって、動画レートで描くフォント（光るテキスト、回転テキスト、動画パス上のテキストなど）
12. 最も最近または保留中のニュース速報項目の発行または予定時間によって、変化するフォントの色
13. ニュース速報の項目数によって変化するフォントの色
14. ニュース速報の意味論的画像またはその同等物のアニメーショングラフィック
15. ニュース速報の項目数
16. 順に描かれるニュース速報項目のタイトル（リストビュー）
17. 順に描かれるニュース速報項目のタイトルと詳細（タイルビュー）
18. オブジェクトの周りの環状動画パス上で動く、意味論的画像／動画
19. 意味論的画像／動画背景上の項目数を示す吹き出しポップアップ
20. 無地な背景で意味論的画像／動画で描かれる項目数を示す吹き出しポップアップ
見出し
見出しの文脈テンプレートは、意味論的情報をどのように伝えるかという点で、ＣＮＮの「ヘッドラインニュース」プログラムの、個人的なデジタル版に類推によって説明することができる。文脈テンプレートでユーザは、情報作成または発行時間、および情報の「鮮度」を定義する設定可能な時間数に従って並べ替えられた情報見出しに、１つ以上のエージェンシーからアクセスできる。例えば、ＣＮＮの「見出しニュース」は、（２４時間体制で）３０分ごとに見出しを表示する。好ましい実施例では、見出しの文脈テンプレートは、以下のサブクエリが順につながれたサーバのＳＱＬクエリとして実行される：今日発行された提案、今日発行されたお気に入り、今日発行された最も高い可能性、今日と明日発生する来るべきイベント、今日発行される注釈の付いた項目。
全てのサブクエリが発行日／時間によって並べ替えられ、一緒に連結されるのが好ましい。追加フィルタは、ＳＱＭＬの述語リストに基づき、クエリに適用される。前記原則は図１０３に図示されるが、それらはスマート砂時計の画像例、割込みページ、転位効果、背景クロムなどの、見出しの視覚化である。
会話の文脈テンプレート
会話の文脈テンプレートは、意味論的情報をいかに伝達するかという点で、ＣＮＮの「クロスファイア」プログラムの個人的なデジタル版に類推によって説明することができる。情報流布用の文脈として会話や議論を使う「クロスファイア」のように、好ましい実施例では、会話の文脈テンプレートは関連情報用の電子メール掲載、注釈およびスレッドを追跡する。
会話の文脈テンプレートは、次の情報オブジェクトタイプからなる。
1. 最低１つのスレッド深度の電子メール（電子メールメッセージへの電子メール返答）
2. 最低１つのスレッド深度の注釈（オブジェクトの一注釈の注釈）
3. インターネットのニュース掲載（ニュース掲載へのニュース掲載返答）
クエリはスレッド深度ごとに並べ替えられる。追加フィルタは、ＳＱＭＬの述語リストに基づきクエリに適用される。また、文脈スキンはスレッドごとに情報項目を表示する。
図１０４はスマート砂時計用の画像例、割込みページ、転位効果、背景クロムなどの視覚化である（机で仕事をしている二人）。
会話文脈 − オブジェクトおよび文脈バーの視覚化の例
以下は、対応する表示された文脈（括弧内）に意味論的に適切な、視覚化要素を考察、または特徴のリストである。
1. 意味論的画像／動画のアニメーショングラフィック（アイコンと文脈ガイドビュー）
2. 無地の背景上の最大スレッド深度（アイコンおよび文脈ガイドビュー）
3. 意味論的画像／動画上の最大スレッド深度（アイコンおよび文脈ガイドビュー）
4. 順に描かれる会話のタイトル（リストビュー）
5. 順に描かれる会話のタイトルと詳細（タイルビュー）
6. 無地の背景上の会話数（アイコンおよび文脈ガイドビュー）
7. 意味論的画像／動画上の会話数（アイコンおよび文脈ガイドビュー）
新聞ダネの人の文脈テンプレート
新聞ダネの人の文脈テンプレートは、どのように意味論的情報を伝えるかという点において、ＮＢＣの「ミートザプレス」プログラムの個人的なデジタル版と類推によって説明することができる。この場合、ニュースそのものまたは会話ではなく、「ニュースでの人々」が重要視される。ユーザは、情報オブジェクトピボットとして返された人々を使い、ネットワークをナビゲートする。新聞ダネになる人の文脈テンプレートは、見出しの文脈テンプレートとして考えることができ、好ましくは、「人々」または「ユーザ」オブジェクトタイプのフィルタ、および「〜が著作」、「〜が著作した可能性がある」、「〜がホストした」、「〜が注釈を付けた」、「〜の専門家」などの述語で使うのが望ましい（人々を情報に関連付ける述語）。「〜に関連する」のデフォルトの述語は、全ての密接に結びついた特定の述語を包括するのに使うことが好ましい。（新聞ダネの人など）関連情報の並べ替え順は、「新聞を飾るニュース」（見出しなど）の順番によって並べ替えられる。
クエリは、見出しの数によって並べ替えられる。追加フィルタは、ＳＱＭＬの述語リストに基づきクエリに適用される。
図１０５は、スマート砂時計、割込みページ、転位効果、背景クロムなど用の意味論的「新聞ダネの人」の視覚化または画像例を図示する（フットボールの優勝戦）。
新聞ダネの人 − オブジェクトおよび文脈バーの視覚化の例
1. 二人の頭が会話をしているアニメーショングラフィック（アイコンと文脈ガイドビュー）
2. 意味論的画像／動画のアニメーショングラフィック（アイコンと文脈ガイドビュー）
3. 新聞ダネの人の合計数（アイコンと文脈ガイドビュー）
4. 意味論的画像／動画上の新聞ダネの人の合計数（アイコンと文脈ガイドビュー）
5. 順に描かれる新聞ダネの人の名前（リストビュー）
6. 順に描かれる新聞ダネの人の名前と詳細（タイルビュー）
来るべきイベントの文脈テンプレート
来るべきイベントの文脈テンプレート（およびその結果的な特別エージェント）は、来るべきイベントに関する情報を伝える特別プログラムの、個人的なデジタル版に類推によって説明することができる。例には、「ワールドシリーズ」、「ＮＢＡ決勝戦」、「サッカーワールドカップの決勝戦」などの特別イベントが含まれる。知識労働者のシナリオでの同等物は、１つ以上のカテゴリ、文書またはその他の情報オブジェクトピボットに関連する、全ての来るべき業界イベントを監視したいユーザである。来るべきイベントの文脈テンプレートは、来るべきイベントのみがフィルタされ表示される（イベントと時間の重要性を暗示する、意味論的に適切な「文脈スキン」を使うことが好ましい）ことを除いては、見出しの文脈テンプレートと同一であることが好ましい。返されるオブジェクトは、最も間近に迫ったイベントを最初にリストして、タイムクリティカル性を基に並べ替えるのが望ましい。
図１０６は、スマート砂時計、割込みページ、転位効果、背景クロムの画像例など、意味論的「来るべきイベント」の視覚化を図示する（約束バインダー）。
来るべきイベント − オブジェクトおよび文脈バーの視覚化の例
1. 来るべきイベントの合計数の背景上に、次のイベントまでの時間を示す時を刻む時計（アイコンおよび文脈ガイドビュー）
2. 意味論的画像／動画上に、次のイベントまでの時間を刻む時計（アイコンおよび文脈ガイドビュー）
3. 意味論的画像／動画と来るべきイベントの合計数の上に、次のイベントまでの時間を示す時を刻む時計（アイコンおよび文脈ガイドビュー）
4. 無地の背景の上に、次のイベントまでの時間を示す時を刻む時計（アイコンおよび文脈ガイドビュー）
5. 様々な背景上に、全ての来るべきイベント（順に）までの時間を示す、時を刻まない時計（アイコンおよび文脈ガイドビュー）
6. 様々な背景の上に、次の来るべきイベントの予定時間を示すカレンダービュー（アイコンおよび文脈ガイドビュー）
7. 様々な背景の上に、全ての来るべきイベント（順に）の予定時間を示すカレンダービュー（アイコンおよび文脈ガイドビュー）
8. カレンダー動画を示すアニメーショングラフィック（アイコンおよび文脈ガイドビュー）
9. 意味論的画像／動画のアニメーショングラフィック（スケジュールブックなど）（アイコンおよび文脈ガイドビュー）
10. 意味論的画像／動画上の来るべきイベントの合計数（アイコンおよび文脈ガイドビュー）
11. 無地の背景の上の来るべきイベントの合計数（アイコンおよび文脈ガイドビュー）
12. 順に描かれる来るべきイベントのタイトル（リストビュー）
13. 順に描かれる来るべきイベントのタイトルと詳細（タイルビュー）
発見
発見の文脈テンプレートは、「ディスカバリチャンネル」の個人的なデジタル版に類推によって説明することができる。この場合、特定のトピックに関する「ドキュメンタリ」に重要性が置かれる。発見の文脈テンプレートは、任意のカテゴリの一組に関連する情報オブジェクトを無作為に選択することで、情報の知的統合をシミュレートし、そして任意に前もって決められた設定可能な時間期間内に掲載される。時間ではなく意味論的重要性が、情報をどのように順番付けるかまたは提示するかを決定する好ましい考慮材料である。文脈テンプレートは、全ての情報タイプを分類述語用の意味論的リンク強度によってフィルタリングして実行できる。この場合、フィルタは、「最も高い可能性」フィルタより選択度が低くなければならない。文脈テンプレートは、フィルタリングに関しては「最も高い可能性」と「全ての可能性」の中間に位置する。
図１０７は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、「発見」の視覚化である（ペトリ皿）。
発見 − オブジェクトおよび文脈バーの視覚化の例
1. 意味論的画像／動画のアニメーショングラフィック（テレスコープ、ボイジャー宇宙船、海に浮かぶ古い船など）（アイコンおよび文脈ガイドビュー）
2. 順次アニメーションでの最初のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションでの最初のＮ情報項目のタイトルおよび詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンおよび文脈ガイドビュー）
5. 合計項目数（アイコンおよび文脈ガイドビュー）
履歴
履歴の文脈テンプレートは、「ヒストリーチャンネル」の個人的なデジタル版に類推によって説明することができる。この場合、特定のトピックだけでなく、歴史的文脈での情報伝達に重要性が置かれる。このテンプレートに関しては、好ましい軸はカテゴリと時間である。履歴の文脈テンプレートは、発見の文脈テンプレートに類似し、さらに「最小年数制限」と呼応する。パラメータは、「最大年数制限」パラメータを「最小年数制限」パラメータ（またはオプションの「歴史時間期間」パラメータ）で置き換える以外は、発見の文脈プレートと同じであることが好ましい。また、返されるオブジェクトは、システムでの年数または作成からの年数を基に、逆または無作為順に並べ替えるのが望ましい。
図１０８は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的な「ヒストリー」の視覚化を図示する（戦争記念碑）。
履歴 − オブジェクトおよび文脈バーアニメーションの視覚化の例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションでの最古の（または無作為）Ｎ情報項目のタイトル（リストビュー）
3. 順次アニメーションでの最古の（または無作為）Ｎ情報項目のタイトルおよび詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンおよび文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンおよび文脈ガイドビュー）
全項目
全項目の文脈テンプレートは、意味論またはキーワードかテキストベース検索のいずれかを基に関連する、全ての情報を返す文脈を表す。この場合、文脈にほんの少しでも関連する情報の流布に重要性が置かれる。全項目の文脈テンプレート用の主要軸は、関連性の単なる可能性であるあるものが好ましい。好ましい実施例では、全項目の文脈テンプレートは、関連性の可能性がある最も幅広い一組または結果領域を返すために、意味論的およびテキストベースクエリの両方を用いる。
図１０９は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的視覚化を図示する（宇宙）。
全項目 − 視覚化およびオブジェクトと文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）
最も高い可能性
最も高い可能性の文脈テンプレート（およびその結果的な特別エージェント）は、関連性の高い情報のみを返す文脈を表す。好ましい実施例では、関連性が高く、意味論的に重要と見なされる情報伝達に重要性を置く。この文脈テンプレートに関しては、主要軸は関連性である。本質的には、最も高い可能性の文脈テンプレートは、テキストベースのクエリ結果の関連性を保証できないため、テキストベースのクエリは使用せず、意味論的クエリを採用する。最も高い可能性の文脈テンプレートは、カテゴリフィルタまたはキーワードで初期化するのが好ましい。キーワードが指定される場合、サーバは動的に分類を行う。結果は関連性評点、またはオブジェクトからカテゴリフィルタへの「カテゴリに属する」意味論的リンクの強度に基づき並べ替えるのが望ましい。
図１１０は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、「最も高い可能性」の視覚化を図示する（顕微鏡）。
最も高い可能性の視覚化 − オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）
お気に入り
お気に入りの文脈テンプレート（およびその結果としての特別エージェント）は、「お気に入り」または「人気のある」情報を返す文脈を表す。この場合、他者から支持され、好ましく認められた情報流布に重要性が置かれる。好ましい実施例では、お気に入りの文脈テンプレートの軸には、読者層の関心度、オブジェクトが受ける「書評」およびオブジェクトに関する注釈スレッドの深度が含まれる。１つの実施例では、お気に入りの文脈テンプレートは、「お気に入り」意味論的リンクを有する情報のみを返し、同オブジェクトに対する（この意味論的リンクに基づく）「投票」数を数えて並べ替える。
図１１１は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的視覚化を図示する（コーヒーとペストリー）。
お気に入りの視覚化 − オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）
名著
名著の文脈テンプレート（およびその結果としての特別エージェント）は、「名著」情報または、価値を認識された情報を返す文脈を表す。お気に入りの文脈テンプレートと同様に、他者から支持を得て、好ましく認識された情報流布に重要性が置かれる。この文脈テンプレートに関しては、好ましい軸には、歴史的文脈、読者層の関心度、オブジェクトが受けた「書評」およびオブジェクトに関する注釈スレッドの深度が含まれる。名著の文脈テンプレートは、実質的に「古いお気に入り」の文脈プレートとして機能する、追加の最小年数制限フィルタおよび投票評点の付いた、好ましい文脈プレートに基づき実行されるのが好ましい。
図１１２は、スマート砂時計、割込みページ、転位効果、背景クロムなどの「名著」に対する意味論的に適切な画像例を図示する（車）。
名著の視覚化 − オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）
推奨
推奨の文脈テンプレートは、「推奨する」情報、またはエージェンシーがユーザが関心があると推測した情報を返す文脈を表す。「推奨」意味論的リンクを「ＳｅｍａｎｔｉｃＬｉｎｋｓ」テーブルに追加し、ユーザが示すお気に入りの意味論的リンクをマイニングして、推奨は挿入される。推奨は、機械学習および協調フィルタリングのような技法を使って行われるのが望ましい。この文脈テンプレートは、ユーザが関心を持つかもしれないが、ユーザがまだ見ていない可能性のある情報流布に重要性が置かれる。この文脈テンプレートに関しては、主要軸は関心の見込みおよび鮮度を含むのが好ましい。
図１１３は、スマート砂時計、割込みページ、転位効果、背景クロムなどの文脈／アプリケーション要素の画像例で、意味論的に適切な「推奨」の視覚化を図示する（親指を立てて賛同）。
推奨の視覚化 − オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）
今日
今日の文脈テンプレートは、「今日」掲載した情報または（イベントの場合）開催する情報を表示する文脈を表す。この文脈テンプレートは、鮮度を決定するフィルタである「今日」に基づき、最新と見なされる情報流布に重要性が置かれる。
図１１４は、スマート砂時計、割込みページ、転位効果、背景クロムなどの要素の画像例で、意味論的「今日」の視覚化を図示する。
「今日の視覚化」 − オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）
注釈付き項目
注釈付き項目の文脈テンプレートは、注釈の付いた情報を返す文脈を表す。この文脈テンプレートは、一人かそれ以上のユーザが項目に注釈を付けたという事実に基づき、重要である可能性のある情報流布に重要性が置かれる。
図１１５は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的な「注釈付き項目」の視覚化を図示する。
「注釈付き項目」の視覚化 −オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）
注釈
注釈の文脈テンプレートは、注釈の付いた情報を返す文脈を表す。この文脈テンプレートは、注釈である情報流布に重要性が置かれる。
図１６は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的視覚化を図示する（掲示板にピンで留めたメモ）。
「注釈」の視覚化 − オブジェクトと文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）
専門家
図１１７は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的「専門家」の視覚化を図示する（教授）。
「専門家」の視覚化 − オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ専門家のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ専門家のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の専門家の合計数（アイコンと文脈ガイドビュー）
5. 無地の背景上の専門家の合計数（アイコンと文脈ガイドビュー）
場所
図１１８は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的な「場所」の視覚化を図示する（パリ）。
「場所」の視覚化 − オブジェクトと文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ場所の名前（リストビュー）
3. 順次アニメーションで最も最近のＮ場所の名前と詳細（タイルビュー）
4. 意味論的画像／動画上の場所の合計数（アイコンと文脈ガイドビュー）
5. 無地の背景上の場所の合計数（アイコンと文脈ガイドビュー）
ブレンダー
図１１９は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的「ブレンダー」の視覚化を図示する。
「ブレンダー」の視覚化 − アイコンのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 活動中のブレンダーまたはミキサーのアニメーショングラフィック
3. 順次アニメーションでのブレンダー項目のタイトル（リストビュー）
4. 順次アニメーションでのブレンダー項目のタイトルと詳細（タイルビュー）
5. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
6. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）
情報オブジェクトのタイプ
図１２０から１３８までは、以下のそれぞれの情報オブジェクトのタイプの意味論的視覚化を図示する：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、 ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。
プレゼンテーションスキンのタイプ
時系列
図１３９は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的「時系列」の視覚化を図示する。
「時系列」の視覚化 − オブジェクトおよび文脈バーのアニメーション例
1. 様々な背景上の情報項目の効果的時間（発行時間、予定時間など）を示すカレンダービュー（アイコンと文脈ガイドビュー）
2. 様々な背景上の全ての情報項目（順次）の効果的時間を示すカレンダービュー（アイコンと文脈ガイドビュー）
3. カレンダー動画を示すアニメーショングラフィック（アイコンと文脈のガイドビュー）
4. 意味論的画像／動画のアニメーショングラフィック（時間歪曲画像／動画など）（アイコンと文脈ガイドビュー）
5. 意味論的画像／動画上の情報項目の合計数（アイコンと文脈ガイドビュー）
6. 無地の背景上の情報項目の合計数（アイコンと文脈ガイドビュー）
7. 順次描かれる情報項目のタイトル（リストビュー）
8. 順次描かれる情報項目のタイトルと詳細（タイルビュー）
9. 効果的な日付／時間に基づいてポピュレートされた項目でスクロール、直線時系列の制御
10. 効果的な日付／時間で並べ替えられた時系列チッカー制御のアニメーション
意味論的視覚化の威力
視覚化に関して最後に１つ述べるとすれば、好ましい実施例は、意味論的に情報を検索し、その検索した情報を意味論的に組織化して格納するだけでなく、意味論的に提示する。また、その提示は情報の順序、組織化および関係でのみ意味論的なのではなく、前述の視覚化がそうであるように、視覚的な伝達を意図する上である程度意味論的である。その結果、映画の視聴者が、照明、衣装、音楽や全体の舞台セットや背景の周辺状況により、対話の意味を理解する手助けを得るのとおおよそ同じように、ユーザは本システムが提示する情報を理解する上で支援を得る。つまり、好ましい実施例のシステムが提示または管理した、あるいは見つけ出したその他のすべてと同様に、視覚化は意義深い情報の伝達目的を達成する、または同じくらい適切に情報を意義深く伝達する。意味は好ましい実施例の統一主題であり、システムの設計と操作、およびシステムが構成されるそれぞれの構成要素に浸透している。
以上、本発明の好ましい実施例および他の代替実施例を示し説明したが、本発明の精神と範囲から外れることなく数多くの変更することができる。従って、本発明の範囲は好ましい実施例の開示に限定されるものではない。むしろ、本発明はこれに続く請求の範囲を参照することにより全てを判断されるべきである。
知識の取得、管理、伝達、及び提示のシステム及び方法
発明者
ノサ オモイグイ
優先権の主張
本出願は米国仮出願第６０/３００３８５（２００１年６月２２日出願）、及び米国仮出願第６０/３６０６１０号（２００２年２月２８日出願）より優先権を主張する出願である。
著作権表示
本開示は米国著作権法及び国際著作権法により保護されている。著作権 2002 Nosa Omoigui（ノサ オモイグイ）無断複写・複製・転載を禁ず。本特許明細書の開示の一部は、著作権の保護を受ける内容を含む。著作権所有者は、特許商標局の特許ファイル又は記録に見ることができるので、何人の特許明細書又は特許開示内容の複製に異存はないが、その他の点では全ての著作権を所有するものである。
発明の属する技術分野
本発明は情報管理システムに関し、特に知識の取得、管理、伝達、及び提示用に統合されたシームレスな実装の枠組みとその結果生じるメディアに関するものである。
発明の背景
知識は、今では世界中の組織にとって中核資産、及び競争上の優位性のツールとして広く認識されている。現在の接続された状態にある、情報に基づく世界において、知識労働者は生産性の向上、顧客関係の強化、事業の優位性向上のために、より優れて、迅速で、多くの情報に基づいた決定を行うために必要となる知識とツールにアクセスを持つことが必要である。更に、業界観測者は「敏捷さ」と「リアルタイム企業」を、情報経済の重要な事業目標としてもてはやしてきた。
多くの組織は、製品と顧客サービスの向上のために、組織内の知識流布の価値及び十分に訓練を受けた従業員を持つ価値を認識し始めている。企業の電子学習への投資と企業研修もこれを裏付けている。企業は又、コンテンツ管理、検索、共同作業、及びビジネスインテリジェンスのツールにも投資を行っている。更に業務プロセス、特に顧客獲得と顧客保持に関するデジタル化にかなりの資源を費やしている。
しかしながら、多くの知識／学習と顧客関係の資産は、相互の言語を理解しない多様なリポジトリに現在でも格納されており、その結果、個別の情報の孤立集団として管理され相互に作用している。従って、多くの組織が「知識」と呼んでいるものは、データと情報にすぎない。情報経済は主に、増加の一途をたどるこのデータと情報の集団に文脈（コンテキスト）、意味、及び、効率的なアクセスを提供する方法を模索している。言い換えれば、利用可能なデータと情報の集合の、を使用可能な知識への変換方法を模索している。
情報は、様々な普及度で、新聞、書籍、ラジオ／テレビのメディア、及び電子形式等の多種多様な形式でずっとアクセスされてきている。情報の管理とアクセスは、コンピュータとコンピュータネットワークの使用で劇的に変化した。ネットワーク化されたコンピュータシステムは、システム上のいかなる箇所で保持されている情報へのアクセスをシステム全体で提供する。ユーザはアクセスを取得するために、ネットワークへの必要な接続を確立し、適切な許可を与えて、所望の情報を特定するだけでよい。
情報へのアクセスは、インターネットの出現で更に向上した。インターネットは莫大な情報の集団へのアクセスを提供するために、世界中の多数のコンピュータを接続する。インターネット上で情報を提供するもっとも普及した方法は、ワールドワイドウェブ経由である。ウェブは、通常ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ファイル転送プロトコル（ＦＴＰ）、ゴーファ（ＧＯＰＨＥＲ）、又は他のサーバを実行するインターネットに接続されたコンピュータ、又はウェブサーバのサブセットで構成される。ウェブサーバはウェブサイトでウェブページをホストする。ウェブページは、本来のハイパーテキストマークアップ言語（ＨＴＭＬ）、又はもっと最近の拡張可能なマークアップ言語（ＸＭＬ）、あるいは標準一般化マークアップ言語（ＳＧＭＬ）等の１つ以上の言語を使って符号化されている。これらの言語の公開仕様は引用によって本明細書に取り込まれている。これらのフォーマッティング言語によるウェブページは、マイクロソフトのインターネットエクスプローラ、又はネットスケープのナビゲータ等のウェブ閲覧ソフトウェアを経由して、インターネットユーザにアクセスを可能にさせる。
ウェブは、文脈と意味論（セマンティック）よりもむしろ主に、構文と構造に基づいて組織化されてきた。その結果、情報は通常検索エンジンとウェブディレクトリを経由してアクセスされる。現在の検索エンジンは、関連付けられた文脈（コンテキスト）と意味論的な情報を持たず、逐語的、又は簡単な主題の情報と索引に依存するキーワードと対応する検索手法を用いる。残念なことに、このような検索方法は、主として応答がない結果、つまり行動可能な知識ではなく、文書（ドキュメント）を大量に生じさせることになる。高度検索手法は、照会（クエリ）に重点を置き、検索結果の関連性向上のために開発されてきた。このような手法の多くは、ユーザの検索傾向の履歴に依存して所望情報に関して基本的想定を行う。あるいは、他の検索手法は、一番関連性があると予想される分野に、更に検索結果を絞り込むために、ウェブサイトのカテゴリ化に依存する。検索手法に関係なく、検索可能な情報の基底をなす編成は、文脈主導よりもむしろ索引主導である。文書の主題の属性とその属性のユーザの文脈への関連方法ではなく、文書に関連付けられた逐語的な情報の頻度、又はタイプが検索結果を決定してしまう。行動可能な知識を獲得するためのツールとしてのウェブの使用を取り巻く、曖昧さと非効率性の連続という結果に終わる。
現在の世界中の企業において、ウェブは知識労働者のための情報プラットフォームである。問題はその情報プラットフォームにある。現在のウェブは、データと情報のプラットフォームであるのに、ユーザは「知識」の次元で操作している。この分断は非常に本質的なものだといっても過言ではない。「情報を意のままに」の夢は、ウェブが大いにかなえてきた。しかしながら、知識労働者は単なる「情報を意のままに」ではなく、「知識を意のままに」を要求している。残念ながら、現在の知識労働者は、問い合わせに関連ある実際の知識ではなく、むしろ文書、つまりデータと情報の寄せ集めを閲覧／検索するためにウェブを使用している。効果的な知識を得るために、適切な文脈、意味、及びデータと情報への効率的なアクセス、を提供することが求められており、これら全ては従来のウェブには欠けている。
「知識を意のままに」の目標を達成するための努力が行われてきた。その一例が、意味論的ウェブと呼ばれる情報の編成と配信のための新しい概念である。意味論的ウェブは、現在のウェブの拡張機能で情報に十分に定義された意味が与えられ、コンピュータと人間がより優れた協力作業をできるようにする。概念上では、インターネット上での文脈、意味、及び情報のアクセスの向上に対応する方向への大きな前進であるが、意味論的ウェブは約束されている潜在能力の期待に十分に答えるだけの成果のある実装はまだ見つかっていない。
現在のウェブと意味論的ウェブは両方とも、ユーザが行動可能な知識の獲得をできるよう、適切な文脈、意味、及びデータと情報への効率的なアクセスを提供していない。これは特に現在のウェブと考案中の意味論的ウェブの構造化、言い換えれば、技術階層に関する問題である。図１に示すように、例えば現在のウェブはハイパーテキストメディアであるが、「ダム（無能な)」リンク、すなわち文脈依存性、時間への敏感さ等を持たないリンクを含む３つの技術階層を提供する。「意味論的ハイパーメディア」とも呼ばれる意味論的ウェブの現在の概念化は、図２に示すように５つの技術階層を提供する。以下で詳しく述べるが、それぞれの技術階層構造に関連する重大な限界がある。
更に、知識の取得、管理、伝達、及び提示用に統合されたシームレスな実装の枠組みとその結果生じるメディアを提供するために、さまざまな特性が包括的な情報管理システムの中に存在しなければならない。これらの特性には、意味論的／意味、文脈依存性、時間への敏感さ、自動かつ知的な発見の容易性、動的リンク、ユーザ制御のナビゲーション及びブラウジング、非ＨＴＭＬ及びローカルの文書のネットワークへの参加、表示情報の意味論をスマートに伝達する柔軟性のある提示、論理と推測と推論、柔軟性のあるユーザ主導の情報分析、柔軟性のある意味論的な照会、読み取り／書き込みのサポート、注釈付加、「信用の輪」、情報パッケージ（「ブレンダー」）、コンテキストテンプレート、及びユーザ主導の情報集約が含まれるが、全てではない。これらの特性は、それぞれ以下の現在のウェブと意味論的ウェブの両方の応用に関連して説明される。
意味論的／意味
現在のウェブは、プラットフォームとユーザ経験に固有な（イントリンシック）要素としての意味論が欠けている。ウェブページは、そのページに含まれるデータの意味論よりもむしろ、テキスト、及びグラフィックスのデータのみを伝達する。その結果、ユーザは、例えば「５年以内に出版されたラテンジャズに関する100ページ以下の本を全て検索する」といった自然言語で当然期待されるであろう意味論的な照会を送信ことができない。そのような照会の処理を可能にするには、ウェブサイト、又は検索エンジンが、本が含まれることを「識別する」必要があり、その照会要求の意味論に基づいて、コンテンツを知的にフィルタ処理しなけなければならない。そのような照会は、現在のウェブでは不可能である。その代わりにユーザは、テキストベースの検索に依存せざるを得ない。このような検索は通常、情報の過負荷、又は情報の損失という結果になる。なぜならユーザは情報ベースにあるテキストと一致しないかもしれない検索語の選定を余儀なくされるからである。上記の例において、ユーザは「本 ラテン ジャズ」の検索語を選定して、検索エンジンが関連付けをしてくれることを願うかもしれない。ユーザは通常、独力で検索結果にフィルタ処理をしなければならない。更にこのようなテキストベースの検索は、同じ意味を伝達するかもしれない言葉をも包含する。上記の例において、「南アメリカ、又は中央アメリカのジャズに関する本」、又は「ラテンアメリカのジャズに関する出版物」等の検索語からの結果は、検索照会の処理時に無視される可能性がある。
意味論が欠けていることは又、現在のウェブは、人間が考えるようなやり方でユーザがナビゲートすることができないことを暗示している。例えば、ある人は組織構造を用いて社内イントラネットをナビゲートすることを希望するかもしれない。例えば、人から、人が作成する文書へ、その文書に関するエキスパートへ、そのエキスパートの直属部下へ、その直属部下が会員である配信リストへ、その配信リストの会員へ、これらの会員が作成した文書へ等である。この「ウェブ（クモの巣状のもの）」は意味論であり、実際の情報分類（「事項」）に基づいており、現在のウェブのようなただの「ページ」ではない。
意味論の欠如は他の意味合いを持っている。まず、ウェブがプログラム可能でないことを意味する。意味論を用いると、ページとリンクの意味を理解し、推測、推薦等を行うことができるスマートエージェントによってウェブを利用できる。現在のウェブでは、推測を行うことができる「エージェント」は人間の頭脳のみである。従ってウェブは、コンピュータが持つ巨大な処理能力を行使していない。なぜならウェブはコンピュータが理解できるような様式で表現されていないからである。
意味論の欠如は情報が行動可能でないことも示す。検索エンジンはウェブが吐き出す結果を「理解」していない。従って、いったんユーザが検索結果を受信すると、あとは「本人まかせ」である。又、ウェブブラウザは表示する情報を「理解」しておらず、従って情報を用いてスマートな（賢い）事項を行うことができない。適所に配置された意味論があれば、スマートビューは、例えばイベントはイベントであることを「識別」し、そのイベントがユーザのカレンダーにすでに入っているかを調べて、予定あり／なしの情報を表示したり、自動的にそのイベントをカレンダーに挿入することにより、ユーザがその情報を行動可能にするといった面白い事を行うかもしれない。意味論なしで提示された情報は行動可能でない、又は意味論の推測が必要となる可能性があり、よって不愉快なユーザ経験となる可能性がある。
意味論的ウェブは、十分に定義された意味論で情報を符号化することによって、現在のウェブが持つ意味論的／意味の限界に対処することを目指す。意味論的ウェブ上のウェブページには、メタデータ及び他のメタデータへの意味論的なリンクが含まれ、それによって検索エンジンは、より知的で正確な検索を行うことができる。更に、意味論的ウェブは、知識表現に用いられるオントロジを含むので、意味論的検索エンジンに言葉を単なる文字ではなく、意味に基づいた解釈をさせることができる。例えば、上記の例において、ラテンジャズのオントロジを意味論的ウェブサイトで活用して、サイトの検索エンジンに「南アメリカ、又は中央アメリカのジャズの本」、又は「ラテンアメリカのジャズに関する出版物」という言葉に、「ラテンジャズに関する本」の言葉と同じ意味があることを「識別」させることができるかもしれない。概念上では現在のウェブが持つ多くの欠陥を打開する一方で、文脈依存性と時間への敏感さ、等の付加的な特徴を提供するために、特に必須の意味論的なリンク、オントロジ、等を含む、文脈と意味を提供する十分に定義されたデータモデルの成果のある実装は、現時点ではまだ存在しない。
文脈依存性
現在のウェブは文脈依存性に欠けている。文脈が欠けていることは、現在のウェブは個人的でないということである。例えば、アクセス可能な記憶領域に存在する文書は、個別に静的であり従って無能である。文書の主題に関連する情報は、すでに公開済みである、新しく公開中である、又は間もなく公開される予定である、のどれかである。しかし、記憶領域内の文書は静的なので、リアルタイムに主題とこれに関連ある情報とを動的に関連付ける手立てがない。言い換えれば、ユーザは個人的な文脈をリアルタイムに外部の情報と動的に接続する手立てを持たない。文脈を形成する情報源（文書等）は、各自孤立集団に存在しており、他の関連ある情報源からまったく孤立している。これは、情報と生産性の損失という結果を生じる。
これの主な理由は、現在のウェブが（遠隔コンピュータ等の）ダムクライアントに情報を表示する提示用に設計された、提示指向のメディアであるからである。クライアントは単にサーバが示すよう命令したことを表示する以外は、実質上ユーザ経験への役割をまったく持っていない。（ＪａｖａアプレットやＡｃｔｉｖｅＸコントロール等の）クライアント側にコードがある場合でも、コントロールは通常1つの特定な事項を行い、クライアント側のコードとサーバ側のコードが連携するように、遠隔サーバとの調整されたアクションを持たない。
生産性の観点から見ると、これは知識労働者と情報消費者は完全に情報作成者の言いなりになっていることを意味する。現在、知識労働者は企業情報、外部データ、等のカスタムビューを提供するために管理・更新されたポータルを持っている。しかしながら、これはまだ非常に限定されている。なぜなら、知識労働者の作業の前後関係で関連ある情報と、ユーザがアクセスを持つ情報を動的で知的に結び付けるものがまったくないのであれば、知識労働者はどうすることもできないからである。
知識労働者が、自分のポータル上にある情報の関連部分へのリンクが表示されていない、又は友達や同僚がそのリンクを電子メールで知らせないのであれば、情報は脱落してしまう。つまり情報は、ユーザの文脈、又は表示されている文脈に結びついたり適合しないのである。同様に、単にポータル全体の新しいデータが入手可能であることをユーザに通知して、ローカルのハードドライブに押し込んでしまうだけでは不十分である。それでは、 文脈依存の警告通知を持つカスタマイズ可能な提示に欠けている。
文脈依存性に関しては、意味論的ウェブは、現在のウェブと同様の限界の問題を抱えている。意味論的ウェブにおいて、ユーザは同様に情報作成者のなすがままになっている。意味論的ウェブ自体は作成されるが、オーサリングに意味論が含まれることになる。その結果、ユーザは未だに独力で、利用可能な情報の関連性を見つけ出し、評価しなければならない。意味論的ウェブは、単独型の実体としては、他の情報源と動的な結び付きをすることはできない。
時間への敏感さ
現在のウェブは時間への敏感さに欠けている。（例えばブラウザのような）ウェブプラットフォームは、情報への敏感さにまったく関係なく、単に情報を表示する単機能のソフトウェアである。ユーザは、時間への敏感さを推測推測する、又はなしで済ますかしなければならない。これは、ウェブプラットフォームがリアルタイムに、時間に敏感な結び付きができないので生産性の大幅な損失である。ウェブサイトの中には、例えば、所定の日付が過ぎた情報に索引付けをする等、時間に敏感な情報表示に重点を置くものもあるが、ウェブブラウザ自体は時間への敏感さの概念がない。代わりに、独自の孤立集団内で表示する情報に時間への敏感さを含むかどうかは各ウェブサイト次第である。言い換えれば、ウェブリンク上には時間の軸がない。
意味論的ウェブも又、現在のウェブのように、時間への敏感さに対応していない。意味論的ウェブは、時間を内在化しない意味論的リンクを持つことができる。これは主として、意味論的ウェブが、潜在的に文脈依存性と時間への敏感さを扱うウェブサービスのソフトウェアの概念を持っていないからである。
自動かつ知的な発見の容易性
現在のウェブは、新しく作成された情報についての自動かつ知的な発見の容易性に欠けている。現在どのウェブサイトが、今日、又は昨日新しく開設されたものか知るすべがない。通知を受けるか、検索を行う際に運良く新しいサイトを発見する以外には、ユーザは新しいウェブサイトやページがあるかどうか知るすべがない。同じ問題はエンタープライズ（企業）にも存在する。イントラネット上で新しいウェブサイトができても、知識労働者はなんらかの外部手段により通知を受けない限り、それを知るすべがない。ウェブプラットフォーム自体には、告知又は発見の概念がない。更に、ユーザの作業、又は現在の情報空間の文脈内に新しいサイト、又はページを判断する文脈依存の発見が存在しない。
意味論的ウェブは現在のウェブと同様に、自動的な発見の容易性に欠けていることに対処していない。意味論的ウェブは、ユーザが外部の情報源、又は検索時の個人的な発見を通して、新しい情報源の存在を発見せざるを得ないという同じ問題を抱えている。
動的リンク
現在のウェブは情報モデルに、単なるネットワーク、又はグラフの「データ構造」を採用している。各ウェブページは、ネットワークの１つのノードを表し、各ページはネットワーク内の他のノードとのリンクを含むことができる。各リンクはページごとに手作業で作成される。これにはいくつかの問題がある。まず、ネットワークは、持続的に価値があるようにメンテナンスが必要になることを意味する。ウェブページが更新されていなかったり、ウェブページ、又はサイトの作成者が関連性に基づいたページのリンクを追加する規律を守っていない場合は、ネットワークは価値を失う。現在のウェブは、本質的に存在しないリンク、廃れたリンク、等が張られている傾向がある。単なるネットワーク、又はグラフの情報モデルのもう１つの問題は、情報消費者が、ウェブページ、又はサイトの提示を制御する立場にあるのではなくむしろ、その提示のなすがままになっていることである。言い換えれば、ウェブページ、又はサイトにリンクが存在していない場合は、ユーザは関連ある情報を探し出す手だてがない。検索エンジンは、単にページ、又はノードをネットワークに戻すだけなのでほとんど頼りにならない。ネットワーク自体は、個別な、又は動的リンク能力を持っていない。従って、検索エンジンは、ウェブページ自体がリンクを持たない、又はリンク先が存在しなかったり、古かったり、不適切なリンクを持つページに簡単にリンクを返すことができる。ユーザは、いったん検索結果を得ると独力となり、返されたページの作成者が関連性のある時間に敏感なリンクをページに挿入しているか否かに完全に左右されてしまう。
意味論的ウェブは、単に現在のウェブに意味論を付け加えたものであるから、現在のウェブと同じ問題を抱えている。（現在のウェブではできない事であるが）ユーザはネットワークを意味論的にナビゲートすることは可能になるが、やはり情報の作成方法に左右される。言い換えれば、意味論的ウェブも又作成者がどれだけ規律を守っているかに依存しており、従って上記で述べた現在のウェブが持つ同じ問題を抱えている。意味論的ウェブが、オントロジとメタデータを持つページを含んでいても、うまく管理されていなかったり、関連する他の情報源へのリンクが含まれていないと、ユーザはやはり現在のリンクと他の情報を得ることができない。現在考案中の意味論的ウェブは、スマートで、動的で自動オーサリングし、自己修復するネットワークではない。
ユーザ制御のナビゲーション及びブラウジング
現在のウェブでは、ユーザはナビゲーション及びブラウジングの経験を制御できなく、むしろウェブページとそのページのリンク（もしもリンクが存在するのであれば）の作成方法に完全に任されてしまう。図３の先行技術を参照にして示すように、現在のウェブは「ダムリンク」、又はナビゲートできるには継続的なメンテナンスに完全に頼り切っている静的に作成された汎用リンク、から構成される。
意味論的ウェブは、ユーザ制御のブラウジングがない点で現在のウェブと類似の問題を抱えている。代わりに、図４の先行技術を参照にして示すように、意味論的ウェブは更に意味論的な情報とメタデータが含まれた「ダムリンク」で構成される。しかしながら、同様に意味論的ウェブはナビゲートできるには、継続的なメンテナンスに頼っている。
非ＨＴＭＬ及びローカルの文書のネットワークへの参加
現在のウェブが抱えるもう１つの問題は、ＨＴＭＬとして作成された文書のみがウェブに参加できるという事実に加えて、これらの文書にリンクが含まれなければならないという要求仕様である。（例えば、ＰＤＦ、マイクロソフトワード、パワーポイント、エクセルの文書等の）非ＨＴＭＬ文書等の他の情報オブジェクト、特にユーザのハードドライブに存在するものは、ネットワークの他のオブジェクトとリンクする利点から除外されていることを示唆する。これは特に、非ＨＴＭＬの情報オブジェクト及びリンクを含まない情報オブジェクトとの間に、意味論的な関連性がある可能性があるので、非常に制約される。
更には、ウェブ上で利用可能な莫大な量のコンテンツは、標準のウェブクローラーではアクセス不可能なので、検索エンジンは領域全体の情報の結果を返さない。例えば、これにはデータベースに格納されたコンテンツ、索引のないファイルレポジトリ、登録サイト、ローカルのマシン及びデバイス、（マイクロソフトオフィスドキュメント及び電子メール等の）所有権のあるファイル形式、テキスト以外のマルチメディアファイルが含まれる。これらは、インターネット上のアクセス不可能な物体の巨大な一群を形成し、企業内では「見えないイントラネット」を呼ばれている。現在のウェブサーバは、この問題に対処するウェブクローラーのツールを提供していない。
意味論的ウェブもこの制約の問題を抱えている。すでに存在する無数の非ＨＴＭＬ文書、特にユーザのハードドライブ上に存在するものに対処していない。これは、ＲＤＦメタデータの同等物、又はその代用物を持っていない文書は、動的にネットワークとリンクできないことを意味する。
表示情報の意味論をスマートに伝達する柔軟性のある提示
現在のウェブでは、ユーザがウェブサイト、又はページをカスタマイズ、又は「スキン」することができない。これは、現在のウェブサーバがブラウザによって提示用にすでに書式設定された情報を返すからである。エンドユーザには、（情報のタイプ、利用可能な表示領域等の）異なる条件に基づいて情報を表示する最善方法を選択する柔軟性がない。
意味論的ウェブは、柔軟性のある提示の課題に対処していない。意味論的なウェブのサイトは、ＲＤＦとオントロジを概念的には採用しているものの、ＨＴＭＬをブラウザに送信する。本質的に意味論的ウェブは、提示用の特定な能力をユーザに与えていない。従って、現在のウェブのプラットフォームで表示された意味論的ウェブサイトは、柔軟性のある提示能力をユーザに与えていない。更には業界のＸＭＬへの動きにもかかわらず、新しいプラットフォームのみが、データを提示から切り離すよう規定し、データをプログラム可能にするための指針の定義が可能である。意味論的ウェブ用のコンテンツを構築する作成者は、ＸＭＬを返して提示の問題を完全に避けるか、又はレンダリング用の単一の表示形式（垂直型企業の場合）に取り組みに集中させている。どちらの取り組み方でも、意味論的ウェブが最適な度合いの知識普及を達成させることはできない。
論理と推測と推論
現在のウェブは、意味論、メタデータ、又は知識表現を持っていないので、コンピュータが新しいリンクを推測したり、通知推測を発行するために論理と推測を使ってウェブページを処理することができない。現在のウェブは、コンピュータの利用向けではなく、人間が利用できるように設計されて構築されている。従って、現在のウェブは、メタデータの抽出、及び論理と推測の適用のためのスクリーンスクレイピング等の、もろくあてにならない技術に頼る以外には情報構造にメスを入れることができない。
意味論的ウェブは、概念的にはコンピュータが処理できる符号化された情報を、ウェブのページ、及びサイトに提供するために、メタデータと意味を使用する一方で、このコンピュータ処理をうまく実現させて、情報の消費者、又は生産者に恩恵を与える新しい、又は改善されたシナリオを示す実装は現時点では存在しない。
柔軟性のあるユーザ主導の情報分析
現在のウェブは、ユーザ主導の情報分析に欠けている。現在のウェブでは、ユーザは異なるフィルタと条件を使って、複数リンクの異なる「ビュー」を表示させることができない。例えば、ウェブの検索エンジンでは、ユーザは異なるシナリオの下で検索結果を試すことができない。ユーザは情報のタイプ（文書、電子メール等）、文脈（「見出し」、「最も確実な予想」等）、カテゴリ（「ワイヤレス」、「技術」等）の異なるピボットを使って結果を表示することができない。
意味論的ウェブは、より柔軟性のある情報分析を提供する一方で、プレゼンテーション層が柔軟性のある分析を提供するために、対話方式でウェブ自体と連係する方法を記述していない。
柔軟性のある意味論的な照会
現在のウェブでは、テキストベースの照会、つまり1つの特定のウェブサイトのスキーマに関連付けた照会のみを行うことができる。このような照会は柔軟性に欠けている。現在のウェブでは、ユーザは自然言語に近い照会、又は意味論と局所的文脈を取り入れた照会を送信できない。例えば、「自分のハードディスク上のこの仕様書に関連する、自分の上司、又は研究部内の誰かにが作成した電子メールのメッセージを全て検索する」といった照会である。
メタデータとオントロジを採用することで、概念上の意味論的ウェブでは、ユーザは現在のウェブよりもより柔軟性のある照会を送信できる。例えば、ユーザは「自分の上司、又は研究部内の誰かが作成した電子メールのメッセージを全て検索する」のような照会を送信できる。しかしながら、ユーザは局所的文脈を取り入れることができない。更に意味論的ウェブは、ユーザが自然言語を用いないでウェブに照会を行う簡単な方法を定義していない。自然言語の技術は１つの選択肢ではあるが、信頼性のある技術にはほど遠い。従って、自然言語に近く、しかも自然言語に依存しないような照会のユーザインターフェースが必要とされる。意味論的ウェブはこれに対処していない。
読み取り／書き込みのサポート
現在のウェブは、読み取り専用ウェブである。例えば、リンク先が存在しないリンク（例：「４０４」エラー）にユーザが出くわした場合、ユーザが知っているかもしれない更新された宛先へとそのリンクを指し示すことで「修正する」ことはできない。ユーザが他の者と共有する重要な知識を持っているかもしれない場合、及びネットワークの表現及び展開の方法に関してユーザーが意見がある場合は特に限定される。
意味論的ウェブは概念上、単独参加のアプリケーションによって提供されるものとして、読み取り／書き込みのシナリオを可能にするが、現在この能力を提供する実装は存在しない。
注釈付加
現在のウェブは、注釈付加の潜在的サポートがない。注釈付加をサポートするウェブサイトがいくらかあるが、それは非常に制限され独立型の方法で行っている。現在のウェブのメディア自体は、注釈付加に対処していない。言い換えれば、ユーザはどんなリンクも自分の意見、又はアクセスのある追加的な情報で注釈付けすることができない。これは潜在的な情報の損失につながる。
意味論的ウェブは概念上、セキュリティ制約を条件として注釈付加のシステムへの組み込みを可能にするが、現在この能力を提供する実装は存在しない。
「信用の輪」
現在のウェブは、認証、アクセス制御、及びウェブへの許可のシームレスな統合、つまり「信用の輪」と呼ばれているものに欠けている。信用の輪があれば、例えば、ユーザはアサーションを作成し、ウェブリンクを修正、及び更新して、そのような操作にアクセス制御の制約事項を組み込むことができる。現在のウェブでこの信用が欠けていることは又、ウェブサービスが所有権のあるユーザ登録許可、アクセス制御、又は決済システムを実施しなければならない孤立集団のままであることを意味する。この情報をサードパーティのサーバに集中化する大がかりな方法は、個人情報保護の懸念から消費者及びベンダーからの不信を買っている。資産を使用するユーザは、豊富なコンテンツにアクセスするために、各自ログインして、各サイトでＩＤ情報を提供しなければならない。
意味論的ウェブは概念上、信用の輪を可能にするが、現在この能力を提供する実装は存在しない。
情報パッケージ（ブレンダー）
現在のウェブと意味論的ウェブのどちらにおいても、ユーザは、（例えば、カスタマイズされた個人用新聞やテレビチャンネルを作成するような）重複する結果を作成するために、潜在的に相違する意味論的な情報の特徴を合成して、１つの全体のユニットとして関連した意味論的な情報を取り扱うことができない。
コンテキストテンプレート
現在のウェブも意味論的ウェブもどちらもにおいても、ユーザは情報のアクセスと取得用に、特定で、及びよく知っている意味論的モデルを個別に作成しマッピングをすることができない。
ユーザ主導の情報集約
現在のウェブは、ユーザ主導の情報集約のサポートに欠けている。ユーザは、１回の閲覧セッションの状況で、一度に1つのウェブサイト、又は1つの検索エンジンしかアクセスができない。従って、ユーザが現在表示している情報に関連する他の情報源に文脈に依存する、又は時間に敏感な情報があったとしても、これらの情報源はユーザの作業の現在の状況では総体的なやり方で提示することはできない。
意味論的ウェブは又ユーザ主導の情報集約に欠けている。メディア自体が現在のウェブの拡張機能である。従って、ユーザは一度に1つのサイト、又は1つの検索エンジンにアクセスするので、文脈に依存する方法、又は時間に敏感な方法で情報レポジトリ全体の情報の集約をすることができない。
「知識を意のままに」の要求の高まりを考慮して、又、上記で多くを説明した現在のウェブと概念上の意味論的ウェブの欠陥を考慮すると、知識の取得、管理、及び伝達の新しく包括的なシステムと方法の必要性がある。

発明の要約
本発明は、知識の取得、管理、伝達、及び提示用に統合されたシームレスな実装の枠組みとその結果生じるメディアに部分的に関するものである。システムは、通信メディアを経由して提示のプラットフォームを運用するクライアントに、文脈に依存し時間に敏感な意味論的な情報の取得サービスを提供するために連携するいくつかの構成要素で構成されるサーバを含む。サーバは、ドメイン固有の意味論的な情報、つまりインテリジェンスの追加、及び管理の役目を持つ第一サーバ構成要素を含む。第一サーバ構成要素は、意味ネットワーク、セマンティックデータ ギャザラー、セマンティックネットワーク コンシステンシーチェッカー、インファレンスエンジン、セマンティッククエリ プロセッサ、自然言語パーサ、イーメールナレッジ エージェント、ナレッジドメイン マネージャを提供するための構造、又は方法論が含まれることが好ましい。サーバは、意味論的な情報を分類しカテゴリ化するのに使われるドメイン固有の情報をホストする第二サーバ構成要素を含む。第一、及び第二サーバの構成要素は連携し、物理的に統合されている場合もあれば、又は分離されている場合もある。
システム内で、指定の階層内にある全てのオブジェクト、又はイベントは、意味論的に互いに関連し、（基本のアクションコードから成る）照会を表現するアクティブなエージェントで、所定のカスタマイズ可能なテーマ、又は「スキン」に従って、クライアントに提示するためのデータオブジェクトを返す。本システムは、クライアントにエージェント及び基本となる関連した照会ををカスタマイズ、及び「混合する」ための多種の手段を提供し、結果として生じる情報の提示を最適化する。
本発明のエンドツーエンドシステムのアーキテクチャは、カスタムクライアントでプログラマチックな統合を実現する付加的なソフトウェア開発キット（ＳＤＫ）層を提供する本発明によって修正されたように、独立した意味論的ウェブのプラットフォーム、又は従来のウェブポータル（現在のウェブアクセス ブラウザ等）を経由して多種多様の知識情報源間での複数クライアントアクセスの通信手段を提供する。
本発明の方法論は、知識の取得、管理、伝達、及び提示を含むシステム全体の運用側面に部分的に関するものである。これには、情報源からの情報確保、情報源から情報を意味論的にリンクする、意味論的にリンクされたられた情報の集団の意味論的属性の管理、ユーザの照会に基づいて要求された意味論的な情報の配信、及びカスタマイズ可能なユーザプレファレンスに従った意味論的な情報の表示が含まれることが好ましい。本発明の方法論における別の実施例は、意味論的に関連ある情報を生み出す、効率的で推測に基づいた照会を可能にするためにサーバ側、及びクライアント側のアプリケーションで使用される照会を表現するエージェントの運用に関する。

図面の簡単な説明
本発明の好ましい実施の形態と他の実施の形態について以下の図面を参照して詳しく説明する。
図１ 現在のウェブの技術階層を示す表である。
図２ 概念上の意味論的ウェブの技術階層を示す表である。
図３ 現在のウェブにおけるリンクへのユーザのナビゲーションを示す図である。
図４ 概念上の意味論的ウェブにおけるリンクへのユーザのナビゲーションを示す図である。
図５ 本発明によるインフォメーションエージェントのリゾルトペインの一例を示す画面例である。
図６ 現在のウェブと本発明のインフォメーションナーバス システムの技術プラットフォームのスタックを示す。
図７ 本発明のシステムの概要を示す画面である。
図８ 本発明のインフォメーションナーバス システムのエンドツーエンドシステムのアーキテクチャを示す図である。
図９ 本発明のインフォメーションナーバス システムのナレッジインテグレーション サーバ（ＫＩＳ）のシステムのアーキテクチャを示す図である。
図１０ 現在のウェブの上位記述プラットフォーム層と、本発明のインフォメーションナーバス システムでの同等物（該当する場合）との間の比較である。
図１１ インフォメーションナーバス システムの好ましい実施の形態と、本発明用の異種混合ネットワークでクロスプラットフォームの文脈を示す。
図１２ 本発明の好ましい実施の形態によるブレンダーウィザードのユーザインターフェースの画面例である。
図１３ 本発明の好ましい実施の形態によるブレンダーウィザードのユーザインターフェースの画面例である。
図１４ 本発明の好ましい実施の形態によるブレンダーウィザードのユーザインターフェースの画面例である。
図１５ ブレイキングニュース エージェントのユーザインターフェースの一例ペインである。
図１６ 本発明の「エージェントを開く」ダイアログの好ましい実施の形態を示す。
図１７ 「エージェントを開く」ダイアログに関連するセマンティックエンバイロメントの一例のツリービューを示す。
図１８ 「エージェントを開く」ダイアログに関連するセマンティックエンバイロメントの一例のツリービューを示す。
図１９ 「エージェントを開く」ダイアログに関連するセマンティックエンバイロメントの一例のツリービューを示す。
図２０ 本発明の好ましい実施の形態のエージェントスキーマを示す。
図２１ 本発明の好ましい実施の形態の AgentTypeID を示す。
図２２ 本発明の好ましい実施の形態の AgentQueryTypeID を示す。
図２３ 本発明のＫＩＳ上でサーバ側のエージェントの好ましい設定方法を示すエージェント名に対応する意味論的照会の例を示す。
図２４ 本発明のＫＩＳの概要を示す図である。
図２５ 本発明によるエンタープライズ環境向けの意味ネットワークを例示する図である。
図２６ 本発明による Object タイプの好ましいスキーマを示す表である。
図２７ 本発明の SemanticLinks の表を示す。
図２８ 本発明の好ましい実施の形態の述語タイプＩＤを示す表である。
図２９ 本発明に従って作成された好ましいユーザオブジェクトのスキーマを示す表である。
図３０ ユーザ（人）オブジェクトのスキーマに関連付けられた好ましい MailingAddressTypeID を示す表である。
図３１ 本発明に従って作成された好ましいカテゴリオブジェクトのスキーマの表である。
図３２ 本発明に従って作成された好ましい文書オブジェクトのスキーマの表である。
図３３ 好ましい実施の形態の活字メディアタイプ ID を示す。
図３４ 好ましい FORMATTYPEID を示す。
図３５ 本発明に従って作成された好ましい電子メールメッセージリストオブジェクトのスキーマを示す。
図３６本発明の好ましい実施の形態の電子メール配信リストと電子メール共有フォルダ、それぞれのオブジェクトのスキーマの表の例を示す。
図３７ 本発明の好ましい実施の形態の電子メール配信リストと電子メール共有フォルダ、それぞれのオブジェクトのスキーマの表の例を示す。
図３８ 本発明の好ましい PublicFolderTypeID を示す。
図３９ 本発明に従って作成された好ましいイベントオブジェクトのスキーマのメッセージリストのオブジェクトのスキーマを示す。
図４０ 本発明の好ましい実施の形態のイベントタイプを示す。
図４１ 本発明に従って作成された好ましいメディアオブジェクトのスキーマのメッセージリストのオブジェクトのスキーマを示す。
図４２ 本発明の好ましい実施の形態のメディアタイプを示す。
図４３ 本発明の好ましい実施の形態におけるオブジェクトのカテゴリ化と活用の方法を示す追加例である。
図４４ 本発明の好ましい実施の形態におけるオブジェクトのカテゴリ化と活用の方法を示す追加例である。
図４５ 本発明の好ましい実施の形態におけるオブジェクトのカテゴリ化と活用の方法を示す追加例である。
図４６ 本発明による生の電子メールのＸＭＬ形式メタデータの意味ネットワークへのマッピングを示すオブジェクトグラフである。
図４７ ＫＩＳによるエージェント管理の画面例である。
図４８ ＫＩＳによるエージェント管理の画面例である。
図４９ ＫＩＳによるエージェント管理の画面例である。
図５０ ＫＩＳによるエージェント管理の画面例である。
図５１ ＫＩＳによるエージェント管理の画面例である。
図５２ ＫＩＳによるエージェント管理の画面例である。
図５３ ＫＩＳによるエージェント管理の画面例である。
図５４ インフォメーションエージェントのリゾルトペインに表示された情報オブジェクトを示すユーザインターフェースの一例を示す。
図５５ 本発明による電子メールの一例を示すイントリンシックセマンティック リンクに関連付けられた吹き出しポップアップの一例を示す。
図５６ 本発明による動詞ユーザインターフェースに関連した吹き出しポップアップの一例を示す。
図５７ 本発明によるディープインフォメーション モードのユーザインターフェースに関連した吹き出しポップアップの一例を示す。
図５８ 本発明によるセマンティックエンバイロメントの図解を示す。
図５９ 本発明によるセマンティックエンバイロメントの図解を示す。
図６０ 本発明の好ましい実施の形態によるインフォメーションエージェントの画面例である。
図６１ 本発明の好ましい実施の形態によるインフォメーションエージェントの画面例である。
図６２ 本発明の好ましい実施の形態によるインフォメーションエージェントの画面例である。
図６３ 本発明の好ましい実施の形態によるインフォメーションエージェントの画面例である。
図６４ 本発明の好ましい実施の形態によるインフォメーションエージェントの画面例である。
図６５ 本発明の好ましい実施の形態によるインフォメーションエージェントの画面例である。
図６６ 本発明の好ましい実施の形態によるインフォメーションエージェントの画面例である。
図６７ 本発明の好ましい実施の形態によるインフォメーションエージェントの画面例である。
図６８ 本発明の好ましい実施の形態によるインフォメーションエージェントの画面例である。
図６９ 本発明によるインフォメーションエージェントのスマートレンズ機能に関連した吹き出しポップアップメニューの例を示す。
図７０ 本発明によるインフォメーションエージェントのスマートレンズ機能に関連した吹き出しポップアップメニューの例を示す。
図７１ 本発明によるインフォメーションエージェントのスマートレンズ機能に関連した吹き出しポップアップメニューの例を示す。
図７２ ２つのオブジェクトの関連性尺度を示す図７１の吹き出しポップアップメニューの異なる例を示す。
図７３ スマートレンズを用いた場合のオブジェクトのタイプと述語を含む動作と関係を例示する表である。
図７４ スマートレンズを用いた場合のオブジェクトのタイプと述語を含む動作と関係を例示する表である。
図７５ スマートレンズを用いた場合のオブジェクトのタイプと述語を含む動作と関係を例示する表である。
図７６ 本発明によるプレーヤー／プレビューコントロールの意味論的結果を示すユーザインターフェースの一例である。
図７７ ブレンダーの意味論的結果を示すユーザインターフェースの一例である。
図７８ 本発明の機能性のマッピングの例を示す。
図７９ 本発明の機能性のマッピングの例を示す。
図８０ 本発明によるエージェントの結果と対応する文脈パレットを示すユーザインターフェースを図解したものである。
図８１ 本発明によるスマート推薦のポップアップの文脈リゾルトペインを例示する図である。
図８２ 本発明のインフォメーションナーバス システムの技術階層を示す表である。
図８３ 本発明の好ましい実施の形態による動的リンクとユーザ制御のナビゲーション及びブラウジングを示す。

引用によって本明細書に組み込まれている文書
ここに添付し参照する付属書類は引用によって本明細書に組み込まれている。本付属書類は本発明の好ましい実施の形態を示すコード例を含む。

発明の詳細な説明の内容
A. 定義
B. 概要
1. 発明の前後関係
2. 価値命題
3. 現在の「情報」ウェブと本発明のインフォメーションナーバス システムの比較
C. システムのアーキテクチャと技術の考慮事項
1. システムの概要
2. システムのアーキテクチャ
3. テクノロジスタック
4. システムの異種混合性
5. セキュリティ
6. 効率性の考慮事項
D. システムの構成要素と操作
1. エージェンシーとエージェント
a. エージェンシー
b. エージェント
2. ナレッジインテグレーション サーバ
a. 意味ネットワーク
b. セマンティックデータ ギャザラー
c. セマンティックネットワーク コンシステンシーチェッカー
d. インファレンスエンジン
e. セマンティッククエリ プロセッサ
f. 自然言語パーサ
g. イーメールナレッジ エージェント
h. ナレッジドメイン マネージャ
i. その他の構成要素
3. ナレッジベース サーバ
4. インフォメーションエージェント（意味論的ブラウザプラットフォーム）
a. 概要
b. クライアントの設定
c. クライアントの枠組みの仕様
d. クライアントの枠組み
e. 意味論的な照会文書
f. セマンティックエンバイロメント
g. セマンティックエンバイロメント マネージャ
h.環境ブラウザ（意味論的ブラウザ、又はインフォメーションエージェント（Ｉｎｆｏｒｍａｔｉｏｎ Ａｇｅｎｔ(登録商標)））
i. その他のアプリケーションの機能
5. 本発明における文脈の提供
a. コンテキストテンプレート
b. 文脈スキン
c. スキンテンプレート
d. デフォルトの述語
e. 文脈述語
f. 文脈属性
g. 文脈パレット
h. 組み込み警告
i. スマート推薦
6. 本発明の持つ特性の利点
E. シナリオ
1. 本発明を利用した意味論的照会の例
2. 実務上の問題
3. 状況
発明の詳細な説明
A. 定義
アクションスクリプト（ＡｃｔｉｏｎＳｃｒｉｐｔ） マクロメディアフラッシュ（Ｍａｃｒｏｍｅｄｉａ Ｆｌａｓｈ）のスクリプト言語。双方向映画を作成するユーザの双方向通信を支援。http://www.macromedia.com/support/flash/action_scripts/actionscript_tutorial/を参照のこと。
エージェンシー（Ａｇｅｎｃｙ） ナレッジインテグレーション サーバ（ＫＩＳ）の名前付き実現値で、意味論的にウェブサイトに相当する。
エージェンシーディレクトリ（Ａｇｅｎｃｙ Ｄｉｒｅｃｔｏｒｙ） エージェンシー用のメタデータ情報を格納し、この中に格納されたエージェンシーをクライアントが追加、削除、検索、参照できるディレクトリ。エージェンシーは、ＬＤＡＰ、又はマイクロソフトのアクティブディレクトリのようなディレクトリ上に公開することができる。エージェンシーは又、エージェント専用に構築された専有のディレクトリ上に公開することもできる。
エージェント（Ａｇｅｎｔ） 特定の意味論的なオブジェクトのタイプ（文書、電子メール、人等）、文脈（見出し、会話等）、又はブレンダー用にＸＭＬによる情報を返す意味論的フィルタの照会。
・ ブレンダー（Ｂｌｅｎｄｅｒ(登録商標)）あるいはコンパウンドエージェント（Ｃｏｍｐｏｕｎｄ Ａｇｅｎｔ(登録商標)） 他の複数のエージェントを含むエージェントの商標名で、（クライアント側ブレンダーの場合は）ユーザ、又は（サーバ側ブレンダーの場合は）エージェンシー管理者が、含まれるエージェントの結果の論理和又は論理積である、結果を生成する照会を作成できるようにする。クライアント側ブレンダーの場合は、結果は（異なるフレームのブレンダーにある各エージェントのビュー、含まれるエージェント全体にある特定のオブジェクトタイプを持つ全オブジェクトのビュー等の）異なるビューを用いた生成が可能である。
・ ブレイキングニュース エージェント（Ｂｒｅａｋｉｎｇ Ｎｅｗｓ Ａｇｅｎｔ(登録商標)） 時間の重要度を表示するものとして、ユーザが特別にタグ付けするスマートエージェントの商標名。ユーザは、どんなスマートエージェントでもブレイキングニュース エージェントとしてタグ付けできる。次にこの属性は、ユーザのセマンティックエンバイロメントに格納される。ブレイキングニュース エージェントは、表示される情報と関連した最新ニュースがある場合に警告を表示することが好ましい。
・ デフォルトエージェント（Ｄｅｆａｕｌｔ Ａｇｅｎｔ(登録商標)） ユーザに提示された、ユーザは修正できない標準化されたエージェントの商標名。
・ ドメインエージェント（Ｄｏｍａｉｎ Ａｇｅｎｔ(登録商標)） 意味論的ドメインに属するエージェントの商標名。これは、「カテゴリ」表への参照を含むエージェント照会で初期化される。
・ ダムエージェント（Ｄｕｍｂ Ａｇｅｎｔ(登録商標)） （ローカルハードドライブ上の）、ネットワークシェア上、ウェブリンク、又はＵＲＬ上のローカル情報を参照する、エージェンシーを持たないエージェントの商標名。ダムエージェントは、（ファイルシステム、又はインターネット等の）スマートでないサンドボックスから、（インフォメーションエージェント（意味論的ブラウザ）を経由したインフォメーションナーバス システムといった）スマートなサンドボックスに、本質的に（文書等の）情報項目を読み込むのに使われる。
・ イーメールエージェント（Ｅｍａｉｌ Ａｇｅｎｔ(登録商標) ）、あるいはイーメールナレッジ エージェント（Ｅｍａｉｌ Ｋｎｏｗｌｅｄｇｅ Ａｇｅｎｔ(登録商標)） エージェンシー上で情報を公開したり、注釈付加して、知識を共有するのに使われるパブリックエージェントの商標名。
・ フェイバリットエージェント（Ｆａｖｏｒｉｔｅ Ａｇｅｎｔ(登録商標)） ユーザが自分の好みで頻繁にアクセスすることを示すエージェントの商標名。
・ パブリックエージェント（Ｐｕｂｌｉｃ Ａｇｅｎｔ(登録商標)） システム管理者が作成し管理するエージェントの商標名。
・ パブリックあるいはローカルエージェント（Ｐｒｉｖａｔｅ ｏｒ Ｌｏｃａｌ Ａｇｅｎｔｓ(登録商標)） ユーザが作成し管理するエージェントの商標名。
・ サーチエージェント（Ｓｅａｒｃｈ Ａｇｅｎｔ(登録商標)） スマートエージェント上の付加的なテキストベースの照会フィルタを呼び出すために、キーワードを使って意味論的な環境のキーワード検索、又は既存スマートエージェントの検索で作成されたスマートエージェントの商標名。
・ シンプルあるいはスタンダードエージェント（Ｓｉｍｐｌｅ ｏｒ Ｓｔａｎｄａｒｄ Ａｇｅｎｔ(登録商標)） （ローカルのファイルシステム、又はデータソース等の）構造化された非意味論的な照会をカプセル化する単独型エージェントの商標名。
・ スマートエージェント（Ｓｍａｒｔ Ａｇｅｎｔ(登録商標)） ＸＭＬウェブサービスを経由して、エージェンシーを参照する構造化されて意味論的な照会をカプセル化する単独型エージェントの商標名。
・ スペシャルエージェント（Ｓｐｅｃｉａｌ Ａｇｅｎｔ(登録商標)） コンテキストテンプレートに基づいて作成されたスマートエージェントの商標名。
エージェント発見（Ａｇｅｎｔ Ｄｉｓｃｏｖｅｒｙ） ユーザに、（友達、又は同僚等の）他者が作成した新しいサーバ側エージェント、又はクライアント側エージェントを簡単で自動的に発見させる、本発明の情報メディアの特性。「発見の容易性」も参照のこと。
注釈付加（Ａｎｎｏｔａｔｉｏｎ） 情報オブジェクトに個人的な文脈を付加するのに使われる注釈、意見、又は解釈のこと。好ましい実施の形態においては、注釈付加は対象となるオブジェクトにリンクされた電子メールのメッセージであり、（通常の電子メールと同じく）添付ファイルを持つことができる。更に注釈付加は、システムでは最初のクラス情報オブジェクトであり、自らに注釈付加することができ、その結果最初のオブジェクトをルートとしたスレッド化された注釈付加、つまり注釈付加のツリーが生まれる。
アプリケーションプログラミングインタフェース（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ） ソフトウェアプログラマーがある特定のコンピュータの機能をどのように利用するかを定義したもの。ＡＰＩはウィンドウ機能のシステム、ファイルシステム、データベースシステム、ネットワークシステム、及び他のシステム用に存在する。
カレンダーアクセス プロトコル（ＣＡＰ：Ｃａｌｅｎｄａｒ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ） ユーザがアイカレンダー（ｉＣａｌｅｎｄａｒ）規格ベースのカレンダーストアに、デジタル方式でアクセスできるようにするインターネットプロトコル。
コンパウンドエージェント マネージャ（Ｃｏｍｐｏｕｎｄ Ａｇｅｎｔ Ｍａｎａｇｅｒ(登録商標)） コンパウンドエージェントの作成と削除を行うことで、ユーザがコンパウンドエージェントの作成、削除、と管理をプログラマチックに行えるようにするエージェンシー構成要素の商標名。
文脈（コンテキスト）（Ｃｏｎｔｅｘｔ） 情報消費者が項目を解釈する際、及びこの項目に関連する他の関連情報を検索する際に、意味の提供、又は手助けとなる特定の項目を取り囲んでいる情報。
文脈のリゾルトペイン（Ｃｏｎｔｅｘｔ Ｒｅｓｕｌｔｓ Ｐａｎｅ） 文脈に基づいた照会結果を表示するリゾルトペイン。これには、文脈パレット、スマートレンズ、ディープインフォメーション等の結果を含む。「リゾルトペイン」を参照のこと。
文脈依存性（Ｃｏｎｔｅｘｔ−Ｓｅｎｓｉｔｉｖｉｔｙ） 表示する全情報の文脈を知的、及び動的に認識することを可能にし、その文脈に与えられた付加的で関連ある情報を表示することを可能にする情報メディアの特性。文脈依存性システム、又はメディアは、表示する情報の意味論を理解し、（組み込みとしてかつ関係的に）正確な文脈で情報を表示するために、適切な動作（ユーザのアクションに基づいた事前対応型と事後対応型の動作）を提供する。
コンテキストテンプレート（Ｃｏｎｔｅｘｔ Ｔｅｍｐｌａｔｅ(登録商標)） 情報アクセスと取得用に、特定で、及びよく知っている意味論的モデルにマッピングするシナリオ主導型の情報照会テンプレートの商標名。例えば、好ましい実施の形態の「見出し」のテンプレートは、（新鮮さと高い興味度の可能性が取得の主要軸である）「見出し」の配信と一貫したパラメータを持つ。「今後のイベント」のテンプレートは「今後のイベント」の配信と一貫したパラメータを持つ等々。本質的にコンテキストテンプレートは、よく知られた意味論的テンプレートを用いることにより、ユーザに情報を配信する、個人的でデジタルの意味論的な情報の取得の「チャネル」という喩えを使って説明することができる。
ディープインフォメーション（Ｄｅｅｐ Ｉｎｆｏｒｍａｔｉｏｎ(登録商標)） インフォメーションエージェントに、情報オブジェクトに関連する内在的な文脈情報の表示を可能にする本発明の特徴の商標名。文脈情報には、そのオブジェクト所属先に当たるエージェンシーの意味ネットワークから掘り下げられた情報を含む。
発見の容易性（Ｄｉｓｃｏｖｅｒａｂｉｌｉｔｙ） ユーザが情報を明示的に探さなくても、知的に事前対応的にその情報を明らかにする、又は容易に表示する本発明の情報メディアの機能である。
ドメインエージェント ウィザード（Ｄｏｍａｉｎ Ａｇｅｎｔ Ｗｉｚａｒｄ(登録商標)） エージェンシー管理者がドメインエージェントの作成と管理を行えるようにするシステム構成要素とそのユーザインターフェースの商標名。
ドットネット（．ＮＥＴ） マイクロソフト（Ｍｉｃｒｏｓｏｆｔ(登録商標)）のドットネットは、情報、人、システム、及びデバイスを接続する一式のマイクロソフトのソフトウェア技術である。ＸＭＬウェブサービスを使ってソフトウェア統合を可能にする。小型で別個のビルディングブロック アプリケーションの相互接続だけでなく、インターネットを経由して、他の大規模なアプリケーションの相互接続を可能にする。ドットネットで接続されたソフトウェアは、ＸＭＬウェブサービスの作成と統合を容易にする。http://www.microsoft.com/net/defined/default.aspを参照のこと。
ダイナミックリンキング（Ｄｙｎａｍｉｃ Ｌｉｎｋｉｎｇ(登録商標)） 情報項目自体にリンクが含まれていなくても、ユーザが情報を動的に意味論的に、及び思考の速度でのリンクを可能にする本発明のインフォメーションナーバス システム機能の商標名。組み込み動作を持つスマートオブジェクトを採用し、インフォメーションエージェンシーのＸＭＬウェブサービスに埋め込まれた帰納的なインテリジェンスを使用することより、意味ネットワークの各ノードは、現在のウェブ、又は概念上の意味論的ウェブ上にある通常のリンク、又はノードよりはるかに知的である。言い換えれば、本発明のスマート仮想ネットワーク、又はウェブの各ノードは、オーサリングとは無関係に他のノードにリンクできる。各ノードは、ドラッグ＆ドロップとスマートコピー＆ペーストで、エージェンシーとスマートエージェントを動的にリンクする、セマンティックエンバイロメントのエージェンシーにリンクする、新しいリンクを作成するためにスマートエージェントからのレンズの要求に応答する、エージェンシー上の文脈に依存し時間に敏感な情報にリンクを動的に作成する組み込み警告を含める、（ノードが名前空間で最新ニュースエージェントに自動的にリンクする）最新ニュースの提示ヒントを含める、ユーザが新しいリンクを見つけ出すことができる詳細情報の基盤を構築する、等が可能となる動作を持っている。従って本発明のユーザは、メタデータ作成者に左右されない。ユーザは、いったんネットワークのノードに到達すると、文脈、時間、スマートエージェンシーとエージェンシーとの関連性等を使って、動的かつ自動的にナビゲートする多くの意味論的手段を持つ。
電子メールＸＭＬオブジェクト（Ｅｍａｉｌ ＸＭＬ Ｏｂｊｅｃｔ） 「電子メール」情報オブジェクトタイプを持つ情報オブジェクトのこと。ＸＭＬオブジェクトは、（ＸＭＬを使う）「電子メール」のＳＲＭＬスキーマを持つ。
環境ブラウザ（Ｅｎｖｉｒｏｎｍｅｎｔ Ｂｒｏｗｓｅｒ） 「インフォメーションエージェント」を参照のこと。
フェイバリットエージェント マネージャ（Ｆａｖｏｒｉｔｅ Ａｇｅｎｔｓ Ｍａｎａｇｅｒ(登録商標)） エージェンシー管理者が、サーバ側フェイバリットエージェントの管理をできるようにするシステム構成要素とユーザインターフェース要素の商標名。
フラッシュ（Ｆｌａｓｈ） マクロメディアフラッシュのユーザインターフェースプラットフォームで、開発者とコンテンツ作成者がコンテンツ内で高度なグラフィックスとアニメーションの埋め込みをできるようにする。http://www.macromedia.com/flashを参照のこと。
フラッシュＭＸ（Ｆｌａｓｈ ＭＸ） マクロメディアフラッシュＭＸは、インターネット用に様々な影響力の大きいコンテンツ、及びリッチなアプリケーションを作成するためのテキスト、グラフィックス、及びアニメーションの設計と開発の環境である。http://www.macromedia.com/software/flash/productinfo/product_overview/を参照のこと。
グローバルエージェンシー ディレクトリ（Ｇｌｏｂａｌ Ａｇｅｎｃｙ Ｄｉｒｅｃｔｏｒｙ(登録商標)） インターネット（又は他のグローバルネットワーク）上で動作するエージェンシーディレクトリの実現値の商標名。グローバルエージェンシー ディレクトリによって、ユーザは（意味論的な環境で直接に）インフォメーションエージェントを使ってインターネットベースのエージェンシーを見つけ出し、検索し、参照できる。「エージェンシーディレクトリ」も参照のこと。
ＨＴＴＰ ハイパーテキスト転送プロトコル（ＨＴＴＰ：Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）は、分散型で協調的なハイパーメディア情報システムのアプリケーションレベルのプロトコルである。汎用のステートレスプロトコルで、リクエストメソッド、エラーコード、ヘッダの延長を通して、ネームサーバや分散オブジェクト管理システム等のハイパーテキスト用の使用以外にも多くのタスクに使用することができる。ＨＴＴＰの特徴は、データ表現の入力とネゴシエーションで、転送データに関係なくシステム構築を可能にする。http://www.w3.org/Protocols/とhttp://www.w3.org/Protocols/Specs.htmlを参照のこと。
インファレンスエンジン（Ｉｎｆｅｒｅｎｃｅ Ｅｎｇｉｎｅ(登録商標)） 推論によって関連のある論理的に有効な結論に到達するためにパターンとデータを観察する本発明の方法論の商標名。本発明の意味ネットワークに意味論的なリンクを付加するために、インファレンスルール（所定の一組のヒューリスティック手法 ）を利用することが好ましい。
情報（Ｉｎｆｏｒｍａｔｉｏｎ） 知識を伝達するコンテンツ、又はデータの関連性、及びインテリジェンスの定量的、又は定性的な尺度。
インフォメーションエージェント（Ｉｎｆｏｒｍａｔｉｏｎ Ａｇｅｎｔ(登録商標)） 文脈に依存し時間に敏感な配信、及び複数の情報源、情報タイプ、及びテンプレートから行動可能な情報（又は知識）の表示を提供し、多種のレポジトリの全域で情報の動的リンクを行う、本発明の意味論的クライアント、又はブラウザの商標名。
インフォメーションナーバス システム（Ｉｎｆｏｒｍａｔｉｏｎ Ｎｅｒｖｏｕｓ Ｓｙｓｔｅｍ(登録商標)） ユーザが手元の作業を行うための知識の取得と使用を最大限に活用するために、思考の速度で文脈依存性と時間への敏感さを持って、情報を知的に、及び動的にリンクできるようにする、本発明の動的で自動オーサリングする、文脈と時間に敏感な情報システムの商標名。
インフォメーションオブジェクト、あるいはアイテム、あるいはパケット（Ｉｎｆｏｒｍａｔｉｏｎ Ｏｂｊｅｃｔ(登録商標) ｏｒ Ｉｔｅｍ ｏｒ Ｐａｃｋｅｔ） 所定の文脈中で知識を伝達する特定タイプの情報単位の商標名。
インフォメーションオブジェクト ピボット（Ｉｎｆｏｒｍａｔｉｏｎ Ｏｂｊｅｃｔ Ｐｉｖｏｔ(登録商標)） 同一文脈中で、関連ある他の情報を見つけ出すために、ユーザがナビゲーション状のピボットとして使う情報オブジェクトの商標名。
インフォメーションオブジェクト タイプ（Ｉｎｆｏｒｍａｔｉｏｎ Ｏｂｊｅｃｔ Ｔｙｐｅ） 「オブジェクトタイプ」を参照のこと。
知的エージェント（Ｉｎｔｅｌｌｉｇｅｎｔ Ａｇｅｎｔ） 情報を見つけ出してフィルタ処理を行う、サービスのネゴシエーションを行う、複雑なタスクを容易に自動化する、又は複雑な問題を解決するために他のソフトウェアエージェントと協力する、ことをユーザに代わって行うソフトウェアエージェント。その名が示すとおり、知的エージェントは自律的、つまりユーザの介入なしに自由に実行しなければならない。更に知的エージェントは、他のソフトウェア、又は人間のエージェントと通信する能力を持つ必要があり、そのエージェントが存在する環境を認識して監視する能力を有しなければならない。http://www.findarticles.com/cf_dls/m0FWE/7_4/64694222/p1/article.jhtmlを参照のこと。
インターネットカレンダリング及びスケジューリング（Ｉｎｔｅｒｎｅｔ Ｃａｌｅｎｄａｒｉｎｇ ａｎｄ Ｓｃｈｅｄｕｌｉｎｇ）（アイカレンダー：ｉＣａｌｅｎｄａｒ） インターネット用の相互運用が可能なカレンダリング、及びスケジューリングのサービスの配置を可能にするプロトコル。このプロトコルは、インターネット全域で公開でカレンダリング、及びスケジューリングの情報を交換するための共通形式の定義を提供する。
インターネットメッセージ アクセスプロトコル（ＩＭＡＰ：Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ） メールクライアントがメールサーバと対話し、そのサーバ上のメールボックスを処理するための通信方法。おそらく現在最も一般的なメールアクセスのプロトコルは、ポストオフィス プロトコル（ＰＯＰ）で、ＰＯＰはメールの遠隔アクセスのニーズにも対応する。ＩＭＡＰは、ＰＯＰ機能の上位集合を提供し、それによりはるかに複雑な対話を可能にし、ＰＯＰよりも更に効率的なアクセスの提供が可能になる。http://www-smi.stanford.edu/projects/imap/ml/imap.htmlを参照のこと。
イントリンシックセマンティック リンク（Ｉｎｔｒｉｎｓｉｃ Ｓｅｍａｎｔｉｃｋ Ｌｉｎｋ(登録商標)） 特定の情報オブジェクトのスキーマに組み込まれている意味論的リンクの商標名。例えば、電子メールの情報オブジェクトは、オブジェクト自体にネイティブで電子メールの情報オブジェクトタイプのスキーマで定義された「差出人」、「宛先」、「ＣＣ（カーボンコピー）」、「ＢＣＣ（ブラインドカーボンコピー）」、及び「添付ファイル」のような組み込みリンクを持っている。
孤立集団（Ｉｓｌａｎｄ） 関連性を持つ、意味論的に関係付けられた、文脈に依存し時間に敏感な情報を含んでいる可能性があるが、そのような関連性のある情報が存在する可能性がある他の文脈から切断されており、他のレポジトリから孤立している情報レポジトリ。
Ｊ２ＥＥ Ｊａｖａ(登録商標)２プラットフォームエンタープライズエディション（Ｊ２ＥＥ：Ｊａｖａ(登録商標) ２ Ｐｌａｔｆｏｒｍ， Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）は、多階層エンタープライズアプリケーションの開発用に使われる。Ｊ２ＥＥは、構成要素に一連のサービスを提供し、アプリケーション動作の数多くの詳細を自動的に処理することによって、標準化されたモジュール構成要素上にエンタープライズアプリケーションの基礎を構築する。http://java.sun.com/j2ee/overview.html.を参照のこと。
知識（Ｋｎｏｗｌｅｄｇｅ） 情報消費者が、関連ある作業に対してよりスマートに時宜にかなった決定を行うための情報からの学習、及び情報応用を行えるようにする、文脈に依存し時間に敏感な方法で提示された情報。
ナレッジエージェント（Ｋｎｏｗｌｅｄｇｅ Ａｇｅｎｔ(登録商標)） 「インフォメーションエージェント」を参照のこと。
ナレッジベース サーバ（ＫＢＳ）（Ｋｎｏｗｌｅｄｇｅ Ｂａｓｅ Ｓｅｒｖｅｒ(登録商標)）
ナレッジインテグレーション サーバ (ＫＩＳ)用に知識をホストするサーバの商標名。
ナレッジドメイン マネージャ（ＫＤＭ）（Ｋｎｏｗｌｅｄｇｅ Ｄｏｍａｉｎ Ｍａｎａｇｅｒ(登録商標)） 意味ネットワーク上で、ドメイン固有のインテリジェンスの追加、及び管理の役目を持つナレッジインテグレーション サーバの構成要素の商標名。
ナレッジインテグレーション サーバ（ＫＩＳ）（Ｋｎｏｗｌｅｄｇｅ Ｉｎｔｅｇｒａｔｉｏｎ Ｓｅｒｖｅｒ(登録商標)） 複数で様々な情報源から、意味ネットワークへデータを意味論的に統合するサーバで、ネットワークへのアクセスを提供するサーバ側エージェントをホストすることもでき、サーバ上の知識に文脈に依存し時間に敏感なアクセスを提供するＸＭＬウェブサービスをホストするサーバの商標名。
ナレッジウェブ（Ｋｎｏｗｌｅｄｇｅ Ｗｅｂ(登録商標)） 「インフォメーションナーバス システム」を参照のこと。
リバティアライアンス（Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ） リバティアライアンスのビジョンは、個人とビジネスが重要なＩＤ情報の個人情報保護と、セキュリティを保護しながらより容易なトランザクションが行えるネットワーク化した世界を実現することである。このビジョンを実現するために、リバティアライアンスは、公開された技術仕様書を通して連合ネットワーク認証情報のオープンスタンダードの設立を目指している。http://www.projectliberty.org/index.htmlを参照のこと。
ライトウェイトディレクトリ アクセスプロトコル（ＬＤＡＰ：Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ） 共通のディレクトリ情報にアクセスするための技術。ＬＤＡＰは大半のネットワーク志向のミドルウェアに取り入れられ実装されてきた。オープンでベンダー中立の規格として、ＬＤＡＰは現在の分散システム、及び分散サービスに利用可能な必要のある情報の集中型格納と管理のための拡張可能なアーキテクチャを提供する。ＬＤＡＰは現在、大半のネットワークオペレーティングシステム、グループウェア、及びパッケージのネットワークアプリケーションにおいてもサポートされている。http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg244986.html?Openを参照のこと。
リンクテンプレート（Ｌｉｎｋ Ｔｅｍｐｌａｔｅ(登録商標)） 「コンテキストテンプレート」を参照のこと。
局所的文脈（Ｌｏｃａｌ Ｃｏｎｔｅｘｔ） 局所的文脈とは、ユーザにアクセス可能なクライアント側の情報オブジェクトとエージェントのことである。これには、セマンティックエンバイロメント、ローカルファイル、フォルダ、ユーザの電子メール受信トレイの電子メール項目、ユーザのお気に入りのウェブページと最近使ったウェブページ、現在選択しているウェブページ、現在開いている文書、及びユーザの現在の作業、場所、時刻、又は状況を表すその他の情報オブジェクトにあるエージェントを含む。
意味（Ｍｅａｎｉｎｇ） 情報の有用性を最大化するために、情報消費者が（テキスト又はデータに対立するものとしての）関連ある情報の内容に基づいて情報を検索、及びナビゲートし、文脈に依存し時間に敏感な方法で対処できるようにする情報の振る舞いの属性。
メタデータ（Ｍｅｔａｄａｔａ） 「データに関するデータ」。情報オブジェクトを完全に記述するデータのフィールド、リンク、及び属性が含まれる。
自然言語パーサ（Ｎａｔｕｒａｌ Ｌａｎｇｕａｇｅ Ｐａｒｓｅｒ） 自然言語での照会を理解して、それを構造化した意味論的な情報の照会に変換する、構文解析と解釈のソフトウェアの構成要素。
ナーバナ（Ｎｅｒｖａｎａ(登録商標)） インフォメーションナーバス システムの情報メディア／プラットフォームの所有権のあるエンドツーエンドの実装の商標名。これは、リソースタイプと、述語名の修飾子の専有の名前空間も定義する。
ドットネットパスポート（．ＮＥＴ．Ｐａｓｓｐｏｒｔ） マイクロソフトのドットネットパスポートは、インターネット、及びオンライン購買向けのウェブベースサービスのパッケージソフトである。ドットネットパスポートは、ユーザにシングルサインイン（SSI：single sign-in）と、ユーザが記憶しておく、又は再入力しなければならない情報量を削減することで、ますます加入数が増えているサイトでの迅速な購買能力を提供している。 ドットネットパスポートは、大規模なユーザベース向けの上質のオンライン体験を提供し、データ保護にセキュアソケット レイヤ（SSL：Secure Sockets Layer）、及びトリプルデータ暗号化規格（3DES）アルゴリズム等の強力な暗号化技術を用いる。個人情報保護も又最優先事項で、全加入サイトは業界承認の指針を順守する個人情報保護方針を掲示すること、及び順守することに合意する契約を結ぶ。
ネットワーク効果（Ｎｅｔｗｏｒｋ Ｅｆｆｅｃｔ） これは、他のユーザの数が、あるユーザにとっての製品、又はサービスの価値に影響する時に存在する。電話サービスは、明解な例である。ユーザにとって電話サービスの価値は、他の登録者数に相関する。電話が誰にも接続されていないのであれば、電話に関心を持つ人はほとんどいないであろうし、大半の人はローカルネットワークだけよりも全国ネットワークに接続された電話サービスを高く評価するだろう。同様に、コンピュータユーザの多くは、他のユーザと簡単に情報を交換できるコンピュータシステムを高く評価する。
従って、ネットワーク効果は、成功している製品には更に成功する前向きなフィードバック効果をもたらす、需要側からの副次的影響である。このように、ネットワーク効果は、規模と範囲の供給側の経済性に類似している。企業が生産高を増加するにつれて、規模の経済性は平均原価の減少をもたらし、価格を引き下げて競合企業から他の取引を獲得することができる。続けて展開することで、平均原価を更に減少させ、価格の更なる引き下げが正当化される。同様に、ネットワーク効果からの前向きな反応は、以前に起こった成功の上に築かれる。コンピュータ業界において、例えば、知名度が高いコンピュータシステムにもっと払うか、又は２つのコンピュータシステムが価格と他の特長において同等な場合、ユーザは全てが同じ場合は、より大規模な設置基盤を持つシステムの方を選ぶ。http://www.ei.com/publications/1996/fall1.htmを参照のこと。
ネットワークニュース転送プロトコル（ＮＮＴＰ：Ｎｅｔｗｏｒｋ Ｎｅｗｓ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）） ＡＲＰＡインターネットコミュニティ間のニュースを信頼性ある、ストリームベースの転送を使うニュース記事の配信、問い合わせ、取得及び投稿用のプロトコル。ＮＮＴＰは、ニュース記事が中央データベースに格納されており、会員登録者が読みたい項目だけを選択できるように設計されている。索引付け、相互参照、及び古いメッセージの期限切れも提供する。
通知（Ｎｏｔｉｆｉｃａｔｉｏｎ） 通知は、（クライアント側エージェント、又はサーバ側エージェントのどちらかの）エージェント上に新しい情報があることをユーザに表示するための、インフォメーションエージェント、又はエージェンシーにより送信される警告である。ユーザは、セマンティックエンバイロメントにあるエージェントから通知を要求することができる。ユーザは、通知を受信したことを表示できる。（クライアント又はサーバの）通知元は、ユーザがエージェント用通知の受信確認を最後に行ったのがいつかを示して、ユーザとエージェント用の情報を格納する。通知元は、最後の受信確認以来新しい情報があるか否かを調べるために、エージェントをポーリングする。もしあれば通知元はユーザに警告を出す。警告は、電子メール、ポケットベル、音声、又はマイクロソフトのドットネット警告サービス等のカスタム警告方法で送信できる。ユーザは、通知元上の全てのエージェントに適用される（クライアント又はサーバの）通知元全体用、又は通知元に示したプレファレンスを上書きするエージェント単位で、自分の好みの通知方法を示す選択肢がある。
オブジェクト（Ｏｂｊｅｃｔ） 「インフォメーションオブジェクト」を参照のこと。
オブジェクトタイプ（Ｏｂｊｅｃｔ Ｔｙｐｅ） 情報に関連付けられた識別データで、消費者が。情報の性質の理解をしたり、内容を解釈したり、情報を行動に移す方法を予測したり、及びそのオブジェクトタイプが実社会で一般的にどのように関係するかに基づく他の関連ある情報の項目にリンクしたりするのをできるようにする。例としては、文書、イベント、電子メールメッセージ、人等が挙げられる。
オントロジ（Ｏｎｔｏｌｏｇｙ） 本質的な性質に基づく知識の階層構造。オントロジは、概念化を明示的に詳述したものである。哲学からの借用語で、「オントロジ（存在論）」とは存在を系統的に説明したものである。人工知能システムでは、「存在」するものは表わすことができる。ドメインの知識が宣言形式で表されると、一組の表現可能なオブジェクトは、論議領域と呼ばれる。この一組のオブジェクト、及びその中での記述可能な関係は、知識に基づいたプログラムが知識を表現する具象的な語彙に反映される。従って、人工知能の文脈では、プログラムのオントロジは一組の具象的な用語を定義することで記述される。そのようなオントロジにおいて、定義は（クラス、関係、関数、又は他のオブジェクトといった）論議領域における実体の名前を、名前の意味を記述した人間可読テキスト、及びこれらの用語の解釈とよくまとめられた使用を拘束する形式的な公理に関連付ける。形式上オントロジは、論理的理論における命令文である。
オントロジの主題は、あるドメインに存在する、又は存在するかもしれない事象のカテゴリ化についての研究である。オントロジと呼ばれるそのような研究の成果は、関心事のドメインＤについて語る目的で言語Ｌを使用する人の観点から、Ｄに存在すると想定される事象タイプのカタログである。オントロジにおけるタイプは、ドメインＤ内のトピックを議論するのに使われる際の言語Ｌの述語、語義、又は概念と関係タイプを表す。一般的にはhttp://www-ksl.stanford.edu/kst/what-is-an-ontology.htmlとhttp://users.bestweb.net/~sowa/ontology/を参照のこと。
述語（Ｐｒｅｄｉｃａｔｅ） 述語は、結果がある条件の真偽を表す属性、又はリンクである。例えば、述語「による作成」は、情報オブジェクトと人をリンクし、人がそのオブジェクトを作成したかどうかを示す。
プレゼンタ（Ｐｒｅｓｅｎｔｅｒ(登録商標)） 本発明のインフォメーションエージェント（意味論的ブラウザ）にあるシステム構成要素で、（ＳＱＭＬを解釈することが好ましい）意味論的な照会プロセッサからの結果の集約、及び提示を担当する。プレゼンタは、レイアウト管理、集約、ナビゲーション、スキン管理、文脈パレットの提示、対話性、アニメーション等を担当する。
ＲＤＦ リソースディスクリプション フレームワーク（ＲＤＦ：Ｒｅｓｏｕｒｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｒｏｋ）は、メタデータ処理の基礎で、ウェブ上で機械が理解可能な情報をやりとりするアプリケーション間で相互運用性を提供する。ＲＤＦは、ウェブリソースの自動処理を可能にするための使いやすさを重視する。ＲＤＦは、指名された特性と価値の点からリソース間の関係を記述する単純モデルを定義する。ＲＤＦの特性はリソースの属性としてとらえられることがあるが、その意味では従来の属性と属性値のペアに相当する。ＲＤＦの特性は又リソース間の関係を表す。従って、ＲＤＦのデータモデルはＥＲ（実体関連）図に類似する。
ＲＤＦは、より優れた検索エンジン機能を提供するためのリソースを検索したり、知識の共有及び交換を円滑にするための知的ソフトウェアエージェントによる特定のウェブのサイト、ページ、又はデジタルライブラリにおいて利用可能なコンテンツとコンテンツの関係の記述用にカタログ化したり、コンテンツを評価したり、単一の論理「文書」を表現するページの集合を記述する、ウェブページの知的所有権を記述したり、及びウェブサイトにおける個人情報保護のプレファレンス、及び個人情報保護方針を記述したりする等の多種多様なアプリケーション分野で使用できる。デジタル署名の機能を持つＲＤＦは、電子商取引、共同作業、及びその他のアプリケーション用の「信用の輪」を構築する構成要素であることが好ましい。一般的にはhttp://www.w3.org/TR/PR-rdf-syntax/とhttp://www.w3.org/TR/rdf-schema/を参照のこと。
ＲＤＦＳ（ＲＤＦ Ｓｃｈｅｍａ） ＲＤＦスキーマの頭字語である。リソース記述のコミュニティでは、特定タイプのリソースに関するある事項の記述能力を必要とする。例えば、資料（bibliographic resource）を記述するのに、「作成者」、「タイトル」及び「件名」を含む記述属性は一般的である。デジタル認証用に、「チェックサム」、及び「許可」等の属性がよく必要とされる。これらの特性（属性）の宣言と、それに対応する意味論は、ＲＤＦの文脈でＲＤＦスキーマとして定義される。スキーマは、（タイトル、作成者、件名、サイズ、色等の）リソースの特性を定義するだけではなく、（書籍、ウェブページ、人、会社等の）記述対象となるリソースタイプも定義する。http://www.w3.org/TR/rdf-schema/を参照のこと。
リゾルトペイン（Ｒｅｓｕｌｔｓ Ｐａｎｅ(登録商標)） SQML照会結果を表示する、インフォメーションエージェント（意味論的ブラウザ）内にある画像表示領域の商標名。サーバ側エージェント、任意選択のプレーヤーコントロール／ナビゲーション／フィルタのツールバー、（ユーザがサーバ側エージェントを参照したり開くようにできる）「サーバ側エージェントダイアログ」、及びサーバ側エージェントからの（「文書」情報オブジェクトタイプを持った）結果例を示したインフォメーションエージェントの画面例である図５を参照のこと。
意味論（Ｓｅｍａｎｔｉｃｓ） 内包的意味のこと。
セマンティックエンバイロメント（Ｓｅｍａｎｔｉｃ Ｅｎｖｉｒｏｎｍｅｎｔ(登録商標)） ユーザのローカルマシンに格納された全てのデータ、更に（会員登録するサーバ側エージェンシー、サーバ側フェイバリットエージェント等の）エージェントサーバ上にあるユーザ固有のデータのこと。クライアント側の状態は、各クライアント側の（ユーザが作成した）エージェント用のＳＱＭＬファイルとバッファに加えて、お気に入りのエージェントと最近のエージェント、及び（多種のエージェンシー用のユーザ名とパスワード等の）認証と許可の情報を含む。インフォメーションエージェントは、「お気に入り」のリストに加えられたものを除いては、自動的に削除される前にある一定の期間はエージェントを格納するように設定されることが好ましい。例えば、ユーザは、エージェントを２週間格納しておくように、インフォメーションエージェントを設定することができる。この場合、２週間以上経ったエージェントは、システムから自動的に消去され、セマンティックエンバイロメントがそれに応じて調整される。セマンティックエンバイロメントは文脈パレットに使われる（文脈パレットではデフォルトエージェンシーのユーザが文脈を表示したいものを予測するための、「最近使われた」及び「お気に入り」のリストにあるエージェンシーを使う）。
セマンティックエンバイロメント マネージャ（Ｓｅｍａｎｔｉｃ Ｅｎｖｉｒｏｎｍｅｎｔ Ｍａｎａｇｅｒ(登録商標)） （インフォメーションエージェント内で）セマンティックエンバイロメントの全てのローカル状態を管理するソフトウェア構成要素の商標名。これには、クライアント側エージェント（及び履歴、及びお気に入りのエージェントの下位リスト）のメタデータ、（エージェントスキン、エージェントのプレファレンス等の）エージェントごとの状態、通知管理、（エージェンシーディレクトリでの）エージェンシー閲覧、マルチキャスト、及びピアツーピアの告知プロトコルを経由したエージェンシーのリスン、（ツリービュー、「エージェントを開く」ダイアログ、及びリゾルトペイン等を使った）意味論的ブラウザを経由してユーザがセマンティックエンバイロメントを参照できるサービス、等を格納し管理することが含まれる。
セマンティックデータ ギャザラー（ＳＤＧ）（Ｓｅｍａｎｔｉｃ Ｄａｔａ Ｇａｔｈｅｒｅｒ(登録商標)） ナレッジインテグレーション サーバ（ＫＩＳ）によって使われるＸＭＬウェブサービスの商標名で、セマンティックメタデータ ストア（ＳＭＳ）を経由した意味ネットワークでエントリの追加、除去、及び更新の役目を持つ。
セマンティックメタデータ ストア（ＳＭＳ）（Ｓｅｍａｎｔｉｃ Ｍｅｔａｄａｔａ Ｓｔｏｒｅ(登録商標)） ＫＩＳ上に全てのメタデータを格納するために、それぞれの主要オブジェクトタイプの表を持つ（ＳＱＬサーバ、オラクル、ＤＢ２等の）データベースを用いる、ＫＩＳ上にあるソフトウェア構成要素の商標名。
意味ネットワーク（Ｓｅｍａｎｔｉｃ Ｎｅｔｗｏｒｋ） セマンティックメタデータ ストア上のデータベース表を経由して意味論的なやり方でスキーマに関連付けられたオブジェクトをリンクするシステムと方法。
セマンティックネットワーク コンシステンシーチェッカー（Ｓｅｍａｎｔｉｃ Ｎｅｔｗｏｒｋ Ｃｏｎｓｉｓｔｅｎｃｙ Ｃｈｅｃｋｅｒ(登録商標)） 意味ネットワークの完全性と整合性の維持を担う、本発明のエージェンシー上で実行するソフトウェア構成要素の商標名。このチェッカーは、定期的に実行され、「セマンティックリンク」表のエントリがネイティブなオブジェクト表内に存在すること、「オブジェクト」表のエントリがネイティブなオブジェクト表に存在すること、及びセマンティックメタデータ ストア内の全てのエントリが収集されてきたレポジトリに依然として存在することを確実にする。
意味論的な照会（Ｓｅｍａｎｔｉｃ Ｑｕｅｒｙ） 自然言語に存在するような意味、文脈、時間への敏感さ、コンテキストテンプレート、及び豊かさを組み込んだ照会。文脈に依存し時間に敏感で、意味又は意味論を組み込んでいるので、単純でキーワードに基づいた照会よりもはるかに強力である。
意味論的クエリマークアップ言語（ＳＱＭＬ：Ｓｅｍａｎｔａｉｃ Ｑｕｅｒｙ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ） 本発明で使われる専有のＸＭＬベースの照会言語で、クライアント側の意味論的照会を定義、格納、解釈、及び実行する。ＳＱＭＬには、ファイル、フォルダ、アプリケーションレポジトリ、及び（リソース識別子及びＵＲＬを経由した）エージェンシーのＸＭＬウェブサービスへの参照等の（データソースを表現する）多種多様なリソースからデータを取得する照会を定義するタグが含まれる。更に、ＳＱＭＬにはリソースからのデータの照会、及びフィルタリングの方法を示す（カスタムリンク、及び述語を経由した）意味論的なフィルタリングを可能にするタグ、リソースの照会方法、及び結果のフィルタリング方法を示す引数が含まれる。特に引数は、局所的、又は遠隔の文脈への参照を含むことができる。次に文脈引数はランタイムに、ＸＭＬ形式メタデータへクライアント側ＳＱＰによって解決される。この後ＸＭＬ形式メタデータは、（エージェンシーのＸＭＬウェブサービス等の）リソースにより照会がどのように解決されるかを示すリソースと意味論的なリンクと述語と一緒に、メソッド呼び出しとして（エージェンシーのＸＭＬウェブサービス等の）適切なリソース渡される。ＨＴＭＬが現在のウェブ用であるのと同様、ＳＱＭＬはインフォメーションナーバス システム用である。主な違いは、ＨＴＭＬがハイパーテキストの表示規則を定義するのに対し、ＳＱＭＬは意味論的な照会の規則を定義することである。ＳＱＭＬが優っているのは、ドラッグ＆ドロップとスマートコピー＆ペースト、スマートレンズ、コンテキストテンプレート、及びパレット等を経由して、クライアントに（既存のＳＱＭＬの照会から派生した新しいリンクで新しいＳＱＭＬを作成することによって）既存照会から新しい意味論的照会の再帰的な作成を可能にすることである。更にＳＱＭＬは、表示規則を定義しないので、ユーザのプレファレンス、興味、状態、又は文脈に基づいた提示を生成するために（ＳＲＭＬにおける）結果を取得する「スキン」を使って、意味論的な照会結果を複数の方法で提示することができる。更にＳＱＭＬは、コンテキストテンプレートを参照、又は使用するような抽象的なリンク、及び述語を含むことができる。（エージェンシーのＸＭＬウェブサービス等の）リソースは、次に（ＳＱＬ、又はエージェンシーのＸＭＬウェブサービスの場合はそれの同等物等）の適切な照会形式にＳＱＭＬを解決してから、（ユーザの文脈、又はコンテキストテンプレートを説明することになる）結果を生成するための「実際の」照会を呼び出す。又、ＳＱＭＬバッファ、又はファイルは、複数のリソース（及びエージェンシー）を参照できるので、データのソースに基づいた結果よりもむしろクライアントが（文脈依存性、又は時刻への敏感性に基づいた）集合体として結果を表示する能力を与える。これはユーザ制御のブラウジング、及び情報の集約（これについての以下の各項を参照のこと）を可能にする本発明の強力な特徴である。最後に、各ウェブページがＨＴＭＬファイルを持っているのと同様に、各クライアント側エージェントはＳＱＭＬの定義とファイルを持っている。
セマンティッククエリ プロセッサ（ＳＱＰ）（Ｓｅｍａｎｔｉｃ Ｑｕｅｒｙ Ｐｒｏｃｅｓｓｏｒ(登録商標)） ＳＱＭＬを取得し、それを（好ましい実施の形態の場合には）ＳＱＬに変換して、その結果をＸＭＬ形式として返すサーバ側の意味論的な照会プロセッサ（好ましい実施の形態ではＸＭＬウェブサービス）の商標名。ナレッジインテグレーション サーバ（ＫＩＳ）のおいて、ＳＱＰはＫＩＳクライアントからの意味論的照会に応答する役目を持つ、本発明の意味ネットワークへの主な入口点である。サーバ側では、クライアントからＳＱＭＬとして表された意味論的照会を処理するソフトウェア構成要素である。クライアント側では、クライアント側ＳＱＰは集合体ＳＱＭＬを取得し、それをサーバ（又はエージェンシーの）ＸＭＬウェブサービスに送ることができる個別のＳＱＭＬの照会にコンパイル、又はマッピングする。
意味論的結果マークアップ言語（ＳＲＭＬ：Ｓｅｍａｎｔｉｃ Ｒｅｓｕｌｔｓ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ） 意味論的結果を定義、格納、解釈、及び提示するために本発明で使われる専有のＸＭＬベースのデータスキーマとデータ形式。クライアント側では、意味論的データソースに解釈、書式設定、及び照会要求を発行する意味論的リソースハンドラを経由してＳＲＭＬはＳＱＰから返される。意味論的データソースには、エージェンシーのＸＭＬウェブサービス、ローカルファイル、ローカルフォルダ、（マイクロソフトのアウトルック電子メールアプリケーションの受信トレイ等の）ローカル又は遠隔のアプリケーションからのカスタムデータソース等が含まれる。ＸＭＬウェブサービスは、クライアントの意味論的な照会に対応してＳＲＭＬをクライアントに返す。このやり方では、ＸＭＬウェブサービスはクライアントにおいて結果がどのように提示されるかは「配慮」しない。これはサーバが、クライアントに提示するためにすでに書式設定済みのＨＴＭＬを返しクライアントが単に（意味論的データと対比した）提示データを表示し、データの提示をカスタマイズすることはできない現在のウェブと意味論的ウェブとは対照的な点である。本発明において、２つのうちどちらかのクライアントのユーザによって、選択、又は適用された現在の「スキン」を基にして、２つのクライアントは同じＳＲＭＬをまったく異なるやり方で表現することができる。「スキン」はそれからＸＨＴＭＬ、ＤＨＴＭＬ＋ＴＩＭＥ、ＳＶＧ、フラッシュＭＸ等の表示対応の形式にＳＲＭＬを変換する。
ＳＲＭＬは、（文書、電子メール、人、イベント等の）異なる情報オブジェクトタイプ用のデータを含むことができるコンテナ形式であるという意味でメタスキーマである。ＳＲＭＬファイル、又はバッファには、これらのオブジェクト各タイプが互いに関係した結果を含むことができる。整形式ＳＲＭＬには、ＳＲＭＬが表現する意味論的結果に含まれた情報オブジェクトのタイプのスキーマと一致する整形式ＸＭＬ文書セクションが含まれる。本付属書類の実例Ａを参照のこと。
意味論的ウェブ（Ｓｅｍａｎｔｉｃ Ｗｅｂ） 現在のウェブの延長で、情報には十分に定義された意味が与えられ、コンピュータと人とのより優れた協力作業を可能にする（参照文献：Tim Berners-Lee, James Hendler, Ora Lassila, The Semantic Web, Scientific American, May 2000）。
現在のウェブの機械が理解可能なデータを含める機能は、多くのコミュニティにとって最優先事項になってきている。ウェブは、人だけでなく自動化されたツールによってデータが共有、及び処理される場所になる場合に、初めて最大限の可能性に達成できる。ウェブの規模を変更するためには、将来のプログラムは、全く個別に設計されていたとしても、データを共有、及び処理できなければならない。意味論的ウェブは概念上のビジョンである。つまりウェブ上のデータを、多種多様なアプリケーションにわたってデータを表示用だけでなく、自動化、統合化、及び再利用するためにマシンによって利用できるようなやり方で定義してリンクする着想のことである。http://www.w3.org/2001/sw/も参照のこと。
セッションアナウンスメント プロトコル（ＳＡＰ：Ｓｅｓｓｉｏｎ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ） マルチキャストのマルチメディア会議、及び他のマルチキャストセッションの通知を支援する、及び関連あるセッションの設定情報を予定参加者に連絡するために、分散セッションのディレクトリを使うことも可能である。このようなセッションディレクトリの場合、セッションの内容を含むパケットを定期的にマルチキャストし、そのような通知は、遠隔予定参加者がセッションに参加するために必要となるツールを起動するために、セッション記述が利用できるように、他のセッションディレクトリによって受信される。
もっとも単純な形態では、特定セッションを記述するセッション告知パケットの定期的なマルチキャストを必要とする。ＳＡＰを受信するために、受信側では単に周知のマルチキャストアドレスとポートにリスンする。セッションはセッション記述プロトコル（ftp://ftp.isi.edu/in-notes/rfc2327.txt）を使って記述されている。受信側がセッション告知パケットを受信すると、単にＳＤＰメッセージを復号化してユーザ用のセッション情報を表示することができる。同じセッションの記述メッセージの反復間の間隔は、告知するセッション数によって決まり（特定の範囲にある各送信側は同範囲内にある他の送信側を聞く事ができる）、そうすることにより特定の範囲のセッション告知用に使われる帯域幅はほぼ一定に保持される。受信側が所定時間リスンし、セッションの告知を聞かなければ、受信側ではセッションが削除され、もはや存在しないと結論付けることができる。所定期間は、受信側で予測する送信側が送るべき頻度数に基づく。一般的にはhttp://www.faqs.org/rfcs/rfc2974.html、http://www.video.ja.net/mice/archive/sdr_docs/node1.html、ftp://ftp.isi.edu/in-notes/rfc2327.txtを参照のこと。
シンプルメール転送プロトコル（ＳＭＴＰ：Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ） 確実で効率的にメールを転送するために作られたプロトコル。ＳＭＴＰは、特定の伝送サブシステムと無関係で、確実に命令したデータストリームのチャネルのみが必要とされる。ＳＭＴＰの重要な特徴は、トランスポート環境全域にメールをリレーする機能である。http://www.ietf.org/rfc/rfc0821.txtを参照のこと。
スキン（Ｓｋｉｎ） エージェント単位でユーザ経験をカスタマイズするのに用いたり、又は意味論的ドメイン名／パス、又はオントロジ、及び他の考慮事項用に（エージェントと無関係に）レイアウト全体、又は（情報オブジェクトのタイプに基づいた）オブジェクト、（コンテキストテンプレートに基づいた）文脈、（ブレンダーであるエージェント用の）ブレンダーの提示をカスタマイズするのに用いる表示テンプレートである。各エージェントはスキンを含み、スキンは情報オブジェクト（レイアウトスキン）を表すＸＭＬ形式による結果のレイアウトをカスタマイズするためのパラメータのＸＭＬ形式メタデータ表現を持つ。例としては、結果のアニメーション化の有無、各結果の表示方法、現在の結果のオントロジ（オントロジスキン）を示すオブジェクトのタイプ（オブジェクトスキン）、スタイル、色、グラフィックス、フィルタ、変形、効果、アニメーション等と、現在の結果のコンテキストテンプレートを示すスタイル（文脈のスキン）、及びブレンダーからの結果の表示、及びナビューゲートの方法を示すスタイル（例えば、ブレンダースキン）の表現を含む。
スマートレンズ（Ｓｍａｒｔ Ｌｅｎｓ(登録商標)） ユーザが、スマートエージェント、又はオブジェクトを別のオブジェクト、又はエージェントを表示するための文脈として、スマートエージェント、又はオブジェクトを選択できるようにする本発明の専有の特徴の商標名。レンズは文脈が呼び出されると、何を期待すべきかをユーザに指示するメタデータ、リンク、及び結果のプレビューを表示する。本質的にスマートレンズは、「起こり得る照会」の結果を表示する。スマートレンズによって、ユーザは実際照会を呼び出すことなく文脈結果をすばやくプレビューすることを可能にする（従って生産性が向上する）。更に、スマートレンズはピボット、テンプレート及びプレビューウィンドウを使って、文脈と一致するビューを表示することができ、それによりユーザが照会を呼び出す前に異なるやり方で文脈を分析できる。
スマート バーチャル ウェブ（Ｓｍａｒｔ Ｖｉｒｔｕａｌ Ｗｅｂ(登録商標)） ユーザが、制御しカスタマイズ可能な、動的で仮想、「オンザフライで」、ユーザ制御で「ウェブ」をブラウジングする能力を与える、意味論、文脈依存性、時間への敏感性、及びダイナミズムを統合するための本発明の特性の商標名。これは、ユーザがネットワーク上の情報の作成者に左右されてる、手作業で作成されたネットワークを使用する現在のウェブと概念上の意味論的ウェブと対照的である。
構造化照会言語（ＳＱＬ：Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ） 「エスキューエル」と発音する。ＳＱＬはデータベースと通信するのに使われる。米国規格協会（ＡＮＳＩ）によると、リレーショナルデータベース管理システム用の標準言語である。ＳＱＬ文は、データベースのデータの更新、又はデータベースからのデータの取得等のタスクを行うのに使われる。ＳＱＬを使う一般的なリレーショナルデータベース管理システムには、オラクル、サイベース、マイクロソフトＳＱＬサーバ、アクセス、イングレス、等が含まれる。大半のデータベースシステムがＳＱＬを使うが、その多くは通常各自のシステム上でのみ使われる、付加的な所有権のある拡張機能も持っている。しかしながら、「Select」、「Insert」、「Update」、「Delete」、「Create」及び「Drop」等の標準ＳＱＬコマンドを使って、データベースの操作に必要なほとんど全てを遂行できる。
ＳＱＬはリレーショナルデータベースと連動する。リレーショナルデータベースは、表（関係）にデータを格納する。データベースは表の集合体である。表はレコードのリストで構成され、表の各レコードには同じ構造が含まれることが望ましく、それぞれは指定タイプの一定数の「フィールド」を持っている。一般的にはhttp://www.sqlcourse.com/intro.htmlとhttp://www.dcs.napier.ac.uk/~andrew/sql/0/w.htmを参照のこと。
スケーラブルベクター グラフィックス（ＳＶＧ：Ｓｃａｌａｂｌｅ Ｖｅｃｏｔｒ Ｇｒａｐｈｉｃｓ） ＸＭＬで二次元グラフィックスを記述する言語である。ＳＶＧで、（直線と曲線からなるパス等の）ベクトル図形の形状、画像及びテキストの３つのタイプの図形オブジェクトが可能になる。図形オブジェクトは、以前描画したオブジェクトにグループ分け、スタイル化、変形、及び合成できる。テキストはアプリケーションに適したどんなＸＭＬ名前空間にでも存在でき、これはＳＶＧグラフィックスの検索とアクセスの容易性を強化する。機能セットには、繰り込み変換、クリッピングパス、アルファマスク、フィルタ効果、テンプレートオブジェクト及び拡張性が含まれる。ＳＶＧ図面は動的で対話型である。ＳＶＧ用文書オブジェクトモデル（ＤＯＭ）は、完全なＸＭＬ ＤＯＭを含み、スクリプト記述を通して簡単で効果的なベクトルグラフィックスアニメーションを可能にする。onmouseover（オンマウスオーバー） と onclick（オンクリック）等の豊富なイベントハンドラの一式は、どんなＳＶＧテキストのオブジェクトへも割り当てができる。他のウェブ規格との互換性と流用性があるため、スクリプト記述等の機能は、同じウェブページ内の異なる名前空間から同時に、ＳＶＧ要素、及び他のＸＭＬ要素上に行うことができる。http://www.w3.org/Graphics/SVG/Overview.htm8.を参照のこと。
分類法（Ｔａｘｏｎｏｍｙ） グループ、又はカテゴリに編成された区分の中での組織構造。
時間への敏感さ（Ｔｉｍｅ−Ｓｅｎｓｉｔｉｖｉｔｙ） 情報が最も妥当な時に基づいて、その情報を配信、及び提示するための情報メディアの特性。例えば、新鮮さは時間への敏感さを表示する属性である。更に、今後のイベントの配信と提示（これは明らかに時間に敏感である）、及び時間の重要度順に表示されたイベントは、時間に敏感なメディアの特性である。
現在のウェブ（Ｔｏｄａｙ‘ｓ Ｗｅｂ） これは、現在ワールドワイドウェブとして知られているものである。現在のウェブは、サーバがテキスト、グラフィックス、音声のファイル等を一緒にリンクするハイパーテキストサーバ（ＨＴＴＰサーバ）の世界である。ハイパーテキストは単に情報を表示する非線形な方法である。作成者、又は編集者、もしくは発行者が読み手のために配置する順に事柄を読んだり、学んだりするよりもむしろ、ハイパーテキストの読み手が自分の道順をたどって、資料から独自の順序や意義を作成できる。これは、情報間に「リンク」を作成することにより実現する。このようなリンクは、ユーザが検討中の特定のトピックに関する他の情報に「ジャンプ」（これには更にリンクがあるかもしれず、各読み手を異なった方向に導びく）ができるように提供されている。ハイパーテキストメディアには、写真、音声、及び映像を組み込んだり、情報表示にマルチメディアのアプローチを提示することができる。これはハイパーメディアとも呼ばれる。一般的にはhttp://www.w3.org/History.htmlとhttp://www.umassd.edu/Public/People/KAmaral/Thesis/hypertext.htmlを参照のこと。
マルチキャストの有効期限（ＴＴＬ：Ｍｕｌｔｉｃａｓｔ Ｔｉｍｅ ｔｏ Ｌｉｖｅ） マルチキャストのルーティングプロトコルは、送信ホストから指定のマルチキャストパケットがどれだけ「遠く」に転送されるべきかを決めるためにデータグラムのフィールドを使う。マルチキャストデータグラムのデフォルトのＴＴＬは１で、マルチキャストパケットがローカルネットワーク上の他のホストにのみ行くことになる。setsockopt(2)呼び出しはＴＴＬを変更するのに使うことができる。ＴＴＬの値が大きくなるにつれて、ルータはマルチキャストパケットを転送するホップ数を大きくする。有意義な範囲制御を提供するために、通常マルチキャストルータは、ＴＴＬのフィールドに基づいて転送に関する次の「しきい値」を実施する。
・ ０は同一ホストに限定される。
・ １は同一サブネットに限定される。
・ ３２は同一サイトに限定される。
・ ６４は同一領域に限定される。
・ １２８は同一大陸に限定される。
・ ２２５は制限なし。
http://www.isl.org/projects/eies/mbone/mbone27.htmを参照のこと。
ユーザ状態（Ｕｓｅｒ Ｓｔａｔｅ） ユーザによって作成された全ての状態、あるいはユーザプレファレンス、お気に入り、又は他の個人的な情報をクライアント又はサーバ上にキャッシュするのに必要な全ての状態のいずれかを指す。クライアント側のユーザ状態には、認証用の資格証明書、ユーザエージェントのリスト（及びそのエージェントのＳＱＭＬ照会を含む全てのメタデータ）、ホームエージェント、構成の選択肢、スキン等のプレファレンスが含まれる。本質的にクライアント側のユーザ状態は、ユーザのセマンティックエンバイロメントの持続的な形態である。サーバ側のユーザ状態には、ユーザのフェイバリットエージェント、会員登録したエージェント、デフォルトエージェント、（「お気に入り」のリンク等の）サーバ上の情報オブジェクトへの意味論なリンク等が含まれる。サーバ側のユーザ状態は、サーバの任意選択であるが、サポートされることが好ましい。サーバは好み、推薦、及び「ニュースメーカー」、「エキスパート」、「推薦」、「お気に入り」、「権威的」等のコンテキストテンプレートの機能に必要となるので、（サーバ側エージェントなしでも）ユーザのログオン及び「人」のオブジェクトタイプをサポートすることが好ましい。
バーチャルインフォメーション オブジェクトタイプ（Ｖｉｒｔｕａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｏｂｊｅｃｔ Ｔｙｐｅ(登録商標)） 個別のオブジェクトタイプへのマッピングは行われないが、ユーザに意味論的な興味のあるオブジェクトのタイプの商標名。
バーチャルパラメータ（Ｖｉｒｔｕａｌ Ｐａｒａｍｅｔｅｒ(登録商標)） 意味論的な照会プロセッサにより、ランタイムに動的に解釈される変数、パラメータ、引数、又は名前の商標名。これにより、エージェンシー管理者は仮想名を参照するエージェントを格納させたり、照会呼び出し時にこの名前を実際の関連用語に変換させたりできるようにする。
信用の輪（Ｗｅｂ ｏｆ Ｔｒｕｓｔ） 意味論的ウェブ研究コミュニティの会員が造語した用語で、意味論的ウェブのユーザがアサーションと命令文を検証するのに使うことができる一連の許可を指す。数学と暗号手法の研究に基づいて、デジタル署名は、ある人が文書、又は命令文を作成した（又は同意する）ことの証明を提供する。ユーザは、自分の全てのＲＤＦ文をデジタル処理して署名することが好ましい。これによりユーザは、自分が作成したことを確実にすることができる（又は少なくともその信ぴょう性を保証することができる）。ユーザはプログラムに誰の署名を信用するのかを指示するだけでよい。ユーザは各自の信用度を設定することができ、コンピュータは読み取るものをどの程度信用すべきか判断することができる。
信用の輪を説明する一例として、ユーザは自分の親友のロバートを信用するとコンピュータに指示する。ロバートはネット上でかなり人気のある人で、多数の人を信用している。彼が信用する人々は全員又他の一連の人々を信用する。それぞれの信用度は特定である（ロバートはウェンディを大変信用しているが、サリーを少ししか信用していない等）。信用に加えて、不信の度合も要素として組み込むことができる。誰も明示的に信用しておらず、かつ誰も完全に偽りであるとも言っていない文書をユーザのコンピュータが発見した場合、コンピュータは多くの人が偽りであると言ったものよりもその情報の方をいくらか多く信頼することになる。コンピュータは、１つの情報の信頼度を決める際に、これらの要素を全て考慮に入れる。コンピュータは、この情報全てを簡単な表示（親指を上・下に向けて示す良し／悪し）、又はもっと複雑な説明（関連した多様な信用要素の全ての説明）にまとめるのが好ましい。http://blogspace.com/rdf/SwartzHendlerを参照のこと。
Ｗｅｂ Ｓｅｒｖｉｃｅｓ−Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ（ＷＳ−Ｉ） プラットフォーム、オペレーティングシステム、及びプログラミング言語にわたるウェブサービスの相互運用性の向上を推進するために設立されたオープンな業界団体。当団体は、ウェブサービスソリューション開発の指針、最優良事例（ベストプラクティス）、及び資源を提供することでユーザのニーズに答えるために業界及び標準化機構と横断的な取り組みを行っている。http://www.ws-i.orgを参照のこと。
ウェブサービスセキュリティ（ＷＳ−Ｓｅｃｕｒｉｔｙ） メッセージの完全性、メッセージの機密性、及び単一のメッセージ認証を通して、良質な保護を提供するＳＯＡＰメッセージングの拡張機能。これらの機構は、多種多様なセキュリティモデル、及び暗号化技術に合わせて使うことができる。ＷＳ−Ｓｅｃｕｒｉｔｙは、セキュリティトークンをメッセージに関連付けるための汎用機構も提供する。ＷＳ−Ｓｅｃｕｒｉｔｙでは、特別タイプのセキュリティトークンは必要としない。（複数のセキュリティトークン形式をサポートする等）拡張性を持たせてある。例えば、クライアントは出所の証明、及び特定のビジネス認証を持つ証明を提供するかもしれない。更にＷＳ−Ｓｅｃｕｒｉｔｙは、バイナリセキュリティトークンを符号化する方法を記述する。具体的には、仕様はＸ．５０９証明書とケルベロス（Kerberos）チケットを符号化する方法、及び不透明な暗号キーの含め方を記述する。メッセージに含まれる資格証明書の特徴を更に記述するのに使用できる拡張性機構も含まれる。http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.aspを参照のこと。
拡張可能なマークアップ言語（ＸＭＬ：Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ） ウェブ上の構造化された文書とデータの汎用形式。構造化データには表計算、アドレス帳、構成パラメータ、金融取引、及び製図等を含む。ＸＭＬは、データを構築できるテキストの書式を設計するための一組の規則（指針又は約束事と考えてもよい）である。ＸＭＬはプログラミング言語ではなく、使用したり学習するのにプログラマーである必要はない。ＸＭＬはコンピュータがデータの生成、データの読み取り、及びデータ構造の明確さを確保することを容易にする。ＸＭＬは言語設計で起こりがちな落とし穴を避ける。つまり、拡張性を持ち、プラットフォームに依存せず、国際化と地域化をサポートする。ＸＭＬは完全にユニコード準拠している。http://www.w3.org/XML/1999/XML-in-10-pointsを参照のこと。
ＸＭＬウェブサービス（ＸＭＬ Ｗｅｂ Ｓｅｒｖｉｃｅ）（又は「ウェブサービス（Ｗｅｂ Ｓｅｒｖｉｃｅ）」でも知られる） 動的な文脈主導の情報をユーザに表示する際に関わる、異なるソフトウェアアプリケーション間に標準通信方法を提供するサービスである。詳細の定義には以下を含む。
1. ＵＲＩによって識別されたソフトウェアアプリケーションで、インターフェースとバインディングはＸＭＬの成果物によって定義、記述、及び発見されることができる。インターネットベースのプロトコル経由で、ＸＭＬベースのメッセージを使って他のソフトウェアアプリケーションとの直接的な対話をサポートする。
2. インターフェース規格を使う他のウェブサービスとの統合が可能なサービスとして配信されたアプリケーション。使用希望のクライアントに、情報をプログラムにより返すＵＲＬのアドレス指定が可能なリソース。主に使われている通信プロトコルは、シンプルオブジェクト アクセスプロトコル（ＳＯＡＰ）で、これは大半の場合はＨＴＴＰ経由のＸＭＬである。
3. 標準インターネットプロトコルを用いてアクセスができる、プログラム可能なアプリケーションロジック。ウェブサービスは構成要素に基づく開発とウェブの側面を結合する。構成要素と同様に、ウェブサービスはサービスの実装方法を心配しなくても再生可能なブラックボックス的機能に相当する。今日の構成要素技術とは違い、ウェブサービスはＤＣＯＭ、ＲＭＩ、又はＩＩＯＰ等のオブジェクトモデル固有のプロトコル経由でアクセスされず、代わりにユビキタスなウェブプロトコル（例：ＨＴＴＰ）及びデータ形式（例：ＸＭＬ）経由でアクセスされる。http://www.xmlwebservices.cc/、http://www.perfectxml.com/WebSvc1.asp、及びhttp://www.w3.org/2002/ws/arch/2/06/wd-wsa-reqs-20020605.htmlを参照のこと。
ＸＱｕｅｒｙ 物理的にＸＭＬで格納されているデータであっても、ミドルウェア経由でＸＭＬとして表示されるデータであっても、全タイプのデータを横断して知的に照会を表現するために、ＸＭＬ構造を使用する照会言語。http://www.w3.org/TR/xquery/及びhttp://www-106.ibm.com/developerworks/xml/library/x-xquery.htmlを参照のこと。
ＸＰａｔｈ ＸＳＬ Ｔｒａｎｆｏｒｍａｔｉｏｎｓ（http://www.w3.org/TR/XSLT）とＸＰｏｉｎｔｅｒ（http://www.w3.org/TR/XSLT）の間での共有機能に共通構文と意味論を提供するための努力の結果である。ＸＰａｔｈの主目的は、ＸＭＬ [ＸＭＬ] 文書の部分のアドレス指定である。この主目的を支持して、文字列、数値、及びブール値の操作の基本的な機能も提供する。ＸＰａｔｈは、ＵＲＩとＸＭＬの属性値内でＸＰａｔｈの使用を円滑にするために、コンパクトな非ＸＭＬ構文を使用する。ＸＰａｔｈは、表面的な構文よりもむしろ、ＸＭＬ文書の抽象的で論理的な構造上で動作する。ＸＰａｔｈはＵＲＬと同様に、ＸＭＬ文書の階層構造の中をナビゲートするのでパス表記法の使用からその名を得ている。
アドレス指定の利用のほかに、ＸＰａｔｈは（ノードがパターンに一致するかどうかを検証する）マッチングに使用できる自然のサブセットを持つようにも設計されている。この使用はＸＳＬＴで記述される。ＸＰａｔｈはノードツリーとしてＸＭＬ文書を手本にしている。要素ノード、属性ノード、及びテキストノードを含む異なるタイプのノードがある。ＸＰａｔｈは各タイプのノードの文字列値 (string-value) を計算する方法を定義する。ノードのタイプによって名前を持つものがある。ＸＰａｔｈはＸＭＬ名前空間を完全にサポートする（http://www.w3.org/TR/xpath#XMLNAMES）。従ってノードの名前は、ローカル部分と可能性として空白の名前空間ＵＲＩから成るペアとして設計される。これはhttp://www.w3.org/TR/xpath#dt-expanded-nameと呼ばれる。http://www.w3.org/TR/xpath#XPTRを参照のこと。
ＸＳＬ フォーマッティングの指定用にＸＭＬボキャブラリを含むＸＭＬ用のスタイルシート言語。http://www.w3.org/TR/xslt11/を参照のこと。
ＸＳＬＴ 文書が、フォーマッティングのボキャブラリを使う別のＸＭＬ文書にどのように変換されるかを記述するためにＸＳＬによって使われる。http://www.w3.org/TR/xslt11/を参照のこと。
B. 概要
1. 発明の前後関係
情報アクセスへの究極の目的は、自然言語での検索能力の提供であるとの誤解がある。以前の情報アクセス技術は、情報取得の最適化のために情報の検索、又はアクセスインターフェースの改善に主として焦点が当てられてきた。情報に対する自然言語のインターフェースを提供すれば、ユーザの情報へのアクセス問題を解決し、情報を探し出す際のフラストレーションが無くなるであろうということが一般的な憶測であった。
しかし実際には、多くの分析軸は人が実社会でどのようにして知識を取得しているかに関わっている。一例が文脈である。人がある場所にある時にいたから知っていることがたくさんある。その場所にその時に居合わせなかったら、実際に知られている事を知らなかったり、又は実際に知りたいと思わないかもしれない。現在知られている事を自然言語で検索する能力を持つことは、ある場所とある時に関連する知識を発見する助けにはならない。所望の情報を取得するために、的確な照会を作成する自然のパラメータは簡単には存在しない。
難問は、価値があるかどうか知ることさえないことに対しては、事後まで質問することができない。言い換えれば、知らないことが分かっていないことを、又は知りたいかもしれないことが分かっていないことを照会することはできない。文脈依存性、時間への敏感さ、発見、動的リンク、ユーザ制御のブラウジング、ユーザの「セマンティックエンバイロメント」、柔軟性のあるビュー、文脈スキン、文脈の属性、（コンテキストテンプレートに基づいて適切な、文脈に依存し時間に敏感な情報を提示する）文脈パレット、及び本発明の他の側面は、既存情報システムの根本的な欠陥を認識し是正する。
例えば、ある人はいくらかのパーティに出かけて、いくらかの人と話をすることで自分のライブラリーに多数のＣＤを持っているかもしれない（それにより音楽の「知識」に追加することになる）。パーティに居合わせた人々がその人にＣＤのことを話したので、その人の音楽の知識が増加したのである。別な例としては、ある人が飛行機でたまたま隣に座ることなった他人からの推薦を基にして、ある本を購入するかも知れない（もし読むと、その人は本の特有のトピックに関しての知識を高めることになる）。実社会において、人々は読んだり探したりすることだけではなく、自分が付き合っている友達、やり取りがある人や信頼する判断を持つ人に基づいて知識を得る。「知識の環境」は知識の流布と取得のためにもしかすると（デジタルであれアナログであれ）取得のモデルと同じ、又はもっと重大であるかもしれない。
本発明は事実上、現実世界の知識取得のシナリオをデジタル世界に映し出している。結果としてのインフォメーションナーバス システムは、その作業の大半を行うメディアであるが、シナリオは非常に見事にアナログ（現実）の世界にはっきりと対応している。現在のウェブ、及び意味論的ウェブの自然言語検索手法等の努力は、知識の流布と取得の多くの方法を認識できないので詰まるところ無能である。本発明は、情報伝達に使われた実際の技術には関係なく、人間が常に知識を取得してきた多様な方法を明らかにするものである。
一例として常に文脈があり時間があった。同様に常に伝達の概念と、情報を動的にユーザの制御でリンクする必要性があった。ここで示した「権威的」、「履歴」、「時系列」、「今後のイベント」、「見出し」等の異なるメディアにもかかわらず、ある程度のコンテキストテンプレートは常に存在していた。これらのテンプレートはインターネット、現在のウェブ、電子メール、ｅラーニング（電子学習）等が作られた以前に存在していた。それにもかかわらず本発明以前には、電子メディアは、実際の情報のタイプ、意味論的なリンク、メタデータ等ではなく（例えばコンテキストテンプレート、文脈依存性、時間への敏感さ、動的リンク、柔軟性のある提示、文脈スキン、文脈の属性等の）現実世界のシナリオをはっきりと描く知識伝達のモード、プロトコル、及び提示に焦点を置く能力はなかった。常に新しい情報のタイプが出てくることになる。しかし（コンテキストテンプレートのような）知識の流布、及び取得の軸は過去も将来も常に同じである。本発明はこの事実を捉えている。
更に本発明は、求めずして思わぬ発見をする能力 (serendipity) でもって知識を流布する能力を提供する。求めずして思わぬ発見をする能力は、実社会での知識の取得に大きな役割をもっており、知識伝達の最上な形態である。本発明は文脈、時間、コンテキストテンプレート等をサポートすることによって、ユーザが情報を（知的であるものの）思いがけなく取得できるようにするものである。
「ウェブ」のように精密で静的な構造を採用する情報モデル、又はメディアは、作成された「ネットワーク」又は「ウェブ」が存在すると決め込んで、知識が形成するさまざまな軸を明らかにしないので崩壊してしまう。そのような情報モデルは、ユーザに焦点を当てておらず、文脈、時間、ダイナミズム及びテンプレートを組み込んでおらず、現実世界の知識の取得と流布のシナリオに対応していない。本発明は、本質的な「ウェブ」の存在なしでも、及び情報を見つけ出すのに自然言語が使われなくても、情報の損失を最小限に抑え、情報の保持を最大限にする。これは、既存情報アクセス用メディアとは違い、本発明の好ましい実施の形態は（エンドユーザとコンテンツ作成者の双方のために）文脈、時間、ダイナミズム、及びテンプレートを組み込む知識の流布モデルに焦点を置き、アクセスインターフェース、又は静的データのモデル、あるいは人間ベースのオーサリングに基づいた情報リソースの（意味論的又は非意味論的な）リンクに焦点を置いていないので可能である。多くのシナリオにおいて、（意味論的又は非意味論的な）「ウェブ」はナビゲーションの手段として必要であるが、知識の流布と取得の手段としては決して十分ではない。本発明のインフォメーションナーバス システムは、本発明で説明する（リンクに基づいたナビゲーションを含むがこれに限定するものではない）「知識の軸」を取り入れており、知識の流布と取得を円滑にして、知識の転送に関わる全当事者の役に立つようにこれらの軸を知的にシームレスに組み込む。
2. 価値命題
現在知識は企業、消費者、又は一般の詮索好きな大衆向けであろうと、情報構造のデジタル構造に「手作業でハードコード化」される必要がある。知識は適切に作成され配信されなければ、誰もその存在を知らず、他の情報源に関連づけする方法やリアルタイムに適切なやり方で取り扱う方法を誰も知らない。これは主として現在のウェブが、知識のプラットフォームになるように考案されていないからである。提示のプラットフォームとして作られており、意図的にダム（無能）で静的で事後対応型である。今日、文脈と意味を追加することで情報を利用しようとする知識労働者は、知識作成者のなすがままになっている。
知識の相互作用の重要な側面は、知識労働者が非常に直感的な方法で知識空間をナビゲートして、希望する速度で判断を出し、知識に基づいて行動することを可能にすることである。言い換えれば、知識労働者は電子学習の孤立集団を、自分の組織内の文書、顧客のフィードバックが入っている電子メール、メディアファイル、予定されているテレビ会議、最近行われた会議、ニュースグループに格納された情報、又は関連書籍から分離したものとして「考える」必要がないということである。好ましい状況は、情報の「タイプ」と「ソース（源）」に帰属させて、全ての孤立集団を意味論的なやり方で横断する「シームレスな知識の経験」を作り出すことである。
更に知識の経験を作り出す際には、内容（コンテンツ）提供者、パートナー、供給者、顧客、及び人の境界を横断して知識の資産を統合できることが好ましい。例えば企業のシナリオにおいて、競争力維持のために必要な知識を全て持っている企業はいない。知識は、業界レポート、コンサルタント会社、及び投資銀行、ロイター及びブルームバーグのようなマスコミ会社からの調査文書等に格納されている。これら全てが「知識」を構成する。一回限り、又は定期的にユーザを訓練するために電子学習のレポジトリを配備するだけでは十分ではない。ユーザは様々な情報源から、適所で、現在の作業に関連する知的な文脈で知識への常時接続のアクセスを持つべきである。
これら全てに必要なのは、現在利用可能でないインテリジェンスを持つ層と事前対応性である。例えば現在企業は、イントラネットとインターネットのような情報ポータルを従業員に情報を流布する方法として使う。しかしながら、これは表示レベルでの統合化しか提供しないので決して十分ではない。これは、情報の管理を代行し、オンザフライで新しい情報を見つけ出して同僚と情報を獲得し共有する手助けをしてくれるエージェントを持っているのとは対照的に、新しい情報を得るために社内報を購読するのと似ている。
所望するレベルの知識の相互作用を達成するために、エージェントは、知識経験のシームレスな部分となるために、背景で作業をし、推論し、学習し、推測し、プロファイルに基づいてユーザを一致させ、新しい知識を獲得し、自動的に新しい知識を推定し、外部情報源からの知識を統合することが要求される。これは言い換えると、単に表示レベルの統合化と文書検索の基盤を提供するよりもむしろ、全体的に意味が通るように知識の資産の意味論的な統合化が必要になる。実装の枠組みとその結果としてのメディアは、文脈に依存し時間に敏感な情報が「尊重」されて、知識労働者がより生産性を高め、より多くのことをより早くより少しで行えるように、リアルタイムで機敏な発見と推薦サービスを提供しなければならない。そして最後に、システムはプラグアンドプレイのやり方で既存情報源と連携されなければならず、周知の知識資産をシームレスでかつ自動的に分類し統合しなければならず、知識自体に知識のツールを埋め込まなければならず、その結果、知識の資産に別な「次元」を加えることになる。
本発明は、現在のウェブ（又はその他の表示の層）と共存する知的で事前対応型でリアルタイムの知識プラットフォームとなるように作られている。本発明を取り入れ使用することで、（「結び付き」を経由した）オーサリングが知的で、動的で、自動的で、及び思考の速度で行われるので、知識労働者は自己の知識の経験を管理することができる。
3. 現在の「情報」ウェブと本発明のインフォメーションナーバス システムとの比較
現在のウェブ環境では、提示された情報の意味論は構造化データがサーバでＨＴＭＬに会話すると同時に失われる。つまりユーザが対話する機会を持つ前に「知識」はオブジェクトから剥ぎ取られてしまう。更に現在のウェブは、情報がどのようにナビゲートされ利用されるか、作成者が「信じる」方法に基づいてサーバ上に「ハードコード化」され作成される。ユーザは自分に提示された情報のみを利用する。
本発明は、今日のＨＴＭＬベースのウェブ環境がサポートできない１つのインテリジェンスを持つ層と複数のカスタマイズの層を追加する。本発明は、オブジェクトの意味論がサーバとクライアント間に保持されるダムなウェブページではなく、スマートな知識オブジェクトから構成されるＸＭＬベースの動的なウェブを提供するので、ユーザにより強力で制御力を持った知識の経験を持たせることができる。更に、本発明のウェブでは、知識労働者は、「動的リンク」と「ユーザ制御のブラウジング」を経由して、自己の知識の経験を対話形式で作成するので、情報を自分の言うとおりの条件で利用し行動することが可能である。
本発明のインフォメーションエージェント（意味論的ブラウザ）は、現在のウェブと共存して、インターネットだけでなく個人又は公共の全てのイントラネットのファセットと統合し拡大するように設計されている。現在のウェブと本発明のインフォメーションナーバス システムの技術プラットフォームのスタックは図６に要約されている。図６を参照すると、現在のウェブのスタックは最下位層にデータベースに格納されたデータとしての情報を含んだ構造化の情報源と、文書、電子メールメッセージ等の情報を含んだ非構造化の情報源を持つ。両層の情報は区別して処理される。情報索引付け層では意味論は使用されず、むしろキーワードに基づいた検索エンジンが使われる。論理層は検索、規則、ビュー、トリガ等のプログラム化が可能になるデータベースから主に構成されている。アプリケーション層はユーザ入力に基づく電子商取引のアプリケーションを駆動するサーバ側スクリプトから成る。最上位のプレゼンテーション層にある現在のウェブは、（ブラウザ等の）ウェブプラットフォームでポータルを経由して公開される（ウェブページの形態の）提示情報を持つ。
処理の層が重複することのほかに、本発明は基本となる情報源の意味論を保持するやり方で、最下位の演算から情報を一意的に扱う。構造化及び非構造化の情報源層の両方において、システム１０は情報を均一に処理し、情報に関連付けられたメタデータと意味論を組み込む。情報索引付け層において、情報のメタデータと意味論は非構造化から抽出される。システム１０は現在のウェブでは存在しない３つの付加的なプラットフォーム層を加える。つまり構造化及び非構造化の両方の情報源からの情報が意味論に符号化される、知識索引付け及びカテゴリ層、知識オブジェクトの意味ネットワークの自己回復、つまり自己修正のメンテナンスを可能にする関連付けが作成される知識表現層、及び新しい結び付きと特性が意味ネットワークで推測される知識オントロジ及びインファレンス層である。論理層において、意味論的なレベルでプログラム化を可能にする知識ベースが作成される。アプリケーション層において、サーバ側スクリプトはその知識ベースと関連して使われる。これらのスクリプトは、ユーザの入力に基づいて知識オブジェクトを動的に生成し、取得、通知、及び論理用の意味論的コマンドを含むこともできる。
この層には意味論的なユーザの入力の処理を最大化するためにスマートエージェントを含むこともできる。システム１０のプレゼンテーション層は、最下位層から追跡された意味論を保持する。この層の表示は、クライアントのコンピュータシステム上で動的に生成され完全にカスタマイズ可能である。全ての技術階層での意味論のメンテナンス、統合、及び使用により、本発明は物理的に、又は仮想的に、人間が対話する「事項」に直接対応する行動可能な「オブジェクト」の仮想ウェブ、もっと聞きなれた言葉に言い換えれば「コンテキストテンプレート」を作成する。文書のダムウェブである現在のウェブとは対照的に、本発明は特性と関係を持っている行動可能なオブジェクトのスマート仮想ウェブを提供する。そこではイベントはその仮想ウェブの他の部分に動的な変化を起こさせることができる。
本発明はプログラム可能なウェブを提供する。文書のダムウェブである現在のウェブとは異なり、本発明のウェブはデータベースに類似しておりプログラム可能である。つまり論理と規則の処理が可能で、イベントを開始できる。
現在のウェブは人間用に符号化されているので、静的な情報の提示に主な焦点が当てられているが、本発明の仮想ウェブは知識伝達の鎖の最終点として最終的に人間に提示されるのだが、主としてマシン用に符号化されている。本発明は知的で学習するウェブを提供する。これは本発明の仮想ウェブが新しい結び付きを学び、時間と共によりスマートになることを意味する。ウェブは動的、仮想、及び自動オーサリングであるので、現在のウェブが提供できない意味論的な結び付きを知的に事前対応的に行うことにより、知識労働者により大きな力を提供するものである。従って情報の損失の削減につながり、結果的には情報損失を無くすことにつながる。
本発明のウェブは自己修復するウェブである。文書作成者が手作業で管理をしなくてはならない現在のウェブとは異なり、本発明はマシンが自己管理するウェブを提供する。この特徴は、ウェブがネットワーク内の切断を自動的に修復するので壊れたリンクを修正する。
最後に、以下で詳細を説明するように、本発明の多種の実施の形態は、現在のウェブ、又は概念上の意味論的ウェブに関する既存システムに比べてはるかな優位性を提供するために、上記で述べた知識取得の軸の一部又は全部を組み込んでいる。
C. システムのアーキテクチャと技術の考慮事項
1. システムの概要
本発明は知識の取得、管理、及び伝達のシステム及び方法に関する。ここでは本システム及び方法は商標名のインフォメーションナーバス システムで呼ばれる。図７を参照に、システム１０の最上位にインターネット又はイントラネット等の通信メディア４０を経由して、（ブラウザ等の）提示プラットフォームを操作するクライアント３０へ、文脈に依存し時間に敏感な意味論的な情報取得サービスを提供するために、連携するいくつかの構成要素から成るサーバ２０を含む。サーバの構成要素は、ナレッジインテグレーション サーバ（ＫＩＳ）５０、及びナレッジベース サーバ（ＫＢＳ）８０を含むのが好ましく、これらは物理的に統合又は分離されていてもよい。システム内で、指定階層にある全てのオブジェクト、又はイベントは、意味論的に互いに関連し、（基本のアクションコードから成る）照会を表現するアクティブなエージェント９０で、所定のカスタマイズ可能なテーマ、又は「スキン」に従ってクライアントに提示するためのデータオブジェクトを返す。本システムは、多種多様なアプリケーション、及びクライアントがエージェントとカスタマイズし「混合する」ための多種の手段、及びその結果生じる情報の提示を最適化するために、基本の関連した照会のための多種の手段を意図する。本発明のシステム１０のそれぞれの好ましい構成要素について、及び構成要素間の相互作用は以下で詳細に説明する。
2. システムのアーキテクチャ
本発明のインフォメーションナーバス システムのエンドツーエンドシステムのアーキテクチャを図８を参照にして示す。図８は本発明がインフォメーションナーバス システムのＸＭＬウェブサービス（ＫＩＳ）とスマートエージェントとの間の、複数クライアントの通信アクセス手段を提供する。好ましい実施の形態において、これはインフォメーションエージェントを経由して行われる。他の実施の形態においては、通信は（現在のウェブのアクセスブラウザ等の）エンタープライズナレッジ ポータル、又はカスタムクライアントでプログラムによる統合を実現するＳＤＫ層を経由してプログラムで行うことができる。
インフォメーションナーバス システムのＫＩＳ用システムのアーキテクチャはその構成要素を含めて図９を参照にして示す。これらの構成要素は以下で詳細に説明する。
3. テクノロジスタック
図１０を参照にして示すように、現在のウェブと概念上の意味論的ウェブとの間の重大な違いは、各テクノロジスタックを参照することによってより明確になる。図１０は、現在のウェブの上位記述プラットフォーム層と、本発明のインフォメーションナーバス システムの（該当する際の）同等物との間の比較である。図１０は、ある事例において、現在のウェブのシナリオがインフォメーションナーバス システムのシナリオにどう割り当てるかを示したもので、ユーザに論理的な移行パスを提供し、現在のウェブに存在しないインフォメーションナーバス システムの側面も明らかにする。
4. システムの異種混合性
異種混合性は本発明の利点である。好ましい実施の形態において、ＫＩＳエージェンシーのＸＭＬウェブサービスは移植可能である。これは（相互運用性のためにＷＳ−Ｉ標準を採用する等で）相互運用可能なＸＭＬ，ＸＭＬウェブサービスのようなオープンスタンダード、（ＳＱＬ及びＯＤＢＣ／ＪＤＢＣ等の）データ格納とアクセスの標準、及び（ＬＤＡＰ、ＳＭＴＰ、ＨＴＴＰ等の）ＤＳＡによりデータが収集される情報レポジトリ用の標準プロトコルをサポートすることを意味する。
例えば、好ましい実施の形態において（エージェンシーが実行中の）ＫＩＳは以下を行うことができる。
・ （ＬＤＡＰ ＤＳＡを使用して）ＬＤＡＰストアから「人」のメタデータを収集する。これは、マイクロソフトウィンドウズ（登録商標）２０００のアクティブディレクトリ、サンのディレクトリサーバ、及びＬＤＡＰをサポートする他のディレクトリのサポートを可能にする。これは「人」のメタデータを収集するために、プラットフォーム固有のＡＰＩを使う、プラットフォーム固有のアクティブディレクトリＤＳＡを持つよりも好ましい。
・ （任意のソースからの電子メール、又はシステムの受信トレイ用の）ＳＭＴＰストアから電子メールのメタデータを収集する。これはマイクロソフトのエクスチェンジ、ロータスノーツ、及び他の（ＳＭＴＰをサポートする）電子メールサーバのサポートを可能にする。これは、プラットフォーム固有のマイクロソフトエクスチェンジの電子メールＤＳＡ、又はロータスノーツの電子メールＤＳＡを持つよりも好ましい。
・ アイカレンダーのオープンスタンダードをサポートするカレンダーストアからの「イベント」メタデータを集めてカレンダーアクセスプロトコル（ＣＡＰ）等のプロトコルを使う。これは、アイカレンダー、又はＣＡＬプロトコル標準をサポートする任意のイベントレポジトリのサポートを可能にする。これは、プラットフォーム固有のマイクロソフトのエクスチェンジカレンダー（又はイベント）ＤＳＡ、ロータスノーツカレンダーＤＳＡ等を持つよりも好ましい。
他の実施の形態においては、ＫＩＳエージェンシーは（適切なＤＳＡを経由した）専有のレポジトリに格納されたメタデータを抽出するために設定することもできる。
異種混合性を実現するために、好ましい実施の形態ではクライアントサーバの通信用にシステム１０は（プラットフォームにわたって）相互運用可能なやり方で動作するＸＭＬウェブサービス規格を使用する。これには、ＳＯＡＰ、ＸＭＬ、ウェブサービスセキュリティ（ＷＳ−Ｓｅｃｕｒｉｔｙ）、ウェブサービスキャッシング（ＷＳ−Ｃａｃｈｉｎｇ）等用の該当するオープンで相互運用可能な規格が含まれる。
本発明の好ましい実施の形態において、意味論的ブラウザ（又商標名のインフォメーションエージェント（Ｉｎｆｏｒｍａｔｉｏｎ Ａｇｅｎｔ(登録商標)）とも呼ばれる）は、クロスプラットフォームでウィンドウズ、ドットネット、Ｊ２ＥＥ、ユニックス等の異なる環境における動作が可能である。この能力は、ユーザがどの「プラットフォーム」でブラウザが実行されているか、又はどのプラットフォームでエージェンシー（サーバ）が実行しているかを気にする必要がないので、意味論的なユーザ経験の概念と一致する。本発明の意味論的ブラウザは、ユーザがウィンドウズ（又はドットネット）サーバと「話している」のであれ、Ｊ２ＥＥサーバと「話している」のであれ関係なく一貫した経験を提供する。ユーザは、実行中に対話対象の任意のエージェンシーのプラットフォームに基づいて、クライアントをインストール、又は使用している間に余分な手順を行う必要がない。
インフォメーションエージェントは、スキン、及び他の提示効果用にオープンスタンダードを使うことが好ましい。これにはＸＳＬＴ、ＳＶＧ、及び（フラッシュ ＭＸ/アクションスクリプトの該当するバージョン等の）プラットフォームにわたって動作する専有の提示形式が含まれる。
本発明のインフォメーションナーバス システムの好ましい実施の形態の異種混合エンドツーエンドの実装例を図１１で参照に示す。図１１は、インフォメーションナーバス システムの好ましい実施の形態で、本発明の異種混合でクロスプラットフォームの文脈を示す。図１１に示す構成要素は以下で詳細に説明する。
5. セキュリティ
インフォメーションナーバス システムの好ましい実施の形態は、セキュリティの全側面のサポートを提供する。つまり、認証、許可、監査、データ機密性、データ完全性、有用性、及び否認防止である。これはＸＭＬウェブサービスのアプリケーションでプラットフォームにセキュリティを提供するＷＳ−Ｓｅｃｕｒｉｔｙ等の規格を用いることで実現する。セキュリティは、ＸＭＬウェブサービスのプロトコルスタックのセキュリティ規格を経由したプロトコル層で取り扱われるのが好ましい。これには、クライアント（意味論的ブラウザ）からサーバ（エージェンシー）まで暗号化するメソッド呼び出し、デジタル署名のサポート、エージェンシーの意味ネットワークへのアクセスを許可する前に呼び出し側ユーザの認証、及びＸＭＬウェブサービスのメソッド等を含む。
本発明の好ましい実施の形態は、ローカルの（クライアント側）資格証明書管理をサポートする。これは、ユーザに（イントラネット内の）複数エージェンシー、又はインターネット上で使うユーザ名とパスワードのリストを入力するように要求することで実行されることが好ましい。意味論的ブラウザは、ユーザ用に異なる認証の資格証明書を持つであろう複数のエージェンシーから情報を集約する。サポートされる認証の資格証明書は、ユーザ名とパスワードを使った基本的な認証、ＳＳＬ，マイクロソフトのドットネットパスポートの認証サービス上での基本的な認証、新しいリバティアライアンスの認証サービス、ＳＳＬ上でのクライアント証明書、ダイジェスト認証、及び（ウィンドウズ環境使用の）統合されたウィンドウズ認証等の一般的な体系を含むこともできる。
好ましい実施の形態において、クライアントでキャッシュされたユーザの資格証明書で、意味論的ブラウザは、（エージェンシーのスキーマの一部である）エージェンシー用にサポートされた認証のレベルと体系を調べることにより指定のエージェンシーの適切な証明を用いる。例えば、エージェンシーが統合されたウィンドウズ認証をサポートするのであれば、意味論的ブラウザは現在のユーザ用ログオンのハンドル又は他の識別子を使ってＸＭＬウェブサービスのメソッドを呼び出す。エージェンシーがＳＳＬ上の基本認証のみをサポートするのであれば、意味論的ブラウザはログオンするために、ユーザ名とパスワード、又は（クライアントが以前ログオンしておりログオンのハンドルがまだ期限切れしていないのであれば）ログオンのハンドルをキャッシュしたコピーのどちらかを渡す。好ましい実施の形態は、認証プロセス（及びログオンのハンドル検索）を迅速化するために、及びログオンのハンドルが乗っ取られないように対処をすることで更なるセキュリティを提供するために、ログオンのハンドルキャッシング、及びＫＩＳ上の時効と期限切れの技術を採用する。
エージェンシーのＸＭＬウェブサービスは、（特徴がサーバのオペレーティングシステム、又はアプリケーションサーバによってネイティブにサポートされるのであれば）暗黙的に、又はＸＭＬウェブサービスの実装自体によりアプリケーションのレベルで異なる認証体系をサポートするのが好ましい。ＫＩＳエージェンシーのＸＭＬウェブサービスの他の実施の形態は、基本認証、ＳＳＬ上の基本、ダイジェスト、統合されたウィンドウズ認証、ＳＳＬ上でのクライアント証明書、及び統合されたドットネットパスポート認証等の多種の認証体系を用いることが好ましい。
6. 効率性の考慮事項
クライアント側とサーバ側の照会及びオブジェクトキャッシュ−本発明は、迅速なアクセスのため照会キャッシングを行う照会のキャッシュを提供する。クライアント上でクライアント側の照会のキャッシュは、指定の引数でＳＱＭＬ照会結果をキャッシュに格納する。キャッシュは、所定の時間（例：数分）後にそのコンテンツを消去するように設定されるのが好ましい。時間は、システムの使用の模型化とキャッシュ制限時間用の最適値に到達することによって設定するのが好ましい。（別の実装選択であるエージェンシーごとのキャッシュの場合は）エージェンシー上のデータの到着率、ユーザの（ナビゲーション率等の）利用モデル等の他のパラメータを考慮に入れることもできる。
キャッシングは、ユーザが意味論的な環境をナビゲートするごとにクライアントが最近使われたサーバを不必要にアクセスする必要がないので処理能力の向上につながる。好ましい実施の形態において、クライアントは（ＷＳ−Ｃａｃｈｉｎｇ等）の標準ＸＭＬウェブサービスのキャッシング技術を用いる。更にクライアント上にオブジェクトキャッシュがあるのが好ましい。このキャッシュは各ＳＱＭＬリソースの結果をキャッシュに格納し、（ファイルパス、ＵＲＬ等の）リソース参照でタグ付けされる。これは、クライアントがリソース自体へのアクセスをすることなく、オブジェクトのキャッシュからＳＱＭＬリソース用のＸＭＬ形式メタデータを直接得ることができるのでＳＱＭＬの処理を最適化する。リソースはローカルのファイルシステム、（マイクロソフトアウトルック等の）ローカルアプリケーション、又はエージェンシーのＸＭＬウェブサービスであってもよい。照会キャッシュと同様に、オブジェクトのキャッシュはある一定の時間（例：数分）後にそのコンテンツを消去するように設定することができる。
サーバ上の他の実施の形態においては、サーバ側の照会はＸＭＬ引数用のカテゴリ結果をキャッシュに格納する。これは、サーバが各照会要求ごとに（ＫＩＳがドメインの知識を取得してくるように設定されているＫＢＳの１つ以上の実現値を経由して）、ＸＭＬ引数をカテゴリ化するためにＫＤＭに照会する必要がないので照会の応答時間を迅速化する。更に、サーバはクライアントから受信するＳＱＭＬ引数のＳＱＬ同等物をキャッシュに格納することができる。これは、サーバがクライアントから要求を受信するごとにＳＱＭＬ引数をＳＱＬに変換する必要がないので照会の応答時間を迅速化する。好ましい実施の形態において、積極的なクライアント側のキャッシングが用いられ、サーバ側のキャッシングは処理能力が明らかに向上する場合を除いては回避される。これは、クライアントのキャッシュ格納が局所的文脈に基づいて要求するので、クライアント側のキャッシングがサーバ側のキャッシリングよりも規模の変更が優れているからである。
仮想の分散照会−本発明は仮想の分散照会を採用する。これは「動的リンク」と「ユーザ制御のブラウジング」の機能と一致する。システムは、システム用の全メタデータをリンクする（又は収容する個々の大規模なデータベース）静的なネットワークを必要としない。これは、ローカル、又は世界的な範囲で手動によるオーサリングとメンテナンスの必要性を排除する。更に、これは統合された（又は全世界の）格納の必要性を排除するので、全てのメタデータが単一のメタデータストアに格納され、（ＳＱＬ等の）１つのデータベース照会インターフェースを通してアクセス可能となる必要がない。むしろ、本発明はクライアント上で照会結果を整合性があり、利用者が簡単に使える方法で集約するために、（文脈に依存し時間に敏感な方法で）多種多様なエージェンシーにわたって照会を動的に分散させるＸＭＬウェブサービスの使用による「動的アクセス」の原則を採用する。
D. システムの構成要素と操作
1. エージェンシーとエージェント
本発明は知識を取得、管理、及び伝達するためにエージェンシーとエージェントと使う独特のアプローチを導入する。
a. エージェンシー
本発明の好ましい実施の形態においては、エージェンシーはナレッジインテグレーション サーバ（ＫＩＳ）５０の実現値であり、ウェブサイトに相当する。エージェンシーは、ＸＭＬウェブサービスを公開するために（ウェブサーバ上の）ウェブアプリケーションとしてインストールされるのが好ましい。エージェンシーはエージェンシー管理者を含むのが好ましい。本発明の好ましい実施の形態において、エージェンシーは以下の主要構成要素を持っている。
・ エージェンシーが認証をサポートする、又は要求する（又はその両方の）ことを示すフラグ−エージェンシーが認証を要求すると、エージェンシーは基本的ユーザ情報とパスワードを求め、サポートする認証のタイプに情報を格納する。ユーザ情報を格納するエージェンシーのために、エージェンシーは（ある特定エージェンシー上のエージェント登録用に）ユーザ登録情報も要求する。
・ 意味論的オブジェクトの構造化ストア−（文書、電子メールメッセージ等）それぞれのクラスのスキーマに対応する。
・ 意味論的な照会に対応するランタイムの構成要素−呼び出し側アプリケーションにＸＭＬを返し、意味論的ブラウザの情報取得の全機能用システムのサービスを提供する構成要素である。
サーバ側のユーザ状態−本発明の好ましい実施の形態において、エージェンシーはサーバ側のユーザ状態をサポートする。これは「人」のメタデータとユーザ認証を含む関連概念とを関連付ける。サーバ側のユーザ状態は本発明の実装の詳細の多くを円滑にする。それには（人のオブジェクトと情報のオブジェクト間を意味論的にリンクすることによる）ユーザのお気に入りの格納、（推薦等の）新しいリンクを生成するためのお気に入りの推測、（ユーザの意見を情報のオブジェクトに割り当てる）注釈付加、ユーザを（投稿された電子メール、注釈付加等の）情報にマッピングする意味論的なリンクに基づいた「エキスパート」の推測を含む。サーバ側のユーザ状態は「エキスパート」、「お気に入り」、「推薦」、及び「ニュースメーカー」のようないくつかのコンテキストテンプレートを用いて使用されるのが好ましい。
クライアント側のユーザ状態−インフォメーションエージェント（意味論的ブラウザ）は、ローカルのクライアント側のユーザ状態のローミングをサポートすることが好ましい。これには、ユーザのセマンティックエンバイロメント及びユーザの（安全に転送された）資格証明書を含む。好ましい実施の形態において、ユーザはセマンティックエンバイロメントを別なマシン上に複製するために別のマシンにクライアント側のユーザ状態を簡単にエクスポートすることができる。これはユーザのエージェントのリスト（最近とお気に入りのリスト）、（ＳＱＭＬバッファを含む）エージェント用のメタデータ、ユーザのローカルセキュリティの資格証明書等を全部この状態をシリアライズし状態を簡単に転送できるようＸＭＬ形式へと転送することにより実現するのが好ましい。又は、ＸＭＬスキーマはローカルのクライアント側の全てのユーザ状態用に開発することもできる。又、サーバ上でユーザ状態をキャッシングし、共通の同期化の技術を使ってユーザ状態を同期することで、ローミングを円滑にすることができる。意味論的ブラウザは、（ＸＭＬファイルやウィンドウズレジストリ等の専有の格納内に）状態をローカルに格納するのではなく、クライアント側の全てのユーザ状態をサーバ上にダウンロード／アップロードすることが好ましい。
b. エージェント
エージェントは本発明の意味ネットワークへの主な入口点である。エージェントは特定の意味論的オブジェクトタイプ（文書、電子メール、人等）用にＸＭＬによる情報を返す意味論的フィルタの照会で構成されるのが好ましい。言い換えれば、エージェントはある特定のオブジェクトタイプで設定されるのが好ましい（以下で説明する）。エージェントはコンテキストテンプレートで設定することも可能である（以下で説明する）。この場合、照会はオブジェクトタイプを返すが、コンテキストテンプレートの意味論を組み込んでいる。例えば、「見出し」のコンテキストテンプレートで設定されるエージェントは時刻や関連性等で並べ替えられる。エージェントは又、通知、警告及び告知をフィルタリングするのに使われる。エージェントにはどのような名前を与えることもできるが、本発明の好ましい実施の形態において、ほとんどのエージェントの命名形式は以下の通りである。
<Agentobjecttype>.<semanticqualifier>.<semanticqualifier>
エージェントは任意に名前を付けることができるが、エージェント名の例には以下を含む。
All.All
Email.All
Documents.Technology.Wireless.80211B.All
Events.Upcoming.NextThirtyDays.All
異なる命名規則（以下を参照）に従うことができるドメインエージェント（以下を参照）も存在する。本発明の意味論的ブラウザにおいて、完全修飾ドメインエージェント名は以下の形式を持つ。
<Agentobjecttype>.<semanticdomainname>.<categoryname>
[Agency=<Agency url>, kb=<kb url>]
例えば、industries.informationtechnology の意味論的ドメイン名で knowledge-base ABC.com/kb.asp から wireless.all のカテゴリで設定されたエージェンシー上の電子メールドメインエージェント http://research.Agency.asp は以下の通りである。
Email.Industries.InformationTechnology.Wireless.All
[Agency=http://research/Agency.asp, kb="http://abccorp.com/kb.asp"
本発明の意味論的ブラウザはエージェント名のみで使う、又は”Ａｇｅｎｃｙ”及び”ｋｂ”の修飾子を含んで設定可能であることが好ましい。
エージェントタイプ−サーバ２０で作成された３つの主なエージェントタイプがある。スタンダードエージェント、コンパウンドエージェント、及びドメインエージェントである。スタンダードエージェントは、構造化された非意味論的な照会を、すなわちドメインの知識（又はオントロジ／分類法のマッピング）なしに、カプセル化する単独型のエージェントである。例えば、サーバ上に、エージェント All.PostedToday.All は CreationTime の特性に基づいた全てのオブジェクトをフィルタリングすることにより解決される単純エージェントである。スタンダードエージェントはもっと複雑になり得る。例えば、エージェント All.PostedByAnyMemberOfMyTeam.All は Objects 表と Users 表からの結合と下位照会を伴う複雑な照会に解決することができる（以下を参照）。
コンパウンドエージェントは他のエージェントを含み、エージェンシー管理者は（設定次第で）含まれたエージェントの結果の論理和 (UNION) 又は論理積 (INTERSECTION) である結果を生成する照会を作成できる。コンパウンドエージェントは他のコンパウンドエージェントをも含むことが可能である。本発明の好ましい実施の形態において、コンパウンドエージェントは同エージェンシーからのエージェントを含む。しかし、本発明は異なるエージェンシーからのエージェントの統合を予期している。一例として、コンパウンドエージェント All.Technology.Wireless.All は以下のエージェントと複合させることで作成することができる。
・ Documents.Technology.Wireless.All
・ Email.Technology.Wireless.All
・ People.Experts.Technology.Wireless.All
上記で説明した通り、ドメインエージェントは意味論的ドメインに属するエージェントである。ドメインエージェントは、他のエージェントと同様に、エージェント照会で初期化される。しかし、この照会はナレッジドメイン マネージャがデータを取り込む CATEGORIES の表を含む（以下を参照）。本発明の好ましい実施の形態は、個人的なセマンティックエンバイロメントと対応する独自のオントロジを持つＫＢＳ８０を利用するが、本発明は例えばエージェンシーが組織用に専有のオントロジで前もって初期化された組織内で、エージェンシーが１つ以上のカスタムの個人的なＫＢＳに接続することを可能にするオントロジ交換規格の統合されたサポートを意図する。
ドメインエージェントの例としては、Email.Technology.Wireless.All がある。このエージェントは以下のような知識源ＵＲＬで作成されるのが好ましい。
category://technology.wireless.all@ABC.com/marketingknowledge.asp
この知識源ＵＲＬは ABC.com/marketingknowledge.asp のウェブサービスにインストールされた知識ベース上にあるデフォルトのドメイン用の Technology.Wireless.All カテゴリに対応する。これは http://ABC.com/marketingknowledge.asp?category=“technology.wireless.all.”のＨＴＴＰのＵＲＬに解決する。この例では、完全修飾表記のカテゴリのＵＲＬは次のようになる可能性がある。
category://technology.wireless.all@abccorp.com/marketingknowledge.asp?semanticdomainname="InformationTechnology"
この場合カテゴリのＵＲＬは、ドメイン名で修飾される。
ドメインエージェントは、ドメインエージェント ウィザードを経由して作成されるのが望ましく、エージェンシー管理者は、ＫＢＳ８０から本発明の意味ネットワークにドメインエージェントを追加することができる。ドメインエージェント ウィザードによって、ユーザは（カテゴリのＵＲＬを使って）特定のカテゴリ用、又は全体の意味論的ドメイン名用のドメインエージェントを作成できる。後者の場合は、新しいカテゴリがＫＢＳ上の意味論的ドメインへ追加されるごとにエージェンシーはドメインエージェントを自動的に作成するように設定されるのが好ましい。この機能はドメインとカテゴリが引き続き動的であることを可能にし、従って時間と共にユーザのニーズに簡単に順応できる。ドメインエージェントがこのようなやり方で管理されると、もはや意味論的ドメインに存在しないエージェントを除去できるようにエージェンシーを設定できる。本質的に、このモードではドメインエージェントは、CATEGORIES の表で同期化される（そして以下で説明するように、次にナレッジドメイン マネージャによって関連あるＫＢＳにおいて、CATEGORIES のリストで同期化される）。
ドメインエージェントは、エージェントがカテゴリ名、又はＵＲＬに基づいて管理するデータをフィルタリングする構造化照会で初期化される。この場合、構造化照会はスタンダードエージェントの照会と同一である。あるカテゴリのエージェント結果として生じる照会の例は以下の通りである。
SELECT OBJECT FROM OBJECTS WHERE OBJECTID IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE PREDICATETYPEID=50 AND SUBJECTID=1000 AND OBJECTID IN (SELECT OBJECTID FROM CATEGORIES WHERE URL LIKE
category://technology.wireless.all@ABC.com/kb.asp?domain="marketing"))
この例において、「カテゴリに所属する」の述語タイプＩＤは、値５０を持つと想定し、カテゴリの objectid の値が１０００を持つと想定する。この照会は次のように翻訳することができる。
カテゴリのオブジェクトが objectid の値が１０００で、ＵＲＬが category://technology.wireless.all@abccorp.com/kb.asp?domain=“marketing”であるカテゴリに属するエージェンシーの全てのオブジェクトを選択する。"
これは又次のように言い換えられる。
カテゴリ category://technology.wireless.all@abccorp.com/kb.asp?domain=“marketing”のエージェンシー内にあるオブジェクトを全て選択する。
ドメインエージェント ウィザードでは、カテゴリ名を省略してエージェントに名前付けをするか、又は理解しやすい完全修飾カテゴリ名の表記にするかをユーザに確認する。後者の一例は Marketing.Technology.Wireless.All [@ABC] である。
完全修飾ドメイン名の規則では次のようになる。
<objecttypename>.<semanticdomainname>.<categoryname>.all [@KB Name].
この例で、ドメインエージェント名は次のようになる。
Email.Marketing.Technology.Wireless.All [@ABC].
ブレンダー−ブレンダーはユーザの個人用のスーパーエージェントである。ユーザはブレンダーを作成し、（エージェンシー全体の）エージェントをブレンダーへ/から追加及び除去ができる。これはユーザが自分の「個人的なエージェンシー」を持つのに類似している。ブレンダーは、複数のエージェンシーからのエージェントを含むのでシステムのクライアント上のみで呼び出されるのが好ましい。本発明のクライアントは、ブレンダーのエージェントからの全てのオブジェクトを集約して適切に提示する。ブレンダーはドラッグ＆ドロップやスマートレンズ（以下を参照のこと）等の他のタイプのエージェントの操作特徴を全て含んでいることが好ましい。ブレンダーは（スタンダードエージェント、サーチエージェント、スペシャルエージェント及び他のブレンダー等）の任意のタイプのエージェントを含むことができる。
本発明は、ユーザのブレンダー作成を円滑にするためのユーザインターフェースであるブレンダーウィザードを提供する。図１２〜図１４は、本発明の好ましい実施の形態によるブレンダーウィザードのユーザインターフェースの画面例を示す。図１２は、セマンティックエンバイロメントの一例のツリービューを示すインフォメーションエージェントと、ユーザが新しいブレンダーを作成し管理できる「ブレンダーの追加」ウィザードの画面例を示す。図１３は、「ブレンダーの追加」ウィザードの第二ページを示しており、ここでユーザはブレンダーの名前と記述を入力して情報オブジェクトタイプのフィルタを選択することもできる。図１４は、本発明の好ましい実施の形態による「ブレンダーの追加」ウィザードの第３ページを示す。この例において、ユーザはセマンティックエンバイロメントからブレンダーへエージェントを追加、及びブレンダーから除去する。「エージェントの追加」の選択肢が選択されると、「エージェントを開く」ダイアログが表示され、ユーザは新しいブレンダーに新しいエージェント、ブレンダー、又はエージェンシーを追加できる。
ブレイキングニュース エージェント−ブレイキングニュース エージェントは特別にタグ付けされたスマートエージェントである。エージェンシー管理者が定義する時間の重要性の選択肢の他に、ユーザはどのエージェントが参照した情報に対して警告を受けたいのかを示す選択肢がある。ブレイキングニュース エージェント上のそれに関連する最新ニュースがあれば、表示された情報によって警告が表示される。例えば、ユーザはエージェントを「今日ロイターに掲載された全ての文書」、又は「コンピュータテクノロジー関連で２４時間先にシアトルで行われる全てのイベント」をブレイキングニュース エージェントとして作成することができる。各ブレイキングニュース エージェントは個人的なので（「最新」は主観的でユーザ次第である）、この機能は個人的な方法で機能する。例えば、シアトルのユーザは、２４時間先のシアトルのイベント、（安い航空券が見つかる時間帯で）来週西海岸で行われるイベント、（大半の米国航空会社の大陸横断便の割安チケットを得るための事前通告期間である）１４日先に米国で行われるイベント、（おそらくホテルの予約に時間が必要なので）来月に欧州で行われるイベント、及び６カ月先に世界のどこかで行われるイベントに関する通知を希望するとする。
好ましい実施の形態において、本発明は新しいブレイキングニュース エージェントに照会する、又は「ブレイキングニューズ」のコンテキストテンプレートに照会することによって最新ニュースのセマンティックエンバイロメントを自動的に調べる。これは、意味論的ブラウザウィンドウに表示される全てのオブジェクトに対して行われる。ブレイキングニュース エージェントが最新ニュースがあることを示すと、インフォメーションエージェントのオブジェクトスキンはウィンドウを点滅させたり、オブジェクトに関連する警告があることを明確に示すユーザインターフェースを表示することによってそれを示す。ユーザが最新ニュースのアイコンをクリックすると、最新ニュースのペイン、又は「最新ニュース」のコンテキストテンプレート用の文脈パレットが表示され、ユーザは最新ニュースを見ることができ、（複数の最新ニュースがあれば）ブレイキングニュース エージェントを選択し、述語を選び、他の選択肢を選ぶことができる。図１５に、ブレイキングニュース エージェントのユーザインターフェースのペイン例を示す。このユーザインターフェース例は、文脈リゾルトペインのポップアップメニューを示す。エージェントがブレイキングニュース エージェントであることを除いては、スマートレンズ（エージェントオブジェクト）のポップアップの文脈リゾルトペイン（以下で説明する）の文脈ペインとよく似ている。
デフォルトエージェント−他の実施の形態においては、各エージェントはデフォルトのエージェントのリストを公開する。デフォルトエージェントは、ウェブサイト上のデフォルトのページに類似する。つまりエージェンシーの作成者がどのエージェントを常時ユーザに表示したいのかを決める。又は、クライアント上でユーザが（例えば、現在のウェブブラウザ上での「ホームページ」に相当する「ホームエージェント」に一致するのが好ましい）インフォメーションエージェント環境のルートをクリックすると、デフォルトエージェントが起動されるようにすることができる。複合デフォルトエージェントも又ユーザによって設定できる。
デフォルトスペシャル（又は文脈）エージェント−好ましい実施の形態において、クライアント又はエージェンシーは、各コンテキストテンプレートにマッピングするデフォルトスペシャル（又は文脈）エージェントをサポートする（以下で説明する）。これらのエージェントは、フィルタなしで該当するコンテキストテンプレートを使うのが好ましい。例えば、「今日」と呼ばれるデフォルトスペシャル エージェントが、今日投稿された「最近の」及び「お気に入り」のリストの中の（又はエージェンシーの設定リストに基づいた）全てのエージェンシー上の全項目を返す。別の例においては、「寄せ集め」と呼ばれるデフォルトスペシャル エージェントは、「バラエティ」のコンテキストテンプレートに一致するセマンティックエンバイロメントの全エージェンシーの無作為な組の結果を示す。
デフォルトスペシャル エージェントは、大半のユーザにとって本発明のインフォメーションナーバス システムに慣れるための手始めの役目を果たすのが好ましい。更に、デフォルトスペシャル エージェントは、ドラッグ＆ドロップ、コピー＆ペースト、スマートレンズ、ディープインフォメーション等の使用といったスマートエージェントとしての同機能を保持する。
水平型意志決定エージェント−好ましい実施の形態において、次のようなエージェントがユーザとの対話を支援するためにクライアントによって利用される。
・ スケジュールエージェント：スケジュールエージェントは特定のユーザがイベントに出席を希望するであろう可能性に基づいてイベントを知的にランク付けする。
・ 会議追跡エージェント：会議追跡エージェントは過去に起こった会議の追跡会議の時間が来たことをユーザに知的に告知する。インファレンスエンジン（以下を参照）は、追跡会議を正当化するに十分な変化が起こったかどうかを判断するために関連する意味論的活動を監視する。ユーザは（新しい文書、参加希望の新しい人等の）関連のある知識の変更を見つけ出すために、以前の会議をインフォメーションオブジェクト ピボットとして使うのが好ましい。
・ 作業追跡エージェント：作業追跡エージェントは（文書を読む、カレンダーにイベントを追加する等）ユーザが行う作業に応じてユーザに推薦を送信する。エージェントは、ユーザが一定の追跡を持っていることを確実にする。推薦はユーザのプロファイルに基づいて、及びエージェントは推薦を判断するために協調フィルタリングを使用することが好ましい。
・ 顧客追跡エージェント−顧客追跡エージェントは、顧客活動に基づいてユーザに通知を送信する。エージェントは（ユーザからの受信電子メール、ユーザサービスの役に立つかもしれない新しい文書等に基づいて）ユーザの注意が必要な時を知的に判断する。
パブリックエージェント対ローカルエージェント−エージェンシー管理者によって作成されるエージェントは「パブリックエージェント」である。ユーザによって作成され管理されるエージェントは「ローカルエージェント」である。ローカルエージェントは、エージェンシーＸＭＬウェブサービスのＵＲＬの参照を含むＳＱＭＬ経由の遠隔エージェンシーを参照することができる。又はローカルメタデータ格納でＫＩＳのローカル実現値を実行するローカルエージェンシーに参照することもできる。
保存したエージェント−ユーザのマイエージェントリスト−好ましい実施の形態において、ユーザは呼び出されたエージェントのコピー、又はローカルエージェントとしての照会結果のコピーを保存できる。例えば、ユーザは意味論的に関係照会を生成するために、自己のハードドライブ上の文書をエージェントのフォルダにドラッグ＆ドロップできる。ユーザはその結果を「Documents.Technology.Wireless.RelatedToMyDocument」と名付けたエージェントとして保存できる。これは後でユーザがそのエージェントまでナビゲートして個人化された意味論な照会を表示できる。ユーザはそれから、そのエージェントを使って個人的な新規エージェントの作成の等ができる。個人的なエージェントは、エージェンシーに「公開する」こともできる。他のユーザがそのエージェントを発見して、会員登録できるようにすることが好ましい。
好ましい実施の形態において、ローカルエージェントは意味論に関係照会結果が表示された際には必ず、クライアント上に現れる「エージェントとして保存」ボタンによって作成される。これはユーザが新しい文書を保存するのに似ている。エージェントが保存されると、ユーザのマイエージェントリストに追加される。エージェントは、ホスト先のエージェントの意味論的ドメインに基づいて意味論的な照会に対応する。本質的にエージェントへの意味論的な照会は、エージェントが「照会を理解している」かどうかをたずねるのに似ている。エージェントは「理解力」の及ぶ限りで照会に応答する。更なる説明として、「人」を管理するエージェントは、文書のエキスパートを求める意味論的な照会に対して、意味論的ドメイン内の人とそのドメインでのカテゴリとの独自で内部マッピングに基づいて応答する。
あるいは、システムのクライアントは非意味論的な照会を使うように設定することもできる。この場合、エージェンシーは照会用に抽出されたキーワードを使う。全てのエージェントは非意味論的な照会をサポートする。意味論的ドメインに属するエージェンシー上のエージェントのみが、意味論的な照会をサポートするのが好ましい。言い換えれば、意味論的検索は検索に格下げとなる。
各エージェントは「スマート」かどうかを示す属性を持つ。スマートエージェントは、エージェンシーが意味論的ドメインに属するのであればエージェンシー上に作成されるのが好ましい。更に、スマートエージェントのみが完全に「理解する」オブジェクトを返す。好ましい実施の形態において、エージェンシーがインストールされる際に、エージェンシー管理者がインストールの選択をすることもできるデフォルトのスマートエージェントがあり、以下がそれに含まれる。
・ All.Understood.All
・ Documents.Understood.All
・ Email.Understood.All
例えば、Email.Understood.All はエージェンシーがその意味論的ドメイン（又はオントロジ）に基づいて意味論的に理解できる電子メールのオブジェクトのみを返す。
本発明は、ユーザが全てのオブジェクトの表示とエージェンシーが理解するオブジェクトのみの表示を行う機能を含むことが好ましい。
サーチエージェント−サーチエージェントは、検索文字列で初期化されたエージェントである。好ましい実施の形態において、起動時にクライアントは検索要求を発行する。サーチエージェントは、以下を含むセマンティックエンバイロメントの任意の部分の検索ができるように設定することができる。
・ 頻繁に使用するエージェント
・ 最近使用したエージェント
・ 最近作成したエージェント
・ お気に入り
・ 全ての [保存した] エージェント
・ 削除したエージェント
・ ローカルエリアネットワーク上のエージェント
・ グローバルエージェンシー ディレクトリ上のエージェント
・ ユーザがカスタマイズしたエージェンシーのディレクトリ上のエージェント
・ 全セマンティックエンバイロメントにある全てのエージェント
クライアントはサーチエージェントの範囲に基づいて検索要求を発行する。ユーザが、全セマンティックエンバイロメントを網羅する検索の希望を指示すると、クライアントは、セマンティックエンバイロメント マネージャ（以下を参照のこと）にある全エージェントと、ローカルエリアネットワーク、グローバルエージェンシー ディレクトリ、及びユーザがカスタマイズしたエージェンシーディレクトリ上にある全エージェントに要求を出す。
サーバ側のフェイバリットエージェント−他の実施の形態においては、エージェンシーはユーザ状態のサポートのフェイバリットエージェントをサポートする。現在のウェブで類似した状況では、ウェブサイトがユーザに好みのリンク、銘柄等のカスタマイズを可能にする。最初に照会を行うと、エージェンシーはデフォルトエージェントと（ユーザ状態が存在すれば）呼び出し側ユーザのフェイバリットエージェントの両方を表示する。
スマートエージェント−スマートエージェントは、ＸＭＬウェブサービスを経由したエージェンシーを参照する構造化された意味論的な照会をカプセル化する単独型エージェントである。好ましい実施の形態において、クライアント上のユーザは、「エージェントを開く」ダイアログを経由してセマンティックエンバイロメントの参照ができる「スマートエージェントの作成」ウィザードで、スマートエージェントを作成・編集して、指定のエージェンシーからのリンクを追加できる。本質的に、これはユーザインターフェースからＳＱＭＬ照会を作成するユーザに相当する。好ましい実施の形態において、ユーザインターフェースは同じエージェンシーのリソースからのリンクの追加のみが可能になる。しかしながら、ユーザは（できれば異種のエージェンシーの）スペシャルエージェントとブレンダーに加えて、複数エージェンシーにわたって同じカテゴリのエージェントを作成できる。ユーザインターフェースは、スマートエージェントが現在の照会を同じエージェンシーを参照にすることを条件として、ユーザは既存スマートエージェントをインフォメーションオブジェクト ピボットとして使いリンクを追加できる。図１６は、リンク（述語）のテンプレート、リンク自体、及びオブジェクト選択用のユーザインターフェース制御を持つ「エージェントを開く」ダイアログを示した好ましい実施の形態である。図１７〜図１９は、「エージェントを開く」ダイアログに関連するセマンティックエンバイロメントのツリービューを例示する図である。図１７は、ユーザがセマンティックエンバイロメントを参照してエージェントを開くことができるようにする「エージェントを開く」ダイアログを示す。図１８は、セマンティックエンバイロメントでエージェンシーをナビゲートする方法と「スマートプレビュー」ビューがある「エージェントを開く」ダイアログを示す。図１９は、セマンティックエンバイロメントからエージェントを開くために、又はダムエージェントを作成することによって、セマンティックエンバイロメントに（ファイルシステム等からの）普通の情報を取り込むために新しい選択肢を示しているツールバー上にある「開く」ツールを示す。
リンクのテンプレートによって本質的に、ユーザが事前定義済みフィルタを使って現在のオブジェクトタイプの述語をナビゲートできる。従ってユーザはオブジェクトタイプの全ての述語に目を通さなくてもすむ。リンクテンプレートの例としては以下の通りである。
・ 全て
・ 最新ニュース（「最後に掲示された」等、時間への敏感さを参照するリンク）
・ カテゴリ化
・ 確実である（非確率的なリンク）
・ 有望である（確率的なリンク）
・ 注釈付加
好ましい実施の形態において、「エージェントを開く」ダイアログは、ユーザにオブジェクトの「リンク先」の選択を可能にする。そして、オブジェクトタイプによっては、ユーザに（例えば、オブジェクトが日付/時刻であればカレンダーコントロールから、テキストであればテキストボックスから、ファイル又はフォルダのパスであればファイルシステムから等の）オブジェクトの参照を可能にする。ウィザードユーザインターフェースは、ユーザが照会結果のプレビューできる。一時的なＳＱＭＬエントリを現在の述語リストを使って作成し、それがウィザードダイアログボックス内のミニブラウザのウィンドウに読み込まれる。ユーザは述語の追加や除去ができ、述語の論理和（“ＯＲ”）又は論理積（“ＡＮＤ”）のどちらを希望するかの選択肢がある。ユーザインターフェースは重複した述語も調べる。
ユーザがウィザードを使ってスマートエージェントの作成を終えると、スマートエージェントはセマンティックエンバイロメントに追加され、ＳＱＭＬも又関連付けたオブジェクトエントリと一緒に保存される。好ましい実施の形態において、ユーザは後でエージェントのプロパティインスペクタ特性シートを使ってスマートエージェントを参照できる。これはユーザに、（名前、記述、作成時刻等の）単純なセマンティックエンバイロメント特性の表示を可能にし、又リソースＵＲＬ（照会を受けているエージェンシーのＸＭＬウェブサービスへのＷＳＤＬ ＵＲＬ）と述語リストの表示を可能にする。ユーザは特性シートからのリストを編集できる。
デフォルトスマート エージェント−デフォルトスマート エージェントは、コンテキストテンプレートではなく情報オブジェクトタイプに基づくこと以外は、デフォルトスペシャル エージェントに似ている。一例として、「文書」は、ユーザのセマンティックエンバイロメントに、全てのエージェンシー上にある全文書を返し、「電子メール」はユーザのセマンティックエンバイロメントに全ての電子メールメッセージを返す、等がある。
スペシャルエージェント−スペシャルエージェントは、コンテキストテンプレートに基づいてユーザにより作成されたスマートエージェントである（以下を参照のこと）。スペシャルエージェントは、特別なエージェントの参照の有無に関わらず、エージェント名で初期化されるのが好ましい。例えば、スペシャルエージェント「Email.Technology.Wireless.All」は、セマンティックエンバイロメントにその名前のエージェントがない場合にでも作成することができる。サーチエージェントと同様に、スペシャルエージェントは、セマンティックエンバイロメントの任意の部分上でその名前で任意のエージェントの検索をする。
好ましい実施の形態において、スペシャルエージェントがユーザによって呼び出されると、クライアントはその名前を持つどんなエージェントでも検索する。もしもその名前のエージェントが見つかれば、クライアントはエージェントを呼び出す。好ましい実施の形態において、ユーザは（必要に応じて）カテゴリのフィラーと、どのエージェンシーに照会するかを指示するコンテキストテンプレートと一致するパラメータを入力する。これらは「エージェントを開く」ダイアログを使って手作業で入力するか、又はユーザが「最近」のエージェンシーと「お気に入り」のエージェンシーのいずれか、又は両方の照会を希望するものを指示できる。他の実施の形態においては、ユーザは（必要に応じて）選択したエージェンシーの論理和又は論理積のカテゴリを選ぶか、又はグローバルエージェンシー ディレクトリで知られる全てのカテゴリを選ぶかの選択肢がある。他の実施の形態においては、ユーザは（コンテキストテンプレートとは対照的に）情報タイプと（述語又はカテゴリとは対照的に）検索するキーワードを選択することができる。
デフォルトスペシャル エージェント−好ましい実施の形態において、システムのクライアントはサポートされる全てのコンテキストテンプレートをマッピングするデフォルトスペシャル エージェントをインストールする。好ましい実施の形態の一例として、デフォルトスペシャル エージェントには以下が含まれる。
見出し
最新ニュース
会話
ニュースメーカー
今後のイベント
発見
履歴
全ての予想
最も確実な予想
エキスパート
お気に入り
権威的
推薦
今日
バラエティ
時系列
今後のイベント
ガイド
カスタムスペシャル エージェント−ユーザが作成したスペシャルエージェントとは対照的に、カスタムスペシャル エージェントは、スペシャルエージェントが安全で、確実で、及び高性能であることを保証するために特別に開発・署名されたスペシャルエージェントである。本発明は、組織及び開発者がカスタムのブレンダーを作成できるようにプラグイン層を提供する。カスタムのブレンダーの一例は「All.CriticalPriority.All that relates to my most recent documents or email」である。このカスタムのブレンダーは、以下のようにリソースエントリでＳＱＭＬファイルにより実装できる。
<resource type= "nervana:url"
agent://all.criticalpriority.all@localhost>
<link predicate= "nervana:relevantto"
type= "nervana:localsemanticref"
recentdocuments >
</link>
<link operator= "or"
type= "nervana:localsemanticref"
recentemail>
</link>
</resource>
好ましい実施の形態において、プレゼンタ（以下を参照）はローカルで「リンク」エントリを解決して、最新の文書又は電子メールメッセージに対応するＸＭＬ引数で目的のリソースへＸＭＬウェブサービス要求を開始する。これにより目的のエージェントはフィルタの起点に関連する意味論を知らずにＸＭＬフィルタで純粋に意味論的な照会への対応に焦点を当てることができる。他の実施の形態においては、上記の例のようなカスタムのブレンダーはデフォルトエージェントである。
垂直型意志決定エージェント−垂直型意志決定エージェントは、垂直型企業のシナリオの意志決定支援を提供するエージェントである。
エージェントスキーマ−エージェントは指定のパラメータ内で動作し、エージェントスキーマを構成する所定の特徴を提示する。エージェントスキーマは、本発明の技術内で変化に富んでおり同様に適用範囲が広い。一例として、本発明の好ましい実施の形態のエージェントスキーマを図２０に示す。本発明は特に更なるフィールドの追加を意図する。例えば、カテゴリのＵＲＬ（又はパス）のフィールドとコンテキストテンプレート名は、（該当する場合は）エージェントが示すカテゴリとコンテキストテンプレートにクライアントとサーバが迅速にアクセスできるように、エージェントスキーマを追加することが可能である。これは（カテゴリ別、文脈別等の）エージェントの異なるビューを提供するのでセマンティックエンバイロメント マネージャにとって有用である。これは（属性及び／又は述語で表現された）エージェント用にＳＱＭＬでフィールドの存在を補足する。好ましい実施の形態における AgentTypeID を図２１に示す。好ましい実施の形態における AgentQueryTypeID を図２２に示す。
好ましい実施の形態においては、ＳＱＬ照会の形式が使用される。しかしながら、複数の照会形式、例えば、ＸＱＬ、ＸＱｕｅｒｙ等が本発明の範囲内として意図される。
ＫＩＳ５０は、このスキーマに対応するデータストアで（サーバ側エージェントの）エージェント表をホストすることが好ましい。図２３は、本発明のＫＩＳ上でサーバ側エージェントの好ましい設定方法を示すエージェント名に対応する意味論的な照会の例を示す。
以下で詳細に説明されるように、エージェントは自己のスキンを含むこともできる。エージェントスキンはＸＳＬＴファイルへのＵＲＬとして示される。又はフラッシュＭＸ又はアクションスクリプトに相当するエージェントのスキンのＵＲＬが指定されていない場合は、エージェントのオブジェクトタイプ用のデフォルトスキンが使われる。
エージェントの照会の規則−各サーバ側エージェントの照会は、OBJECTID のカラムに戻されるように指定されなければならない。各表は Objects の表を派生オブジェクトタイプ用の表とリンクするのでこのカラムを持っている。Objects と他の表は、以下で詳細に説明する。
各エージェントの照会は副照会、カスケード式の照会、又は結合の基本を形成することができるので、各照会はこの形式に従うことが好ましい。一例として、News.All の照会が「SELECT OBJECTID FROM NEWS」（ここで「NEWS」は「ニュース」スキーマを持つニュース記事のメタデータをホストしている表の名前である）として現れるかもしれない。その結果、サーバ１０は、この照会を複合照会の一部として使うことができる。例えば、ユーザがエージェント上に文書をドラッグ＆ドロップすると、サーバは次のような照会を実行する可能性がある。
SELECT OBJECTID FROM NEWS WHERE OBJECTID IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE SUBJECTID IN (50, 67, 89) AND LINKSCORE > 90)
この例は、文書がオブジェクト識別子５０、６７、及び８９で、CATEGORIES の表内のカテゴリに属すると分類されており、０．９のリンクの確率は文書がカテゴリに属することを確定するしきい値である。この例では、文書は News.All の照会のフィルタとして使われ、照会のテキストは複合照会の一部として使われる。
照会用に整合性のある標準を持つことで、意味論的な照会プロセッサに、照会を最終的に表示されるまでマージさせることを可能にする。例えば、意味論的な照会プロセッサの各呼び出しは、どのオブジェクトタイプが結果を返したのかを示さなければならない。そうすると照会プロセッサは、要求されたオブジェクトタイプのスキーマと一致したＸＭＬ情報を返す。言い換えれば、照会プロセッサは表示用のスキーマ固有の結果を返すのが好ましい。各照会は、（OBJECTID に返すために）意味論的層に格納される。最後の例を使うには、ユーザが News.All エージェントを呼び出した際に、ブラウザはエージェンシーのＸＭＬウェブサービス上にある照会プロセッサを呼び出す。すると照会プロセッサは、照会を呼び出して、次のような「ニュース記事」のオブジェクトタイプでフィルタリングする。
SELECT * FROM NEWS WHERE OBJECTID IN (SELECT OBJECTID FROM NEWS)
これはニューススキーマの全てのフィールドを返す。（プレゼンタ経由の）ブラウザは、エージェントスキン又はユーザが指定したスキン（これはエージェントのスキンを上書きする）のどちらかのために、ＸＳＬＴ（又はフラッシュＭＸ又はアクションスクリプト等の提示ツール）を用いて情報を表示する。
照会のバーチャルパラメータ−エージェントの照会には、特別なバーチャルパラメータが含まれているのが好ましい。典型的な例としては‘%USERNAME% が挙げられる。この例では、セマンティッククエリ プロセッサ（ＳＱＰ）は照会を呼び出す前に、バーチャルパラメータを実引数に解決する。エージェント People.MyTeam.All はＳＱＬ照会で次のように設定される。
SELECT * FROM USERS WHERE Division IN (SELECT Division FROM USERS WHERE Name LIKE %USERNAME%)
この例でエージェント名は、たとえエージェントがいかなるユーザに適用するとしても「マイチーム」を含む。 %USERNAME% 変数はＳＱＬにより実際の呼び出し側となるユーザの名前に解決される。ＳＱＬの呼び出しは次のように解決される。
SELECT * FROM USERS WHERE Division IN (SELECT Division FROM USERS WHERE Name LIKE JohnDoe)
この例で、ジョン ドウ（JohnDoe）は呼び出し元のユーザ名と想定する。
シンプルエージェントの検索−各エージェントは、単純検索機能をサポートする。好ましい実施の形態において、ユーザはインフォメーションエージェントのスマートエージェントを右クリックして、「検索」をクリックできる。これでユーザが検索文字列を入力するダイアログボックスが表示される。これは「nervana:contains」等の関連付けられた述語で適切なＳＱＭＬを作成する。本発明は、ユーザが（二者択一的に同じ結果を得ることができる）「スマートエージェントの作成」ウィザードを経て、「テキストを含む」の述語を選択しないで、エージェントの検索（及び、そこからスマートエージェントの作成）を行う簡単で迅速な方法を提供する。
エージェンシーのエージェントビュー−本発明の他の実施の形態は、エージェンシーのエージェントビューを含む。エージェンシーのエージェントビューは、事前定義済み条件に基づいてエージェントのフィルタリングを行う照会である。例えば、エージェントビューの「文書」は、文書の意味論的なクラスオブジェクトを管理するエージェントのみを返す。エージェントビュー「ロイターニュース」は、「ロイター」を発行者としてニュースオブジェクトを管理するエージェントのリストを返す。エージェンシーのエージェントビューは、ユーザにエージェントの中を簡単にナビゲートする方法を提供するために重要である。エージェンシー管理者は、エージェントビューを作成・削除できる。
エージェントの公開及び共有−好ましい実施の形態はエージェントが公開され共有されることを容易にする。これはセマンティックエンバイロメントを、最近のエージェントとフェイバリットエージェント、それらのスキーマ、ＳＱＭＬバッファ等を含むＸＭＬ文書にシリアライズすること、及び文書を公開ポイントに公開することにより実装されるのが好ましい。このＸＭＬ文書は、ローカルの（ユーザが作成した）エージェントの伝達及び共有を円滑にするために同僚、友人等に電子メールで送ることも可能である。これは現在のウェブページが公開される方法とウェブのＵＲＬとリンクが電子メール経由でリンクと添付ファイルを送信することにより共有されるやり方に似ている。
2. ナレッジインテグレーション サーバ
ナレッジインテグレーション サーバ（ＫＩＳ）５０は、システム１０のサーバ側の心臓部である。ＫＩＳは、意味論的にデータを複数の多様な情報源から意味ネットワークに統合し、ネットワークへのアクセスを提供するエージェントをホストする。ＫＩＳは又、クライアントにエージェント経由の意味ネットワークへのアクセスを提供するための意味論的ＸＭＬウェブサービスをホストする。ユーザにとって、ＫＩＳの設定はエージェンシーとして考えることもできる。ＫＩＳは次の特性で初期化されるのが好ましい。
・ エージェンシー名−エージェンシーの名前（例：「ＡＢＣ」）
・ エージェンシーフレンドリーネーム−エージェンシーのフルネーム（例：「ＡＢＣコーポレーション」
・ エージェンシー記述−エージェンシーの記述
・ エージェンシーのシステムユーザ名−エージェンシーのユーザ名。各エージェンシーはインストールされたエンタープライズ（又はウェブサイト）のディレクトリ上のユーザによって示される。システムのユーザ名は、（どのユーザが文書、電子メール及び注釈付加をエージェンシーに公開するかを通して）システムの受信トレイをホストするのに使われる。認証用にエージェンシーは、システムのユーザアカウントにアクセスのあるサーバ上にインストールされなければならない。
・ エージェンシーの認証サポートのレベル−エージェンシーがユーザの認証をサポート又は要求をするかどうかを示す。エージェンシーは（全てのユーザにオープンで、ユーザ状態を持っていない場合は）認証をサポートしない、認証をサポートするが必要としない、認証を必要とする、に設定することができる。認証を必要とする設定では、認証暗号化のタイプが示されているのが好ましい。
・ エージェンシーのユーザディレクトリのタイプ−エージェンシーがユーザを認証するのに使うユーザディレクトリのタイプと、エージェンシーがユーザ情報をどこから得るかを示す。例えば、これはＬＤＡＰディレクトリ、マイクロソフトのエクスチェンジ２０００ユーザディレクトリ、又はウィンドウズ２０００アクティブディレクトリ上のロータスノーツユーザディレクトリ等であってもよい。
・ エージェンシーのユーザディレクトリ名−（マイクロソフトのエクスチェンジ２０００サーバ名等）のエージェンシーのユーザディレクトリのサーバ名を示す。
・ エージェンシーのユーザドメイン名−これは認証のためのユーザドメイン名を示す。このフィールドは任意選択で、エージェンシーが認証をサポートする場合にのみ含まれる。
・ エージェンシーのユーザグループ名−これは認証のためのユーザグループ名を示す。例えば、エージェンシーは「米国従業員」のドメイン名と「マーケティング」のグループ名で初期化することができる。その場合、エージェンシーは、ユーザがそのユーザグループの会員であることを確認するためにユーザ名を調べてから、ユーザディレクトリのタイプで示されたユーザディレクトリ認証符号に認証要求を転送する。呼び出し側のユーザが、そのユーザグループの会員でない場合、認証要求が拒否される。このフィールドはエージェンシーが認証をサポートする場合にのみ有効である。
・ データストア接続名−これはデータベースストアの接続名を示す。これは例えば、ウィンドウズ上のＯＤＢＣ接続名（又はＪＤＢＣ名等）として表すことができる。ＫＩＳは表の格納、更新、及び管理をするために接続名によって参照されたデータベースを用いる（以下を参照）。
・ 動的特性の評価−エージェンシーのＸＭＬウェブサービスは、サーバが現在サポート、又は「理解する」意味論的ドメインのパスのリスト等の、動的特性を返すためのメソッドを公開するのが好ましい。これはユーザにサポートされている意味論的ドメインパス、又はオントロジ／分類学を使ってクライアント上でエージェンシーの参照を可能にする。
図２４を参照にして示すように、ＫＩＳ５０は、意味ネットワーク５２、セマンティックデータ ギャザラー５４、セマンティックネットワーク コンシステンシーチェッカー５６、インファレンスエンジン５８、セマンティッククエリ プロセッサ６０、自然言語パーサ６２、イーメールナレッジ エージェント６４、及びナレッジドメイン マネージャ６６、の主要構成要素を含むことが好ましい。
a. 意味ネットワーク
意味ネットワークはＫＩＳにおいて中核となるデータの構成要素である。意味ネットワークは、データベース表を経由して意味論的な方法、本発明で定義されたスキーマのオブジェクトを一緒にリンクする。意味ネットワークは、スキーマとセマンティックメタデータ ストア（ＳＭＳ）で構成される。意味ネットワークは、オブジェクトとセマンティックリンクの２つのデータスキーマで構成されるのが好ましい。追加的なデータスキーマは、システム要求仕様とエンタープライズのニーズに基づいて含むことができる。ＳＭＳは、全ての意味論的データがデータベース表を経由して格納され更新される（ＳＱＬサーバ、オラクル、ＤＢ２等の）標準データベースが好ましい。ＳＭＳは各主要オブジェクトタイプの表を含むことが好ましい（以下で説明する）。
一例として、図２５は本発明のビジネスユーザと知識の取得、管理、伝達、及び提示の多種の情報源と結果との間の関係を示すエンタープライズ環境向けの意味ネットワークを例示する図である。
Objects− Objects の表は、意味ネットワークの全てのオブジェクトを含む。「Object」は全ての意味論的オブジェクトタイプが生成される「基本クラス」として考えることができる。Object のタイプの好ましいスキーマを図２６を参照にして示す。ObjectID は、意味ネットワークのオブジェクトをタグ付けする一意の識別子である。システムの各オブジェクトは、Object スキーマの拡張子であるスキーマを持つ。あるいは、（文書、電子メール、イベント等の）意味論的オブジェクトタイプは ObjectID のフィールドのみを持つ。照会が呼び出されると、照会プロセッサは最終結果を形成するために Object の表と固有の意味論的表から情報を集約することができる。（各スキーマを Object スキーマの拡張子として持つ）前者のアプローチは結合を避けるのでランタイムのパフォーマンスが向上する。しかしながら、後者のアプローチは計算処理的には高価であるが、ストレージの無駄が少ない。ObjectTypeID は「documents＼documents」、「documents＼analyst briefs」、及び「events＼meetings」等のオブジェクトタイプの階層を記述する文字列に解決する数値であることが好ましい。
SourceID は、オブジェクトが収集されるセマンティック データアダプタ（ＳＤＡ：Ｓｅｍａｎｔｉｃ Ｄａｔａ Ａｄａｐｔｅｒ）用の識別子を指す。セマンティックデータ ギャザラー（ＳＤＧ）は、この情報をオブジェクトが取得されるＳＤＡからの状況情報を要求することでオブジェクトが依然として存在するかどうかを定期的に調べるために使う。
SemanticLinks−ＳＭＳは意味論的なリンクを格納する SemanticLinks スキーマ（及び対応するデータベース表）を含むのが好ましい。これらのリンクは、ＳＭＳにある他のデータ表のオブジェクトを注釈付加し、意味ネットワーク用のデータモデルを構成するのが好ましい。各意味論的なリンクは、意味論的なリンクのＩＤを持つことになる。SemanticLinksの表は、図２７を参照にして示すフィールド名とタイプを含むことが好ましい。SubjectID と SubjectTypeID は、リンク元のオブジェクトのオブジェクトＩＤとオブジェクトタイプＩＤである。ObjectID と ObjectTypeID は、リンク先のオブジェクトのオブジェクトＩＤとオブジェクトタイプＩＤである。LinkScore は、０から１００の範囲が望ましく、確率としてリンクの意味論的強度を示す。これらのフィールドは、例示的なものであって、特定のオブジェクトタイプ及びユーザが所望する意味論的なリンクに基づいて更なる述語を意図する。本発明の好ましい実施の形態は、図２８に示した述語タイプＩＤを提供する。本発明は更なる述語タイプＩＤの追加を意図する。
一例として、意味論的なリンクの「スティーブはパトリックに直属する」は Users 表にあるスティーブのＩＤに対応する主題ＩＤ、PREDICATETYPEID_REPORTSTO の述語タイプ（以下の表を参照のこと）、Users 表にあるパトリックのオブジェクトＩＤ，（「真理」であり、リンクは確率的でないこと示す）リンクスコア１００、及びリンクを修飾する Reference Date 表に表現されることになる。
ＫＩＳは（ＳＭＳ経由で）各オブジェクトタイプのデータベース表を作成、更新、及び管理する。以下は、好ましいプライマリ、及び派生オブジェクトのタイプを列挙したものであるが、これが全てではない。
・ Person（人）
・ User（ユーザ）
・ Customer（顧客）
・ Category（カテゴリ）
・ Document（文書）
・ Analyst Brief（アナリスト要約）
・ Analyst Report（アナリストレポート）
・ Case Study（ケーススタディ）
・ White Paper（ホワイトペーパー）
・ Company Profile（会社の概要）
・ E-Book（ｅブック）
・ E-Magazine（ｅマガジン）
・ Email Message（電子メールメッセージ）
・ Email Annotation（電子メール注釈付加）
・ Email News Posting（電子メールニュースへの投稿
・ Email Distribution List（電子メール配信リスト）
・ Email Public Folder（電子メールの共有フォルダ）
・ Email Public Folder Newsgroup（電子メールの共有フォルダのニュースグループ）
・ News Article（ニュース記事）
・ Event（イベント）
・ Meeting（会議）
・ Corporate Event（会社のイベント）
・ Industry Event（業界のイベント）
・ TV Event（テレビのイベント）
・ Radio Event（ラジオのイベント）
・ Print Media Event（活字メディアのイベント）
・ Online Meeting（オンライン会議）
・ Arts and Entertainment Event（アート及び娯楽イベント）
・ Online Course（オンライン講座）
・ Media（メディア）
・ Book（書籍）
・ Magazine（雑誌）
・ Multimedia（マルチメディア）
・ Online Broadcast（オンラインブロードキャスト）
・ Online Conference（オンライン会議）
オブジェクトタイプは階層パスとして表現されるのが好ましい。パスは例えば、「events＼meetings」を「修飾した Meetings」で拡張して「events＼meetings＼company meetings」のように展開できる。このスキーマモデルは無制限に拡張及び設定可能である。
バーチャルインフォメーション オブジェクトタイプ−バーチャルインフォメーション オブジェクトタイプは、個別のオブジェクトタイプへのマッピングは行わないが、意味論的にユーザにとって興味のあるオブジェクトタイプである。一例としては、「Email」オブジェクトタイプから派生する「Customer Email」オブジェクトタイプがある。このオブジェクトタイプは、個別のスキーマを持たず結果としてＫＩＳ上のＳＭＳに個別の表を持たないことで「バーチャル（仮想）」である。むしろ「Email」オブジェクトタイプから派生するので、ＳＭＳ上の「Email」表を使う。個別のオブジェクトタイプではないが、ユーザはまるで個別のように「Customer Email」の参照と検索に興味を持つことになる。
好ましい実施の形態において、仮想オブジェクトタイプはＳＭＳ上の該当する表にメタデータを格納することで実装される（この場合は「Email」から派生したオブジェクトタイプなので「Email」表に格納される）。しかしながら、オブジェクトタイプの照会の解決は、個別のオブジェクトタイプ用の通常の照会とは異なって行われる。サーバＳＱＰが、（「Customer Email」等の）仮想情報オブジェクトタイプ用の（ＸＭＬウェブサービスを経由した）意味論的な照会要求を受信すると、オブジェクトタイプを一緒に形成する表を結合させることで要求を解決する。例えば、好ましい実施の形態において、「Customer Email」の場合サーバは次のようにＳＱＬ副照会で照会を解決する。
SELECT OBJECTID FROM EMAIL WHERE OBJECTID IN (SELECT OBJECTID FROM CUSTOMERS WHERE EMAILADDRESS IN (SELECT EMAILADDRESS FROM EMAIL)
この照会は、「Customers 表内にも存在する電子メールアドレス値を持つ Email 表から全てのオブジェクトを選択する」に相当する。これは「Customer Email」が顧客による送信、又は受信である電子メールを参照すると想定する。仮想オブジェクトタイプの他の定義も可能で、照会の解決は定義と一貫していることが好ましい。ＳＱＰは「Customer Email」の全ての照会にこの副照会を適用するのが好ましい。この副照会は本質的に、顧客からの電子メールメッセージ用に Email 表をフィルタリングする。これにより実際に存在しないのに、「Customer Email」が存在するような幻想でユーザに所望の結果を送信する。
本発明は各オブジェクトタイプと関連付けられた多種のスキーマを意図する。本発明と同程度の応用性を持つ他のスキーマが開発中である。「Document」スキーマは例えば、ダブリンコア（Ｄｕｂｌｉｎ Ｃｏｒｅ）スキーマ(http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2413.html) 及び他の業界標準のスキーマからフィールドを拡張することができる。又別な例として「News Article」のスキーマは NewsML スキーマ (http://www.newsml.org) の拡張であってもよい。一例として、本発明に従って作られた好ましいユーザオブジェクトのスキーマを図２９を参照にして示す。全てのスキーマは同一のサブセットとしてオブジェクトスキーマのフィールドを持つことが好ましい。MailingAddressTypeID は、図３０に参照にして示すような User（人）のユーザオブジェクトスキーマと関連付けられたものが好ましい。
一例として、本発明に従って作られた好ましいカテゴリオブジェクトのスキーマを図３１に示す。
一例として、本発明に従って作られた好ましい文書オブジェクトのスキーマを図３２に示す。「DocumentCategory」のフィールドは、ＫＩＳ自体によって管理される意味論的カテゴリを参照するのではなく、（ドキュメントデータソースによって）文書でタグ付けされた専有のカテゴリを参照する。「DocumentFormatTypeID」のフィールドは文書タイプを参照する。図３３に示すのは、好ましい実施の形態の活字メディアタイプ ID であり、図３４に示すのは好ましいFORMATTYPEID である。
一例として、本発明に従って作られた好ましい電子メールメッセージリストのオブジェクトのスキーマを図３５を参照にして示す。電子メールの優先度は、低、中、高の優先度に相当する０、１、２が好ましい。EmialTypeID はEMAILTYPEID_EMAIL、EMAILTYPEID_NEWSPOSTING、及びEMAILTYPEID_EMAILANNOTATION（値は１，２，３）を含むことが好ましい。本発明の好ましい実施の形態の、電子メールの配信リストと電子メールの共有フォルダのオブジェクトのスキーマをそれぞれ図３６と図３７に示す。好ましい実施の形態において、PublicFolderTypeID は図３８に示すものが含まれる。
一例として、本発明に従って作られた好ましいイベントオブジェクトのスキーマのメッセージリストのオブジェクトスキーマを図３９を参照にして示す。図４０は、本発明の好ましい実施の形態のイベントタイプを示す。
一例として、本発明に従って作られた好ましいメディアオブジェクトのスキーマのメッセージリストのオブジェクトスキーマを図４１を参照にして示す。図４２は、本発明の好ましい実施の形態のメディアタイプを示す。
一例として、図４３〜図４５は本発明の好ましい実施の形態におけるオブジェクトのカテゴリ化と活用方法を示す追加的な例である。図４３は、ルートオブジェクトのコンテナタイプを示す。図４４は、修飾オブジェクトタイプの階層スキーマを示す。図４５は、ネイティブなコンテナのオブジェクトタイプの述語の例を示す。Person と Customer のタイプ以外の全タイプは、ルートタイプ「全ての情報（All Information）」から全ての述語を継承することが好ましい。本発明は、全て；最新ニュース；カテゴリ化、作成者；注釈付加；確実なリンク；有望なリンク；及び人気のある、を例として含むネイティブなコンテナオブジェクトタイプの述語テンプレートを提供する。
b. セマンティックデータ ギャザラー
好ましい実施の形態において、セマンティックデータ ギャザラー（ＳＤＧ）はＳＭＳを経由して意味ネットワークで入力の追加、取り外し、及び更新の役目を持つ。ＳＤＧはＸＭＬウェブサービス参照のリストで構成される。これらは情報源抽象化層（ＩＳＡＬ）を形成する。各参照はデータソースアダプタ（ＤＳＡ）経由でデータを収集するように初期化される。データソースアダプタは、指定のオブジェクトタイプ用にローカル、又は遠隔の意味論的データソースから情報を収集するＸＭＬウェブサービスである。それはデータソースでオブジェクトエントリに対応するＸＭＬを返す。全てのＤＳＡは、ＸＭＬデータを収集するＳＤＧを経由して同じインターフェースをサポートするのが好ましい。このインターフェースは以下のメソッドを含む。
・ 指定の開始索引と終了索引（例：オブジェクト０〜４９）用オブジェクトのＸＭＬ形式メタデータを取得する。
・ （ＤＳＡタイムクロック上の）ある特定の日付／時刻以後、追加又は削除されたオブジェクトがないかを調べる。
・ （ＤＳＡタイムクロック上の）ある特定の日付／時刻以後の、追加又は削除されたオブジェクトのＸＭＬ形式メタデータを取得する。
・ （引数として渡される）オブジェクトのＸＭＬ形式メタデータを検査することで、意味論的データソースにオブジェクトがまだ存在するか、しないかを調べる。
ＤＳＡのＸＭＬウェブサービスへの各呼び出しがステートレスであれば、ＡＰＩはできれば、要求を修飾するコマンドパラメータを持つ文字列を経由して情報を含むべきである。例えば、電子メール受信トレイ用のＤＳＡは、収集される対象の受信トレイのユーザ名等のラメータを含む。ウェブサイト、又は文書格納用のＤＳＡは、ＵＲＬ上の情報又はクロールするディレクトリのパスを含まなければならない。
各ＤＳＡは、オブジェクトタイプのスキーマに情報を取得することが要求される。ＤＳＡはある特定のオブジェクトタイプ用に実装されなければならないので、ＤＳＡに収集の呼び出しを開始したときに、ＳＤＧはＸＭＬにそのオブジェクトタイプのスキーマを予期する。
ＳＤＧは、ＳＭＳ（意味ネットワーク）の全てのデータベース表の完全性と整合性を管理する役目を持つ。この実施の形態において、ＳＤＧは意味ネットワークマネージャ（ＳＮＭ：Ｓｅｍａｎｔｉｃ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｒ）とも呼ばれる。データベース表には重複したり、又は古いエントリを含まないことが好ましい。ＳＤＧは、オブジェクトのタイプのそれぞれの意味論が理解される既知のスキーマでオブジェクトを取得するので、ＳＤＧはそれに従って表の整合性を管理する。例えば、ＳＤＧは重複する Document のＸＭＬ形式メタデータを DOCUMENTS の表に追加しないことが好ましい。ＳＤＧは重複していないか調べるのに文書の意味論を使う。好ましい実施の形態において、これは作成者名、作成日時、ファイルパス等を比較することで行われる。ＳＤＧは（EVENT、CUSTOMERS 、NEWS 等の）他の表もこの検査を行う。例えば、ＳＤＧはタイトル、場所、日付／時刻を調べることでイベントの冗長検査を行う。他の表も同じように管理される。ＳＤＧは変更されたデータベース表のオブジェクトも更新する。
又ＳＤＧはデータベース表の整理の役目を持つことが好ましい。ＳＤＧは、ＤＳＡが管理する各表にオブジェクトの全てがまだ存在するかどうかを判断するために、定期的にＤＳＡに照会を行う。例えば、文書を取得するＤＳＡには、ＳＤＧはＸＭＬ形式メタデータをＤＳＡウェブサービスに渡してオブジェクトがまだ存在するかを照会する。ＤＳＡは文書のＵＲＬを開く試みを行う。文書がもはや存在しないのであれば、ＤＳＡはそれをＳＤＧに示す。ＳＤＧではなく、個々のＤＳＡが、データソース固有のセキュリティ制限を避けるためにオブジェクトの検証の役目を持つ。例えば、ローカルのリソースへの遠隔からのアクセスを妨げるデータソースの制約が存在するかもしれない。そのような場合には、（できればデータソースに対してローカルで実行される）ＤＳＡのＸＭＬウェブサービスのみがそのデータソースへのアクセスを持つ。あるいは、いくつかのＤＳＡが、ＳＤＧと他のサーバの構成要素と平行してエージェンシーのサーバ上で実行して、データを遠隔から取得する可能性がある。
ＤＳＡにオブジェクトの検証を処理させると、ＤＳＡは、ＳＤＧがオブジェクトがまだ存在するかどうかを調べるために各データソースの開き方の詳細を認識しないようにするので、付加的な効率性とセキュリティを提供することにもなる。ＤＳＡは、（データソースからＸＭＬデータを取得するためデータソースに固有のコードを持っているので）これを認識する必要があるので、ＤＳＡがこのタスクを処理することは適切なことである。
ＳＤＧは、ＤＳＡのＸＭＬウェブサービスのＵＲＬを示唆する収集リストを管理することが好ましい。ＫＩＳ管理者は、ＳＤＧ収集リストからＤＳＡエントリを追加、削除、及び更新することができる。各収集リストエントリは次の通りに設定されていることが好ましい。
1. ＤＳＡの名前とＸＭＬウェブサービスの参照。これは本質的にデータソース、オブジェクトタイプ、（ＷＳＤＬウェブサービスのＵＲＬ等の）ＤＳＡを実装するＸＭＬウェブサービスへの参照の組み合わせを指す。例として以下が含まれる。
a. マイクロソフトのエクスチェンジ２０００電子メールＤＳＡ−このＤＳＡは、マイクロソフトのエクスチェンジ２０００の受信トレイ又は共有フォルダから電子メールのＸＭＬ形式メタデータを収集する。
b. マイクロソフトのエクスチェンジ２０００カレンダーＤＳＡ−このＤＳＡは、マイクロソフトのエクスチェンジ２０００カレンダーから、イベントのＸＭＬ形式メタデータを収集する。
c. マイクロソフトのエクスチェンジ２０００ユーザＤＳＡ−このＤＳＡは、マイクロソフトのエクスチェンジ２０００ディレクトリから、ユーザ／人のＸＭＬ形式メタデータを収集する。
d. マイクロソフトのエクスチェンジ２０００電子メール配信リストＤＳＡ−このＤＳＡは、マイクロソフトのエクスチェンジ２０００ディレクトリから、電子メールの配信リストメタデータを収集する。
e. ロータスノーツの受信トレイ−このＤＳＡは、ロータスノーツの受信トレイ、又は共有フォルダから、電子メールのＸＭＬ形式メタデータを収集する。
f. シーベル（Ｓｉｅｂｅｌ）のＣＲＭデータベース−このＤＳＡは、シーベルのＣＲＭシステムから、顧客のＸＭＬ形式メタデータを収集する。
g. ウェブサイト−このＤＳＡは、ウェブサイトから、文書のＸＭＬ形式メタデータを収集する。
h. ファイルディレクトリ又は共有−このＤＳＡは、ファイルディレクトリ又は共有から、文書のＸＭＬ形式メタデータを収集する。
i. サバ（Ｓａｂａ）Ｅ−ＬｅａｒｎｉｎｇのＬＭＳのレポジトリ−このＤＳＡは、サバラーニング管理システム（ＬＭＳ）のレポジトリから、電子学習のＸＭＬ形式メタデータを収集する。
j. マイクロソフトのシェアポイントドキュメントＤＳＡ−このＤＳＡは、マイクロソフト シェアポイントのサーバワークスペースから、文書のＸＭＬ形式メタデータを収集する。
k. ロイターニュースのレポジトリ−このＤＳＡは、ロイターニュース記事のレポジトリから、ニュース記事のＸＭＬ形式メタデータを収集する。
2. ＤＳＡ収集エントリの記述
3. ＤＳＡ用の初期化情報を示す文字列
4. 収集スケジュール−これはＸＭＬ形式メタデータを収集するために、ＳＤＧがＤＳＡを「クロール」する頻度を示す。
好ましい実施の形態において、エージェンシーはユーザディレクトリのドメインとグループ名で初期化される。この場合、ＳＤＧはユーザディレクトリのＤＳＡ用の収集リストエントリを自動的に行うことが好ましい。例えば、エージェンシーがドメイン名「Ｆｏｏ」とアドレス帳又はグループ名「全員（Ｅｖｅｒｙｏｎｅ）」で、エクスチェンジ２０００のユーザディレクトリで設定される場合、ＳＤＧは（これらのパラメータで初期化された）エクスチェンジ２０００のユーザＤＳＡで収集リストエントリを作成する。又は、エージェンシーは（マイクロソフトのエクスチェンジ、又はロータスノーツ等の）任意の電子メールアプリケーションサーバからユーザディレクトリを取得するように設定することができる。ＳＤＧは、システムユーザ（及び以下に説明するイーメールナレッジ エージェント）用に、電子メール受信トレイとカレンダーＤＳＡの収集リストエントリを初期化する。この３つの収集リストエントリのＤＳＡ（ユーザ、受信トレイ、カレンダー）はデフォルト値に初期化される。受信トレイは、エージェンシーの電子メールの投稿と注釈付加の格納に、カレンダーＤＳＡはユーザによってエージェンシーに投稿されたイベントの格納に使用されるのが好ましい。他のカスタムのＤＳＡは、エージェンシー管理者によって追加することができる。
更にＳＤＧは、データソースから又はデータソースに、オブジェクトが追加、又は削除されたことをＳＤＡが報告した最終時刻を追跡する。この日付／時刻の情報はＳＤＡの刻時機構に基づくことが好ましい。新しい又は削除されたデータがあることをＳＤＡが報告するごとに、ＳＤＧはＳＤＡ用のエントリに日付／時刻の情報を更新し、ＳＤＡにある新しい又は削除された情報を収集する。次にＳＤＧはデータベース表を更新する。
ＳＤＧはＳＤＡから受信するＸＭＬ情報を、本発明の意味ネットワークにマッピングすることが好ましい。ＳＤＧは、ＳＭＳ内のデータベース表に全てのＸＭＬ形式メタデータを格納する。更に、ＳＤＧはＳＤＡから受信したＸＭＬを解析して、必要に応じて意味論的なリンクを固有のＸＭＬフィールドにマッピングする。オブジェクトを一緒に「リンクさせる」情報がＸＭＬに含まれる場合は、ＳＤＧは意味論的なリンクを追加又は更新する。例えば、電子メールのオブジェクトのスキーマは「差出人（Ｆｒｏｍ）」、「宛先（Ｔｏ）」、「ＣＣ（カーボンコピー）」、「ＢＣＣ（ブラインドカーボンコピー）」及び「添付ファイル（Ａｔｔａｃｈｍｅｎｔｓ）」のフィールドを含むことが好ましい。「差出人」、「宛先」、「ＣＣ」、「ＢＣＣ」のカラムでは、ＸＭＬのフィールドは（「;」又は「,」又はスペースのような区切り文字で区切られた）電子メールアドレスを参照する。「添付ファイル」のカラムでは、このフィールドは（「,」等の区切り文字で区切られた）電子メールのメッセージに添付されたファイルのファイルパスを参照する。この生ＸＭＬは他のカラムと一緒に、EMAIL のデータベース表に格納される。更にＳＤＧは、電子メールオブジェクトのフィールドを解析し、これらのフィールドのコンテンツで識別される他のオブジェクトと意味論的なリンクを追加する。例えば、「宛先」のフィールドが john@foo.com を含み、添付ファイルのフィールドに c:＼foo.doc, c:＼bar.doc の文字列が含まれている場合、ＳＤＧは電子メールを以下のように処理する。
1. 電子メールのアドレスjohn@foo.com.を持ち USERS 表のオブジェクトを検索する。又、差出人、宛先、CC、及び BCC のフィールド内の電子メールのアドレスで、他の USER オブジェクトを検索する。
2. オブジェクトが見つかったら、サブジェクトと適切な述語のタイプＩＤとして、電子メールオブジェクトＩＤのある、SEMANTICLINKS の表に意味論的リンクエントリを追加する。この場合、述語の PREDICATETYPEID_CREATOR は電子メールのメッセージの差出人を指す。述語の PREDICATETYPEID_SENTTO は、電子メールのＸＭＬ形式メタデータの「宛先」のフィールドのコンテンツによって参照される、電子メールのオブジェクトと USER のオブジェクトをリンクするのに使われる。述語のPREDICATETYPEID_COPIEDTO と PREDICATETYPEID_BLINDCOPIEDTO は類似の方法で「ＣＣ」と「ＢＣＣ」のフィールドのオブジェクトをリンクするのに使われる。
添付ファイルでは、ＳＤＧは添付された文書のＸＭＬ形式メタデータを抽出する。ファイルパスを持つＸＭＬオブジェクトがＳＭＳ（言い換えれば意味ネットワーク）にすでに存在する場合、ＳＤＧはメタデータを更新する。ＸＭＬオブジェクトがまだ存在しない場合、ＳＤＧはＸＭＬ形式メタデータで新しい文書オブジェクトを作成する。ＳＤＧは、件名として電子メールオブジェクト￥ＩＤ、件名として新しい文書オブジェクトＩＤ、及び述語の PREDICATETYPEID_ATTACHEDTO を持つ SEMANTICLINKS 表にエントリを追加する。これによって、ユーザは、電子メールのメッセージからその添付ファイルにナビゲートして、そして、添付ファイルを、例えばスマートレンズ等の意味論的ツールを使って意味ネットワークを引き続き参照するためのピボットとして使用できるようにする（以下で説明する）。
ＸＭＬのフィールド内エントリと一致するユーザオブジェクトが見つからない場合、ＳＤＧはイベントにオブジェクトを作成しない。ユーザが手作業でエージェンシーに追加される場合には、ＳＤＧは Directory SDA から情報を収集することが好ましい。エージェンシー管理者は、エージェンシーの特性上のユーザグループを経由して、エージェンシーにユーザを追加することが好ましい。
以下は生の電子メールのＸＭＬ形式メタデータを、意味ネットワークにマッピングした一例である。
<email from="john@foo.com"
to="nosa@nervana.net"
cc="steve@nervana.net"
bcc="patrick@nervana.net"
subject="Meeting this Friday"
body="Let us meet on Friday at 2pm"
attachments="c:＼foo.doc; c:＼bar.htm" >
</email>
以上は図４６のオブジェクトグラフに変換される。
c. セマンティックネットワーク コンシステンシーチェッカー
セマンティックネットワーク コンシステンシーチェッカー（ＣＣ）はＳＤＧによって行われる整合性検査を補足する。上記で説明したように、ＳＤＧは重複したエントリが（多種のデータソースから）意味ネットワークに追加されるのを妨ぐことにより、データベース表の完全性を保持する。ＣＣは又、OBJECTS と SEMANTICLINKS 表の整合性を確実にする。 ＣＣは各オブジェクトがネイティブな表に存在することを確実にするために、OBJECTS 表を定期的に調べることが好ましい（OBJECTID のフィールドの値を調べることが好ましい）。例えば、OBJECTS 表にある文書オブジェクトのエントリが、（同じオブジェクトのＩＤを持つ）DOCUMENTS の表に存在することが好ましい。（DOCUMENTS、EVENTS、EMAIL 等の）ネイティブな表に対応しない OBJECTS 表内のオブジェクトは、ＣＣにより除去され、その逆も行われる。
ＣＣは又 SEMANTICLINKS 表の整合性を保持する役目を持つ。この表の意味論は、「サブジェクト（「リンク元」」又はオブジェクト（「リンク先」）のどちらかが存在しない場合には、意味論的なリンクは存在しない」であることが好ましい。これを説明するために、例えばオブジェクトＡは、オブジェクトＢに述語Ｐでリンクされており、Ａ又はＢが削除された場合、そのリンクは削除されるべきである。ＣＣは SEMANTICLINKS の表を定期的に調べる。任意のサブジェクト、又はオブジェクトが削除された場合、ＣＣは意味論的なリンクエントリを削除する。
整合性検査は、ＫＩＳ自体にあるコードで、又はストアード プロシージャ、又はデータベースレベルでの制約として実装してもよい。
d. インファレンスエンジン
インファレンスエンジンは、意味ネットワークに意味論的なリンクを追加する役目を持つ。インファレンスエンジンは、持続的な意味論的活動に基づいた意味論的なリンクを追加するために、一組のヒューリスティック手法から成るインファレンスルールを採用する。
インファレンスエンジンは、意味論的なリンクを除去できることが好ましい。意志決定エージェント（以下で説明する）は、知識労働者が意志決定を下す際に支援するためにインファレンスエンジンを使う。
インファレンスエンジンは、意味ネットワークを掘り下げて、確率的な推測に基づく新しい意味論的なリンクを追加することで動作する。例えばインファレンスエンジンは、意味ネットワークを監視して、電子メールの送信方法、電子メールのタイプ、及び送信者のパターンを観察することが好ましい。インファレンスエンジンは、ユーザの専門的知識、インファレンスエンジンの監視範囲内のさまざまな主題のカテゴリに関連した参考資料等から情報の推測を行う。例えばインファレンスエンジンは、ユーザがある特定のカテゴリのエキスパートであることを指すのに、意味論的なリンクを述語の PREDICATETYPEID_EXPERTON で追加する。この場合のサブジェクトはユーザオブジェクトで、オブジェクトはカテゴリオブジェクトである。これを推測するには、インファレンスエンジンは最低ある一定期間（例として２週間）意味論的活動を観察するように設定されることが好ましい。あるいはユーザが最低ある所定数のメッセージを送った後、又はある数の文書を作成した後にのみリンクを推測するように設定されることが好ましい。インファレンスエンジンは PREDICATETYPEID_CREATOR と PREDICATETYPEID_CONTRIBUTOR のリンク上で統計を記録することで新しいリンクを推測する。
一例として、インファレンスエンジンは以下である場合、ユーザがあるカテゴリのエキスパートであることを推測する可能性がある。
・ 作成した電子メールメッセージの全てのカテゴリの中で、このカテゴリは上位Ｎ（設定可能）の１つである。
・ 同カテゴリに関する電子メールメッセージを週に平均Ｍ回以上（設定可能）書いている。
・ 過去Ｐカ月（設定可能）に少なくともＯ回（設定可能）の電子メールメッセージを書いている。
このデータを正確に推測するより高度な推測モデルを意図する。例えば、確率分布と統計上の相関関係のモデルを採用することが可能である。このようなモデルはゆっくり時間をかけて、シナリオごとに開発されることが好ましい。
インファレンスエンジンは又、追加された可能性があるリンクを削除する役目を持つ。例えば、従業員が転職をした場合、（他の従業員と比較して）ある特定カテゴリのエキスパートで「なくなる」かもしれない。インファレンスエンジンがこのことを（電子メールのパターンを観察する等で）検出すると、その人がそのカテゴリのエキスパートであることを示す意味論的なリンクを除去する。
推測された意味論的なリンクは、確率的な意味論的な照会を持つシナリオにとって重要である。本発明の実施の形態の一例として、インフォメーションエージェントを使って、ユーザはファイルシステムから文書をエージェント（例えば、People.Research.All）にドラッグ＆ドロップすることができる。これはユーザが研究部門でその文書のエキスパートを知りたい場合である。するとブラウザが、エージェントをリソース（又はサブジェクト）として持ち、述語が nervana:experton で、文書のパスがオブジェクトであるＳＱＭＬ照会を呼び出す。次にプレゼンタが、その文書のＸＭＬ形式メタデータを取得して、エージェントをホストするエージェンシー上に存在するＸＭＬウェブサービスを述語ＩＤと文書のＸＭＬ形式メタデータを引数として呼び出す。エージェンシー上のサーバ側の意味論的な照会プロセッサがこのＸＭＬウェブサービスの呼び出しを処理して、その呼び出しを意味ネットワークのデータモデルと一致するＳＱＬ照会に変換する。この例において、呼び出しは以下のように解決されるのが好ましい。
1. ＫＤＭの全ての意味論的ドメインエントリに対して、文書のカテゴリ化を行うために対応するＫＢＳを呼び出す。
2. 返されたカテゴリを（ＵＲＬを比較することによって）意味ネットワークカテゴリのオブジェクトにマッピングする。
3. People.Research.All エージェントの照会を副照会として使って、照会を呼び出す。
この例では、最終的な照会は以下のように表示される。
SELECT * FROM USERS WHERE DEPARTMENT LIKE "RESEARCH" AND OBJECTID IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE OBJECTTYPEID = 32 AND PREDICATETYPEID = 98 AND SUBJECTID IN (SELECT OBJECTID AS SUBJECTID FROM CATEGORIES WHERE OBJECTID IN (34, 56, 78)) AND LINKSCORE > 90 )
この照会は、ユーザのオブジェクトタイプのオブジェクトタイプＩＤが３２で、PREDICATETYPEID_EXPERTON の述語タイプＩＤの値が９８、文書はオブジェクトＩＤが３４、５６、及び７８を持つカテゴリに属し、意味論的なリンクスコアのしきい値が９０であると想定する。
e. サーバ側のセマンティッククエリ プロセッ
サーバ側のセマンティッククエリ プロセッサ（ＳＱＰ）はＫＩＳのクライアントからの意味論的な照会に応答する。ＳＱＰがＫＩＳ（又はエージェンシー）上の意味ネットワークへの主な入口点であることが好ましい。ＳＱＰはエージェンシーのＸＭＬウェブサービスを経由して公開される。ＳＱＰは意味論的なリンクのフィルタで、エージェントの直接の意味論的な照会と（クライアントが生成した）汎用の意味論的な照会を処理する（以下を参照のこと）。サーバ側エージェントのフィルタでの照会に対して、インフォメーションエージェントは、エージェント名とオブジェクト索引引数をＳＱＰに渡して呼び出す。例えば、ブラウザは Documents.Technology.Wireless.All のエージェント上のオブジェクト０〜２４を要求することができる。この例では、ＳＱＰはエージェント表にあるエージェントの照会を検索して、その照会をセマンティックメタデータ ストア（ＳＭＳ）をホストするデータベース上で呼び出す。エージェントの照会はＳＱＬ、あるいはＸＱｕｅｒｙ、又はＸＱＬ等のよく知られた別の照会形式として格納されることが好ましい。ＳＱＰは、（全ての表を保持する）データベースが理解する形式に照会形式を変換してもよい。大半の商用データベースはＳＱＬを理解するので、デフォルトのエージェント照会形式として操作することが好ましい。
エージェントの照会は、上記で説明した照会規則に従うことが好ましい。その結果照会は、エージェントのオブジェクトタイプとしてスキーマのフィールドではなくオブジェクトＩＤを返す。上記で説明した例においてでは、Documents.Technology.Wireless.All は「SELECT OBJECTID FROM DOCUMENTS WHERE …」というエージェントの照会を呼び出す。ＳＱＰはエージェントの照会でフィルタリングされた照会を発行する役目を持つが、これによりオブジェクトタイプ（この場合は「文書」のオブジェクトタイプ）の実際のメタデータを返す。この例では、照会は以下のように表示される。
SELECT * FROM DOCUMENTS WHERE OBJECTID IN (SELECT OBJECTID FROM DOCUMENTS WHERE ...)
この照会は、最初のエージェントの照会内で一致するオブジェクトのＩＤを持つ全てのオブジェクトに対して、「文書」スキーマのデータのカラムを返す。ＳＱＰはデータベースの照会のメタデータの結果を確認し、その結果をエージェントのオブジェクトのタイプ（この場合は「文書」）用の適切なスキーマを用いて整形式ＸＭＬに変換する。データベースが生ＸＭＬの取得をサポートする場合、ＳＱＰはデータベースにＸＭＬの結果を与えるように要求することで照会を最適化する。これはＳＱＰが余分の変換手順を踏まなくてもよいので、処理能力の向上につながる。ＳＱＰはエージェンシーのＸＭＬウェブサービスを経由して、ＸＭＬを呼び出し側に渡す。
ＳＱＰは意味論的ブラウザ（又はＸＭＬウェブサービスの他のクライアント）によって渡された、より複雑な照会を処理することが好ましい。一例として、このような照会は以下に挙げるＸＭＬウェブサービスのＡＰＩの形式を取ることが可能である。
String
InvokeSemanticQuery(
Integer BeginIndex,
Integer EndIndex,
String AgentName,
Integer NumberOfLinks,
String OperatorNames[],
String LinkPredicateNames[],
String LinkTypeNames[]
String LinkObjects[]);
この例で、「[]」記号は配列を指す。ＡＰＩはゼロベースの開始索引、ゼロベースの終了索引、任意選択のエージェント名、意味論的なリンクの数を指す整数、演算子名の配列、リンク述語名の配列、リンクタイプ名の配列、及びリンクのオブジェクトを参照する文字列の配列を取得する。エージェント名がＮＵＬＬ（“”）の場合、ＳＱＰは照会を「そのまま」処理する。つまり前もって形成されたエージェントのフィルタなしで処理する。クライアントから完全に生成された照会の場合が該当する。配列は、NumberOfLinks のパラメータが各配列のサイズを指すので可変サイズである。演算子名は論理演算子を含む所定の有効な演算子を含み、ＳＱＬ又は他の照会形式で照会を修飾するために使うことができる。term:or と term:and がその例に含まれる。リンクの述語名は（term:relevantto、term:reportsto、term:sentto、term:annotates、term:annotatedby、term:withcontext 等の）１つ以上の事前定義済み述語が含まれる。リンクタイプ名はリンクのオブジェクトタイプを示す。一般的な例には term:url 及び term:object が含まれる。term:urlの場合は、リンクオブジェクトの文字列は objects://… 又は Agent://… から成る整形式ＵＲＬを参照する。term:object の場合は、引数は本発明の中で定義されたオブジェクトを参照する整形式ＸＭＬ形式メタデータの命令である。このオブジェクトは、クライアントから又は別のエージェンシーから解決されるのが好ましい。ＡＰＩは（ＸＭＬウェブサービスのメソッド呼び出し自体の戻り値に加えて）ＸＭＬの結果を含む文字列を返す。
一例として、以下のデータを持つＳＱＭＬは：
<resource type="term:url"
Agent://all.criticalpriority.all@abc.com/Agency.asp>
<link predicate="term:relevantto"
type="term,:object"
object://4576 >
</link>
<link operator="or"
predicate="term:intersects"
type="term:url"
Agent://email.wireless.all@abc.com/Agency.asp>
</link>
</resource>
abc.com/Agency.asp 上のウェブサービスに位置するエージェンシー上で以下のように解決される。
InvokeSemanticQuery(
0,
24,
"all.criticalpriority.all",
2,
{ "term:and", "term:or" },
{ "term:relevantto", "term:intersects" },
{ "term:object", "term:url" },
{ "object://4576", "Agent://email.wireless.all@abc.com/Agency.asp" } );
これは次のＳＱＬ照会に解決されるのが好ましい。
SELECT TOP 25 * OBJECTS WHERE OBJECTID IN (SELECT OBJECTID FROM OBJECTS WHERE CREATIONDATETIME='02/26/02' AND (OBJECTID [RELATEDTO] [OBJECT WITH ID 4576]) AND OBJECTID IN (SELECT OBJECTS FROM EMAIL WHERE CATEGORY [IS] 'WIRELESS')
このＳＱＬの例は、ＳＱＰによって生成される照会タイプを説明するためにショートハンドを使用する。ＳＱＰはＸＭＬを取得して、それを呼び出し側に返す。このＸＭＬはＳＲＭＬ（意味論的結果マークアップ言語）形式であり、これは本発明の好ましい実施の形態における意味論的な照会結果のＸＭＬメタスキーマの定義である。本付属書類の実例Ａは、ＳＲＭＬの意味論的結果のバッファ、又は文書である。これはエージェンシーが意味論的な照会に応答して返すＸＭＬの例である。クライアントのスキンはこれらの結果を取得し、スキンとエージェント（オブジェクトスキン／文脈スキン／ブレンダースキン）の特性、利用可能な表示領域の量、無能力の考慮及びスキンの属性に基づいて、（ＸＳＬＴ及び／又はスクリプトを使って）それから提示を生成する。
f. 自然言語パーサ（Ｎａｔｕｒａｌ Ｌａｎｇｕａｇｅ Ｐａｒｓｅｒ）
自然言語パーサ（ＮＬＰ）は自然言語のテキストを、ＳＱＰが理解するＡＰＩの呼び出し、又はデータベースで処理できる生ＳＱＬ（又は単純照会の形式）のいずれかに変換することが好ましい。自然言語パーサはテキストを意味論的ブラウザから、又はイーメールナレッジ エージェントを経由した電子メールによって直接渡される（以下を参照のこと）。
g. イーメールナレッジ エージェント
ＫＩＳはイーメールナレッジ エージェント（又はエンタープライズインフォメーション エージェント（ＥＩＡ：Ｅｎｔｅｒｐｒｉｓｅ Ｉｎｆｏｒｍａｔｉｏｎ Ａｇｅｎｔ）と呼ばれる１つの主要な公開の構成要素を含むことが好ましい。このエージェントの機能は本質的にデジタルの使用人として、（エージェンシー管理者が選択したカスタムの名前等の）一意的な電子メールアドレスを含むことが好ましい。イーメールナレッジ エージェントは、情報公開と知識の共有の「Fire and Forget（発信後削除）」のメソッドを追加することでマイクロソフト オフィス、シェアポイント等の既存公開ツールを補足する。これは情報の公開者が、誰がその情報に興味を持つだろうか分からない場合に特に有用である。
本発明の好ましい実施の形態において、ユーザは意見、注釈付加、文書、添付ファイル等を公開するためにイーメールナレッジ エージェントに電子メールを送信する。イーメールナレッジ エージェントは、その電子メールから意味を抽出してそれを意味ネットワークに適切に追加する。他のユーザは、ドラッグ＆ドロップ、スマートレンズ等の他のプラットフォームの提示ツールのエージェントを経由して、公開された情報にアクセスすることができる（以下で説明する）。
イーメールナレッジ エージェントは、エージェンシー管理者によって作成されたシステムの構成要素である。システムのユーザ名はサーバの最初のインストール時に表示される。システムユーザは、（マイクロソフトのエクスチェンジ、ロータスノーツ等の）エンタープライズ環境向けの電子メールシステムで電子メールのユーザに一致するのが好ましい。この実施の形態において、イーメールエージェントは自己のメールボックス、カレンダー、アドレス帳等を持つ。その結果としてこれらは、システムユーザ用の電子メールサーバ上のオブジェクトと一致する。サーバがインストールされると、ＫＩＳは（電子メールのアプリケーション次第で）システムの受信トレイ用に適切なＤＳＡをインストールする。ＫＩＳは、システムの受信トレイが定期的に電子メールを探してクロールされるべきであることを指示して、ＳＤＧに収集リストエントリを自動的に追加することが好ましい。
イーメールナレッジ エージェントは、第一種の電子メールアドレスであるので、（自然言語とインスタントメッセージ用の）通知元及び照会元としても機能する。エージェンシーからの通知は、（ユーザが興味を示す可能性のある新しい関連情報があることを示した）イーメールナレッジ エージェントによって送信されるのが好ましい。イーメールナレッジ エージェントは又、自然言語照会としてユーザから電子メールを受信することもできる。これらのメッセージはＳＱＰによって解析され処理される。ＸＭＬの結果は、自然言語照会のＸＭＬの結果上で処理されたＸＳＬＴで生成された、（適切なデフォルトスキンでの）ＨＴＭＬファイルとしてユーザに送信されるのが好ましい。
イーメールナレッジ エージェントは、普通のなじみの深い構成要素又は「使用人」であるので、エージェンシー管理者はそのアドレスを配信リストに追加することが好ましい。この手順によって、ＳＤＧに配信リスト内の全ての電子メールに意味論的な索引付けができるので、イーメールナレッジ エージェントをユーザにとって有用な配信リストをシームレスに統合することによって意味ネットワークにデータを読み込む。これは本発明のデジタルのインフォメーションナーバス システムを組織内での労働者と円滑に統合する方法である。
注釈付加−イーメールナレッジ エージェントは、注釈付加を公開するのに使用されることが好ましい。本発明において、注釈付加は電子メールメッセージであることが好ましい。好ましい実施の形態において、注釈付加オブジェクトタイプは電子メールオブジェクトタイプのサブクラスである。これによってユーザは意味論的ブラウザにオブジェクトを注釈付加するために、もっとも一般的な公開ツールである電子メールを使用できる。ユーザはオブジェクトを注釈付加して、その注釈付加に添付ファイルを追加できる。これらの添付ファイルはＫＩＳ上にＳＤＧで意味論的に索引付けされる。これはユーザが、例えば文書から、注釈付加へ、次に添付ファイルへ、それからロイター記事に、次に来週始まる業界のイベントへとナビゲートできるシナリオを可能にする。
（電子メールのＸＭＬスキーマを意味ネットワークにマッピングすることによって）、電子メールを意味論的に索引付けするために記述されたプロセスは又注釈付加にも適用される。しかしながら、本発明の好ましい実施の形態において注釈付加の場合は付加的な処理が望ましい。特に、ユーザが意味論的ブラウザ内にある「プレゼンタ」ウィンドウのオブジェクト上の「注釈付加」をクリックすると、（以下で説明する）、ブラウザは（マイクロソフトのアウトルック、マイクロソフトのアウトルックエクスプレス等の）ローカルマシン上に登録された電子メールクライアントを読み込む。「宛先」フィールドはオブジェクトをホストするエージェンシー用システムユーザのアドレスからデータが読み込まれる。「件名」フィールドは例えば annotation: object=[objectid] の特殊文字列からデータが読み込まれる。電子メールがイーメールナレッジ エージェントの受信トレイに着信すると、電子メールの受信トレイ用ＤＳＡは（サーバのイベント経由等で）その電子メールを受け取る。ＳＤＧはイベントを受信するＤＳＡから、又は次回に他のデータをＤＳＡに要求する際にＤＳＡから新しい電子メールのＸＭＬ形式メタデータを取得する。好ましい実施の形態において、このポーリングの処理は頻繁に行われる。電子メールオブジェクトは、電子メールオブジェクトタイプ、又は注釈付加オブジェクトタイプを参照するという事実には気がつかないで、ＤＳＡは電子メールオブジェクトのＸＭＬ形式メタデータを返す。ＳＤＧは電子メールのＸＭＬ形式メタデータを処理し、「件名」フィールドを検証する。ＳＤＧが「注釈付加」の接頭辞を「見る」と、その電子メールは実際には注釈付加であることを認識し、件名のテキストからオブジェクトＩＤ引数の抽出を行う。ＳＤＧは（各メッセージを OBJECTS、及び EMAIL の表に追加して、必要に応じて「差出人」、「宛先」、「ＣＣ」、「ＢＣＣ」及び「添付ファイル」のフィールドに意味論的なリンクを追加する等）残りの電子メールメッセージの意味ネットワークを更新する。好ましい実施の形態において、ＳＤＧは追加の手順を行う。特に、電子メールのオブジェクトを（PREDICATETYPEID_ANNOTATES の述語で）件名のテキストにオブジェクトＩＤ引数によって示されたオブジェクトでリンクする意味論的なリンクのエントリを追加する。
本発明では、注釈付加は特別な述語を持つ別の意味論的なリンクとして取り扱われる。その結果、全ての意味論的な機能は、意味論的なリンク、意味論的な照会等を経由した意味論的ナビゲーションのような注釈付加に適用される。例えばユーザは、ここ６カ月間にユーザのチームにいる会員全員によって書かれた全ての注釈付加を要求する照会を行うことができる。これは、例えば、People.MyTeam.All のエージェントの上位にある Agent Annotations.All をドラッグして結果を並べ替える、又は照会を作成する「スマートエージェントの作成」ウィザードを呼び出すことになるスマートエージェントを作成することによって、意味論的ブラウザ内で実現できる。
h. ナレッジドメイン マネージャ
ナレッジドメイン マネージャはＫＩＳ上の構成要素で、意味ネットワークにあるドメイン固有のインテリジェンスを追加及び管理する役目を持つ。ＫＤＭは本質的に、ドメインインテリジェンスで意味ネットワークを「注釈付加」する。ＫＤＭはナレッジベース サーバ（ＫＢＳ）の１つ以上の実現値に関連付けられたＵＲＬで初期化される。これは１つ以上の意味論的ドメイン用に「知識」を効率よく格納することになる。ＫＢＳはサポートするそれぞれの意味論的ドメイン用の分類法に対応する、オントロジとカテゴリを持つ。更に、（ＫＢＳに接続された）意味論的ドメインを持つエージェントは、意味論的な照会に応答する。エージェントが意味論的ドメインに属しない場合、（オントロジ又は分類法を必要とする）意味論的な照会に対応できない。むしろ（文脈に依存し時間に敏感な取得サービスを提供するが利用可能な文脈は限定される）キーワードに基づいた照会にのみ応答する。
ＫＤＭの各エントリは意味論的ドメインのエントリである。意味論的ドメインのエントリは、ＫＢＳへのＵＲＬと、意味論的ドメイン名を持つ。意味論的ドメイン名はＫＢＳ上にある固有オントロジにマッピングする。本発明の好ましい実施の形態において、意味論的ドメイン名は以下の規則に従う。
<Top Level Domain Name>＼<Secondary Level Domain Name>......
意味論的ドメイン名の例には次が含まれる。
・ Industries
・ Industries＼Pharmaceuticals＼LifeSciences
・ Industries＼InformationTechnology
・ General＼Sports.Basketball＼NBA
・ General＼Sports.Basketball＼CBA
あるいは意味論的ドメイン名は、完全修飾されていれば「ドメインパス」と呼ぶこともできる。完全修飾はパスの始めにインターネットのドメイン名の接頭辞を付け加えることで実現する。これは意味論的ドメインの「所有者」又は「ソース」であることを示す。例えば Nervana.NET＼Industries＼Pharmaceuticals はインターネットのドメイン名の NERVANA.NET に基づいて Industries＼Pharmaceuticals の意味論的ドメインを参照する。別の例では Reuters.com＼Sports＼Basketball は Reuters.com 上の Sports＼Basketball を参照する。このアプローチを使って、ドメイン名とパスは全世界で一意的に管理される。
ナレッジドメイン マネージャカテゴリ（ＫＤＭ）は知識ドメインのカテゴリをドメインエントリリスト内の各ＫＢＳに定期的に要求する。ＫＤＭはＫＩＳ上のＸＭＬウェブサービスとして実装されることが好ましい。ＫＤＭは各意味論的ドメインエントリ用の構成の選択肢を含む。その選択肢の１つは、意味論的ドメインエントリに対応するドメイン固有のインテリジェンスで、ＫＤＭが意味ネットワークを更新するスケジュールが含まれていてもよい。例えばエージェンシー管理者は、毎日午後１時にＫＢＳ上の意味論的ドメインをクロールするように（ＫＩＳ経由で）ＫＤＭを設定することができる。更新スケジュールは、管理者が考えるＫＢＳ上のオントロジ又は分類法の変更頻度と一致するべきである。
ＫＩＳはＫＤＭを定期的に呼び出して、CATEGORIES 表の更新を要求することが好ましい。好ましい実施の形態においてＫＤＭは、ある特定の分類法に対応する意味論的ドメインエントリ内の意味論的ドメイン名用に更新されたカテゴリを取得するために、（ＸＭＬウェブサービスのＡＰＩ呼び出しを経由して）ＫＢＳを呼び出す。ＡＰＩの呼び出しの一例は、GetCategoriesForSemanticDomain (String SemanticDomainName) である。ＫＢＳは意味論的ドメイン名によって参照された意味論的ドメイン内にある全てのカテゴリのＸＭＬベースリストを返す。このＸＭＬリストは上記に示す CATEGORIES スキーマ（カテゴリのＵＲＬ、名前、記述、ＫＢＳのＵＲＬ、及び意味論的ドメイン名）と一致する。ＫＤＭはこの情報で CATEGORIES 表を更新する。表内にすでに存在しているカテゴリのエントリ用に、ＫＤＭは名前と記述を更新する。新しいエントリ用に、ＫＤＭはオブジェクトマネージャから新しいオブジェクトＩＤを要求して、それをカテゴリのエントリに割り当てる。好ましい実施の形態において、カテゴリは「オブジェクト」であるので Object タイプから継承し、その結果オブジェクトＩＤを持つ。
ＫＤＭは、カテゴリのエントリのＵＲＬを調べて、関連するＫＢＳのＵＲＬと意味論的ドメイン名を取得した後で、新しいリスト内に存在しない CATEGORIES 表内のエントリを削除することで、（特定意味論的ドメインの）ＫＢＳ上にある CATEGORIES リストに CATEGORIES 表を同期化させる。意味論的ドメインのエントリがＫＩＳから削除されている場合、ＫＤＭは対応する意味論的ドメイン名とＫＢＳのＵＲＬで全てのカテゴリのエントリを削除する。これは本質的に、既存の知識のエージェンシーを除去するのに似ている。
ＫＤＭは意味論的ドメインのエントリに基づいて、意味ネットワークの全ての「知識オブジェクト」を定期的にカテゴリ化する。新しいオブジェクトが意味ネットワークにＳＤＧによって追加されると、ＳＤＧはＫＤＭにそのオブジェクトをカテゴリ化するように要求する。ＫＤＭはその意味論的ドメインにあるエントリ内の全てのＫＢＳの実現値を列挙して、オブジェクトのＸＭＬを引数としてＸＭＬウェブサービスの呼び出しを開始する。好ましい実施の形態において、ＫＢＳは以下と類似するＸＭＬのバッファで結果を返す。
<results>
<result categoryurl="category://foo"
score="91" >
<result categoryurl="category://bar"
score="93" >
<result categoryurl="category://foobar"
score="100" >
</results>
この情報は、意味論的カテゴリ化のＫＢＳ上における意味論的ドメイン内のカテゴリ化に対するＸＭＬオブジェクトの重要度を示す。本発明の好ましい実施の形態において、意味論的ドメインのエントリは、ＫＤＭがＫＢＳから要求すべき最低の重要度を示すしきい値（０〜１００）で設定される。ＫＢＳは所定のしきい値を超えるスコアを返す。ＫＤＭはこのカテゴリ化の結果に基づいて、意味ネットワークを注釈付加する。これは「カテゴリに属する」という述語タイプＩＤと結果内のカテゴリのオブジェクトＩＤで意味論的なリンクを追加、又は更新することで実現されることが好ましい。ＫＤＭは SEMANTICLINKS 表を更新する。カテゴリ化されたオブジェクトが、オブジェクトＩＤの値５６を持つと想定すると、更新の照会は以下のように表示される。
UPDATE SEMANTICLINKS SET LINKSCORE = 91 WHERE OBJECTID=56 AND PREDICATETYPEID = 67 AND SUBJECTID IN (SELECT OBJECTID AS SUBJECTID FROM CATEGORIES WHERE URL LIKE "CATEGORY://FOO")
ＫＤＭは「知識オブジェクト」（できれば文書、ニュース記事、イベント、電子メール等で、人のようなオブジェクトを含まない）の全てを定期的に検知してカテゴリ化する。このプロセスはＫＢＳが可能性として「よりスマートに」なるとより優れたカテゴリ化を提供するので、意味ネットワークのオブジェクトが以前にカテゴリ化された場合にでも行われるのが好ましい。このような場合には、同じカテゴリ化の要求が繰り返された場合でも結果が変わる可能性がある。これは例えば、ＫＢＳ上のオントロジが更新された場合に起こる。従って好ましい実施の形態においては、オブジェクトがセマンティックデータ ギャザラーによって意味ネットワークに追加された時と、意味ネットワークがドメインの最新知識を持っていることを定期的に確実にすることが行われた時の両方でカテゴリ化が行われる。
i. 他の構成要素
フェイバリットエージェント マネージャ−ユーザ状態をサポートするエージェンシー上で、フェイバリットエージェントはユーザ単位での好みのエージェントのリストを管理する。好ましい実施の形態において、フェイバリットエージェント マネージャはユーザ名の UserFavoriteAgents 表内にあるお気に入りのエージェントへのマッピングを格納する。
コンパウンドエージェント マネージャ−コンパウンドエージェント マネージャは複合エージェントの作成、削除、及び更新の管理を行う。上記で説明したように、複合エージェントはシステム内の他のエージェントから成るエージェントで、含まれたエージェント内の照会結果の論理和又は論理積を送信するように初期化される。コンパウンドエージェント マネージャは、システム内にある全ての複合エージェントを管理し、複合エージェントを CompoundAgentMap表を経由して含んでいるエージェントにマッピングする。
コンパウンドエージェント マネージャは複合エージェントの作成、そこからエージェントを削除、名前の変更、追加、及び除去、そして論理和又は論理積のどちらが望ましいかを示すために関数を公開する。コンパウンドエージェントは他の複合エージェントを追加することができる。起動時に意味論的な照会プロセッサは、コンパウンドエージェント マネージャに複合照会を要求する。コンパウンドエージェント マネージャはそのエージェントのマップグラフの中をナビゲートして、全てのエージェントに対する全ての照会を含んでいる複合照会を返す。エージェントが削除された場合、エージェントの照会を無視して、複合エージェントは呼び出し時の新しい状態を「引き取る」。言い換えれば、照会の複合化は現存するエージェントにのみ行われる。エージェントのどれかが削除されたことを複合エージェントが観察するとそのエントリはマップから削除される。
ユーザプロファイルマネージャ−ユーザプロファイルマネージャ（ＵＰＭ：Ｕｓｅｒ Ｐｒｏｆｉｌｅ Ｍａｎａｇｅｒ）は継続的にユーザプロファイルを推測するためにインファレンスエンジンを使用することが好ましい。ＵＰＭはユーザからの明示的なプレファレンスに関するフィードバックに基づいて、意味ネットワークを注釈付加する。好ましい実施の形態において、このプロセスは PREDICATEID_ISINTERESTEDIN の述語の使用を必要とする。ＵＰＭは意味論的なリンクを推測し PREDICATEID_ISLIKELYTOBEINTERESTEDIN の述語で意味ネットワークを注釈付加する。ユーザへの全ての照会結果は PREDICATEID_ISLIKELYTOBEINTERESTEDIN の述語の意味ネットワークへの照会で修飾される（アウトオブバウンド）。インファレンスエンジンは時間と共に学習するので、照会結果はユーザの習慣に基づいている。
あるいはＵＰＭは、ユーザステート ストア（ＵＳＳ）に格納されたユーザプロファイルの情報で設定することもできる。この情報はクライアント側でユーザプレファレンスを示して手作業で入力される。この情報はユーザが対話するサーバに転送され格納される。これらのプレファレンスは異なるスキーマにリンクされている。例えば文書用に対して、スキーマは好みのカテゴリに基づいたものであってもよい。電子メールメッセージに対して、スキーマは好みのカテゴリ、作成者、又は添付ファイルに基づいたものであってもよい。これらは考えられる多数の例の中から２つを挙げたものである。ＵＰＳはＵＳＳに手作業で入力された情報に基づいて、意味ネットワークを注釈付加する。
サーバ通知マネージャ−サーバ通知マネージャ（ＳＮＭ：Ｓｅｒｖｅｒ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｍａｎａｇｅｒ）は、サーバ側の通知をバッチ処理しそれをユーザに転送する役目を持つ。好ましい実施の形態において、ユーザはエージェントのレベルでサーバ側の通知を登録する。各エージェントは照会結果の通知を発行する能力を持つ。サーバ通知マネージャは、照会結果のフィルタリング方法、及び電子メール、音声、ポケットベル、又はマイクロソフトドットネット警告通知サービス等の他の通知機構を経由して配信するためのフォーマット方法を決める。サーバ通知マネージャは、最後にユーザが通知を「読んだ」情報を管理する。これはユーザインターフェースを経由してクライアントから示されることが好ましい。ＳＮＭは、特定ユーザが最後に「読んだ」時以降、エージェント上に新しい情報がある場合にのみユーザに通知することが好ましい。
エージェントの発見−マルチキャストベースのエージェントの発見を使って、各エージェンシーはローカルのマルチキャストネットワーク上での存在を示すマルチキャストの告知を送信する。エージェンシー管理者はマルチキャストのＴＴＬを決める。本発明は周知のポート：９８７５とＴＴＬ：２５５でのセッションアナウンスメント プロトコル（ＳＡＰ）、又はカスタマイズ可能なＴＴＬを使った専有の告知ポートのどちらかを使うことが好ましい。ＳＡＰについての詳細は引用によって本明細書に組み込まれており、http://sunsite.cnlab-switch.ch/ftp/doc/standard/rfc/29xx/2974を参照のこと。
インフォメーションエージェントはＳＡＰ告知を受信するリスナ構成要素を含むことが好ましい。好ましい実施の形態において、告知はＸＭＬで送信され以下の情報を含む。
・ サーバのＩＤ（一意的な識別子である）
・ サーバのＵＲＬ（エージェンシーのＸＭＬウェブサービスへのＨＴＴＰのＵＲＬである）
・ 告知期間（Ｔ）−これは各告知の間の時間を示す。
・ 最後の告知と（エージェンシーの刻時機構上の）最後のエージェントの作成時刻以後に、エージェンシー内に新しいエージェントが存在するかどうか。
各エージェンシーはＸＭＬの告知を送信し、パケットを符号化するために前方誤り訂正（ＦＥＣ）、又は前方消去訂正を使う。これはドロップしたパケットに対してシステムを堅固にする。あるいはエージェンシーは、ＸＭＬ告知を（告知ごとに）連続的に数回送信するように設定することができる。
インフォメーションエージェントのマルチキャストのリスナは、ディレクトリのような意味論をセマンティックエンバイロメント マネージャに公開する。リスナは告知を受信するエージェンシーからＸＭＬの告知を全て集約する。更に各エージェンシーから最後に受信した告知をキャッシュに格納する。リスナはリンク先が存在しないリンク、又は非アクティブなリンクであると見なすエージェンシーにフラグで警告を出す。エージェンシーの告知期間よりも長い間、エージェンシーから何も連絡がなかった際に行われる。リスナはエージェンシーが非アクティブであるとのフラグを出す前に、数期間待つように設定することができる。これは（おそらくトラフィックが混み合っているために）ドロップした告知の場合を処理する。リスナは告知を受信するごとに、セマンティックエンバイロメント マネージャのエージェンシーのリストを更新する。
セマンティックエンバイロメント マネージャは定期的にリスナに新しいエージェントの有無を照会する。セマンティックエンバイロメント マネージャはエージェンシーのリストを調べて、アクティブな各エージェントに新しいエージェントの有無を確認する。セマンティックエンバイロメント マネージャはローカルで保持されるエージェンシーによる最後のエージェントの作成時刻と、エージェンシーの刻時機構に基づいた現在時刻でこの要求を修飾する。エージェンシーは応答して、最後のエージェント作成時刻の新しい値を又送信する。セマンティックエンバイロメント マネージャは、エージェンシーのエントリにこの値をキャッシュする。新しいエージェントが存在する場合、ブラウザはダイアログボックス経由でユーザに連絡し、その新しいエージェントを表示するかどうかユーザに確認する。
本発明は又、ピアツーピアのエージェントの発見を使ってエージェンシーの告知をサポートする。このモデルにおいて、告知は全てのクライアントが確認するディレクトリのサーバへ、又は標準のピアツーピア公開プロトコルを経由して直接クライアントへのどちらかで送信される。
図４７〜５３は、ＫＩＳによるエージェント管理の画面例を示す。図４７〜５０は、サーバ側エージェントビューとサーバ側エージェントを示すＫＩＳエージェンシー管理マネージャの画面例を示す。更に図５１は、ＳＤＧ（クロール）タスク、システムタスク（インファレンスエンジン等）、システムエージェント イーメール（受信トレイ等）、カレンダーと連絡先のＤＳＡ、及び（オブジェクト、意味論的なリンク、カテゴリ等の）全てのＳＭＳデータの表を管理する管理者ユーザインターフェースの要素を示す。図５２は、ＫＩＳエージェンシー管理マネージャ内の本発明の「サーバ特性」ダイアログの画面例である。ダイアログは、サーバ名、ディスプレイ名、ＳＭＳデータストア特性、（知識ドメインのパス等）ＫＤＭの特性、及びユーザのＤＳＡ特性のようなサーバ特性のサーバ管理者による設定方法を示す。図５３は好ましい実施の形態のＫＩＳエージェンシー管理マネージャにおける「サーバ スタティスティックス」ダイアログの画面例である。ダイアログは、サーバ側エージェント（スタンダードエージェントとブレンダー）合計数、サーバ側スタンダードエージェント合計数、サーバ側ブレンダー合計数、サーバ側エージェントビュー合計数、サーバ側エージェントの登録合計数、サーバ上に格納された情報オブジェクト合計数、意味論的なリンク合計数、サーバ（エージェンシー）上のユーザ合計数、及びユーザグループ合計数等の統計表示を示す。
3. ナレッジベース サーバ
ナレッジベース サーバ（ＫＢＳ）はＫＩＳの知識をホストするサーバである。大半のアプリケーションにおいて、ＫＩＳの多くの実現値が配置されるが、少数の（又は１つの）ＫＢＳのみ指定の組織に配置される。これはＫＢＳが再生可能だからである（ドメイン固有であるがデータに依存しない）。例えば、製薬会社は医薬品のオントロジで初期化された1つのＫＢＳを配置する可能性があるが、従業員の部門ごと、又は従業員グループごとに、数個のＫＩＳ設定を持つ。ＫＩＳは以下の構成要素を含むことが好ましい。
1. １つ以上の意味論的（知識）ドメインに対応する１つ以上のオントロジ。意味論的ドメインは意味論的ドメイン名を使って参照される。これは意味論的階層内のドメインパスを参照する。例としては、Industries.Technology、 Industries.Pharmaceuticals.LifeSciences、及び General.Sports.Basketball が挙げられる。これらの名前又はパスは又、上記で説明したように（インターネットのドメイン名等の）全世界で一意的に修飾されることができる。
2. サポートした意味論的ドメインに対応する1つ以上の分類法。これらの分類法はカテゴリ名の階層を含む。
3. テキスト又はＸＭＬの一部分とカテゴリ化が行われる意味論的ドメイン名を取得し、（０〜１０の尺度、又はできれば０〜１００の尺度の）カテゴリ化のスコアと共に、テキスト又はＸＭＬが属するドメイン内のカテゴリを返すカテゴリ化エンジン。
4. 新しくサポートされた意味論的ドメイン（及び対応するオントロジと分類法）を追加して、指定の意味論的ドメイン用のカテゴリを列挙し、テキスト又はＸＭＬデータのＢＬＯＢをカテゴリ化するためにＡＰＩを公開するＸＭＬウェブサービス。
5. ＫＢＳが知識を取得する別のＫＢＳを参照するＸＭＬウェブサービス。このモードではＫＢＳはプロキシとして機能する。ＫＢＳはプロキシとして機能をし、サポートされた意味論的ドメイン、オントロジ、及び分類法を別のＫＢＳから取得するように初期化することができる。
上記で説明したように、（ＫＤＭ経由の）ＫＩＳは指定の意味論的ドメイン用にカテゴリ化するためにＸＭＬオブジェクトをＫＢＳに定期的に送信する。
4. インフォメーションエージェント（意味論的ブラウザ プラットフォーム）
a. 概要
本発明のインフォメーションエージェントの好ましい実施の形態において、システムのクライアントは意味論的ブラウザの構成要素と意味論的なユーザ経験を提供するユーザインターフェースを含む。好ましい実施の形態において、インフォメーションエージェントは以下に挙げる上位レベルのサービスを提供する。
・ ユーザにローカル及び遠隔のインフォメーションエージェントを経由して、文脈に依存し時間に敏感な意味論的な情報取得の能力を与える。
・ ユーザが本発明のＸＭＬウェブサービスを通してエージェント経由で公開されたローカル及び遠隔のエージェンシー情報を発見できるようにする。この情報は文書、電子メール、電子メール配信リスト、人、イベント、マルチメディア、及び顧客等、周知の意味論的なクラスにカテゴリされることが好ましい。
・ ユーザが本発明のエージェントを経由して発見した情報の意味論的ビューを参照できるようにする。
・ ユーザがエージェンシーに情報を公開できるようにする。
・ ユーザが別のエージェンシーのエージェント上で発見した情報で、ハードドライブ、ローカルネットワーク、又は指定のエージェンシー上の情報と動的リンクを行えるようにする。これは動的な電子リンク、及びユーザ制御のブラウジングを円滑にする。
本発明のインフォメーションエージェントの利点は、ユーザがファイルシステムの名前空間から文書を開くのと類似の方法でエージェントを開くことである。インフォメーションエージェントは、情報の意味論的な「世界」を開く独自の環境を持つことになる。例えば、ＡＢＣ会社は社内の文書、電子メール等用のエージェントを持つ内部のＫＩＳエージェンシーを持つことができる。更に、サードパーティが業界レポート、産業イベント等の情報を保持するために、インターネット上のエージェンシーをホストしてもよい。本発明の好ましい実施の形態において、ＡＢＣ会社の従業員は、業務に関連する情報をインターネット上で発見するためだけでなく、ＡＢＣ会社の社内情報と、社外ではあるが同社と関連する情報を意味論的に関連付けるためにエージェントを開く。
b. クライアントの設定
好ましい実施の形態において、システムのクライアントはローカルだけでなく遠隔のエージェンシー上で発見した情報を意味論的にリンクできる。これはグローバルエージェンシー ディレクトリからのエージェンシー、（マルチキャスト又はピアツーピア公開システムを経由して公開された）ローカルエリア ネットワーク上のエージェンシー、及びエージェント発見を使用した、カスタムのエージェンシーディレクトリからのエージェンシーで構成された公開セマンティックエンバイロメントの使用を通して実現することが好ましい。クライアントの設定はエージェントとローカルのエージェンシーを持つ枠組みに基づくことが好ましく、履歴とお気に入りの比喩を本質的に統合させたローカルに格納したエージェントとフェイバリットエージェントを管理するセマンティックエンバイロメント マネージャを含むことが好ましい。セマンティックエンバイロメント マネージャは、セマンティックエンバイロメント ブラウザを経由して、ユーザに知識を表示するために、セマンティックエンバイロメント内の意味論的な照会文書を使う。クライアントの設定は又、（エージェンシーのリスト、エージェンシーのディレクトリ情報等の）エージェント発見の情報を含む。
c. クライアントの枠組みの仕様
概要−クライアントの枠組みの仕様は、インフォメーションエージェントユーザインターフェースのサービスインフラストラクチャを提供し、基本的なサービスとインターフェースを定義し、中核となるユーザインターフェースの構成要素を含み、インフォメーションエージェントのユーザインターフェースの主な基礎的要素に拡張性があり設定可能な環境を提供する。ここで本発明の好ましい実施の形態に従ったクライアントの枠組みの仕様を説明する。枠組みの中核は基本のサービス、設定、プレファレンス及びセキュリティの機構を定義する。中核となるユーザインターフェースの構成要素は、サーバとエージェントの設定、制御と呼び出し、及び意味論的ブラウザの枠組みのいくらかの設定をサポートする、ユーザインターフェースのサービスとモジュールを定義する。中核となるユーザインターフェースの構成要素は、ウィンドウズのシェル拡張子、及び関連付けられたユーザインターフェースとして実装される（以下で説明する）。意味論的ブラウザの枠組みは、基本的な照会と結果の管理サービス、及び結果表示用の枠組みを提供する。意味論的なオブジェクト提示に関連するユーザインターフェースの詳細は、デフォルトの表示サポートがあらかじめインストールされた「拡張子」として提供されていても、設定可能で拡張性があることが好ましい。意味論的ブラウザの枠組みは、（インターネットエクスプローラ等の）現在のウェブで使われる既存プラットフォームへの一連の動作拡張機能として実装され、サポートされるＸＭＬ、ＸＳＬＴ、ＨＴＭＬ／ＣＳＳ及びＤＯＭの機能の応用を支援することが好ましい。
文脈−クライアントの枠組みは、意味論的な照会のサポート、文脈に依存し時間に敏感な意味論的な処理、及び情報のリンク等を含む本発明の意味論的なサービスの構成要素上に形成される。クライアントの枠組みは、既存ツールと環境の文脈内でユーザに機能を提供する（インターネットエクスプローラ等の）プラットフォームの拡張機能とシェル拡張子として構築されることが好ましい。例えば、インフォメーションエージェントは、（ウィンドウズシェルを拡張し、標準のエクスプローラビューとユーザインターフェースのモデルを用いる）シェル拡張子として実装することができる。他の実施の形態においては、本発明は単独型の意味論的ブラウザのアプリケーション内で同様に応用可能である。
要求仕様−クライアントの枠組みの好ましい要求仕様は、柔軟性と拡張性に関する。これはより多くの情報オブジェクトタイプ、ユーザプロファイル等が存在するので、ユーザインターフェースが簡単に素早く応用できることを確実にする。必要条件には以下が含まれる。
・ 全ての組の照会を管理するためにスキンのサポートを提供する。
・ リスト、表、時刻指定のスライド等を含む広範囲のアプローチを可能にする。
・ スクリーンセーバー（又は同等物）のモードを提供する。
・ オブジェクトクラスと関連付けられるスキンのサポートを提供する。
・ 全てのクラスを処理できるデフォルトのスキンがあることを確実にする。
・ スキンはＸＳＬＴと同様に簡単でかつスクリプトのサポートを可能にし、可能性としては（適切なセキュリティ制限つきの）符号化をも可能にするべきである。
・ スマート、ダム、及びスペシャルの）エージェント、エージェンシー及びブレンダーを含む（エージェントツリー ビューを補足するために）結果ビュー内でセマンティックエンバイロメントの閲覧のサポートを提供する。
・ 構成要素間で十分に定義されたインターフェースを提供し、全ての通信が枠組みを経由して起こることと確実にする。
・ 枠組み全体で安定したセキュリティのモデルを提供する。
枠組みの中核
セマンティックエンバイロメント マネージャ（ＳＥＭ）−ＳＥＭはユーザのローカルのマシン上でエージェント、ブレンダー及びエージェンシーの作成、削除、更新及び参照を管理する。更にＳＥＭは、エージェンシーのマルチキャスト告知のリスン、（ＬＤＡＰ経由等で）エンタープライズのディレクトリ上にあるエージェンシーの参照、カスタムのディレクトリ上にあるエージェンシーの参照、及びグローバルエージェンシー ディレクトリ上でエージェンシーの参照を行う役目を持つ。
ＳＥＭは（エージェント名、記述、作成時刻、最終使用時刻、（スマート、ダム、スペシャル等の）エージェントタイプ、（情報タイプに基づいて作成されたエージェント用の）エージェントが表す情報オブジェクトタイプ、（コンテキストテンプレートに基づいて作成されたスペシャルエージェント又はエージェント用の）エージェントを表す文脈タイプ、エージェント属性、（フィルタリング／並べ替えのプレファレンスと他の提示体系を含む）エージェントのスキンを表すＸＳＬＴ、又は他のスクリプトファイルへの参照、（エージェントから要求がある場合の）通知情報と方法、及びエージェントのＳＱＭＬ照会へのバッファ、又はファイルパス／ＵＲＬを含む、システム上にある全エージェントのメタデータを格納する格納層を含む。インフォメーションエージェント（意味論的ブラウザ）は、ローカルのデータベース内、ウィンドウズレジストリのようなストア、又はローカルのファイルシステム上のＸＭＬファイルストア内に上記のエージェントのメタデータを格納することができる。
ＳＥＭはエージェントがフェイバリットエージェントであるかどうかを示すエージェントの属性も使う。更にＳＥＭは、お気に入りのエージェントではなく、（２週間等の）設定可能な時間制限よりも古いエージェントを自動的に削除する。
インフォメーションエージェントのシェル拡張子と（ツールバー及び「エージェントを開く」ダイアログ等の）他の構成要素は、ユーザインターフェースを経由してエージェントにエージェントの作成、削除、参照、更新、及び管理を提供するためにＳＥＭを用いる。
プレファレンスマネージャ−この構成要素は、プレファレンスに持続するためのサービスを提供することで全てのクライアント側プレファレンスを管理し、プレファレンスの共有又はローミングのサポートをするために必要に応じてサーバとの通信を行い、他の構成要素からプレファレンス値の設定と取得をサポートする。この構成要素は、関連付けられたユーザインターフェースだけでなく、もっと具体的なユーザインターフェース構成要素のプレファレンスを持つ。プレファレンスはサブ構成要素に分けられており、関連したクライアントのクラスプレファレンスを抽出化できる。これには以下が含まれる。
・ 中核となるプレファレンス−これにはユーザのプロファイルとペルソナ情報等の基本的な設定が含まれる。
・ スキンのプレファレンス−これも又希望のスキンをオブジェクトクラスとを関連付ける。希望のリストスキンをスクリーンセーバーのスキンも同様である。スキンに関連したプレファレンス設定が更に存在していてもよい。
この構成要素は又ローカルで利用可能な一連のスキンを管理する。ダウンロード可能なスキンはこの構成要素を通して管理されることが好ましい。
通知マネージャ−通知は指定のスマートエージェント上に新しい情報が利用可能であることをユーザに示す手段を提供する。ユーザは任意選択として通知をサポート又は提供できるように特定のスマートエージェントを設定（大半のスマートエージェントのデフォルトはオフである）することもでき、ユーザへの通知の表示方法も設定する。これらの通知は通知のユーザインターフェース構成要素によって表示される。
通知マネージャは背景、適切な一連のスマートエージェント用照会をポーリングする役目を持つ。ライブ情報マネージャは、結果ブラウザに類似のサービスを提供する平行する構成要素である。
通知マネージャは、通知用に印が付けられたスマートエージェントのリストを収集し、新しい情報を求めて関連付けられたサーバを定期的にポーリングする。「新しい」は「最後のポーリング [又は照会] 以後」と定義される。ポーリングが応答するごとに、通知マネージャが持続しなければならないエージェントに関連付けられたタイムスタンプのインジケータを含む。
通知マネージャの設定と関連付けられたユーザインターフェースは、エージェントツリー ビューとの連携で実装されることが好ましい。これは（各スマートエージェントの「通知」ポップアップメニューの選択肢等の）通知を可能にする。通知マネージャは、新しい結果が利用できる時にユーザに通知する代替方法をサポートしてもよい。選択肢には、エージェントツリー ビュー内のエージェント用の（太字、色付き等の）表示スタイル、確認メッセージダイアログ、音声通知、又は電子メール、ＩＭ又はＳＭＳ通知のようなもっと通常とは異なるなアクションを含む。
クライアント側セキュリティ−クライアント側セキュリティの課題は拡張コードとスキンに関連する。スキンはＸＳＬＴが好ましいが、スクリプトをサポートしてもよい。更に生成されたＨＴＭＬは、ＡｃｔｉｖｅＸの構成要素と動作への参照を含んでもよい。提示のサンドボックスは、スクリプト経由でスキンが潜在的に悪質なコードを実行するのを防ぐセキュリティ制限を含んでもよい。例えば、実装は（ＡｃｔｉｖｅＸ及びＤＨＴＭＬの動作を含む）無署名のコードを完全に不許可にしてもよい。
全てのクライアント側エージェンシーとの通信は、サードパーティがカスタムスキンを提供するためにカスタマイズする（スキン用の）公開されたインターフェースから非表示にすることが好ましい。この機能を主なクライアントランタイムの外側に孤立させることで、セキュリティが侵害される危険を減少することができる。
中核となるユーザインターフェースの構成要素
エージェントツリー ビュー−これはエージェントを制御し呼び出すために中核となるユーザインターフェースの多くをサポートするシェル拡張子のツリービューである。
セマンティックエンバイロメントの参照用のユーザインターフェース−これは、ユーザにセマンティックエンバイロメントの参照を可能にするユーザインターフェースを提供する。「「エージェントを開く」ダイアログ」がこの一例である。これは名前空間の階層ビューをも表示するエージェントツリー ビューを補足する（画面例を参照のこと）。
エージェントインスペクタ−これは特性の表示、又は個々のエージェント、ブレンダー、又はエージェンシーの編集（ユーザが作成したスマートエージェントの場合）を行うためのユーザインターフェースを提供する。
ブラウザのホスト−これは、エージェントツリー ビュー内のエージェント、エージェンシー、及びブレンダーのカスタムビューの提示を可能にする（インターネットエクスプローラのブラウザのランタイム等の）意味論的ブラウザの中核上での「ラッパー」であることが好ましい。独自のユーザインターフェースを持たないことが好ましいが、シェル拡張子とブラウザ枠組みとの間の橋渡しをする構成要素である。この構成要素は又、（ユーザが１つの「戻る／進む（次に）（Ｂａｃｋ／Ｆｏｒｗａｒｄ）」の履歴リストにのみ対応しなければならない場合に）シームレスな「戻る／進む（次に）」のユーザ経験を提供するために、特にナビゲーション（「戻る／進む（次に）」）の機構を含むウィンドウズシェルのユーザインターフェースで特定のブラウザ機能を調整する役割を持つことが好ましい。
中核となるプレファレンスのユーザインターフェース（ＵＩ）−これはセマンティックエンバイロメント、サーバ、ペルソナ及びエージェント管理、更に他の各種基本設定に関するプレファレンスのユーザインターフェースを提供する。これにはなるべく機能分野別に個別のシートに分けられたプリミティブ型の特性シートを含むことが好ましい。好ましい実施の形態において、これはタブ付きダイアログのユーザインターフェースであるべきである。
スキンのプレファレンスのユーザインターフェース−これはスキン管理に関するプレファレンスのユーザインターフェースを提供する。これは特性シートのダイアログが好ましい。利用可能なスキンのリストは選択用のリストとして表示されるべきである。このユーザインターフェースにより、ユーザは現在のスキンをデフォルトのスキンと区別して設定できる。これはユーザが現在のスキンをデフォルトに設定できることが好ましい。エージェント単位のスキンプレファレンス用に、これはユーザが現在選択の、又は開いているエージェントのスキンを選択できることが好ましい。
通知のユーザインターフェース−通知マネージャの設定に関連付けられたユーザインターフェースは、エージェントツリー ビューとの連携で実装されることが好ましい。通知マネージャは新しい結果が利用可能な時にユーザに通知する代替方法をサポートしてもよい。選択肢には、エージェントツリー ビュー内のエージェント用の（太字、色付き等の）表示スタイル、催促のダイアログ、音声での通知、又は電子メール、ＩＭ又はＳＭＳ通知のようなもっと通常とは異なるアクションを含む。好ましい実施の形態において、ユーザが上記の通知の体系等から選択できるように、ユーザインターフェースはタブ付きダイアログ（又は同等物）が含まれるべきである。
スクリーンセーバー−ユーザインターフェースは、シアターモードの表示で画面が満たされるスクリーンセーバーのような機能をする結果ブラウザへの特別なモダリティを提供することが好ましい。好ましい実施の形態において、特別なスキンはスクリーンセーバーのモードが使われるべきである。これらのスキンはより広い画面領域の活用できる動的表示を強調できるが、より大きなフォントとより間隔を置いたレイアウトを使うこともできる。
ブラウザの枠組み
結果ブラウザ−結果ブラウザは照会結果とローカルに開かれたリソース上の情報の表示をする役目を持つ。結果ブラウザは、照会マネージャから１つ以上のＸＭＬファイルを取得して、これらをオブジェクトのリストを表す単一のＸＭＬファイルにマージすることが好ましい。最初の手順としてそのリスト自体をフィルタリングする、又は並べ替えることもできる。構造としてのリストは、リストを処理する（可能性としていくらかのスクリプトを含むＸＳＬＴの変換シートの）特別なクラスのスキンによって変換される。リストスキンは、例えばリスト、表、又は時限シーケンス等の主なＤＨＴＭＬ等の構造を作成する。オブジェクトスキンは、各オブジェクトの実現値情報を表示するＤＨＴＭＬ項目を管理する。リストスキンは、（オブジェクトクラスをスキンにマッピングして）個々のオブジェクトスキンのディスパッチを処理できるが、結果ブラウザが単純化のためにスキンにクラスのデフォルトのマッピングを提供することが好ましい。
ユーザは指定の表示形式を望むことができ（リスト及びオブジェクトクラス用の）デフォルトのスキンを選ぶことができる。（ＳＱＭＬ等の）最初の照会は、（特にどのリストスキンの）どのスキンが使用されるべきかを示すパラメータを含んでもよい。これらは結果と一緒に結果ブラウザに渡される。結果ブラウザは、適用する適切なスキンを選ぶためにスキンマネージャの機能を使う。ユーザのプレファレンスとエージェント（作成者）のプレファレンスをどのように組み合わせて優先度を付けるかについては異なった規則を用いてもよい。
照会結果が個別の複数ＸＭＬファイルで構成される場合、結果ブラウザはシームレスなユーザ経験を提供するために、それらを単一のＸＭＬ文書にマージする必要がある。好ましい実施の形態は、追加的な結果の動的処理を提供する。この動的更新モードは、異なるテンプレート、又はＸＳＬＴのテンプレート内のスクリプトメソッドを使って実装されるのが好ましい。あるいは、リストスキンはユーザの文脈を妨げないで文書への追加の論理を管理するために、動作（又はローカルのランタイムの構成要素）を必要とするかもしれない。
照会マネージャ（又はクライアント側セマンティッククエリ プロセッサ）−照会マネージャは、情報の要求を実行しＸＭＬ結果を収集して（単数又は複数の）サーバとの通信を処理する役目を持つ。結果としてのＸＭＬは、ユーザへの提示のため結果ブラウザに渡される。
照会マネージャはスマートレンズ機能をサポートするサービスを提供することが好ましい。スマートレンズの要求が出されると、結果はＸＭＬとして返され結果ブラウザに渡される。その時指定のオブジェクト用スマートレンズの結果であることを示す印が付けられていることが好ましい。照会マネージャは照会要求を満たすために個々のサービスを提供する、以下のサブ構成要素を含むことが好ましい。
・ ＳＱＭＬ解釈プログラム−この構成要素は、可能性としてはリンクされたリソースと一緒に、渡したＳＱＭＬを一連の要求に分解しなければならない。各要求、又はリソースのリンクは、（ＨＴＴＰ、又は outlook: あるいは document:の数あるローカルの疑似プロトコルの１つ等）の関連したプロトコルでリソースを解決し、関連したプロトコルハンドラにディスパッチされる。指定のＳＱＭＬファイルは、ネットワークとローカルリソースタイプの混合が含まれていてもよい。
・ リソースハンドラのマネージャ−これはリソースハンドラ用に１か所に集中した登録機構であることが好ましい。これはプロトコルと疑似プロトコルをハンドラで関連付けて、リソースの要求のディスパッチを簡素化する最小限の層である。
・ リソースハンドラ−これは指定の「サーバ」からリソースをアクセスするための詳細をカプセル化する構成要素である。リソースハンドラは、リンクされたリソースの解決は行わない。これはＳＱＭＬ解釈プログラムの役目であることが好ましい（例えば、ＳＱＭＬ解釈プログラムは、すでに解決したリンクされたリソースを解決し、このハンドラへのリソースの要求の一部として、関連したメタデータを提供している）。リソースが意味論的ウェブのサービスである場合、構成要素は要求を組み込んでｈｔｔｐ経由で発行することが好ましい。リソースが（document:又は Outlook: resource等の）ローカルのリソースである場合は、そのリソースのハンドラは直接リソースを取り扱う。文書用に、リソースハンドラは文書（a file:URL）をメタデータを抽出するために意味論的な意味の抽出、集計、カテゴリ化のエンジンに渡す。電子メール用に、リソースハンドラは交換サーバ、又はローカルの．ＰＳＴファイルからメッセージを抽出する。ここで留意すべきは、ローカルのリソース上にリンクがある場合、ローカルのリソースハンドラは結果を意味論的な関連性のためにフィルタリングする必要があることである。これは効率性の面からハンドラに特化したものであってもよいが、集中した汎用関連性エンジンは大半の場合にサービスを提供する。
・ 関連性エンジン−これは関連性のためにオブジェクトを比較する論理を収集する場所である。比較は関わるスキーマの混合に依存することが好ましいが、そうでなければ２つのオブジェクトがある場合には、簡単な操作で関連性尺度を提供する。
フィルタリング／並べ替えのマネージャ−フィルタリング／並べ替えのマネージャはフィルタの適用をサポートし、結果ブラウザに提供された結果のリストの並べ替えを行う。フィルタリング／並べ替えのマネージャは、現在の設定用ユーザプレファレンスを取得するために、フィルタリング／並べ替えのプレファレンス構成要素のサービスの適用を利用する。この構成要素の主な機能は、一般のプレファレンス、エージェント単位のプレファレンス、及び実際の結果内に定義された設定（これはサポートされない可能性がある）を解決することである。この構成要素はユーザが現在適用のフィルタ処理と並べ替えを変更する場合に、フィルタリング／並べ替えのプレファレンスによって通知される。関連したユーザインターフェースは（右側ペインのビュー等の）シェル拡張子と関連したツールバーの一部であるが、機能の適用は結果ブラウザの領域で行われ、その制御は概して間接的である。
レンズモード−スマートレンズが呼び出されると、結果ブラウザはユーザが選択するオブジェクト用レンズの要求（照会）を生成する必要がある。照会は非同期なので、ユーザが多種のオブジェクト用にスマートレンズ照会を選択して、結果が返されと同時に表示できる。この目的のユーザインターフェースはスマートレンズアイコン用に所要面積をいくらか控えておくことが提案される。スマートレンズモードで、ユーザがスマートレンズアイコン上をクリック（又はマウスカーソルを合わせる）と、照会が発行され、アイコンは照会が進行中であることを表示するように変わる。結果が返されると、これらは結果ブラウザとスキン内の専用のスマートレンズテンプレートで処理され、オブジェクトのスマートレンズアイコンは結果が利用可能であることを表示するように変わる。もう一度アイコン上をクリックする、又はマウスカーソルを合わせる、スマートレンズの結果がスキン固有の方法で表示される（スマートレンズペインのユーザインターフェース例を参照のこと）。照会が素早く返されると、全体の機能がその上でマウスカーソルを合わせるたり、又はシングルクリックしたりすることによって起動されたポップアップのように感じられることが好ましい。
ディープインフォメーションのビュー−ディープインフォメーションが最初の結果で利用できない場合、この構成要素は関連照会を生成する。照会は非同期であることが好ましい。結果が結果ブラウザに返されると、（各スキン用に特別なディープインフォメーションのテンプレートを使って）適切なスキンを通して処理され、その結果生じるＨＴＭＬは関連オブジェクトで結果の文書の中に組み込まれる。結果ブラウザが結果を組み込んだ場所を認識するため、スキーマの主要スキンはオブジェクトのためにＨＴＭＬでディープインフォメーション要素に挿入する。（最初の結果の一部として、又はディープインフォメーション照会への対応としてのどちらかで）ディープインフォメーションが利用可能な場合、スキンは直接表示するか、又はその存在を示し、いくらかのスキンで定義されたユーザインターフェースはユーザにその表示を（ポップアップウィンドウ等で）可能にする。
文脈情報マネージャ−結果ブラウザに現在表示されているオブジェクト用に、特定の通知はデフォルト設定で提供されることが好ましい。以下のような新しい情報、又は付加的情報の２つのクラスがユーザに提供される。
1. ユーザが最初の要求を出してからサーバに追加された付加的な結果。これは見出し又はアクティブな電子メールのスレッド等に特に有用である。結果はビューに新しいオブジェクトを挿入することで結果ブラウザによって処理される。
2. ユーザに興味のあるコンテキストテンプレートと関連情報。これは特定のオブジェクトを文脈として用いて（スマートエージェント、スペシャルエージェント、ブレンダー、又はエージェンシーの）固有のエージェントへの付加的な照会によって生成される。結果は、照会から返されたＸＭＬを処理し、結果としてのＨＴＭＬをそのオブジェクト用の既存ＨＴＭＬに挿入することによって、ディープインフォメーション ビューとスマートレンズモードの結果が処理される方法に類似したやり方で処理される。スキンは表示機構とユーザインターフェースを制御する。関連情報の例としてオブジェクトに関連付けられた「最新ニュース」がある。
スキンマネージャ−リストスキン、オブジェクトスキン、及びリストスキンとオブジェクトスキンとの間の従属関係用のユーザプレファレンスを管理する（特定のオブジェクトスキンは、指定のリストスキンにのみに意味を成す可能性がある）。スキンマネージャは又、どれくらい画面の所要面積が必要であるか、又は最も適するモダリティモダリティ等の、スキンの制約を示す各スキンに対するパラメータを管理する。画面とウィンドウのサイズの一連の制約、及びモダリティ、アクセスのし易さ、言語その他の制約を考慮してスキンを選択するために、結果ブラウザを支援するかなりの量のインテリジェンスが組み込まれていることが好ましい。初期版は非常に単純であることが予想される。
スキンテンプレート−これはスキンの構造と結果ブラウザ内からの適用方法を記述する。スキンは結果のＸＭＬを、ＸＨＴＭＬに（及び／又はＳＶＧ等の他の言語）、又はフラッシュＭＸ及びアクションスクリプトの専有の提示プラットフォームに変換するＸＳＬＴのテンプレートが好ましい。テンプレートはＣＳＳスタイリング向けのようなスタイリング情報を挿入することもできる。その結果としての提示コード（ＸＨＴＭＬ等）は、セキュリティのためにコードの包含を制限することができる。結果ブラウザ内枠組みのコードがスキンを呼び出す。好ましい実施の形態は以下のスキンクラスを含む。
・ リストスキン（又はレイアウトスキン）−リストスキンは、照会から返されたオブジェクトのリストをある全体の提示構造に変換するのに使われる。これは単純なリスト、表、又は時刻指定のスライドのシーケンスであってもよい。リストスキンは、関連した提示形式を定義する制約内で動作する一定のスキンのみサポートするかもしれないが、スキーマ、又はオブジェクトに特定されない。例えば、表のレイアウトを定義するリストスキンは、小さい長方形の形式で情報を作成できるオブジェクトスキンを要求、又は選ぶかもしれない。
・ オブジェクトスキン−オブジェクトスキンはスキーマ固有で、指定の情報オブジェクトタイプ（又は情報のクラス）の個々のオブジェクトの提示を生成する。（いくらかの詳細をおそらく省略することによって）ある範囲の派生クラス、又はサブクラスのデフォルトのスキンとして機能する汎用スーパークラス（又は他のスーパークラス）用のスキンを定義することが可能である。
・ 文脈スキン−文脈スキンは特定のコンテキストテンプレートに結合しており、そのテンプレートで示される文脈を最も効率的に伝達する提示を生成する。
・ ブレンダースキン−ブレンダースキンはブレンダーからの結果を表示するように設計されている。これらのスキンはユーザに、ブレンダー内に含まれるエージェントを経由して、情報オブジェクトタイプを経由して、又は全ての結果が１つのソースから来たように表示するマージされたビューを経由して結果を表示することを可能にすべきである。
スキンは（ブラウザコア自体にあるイベントによって静的に、又は動的にパラメータとして渡された）制約を処理することで、モダリティと提示の表示領域等の制約をモデルにすることが好ましい。これはリストスキンが容認できるオブジェクトスキンを１つだけ特定しなければならないという制限を課すことでサポートされることが好ましい。別なアプローチにおいては、オブジェクトスキンは指定のリストスキン用に設計することができ、結果ブラウザ／スキンマネージャは現在のリストスキン用にオブジェクトスキンを選択する。
リストスキンの詳細−ユーザは現行ビュー用に単一のリストスキンを選び、それをデフォルトにすることができる。リストスキンは個々のエージェントと関連付けてもよい。その場合汎用デフォルトは上書きされる。結果ブラウザは結果のリストを処理するためにリストスキンを呼び出すが、リストスキンは実際に個々のオブジェクトを処理しないことが好ましい。それにより（シーケンスで時限エントリ、又は表内のセル、あるいはリスト内の項目等）の枠組みの提示におけるオブジェクト単位の実現値がある程度作成され、それからオブジェクトスキンは詳細のデータを埋める。
オブジェクトスキンの詳細−オブジェクトスキンは特定のスキーマをＸＨＴＭＬに変換する。ディープインフォメーションやコンテキストテンプレートの情報のような非同期の照会結果のサポートは、照会結果のＸＭＬ上の（ＤＯＭを通した）結果ブラウザから関連したテンプレートを呼び出し、それから結果として生じるＸＨＴＭＬを、ＤＯＭインターフェースを通して結果文書に挿入することで提供される。オブジェクトスキン内には、以下のようないくつかの個々のテンプレートが存在することが好ましい。
・ 主要スキーマのテンプレート−これはデフォルトビュー用に、ＸＨＴＭＬを生成する主要部分である。これはディープインフォメーション、スマートレンズ情報、コンテキストテンプレートの情報コンテンツ、及び関連したビュー上でのユーザ制御を提供する任意スクリプト用ラッパーを作成しなければならない。
・ ディープインフォメーションのテンプレート−このテンプレートはディープインフォメーション用メタ情報を取り扱う。これは最初の結果で提供されたインラインの詳細情報を呼び出してもよいし、又は非同期で要求したディープインフォメーション処理を呼び出してもよい。どちらの方法でも、何らかの形でＸＨＴＭＬを生成することが好ましく、それがディープインフォメーション用にラッパー要素の下に挿入される。挿入は可能性としてはインラインの詳細情報用にＸＳＬＴで発生し、ディープインフォメーションの照会結果にはＤＯＭを挿入して有効になる。
・ 文脈情報のテンプレート−このテンプレートは文脈情報の照会結果の結果情報を処理する。それは何らかの形でＸＨＴＭＬを生成し、ライブ情報用にラッパー要素の下に挿入される。この挿入はディープインフォメーションの照会結果用にＤＯＭを挿入して有効になる。
・ スマートレンズの情報のテンプレート−このテンプレートはスマートレンズの照会結果用の結果情報を処理する。これは何らかの形でＸＨＴＭＬを生成し、ライブ情報用にラッパー要素の下に挿入される。この挿入はディープインフォメーションの照会結果用にＤＯＭを挿入して有効になる。
好ましい実施の形態において、テンプレートは（同じオブジェクト用であっても）ＸＨＴＭＬの他のコンテンツを修正できないので、ディープインフォメーション、ライブ情報、又はスマートレンズの結果がいつ利用可能なのかを示すユーザインターフェースの変更を調整するのは結果ブラウザ次第である。枠組みは結果ブラウザが必要に応じて検索や修正できるように通常の名前や要素タイプを持つために（又整合性のためにも）特定アイコンの使用が必要となる。更に、結果ブラウザは状態の変更を示すために、イベントを作成し発生させることができる。テンプレートで生成されたスクリプトはこれらのイベントに対応して希望に応じた関連情報を表示できる。
デフォルトのスキン−好ましい実施の形態において、一連のデフォルトのスキンが提供される。これは基本的なオブジェクトクラス用のスキンと、照会結果の多様なビューを可能にする、小さい１組のリストスキンが含まれることが好ましい。望ましいリストスキンには以下が含まれる。
・ （ウィンドウズエクスプローラの詳細ビューのような）詳細リストのビュー
・ 表形式のアイコンビュー（これも又ウィンドウズエクスプローラのアイコンビューのようなものであるが、幾分豊かである）
・ 時刻指定の提示ビュー
e. クライアントの枠組み
好ましい実施の形態において、文脈と意味を持つ情報を表示するために、システムのクライアントには、シェル拡張子、プレゼンタ、及びプレゼンタが使用するスキンを含む。
シェル拡張子−エクスプローラのシェル拡張子は、ウィンドウズシェルをカスタムコードで拡張するマイクロソフトウィンドウズのソフトウェア構成要素である。シェル拡張子はアプリケーションがシェルをカスタムクライアントとして使用することを可能にし、又デスクトップ、ファイルシステム、インターネットエクスプローラ等とのクリーンな統合等のサービスを提供する。デフォルトのシェル拡張子例として、「マイドキュメント」、「マイコンピュータ」、「マイネットワーク」、「ごみ箱」、「インターネットエクスプローラ」が挙げられる。
本発明の好ましい実施の形態でのシェル拡張子の使用は、次のようないくつかの利点を持つ。
1. 現在知識労働者が情報を閲覧している方法で、シームレスに統合されたユーザ経験を提供するのに非常にクリーンな方法を提供する。言い換えれば、これは専有クライアントを開発する必要性を未然に防ぎ、マイクロソフトのインターネットエクスプローラ、「マイドキュメント」等で非標準な統合を可能にする。
2. 現在のウェブを取り入れて、現在のウェブのコンテンツを本発明のインフォメーションナーバス システムへ転送するための移行パスを提供する。例えば、ユーザが（マイクロソフトエクスプローラ経由で）ハードドライブから、又は（インターネットエクスプローラ経由で）インターネットから本発明のシェル拡張子上の遠隔エージェントに文書をドラッグ＆ドロップすることを望んでいる。これは専有クライアントでは困難で非直感的である。それにもかかわらず、本発明はウィンドウズ以外のオペレーティングシステムとパーソナルコンピュータ以外のデバイス用オペレーティングシステム上で、専有クライアント、又はシェル拡張子の同等物の移植性を意図する。
本発明のシェル拡張子はユーザのセマンティックエンバイロメント（履歴、お気に入り、及びその他のビュー等の）ビューを提供する。好ましい実施の形態において、シェル拡張子は以下を提供する。
ユーザが意味論的ブラウザのセマンティックエンバイロメント上にあるエージェント、文書、フォルダ、又はアドレスを開けることができる。エージェント用に、クライアントはユーザに意味論的ブラウザのセマンティックエンバイロメントの閲覧を可能にするカスタムの「エージェントを開く」ダイアログボックスを表示する。これには、ユーザのマイエージェントリスト内にあるエージェント、グローバルエージェンシー ディレクトリ上のエージェンシー、（マルチキャスト経由告知で）ローカルエリア ネットワーク上にあるエージェンシー、ユーザが設定した任意でカスタムのエージェンシーディレクトリ上にあるエージェンシーを含まれることが好ましい。[INSERT RELEVANT SCREEN SHOTS ON UI]エージェントを開くと、クライアントがエージェントの照会結果を表示することになる。文書を開くと、文書オブジェクトタイプのスキーマと一致する文書のＸＭＬ形式メタデータを開く。フォルダを開くと、ファイルシステムのフォルダ用のＸＭＬ形式メタデータを開く。ユーザはフォルダ自体を経由して、フォルダの直接すぐあるコンテンツ、又は深部にあるコンテンツを開くことができる。アドレスを開くと、ユーザがクライアントの枠組みで開く任意アドレスを入力できる。
1. これは、（文書用のＸＭＬ形式メタデータを開く）ＵＲＬ、ファイルシステム上にある文書、エージェント、又はオブジェクトを含む（以下の「ＵＲＬの命名規則」を参照のこと）。エージェントの場合、エージェントのＵＲＬは、「Agent://<Agent name>@<Agency name>.<domain name>」のように入力されるのが好ましい。これはＨＴＴＰのＵＲＬの「http://<URL>」 という命名規則に似ている。この場合「アドレスを開く」の選択肢で、任意のアドレスを開くことができるように「Agent:// 接頭辞」が必要である。「エージェントを開く」の選択肢の場合、ユーザは接頭辞を追加する必要がないことが好ましい。つまりクライアントの枠組みは接頭辞を含むように自動的にＵＲＬを正規化（カノニカライズ）する。これはユーザが現在のウェブに「http:// 接頭辞」で修飾しないで「www.foo.com」を入力できることと似ている。
クライアントはユーザにマイクロソフトのアウトルック．ＰＳＴファイルのような他のオブジェクトを開くことができるようにすることを意図する。
2. ユーザがユーザ状態をサポートする指定エージェンシー上で、エージェントから／エージェントへ参照すること、会員登録をすること、会員登録を解除することができる。
3. ユーザがマイエージェントのリストに呼び出されたエージェント又は意味論的な照会結果を格納できる。
4. ユーザはブレンダーの作成ができ、（ドラッグ＆ドロップを経由することも含めて）エージェントをブレンダーへ及びブレンダーから追加及び除去ができる。
5. 最後に確認してから、（グローバルエージェンシー ディレクトリ、ローカルエリア マルチキャストネットワーク、又は任意でカスタムのエージェンシーディレクトリ等の）エージェンシーのディレクトリ上に新しいエージェンシーがある場合にユーザに通知する。
6. 最後に確認してから、ある特定のエージェンシー上に新しいエージェントがある場合ユーザに通知する。
7. セマンティックエンバイロメントにあるオブジェクトの意味論的な関係照会へのドラッグ＆ドロップのアクセスを提供する。シェル拡張子によって、ユーザはエージェントを表現するシェルフォルダに（ローカルドライブ、ネットワークコンピュータ、イントラネット、又はインターネットのどれかで）セマンティックエンバイロメントから文書をドラッグ＆ドロップできる。これは文書のメタデータを引数として、指定エージェンシー用にＸＭＬウェブサービスへの遠隔手続き呼び出しを起動させる。
8. システムのクリップボードにコピーされたオブジェクトに、「ペースト」のアクセスを提供する。本発明ではユーザが、後でのアクセス用に任意のオブジェクトをコピーできるためにシステムのクリップボードを用いる。更にクリップボードではユーザに、（アウトルックからの電子メールの項目等の）マイクロソフトオフィスのアプリケーションのような他のアプリケーションからのオブジェクトのコピー、マルチメディアアプリケーションからのオブジェクトのコピー、及び任意のアプリケーションからのデータのコピーができる。
9. ユーザはエージェントをスマートレンズとして選択できる。スマートレンズではユーザは、エージェントからの内容に基づいた結果ビュー内でのオブジェクトの表示、又はシステムのクリップボードへコピー可能な任意のオブジェクトの表示ができる。例えば、通常、文書オブジェクトは結果ビュー内にあり、ユーザがオブジェクトを表現するリンク上にマウスカーソルを合わせると、オブジェクトメタデータが表示される。しかしながら、（例えば、結果シート上にペーストすることによって）スマートレンズが選択されて、ユーザがオブジェクト上にマウスカーソルを合わせると、スマートレンズ内のオブジェクトとカーソルの下のオブジェクトとを関連付ける情報が表示される。例えば、ユーザが People.Research.All をクリップボードにコピーしてスマートレンズとしてペーストして、次に文書上にマウスカーソルを合わせると、メタデータは「この文書のエキスパートを１５人 People.Research.All で発見する」と吹き出しポップアップで表示することができる。「この文書を書いた可能性がある人を3人発見する」と「People.Research.All にある人によって投稿されたこのオブジェクトに関する電子メールメッセージを７８件発見する」が他の例として挙げられる。ユーザは吹き出しポップアップのメタデータ内リンクのどれを呼び出しするかを決める。他の実施の形態においては、ポップアップはサイドバーで表示されて吹き出しは必要としないものがある。スマートレンズがクリップボード上にペーストされると、シェル拡張子はシステムと通信して、選択されたエージェントの名前が反映されるようにマウスカーソルを変えることが好ましい。スマートレンズはクリップボードからコピーされるので、グローバルな範囲を持つことが好ましい。言い換えれば、例えばウィンドウズエクスプローラとインターネットエクスプローラの全ての実現値がスマートレンズを「見て」そのアクションに応対する。好ましい実施の形態において、（エージェント又は他のオブジェクト等の）クリップボード上にある現在のオブジェクトに適用するインフォメーションエージェントのツールバーにスマートレンズツールが存在する。デフォルト設定では、リンクがいったんシステムでクリックされると、スマートレンズのツールは選択解除される。ユーザはスマートレンズを「固定」できることが好ましい。スマートレンズが固定されると、スマートレンズはユーザが明示的に選択解除するまでアクティブの状態を保つ。好ましい実施の形態において、スマートレンズを固定するには、ユーザはツールバー上で「スマートレンズとしてペーストして固定」のツールを選択する。
10. ユーザはシェル拡張子からエージェントの結果を「切り離して」、デスクトップのドッキングビューに表示できる。このビューにおいて、エージェントの結果ブラウザウィンドウは意味論上におけるティッカー（電子掲示板）の役割を果たす。この機能ではユーザが他の仕事を引き続き行いながら意味論的情報を常に表示できる。
11. ユーザはエージェントをスクリーンセーバーとして使用できる。
12. ユーザはグローバルエージェンシー ディレクトリ上の利用可能なスキンの閲覧、及び呼び出しができる。
プレゼンタ−プレゼンタは、意味論的な照会をスクリプト（又は他のプラグイン）から取得し、ＫＩＳエージェンシーのＸＭＬウェブサービスに渡す（ブラウザのプラグイン等の）一組のローカル構成要素である。本発明は意味論的な照会結果を変換し、ユーザへの最終的な提示用にＸＭＬを他の動作又はスクリプトに渡す。
好ましい実施の形態において、プレゼンタはＳＱＭＬファイルでシェル拡張子によって呼び出される。システムはＸＭＬウェブサービスのディレクトリと通信することが好ましい。システムはＳＱＭＬファイルを解決して（ＳＱＭＬファイル内で参照されたエージェンシー上のＸＭＬウェブサービスを経由して）ローカルに、又は遠隔に情報源を持つＸＭＬ情報を開くために呼び出しを起動する。あるいは、エージェントのＵＲＬがシステムに渡されると、プレゼンタはエージェントがホストされるエージェンシーのＸＭＬウェブサービスへの呼び出しを経由して起動することでＵＲＬを直接開く。好ましい実施の形態において、システムは適切なメソッドを適切な意味論的なオブジェクトタイプで呼び出す。デフォルトの意味論的なオブジェクトタイプの例は、SEMANTICOBJECTYPEID_EVENT、SEMANTICOBJECTTYPEID_EMAILMESSAGE等で、ヘッダファイル（semanticruntime.h）内で定義される。好ましい実施の形態は RegisterSemanticObjectType のＡＰＩを経由して新しい意味論的なオブジェクトタイプの登録を可能にする。エージェンシー上のこの意味論的な照会プロセッサは、意味論的なオブジェクトタイプをフィルタとして用い適切なＸＭＬの結果を返す。
好ましい実施の形態において、本発明によるスキン（以下を参照）は（ＸＭＬウェブサービスからの途中で）枠組みから返されたＸＭＬをＤＨＴＭＬに変換するために、ＸＳＬＴ（及び／又はスクリプト）を用いる。シェル拡張子ではユーザが現在の照会用の新しいスキンを選択できる。
スキンはオブジェクトタイプ固有で、（スペシャルエージェント用に）コンテキストテンプレート固有、又は（ブレンダー用に）ブレンダー固有であることが好ましい。スキンは又、エージェントの意味論的ドメイン名／パス、又はオントロジに基づいて、及びユーザのペルソナ、状態、場所等の他の属性に基づいてカスタマイズできる。各エージェントはデフォルトのスキンを使ってエージェンシー上で設定される。本発明は更に（グローバルエージェンシー ディレクトリ上等の）ルートエージェンシー上に公開することができるカスタムスキンを意図する。クライアントは宣言されたエージェント用のエージェンシー、又は（グローバルエージェンシー ディレクトリ等の）中央サーバのどちらかからスキンをダウンロードして、現在のビューに適用することが好ましい。クライアントはエージェントのスキンを無視するため、又はユーザインターフェースの一部分に限定するためにユーザプレファレンスを含むこともできる。
（オブジェクトスキン、リスト／レイアウトスキン、文脈スキン、ブレンダースキン等の）スキンタイプのほかに、好ましい実施の形態では、スキンは以下のようにカテゴリ化される。
・ 設計テンプレートスキン
・ 色テンプレートスキン
・ アニメーションテンプレートスキン
意味論的なスキンは、切り離し（上記を参照）、又はスクリーンセーバーとして表示される場合を除いては、対話型が要求されることが好ましい。各スキンではユーザが「意味論的なビュー」内での特定箇所の検索ができる。例えば、スキンが初めに最初の２５項目のみを表示するとすれば、ユーザが次の２５項目の検索、早送り、巻き戻し等ができるように、スキンはシークバー（又は他のユーザインターフェースの機構）を持つ必要がある。スキンによっては「リアルタイムモード」の選択肢を持つものがある。このモードではスキンは、（プル経由で）ＸＭＬウェブサービスから新しいオブジェクトを継続的に取得する。スキンは希望のオブジェクトのスキーマに基づいて、新しい情報用のＸＭＬウェブサービスをポーリングする役目を持つ。好ましい実施の形態において、エージェンシーはスケーラビリティの理由でクライアント固有の状態を全く保持しないので、クライアントへの通知は行われない。
スキンはリアルタイムモードを含むこともできる。これらのスキンは優先度に基づいてオブジェクトを（表示する、並び替える、又は強調表示する等の）循環して繰り返さなければならないので知的であることが必要である。例えば、エージェンシーに新しいオブジェクトが掲示されたことを示す情報をプレゼンタが中継すると、スキンは直ちにこれを表示／並び替え／強調表示して、残りのオブジェクトの提示を続ける。プレゼンタは並び替えを判断して、多種の並べ替えとフィルタ設定からスキンはダイナミズムを処理する。これは意味論的な提示がリアルタイムで発生しているような認識を生み出す。好ましい実施の形態において、これはユーザがスキンを使ってアクセスできる新しいデータが存在する場合に起こる。リストが時刻で並べ替えられている場合、リアルタイムの提示ではユーザインターフェースが対話モードにジャンプしてしまうのでユーザを困惑させることになりかねる。（スクリーンセーバーモード等の）いくつかのモードにおけるユーザプレファレンスの選択肢は、（リストの一番上に新しいデータが挿入されると、並べ替えたリストの一番上にスクロールする等）その新しいデータを表示するためにスキンを自動的にリセットする。
他の実施の形態においては、スキンは利用可能な提示ウィンドウの分量に基づいて、提示をカスタマイズするように設計されている。例えば、スキンは提示ウィンドウが比較的小さいと、フェードインとフェードアウトを使って情報を表示することで、静的モードから動的モードに変更することができる。スキンは予期されるレベルのユーザの対話に応じて、モーダルであることが好ましい。例えば、スクリーンセーバーはブラウザとは異なる動作する。同様にドッキングビューは（小さいだけでなく、ユーザの対話の焦点ではなく背景ビューの１種類と見なされるので）違う。ビューが最小化、又は非表示されている場合、（特に新しい情報を示すために）代わりのモードが使われてもよい。その例は音声通知、確認メッセージのような警告、スタートバーの表示、及び（アウトルックの通知のような）点滅が挙げられる。エージェントは、電子メール、テレフォニー又はインスタントメッセンジャー（ＩＭ）による通知の送信に使用してもよい。他の実施の形態においては、本発明は（イベントのカレンダー用にＨＴＭＬ自動コンテンツ作成等）ウェブサイトに掲示するエージェントを意図する。
あるいは、スキンは視聴覚情報を生成することもできる。例えば、音声合成のスキンは電子メールオブジェクトを読み上げることができる。この機能は身体障害を持つユーザ用、及びオートピーシー（Ａｕｔｏ ＰＣ）のユーザ用だけでなく他のユーザ向けにも大きな潜在的価値を持つ。
好ましい実施の形態において、スキンの枠組みは以下のサービスを公開する。
1. ＳＱＭＬベースの意味論的な照会を開くメソッド。これはローカルのＳＱＭＬ文書、エージェント等であり得る。
2. エージェントのＵＲＬディレクトリを開くメソッド。
3. インフォメーションエージェントのセマンティックエンバイロメントを参照するメソッド。
4. カスタマイズ可能なクリップボード形式を使ってシステムのクリップボードとインターフェースで接続するメソッド。
5. 指定の照会用又は指定の意味論的なクラスＩＤ用に現在のスキンを持続するメソッド。
スキン−上記で提示したように、スキンはエージェント単位でユーザ経験をカスタマイズするのに用いられる提示テンプレートである。好ましい実施の形態において、スキンは中央サーバにホストされるＸＳＬＴのテンプレート及び／又はスクリプトである。本発明によるスキンは、（プレゼンタの表示、音声合成、プラグイン経由の構造化ベクトルグラフィック（ＳＶＧ）等の）ＸＨＴＭＬ＋ＴＩＭＥコードを生成し、多種のシステムのサービスにアクセスすることが好ましい。好ましい実施の形態において、スキンは以下の機能をサポートする。
1. 表示されているオブジェクトのＸＭＬスキーマに対応するフィールドの一部分、又は全てを表示する。スキンはユーザに返された組の中でオブジェクトを一意的に区別する方法、又はファイル名、ＵＲＬ、又は（人用の）個人名等の従来のアクセス方法を提供することもできる。
2. オブジェクトがホストのエージェンシーによって理解されたかを示すユーザインターフェースを表示する。各オブジェクトはこの情報を示す「理解済み」フィールドを含むことが好ましい。
3. 意味論的なオブジェクトタイプの SEMANTICOBJECTTYPE_OBJECT 用に、スキンは生のオブジェクトメタデータ、又は生のオブジェクトを表現するクラス固有のオブジェクト用ＸＭＬスキーマのメタデータを表示することもできる。生のオブジェクトを参照する照会用クラス固有のＸＭＬスキーマを表示するスキンの場合は、スキンは異なるペインでクラス固有の情報を表示するために「スマートで」なければならない。これを実現する好ましい方法は、フレーム、タブ付きボックス、又は他のユーザインターフェースの技術を用いる。全ての意味論的な照会が生のオブジェクトを指すので、スキンは（単に生のオブジェクトを返す） SEMANTICOBJECTTYPE_OBJECT のフィルタで照会を読み込むか、又は必要なオブジェクトタイプＩＤを読み込むかのどちらかが好ましい。好ましい実施の形態において、多くのクラスにおける生のオブジェクトでオブジェクトリストの提示を用意するために、スキンはまず以下を行うべきである。
・ オブジェクトの照会を取得する。
・ 各意味論的なオブジェクトタイプには、指定のオブジェクトタイプに対してエージェントリソース内にオブジェクトが何個存在するかを判断する。これはエージェントのＵＲＬと（電子メール、文書、イベント等の）オブジェクトタイプＩＤ名を引数として持つ、エージェンシーのＸＭＬウェブサービスのメソッド GetNumObjectsOfClassInAgent を呼び出すことで取得されるのが好ましい。ＸＭＬウェブサービスは、オブジェクトタイプＩＤフィルタの条件を満たすエージェント内にあるオブジェクト数を返す。
・ エージェントの照会に何タイプのオブジェクトがあるかによって、スキンはオブジェクトタイプ数に適切なフレーム、又は他のユーザインターフェースを表示する。好ましい実施の形態において、スキンがオブジェクトタイプ固有のメタデータを読み込む準備ができると、エージェントのＵＲＬと意味論的なオブジェクトタイプを引数として持つ、エージェンシーのＸＭＬウェブサービスのメソッド ExecuteSemanticQuery を呼び出す。
4. ユーザがオブジェクト上にマウスカーソルを合わせると、更に多くのオブジェクト用のメタデータが表示できる。
5. スマートエージェントのスマートレンズが選択されると、本発明のインフォメーションエージェントは、スマートレンズにあるオブジェクトをマウスの下にあるオブジェクトにマッピングする文脈上のメタデータを表示する。１つの実施の形態において、スマートレンズはプレゼンタ内で表示されたオブジェクトに適用する。他の実施の形態においては、本発明はスマートレンズが（マイクロソフトオフィスのアプリケーション、デスクトップ等の）他のアプリケーションにおいて起動できる。これはマウスがシステムのどこを動いているときもスマートレンズアプリケーションを呼び出して、マウスを追跡するシステムフックのインストールを必要とする。「フック」が全てのマウスのイベントに呼び出されて、フックは又マウスをキャプチャする。スマートレンズは二者択一的に、非同期起動もできる。この実施の形態においては、プレゼンタが新しい結果を表示するときはいつでも意味論的なスマートレンズの情報がないかクリップボードを調べる。非同期の実施の形態において、プレゼンタはビュー内の全オブジェクトの全てのスマートレンズの結果を、自動的にキャプチャする。表示する各オブジェクトの横にアイコンを表示して、そこに文脈固有の関連した情報があることを示す。好ましい実施の形態において、ユーザはビューで任意のオブジェクトにスマートレンズを起動できる。
6. 最新情報−各オブジェクトはオブジェクトに関連する「最新情報」があるかどうかを示すユーザインターフェースを表示することが好ましい。これは意味論的に「最新ニュース」に相当する。ユーザインターフェースは情報の重大性を示すために表示されるのが好ましいが、ユーザがその情報を必要としない場合のために押し付けがましいものであってはいけない。例えば、ユーザインターフェースはオブジェクトのビューウィンドウの隅でゆっくりと点滅するアイコンとして示してもよい。ユーザがアイコン上にマウスカーソルを合わせると、「最新情報」のメタデータが表示される。好ましい実施の形態において、「最新情報」は最新ニュースのコンテキストテンプレートを使って、全てのエージェントに呼び出しを起動する暗黙的なスペシャルエージェントによって実装される。
7. 各オブジェクトは注釈付加を持っているかどうかを示すユーザインターフェースで表示可能であることが好ましい。この情報は全てのオブジェクトに対して、全ての照会結果内にフィールドとして含まれる。
8. 各オブジェクトは、事前定義済みコンテキストテンプレート上に関連した情報があるか、又はクライアント上にスペシャルエージェントがあるかどうかを示すユーザインターフェースで表示可能であることが好ましい。これにはユーザによって作成されたスペシャルエージェントと（例えば、クライアントによってインストールされた）デフォルトのスペシャルエージェントを含むことが好ましい。好ましい実施の形態において、コンテキストテンプレート用の文脈パレットは、ユーザが（文脈パレットをナビゲートするために）１つ以上の文脈パレットを表示したり、非表示したり、スクロールしたりする選択肢を持って、表示される。コンテキストテンプレートと文脈パレットは以下で詳細に説明する。他の実施の形態において、エージェンシーの優先度には以下を含むことが好ましい。
・ 優先度が非常に高い−これは最優先事項である。例えばある指定の文書用に、関連した電子メールメッセージが投稿されたばかり（この場合数分以内）である、又は今後のイベントが切迫している場合、このフラグは（エージェンシー上で） TRUE である。
・ 優先度が高い−これはその次に最優先事項である。ユーザインターフェースのフィードバックはあまり押し付けがましいものではいけないが、優先度が十分に高いのでユーザの注意に値することを明確にすることが好ましい。優先度はユーザによって異なるようにすることもできる。例えば、ユーザにとって地元のイベントがあれば、その優先度は遠隔地のイベント（特に遠隔ユーザにとってそのイベントに参加する可能性が全くない場合）よりも高くなることが可能である。
・ 優先度が中程度−これは単にユーザに時間があれば目を渡すべき情報があることを示すことができる。ユーザインターフェースのフィードバックはこれを明確にする必要がある。
・ 優先度が低い−これは関連した情報は密接な関係を持つが最近のものでないことを示してもよい。
この４つの優先度の仮想ブレンダーは、クライアント上にデフォルト設定でインストールされることが好ましい。これらのブレンダーはマイエージェンシーリストにある各エージェンシー上の対応する優先度のエージェントから情報を自動的に集約する。これは全てのエージェンシー上でのデフォルトの優先度エージェンシーであることが好ましい。好ましい実施の形態において、意味論的な関係照会は文脈とユーザを考慮に入れる。
各コンテキストテンプレート（又は現在選択されているコンテキストテンプレート）の好ましい実施の形態において、プレゼンタはユーザがマイお気に入りのエージェンシーのリスト、又は最近のエージェンシーに追加するエージェンシーを列挙して、コンテキストテンプレートに基づいて現在のオブジェクトに関係するオブジェクトがあるかどうかを探し出すために、適切なエージェンシーに動的に生成されたＳＱＭＬを使って照会をする。お気に入り又は最近のリストのエージェンシーのどれもにアクセスできな場合、ユーザインターフェースはエージェンシーを無視することで、ユーザに気付かれないようにこれを処理することが好ましい。好ましい実施の形態において、デフォルト設定では、動的に生成されたＳＱＭＬは現在選択されたオブジェクトのＳＲＭＬのＳＱＭＬを索引付けして、ＳＱＭＬ内のリソースをリンクフィルタとして、コンテキストテンプレートのＳＱＭＬに（できればデフォルトの述語である「関連する」を使って）挿入することで作成される。これは現在選択されたオブジェクトのオブジェクトタイプを表示された文脈パレットの意味論へのマッピングを知的に処理する。例えば、現在選択されたオブジェクトが文書である場合、見出しの文脈パレットはＳＱＭＬの派生に基づいたＳＱＭＬを見出しのコンテキストテンプレートに用いる。セマンティックエンバイロメントの各エージェンシーは、デフォルトの述語を適切に使用して結果として生じるＳＱＭＬを意味論的に処理する。又別な例において、選択されたオブジェクトが人の場合、見出しのパレットは、人が作成、又は注釈付加した「見出し」等、その人に関連する見出しを示す。あるいは、現在選択されたオブジェクトが文書、又は電子メールメッセージである場合、（デフォルトの述語を持つ）ＳＱＭＬは各エージェンシー上の意味論的に関連する見出しを表す意味論的結果を作成する。これらの結果は文脈パレットに表示されることが好ましい。（権威的、ニュースメーカー等の）他の文脈パレットも同様である。
人のオブジェクトには、優先度のフラグはその人が投稿したオブジェクト、又はその人が作成又はホストするオブジェクトのどちらかを示すことが好ましい。この例で意味論的に一意的なメタデータのフィールドだけがこの判断を行うことが好ましい（例：その人の電子メールアドレス）。
9. 各オブジェクトはいくつかの操作の選択肢を含んだユーザインターフェースを表示することが好ましい。一例として、図５４はインフォメーションエージェント（意味論的ブラウザ）のリゾルトペインに表示された情報オブジェクトを示すユーザインターフェースの画面例である。図５４は、ユーザが推薦の文脈ペイン、最新ニュースの文脈ペイン、動詞のポップアップメニュー等ツールの選択肢を起動できる、（オブジェクトのメタデータ用の）吹き出しポップアップ及びオブジェクトのユーザインターフェースを示す。付加的及び他のユーザインターフェースの選択肢には以下を含む。
・ イントリンシックセマンティック リンク−これはオブジェクトの意味論的なクラスに組み込まれたリンクである。イントリンシックセマンティック リンクが存在しない場合は、何も表示される必要がない。一例として、好ましい実施の形態の電子メールオブジェクトには以下のイントリンシックセマンティック リンクが含まれる。
1. 差出人リスト->
1. 人Ａ
2. 宛先リスト->
1. 人Ｂ
2. 人Ｃ
3. ＣＣリスト->
1. 人Ｄ
2. 人Ｅ
4. ＢＣＣリスト->
1. 人Ｆ
2. 人Ｇ
5. 添付ファイル->
1. 文書１
2. 文書２
3. 文書３
好ましい実施の形態において、これらの意味論的なリンクのどれかがユーザによって呼び出されると、クライアントは関連オブジェクトの（及びオブジェクト自体でない）メタデータを取得する。これではユーザが最初のオブジェクトの側面で意味論的な情報の探索ができる。スキンは、適切なメソッドでオブジェクトをホストするＸＭＬウェブサービスのエージェンシーを呼び出すことが好ましい。好ましい実施の形態において、このメソッドの形式はISemanticRuntimeService::LoadNativeSemanticLink である。この実施の形態には、意味論的なクラスＩＤ、意味論的なリンク名、引数名、及び引数の文字列形式を含む。例えば、（ゼロベースの索引で）３番目の添付ファイルを「ナビゲート」するために、スキンは LoadNativeSemanticLink（SEMANTICCLASS_EMAILMESSAGE, “Attachments”, “Index”, 2）を呼び出すべきである。これはこの意味論的な関係照会を表現し、このＳＱＭＬを持つ新しい一時的なスマートエージェントを作成し、スマートエージェントを読み込むＳＱＭＬが生成されることが好ましい。これは好ましい意味論的ナビゲーションを示す。プロセスは再帰的であることもできる。ユーザは新しいオブジェクトとピボット等を任意に使って、新しい結果をナビゲートすることができる。図５５は本発明による電子メールの例を示すイントリンシックセマンティック リンクに関連した吹き出しポップアップの一例である。このユーザインターフェースの見本では、ユーザがリゾルトペイン内の情報オブジェクト上にある「組み込みリンク」アイコンを選択すると、ポップアップメニューが表示される。この図解はイントリンシックセマンティック リンクのユーザに電子メールオブジェクトに対して何が表示されるのかを示す。好ましい実施の形態において、ユーザがメニューの選択肢をクリックすると、ポップアップメニューの項目が（適切なリソースと述語のリンクが何であるかの）新しいＳＱＭＬ照会を呼び出す。新しい一時的なエージェンシーは照会結果を示して（ＳＱＭＬで）作成される。ユーザはエージェントをお気に入りのリストに保存できる。又新しい結果はイントリンシックセマンティック リンク、コンテキストテンプレート等を表示し、その結果ユーザが情報を意味論的にナビゲートできるユーザ制御のブラウジングをサポートする。ネイティブな動詞の代替の設定と機能は以下の通りである。
ALL INFORMATION（全ての情報）：
（エージェンシーが出所である場合にのみ）エージェンシー上の関連した情報を検索
（エージェンシーが出所である場合にのみ）エージェンシー上の関連した可能性がある情報を検索
注釈付加を開く->
全て
注釈付加１
注釈付加２
注釈付加２
EMAIL（電子メール）：+=
差出人リスト->
人Ａ
宛先リスト->
人Ｂ
人Ｃ
ＣＣリスト->
人Ｄ
人Ｅ
ＢＣＣリスト->
人Ｆ
人Ｇ
添付ファイル->
文書１
文書２
文書３
PERSON（人）：
直属先->
直属の部下->
配信リストの会員->
情報作成者->
情報注釈付加者->
この人がエキスパートであるカテゴリを持つ情報->
CUSTOMER（顧客）：
情報注釈付加者->
・ 注釈付加−これではユーザが現在のオブジェクトの全ての注釈付加に対する要約ビューをナビゲートできるようにすることが好ましい。好ましい実施の形態において、スキンは（オブジェクトメタデータを引数として） ISemanticRuntimeService::EnumAnnotations を呼び出すことで、全ての注釈付加を表示する。これは注釈付加オブジェクト用のメタデータを含む特性の表のＸＭＬ表現を返す。スキンは（注釈付加の名前又はタイトル等の）表示される注釈付加の概要の内一部の表現を表示することが好ましい。注釈付加リンクがユーザによって呼び出されると、スキンは注釈付加オブジェクト用メタデータを表示する。これらの機能はクライアント上で適用されたフィルタに源を発することが好ましい。あるいは、これらの機能はエージェントとして作成できる。本発明のこの側面は更に意味論的ナビゲーションを説明する。「注釈付加」の照会のＳＱＭＬによる表現を使って注釈付加を読み込むことが好ましい。これは、このＳＱＭＬで新しいスマートエージェントを作成する。次にスマートエージェントは「最近の」リストに追加して読み込む（又はナビゲートする）。プロセスは再帰的であることもできる。ユーザは新しく表示された注釈付加をピボット等として使ってナビゲートすることができる。
・ 関連したオブジェクト−好ましい実施の形態において、これは任意選択で、ユーザが現在のオブジェクトをインフォメーションオブジェクト ピボットとして用いて、ユーザのマイエージェンシーのリストに含まれる各エージェンシーにある関連した情報を検索できる。これはコピー＆ペーストを手段とせず、又はシェル拡張子のユーザインターフェースに頼らずに実現することが好ましい。好ましい実施の形態において、ユーザインターフェースのポップアップは以下の形式で情報を示す。
Find Related Objects -->
All my agencies -->
Agency Foo -->
All.All
All.Understood.All
All.CriticalPriority.All
All.HighPriority.All
All.MediumPriority.All
All.LowPriority.All
All.MyFavorites.All
All.Recommended.All
Agencies that understand this object -->
Agency Bar -->
All.All
All.Understood.All
All.CriticalPriority.All
All.HighPriority.All
All.MediumPriority.All
All.LowPriority.All
All.MyFavorites.All
All.Recommended.All
All my agencies のリストはユーザがローカルに登録したエージェンシーを列挙するだけでプレゼンタによって取得される。プレゼンタはローカルに登録した各エージェンシーに当該のオブジェクトを理解するかどうかを「尋ねる」ことで「このオブジェクトを理解するエージェンシー」のリストを返す。プレゼンタはエージェンシーにオブジェクトのＸＭＬ表現を渡し、エージェンシーはそのＸＭＬ表現の意味論的な処理を試みる。エージェンシーはオブジェクトを理解するかどうかを示すフラグを返す。各オブジェクトはエージェンシーがそのコンテンツを理解するかどうかを示すフィールドを持っているので、プレゼンタはそのオブジェクト自体がホストされているエージェンシーを除外することで返されたリストを最適化する。
・ 動詞−これによって、ユーザは現在のオブジェクトに直接関係する任意のアクションを呼び出すことができる。例えば、文書又は電子メールメッセージは「開く」動詞を持つことができる。これはワードプロセッサ、又は電子メールクライアントを開いて情報を表示する。イベントは「アウトルックのカレンダーに追加」の動詞を持つことができる。好ましい実施の形態において、動詞は、クラス固有であることが望ましいが、システムの枠組みによってクライアント上で呼び出される。エージェンシーは動詞のことを知る必要はまったくない。好ましい実施の形態において、各オブジェクトにはいくつかの動詞がある。これらの動詞は最初にポップアップメニューで表示されることが好ましい。好ましい実施の形態において動詞は以下を行う。
1. 注釈付加をする−ユーザがこの動詞を呼び出すと、スキンはクライアントのランタイムと通信して注釈付加をするメソッドを呼び出すことが好ましい。このメソッドは（エージェンシーが注釈付加を解釈するために構文解析する）適切な件名でデフォルトのメールクライアントを開始する。ユーザは通常の電子メールメッセージをオブジェクトの注釈付加として送信する。電子メールの注釈付加は、更に意味論的なリンクを構成する添付ファイルを含むこともできる。これによって、ユーザは（文書等の）オブジェクトからその注釈付加に、そしてその添付ファイルへ、そして（例えば、スマートレンズを経由して）外部のコンテンツソースへとナビゲートできる。他の実施の形態は又、単純な形式に基づいた、又はダイアログに基づいた注釈付加等、注釈付加をサポートする。しかしながら、電子メールは最も意味論的な豊かさを提供する。
2. コピーする−これはオブジェクトのＸＭＬをシステムクリップボードにコピーする。
3. 非表示する−これはユーザがオブジェクトのビューに興味がないことを示す。
4. 開く−これは何が開かれているかのリンクで修飾される。文書の例では、「文書を開く」が表示され得る。電子メールメッセージ用には、「電子メールを開く」が表示され得る。クライアントはリンクのＭＩＭＥタイプ用にシステムで登録された、デフォルトのアプリケーションでオブジェクトを開く。他の実施の形態においては、本発明は特定のアプリケーションでオブジェクトを開くことができる「次を使って開く」等の他に関連した開くの動詞をサポートする。
5. お気に入りのマークを付ける−これはエージェンシーがユーザ状態をサポートして、オブジェクトがお気に入りでない場合に表示されることが好ましい。
6. お気に入りのマークを解除する−これはエージェンシーがユーザ状態をサポートして、オブジェクトがお気に入りである場合に表示されることが好ましい。
図５６は本発明による動詞のユーザインターフェースに関連した吹き出しポップアップの一例である。このユーザインターフェースの例では、ユーザがリゾルトペインに表示された情報オブジェクト上の「動詞」アイコンをクリックすると、吹き出しポップアップが表示される。メニューは（文書、電子メール、人等の）オブジェクトタイプに基づいた情報オブジェクトに対する関連がありサポートされたアクションを示す。ネイティブの動詞の代替の設定と機能は以下の通りである。
ALL INFORMATION（全ての情報）：
・ 注釈付加する（アウトルックを開く。オブジェクトの出所がエージェンシーである場合、エージェンシーのイーメールエージェントアドレスは「宛先」フィールドからデータを取り込み、そうでない場合、オブジェクトの注釈付加の関連付け用にユーザがエージェンシーを指示できるように、「宛先」フィールドは空白のままになる）。オブジェクトの出所がエージェンシーでない場合、オブジェクトは電子メールメッセージに、ＵＲＬ、又は完全な添付ファイルとして添付されるべきである。
・ コピーする
・ 開く
・ お気に入りのマークを付ける（クライアント上に格納される）
・ お気に入りのマークを解除する
PERSON AND CUSTOMER：+="Send Email"
10. スキンが１つ以上のオブジェクト用に新しい照会、又はメタデータを読み込む際に、スキンはその照会、又はメタデータで枠組みを呼び出すことが好ましい。好ましい実施の形態において、スキンは照会を実行しないで、プレゼンタのランタイムに照会を渡し、そこで結果が管理される。
11. ディープインフォメーション（又は提示）モード−本発明の他の実施の形態は、詳細提示モードのスキンのサポートを提供する。この実施の形態においては、スキンは現在のオブジェクトに関連する情報があるかどうかを示すユーザインターフェースを表示する。スキンは又情報を記述するテキストを表示する。例えば、指定の文書オブジェクト用に、スキンは「Jane Doe がこのオブジェクトに関連する最近の電子メールメッセージを投稿しました：＜電子メールのメッセージの要約＞」というテキストでポップアップを表示できる。この実施の形態において、スキンは最後に投稿された関連のオブジェクト、又は最も間近に予定されているオブジェクト等の特定情報の詳細を示す。スキンはユーザが興味を持つかもしれない他の「真実」、又は推測されたデータを表示することもできる。その例として以下が挙げられる。
・ リサ ヘイルボーンが最近関連文書を投稿した：<summary>
・ この文書の作成者はおそらく <foo> である。
・ スティーブ ジョドキンズはパトリック シュミッツの直属である。パトリックはこれに関連して優先度が非常に高いオブジェクトを５４個投稿している。
・ この文書はエキスパートが３人いる可能性がある： <names>
・ ユーイング チェンはこの文書に関して最も専門知識があるようである。
本発明の枠組みは、スキンが情報を取得するのに使ういくつかの「意味論的な詳細」を公開する。スマートレンズも又、詳細提示モードをサポートするように設定できる。言い換えれば、好ましい実施の形態において、オブジェクト上でスマートレンズを起動すると、上記の例に似た詳細情報を返す。スキンはオブジェクトのビューウィンドウの隅にアイコンを表示する。ユーザはそのアイコンをクリックして「詳細情報」を表示することができる。「詳細情報」のメタデータは非同期的に取得されることもできる。
図５７は本発明に従って、リゾルトペインの文脈内で提示された、ディープインフォメーションモードのユーザインターフェースに関連した吹き出しポップアップの一例を示す。この例ではユーザは、（例えば、「スティーブ ジョドキンズ」は人のオブジェクトで、「エキスパート」はコンテキストテンプレートの結果オブジェクトで、「直属の部下」は「直属の部下」述語フィルタを使うオブジェクト等）のセマンティックエンバイロメント内の意味論的な（ＳＱＭＬ）リンクの他に、どのタイプのディープインフォメーションを表示するかをフィルタリングするためのディープインフォメーションのテンプレートを選択する、及びディープインフォメーションの「ストーリー」を表示するという選択肢がある。更に、ユーザはプレビューのプレイヤー／コントロールを使って、適所での意味論的な照会結果をプレビューする選択肢がある。
e. 意味論的な照会文書
クライアントの観点からすると、クライアントが理解する全てが照会文書である。本発明において、ワードプロセッサが「テキストの複合文書」を開く方法と類似したやり方で、クライアントは「照会文書」を開く。クライアントの主な役割は、意味論的な照会文書の処理とその結果の表現である。意味論的な照会文書は、意味論的クエリマークアップ言語（ＳＱＭＬ）形式で表現され格納されることが好ましい。これは「意味論的なファイル形式」と似ている。好ましい実施の形態において、ＳＱＭＬの意味論的なファイル形式は以下を含む。
・ Head−ヘッドタグは文書を記述するタグを含む。
・ Head: Title-これは文書のタイトルを示す。
・ Filters−プレゼンタは「フィルタ」タグ内のエントリを使って返されたオブジェクト全てをフィルタリングする。このようなエントリは（文書、イベント、電子メール等の）オブジェクトタイプ名を含むこともできる。フィルタの指定がない場合、オブジェクトはフィルタリングされない。タグはエントリが含まれるか含まれないかを示す修飾子を持つ。（「含む」と「除外する」の両方のタグで示された）重複したエントリの場合、解釈プログラムはエントリを除外する（すなわち、タイの場合は「除外する」と推定される）。
・ Attributes−このタグは文書の属性を示す。
・ Skins−これはスキンに関連する全てのエントリ用の親タグである。
・ skin:<objecttypename> これは object type name で示すオブジェクトタイプのオブジェクトを管理するスキンの情報を含む。ＳＱＭＬ文書内で対応するスキンのエントリを持たないオブジェクトには、プレゼンタはデフォルトとエージェントのスキンを用いる。選択肢は以下を含むことが好ましい。
・ skin:<objecttypename>:color これはこの文書で使われる色のテンプレートの情報を持つ。主なエントリはＸＳＬＴのＵＲＬである。
・ skin<objecttypename>:design これはこの文書で使われるデザインのテンプレートの情報を持つ。主なエントリはＸＳＬＴのＵＲＬである。
・ skin:<objecttypename>:animation これはこの文書で使われるアニメーションのテンプレートの情報を持つ。主なエントリはＸＳＬＴのＵＲＬである。
・ Query−これは照会文書の主な照会の全てのエントリ用の親タグで、以下を含んでもよい。
・ Resource−照会が行われるリソースへの参照。例としてファイルパス、ＵＲＬ、キャッシュエントリの識別子等を含む。これらは解釈プログラムによって実際のリソース管理の構成要素にマッピングが行われる。
・ resource:type−名前空間で修飾されたリソース参照のタイプ。定義されたリソース参照のタイプの例としては、nervana:url （これはリソース参照が整形式標準のインターネットのＵＲＬである、又 agent://… のようなカスタムのＵＲＬであることを示す）と nervana:filepath （これはリソース参照がファイルシステム上のファイル、又はディレクトリへのパスであることを示す）が挙げられる。
・ resource:arg−これは解釈プログラムがリソース参照を実際のリソースに変換する時に、リソースに渡される任意選択の文字列を示す。実行可能ファイルへのコマンドライン引数に相当する。ここで留意すべきは、リソースによってはこの引数を rref の引数の一部ではなく、 rref の一部として解釈する可能性があることである。例えば、標準のＵＲＬはＵＲＬ自体の最後に（「?」タグを接頭辞として付けた） rref の引数を渡すことができる。
・ resource:version−以下を参照のこと。
・ resource:link−全てのリンクタグ。
・ resource:link:predicate−これはリンク用の述語タイプを示す。例えば、述語 nervana:relevantto は、照会が「オブジェクトＯに関するリソースＲから全てのオブジェクトを返す」で、ここで、ＲとＯは、それぞれ指定のリソース、及びオブジェクトを表す。述語の他の例には、nervana:reportsto、nervana:teammateof、nervana:from、nervana:to、nervana:cc、nervana:bcc、nervana:attachedto、nervana:sentby、nervana:sentto、nervana:postedon、nervana:containstext 等を含む。
・ resource:link−これは意味論的なリンクのオブジェクトの参照を示す。
・ resource:link:type−これは oref のタグで示すオブジェクトの参照タイプを示す。例としては、xml:string、 xml:integer、（「今日」、「明日」のようなオブジェクトの参照を検索する可能性がある）nervana:datetimeref を含むカスタムタイプ、本発明が意味論的なＸＭＬオブジェクトとして処理できるオブジェクトを検索する任意の標準インターネットＵＲＬ（ＨＴＴＰ、ＦＴＰ等）、あるいは（ｏｂｊｅｃｔｓ：／／等の）システムのＵＲＬ等、を含む標準のＸＭＬデータタイプを含む。
・ resource:link:version−これはリソースの意味論的なリンクのバージョンを示す。これはエージェンシーの意味論的な照会プロセッサにバージョン化した結果を返すことを可能にする。例えば、意味論的ブラウザの１つのバージョンは、照会のバージョン１を使い、別なバージョンはバージョン２を使うことができる。これはエージェンシーに（エージェント用等の）リソースのレベルとリンクのレベルの両方で下位互換性を提供する。
・ Query Type−これはこのＳＱＭＬバッファのファイルが表現する照会（又はエージェント）タイプを示す。好ましい実施の形態において、これはエージェント、エージェンシー、スペシャルエージェント及びブレンダーを含む。
・ Query Return Type−これは（文書、電子メール、見出し、権威的等の）照会が返すオブジェクトタイプを示す。あるいは、コンテキストテンプレート等の情報オブジェクトタイプの名前を示してもよい。
一例として、本付属書類の実例Ｂは、本発明による意味論的な照会文書を説明する。
好ましい実施の形態において、プレゼンタはＳＱＭＬ解釈プログラムを含む。プレゼンタがＳＱＭＬファイルを開くと、まず構文解析、検証、マスタのエントリ表の作成を行い、次にそのエントリ表にあるエントリを実行することが好ましい。言語コンパイラがソースコードを他のモジュールにリンクさせて実行する前にオブジェクトのモジュールにコンパイルする方法と異なっておらず、実際上、ＳＱＭＬファイルを「実行」する前に「コンパイルする」。ＳＱＭＬ解釈プログラムの場合、このプロセスは参照を経由して、任意選択として他のＳＱＭＬファイルの読み込みを含むこともできる。このプロセスは循環でないことが好ましい。宣言された各オブジェクトのタイプ情報を表示するために、クライアントは（利用可能でデフォルト、又はエージェントのスキンで上書きされていない場合は）<skin> のタグ内のＸＳＬＴテンプレートを使う。宣言されたスキンを持たない返されたオブジェクトは、オブジェクトタイプのデフォルトスキン、あるいは、単一のエージェントエントリの場合には、（指定されている場合は）エージェントのデフォルトスキンで表示される。
他の実施の形態においては、クライアントは意味論的な照会文書が開かれた後でも、各オブジェクトタイプを表示するために、新しいスキンを読み込むことができる。この実施の形態において、<skin> のタグは、クライアントにどのスキンで最初に照会を読み込むのかを知らせることが好ましい。この実施の形態において、指定したスキンは宣言されたオブジェクトタイプに適切であることが好ましい。
好ましい実施の形態において、枠組みは検証段階と実行段階の２つの段階で、文書を実行する。検証段階では、解釈プログラムはまずマスタの意味論的なエントリ表を構築する。表はリソースのＵＲＬで入力され、演算子、リソース、リソースタイプ、述語、述語タイプ、及びリンクのカラムがある。解釈プログラムは表にエントリが追加される際に、重複したエントリを全て除外する。又解釈プログラムは、表に追加する前に全てのＵＲＬを正規化することが好ましい。例えば、http://www.abccorp.com と www.abccorp.com/ のＵＲＬは同じ正規の形式を共有するので同一であると解釈される。解釈プログラムは個別のＳＱＭＬ参照表を構築し管理する。この表はＳＱＭＬファイルへの正しいパスを含む。解釈プログラムが最初のＳＱＭＬファイルを読み込むと、参照表に正しいファイルパスを追加する。ＳＱＭＬファイルがそれ自体を指すと、解釈プログラムはエントリを無視するか、又はエラーを返す。ＳＱＭＬファイルが別のＳＱＭＬリソースを指すと、参照表に新しいファイルを追加する。次に新しいリソースを再帰的に読み込み、プロセスは自己反復する。プロセス中に、解釈プログラムがすでに参照表に存在するＳＱＭＬエントリを見つけると、解釈プログラムは呼び出し側のアプリケーションに（ＳＱＭＬ文書中に再帰ループが存在していることを示して）エラーを返す。解釈プログラムが文書のグラフパスの中に更にリソースを見つけるたびに、指定リソース用のマスタのエントリ表に追加する。エントリ表のそのリソースのエントリに指定リソース用のリンクを動的に追加する。その結果、解釈プログラムはグラフにある各リソース用の文書リンクグラフを効果的に平らにする。
次に解釈プログラムは実行段階に進む。この段階で解釈プログラムは、意味論的なエントリ表を見直して、全てのリソース照会を非同期的、あるいは順次的に実行する。次にリソースタイプに基づいて各リソースを処理する。例えば、ファイルのリソース用には、ファイル用に特性メタデータを開き、メタデータを表示する。（文書等の）理解したタイプを参照するＨＴＴＰリソース用には、解釈プログラムはＵＲＬをダウンロードして、抽出し表示する。エージェントのリソース用には、各エージェントのＸＭＬウェブサービスを呼び出して、各リンクを演算子で修飾させてＸＭＬ引数として渡す。好ましい実施の形態において、文書の境界を越えるリンクの演算子は常にＡＮＤである。言い換えれば、再帰照会はフィルタと見なされるので、解釈プログラムは一緒に宣言されていない同一のリソースのリンク全ての論理積をとる。解釈プログラムはリソースを表現する構成要素への呼び出しは、エージェントのリソース数と同数発行する。各リンク用には、解釈プログラムはリンクをリソースによる処理に適した照会に変換することによってリンクを解決する。例えば、次のような属性でのリンクを持つエージェントは、
<predicate>nervana:relevantto</predicate>
<oref>c:＼foo.doc</oref>
<oreftype>nervana:filepath</oreftype>
（ c:＼foo.doc 等の）オブジェクトのＸＭＬ形式メタデータを抽出して、ＸＭＬを引数としてエージェントリソース用にＸＭＬウェブサービスを呼び出すことで解決される。これは、局所的文脈が、どのようにサーバが理解し処理できる汎用の（ＸＭＬベースの）照会に解決されるのかを示す。
照会を最適化するために、エージェンシーのＸＭＬウェブサービスは（ＡＮＤ、ＯＲ等の）演算子で修飾されたいくつかの引数を渡すためのメソッドを公開する。解釈プログラムは、リンクの全ての引数でエージェントリソース用に１つの呼び出しをＸＭＬウェブサービスに発行することが好ましい。
意味論的な照会の実装のシナリオ−以下は本発明の好ましい実施の形態による、意味論的な照会文書の実装と操作を説明したシナリオの例である。
シナリオ１：ＳＱＭＬ文書の読み込み−クライアントは一時ファイルを作成して、それを単純でローカルのＨＴＭＬページの属性を含むバッファに書き込む。このページは（ＡｃｔｉｖｅＸコントロール、Ｊａｖａアプレット、インターネットエクスプローラの動作等の）クライアントの枠組みの構成要素を含む。ページはＳＱＭＬファイルを開くこの構成要素と、インフォメーションエージェントの実現値を識別する一意的なＩＤで初期化される。構成要素自体がＳＱＭＬファイルを開く。言い換えれば、クライアントの枠組みは、プラグインにどのＳＱＭＬの照会文書を開くかを指示する。プラグインは上記で説明したように、それを解釈することによって、意味論的な照会文書を開く。
シナリオ２：文書を開く−クライアントは、ユーザが開くファイルを選択できる標準のダイアログボックスを開く。ダイアログボックスは（ＰＤＦ、ＤＯＣ、ＨＴＭ等の）標準文書ファイルの拡張子で初期化される。ユーザが文書を選択すると、ダイアログボックスは、開いた文書全てのリストを返す。クライアントは新しいＳＱＭＬファイルを作成して、開いた文書のパスでリソースのエントリを追加する。新しいＳＱＭＬファイルは一意的な名前が与えられる（グローバルに一意的な識別子（ＧＵＩＤ）に基づいた名前が好ましい）。これは一時ファイルなので、名前はユーザに公開されないことが好ましい。方法論は上記で説明したようにシナリオ１に進む。
シナリオ３：文書のフォルダを開く−クライアントは（上記で説明したように）ＳＱＭＬファイルを開き、１つのリソースエントリ file://<folderpath>?includesubfolders=(true|false) で初期化する。ＳＱＭＬファイルは、フォルダの中にある全ての文書を列挙して、文書のメタデータを表示することで（シナリオ１と同様に）読み込まれる。
シナリオ４：エージェントとして保存−クライアントはダイアログボックスを開いて、ユーザはエージェント名を設定できる。クライアントはセマンティックエンバイロメント（以下を参照のこと）のエージェント名を新しい名前に変更する。保存されるエージェントは一時的か、又は異なる名前ですでに保存されていてもよい。インフォメーションエージェントはエージェントの名前を示唆するものが好ましい。
シナリオ５：ブレンダーの中に保存−クライアントは、ユーザがブレンダーを選択できるダイアログボックスを開く。ダイアログボックスは、ユーザが新しいブレンダーを作成できるものが好ましい。ブレンダーが選択されると、クライアントはブレンダーのＳＱＭＬファイルをＳＱＭＬオブジェクトモデルの中に開き、新しいエントリ（現在読み込まれたＳＱＭＬファイル）を追加する。次に現在のエントリの参照数を増分する。
シナリオ６：ドラッグ＆ドロップ−クライアントは、一例として以下のような単純なリソースエントリで、ＳＱＭＬファイルを作成して開く。
<resource type="nervana:url">
agent://documents.all@abccorp.com
<link predicate="nervana:relevantto"
type="nervana:filepath"
c:＼foo.doc
</link>
</resource>
この例は c:＼foo.doc を表現するアイコンがエージェント agent://documents.all@abccorp.com を参照するインフォメーションエージェントにあるアイコン上にドラッグ＆ドロップされることを想定している。
シナリオ７：複数のドラッグ＆ドロップ−クライアントは、一例として以下のような単純なリソースエントリで、ＳＱＭＬファイルを作成して開く。
<resource type="nervana:url">
agent://documents.all@abccorp.com
<link predicate="nervana:relevantto"
type="nervana:filepath"
c:＼foo1.doc
</link>
<link type="nervana:filepath"
operator="or"
predicate="nervana:relevantto"
c:＼foo2.doc
</link>
<link type="nervana:filepath">
operator="or"
predicate="nervana:relevantto"
type "nervana:filepath"
</link>
</resource>
この例は c:＼foo1.doc、c:＼foo2.doc、c:＼foo3.doc を表現する複数のアイコンが、エージェント agent://documents.all@abccorp.com を参照するインフォメーションエージェントにあるアイコン上にドラッグ＆ドロップされることを想定している。更に、この例ではユーザがエージェントのリソースで対象とする意味論的な照会の論理和を希望することを示すと想定している。
シナリオ８：スマートレンズ−スマートレンズがインフォメーションエージェントで選択されると、インフォメーションエージェントはセマンティックエンバイロメント マネージャ（以下を参照）にスマートレンズがインフォメーションエージェントの識別子に選択されたことを示す。（文書オブジェクトモデル（ＤＯＭ）の「onmouseover」イベント経由等で）マウスがオブジェクト上にあることをスキンが検出すると、インフォメーションエージェントがスマートレンズモードであるかどうかを見つけ出すために、まずプレゼンタを呼び出す。クライアントの枠組みは、識別子を持つインフォメーションエージェントがスマートレンズモードであるかをセマンティックエンバイロメント マネージャに尋ねることでこれを判断する。セマンティックエンバイロメント マネージャは、インフォメーションエージェント自体からこの情報をキャッシュするので、インフォメーションエージェントの代わりに質問に回答できる。インフォメーションエージェントがスマートレンズモードである場合、クライアントの枠組みは、セマンティックエンバイロメント マネージャを経由して、システムクリップボードからＳＱＭＬバッファを取得することが好ましい。これはスマートレンズが仮想の「ペースト」であり、情報をクリップボードから取得するからである。言い換えれば、クリップボードにコピーされた任意のオブジェクト、又はエージェントは（通常のテキストでさえ）スマートレンズとして使うことができる。枠組みはＳＱＭＬバッファを取得して、ＳＱＭＬバッファにある全てのリソースに対するリソース構成要素の実現値を生成する。クライアントの枠組みは現在表示されたオブジェクト用のＸＭＬによる情報をリソースに渡すリソースＡＰＩの GetInformationForSmartLens を呼び出す。全てのリソースは、スマートレンズのメタデータをクライアントの枠組みに返すことが好ましい。各リソースはスマートレンズの情報のナゲット（塊り）のリストの形式でメタデータを返すことが好ましい。それぞれのナゲットはテキスト入力と、（ＳＱＭＬで）照会のバッファのリストを含む。テキスト入力は単純なテキスト、又は一例として以下のようなカスタムテキストの書式を含む。
Steve reports to <A>Patrick</A>. Patrick posted <A>54 critical-priority messages</A> relating to this one.
各 <A> のタグのペアは情報のナゲットの中に対応するＳＱＭＬ照会のバッファを含むことが好ましい。クライアントの枠組みは、（吹き出しポップアップ、又は他のユーザインターフェースで、マウスカーソルを合わせたオブジェクトを阻止したり隠してしまうようなものでないことが好ましい）等のインフォメーションエージェントで表示するために、テキストをＤＨＴＭＬ（又は類似の提示形式）に書式設定する。クライアントの枠組みは包含する <A> と </A> のタグが見つかったリンク（ＨＴＭＬリンクに類似）のユーザインターフェースを表示する。リンクが呼び出されると、クライアントの枠組みは新しいキャッシュエントリを作成するために、セマンティックエンバイロメント マネージャを呼び出す。セマンティックエンバイロメント マネージャはそのエントリがどのファイルパスに格納されるべきかを示す。クライアントの枠組みは、クリックした <A> のタグ用のＳＱＭＬバッファをファイルに書き込む。クライアントの枠組みはＳＱＭＬ文書をセマンティックエンバイロメント マネージャに送り、ＳＱＭＬを（ダイナミックＨＴＭＬ経由で）インフォメーションエージェントに読み込む。セマンティックエンバイロメント マネージャはこのＳＱＭＬ文書を現在の文書として含むので、ユーザは（「エージェントとして保存」、又は「ブレンダーの中に保存」等の）インフォメーションエージェントの「保存」ボタンを経由して文書を保存することができる。スマートレンズが表示できる情報例を以下に挙げる。
エージェントの Email.Technology.All@Marketing はこのオブジェクトに関連するオブジェクトを合計３００個持つ。優先度が非常に高い：５個のオブジェクト、優先度が高い：５０個のオブジェクト、優先度が中程度：１００個のオブジェクト、優先度が低い：１４５個のオブジェクト。
好ましい実施の形態において、ユーザが吹き出しのリンクのどれをもクリックしない場合は、ＳＱＭＬ文書は作成されず、セマンティックエンバイロメントに何も追加されない。これはスマートレンズが「可能性のある照会」のみを表すことが好ましいからである。
好ましい実施の形態において、ＳＱＭＬで含むことができる情報であれば全てスマートレンズとして起動することができる（例：エージェント、人、文書、見出し、権威的、エージェンシー、テキスト、ＨＴＴＰのＵＲＬ、ＦＴＰのＵＲＬ、ファイルシステムからのファイル、ファイルシステムからのフォルダ、マイクロソフトアウトルック等の電子メールのアプリケーションからの電子メールのＵＲＬ、電子メールフォルダのＵＲＬ等）。例えば、ユーザはテキストベースのアプリケーションから、通常のテキストをクリップボードにコピーすることができる。ユーザがインフォメーションエージェントを入力してスマートレンズを選択すると、ＳＱＭＬバージョンのテキストが（「文書」リソースを経由して）スマートレンズとして起動する。「テキストのスマートレンズ」がそのとき文書オブジェクトの上にマウスカーソルを合わせると、テキストのスマートレンズを表現する文書リソースは、スマートレンズにあるオブジェクトとマウスの下にあるオブジェクトとの類似性をユーザに示すことで、類似指数を表示することもできる。マウスの下にあるオブジェクトが人のオブジェクトである場合、文書リソースは、人のオブジェクトを表すエージェントに、エージェントはテキストに含まれる情報に関してのエキスパートであるかどうかを、「尋ねる」かもしれない。あるいは、スマートレンズは類似の文書へのリンク、又は、その人がそのテキストに関連して作成した電子メールメッセージを表示してもよい。
シナリオ９：コピー＆ペースト
コピー：セマンティックエンバイロメント内で「コピー」コマンドの起動時に、クライアントの枠組みは、カスタムのクリップボード形式でＳＱＭＬバッファをシステムクリップボードにコピーする。これは（マイクロソフトワード、エクセル、ノートパッド等の）他のアプリケーションが形式を認識せず、情報のペーストを試みないことを確実にする。ＳＱＭＬバッファは、コピーされるオブジェクトの意味論と一致することが好ましい。例えば、プレゼンタに表示されるオブジェクトからのコピーの操作は、メタデータの出所から適切なリソースタイプとＵＲＬでリソースとしてコピーされる。エージェントを表現するアイコンのコピーは、エージェントのＵＲＬ、又はセマンティックエンバイロメント内にあるエージェントのエントリを参照するキャッシュエントリをコピーする。（マイクロソフトアウトルック等の）デスクトップアプリケーションからの情報のコピーは、ソースのアプリケーションを参照するリソースタイプと、そのアプリケーションにあるオブジェクトを指すＵＲＬでＳＱＭＬをコピーする。これらのＵＲＬは、ランタイムに解釈プログラムによって、そのアプリケーション内のオブジェクトに解決できることが好ましい。例えば、アウトルックからセマンティックエンバイロメントへと電子メールメッセージをコピーする際には、以下のようなリソースエントリを作成する可能性がある。
<resource type="nervana:outlookemailmessage">
outlook://file://c:＼temp＼foo.html
</resource>
ペースト：「ペースト」コマンドの呼び出し時に、クライアントの枠組みは、情報がペーストされるクリップボード形式に基づいて、ＳＱＭＬファイルを作成する。例えば、クリップボードがファイルパスを含む場合、ＳＱＭＬファイルはそのファイルパスを持つオブジェクトへの（ペーストが起動されたリソースからの）リンクを含む。このファイルは上記の通りに開く。クリップボード形式がＵＲＬの場合、オブジェクトはＵＲＬオブジェクトタイプである。形式が通常のテキストの場合、オブジェクトは実際のテキストを含み、この例ではリソースタイプの nervana:text である。あるいは、クライアントの枠組みは一時的なキャッシュエントリを作成して、（．ＴＸＴファイルとして）そこにテキストを格納して、ＳＱＭＬのオブジェクトをそのファイルパスとオブジェクトタイプで格納する。この例では nervana:filepath である。解釈プログラムが起動されると、ＸＭＬ形式メタデータのバージョンのテキストを作成し、ＸＭＬリンクの引数でリソースを起動する。クリップボード形式が本発明のＳＱＭＬのクリップボード形式の場合、同様の処理が行われる。ただしファイルが作成されるのであれば、拡張子は．．ＳＱＭ（又は．．ＳＱＭＬ）となる。これは解釈プログラムに、オブジェクトがＳＱＭＬファイルであり、普通のテキストファイルではないことを示す。
f. セマンティックエンバイロメント
本発明のセマンティックエンバイロメントの好ましい実施の形態は、インフォメーションエージェントを経由してユーザに利用可能な全てのエージェントとエージェンシーのビューを提供する。これは、ローカルでお気に入りの「マイエージェント」のリスト、最近使ったエージェント、ローカルのエージェンシー上にあるエージェント、及び遠隔エージェンシー上にあるエージェントに保存されたエージェントを含むことが好ましい。遠隔エージェンシーは、ローカルエリア ネットワークのマルチキャストを介して存在することを告知するエージェンシー、グローバルエージェンシー ディレクトリ上で利用可能なエージェンシー、及びカスタムのエージェンシーディレクトリ上で利用可能なエージェンシーを含む。エージェントは各自のＵＲＬを呼び出すことで、動的にセマンティックエンバイロメントに追加することができる。好ましい実施の形態において、セマンティックエンバイロメントの階層は、本付属書類の実例Ｃに示す構図を持つ。「最近使った」及び「最近作成した」エージェントは「最近のエージェント」に縮小されることが好ましい。任意選択として、「全てのエージェント」、「削除したエージェント」及び「カスタムビュー」を追加することもできる。
エージェンシービューでは、ユーザがエージェンシーでメインビューのエージェントを閲覧できる。オブジェクトタイプのビューは、ユーザが同じエージェントの表示だが、オブジェクトタイプ別でフィルタリングされたものを表示できる。例えば、（コンテキストテンプレートに基づく）「文脈別」及び「時刻別」等の他のビューは、類似の方法で動作する。セマンティックエンバイロメントは、「お気に入り」の概念を「履歴」の概念とマージさせる。セマンティックエンバイロメントは、「最近使ったエージェント」のような動的に管理されたビューを追加することもできる。これらのビューはセマンティックエンバイロメント マネージャ内で実行しているコードで更新されることが好ましい（以下を参照）。
本発明によるセマンティックエンバイロメントの図例を、図５８と図５９に示す。セマンティックエンバイロメントに組み込まれたアイコンは以下を含むことができる。
アプリケーション
全てのコンテナのオブジェクトタイプ
全ての文書ファイルタイプ
ブレイキングニュース エージェントのアイコンの修飾子（例、感嘆符）
スペシャルエージェントのアイコンの修飾子（例、ハロー）
各オブジェクトタイプのスタンダードエージェント
エージェンシー
エージェントビューのコンテナ
マイエージェント
ブレイキングニュース エージェント
フェイバリットエージェント
スペシャルエージェント
最近使ったエージェント
スナップショット−ユーザは、セマンティックエンバイロメントのスナップショットを保存できることが好ましい。セマンティックエンバイロメントのスナップショットは、本質的に時間に基づいたセマンティックエンバイロメントの状態のキャッシュである。好ましい実施の形態において、スナップショットには、以下の情報を持つローカルに格納された状態を含む。
・ スナップショット時に新しいエージェントを持つ全てのエージェンシー
・ （エージェンシーの刻時機構に基づいて）各エージェントが最後にエージェンシーを作成した時刻
・ （エージェンシーの刻時機構に基づいた）各エージェンシーの現在の時刻
スナップショットはユーザにアクセス可能であることが好ましい。インフォメーションエージェントは、スナップショットリスト内のエージェンシーと、最終エージェンシーの作成時刻と各エージェンシーのスナップショット時刻との間に作成された各エージェンシー内のエージェントのみを示すように、セマンティックエンバイロメントをフィルタリングする。
g. セマンティックエンバイロメント マネージャ
本発明は、セマンティックエンバイロメントのオブジェクトを管理するＡＰＩを公開するセマンティックエンバイロメント マネージャを提供する。好ましい実施の形態において、管理されたセマンティックエンバイロメントのオブジェクトは、主としてＳＱＭＬバッファを経由したエージェントの参照で構成される。セマンティックエンバイロメント マネージャは又、セマンティックエンバイロメントをナビゲートするためにＡＰＩを公開する。好ましい実施の形態において、セマンティックエンバイロメント マネージャでは、インフォメーションエージェントの実現値の以下の項目を可能にする。
1. セマンティックエンバイロメント マネージャでそれ自体を登録する− セマンティックエンバイロメント マネージャは、全ての開いたインフォメーションエージェントの実現値上で情報を保持することが好ましい。これは（クリップボードのアクセス、スマートレンズのアクセス等の）多数のサービスが、シェル拡張子のアプリケーション、ブラウザコントロール内で実行しているプレゼンタ構成要素等のアプリケーションにわたって行われるからである。例えば、プレゼンタが新しいＳＱＭＬ文書を表示領域に読み込む際に、セマンティックエンバイロメント マネージャからキャッシュエントリを取得する必要がある。プレゼンタは、セマンティックエンバイロメント マネージャに指定のＳＱＭＬバッファ用に新しいキャッシュエントリを作成するように要求する。セマンティックエンバイロメント マネージャは、キャッシュエントリを作成し、そのエントリに対応するファイルパスにＳＱＭＬバッファを書き込み、そのキャッシュエントリを指すＡｃｔｉｖｅＸコントロール、ダイナミックＨＴＭＬの動作、Ｊａｖａアプレット（又は相当するクライアントのランタイムエンジン）で初期化される一時ＨＴＭＬファイルを作成し、キャッシュエントリの識別子と一時ＨＴＭＬファイルへのファイルパスをプレゼンタに返す。例えば、好ましい実施の形態において、一時ＨＴＭＬファイルは以下のように名前をつけることができる。
c:＼windows＼temp＼nervana_39fc54bc-81e5-4954-8cef-3d1a54935a0d.htm
ここで 39fc54bc-81e5-4954-8cef-3d1a54935a0d はキャッシュエントリの識別子である。含まれるインフォメーションエージェントは（含まれるインフォメーションエージェントのコントロールのイベントを経由して）読み込まれる新しい文書を自動的に検出する。含まれるインフォメーションエージェントは、ユーザが（例えば、「エージェントとして保存」、又は「ブレンダーの中に保存」等の）「保存」をクリックした時に対応することができる。インフォメーションエージェントは、現在の文書のファイルパスを取得し、（ファイルパスは部分的に識別子で名前を付けられているので）ファイルパスからキャッシュエントリの識別子を取得し、ユーザが「名前を付けて保存」をクリックすると（名前、記述等の）キャッシュエントリ用のメタデータを表示することでこれを実現する。インフォメーションエージェントは、セマンティックエンバイロメント マネージャにキャッシュエントリを新しい名前で保存するように要求することもできる。インフォメーションエージェントは、実現値のプロセスＩＤで、セマンティックエンバイロメント マネージャを使って自己登録する（起動時が好ましい）。セマンティックエンバイロメント マネージャは、インフォメーションエージェント用に新しい識別子を割り当てて、（現在スマートレンズモードであるかどうかの等）インフォメーションエージェントの実現値のメタデータを格納する。インフォメーションエージェントはこの識別子を格納する。インフォメーションエージェントは呼び出しを行うごとに、セマンティックエンバイロメント マネージャに識別子を渡すことが好ましい。インフォメーションエージェントはこの識別子でプレゼンタを初期化する。好ましい実施の形態において、クライアントの枠組みはアプリケーション間のサービスが必要なたびに、識別子でセマンティックエンバイロメント マネージャを呼び出す。セマンティックエンバイロメント マネージャは、インフォメーションエージェントの処理の終了時に、全てのインフォメーションエージェントのエントリのごみ集めするために、インフォメーションエージェントの実現値の処理識別子を格納する。インフォメーションエージェントは終了時を「認識」しないかもしれないので、セマンティックエンバイロメント マネージャはインフォメーションエージェントのエントリを除去するためにこれを実現することが好ましい。
2. 新しいエージェントの参照をセマンティックエンバイロメントに追加する−エージェントの参照エントリはデータベース、ファイルシステム、又は（ウィンドウズのレジストリ等の）システムの格納内で格納されることが好ましい。好ましい実施の形態において、各セマンティックエンバイロメントのエントリは以下を含む。
a. Identifier−これはセマンティックエンバイロメント内でエージェントを一意的に識別する。
b. Name−これはエージェントの名前を指す。インフォメーションエージェントは、新しいエージェントが作成されると、デフォルトのエージェント名を設定する。このエージェント名は作成方法に基づいて設定される。例えば、文書「ｆｏｏ」がエージェント「ｂａｒ」上にコピーしてペーストされると、インフォメーションエージェントは（現在時刻の）「ｆｏｏ」に関連する「ｂａｒ」という一時的なエージェントの名前を作成できる。現在時刻は、（万一ユーザが同じ照会を再発行した時のために）一意的な名前が付けられたエージェントに格納される。ユーザはエージェントを希望通りの名前に変更できる。
c. Query Buffer−これはエージェント用にＳＱＭＬを含むバッファを指す。
d. Type−これは（スタンダードエージェント、ブレンダー、サーチエージェント、スペシャルエージェント等の）エージェントタイプを指す。
e. CreationTime−これはエージェントのエントリが作成された時刻を指す。
f. LastModifiedTime−これはエージェントのエントリが最後に修正された時刻を指す。
g. LastUsedTime−これはエージェントのエントリが最後に使われた時刻を指す。
h. UsageCount−これはエージェントが、単独で、フィルタとして、又はスマートレンズとして使われた回数を指す。
i. Attributes−これらは（通常、一時、仮想、及び削除用に印を付ける等の）エージェントの属性である。エントリが一時的であれば、ユーザがローカルのエージェントとして明示的に保存していないという意味である。一時的なエントリは、ユーザがドラッグ＆ドロップを使って複雑な照会を作成し、しかも仲介の照会をエージェントとして保存しない場合に使われることが好ましい。ユーザが照会をエージェントとして保存すると、インフォメーションエージェントは、クライアントのエントリが永久になったことを示す一時フラグをリセットする。
j. ReferenceCount−これは他のエージェントとブレンダーによってエージェントを参照する回数を指す。回数は新しいエントリの作成時に０に初期化される。
3. セマンティックエンバイロメントからエージェントを削除する−これは２段階で実現されるのが好ましい。エージェントは削除用に印を付けることができ、その場合、セマンティックエンバイロメント マネージャはエージェンシーのエントリが「ごみ箱」にあることを示すフラグを設定する。エージェントのエントリは又、永久に削除することができ、その場合エントリはキャッシュから全て除去される。
4. （ユーザのエージェント保存時にエージェント用の一時フラグをリセットする等の）セマンティックエンバイロメントにあるエージェントの特性を変更する。
5. セマンティックエンバイロメント内のエージェントの名前を変更する。
6. エントリを取得するために、キャッシュを以下と同様に列挙することが好ましい。
a. 全てのエージェント
b. 削除したエージェント
c. 最も頻繁に使ったエージェント
d. 最も最近使ったエージェント
e. 最も最近作成したエージェント
f. （文書、電子メール、イベント等の）前記のビューの下位にある各オブジェクトをフィルタリングする。
g. 前記のビューでエージェントをホストするエージェンシーをフィルタリングし、エージェンシー、及び（文書、電子メール等の）表示に適合するエージェント上のオブジェクトタイプをフィルタリングする。
h. （見出し、権威的、ニュースメーカー等の）コンテキストテンプレートに基づいたスペシャルエージェントをフィルタリングする。
図１２〜１４はこの列挙とビューを図示したもので、図１７〜１９は、セマンティックエンバイロメントのツリー ビューを示す。
7. インフォメーションエージェントの実現値からの呼び出しを経由して更新された回数に基づいたエージェントのリストをフィルタリングする−インフォメーションエージェントの各実現値は、１つのセマンティックエンバイロメント マネージャと通信することが好ましい。そのやり方では、更新はセッション主導ではなく、ユーザ主導となる。例えば、ユーザが１つのインフォメーションエージェントのエージェントを開くと、エージェントのエントリは、別のインフォメーションエージェント内の最近使ったエージェントビューに表示する。セマンティックエンバイロメント マネージャは各エージェントが使われた回数、各エージェントが使われた最後の時刻等に関する情報を管理する。エージェントをフィルタリングする。例えば、最も頻繁に使ったエージェントは、Ｎエージェントの最大の使用回数に基づいてフィルタリングされる。ここでＮは設定可能で、フィルタリングはある安定のための待ち時間（例えば、使用回数の合計が少なくともＹで、このＹも又、２週間の間にエージェントを使う予測回数等の簡単なヒューリスティック手法に基づいて設定可能である）が経過した後で適用される。最近使ったエージェントは、使用回数に基づいてフィルタリングされる（これはエージェント単位で格納され、エージェントが使用されるごとにインフォメーションエージェントの実現値によって更新される）。最近作成されたエージェントは、エージェントの作成時刻に基づいてフィルタリングがされる。削除したエージェントは、各エージェントの「削除用にマークを付ける」のフラグを調べることでフィルタリングされる。お気に入りのエージェントは、各エージェントの「お気に入りのマークを付ける」を調べることでフィルタリングされる。前記のそれぞれの親ビューに対して、基本ビューは簡単なフィルタを使ってデータが取り込まれる。エージェンシービューは、親ビューで返された各エージェントを調べて、そこから一意のエージェンシーを抽出することでデータが取り込まれる。そこで表示される各エージェンシーの下にあるオブジェクトタイプのビューは、次に（文書、電子メール、イベント等の）エージェントのオブジェクトタイプに基づいてエージェントをフィルタリングすることでデータが取り込まれる。ブレンダービューは、「ブレンダー」タイプを持つエージェントのみを表示することでフィルタリングされる。オブジェクトタイプビューは、エージェントのオブジェクトタイプを使って直接フィルタリングされる。「マイエージェンシー」ビューはローカルのエージェンシーを表示する。この下位の各ビューは、エージェンシーにある利用可能な各エージェントを使ってフィルタリングされたオブジェクトタイプのビューであることが好ましい。「文脈別」ビューは、（コンテキストテンプレートで作成されたものが好ましい）スペシャルエージェント用のみをフィルタリングし、（見出し、権威的等の）文脈名を調べることでデータが取り込まれる。
8. セマンティックエンバイロメント内のエージェントの参照数を管理する−文書エントリの参照数を増分及び減分するのは、呼び出し側の構成要素（インフォメーションエージェント）の役目である。インフォメーションエージェントは、ドラッグ＆ドロップ、コピー＆ペースト等の方法でこれを実現することが好ましい。言い換えれば、既存エージェントを参照する新しい照会を作成するアクションである。
9. セマンティックエンバイロメントを空にする−これは全てのエージェントを削除する。
10. ごみ集めを行う−セマンティックエンバイロメント マネージャは、全ての古い（及び一時的な）エージェントを自動的に削除する。キャッシュは、一定の期限までエージェントの履歴を保存するように設定してもよい。例えば、キャッシュが２週間分のエージェントの情報のみを保存するように設定されている場合、２週間以上期限が経っている一時エージェントを定期的に調べる。そのようなエージェントが見つかれば、参照の回数がゼロであるエージェントのエントリを自動的に削除する。これはインフォメーションエージェントが新しいキャッシュのエントリを作成しても、それを参照する別のエントリ（エージェント又はブレンダー）を作成しない場合に起こることが好ましい。言い換えれば、インフォメーションエージェントは（複雑にならないように）直接のリンクに対してリンク追跡を行う。
セマンティックエンバイロメント マネージャは詳細のごみ集めを行うこともできる。これは設定可能なスケジュールで定期的に起こる。これは参照数がゼロ以上で、しかも他のエントリが削除された時にリンクが管理されていなかったので実際に参照を持たないエントリに適用する。エージェントとブレンダーが保存、又は編集された時に、インフォメーションエージェントができればエージェントとブレンダーとの間を追跡しないので、複雑性を最小限に抑えるためにこの機能が好ましい実施の形態に組み込まれている。他の実施の形態においては、エージェントが起動した時に、プレゼンタはエージェントの遅延リンク追跡を行う。クライアントの枠組みは、セマンティックエンバイロメントから削除された全ての参照を無視する。これはリンクの１つが削除された時に、ウェブページが４０４（ファイルが見つかりません）のエラーを返すやり方に類似する。言い換えれば、本発明は不完全な照会の場合に備えている。一例として、以下のようなシナリオが考えられる。
ブレンダーＢ１−＞ブレンダーＢ２を参照ー＞エージェントＡ１を参照ー＞エージェントＡ２を参照
この場合、参照数の連鎖は４であるが、各エントリの参照数は１である。従って、参照の回数がゼロ以上でも、古いエントリを持つ可能性がある。ごみ集め対象の各エントリに対して、ガーベッジコレクタは全てのＳＱＭＬ文書内のエントリに対して参照がないか捜す。参照が見つからなければ、エントリ（一時的で期限よりも古いものは）除去される。 11. 通知管理を処理する−ユーザは、（保存された、又はローカルのエージェント、スタンダードエージェント、ブレンダー等の）セマンティックエンバイロメント内の任意のエージェントからの通知を登録できる。好ましい実施の形態において、通知方法は電子メール、インスタントメッセージ、ポケットベルへのメッセージ、テレフォニーのメッセージ等を含む。セマンティックエンバイロメント マネージャは、インフォメーションエージェント経由でユーザからの通知要求を管理する通知マネージャ（以下を参照）を含む。通知マネージャは通知要求のリストを格納する。通知要求は、（エージェントを識別する）セマンティックエンバイロメントのオブジェクトＩＤ、（電子メール、ＩＭ等の）通知タイプ、及び電子メールアドレス等の宛先を含むことが好ましい。通知マネージャは、新しいオブジェクトがあるかどうか「尋ねる」ために、通知要求リストの各エージェントを定期的にポーリングする。通知マネージャは又、（送り先のエージェントの刻時機構に基づいて）「最後に要求された時刻」を渡す。エージェントは（格納された照会を呼び出して、「最後に要求された時刻」以降に作成された照会結果にあるオブジェクトの数を渡すことで）新しいオブジェクトの数に対応する。エージェントは（刻時機構上の）現在時刻で対応する。通知マネージャは時刻の同期化の問題を避けるために、エージェントの時刻を格納する。あるいは、クライアントと全てのエージェンシーは、時刻を取得して全ての時刻の比較は同じ尺度によるものであることを確実にするために、同じタイムサーバ（タイムウェブサービス）を用いる。
エージェンシーディレクトリ−好ましい実施の形態において、セマンティックエンバイロメント マネージャは各エージェンシーの「ディレクトリ」用にエージェンシーのリストを管理することが好ましい。マルチキャストのネットワークは、セマンティックエンバイロメント マネージャをエージェンシーのディレクトリとして見ることが好ましい。好ましい実施の形態において、一般のシステム上のＸＭＬウェブサービスにＵＲＬで設定されたデフォルトのグローバルエージェンシー ディレクトリがある。このＸＭＬウェブサービスは、登録された全てのエージェンシーのキャッシュを格納する（ＩＤ、ＵＲＬ等、上記で説明した情報を含むことが好ましい）。ＸＭＬウェブサービスはエージェンシーに、その存在をエージェンシーディレクトリ上で登録可能にするメソッドを公開する。ＸＭＬウェブサービスは重複したエントリをフィルタリングする。ＸＭＬウェブサービスでは又、ユーザがエージェンシーディレクトリ上にある全てのエージェンシーを列挙できるメソッドを公開する。セマンティックエンバイロメント マネージャはこの方法でディレクトリを列挙する。インフォメーションエージェントは、エージェンシーディレクトリをセマンティックエンバイロメントの拡張機能として見なし、ユーザにエージェンシーディレクトリ上に載っているエージェンシー上のエージェントを参照して開くことを可能にすることが好ましい。ユーザは、内部ネットワークにインストールすることができるカスタムのエージェンシーディレクトリに、ＵＲＬを追加できることが好ましい。本発明は、カスタマイズ可能なエージェンシーディレクトリの作成と統合を意図する。これは本質的に、マルチキャストが（処理能力を管理する理由で）ネットワーク上で使用できない場合、又は広域ネットワーク上の特定のサブネットがマルチキャストをサポートしない場合は、発見用マルチキャストの使用に代わるものである。
h. 環境ブラウザ（意味論的ブラウザ又はインフォメーションエージェント（Ｉｎｆｏｒｍａｔｉｏｎ Ａｇｅｎｔ(登録商標)）
環境ブラウザ、又はインフォメーションエージェントは、（インターネットエクスプローラ、ＡｃｔｉｖｅＸコントロール等の）通常のウェブブラウザの構成要素をホストし、ＳＱＭＬファイルを取得しプレゼンタを経由して結果を表現することが主な役割である。好ましい実施の形態において、これは、ＳＱＭＬファイルのＳＱＭＬ文書のキャッシュエントリへの参照と一緒に初期化されたローカルのＨＴＭＬファイルを開くことで行われる。ＨＴＭＬファイルは（ＡｃｔｉｖｅＸ、Ｊａｖａ、インターネットエクスプローラの動作等の）コントロールを通してプレゼンタに読み込む。このコントロールは（セマンティックエンバイロメント マネージャを経由して）キャッシュからＳＱＭＬ文書を取得して、上記で説明したようにＳＱＭＬファイルを読み込む。コントロールは、オブジェクトがＸＨＴＭＬ（又は、できれば現在のＸＳＬＴ及び/又はスクリプトベースのスキンを経由した提示形式に同等物）に変換可能であることを示したリソースからのコールバックを受信すると、オブジェクトをウェブブラウザの文書オブジェクトモデル（ＤＯＭ）に追加して、表示のためにＤＯＭに送り込む。インフォメーションエージェントではユーザは、（キャッシュＩＤを経由して）キャッシュ内のＳＱＭＬファイル、又はエントリを開くことができる。インフォメーションエージェントは又、ユーザが前後にナビゲートしたり、スタック内にある最初の文書をナビゲートしたりできる（現在のウェブのブラウザでの「戻る（Ｂａｃｋ）」、「進む（Ｆｏｒｗａｒｄ）」、「ホーム（Ｈｏｍｅ）」の選択肢に類似するが、ＨＴＭＬと他の文書とは対照的に、この場合ＳＱＭＬ文書は（結果の）解釈と表示用に開くことが違う）。
図６０〜６８は本発明の好ましい実施の形態によるインフォメーションエージェントの画面図を示す。図６０は、ユーザが、新しいスペシャルエージェント、新しいブレンダー、又は新しいローカルのエージェンシーを作成するために、例えば、ダムエージェント経由で、セマンティックエンバイロメントの中にローカルの検索結果をインポートできるツールを持つ、ツールバーのポップアップメニューを示すセマンティックエンバイロメントの画面図である。あるいは、これらのツールは、ユーザが作成希望のエージェントタイプ（ダム、スマート、スペシャル）、又はエージェンシーを選択することができるウィザードを呼び出す１つのツールボタンに縮小可能である。図６１は、ユーザがキーワードを使ってセマンティックエンバイロメントを検索できるダイアログ例を示す。これは（適切なＳＱＭＬで）新しいスマートエージェントを作成する。ユーザは新しいスマートエージェントの名前のカスタマイズ化、及び任意選択の記述の追加ができることが好ましい。図６２は、ユーザが新規作成、又は開いたエージェントを永久に（例えば、「お気に入り」リスト等）セマンティックエンバイロメントに保存、又はエージェントをブレンダーに保存ができるようにする、ツールバーの「保存」ツールポップアップのメニューの選択肢を示す。図６３は、ユーザに（スマートエージェント、又は現在クリップボード上にあるオブジェクトに基づいて）スマートレンズの起動を可能にするツールバーのスマートレンズのツールメニューの選択肢を示す。これはユーザがクリップボードのコンテンツをスマートレンズとして使いたいことをプレゼンタに伝える。プレゼンタは（マウス等で）ユーザがマウスカーソルを合わせている任意のオブジェクト用に、スマートレンズの機能を自動的に起動することが好ましい。メニューは又、ユーザが明示的にスマートレンズをオフにするまで、スマートレンズを（エージェントのナビゲーションをにわたってでも）オンの状態を保持する「スマートレンズとしてペーストして固定」の選択肢を示す。図６４は、ユーザがセマンティックエンバイロメントからサーバ側エージェントを開いて、（大きなアイコン、小さいアイコン、リスト等の）環境「ビュー」を変更する方法を示す「エージェントを開く」ダイアログの画面例である。図６５は、ユーザがファイルシステムからの「通常の」文書を、インフォメーションナーバス システムのセマンティックエンバイロメントにインポートする方法を示す標準のウィンドウズの「開く」ダイアログを示す。ダムエージェントは文書の参照に作成される。ダムエージェントが起動されると、文書はインフォメーションエージェント内で開けられ、（スマートコピー＆ペースト、コンテキストテンプレート等の）意味論的ツールの全てが文書と共に利用可能となる。これはブラウザが、ファイルシステム上の通常の「無能な」文書を意味論的に「スマート」にする方法を示す。図６６はユーザがローカルのファイルシステム上のフォルダにある文書を検索して、セマンティックエンバイロメントにインポートを可能にする、カスタムの「フォルダの文書を開く」ダイアログを示す。これは、（例えば、スマートコピー＆ペースト、コンテキストテンプレート等の）インフォメーションナーバス システムの意味論的ツールを経由して文書を「公開する」ことで、その文書を「スマート」にする。図６７はユーザが参照の選択肢を選択すると表示される「フォルダを参照」ダイアログボックスを示す。これはユーザに（ローカルのファイルシステムから）フォルダを開ける選択を可能にする。図６８はユーザが標準のブレンダーと仮想ブレンダーのどちらかを作成するよう選択できる、「ブレンダーの追加」ウィザードからのページを示す。
i. 付加的なアプリケーションの機能
アプリケーションのメニューの拡張機能と他の枠組みの機能−システムのクライアントは、プログラムによる拡張機能をサポートして、しかもまだクリップボードへのデータのコピーはサポートしないアプリケーションへのメニューの拡張機能をインストールすることが好ましい。これには、マイクロソフトウィンドウズのメディアプレーヤと（電子メールメッセージのヘッダ用の）マイクロソフトのアウトルック等のアプリケーションが含まれる。好ましい実施の形態において、メニューの拡張機能は「コピー」を読み込む。システムはＸＭＬオブジェクトとして選択されたオブジェクトを、ウィンドウズのシステムのクリップボードにコピーする。例えば、電子メール用のシステムプラグインであるマイクロソフトのアウトルックは、選択された電子メールオブジェクトを電子メールＸＭＬオブジェクトとしてコピーする。クリップボードをすでにサポートするアプリケーションには拡張機能は必要としない。
サーバ側のお気に入りのオブジェクト−ユーザ状態をサポートするエージェンシー上で、ユーザはオブジェクトを「お気に入り」としてマークを付けることができる。オブジェクトがお気に入りとして印を付けられると、プレゼンタはエージェンシーのＸＭＬウェブサービス上のメソッドを起動する。ＸＭＬウェブサービスは、ユーザオブジェクトと照会を受けているオブジェクトとの間に意味論的なリンクを追加する。好ましい実施の形態において、ユーザは All.MyFavorites.All Default Agent を経由してお気に入りのオブジェクトを表示できる。このエージェントは、お気に入りの印が付けられた全てのオブジェクトを返す。エージェンシー管理者は、 All.MyFavorites.Technology.XML.All 等のサブエージェントを作成することができる。
プレゼンタはユーザがお気に入りのマークを付けたり、マーク解除したりできる。これは又、サーバとエージェンシーが書き出す構造を再定義する方法である。「お気に入り」のシナリオを使うことは、ユーザが興味のあるオブジェクトを見て、それを直ちにナビゲートしたくない場合に特に有用である。お気に入りの機能は、エージェンシーがオブジェクトをユーザに推薦するため使用することもできる。好ましい実施の形態において、この推薦オブジェクトは All.Recommended.All Agent を経由して取得可能である。エージェンシーは、主としてユーザがお気に入りと印を付けたオブジェクトに基づいてオブジェクトを推薦する。サーバ側のお気に入りは又、「お気に入り」、権威的、及び推薦のコンテキストテンプレートと一緒に使われることが好ましい。
エージェントのスクリーンセーバー−本発明の好ましい実施の形態は、ユーザに任意の会員登録したエージェントをスクリーンセーバーとして選択可能にする。ユーザは、エージェントが機密事項を取り扱うデータを公開する可能性があることの警告を受けて、特定のエージェントをスクリーンセーバーとして使うことが安全かどうかを決める機会が与えられることが好ましい。好ましい実施の形態において、システムのクライアントは会員登録した任意のエージェントをスクリーンセーバーとして読み込むことができる。他の実施の形態においては、ユーザは希望のスクリーンセーバーの表示を備えるためにエージェントを組み合わせてもよい。あるいは、スクリーンセーバーは、例えば、画面を四分割したそれぞれの領域にエージェントを平行に表示することを含む構造化されたスキンでもよい。
エージェントのエージェント用スマートレンズ−他の実施の形態においては、システムのクライアントは、別のエージェント、又はブレンダーを起動するための文脈として、（エージェント、又はブレンダーのどちらかを通して起動された）スマートレンズの使用をサポートする。例えば、ユーザは、優先度が非常に高く、更に送り先のエージェントが理解する全てのオブジェクトを探し出すために、All.CriticalPriority.All を選択して、そのエージェントを All.Understood.All を参照するためのスマートレンズとして使用することを希望するかもしれない。
スマートレンズのユーザインターフェース例の説明−図６９〜７１は、本発明によるインフォメーションエージェントのスマートレンズの機能に関連した吹き出しポップアップメニューの例を示す。図６９はスマートエージェントをスマートレンズとして、文脈リゾルトペイン内の吹き出しポップアップメニューの例を示す。これはユーザが情報オブジェクト上のスマートレンズのアイコンを選択した際に表示されるポップアップウィンドウである。これは、スマートレンズのタイトルが「 [Ｎｅｒｖａｎａの私のＵＩ仕様] に関するロイターの文書」がクリップボード上にあり、「Ｎｅｒｖａｎａのユーザインターフェースに関するユーイングの考え」とタイトルが付けられた電子メールオブジェクト上にスマートレンズとして「投稿」された場合を示す。図７０は、オブジェクトをスマートレンズとして（エージェント上で「マウスカーソルを合わせた」）文脈リゾルトペイン内の吹き出しポップアップメニューの例を示す。これは、スマートレンズが内包的（ A[SMART LENS] B = B [SMART LENS] A ）である場合を示す。文脈ペインの結果の部分は、図６９に示す例を同じであり、好ましい実施の形態におけるスマートレンズは、内包的であることを示す。図７１は情報オブジェクトをスマートレンズとして、情報オブジェクトを「レンズを置かれた」項目とした文脈リゾルトペイン内の吹き出しポップアップメニューの例を示す。この例では、「Ｎｅｒｖａｎａの私のＵＩ仕様」のタイトルが付いたオブジェクトがクリップボードにコピーされ（オブジェクトのＳＱＭＬ表現）、「Ｎｅｒｖａｎａのユーザインターフェースに関するユーイングの考え」（電子メールオブジェクト）というタイトルの（リゾルトペイン内にある）別なオブジェクト上にスマートレンズとしてペーストされている。この例では、ユーザは文書と電子メールメッセージの組み合わせで意味論的に一致する述語を選択する選択肢を持つ。図７２は、図７１の吹き出しポップアップメニューの別な例で、（スマートレンズのオブジェクトと「レンズを置かれた」オブジェクトの）２つのオブジェクトの関連性尺度を百分率とグラフ表示の両方で示す。この例では棒グラフで示す。
図７３〜７５はスマートレンズを用いた場合の、オブジェクトタイプと述語を含む動作と関係を説明した表である。図７３は、スマートレンズの動作が例えば、A[Smart Lens]B = B[Smart Lens] A のように可換である全ての情報用の「エージェントとオブジェクト」のシナリオを示す。図７４と７５は、ここでもスマートレンズの動作が例えば、A[Smart Lens]B = B[Smart Lens] A のように可換である、それぞれ文書と電子メール用の「オブジェクトとオブジェクト」のシナリオを示す。
ブレンダースキンのユーザインターフェースの説明−図７６は、意味論的結果のプレーヤー／プレビューコントロールを図解するユーザインターフェースの例である。インフォメーションエージェントのプレゼンタは、この制御を各リゾルトペインに添付することが好ましい。プレーヤー／プレビューコントロールはユーザに、リゾルトペイン内の結果をナビゲートして、（再生、停止、一時停止、変更、高速化等の）結果をアニメーション化する、及び（ブレンダーの結果の場合等の）結果のフィルタリングを可能にする。図７７はブレンダーの意味論的結果を示すユーザインターフェースの一例である。この例において、ブレンダースキンは、ブレンダーの各エージェント用に個別のフレームとして表示領域の部分に保留して、各フレームにプレーヤー／プレビューコントロールを添付する。それによって、ユーザにブレンダー内の各エージェントの結果を個別にナビゲート、制御、アニメーション化を可能にする。あるいは、ブレンダースキンは（１つのプレーヤー／プレビューコントロールが添付された）ブレンダー内の全てのエージェントからマージされた結果の表示、及び情報オブジェクトのタイプ等に従ったフレーム結果の表示が可能である。
複数のドラッグ＆ドロップ−他の実施の形態においては、システムのクライアントではユーザはデスクトップから複数の文書、又はフォルダを選択して、エージェント又はブレンダー上で関係照会の基本として使用できる。これはユーザが複数の文書を洗練化のツールとして結果の精度を高めることができる。例えば、ユーザは（各文書をフィルタとして用いることで）結果を論理和、又は論理積の演算をするのかを示すこともできる。これは（オブジェクト上でリンクがドラッグされた）１つのリソースを持つＳＱＭＬファイル、及び（文書ごと又はドラッグしたオブジェクトごとの）複数のリンクを作成する。クライアントのＳＱＰはこれを、全てのオブジェクトのフィルタ用にＸＭＬ形式メタデータを取得し、ＸＭＬ引数で送り先のスマートエージェントのＸＭＬウェブサービスを呼び出すことで解釈することが好ましい。好ましい実施の形態において、エージェンシーのＸＭＬウェブサービスはＸＭＬ形式メタデータの引数をカテゴリ化して、照会を適切なＳＱＬによる表現に形成して、結果を返す。
ＵＲＬのショートカットの規則−本発明のエージェンシーは、インターネットのウェブがウェブのアプリケーションとして任意的にインストールされているので、それを共有することもできる。その結果、エージェンシーは（通常のＨＴＴＰのＵＲＬ等の）ウェブの命名体系を使って参照することもできる。好ましい実施の形態において、本発明はショートカットの命名規則とインフォメーションエージェントのセマンティックエンバイロメントに固有であるＵＲＬを公開する。
・ エージェントのショートカットのＵＲＬの規則−エージェントのショートカットのＵＲＬの規則は以下の通りである。
agent://<agentname>@<agencyurl>?start=<start>&end=<end>&skin=<skin urlL>
起動すると、これは、以下に挙げる例のような完全修飾のＨＴＴＰのＵＲＬにマッピングされることが好ましい。
http://<path to Agency ASP; or CGI script>?agentname=<agentname>& start=<start>&end=<end>&skin=<SkinUrl>.
エージェントのショートカットのＵＲＬの規則の一例は以下の通りである。
agent://email.technology.wireless.all@marketing.abccorp.com?start=0&end=25&skin=http://www.nervana.net/skins/email/abcemailskin.xslt
このＵＲＬは、クライアントによって次のように解決される。ウェブサービスのプロキシを開始する、ＷＳＤＬファイルの http://abc.com/nervanaroot/webservice.wsdl を開いて、ウェブサービスに Marketing と名付けられたエージェンシーの統計のウェブサービスを尋ねる。ＨＴＴＰのアクセスの場合、これはＡＳＰ、又はＣＧＩへのパスで解決される。以下は一例である。
http://abccorp.com/marketingagency.asp?urltype=agent&agentname= email.technology.wireless.all& start=0&end=25&skin=http://www.nervana.net/skins/email/abccorpemailskin.xslt
開始引数は、最初にオブジェクトのゼロベースの開始索引を返すことを示す。終了引数は終了索引を示す。スキンのＵＲＬは任意的である。スキンのＵＲＬが指定されていない場合、クライアントはエージェントのデフォルトスキンでエージェントを読み込む。ローカルに保存されたエージェントは、agent://<agentname>@localhost でアクセスしてもよい。例えば、agent://Documents.[Related to My Business Plan]@localhost はローカルに保存された（マイエージェント内の） Documents.[Related to My Business Plan] と名付けられたエージェントを読み込むことになる。
・ エージェンシーのＵＲＬの規制−以下はその一例である。
agency://<agencyname>.<domainname>?query=getproperties|getstats|getagents@agentviewfilter=<agentviewfilter>&agentnamecontainsfilter=<agentnamecontainsfilter>&agenttypefilter=<agenttypefilter>&agentobjecttypefilter=<agentobjecttypefilter>
この例では、照会の引数は getproperties である。ＵＲＬは（例えば、ローカル、又は遠隔のどちらかにある名前、ビュー名等の）エージェンシー自体の特性を取得する。あるいは、特性が getstats であれば、ＵＲＬは（エージェント合計数、スタンダードエージェント数、コンパウンドエージェント数、ドメインエージェント数、オブジェクト合計数、文書オブジェクト数、電子メールオブジェクト数等の）エージェンシーの統計を取得する。好ましい実施の形態において、 getproperties のフラグがデフォルトであり、つまり他の引数が指定されていない場合は特性が取得される。getproperties 又は getstats の引数のどちらかが指定される場合、他の引数が同時に指定されないことが好ましい。
agentviewfilter の引数は任意選択で、呼び出し側が検索を限定するためにエージェントビュー内で特定することを可能にする。例えば、エージェントビュー「ロイターニュース」は、ロイターからの新しいオブジェクトを管理するエージェントのみを返すようにサーバにインストールすることもできる。agentnamecontainsfilter の引数は任意選択で、ユーザはエージェント名用の検索文字列で結果をフィルタリングできる。agenttypefilter は任意選択で、ユーザは（スタンダードエージェント、コンパウンドエージェント、又はドメインエージェントの）エージェントタイプに基づいてエージェントをフィルタリングできる。agentobjecttypefilter の引数は任意選択で、ユーザは（電子メール、文書、人等の）エージェントが管理するオブジェクトタイプで結果をフィルタリングできる。以下のような例を含む。
agency://sales.boeing.com?query=getstats (corresponding to the HTTP URL http://boeing.com/salesagency.asp?urltype=agency&query=getstats)
agency://sales.boeing.com?agenttypefilter=standard&agentobjecttypeidfilter=events (corresponding to the HTTP URL http://boeing.com/salesagency.asp?urltype=agency&agenttypefilter=standard&agentobjecttypeidfilter=events
・ オブジェクトのＵＲＬの規則−エージェンシーのオブジェクトはクライアントから直接アクセス可能である。ＵＲＬの規則は以下の通りである。
objects://<querystring><agencyname>.<domainname>?querytype=<objectid|searchstring>&objecttypefilter=<objecttypefilter>
objecttypefilter の引数は任意選択で、オブジェクトタイプによって返されたオブジェクトのフィルタリングに使用できる。これは（文書、電子メール、イベント等の）既知のオブジェクトタイプの列挙である。以下のような例を含む。
objects://34547848@support.attwireless.com?querytype=objectidはobjectid34547848でオブジェクトを返す。
objects://80211@support.attwireless.com?querytype=searchstring&objecttype=email は照会文字列 80211 に一致する電子メールオブジェクトを返す。
・ カテゴリのＵＲＬの規則−ＵＲＬの規則は以下の通りである。
category://<<categoryname>@<kbsurl>?semanticdomainname=<semanticdomainname>semanticdomainname の引数は任意選択である。好ましい実施の形態において、省略された場合は、ＫＢＳのデフォルトのドメインが選択される。一例は以下の通りである。
category://technology.wireless.all@abccorp.com/marketingknowledge.asp
これは、abccorp.com/marketingknowledge.asp ウェブサービスにインストールされた知識ベース上にあるデフォルトのドメイン用の Technology.Wireless.All カテゴリに対応する。これは http://abccorp.com/marketingknowledge.asp?category=“technology.wireless.all. のようなＨＴＴＰのＵＲＬに解決されることになる。カテゴリが完全修飾されたＵＲＬの一例は以下の通りである。
category://technology.wireless.all@abccorp.com/marketingknowledge.asp?semanticdomainname="/InformationTechnology"
クライアント情報の共有とローミング−好ましい実施の形態において、ユーザは（ブレンダーを含む）エージェントを電子メール経由、インスタントメッセージ等で他者と共有することができる。ローカル情報を使用するユーザは、エージェントの情報をローカルに格納する、又は（部門全体のローミング用にウィンドウズ２０００でＡｂｃｃｏｒｐｌｉＭｉｒｒｏｒサポートを経由して、（身分証明にパスワードを使用して）グローバルエージェンシー ディレクトリ上にある独自仕様のＸＭＬウェブサービスを経由して、又はマイクロソフトのパスポート身分証明サービスを採用するマイクロソフトドットネットのマイサービスとの統合を介して）、ユーザと共に情報をローミングするかのいずれかを行うことが好ましい。
ローカルのエージェンシー−システムのクライアントでは又、ユーザがＫＩＳのローカル実現値を「マイエージェンシー」のリストに実行するローカルのエージェンシーを作成及び追加できることが好ましい。この実施の形態において、クライアントは又、ユーザが個人的なエージェンシーを削除できるようにする。
ユーザ経験の整合性と秩序の非破壊性−本発明のインフォメーションエージェント（意味論的ブラウザ）は整合性があり、秩序を破壊しないユーザ経験を提供する。言い換えれば、インフォメーションエージェントは現在のウェブのブラウザとシームレスに共存する。「戻る（Ｂａｃｋ）」、「進む（Ｆｏｒｗａｒｄ）」、「ホーム（Ｈｏｍｅ）」、「停止（Ｓｔｏｐ）」、「更新（Ｒｅｆｒｅｓｈ）」、「印刷（Ｐｒｉｎｔ）」等のツールは、ユーザを混乱させないように現在のウェブのブラウザと同様な操作をすることが好ましい。ツールの多くは、機能性は異なるが同じである。更に、新しいツールがツールバーと意味論的ブラウザの新しい機能性を反映するメニューの選択肢に追加されることが好ましい（これらの新しいツールは画面図のツールバーを観察することで見ることができる）。
図７８と７９は、比喩の整合性を保持しながら、新しい機能性をユーザに提供するための好ましいマッピングを具体的に説明することで、本発明の機能性のマッピングの例を示す。図７８は現在のウェブのブラウザ用と、本発明のインフォメーションエージェントの好ましい実施の形態とのデフォルトのユーザインターフェースのツールセットの比較を示す。図７９はマイクロソフトエクスプローラ／ドキュメントビューアのファイルシステム用と、本発明のインフォメーションエージェントの好ましい実施の形態とのデフォルトのユーザインターフェースのツールセットの比較を示す。
5. 本発明での文脈の提供
a. コンテキストテンプレート
本発明は、情報のアクセスと取得のために、特定の意味論的モデルをマッピングするコンテキストテンプレート、又はシナリオ主導情報の照会テンプレートを提供する。本質的にコンテキストテンプレートは、事前定義済み意味論的テンプレートを用いることで、ユーザに情報を配信する個人的でデジタルの意味論的な情報取得「チャネル」として考えることができる。好ましい実施の形態において、意味論的ブラウザ３０は、ユーザにエージェントの特性を初期化するために、コンテキストテンプレートを使って新しい「スペシャルエージェント」の作成を可能にする。コンテキストテンプレートは、１つ以上のエージェンシーから情報を集約することが好ましい。
一例として、本発明は以下のコンテキストテンプレートを定義する。意味論的な情報の多種多様のタイプの統合と流布に関する付加的なコンテキストテンプレートは、本発明の範囲内として意図される（その例として、「怒った」、「悲しい」等の感情に関するコンテキストテンプレート、場所、機動性、周囲の状態、ユーザの作業用等のコンテキストテンプレートが挙げられる）。
「見出し」のコンテキストテンプレート−見出しのコンテキストテンプレート（及びその結果生じるスペシャルエージェント）は、意味論的な情報の伝達方法という点で、ＣＮＮの「ヘッドラインニュース」番組の個人的なデジタル版に喩えることができる。コンテキストテンプレートはユーザに、情報の作成、又は公開時刻と、情報の「新鮮さ」を定義する設定可能な時間の量に従って並べ替えられた１つ以上のエージェンシーから情報の見出しのアクセスを可能にする。例えば、ＣＮＮの「ヘッドラインニュース」は（一日中）３０分ごとに見出しを表示する。好ましい実施の形態において、本発明のインフォメーションエージェント３０は、以下に説明するフィルタとパラメータを使って、ユーザが見出しのスペシャルエージェントを作成できるようにする。
・ インフォメーションオブジェクト ピボット−結果としてのブレンダーはこれらのオブジェクトに関連する結果を示す。これは任意選択のパラメータである。指定がない場合、見出しは（オブジェクトに基づいたフィルタなしで）全体のエージェンシー用に表示される。
・ 所定の「新鮮さ」の期間−例えば、３０分、１時間等。
・ 述語−これは取得される情報へのインフォメーションオブジェクト ピボットのリンクの方法を定義する。例として、「関連する」、（テキストベースの検索を使う）「可能性として関連する」、（人がオブジェクトの場合の）「作成した」、「可能性として作成した」、「次に関する専門知識を持つ」が挙げられる。デフォルトの述語は、「に関連する」がデフォルト設定で使われることが好ましい。このデフォルトの述語は、特定の述語に知的にマッピングされることでエージェンシーによって解決される。
・ エージェンシー−これには、見出しを調べるエージェンシーを含む。少なくとも１つのエージェンシーが指定される必要があり、指定できるエージェンシーの数は無制限である。ユーザは「最近の」及び／又は「お気に入り」のリストの全てのエージェンシーが使用されるべきかを示すこともできる。
・ カテゴリリスト−Technology.Wireless.All が一例である。これは照会の付加的なフィルタとして動作する。
新鮮さに加えて、見出しのコンテキストテンプレートは、結果のランク付けを決めるために結果の項目がどのくらい「今はやり」かを組み込むことが好ましい。これはエージェンシー上にある意味論的に関連したオブジェクト数を調べるために、エージェンシーに照会することで実現する。これはオブジェクトのトピックが「今はやり」であるかを知るためのよい指標である。更に、返されたオブジェクト（あるいは項目）は新鮮さ別で、又は新規別で並べ替えることが好ましい。
一例として、本付属書類の実例Ｄは、好ましい実施の形態の見出しのコンテキストテンプレートからのＳＱＭＬ出力を示す。この例では、コンテキストテンプレートは、３０分という新鮮さの時間の間隔と、（意味論的な照会を示す）「関連する」の述語で、（マーケティング、研究、営業、及び人事）の４つの異なるエージェンシーから全ての情報を取得する。好ましい実施の形態において、この例のＳＱＭＬは、全てのコンテキストテンプレートに関する限りでは、意味論的ツールボックスのスマートレンズ、スマートコピー＆ペースト、ドラッグ＆ドロップ、及び他のツールの基礎を任意選択として形成することもできる。
「最新ニュース」のコンテキストテンプレート−最新ニュースのコンテキストテンプレート（及びその結果生じるスペシャルエージェント）は、意味論的な情報伝達方法の点で、通常設定された番組に割り込んでくる、ＣＮＮの「ブレイキングニュース」番組速報の個人的なデジタル版に喩えることができる。ＣＮＮの「ブレイキングニュース」の速報のように、このコンテキストテンプレートはユーザに、１つ以上のエージェンシーからの「最新」で、時間が重要な情報へのアクセスを可能にする。その情報は、情報の作成又は公開時刻、あるいは（イベントの場合は）イベントの発生時刻で並べ替えられ、イベントにおける時間の重要度を定義する設定可能な「締め切り時刻」と、新鮮度を定義する設定可能な時間の量が含まれていることが好ましい。例えば、コンテキストテンプレートは１時間以内に投稿された情報オブジェクト、又は次の１日以内に起こるイベントをフィルタリングするように定義することができる。
好ましい実施の形態において、最新ニュースのコンテキストテンプレートはブレイキングニュース エージェントとは異なる。コンテキストテンプレートは、１つ以上のエージェンシーに渡される静的な照会のパラメータを定義するテンプレートである。ブレイキングニュース エージェントは、ユーザが作成したかもしれないスマートエージェントで、本質的にユーザが作成したものでカスタマイズ可能である。一例として、最新ニュースのコンテキストテンプレートに基づいた最新ニュースのスペシャルエージェントではユーザは、ローカルの文書（又は指定があれば、他の局所的文脈）に関して１時間以内に投稿された情報オブジェクト、又は翌日に行われるイベントを伝達してもよい。しかしブレイキングニュース エージェントは、「自分のチームの一員による無線技術に関するイベントで、次の２４時間以内にシアトル又はポートランドで開催され、自分のハードドライブのこの文書に関連するイベント」に対する警告を受信する柔軟性をユーザに提供する。ブレイキングニュース エージェントは、ユーザに最新ニュースのコンテキストテンプレートよりもはるかに大きな柔軟性と個人化を提供する。最新ニュースのコンテキストテンプレートの利点は、典型的なユーザにとって「最新」としての条件に入るパラメータを使って、できれば組み込み警告用の基礎を形成することである。
「会話」のコンテキストテンプレート−会話のコンテキストテンプレート（及びその結果生じるスペシャルエージェント）は、意味論的な情報の伝達方法の点で、ＣＮＮの「クロスファイア」番組の個人的なデジタル版にに喩えることができる。会話と討論を情報流布の文脈として使う「クロスファイア」のように、好ましい実施の形態において、会話のスペシャルエージェントは関連ある情報用に電子メールの投稿、注釈付加、及びスレッドを追跡する。会話のコンテキストテンプレートは、電子メールオブジェクトタイプでフィルタリングされた見出しのコンテキストテンプレートとして考えることもできる。「見出し」のパラメータに加えて、会話のコンテキストテンプレートは以下のパラメータを含むことが（任意選択であるが）好ましい。
・ 返すスレッドの最小長−ユーザは最低１つの応答、２つの応答等、希望する電子メールのスレッドを示すこともできる。多くの場合、スレッド数は意味論的の重要度の目安を提供する。デフォルトはゼロである。
・ 配信リストフィルタ−ユーザは返された電子メールを、「差出人」、「宛先」、「ＣＣ」、又は「ＢＣＣ」の行に１つ以上の配信リストの会員を持つものに限定することもできる。これは優先グループ、部門等からの討論を監視したいユーザの希望を可能にする。
・ 配信行フィルタ−ユーザは返された電子メールを、「差出人」、「宛先」、「ＣＣ」、又は「ＢＣＣ」の行にフィルタの電子メールアドレスを持つものに限定することもできる。返された項目は新鮮さに基づいて、又は会話のスレッドの深さに基づいて並べ替えることもできる。
「ニュースメーカー」のコンテキストテンプレート−ニュースメーカーのコンテキストテンプレート（及びその結果生じるスペシャルエージェント）は、意味論的な情報伝達方法の点で、ＮＢＣの「ミートザプレス」番組の個人的なデジタル版に喩えることができる。この場合、重要視されるのはニュース自体、又は会話ではなく、「ニュースの渦中にいる人」である。ユーザは返された人をインフォメーションオブジェクト ピボットとしてネットワークをナビゲートする。ニュースメーカーのコンテキストテンプレートは、「People」又は「User」のオブジェクトタイプのフィルタと、「作成した」、「可能性として作成した」、「ホストした」、「注釈付加した」、「次に関するエキスパート」等の述語（人を情報に関連付ける述語）をできれば持っている、見出しのコンテキストテンプレートとして考えることもできる。「関連する」のデフォルトの述語は、密接な関係を持つ指定の述語を全て対象とするために使うことが好ましい。「ニュースメーカー」等の関連する情報の並べ替えの順番は、見出し等の作られるニュースの順番に基づいて並べ替えられる。見出しのコンテキストテンプレートのパラメータに加えて、ニュースメーカーのコンテキストテンプレートは以下のような任意選択のパラメータを含むことが好ましい。
・ 配信リストフィルタ−ユーザは返された電子メールを、「差出人」、「宛先」、「ＣＣ」、又は「ＢＣＣ」の行に１つ以上の配信リストの会員を持つものに限定することもできる。これは優先グループ、部門等からの討論を監視したいユーザの希望を可能にする。
・ 配信行フィルタ−ユーザは返された電子メールを、「差出人」、「宛先」、「ＣＣ」、又は「ＢＣＣ」の行にフィルタの電子メールアドレスを持つものに限定することもできる。
「今後のイベント」のコンテキストテンプレート−今後のイベントのコンテキストテンプレート（及びその結果生じるスペシャルエージェント）は、今後のイベントに関する情報を伝達する、特別番組の個人的なデジタル版に喩えることができる。イベントの特別番組に含められる例としては、「全米プロ野球のワールドシリーズ」、「ＮＢＡバスケットボールの決勝戦」、「サッカーのワールドカップ決勝戦」等が挙げられる。知識労働者のシナリオでは、１つ以上のカテゴリ、文書、又は他のインフォメーションオブジェクト ピボットに関する業界の今後のイベントの全てを監視したいユーザがそれに相当する。今後のイベントのコンテキストテンプレートは、今後のイベントがフィルタリングされて、（できればイベントと時間の重要度を内包する意味論的に適切な「文脈スキン」を使って）表示されることを除いては、見出しのコンテキストテンプレートと同一であることが好ましい。返されたオブジェクトは、最も差し迫ったイベントを一番始めに、時間の重要度に基づいて並べ替えられることが好ましい。
「発見」のコンテキストテンプレート−発見のコンテキストテンプレート（及びその結果生じるスペシャルエージェント）は、「ディスカバリチャンネル」の個人的なデジタル版に喩えることができる。この場合は、特定のトピックに関する「ドキュメンタリー」が重要視される。「ヘッドラインニュース」の場合とは異なり、意味論的な情報のアクセスと取得用の主軸は時間ではなく、むしろ、カテゴリを取り囲む情報の知的な集約を持つ１つ以上のカテゴリである。本発明の好ましい実施の形態において、発見のコンテキストテンプレートは、ある一組のカテゴリに関連し、任意選択で所定の設定可能な期間以内に投稿された情報オブジェクトを無作為に選択することで、情報の知的な集約をシミュレートする。任意選択で設定可能な期間は存在するが、時間ではなく意味論的な重要度が、情報の順番と表示の方法を決めるのに優先する考慮事項である。本発明は異なる軸の使用が可能で、「発見される」カテゴリ用の意味論的な重要度、時間、無作為性、又はすべの軸の組み合わせ（この場合は「発見」の効率が上がると見られる）が例として挙げられる。発見のコンテキストテンプレートは、新鮮さの時間の間隔が、エージェントが返すべき（エージェンシーに投稿された）情報の最大限の経過時間を示す、任意選択の最大限の経過時間に取り替えられることを除いては、見出しのコンテキストテンプレートと同じパラメータを持つことが好ましい。
「履歴」のコンテキストテンプレート−履歴のコンテキストテンプレート（及びその結果生じるスペシャルエージェント）は、「ヒストリーチャンネル」の個人的なデジタル版に喩えることができる。この場合重要視されるのは、特定のトピックに関しての情報の流布だけでなく、履歴の文脈も持つ情報の流布である。このテンプレートの好ましい軸は、カテゴリと時間である。履歴のコンテキストテンプレートは、更に「最小の経過時間の制限」に合わせたた発見のコンテキストテンプレートと似ている。パラメータは、「最大限の経過時間の制限」パラメータが「最小限の経過時間の制限」パラメータ（又は任意選択の「履歴の時間の間隔」パラメータ）に取り替えられることを除いては、発見のコンテキストテンプレートと同じことが好ましい。更に、返されたオブジェクトは、システム内での経過時間、又は作成以後の経過時間に基づいて、逆の順番で並べ替えられることが好ましい。
「全ての予想」のコンテキストテンプレート−全ての予想のコンテキストテンプレート（及びその結果生じるスペシャルエージェント）は、意味論、又はキーワード、あるいはテキストベースの検索に基づいて関連した任意の情報を返す文脈を表す。この場合重要視されるのは、文脈にわずかでも関連する可能性がある情報の流布である。全ての予想のコンテキストテンプレート用の主軸は、単なる関連性の可能性であることが好ましい。好ましい実施の形態において、全ての予想のコンテキストテンプレートは、関連性の可能性がある、できる限り広範囲の結果を返すために、意味論とテキストベースの照会の両方を用いる。
「最も確実な予想」のコンテキストテンプレート−最も確実な予想のコンテキストテンプレート及びその結果生じるスペシャルエージェント）は、関連性が高い情報のみを返す文脈を表す。好ましい実施の形態において、重要視されるのは、関連性が高く意味論的に重要であるとみなされる情報の流布である。このコンテキストテンプレートの主軸は関連性である。本質的に、最も確実な予想のコンテキストテンプレートは、テキストベースの照会結果の関連性は保証できないので、意味論的な照会を用い、テキストベースの照会は用いない。最も確実な予想のコンテキストテンプレートは、カテゴリのフィルタ、又はキーワードで初期化されることが好ましい。キーワードが指定される場合は、サーバによって動的にカテゴリ化が行われる。結果は関連性の得点、又はオブジェクトからカテゴリのフィルタへの「カテゴリに属する」意味論的なリンクの強度に基づいて並べ替えられることが好ましい。
「お気に入り」のコンテキストテンプレート−お気に入りのコンテキストテンプレート（及びその結果生じるスペシャルエージェント）は、「お気に入り」又は「人気のある」情報を返す文脈を表す。この場合重要視されるのは、他者から支持され好意的に認められた情報の流布である。好ましい実施の形態において、お気に入りのコンテキストテンプレートの軸は、読者層の興味の度合、オブジェクトにつけられた「批評」、及びオブジェクト上にある注釈付加のスレッドの深さを含む。１つの実施の形態において、お気に入りのコンテキストテンプレートは、「お気に入り」の意味論的なリンクを持つ情報のみを返し、（この意味論的なリンクに基づいて）オブジェクトの「投票」数の回数別で並べ替えられる。
「権威的」のコンテキストテンプレート−権威的のコンテキストテンプレート（及びその結果生じるスペシャルエージェント）は、「一流な」情報、又は価値があると認められる情報を返す文脈を表す。お気に入りのコンテキストテンプレートと同様に、重要視されるのは、他者から支持され好意的に認められた情報の流布である。このコンテキストテンプレートの好ましい軸には、履歴の文脈、読者層の興味の度合、オブジェクトにつけられた「批評」、及びオブジェクト上にある注釈付加のスレッドの深さを含む。権威的のコンテキストテンプレートは、お気に入りのコンテキストテンプレートに基づき、しかも本質的に「古いお気に入り」のコンテキストテンプレートとして機能する、付加的な最小限の経過時間のフィルタで実装されることが好ましい。
「推薦」のコンテキストテンプレート−推薦のコンテキストテンプレート（及びその結果生じるスペシャルエージェント）は、「推薦された」情報、又はエージェンシーがユーザに興味があるだろうと推測した情報を返す文脈を表す。推薦は「推薦」の意味論的なリンクを、「セマンティックリンク」の表に追加して、ユーザが示すお気に入りの意味論的なリンクを掘り下げることによって挿入される。推薦は機械学習、及び協調フィルタリング等の技術を使って行われることが好ましい。このコンテキストテンプレートで重要視されるのは、ユーザが興味を持つ可能性があり、しかもまだ見たことがないであろう情報の流布である。このコンテキストテンプレートの主軸には、興味と新鮮さの見込みを含むことが好ましい。好ましい実施の形態において、コンテキストテンプレートはセマンティックエンバイロメント内のエージェンシー上で主な述語のフィルタとして、PREDICATETYPEID_ISLIKELYTOBEINTERESTEDIN の述語を持つＳＱＭＬを生成することで実装される。
「今日」のコンテキストテンプレート−今日のコンテキストテンプレート（及びその結果生じるスペシャルエージェント）は、「今日」投稿された、又は（イベントの場合は）行われる情報を返す文脈を表す。このコンテキストテンプレートで重要視されるのは、できれば新鮮さを判断するためのフィルタは「今日」に基づいて現在であると見なされた情報の流布である。好ましい実施の形態において、今日のコンテキストテンプレートの結果は、結果が「今日」投稿された、又は「今日」行われるイベントが表示される見出しのコンテキストテンプレートの結果のサブセットである。
「バラエティ」のコンテキストテンプレート−バラエティのコンテキストテンプレート（及びその結果生じるスペシャルエージェント）は、無作為の情報を返す文脈を表す。このコンテキストテンプレートは、ユーザができるだけ広範囲の情報の項目を取得するために、無作為の情報の流布が重要視されることが好ましい。好ましい実施の形態において、主軸は「無作為な」項目が（「関連する」の述語を用いて）意味論的に照会のフィルタに関連しているにもかかわらず、無作為性である。
b. 文脈スキン
本発明は「文脈スキン」と呼ばれる特別なクラスのスキンを含む。文脈スキンは提出する文脈の意味論を伝達する提示情報を含む。例えば、今日のコンテキストテンプレートの文脈スキンは、真夜中を指している時計、あるいは他の「今日」の表現で、背景又はフィルタの効果を表示することができる。あるいは別な例として、バラエティのコンテキストテンプレートの文脈スキンは、（結果の無作為性を示した）ボーリングのボールが無作為に転がるような変換効果を示すことができ、最新ニュースの文脈スキンは、文脈の重要性を示すのに点滅している文字、救急車の赤灯等で効果と軽いアニメーション化を示すことができ、履歴の文脈スキンは、古い車、時計等で「経過時間」を表すグラフィックスを示すことができる。
文脈スキンは表示されるオブジェクトタイプの提示テンプレートを「重んずる」ことが好ましい。例えば、電子メールオブジェクトは、コンテキストテンプレートを示すグラフィックスに加えて、切手又は郵便配達車を示す背景で表示されることができる。コンテキストテンプレートの中にはエージェンシー間にまたがるものがある、つまりオントロジ間をまたがるので、（業界の情報等の）オントロジを示す情報を表示する必要がない。しかしながら、カテゴリのフィルタで初期化された文脈スキンは、コンテキストテンプレートのカテゴリ又はオントロジを示すことが好ましい。一般的にこれは、オントロジの業界又は分野を示すグラフィックス要素（及びフィルタ、変形等）で表される。例えば、医薬品の文脈スキンは実験器具を、石油とガスの文脈スキンは石油掘削リグを、スポーツの文脈スキンはスポーツ用品を示す等のフィルタ効果を持つことができる。
c. スキンテンプレート
本発明はユーザに、当座の作業に応じた異なるタイプのスキンの選択を可能にする。柔軟性のある提示を持つことは、ユーザが現在の作業に基づいて最適な提示モードを選択できることを意味する。例えば、ユーザがメインのマシンで作業を行っている時、生産性が最も重要で効果があまり重要ではないところでは、かすかなスキンを選択することができる。ユーザは、生産性が又重要で、効果も又同様にあった方がいい場合には、中程度のスキンを選択することができる。例えば、ユーザが周辺視野で情報を閲覧しており、音声合成のような機能で最新ニュースの警告を受けることが重要な場合には、ユーザは第二マシンのようなシナリオには、刺激的なスキンを選択することができる。刺激的なスキンは、アニメーション化、詳細情報用のストーリーボードのような効果、モーションパスに表示されたオブジェクト、及びその他の効果を取り扱うことができる。刺激的なスキンはスクリーンセーバーと一緒に使われる可能性が大きい。スキンはユーザによって設定できることが好ましい。
d. デフォルトの述語
好ましい実施の形態において、各オブジェクトタイプは他のオブジェクトタイプとリンクするデフォルトの述語を含む。これは、意味論的なリンク用に使う述語を個別に評価する必要なく、オブジェクトを動的にリンクする直感的な方法をユーザに提供する。例えば、文書のオブジェクトから文書を返すエージェントへのドラッグ＆ドロップの操作は、「関連する」と「可能性として関連する」の述語を持つことが可能である。文書のオブジェクトが、文書のエージェントの上にドラッグされると、本発明の意味論的ブラウザはユーザが意味論的な照会に使う述語を選択できる、ポップアップメニューの選択肢を表示する。他の実施の形態においては、例えば、ユーザがリンク又は述語のテンプレートを選択できる最初のポップアップメニュー、選択したテンプレートの実際の述語を表示する子ポップアップメニューのような他の関連したポップアップメニューを組み込んでもよい。デフォルトの述語は、照会が呼び出される対象となる、動的に生成されたＳＱＭＬに挿入されることが好ましい。
一例として、デフォルトの述語は「関連する」であってもよい。この述語は、ドラッグされるオブジェクトに関連する文書のエージェント内にある情報を返す照会にマッピングされる。この場合デフォルトの述語を持つ利点は、本発明の意味論的ブラウザが、この述語を使って照会を呼び出すことになる「開く」ポップアップメニューを表示できることである。意味論的ブラウザは、特定の述語がありサブメニューの選択肢を持つ「リンクで開く」と名付けられたポップアップメニューを表示することもできる。デフォルトの述語はシステムを使いやすくする。なぜなら、ユーザは、デフォルトのオブジェクトが、ソースオブジェクトとその対象となるエージェント又はオブジェクトを考慮すると賢明な選択であることを承知して、動的リンクを使ってシステムを参照することができるからである。
ドラッグ＆ドロップのシナリオで使われる以外に、デフォルトの述語は、スマートレンズ、スマートコピー＆ペーストで使用することもできる。デフォルトの述語は、文脈を考慮すると「正しいこと」を返すスマートなリンクを劣化させたものに喩えられる。デフォルトの述語は「関連する」であることが好ましい。これは意味論的距離が１つに対する適切な照会結果として「正しいこと」を生み出す可能性がある。他の実施の形態においては、デフォルトの述語はいくつかの特定述語のマージであってもよい。例えば、文書から人へのドラッグ又はドロップ、コピー又はペースト、あるいはスマートレンズ用のデフォルトの述語は、「関連する」で、ＫＩＳエージェンシーのＸＭＬウェブサービスによって、例えば、「作成した」、「次に関するエキスパート」、及び「注釈付加した」の述語が含まれるカスケード式照会として解釈されることができる。言い換えれば、「関連性」は本発明によってスマートに解釈されて、異なる述語のマージを生じる可能性がある。デフォルトの述語は、ユーザがシステムを素早く、効率よく、ほとんど考えることなくナビゲートできるようにする。
デフォルトの述語はシステムに簡素化を提供し、直感的に使うことができる。更に、ユーザは「起動する」という１つの述語しかない現在のウェブ上でＨＴＭＬのリンクを起動することにすでに慣れているので、デフォルトの述語はユーザにとって使いやすい。
e. 文脈述語
文脈述語は、抽象化の上位レベルで定義された述語で、コンテキストテンプレートの該当するサブセットにマッピングされる。文脈述語はユーザに、下位レベルシステムの述語に基づくのではなく、コンテキストテンプレートに基づいた述語のフィルタの選択を可能にする。照会が文脈述語で起動されると、コンテキストテンプレートのフィルタのパラメータで含まれるＳＱＭＬをフィルタ処理することにより、新しいＳＱＭＬ照会が生成される。例えば、文脈述語の「最も確実な予想」は、同じ名前のコンテキストテンプレートにマッピングして、「最も確実な予想」な情報オブジェクト（一般的に、テキストベースの照会からではなく、意味論的な照会から返された項目である）で照会をフィルタ処理する。同様に最新ニュースの文脈述語は、項目が最新ニュースのコンテキストテンプレートのフィルタ条件を満たすかどうかに基づいて、フィルタ処理を行う。一般に、文脈述語はコンテキストテンプレートと整合性のあるオブジェクトタイプに適用される（例えば、文脈述語「エキスパート」及び「ニュースメーカー」は「Person」のオブジェクトを返す照会にのみ有効である）。
f. 文脈属性
文脈属性は「仮想的な属性」で、エージェンシーがクライアントに返す各ＸＭＬオブジェクトの部分としてキャッシュされる。このような属性は、結果が表示される現在の文脈を反映するので動的である。例えば、適所で文脈属性の「最も確実な予想」が、現在の照会のＳＱＭＬ内の意味論的な照会を満たす各ＸＭＬの結果に添付される。デフォルトの述語を持つ意味論的な照会結果は、意味論的と非意味論的（テキストベースの照会）の両方の結果を含む可能性がある。照会を処理するエージェンシーは、結果のオブジェクトをフィルタとして、ＳＱＭＬ上の意味論的な副照会を実行することにより、「最も確実な予想」であるＸＭＬ結果用の文脈属性をキャッシュすることもできる。この場合、「オブジェクト」用のスキーマと派生のタイプは、（「最も確実な予想」の属性、「見出し」の属性等の）それぞれ該当するコンテキストテンプレートの属性フィールドを含むべきである。これが好ましい実施の形態である。あるいは、意味論的ブラウザがエージェンシーを呼び出して、それぞれのＸＭＬオブジェクトを引数として渡し、オブジェクトが文脈属性を満たすかどうかを「尋ねる」。他の例では、オブジェクトが現在の照会の文脈内で「見出し」として適格であるかどうかを示す見出しの文脈属性、「権威的」の属性等が挙げられる。意味論的ブラウザは、文脈属性が設定されているかどうかを示すユーザインターフェースを表示すべきである。
文脈属性は、システムを使いやすくするという点で、従来のシステムより更なる利点を提供する。例えば、ユーザは、（エージェンシーがクライアントからＳＱＭＬ引数を受け取るとエージェンシーによって処理される）意味論的と非意味論的の両方の照会フィルタを含む、関係照会を生成するために、ドラッグ＆ドロップの操作を行うことができる。１つの実施の形態において、ブラウザは広範囲の照会、又は「最も確実な予想」な照会を希望するのかをユーザに「尋ねる」。このモードでは、ユーザは照会が発行される前に、効果的に付加的なフィルタを適用する。あるいは、意味論的ブラウザと連携したエージェンシーは、広範囲の照会結果を返し、又各結果を文脈属性と、各結果のオブジェクトが「広範囲」か「最も確実な予想」であるかどうかを示す対応するユーザインターフェースで修飾することが好ましい。「Person」のオブジェクトタイプのような他のオブジェクトタイプも同じことが適用される。ユーザが、人のエージェントへの関係照会は「作成者」、「エキスパート」又は「注釈付加者」が返されるべきかどうかを示すのではなく、ブラウザが広範囲の照会を発行することができ、それからそれぞれ返された「Person」のオブジェクトが現在の文脈用に「作成者」、「エキスパート」、又は「注釈付加者」であるかどうかの結果を（エージェンシーの助けを借りて）限定することができる。
g. 文脈パレット
文脈パレットは本発明の非常に強力な機能で、意味論的ブラウザ内で現在選択されたオブジェクト用にコンテキストテンプレートを動的に起動する。本質的に、文脈パレットは、ユーザがリゾルトペイン内の任意のオブジェクトを選択すると自動的に起動し表示されることが好ましい。文脈パレットはユーザが、現在表示されている結果の文脈が自由に使えるように常時保持できるようにする。更に、意味論的ブラウザは現在選択されたオブジェクト用に常にパレットを更新するので、オブジェクトの文脈は常時最新のものであることを保証する。好ましい実施の形態において、これは更新のアクションを発生させる刻時機構を経由して、又は最後にパレットが更新されて以降、新しいオブジェクトが存在するかどうかを文脈パレット用のＳＱＭＬ照会プロセスに照会を発行ことによって実現する。
好ましい実施の形態において、情報オブジェクトがメインのリゾルトペインに表示されるのと同様に、情報オブジェクトと同様に、文脈パレットに表示された結果は、「第一種」の情報オブジェクトである。言い換えれば、文脈パレットの結果は、スマートコピー＆ペースト、スマートレンズ、ディープインフォメーション等の本発明の全ての意味論的ツールで使用されることが好ましい。本発明において他の文脈のペインで表示される結果もできれば同様に当てはまることが意図される。
本発明は以下の文脈パレットを含むことが好ましい。好ましい実施の形態において、ユーザは選択したオブジェクト用に異なる文脈パレットを「スクロール」する選択肢を持つ。付加的で異なる文脈パレットを組み込むことも明示的に意図しており、付加的なコンテキストテンプレートと平行する可能性がある。
「見出し」の文脈パレット−これは見出しのコンテキストテンプレートを用い、現在選択されたオブジェクトとの付加的なリンクで、見出しのコンテキストテンプレートのＳＱＭＬと、オブジェクトタイプの組み合わせ用のデフォルトの述語を持つＳＱＭＬを採用する。特にＳＱＭＬは、セマンティックエンバイロメント内にある全てのお気に入りのエージェント、又は最近のエージェントをマッピングするリソースを引き起こすことになる。ユーザは、文脈パレットを生成する際に、フェイバリットエージェント、最近のエージェント、又は両方の使用を希望するのかを設定する。更に、見出しの文脈パレットは又、表示されるオブジェクト数用のフィルタなしで、又は「新鮮さ」の時間制限用のフィルタなしで見出しを表示する設定が可能である。この場合、パレットはユーザが公開又は投稿時刻で並べ替えられた関係のある結果をナビゲートできるようにする。
「最新ニュース」の文脈パレット−オブジェクトタイプの組み合わせのデフォルトの述語を使って、セマンティックエンバイロメント内にある全てのブレイキングニュース エージェントから関係のある結果と、現在選択されたオブジェクトとリンクされた関係のある結果を含む。更に、デフォルトの最新ニュースの文脈パレット用の結果が表示される。本発明の意味論的ブラウザは、ブレイキングニュース エージェントと同数（及び同一）のリソース、又はリンクの組み合わせと、デフォルトの述語と（ファイルパス、フォルダパス、object://URL 等）の現在選択されたオブジェクトのリソースの修飾子を持つ付加的なリンクで、動的にＳＱＭＬを生成する。本発明の意味論的ブラウザは、生成されたＳＱＭＬ照会を起動し、ＳＲＭＬの結果でパレットのウィンドウを読み込む。最新ニュースの文脈パレットは、ユーザが文脈パレット内の結果をナビゲートできるようにするために、ナビゲート制御を含むことが好ましい。
「会話」の文脈パレット−見出しの文脈パレットと類似しているが、会話のコンテキストテンプレートを用いる。
「ニュースメーカー」の文脈パレット−見出しの文脈パレットと類似しているが、ニュースメーカーのコンテキストテンプレートを用いる。
「今後のイベント」の文脈パレット−見出しの文脈パレットと類似しているが、今後のイベントのコンテキストテンプレートを用いる。
「発見」の文脈パレット−見出しの文脈パレットと類似しているが、発見のコンテキストテンプレートを用いる。
「履歴」の文脈パレット−見出しの文脈パレットと類似しているが、履歴のコンテキストテンプレートを用いる。
「全ての予想」の文脈パレット−見出しの文脈パレットと類似しているが、全ての予想の文脈パレットを用いる。
「最も確実な予想」の文脈パレット−見出しの文脈パレットと類似しているが、最も確実な予想のコンテキストテンプレートを用いる。
「お気に入り」の文脈パレット−見出しの文脈パレットと類似しているが、お気に入りのコンテキストテンプレートを用いる。
「権威的」の文脈パレット−見出しの文脈パレットと類似しているが、権威的のコンテキストテンプレートを用いる。
「推薦」の文脈パレット−見出しの文脈パレットと類似しているが、推薦のコンテキストテンプレートを用いる。
「今日」の文脈パレット−見出しの文脈パレットと類似しているが、今日のコンテキストテンプレートを用いる。
「バラエティ」の文脈パレット−見出しの文脈パレットと類似しているが、バラエティのコンテキストテンプレートを用いる。
「時系列」の文脈パレット−この文脈パレットは見出し、最も確実な予想、履歴、及び、今後のイベントのコンテキストテンプレートをマージした結果を含むことが好ましい。時系列の文脈パレットはユーザが、現在選択されているオブジェクトに基づいて意味論的な時系列上の全てのオブジェクトをナビゲートできるようにすることが好ましい。時系列は公開／投稿の時刻に基づいた情報の項目、予約の時刻に基づいたイベントの項目等を含むことができる。本質的に、時系列の文脈パレットで、ユーザは情報伝達の主要軸として時間を使って、関連した（及び、できれば他の意味論的に関連した）オブジェクトをナビゲートする。
「ガイド」の文脈パレット−本発明の好ましい実施の形態は、統合したガイドの文脈パレットを含む。この文脈パレットは全ての文脈パレットを組み合わせている。言い換えれば、ガイドの文脈パレットの各ウィンドウは、他のそれぞれのシステムの文脈パレットからの結果１つに対応する。ガイドの文脈パレット用のユーザインターフェースは、ユーザが、各ウィンドウの各文脈パレット用の結果をスクロールしたり、例えば、フェードインとフェードアウトの技術等のアニメーション技術を使って結果をアニメーション化できるようにする。ガイドの文脈パレットの好ましい使用は、最小のビュー領域で現在選択されたオブジェクトの文脈を表示することである。好ましい実施の形態において、ユーザは全ての文脈パレットを（縦に、横に、斜め等に）並べて表示する、ドッキングする、又は他の配置形式の選択肢を持つ。
文脈パレットのユーザインターフェース−文脈パレットのユーザインターフェースは、現在表示のエージェント用のレイアウトスキンに基づいて設定可能であることが好ましい。好ましい実施の形態において、文脈パレットはリゾルトペインの左側、右側、上部、又は下部にドッキングさせてもよい。文脈パレットはビュー領域への侵入をできるだけ少なくするために縮小、あるいは動的に全画面に再度拡大できる。スキンは、文脈パレットのウィンドウを多種のサイズ、又は前もって設定、固定のサイズにサイズ変更することもできる。あるいは、スキンの中には、文脈パレットの結果をアニメーション化することもできる。
一例として、図８０はエージェントの結果とそれに対応する文脈パレットを示すユーザインターフェースを示す。この例では、いくつかの文脈パレットが縮小され、文脈パレットは表示、又はリゾルトペインの右側に縦にドッキングされるようにスキンされる（又は提示される）。
h. 組み込み警告
好ましい実施の形態において、ブレイキングニュース エージェントに加えて、本発明は組み込み警告を提供する。概念上ブレイキングニュース エージェントに類似するが、組み込み警告は基本的に操作が異なる。ブレイキングニュース エージェントの場合、本発明は、ユーザが指定した各ブレイキングニュース エージェントをポーリングして、急に入ってきた現在のオブジェクトに関連があるかを検索するために照会した後で、最新ニュースの通知に関してユーザに信号を送る。組み込み警告は、ユーザにブレイキングニュース エージェントを指定することを必要とせず、又は別は方法で最新ニュースの通知を発生するために任意のアクションを行う。組み込み警告は、基本的で本来備わっている方法で未解決のオブジェクトに関するイベントがある時は、（現在表示されている全てのオブジェクトに対して）ユーザインターフェースで自動的に信号を送る。例えば、現在のオブジェクトが文書である場合、本発明が文書の出所のエージェンシーをポーリングして、そのオブジェクトに関連する情報がエージェンシー上に最近投稿されたかどうかをエージェンシーに尋ねる。現在のオブジェクトが人の場合、本発明はエージェンシーをポーリングして、その人が最近電子メールを送信したか、最近文書を投稿したか、最近文書に注釈付加をしたか、最近配信リストに入会したか、又は退会したか等を尋ねる。これはユーザが、時間に敏感な方法で、オブジェクトのネイティブな文脈内で、適所での情報を持つことができるようにする。
好ましい実施の形態において、組み込み警告用のデフォルトの実施は、オブジェクトの出所のエージェンシーのみをポーリングする。これはユーザインターフェースを簡素化する利点がある。つまり、ユーザがエージェンシーを間にわたって照会を行いたいのであれば、関係照会を起動するために、ドラッグ＆ドロップ、コピー＆ペースト等の選択肢を持つ。他の実施の形態においては、組み込み警告は、最新ニュースの通知を検索するために、オブジェクトの出所以外のエージェンシーを含んで、最新ニュースのエージェンシーをポーリングすることになる。
他の実施の形態においては、本発明はユーザがオブジェクトにアクセスしたかどうかに関する情報を保持するように設定することができる。これは、ユーザがどの電子メールメッセージを読んだのかを電子メールサーバが把握する方法に喩えられる。エージェンシーがオブジェクト単位で、ユーザごとのサポート側の状態をサポートする実施の形態において、エージェンシーはユーザがアクセスした、又は読んだ問題のオブジェクトに関するエージェンシー上の情報が存在する場合にだけ、エージェンシーが「組み込み最新ニュース」があることを示すので、組み込み警告は常に正確である。この代替方法は、ＳＱＭＬ照会上の付加的なフィルタ処理の手段で実現することが好ましい。
本実施の形態で必要とされる、オブジェクト単位でユーザごとのサーバ側の状態の代替方法は、特にエージェンシーにとって莫大な量の情報を持つことになり、（インターネットベースのエージェンシー等の）莫大な数のユーザを持つことになるので不利となる。この場合、状態がオブジェクト単位でユーザごとに管理されているのであれば、システムは十分に規模の変更ができない。
エージェンシーがオブジェクト単位でユーザごとの状態をサポートしない他の実施の形態においては、エージェンシーは、組み込み警告用の静的な新鮮さの時間制限で設定できる。例えば、サーバは３０分の新鮮さの時間制限で設定することができ、その場合サーバは、照会オブジェクトに関連する新しいオブジェクトが到着した３０分以内に、組み込み警告が受信されると、肯定的な表現で応答することになる。好ましい実施の形態において、ＫＩＳエージェンシーは情報の平均到着率に関する情報を管理する。このやり方では、使用中のサーバは、新しい情報をたまにしか受信しないサーバよりも、新鮮度の時間制限が低くなる。平均到着率は警告の信号が送られるべきかどうかの概算のみを発行するので、サーバがオブジェクト単位でユーザごとの状態の保管をした場合は、この実施の形態はあまり正確でない。しかしながら、この実施の形態は情報損失の減少につながる。好ましい実施の形態において、本発明は（警告が最も良い推測にすぎない等の）の確率的な性質を示唆する押しつけがましくない方法で、組み込み警告の信号を送ることもできる。
i. スマート推薦
スマート推薦は、インフォメーションオブジェクト ピボットとしてオブジェクトを使い、推測された意味論的なリンク用に、意味ネットワークに意味論的な照会を表現する。例えば、インファレンスエンジンは、ユーザが、過去の出席したイベントに基づいて、イベントの提示者と多くの電子メールの会話を交わしたという事実に基づいて等で、特定のイベントに出席を希望すると推測することができる。一例として、好ましい実施の形態において、この情報は、図８１に示すスマート推薦ポップアップの文脈リゾルトペインで利用できる。これはユーザが推薦のコンテキストテンプレートを背景にして指定のオブジェクトを閲覧するのに似ている。
好ましい実施の形態において、各リンクはオブジェクトスキン、又は特別の推薦情報ペインのスキンによって生成され、推測された意味論的なリンクの述語を含んだＳＱＭＬにリンクされる。
6. 本発明の持つ特性の利点
本発明のインフォメーションナーバス システムは適切な文脈、意味、データと情報への効果的なアクセスを提供し、ユーザに行動可能な知識の取得を可能にする。インフォメーションナーバス システムが現在のウェブと概念上の意味論的ウェブよりも優位な点の多くは、図８２に示す技術階層の使用に由来する。本発明のさまざまな実施の形態は、統合されたシームレスな実装の枠組みとその結果としての知識の取得、管理及び伝達のメディアを作り出すために必要な特性に関するので優位性を明示する。これには、意味論的／意味、文脈依存性、時間への敏感さ、自動かつ知的な発見の容易性、動的リンク、ユーザ制御のナビゲーション及びブラウジング、非ＨＴＭＬ及びローカルの文書のネットワークへの参加、表示情報の意味論をスマートに伝達する柔軟性のある提示、論理と推測と推論、柔軟性のあるユーザ主導の情報分析、柔軟性のある意味論的な照会、読み取り／書き込みのウェブ、注釈付加、「信用の輪」、情報パッケージ（「ブレンダー」）、コンテキストテンプレート、及びユーザ主導の情報集約が含まれる。
意味論的／意味
本発明は、意味論的なリンク、オントロジ、及びＸＭＬを使用した十分に定義されたデータのモデルを採用する。その結果、上記で説明したエージェンシーは意味論を含む情報を持つ意味論的なウェブのサイトの力を持つ。更に、ＸＭＬウェブサービスの組み込み部分として意味を提供することにより、主題に関連付けた文脈依存性、時間への敏感性等を提供する。
文脈依存性
上記で説明した知的なシステムであるエージェントは、ユーザの個人的な文脈を監視して、特定の文脈に関連した、関連情報が情報源上にある場合は、ユーザに自動的に警告を出す。一例として、特定の文脈は以下を含む可能性がある。
・ マイドキュメント
・ マイウェブポータル
・ マイお気に入りのウェブサイト
・ マイ電子メール
・ マイ連絡先
・ マイカレンダー
・ マイ顧客
・ マイ音楽
・ マイ場所
・ 「この」文書
・ 「この」ウェブサイト/ページ
・ 「この」電子メールのメッセージ
・ 「この」連絡先
・ 「この」私のカレンダーのイベント
・ 「この」顧客
・ 「この」音楽曲、アルバム、又はプレイリスト
本発明は、サーバ１０と関連付けた情報のエージェントの使用を経由して、及び意味論的ブラウザ３０と関連したＸＭＬウェブサービスを経由して文脈依存性のユーザ経験を提供する。例えば、ユーザは、（ファイルシステム、マイクロソフトアウトルック等のアプリケーションの孤立集団から）「マイドキュメント」、「マイ電子メール」等内にある情報を、意味論的に関連ある情報を持つ遠隔の情報源と自動的に結合する。ユーザは、この結合を、例えば、ドラッグ＆ドロップ、スマートレンズ、スマートコピー＆ペースト等の上記で説明した新しい照会ツール等の意味ネットワークの上部に存在するアプリケーションレベルの革新を通して、リアルタイムで行う柔軟性を持つ。このようなアプリケーションのツールは、例えば、現在のウェブの現存するブラウザに組み込まれるような、意味ネットワークから独立して使用が可能であることも意図される。
好ましい実施の形態において、本発明のＫＩＳは、意味論的な情報を、意味論的ウェブ、又は（できればＲＤＦのプラグイン経由で）意味論的なマークアップで他のレポジトリから、意味ネットワークに引っ張ってくる。あるいは、本発明のシステム１０は意味論的ウェブなしで存在する。この場合、ＫＩＳは（電子メール、文書等）のシステム管理者が選択するデータソースから（個人的な意味論的なウェブ等の）自らの意味ネットワークを構築する。本発明のシステム１０は、（意味論的ウェブを任意選択で含むことができる）意味論的なバックエンドで実際の意味論的なアプリケーションを利用することができる。システム１０はこのようにして、（専有の意味論的ブラウザ３０を含む）クライアント側のアプリケーション、記憶場所追跡のツール等、及び（意味論的ウェブが記述しない）専有のＸＭＬウェブサービスとの統合を経由して文脈依存性を提供する。より具体的には、概念上の意味論的ウェブが意味論的なリンクと知識表現のアーキテクチャを記述する一方で、文脈依存性、時間への敏感さ、動的リンク、コンテキストテンプレート、文脈パレット等を提供するためにＸＭＬウェブサービスを使用するシナリオと革新に対処していない。それとは対照的に、本発明は意味論的なデータモデルと意味ネットワークを経由して意味論的なリンクに対処すると同時に、独自仕様のＸＭＬウェブサービスとの統合を経由して、文脈依存性、時間への敏感さ、意味論的な照会、動的リンク、コンテキストテンプレート、文脈パレット等のためのソフトウェアサービスを提供する。
時間への敏感さ
本発明は時間への敏感さが組み込まれた概念を持つ。例えば、ブレイキングニュース エージェント、最新ニュースのコンテキストテンプレート、最新ニュースの文脈パレット、及び組み込み警告等の時間への敏感さに関する機能を提供することで、本発明は意味論と表示の要素としての時間の重要性を明示する。普遍的に真実ではないが、一般的に言って、古い情報は新しい情報ほど妥当性がない。例えば、ＣＮＮが最新ニュースを見せるためにニュース番組を中断すると、中断は意味論（表示される最新ニュースの妥当性）とニュースが実際に入ってくる事実の組み合わせに基づいたものである。ウェブ作成者が特別に時間で優先順位をつけた分析を組み入れるような稀な場合を除いて、警告と提示の軸としてのこの時間への敏感さの要素は、完全に現在のウェブと概念上の意味論的ウェブには欠けている。
本発明はユーザが、スマートエージェントをブレイキングニュース エージェントとして選択できるようにする。表示される任意の情報は、最新ニュースのエージェント上での関連のある最新ニュースがあると警告を示す。例えば、本発明において、ユーザはエージェントを「今日ロイターに投稿された全ての文書」又は「コンピュータテクノロジ関連で２４時間先にシアトルで行われる全てのイベント」をブレイキングニュース エージェントとして作成することができる。このようなエージェントは個人的なので（「最新」は主観的でユーザ次第である）、ブラウザは一意的に個人的なサポートを提供する。又別な例において、シアトルのユーザは２４時間先のシアトルで行われるイベント、（安い航空券が見つかる時間帯で）来週西海岸で行われるイベント、（大半の米国航空会社の大陸横断便の割安チケットを得るための事前通告期間である）１４日先に米国で行われるイベント、（おそらくホテルの予約に時間が必要なので）来月に欧州で行われるイベント、及び６カ月先に世界のどこかで行われるイベントに関する通知を予定することができる。
本発明は更に、ユーザが作成できるブレイキングニュース エージェントに基づいて、最新ニュースのコンテキストテンプレートをサポートする。その上、本発明は、ユーザが「最新ニュース」のテンプレートに基づいた定義の文脈で、表示された全ての結果を閲覧できる最新ニュースの文脈パレットをサポートするので、文脈と時間への敏感さをシームレスで知的に統合する。
本発明は更に履歴の分析用に、強力な個人的な時系列データの分析（ｈｉｓｔｏｒｉａｎ）ツールを提供する。履歴の参照、過去のイベント、及び文書の作成時刻を使って、システム１０は、イベント詳細を再表示することで、例えば「１９９８年６月１日から１９９９年６月１日に設計会議に出席した同僚」の照会結果を表示することによって、不良のメモリを補正することができる。あるいはシステムは、イベントの塊りを検索することもできる。例えば、検索者は、「２００１年７月１日から２００１年９月１１日までの航空会社株に関連する一千万ドル以上の全ての株式取引」、又は「このイベントに関して１０日以内に作成された全ての文書を表示」を検索することもできる。
自動かつ知的な発見の容易性
本発明のシステム１０は、発見が組み込まれた概念を持つ。好ましい実施の形態において、ＫＩＳはローカルのマルチキャストネットワーク上、（ＬＤＡＰのデフォルト又はウィンドウズ２０００アクティブディレクトリ等の）エンタープライズのディレクトリ上、ピアツーピアのシステム、又はその他のシステム上に自己の存在を自動的に告知する本発明のシステム１０は、発見が組み込まれた概念を持つ。好ましい実施の形態において、ＫＩＳはローカルのマルチキャストネットワーク上、（ＬＤＡＰのデフォルト又はウィンドウズ２０００アクティブディレクトリ等の）エンタープライズのディレクトリ上、ピアツーピアのシステム、又はその他のシステム上に自己の存在を自動的に告知する。意味論的ブラウザ３０は、マルチキャスト又はピアツーピアの告知に定期的にリスンし、エンタープライズのディレクトリ、又はグローバルエージェンシー ディレクトリを定期的に調べることが理想的である。ブラウザは又、ユーザに付加的なエージェンシーを検索するために、階層的な方法でシステムのナビゲートを可能にする。このやり方では、ユーザは新しいエージェンシーが利用可能である時、及び既存エージェンシーの期限が切れる時に通知を受ける。本発明の意味論的ブラウザは、新しいエージェンシーが名前空間のスナップショットと、告知とディレクトリの存在を調べる定期的な確認を通して、利用可能である時は直ちにユーザに通知することが好ましい。
ピアツーピアの側面は、システム１０に（組織にとって大きな継続的経費である）中央集中メンテナンスなしで、エンタープライズディレクトリから自動的にデータを読み込み、規模の変更を可能にする。システムはできれば新しいクラスのサーバに対してプログラムによる照会を使うので、ウェブのログを必要としない。
ダイナミックリンキング
本発明のシステム１０は、組み込み動作を持つスマートオブジェクトを採用することにより、現在のウェブと概念上の意味論的ウェブよりも基本的な優位性を提供する。システムは各エージェンシーのＸＭＬウェブサービスに動作的な特徴を埋め込むので、意味ネットワークの各ノードは、現在のウェブ又は意味論的ウェブの通常のリンク、又はノードよりもスマートになる。言い換えれば、好ましい実施の形態において、本発明の意味ネットワークの各ノードはオーサリングに関係なく他のノードとリンクする。各ノードはエージェンシーに動的にリンクする動作を持つ。スマートエージェントは又、ドラッグ＆ドロップ、スマートコピー＆ペースト、セマンティックエンバイロメント内でエージェンシーへのリンクを作成する、スマートエージェントから新しいリンクを作成するためのレンズの要求に応答する、エージェンシー上に時間に敏感な情報へのリンクを動的に作成する組み込み警告を含む、（ノードが名前空間の最新ニュースのエージェントに自動的にリンクできる）最新ニュース用の提示のヒントを含む、等を可能にする。これらの機能は、新しいリンクを検索しナビゲートするといった、ユーザの能力を動的に増やす。ユーザがネットワーク内のノードに到達すると、ユーザは文脈、時刻、スマートなエージェンシーとエージェントの関連性等を使って、動的に、及び自動的にナビゲートする多くの意味論的な手段を持つ。ネットワーク内の各ノードをよりスマートにすることで、意味ネットワーク全体がスマートで、仮想で、自己修復、及び自動オーサリングをするネットワークになる。
本発明の動的リンクの技術は、ユーザにローカル／遠隔の情報の境界を越えた照会の発行を可能にする。例えば、（できればＳＱＭＬ技術を使った）本発明は、ユーザに「自分のハードディスク上のこの仕様書に関連するもので、上司又は研究部の者にが書いた電子メールのメッセージを全て検索する」のような照会の発行を可能にする。（できればＳＱＭＬを経由した）クライアント側の照会処理技術は、プロセッサがクライアントからのメタデータを、関係照会を処理する遠隔のＸＭＬウェブサービスとリンクするので、この柔軟性のある照会を可能にする。
スマートで動的な情報伝達−本発明で提供する動的リンクは、知的な情報伝達を提供する意味ネットワークは現在のウェブ、又は意味論的ウェブよりも多数の軸からナビゲートできるので、情報の共有と伝達ははるかに効率的になり、情報の損失が最小限に抑えられる。
ユーザ制御のナビゲーション及びブラウジング
本発明の動的リンクは、静的なリンクが「行き止まり」のブラウジングとなってしまう現在のウェブ、及び意味論的ウェブとは対照的に、継続的な意味論的なブラウジングを可能にする。現在のウェブ、及び意味論的ウェブでは、ユーザは通常所望の場所を参照し、事実上これ以上リンクがない行き詰まりに到達する。動的リンクでは、ノード自体が動的にリンクを更新するインテリジェンスを含むので、ユーザは、その時点での情報空間の性質次第で、無制限にブラウジングを続けることができる。
例えば、本発明が提供するシームレスなリンクの統合と意味論的なＸＭＬウェブサービスを経由して、ユーザは、新しいスマートエージェントを作成するために、スマートエージェントにファイル、リンク等をドラッグ＆ドロップする。これは再帰的に起こることが好ましい。するとスマートエージェントは、適所でブレイキングニュース エージェントになることができる。提示中の他のノードは、任意のブレイキングニュース エージェント上に最新ニュースが存在するかどうかを示す提示のヒントを表示する。引き続きこの例において、ブレイキングニュース エージェントの照会結果は、更に結果を示すスマートレンズとして使うことができる。これらの結果は、ネットワークを通して文脈に依存し時間に敏感なパスをユーザに提供する組み込み警告を含むことが好ましい。続いて起こる結果は、任意のエージェンシーにコピー＆ペーストできるだけでなく、他のスマートエージェント上にドラッグ＆ドロップすることもできる。
好ましい実施の形態において、本発明の動的リンクは、意味論的な「サンドボックス」内のオブジェクト（システム１０の環境内にあり、意味論的ブラウザ３０内で表示されるオブジェクト）と、環境に動的に付加できる外部のオブジェクトの両方に適用される。これは、（ファイルシステム、現在のウェブ、又は他の環境上の）既存文書から、本発明のシステム１０へのシームレスで動的な移行パスを提供する。
図８３は、本発明の好ましい実施の形態による、動的リンクとユーザ制御のナビゲーション及びブラウジングを図解する。この例用に、「スマートなリンク」は、本発明の動的でプログラム可能な意味論的なリンクを指していることに留意すべきである。
非ＨＴＭＬ及びローカルの文書のネットワークへの参加
本発明は、文書がネットワークに含まれる前に、ＲＤＦ、又はＸＭＬで符号化される必要がない。むしろ、ＫＩＳ（又はエージェンシーのサーバ）は、あらゆる文書からメタデータを自動的に抽出し、それを意味ネットワークに追加する。更に、できればドラッグ＆ドロップ、スマートコピー＆ペースト及びスマートレンズの機能を経由して、クライアント側の動的リンクは、ローカルの全タイプの文書のネットワークへのリンクを確実にするので、ネットワークの価値と範囲が増大する。本発明は、ローカルの文書から自動的にメタデータを抽出し、意味論的に関連する情報を取得するために（ＫＩＳのＸＭＬウェブサービスを経由して）ＫＩＳを呼び出す。従って、ローカルの文書はネットワークから除外されない。本発明はユーザに、（現在のウェブ、又はファイルシステム等の）無能な環境から文書をシステム１０にドラッグ＆ドロップする能力を与えるので、その文書に意味論的なインテリジェンスを提供する。いったんメタデータがシステム１０に入ると、意味論的なレンズ、スマートコピー＆ペースト等の意味論的ツールは、オブジェクトに、及びオブジェクトを使って操作を行うことができる。ドラッグ＆ドロップは又、ユーザのファイルシステム、及び現在のウェブからシステム１０に直接サポートされる。
表示情報の意味論をスマートに伝達する柔軟性のある提示
本発明はユーザに柔軟性のある提示の能力を与える。ＸＭＬウェブサービスが、ＨＴＭＬではなくＸＭＬを返すこと、及び提示がクライアント上で動的に生成されることが理由で、ユーザは意味論的な情報を表示する「スキン」を多種の中から選択する。スキンはＸＭＬを（ＸＨＴＭＬ＋ＴＩＭＥ、ＳＶＧ等の）提示に適した形式に変換することが好ましく、ユーザに多種の表示技術の機能に基づいた動的なスキンの選択を可能にする。例えば、ＳＶＧは、ＸＨＴＭＬ＋ＴＩＭＥが持っていない機能を持ち、その逆も事実である。ユーザは、ＳＶＧが最適化されているシナリオには、ＳＶＧを選択することができる。あるいは、ユーザは、他のシナリオにＸＨＴＭＬ＋ＴＩＭＥを選択することもできる。
本発明の一部としてのスキンの柔軟性は、更なる状況における適用に備える。多種の他の実施の形態においては、例えば、盲目ユーザを支援するために、音声合成のスキンを第一、又はメインのマシンと平行に第二のマシン上で意味論的ブラウザ３０を動作する、現在のビュー域のサイズに合わせて動的にサイズ変更可能なスキン（それによって、ユーザはウィンドウのサイズを変更しながらも快適なユーザ経験を保持することができる）、（予定あり／なしの情報等のイベント情報に関するユーザのカレンダー等の）意味論的なヒントを表示するためにローカルの状態を調べるスキン、ユーザのナビゲーションの時間を節約し、生産性を高めるインラインプレビューのウィンドウを表示するスキン、組み込み警告、最新ニュース、詳細情報、スマート推薦、組み込みリンク、レンズの情報用に多種のカスタマイズ可能なヒントを表示するスキン、等によってユーザに能力を与える。ユーザは又、例えば、ユーザがスクリーンセーバーのモードでエージェントの表示を希望する際には、スマートなスクリーンセーバーと一緒に使うスキンを選択することができる。他の実施の形態においては、システム１０は、見出し、ニュースメーカー、会話等のコンテキストテンプレート用のスキンをサポートする（以下で説明する）。
柔軟性のある表示ができるので、本発明はユーザが現在の作業に基づいて最適な提示モードを選択できるようにする。例えば、ユーザは生産性が美的な効果よりも高い優先度にあるメインのマシン上で作業をしている際は、かすかなスキンを選択できる。ユーザは、生産性も重要だが効果があってもよい場合は、中程度のスキンを選択することができる。ユーザが周辺視野で情報を閲覧しており、音声合成のような機能で最新ニュースの警告を希望しているような第二のマシンを使用しているようなシナリオには、ユーザは刺激的なスキンを選択することができる。刺激的なスキンは、二者択一的に、アニメーション化、詳細情報用のストーリーボードのような効果、モーションパスに表示されたオブジェクト、及びその他の効果を扱うことができる。
更に、本発明のスキンは、オブジェクトタイプのフィルタを含む、除外するという設定もできる。例えば、スキンは「文書」のみを含み、しかも「分析報告書」は除外するように設定できる。スキンが最終的な提示を判断するのにＸＭＬの結果を使うので、スキンは返されたオブジェクトのオブジェクトタイプ（又は他の属性）を調べることで、ＸＭＬ（ＳＲＭＬ）の結果にオブジェクトを含む、又は除外することができる。
論理と推測と推論
本発明は論理と推測と推論を提供する。ＫＩＳエージェンシー上の意味論的なデータモデルは、意味ネットワークのデータベース処理、意味論的な照会のＳＱＬへの変換、論理処理用の他のデータベース照会言語等を経由して、論理サポートを提供することが好ましい。更に、本発明のシステム１０は、特定のカテゴリ、又は情報項目に関するエキスパート、推薦、（ある人が文書を書いた確率等の）確率的なリンク等の推測的リンクのためのインファレンスエンジンを含むことが好ましい。上記で説明したように、本発明のインファレンスエンジンは、意味ネットワークを観察し、新しい意味論的なリンクを推測するために意味ネットワークを掘り下げて、その結果のリンクをセマンティックリンクの表に表すことが好ましい。
柔軟性のあるユーザ主導の情報分析
本発明は、クライアント上で柔軟性のある情報分析のネイティブなサポートを提供する。本発明のプレゼンタは、ユーザに照会を出す前に意味論的な照会結果がプレビューできるようにスマートレンズを使用することが好ましい。ユーザは結果をプレビューするために、関連のある述語と他のフィルタを変えることができる。他の実施の形態においては、ユーザは照会を起動して、必要に応じてそれを新しい副照会の基礎として使う選択肢を持つ。
柔軟性のある意味論的な照会
本発明は、ユーザに非常に柔軟性のある意味論的な照会を可能にする。ユーザは、「自分のハードドライブ上でこの文書に関連する」のようなフィルタを使って、局所的文脈を照会に組み込むことができる。現在のウェブ、あるいは意味論的ウェブはこれができない。更に、本発明は、独自仕様の意味論的な照会言語（ＳＱＭＬ）への参照を利用して、ローカルと遠隔のリソース、述語、カテゴリ参照、及びオブジェクトを含むスマートエージェントを組み込むことが好ましい。本発明は、簡単なウィザードのモデルを使って、（意味論的な照会を表現する）スマートエージェントの作成と編集用に使いやすいユーザインターフェースを組み込むことが好ましい。上記で説明したように、システム１０はドラッグ＆ドロップの機能を再帰的に行うことで、意味論的な照会に、新しい照会の基礎の形成を可能にする。例えば、文書、又はＨＴＭＬのリンクを既存の、又は新しいスマートエージェントにドラッグして、次のスマートエージェントを作成することが可能である。スマートエージェントは二者択一的に、レンズとして使用することが可能で、新しい意味論的な照会を形成するためにオブジェクトをスマートエージェント上にペースト、又はブレンダーに追加することができる。ブレンダーはそれ自体意味論的な照会のコンテナで、そのコンテナも又フィルタ処理が可能なので、下位ブレンダー、又は下位エージェントのコンテナを作成する。
読み取り／書き込みのサポート
本発明のシステム１０は、ユーザが情報を直接意味ネットワークに公開できるようにするＸＭＬウェブサービスを提供することによって、読み取り／書き込みの機能のサポートを提供する。これは、任意の文書、注釈付加、又は壊れたリンクの訂正や新しいリンクの提供をする意味論的なリンク、のどれかである。これは全てＸＭＬウェブサービスでのセキュリティ制限、及びオペレーティングシステム階層を条件とする。システム１０は、認証、アクセス制御、及びＸＭＬウェブサービスの下位に存在するオペレーティングシステムとアプリケーションサーバからの他のサービスを採用する。これらのセキュリティサービスは、意味ネットワークへの読み取り／書き込みのアクセスを確保するために使用されることが好ましい。
注釈付加
本発明は、注釈付加用に組み込みサポートを含む。人のオブジェクトと（文書、電子メールの投稿、オンライン講座等の）他の情報オブジェクトの間の意味論的なリンクの注釈付加を定義する「注釈付加した」の特別な述語がある。システム１０は、ユーザに組み込みリンク、スマートレンズ等を経由して注釈付加のナビゲートを可能にすることにより、注釈付加用のプレゼンテーション層のサポートを含む。本発明が注釈付加を組み込むやり方は、（注釈付加する情報オブジェクトの一部として、注釈付加を埋め込む、埋め込み先の注釈付加技法のような）既存技法の利点を提供する。本発明の好ましい実施の形態において、注釈付加は「第一種」の情報オブジェクトである。これは、双方向にリンクする、（スマートレンズを使って）「レンズ」を置く、（スマートコピー＆ペーストを使って）コピー＆ペーストを行う、等ができることを意味する。本発明は注釈付加を、本発明の全ての意味論的ツールに公開するので、標準の注釈付加の技法を使った性能より強力なユーザ経験を容易にする。更に、本発明の注釈付加はコンテキストテンプレートと一緒に使われる。その結果、インファレンスエンジンがそれらを使って、システムを時間と共によりスマートにすることができる。更には、システム１０は、エージェンシーの電子メールのエージェントに、（修飾したメッセージ本文部と共に）特別に書式設定された電子メールを送信することで、オブジェクトの注釈付加に一意的で簡単な方法を提供する。
「信用の輪」
本発明は、ＸＭＬウェブサービスを経由して「信用の輪」を提供する。このサービスは、意味ネットワークの更新、アサーションの作成、リンクの修正／更新等を希望するユーザを認証する。又これは、ＫＩＳエージェンシーを経由して、豊富なコンテンツが、従量料金制のコンテンツの登録購読者に利用可能になるようにする。ユーザが同じプラットフォームのツールを利用して、多くの豊富なコンテンツのソースにわたって、シームレスにナビゲートできると、全体のネットワークの価値が増大する。
情報パッケージ（「ブレンダー」）
本発明は、情報パッケージ、又は「ブレンダー」を提供する。ブレンダーは、スマートエージェントからの意味論的な照会の参照を含む意味論的なコンテナである。これは、ユーザに関連のある意味論的な情報を１つのまとまったユニットとして取り扱うことを可能にする。ユーザはブレンダー内の個別なエージェントを別々に表示、又はブレンダー内の情報がまるで１つの集約したエージェントからの情報であるかのように、ブレンダー全体を表示することができる。これは、ＸＭＬウェブサービスへの呼び出しを経由して、各エージェントを起動させることによって実現することが好ましい。好ましい実施の形態において、ユーザは、オブジェクトをブレンダー上にドラッグ＆ドロップして、下位のブレンダーを作成する。これは再帰的に行われることが好ましい。
ブレンダーは作成、削除、及び編集可能である。ユーザはブレンダーから／ブレンダーに、スマートエージェントを追加、及び除去ができる。ブレンダーは異なるセクションを含んだ新聞の個人的なデジタル版として考えることができる。例えば、ＵＳＡツデー、ニューヨークタイムズ、ウォールストリートジャーナル等は、ニュース、経済、スポーツ、暮らし／娯楽等の異なるセクションを含む。これらの各セクションは、ブレンダーのスマートエージェントのエントリに相当し、新聞全体がブレンダーに相当する。本発明によって提供される柔軟性のある表示とナビゲーションは、ユーザが新聞の各セクションをそれぞれ順次に全部目を通したり、各セクションの１ページ目から始めて、次に各セクションの２ページ目のやり方で新聞全体に目を通したりできるデジタル版として考えることができる。
コンテキストテンプレート
上記で詳細に説明した通り、本発明はコンテキストテンプレートを提供する。コンテキストテンプレートは、シナリオ主導型の情報照会のテンプレートで、情報のアクセスと取得のために特定の意味論的モデルにマッピングする。本質的に、コンテキストテンプレートは、事前定義済み意味論的テンプレートを用いることで、ユーザに情報を伝達する、個人的で、デジタルの意味論的な情報の取得の「チャネル」として考えることができる。好ましい実施の形態において、意味論的ブラウザ３０は、ユーザにエージェントの特性を初期化するために、コンテキストテンプレートを使って新しいブレンダー、又はスペシャルエージェントの作成を可能にする。コンテキストテンプレートは、１つ以上のエージェンシーにわたって情報を集約することが好ましい。更に、コンテキストテンプレートは、ユーザが表示又は選択した任意の情報オブジェクト用に、知的で動的な適所での文脈を提供するために文脈パレットを使うことが好ましい。
ユーザ主導の情報集約
本発明はユーザ主導の情報集約用に、組み込みサポートを持つ。シナリオにより、ユーザは文脈及び時間に敏感な情報を、情報のレポジトリにまたがったものでも、まるで１つのソースからきたように表示する能力を持つことができる。これは、情報源に関係なく、適切な情報を、適切な文脈で、適切な時に提示するユーザ主導のコンピュータの使用をユーザに提供することによって、現在のウェブと概念上の意味論的ウェブを使うよりもはるかに生産的なユーザ経験を提供する。インフォメーションエージェントは、情報源にわたって、ＳＱＭＬを経由してクライアント側の意味論的な照会を使い、異なるエージェンシーの応答からのＸＭＬ結果をＳＱＭＬに集約することで、情報を動的に集約する。
E. シナリオ
以下は、本発明の好ましい実施の形態と他の実施の形態を、様々な実用的な状況に応用したシナリオ例である。
1. 本発明を用いた意味論的な照会の例
a. ファイルパス c:＼spec.doc 上の仕様に関連する文脈を全て検索する。
文書を表すアイコンを、インフォメーションエージェントを表すアイコンに、ドラッグ＆ドロップする。ファイルが意味論的ブラウザ内で開き、文脈パレットが表示される。好ましい実施の形態において、これには見出し、発見、ニュースメーカー、今後のイベント、時系列、会話、バラエティ、権威的、最も確実な予想、今日、最新ニュース、等のコンテキストテンプレートの一部、又は全部を含む。これらのパレットは、名前空間の「最近の」及び「お気に入り」のリストに、エージェンシーからの関連した文脈を含む。
b. 無線技術の専門知識を持つ「Ｒ＆Ｄ」というタイトルの付いたエージェンシー上のエキスパートを全て検索する。
「新しいスマートエージェント」ウィザードを起動して、エージェントの作成時に「コンテキストテンプレートの使用」の選択肢を選択する。「エージェンシーを選択」ダイアログから「Ｒ＆Ｄ」エージェンシーを選択し、カテゴリのブラウザから「無線」カテゴリを選択する。新しく作成されたスマートエージェントを開く。
c. 現在表示されているウェブページ上のリンクに関連する、ロイターの情報を全て検索する。
そのリンクを「ロイター」を表すエージェンシーのアイコンにドラッグ＆ドロップする。新しいスマートエージェントが、「[リンクのタイトル] に関連するロイター上の情報」というタイトルで作成され、インフォメーションエージェント内で開く。
d. ファイルパス c:＼spec.doc の仕様書に関連する、現在のウェブページ上のリンクに関連するロイターの情報を全て検索する。
文書を表すアイコンを、上記で作成されたばかりのエージェント（「[リンクのタイトル] に関連するロイター上の全ての情報」）にドラッグ＆ドロップする。これによって、「spec.doc に関連する、及び[リンクのタイトル] に関連するロイター上の情報」というタイトルで 新しいスマートエージェントが作成される。これはユーザ制御のブラウジングと動的リンクを示す。
e. 前回の照会で返されたロイター上の最初の記事に関連する、「マーケティング」のタイトルの付いた内部エージェンシー上にある電子メールを全て検索する。
ロイターの記事のオブジェクトを強調表示し、「動詞」ボタンをクリックする。これはポップアップメニューを表示する。「コピー」を選択する。（シェル拡張子のツリービュー上にある）「マーケティング」というタイトルのエージェンシーを表すアイコンを検索する。そのアイコンを右クリックする。「ペースト」をクリックする。これによって「[ロイターの記事のタイトル] に関連する「マーケティング」に関する情報」というタイトルの新しいスマートエージェントが作成されて開く。電子メールのオブジェクトを表示する結果のウィンドウ内のフレームに着目する。
f. 電子メールの作成者までナビゲートする。
電子メールオブジェクトを強調表示し、「リンク」ボタンをクリックする。これによって、組み込みリンクを示すポップアップメニューが表示される。「差出人：」というタイトルのメニュー項目までナビゲートする。これによって、電子メールオブジェクトの「差出人」行上で人のオブジェクトを示すポップアップメニューが表示される。希望するオブジェクトを選択する。これによって、電子メールオブジェクトを作成した人のメタデータを示すインフォメーションエージェント内に新しいスマートエージェントが開く。人の文脈も又、文脈パレット内に表示される。ユーザは（任意の文脈パレット上で）人のオブジェクト、又はその文脈を使って引き続きブラウジングすることができる。
g. 電子メール内の添付ファイルまでナビゲートする。
電子メールオブジェクトを強調表示し、「リンク」ボタンをクリックする。これによって、電子メールオブジェクトの組み込みリンクを示すポップアップメニューが表示される。「添付ファイル」というタイトルのメニュー項目までナビゲートする。これによって、添付ファイルというタイトルを示すポップアップメニューが表示される。希望する添付ファイルを選択する。これによって、添付ファイルがインフォメーションエージェントのウィンドウ内で、新しいスマートエージェントとして開く。添付ファイルの文脈が文脈パレット内に表示される。
h. 添付ファイルに関連する「エネルギー産業のイベント」のエージェンシー上のイベントを全て検索する。
添付ファイルオブジェクトを強調表示し、「動詞」ボタンをクリックする。これによりポップアップメニューが表示される。「コピー」を選択する。（シェル拡張子のツリービュー上で）「エネルギー産業のイベント」というタイトルのエージェンシーを表すアイコンを検索する。そのアイコンを右クリックする。「ペースト」をクリックする。これによって、「[電子メールの添付ファイルのタイトル] に関連する「エネルギー産業のイベント」というタイトルの新しいスマートエージェントが作成されて開く。
i. ロイターを文脈として使って「マイドキュメント」のフォルダを参照する。
インフォメーションエージェント内で「フォルダの文書を開く」を選択する。あるいは、「マイドキュメント」のフォルダを、インフォメーションエージェントを表すアイコンに、ドラッグ＆ドロップする。下位フォルダが含まれるのかどうかを示す。これにより、「マイドキュメント」というタイトルの新しいダムエージェントが作成されて開く。このエージェントをクリックすると、このフォルダ内の文書のメタデータが、インフォメーションエージェント内で開く。文書を１つ選択すると、その文書用の文脈パレットが表示される。ロイターを文脈として使い文書を参照するために、ユーザはロイターのエージェンシーを表すアイコンを探して、そのアイコンを右クリックし、「コピー」をクリックする。ユーザは、インフォメーションエージェント内の文書のメタデータを示す任意の結果の上にマウスカーソルを合わせて、スマートレンズを示すアイコンを選択する。関係照会結果上の情報を示す、スマートレンズウィンドウが表示される。一番最近に投稿された項目等の情報に加えて、ロイター上で見つかった文書に関連する項目数が表示される。更に、ユーザが結果を適所でプレビューできるプレビューコントロールが表示される。ユーザは、新しい関係照会を表現するエージェントを開くために、結果を選択してクリックすることができる。それが完了すると、結果内にある最初のオブジェクトの文脈が、文脈パレットを使用して表示される。
j. この文書に関連しており、ＸＭＬ技術に関する最新ニュースが何でも存在する場合、電子メール、音声、又はポケットベルで通知する。
「最新ニュース」の文脈を使い、「ＸＭＬ」カテゴリをカテゴリのフィルタとして使用して、新しいスマートエージェントを作成する。この文書を表すアイコンをエージェントにドラッグ＆ドロップする。これによって、適切なタイトルで新しいスマートエージェントが作成される。インフォメーションエージェントの「オプション」メニューに移動して、（自分の電子メールのアドレス、ポケットベル番号、電話番号等）の通知セクションに適切な情報を入力する。スマートエージェントを右クリックして「通知」を選択する。
2. 実務上の問題
a. 情報のアクセス
現在のウェブ−ジョン ヘッドマスターは、サンディエゴに所在するマーケティングコンサルティング業務を提供するＦａｓｔＳｅｒｖｅ社で勤務する。ジョンは毎日出勤すると、ウェブブラウザを起動させる。今日は新しくて興味のある情報がないかどうか、本社のウェブを参照することにした。（企業情報ポータルを使って）ブラウザのホームページは、本社ホームページに設定されている。本社ホームページには同社の別な部門のホームページへのリンクを持っている。ジョンは本社ホームページから、リンクをクリックしながら、他部門のリンクへとナビゲートする。しばらくして、ジョンはもっと多くの情報源があるのは知っているが、どのパスを選べばよいのか分からないので、情報源へとナビゲートできないので苛立ってくる。結局のところあきらめてしまう。
インフォメーションナーバス システム−ジョンはインフォメーションエージェント（意味論的ブラウザ）を起動させる。これによってホームエージェントが開く。ページ上に、製品、製品グループ、報告書、会社のイベント、オンライン講座、及びビデオプレゼンテーションに対応する知識リンクのリストが表示される。ジョンは「製品グループ」のリンクにマウスカーソルを合わせる。自動的に、吹き出しポップアップが現れて、製品グループ数とそのリンクについての他のデータが表示される。それからそのリンクを開く。すると製品グループのオブジェクトリストが、カスタマイズ可能な外観、又は「スキン」で表示される。次に最初のオブジェクトにマウスカーソルを合わせる。即座にポップアップメニューが、「会員を表示する」、「類似の製品グループを一覧表にする」、及び「グループのイベントに会員登録をする」のアクションでリンク上に現れる。「グループのイベントに会員登録をする」をクリックする。ジョンは今後この製品グループに関連する全てのイベントを（エンタープライズインフォメーション エージェントを介して）電子メールで通知を受けることになる。次に「会員を表示する」をクリックする。これによって、人に対応するアイコンを持つ新しい「知識のページ」が開く。そこで「スーザン グループリーダー」のアイコンにマウスカーソルを合わせる。吹き出しポップアップが現れて、スーザンの情報が表示される。それから、「直属の上司」、「直属の部下を一覧表にする」、「所属する会」、「作成した文書」、及び「最近出席した会議」のアクションで、右クリックのメニューが表示される。ジョンは「最近出席した会議」を選択する。これによって、１つの会議のオブジェクトを持つ新しい知識のページが開く。ジョンはこれにマウスカーソルを合わせて、ブラウジングを続ける。
ある時点で、ジョンは前日会った同僚の検索をすることにした。「ウィルバー ジョーンズ」と入力する。これによって、ウィルバーに一致する人のオブジェクトが返される。ジョンは、ウィルバーを情報知識のピボットとして使ってブラウジングを続ける。
そのうちにジョンは、ウィルバーは必要な情報を持っていないらしいことに気が付く。そこで、インフォメーションエージェント上の検索ボックスに、「今度の２００２年度営業会議に関するオンライン講座と文書を全て一覧表にする」の照会を入力する。（イーメールエージェントを経由して）インフォメーションエージェントが、その知識の照会と一致する、行動可能なオンライン講座と文書のリストを返す。
b. 知識主導の顧客関係の管理
顧客との接点−ＡｎｙＳｏｆｔ社は、１００カ国語で５０個の製品を持つソフトウェア製造業者である。顧客に最新の情報を提供するために、ウェブサイト（ａｎｙｓｏｆｔ．ｃｏｍ）を用いている。しかしながら、顧客から同社のウェブサイトは非常にナビゲートが難しく、製品の情報の検索と通知の会員購読をするのが難しいとの苦情が出ている。
本発明の１つの実施の形態に基づいたインフォメーションナーバス システムを導入することで、ＡｎｙＳｏｆｔ社は既存ウェブサイトと共存するインフォメーションナーバス システムを配置した。インフォメーションエージェントは、ホームページと検索バーからアクセスできる。顧客は、製品、関連ホワイトペーパー、お知らせ、プレスリリース、会社のイベント情報等を得るのに、ウェブサイトをはるかに直感的にナビゲートする方法を持つことになった。顧客は、自動的なナビゲートが可能で、行動可能な知識オブジェクトを返す自然言語の照会が出せるようになった。この機能だけで、顧客は知識を意のままにアクセスできる。顧客は更に、自然言語を使って携帯デバイスからＡｎｙＳｏｆｔ．ｃｏｍのウェブサイトをナビゲートするできる。
顧客のフィードバックと追跡−Ｃｏｍｐ−Ｍａｒｔ社は、複数の流通経路を持つコンピュータ周辺機器の販売代理業者である。当社は、ウェブサイト、コールセンター、直販チーム、電話勧誘販売の代理店等から顧客からのフィードバックを得ている。フィードバックは文書と電子メールの形態で入ってくる。当社では、顧客からのフィードバックがその情報を必要とする社員に適切に回されていない問題が判明した。製品開発の社員は、情報の検索方法が分からなく、重要な知識が組織内で共有されていないので、製品開発の過程に顧客からのフィードバックを組み込むことが難しいと経営陣に訴えた。
インフォメーションナーバス システムを適所に配置することで、顧客からのフィードバックを含む電子メールは、当社のセマンティックエンバイロメントに意味論的に組み込まれるようになった。本発明のＫＩＳは、文書、プロジェクト、密接な結び付きのある製品に従事する従業員のような意味論的なオブジェクトと顧客からのフィードバックの電子メールとの間に意味論的なリンクを自動的に追加する。顧客からのフィードバックは、知識空間の適所で知的に活発化する。イーメールエージェントは、顧客からのフィードバックの電子メールを読むことにおそらく興味がある人に、定期的に通知を送り出す。
又、インフォメーションナーバス システムで、顧客は情報知識のピボットとなる。これによって、顧客からのフィードバックへの対応と、組織全体にわたって顧客に関連した知識の追跡がはるかに迅速で容易になる。インフォメーションナーバス システムは、顧客のオブジェクトを、関連する電子メールのメッセージ、文書、類似の顧客等で自動的に注釈付加する。これによって、顧客へのリンクを電子メール経由で転送することができ、同僚はそこから関連ある情報をナビゲートすることができる。顧客のオブジェクトは検索したり参照したりすることができる。
c. 知識主導の直販／出張サービス
マーシャ マインドセットは、ミズーリ州カンザスシティーのコンピュータサービスを提供する会社の、ＪｕｓｔＩｎＴｉｍｅサポートサービスの顧客サービス担当者である。マーシャは、カンザスシティー市周辺の顧客を訪問する。彼女は困った時にはサポート本部に電子メールを打てるように常時無線ＰＤＡを携帯している。ＪｕｓｔＩｎＴｉｍｅ社は最近ＫＩＳとイーメールエージェントを導入した。マーシャは、サポートの質問があるときはいつでも、イーメールエージェントに電子メールを出して、自然言語で質問をすることができるようになった。イーメールエージェントは、彼女の電子メールに直接的な回答で応答する、又は関連したサポートの電子メール、文書、又は、電子メールを出したり電話で呼び出すことができる人に、即座にアクセスできる「知識リンク」で応答する。ＪｕｓｔＩｎＴｉｍｅ社の直販チームは又、顧客にソリューションを出先で営業中に本発明の技術を使っている。営業員は又無線のＰＤＡを携帯し、イーメールエージェントに要求を出すことができる。
d. 事例研究
企業内教育訓練、知識の転送、及び共有−ＷａｖｅＧｅｎ社は、米国内の医師に「管理医療」のソリューションを提供するバイオ技術の会社である。当社は最近、従業員（特に営業員）の訓練用に、サバ ラーニング管理システムのプラットフォームを導入した。これによって、出張経費の節減と、当社の営業チームが全国の異なる医療地域の医師に対応する態勢を強化することができる。
更に、同社の研究員が定期的にバイオ技術研究団体の最近の発見情報の報告を受け取る支援をする。当社は又、価値のある知識源を保持する他のソフトウェア資産を適所に持っている。当社は、文書とメディアファイル、電子メール用にマイクロソフトのエクスチェンジ、及びオンライン会議用のコラボレーションソフトウェアをホストするコンテンツ管理ソリューションを導入した。しかしながら、当社では知識の転送は、このソリューションの全てが前者にわたって統合されていないので、あまり効果的ではないことに気がついた。営業員は、当社の製品を医師に売り込む際に役立つ、組織内外の重要な知識の情報源を検索するツールがないことを指摘した。企業情報ポータルは、営業チームに次回のオンライン講座と重要なイベントを通知するのに現在使われている。しかしながら、営業員は（電子メール、文書等に格納された）多くの情報は、誰がその情報を必要としているのかが分からないので、気付かないと訴えた。
更に、営業員はマイクロソフトのアウトルックを使って、次回の医師どの面会の約束をカレンダーに入れている。しかしながら、約束の通知だけ受け取り、製品をもっと効果的に営業するのに役に立つ多くの情報が自動的に、医師との面会の事前に利用できないことについて苦情を訴えている。
ＷａｖｅＧｅｎ社は、本発明からの技術に基づいてインフォメーションエージェントを導入した。当社は、営業及び研究チームが、顧客への対応と当社の製品向上のために、より優位な意志決定を下すのに役立つために、知的な情報の結び付きと配信を円滑にするために、最近ＫＩＳとイーメールエージェントを導入した。インフォメーションエージェントを使って、営業チームは文書だけでなく、当座の作業により直接的に関係した「知識オブジェクト」に即時アクセスができるようになった。例えば、営業員はＸＭＬオブジェクトとして「ジョーンズ医師」をエージェントに持つことができる。これは文書でもウェブページでもなく、むしろ顧客の意味論的な表現である。営業員は、「最近の電子メールのメッセージ」、「関連のある文書」、「特性」、「重要な日付」、「関連のある次回のオンライン講座」等のような意味論的なリンクを見ることができる。このやり方では、顧客がピボットとなり、営業員はそのピボットで社内のウェブをナビゲートする。これらのリンクは、ファイルシェア、電子メール格納データベース、マイクロソフトのエクスチェンジ等からの結果を生成することができる。しかし、これらの知識源を孤立集団として検索、又はナビゲートするのではなく、自己の営業の作業に関連付けるので、営業員は意味論的な関係に基づいた新しい知識を発見することができる。
このやり方で営業員は、より強力な知識を意のままに操ることができ、従ってより優れた顧客への対応を可能にする。この知識は、同僚、他の営業員が発行した文書、存在が知られていないかもしれない配信リストに送られた電子メール、等から発する。ＫＩＳは、これら全ての異種の情報源から、意味論的な結び付けを自動的に行うスマートな動作をする。そうすると営業員はこの「ページ」を同僚に電子メールすることができる。これは、同僚が同じ「ジョーンズ医師」をピボットに使ってインフォメーションエージェントをナビゲートすることができるので、非常に強力な知識共有形式となる。
イーメールエージェントは又、営業員に自然言語での知識の照会を可能にする。照会結果はインファレンスエンジンから派生しており、既存知識から推定した知識に基づいた可能性がある。本発明のインフォメーションナーバス システムの強力な機能は、知識の転送、共有、発見は全て意味ネットワークに基づいて自動的に起こることである。
3. 場面説明
a. 意味論的な情報の発見、取得、及びナビゲーション
ジョー ナレッジワーカーは、インフォメーションエージェント（本発明のＸＭＬベースの意味論的ブラウザ）を起動させる。ログインすると、意味論的なイントラネット上に利用可能な新しいエージェントがあることを示すダイアログボックスが表示される。次に組織の内外からのエージェントのリストが表示され、それには以下を含むことができる。
・ Documents.Technology.All
・ Documents.Marketing.All
・ People.Divisions.Sales.All
・ People.Division.Sales.Managers
・ OnlineCourses.Sales.101
・ OnlineCourses.Technology.XML.101
・ Meetings.ThisWeek.All
・ Meetings.LastWeek.All
・ Books.Computers.Programming.All
・ Newsgroups.Microsoft.Public.Soap
・ Email.Mine.All
・ Email.Mine.ProjectX.All
・ Events.Technology.Wireless.All
・ Reports.Gartner.Software.All
・ Reports.IDC.All
・ Videos.ExecutivePresentations.All
次にジョーは Meetings.ThisWeek.All を選択する。すると、インフォメーションエージェントはジョーが今週出席した会議を表すオブジェクトのリストを表示する。この情報はマイクロソフトのエクスチェンジから来ており、ジョーには公開されていない。ジョーは最初の会議オブジェクトリンクにマウスカーソルを合わせる。すると、新しい研修講座がイントラネットで利用できるようになったことを知らせる吹き出しポップアップが表示される。吹き出しは又、ジョーに関連があるかもしれない新しい報告書がＩＤＣ上にあることを示す。吹き出しに加えて、ポップアップメニューがオブジェクトの右側に表示される。このメニューには以下の動詞が含まれる。
・ 参加者を一覧表示する
・ 代理参加者候補を一覧表示する
・ 関連したオブジェクトを表示する->
・ On News.Reuters.MarketForecasts.All
・ On Documents.Technology.All
・ On Events.Corporate.Today.All
・ 追跡用に会員登録する
次にジョーは「追跡用に会員登録する」を選択する。これによって、サーバ上の会議追跡エージェントに連絡される。このエージェントは、会議の参加者に関連情報の定期的な更新を送信する。これは、ブラウザ、又は電子メールを使って行うことができる。ジョーは次に、Events.Corporate.Today.All に関連するオブジェクトを選択する。これにより、イベントの情報オブジェクトのリストが表示される。次にジョーが最初のオブジェクト上にマウスカーソルを合わせると、ポップアップメニューが表示される。それから「カレンダーに追加する」を選んで、イベントを自分のカレンダーに追加する。ジョーは次に、会社のイベントに関連する業界のイベントを全て検索することにする。Events.Technology.All のエージェントのオブジェクトをドラッグして、マウスボタンを離す。マウスボタンを離すと、ブラウザは、（ウェブサイト及び他の孤立集団すべてにある）Events.Technology.All から情報オブジェクトを読み込む。それらはジョーがドラッグしたオブジェクトの会社のイベントに関連している。
次の週、ジョーはイーメールエージェントから電子メールを受け取る。その電子メールで、エージェントはイベントを各自のカレンダーに追加した全員が、会社のメディアサーバからの企業内教育訓練のビデオをも見たことに気が付いたことをジョーに知らせる。電子メールはＸＭＬリンクを含むので、ジョーはインフォメーションエージェントに戻る。ブラウザは次にビデオのメタデータを表示する。ポップアップ上の項目の１つは「ビデオを見る」である。ジョーはそれを選択してビデオを見る。
次にジョーが自分のワークステーションにログインすると、新しいエージェントがあるのに気がつく。Books.Ebay.Computers.All を会員購読して、それを自分のマイエージェントのリストに追加する。自動的に、本発明の実施の形態はこのエージェントをジョーのセマンティックエンバイロメントに追加する。インフォメーションエージェントは、暗黙的な照会を行い、このエージェントを含む（妥当性と時間への敏感さでランク付けがされた）推薦を提供する。それでジョーがこのエージェントをクリックすると、（書籍を表す）意味論的な情報オブジェクトがリゾルトペインに表示される。オブジェクトの１つにマウスカーソルを合わせと、吹き出しポップアップが即座に表示され、その本の著者が開催する関連業界の会合があると警告を出す。ポップアップのリンクをクリックすると、（マイクロソフトのアウトルック、又は（マイクロソフトのヘイルストームのウェブサービスを経由してアクセスできる）ＭＳＮカレンダーのようなインターネットベースのカレンダー、ＡＯＬのカレンダー等の）自分のカレンダーにイベントの追加を可能にする動詞を完備した、イベントのオブジェクトが、ブラウザに読み込まれる。
シナリオの説明−このシナリオは、本発明で知識労働者が「連合知識」にアクセスできる方法を示す。この例において、ジョーの会社は、知識のエージェントをガートナー、ＩＤＣ、ロイター、イーベイ等から、会社の知識空間に「インポート」した。このようにエージェントは自動的に、会社の意味ネットワークに知識を追加する。シナリオは又、ジョーが直感的に名付けられたスマートエージェントを介して、組織全体の知識空間の「オブジェクトのモデル」ビューをどのように取得できたかを示した。ジョーはこれらのエージェントを使ってセマンティックエンバイロメントに「入る」ことができ、そこからナビゲートを続けた。全ての情報オブジェクトはリアルタイムで配信され、（適所に表示された関連した動詞で）行動可能である。このやり方では、ジョーはオブジェクトがどの情報の孤立集団から来たのか、又はどのアプリケーションで生成されたのかを気にする必要がない。
シナリオは又、ジョーがどのように新しい情報だけでなく、新しいエージェントを発見することができたかを示す。シナリオは、インフォメーションエージェントが気付いた組織の他者の行動に基づいてジョーに推薦を与えた、協調フィルタリングを介して実践されている知識の共同作業を示す。
最後にシナリオは、時間に敏感な情報が道理にかなった文脈の時点で、自動的にユーザの目に留まるようにするやり方を説明する。イーメールエージェントは、次回の業界のイベントとイーベイからの本を自動的に結び付けて、イベントに妥当性と時間への敏感さのランク付けを推測して割り当て、イベントが意味論的ブラウザの警告を経由して、即時にその情報を表示するに値するだけ重要であると判断した。
b. ピアツーピアの知識共有と獲得
ナンシー ハードワーカーは、４万人の従業員を抱えるフォーチュン５００の企業で働く。彼女は多種のウェブサイトに会員登録しており、友人や同僚からの電子メールで情報が転送されてくる。取引先の誰かから大量の文書を受け取ったばかりで、組織内でその情報を共有したいと思っている。自分が会員である全ての配信リストに文書を送信する。エンタープライズインフォメーション エージェントはこれらのリストの会員でもある（サーバのインストール時に、エージェントはエージェント自体を一般の全ての配信リストに追加する）。エージェントが情報を受信すると、分類して意味ネットワークに追加する。次にインファレンスエンジンがその情報を取り上げる。
ナンシーが転送した文書の配信リストの会員でない同僚が何千人といる。しかしながら、全員がインテグレータを使用しており、全員が Email.Public.All Agent の会員登録をしている。他の同僚らが知識ウェブの関連した他の部分を参照している間に、Email.Public.All Agent 上に新しく関連した電子メールがあることを示した吹き出しポップアップが現れる。その同僚らがエージェントを開くと、電子メールオブジェクトが表示される。電子メール項目上のメニュー項目の１つに、「メッセージが転送された配信リストを表示する」がある。その同僚らがこれを選択すると、配信リストの情報オブジェクトがブラウザに表示される。配信リスト上にマウスカーソルを合わせると、ポップアップメニューの項目が表示される。最初の項目は「会員を表示する」である。２番目の項目は「入会する」である。その同僚らは配信リストに入会する。
シナリオの説明−このシナリオは、電子メールを経由した情報の公開、共有、及び獲得方法を示し、意味ネットワークを使って、他の同僚らがこの情報（及び、存在を知らなかった配信リスト）を異なってはいるが、関連した「知識の角度」から見つけ出した方法を示す。シナリオは、完全にシームレスな方法で、ユーザが情報をレポジトリに発行する、又は自分で情報を分類する必要なく、ピアツーピアの知識の共有を示す。本発明の特定の実施の形態を用いて、全てが（背後で）自動的に起こり、知識が適所で表面化する。
以上好ましい実施の形態、及び他の実施の形態を示して本発明について説明してきたが、上記で留意したように、本発明の精神及び範囲内から逸脱することなく、様々な変更が可能であることを理解すべきである。従って、本発明の範囲は好ましい実施の形態、及び代替の実施の形態の開示に限定されるものではない。

知識の取得、管理、伝達、及び提示のシステム及び方法

発明者
ノサ オモイグイ

本付属書類
コード仕様の実例
実例Ａ−ＳＲＭＬ文書
<?xml version="1.0" encoding="utf-8" ?>
<srml xmlns=http://schemas.nervana.net/srml
xmlns:n="http://schemas.nervana.net/srml" xmlns:rdf="http://rdfland.org"
xmlns:dc="http://dcland.org" dummyarg="hello">
<results content="new">
<queryref guid="12345678-1234-1234-1234-123456789ABC" />
<document>
<objectref guid="12345678-0000-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>インシンクーマルチメディア用の制約ベースのツールキット</dc:title>
<dc:creator>ブライアン ベイリー</dc:creator>
<dc:creator>ジョセフ Ａ コンスタン</dc:creator>
<dc:description>
<n:abstract>Ｎｓｙｎｃ（「インシンク」と発音する）は宣言型の同期化用ツールキットで、完全にＴｃｌでよって実装され、革新的で、インタラクティブなマルチメディアアプリケーションの設計の複雑さの簡素化を目的とする。</n:abstract>
</dc:description>
<dc:date>2001-07-02</dc:date>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
<dc:identifier>bailey97nsync.pdf</dc:identifier>
</rdf:Description>
<size>84957</size>
</document>
<document>
<objectref guid="12345678-0001-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>マルチメディアシステム用のパラダイムとして、ストリームとタイムアドバンスの比較</dc:title>
<dc:creator>ロジャー Ｂ ダネンバーグとディーン ルービン</dc:creator>
<dc:description>
<n:abstract>マルチメディアシステムの一般的なモデルは、音声サンプルとビデオフレーム等の持続的に時間に依存するデータの流れを表現する抽象化であるストリームである。</n:abstract>
</dc:description>
<dc:date>2001-07-0218:48</dc:date>
<dc:identifier>dannenberg94comparison.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>55421</size>
</document>
<document>
<objectref guid="12345678-0002-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>現在時刻は？時間ベースのハイパーメディアの構成とリンク</dc:title>
<dc:creator>リンダ ハードマンその他</dc:creator>
<dc:description>
<n:abstract>Iこの論文では提示の時間の概念、つまり提示の個々の部分のタイミングとその間の時間の関係について扱う。</n:abstract>
</dc:description>
<dc:date>2001-06-2916:57</dc:date>
<dc:identifier>hardman99do.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>266873</size>
</document>
<document>
<objectref guid="12345678-0003-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>間隔ベースの概念的なモデル</dc:title>
<dc:creator>リトルとガフォー</dc:creator>
<dc:date>2001-07-0218:52</dc:date>
<dc:identifier>little93intervalbased.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>364367</size>
</document>
<document>
<objectref guid="12345678-0004-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>時空の制約を使った効率的な動作の転移の生成
</dc:title>
<dc:creator>チャールズ ローズ</dc:creator>
<dc:description>
<n:abstract>この論文は人体の動きのセグメント間の転移を作成するための時空の制約の応用について述べる。</n:abstract>
</dc:description>
<dc:date>2001-06-2917:22</dc:date>
<dc:identifier>rose96efficient.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>1217898</size>
</document>
<document>
<objectref guid="12345678-0005-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>ＨｙＴｉｍｅ用のモデリングの技法</dc:title>
<dc:creator>ロイド ルットレッジ</dc:creator>
<dc:description>
<n:abstract>ハイパーメディア／時間ベースの構成言語（ＨｙＴｉｍｅ）は一般的なハイパーメディアの文書の概念を表す構成概念を定義する。</n:abstract>
</dc:description>
<dc:date>2001-06-2917:07</dc:date>
<dc:identifier>rutledge95modeling.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>129404</size>
</document>
<document>
<objectref guid="12345678-0006-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>時限システムの構成内容の仕様書</dc:title>
<dc:creator>ジョセフ シファキス</dc:creator>
<dc:description>
<n:abstract>このチュートリアルでは、構成内容の記述の問題に重点をおいて、グローバルな時間の概念で存在する行動可能な時限の形式主義の概要を紹介する。</n:abstract>
</dc:description>
<dc:date>2001-07-0211:37</dc:date>
<dc:identifier>the-compositional-specification-of.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>132810</size>
</document>
<document>
<objectref guid="12345678-0007-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>簡単で、直感的なハイパーメディアの同期化モデルとブラウザ／Ｊａｖａ環境におけるその実現化</dc:title>
<dc:creator>ジン ユー</dc:creator>
<dc:description>
<n:abstract>この論文は、簡単で直感的なハイパーメディアの同期化のモデルであるメディアリレーション グラフ（ＭＲＧ）を紹介する。</n:abstract>
</dc:description>
<dc:date>2001-07-0211:55</dc:date>
<dc:identifier>yu98simple.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>288218</size>
</document>
<document>
<objectref guid="12345678-0008-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>持続的なメディアプレーヤー</dc:title>
<dc:creator>ローレンス Ａ ロウとブライアン Ｃ スミス</dc:creator>
<dc:description>
<n:abstract>Ｕｎｉｘのワークステーション用の持続的なメディアプレーヤーの設計と実装を記述する。</n:abstract>
</dc:description>
<dc:date>2001-06-2917:08</dc:date>
<dc:identifier>a-continuous-media-player.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>231817</size>
</document>
<document>
<objectref guid="12345678-0009-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>融通のある時間を持つマルチメディア文書
</dc:title>
<dc:creator>ミッシェル Ｙ キム</dc:creator>
<dc:description>
<n:abstract>マルチメディア文書用に融通のある時間のモデルを紹介する。</n:abstract>
</dc:description>
<dc:date>2001-07-0212:07</dc:date>
<dc:identifier>p143-kim.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>272532</size>
</document>
<document>
<objectref guid="12345678-000A-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>刻時機構の階層：メディアストリームのグループ化と制御の抽象化</dc:title>
<dc:creator>カート ロザーメル</dc:creator>
<dc:description>
<n:abstract>この論文では、分散環境での持続的なメディアストリームの制御と同期化用の強力な一組の抽象化を提案する。</n:abstract>
</dc:description>
<dc:date>2001-07-0218:51</dc:date>
<dc:identifier>rothermel96clock.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>93052</size>
</document>
<document>
<objectref guid="12345678-000B-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>マルチメディアのオブジェクトにおける時間的な関係：ＨｙＴｉｍｅの仕様からのＷＷＷの提示
</dc:title>
<dc:creator>マリア デガラカ Ｃ ピメンテル
</dc:creator>
<dc:description>
<n:abstract>初めに、この論文はバイナリの時間的な関係の仕様用にＨｙＴｉｍｅの使用を検討する。次にワールド ワイド ウェブの環境の文脈に提示される要素へのＨｙＴｉｍｅの同期化仕様の自動的な変換へのアプローチを検討する。</n:abstract>
</dc:description>
<dc:date>2001-06-2916:48</dc:date>
<dc:identifier>temporal-relations-in-multimedia.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>102862</size>
</document>
<document>
<objectref guid="12345678-000C-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>マルチメディアのシナリオのモデル用のイベントとアクションの表現と作成</dc:title>
<dc:creator>Ｍ．バジルギアニス</dc:creator>
<dc:description>
<n:abstract>この論文では、シナリオの概念に基づいてマルチメディアアプリケーションの表現用のモデルを紹介する。</n:abstract>
</dc:description>
<dc:date>2001-07-0211:43</dc:date>
<dc:identifier>vazirgiannis96event.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>387575</size>
</document>
<document>
<objectref guid="12345678-000D-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>マルチメディアのシステムで時間の表現</dc:title>
<dc:creator>トーマス ワール、 カート ロザーメル
</dc:creator>
<dc:description>
<n:abstract>この論文は時間論と時相論理の基本的文に応用する最も一般的な既存モデルの選択の評価と記述する。</n:abstract>
</dc:description>
<dc:date>2001-06-2916:49</dc:date>
<dc:identifier>wahl93representing.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>67658</size>
</document>
<document>
<objectref guid="12345678-000E-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>インシンクーインタラクティブなマルチメディアの提示を構築するツールキット</dc:title>
<dc:creator>ブライアン ベイリー</dc:creator>
<dc:description>
<n:abstract>Ｎｓｙｎｃ（「インシンク」と発音する）マルチメディアの同期化用のツールキットを開発した。これは柔軟性があり、インタラクティブなマルチメディアの提示の設計に内在する複雑な課題に対処する。</n:abstract>
</dc:description>
<dc:date>2001-06-2917:09</dc:date>
<dc:identifier>bailey98nsync.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>115592</size>
</document>
<document>
<objectref guid="12345678-000F-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>マルチメディア文書の時間的な提示の課題
</dc:title>
<dc:creator>ナビル ラヤイダ</dc:creator>
<dc:description>
<n:abstract>この方針説明書において、マルチメディア文書の提示の設計に役立つ可能性がある一連の関連のある課題を提示する。これはＭＡＤＥＵＳと呼ばれるオーサリングとブラウジングのツールを設計及び実装した際の経験に基づくものである。
</n:abstract>
</dc:description>
<dc:date>2001-07-0211:54</dc:date>
<dc:identifier>issues-in-temporal-representation.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>17348</size>
</document>
<document>
<objectref guid="12345678-0010-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>空間ーマルチメディアアプリケーションにおいての時間的な構成</dc:title>
<dc:creator>Ｄｒ．マイケル バジルギア</dc:creator>
<dc:description>
<n:abstract>この研究は、現在のマルチメディア文書の規格とオーサリングのツールにおいて、オブジェクトの代表的な時間と空間に関する構成の完全で宣言方法が欠けていることを動機とする。</n:abstract>
</dc:description>
<dc:date>2001-07-0211:43</dc:date>
<dc:identifier>spatio-temporal-composition-in.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>89176</size>
</document>
<document>
<objectref guid="12345678-0011-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>インタラクティブなアニメーションの技法の統合用のオブジェクト指向の枠組み</dc:title>
<dc:creator>ロバート Ｃ ゼレニックその他</dc:creator>
<dc:description>
<n:abstract>多様なシミュレーションとアニメーションのパラダイムの統合を円滑にするインタラクティブなモデリングとアニメーションのシステムを紹介する。</n:abstract>
</dc:description>
<dc:date>2001-06-2916:30</dc:date>
<dc:identifier>zeleznik91objectoriented.pdf</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/pdf</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>133440</size>
</document>
<document>
<objectref guid="12345678-0012-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>インタラクティブなセッションの記録のプレイバックにおける同期化とタイミングの変数の扱い方</dc:title>
<dc:creator>ネルソン Ｒ マノア</dc:creator>
<dc:description>
<n:abstract>この論文で、セッションオブジェクトと呼ばれる新規のマルチメディア文書をサポートするスケジューリングと同期化を説明する。</n:abstract>
</dc:description>
<dc:date>2001-07-0216:30</dc:date>
<dc:identifier>p45-manohar.htm</dc:identifier>
<dc:type>text</dc:type>
<dc:format>text/html</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>99000</size>
</document>
<document>
<objectref guid="12345678-0013-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>ＤｉｒｅｃｔＡｎｉｍａｔｉｏｎでマルチメディアを簡単に作成</dc:title>
<dc:description>
<n:abstract>この論文は、ＤｉｒｅｃｔＸのＡＰＩ系の構成要素で、ウェブページ、ＣＤ−ＲＯＭのタイトル、及びマルチメディアアプリケーション用のアニメーションと統合したメディアのサポートを提供するマイクロソフトのＤｉｒｅｃｔＡｎｉｍａｔｉｏｎを説明する。</n:abstract>
</dc:description>
<dc:date>1998-10-0216:30</dc:date>
<dc:identifier>DirectAnimation.doc</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/msword</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>152000</size>
</document>
<document>
<objectref guid="12345678-0014-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>ウィンドウズのメディア技術</dc:title>
<dc:description>
<n:abstract>この論文は、ウィンドウズのメディア技術であるウィンドウズＮＴサーバのネットショーサービス、ネットショーシアター サーバ、及びマイクロソフトウィンドウズのメディアプレイヤーのストリーミングのメディア構成要素の技術的な概要に関する。</n:abstract>
</dc:description>
<dc:date>1998-07-0216:30</dc:date>
<dc:identifier>NetShow3.doc</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/msword</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>631000</size>
</document>
<document>
<objectref guid="12345678-0015-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>ＸＭＬ文書への統合のタイミング</dc:title>
<dc:creator>パトリック シュミッツ</dc:creator>
<dc:date>2000-07-0216:30</dc:date>
<dc:identifier>IntegratingTimingWithXML.ppt</dc:identifier>
<dc:type>text</dc:type>
<dc:format>powerpoint</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>195000</size>
</document>
<document>
<objectref guid="12345678-0016-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>ＳＭＩＬ２．０のタイミングと同期化のモデル
</dc:title>
<dc:creator>パトリック シュミッツ</dc:creator>
<dc:description>
<n:abstract>アニメーション、及びランタイムの同期化の管理用のスケジューリング、相互作用、先行制御を統合するために強力で柔軟性のあるモデルが必要である。ＳＭＩＬ２．０はこれらのニーズに対処する言語と意味論的なモデルを定義する。
</n:abstract>
</dc:description>
<dc:date>2001-07-0216:30</dc:date>
<dc:identifier>SMILTimingForTheWeb.doc</dc:identifier>
<dc:type>text</dc:type>
<dc:format>application/msword</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>175000</size>
</document>
<document>
<objectref guid="12345678-0017-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>ＸＭＬ文書のタイミングを表現するための統合モデル</dc:title>
<dc:creator>パトリック シュミッツ</dc:creator>
<dc:description>
<n:abstract>作成者が異なる文書タイプ、又は異なるオーサリングのシナリオ用に異なるモデルの学習と記憶を余儀なくさせられないようにタイミングの共通モデルを提供する必要がある。</n:abstract>
</dc:description>
<dc:date>2001-07-0216:30</dc:date>
<dc:identifier>TimingIntegrationPositionPaper.htm</dc:identifier>
<dc:type>text</dc:type>
<dc:format>text/html</dc:format>
<dc:language>en</dc:language>
</rdf:Description>
<size>10000</size>
</document>
<email>
<objectref guid="12345678-0018-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>Ｎｅｒｖａｎａクライアントに関する考えt</dc:title>
<dc:creator>パトリック シュミッツ</dc:creator>
<dc:date>2002-04-0410:30</dc:date>
<dc:type>text</dc:type>
<dc:format>text</dc:format>
<dc:language>en</dc:language>
<dc:identifier>outlook:fooBarWhoKnows123xyz</dc:identifier>
</rdf:Description>
<subject>Ｎｅｒｖａｎａクライアントに関する考え</subject>
<from>パトリック シュミッツ[cogit@ludicrum.org]</from>
<to>ノサ オモイグイ[nosa@nervana.net]</to>
<to>スティーブ ジョッドキンズ[stevenj007@hotmail.com]</to>
<cc>オモイグイ、イゴサ Ｄ[eghosa.d.omoigui@intel.com]</cc>
<cc>ジェローム ベアード[jbeard@picsmart.net]</cc>
<size>434</size>
</email>
<email>
<objectref guid="12345678-0019-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>転送：次のウェブ（ビジネスウィーク）</dc:title>
<dc:creator>ノサ オモイグイ</dc:creator>
<dc:description>
<n:abstract>一方で、業界はＥＤＩの問題と限界を切実に認識しているので、経営幹部は楽観的である。「決定的なアプリケーションが現実化されるまでは、鶏が先が卵が先がの状況であるだろうが、実現すると確信している」と。スーパーコンピュータの先駆者で現在新興企業のＡｐｐｌｉｅｄ Ｍｉｎｄｓ Ｉｎｃ．の社長のＷ．ダニエル ヒリス氏は語った。
</n:abstract>
</dc:description>
<dc:date>2002-02-2513:44</dc:date>
<dc:type>text</dc:type>
<dc:format>text</dc:format>
<dc:language>en</dc:language>
<dc:identifier>outlook:fooBarWhoKnows123xyz</dc:identifier>
</rdf:Description>
<subject>転送：次のウェブ（ビジネスウィーク）</subject>
<from>ノサ オモイグイ[nosa@nervana.net]</from>
<to>パトリック シュミッツ[cogit@ludicrum.org]</to>
<to>スティーブ ジョドキンズ[stevenj007@hotmail.com]</to>
<to>オモイグイ、イゴサ Ｄ[eghosa.d.omoigui@intel.com]</to>
<to>EghosaO@aol.com</to>
<to>ChereceO@aol.com</to>
<to>ジェローム ベアード[jbeard@picsmart.net]</to>
<cc>ノサ オモイグイ[nosa@nervana.net]</cc>
<size>434</size>
</email>
<email>
<objectref guid="12345678-001A-1234-1234-123456789ABC" />
<rdf:Description>
<dc:title>大手ソフト企業は大変動に備える[Fortune]</dc:title>
<dc:creator>EghosaO@aol.com</dc:creator>
<dc:description>
<n:abstract>ウェブサービスと呼ばれる漠然とした新顔が、マイクロソフト、オラクル、ＩＢＭ、及びソフトウェアの大企業全ての間での新しい戦闘を引き起こしている。</n:abstract>
</dc:description>
<dc:date>2002-03-0213:41</dc:date>
<dc:type>text</dc:type>
<dc:format>text</dc:format>
<dc:language>en</dc:language>
<dc:identifier>outlook:fooBarWhoKnows123xyz</dc:identifier>
</rdf:Description>
<subject>大手ソフト企業は大変動に備える [Fortune]</subject>
<from>EghosaO@aol.com</from>
<to>ノサ オモイグイ[nosa@nervana.net]</to>
<to>cogit@ludicrum.org</to>
<to>lisah@stanfordalumni.org</to>
<to>stevenj007@hotmail.com</to>
<size units="KB">13</size>
</email>
</results>
</srml>

実例Ｂ−意味論的な照会文書
<?xml version="1.0" encoding="utf-8"?>
<sqml>
<head title="foo"> </head>
<filters>
<include>
<type class="nervana:objecttype">
documents
</type>
</include>
</filters>
<attributes></attributes>
<skins>
<documents
color="http://nervana.net/dc.xslt"
design="http://nervana.net/dd.xslt"
animation="http://nervana.net/da.xslt" >
</documents>
<email
color="http://nervana.net/ec.xslt"
design="http://nervana.net/ed.xslt"
animation="http://nervana.net/ea.xslt" >
</email>
</skins>
<query>
<resource type="nervana:filepath">
c:＼foo.doc
</resource>
<resource type="nervana:url">
file://c:＼bar.doc
</resource>
<resource type="nervana:url">
file://c:?includesubfolders=true
</resource>
<resource type="nervana:url">
http://www.bar.com/doc.htm
</resource>
<resource type="nervana:url">
ftp://gate.com/doc.txt
</resource>
<resource type="nervana:url">
＼＼servers＼server＼file.pdf
</resource>
<resource type="nervana:text" arg="contains=fox">
The quick brown fox
</resource>
<resource type="nervana:cacheentry">
ef9c90ea-282d-46d6-b355-ac8a4fc2f3e5
<link predicate="nervana:relatedto"
type="nervana:url">
c:＼foo.doc
</link>
</resource>
<resource type="nervana:url">
agent://email.all@ibm.com
</resource>
<resource type="nervana:url">
objects://rad.com/agency.asp
<link predicate="nervana:containstext"
type="xml:string">
80211
</link>
</resource>
<resource type="nervana:url">
objects://rad.com/agency.asp
<link predicate="nervana:postedon"
type="nervana:datetimeref">
today
</link>
</resource>
<resource type="nervana:url">
objects://rad.com/agency.asp
<link predicate="nervana:postedon"
type="xml:datetime">
01-10-2002
</link>
<link operator="or"
predicate="nervana:postedbefore"
type="xml:datetime">
01-11-2002
</link>
</resource>
<resource type="nervana:url">
agent://documents.all@abccorp.com
<link predicate="nervana:relatedto"
type="nervana:url">
objects://98@in.com/m.asp
</link>
<link operator="and"
predicate="nervana:isofpriority"
type="nervana:priority">
criticalpriority
</link>
</resource>
</query>
</sqml>

実例Ｃ−-セマンティックエンバイロメントの階層

インフォメーションエージェント（意味論的環境のルート）
マイエージェント
頻繁に使用するエージェント
エージェンシー
エージェンシーＡ１
文書
Documents.All
Documents.CriticalPriority.All
電子メール
Email.Technology.Wireless.All
注釈付加
Annotations.RecentlyPosted.PastOneDay.All
人
People.Research.All
イベント
Events.All
Events.Upcoming.NextOneDay.All
エージェンシーＡ２
文書
Documents.Technology.XML.XPath.All
電子メール
Email.Favorites.All
電子学習のコース
ELearning.All
エージェンシーＡ３
ニュース記事
News.Technology.Semiconductors.All
...
Agency AN...
最近使ったエージェント
[上記の階層と類似するが最近使ったエージェント]
最近作成したエージェント
[上記の階層と類似するが最近作成したエージェント用]
フェイバリットエージェント
[上記の階層と類似するがユーザによってお気に入りと印が付けられたエージェント用]
全てのエージェント
[上記の階層と類似するがマイエージェントのリスト内の全てのエージェント用]
削除したエージェント
[上記の階層と類似するが削除する印が付けられたエージェント用]
...カスタムビュー
[上記の階層と類似するがカスタムビューと一致したエージェント用]

実例Ｄ−見出しのコンテキストテンプレートからのＳＱＭＬのアウトプット
<?xml version="1.0" encoding="utf-8"?>
<sqml>
<head title="foo" type="all information"> </head>
<filters>
<include>
<type class="nervana:objecttype">
all information
</type>
</include>
</filters>
<query>
<resource type="nervana:Agency">
wsAgency://marketing.com/Agency.wsdl
<link predicate="nervana:postedinthelast"
type="nervana:time:minutesref">
30
</link>
<link predicate="nervana:relevantto"
type="nervana:sqml">
[object sqml]
</link>
</resource>
<resource type="nervana:Agency">
wsAgency://research.com/Agency.wsdl
<link predicate="nervana:postedinthelast"
type="nervana:time:minutesref">
30
</link>
<link predicate="nervana:relevantto"
type="nervana:sqml">
[object sqml]
</link>
</resource>
<resource type="nervana:Agency">
wsAgency://sales.com/Agency.wsdl
<link predicate="nervana:postedinthelast"
type="nervana:time:minutesref">
30
</link>
<link predicate="nervana:relevantto"
type="nervana:sqml">
[object sqml]
</link>
</resource>
<resource type="nervana:Agency">
wsAgency://humanresources.com/Agency.wsdl
<link predicate="nervana:postedinthelast"
type="nervana:time:minutesref">
30
</link>
<link predicate="nervana:relevantto"
type="nervana:sqml">
[object sqml]
</link>
</resource>
</query>
</sqml>

排他的な所有権、又は特権を主張する本発明の実施の形態を以下に定義する。

請求項１
知識の取得、管理、伝達、及び提示のためのシステムであって、
ドメイン固有の意味論的な情報を追加、及び管理するためにプログラム可能な第一サーバと、
前記第一サーバと通信する第二サーバで、意味論的な情報を分類、及びカテゴリ化するのに使用されるドメイン固有の情報をホストするためにプログラム可能な前記第二サーバと、
前記第一サーバ、及び前記第二サーバとユーザーが通信するためのユーザインターフェースを提供するクライアントと、
前記第一サーバと前記第二サーバのプロセッサは一緒に動作して、
情報源から情報を確保し、
前記情報源から前記情報を意味論的にリンクし、
前記意味論的にリンクされた情報の前記意味論的な属性を保持し、
ユーザの照会に基づいて要求された意味論的な情報を伝達し、
カスタマイズ可能なユーザプレファレンスに従って意味論的な情報を提示する手順を行うことを含むことを特徴とする知識の取得、管理、伝達、及び提示のためのシステム。
請求項２
請求項１記載のシステムにおいて、前記第一サーバは更に、意味ネットワーク、セマンティックデータ ギャザラー、セマンティックネットワーク コンシステンシーチェッカー、インファレンスエンジン、セマンティッククエリ プロセッサ、自然言語パーサ、イーメールナレッジ エージェント、又はナレッジドメイン マネージャの少なくとも１つを提供するための構造又は方法論を含むことを特徴とするシステム。
請求項３
請求項１記載のシステムにおいて、
前記情報源からの前記情報はオブジェクト、又はイベントで構成されており、前記オブジェクト、又は前記イベントは意味論的に互いに関連したアクティブなエージェントで、所定のテーマに従って提示用にデータオブジェクトを返す照会を表現することを特徴とするシステム。
請求項４
請求項３記載のシステムにおいて、前記データオブジェクトの提示に従う前記所定の主題はユーザによってカスタマイズ可能であることを特徴とするシステム。
請求項５
請求項１記載のシステムにおいて、前記クライアントは前記ユーザの照会から結果として生じる前記意味論的な情報を配信し提示することを特徴とするシステム。
請求項６
意味論的な情報を分類及びカテゴリ化するのに使用されるドメイン固有の情報を追加、管理、及びホストするためにプログラムされたサーバシステムと一緒に使用される知識の取得、管理、伝達、及び提示の方法であって、
情報源から情報の確保と、
前記情報源から前記情報の意味論的なリンクと、
前記意味論的にリンクされた情報の前記意味論的な属性の管理と、
ユーザの照会に基づいて要求された意味論的な情報の伝達と、
カスタマイズ可能なユーザプレファレンスに従って意味論的な情報の提示を含むことを特徴とする知識の取得、管理、伝達、及び提示の方法。

知識の取得、管理、伝達、及び提示のシステム及び方法
開示内容の要約
本発明は知識の取得、管理、伝達、及び提示用に統合された実装の枠組み、及びその結果生じるメディアに関するものである。システムは、ドメイン固有の意味論的な情報を追加及び管理する役割を持つ第一サーバの構成要素と、通信メディアを経由して提示プラットフォームを運用するクライアントへの文脈に依存し時間に敏感な意味論的な情報取得サービスを提供するために連携する第一サーバの構成要素が使用する意味論的な情報及び他の情報をホストする第二サーバの構成要素を含む。システム内で、指定の階層内にある全てのオブジェクト、又はイベントは、意味論的に互いに関連し、（基本のアクションコードから成る）照会を表現するアクティブなエージェントで、所定のカスタマイズ可能なテーマ、又は「スキン」に従って、クライアントに提示するためのデータオブジェクトを返す。本システムは、クライアントにエージェント及び基本となる関連した照会をカスタマイズ、及び「混合する」ための多種の手段を提供し、結果として生じる情報の提示を最適化する。
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
付録B

補助的発明

インフォメーション・ナーバス・システムへの補助的発明

オモイグイ・ノサ

パート1. スマート選択レンズ

概要

スマート選択レンズは、インフォメーションナーバスシステム情報媒体のスマートレンズ機能に類似する。この場合、ユーザはオブジェクト内のテキストを選択でき、レンズは選択テキストをオブジェクトとして適用される（選択が変わるに従って動的に新規「画像」が生成される）。この方法ではユーザは、オブジェクト全体か何もなしかのどちらかに「レンズ」を当てることを制約されるのでなく、オブジェクトメタデータの設定可能なサブセットに「レンズ」を当てることができる。この機能は文脈で過負荷したカーソル／動詞の選択と似通っている。例えば、ユーザはプレゼンターのテキストを１つ選択し、テキストが表示されるオブジェクト上で「レンズとしてペーストする」アイコンを押すことができる。プレゼンターは次に、以下のようなメソッド呼出しを使って、クライアントランタイムコンポーネント（ＡｃｔｉｖｅＸのオブジェクトなど）にテキストを送る。
bstrSRML = GetSRMLForText( bstrText );
この呼出しによって引数テキストをカプセル化する一時的なＳＲＭＬバッファを返す。プレゼンターは次のようなメソッドを呼び出す。
bstrSQML = GetQueryForSmartLensOnObject( bstrSRMLObject );
このメソッドによってＳＱＭＬをクリップボードから取り、オブジェクト用の引数ＳＲＭＬを取得し、（「関連する」のデフォルトの述語で）ＳＱＭＬのリンクとしてＳＲＭＬの中のリソースを含む新規ＳＱＭＬを動的に作成する。メソッドは次に新規ＳＱＭＬを返す。プレゼンターは次のようにメソッドを呼び出す。
ProcessSemanticQuery( bstrSQML);
このメソッドによって生成レンズのＳＱＭＬを渡し、結果およびＳＲＭＬ結果の項目数を、好ましくは非同期で取得する。この呼出しに関する詳細は、仕様「インフォメーションナーバスシステムの意味論的ランタイムＯＣＳ」を参照されたい。プレゼンターは次のようなプレビューウィンドウ（または今使っているスキンによる相当物）を表示する。

［レンズエージェントタイトル］
２３項目見つかりました
［プレビューオブジェクト１］
［プレビューウィンドウ制御］

「レンズエージェントタイトル」は、クリップボード上のエージェントの題名である。プレビューウィンドウ（およびプレビューウィンドウ制御）に関する詳細は、当発明者の親出願通し番号１０／１７９，６５１号を参照されたい。
好ましい実施例では、プレビューウィンドウは次を行う。
・ タイマーが切れたあと（５００ｍｓ程度で）非表示となる。マウスの動きによって、タイマーがリセットされるのが好ましい（これでユーザが同じ場所の周辺でマウスを動かすときに、ウィンドウの点滅を回避する）。
・ （最終的に）ゆっくりとフェードアウトする。
好ましい実施例は次の機能も含む。
1. オブジェクトごとに１つの選択範囲であるが、結果の組につき複数の選択ができるのが最適なオプションである。そうでないと、システムは（オブジェクトごとではなく）オブジェクトごと選択ごとのレンズアイコンを表示するために、ユーザにとってわかりにくい経験となり、複雑なＵＩを作り出してしまう。
2. （エージェントレンズと一致させて動的に生成されたＳＱＭＬにもかかわらず、通常のＳＱＭＬクエリである）未解決のレンズクエリのリクエストは、プレゼンターがもはや必要としなくなった時点で取り消されるべきである（例えば、プレゼンターが新しいページをナビゲートしたり、オブジェクトの新しいレンズをリクエストしたりする場合）。いずれにしても、レンズクエリはおそらく一度に数個のオブジェクトを求めるだけであろうから、係る取消しは性能的（または帯域幅）にも重大ではない。たとえクエリが取り消されなくても、プレゼンターは結果を無視することができる。（レンズクエリが取り消されるかどうかに関係なく）いずれにしても、プレゼンターは処分するなどして廃れてしまった結果を始末しないといけないので同じことである。プレゼンターがリクエスト取消しリクエストを出すのと、取消しが実際に完了する間になんらかの遅延が生じる。結果の一部がこの間に漏れる可能性があるので、これらは廃棄する必要がある。従って好ましい実施例には非同期取消し実施が含まれ、ソフトウェアコンポーネントは、常に不良または廃れた結果を無視するよう設計されている。
3. プレゼンターは（現在のレンズのリクエスト状態を示す）アイコンとツールヒントの両方を持っていることが好ましい。ユーザがオブジェクトにマウスカーソルを合わせる、またはクリックすると、プレゼンターはフレーズ「レンズ情報をリクエストする」（またはそれと同じ効果のフレーズ）のようなツールヒントを掲げることができる。情報が戻ってくると、マウスカーソルを合わせることで「２３件のオブジェクトを発見」のヒントが表示され、クリックすると結果が表示される。この割込みツールヒントは、結果が戻ってくるときにまだ表示されている場合には、プレビューウィンドウに移行させることができる。
また、ここで留意すべきは、スマートレンズのようなスマート選択レンズは、テキストメタデータ以外のオブジェクトにも適用できることである。例えば、スマート選択レンズは、画像、ビデオ、オーディオストリームの一部またはその他メタデータに適用できる。これらの場合、プレゼンターはデータタイプと「選択区域」と一致する適切なＳＲＭＬを返す。この区域とは、画像、ビデオ、オーディオストリーム内の時間の間隔などがあり得る。スマートレンズ機能性の残りの部分は、（レンズの下でデータタイプのスキーマに基づくことになる）ＳＲＭＬに基づいて生成される適切なＳＱＭＬに、上述のように適用される。

パート2. 人物オブジェクトのペースト

概要

インフォメーションナーバスシステム（これもこの本出願の好ましい実施例のある側面に対する現在の略名の１つである）は、（人、ユーザ、顧客など）の「人物」オブジェクトのドラッグ＆ドロップ、コピー＆ペーストもサポートする。この場合、好ましい実施例の操作を示す少なくとも２つのシナリオが存在する。
1. 人物の出所の知識コミュニティ（またはエージェンシー）を代表するスマートリクエストに人物オブジェクトをペーストする。この場合、サーバの意味論的クエリプロセッサは、人物を引数として使ったクライアントからのＳＱＭＬを単に解決するに過ぎない。例えば、ユーザが人物「ジョー」をスマートリクエストの「ロイターの見出し」の上にペースト（またはドラッグ＆ドロップ）すると、クライアントは追加引数を使って新しいスマートリクエストを作成する。ロイターのインフォメーションナーバスシステムのウェブサービスは次に、「ジョー」によって注釈、あるいは公開された見出しすべてを返すことで、このリクエストを解決する。この場合、サーバは、本シナリオに対して意味をなす（「〜によって公開か注釈された」）の適切なデフォルトの述語を本質的に適用する。
2. 人物の出所でない知識コミュニティ（またはエージェンシー）を代表するスマートリクエストに人物オブジェクトをペーストする。この場合、人物オブジェクトは（ＳＭＳ上）の送信先の知識コミュニティの意味ネットワークにないため、サーバの意味論的クエリプロセッサは、人物引数の意味が通らない。従って、例えば人物が（好ましい実施例において）専門家または新聞ダネになる人のカテゴリを使うなど、サーバは別の方法で人物引数を解決する必要がある。例えば、上記の例をとると、ユーザが人物「ジョー」をスマートリクエストの「ロイターの見出し」上にペースト（またはドラッグ＆ドロップ）して、ジョーがロイターの知識コミュニティ上の人物でない場合、（好ましい実施例では）ロイターウェブサービスが、「ジョーの専門に関連する」見出しを返さなければならない。この実施例は次に、クライアントがＳＱＭＬを送信先のウェブサービスに送る前に、２つのパスの方法を取る必要がある。まず、その人物が所属する知識コミュニティにその人物の専門を代表する「代表データ（ＳＲＭＬ）」を問い合わせる。ウェブサービスはこのリクエストを次のように解決する。
a. その人物のオブジェクトがペーストあるいはドロップされた知識コミュニティ（ロイターなど）のクエリを行い、そのコミュニティの意味論的ドメインの情報はそのコミュニティの特定の分類法またはオントロジーを構成するおよび／または代表する。ここで留意すべきは、いくつかの意味論的ドメインが存在し得ることである。
b. その人物オブジェクトの出所である知識コミュニティにその人物の意味論的ドメイン情報のクエリを行う。
c. 意味論的ドメインが同一であるか、最低１つの共通する意味論的ドメインが存在する場合、クライアントはその人物オブジェクトの出所である知識コミュニティにその人物の意味論的ドメイン情報のクエリを行う。クライアントは次に、これらのカテゴリを引数としてＳＱＭＬを構築し、その人物がペーストまたはドロップされた知識コミュニティにこのＳＱＭＬを送る。
d. 意味論的ドメインが同一でないか、少なくとも１つの共通意味論的ドメインが存在しない場合、その人物オブジェクトの出所である知識コミュニティにその人物が専門家としてカテゴリに属するいくつかのオブジェクトにクエリを行う。好ましい実施例では、この実行では、専門のカテゴリを正確に表すのに充分な高いオブジェクト数が選ばれるはずである（この数字は実験に基づき選ぶのが好ましい）。この場合のオブジェクトを選択する理由は、送信先ウェブサービスは人物の出所である知識コミュニティのカテゴリを理解せず、よって特有のカテゴリにそれらをマッピングできないことによる。その代わりに、異なる知識コミュニティの間でカテゴリをマッピングする、（インターネットの集中ウェブサービスを通じて）カテゴリのマッパーを採用できる。この場合、送信先の知識コミュニティは、たとえそれらのカテゴリを理解しないとしても、常にカテゴリをＳＱＭＬの一部として受け取り、知識コミュニティはその後に、カテゴリマッパーウェブサービスを使って、これらのカテゴリを内部カテゴリにマッピングする。カテゴリマッパーウェブサービスは、カテゴリの解決法およびカテゴリマッピングを公開する方法を有する。

パート3. スマートリクエストの保存と共有

概要

インフォメーションナーバスシステムの意味論的ブラウザ（インフォメーションエージェントまたはライブラリアン）のユーザは、スマートリクエストをディスクに保存、添付書類として電子メールで送付またはインスタントメッセンジャー（これも添付書類として）で共有またはその他の手段も使える。クライアントアプリケーションは、スマートリクエストを共有可能文書として保存する方法を公開する。クライアントアプリケーションはまた、スマートリクエスト文書を電子メールまたはインスタントメッセンジャーの添付書類として共有する方法も公開する。
共有可能なスマートリクエスト文書は、（バイナリフォーマットで安全なストリームを通じて）ＳＱＭＬをカプセル化するバイナリ文書である。数ある機能の中でも、仕様の保全性を維持し知的所有権を保護できる、意味論的クエリの安全で連続化した表現を提供する。例えば、クエリ自体が研究者の雇用主の企業秘密を具現化している可能性があり、それが公開された場合は、重要で競争力ある情報を競争相手が逆エンジニアして会社に損失をもたらすこともあり得る。これを保護するには、意味論的クエリのＸＭＬバージョン（ＳＱＭＬ）の強力な暗号化または強力な一方向性ハッシュ法など、いくつかの方法がある。共有可能文書には、リクエストを表す拡張子 （．ＲＥＱ）が付いている。クライアントオペレーティングシステムの拡張子ハンドラは、この拡張子を表すためにインストールされる。その拡張子の付いた文書を開ける際には、文書をオープンするために拡張子ハンドラが呼び出される。拡張子ハンドラは、安全なストリームからＳＱＭＬを抽出して文書を開け、意味ネームスペースにＳＱＭＬでスマートリクエストを作成する。ハンドラは次に、意味ネームスペースでスマートリクエストをオープンする。
意味ネームスペースのスマートリクエストを保存するか、ユーザが電子メールの添付書類として送信したい場合、クライアントはスマートリクエストを表すＳＱＭＬをバイナリ．ＲＥＱフォーマットでシリアル化し、リクエストされたディレクトリパスで保存するか、または．ＲＥＱ文書が添付書類として付いた電子メールクライアントを開く。
以下の図1は、スマートリクエストでＳＱＭＬバッファをカプセル化するバイナリ文書フォーマットを示し、拡張子ハンドラの文書の開き方も図示する。同様のモデルを結果共有のために（ＳＲＭＬ経由にて）用いることもできる。この場合、バイナリ文書は、上記のＳＱＭＬの代わりにＳＲＭＬをカプセル化する。

Figure 2006522388
図2は、ウィンドウズ（登録商標）シェルで登録関連付けされた２つの．ＲＥＱ文書（右端の「私の研究レポート（ライブ）に関連するロイターの見出し」および「ロイターの見出し（２００３年１月２１日０８ １７ＡＭ現在）」の表題）を図示する。最初のリクエスト文書は、「ライブ」で、二番目の文書は特定時間のスナップショットである（どちらも時間に敏感なリクエストである）。ここで留意すべきは、オペレーティングシステムが意味論的ブラウザ・アプリケーション（ナバナライブラリアン（Ｎｅｒｎａｖａ Ｌｉｂｒａｒｉａｎ））を文書と関連付けたことである。文書を開くと、意味論的クエリがアプリケーションで開かれる。

Figure 2006522388
・ エンティティの保存と共有 − エンティティを表す。ＥＮＴ拡張子が付く以外は、上記と同じプロセスが適用される。エンティティ文書が呼び出されると、ナバナライブラリアンは、エンティティＳＱＭＬをブラウザに開く。
・ 拡張子特性シート − 一時的なスマートリクエストまたはエンティティ（文書の種類によって）を意味論環境に作成し、スマートリクエストまたはエンティティに関する特性シートを表示する。
・ 拡張子ツールヒント − ユーザがライブラリアン文書（リクエスト、．ＲＥＱまたはエンティティ、．ＥＮＴ）にマウスを合わせた際に、役立つツールヒントを表示する。

パート4. スマートスナップショットの保存と共有

概要

インフォメーションナーバスシステムは、当発明者が「スマートスナップショット」と呼ぶ物の共有もサポートする。スマートスナップショットは、スマートリクエストをある時点で凍結したものである。これでユーザがスマートリクエストを共有したいが、「ライブ」である必要はない場合に役立つ。例えば、デフォルト設定でユーザが、「この文書に関連するロイターのニュース速報」というスマートリクエストを同僚と共有する場合、同僚は（「現在の時間」を基にして）スマートリクエストのライブ結果を見られる。ただし、ユーザが「この文書に関連するロイターの［現在の時間の］ニュース速報」を共有したい場合は、スマートスナップショットが用いられる。
スマートスナップショットは、ＳＱＭＬ文書の「属性」部分にスナップショット（フラグＱＵＥＲＹＡＴＴＲＩＢＵＴＥＳ＿ＳＮＡＰＳＨＯＴ）であることを印す属性が含まれることを除けば、スマートリクエストと同じである（ＳＱＭＬクエリ文書によって表される）。ＳＱＭＬ文書の作成日／時間もＳＱＭＬに保存される（前と同様に、ＳＱＭＬスキーマには作成日／時間のフィールドが含まれる）。ユーザがスマートリクエストを共有する意向を示すとき、ユーザインタフェース（意味論的ブラウザ、インフォメーションエージェントまたはライブラリアン）は、スマートリクエスト（ライブ）かスマートスナップショットのどちらを共有したいのかを尋ねる。ユーザがスマートリクエストを指定する場合、上記で説明したプロセス（パート３）が用いられる。ユーザがスマートスナップショットを指定すると、バイナリ文書は編集済みのＳＱＭＬ（スナップショット属性を含む）をポピュレートして、残りのプロセスに上記のように従う。
バイナリ文書を（電子メール、インスタントメッセージングなどで）受信者が受け取り開くと、拡張子ハンドラが文書を開き、エントリをスマートリクエストとして意味ネームスペースへ追加する（上記で説明の通り）。受信者がスマートリクエストを開くと、クライアントの意味論的クエリプロセッサが処理済みのＳＱＭＬを（前回説明の通り）サーバのＸＭＬウェブサービスへ送信する。サーバの意味論的クエリプロセッサは次に、ＳＱＭＬを処理し、ＳＱＭＬの作成日／時間に関連する意味論的クエリを呼び出して、スナップショット属性を受け入れる。このように結果は元の日／時間に関連させることにより、送信者の意向が尊重される。

パート5. 仮想知識コミュニティ

仮想知識コミュニティ（エージェンシー）とは、サーバ群が１つのサーバであるかのように見せて発行することを知識コミュニティの発行者に許可するインフォメーションナーバスシステムの一機能である。例えば、ロイターは業界ごとのロイター知識コミュニティ（医薬品、石油とガス、製造業、金融サービスなど）を持つことができるが、１つの「ロイター」の知識コミュニティに公開することを選択する場合がある。これを行うには、ロイターは（ＸＭＬウェブサービスのＷＳＤＬのＵＲＬの代わりに）仮想知識コミュニティに対するＳＱＭＬを発行および発表する。ＳＱＭＬには、実際の知識コミュニティのＷＳＤＬブレンダー（または集合）が含まれる。意味論的ブラウザは次に、ＳＱＭＬを取り込み（単一サーバであるかのように）知識コミュニティのアイコンを表示する。知識コミュニティに関するいかなるアクションも、ＳＱＭＬの各サーバに広められる。ユーザが係るアクションへのアクセスを持たない場合、ウェブサービス呼出しはそれに従って不成功に終わるが、そうでなければアクションが行われる（ユーザが知識コミュニティを含むブレンダーをマニュアルで作成するのと変わらない）。

パート6. 時間に敏感な意味論的クエリの実行

時間に敏感な意味論的クエリは、問題となる知識コミュニティ（エージェンシー）での知識生成率にあった知的な方法で実行するのが好ましい。例えば、毎秒１０の文書を入手するサーバの「ニュース速報」は、毎月１０の文書を入手するサーバの「ニュース速報」とは同じではない、同様に、サーバ側の意味論的クエリプロセッサは、時間に敏感な意味論的クエリ扱いを、情報のサーバでの累積率に従って調節するのが好ましい。これを実行するには、例えば、一般的な規則の目安は次のようである。

・ 毎分の新規オブジェクト数に基づいてＮが調節される、最も最近のＮオブジェクト
・ オブジェクト数に上限をつけた、最後のＮ分間に入手した全オブジェクト数（最小値（上限、過去Ｎ分間に入手した全オブジェクト数））

クエリが見出しかニュース速報かに基づき、Ｎを調節することができる。好ましい実施例では、新聞ダネになる人のクエリは、見出しと同じ時間に敏感なパラメータで実施することが好ましい。

パート7. 音声変換スキン

概要

音声変換はオブジェクトレベルおよびリクエストレベルで実装される。オブジェクトレベルでは、オブジェクトスキンはオブジェクトのＳＲＭＬを取るためのスクリプトを実行し、ＳＲＭＬを解釈し、次に（ＳＲＭＬフィールド内の）テキストが選択した部分を（マイクロソフトウィンドウズのスピーチＳＤＫなどを使って）音声変換エンジンに渡して音声出力を生成する。
図3は、音声変換オブジェクトスキンの図を示す。実行されると、図3で示すパイプラインは、次のような音声出力として表示される。
1. 電子メールメッセージの読込み
2. 適切な遅延
3. ノサ・オモイグイからのメッセージ
4. 適切な遅延
5. ジョン・スミス宛に送られたメッセージ
6. 適切な遅延
7. ジョー・サムボディにコピーしたメッセージ
8. 適切な遅延
9. 「メッセージ主題はウェブサービス」は、分散コンピューティングに使われるソフトウェア構築ブロックである
10. 適切な遅延
11. 「メッセージ要約」はウェブサービス
12. 適切な遅延
13. 「［オプションの］ メッセージ本文はウェブサービス」は、分散コンピューティングに使われるソフトウェア構築ブロックである。
この例は、次のような音声スキンテンプレートを想定する。
1. 電子メッセージの読込み
2. 適切な遅延
3. ＜メッセージ作者名＞からのメッセージ
4. 適切な遅延
5. ＜宛先： 受信者＞ へ送信されたメッセージ
6. 適切な遅延
7. ＜メッセージｃｃ： 受信者名＞
8. 適切な遅延
9. メッセージの主題は ＜メッセージ主題テキスト＞
10. 適切な遅延
11. メッセージ要約は ＜メッセージ本文要約＞
12. 適切な遅延
13. ［オプションの］メッセージ本文は ＜メッセージ本文＞

音声を演出するのに、理解しやすく、提供するオブジェクトの意味を伝えるその他のテンプレートも使用できる。上記に示す例（電子メール用）のように、オブジェクトタイプの意味を捉えるには、実装には、すべての情報オブジェクトタイプに対して適切な音声変換テンプレートを使うべきである。
リクエストレベルでは、意味論的ブラウザの表示エンジン（プレゼンター）が（ユーザ選択のカーソル位置に基づいて）演出されるすべての最新オブジェクトに対してＳＲＭＬを取るスキンを読み込み、次に各オブジェクトに対して音声変換オブジェクトスキンを呼び出す。これは基本的には、演出される各ＸＭＬオブジェクトに対して音声変換アクションを次々に繰り返す。

Figure 2006522388
以下の図4は、リクエストスキンを通して意味論的ブラウザに表示される、いくつかの電子メールオブジェクトの図示である。

Figure 2006522388
パート8. 言語翻訳スキン

言語翻訳スキンは、変換が言語軸上であることを除けば、音声変換スキンと同じように実装される。ＸＳＬＴスキン（スマートスタイル）は、言語翻訳をリアルタイムで自動的に行うためのソフトウェアエンジンを呼び出すことができ、その後世界各国の言語を表すためにユニコード（文字当り１６ビット）でコード化されたＸＭＬを生成する。最終的な表示出力を生成するＸＳＬＴ変換は、翻訳されたＸＭＬの内容を基に適当な文字セットを使って出力を処理する。

パート9. ユーザ経験でのファーストクラスのオブジェクトとしてのカテゴリ

これは、知識コミュニティのカテゴリがエンドユーザに公表される機能のことである。エンドユーザは情報タイプ（「ウェブサービス」など）としてカテゴリに対してクエリを発行できる。次にメタデータが任意のファーストクラス情報のオブジェクトタイプの場合と同様に、意味論的ブラウザに表示される。視覚化、動的リンク、文脈パレットなども、カテゴリオブジェクトをピボットとして使って使用できる。この機能は、カテゴリをパラメータとして持つスマートリクエスト（スマートエージェント）で開始するのではなく、ユーザがカテゴリで開始して、そのカテゴリを動的ナビゲーションのピボットとして使いたい場合に役に立つ。

パート10. 分類された注釈

分類された注釈は、ファーストクラスのオブジェクトであるカテゴリから得られる。ユーザはカテゴリに直接注釈を付けることができ、従ってカテゴリにマッピングされた電子メールリストをシミュレートする。ただし、（例えば医薬品など）カテゴリが多くある場合、情報が多数のカテゴリに属する場合があり、ユーザがどのカテゴリに注釈を付けるかを考える必要があるべきではないので、この方法は薦められない。ユーザは注釈を自動的に分類される知識コミュニティ（エージェンシー）に直接発行する、あるいはカテゴリよりも文脈的である文書または電子メッセージのようなオブジェクトに注釈を付けるべきである。

パート11. 補助的文脈テンプレート

1. 専門家 − この機能は、当発明者の親出願では特別エージェントとして示したが、文脈テンプレートの項目からは誤って削除された除外された。専門家は文脈テンプレートであり、その名称が示唆するように、１つ以上の主題または文脈に専門知識を有する人々を示す（ＰＲＥＤＩＣＡＴＥＴＹＰＥＩＤ＿ＥＸＰＥＲＴＯＮ属性で示す）。

２. 私の項目の注釈 − これは注釈の変形である文脈テンプレートであるが、呼び出すユーザによって発行された項目でさらにフィルタリングされている。これによってユーザが掲載したか注釈を付けた項目に関して特別にフィードバックを監視できる

パート12. ユーザ状態のインポートとエクスポート

意味論的ブラウザは、ユーザ状態のインポートとエクスポートをサポートする。ユーザは各自の個人的な状態を文書に保存でき、それを別のマシンにエクスポートしたり、その逆をしたりすることも可能である。この状態には次のような情報（およびメタデータ）が含まれる。

・ デフォルトのユーザ状態（コンピュータ高度化レベル、関心分野のデフォルト、ジョブ役割デフォルト、スマートスタイルのデフォルトなど）
・ プロフィール
・ エンティティ（プロフィールごと）
・ スマートリクエスト（プロフィールごと）
・ ローカルリクエスト（プロフィールごと）
・ 登録する知識コミュニティ（プロフィールごと）

意味論的ブラウザは、ユーザにどちらのユーザ状態タイプをインポートまたはエクスポートするかを選択させるＵＩ（ウィザードの可能性あり）を示す。ＵＩはまた、ユーザに識別／ログオン情報を含めるかどうかを尋ねる。ＵＩが呼び出されると、意味論的ブラウザはユーザ状態を、全ユーザ状態タイプのメタデータと一致するフィールドを持つＸＭＬ文書にシリアル化する。ＸＭＬ文書がインポートされると、意味論的ブラウザはＸＭＬ文書ノードをナビゲートし、ＸＭＬ文書のノードと一致するクライアント環境のユーザ状態タイプを追加または設定する。

パート13. ローカルスマートリクエスト

ローカルスマートリクエストは、ユーザが知識コミュニティ（エージェンシー）からのカテゴリを使ってローカル情報をブラウズすることを可能にする。分類されたローカルリクエストの場合、意味クライアントはローカルハードドライブ、電子メール格納などをクロールし、（概要を含む）メタデータを抽出し、メタデータを意味論的メタデータ格納（ｓｅｍａｎｔｉｃ ｍｅｔａｄａｔａ ｓｔｏｒｅ、ＳＭＳ）のローカルバージョンに保存する。クライアントはＸＭＬメタデータを（オブジェクトごとに）分類のために知識コミュニティに送る（そのコミュニティのＸＭＬウェブサービスを経由）。知識コミュニティは次にカテゴリ割当てメタデータで対応する。クライアントは次に、（ローカルＳＭＳ経由で）ローカル意味ネットワークを更新し、サーバが行うのと同様に意味論的クエリに対応する。本質的に、この機能はローカルサーバに等しい機能性を提供できる。

パート14. 統合ナビゲーション

統合ナビゲーションは、ユーザが（右側の主な結果ウィンドウペイン内の）プレゼンター内で動的にナビゲートすることを可能にし、ナビゲーションを左側のシェル拡張子ナビゲーションと統合化させる。実質的にこれによって両方のスタックが統合される。好ましい実施例では、これはイベントシグナル伝達を通して達成される。プレゼンターが新しいリクエストに動的にナビゲートしたい場合、現在のブラウザビューを識別するＧＵＩＤに何らかの状態を引き起こす。ＧＵＩＤは、「ナビゲーションイベント」、「次のネームスペースオブジェクトＩＤ」および「次のパス」と呼ばれるフィールドも持つレジストリにキーにマッピングする。「ナビゲーションイベント」フィールドは、ロードされると現在のブラウザビューで作成されるイベントハンドルを指すＤＷＡＲＤ値を有す。プレゼンターが新規リクエストへのナビゲートを希望する際には、意味論環境にリクエストを作成しリクエストの返されたＩＤをキャシュに入れる。次に（リクエストの情報／文脈タイプ次第で）リクエストの適切なネームスペースパスを動的に取り込み、それもキャシュに入れる。その後２つのフィールド（「次のネームスペースオブジェクトＩＤ」および「次のパス」をこの２つの値で）を設定する。次に、「ナビゲーションイベント」（ウィンドウズでは、「ＳｅｔＥｖｅｎｔ」という名のＷｉｎ３２ＡＰＩを呼び出して行う）を設定する。
ナビゲーションイベントを取り込むには、ブラウザビューは最初に開始されたときにワーカースレッドを開始する。このスレッドはナビゲーションイベント上で待機し（同時にブラウザビューが終了する際にシグナル伝達されるシャットダウンイベント上で待機する − ウィンドウズでは「ＷａｉｔＦｏｒＭｕｌｔｉｐｌｅＯｂｊｅｃｔｓ」という名のＷｉｎ３２ ＡＰＩ経由で行われる）。ナビゲーションイベントがシグナル伝達されると、ナビゲーションイベントがシグナル伝達されたことを示す「待ち」ＡＰＩを返す。ワーカースレッドは次にレジストリを調べて、（オブジェクトのＩＤとパスの）ナビゲーション状態を取得する。次にシェルブラウザを呼び出し、このオブジェクトＩＤとパスにナビゲートする（ウィンドウズでは、これは「ＰＩＤＬ」を取得し、次にＩｓｈｅｌｌＶｉｅｗを実装するシェルビューインスタンスからＩｓｈｅｌｌＢｒｏｗｓｅｒ：：ＢｒｏｗｓｅＴｏを呼び出すことで行われる）。

パート15. 探訪結果のヒント

ナバナ（Ｎｅｒｖａｎａ）意味論的ブラウザは、ユーザが思考速度で知識スペースを動的にナビゲートする力を与える。ユーザは文脈、情報または時間軸に沿ってナビゲートできる。ただし、ユーザがナビゲートするに従い、重複した情報が提示される可能性がある。例えば、ユーザがローカル文書から「ニュース速報」にナビゲートでき、「ニュース速報」の結果オブジェクトの１つから「見出し」へナビゲートできる。しかし、意味論的には、見出しの一部はニュース速報と重複する場合がある（特に充分な時間が経過していない場合）。これはウェブをブラウズして同じページを何度も繰り返し別の「角度」から参照するのと同じである。
ナバナ意味論的ブラウザは、最近提示された結果のローカルキャシュを設けることによって、この重複問題を処理する。プレゼンターは次に、結果を別の色または別のＵＩ機構で示して、重複結果をユーザに示す。ローカルキャシュは時間を経ている（数時間、あるいは一般的な「ブラウジングの経験」の測定時間を経た後が好ましい）。古いエントリは消去され、キャシュは充分な時間が経過した後で最終的にリセットされる。
意味論的ブラウザはまた、例えば、同じメタデータを持つ複数オブジェクトが異なる知識コミュニティ（エージェンシー）に表示される場合、プレゼンターでレンダリングする前に、重複結果を削除して処理する。意味論的ブラウザは、メタデータの比較を行ってこれを検出する。文書、電子メールなどのような体系化されていないデータに関しては、意味論的ブラウザは概要を比較する。概要が同一の場合、文書も同一である可能性が高い（絶対的な保証はできないが、長文の場合は特にそうである）。

パート16. 知識連合

知識連合とは、知識コミュニティの範囲内で外部知識を連合させることができる技術である。例えば、多くの会社は情報を提供するロイターのような外部コンテンツプロバイダに依存する。ただし、インフォメーションナーバスシステムでは、注釈、個人発行物などに関連するセキュリティおよびプライバシーの問題が発生する。多くのエンタープライズ顧客は、外部コンテンツプロバイダがホストし管理する遠隔サーバに機密情報の注釈が格納されることを望まない。
これに対処するには、外部コンテンツプロバイダがＫＩＳメタデータキャシュのコンテンツを提供し、それを会社がホストし管理する。例えば、ロイターはインテルのようなクライアントにコンテンツを提供するが、インテルがＫＩＳをホストし管理する。インテルのＫＩＳはロイターのＫＩＳ（これによってＫＩＳサーバをつなぐ）またはロイターのＤＳＡをクロールする。こうすることにより、インテルの機密情報の注釈は、インテルが機密情報データへのコントロールを維持しながら、ロイターのコンテンツを文脈として使って、「ポストイット」として発行できる。
連合情報コミュニティ用のカテゴリ命名 例えば、インテルで導入されるロイターの知識コミュニティ（エージェンシー）は、Reuters@Intelのように命名され、そのカテゴリは「Reuters@Intel/InformationTechnology /Wireless/80211」のように命名される。

パート17. 匿名の注釈および発行物

意味論的ブラウザはまた、ユーザが知識コミュニティ（エージェンシー） に匿名で注釈を付け発行することを可能にする。このモードでは、メタデータは（ユーザ識別情報と共に）完全に保存されるが、発行者が匿名のままでいることを希望することを示すフラグが付けられる。こうすることにより、推論エンジンは、完全なメタデータを使って推論できるが、発行者は身元を明かさないように要求できる。逆に管理者は、推論エンジンが匿名の注釈または発行物を使って推論できないよう、知識コミュニティ（エージェンシー）を設定することもできる。

パート18. 意味論的ブラウザでのオフラインサポート

意味論的ブラウザはオフラインサポートも有する。ブラウザは遠隔呼出しすべてに対してキャシュを有する。キャシュはＸＭＬデータへのエントリを含む。これはＳＲＭＬ、またはＸＭＬウェブサービスへの呼び出しから返ってくるその他データでもあり得る。各呼出しは、意味論的ブラウザによって固有の署名が与えられ、この署名はＸＭＬデータにハッシュするのに使用される。例えば、意味論的クエリはＳＱＭＬによってハッシュされる。その他の遠隔呼出しは、方法名、引数の名前およびタイプ、引数データの組合せを使ってハッシュされる
ＸＭＬウェブサービスへのすべての呼出しに対して、意味ランタイムクライアントは呼出しの署名を抽出してローカルキャシュのエントリへにマッピングする。ブラウザ（またはシステム）が現在オフラインの場合、クライアントはＸＭＬデータを（存在する場合は）キャシュに戻す。キャシュが存在しない場合、クライアントは呼出し側（プレゼンターの可能性が高い）にエラーを返す。ブラウザがオンラインの場合、クライアントはＸＭＬウェブサービスからＸＭＬデータを取り出して、署名ハッシュが示すファイルパスで、ファイルエントリの以前のコンテンツを上書きしてキャシュを更新する。これは遠隔呼出しが実際に可能であることを想定する。ネットワークの混雑やその他の条件によりシステム/ブラウザがオンラインの場合でもできない可能性がある。そのような場合、キャシュは上書きされない（新しいデータが存在する際にのみ上書きされ、最初に消去されない）。

パート19. 意味論的ブラウザでの保証付きクロスプラットフォームサポート

概要

当発明者の親出願で説明したように、インフォメーションナーバスシステムはクロスプラットフォームで実施することができる。標準プロトコルは可能な場所で用いることが好ましく、ウェブサービス層には相互操作が可能なウェブサービス基準を使い、独自仕様の実装は避けるべきである。本質的には、ウェブサービスが対話中の知識コミュニティ（またはエージェンシー）が特定のプラットフォームで実行中かどうかを「知る」必要はないということである。例えば、意味論的ブラウザは対話中のウェブサービスが（専有のアプリケーションサーバの２つの例である）マイクロソフトの．ＮＥＴ（登録商標）プラットフォームかサンのＪ２ＥＥ（登録商標）プラットフォーム、リナックスまたはその他の「オープンソース」サーバで実行中かを知る必要はない。知識コミュニティのウェブサービスおよびクライアントサーバのプロトコルは、．ＮＥＴ（登録商標）やＪ２ＥＥ（登録商標）などの異なるウェブサービスの実施で一般にサポートされるウェブサービス基準を採用すべきである。
あえて言えば、ウェブサービスのベンダー実装全体で支持され適切に実装される共通した基準一式が存在することが理想である。ただし、現実には難しく、少なくとも今はまだ可能ではない。意味論的ブラウザが異なるウェブサービスの実装における独自の機能性を扱わなくてはならない場合、知識コミュニティのスキーマは、ウェブサービスプラットフォームの実装を示すフィールドを含むよう、拡張されていることが好ましい。例えば、知識コミュニティの．ＮＥＴ（登録商標）実装は、プラットフォームが．ＮＥＴ（登録商標）であることを示すフィールド付きで発行されるのが好ましい。同じことがＪ２ＥＥ（登録商標）にも当てはまる。そうすれば、意味論的ブラウザが、（ＷＳＤＬ ＵＲＬ経由で直接知識コミュニティへ、マルチキャスト、エンタープライズディレクトリ（ＬＤＡＰなど）、グローバル知識コミュニティなど通じて通知を受けることによって）知識コミュニティのメタデータを取得する際に、このフィールドにアクセスすることができる。
意味論的ブラウザはその後に、知識コミュニティが実行中のプラットフォームによって、プラットフォーム固有の呼出しを発することができる（例えば、Microsoft、IBMやその他業者が支持しても、Sun（WS-セキュリティ、WS-ルーティング、WS-付属物など）は全面的に支持していない基準が存在する）。プラットフォーム固有の呼び出しを行うことが絶対に必要である場合以外ではこれは薦められる方法ではない。このモデルは好ましい実施例で用いられることが好ましい。

パート20. 知識モデル化

知識モデル化とは、エンタープライズがインフォメーションナーバスシステムを導入する上で薦める方法を指す。これには（高度の知識ドメインごとに）いくつかのＫＩＳサーバと、関連するオントロジーおよび分類化をホストする１つ（または多くて数個）のＫＤＳ（旧ＫＢＳ）のサーバの導入が関係する。狭すぎるためにネットワークでのナビゲーションと推論の充分な知識共有の可能性がないのと、高すぎるために（データベースおよび／または推論エンジンが必要とする格納とＣＰＵの馬力における）スケーラビリティが問題となる場合の間のバランスを取るよう、ＫＩＳサーバはドメインごとに導入することが好ましい。もちろん、具体的なバランスポイントは、ハードウェアとソフトウェア技術の発達に伴い経時変動するが、好ましい実施例では特定のバランスに依存するものではない。また、ＫＩＳサーバは、複数のグループが同じＫＩＳを共有するグループレベルでアクセス制御を強いるのではなく、（より高度のセキュリティのために）サーバレベルでアクセス制御が必要になるポイントで実装されることが好ましい。例えば、大手の医薬品会社は、会社全体のオンコロジーに知識コミュニティのＫＩＳを有し、別のＫＩＳを先端のＲ＆Ｄに従事する研究者や戦力的特許出願用意有することができる。これら２つのＫＩＳは、同じ情報ソースをクロールするかもしれないが、Ｒ＆Ｄのグループからのユーザのみにアクセスを提供するため、後者のＫＩＳのほうがより安全である。また、これらの研究者の発行物や注釈は企業のＫＩＳでは参照不可能である。
以下の図5は、医薬品会社用に考えられる知識アーキテクチャの実施例を示す。

Figure 2006522388


パート21. ＫＩＳハウスキーピングの規則

知識統合サーバ（Ｋｎｏｗｌｅｄｇｅ Ｉｎｔｅｇｒａｔｉｏｎ Ｓｅｒｖｅｒ 、ＫＩＳ） は、管理者が「ハウスキーピング」規則を設定して、古いか廃れたメタデータを消去することを可能にする。これによってＫＩＳ上のＳＭＳが無限に大きくなることを防ぐ。この規則は一定の年数（会社の旧データ保管方針によって２−５年の間）よりも古く、注釈がなく、お気に入りとしてマークされない（または格付けされない）メタデータを消去するという簡単なものでもよい。

パート22. クライアントのコンポーネント統合およびワークフローの相互作用

1) シェル：ユーザはＵＩナビゲーションまたはウィザードを通じて、潜在的にＳＱＭＬクエリ（エージェントなど）を作成する。
2) シェル：ユーザが（ツリーまたはフォルダの参照経由で）エージェントをオープンする。
3) クエリバッファはファイルとして保存され、作成されたレジストリのエントリはエージェント用に作成される。
a) レジストリのエントリには次が含まれる：エージェント名、作成日、エージェント（リクエスト）− ＧＵＩＤ、ＳＱＭＬパス、コメント、ネームスペースオブジェクトタイプ（エージェンシー、エージェント、ブレンダーなど）および属性
4) シェル：リクエストはプレゼンターに渡される。
a) レジストリリクエストのＧＵＩＤエントリは、(リクエストを生成したネームスペースパス、ＳＱＭＬファイルＵＲＬ)を含めて作成される。
b) ブラウザを初期化し、http://PresenterPage.html#RequestGUID、http://presenterpage.html/ のコマンドラインとともに開く。プレゼンターは、ページに含まれるデフォルトのクロムをロードする。
c) プレゼンターページはプレゼンターのバイナリ動作と意味論的ランタイムＯＣＸをロードする。
5) プレゼンター：ＳＱＭＬをロードし、クエリマネージャを通じてリクエストを発行する。
a) ＳＱＭＬファイルパスを得るために、リクエストＧＵＩＤを解決する。
b) ＳＱＭＬファイルをバッファにロードし、リソースハンドラのリクエストを作成し、それらをリソースハンドラに渡し、結果を待ち収集する。ローカルリソースの要約はここで発生する。すべての要約は次の２つのパスのうち１つに従う。このファイルパスが示すｄｏｃを要約するか、（クリップボード、アウトルック、エクスチェンジなどから抽出された）そのテキストを要約する。両方のパスは、意味サーバＸＭＬウェブサービスへのリクエストに含むのに適するように、同じ形式で要約を作成する。
c) 上記の任意のリソース要約など、ＳＱＭＬファイルを個別のサーバリクエストバッファにコンパイルする。
d) 意味論的ランタイムクライアントのクエリマネージャを呼び出してサーバリクエストを開始する。
6) クエリマネージャ：サーバリクエストを監視し、データのコールバックを行う。また、要求があり次第イベントの完了またはタイムアウトを伝達する。コールバックはプレゼンターへ入るが、これはＸＭＬを渡すプロセス間のメッセージ伝達を意味する。
7) プレゼンター：データを受信し適切なスキンをロードする。
a) ＳＲＭＬデータをバッファで受け取る。これはインクリメントで行われる。
b) このエージェントに関連する好ましいスキン（スマートスタイル）があるかどうかを判断し、なければデフォルトのスキンを選択する。
c) ＸＳＬＴを通じてＳＲＭＬを好ましいスキンフォーマットに変換する。これは結果が出るに従い、結果のツリーは多段式である（ルートはリストで、次にオブジェクトでディープ／レンズ／ＢＮ情報）。
d) 結果をターゲットＤＩＶでページに表示する。ターゲットは動作自体への引数であり、ルートページにより定義される
8) プレゼンター： 意味論的ランタイムを呼出して、（文脈テンプレートごとの）文脈パネル、ディープインフォメーション、スマートコピー＆ペーストその他意味論的コマンドで埋める。プレゼンターはまた、スマートスタイルをロードし、次にリクエストの意味と一致する意味論的画像、動きなどをロードする。
以下の図6は、上記で説明した本発明の好まれるクライアントコンポーネント統合およびワークフローの相互作用を示す。

Figure 2006522388

ディープインフォの仕様

インフォメーションナーバスシステム用のディープインフォメーションの仕様

オモイグイ・ノサ

パート1. ディープインフォメーション

ディープインフォの概要

はじめに

好ましい実施例では、ナバナの「ディープインフォ」ツールは、ナバナ情報オブジェクトに対して、文脈依存の物語風の情報を提供することを目的とする。ディープインフォは本質的に、ナバナのユーザに、特定の文脈において本来なら失われるはずの情報を提供する。おおよその例えでは、ディープインフォは、（現在のアーティスト、流行歌や場合によっては、歌の中の楽器に関する情報を示す）ＭＴＶのミュージックビデオに表示される文脈情報のようなものである。
「ディープインフォ」の「ディープ」とは、オブジェクトの出所であるエージェンシーの意味ネットワークで、文脈情報がしばしば複数の「ホップ」に渡ることを指す。「ディープインフォ」は、計画テキストメタデータまたは（ＳＱＭＬ経由での）意味論的クエリリンクでのメタデータのどちらかであり得る「ディープインフォナゲッツ」から成る。
好ましい実施例では、最低５種類のディープインフォナゲッツが存在する。
１．基本的な意味論的リンクのナゲッツ
２．文脈テンプレートのナゲッツ
３．雑学ナゲッツ
４．仲介役ナゲッツ
５．再帰ナゲッツ

基本的な意味論的リンクのナゲッツ

基本的な意味論的リンクの真理では、ディープインフォナゲッツは、現在のオブジェクトの意味論的リンクを伝えるのみである。これらのナゲッツは、意味論的リンクの距離１に関与する。この場合、「リンク」文脈／タスクペインに表示されるものとの重複が存在する。

それらの例は次の通りである。
・ パトリック・シュミッツは、ノサ・オモイグイに直属する
・ パトリック・シュミッツは、５つの直属部下を持つ
・ パトリック・シュミッツは、４７件のオブジェクトに注釈を付けた
・ パトリック・シュミッツは、１３件のオブジェクトを著作した。
・ パトリック・シュミッツは、５６件の電子メールオブジェクトにコピーされた

文脈テンプレートのナゲッツ

文脈テンプレートのナゲッツは、手許にある情報を基に、各関連文脈テンプレートの文脈情報を表示する。これらのナゲッツは、各文脈テンプレートのタイプに対して、文脈バーまたは文脈パネルに表示されるものと同一である。

次はその例である。
・ パトリック・シュミッツは、３件のニュース速報項目を掲載した
・ パトリック・シュミッツは、１４件の名著を掲載した
・ パトリック・シュミッツは、１７件の見出しを著作した
・ パトリック・シュミッツは、１３件の会話に参加する。
・ パトリック・シュミッツは、３５６件のオブジェクトに関する新聞ダネになる人である。

雑学ナゲッツ

エージェンシー上のすべての電子メールオブジェクト用の例
・ スティーブ・ジュドキンスは、そのうちの全ての「宛先」リストに登場する
・ スティーブ・ジュドキンスは、そのうちの２３％に返答した
・ パトリック・シュミッツは、そのうちの５０％に注釈を付けた
・ そのうちの３件のみが、２より大きいスレッド深度を有する

エージェンシー上のすべての人々オブジェクト用の例
・ パトリック・シュミッツは、電子メールをそのうち４７％に送信した
・ そのうち１４％は、ノサ・オモイグイに直属する
・ サリー・スミスは、そのうちの８５％と会話を持った
・ そのうちの１２％は、最低一件のトピックに関する新聞ダネになる人である
・ そのうちの全ては、今週最低一件の会話に関わっている
・ そのうちの３３％は、最低１つのトピックに関して専門家である
・ そのうちの８％は、三つ以上のトピックに関して専門家である

エージェンシー上の任意の配布リスト用の例
・ スティーブン・ジュドキンスは、このリストに最多の電子メールを掲載した
・ サラ・トレントは、このリストに最多の電子メールに返答した
・ ノサ・オモイグイは、このリストに掲載したことがない
・ パトリック・シュミッツは、今月このリストに８７件のメッセージを掲載した
・ リチャード・ノボトニーは、今年このリストに３４５件のメッセージを掲載した

エージェンシー上のすべての配布リスト用の例
・ スティーブン・ジュドキンスは、すべてのリストに最多の電子メールを掲載した
・ リサ・ヘイブロンは、すべてのリストのたったの２％にしか電子メールに返答していない
・ ノサ・オモイグイは、どのリストにも掲載したことがない
・ パトリック・シュミッツは、すべてのリストに最低週に一度は掲載した
・ リチャード・ノボトニーは、３つのリストにメッセージを掲載した。

エージェンシー上のすべての情報オブジェクト用の例
・ スティーブン・ジュドキンスは、最も多作の発行者である（そのうちの５％を発行した）
・ サリー・スミスは、最も多作の注釈者である（そのうちの２％に注釈を付けた）
・ ノサ・オモイグイは、最も活発な新聞ダネになる人である
・ パトリック・シュミッツは、最も統合的な専門知識を持つ
・ スティーブ・ジュドキンスは、今年発行された情報に関して最多の専門知識を有する
・ ガヴィン・シュミッツは、最も多く会話に参加している（そのうちの１２％）
・ リチャード・ノボトニーは、今月最も多く会話に参加した（そのうちの１８％）

仲介役ナゲッツ

人物から人物へ
意味論的リンクベース
・ パトリック・シュミッツは、電子メールを１３人に送信した
・ ４７人がパトリック・シュミッツと同じ「宛先」リストに登場した
・ ４７人がパトリック・シュミッツと同じＣＣリストに登場した
・ 合計８９人が、パトリック・シュミッツが送信した電子メールで参照された
・ ２４人が、パトリック・シュミッツと同じ情報を注釈付けた
・ ３人が、パトリック・シュミッツと同じ全配布リストに載っている
・ ２９人が、パトリック・シュミッツの配布リストの最低一件に載っている
文脈テンプレートベース
・ １２人が、パトリック・シュミッツと同じ情報カテゴリに関する専門知識を有する
・ １４人とパトリック・シュミッツは、同じ情報項目に関する新聞ダネになる人である
・ ２７人がパトリック・シュミッツと会話している

人物への情報
意味論的リンクベース
・ パトリック・シュミッツは、この情報項目を掲載した
・ スティーブ・ジュンキンスは、この情報項目を著作した
・ この情報項目は、二人にコピーされた
・ ３人がこの情報項目に注釈を付けた
文脈テンプレートベース（文脈テンプレートのナゲッツと類似）
・ この情報項目に関して４人の専門家が存在する
・ この情報項目に関して２７人の新聞ダネになる人が存在する

情報から情報へ
文脈テンプレートベース（文脈テンプレートのナゲッツと類似）
・ ５７８件の関連する「全ての可能性」が存在する
・ ２３５件の関連する「最も高い可能性」が存在する
・ ４件の関連するニュース速報項目が存在する
・ ４６件の関連する見出しが存在する
意味論的リンクベース（人々を経由）
・ これと同じ専門家を有する２１件の情報項目が存在する
・ これと同じ新聞ダネになる人を有する２３件の情報項目が存在する
・ これを掲載したのと同じ人物によって掲載された３４件の情報項目が存在する
・ これを著作した同じ人物によって著作された３４件の情報項目が存在する
・ これを注釈した人々によって注釈された４４件の情報項目が存在する

再帰ナゲッツ
再帰ナゲッツで、現在の情報ナゲッツのサブジェクトに関するディープインフォメーションを表示することで、文脈階層を形成する。システムは次に、サブジェクトのオブジェクトタイプを基に、ナゲッツを再帰的に表示する。再帰ナゲッツで、システムはソースオブジェクトから開始し、ネットワークパスに沿ってナゲッツを表示するまで、実質的に意味ネットワークを探査する。リソースの制限と一致する深度で、およびユーザフィードバックを基に、探査を停止することが好ましい。以下はその例である。

[+] パトリック・シュミッツがこの電子メールを著作した
[+] パトリック・シュミッツはノサ・オモイグイに直属する
[+] ノサ・オモイグイは６人の直属部下を有する
[+] スティーブ・ジュドキンス ...
[+] スティーブ・ジュドキンスは... を掲載した
[+] スティーブ・ジュドキンスは...に関する専門家である
[+] スティーブ・ジュドキンスは...の新聞ダネの人である
[+] スティーブ・ジュドキンスは、6件の会話に関わった。
[etc.]
[+] リチャード・ノボトニー...
[+] [残りの６人の直属部下]
[+] ノサ・オモイグイは１３件のオブジェクトに注釈を付けた...
[+] [１３件のオブジェクトに関するさらに多くの文脈テンプレートナゲッツ]
[+] ノサ・オモイグイは２７８件のオブジェクトを著作した
[+] ノサ・オモイグイは２３項目に注釈を付けた [...]
[+] パトリック・シュミッツは、５人の直属部下を有する
[+] ジョン・ドー ...
[+] 直属部下に関するさらに多くのネイティブナゲッツ
[+] パトリック・シュミッツは４７件のオブジェクトに注釈を付けた

Figure 2006522388


インフォメーションナーバスシステム用セキュリティの仕様

オモイグイ・ノサ

パート1. 権限

権限概要

はじめに

「人々」ＤＳＡは、ＬＤＡＰディレクトリＵＲＬおよびグループ名で初期化される。「ユーザ」ＤＳＡもまた、ＬＤＡＰディレクトリＵＲＬおよびグループ名で初期化される。一般的に、「ユーザ」は「人々」のサブセットである。例えば、医薬品会社は、異なる大型の医薬品カテゴリ（バイオテク、ライフサイエンス、薬理学など）用にＫＩＳをインストールする可能性がある。これらカテゴリのそれぞれは、そのカテゴリに関して知識があるか、関心のあるユーザグループを有する。ただし、ＫＩＳはまた、その会社の全社員をポピュレートした「人々」グループも有する。これはＫＩＳのユーザが、全社員の母集団のメンバーをＫＩＳのユーザでなくてもナビゲートすることができる。また推論エンジンは、必ずしもＫＩＳのユーザだけでなく、会社内の人々から意味論的リンクで専門知識を推論できる。
これはまた、ＫＩＳレベルのアクセス制御にも有益である。つまり、ウェブサービス層でアプリケーションサーバが提供するアクセス制御を相補または補足する。ユーザグループは、ＫＩＳ知識へのアクセスを有する人々を包括する。ただし人々のグループは、ＫＩＳへのアクセスを有しなくても、ＫＩＳ知識に関連のある人々を包括する。
人々とユーザＤＳＡの両方が、意味論的メタデータ格納（ＳＭＳ）内の人々のテーブルにポピュレートされ、適切にオブジェクトタイプＩＤを示す。ここで留意すべきは、パスワードはＳＭＳの人々のテーブルに格納されないほうが好ましいことである。
ユーザＤＳＡはまた、ユーザ認証テーブル（Ｕｓｅｒ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｔａｂｌｅ 、ＵＡＴ）にもポピュレートされる。これは、ユーザ名をパスワードにマッピングするメモリ内のハッシュテーブルである。サーバのウェブサービスは、ＩＰａｓｓｗｏｒｄＰｒｏｖｉｄｅｒインタフェースまたはその同等物を実装する。ＰａｓｓｗｏｒｄＰｒｏｖｉｄｅｒの実装で、特定のユーザ名にマッピングするパスワードを返す。以下のC#の例は、これを説明する。
namespace WSDK_Security
{
public class PasswordProvider : Microsoft.WSDK.Security.IpasswordProvider
{
public string GetPassword( string username )
{
return "opensezme";
}
}
次のC#コードは、ユーザが認証された後でウェブサービスがどのようにユーザ情報を取得するかを示す。
using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Web;
using System.Web.Services;
using Microsoft.WSDK.Security;
using Microsoft.WSDK;
namespace WSDK_Security
{
public class Service1 : System.Web.Services.WebService
{
[WebMethod]
public string PersonalHello()
{
string response = "";
SoapContext requestContext = HttpSoapContext.RequestContext;
if (requestContext == null)
{
throw new ApplicationException("Non-SOAP request.");
}
foreach (SecurityToken tok in requestContext.Security.Tokens)
{
if (tok is UsernameToken)
{
response += "Hello " + ((UsernameToken)tok).Username;
}
}
return response;
}
}
}
ナバナウェブサービスはその後、呼出しユーザネームでサーバ意味ランタイムを呼び出すことができる。ランタイムは次に、これをＳＱＬにマッピングし、意味論的クエリを発行するために適切なフィルタを使用する。
ナバナＡＳＰ．ＮＥＴアプリケーションに関しては、親構成コンポーネントの子として、以下のエントリがＷｅｂ．ｃｏｎｆｉｇファイルに追加される。
<microsoft.wsdk>
<security>
<passwordProvider
type="WSDK_Security.PasswordProvider, WSDK-Security" />
</security>
</microsoft.wsdk>

a. クライアント側の認証リクエスト
ＵｓｅｒｎａｍｅＴｏｋｅｎをリクエスト用に作成するため、ナバナクライアントは、ユーザネームとパスワードをＳＯＡＰリクエストの一部として渡す必要がある。ナバナクライアントは、複数のトークンをリクエストの一部として送ることができるが、これはユーザの識別情報が複数の認証プロバイダ全体で連合されている場合にこれは好ましい。ナバナクライアントは、ユーザが供給したすべてのユーザアカウント情報（ユーザネームおよびパスワード情報を含む）を収集し、これらをＷＳ−セキュリティトークンに変換し、次にＳＯＡＰリクエストを発行する。クライアントコードは、以下のように表示される（参照：http://www.msdn.microsoft.com）。

localhost.Service1 proxy = new localhost.Service1();
UsernameToken clearTextToken
= new UsernameToken("Joe",
"opensezme",
PasswordOption.SendHashed);
proxy.RequestSoapContext.Security.Tokens.Add(clearTextToken);
label1.Text = proxy.PersonalHello();

b. サーバ上でのＵｓｅｒｎａｍｅＴｏｋｅｎの検証
(http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnwssecur/html/wssecwithwsdk.asp)
ＷＳＤＫはセキュリティのヘッダ構文を検証し、パスワードハッシュをパスワードプロバイダからのパスワードと照らしてチェックするが、要請に基づいて行われることが望ましい追加的な検証がある。例えば、パスワード要素を包含しないＵｓｅｒｎａｍｅＴｏｋｅｎを受信した場合、ＷＳＤＫはパスワードプロバイダを呼び出さない。チェックするパスワードが存在しない場合、パスワードプロバイダを呼び出す理由はない。つまり、ＵｓｅｒｎａｍｅＴｏｋｅｎのフォーマットを自分たちで検証する必要があるということである。
もう１つの可能性として、リクエストに１つ以上のＵｓｅｒｎａｍｅＴｏｋｅｎ要素が含まれていることである。ＷＳ−セキュリティは、別々の目的に使える任意数のトークンをリクエストに含めるためのサポートを提供する。
ＵｓｅｒｎａｍｅＴｏｋｅｎにハッシュパスワードが含まれていることを検証し、単一のＵｓｅｒｎａｍｅＴｏｋｅｎを持つ着信リクエストのみを受け入れるように、ナバナウェブメソッド用に上記のコードを変更できる。変更したコードは次のとおりである。
[WebMethod]
public string ProcessSemanticQuery( string Query )
{
SoapContext requestContext = HttpSoapContext.RequestContext;
if (requestContext == null)
{
throw new ApplicationException("Non-SOAP request.");
}
if (requestContext.Security.Tokens.Count == 1)
{
foreach (SecurityToken tok in requestContext.Security.Tokens)
{
if (tok is UsernameToken)
{
UsernameToken UserToken = (UsernameToken)tok;
if (UserToken.PasswordOption
== PasswordOption.SendHashed)
{
return ProcessSemanticQueryInternal( Query, UserToken.Username );
}
else
{
throw new SoapException(
"Invalid UsernameToken password type.",
SoapException.ClientFaultCode);
}
}
else
{
throw new SoapException(
"UsernameToken security token required.",
SoapException.ClientFaultCode);
}
}
}
else
{
throw new SoapException(
"Request must have exactly one security token.",
SoapException.ClientFaultCode);
}
return null;
}

２．人々のグループ
ＫＩＳは人々のグループ用のメタデータを包含する。これらは現代のオペレーティングシステムのユーザグループのようである。人々のグループはナバナのファーストクラスのオブジェクトである（つまりオブジェクトクラスから受け継ぐ）。また、人々のグループのスキーマは次の通りである。

Figure 2006522388
大抵の場合、人々のグループはディレクトリシステムの （ＬＤＡＰのような） ユーザグループをマッピングする。例えば、ＫＩＳサーバの管理者は、ＫＩＳを設定可能なユーザグループの組をクロールさせる。ユーザグループをクロールし、人々のグループとＳＭＳのユーザテーブルをにポピュレートする人々ＤＳＡが存在する。人々ＤＳＡは次の行動を行う。
・ （ＳＭＳに存在しない場合）グループを作成する、あるいは（存在する場合は）グループのメタデータを更新する。
・ グループの全ユーザを列挙する（ソースにて、好ましい実施例ではＬＤＡＰディレクトリである）。
・ グループの全ユーザに対して、人々オブジェクトを作成する（またはオブジェクトがＳＭＳに既に存在する場合には、メタデータを更新する）。
・ （ＢＥＬＯＮＧＳ＿ＴＯ＿ＧＲＯＵＰ意味論的リンクタイプを使って）人々オブジェクトをグループオブジェクトにマッピングして、（ＳＭＳの「ＳｅｍａｎｔｉｃＬｉｎｋｓ」テーブル経由で）意味ネットワークを更新する。これによって、ＳＭＳはグループのメンバーシップ情報を取り込む意味論的リンクを（グループおよびユーザ自身に加えて）有することを確実にする。
３．識別情報のメタデータ連合
識別情報のメタデータ連合（Ｉｄｅｎｔｉｔｙ Ｍｅｔａｄａｔａ Ｆｅｄｅｒａｔｉｏｎ、ＩＭＦ）とは、情報コミュニティ（エージェンシー）がインターネット上に配置されるが、企業または個人顧客に情報を提供するのに使われる機能を指す。例えば、ロイターは専有コンテンツに依存する企業顧客すべて用の情報コミュニティを設定できる。複数の顧客が情報コミュニティを共有する様な場合（同業界で起こりやすい）には、ロイターは各顧客用に、ＳＭＳ上にグループを持つ。ただし、人々メタデータを使用可能にするには、各顧客は企業ディレクトリをロイターにミラー化させる必要がある。これは、特にセキュリティやプライバシーの観点において問題を生じる可能性がある。企業は、外部のコンテンツプロバイダが、自社社員のメタデータのアクセスを持つことを快く思わないであろう。ＩＭＦは、インターネットがホストする情報コミュニティ（エージェンシー）に、ユーザ認証に充分なメタデータのみをホストさせることで、この問題を解決する。例えば、ロイターは企業顧客のユーザ用ログオン情報のみをＳＭＳに格納する。意味論的ブラウザが、このような不完全なメタデータを含むＳＲＭＬを受信すると、クライアントはユーザの完全なメタデータをフェッチするため、もう１つのクエリを（ＬＤＡＰアクセス、またはエンタープライズディレクトリのメタデータがウェブサービス・ディレクトリ経由で提供される場合はＵＤＤＩ経由で）エンタープライズディレクトリに発行する。外部に格納されたメタデータは、残りのメタデータをフェッチできる識別情報を有するため、これが可能である。クライアントはエンタープライズのファイアウォール内の残りのメタデータをフェッチするため、企業の機密のメタデータは外界とは共有されない。
４．アクセス制御
a. アクセス制御ポリシー
好ましい実施例では、ＫＩＳはアクセス制御意味論を包括し強制実行する。ＫＩＳは「デフォルト設定アクセス」ポリシーを採用する。ここで言うデフォルト設定アクセスは、アクセスが拒否される場合を除いては、ＫＩＳは呼出しユーザに、ＳＭＳの任意メタデータへのアクセスを容認することを意味する。このように、システムは新しい形式のアクセスではなく、新しい形式の拒否が提供できるように拡張することができる。また、拒否する根拠が存在しない場合、ユーザはアクセスを容認されることを示唆する（これはより簡単で欠点のないアクセス制御モデルにつながる）。
ＫＩＳはアクセス制御マネージャ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｍａｎａｇｅｒ、ＡＣＭ）を有する。ＡＣＭは主に拒否意味論的クエリ（Ｄｅｎｉａｌ Ｓｅｍａｎｔｉｃ Ｑｕｅｒｙ、ＤＳＱ）生成の役割を担い、ＳＱＰはそれをクライアントからの任意の意味リクエスト用のクエリに加える。ＡＣＭは以下のメソッドを公開する（C#サンプル）。
String GetDenialSemanticQuery( String CallingUserName )
メソッドは呼出しユーザネームを取り入れ、例外オブジェクトをカプセル化するＳＱＬクエリ（またはその同等物）を返すことが好ましい。例外オブジェクトはＳＱＰによって呼出しユーザに返してはいけないオブジェクトである（つまり、ユーザがアクセスを持たないオブジェクトである）。
次にＳＱＰは、次のような拒否クエリを含む最終的な未加工クエリを構築する。
Aggregate Raw Query AND NOT IN (Denial Query)
例えば、統合未加工クエリが次の場合で：
SELECT OBJECTID FROM OBJECTS WHERE OBJECTTYPEID = 5,
拒否クエリが次のような場合：
SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME <>
'JOHNDOE',
最終的な未加工クエリ（つまりＳＱＰは呼出しユーザに返すために、最終的に実行しＳＲＭＬにシリアル化する）は次のようになる。
SELECT OBJECTID FROM OBJECTS WHERE OBJECTTYPEID = 5 AND NOT IN (SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME <>
'JOHNDOE')
意味論的に、これはおそらく次と同等である。
「５のオブジェクトタイプｉｄを有するが、ＪＯＨＮ ＤＯＥが所有しないオブジェクトリストに含まれない、全オブジェクトを選択する。」
これはたぶん意味論的に次と同等である。
「ＪＯＨＮ ＤＯＥが所有する、オブジェクトタイプＩＤが５である全オブジェクトを選択する。」
b. 一般的なアクセス制御規則
意味論的クエリプロセッサ（ＳＱＰ）が処理した各意味論的クエリには、アクセス制御チェックが含まれる。これによって、呼出しユーザはユーザがアクセスを持つメタデータのみを受信することを確実にする。ＳＱＰは、意味論的クエリを処理する際に、以下のアクセス制御規則を採用する。
1. 好ましくは、クエリが「人々」オブジェクトに対するものである場合（人々、ユーザ、顧客、専門家、新聞ダネになる人など）、戻ってくる「人々」オブジェクトは次のいずれかでなければならない。
・ 呼出しユーザを含む、あるいは
・ 呼出しユーザと最低１つの人々のグループを共有し、かつ呼出しユーザ、あるいはシステムによって所有される人々を包含する。
対応する拒否クエリは、次の規則をマッピングするのが好ましい。戻されたオブジェクトは、次の条件を満さなければならない。
・ 呼出しユーザではない +
・ 呼出しユーザまたはシステムによって所有されない ＋
・ 呼出しユーザと任意の人々のグループを共有しない人々を有する

拒否クエリＳＱＬ例
以下のＳＱＬは、アクセス制御ポリシーを強制実行するために、ＡＣＭが生成しＳＱＰが付け加えるアクセス制御拒否クエリを示す。この例では、呼出しユーザの名前は「JOHNDOE」である。
SELECT OBJECTID FROM OBJECTS WHERE
OWNERUSERNAME <> 'JOHNDOE' OR
OWNERUSERNAME <> 'SYSTEM' OR
WHERE OBJECTID NOT IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE') OR
WHERE OBJECTID NOT IN
(SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID = ''PERSON AND
PREDICATETYPEID='BELONGS_TO_GROUP' AND SUBJECTID IN (SELECT
SUBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN (SELECT OBJECTID
FROM PEOPLE WHERE NAME='JOHNDOE' ) )

2. 好ましくは、クエリが（文書、電子メール、イベントなど）人々のオブジェクト用でない場合、戻ってくるオブジェクトは次でなければならない。
・ 呼出しユーザまたはシステムユーザが所有し、かつ
・ 呼出しユーザがオブジェクトである意味論的リンクのサブジェクトである、あるいは
・ 呼出しユーザがサブジェクトである意味論的リンクのオブジェクトである、あるいは
・ オブジェクトが、最低１つの人々のグループを呼出しユーザと共有する人物である意味論的リンクのサブジェクトである、あるいは
・ サブジェクトが最低１つの人々のグループを呼出しユーザと共有する人物である、意味論的リンクのオブジェクトである
対応する拒否クエリは、次の規則をマッピングするのが好ましい。戻ってくるオブジェクトは次の条件を満たさなくてはならない。
・ 呼出しユーザが所有しない +
・ システムユーザが所有しない +
・ 呼出しユーザがオブジェクトである意味論的リンクのサブジェクトではない +
・ 呼出しユーザがサブジェクトである意味論的リンクのオブジェクトではない +
・ オブジェクトが、最低１つの人々のグループを呼出しユーザと共有する人物である意味論的リンクのサブジェクトではない +
・ サブジェクトが、最低１つの人々のグループを呼出しユーザと共有する人物である意味論的リンクのオブジェクトではない

拒否クエリＳＱＬサンプル
以下のＳＱＬは、アクセス制御ポリシーを強制実行するため、ＡＣＭが生成しＳＱＰが付け加えるアクセス制御拒否クエリを示す。この例では、呼出しユーザの名前は「JOHNDOE」である。
SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME <>
'JOHNDOE' OR
OWNERUSERNAME <> 'SYSTEM' OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID = ''PERSON' AND OBJECTID IN (SELECT OBJECTID FROM
PEOPLE WHERE NAME='JOHNDOE') OR
WHERE OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS
INNER JOIN PEOPLE WHERE SEMANTICLINKS.SUBJECTTYPEID='PERSON' AND SEMANTICLINKS.SUBJECTID = PEOPLE.OBJECTID) OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID='PERSON' AND PREDICATETYPEID='BELONGS_TO_GROUP' AND SUBJECTID IN (SELECT SUBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE')) OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID='PERSON' AND PREDICATETYPEID='BELONGS_TO_GROUP' AND OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE'))

統合拒否クエリＳＱＬの例
これら２つの規則を統合させることにより、ＡＣＭはアクセス拒否のため、次のような統合クエリをＳＱＰに返す。
SELECT OBJECTID FROM OBJECTS WHERE
OWNERUSERNAME <> 'JOHNDOE' OR
OWNERUSERNAME <> 'SYSTEM' OR
OBJECTID NOT IN (SELECT OBJECTID FROM PEOPLE WHERE
NAME='JOHNDOE') OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID = ''PERSON AND
PREDICATETYPEID='BELONGS_TO_GROUP' AND SUBJECTID IN (SELECT
SUBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN (SELECT OBJECTID
FROM PEOPLE WHERE NAME='JOHNDOE')) OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID = ''PERSON' AND OBJECTID IN (SELECT OBJECTID FROM PEOPLE
WHERE NAME='JOHNDOE') OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS INNER JOIN
PEOPLE ON SEMANTICLINKS.SUBJECTTYPEID='PERSON' AND
SEMANTICLINKS.SUBJECTID = PEOPLE.OBJECTID) OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID='PERSON' AND PREDICATETYPEID='BELONGS_TO_GROUP' AND SUBJECTID IN (SELECT SUBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN
(SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE')) OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE
OBJECTTYPEID='PERSON' AND PREDICATETYPEID='BELONGS_TO_GROUP' AND OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE'))

シナリオ例
例えば、１つのロイターのエージェンシー（ＫＩＳ）は、ロイターが情報を提供する各エンタープライズ顧客に対して、人々のグループを有する場合がある。エージェンシーは共通の情報ベース（ロイターのコンテンツ）を有するが、エンタープライズ顧客ごとに人々のグループを有する。これらのグループには、競争相手を含む場合もある。このような場合、知識フロー、生成および推論が、競争相手の境界を越えないことを確実にするのが好ましい。例えば、Ａ社の社員はＡ社の競争相手であるＢ社の社員から直接知識を得るべきでなく、（推論経由で）間接的に得るべきでもない。Ａ社の社員は、Ｂ社の社員が注釈を付けた項目への提言を得るべきではない。または、Ａ社の社員は、Ｂ社で働く専門家を検索できるべきではない。もちろんこの場合、Ａ社とＢ社は何らかの意味でパートナーではないと仮定する（もしそうであれば、知識の共有を希望する可能性がある）。知識パートナーの場合、ロイターはＡ社とＢ社の人々のグループを含む人々のグループを（おそらくＬＤＡＰ経由で）作成する。するとロイターＫＩＳは、Ａ社、Ｂ社、およびＡ＆Ｂ社の人々のグループを持つことになる。ＳＭＳはまた、Ａ社とＢ社の人々がこれらのグループに属することを示すメタデータ（「グループに所属」意味論的リンクタイプ経由で）を包含する。このプロセスを設定すると、前記の規則は、Ａ社とＢ社間で知識が共有されることを確実にする。
c. 注釈用のアクセス制御規則
注釈の場合、クエリを行うのとは対照的に、呼出しユーザは意味ネットワークを編集する。この場合、以下の規則が適用される。
１．好ましくは、注釈が付けられるオブジェクトが人物オブジェクトである場合、そのオブジェクトは次のいずれかでなければならない。
・ 呼出しユーザか
・ 最低１つの人々のグループを呼出しユーザと共有し、呼出しユーザまたはシステムが所有する人物
２．好ましくは、注釈が付けられるオブジェクトが人物でないオブジェクト（文書、電子メール、イベントなど）である場合、オブジェクトは次のいずれかでなければならない。
・ 呼出しユーザが所有する
・ システムが所有する
拒否クエリＳＱＬ例
以下のＳＱＬは、アクセス制御ポリシーを強制実行するため、（注釈用にアクセス制御チェックするために）ＡＣＭが生成しＳＱＰが付加するアクセス制御拒否クエリを示す。この例では、呼出しユーザの名前は「ＪＯＨＮＤＯＥ」である。
SELECT OBJECTID FROM OBJECTS WHERE
OWNERUSERNAME <> 'JOHNDOE' OR
OWNERUSERNAME <> 'SYSTEM' OR
OBJECTID NOT IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE') OR
OBJECTID NOT IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE OBJECTTYPEID='PERSON' AND PREDICATETYPEID='BELONGS_TO_GROUP' AND OBJECTID IN (SELECT OBJECTID FROM SEMANTICLINKS WHERE OBJECTID IN (SELECT OBJECTID FROM PEOPLE WHERE NAME='JOHNDOE'))
アクセス制御強制実行
ＡＣＭは、ＫＩＳ上の注釈およびその他書込み演算用のアクセス制御を強制実行する。ＫＩＳ ＸＭＬウェブサービスは、以下のように注釈メソッドを公表する（C#サンプル）。
AnnotateObject( String CallingUserName, String ObjectID );
このメソッドは、拒否クエリを得るためにACMを呼び出す。その後、次のような最終クエリを作成する。
Annotation Object Query AND NOT IN (Denial Query)
好ましい実施例では、注釈のオブジェクトクエリは、常に次のような形式である。
SELECT OBJECTID FROM OBJECTS WHERE OBJECTID=ObjectID,
ここでＯｂｊｅｃｔＩＤは、ＡｎｎｏｔａｔｅＯｂｊｅｃｔメソッドへの引数である。
ＡＣＭはその後、最終アクセス制御クエリＳＱＬを構築し、このＳＱＬを使ってアクセス制御をチェックする。ＡＣＭはそのＳＱＬを返す必要がないため、アクセス制御をチェックするために単に直接呼び出す。また、これは（アクセスか非アクセスかの）バイナリチェックのため、ＡＣＭは拒否クエリが最低一行返すかどうかをチェックするだけである。例えば、最終クエリは次のように表示される可能性がある。
SELECT OBJECTID FROM OBJECTS WHERE OBJECTID = ObjectID AND NOT IN (SELECT OBJECTID FROM OBJECTS WHERE OWNERUSERNAME <> 'JOHNDOE')
ＡＣＭは次に、（ＳＱＬクエリプロセッサ経由で）このクエリを実行し、結果セットにある行数を訊ねる。一行の場合、アクセスは許可されるが、それ以外ではアクセスは拒否される。このモデルは、拒否クエリモデルとの整合性を持たせるためこのように実装される（ＡＣＭは常に拒否クエリを構築し、これをすべてのアクセス制御チェックの基盤として使う）。

インフォメーションナーバスシステムの意味論的クエリ定義および視覚化の仕様

１．意味論的画像と動画

a. 概要
意味論的画像と動画は、ナバナの意味論的ユーザ経験という点では、好ましい実施例の有益なコンポーネントになり得る。つまり、本システムでのユーザ経験は、ナバナエージェンシー（情報コミュニティ）に格納されナバナＸＭＬウェブサービス経由でアクセスした意味論的画像／動画メタデータを有する実施例によって強化される。この実施例では、ナバナを経由して、エンドユーザは画像への文脈および時間に敏感な意味論的アクセスを有する。例えば、ゲティイメージス（またはコービス）のエージェントを電子メール上のスマートレンズとして使うと、呼び出されると、メッセージに意味論的に関連する画像を開く。あるいは、意味論的に関連する画像を表示するために、文書を自分のハードドライブからゲティエージェントへドラッグ＆ドロップすることを想像していただきたい。これで（画像スキーマと一致する）画像メタデータが持てる。ナバナのツールボックスは同じ状態であり、画像用の新しい情報オブジェクトタイプを追加したに過ぎない。また、異なるビュー、サムネール、スライドショー、フィルタリング、統合など、意味論的画像用の意味論的スキンも存在する。意味論的画像の例は、次で閲覧できる。
http://creative.gettyimages.com/source/search/resultsmain.asp?source=advSearch&hdnSync=Medicine%7E0%2C12%2C449%2C3%2C15%2C1%2C0%2C0%2C0%2C12287%2C0%2C7%2C14%2C6%2C3%2C3%2C0%2C12%2C449%2Cen%2Dus&UQR=tfxfwz
ごく一般的には、意味論的視覚化の特性は、いくつかの異なる変数によって変化する。システムの機能または特性が呼び出されている対象の文脈をふくむ文脈がその変数である場合が多くある。次のいくつかの項では、意味論的決定を左右する文脈変数の一部をリストする／または説明する。多くの場合、意味論的視覚化の変数または決定要因には重複または共通性が存在するが、場合によっては、考慮または考慮の組合せが具体的な状況にとって一意的である。
b. 業界固有の意味論的画像と動画
業界固有の意味論的画像／動画は、（業界にマッピングされる）１つ以上のカテゴリに対する意味論的結果の表示雰囲気の一部として使うことができる（そして好ましい実施例では使われている）。例えば、ｈｔｔｐ：／／ｗｗｗ．ｃｏｒｂｉｓ．ｃｏｍおよびｈｔｔｐ：／／ｗｗｗ．ｇｅｔｔｙｉｍａｇｅｓ．ｃｏｍを閲覧し、以下にリストされたするキーワードで検索をかける（統合では、業界標準分類法に基づき、目標業界にマッピングされる）。このような画像／動画は、文脈および（文脈テンプレートおよびカテゴリにマッピングされる）カテゴリスキン用の背景、フィルタ効果、変換および動画としても使える。また、これらの画像／動画は、優れたスクリーンセーバー用にこれらの画像の一部から抽出した動画パス用のビジュアルにも使える。例えば、これらの意味論的画像（「電力」業界用に電球の中で回転するメタデータなど）の１つから抽出した動画パスに沿って、その他の周辺画像や動画などのクロムと併せて、メタデータおよび視覚化を表示するスキンを想像していただきたい。業界固有の画像と動画を持つ他の業界として次が挙げられる。

Figure 2006522388

例えば、ユーザがバイオインフォマティックスまたは蛋白質工学に関する見出しというリクエスト／エージェントを開始する場合、意味論的ブラウザはＳＱＭＬからのバイオテク関連カテゴリをバイオテク業界の一組の画像にマッピングする。次に１つ以上の画像を、そのリクエスト／エージェントの結果用のスキンの一部として表示する（その結果、リクエスト／エージェントの視覚的な「雰囲気」を伝えると共に、心地よいユーザ経験となる）。
図１０１は医薬品／バイオテク業界用の意味論的画像の例である（コービスウェブサイトから許可を得たもので、左側には人間の顔に芸術的ＤＮＡへリックスが重ね合わせたもの、および右側には有機的化学チャートがある）。
同じことが情報タイプおよび文脈テンプレートに対しても適用される。スキンは文脈／情報タイプとカテゴリ／オントロジーに基づいて気の利いた（スマートな）ことを行い、これらの特性全体で意味論的画像／動画を知的方法で組み合わせる。例えば、「ワイヤレス技術に関する見出し」と題するエージェントは、「見出し」画像／動画と「ワイヤレス」画像／動画の間でトグルできる画像／動画ベースのアニメーションを見せる、クロム（および／またはスマート砂時計、以下を参照）を包含することができる。「ワイヤレスに関する見出しおよび半導体に関するニュース速報、および製品仕様に関連して私のグループの誰かが書いた電子メール」と題するブレンダーは、「見出し」、「ニュース」、「ワイヤレス」、「半導体」および「電子メール」用の画像／動画間で「トグルする」クロム（および／またはスマート砂時計）を包含することができる。
プレゼンターのクエリプロセッサは、全文脈テンプレートと情報タイプおよび（エージェント／ブレンダーＳＱＭＬからの）全カテゴリを列挙し、それに応じてクロムアニメーションを設定することができる。
情報タイプに関しては、（コービスやゲティなどで）次の検索を入力する。

Figure 2006522388
また、文脈テンプレートに関しては、次の検索を入力する。

Figure 2006522388
また、意味論的画像／動画は、全く無作為でないほうが好ましい。ただし、決まった組からでないほうが好ましい。注意深く選択したもので、スキンは選択した組から無作為に選択できるのが望ましい。しかし、例えばコービスまたはゲティイメージスなどの全体の組から無作為に選ばないほうが好ましい。そうしないと、くだらない画像、漫画および場合によっては攻撃的か不適切な画像がある可能性がある。また、これらのガイドラインの一部は、スキンの主題が微妙、適度、刺激的または超刺激的なモードのいずれかによって、変化するのが好ましい。微妙モードでは、スキンは視覚化ピボットごとに１つの画像／動画の選択を決定するかもしれない。その他のモードでは、これは退屈なユーザ経験になる可能性がある。
あまり派手でないモードでは、スキンは意味論的画像／動画を、パワーポイントのスライドデック背景（アルファ・ブレンドされたものなど）のようなクロムの一部として使うことができる。意味論的画像／動画はまた、（文脈バー、パネルまたはパレット上で）視覚化の一部として、およびスマート砂時計（以下を参照）でも使える。文脈および情報タイプの視覚化用に、意味論的画像／動画は、情報タイプまたは文脈を明確に示すよう慎重に選択することが望ましい。また、選択モードはスキン特性でも良い。
また、スキンごとに使える意味論的画像／動画の数は、画像／動画がどこに表示されるかによって、上限を定める必要が生じる場合がある。ただし、シナリオによっては、その必要はないかもしれない。例えば、ブレンダーのスキンは、ユーザがブレンダーの結果を（ページからページまたはエージェントからエージェントの）ナビゲートするに従い、ブレンダーから現在表示されているものとの一貫性を持たせるために、クロム背景間で循環させる可能性がある。これはまたスキン特性でも良い。
c. クライアント側の意味論的画像と動画のキャシュ
プレゼンターは、クライアントに（インストール時に）ダウンロードされ格納される意味論的画像と動画で、気の利いた（スマートな）拡張可能なクライアント側キャシュを有する。スキンは次に、この事前にキャシュされた画像と動画から選択できる。画像／動画は、ユーザのお気に入りのカテゴリと（その人物が選択する）関心のある分野に基づいて事前にキャシュでき、それは目標とする業界にマッピングされる。スキンは次に、（ナバナ、またはコービス、ゲティイメージスのようなサードパーティサーバが提供するサーバ側の画像／動画を公表するＸＭＬウェブサービスで）画像サーバへのオンデマンド画像クエリで、事前にキャシュした意味論的画像／動画を補完することができる。
プレゼンターはまた、気の利いた（スマートな）ことを行い、バイアス機能を使って、最近ダウンロードされた画像／動画が（タイブレーカーとして）それより古いものより先に選択される。「使用数」もまた各画像／動画と共にキャシュされ、プレゼンターは、どの画像／動画をいつ表示するかをフィルタする際にこの数を使う。このような「ロード平衡」は、より新鮮で繰り返しのないユーザ経験をもたらす。
キャシュは（ユーザの意味論的クエリに基づき）要求に応じてポピュレートされるのが好ましい。例えば、ボーイング社においてユーザのマシンに医療品画像／動画を事前にキャシュしても意味がない。キャシュサイズにも上限を決め、画像キャシュマネージャが「古い」および「未使用」画像を、ＬＲＵアルゴリズムまたはその同等物を使って消去することが好ましい。こうすれば、キャシュは、ユーザのエージェントの使用パターンおよびお気に入りのエージェントリストと「意味論的に同期」にできる。

２．スマート砂時計

「意味論的ユーザ経験」を提供するために、ナバナのプレゼンターが行う呼出しの過半数は、ＸＭＬウェブサービスへの遠隔呼出しであろう。このような場合、予測不可能で潜在的に無限の遅延がＵＩに発生する可能性がある。エンタープライズ内ではかなりの量の帯域幅およびサーバ馬力が期待できるものの、ナバナユーザインタフェースは、メソッド呼出しに未知数の待ち時間を「予定」しておかなくてはならない。
今日のオペレーティングシステムは、ディスクまたはネットワークへの無限のＩ／Ｏ呼出しに関連するこの問題を有する。一部のＣＰＵ集中演算も、かなりの遅延を有する。ＷｉｎｄｏｗｓおよびＭａｃのＵＩでユーザは、通常「砂時計」の形をした「待ち」カーソル経由で遅延を知覚させられる。
好ましい実施例では、プレゼンターは（ＳＱＭＬ「メソッド呼出し」への直接的なアクセス経由で）意味論的ヒントを得て、それによって「スマートまたは意味論的砂時計」の同等物を表示する。これが「ローディング中」またはその他の効果を表示する、中間ページの形式であり得る。追加としてプレゼンターは、クエリが代表するカテゴリおよび情報タイプまたは文脈テンプレートに関するヒントを得るため、ＳＱＭＬを読み込むことにより、クエリの意味論を伝えることができる。プレゼンターは次に、結果をまだ受信していなくても、これらのヒントを使ってクエリと一致する意味論的画像およびテキストを表示することができる。より多くのヒントをクエリが得るほど、砂時計はより賢く（スマートに）なる。ウェブサービスから実際の結果が到着し、（必要であれば）最終結果を発生させるためにプレゼンターにより統合される前であっても、「ローディング中」のページは次に、「次に来るもの」の雰囲気を伝えることができる。
「スマート砂時計」は、主な結果ペインだけでなく、スマートレンズの吹き出しポップアップウィンドウおよびインラインのプレビューウィンドウ（実質的には、ウェブサービスへのすべての呼出しサイトおよび「焦点」がある場所）にも表示できる。プレゼンターは、「砂時計」を表示する前にクエリをタイムアウトすることにより、気の利いた（スマートな）ことができる（たぶん数百ミリ秒後で、このための数字に到達するために、実装は有用性テストを行うべきである）。

３．視覚化 − 文脈テンプレート

概要
文脈テンプレートは、情報アクセスおよび取得のために特定の意味論的モデルにマッピングされるシナリオ主導型の情報クエリのテンプレートである。本質的に文脈テンプレートは、事前定義された意味テンプレートを用いて情報をユーザに伝達する、個人的で、デジタル意味論的な情報取得「経路」として考えることができる。文脈テンプレートは、１つ以上エージェンシー全体で情報を統合することが好ましい。
以下で説明する文脈テンプレートは、定義済みである。各種の意味論的情報の統合および流布向けの補足的な文脈テンプレートが予期される（その例には、感情（「怒り」、「悲しみ」などに関連する文脈テンプレート、場所、移動性、周囲の条件、ユーザタスクなどのための文脈テンプレートが含まれる）。
ニュース速報
ニュース速報の文脈テンプレートは、どのように意味論的情報を伝達するかという点で、ＣＮＮの「ブレイキングニュース」プログラム挿入部分の個人的なデジタル版に 類推によって説明することができる。文脈テンプレートでユーザは、情報作成または発行時間、および情報の重要性を定義する設定可能な時間数に従って並べ替えられた、非常にタイムクリティカルな情報に、１つ以上のエージェンシーからアクセスできる。
図１０２は、ニュース速報文脈テンプレート用の意味論的に適切な画像の視覚化を図示したものである。


Figure 2006522388
ニュース速報 − オブジェクトおよび文脈バーの視覚化の例
以下は、ニュース速報文脈に適切な視覚化の例または代表的要素のリストである。好ましい実施例の全ての視覚化（またはそのコンポーネント）と同様に、「雰囲気」または意味論的感覚または含意が、特定の文脈には適切である。大変大まかな類推をすると、１つの「舞台セット」が映画の脚本の特定の場面に適切でなければならないのと同様に、視覚化はアプリケーション内の文脈に適している。これはこの特定のオブジェクトや文脈バーの視覚化だけでなく、好ましい実施例の全ての視覚化にも当てはまる。
1. 来るべきニュース速報項目の合計数の背景の上に、最も最近または保留中のニュース速報項目の発行または予定時間を示す時を刻む時計
2. 意味論的画像の上に、最も最近または保留中のニュース速報項目の発行または予定時間を示す時を刻む時計
3. 意味論的画像とニュース速報項目の合計数の上に、最も最近または保留中のニュース速報項目の発行または予定時間を示す時を刻む時計
4. 無地の背景の上に、最も最近または保留中のニュース速報項目の発行または予定時間を示す時を刻む時計
5. 様々な背景の上に、全てのニュース速報項目の（順に）発行または予定時間を示す時を刻まない時計
6. 様々な背景の上に、最も最近または保留中のニュース速報項目の発行または予定時間を示すカレンダービュー
7. 様々な背景の上に、全てのニュース速報項目の（順に）発行または予定時間を示すカレンダービュー
8. 最も最近または保留中のニュース速報項目の発行または予定時間によって、フォントサイズを拡大／縮小
9. ニュース速報の項目数によって、フォントサイズを拡大／縮小
10. 最も最近または保留中のニュース速報項目の発行または予定時間によって、動画レートで描くフォント（光るテキスト、回転テキスト、動画パス上のテキストなど）
11. ニュース速報の項目数によって、動画レートで描くフォント（光るテキスト、回転テキスト、動画パス上のテキストなど）
12. 最も最近または保留中のニュース速報項目の発行または予定時間によって、変化するフォントの色
13. ニュース速報の項目数によって変化するフォントの色
14. ニュース速報の意味論的画像またはその同等物のアニメーショングラフィック
15. ニュース速報の項目数
16. 順に描かれるニュース速報項目のタイトル（リストビュー）
17. 順に描かれるニュース速報項目のタイトルと詳細（タイルビュー）
18. オブジェクトの周りの環状動画パス上で動く、意味論的画像／動画
19. 意味論的画像／動画背景上の項目数を示す吹き出しポップアップ
20. 無地な背景で意味論的画像／動画で描かれる項目数を示す吹き出しポップアップ

見出し
見出しの文脈テンプレートは、意味論的情報をどのように伝えるかという点で、ＣＮＮの「ヘッドラインニュース」プログラムの、個人的なデジタル版に類推によって説明することができる。文脈テンプレートでユーザは、情報作成または発行時間、および情報の「鮮度」を定義する設定可能な時間数に従って並べ替えられた情報見出しに、１つ以上のエージェンシーからアクセスできる。例えば、ＣＮＮの「見出しニュース」は、（２４時間体制で）３０分ごとに見出しを表示する。好ましい実施例では、見出しの文脈テンプレートは、以下のサブクエリが順につながれたサーバのＳＱＬクエリとして実行される：今日発行された提案、今日発行されたお気に入り、今日発行された最も高い可能性、今日と明日発生する来るべきイベント、今日発行される注釈の付いた項目。
全てのサブクエリが発行日／時間によって並べ替えられ、一緒に連結されるのが好ましい。追加フィルタは、ＳＱＭＬの述語リストに基づき、クエリに適用される。前記原則は図１０３に図示されるが、それらはスマート砂時計の画像例、割込みページ、転位効果、背景クロムなどの、見出しの視覚化である。

Figure 2006522388
会話の文脈テンプレート
会話の文脈テンプレートは、意味論的情報をいかに伝達するかという点で、ＣＮＮの「クロスファイア」プログラムの個人的なデジタル版に類推によって説明することができる。情報流布用の文脈として会話や議論を使う「クロスファイア」のように、好ましい実施例では、会話の文脈テンプレートは関連情報用の電子メール掲載、注釈およびスレッドを追跡する。
会話の文脈テンプレートは、次の情報オブジェクトタイプからなる。
1. 最低１つのスレッド深度の電子メール（電子メールメッセージへの電子メール返答）
2. 最低１つのスレッド深度の注釈（オブジェクトの一注釈の注釈）
3. インターネットのニュース掲載（ニュース掲載へのニュース掲載返答）
クエリはスレッド深度ごとに並べ替えられる。追加フィルタは、ＳＱＭＬの述語リストに基づきクエリに適用される。また、文脈スキンはスレッドごとに情報項目を表示する。
図１０４はスマート砂時計用の画像例、割込みページ、転位効果、背景クロムなどの視覚化である（机で仕事をしている二人）。

Figure 2006522388

会話文脈 − オブジェクトおよび文脈バーの視覚化の例
以下は、対応する表示された文脈（括弧内）に意味論的に適切な、視覚化要素を考察、または特徴のリストである。
1. 意味論的画像／動画のアニメーショングラフィック（アイコンと文脈ガイドビュー）
2. 無地の背景上の最大スレッド深度（アイコンおよび文脈ガイドビュー）
3. 意味論的画像／動画上の最大スレッド深度（アイコンおよび文脈ガイドビュー）
4. 順に描かれる会話のタイトル（リストビュー）
5. 順に描かれる会話のタイトルと詳細（タイルビュー）
6. 無地の背景上の会話数（アイコンおよび文脈ガイドビュー）
7. 意味論的画像／動画上の会話数（アイコンおよび文脈ガイドビュー）

新聞ダネの人の文脈テンプレート
新聞ダネの人の文脈テンプレートは、どのように意味論的情報を伝えるかという点において、ＮＢＣの「ミートザプレス」プログラムの個人的なデジタル版と類推によって説明することができる。この場合、ニュースそのものまたは会話ではなく、「ニュースでの人々」が重要視される。ユーザは、情報オブジェクトピボットとして返された人々を使い、ネットワークをナビゲートする。新聞ダネになる人の文脈テンプレートは、見出しの文脈テンプレートとして考えることができ、好ましくは、「人々」または「ユーザ」オブジェクトタイプのフィルタ、および「〜が著作」、「〜が著作した可能性がある」、「〜がホストした」、「〜が注釈を付けた」、「〜の専門家」などの述語で使うのが望ましい（人々を情報に関連付ける述語）。「〜に関連する」のデフォルトの述語は、全ての密接に結びついた特定の述語を包括するのに使うことが好ましい。（新聞ダネの人など）関連情報の並べ替え順は、「新聞を飾るニュース」（見出しなど）の順番によって並べ替えられる。
クエリは、見出しの数によって並べ替えられる。追加フィルタは、ＳＱＭＬの述語リストに基づきクエリに適用される。
図１０５は、スマート砂時計、割込みページ、転位効果、背景クロムなど用の意味論的「新聞ダネの人」の視覚化または画像例を図示する（フットボールの優勝戦）。

Figure 2006522388
新聞ダネの人 − オブジェクトおよび文脈バーの視覚化の例
1. 二人の頭が会話をしているアニメーショングラフィック（アイコンと文脈ガイドビュー）
2. 意味論的画像／動画のアニメーショングラフィック（アイコンと文脈ガイドビュー）
3. 新聞ダネの人の合計数（アイコンと文脈ガイドビュー）
4. 意味論的画像／動画上の新聞ダネの人の合計数（アイコンと文脈ガイドビュー）
5. 順に描かれる新聞ダネの人の名前（リストビュー）
6. 順に描かれる新聞ダネの人の名前と詳細（タイルビュー）

来るべきイベントの文脈テンプレート
来るべきイベントの文脈テンプレート（およびその結果的な特別エージェント）は、来るべきイベントに関する情報を伝える特別プログラムの、個人的なデジタル版に類推によって説明することができる。例には、「ワールドシリーズ」、「ＮＢＡ決勝戦」、「サッカーワールドカップの決勝戦」などの特別イベントが含まれる。知識労働者のシナリオでの同等物は、１つ以上のカテゴリ、文書またはその他の情報オブジェクトピボットに関連する、全ての来るべき業界イベントを監視したいユーザである。来るべきイベントの文脈テンプレートは、来るべきイベントのみがフィルタされ表示される（イベントと時間の重要性を暗示する、意味論的に適切な「文脈スキン」を使うことが好ましい）ことを除いては、見出しの文脈テンプレートと同一であることが好ましい。返されるオブジェクトは、最も間近に迫ったイベントを最初にリストして、タイムクリティカル性を基に並べ替えるのが望ましい。
図１０６は、スマート砂時計、割込みページ、転位効果、背景クロムの画像例など、意味論的「来るべきイベント」の視覚化を図示する（約束バインダー）。

Figure 2006522388
来るべきイベント − オブジェクトおよび文脈バーの視覚化の例
1. 来るべきイベントの合計数の背景上に、次のイベントまでの時間を示す時を刻む時計（アイコンおよび文脈ガイドビュー）
2. 意味論的画像／動画上に、次のイベントまでの時間を刻む時計（アイコンおよび文脈ガイドビュー）
3. 意味論的画像／動画と来るべきイベントの合計数の上に、次のイベントまでの時間を示す時を刻む時計（アイコンおよび文脈ガイドビュー）
4. 無地の背景の上に、次のイベントまでの時間を示す時を刻む時計（アイコンおよび文脈ガイドビュー）
5. 様々な背景上に、全ての来るべきイベント（順に）までの時間を示す、時を刻まない時計（アイコンおよび文脈ガイドビュー）
6. 様々な背景の上に、次の来るべきイベントの予定時間を示すカレンダービュー（アイコンおよび文脈ガイドビュー）
7. 様々な背景の上に、全ての来るべきイベント（順に）の予定時間を示すカレンダービュー（アイコンおよび文脈ガイドビュー）
8. カレンダー動画を示すアニメーショングラフィック（アイコンおよび文脈ガイドビュー）
9. 意味論的画像／動画のアニメーショングラフィック（スケジュールブックなど）（アイコンおよび文脈ガイドビュー）
10. 意味論的画像／動画上の来るべきイベントの合計数（アイコンおよび文脈ガイドビュー）
11. 無地の背景の上の来るべきイベントの合計数（アイコンおよび文脈ガイドビュー）
12. 順に描かれる来るべきイベントのタイトル（リストビュー）
13. 順に描かれる来るべきイベントのタイトルと詳細（タイルビュー）

発見
発見の文脈テンプレートは、「ディスカバリチャンネル」の個人的なデジタル版に類推によって説明することができる。この場合、特定のトピックに関する「ドキュメンタリ」に重要性が置かれる。発見の文脈テンプレートは、任意のカテゴリの一組に関連する情報オブジェクトを無作為に選択することで、情報の知的統合をシミュレートし、そして任意に前もって決められた設定可能な時間期間内に掲載される。時間ではなく意味論的重要性が、情報をどのように順番付けるかまたは提示するかを決定する好ましい考慮材料である。文脈テンプレートは、全ての情報タイプを分類述語用の意味論的リンク強度によってフィルタリングして実行できる。この場合、フィルタは、「最も高い可能性」フィルタより選択度が低くなければならない。文脈テンプレートは、フィルタリングに関しては「最も高い可能性」と「全ての可能性」の中間に位置する。
図１０７は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、「発見」の視覚化である（ペトリ皿）。

Figure 2006522388
発見 − オブジェクトおよび文脈バーの視覚化の例
1. 意味論的画像／動画のアニメーショングラフィック（テレスコープ、ボイジャー宇宙船、海に浮かぶ古い船など）（アイコンおよび文脈ガイドビュー）
2. 順次アニメーションでの最初のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションでの最初のＮ情報項目のタイトルおよび詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンおよび文脈ガイドビュー）
5. 合計項目数（アイコンおよび文脈ガイドビュー）

履歴
履歴の文脈テンプレートは、「ヒストリーチャンネル」の個人的なデジタル版に類推によって説明することができる。この場合、特定のトピックだけでなく、歴史的文脈での情報伝達に重要性が置かれる。このテンプレートに関しては、好ましい軸はカテゴリと時間である。履歴の文脈テンプレートは、発見の文脈テンプレートに類似し、さらに「最小年数制限」と呼応する。パラメータは、「最大年数制限」パラメータを「最小年数制限」パラメータ（またはオプションの「歴史時間期間」パラメータ）で置き換える以外は、発見の文脈プレートと同じであることが好ましい。また、返されるオブジェクトは、システムでの年数または作成からの年数を基に、逆または無作為順に並べ替えるのが望ましい。
図１０８は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的な「ヒストリー」の視覚化を図示する（戦争記念碑）。

Figure 2006522388
履歴 − オブジェクトおよび文脈バーアニメーションの視覚化の例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションでの最古の（または無作為）Ｎ情報項目のタイトル（リストビュー）
3. 順次アニメーションでの最古の（または無作為）Ｎ情報項目のタイトルおよび詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンおよび文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンおよび文脈ガイドビュー）

全項目
全項目の文脈テンプレートは、意味論またはキーワードかテキストベース検索のいずれかを基に関連する、全ての情報を返す文脈を表す。この場合、文脈にほんの少しでも関連する情報の流布に重要性が置かれる。全項目の文脈テンプレート用の主要軸は、関連性の単なる可能性であるあるものが好ましい。好ましい実施例では、全項目の文脈テンプレートは、関連性の可能性がある最も幅広い一組または結果領域を返すために、意味論的およびテキストベースクエリの両方を用いる。
図１０９は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的視覚化を図示する（宇宙）。

Figure 2006522388
全項目 − 視覚化およびオブジェクトと文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）

最も高い可能性
最も高い可能性の文脈テンプレート（およびその結果的な特別エージェント）は、関連性の高い情報のみを返す文脈を表す。好ましい実施例では、関連性が高く、意味論的に重要と見なされる情報伝達に重要性を置く。この文脈テンプレートに関しては、主要軸は関連性である。本質的には、最も高い可能性の文脈テンプレートは、テキストベースのクエリ結果の関連性を保証できないため、テキストベースのクエリは使用せず、意味論的クエリを採用する。最も高い可能性の文脈テンプレートは、カテゴリフィルタまたはキーワードで初期化するのが好ましい。キーワードが指定される場合、サーバは動的に分類を行う。結果は関連性評点、またはオブジェクトからカテゴリフィルタへの「カテゴリに属する」意味論的リンクの強度に基づき並べ替えるのが望ましい。
図１１０は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、「最も高い可能性」の視覚化を図示する（顕微鏡）。

Figure 2006522388
最も高い可能性の視覚化 − オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）

お気に入り
お気に入りの文脈テンプレート（およびその結果としての特別エージェント）は、「お気に入り」または「人気のある」情報を返す文脈を表す。この場合、他者から支持され、好ましく認められた情報流布に重要性が置かれる。好ましい実施例では、お気に入りの文脈テンプレートの軸には、読者層の関心度、オブジェクトが受ける「書評」およびオブジェクトに関する注釈スレッドの深度が含まれる。１つの実施例では、お気に入りの文脈テンプレートは、「お気に入り」意味論的リンクを有する情報のみを返し、同オブジェクトに対する（この意味論的リンクに基づく）「投票」数を数えて並べ替える。
図１１１は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的視覚化を図示する（コーヒーとペストリー）。

Figure 2006522388
お気に入りの視覚化 − オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）

名著
名著の文脈テンプレート（およびその結果としての特別エージェント）は、「名著」情報または、価値を認識された情報を返す文脈を表す。お気に入りの文脈テンプレートと同様に、他者から支持を得て、好ましく認識された情報流布に重要性が置かれる。この文脈テンプレートに関しては、好ましい軸には、歴史的文脈、読者層の関心度、オブジェクトが受けた「書評」およびオブジェクトに関する注釈スレッドの深度が含まれる。名著の文脈テンプレートは、実質的に「古いお気に入り」の文脈プレートとして機能する、追加の最小年数制限フィルタおよび投票評点の付いた、好ましい文脈プレートに基づき実行されるのが好ましい。
図１１２は、スマート砂時計、割込みページ、転位効果、背景クロムなどの「名著」に対する意味論的に適切な画像例を図示する（車）。

Figure 2006522388
名著の視覚化 − オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）

推奨
推奨の文脈テンプレートは、「推奨する」情報、またはエージェンシーがユーザが関心があると推測した情報を返す文脈を表す。「推奨」意味論的リンクを「ＳｅｍａｎｔｉｃＬｉｎｋｓ」テーブルに追加し、ユーザが示すお気に入りの意味論的リンクをマイニングして、推奨は挿入される。推奨は、機械学習および協調フィルタリングのような技法を使って行われるのが望ましい。この文脈テンプレートは、ユーザが関心を持つかもしれないが、ユーザがまだ見ていない可能性のある情報流布に重要性が置かれる。この文脈テンプレートに関しては、主要軸は関心の見込みおよび鮮度を含むのが好ましい。
図１１３は、スマート砂時計、割込みページ、転位効果、背景クロムなどの文脈／アプリケーション要素の画像例で、意味論的に適切な「推奨」の視覚化を図示する（親指を立てて賛同）。

Figure 2006522388
推奨の視覚化 − オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）

今日
今日の文脈テンプレートは、「今日」掲載した情報または（イベントの場合）開催する情報を表示する文脈を表す。この文脈テンプレートは、鮮度を決定するフィルタである「今日」に基づき、最新と見なされる情報流布に重要性が置かれる。
図１１４は、スマート砂時計、割込みページ、転位効果、背景クロムなどの要素の画像例で、意味論的「今日」の視覚化を図示する。

Figure 2006522388
「今日の視覚化」 − オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）

注釈付き項目
注釈付き項目の文脈テンプレートは、注釈の付いた情報を返す文脈を表す。この文脈テンプレートは、一人かそれ以上のユーザが項目に注釈を付けたという事実に基づき、重要である可能性のある情報流布に重要性が置かれる。
図１１５は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的な「注釈付き項目」の視覚化を図示する。

Figure 2006522388
「注釈付き項目」の視覚化 −オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）

注釈
注釈の文脈テンプレートは、注釈の付いた情報を返す文脈を表す。この文脈テンプレートは、注釈である情報流布に重要性が置かれる。
図１６は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的視覚化を図示する（掲示板にピンで留めたメモ）。

Figure 2006522388
「注釈」の視覚化 − オブジェクトと文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ情報項目のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ情報項目のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
5. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）

専門家
図１１７は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的「専門家」の視覚化を図示する（教授）。

Figure 2006522388
「専門家」の視覚化 − オブジェクトおよび文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ専門家のタイトル（リストビュー）
3. 順次アニメーションで最も最近のＮ専門家のタイトルと詳細（タイルビュー）
4. 意味論的画像／動画上の専門家の合計数（アイコンと文脈ガイドビュー）
5. 無地の背景上の専門家の合計数（アイコンと文脈ガイドビュー）

場所
図１１８は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的な「場所」の視覚化を図示する（パリ）。

Figure 2006522388
「場所」の視覚化 − オブジェクトと文脈バーのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 順次アニメーションで最も最近のＮ場所の名前（リストビュー）
3. 順次アニメーションで最も最近のＮ場所の名前と詳細（タイルビュー）
4. 意味論的画像／動画上の場所の合計数（アイコンと文脈ガイドビュー）
5. 無地の背景上の場所の合計数（アイコンと文脈ガイドビュー）

ブレンダー
図１１９は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的「ブレンダー」の視覚化を図示する。

Figure 2006522388
「ブレンダー」の視覚化 − アイコンのアニメーション例
1. 意味論的画像／動画またはその同等物のアニメーショングラフィック
2. 活動中のブレンダーまたはミキサーのアニメーショングラフィック
3. 順次アニメーションでのブレンダー項目のタイトル（リストビュー）
4. 順次アニメーションでのブレンダー項目のタイトルと詳細（タイルビュー）
5. 意味論的画像／動画上の合計項目数（アイコンと文脈ガイドビュー）
6. 無地の背景上の合計項目数（アイコンと文脈ガイドビュー）

情報オブジェクトのタイプ
図１２０から１３８までは、以下のそれぞれの情報オブジェクトのタイプの意味論的視覚化を図示する：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、 ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。

Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388


プレゼンテーションスキンのタイプ
時系列
図１３９は、スマート砂時計、割込みページ、転位効果、背景クロムなどの画像例で、意味論的「時系列」の視覚化を図示する。

Figure 2006522388
「時系列」の視覚化 − オブジェクトおよび文脈バーのアニメーション例
1. 様々な背景上の情報項目の効果的時間（発行時間、予定時間など）を示すカレンダービュー（アイコンと文脈ガイドビュー）
2. 様々な背景上の全ての情報項目（順次）の効果的時間を示すカレンダービュー（アイコンと文脈ガイドビュー）
3. カレンダー動画を示すアニメーショングラフィック（アイコンと文脈のガイドビュー）
4. 意味論的画像／動画のアニメーショングラフィック（時間歪曲画像／動画など）（アイコンと文脈ガイドビュー）
5. 意味論的画像／動画上の情報項目の合計数（アイコンと文脈ガイドビュー）
6. 無地の背景上の情報項目の合計数（アイコンと文脈ガイドビュー）
7. 順次描かれる情報項目のタイトル（リストビュー）
8. 順次描かれる情報項目のタイトルと詳細（タイルビュー）
9. 効果的な日付／時間に基づいてポピュレートされた項目でスクロール、直線時系列の制御
10. 効果的な日付／時間で並べ替えられた時系列チッカー制御のアニメーション

意味論的視覚化の威力
視覚化に関して最後に１つ述べるとすれば、好ましい実施例は、意味論的に情報を検索し、その検索した情報を意味論的に組織化して格納するだけでなく、意味論的に提示する。また、その提示は情報の順序、組織化および関係でのみ意味論的なのではなく、前述の視覚化がそうであるように、視覚的な伝達を意図する上である程度意味論的である。その結果、映画の視聴者が、照明、衣装、音楽や全体の舞台セットや背景の周辺状況により、対話の意味を理解する手助けを得るのとおおよそ同じように、ユーザは本システムが提示する情報を理解する上で支援を得る。つまり、好ましい実施例のシステムが提示または管理した、あるいは見つけ出したその他のすべてと同様に、視覚化は意義深い情報の伝達目的を達成する、または同じくらい適切に情報を意義深く伝達する。意味は好ましい実施例の統一主題であり、システムの設計と操作、およびシステムが構成されるそれぞれの構成要素に浸透している。
以上、本発明の好ましい実施例および他の代替実施例を示し説明したが、本発明の精神と範囲から外れることなく数多くの変更することができる。従って、本発明の範囲は好ましい実施例の開示に限定されるものではない。むしろ、本発明はこれに続く請求の範囲を参照することにより全てを判断されるべきである。


インフォメーションナーバスシステム用の意味論的クライアント側のランタイム制御ＡＰＩの仕様

１．ナバナ意味論的ランタイム制御の導入 − 概要

好ましい実施例では、ナバナの意味論的ランタイム制御は、ナバナの意味論的ユーザ経験を使って、意味論的データを表示するのに使用する特性およびメソッドを公開するアクティブＸ制御である。この制御は、ナバナ意味論的ユーザ経験の必要条件と一致するように、（ＳＲＭＬスキーマを使って）ＸＭＬデータを取り込み、ＤＨＴＭＬ＋ＴＩＭＥまたはＳＶＧアウトプットを生成するＸＳＬＴスキンから主に呼ばれる。原則的にこの実施例では、ナバナ制御は、意味論的なコンテンツ駆動のユーザ経験を生み出すためにＸＳＬＴスキンが位置する上部に「ＳＤＫ」をカプセル化する。以下に挙げるＡＰＩは、好ましい実施例において最終ＡＰＩによって公開されるか使用可能になる機能性を示す。

２．ナバナ意味論的ランタイム制御ＡＰＩ
a. EnumObjectsInNamespacePath
概要
EnumObjectsInNamespacePathメソッドは、ネームスペースパスのオブジェクトを返す。
使用のシナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、ユーザが意味論的ブラウザ内からネームスペースをナビゲートできるように、ネームスペースパスを開くためにこのメソッドを呼び出す。
PROTOTYPE
SCODE
EnumObjectsInNamespacePath(
[in] BSTR Path,
[in] LongQueryMask,
[out] BSTR *pQueryRequestGuid );

b. CompileSemanticQueryFromBuffer
概要
CompileSemanticQueryFromBufferメソッドは、ＳＱＭＬバッファを開いて、それを１つ以上の実行準備ができたＳＱＭＬバッファ内にコンパイルする。例えば、ブレンダーを含有するＳＱＭＬファイルは、各ブレンダーエントリを表わすＳＱＭＬバッファ内にコンパイルされる。ブレンダーにブレンダーが含まれる場合、それらのブレンダーはアンラップされ、ＳＱＭＬバッファがそれぞれの包含されたブレンダーに対して返される。コンパイル済みか「実施準備ができた」ＳＱＭＬバッファは、エージェンシーによって意味論的に処理できるものである。つまり、複数のエージェンシーからのエージェントを有するブレンダーは、ＳＱＭＬを各エージェンシーからの適切なＳＱＭＬで、バッファにコンパイルさせることを示唆する。
注意：バッファが既にコンパイルされている場合、メソッドはＳ＿ＦＡＬＳＥを返し、戻し引数は無視される。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、ＳＱＭＬバッファをコンパイルし、実行準備ができた生成済みの「コンパイル済みコード」を取得するため、このメソッドを呼び出す。典型的なシナリオでは、アプリケーションまたはスキンは、ＳＱＭＬバッファをコンパイルし、次にそれぞれ個別のＳＱＭＬクエリを位置させたいフレームウィンドウを準備する。次にOpenSemanticQueryFromBufferを呼び出して個別のＳＱＭＬ意味論的呼出しを発行し、その結果を個別のフレームに表示することができる。
PROTOTYPE
SCODE

CompileSemanticQueryFromBuffer(
[in] BSTR SQMLBuffer,
[in] DWORD Flags,
[out] DWORD *pdwNumCompiledBuffers,
[out] BSTR *pbstrCompiledBuffers );

c. OpenSemanticQueryFromBuffer
概要
OpenSemanticQueryFromBufferメソッドは、ＳＱＭＬバッファを開いて、非同期的に（ＳＲＭＬ内の）ＸＭＬの結果をＤＯＭの上で発生させ、そこからナバナスキンはイベントをシンクすることができる。ここで留意すべきは、この実施例では、ＳＱＭＬは「コンパイル」され、実行の準備ができていることである。ＳＱＭＬは実行の準備ができていない場合、呼出しは失敗する。ＳＱＭＬバッファをコンパイルするため、CompileSemanticQueryFromBufferを呼び出す。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、コンパイル済みＳＱＭＬバッファを開くためにこのメソッドを呼び出す。
PROTOTYPE
SCODE
OpenSemanticQueryFromBuffer(
[in] BSTR SQMLBuffer,
[in] DWORD Flags,
[out] GUID *pQueryID );

d. GetSemanticQueryBufferFromFile
概要
GetSemanticQueryBufferFromFileメソッドは、ＳＱＭＬファイルを開き、バッファのコンテンツを返す。バッファはその後コンパイルされる／または開かれる。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、処理前にＳＱＭＬファイルをバッファに変換するために、このメソッドを呼び出す。
PROTOTYPE
SCODE
GetSemanticQueryBufferFromFile (
[in] BSTR SQMLFilePath,
[in] DWORD FileOpenFlags,
[out] BSTR *pbstrSQMLBuffer );

e. GetSemanticQueryBufferFromNamespace
概要
GetSemanticQueryBufferFromNamespaceメソッドは、ネームスペースオブジェクトを開き、そのＳＱＭＬバッファを取得する。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、ネームスペースオブジェクトのｉｄおよびパスへのアクセスを既に有する際に、ＳＱＭＬバッファを開くため、このメソッドを呼び出す。
PROTOTYPE
SCODE
GetSemanticQueryBufferFromNamespace(
[in] GUID ObjectID,
[in] BSTR Path,
[out] BSTR *pbstrSQMLBuffer );

f. GetSemanticQueryBufferFromURL
概要
GetSemanticQueryBufferFromURLメソッドは、ＳＱＭＬバッファのＵＲＬをラップし、バッファを返す。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、任意タイプのＵＲＬをＳＱＭＬに変換するため、このメソッドを呼び出す。これにはファイルパス、ＨＴＴＰ ＵＲＬ、ＦＴＰ ＵＲＬ、ナバナエージェンシーのオブジェクトＵＲＬ （「wsobject://」が前置） またはナバナエージェンシーＵＲＬ（「wsagency://」が前置）が含まれる。
PROTOTYPE
SCODE
GetSemanticQueryBufferFromURL(
[in] BSTR URL,
[out] BSTR *pBuffer );

g. GetSemanticQueryBufferFromClipboard
概要
GetSemanticQueryBufferFromClipboardメソッドは、クリップボードのコンテンツをＳＱＭＬに変換し、バッファを返す。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、クリップボードから意味論的クエリを取得するため、このメソッドを呼び出す。アプリケーションはその後、クエリバッファをロードすることができる。
PROTOTYPE
SCODE GetSemanticQueryBufferFromClipboard( [out] BSTR *pBuffer );

h. Stop
概要
Stopメソッドは、現在開かれているリクエストを停止する。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、発行されたばかりのリクエストのロードを停止するため、このメソッドを呼び出す。
PROTOTYPE
SCODE Stop( [in] GUID QueryID );

i. Reflesh
概要
Reflesh メソッドで、現在開かれているリクエストをリフレッシュする。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、現在ロードされているリクエストを更新するため、このメソッドを呼び出す。
PROTOTYPE
SCODE Refresh( [in] GUID QueryID );

j. CreateNamespaceObject
概要
CreateNamespaceObjectメソッドは、ネームスペースオブジェクトを作成し、そのＧＵＩＤを返す。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは通常、新規クエリ文書が開かれたときに、一時的なネームスペースオブジェクトを作成するために、このメソッドを呼び出す。
PROTOTYPE
SCODE
CreateNamespaceObject(
[in] BSTR Name,
[in] BSTR Description,
[in] BSTR QueryBuffer,
[in] LONG AgentObjectType,
[in] LONG Attributes,
[in] LONG NamespaceObjectType,
[out] GUID *pObjectID );

k. DeleteNamespaceObject
概要
DeleteNamespaceObjectメソッドは、ネームスペースのオブジェクトを削除する。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは通常、一時的なネームスペースのオブジェクトを削除するため、このメソッドを呼び出す。
PROTOTYPE
SCODE DeleteNamespaceObject( [in] GUID ObjectID );

l. CopyObject
概要
CopyObjectメソッドは、専用のSQMLクリップボードのフォーマットを使って、意味論的オブジェクトをSQMLバッファとしてクリップボードにコピーする。オブジェクトはその後、関係意味論的クエリ用にエージェントに「ペースト」されるか、その他のオブジェクトまたはエージェント上のレンズとして使われる。
使用シナリオ
ナバナスキンは通常、ユーザがオブジェクトのポップアップメニューから「コピー」メニューオプションをクリックすると、CopyObjectを呼び出す。
PROTOTYPE
SCODE CopyObject( [in] BSTR ObjectSRML );

m. CanObjectBeAnnotated
概要
CanObjectBeAnnotatedメソッドは、任意のオブジェクトに注釈を付けられるかどうかをチェックする。
使用シナリオ
ナバナスキンは通常、「注釈を付ける」コマンドを示すUIを表示するかどうかを決定するため、CanObjectBeAnnotatedメソッドを呼び出す。
PROTOTYPE
SCODE CanObjectBeAnnotated( [in] BSTR bstrObjectSRML );

n. AnnotateObject
概要
AnnotateObjectメソッドは、オブジェクトの電子メール注釈をオブジェクトの出所のエージェンシーの電子メールエージェントへ送信するため、現在インストールされている電子メールのクライアントを呼び出し、それを初期化する。
使用シナリオ
ナバナスキンは通常、ユーザがオブジェクトのポップアップメニューから「注釈を付ける」メニューオプションをクリックすると、AnnotateObjectメソッドを呼び出す。
PROTOTYPE
SCODE AnnotateObject( [in] BSTR bstrObjectSRML );

o. CanObjectBePublished
概要
CanObjectBePublishedメソッドは、任意のオブジェクトが発行できるかどうかをチェックする。
使用シナリオ
ナバナスキンは通常、「発行する」コマンドを示すUIを表示するかどうか決定するために、CanObjectBePublishedメソッドを呼び出す。
PROTOTYPE
SCODE CanObjectBePublished ( [in] BSTR bstrObjectSRML );

p. PublishObject
概要
PublishObjectメソッドは、オブジェクトの電子メール発行物を、オブジェクトの出所のエージェンシーの電子メールエージェントに送信するために、現在インストールされている電子メールクライアントを呼び出し、それを初期化する。
使用シナリオ
ナバナスキンは通常、ユーザがオブジェクトのポップアップメニューから「発行する」メニューオプションをクリックすると、PublishObjectメソッドを呼び出す。
PROTOTYPE
SCODE AnnotateObject( [in] BSTR bstrObjectSRML );

q. OpenObjectContents
概要
OpenObjectContentsメソッドは、適切なビューアーを使ってオブジェクトを開く。例えば、電子メールオブジェクトは電子メールクライアントで開かれ、文書はブラウザで開かれる。
使用シナリオ
ナバナスキンは通常、ユーザがオブジェクトのポップアップメニューから「開く」のメニューオプションをクリックすると、OpenObjectContentsを呼び出す。
PROTOTYPE
SCODE OpenObjectContents ( [in] BSTR ObjectSRML );

r. SendEmailToPersonObject
概要
SendEmailToObjectメソッドは、電子メールを人物または顧客のオブジェクトに送信するために呼び出される。このメソッドは、その人物または顧客のオブジェクトの電子メールアドレスで、電子メールクライアントを開き初期化する。
使用シナリオ
ナバナスキンは一般に、ユーザが人物または顧客のオブジェクトのポップアップメニューから「電子メールを送信」メニューオプションをクリックすると、SendEmailToObjectメソッドを呼び出す。
PROTOTYPE
SCODE SendEmailToObject( [in] BSTR ObjectSRML );

s. GetObjectAnnotations
概要
GetObjectAnnotationsメソッドは、オブジェクトの出所のエージェンシーに関する注釈を取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、オブジェクトが有する注釈のタイトルを表示したいときに、GetObjectAnnotationsメソッドを呼び出す。例えば、ポップアップメニューで、または注釈メタデータをウィンドウに表示したいときなどである。
PROTOTYPE
SCODE
GetObjectAnnotations(
[in] BSTR ObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );

t. IsObjectMarkedAsFavorite
概要
IsObjectMarkedAsFavoriteメソッドは、オブジェクトの出所のエージェンシーでお気に入りとしてマークされたかどうかをチェックするために呼び出される。
使用シナリオ
ナバナスキンは通常、「お気に入りとしてマークする」または「お気に入りとしてのマークを解除する」コマンドのどちらかのＵＩを表示するかを決定するために、IsObjectMarkedAs Favoriteメソッドを呼び出す。オブジェクトが（例えば、エージェンシーから出ていない場合）お気に入りとしてマークできない場合、エラーコードE_INVALIDARGを返す。
PROTOTYPE
SCODE
IsObjectMarkedAsFavorite( in) BSTR ObjectSRML );

u. MarkObjectAsFavorite
概要
MarkObjectAsFavoriteメソッドは、オブジェクトの出所のエージェンシーでお気に入りとしてマークするために呼び出される。
使用シナリオ
ナバナスキンは通常、ユーザが「お気に入りとしてマークする」コマンドをクリックすると、MarkObjectAsFavoriteメソッドを呼び出す。
PROTOTYPE
SCODE
MarkAsFavorite( in) BSTR ObjectSRML );

v. UnmarkObjectAsFavorte
概要
UnmarkObjectAsFavoriteメソッドは、出所のエージェンシーで、オブジェクトをお気に入りのマークを解除するために呼び出される。
使用シナリオ
ナバナスキンは通常、ユーザが「お気に入りのマークを解除する」をクリックすると、UnmarkObjectAsFavoriteメソッドを呼び出す。
PROTOTYPE
SCODE
UnmarkAsFavorite( in) BSTR ObjectSRML );

w. IsSmartAgentOnClipboard
概要
IsSmartAgentOnClipboardメソッドは、スマートエージェントがクリップボードにコピーされたかどうかをチェックするために呼び出される。
使用シナリオ
ナバナスキンは通常、「ペーストする」アイコンを表示するためにユーザインタフェースをトグルするか、「ペーストする」コマンドが呼び出したいときに、IsSmartAgentOnClipboardメソッドを呼び出す。
PROTOTYPE
SCODE
IsSmartAgentOnClipboard();

x. GetSmartLensQueryBuffer
概要
GetSmartLensQueryBufferメソッドは、スマートレンズのクエリバッファを取得するために呼び出される。これによってクリップボード上のスマートエージェントにあり、任意のオブジェクトに意味論的に関連するオブジェクトを表すクエリのSQMLを返す。
使用シナリオ
ナバナスキンは通常、ユーザがクリップボード上のスマートエージェントからスマートレンズを呼び出すために、「スマートレンズとしてペーストする」を押すと、GetSmartLensQueryBufferを呼び出す。
PROTOTYPE
SCODE
GetSmartLensQueryBuffer(
[in] BSTR ObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );

y. OpenObjectContents
概要
OpenObjectContentsメソッドは、適切なビューアーを使ってオブジェクトを開く。例えば、電子メールオブジェクトは電子メールクライアントで開き、文書はブラウザで開く。
使用シナリオ
ナバナスキンは通常、ユーザがオブジェクトのポップアップメニューから「開く」メニューオプションをクリックすると、OpenObjectContentsメソッドを呼び出す。
PROTOTYPE
SCODE OpenObjectContents( [in] BSTR ObjectSRML );
Part

３．電子メール制御のＡＰＩ
a. Email_GetFromLinkObjects
概要
Email_GetFromLinkObjectsメソッドは、電子メールオブジェクトの出所であるエージェンシーから、電子メールオブジェクトに関する「送信者」リンク用のメタデータを取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、電子メールオブジェクトから「送信者」リストにナビゲートするか、「送信者」リストの人物の名前でポップアップメニューを表示したいときに、Email_GetFromLnikObjectsを呼び出す。
PROTOTYPE
SCODE
Email_GetFromLinkObjects(
[in] BSTR EmailObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );

b. Email_GetToLinkObjects
概要
Email_GetFromLinkObjectsメソッドは、メタデータの出所のエージェンシーから電子メールオブジェクトに関する「宛先」リンク用のメタデータを取得する際に呼び出される。
使用シナリオ
ナバナスキンは通常、電子メールオブジェクトから「宛先」リストにナビゲートするか、「宛先」リストの人物の名前でポップアップメニューを表示したいときに、Email_GetToLinkObjectsメソッドを呼び出す。
PROTOTYPE
SCODE
Email_GetToLinkObjects(
[in] BSTR EmailObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );

c. Email_GetCcLinkObjects
概要
Email_GetCcLinkObjectsメソッドは、メタデータ出所のエージェンシーから電子メールオブジェクトに関する「ＣＣ」リンク用メタデータを取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、電子メールオブジェクトから「ＣＣ」リストにナビゲートするか、「ＣＣ」リストの人物の名前でポップアップメニューを表示したいときに、Email_GetCcLinkObjectsメソッドを呼び出す。
PROTOTYPE
SCODE
Email_GetCcLinkObjects(
[in] BSTR EmailObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );

d. Email_GetBccLinkObjects
概要
Email_GetBccLinkObjectsメソッドは、メタデータの出所のエージェンシーから電子メールオブジェクトに関する「ＢＣＣ」リンク用メタデータを取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、電子メールオブジェクトからの「BCC」リストにナビゲートするか、「BCC」リストの人物の名前でポップアップメニューを表示したいときに、Email_GetBccLinkObjectsメソッドを呼び出す。
PROTOTYPE
SCODE
Email_GetBccLinkObjects(
[in] BSTR EmailObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );
e. Email_GetAttachmentLinkObjects
概要
Email_GetAttachmentLinkObjectsメソッドは、メタデータの出所のエージェンシーから電子メールオブジェクトに関する「添付書類」リンク用メタデータを取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、電子メールオブジェクトから「添付書類」リンクへナビゲートするか、「添付書類」リストの添付書類のタイトルでポップアップメニューを表示したいときに、Email_GetAttachmentLinkObjectsメソッドを呼び出す。
PROTOTYPE
SCODE
Email_GetAttachmentLinkObjects(
[in] BSTR EmailObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );

４．人物制御ＡＰＩ
a. Person_GetDirectReports
概要
Person_GetDirectReportsメソッドは、メタデータの出所のエージェンシーから人物オブジェクトに関する「直属の部下」リンク用メタデータを取得するため に呼び出される。
使用シナリオ
ナバナスキンは通常、人物オブジェクトから「直属の部下」リンクにナビゲートするか、「直属の部下」リストの直属の部下の名前でポップアップメニューを表示したいときに、Person_GetDirectReportsメソッドを呼び出す。
PROTOTYPE
SCODE
Person_GetDirectReports(
[in] BSTR EmailObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );

b. Person_GetDistributionLists
概要
Person_GetDistributionListsメソッドは、メタデータの出所のエージェンシーから人物オブジェクトに関する「配布リストのメンバー」リンク用メタデータを取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、人物オブジェクトから「配布リストのメンバー」リンクへナビゲートするか、人物が属する配布リストの名前でポップアップメニューを表示したいときに、Person_GetDistributionListsメソッドを呼び出す。
PROTOTYPE
SCODE
Person_GetDistributionLists(
[in] BSTR PersonObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );

c. Person_GetInfoAuthored
概要
Person_GetInfoAuthoredメソッドは、メタデータの出所のエージェンシーからの人物オブジェクトに関する「人物の著作情報」用メタデータを呼び出す。
使用シナリオ
ナバナスキンは通常、人物オブジェクトから「人物の著作情報」リンクへナビゲートするか、その人物が著作したタイムクリティカルまたは最近の情報の付いたプレビューウィンドウを表示するため、Person_GetInfoAuthoredメソッドを呼び出す。
PROTOTYPE
SCODE
Person_GetInfoAuthored(
[in] BSTR PersonObjectSRML,
[in] BOOL SemanticQuery,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );

d. Person_GetInfoAnnotated
概要
出所のエージェンシーから人物オブジェクトに関する「人物が注釈を付けた情報」リンク用メタデータを取得するため、Person_GetInfoAnnotatedメソッドが呼び出される。
使用シナリオ
ナバナスキンは通常、人物オブジェクトからの「人物が注釈を付けた情報」リンクへナビゲートしたいか、人物が注釈を付けたタイムクリティカルな情報、または最近の情報でプレビューウィンドウを表示したいときにPerson_GetInfoAnnotatedメソッドを呼び出す。
PROTOTYPE
SCODE
Person_GetInfoAnnotated(
[in] BSTR PersonObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );

e. Person_GetAnnotationsPosted
概要
Person_GetAnnotationsPostedメソッドは、メタデータの出所のエージェンシーからの人物オブジェクトに関する「人物が掲載した注釈」リンク用メタデータを取得するために呼び出される。
使用シナリオ
ナバナスキンは通常、人物オブジェクトから「人物が掲載した注釈」リンクにナビゲートするか、人物が掲載したタイムクリティカルな注釈、または最近の注釈でプレビューウィンドウを表示したいときに、Person_GetAnnotationsPostedメソッドを呼び出す。
PROTOTYPE
SCODE
Person_GetAnnotationsPosted(
[in] BSTR PersonObjectSRML,
[in] LONG QueryMask,
[out] BSTR *pQueryRequestGuid );

f. Person_SendEmailTo
概要
Person_SendEmailToメソッドは、電子メールを人物または顧客のオブジェクトに送信するために呼び出す。メソッドは、電子メールクライアントを開き、その人物または顧客のオブジェクトの電子メールアドレスで初期化する。
使用シナリオ
ナバナスキンは通常、ユーザが人物または顧客のオブジェクトのポップアップメニューから、「電子メールを送る」メニューオプションをクリックすると、Person_SendEmailToメソッドを呼び出す。
PROTOTYPE
SCODE Person_SendEmailTo( [in] BSTR ObjectSRML );

５．システム制御イベント
a. イベント: OnBeforeQuery
概要
OnBeforeQueryイベントは、制御がクエリを現在の意味論的リクエストと一致するリソースに発行する前に送出される。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、クエリが発行される前にクエリまたはキャシュ状態を取り消したい際に、このイベントをシンクする。
PROTOTYPE
VOID
OnBeforeQuery(
[in] GUID QueryID,
[in] BSTR QueryBuffer,
[in] DWORD QueryMask,
[in] DWORD Flags,
[out] BOOL *Cancel );

b. イベント: OnQueryBegin
概要
OnQueryBeginイベントは、制御が最初のクエリを現在の意味論的リクエストと一致するリソースに発行する際に送出される。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、クエリが進行中に状態をキャシュするか、状態情報を表示したいときにこのイベントをシンクする。
PROTOTYPE
VOID
OnQueryBegin( [in] GUID ObjectID );

c. イベント: OnQueryComplete
概要
OnQueryCompleteイベントは、制御がクエリを現在の意味リクエストと一致するリソースに発行する前に送出される。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、クエリが発行される前にクエリまたはキャシュ状態を取り消したいときに、このイベントをシンクする。
PROTOTYPE
VOID
OnQueryComplete( [in] GUID QueryID );

d. イベント: OnQueryResultsAvailable
概要
OnQueryResultsAvailableイベントは、非同期メソッド呼出しの使用可能な結果が存在するときに送出される。イベントはリクエストGUIDを示し、それを通して、呼び出した側は返答を生成した特定のメソッド呼出しを一意に識別できる。
使用シナリオ
ナバナクライアントアプリケーション（例えば、意味論的ブラウザ）またはナバナスキンは、制御のメソッド呼出しへの返答を得るために、このイベントをシンクする。
PROTOTYPE
VOID
OnQueryResultsAvailable(
[in] GUIDQueryID,
[in] SCODE QueryResult,
[in] BSTR Results,
[in] DWORD NumResults,
[in] DWORD QueryMask,
[in] VARIANT ResultsParam );

e. 付録 A
QUERY MASK VALUES
#define QM_RESULTS 0x01
#define QM_RESULTCOUNT 0x02
#define QM_NEWRESULTS 0x04
#define QM_NEWRESULTCOUNT 0x08
#define QM_DEFAULT ( QM_RESULTS )

例:
Person_GetInfoAuthored(
PersonObjectSRML,
QM_RESULTS | QM_RESULTCOUNT,
&QueryRequestGuid );

インフォメーションナーバスシステム用のスマートリクエスト警戒の仕様

1. 概要
スマートリクエスト警戒とは、意味論的ブラウザのユーザ（インフォメーションエージェントまたはライブラリアン）に、スマートリクエストを平行して監視（または「警戒」）させることができる機能を指す。これは、ユーザにいくつかのリクエストを同時に追跡させて生産性を高めることができる点で、大変有益な機能である。
この機能は、クライアント側の意義的ランタイム、意味論的ブラウザおよび（ＴＶセットの「ピクチャーインピクチャー」（ＰＩＰ）の機能性に似たメカニズムを通して）スマートリクエストを警戒する設定可能な方法を可能にするスキンで実装される。以下のソフトウェアのコンポーネントのうちの１つ以上が使われることが好ましい。
1. リクエスト警戒リスト（Ｒｅｑｕｅｓｔ Ｗａｔｃｈ Ｌｉｓｔ、ＲＷＬ）
2. リクエスト警戒グループ
3. 通知マネージャ（ＮＭ）
4. 警戒グループモニター（Ｗａｔｃｈ Ｇｒｏｕｐ Ｍｏｎｉｔｏｒｓ、ＷＬＭ）
5. 警戒ペイン
6. 警戒ウィンドウ

2. リクエスト警戒リスト（ＲＷＬ） およびリクエスト警戒グループ（ＲＷＧ）
リクエスト警戒リストは、クライアントのランタイムが管理するスマートリクエスト（またはスマートエージェント）の一覧である。このリストは実質的には、ユーザが監視したいスマートリクエストで構成される。リクエスト警戒リストは、エントリのリストからなり、次のデータ構造を持つリクエスト警戒リストエントリ（ Ｒｅｑｕｅｓｔ Ｗａｔｃｈ Ｌｉｓｔ Ｅｎｔｒｙ、 ＲＷＬＥ）である。

Figure 2006522388
リクエスト警戒リスト（ＲＷＬ）には、ＲＷＬＥ構造の配列またはベクトルが含まれる。リクエスト警戒リストマネージャで、ＲＷＬを管理する。意味論的ブラウザはユーザにスマートリクエストをＲＷＬに追加できるインタフェースを提供する。ＵＩはＲＷＬＭと対話し、ＲＷＬＥをＲＷＬに追加したりＲＷＬから削除したりする。ＲＷＬは、クライアント側の意味ランタイム（ＸＭＬファイルベースの表現かウィンドウズレジストリのような格納のどちらかとして）によって中央で格納（および存続）する。
ＲＷＬはまた、リクエスト警戒グループ（Ｒｅｑｕｅｓｔ Ｗａｔｃｈ Ｇｒｏｕｐｓ、ＲＷＧ）の手段によってポピュレートすることができる。リクエスト警戒グループは、ユーザにスマートリクエストの集合を監視する手段を提供する。また、設定可能な基準に基づいて意味論的ブラウザにＲＷＬを自動的にポピュレートさせる簡単な方法をユーザに提供する。自動リクエスト警戒グループと手動リクエスト警戒グループという、最低２つのタイプのＲＷＧが存在する。自動リクエスト警戒グループは、選択したプロフィール、現在表示されているリクエストのプロフィールなどによって、意味論的ブラウザによって動的にポピュレートされるグループである。手動リクエスト警戒グループでは、ユーザはスマートリクエストのグループ（通常のスマートリクエストまたはブレンダー）を集合として監視するため、手動でポピュレートができる。手動リクエスト警戒グループはまた、ユーザに（文書、カテゴリ、テキスト、キーワード、エンティティなど）サポート文脈のタイプを追加させることができる。この場合、システムは意味論的クエリ（ＳＱＭＬ）をフィルタから動的に生成し、結果として得られるクエリを手動リクエスト警戒グループに追加する。これは、フィルタを警戒グループに追加する前に、１つ以上のフィルタを基にまず時間に敏感なリクエストを作成させることでユーザの手間を省く。ユーザは単にフィルタに焦点を当て、システムが残りを行う。
ユーザは以下のタイプの自動ＲＷＧを追加できる（図１９のスマートリクエストダイアログボックスに示す「全てのプロフィール」を含む１つ以上の設定可能プロフィール用）。
1. ニュース速報 − 意味論的ブラウザに対し、ニュース速報のスマートリクエストを自動的にＲＷＬに追加するよう指示する（選択するプロフィール用）。
2. 見出し − 意味論的ブラウザに対し、見出しのスマートリクエストを自動的に（選択したプロフィール用に）ＲＷＬに追加するよう指示する。
3. 新聞ダネになる人 − 意味論的ブラウザに対し、新聞ダネになる人のスマートリクエストを自動的に（選択したプロフィール用に）ＲＷＬに追加するよう指示する。
4. 分類されたニュース速報 − 意味論的ブラウザに対し、分類されたニュース速報を自動的に（文脈プロフィール用に）ＲＷＬへ追加するよう指示する。意味論的ブラウザは、現在表示されているスマートリクエストにカテゴリが含まれている場合、現在表示されているスマートリクエスト（および文脈または現在のプロフィール用）の各サブカテゴリと一致するカテゴリフィルタで、スマートリクエストを動的に追加する。例えば、「技術に関するニュース速報」のスマートリクエストが現在意味論的ブラウザのインスタンスに表示される場合で、カテゴリ「技術」に（例えばワイヤレス、半導体、ナノテクノロジー、ソフトウェア、エレクトロニクスの）５つのサブカテゴリがある場合、以下のスマートリクエストが、現在のスマートリクエストがロードされる際に動的にＲＷＬに追加される。
・ 技術．ワイヤレス［＜文脈のプロフィール名＞］に関するニュース速報
・ 技術．半導体［＜文脈のプロフィール名＞］に関するニュース速報
・ 技術．ナノテクノロジーに関するニュース速報［＜文脈のプロフィール名＞］
・ 技術．ソフトウェア［＜文脈のプロフィール名＞］に関するニュース速報
・ 技術．エレクトロニクス［＜文脈のプロフィール名＞］に関するニュース速報
また、このようなエントリのＲＷＬＥは、現在の意味論的ブラウザインスタンスのリクエストビューインスタンスＩＤで初期化される。ユーザが新しいスマートリクエストにナビゲートする場合、以前にロードされたスマートリクエスト用に分類されたニュース速報はＲＷＬから削除され、分類されたニュース速報の新しいリストが新しいスマートリクエスト用に追加され（カテゴリを有する場合）、新しいスマートリクエストビューと一致する新しいリクエストビューインスタンスＩＤで初期化される。こうして、（サブカテゴリ用の）関連する分類済みニュース速報が、現在表示されるリクエストに基づいて動的に表示される、スマートユーザ経験を作成する。ユーザは次に、分類されたニュース速報のスマートリクエストを警戒グループまたは集合として監視できる。
5. 分類された見出し − これによって、自動的に分類された見出しスマートリクエストを（文脈プロフィール用に）ＲＷＬに追加するよう意味論的ブラウザに指示する。これは、見出しがこの場合に使われている以外は、分類されたニュース速報と似通っている。ユーザは次に、分類された見出しのスマートリクエストを警戒グループまたは集合として監視できる。
6. 分類された新聞ダネになる人 − これは、分類された新聞ダネになる人のスマートリクエストを（文脈プロフィール用に）ＲＷＬに自動的に追加するよう意味論的ブラウザに指示する。新聞ダネになる人がこの場合に使われている以外は、これは分類されたニュース速報と似通っている。ユーザは次に、分類された新聞ダネになる人のスマートリクエストを警戒グループまたは集合として監視できる。
7. 私のお気に入りのリクエスト − これは、全てのお気に入りのスマートリクエストを（選択したプロフィール用に）ＲＷＬに自動的に追加するよう意味論的ブラウザに指示する。こうしてユーザは全ての自分のお気に入りのスマートリクエストをグループとして警戒または監視できる。
8. 私のお気に入りのニュース速報 − これは、全てのお気に入りニュース速報のスマートリクエストを（選択したプロフィール用に）ＲＷＬに自動的に追加するよう、意味論的ブラウザに指示できる。これによってユーザは、すべての自分のお気に入りニュース速報のスマートリクエストを、グループとして警戒または監視できる。
9. 私のお気に入りの見出し − これは、全てのお気に入りの見出しのスマートリクエストを（選択したプロフィール用に）ＲＷＬに自動的に追加するよう、意味論的ブラウザに指示できる。こうして、ユーザは自分のお気に入りの見出しのスマートリクエストを、グループとして警戒または監視できる。
10. 私のお気に入りの新聞ダネになる人 − これは、全てのお気に入りの新聞ダネになる人のスマートリクエストを（選択したプロフィール用に）ＲＷＬに自動的に追加するよう、意味論的ブラウザに指示できる。こうしてユーザは自分のお気に入りの新聞ダネになる人のスマートリクエストを、グループとして警戒または監視できる。

リクエスト警戒グループマネージャのユーザインタフェース
図１９は、好ましい実施例の意味論的ブラウザの「スマートリクエスト警戒」ダイアログボックスを図示する。ダイアログボックスの上半分は、自動警戒グループを追加するのに使われる。ユーザは自動警戒グループタイプとプロフィールタイプ（「全てのプロフィール」、「文脈プロフィール」および実際のプロフィール名）を選択し、それらを自動警戒グループリストに追加する。ユーザはまた、自動警戒グループの削除もできる。ダイアログボックスの下半分は、スマートリクエストを手動警戒グループに追加したり、手動警戒グループから削除したりするのに使われる。

Figure 2006522388

3. 通知マネージャ（ＮＭ）
好ましい実施例では、通知マネージャ（ＮＭ）は、ＲＷＬのスマートリクエストを監視する意味ランタイムクライアントのコンポーネントである。ＮＭは（クライアントの意味論的クエリプロセッサ経由で）ＲＷＬの各スマートリクエストを定期的に呼び出すスレッドを持ち、「結果カウント」および「最終更新時間」でＲＷＬＥを更新する。好ましい実施例では、ＮＭは５−３０秒ごとにスマートリクエストを呼び出すのが好ましい。ＮＭは、（ウェブサービスでの帯域幅使用とスケーラビリティの影響を最小限に抑えるため）ＲＷＬのサイズによって、リクエストチェックの周期性または頻度を知的に調節できる。
（ニュース速報、見出しおよび新聞ダネになる人など）時間に敏感なスマートリクエストに関しては、ＮＭは追加の時間フィルタなしに、スマートリクエストを呼び出すのが好ましい。ただし、（文脈タイプではなく情報として、またはお気に入りや推奨のような時間に非敏感な文脈テンプレート用など）時間に非敏感なリクエストに関しては、ＮＭは（過去１０分間など）時間フィルタでスマートリクエスト用クエリを呼び出すことが好ましい。

4. 警戒グループのモニター
好ましい実施例では、意味論的ランタイムのクライアントは、本発明者が呼ぶところの警戒グループモニター（ Ｗａｔｃｈ Ｇｒｏｕｐ Ｍｏｎｉｔｏｒｓ、 ＷＧＭ）を管理する。ユーザが警戒グループリストに追加した各警戒グループに対し、クライアントは警戒グループモニターを作成する。警戒グループモニターは、警戒グループ内の各リクエストの新しいリクエストの数を追跡する。警戒グループモニターは、新しい結果を有する警戒グループのＲＷＬＥに待ち行列を作成する。ＷＧＭは、結果の新鮮さを最大限にするために待ち行列を管理する。ＷＧＭは、警戒グループの各リクエストに新しい結果が存在するかを調べるために定期的にＮＭをポーリングする。もし存在する場合、そのリクエストの「最終結果時間」によって、それを待ち行列に追加する。最も新鮮な結果を有するリクエストをまず優先するため、これを行う。プレゼンターで実行されている現在表示されている視的スタイル（スキン）は、次にＷＧＭの待ち行列内のリクエストを待機解除するため、意味ランタイムＯＣＸを呼び出す。こうすると、リクエスト警戒ユーザインタフェースは、新しい結果の存在と結果の鮮度とが一致する。現在表示中のリクエストに新しい結果がもはや存在しないと、スマートスタイルは次のリクエストをＷＧＭの待ち行列から待機解除する。

5. 警戒ペイン
警戒ペイン（Ｗａｔｃｈ Ｐａｎｅ、 ＷＰ）とは、（主な結果ペインの隣の）プレゼンターに表示されるパネルを指し、ユーザ警戒グループの視的表現を保持する。ＷＰはユーザに、リクエスト内に新しい結果があるかどうかが各警戒グループを一目みてわかるようにする。ＷＰはまた、各警戒グループのリアルタイムの状態の表示で現在のビューをユーザに変更させる。次のビューが現在定義されている。
・ タイルビュー − すべてのスマートリクエスト内の新しい結果の合計数で警戒グループのタイトルを表示する。
・ チッカービュー − すべての警戒グループのスマートリクエスト内の新しい結果の合計数を表示するが、（チッカーとして）各スマートリクエスト内の新しい結果数を連続的に表示するアニメーションを示す。
・ プレビューのビュー − チッカービューと似ているが、スマートリクエストごとの最も最近の結果も、チッカーの新しい結果数の横に表示される。
・ ディープビュー − このビューでは、ＷＰはすべての警戒グループのスマートリクエスト内の新しい結果の合計数を、各スマートリクエスト内の新しい結果の合計数を示すチッカーと、スマートリクエストごとの全ての新しい結果のスライドショーと共に表示する。

6. 警戒ウィンドウ
ＷＰはまた、ユーザに警戒グループを観察させることができる。ユーザは、ＷＰの警戒グループの１つを選び、それを主な結果のペインにドラッグ（またはそれと同様のテクニックで）して行う。これによって警戒ウィンドウ（Ｗａｔｃｈ Ｗｉｎｄｏｗ、ＷＷ）が形成される。このＷＷは、外観またはレイアウトの点でＴＶのピクチャーインピクチャーの機能に似ているが、いくつかの点で異なっている。その最も顕著なのは、ＴＶのチャンネルが「観られる」のに対し、この場合は、表示されるコンテンツは意味リクエストと結果で構成されていることである。もちろん、根本的なコンテンツ生成技術も異なる。ＷＷは前記ビューのどれにでも表示できる。ただし、ＷＷがディープビューの場合、ＷＷのビュー制御が表示される。以下の制御が現在定義されている。
・ リクエストのピン留め − ユーザに、警戒グループの特定のリクエストをピン留めさせることができる。ＷＷはピン留めされたリクエストのみ新しい結果が（周期的に）表示し続け、現在のリクエストがピン留めされている限り、警戒グループのその他のリクエストへ進まない。
・ リクエストの交換 − ユーザに、現在表示されているリクエストを意味論的ブラウザで示す主なリクエストと交換させることができる。スマートスタイルは、ＯＣＸ上のメソッドを呼び出し、（ＳＱＭＬバッファでハッシュした）交換したリクエストで一時的なリクエストを作成し、次にプレゼンターに主なリクエストを（ＷＷ内の）の場所に表示するよう連絡する一方で、その一時的なリクエストへとナビゲートする。
・ 停止、再生、シーク、ＦＦ、ＲＷ、加速化 − ユーザに「警戒グループのリクエストストリーム」を停止、再生、シーク、早送り、巻き戻しまたは加速化させることができる。例えば早送りは、現在表示されているリクエストよりいくつか先のリクエストに進む。
・ 結果の制御 − ユーザが、警戒グループの各リクエストの結果を制御することができる。実質的には、結果はストリーム内のストリームであり、これによってユーザは、現在の警戒グループの現在のリクエストの結果を制御することができる。
・ 自動表示モード − 表示する結果がない場合、自動的にＷＷを隠し、新しい結果があるときには、次第に明るくなる。こうして、ユーザは新しい意味論的結果が存在すると警戒ウィンドウが次第に明るくなることを知っているので、画面の占有面積を最大限に活用できる。この機能はまた、個人的および意義的な方法で情報の相互作用を行う間に、ユーザは各自の注意の対象を管理することができる。
・ ドッキング、閉じる、最小化、最大化− これらの機能は、その名前の通り、ユーザに警戒ウィンドウをドッキング、閉じる、最小化、最大化にさせることができる。図２０は、フィルタされたスマートリクエストを表示する観察ウィンドウを示す（ワイヤレスに関する見出しなど）。図２０は、フィルタリングされたスマートリクエスト（携帯での「見出し」など）を表示する警戒ウィンドウの図示である。図２０は現在のスマートリクエストのタイトル（「ニュース速報」など）で警戒ウィンドウを図示したものである。

7. 警戒リストの付録
ユーザインタフェースでは、警戒リストは「ニュースの見張り」と命名できる。ユーザは「ニュースの見張り」へ／からリクエスト、オブジェクト、キーワード、テキスト、エンティティなどを追加／削除するのかを問われる。「ニュースの見張り」は、ニューススタンドの警戒ペインで表示することができる。これはユーザのリクエストや（警戒リストに追加されたオブジェクトを経由して、そのオブジェクトをフィルタとして使い、ランタイムによって動的に作成された）動的に作成されたリクエストの空間指向のビューを提供する。ちょうど図書館や本屋に足を踏み入れたときのニュースや雑誌が並んだ棚と光景と同じである。

Figure 2006522388

インフォメーションナーバスシステム用のスマートスタイルの仕様

2. スマートスタイルの概要
スタイルのテーマに適用される色のテーマとアニメーションのテーマが、「スマートスタイル」を生みだす。この文脈での「スマート」とは、スタイルはリクエスト、文脈ペイン、プレビューモード、携帯モード、ライブモード、スライドショーモード、スクリーンセーバーモード、ブレンダー／集合モード、アクセスのしやすさ、ユーザ設定の認識、および（以下の）他のシステム内の可能な変数のムードに対して適応し反応することを意味する。可能なスタイルは無限で無数の種類または「クラス」がある。好ましい実施例は、少なくとも以下のスタイルクラスで構成される。
1. 微妙 − タスク指向の生産性用
2. 適度 − ある程度のプレゼンテーション効果でタスク指向の生産性用
3. 刺激的 − 刺激的効果（一次および二次の両方のマシン、不活発なナバナ・ウィンドウズに適している − 背景のナバナクライアントウィンドウまたはタスクバーに結合）
4. 超刺激的（生産性のあるスマートスクリーンセーバーに最適 − ユーザが自分の一次マシンを使用中の二次マシンなど）
5. ＳＦ （マトリックスファン用、生産性に特別必要性がないスマートスクリーンセーバーに最適 − ユーザが席を外しているときなど）

スタイル、色およびアニメーションのテーマ − 変数、無制限 − ナバナで作成、可能性としてはユーザおよび／またはサードパーティのスキン作成者

3. 潜在的で動的なスマートスタイル特性
ａ． ムード − スマートスタイルは、リクエストのムードを伝えなくてはならない（リクエストはスマートスタイルに渡されるパラメータである）。これにはスマートリクエストの意義的に伝えられる、または意義的に判断される（文脈テンプレートまたは情報タイプ、カテゴリ、フィルタが存在するかどうか（例えばローカル文書など）、そのフィルタの情報タイプなどの）特性を伝える意味論的画像、意味論的動画、視覚化などが関わる。
ｂ． 文脈ペイン − ディープインフォメーションのペイン（オブジェクトごと）、ドックすることが可能なプレビューペイン、ドックすることが可能な文脈ＰＩＰ警戒グループ／ペインなど。
ｃ． プレビューモード − 各スマートスタイルは、プレビューのために（小ウィンドウで）その結果を表示できなければならない。
ｄ． 携帯モード − 各スマートスタイルは、携帯デバイス用に結果を最適化して表示できなければならない。
ｅ． ライブモード − 各スマートスタイルは、（オブジェクトごとの）意味論的視覚化をリアルタイムで表示できる「ライブ」モードを有することが必要である。これは、（ユーザが意義的視覚化をリアルタイムで望まない場合、またはオブジェクトごとのリアルタイム・ウェブサービスコールの結果としての帯域幅を保存するためなど）トグルでオンかオフに切り替えられる。
ｆ． スライドショーモード − 各スマートスタイルは、好ましくはライブストリームのようにリクエスト結果を「再生」できなければならない。
ｇ． スクリーンセーバーモード −各スマートスタイルは、好ましくはリクエストの結果をスクリーンセーバーとして「再生」できなくてはならない。これは、フルスクリーン／シアターモード以外では、スライドショーモードの変形である。
ｈ． ブレンダー／集合モード − 各スマートスタイルは、好ましくは表示しているリクエストがブレンダー／集合である場合、ＵＩを適切に変更しなければならない。
ｉ． アクセスのしやすさ −各スマートスタイルは、好ましくはアクセスのしやすさをサポートしなくてはならない。
ｊ． ユーザ設定の認識 − ナバナライブラリアンは、ユーザに初心者、中級ユーザまたはパワーユーザのどれか、および各人のジョブ機能（Ｒ＆Ｄ、セールス、マーケティング、エグゼクティブなど）を示させることができる。各スマートスタイルは適宜これらの機能を考慮する（または影響を受ける）ことが好ましい。
・ 各スマートスタイルは、リクエストの意義と一致した、認識（または識別か感知）することを担当し、次に視覚化（またはユーザの注目に値する方法で提示、描写または図示する）を担うことが好ましい。
・ 現在のリクエストのムード（意義的画像、動画、クロムなど）
・ 現在のリクエストの項目数の変更
・ 各オブジェクトのムード（組み込み的）
・ 各オブジェクトの文脈のムード（見出し、ニュース速報、専門家など）
・ 程度問題、またはグラデーションか連続体の問題とは区別される（ニュース速報が存在するのか否か？何人の専門家がいるのか？見出しはいくつ？など）バイナリ／絶対値の問題または特徴
・ 特徴がグラデーションまたは連続体に関するものである場合、それに沿った相対的な配置の知覚（ニュース速報はどの位の速報なのか？見出しはどれほど重要なのか？専門家の専門知識レベルはどのくらい？など）
・ 各オブジェクトの文脈変更（新しいニュース速報がある、新しい注釈ある、など）
・ 表示される各オブジェクトの相対的重要性（異なるサイズのビューポート、異なるフォント、異なるクロムなど）
・ リクエストナビゲーションおよび「ローディング」の状態（ロード中の新しいリクエストのムードを導入する割り込み）
・ 任意の個別ＰＩＰウィンドウの全特性（アニメーション制御で描き出される）
・ 新しいＰＩＰウィンドウの追加（ＰＩＰウィンドウパレットへ）
・ ＰＩＰウィンドウのサイズ変更／移動／ドッキング
・ 任意のプレビューウィンドウ（文脈パレット、各オブジェクトの「視覚化ＵＩ」、時系列など）
・ 前記ムードおよび通知の視覚化のすべてと一致するサウンド（全体的）
図１８は、前記操作と機能の一部を図示する「スマートスタイル」のダイアログボックスのスクリーンショット例を示す。ここで示すとおり、ダイアログボックスでユーザは、スタイルクラス、スタイルテーマ、色テーマおよびアニメーションテーマ全体をピボットすることでスマートスタイルを参照することができる。プレビューウィンドウは、現在選択されているスマートスタイルのプレビューをユーザに示す。

Figure 2006522388



インフォメーションナーバスシステム用のクライアント側の意味論的クエリ文書仕様

１．意味論的クエリマークアップ言語（Ｓｅｍａｎｔｉｃ Ｑｕｅｒｙ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ、ＳＱＭＬ）の概要

本出願の好ましい実施例では、ナバナ意味論的ＤＨＴＭＬの動作は、インターネットエクスプロラＤＨＴＭＬの動作であり、クライアントからの観点では、すべてをクエリ文書として理解する。ワードプロセッサが「テキストおよび複合文書」を開くのと似通った方法で、クライアントは「クエリ文書」を開く。ナバナクライアントは、主にナバナ意味論的クエリ文書を処理し、結果を表示する役目を持つ。ナバナ意味論的クエリ文書は、ナバナ意味論的クエリマークアップ言語（ＳＱＭＬ）の形式で表現され保存される。これは、「意味ファイル形式」と類似している。
好ましい実施例では、ＳＱＭＬの意味ファイル形式は以下で構成される。
・ Head − ＨＴＭＬの場合のように、「ヘッド」タグには文書を説明するタグが含まれる。
・ Title − 文書のタイトル
・ Comments − 文書のコメント
・ UserName − 文書作者のユーザ名
・ SystemName − 文書が作成されるデバイスのシステム名
・ Subject − 文書の主題
・ Creator − 文書の作者
・ Company − 文書が作成された会社
・ RequestType − リクエストのタイプを示す。「smart request」（１つ以上の情報コミュニティウェブサービスへのリクエストを示す）または「dumb request」」（１つ以上のローカルかネットワークリソースへのリクエストを示す）があり得る。
・ ObjectType − クエリが返すオブジェクトのタイプを完全修飾する。
・ URI − 文書の場所
・ CreationTime − 文書の作成時間
・ LastModifiedTime − 文書が最後に変更された時間
・ LastAccessedTime − 文書が最後にアクセスされた時間
・ Attributes − 文書の属性（存在する場合）
・ RevisionNumber − 文書の改定番号
・ Language − 文書の言語
・ Version − クエリのバージョンを示す。ウェブサービスの意味論的クエリプロセッサに、バージョン化した結果を返すことができる。例えば、ブラウザの１つバージョンは、クエリのＶ１を使うことができ、別のバージョンはＶ２を使える。こうしてウェブサービスは、（エージェント用など）リソースレベルとリンクレベルの両方で、逆互換性を提供することができる。
・ Targets − クエリ文書が目標とする情報コミュニティウェブサービスの名前とＵＲＬを示す。
・ Type − ターゲットタイプを示す。これは、タグが実際のウェブサービスターゲットを示すサブタグを含む「targetentries」とクエリプロセッサがすべての登録情報コミュニティを使う「allsubscribedtargets」がある。
・ Categories − クエリ文書が参照する、カテゴリＵＲＬのリストを示す。各「category」エントリには、名前属性およびカテゴリの出所である知識ドメインサーバ（Ｋｎｏｗｌｅｄｇｅ Ｄｏｍａｉｎ Ｓｅｒｖｅｒ、ＫＤＳ）のＵＲＬを示すＵＲＩ属性が含まれる。
・ Type − カテゴリのタイプを示す。これは、サブタグがカテゴリエントリのリストを参照する「categoryentries」か、全カテゴリが情報コミュニティウェブサービスからリクエストされる「allcategories」か、クエリプロセッサがユーザのお気に入りカテゴリを得て、これらのカテゴリを含むコンパイルされたＳＱＭＬを生成する「myfavoritecategories」のいずれかである（コンパイルされたＳＱＭＬは次にサーバに送られる）。
・ Query − クエリ文書の全ての主なクエリエントリ用の親タグである。
・ Resource − クエリされる「ダム」リソースへの参照である。例としてはファイルパス、ＵＲＬ、キャシュエントリ識別子などが含まれる。これらは、解釈プログラムにより、実際のリソースマネージャコンポーネントにマッピングされる。
・ Type − ネームスペースで修飾されたリソース参照のタイプである。定義されたリソース参照のタイプの例として、nervana: url（これは、リソース参照が完全形成された標準インターネットＵＲＬであるか、「agent://...」のような特別仕様のナバナＵＲＬであるかを示す）、nervana:filepath（これは、リソース参照が、ファイルシステム上のファイルまたはディレクトリへのパスであることを示す）、nervana:namespaceref （これは、リソースがクライアントの意味ネームスペースから発していることを示す）がある。
・ Uri − リソースのユニバーサル リソース識別子を示す。パスとインターネットＵＲＬの場合、これはＵＲＬそのものを指す。ネームスペースのエントリの場合、これはエントリのＧＵＩＤ識別子を示す。
・ Mid − メタデータ識別子を示し、ＳＱＭＬ解釈プログラムにより、リソースを文書のメタデータ部分にマッピングするのに使われる。メタデータ識別子は、メタデータ部分内の同じ識別子にマッピングされる。
・ Args − リソース識別子の引数を示す。
・ Links − 意味論的リンクへの参照を示す（「ターゲット」用のみ）
・ Type − リンクのタイプを示す。リンクが明示的なエントリであることを示す「linkentries」であり得る。
・ LinkEntries − リンクエントリの詳細を示す。
・ Predicate − リンク用の述語タイプを示す。例えば「nervana:relevantto」は、クエリが「オブジェクトＯと関連するリソースＲからの全オブジェクトを返す」であることを示し、ここでＲとＯはそれぞれ指定されたリソースとオブジェクトである。そのほかの述語として、nervana:reportsto, nirvana:teammateof, nervana:from, nervana:to, nervana:cc, nervana:bcc, nervana:attachedto, nervana:sentby, nervana:sentto, nervana:postedon, nervana:containstextなどがある。
・ Type − 「リンク」タグで示すオブジェクト参照のタイプを示す。例としては、xml:string, xml:integerのような標準ＸＭＬデータタイプ、同等のナバナ版、nervana:datetimeref のような特別仕様のナバナのタイプ （これは「今日」や「明日」のようなオブジェクトの参照を参照する）、およびナバナが意味論的ＸＭＬオブジェクトとして処理できる１つのオブジェクトを参照する、任意の標準インターネットＵＲＬ （ＨＴＴＰ， ＦＴＰなど） またはナバナＵＲＬ （objects:// など） がある。
・ Metadata − メタデータエントリの参照を含む。
・ MetadataEntry − メタデータのエントリの参照を示す。
・ Mid − メタデータの識別子 （ＧＵＩＤ）を示す。
・ Value − メタデータそのものを示す。
例：文書（情報または文脈ベース）
<?xml version="1.0" encoding="utf-8"?>
<sqml>
<head
requesttype="smart request"
objecttype="context＼headlines"
uri="c:＼foo's＼bar.pdf"
creationtime="foo"
lastmodifiedtime="foo"
lastaccessedtime="foo"
attributes="0"
revisionnumber="0"
language="foo"
version="foo" />
<title>foo</title>
<comments>foo</comments>
<username>foo</username>
<systemname>foo</systemname>
<subject>foo</subject>
<creator>foo</creator>
<company>foo</company>
<targets>
<target
name="Marketing"
reftype="uri"
ref="kisp://marketing/default.wsdl"
/>
<target
name="Research"
reftype="uri"
ref="kisp://research/default.wsdl"
/>
</targets>
<categories>
<category
name="reuters＼pharmaceuticals＼biotechnology"
reftype="uri"
ref="kdsp://reuters.com/categories.wsdl?id=45"
/>
<category
name="reuters＼pharmaceuticals＼life_sciences"
reftype="uri"
ref="kdsp://reuters.com/categories.wsdl?id=57"
/>
</categories>
/>
<resources>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:filepath"
ref="file://c:＼bar.doc"
mid="7886e4a0-55d9-45ac-a084-97adc6fffd0f"
args=""
/>
<resource
name="foo"
type="information＼all information"
reftype="nervana:url"
ref="file://c:＼bar.doc"
mid="01fc64a3-c068-4339-bc97-17e5ff37e93f"
args=""
/>
<resource
name="foo"
type="information＼all information"
reftype="nervana:folderpath"
ref="file://c:＼"
mid="f8cc39c3-e4f0-4a29-be2a-d2faf36eb3a0"
args="includesubfolders=true"
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:url"
ref="http://www.bar.com/doc.htm"
mid="f8cc39c3-e4f0-4a29-be2a-d2faf36eb3a0"
args=""
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:url"
ref="ftp://gate.com/doc.txt"
mid="f8cc39c3-e4f0-4a29-be2a-d2faf36eb3a0"
args=""
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:filepath"
ref="file://＼＼servers＼server＼file.pdf"
mid="1b870a25-4e98-45d8-a444-f0283a495357"
args=""
/>
<resource
name="foo"
type="information＼documents＼text document"
reftype="nervana:text"
ref=""
mid="7886e4a0-55d9-45ac-a084-97adc6fffd0f"
args=""
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:cacheentry"
ref="ef9c90ea-282d-46d6-b355-ac8a4fc2f3e5"
mid=""
args=""
/>
<resource
name="foo"
type="information＼email＼email message"
reftype="nervana:url"
ref="request://email.all@ibm.com"
mid=""
args=""
/>
<resource
name="foo"
type="information＼email＼email annotation"
reftype="nervana:url"
ref="objects://rad.com/agency.asp"
mid=""
args=""
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:url"
ref="objects://rad.com/agency.asp"
mid=""
args=""
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:url"
ref="objects://rad.com/agency.asp"
mid=""
args=""
/>
<resource
name="foo"
type="information＼documents＼general document"
reftype="nervana:url"
ref="request://documents.all@intel.com"
mid=""
args=""
/>
</resources>
<links>
<link
operator="and"
predicate="nervana:relatedto"
name="foo"
type="information＼documents＼general document"
reftype="nervana:filepath"
ref="file://c:＼foo.doc"
mid="7886e4a0-55d9-45ac-a084-97adc6fffd0f"
args=""
/>
<link
operator="and"
predicate="nervana:contains"
name="foo"
type="information＼documents＼general document"
reftype="nervana:text"
ref=""
mid="46ea76cb-1383-4885-af6f-0e0fc6a66896"
args=""
/>
<link
operator="and"
predicate="nervana:postedon"
name="foo"
type="types＼datetime"
reftype="nervana:datetimeref"
ref=""
mid="3fa64c3c-4754-4380-91b5-521299036c62"
args=""
/>
<link
operator="and"
predicate="nervana:relatedto"
name="foo"
type="information＼documents＼general document"
reftype="nervana:url"
ref="kisp://98@in.com/m.asp"
mid="c2649c39-a1c3-4ca8-ae8d-c85c04372e9a"
args=""
/>
<link
operator="and"
predicate="nervana:isofpriority"
name="foo"
type="types＼priority"
reftype="nervana:priority"
ref=""
mid="69bbc048-98c8-4f76-8edf-5a00ce91c183"
args=""
/>
</links>
<metadata>
<metadataentry
mid="7886e4a0-55d9-45ac-a084-97adc6fffd0f"
reftype="uri"
ref="file://c:＼foo＼bar.pdf" />
<value>
<document>
<title>scenario modelling</title>
<type>text</type>
<format>application/pdf</format>
<filepath>c:＼foo＼bar.pdf</filepath>
<shortfilename>bar.pdf</shortfilename>
<creationtime>foo</creationtime>
<lastmodifiedtime>foo</lastmodifiedtime>
<lastaccessedtime>foo</lastaccessedtime>
<attributes>0</attributes>
<size>0</size>
<subject>foo</subject>
<creator>foo</creator>
<manager>foo</manager>
<company>foo</company>
<category>foo</category>
<keywords>foo</keywords>
<comments>foo</comments>
<hlinkbase>foo</hlinkbase>
<template>foo</template>
<lastsavedby>foo</lastsavedby>
<revisionnumber>0</revisionnumber>
<totaleditingtime>foo</totaleditingtime>
<numpages>0</numpages>
<numparagraphs>0</numparagraphs>
<numlines>0</numlines>
<numwords>0</numwords>
<numcharacters>0</numcharacters>

<numcharacterswithspaces>0</numcharacterswithspaces>
<numbytes>0</numbytes>
<language>foo</language>
<version>foo</version>
<abstract>foo</abstract>
</document>
</value>
/>
<metadataentry
mid="bfcb12b4-70bb-473a-847c-ebffe187828f"
reftype="uri"
ref="file://c:＼foo＼bar.pdf" />
<value>
<email>
<title>scenario modelling</title>
<type>text</type>
<format>application/pdf</format>
<filepath>c:＼foo＼bar.pdf</filepath>
<shortfilename>bar.pdf</shortfilename>
<creationtime>foo</creationtime>
<lastmodifiedtime>foo</lastmodifiedtime>
<lastaccessedtime>foo</lastaccessedtime>
<attributes>0</attributes>
<size>0</size>
<subject>foo</subject>
<creator>foo</creator>
<manager>foo</manager>
<company>foo</company>
<category>foo</category>
<keywords>foo</keywords>
<comments>foo</comments>
<hlinkbase>foo</hlinkbase>
<template>foo</template>
<lastsavedby>foo</lastsavedby>
<revisionnumber>0</revisionnumber>
<totaleditingtime>foo</totaleditingtime>
<numpages>0</numpages>
<numparagraphs>0</numparagraphs>
<numlines>0</numlines>
<numwords>0</numwords>
<numcharacters>0</numcharacters>

<numcharacterswithspaces>0</numcharacterswithspaces>
<numbytes>0</numbytes>
<language>foo</language>
<version>foo</version>
<abstract>foo</abstract>
</email>
</value>
/>
</metadata>
</sqml>

２．ＳＱＭＬの生成
次のようないくつかの方法のうち、１つ以上の方法でＳＱＭＬが生成されることが好ましい。
・ スマートリクエストを作成する
・ ローカルリクエストを作成する
・ エンティティを作成する
・ １つ以上のローカル文書を意味論的ブラウザに開く
・ クライアントによって（動的に）− ドラッグ＆ドロップ、スマートコピー＆ペースト、組み込み警告、文脈パネル／リンク呼出しなどに呼応して

３．ＳＱＭＬの構文解析
ある状況下の実施例によっては、クライアント上で作成されるＳＱＭＬは、サーバのＸＭＬウェブサービスによって、または別のマシンサイトで、（リアルタイムでの）遠隔利用を受け入れる準備ができていない可能性がある。ＳＱＭＬが文書、エンティティ、または（意味論環境で固有の識別子によって識別される）スマートリクエストのようなローカル文脈を参照する際には、特にこれが当てはまる傾向にある（ブレンダー（または集合）には、スマートリクエストへの参照が含まれる）。好ましい実施例では、クライアントは一般に遠隔利用を受け入れる準備ができているＳＱＭＬを作成する。文書のメタデータ部分における全ての参照に対して、メタデータをキャシュすることによってこれを行うことが好ましい。クエリが呼び出される際に、参照が示すリソースまたはオブジェクトがもはや存在しない場合があるためにこうすることが好ましい。例えば、ユーザは新しい関係リクエストを生成するために、インターネットからの文書をドラッグ＆ドロップするとする。クライアントはリンクから（要約を含む）メタデータを抽出し、メタデータをＳＱＭＬに挿入する。クエリの解決はメタデータのみを使うため、一旦メタデータがＳＱＭＬ文書に挿入されると、クエリは利用する準備ができる。ただし、オブジェクトが参照するリンクは、ユーザが発見した次の日には存在しないかもしれない。そのような場合、リンクが存在しなくなった後で、ユーザが関係リクエストを呼び出しても、メタデータはすでにＳＱＭＬにキャシュされているため、リクエストは依然として有効である。
クライアントのＳＱＭＬパーサは、ＳＱＭＬでメタデータの「遅延」更新を行う。リクエストが呼び出されると、オブジェクトは関係リクエストを作成するのに使われて以来、オブジェクトが変更された可能性がある場合に対処するために、全パラメータのメタデータ（リソースなど）をＳＱＭＬで更新しようとする。オブジェクトが存在しない場合、クライアントは既に存在するメタデータを使用する。さもなければ、クライアントはそのメタデータを更新し、更新されたメタデータを使用する。こうして、オブジェクトが削除された場合でも、ユーザが実際にメタデータの出所のオブジェクトを開こうと試みるまで、ユーザ経験は中断されない。

インフォメーションナーバスシステム用のエンティティ仕様
１．概要
エンティティは、インフォメーションナーバスシステムの好ましい実施例の大変強力な機能である。エンティティはユーザに、いかに標準基盤で動作するかをマッピングする文脈定義を作成させる。エンティティの例には次が含まれる。
Figure 2006522388
業界固有のエンティティも存在する。例えば、医薬品では、エンティティには薬品、薬物相互作用問題、特許、ＦＤＡ臨床検査などが含まれる。実質的には、エンティティはスマート文脈オブジェクトである意義的なエンベロープである。エンティティは他の任意のスマートオブジェクトのように、ドラッグ＆ドロップできる。ただし、エンティティはＳＱＭＬとして表されるが、ＳＲＭＬでは表されない（はるかに豊かな意義を持つため、クエリオブジェクトである）。エンティティは、スマートリクエストへのパラメータとして含むことができる。
ユーザは、自分のタスクに基づきエンティティを作成する。好ましい実施例のエンティティは、最低でも以下の情報を包括する（代替実施例では、それ以上それ以下の情報を包括できる）。
１．名前／説明 − エンティティの親しみやすく記述的な名前
２．エンティティのカテゴリ −産業間共通の標準分類法または縦型／会社固有の分類法
３．文脈リソース − キーワード、ローカル文書、インターネット文書または（人々などの）スマートオブジェクトが含まれる。
エンティティは意味論的ブラウザで開くことができ、ナビゲーションのピボットとして、（私のプロジェクトに関する見出しなど）スマートリクエストのパラメータとして使うことができ、ドラッグ＆ドロップ、コピー＆ペースができ、スマートレンズと一緒に使うことができ、スマートスタイルで視覚化でき、組み込み警告の基盤として使え、．ＥＮＴ文書として保存でき、電子メールで送信、共有などができる。つまりエンティティは、ファーストクラススマートオブジェクトである。
意味論的ランタイムのクライアントは、エンティティを参照する新しくて表現力豊かなＳＱＭＬを作成するため、エンティティの充実したメタデータを相関的なリクエストの主題に加えることにより、ＳＱＭＬを動的に作成する。
エンティティは、次のようなその他の強力な特徴を有することが望ましい。
１．トピックに関しては、エンティティはユーザに、自分の私的分類法を作成できる（厳格に定義された公共分類法に翻弄されたり制約を受けたりすることがないので、その結果、リクエストに対しユーザ固有の文脈の通りにマッピングされないかもしれない）。分類法の問題点は、全員のニーズを満たす分類法は存在しないということである。例え同じ組織内であってもである。文脈は大変個人的なもので、エンティティでユーザは個人的な分類法を作成することができる。例えば、スティーブが飼っているカシミールという名の犬（ボクサー犬）の例を取ってみる。（スティーブ以外の）他のみんなにとっては、カシミールは（分類的に）次のように表現される。
生き物
動物
哺乳類
犬
ボクサー
カシミール
しかしスティーブにとっては、カシミールはそれ以外に：
自分の愛する相手
自分のペット
カシミール
しかし、スティーブの獣医にとってカシミールは：
自分のクライアント
自分の犬
健康な自分の犬
カシミール
カシミールを「定義する」のに、（スタンドアロンで）分類法が使われるとすれば、３つの分類法のどれも一般大衆、スティーブ、スティーブの獣医を満足させることはできないであろう。一方エンティティでは、スティーブは「カシミールが自分にとって持つ意味」を基に、「カシミール」のエンティティを作成できる。他の皆も同じことができる。スティーブの獣医もそうである。従ってエンティティは、幅広い分類法の拡張の可能性のある私的トピックを作成させる能力を、ユーザに与える。
別の例では、大手薬品会社の医薬品研究者が、ゲノミクスに関する新しい極秘プロジェクト（「遺伝子プロジェクト」と命名）に取り組むとする。「遺伝子プロジェクト」は社内プロジェクトであるため、当発明者の発明の好ましい実施例の意味論的ブラウザで使える、公的分類法には存在しない可能性が高い。ただし、研究者は「遺伝子プロジェクト」と名づけたエンティティを作成し、プロジェクトとしてタイプし、それを（幅広い分類法で存在する）ゲノミクスに範囲を定めることでエンティティを初期化し、次に（ＡＮＤ演算子を使って）キーワードフレーズの「遺伝子プロジェクト」で修飾する。本質的には、「遺伝子プロジェクト」のフレーズを有するゲノミクス関連事項すべてとして「遺伝子プロジェクト」を定義することに似ている。これは単にキーワード「遺伝子プロジェクト」（単語「プロジェクト」を含む結果でゲノミクスとは何の関係もないを返す可能性がある）を使うよりもはるかに厳密な文脈を課す。ゲノミクスをスコープするが特定の修飾子で「遺伝子プロジェクト」にも拡張する個人的なトピックを定義することにより、研究者ははるかに厳密で個人的な文脈を有する。エンティティは次に（「遺伝子プロジェクトに関する専門家」などの）リクエストを作成するためにドラッグ＆ドロップ、コピー＆ペーストなどができる。ランタイムでは、サーバ側の意味論的クエリプロセッサは、これを（ＳＱＭＬを意味ネットワークにマッピングして）「カテゴリ、ゲノミクスに属するなんらかの情報に関する専門家ＡＮＤフレーズ「遺伝子プロジェクト」も包括する」として解釈する。
２．エンティティで、ユーザは動的分類法も作成できる − 公共分類法は大変静的であり定期的に更新されない。エンティティで、ユーザは自分の私的分類法を動的で考える速度で「拡張」できる。知識は思考速度で転送される。エンティティは、ユーザに自分の心や思考の流れと同じ速度および活力で文脈を作成させることができる。これは著しい飛躍である。例えば、ユーザは新しく計画されたミーティング、発見したばかりの会議、新規顧客、新しく発見した競争相手などのエンティティを、すべてを思考速度で作成できる。分類法ではこれは可能ではない。
３．分類法は、トピックが文脈の唯一のソースであると推定する。エンティティでは、ユーザは抽象的な文脈定義を作成でき、それにはトピックを含むがそれに限定されない。例として、人々、チーム、イベント、会社などが含まれる。エンティティは最終的に、分類法内でトピックに「進化」するかもしれないが（経時的、およびこれらのエンティティが「名声」または「悪評」を取り込むにつれ）、「短時間」では、エンティティはユーザにまだ本格的な分類法エントリに進化していない（または絶対に進化しない可能性もある）文脈を作成させることができる。例えば、ナバナ（我が社）は、当初は（当社とその少数の社員のみに知られた）エンティティであったが、成長し一般の関心を引くようになると、エンティティとして我が社は公共分類法のトピックに進化しつつある。エンティティだと、ユーザは（ナバナのような）文脈が「最終的に」トピックになるのを待つ必要がない。
４．エンティティはユーザに、発明者が呼ぶところの「複合文脈」を作成させることができる。この例はミーティングである。ミーティングは一般に、何人かの出席者と文書、プレゼンテーション用スライドおよび／または議題に関連する配布資料が関与する。インフォメーションナーバスシステムのエンティティを使えば、ユーザはミーティングの意義を捉えた「ミーティング」文脈を作成できる。エンティティ作成ウィザードを使って、ユーザはエンティティがミーティングであることを指定し、次に意味フィルタを指定することができる。５人の出席者と２種類の配布文書と一件のプレゼンテーションスライドのあるプロジェクトミーティングを例として考える。ミーティングのプレゼンターは、ミーティングに具体的に関連する知識を追跡するためのエンティティ作成を希望するかもしれない。例えば、フォローアップミーティングの予定をいつにするかを決める、またはミーティングに関連した特定の活動項目を追跡するため、プレゼンターはこれを行いたいかもしれない。エンティティを作成するため、ユーザは参加者の電子メールアドレス、配布文書およびプレゼンテーションをエンティティのフィルタ定義に追加する。ユーザは次にエンティティを保存すると、それは意味論的ネームスペース／環境を作成する。ユーザは例えば、ミーティングに関連したであろう新しい文書を発見した場合、次にエンティティを新規または削除されたフィルタで（および／または新規名称／説明）を後の日付／時間で編集できる。ユーザがエンティティをドラッグ＆ドロップするか、それをリクエスト／エージェントに包括する際に、意味論的ブラウザはそのエンティティをコンパイルし、同じく解釈用にＸＭＬウェブサービスに送られたサブクエリでそれをマスタＳＱＭＬに包含する。サーバ側の意味論的クエリプロセッサは次に、一連のＳＱＬサブクエリ（または同等のもの）を構築し、これらのクエリを、ＳＱＬサブクエリを使って次に生成されるエンティティのサブクエリと連結して、複合ＳＱＭＬを処理する。
ユーザはＡＮＤまたはＯＲ（またはその他）演算子を使って、エンティティフィルタの適用方法を示す。例えば、ユーザはミーティング（意義的に）とは、ミーティングの参加者および（ＡＮＤ）会議中に配布された文書／スライドであることを示すことができる。エントリがクライアントおよびサーバでコンパイルされると、ＳＱＭＬの同等物を使ってエンティティを（望む演算子で）解釈する。これは大変強力である。つまり、ユーザは「プロジェクトミーティング」と命名されたエンティティを定義でき、そのエンティティを「ニュース速報」と命名された特別エージェントにドラッグ＆ドロップできる。次に（エンティティの識別子を参照する適切なＳＱＭＬで）「プロジェクトミーティングに関するニュース速報」と命名されたリクエストを作成し、それが解釈のためにサーバに送られる前に、サブＳＱＭＬにコンパイルされる。サーバは次に（そのオブジェクトに対して「意味を成す」ことに基づいて）デフォルトの述語をエンティティ内のエントリに適用する。この例では、エンティティの定義のため、サーバは次のみを返す。
全ての（ＡＬＬ）参加者によるニュース速報であり（ＡＮＤ）、意味論的にも（ＡＬＳＯ）全ての（ＴＯ ＡＬＬ）文書／スライドに関連する
例えばこの場合、ミーティングの全参加者が関係しておりかつ会議中に配布される全資料に意味論的に関連する会話／スレッドだけを返す。これが（この場合）ちょうどユーザが望んだことで、意味論的ブラウザは本質的にかなり複雑なクエリを構築する力をユーザに与えたはずである。
それよりもっと複雑なクエリも可能である。エンティティは複合エンティティを可能にするため、その他のエンティティを包含することもできる。例えば、人々のチーム全体がミーティングに関わる場合、プレゼンターはこれらの人々の電子メール配布リストを含むエンティティを作成したいかもしれない。この場合、ユーザは配布リストを求めてインフォメーションナーバスシステムを検索し、結果をエンティティとして保存するかもしれない。ブラウザで、ユーザは結果をエンティティとして保存でき、結果のタイプを基に、「意味を成す」デフォルトのエンティティタイプでエンティティを自動的に作成する。例えば、ユーザが文書の結果をエンティティとして保存する場合、意味論的ブラウザは「トピック」エンティティを作成する。ユーザが人物結果をエンティティとして保存する場合、意味論的ブラウザは「人物」エンティティを作成する。ユーザが電子メール配布リストをエンティティとして保存する場合、意味論的ブラウザは「チーム」エンティティを作成する。
この例では、ユーザは人物結果を人物エンティティとして保存でき、次にそのエンティティをプロジェクトミーティングのエンティティにドラッグ＆ドロップする。ミーティング参加者の電子メール配布リストにマッピングするチームエンティティは、プロジェクトミーティングのエンティティにドラッグ＆ドロップすることができる。ユーザは次に、そのエンティティを含む「プロジェクトミーティングに関する見出し」と呼ばれるリクエストを作成できる。意味論的クエリプロセッサは次に、電子メール配布リストの任意の人物による（ＢＹ）見出しを（適切なデフォルトの述語を使って）返すが、それはミーティングの間に配布された全ての（ＡＬＬ）配布資料に意味論的に関連する。同様に、プロジェクトミーティングに関するドシェ（ガイド）は、ミーティングに関する全ての可能性、ミーティングに関する最も高い可能性、ミーティングに関する専門家などを返す。
ここで留意すべきは、その他のエンティティを含むそのような複合エンティティは、参照整合性がクライアント側の意味整合性チェッカーでチェックされることである。つまり、エンティティＡがエンティティＢを参照し、ユーザがエンティティＢの削除を試みると、意味論的ブラウザはこれを検出し、エンティティＢに未処理の参照があることをフラグする。それでもユーザがエンティティＢを削除する場合、エンティティＡ内の参照（およびエンティティＢへのその他参照）は削除される。代わりに一部の実施例では、エンティティに関連する組織内のその他の許可に基づき、ユーザが同じ状況でエンティティＢを削除するのを（通知されていたか否かに関わらず）禁止される場合がある。例えば雇用主は、一部の会社では電子メールで行うように、ただしもっと潜在的で効果的に、危機管理のために社員の活動を監視する場合がある（もちろん、適切な方針やプライバシーを考慮に入れなくてはならない）。同じ過程がリクエスト集合（ブレンダー）、ポートフォリオ（エンティティ集合−以下を参照）および意味ネームスペース／環境の（ネームスペース／環境でその他の項目を参照する）その他の複合項目にも適用される。
５．人気のあるエンティティも、知識コミュニティのメンバー間で共有できる。（リクエストまたは知識コミュニティ（エージェンシー）のように）意味論的ブラウザのほかの項目のように、エンティティはファイルとして保存できる（のでユーザがあとで開いたり、同僚に電子メールで送信したり、中央ファイル共有などで保存できる）。よくあるシナリオとしては、事業での企業ライブラリアンが、社内プロジェクト、ミーティング、セミナー、タスクおよびその他の関心のある重要な企業知識項目にマッピングするエンティティを作成する。これらのエンティティは次に、ファイル共有または（ポータルまたはウェブサイトなど）その他の共有メカニズムまたは知識コミュニティ（エージェンシー）に保存される。そうすると組織内の知識労働者がエンティティを使うことができる。エンティティが更新されるに従い、好ましい実施例では、ライブラリアンは自動的に自分の文脈を編集でき、また編集して、ユーザは更新または新しいエンティティに同期化することができる。エンティティはまた、個別のユーザによってピア・ツー・ピアベースで交代で共有できる。これは、音楽を共有する合法的なピア・ツー・ピアのファイル共有に似ているが、音楽の代わりに、共有するのは意味、あるいはもっと意義あるコミュニケーションを円滑にするための文脈である。

２．ポートフォリオ（またはエンティティ集合）
ポートフォリオはエンティティの集合を含む、特別なタイプのエンティティである。エンティティは任意のサイズまたは構成が可能で、ポートフォリオは任意の種類または数のエンティティを含むことが可能であるが、好ましい実施例では、（少なくとも命名法または用語の）複雑性や混乱を最小限に押さえるため、ポートフォリオはその他のポートフォリオを包含しない。ポートフォリオはユーザに、ファーストクラスのエンティティを一単位として管理させることができる。ポートフォリオはファーストクラスのエンティティであり、従って前記のエンティティとしての機能全てを備えている。ポートフォリオがスマートリクエストでパラメータとして使われる場合は、ＯＲ修飾子がその包括されるエンティティに（デフォルト設定で）適用される。つまり、もしポートフォリオＰがエンティティＥ１とＥ２を包含する場合、「Ｐに関する見出し」と題されたスマートリクエストは、「Ｅ１またはＥ２に関する見出し」として処理される。ユーザはこの設定を個別のスマートリクエストに対して（ＡＮＤ修飾子に）変更できる。

３．シナリオの例
再度以下のシナリオを検討して行く上で、本システムは、１つには誰が情報を求めているかを「知って」おり、その人物またはグループが誰であるか、およびどのような情報に関心がありそうかを「理解している」ために、概念的により関連した情報を収集できるということを再確認することが役に立つ。もちろん厳密に言えば、本システムは完全な人間の意味では認識または自己認識を持たないし前文で使われた操作を表す動詞は、概念的な暗喩または直喩である。しかしながら、操作と結果において、１つには、本システムの根底にある意味論的情報を与えられたアーキテクチャと実行のため、理解と知識を前例にない度合いまで模倣する。
この点は、単純な対照によって説明できる。二人のまったく別な人間が、Ｇｏｏｇｌｅのような検索エンジンに全く同じ検索を同時に行った場合、全く同じ結果を得る。それと対照的に、本出願のシステムの好ましい実施例では、この二人の人物がエンティティ経由で同じリクエストを行った場合、それぞれに合わせた関連のある別の結果が得られる。
この機能のいくつかの潜在能力を正当に評価するには、システムまたはエンティティは、誰がクエリを投稿しているのかを「知っている」一方で、エンティティは情報に通じており常に更新および情報を持っていることを、（ユーザ情報はいつでも供給および考慮の対象になるが）ユーザに関するその知識に依存していないことに注目すべきである。。もしユーザに依存するならば、システムは多くの状況で効率的かつ有益な結果を得るには、あまりにも大きな労働力を必要するので、労力がかかり過ぎる。その代わりに、エンティティは、本出願や親出願を通して説明するように、誰が要求しているのかを、推論と時には他から提供された特徴から、またあるときは派生または演繹、時には他からのリクエストや同類物によって収集した特性からの意義によって、「知っている」のである。
操作中のエンティティのシナリオ例は次の通りである。
1. 医薬品「特許」エンティティは、特許のカテゴリ、関連キーワードおよび関連文書を包含することができる。
2. ＣＩＡエージェントは、テロリストを追跡するために「テロリスト」エンティティを作成することができる。これにはテロリズムに関するカテゴリ、不審な電信送金、不審な武器販売、機密文書、キーワードおよび情報コミュニティにおけるテロリズムの専門家が含まれる。
3. 昨日のミーティングに関する全てのニュース速報を検索する。
4. 私の任意の競争相手に関する見出しを検索する。（これは、競争相手エンティティを作成し、次に各述語につきＯＲ修飾子を使ってエンティティでスマートリクエストをパラメータとして作成して行う）
5. 私の投資ポートフォリオ会社に関する専門家を検索する。（個別エンティティを作成し、これらのエンティティを含むポートフォリオを作成して、次に「専門家」文脈テンプレートを有し、そのポートフォリオを引数として使うスマートリクエストを作成する）
6. 私の競争相手に関するドシェ（ガイド）を開く。（個別の競争相手エンティティを作成し、これらエンティティを含むポートフォリオを作成し、次に「ドシェ」（または「ガイド」）文脈テンプレートを有し、そのポートフォリオを引数として使うスマートリクエストを作成する）。図２１は、意味論的ブラウザに表示されたエンティティのビューを表示する（左側。

Figure 2006522388

インフォメーションナーバスシステム用の拡張可能なクライアント側のユーザプロフィール仕様

概要
拡張可能なクライアント側のプロフィールは、意味論的ブラウザのユーザに、異なるジョブの役割、知識ソース、身元情報、人格、仕事のスタイルその他に対して別の状態を有することを可能にする。これは実質的には、ユーザが異なるシナリオに対して、異なる「知識世界」を作成することを可能にさせる。例えば医薬品の研究者は、自分の仕事に関連するあらゆるソースからの知識を含むデフォルトのプロフィールを有するとする。当発明者の親出願通し番号１０／１７９，６５１号で説明するとおり、そのようなソースの各々からのＳＲＭＬはクライアントでマージされ、ユーザは１つのソースから発生したかのように結果をシームレスに調べることができる。しかしながら、研究者は他のすべてとは別に特許を追跡することを望むかもしれない。そのような場合には、研究者は別の「特許」プロフィールを作成し、特許と関連する知識コミュニティ（エージェンシー）も含むこともできる（米国特許庁のデータベース、ＥＵ特許データベースなど）。
また別な例を挙げれば、例えばユーザは「仕事」と「家庭」に関するプロフィールをそれぞれ作成するとする。多くの出資アナリストは、様々な業界を横切って会社を追跡する。意味論的ブラウザを使うと、追跡する各業界に対してプロフィールを作成する。コンサルタントはプロジェクトからプロジェクト（および業界から業界）へと移行して、各プロジェクトで作成したリクエストやエンティティを保存したいかもしれない。プロフィールがはこのようなシナリオを扱うためにも使われる。
プロフィールには次のユーザ状態が含まれる。
・ 名前／詳細 − プロフィールの詳細名
・ リクエスト（エージェント）が呼び出される（ＫＩＳ上で実行される）知識のソースを示す１つ以上の知識コミュニティ（エージェンシー）
・ 身元情報 − （現在ユーザの電子メールアドレスにタグされている）ユーザ名およびパスワード
・ 関心のある分野またはお気に入りのカテゴリ − 情報コミュニティ（エージェンシー）を（同一または類似カテゴリの情報コミュニティと比較することで）ユーザに提案し、プロフィールで作成されたリクエスト用のデフォルト・クエリフィルタとして使われる。
・ スマートスタイル − スマートスタイルはプロフィールで作成されたリクエストやエンティティ用にデフォルトとして使われる。
・ デフォルトのフラグ − プロフィールがデフォルトプロフィールであるかどうかを示す。デフォルトのプロフィールは、ユーザがリクエストやエンティティを作成する、あるいは情報コミュニティなどを参照したいときに、デフォルト設定で開始される。ユーザが明確に異なるプロフィールを選択するのでない限り、デフォルトのプロフィールが使われる。
プロフィールは作成、削除、変更および改名できる。ただし、好ましい実施例では、最低１つのプロフィールが常にシステムになければならないので、デフォルトのプロフィールは削除できない。代替実施例では、最低限のプロフィールは必要とされない。
好ましくは、意味論的ブラウザの全オブジェクトはプロフィールの文脈内で開かれる。例えば、スマートリクエストはプロフィールで作成され、実行時には、クライアント意味論的クエリプロセッサは、リクエストを呼び出すため、プロフィールの特性（特に、そのプロフィール内で登録された知識コミュニティ（エージェンシー））を使用する。これによって、ユーザはリクエストの知識の特徴（より一般的には、リクエスト用にユーザが使いたい知識のソース）に基づいて、リクエストを具体的なプロフィールに関連付ける、またはスコープすることができる。
図１５は、２つのプロフィール（１５Ａの「私のプロフィール」と名づけられたデフォルトプロフィールと１５Ｂの「特許」と名づけられたプロフィール）を示す意味論的ブラウザを図示する。ユーザが干渉されずに、両方のプロフィールを経由して自分の知識世界をナビゲートできるかに注目されたい。
図１６Ａ−Ｃでは、ユーザがどのようにプロフィールを設定するかを図示する（プロフィールを作成するには、ユーザは「プロフィール作成ウィザード」を使用し、プロフィールはその後、示すように特性シート経由で変更できる）。
図１７は、「リクエスト作成ウィザード」でリクエストを作成する際に、ユーザがどのようにプロフィールを選択するかを示す。

インフォメーションナーバスシステム用の知識コミュニティ閲覧と登録の仕様

概要
ナバナ意味論的ブラウザにより、ユーザは任意のプロフィールに対し、知識コミュニティ（エージェンシー）を登録および登録解除することができる。これらの知識コミュニティは、意味論環境でのプロフィールエントリの下でユーザがいつでも利用できる。またこれらの知識コミュニティは、同じプロフィールを使って作成された任意のリクエストに対して結果が表示される際にはいつでも、組み込み警告、文脈パネルなど用にデフォルト設定で検索要求される。
意味論環境は、各プロフィールに対し登録された知識コミュニティを示す状態を包含する。クライアント側の意味論的クエリプロセッサ（ＳＱＰ）は、任意プロフィールのリクエストに対する結果から開始される動的リクエスト用に、この情報を利用する（ＳＱＰは意味ランタイムクライアントにプロフィールに対する知識コミュニティを訊ね、次に必要に応じてＸＭＬウェブサービス呼出しを、それらの知識コミュニティに発行する）。
図２２Ａと２２Ｂは、知識コミュニティの登録および登録解除用のユーザインタフェースを示す。ダイアログボックスにはコンボボックスが含まれ、ユーザはプロフィールごとにフィルタリングをしたり、全て、新規、登録済み、推奨するおよび登録解除されたコミュニティを、産業および関心分野別、キーワード別、（全ての発行地点、ローカルエリアネットワーク、エンタープライズディレクトリ、グローバル知識コミュニティのディレクトリの）発行地点別、および（任意時間、今日、昨日、今週、先週の）作成時間別に、表示したりすることができる。意味論的ランタイムクライアントは、これらのフィルタを使って（各発行ポイントに対して）発行地点終点リスナーを検索要求する。次に結果を収集し、それらを結果ペインに表示する。ユーザはまた、各知識コミュニティのカテゴリを、コンボボックス経由の結果ペインで表示できる。図２０Ｂは、知識コミュニティダイアログボックスの一番下の部分を示す。

Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388
Figure 2006522388

図１は部分的なスクリーンショットの概観図である。 図２は特許審査官が先行技術検索で好ましい実施例を使うというシナリオでの図１のダイアログボックスを拡張したものであり、医薬品分類法で「磁気共鳴影像法」が発生するスクリーンショットである。 図３は、スマートリクエストでＳＱＭＬバッファをカプセル化するバイナリ文書書式である共有可能なスマートリクエストシステムの相互作用を示し、拡張ハンドラの文書の開き方も図解する。 図４Ａは、文書ファイルの部分的なスクリーンショットの概観である。 図４Ｂは、ウィンドウズシェルに登録関連付けられた図４Ａ（右端の「私の研究レポート関連のロイター見出し（ライブ）」および「ロイター見出し（２００３年１月２１日０８：１７ＡＭ現在）という題名」からの２つの．ＲＥＱ文書の図解を示す。 図５は音声変換オブジェクトスキンの図であり、音声変換オブジェクトスキン経由で提供される電子メールメッセージを図示する。 図６は音声変換リクエストスキンを図示する。 図７は医薬品会社例の知識モデル化を図示する。 図８はクライアントコンポーネントの統合とワークフローの相互作用を図示する。 図９は、エクスプロアカテゴリのダイアログボックスの３種の異なるビューを示す。 図１０は、エクスプロアカテゴリのダイアログボックスの３種の異なるビューを示す。 図１１は、エクスプロアカテゴリのダイアログボックスの３種の異なるビューを示す。 図１２は、作動中のドシェ（報告書）スマートレンズのスクリーンショット例を示す。 図１３は、作動中のドシェ（報告書）スマートレンズのスクリーンショット例を示す。 図１４は、サーバ側の意味論的クエリプロセッサが入ってくる意味論的クエリをどう処理するかを示す（ＳＱＭＬとして表示）。 図１５は、２つのプロフィール（「私のプロフィール」という名のデフォルトプロフィールと「特許」という名のプロフィール）を示す意味論的ブラウザを図示する。ユーザが、妨害されずに両方のプロフィールを通してどのように自分の知識世界をナビゲートできるかを観察する。 図１６Ａは、ユーザがどのようにプロフィールを設定するかを図示する（プロフィールを作成するには、ユーザは「プロフィール作成ウィザード」を使用するが、プロフィールはほかの図で示すような特性シート経由で後で変更できる）。 図１６Ｂは、ユーザがどのようにプロフィールを設定するかを図示する（プロフィールを作成するには、ユーザは「プロフィール作成ウィザード」を使用するが、プロフィールはほかの図で示すような特性シート経由で後で変更できる）。 図１６Ｃは、ユーザがどのようにプロフィールを設定するかを図示する（プロフィールを作成するには、ユーザは「プロフィール作成ウィザード」を使用するが、プロフィールはほかの図で示すような特性シート経由で後で変更できる）。 図１７Ａは、「リクエスト作成ウィザード」でリクエストを作成する際に、ユーザがどのようにプロフィールを選択するかを示す。 図１７Ｂは、「リクエスト作成ウィザード」でリクエストを作成する際に、ユーザがどのようにプロフィールを選択するかを示す。 図１７Ｃは、「リクエスト作成ウィザード」でリクエストを作成する際に、ユーザがどのようにプロフィールを選択するかを示す。 図１７Ｄは、「リクエスト作成ウィザード」でリクエストを作成する際に、ユーザがどのようにプロフィールを選択するかを示す。 図１７Ｅ１は、「リクエスト作成ウィザード」でリクエストを作成する際に、ユーザがどのようにプロフィールを選択するかを示す。 図１７Ｅ２は、「リクエスト作成ウィザード」でリクエストを作成する際に、ユーザがどのようにプロフィールを選択するかを示す。 図１８は、前記操作や機能の一部を示した「スマートスタイル」ダイアログボックスのスクリーンショットを示す。 図１９は、「スマートリクエスト観察」ダイアログボックスを図示する。 図２０は、フィルタリングされたスマートリクエスト（ワイヤレスに関する見出しなど）を示す観察ウィンドウを図示する。図２０は現在のスマートリクエストタイトル（「ニュース速報」など）の観察ウィンドウの図である。 図２１は、意味論的ブラウザに表示されたエンティティビューを示す。 図２２Ａは、知識コミュニティ登録用ＵＩを示す。 図２２Ｂは、知識コミュニティ登録用ＵＩを示す。 図２３は、意味論的スレッドオブジェクトとその意味論的リンクを図示する。 図２４は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図２５は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図２６は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図２７は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図２８は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図２９は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図３０は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図３１は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図３２は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図３３は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図３４は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図３５は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図３６は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図３７は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図３８は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図３９は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図４０は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図４１は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図４２は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図４３は、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図４４Ａは、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図４４Ｂは、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図４５Ａは、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図４５Ｂは、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図４５Ｃは、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図４６Ａは、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図４６Ｂは、詳細な説明の機能、オプションや操作をさらに示す追加のスクリーンショットである。 図４７は、医薬品／バイオテク業界（ＤＮＡへリックス）の意味論的画像サンプルである。 図４８は、ニュース速報文脈テンプレート用の意味論的に適切な画像視覚化の図である。 図４９は視覚化例で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像（見出し）を示す。 図５０は視覚化例で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像（デスクで働く二人）を示す。 図５１は、意味論的な「新聞ダネになる人」の視覚化例、またはスマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像を示す。 図５２は意味論的「来るべきイベント」の視覚化例で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像を示す。 図５３は視覚化例で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像（ペトリ皿）を示す。 図５４は意味論的「履歴」視覚化例で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像を示す。 図５５は意味論的視覚化例で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像（宇宙船）を示す。 図５６は「最も高い可能性」の視覚化例で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像である。 図５７は、意味論的視覚化例で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像（コーヒー）を示す。 図５８は、意味論的に適した「名著」の視覚化で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像（車）を示す。 図５９は、意味論的に適した「推奨」の視覚化で、スマート砂時計、割込みページ、転位効果、背景クロムなどの文脈／アプリケーション要素のサンプル画像（親指を立てて賛同）を示す。 図６０は、意味論的な「今日」の視覚化で、スマート砂時計、割込みページ、転位効果、背景クロムなどの要素のサンプル画像を示す。 図６１は、意味論的な「注釈付き項目」の視覚化で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像を示す。 図６２は、意味論的な「注釈」の視覚化で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像を示す。 図６３は、意味論的な「専門家」の視覚化で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像を示す。 図６４は、意味論的な「場所」の視覚化で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像を示す。 図６５は、意味論的な「ブレンダー」の視覚化で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像を示す。 図６６は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図６７は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図６８は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図６９は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図７０は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図７１は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図７２は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図７３は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図７４は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図７５は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図７６は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図７７は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図７８は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図７９は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図８０は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図８１は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図８２は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図８３は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図８４は情報オブジェクトタイプの意味論的な視覚化例をそれぞれ示す：文書、書籍、雑誌、プレゼンテーション、履歴書、スプレッドシート、テキスト、ウェブページ、白書、電子メール、電子メール注釈、電子メールの配布リスト、イベント、ミーティング、マルチメディア、オンラインコース、人々、顧客およびユーザ。 図８５は、意味論的「時系列」の視覚化で、スマート砂時計、割込みページ、転位効果、背景クロムなどのサンプル画像を示す。

Claims (4)

  1. 知識の取得、管理、伝達および提示のためのシステムであって、
    意味論的情報を管理するためにプログラム可能なサーバと、
    ユーザが前記サーバと通信するためにユーザインタフェースを提供するクライアントからなり、
    前記サーバの前記プロセッサは、
    情報ソースから情報を確保する手順と、
    前記情報の１つ以上の意味論的特性を意味論的に確認する手順と、
    前記意味論的特性の１つ以上に基づき、ユーザのクエリに対応する手順とを行うために操作することを特徴とする知識の取得、管理、伝達および提示のためのシステム。
  2. 第一サーバは更に、意味ネットワーク、意味論的データギャザラー、意味ネットワーク整合性チェッカー、推論エンジン、意味論的クエリプロセッサ、自然言語パーサ、電子メール知識エージェント、又は知識ドメインマネージャの少なくとも１つを提供するための構造又は方法論を含むことを特徴とする請求項１に記載のシステム。
  3. 前記情報はオブジェクトまたはイベントからなり、
    前記オブジェクトまたはイベントの前記意味論的特性は、前記クエリの前記意味論と特性に意味論的にリンクするためのアクティブなエージェントによって表されることを特徴とする請求項１に記載のシステム。
  4. 意味論的情報を識別し分類するのに使われるドメイン固有の情報を追加、管理およびホストするようにプログラムされたサーバシステムで使う知識の取得、管理、伝達および提示用の方法であって、
    情報ソースから情報を確保して、
    前記情報ソースからの前記情報を意味論的にリンクして、
    前記意味論的にリンクされた情報の意味論的属性を管理して、
    ユーザのクエリに基づきリクエストされた意味論的情報を伝達して、
    カスタマイズ可能なユーザの好みに従って意味論的情報を提示することを特徴とする知識の取得、管理、伝達および提示用の方法。
JP2006503648A 2003-02-14 2004-02-17 意味論的知識の取得、管理、取り込み、共有、発見、伝達および提示用のシステムおよび方法 Pending JP2006522388A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US44773603P 2003-02-14 2003-02-14
PCT/US2004/004674 WO2004075466A2 (en) 2003-02-14 2004-02-17 Semantic knowledge retrieval management and presentation

Publications (1)

Publication Number Publication Date
JP2006522388A true JP2006522388A (ja) 2006-09-28

Family

ID=32908491

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006503648A Pending JP2006522388A (ja) 2003-02-14 2004-02-17 意味論的知識の取得、管理、取り込み、共有、発見、伝達および提示用のシステムおよび方法

Country Status (10)

Country Link
EP (1) EP1599811A4 (ja)
JP (1) JP2006522388A (ja)
KR (1) KR20060004909A (ja)
CN (1) CN1853180A (ja)
AU (1) AU2004213986A1 (ja)
BR (1) BRPI0407451A (ja)
CA (1) CA2555280A1 (ja)
EA (1) EA200501304A1 (ja)
MX (1) MXPA05008670A (ja)
WO (1) WO2004075466A2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011087922A2 (en) * 2010-01-15 2011-07-21 Apollo Enterprise Solutions, Inc. System and method for resolving transactions employing goal seeking attributes
JP2018186420A (ja) * 2017-04-26 2018-11-22 サイレックス・テクノロジー株式会社 基地局、基地局システム、通信方法及び基地局システムの通信方法
US20230078586A1 (en) * 2018-08-30 2023-03-16 Netskope, Inc. Enriched document-sensitivity metadata using contextual information

Families Citing this family (102)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009021198A1 (en) 2007-08-08 2009-02-12 Baynote, Inc. Method and apparatus for context-based content recommendation
US7698270B2 (en) 2004-12-29 2010-04-13 Baynote, Inc. Method and apparatus for identifying, extracting, capturing, and leveraging expertise and knowledge
US8849860B2 (en) 2005-03-30 2014-09-30 Primal Fusion Inc. Systems and methods for applying statistical inference techniques to knowledge representations
US7849090B2 (en) 2005-03-30 2010-12-07 Primal Fusion Inc. System, method and computer program for faceted classification synthesis
US10002325B2 (en) 2005-03-30 2018-06-19 Primal Fusion Inc. Knowledge representation systems and methods incorporating inference rules
US9177248B2 (en) 2005-03-30 2015-11-03 Primal Fusion Inc. Knowledge representation systems and methods incorporating customization
US9378203B2 (en) 2008-05-01 2016-06-28 Primal Fusion Inc. Methods and apparatus for providing information of interest to one or more users
US9104779B2 (en) 2005-03-30 2015-08-11 Primal Fusion Inc. Systems and methods for analyzing and synthesizing complex knowledge representations
US7693836B2 (en) 2005-12-27 2010-04-06 Baynote, Inc. Method and apparatus for determining peer groups based upon observed usage patterns
US8495147B1 (en) 2006-07-13 2013-07-23 Avaya Inc. Threading of mixed media
US7685199B2 (en) * 2006-07-31 2010-03-23 Microsoft Corporation Presenting information related to topics extracted from event classes
EP1895505A1 (en) 2006-09-04 2008-03-05 Sony Deutschland GmbH Method and device for musical mood detection
KR100882582B1 (ko) * 2006-12-20 2009-02-12 한국과학기술정보연구원 시맨틱 웹 기반 연구정보 서비스 시스템 및 그 방법
US7930263B2 (en) 2007-01-12 2011-04-19 Health Information Flow, Inc. Knowledge utilization
EP2122487A4 (en) * 2007-01-16 2011-02-02 Timmins Software Corp SYSTEMS AND METHOD FOR ANALYZING INFORMATION TECHNOLOGY SYSTEMS WITH COLLABORATIVE INTELLIGENCE
EP2129120A4 (en) * 2007-01-22 2010-02-03 Sony Corp INFORMATION PROCESSING DEVICE, METHOD, AND PROGRAM
US8204856B2 (en) 2007-03-15 2012-06-19 Google Inc. Database replication
WO2008150923A1 (en) 2007-05-29 2008-12-11 Livescribe, Inc. Customer authoring tools for creating user-generated content for smart pen applications
KR100913441B1 (ko) * 2007-08-20 2009-09-03 한국과학기술원 자원의 시맨틱 공간 매핑을 이용한 시맨틱 자원 검색 방법
KR100918503B1 (ko) * 2008-01-21 2009-09-24 윤재민 웹사이트 링크정보를 이용한 웹페이지 정보 전달 방법 및 그 시스템
US9361365B2 (en) 2008-05-01 2016-06-07 Primal Fusion Inc. Methods and apparatus for searching of content using semantic synthesis
WO2009132442A1 (en) 2008-05-01 2009-11-05 Sweeney Peter Method, system, and computer program for user-driven dynamic generation of semantic networks and media synthesis
US8676732B2 (en) 2008-05-01 2014-03-18 Primal Fusion Inc. Methods and apparatus for providing information of interest to one or more users
US9589381B2 (en) * 2008-06-12 2017-03-07 Microsoft Technology Licensing, Llc Copying of animation effects from a source object to at least one target object
CA2988181C (en) 2008-08-29 2020-03-10 Primal Fusion Inc. Systems and methods for semantic concept definition and semantic concept relationship synthesis utilizing existing domain definitions
CA2735160A1 (en) * 2008-08-29 2010-03-04 The Administrators Of The Tulane Educational Fund Copyright status determination system and method
CA2639438A1 (en) 2008-09-08 2010-03-08 Semanti Inc. Semantically associated computer search index, and uses therefore
US9524506B2 (en) 2011-10-21 2016-12-20 Bigmachines, Inc. Methods and apparatus for maintaining business rules in a configuration system
WO2010089248A1 (en) 2009-02-03 2010-08-12 International Business Machines Corporation Method and system for semantic searching
KR101072147B1 (ko) * 2009-02-10 2011-10-10 경북대학교 산학협력단 블로그 포스트를 온톨로지 기반 정보로 변환하는 방법 및 그 시스템
US20110041052A1 (en) * 2009-07-14 2011-02-17 Zoomii, Inc. Markup language-based authoring and runtime environment for interactive content platform
US9292855B2 (en) 2009-09-08 2016-03-22 Primal Fusion Inc. Synthesizing messaging using context provided by consumers
US9262520B2 (en) 2009-11-10 2016-02-16 Primal Fusion Inc. System, method and computer program for creating and manipulating data structures using an interactive graphical interface
US20110184945A1 (en) * 2010-01-22 2011-07-28 Qualcomm Incorporated Location aware recommendation engine
KR101146510B1 (ko) * 2010-05-20 2012-05-25 소프트포럼 주식회사 Ｓｙｎｋ 데이터베이스 암호화 시스템 및 그 방법
US9235806B2 (en) 2010-06-22 2016-01-12 Primal Fusion Inc. Methods and devices for customizing knowledge representation systems
US10474647B2 (en) 2010-06-22 2019-11-12 Primal Fusion Inc. Methods and devices for customizing knowledge representation systems
US10140619B2 (en) 2010-06-22 2018-11-27 Sizmek Technologies, Inc. Dynamic creative creation and delivery
US10002335B2 (en) 2011-01-06 2018-06-19 Cardinal Logistics Management Corporation Dynamic workflow for remote devices
US11294977B2 (en) 2011-06-20 2022-04-05 Primal Fusion Inc. Techniques for presenting content to a user based on the user's preferences
CN102737052A (zh) * 2011-04-12 2012-10-17 国际商业机器公司 一种用于处理输入的方法和系统
CN102185917A (zh) * 2011-04-29 2011-09-14 深圳市五巨科技有限公司 一种服务器适配移动终端的方法及系统、服务器适配装置
US9104765B2 (en) 2011-06-17 2015-08-11 Robert Osann, Jr. Automatic webpage characterization and search results annotation
US9098575B2 (en) 2011-06-20 2015-08-04 Primal Fusion Inc. Preference-guided semantic processing
CN102609819A (zh) * 2012-02-16 2012-07-25 华为软件技术有限公司 一种信息展现系统
KR101445218B1 (ko) * 2012-05-23 2014-09-30 이청종 컨텐츠 협력작업의 수익배분 방법
JP5962256B2 (ja) * 2012-06-29 2016-08-03 カシオ計算機株式会社 入力支援装置及び入力支援プログラム
US9270667B2 (en) * 2012-11-01 2016-02-23 Microsoft Technology Licensing, Llc Utilizing X.509 authentication for single sign-on between disparate servers
US9098502B1 (en) 2012-11-16 2015-08-04 Google Inc. Identifying documents for dissemination by an entity
US10439969B2 (en) * 2013-01-16 2019-10-08 Google Llc Double filtering of annotations in emails
US10223637B1 (en) 2013-05-30 2019-03-05 Google Llc Predicting accuracy of submitted data
US9355088B2 (en) 2013-07-12 2016-05-31 Microsoft Technology Licensing, Llc Feature completion in computer-human interactive learning
KR101503463B1 (ko) * 2013-09-25 2015-03-19 목포대학교산학협력단 가중치평균을 이용한 선박 내부 모니터링 방법
CN103729112B (zh) * 2014-01-10 2018-03-06 百度在线网络技术（北京）有限公司 显示信息的方法和装置
US9836765B2 (en) 2014-05-19 2017-12-05 Kibo Software, Inc. System and method for context-aware recommendation through user activity change detection
CN105095320B (zh) * 2014-05-23 2019-04-19 邓寅生 基于关系叠加组合的文档的标识、关联、搜索及展现的系统
JP6703527B2 (ja) * 2014-09-25 2020-06-03 オラクル・インターナショナル・コーポレイション マルチテナントアプリケーションサーバ環境におけるパーティション識別子の決定のためのシステムおよび方法
CN104639987B (zh) * 2015-01-29 2018-12-14 联发科技（新加坡）私人有限公司 被控终端及其信息提供方法
CN106326300A (zh) * 2015-07-02 2017-01-11 富士通株式会社 信息处理方法以及信息处理设备
CN105141668B (zh) * 2015-07-31 2018-09-25 中冶南方工程技术有限公司 一种基于分布式多智能体的数据同步方法
US10042619B2 (en) 2015-08-25 2018-08-07 Cognizant Technology Solutions India Pvt. Ltd. System and method for efficiently managing enterprise architecture using resource description framework
CN106886543B (zh) * 2015-12-16 2020-01-17 清华大学 结合实体描述的知识图谱表示学习方法和系统
CN106960271A (zh) * 2016-02-29 2017-07-18 艾威梯科技(北京)有限公司 一种协同工作与质量控制方法与系统
CN105740471A (zh) * 2016-03-14 2016-07-06 燕山大学 一种可动态查询论文收录状态的智能方法
EP3471376B1 (en) * 2016-03-17 2020-06-17 Google LLC Hybrid client-server data provision
US10083451B2 (en) 2016-07-08 2018-09-25 Asapp, Inc. Using semantic processing for customer support
CN109792402B (zh) * 2016-07-08 2020-03-06 艾赛普公司 自动响应用户的请求
JP6960218B2 (ja) * 2016-11-18 2021-11-05 株式会社ベネッセスタイルケア サービス支援システム、サービス支援方法及びプログラム
KR101869618B1 (ko) * 2016-12-29 2018-06-20 (주) 쓰리웨어 맞춤형 뉴스컨텐츠 제공시스템
KR101904643B1 (ko) 2017-02-09 2018-10-05 한국기술교육대학교 산학협력단 의사결정트리를 이용한 기사 생성 방법
KR102457568B1 (ko) * 2017-09-29 2022-10-21 삼성전자주식회사 입력된 정보와 관련된 이미지를 제공하기 위한 전자 장치 및 그의 동작 방법
CN107862081B (zh) * 2017-11-29 2021-07-16 四川无声信息技术有限公司 网络信息源查找方法、装置及服务器
CN109299400A (zh) * 2018-09-06 2019-02-01 北京奇艺世纪科技有限公司 一种观点抽取方法、装置及设备
CN109256029B (zh) * 2018-09-12 2021-09-03 广州小鹏汽车科技有限公司 一种地点属性的自动设置方法及装置
CN109492208B (zh) * 2018-10-12 2023-06-23 天津字节跳动科技有限公司 文档编辑方法及其装置、设备、存储介质
CN111049723B (zh) * 2018-10-15 2022-11-08 广州虎牙信息科技有限公司 消息推送方法、消息管理系统、服务器及计算机存储介质
US11630824B2 (en) * 2018-10-16 2023-04-18 Shimadzu Corporation Document search method and document search system
CN109858036B (zh) * 2019-02-26 2023-07-28 科大讯飞股份有限公司 一种文书划分方法及装置
CN110048936B (zh) * 2019-04-18 2021-09-10 宁波青年优品信息科技有限公司 一种语义关联词判断垃圾邮件的方法
CN110222017B (zh) * 2019-05-13 2021-09-21 北京百度网讯科技有限公司 实时数据的处理方法、装置、设备及计算机可读存储介质
US11153400B1 (en) * 2019-06-04 2021-10-19 Thomas Layne Bascom Federation broker system and method for coordinating discovery, interoperability, connections and correspondence among networked resources
CN110347839B (zh) * 2019-07-18 2021-07-16 湖南数定智能科技有限公司 一种基于生成式多任务学习模型的文本分类方法
US11063986B2 (en) 2019-08-29 2021-07-13 Fraudmarc Inc. Low-latency, outbound message monitoring, control, and authentication
CN110727760B (zh) * 2019-09-08 2023-11-07 天津大学 一种对大规模知识图谱进行分布式正则路径查询的方法
CN110781685B (zh) * 2019-10-18 2022-08-19 四川长虹电器股份有限公司 基于用户反馈自动标注语义分析结果正误性的方法
CN110728389B (zh) * 2019-10-21 2023-11-10 中国民航信息网络股份有限公司 一种跨预定系统的机票订单处理方法、装置及系统
CN111209028B (zh) * 2020-01-07 2021-10-01 京东数字科技控股有限公司 一种数据处理方法、装置、电子设备及存储介质
CN111392296B (zh) * 2020-04-14 2021-03-09 重庆市环卫集团有限公司 一种用于垃圾转运站的智慧收运系统
WO2021260684A1 (en) * 2020-06-21 2021-12-30 Avivi Eliahu Kadoori System and method for detection and auto-validation of key data in any non-handwritten document
US11720346B2 (en) 2020-10-02 2023-08-08 International Business Machines Corporation Semantic code retrieval using graph matching
CN112749548B (zh) * 2020-11-02 2024-04-26 万齐智 一种基于规则的中文结构化金融事件缺省补全抽取方法
KR102542394B1 (ko) 2020-12-09 2023-06-13 주식회사 이앤지테크 고객맞춤형 여행 스케줄링 가상현실 플랫폼 시스템 및 그 구동방법
CN113761228A (zh) * 2021-01-15 2021-12-07 北京沃东天骏信息技术有限公司 基于多任务的标签生成方法、装置、电子设备和介质
US12072915B2 (en) 2021-03-12 2024-08-27 Hcl Technologies Limited Method and system for providing profile based data access through semantic domain layer
US11272888B1 (en) * 2021-06-22 2022-03-15 Nft Ip Holdings Llc Devices and systems that measure, quantify, compare, package, and capture human content in databases
US20230004719A1 (en) * 2021-06-30 2023-01-05 Earley Information Science, Inc. Digital data processing systems and methods for multi-domain digital content retrieval and generation with dead-end prevention
WO2023278682A1 (en) * 2021-06-30 2023-01-05 Earley Information Science, Inc. Multi-bot digital content retrieval and generation systems
CN113312656B (zh) * 2021-07-29 2022-04-15 阿里云计算有限公司 数据轮转方法、装置、设备及系统
CN113657121B (zh) * 2021-09-03 2023-04-07 四川大学 一种日志变量语义标注方法
US20230177206A1 (en) * 2021-12-06 2023-06-08 Sap Se Data privacy integration services processing using multiple work packages and multiple responder groups
CN114398442B (zh) * 2022-01-25 2023-09-19 中国电子科技集团公司第十研究所 一种基于数据驱动的情报处理系统
CN115357581B (zh) * 2022-08-19 2023-05-05 筑智建科技(重庆)有限公司 一种海量bim数据的分布式存储方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001069428A1 (en) * 2000-03-15 2001-09-20 Taalee, Inc. System and method for creating a semantic web and its applications in browsing, searching, profiling, personalization and advertising
WO2003001413A1 (en) * 2001-06-22 2003-01-03 Nosa Omoigui System and method for knowledge retrieval, management, delivery and presentation

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6240407B1 (en) * 1998-04-29 2001-05-29 International Business Machines Corp. Method and apparatus for creating an index in a database system
US6418448B1 (en) * 1999-12-06 2002-07-09 Shyam Sundar Sarkar Method and apparatus for processing markup language specifications for data and metadata used inside multiple related internet documents to navigate, query and manipulate information from a plurality of object relational databases over the web

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001069428A1 (en) * 2000-03-15 2001-09-20 Taalee, Inc. System and method for creating a semantic web and its applications in browsing, searching, profiling, personalization and advertising
WO2003001413A1 (en) * 2001-06-22 2003-01-03 Nosa Omoigui System and method for knowledge retrieval, management, delivery and presentation

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011087922A2 (en) * 2010-01-15 2011-07-21 Apollo Enterprise Solutions, Inc. System and method for resolving transactions employing goal seeking attributes
WO2011087922A3 (en) * 2010-01-15 2011-11-10 Apollo Enterprise Solutions, Inc. System and method for resolving transactions employing goal seeking attributes
JP2018186420A (ja) * 2017-04-26 2018-11-22 サイレックス・テクノロジー株式会社 基地局、基地局システム、通信方法及び基地局システムの通信方法
US20230078586A1 (en) * 2018-08-30 2023-03-16 Netskope, Inc. Enriched document-sensitivity metadata using contextual information
US11907393B2 (en) * 2018-08-30 2024-02-20 Netskope, Inc. Enriched document-sensitivity metadata using contextual information

Also Published As

Publication number Publication date
WO2004075466A3 (en) 2004-10-28
KR20060004909A (ko) 2006-01-16
WO2004075466A2 (en) 2004-09-02
AU2004213986A1 (en) 2004-09-02
MXPA05008670A (es) 2005-11-17
CN1853180A (zh) 2006-10-25
BRPI0407451A (pt) 2006-02-07
EA200501304A1 (ru) 2006-08-25
CA2555280A1 (en) 2004-09-02
EP1599811A4 (en) 2008-02-06
EP1599811A2 (en) 2005-11-30

Similar Documents

Publication Publication Date Title
JP2006522388A (ja) 意味論的知識の取得、管理、取り込み、共有、発見、伝達および提示用のシステムおよび方法
US20120191716A1 (en) System and method for knowledge retrieval, management, delivery and presentation
US20030126136A1 (en) System and method for knowledge retrieval, management, delivery and presentation
US20070081197A1 (en) System and method for semantic knowledge retrieval, management, capture, sharing, discovery, delivery and presentation
Dzbor et al. Magpie–towards a semantic web browser
US7433876B2 (en) Semantic web portal and platform
CA2808275C (en) Distributed computing services platform
US7584208B2 (en) Methods and systems for managing offers and requests in a network
AU2001268674A1 (en) Distributed computing services platform
WO2005099381A9 (en) Expression and time-based data creation and creator-controlled organization
KR100919606B1 (ko) 분산 컴퓨팅 서비스 플랫폼
US20160077727A1 (en) Online Protocol Community
McDowell Meaning for the Masses: Theory and Applications for Semantic Web and Semantic Email Systems
Paralič et al. Some approaches to text mining and their potential for semantic web applications
AU2002345906A1 (en) System and method for knowledge retrieval, management, delivery and presentation
Wang NewsView: A Recommender System for Usenet based on FAST Data Search

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070216

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100615

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100915

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100924

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20110222