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を「資源」と訳している。)
... 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). [日本語訳]
HTTP URI (HTTP URL) を抽象リソース(クラスなど)の識別に用いることは、例えば RDF Schema やOWLにおいて広く行われている。それらのURIはHTTPと関連付けられているので、HTTPでアクセスされた際に、典型的にはウェブブラウザで、リソースのどのような種類の表現を(もしあれば)返すべきか、また抽象リソースと情報リソースを区別するためにURIの構文をどう使うべきか、といった疑問が生まれている。RFC3986などのURIの規格では、リソースに対する実際の処理を定義する役目を個別のプロトコルの規格に任せており、それらの疑問に対してなんの解答も示していない。情報リソースに対してはフラグメント識別子を使わず、抽象リソースを表すためのみに使うという方法も提案されているが、それを現実に実施するのは不可能である。
HTTP URIがどのような種類のリソースを識別するべきかまたするべきでないか、という一般的な疑問はW3CではhttpRange-14として知られている。これはTechnical Architecture Group (TAG) が作成したリスト上の名前から来ている。TAGは2005年にこの問題に対する最終解答を示した。それはGETリクエストに対するサーバの応答の種類によって情報リソースと非情報リソースを区別するというものだった。この解決法によって論争は終わり、セマンティック・ウェブのコミュニティにおいて合意を得たようにみえるが、Pat Hayes などその実行可能性と概念的基盤について懸念を示すものもいる。Hayes の意見によれば、情報リソースとその他のリソースの明確な区別は不可能であり、全く指定されるべきではなく、対象リソースの曖昧さはURI(とその他の名前付けの仕組み)がそもそも持っている性質なのである。