RDF 1.1 Concepts and Abstract Syntax

W3C Working Draft 05 June 2012

This version:
Latest published version:
Latest editor's draft:
Previous version:
Latest recommendation:
Richard Cyganiak, DERI, NUI Galway
David Wood, 3 Round Stones
Previous editors:
Graham Klyne, Nine by Nine
Jeremy J. Carroll, Hewlett Packard Labs
Brian McBride, Hewlett Packard Labs (RDF 2004 Series Editor)


The Resource Description Framework (RDF) is a framework for representing information in the Web.

RDF Concepts and Abstract Syntax defines an abstract syntax on which RDF is based, and which serves to link its concrete syntax to its formal semantics. It also includes discussion of key concepts, datatyping, character normalization and handling of IRIs.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a snapshot of the RDF Working Group's progress towards updating the RDF data model for RDF 1.1. A list of changes since the previous working draft is provided as an appendix. Notable highlights include:

Going forward, the Group expects to extend the data model to support multiple graphs. This is the only expected remaining normative change. Besides that, some content may still be moved between this and other RDF documents, and various editorial changes under consideration are highlighted throughout the document.

This document was published by the RDF Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-rdf-comments@w3.org (subscribe, archives). All feedback is welcome.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1 Introduction

This section is non-normative.

The Resource Description Framework (RDF) is a framework for representing information in the Web.

This document defines an abstract syntax (a data model) which serves to link all RDF-based languages and specifications, including:

1.1 Graph-based Data Model

The core structure of the abstract syntax is a collection of triples, each consisting of a subject, a predicate and an object. A set of such triples is called an RDF graph. This can be illustrated by a node and directed-arc diagram, in which each triple is represented as a node-arc-node link; hence the term “graph”.

An RDF graph with two nodes (Subject and Object) and a triple connecting them (Predicate)

There may be three kinds of nodes in an RDF graph: IRIs, literals, and blank nodes.

1.2 Resources and Statements

Any IRI and literal denotes some thing in the universe of discourse. These things are called resources. Anything can be a resource, including physical things, documents, abstract concepts, numbers and strings; the term is synonymous with “entity”. The resource denoted by an IRI is called its referent, and the resource denoted by a literal is called its value. Literals have datatypes that define the range of possible values, such as strings, numbers, and dates. A special kind of literals, language-tagged strings, denote plain-text strings in a natural language.

The assertion of an RDF triple says that some relationship, indicated by the predicate, holds between the resources denoted by the subject and object. This statement corresponding to an RDF triple is known as an RDF statement. The predicate itself is an IRI and denotes a binary relation, also known as a property. (Relations that involve more than two entities can only be indirectly expressed in RDF [SWBP-N-ARYRELATIONS].)

The assertion of an RDF graph amounts to asserting all the triples in it, so the meaning of an RDF graph is the conjunction (logical AND) of the statements corresponding to all the triples it contains.

Unlike IRIs and literals, blank nodes do not denote specific resources. Statements involving blank nodes say that something with the given relationships exists, without explicitly naming it.

1.3 The Referent of an IRI

The resource denoted by an IRI is also called its referent. What exactly is denoted by any given IRI is not defined by this specification. The question is treated in other documents like Architecture of the World Wide Web, Volume One [WEBARCH] and Cool URIs for the Semantic Web [COOLURIS]. A very brief, informal and partial account follows:

This should explain better that IRIs in RDF play two roles—as globally unique identifiers in a graph data model that describes resources, and as starting points for RESTful interaction with these resources (like elsewhere in the Web). This specification is only concerned with the first aspect. Alignment between the two aspects is generally important, but out of scope for this spec.

1.4 RDF Vocabularies and Namespace IRIs

An RDF vocabulary is a collection of IRIs with clearly established referents intended for use in RDF graphs. For example, the IRIs documented in [RDF-SCHEMA] are the RDF Schema vocabulary. RDF Schema can itself be used to define and document additional RDF vocabularies. Some such vocabularies are mentioned in the Primer [RDF-PRIMER].

The material below may be moved to the new RDF 1.1 Primer document once it becomes available.

The IRIs in an RDF vocabulary often share a common substring known as a namespace IRI. Some namespace IRIs are associated by convention with a short name known as a namespace prefix. Some examples:

Namespace prefixNamespace IRIRDF vocabulary
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#The RDF built-in vocabulary [RDF-SCHEMA]
rdfshttp://www.w3.org/2000/01/rdf-schema#The RDF Schema vocabulary [RDF-SCHEMA]
xsdhttp://www.w3.org/2001/XMLSchema#The RDF-compatible XSD types

In some contexts it is common to abbreviate IRIs that start with namespace IRIs by using the associated namespace prefix. For example, the IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral would be abbreviated as rdf:XMLLiteral. Note however that these abbreviations are not valid IRIs, and must not be used in contexts where IRIs are expected. Namespace IRIs and namespace prefixes are not a formal part of the RDF data model. They are merely a syntactic convenience for abbreviating IRIs.

The term “namespace” on its own does not have a well-defined meaning in the context of RDF, but is sometimes informally used to mean “namespace IRI” or “RDF vocabulary”.

1.5 Formal Meaning and Entailment

The idea of meaning in RDF is underpinned by the formal concept of entailment. In brief, an RDF graph A is said to entail another RDF graph B if every possible arrangement of things in the world that makes A true also makes B true. On this basis, if the truth of A is presumed or demonstrated then the truth of B can be inferred. An account of meaning and entailment in RDF, using the formalism of model theory, is given in [RDF-MT].

The Working Group is considering removing the informative entailment rules from the RDF Semantics document, and moving them to another document. Moving them to this document is one possibility.

1.6 Merging and Managing RDF Graphs

This section should explain terminology around working with multiple graphs, and explain the fact that graphs merge easily. This will be added once the Working Group has finalised a design.

An RDF document is a document that encodes an RDF graph in a concrete RDF syntax, such as Turtle [TURTLE-TR], RDFa [RDFA-PRIMER], RDF/XML [RDF-SYNTAX-GRAMMAR], or N-Triples [N-TRIPLES].

2 Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].

This specification, RDF 1.1 Concepts and Abstract Syntax, defines a data model and related terminology for use in other specifications, such as concrete RDF syntaxes, API specifications, and query languages. Implementations cannot directly conform to RDF 1.1 Concepts and Abstract Syntax, but can conform to such other specifications that are based on the RDF data model.

Another specification conforms to RDF 1.1 Concepts and Abstract Syntax if it defines operations in terms of RDF graphs or RDF datasets, and if any use of terminology defined in normative sections of RDF 1.1 Concepts and Abstract Syntax is consistent with its definitions and conformance requirements.

3 RDF Graphs

An RDF graph is a set of RDF triples.

Graph isomorphism: Two RDF graphs G and G' are isomorphic if there is a bijection M between the sets of nodes of the two graphs, such that:

  1. M maps blank nodes to blank nodes.
  2. M(lit)=lit for all RDF literals lit which are nodes of G.
  3. M(uri)=uri for all IRIs uri which are nodes of G.
  4. The triple ( s, p, o ) is in G if and only if the triple ( M(s), p, M(o) ) is in G'

With this definition, M shows how each blank node in G can be replaced with a new blank node to give G'. Graph isomorphism is needed to support the RDF Test Cases [RDF-TESTCASES] specification.

3.1 Triples

An RDF triple contains three components:

An RDF triple is conventionally written in the order subject, predicate, object.

The set of nodes of an RDF graph is the set of subjects and objects of triples in the graph. Predicate IRIs may also appear as nodes in the graph.

IRIs, blank nodes and literals are collectively known as RDF terms.

3.2 IRIs

An IRI (Internationalized Resource Identifier) within an RDF graph is a Unicode string [UNICODE] that conforms to the syntax defined in RFC 3987 [IRI]. IRIs are a generalization of URIs [URI]. Every absolute URI and URL is an IRI.

IRIs in the RDF abstract syntax must be absolute, and may contain a fragment identifier.

IRI equality: Two IRIs are equal if and only if they are equivalent under Simple String Comparison according to section 5.1 of [IRI]. Further normalization must not be performed when comparing IRIs for equality.

When IRIs are used in operations that are only defined for URIs, they must first be converted according to the mapping defined in section 3.1 of [IRI]. A notable example is retrieval over the HTTP protocol. The mapping involves UTF-8 encoding of non-ASCII characters, %-encoding of octets not allowed in URIs, and Punycode-encoding of domain names.

Some concrete syntaxes permit relative IRIs as a shorthand for absolute IRIs, and define how to resolve the relative IRIs against a base IRI.

Previous versions of RDF used the term “RDF URI Reference” instead of “IRI” and allowed additional characters: “<”, “>”, “{”, “}”, “|”, “\”, “^”, “`”, ‘’ (double quote), and “ ” (space). In IRIs, these characters must be percent-encoded as described in section 2.1 of [URI].

Interoperability problems can be avoided by minting only IRIs that are normalized according to Section 5 of [IRI]. Non-normalized forms that should be avoided include:

  • Uppercase characters in scheme names and domain names
  • Percent-encoding of characters where it is not required by IRI syntax
  • Explicitly stated HTTP default port (http://example.com:80/); http://example.com/ is preferrable
  • Completely empty path in HTTP IRIs (http://example.com); http://example.com/ is preferrable
  • /./” or “/../” in the path component of an IRI
  • Lowercase hexadecimal letters within percent-encoding triplets (“%3F” is preferable over “%3f”)
  • Punycode-encoding of Internationalized Domain Names in IRIs
  • IRIs that are not in Unicode Normalization Form C [NFC]

3.3 Literals

Literals are used to denote values such as strings, numbers and dates by means of a lexical representation.

A literal in an RDF graph consists of:

A language-tagged string is any literal whose datatype IRI is equal to http://www.w3.org/1999/02/22-rdf-syntax-ns#langString. In addition to lexical form and datatype IRI, a language-tagged string also has:

Concrete syntaxes may support simple literals, consisting of only a lexical form without any datatype IRI or language tag. Simple literals only exist in concrete syntaxes, and are treated as syntactic sugar for abstract syntax literals with the datatype IRI http://www.w3.org/2001/XMLSchema#string.

Literal equality: Two literals are equal if and only if the two lexical forms, the two datatype IRIs, and the two language tags (if any) compare equal, character by character.

In earlier versions of RDF, literals with a language tag did not have a datatype IRI, and simple literals could appear directly in the abstract syntax. Simple literals and literals with a language tag were collectively known as plain literals.

Literals in which the lexical form begins with a composing character (as defined by [CHARMOD]) are allowed however they may cause interoperability problems, particularly with XML version 1.1 [XML11].

Earlier versions of RDF permitted tags that adhered to the generic tag/subtag syntax of language tags, but were not well-formed according to [BCP47]. Such language tags do not conform to RDF 1.1.

The xsd:string datatype does not permit the #x0 character, and implementations may not permit control codes in the #x1-#x1F range. Earlier versions of RDF allowed these characters in simple literals, although they could never be serialized in a W3C-recommended concrete syntax.

When using the language tag, care must be taken not to confuse language with locale. The language tag relates only to human language text. Presentational issues should be addressed in end-user applications.

The case normalization of language tags is part of the description of the abstract syntax, and consequently the abstract behaviour of RDF applications. It does not constrain an RDF implementation to actually normalize the case. Crucially, the result of comparing two language tags should not be sensitive to the case of the original input.

RDF Literals are distinct and distinguishable from IRIs; e.g. http://example.org/ as a string literal is not equal to http://example.org/ as an IRI.

3.4 Blank Nodes

The blank nodes in an RDF graph are drawn from an infinite set. This set is disjoint from the set of all IRIs and the set of all literals. Otherwise, this set of blank nodes is arbitrary.

Given two blank nodes, it is possible to determine whether or not they are the same. Besides that, RDF makes no reference to any internal structure of blank nodes.

Blank node identifiers are local identifiers that are used in some concrete RDF syntaxes or RDF store implementations. They are always locally scoped to the file or RDF store, and are not persistent or portable identifiers for blank nodes. Blank node identifiers are not part of the RDF abstract syntax, but are entirely dependent on the concrete syntax or implementation. The syntactic restrictions on blank node identifiers, if any, therefore also depend on the concrete RDF syntax or implementation.

3.5 Replacing Blank Nodes with IRIs

Blank nodes do not have identifiers in the RDF abstract syntax. The blank node identifiers introduced by some concrete syntaxes have only local scope and are purely an artifact of the serialization.

In situations where stronger identification is needed, systems may systematically transform some or all of the blank nodes in an RDF graph into IRIs [IRI]. Systems wishing to do this should mint a new, globally unique IRI (a Skolem IRI) for each blank node so transformed.

This transformation does not change the meaning of an RDF graph, provided that the Skolem IRIs do not occur anywhere else.

Systems may wish to mint Skolem IRIs in such a way that they can recognize the IRIs as having been introduced solely to replace a blank node, and map back to the source blank node where possible.

Systems that want Skolem IRIs to be recognizable outside of the system boundaries should use a well-known IRI [WELL-KNOWN] with the registered name genid. This is an IRI that uses the HTTP or HTTPS scheme, or another scheme that has been specified to use well-known IRIs; and whose path component starts with /.well-known/genid/.

For example, the authority responsible for the domain example.com could mint the following recognizable Skolem IRI:


IETF registration of the genid name is currently in progress. This is ACTION-82.

RFC 5785 [WELL-KNOWN] only specifies well-known URIs, not IRIs. For the purpose of this document, a well-known IRI is any IRI that results in a well-known URI after IRI-to-URI mapping [IRI].

4 RDF Datasets

The RDF data model expresses information as RDF graphs consisting of triples with subject, predicate and object. Often, one wants to hold multiple RDF graphs and record information about each graph, allowing an application to work with datasets that involve information from more than one graph.

An RDF Dataset is a collection of RDF graphs and comprises:

The Working Group will standardize a model and semantics for multiple graphs and graphs stores. The charter notes:

The RDF Community has used the term “named graphs” for a number of years in various settings, but this term is ambiguous, and often refers to what could rather be referred as quoted graphs, graph literals, IRIs for graphs, knowledge bases, graph stores, etc. The term “Support for Multiple Graphs and Graph Stores” is used as a neutral term in this charter; this term is not and should not be considered as definitive. The Working Group will have to define the right term(s).

Progress on the design for this feature is tracked under multiple issues:

The design presented here should be considered a preliminary proposal. It is based on RDF Datasets as defined in SPARQL 1.1.

When RDF graphs are merged, their blank nodes must be kept distinct if meaning is to be preserved; this may call for re-allocation of blank node identifiers.

Should “Graph merge” be defined in this spec? If not, then the previous note could just as well go. This will be decided once a multigraph design has been decided upon.

5 Datatypes

Datatypes are used with RDF literals to represent values such as string, numbers and dates. The datatype abstraction used in RDF is compatible with XML Schema [XMLSCHEMA11-2]. Any datatype definition that conforms to this abstraction may be used in RDF, even if not defined in terms of XML Schema. RDF re-uses the XML Schema built-in datatypes, and provides two additional built-in datatypes, rdf:HTML and rdf:XMLLiteral.

A datatype consists of a lexical space, a value space and a lexical-to-value mapping, and is denoted by one or more IRIs.

The lexical space of a datatype is a set of Unicode [UNICODE] strings.

The lexical-to-value mapping of a datatype is a set of pairs whose first element belongs to the lexical space of the datatype, and the second element belongs to the value space of the datatype:

When the datatype is defined using XML Schema:

Language-tagged strings have the datatype IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#langString. No datatype is formally defined for this IRI because the definition of datatypes does not accommodate language tags in the lexical space. The value space associated with the datatype IRI is the set of all pairs of strings and language tags.

For example, the XML Schema datatype xsd:boolean, where each member of the value space has two lexical representations, is defined as follows:

Lexical space:
{“true”, “false”, “1”, “0”}
Value space:
{true, false}
Lexical-to-value mapping
{ <“true”, true>, <“false”, false>, <“1”, true>, <“0”, false>, }

The literals that can be defined using this datatype are:

Literal Value
<“true”, xsd:boolean> true
<“false”, xsd:boolean> false
<“1”, xsd:boolean> true
<“0”, xsd:boolean> false

5.1 The XML Schema Built-in Datatypes

IRIs of the form http://www.w3.org/2001/XMLSchema#xxx, where xxx is the name of a datatype, denote the built-in datatypes defined in XML Schema 1.1 Part 2: Datatypes [XMLSCHEMA11-2]. The XML Schema built-in types listed in the following table are the RDF-compatible XSD types. Their use is recommended.

DatatypeValue space (informative)
Core typesxsd:stringCharacter strings
xsd:booleantrue, false
xsd:decimalArbitrary-precision decimal numbers
xsd:integerArbitrary-size integer numbers
IEEE floating-point
xsd:double64-bit floating point numbers incl. ±Inf, ±0, NaN
xsd:float32-bit floating point numbers incl. ±Inf, ±0, NaN
Time and date xsd:dateDates (yyyy-mm-dd) with or without timezone
xsd:timeTimes (hh:mm:ss.sss…) with or without timezone
xsd:dateTimeDate and time with or without timezone
xsd:dateTimeStampDate and time with required timezone
Recurring and
partial dates
xsd:gYearGregorian calendar year
xsd:gMonthGregorian calendar month
xsd:gDayGregorian calendar day of the month
xsd:gYearMonthGregorian calendar year and month
xsd:gMonthDayGregorian calendar month and day
xsd:durationDuration of time
xsd:yearMonthDurationDuration of time (months and years only)
xsd:dayTimeDurationDuration of time (days, hours, minutes, seconds only)
integer numbers
xsd:byte-128…+127 (8 bit)
xsd:short-32768…+32767 (16 bit)
xsd:int-2147483648…+2147483647 (32 bit)
xsd:long-9223372036854775808…+9223372036854775807 (64 bit)
xsd:unsignedByte0…255 (8 bit)
xsd:unsignedShort0…65535 (16 bit)
xsd:unsignedInt0…4294967295 (32 bit)
xsd:unsignedLong0…18446744073709551615 (64 bit)
xsd:positiveIntegerInteger numbers >0
xsd:nonNegativeIntegerInteger numbers ≥0
xsd:negativeIntegerInteger numbers <0
xsd:nonPositiveIntegerInteger numbers ≤0
Encoded binary data xsd:hexBinaryHex-encoded binary data
xsd:base64BinaryBase64-encoded binary data
XSD types
xsd:anyURIAbsolute or relative URIs and IRIs
xsd:languageLanguage tags per [BCP47]
xsd:normalizedStringWhitespace-normalized strings
xsd:tokenTokenized strings
xsd:NameXML Names
xsd:NCNameXML NCNames

The other built-in XML Schema datatypes are unsuitable for various reasons, and should not be used.

5.2 The rdf:HTML Datatype

RDF provides for HTML content as a possible literal value. This allows markup in literal values. Such content is indicated in an RDF graph using a literal whose datatype is a special built-in datatype rdf:HTML. This datatype is defined as follows:

An IRI denoting this datatype
is http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML.
The lexical space
is the set of Unicode [UNICODE] strings.
The value space
is a set of DOM DocumentFragment nodes [DOM4]. Two DocumentFragment nodes A and B are considered equal if and only if the DOM method A.isEqualNode(B) [DOM4] returns true.
The lexical-to-value mapping

Any language annotation (lang="…") or XML namespaces (xmlns) desired in the HTML content must be included explicitly in the HTML literal. Relative URLs in attributes such as href do not have a well-defined base URL and are best avoided.

RDF applications may use additional equivalence relations, such as that which relates an xsd:string with an rdf:HTML literal corresponding to a single text node of the same string.

5.3 The rdf:XMLLiteral Datatype

RDF provides for XML content as a possible literal value. Such content is indicated in an RDF graph using a literal whose datatype is a special built-in datatype rdf:XMLLiteral, which is defined as follows:

An IRI denoting this datatype
is http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral.
The lexical space
is the set of all strings which are well-balanced, self-contained XML content [XML10]; and for which embedding between an arbitrary XML start tag and an end tag yields a document conforming to XML Namespaces [XML-NAMES].
The value space
is a set of DOM DocumentFragment nodes [DOM4]. Two DocumentFragment nodes A and B are considered equal if and only if the DOM method A.isEqualNode(B) returns true.
The lexical-to-value mapping
The canonical mapping
defines a canonical lexical form [XMLSCHEMA11-2] for each member of the value space. The rdf:XMLLiteral canonical mapping is the exclusive XML canonicalization method (with comments, with empty InclusiveNamespaces PrefixList) [XML-EXC-C14N].

Any XML namespace declarations (xmlns), language annotation (xml:lang) or base URI declarations (xml:base) desired in the XML content must be included explicitly in the XML literal. Note that some concrete RDF syntaxes may define mechanisms for inheriting them from the context (e.g., @parseType="literal" in RDF/XML [RDF-SYNTAX-GRAMMAR]).

Not all values of this datatype are compliant with XML 1.1 [XML11]. If compliance with XML 1.1 is desired, then only those values that are fully normalized according to XML 1.1 should be used.

5.4 Datatype Maps

A datatype map is an implementation-defined set of <IRI, datatype> pairs such that no IRI appears twice in the set and the IRI denotes the datatype. It can be seen as a function from IRIs to datatypes.

If a datatype map contains the IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral, then it must be paired with the datatype rdf:XMLLiteral.

If a datatype map contains an IRI of the form http://www.w3.org/2001/XMLSchema#xxx, then it must be paired with the RDF-compatible XSD type named xsd:xxx.

5.5 The Value Corresponding to a Literal

The literal value associated with a literal is:

  1. If the literal is a language-tagged string, then the literal value is a pair consisting of its lexical form and its language tag, in that order.
  2. If the literal's datatype IRI is not in the implementation-defined datatype map, then the literal value is not defined by this specification.
  3. Let d be the datatype associated with the datatype IRI in the implementation-defined datatype map.
  4. If the literal's lexical form is in the lexical space of d, then the literal value is the result of applying the lexical-to-value mapping of d to the lexical form.
  5. Otherwise, the literal is ill-typed, and no literal value can be associated with the literal. Such a case, while in error, is not syntactically ill-formed.

In application contexts, comparing the values of literals is usually more helpful than comparing their syntactic forms (literal equality). Similarly, for comparing RDF graphs, semantic notions of entailment are usually more helpful than syntactic graph isomorphism.

6 Fragment Identifiers

This section is non-normative.

RDF uses IRIs, which may include fragment identifiers, as resource identifiers. The semantics of fragment identifiers are defined in RFC 3986 [URI]: They identify a secondary resource that is usually a part of, view of, defined in, or described in the primary resource, and the precise semantics depend on the set of representations that might result from a retrieval action on the primary resource.

This section discusses the handling of fragment identifiers in representations that encode RDF graphs.

In RDF-bearing representations of a resource <foo>, the secondary resource identified by a fragment #bar is the entity denoted by the full IRI <foo#bar> in the RDF graph. Since IRIs in RDF graphs can denote anything, this can be something external to the representation, or even external to the Web.

In this way, the RDF representation acts as an intermediary between some web-retrievable document, and some set of possibly non-web or abstract entities that the RDF may describe.

Primary resources may have multiple representations (a.k.a. content negotiation). Fragments in RDF-bearing representations should be used consistently with the semantics imposed by any non-RDF representations. For example, if the fragment #chapter1 identifies a document section in an HTML representation of a primary resource, then #chapter1 should be taken to denote that same section in all RDF-bearing representations of the same primary resource.

Likewise, RDF graphs embedded in non-RDF representations with mechanism such as RDFa [RDFA-PRIMER] should use fragment identifiers consistently with the semantics imposed by the host language. For example, if the fragment #chapter1 identifies a document section in an HTML+RDFa representation, then #chapter1 should be taken to denote that same section in any RDFa-encoded statements in the document.

7 Acknowledgments

This section is non-normative.

This section may not yet acknowledge all contributions to the RDF 1.1 version.

The RDF 1.1 editors acknowledge valuable contributions from Thomas Baker, Dan Brickley, Gavin Carothers, Jeremy Carroll, John Cowan, Martin J. Dürst, Alex Hall, Steve Harris, Pat Hayes, Ivan Herman, Peter F. Patel-Schneider, Addison Phillips, Eric Prud'hommeaux, Andy Seaborne, Leif Halvard Silli, Nathan Rixham, Dominik Tomaszuk and Antoine Zimmermann.

The RDF 2004 editors acknowledge valuable contributions from Frank Manola, Pat Hayes, Dan Brickley, Jos de Roo, Dave Beckett, Patrick Stickler, Peter F. Patel-Schneider, Jerome Euzenat, Massimo Marchiori, Tim Berners-Lee, Dave Reynolds and Dan Connolly.

This specification contains a significant contribution from the designers of the RDF typed literal mechanism, Pat Hayes, Sergey Melnik and Patrick Stickler. The document draws upon an earlier RDF Model and Syntax document edited by Ora Lassilla and Ralph Swick, and RDF Schema edited by Dan Brickley and R. V. Guha.

This specification is a product of extended deliberations by the members of the RDFcore Working Group and the Schema Working Group.

A Changes from RDF 2004

This section is non-normative.

A.1 Changes from FPWD to this version

This section lists changes from the First Public Working Draft (FPWD) to this Working Draft of RDF 1.1 Concepts and Abstract Syntax.

A.2 Changes from RDF 2004 to FPWD

This section lists changes from the 2004 Recommendation of RDF Concepts and Abstract Syntax to the First Public Working Draft (FPWD) of RDF 1.1 Concepts and Abstract Syntax.

B References

B.1 Normative references

A. Phillips; M. Davis. Tags for Identifying Languages September 2009. IETF Best Current Practice. URL: http://tools.ietf.org/html/bcp47
Anne van Kesteren; Aryeh Gregor; Ms2ger. DOM4. 5 January 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2012/WD-dom-20120105/
Ian Hickson; David Hyatt. HTML5. 25 May 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/html5
M. Duerst, M. Suignard. Internationalized Resource Identifiers (IRI). January 2005. Internet RFC 3987. URL: http://www.ietf.org/rfc/rfc3987.txt
M. Davis, Ken Whistler. TR15, Unicode Normalization Forms.. 17 September 2010, URL: http://www.unicode.org/reports/tr15/
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt
The Unicode Consortium. The Unicode Standard. 2003. Defined by: The Unicode Standard, Version 4.0 (Boston, MA, Addison-Wesley, ISBN 0-321-18578-1), as updated from time to time by the publication of new versions URL: http://www.unicode.org/unicode/standard/versions/enumeratedversions.html
Donald E. Eastlake 3rd; Joseph Reagle; John Boyer. Exclusive XML Canonicalization Version 1.0. 18 July 2002. W3C Recommendation. URL: http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/
Richard Tobin; et al. Namespaces in XML 1.0 (Third Edition). 8 December 2009. W3C Recommendation. URL: http://www.w3.org/TR/2009/REC-xml-names-20091208/
C. M. Sperberg-McQueen; et al. Extensible Markup Language (XML) 1.0 (Fifth Edition). 26 November 2008. W3C Recommendation. URL: http://www.w3.org/TR/2008/REC-xml-20081126/
Henry S. Thompson; et al. W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. 5 April 2012. W3C Recommendation URL: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/

B.2 Informative references

Martin J. Dürst; et al. Character Model for the World Wide Web 1.0: Fundamentals. 15 February 2005. W3C Recommendation. URL: http://www.w3.org/TR/2005/REC-charmod-20050215
Richard Cyganiak; Leo Sauermann. Cool URIs for the Semantic Web. 3 December 2008. W3C Note. URL: http://www.w3.org/TR/2008/NOTE-cooluris-20081203
Gavin Nicol; et al. Document Object Model (DOM) Level 3 Core Specification. 7 April 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407
Jan Grant; Dave Beckett. N-Triples 10 February 2004. W3C Recommendation. URL: http://www.w3.org/TR/rdf-testcases/#ntriples
Patrick Hayes. RDF Semantics. 10 February 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-rdf-mt-20040210
Frank Manola; Eric Miller. RDF Primer. 10 February 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-rdf-primer-20040210/
Dan Brickley; Ramanathan V. Guha. RDF Vocabulary Description Language 1.0: RDF Schema. 10 February 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-rdf-schema-20040210
Andy Seaborne; Eric Prud'hommeaux. SPARQL Query Language for RDF. 15 January 2008. W3C Recommendation. URL: http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115
Dave Beckett. RDF/XML Syntax Specification (Revised). 10 February 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210
Jan Grant; Dave Beckett. RDF Test Cases. 10 February 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-rdf-testcases-20040210
Ben Adida, Ivan Herman, Manu Sporny. RDFa 1.1 Primer. 08 May 2012. W3C Working Draft. URL: http://www.w3.org/TR/2012/WD-rdfa-primer-20120508/
Natasha Noy; Alan Rector. Defining N-ary Relations on the Semantic Web. 12 April 2006. W3C Note. URL: http://www.w3.org/TR/2006/NOTE-swbp-n-aryRelations-20060412
Eric Prud'hommeaux, Gavin Carothers. Turtle: Terse RDF Triple Language. 09 August 2011. W3C Working Draft. URL: http://www.w3.org/TR/2011/WD-turtle-20110809/
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifiers (URI): generic syntax. January 2005. Internet RFC 3986. URL: http://www.ietf.org/rfc/rfc3986.txt
Norman Walsh; Ian Jacobs. Architecture of the World Wide Web, Volume One. 15 December 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-webarch-20041215/
M. Nottingham; E. Hammer-Lahav. Defining Well-Known Uniform Resource Identifiers (URIs). April 2010. Internet RFC 5785. URL: http://tools.ietf.org/html/rfc5785
Eve Maler; et al. Extensible Markup Language (XML) 1.1 (Second Edition). 16 August 2006. W3C Recommendation. URL: http://www.w3.org/TR/2006/REC-xml11-20060816
C. M. Sperberg-McQueen; Henry S. Thompson; Shudi Gao. W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures. 5 April 2012. W3C Recommendation URL: http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/