RDF Primer

2.1 Basic Concepts

Imagine that we want to state the fact that someone named John Smith created a particular Web page. A straightforward way to state this in English would be in the form of a simple statement such as:

http://www.example.org/index.html has a creator whose value is John Smith

We've underlined parts of this statement to illustrate that, in order to describe the properties of something, we need ways to name, or identify, a number of things:

• We need a way to identify the thing we want to describe (the Web page, in this case)
• We need a way to identify a specific property (creator, in this case) of the thing that we want to describe
• We need a way to identify the thing we want to assign as the value of this property (who the creator is), for the thing we want to describe

In this statement, we've used the Web page's URL (Uniform Resource Locator) to identify it. In addition, we've used the word "creator" to identify the property we want to talk about, and the two words "John Smith" to identify the thing (a person) we want to say is the value of this property.

We could state other properties of this Web page by writing additional English statements of the same general form, using the URL to identify the page, and words (or other expressions) to identify the properties and their values. For example, to specify the date the page was created, and the language in which the page is written, we could write the additional statements:

http://www.example.org/index.html has a creation-date whose value is August 16, 1999
http://www.example.org/index.html has a language whose value is English

RDF is based on the idea that the things we want to describe have properties which have values, and that resources can be described by making statements, similar to those above, that specify those properties and values. RDF uses a particular terminology for talking about the various parts of statements. Specifically, the part that identifies the thing the statement is about (the Web page in this example) is called the subject. The part that identifies the property or characteristic of the subject that the statement specifies (creator, creation-date, or language in these examples) is called the predicate, and the part that identifies the value of that property is called the object. So, taking the English statement

http://www.example.org/index.html has a creator whose value is John Smith

the RDF terms for the various parts of the statement are:

• the subject is the URL http://www.example.org/index.html
• the predicate is the word "creator"
• the object is the words "John Smith"

However, while English is good for communicating between (English-speaking) humans, RDF is about making machine-processable statements. To make these kinds of statements suitable for processing by machines, we need two things:

• a system of machine-processable identifiers that allows us to identify a subject, predicate, or object in a statement without any possibility of confusion with a similar-looking identifier that might be used by someone else on the Web.
• a machine-processable language for representing these statements and exchanging them between machines.

Fortunately, the existing Web architecture provides both these necessary facilities.

As we've seen, the Web already provides one form of identifier, the Uniform Resource Locator (URL). We used a URL in our original example to identify the Web page that John Smith created. A URL is a character string that identifies a Web resource by representing its primary access mechanism (essentially, its network "location"). However, we would also like to be able to record information about many things that, unlike Web pages, don't have network locations or URLs.

The Web provides a more general form of identifier for these purposes, called the Uniform Resource Identifier (URI). URLs are a particular kind of URI. All URIs share the property that different persons or organizations can independently create them, and use them to identify things. However, URIs are not limited to identifying things that have network locations, or use other computer access mechanisms. In fact, we can create a URI to refer to anything we want to talk about, including

• network-accessible things, such as an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), or a group of other resources.
• things that are not network-accessible, such as human beings, corporations, and bound books in a library.
• abstract concepts that don't physically exist, like the concept of a "creator".

Because of this generality, RDF uses URIs as the basis of its mechanism for identifying the subjects, predicates, and objects in statements. To be more precise, RDF uses URI references [URIS]. A URI reference (or URIref) is a URI, together with an optional fragment identifier at the end. For example, the URI reference http://www.example.org/index.html#section2 consists of the URI http://www.example.org/index.html and (separated by the "#" character) the fragment identifier Section2. RDF defines a resource as anything that is identifiable by a URI reference, so using URIrefs allows RDF to describe practically anything, and to state relationships between such things as well. URIrefs and fragment identifiers are discussed further in Appendix A and [RDF-CONCEPTS].

To represent RDF statements in a machine-processable way, RDF uses the Extensible Markup Language [XML]. XML was designed to allow anyone to design their own document format and then write a document in that format. RDF defines a specific XML markup language, referred to as RDF/XML, for use in representing RDF information, and for exchanging it between machines. An example of RDF/XML was given in Section 1. That example (Example 1) used tags such as <contact:fullName> and <contact:personalTitle> to delimit the text content Eric Miller and Dr., respectively. Such tags allow programs written with an understanding of what the tags mean to property interpret that content. Appendix B provides further background on XML in general. The specific RDF/XML syntax used for RDF is described in more detail in Section 3.

2.2 The RDF Model

Now that we've introduced RDF's basic statement concepts, URI references for identifying things we want to talk about on the Web, and RDF/XML as a machine-processable way of representing RDF statements, we can describe how RDF lets us use URIs to make statements about resources. In the introduction, we said that RDF was based on the idea of expressing simple statements about resources, where those statements are built using subjects, predicates, and objects. In RDF, we could represent our original English statement:

http://www.example.org/index.html has a creator whose value is John Smith

by an RDF statement having:

• a subject http://www.example.org/index.html
• a predicate http://purl.org/dc/elements/1.1/creator
• and an object http://www.example.org/staffid/85740

Note how we have introduced URIrefs to identify not only the subject of the original statement, but also the predicate and object, instead of using the words "creator" and "John Smith", respectively. We'll discuss this further a bit later on.

RDF models statements as nodes and arcs in a graph. RDF's graph model is defined in [RDF-CONCEPTS]. In this notation, a statement is represented by:

• a node for the subject, labeled with its URIref
• a node for the object, labeled with its URIref
• an arc for the predicate, labeled with its URIref, directed from the subject node to the object node.

So the RDF statement above would be represented by the graph shown in Figure 2:

Figure 2: A Simple RDF Statement

Groups of statements are represented by corresponding groups of nodes and arcs. So if we wanted to also represent the additional statements

http://www.example.org/index.html has a creation-date whose value is August 16, 1999
http://www.example.org/index.html has a language whose value is English

we could, by introducing suitable URIrefs to name the properties "creation-date" and "language", use the graph shown in Figure 3:

Figure 3: Several Statements About the Same Resource

Figure 3 illustrates that the objects of RDF statements may be either resources identified by URIrefs, or constant values (called literals) represented by character strings, in order to represent certain kinds of property values. Literals may not be the subjects or predicates of RDF statements. (The simple character string literals we will use for now are called plain literals, to distinguish them from the typed literals we will introduce in Section 2.4. The various kinds of literals that can be used in RDF statements are defined in [RDF-CONCEPTS].) In drawing RDF graphs, nodes that represent resources identified by URIrefs are shown as ellipses, while nodes that represent literals are shown as boxes (labeled by the literal itself). RDF graphs can be described as "labeled directed graphs", since the arcs have labels, and are "directed" (point in a specific direction, from subject to object).

Sometimes it is not convenient to draw graphs when discussing them, so an alternative way of writing down the statements, called triples, is also used. In the triples notation, each statement in the graph is written as a simple triple of subject, predicate, and object node labels (either URIref or literal), in that order. The triples representing the three statements shown in Figure 3 would be written in full as:

<http://www.example.org/index.html> <http://purl.org/dc/elements/1.1/creator> <http://www.example.org/staffid/85740> .

<http://www.example.org/index.html> <http://www.example.org/terms/creation-date> "August 16, 1999" .

<http://www.example.org/index.html> <http://www.example.org/terms/language> "English" .

Each triple corresponds to a single arc in the graph, complete with the arc's beginning and ending nodes (the subject and object of the statement). Unlike the drawn graph (but like the original statements), the triples notation requires that a node be separately identified for each statement it appears in. So, for example, http://www.example.org/index.html appears three times (once in each triple) in the triples representation of the graph, but only once in the drawn graph. However, the triples represent exactly the same information as the drawn graph, and this is a key point: what is fundamental to RDF is the graph model of the statements. The notation used to represent or depict the graph is secondary.

The full triples notation requires that URI references be written out completely, in angle brackets, which, as the example above illustrates, can result in very long lines. For convenience, we will use a shorthand way of writing triples in the rest of this Primer, and also in other RDF specifications. In this shorthand, we can substitute a qualified name (or QName) without angle brackets as an abbreviation of a full URI reference. A QName contains a prefix that has been assigned to a namespace URI, followed by a colon, and then a local name (QNames are discussed further in Appendix B). So, for example, if the QName prefix foo is assigned to the namespace URI http://example.org/somewhere/, then the QName foo:bar is shorthand for the URIref http://example.org/somewhere/bar. We will also make extensive use in these examples of several "well-known" QName prefixes (which we will use without explicitly specifying them each time), defined as follows:

prefix rdf:, namespace URI: http://www.w3.org/1999/02/22-rdf-syntax-ns#
prefix rdfs:, namespace URI: http://www.w3.org/2000/01/rdf-schema#
prefix dc:, namespace URI: http://purl.org/dc/elements/1.1/
prefix daml:, namespace URI: http://www.daml.org/2001/03/daml+oil#
prefix ex:, namespace URI: http://www.example.org/ (or http://www.example.com/)
prefix xsd:, namespace URI: http://www.w3.org/2001/XMLSchema#

We will also use variations on the "example" prefix ex: as needed in the examples, where this will not cause confusion, for example,

prefix exterms:, namespace URI: http://www.example.org/terms/ (for terms used by our example organization),
prefix exstaff:, namespace URI: http://www.example.org/staffid/ (for our example organization's staff identifiers),
prefix ex2:, namespace URI: http://www.domain2.example.org/ (for a second example organization), and so on.

Using our new shorthand, we can write the previous set of triples as:

ex:index.html dc:creator exstaff:85740 .

ex:index.html exterms:creation-date "August 16, 1999" .

ex:index.html exterms:language "English" .

The examples we've just given of RDF statements begin to illustrate some of the advantages of using URIrefs as RDF's basic way of identifying things. For instance, instead of identifying the creator of the Web page in our first example by the character string "John Smith", we've assigned him a URIref, in this case (using a URIref based on his employee number) http://www.example.org/staffid/85740 . An advantage of using a URIref in this case is that we can be more precise in our identification. That is, the creator of the page isn't the character string "John Smith", or any one of the thousands of people named John Smith, but the particular John Smith associated with that URIref (whoever created the URIref defines the association). Moreover, since we have a URIref for the creator of the page, it is a full-fledged resource, and we can record additional information about him, such as his name, and age, as in the graph shown in Figure 4:

Figure 4: More Information About John Smith

These examples also illustrate that RDF uses URIrefs as predicates in RDF statements. That is, rather than using character strings (or words) such as "creator" or "name" to identify properties, RDF uses URIrefs. Using URIrefs to identify properties is important for a number of reasons. First, it allows us to distinguish the properties we use from properties someone else may use that would otherwise be identified by the same character string. For instance, in our example, example.org uses "name" to mean someone's full name written out as a character string literal (e.g., "John Smith"), but someone else may intend "name" to mean something different (e.g., the name of a variable in a piece of program text). A program encountering "name" as a property identifier on the Web wouldn't necessarily be able to distinguish these uses. However, if example.org writes http://www.example.org/terms/name for its "name" property, and the other person writes http://www.domain2.example.org/genealogy/terms/name for hers, we can keep straight the fact that there are distinct properties involved (even if a program cannot automatically determine the distinct meanings). Another reason why it is important to use URIrefs to identify properties is that it allows us to treat RDF properties as resources themselves. Since properties are resources, we can record descriptive information about them (e.g., the English description of what example.org means by "name"), simply by adding additional RDF statements with the property's URIref as the subject.

Using URIrefs as subjects, predicates, and objects in RDF statements allows us to begin to develop and use a shared vocabulary on the Web, reflecting (and creating) a shared understanding of the concepts we talk about. For example, in the triple

ex:index.html  dc:creator  exstaff:85740 .

the predicate dc:creator, when fully expanded as a URIref, is an unambiguous reference to the "creator" attribute in the Dublin Core metadata attribute set (discussed further in Section 6.1), a widely-used set of attributes (properties) for describing information of all kinds. The writer of this triple is effectively saying that the relationship between the Web page (identified by http://www.example.org/index.html ) and the creator of the page (a distinct person, identified by http://www.example.org/staffid/85740 ) is exactly the concept identified by http://purl.org/dc/elements/1.1/creator . Moreover, anyone else, or any program, that understands http://purl.org/dc/elements/1.1/creator will know exactly what is meant by this relationship.

Of course, RDF's use of URIrefs doesn't solve all our problems because, for example, people can still use different URIrefs to refer to the same thing. However, the fact that these different URIrefs are used in the commonly-accessible "Web space" creates the opportunity both to identify equivalences among these different references, and to migrate toward the use of common references.

The result of all this is that RDF provides a way to make statements that applications can more easily process. Now an application can't actually "understand" such statements, of course, but it can deal with them in a way that makes it seem like it does. For example, a user could search the Web for all book reviews and create an average rating for each book. Then, the user could put that information back on the Web. Another web site could take that list of book rating averages and create a "Top Ten Highest Rated Books" page. Here, the availability and use of a shared vocabulary about ratings, and a shared group of URIrefs identifying the books they apply to, allows individuals to build a mutually-understood and increasingly-powerful (as additional contributions are made) "information base" about books on the Web. The same principle applies to the vast amounts of information that people create about thousands of subjects every day on the Web.

RDF statements are similar to a number of other formats for recording information, such as:

• entries in a simple record or catalog listing describing the resource in a data processing system.
• rows in a simple relational database.
• simple assertions in formal logic

and information in these formats can be treated as RDF statements, allowing RDF to be used as a unifying model for integrating data from many sources.

2.3 Structured Property Values and Blank Nodes

Things would be very simple if the only types of information we had to record about things were obviously in the form of the simple RDF statements we've illustrated so far. However, most real-world data involves structures that are more complicated than that, at least on the surface. For instance, in our original example, we recorded the date the Web page was created as a single exterms:creation-date property, with a plain literal as its value. However, suppose we wanted to show, as the value of the exterms:creation-date property, the month, day, and year as separate pieces of information? Or, in the case of John Smith's personal information, suppose we wanted to record his address. We might write the whole address out as a plain literal, as in the triple

exstaff:85740  exterms:address  "1501 Grant Avenue, Bedford, Massachusetts 01730" .

However, suppose we wanted to record John's address as a structure consisting of separate street, city, state, and Zip code values? How do we do this in RDF?

We can represent such structured information in RDF by considering the aggregate thing we want to talk about (like John Smith's address) as a resource, and then making statements about that new resource. So, in the RDF graph, in order to break up John Smith's address into its component parts, we create a new node to represent the concept of John Smith's address, and assign that concept a new URIref to identify it, say http://www.example.org/addressid/85740 (which we will abbreviate as exaddressid:85740). We then write RDF statements (create additional arcs and nodes) with that node as the subject, to represent the additional information, producing the graph shown in Figure 5:

Figure 5: Breaking Up John's Address

or the triples:

exstaff:85740      exterms:address  exaddressid:85740 .
exaddressid:85740  exterms:street   "1501 Grant Avenue" .
exaddressid:85740  exterms:city     "Bedford" .
exaddressid:85740  exterms:state    "Massachusetts" .
exaddressid:85740  exterms:Zip      "01730" .

Using this approach allows us to represent structured information in RDF, but it can involve generating numerous "intermediate" URIrefs to represent aggregate concepts such as John's address. Such concepts may never need to be referred to directly from outside a particular graph, and hence may not require "universal" identifiers. In addition, in the drawing of the graph representing the group of statements shown in Figure 5, we didn't really need the URIref we assigned to identify "John Smith's address", since we could just as easily have drawn the graph as in Figure 6:

Figure 6: Using a Blank Node

In Figure 6, which is a perfectly good RDF graph, we've used a node without a label to stand for the concept of "John Smith's address". This unlabeled node, or blank node, serves its purpose in the drawing without needing a URIref, since the node itself provides the necessary connectivity between the various other parts of the graph. (Blank nodes were called anonymous resources in [RDF-MS].) However, we would need some form of explicit identifier for that node if we wanted to represent this graph as triples. To see this, we can try to write the triples corresponding to what is shown in Figure 6. What we would get would be something like:

exstaff:85740  exterms:address  ??? .
???            exterms:street   "1501 Grant Avenue" .
???            exterms:city     "Bedford" .
???            exterms:state    "Massachusetts" .
???            exterms:Zip      "01730" 

where ??? stands for something that indicates the presence of the blank node. Since a complex graph might contain more than one blank node, we would also need a way to differentiate between these multiple blank nodes in a triples representation of the graph. To do this, we use blank node identifiers, having the form _:name, to indicate the presence of blank nodes in triples. For instance, in this example we might use the blank node identifier _:johnaddress to refer to the blank node, in which case the resulting triples might be:

exstaff:85740  exterms:address  _:johnaddress .
_:johnaddress  exterms:street   "1501 Grant Avenue" .
_:johnaddress  exterms:city     "Bedford" .
_:johnaddress  exterms:state    "Massachusetts" .
_:johnaddress  exterms:Zip      "01730" .

In a triples representation of a graph, each distinct blank node in the graph is given a different blank node identifier. Unlike URIrefs and literals, blank node identifiers are not considered to be actual parts of the RDF graph (this can be seen by looking at the drawn graph in Figure 6 and noting that the blank node has no blank node identifier). Blank node identifiers are just a way of representing the blank nodes in a graph (and distinguishing one blank node from another) when the graph is written in triple form. Blank node identifiers also have significance only within the triples representing a single graph (two different graphs with the same number of blank nodes might independently use the same blank node identifiers to distinguish them, and it would be incorrect to assume that blank nodes from different graphs having the same blank node identifiers are the same). If it is expected that a node in a graph will need to be referenced from outside the graph, a URIref should be assigned to identify it.

At the beginning of this section, we noted that we can represent aggregate structures, like John Smith's address, by considering the aggregate thing we want to talk about as a resource, and then making statements about that new resource. This example illustrates an important aspect of RDF: RDF directly represents only binary relationships, e.g. the relationship between John Smith and the literal representing his address. When we try to represent the relationship between John and the group of separate components of this address, we are dealing with an n-ary (n-way) relationship (in this case, n=5) between John and the street, city, state, and zip components. In order to represent such structures directly in RDF (e.g., considering the address as a group of street, city, state, and zip sub-components), we need to break this n-way relationship up into a group of separate binary relationships. Blank nodes give us one way to do this. Each time we have an n-ary relationship, we can choose one of the participants as the subject of the relationship (John in this case), and create a blank node to represent the rest of the relationship (John's address in this case). We can then represent the remaining participants in the relationship (such as the city in our example) as separate properties of the new resource represented by the blank node.

Blank nodes also give us a way to more accurately make statements about resources that may not have URIs, but that are described in terms of relationships with other resources that do have URIs. For example, when making statements about a person, say Jane Smith, it may seem natural to use a URI based on that person's email address as her URI, e.g., mailto:jane@example.org. However, this approach can cause problems. For example, we may want to record information about Jane's mailbox (e.g., the server it is on) as well as about Jane herself (e.g., her current address), and using a URIref for Jane based on her email address makes it difficult to know which thing we're talking about. The same problem exists when a company's Web page URL, say http://www.example.com/, is used as the URI of the company itself. Once again, we may need to record information about the Web page (e.g., who created it and when) as well as about the company, and using http://www.example.com/ as an identifier for both makes it difficult to know which thing we're talking about.

The fundamental problem is that using Jane's mailbox as a stand-in for Jane isn't really accurate: Jane and her mailbox are not the same thing, and hence their identifiers should be different. When Jane herself doesn't have a URI, a blank node gives us a more accurate way of modeling this situation. We can represent Jane by a blank node, and give the blank node an exterms:mailbox property having the URIref mailto:jane@example.org as its value. We can also assign the blank node an rdf:type property with a value of exterms:Person (we will discuss types in more detail in the following sections), an exterms:name property with a value of "Jane Smith", and any other descriptive information we might want to provide, as shown in the following triples:

_:jane  exterms:mailbox   mailto:jane@example.org .
_:jane  rdf:type       exterms:Person .
_:jane  exterms:name   "Jane Smith" .
_:jane  exterms:empID  "23748"
_:jane  exterms:age    "26" .

This says, accurately, that "there is a resource of type exterms:Person, whose electronic mailbox is identified by mailto:jane@example.org, whose name is Jane Smith, etc." That is, the blank node can be read as "there is a resource". Statements with that blank node as subject then provide information about the characteristics of that resource.

In practice, using blank nodes instead of URIrefs in these cases doesn't change the way we actually handle this kind of information very much. For example, if we know independently that an email address uniquely identifies someone at example.org (particularly if the address is unlikely to be reused), we can still use that fact to associate information about that person from multiple sources, even though the email address is not the person's URI. For example, if we were to find another piece of RDF on the web that described a book, and gives the author's contact information as mailto:jane@example.org, we might reasonably conclude that the author's name is Jane Smith. The point is that saying something like "the author of the book is mailto:jane@example.org" is typically a shorthand for "the author of the book is someone whose mailbox is mailto:jane@example.org". Using a blank node to represent this "someone" is just a more accurate way to represent the real world situation. (Incidentally, some RDF-based schema languages allow specifying that certain properties are unique identifiers. This is discussed further in Section 5.5.)

2.4 Typed Literals

In the last section, we described how to handle situations in which we needed to take property values represented by plain literals, and break them up into structured values that identify the individual parts of those property values. Using this approach, instead of, say, recording the date a Web page was created as a single exterms:creation-date property, with a single plain literal as its value, we could represent the value as a structure consisting of the month, day, and year as separate pieces of information. However, so far, we've followed the practice of representing any constant values that serve as objects in RDF statements by these plain (untyped) literals, even when we probably intend for the value of the property to be a number (e.g., the value of a year or age property) or some other kind of more specialized value.

For example, in Figure 4 we illustrated an RDF graph recording information about John Smith. In that graph, we recorded the value of John Smith's exterms:age property as the plain literal "27", as shown in Figure 7:

Figure 7: Representing John Smith's Age

In this case, our hypothetical organization example.org probably intends for "27" to be interpreted as a number, rather than as the string consisting of the character "2" followed by the character "7". However, an application reading that literal "27" would only know to do that if the application was explicitly given the information that the literal "27" was intended to represent a number, and knew which number the literal "27" was supposed to represent. The common practice in programming languages or database systems is to provide this kind of information by associating a datatype with the literal, in this case, a datatype like decimal or integer. An application that understands the datatype then knows, for example, whether the literal "10" is intended to represent the number ten, the number two, or the string consisting of the character "1" followed by the character "0", depending on whether the specified datatype is integer, binary, or string. In RDF, typed literals are used to provide this kind of information.

Using a typed literal, we could describe John Smith's age as being the integer number 27 using the triple:

<http://www.example.org/staffid/85740>  <http://www.example.org/terms/age> "27"^^<http://www.w3.org/2001/XMLSchema#integer> .

or, using our QName simplification for writing long URIs:

exstaff:85740  exterms:age  "27"^^xsd:integer .

or as shown in Figure 8:

Figure 8: A Typed Literal for John Smith's Age

Similarly, in the graph shown in Figure 3 describing information about a Web page, we recorded the value of the page's exterms:creation-date property as the plain literal "August 16, 1999". However, using a typed literal, we could describe the creation date of the Web page as being the date August 16, 1999, using the triple:

ex:index.html  exterms:creation-date  "1999-08-16"^^xsd:date .

or as shown in Figure 9:

Figure 9: A Typed Literal for a Web Page's Creation Date

As these examples illustrate, an RDF typed literal is formed by explicitly pairing a URIref identifying a particular datatype (in these examples, the datatypes integer and date from XML Schema Part 2: Datatypes [XML-SCHEMA2]) with a literal that the datatype uses to represent the intended value. In each case, this results in a single node in the RDF graph with the pair as its label.

Unlike typical programming languages and database systems, RDF has no built-in set of datatypes of its own, such as datatypes for integers, reals, strings, or dates. Instead, it relies on datatypes defined elsewhere that can be identified by a datatype URIref. RDF typed literals simply provide a way to explicitly indicate, for a given literal, what datatype should be used to interpret it. As far as RDF is concerned, you can write any pair of URIref and literal you want as a typed literal. This gives RDF the flexibility to directly represent information coming from different sources without the need to perform type conversions between these sources and a native set of RDF datatypes. (Type conversions would still be required when moving information between systems with different datatype systems, but RDF would impose no extra conversions into and out of a native set of RDF types.)

The actual interpretation of a typed literal (determining the value it denotes) must be performed by an RDF processor that is programmed to "understand" that datatype. In particular, we've used XML Schema datatypes in the two examples we've just presented, and will be using XML Schema datatypes in most of our other examples as well (for one thing, XML Schema data types have URIrefs we can use to refer to them, specified in [XML-SCHEMA2]). XML Schema datatypes have a "first among equals" status in RDF. They are treated no differently than any other datatype, but they are expected to be the most widely used, and therefore the most likely to be interoperable among different software. As a result, it is expected that many RDF processors will be programmed to recognize these datatypes. However, RDF software could be programmed to process other sets of datatypes as well.

RDF datatype concepts also borrow a conceptual framework from XML Schema datatypes [XML-SCHEMA2] to more precisely describe datatype requirements. RDF's use of this framework is defined in RDF Concepts and Abstract Syntax [RDF-CONCEPTS].

The flexibility provided by RDF typed literals comes at a price. For one thing, RDF has no way of knowing whether or not a URIref in a typed literal actually identifies a datatype. Moreover, even when a URIref does identify a datatype, RDF itself does not define the validity of pairing that datatype with a particular literal. This validity can only be determined by software built to understand that datatype. For example, you could write the triple:

exstaff:85740  exterms:age  "pumpkin"^^xsd:integer .

or the graph shown in Figure 10:

Figure 10: An Invalid Typed Literal for John Smith's Age

The typed literal in Figure 10 is valid RDF, but obviously an error as far as the xsd:integer datatype is concerned, since "pumpkin" is not defined as being a legal literal for xsd:integer.

In general, RDF software may be called on to process RDF data that contains datatypes that it has not been programmed to understand, in which case there are some things the software will not be able to do. This includes recognizing whether or not a particular string represents a legal value for a particular datatype. In this case, RDF software not built to understand the xsd:integer datatype would not be able to recognize that "pumpkin" is not a valid xsd:integer.

2.5. Concepts Summary

Taken as a whole, RDF is simple: nodes-and-arcs diagrams interpreted as statements about things identified by URIrefs. This section has presented an introduction to these concepts. As noted earlier, the normative (i.e., definitive) RDF specification describing these concepts is the RDF Concepts and Abstract Syntax [RDF-CONCEPTS], which should be consulted for further information. Together with the RDF Semantics [RDF-SEMANTICS] document, [RDF-CONCEPTS] provides the definition of the abstract syntax for RDF, together with its formal semantics (meaning).

However, in addition to the basic techniques for representing RDF statements in diagrams (or triples) we've seen so far, it should be clear that we also need a way for people to define the vocabularies they intend to use in those statements, including:

• defining types of things (like ex:Person)
• defining properties (like ex:age and ex:creation-date), and
• defining the types of things that can serve as the subjects or objects of statements involving those properties (such as specifying that the value of an ex:age property should always be an xsd:integer).

The basis for describing such vocabularies in RDF is the RDF Vocabulary Description Language 1.0: RDF Schema [RDF-VOCABULARY], which will be described in Section 5.

Additional background on the basic ideas underlying RDF, and its role in providing a general language for describing Web information, can be found in [WEBDATA]. RDF draws upon ideas from knowledge representation, artificial intelligence, and data management, including Conceptual Graphs, logic-based knowledge representation, frames, and relational databases. Some possible sources of background information on these subjects include [Sowa], [CG], [KIF], [Hayes], [Luger], and [Gray].

3.1. Basic Principles

We can illustrate the basic ideas behind the RDF/XML syntax using some of the examples we've presented already. Suppose we want to represent one of our initial statements:

http://www.example.org/index.html has a creation-date whose value is August 16, 1999

The RDF graph for this single statement, after assigning a URIref to the creation-date property, is shown in Figure 11:

Figure 11: A Simple RDF Statement

with a triple representation of:

ex:index.html  exterms:creation-date  "August 16, 1999" .

Example 2 shows the RDF/XML syntax corresponding to the graph in Figure 11:

1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.             xmlns:exterms="http://www.example.org/terms/">

4.   <rdf:Description rdf:about="http://www.example.org/index.html">
5.       <exterms:creation-date>August 16, 1999</exterms:creation-date>
6.   </rdf:Description>

7. </rdf:RDF>

(we have added line numbers to use in explaining the example).

This seems like a lot of overhead. We can understand better what is going on by considering each part of this XML in turn (a brief introduction to XML is provided in Appendix B).

Line 1, <?xml version="1.0"?>, is the XML declaration, which indicates that the following content is XML, and what version of XML it is.

Line 2 begins an rdf:RDF element. This indicates that the following XML content (starting here and ending with the </rdf:RDF> in Line 7) is intended to represent RDF. Following the rdf:RDF on this same line is an XML namespace declaration, represented as an xmlns attribute of the rdf:RDF start-tag. This declaration specifies that all tags in this content prefixed with rdf: are part of the namespace identified by the URIref http://www.w3.org/1999/02/22-rdf-syntax-ns#. This namespace is the source for the RDF-specific terms used in RDF/XML.

Line 3 specifies another XML namespace declaration, this time for the prefix exterms:. This is expressed as another xmlns attribute of the rdf:RDF element, and specifies that the namespace URIref http://www.example.org/terms/ is to be associated with the exterms: prefix. This namespace is the source for the specific terms defined by our example organization, example.org. The ">" at the end of line 3 indicates the end of the rdf:RDF start-tag. Lines 1-3 are general "housekeeping" necessary to indicate that we are defining RDF/XML content, and to identify the sources of the terms we are using.

Lines 4-6 provide the RDF/XML for the specific statement we're representing. An obvious way to talk about any RDF statement is to say it's a description, and that it's about the subject of the statement (in this case, about http://www.example.org/index.html), and this is the way RDF/XML represents the statement. The rdf:Description start-tag in Line 4 indicates that we're starting a description of a resource, and goes on to identify the resource the statement is about (the subject of the statement) using the rdf:about attribute to specify the URIref of the subject resource. Line 5 provides a property element, with the QName <exterms:creation-date> as its tag, to hold the plain literal August 19, 1999 of the creation-date property of the statement. It is nested within the containing rdf:Description element, indicating that this property applies to the resource specified in the rdf:about attribute of the rdf:Description element. The URIref of the creation-date property corresponding to the QName <exterms:creation-date> is obtained by appending the name creation-date to the URIref of the exterms: prefix (http://www.example.org/terms/), giving http://www.example.org/terms/creation-date. Line 6 indicates the end of this particular rdf:Description element.

Finally, Line 7 indicates the end of the rdf:RDF element started on Line 2.

Example 2 illustrates the basic ideas used by RDF/XML to encode an RDF graph as XML elements, attributes, element content, and attribute values. The URIref labels for properties and object nodes are written as XML QNames, consisting of a short prefix denoting a namespace URI, together with a local name denoting a namespace-qualified element or attribute, as described in Appendix B. The (namespace URIref, local name) pair are chosen so that concatenating them forms the URIref of the original node. The URIrefs of subject nodes are written as XML attribute values. The nodes labeled by literals (which are always object nodes) become element text content or attribute values. (All these options are described in [RDF-SYNTAX]).

We could represent an RDF graph consisting of multiple statements in RDF/XML by using RDF/XML similar to Lines 4-6 in Example 2 to separately represent each statement. For example, if we wanted to write the following two statements:

ex:index.html  exterms:creation-date  "August 16, 1999" .
ex:index.html  exterms:language "English" .

we could write the RDF/XML in Example 3:

1.  <?xml version="1.0"?>
2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.              xmlns:exterms="http://www.example.org/terms/">

4.    <rdf:Description rdf:about="http://www.example.org/index.html">
5.        <exterms:creation-date>August 16, 1999</exterms:creation-date>
6.    </rdf:Description>

7.    <rdf:Description rdf:about="http://www.example.org/index.html">
8.        <exterms:language>English</exterms:language>
9.    </rdf:Description>

10. </rdf:RDF>

Example 3 is the same as Example 2, with the addition of lines 7-9, a second rdf:Description element to represent the second statement. We could represent an arbitrary number of additional statements in the same way, using a separate rdf:Description element for each additional statement. As Example 3 illustrates, once the overhead of writing the XML and namespace declarations is dealt with, writing each additional RDF statement in RDF/XML is both straightforward and not too complicated.

The RDF/XML syntax provides a number of abbreviations to make common uses easier to write. For example, it is typical for the same resource to be described with several properties and values at the same time, as in Example 3, where the resource ex:index.html is the subject of several statements. To handle such cases, RDF/XML allows multiple property elements representing those properties to be nested within the rdf:Description element that identifies the subject resource. For example, if we wanted to represent the following group of statements about http://www.example.org/index.html:

ex:index.html  dc:creator  exstaff:85740 .
ex:index.html  exterms:creation-date  "August 16, 1999" .
ex:index.html  exterms:language "English" .

whose graph (the same as Figure 3) is shown in Figure 12:

Figure 12: Several Statements About the Same Resource

we could write the RDF/XML as shown in Example 4:

1.  <?xml version="1.0"?>
2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.              xmlns:dc="http://purl.org/dc/elements/1.1/"
4.              xmlns:exterms="http://www.example.org/terms/">

5.    <rdf:Description rdf:about="http://www.example.org/index.html">
6.         <exterms:creation-date>August 16, 1999</exterms:creation-date>
7.         <exterms:language>English</exterms:language>
8.         <dc:creator rdf:resource="http://www.example.org/staffid/85740"/>
9.    </rdf:Description>

10. </rdf:RDF>

Compared with the previous two examples, Example 4 adds an additional namespace declaration (in Line 3), and an additional creator property element (in Line 8). In addition, we've nested the property elements for the three properties whose subject is http://www.example.org/index.html within a single rdf:Description element identifying that subject, rather than writing a separate rdf:Description element for each statement.

Line 8 also introduces a new form of property element. (The element tag also uses a different namespace prefix, the new namespace prefix dc: we defined in Line 3.) The exterms:language element in Line 7 is similar to the exterms:creation-date element we defined in Example 2. Both these elements represent properties with plain literals as property values, and such elements are specified by enclosing the literal within start- and end-tags corresponding to the property name. However, the dc:creator element on Line 8 represents a property whose value is another resource, rather than a literal. If we had written the URIref of this resource as a plain literal within start- and end-tags in the same way as we wrote the literal values of the other elements, we would be saying that the value of the dc:creator element was the character string http://www.example.org/staffid/85740, rather than the resource identified by that literal interpreted as a URIref. In order to indicate the difference, we've written the dc:creator element using what XML calls an empty-element tag (it has no separate end-tag), and defined the property value using an rdf:resource attribute within that empty element. The rdf:resource attribute indicates that the property element's value is another resource, identified by its URIref. Because the URIref is being used as an attribute value, RDF/XML requires that we write out the URIref, rather than abbreviating it as a QName, as we've done in writing element and attribute names.

It is important to understand that the RDF/XML in the Example 4 is an abbreviation. The RDF/XML in Example 5, in which each statement is written separately, describes exactly the same RDF graph:

 <?xml version="1.0"?>
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:exterms="http://www.example.org/terms/">

   <rdf:Description rdf:about="http://www.example.org/index.html">
       <exterms:creation-date>August 16, 1999</exterms:creation-date>
   </rdf:Description>

   <rdf:Description rdf:about="http://www.example.org/index.html">
       <exterms:language>English</exterms:language>
   </rdf:Description>

   <rdf:Description rdf:about="http://www.example.org/index.html">
       <dc:creator rdf:resource="http://www.example.org/staffid/85740"/>
   </rdf:Description>

 </rdf:RDF>

We will describe a few additional RDF/XML abbreviations in the following sections. However, you should consult [RDF-SYNTAX] for a more thorough description of the abbreviations that are available.

RDF/XML also allows us to represent graphs that include nodes that have no URIrefs, i.e., blank nodes. For example, Figure 13 (taken from [RDF-SYNTAX]) shows a graph saying "the document 'http://www.w3.org/TR/rdf-syntax-grammar' has a title 'RDF/XML Syntax Specification (Revised)' and has an editor, the editor has a name 'Dave Beckett' and a home page 'http://purl.org/net/dajobe/' ".

Figure 13: A Graph Containing a Blank Node

This illustrates an idea we discussed in Section 2.3: the use of a blank node to represent something that does not have a URIref, but can be described in terms of other information. In this case, the blank node represents a person, the editor of the document, and the person is described by his name and home page.

RDF/XML provides several ways to represent blank nodes. These are described in [RDF-SYNTAX]. The approach we will illustrate here, which is the most direct approach, is to assign a blank node identifier to the blank node. A blank node identifier serves to identify a blank node within a particular RDF/XML document but, unlike a URIref, is unknown outside the document in which it is assigned. A blank node is referred to in RDF/XML using an rdf:nodeID attribute with a blank node identifier as its value in places where the URIref of a resource node would otherwise appear. Specifically, a statement with a blank node as its subject can be written in RDF/XML using an rdf:Description element which specifies an rdf:nodeID attribute instead of an rdf:about attribute. Similarly, a statement with a blank node as its object can be written using a property element with an rdf:nodeID attribute instead of an rdf:resource attribute. Using rdf:nodeID, Example 6 shows the RDF/XML corresponding to Figure 13:

1.  <?xml version="1.0"?>
2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.              xmlns:dc="http://purl.org/dc/elements/1.1/"
4.              xmlns:exterms="http://example.org/stuff/1.0/">

5.     <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
6.       <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
7.       <exterms:editor rdf:nodeID="abc"/>
8.     </rdf:Description>

9.     <rdf:Description rdf:nodeID="abc">
10.        <exterms:fullName>Dave Beckett</exterms:fullName>
11.        <exterms:homePage rdf:resource="http://purl.org/net/dajobe/"/>
12.    </rdf:Description>

13. </rdf:RDF>

In Example 6, the blank node identifier abc is used in Line 9 to identify the blank node as the subject of several statements, and is used in Line 7 to indicate that the blank node is the value of a resource's exterms:editor property. The advantage of using a blank node identifier over some of the other approaches described in [RDF-SYNTAX] is that using a blank node identifier allows the same blank node to be referred to in more than one place in the same RDF/XML document.

Finally, the typed literals we described in Section 2.4 may be used as property values instead of the plain literals we have used in the examples so far. A typed literal is represented in RDF/XML by adding an rdf:datatype attribute specifying a datatype URIref to the property element containing the literal.

For example, to change the statement from Example 2 to use a typed literal instead of a plain literal for the creation-date property, the triple representation would be:

ex:index.html  exterms:creation-date  "1999-08-16"^^xsd:date .

with corresponding RDF/XML syntax shown in Example 7:

1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.             xmlns:exterms="http://www.example.org/terms/">

4.   <rdf:Description rdf:about="http://www.example.org/index.html">
5.     <exterms:creation-date rdf:datatype=
         "http://www.w3.org/2001/XMLSchema#date">1999-08-16
       </exterms:creation-date>
6.   </rdf:Description>

7. </rdf:RDF>

In Line 5 of Example 7, a typed literal is given as the value of the ex:creation-date property element by adding an rdf:datatype attribute to the element's start-tag to specify the datatype. The value of this attribute is the URIref of the datatype, in this case, the URIref of the XML Schema date datatype. Since this is an attribute value, the URIref must be written out, rather than using the QName abbreviation xsd:date that we used in the triple. A literal appropriate to this datatype is then written as the element content, in this case, the literal 1999-08-16, which is the literal representation for August 16, 1999 in the XML Schema date datatype.

For the most part, we will continue to use plain (untyped) literals in our examples. However, you should be aware that typed literals from appropriate datatypes, such as XML Schema datatypes, can always be used instead.

Although additional abbreviated forms for writing RDF/XML are available, the facilities we have illustrated so far provide a simple but general way to serialize graphs in RDF/XML. Using these facilities, an RDF graph is written in RDF/XML as follows:

• All blank nodes are assigned blank node identifiers.
• Each node is listed in turn as the subject of an un-nested rdf:Description element, using an rdf:about attribute if the node has a URIref, or an rdf:nodeID attribute if the node is blank.
  For each triple with this node as subject, an appropriate property element is created, with either literal content (possibly empty), an rdf:resource attribute specifying the object of the triple (if the object node has a URIref), or an rdf:nodeID attribute specifying the object of the triple (if the object node is blank).

Compared to some of the more abbreviated serialization approaches described in [RDF-SYNTAX], this simple serialization approach provides the most direct representation of the actual graph structure, and is particularly recommended for applications in which the output RDF/XML is to be used in further RDF processing.

3.2. Abbreviating and Organizing RDF URIrefs

So far, we've been describing resources that we imagine have been given URIrefs already. For instance, in our initial examples, we provided descriptive information about example.org's web page, whose URIref was http://www.example.org/index.html. We referred to this resource using an rdf:about attribute citing its full URIref. Although RDF doesn't specify or control how URIrefs are assigned to resources, sometimes we want to achieve the effect of assigning URIrefs to resources that are part of an organized group of resources. For example, suppose a sporting goods company, example.com, wanted to provide an RDF-based catalog of its products, such as tents, hiking boots, and so on, as an RDF/XML document, identified by (and located at) http://www.example.com/2002/04/products. In that resource, each product might be given a separate RDF description. This catalog, along with one of these descriptions, the catalog entry for a model of tent called the "Overnighter", might be written in RDF/XML as shown in Example 8:

1.   <?xml version="1.0"?>
2.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.               xmlns:exterms="http://www.example.com/terms/">

4.     <rdf:Description rdf:ID="item10245">
5.          <exterms:model>Overnighter</exterms:model>
6.          <exterms:sleeps>2</exterms:sleeps>
7.          <exterms:weight>2.4</exterms:weight>
8.          <exterms:packedSize>14x56</exterms:packedSize>
9.     </rdf:Description>

  ...other product descriptions...

10.  </rdf:RDF>

(We've included the surrounding xml, RDF, and namespace information in lines 1 through 3, and line 10, but this information would only need to be defined once for the whole catalog, not repeated for each entry in the catalog).

Example 8 is similar to our previous examples in the way it represents the properties (model, sleeping capacity, weight) of the resource (the tent) being described. However, in line 4, the rdf:Description element has an rdf:ID attribute instead of an rdf:about attribute. Using rdf:ID indicates that we are using a fragment identifier, given by the value of the rdf:ID attribute (item10245 in this case, which might be the catalog number assigned by example.com), as an abbreviation of the complete URIref of the resource we are describing. The fragment identifier item10245 will be interpreted relative to a base URI, in this case, the URI of the containing catalog document. The full URIref for the tent is formed by taking the base URI (of the catalog), and appending # (to indicate that what follows is a fragment identifier) and then item10245 to it, giving the absolute URIref http://www.example.com/2002/04/products#item10245.

The rdf:ID attribute is somewhat similar to the ID attribute in XML and HTML, in that it defines a name which must be unique within the document (in this case, the catalog) in which it is defined. In this case, the rdf:ID attribute appears to be assigning a name (item10245) to this particular kind of tent. Any other RDF/XML within this catalog could refer to the tent by using the relative URIref #item10245 in an rdf:about attribute. This would be understood as being a URIref defined relative to the base URIref of the catalog. Using a similar abbreviation, we could also have given the URIref of the tent by specifying rdf:about="#item10245" in the catalog entry (i.e., by specifying the relative URIref directly) instead of rdf:ID="item10245" . The two forms are essentially synonyms: the full URIref formed by RDF/XML is the same in either case: http://www.example.com/2002/04/products#item10245. In either case, example.com would be giving the URIref for the tent in a two-stage process, first assigning the URIref for the whole catalog, and then using a relative URIref in the description of the tent in the catalog to indicate the URIref that has been assigned to this particular kind of tent. Moreover, you can think of this use of a relative URIref as either being an abbreviation for a full URIref that has been assigned to the tent independently of the RDF, or as being the assignment of the URIref to the tent within the catalog.

RDF located outside the catalog could refer to this tent by using the full URIref, i.e., by concatenating the relative URIref #item10245 of the tent to the base URI of the catalog, forming the absolute URIref http://www.example.com/2002/04/products#item10245. For example, an outdoor sports web site exampleRatings.com might use RDF to provide ratings of various tents. The (5-star) rating given to the tent described in Example 8 might then be represented on exampleRatings.com's web site as shown in Example 9:

1.  <?xml version="1.0"?>
2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.              xmlns:sportex="http://www.exampleRatings.com/terms/">

4.    <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">
5.         <sportex:ratingBy>Richard Roe</sportex:ratingBy>
6.         <sportex:numberStars>5</sportex:numberStars>
7.    </rdf:Description>
8.  </rdf:RDF>

In Example 9, line 4 uses an rdf:Description element with an rdf:about attribute whose value is the full URIref of the tent. The use of this URIref allows the tent being referred to in the rating to be precisely identified.

These examples illustrate several points. First, even though RDF doesn't specify or control how URIrefs are assigned to resources (in this case, the various tents and other items in the catalog), the effect of assigning URIrefs to resources in RDF can be achieved by combining a process (external to RDF) that identifies a single document (the catalog in this case) as the source for descriptions of those resources, with the use of relative URIrefs in descriptions of those resources within that document. For instance, example.com could use this catalog as the central source where its products are described, with the understanding that if a product's item number isn't in an entry in this catalog, it's not a product known to example.com. (Note that RDF does not assume any particular relationship exists between two resources just because their URIrefs have the same base, or are otherwise similar. This relationship may be known to example.com, but it is not directly defined by RDF.)

These examples also illustrate one of the basic architectural principles of the Web, which is that anyone should be able say anything they want about existing resources [BERNERS-LEE98]. The examples further illustrate that the RDF describing a particular resource does not need to be located all in one place; instead, it may be distributed throughout the web. This is true not only for situations like this one, in which one organization is rating or commenting on resources defined by another, but also for situations in which the original definer of a resource (or anyone else) wishes to amplify the description of that resource by providing additional information about it. This may be done either by modifying the RDF document in which the resource was originally described, to add the properties and values needed to describe the additional information, or, as this example illustrates, by creating a separate document, and providing the additional properties and values in rdf:Description elements that refer to the original resource via its URIref using rdf:about.

The discussion above indicated that fragment identifiers such as #item10245 will be interpreted relative to a base URI. By default, this base URI would be the URI of the resource in which the fragment identifier is used. However, in some cases it is desirable to be able to explicitly specify this base URI. For instance, suppose that in addition to the catalog located at http://www.example.com/2002/04/products, example.org wanted to provide a duplicate catalog on a mirror site, say at http://mirror.example.com/2002/04/products. This could create a problem, since if the catalog was accessed from the mirror site, the URIref for our example tent would be generated from the URI of the containing document, forming http://mirror.example.com/2002/04/products#item10245, rather than http://www.example.com/2002/04/products#item10245, and hence would apparently refer to a different resource than the one intended. Alternatively, example.org might want to assign a base URIref for its set of product URIrefs without publishing a single source document whose location defines the base.

To deal with such cases, RDF/XML supports XML Base [XML-BASE], which allows an XML document to specify a base URI other than the URI of the document itself. Example 10 shows how we would define the catalog using XML Base:

1.   <?xml version="1.0"?>
2.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.               xmlns:exterms="http://www.example.com/terms/"
4.               xml:base="http://www.example.com/2002/04/products">

5.     <rdf:Description rdf:ID="item10245">
6.          <exterms:model>Overnighter</exterms:model>
7.          <exterms:sleeps>2</exterms:sleeps>
8.          <exterms:weight>2.4</exterms:weight>
9.          <exterms:packedSize>14x56</exterms:packedSize>
10.    </rdf:Description>

  ...other product descriptions...

11.  </rdf:RDF>

In Example 10, the xml:base declaration in line 4 specifies that the base URI for the content within the rdf:RDF element (until another xml:base attribute is specified) is http://www.example.com/2002/04/products, and all relative URIrefs cited within that content will be interpreted relative to that base, no matter what the URI of the containing document is. As a result, the relative URIref of our tent, #item10245, will be interpreted as the same absolute URIref, http://www.example.com/2002/04/products#item10245, no matter what the actual URI of the catalog document is, or whether the base URIref actually identifies a particular document at all.

So far, we've been talking about a single product description, a particular model of tent, from example.com's catalog. However, example.com will probably offer several different models of tents, as well as multiple instances of other categories of products, such as backpacks, hiking boots, and so on. This idea of things being classified into different kinds or categories is similar to the programming language concept of objects having different types or classes. RDF supports this concept by providing a predefined property, rdf:type. When an RDF resource is described with an rdf:type property, the value of that property is considered to be a resource that represents a category or class of things, and the subject of that property is considered to be an instance of that category or class. Using rdf:type, Example 11 shows how example.com might indicate that our product description is that of a tent:

1.   <?xml version="1.0"?>
2.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.               xmlns:exterms="http://www.example.com/terms/"
4.               xml:base="http://www.example.com/2002/04/products">

5.     <rdf:Description rdf:ID="item10245">
6.          <rdf:type rdf:resource="http://www.example.com/terms/Tent" />
7.          <exterms:model>Overnighter</exterms:model>
8.          <exterms:sleeps>2</exterms:sleeps>
9.          <exterms:weight>2.4</exterms:weight>
10.         <exterms:packedSize>14x56</exterms:packedSize>
11.    </rdf:Description>

  ...other product descriptions...

12.  </rdf:RDF>

In Example 11, the rdf:type property in Line 6 indicates that the instance belongs to a class identified by the URIref http://www.example.com/terms/Tent. In this case, we imagine that example.com has described its classes as part of the same vocabulary that it uses to describe its other terms (such as the property exterms:weight), so we use the absolute URIref of the class to refer to it. If example.com had described these classes as part of the product catalog itself, we could have used the relative URIref #Tent to refer to it.

RDF itself does not define a vocabulary for defining application-specific classes of things, such as Tent in this example. Instead, such classes would be described in an RDF Schema. The facilities provided by RDF for describing application-specific classes and their properties are discussed in Section 5. Other such facilities for describing classes can also be defined, such as the DAML+OIL and OWL languages described in Section 5.5.

Since describing resources as instances of specific types or classes is fairly common, RDF/XML provides a special abbreviation for instances described as members of classes using the rdf:type property. In this abbrevation, the rdf:type property and its value are removed, and the rdf:Description element is replaced by an element whose name is the class name. Using this abbreviation, example.com's tent from Example 11 could also be described as shown in Example 12:

1.   <?xml version="1.0"?>
2.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.               xmlns:exterms="http://www.example.com/terms/"
4.               xml:base="http://www.example.com/2002/04/products">

5.     <exterms:Tent rdf:ID="item10245">
6.          <exterms:model>Overnighter</exterms:model>
7.          <exterms:sleeps>2</exterms:sleeps>
8.          <exterms:weight>2.4</exterms:weight>
9.          <exterms:packedSize>14x56</exterms:packedSize>
10.    </exterms:Tent>

  ...other product descriptions...

11.  </rdf:RDF>

Both Example 11 and Example 12 illustrate that RDF statements can be written in RDF/XML in a way that closely resembles descriptions that might have been written directly in XML. This is an important consideration, given the increasing use of XML in all kinds of applications, since it suggests that RDF could be used in these applications without requiring major changes in the way their information is structured.

3.3. RDF/XML Summary

The examples above have illustrated some of the basic ideas behind the RDF/XML syntax. These examples provide enough information to enable you to begin writing useful RDF/XML. For a more thorough discussion of the principles behind the modeling of RDF statements in XML (known as striping), together with a presentation of the other RDF/XML abbreviations available, and other details and examples about writing RDF in XML, you should refer to the RDF/XML Syntax Specification [RDF-SYNTAX].

4.1. RDF Containers

There is often a need to describe groups of things. For example, we might want to say that a book was created by several authors, or to list the students in a course, or the software modules in a package. RDF provides several pre-defined types and properties that can be used to describe such groups.

First, RDF provides a container vocabulary consisting of three predefined types (together with some associated predefined properties). A container is a resource that contains things. The contained things are called members. The members of a container may be resources or literals. RDF defines three types of containers:

• rdf:Bag
• rdf:Seq
• rdf:Alt

A Bag (a resource having type rdf:Bag) is a group of resources or literals, possibly including duplicate members, where there is no significance in the order of the members. For example, a Bag might be used to describe a group of part numbers in which the order of entry or processing of the part numbers does not matter.

A Sequence or Seq (a resource having type rdf:Seq) is a group of resources or literals, possibly including duplicate members, where the order of the members is significant. For example, a Sequence might be used to describe a group that must be maintained in alphabetical order.

An Alternative or Alt (a resource having type rdf:Alt) is a group of resources or literals that are alternatives (typically for a single value of a property). For example, an Alt might be used to describe alternative language translations for the title of a book, or to describe a list of alternative Internet sites at which a resource might be found. An application using a property whose value is an Alt container should be aware that it can choose any one of the members of the group as appropriate.

To describe a resource as being one of these types of containers, you give the resource an rdf:type property whose value is one of the pre-defined resources rdf:Bag, rdf:Seq, or rdf:Alt (whichever is appropriate). The container resource (which may either be a blank node or a resource with a URIref) denotes the group as a whole. The members of the container can be described by defining a container membership property for each member with the container resource as its subject and the member as its object. These container membership properties have names of the form rdf:_n, where n is an integer, e.g., rdf:_1, rdf_2, rdf_3, and so on, and are used specifically for describing the members of containers. Container resources may also have other properties that describe the container, in addition to the container membership properties and the rdf:type property.

It is important to understand that while these types of containers are described using pre-defined RDF types and properties, any special meanings associated with these containers, e.g., that the members of an Alt container are alternative values, are only intended meanings. These specific container types, and their definitions, are provided with the aim of establishing a shared convention among those who need to describe groups of things. All RDF does is provide the types and properties that can be used to construct the RDF graphs to describe each type of container. RDF has no more built-in understanding of what a resource of type rdf:Bag is than it has of what a resource of type ex:Tent, that we discussed in Section 3.2, is. In each case, applications must be written to behave according to the particular meaning involved for each type. This point will be expanded on in the following examples.

A typical use of a container is to indicate that the value of a property is a group of things. For example, to represent the sentence "Course 6.001 has the students Amy, Tim, John, Mary, and Sue", you could describe the course by giving it a s:students property whose value is a container of type rdf:Bag (the group of students) and then, using the container membership properties, describe the individual students as being members of that container, as in the RDF graph shown in Figure 14:

Figure 14: A Simple Bag Container Description

Since the value of the s:students property in this example is described as a Bag, there is no intended significance in the order given for the URIrefs of each student, even though the properties in the graph have integers in their names. It is up to applications creating and processing graphs that include rdf:Bag containers to ignore any (apparent) order in the names of the membership properties.

RDF/XML provides some special syntax and abbreviations to make it simpler to describe such containers. For example, Example 13 describes the graph shown in Figure 14:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://example.edu/students/vocab#">

   <rdf:Description rdf:about="http://example.edu/courses/6.001">
      <s:students>
         <rdf:Bag>
            <rdf:li rdf:resource="http://example.edu/students/Amy"/>
            <rdf:li rdf:resource="http://example.edu/students/Tim"/>
            <rdf:li rdf:resource="http://example.edu/students/John"/>
            <rdf:li rdf:resource="http://example.edu/students/Mary"/>
            <rdf:li rdf:resource="http://example.edu/students/Sue"/>
         </rdf:Bag>
      </s:students>
   </rdf:Description>
</rdf:RDF>

Example 13 shows that RDF/XML provides li as a convenience element to avoid having to explicitly number each membership property. The numbered properties rdf:_1, rdf:_2, and so on are generated from the li elements in forming the corresponding graph. The element name li was chosen to be mnemonic with the term "list item" from HTML. Note also the use of a <rdf:Bag> element within the <s:students> property element. The <rdf:Bag> element is another example of the abbreviation we used in Example 12 that lets us replace both an rdf:Description element and an rdf:type element with a single element. Since no URIref is specified, the Bag is a blank node. Its nesting within the <s:students> property element is an abbreviated way of indicating that the blank node is the value of this property. These abbreviations are described further in [RDF-SYNTAX].

The graph structure for an rdf:Seq container, and the corresponding RDF/XML, are similar to those for an rdf:Bag (the only difference is in the type, rdf:Seq). Once again, although an rdf:Seq container is intended to describe a sequence, it is up to applications creating and processing the graph to appropriately interpret the sequence of integer-valued property names.

As an illustration of an Alt container, the sentence "The source code for X11 may be found at ftp.example.org, ftp.example1.org, or ftp.example2.org" could be expressed in the RDF graph shown in Figure 15:

Figure 15: A Simple Alt Container Description

Example 14 shows how the graph in Figure 15 could be written in RDF/XML:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://example.org/packages/vocab#">

   <rdf:Description rdf:about="http://example.org/packages/X11">
      <s:DistributionSite>
         <rdf:Alt>
            <rdf:li rdf:resource="ftp://ftp.example.org"/>
            <rdf:li rdf:resource="ftp://ftp.example1.org"/>
            <rdf:li rdf:resource="ftp://ftp.example2.org"/>
         </rdf:Alt>
      </s:DistributionSite>
   </rdf:Description>
</rdf:RDF>

An Alt container is intended to have at least one member, identified by the property rdf:_1. This member is intended to be considered as the default or preferred value. Other than the member identified as rdf:_1, the order of the remaining elements is not significant.

The RDF in Figure 15 as written states simply that the value of the s:DistributionSite site property is the Alt container resource itself. Any additional meaning that is to be read into this graph, e.g., that one of the members of the Alt container is to be considered as the value of the s:DistributionSite site property, or that ftp://ftp.example.org is the default or preferred value, must be built into an application's understanding of how an Alt is intended to behave, and/or into the meaning defined for the particular property (s:DistributionSite in this case), which also must be understood by the application.

Alt containers are frequently used in conjunction with language tagging. For example, a work whose title has been translated into several languages might have its Title property pointing to an Alt container holding each of the language variants.

The distinction between the intended meanings of a Bag and an Alt can be further illustrated by considering the authorship of the book "Huckleberry Finn". The book has exactly one author, but the author has two names (Mark Twain and Samuel Clemens). Either name is sufficient to specify the author. Thus using an Alt container of the author's names more accurately represents the relationship than using a Bag (which might suggest there are two different authors).

Users are free to choose their ways to describe groups of resources, rather than using the ones described here. These RDF containers are merely provided as common definitions that, if generally used, could help make data involving groups of resources more interoperable.

Sometimes there are clear alternatives to using these RDF container types. For example, a relationship between a particular resource and a group of other resources could be indicated by making the first resource the subject of multiple statements using the same property. This is structurally not the same as the resource being the subject of a single statement whose object is a container containing multiple members. In some cases, these two structures may have equivalent meaning, but in other cases they may not. The choice of which to use in a given situation should be made with this in mind.

Consider as an example the relationship between a writer and her publications. We might have the sentence:

Sue has written "Anthology of Time", "Zoological Reasoning", and "Gravitational Reflections".

In this case, there are three resources each of which was written independently by the same writer. This could be expressed using repeated properties as:

exstaff:Sue exterms:publication ex:AnthologyOfTime .
exstaff:Sue exterms:publication ex:ZoologicalReasoning .
exstaff:Sue exterms:publication ex:GravitationalReflections .

In this example there is no stated relationship between the publications other than that they were written by the same person. Each of the statements is an independent fact, and so using repeated properties would be a reasonable choice. However, this could just as reasonably be represented as a statement about the group of resources written by Sue:

exstaff:Sue exterms:publication _:z
_:z rdf:type rdf:Bag .
_:z rdf:_1 ex:AnthologyOfTime .
_:z rdf:_2 ex:ZoologicalReasoning .
_:z rdf:_3 ex:GravitationalReflections .

On the other hand, the sentence:

The resolution was approved by the Rules Committee, having members Fred, Wilma, and Dino.

says that the committee as a whole approved the resolution; it does not necessarily state that each committee member individually voted in favor of the resolution. In this case, it would be potentially misleading to model this sentence as three separate exterms:approvedBy statements, one for each committee member, as shown below:

ex:resolution exterms:approvedBy ex:Fred .
ex:resolution exterms:approvedBy ex:Wilma .
ex:resolution exterms:approvedBy ex:Dino .

since these statements say that each member individually approved the resolution.

In this case, it would be better to model the sentence as a single exterms:approvedBy statement whose subject is the resolution and whose object is the committee itself. The committee resource could then be described as a Bag whose members are the members of the committee, as in the following triples:

ex:resolution exterms:approvedBy ex:rulesCommittee
ex:rulesCommittee rdf:type rdf:Bag .
ex:rulesCommittee rdf:_1 ex:Fred .
ex:rulesCommittee rdf:_2 ex:Wilma .
ex:rulesCommittee rdf:_3 ex:Dino .

Finally, when using these RDF containers, it is important to understand that you are not constructing containers, as you would a programming language data structure; instead, you are describing containers (groups of things) that actually exist. For instance, in the Rules Committee example just given, the Rules Committee is an unordered group of people, whether you describe it in RDF that way or not. When you give the Rules Committee resource an rdf:type property whose value is rdf:Bag, you are simply describing the Rules Committee as having whatever characteristics you associate with things of type rdf:Bag, not constructing a particular data structure to hold the members of the group (you could indicate that the Rules Committe was a Bag without describing any members at all). Similarly, when you use the container membership properties, you are simply describing a container resource as having certain things as members. You are not necessarily saying that the things that you describe as members are the only members that exist. For example, the triples given above to describe the Rules Committee say only that Fred, Wilma, and Dino are members of the Bag, not that they are the only members of the Bag.

4.2. RDF Collections

A limitation of the containers described in Section 4.1 is that there is no way to close them, i.e., to say "these are all the members of the container". This is because, while one graph may describe some of the members, there is no way to exclude the possibility that there is another graph somewhere that describes additional members. RDF provides support for describing groups containing only the specified members, in the form of RDF collections. An RDF collection is a group of things represented as a list structure in the RDF graph. This list structure is constructed using a predefined collection vocabulary consisting of the predefined type rdf:List, the predefined properties rdf:first and rdf:rest, and the predefined resource rdf:nil.

To illustrate this, you could represent the sentence "The students in course 6.001 are Amy, Tim, and John" using the graph shown in Figure 16:

Figure 16: An RDF Collection (list structure)

For each member of the collection, such as s:Amy, there is a corresponding resource of type rdf:List. This list resource is linked to the collection member by an rdf:first property, and to the rest of the list by an rdf:rest property. The end of the list is indicated by an rdf:rest property being the resource rdf:nil. This structure will be familiar to those who know the Lisp programming language. As in Lisp, the rdf:first and rdf:rest properties allow applications to traverse the structure.

RDF/XML provides a special notation to make it easier to describe collections. In RDF/XML, a collection is described by a property element that has the attribute rdf:parseType="Collection", and that contains a group of nested elements representing the members of the collection. The rdf:parseType="Collection" attribute indicates that the enclosed elements are to be used to create the corresponding list structure in the RDF graph.

To illustrate how this works, the RDF/XML from Example 15 would result in the RDF graph shown in Figure 16:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://example.edu/students/vocab#">

   <rdf:Description rdf:about="http://example.edu/courses/6.001">
      <s:students rdf:parseType="Collection">
            <rdf:Description rdf:about="http://example.edu/students/Amy"/>
            <rdf:Description rdf:about="http://example.edu/students/Tim"/>
            <rdf:Description rdf:about="http://example.edu/students/John"/>
      </s:students>
   </rdf:Description>
</rdf:RDF>

The use of rdf:parseType="Collection" always indicates the construction of a list structure like the one shown in Figure 16, which defines a fixed finite list of items with a given length and terminated by rdf:nil, and uses "new" blank nodes which are unique to the list structure itself. However, RDF does not enforce this particular way of using the RDF collection vocabulary, and so it is possible to use this vocabulary in other ways, some of which may not describe lists. For example, it is not illegal to assert that a given node has two distinct values of the rdf:first property, or to simply omit part of the description of a collection. In general, therefore, RDF applications which require collections to be well-structured should be written to check that the collection vocabulary is being used appropriately, in order to be fully robust.

4.3. RDF Reification

RDF applications sometimes need to make statements about statements, for instance, to record information about when a statement was made, who made it, or other similar information. For example, consider a statement about the tent we discussed in Section 3.2:

product item10245 has a weight whose value is 2.4

with a triple representation of:

exproducts:item10245  exterms:weight  "2.4" .

Now, suppose we wanted to say in RDF that this statement was made by John Smith. Since in RDF we can only make statements about resources, what we would like to be able to do is write something like:

 [[exproducts:item10245  exterms:weight  "2.4" .]] dc:creator  exstaff:85740 .

That is, we want to be able to turn the original statement into a resource, so that we can make it the subject of another RDF statement that talks about it. RDF provides a built-in vocabulary for modeling statements as resources. This modeling is called reification in RDF, and a model of a statement is called the reification of the statement.

The RDF reification vocabulary consists of the type rdf:Statement, and the properties rdf:subject, rdf:predicate, and rdf:object. In this vocabulary, a triple of the form:

foo  rdf:type  rdf:Statement .

is a statement that the resource foo is an RDF triple in some RDF document. The three properties rdf:subject, rdf:predicate, and rdf:object, when applied to foo, then specify the subject, predicate, and object components of that triple foo.

Using this vocabulary, a reification of our original triple:

exproducts:item10245  exterms:weight  "2.4" .

is given by the graph:

_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject exproducts:item10245 .
_:xxx rdf:predicate exterms:weight . 
_:xxx rdf:object "2.4" .

(The node that is intended to refer to the first triple, the blank node _:xxx in the reification, could be either a blank node or a URIref.)

The intended interpretation of a reification like this is that _:xxx should be understood as referring to the original triple (as a whole), which is described by the subject, predicate, and object triples in the reification. So, using the reification, we would express the fact that the original statement was made by John Smith using the graph:

_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject exproducts:item10245 . 
_:xxx rdf:predicate exterms:weight . 
_:xxx rdf:object "2.4" .
_:xxx dc:creator exstaff:85740 . 

Note that the intended interpretation is that the triple that _:xxx refers to is a particular instance of a triple in a particular RDF document, rather than some arbitrary triple having the same subject, predicate, and object. There could be several such triples that have the same subject, predicate and object properties. Although a graph is defined as a set of triples, several instances with the same triple structure might occur in different documents. Thus, without this understanding, it would be meaningful to claim that _:xxx does not refer to the triple in the first graph, but to some other triple with the same structure. This particular interpretation of reification is used because reification is intended to be used to express properties such as dates of composition and source information, as in our example, and these properties need to be applied to specific instances of triples.

Note also that the assertion of the reified statement is not the same as the assertion of the original statement, and neither implies the other. That is, when someone asserts that John said foo, they are not asserting foo themselves, just that John said it. Conversely, when someone asserts foo, they are not also asserting its reification, since by asserting foo they are not also saying that there are such things as statements that they intend to talk about.

We have referred to the intended interpretation of reification in the discussion above because, while this may be the interpretation that is generally intended when reification is used, RDF reification does not actually capture all this meaning. Specifically, RDF syntax by itself provides no way to "connect" an RDF triple to its reification. All that the graph:

_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject exproducts:item10245 . 
_:xxx rdf:predicate exterms:weight . 
_:xxx rdf:object "2.4" .
_:xxx dc:creator exstaff:85740 . 

actually says is, "there is a statement that has a subject exproducts:item10245, a predicate exterms:weight, and an object 2.4, and John made it". It does not say that that statement (referred to by _:xxx) is the same as some particular statement in some particular RDF document.

To see this, given the original triple:

exproducts:item10245  exterms:weight  "2.4" .

and the following reification of it, together with an additional triple that associates John with the reification:

_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject exproducts:item10245 .
_:xxx rdf:predicate exterms:weight . 
_:xxx rdf:object "2.4" .

_:xxx dc:creator exstaff:85740 .

note that there is nothing that explicitly associates _:xxx with the original triple, and hence would allow you to say that John created it.

This does not mean that such "provenance" information cannot be expressed in RDF, just that it cannot be done using only the meaning RDF associates with the reification vocabulary. For example, if an RDF document (say, a Web page) has a URI, you could make statements about the resource identified by that URI and, based on some application-dependent understanding of how those statements should be interpreted, act as if those statements "distribute" over (apply equally to) all the statements in the document. Also, if some mechanism exists (outside of RDF) to assign URIs to individual RDF statements, then you could certainly make statements about those individual statements, using their URIs to identify them. In these cases, you would not need to use the reification vocabulary at all.

To see this, if our original triple had a URI, say ex:statementfoo, then you could attribute that statement to John simply by the statement:

ex:statementfoo dc:creator exstaff:85740 .

with no use of the reification vocabulary.

In addition, you could use the reification vocabulary directly according to the intended interpretation described above, and have an application-dependent understanding as to how to associate specific triples with their reifications. However, other applications receiving this RDF would not necessarily share this application-dependent understanding, and thus would not necessarily interpret the graphs appropriately.

Finally, since the relation between triples and reifications of triples in any RDF graph or graphs need not be one-to-one, asserting a property about some resource described by a reification does not necessarily mean that the same property holds of another such resource, even if it has the same components. For example, given the following graph:

_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject exproducts:item10245 . 
_:xxx rdf:predicate exterms:weight . 
_:xxx rdf:object "2.4" .

_:yyy rdf:type rdf:Statement .
_:yyy rdf:subject exproducts:item10245 . 
_:yyy rdf:predicate exterms:weight . 
_:yyy rdf:object "2.4" .

_:xxx dc:creator exstaff:85740 .

it does not follow that:

_:yyy dc:creator exstaff:85740 .

4.4. More on Structured Values: rdf:value

In Section 2.3, we noted that the RDF data model intrinsically supports only binary relations; that is, a statement specifies a relation between two resources. For example, the statement:

exstaff:85740  exterms:manager  exstaff:62345 .

states that the relation "manager" holds between two employees (presumably one manages the other).

However, in some cases we need to be able to represent information involving higher arity relations (relations between more than two resources) in RDF. We discussed one example of this in Section 2.3, where the problem was to represent the relationship between John Smith and his address information, and the value of John's address was a structured value of his street, city, state, and Zip. If we had tried to write this as a relation, we'd have seen that address was 5-ary relation of the form:

address(exstaff:85740, "1501 Grant Avenue", "Bedford", "Massachusetts", "01730")

We indicated that we can represent such structured information in RDF by considering the aggregate thing we want to talk about (here, the group of components representing John's address) as a separate resource, and then making separate statements about that new resource, as in the triples:

exstaff:85740  exterms:address  _:johnaddress .
_:johnaddress  exterms:street   "1501 Grant Avenue" .
_:johnaddress  exterms:city     "Bedford" .
_:johnaddress  exterms:state    "Massachusetts" .
_:johnaddress  exterms:Zip      "01730" .

(where _:johnaddress is the blank node identifier of the blank node representing John's address.)

This is a general way to represent any n-ary relation in RDF: you select one of the participants (John in this case) to serve as the subject of the original relation (address in this case). You then specify an intermediate resource to represent the rest of the relation (either with or without assigning it a URI), and then give that new resource properties representing the remaining components of the relation.

In the case of John's address, none of the individual parts of the structured value could be considered the "main" value of the exterms:address property; all of the parts contribute equally to the value. However, in some cases one of the parts of the structured value is often thought of as the "main" value, with the other parts of the relation providing additional contextual or other information that qualifies the main value. For example, in our tent example in Section 3.2, we gave the weight of the particular tent we were describing as the plain literal "2.4", i.e.,

exproduct:item10245  exterms:weight  "2.4" .

In fact, a more complete description of the weight would have been "2.4 kilograms" rather than just "2.4". To state this, the value of the exterms:weight property would need to have two components, the literal "2.4" and an indication of the unit of measure (kilograms). In this situation the literal "2.4" could be considered the "main" value of the exterms:weight property, because frequently the value would be recorded simply as the value "2.4" (as we did in the triple above), relying on an understanding of the context to fill in the unstated units information.

In the RDF model a qualified property value of this kind is considered as simply another kind of structured value. To represent this, we use a separate resource to represent the structured value as a whole (the weight, in this case), and to serve as the object of the original statement. We then give that resource properties representing the individual parts of the structured value. In this case, we need a property for the literal "2.4", and a property for the unit "kilograms". RDF provides a pre-defined rdf:value property to describe the main value (if there is one) of a structured value. So in this case, we would give the literal "2.4" as the value of the rdf:value property, and give the resource exunits:kilograms as the value of an exterms:units property (assuming the resource exunits:kilograms is defined in a example.org schema with the URIref http://www.example.org/units/kilograms). The resulting triples would be:

exproduct:item10245  exterms:weight  _:weight10245 .
_:weight10245    rdf:value  "2.4" .
_:weight10245    exterms:units   exunits:kilograms .

which can be exchanged using the RDF/XML shown in Example 16:

 <?xml version="1.0"?>
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:exterms="http://www.example.org/terms/">

   <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">
      <exterms:weight rdf:parseType="Resource">
        <rdf:value>2.4</rdf:value>
        <exterms:units rdf:resource="http://www.example.org/units/kilograms" />
      </exterms:weight>
   </rdf:Description>
 </rdf:RDF>

(Example 16 uses some additional RDF/XML abbrevations that were not discussed in Section 3, but are described in [RDF-SYNTAX].)

The same approach can be used to represent quantities using any units of measure, as well as values taken from different classification schemes or rating systems, by using the rdf:value property to give the main value, and using additional properties to identify the classification scheme or other information that further describes the value.

You need not use rdf:value for these purposes (e.g., you could assign your own property name, such as ex:amount, in the example above), and RDF does not associate any particular meaning with it. rdf:value is simply provided as a convenience for use in these commonly-occurring situations.

5.1. Describing Classes

A basic step in any kind of description process is identifying the various kinds of things to be described. RDF Schema refers to these "kinds of things" as classes. A class in RDF Schema corresponds to the generic concept of a Type or Category, somewhat like the notion of a class in object-oriented programming languages such as Java. RDF classes can be used to represent almost any category of thing, such as web pages, people, document types, databases or abstract concepts. Classes are described using the RDFS-defined resources rdfs:Class and rdfs:Resource, and the properties rdf:type and rdfs:subClassOf.

For example, suppose we wanted to use RDF to provide information about different kinds of motor vehicles. In RDF Schema, we would first need a class to represent the category of things that are motor vehicles. The resources that belong to a class are called its instances. In this case, we intend for the instances of our class to be resources that are motor vehicles.

In RDF Schema, a class is any resource having an rdf:type property whose value is the RDFS-defined resource rdfs:Class. So our motor vehicle class would be described by assigning the class a URIref, say ex:MotorVehicle (using ex: to stand for the namespace URIref http://www.example.org/schemas/vehicles, we will use in this example) and describing that resource with an rdf:type property whose value is the RDFS-defined resource rdfs:Class. That is, we would write the RDF statement:

ex:MotorVehicle rdf:type rdfs:Class .

As we indicated in Section 3.2, the property rdf:type is used to indicate that a resource is an instance of a class. So, having described ex:MotorVehicle as a class, if we wanted to describe a resource ex:companyCar as being a motor vehicle, we would write the RDF statement:

ex:companyCar rdf:type ex:MotorVehicle .

(We are using a frequently-used convention that class names are written with an initial uppercase letter, while property and instance names are written with an initial lowercase letter. However, this convention is not required in RDFS)

The resource rdfs:Class itself has an rdf:type of rdfs:Class. A resource may be an instance of more than one class.

After describing class ex:MotorVehicle, we might want to describe additional classes representing various specialized kinds of motor vehicle, e.g., passenger vehicles, vans, minivans, and so on. We can describe these classes in the same way as we described class ex:MotorVehicle, by assigning a URIref for each new class, and writing RDF statements describing these resources as classes, e.g., writing:

ex:Van rdf:type rdfs:Class .
ex:Truck rdf:type rdfs:Class .

and so on. However, we want to do more than just describe the individual classes; we also want to indicate their special relationship to class ex:MotorVehicle, i.e., that they are specialized kinds of MotorVehicle. To do this, we use the RDFS concept of subclass.

An RDF subclass represents a subset/superset relationship between two classes. We describe this relationship using the pre-defined rdfs:subClassOf property to relate the two classes. For example, to state that ex:Van is a subclass of ex:MotorVehicle, we would write the RDF statement:

ex:Van rdfs:subClassOf ex:MotorVehicle .

The meaning of the rdfs:subClassOf relationship is that if resource ex:companyVan is an instance of ex:Van, then ex:companyVan is also implicitly considered an instance of ex:Motorvehicle (that is, you can "infer" or act as if ex:companyVan is an instance of ex:MotorVehicle even if this is not explicitly stated).

The rdfs:subClassOf property is transitive. This means, for example, that if we have the RDF statements:

ex:Van rdfs:subClassOf ex:MotorVehicle .
ex:MiniVan rdfs:subClassOf ex:Van .

then ex:MiniVan is also implicitly a subclass of ex:Motorvehicle. As a result, resources that are instances of class ex:MiniVan are also considered instances of class ex:Motorvehicle (as well as of class ex:Van). A class may be a subclass of more than one class (for example, ex:MiniVan may be a subclass of both ex:Van and ex:PassengerVehicle). All classes are implicitly subclasses of class rdfs:Resource (since the instances belonging to all classes are resources).

Figure 17 shows the full class hierarchy we have been discussing.

Figure 17: A Simple Class Hierarchy

This schema could also be described by the triples:

ex:MotorVehicle rdf:type rdfs:Class .
ex:PassengerVehicle rdf:type rdfs:Class .
ex:Van rdf:type rdfs:Class .
ex:Truck rdf:type rdfs:Class .
ex:MiniVan rdf:type rdfs:Class .

ex:PassengerVehicle rdfs:subClassOf ex:MotorVehicle .
ex:Van rdfs:subClassOf ex:MotorVehicle .
ex:Truck rdfs:subClassOf ex:MotorVehicle .

ex:MiniVan rdfs:subClassOf ex:Van .
ex:MiniVan rdfs:subClassOf ex:PassengerVehicle .

Example 17 shows how this schema could be written in RDF/XML.

<?xml version="1.0"?>
<rdf:RDF   
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">

<rdf:Description rdf:ID="MotorVehicle">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
</rdf:Description>

<rdf:Description rdf:ID="PassengerVehicle">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="Truck">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="Van">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="MiniVan">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#Van"/>
  <rdfs:subClassOf rdf:resource="#PassengerVehicle"/>
</rdf:Description>

</rdf:RDF>

This RDF/XML introduces names, such as MotorVehicle, for the resources (classes) that it describes using rdf:ID, to give the effect of "assigning" URIrefs relative to the schema document as we described in Section 3.2. Relative URIrefs based on these names can then be used in other class definitions within the same schema (e.g., as we used #MotorVehicle in the description of the other classes). The full URIref of this class, assuming that the schema itself was the resource http://example.org/schemas/vehicles, would be http://example.org/schemas/vehicles#MotorVehicle (as shown in Figure 17). As noted in Section 3.2, to ensure that the references to these schema classes would be consistently maintained even if the schema were relocated or copied (or to simply assign a base URIref for the schema classes without assuming they are all published at a single location), the class descriptions could also include an explicit xml:base="http://example.org/schemas/vehicles" declaration.

To refer to these classes in RDF instance data (e.g., data describing individual vehicles of these classes) located elsewhere, we would need to use the full URIrefs to identify the classes. For example, to describe the resource ex2:companyCar as an instance of the class ex:MotorVehicle described in this schema, we could use the RDF/XML shown in Example 18:

<?xml version="1.0"?>
<rdf:RDF   
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
  xmlns:ex="http://example.org/schemas/vehicles">

   <rdf:Description rdf:ID="companyCar">
     <rdf:type rdf:resource="http://example.org/schemas/vehicles#MotorVehicle"/>
   </rdf:Description>

</rdf:RDF>

5.2. Describing Properties

In addition to describing the specific classes of things they want to describe, user communities also need to be able to describe specific properties that characterize those classes of things (such as rearSeatLegRoom to describe a passenger vehicle). In RDF Schema, properties are described using the RDF-defined class rdf:Property, and the RDFS-defined properties rdfs:domain, rdfs:range, and rdfs:subPropertyOf.

All properties in RDF are described as instances of class rdf:Property. So a new property, such as exterms:weightInKg, is described by assigning the property a URIref, and describing that resource with an rdf:type property whose value is the resource rdf:Property. That is, we would write the RDF statement:

exterms:weightInKg  rdf:type  rdf:Property .

RDF Schema also provides vocabulary for describing how properties and classes are intended to be used together in RDF data. The most important information of this kind is supplied by using the RDFS-defined properties rdfs:range and rdfs:domain to further describe application-specific properties.

The rdfs:range property is used to indicate that the values of a particular property are instances of a designated class. For example, if we wanted to indicate that the property ex:author had values that are instances of class ex:Person, we would write the RDF statements:

ex:Person  rdf:type  rdfs:Class .
ex:author  rdf:type  rdf:Property .
ex:author  rdfs:range  ex:Person .

These statements indicate that ex:Person is a class, ex:author is a property, and that RDF statements using the ex:author property have instances of ex:Person as objects.

A property, say ex:hasMother, can have zero, one, or more than one range property. If ex:hasMother has no range property, then we are saying nothing about the values of the ex:hasMother property. If ex:hasMother has one range property, say one specifying ex:Person as the range, this says that the values of the ex:hasMother property are instances of class ex:Person. If ex:hasMother has more than one range property, say one specifying ex:Person as its range, and another specifying ex:Female as its range, this says that the values of the ex:hasMother property are resources that are instances of all of the classes specified as the ranges, i.e., that any value of ex:hasMother is both a ex:Female and a ex:Person.

The rdfs:range property can also be used to indicate that the value of a property is given by a typed literal, as discussed in Section 2.4. For example, if we wanted to indicate that the property ex:age had values from the XML Schema datatype xsd:integer, we would write the RDF statement:

ex:age  rdf:type  rdf:Property .
ex:age  rdfs:range  xsd:integer .

The datatype xsd:integer is identified by its URIref (the full URIref being http://www.w3.org/2001/XMLSchema#integer). This URIref can be used without explicitly stating in the RDF Schema that it identifies a datatype. However, it is often useful to explicitly state that a given URIref identifies a datatype. This can be done using the RDFS-defined class rdfs:Datatype. To state that xsd:integer is a datatype, we would write the RDF statement:

xsd:integer rdf:type rdfs:Datatype .

This statement says that xsd:integer is the URIref of a datatype (which is assumed to conform to the requirements for RDF datatypes described in [RDF-CONCEPTS]). Such a statement does not constitute a definition of a datatype, e.g., in the sense that we are defining a new datatype. There is no way to define datatypes in RDFS. As noted in Section 2.4, datatypes are defined externally to RDFS, and referred to in RDF statements by their URIrefs. What this statement does is document the existence of the datatype, and indicates explicitly that it is being used in this schema.

The rdfs:domain property is used to indicate that a particular property applies to a designated class. For example, if we wanted to indicate that the property ex:author applies to instances of class ex:Book, we would write the RDF statements:

ex:Book  rdf:type  rdfs:Class .
ex:author  rdf:type  rdf:Property .
ex:author  rdfs:domain  ex:Book .

These statements indicate that ex:Person is a class, ex:author is a property, and that RDF statements using the ex:author property have instances of ex:Book as subjects.

A given property, say exterms:weight, may have zero, one, or more than one domain property. If exterms:weight has no domain property, then we are saying nothing about the resources that exterms:weight properties may be used with (any resource could have a exterms:weight property). If exterms:weight has one domain property, say one specifying ex:Book as the domain, this says that the exterms:weight property applies to instances of class ex:Book. If exterms:weight has more than one domain property, say one specifying ex:Book as the domain and another one specifying ex:MotorVehicle as the domain, this says that any resource that has a exterms:weight property is an instance of all of the classes specified as the domains, i.e., that any resource that has a exterms:weight property is both a ex:Book and a ex:MotorVehicle (illustrating the need for care in specifying domains and ranges).

We can illustrate the use of these range and domain descriptions by extending our vehicle schema, adding two properties ex:registeredTo and ex:rearSeatLegRoom, a new class ex:Person, and explicitly describing the datatype xsd:integer as a datatype. The ex:registeredTo property applies to any ex:MotorVehicle and its value is a ex:Person. For the sake of this example, ex:rearSeatLegRoom applies only to instances of class ex:PassengerVehicle. The value is an xsd:integer giving the number of centimeters of rear seat legroom. These descriptions are shown in Example 19:

<rdf:Description rdf:ID="registeredTo">
  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
  <rdfs:domain rdf:resource="#MotorVehicle"/>
  <rdfs:range rdf:resource="#Person"/>
</rdf:Description>

<rdf:Description rdf:ID="rearSeatLegRoom">
  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
  <rdfs:domain rdf:resource="#PassengerVehicle"/> 
  <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/>
</rdf:Description>

<rdf:Description rdf:ID="Person">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#integer">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Datatype"/>
</rdf:Description>

Note that we have not used an <rdf:RDF> element in Example 19 because we have assumed we are adding this RDF/XML to the vehicle schema we described earlier, identified by http://example.org/schemas/vehicles. This same assumption also allows us to use relative URIrefs like #MotorVehicle to refer to other classes from that schema.

RDF Schema provides a way to specialize properties as well as classes. We describe this specialization relationship between two properties using the pre-defined rdfs:subPropertyOf property. For example, if ex:primaryDriver and ex:driver are both properties, we can describe these properties, and the fact that ex:primaryDriver is a specialization of ex:driver, by writing the RDF statements:

ex:driver  rdf:type  rdf:Property .
ex:primaryDriver  rdf:type  rdf:Property .
ex:primaryDriver  rdfs:subPropertyOf  ex:driver .

The meaning of the rdfs:subPropertyOf relationship is that if an instance ex:fred is an ex:primaryDriver of the instance ex:companyVan, then ex:fred is implicitly considered to also be an ex:primaryDriver of ex:companyVan. The RDF/XML describing these properties (assuming again that we are adding this to the vehicle schema we described earlier) is shown in Example 20.

<rdf:Description rdf:ID="driver">
  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
  <rdfs:domain rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="primaryDriver">
  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
  <rdfs:subPropertyOf rdf:resource="#driver"/>
</rdf:Description>

A property may be a subproperty of zero, one or more properties. All RDF rdfs:range and rdfs:domain properties that apply to an RDF property also apply to each of its subproperties. So in the above example ex:primaryDriver, because of its subproperty relationship to ex:driver, implicitly also has an rdfs:domain of ex:MotorVehicle.

Example 21 shows the RDF/XML for the full vehicle schema, containing all the descriptions we've given so far:

<?xml version="1.0"?>
<rdf:RDF   
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xml:base="http://example.org/schemas/vehicles">

<rdf:Description rdf:ID="MotorVehicle">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
</rdf:Description>

<rdf:Description rdf:ID="PassengerVehicle">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="Truck">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="Van">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="MiniVan">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#Van"/>
  <rdfs:subClassOf rdf:resource="#PassengerVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="Person">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#integer">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Datatype"/>
</rdf:Description>

<rdf:Description rdf:ID="registeredTo">
  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
  <rdfs:domain rdf:resource="#MotorVehicle"/>
  <rdfs:range rdf:resource="#Person"/>
</rdf:Description>

<rdf:Description rdf:ID="rearSeatLegRoom">
  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
  <rdfs:domain rdf:resource="#PassengerVehicle"/> 
  <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/>
</rdf:Description>

<rdf:Description rdf:ID="driver">
  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
  <rdfs:domain rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="primaryDriver">
  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
  <rdfs:subPropertyOf rdf:resource="#driver"/>
</rdf:Description>

</rdf:RDF>

Now that we've shown how to describe classes and properties using RDF Schema, we can see what instances corresponding to those descriptions might look like. For example, Example 22 describes an instance of the ex:PassengerVehicle class we described above, together with some hypothetical values for its properties.

  <?xml version="1.0"?>
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
              xmlns:ex="http://example.org/schemas/vehicles">

    <rdf:Description rdf:ID="johnSmithsCar">
         <rdf:type rdf:resource="http://example.org/schemas/vehicles#PassengerVehicle"/>
         <ex:registeredTo rdf:resource="http://www.example.org/staffid/85740"/>
         <ex:rearSeatLegRoom 
             rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">127</ex:rearSeatLegRoom>
         <ex:primaryDriver rdf:resource="http://www.example.org/staffid/85740"/>
    </rdf:Description>
  </rdf:RDF>

We are assuming that this instance is described in a separate document from the schema and, as before, that the schema is the resource http://example.org/schemas/vehicles. So we provide the namespace declaration xmlns:ex="http://example.org/schemas/vehicles" to refer to the schema, which allows the instance data to use abbreviations such as ex:registeredTo to refer unambiguously to properties described in that schema. However, when we use the rdf:type property to indicate the class membership of the instance, we must use the full URIref of the class to refer to it (since we cannot use a QName referencing the ex: namespace as a value of the rdf:resource attribute.

Note that we can use an ex:registeredTo property in describing this instance of ex:PassengerVehicle, because ex:PassengerVehicle is a subclass of ex:MotorVehicle. Note also that we use a typed literal for the value of the ex:rearSetLegRoom property in our instance, rather than a plain literal (i.e., we didn't say <ex:rearSeatLegRoom>127</ex:rearSeatLegRoom>). Because the schema describes the range of this property as an xsd:integer, the value of the property must be a typed literal of that datatype in order to match the range description (i.e., the range declaration does not "assign" a datatype to a plain literal).

As we discussed in Section 3.2, the RDF/XML syntax provides an abbreviation for instances defined as members of classes using the rdf:type property. Using this abbreviation, we could describe this same instance as shown in Example 23:

  <?xml version="1.0"?>
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
              xmlns:ex="http://example.org/schemas/vehicles">

    <ex:PassengerVehicle rdf:ID="johnSmithsCar">
         <ex:registeredTo rdf:resource="http://www.example.org/staffid/85740"/>
         <ex:rearSeatLegRoom 
             rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">127</ex:rearSeatLegRoom>
         <ex:primaryDriver rdf:resource="http://www.example.org/staffid/85740"/>
    </ex:PassengerVehicle>
  </rdf:RDF>

In Example 23 the class is identified by an element name (ex:PasssengerVehicle) rather than as the value of an rdf:resource attribute, so we can abbreviate it with the QName ex:PasssengerVehicle rather than writing it as a full URIref as we did in the earlier form.

5.3. Interpreting RDF Schema Declarations

As noted earlier, the RDF Schema type system is similar in some respects to the type systems of object-oriented programming languages such as Java. However, RDF differs from most programming language type systems in several important respects.

One important difference is that instead of describing a class as having a collection of specific properties, an RDF schema describes properties as applying to specific classes of resource, using domain and range properties. For example, a typical object-oriented programming language might define a class Book with an attribute called author having values of type Person. A corresponding RDF schema would describe a class ex:Book, and, in a separate description, a property ex:author having a domain of ex:Book and a range of ex:Person.

The difference between these approaches may seem to be only syntactic, but in fact there is an important difference. In the programming language class description, the attribute author is part of the description of class Book, and applies only to instances of class Book. Another class (say, softwareModule) might also have an attribute called author, but this would be considered a different attribute. In other words, the scope of an attribute description in most programming languages is restricted to the class or type in which it is defined. In RDF, on the other hand, property descriptions are, by default, independent of class definitions, and have, by default, global scope (although they may optionally be declared to apply only to certain classes using domain specifications).

So, for example, an RDF schema could describe a property exterms:weight without a domain being specified. This property could then be used to describe instances of any class that might be considered to have a weight. One benefit of the RDF property-based approach is that it becomes easier to extend the use of property definitions to situations that might not have been anticipated in the original description. (Of course, this is a "benefit" which must be used with care, to insure that properties are not mis-applied in inappropriate situations.)

Another important difference is that RDF Schema descriptions are not necessarily prescriptive in the way programming language type declarations typically are. For example, if a programming language declares a class Book with an author attribute having values of type Person, this is usually interpreted as a group of constraints. The language will not allow the creation of an instance of Book without an author attribute, and it will not allow an instance of Book with an author attribute that does not have a Person as its value. Moreover, if author is the only attribute defined for class Book, the language will not allow an instance of Book with some other attribute.

RDF Schema, on the other hand, provides schema information as additional descriptions of resources, but does not prescribe how these descriptions should be used by an application. For example, suppose an RDF schema states that an ex:author property has an rdfs:range of class ex:Person. This is simply an RDF statement that RDF statements containing ex:author properties have instances of ex:Person as objects.

This schema-supplied information might be used in different ways. One application might interpret this statement as specifying part of a template for RDF data it is creating, and use it to ensure that any ex:author property has a value of the indicated (ex:Person) class. That is, this application interprets the schema description as a constraint in the same way that a programming language might. However, another application might interpret this statement as providing additional information about data it is receiving, information which may not be provided explicitly in the original data. For example, this second application might receive some RDF data that includes an ex:author property whose value is a resource of unspecified class, and use this schema-provided statement to conclude that the resource must be an instance of class ex:Person. A third application might receive some RDF data that includes an ex:author property whose value is a resource of class ex:Corporation, and use this schema information as the basis of a warning that "there may be an inconsistency here, but on the other hand there may not be". Somewhere else there may be a declaration that resolves the apparent inconsistency (e.g., a declaration to the effect that "a Corporation is a (legal) Person").

Moreover, depending on how the application interprets the property descriptions, a description of an instance might be considered valid either without some of the schema-specified properties (e.g., you might have an instance of ex:Book without an ex:author property, even if ex:author is described as having a domain of ex:Book), or with additional properties (you might describe an instance of ex:Book with an ex:technicalEditor property, even though you haven't described such a property in your particular schema.)

In other words, statements in an RDF Schema are always descriptions. They may also be prescriptive (introduce constraints), but only if the application interpreting those statements wants to treat them that way. All RDF Schema does is provide a way of stating this additional information. Whether this information conflicts with explicitly specified instance data is up to the application to determine and act upon.

5.4. Other Schema Information

RDF Schema also provides a number of other properties, which can be used to provide documentation and other information about an RDF schema or about instances. For example the rdfs:comment property can be used to provide a human-readable description of a resource. The rdfs:label property can be used to provide a more human-readable version of a resource's name. The rdfs:seeAlso property can be used to indicate a resource that might provide additional information about the subject resource. The rdfs:isDefinedBy property is a subproperty of rdfs:seeAlso, and can be used to indicate a resource that (in a sense not specified by RDF; e.g., the resource may not be an RDF schema) "defines" the subject resource. For further discussion of these properties, you should consult RDF Vocabulary Description Language 1.0: RDF Schema [RDF-VOCABULARY].

5.5. Richer Schema Languages

RDF Schema provides basic capabilities for describing RDF vocabularies, but additional capabilities are also possible, and can be useful. These capabilities may be provided through further development of RDF Schema, or in other languages. Other richer schema capabilities that have been identified as useful (but that are not provided by RDF Schema) include:

• cardinality constraints on properties, e.g., that a Person has exactly one biological father.
• specifying that a given property (such as hasAncestor) is transitive, e.g., that if A hasAncestor B, and B hasAncestor C, then A hasAncestor C.
• specifying that a given property is a unique identifier (or key) for instances of a particular class.
• specifying that two different classes (having different URIrefs) actually represent the same concept.
• specifying that two different instances (having different URIrefs) actually represent the same individual.
• the ability to describe new classes in terms of combinations (e.g., unions and intersections) of other classes, or to say that two classes are disjoint (i.e., that no resource is an instance of both classes).

The additional capabilities mentioned above, in addition to others, are the targets of ontology languages such as DAML+OIL [DAML+OIL] and OWL [OWL]. Both these languages are based on RDF and RDF Schema (and both currently provide all the additional capabilities mentioned above). The intent of such languages is to provide additional machine-processable semantics for resources, that is, to make the machine representations of resources more closely resemble their intended real world counterparts. While such capabilities are not necessarily needed to build useful applications using RDF (see Section 6 for a description of a number of existing RDF applications), the development of such languages is a very active subject of work as part of the development of the Semantic Web.

6.1 Dublin Core Metadata Initiative

Metadata is data about data. Specifically, the term refers to data used to identify, describe, or locate information resources, whether these resources are physical or electronic. While structured metadata processed by computers is relatively new, the basic concept of metadata has been used for many years in helping manage and use large collections of information. Library card catalogs are a familiar example of such metadata.

The Dublin Core is a set of "elements" (properties) for describing documents (and hence, for recording metadata). The element set was originally developed at the March 1995 Metadata Workshop in Dublin, Ohio. The Dublin Core has subsequently been modified on the basis of later Dublin Core Metadata workshops, and is currently maintained by the Dublin Core Metadata Initiative. The goal of the Dublin Core is to provide a minimal set of descriptive elements that facilitate the description and the automated indexing of document-like networked objects, in a manner similar to a library card catalog. The Dublin Core metadata set is intended to be suitable for use by resource discovery tools on the Internet, such as the "webcrawlers" employed by popular World Wide Web search engines. In addition, the Dublin Core is meant to be sufficiently simple to be understood and used by the wide range of authors and casual publishers who contribute information to the Internet. Dublin Core elements have become widely used in documenting Internet resources (we have already used the Dublin Core creator element in earlier examples). The current elements of the Dublin Core are defined in the Dublin Core Metadata Element Set, Version 1.1: Reference Description [DC], and contain definitions for the following properties:

• Title: A name given to the resource.
• Creator: An entity primarily responsible for making the content of the resource.
• Subject: The topic of the content of the resource.
• Description: An account of the content of the resource.
• Publisher: An entity responsible for making the resource available
• Contributor: An entity responsible for making contributions to the content of the resource.
• Date: A date associated with an event in the life cycle of the resource.
• Type: The nature or genre of the content of the resource.
• Format: The physical or digital manifestation of the resource.
• Identifier: An unambiguous reference to the resource within a given context.
• Source: A Reference to a resource from which the present resource is derived.
• Language: A language of the intellectual content of the resource.
• Relation: A reference to a related resource.
• Coverage: The extent or scope of the content of the resource.
• Rights: Information about rights held in and over the resource.

Information using the Dublin Core elements may be represented in any suitable language (e.g., in HTML Meta elements). However, RDF is an ideal representation for Dublin Core information. The examples below represent the simple description of a set of resources in RDF using the Dublin Core vocabulary. Note that the specific Dublin Core RDF vocabulary shown here is not intended to be authoritative. The Dublin Core Reference Description [DC] is the authoritative reference.

The first example, Example 24, describes a Web site home page using Dublin Core properties:

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/">
    <rdf:Description rdf:about="http://www.dlib.org">
      <dc:title>D-Lib Program - Research in Digital Libraries</dc:title>
      <dc:description>The D-Lib program supports the community of people
       with research interests in digital libraries and electronic
       publishing.</dc:description>
      <dc:publisher>Corporation For National Research Initiatives</dc:publisher>
      <dc:date>1995-01-07</dc:date>
      <dc:subject>
        <rdf:Bag>
          <rdf:li>Research; statistical methods</rdf:li>
          <rdf:li>Education, research, related topics</rdf:li>
          <rdf:li>Library use Studies</rdf:li>
        </rdf:Bag>
      </dc:subject>
      <dc:type>World Wide Web Home Page</dc:type>
      <dc:format>text/html</dc:format>
      <dc:language>en</dc:language>
    </rdf:Description>
</rdf:RDF>

Note that both RDF and the Dublin Core define an (XML) element called "Description" (although here we've written the Dublin Core element name in lower case). Even if the initial letter were identically uppercase, the XML namespace mechanism enables us to distinguish between these two elements (one is rdf:Description, and the other is dc:description). Also, as a matter of interest, if you access http://purl.org/dc/elements/1.1/ in a Web browser (as of the current writing), you will get an RDF Schema declaration for [DC].

Our second example, Example 25, describes a published magazine:

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dcterms="http://purl.org/dc/terms/">
    <rdf:Description rdf:about="http://www.dlib.org/dlib/may98/05contents.html">
      <dc:title>DLIB Magazine - The Magazine for Digital Library Research
        - May 1998</dc:title>
      <dc:description>D-LIB magazine is a monthly compilation of
       contributed stories, commentary, and briefings.</dc:description>
      <dc:contributor>Amy Friedlander</dc:contributor>
      <dc:publisher>Corporation for National Research Initiatives</dc:publisher>
      <dc:date>1998-01-05</dc:date>
      <dc:type>electronic journal</dc:type>
      <dc:subject>
        <rdf:Bag>
          <rdf:li>library use studies</rdf:li>
          <rdf:li>magazines and newspapers</rdf:li>
        </rdf:Bag>
      </dc:subject>
      <dc:format>text/html</dc:format>
      <dc:identifier>urn:issn:1082-9873</dc:identifier>
      <dcterms:isPartOf rdf:resource="http://www.dlib.org"/>
    </rdf:Description>
 </rdf:RDF>

In Example 25, we've used (in the third line from the bottom) the Dublin Core qualifier isPartOf (from a separate namespace) to indicate that this magazine is "part of" the previously-described web site.

The third example, Example 26, describes a specific article in the magazine described in Example 25.

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dcterms="http://purl.org/dc/terms/">
    <rdf:Description rdf:about="http://www.dlib.org/dlib/may98/miller/05miller.html">
      <dc:title>An Introduction to the Resource Description Framework</dc:title>
      <dc:creator>Eric J. Miller</dc:creator>
      <dc:description>The Resource Description Framework (RDF) is an
       infrastructure that enables the encoding, exchange and reuse of
       structured metadata. rdf is an application of xml that imposes needed
       structural constraints to provide unambiguous methods of expressing
       semantics. rdf additionally provides a means for publishing both
       human-readable and machine-processable vocabularies designed to
       encourage the reuse and extension of metadata semantics among
       disparate information communities. the structural constraints rdf
       imposes to support the consistent encoding and exchange of
       standardized metadata provides for the interchangeability of separate
       packages of metadata defined by different resource description
       communities. </dc:description>
      <dc:publisher>Corporation for National Research Initiatives</dc:publisher>
      <dc:subject>
        <rdf:Bag>
          <rdf:li>machine-readable catalog record formats</rdf:li>
          <rdf:li>applications of computer file organization and
           access methods</rdf:li>
        </rdf:Bag>
      </dc:subject>
      <dc:rights>Copyright @ 1998 Eric Miller</dc:rights>
      <dc:type>Electronic Document</dc:type>
      <dc:format>text/html</dc:format>
      <dc:language>en</dc:language>
      <dcterms:isPartOf rdf:resource="http://www.dlib.org/dlib/may98/05contents.html"/>
    </rdf:Description>
</rdf:RDF>

In Example 26, we've also used the qualifier isPartOf, this time to indicate that this article is "part of" the previously-described magazine.

6.2 PRISM

PRISM: Publishing Requirements for Industry Standard Metadata [PRISM] is a metadata specification developed in the publishing industry. Magazine publishers and their vendors formed the PRISM Working Group to identify the industry's needs for metadata and define a specification to meet them. Publishers want to use existing content in many ways in order to get a greater return on the investment made in creating it. Converting magazine articles to HTML for posting on the web is one example. Licensing it to aggregators like LexisNexis is another. All of these are "first uses" of the content; typically they all go live at the time the magazine hits the stands. The publishers also want their content to be "evergreen". It might be used in new issues, such as in a retrospective article. It could be used by other divisions in the company, such as in a book compiled from the magazine's photos, recipes, etc. Another use is to license it to outsiders, such as in a reprint of a product review, or in a retrospective produced by a different publisher. This overall goal requires a metadata approach which emphasizes discovery, rights tracking, and end-to-end metadata.

Discovery: Discovery is a general term for finding content which encompasses searching, browsing, content routing, and other techniques. Discussions of discovery frequently center on a consumer searching a public web site. However, discovering content is much broader than that. The audience may consist of consumers, or it may consist of internal users such as researchers, designers, photo editors, licensing agents, etc. To assist discovery, PRISM provides properties to describe the topics, formats, genre, origin, and contexts of a resource. It also provides means for categorizing resources using multiple subject description taxonomies.

Rights Tracking: Magazines frequently contain material licensed from others. Photos from a stock photo agency are the most common type of licensed material, but articles, sidebars, and all other types of content may be licensed. Simply knowing if content was licensed for one-time use, requires royalty payments, or is wholly-owned by the publisher is a struggle. PRISM provides elements for basic tracking of such rights. A separate namespace (vocabulary) defined in the PRISM specification supports description of places, times, and industries where content may or may not be used.

End-to-end metadata: Most published content already has metadata created for it. Unfortunately, when content moves between systems, the metadata is frequently discarded, only to be re-created later in the production process at considerable expense. PRISM aims to reduce this problem by providing a specification that can be used in multiple stages in the content production pipeline. An important feature of the PRISM specification is its use of other existing specifications. Rather than create an entirely new thing, the group decided to use existing specifications as much as possible, and only define new things where needed. For this reason, the PRISM specification uses XML, RDF, Dublin Core, and well as various ISO formats and vocabularies.

A PRISM description may be as simple as a few Dublin Core properties with plain literal values. Example 27 describes a photograph, giving basic information on its title, photographer, format, etc.

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xml:lang="en-US">

 <rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg">
  <dc:title>Walking on the Beach in Corfu</dc:title>
  <dc:description>Photograph taken at 6:00 am on Corfu with two models
  </dc:description>
  <dc:creator>John Peterson</dc:creator>
  <dc:contributor>Sally Smith, lighting</dc:contributor>
  <dc:format>image/jpeg</dc:format>
 </rdf:Description>
</rdf:RDF>

PRISM also augments the Dublin Core to allow more detailed descriptions. The augmentations are defined in three new namespaces, generally cited using the prefixes prism:, pcv:, and prl:.

prism: This prefix refers to the main PRISM namespace, whose URI is http://prismstandard.org/namespaces/basic/1.0/. Most of its properties are more specific versions of properties from the Dublin Core. For example, dc:date is extended by properties like prism:publicationTime, prism:releaseTime, prism:expirationTime, etc.

pcv: This prefix refers to the PRISM Controlled Vocabulary namespace, whose URI is http://prismstandard.org/namespaces/pcv/1.0/. Currently, common practice for describing the subject(s) of an article is by supplying appropriate-seeming keywords. Unfortunately, simple keywords do not make a great difference in retrieval performance, due to the fact that different people will use different keywords [BATES96]. Best practice is to code the articles with subject terms from a "controlled vocabulary". The vocabulary should provide as many synonyms as possible for its terms in the vocabulary. This way the controlled terms provide a meeting ground for the keywords supplied by the searcher and the indexer. The PRISM Controlled Vocabulary (pcv) namespace provides properties for specifying terms in a vocabulary, the relations between terms, and alternate names for the terms.

prl: This prefix refers to the PRISM Rights Language namespace, whose URI is http://prismstandard.org/namespaces/prl/1.0/. Digital Rights Management is an area undergoing considerable upheaval. There are a number of proposals for rights management languages, but none are clearly favored throughout the industry. Because there was no clear choice to recommend, the PRISM Rights Language (PRL) was defined as an interim measure. It provides properties which let people say if an item can or can't be "used", depending on conditions of time, geography, and industry. This is believed to be an 80/20 tradeoff which will help publishers begin to save money when tracking rights. It is not intended to be a general rights language, or allow publishers to automatically enforce limits on consumer uses of the content.

PRISM uses RDF because of its abilities for dealing with descriptions of varying complexity. Currently, a great deal of metadata uses simple character string (plain literal) values, such as:

<dc:coverage>Greece</dc:coverage>

Over time the developers of PRISM expect uses of the PRISM specification to become more sophisticated, moving from simple literal values to more structured values. In fact, that range of values is a situation being faced now. Some publishers already use sophisticated controlled vocabularies, others are barely using manually-supplied keywords. To illustrate this, some examples of the different kinds of values that can be given for the coverage property are:

<dc:coverage>Greece</dc:coverage>

<dc:coverage rdf:resource="http://prismstandard.org/vocabs/ISO-3166/GR"/>

(i.e., using either a plain literal or a URIref) and

<dc:coverage>
  <pcv:Descriptor rdf:about="http://prismstandard.org/vocabs/ISO-3166/GR">
    <pcv:label xml:lang="en">Greece</pcv:label>
    <pcv:label xml:lang="fr">Grece</pcv:label>
  </pcv:Descriptor>
</dc:coverage>

(using a structured value).

Note also that there are properties whose meanings are similar, or subsets of other properties. For example, the geographic subject of a resource could be given with

<prism:subject>Greece</prism:subject>
<dc:coverage>Greece</dc:coverage>

or

<prism:location>Greece</prism:location>

Any of those properties might use the simple literal value, or a more complex structured value. Such a range of possibilities cannot be adequately described by DTDs, or even by the newer XML Schemas. While there is a wide range of syntactic variations to deal with, RDF's graph model has a simple structure - a set of triples. Dealing with the metadata in the triples domain makes it much easier for older software to accommodate content with new extensions.

We will close this section with two final examples. Example 28 says that the image (.../Corfu.jpg) cannot be used (#none) in the tobacco industry (code 21 in SIC, the Standard Industrial Classifications).

<rdf:RDF xmlns:prism="http://prismstandard.org/namespaces/basic/1.0/"
         xmlns:prl="http://prismstandard.org/namespaces/prl/1.0/"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/">

 <rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg">
  <dc:rights rdf:parseType="Resource"
         xml:base="http://prismstandard.org/vocabularies/1.0/usage.xml">
     <prl:usage rdf:resource="#none"/>
     <prl:industry rdf:resource="http://prismstandard.org/vocabs/SIC/21"/>
  </dc:rights>
 </rdf:Description>
</rdf:RDF>

Example 29 says that the photographer for the Corfu image was employee 3845, better known as John Peterson. It also says that the geographic coverage of the photo is Greece. It does so by providing, not just a code from a controlled vocabulary, but a cached version of the information for that term in the vocabulary.

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:pcv="http://prismstandard.org/namespaces/pcv/1.0/"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xml:base="http://wanderlust.com/">

  <rdf:Description rdf:about="/2000/08/Corfu.jpg">
    <dc:identifier rdf:resource="/content/2357845" />
    <dc:creator>
      <pcv:Descriptor rdf:about="/emp3845">
        <pcv:label>John Peterson</pcv:label>
      </pcv:Descriptor>
    </dc:creator>
    <dc:coverage>
      <pcv:Descriptor
          rdf:about="http://prismstandard.org/vocabs/ISO-3166/GR">
        <pcv:label xml:lang="en">Greece</pcv:label>
        <pcv:label xml:lang="fr">Grece</pcv:label>
      </pcv:Descriptor>
    </dc:coverage>
  </rdf:Description>
</rdf:RDF>

6.3 XPackage

Many situations involve the need to maintain information about structured groupings of resources and their associations that are, or may be, used as a unit. The XML Package (XPackage) specification [XPACKAGE] provides a framework for defining such groupings, called packages. XPackage specifies a framework for describing the resources included in such packages, the properties of those resources, their method of inclusion, and their relationships with each other. XPackage applications include specifying the stylesheets used by a document, declaring the images shared by multiple documents, indicating the author and other metadata of a document, describing how namespaces are used by XML resources, and providing a manifest for bundling resources into a single archive file.

The XPackage framework is based upon XML, RDF, and the XML Linking Language [XLINK], and provides two RDF vocabularies: one for general packaging descriptions, and another specifically for describing XML resources. The XPackage framework also allows customization through extension and/or restriction.

One application of XPackage is the description of XHTML documents and their supporting resources. An XHTML document retrieved from a web site may rely on other resources such as stylesheets and image files that also need to be retrieved. However, the identities of these supporting resources may not be obvious without processing the entire document. Other information about the document, such as the name of its author, may also not be available without processing the document. XPackage allows such descriptive information to be stored in a standard way in a package description document containing RDF. The outer elements of a package description document describing such an XHTML document might look like Example 30 (with namespace declarations removed for simplicity):

<?xml version="1.0"?>
<xpackage:description>
  <rdf:RDF>

    (description of individual resources go here)

  </rdf:RDF>
</xpackage:description>

Resources (such as the XHTML document, stylesheets, and images) are described within this package description document. The XHTML document resource itself is described using an RDF resource description element <xpackage:resource> from the XPackage ontology (the term XPackage uses for a vocabulary). Each resource description element may include RDF properties from various ontologies. In Example 31, the document's MIME content type ("application/xhtml+xml") is defined using a standard XPackage property from the XPackage ontology, xpackage:contentType. Another property, the document's author (in this case, "Garret Wilson"), is described using a property from the Dublin Core (which is considered a custom ontology in XPackage), resulting in a dc:creator property. XPackage itself specifies an extension property set specifically for XML-based resources, the XML ontology, including specifying XML namespaces and stylesheets used with the xmlprop:namespace and xmlprop:style properties, respectively.

    <!--doc.html-->
    <xpackage:resource rdf:about="urn:examples:xhtmldocument-doc">
      <rdfs:comment>The XHTML document.</rdfs:comment>
      <xpackage:location xlink:href="doc.html"/>
      <xpackage:contentType>application/xhtml+xml</xpackage:contentType>
      <xmlprop:namespace rdf:resource="http://www.w3.org/1999/xhtml"/>
      <xmlprop:style rdf:resource="urn:examples:xhtmldocument-stylesheet"/>
      <xmlprop:annotation rdf:resource="urn:examples:xhtmldocument-annotation"/>
      <dc:creator>Garret Wilson</dc:creator>
      <xpackage:manifest>
        <rdf:Bag>
          <rdf:li rdf:resource="urn:examples:xhtmldocument-stylesheet"/>
          <rdf:li rdf:resource="urn:examples:xhtmldocument-image"/>
        </rdf:Bag>
      </xpackage:manifest>
    </xpackage:resource>

The xpackage:manifest property indicates that both the stylesheet and image resources are necessary for processing; those resources are described separately within the package description document. The example stylesheet resource description in Example 32 lists its location ("stylesheet.css") using the XPackage ontology xpackage:location property (which is compatible with XLink), and shows through use of the XPackage ontology xpackage:contentType property that it is a CSS stylesheet ("text/css").

    <!--stylesheet.css-->
    <xpackage:resource rdf:about="urn:examples:xhtmldocument-css">
      <rdfs:comment>The document stylesheet.</rdfs:comment>
      <xpackage:location xlink:href="stylesheet.css"/>
      <xpackage:contentType>text/css</xpackage:contentType>
    </xpackage:resource>

The full version of this example may be found in [XPACKAGE].

6.4 RSS 1.0: RDF Site Summary

When you consider all of the information that you access on the Web on a day-to-day basis: schedules, to-do lists, news headlines, search results, "What's New", etc., it becomes increasingly difficult to manage this information and integrate it into a coherent whole as the sources and diversity of the information increase. RSS 1.0 ("RDF Site Summary") is an RDF vocabulary that provides a lightweight multipurpose extensible metadata description and syndication format. In short, RSS 1.0 is a powerful and extensible way of describing, managing and making available to broad audiences relevant and timely information. It allows this information to be made available in a rich and reusable way, and is also perhaps the most widely deployed RDF application on the web.

To give a simple example, the W3C home page, shown in Figure 18, is a primary point of contact with the public and serves in part to disseminate information about the deliverables of the Consortium. The center column of news items changes frequently. To support the timely dissemination of this information, the W3C Team has implemented an RDF Site Summary (RSS 1.0) news feed that makes the content in the center column available to others to repurpose as they will. News syndication sites may merge the headlines into a summary of the day's latest news, others may display the headlines as links as a service to their readers, and, increasingly, individuals may subscribe to this feed with a desktop application. These desktop RSS readers allow their users to keep track of potentially hundreds of sites, without having to visit each one in their browser.

Figure 18: The W3C Home Page

Numerous sites all over the Web provide RSS 1.0 feeds. Example 33 is an example of the W3C feed:

<?xml version="1.0" encoding="utf-8"?>

<rdf:RDF xmlns="http://purl.org/rss/1.0/"
    xmlns:dc="http://purl.org/dc/elements/1.1/" 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

  <channel rdf:about="http://www.w3.org/2000/08/w3c-synd/home.rss">
    <title>The World Wide Web Consortium</title>
    <description>Leading the Web to its Full Potential...</description>
    <link>http://www.w3.org/</link>

    <dc:date>2002-10-28T08:07:21Z</dc:date>

    <items>
        <rdf:Seq>
            <rdf:li rdf:resource="http://www.w3.org/News/2002#item164"/>
            <rdf:li rdf:resource="http://www.w3.org/News/2002#item168"/>
            <rdf:li rdf:resource="http://www.w3.org/News/2002#item167"/>
        </rdf:Seq>
    </items>

  </channel>

  <item rdf:about="http://www.w3.org/News/2002#item164">
    <title>User Agent Accessibility Guidelines Become a W3C 
       Proposed Recommendation</title>
    <description>17 October 2002: W3C is pleased to announce the 
       advancement of User Agent Accessibility Guidelines 1.0 to 
       Proposed Recommendation. Comments are welcome through 14 November. 
       Written for developers of user agents, the guidelines lower 
       barriers to Web accessibility for people with disabilities 
       (visual, hearing, physical, cognitive, and neurological). 
       The companion Techniques Working Draft is updated. Read about 
       the Web Accessibility Initiative. (News archive)</description>
    <link>http://www.w3.org/News/2002#item164</link>
    <dc:date>2002-10-17</dc:date>
  </item>

  <item rdf:about="http://www.w3.org/News/2002#item168">
    <title>Working Draft of Authoring Challenges for Device 
       Independence Published</title>
    <description>25 October 2002: The Device Independence 
       Working Group has released the first public Working Draft of 
       Authoring Challenges for Device Independence. The draft describes 
       the considerations that Web authors face in supporting access to 
       their sites from a variety of different devices. It is written 
       for authors, language developers, device experts and developers 
       of Web applications and authoring systems. Read about the Device 
       Independence Activity (News archive)</description>
    <link>http://www.w3.org/News/2002#item168</link>
    <dc:date>2002-10-25</dc:date>
  </item>

  <item rdf:about="http://www.w3.org/News/2002#item167">
    <title>CSS3 Last Call Working Drafts Published</title>
    <description>24 October 2002: The CSS Working Group has 
       released two Last Call Working Drafts and welcomes comments 
       on them through 27 November. CSS3 module: text is a set of 
       text formatting properties and addresses international contexts. 
       CSS3 module: Ruby is properties for ruby, a short run of text 
       alongside base text typically used in East Asia. CSS3 module: 
       The box model for the layout of textual documents in visual 
       media is also updated. Cascading Style Sheets (CSS) is a 
       language used to render structured documents like HTML and 
       XML on screen, on paper, and in speech. Visit the CSS home 
       page. (News archive)</description>
    <link>http://www.w3.org/News/2002#item167</link>
    <dc:date>2002-10-24</dc:date>
  </item>

</rdf:RDF>

As Example 33 shows, the format is designed for content that can be packaged into easily disinguishable sections. News sites, web logs, sports scores, stock quotes, and the like are all use-cases for RSS 1.0.

The RSS feed can be requested by any application able to "speak" HTTP. More recently, however, RSS 1.0 applications are splitting into three different catagories:

• Online aggregators - Sites such as Meerkat and NewsIsFree, shown side-by-side in Figure 19 (each mirroring W3C's column of news). These gather feeds from thousands of sources, and seperate each of the <item>s out, and add them together again into one large group. The whole group is then made searchable. In this way, one can search for the latest news on, for example, "Java" from perhaps thousands of sites, without having to search them all.
• Desktop Readers - Utilities such as Amphetadesk and NetNewsWire Lite allow their users to subscribe to hundreds of feeds from their desktop. Readers customarily refresh each feed once an hour, allowing users to stay up to date.
• Scripts - RSS's original purpose was to allow webmasters to include the content of another's site within their own. RSS 1.0 is still used in this way, with many sites (Slashdot for example) incorporating RSS feeds on their front page.

Figure 19: MeerKat and NewsIsFree

RSS 1.0 is extensible by design. By importing additional RDF vocabularies (or modules as they are known within the RSS development community), the RSS 1.0 author can provide large amounts of metadata and handling instructions to the recipient of the file. Modules can, as with more general RDF vocabularies, be written by anyone. Currently there are 3 official modules and 19 proposed modules readily recognised by the community at large. These modules range from the complete Dublin Core module to more specialised RSS-centric modules such as the Aggregation module.

Care should be taken when discussing "RSS" is the scope of RDF. There are currently two RSS specification strands. One strand (RSS 0.91,0.92,0.93,0.94 and 2.0) does not use RDF. The other strand (RSS 0.9 and 1.0) does.

6.5 CIM/XML

Electric utilities use power system models for a number of different purposes. For example, simulations of power systems are necessary for planning and security analysis. Power system models are also used in actual operations, e.g., by the Energy Management Systems (EMS) used in energy control centers. An operational power system model can consist of thousands of classes of information. In addition to using these models in-house, utilities need to exchange system modeling information, both in planning, and for operational purposes, e.g., for coordinating transmission and ensuring reliable operations. However, individual utilities use different software for these purposes, and as a result the system models are stored in different formats, making the exchange of these models difficult.

In order to support the exchange of power system models, utilities needed to agree on common definitions of power system entities and relationships. To support this, the Electric Power Research Institute (EPRI) a non-profit energy research consortium, developed a Common Information Model (CIM). The CIM specifies common semantics for power system resources, their attributes, and relationships. In addition, to further support the ability to electronically exchange CIM models, the power industry has developed CIM/XML, a language for expressing CIM models in XML. CIM/XML is an RDF application, using RDF and RDF Schema to organize its XML structures. The North American Electric Reliability Council (NERC) (an industry-supported organization formed to promote the reliability of electricity delivery in North America) has adopted CIM/XML as the standard for exchanging models between power transmission system operators. The CIM/XML format is also going through an IEC international standardization process. An excellent discussion of CIM/XML can be found in [DWZ01]. [NB: This power industry CIM should not be confused with the CIM developed by the Distributed Management Task Force for defining management information for distributed software, network, and enterprise environments. The DMTF CIM also has an XML representation, but does not use RDF.]

The CIM can represent all of the major objects of an electric utility as object classes and attributes, as well as their relationships. CIM uses these object classes and attributes to support the integration of independently developed applications between vendor specific EMS systems, or between an EMS system and other systems that are concerned with different aspects of power system operations, such as generation or distribution management.

The CIM is specified as a set of class diagrams using the Unified Modeling Language (UML). The base class of the CIM is the PowerSystemResource class, with other more specialized classes such as Substation, Switch, and Breaker being defined as subclasses. CIM/XML represents the CIM as an RDF schema vocabulary, and uses RDF/XML as the language for exchanging specific system models. Example 34 shows examples of CIM/XML class and property definitions:

<rdfs:Class rdf:ID="PowerSystemResource"> 
  <rdfs:label xml:lang="en">PowerSystemResource</rdfs:label> 
  <rdfs:comment>"A power system component that can be either an
    individual element such as a switch or a set of elements 
    such as an substation. PowerSystemResources that are sets 
    could be members of other sets. For example a Switch is a 
    member of a Substation and a Substation could be a member 
    of a division of a Company"</rdfs:comment> 
</rdfs:Class>

<rdfs:Class rdf:ID="Breaker"> 
  <rdfs:label xml:lang="en">Breaker</rdfs:label> 
  <rdfs:subClassOf rdf:resource="#Switch" /> 
  <rdfs:comment>"A mechanical switching device capable of making, 
     carrying, and breaking currents under normal circuit conditions 
     and also making, carrying for a specified time, and breaking 
     currents under specified abnormal circuit conditions e.g. those 
     of short circuit. The typeName is the type of breaker, e.g., 
     oil, air blast, vacuum, SF6."</rdfs:comment> 
</rdfs:Class>

<rdf:Property rdf:ID="Breaker.ampRating"> 
   <rdfs:label xml:lang="en">ampRating</rdfs:label> 
   <rdfs:domain rdf:resource="#Breaker" /> 
   <rdfs:range rdf:resource="#CurrentFlow" /> 
   <rdfs:comment>"Fault interrupting rating in amperes"</rdfs:comment> 
</rdf:Property>

CIM/XML uses only a subset of the complete RDF/XML syntax, in order to simplify serialization of models. In addition, CIM/XML implements some extensions to the RDF Schema vocabulary (defined in the cims: namespace) to support inverse roles and multiplicity (cardinality) constraints describing how many instances of a given property are allowed for a given resource from the CIM UML diagrams (allowable values for a multiplicity declaration are zero-or-one, exactly-one, zero-or-more, one-or-more). The properties in Example 35 illustrate these extensions:

<rdf:Property rdf:ID="Breaker.OperatedBy"> 
   <rdfs:label xml:lang="en">OperatedBy</rdfs:label> 
   <rdfs:domain rdf:resource="#Breaker" /> 
   <rdfs:range rdf:resource="#ProtectionEquipment" /> 
   <cims:inverseRoleName rdf:resource="#ProtectionEquipment.Operates" /> 
   <cims:multiplicity rdf:resource="http://www.cim-logic.com/schema/990530#M:0..n" />
   <rdfs:comment>"Circuit breakers may be operated by 
       protection relays."</rdfs:comment>
</rdf:Property>

<rdf:Property rdf:ID="ProtectionEquipment.Operates"> 
   <rdfs:label xml:lang="en">Operates</rdfs:label> 
   <rdfs:domain rdf:resource="#ProtectionEquipment" /> 
   <rdfs:range rdf:resource="#Breaker" /> 
   <cims:inverseRoleName rdf:resource="#Breaker.OperatedBy" /> 
   <cims:multiplicity rdf:resource="http://www.cim-logic.com/schema/990530#M:0..n" />
   <rdfs:comment>"Circuit breakers may be operated by 
       protection relays."</rdfs:comment>
</rdf:Property>

EPRI has conducted successful interoperability tests using CIM/XML to exchange real-life, large-scale models (involving, in the case of one test, data describing over 2000 substations) between a variety of vendor products, and validating that these models would be correctly interpreted by typical utility applications. Although the CIM was originally intended for EMS systems, it is also being extended to support power distribution and other applications as well.

The Object Management Group has adopted an object interface standard to access CIM power system models called the Data Access Facility [DAF]. Like the CIM/XML language, the DAF is based on the RDF model and shares the same RDFS CIM schema. However, while CIM/XML enables a model to be exchanged as a document, DAF enables an application to access the model as a set of objects.

CIM/XML illustrates the useful role RDF can play in supporting XML-based exchange of information that is naturally expressed as entity-relationship or object-oriented classes, attributes, and relationships (even when that information will not necessarily be Web-accessable). In these cases, RDF provides a basic structure for the XML in support of identifying objects, and using them in structured relationships. This connection is illustrated by a number of applications using RDF/XML for information interchange, as well as a number of projects investigating linkages between RDF (or ontology languages such as DAML+OIL) and UML (and its XML representations).

The need for additional declarative power illustrated by the need to add cardinality constaints to CIM/XML shows the type of requirement leading to the development of more powerful RDF-based schema/ontology languages such as DAML+OIL or OWL described in Section 5.5. Such languages may be appropriate in supporting many similar modeling applications in the future.

Finally, CIM/XML also illustrates an important fact for those looking for additional examples of "RDF in the Field": sometimes languages are described as "XML" languages, or systems are described as using "XML", and the "XML" they are actually using is RDF/XML, i.e., they are RDF applications. Sometimes it is necessary to go fairly far into the description of the language or system in order to find this out (in some examples that have been found, RDF is never explicitly mentioned at all, but sample data clearly shows it is RDF/XML). Moreover, in applications such as CIM/XML, the RDF that is created will not be readily found on the Web, since it is intended for information exchange between software components rather than for general access (although future scenarios could be imagined in which more of this type of RDF would become Web-accessible).

6.6 Gene Ontology Consortium

Structured metadata using controlled vocabularies such as SNOMED RT (Systematized Nomenclature of Medicine Reference Terminology) and MeSH (Medical Subject Headings) plays an important role in medicine, enabling efficient literature searches and aiding in the distribution and exchange of medical knowledge [COWAN]. At the same time, the field of medicine is rapidly changing, and with that comes the need to develop additional vocabularies.

The objective of the Gene Ontology (GO) Consortium is to provide controlled vocabularies to describe specific aspects of gene products. Collaborating databases annotate their gene products (or genes) with GO terms, providing references and indicating what kind of evidence is available to support the annotations. The use of common GO terms by these databases facilitates uniform queries across them. The GO ontologies are structured to allow both attribution and querying to be performed at different levels of granularity. The GO vocabularies are dynamic, since knowledge of gene and protein roles in cells is accumulating and changing.

The three organizing principles of the GO are molecular function, biological process and cellular component. A gene product has one or more molecular functions and is used in one or more biological processes; it may be, or may be associated with, one or more cellular components. Definitions of the terms within all three of these ontologies are contained in a single (text) definition file. XML (actually, RDF/XML) formatted versions, containing all three ontology files and all available definitions, are generated monthly.

Function, process and component are represented as directed acyclic graphs (DAGs) or networks. A child term may be an "instance" of its parent term (isa relationship) or a component of its parent term (part-of relationship). A child term may have more than one parent term and may have a different class of relationship with its different parents. Synonyms and cross-references to external databases are also represented in the ontologies. RDF was chosen for use in the XML versions of the ontologies because of its flexibility in representing these graph structures, as well as its widespread tool support.

Example 36 shows some sample GO information from the GO documentation:

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE go:go> 
<go:go xmlns:go="http://www.geneontology.org/xml-dtd/go.dtd#" 
       xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> 
  <go:version timestamp="Wed May 9 23:55:02 2001" /> 

  <rdf:RDF> 
     <go:term rdf:about="http://www.geneontology.org/go#GO:0003673"> 
        <go:accession>GO:0003673</go:accession> 
        <go:name>Gene_Ontology</go:name> 
        <go:definition></go:definition> 
     </go:term> 

     <go:term rdf:about="http://www.geneontology.org/go#GO:0003674"> 
        <go:accession>GO:0003674</go:accession> 
        <go:name>molecular_function</go:name> 
        <go:definition>The action characteristic of a gene product.</go:definition> 
        <go:part-of rdf:resource="http://www.geneontology.org/go#GO:0003673" /> 
        <go:dbxref> 
           <go:database_symbol>go</go:database_symbol> 
           <go:reference>curators</go:reference> 
        </go:dbxref> 
     </go:term> 

     <go:term rdf:about="http://www.geneontology.org/go#GO:0016209"> 
        <go:accession>GO:0016209</go:accession> 
        <go:name>antioxidant</go:name> 
        <go:definition></go:definition> 
        <go:isa rdf:resource="http://www.geneontology.org/go#GO:0003674" /> 
        <go:association> 
           <go:evidence evidence_code="ISS"> 
              <go:dbxref> 
                 <go:database_symbol>fb</go:database_symbol> 
                 <go:reference>fbrf0105495</go:reference> 
              </go:dbxref> 
           </go:evidence> 
           <go:gene_product> 
              <go:name>CG7217</go:name> 
              <go:dbxref> 
                 <go:database_symbol>fb</go:database_symbol> 
                 <go:reference>FBgn0038570</go:reference> 
              </go:dbxref> 
           </go:gene_product> 
        </go:association> 
        <go:association> 
           <go:evidence evidence_code="ISS"> 
              <go:dbxref> 
                 <go:database_symbol>fb</go:database_symbol> 
                 <go:reference>fbrf0105495</go:reference> 
              </go:dbxref> 
           </go:evidence> 
           <go:gene_product> 
              <go:name>Jafrac1</go:name> 
              <go:dbxref> 
                 <go:database_symbol>fb</go:database_symbol> 
                 <go:reference>FBgn0040309</go:reference> 
              </go:dbxref> 
           </go:gene_product> 
        </go:association> 
      </go:term> 
  </rdf:RDF> 
</go:go> 

Example 36 illustrates that go:term is the basic element. The GO has added its own extensions to the RDF vocabulary (they do not use RDFS). For example, term GO:0016209 has the element <go:isa rdf:resource="http://www.geneontology.org/go#GO:0003674" />. This tag represents the relationship "GO:0016209 isa GO:0003674", or, in English, "Antioxidant is a molecular function." Another specialized relationship is go:part-of. For example, GO:0003674 has the element <go:part-of rdf:resource="http://www.geneontology.org/go#GO:0003673" />. This says that "Molecular function is part of the Gene Ontology".

Every annotation must be attributed to a source, which may be a literature reference, another database or a computational analysis. The annotation must indicate what kind of evidence is found in the cited source to support the association between the gene product and the GO term. A simple controlled vocabulary is used to record evidence. Examples include:

• ISS means "inferred from sequence similarity [with <database:sequence_id>]"
• IDA means "inferred from direct assay"
• TAS means "traceable author statement"

The go:dbxref element represents the term in an external database, and go:association represents the gene associations of each term. go:association can have both go:evidence, which holds a go:dbxref to the evidence supporting the association, and a go:gene_product, which contains the gene symbol and go:dbxref.

The GO illustrates a number of interesting points. First, it shows that the value of using XML for information exchange can be enhanced by structuring that XML using RDF. This is particularly true for data that has a graph or network structure, rather than being a strict hierarchy. The GO is also another example in which the RDF will not necessarily appear for direct use on the Web (although the files are Web-accessible). It is also another example of data which is, on the surface, described as "XML", but on closer examination is RDF/XML. In addition, the GO illustrates the role RDF can play as a basis for representing ontologies. This role will be further enhanced once richer RDF-based languages for specifying ontologies, such as the DAML+OIL or OWL languages discussed in Section 5.5, become more widely used.

6.7 Describing Device Capabilities and User Preferences

In recent years a large number of new mobile devices for browsing the web have appeared. Many of these devices have highly divergent capabilities including a wide range of input and output capabilities as well as different levels of language support. Mobile devices may also have widely differing network connectivity capabilities. Users of these new devices expect a usable presentation regardless of the device's capabilities or the current network characteristics. Likewise, users want their dynamically changing preferences (e.g. turn audio on/off) to be considered when content or an application is presented. The reality, however, is that device heterogeneity and the lack of a standard way for users to convey their preferences to the server, may result in: content that cannot be stored on the device, content that cannot be displayed or content that violates the desires of the user. Additionally, the resulting content may take too long to convey over the network to the client device.

A solution for addressing these problems is for a client to encode its delivery context - the device's capabilities, the user's preferences, the network characteristics, etc. - in such a way that a server can use the context to customize content for the device and user (see [DIPRINC] for a definition of delivery context). The W3C's Composite Capabilities/Preferences Profile (CC/PP) specification [CC/PP] helps to address this problem by defining a generic framework for describing a delivery context.

The CC/PP framework defines a relatively simple structure - a two-level hierarchy of components and attribute/value pairs. A component may be used to capture a part of a delivery context (e.g. network characteristics, software supported by a device or the hardware characteristics of a device). A component may contain one or more attributes. For example a component that encodes user preferences may contain an attribute to specify whether or not AudioOutput is desired.

CC/PP defines its structure (the hierarchy described above) using RDF Schema (see [CC/PP] for details of the structure schema). A CC/PP vocabulary defines specific components and their attributes. [CC/PP], however, does not define such vocabularies. Instead, vocabularies are defined by other organizations or applications (as described below). [CC/PP] also does not define a protocol for transporting an instance of a CC/PP vocabulary.

An instance of a CC/PP vocabulary is called a profile. CC/PP attributes are encoded as RDF properties in a profile. Example 37 shows a profile fragment of user preferences for a user that prefers an audio presentation:

 <ccpp:component>
  <rdf:Description rdf:ID="UserPreferences">
   <rdf:type rdf:resource="http://www.example.org/profiles/prefs/v1_0#UserPreferences"/>
   <ex:AudioOutput>Yes</ex:AudioOutput>
   <ex:Graphics>No</ex:Graphics>
   <ex:Languages>
    <rdf:Seq>
     <rdf:li>en-cockney</rdf:li>
     <rdf:li>en</rdf:li>
    </rdf:Seq>
   </ex:Languages>
  </rdf:Description>
 </ccpp:component>

There are several advantages to using RDF in this application. First, a profile encoded via CC/PP may include attributes that were defined in schemas created by different organizations. RDF is a natural fit for these profiles because no single organization is likely to create a super schema for the aggregated profile data. A second advantage of RDF is that it facilitates (by virtue of its graph-based data model) the insertion of arbitrary attributes (RDF properties) into a profile. This is particularly useful for profiles that include frequently changing data such as location information.

The Open Mobile Alliance has defined the User Agent Profile (UAProf) [UAPROF] - a CC/PP-based framework that includes a vocabulary for describing device capabilities, user agent capabilities, network characteristics, etc., as well as a protocol for transporting a profile. UAProf defines six components including: HardwarePlatform, SoftwarePlatform, NetworkCharacteristics and BrowserUA. It also defines several attributes for each of its components although a component's attributes are not fixed - they may be supplemented or overridden. Example 38 shows a fragment of UAProf's HardwarePlatform component:

 <prf:component>
  <rdf:Description rdf:ID="HardwarePlatform">
   <rdf:type rdf:resource="http://www.openmobilealliance.org/profiles/UAPROF/ccppschema-20021113#HardwarePlatform"/>
   <prf:ScreenSizeChar>15x6</prf:ScreenSizeChar>
   <prf:BitsPerPixel>2</prf:BitsPerPixel>
   <prf:ColorCapable>No</prf:ColorCapable>
   <prf:BluetoothProfile>
    <rdf:Bag>
     <rdf:li>headset</rdf:li>
     <rdf:li>dialup</rdf:li>
     <rdf:li>lanaccess</rdf:li>
    </rdf:Bag>
   </prf:BluetoothProfile>
  </rdf:Description>
 </prf:component>

The UAProf protocol supports both static profiles and dynamic profiles. A static profile is accessed via a URI. This has several advantages: a client's request to a server only contains a URI rather a potentially verbose XML document (thus minimizing over the air traffic); the client does not have to store and/or create the profile; the implementation burden on a client is relatively light-weight. Dynamic profiles are created on-the-fly and consequently do not have an associated URI. They may consist of a profile fragment containing a difference from a static profile, but they may also contain unique data that is not included in the client's static profile. A request may contain any number of static profiles and dynamic profiles. However, the ordering of the profiles is important as later profiles override earlier profiles in the request. See [UAPROF] for more information about UAProf's protocol and its rules for resolving multiple profiles.

Several other communities (i.e. 3GPP's TS 26.234 [3GPP] and the WAP Forum's Multimedia Messaging Service Client Transactions Specification [MMS-CTR]) have defined vocabularies based on CC/PP. As a result, a profile may take advantage of the distributed nature of RDF and include components defined from various vocabularies. Example 39 is shows such a profile:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#"
         xmlns:mms="http://www.wapforum.org/profiles/MMS/ccppschema-20010111#"
	 xmlns:pss="http://www.3gpp.org/profiles/PSS/ccppschema-YYYYMMDD#">

 <rdf:Description rdf:ID="SomeDevice">
  <prf:component>
   <rdf:Description rdf:ID="Streaming">
    <rdf:type rdf:resource="http://www.3gpp.org/profiles/PSS/ccppschema-PSS5#Streaming"/>
    <pss:AudioChannels>Stereo</pss:AudioChannels>
    <pss:VideoPreDecoderBufferSize>30720</pss:VideoPreDecoderBufferSize>
    <pss:VideoInitialPostDecoderBufferingPeriod>0</pss:VideoInitialPostDecoderBufferingPeriod>
    <pss:VideoDecodingByteRate>16000</pss:VideoDecodingByteRate>
   </rdf:Description>
  </prf:component>
 
  <prf:component>
   <rdf:Description rdf:ID="MmsCharacteristics">
    <rdf:type rdf:resource="http://www.wapforum.org/profiles/MMS/ccppschema-20010111#Streaming"/>
    <mms:MmsMaxMessageSize>2048</mms:MmsMaxMessageSize>
    <mms:MmsMaxImageResolution>80x60</mms:MmsMaxImageResolution>
    <mms:MmsVersion>2.0</mms:MmsVersion>
   </rdf:Description>
  </prf:component>

  <prf:component>
   <rdf:Description rdf:ID="PushCharacteristics">
    <rdf:type rdf:resource="http://www.openmobilealliance.org/profiles/UAPROF/ccppschema-20010330#PushCharacteristics"/>
    <prf:Push-MsgSize>1024</prf:Push-MsgSize>
    <prf:Push-MaxPushReq>5</prf:Push-MaxPushReq>
    <prf:Push-Accept>
     <rdf:Bag>
      <rdf:li>text/html</rdf:li>
      <rdf:li>text/plain</rdf:li>
      <rdf:li>image/gif</rdf:li>
     </rdf:Bag>
    </prf:Push-Accept>
   </rdf:Description>
  </prf:component>

 </rdf:Description>
</rdf:RDF>

The definition of a delivery context and the data within a context will continually evolve. Consequently, RDF's inherent extensibility, and thus support for dynamically changing vocabularies, make RDF a good framework for encoding a delivery context.

7.1 RDF Semantics

As we've seen in the preceding sections, RDF is intended to be used to express statements about resources in the form of a graph, using specific vocabularies (names of resources, properties, classes, etc.). RDF is also intended to be the foundation for more advanced languages, such as those discussed in Section 5.5. In order to serve these purposes, the "meaning" of an RDF graph must be defined in a very precise manner.

Exactly what constitutes the "meaning" of an RDF graph in a broad sense may depend on many factors, including social conventions, comments in natural language, or links to other content-bearing documents ([RDF-CONCEPTS] provides further discussion of the various notions of meaning in RDF). Much of the meaning conveyed in these forms will not be directly accessible to machine processing, although this meaning may be used by human interpreters of the RDF information, or by programmers writing software to perform various kinds of processing on that RDF information. However, RDF statements also have a formal meaning which determines, with mathematical precision, the conclusions (or entailments) that machines can draw from an RDF graph. The RDF Semantics [RDF-SEMANTICS] defines this formal meaning, using a technique called model theory for specifying the semantics of a formal language. In other words, the RDF model theory provides the formal underpinnings for all of the concepts we have described. Based on the semantics defined in the model theory, it is simple to translate an RDF graph into a logical expression with essentially the same meaning.

7.2 Test Cases

The RDF Test Cases [RDF-TESTS] supplement the textual RDF specifications with test cases (examples) corresponding to particular technical issues addressed by the RDF Core Working Group. To help describe these examples, the Test Cases document introduces a notation called N-triples, which provides the basis for the triples notation used throughout this Primer. The test cases are published in machine-readable form at Web locations referenced by the Test Cases document, so developers can use these as the basis for automated testing of RDF software.

The test cases are divided into a number of categories:

• Positive and Negative Parser Tests: These test whether RDF/XML parsers produce a correct N-triples output graph from legal RDF/XML input documents, or correctly report errors if the input documents are not legal RDF/XML.
• Positive and Negative Entailment Tests: These test whether proper entailments (conclusions) are or are not drawn from sets of specified RDF statements.
• Datatype-aware Entailment Tests: These are positive or negative entailment tests that involve the use of datatypes, and hence require additional support for the specific datatypes involved in the tests.
• Miscellaneous Tests: These are tests that do not fall into one of the other categories.

The test cases are not a complete specification of RDF, and are not intended to take precedence over the normative specification documents. However, they are intended to illustrate the intent of the RDF Core Working Group with respect to the design of RDF, and developers may find these test cases helpful should the wording of the specifications be unclear on any point of detail.

8.1 Normative References

[RDF-CONCEPTS]

Resource Description Framework (RDF): Concepts and Abstract Syntax, Klyne G., Carroll J. (Editors), World Wide Web Consortium, 08 November 2002 (work in progress). This version is http://www.w3.org/TR/2002/WD-rdf-concepts-20021108/. The latest version is http://www.w3.org/TR/rdf-concepts/.

[RDF-MIME-TYPE]

Application/rdf+xml Media Type Registration, Swartz A., IETF Internet Draft, August 2002 (work in progress). Version available at http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-01.txt .

[RDF-MS]

Resource Description Framework (RDF) Model and Syntax Specification, Lassila O., Swick R. (Editors), World Wide Web Consortium. 22 February 1999. This version is http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/. The latest version is http://www.w3.org/TR/REC-rdf-syntax/.

[RDF-SEMANTICS]

RDF Semantics, Hayes P. (Editor), World Wide Web Consortium, 12 November 2002 (work in progress). This version is http://www.w3.org/TR/2002/WD-rdf-mt-20021112/. The latest version is http://www.w3.org/TR/rdf-mt/.

[RDF-SYNTAX]

RDF/XML Syntax Specification (Revised), Beckett D. (Editor), World Wide Web Consortium, 8 November 2002 (work in progress). This version is http://www.w3.org/TR/2002/WD-rdf-syntax-grammar-20021108/. The latest version is http://www.w3.org/TR/rdf-syntax-grammar.

[RDF-TESTS]

RDF Test Cases, Grant J., Beckett D. (Editors), World Wide Web Consortium, 12 November 2002 (work in progress). This version is http://www.w3.org/TR/2002/WD-rdf-testcases-20021112/. The latest version is http://www.w3.org/TR/rdf-testcases/.

[RDF-VOCABULARY]

RDF Vocabulary Description Language 1.0: RDF Schema, Brickley D., Guha R.V. (Editors), World Wide Web Consortium, 12 November 2002 (work in progress). This version is http://www.w3.org/TR/2002/WD-rdf-schema-20021112/. The latest version is http://www.w3.org/TR/rdf-schema/.

[URIS]

RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax, Berners-Lee T., Fielding R., Masinter L., IETF, August 1998. This document is http://www.isi.edu/in-notes/rfc2396.txt.

[XML]

Extensible Markup Language (XML) 1.0, Second Edition, Bray T., Paoli J., Sperberg-McQueen C.M, Maler E. (Editors), World Wide Web Consortium, 6 October 2000. This version is http://www.w3.org/TR/2000/REC-xml-20001006. The latest version is http://www.w3.org/TR/REC-xml.

[XML-BASE]

XML Base, Marsh J. (Editor), W3C Recommendation. World Wide Web Consortium, 27 June 2001. This version is http://www.w3.org/TR/2001/REC-xmlbase-20010627/. The latest version is http://www.w3.org/TR/xmlbase/.

[XML-NS]

Namespaces in XML, Bray T., Hollander D., Layman A. (Editors), World Wide Web Consortium, 14 January 1999. This version is http://www.w3.org/TR/1999/REC-xml-names-19990114/. The latest version is http://www.w3.org/TR/REC-xml-names/.

8.2 Informational References

[3GPP]

3GPP TS 26.234. 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end packet switched streaming service; Protocols and codecs V5.2.0 (2002-09). This document is available at http://www.3gpp.org/specs/specs.htm via directory ftp://ftp.3gpp.org/specs/2002-09/Rel-5/26_series/.

[ADDRESS-SCHEMES]

Addressing Schemes, Connolly D., 2001. This document is http://www.w3.org/Addressing/schemes.html.

[BATES96]

Indexing and Access for Digital Libraries and the Internet: Human, Database, and Domain Factors, Bates M.J., 1996. This document is http://is.gseis.ucla.edu/research/mjbates.html.

[BERNERS-LEE98]

What the Semantic Web can represent, Berners-Lee T., 1998. This document is http://www.w3.org/DesignIssues/RDFnot.html.

[CC/PP]

Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies, Klyne G., Reynolds F., Woodrow C., Ohto H., Butler, M., World Wide Web Consortium, 08 November 2002 (work in progress). This version is http://www.w3.org/TR/2002/WD-CCPP-struct-vocab-20021108/. The latest version is http://www.w3.org/TR/CCPP-struct-vocab/.

[CG]

Conceptual Graphs, Sowa J., ISO working document ISO/JTC1/SC32/WG2 N 000, 2 April 2001 (work in progress). Available at http://users.bestweb.net/~sowa/cg/cgstand.htm.

[COWAN]

Metadata, Reuters Health Information, and Cross-Media Publishing , Cowan, J., 2002. Presentation at Seybold New York 2002 Enterprise Publishing Conference. This document is http://seminars.seyboldreports.com/seminars/2002_new_york/presentations/014/cowan_john.ppt. An accompanying transcript is http://seminars.seyboldreports.com/seminars/2002_new_york/transcripts/doc/transcript_EP7.doc

[DAF]

Utility Management System (UMS) Data Access Facility, Object Management Group, OMG document formal/01-06-01, June 2001. This document is http://cgi.omg.org/docs/formal/01-06-01.pdf.

[DAML+OIL]

DAML+OIL (March 2001) Reference Description, Connolly D., van Harmelen F., Horrocks I., McGuinness D.L., Patel-Schneider P.F., Stein L.A., W3C Note 18 December 2001. This document is http://www.w3.org/TR/daml+oil-reference.

[DC]

Dublin Core Metadata Element Set, Version 1.1: Reference Description, 02 July 1999. This document is http://dublincore.org/documents/dces/.

[DIPRINC]

Device Independence Principles. Gimson, R., Finkelstein, S., Maes, S., Suryanarayana, L., World Wide Web Consortium, 18 September 2001 (work in progress). This version is http://www.w3.org/TR/2001/WD-di-princ-20010918. The latest version is http://www.w3.org/TR/di-princ/.

[DWZ01]

XML for CIM Model Exchange , deVos A., Widergreen S.E., Zhu J., Proc. IEEE Conference on Power Industry Computer Systems, Sydney, Australia, 2001. This document is http://www.langdale.com.au/PICA/.

[GRAY]

Logic, Algebra and Databases, Gray P., Ellis Horwood Ltd., 1984. ISBN 0-85312-709-3, 0-85312-803-0, 0-470-20103-7, 0-470-20259-9.

[HAYES]

In Defense of Logic, Hayes P., Proceedings from the International Joint Conference on Artificial Intelligence, 1975, San Francisco. Morgan Kaufmann Inc., 1977. Also in Computation and Intelligence: Collected Readings, Luger G. (ed), AAAI press/MIT press, 1995. ISBN 0-262-62101-0.

[KIF]

Knowledge Interchange Format, Genesereth M., draft proposed American National Standard NCITS.T2/98-004. Available at http://logic.stanford.edu/kif/dpans.html.

[LUGER]

Artificial Intelligence: Structures and Strategies for Complex Problem Solving (3rd ed.), Luger G., Stubblefield W., Addison Wesley Longman, 1998. ISBN 0-805-31196-3.

[MMS-CTR]

Multimedia Messaging Service Client Transactions Specification. WAP-206-MMSCTR-20020115-a. This document is available at http://www.openmobilealliance.org/.

[NAMEADDRESS]

Naming and Addressing: URIs, URLs, ..., Connolly D., 2002. This document is http://www.w3.org/Addressing/.

[OWL]

OWL Web Ontology Language 1.0 Reference, Dean M., Connolly D., van Harmelen F., Hendler J., Horrocks I., McGuinness D.L., Patel-Schneider P.F., Stein L.A. (Editors), World Wide Web Consortium, 12 November 2002 (work in progress). This version is http://www.w3.org/TR/2002/WD-owl-ref-20021112/. The latest version is http://www.w3.org/TR/owl-ref/.

[PRISM]

PRISM: Publishing Requirements for Industry Standard Metadata, Version 1.1, 19 February 2002. This document is http://www.prismstandard.org/techdev/prismspec11.asp.

[RDFISSUE]

RDF Issue Tracking, McBride B., 2002. This document is http://www.w3.org/2000/03/rdf-tracking/.

[RSS]

RDF Site Summary (RSS) 1.0, Beged-Dov G., Brickley D., Dornfest R., Davis I., Dodds L., Eisenzopf J., Galbraith D., Guha R.V., MacLeod K., Miller E., Swartz A., van der Vlist E., 2000. This document is http://purl.org/rss/1.0/spec.

[SOWA]

Knowledge Representation: Logical, Philosophical and Computational Foundations, Sowa J., Brookes/Cole, 2000. ISBN 0-534-94965-7.

[UAPROF]

User Agent Profile. OMA-WAP-UAProf-v1_1. This document is available at http://www.openmobilealliance.org/.

[WEBDATA]

Web Architecture: Describing and Exchanging Data, Berners-Lee T., Connolly D., Swick R., W3C Note, 7 June 1999. This document is http://www.w3.org/1999/04/WebData.

[XLINK]

XML Linking Language (XLink) Version 1.0, DeRose S., Maler E., Orchard D. (Editors), World Wide Web Consortium, 27 June 2001. This version is http://www.w3.org/TR/2001/REC-xlink-20010627/. The latest version is http://www.w3.org/TR/xlink/.

[XML-SCHEMA2]

XML Schema Part 2: Datatypes, Biron P., A. Malhotra (Editors), World Wide Web Consortium. 2 May 2001. This version is http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/. The latest version is http://www.w3.org/TR/xmlschema-2/.

[XPACKAGE]

XML Package (XPackage) 1.0 , Wilson G., Open eBook Forum Editor's Working Draft, 23 October 2002. This version is http://www.xpackage.org/specification/xpackage-draft-20021023.html. The latest version is http://www.xpackage.org/specification/.