index.html 23.4 KB

Raw Blame History Permalink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
                      "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
  <style type="text/css">
        .example {
        BACKGROUND-COLOR: #f9f5de; BORDER-BOTTOM: 1px solid; BORDER-LEFT: 1px solid; BORDER-RIGHT: 1px solid; BORDER-TOP: 1px solid; COLOR: #5d0091; MARGIN-LEFT: 10%; WIDTH: 65%
        }
        img.W3CIcon {
        BORDER: 0;
        }       </style>
  <title>RDF Description Services</title>
  <!--LINK rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-NOTE"-->
  <link rel="stylesheet" type="text/css" href="prenote.css">
</head>

<body>

<div class="head">
<!-- IMG src="http://www.w3.org/Icons/WWW/w3c_home" ALT  ="W3C" class="W3CIcon" -->

<h1>RDF Description Services</h1>

<h3>RDF Interest Group Discussion Document, 23rd November 1999</h3>

<p>Current version: <a
href="http://www.w3.org/1999/11/02-RDFServices/">http://www.w3.org/1999/11/02-RDFServices/</a>
<br>
Author: Dan Brickley &lt;<a href="mailto:danbri@w3.org">danbri@w3.org</a>></p>

<p></p>

<h2>Status of this document</h2>

<p>This is the first public draft of a discussion document for the <a
href="/RDF/Interest/">RDF Interest Group</a>. 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.</p>

<p>Comments from the public on this document are invited and should (with the
exception of minor editorial suggestions) be sent to the <a
href="/RDF/Interest/">RDF Interest Group</a>, <a
href="mailto:www-rdf-interest@w3.org">www-rdf-interest@w3.org</a> which is an
automatically <a
href="http://lists.w3.org/Archives/Public/www-rdf-interest/">archived</a>
email list. Information on how to join the RDF Interest Group mailing list can
be found on the group's <a href="/RDF/Interest/">home page</a>.</p>

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

<p><strong>Editorial Note:</strong> 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.</p>

<p><a
href="http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright">Copyright</a>
&copy;1999 <a href="http://www.w3.org">W3C</a> (<a
href="http://www.lcs.mit.edu">MIT</a>, <a
href="http://www.inria.fr/">INRIA</a>, <a
href="http://www.keio.ac.jp/">Keio</a> ), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice.html#LegalDisclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice.html#W3CTrademarks">trademark</a>,
<a href="http://www.w3.org/Consortium/Legal/copyright-documents.html">document
use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software.html">software
licensing</a> rules apply.</p>
</div>

<h2>Contents</h2>

<p></p>
<ul>
  <li><a href="#abst">Abstract</a></li>
  <li><a href="#intro">Introduction</a></li>
  <li><a href="#desc">Description Services</a>
    <ul>
      <li><a href="#scop">Scope</a></li>
      <li><a href="#core">Core Functionality</a></li>
      <li><a href="#moti">Motivating Examples</a></li>
      <li><a href="#quer">Query model</a></li>
      <li><a href="#gene">General vs Specific Labels</a></li>
      <li><a href="#attr">Attribution</a></li>
      <li><a href="#self">Self Description</a></li>
      <li><a href="#seea">See Also references</a></li>
      <li><a href="#read">Read/Write capability</a></li>
    </ul>
  </li>
  <li><a href="#prot">Protocol Interfaces</a>
    <ul>
      <li><a href="#http">HTTP/1.1 GET</a></li>
      <li><a href="#nonw">Non-Web Interfaces</a></li>
      <li><a href="#exte">Extensions</a></li>
    </ul>
  </li>
  <li><a href="#term">Appendix: Terminology</a></li>
  <li><a href="#term">Appendix: Open Issues</a></li>
  <li><a href="#refe">Appendix: References</a></li>
</ul>

<h2><a name="abst">Abstract</a></h2>

<p>This document describes an application of W3C's RDF, the Resource
Description Framework, to support a broad range of queryable  <em>Description
Services</em> on the Web. The approach adopted here is in essence a
generalisation of the <a href="http://www.w3.org/TR/REC-PICS-labels">PICS
Label Distribution Label Syntax and Communication Protocols</a>, 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 <a
href="http://www.w3.org/TR/PR-rdf-schema/">Schema</a>, <a
href="http://www.w3.org/TR/REC-rdf-syntax/">Model and Syntax</a>
specifications by describing a syntax-neutral convention for presenting RDF
views of networked databases.</p>

<h2><a name="intro">Introduction</a></h2>

<p>The Resource Description Framework (RDF) provides a highly general
formalism for modeling structured data on the Web. In particular, the RDF <a
href="http://www.w3.org/TR/REC-rdf-syntax/">Model and Syntax specification</a>
defines a graph-based data structure based around URI resource names, and an
XML-based interchange format. Unlike <a href="/PICS">PICS</a>, 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 <a
href="http://www.w3.org/TR/REC-rdf-syntax/#transport">notes that</a> RDF
descriptions may be associated with the resource(s) they describe in a number
of ways. In particular:</p>

<blockquote>
  [3.] The Description may be retrieved independently from the resource,
  including from a different source ("service bureau"; e.g. using HTTP
GET).</blockquote>

<p>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 <a
href="http://www.w3.org/TR/REC-PICS-labels">PICS Label Distribution Label
Syntax and Communication Protocols</a>.</p>

<p>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: "<em>Tell me about the resource whose URI is
[x]</em>". 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.</p>

<h2><a name="desc">Description Services</a></h2>

<p>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.</p>
<a name="scop"></a>

<h3>Scope</h3>

<p>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 <em>not</em> 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 ]</p>

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

<p>RDF Description Services can be used to expose descriptions of <em>any</em>
entities (objects, resources, things) that can be identified using URIs. The
<a href="http://www.ics.uci.edu/pub/ietf/uri/rfc2396.txt">URI
specification</a> (RFC 2396) provides a broad definition of resource as
"anything that has identity". RDF's notion of a resource is a URI-identifiable
entity.</p>

<blockquote>
  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.<br>
  (excerpt from RFC 2396 section 1.1)</blockquote>

<p>RDF Description Services can therefore provide a simple, unifying interface
to a very broad range of resource descriptions.</p>
<a name="core"></a>

<h3>Core Functionality</h3>

<p>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 <em>not</em> 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.</p>

<p>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
<em>seeAlso</em> statements may be used to provide hints as to further queries
that may be useful.</p>
<a name="moti"></a>

<h3>Motivating Examples</h3>

<p>The following <em>motivating examples</em> 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.</p>

<p>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.</p>
<dl>
  <dt>Example 1: annotation server</dt>
    <dd><p>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.</p>
    </dd>
  <dt>Example 2: thesaurus server</dt>
    <dd><p>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).</p>
    </dd>
  <dt>Example 3: URI resolution</dt>
    <dd><p>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.</p>
    </dd>
  <dt>Example 4: internet library catalogue</dt>
    <dd><p>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 <em>annotation service</em>.</p>
    </dd>
  <dt>Example 5: child protection</dt>
    <dd><p>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.</p>
    </dd>
</dl>

<p>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.</p>
<a name="quer"></a>

<h3>Query model</h3>

<p>A typical pattern of interaction with an RDF Description Service is for
some <em>client application</em> 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.</p>

<p>The following example scenario uses an HTTP-based interface to the service,
specified more formally below.</p>

<h4>Example</h4>

<p>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:</p>
<pre>     GET /bureau?http%3A%2F%2Fsomesiteorother.com/ HTTP/1.1
     Host: 127.0.0.1</pre>

<p>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.</p>
<pre>        &lt;?xml version="1.0"?>
        &lt;web:RDF
           xmlns:web = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
           xmlns = "http://purl.org/dc/elements/1.1/" >
           &lt;web:Description about = "http://somesiteorother.com/"
                 title = "Name of site here"
                 subject = "subject goes here..."
           />
        &lt;/web:RDF></pre>
<a name="gene"></a>

<h3>General vs Specific Labels</h3>

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

<p>This specification does not provide any mechanism for client applications
to request <em>generic</em> labels. The RDF specifications provides a simple
XML-syntax construct <code>rdf:aboutEachPrefix</code> 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 <code>aboutEachPrefix</code> mechanism.</p>
<a name="attr"></a>

<h3>Attribution</h3>

<p>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]</p>
<a name="self"></a>

<h3>Self Description</h3>

<p>All RDF Description Services should be prepared to offer an RDF Description
of themselves. In other words, a server whose URI is <em>X</em>, when asked
for a description of <em>X</em>, should provide some RDF graph as a response.
This document does not, however, constrain the content of this graph in any
way. The <a href="#dc">Dublin Core Element Set</a> may prove a useful base
vocabulary appropriate for this task.</p>
<a name="seea"></a>

<h3>See Also references</h3>

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

<p>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 <em>not</em> define any means by which the descriptive
capabilities of a given server can be determined. <!-- open issue: should the seeAlso point to the server or the
query against the server-->
</p>
<a name="read"></a>

<h3>Read/Write capability</h3>

<p>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  <a
href="http://www.w3.org/PICS/refcode/Bureau/PUT.htm">'PUT' method</a> for PICS
bureau.</p>
<a name="prot"></a>

<h2>Protocol Interfaces</h2>

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

<p>[open issues: error handling -- HTTP codes applicable?]</p>
<a name="http"></a>

<h3>HTTP GET interface</h3>

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

<p><b>[TODO]  more formal specification goes here </b></p>

<p>[open issue: content negotiation]<br>
[open issue: HTTP GET vs HTTP HEAD]<br>
[open issue: cache control headers]<br>
</p>
<a name="nonw"></a>

<h3>Non-Web interfaces</h3>

<p>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.</p>
<a name="exte"></a>

<h3>Extensions</h3>

<p>Detailed extensions to the basic framework outlined here may depend on the
particular facilities offered by implementation environments such as HTTP.</p>

<p>[open issue: Future versions of this document should provide a more
detailed survey of extensibility issues]</p>
<a name="term"></a>

<h3>Terminology</h3>
<dl>
  <dt>RDF model</dt>
    <dd>An instance of an RDF graph data structure compliant with the RDF
      model and syntax specification</dd>
  <dt>RDF Description Service</dt>
    <dd>A network-accessible database which exposes an interface allowing RDF
      descriptions (from some <em>RDF model</em>) to be provided for some
      specified URI. A single RDF Description Service might be available via
      one or more protocols, APIs or machine-interfaces. A common scenario is
      for the service to be accessible by HTTP using the conventions outlined
      below.</dd>
  <dt>Label Bureau</dt>
    <dd>A 'label bureau' is a PICS service that provides PICS labels in
      response to query URL(s).</dd>
  <dt>Metadata Bureau</dt>
    <dd>An alternative name for 'RDF Description Service'</dd>
  <dt>Client application</dt>
    <dd>A software process or user agent playing a client role in some
      interaction with an RDF Description Service. Specifically, client
      applications will request RDF descriptions for URI-named Web
    resources.</dd>
</dl>
<a name="open"></a>

<h2>Open Issues</h2>

<p>[TODO] Open issues are currently scattered through the text above.
Additional issues...</p>

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

<h2><a name="refe">References</a> (to be completed)</h2>

<p><a name="[RDF]">[RDF]</a> <a
href="http://www.w3.org/TR/WD-rdf-syntax/">Resource Description Framework,
(RDF) Model and Syntax Specification. Lassila O., Swick R. W3C Working
Draft.</a></p>

<p><a name="DC">[DC]</a><a href="http://purl.org/dc/elements/1.0/">Dublin Core
Metdata Element Set v1.0</a>, Dublin Core Metadata Initiative.</p>
<a href="http://www.w3.org/TR/WD-rdf-schema/">Resource Description Framework
(RDF) Schema Specification. Brickley, D., Guha, R.V., W3C Proposed
Recommendation.</a>
<dl>
  <dt>[URI Schemes]</dt>
    <dd>The W3C index of <a
      href="http://www.w3.org/Addressing/schemes.html">URI Addressing
      Schemes</a> provides an informal registry of URI schemes.</dd>
</dl>
</body>
</html>