This document is one of ten RDF 1.2 and twelve SPARQL 1.2 documents produced by theRDF-star Working Group.

The core structure of the abstract syntax is a set oftriples, each consisting of asubject, apredicate and anobject. A set of such triples is called anRDF 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.

There can be four kinds ofnodes in anRDF graph:IRIs,literals,blank nodes, andtriple terms.

AnyIRI orliteraldenotes something in the world (the "universe of discourse"). These things are calledresources. Anything can be a resource, including physical things, documents, abstract concepts, numbers and strings; the term is synonymous with "entity" as it is used inRDF 1.2 Semantics [RDF12-SEMANTICS]. The resource denoted by anIRI is called itsreferent, 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 anddirectional 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 anRDF triple says thatsome relationship, indicated by thepredicate, holds between theresourcesdenoted by thesubject andobject. This statement corresponding to an RDF triple is known as anRDF statement. The predicate itself is anIRI and denotes aproperty, that is, aresource 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].)

UnlikeIRIs andliterals,blank nodes do not identify specificresources.Statements involving blank nodes say that something with the given relationships exists, without explicitly naming it.

Theresourcedenoted by anIRI is also called itsreferent. 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 givenIRI is not defined by this specification. Other specifications may fixIRI referents, or apply other constraints on what may be the referent of anyIRI.

Guidelines for determining thereferent of anIRI are provided in other documents, likeArchitecture of the World Wide Web, Volume One [WEBARCH] andCool URIs for the Semantic Web [COOLURIS]. A very brief, informal, and partial account follows:

• By design, IRIs have global scope. Thus, two different appearances of anIRIdenote the sameresource. Violating this principle constitutes anIRI collision [WEBARCH].
• By social convention, theIRI owner [WEBARCH] gets to say what the intended (or usual) referent of anIRI is. Applications and users need not abide by this intended denotation, but there may be a loss of interoperability with other applications and users if they do not do so.
• TheIRI owner can establish the intendedreferent by means of a specification or other document that explains what is denoted. For example, theThe Organization Ontology [VOCAB-ORG] specifies the intended referents of various IRIs that start withhttp://www.w3.org/ns/org#.
• A good way of communicating the intended referent is to set up theIRI so that itdereferences [WEBARCH] to such a document.
• Such a document can, in fact, be anRDF document that describes the denoted resource by means ofRDF statements.

Perhaps the most important characteristic ofIRIs 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 ofLinked Data Design Issues, [LINKED-DATA], which makes use of the RDF data model and serialization formats.

AnRDF vocabulary is a collection ofIRIs intended for use inRDF 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].

TheIRIs in anRDF vocabulary often begin with a common substring known as anamespaceIRI. Some namespace IRIs are associated by convention with a short name known as anamespace prefix. Some examples:

In some serialization formats it is common to abbreviateIRIs that start withnamespace IRIs by using anamespace prefix in order to assist readability. For example, theIRIhttp://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral would be abbreviated asrdf:XMLLiteral. Note however that these abbreviations arenot valid IRIs, and must not be used in contexts where IRIs are expected. Namespace IRIs and namespace prefixes arenot 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 “namespaceIRI” or “RDF vocabulary”.

Atriple term is anRDF triple used as anRDF term in theobject position of another triple.

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

Atriple term can be used as the object of atriple with the predicaterdf:reifies; such atriple is then areifying triple. Thesubject of thattriple is called areifier. Assertions on thetriple term are made using thereifier. A concrete syntax may provide a special notation for specifyingreifying triples.

The following diagram represents a statement and a reification of an unassertedtriple term.

A variation on the graph shown inFigure2 can be described where thetriple term is alsoasserted.

Note that atriple term may also have anothertriple term as anobject.

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

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

SinceRDF graphs are defined as mathematical sets, adding or removingtriples from an RDF graph yields a different RDF graph.

We informally use the termRDF source to refer to a persistent yet mutable source or container ofRDF graphs. An RDF source is aresource 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 withIRIs and therefore described in other RDF graphs.

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

• AnIRI, once minted, should never change its intendedreferent. (SeeURI persistence [WEBARCH].)
• Literals, by design, are constants and never change theirvalue.
• A relationship that holds between tworesources at one time may not hold at another time.
• RDF sources may change their state over time. That is, they may provide differentRDF graphs at different times.
• SomeRDF sources may, however, be immutable snapshots of another RDF source, archiving its state at some point in time.

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.

AnRDF dataset is a collection ofRDF graphs. All but one of these graphs have an associatedIRI or blank node. They are callednamed graphs, and theIRI or blank node is called thegraph name. The remaining graph does not have an associatedIRI, and is called thedefault graph of the RDF dataset.

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

AnRDF triple encodes aproposition — a simple logical expression, describing a relationship between two entities. Anasserted triple is a claim that the corresponding proposition is true. AnRDF graph is the conjunction (logicalAND) of all the claims made by itsasserted triples. The precise details of this meaning ofRDF triples andRDF graphs are the subject ofRDF 1.2 Semantics [RDF12-SEMANTICS], which yields the following relationships betweenRDF graphs:

Entailment

AnRDF graphA entails another RDF graphB if every possible arrangement of the world that makesA true also makesB true. WhenA entailsB, if the truth ofA is presumed or demonstrated then the truth ofB is established.

Equivalence

TwoRDF graphsA andB are equivalent if they make the same claim about the world.A is equivalent toB if and only ifAentailsB andB entailsA.

Inconsistency

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

Anentailment 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 asRDF 1.2 Schema [RDF12-SCHEMA] andOWL 2 [OWL2-OVERVIEW], add more powerful entailment regimes, as do some domain-specificvocabularies.

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 noentailed information available to users.

AnRDF document is a document that encodes anRDF graph orRDF dataset in aconcrete RDF syntax, such as 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.

Aconcrete RDF syntax may offer many different ways to encode the sameRDF 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 theRDF document, they are not significant for its meaning.

RDF uses Unicode [Unicode] as the fundamental representation for string values. Within this, and related specifications, the termstring, orRDF string, is used to describe an ordered sequence of zero or moreUnicode code points which areUnicode scalar values. Unicode scalar values do not include thesurrogate code points. Note that mostconcrete 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 implementationMAY determine string equality by comparing thecode units of two strings that use the sameUnicode character encoding (UTF-8 or UTF-16) without decoding the string into aUnicode code point sequence.

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

• Ifs is anIRI or ablank node,p is anIRI, ando is anIRI, ablank node, or aliteral, then (s,p,o) is anRDF triple.
• Ifs is anIRI or ablank node,p is anIRI, ando is anRDF triple, then (s,p,o) is anRDF triple.

The three components (s,p,o) of anRDF triple are respectively called thesubject,predicate andobject of the triple.

The set ofnodes of anRDF graph is the set ofsubjects andobjects of theasserted triples of the graph. It is possible for apredicateIRI to also occur as anode in the same graph.

Triple equality: Two triples (s,p,o) and (s',p',o') are equal (the sameRDF triple) if and only if all of the following three conditions hold.

• s ands' areequal.
• p andp' areequal.
• o ando' areequal.

IRIs,literals,blank nodes, andtriple terms are collectively known asRDF terms.

IRIs,literals andblank nodes are said to beatomicRDF terms.

RDF term equality: TwoRDF termst andt' are equal (the sameRDF term) if and only if one of the following four conditions holds:

• t andt' areIRIs that areequal (perIRI equality).
• t andt' areliterals that areequal (perliteral term equality).
• t andt' areblank nodes that areequal (perblank node equality).
• t andt' aretriple terms that areequal (pertriple equality).

The set ofRDF termsappearing in anRDF triplet is defined inductively as follows:

• Thesubject,predicate andobject oftappear int.
• If theobject oft is anRDF triplet2, then anyRDF termappearing int2 alsoappears int.

By extension, anRDF term is said toappear in anRDF graph if it appears in anasserted triple of that graph. AnRDF triple is said toappear in anRDF graph if it is either anasserted triple of that graph or atriple termappearing in that graph.

AnRDF term is said to beground if it is anIRI, aliteral, or atriple term in which onlyground termsappear. By extension, anRDF triple is said to beground if itssubject,predicate, andobject are all ground. AnRDF graph is said to beground if all itsasserted triples areground.

AnIRI (Internationalized Resource Identifier) within an RDF graph is astring that conforms to the syntax defined in RFC 3987 [RFC3987].

AnIRI in the RDF abstract syntaxMUST beresolved per [RFC3986] andMUST NOT be arelative reference. AnIRIMAY contain afragment identifier. AnIRISHOULD follow rules defined by theIRI 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 normalizationMUST NOT be performed before this comparison.

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

Aliteral in anRDF graph consists of two, three, or four elements, as follow:

1. Alexical form, being anRDF string.
2. AdatatypeIRI, being anIRI identifying a datatype that determines how the lexical form maps to aliteral value.
3. If and only if thedatatypeIRI ishttp://www.w3.org/1999/02/22-rdf-syntax-ns#langString orhttp://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString, a non-emptylanguage tag as defined by [BCP47]. The language tagMUST be well-formed according tosection 2.2.9 of [BCP47], andMUST be treated accordingly, that is, in a case insensitive manner. Two [BCP47]-complying strings that differ only by case represent the samelanguage tag.
4. If and only if thedatatypeIRI ishttp://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString, abase direction thatMUST 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 alanguage-tagged string if the third element is present and the fourth element is not present. A literal is adirectional language-tagged string if both the third element and fourth elements are present.

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

• The twolexical forms compare equal, where this comparison is performed usingcase-sensitive matching (see description of string comparison in2.1Strings in RDF).
• The twodatatype IRIs compareequal (perIRI equality).
• The twolanguage tags are either both absent, or both present and compare equal, where this comparison is performed usingASCII case-insensitive matching (in contrast to the case-sensitive comparison of the lexical forms).
• The twobase directions are either both absent, bothltr, or bothrtl.

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

Blank nodes are disjoint fromIRIs andliterals. 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.

AnRDF triple used as theobject of anothertriple is called atriple term. In a givenRDF graph, atriple can appear as atriple term, anasserted triple, or both.

Triple term equality: Since triple terms aretriples, equality of triple terms is the same astriple equality.

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

A functionM from the set of allRDF terms into that same set is called anisomorphic RDF-term mapping if it is has all of the following properties:

• M is bijective.
• For everyblank nodeb,M(b) is ablank node (but not necessarily the same asb).
• For everyliterallit,M(lit) islit.
• For everyIRIiri,M(iri) isiri.
• For everytriple termtt of the form (s,p,o),M(tt) is the triple term (M(s),M(p),M(o) ).

TwoRDF graphsG andG' areisomorphic (that is, they have the same form) if there exists anisomorphic RDF-term mappingM such that the triple (s,p,o) is inG if and only if the triple (M(s),M(p),M(o) ) is inG'.

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

This section is non-normative.

Thebase direction of adirectional 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. TheUnicode 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'sdir attribute) it can then be correctly presented as:

In the absence of an explicit initial text direction, theUnicode 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 avoidspillover effects, users need to employbidi 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 "ספרים בינלאומיים!"

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, systemsMAY systematically replace some or all of the blank nodes in an RDF graph withIRIs. Systems wishing to do thisSHOULD mint a new, globally uniqueIRI (aSkolemIRI) 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 the possibility of other graphs subsequently using the Skolem IRIs, which is not possible for 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 boundariesSHOULD use a well-knownIRI [RFC8615] with the registered namegenid. This is anIRI 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 SkolemIRI:

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

TwoRDF datasetsD1 andD2 (respectively, withdefault graphsDG1 andDG2 and setsNG1 andNG2 ofnamed graphs) aredataset-isomorphic if and only if there exists anisomorphic RDF-term mappingM for which all of the following properties hold:

• The triple (s,p,o) is inDG1 if and only if the triple (M(s),M(p),M(o) ) is inDG2.
• Thenamed graph (n,G) is inNG1 if and only if there is anamed graph (n',G') inNG2 such that the following are true:
  • M(n) isequal ton'.
  • For every triplet=(s,p,o), it holds thatt is inG if and only if the triple (M(s),M(p),M(o) ) is inG'.

This section is non-normative.

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 bothRDF datasets andRDF graphs. If anRDF dataset is returned and the consumer is expecting anRDF graph, the consumer is expected to use theRDF dataset's default graph.

This section is non-normative.

Aquad is atriple associated with an optionalgraph name and is used when referring to triples within anRDF dataset.

Aquad can be represented as a tuple composed ofsubject,predicate,object, and an optionalgraph name.

AnRDF dataset can be considered to be a set ofquads where quads with nograph name supply thetriples of thedefault graph, and quads with the same graph name supply the triples of thenamed graph with that name.

IRIs of the formhttp://www.w3.org/2001/XMLSchema#xxx, wherexxx is the name of a datatype, denote the built-in datatypes defined inW3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes [XMLSCHEMA11-2]. The XML Schema built-in types listed in the following table are theRDF-compatible XSD types. Their use isRECOMMENDED.

Readers might note that the only safe datatypes for transferring binary information arexsd:hexBinary andxsd:base64Binary.

Thelexical-to-value mapping forxsd:float andxsd:doubleMUST use a method consistent withdoubleLexicalMap, whichMUST strictly conform to the rounding method described infloatPtRound [XMLSCHEMA11-2].

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

• xsd:QName andxsd:ENTITY require an enclosing XML document context.
• xsd:ID andxsd:IDREF are for cross references within an XML document.
• xsd:NOTATION is not intended for direct use.
• xsd:IDREFS,xsd:ENTITIES andxsd:NMTOKENS are sequence-valued datatypes which do not fit the RDFdatatype model.

Datatypes are identified byIRIs.

If anyIRI of the formhttp://www.w3.org/2001/XMLSchema#xxx is handled by an RDF implementation, itMUST refer to the RDF-compatible XSD type namedxsd:xxx for every XSD type listed insection 5.1.

The datatypes identified by the three IRIs below are defined in Appendix A.Additional Datatypes:

• TheIRIhttp://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral refers to the datatyperdf:XMLLiteral.
• TheIRIhttp://www.w3.org/1999/02/22-rdf-syntax-ns#HTML refers to the datatyperdf:HTML.
• TheIRIhttp://www.w3.org/1999/02/22-rdf-syntax-ns#JSON refers to the datatyperdf:JSON.

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 unknownIRI, i.e., as referring to an unknown thing. ApplicationsMAY give a warning message if they are unable to determine the referent of anIRI used in a typed literal. RDF implementationsSHOULD NOT reject a literal with an unknown datatype as either a syntactic or semantic error.

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

Encoding anRDF graph to ensure that it is consumable by an RDFClassic implementation is calledclassicizing it.Classicizing consists of repeating the following steps until notriple termappears in the graph, and the graph is therefore compliant with RDFClassic: picking atriple termtt thatappears in the graph; minting a freshblank nodeb (i.e., a blank node not yet in use in the graph); replacing all occurrences ofttappearing in the graph withb; and then adding the following triples to the graph (wheres,p, ando are respectively thesubject,predicate andobject oftt):

• (b,rdf:type,rdf:TripleTerm)
• (b,rdf:ttSubject,s)
• (b,rdf:ttPredicate,p)
• (b,rdf:ttObject,o)

Note that this transformation isinformation preserving only when the input graph either has notriple termappearing in it, or contains noasserted triple (b,rdf:type,rdf:TripleTerm) whereb is ablank node. Implementations encountering this situationMUST report an error. This limitation is discussed in Section 8.3Limitations.

Classicizing anRDF dataset consists ofclassicizing itsdefault graph and each of itsnamed graph. In this case, the freshblank node assigned to eachtriple term must not be used in any graph of the dataset.

A detailed algorithm of the transformation is found in Section8.4.1Theclassicize algorithm.

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>PREFIX ex: <http://example.org/><< ex:s ex:p ex:o >> ex:q "some value".

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>PREFIX ex: <http://example.org/>_:r1 rdf:reifies <<( ex:s ex:p ex:o )>>._:r1 ex:q "some value".

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>PREFIX ex: <http://example.org/>_:r1 rdf:reifies _:gen1._:r1 ex:q "some value"._:gen1 a rdf:TripleTerm ;  rdf:ttSubject ex:s;  rdf:ttPredicate ex:p;  rdf:ttObject ex:o.

Reverting aclassicized graph to its original form consists of locating eachasserted triple (b,rdf:type,rdf:TripleTerm) that has ablank nodeb as its subject, along with the three associatedasserted triples that have the sameblank nodeb 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 ofbappearing in the graph with the triple term (s,p,o).

An implementationMUST report an error if, for a givenb, it can not unambiguously determines,p, oro (i.e., if one of the properties ofb —rdf:ttSubject,rdf:ttPredicate, orrdf:ttObject — is missing or duplicated). An implementationMUST also report an error if the input graph contains at the same time atriple term and anasserted triple (b,rdf:type,rdf:TripleTerm) whereb is the sameblank node. Note that none of these situations can occur if the input graph was produced by theclassicize transformation.

To revert aclassicizedRDF dataset to its original form, the transformation above is applied to itsdefault graph and to each of itsnamed graphs.

Note that this transformation has no effect on anyRDF graph orRDF dataset that does not use therdf:TripleTerm type, includingFull graphs or datasets containingtriple terms. This makes this transformationidempotent as intended.

The two transformations above explicitly do not support graphs or datasets containing at the same time atriple term and anasserted triple (b,rdf:type,rdf:TripleTerm) whereb is ablank node. This means that theclassicize transformation is notstrictly universal.

This limitation should not be an issue in practice. Therdf: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 theclassicize transformation, and not used otherwise.

Another consequence of this restriction is that implementers will need to be aware and careful when merging graphs in an application thatclassicizes graphs or datasets. The concern is that merging aFullRDF graph containing at least onetriple term with aclassicizedRDF graph (which might containblank node instances ofrdf:TripleTerm) could result in a "hybrid" graph that cannot be transformed to a consistentFull norClassicRDF graph. Therefore, such applications shouldclassicize every graph prior to merging them. Conversely, applications supporting RDFFull should make sure to apply the reverse transformation to any graph that is known or likely to have beenclassicized, to avoid creating such "hybrid" graphs. Since these transformations are designed to beidempotent, there is no harm in applying them more than necessary.

RDF provides for HTML content as a possibleliteral value. This allows markup in literal values. Such content is indicated in anRDF graph using aliteral whosedatatype is set tordf:HTML.

Therdf:HTML datatype is defined as follows:

TheIRI denoting this datatype

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

Thevalue space

is the set of DOMDocumentFragment nodes [DOM]. TwoDocumentFragment nodesnode andotherNode are considered equal if and only if the DOM methodnode.isEqualNode(otherNode) [DOM] returnstrue.

The lexical-to-value mapping

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

• Letdomnodes be the list ofDOM nodes [DOM] that result from applying theHTML fragment parsing algorithm [HTML5] to the input string, without a context element.
• Letdomfrag be a DOMDocumentFragment [DOM] whosechildNodes attribute is equal todomnodes
• Returndomfrag.normalize().

RDF provides for XML content as a possibleliteral value. Such content is indicated in anRDF graph using aliteral whosedatatype is set tordf:XMLLiteral.

Therdf:XMLLiteral datatype is defined as follows:

TheIRI denoting thisdatatype

ishttp://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral.

Thelexical space

is the set of allstrings which are well-balanced, self-containedXML content [XML11]; and for which embedding between an arbitrary XML start tag and an end tag yields a document conforming toNamespaces in XML 1.0 (Third Edition) [XML-NAMES].

Thevalue space

is the set of DOMDocumentFragment nodes [DOM]. TwoDocumentFragment nodesnode andotherNode are considered equal if and only if the DOM methodnode.isEqualNode(otherNode) returnstrue.

Thelexical-to-value mapping

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

• Letdomfrag be a DOMDocumentFragment node [DOM] corresponding to the input string.
• Returndomfrag.normalize().

RDF provides for JSON content as a possibleliteral value. This includes allowing markup in literal values. Such content is indicated in anRDF graph as aliteral whosedatatype is set tordf:JSON.

Therdf:JSON datatype is defined as follows:

TheIRI denoting thisdatatype

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

Thelexical space

is the set of allRDF strings that conform to theJSON Grammar as described inSection 2 JSON Grammar of [RFC8259], which also conform to the requirements ofThe I-JSON Message Format [RFC7493].

Note

The JavaScript Object Notation (JSON) Data Interchange Format [RFC8259] allows strings to includesurrogate code points not allowed inRDF strings, which are also excluded in [RFC7493], thus the lexical representation of JSON literals excludes those includingsurrogate code points.

Thevalue space

is the smallest set containingstrings, numbers (xsd:double),maps (mappingstrings to values in thevalue space where the order ofmap entries is not significant),lists (of values in thevalue space), and literal values (true,false, andnull) fromInfra Standard [INFRA] andW3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes [XMLSCHEMA11-2].

Note

The value space ofmaps andlists does not include values having themselves as members, which cannot be represented in JSON.

Two values (a andb) are considered equal if any of the following are true:

• They are the samestring, number (xsd:double), or literal value.
• They are bothlists containingitems which are pairwise equal – meaning that eachitem ina is equal theitem at the corresponding index inb, and botha andb have the samesize.
• They are bothmaps with equalentries – meaning that for each entrye_a ina there exists an entrye_b inb such that thekey ine_a equals thekey ine_b, thevalue ine_a equals thevalue ine_b, and botha andb have the samesize.
  Note

  Two JSON Objects containing maps which are serialized with entries in a different order will be equal under this definition when transformed to the value space. For example,{ "a": 1, "b": 2 } and { "b": 2, "a": 1 } are considered equal. As a result of the value space being defined using terminology from [INFRA], property values which can contain more than one item, such aslists andmaps, are explicitly ordered. All list-like value structures in [INFRA] are ordered, whether or not that order is significant. For the purposes of this specification, unless otherwise stated,map ordering is not important and implementations are not expected to produce or consume deterministically ordered values.

Thelexical-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, andnull).

• AJSON Object is mapped to amap by transforming each object member into amap entry with thekey taken from the member name andvalue taken by performing this mapping to the member value.Map entries are treated as being unordered.
• AJSON Array is mapped to alist such that thislist contains as many elements as theJSON Array and, for every positioni in thearray, the element at thei-th position in thelist is the value that results from applying this mapping to thei-th element of thearray.
• AJSON Number is mapped to anxsd:double using a method consistent withdoubleLexicalMap, whichMUST strictly conform to the rounding method described infloatPtRound [XMLSCHEMA11-2].
  Note

  Some numbers cannot be represented as finitexsd:double values and may map to+INF or-INF. Such values cannot be represented as JSON Numbers, limiting the ability to serialize such values back to JSON.
• AJSON String is mapped to astring after converting any escape sequences to the associatedUnicode code point.
• AJSON literal name maps JSONtrue,false, andnull values to [INFRA]true,false, andnull values, respectively.

This section is non-normative.

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 theW3C 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).

This section is non-normative.

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.

This section is non-normative.

In addition to the editors, the following people have contributed to this specification:Denis Ah-Kang, Dominik Tomaszuk, Niklas Lindström, Peter F. Patel-Schneider, Sarven Capadisli, Ted Thibodeau Jr, and Thomas Tanon

Members of the RDF-star Working Group Group included Vladimir Alexiev, Amin Anjomshoaa, Julián Arenas-Guerrero, Dörthe Arndt, Bilal Ben Mahria, Erich Bremer, Kurt Cagle, Rémi Ceres,Pierre-Antoine Champin, Souripriya Das, Daniil Dobriy, Enrico Franconi, Jeffrey Phillips Freeman, Fabien Gandon, Benjamin Goering, Adrian Gschwend, Olaf Hartig, Timothée Haudebourg, Ian Horrocks, Gregg Kellogg, Mark Kim, Jose Emilio Labra Gayo, Ora Lassila, Richard Lea, Niklas Lindström, Pasquale Lisena, Thomas Lörtsch, Matthew Nguyen, Peter Patel-Schneider, Thomas Pellissier Tanon, Dave Raggett, Jean-Yves ROSSI, Felix Sasaki, Andy Seaborne, Ruben Taelman, Ted Thibodeau Jr, Dominik Tomaszuk, Raphaël Troncy, William Van Woensel, Gregory Williams, Jesse Wright, Achille Zappa, and Antoine Zimmermann.

• appearing§3.2
• asserted§3.
• atomic§3.2
• base direction§3.4
• base IRI§3.3
• Blank node equality§3.5
• Blank node identifiers§3.5
• Blank nodes§3.5
• Classic conformance§2.
• classicizing§8.1
• concrete RDF syntax§1.9
• dataset-isomorphic§4.1
• datatype§5.
• datatype IRI§3.4
• default graph§4.
• denotes§1.2
• directional language-tagged string§3.4
• Entailment§1.8
• Equivalence§1.8
• fragment identifiers§6.
• Full conformance§2.
• generalized RDF dataset§7.
• generalized RDF graph§7.
• generalized RDF triple§7.
• graph name§4.
• ground§3.2
• ill-typed§3.4.2
• Inconsistency§1.8
• IRI§3.3
• IRI equality§3.3
• IRI references§3.3
• isomorphic§3.7
• isomorphic RDF-term mapping§3.7
• language tag§3.4
• language-tagged string§3.4
• lexical form§3.4
• lexical space§5.
• lexical-to-value mapping§5.
• literal§3.4
• Literal term equality§3.4
• literal value§3.4.2
• named graphs§4.
• namespace§1.4
• namespace IRI§1.4
• namespace prefix§1.4
• nodes§3.1
• object§3.1
• predicate§3.1
• property§1.2
• proposition§1.8
• quad§4.3
• RDF dataset§4.
• RDF document§1.9
• RDF graph§3.
• RDF source§1.6
• RDF statement§1.2
• RDF term equality§3.2
• RDF terms§3.2
• RDF triple§3.1
• RDF vocabulary§1.4
• RDF-compatible XSD types§5.1
• rdf:HTML§A.1
• rdf:JSON§A.3
• rdf:XMLLiteral§A.2
• referent§1.3
• reifier§1.5
• reifying triple§1.5
• relative IRI references§3.3
• resources§1.2
• simple literals§3.4.1
• Skolem IRI§3.9
• string§2.1
• subject§3.1
• symmetric RDF dataset§7.
• symmetric RDF graph§7.
• symmetric RDF triple§7.
• Triple equality§3.1
• triple term§3.6
• URIs§3.3
• value space§5.

• [BCP47] defines the following:
  • BCP 47 section 4.5
  • section 2.2.9
• [DID-CORE] defines the following:
  • DID syntax
• [DOM] defines the following:
  • DocumentFragment
  • DOM nodes
  • isEqualNode(otherNode) (forNode)
  • normalize() (forNode)
• [HTML] defines the following:
  • dir attribute
• [HTML5] defines the following:
  • HTML fragment parsing algorithm
• [I18N-GLOSSARY] defines the following:
  • ASCII case-insensitive matching
  • bidi isolation
  • case-sensitive matching
  • code units
  • Normalization Form C
  • spillover effects
  • surrogate code points
  • Unicode Bidirectional Algorithm
  • Unicode character encoding
  • Unicode code points
  • Unicode scalar values
• [INFRA] defines the following:
  • items
  • key
  • lists
  • map entries
  • maps
  • null
  • size
  • size
  • true, false
  • value
• [JSON-LD11] defines the following:
  • i18n namespace
  • Section 10.2 The rdf:JSON Datatype
• [OWL2-OVERVIEW] defines the following:
  • OWL 2
• [OWL2-SYNTAX] defines the following:
  • custom datatypes
• [RDF12-SCHEMA] defines the following:
  • reification vocabulary
• [RDF12-SEMANTICS] defines the following:
  • entailment regime
  • RDF Semantics, "recognizing"
  • semantic extensions
• [RDF12-XML] defines the following:
  • @parseType="literal"
• [RFC3986] defines the following:
  • base IRI can be established
  • Collected ABNF for URI
  • fragment identifier
  • IRI scheme
  • relative reference
  • resolved
  • resolved against
• [RFC3987] defines the following:
  • section 1.3
  • section 3.1
  • Section 5
  • section 5.3.1
• [RFC7230] defines the following:
  • scheme rules for HTTP/HTTPS
• [RFC8259] defines the following:
  • JSON Array
  • JSON Grammar
  • JSON literal name
  • JSON Number
  • JSON Object
  • JSON String
• [SPARQL12-QUERY] defines the following:
  • the same concept of an RDF Dataset
• [SWBP-N-ARYRELATIONS] defines the following:
  • indirectly expressed in RDF
• [SWBP-XSCH-DATATYPES] defines the following:
  • user-defined simple XML Schema datatypes
• [WEBARCH] defines the following:
  • content negotiation
  • dereferences
  • IRI collision
  • IRI owner
  • URI persistence
• [XML11] defines the following:
  • Char
  • XML content
• [XMLSCHEMA11-2] defines the following:
  • doubleLexicalMap
  • floatPtRound
  • xsd:anyURI
  • xsd:base64Binary
  • xsd:boolean
  • xsd:byte
  • xsd:date
  • xsd:dateTime
  • xsd:dateTimeStamp
  • xsd:dayTimeDuration
  • xsd:decimal
  • xsd:double
  • xsd:duration
  • xsd:ENTITIES
  • xsd:ENTITY
  • xsd:float
  • xsd:gDay
  • xsd:gMonth
  • xsd:gMonthDay
  • xsd:gYear
  • xsd:gYearMonth
  • xsd:hexBinary
  • xsd:ID
  • xsd:IDREF
  • xsd:IDREFS
  • xsd:int
  • xsd:integer
  • xsd:language
  • xsd:long
  • xsd:Name
  • xsd:NCName
  • xsd:negativeInteger
  • xsd:NMTOKEN
  • xsd:NMTOKENS
  • xsd:nonNegativeInteger
  • xsd:nonPositiveInteger
  • xsd:normalizedString
  • xsd:NOTATION
  • xsd:positiveInteger
  • xsd:QName
  • xsd:short
  • xsd:string
  • xsd:time
  • xsd:token
  • xsd:unsignedByte
  • xsd:unsignedInt
  • xsd:unsignedLong
  • xsd:unsignedShort
  • xsd:yearMonthDuration

[BCP47]

Tags for Identifying Languages. A. Phillips, Ed.; M. Davis, Ed. IETF. September 2009. Best Current Practice. URL:https://www.rfc-editor.org/rfc/rfc5646

[DOM]

DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL:https://dom.spec.whatwg.org/

[HTML5]

HTML5. Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. 27 March 2018. W3C Recommendation. URL:https://www.w3.org/TR/html5/

[I18N-GLOSSARY]

Internationalization Glossary. Richard Ishida; Addison Phillips. W3C. 17 October 2024. W3C Working Group Note. URL:https://www.w3.org/TR/i18n-glossary/

[INFRA]

Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL:https://infra.spec.whatwg.org/

[RDF11-TESTCASES]

RDF 1.1 Test Cases. Gregg Kellogg; Markus Lanthaler. W3C. 25 February 2014. W3C Working Group Note. URL:https://www.w3.org/TR/rdf11-testcases/

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL:https://www.rfc-editor.org/rfc/rfc2119

[RFC3629]

UTF-8, a transformation format of ISO 10646. F. Yergeau. IETF. November 2003. Internet Standard. URL:https://www.rfc-editor.org/rfc/rfc3629

[RFC3986]

Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL:https://www.rfc-editor.org/rfc/rfc3986

[RFC3987]

Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL:https://www.rfc-editor.org/rfc/rfc3987

[RFC7493]

The I-JSON Message Format. T. Bray, Ed. IETF. March 2015. Proposed Standard. URL:https://www.rfc-editor.org/rfc/rfc7493

[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL:https://www.rfc-editor.org/rfc/rfc8174

[RFC8259]

The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed. IETF. December 2017. Internet Standard. URL:https://www.rfc-editor.org/rfc/rfc8259

[RFC8615]

Well-Known Uniform Resource Identifiers (URIs). M. Nottingham. IETF. May 2019. Proposed Standard. URL:https://www.rfc-editor.org/rfc/rfc8615

[Unicode]

The Unicode Standard. Unicode Consortium. URL:https://www.unicode.org/versions/latest/

[XML-NAMES]

Namespaces in XML 1.0 (Third Edition). Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson et al. W3C. 8 December 2009. W3C Recommendation. URL:https://www.w3.org/TR/xml-names/

[XML11]

Extensible Markup Language (XML) 1.1 (Second Edition). Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau; John Cowan et al. W3C. 16 August 2006. W3C Recommendation. URL:https://www.w3.org/TR/xml11/

[XMLSCHEMA11-2]

W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL:https://www.w3.org/TR/xmlschema11-2/

[ABNF]

Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed.; P. Overell. IETF. January 2008. Internet Standard. URL:https://www.rfc-editor.org/rfc/rfc5234

[COOLURIS]

Cool URIs for the Semantic Web. Leo Sauermann; Richard Cyganiak. W3C. 3 December 2008. W3C Working Group Note. URL:https://www.w3.org/TR/cooluris/

[did-core]

Decentralized Identifiers (DIDs) v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed. W3C. 19 July 2022. W3C Recommendation. URL:https://www.w3.org/TR/did-core/

[HTML]

HTML Standard. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL:https://html.spec.whatwg.org/multipage/

[HTML-RDFA]

HTML+RDFa 1.1 - Second Edition. Manu Sporny. W3C. 17 March 2015. W3C Recommendation. URL:https://www.w3.org/TR/html-rdfa/

[JSON-LD11]

JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL:https://www.w3.org/TR/json-ld11/

[LINKED-DATA]

Linked Data Design Issues. Tim Berners-Lee. W3C. 27 July 2006. W3C-Internal Document. URL:https://www.w3.org/DesignIssues/LinkedData.html

[OWL2-OVERVIEW]

OWL 2 Web Ontology Language Document Overview (Second Edition). W3C OWL Working Group. W3C. 11 December 2012. W3C Recommendation. URL:https://www.w3.org/TR/owl2-overview/

[OWL2-SYNTAX]

OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition). Boris Motik; Peter Patel-Schneider; Bijan Parsia. W3C. 11 December 2012. W3C Recommendation. URL:https://www.w3.org/TR/owl2-syntax/

[RDF-CONCEPTS-20040210]

Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne; Jeremy Carroll. W3C. 10 February 2004. W3C Recommendation. URL:https://www.w3.org/TR/2004/REC-rdf-concepts-20040210/

[RDF11-CONCEPTS]

RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL:https://www.w3.org/TR/rdf11-concepts/

[RDF11-DATASETS]

RDF 1.1: On Semantics of RDF Datasets. Antoine Zimmermann. W3C. 25 February 2014. W3C Working Group Note. URL:https://www.w3.org/TR/rdf11-datasets/

[RDF12-N-QUADS]

RDF 1.2 N-Quads. Gregg Kellogg; Dominik Tomaszuk. W3C. 20 February 2025. W3C Working Draft. URL:https://www.w3.org/TR/rdf12-n-quads/

[RDF12-N-TRIPLES]

RDF 1.2 N-Triples. Gregg Kellogg; Dominik Tomaszuk. W3C. 19 December 2024. W3C Working Draft. URL:https://www.w3.org/TR/rdf12-n-triples/

[RDF12-NEW]

What’s New in RDF 1.2. David Wood. W3C. DNOTE. URL:https://w3c.github.io/rdf-new/spec/

[RDF12-PRIMER]

RDF 1.2 Primer. Guus Schreiber; Yves Raimond. W3C. DNOTE. URL:https://w3c.github.io/rdf-primer/spec/

[RDF12-SCHEMA]

RDF 1.2 Schema. Dominik Tomaszuk; Timothée Haudebourg. W3C. 24 February 2025. W3C Working Draft. URL:https://www.w3.org/TR/rdf12-schema/

[RDF12-SEMANTICS]

RDF 1.2 Semantics. Peter Patel-Schneider; Dörthe Arndt; Enrico Franconi. W3C. 27 March 2025. W3C Working Draft. URL:https://www.w3.org/TR/rdf12-semantics/

[RDF12-TRIG]

RDF 1.2 TriG. Gregg Kellogg; Dominik Tomaszuk. W3C. 19 December 2024. W3C Working Draft. URL:https://www.w3.org/TR/rdf12-trig/

[RDF12-TURTLE]

RDF 1.2 Turtle. Gregg Kellogg; Dominik Tomaszuk. W3C. 20 February 2025. W3C Working Draft. URL:https://www.w3.org/TR/rdf12-turtle/

[RDF12-XML]

RDF 1.2 XML Syntax. Gregg Kellogg. W3C. 27 February 2025. W3C Working Draft. URL:https://www.w3.org/TR/rdf12-xml/

[RDFA-CORE]

RDFa Core 1.1 - Third Edition. Ben Adida; Mark Birbeck; Shane McCarron; Ivan Herman et al. W3C. 17 March 2015. W3C Recommendation. URL:https://www.w3.org/TR/rdfa-core/

[RFC3023]

XML Media Types. M. Murata; S. St. Laurent; D. Kohn. IETF. January 2001. Proposed Standard. URL:https://www.rfc-editor.org/rfc/rfc3023

[RFC5890]

Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. IETF. August 2010. Proposed Standard. URL:https://www.rfc-editor.org/rfc/rfc5890

[RFC5892]

The Unicode Code Points and Internationalized Domain Names for Applications (IDNA). P. Faltstrom, Ed. IETF. August 2010. Proposed Standard. URL:https://www.rfc-editor.org/rfc/rfc5892

[RFC6874]

Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers. B. Carpenter; S. Cheshire; R. Hinden. IETF. February 2013. Proposed Standard. URL:https://www.rfc-editor.org/rfc/rfc6874

[RFC7230]

Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed. IETF. June 2014. Proposed Standard. URL:https://httpwg.org/specs/rfc7230.html

[SPARQL11-QUERY]

SPARQL 1.1 Query Language. Steven Harris; Andy Seaborne. W3C. 21 March 2013. W3C Recommendation. URL:https://www.w3.org/TR/sparql11-query/

[SPARQL12-CONCEPTS]

SPARQL 1.2 Concepts. The W3C RDF-star Working Group. W3C. W3C Working Draft. URL:https://w3c.github.io/sparql-concepts/spec/

[SPARQL12-ENTAILMENT]

SPARQL 1.2 Entailment Regimes. Peter Patel-Schneider. W3C. 19 December 2024. W3C Working Draft. URL:https://www.w3.org/TR/sparql12-entailment/

[SPARQL12-FEDERATED-QUERY]

SPARQL 1.2 Federated Query. Ruben Taelman; Gregory Williams. W3C. 19 December 2024. W3C Working Draft. URL:https://www.w3.org/TR/sparql12-federated-query/

[SPARQL12-GRAPH-STORE-PROTOCOL]

SPARQL 1.2 Graph Store Protocol. Andy Seaborne; Thomas Pellissier Tanon. W3C. 19 December 2024. W3C Working Draft. URL:https://www.w3.org/TR/sparql12-graph-store-protocol/

[SPARQL12-NEW]

What’s New in SPARQL 1.2. The W3C RDF-star Working Group. W3C. W3C Working Draft. URL:https://w3c.github.io/sparql-new/spec/

[SPARQL12-PROTOCOL]

SPARQL 1.2 Protocol. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 19 December 2024. W3C Working Draft. URL:https://www.w3.org/TR/sparql12-protocol/

[SPARQL12-QUERY]

SPARQL 1.2 Query Language. Olaf Hartig; Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 28 February 2025. W3C Working Draft. URL:https://www.w3.org/TR/sparql12-query/

[SPARQL12-RESULTS-CSV-TSV]

SPARQL 1.2 Query Results CSV and TSV Formats. Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 19 December 2024. W3C Working Draft. URL:https://www.w3.org/TR/sparql12-results-csv-tsv/

[SPARQL12-RESULTS-JSON]

SPARQL 1.2 Query Results JSON Format. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 19 December 2024. W3C Working Draft. URL:https://www.w3.org/TR/sparql12-results-json/

[SPARQL12-RESULTS-XML]

SPARQL 1.2 Query Results XML Format. Ruben Taelman; Dominik Tomaszuk; Thomas Pellissier Tanon. W3C. 27 December 2024. W3C Working Draft. URL:https://www.w3.org/TR/sparql12-results-xml/

[SPARQL12-SERVICE-DESCRIPTION]

SPARQL 1.2 Service Description. Ruben Taelman; Gregory Williams. W3C. 19 December 2024. W3C Working Draft. URL:https://www.w3.org/TR/sparql12-service-description/

[SPARQL12-UPDATE]

SPARQL 1.2 Update. Ruben Taelman; Andy Seaborne; Thomas Pellissier Tanon. W3C. 6 February 2025. W3C Working Draft. URL:https://www.w3.org/TR/sparql12-update/

[STRING-META]

Strings on the Web: Language and Direction Metadata. Richard Ishida; Addison Phillips. W3C. 17 October 2024. W3C Working Group Note. URL:https://www.w3.org/TR/string-meta/

[SWBP-N-ARYRELATIONS]

Defining N-ary Relations on the Semantic Web. Natasha Noy; Alan Rector. W3C. 12 April 2006. W3C Working Group Note. URL:https://www.w3.org/TR/swbp-n-aryRelations/

[SWBP-XSCH-DATATYPES]

XML Schema Datatypes in RDF and OWL. Jeremy Carroll; Jeff Pan. W3C. 14 March 2006. W3C Working Group Note. URL:https://www.w3.org/TR/swbp-xsch-datatypes/

[UNICODE-SECURITY]

Unicode Security Considerations. Mark Davis; Michel Suignard. Unicode Consortium. 19 September 2014. Unicode Technical Report #36. URL:https://www.unicode.org/reports/tr36/tr36-15.html

[URL]

URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL:https://url.spec.whatwg.org/

[VOCAB-ORG]

The Organization Ontology. Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL:https://www.w3.org/TR/vocab-org/

[WEBARCH]

Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh. W3C. 15 December 2004. W3C Recommendation. URL:https://www.w3.org/TR/webarch/