RDF Assertions over HTTP

This note describes a simple pattern for naming assertion-encoding parameters passed via HTTP GET and POST methods from Web client to server. While HTTP POST should always be used in cases where changes wil be caused in the server, it is likely this this pattern will nevertheless find us in HTTP GET URIs, for example to allow Javascript 'bookmarklets' to solicit Web annotations from users.

The Problem

The use of named parameters as a data-transport between Web clients and servers is commonplace. The HTTP, CGI and HTML specs(?) together provide a simple framework by which UI elements in the client can solicit data from users and send this via HTTP to a server. Unfortunately there are no widespread conventions in place for documenting the meaning of these parameters. This note does not present a general solution to this problem. Instead, we propose a pattern for naming parameters in such as a way as to allow them to encode simple RDF assertions about a Web resource. The intended application is for Web rating services to have a mechanism for decoding a variety of end-user assertions and annotations without explicit advance knowledge of the rating vocabularies in use.

Motivating Examples

The following are simple assertions which a user might make about a Web page while surfing. The aim here is to find a common mechanism for unambiguously encoding these for transport to a generic ratings bureau (which may for example use additional authentication information to determine the agency making the assertion(s)).

Informally...
  1. I recommend this page
  2. I dislike this page
  3. I recommend this page; it is about cars
  4. I recommend this page; here is my description of it
Formal RDF Statements

For some page 'http://somepage/'

  1. < rdf:Description rdf:about="http://somepage/" xmlns:rdf="http://www.w3.org/TR/1999/02/rdf-syntax"
    	xmlns:ratings="http://rdf.desire.org/ratings/" >
      	<ratings:likeOrNot rdf:resource="http://rdf.desire.org/ratings/like"/>
    </rdf:Description>
    
    
  2. < rdf:Description rdf:about="http://somepage/" xmlns:rdf="http://www.w3.org/TR/1999/02/rdf-syntax"
    	xmlns:ratings="http://rdf.desire.org/ratings/" >
      	<ratings:likeOrNot rdf:resource="http://rdf.desire.org/ratings/dislike"/>
    </rdf:Description>
    
    
  3. < rdf:Description rdf:about="http://somepage/" xmlns:rdf="http://www.w3.org/TR/1999/02/rdf-syntax"
    	xmlns:ratings="http://rdf.desire.org/ratings/" >
      	<ratings:likeOrNot rdf:resource="http://rdf.desire.org/ratings/like"/>
    	<dc:Subject rdf:resource="http://vocab.org/topics/Cars"/>
    </rdf:Description>
    
    
  4. < rdf:Description rdf:about="http://somepage/" xmlns:rdf="http://www.w3.org/TR/1999/02/rdf-syntax"
    	xmlns:ratings="http://rdf.desire.org/ratings/" >
      	<ratings:likeOrNot rdf:resource="http://rdf.desire.org/ratings/like"/>
    	<dc:Description> This is a wonderful document, giving a history of cars from 1920 to the present day
    	</dc:Description>
    </rdf:Description>
    
    
As attribute/value parameters

There is an infinite number of ways in which this data could be flattened into the attribute value pairs typically used to transport HTML FORM data to servers. The aim here is to encode simple RDF assertions about a single resource in such a way as to preserve the URI information, as well as other facts such as whether the value of a statement is a URI reference or an atomic ('literal') value. If this information can be encoded in a predicatable manner, server-side services can re-construct the RDF statements made at the client.

Note: web applications should not use HTTP GET for transporting data which will cause changes in the state of server-side objects. In this case we violate this rule when describing how a 'bookmarklet' or bookmarkable Javascript fragment can be used to encode templates for RDF statements such as those above.

The following shows one way of encoding the statements shown above in attribute/value form.

  1. ns = rdf::http://www.w3.org/TR/1999/02/rdf-syntax
    ns = ratings::http://rdf.desire.org/ratings/
    subject = http://somepage/
    ratings::likeOrNot = ratings::like
    
    
  2. ns = rdf::http://www.w3.org/TR/1999/02/rdf-syntax
    ns = ratings::http://rdf.desire.org/ratings/
    subject = http://somepage/
    ratings::likeOrNot = ratings::dislike
    
    
  3. ns = rdf::http://www.w3.org/TR/1999/02/rdf-syntax
    ns = ratings::http://rdf.desire.org/ratings/
    ns = useful::http://vocab.org/topics/
    subject = http://somepage/
    ratings::likeOrNot = ratings::like
    dc::Subject = useful::Cars
    
    
  4. ns = rdf::http://www.w3.org/TR/1999/02/rdf-syntax
    ns = ratings::http://rdf.desire.org/ratings/
    ns = useful::http://vocab.org/topics/
    subject = http://somepage/
    ratings::likeOrNot = ratings::like
    dc::Subject = useful::Cars
    dc""Description = This is a wonderful document, giving a history of cars from 1920 to the present day
    sitemap__isPartOf = ../../index.html
    
    
Definitions

The examples shown above give an informal overview of what is possible. Slightly more formally, here is what is going on...

The encoding mechanism is built around a notion of abbreviated names for RDF vocabularies, each of which is specified unambiguously through use of a URI (Uniform Resource Identifier). The 'ns' attribute is used (repeatedly) to associate a short name with each RDF vocabulary URI. The (repeatable) 'subject' attribute specifies the URI of (one or more) Web resources that are the subject of the encoded RDF statements. The remainder of the attributes are considered to encode RDF statements about that resource only when their names match one of the following patterns:
i) {shortname}::name
Both the RDF property and the value of that property consist of a local name (to the right of the '::') and a namespace-identifying short name (before the '::').

ii){shortname}__name
The value in this case is a RDF resource URI. This may be a relative URI such as '../../news.txt'. The property identifier is encoded as above, using '__' instead of '::' to signify the differing syntax used in the value.

iii){shortname}::name
As above, except the different separate character signifies that the value of the statement encoded in this way is an atomic (literal) string.


Author: Dan Brickley