The URI Query Agent Model A Semantic Web Enabler

Overview

As the Semantic Web emerges and the behavior of automated software becomes increasingly directed by explicit knowledge about resources, gathered from disparate sources, the need for a standardized means of sharing authoritative knowledge about a given resource, based solely on the URI denoting that resource, becomes critical to achieving a fully open, global, scalable, and ubiquitous Semantic Web.

URIQA (URI Query Agent) is a model for knowledge discovery, both from authoritative sources as well as from arbitrary third party sources. It introduces an extension to the present web architecture used to indicate to a web server that it should resolve the specified URI in terms of knowledge about the resource denoted by that URI rather than in terms of a representation of the resource in question.

URIQA employs a particular form of resource description called a concise bounded description. A concise bounded description of a resource is a general and broadly optimal unit of specific knowledge about that resource to be utilized by, and/or interchanged between, semantic web agents.

Concise bounded descriptions are defined in the W3C Member Submission http://www.w3.org/Submission/CBD/.

Extending the Web Architecture

Semantic Web Methods for HTTP

URIQA extends the present web architecture by introducing the following new HTTP methods for interacting with an authoritative semantic web enabled web server:

MGET	Return a concise bounded description of the resource denoted by the request URI. E.g. MGET /foo HTTP/1.1 Host: example.com I.e. Get a description of the resource denoted by <http://example.com/foo>.
MPUT	Add the statements contained in a concise bounded description of the resource, provided as input, to the (possibly empty) body of knowledge maintained about the resource denoted by the request URI. E.g. MPUT /foo HTTP/1.1 Host: example.com I.e. Add statements to the description of the resource denoted by <http://example.com/foo>.
MDELETE	Remove the statements contained in a concise bounded description of the resource, provided as input, from the existing knowledge maintained about the resource denoted by the request URI. If no description is provided as input, remove all statements asserted about the specified resource. E.g. MDELETE /foo HTTP/1.1 Host: example.com I.e. Delete statements from the description of the resource denoted by <http://example.com/foo>.

The URIQA Semantic Web Service Interface

In addition to the methods described above, the URIQA model also defines a simple semantic web service interface providing for access to descriptions of resources by third parties other than the web authority of the URI denoting the resource and/or for resources denoted by URIs which are not meaningful to the HTTP protocol.

All URIQA service implementations must provide support for the following parameters:

Method	Parameter	Value	Description
GET, POST	uri	<URI>	The URL encoded URI denoting the resource described.
POST	method	MGET, MPUT, or MDELETE	The URIQA method to be applied.

Input resource descriptions should be provided to POST requests as the request body, as appropriate.

E.g.:

GET /uriqa?uri=http%3a%2f%2fexample%2ecom%2fblargh HTTP/1.1
Host: example.com

Retrieve from example.com a description of the resource denoted by <http://example.com/blargh>.

POST /uriqa?uri=http%3a%2f%2fwidgets%2eorg%2ffoo%23bar&method=MGET HTTP/1.1
Host: example.com

Retrieve from example.com a description of the resource denoted by <http://widgets.org/foo#bar>.

Note: it is recommended that GET normally be used to retrieve resource descriptions so that bookmarking and similar operations can be employed.

POST /uriqa?uri=urn%3aissn%3a1560%2d1560&method=MPUT HTTP/1.1
Host: example.com

Add statements to the description maintained by example.com of the resource denoted by <urn:issn:1560-1560> (manditory description provided as request body).

POST /uriqa?uri=uuid%3a438c44e9%2d6b2f%2d11d7%2d944a%2d006097b1ebc&method=MDELETE HTTP/1.1
Host: example.com

Remove statements from the description maintained by example.com of the resource denoted by <uuid:438c44e9-6b2f-11d7-944a-006097b1ebc> (optional description provided as request body).

Note that the particular name of the web service is not mandated, but for the sake of consistency, '/uriqa' is recommended.

URI References with Fragment Identifiers

URI references which contain fragment identifiers are problematic in a semantic web environment where the precise form of the URI must be preserved during interchange to ensure correct interpretation. Many software applications, gateways, proxies, and other intermediaries may discard the fragment identifier portion of an HTTP request URI, resulting in miscommunication between two semantic web agents which are communicating with one another via HTTP.

E.g., a URIQA request such as

MGET /foo#bar HTTP/1.1
Host: example.com

can arrive at the authoritative server as

MGET /foo HTTP/1.1
Host: example.com

hence being misunderstood as a request for a description of an entirely different resource than was intended by the requesting agent.

As a workaround for this special case, it is recommended that when submitting a URIQA request where the request URI contains a fragment identifier, the full URI should be redundantly specified using the special HTTP message header URIQA-uri:

E.g.

MGET /foo#bar HTTP/1.1
Host: example.com
URIQA-uri: http://example.com/foo#bar

A URIQA enlightened server must check for the presence of the URIQA-uri: header. If a URIQA-uri: header value is specified, and if the request URI constitutes the base URI of the header specified URI, then the server should presume that the header specified URI denotes the intended target of the request and that the fragment identifier was lost from the request URI during transit, and should use the header specified URI when processing the request.

Thus, the following requests, as received by a URIQA enlightened server, are all equivalent:

MGET /foo#bar HTTP/1.1
Host: example.com

MGET /foo HTTP/1.1
Host: example.com
URIQA-uri: http://example.com/foo#bar

MGET /foo#bar HTTP/1.1
Host: example.com
URIQA-uri: http://example.com/foo#bar

All three requests should result in the server attempting to return a description of the resource denoted by the URI <http://example.com/foo#bar>.

Descriptions as Fall-Back Representations

A URIQA enlightened server should attempt to provide a description of a resource when a general GET request fails. This is particularly important for resources which are denoted by http: URIs but which may have no (other) web-accessible representations, such as vocabulary terms, abstract concepts, physical entities, etc.

The Nokia URIQA semantic web service is implemented as an RDF Gateway Package. This service constitutes the backbone of the Nokia Semantic Web Server, and also provides a reference implementation demonstrating the correct behavior of a URIQA enlightened server. The Nokia implementation may be downloaded and used free of charge, in accordance with the terms specified.

Nokia URIQA Service Extended Parameters

In addition to the required parameters for all URIQA semantic web services, the Nokia URIQA service also supports the following additional parameters, which are relevant for GET requests:

Parameter	Value *	Description
format	application/rdf+xml	Return RDF statements serialized as RDF/XML. [default]
	text/html	Return RDF statements presented as browseable HTML.
	application/rdf-facets	Return RDF statements presented as RDF Index Facets.
naming	label	When format is HTML, use labels, titles, or localname suffixes in place of complete URIs. [default]
	uri	When format is HTML, use URIs to denote resources.
inference	exclude	Only explicitly asserted statements are returned. No inference is performed. [default]
	include	All explicitly asserted statements, as well as statements inferable by select rules are returned.

^* All service parameter values must be URL encoded as appropriate.

Frequently Asked Questions

Why not use a link in the representation to provide the URI via which the description can be accessed?

First, this requires that you download the entire representation to get to that link, which is simply inefficient. Secondly, the insertion of the link would be encoding specific and not all encodings facilitate such links. Thirdly, the solution would not be consistent across all encodings, and for each new encoding, yet another way to embed/encode that link would have to be devised. Finally, it precludes processing of descriptions by agents who do not support the particular encodings yet can still operate on RDF/XML descriptions.

Why not have a standardized suffix, prefix, or other URI transformation that allows one to derive from a resource URI another URI via which the resource description can be accessed?

Such an approach both violates the sanctity of the web authority's URI space, since an agent has no way of knowing whether the web authority subscribes to such a transformation. It also violates the principle of URI opacity. Finally, such a transformation would have to work with any URI scheme whatsoever, which may very well not be feasible.

Why not just use a special header to indicate that you want a description rather than some other form of representation?

If the header is not understood by the server, then it may provide a response which appears to be successful but is not a description. In the case of a resource which has a default representation encoded as RDF/XML, it may not be clear even upon examination of the response that a misunderstanding has occurred. And that response may also be exceptionally large, such as in the case where the agent asks for a description of an MPEG4 encoding of a full-length motion picture, but because the server does not understand the special header, returns the entire 1.2GB MPEG4 video stream.

Furthermore, in the case of PUT and DELETE, use of a special header to capture the same semantics as defined for MPUT and MDELETE would change the semantics of PUT and DELETE in a way that is unlikely to be considered acceptable, as MPUT and MDELETE can be used to (partially) modify a resource description and have no affect on the state (or representation of the state) of the resource itself.

Why not use a MIME type and content negotiation to request a description?

Content negotiation is designed to allow agents to select from among a set of alternate encodings. The distinction between a resource description and (other kind of) resource representations is not based on any distinction in encoding. In fact, a given description (which is itself a resource) may have several available encodings (RDF/XML, XTM, N3, etc.). Thus, if you use content negotiation to indicate that you want a description, you can't use it to indicate the preferred encoding of the description (if/when other encodings than RDF/XML are available).

Why not first use a HEAD request to get another URI via which the description can be accessed?

Firstly, this requires an agent to make two requests to the server, rather than just one, which is inherently inefficient. Secondly, while each description is a resource in its own right and can be denoted by a distinct URI, it is seldom necessary to give descriptions distinct identity and therefore unnecessarily burdensome to require that every description of every resource be given an explicit URI simply in order to be able to access a resource's description.

Why not use DDDS (DNS) to get another URI via which the description can be accessed?

While DDDS would be more efficient than the HEAD request approach above, it adds yet another architectural layer into the mix, and it is unclear at this point whether or not that introduces additional challenges, particularly in areas of configuration, management, and security. While this approach should be explored further, at present it does not appear to offer a better solution to the present URIQA methods. It also shares a shortcoming with the HEAD request approach in that it requires all descriptions to be given an explicit identity, which in most cases is unnecessary management overhead.

Why not use OPTIONS to get the URI of a service/portal via which the description can be accessed?

This is a slightly better variant of the HEAD request approach, in that (a) the OPTIONS request is relevant to an entire web authority, and with caching, means that even if the request is being made frequently for many resources denoted by URIs grounded in that web authority, there is not as significant an efficiency hit as for the same number of HEAD requests (which even if cached may only be made once each), and (b) an agent may choose to keep track of the service URI provided by the OPTIONS request response and thus forego additional requests to the same web authority. Of all of the alternative approaches to URIQA as presently defined, this approach has the greatest merit. Nevertheless, it presumes that resource descriptions will always be centrally managed by some web service, and limits the freedom of web authorities from deciding how best to provide resource descriptions. The present URIQA design imposes no implementation constraints whatsoever.

Why not use OPTIONS to get the definition of a regular transformation to apply to the resource URI in order to generate another URI via which the description can be accessed?

This is a variant of the OPTIONS approach above which does not violate the sanctity of the web authority's namespace as would a more general syntactic transformation, as each web authority is free to specify their own transformation as they see fit. It shares, though, the shortcomings of the other OPTIONS approach in that it incurs multiple requests and requires explicit identity of all descriptions. It also has the additional drawback of placing both a greater implementational burden as well as a heavier runtime burden on clients in that they will have to be able to apply the transformations locally. Such concerns are particularly relevant for mobile clients.