Comments in bold green are stylistic and from bwm. Suggested replace text has no emphasis.

In general, there is a lot of redundancy in some areas of the text. I've taken a fairly ruthless green pen to it.

Section 2 needs a fair amount of work refining the text. I'd have preferred to suggest alteranatives, but there is just too much to do in the time I have today.

Technical comments are strong purple. Suggested replacement text has no emphasis.


Resource Description Framework (RDF):
Concepts and Abstract Data Model

Editors' Working Draft 26 October 2002

This version:
Latest version:
Previous version:
Previous published version:
Graham Klyne (Clearswift and Nine by Nine), <>
Jeremy J. Carroll (Hewlett Packard Labs), <>
Series editor:
Brian McBride (Hewlett Packard Labs) <>


The Resource Description Framework (RDF) is a data format for representing metadata about Web resources, and other information.

Align with similar statements in other docs. See suggestion.

This document defines the abstract graph syntax on which RDF is based, and which serves to link its XML serialization to its formal semantics. It also describes some other technical aspects of RDF that do not fall under the topics of formal semantics, XML serialization syntax or RDF schema and vocabulary definitions (which are each covered by a separate document in this series). These include: discussion of design goals, meaning of RDF documents, key concepts, datatyping, character normalization and handling of URI references.

Suggest:This document defines the abstract syntax on which RDF is based, and which serves to link its various concrete syntaxes to its formal semantics. It also includes discussion of design goals, meaning of RDF documents, key concepts, datatyping, character normalization and handling of URI references.

Status of this Document

This is an editors' working draft, whose intended status is as noted below.

An editors' issue-list for this document can be found here:

This is a W3C RDF Core Working Group Working Draft produced as part of the W3C Semantic Web Activity (Activity Statement).

This document is being released for review by W3C Members and other interested parties to encourage feedback and comments, especially with regard to the sections on datatyping and how the changes affect existing implementations and content.

This is a public W3C Working Draft and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite as other than "work in progress". A list of current W3C Recommendations and other technical documents can be found at

In conformance with W3C policy requirements, known patent and IPR constraints associated with this Working Draft are detailed on the RDF Core Working Group Patent Disclosure page.

Comments on this document are invited and should be sent to the public mailing list An archive of comments is available at

Table of contents

1. Introduction

The Resource Description Framework (RDF) is a data format for representing metadata about Web resources, and other information.

Align with other docs as before.

This document defines the abstract graph syntax on which RDF is based, and which serves to link its XML serialization to its formal semantics. It also describes some other technical aspects of RDF that are not covered by separate normative documents in this series.

The normative documentation of RDF falls broadly into the following areas:


This document defines the abstract syntax on which RDF is based, and which serves to link its various concrete syntaxes to its formal semantics. This document discusses RDF's design goals, the meaning of RDF documents, its key concepts and various technical aspects such as character normalization and handling of URI references.

[[[NOTE: it is anticipated that some of the material in this document may be moved to other documents as part of the document review process.]]]

In section 2, some background to the design goals and rationale of RDF is presented. There is also some discussion of the intended implications of publishing an RDF document (section 2.3).

RDF is based on a graph syntax, which is typically serialized using XML (but which is quite distinct from XML's tree-based infoset [XML-INFOSET]). This graph syntax captures the fundamental structure of RDF, independently of any serialization syntax that may be used. The formal semantics of RDF are defined in terms of the graph syntax. The graph syntax is defined in section 3 of this document.

Suggest:RDF's abstract syntax is a graph which is typically serialized using XML (but which is quite distinct from XML's tree-based infoset [XML-INFOSET]). The abstract syntax captures the fundamental structure of RDF, independently of any concrete syntax used for serialization. The formal semantics of RDF are defined in terms of the abstract syntax. The abstract syntax is defined insection 4of this document.

Note section number.

Section 4 presents some other technical issues that don't clearly fall into any of the more explicit areas noted above.

Suggest:Section 5presents some other technical issues.

Note section number.

2. RDF background, rationale and concepts

RDF uses well established ideas from various data and knowledge representation communities, with recognizable relationships to Conceptual Graphs, logic-based knowedge representation, frames, and relational databases [Sowa] [CG] [KIF] [Hayes] [Luger] [Gray].

Suggest delete para and references. I don't recognise such relationships. This feels a bit like name dropping, quoting references to august publications to gain gloss by association.

RDF is a member of the family of languages that use XML, which in turn provides a syntactic framework for representing documents and other information. It has a simple graph-based data model and formal semantics with a rigorously defined notion of entailment, which in turn provides a basis for well founded deductions in RDF data.

Suggest delete para. There is not much new information here. We've already said there is an xml serialization. We don't need to say what xml is for. We've already said it has a graph based syntax. The term 'data model' is not defined and is rather woolly. All thats left is the formal semantics and we can leave that to the model theory.

The real value of RDF comes not so much from any single application, but from the possibilities for sharing data between applications. The value of information thus increases as it becomes accessible to more and more applications across the entire Internet.

Suggest delete para. Its a bit lonely without the others and isn't saying much.

2.1 Motivation

The development of RDF has been motivated by the following uses, among others:

2.2 Design goals

The design of RDF is intended to meet the following goals:

2.2.1 A simple data model

RDF has a simple data model that is easy for applications to process and manipulate. The data model is independent of any specific serialization syntax.

NOTE: the term "model" used here in "data model" has a completely different sense to its use in the term "model theory". See the RDF model theory specification [RDF-SEMANTICS] or a textbook on logical semantics (e.g., [HUNTER] [DAVIS]) for more information about what logicians call "model theory".

2.2.2 Formal semantics and well-founded inference

RDF has a formal semantics which provides a sound basis for reasoning about the meaning of an RDF expression. In particular, it supports rigorously defined notions of entailment which provide a basis for defining reliable rules of inference in RDF data.

2.2.3 Extensible URI-based vocabulary

The vocabulary is fully extensible, being based on URIs with optional fragment identifiers (URI references, or URIrefs). URIrefs are used for naming all kinds of things in RDF data. The only other kind of label that appears in RDF data is a literal string.

[[[Review this on resolution of datatypes issues]]]

2.2.4 XML-based syntax

RDF has a recommended XML serialization form [RDF-SYNTAX], which can be used to encode the data model for exchange of information between applications.

2.2.5 Use XML schema datatypes

RDF can be used with XML schema datatypes [XML-SCHEMA2], thus assisting the exchange of information between RDF and other XML applications.

[[[Review this on resolution of datatypes issues]]]

2.2.6 Anyone can make simple assertions about anything

To facilitate operation at Internet scale, RDF is an open-world framework that allows anyone to make simple assertions about anything. In general, it is not assumed that all information about any topic is available. A consequence of this is that RDF cannot prevent anyone from making assertions that are nonsensical or inconsistent with the world as people see it, and applications that build upon RDF must find ways to deal with incomplete and conflicting sources of information. (This is where RDF departs from the XML approach to data representation, which is generally quite prescriptive and aims to present an application with information that is well-formed and complete for the application's needs.)

2.2.7 Universal expression of simple facts

But what consitutes a "simple fact"? Roughly, the kind of information that can be stored in a relational database, possibly about any nameable thing or concept.

The basic building block of RDF is a statement, which is a binary relational assertion. For example, the expression "floats(oil,water)" is a binary relational assertion expressing that oil floats on water. The term "floats" names a relationship that holds between "oil" and "water". An RDF statement can also contain a variable; e.g., as in "floats(?x,water)" expressing that there is something that floats on water, where "?x" stands for the something, without saying what it is.

Conjunction (logical-AND) of statements can be used to express more complex facts, such as "floats(oil,water) AND burns(oil,air)". Using the same variable in several different statements of a conjunction can say more than one might immediately expect, e.g. "type(?x,fluid) AND floats(?x,water)" says there is a fluid that floats on water.

Relationships involving more than two things can be expressed as a conjunction of binary relations, so "boilsAt(water,100C,1atm)" could be expressed as the existence of a boiling event, say "?b", such that "boils(?b,water) AND temp(?b,100C) AND press(?b,1atm)".

The expressive power of RDF corresponds to the existential-conjunctive (EC) subset of first order logic [Sowa]. It does not provide means to express negation (NOT) or disjunction (OR). RDF is unusual, for a first order logic subset, in that it allows statements to be made about the relation terms themselves, e.g. "type(floats,physical-relationship) and floats(oil,water)". This kind of expression is more commonly associated with higher order logics, but the use allowed by RDF has first-order semantics.

Through its use of extensible URI-based vocabularies, RDF aims to provide for universal expression of facts about arbitrary subjects; i.e. assertions of named properties about specific named things. A URI can be constructed for any thing that can be named, so RDF facts can be about any such things. And, as noted above, RDF also provides for expression of assertions about unnamed things, which may be fully identifiable in terms of such assertions [TAP-RBD].

RDF itself does not provide the machinery of inference, but provides the raw data upon which such machinery can operate. The Web Ontology Language [OWL] allows more expressive expressions to be built on the basic capabilities of the RDF core language.

This whole section seems inappropriate. This section is supposed to be about design goals. The design goal is to have a simple expressive model for representing information.

2.2.8 A basis for binding agrements

Spelling: 'agreements'

RDF is intended to convey assertions that are meaningful to the extent that they may, in appropriate contexts, be used to express the terms of binding agreements.

This goal is explored further in section 2.3 below.

2.3 Meaning of RDF documents

The RDF specification emphasizes the formal structure and meaning of RDF. But there is also a social dimension that is easily overlooked when dealing with such formal aspects.

2.3.1 Formal semantics

RDF is a language designed to support the Semantic Web, in much the same way that HTML is the language that supports the original Web. The Semantic Web aims for data to be shared and processed by automated tools as well as by people. To serve this purpose, formal meanings of RDF statements must be defined in a precise manner; this is provided by the RDF Model Theory [RDF-SEMANTICS].

Model-theoretic semantics assumes that the expressions of a language refer to a world but may not describe it completely. Asserting a sentence in a language, on this view, imposes a constraint on the possible ways the world can be: it has at least to make the sentence true. As more knowledge is added - more assertions are made - the collection of possible worlds is reduced. The basic relationship between language and reality is that the more sentences are asserted, the more tightly reality is circumscribed, if none of those assertions are to come out false. The main purpose of the semantics is to make this intuition precise by giving a simple mathematical description of what counts as a 'possible way the world can be' - often simply called a 'possible world' - and of how such a possible world determines the truth-values of sentences. This combination of a world and a mapping between the language and the world is called an interpretation, so model theory might be better called 'interpretation theory'.

The chief utility of such a semantic theory is not to suggest any particular processing model, or to provide any deep analysis of the nature of the things being described by the language (in our case, the nature of resources), but rather to provide a technical tool to analyze the semantic properties of proposed operations on the language; in particular, to provide a way to determine when they preserve meaning.

The RDF model theory treats RDF as a simple assertional language, in which each triple makes a distinct assertion, and the meaning of any triple is not changed by adding other triples. Based on the semantics defined in the model theory, it is simple to translate an RDF graph into a logical expression with essentially the same meaning.

The RDF model theory is couched in the language of set theory simply because that is the normal language of mathematics - for example, the model theory assumes that names denote things in a set IR called the 'universe' - but the use of set- theoretic language is not supposed to imply that the things in the universe are set-theoretic in nature.

We don't need all this stuff about model theory here. This duplicates what is in the model theory document. Suggest delete most of this section and leave just enough to contrast with social meaning which is the main point we have to make, e.g.

There are two aspects to the meaning of an RDF document. There is the formal meaning of the document as determined by the RDF model theory [ref]. This determines, with mathematical precision, all the conclusions that can be legitimately drawn from an RDF document. There is also the social meaning of the document. It is the social meaning that affects what the document means to people and how it interacts with human social institutions such as our systems of law.

Also the above uses the term' triple' which has not been introduced yet. We need some introduction to RDF concepts before we can start talking about their meaning, formal or otherwise. What we have is currently buried in a section on goals. Need a section on RDF concepts. Ah - I see it comes later. Maybe some reordering will fix this.

2.3.2 Social meaning

RDF/XML documents, i.e. encodings of RDF graphs, can be used to make representations of claims or assertions about the 'real' world. But not every RDF/XML document does so.

What is the word 'representations' doing here. Suggest:

RDF/XML documents can be used to make assertions about the 'real' world, but not all RDF/XML documents do so. Consider a document published on the web. It is making assertions. However, the same document, sent in an attachment to an email message in which the author of the message made it clear that he did not believe the contents of the attachment, is not making any assertions.

While the formal semantics of an RDF statement (triple) is that of a distinct assertion, individual RDF statements may convey meaning that is partly determined by the circumstances in which they are used. For example, in English, a statement "I don't believe that George is a clown" contains the words "George is a clown", which, considered in isolation, have the form of an assertion that George exhibits certain comic qualities. However, considering the whole sentence, no such assertion is considered to be made.

Similarly, a collection of RDF statements having an assertional form could be presented in a context that they are not understood to be stating a truth. Thus, there is a distinction between RDF expressions that are asserted, and those that are not.

When an RDF graph is asserted in the web, its publisher is saying something about their view of the world. Such an assertion should be understood to carry the same social import and responsibilities as an assertion in any other format. A combination of social (e.g. legal) and technical machinery (protocols, file formats, publication frameworks) provide the contexts that fix the intended meanings of the vocabulary of some piece of RDF, and which distinguish assertions from other uses (e.g. citations, denials or illustrations).

The technical machinery includes protocols for transferring information (e.g. HTTP, SMTP) and file formats for encapsulating and labelling information (e.g. MIME, XML). A media type, application/rdf+xml [RDF-MIME-TYPE] is being registered for indicating the use of RDF/XML as distinct from some other XML that happens to look like RDF. Issuing an HTTP GET request and obtaining data with a "200 OK" response code is a technical indication that the received data was published at the request URI; but data received with a "404 Not found" response cannot be considered to be similarly published information.

The social machinery includes the form of publication: publishing some unqualified statements on one's World Wide Web home page would generally be taken as an assertion of those statements. But publishing the same statements with a qualification, such as "here are some common myths", or as part of a rebuttal, would likely not be construed as an assertion of the truth of those statements. Similar considerations apply to the publication of assertions expressed in RDF.

Noting that there is no single human opinion about the truth of some statements, the graph may further contain commentary for human interpreters to indicate the realm of human interpretation that should be applied. This means a graph may contain "defining information" that is opaque to logical reasoners. This information may be used by human interpreters of RDF information, or programmers writing software to perform specialized forms of deduction in the Semantic Web.

When a user invokes an application that uses RDF, there is also a social and technical context of invocation that determines some set of RDF assertions that will be assumed to be true: the application itself, and any RDF files that are passed to it. Garbage-in, garbage-out applies: if the initial assumed facts are wrong or meaningless, the results will have little value. No specific mechanisms for deciding or evaluating the validity of any such assertions are defined here.

Note: I suggest the text of this section could be shorter and clearer. I realise that's not very helpful, but I don't have time to compose alternate text now. This is just a placeholder to come back to it.

2.3.3 Interaction between social and formal meaning

Using RDF, 'received meaning' can be characterized as the social meaning of any logical consequences. If you publish a graph G and G logically entails G', and we interpret G' using the same social conventions that everyone agrees could be reasonably used to interpret G, then you are asserting that content of G' as well.

Human publishers of RDF content commit themselves to the mechanically-inferred social obligations. The machines doing the inferences aren't expected to know about all these social conventions and obligations.

Imagine three websites each publishing some RDF:

asserts the following, and this is all that one can find on the website about that term:
A:Clown rdf:type rdfs:Class .
A:Clown rdfs:Comment "A foolish person, whose pronouncements are probably ill-considered and not to be taken seriously" .

B:Comic rdf:subClassOf <> .

asserts the following, assuming that C:JohnSmith is understood to refer to some particular person:

C:JohnSmith rdf:type <> .

Now, it follows by the formal RDF model theory that these three together entail:

C:JohnSmith rdf:type <> .

which the person identified as C:JohnSmith might reasonably consider an insult. Why? Not because of the RDF model theory, which merely says he is in some class about which nothing can be formally inferred. However, the rdfs:comment associated with that class name by the owner of that name provides the insulting content, in the social context of web publication, even though it cannot be formally inferred via the RDF inference rules.

But who has insulted the identified person? A merely defined the term; B doesn't mention him in particular, so even A and B together do not constitute a personal insult. And C might argue that although he refers to the person, he only asserts that he is a comic, which is not in itself grounds for a libel suit. However, one could reasonably claim that C is to blame, since C uses not a generic term 'Comic', but a particular uriref which is defined by its owner (B) in a way which is clearly insulting, since B in turn explicitly refers to, and uses, the term defined by A. Thus, C's use of a B-defined term suggests a clear intent by C to convey a meaning defined by B, by virtue of a definition by A, which is insulting.

Note that this argument depends on another social convention of RDF, which is that URIs 'belong to' somebody who has authority and responsibility for defining their meanings. By using the specific name instead of some term defined in, say, a glossary of job descriptions, B has explicitly removed his use of the term 'Clown' from any formal connection with people who are entertainers. In order to succeed in his probable intent of making a generic slander against these people, B should have used a term that was defined by someone else, such as:

rdfs:subClassOf <> .

and then if C had also used this first uriref, then in spite of a similar formal inference chain generating the insulting conclusion about C:JohnSmith, there would be nobody to sue, since now C would indeed have simply made a harmless observation about his occupation, and B's assertion, while indeed arguably offensive, makes no reference to him in particular.

The point of this example is to emphasize that publication of RDF, when considered as a social act, constitutes a publication of some content which is defined by whatever normal social conditions are used by the publishers of any terms in the RDF to define the meanings of those terms, even if those meanings and definitions are not accessible to the formal semantics of RDF; and, moreover, those meanings are preserved under any formally sanctioned inference processes. In a nutshell, the formal entailments of social meanings are themselves part of the social meaning.

[[[NOTE: we're not sure if this final bit is helpful. Jeremy thinks it may thwart some intended OWL inferences. Is this getting too far into murky legalistic territory?]]]

Note that we cannot use a single notion of 'meaning' to say this properly, since of course the formal entailments cannot themselves utilize the social aspects of meaning which are included in informal aspects of the publication, such as the fact that the use of 'Clown' is insulting, which is only mentioned in a comment which is opaque to any likely RDF inference engine or machine processor. Social meanings can be, as it were, transferred or carried by formal entailments, but they cannot be incorporated into the formal entailments. To emphasize this, suppose that B had failed to use rdfs:subClassOf and instead had tried to use his own term:

B:Comic B:oneOfThem <> .
B:oneOfThem rdfs:comment "This means the same as rdfs:subClassOf" .

then in spite of the clear social meaning of the comment, there would be no formal inference path from this, taken with the A and C publications, to anything that could be found insulting; so even if C had intended to bad-mouth the person C:JohnSmith, B's stupidity would have thwarted him.

Note: I'm worried about the volume of text here. if its at all possible this should be much shorter. This is a difficult area and the more we write the more we are likely to cause problems. Isn't it just enough to say that if you assert a graph, then you assert also all its entailments as defined by the model theory.

2.3.4 A difference between RDF and natural language.

An RDF predicate is defined by an authoritative body implicit in its URI, and misuse by others should not be permited to undermine that authority.

I don't buy 'implicit in its URI'. RDF assumes that for any URI some individual or organisation has the authority to define the meaning of that URI. But that is not implicit in the URI. We have social mechanisms to determine who is responsible.

Further, information about the meaning of a statement is primarily dependent on the predicate used. The subject and object contribute to the meaning of a statement according to the definition of the predicate, but cannot change the predicate's fundamental meaning. For example, suppose some authority defines the predicate "floats(x,y)" to mean that x floats on y, so that "floats(oil,water)" means that oil floats on water. It is not legitimate for some other party to assert that "floats(water,wood)" means that wood floats on water because they think the original definition doesn't make sense when wood is used as the second parameter.

2.3.5 RDF Inferences

The RDF core language provides a way to make simple formal assertions, with no way to formally express allowable inferences beyond those entailments that are defined by the RDF formal semantics [RDF-SEMANTICS].

Many inferences are performed by processes, embedded in software implementations, whose validity is not formally demonstrable, and must be assumed or trusted to be socially acceptable. Semantic web languages layered on RDF, such as OWL [OWL], give formal expression to allowable inferences, thus to enable provable deductions by generic software modules to replace some of the individual, ad-hoc implementations.

I have no idea what this is trying to say. It seems to say that any inference done by software MUST be assumed to be valid or trusted to be socially acceptable!

2.4 RDF concepts

RDF uses the following key concepts:

2.4.1 Graph data model

The underlying structure of any RDF expression where did this term come from. is a directed labelled graph (or multigraph), which consists of nodes and labelled directed arcs that link pairs of nodes (these notions are defined more formally in section 3). The formal semantics for RDF is defined in terms of this graph syntax.This is getting a bit repetitive. An RDF expression is sometimes sometimes?called an RDF graph. The graph can conveniently be represented as a set of triples, where each triple contains two node labels and an arc label: this brings up bnode labels. We don't want to go there. Suggest delete sentence.

image of the rdf triple comprising (subject, predicate, object)

Maybe 'arc' is better than 'property arc'?

Each arc corresponds to a statement that asserts a relationship between the nodes that it links. Well, they are not all asserted in all contexts. Suggest:Each arc represents a relationship between the nodes that it links. All the arcs labelled with the same predicate thus form a single dyadic relationship, and the RDF graph can be informally viewed as a set of graphs, one for each relation, overlaid on top of one another with the labels showing which relation each arc has been derived from (cf. [Sowa2]). Where did that come from and why do we need it? Lets not put unnecessary stuff in here. The more we write the more opportunity there is for confusion and error. The meaning of an RDF graph is the conjunction (i.e. logical AND) of all the statements that it contains.

Need to introduce the notion of subject, predicate and object in the text.

2.4.2 URI-based vocabulary

Nodes in an RDF graph are labelled with URIs with optional fragment identifiers (URI references, or URIrefs), literal strings, or nothing at all. Datatype values? Arcs are labelled with URIrefs. (See [URIS], section 4, for a description of URI reference forms, noting that relative URIs are not used in an RDF graph. See also section 3.1.)

Why the big bold fonts for the new terms. Is this your choice or W3C guidance? I would have thought <em>...<em> would be enough.

The label on a node indicates what that node is meant to represent. The label on an arc names the relationship that is asserted to hold between the nodes connected by that arc. Suggest:The label on a node identifies what that node represents. The label on an arc identifies the relationship between the nodes connected by the arc.Some URIrefs may indicate web resources, and a node thus labelled denotes that resource. Other URIrefs may represent abstract ideas or values rather than a retreivable Web resource. Implying that nodes so named don't denote those abstract ideas or values?RDF thus leverages the universal naming space of URIs [URIS]. Suggest delete last sentence. It adds nothing.

2.4.3 Literals

Literals are used to indicate values in an RDF graph by means of a lexical representation. They are typically used to represent things like numbers, strings and other common kinds of value. Anything that can be represented by a literal could also be represented by a URI, but it is often more convenient and/or intuitive to use literals.

Suggest:Literal labels are used to identify values such as numbers and dates.

Literals may appear in the object position of RDF statements, and nowhere else. Well, they can appear in this document! Suggest:A literal may label the object of an RDF statement but not the subject or the arc.

Literals may be typed or untyped. The datatype, What datatype? Nothing has been said about datatypes yet. if any, provides a means of interpreting the lexical form, and hence of finding the value denoted by the literal. Suggest: delete last sentence.

An untyped literal is a string combined with a (possibly empty) language identifier. This should be used for plain text in a natural language. As recommended in the RDF formal semantics [RDF-SEMANTICS], these untyped literals are self-denoting, i.e. their formal meaning is that they mean what they are.

A single datatype is prefined as part of this recommendation:

The notion of what a datatype is has not yet been introduced. Move this bit later.

used for well-formed XML element content.

Other datatypes are provided by XML Schema datatypes [XML-SCHEMA2].

A typed literal additionally has an associated datatype URI that identifies a datatype.

Further information about literals may be found in section 4 below on graph syntax. Suggest delete: unnecessary.

2.4.4 Datatypes

Datatyping in RDF is the use of a datatype to associate a lexical form with a denoted value.

For example, the datatype xsd:integer might be used to associate the numeral string "10" with the integer value 10, or the datatype xsd:date might be used to associate the string "2002-09-30" with the 30th day of September in the year 2002 according to the Gregorian calendar.

No this isn't right. This is describing the means, when it should be describing the end. Suggest:Datatypes are used in RDF to represent values such as integers, floating point numbers and dates. RDF uses the datatype abstraction define by XML Schema Part 2: Datatypes [Ref]. A datatype consists of a lexical space, a value space and a datatype mapping.

Then move the para below further down and run into "A datatype mapping ..."

RDF only predefines one datatype rdfs:XMLLiteral, used for embedding XML in RDF. There is no built-in concept of numbers or dates or other common values. Rather, RDF defers to datatypes that are defined separately, and identified with URIs. In particular, the predefined XML Schema datatypes [XML-SCHEMA2] are expected to be widely used for this purpose.

A datatype mapping is a set of pairs whose first element belongs to the lexical space of the datatype, and the second element belongs to the value space of the datatype.

A datatype mapping satisfies the following properties:

The datatypes used in RDF have a lexical space consisiting of a set of strings. Exceptionally, rdfs:XMLLiteral also accesses a langauge identifier, in its datatype mapping.

For example, the datatype mapping for the XML Schema datatype xsd:boolean, where each member of the value space (represented here as 'T' and 'F') has two lexical representations, is as follows:

Value Space {T, F}
Lexical Space {"0", "1", "true", "false"}
Datatype Mapping {<"true", T>, <"1", T>, <"0", F>, <"false", F>}

Datatypes are used in RDF for the explicit designation of the type of literals. No. They are used to represent datatype values. A typed literal contains a datatype URI and a member of the datatype's lexical space. This serves to unambiguously identify a member of the value space of the datatype.

In the abstract syntax below, literals include a language identifier. For the exceptional datatype, rdfs:XMLLiteral, the lexical space is a set of pairs, involving such language identifiers; and the value identified by the literal depends on the langauge identifier. For all other datatypes the lexical space is a set of strings, not involving such language identifiers. The value identified by the literal is independent of the language identifier, which is simply ignored.

NOTE: XML Schema Datatypes [XML-SCHEMA2] provide an extensibility mechanism suitable for defining new datatypes for use in RDF.

For example, the typed literals which can be defined for the XML Schema datatype xsd:boolean are as follows:

Typed Literal Datatype Mapping Value
<xsd:boolean, "true"> <"true", T> T
<xsd:boolean, "1"> <"1", T> T
<xsd:boolean, "false"> <"false", F> F
<xsd:boolean, "0"> <"0", F> F

RDF datatyping depends on externally defined datatypes, and does not of itself provide any mechanisms for defining new datatypes. The defining authority associated with a datatype URI is responsible for specifying the corresponding datatype mapping, and knowledge of this mapping is presumed No its not. An rdf processor with no knowledge of a datatype can do all but the datatype entailments specific to that datatype. It is wrong to suggest that knowlege of the datatype MUST be built in to be built-in to applications that process datatypes in RDF data. RDF applications that have no such knowledge can preserve information in the RDF graph by treating the literal structure as an opaque value.

Suggest replace para with: RDF provides no mechanism for defining new datatypes. The defining authority of a URI which identifies a datatype is responsible for specifying the datatype's lexical space, value space and datatype mapping.

2.4.5 XML serialization syntax

RDF has a specific serialization syntax based on XML [RDF-SYNTAX].

Only the XML syntax is normatively specified and recommended for use to exchange information between Internet applications: other syntaxes for RDF graphs are possible, and may be widely used (e.g. [NOTATION3]), but are not covered by this recommendation.

RDF/XML is not covered by this recommendation either. This section isn't saying anything. Delete.

2.4.6 Entailment

Can we leave this to the model theory? No, not if we are to talk about it in social meaning. However, we can make it simpler than this. Suggest a single para in the section on social meaning is sufficient.

The ideas on meaning and inference in RDF are underpinned by the concept of entailment. An RDF expression A is said to entail another RDF expression B if every possible arrangement of things in the world that makes A true also makes B true. On this basis, if we presume or demonstrate the truth of A then we can also infer the truth of B. This idea is discussed at greater length in section 2.3.1 on formal semantics, and in the RDF formal semantics document [RDF-SEMANTICS].

This idea of entailment sets RDF apart from many other network data formats. What obligations does an entailment place on a processor of RDF data? The answer is: none. RDF applications are not required to find all facts that can be inferred on the basis of allowed entailments. (Further, it may be not possible to find all such facts.) But useful applications MAY infer some such facts, and treat those facts as if they were part of the supplied input data.

The RDF test cases described by [RDF-TESTS] contain some entailment and non-entailment tests (positive entailment tests and negative entailment tests), covering both RDF-entailment and RDFS-entailment. A positive entailment test indicates that the indicated conclusion can be inferred from the given antecendents; RDF applications are allowed to perform such inferences, but not required to do so. A negative entailment test indicates that an RDF application is not entitled by the rules of RDF alone to infer the indicated conclusion from the corresponding antecendent. A non-entailment does not mean that the conclusion is necessarily false: it may be true for reasons unrelated to the antecedent facts.

So we have the situation that a positive entailment does not mean that an RDF application must infer the conclusion, and a negative entailment does not mean the conclusion is necessarily false. How are we to judge whether a given RDF application is truly playing by the rules of RDF? The answer lies in the existence of a proof. An application that validly infers a conclusion from some antecedent facts must do so in a series of steps that can be directly traced to allowable entailments, which series constitutes a proof. The allowable entailments and corresponding proof steps sanctioned by the RDF specification are set out in the RDF formal semantics document [RDF-SEMANTICS].

2.5 RDF core URI vocabulary and namespaces

RDF uses URIs to label resources and properties. Certain URIs are reserved for use by RDF, and may not be used for any purpose not sanctioned the RDF specifications. Specifically, URIs with the following leading substrings are reserved for RDF core vocabulary:

Used with the RDF/XML serialization, these URI prefix strings correspond to XML namespaces [XML-NS] associated with the RDF core vocabulary terms.

NOTE: these namespace URIs are the same as those used in earlier RDF documents [RDF-MS] [RDF-SCHEMA].

[[[NOTE FOR REVIEWERS: Some terms in these namespaces have been deprecated, some have been added, and some RDF schema terms have had their meaning changed. We invite community feedback regarding the relative costs of adopting these changes under the old namespace URIs vs creating new URIs for this revision of RDF.]]]

Vocabulary terms in the rdf: namespace are listed in section 3.4 [[[check this]]] of the RDF syntax specification [RDF-SYNTAX].

Vocabulary terms defined in the rdfs: namespace are defined [[[where?]]] in the RDF schema vocabulary specification [RDF-VOCABULARY].

3. XML Content within an RDF Graph

RDF provides for XML content as a possible literal value. This typically originates from the use of rdf:parseType="Literal" in the RDF/XML Syntax [RDF-SYNTAX].

Such content is indicated in an RDF graph using a typed literal whose datatype is a special builtin datatype, rdfs:XMLLiteral.

As part of the definition of this datatype, we use an ancillary definition.

The XML document corresponding to a pair ( str, lang ) is formed as follows:

If lang is not the empty language identifier, then concatenate the five strings:

  1. "<rdf-wrapper xml:lang='"
  2. lang
  3. "'>"
  4. str
  5. "</rdf-wrapper>"

Encode the resulting Unicode string in UTF-8 to form the correspond XML document.

If lang is the empty language identifier, then enclose str with "<rdf-wrapper>" and "</rdf-wrapper>" and encode the resulting string in UTF-8 to form the correspond XML document.

Is the distinction between the empty lang id and the others necessary? Given that an empy lang id now turns of any outer scoped lang is, would it better/simpler to have the lang attribute anyway.

Using this, the datatype rdfs:XMLLiteral is defined as follows.

The datatype URI
The value space
is the set of all XML documents which:
The lexical space
contains all pairs ( string, lang ) where lang is any language identifier [RFC-3066] in lower case, and string is well-balanced, self-contained XML element content [XML], for which the XML document corresponding to the pair is a well-formed XML document [XML] that also conforms to XML Namespaces [XML-NS].
The mapping
is defined as the function that maps a pair to the canonical form [XML-C14N] (with comments) of the corresponding XML document.

REMINDER: All other datatypes have a lexical space being a set of strings, and a mapping which maps strings to values.

NOTE: If compatibility with XML version 1.1 is desired, then the value space of this datatype must be restricted to those that are fully normalized according to [XML 1.1]; with a corresponding restriction on the lexical space.

I'm not sure how to interpret this note. We seem to have two versions of the datatype here, one xml 1.1 compliant and one not. Don't we have to be clear? Do you mean:

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

Perhaps we should define a subclass of rdfs:XMLLiteral that is XML 1.1 compliant. Then again, perhaps not. Lets not add stuff unless we absolutely have to.

4. Graph Abstract Syntax

Is there more than one abstract syntax for RDF? This defines the abstract syntax which happens, currently, to be a graph. Suggest section title: Abstract Syntax.

[[[This section, particularly how nodes and node labels are handled, is not completely in sync with the current Model Theory WD -- coordinate with MT editors, and review after next MT WD]]]

This section defines the RDF graph abstract syntax. The RDF graph is sometimes referred to as the (data) model of RDF (see the RDF Primer [RDF-PRIMER], and RDF Model & Syntax [RDF-MS]). In brief, the RDF graph is a directed graph with labelled edges and partially labelled nodes.

Suggest: This section defines the RDF abstract syntax. The RDF abstract syntax is a directed graph with labelled edges and partially labelled nodes.

A goal of this section is the precise definition of equality between RDF graphs. This benefits interoperability (two conformant implementations are more likely to be practically interoperable if they have a precise conception of the way in which they are the same). It is required for the specification of the RDF Test Cases [RDF-TESTS], which depend on testing equality of RDF graphs for their execution. It is required by the RDF Model Theory [RDF-SEMANTICS] which assigns the same meaning to any pair of equal RDF graphs.

Is it really REQUIRED for the model theory. Suggest:

This section defines equality between RDF graphs. A definition of equality is needed to support the RDF Test Cases [RDF-TESTS] specification that contains many tests that depend on determining whether two graphs are equal.

NOTE: Many RDF applications and frameworks do not need to implement RDF graph equality. They do need to respect equality when assigning meaning to RDF graphs.

Suggest delete note above.

The specification of the RDF graph commences with the labels used in the graph, which can be URI references or literals; equality is defined for each. It then proceeds to describing arcs (triples), a complete graph and graph equality.

Suggest: it would be clearer to go top down rather than bottom up. Start with the graph and then fill in detail.

4.1 URI References

[[[This text should be reviewed in light of the IRI section in the namespaces 1.1 last call WD and comments made on it; I had one attempt but it failed.]]]

A URI Reference Label within an RDF graph (an RDF URI reference) is a Unicode string [UNICODE] that:

The disallowed characters that must be %-escaped include all non-ASCII characters, the excluded characters listed in Section 2.4 of [URIS], except for the number sign (#) and percent sign (%) characters and the square bracket characters re-allowed in [RFC-2732].

Is that right? '%' does not itself have to be escaped? Does that make ambiguous?

Disallowed characters must be escaped as follows:

  1. Each disallowed character is converted to UTF-8 [RFC-2279] as one or more bytes.
  2. Any bytes corresponding to a disallowed character are escaped with the URI escaping mechanism (that is, converted to %HH, where HH is the hexadecimal notation of the byte value).

    That reads a bit strangely. Are you saying that if when converted to bytes, some of those bytes correspond to allowed ascii characters, then those characters can be included without escaping? Did you mean:

    Each byte is converted to %HH, where HH is the hexadecimal notation of the byte value.


    Each byte is considered as an encoding of an ascii character. If the character is allowed, then that character is used. If that character is not allowed, it is replaced with %HH where HH is the hexadecimal notation of the byte value.

  3. The original character is replaced by the resulting character sequence.

    What character sequence. The text above should be couched as an algorithm working on a characters sequence

Two RDF URI references are equal if and only if they compare as equal, character by character, as Unicode strings. A URI reference label is not equal to a string literal label or an XML literal label.

Note: RDF URI references are compatible with the anyURI datatype as defined by XML schema datatypes [XML-SCHEMA2], constrained to be an absolute rather than a relative URI reference, and constrained to be in Unicode Normal Form C [NFC] (for compatibility with [CHARMOD]).

Note: RDF URI references are compatible with International Resource Identifiers as defined by [XML Namespaces 1.1].

Note: The restriction to absolute URI references is found in this abstract syntax. Concrete syntaxes, such as RDF/XML, may permit relative URIs (when there is a well-defined base URI) as a shorthand for such absolute URI references.

See the following test cases, per [RDF-TESTS]:

4.2 RDF Literals

A literal in an RDF graph is a triple:

An untyped literal is one in which the datatype URI is absent.

A typed literal is one in which the datatype URI is present.

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

Note: When using the language identifier, care must be taken not to confuse language with locale. The language identifier only relates to human language text. Presentational issues, as to how to best represent typed data to the end-user, should be addressed in end-user applications.

Suggest delete: no longer needed.

4.2.1 Literal Equality

Two literals are equal if and only if all of the following hold:

4.2.2 The Value Corresponding to a Typed Literal

The datatype URI refers to a datatype. For XML Schema built-in datatypes, URIs such as <> suggest drop angle brackets. suggest use xsd:int. suggest note somewhere in doc on qname notation. are used. The URI of the datatype rdfs:XMLLiteral may be used. There may be other, implementation dependent, mechanisms by which URIs refer to datatypes.

The last sentence reads oddly. "Other mechanisms". There are no other mechisms mentioned in this para. Suggest: RDF is not restricted to using only the built in datatype rdfs:XMLLiteral and XML Schema built-in datatypes. Any datatype corresponding to the XML Schema datatyping model [ref] may be used, provided it is identified by an RDF URI Reference.

The value associated with a typed literal is found by applying the datatype mapping associated with the datatype URI to the lexical form. The URI does not identify the mapping, it identifies the datatype. Suggest: The value denoted by a typed literal is determined by applying the datatype mapping of the datatype identified by the RDF URI Reference to the lexical form of the literal. This mapping fails if the lexical form is not in the lexical space of the datatype associated with the datatype URI. Exceptionally, if the datatype is rdfs:XMLLiteral then the datatype mapping is applied to the pair form by the lexical form and the langauge identifier.

In this abstract syntax there are others? the failure of any such mapping is regarded as a semantic rather than a syntactic problem; and this subsection does not create any well-formedness conditions on either the datatype URI or the lexical form.

Suggest: A typed literal for which the datatype does not map the lexical form to a value is not syntacticaly illformed.

4.2.3 Test Cases Concerning Literals

[[Should this subsection be deleted. It is redundant.]]

yes: it won't be complete forever either.

See the following test cases, per [RDF-TESTS]:

Concerning untyped literals:
Concerning literals of type rdfs:XMLLiteral
Concerning literals of other datatypes.

4.3 Nodes

An RDF graph is defined using a set of nodes. Each node may be blank (unlabelled) or labelled with an RDF literal or an RDF URI reference, i.e. there is a partial labelling function from the set of nodes to the union of the set of RDF literals and RDF URI references.

Suggest delete "i.e. there is a partial ..."

In an RDF graph, no two nodes have equal labels; there may be any number of distinct blank nodes. Suggest: Leave that constraint for the section on graphs.

Two nodes are equal if and only if they are the same node. In particular, two different blank nodes are not equal.

4.4 RDF triples

An RDF triple describes an arc in an RDF graph. It contains three components:

If the subject and object nodes of a triple are both labelled with equal labels then they are the same node.

Suggest: delete last sentence. Its redundant.

The subject must not be labelled with an RDF literal.

Two RDF triples are equal if and only if their subjects are equal, their predicates are equal, and their objects are equal.

4.5 RDF graph

An RDF graph is a set of RDF triples.

The set of nodes of an RDF graph is the set of nodes that are either subject or object of some triple in the graph. No two nodes have equal labels.

[[[Suggestions of a standard graph theory text which treats digraphs as primary would be welcome.]]]

Note: The definition of an RDF graph diverges from the definition of a directed graph in a standard text such as [[[missing ref]]] in that: (a) all nodes must be in at least one arc; (b) all the arcs are labelled; (c) some of the nodes are labelled; (d) labels on nodes are required to be distinct; (e) some labels are shared between nodes and arcs; (f) there can be multiple arcs between the same end-points, as long as they are labelled differently.

I'm not sure why this note is here. Is there some significance to this difference?

4.6 Graph Equality

Two RDF graphs are equal if and only if they are isomorphic. Not just any isomorphism will do. Suggest: This section defines the requirements of an RDF Graph Equality Isomorphism. Two graphs are equal if and only if there exists a RDF Graph Equality Isomorphism between them.

An RDF graph Equality isomorphism is a directed graph isomorphism that respects the labels on both arcs and nodes. Dunno what that means. 'respects'? this is in purple cos I assume you are saying something important.

An RDF Graph Equality isomorphism I between two graphs G and G' is a suggest any bijection between the nodes of G and the nodes of G', such that:

for all nodes n, s, o in G and all RDF URI references p.

5. Additional technical considerations

5.1 Character normalization

[[[This subsection normatively depends on CHARMOD, currently a last call working draft. If CHARMOD has not reached the appropriate recommendation status as this document progresses down the recommendation track, this section will be deleted.]]]

What is the current status of charmod?

[[[WG-REVIEW: Moreover, the CHARMOD editors seem minded to respond to (multiple) last call comments about their dependency on IRI-draft by waiting for IRI to move along the standards track. Thus, it is likely that this subsection will go.]]]

For the processing of character data that can be represented in different ways, RDF processors are required to conform to Early Uniform Normalization, as described by Character Model for the World Wide Web 1.0 [CHARMOD].

5.2 Fragment identifiers

How should RDF treat a URI reference with a fragment identifier? This is a specification. It is supposed to answer questions, not ask them. Conventional web architecture reference has that the meaning of a fragment identifier is dependent on the MIME type of a resource that is obtained by dereferencing the URI part. Suggest: RFC 2396 states that the meaning of a fragment identifier depends on the mime type of a document. URIs without fragment identifiers are generally presumed to map to some resource for which a Web representation (or several) can be retrieved. I'm not sure how general that presumption is, but the tag seem split n:1 (the one being tbl) in favour of the view that URI's without fragment identifiers can name things that are not web retrievable. Are you confusing URI's and http URI's here? But RDF has no concept of a fragment identifier separate from a URI: RDF treats a URI reference as an opaque identifier that denotes some resource [RDF-SEMANTICS]. Further, an RDF resource identifier may denote something that is not web-retrievable; e.g. a car, or a Unicorn.

This needs some polishing. Out with the brasso and trying:

RDF uses an RDF URI Reference, which may include a fragment identifier, as a context free identifier for a resource. RFC 2396 states that the meaning of a fragment identifier depends on the mime type of a document, i.e. is context dependent.

These apparently conflicting interpretations can be reconciled if:

We ought to say if we are reconcilling them or not. Suggest: These apparently conflicting views are reconcilled as follows:

This provides a handling of URI referencess and their denotation that is consistent with the RDF model theory and usage, and also with conventional web behaviour. This approach somewhat extends the idea of a "fragment" or "view" beyond the common idea (when handling web documents) that it is a physical part of a containing document. Suggest delete last sentence on the grounds that a) its wrong - what is proposed is entirely consistent with the standard interpretation of fragment identifiers and b) if we go around mucking with them we wont have a defense when we get comments.

In view of this, it is reasonable to consider that URIs without fragment identifiers are most helpfully used for indicating web-retrievable resources (when used in RDF), and URIs with fragment identifiers are used for abstract ideas that don't have a direct web representation.

We don't need to say this.

This is not a hard-and-fast distinction, as the line between resources having or not having a web-retrievable representation is sometimes hard to draw precisely.

5.3 Forming a URI reference from a QName

The RDF/XML syntax uses QName syntax [XML-NS], section 3, to identify various resources, notably RDF properties. But the RDF graph syntax contains only URI references, and does not recognize QName forms.

Mostly, QNames are handled by the mapping between RDF/XML documents and RDF graph syntax. But there are some occasions where an RDF writer needs to know the correspondence between QNames and URI references (e.g. when using a typed node production). The mapping is described in [RDF-SYNTAX], sections 3.1.2 or 3.1.4.

Why is this here? If you are using qnames in this document then by all means explain the notation. But I don't think you do, so just leave this to the syntax doc.

6. Acknowledgments

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.

Some neutral ordering of names in these lists would be appropriate.

The editors acknowledge valuable contributions from the following:

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

This document is a product of extended deliberations by the RDFcore working group, whose members have included:

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. Whats in here that came from the schema document? RDF and RDF Schema Working group members who contributed to this earlier work are:

7. References

7.1 Normative References

RDF/XML Syntax Specification (Revised), Dave Beckett, World Wide Web Consortium, July 2002 (work in progress). The latest version is at
RDF Model Theory, P. Hayes, Editor. Work in progress. World Wide Web Consortium, 14 February 2002. This version of the RDF Model Theory is The latest version of the RDF Model Tlatest version of the RDF Model Theory is at
RDF Vocabulary Description Language 1.0: RDF Schema, Dan Brickley, R.V. Guha, World Wide Web Consortium, April 2002 (work in progress). The latest vesion is at
Application/rdf+xml Media Type Registration, A. Swartz, IETF Internet Draft, March 2002 (work in progress). Version available at
RDF Test Cases, Jan Grant and Dave Beckett, Editors. Work in progress. World Wide Web Consortium, 29 April 2002. This version of the RDF Test Cases is The latest version of the RDF Test Cases is at
Extensible Markup Language (XML) 1.0, Second Edition, T. Bray, J. Paoli, C.M. Sperberg-McQueen and E. Maler, Editors. World Wide Web Consortium. 6 October 2000. This version is The latest version of XML is available at
Namespaces in XML, T. Bray, D. Hollander and A. Layman, Editors. World Wide Web Consortium. 14 January 1999. This version is The latest version of Namespaces in XML is available at
RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding and L. Masinter, IETF, August 1998. This document is
RFC 2732 - Format for Literal IPv6 Addresses in URL's, R. Hinden, B. Carpenter and L. Masinter, IETF, December 1999. This document is
RFC 2279 - UTF-8, a transformation format of ISO 10646, F. Yergeau, IETF, January 1998. This document is
The Unicode Standard, Version 3, The Unicode Consortium, Addison-Wesley, 2000. ISBN 0-201-61633-5, as updated from time to time by the publication of new versions. (See for the latest version and additional information on versions of the standard and of the Unicode Character Database).
Unicode Normalization Forms, Unicode Standard Annex #15, Mark Davis, Martin Dürst. (See for the latest version).
Character Model for the World Wide Web 1.0, M. Dürst, F. Yergeau, R. Ishida, M. Wolf, A. Freytag, T Texin, Editors, World Wide Web Consortium Working Draft, work in progress, 20 February 2002. This version of the Character Model is The latest version of the Character Model is at
RFC 3066 - Tags for the Identification of Languages, H. Alvestrand, IETF, January 2001. This document is
Canonical XML. J. Boyer. W3C Recommendation, March 2001.
Available at
Available at
RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, IETF. March 1997. This document is [[[Is this used?]]]
RFC 3032 - XML Media Types, M. Murata, S. St.Laurent, D.Kohn, IETF, January 2001. This document is

7.2 Informational References

RDF Primer, F. Manola, E. Miller, Editors, World Wide Web Consortium W3C Working Draft, work in progress, 19 March 2002. This version of the RDF Primer is The latest version of the RDF Primer is at
Extensible Markup Language (XML) 1.1, John Cowan, Editor. World Wide Web Consortium Working Draft 25 April 2002. (Work in progress)
Namespaces in XML 1.1, Tim Bray, Dave Hollander, Andrew Layman, Richard Tobin, Editors. World Wide Web Consortium Working Draft 5 September 2002. (Work in progress)
XML Information Set, John Cowan and Richard Tobin, W3C Recommendation, 24 October 2001. This document is
XML Schema Part 0: Primer - W3C Recommendation, World Wide Web Consortium, 2 May 2001.
XML Schema Part 1: Structures - W3C Recommendation, World Wide Web Consortium, 2 May 2001.
XML Schema Part 2: Datatypes - W3C Recommendation, World Wide Web Consortium, 2 May 2001.
OWL Web Ontology Language 1.0 Reference, Mike Dean, Dan Connolly, Frank van Harmelen, James Hendler, Ian Horrocks, Deborah L. McGuinness, Peter F. Patel-Schneider, and Lynn Andrea Stein. W3C Working Draft 29 July 2002. Latest version is available at
Knowledge Representation: Logical, Philosophical and Computational Foundations, John F. Sowa, Brookes/Cole, 2000. ISBN 0-534-94965-7.
Mathematical Background, John F. Sowa, (an extended version of appendix A from Conceptual Structures: Information Processing in Mind and Machine, 1984).
Conceptual Graphs, John F. Sowa, ISO working document ISO/JTC1/SC 32/WG2 N 000, 2 April 2001 (work in progress). Available at
Knowledge Interchange Format, Michael R. Genesereth, draft proposed American National Standard NCITS.T2/98-004. Available at
Artificial Intelligence: Structures and Strategies for Complex Problem Solving (3rd ed.), George F. Luger and William A. Stubblefield, Addison Wesley Longman, 1998. ISBN 0-805-31196-3.
In Defense of Logic, Patrick J. Hayes, Proceedings from the International Joint Conference on Artificial Intelligence, 1975, San Francisco. Morgan Kaufmann Inc., 1977. Also in Computation and Intelligence: Collected Readings, George F. Luger (ed), AAAI press/MIT press, 1995. ISBN 0-262-62101-0.
Logic, Algebra and Databases, Peter Gray, Ellis Horwood Ltd., 1984. ISBN 0-85312-709-3, 0-85312-803-0, 0-470-20103-7, 0-470-20259-9.
Metalogic: An Introduction to the Metatheory of Standard First Order Logic, Geoffrey Hunter, University of California Press, 1971. ISBN 0-520-02356-0.
Truth, Deduction and Computation: logic and semantics for computer science, Ruth E. Davis, Computer Science Press, 1989. ISBN 0-7167-8201-4.
Philosophy of Logic (2nd ed.), W. V. Quine, Harvard University Press 1986, ISBN 0-674-66563-5.
Tim Berners-Lee, DesignIssues note on N3, ...
Resource Description Framework (RDF) Model and Syntax Specification, O. Lassila and R. Swick, Editors. World Wide Web Consortium. 22 February 1999. This version is The latest version of RDF M&S is available at
Resource Description Framework (RDF) Schema Specification 1.0, Dan Brickley and R. V. Guha, W3C Candidate Recommendation, 27 March 2000. This document is
Reference by Description, R. V. Guha: (Related to the TAP project:

Appendix Y: Change log

[[[For reviewers' reference. This appendix will be removed on final publication.]]]

$Log: rdf-concepts.html,v $
Revision 1.16  2002/10/25 09:46:12  graham
Jeremy's updates to abstract syntax and datatyped literals.
- *all* literals are typed
- two new predefined types for what were previously untyped literals.
- literal is a pair (datatypeURI, lexical form)
- lexical form is also a pair (string, language-identifier)
- datatype mappings (see section 2.4.4) can be from string=>value or from lexical form=>value
Some reformatting of the HTML.

Revision 1.15  2002/10/22 17:44:29  graham
Fix up editing errors.
Relinquish lock to Jeremy.

Revision 1.14  2002/10/22 17:10:18  graham
Clean up some text.
Relinquish lock to Jeremy.

Revision 1.13 2002/10/22 16:11:25 graham
Sect. 2.3.2 fix typos
Sect. 2.3.2 clarify distinction between assertional form and making an assertion
Sect. 2.4.6 new section about entailment

Revision 1.12  2002/10/17 17:19:32  graham
Minor editorial changes.
Added link and email for GK.

Revision 1.11  2002/10/17 16:22:29  graham
Jeremy's changes - lock relinquished:
- name to include middle initial, e-mail and links
- added some of Frank's text to 2.4.1, with new ref to Sowa2
- updated 3.1 URI Ref to be very like XML Namespaces 1.1 section 7 IRI
- updated 3.2 using majority text with little bits from minority text
- added acknowledgement to host in Pisa
- added Sowa2 ref

Revision 1.10  2002/10/14 14:00:32  graham
Minor updates; hand lock to Jeremy

Revision 1.9  2002/10/10 14:55:15  graham
Folded in co-editor review comments, added reference to OWL.

Revision 1.8  2002/10/07 15:16:59  graham
Add 'latest' version of RDF concepts

Revision 1.7  2002/10/02 11:39:44  graham
Incorporate revised wording on formal semantics into section 2.3.1

Revision 1.6  2002/09/30 17:22:17  graham
Fold in some further comments from Pat Hayes

Revision 1.5  2002/09/30 12:11:05  graham
Remove some superfluous comments and reference

Revision 1.4  2002/09/30 11:58:40  graham
Update document links following move to new directory

Revision 1.3  2002/09/30 11:38:20  graham
Incorporated material from datatyping draft,
per issue 010-DatatypingConcepts

Revision 1.2  2002/09/30 10:09:07  graham
Add new sections for literals and datatyping
Address issue 008-InteractionUnclear
Address issue 011-DatatypingAcknowledgement
Address issue 012-AssertionConflictingUse
Address remaining non-syntax items from  issue 013-Various
Regenerate table of contents

Revision 1.1  2002/09/30 09:32:01  graham
Update document and move to RDF-Concepts directory

Revision 1.9  2002/09/28 17:30:42  graham
Rework section 2.3 to take account of comments from Pat Hayes and
Tim Berners-Lee, and incorporating a sanitized version of Pat's example
of formal entailment of social meaning.

Revision 1.8  2002/09/26 16:55:46  graham
Fix up previous document link

Revision 1.7  2002/09/26 16:30:14  graham
Apply edits for issue 007-Meaning-machinery

Revision 1.6  2002/09/26 13:32:26  graham
Apply edits for issue 003-ModelTheory.html

Revision 1.5  2002/09/26 13:15:15  graham
Apply edits for issue 002-InconsistentAssertions

Revision 1.4  2002/09/26 12:36:27  graham
Apply edits for issue 001-Editorial

Revision 1.3  2002/09/26 12:13:02  graham
Update previous version links

Revision 1.2  2002/09/26 12:01:36  graham
Re-import published WD as editors' working copy


Suggested text for Syntax doc

Two alternative versions which could go in this subsection: or perhaps

precise unreadable version

The string value associated with the literal text l is implementation dependent. The literal node produced from the string value associated with this literal text is related by the rdfs:XMLLiteral datatype to a value, which is a canonical XML document.

[[[This next para is a mouthful...]]]

A constraint placed on the string value, is that the exclusive canonicalization without comments [XC14N] of the literal text l (i.e. the entire element content of the enclosing element) is equal to the exclusive canonicalization without comments of the root element content of this related canonical XML document.

This condition leaves the treatment of comments and namespaces that are not visibly utilized (as defined by [XC14N]), as well as the treatment of aspects of XML that are not reflected in canonical XML, as implementation dependent.

The RDF Test Cases [RDF-TESTS] use the exclusive canonicalization without comments to compute the string value of the literal.

more readable, slightly less precise version

The string value associated with the literal text l is implementation dependent. The literal node produced from the string value associated with this literal text is related by the rdfs:XMLLiteral datatype to a value, which is a canonical XML document.

The string value must preserve the information found in the exclusive canonicalization without comments [XC14N] of the literal text l.

The string value may be the exclusive canonicalization with or without comments [XC14N] of the literal text l.

The treatment of namespaces that are not visibly utilized (as defined by [XC14N]), XML comments, and of aspects of an XML document that are not reflected in the canonical form (e.g. insignificant white space within element tags) is explicitly implementation dependent.

The RDF Test Cases [RDF-TESTS] use the exclusive canonicalization without comments, discarding namespaces that are not visibly utilized, in order to compute the string value of the literal.

Other Editorial

Markup issues to be considered: <code> vs <p class=code>; note format; spurious <div class="head"> elements ; <blockquote> for indented text.

RDF/XML Metadata