Loading article…
知識サービス( KaaS ) は、知識モデルに基づいてユーザーに情報を提供するコンピューティング サービスであり、その知識モデルは、決定木、関連ルール、ニューラル ネットワークなど、さまざまなモデルから構築される可能性があります。[ 1 ]知識サービス プロバイダーは、中央集権型の知識サーバーを介してユーザーからの知識要求に応答し、ユーザーとデータ所有者間のインターフェースを提供します。[ 2 ] [ 3 ]
KaaSは、クラウドコンピューティングに依存するビジネスモデルの一つで、コンピュータ資源をオンデマンドで、使用量に応じて支払う方式で販売するものです。[ 4 ]
2019 年の国際セマンティック Web カンファレンスでは、知識を Web 上でライブ化して進化させ、ユーザーが精緻化された知識から直接学習できるようにする方法が説明されました。これは現在、知識グラフの形で現れています。[ 5 ] KaaS は、知識グラフがサービスを介してアクセスされるときに現れます。これは、大量のデータを計算し、そのデータを統合して分析し、Web サービス API を使用してリアルタイムで公開する DaaS とは対照的です ( Data as a Serviceより)。KaaS では、コンテキストを活用できます。つまり、KaaS の情報要求に関連するユーザーのコンテキスト (要求を行う場所と時間) と、KaaS が自動的に理解するか、ユーザーによって示された、ユーザーの何らかの目的や目標に関連する情報のコンテキストの両方です。
いわゆるDIKW ピラミッドのような、このような区別を行う概念モデルは、おそらく 40 年以上前から存在しています (これについては 1974 年のジャーナル記事を参照[ 6 ] )。しかし、定義は安定しておらず、普遍的に受け入れられていません (知恵の価値を問う DIKW Wikipedia 記事内のDIKW の概念化についての議論を参照)。DIKW の知識要素は、定義するのが難しい捉えどころのない概念であると一般的に合意されていますが、Rowley 2007 は、有名な学生用教科書[ 7 ]の中で、知識は「情報を参照して定義される」ものであり、事実だけでなく「信念や期待」も含まれると述べることで、知識をデータから区別しました。
知識グラフに関して言えば、知識とは、純粋なデータに加えて提供される追加コンテンツであり、概念、データ、エンティティ間のカテゴリ、特性、関係の定義であり、1つ、複数、またはすべての議論領域を実体化するものである（オントロジーの定義を参照）。
「信念や期待」、あるいはそれほど直接的に明示的ではないその他の知識を表現する能力は、情報科学における継続的な改善分野であり（暗黙知を参照）、KaaSに関連して、それを行うための最新の情報学的メカニズムの確立は、KaaSが単なる付加価値のあるDaaSと区別されるため、KaaSの正当性にとって極めて重要である。
知識グラフは、提供する議論の1つ、複数、またはすべての領域を裏付ける概念、データ、エンティティ間のカテゴリ、特性、関係を定義することによってコンテキストを表現する能力（オントロジーの定義を参照）により、知識ネットワークへのアクセスを提供することがKaaSの必須機能となる可能性があるという考えにつながっています。
サービスで提供されるコンテンツの多くは、ユーザー（クライアント）が質問への回答を理解するために必要なコンテキストの大部分をセッションを通じて提供することに依存しています。例えば、現在のHTTPインターネットプロトコルを使用する場合、ウェブページなどのURIGETで識別される情報を取得するリクエストに対して、クライアント（人間または機械）は、ペイウォールやその他のコンテンツアクセス制御を回避できるように、アクセス情報を自動的に提供されることがあります。この場合、クライアントの情報アクセス権限に関するコンテキストによって、提供される情報が変更される可能性があります。
このインターネットプロトコルの例を論理的に拡張すると、サーバーはクライアントから、手動または自動で、クライアントの状況に関する情報である完全なコンテキストを受け取り、これによりサーバーはクライアントの要求を最適に解釈できるようになります。現在のインターネットプロトコルでは、クライアントがフォーマット、言語、および関連する設定を表現できますが、クライアントが既に知っていることや理解できる可能性のあることについては言及されていません。最近のプロファイルによるコンテンツネゴシエーション[ 8 ]は、HTTPインターネットプロトコルと関連サービスの両方に、クライアントが識別された情報モデルに合致する情報（サーバーからの応答）を要求できるようにする機能を追加することを提案しています。これにより、クライアントは理解しているフォーマットや言語（技術的には好みのもの）だけでなく、理解している議論の領域も示すことができるようになり、包括的なクライアントコンテキストの提供に向けた一歩となります。