Current version: http://www.w3.org/1999/11/02-RDFServices/
Author: Dan Brickley <danbri@w3.org>
This is the first public draft of a discussion document for the RDF Interest Group. This document has no formal standing within W3C Process. If there is sufficient interest in the approach outlined here, future versions of this work might be published as W3C Notes. This document is a work in progress, and does not represent the activity of any chartered working group within W3C process.
Comments from the public on this document are invited and should (with the exception of minor editorial suggestions) be sent to the RDF Interest Group, www-rdf-interest@w3.org which is an automatically archived email list. Information on how to join the RDF Interest Group mailing list can be found on the group's home page.
This document is made available for discussion only. This indicates no endorsement by W3C of its content, nor that the Consortium has, is, or will be allocating any resources to the issues addressed by this document.
Editorial Note: while the broad outline of the RDF Description Services proposal is complete, this document currently fails to provide an adequately detailed specification for implementors. This early release of the document is being circulated for discussion within the RDF Interest Group, and should be considered incomplete and far from finalised.
Copyright ©1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document describes an application of W3C's RDF, the Resource Description Framework, to support a broad range of queryable Description Services on the Web. The approach adopted here is in essence a generalisation of the PICS Label Distribution Label Syntax and Communication Protocols, and describes a simple abstract model that applies in a number of common scenarios. The core functionality exhibited by RDF Description Services is the ability to provide RDF descriptions for URI-named entities in response to simple client requests. This document builds upon the RDF Schema, Model and Syntax specifications by describing a syntax-neutral convention for presenting RDF views of networked databases.
The Resource Description Framework (RDF) provides a highly general formalism for modeling structured data on the Web. In particular, the RDF Model and Syntax specification defines a graph-based data structure based around URI resource names, and an XML-based interchange format. Unlike PICS, the system RDF was designed to supercede, the core RDF specifications do not yet provide for any notion of a 'metadata bureau'. The RDF model specification notes that RDF descriptions may be associated with the resource(s) they describe in a number of ways. In particular:
[3.] The Description may be retrieved independently from the resource, including from a different source ("service bureau"; e.g. using HTTP GET).
There are a number of ways in which (meta)data describing some Web-identifiable resource may be found; this note specifies one such mechanism based upon a generalisation of the 'label bureau' protocol described in the PICS Label Distribution Label Syntax and Communication Protocols.
The mechanism described here provides a common interface to a variety of RDF services and can be characterised very simply as allowing an application to say to an RDF data source: "Tell me about the resource whose URI is [x]". Just as the PICS label bureau protocol allows a client application to request labels for some given URL, the services described here will provide RDF descriptions applicable to some specified URI-named resource.
RDF Description Services can be characterised very simply as networked services that can provide RDF models describing (some subset of) URI-named resources. Protocol-specific implementations (eg. HTTP-based services) require more specific characterisation, and may provide additional facilities such as content negotiation or data upload. This document describes the features common to all RDF Description Services, and outlines some likely extensions for HTTP-based implementations.
There are likely to be a number of different ways in which Web applications interact with services that use the RDF data model. The framework proposed here is only one component and is not proposed as the only possible machine-level interface to RDF data stores. Specifically, this note does not provide any notion of an RDF API, nor any system sophisticated enough to merit the label 'query language'. It would be advantageous if systems which provide RDF Description Services as outlined here could be extended to offer additional RDF Query or RDF API facilities as these become standardised. [ open issue ]
This note takes as given a context in which some client application has already identified a particular metadata server as a likely source of information concerning one or more objects of interest ('resources'). We do not address here a number of broader issues concerning 'label discovery' or 'query routing', except as discussed under 'seeAlso' below.
RDF Description Services can be used to expose descriptions of any entities (objects, resources, things) that can be identified using URIs. The URI specification (RFC 2396) provides a broad definition of resource as "anything that has identity". RDF's notion of a resource is a URI-identifiable entity.
Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources.
(excerpt from RFC 2396 section 1.1)
RDF Description Services can therefore provide a simple, unifying interface to a very broad range of resource descriptions.
The core functionality exhibited by RDF Description Services operating in accordance with these guidelines is the ability to provide RDF descriptions of one or more Web resources in response to a client request. As was the case with the PICS label protocol, this simple core does not provide for SQL-like selectivity regarding the detailed nature of the data stuctures returned. Although such facilities would be useful, there are many application scenarios that can be facilitated with an extremely simple 'describe this' mechanism.
The core model behind all RDF Description Services is extremely simple. The service is queried by providing it (through some more specific interface, eg. HTTP) with a (possibly relative) URI reference as defined in RFC 2396. The service responds by providing (through some specific interface and syntax or syntaxes) an RDF model providing a description of that URI-named resource and related resources. This document does not further constrain further the content or structure of this RDF description except to note that seeAlso statements may be used to provide hints as to further queries that may be useful.
The following motivating examples provide an illustration of the variety of networked data services that share a common interaction pattern: in each case, some service is asked about some (URI-named) resource.
While this document does not itself define a formal taxonomy for RDF Description Services, the examples below indicate a few sample categories that might be described using RDF to provide mechanically-processable service descriptions. Since RDF Description Services are expected to offer self-descriptions, RDF vocabularies which formalised these categories could support metadata service discovery applications.
Given the URI for a Web page or other resource, the Description Service would return a set of 3rd party annotations describing (eg. classifying, rating, recommending) it.
Given the URI for some concept in a controlled vocabulary scheme such as a thesaurus or library classification system, the Description Service would provide a description of that concept (most likely giving information about relationships to broader/narrower related concepts).
Given a URI for some abstract resource, perhaps representing a URN, DOI, handle or other identifier that does not encode resolution-hint semantics, a Description Service could return references to concrete manifestations of that resource on the Web. The service could also provide catalogue-like, versioning or rights related metadata alongside the resolution data.
A number of Web services offer quality controlled, library-like catalogues of Internet resources. Description Services associated with these could provide an RDF view of these databases. This can be considered a specialised type of annotation service.
Child protection applications could provide PICS-like content labels using RDF/XML instead of the older PICS 1.1 label syntax. Since RDF provides a model for intermingling multiple vocabularies, child protection metadata can be easily mixed with other data such as textual annotations, classifications etc.
Each of these examples could be implement using any machine interface to the appropriate RDF Description Service(s). These services can be seen as a mechanisation of an existing collection of 'page oriented' facilities. A number of Web-based systems offer HTML documents in response to URI-based queries. Further examples include: validators, spelling or grammar checkers, link checkers, back-link services, map viewers, restaurant reviews. In general, any HTML-based Web service that offers descriptions concerning objects that might be URI-named (eg. restaurants, films, compact discs, movies, web pages, postcodes...) could easily manifest an RDF service following the model outlined here.
A typical pattern of interaction with an RDF Description Service is for some client application to request an RDF description of one or more URIs. Note that the agencies playing a client role in a particular interaction may in other contexts manifest their own Description Service interfaces on the network. In other words, the mechanisms described here are applicable in server-to-server interactions; 'client' is a role that may be played by any software entity that can interact with RDF Description Services.
The following example scenario uses an HTTP-based interface to the service, specified more formally below.
Consider an RDF data provider, identified by the URI 'http://fiction.w3.org/bureau/', who decides to run a public Description Service to dispense labels and other annotations for a variety of Web resources. The following HTTP 1.1 GET request (which might be sent to the description server at fiction.w3.org) shows one way in which an RDF model describing some Web resource might be solicited:
GET /bureau?http%3A%2F%2Fsomesiteorother.com/ HTTP/1.1
Host: 127.0.0.1
The PICS 1.1 label bureau specification offers a similiar facility, and will respond to such a request with labels in the PICS 1.1 syntax. In the framework presented here, RDF's XML syntax is the default encoding for RDF models. Particular protocol interfaces to RDF Description Services (such as HTTP, below) may offer client applications the ability to express (for example using HTTP Content Negotiation) preferences about preferred data formats. In the simplest case, shown here, a URI is transmitted to a server and an RDF XML syntax response is returned to the querying client.
<?xml version="1.0"?>
<web:RDF
xmlns:web = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns = "http://purl.org/dc/elements/1.1/" >
<web:Description about = "http://somesiteorother.com/"
title = "Name of site here"
subject = "subject goes here..."
/>
</web:RDF>
The PICS specification distinguishes between 'generic' and 'specific' labels, and allows client applications to say which flavour of description they want. A generic label is true of all resources whose URI name shares a common base URI with the labelled 'generic' URI. A specific label describes only the resource whose URI matches exactly that used in the label.
This specification does not provide any mechanism for client applications
to request generic labels. The RDF specifications provides a simple
XML-syntax construct rdf:aboutEachPrefix which provides a compact
representation for RDF statements that apply to a collection of resources
sharing a common base URI. RDF does not define an RDF model representation for
the aboutEachPrefix mechanism.
It is often important to be clear about the agency or agencies making RDF assertions. RDF provides some machinery explicitly designed to help with this, by making it possible to 'reify' (or quote) RDF assertions, making RDF statements into describable entities. In many cases, an RDF Description Service will not need to make use of the reification mechnanism and will simply return unquoted assertions to client applications. Note that in this default case we do not say anything in the current document sufficient to specify the real-world agency that bears responsibility for the RDF statements returned by the description service. [open issue]
All RDF Description Services should be prepared to offer an RDF Description of themselves. In other words, a server whose URI is X, when asked for a description of X, should provide some RDF graph as a response. This document does not, however, constrain the content of this graph in any way. The Dublin Core Element Set may prove a useful base vocabulary appropriate for this task.
It is often the case that an RDF graph will need to contain statements that inform client applications about further descriptive resources on the Web that relate to the resource being described. The RDF Schema specification provides an 'seeAlso' property appropriate for this purpose. By using 'rdfs:seeAlso' we can provide hints to client applications about other description services available on the network.
For example, we might ask server-1 about resource-23 (http://server-1.fiction.w3.org/bureau?http://resource23.fiction.w3.org) and receive an RDF graph in response which tells us that 'http://resource23.fiction.w3.org/' has an 'rdfs:seeAlso' property whose value is the resource 'http://server-2.fiction.w3.org/bureau?http://resource23.fiction.w3.org/'. This tells us that further descriptive information may be available at the latter URI. This simple mechanism can be used to expose federated or query-routing structures amongst networks of RDF Description Servers. This facility does not define any means by which the descriptive capabilities of a given server can be determined.
Following the PICS 1.1 model, this note does not define any mechanism allowing RDF statements to be added to the graph managed by an RDF Description Server. These facilities may be available (for example, in an annotation bureau application) but are not defined here. An RDF Description Service may expose one or more protocol interfaces (eg. HTTP) to serve as a metadata bureau; other interfaces (eg. a more general RDF API) could offer facilities for adding new RDF assertions into the graph(s) managed by the server. For example, the service might also manifest itself as a PICS Label Bureau and honour the proposed 'PUT' method for PICS bureau.
The notion of a network-accessible interface to an RDF graph that answers 'tell me about this URI' queries is very general, and makes sense in a variety of contexts. We define here a simple HTTP GET interface and allude to a number of other ways in which this facility might be exposed to client applications.
[open issues: error handling -- HTTP codes applicable?]
In the simplest case, an RDF Description Service can expose a public interface using the HTTP GET method, where the URI name of the resource to be described is passed in using the GET query string.
[TODO] more formal specification goes here
[open issue: content negotiation]
[open issue: HTTP GET vs HTTP HEAD]
[open issue: cache control headers]
It should be possible to define interfaces to RDF Description Services in a variety of computing environments. For example, CORBA, or XML-RPC interfaces might be defined.
Detailed extensions to the basic framework outlined here may depend on the particular facilities offered by implementation environments such as HTTP.
[open issue: Future versions of this document should provide a more detailed survey of extensibility issues]
[TODO] Open issues are currently scattered through the text above. Additional issues...
Do we distinguish between RDF Description Servers that describe their own content versus 3rd party? Where describing own content, presume HTTP HEAD makes sense. Overlap with WebDAV extensions; need to compare w/ WebDAV properties model...
[RDF] Resource Description Framework, (RDF) Model and Syntax Specification. Lassila O., Swick R. W3C Working Draft.
[DC]Dublin Core Metdata Element Set v1.0, Dublin Core Metadata Initiative.
Resource Description Framework (RDF) Schema Specification. Brickley, D., Guha, R.V., W3C Proposed Recommendation.