The identification of resources in the Web via URIs [add ref] may not be sufficient to uniquely resolve a document as other factors might come into play like HTTP content negotiation according to pre-defined user characteristics. This issue is particularly important for conformance testing, conformance claims and reporting languages like the Evaluation and Repair Language (EARL, add ref) when they address Web resources. This document describes a representation of HTTP concepts in RDF that will serve to the purpose mentioned earlier, as it can allow the identification of resources served via the HTTP protocol. The proposed vocabulary also includes some extensions to HTTP outside the standard RFCs.

[Note] Shall be mention HTTPS here?

Status of this document

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/.

More things to be added later ...

Table of Contents

To be defined at a later stage ...

1 Introduction

This note presents an RDF representation of the HTTP headers that can support the unique identification of Web resources when the sole use of an URI [add ref] may not suffice due to common content negotiation techniques used by most browsers nowadays. It also will help to identify complex Web resources like form responses, which need, for example, information on the POST request used and the sent parameters. This document is not intended to be a clarification of the different concepts of the HTTP specification [RFC2616].

[Note] Use cases discussion? E.g., EARL, conformance claims, Web Services in the Semantic Web, ...

2 HTTP/1.1 classes and properties

In this document we refer to version 1.1 of HTTP. Section 3 refers to common extensions used in the Web, and how they can be incorporated into the vocabulary. As defined in [RFC2616], The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP is a request/response protocol, and therefore, the basic classes represent this structure message format [RFC822]:

2.1 The Request class

The Request class represents an HTTP request. There are eight subclasses derived from the Request class, one for each request type defined in [RFC2616]:

2.1.1 The Request properties

The following properties may appear in nodes of type Request:

2.2 The Response class

The Response class represents an HTTP response as defined in [RFC2616].

2.2.1 The Response properties

The following properties may appear in nodes of type Response:

2.3 The header property

The header property represents an HTTP header. There is a property derived from the header property for every header defined in [RFC2616]. The following properties may appear in nodes of type Request:

The following properties may appear in nodes of type Response:

The following properties may appear in nodes of type Request or Response:

2.4 The body property

The body property represents an HTTP entity body. It can appear in nodes of both type Request or Response. HTTP bodies are series of bytes, thus we need to translate that to a string of text with a given encoding to make it representable in RDF. The body is then represented by an anonymous Resource with two properties:

2.5 Namespaces


3 Extensions to HTTP

There are quite a lot of headers widely used in HTTP, which are not defined in the HTTP/1.1 specification itself. The following extension properties may appear in nodes of type Request:

The following extension properties may appear in nodes of type Response:

3.1 The additionalHeader property

For headers not defined in HTTP/1.1 or any of the previous extensions, you can use the additionalHeader property. The object of this property is of type Field.

3.2 The Field class

The Field class represents a field defined in [RFC822], and should be in a different namespace. It can have the following properties:

4. Example

<?xml version="1.0" encoding="utf-8"?>
  <earl:WebContent rdf:about="http://www.example.org/">
        <http:accept>text/html;q=1.0, */*;q=0.01</http:accept>
        <http:acceptLanguage>de-DE;q=1.0, de;q=0.75, en-GB;q=0.5, en;q=0.25, *;q=0.01</http:acceptLanguage>
        <http:vary>negotiate, accept, accept-language</http:vary>
        <http:body rdf:parseType="Resource">

5. RDF Schema

To be added later ...


Persistent client state HTTP cookies – Netscape Preliminary Specification
"The Platform for Privacy Preferences 1.0 (P3P1.0) Specification" – Lorrie Cranor, Marc Langheinrich, Massimo Marchiori, Martin Presler-Marshall, Joseph Reagle, W3C Recommendation, 16 April 2002.
"Resource Description Framework (RDF): Concepts and Abstract Syntax" – Graham Klyne, Jeremy J. Carroll, W3C Recommendation, 10 February 2004.
"Standard for ARPA Internet Text Messages" – David H. Crocker, August 13, 1982.
"Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field" – R. Troost, S. Dorner, K. Moore, August 1997.
"Transparent Content Negotiation in HTTP" – K. Holtman, A. Mutz, March 1998.
"Hypertext Transfer Protocol -- HTTP/1.1" – R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, L. Masinter, P. Leach and T. Berners-Lee, June 1999.
"HTTP State Management Mechanism" – D. Kristol, L. Montulli, October 2000.