Web resource: Difference between revisions

Revision as of 22:41, 26 December 2021

Revision as of 00:22, 27 December 2021

Line 11:

== From documents and files to web resources ==

In the early specifications of the web (1990–1994), the term ''resource'' is barely used at all. The web is designed as a network of more or less static addressable objects, basically files and documents, linked using [[uniform resource locator]]s (URL）URLs). A web resource is implicitly defined as something which can be identified. The identification serves two distinct purposes: naming and addressing; the latter only depends on a protocol. It is notable that RFC 1630 does not attempt to define at all the notion of resource; actually it barely uses the term besides its occurrence in URI, URL and URN, and still speaks about "Objects of the Network".

A web resource is implicitly defined as something which can be identified. The identification serves two distinct purposes: naming and addressing; the latter only depends on a protocol. It is notable that RFC 1630 does not attempt to define at all the notion of resource; actually it barely uses the term besides its occurrence in URI, URL and URN, and still speaks about "Objects of the Network".

RFC 1738 (December 1994) further specifies URLs, the term "Universal" being changed to "Uniform". The document is making a more systematic use of ''resource'' to refer to objects which are "available", or "can be located and accessed" through the internet. There again, the term ''resource'' itself is not explicitly defined.

Line 34 ⟶ 32:

===Using HTTP URIs to identify abstract resources===

[[URL]]s, particularly [[uniform resource identifier|HTTP URI]]s, are frequently used to identify abstract resources, such as classes, properties or other kind of concepts. Examples can be found in RDFS or OWL [[Ontology (computer science)|ontologies]]. Since such URIs are associated with the HTTP protocol, the question arose of which kind of representation, if any, should one get for such resources through this protocol, typically using a web browser, and if the syntax of the URI itself could help to differentiate "abstract" resources from "information" resources. The URI specifications such as RFC 3986 left to the protocol specification the task of defining actions performed on the resources and they don't provide any answer to this question. It had been suggested that an HTTP URI identifying a resource in the original sense, such as a file, document, or any kind of so-called information resource, should be "slash" URIs — in other words, should not contain a [[fragment identifier]], whereas a URI used to identify a concept or abstract resource should be a "hash" URI using a fragment identifier.

For example: <code><nowiki>http://www.example.org/catalogue/widgets</nowiki></code>

<code>A</code>

For example: <code><nowiki>http://www.example.org/catalogue/widgets.html</nowiki></code> would both identify and locate a web page (maybe providing some human-readable description of the widgets sold by Silly Widgets, Inc.) whereas <code><nowiki>http://www.example.org/ontology#Widget</nowiki></code> would identify the abstract concept or class "Widget" in this company ontology, and would not necessarily retrieve any physical resource through [[HTTP protocol]]. But it has been answered that such a distinction is impossible to enforce in practice, and famous standard vocabularies provide counter-examples widely used. For example, the [[Dublin Core]] concepts such as "title", "publisher", "creator" are identified by "slash" URIs like <code><nowiki>http://purl.org/dc/elements/1.1/title</nowiki></code>.

The general question of which kind of resources HTTP URI should or should not identify has been formerly known in W3C as the [http://www.w3.org/2001/tag/issues.html#httpRange-14 httpRange-14] issue, following its name on the list defined by the (TAG). The TAG delivered in 2005 a final answer to this issue, making the distinction between an "information resource" and a "non-information" resource dependent on the type of answer given by the server to a "GET" request: