Abstract

RDF enables providers to publish various types of data on the
Web in a unified format. This data intends to be
machine-interpretable so that web developers can access it by
programming languages in order to create applications for i.e.,
crawling, aggregating, summarizing, or highlighting contained
information. While publishing RDF data on the web is vital to the
growth of the Semantic Web, using the information to improve the
collective utility of the Web is the true goal of the Semantic Web.
To accomplish this goal, the RDF Application Programming Interface
(RDF API) defines a set of standardized interfaces for working with
RDF data in a web-based programming environment.

Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].

Conformance requirements phrased as algorithms or specific
steps may be implemented in any manner, so long as the end result is
equivalent. In particular, the algorithms defined in this
specification are intended to be easy to follow, and not intended to
be performant.

User agents may impose implementation-specific limits on
otherwise unconstrained inputs, e.g. to prevent denial of service
attacks, to guard against running out of memory, or to work around
platform-specific limitations.

Implementations that use ECMAScript or Java to implement the
Interfaces defined in this specification must implement them in a
manner consistent with the respective ECMAScript or Java Bindings
defined in the Web IDL specification, as this specification uses
that specification's terminology. [WEBIDL]

Implementations that use any other language to implement the
Interfaces defined in this specification that do not have bindings
defined in the Web IDL specification should attempt to map the
Interfaces as closely as possible to the implementation language's
native mechanisms and datatypes. Developers are encouraged to work
with other developers who are providing the RDF Interfaces in the
same langauge to ensure that implementations are modular and easily
exchangable.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Publication as a Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

1. Introduction

This section is non-normative.

RDF provides a means to publish and exchange machine-readable data
about resources on the Web. A Web document can be attached with
metadata in RDF in order to add a machine-interpretable layer
underneath the document's content which is intended to be read by
humans. By publishing RDF conform to the principles of Linking Open Data metadata about
resources can be interlinked across different Web servers. This
enables web developers to process published metadata about for
example a News article and combine it with additional information
from other sources.

This specification defines the RDF API, which may be used by
developers and Web Applications to access and work with RDF data on
the Web, while programing in a Web environment. The RDF API is
designed to define a standardized programming interface for
processing RDF within a Browser environment. The primary target
language for the RDF API is ECMAScript, although other languages may
also be considered.

1.1 How to Read this Document

This section is non-normative.

This document is a detailed specification for the RDF API.
The document is primarily intended for web developers who want to
process RDF data in a browser environment.

If you are not familiar with RDF, you should read about the
Resource Description Framework (RDF) [RDF-CONCEPTS] before reading
this document.

This document uses the Web Interface Definition Language
[WEBIDL] to specify all language bindings. If you intend to
implement any part of the RDF API you should be familiar
with the Web IDL language [WEBIDL].

Examples may contain references to existing vocabularies and
use abbreviations in CURIEs and source code. The following is a list
of all vocabularies and their abbreviations, as used in this
document:

1.2 Design Considerations

This section is non-normative.

More and more information providers put RDF data to published
Web content. Although a variety of Web browsers have been extended
to enable RDF support for viewing, browsing, collecting, and
aggregating existing RDF data, a common programming interface for
processing RDF data similarly across different programming
languages, like it is possible for XML, is still missing.

This specification defines all necessary means for processing
RDF within a Browser environment. The RDF API comprises the
following functionalities:

Simple projections that allow the processing of RDF data in
an object-oriented programming style.

A parser interface to parse RDF data from various formats.

A query interface to retrieve objects from RDF.

2. The RDF API Specification

The following section contains all of the interfaces that RDFa
API implementers are expected to provide as well as guidance to
ensure that implementations are conformant.

2.1 Projections

This section is non-normative.

A
Projection
is an object-oriented view of a particular subject that is expressed
in the document. For example, to get all projections that express
people in an RDF document, a developer can do the following:

2.2.2 Methods

If a
Projection
is passed to the parser as pattern, then each RDF data found in
the document will only be added to the output Sequence of
Projection
s if it matches the null values used as wildcarts in the passed
pattern.

A boolean response is given indicating if the parse was
successful or not.

The document to parse, the type of argument required may further
be constrained by implementations of this interface, for instance
an RDFa parser may require an instance of
Document
, whilst a
Turtle
parser may require a
String
.

The
Projection
template is used to build the return value. The template consists
of a key-value associative array where the key is the name of the
property to create in the
Projection
and the value is the URI to use when matching against predicates
in each triple.

The subject to use when matching against triples. The subject can
be either an absolute URI or a CURIE. The subject is used to match
against the URI in the first part of a triple. An implementation
must coerce the DOMString to the same type as the triple's subject
being compared. If the type coercion will result in a URI, the
CURIE mappings must be queried first for a mapping and the given
property expanded as a CURIE if a mapping is found. If the subject
does not exist in the RDF document, the return value must be
null
.

The
Projection
template is used to build the return value. The template consists
of a key-value associative array where the key is the name of the
property to create in the
Projection
and the value is the URI to use when matching against predicates
in each triple.

The
Projection
template is used to build the return value. The template consists
of a key-value associative array where the key is the name of the
property to create in the
Projection
and the value is the URI to use when matching against predicates
in each triple.

The property to use when matching against triples. The property
can be either an absolute URI or a CURIE. The property is used to
match against the URI in the second part of a triple, also known
as the predicate. An implementation must coerce the DOMString to
the same type as the predicate being compared. If the type
coercion will result in a URI, the CURIE mappings must be queried
first for a mapping and the given property expanded as a CURIE if
a mapping is found. If the value is
null
, the match is always positive.

The value to use when matching against triples. The value can be
either an absolute URI or a CURIE. The value is used to match
against the final part of a triple, also known as the object. An
implementation must coerce the DOMString to the same type as the
object being compared. If the type coercion will result in a URI,
the CURIE mappings must be queried first for a mapping and the
given value expanded as a CURIE if a mapping is found. If the
value is
null
, the match is always positive.

The
Projection
template is used to build the return value. The template consists
of a key-value associative array where the key is the name of the
property to create in the
Projection
and the value is the URI to use when matching against predicates
in each triple.

The subject to use when matching against triples. The subject is
used to match against the URI in the first part of a triple. The
subject can be either an absolute URI or a CURIE. The subject is
used to match against the first part of a triple. An
implementation must coerce the DOMString to the same type as the
triple's subject that is being compared. If the type coercion will
result in a URI, the CURIE mappings must be queried first for a
mapping and the given property expanded as a CURIE if a mapping is
found. If the given subject is
null
, the match is always positive.

The property to use when matching against triples. The property
can be either an absolute URI or a CURIE. The property is used to
match against the URI in the second part of a triple, also known
as the predicate. An implementation must coerce the DOMString to
the same type as the predicate being compared. If the type
coercion will result in a URI, the CURIE mappings must be queried
first for a mapping and the given property expanded as a CURIE if
a mapping is found. If the value is
null
, the match is always positive.

The value to use when matching against triples. The value can be a
number, a boolean, a DOMString, an absolute URI or a CURIE. The
value is used to match against the final part of a triple, also
known as the object. An implementation must coerce the DOMString
to the same type as the triple object being compared. If the type
coercion will result in a URI, the CURIE mappings must be queried
first for a mapping and the given property expanded as a CURIE if
a mapping is found. If the value is
null
, the match is always positive.

The subject to use when matching against triples. The subject can
be either an absolute URI or a CURIE. The subject is used to match
against the URI in the first part of a triple. An implementation
must coerce the DOMString to the same type as the subject being
compared. If the type coercion will result in a URI, the CURIE
mappings must be queried first for a mapping and the given
property expanded as a CURIE if a mapping is found. If the value
is
null
, the match is always positive.

The property to use when matching against triples. The property
can be either an absolute URI or a CURIE. The property is used to
match against the URI in the second part of a triple, also known
as the predicate. An implementation must coerce the DOMString to
the same type as the predicate being compared. If the type
coercion will result in a URI, the CURIE mappings must be queried
first for a mapping and the given property expanded as a CURIE if
a mapping is found. If the value is
null
, the match is always positive.

The document to parse, the type of argument required may further
be constrained by implementations of this interface, for instance
an RDFa parser may require an instance of
Document
, whilst a
Turtle
parser may require a
String
.

The
Projection
template is used to build the return value. The template consists
of a key-value associative array where the key is the name of the
property to create in the
Projection
and the value is the URI to use when matching against predicates
in each triple.

The
Projection
template is used to build the return value. The template consists
of a key-value associative array where the key is the name of the
property to create in the
Projection
and the value is the URI to use when matching against predicates
in each triple.