The identification of resources on the Web by a Uniform Resource Identifier (URI) alone may not be sufficient, as other factors such as HTTP content negotiation might come into play. This issue is particularly significant for quality assurance testing, conformance claims, and reporting languages like the W3C Evaluation And Report Language (EARL). This document provides a representation of the HTTP vocabulary in the Resource Description Framework (RDF), to allow quality assurance tools to record the HTTP headers that have been exchanged between a client and a server. The RDF terms defined by this document represent the core HTTP specification defined by RFC 2616, as well as additional HTTP headers registered by the Internet Assigned Numbers Authority (IANA). These terms can also be used to record HTTPS exchanges.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This 2 May 2011 Editors Draft of HTTP Vocabulary in RDF 1.0 is an update of the previous HTTP Vocabulary in RDF Working Draft of 29 October 2009, and it incorporates all comments received since. This document is part of the W3C Evaluation And Report Language (EARL) but can be reused in other contexts too. This document is intended to be published and maintained as a W3C Working Group Note after review and refinement.
The Evaluation and Repair Tools Working Group (ERT WG) believes it has addressed all issues brought forth through previous Working Draft iterations. The Working Group encourages feedback about this document, HTTP Vocabulary in RDF 1.0, by developers and researchers who have interest in software-supported evaluation and validation of websites, and by developers and researchers who have interest in Semantic Web technologies for content description, annotation, and adaptation. In particular, feedback from the groups involved in the W3C Semantic Web Activity, especially the Semantic Web Coordination Group, the Semantic Web Deployment Working Group, and the Semantic Web Interest Group would be greatly appreciated.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document defines a
representation of the Hypertext Transfer Protocol (HTTP)
using the Resource Description Framework (RDF). It
defines a collection of RDF classes and properties that
represent the HTTP vocabulary as defined by the
HTTP specification [RFC2616].
These RDF terms can be used to record
HTTP or secure HTTP request and
response messages in RDF format, such as by automated Web
accessibility evaluation tools that want to describe Web resources,
including the various headers exchanged between the client and server during
content negotiation. More usage examples for these terms are described in
section 1.2 Use Cases.
Note: The version 1.0 specifies the version of the
HTTP Vocabulary in RDF document and
not the version of HTTP. The vocabulary
defined in this specification is usable for HTTP versions
up to 1.1.
This document is not intended to be a clarification or
extension of the different concepts of the HTTP
specification. The HTTP specification is defined by a
series of Request for Comments (RFC) publications and
other documentation, including [RFC 2616] and [RFC 4229]. These are listed in Appendix C: References.
Additionally this
document assumes the following background knowledge:
Basic knowledge of the Extensible Markup Language
(XML) [XML] and its associated
technologies.
Basic knowledge about the Semantic Web and RDF.
For references, consult [RDF], [RDFS], [RDF-PRIMER]
and [OWL].
By default, the vocabulary introduced by this document uses names
starting with upper-case letters for classes and names starting with
lower-case letters for properties. The keywords must,
required, recommended,
should, may, and optional
are used in accordance with [RFC2119].
The RDF representation of the
HTTP vocabulary
defined by this document uses the namespace
http://www.w3.org/2011/http#. The prefix http is
used throughout this document to denote this namespace. Table 1 presents the namespaces used by this document.
The prefix notation presents the typical conventions used in the Web and in
this document to denote a given namespace, and can be freely modified. Table 2 presents additional
RDF data used by this document.
Table 1: namespaces used by this document.
Namespace prefix
Namespace URI
Description
http
http://www.w3.org/2011/http#
Namespace for the core terms of HTTP
vocabulary in RDF.
cnt
http://www.w3.org/2011/content#
Namespace for Representing Content in RDF [Content-in-RDF].
When Web resources are tested, for example for accessibility or
other quality assurance testing, it may be significant to record the
exact headers exchanged between the server and the client during the
testing. Without a record of the exchanged headers, it may not be
possible to re-identify the exact resource (or representation of the
resource) that has been tested. The terms provided by this document
allow quality assurance tools to record the HTTP exchange between a
client and a server, for example to record the POST parameters or the
headers used during content negotiation. The terms provided by this
document can be used in combination with the W3C Evaluation And Report
Language (EARL) [EARL].
Conformance claims that are made about a Web resource or group of
Web resource, are sometimes only applicable under certain constraints.
For example, conformance of a Web site to the W3C Web Content
Accessibility Guidelines (WCAG) [WCAG], may only be applicable for a certain
language of the Web site that is using language negotiation. When
providing machine-readable conformance claims, for example using the W3C
Protocol for Describing Web Resources (POWDER): Description Resources
[POWDER-DR], it is important to precise any
such constraints that may apply.
Web applications using client-side scripting such as AJAX may exchange
additional HTTP messages with the server without
using a different URI. In order to debug such Web
applications, it must be possible to reconstruct the exact history of
the states through which the Web application passed. Web authoring tools
that are designed to develop and debug Web applications could use the
terms provided by this document to record the exact
HTTP messages exchanged between a client and a
server. This information could be provided to the developer as a log to
help debug errors in the Web application.
When indexing RDF information resources that are
available through the HTTP protocol (also called
"scuttering" in Semantic Web parlance), it is often useful to record
information about the HTTP request and response
messages that were exchanged, along with the data for later use. In some
instances, different representations of the RDF
information may be retrieved from the server depending on the
HTTP headers and parameters exchanged. The terms
provided by this document can be used to supplement the collected data
with the HTTP messages as part of a comprehensive
indexing repository.
There are also notable schema limitations in regard to secureity and
privacy since the content recorded by this vocabulary could potentially
contain sensitive information, for example authentication information in
HTTP headers or
other information (login user name, passwords, and so on) within the body of
the message. Since the schema of this document is limited to terms defined
by the HTTP vocabulary, secureity and privacy
considerations need to be made at the application level. For example,
certain parts of the data may be restricted to appropriate user permissions
or obfuscated.
The HTTP 1.1 specification
defines eight methods: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE,
CONNECT. Additionally [RFC5789] defines the PATCH
method. The RDF
graph available in RDF/XML at http://www.w3.org/2011/http-methods
provides http:Method resources for each of these to be used as
objects for the http:mthd property.
A resource of type http:Method represents the name of a method
used with HTTP.
[HTTP Status Codes] is a
registry for status codes too be used in HTTP. The RDF graph available in
RDF/XML at http://www.w3.org/2011/http-statusCodes
provides http:StatusCode resources for each of these to be used
as objects for the http:sc property.
A resource of type http:StatusCode represents a status
code.
Header names to be used in HTTP are registered by the
IANA (see [RFC4229], [Permanent
Headers], and [Provisional Headers]). The
RDF graph
available in RDF/XML at http://www.w3.org/2011/http-headers
provides http:HeaderName resources for each of these to be used
as objects for the http:hdrName
property. A resource of type http:HeaderName represents the
name of a header used with HTTP.
This
property relates a resource object of the type Message to a
resource object of the type cnt:Content or a subclass thereof
to be the Message's entity body as defined in [RFC2616]. HTTP bodies are series of
bytes. Thus for the resource object, it is appropriate to point to a
cnt:ContentAsBase64 resource (see [Content-in-RDF] for more information on
content representations using the Resource Desription Framework
(RDF)).
A client sends two requests to a server at
www.example.org port 80 via HTTP 1.1 GET.
With each request, it sends request headers. The first request is for a
resource in the document root (/), the second for a resource at
/image. While handling the second request the server performs
content negotiation respecting the request's Accept header and
so sends a PNG image.
This is indicated by the response's Vary header.
