WebCap: Web-based Capability List File Format and Model

Revision History
Revision 12006-03-23

Initial draft. Much room for enhancement; the focus is on the document syntax in order to guide initial implementation efforts, although this draft does attempt to provide some brief initial explanation.


This document defines WebCap, a simple language for explicitly grouping sets of URIs having a specific relationship to one another for a particular purpose.

Table of Contents

Use Cases
Expressing Intended Access Priveleges on a Set of Files
WebCap Document Format
Root cap:capabilities Element
cap:relationship Element
cap:description Element
cap:map Element
cap:local, cap:global, and cap:exposed Elements
cap:all Element
For the Future

WebCap is a file format and a data model for organizing and exposing URIs. WebCap provides a way for users to bundle related URIs together in a way that takes advantage of the hierarchical form of those URIs when it is available, in order to make managing URIs more like managing names in a filesystem. URIs are managed in bundles in order to provide the user with a way to process those URIs across contextual boundaries based upon the bundling relationship.

WebCap is related to, and draws inspiration from, RDF [RDF-XML] and XML Catalogs [XMLCatalogs].

The following WebCap document might be used to describe both equivalent http URLs as well as working copy URLs for a (small) source code repository, part of which should be published (or exposed) in a web environment.

<capabilities xmlns="ahttp://infinitesque.net/2006/ns/capabilities/">
    <sameAs xmlns="http://www.w3.org/2002/07/owl#"/>

    <div xmlns="http://www.w3.org/1999/xhtml">
      <p>This capabilities file describes URI equivalencies for
      accessing source code for the example.org project.</p>












The WebCap document above expresses the following 11 URI mapping bundles. The first URI in each mapping bundle is the stable or global identifier for the resource, the second URI is the local identifier for the resource, and the third (when it exists) is the exposed identifier for the resource. When it exists, this third URI indicates that it is a member of the capabilities set provided by the document; in this case, the author may intend that the specific capability is that web users can read the resource using the exposed URI. Also, within each URI mapping bundle, earlier URIs have the relationship http://www.w3.org/2002/07/owl#sameAs with later URIs. (According to the OWL ontology, this means that these URIs represent the same resource.)

This WebCap document could then be used to generate a number of XML Catalog documents (depending on the direction of URI resolution desired) as well as an "equivalent" RDF/XML file (or RDF serialized to another format, such as TriX).

WebCap documents must be well-formed XML documents. WebCap elements defined in this specification have ahttp://infinitesque.net/2006/ns/capabilities/ as their XML Namespace URI, and this specification uses cap to represent this XML Namespace URI in QNames where the context does not otherwise provide this mapping.

The cap:relationship allows the user to define an RDF property between resources identified within mapped bundles in the current WebCap document. This element SHOULD contain a single child element; the RDF URI reference for the property to use is determined from the QName of this element as described in section 2.1 of the RDF/XML Syntax Specification. If A and B are any two members of a mapped bundle in the current document, this RDF property is considered to hold between those two members if B comes after A in document order. For this reason, the RDF property defined within the cap:relationship element SHOULD be a transitive property.

This single property is intended to describe how the members of mapped bundles within the current document are related, which should be homogenous within a given WebCap document. In order to make additional statements about these resources and their relationships, users should use distinct WebCap documents or more powerful applications, such as RDF.

These elements directly designate one URI component of the mapping bundle for the parent cap:map. Each of these elements MUST be a child of a cap:map element, and the contents of each of these elements MUST be a shorthand reference (which is syntactically the same as a relative reference). To determine the effective URI for this component, follow these steps:

A cap:local URI SHOULD be considered to be a locally available identifier for a resource without an expectation of global uniqueness (such as a URI using the file scheme). A cap:global URI SHOULD be considered to be a globally unique identifier for a resource without an expectation of any retrieval semantics. A cap:exposed URI SHOULD be considered to be the globally unique identifier for a resource that is or will be available for the defining capability offered by the current WebCap document.

This section describes ideas for enhancement in future versions of this specification.

This section is non-normative.


grounding URI

A grounding URI has the same syntax as a URI as defined in section 3 of RFC 3986 [RFC3986], and can be used to resolve shorthand references.

shorthand reference

A shorthand reference has the same syntax as a relative-ref as defined in section 4 of RFC 3986 [RFC3986] and can be resolved against an application-specific grounding URI to obtain a URI using the mechanism defined in section 5 of RFC 3986.