RDF Primer

2.1 Uniform Resource Identifiers (URIs)

If we want to discuss something, we must first identify it. How else will we know what we are referring to? In everyday communication, we use references such as "Bob", "The Moon", "373 Whitaker Ave.", "California", "VIN 2745534", "today's weather", etc., to identify things. Ambiguities in these identifiers are generally resolved in terms of a shared semantic context between the sender and the receiver. To refer to "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 character 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 network locations or URLs. For example, I (a human being) don't have a network location or 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), inoculations 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 a recognized 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). The URLs we've already discussed 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 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. A number of different URI schemes (URI forms) have been already been developed, and are being used, for various purposes. Examples include:

• http: (Hypertext Transfer Protocol, primarily for Web pages)
• mailto: (email addresses), e.g., mailto:em@w3.org
• ftp: (File Transfer Protocol)
• urn: (Uniform Resource Names, intended to be persistent location-independent resource identifiers), e.g., urn:isbn:0-520-02356-0 (for a book)

URIs are defined in RFC 2396 [URI]. Some additional discussion of URIs can be found in Naming and Addressing: URIs, URLs, ... [NAMEADDRESS]. A list of existing URI schemes can be found in Addressing Schemes [ADDRESS-SCHEMES], and it is a good idea to consider adapting one of the existing schemes for any specialized identification purposes you may have, rather than trying to invent a new one.

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. Also, you can create URIs for things you don't own, just as in ordinary language you can use whatever name you like for things you don't own. 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 the basis of its mechanism for identifying the subjects, predicates, and objects in statements. To be more precise, RDF uses URI references [URI] to define its subjects, predicates, and objects. 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, and hence using URIrefs allows RDF to describe practically anything, and to state relationships between such things as well.

While both RDF and web browsers use URIrefs to identify things, RDF and browsers interpret URIrefs in slightly different ways. This is because RDF uses URIrefs only to identify things, while browsers also use URIrefs to retrieve things. Often there is no effective difference, but in some cases the difference can be significant. One obvious difference is when a URIref is used in a browser, there is the expectation that it identifies a resource that can actually be retrieved: that something is actually "at" the location identified by the URI. However, In RDF a URIref may be used to identify something, like a person, that has no physical existence on the web, and hence can't be retrieved. People sometimes use RDF together with a convention that, when a URIref is used to identify an RDF resource, a page containing descriptive information about that resource will be placed on the web "at" that URI, so that the URIref can be used in a browser to retrieve that information. This can be a useful convention in some circumstances (although it creates a difficulty in distinguishing the identity of the original resource from the identity of the web page describing it). However, this convention is not an explicit part of the definition of RDF, and RDF itself does not assume that a URIref identifies something that can be retrieved.

Another difference is in the way URIrefs with fragment identifiers are handled. Fragment identifiers are often seen in URLs that identify HTML documents, where they serve to identify a specific place within the document identified by the URL. In normal HTML usage, where URI references are used to retrieve the indicated resources, the two URI references:

http://www.example.org/index.html
http://www.example.org/index.html#Section2

In later sections, we'll see how RDF uses URIrefs for identifying the subjects, predicates, and objects in statements. But before we do that, we need to briefly introduce, in the next section, the basis of how RDF statements are physically represented and exchanged.

2.2 Documents: Extensible Markup Language (XML)

The Extensible Markup Language [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 convey meaning 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 passage, for example:

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

To a machine, this passage has the exact same structure as the previous example. However, it is no longer clear to an English-speaker what is being said, because the tags are no longer English words. Moreover, others may have used the same words as tags 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 [XML-NS]. 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 with identical spellings 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. The following example illustrates the use of an XML 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>

In this example, xmlns:my="http://example.org/xml/documents/ declares a namespace for use in this piece of XML. It maps the prefix my to the namespace URI http://example.org/xml/documents/. The XML content can then use qualified names (or QNames) like my:person as tags. A QName contains a prefix that identifies a namespace, followed by a colon, and then a local name for an XML tag (element) or attribute. By using namespace URIs to distinguish specific collections of names, and qualifying tags with the URIs of the namespaces they come from, as in this example, we don't have to worry about tag names conflicting. Two tags having the same spelling are considered the same only if they also have the same namespace URIs.

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

In RDF/XML, XML QName tags are used with namespace URIs to provide URIrefs for the names used in RDF. This is done by concatenating the namespace URI and the local (tag) name. For example, if the XML namespace assigned to prefix foo has the URI http://example.org/somewhere/, then the tag foo:bar would correspond to the RDF resource with URIref http://example.org/somewhere/bar. Similarly, in the previous example, the my:person tag would have the namespace URI http://example.org/xml/documents/ concatenated with local name person, giving it the URIref http://example.org/xml/documents/person. This simple method restricts the URIrefs that can be generated from the XML, and allows the same URIref to be constructed in multiple ways, but if care is taken, it works satisfactorily.

2.3 The RDF Model

Now that we've introduced URI references 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, 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. 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 1:

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, by introducing suitable URIrefs to name the properties "creation-date" and "language", use the graph shown in Figure 2:

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

Figure 2 illustrates that RDF permits the objects of statements (but not the subjects or predicates) to be either URIrefs or simple character strings, in order to represent certain kinds of property values. In drawing RDF graphs, nodes that represent resources identified by URIrefs are shown as ellipses, while nodes that represent character strings are shown as boxes (labeled by the character strings themselves). 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 node labels (either URIref or character string), 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 (but like the original statements), 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. However, the triples represent exactly the same information as the graph.

The N-triples syntax requires that URI references be written out in full, 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 QName without angle brackets as an abbreviation of a full URI reference. We will also make extensive use in these examples of several "well-known" QName prefixes (which we will use without explicitly specifying them), 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/

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:

<http://www.example.org/index.html> dc:creator exstaff:85740 .

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

<http://www.example.org/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 having "John Smith" as their name, 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 3:

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

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

<http://www.example.org/index.html>  dc:creator  exstaff:85740 .

the predicate dc: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.

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 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 information (the list of book rating averages) and create a "Top Ten Highest Rated Books" page. The availability and use of a shared vocabulary about ratings allows individuals to build a mutually-understood and increasingly-powerful "information base" about books 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. This relationship is further explored in Section 8.

2.4 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 simple character string. 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 character string, as in the triple

exstaff:85740  exterms: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 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 4:

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

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, concepts that may never need to be referred to directly from outside a particular graph, and thus don't, strictly speaking, require "universal" identifiers. In addition, in order to draw the graph representing the collection of statements shown in Figure 4, we don'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 5:

Figure 5: Using a Blank Node (SVG version)

In Figure 5, 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 URIref, since the node itself provides the necessary connectivity between the various other parts of the graph. However, we do need some form of explicit identifier for that node if we are going to represent this graph as triples. To see this, we can try to write the triples corresponding to what is shown in the drawn graph. 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 also need a way to differentiate between the various blank nodes in the corresponding triples representation of the graph. To do this, the triples notation uses a node identifier, having the form _:name, to indicate the presence of a blank node. For instance, in this example we might generate the 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 node identifier. Unlike URIrefs and character string literals, 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 5 and noting that there is no node identifier used to label the blank node). Node identifiers only have significance within the triple representation of the graph, and only for the purpose of distinguishing one blank node from another (so that two collections of triples that differ only by re-naming their node identifiers are considered to represent identical RDF graphs). Node identifiers also have significance only within the triples representing a single graph (so that two different graphs with the same number of blank nodes might use the same node identifiers to distinguish them, and it would be unwise to assume that blank nodes from different graphs having the same node identifiers referred to the same resource). 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.

@@Might want to say something at this point about the relationship of a "graph" with a "document".@@

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 separate resource, and then making separate 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 his address. When we try to deal with an address as an aggregate of (street, city, state, zip), we are effectly dealing with an n-ary (n-way) relationship (in this case, n=4) between the street, city, state, and zip components. In order to represent such structures directly in RDF (e.g., considering the address as a collection of street, city, state, and zip sub-components), we need to break this n-way relationship up into a collection of separate binary relationships.

Blank nodes give us a general way of representing such n-ary relationships using RDF triples. Each time we have an n-ary relationship (such as the address example), we can create a blank node representing an instance of the relationship, and then represent the 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 model resources that may not have URIs, but that are described in terms of relationships with other resources that do have URIs. For example, when representing a person, it may seem natural to use that person's email address as her URI, e.g., mailto:jane@example.org. However, this approach can cause a number of problems. One obvious problem is that Jane's email address may change when she changes jobs, and so it may be hard to combine information about Jane acquired at different times. Another problem is that we may want to record information about Jane's mailbox (e.g., the server it is on) as well as about Jane (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 fundamental problem here is that using Jane's email address as a stand-in for Jane is an inaccurate model: Jane's email address identifies a mailbox, and Jane and her mailbox are not the same thing. 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 emailaddress property having the URIref mailto:jane@example.org as its value. We can also assign the blank node a type property with a value of Person, a name property with a value of "Jane Smith", and any other descriptive information we might want to provide (we will discuss types in more detail in the following sections). This says, accurately, that "there is a resource of type Person whose email address is mailto:jane@example.org, whose name is Jane Smith, etc."

In practice, this doesn't change the way we actually handle this kind of information. 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 relate information from multiple sources. If we were to find another piece of RDF on the web that described a book, and gives the author's contact information as the email address 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 actually a shorthand for "the author of the book is someone whose email address is mailto:jane@example.org". Using a blank node to represent this "someone" simply makes what is actually happening more explicit. Of course, modeling the person and her mailbox as separate resources makes sense even when the person actually has a URI, since we still want to distinguish the person from her mailbox.

@@Note the example of the RDF/XML Syntax document editor in Section 3 has this form too. Might also note that more advanced Schema languages (described later) such as DAML+OIL allow specification of which properties are unique identifiers.@@

This is all there is to basic RDF: nodes-and-arcs diagrams interpreted as statements about concepts or digital resources identified by URIrefs . However, it should be clear that, in addition to the basic techniques for representing RDF statements in diagrams (or triples), we also need a way for people to define the vocabularies they intend to use in those statements, e.g., to define properties like "city" and "creator" (and even types of things like "Person"). The basis for defining 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].

4.1. 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 (a resource having 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 (i.e., repeated) values.

A Sequence (a resource having 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 alphabetical order. A Sequence can contain duplicate values.

An Alternative (a resource having 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.

The distinction between a Bag and an Alternative 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 Alternative more accurately represents the relationship than the Bag (which might suggest there are two different authors).

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 URIref. 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 as shown in Figure 10:

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 URIrefs 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 the RDF graph shown in Figure 11:

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 as the default or preferred value. Other than the member identified as rdf:_1, the order of the remaining elements is not significant.

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 containers are merely provided as common definitions that, if generally used, would help make data involving collections more interoperable.

A resource may have multiple statements with the same predicate (i.e. using the same property). This is not the same as having a single statement whose object is a container containing multiple members. The choice of which to use in a given situation in some cases involves a difference in meaning, while in other cases is a simple choice of representation.

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 ex:publication ex:AnthologyOfTime .
exstaff:Sue ex:publication ex:ZoologicalReasoning .
exstaff:Sue ex: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 true or false independently of the others Hence, using repeated properties is a reasonable choice.

However, the sentence:

The committee of Fred, Wilma, and Dino approved the resolution.

says that the three committee members as a whole voted in a certain manner; 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 the three separate approvedBy statements, one for each committee member, shown below:

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

since this could imply the vote of each individual member.

In this case, it would be better to model the sentence as a single approvedBy statement whose subject is the resolution and whose object is a separate resource representing the entire committee. The resource representing the committee could be a Bag containing the committee members' identities, as in the following:

ex:resolution ex:approvedBy _:z
_:z rdf:type rdf:Bag .
_:z rdf:_1 ex:Fred .
_:z rdf:_2 ex:Wilma .
_:z rdf:_3 ex:Dino .

Alternatively, the resource representing the committee could be a non-Bag resource. This resource might in turn have a members property with the Bag of members as its value, or separate memberOf properties for each member (since each person is independently a member of the committee).

4.2. RDF Reification

@@TBD@@

4.3. Miscellaneous RDF Facilities

@@Organization of this section is in progress.@@

rdf:value

Often the value of a property is something that has additional contextual information that is considered "part of" that value. In other words, there is a need to qualify property values. Examples of such qualification include naming a unit of measure, a particular restricted vocabulary, or some other annotation. For some uses it is appropriate to use the property value without the qualifiers. For example, in the statement "the price of that pencil is 75 U.S. cents" it is often sufficient to say simply "the price of that pencil is 75".

In the RDF model a qualified property value is simply another instance of a structured value. The object of the original statement is this structured value and the qualifiers are further properties of this common resource. The principal value being qualified is given as the value of the rdf:value property of this common resource.

@@second part of description@@

The RDF data model intrinsically only supports binary relations; that is, a statement specifies a relation between two resources. In the following examples we show the recommended way to represent higher arity relations in RDF using just binary relations. The recommended technique is to use an intermediate resource with additional properties of this resource giving the remaining relations. As an example, consider the subject of one of John Smith's recent articles -- library science. We could use the Dewey Decimal Code for library science to categorize that article. Dewey Decimal codes are far from the only subject categorization scheme, so to hold the classification system relation we identify an additional resource that is used as the value of the subject property and annotate this resource with an additional property that identifies the categorization scheme that was used. As specified in Section 2.3., the RDF core includes a rdf:value property to denote the principal value of the main relation. The resulting graph might look like:

@@All these examples, if they stay, need further checking.@@

<http://www.example.org/Jan97> dc:subject         _:category .
_:category                     rdf:value          "020 - Library Science" .
_:category                     ex:classification  "Dewey Decimal Code" .

which could be exchanged as:

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

   <rdf:Description rdf:about="http://www.example.org/Jan97.html">
        <dc:subject
          rdf:value="020 - Library Science"
          ex:classification="Dewey Decimal Code"/>
   </rdf:Description>
 </rdf:RDF>

Note that two namespace declarations exist for the same namespace in this example. This is frequently needed when default namespaces are declared so that attributes that do not come from the namespace of the element may be specified, as is the case with the rdf:value attribute in the dc:subject element above.

@@It's not clear the above is illustrated properly@@

A common use of this higher-arity capability is when dealing with units of measure. A person's weight is not just a number such as "200", it also includes the unit of measure used. In this case we might be using either pounds or kilograms. We could use a relationship with an additional arc to record the fact that John Smith is a rather strapping gentleman:

exstaff:85740  exterms:weight  _:johnweight .
_:johnweight   rdf:value  "200" .
_:johnweight   exterms:units   exunits:Pounds .

which can be exchanged as:

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

   <rdf:Description rdf:about="http://www.example.org/staffid/85740">
      <ex:weight rdf:parseType="Resource">
        <rdf:value>200</rdf:value>
        <ex:units rdf:resource="http://www.example.org/units/Pounds/" />
      </ex:weight>
   </rdf:Description>
 </rdf:RDF>

provided the resource "Pounds" is defined in a example.org schema with the URIref http://www.example.org/units/Pounds/.

Boolean valued properties

RDF does not define the values TRUE and FALSE for use as property values.

Such definitions are not necessary: a similar effect can be achieved by using data types to indicate Boolean attributes of a resource. This is entirely consistent with the way that the formal semantics treats RDF classes.

RDF in HTML

@@This material is here only temporarily. It is intended to place it in Section 3, where it can be used, among other things, to illustrate the use of one of the RDF/XML abbreviation formats.@@

The RDF/XML serialization syntax provides different forms of expression that are equivalent for the purposes of RDF, but which may be handled differently when the RDF is embedded in another document format. Consider the following piece of RDF:

 <rdf:RDF> 
    <rdf:Description rdf:about="http://www.w3.org">
      <ex:publisher>World Wide Web Consortium</ex:publisher>
      <ex:title>W3C Home Page</ex:title>      
      <ex:date>1998-10-03T02:27</ex:date>
    </rdf:Description>
 </rdf:RDF>

which is equivalent for RDF purposes to (using attributes instead of elements):

 <rdf:RDF> 
    <rdf:Description rdf:about="http://www.w3.org"
           ex:publisher="World Wide Web Consortium"
           ex:title="W3C Home Page"      
           ex:date="1998-10-03T02:27"/>
 </rdf:RDF>

While these are equivalent RDF expressions, they may be treated differently by other processing engines. In particular, if these two expressions were embedded into an HTML document then the default behavior of a non-RDF-aware browser would be to display the values of the properties in the first case while in the second case there should be no text displayed (or at most a whitespace character).

5. Defining RDF Vocabularies: RDF Schema

RDF defines a data model for expressing simple statements about resources, using named properties and values. However, RDF user communities also need the ability to indicate that they are describing certain types or classes of resources, and to define specific properties to be used in describing those resources. For example, the company example.com from our examples in Section 3 would want to define classes such as ex:Tent, and properties such as ex:model, ex:weightInKg, and ex:packedSize to describe them (we use QNames with various "example" namespace prefixes as the names of classes and properties here as a reminder that in RDF these names are actually URI references, as discussed in Section 2). Similarly, people interested in describing bibliographic resources would want to define classes such as ex2:Book or ex2:MagazineArticle, and describe them using properties such as ex2:author, ex2:title, and ex2:subject. Other applications might require defining classes such as ex3:Person and ex3:Company, and properties such as ex3:age, ex3:jobTitle, ex3:stockSymbol, and ex3:numberOfEmployees. The RDF data model itself provides no vocabulary for specifying these things. Instead, such classes and properties are defined in an RDF schema . The facilities for defining RDF schemas are specified in RDF Vocabulary Description Language 1.0: RDF Schema [RDFSCHEMA].

RDF Schema does not provide a specific vocabulary of application-oriented classes like ex:Tent, ex2:Book, or ex3:Person, and properties like ex:weightInKg, ex2:author or ex3:JobTitle. Instead, it provides the mechanisms needed to define such classes and properties, and to indicate which classes and properties are expected to be used together (for example, you might expect the property ex3:jobTitle to be used in the description of a ex3:Person). In other words, RDF Schema provides a basic type system for use in RDF models. The RDF Schema type system is similar in some respects to the type systems of object-oriented programming languages such as Java. For example, RDF Schema 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 ex:Dog might be defined as a subclass of ex:Mammal which is a subclass of ex:Animal, meaning that any resource which is in class ex:Dog is also considered to be in class ex:Animal. However, RDF classes and properties are in some respects very different from programming language types. RDF class and property definitions do not create a straightjacket into which information must be forced, but instead provide additional information about the RDF resources they describe. This information can be used in a variety of ways. We will say more about this point in Section 4.3.

RDF Schema uses the RDF data model itself to define the RDF type system, by providing a set of pre-defined RDF resources and properties, together with their meanings, that can be used to define user-specific classes and properties. These additional RDF Schema resources extend RDF to include a larger reserved vocabulary with additional meaning. These resources become part of the RDF model of any description that uses them, and extend the meaning of that description for any processor that understands the extended vocabulary. The RDF Schema (RDFS) vocabulary is defined in a namespace identified by the URI reference http://www.w3.org/2000/01/rdf-schema#" (in the examples, we will use the prefix rdfs: to refer to this namespace). We will illustrate RDF Schema's basic resources and properties in the following sections.

5.1. Defining 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 defined to represent almost anything, such as web pages, people, document types, databases or abstract concepts. Classes are defined using the RDFS-defined resources rdfs:Class and rdfs:Resource, and the properties rdf:type and rdfs:subClassOf.

For example, suppose we wanted to provide information about different kinds of motor vehicles. In RDF Schema, we would first define a class called xyz:MotorVehicle (using xyz: to stand for the namespace we will use in this example). A class represents the collection of resources that belong to the class, called its instances. In this case, we intend the class xyz:MotorVehicle to represent the collection of resources that we intend to represent motor vehicles. As we noted in earlier sections, all things described in RDF are called resources, and all resources are considered to be instances of the RDFS-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 an instance of a class. In our example, if we wanted to define a resource, say xyz:companyCar, to represent a motor vehicle, we would define the resource xyz:companyCar with an rdf:type property whose value is xyz:MotorVehicle. This is an RDF statement that xyz:MotorVehicle is a class, and xyz:companyCar is an instance of that class.

A Class is any resource having an rdf:type property whose value is the RDFS-defined resource rdfs:Class. So a new class, such as xyz:MotorVehicle, is defined by creating an RDF resource to represent the new class, and giving it an rdf:type property whose value is the RDFS-defined resource rdfs:Class. The resource rdfs:Class itself has an rdf:type of rdfs:Class. A resource may be an instance of more than one class.

After defining class xyz:MotorVehicle, we might want to define additional classes representing various specialized kinds of motor vehicle, e.g., passenger vehicles, vans, minivans, and so on. We can define these classes in the same way as we defined class xyz:MotorVehicle, by defining a resource to represent each new class, and giving it an rdf:type property whose value is rdfs:Class. However, we want to do more than just define the separate classes; we also want to indicate their relationship to class xyz: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 define this relationship using the pre-defined rdfs:subClassOf property to relate the two classes. For example, if a resource xyz:Van has an rdfs:subClassOf property whose value is another resource xyz:MotorVehicle, this is an RDF statement that both xyz:Van and xyz:MotorVehicle are classes, and that xyz:Van is a subclass of xyz:MotorVehicle. The meaning of this relationship is that if xyz:Van is a subclass of xyz:MotorVehicle, and resource xyz:mycar is an instance of xyz:Van, then xyz:mycar is also implicitly considered an instance of xyz:Motorvehicle (that is, you can "infer" or act as if xyz:mycar is an instance of xyz:MotorVehicle even if this is not explicitly stated).

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

The example in Figure 9 shows the simple class hierarchy we have been discussing. At the bottom, we show a class MotorVehicle. We then show three subclasses of MotorVehicle, namely PassengerVehicle, Truck and Van, related to class MotorVehicle by rdfs:subClassOf properties. At the top, we show class Minivan, which is a subclass of both Van and PassengerVehicle.

Figure 9: A Simple Class Hierarchy (SVG version)

Some corresponding RDF/XML syntax for this schema, defining the new classes using the techniques for creating new resources described in Section 3, is shown below.

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

This schema uses rdf:ID to assign names, such as MotorVehicle, to the new resources (classes) that it defines. These names are then referred to in other class definitions within the same schema. To refer to this RDF schema in RDF instance data (e.g., data defining individual vehicles of these classes), which might be located elsewhere, the instance data would typically include an XML namespace declaration referencing the schema, for example (assuming that the schema was the resource http://example.org/schemas/vehicles.rdfs), the namespace declaration xmlns:xyz="http://example.org/schemas/vehicles#". This would allow the instance data to use abbreviations such as xyz:MotorVehicle to refer unambiguously to the class MotorVehicle from this RDF Schema. As noted in Section 3, to ensure that these references would be consistently maintained even if the schema were relocated, the schema could also include an explicit xml:base="http://example.org/schemas/vehicles" declaration.

<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="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.example.org/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.example.org/classes#Number"/>
</rdf:Description>

</rdf:RDF>

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

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

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

7. Other Parts of the RDF Specification

@@section intro TBD@@

8. RDF As a Data Model

@@This is currently a placeholder (the title might change too) for a brief discussion of several related topics: (a) how RDF relates to XML (why you might want to use RDF, rather than using other XML structures); (b) where RDF fits in the general world of data models, particularly its relationship to the relational data model, and related work on binary relational and other "semantic" data models. As part of this latter material, there will be pointers to some of the literature on database (schema) design (functional dependencies are highly relevant to RDF design), since analysis and design is going to be needed to develop robust RDF applications, and a lot of prior work exists on this subject that can be drawn from; (c) "identifier design": that deciding how to assign URIrefs to things is a design issue too, and some of the issues involved (e.g., options when different people assign different URIrefs to the same thing). The idea is mainly to point out the issues, and cite some sources for further reading. Depending on how the material turns out, it might be distributed in other sections instead of being placed here.@@

9. References

10. Acknowledgments

This document has benefited from inputs from many members of the RDF Core Working Group. Specific thanks to Dave Beckett, Dan Brickley, Ronald Daniel, Martyn Horner, Graham Klyne, Sean Palmer, Patrick Stickler, Aaron Swartz, Ralph Swick, and Garret Wilson, who provided valuable contributions to this document.

Appendix A: Changes

Changes since the 26 April 2002 Working Draft:

• Added Appendix A.
• Miscellaneous formatting corrections.
• Introduced an abbreviated notation for triples and corrected the examples.
• Divided References into Normative and Informational References, added references, and corrected format.
• Added additional material on URIs and discussion about fragment identifiers.
• Changed many references from "URI" to "URIref" to clarify the distinction made in the above material.
• Corrected material on rdf:ID and rdf:about, and on parseType="Resource", in Section 3, and added material on xml:base.
• Corrected material on RDF capabilities in the Abstract and Section 1.
• Introduced a new section to hold containers, reification, and miscellaneous capabilities, and added material on rdf:value, Boolean values, and (temporarily) RDF in HTML to that section.
• Rewrote the RDF Schema material to emphasize its descriptive role, and to include how xml:base might be used, and changed its placement.
• Added an example illustrating the use of blank nodes to model things that don't naturally have URIs.