RDF Primer

2.1 Basic Concepts

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

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

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

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

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

We could state other Other properties of this Web page could be described 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, deleted text: to specify the date the page was created, and the language in which the page is written, deleted text: we could write be described using the additional statements:

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

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

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

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

• the subject is the URL <tt> http://www.example.org/index.html </tt>
• the predicate is the word "creator"
• the object is the phrase "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, deleted text: we need two things: things are needed:

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

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

As we've seen, illustrated earlier, the Web already provides one form of identifier, the Uniform Resource Locator (URL). We used a A URL was used in our the 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 it is also like important to be able to record information about many things that, unlike Web pages, don't do not have network locations or URLs.

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

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

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

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

2.2 The RDF Model

Now that we've Section 2.1 has introduced RDF's basic statement concepts, the idea of using URI references deleted text: for identifying things we want to talk about on identify the Web, things referred to in RDF statements, and RDF/XML as a machine-processable way of representing to represent RDF statements, we can describe statements. With that background, this section describes how RDF lets us use uses URIs to make statements about resources. In the introduction, we The introduction said that RDF was based on the idea of expressing simple statements about resources, where those statements are built using subjects, predicates, each statement consists of a subject, a predicate, and objects. an object. In RDF, we could represent our original the English statement:

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

could be represented by an RDF statement having:

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

Note how deleted text: we have used URIrefs are used 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 respectively (some of the effects of using URIrefs in this further way will be discussed later in this section. section).

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

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

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

Figure 2: A Simple RDF Statement

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

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

we could, by using suitable URIrefs to name in the properties "creation-date" and "language", use RDF graph, the graph shown in Figure 3 </a>: could be used (using suitable URIrefs to name the properties "creation-date" and "language"):

Figure 3: Several Statements About the Same Resource

Figure 3 illustrates that deleted text: the objects of in RDF statements may be either deleted text: resources identified by URIrefs, or constant values (called literals ) represented by character strings, in order to represent certain kinds of property values. Literals may not be the used as subjects or predicates of in RDF statements. In drawing RDF graphs, nodes that are URIrefs are shown as ellipses, while nodes that are literals are shown as boxes. (The simple character string literals we will use for now used in these examples are called plain literals , to distinguish them from the typed literals we will introduce to be introduced in Section 2.4 . The various kinds of literals that can be used in RDF statements are defined in [RDF-CONCEPTS] .) In drawing RDF graphs, nodes that represent resources identified by URIrefs are shown as ellipses, while nodes that represent literals are shown as boxes (labeled by the literal itself). .

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

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



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



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

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

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

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

We will also use Obvious variations on the "example" prefix <tt> ex: </tt> will also be used as needed in the examples, deleted text: where this will not cause confusion, for example, instance,

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

Using our this new shorthand, deleted text: we can write the previous set of triples can be written as:

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



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







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



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







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



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

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



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



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

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

Figure 4: More Information About John Smith

These examples also illustrate that RDF uses URIrefs as predicates in RDF statements. That is, rather than using character strings (or words) such as "creator" or "name" to identify properties, RDF uses URIrefs. Using URIrefs to identify properties is important for a number of reasons. First, it allows us to distinguish distinguishes the properties we one person may use from different properties someone else may use that would otherwise be identified by the same character string. For instance, in our example, the example in Figure 4 , example.org uses "name" to mean someone's full name written out as a character string literal (e.g., "John Smith"), but someone else may intend "name" to mean something different (e.g., the name of a variable in a piece of program text). A program encountering "name" as a property identifier on the Web wouldn't (or merging data from multiple sources) would not necessarily be able to distinguish these uses. However, if example.org writes <tt> http://www.example.org/terms/name </tt> for its "name" property, and the other person writes <tt> http://www.domain2.example.org/genealogy/terms/name </tt> for hers, we can keep straight the fact it is clear that there are distinct properties involved (even if a program cannot automatically determine the distinct meanings). Another reason why it is important to use Also, using URIrefs to identify properties is that it allows us to treat RDF enables the properties to be treated as resources themselves. Since properties are resources, we can record descriptive additional information can be recorded 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 supports the development and use of a shared vocabulary on the Web, since people can discover and begin using vocabularies already used by others to describe things, reflecting deleted text: (and creating) a shared understanding of the concepts we talk about. those concepts. For example, in the triple

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



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

the predicate <tt> dc:creator </tt>, , when fully expanded as a URIref, is an unambiguous reference to the "creator" attribute in the Dublin Core metadata attribute set (discussed further in Section 6.1 ), a widely-used set of attributes (properties) for describing information of all kinds. The writer of this triple is effectively saying that the relationship between the Web page (identified by <tt> http://www.example.org/index.html </tt> ) and the creator of the page (a distinct person, identified by <tt> http://www.example.org/staffid/85740 </tt> ) is exactly the concept identified by <tt> http://purl.org/dc/elements/1.1/creator </tt> . Moreover, anyone else, . Another person familiar with the Dublin Core vocabulary, or any program, that understands <tt> http://purl.org/dc/elements/1.1/creator </tt> who finds out what dc:creator means (say by looking up its definition on the Web) will know deleted text: exactly what is meant by this relationship. In addition, based on this understanding, people can write programs to behave in accordance with that meaning when processing triples containing the predicate dc:creator .

Of course, this depends on increasing the general use of URIrefs to refer to things instead of using literals; e.g., using URIrefs like exstaff:85740 and dc:creator instead of character string literals like John Smith and creator . Even then, RDF's use of URIrefs doesn't does not solve all our identification problems because, for example, people can still use different URIrefs to refer to the same thing. However, the fact that these different URIrefs are used in the commonly-accessible "Web space" creates the opportunity both to identify equivalences among these different references, and to migrate toward the use of common references.

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

fy:joefy.iunm  ed:dsfbups  fytubgg:85740 .

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 cannot actually "understand" such statements, of course, but as noted above, any more than a database system "understands" terms like "employee" or "salary" in processing a query like SELECT NAME FROM EMPLOYEE WHERE SALARY > 35000 . However, if an application is appropriately written, it can deal with them RDF statements in a way that makes it seem like it does. does understand them, just as a database system and its applications can do useful work in processing employee and payroll information without understanding "employee" and "payroll". 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 Web site could take that list of book rating averages and create a "Top Ten Highest Rated Books" page. Here, the availability and use of a shared vocabulary about ratings, and a shared group of URIrefs identifying the books they apply to, allows individuals to build a mutually-understood and increasingly-powerful (as additional contributions are made) "information base" about books on the Web. The same principle applies to the vast amounts of information that people create about thousands of subjects every day on the Web.

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

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

and information in these formats can be treated as RDF statements, allowing RDF to be used to integrate data from many sources.

2.3 Structured Property Values and Blank Nodes

Things would be very simple if the only types of information deleted text: we had to record be recorded about things were obviously in the form of the simple RDF statements deleted text: 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 the original example, deleted text: we recorded the date the Web page was created is recorded as a single <tt> exterms:creation-date </tt> property, with a plain literal as its value. However, suppose deleted text: we wanted to show, as the value of the <tt> exterms:creation-date </tt> property, property needed 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 John's address was being described. The whole address could be written out as a plain literal, as in the triple

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



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

However, suppose deleted text: we wanted to record John's address needed to be recorded as a structure consisting of separate street, city, state, and Zip postal code values? How do we do would this be done in RDF?

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

<img src="fig5dec16.png" alt="Breaking Up John's Address" />
Figure 5: Breaking Up John's Address

or the triples:

exstaff:85740      exterms:address  exaddressid:85740 .



exstaff:85740       exterms:address        exaddressid:85740 .





exaddressid:85740  exterms:street   "1501 Grant Avenue" .



exaddressid:85740   exterms:street         "1501 Grant Avenue" .





exaddressid:85740  exterms:city     "Bedford" .



exaddressid:85740   exterms:city           "Bedford" .





exaddressid:85740  exterms:state    "Massachusetts" .



exaddressid:85740   exterms:state          "Massachusetts" .





exaddressid:85740  exterms:Zip      "01730" .



exaddressid:85740   exterms:postalCode     "01730" .

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

<img src="fig6dec16.png" alt="Using a Blank Node" />
Figure 6: Using a Blank Node

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

exstaff:85740  exterms:address  ??? .



exstaff:85740   exterms:address         ??? .





???            exterms:street   "1501 Grant Avenue" .



???             exterms:street          "1501 Grant Avenue" .





???            exterms:city     "Bedford" .



???             exterms:city            "Bedford" .





???            exterms:state    "Massachusetts" .



???             exterms:state           "Massachusetts" .





???            exterms:Zip      "01730" 



???             exterms:postalCode      "01730" .

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

exstaff:85740  exterms:address  _:johnaddress .



exstaff:85740   exterms:address         _:johnaddress .





_:johnaddress  exterms:street   "1501 Grant Avenue" .



_:johnaddress   exterms:street          "1501 Grant Avenue" .





_:johnaddress  exterms:city     "Bedford" .



_:johnaddress   exterms:city            "Bedford" .





_:johnaddress  exterms:state    "Massachusetts" .



_:johnaddress   exterms:state           "Massachusetts" .





_:johnaddress  exterms:Zip      "01730" .



_:johnaddress   exterms:postalCode      "01730" .

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

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

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

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

_:jane  exterms:mailbox   mailto:jane@example.org .



_:jane   exterms:mailbox   <mailto:jane@example.org> .





_:jane  rdf:type       exterms:Person .



_:jane   rdf:type          exterms:Person .





_:jane  exterms:name   "Jane Smith" .



_:jane   exterms:name      "Jane Smith" .





_:jane  exterms:empID  "23748"



_:jane   exterms:empID     "23748"  .





_:jane  exterms:age    "26" .



_:jane   exterms:age       "26" .

(Note that mailto:jane@example.org is written within angle brackets in the first triple. This is because mailto:jane@example.org is a full URIref in the mailto URI scheme, rather than a QName abbreviation, and full URIrefs must be enclosed in angle brackets in the triples notation.)

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

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

ex2terms:book78354   rdf:type          ex2terms:Book .

ex2terms:book78354   ex2terms:author   "Jane Smith" .

ex2terms:book78354   rdf:type          ex2terms:Book .

ex2terms:book78354   ex2terms:author   _:author78354 .

_:author78354        rdf:type          ex2terms:Person .

_:author78354        ex2terms:name     "Jane Smith" .

2.4 Typed Literals

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

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

Figure 7: Representing John Smith's Age

In this case, our the hypothetical organization example.org probably intends for "27" to be interpreted as a number, rather than as the string consisting of the character "2" followed by the character "7". However, "7" (since the literal represents the value of an application reading "age" property). However, there is no information in Figure 7's graph that explicitly indicates that deleted text: literal "27" would only know should be interpreted as a number. Similarly, example.org also probably intends for "27" to do be interpreted as a decimal number, i.e., the value twenty seven , rather than, say, as an octal number, i.e., the value twenty three . However, once again there is no information in Figure 7's graph that if explicitly indicates this. Specific applications might be written with the application was understanding that they should interpret values of the exterms:age property as decimal numbers, but this would mean that proper interpretation of this RDF would depend on information not explicitly given provided in the RDF graph, and hence on information that the literal "27" was intended would not necessarily be available to represent a number, and knew which number the literal "27" was supposed other applications that might need to represent. interpret this RDF.

The common practice in programming languages or database systems is to provide this kind of additional information about how to interpret a literal by associating a datatype with the literal, in this case, a datatype like <tt> decimal </tt> or <tt> integer </tt>. . An application that understands the datatype then knows, for example, whether the literal "10" is intended to represent the number ten , the number two , or the string consisting of the character "1" followed by the character "0", depending on whether the specified datatype is <tt> integer </tt>, <tt> , binary </tt>, , or <tt> string </tt>. . In RDF, typed literals are used to provide this kind of information.

Using An RDF typed literal is formed by pairing a string with a URIref that identifies a particular datatype. This results in a single literal node in the RDF graph with the pair as the literal. The value represented by the typed literal is the value that the specified datatype associates with the specified string. For example, using a typed literal, deleted text: we could describe John Smith's age could be described as being the integer number 27 using the triple:

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

or, using our the QName simplification for writing long URIs:

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

or as shown in Figure 8 :

<img src="fig8dec16.png" alt="A Typed Literal for John Smith's Age" />
Figure 8: A Typed Literal for John Smith's Age

Similarly, in the graph shown in Figure 3 describing information about a Web page, deleted text: we recorded the value of the page's <tt> exterms:creation-date </tt> property was written as the plain literal "August 16, 1999". However, using a typed literal, deleted text: we could describe the creation date of the Web page could be explicitly described as being the date August 16, 1999 , using the triple:

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

or as shown in Figure 9 :

<img src="fig9dec16.png" alt="A Typed Literal for a Web Page's Creation Date" />
Figure 9: A Typed Literal for a Web Page's Creation Date

deleted text: As these examples illustrate, an RDF typed literal is formed by explicitly pairing a URIref identifying a particular datatype (in these examples, the datatypes <tt> integer </tt> and <tt> date </tt> from <a href="http://www.w3.org/TR/xmlschema-2/"> XML Schema Part 2: Datatypes </a> <a href="#ref-xmlschema2"> [XML-SCHEMA2] </a> ) with a literal that the datatype uses to represent the intended value. In each case, this results in a single node in the RDF graph with the pair as its label. </p> <p> Unlike typical programming languages and database systems, RDF has no built-in set of datatypes of its own, such as datatypes for integers, reals, strings, or dates. Instead, deleted text: it relies on datatypes defined elsewhere that can be identified by a <a href="http://www.w3.org/TR/rdf-concepts/#dfn-datatype-URI"> datatype URI </a>. RDF typed literals simply provide a way to explicitly indicate, for a given literal, what datatype should be used to interpret it. As far as RDF The datatypes used in typed literals are defined externally to RDF, and identified by their datatype URIs . (There is concerned, you can write any pair of one exception: RDF defines a built-in datatype with the URIref and literal you want rdf:XMLLiteral to represent XML content as a typed literal. literal value. This datatype is defined in [RDF-CONCEPTS] , and its use is described in Section 4.5 .) For instance, the examples in Figure 8 and Figure 9 use the datatypes integer and date from the XML Schema datatypes defined in XML Schema Part 2: Datatypes [XML-SCHEMA2] . An advantage of this approach is that it gives RDF the flexibility to directly represent information coming from different sources without the need to perform type conversions between these sources and a native set of RDF datatypes. (Type conversions would still be required when moving information between systems with having different datatype systems, sets of datatypes, but RDF would impose no extra conversions into and out of a native set of RDF types.) datatypes.)

Since the value that a given typed literal denotes is defined by the typed literal's datatype, and, with the exception of rdf:XMLLiteral , RDF does not define any datatypes, the actual interpretation of a typed literal (determining appearing in an RDF graph (e.g., determining the value it denotes) must be performed by an RDF processor software that is programmed written to "understand" correctly process not only RDF, but the typed literal's datatype as well. Effectively, this software must be written to process an extended language that datatype. In particular, we've used includes not only RDF, but also the datatype, as part of its built-in vocabulary. This raises the issue of which datatypes will be generally available in RDF software. Generally, the XML Schema datatypes that are listed as suitable for use in RDF in [RDF-SEMANTICS] have a "first among equals" status in RDF. As noted already, the deleted text: two examples we've just presented, in Figure 8 and Figure 9 used some of these XML Schema datatypes, and the Primer will be using XML Schema these datatypes in most of our its other examples of typed literals as well (for one thing, XML Schema data types datatypes already have assigned URIrefs we that can use be used to refer to them, specified in [XML-SCHEMA2] ). These XML Schema datatypes deleted text: have a "first among equals" status in RDF. They are treated no differently than any other datatype, but they are expected to be the most widely used, and therefore the most likely to be interoperable among different software. As a result, it is expected that many much RDF processors software will also be programmed written to recognize process these datatypes. However, RDF software could be programmed written to process other sets of datatypes as well. well, assuming they were determined to be suitable for use with RDF, as described already.

In general, RDF datatype concepts also borrow a conceptual framework from XML Schema software may be called on to process RDF data that contains references to datatypes <a href="#ref-xmlschema2"> [XML-SCHEMA2] </a> that the software has not been written to more precisely describe datatype requirements. RDF's use of this framework is defined process, in <a href="http://www.w3.org/TR/rdf-concepts/"> RDF Concepts and Abstract Syntax </a> <a href="#ref-rdf-concepts"> [RDF-CONCEPTS] </a>. </p> <p> The flexibility provided by RDF typed literals comes at a price. which case there are some things the software will not be able to do. For one thing, with the exception of rdf:XMLLiteral , RDF itself does not define the URIrefs that identify datatypes. As a result, RDF software, unless it has no way of knowing been written to recognize specific URIrefs, will not be able to determine whether or not a URIref written in a typed literal actually identifies a datatype. Moreover, even when a URIref does identify a datatype, RDF itself does not define the validity of pairing that datatype with a particular literal. This validity can only be determined by software built written to understand correctly process that particular datatype.

For example, you could write the typed literal in the triple:

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

or the graph shown in Figure 10 :

<img src="fig10dec16.png" alt="An Invalid Typed Literal for John Smith's Age" />
Figure 10: An Invalid Typed Literal for John Smith's Age

deleted text: The typed literal in <a href="#figure10"> Figure 10 </a> is valid RDF, but obviously an error as far as the <tt> xsd:integer </tt> datatype is concerned, since "pumpkin" is not defined as being deleted text: a legal literal for <tt> xsd:integer </tt>. </p> <p> In general, RDF software may be called on to process RDF data that contains datatypes that it has not been programmed to understand, in deleted text: which case there are some things the software will not be able to do. This includes recognizing whether or not a particular string represents a legal value for a particular datatype. In this case, lexical space of xsd:integer . RDF software not built written to understand process the <tt> xsd:integer </tt> datatype would not be able to recognize that "pumpkin" is not this error.

However, proper use of RDF typed literals provides more information about the intended interpretation of literal values, and hence makes RDF statements a valid <tt> xsd:integer </tt>. better means of information exchange among applications.

2.5 Concepts Summary

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

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

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

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

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

3.1 Basic Principles

We can illustrate the The basic ideas behind the RDF/XML syntax can be illustrated using some of the examples deleted text: we've presented already. Suppose we want to represent one of our initial statements: Take as an example the English statement:

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

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

<img src="fig11dec16.png" alt="A Simple RDF Statement" />
Figure 11: A Simple RDF Statement Describing a Web Page's Creation Date

with a triple representation of:

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



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

(Note that a typed literal is not used for the date value in this example. Representing typed literals in RDF/XML will be described later in this section).

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

1. <?xml version="1.0"?>

2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

3.             xmlns:exterms="http://www.example.org/terms/">



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

5.       <exterms:creation-date>August 16, 1999</exterms:creation-date>

6.   </rdf:Description>



7. </rdf:RDF>

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

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

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

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

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

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

Finally, Line 7 indicates the end of the <tt> rdf:RDF </tt> element started on Line line 2. Using an rdf:RDF element to enclose RDF/XML content is optional in situations where the XML can be identified as RDF/XML by context. This is discussed further in [RDF-SYNTAX] . However, it does not hurt to provide the rdf:RDF element in any case, and Primer examples will generally (but not always) provide one.

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

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

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



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





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



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

deleted text: we could write the RDF/XML in Example 3 </a>: could be used:

1.  <?xml version="1.0"?>

2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

3.              xmlns:exterms="http://www.example.org/terms/">



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

5.        <exterms:creation-date>August 16, 1999</exterms:creation-date>

6.    </rdf:Description>



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

8.        <exterms:language>English</exterms:language>

9.    </rdf:Description>



10. </rdf:RDF>

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

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

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



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





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



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





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



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

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

Figure 12: Several Statements About the Same Resource

deleted text: we could write the RDF/XML deleted text: as shown in Example 4 </a>: could be written:

1.  <?xml version="1.0"?>

2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

3.              xmlns:dc="http://purl.org/dc/elements/1.1/"

4.              xmlns:exterms="http://www.example.org/terms/">



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

6.         <exterms:creation-date>August 16, 1999</exterms:creation-date>

7.         <exterms:language>English</exterms:language>

8.         <dc:creator rdf:resource="http://www.example.org/staffid/85740"/>

9.    </rdf:Description>



10. </rdf:RDF>

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

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

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

 <?xml version="1.0"?>

 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

             xmlns:dc="http://purl.org/dc/elements/1.1/"

             xmlns:exterms="http://www.example.org/terms/">



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

       <exterms:creation-date>August 16, 1999</exterms:creation-date>

   </rdf:Description>



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

       <exterms:language>English</exterms:language>

   </rdf:Description>



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

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

   </rdf:Description>



 </rdf:RDF>

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

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

Figure 13: A Graph Containing a Blank Node

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

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

1.  <?xml version="1.0"?>

2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

3.              xmlns:dc="http://purl.org/dc/elements/1.1/"

4.              xmlns:exterms="http://example.org/stuff/1.0/">



5.     <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">

6.       <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>

7.       <exterms:editor rdf:nodeID="abc"/>

8.     </rdf:Description>



9.     <rdf:Description rdf:nodeID="abc">

10.        <exterms:fullName>Dave Beckett</exterms:fullName>

11.        <exterms:homePage rdf:resource="http://purl.org/net/dajobe/"/>

12.    </rdf:Description>



13. </rdf:RDF>

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

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

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

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



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

with corresponding RDF/XML syntax shown in Example 7 :

1. <?xml version="1.0"?>

2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

3.             xmlns:exterms="http://www.example.org/terms/">



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

5.     <exterms:creation-date rdf:datatype=

         "http://www.w3.org/2001/XMLSchema#date">1999-08-16

       </exterms:creation-date>

6.   </rdf:Description>



7. </rdf:RDF>

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

<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> 

1. <?xml version="1.0"?>

2. <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>



3. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

4.             xmlns:exterms="http://www.example.org/terms/">



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

6.     <exterms:creation-date rdf:datatype="&xsd;date">1999-08-16

       </exterms:creation-date>

7.   </rdf:Description>



8. </rdf:RDF>

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

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

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

3.2 Abbreviating and Organizing RDF URIrefs

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

1.   <?xml version="1.0"?>



2.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"



2.   <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>





3.               xmlns:exterms="http://www.example.com/terms/">



3.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"





4.               xmlns:exterms="http://www.example.com/terms/">




deleted text: 

4.     <rdf:Description rdf:ID="item10245">





5.          <exterms:model>Overnighter</exterms:model>



5.     <rdf:Description rdf:ID="item10245">





6.          <exterms:sleeps>2</exterms:sleeps>



6.          <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model>





7.          <exterms:weight>2.4</exterms:weight>



7.          <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps>





8.          <exterms:packedSize>14x56</exterms:packedSize>



8.          <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>





9.     </rdf:Description>



9.          <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize>

10.    </rdf:Description>





  ...other product descriptions...





10.  </rdf:RDF>



11.  </rdf:RDF>

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

<a href="#example8"> Example 8 9 is similar to deleted text: 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, 5, the <tt> rdf:Description </tt> element has an <tt> rdf:ID </tt> attribute instead of an <tt> rdf:about </tt> attribute. Using <tt> rdf:ID </tt> indicates that we are using specifies a fragment identifier , given by the value of the <tt> rdf:ID </tt> attribute ( <tt> item10245 </tt> in this case, which might be the catalog number assigned by example.com), as an abbreviation of the complete URIref of the resource we are describing. being described. The fragment identifier <tt> item10245 </tt> will be interpreted relative to a base URI , in this case, the URI of the containing catalog document. The full URIref for the tent is formed by taking the base URI (of the catalog), and appending <tt> the character " # </tt> " (to indicate that what follows is a fragment identifier) and then <tt> item10245 </tt> to it, giving the absolute URIref <tt> http://www.example.com/2002/04/products#item10245 </tt>. .

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

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

1.  <?xml version="1.0"?>



2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"



2.  <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>





3.              xmlns:sportex="http://www.exampleRatings.com/terms/">



3.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"





4.              xmlns:sportex="http://www.exampleRatings.com/terms/">




deleted text: 

4.    <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">





5.         <sportex:ratingBy>Richard Roe</sportex:ratingBy>



5.    <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">





6.         <sportex:numberStars>5</sportex:numberStars>



6.         <sportex:ratingBy rdf:datatype="&xsd;string">Richard Roe</sportex:ratingBy>





7.    </rdf:Description>



7.         <sportex:numberStars rdf:datatype="&xsd;integer">5</sportex:numberStars>





8.  </rdf:RDF>



8.    </rdf:Description>

9.  </rdf:RDF>

In <a href="#example9"> Example 9 10 , line 4 5 uses an <tt> rdf:Description </tt> element with an <tt> rdf:about </tt> attribute whose value is the full URIref of the tent. The use of this URIref allows the tent being referred to in the rating to be precisely identified.

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

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

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

To deal with such cases, RDF/XML supports XML Base [XML-BASE] , which allows an XML document to specify a base URI other than the URI of the document itself. <a href="#example10"> Example 10 11 shows how deleted text: we would define the catalog would be described using XML Base:

1.   <?xml version="1.0"?>



2.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"



2.   <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>





3.               xmlns:exterms="http://www.example.com/terms/"



3.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"





4.               xml:base="http://www.example.com/2002/04/products">



4.               xmlns:exterms="http://www.example.com/terms/"





5.               xml:base="http://www.example.com/2002/04/products">




deleted text: 

5.     <rdf:Description rdf:ID="item10245">





6.          <exterms:model>Overnighter</exterms:model>



6.     <rdf:Description rdf:ID="item10245">





7.          <exterms:sleeps>2</exterms:sleeps>



7.          <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model>





8.          <exterms:weight>2.4</exterms:weight>



8.          <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps>





9.          <exterms:packedSize>14x56</exterms:packedSize>



9.          <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>





10.    </rdf:Description>



10.         <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize>

11.    </rdf:Description>





  ...other product descriptions...





11.  </rdf:RDF>



12.  </rdf:RDF>

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

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

1.   <?xml version="1.0"?>



2.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"



2.   <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>





3.               xmlns:exterms="http://www.example.com/terms/"



3.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"





4.               xml:base="http://www.example.com/2002/04/products">



4.               xmlns:exterms="http://www.example.com/terms/"





5.               xml:base="http://www.example.com/2002/04/products">




deleted text: 

5.     <rdf:Description rdf:ID="item10245">





6.          <rdf:type rdf:resource="http://www.example.com/terms/Tent" />



6.     <rdf:Description rdf:ID="item10245">





7.          <exterms:model>Overnighter</exterms:model>



7.          <rdf:type rdf:resource="http://www.example.com/terms/Tent"/>





8.          <exterms:sleeps>2</exterms:sleeps>



8.          <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model>





9.          <exterms:weight>2.4</exterms:weight>



9.          <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps>





10.         <exterms:packedSize>14x56</exterms:packedSize>



10.         <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>





11.    </rdf:Description>



11.         <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize>

12.    </rdf:Description>





  ...other product descriptions...





12.  </rdf:RDF>



13.  </rdf:RDF>

In <a href="#example11"> Example 11 12 , the <tt> rdf:type </tt> property in Line 6 line 7 indicates that the resource being described is an instance belongs to a of the class identified by the URIref <tt> http://www.example.com/terms/Tent </tt>. In this case, we imagine . This assumes that example.com has described its classes as part of the same vocabulary that it uses to describe its other terms (such as the property <tt> exterms:weight </tt> ), so deleted text: we use the absolute URIref of the class is used to refer to it. If example.com had described these classes as part of the product catalog itself, deleted text: we could have used the relative URIref <tt> #Tent </tt> could have been used to refer to it.

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

Since describing It is fairly common in RDF for resources to have rdf:type properties that describe the resources as instances of specific types or classes is fairly common, classes. Such resources are called typed nodes in the graph, or typed node elements in the RDF/XML. RDF/XML provides a special abbreviation for instances described as members of classes using the <tt> rdf:type </tt> property. describing these typed nodes. In this abbreviation, the <tt> rdf:type </tt> property and its value are removed, and the <tt> rdf:Description </tt> element for the node is replaced by an element whose name is the QName corresponding to the class URIref. value of the removed rdf:type property (a URIref that names a class). Using this abbreviation, example.com's tent from <a href="#example11"> Example 11 12 could also be described as shown in <a href="#example12"> Example 12 13 :

1.   <?xml version="1.0"?>



2.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"



2.   <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>





3.               xmlns:exterms="http://www.example.com/terms/"



3.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"





4.               xml:base="http://www.example.com/2002/04/products">



4.               xmlns:exterms="http://www.example.com/terms/"





5.               xml:base="http://www.example.com/2002/04/products">




deleted text: 

5.     <exterms:Tent rdf:ID="item10245">





6.          <exterms:model>Overnighter</exterms:model>



6.     <exterms:Tent rdf:ID="item10245">





7.          <exterms:sleeps>2</exterms:sleeps>



7.          <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model>





8.          <exterms:weight>2.4</exterms:weight>



8.          <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps>





9.          <exterms:packedSize>14x56</exterms:packedSize>



9.          <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>





10.    </exterms:Tent>



10.         <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize>

11.    </exterms:Tent>





  ...other product descriptions...





11.  </rdf:RDF>



12.  </rdf:RDF>

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

3.3 RDF/XML Summary

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

4.1 RDF Containers

There is often a need to describe groups of things. For things: for example, deleted text: 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 predefined (built-in) types and properties that can be used to describe such groups.

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

• <tt> rdf:Bag </tt>
• <tt> rdf:Seq </tt>
• <tt> rdf:Alt </tt>

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

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

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

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

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

A typical use of a container is to indicate that the value of a property is a group of things. For example, to represent the sentence "Course 6.001 has the students Amy, Tim, John, Mary, Mohamed, Johann, Maria, and Sue", you could describe Phuong", the course could be described by giving it a <tt> s:students </tt> property (from an appropriate vocabulary) whose value is a container of type <tt> rdf:Bag </tt> (the ( representing the group of students) and then, students). Then, using the container membership properties, deleted text: describe the individual students could be identified as being members of that container, group, as in the RDF graph shown in Figure 14 :

<img src="fig14dec16.png" alt="A Simple Bag Container Description" />
Figure 14: A Simple Bag Container Description

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

RDF/XML provides some special syntax and abbreviations to make it simpler to describe such containers. For example, <a href="#example13"> Example 13 14 describes the graph shown in Figure 14 :

<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"



         xmlns:s="http://example.edu/students/vocab#">



         xmlns:s="http://example.org/students/vocab#">







   <rdf:Description rdf:about="http://example.edu/courses/6.001">



   <rdf:Description rdf:about="http://example.org/courses/6.001">



      <s:students>

         <rdf:Bag>



            <rdf:li rdf:resource="http://example.edu/students/Amy"/>



            <rdf:li rdf:resource="http://example.org/students/Amy"/>





            <rdf:li rdf:resource="http://example.edu/students/Tim"/>



            <rdf:li rdf:resource="http://example.org/students/Mohamed"/>





            <rdf:li rdf:resource="http://example.edu/students/John"/>



            <rdf:li rdf:resource="http://example.org/students/Johann"/>





            <rdf:li rdf:resource="http://example.edu/students/Mary"/>



            <rdf:li rdf:resource="http://example.org/students/Maria"/>





            <rdf:li rdf:resource="http://example.edu/students/Sue"/>



            <rdf:li rdf:resource="http://example.org/students/Phuong"/>



         </rdf:Bag>

      </s:students>

   </rdf:Description>

</rdf:RDF>

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

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

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

<img src="fig15dec16.png" alt="A Simple Alt Container Description" />
Figure 15: A Simple Alt Container Description

<a href="#example14"> Example 14 15 shows how the graph in Figure 15 could be written in RDF/XML:

<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

         xmlns:s="http://example.org/packages/vocab#">



   <rdf:Description rdf:about="http://example.org/packages/X11">

      <s:DistributionSite>

         <rdf:Alt>

            <rdf:li rdf:resource="ftp://ftp.example.org"/>



            <rdf:li rdf:resource="ftp://ftp.example1.org"/>



            <rdf:li rdf:resource="ftp://ftp1.example.org"/>





            <rdf:li rdf:resource="ftp://ftp.example2.org"/>



            <rdf:li rdf:resource="ftp://ftp2.example.org"/>



         </rdf:Alt>

      </s:DistributionSite>

   </rdf:Description>

</rdf:RDF>

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

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

Alt containers are frequently used in conjunction with language tagging. (RDF/XML permits the use of the xml:lang attribute defined in [XML] to indicate that the element content is in a specified language. The use of xml:lang is described in [RDF-SYNTAX] , and illustrated later in Section 6.2 .) For example, a work whose title has been translated into several languages might have its <tt> Title </tt> title property pointing to an Alt container holding literals representing the titles expressed in each of the language variants.

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

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

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

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

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

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

exstaff:Sue exterms:publication ex:AnthologyOfTime .



exstaff:Sue   exterms:publication   ex:AnthologyOfTime .





exstaff:Sue exterms:publication ex:ZoologicalReasoning .



exstaff:Sue   exterms:publication   ex:ZoologicalReasoning .





exstaff:Sue exterms:publication ex:GravitationalReflections .



exstaff:Sue   exterms:publication   ex:GravitationalReflections .

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

exstaff:Sue exterms:publication _:z



exstaff:Sue   exterms:publication   _:z .





_:z rdf:type rdf:Bag .



_:z           rdf:type              rdf:Bag .





_:z rdf:_1 ex:AnthologyOfTime .



_:z           rdf:_1                ex:AnthologyOfTime .





_:z rdf:_2 ex:ZoologicalReasoning .



_:z           rdf:_2                ex:ZoologicalReasoning .





_:z rdf:_3 ex:GravitationalReflections .



_:z           rdf:_3                ex:GravitationalReflections .

On the other hand, the sentence:

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

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

ex:resolution exterms:approvedBy ex:Fred .



ex:resolution   exterms:approvedBy   ex:Fred .





ex:resolution exterms:approvedBy ex:Wilma .



ex:resolution   exterms:approvedBy   ex:Wilma .





ex:resolution exterms:approvedBy ex:Dino .



ex:resolution   exterms:approvedBy   ex:Dino .

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

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

ex:resolution exterms:approvedBy ex:rulesCommittee



ex:resolution       exterms:approvedBy   ex:rulesCommittee .





ex:rulesCommittee rdf:type rdf:Bag .



ex:rulesCommittee   rdf:type             rdf:Bag .





ex:rulesCommittee rdf:_1 ex:Fred .



ex:rulesCommittee   rdf:_1               ex:Fred .





ex:rulesCommittee rdf:_2 ex:Wilma .



ex:rulesCommittee   rdf:_2               ex:Wilma .





ex:rulesCommittee rdf:_3 ex:Dino .



ex:rulesCommittee   rdf:_3               ex:Dino .

Finally, when When using deleted text: these RDF containers, it is important to understand that you the statements are not constructing containers, as you would in a programming language data structure; instead, you structure. Instead, the statements are describing containers (groups of things) that actually presumably exist. For instance, in the Rules Committee example just given, the Rules Committee is an unordered group of people, whether deleted text: you describe it is described in RDF that way or not. When you give Saying that the deleted text: Rules Committee resource an <tt> rdf:type </tt> property whose value is <tt> ex:rulesCommittee has type rdf:Bag </tt>, you are simply describing is not saying that the Rules Committee as having whatever characteristics you associate with things of type <tt> rdf:Bag </tt>, not is a data structure, or constructing a particular data structure to hold the members of the group (you could indicate that the (the Rules Committee was could be described as a Bag without describing any members at all). Instead, it is describing the Rules Committee as having characteristics corresponding to those associated with a Bag container, namely that it has members, and their order of description is not significant. Similarly, when you use using the container membership properties, you are properties simply describing describes a container resource as having certain things as members. You are This does not necessarily saying say that the things that you describe described as members are the only members that exist. For example, the triples given above to describe the Rules Committee say only that Fred, Wilma, and Dino are members of the Bag, committee, not that they are the only members of the Bag. committee.

<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

         xmlns:s="http://example.org/packages/vocab#"> 

 

 <rdf:Description rdf:about="http://example.org/packages/X11">

    <s:DistributionSite>

       <rdf:Alt>

          <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag"/> 

          <rdf:_2 rdf:resource="ftp://ftp.example.org"/>

          <rdf:_2 rdf:resource="ftp://ftp1.example.org"/>

          <rdf:_5 rdf:resource="ftp://ftp2.example.org"/>

      </rdf:Alt>

    </s:DistributionSite>

 </rdf:Description>

</rdf:RDF>

4.2 RDF Collections

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

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

<img src="fig16dec16.png" alt="An RDF Collection (list structure)" />
Figure 16: An RDF Collection (list structure)

For In this graph, each member of the collection, such as <tt> s:Amy </tt>, there , is the object of an rdf:first property whose subject is a deleted text: corresponding resource of type <tt> rdf:List </tt>. (a blank node in this example) that represents a list. This list resource is linked to the deleted text: collection member by an <tt> rdf:first </tt> property, and to the rest of the list by an <tt> rdf:rest </tt> property. The end of the list is indicated by an <tt> the rdf:rest </tt> property being having as its object the resource <tt> rdf:nil </tt>. (the resource rdf:nil represents the empty list, and is defined as being of type rdf:List ). This structure will be familiar to those who know the Lisp programming language. As in Lisp, the <tt> rdf:first </tt> and <tt> rdf:rest </tt> properties allow applications to traverse the structure. Each of the blank nodes forming this list structure is implicitly of type rdf:List (that is, each of these nodes implicitly has an rdf:type property whose value is the predefined type rdf:List ), although this is not explicitly shown in the graph. The RDF Schema language [RDF-VOCABULARY] defines the properties rdf:first and rdf:rest as having subjects of type rdf:List , so the information about these nodes being lists can generally be inferred, rather than the corresponding rdf:type triples being written out all the time.

RDF/XML provides a special notation to make it easier easy to describe collections. collections using graphs of this form. In RDF/XML, a collection is can be described by a property element that has the attribute <tt> rdf:parseType="Collection" </tt>, , and that contains a group of nested elements representing the members of the collection. The <tt> RDF/XML provides the rdf:parseType attribute to indicate that the contents of an element are to be interpreted in a special way. In this case, the rdf:parseType="Collection" </tt> attribute indicates that the enclosed elements are to be used to create the corresponding list structure in the RDF graph. graph (other values of the rdf:parseType attribute will be described in later sections of the Primer).

To illustrate how this rdf:parseType="Collection" works, the RDF/XML from <a href="#example15"> Example 15 17 would result in the RDF graph shown in Figure 16 :

<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"



         xmlns:s="http://example.edu/students/vocab#">



         xmlns:s="http://example.org/students/vocab#">







   <rdf:Description rdf:about="http://example.edu/courses/6.001">



   <rdf:Description rdf:about="http://example.org/courses/6.001">



      <s:students rdf:parseType="Collection">



            <rdf:Description rdf:about="http://example.edu/students/Amy"/>



            <rdf:Description rdf:about="http://example.org/students/Amy"/>





            <rdf:Description rdf:about="http://example.edu/students/Tim"/>



            <rdf:Description rdf:about="http://example.org/students/Mohamed"/>





            <rdf:Description rdf:about="http://example.edu/students/John"/>



            <rdf:Description rdf:about="http://example.org/students/Johann"/>



      </s:students>

   </rdf:Description>

</rdf:RDF>

<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

         xmlns:s="http://example.org/students/vocab#"> 



<rdf:Description rdf:about="http://example.org/courses/6.001"> 

   <s:students rdf:nodeID="sch1"/>

</rdf:Description>

 

<rdf:Description rdf:nodeID="sch1"> 

   <rdf:first rdf:resource="http://example.org/students/Amy"/>

   <rdf:rest rdf:nodeID="sch2"/> 

</rdf:Description>

 

<rdf:Description rdf:nodeID="sch2"> 

   <rdf:first rdf:resource="http://example.org/students/Mohamed"/>

   <rdf:rest rdf:nodeID="sch3"/> 

</rdf:Description>

 

<rdf:Description rdf:nodeID="sch3"> 

   <rdf:first rdf:resource="http://example.org/students/Johann"/>

   <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/> 

</rdf:Description>

</rdf:RDF>

4.3 RDF Reification

RDF applications sometimes need to make <em> statements about describe other RDF statements </em>, using RDF, for instance, to record information about when a statement was statements were made, who made it, them, or other similar information. information (this is sometimes referred to as "provenance" information). For example, consider a statement about the tent we discussed Example 9 in Section 3.2 </a>: </p> <p class="ptriple"> <tt> <u> product item10245 </u> has described a <u> weight </u> whose value is <u> 2.4 </u> </tt> </p> <p> particular tent with a triple representation of: </p> <div class="exampleOuter exampleInner"> <pre> exproducts:item10245 exterms:weight "2.4" . </pre> </div> <p> Now, suppose we wanted to say in RDF that this statement was made URIref exproducts:item10245 , offered for sale by John Smith. Since in RDF we can only make statements about <em> resources </em>, what we would like to be able to do is write something like: example.com. One of the triples from that description, describing the weight of the tent, was:

 <strong>[[</strong>exproducts:item10245  exterms:weight  "2.4" .<strong>]]</strong> dc:creator  exstaff:85740 .



exproducts:item10245   exterms:weight   "2.4"^^xsd:decimal .

That is, we want to and it might be able useful for example.com to turn the original statement into a resource, so record who provided that we can make it the subject particular piece of another RDF statement that talks about it. information.

RDF provides a built-in vocabulary intended for modeling statements as resources. This modeling is called <em> reification </em> in RDF, and a model describing RDF statements. A description of a statement using this vocabulary is called the a reification of the statement. deleted text: </p> <p> The RDF reification vocabulary consists of the type <tt> rdf:Statement </tt>, , and the properties <tt> rdf:subject </tt>, <tt> , rdf:predicate </tt>, , and <tt> rdf:object </tt>. In . However, while RDF provides this reification vocabulary, care is needed in using it, because it is easy to imagine that the vocabulary defines some things that are not actually defined. This point will be discussed further later in this section.

Using the reification vocabulary, a triple reification of the form: statement about the tent's weight would be given by assigning the statement a URIref such as exproducts:triple12345 (so statements can be written describing it), and then describing the statement using the statements:

foo  rdf:type  rdf:Statement .



exproducts:triple12345   rdf:type        rdf:Statement .

exproducts:triple12345   rdf:subject     exproducts:item10245 .

exproducts:triple12345   rdf:predicate   exterms:weight . 

exproducts:triple12345   rdf:object      "2.4"^^xsd:decimal .

is a statement These statements say that the resource <tt> foo </tt> identified by the URIref exproducts:triple12345 is an RDF triple in some RDF document. The three properties <tt> rdf:subject </tt>, <tt> rdf:predicate </tt>, and <tt> rdf:object </tt>, when applied statement, that the subject of the statement refers to deleted text: <tt> foo </tt>, then specify the subject, predicate, resource identified by exproducts:item10245 , the predicate of the statement refers to the resource identified by exterms:weight , and the object deleted text: components of the statement refers to the decimal value identified by the typed literal "2.4"^^xsd:decimal . Assuming that triple <tt> foo </tt>. the original statement is actually identified by exproducts:triple12345 , it should be clear by comparing the original statement with the reification that the reification actually does describe it. The conventional use of the RDF reification vocabulary always involves describing a statement using four statements in this pattern; the four statements are sometimes referred to as a "reification quad" for this reason.

Using reification according to this vocabulary, convention, example.com could record the fact that John Smith made the original statement about the tent's weight by first assigning the original statement a <em> URIref (such as exproducts:triple12345 as before), describing that statement using the reification </em> of our original triple: just described, and then adding an additional statement that exproducts:triple12345 was written by John Smith (using a URIref to identify which John Smith is being referred to). The resulting statements would be:

exproducts:item10245  exterms:weight  "2.4" .



exproducts:triple12345   rdf:type        rdf:Statement .

exproducts:triple12345   rdf:subject     exproducts:item10245 . 

exproducts:triple12345   rdf:predicate   exterms:weight . 

exproducts:triple12345   rdf:object      "2.4"^^xsd:decimal .

exproducts:triple12345   dc:creator      exstaff:85740 . 

is given by The original statement, together with the graph: reification and the attribution of the statement to John Smith, forms the graph shown in Figure 17 :

<div class="exampleOuter exampleInner">

Figure 17: A Statement, Its Reification, and Its Attribution

This graph could be written in RDF/XML as shown in Example 19 :

Example 19: RDF/XML for the Reification Example

_:xxx rdf:type rdf:Statement .



<?xml version="1.0"?>





_:xxx rdf:subject exproducts:item10245 .



<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>





_:xxx rdf:predicate exterms:weight . 



<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

            xmlns:dc="http://purl.org/dc/elements/1.1/"

            xmlns:exterms="http://www.example.com/terms/"

            xml:base="http://www.example.com/2002/04/products">





_:xxx rdf:object "2.4" .





  <rdf:Description rdf:ID="item10245">

     <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>

  </rdf:Description>



  <rdf:Statement rdf:about="#triple12345">

     <rdf:subject rdf:resource="http://www.example.com/2002/04/products#item10245"/>

     <rdf:predicate rdf:resource="http://www.example.com/terms/weight"/>

     <rdf:object rdf:datatype="&xsd;decimal">2.4</rdf:object>



     <dc:creator rdf:resource="http://www.example.com/staffid/85740"/>

  </rdf:Statement>



</rdf:RDF>

(The node that is intended to refer to Section 3.2 introduced the first triple, use of the blank node <tt> _:xxx </tt> rdf:ID attribute in RDF/XML in an rdf:Description element to abbreviate the reification, could be either a blank node or a URIref.) </p> <p> The <em> intended </em> interpretation URIref of the subject of a reification like this is that <tt> _:xxx </tt> should statement. rdf:ID can also be understood as referring used in a property element to automatically produce a reification of the deleted text: original triple (as a whole), which is described by that the subject, predicate, and object triples in property element generates. Example 20 shows how this could be used to produce the reification. So, same graph as Example 19 :

Example 20: Generating Reifications using rdf:ID

<?xml version="1.0"?>

<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

            xmlns:dc="http://purl.org/dc/elements/1.1/"

            xmlns:exterms="http://www.example.com/terms/"

            xml:base="http://www.example.com/2002/04/products">



  <rdf:Description rdf:ID="item10245">

     <exterms:weight rdf:ID="triple12345" rdf:datatype="&xsd;decimal">2.4

     </exterms:weight>

  </rdf:Description>



  <rdf:Description rdf:about="#triple12345">

     <dc:creator rdf:resource="http://www.example.com/staffid/85740"/>

  </rdf:Description>



</rdf:RDF>

In this case, specifying the reification, we would express attribute rdf:ID="triple12345" in the fact that exterms:weight element results in the original statement was made by John Smith using triple describing the graph: tent's weight:

_:xxx rdf:type rdf:Statement .



exproducts:item10245   exterms:weight   "2.4"^^xsd:decimal .





_:xxx rdf:subject exproducts:item10245 . 

plus the reification triples:

_:xxx rdf:predicate exterms:weight . 



exproducts:triple12345   rdf:type        rdf:Statement .





_:xxx rdf:object "2.4" .



exproducts:triple12345   rdf:subject     exproducts:item10245 .





_:xxx dc:creator exstaff:85740 . 



exproducts:triple12345   rdf:predicate   exterms:weight . 

exproducts:triple12345   rdf:object      "2.4"^^xsd:decimal .

The subject of these reification triples is a URIref formed by concatenating the base URI of the document (given in the xml:base declaration), the character " # " (to indicate that what follows is a fragment identifier), and the value of the rdf:ID attribute; that is, the triples have the same subject exproducts:triple12345 as in the previous examples.

Note that asserting the intended interpretation reification is not the same as asserting the original statement, and neither implies the other. That is, when someone says that John said something about the triple weight of a tent, they are not making a statement about the weight of a tent themselves, they are making a statement about something John said. Conversely, when someone describes the weight of a tent, they are not also making a statement about a statement they made (since they may have no intention of talking about things called "statements").

The text above deliberately referred in a number of places to "the conventional use of reification". As noted earlier, care is needed when using the RDF reification vocabulary because it is easy to imagine that <tt> _:xxx </tt> refers the vocabulary defines some things that are not actually defined. While there are applications that successfully use reification, they do so by following some conventions, and making some assumptions, that are in addition to the actual meaning that RDF defines for the reification vocabulary, and the actual facilities that RDF provides to support it.

For one thing, it is important to note that in the conventional use of reification, the subject of the reification triples is assumed to identify a particular instance of a triple in a particular RDF document, rather than some arbitrary triple having the same subject, predicate, and object. This particular convention is used because reification is intended for expressing properties such as dates of composition and source information, as in the examples given already, and these properties need to be applied to specific instances of triples. There could be several deleted text: such triples that have the same subject, predicate predicate, and object properties. Although and, although a graph is defined as a set of triples, several instances with the same triple structure might occur in different documents. Thus, deleted text: without this understanding, it would be meaningful to claim that <tt> _:xxx </tt> does not refer to the triple in the first graph, but fully support this convention, there needs to be some other triple with means of associating the same structure. This particular interpretation subject of the reification is used because reification is intended to be used to express properties such as dates of composition and source information, as triples with an individual triple in our example, and these properties need to be applied some document . However, RDF provides no way to specific instances of triples. do this.

Note also that For instance, in the assertion of examples above, there is no explicit information in either the reified triples or the RDF/XML that actually indicates that the original statement describing the tent's weight is deleted text: not the same as resource exproducts:triple12345 , the assertion resource that is the subject of the original statement, four reification statements and deleted text: neither implies the other. That is, when someone asserts that John said foo, they are not asserting foo themselves, just statement that John said Smith created it. Conversely, when someone asserts foo, they are not also asserting its reification, since This can be seen by asserting foo they are not also saying that there are such things as statements that they intend to talk about. </p> <p> We have referred to looking at the <em> intended </em> interpretation of reification drawn graph shown in the discussion above because, while Figure 17 . The original statement is certainly part of this may be graph, but as far as the interpretation that information in the graph is generally intended when reification concerned, exproducts:triple12345 is used, a separate resource, rather than identifying that part of the graph. RDF deleted text: reification does not actually capture all this meaning. Specifically, RDF syntax by itself provides no provide a built-in way to "connect" an RDF triple to its reification. All that the graph: </p> <div class="exampleOuter exampleInner"> <pre> _:xxx rdf:type rdf:Statement . _:xxx rdf:subject exproducts:item10245 . _:xxx rdf:predicate exterms:weight . _:xxx rdf:object "2.4" . _:xxx dc:creator exstaff:85740 . </pre> </div> <p> actually says is, "there of indicating how a URIref like exproducts:triple12345 is associated with a particular statement that has or graph, any more than it provides a subject <tt> exproducts:item10245 </tt>, built-in way of indicating how a predicate <tt> exterms:weight </tt>, and an object <tt> 2.4 </tt>, and John made it". It does <em> not </em> say that that statement (referred to by <tt> _:xxx </tt> ) URIref like exproducts:item10245 is the same as some particular statement associated with an actual tent. Associating specific URIrefs with specific resources (statements in some particular RDF document. this case) must be done using mechanisms outside of RDF.

To see this, given Using rdf:ID as shown in Example 20 generates the original triple: </p> <div class="exampleOuter exampleInner"> <pre> exproducts:item10245 exterms:weight "2.4" . </pre> </div> <p> reification automatically, and provides a convenient way of indicating the following reification URIref to be used as the subject of it, together with an additional triple that associates John the statements in the reification. Moreover, it provides a partial "hook" relating the triples in the reification with the reification: </p> <div class="exampleOuter exampleInner"> <pre> _:xxx rdf:type rdf:Statement . _:xxx rdf:subject exproducts:item10245 . _:xxx rdf:predicate exterms:weight . _:xxx rdf:object "2.4" . _:xxx dc:creator exstaff:85740 . </pre> </div> <p> note piece of RDF/XML syntax that caused them to be created, since the value triple12345 of the rdf:ID attribute is used to generate the URIref of the subject of the reification triples. However, this relationship is once again outside RDF, since there is nothing in the resulting triples that explicitly associates <tt> _:xxx </tt> with says that the original triple, triple had the URIref exproducts:triple12345 (RDF does not assume there is any relationship between a URIref and hence would allow you to say any RDF/XML that John created it. it might have been used or abbreviated in).

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

To see this, if our assuming the original triple statement:

exproducts:item10245   exterms:weight   "2.4"^^xsd:decimal .

had a URI, say <tt> ex:statementfoo </tt>, then you could attribute that URIref of exproducts:triple12345 , the statement could be attributed to John Smith simply by the statement:

ex:statementfoo dc:creator exstaff:85740 .



exproducts:triple12345   dc:creator   exstaff:85740 .

with no use of the reification vocabulary. vocabulary (although the description of exproducts:triple12345 as having rdf:type rdf:Statement might also be helpful).

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

Finally, since It is also important to note that the relation between triples and reifications interpretation of deleted text: triples in any RDF graph or graphs need not be one-to-one, asserting a property about some resource described by a reification does described here is not deleted text: necessarily mean that the same property holds as "quotation", as found in some languages. Instead, the reification describes the relationship between a particular instance of another such resource, even if it has a triple and the same components. resources the triple refers to. The reification can be read intuitively as saying "this RDF triple talks about these things", rather than (as in quotation) "this RDF triple has this form." For example, given instance, in the following graph: reification example used in this section, the triple:

_:xxx rdf:type rdf:Statement .

_:xxx rdf:subject exproducts:item10245 . 

_:xxx rdf:predicate exterms:weight . 

_:xxx rdf:object "2.4" .



_:yyy rdf:type rdf:Statement .

_:yyy rdf:subject exproducts:item10245 . 

_:yyy rdf:predicate exterms:weight . 

_:yyy rdf:object "2.4" .



_:xxx dc:creator exstaff:85740 .



exproducts:triple12345   rdf:subject   exproducts:item10245 .

it describing the rdf:subject of the original statement says that the subject of the statement is the resource (the tent) identified by the URIref exproducts:item10245 . It does not follow that: say that the subject of the statement is the URIref itself (i.e., a string beginning with certain characters), as quotation would do.

deleted text: <div class="exampleOuter exampleInner"> <pre> _:yyy dc:creator exstaff:85740 . </pre>

4.4 More on Structured Values: rdf:value

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

exstaff:85740  exterms:manager  exstaff:62345 .



exstaff:85740   exterms:manager   exstaff:62345 .

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

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

<tt> address(exstaff:85740, "1501 Grant Avenue", "Bedford", "Massachusetts", "01730") </tt>

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

exstaff:85740  exterms:address  _:johnaddress .



exstaff:85740   exterms:address        _:johnaddress .





_:johnaddress  exterms:street   "1501 Grant Avenue" .



_:johnaddress   exterms:street         "1501 Grant Avenue" .





_:johnaddress  exterms:city     "Bedford" .



_:johnaddress   exterms:city           "Bedford" .





_:johnaddress  exterms:state    "Massachusetts" .



_:johnaddress   exterms:state          "Massachusetts" .





_:johnaddress  exterms:Zip      "01730" .



_:johnaddress   exterms:postalCode     "01730" .

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

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

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

exproduct:item10245  exterms:weight  "2.4" .



exproduct:item10245   exterms:weight   "2.4"^^xsd:decimal .

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

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

exproduct:item10245  exterms:weight  _:weight10245 .



exproduct:item10245   exterms:weight   _:weight10245 .





_:weight10245    rdf:value  "2.4" .



_:weight10245         rdf:value        "2.4"^^xsd:decimal .





_:weight10245    exterms:units   exunits:kilograms .



_:weight10245         exterms:units    exunits:kilograms .

which can be exchanged expressed using the RDF/XML shown in <a href="#example16"> Example 16 21 :

 <?xml version="1.0"?>



<?xml version="1.0"?>





 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"



<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>





             xmlns:exterms="http://www.example.org/terms/">



<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"





            xmlns:exterms="http://www.example.org/terms/">




deleted text: 

   <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">





      <exterms:weight rdf:parseType="Resource">



  <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">





        <rdf:value>2.4</rdf:value>



     <exterms:weight rdf:parseType="Resource">





        <exterms:units rdf:resource="http://www.example.org/units/kilograms" />



       <rdf:value rdf:datatype="&xsd;decimal">2.4</rdf:value>





      </exterms:weight>



       <exterms:units rdf:resource="http://www.example.org/units/kilograms"/>





   </rdf:Description>



     </exterms:weight>

  </rdf:Description>





 </rdf:RDF>





</rdf:RDF>

Example 16 21 uses some additional RDF/XML abbreviations that were not discussed also illustrates a second use of the rdf:parseType attribute introduced in <a href="#rdfxml"> Section 3 4.2 , but in this case, rdf:parseType="Resource" . An rdf:parseType="Resource" attribute is used to indicate that the contents of an element are described to be interpreted as the description of a new (blank node) resource, without actually having to write a nested rdf:Description element. In this case, the rdf:parseType="Resource" attribute used in the exterms:weight property element indicates that a blank node is to be created as the value of the exterms:weight property, and that the enclosed elements ( rdf:value and exterms:units ) describe properties of that blank node. Further details on rdf:parseType="Resource" are given in [RDF-SYNTAX] </a>.) .

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

You There is no need not to use <tt> rdf:value </tt> for these purposes (e.g., you could assign your own a user-defined property name, such as <tt> ex:amount </tt>, exterms:amount , could have been used instead of rdf:value in the example above), Example 21 ), and RDF does not associate any particular special meaning with it. <tt> rdf:value </tt> . rdf:value is simply provided as a convenience for use in these commonly-occurring situations.

5.1 Describing Classes

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

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

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

ex:MotorVehicle rdf:type rdfs:Class .



ex:MotorVehicle   rdf:type   rdfs:Class .

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

ex:companyCar rdf:type ex:MotorVehicle .



exthings:companyCar   rdf:type   ex:MotorVehicle .

(We are using (This statement uses a frequently-used common convention that class names are written with an initial uppercase letter, while property and instance names are written with an initial lowercase letter. However, this convention is not required in RDFS) RDF Schema. The statement also assumes that example.org has decided to define separate vocabularies for classes of things, and instances of things.)

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

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

ex:Van rdf:type rdfs:Class .



ex:Van     rdf:type   rdfs:Class .





ex:Truck rdf:type rdfs:Class .



ex:Truck   rdf:type   rdfs:Class .

and so on. However, we want to do more than just these statements by themselves only describe the individual classes; we classes. example.org may also want to indicate their special relationship to class <tt> ex:MotorVehicle </tt>, , i.e., that they are specialized kinds of MotorVehicle. deleted text: To do this, we use the RDFS concept of <em> subclass </em>.

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

ex:Van rdfs:subClassOf ex:MotorVehicle .



ex:Van   rdfs:subClassOf   ex:MotorVehicle .

The meaning of the <tt> this rdfs:subClassOf </tt> relationship is that any instance of class ex:Van is also an instance of class ex:MotorVehicle . So if resource <tt> ex:companyVan </tt> exthings:companyVan is an instance of <tt> ex:Van </tt>, then <tt> ex:companyVan </tt> then, based on the declared rdfs:subClassOf relationship, RDF software written to understand the RDF Schema vocabulary can infer the additional information that exthings:companyVan is also deleted text: implicitly considered an instance of <tt> ex:Motorvehicle </tt> (that is, you can "infer" or act ex:MotorVehicle .

This example of exthings:companyVan illustrates the point made earlier about RDF Schema defining an extended language. RDF itself does not define the special meaning of terms from the RDF Schema vocabulary such as rdfs:subClassOf . So if <tt> ex:companyVan </tt> an RDF schema defines this rdfs:subClassOf relationship between ex:Van and ex:MotorVehicle , RDF software not written to understand the RDF Schema terms would recognize this as a triple, with predicate rdfs:subClassOf , but it would not understand the special significance of rdfs:subClassOf , and not be able to draw the additional inference that exthings:companyVan is also an instance of <tt> ex:MotorVehicle </tt> even if this is not explicitly stated). .

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

ex:Van rdfs:subClassOf ex:MotorVehicle .



ex:Van       rdfs:subClassOf   ex:MotorVehicle .





ex:MiniVan rdfs:subClassOf ex:Van .



ex:MiniVan   rdfs:subClassOf   ex:Van .

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

<a href="#figure17"> Figure 17 18 shows the full class hierarchy we have been discussing. being discussed in these examples.

<img src="fig17dec16.png" alt="A Simple Class Hierarchy" />
<a id="figure17" name="figure17"> Figure 17: 18: A Simple Vehicle Class Hierarchy

(To simplify the figure, the rdf:type properties relating each of the classes to rdfs:Class are omitted in Figure 18 . In fact, RDF Schema defines both the subjects and objects of statements that use the rdfs:subClassOf property to be resources of type rdfs:Class , so this information could be inferred. However, in actually writing schemas, it is good practice to explicitly provide this information.)

This schema could also be described by the triples:

ex:MotorVehicle rdf:type rdfs:Class .



ex:MotorVehicle       rdf:type          rdfs:Class .





ex:PassengerVehicle rdf:type rdfs:Class .



ex:PassengerVehicle   rdf:type          rdfs:Class .





ex:Van rdf:type rdfs:Class .



ex:Van                rdf:type          rdfs:Class .





ex:Truck rdf:type rdfs:Class .



ex:Truck              rdf:type          rdfs:Class .





ex:MiniVan rdf:type rdfs:Class .



ex:MiniVan            rdf:type          rdfs:Class .







ex:PassengerVehicle rdfs:subClassOf ex:MotorVehicle .



ex:PassengerVehicle   rdfs:subClassOf   ex:MotorVehicle .





ex:Van rdfs:subClassOf ex:MotorVehicle .



ex:Van                rdfs:subClassOf   ex:MotorVehicle .





ex:Truck rdfs:subClassOf ex:MotorVehicle .



ex:Truck              rdfs:subClassOf   ex:MotorVehicle .







ex:MiniVan rdfs:subClassOf ex:Van .



ex:MiniVan            rdfs:subClassOf   ex:Van .





ex:MiniVan rdfs:subClassOf ex:PassengerVehicle .



ex:MiniVan            rdfs:subClassOf   ex:PassengerVehicle .

<a href="#example1"> Example 17 23 shows how this schema could be written in RDF/XML.

<?xml version="1.0"?>



<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>



<rdf:RDF   

  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  



  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">



  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

  xml:base="http://example.org/schemas/vehicles">





<rdf:Description rdf:ID="MotorVehicle">

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

</rdf:Description>



<rdf:Description rdf:ID="PassengerVehicle">

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

  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>

</rdf:Description>



<rdf:Description rdf:ID="Truck">

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

  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>

</rdf:Description>



<rdf:Description rdf:ID="Van">

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

  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>

</rdf:Description>



<rdf:Description rdf:ID="MiniVan">

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

  <rdfs:subClassOf rdf:resource="#Van"/>

  <rdfs:subClassOf rdf:resource="#PassengerVehicle"/>

</rdf:Description>



</rdf:RDF>

<?xml version="1.0"?>

<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>

<rdf:RDF   

  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  

  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

  xml:base="http://example.org/schemas/vehicles">



<rdfs:Class rdf:ID="MotorVehicle"/>



<rdfs:Class rdf:ID="PassengerVehicle">

  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>

</rdfs:Class>



<rdfs:Class rdf:ID="Truck">

  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>

</rdfs:Class>



<rdfs:Class rdf:ID="Van">

  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>

</rdfs:Class>



<rdfs:Class rdf:ID="MiniVan">

  <rdfs:subClassOf rdf:resource="#Van"/>

  <rdfs:subClassOf rdf:resource="#PassengerVehicle"/>

</rdfs:Class>



</rdf:RDF>

The RDF/XML in Example 23 and Example 24 introduces names, such as <tt> MotorVehicle </tt>, , for the resources (classes) that it describes using <tt> rdf:ID </tt>, , to give the effect of "assigning" URIrefs relative to the schema document as deleted text: we described in Section 3.2 . rdf:ID is useful here because it both abbreviates the URIrefs, and also provides an additional check that the value of the rdf:ID attribute is unique against the current base URI (usually the document URI). This helps pick up repeated rdf:ID values when defining the names of classes and properties in RDF schemas. Relative URIrefs based on these names can then be used in other class definitions within the same schema (e.g., as we used <tt> #MotorVehicle </tt> is used in the description of the other classes). The full URIref of this class, assuming that the schema itself was the resource <tt> http://example.org/schemas/vehicles </tt>, , would be <tt> http://example.org/schemas/vehicles#MotorVehicle </tt> (as shown (shown in <a href="#figure17"> Figure 17 18 ). As noted in Section 3.2 , to ensure that the references to these schema classes would be consistently maintained even if the schema were relocated or copied (or to simply assign a base URIref for the schema classes without assuming they are all published at a single location), the class descriptions could also include an explicit <tt> xml:base="http://example.org/schemas/vehicles" </tt> declaration. Use of an explicit xml:base declaration is considered good practice, and one is provided in both examples.

To refer to these classes in RDF instance data (e.g., data describing individual vehicles of these classes) located elsewhere, we example.org would need to use identify the full classes either by writing absolute URIrefs, by using relative URIrefs together with an appropriate xml:base declaration, or by using QNames together with an appropriate namespace declaration that allows the QNames to be expanded to deleted text: identify the classes. proper URIrefs. For example, deleted text: to describe the resource <tt> ex2:companyCar </tt> exthings:companyCar could be described as an instance of the class <tt> ex:MotorVehicle </tt> described in this schema, we could use the schema of Example 24 by the RDF/XML shown in <a href="#example18"> Example 18 </a>: 25 :

<?xml version="1.0"?>

<rdf:RDF   

  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  



  xmlns:ex="http://example.org/schemas/vehicles">




  xmlns:ex="http://example.org/schemas/vehicles#"





  xml:base="http://example.org/things">



deleted text: 

   <rdf:Description rdf:ID="companyCar">



deleted text: 

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





   </rdf:Description>



   <ex:MotorVehicle rdf:ID="companyCar"/>





</rdf:RDF>

5.2 Describing Properties

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

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

exterms:weightInKg  rdf:type  rdf:Property .



exterms:weightInKg   rdf:type   rdf:Property .

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

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

ex:Person  rdf:type  rdfs:Class .



ex:Person   rdf:type     rdfs:Class .





ex:author  rdf:type  rdf:Property .



ex:author   rdf:type     rdf:Property .





ex:author  rdfs:range  ex:Person .



ex:author   rdfs:range   ex:Person .

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

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

ex:hasMother   rdfs:range   ex:Female .

ex:hasMother   rdfs:range   ex:Person .

exstaff:frank   ex:hasMother   exstaff:frances .

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

ex:age  rdf:type  rdf:Property .



ex:age   rdf:type     rdf:Property .





ex:age  rdfs:range  xsd:integer .



ex:age   rdfs:range   xsd:integer .

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

xsd:integer rdf:type rdfs:Datatype .



xsd:integer   rdf:type   rdfs:Datatype .

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

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

ex:Book  rdf:type  rdfs:Class .



ex:Book     rdf:type      rdfs:Class .





ex:author  rdf:type  rdf:Property .



ex:author   rdf:type      rdf:Property .





ex:author  rdfs:domain  ex:Book .



ex:author   rdfs:domain   ex:Book .

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

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

exterms:weight   rdfs:domain   ex:Book .

exterms:weight   rdfs:domain   ex:MotorVehicle .

exthings:companyCar   exterms:weight   "2500"^^xsd:integer .

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

<rdf:Description rdf:ID="registeredTo">

  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>



<rdf:Property rdf:ID="registeredTo">



  <rdfs:domain rdf:resource="#MotorVehicle"/>

  <rdfs:range rdf:resource="#Person"/>



</rdf:Description>




</rdf:Property>




deleted text: 

<rdf:Description rdf:ID="rearSeatLegRoom">





  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>



<rdf:Property rdf:ID="rearSeatLegRoom">



  <rdfs:domain rdf:resource="#PassengerVehicle"/> 



  <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/>

</rdf:Description>





  <rdfs:range rdf:resource="&xsd;integer"/>





<rdf:Description rdf:ID="Person">



</rdf:Property>



deleted text: 

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

</rdf:Description>






<rdfs:Class rdf:ID="Person"/>



deleted text: 

<rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#integer">



deleted text: 

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





</rdf:Description>



<rdfs:Datatype rdf:about="&xsd;integer"/>

Note that deleted text: we have not used an <tt> <rdf:RDF> </tt> element is not used in <a href="#example19"> Example 19 </a> 26 , because we have it is assumed deleted text: we are adding this RDF/XML is being added to the vehicle schema deleted text: we described earlier, identified by <tt> http://example.org/schemas/vehicles </tt>. in Example 24 . This same assumption also allows us to the use of relative URIrefs like <tt> #MotorVehicle </tt> to refer to other classes from that schema.

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

ex:driver  rdf:type  rdf:Property .



ex:driver          rdf:type             rdf:Property .





ex:primaryDriver  rdf:type  rdf:Property .



ex:primaryDriver   rdf:type             rdf:Property .





ex:primaryDriver  rdfs:subPropertyOf  ex:driver .



ex:primaryDriver   rdfs:subPropertyOf   ex:driver .

The meaning of the <tt> this rdfs:subPropertyOf </tt> relationship is that if an instance <tt> ex:fred </tt> exstaff:fred is an <tt> ex:primaryDriver </tt> of the instance <tt> ex:companyVan </tt>, , then <tt> ex:fred </tt> is implicitly considered to RDF Schema defines exstaff:fred as also be being an <tt> ex:primaryDriver </tt> ex:driver of <tt> ex:companyVan </tt>. . The RDF/XML describing these properties (assuming again that we are adding this it is being added to the vehicle schema deleted text: we described earlier) in Example 24 ) is shown in <a href="#example20"> Example 20 27 .

<rdf:Description rdf:ID="driver">

  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>



<rdf:Property rdf:ID="driver">



  <rdfs:domain rdf:resource="#MotorVehicle"/>



</rdf:Description>




</rdf:Property>




deleted text: 

<rdf:Description rdf:ID="primaryDriver">





  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>



<rdf:Property rdf:ID="primaryDriver">



  <rdfs:subPropertyOf rdf:resource="#driver"/>



</rdf:Description>



</rdf:Property>

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

<a href="#example1"> Example 21 28 shows the RDF/XML for the full vehicle schema, containing all the descriptions deleted text: we've given so far:

<?xml version="1.0"?>



<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>



<rdf:RDF   

  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  

  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

  xml:base="http://example.org/schemas/vehicles">





<rdf:Description rdf:ID="MotorVehicle">

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

</rdf:Description>




<rdfs:Class rdf:ID="MotorVehicle"/>




deleted text: 

<rdf:Description rdf:ID="PassengerVehicle">





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



<rdfs:Class rdf:ID="PassengerVehicle">



  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>



</rdf:Description>




</rdfs:Class>




deleted text: 

<rdf:Description rdf:ID="Truck">





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



<rdfs:Class rdf:ID="Truck">



  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>



</rdf:Description>



</rdfs:Class>







<rdf:Description rdf:ID="Van">

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



<rdfs:Class rdf:ID="Van">



  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>



</rdf:Description>




</rdfs:Class>




deleted text: 

<rdf:Description rdf:ID="MiniVan">





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



<rdfs:Class rdf:ID="MiniVan">



  <rdfs:subClassOf rdf:resource="#Van"/>

  <rdfs:subClassOf rdf:resource="#PassengerVehicle"/>



</rdf:Description>



<rdf:Description rdf:ID="Person">

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

</rdf:Description>



</rdfs:Class>







<rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#integer">



<rdfs:Class rdf:ID="Person"/>



deleted text: 

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



deleted text: 

</rdf:Description>





<rdfs:Datatype rdf:about="&xsd;integer"/>




deleted text: 

<rdf:Description rdf:ID="registeredTo">





  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>



<rdf:Property rdf:ID="registeredTo">



  <rdfs:domain rdf:resource="#MotorVehicle"/>

  <rdfs:range rdf:resource="#Person"/>



</rdf:Description>




</rdf:Property>




deleted text: 

<rdf:Description rdf:ID="rearSeatLegRoom">





  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>



<rdf:Property rdf:ID="rearSeatLegRoom">



  <rdfs:domain rdf:resource="#PassengerVehicle"/> 



  <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/>

</rdf:Description>



  <rdfs:range rdf:resource="&xsd;integer"/>





</rdf:Property>




deleted text: 

<rdf:Description rdf:ID="driver">





  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>



<rdf:Property rdf:ID="driver">



  <rdfs:domain rdf:resource="#MotorVehicle"/>



</rdf:Description>




</rdf:Property>




deleted text: 

<rdf:Description rdf:ID="primaryDriver">





  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>



<rdf:Property rdf:ID="primaryDriver">



  <rdfs:subPropertyOf rdf:resource="#driver"/>



</rdf:Description>



</rdf:Property>





</rdf:RDF>

Now that we've Having shown how to describe classes and properties using RDF Schema, deleted text: we can see what instances corresponding to using those descriptions might look like. classes and properties can now be illustrated. For example, <a href="#example22"> Example 22 29 describes an instance of the <tt> ex:PassengerVehicle </tt> class deleted text: we described above, in Example 28 , together with some hypothetical values for its properties.

  <?xml version="1.0"?>



<?xml version="1.0"?>





  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"



<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>





              xmlns:ex="http://example.org/schemas/vehicles">



<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"





            xmlns:ex="http://example.org/schemas/vehicles#"





            xml:base="http://example.org/things">



deleted text: 

    <rdf:Description rdf:ID="johnSmithsCar">



deleted text: 

         <rdf:type rdf:resource="http://example.org/schemas/vehicles#PassengerVehicle"/>





         <ex:registeredTo rdf:resource="http://www.example.org/staffid/85740"/>



  <ex:PassengerVehicle rdf:ID="johnSmithsCar">





         <ex:rearSeatLegRoom 



       <ex:registeredTo rdf:resource="http://www.example.org/staffid/85740"/>





             rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">127</ex:rearSeatLegRoom>



       <ex:rearSeatLegRoom 





         <ex:primaryDriver rdf:resource="http://www.example.org/staffid/85740"/>



           rdf:datatype="&xsd;integer">127</ex:rearSeatLegRoom>





    </rdf:Description>



       <ex:primaryDriver rdf:resource="http://www.example.org/staffid/85740"/>





  </rdf:RDF>



  </ex:PassengerVehicle>

</rdf:RDF>

Note that deleted text: we can use an <tt> ex:registeredTo </tt> property can be used in describing this instance of <tt> ex:PassengerVehicle </tt>, , because <tt> ex:PassengerVehicle </tt> is a subclass of <tt> ex:MotorVehicle </tt>. . Note also that deleted text: we use a typed literal is used for the value of the <tt> ex:rearSetLegRoom </tt> property in our this instance, rather than a plain literal (i.e., we didn't say <tt> rather than stating the value as <ex:rearSeatLegRoom>127</ex:rearSeatLegRoom> </tt> ). Because the schema describes the range of this property as an <tt> xsd:integer </tt>, , the value of the property must should be a typed literal of that datatype in order to match the range description (i.e., the range declaration does not automatically "assign" a datatype to a plain literal). </p> <p> As we discussed in <a href="#newresources"> Section 3.2 </a>, the RDF/XML syntax provides an abbreviation for instances defined as members of classes using the <tt> rdf:type </tt> property. Using this abbreviation, we could describe this same instance as shown in <a href="#example23"> Example 23 </a>: </p> <div class="exampleOuter"> <div class="c1"> <a id="example23" name="example23"> Example 23: An Abbreviation of the Instance from Example 22 </a> </div> <div class="exampleInner"> <pre> <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://example.org/schemas/vehicles"> <ex:PassengerVehicle rdf:ID="johnSmithsCar"> <ex:registeredTo rdf:resource="http://www.example.org/staffid/85740"/> <ex:rearSeatLegRoom rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">127</ex:rearSeatLegRoom> <ex:primaryDriver rdf:resource="http://www.example.org/staffid/85740"/> </ex:PassengerVehicle> </rdf:RDF> </pre> </div> </div> <p> In <a href="#example23"> Example 23 </a> the class is identified by an element name ( <tt> ex:PasssengerVehicle </tt> ) rather than as the value of an <tt> rdf:resource </tt> attribute, literal, and so deleted text: we can abbreviate it with the QName <tt> ex:PasssengerVehicle </tt> rather than writing it as a full URIref as we did in typed literal of the earlier form. appropriate datatype must be explicitly provided).

5.3 Interpreting RDF Schema Declarations

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

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

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

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

Another result of the global scope of RDF property descriptions is that it is not possible in an RDF schema to define a specific property as having locally-different ranges depending on the class of the resource it is applied to. For example, in defining the property ex:hasParent , it would be desirable to be able to say that if the property is used to describe a resource of class ex:Human , then the range of the property is also a resource of class ex:Human , while if the property is used to describe a resource of class ex:Tiger , then the range of the property is also a resource of class ex:Tiger . This kind of definition is not possible in RDF Schema. Instead, any range defined for an RDF property applies to all uses of the property, and so ranges should be defined with care. However, while such locally-different ranges cannot be defined in RDF Schema, they can be defined in some of the richer schema languages discussed in Section 5.5 .

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

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

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

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

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

5.4 Other Schema Information

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

As with a number of the built-in RDF properties such as rdf:value , the uses described for these RDF Schema properties are only their intended uses. [RDF-SEMANTICS] defines no special meanings for these properties, and RDF Schema does not define any constraints based on these intended uses. For example, there is no constraint specified that the object of a rdfs:seeAlso property must provide additional information about the subject of the statement in which it appears.

5.5 Richer Schema Languages

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

• cardinality constraints on properties, e.g., that a Person has exactly one biological father.
• specifying that a given property (such as <tt> hasAncestor </tt> ex:hasAncestor ) is transitive , e.g., that if A <tt> hasAncestor </tt> ex:hasAncestor B, and B <tt> hasAncestor </tt> ex:hasAncestor C, then A <tt> hasAncestor </tt> ex:hasAncestor C.
• specifying that a given property is a unique identifier (or key ) for instances of a particular class.
• specifying that two different classes (having different URIrefs) actually represent the same concept. class.
• specifying that two different instances (having different URIrefs) actually represent the same individual.
• specifying constraints on the range or cardinality of a property that depend on the class of resource to which a property is applied, e.g., being able to say that for a soccer team the ex:hasPlayers property has 11 values, while for a basketball team the same property should have only 5 values.
• the ability to describe new classes in terms of combinations (e.g., unions and intersections) of other classes, or to say that two classes are disjoint (i.e., that no resource is an instance of both classes).