You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
502 lines
23 KiB
502 lines
23 KiB
<!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 <<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>
|
|
©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> <?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></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>
|