Loading AI tools
ウィキペディアから
リソース (resource) はWorld Wide Web (WWW) の基本となる概念である。しかしながら、それが実際に意味するものについては複数の理解がある。
リソースという用語は、Uniform Resource Locator (URL) の対象を指すものとして初めて登場したが、後にあらゆるUniform Resource Identifier (URI、RFC 3986)、またはInternationalized Resource Identifier (IRI、RFC 3987)、が指し示すものを含むように拡張された。セマンティック・ウェブにおいては抽象的なリソースとその意味プロパティがResource Description Framework (RDF) に基づいた言語群で記述される。
リソースの概念はウェブの歴史の中で進化していった。初期の静的に参照可能な文書やファイルという概念から、より汎用的かつ抽象的な定義へと変化し、現在ではウェブ上の識別できる、または名前が付けられる、参照できる、処理できる、あらゆるものを含むようになった。その宣言的な側面(識別できる、名前が付けられる)と機能的な側面(参照できる、処理できる)は初期のウェブの仕様においてははっきりと区別されておらず、その概念は長い間、そして現在でも、難解な議論の的となっている。
ウェブの初期の仕様 (1990-1994) では、「リソース」という語はほとんど使われていない。ウェブとはハイパーテキストでリンクしあった静的に参照可能なオブジェクト、基本的にはファイルと文書、のネットワークそれ以上でも以下でもなかった。それらのオブジェクトは特定のプロトコルで参照・処理されるものだとしかみなされていなかった。ウェブページはHTTPでアクセスされ、ファイルはFTPで交換される、など。
リソースという語が最初に目立った形で使われたのは1994年6月に公開されたRFC 1630においてである。この文書はUniversal Resource Identifier (URI) の汎用的な概念と、その2つのサブセットであるUniversal Resource Locator (URL) とUniversal Resource Name (URN) を定義している。リソースは識別できる何かとして暗黙的に定義されている。ここでいう識別には名前付けと参照という2つの目的があり、後者のみがプロトコルに依存する。実際のところ、RFC 1630はリソースの概念を定義しようとはしておらず、URI・URL・URNに含まれた形以外でリソースという語を使っていることはほとんどない。また、依然「オブジェクトのネットワーク」について述べている。
後にRFC 1738(1994年12月)でURLの仕様が定められ、"Universal"という単語が"Uniform"と置き換えられた。この文書ではリソースという語がインターネット上で「利用可能な」または「存在しており、アクセスできる」オブジェクトを指して、より頻繁に用いられている。しかしながら、依然「リソース」という語について明示的に定義されてはいなかった。
最初の明示的なリソースの定義はRFC 2396(1998年8月)にある:
A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources. [日本語訳](Resourceを「資源」と訳している。)
挙げられている例は物理的なものばかりだが、この定義によってより抽象的なリソースへの道が開かれた。ある概念にアイデンティティを与え、アイデンティティを正しい書式のURIで表現すれば、概念はリソースに成り得る。2005年1月、RFC 3986でこの定義拡張が完全に明示された:
... abstract concepts can be resources, such as the operators and operands of a mathematical equation, the types of a relationship (e.g., "parent" or "employee"), or numeric values (e.g., zero, one, and infinity). [日本語訳]
1999年にリリースされたRDF (Resource Description Framework) はリソースについて記述すること、言い換えればリソースのメタデータを標準的な方法で言明すること、を第一に意図している。RDFによるリソース記述はトリプル(主語・述語・目的語)を単位とし、主語は記述するリソース、述語はプロパティの種類、目的語はデータや他のリソースを表す。述語自身もリソースとしてURIで識別される。つまり、"title"(タイトル)や"author"(著者)といった述語もRDFではリソースとして表現され、他のトリプルの主語として再帰的に使うことができる。この帰納的な原理に基づき、RDF SchemaやOWLといったRDFの語彙ではクラスやプロパティ、その他の概念をURIで識別される抽象リソースの形で定義している。
RDFでは無名リソースまたはブランクノードと呼ばれるURIを持たないリソースも実用のために定義されている。
HTTP URI (HTTP URL) を抽象リソース(クラスなど)の識別に用いることは、例えば RDF Schema やOWLにおいて広く行われている。それらのURIはHTTPと関連付けられているので、HTTPでアクセスされた際に、典型的にはウェブブラウザで、リソースのどのような種類の表現を(もしあれば)返すべきか、また抽象リソースと情報リソースを区別するためにURIの構文をどう使うべきか、といった疑問が生まれている。RFC 3986などのURIの規格では、リソースに対する実際の処理を定義する役目を個別のプロトコルの規格に任せており、それらの疑問に対してなんの解答も示していない。情報リソースに対してはフラグメント識別子を使わず、抽象リソースを表すためのみに使うという方法も提案されているが、それを現実に実施するのは不可能である。
HTTP URIがどのような種類のリソースを識別するべきかまたするべきでないか、という一般的な疑問はW3CではhttpRange-14として知られている。これはTechnical Architecture Group (TAG) が作成したリスト上の名前から来ている。TAGは2005年にこの問題に対する最終解答を示した。それはGETリクエストに対するサーバの応答の種類によって情報リソースと非情報リソースを区別するというものだった。この解決法によって論争は終わり、セマンティック・ウェブのコミュニティにおいて合意を得たようにみえるが、Pat Hayes などその実行可能性と概念的基盤について懸念を示すものもいる。Hayes の意見によれば、情報リソースとその他のリソースの明確な区別は不可能であり、全く指定されるべきではなく、対象リソースの曖昧さはURI(とその他の名前付けの仕組み)がそもそも持っている性質なのである。
RDFでは、「誰でもあらゆるものについてあらゆることを言明できる」。リソースは形式的な記述によって「定義」され、それは誰でもウェブ上で発行し、複製し、変更し、発行することができる。古典的な意味でのリソース(ウェブページとウェブ上のファイル)の内容がその発行者(知的所有権を主張できる者)に所有されていることがはっきりしているとして、その一方、抽象リソースはRDF記述の積み重ねによって定義され、単一の発行者によって管理される必要はなく、互いに一貫している必要もない。リソースが明確で信頼できる所有権による権威ある定義を持つべきかどうか、またそうであるのなら、その記述をその他の記述とどう技術的に区別するべきか、という問題は未解決のままである。それと同時に知的所有権がそれらの記述に対してどのように適用できるのか、という問題もある。
RESTにおけるリソースはRDFにおけるそれより具体的なものである。リソースはURIによって識別され、標準化されたCRUDインタフェース(HTTPのPOST・GET・PUT・DELETE)を持ち、ネットワークを通してその表現(XMLなど)が交換される。リソースとその表現を明確に区別しないことも多い。
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.