RDF Primer

1. Introduction

The Resource Description Framework (RDF) is a general-purpose language for representing information in the World Wide Web. It is particularly intended for representing metadata about Web resources, such as the title, author, and modification date of a Web page, the copyright and syndication information about a Web document, the availability schedule for some shared resource, or the description of a Web user's preferences for information delivery. However, by generalizing the concept of a "Web resource", RDF can be used to represent information about anything that can be identified on the Web, such as information about items available from online shopping facilities (e.g., information about prices, publishers, and availability of books or recordings).

RDF provides a common framework for expressing this information in such a way that it can be exchanged between applications without loss of meaning. Since it is a common framework, application designers can leverage the availability of common RDF parsers and processing tools. Exchanging information between different applications means that the information may be made available to applications other than those for which it was originally created.

To make this discussion somewhat more concrete as soon as possible, the following is a small chunk of RDF in its XML serialization format.

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns="http://www.w3.org/2000/10/swap/pim/contact#">
  <Person rdf:about="http://www.w3.org/People/EM/contact#me">
    <mailbox rdf:resource="mailto:em@w3.org"/>
    <fullName>Eric Miller</fullName>
    <personalTitle>Semantic Web Activity Lead</personalTitle> 
  </Person>
</rdf:RDF>

This example roughly translates as a collection of statements "there is someone called Eric Miller, with the email address em@w3.org, and who is the Semantic Web Activity Lead". Note that the example contains what seem to be Web addresses, as well as some "properties" like "mailbox" and "fullName", and the values "em@w3.org", and "Eric Miller".

Like HTML, this form of information is machine processable, and links pieces of data across the Web. However, unlike conventional hypertext, RDF links can reference any identifiable things, including things that may or may not be Web-based data. The result is that in addition to describing Web pages, we can also convey information about cars, businesses, people, news events, etc. Further, RDF links themselves can be labeled, to indicate the kind of relationship that exists between the linked items.

The complete specification of RDF consists of a number of documents:

• RDF Model Theory (and graph syntax)
• RDF/XML syntax
• RDF Schema (and datatypes)
• RDF Test Cases
• RDF Primer (this document)

This Primer is intended to augment the other parts of the RDF specification, to help information system designers and application developers understand the features of RDF, and how to use them. In particular, the Primer is intended to answer such questions as:

• What information can RDF represent?
• What does RDF look like?
• How is RDF information created, accessed, and processed?
• How can existing information be combined with RDF?

The Primer is a non-normative document, which means that it does not provide a definitive (from the W3C's point of view) specification of RDF. The examples and other explanatory material in this document are provided to help you understand RDF, but they may not always provide definitive or fully-complete answers. In such cases, you should refer to the relevant normative parts of the RDF specification. To help you do this, we provide links pointing to the relevant parts of the normative specifications.

2. Making Statements About Resources

RDF is intended to provide a simple way to state properties of (facts about) Web resources, e.g., Web pages. For example, imagine that we want to record the fact that someone named John Smith created a particular Web page. A straightforward way to state this fact in English would be in the form of a simple statement, e.g.:

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 (the creator) 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

(note the use of "August 16, 1999" to identify a date).

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 this case) 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, object, or predicate 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 format for representing these statements and exchanging them between machines.

Fortunately, the existing Web architecture provides us with both of the necessary mechanisms. The Web's Uniform Resource Identifier (URI) provides us with a way to uniquely identify anything we want to talk about in an RDF statement, and the Extensible Markup Language (XML) provides us with a format for representing and exchanging RDF statements. The next two sections briefly describe these mechanisms.

2.1 Identifiers: Uniform Resource Identifier (URI)

If we want to discuss something, we must first identify it. How else will you know what one is referring to? In everyday communication, identity is assigned in many ways: "Bob", "The Moon", "373 Whitaker Ave.", "California", "VIN 2745534", "today's weather", etc., and ambiguities are generally resolved in terms of a shared semantic context between the sender and the receiver. To identify "things" on the Web, we also use identifiers.

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 string that identifies a Web resource by representing its primary access mechanism (essentially, its network "location"). However, we would like to be able to record information about many things in addition to Web pages. In particular, we'd like to record information about lots of things that don't have URLs. For example, I don't have a URL, and yet my employer needs to record all sorts of things about me in order to pay my salary, keep track of the work that I've been doing, and so on. My doctor needs to record other sorts of things about me in order to keep track of my medical history, tests that have been performed (and the results, who performed them, and when), shots I've received, etc.

We've recorded information about lots of things that don't have URLs in files (both manual and automated) for many years, and the way we identify those things is by assigning them identifiers : values that we uniquely associate with the individual things. The identifiers we use to identify various kinds of things go by names like "Social Security Number", "Part Number", "license number", "employee number", "user-id", etc. In some cases, these identifiers (such as Social Security Numbers) are assigned by an official authority of some kind. In other cases, these identifiers are generated by a private organization or individual. In some cases, these identifiers have a national or international scope within which they are unique (a Social Security Number has national scope), while in other cases they may only be unique within a very limited scope (my employee number is only unique among the numbers assigned by my specific employer). Nevertheless, these identifiers serve, if used properly, to identify the things we want to talk about.

The Web provides its own form of identifier for these purposes, called the Uniform Resource Identifier (URI). URIs are similar to URLs, in that different persons or organizations can independently create them, and use them to identify things. However, unlike URLs, 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 collection 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".

URIs essentially constitute an infinite stock of names that can be used to identify things. No one person or organization controls who makes URIs or how they can be used. While some URI schemes (such as URL's http:) depend on centralized systems (such as DNS), other schemes (such as freenet: ) are completely decentralized. This means that (as with any other kind of name), you don't need special authority or permission to create a URI for something, and you can create URIs for things you don't own (just as you can use whatever name you like for things you don't own in ordinary language). The URI is the foundation of the Web. While nearly every other part of the Web can be replaced, the URI cannot: it holds the Web together.

Since the URI is such a general identification mechanism, capable of identifying anything, it should not be surprising that RDF uses URIs as its mechanism for identifying the subjects, objects, and predicates in statements. In fact, RDF defines a resource as anything that is identifiable by a URI, and hence using URIs allows RDF to describe practically anything, and to state relationships between such things as well. We'll see how this works just a bit further on. But before we do that, we need to introduce a way for RDF statements to be physically represented and exchanged.

@@Introduce additional URI schemes explicitly: URNs, mailto:; rather than just mentioning freenet. Cite the W3C page on addressing: http://www.w3.org/Addressing/, and on registered addressing schemes: http://www.w3.org/Addressing/schemes.html@@.

@@Also need to resolve where the fragment identifiers text goes. It logically goes here with the URI discussion, but the explanatory text uses N-Triples, which are not introduced until later.@@

2.2 Documents: Extensible Markup Language (XML)

XML was designed to allow anyone to design their own document format and then write a document in that format. Like HTML documents (Web pages), XML documents contain text. This text consists primarily of plain text content, and markup in the form of tags. This markup allows a processing program to interpret the various pieces of content (elements). In HTML, the set of permissible tags, and their interpretation, is defined by the HTML specification. However, XML allows users to define their own markup languages (tags and the structures in which they can appear) adapted to their own specific requirements. For example, the following is a simple passage marked up using an XML-based markup language:

<sentence><person href="http://example.com/#me">I</person> 
just got a new pet <animal>dog</animal>.</sentence>

Elements delimited by tags ("sentence", "person", etc.) are introduced to reflect a particular structure associated with the passage. These tags allow a program written with an understanding of these particular elements to properly interpret the passage.

This particular markup language uses the words "sentence," "person," and "animal" to attempt to convey meaning. And they would to an English-speaking person reading it, or to a program specifically written to interpret this vocabulary. However, there is no built-in meaning here. For example, to non-English speakers, or to a program not written to understand this markup, the element "person" may mean absolutely nothing. Take the following for example:

<dfgre><reghh bjhb="http://example.com/#me">I</reghh> 
just got a new pet <yudis>dog</yudis>.</dfgre>

To a machine, this is the exact same structure as the previous example. However, it is no longer clear what is being said. Moreover, others may have used the same words in their own markup languages, but with completely different intended meanings. For example, "sentence" in another markup language might refer to the amount of time that a convicted criminal must serve in a penal institution. So additional mechanisms must be provided to help keep XML vocabulary straight.

To prevent confusion, it is necessary to uniquely identify markup elements. This is done in XML using XML Namespaces . A namespace is just a way of identifying a part of the Web (space) which acts as a qualifier for a specific set of names. A "namespace" is created for an XML markup language by creating a URI for it. By qualifying tag names with the URIs of their namespaces, anyone can create their own tags and properly distinguish them from tags created by others. A useful practice is to create a Web page to describe the markup language (and the intended meaning of the tags) and use the URL of that Web page as the URI for its namespace.

<my:sentence xmlns:my="http://example.org/xml/documents/">
   <my:person my:href="http://example.com/#me">I</my:person> 
just got a new pet <my:animal>dog</my:animal>.
</my:sentence>

Since everyone's tags have their own URIs, we don't have to worry about tag names conflicting. The elements mean the same if they have the same URIs.

RDF defines a specific XML markup language for use in writing down RDF information, and for exchanging it between machines. An example of this language was given in Section 1, and the language is described in Section 3.

2.3 The RDF Model

Now that we've introduced URIs for identifying things we want to talk about on the Web, and 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, 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

RDF models statements as nodes and arcs in a graph. In this notation, a statement is represented by a node for the subject, a node for the object, and a labeled arc between them for the predicate. So the RDF statement above would be represented by the graph:

Figure 1: A Simple RDF Statement (SVG version)

Collections of statements are represented by corresponding collections 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, introducing suitable URIs to name the properties "creation-date" and "language", use the following graph:

Figure 2: Several Statements About the Same Resource (SVG version)

This graph illustrates that RDF permits the objects in statements to be simple strings, if necessary to represent property values, as well as URIs. In drawing RDF graphs, nodes that represent URIs are shown as ellipses, while nodes that represent strings are shown as boxes. RDF graphs are technically "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, so an alternative way of writing down the statements, called N-Triples, can also be used. In the N-Triples notation, each statement in the graph is written as a simple triple of subject, predicate, and object, in that order. The N-Triples representing the above three statements would be written:

<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, the N-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 N-Triples representation of the graph, but only once in the drawn graph.

These examples begin to illustrate some of the advantages of using URIs 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 string "John Smith", we've assigned him a URI, in this case (using a URI based on his employee number) http://www.example.org/staffid/85740 . An advantage of using a URI in this case is that we can be more precise in our identification. That is, the creator of the page isn't the string "John Smith'', or any one of the thousands of people having "John Smith" as their name, but the particular John Smith associated with that URI (whoever created the URI defines the association). Moreover, since we have a URI 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

Figure 3: More Information about John Smith (SVG version)

The examples also illustrate that RDF uses URIs as predicates in RDF statements. That is, rather than using strings such as "creator" or "name" to identify properties, RDF uses URIs. Using URIs 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 text string. For instance, in our example, example.org uses "name" to mean someone's full name written out as a string (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.example.org/geneology/terms/name for hers, we can keep straight the fact that there are distinct properties involved (even if a program can't automatically determine the distinct meanings). Another reason why it is important to use URIs 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 URI as the subject.

Using URIs as subjects, objects, and predicates 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 N-Triple

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

the predicate http://purl.org/dc/elements/1.1/creator is an unambiguous reference to the "creator" attribute in the Dublin Core metadata attribute set, a widely-used collection 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 defined 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.

As a result, 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 information (the list of book rating averages) and create a "Top Ten Highest Rated Books" page.

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.4 Structured Property Values

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 simple string value. However, suppose we wanted to record 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 string, as in the N-Triple

<http://www.example.org/staffid/85740> 
<http://www.example.org/terms/address>
"1501 Grant Avenue, Bedford, Massachusetts 01730" .

However, suppose we wanted to use RDF to record the various pieces of information about his address as separate street, city, state, and Zip code values. How do we do this?

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 separate resource, and then making separate 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 URI to identify it, say http://www.example.org/addressid/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 below:

Figure 4: Breaking Up John's Address (SVG version)

or the N-Triples:

<http://www.example.org/staffid/85740> 
<http://www.example.org/terms/address> 
<http://www.example.org/addressid/85740> .

<http://www.example.org/addressid/85740> 
<http://www.example.org/terms/street> 
"1501 Grant Avenue" .

<http://www.example.org/addressid/85740> 
<http://www.example.org/terms/city> 
"Bedford" .

<http://www.example.org/addressid/85740> 
<http://www.example.org/terms/state> 
"Massachusetts" .

<http://www.example.org/addressid/85740> 
<http://www.example.org/terms/Zip> 
"01730" .

In the drawing of the graph above, the new URI we assigned to identify "John Smith's address" really serves no purpose, since we could just as easily have drawn the graph:

Figure 5: Using a Blank Node (SVG version)

In this drawing, 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, functions perfectly well in the drawing without needing a URI. However, we do need some form of explicit identifier for that node in order to represent this graph as N-Triples. To see this, we can try to write the N-Triples corresponding to what is shown in the drawn graph. What we would get would be something like:

<http://www.example.org/staffid/85740> 
<http://www.example.org/terms/address> 
??? .

??? 
<http://www.example.org/terms/street> 
"1501 Grant Avenue" .

??? 
<http://www.example.org/terms/city> 
"Bedford" .

??? 
<http://www.example.org/terms/state> 
"Massachusetts" .

??? 
<http://www.example.org/terms/Zip> 
"01730" .

where ??? stands for something that indicates the presence of the blank node. Since in a complex graph there might be more than one such blank node, we also need a way to differentiate between the various blank nodes in the corresponding N-Triples representation. To do this, the N-Triples notation uses a concept of node identifiers to identify blank nodes. These are temporary identifiers distinct from URIs (and having their own syntax in N-Triples) that are used to indicate the presence of blank nodes in the N-Triples representation. In this example, we might generate the node identifier _:johnaddress to refer to the blank node, in which case the resulting N-Triples might be:

<http://www.example.org/staffid/85740> 
<http://www.example.org/terms/address> 
_:johnaddress .

_:johnaddress 
<http://www.example.org/terms/street> 
"1501 Grant Avenue" .

_:johnaddress 
<http://www.example.org/terms/city> 
"Bedford" .

_:johnaddress 
<http://www.example.org/terms/state> 
"Massachusetts" .

_:johnaddress 
<http://www.example.org/terms/Zip> 
"01730" .

This is all there is to basic RDF: nodes-and-arcs diagrams interpreted as statements about concepts or digital resources represented by URIs . However, the need for standardized vocabularies for things like the properties "city" and "creator" is evident. The basis for such vocabularies in RDF is RDF Schema , which will be described in Section 4 . Additional discussion of the basic ideas underlying the RDF data model, and its role in providing a general language for describing Web information, can be found in [WEBDATA ].

@@The intro to the idea of standardized vocabularies could be amplified a little.@@

@@Need to point out that blank nodes have only local scope, unlike URIs@@

@@Add an example showing a blank node as representing a Person without an assigned URI, but having local identifiers assigned to it as property values.@@

3. An XML Syntax for RDF

To summarize what we've said already, RDF models statements in terms of a graph consisting of nodes and arcs. The nodes describe resources that can be labeled with URIs, string literals or are blank. The arcs connect the nodes and are all labeled with URIs. This graph is more precisely called a directed edge-labeled graph; each edge is an arc with a direction (an arrow) connecting two nodes. These edges can also be described as triples of subject node , at the blunt end of the arrow/arc, property arc and an object node at the sharp end of the arrow/arc. The property arc is interpreted as an attribute, relationship or predicate of the resource, with a value given by the object node content.

RDF also defines an XML syntax for writing down and exchanging RDF graphs. This syntax is defined in the RDF/XML Syntax Specification ([RDFXML]). In order to encode the graph in XML, the nodes and arcs are turned into XML elements, attributes, element content and attribute values. The URI labels for properties and object nodes are written in XML using XML Namespaces ([XML-NS]) which gives a namespace URI for a short prefix along with namespace-qualified elements and attributes names called local names. The (namespace URI, local name) pair are chosen such that concatenating them forms the original node URI. The URIs labeling subject nodes are stored in XML attribute values. The nodes labeled by string literals (which are always object nodes) become element text content or attribute values.

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 statement, after assigning a URI to the creation-date property, is:

Figure 6: A Simple RDF Statement (SVG version)

with an N-Triple representation of:

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

Corresponding RDF/XML syntax for this would be:

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

4.   <rdf:Description rdf:about="http://www.example.org/index.html">
5.       <ex:creation-date>August 16, 1999</ex: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.

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 namespace name (a URI) http://www.w3.org/1999/02/22-rdf-syntax-ns#. This namespace is the source for the RDF-specific terms used in RDF/XML.

@@Not a URI with #; need to deal with this URI reference business@@

Line 3 specifies another XML namespace declaration, this time for the prefix ex:. This is expressed as another xmlns attribute of the rdf:RDF element, and specifies that the namespace name http://www.example.org/terms/ is to be associated with the ex: 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.

Line 4 begins the RDF/XML for the specific statement we're representing. An obvious way to talk about this RDF statement is to say it's a description, and that it's about http://www.example.org/index.html. This is exactly the way the RDF/XML represents the statement. The rdf:Description element in Line 4 indicates that we're starting a description, and goes on to define the resource the statement is about (the subject of the statement) using the rdf:about attribute to specify the URI of the subject resource. The <ex:creation-date> element in Line 5 holds the value August 19, 1999 of the creation-date property of the statement. It is nested within the preceding rdf:Description element, indicating that this property applies to the resource specified in the containing rdf:Description element. An RDF processor would form the complete URI of the creation-date property by converting the ex: prefix to the namespace URI defined for it in Line 3, and appending creation-date to it.

Finally, Lines 6 and 7 indicate the ends of the rdf:Description and rdf:RDF elements, respectively.

The RDF/XML syntax provides several 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. To handle this case, RDF/XML allows multiple child elements representing those properties to be nested within the rdf:Description element identifying the subject resource. For example, if we wanted to represent our previous collection of statements about http://www.example.org/index.html:

<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" .

whose graph (the same as Figure 2) is:

Figure 7: Several Statements About the Same Resource (SVG version)

the RDF/XML syntax for this would be:

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:ex="http://www.example.org/terms/">

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

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

Compared with the previous example, we've added an additional namespace declaration (in Line 3), and two additional elements defining properties (in Lines 7 and 8). The ex:language element in Line 7 is similar to the ex:creation-date element we defined earlier. Both these elements represent properties with strings as property values, and such elements are specified by enclosing the string value within start- and end-tags corresponding to the property name. The dc:creator element on Line 8 illustrates the syntax used when the property value is another (existing) resource, rather than a string. In this case, the property is represented by what XML calls an empty element (it has no end tag), and the property value is defined by an rdf:resource attribute within that empty element. The rdf:resource attribute indicates that its value is another resource, identified by its URI. This element also uses a different namespace prefix, the new namespace prefix dc: we defined in Line 3.

So far, we've been describing resources that have been defined (and given URIs) already. For instance, in our initial examples, we've been providing descriptive information about example.org's web page, whose URI was http://www.example.org/index.html. We referred to this resource (defined elsewhere) using an rdf:about attribute. However, obviously we also want to be able to define new resources. For example, suppose a company, example.com, wanted to provide an RDF-based catalog of its products as an RDF/XML document, identified by http://www.example.com/2002/04/products. Within that resource, each product might be given a separate RDF description. An example of one of these descriptions (the catalog entry for a tent) might be:

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

4.     <rdf:Description rdf:ID="10245">
5.          <ex:product>tent</ex:product>
6.          <ex:model>Overnighter</ex:model>
7.          <ex:sleeps>2</ex:sleeps>
8.          <ex:weightInKg>2.4</ex:weightInKg>
9.          <ex:packedSize>14x56</ex:packedSize>
10.    </rdf:Description>
11.  </rdf:RDF>

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

This 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 describing a new resource, identified by the value of the rdf:ID attribute ("10245" in this case, which might be the catalog number used by example.com), rather than referring to an existing resource defined somewhere else. The rdf:ID attribute is somewhat similar to the ID attribute in XML and HTML, in that it defines a label which can be used to refer to this new resource. This label must be unique within the resource (in this case, the catalog) in which it is defined. Any other RDF within this catalog could refer to this new resource (this particular catalog entry) using the relative URI #10245. This would be understood to refer to another resource defined within the catalog.

RDF located outside the catalog could refer to this catalog entry by concatenating the relative URI #10245 of the catalog entry to the base URI of the catalog, forming the absolute URI http://www.example.com/2002/04/products#10245. 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 we described earlier might then be represented on exampleRatings.com's web site as:

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#10245">
5.         <sportex:ratingBy>Richard Roe</sportex:ratingBy>
6.         <sportex:numberStars>5</sportex:numberStars>
7.    </rdf:Description>
8.  </rdf:RDF>

In this example, line 4 uses an rdf:Description element with an rdf:about attribute, since it is referring to a resource defined somewhere else. The value of this attribute is the URI of the tent's catalog entry, defined in the earlier RDF description. The use of this URI allows the tent being referred to in the rating to be precisely identified.

This example not only shows how new resources can be defined in RDF/XML; it also illustrates 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 example also illustrates the fact 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 examples like this one, in which one organization is rating or commenting on resources defined by another, but also for situations in which the original creator 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 original document in which the resource was defined, 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 an rdf:Description element that refers to the original resource using rdf:about.

The RDF/XML syntax has many other capabilities. For example, the figure below (from the RDF/XML Syntax Specification) 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 8: Graph for Another RDF/XML Example (SVG version)

In this case, the graph contains a blank node representing the editor (who apparently has not been given a URI). Some RDF/XML corresponding to this graph is:

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:ex="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.       <ex:editor rdf:parseType="Resource">
8.         <ex:fullName>Dave Beckett</ex:fullName>
9.         <ex:homePage rdf:resource="http://purl.org/net/dajobe/" />
10.      </ex:editor>
11.    </rdf:Description>
12. </rdf:RDF>

Much of this XML is similar to what we have seen before. What is new is in lines 7-10, which specify the blank node, and its properties and their values. Line 7 starts with ex:editor, indicating that it is defining the ex:editor property of the containing rdf:Description element (in Line 5). However, it uses an attribute rdf:parseType="Resource to indicate that it is defining a new resource as the value of the ex:editor property. This resource is not given a name (there is no ID attribute), so it corresponds to a blank node. Within the ex:editor start and end tags (on lines 7 and 10), lines 8 and 9 define the ex:fullName and ex:homePage properties of this new resource, respectively. The end tag </ex:editor> on line 10 indicates the end of the information provided about this new resource.

These examples have illustrated some of the basic ideas behind the RDF/XML syntax. For a discussion of the basic principles behind the modeling of RDF statements in XML (known as striping), and other abbreviations that can be used when writing RDF in XML, refer to the RDF/XML Syntax Specification.

4. Defining RDF Vocabularies: RDF Schema

RDF defines a simple data model for describing the properties of resources, and interrelationships among resources, in terms of named properties and values. However, RDF user communities also require the ability to specify that they are describing certain types or classes of resources, and which specific properties will be used to describe each of those types or classes. For example, the company example.com from our examples in Section 3 would want to define classes such as Tent, and properties such as model, weightInKg, and packedSize to describe them. Similarly, people interested in describing bibliographic resources would want to define classes such as Book or MagazineArticle, and describe them using properties such as author, title, and subject. Other applications might require defining classes such as Person and Company, and properties such as age, jobTitle, stockSymbol, and numberOfEmployees. The RDF data model itself provides no mechanisms for specifying these things. Instead, such classes and properties are defined in an RDF schema . The facilities for defining RDF schemas are specified in the RDF Schema Specification [RDFSCHEMA].

The RDF Schema specification does not specify a specific vocabulary of classes like Tent or Book, and properties like weightInKg or author. Instead, it specifies the mechanisms needed to define such classes and properties, and to control which classes and properties are used together (for example, you probably wouldn't want the property jobTitle to be used in the description of a Tent). In other words, the RDF Schema mechanism provides a basic type system for use in RDF models. The RDF Schema type system is somewhat similar to the type systems of object-oriented programming languages such as Java. For example, the RDF Schema type system allows resources to be defined as instances of one or more classes. In addition, it allows classes to be organized in a hierarchical fashion; for example a class Dog might be defined as a subclass of Mammal which is a subclass of Animal, meaning that any resource which is in class Dog is also considered to be in class Animal.

The RDF Schema specification uses the RDF data model itself to define the RDF type system, by providing a set of pre-defined RDF resources and properties that can be used to define user-specific classes and properties. These pre-defined RDF Schema resources effectively define the RDF Schema vocabulary, and become part of the RDF model of any description that uses them. We will illustrate these basic resources and properties in the following sections.

4.1. Defining Classes

A class in RDF Schema corresponds to the generic concept of a Type or Category, similar to the notion of a class in object-oriented programming languages such as Java. RDF classes can be defined to represent almost anything, such as Web pages, people, document types, databases or abstract concepts. Classes are defined using the pre-defined resources rdfs:Class and rdfs:Resource, and the pre-defined properties rdf:type and rdfs:subClassOf.

First of all, all things described in RDF are called resources, and are considered to be instances of the pre-defined class rdfs:Resource. As a result, rdfs:Resource is the most basic class in the RDF Schema type system.

The property rdf:type is used to indicate that a resource is a member of a class, and thus has all the characteristics that are to be expected of a member of that class. When a resource has an rdf:type property whose value is some specific class, we say that the resource is an instance of the specified class. The value of an rdf:type property for some resource is always another resource which is a class.

A class is a resource whose rdf:type property has a value which is the pre-defined resource rdfs:class. So a new class, such as MotorVehicle, is defined by creating an RDF resource to represent the new class, and giving it an rdf:type property whose value is the pre-defined resource rdfs:Class.

The resource rdfs:Class itself has an rdf:type of rdfs:Class. Individual classes (for example, MotorVehicle) will always have an rdf:type property whose value is rdfs:Class (or some subclass of rdfs:Class, as described below). A resource may be an instance of more than one class.

A subset/superset relation between classes is defined using the pre-defined rdfs:subClassOf property. The rdfs:subClassOf property is transitive. This means that if class A is a subclass of some broader class B, and B is a subclass of C, then A is also implicitly a subclass of C. Consequently, resources that are instances of class A will also be instances of C, since A is a sub-set of both B and C. Only instances of rdfs:Class can have the rdfs:subClassOf property, and the property value is always a resource whose rdf:type is rdfs:Class. A class may be a subclass of more than one class.

The following example defines a simple class hierarchy. We first define a class MotorVehicle. We then define three subclasses of MotorVehicle, namely PassengerVehicle, Truck and Van. We then define a class Minivan which is a subclass of both Van and PassengerVehicle.

Figure 9: A Simple Class Hierarchy (SVG version)

Some corresponding RDF/XML syntax, defining the new classes using the techniques for creating new resources described in Section 3, is shown below. Note the use of rdf:ID to assign names (relative URIs), such as MotorVehicle, to the new resources (classes in this case), which are then referred to in other class definitions within the same schema.

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

<!-- Note: this RDF schema would typically be used in RDF instance data     
by referencing it with an XML namespace declaration, for example    
xmlns:xyz="http://www.w3.org/2000/03/example/vehicles#".  This allows    
us to use abbreviations such as xyz:MotorVehicle to refer    
unambiguously to the RDF class 'MotorVehicle'. -->

<rdf:Description rdf:ID="MotorVehicle">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource"/>
</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>

<rdf:RDF xml:lang="en"
  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="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="http://www.w3.org/2000/03/example/classes#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/2000/03/example/classes#Number"/>
</rdf:Description>

</rdf:RDF>

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

    <rdf:Description rdf:ID="johnSmithsCar">
         <rdf:type rdf:resource="#PassengerVehicle"/>
         <xyz:registeredTo rdf:resource="http://www.example.org/staffid/85740"/>
         <xyz:rearSeatLegRoom>127</xyz:rearSeatLegRoom>
    </rdf:Description>
  </rdf:RDF>

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

    <xyz:PassengerVehicle rdf:ID="johnSmithsCar">
         <xyz:registeredTo rdf:resource="http://www.example.org/staffid/85740"/>
         <xyz:rearSeatLegRoom>127</xyz:rearSeatLegRoom>
    </xyz:PassengerVehicle>
  </rdf:RDF>

<rdf:RDF xml:lang="en"
  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="biologicalParent">
  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
</rdf:Description>

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

</rdf:RDF>

5. RDF Containers

There is often a need to represent collections 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 container types that can be used to do this.

A Bag (type rdf:Bag) is an unordered collection of resources or literals. A Bag is used to represent a collection that has multiple values, and there is no significance to the order in which the values are given. For example, a Bag might be used to represent a collection of part numbers in which the order of entry or processing of the part numbers does not matter. A Bag can contain duplicate values.

A Sequence (type rdf:Seq) is an ordered collection of resources or literals. A Sequence is used to represent a collection that has multiple values, and the order of the values is significant. For example, a Sequence might be used to represent a collection that must be maintained in alpabetical order. A Sequence can contain duplicate values.

An Alternative (type rdf:Alt) is a collection of resources or literals that represent alternative values (typically for a single value of a property). For example, an Alternative might be used to specify alternative language translations for the title of a book, or to provide a list of alternative Internet sites at which a resource might be found. An application using a property whose value is an Alternative collection should be aware that it can choose any one of the items in the collection as appropriate.

To represent a specific instance of one of these types of collections, you create a new resource, and give it an rdf:type property whose value is one of the pre-defined resources rdf:Bag, rdf:Seq, or rdf:Alt (whichever is appropriate). This new container resource represents the collection as a whole, and may either be a blank node or be given a URI. The members of the collection are then indicated by defining a membership property for each member that has the new container resource as its subject and the member resource as its object. These membership properties have the names rdf:_1, rdf_2, rdf_3, and so on, and are used specifically for defining the members of containers. Container resources may also have other properties that describe the container, in addition to the membership properties and the rdf:type property.

A typical use of a container is to represent the value of a property. For example, to represent the sentence "The students in course 6.001 are Amy, Tim, John, Mary, and Sue", the RDF graph might be:

Figure 10: A Simple Bag Container (SVG version)

This can be written in RDF/XML as:

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

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

Since the value of the s:students property is expressed as a Bag, there is no significance in the order given for the URIs of each student.

Note that the RDF/XML uses li as a convenience element to avoid having to explicitly number each membership property. The RDF processor will generate the numbered properties rdf:_1, rdf:_2, and so on from the li elements as necessary. The element name li was chosen to be mnemonic with the term "list item" from HTML.

As an illustration of an Alternative container, the sentence "The source code for X11 may be found at ftp.x.org, ftp.example.org, or ftp.example2.org" would have an RDF graph:

Figure 11: A Simple Alternative Container (SVG version)

This can be written in RDF/XML as:

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

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

In this case, the value of the s:DistributionSite site property is considered to be one of the members of the Alternative container, any one of which would be an acceptable value. An Alternative container is required to have at least one member. This member is identified by the property rdf:_1, and is intended to be considered to be the default or preferred value.

Alternative 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 Alternative container holding each of the language variants.

The examples above illustrate that the general structures of the RDF graphs for both Bags and Alternatives are the same (and they are also the same for Sequences); only the indicated rdf:type is different. RDF considers these types as essentially "hints" to a processing application on how to properly interpret the structures. This is because RDF processors are not in a position to control how an application actually uses these structures. For example, an RDF processor has no way to force an application to use the first member of an Alternative collection as a default value. Similarly, an RDF processor has no way to force an application to ignore order in processing a Bag.

RDF processors are also limited in their ability to enforce structural constraints on these collections. For example, these structures explicitly permit duplicate values. RDF does not define a Set container, which would be a Bag with no duplicates, because RDF processors are not necessarily in a position to enforce a no-duplicates constraint (for example, a duplicate might exist somewhere else on the web, unknown to the processor). Also, if you create the membership properties yourself, RDF does not insist that the property numbers be contiguous starting with rdf:_1. For example, you could create a legal Bag with just the membership properties rdf:_3, rdf:_7, rdf:_8, and rdf:_11 (although an RDF processor would not generate these property names from a collection of rdf:li properties).

Users are also free to choose their own representations for collections, rather than using the ones described here. These RDF collections are merely provided as common definitions that, if generally used, would help make data involving collections more interoperable.

@@We've omitted the discussion from the M&S about the use of container objects vs. multiple statements with the same predicate, since the examples were rather forced.@@

6. Some RDF Applications: RDF in the Field

<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>

<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>

<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>

<?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>

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

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

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

<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>

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

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

<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>

<?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>

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

    (description of individual resources go here)

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

    <!--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>

    <!--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>