Wikipedia を元にした DBpedia とかは、Wikipedia と同様 URI にその項目の名前が埋め込まれている（例: http://ja.dbpedia.org/page/京都府。もちろんURIを手掛かりにできるというのも利点になり得るが、それは URI に余計な意味を持たせないという原則*1からするとむしろ望ましくないことのように思える。
名前ベースのシステムの本質はURIに名前が含まれていることではなく、URIのアイデンティティが名前であるように設計されていることだ。URIが/item/00001のような抽象的な文字列であろうが、そのURIで指されるものが例えば URI のrdfs:labelに書かれた名前で決定されるならば、名前ベースのシステムだ。
しかし、大抵の場合、そういうアイデンティティの原則を守りきることは難しく、多くの例外を作ってしまう。しかも、無意識に。名前ベースの原則をはずれたときに URI と内容の不一致が起こることによって作成者に気持ち悪さが生じるように、URI に名前を含めておくのはこの意味でよいプラクティスである。また、Cool URI の原則からしても、アイデンティティに相当する文字列は含めてよい。URIを変更する必要が生じる余計な意味というのはアイデンティティに関わらない付随的な意味のことであるからだ。
さて、名前ベースのシステムとは、名前をURIのアイデンティティとしたシステムだと確認した上で、その利点を説明する。
まず初めに結論を述べておくと、利点は次の２つだ。
- 人間の認知と整合的なデータ空間を構成することができる。
- 一般的に ID 管理のコストが低い。
例えば、製品について紹介するページに製品名を使うことで、余計な製品の情報が混じったりしないし、外部からリンクを張ったりアクセスしたりする人にとって、そのページがどういうページなのか明瞭にわかる。これは「名前」自体、私たちが日常の事物を指すのに使っている Identifier だからだ。それをウェブの世界にも持ち込むことで、人間の認知と整合的なデータ空間を構成することができる。
一方で、人の名前は使われ方も少し複雑で、多くの場合同姓同名が問題になるし、結婚で姓を変えてもその人はその人だ。そこで個人番号みたいな数字でのID管理が議論されることになる。
名前は検索の時に使えればよくて、URIの体系が人間の認知と整合的である必要は無いという反論は可能であるし、Web of Documents の世界を継承するならむしろその考え方が普通だろう。
それは数字などによるID管理と名前ベースの検索エンジン運用のコストが十分に将来にわたって賄える場合は IDベースでも良いだろう。ただ、意味のない番号と実体の対応関係を把握し続けるというのは技術的には容易でも運用面ではなかなか難しい要求だ。名前と実体の対応は、名前が使われている間には社会における名前の運用がその対応関係を保持してくれているので、ID管理の必要が無い。
一方で検索という形にユーザは慣れているので、名前によってある程度ロバストに、関連するリソースのリストがスピーディーに得られることは求められてしまう。SPARQL は一般的に遅いので、このニーズに応えるために、名前ベースで構築した LODAC Species にも検索エンジンを付けた（現在は諸般の事情で停止中）。
とりあえずここまで。あとは検索エンジンの REST の話とかして、検索エンジンも、http://name.ja.org/search#田中太郎 という URI を持つのならばそれは名前ベースのシステムの一部じゃんみたいな話を入れたかったけど、ここらへんはAPIについての話とかも調べなきゃなのでとりあえずここまで。Wikipediaの検索ボックスって、クエリにドンピシャのページがある場合はhttps://ja.wikipedia.org/w/index.php?search=田中&title=特別%3A検索&go=表示ってページからhttps://ja.wikipedia.org/wiki/田中に直接リダイレクトされるようになっていて、検索エンジンとURIによる情報提示がつながっている一例だと思う。
