ユニバーサルキャンパス

インサイドMicrosoft.NET(その3)

　

　ここでは、MSNを例にパーソナライズについて考えてみよう。

　MSNでは、ユーザーの好みによってページを変更することができる。これは、一番シンプルなパーソナライズである。「HotMail」のユーザーIDのプロファイルを使って、そのユーザーが設定した好きな色を管理している。そして、ユーザーがMSNのサイトに入ったときに、Passportの中身を見て、そのPassportからプロファイルを参照して、設定色を見て情報を出している。そして、現在のWebアプリケーションというのは、ほとんど例外なく、ユーザーのパーソナライゼーション(プロファイル情報)は、サーバ側で管理している。ところが、ユニバーサルキャンバスの場合は、クライアント側でのパーソナライゼーション管理が可能となった。

　現在、Internet Explorerでできることを考えてみよう。IEでは、「お気に入り」にそのユーザーが保管しておきたいサイト情報を記憶しておく。ところが、この「お気に入り」には、そのサイトのURLの情報しか記憶できない。その情報が、そのユーザーにとってどういうメリットを持っていて、どういった点で「お気に入り」なのかという情報は、いっさいそこには記憶できない。つまり、ジャンルの分類はユーザーがディレクトリを作って可能だが、ページに対してのプロパティの設定ができないわけだ。

　ユニバーサルキャンバスの、クライアント側でのパーソナライゼーション管理を利用すると、重要度はどのぐらいなのかとかいった情報を、クライアント側のパーソナライゼーションで管理可能となる。ページに対して右クリックすると、プロパティ設定の画面が表示されて、そこで重要度の設定が可能となる。これは、URLの設定に対してある種の意味付けをしているわけで、そこではメタデータが使われている。つまり、URLのリソースに対して、メタデータを使って管理しているわけだ。

Figure 11　「メタデータ」を基盤にしたモデル

　「Microsoft.NET」には、UI、Webサービス、COM+ランタイム、Visual Studio.NETなどのすべてが入っている。 　Microsoftの言い方では、表向きは「XML」が「.NET」の基盤になっているが、正確にいうと「メタデータ」が基盤になっている。セキュリティにしてもCOM+ランタイムにしても、メタデータをベースにした機能を提供しようとしている。「メタデータ」を基盤にするという言い方は、ユーザーにとって分かり難い。「メタデータ」が一般的な用語ではないので、いわゆるすでに普及している聞いた瞬間に理解できる用語「XML」をベースにしているが、技術的に見れば、「XMLではなくメタデータをベースにしている」というのが正しい言い方である。

　URLというのは、ある意味ではXMLのなかのデータの構造の1つである。URLの情報という意味で1つのデータ構造なわけで、それに対して何らかの意味を付けることができる。そしてその情報は、クライアント側のデータベースで管理する。ということは、今まではパーソナライズはサーバサイドで行なっていたことが多かったが、クライアントサイドでも行なうことができるようになり、クライアント／サーバ両方で可能となる。プロファイル情報もクライアント／サーバ間で連携を取って処理することができれば、オンラインになったときに同期を取ることも可能だ。サーバ側でのみのパーソナライズでは、オフラインの時に使えないからである。

　情報に「意味付け」するということは非常に重要である。たとえばコンテンツに対する重要度、機密、セキュリティ情報などといった「レーティング」や、意味的な分類などは、すべてプロパティとして管理する。今までは表示させて閲覧するだけのページに対しても、これからは、そのページに対して、自分なりの書き込みができるということになる。それをメタデータで管理するわけだ。

　その考え方を進めると、Web上のページだけでなく、すべてのリソースに対して属性を付けることができる。たとえば、ディレクトリのなかのファイルのなかのあるドキュメントの一節、つまりWordの文書のなかの、第1章のある段落といったことに対して、属性を付けることができる。あるいは、それぞればらばらな記憶媒体のなかに入っている、電子メールのメッセージやデータベースのレコードなども、一括的にプロパティとして管理できるようになる。

　だから、意味に対して「重要度大」という設定を検索すれば、それが電子メールのメッセージのフォルダに入っていようが、Wordのドキュメントのなかにあろうが、インターネット上のページにあろうが全部探し出される。それを全部メタデータで管理するわけだ。

　ユーザーにとって必要なのは情報の中身であって、情報がどこにあって、どのような形式で保存されているかは関係ない。特にエンドユーザーになればなるほど、データベースのレコードと、ファイルシステムのなかのWordドキュメントの中身がどう違うかなどは、知る必要がないからである。

　ここで必要なのは「意味」の情報であるから、意味ベースの検索というのは、「構文」ベースで行なってはいけない。ファイルにアクセスする時はファイルのサーチを使わなければならないし、データベースではSQLを使うといったように、それぞれ収められてるデータの在り処によって、ばらばらの検索方法を使わなければならなくなる。当然、見つからない可能性もある。だから「意味ベース」で行なうわけである。この方法を使えば、COM+のオブジェクトのなかまで検索可能だ。アプリケーションのなかに持っているデータも、プロパティの対象だからだ(公開するかどうかは、オブジェクト実装している開発者の判断になる)。

　話は遡るが、ここまでくれば、複合ドキュメントが必要なくなったことの意味が分かるはずだ。メタデータベースで処理してきたコンテンツを、どのように組み合わせて表示させるかの問題になるわけである。