Copyright © 1997,1998,1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from other documents. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
The list of know errors in this specification is available at http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/errata.
Comments on this specification may be sent to <www-rdf-comments@w3.org>. The archive of public comments is available at http://www.w3.org/Archives/Public/www-rdf-comments.
The World Wide Web was originally built for human consumption, and although everything on it is machine-readable, this data is not machine-understandable. It is very hard to automate anything on the Web, and because of the volume of information the Web contains, it is not possible to manage it manually. The solution proposed here is to use metadata to describe the data contained on the Web. Metadata is "data about data" (for example, a library catalog is metadata, since it describes publications) or specifically in the context of this specification "data describing Web resources". The distinction between "data" and "metadata" is not an absolute one; it is a distinction created primarily by a particular application, and many times the same resource will be interpreted in both ways simultaneously.
Resource Description Framework (RDF) is a foundation for processing metadata; it provides interoperability between applications that exchange machine-understandable information on the Web. RDF emphasizes facilities to enable automated processing of Web resources. RDF can be used in a variety of application areas; for example: in resource discovery to provide better search engine capabilities, in cataloging for describing the content and content relationships available at a particular Web site, page, or digital library, by intelligent software agents to facilitate knowledge sharing and exchange, in content rating, in describing collections of pages that represent a single logical "document", for describing intellectual property rights of Web pages, and for expressing the privacy preferences of a user as well as the privacy policies of a Web site. RDF with digital signatures will be key to building the "Web of Trust" for electronic commerce, collaboration, and other applications.
This document introduces a model for representing RDF metadata as well as a syntax for encoding and transporting this metadata in a manner that maximizes the interoperability of independently developed Web servers and clients. The syntax presented here uses the Extensible Markup Language [XML]: one of the goals of RDF is to make it possible to specify semantics for data based on XML in a standardized, interoperable manner. RDF and XML are complementary: RDF is a model of metadata and only addresses by reference many of the encoding issues that transportation and file storage require (such as internationalization, character sets, etc.). For these issues, RDF relies on the support of XML. It is also important to understand that this XML syntax is only one possible syntax for RDF and that alternate ways to represent the same RDF data model may emerge.
The broad goal of RDF is to define a mechanism for describing resources that makes no assumptions about a particular application domain, nor defines (a priori) the semantics of any application domain. The definition of the mechanism should be domain neutral, yet the mechanism should be suitable for describing information about any domain.
This specification will be followed by other documents that will complete the framework. Most importantly, to facilitate the definition of metadata, RDF will have a class system much like many object-oriented programming and modeling systems. A collection of classes (typically authored for a specific purpose or domain) is called a schema. Classes are organized in a hierarchy, and offer extensibility through subclass refinement. This way, in order to create a schema slightly different from an existing one it is not necessary to "reinvent the wheel" but one can just provide incremental modifications to the base schema. Through the sharability of schemas RDF will support the reusability of metadata definitions. Due to RDF's incremental extensibility, agents processing metadata will be able to trace the origins of schemata they are unfamiliar with back to known schemata and perform meaningful actions on metadata they weren't originally designed to process. The sharability and extensibility of RDF also allows metadata authors to use multiple inheritance to "mix" definitions, to provide multiple views to their data, leveraging work done by others. In addition, it is possible to create RDF instance data based on multiple schemata from multiple sources (i.e., "interleaving" different types of metadata). Schemas may themselves be written in RDF; a companion document to this specification, [RDFSchema], describes one set of properties and classes for describing RDF schemas.
As a result of many communities coming together and agreeing on basic principles of metadata representation and transport, RDF has drawn influence from several different sources. The main influences have come from the Web standardization community itself in the form of HTML metadata and PICS, the library community, the structured document community in the form of SGML and more importantly XML, and also the knowledge representation (KR) community. There are also other areas of technology that contributed to the RDF design; these include object-oriented programming and modeling languages, as well as databases. While RDF draws from the KR community, readers familiar with that field are cautioned that RDF does not specify a mechanism for reasoning. RDF can be characterized as a simple frame system. A reasoning mechanism could be built on top of this frame system.
The foundation of RDF is a model for representing named properties and property values. The RDF model draws on well-established principles from various data representation communities. RDF properties may be thought of as attributes of resources and in this sense correspond to traditional attribute-value pairs. RDF properties also represent relationships between resources and an RDF model can therefore resemble an entity-relationship diagram. (More precisely, RDF Schemas — which are themselves instances of RDF data models — are ER diagrams.) In object-oriented design terminology, resources correspond to objects and properties correspond to instance variables.
The RDF data model is a syntax-neutral way of representing RDF expressions. The data model representation is used to evaluate equivalence in meaning. Two RDF expressions are equivalent if and only if their data model representations are the same. This definition of equivalence permits some syntactic variation in expression without altering the meaning. (See Section 6. for additional discussion of string comparison issues.)
The basic data model consists of three object types:
| Resources | All things being described by RDF expressions are called resources. A resource may be an entire Web page; such as the HTML document "http://www.w3.org/Overview.html" for example. A resource may be a part of a Web page; e.g. a specific HTML or XML element within the document source. A resource may also be a whole collection of pages; e.g. an entire Web site. A resource may also be an object that is not directly accessible via the Web; e.g. a printed book. Resources are always named by URIs plus optional anchor ids (see [URI]). Anything can have a URI; the extensibility of URIs allows the introduction of identifiers for any entity imaginable. |
| Properties | A property is a specific aspect, characteristic, attribute, or relation used to describe a resource. Each property has a specific meaning, defines its permitted values, the types of resources it can describe, and its relationship with other properties. This document does not address how the characteristics of properties are expressed; for such information, refer to the RDF Schema specification). |
| Statements | A specific resource together with a named property plus the value of that property for that resource is an RDF statement. These three individual parts of a statement are called, respectively, the subject, the predicate, and the object. The object of a statement (i.e., the property value) can be another resource or it can be a literal; i.e., a resource (specified by a URI) or a simple string or other primitive datatype defined by XML. In RDF terms, a literal may have content that is XML markup but is not further evaluated by the RDF processor. There are some syntactic restrictions on how markup in literals may be expressed; see Section 2.2.1. |
Resources are identified by a resource identifier. A resource identifier is a URI plus an optional anchor id (see Section 2.2.1.). For the purposes of this section, properties will be referred to by a simple name.
Consider as a simple example the sentence:
Ora Lassila is the creator of the resource http://www.w3.org/Home/Lassila.
This sentence has the following parts:
Subject (Resource) http://www.w3.org/Home/Lassila Predicate (Property) Creator Object (literal) "Ora Lassila"
In this document we will diagram an RDF statement pictorially using directed labeled graphs (also called "nodes and arcs diagrams"). In these diagrams, the nodes (drawn as ovals) represent resources and arcs represent named properties. Nodes that represent string literals will be drawn as rectangles. The sentence above would thus be diagrammed as:
Figure 1: Simple node and arc diagram
Note: The direction of the arrow is important. The arc always starts at the subject and points to the object of the statement. The simple diagram above may also be read "http://www.w3.org/Home/Lassila has creator Ora Lassila", or in general "<subject> HAS <predicate> <object>".
Now, consider the case that we want to say something more about the characteristics of the creator of this resource. In prose, such a sentence would be:
The individual whose name is Ora Lassila, email <lassila@w3.org>, is the creator of http://www.w3.org/Home/Lassila.
The intention of this sentence is to make the value of the Creator property a structured entity. In RDF such an entity is represented as another resource. The sentence above does not give a name to that resource; it is anonymous, so in the diagram below we represent it with an empty oval:
Figure 2: Property with structured value
Note: corresponding to the reading in the previous note, this diagram could be read "http://www.w3.org/Home/Lassila has creator something and something has name Ora Lassila and email lassila@w3.org".
The structured entity of the previous example can also be assigned a unique identifier. The choice of identifier is made by the application database designer. To continue the example, imagine that an employee id is used as the unique identifier for a "person" resource. The URIs that serve as the unique keys for each employee (as defined by the organization) might then be something like http://www.w3.org/staffId/85740. Now we can write the two sentences:
The individual referred to by employee id 85740 is named Ora Lassila and has the email address lassila@w3.org. The resource http://www.w3.org/Home/Lassila was created by this individual.
The RDF model for these sentences is:
Figure 3: Structured value with identifier
Note that this diagram is identical to the previous one with the addition of the URI for the previously anonymous resource. From the point of view of a second application querying this model, there is no distinction between the statements made in a single sentence and the statements made in separate sentences. Some applications will need to be able to make such a distinction however, and RDF supports this; see Section 4, Statements about Statements, for further details.
The RDF data model provides an abstract, conceptual framework for defining and using metadata. A concrete syntax is also needed for the purposes of creating and exchanging this metadata. This specification of RDF uses the Extensible Markup Language [XML] encoding as its interchange syntax. RDF also requires the XML namespace facility to precisely associate each property with the schema that defines the property; see Section 2.2.3., Schemas and Namespaces.
The syntax descriptions in this document use the Extended Backus-Naur Form notation as defined in Section 6, Notation, of [XML] to describe the essential RDF syntax elements. The EBNF here is condensed for human readability; in particular, the italicized "rdf" is used to represent a variable namespace prefix rather than the more precise BNF notation "'<' NSprefix ':...'". The requirement that the property and type names in end-tags exactly match the names in the corresponding start-tags is implied by the XML rules. All syntactic flexibilities of XML are also implicitly included; e.g. whitespace rules, quoting using either single quote (') or double quote ("), character escaping, case sensitivity, and language tagging.
This specification defines two XML syntaxes for encoding an RDF data model instance. The serialization syntax expresses the full capabilities of the data model in a very regular fashion. The abbreviated syntax includes additional constructs that provide a more compact form to represent a subset of the data model. RDF interpreters are expected to implement both the full serialization syntax and the abbreviated syntax. Consequently, metadata authors are free to mix the two.
A single RDF statement seldom appears in isolation; most commonly several properties of a resource will be given together. The RDF XML syntax has been designed to accomodate this easily by grouping multiple statements for the same resource into a Description element. The Description element names, in an about attribute, the resource to which each of the statements apply. If the resource does not yet exist (i.e., does not yet have a resource identifier) then a Description element can supply the identifer for the resource using an ID attribute.
Basic RDF serialization syntax takes the form:
[1] RDF ::= ['<rdf:RDF>'] description* ['</rdf:RDF>']
[2] description ::= '<rdf:Description' idAboutAttr? '>' propertyElt*
'</rdf:Description>'
[3] idAboutAttr ::= idAttr | aboutAttr
[4] aboutAttr ::= 'about="' URI-reference '"'
[5] idAttr ::= 'ID="' IDsymbol '"'
[6] propertyElt ::= '<' propName '>' value '</' propName '>'
| '<' propName resourceAttr '/>'
[7] propName ::= Qname
[8] value ::= description | string
[9] resourceAttr ::= 'resource="' URI-reference '"'
[10] Qname ::= [ NSprefix ':' ] name
[11] URI-reference ::= string, interpreted per [URI]
[12] IDsymbol ::= (any legal XML name symbol)
[13] name ::= (any legal XML name symbol)
[14] NSprefix ::= (any legal XML namespace prefix)
[15] string ::= (any XML text, with "<", ">", and "&" escaped)
The RDF element is a simple wrapper that marks the boundaries in an XML document between which the content is explicitly intended to be mappable into an RDF data model instance. The RDF element is optional if the content can be known to be RDF from the application context.
Description contains the remaining elements that cause the creation of statements in the model instance. The Description element may be thought of (for purposes of the basic RDF syntax) as simply a place to hold the identification of the resource being described. Typically there will be more than one statement made about a resource; Description provides a way to give the resource name just once for several statements.
When the about attribute is specified with Description, the statements in the Description refer to the resource whose identifier is determined from the about. The value of the about attribute is interpreted as a URI-reference per Section 4 of [URI]. The corresponding resource identifier is obtained by resolving the URI-reference to absolute form as specified by [URI]. If a fragment identifier is included in the URI-reference then the resource identifier refers only to the subcomponent of the containing resource that is identifed by the corresponding fragment id internal to that containing resource (see anchor in [Dexter94]), otherwise the identifier refers to the entire resource specified by the URI. A Description element without an about attribute represents a new resource. Such a resource might be a surrogate, or proxy, for some other physical resource that does not have a recognizable URI. The value of the ID attribute of the Description element, if present, is the anchor id of this "in-line" resource.
If another Description or property value needs to refer to the in-line resource it will use the value of the ID of that resource in its own about attribute. The ID attribute signals the creation of a new resource and the about attribute refers to an existing resource; therefore either ID or about may be specified on Description but not both together in the same element. The values for each ID attribute must not appear in more than one ID attribute within a single document.
A single Description may contain more than one propertyElt element with the same property name. Each such propertyElt adds one arc to the graph. The interpretation of this graph is defined by the schema designer.
Within a propertyElt, the resource attribute specifies that some other resource is the value of this property; that is, the object of the statement is another resource identified by URI rather than a literal. The resource identifier of the object is obtained by resolving the resource attribute URI-reference in the same manner as given above for the about attribute. Strings must be well-formed XML; the usual XML content quoting and escaping mechanisms may be used if the string contains character sequences (e.g. "<" and "&") that violate the well-formedness rules or that otherwise might look like markup. See Section 6. for additional syntax to specify a property value with well-formed XML content containing markup such that the markup is not interpreted by RDF.
Property names must be associated with a schema. This can be done by qualifying the element names with a namespace prefix to unambiguously connect the property definition with the corresponding RDF schema or by declaring a default namespace as specified in [NAMESPACES].
The example sentence from Section 2.1.1
Ora Lassila is the creator of the resource http://www.w3.org/Home/Lassila.
is represented in RDF/XML as:
<rdf:RDF>
<rdf:Description about="http://www.w3.org/Home/Lassila">
<s:Creator>Ora Lassila</s:Creator>
</rdf:Description>
</rdf:RDF>
Here the namespace prefix 's' refers to a specific namespace prefix chosen by the author of this RDF expression and defined in an XML namespace declaration such as:
xmlns:s="http://description.org/schema/"
This namespace declaration would typically be included as an XML attribute on the rdf:RDF element but may also be included with a particular Description element or even an individual propertyElt expression. The namespace name URI in the namespace declaration is a globally unique identifier for the particular schema this metadata author is using to define the use of the Creator property. Other schemas may also define a property named Creator and the two properties will be distinguished via their schema identifiers. Note also that a schema usually defines several properties; a single namespace declaration will suffice to make a large vocabulary of properties available for use.
The complete XML document containing the description above would be:
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://description.org/schema/">
<rdf:Description about="http://www.w3.org/Home/Lassila">
<s:Creator>Ora Lassila</s:Creator>
</rdf:Description>
</rdf:RDF>
Using the default namespace syntax defined in [NAMESPACES] for the RDF namespace itself, this document could also be written as:
<?xml version="1.0"?>
<RDF
xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://description.org/schema/">
<Description about="http://www.w3.org/Home/Lassila">
<s:Creator>Ora Lassila</s:Creator>
</Description>
</RDF>
Furthermore, namespace declarations can be associated with an individual Description element or even an individual propertyElt element as in:
<?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<Description about="http://www.w3.org/Home/Lassila">
<s:Creator xmlns:s="http://description.org/schema/">Ora Lassila</s:Creator>
</Description>
</RDF>
As XML namespace declarations may be nested, the previous example may be further condensed to:
<?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<Description about="http://www.w3.org/Home/Lassila">
<Creator xmlns="http://description.org/schema/">Ora Lassila</Creator>
</Description>
</RDF>
Highly condensed expressions such as this are discouraged, however, when the RDF/XML encoding is written by hand or expected to be edited in a plain text editor. Though unambiguous, the possibility of error is greater than if explicit prefixes are used consistently. Note that an RDF/XML fragment that is intended to be inserted in other documents should declare all the namespaces it uses so that it is completely self-contained. For readability, the introductory examples in the remainder of this section omit the namespace declarations in order to not obscure the specific points being illustrated.
While the serialization syntax shows the structure of an RDF model most clearly, often it is desirable to use a more compact XML form. The RDF abbreviated syntax accomplishes this. As a further benefit, the abbreviated syntax allows documents obeying certain well-structured XML DTDs to be directly interpreted as RDF models.
Three forms of abbreviation are defined for the b