Frank Manola, The MITRE Corporation, fmanola@mitre.org
Copyright©2001,2002W3C®(MIT,INRIA,Keio), All Rights Reserved. W3Cliability,trademark,document useandsoftware licensingrules apply.
The Resource Description Framework (RDF) is a general-purpose language for representing information in the World Wide Web. It is particularly intended for representing metadata about Web resources, such as the title, author, and modification date of a Web page, the copyright and syndication information about a Web document, the availability schedule for some shared resource, or the description of a Web user's preferences for information delivery. RDF provides a common framework for expressing this information in such a way that it can be exchanged between applications without loss of meaning. Since it is a common framework, application designers can leverage the availability of common RDF parsers and processing tools. Exchanging information between different applications means that the information may be made available to applications other than those for which it was originally created. This Primer is designed to provide the reader the basic fundamentals required to effectively use RDF in their particular applications.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use it as reference material or to cite it as other than "work in progress".
@@ toc goes here @@
The Resource Description Framework (RDF) is a general-purpose language for representing information in the World Wide Web. It is particularly intended for representing metadata about Web resources, such as the title, author, and modification date of a Web page, the copyright and syndication information about a Web document, the availability schedule for some shared resource, or the description of a Web user's preferences for information delivery. However, by generalizing the concept of a "Web resource", RDF can be used to represent information about anything that can be identified on the Web, such as information about items available from online shopping facilities (e.g., information about prices, publishers, and availability of books or recordings).
RDF provides a common framework for expressing this information in such a way that it can be exchanged between applications without loss of meaning. Since it is a common framework, application designers can leverage the availability of common RDF parsers and processing tools. Exchanging information between different applications means that the information may be made available to applications other than those for which it was originally created.
This Primer is intended to augment the RDF specifications @@references@@, to help information system designers and application developers understand the features of RDF, and how to use them. In particular, the Primer answers such questions as:
To make this discussion somewhat more concrete as soon as possible, the following is a small chunk of RDF in its XML serialization format.
This example roughly translates as "there is someone called Eric Miller, with the email address em@w3.org, and who is the Semantic Web Activity Lead". Note that the example contains what seem to be Web addresses, as well as some "properties" like "mailbox" and "fullName", and the values "em@w3.org", and "Eric Miller".
Like HTML, this form of information is machine processable, and links pieces of data acorss the Web. However, unlike conventional hypertext, RDF links can also be to any identifiable things, including things that may or may not be Web-based data. The result is that in addition to describing Web pages, we can also convey information about cars, businesses, people, news events, etc. Further, RDF links themselves can be labeled, to indicate the kind of relationship that exists between the linked items.
RDF is intended to provide a simple way to state properties of (facts about) Web resources, e.g., Web pages. For example, imagine that we want to record the fact that someone named John Smith created a particular Web page. A straightforward way to state this fact in English would be in the form of a simple statement, e.g.:
Thecreatorofhttp://www.foobar.org/index.htmlisJohn
Smith
We've underlined parts of this statement to illustrate that, in order to describe the properties of something, we need ways to name, or identify, a number of things:
In this statement, we've used the Web page's URL (Uniform Resource Locator) to identify it. In addition, we've used the word ``creator'' to identify the property we want to talk about, and the two words ``John Smith'' to identify the thing (a person) we want to say is the value of this property.
We could state other properties of this Web page by writing additional English statements of the same general form, using the URL to identify the page, and words (or other expressions) to identify the properties and their values. For example, to specify the date the page was created, and the language in which the page is written, we could write the additional statements, e.g.:
The creation-date ofhttp://www.foobar.org/index.htmlis
August 16, 1999
The language ofhttp://www.foobar.org/index.htmlis
English
(note the use of "August 16, 1999" to identify a date).
RDF is based on the idea that the things we want to describe have properties which have values, and that resources can be described by making statements, similar to those above, that specify those properties and values. RDF uses a particular terminology for talking about the various parts of statements. Specifically, the part that identifies the thing the statement is about (the Web page in this example) is called the subject . The part that identifies the property or characteristic of the subject that the statement specifies (creator, creation-date, or language in this case) is called the predicate, and the part that identifies the value of that property is called the object. So, taking the English statement
The creator ofhttp://www.foobar.org/index.htmlis
John Smith
the RDF terms for the various parts of the statement are:
However, while English is good for communicating between
(English-speaking) humans, RDF is about making machine-processable
statements. To make these kinds of statements suitable for processing by
machines, we need two things:
Fortunately, the existing Web architecture provides us with both of the
necessary mechanisms. The Web's Uniform Resource Identifier (URI) provides us
with a way to uniquely identify anything we want to talk about in an RDF
statement, and the Extensible Markup Language (XML) provides us with a format
for representing and exchanging RDF statements. The next two sections briefly
describe these mechanisms.
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", "todays weather", etc., and ambiguities are generally resolved due to 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
URIs essentially constitute an infinite stock of names that can be used to
identify things. No one person or organization controls who makes URIs or
how they can be used. While some URI schemes (such as URL's
http:) depend on centralized systems (such as DNS), other
schemes (such as freenet:) are completely decentralized. This
means that (as with any other kind of name), you
don't need special authority or permission to create a URI for something, and
you can create URIs for things you don't own (just as you can use whatever
name you like for things you don't own in ordinary language). The URI is
the foundation of the Web. While nearly every other part of the Web can be
replaced, the URI cannot: it holds the Web together.
Since the URI is such a general identification mechanism, capable of
identifying anything, it should not be surprising that RDF uses URIs as its
mechanism for identifying the subjects, objects, and predicates in
statements. In fact, RDF defines a resource as anything that is
identifiable by a URI, and hence using URIs allows RDF to describe
practically anything, and to state relationships between such things as well.
We'll see how this works just a bit further on. But before we do that, we
need to introduce a way for RDF statements to be physically represented and
exchanged.
@@better segue needed?@@
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, andmarkup in the form of tags. This markup allows a processing program to interpret the various pieces of content (elements). In HTML, the set of permissable 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:
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.
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, as in: @@ reference The Professor and the Madman? @@
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.
@@fm: I've left this XML material in (after some editing) for the moment, but it's still pretty rough.@@
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:
The creator ofhttp://www.foobar.org/index.htmlis
John Smith
by an RDF statement having:
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
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
The creation-date ofhttp://www.foobar.org/index.htmlis
August 16, 1999
The language ofhttp://www.foobar.org/index.htmlis
English
we could, introducing suitable URIs for the predicates "creation-date" and "language", use the following graph:
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 Ntriples , can also be used. In the Ntriples notation, each statement in the graph is written as a simple triple of subject, predicate, and object, in that order. The Ntriples representing the above three statements would be written:
<http://www.foobar.org/index.html> <http://purl.org/dc/elements/1.1/creator>
<http://www.foobar.org/staffid/85740> .
<http://www.foobar.org/index.html>
<http://www.foobar.org/terms/creation-date> "August 16, 1999" .
<http://www.foobar.org/index.html>
<http://www.foobar.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 triple notation requires that a node be separately identified for each statement it appears in. So, for example, http://www.foobar.org/index.html appears three times (once in each triple) in the triple 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.foobar.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
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, foobar.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 foobar.org writes http://www.foobar.org/terms/name for its ``name'' property, and the other person writes http://geneology.org/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 foobar.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 Ntriple
<http://www.foobar.org/index.html> <http://purl.org/dc/elements/1.1/creator> <http://www.foobar.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.foobar.org/index.html ) and the creator of the page (a distinct person, identified by http://www.foobar.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 are machine-processable. Now the computer can't actually "understand" what you said, of course, but it can deal with it in a way that makes it seem like it does. For example, I could search the Web for all book reviews and create an average rating for each book. Then, I could put that information back on the Web. Another website could take that information (the list of book rating averages) and create a "Top Ten Highest Rated Books" page. RDF provides a way of recording knowledge so that applications can more easily process. @@want to modify this para a bit@@
RDF statements are similar to a number of other formats for recording information, such as:
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 Ntriple
However, suppose we wanted to record the various pieces of information about his address as separate street, city, state, and Zip code values? How do we do this using RDF?
In RDF, we can represent such structured information 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.foobar.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:
Breaking Up John's Address
or the Ntriples:
<http://www.foobar.org/staffid/85740>
<http://www.foobar.org/terms/address>
<http://www.foobar.org/addressid/85740> .
<http://www.foobar.org/addressid/85740>
<http://www.foobar.org/terms/street> "1501 Grant Avenue" .
<http://www.foobar.org/addressid/85740>
<http://www.foobar.org/terms/city> "Bedford" .
<http://www.foobar.org/addressid/85740>
<http://www.foobar.org/terms/state> "Massachusetts" .
<http://www.foobar.org/addressid/85740>
<http://www.foobar.org/terms/Zip> "01730" .
In the drawing of the graph above, the new URI we assigned to identify "John Smith's address" reallyserves no purpose, since we could just as easily have drawn the graph
Using a bNode
In this drawing, which is perfectly good RDF, we've used a node without a label to stand for the concept of "John Smith's address". This unlabeled node, or bNode (for 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 Ntriples. To see this, we can try to write the Ntriples corresponding to what is shown in the drawn graph. What we would get would be something like:
<http://www.foobar.org/staffid/85740>
<http://www.foobar.org/terms/address> ??? .
???
<http://www.foobar.org/terms/street> "1501 Grant Avenue" .
???
<http://www.foobar.org/terms/city> "Bedford" .
???
<http://www.foobar.org/terms/state> "Massachusetts" .
???
<http://www.foobar.org/terms/Zip> "01730" .
where ??? stands for something that indicates the presence of the bNode. Since in a complex graph there might be more than one such bNode, we also need a way to differentiate between the various bNodes in the corresponding Ntriples representation. To do this, the Ntriples notation uses a concept of node identifiers (or nodeIDs) to identify bNodes. These are temporary identifiers distinct from URIs (and having their own syntax in Ntriples) that are used to indicate the presence of bNodes in the Ntriples representation. In this example, we might generate the node identifier _:johnaddress to refer to the bNode, in which case the resulting triples might be:
<http://www.foobar.org/staffid/85740> <http://www.foobar.org/terms/address>
_:johnaddress .
_:johnaddress
<http://www.foobar.org/terms/street> "1501 Grant Avenue" .
_:johnaddress
<http://www.foobar.org/terms/city> "Bedford" .
_:johnaddress
<http://www.foobar.org/terms/state> "Massachusetts" .
_:johnaddress
<http://www.foobar.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 "city" and the predicate "creator" is evident. The basis for such vocabularies in RDF is RDF Schema, which will be described in Section 4.
To summarize what we've said already, RDF models statements in terms of a graph consisting of nodes and arcs. The nodes describe resources that can be labelled with URIs, string literals or are blank. The arcs connect the nodes and are all labelled with URIs. This graph is more precisely called a directed edge-labelled graph; each edge is an arc with a direction (an arrow) connecting two nodes. These edges can also be described as triples of subject node, at the blunt end of the arrow/arc, property arc and an object node at the sharp end of the arrow/arc. The property arc is interpreted as an attribute, relationship or predicate of the resource, with a value given by the object node content.
RDF also defines an XML syntax for writing down and exchanging RDF graphs. This syntax is defined in theDF/XML Syntax Specification. In order to encode the graph in XML, the nodes and arcs are turned into XML elements, attributes, element content and attribute values. The URI labels for properties and object nodes are written in XML using XML Namespaces ([XML-NS]) which gives a namespace URI for a short prefix along with namespace-qualified elements and attributes names called local names. The (namespace URI, local name) pair are chosen such that concatenating them forms the original node URI. The URIs labelling subject nodes are stored in XML attribute values. The nodes labelled by string literals (which are always object nodes) become element text content or attribute values.
This transformation turns paths in the graph of the form Node, Arc, Node,
Arc, Node, Arc, ... into sequences of nested elements (elements inside
elements). This results in a striping when the elements are written
down; alternating between node elements
and property
elements. The Node at the start of the sequence is always a subject node
and turns into a containing element called an rdf:Description
that is written at the top level of RDF/XML, after the XML document element
(in this case rdf:RDF). So the chains of stripes start at the
top of an RDF/XML document and always begin with nodes.
For example, the figure below shows a graph saying "there exists a document (identified by its URL) with a title, 'RDF/XML Syntax Specification (Revised)' and that document has an editor, the editor has a name "Dave Beckett" and a home page http://purl.org/net/dajobe/.
Graph for RDF/XML Example
If we take the path through the graph shown below:
One Path Through the Graph
this corresponds to the node/arc stripes:
http://www.w3.org/TR/rdf-syntax-grammarhttp://example.org/stuff/1.0/editor[a bNode]http://example.org/stuff/1.0/homepagehttp://purl.org/net/dajobe/In RDF/XML this sequence of 5 nodes and arcs correponds to 5 XML elements (using some namespace abbreviations)):
<rdf:Description>
<ex:editor>
<rdf:Description>
<ex:homePage>
<rdf:Description>
</rdf:Description>
</ex:homePage>
</rdf:Description>
</ex:editor>
</rdf:Description>
Which consists of some nodes with known URIs that can be filled in and others that remain blank:
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<ex:editor>
<rdf:Description>
<ex:homePage>
<rdf:Description rdf:about="http://purl.org/net/dajobe/">
</rdf:Description>
</ex:homePage>
</rdf:Description>
</ex:editor>
</rdf:Description>
There are several abbreviations that can be used to make very common uses
more easy to write down. For example, it is typical for the same resource to
be described with multiple properties and values at the same time, so
multiple child elements can be put inside rdf:Description, all
of which are properties of that node.
Similarly, when the property value is a string it can be encoded more simply as an XML attribute and value, as an attribute of the node element. This is known as a property attribute.
Another very common use is when a node is an instance of a class with
rdf:type relationship, usually called a typed node.
This shorthand is done by replacing the rdf:Description element
name with the namespaced-element corresponding to the URI of the value of the
type relationship.
The above forms the basis of the RDF/XML syntax. although there are some other abbreviated forms, such as for generating RDF list properties and for skipping having to write down a blank element node. This latter abbreviation breaks the striping, but is useful for, among other things, encoding properties with multiple values.
@@illustrate some of these examples more explicitly?
The full example above, filled out and completed, and using some of these additional abbreviations, gives:
<?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:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
<ex:editor rdf:parseType="Resource">
<ex:fullName>Dave Beckett</ex:fullName>
<ex:homePage rdf:resource="http://purl.org/net/dajobe/" />
</ex:editor>
</rdf:Description>
</rdf:RDF>
For a longer introduction to the RDF/XML striped syntax with a historical perspective, see RDF: Understanding the Striped RDF/XML Syntax ([STRIPEDRDF]).
Two kinds of tools are useful when learning RDF/XML: parsers and visualisers. The first such tool was Janne Sareela's SiRPAC; there are now a large number of RDF parsers available, in a variety of programming languages. An RDF parser is a tool that takes an XML encoding ("serialization") of an RDF graph, and returns a textual or programmatic representation of the graph. Playing with an RDF parser such as ARP, the parser used by W3C's RDF Validation Service makes it easy to experiment with RDF/XML files and see the associated node-edge-node triples that constitute the corresponding graph structure.
Another tool that can help an RDF developer get to grips with the syntax is GraphViz, or one of the GraphViz-based RDF visualization tools such as RDFViz. GraphViz is a graph visualisation toolkit. It can take descriptions of (various kinds of) graph and generate reasonably pretty pictures in various image formats. There are now a variety of filters that take the output from an RDF/XML parser and generate .dot input files for GraphViz. This can be incredibly useful when learning the RDF/XML syntax, or debugging RDF content. A GraphViz-based RDF visualizer is now also part of W3C's RDF Validator service.
@@above from DanBri's striping material; could alternatively have a separate section on tools that includes this material, plus a brief discussion of other tools and tool types@@
RDF defines a simple data model for describing the properties of resources, and interrelationships among resources, in terms of named properties and values. However, the RDF data model itself provides no mechanisms for declaring specific types or classes of resources, or for declaring which properties might apply to which classes of resources. However, RDF user communities require the ability to say certain things about certain kinds of resources. For describing bibliographic resources, for example, descriptive attributes including "author", "title", and "subject" are common. For digital certification, attributes such as "checksum" and "authorization" are often required. The declaration of these properties (attributes) are defined in the context of RDF as an RDF schema. A schema defines not only the properties of a resource (e.g., title, author, subject, size, color, etc.) but may also define the kinds of resources being described (books, Web pages, people, companies, etc.).
The RDF Schema specification does not specify a specific vocabulary of
descriptive elements such as "author". Instead, it specifies the mechanisms
needed to define such elements, to define the classes of resources they may
be used with, and to restrict possible combinations of classes and
relationships. In other words, the RDF Schema mechanism provides a basic
type system for use in RDF models. The RDF Schema type system is
similar to the type systems of object-oriented programming languages such as
Java. For example, the type system allows resources to be defined as
instances of one or more classes. In addition, it allows classes to be
organized in a hierarchical fashion; for example a class Dog might be defined as a subclass of
Mammal which is a subclass
of Animal, meaning that
any resource which is of rdf:type Dog is also considered to be of rdf:type Animal. 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. This is
done using domain and range constraints on the properties. For example, we
could define the author
property to have a domain of Book and a range of Literal, whereas a classical OO system
might typically define a class Book with an attribute called
author of type Literal. One benefit of the RDF
property-based approach is that it is very easy for anyone to say anything
they want about existing resources, which is one of the architectural
principles of the Web [BERNERS-LEE98].
This RDF type system is specified in terms of the basic RDF data model, as a set of pre-defined RDF resources and properties. As a result, the resources that make up the type system become part of the RDF model of any description that uses them. The following resources are the core classes that are defined as part of the RDF Schema vocabulary. Every RDF model that draws upon the RDF Schema namespace (implicitly) includes these.
This 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. When a schema defines a new class, the
resource representing that class must have an rdf:type property (one of the core
properties defined below) whose value is the resource rdfs:Class. RDF classes can be
defined to represent almost anything, such as Web pages, people, document
types, databases or abstract concepts.
All things being described by RDF expressions are called
resources, and are considered to be instances of the class rdfs:Resource.
rdf:Property represents the subset of
RDF resources that are properties.
Every RDF model which uses the schema mechanism also (implicitly) includes
the following core properties. These are instances of the rdf:Property class, and provide a
mechanism for expressing relationships between classes and their instances or
superclasses.
This property indicates 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
another resource which must be an instance of rdfs:Class. The resource known
as rdfs:Class is itself a resource whose
rdf:type isrdfs:Class.
Individual classes (for example, 'Dog') 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.
This property specifies a subset/superset relation between classes. The
rdfs:subClassOf property is transitive.
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 of rdf:type rdfs:Class. A class may be a
subclass of more than one class.
The following example expresses 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 goes here@@
Some corresponding RDF/XML serialization syntax is shown 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#">
<!-- 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 ID="MotorVehicle">
<rdf:type 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 ID="PassengerVehicle">
<rdf:type resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>
<rdf:Description ID="Truck">
<rdf:type resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>
<rdf:Description ID="Van">
<rdf:type resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>
<rdf:Description ID="MiniVan">
<rdf:type resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#Van"/>
<rdfs:subClassOf rdf:resource="#PassengerVehicle"/>
</rdf:Description>
</rdf:RDF>
The property rdfs:subPropertyOf is an instance of
rdf:Property that is 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.
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 ID="biologicalParent"> <rdf:type resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/> </rdf:Description> <rdf:Description 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>
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:
author
property might specify that the value of an author property must be a
resource of class Person.author
property could only originate from a resource that was an instance of
class Book.Domain and range constraints are specified using the following predefined RDF properties:
A property that is used to indicate the class(es) that the values of
a property must be members of. The value of a range property is always a Class. Range constraints are only
applied to properties.
A property can have at most one range property. It is possible for it to have no range, in which case the class of the property value is unconstrained. @@fix@@.
Although it is not permitted to express two or more
rangeconstraints on a property, a similar outcome can be achieved by defining a common superclass for any classes that represent appropriate values for some property. For example, to express the constraint that a propertyxyz:drivesMotorVehiclecan have values which are Vans, Trucks or PassengerVehicles, we assert thatxyz:drivesMotorVehiclehas ardfs:rangeofMotorVehicle. IfVan,TruckandPassengerVehicleare known to be subclasses ofMotorVehicle, then all these types of resource are acceptable values forxyz:drivesMotorVehicle. In cases where a common superclass does not exist, one can be defined in a schema in the normal manner. @@fix@@
This property is used to indicate the class(es) on whose members a property can be used.
A property may have zero, one, or more than one class as its domain. If there is no domain property, it may be used with any resource. If there is exactly one domain property, it may only be used on instances of that class (which is the value of the domain property). If there is more than one domain property, the constrained property can be used with instances of any of the classes (that are values of those domain properties). @@fix@@
Note: The RDF Schema specification does not constrain the number of
rdfs:domainproperties that a property may have. If there is nodomainproperty, we know nothing about the classes with which the property is used. If there is more than onerdfs:domainproperty, the constrained property can be used with resources that are members of any of the indicated classes. Note that unlikerangethis is a very weak constraint. @@fix@
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 (defined in the
examples below). For the sake of this example, rearSeatLegRoom only applies
to Minivans and PassengerVehicles. The value is
a Number, which is the
number of centimeters of rear seat legroom. These definitions are shown in
the RDF/XML below:
<rdf:RDF xml:lang="en" style="font-size: 10pt" style="font-size: 10pt" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <rdf:Description 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="#Person"/> </rdf:Description> <rdf:Description ID="rearSeatLegRoom"> <rdf:type resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/> <rdfs:domain rdf:resource="#PassengerVehicle"/> <rdfs:domain rdf:resource="#Minivan"/> <rdfs:range rdf:resource="http://www.w3.org/2000/03/example/classes#Number"/> </rdf:Description> </rdf:RDF>
It should be noted that, while RDF Schema provides a mechanism for
describing constraints, it does not say whether or how an application must
process the constraint information. For example, while an RDF schema can
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 and then announce any inconsistencies.
@@additional sections for other stuff: reification (if it survives), containers, ???@@
The following people provided valuable contributions to the document: