This document defines Notation 3 (also known as N3), an assertion and logic language which is a superset of RDF.

This is very early draft of the Notation3 specification.


The Semantic Web represents a vision of online, interconnected and logical information. The core building block is a logical formalism called the Resource Description Framework (RDF) ([[[RDF11-PRIMER]]]). In RDF, one can express a logical graph as a conjunction of statements that describe properties of subject resources; and then describe the resource objects of those properties; and so on; resulting in a connected graph of logical information. It builds on the fundamental pointer mechanism of the Web, i.e., the Uniform Resource Identifier (URI), also known as International Resource Identifier (IRI), as a means to identify any RDF resource, ranging from abstract concepts (the book "Moby Dick") to physical (a paper copy of the book "Moby Dick") to electronic objects (an e-book copy of "Moby Dick"). People have used RDF to build vast quantities of online, connected knowledge graphs. The Semantic Web has allowed for decision making within an open web environment of shared knowledge graphs, as opposed to a closed system of locally believed facts.

Notation3 Logic, or N3 for short, aims to improve decision-making abilities in an open web environment — by (a) extending the logical representation abilities of RDF and (b) allowing access to, operation on, and reasoning over online information. In line with the design ethos of RDF, N3 attempts to walk the line between, on the one hand, ease-of-use by authors and simplicity of reasoning for developers; and, on the other hand, extended utility and practicality for building real-world applications.

Below, we elaborate on the main characteristics of N3:

Should we highlight log:semantics and log:conclusion that much? They are still causing lots of discussion. Maybe we could highlight other useful built-ins instead? Of course, then we would need other constructs for snaf


The namespace for N3 is .... N3 also makes extensive use of terms from other vocabularies, in particular....

Namespaces and prefixes used in examples in the document are shown in the following table.

Prefix Namespace


The aim of this section is to provide an informal overview of the N3 language and its different features. Where possible, this section borrows from, or is at least based on, the [[[Turtle]]] specification. More formal definitions will follow in the subsequent sections.

N3 document

An N3 document represents an N3 graph in a compact textual form. An N3 graph is a series of N3 statements. These are written as triples consisting of: subject, predicate, and object. In its simplest form a triple expresses a relation between resources, but N3 also contains elements allowing more advanced statements — cited formulae for quoting sets of statements, logical implications for If-Then style, rule-based reasoning, quantified variables, and so on. We introduce these elements below.

Comments are indicated using a separate '#' (i.e., not part of another N3 symbol, such as an IRI) and continue until the end of the line.

Simple triples

The simplest N3 statement or triple is a sequence of subject, predicate, and object, separated by whitespace and terminated by '`.`' after each triple. For now, we will asssume that a resource is represented either by an IRI or a literal. In general, one uses an IRI to identify, well, an identifiable entity, such as a person, place, or thing — a literal is used for a textual or numerical (i.e., datatype) value, such as name, date, height, and so on.

The three N3 triples below highlight the enmity between Spiderman and the Green Goblin, and lists the names of these two individuals:


There is no inherent order for N3 or RDF triples. The same is true for the relational model, i.e., relational tuples or rows do not have an inherent order. Hence, it is a mistake to associate meaning with the order of statements in an N3 document; for instance, it would be an error to assume that the first listed telephone for Spiderman would be his landline, and the second one his mobile number.

Examples will often be written using newlines and tab spaces for readability. However, generally, only the subjects, predicates and objects need to be separated with a whitespace.

Predicate and object lists

As shown in the above example, the same subject (here, Spiderman) will often be described by several N3 statements. To make these N3 statements less cumbersome, one can put a semicolon (";") at the end of an N3 statement to describe the same subject in the subsequent N3 statement (called a "predicate object list"):


Similarly, a predicate (e.g., name) can often list multiple object values for the same subject (e.g., Spiderman). This can be written by listing the object values separated by a ',':



As mentioned, one typically uses an IRI to represent an identifiable entity — such as a person, place, or thing. Until now, we have been writing IRIs [[RFC3987]] (e.g., — which include both the namespace (e.g., and the local name (e.g., Spiderman).

This is a perfectly valid way of writing IRIs, but it is often much easier to write an IRI as a prefixed name — e.g., ex:Spiderman, which includes a prefix label (e.g., ex) and a local name (e.g., Spiderman) separated by a colon (":"). The `@prefix` or `PREFIX` directives associate a prefix label with a namespace IRI — a prefixed name is turned into an IRI by concatenating the namespace IRI with the prefix label. Subsequent `@prefix` or `PREFIX` directives may re-map the same prefix label. For instance, the following is equivalent to using absolute IRIs:


To further simplify prefixed names, one can leave the prefix label empty (e.g., for a namespace that is often used in the N3 document):


Prefixed names are a superset of XML QNames. They differ in that the local part of prefixed names may include:

  • leading digits, e.g. `leg:3032571` or `isbn13:9780136019701`
  • non leading colons, e.g. `og:video:height`
  • reserved character escape sequences, e.g. `wgs:lat\-long`

The `@prefix` and `@base` directives require a trailing `'.'` after the IRI, the equalivent `PREFIX` and `BASE` must not have a trailing `'.'` after the IRI part of the directive.

One can write relative IRI references, e.g., <#Spiderman>, which will be resolved relative to the current base IRI. A relative IRI reference is turned into an absolute IRI by resolving the base IRI relative to the local name (e.g., Spiderman). A base IRI is defined using the `@base` directive. For instance, the following is equivalent to the prior example:


Specifics of relative IRI reference resolution are described in .

We recommend listing the `@prefix` or `PREFIX` declarations (just like `@base` or `BASE` declarations) at the top of an N3 document. This is not mandatory, however, and they can technically be put anywhere before the prefixed name or relative IRI that relies on the declaration. Subsequent @prefix` or `PREFIX` directives may re-map the same prefix label to another namespace IRI.

N3 also supports case-insensitive 'PREFIX' and 'BASE' directives, as does Turtle, to align the syntax with SPARQL. Note that the @prefix and @base directives require a trailing '.' after the IRI, but the equivalent PREFIX and BASE must not have a trailing '.'.

IRI property lists

Similar to the blank node property list discussed in , an IRI property list allows statements on the same resource to be kept together in the context of a referencing property allowing statements to be embedded within other statements. See Embedding in [[JSON-LD11]] for a discussion of a similar feature in another format.

An example showing the same statements using and without using this feature follows:


As shown, a IRI property lists relies on predicate object lists to easily group statements about a given IRI


In general, one uses a literal to represent a textual or numerical (i.e., datatype) value — such as name, date, height, and so on. Numbers (integers, decimals, and doubles) can simply be represented using their numerical value, and booleans can be represented using keywords true or false:


For details on what number syntax is supported (e.g., for decimals, doubles), we refer to the RDF 1.1: Turtle (Section 2.5.2) specification.

Other literals (e.g., date; binary, octal or hex code; XML or JSON code; other types of numbers, such as shorts), and of course strings themselves, need to be written as string literals. For instance, <> <> "2001-08-10". In that case, the lexical form will include the characters between the delimiter quotes (e.g., 2001-08-10).

Clearly, this can raise confusion as to what type of literal is being represented — is it a string or some other arbitrary type? You can indicate the datatype of a literal in RDF using the ^^ symbol and the corresponding datatype IRI. The above example then becomes:


(Take care to add the appropriate xsd prefix declaration.)

One can also specify the language of a string literal using the @ symbol and the corresponding language tag (as defined in [[BCP47]] — find the registry in [[LNG-TAG]]). For instance:


If you need to describe the base direction as well as the language [[BCP47]] you can use the i18n namespace:


If no datatype IRI or language tag is given, the datatype xsd:string will be assumed. In case a language tag is given, the datatype rdf:langString will be assumed. Note that it is not possible to specify both a datatype IRI and a language tag.

Integers, decimals, doubles, and booleans may also be written as string literals with the appropriate datatype IRI. Boolean literals can be written as true and false.

There are also other mechanisms for describing the language tag and base direction of RDF literals.

There are several ways to write string literals. Until now we have used double-quotes " for delimiting, but one may also use single-quotes ', or even compound delimiters consisting of three double-quotes """ or three single-quotes '''. These other delimiters are useful if the string literal is known to contain single- or double-quotes; e.g., if the string contains single-quotes, one could use double-quotes as delimiters, and vice-versa, to avoid syntax errors. Alternatively, one can also use a '\' for escaping the delimiter each time it occurs within a string literal. If a string can contain newlines (or a quote of any type, and it is impractical or undesirable to escape them), one should use the compound type of delimiter, i.e., """ or '''. For instance:


In general, the escape symbol '\' (U+005C) may only appear in a string literal as part of an escape sequence. Other restrictions within string literals depend on the delimiter:

Blank Nodes

When describing resources in RDF, one often runs into the following situations:

Instead, you can use blank nodes to talk about resources. They are existential variables; that is, they state the existence of a thing without identifying that thing. Blank nodes can be represented in several ways:

Blank node identifiers

A blank node can be represented by a blank node identifier, which is unique within the N3 graph, expressed as _: followed by a blank node label (e.g., _:someLabel). Then, we use this identifier to describe a resource in the same way we have been doing.

For instance, we might want to state that the Mona Lisa painting has in its background an unidentified tree, and we want to describe the tree — such as the painting it is in, and the type of tree:


In this example, we minted the blank node identifier _:bn to represent the resource that we want to describe.

Blank node property lists

Using a blank node identifier requires introducing a new identifier for each blank node. Although they're not quite as hard to mint as IRIs, in many cases it is redundant to even introduce such an identifier.

For instance, blank nodes are often used to structure composite pieces of information, such as street addresses, telephone numbers and dates. Using the blank node property list syntax, this kind of pattern can be represented quite conveniently as follows:

Formerly structure composite pieces of information was a reference into [[RDF11-PRIMER]] which does not exist.

Abbreviated:Corresponding simple triples:

As shown, a blank node property lists relies on predicate object lists to easily group statements about blank nodes. We also show the equivalent simple triples using blank node identifiers.

In some cases, using a blank node identifier will simply feel more convenient and natural; e.g., in case you want to describe multiple people with the same address. Of course, we could still use an "inverse" addressOf property to add people with the same address to the blank node property lists, i.e., making :john just another element of the composite piece of information.

Blank node use cases

Below, we summarize typical use cases where blank nodes are used to describe resources.

Unknown resources: we might want to state that the Mona Lisa painting has in its background an unidentified tree, which we know to be a cypress tree. We could mint an IRI such as "mona-lisa-cypress-tree", but we feel that would be redundant — we simply want to describe the tree, such as the painting it is in, and the type of tree. We're not particularly interested in allowing other N3 graphs to refer to the tree. Moreover, there may already exist an IRI for that particular tree, and we don't want to mint another IRI to refer to the same tree (nor do we want to lookup this existing IRI).

Composite information: when describing composite pieces of information, such as street addresses, telephone numbers and dates, it would be quite redundant to mint an IRI just for the purpose of structuring this information. It is unlikely that anyone outside this N3 graph would ever need to refer directly to the IRI. Instead, one can use an RDF blank node to connect the "composed" piece of information, e.g., the street address, to its composite values, e.g., street name, number, and city.

N-ary relations: blank nodes are a convenient way to represent n-ary relations in N3.


We often need to describe collections of things, e.g., a book written by several authors, listing the students in a course, or listing the software modules in a package. N3 provides a succinct collection syntax to represent (possibly empty) collections of terms enclosed by ( ). The contained things are called "members".

To an extent, an N3 collection is equivalent to the more verbose RDF Collection vocabulary.

For instance:


This states that the value of the author property is the collection resource. Important: any additional meaning, e.g., that (a) each member (e.g., :deborah) can be considered as a value of the author property (i.e., the author property "distributes" across the members), or that (b) the first member is the author who put the most effort into the book, is not given by the N3 semantics.

That said, in this example, it would be reasonable to assume these two meanings — i.e., each member is a separate author of the book, and the first member put the most effort in the book. Nevertheless, such meanings would always be application-specific.

This last statement is a little bit problematic since we could see reasoning as some kind of application. Rules could be used to impose one of the meanings. Maybe we could get back to that example when we introduce rules or also with built-ins?

Alternatively, one could represent this information as follows, in such a way that explicates meaning (a):


I.e., we use an object list to explicitly state that these members are separate values of the author property. We no longer need to assume meaning (a) since the RDF semantics already explicates that meaning.

Since N3 / RDF statements do not have an inherent order, this example loses meaning (b) since we no longer know who is the first author.

In the following example, we state that a resolution was approved by a group with members Fred, Wilma, and Dino:


This states that the collection resource consisting of Fred, Wilma, and Dino approved the resolution. As before, the N3 semantics do not imply that Fred, Wilma, and Dino each individually approved the resolution (i.e., the "approvedBy" property does not distribute across the collection members). In contrast to before, such a meaning, which would have to be application-specific, would not make sense either — it is possible that Fred and Wilma formed the majority that approved the resolution, and Dino was the dissenting voice.

In N3, collections may occur as subjects, predicates or objects in a statement. For instance:


Or even:


As before, any meaning that goes beyond the fact that three collection resources are involved in this statement, would be application-specific — for instance, that the predicate (:read :liked :approved) means that the subject collection did all those things for all members in the object collection.

Cited Formulae

It is often useful to attach metadata to groups of triples (such as RDF graphs, named or unnamed) — to give the provenance, context, or version of the information, our opinion on the matter, and so on. We can use cited formulae to quote RDF graphs, and then describe the cited formulae using N3 statements. For instance:


Essentially, a cited formula records of the occurrence of an RDF graph (i.e., a quoting, or citing, of the graph). Importantly, a cited formula does not assert the contents of the RDF graph as being true (e.g., :cervantes dc:wrote :moby_dick). In fact, the cited formula is interpreted as a resource on its own.

Since they represent quoted RDF graphs, cited formulae are not "referentially transparent". For instance:


This N3 statement states that Lois Lane believes that Superman can fly. Even if it is known that :Superman is the same as :ClarkKent, one cannot infer from this that Lois Lane believes that :ClarkKent can fly. In this case, this is an accurate depiction of Lois Lane's statement at the time — she did not know that Superman is Clark Kent at that point, so she would certainly not say that Clark Kent is able to fly.

Cited formulae can be used in any position in an N3 statement. ...


It also useful to describe a relationship between two resources which spans several other anonymous resources. N3 provides a syntax similar to SPARQL property paths [[SPARQL11-QUERY]].

N3 has the concept of a path used to describe a relationship from some N3 triple element to a blank node. In the N3-turtle syntax, a path starts with a pathItem representing a specific N3 triple element followed by a path of one or more predicates, separated by directional indicators for forward ("`!`") and reverse ("`^`") relationships. In the forward direction, a path describes a relationship from a specific N3 triple element (such as an IRI) to a blank node. In the reverse direction, it describes the relationship from a blank node to some N3 triple element. Successive indicator/pathItem pairs describe subsequent relationships with the trailing pathItem describing the relationship predicate.

In SPARQL, a property path is used in the predicate position to describe a string of relationships between a subject and an object resource. Although unrestricted in N3, a resource path is most often used in the subject or object position.

Each path segment can be thought of as a shorthand for an existing relationship. For example, for a predicate |p| and pathItem or path |x|, x!p is equivalent to [ is p of x ]. Similarly, x^p is equivalent to [ p x ]. Thus, the result is always a blank node.

The expansion of a path is equivalent to unwinding these relationships.

Variables and Quantification


Logical Implications


Keywords and special symbols



Terms and Formulae

In order to formally define the semantics of N3, we first give a more formal definition of the basic language concepts introduced in the previous section. Here, we omit constructs like predicate and object lists, or blank node property lists as these can be seen as syntactic sugar.

All examples shown earlier as well as the examples in the remainder of this document follow N3-turtle syntax which is also the standard syntax for N3. It is however possible, to use alternative syntaxes as long as the translation to N3 turtle syntax is clearly defined.

Maybe we put that statement earlier?

N3 is an extension of RDF. We use the following concepts from the [[[RDF11-CONCEPTS]]]: IRI, RDF triple, RDF graph, subject, predicate, object, RDF source, node, blank node, literal, isomorphic, and generalized RDF triples, graphs, and datasets.

We extend these definitions by introducing the following concepts:

The set of N3 triple elements consists of the disjoint sets of IRIs, blank nodes, literals, universal variables, lists, and cited formulae. The set of IRIs conatians the implication sign denoted by the built-in log:implies. This symbol indicates logical implication and MAY in N3-turtle syntax also be represented using the symbols =>. The set of literals contains the two boolean literals false and true. The latter can also be written as {} in N3 turtle syntax.

The set of universal variables is an arbitrary set of symbols which is disjoint to all other N3 triple elements. In N3-turtle syntax, universal variables are represented by strings starting with a question mark ?.

Lists are ordered sets consisting of zero or more N3 triple elements. We call the list which has no elements the empty list. In N3-turtle syntax, we indicate lists by using round brackets (). The empty list in N3 is equivalent to the empty list in RDF and can thus also be represented using rdf:nil.

Cited formulae (sometimes also called quoted graphs) are N3 formulae which are surrounded by quoting signs. In N3-turtle syntax, we denote these quoting signs as curly brackets {}.

An N3 triple consists of the three components subject, predicate and object, each being an N3 triple element.

An N3 formula is a set of N3 triples.

Let T be the set of N3 triple elements and dc:T⟶T a function defined as follows:

For each N3 triple t= s p o we call the set dc(t)=dc(s)∪dc(p)∪dc(o) the direct components of t. For each N3 formula the set of its direct components is the union of the direct components of the triples it contains.

Let T be the set of N3 triple elements and F the set of N3 formula. We define the function nc:T∪F⟶T a function defined as follows:

For each N3 formula f, we call nc(f) the set of nested components.

We call an N3 formula ground if its direct and nested components do not contain blank nodes nor universal variables.

We call an N3 formula closed if its direct and nested components do not contain universal variables and its direct components do not contain blank nodes.

ReSpec complains because ground and closed are defined but not used.

Simple N3 interpretations

Scoped Negation

N3 Built-ins

N3 defines a core set of built-ins defined in a set of vocabularies with defined semantics for querying and manipulating N3 documents. Built-ins are denoted by a controlled IRI defined in one of the core namespaces:

EBNF Grammar

The Turtle grammar was used as the starting point for the N3 grammar, which was subsequently adapted and extended with N3 constructs.

The N3 Working Group made the following decisions that modify the N3 grammar as originally presented in [[N3]]:


White space (WS production) is used to separate terminals. The amount and type of white space (e.g., newline (`%20`) or space (`%0A`)) is only significant within terminals.

We note that the IRIREF production only allows IRI-encoded white spaces.


Comments are indicated using a "#" symbol outside an N3 terminal (e.g., IRIREF, STRING) and will continue until the end of the line (indicated by \r, \n or \f) or end of file, if there is no end of line marker.

All recognized comment terminals will be skipped by the grammar (i.e., a resulting parser will not call listener or visitor code when encountering a comment.)

Escape sequences

There are three forms of escapes used in N3 documents:

IRI resolution

Relative IRIs are resolved with base IRIs using the algorithm in [[[RFC3986]]] [[RFC3986]] Section 5.2 "Relative Resolution" as supplemented by Section 6.5 of [[[RFC3987]]] [[RFC3997]].

The N3 @base or BASE directive can be used to define the Base IRI, per [[RFC3986]] Section 5.1.1 "Base URI Embedded in Conent". Each `@base` or `BASE` directive sets a new In-Scope Base IRI, relative to the previous base IRI.

Path resolution

Paths are resolved into zero or more N3 triples and a single N3 triple element which is used as the expression value of the path.

This section describes two logically equivalent algorithms for transforming a path into a set of N3 triples, and providing a resource to use as the effective subject, predicate, or object in place of the original path expression.

Right to Left Algorithm

The first algorithm describes a means of processing a path starting from the right hand side of the path. This is essentially the algorithm described in the Team Submission. This is useful for an implementation based processing an Abstract Syntax Tree generated by a parser, or where the entire path is treated as a token and language-specific tools are used to process it further.

Processing is performed by recursively processing the path |p|, in reverse, from the last directional indicator ("`!`") or ("`^`"). The result of resolving |p| into an expression and set of emitted N3 triples MUST be equivalent to using the following algorithm:

  1. If |p| matches the pathItem production, then |p| can be reduced no further, return |p| as the result.
  2. Otherwise, separate the |p| into two components pn-1 and predn on the last occurrence of the directional indicator dirn.
  3. Create objn by invoking this algorithm recursively using pn-1 for |p|.
  4. Create a novel blank node Bn.
  5. If dirn is "`!`", emit a new N3 triple (objn predn Bn).
  6. Otherwise, dirn is "`^`", emit a new N3 triple (Bn predn objn).
  7. Return Bn as the result.

Left to Right Algorithm

The second algorithm describes a means of processing a path starting from the left hand side of a path. This is useful for an implementation based on the parser productions described in the grammar that create events in this order (i.e., event-based).

Processing is performed by iteratively processing the path p, in the forward direction, from the first directional indicator (`"!"`) or (`"^"`). The result of resolving p into an expression and set of emitted N3 triples MUST be equivalent to using the following algorithm:

Initialize |n| to `0` and B0 to the first pathItem in |p|. Repeat the following algorithm steps until return.

B0 starts as the first pathItem in |p|, but is updated to a novel blank node on subsequent iterations.

  1. If |n| equals the number of directional indicators in |p|, return Bn.
  2. Increment |n|, set Bn to a novel blank node, set dirn to the next (nth) directional indicator dirn (if any), set predn to the next pathItem (if any).
  3. If dirn is "`!`", emit a new N3 triple (Bn-1 predn Bn).
  4. Otherwise, if dirn is "`^`", emit a new N3 triple (Bn predn Bn-1).


A textual version of this grammar may be found here.

Relationship to Other Languages


N3 is a superset of [[[turtle]]], meaning that all valid Turtle documents will be valid in N3 as well. The inverse is not true, i.e., a valid N3 document will not always be valid in Turtle.

The current N3 grammar started from the Turtle grammar which was adapted and extended to be in line with the original N3 grammar. Hence, many of the grammar productions will be much more similar to the Turtle grammar than the initial N3 grammar.

Important differences with Turtle are the following:


The SPARQL 1.1 Query Language (SPARQL) [[SPARQL11-QUERY]] uses a Turtle-style [[turtle]] syntax for its TriplesBlock production. Differences between Turtle and SPARQL are elaborated in the Turtle specification.

Below, we indicate some important differences between this production and N3:

For more information, see the SPARQL Grammar section of [[[SPARQL11-QUERY]]].


[[[TRIG]]] is itself a superset of the Turtle syntax and includes a compact way to write RDF datasets, i.e., sets of named graphs. In particular, TriG allows the specification of so-called graph statements, which are a pair of an IRI or blank node label and a group of triple statements surrounded by "{" and "}".

For instance:


N3 is not directly compatible with TriG as it does not support this graph statement notation. Nevertheless, since N3 supports quoted graphs (i.e., cited formulae) as part of regular N3 statements, authors can utilize the N3 Named Graphs extension [X] for associating names or identifiers with cited formulae. Although applications could easily introduce their own custom predicates for this purpose, we strongly recommend the use of this extension for interoperability purposes.

The N3 Named Graphs extension [X] defines a set of built-ins (used as predicates) to associate names or identifiers with cited formulae, which then become "named graphs". Moreover, each predicate has a well-defined semantics on how the named graph should be interpreted: as quoted graphs (the default N3 interpretation), a partitioning of triples within a dataset context, sets of triples with their own isolated contexts, or specifying relations between local and online graphs.

Design Patterns

In this section, we present common patterns to solve often-occurring problems, for instance regarding data modeling, in N3.

N-ary Relations

Until now, we only considered binary relations between entities and/or values. But, many types of relations are ternary, quaternary, or, in general, n-ary in nature, i.e., they have an arbitrary number of participants. Typical examples are purchase, employment, membership, .. relations.

In other cases, we want to describe properties of relations — such as the provenance of a piece of information, or the probability of a diagnosis. But, in essence, this is the same problem as representing n-ary relations.

There are several ways of representing n-ary relations in RDF — these are described in [[[swbp-n-aryRelations]]].

Below, we illustrate options for representing n-ary relations in N3 in particular.

Using sets of binary relations

In general, it is possible to convert any n-ary relation into an equivalent set of binary relations. This is a convenient solution, since we already know how to represent binary relations.

First, we create a resource that represents the n-ary relation, and then use a set of binary relations to link each participant to this newly minted resource. Each binary relation is hereby given a meaningful name that represents the role of the participant in the n-ary relation.

For instance, say we want to describe the Purchase relation between a buyer called "John", a purchased book called "Lenny the Lion", the amount paid for the book, and the seller:



Either you could mint a new IRI for representing the n-ary relation, or simply use a blank node. E.g., in case other parties may want to refer to the n-ary relation from outside the N3 graph, one could choose to mint a new IRI; else, it will likely be more convenient to use a blank node property list.

In other cases, things are more naturally described as properties of relations, rather than n-ary relations — for instance, the provenance of a piece of information, the trend of someone's body temperature and when the temperature was taken. Nevertheless, these can be represented in the same way as n-ary relation participants.

We start from the same solution above, i.e., introducing a resource to represent the (in this case, binary) relation, and then linking the two participants to this resource. Subsequently, we use a set of binary relations to attach each descriptive property (e.g., diagnosis probability; temperature trend) to the relation resource.

For instance, when describing someone's (e.g., Christine) current temperature, you may want to indicate the absolute value (e.g., 40 degrees), a description of that value (e.g., elevated), the trend compared to the prior value (e.g., rising), and the time the temperature was taken:


This is possible since we know that the relation resource (e.g., to1) represents the n-ary relation. Hence, any descriptive properties of the relation, in addition to participants in the relation, can simply be attached to the entity.

In this example, we made a statement with one of the participants (:Christine) as subject, and the relation resource (e.g., _:to1) as object. An alternative would have been to add :Christine as just another element of the n-ary relation, e.g., using a property temperatureOf. Our modeling choice here served to indicate that Christine is somehow the "owner" of the relationship.

Using collections

An even easier solution is to use a collection to keep all the participants of the n-ary relation. For instance: ... A clear advantage of this approach is that it is easier and much less verbose to write down. However, the roles each participant play in the n-ary relation are no longer explicated. For instance: .. What roles do X, Y and Z play in this relation? One could answer that question by having a tailored schema: ...

Compound literal

This solution is inspired by a separate discussion of the RDF community on Language Tagged Strings. The essence of the discussion is to separate the string, as a simple data, from all the various characterizations that may be added to it. This design pattern uses the rdf:CompoundLiteral class, which is in the domain of rdf:language and rdf:direction to be used for describing RDF literal values containing base direction and a possible language tag to be associated with the string value of rdf:value on the same subject.


Graph quoted inside another graph

Reification in the RDF context means the expression of something in a language using the language so that it becomes treatable by the language. RDF graphs consist of RDF statements. If one wants to look objectively at an RDF graph and reason about it is using RDF tools, then it is useful to have a mechanism for describing RDF statements. N3 extends RDF to allow graphs themselves to be another form of literal node. A graph can be quoted inside another graph, as in the example:


The above example can also be seen as RDF reification:


Embedding N3 in HTML documents

HTML [[HTML5]] script element can be used to embed data blocks in documents. N3 can be easily embedded in script with the type attribute set to text/n3.

Such content may be escaped as indicated below:


When embedded in XHTML N3 data blocks must be enclosed in CDATA sections. Those CDATA markers must be in Turtle comments. If the character sequence ]]> occurs in the document it must be escaped using strings escapes (\u005d\u0054\u003e). This will also make N3 safe in polyglot documents served as both text/html and application/xhtml+xml. Failing to use CDATA sections or escape ]]> may result in a non well-formed XML document.

Check this, I don't think that CDATA is required for XHTML any longer. See .


Internet Media Type, File Extension and Macintosh File Type

This section has been submitted to the Internet Engineering Steering Group (IESG) for review, approval, and registration with IANA.

Type name:
Subtype name:
Optional parameters:
charset — this parameter is required when transferring non-ASCII data. If present, the value of charset is always UTF-8.
Encoding considerations:
The syntax of Notation3 is expressed over code points in Unicode [[UNICODE]]. The encoding is always UTF-8 [[UTF-8]]. Unicode code points may also be expressed using an \uXXXX (U+0000 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-Fa-f]
Security considerations:
Notation3 is a general-purpose assertion language; 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. Notation3 is used to express arbitrary application data; security considerations will vary by domain of use. Security tools and protocols applicable to text (e.g. PGP encryption, MD5 sum validation, password-protected compression) may also be used on Notation3 documents. Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information. Notation3 can express data which is presented to the user, for example, RDF Schema labels. Application rendering strings retrieved from untrusted Notation3 documents must ensure that malignant strings may not 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. Notation3 uses IRIs as term identifiers. Applications interpreting data expressed in Notation3 should address the security issues of Internationalized Resource Identifiers (IRIs) [[RFC3987]] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [[RFC3986]] Section 7. Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (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 Notation3 must take care to use the IRI that matches the intended semantics, and avoid IRIs that make look similar. Further information about matching of similar characters can be found in Unicode Security Considerations [[UNICODE-SECURITY]] and Internationalized Resource Identifiers (IRIs) [[RFC3987]] Section 8.
Interoperability considerations:
Not Applicable
Published specification:
This specification.
Applications which use this media type:
Any programming environment that requires the exchange of directed graphs. Implementations of Notation3 have been created for JavaScript, Python, Java, and Prolog. It may be used by some web services and clients consuming their data.
Additional information:
Magic number(s):
Notation3 documents may have the strings 'prefix' or 'base' (case independent) near the beginning of the document.
File extension(s):
Macintosh file type code(s):
Person & email address to contact for further information:
Intended usage:
Restrictions on usage:
Dörthe Arndt, William Van Woensel, Dominik Tomaszuk
Change controller:

Changes since the Team Submission

The following is a summary of changes made since the original Team Submission [[N3]]:

There are more accumulated changes to account for, to be sure.


The editors acknowledge valuable contributions from...