ちょっとしたメモ

昨夜のメモで「人物のURIを記述するなら、ホームページなどのネットワーク上に実際に存在するリソースのURIではなく、何か別のURIを用いる必要がある」と書いたのは、RDFだからどうだということではなく、ウェブのアーキテクチャの基本的な問題だ。RDFやセマンティック・ウェブを意識しなければ別にいいでしょ、というものではないので、ここはよく理解しておきたい。

(1) Dublin Coreのcreatorは作者 (An entity primarily responsible for making the content of the resource)を示すものである；(2) link要素は、ウェブ文書がhref属性値URIが示すリソースに対して、rel属性値が示すタイプ（関係）のリンクを持つことを表す；この2つの帰結として、link rel="dc.creator"と書いたら、hrefの値は「作者を表すURI」となる。これはRDFとして解釈するかどうかを問わず、Dublin Coreと(X)HTMLのセマンティクスが定めていることだ。

ここで出てくるのが、「作者のホームページ」や「ユーザ情報ページ」のURIを人物を表すURIとして代用したっていいのでは、という考え方だろう。しかしこれは、Architecture of the World Wide Web, Volume OneがURIの衝突 (URI collision) と呼んでいる問題に陥る。

By design, a URI identifies one resource. Using the same URI to directly identify different resources produces a URI collision. Collision often imposes a cost in communication due to the effort required to resolve ambiguities.

(2.2.1. URI collision)

さらに、先日も紹介したhttpRange-14問題についての結論の1番目は、httpリソースがGETリクエストに対して応答コード2xxを返したら、そのURIで識別されるリソースは“情報リソース”である、と述べている。サーバーが200を返す、すなわちネットワーク上に実在する（取得できる）リソースのURIは、人物を表すものとしては適切とは言えないのだ。

とは言っても、(X)HTMLのlink要素で作者情報を示すのに、そのリンク先がNot Foundでは役に立たないではないか、というのももっともな話だ。ではどうすればいいか。

ひとつの方法は、サーバーによるリダイレクトだ。httpRange-14の解決策の2番目にあるように、作者を表すURIに対してリクエストを受けたら、サーバーが応答コード303でホームページなり作者情報ページのURIを返してやれば、link要素をブラウザがたどったとしても有益な情報が得られ、かつURIの衝突は生じない。

もう一つは、「作者」を表すdc:creatorではなく「作者のホームページ」を表す独自のプロパティ（スキームとrel属性値）を定めて、そのhrefとしてホームページURIを指定する方法だ。これはlink要素でrev="made"としてhrefにメールアドレスを記述するのと同様の考え方になる。これならば、URIは「作者を間接的に特定する」ものとして機能し、やはりURIの衝突は生じない。

hrefの値を、http:リソースではなく純粋なIDとしてのURI（urn:pin:など）にするのでも、もちろん構わない（その場合、ブラウザはリンクを直接は利用できないが）。いずれにしても、ウェブの基本的な約束を踏まえた上で、意欲的な新提案が出てくるのが、みんなにとって望ましいことであるはずだ。