RDF Primer

2.1 Identifiers: Uniform Resource Identifier (URI)

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

As we've seen, the Web already provides one form of identifier, the Uniform Resource Locator (URL). We used a URL in our original example to identify the Web page that John Smith created. A URL is a string that identifies a Web resource by representing its primary access mechanism (essentially, its network "location"). However, we would like to be able to record information about many things in addition to Web pages. In particular, we'd like to record information about lots of things that don't have URLs. For example, I don't have a URL, and yet my employer needs to record all sorts of things about me in order to pay my salary, keep track of the work that I've been doing, and so on. My doctor needs to record other sorts of things about me in order to keep track of my medical history, tests that have been performed (and the results, who performed them, and when), shots I've received, etc.

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

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

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

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

@@Introduce additional URI schemes explicitly: URNs, mailto:; then can talk about freenet better. Cite the W3C page on addressing: http://www.w3.org/Addressing/, and on registered addressing schemes: http://www.w3.org/Addressing/schemes.html@@

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

2.2 Documents: Extensible Markup Language (XML)

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

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

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

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

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

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

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

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

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

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

2.3 The RDF Model

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

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

by an RDF statement having:

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

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

Figure 1: A Simple RDF Statement

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

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

we could, introducing suitable URIs to name the properties "creation-date" and "language", use the following graph:

Figure 2: Several Statements About the Same Resource

This graph illustrates that RDF permits the objects in statements to be simple strings, if necessary to represent property values, as well as URIs. In drawing RDF graphs, nodes that represent URIs are shown as ellipses, while nodes that represent strings are shown as boxes. RDF graphs are technically "labeled directed graphs", since the arcs have labels, and are "directed" (point in a specific direction, from subject to object).

Sometimes it is not convenient to draw graphs, so an alternative way of writing down the statements, called N-Triples, can also be used. In the N-Triples notation, each statement in the graph is written as a simple triple of subject, predicate, and object, in that order. The N-Triples representing the above three statements would be written:

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

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

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

Each triple corresponds to a single arc in the graph, complete with the arc's beginning and ending nodes (the subject and object of the statement). Unlike the drawn graph, the N-Triples notation requires that a node be separately identified for each statement it appears in. So, for example, http://www.example.org/index.html appears three times (once in each triple) in the N-Triples representation of the graph, but only once in the drawn graph.

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

Figure 3: More Information about John Smith

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

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

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

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

As a result, RDF provides a way to make statements that applications can more easily process. Now an application can't actually "understand" such statements, of course, but it can deal with them in a way that makes it seem like it does. For example, a user could search the Web for all book reviews and create an average rating for each book. Then, the user could put that information back on the Web. Another web site could take that information (the list of book rating averages) and create a "Top Ten Highest Rated Books" page.

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

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

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

2.4 Structured Property Values

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

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

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

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

Figure 4: Breaking Up John's Address

or the N-Triples:

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

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

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

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

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

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

Figure 5: Using a Blank Node

In this drawing, which is a perfectly good RDF graph, we've used a node without a label to stand for the concept of "John Smith's address". This unlabeled node, or blank node, functions perfectly well in the drawing without needing a URI. However, we do need some form of explicit identifier for that node in order to represent this graph as N-Triples. To see this, we can try to write the N-Triples corresponding to what is shown in the drawn graph. What we would get would be something like:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1. Defining Classes

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

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

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

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

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

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

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

Figure 9: A Simple Class Hierarchy

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

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

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

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

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

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

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

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

</rdf:RDF>

4.2. Defining Properties

Properties are defined using the pre-defined resource rdf:Property, and the pre-defined properties rdfs:domain, rdfs:range, and rdfs:subPropertyOf.

All properties in RDF are defined as instances of the predefined class rdf:Property. A new property, such as weightInKg, is defined by creating an RDF resource to represent the new property, and giving it an rdf:type property whose value is the pre-defined resource rdf:Property.

RDF Schema also provides a mechanism for specifying simple constraints on the use of properties and classes in RDF data. The basic constraints are those that describe limitations on the types of values that are valid for some property, or on the classes to which it makes sense to assign such properties. Specifically:

• A range constraint specifies that the value of a property should be a resource of a designated class. For example, a range constraint applied to the author property might specify that the value of an author property must be a resource of class Person.
• A domain constraint specifies that a property may be used on resources of a certain class. For example, a domain constraint applied to the author property might specify that the author property could only originate from a resource that was an instance of class Book.

Domain and range constraints are specified using the predefined RDF properties rdfs:range and rdfs:domain.

The rdfs:range property is used to indicate the class(es) that the values of a property must be members of. The value of a rdfs:range property is always a rdfs:Class. Range constraints are only applied to properties.

A property may have zero, one, or more than one range property. If there is no range property, the class of the property value is unconstrained. If there is exactly one range property, the property value must be an instance of the specified class that is the value of the range property. If there is more than one range property, the property value must be an instance of all of the classes that are values of those range properties. For example, if we assert that property xyz:hasMother has both a rdfs:range of Female and an rdfs:range of Person, this means that any value of property xyz:hasMother must be both an instance of class Female and an instance of class Person.

The rdfs:domain property is used to indicate the class(es) on whose members some specified property can be used. As with the rdfs:range property, the value of a rdfs:domain property is always a rdfs:Class, and domain constraints are only applied to properties.

A property may have zero, one, or more than one domain property. If there is no domain property, the property may be used with any resource. If there is exactly one domain property, the property may only be used on resources that are instances of the specified class that is the value of the domain property. If there is more than one domain property, the property can only be used on resources that are instances of all of the classes that are values of those domain properties.

We can illustrate the use of these constraint properties by continuing with our earlier example of MotorVehicle. In this example, we define two properties: registeredTo and rearSeatLegRoom. The registeredTo property is applicable to any MotorVehicle and its value is a Person. For the sake of this example, rearSeatLegRoom only applies to instances of class PassengerVehicle. The value is a Number, which is the number of centimeters of rear seat legroom (we assume that the classes for Person and Number are defined elsewhere>). These definitions are shown in the RDF/XML below:

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

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

<rdf:Description rdf:ID="rearSeatLegRoom">
  <rdf:type resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
  <rdfs:domain rdf:resource="#PassengerVehicle"/> 
  <rdfs:range rdf:resource="http://www.w3.org/2000/03/example/classes#Number"/>
</rdf:Description>

</rdf:RDF>

As noted earlier, the RDF Schema type system is similar to the type systems of object-oriented programming languages such as Java. However, RDF differs from many programming language type systems in that instead of defining a class in terms of the properties its instances may have, an RDF schema defines properties in terms of the classes of resource to which they apply. The classes of resource to which properties apply are specified using domain and range constraints on the properties. For example, a classical object-oriented programming language might define a class Tent having an attribute called packedSize of type Literal. A corresponding RDF schema would define a class Tent, and a property packedSize having a domain of Tent and a range of Literal.

The difference between these approaches may not be immediately obvious, but it can be significant. In the programming language class definition, the attribute packedSize is part of the definition of class Tent, and applies only to instances of class Tent. Another class might also have an attribute called packedSize, but this would be considered a separate attribute. In other words, the scope of attribute definitions in most programming languages is restricted to the type in which they are defined. In RDF, on the other hand, property definitions are, by default, independent of class definitions, and have, by default, global scope (althought they may optionally be restricted to apply only to certain classes using domain constraints). So, for example, an RDF schema could define a property packedSize without a domain constraint. This property could then be used to describe instances of any class that might be considered to have a packed size. 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 by the original definer, provided the properties have not been made overly specific by domain constraints. (Of course, this is a "benefit" which must be used with care, to insure that properties are not mis-applied in inappropriate situations.)

Although RDF Schema provides a mechanism for describing constraints such as domain and range constraints, it does not say whether or how an application must process the constraint information. For example, while an RDF schema might assert that an author property is used to indicate resources that are members of the class Person, it does not say whether or how an application should act in processing that class information. Different applications might use these constraints in different ways - e.g., a validator will look for errors, an interactive editor might suggest legal values, and a reasoning application might infer the class from other information and then announce any inconsistencies.

Now that we've shown how to define classes and properties using RDF Schema, we can see what instances corresponding to those definitions might look like. For example, the following is an instance of the PassengerVehicle class we defined above (which we assume is being defined in the same document as the schema), together with some hypothetical values for its registeredTo and rearSeatLegRoom properties. Note the use of the rdf:type property to indicate its class membership. Also note how we can apply a registeredTo property to this instance of PassengerVehicle, because PassengerVehicle is a subclass of MotorVehicle.

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

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

The RDF/XML syntax provides a special abbreviation for instances defined as members of classes using the rdf:type property. In this abbrevation, the rdf:type property and value are removed, and the rdf:Description element name is replaced by the class name. Using this abbreviation, John's car from the example above could also be defined as:

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

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

RDF Schema provides a way to specialize properties as well as classes. The property rdfs:subPropertyOf can be used to specify that one property is a specialization of another. A property may be a specialization of zero, one or more properties. If some property P2 is a subPropertyOf another more general property P1, and if a resource A has a P2 property with a value B, this implies that the resource A also has a P1 property with value B. All RDF rdfs:range and rdfs:domain properties that apply to an RDF property also apply to each of its sub-properties.

As an example, if the property biologicalFather is a subproperty of the broader property biologicalParent, and if Fred is the biologicalFather of John, then it is implied that Fred is also the biologicalParent of John.

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

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

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

</rdf:RDF>

4.3. Other Schema Information

RDF Schema also defines a number of other properties, which can be used to provide documentation and other information about an RDF schema or about instances. For example the rdfs:comment property can be used to provide a human-readable description of a resource. The rdfs:label property can be used to provide a more human-readable version of a resource's name. The rdfs:seeAlso property can be used to indicate a resource that might provide additional information about the subject resource. The rdfs:isDefinedBy property is a subproperty of rdfs:seeAlso, and can be used to indicate the resource that defines the subject resource. For further discussion of the use of these properties, you should consult the RDF Schema Specification.

4.4. Richer Schema Languages

RDF Schema provides basic capabilities for defining 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. For example, there is currently no way in RDF to indicate that the value of a Person's "age" property must be an integer (number of years); all literal values in RDF are currently strings (although an application is free to interpret a string "25" given as the value of an "age" property as being a number, RDF itself does not define this as the proper interpretation, or enforce this as a constraint when entering the value). An RDF Datatyping specification is currently under development, and may become part of the RDF specifications at some future time.

Other richer schema capabilities have also been identified as useful. For example:

• cardinality constraints on properties, e.g., that a Person has exactly one father.
• that a given property (such as hasAncestor) is transitive, e.g., that if A hasAncestor B, and B hasAncestor C, then A hasAncestor C.
• that two different classes, defined in separate schemas, actually represent the same concept.
• that two different instances, defined separately, actually represent the same individual.
• the ability to define new classes in terms of combinations (e.g., unions and intersections) of other classes.

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

@@The above could clearly be developed a great deal further!@@

6.1 Dublin Core Metadata Initiative

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

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

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

Here is a description of a Web site home page using Dublin Core properties:

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

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

The second example describes a published magazine.

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

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

The third example is of a specific article in the magazine referred to in the previous example.

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

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

6.2 PRISM

@@TBD@@

6.3 XPackage

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

The XPackage framework is based upon XML, RDF, and XLink, and provides two RDF vocabularies: one for general packaging descriptions, and another for describing XML-based resources. Although XPackage is an application of RDF, the package description document is defined by an XML Schema. This allows XPackage to be implemented as a general XML application without an RDF processor, while still maintaining RDF compliance of conforming documents. The XPackage framework also allows customization through extension and/or restriction.

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

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

    (description of individual resources go here)

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

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

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

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

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

The full version of this example may be found in the XML Package specification.

6.4 Intelligent Routing

The world is full of information. Behind the millions of pages on the Internet's publicly visible part, the Web, there are many times as many documents flowing in and out of organizations via emails, cross-company networks and constant always-on information "feeds".

Every document that passes along the wires has to be inspected, processed or re-routed. A document simply written by one human being has to be read by another before anybody knows its worth or where it should be redirected. This is fine for a person-to-person email but, for information destined to a broad circulation, this can be expensive, often reducing the value of the information by raising its handling cost or simply making it late.

For example, when an individual subscribes to a source of news, it's usually on the understanding that everything in that feed is of interest and so everything will be delivered without question. For the distributor to sort out the interesting ones for you manually would be time-consuming, expensive and boring; so instead we accept dozens of emails and delete most of them every morning. And of course it is time-consuming, expensive and boring. Subscription to some less self-critical sources is a step to be taken very seriously.

When a company subscribes to a news feed, it may be risking a deluge of unwanted data. If it intends to circulate the information within the company or to a broad range of clients, it charges itself with checking every document by eye or investing in extra software technology. Without such protection, the company's networks will soon collapse under the load or its clients will consider themselves willfully "spammed" and withdraw their custom.

The redirection of such feeds is therefore a matter of utmost commercial sensitivity in a context of huge and increasing volumes and complexity of data. The technology concerned is "routing" and, in the most modern cases, relies on RDF.

The need, traditionally, for human inspection of incoming documents comes from the fact that, on its own, text has no value. It only has value when you know what it's about, what authority is its source and who it's intended for. Everything else is, as we know, just material for spamming. For a software agent to recognize a document's worth it must have access to an evaluation that is consistently readable, whatever the format of the document, and is reliable in its description.

For those two objectives, we need an internationally standardized language and a globally recognized set of values. These are RDF, together with RDF Schemas such as defined by Dublin Core and PRISM. The longed-for independent evaluation takes the form of an associated RDF document.

Not that every document from every information source comes with its associated RDF description... yet. It is the case however that almost every serious source supplies some value-based annotation in the form of metadata, the significant content of RDF. For example, news feeds generally come in one of a selection of annotated formats, mostly based on XML, such as NewsML or XMLNews. Most standards-oriented companies are adding freely-accessible metadata to their document formats. Adobe, for example, recently announced XMP whereby metadata can be inserted into (and more importantly extracted from) PDF documents. The message from such companies is that, even if you can't understand or even have no right to read the contents, you are entitled to know enough to make an evaluation for your own use or for clients who can use the information. For freely available information, standards are the key.

Now this basic process (source embeds standard annotations: annotations are used to divert and sort documents) is certainly not new. Email (SMTP) and news (NNTP) protocols use standard keyword-value-pair headers which are fundamental to their operation: such documents are marked up according to known and publicized standards. What is new is to normalize all these local formats to a general one and thereby be able to appeal to a globally consistent set of values in making judgments.

For a universal router to do its job, it needs to cancel out these variations in format. Until the world adopts one standard, this will be a matter of tact and ingenuity but the existence of a core standard is important here. When a slew of formats and value-systems need to be compared it is safer to have one standard to convert to first and then to compare rather than do it piecemeal - and that standard must be broader than all the others. Again, RDF (and RDF Schemas) standards are the natural choice.

An Information Router collects metadata and stores it (rather like an enormous RDF document describing maybe millions of resources at once). This metadata store holds the descriptions in exactly the terms of RDF. They can therefore be exported or imported as industry-standard RDF without loss or confusion. World-wide, repositories of metadata may be synchronized and refreshed by exchanging RDF. While humans are exchanging images, videos and news items, metadata servers are exchanging compact RDF evaluations of them (the images, videos and news items, not the humans).

The actual documents described, orders of magnitude larger than the metadata, can be stored elsewhere or just left where they are (located by URI, of course). The metadata is compact and loaded with value. Judgments about distributing material can be made in a context values (the standard predicate systems like Dublin Core) and a vast number of alternatives, all without moving the actual documents around or indeed even looking at them, by computer or by human eye.

Judgments are made by applying RDF "queries" which are testing the value of a document to the reader: whether the subject is interesting, the content is suitable, the author respected, the source reliable, the document accessible, the cost reasonable, the language intelligible, the conclusion desirable, the format tractable, the medium handleable, etc., etc. The actual form of a query varies from product to product. (In any case, the consumer would be given a graphical way to express his wishes.)

In one case, a query takes the form of a modified RDF description which, if you like, asks to be proved or disproved by a body of metadata. So an RDF Description that stated that a document exists with the title "Financial history of Belize" can be viewed as a request to find such a document.

The news distributor's server runs, in addition to the usual server software, one of these Information Router packages, applies queries on behalf of its clients and delivers just those documents that survive the evaluation.

If a complex multi-layered query describing just what it takes to please you is associated with your name as a subscriber, you can, using software available today, guarantee that what you get sent is exactly and only what you need. It's an end to spam, thanks to RDF.

6.5 RSS: RDF Site Summary 1.0

@@ TBD @@

XMP

@@ possible additional section@@

Site Maps / Topic Maps

@@ possible additional section @@