[contents]
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 such as the 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 8 September 2009 Editors Draft [@@ September 2009 Working Draft] of HTTP Vocabulary in RDF 1.0 is an update of the previous HTTP Vocabulary in RDF Working Draft of 8 September 2008, and addresses the comments received since (see history of document changes). 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 to have addressed all issues brought forth through previous Working Draft iterations. The Working Group encourages feedback about this document, HTTP Vocbulary in RDF 1.0, by developers and researchers who have interest in software-supported evaluation and validation of Web sites, and by developers and researchers who have interest in Semantic Web technologies for content description, annotation, and adaptation. In particular, the Working Group is looking for final feedback on the proposed classes and properties to help record HTTP exchanges between clients and servers for any purpose.
Please send comments on this HTTP Vocabulary in RDF 1.0 document by [@@ October 2009] to public-earl10-comments@w3.org (publicly visible mailing list archive).
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 has been produced by the Evaluation and Repair Tools Working Group (ERT WG) as part of the Web Accessibility Initiative (WAI) Technical Activity.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. 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. 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.3. Use Cases.
This document is part of the Evaluation and Report Language (EARL) suite of specifications. Other parts of EARL include:
The Evaluation and Report Language (EARL) Overview provides a brief introduction to EARL.
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.
Note: The version number "1.0" in the document title specifies the version of this 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.
[Editor's note: The working group asks for comments about potential confusion because of the versioning.]
The assumed audience of this specification is developers who are implementing EARL in software or processes, or those who want to reuse the ideas, models, or properties and classes in this HTTP Vocabulary in RDF document for other purposes. Readers who would like more introductory material on implementing EARL are referred to the Evaluation and Report Language (EARL) 1.0 Guide.
This document assumes that the reader is familiar with the Resource Description Framework (RDF) and can read its XML serialization. Readers who wish to understand more about RDF should read a general introduction or the RDF Primer [RDF-PRIMER].
The keywords must, required, recommended, should, may, and optional in this document are used in accordance with RFC 2119 [RFC 2119].
The RDF representation of the vocabulary defined by this document uses the namespace http://www.w3.org/2006/http#. The prefix http is used throughout this document to denote this namespace. Other prefixes used throughout this document include:
cnt - Representing Content in RDF namespace http://www.w3.org/2008/content# (defined by [Content])dct - Dublin Core (DC) namespace http://purl.org/dc/terms/ (defined by [DC])rdf - RDF namespace http://www.w3.org/1999/02/22-rdf-syntax-ns# (defined by [RDF])
In addition to the above namespaces, the following RDF data files are used by this document:
http://www.w3.org/2008/http-headers - HTTP headers as registered by the IANA (see [RFC4229], [Permanent Headers], and [Provisional Headers])http://www.w3.org/2008/http-methods - HTTP methods for requestshttp://www.w3.org/2008/http-statusCodes - HTTP status codes for responses
The following (non-exhaustive) list of use cases aims to highlight some of the different usages of the terms provided by this document:
- Reporting Test Results
- 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].
- Precising Conformance Claims
- 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 provding 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.
- Debugging Web Applications
- 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 bewteen a client and a server. This information could be provided to the developer as a log to help debug errors in the Web application..
- Indexing Information Resources
- 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 paramters 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 with regards to security 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, security 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.
This section defines RDF classes for the HTTP 1.1 specification according to [RFC2616].
A connection that is used for the HTTP transfer.
- Domain of:
- Range of: none
Example 2.1: A Connection resource.
<http:Connection rdf:ID="conn">
<http:connectionAuthority>www.example.org:80</http:connectionAuthority>
<http:requests rdf:parseType="Collection">
<http:Request rdf:ID="req0"/>
<http:Request rdf:ID="req1"/>
</http:requests>
</http:Connection>
An HTTP message.
- Domain of:
- Range of: none
It may be appropriate to provide additional information about the Message by using the following from external vocabularies:
dct:date 
- Message date (see the usage of this property in requests and responses).
Example 2.2: A Message resource.
<http:Message rdf:ID="mess0">
<http:httpVersion>1.1</http:httpVersion>
<dct:date>2007-09-13</dct:date>
<http:headers rdf:parseType="Collection">
<http:MessageHeader rdf:ID="mh0"/>
<http:MessageHeader rdf:ID="mh1"/>
</http:headers>
<http:body>
<cnt:Content rdf:ID="cont0"/>
</http:body>
</http:Message>
There are two subclasses from the http:Message class: http:Request and http:Response.
An HTTP request. The http:Request class is a subclass of the http:Message class.
- Domain of:
- Range of: none
The dct:date property when used in a Request resource represents the date the request was sent by the client.
Example 2.3: A Request resource.
<http:Request rdf:ID="reqs0">
<http:abs_path>/</http:abs_path>
<http:methodName>GET</http:methodName>
<http:mthd rdf:resource="http://www.w3.org/2008/http-methods#GET"/>
<http:resp rdf:resource="#resp0"/>
<dct:date>2007-09-13</dct:date>
<http:httpVersion>1.1</http:httpVersion>
<http:headers rdf:parseType="Collection">
<http:MessageHeader rdf:about="#mh0"/>
<http:MessageHeader rdf:about="#mh1"/>
</http:headers>
</http:Request>
An HTTP response. The http:Response class is a subclass of the http:Message class.
The dct:date property when used in a Response resource represents the date the response was received by the client.
Example 2.4: A Response resource.
<http:Response rdf:ID="resp0">
<http:httpVersion>1.1</http:httpVersion>
<dct:date>2008-01-11</dct:date>
<http:statusCodeNumber>200</http:statusCodeNumber>
<http:sc rdf:resource="http://www.w3.org/2008/http-statusCodes#statusCode200"/>
<http:headers rdf:parseType="Collection">
<http:MessageHeader rdf:about="#mh2"/>
<http:MessageHeader rdf:about="#mh3"/>
</http:headers>
<http:body>
<cnt:Content rdf:ID="cont0"/>
</http:body>
</http:Response>
A header in an HTTP message.
- Domain of:
- Range of: none
Example 2.5: A MessageHeader resource.
<http:MessageHeader rdf:ID="mh0">
<http:fieldValue>text/html, image/png, image/gif;q=0.8</http:fieldValue>
<http:fieldName>Accept</http:fieldName>
<http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#accept"/>
<http:headerElements rdf:parseType="Collection">
<http:HeaderElement rdf:about="#he0"/>
<http:HeaderElement rdf:about="#he1"/>
<http:HeaderElement rdf:about="#he2"/>
</http:headerElements>
</http:MessageHeader>
An element in a header value, if a Message Header value can be decomposed into several parts.
- Domain of:
- Range of: none
Example 2.6: A HeaderElement resource.
<http:HeaderElement rdf:ID="he0">
<http:elementName>image/gif</http:elementName>
<http:params rdf:parseType="Collection">
<http:Parameter rdf:ID="param0"/>
</http:params>
</http:HeaderElement>
A parameter in a Header Element.
- Domain of:
- Range of: none
Example 2.7: A Parameter resource.
<http:Parameter rdf:ID="param0">
<http:paramName>q</http:paramName>
<http:paramValue>0.8</http:paramValue>
</http:Parameter>
The HTTP 1.1 specification defines eight methods: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT. The RDF graph available in RDF/XML at http://www.w3.org/2008/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.
- Domain of: none
- Range of:
[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/2008/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.
- Domain of: none
- Range of:
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/2008/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.
Properties defined by this document:
- Domain of: none
- Range of:
This section defines RDF properties for the HTTP 1.1 specification according to [RFC2616].
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)).
- Domain:
http:Message- Range:
cnt:ContentAsBase64
Example 3.1: The entity body of a message.
<http:Message rdf:ID="mess0">
<http:body>
<cnt:ContentAsBase64 rdf:ID="cont0-bin"/>
</http:body>
</http:Message>
Connection authority - server host and port for a connection.
- Domain:
http:Connection- Range:
- Literal
Header element name (Literal).
- Domain:
http:HeaderElement- Range:
- Literal
Header element value (Literal).
- Domain:
http:HeaderElement- Range:
- Literal
Header name (Literal).
- Domain:
http:MessageHeader- Range:
- Literal
Header value (Literal).
- Domain:
http:MessageHeader- Range:
- Literal
HTTP headers sent with the message.
- Domain:
http:Message- Range:
- unspecified
Header value elements.
- Domain:
http:MessageHeader- Range:
- unspecified
This property relates a resource of type http:MessageHeader to a resource of type http:HeaderName.
- Domain:
http:MessageHeader- Range:
http:HeaderName
Property representing the HTTP version number as a Literal (the format is 'digit.digit').
- Domain:
http:Message- Range:
- Literal
HTTP method.
- Domain:
http:Request- Range:
http:Method
HTTP method name (Literal).
- Domain:
http:Request- Range:
- Literal
Header element parameters.
- Domain:
http:HeaderElement- Range:
- unspecified
Parameter name.
- Domain:
http:Parameter- Range:
- Literal
Parameter value.
- Domain:
http:Parameter- Range:
- Literal
Reason phrase sent by the server.
- Domain:
http:Response- Range:
- Literal
HTTP requests sent via the connection.
- Domain:
http:Connection- Range:
- unspecified
The request URI as specified in section 5.1.2 of [RFC2616]. This vocabulary defines the following sub-properties:
- Domain:
http:Request- Range:
- Literal
Example 3.2: The use of the requestURI property.
<http:Request>
<http:methodName>OPTIONS</http:methodName>
<http:requestURI>*</http:requestURI>
...
</http:Request>
Request URI that is an absolute URI.
Conformance Note: The object for this property must be a Literal (absolute URI).
Example 3.3: The use of the absoluteURI property.
<http:Request>
<http:methodName>GET</http:methodName>
<http:absoluteURI>http://www.example.org:80/foo/bar</http:absoluteURI>
...
</http:Request>
Request URI that is an absolute path.
Conformance Note: The object for this property must be a Literal (absolute path).
Example 3.4: The use of the abs_path property.
<http:Request>
<http:methodName>GET</http:methodName>
<http:abs_path>/foo/bar</http:abs_path>
...
</http:Request>
Request URI that is an authority.
Conformance Note: The object for this property must be a Literal (host and optional port number).
Example 3.5: The use of the authority property.
<http:Request>
<http:methodName>CONNECT</http:methodName>
<http:authority>www.example.org:80</http:authority>
...
</http:Request>
This property relates a resource of type http:Request to a resource of type http:Response.
- Domain:
http:Request- Range:
http:Response
This property relates a resource of type http:Response to a resource of type http:StatusCode.
- Domain:
http:Response- Range:
http:StatusCode
The status code sent by the server (Literal).
- Domain:
http:Response- Range:
- Literal
This section describes conformance with this HTTP-in-RDF specification. It differentiates between the following entities:
[Editor's note: The working group asks for comments about a more colloquial word for "HTTP-in-RDF Graph".]
- HTTP-in-RDF Graph
- An individual file or collection of files that contain HTTP-in-RDF data
- HTTP-in-RDF Producer
- A software tool or Web-based application that produces HTTP-in-RDF data
- HTTP-in-RDF Consumer
- A software tool or Web-based application that processes HTTP-in-RDF data
Graphs conforming to this HTTP-in-RDF specification must meet the following requirements:
- A Connection must have exactly one connection authority (specified by
http:connectionAuthority).
- A Connection may have one collection of Requests (referenced by
http:requests).
- A Message must have exactly one HTTP version (specified by
http:httpVersion).
- A Message may have one collection of Message Headers (referenced by
http:headers).
- A Message may have one message body (referenced by
http:body).
- A Message may have one date (specified by
dct:date ).
- A Request must have exactly one method name (specified by
http:methodName).
- A Request must have exactly one request URI (specified by
http:requestURI).
- A Request may be connected to one Method (referenced by
http:mthd).
- A Request may be connected to one Response (referenced by
http:resp).
- A Response must have exactly one status code number (specified by
http:statusCodeNumber).
- A Response must have exactly one reason phrase (specified by
http:reasonPhrase).
- A Response may be conected to one Status Code (referenced by
http:sc).
- A Message Header must have exactly one field name (specified by
http:fieldName).
- A Message Header must have exactly one field value (specified by
http:fieldValue).
- A Message Header may be connected to one Header Name (referenced by
http:hdrName).
- A Message Header may have one collection of Header Elements (referenced by
http:headerElements).
- A Header Element must have exactly one header element name (specified by
http:elementName).
- A Header Element may have one header element value (specified by
http:elementValue).
- A Header Element may have one collection of Parameters (referenced by
http:params).
- A Parameter must have exactly one parameter name (specified by
http:paramName).
- A Parameter must have exactly one parameter value (specified by
http:paramValue).
- The objects for the
headers property must be an RDF Collection of Message Headers.
- The objects for the
http:headerElements property must be an RDF Collection of Header Elements.
- The object for the
http:params property must be an RDF Collection of Parameters.
- The object for the
http:requests property must be an RDF Collection of Requests.
- Every instance of
cnt:ContentAsBase64 must conform with the respective specification.
Producers conforming to this HTTP-in-RDF specification must meet the following requirements:
- A Producer must generate conforming graphs
- A Producer must be able to generate graphs in RDF/XML serialization and should also support other RDF serializations
- A Producer must generate all of the terms summarized in Appendix B: Terms for which there is information available to it
Consumers conforming to this HTTP-in-RDF specification must meet the following requirements:
- A Consumer must process conforming graphs
- A Consumer must process graphs in any RDF/XML serialization and should also support other RDF serializations
- A Consumer must process all of the terms summarized in Appendix B: Terms for which there is information available to it
The following example shows an RDF/XML representation of an HTTP request and response pair.
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.
<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:http="http://www.w3.org/2006/http#"
xmlns:cnt="http://www.w3.org/2008/content#"
xmlns:dct="http://purl.org/dc/terms/">
<http:Connection rdf:ID="conn">
<http:connectionAuthority>www.example.org:80</http:connectionAuthority>
<http:requests rdf:parseType="Collection">
<http:Request rdf:about="#req0"/>
<http:Request rdf:about="#req1"/>
</http:requests>
</http:Connection>
<http:Request rdf:about="#req0">
<http:httpVersion>1.1</http:httpVersion>
<http:methodName>GET</http:methodName>
<http:mthd rdf:resource="http://www.w3.org/2008/http-methods#GET"/>
<http:abs_path>/</http:abs_path>
<http:headers rdf:parseType="Collection">
<http:MessageHeader>
<http:fieldName>Host</http:fieldName>
<http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#host"/>
<http:fieldValue>www.example.org</http:fieldValue>
</http:MessageHeader>
<http:MessageHeader>
<http:fieldName>User-Agent</http:fieldName>
<http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#user-agent"/>
<http:fieldValue>My User Agent</http:fieldValue>
</http:MessageHeader>
<http:MessageHeader>
<http:fieldName>Accept</http:fieldName>
<http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#accept"/>
<http:fieldValue>text/html, image/png, image/gif;q=0.8</http:fieldValue>
<http:headerElements rdf:parseType="Collection">
<http:HeaderElement>
<http:elementName>text/html</http:elementName>
</http:HeaderElement>
<http:HeaderElement>
<http:elementName>image/png</http:elementName>
</http:HeaderElement>
<http:HeaderElement>
<http:elementName>image/gif</http:elementName>
<http:params rdf:parseType="Collection">
<http:Parameter>
<http:paramName>q</http:paramName>
<http:paramValue>0.8</http:paramValue>
</http:Parameter>
</http:params>
</http:HeaderElement>
</http:headerElements>
</http:MessageHeader>
</http:headers>
<http:resp rdf:resource="#resp0"/>
</http:Request>
<http:Request rdf:about="#req1">
<http:httpVersion>1.1</http:httpVersion>
<http:methodName>GET</http:methodName>
<http:mthd rdf:resource="http://www.w3.org/2008/http-methods#GET"/>
<http:abs_path>/image</http:abs_path>
<http:headers rdf:parseType="Collection">
<http:MessageHeader>
<http:fieldName>Host</http:fieldName>
<http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#host"/>
<http:fieldValue>www.example.org</http:fieldValue>
</http:MessageHeader>
<http:MessageHeader>
<http:fieldName>User-Agent</http:fieldName>
<http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#user-agent"/>
<http:fieldValue>My User Agent</http:fieldValue>
</http:MessageHeader>
<http:MessageHeader>
<http:fieldName>Accept</http:fieldName>
<http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#accept"/>
<http:fieldValue>image/png, image/gif;q=0.8</http:fieldValue>
<http:headerElements rdf:parseType="Collection">
<http:HeaderElement>
<http:elementName>image/png</http:elementName>
</http:HeaderElement>
<http:HeaderElement>
<http:elementName>image/gif</http:elementName>
<http:params rdf:parseType="Collection">
<http:Parameter>
<http:paramName>q</http:paramName>
<http:paramValue>0.8</http:paramValue>
</http:Parameter>
</http:params>
</http:HeaderElement>
</http:headerElements>
</http:MessageHeader>
</http:headers>
<http:resp rdf:resource="#resp1"/>
</http:Request>
<http:Response rdf:ID="resp0">
<http:httpVersion>1.1</http:httpVersion>
<http:statusCodeNumber>200</http:statusCodeNumber>
<http:sc rdf:resource="http://www.w3.org/2008/http-statusCodes#200"/>
<http:reasonPhrase>OK</http:reasonPhrase>
<http:headers rdf:parseType="Collection">
<http:MessageHeader>
<http:fieldName>Date</http:fieldName>
<http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#date"/>
<http:fieldValue>.......</http:fieldValue>
</http:MessageHeader>
<http:MessageHeader>
<http:fieldName>Content-Type</http:fieldName>
<http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#content-type"/>
<http:fieldValue>text/html; charset=utf-8</http:fieldValue>
<http:headerElements rdf:parseType="Collection">
<http:HeaderElement>
<http:elementName>text/html</http:elementName>
<http:params rdf:parseType="Collection">
<http:Parameter>
<http:paramName>charset</http:paramName>
<http:paramValue>utf-8</http:paramValue>
</http:Parameter>
</http:params>
</http:HeaderElement>
</http:headerElements>
</http:MessageHeader>
</http:headers>
<http:body>
<cnt:ContentAsBase64 rdf:ID="cont0-bin">
<cnt:bytes rdf:datatype="http://www.w3.org/2001/XMLSchema#base64Binary"
>ajrq9qguojbglj48z..........</cnt:bytes>
</cnt:ContentAsBase64>
</http:body>
</http:Response>
<cnt:XMLContent rdf:ID="cont0-xml">
<dct:source rdf:resource="#cont0-bin"/>
<cnt:xmlLeadingMisc rdf:parseType="Literal"><!-- This is the start of the document -->
</cnt:xmlLeadingMisc>
<cnt:docTypeDecl>
<cnt:DocTypeDecl>
<cnt:dtdName>html</cnt:dtdName>
<cnt:publicId>-//W3C//DTD XHTML 1.0 Strict//EN</cnt:publicId>
<cnt:systemId rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI"
>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</cnt:systemId>
</cnt:DocTypeDecl>
</cnt:docTypeDecl>
<cnt:xmlRest rdf:parseType="Literal"><html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<title>My document</title>
</head>
<body>
<p><!-- ...... --></p>
</body>
</html></cnt:xmlRest>
</cnt:XMLContent>
<http:Response rdf:ID="resp1">
<http:httpVersion>1.1</http:httpVersion>
<http:statusCodeNumber>200</http:statusCodeNumber>
<http:sc rdf:resource="http://www.w3.org/2008/http-statusCodes#200"/>
<http:reasonPhrase>OK</http:reasonPhrase>
<http:headers rdf:parseType="Collection">
<http:MessageHeader>
<http:fieldName>Date</http:fieldName>
<http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#date"/>
<http:fieldValue>.......</http:fieldValue>
</http:MessageHeader>
<http:MessageHeader>
<http:fieldName>Content-Type</http:fieldName>
<http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#content-type"/>
<http:fieldValue>image/png</http:fieldValue>
</http:MessageHeader>
<http:MessageHeader>
<http:fieldName>Vary</http:fieldName>
<http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#vary"/>
<http:fieldValue>accept</http:fieldValue>
<http:headerElements rdf:parseType="Collection">
<http:HeaderElement>
<http:elementName>accept</http:elementName>
</http:HeaderElement>
</http:headerElements>
</http:MessageHeader>
</http:headers>
<http:body>
<cnt:ContentAsBase64>
<cnt:bytes rdf:datatype="http://www.w3.org/2001/XMLSchema#base64Binary"
>qouh3908t38hohfrf..........</cnt:bytes>
</cnt:ContentAsBase64>
</http:body>
</http:Response>
</rdf:RDF>
The following terms are defined by this specification:
Classes in the HTTP-in-RDF namespace
| Class name |
Label |
Comment |
Refinements |
Related properties |
http:Connection |
Connection |
A connection used for HTTP transfer. |
- |
http:connectionAuthority, http:requests |
http:Message |
Message |
An HTTP message. |
http:Request, http:Response |
http:httpVersion, dct:date, http:body, http:headers |
http:Method |
Method |
The HTTP method used for a request. |
- |
|
http:Parameter |
Parameter |
A parameter for a part of a header value |
- |
http:paramName, http:paramValue |
http:Request |
Request |
An HTTP request. |
- |
http:methodName, http:requestURI, http:mthd, http:resp |
http:Response |
Response |
An HTTP response. |
- |
http:statusCodeNumber, http:reasonPhrase, http:sc |
http:StatusCode |
Status Code |
The status code of an HTTP response. |
- |
|
- [Content-in-RDF]
- Representing Content in RDF - Johannes Koch, Carlos A Velasco (editors). W3C Working Draft 17 July 2008.
- [EARL]
- Evaluation and Report Language (EARL) Overview - W3C
- [HTTP Status Codes]
- "HTTP Status Code Registry" - IANA.
- [OWL]
- Web Ontology Language (OWL) Overview - W3C
- []
- Permanent Message Header Field Names - IANA.
- []
- Provisional Message Header Field Names - IANA.
- [POWDER-DR]
- Protocol for Web Description Resources (POWDER): Description Resources - P. Archer, K. Smith, A. Perego (editors). W3C Proposed Recommendation 04 June 2009.
- [RDF]
- Resource Description Framework (RDF) Overview - W3C
- [RDF-PRIMER]
- RDF Primer - Frank Manola, Eric Miller (editors). W3C Recommendation, 10 February 2004.
- [RDFS]
- RDF Vocabulary Description Language 1.0: RDF Schema - Dan Brickley, R.V. Guha (editors). W3C Recommendation 10 February 2004
- [RFC2119]
- Request for Comments (RFC): 2119. Key words for use in RFCs to Indicate Requirement Levels - IETF March 1997.
- [RFC2616]
- Hypertext Transfer Protocol -- HTTP/1.1 - R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, L. Masinter, P. Leach and T. Berners-Lee. IETF June 1999.
- [RFC4229]
- HTTP Header Field Registrations - M. Nottingham, J. Mogul. IETF December 2005.
- [WCAG]
- Web Content Accessibility Guidelines (WCAG) Overview - W3C.
- [XML]
- Extensible Markup Language (XML) 1.0 (Fifth Edition) - Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau (editors). W3C Recommendation 26 November 2008
The following is a list of substantial changes since the 8 September 2008 Working Draft:
- at most one
body property is allowed for Message resources; this property relates the message to Base64 encoded message content;
- several properties were renamed because their names differed from class names only by case:
headername (now hdrName), method (now mthd), response (now resp), statusCode (now sc);
- the
asterisk resource was removed in favour of the use of the Literal "*";
- the
StatusCodeGroup class was removed in favour of sub-classes of StatusCode;
- a section about conformance was added.