Chapter 10. RDF, RDF Tools, and the Content Model-P1
Chapter 9 introduced the Resource Description Framework (RDF) as the
basis for building display data in the interface, where XUL templates take
RDF-based data and transform it into regular widgets. But RDF is used in
many other more subtle ways in Mozilla. In fact, it is the technology Mozilla
uses for much of its own internal data handling and manipulation.
RDF is, as its name suggests, a framework for integrating many types of data
that go into the browser, including bookmarks, mail messages, user profiles,
IRC channels, new Mozilla applications, and your collection of sidebar tabs.
All these items are sets of data that RDF represents and incorporates into the
browser consistently. RDF is used prolifically in Mozilla, which is why this
chapter is so dense.
This chapter introduces RDF, provides some detail about how Mozilla uses
RDF for its own purposes, and describes the RDF tools that are available on
the Mozilla platform. The chapter includes information on special JavaScript
libraries that make RDF processing much easier, and on the use of RDF in
manifests to represent JAR file contents and cross-platform installation
archives to Mozilla.
Once you understand the concepts in this chapter, you can make better use
of data and metadata in your own application development.
10.1. RDF Basics
RDF has two parts: the RDF Data Model and the RDF Syntax (or Grammar).
The RDF Data Model is a graph with nodes and arcs, much like other data
graphs. More specifically, it's a labeled-directed graph. All nodes
and arcs have some type of label (i.e., an identifier) on them, and arcs point
only in one direction.
The RDF Syntax determines how the RDF Data Model is represented,
typically as a special kind of XML. Most XML specifications define data in
a tree-like model, such as XUL and XBL. But the RDF Data Model cannot
be represented in a true tree-like structure, so the RDF/XML syntax includes
properties that allow you to represent the same data in more than one way:
elements can appear in different orders but mean the same thing, the same
data can be represented as a child element or as a parent attribute, and data
have indirect meanings. The meaning is not inherent in the structure of the
RDF/XML itself; only the relationships are inherent. Thus, an RDF
processor must make sense of the represented RDF data. Fortunately, an
excellent RDF processor is integrated into Mozilla.
10.1.1. RDF Data Model
Three different types of RDF objects are the basis for all other RDF
concepts: resources, properties, and statements. Resources are any type of
data described by RDF. Just as an English sentence is comprised of subjects
and objects, the resources described in RDF are typically subjects and
objects of RDF statements. Consider this example:
Eric wrote a book.
Eric is the subject of this statement, and would probably be an RDF resource
in an RDF statement. A book, the object, might also be a resource because
it represents something about which we might want to say more in RDF --
for example, the book is a computer book or the book sells for twenty
dollars. A property is a characteristic of a resource and might have a
relationship to other resources. In the example, the book was written by Eric.
In the context of RDF, wrote is a property of the Eric resource. An RDF
statement is a resource, a property, and another resource grouped together.
Our example, made into an RDF statement, might look like this:
(Eric) wrote (a book)
Joining RDF statements makes an entire RDF graph.
We are describing the RDF data model here, not the RDF syntax. The
RDF syntax uses XML to describe RDF statements and the relationship
of resources.
As mentioned in the introduction, the RDF content model is a labeled-
directed graph, which means that all relationships expressed in the
graph are unidirectional, as displayed in Figure 10-1.
Figure 10-1. Simple labeled-directed graph
A resource can contain either a URI or a literal. The root resource might
have a URI, for example, from which all other resources in the graph
descend. The RDF processor continues from the root resource along its
properties to other resources in the graph until it runs out of properties to
traverse. RDF processing terminates at a literal, which is just what it sounds
like: something that stands only for itself, generally represented by a string
(e.g., "book," if there were no more information about the book in the
graph). A literal resource contains only non-RDF data. A literal is a terminal
point in the RDF graph.
For a resource to be labeled, it must be addressed through a universal
resource identifier (URI). This address must be a unique string that
designates what the resource is. In practice, most resources don't have
identifiers because they are not nodes on the RDF graph that are meant to be
accessed through a URI. Figure 10-2 is a modified version of Figure 10-1
that shows Eric as a resource identifier and book as a literal.
Figure 10-2. Resource to literal relationship
Resources can have any number of properties, which themselves differ. In
Figure 10-2, wrote is a property of Eric. However, resources can also
have multiple properties, as shown in Figure 10-3.
Figure 10-3. RDF Graph with five nodes
The RDF graph in Figure 10-3 has five nodes, two resources, and three
literals. If this graph were represented in XML, it would probably have three
different XML namespaces inside of it: RDF/XML, a book XML
specification, and a computer XML specification. In English, the graph in
Figure 10-3 might be expressed as follows:
Eric wrote a book of unknown information. Eric's computer is 700 MHz and
has an Athlon CPU.
Note that if Eric wrote a poem and a book, it would be possible to have two
wrote properties for the same resource. Using the same property to point to
separate resources is confusing, however. Instead, RDF containers (see the
section Section 10.1.2.2, later in this chapter) are the best way to organize
data that would otherwise need a single property to branch in this way.
10.1.1.1. RDF URIs relating to namespaces
The URIs used in RDF can be part of the element namespace. (See Section
2.2.3 and in Section 7.1.3 for more information about XML namespaces.)