RDF 1.2 Concepts and Abstract Syntax (original) (raw)

The Resource Description Framework (RDF) is a framework for representing information on the Web. This document defines an abstract syntax (a data model) which serves to link all RDF-based languages and specifications. The abstract syntax has two key data structures:

Compared to RDF 1.1, RDF 1.2 introduces the ability to use an RDF triple as a triple term, in the object position of another triple. RDF 1.2 also introduces directional language-tagged strings, which contain a base direction element that allows the initial text direction to be specified for presentation by a user agent.

This specification introduces key concepts and terminology for RDF 1.2, and subsequently discusses datatyping and the handling of fragment identifiers in IRIs within RDF graphs.

This document is part of the RDF 1.2 document suite. It is the central RDF 1.2 specification and defines the core RDF concepts. Test suites and implementation reports of a number of RDF 1.2 specifications that build on this document are available through the [[[RDF11-TESTCASES]]] document [[RDF11-TESTCASES]].

RDF 1.2 Concepts is an update to [[RDF11-CONCEPTS]], which was itself, an update to [[RDF-CONCEPTS-20040210]].

Determine how to reference 1.2 test cases.

Introduction

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

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

Graph-based Data Model

The core structure of the abstract syntax is a set oftriples, each consisting of a subject, a predicate and an object. A set of such triples is called an RDF graph. An RDF graph can be visualized as a node and directed-arc diagram, in which each triple is represented as a node-arc-node link.

An RDF graph with two nodes (Subject and Object) and an arc (Predicate) connecting them

There can be four kinds of nodes in anRDF graph: IRIs, literals,blank nodes, and triple terms.

There is a mixture of "Abstract Syntax" and "Data Model". We should have a consistent way to say "Abstract Syntax" vs "Data Model". One way is to use "Abstract Syntax" as the basis of semantics and usually say "Data Model" in Concepts otherwise.

Resources and Statements

Any IRI or literal denotes something in the world (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" as it is used in [[[RDF12-SEMANTICS]]] [[RDF12-SEMANTICS]]. The resource denoted by an IRI is called its referent, and the resource denoted by a literal is called itsliteral value. Literals havedatatypes that define the range of possible values, such as strings, numbers, and dates. Special kinds of literals —language-tagged strings and directional language-tagged strings — respectively denote plain-text strings in a natural language, and plain-text strings in a natural language including an initial text direction.

Asserting an RDF triple says that some relationship, indicated by the predicate, holds between theresources 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 property, that is, a resource that can be thought of as a binary relation. (Relations that involve more than two entities can only beindirectly expressed in RDF [[SWBP-N-ARYRELATIONS]].)

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

The Referent of an IRI

The resource denoted by an IRI is also called its referent. For some IRIs with particular meanings, such as those identifying XSD datatypes, the referent is fixed by this specification. For all other IRIs, what exactly isdenoted by any given IRI is not defined by this specification. Other specifications may fix IRI referents, or apply other constraints on what may be the referent of any IRI.

Guidelines for determining the referent of an IRI are provided in other documents, like [[[WEBARCH]]] [[WEBARCH]] and [[[COOLURIS]]] [[COOLURIS]]. A very brief, informal, and partial account follows:

Perhaps the most important characteristic of IRIs in web architecture is that they can bedereferenced, and hence serve as starting points for interactions with a remote server. This specification is not concerned with such interactions. It does not define an interaction model. It only treats IRIs as globally unique identifiers in a graph data model that describes resources. However, those interactions are critical to the concept of [[[LINKED-DATA]]], [[LINKED-DATA]], which makes use of the RDF data model and serialization formats.

RDF Vocabularies and Namespace IRIs

An RDF vocabulary is a collection of IRIs intended for use in RDF graphs. For example, the IRIs documented in [[RDF12-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 [[RDF12-PRIMER]].

The IRIs in an RDF vocabulary often begin with 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:

Some example namespace prefixes and IRIs

Namespace prefix Namespace IRI RDF vocabulary
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# The RDF built-in vocabulary [[RDF12-SCHEMA]]
rdfs http://www.w3.org/2000/01/rdf-schema# The RDF Schema vocabulary [[RDF12-SCHEMA]]
xsd http://www.w3.org/2001/XMLSchema# The RDF-compatible XSD types

In some serialization formats it is common to abbreviate IRIs that start with namespace IRIs by using anamespace prefix in order to assist readability. For example, the IRIhttp://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”.

Triple Terms and Reification

A triple term is an [=RDF triple=] used as an [=RDF term=] in the [=object=] position of another triple.

A triple term is not necessarily asserted, allowing statements to be made about other statements that may not be asserted within an RDF graph. This allows statements to be made about relationships that may be contradictory. For a triple term to be asserted, it must also appear in a graph as an asserted triple.

A triple term can be used as the object of a triple with the predicate rdf:reifies; such a triple is then a reifying triple. The subject of that triple is called a reifier. Assertions on the triple term are made using the reifier. A concrete syntax may provide a special notation for specifying reifying triples.

Using the reifier as an indirect way of referencing a triple term allows multiple groups of assertions to be separated from each other, which might be necessary if the same triple term was derived from different sources. Assertions are always made using the reifier, which can be the subject or object of different triples. Concrete syntaxes, such as Turtle [[RDF12-TURTLE]], may have shortcuts for capturing a triple term with its reifier.

The following diagram represents a reifying triple of an unasserted, abstract triple term, and a triple relating the reifier to another resource.

An RDF graph containing a reifying triple that references an abstract triple term (which is unasserted, depicted using a grey, dashed arc) from a reifier; and a triple describing this reifier.

Here is a variation on the graph shown in . This represents a graph where the triple term corresponds to an asserted triple.

An RDF graph containing a reifying triple where the triple term corresponds to an asserted triple. The diagram represents the proposition as a fact using the asserted triple, meaning that the relationship holds.

Note that a triple term may also have another triple term as an object.

RDF and Change over Time

The RDF data model is atemporal: RDF graphs are static snapshots of information.

However, RDF graphs can express information about events and about temporal aspects of other entities, given appropriate vocabulary terms.

Since RDF graphs are defined as mathematical sets, adding or removing triples from an RDF graph yields a different RDF graph.

We informally use the term RDF source to refer to a persistent yet mutable source or container ofRDF graphs. An RDF source is a resource that may be said to have a state that can change over time. A snapshot of the state can be expressed as an RDF graph. For example, any web document that has an RDF-bearing representation may be considered an RDF source. Like all resources, RDF sources may be named with IRIs and therefore described in other RDF graphs.

Intuitively speaking, changes in the universe of discourse can be reflected in the following ways:

Working with Multiple RDF Graphs

As RDF graphs are sets of triples, they can be combined easily, supporting the use of data from multiple sources. Nevertheless, it is sometimes desirable to work with multiple RDF graphs while keeping their contents separate.RDF datasets support this requirement.

An RDF dataset is a collection ofRDF graphs. All but one of these graphs have an associated IRI or blank node. They are callednamed graphs, and the IRI or blank node is called the graph name. The remaining graph does not have an associated IRI, and is called the default graph of the RDF dataset.

There are many possible uses for RDF datasets. One such use is to hold snapshots of multipleRDF sources.

Equivalence, Entailment and Inconsistency

An RDF triple encodes a proposition — a simple logical expression, describing a relationship between two entities. An [=asserted triple=] is a claim that the corresponding proposition is true. An RDF graph is the conjunction (logical AND) of all the claims made by its [=asserted triples=]. The precise details of this meaning of [=RDF triples=] and [=RDF graphs=] are the subject of [[[RDF12-SEMANTICS]]] [[RDF12-SEMANTICS]], which yields the following relationships between RDF graphs:

Entailment

An RDF graph A entails another RDF graph B if every possible arrangement of the world that makes A true also makes B true. When A entails B, if the truth of A is presumed or demonstrated then the truth of B is established.

Equivalence

Two RDF graphs A and B are equivalent if they make the same claim about the world.A is equivalent to B if and only if_A_ entails B and_B_ entails A.

Inconsistency

An RDF graph is inconsistent if it contains an internal contradiction. There is no possible arrangement of the world that would make the expression true.

An entailment regime [[RDF12-SEMANTICS]] is a specification that defines precise conditions that make these relationships hold. RDF itself recognizes only some basic cases of entailment, equivalence and inconsistency. Other specifications, such as [[[RDF12-SCHEMA]]] [[RDF12-SCHEMA]] and OWL 2 [[OWL2-OVERVIEW]], add more powerful entailment regimes, as do some domain-specific vocabularies.

This specification does not constrain how implementations use the logical relationships defined byentailment regimes. Implementations may or may not detectinconsistencies, and may make all, some or no entailed information available to users.

RDF Documents and Syntaxes

An RDF document is a document that encodes anRDF graph or RDF dataset in a concrete RDF syntax, such as N-Triples [[RDF12-N-TRIPLES]], Turtle [[RDF12-TURTLE]], RDFa [[RDFA-CORE]], JSON-LD [[JSON-LD11]], or TriG [[RDF12-TRIG]]. RDF documents enable the exchange of RDF graphs and RDF datasets between systems.

A concrete RDF syntax may offer many different ways to encode the same RDF graph orRDF dataset, for example through the use ofnamespace prefixes,IRI references, blank node identifiers, and different ordering of triples. While these aspects can have great effect on the convenience of working with the RDF document, they are not significant for its meaning.

This specification, RDF 1.2 Concepts and Abstract Syntax, defines a data model and related terminology for use in other specifications, such asconcrete RDF syntaxes, API specifications, and query languages. Implementations cannot directly conform to_RDF 1.2 Concepts and Abstract Syntax_, but can conform to such other specifications that normatively reference terms defined here.

This specification establishes two conformance levels:

The conformance levels described above are tentative, and still the subject of group discussion. An alternative to conformance levels, "profiles", may be adopted instead, abandoned, or described in another specification.

Change "Classic Conformance" to "Basic Conformance" and define them as profiles.

Strings in RDF

RDF uses Unicode [[Unicode]] as the fundamental representation for string values. Within this, and related specifications, the term string, or RDF string, is used to describe an ordered sequence of zero or moreUnicode code points which are Unicode scalar values. Unicode scalar values do not include thesurrogate code points. Note that most concrete RDF syntaxes require the use of the UTF-8 character encoding [[!RFC3629]], and use the `\u0000` or `\U00000000` forms to express certain non-character values.

A string is identical to another string if it consists of the same sequence of code points. An implementation MAY determine string equality by comparing thecode units of two strings that use the same Unicode character encoding (UTF-8 or UTF-16) without decoding the string into aUnicode code point sequence.

RDF Graphs

An RDF graph is a set of RDF triples.

An [=RDF triple=] that is an element of an [=RDF graph=] is also said to be asserted in that [=RDF graph=]

Triples

An RDF triple (often simply called "triple") is a 3-tuple that is defined inductively as follows:

The three components (|s|, |p|, |o|) of an [=RDF triple=] are respectively called the subject, predicate and object of the triple.

The set of nodes of an RDF graph is the set of subjects and objects of the asserted triples of the graph. It is possible for a [=predicate=] [=IRI=] to also occur as a [=node=] in the same graph.

Triple equality: Two triples (|s|, |p|, |o|) and (s', p', o') are equal (the same [=RDF triple=]) if and only if all of the following three conditions hold.

The definition of triple is recursive. That is, a triple can itself have anobject component which is another triple. However, by this definition, cycles of triples cannot be created.

RDF Terms

IRIs, literals,blank nodes, and triple terms are collectively known asRDF terms.

[=IRIs=], [=literals=] and [=blank nodes=] are said to be atomic [=RDF terms=].

RDF term equality: Two [=RDF terms=] |t| and t' are equal (the same [=RDF term=]) if and only if one of the following four conditions holds:

The set of [=RDF terms=] appearing in an [=RDF triple=] |t| is defined inductively as follows:

By extension, an [=RDF term=] is said to [=appear=] in an [=RDF graph=] if it appears in an [=asserted triple=] of that graph. An [=RDF triple=] is said to [=appear=] in an [=RDF graph=] if it is either an [=asserted triple=] of that graph or a [=triple term=] [=appearing=] in that graph.

An [=RDF term=] is said to be ground if any of the following three conditions holds:

By extension, an [=RDF triple=] is said to be [=ground=] if its [=subject=], [=predicate=], and [=object=] are all ground. An [=RDF graph=] is said to be [=ground=] if all its [=asserted=] triples are [=ground=].

IRIs

An IRI (Internationalized Resource Identifier) within an RDF graph is a string that conforms to the syntax defined in RFC 3987 [[!RFC3987]].

An IRI in the RDF abstract syntax MUST be resolved per [[RFC3986]] and MUST NOT be a relative reference. An IRI MAY contain a fragment identifier. An IRI SHOULD follow rules defined by the IRI scheme.

IRI equality: Two IRIs are equal if and only if they consist of the same sequence ofUnicode code points, as in Simple String Comparison insection 5.3.1 of [[!RFC3987]]. (This is done in the abstract syntax, so the IRIs are resolved IRIs with no escaping or encoding.) Further normalization MUST NOT be performed before this comparison.

For convenience, a complete [[ABNF]] grammar from [[RFC3987]] is provided in .

URIs and IRIs: IRIs are a generalization ofURIs [[RFC3986]] that permits a wider range of Unicode characters [[UNICODE]]. Every URI and URL is an IRI, but not every IRI is an URI. In RDF, IRIs are used as IRI references, as defined in [[RFC3987]]section 1.3. An IRI reference is common usage of an Internationalized Resource Identifier. An IRI reference refers to either a resolved IRI or relative IRI reference, as described by the IRI-reference production in . The abstract syntax uses only fully resolved IRIs. When IRIs are used in operations that are only defined for URIs, they must first be converted according to the mapping defined insection 3.1 of [[!RFC3987]]. 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.

URLs: The [[[URL]]] is largely compatible with [[RFC3987]] IRIs, but is based on a processing model important for implementation within web browsers and are not described using an [[ABNF]] grammar.

Relative IRI references: Some concrete RDF syntaxes permit relative IRI references as a convenient shorthand that allows authoring of documents independently from their final publishing location. Relative IRI references must beresolved against abase IRI. Therefore, the RDF graph serialized in such syntaxes is well-defined only if a base IRI can be established [[RFC3986]].

URI Schemes: Implementations are encouraged to enforce the scheme-specific rules of the common schemes, such as thescheme rules for HTTP/HTTPS and theDID syntax. Implementations ignore URI scheme rules for schemes they do not recognize.

IRI normalization: Interoperability problems can be avoided by minting only IRIs that are normalized according toSection 5 of [[!RFC3987]].

Literals

Literals are used for values such as strings, numbers, and dates.

A literal in an RDF graph consists of two, three, or four elements, as follow:

  1. A lexical form, being an RDF string.
  2. A datatype IRI, being an IRI identifying a datatype that determines how the lexical form maps to a literal value.
  3. If and only if the datatype IRI ishttp://www.w3.org/1999/02/22-rdf-syntax-ns#langString orhttp://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString, a non-empty language tag as defined by [[!BCP47]]. The language tag MUST be well-formed according tosection 2.2.9 of [[!BCP47]], and MUST be treated accordingly, that is, in a case insensitive manner. Two [[!BCP47]]-complying strings that differ only by case represent the same [=language tag=].
  4. If and only if the datatype IRI ishttp://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString, a base direction that MUST be one of the following:
    • `ltr`, indicating that the initial text direction is set to left-to-right
    • `rtl`, indicating that the initial text direction is set to right-to-left

A literal is a language-tagged string if the third element is present and the fourth element is not present. A literal is a directional language-tagged string if both the third element and fourth elements are present.

Literal term equality: two literals are term-equal (the same RDF term) if and only if the following are all true:

Representation of literals

Some concrete syntaxes MAY supportsimple literals consisting of only alexical form without any datatype IRI, language tag, or base direction. Simple literals are syntactic sugar for abstract syntaxliterals with the datatype IRI http://www.w3.org/2001/XMLSchema#string (which is commonly abbreviated as xsd:string).

Similarly, most concrete syntaxes representlanguage-tagged strings and directional language-tagged strings without the datatype IRI because it is always eitherhttp://www.w3.org/1999/02/22-rdf-syntax-ns#langString (rdf:langString) or http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString (rdf:dirLangString), respectively.

Any [=string=] complying with [[!BCP47]] MAY be used to represent a [=language tag=] in concrete syntaxes or implementations. Such strings MAY be case normalized (for example, by canonicalizing as defined byBCP 47 section 4.5). Alternatively, an implementation MAY preserve the case from the original representation, provided that it processes it in a case-insensitive manner.

Literal value

The literal value associated with a literal is defined as follows.

It follows from the above that two literals can have the same value without being the same RDF term. For example:

    "1"^^xsd:integer
    "01"^^xsd:integer

denote the same value, but are not the same literal RDF term because theirlexical forms differ.

Blank Nodes

Blank nodes are disjoint fromIRIs and literals. Otherwise, the set of possible blank nodes is arbitrary. RDF makes no reference to any internal structure of blank nodes.

Blank node equality: Two blank nodes are equal if and only if they are the same blank node.

Blank node identifiers are local identifiers that are used in someconcrete 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. Implementations that handle blank node identifiers in concrete syntaxes need to be careful not to create the same blank node from multiple occurrences of the same blank node identifier except in situations where this is supported by the syntax.

The term "blank node label" is sometimes used informally as an alternative to the term blank node identifier. This alternative was also used in earlier versions of some RDF-related specifications such as [[SPARQL11-QUERY]]. In the interest of consistency, the use of this alternative term is discouraged now.

Triple Terms

An [=RDF triple=] used as the [=object=] of another [=triple=] is called a triple term. In a given [=RDF graph=], a [=triple=] can appear as a [=triple term=], an [=asserted triple=], or both.

Triple term equality: Since triple terms are [=triples=], equality of triple terms is the same as [=triple equality=].

Every triple with a triple term as its [=object=] SHOULD use http://www.w3.org/1999/02/22-rdf-syntax-ns#reifies (rdf:reifies) as its predicate. Every triple whose object is not a triple term SHOULD NOT use http://www.w3.org/1999/02/22-rdf-syntax-ns#reifies (rdf:reifies) as its predicate.

Graph Comparison

This section introduces a notion of graph isomorphism for [=RDF graphs=] which is based on a mapping between [=RDF terms=] that maps blank nodes to blank nodes and is the identity function for IRIs and literals.

A function |M| from the set of all [=RDF terms=] into that same set is called an isomorphic RDF-term mapping if it is has all of the following properties:

Two [=RDF graphs=] |G| and G' areisomorphic (that is, they have the same form) if there exists an [=isomorphic RDF-term mapping=] |M| such that the triple (|s|, |p|, |o|) is in |G| if and only if the triple ( |M|(|s|), |M|(|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 [[RDF11-TESTCASES]] specification.

Initial Text Direction

The base direction of a directional language-tagged string provides a means of establishing the initial direction of text, including text which is a mixture of right-to-left and left-to-right scripts. The [=Unicode Bidirectional Algorithm=] [[?I18N-Glossary]] provides support for automatically rendering a sequence of characters in logical order, so that they are visually ordered as expected, but this is not sufficient to correctly render bidirectional text.

For example, some text with a language tag "`he`" might be displayed in a left-to-right context (such as an English web page) asפעילות הבינאום, W3C, which is incorrect. When provided to a user agent including base direction information (such as using HTML's `dir` attribute) it can then be correctly presented as:

פעילות הבינאום, W3C

In the absence of an explicit initial text direction, the [=Unicode Bidirectional Algorithm=] detects the text direction from the content. This depends on the first strongly directional character in the text or on the context. To avoid [=spillover effects=], users need to employ [=bidi isolation=] whenever text is inserted into a larger document. For example, "<bdi lang="he">ספרים בינלאומיים!</bdi>" displays the Hebrew characters in a right-to-left fashion — i.e., as "ספרים בינלאומיים!" — while they would be stored in memory as "ספרים בינלאומיים!"

Replacing Blank Nodes with IRIs

Blank nodes do not have identifiers in the RDF abstract syntax. Theblank 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 replace some or all of the blank nodes in an RDF graph with IRIs. Systems wishing to do this SHOULD mint a new, globally unique IRI (a Skolem IRI) for each blank node so replaced.

This transformation does not appreciably change the meaning of an RDF graph, provided that the Skolem IRIs do not occur anywhere else. It does however permit other graphs to subsequently use the Skolem IRIs, which is not possible with blank nodes.

Systems may wish to mint Skolem IRIs in such a way that they can recognize the IRIs as having been introduced solely to replace blank nodes. This allows a system to map IRIs back to blank nodes if needed.

Systems that want Skolem IRIs to be recognizable outside of the system boundaries SHOULD use a well-known IRI [[RFC8615]] 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 domainexample.com could mint the following recognizable Skolem IRI:

http://example.com/.well-known/genid/d26a2d0e98334696f4ad70a677abc1f6

RFC 8615 [[RFC8615]] 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 [[!RFC3987]].

RDF Datasets

An RDF dataset is a collection ofRDF graphs, and comprises:

Blank nodes can be shared between graphs in an RDF dataset.

Despite the use of the word “name” in “named graph”, thegraph name is not required to denote the graph. It is merely syntactically paired with the graph. RDF does not place any formal restrictions on what resource the graph name may denote, nor on the relationship between that resource and the graph. A discussion of different RDF dataset semantics can be found in [[RDF11-DATASETS]].

Some RDF dataset implementations do not track empty named graphs. Applications can avoid interoperability issues by not ascribing importance to the presence or absence of empty named graphs.

SPARQL version 1.2 [[SPARQL12-CONCEPTS]] uses the same concept of an RDF Dataset as RDF versions 1.1 and 1.2, in which the graph names of named graphs may be IRIs or blank nodes. In contrast, version 1.1 of the SPARQL Query Language [[SPARQL11-QUERY]] only allowed graph names to be IRIs.

RDF Dataset Comparison

Two RDF datasets |D1| and |D2| (respectively, with [=default graphs=] |DG1| and |DG2| and sets |NG1| and |NG2| of [=named graphs=]) are dataset-isomorphic if and only if there exists an [=isomorphic RDF-term mapping=] |M| for which all of the following properties hold:

Content Negotiation of RDF Datasets

Web resources may have multiple representations that are made available viacontent negotiation [[WEBARCH]]. A representation may be returned in an RDF serialization format that supports the expression of both RDF datasets andRDF graphs. If an RDF dataset is returned and the consumer is expecting an RDF graph, the consumer is expected to use the RDF dataset's default graph.

Dataset as a Set of Quads

A quad is a triple associated with an optional graph name and is used when referring to triples within an RDF dataset.

A quad can be represented as a tuple composed of subject, predicate, object, and an optional graph name.

An RDF dataset can be considered to be a set of quads where quads with no graph name supply the triples of the default graph, and quads with the same graph name supply the triples of the named graph with that name.

Although a quad without a graph name consists of the same three components as a triple, it is a distinct concept, as it specifically captures the notion of a triple within the default graph of an RDF dataset.

Datatypes

Datatypes are used with RDF literals to represent values such as strings, 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 many of the XML Schema built-in datatypes, and defines three additional datatypes,rdf:JSON, rdf:HTML, and rdf:XMLLiteral.

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

The lexical space of a datatype is a set of strings.

The lexical-to-value mapping of a datatype is a set of pairs whose first element belongs to the lexical space, and the second element belongs to the value space of the datatype. Each member of the lexical space is paired with exactly one value, and is a lexical representation of that value. The mapping can be seen as a function from the lexical space to the value space.

Language-tagged strings have the datatype IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#langString (commonly abbreviated as rdf:langString). No datatype is formally defined for this IRI because the definition of datatypes does not accommodatelanguage tags in the lexical space. The value space associated with this datatype IRI is the set of all pairs that consist of a string and a language tag. Similarly, directional language-tagged strings http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString (commonly abbreviated as rdf:dirLangString) also have a base direction in the value space. The value space associated with this datatype IRI is the set of all 3-tuples of a string, a language tag and a base direction.

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:

This table lists the literals of type xsd:boolean.

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

The XML Schema Built-in Datatypes

IRIs of the formhttp://www.w3.org/2001/XMLSchema#_xxx_, where _xxx_ is the name of a datatype, denote the built-in datatypes defined in_[[[XMLSCHEMA11-2]]]_ [[!XMLSCHEMA11-2]]. The XML Schema built-in types listed in the following table are theRDF-compatible XSD types. Their use is RECOMMENDED.

Readers might note that the only safe datatypes for transferring binary information are `xsd:hexBinary` and `xsd:base64Binary`.

A list of the RDF-compatible XSD types, with short descriptions

Datatype Value space (informative)
Core types xsd:string Character strings
xsd:boolean true, false
xsd:decimal Arbitrary-precision decimal numbers
xsd:integer Arbitrary-size integer numbers
IEEE floating-pointnumbers xsd:double 64-bit floating point numbers incl. ±Inf, ±0, NaN
xsd:float 32-bit floating point numbers incl. ±Inf, ±0, NaN
Time and date xsd:date Dates (yyyy-mm-dd) with or without timezone
xsd:time Times (hh:mm:ss.sss…) with or without timezone
xsd:dateTime Date and time with or without timezone
xsd:dateTimeStamp Date and time with required timezone
Recurring andpartial dates xsd:gYear Gregorian calendar year
xsd:gMonth Gregorian calendar month
xsd:gDay Gregorian calendar day of the month
xsd:gYearMonth Gregorian calendar year and month
xsd:gMonthDay Gregorian calendar month and day
xsd:duration Duration of time
xsd:yearMonthDuration Duration of time (months and years only)
xsd:dayTimeDuration Duration of time (days, hours, minutes, seconds only)
Limited-rangeinteger 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:unsignedByte 0…255 (8 bit)
xsd:unsignedShort 0…65535 (16 bit)
xsd:unsignedInt 0…4294967295 (32 bit)
xsd:unsignedLong 0…18446744073709551615 (64 bit)
xsd:positiveInteger Integer numbers >0
xsd:nonNegativeInteger Integer numbers ≥0
xsd:negativeInteger Integer numbers <0
xsd:nonPositiveInteger Integer numbers ≤0
Encoded binary data xsd:hexBinary Hex-encoded binary data
xsd:base64Binary Base64-encoded binary data
MiscellaneousXSD types xsd:anyURI Resolved or relative URI and IRI references
xsd:language Language tags per [[BCP47]]
xsd:normalizedString Whitespace-normalized strings
xsd:token Tokenized strings
xsd:NMTOKEN XML NMTOKENs
xsd:Name XML Names
xsd:NCName XML NCNames

The lexical-to-value mapping for xsd:float and xsd:double MUST use a method consistent with doubleLexicalMap, which MUST strictly conform to the rounding method described infloatPtRound [[XMLSCHEMA11-2]].

The other built-in XML Schema datatypes are unsuitable for various reasons and SHOULD NOT be used:

The value spaces of xsd:double andxsd:float do not include all decimal numbers. For every literal of either of these two datatypes, the value of the literal is a value that can be represented as anIEEE 754-2008 binary floating point representation of the corresponding precision. For instance, the literal with lexical form `"0.1"` and datatype xsd:float denotes the number `0.100000001490116119384765625`. Rather than xsd:double or xsd:float, the datatype xsd:decimal can be used to accurately capture arbitrary decimal numbers.

Datatype IRIs

Datatypes are identified by IRIs.

If any IRI of the formhttp://www.w3.org/2001/XMLSchema#xxx is handled by an RDF implementation, it MUST refer to the RDF-compatible XSD type named xsd:xxx for every XSD type listed in section 5.1.

The datatypes identified by the three IRIs below are defined in Appendix :

RDF implementations are not required to handle all datatypes. Any literal typed with a datatype not handled by an RDF implementation is treated just like an unknown IRI, i.e., as referring to an unknown thing. Applications MAY give a warning message if they are unable to determine the referent of an IRI used in a typed literal. RDF implementations SHOULD NOT reject a literal with an unknown datatype as either a syntactic or semantic error.

Other specifications MAY impose additional constraints ondatatype IRIs, for example, require support for certain datatypes.

Semantic extensions of RDF might choose to recognize other datatype IRIs and require each of them to refer to a fixed datatype. See [[[RDF12-SEMANTICS]]] [[RDF12-SEMANTICS]] for more information on semantic extensions.

The Web Ontology Language [[OWL2-OVERVIEW]] offers facilities for formally definingcustom datatypes that can be used with RDF. Furthermore, a practice for identifying user-defined simple XML Schema datatypes is suggested in [[SWBP-XSCH-DATATYPES]]. RDF implementations are not required to support either of these facilities.

In RDF 1.1, Recognized datatype IRIs were defined in RDF Concepts, overlapping with RDF Semantics, "recognizing" datatype IRIs for semantic extensions.

Fragment Identifiers

RDF uses IRIs, which may include fragment identifiers, as resource identifiers. The semantics of fragment identifiers isdefined in RFC 3986 [[RFC3986]]: They identify a secondary resource that is usually a part of, a 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 primary resource, e.g.,<https://example.com/foo>, the secondary resource identified by a fragment identifier, e.g., bar, is the resource denoted by the full IRI in the RDF graph, which would be <https://example.com/foo#bar> in this case. 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-bearing representation acts as an intermediary between the web-accessible primary resource and some set of possibly non-web or abstract entities that the RDF graph may describe.

In cases where other specifications constrain the semantics offragment identifiers in RDF-bearing representations, the encodedRDF graph should use fragment identifiers in a way that is consistent with these constraints. For example, in an HTML+RDFa document [[HTML-RDFA]], a fragment identifier such as chapter1 may identify a document section via the semantics of HTML's @name or @id attributes. Such an IRI, e.g., <#chapter1>, should then be taken to denote that same section in any RDFa-encodedtriples within the same document. Similarly, fragment identifiers should be used consistently in resources with multiple representations that are made available viacontent negotiation [[WEBARCH]]. For example, if the fragment identifier chapter1 identifies a document section in an HTML representation of the primary resource, then theIRI <#chapter1> should be taken todenote that same section in all RDF-bearing representations of the same primary resource.

Generalizations of RDF Triples, Graphs, and Datasets

It is sometimes convenient to loosen the requirements on RDF triples. For example, the completeness of the RDFS entailment rules is easier to show with a notion of symmetric RDF triples.

Symmetric RDF

A symmetric RDF triple allows the subject to be any RDF term that is allowed in the object position, one of an IRI, a blank node, a literal, or a triple term (which may itself be a symmetric RDF triple). A symmetric RDF graph is a set of symmetric RDF triples. A symmetric RDF dataset comprises a distinguished symmetric RDF graph, and zero or more pairs that each associate an IRI or a blank node with a symmetric RDF graph.

Symmetric RDF triples, graphs, and datasets differ from standard, normative RDF triples,graphs, anddatasets only by allowing IRIs,blank nodes,literals, and triple terms in the subject and object positions.

Generalized RDF

A generalized RDF triple is a triple having a subject, a predicate, and an object, where each can be an IRI, a blank node, a literal, or a triple term (which may itself be a generalized RDF triple). A generalized RDF graph is a set of generalized RDF triples. Ageneralized RDF dataset comprises a distinguished generalized RDF graph, and zero or more pairs each associating an IRI, a blank node, a literal, or a triple term (which may itself be a generalized RDF triple), to a generalized RDF graph.

Generalized RDF triples, graphs, and datasets differ from standard, normative RDF triples,graphs, anddatasets only by allowing IRIs,blank nodes,literals, andtriple terms to appear in any position, i.e., as subject, predicate, object, or graph name.

Any user of symmetric or generalized RDF triples, graphs, or datasets needs to be aware that these notions are non-standard extensions of RDF, and their use may cause interoperability problems. There is no requirement for any RDF tool to accept, process, or produce anything beyond standard normative RDF triples, graphs, and datasets.

Interoperability between RDF [=Classic=] and RDF [=Full=]

Should we make this section normative?

This section provides transformations between [=Full=] [=RDF graphs=] (respectively, [=RDF datasets=]) and [=Classic=] [=RDF graphs=] (respectively, [=RDF datasets=]), to provide some level of interoperability between the different classes of Conformance.

Should we go even further and aim to provide interoperability between RDF 1.1 and RDF 1.2 [=Full=]?

AT RISK: The Working Group may decide to replace the terms `rdf:TripleTerm`, `rdf:ttSubject`, `rdf:ttPredicate`, and `rdf:ttObject` used in this section with other terms, possibly in a different namespace.

These transformation are designed to be:

Information preserving

It must be possible to reconstruct the input graph (respectively, dataset) from the output graph (respectively, dataset). Note, however, that these transformations are not designed to preserve semantics: the output graph is not semantically [=equivalent=] to the input graph, at least not in the entailment regimes defined in [[RDF12-SEMANTICS]].

Idempotent

Applying a transformation several times to a graph (respectively, dataset) should have the same effect as applying it once. Moreover, [=classicizing=] a graph (respectively, dataset) that is already complying with RDF [=Classic=] (i.e., containing no [=triple term=]) must result in the same graph (respectively, dataset).

Universal

It should be possible to transform any [=Full=] graph (respectively, dataset) to a [=Classic=] graph (respectively, dataset) using this method. There is actually a minor caveat to this property.

From [=Full=] to [=Classic=]

Encoding an [=RDF graph=] to ensure that it is consumable by an RDF [=Classic=] implementation is called classicizing it. [=Classicizing=] consists of repeating the following steps until no [=triple term=] [=appears=] in the graph, and the graph is therefore compliant with RDF [=Classic=]: picking a [=triple term=] tt that [=appears=] in the graph; minting a fresh [=blank node=] b (i.e., a blank node not yet in use in the graph); replacing all occurrences of tt [=appearing=] in the graph with b; and then adding the following triples to the graph (where s, p, and o are respectively the [=subject=], [=predicate=] and [=object=] of tt):

Note that this transformation is information preserving only when the input graph either has no [=triple term=] [=appearing=] in it, or contains no [=asserted=] triple (b, `rdf:type`, `rdf:TripleTerm`) where b is a [=blank node=]. Implementations encountering this situation MUST report an error. This limitation is discussed in Section .

The blank nodes generated to replace [=triple terms=] should not be confused with the [=reifiers=] that are typically associated with these [=triple terms=].

[=Classicizing=] an [=RDF dataset=] consists of [=classicizing=] its [=default graph=] and each of its [=named graph=]. In this case, the fresh [=blank node=] assigned to each [=triple term=] must not be used in any graph of the dataset.

A detailed algorithm of the transformation is found in Section .

Example

The examples in this section are expressed in the Turtle concrete syntax [[RDF12-TURTLE]].

From [=Classic=] to [=Full=]

Reverting a [=classicized=] graph to its original form consists of locating each [=asserted=] triple (b, `rdf:type`, `rdf:TripleTerm`) that has a [=blank node=] b as its subject, along with the three associated [=asserted=] triples that have the same [=blank node=] b as their subjects, i.e., (b, `rdf:ttSubject`, s), (b, `rdf:ttPredicate`, p), and (b, `rdf:ttObject`, o); removing these four triples from the graph; and replacing all remaining occurrences of b [=appearing=] in the graph with the triple term (s, p, o).

An implementation MUST report an error if, for a given b, it can not unambiguously determine s, p, or o (i.e., if one of the properties of b — `rdf:ttSubject`, `rdf:ttPredicate`, or `rdf:ttObject` — is missing or duplicated). An implementation MUST also report an error if the input graph contains at the same time a [=triple term=] and an [=asserted triple=] (b, `rdf:type`, `rdf:TripleTerm`) where b is the same [=blank node=]. Note that none of these situations can occur if the input graph was produced by the [=classicize=] transformation.

To revert a [=classicized=] [=RDF dataset=] to its original form, the transformation above is applied to its [=default graph=] and to each of its [=named graphs=].

Note that this transformation has no effect on any [=RDF graph=] or [=RDF dataset=] that does not use the `rdf:TripleTerm` type, including [=Full=] graphs or datasets containing [=triple terms=]. This makes this transformation idempotent as intended.

Limitations

The two transformations above explicitly do not support graphs or datasets containing at the same time a [=triple term=] and an [=asserted triple=] (b, `rdf:type`, `rdf:TripleTerm`) where b is a [=blank node=]. This means that the [=classicize=] transformation is not strictly universal.

This limitation should not be an issue in practice. The `rdf:TripleTerm` type is unlikely to be in used in any published graph or dataset, as it was not defined prior to this specification. For this reason, using it would actually have been bad practice. For future graphs and datasets, this type should be considered to be reserved for use within the [=classicize=] transformation, and not used otherwise.

This is one reason why this transformation introduces new vocabulary terms (`rdf:TripleTerm`, `rdf:ttSubject`, `rdf:ttPredicate`, `rdf::ttObject`), rather than repurposing the existing reification vocabulary (`rdf:Statement`, `rdf:subject`, `rdf:predicate`, `rdf:object`). Unlike `rdf:TripleTerm`, `rdf:Statement` is known to be found in widely used datasets (e.g., Uniprot), so reserving its use for the [=classicize=] transformation was not an option.

Another consequence of this restriction is that implementers will need to be aware and careful when merging graphs in an application that [=classicizes=] graphs or datasets. The concern is that merging a [=Full=] [=RDF graph=] containing at least one [=triple term=] with a [=classicized=] [=RDF graph=] (which might contain [=blank node=] instances of `rdf:TripleTerm`) could result in a "hybrid" graph that cannot be transformed to a consistent [=Full=] nor [=Classic=] [=RDF graph=]. Therefore, such applications should [=classicize=] every graph prior to merging them. Conversely, applications supporting RDF [=Full=] should make sure to apply the reverse transformation to any graph that is known or likely to have been [=classicized=], to avoid creating such "hybrid" graphs. Since these transformations are designed to be idempotent, there is no harm in applying them more than necessary.

Algorithms

The `classicize` algorithm

The algorithm expects one input variable Gᵢ which is an [=RDF graph=]. It returns a [=Classic=] [=RDF graph=].

  1. Let Gₒ be an empty [=RDF graph=].
  2. Let M be an empty map from [=triple terms=] to [=blank nodes=].
  3. Let inputKind be `null`.
  4. For each triple (s, p, o) in Gᵢ:
    1. If s is a [=blank node=], p is `rdf:type` and o is `rdf:TripleTerm`, then:
      1. If inputKind is `"full"` then exit with an error.
      2. Otherwise, set inputKind to `"classic"`.
    2. If o is a [=triple term=], then:
      1. If inputKind is `"classic"` then exit with an error.
      2. Otherwise, set inputKind to `"full"`.
      3. Let b, M' and G' be the result of invoking `classicize-triple-term` passing o as t and M as Mi.
      4. Merge M' into M.
      5. Merge G' into Gₒ.
      6. Set o to b.
    3. Add the triple (s, p, o) to Gₒ.
  5. Return Gₒ.

The `classicize-triple-term` algorithm

This algorithm is responsible for incrementally populating the mapping M and the graph G used internally by the `classicize` algorithm. It receives a [=triple term=] as input and processes it recursively (in case its object is itself a [=triple term=]). It returns, among other things, the [=blank node=] minted to replace the [=triple term=] in the transformed [=Classic=] [=RDF graph=].

This algorithm expects two input variables: a [=triple term=] t, and a map Mᵢ from [=triple terms=] to [=blank nodes=]. It returns a [=blank node=] b, a map Mₒ from [=triple terms=] to [=blank nodes=], and a [=Classic=] [=RDF graph=] G.

  1. Let Mₒ be an empty map.
  2. Let G be an empty [=RDF graph=].
  3. Let b be the [=blank node=] associated with t in Mᵢ, if any.
  4. Otherwise:
    1. Let s, p and o be the subject, predicate and object of t, respectively.
    2. If o is a [=triple term=], then:
      1. Let b', M' and G' be the result of invoking `classicize-triple-term` passing o as t and Mᵢ.
      2. Set o to b'.
      3. Merge M' into Mₒ.
      4. Merge G' into G.
    3. Let b be a fresh blank node.
    4. Add the association (t, b) to Mₒ.
    5. Add the triples (b, `rdf:type`, `rdf:TripleTerm`), (b, `rdf:ttSubject`, s), (b, `rdf:ttPredicate`, p), and (b, `rdf:ttObject`, o) in G.
  5. Return b, Mₒ and G.

The `revert-classicize` algorithm

Write this algorithm

Additional Datatypes

This section defines additional datatypes that RDF implementations MAY support.

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 set to rdf:HTML.

The rdf:HTML datatype is defined as follows:

The IRI denoting this datatype

is http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML.

The value space

is the set of DOMDocumentFragment nodes [[DOM]]. TwoDocumentFragment nodes node and otherNode are considered equal if and only if the DOM methodnode.{{Node/isEqualNode(otherNode)}} [[DOM]] returns true.

The lexical-to-value mapping

Each member of the lexical space is associated with the result of applying the following algorithm:

Any language annotation (lang="…"), text directionality annotation (dir="…"), 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 anrdf:HTML literal corresponding to a single text node of the same string.

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 set to rdf:XMLLiteral.

The rdf:XMLLiteral datatype is defined as follows:

The 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 [[XML11]]; and for which embedding between an arbitrary XML start tag and an end tag yields a document conforming to [[[XML-NAMES]]] [[XML-NAMES]].

The value space

is the set of DOMDocumentFragment nodes [[DOM]]. TwoDocumentFragment nodes node and otherNode are considered equal if and only if the DOM methodnode.{{Node/isEqualNode(otherNode)}} returns true.

The lexical-to-value mapping

Each member of the lexical space is associated with the result of applying the following algorithm:

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 [[RDF12-XML]].

The rdf:JSON Datatype

RDF provides for JSON content as a possible literal value. This includes allowing markup in literal values. Such content is indicated in anRDF graph as a literal whose datatype is set to rdf:JSON.

The rdf:JSON datatype is defined as follows:

The IRI denoting this datatype

is http://www.w3.org/1999/02/22-rdf-syntax-ns#JSON.

The lexical space

is the set of all RDF strings that conform to theJSON Grammar as described inSection 2 JSON Grammar of [[RFC8259]], which also conform to the requirements of [[[RFC7493]]] [[RFC7493]].

[[[RFC8259]]] [[RFC8259]] allows strings to includesurrogate code points not allowed in RDF strings, which are also excluded in [[RFC7493]], thus the lexical representation of JSON literals excludes those includingsurrogate code points.

The value space

is the smallest set containingstrings, numbers (xsd:double),maps (mapping strings to values in the value space where the order of map entries is not significant),lists (of values in the value space), and literal values (`true`, `false`, and `null`) from [[[INFRA]]] [[INFRA]] and [[[XMLSCHEMA11-2]]] [[XMLSCHEMA11-2]].

The value space of maps and lists does not include values having themselves as members, which cannot be represented in JSON.

Two values (|a| and |b|) are considered equal if any of the following are true:

The lexical-to-value mapping

maps every element of the lexical space to the result of parsing it into astring, number (xsd:double),map,list, or literal value (`true`, `false`, and `null`).

The issue refers to the use of ordered map from [[INFRA]] for describing the value space of JSON Objects and suggests defining a new datatype for unordered maps.

Privacy Considerations

RDF is used to express arbitrary application data, which may include the expression of personally identifiable information (PII) or other information which could be considered sensitive. Authors publishing such information are advised to carefully consider the needs and use of publishing such information, as well as the applicable regulations for the regions where the data is expected to be consumed and potentially revealed (e.g., GDPR, CCPA,others), particularly whether authorization measures are needed for access to the data.

Security Considerations

The RDF Abstract Syntax is not used directly for conveying information, although concrete serialization forms are specifically intended to do so.

Applications MAY evaluate given data to infer more assertions or to dereference IRIs, invoking the security considerations of the scheme for that IRI. Note in particular, the privacy issues in [[RFC3023]] section 10 for HTTP IRIs. Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions, as well as the dereferencing of unintended IRIs. Care must be taken to align the trust in consulted resources with the sensitivity of the intended use of the data; inferences of potential medical treatments would likely require different trust than inferences for trip planning.

RDF is used to express arbitrary application data; security considerations will vary by domain of use. Security tools and protocols applicable to text (for example, PGP encryption, checksum validation, password-protected compression) may also be used on RDF documents. Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information.

RDF can express data which is presented to the user, such as RDF Schema labels. Applications rendering strings retrieved from untrusted RDF documents, or using unescaped characters, SHOULD use warnings and other appropriate means to limit the possibility that malignant strings might be used to mislead the reader. The security considerations in the media type registration for XML ([[RFC3023]] section 10) provide additional guidance around the expression of arbitrary data and markup.

RDF uses IRIs as term identifiers. Applications interpreting data expressed in RDF SHOULD address the security issues of [[[RFC3987]]] [[RFC3987]] Section 8, as well as [[[RFC3986]]] [[RFC3986]] Section 7.

Multiple IRIs may have the same appearance. Characters in different scripts may look similar (for instance, a Cyrillic "о" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (for example, LATIN SMALL LETTER "E" followed by COMBINING ACUTE ACCENT has the same visual representation as LATIN SMALL LETTER "E" WITH ACUTE). Any person or application that is writing or interpreting data in RDF must take care to use the IRI that matches the intended semantics, and avoid IRIs that may look similar. Further information about matching visually similar characters can be found in [[[UNICODE-SECURITY]]] [[UNICODE-SECURITY]] and [[[RFC3987]]] [[RFC3987]] Section 8.

These considerations are a more generic form of Security Considerations for [[RDF12-TURTLE]], [[RDF12-TRIG]], [[RDF12-N-TRIPLES]], and [[RDF12-N-QUADS]].

Internationalization Considerations

Unicode [[UNICODE]] provides a mechanism for signaling direction within a string (see [=Unicode Bidirectional Algorithm=] [[I18N-Glossary]]). RDF provides a mechanism for specifying the base direction of a directional language-tagged string to signal the initial text direction of a string. For most human language strings, but particularly for those whose base direction cannot be accurately determined from the string content, is it valuable to have an external indicator in order to get the proper display and isolation of the value. One example of such an indicator is the [[HTML]] dir attribute; see [[STRING-META]].

[[[JSON-LD11]]] [[JSON-LD11]] introduced thei18n namespace to use a datatype to specify both the base direction an language tag of an RDF literal.

IRI Grammar

The following [[ABNF]] grammar applies the changes from [[RFC3987]] and [[RFC6874]] to the sectionCollected ABNF for URI of [[RFC3986]] to give a consolidated grammar for IRIs.

This is provided for convenience only. If it differs from definitions in [[RFC3986]], [[RFC3987]], or any subsequent updates, then those definitions should be used.

The ABNF can also be accessed directly from <iri-grammar.abnf>.

Acknowledgments

Acknowledgments for RDF 1.0

The editors of the original version of the spec were Graham Klyne (Nine by Nine) and Jeremy J. Carroll (Hewlett Packard Labs).

This document contains a significant contribution from Pat Hayes, Sergey Melnik and Patrick Stickler, under whose leadership was developed the framework described in the RDF family of specifications for representing datatyped values, such as integers and dates.

The editors acknowledge valuable contributions from the following: 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.

Jeremy Carroll thanks Oreste Signore, his host at the W3C Office in Italy and Istituto di Scienza e Tecnologie dell'Informazione "Alessandro Faedo", part of the Consiglio Nazionale delle Ricerche, where Jeremy is a visiting researcher.

This document is a product of extended deliberations by the RDFcore Working Group, whose members have included: Art Barstow (W3C), Dave Beckett (ILRT), Dan Brickley (ILRT), Dan Connolly (W3C), Jeremy Carroll (Hewlett Packard), Ron Daniel (Interwoven Inc), Bill dehOra (InterX), Jos De Roo (AGFA), Jan Grant (ILRT), Graham Klyne (Nine by Nine), Frank Manola (MITRE Corporation), Brian McBride (Hewlett Packard), Eric Miller (W3C), Stephen Petschulat (IBM), Patrick Stickler (Nokia), Aaron Swartz (HWG), Mike Dean (BBN Technologies / Verizon), R. V. Guha (Alpiri Inc), Pat Hayes (IHMC), Sergey Melnik (Stanford University) and Martyn Horner (Profium Ltd).

This specification also 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. RDF and RDF Schema Working Group members who contributed to this earlier work are: Nick Arnett (Verity), Tim Berners-Lee (W3C), Tim Bray (Textuality), Dan Brickley (ILRT / University of Bristol), Walter Chang (Adobe), Sailesh Chutani (Oracle), Dan Connolly (W3C), Ron Daniel (DATAFUSION), Charles Frankston (Microsoft), Patrick Gannon (CommerceNet), R. V. Guha (Epinions, previously of Netscape Communications), Tom Hill (Apple Computer), Arthur van Hoff (Marimba), Renato Iannella (DSTC), Sandeep Jain (Oracle), Kevin Jones, (InterMind), Emiko Kezuka (Digital Vision Laboratories), Joe Lapp (webMethods Inc.), Ora Lassila (Nokia Research Center), Andrew Layman (Microsoft), Ralph LeVan (OCLC), John McCarthy (Lawrence Berkeley National Laboratory), Chris McConnell (Microsoft), Murray Maloney (Grif), Michael Mealling (Network Solutions), Norbert Mikula (DataChannel), Eric Miller (OCLC), Jim Miller (W3C, emeritus), Frank Olken (Lawrence Berkeley National Laboratory), Jean Paoli (Microsoft), Sri Raghavan (Digital/Compaq), Lisa Rein (webMethods Inc.), Paul Resnick (University of Michigan), Bill Roberts (KnowledgeCite), i Tsuyoshi Sakata (Digital Vision Laboratories), Bob Schloss (IBM), Leon Shklar (Pencom Web Works), David Singer (IBM), Wei (William) Song (SISU), Neel Sundaresan (IBM), Ralph Swick (W3C), Naohiko Uramoto (IBM), Charles Wicksteed (Reuters Ltd.), Misha Wolf (Reuters Ltd.) and Lauren Wood (SoftQuad).

Acknowledgments for RDF 1.1

The editors of the RDF 1.1 version of the spec were Richard Cyganiak (DERI), David Wood (3 Round Stones), and Markus Lanthaler (Graz University of Technology).

The editors acknowledge valuable contributions from Thomas Baker, Tim Berners-Lee, David Booth, Dan Brickley, Gavin Carothers, Jeremy Carroll, Pierre-Antoine Champin, Dan Connolly, John Cowan, Martin J. Dürst, Alex Hall, Steve Harris, Sandro Hawke, Pat Hayes, Ivan Herman, Peter F. Patel-Schneider, Addison Phillips, Eric Prud'hommeaux, Nathan Rixham, Andy Seaborne, Leif Halvard Silli, Guus Schreiber, Dominik Tomaszuk, and Antoine Zimmermann.

The membership of the RDF Working Group included Thomas Baker, Scott Bauer, Dan Brickley, Gavin Carothers, Pierre-Antoine Champin, Olivier Corby, Richard Cyganiak, Souripriya Das, Ian Davis, Lee Feigenbaum, Fabien Gandon, Charles Greer, Alex Hall, Steve Harris, Sandro Hawke, Pat Hayes, Ivan Herman, Nicholas Humfrey, Kingsley Idehen, Gregg Kellogg, Markus Lanthaler, Arnaud Le Hors, Peter F. Patel-Schneider, Eric Prud'hommeaux, Yves Raimond, Nathan Rixham, Guus Schreiber, Andy Seaborne, Manu Sporny, Thomas Steiner, Ted Thibodeau, Mischa Tuffield, William Waites, Jan Wielemaker, David Wood, Zhe Wu, and Antoine Zimmermann.

Acknowledgments for RDF 1.2

In addition to the editors, the following people have contributed to this specification:

Recognize members of the Task Force? Not an easy to find list of contributors.

Changes between RDF 1.1 and RDF 1.2

A detailed overview of the differences between RDF versions 1.1 and 1.2 can be found in [[[RDF12-NEW]]] [[RDF12-NEW]].