RDF Semantics

This is a specification of a precise semantics for RDF and RDFS, semantics, and deleted text: of corresponding <a href="#glossEntail" class="termref"> entailment </a> and <a href="#glossInference" class="termref"> complete systems of inference </a> rules which are sanctioned by rules, for the semantics. Resource Description Framework (RDF) and RDF Schema (RDFS).

Status of this Document

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

Detailed changes from the previous 5 September 2003 working draft are described in Appendix D. The requirement on character strings being in Normal Form C has been weakened from MUST to SHOULD; all the other changes are editorial.

This document is in the Last Call review period, which ends on 21 February 07 November 2003. This Last Call publication consolidates changes and editorial improvements undertaken in response to feedback received during the previous Last Call publication of the RDFCore specifications which began on 23 January 2003. A list of the Last Call issues addressed by the Working Group is also available. This document has been endorsed by the RDF Core Working Group.

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

deleted text: The Working Group notes that this Last Call Working Draft completes the group's design of the formal Semantics for RDF, however it may still need some editorial polishing and clarification following Last Call. 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.

This is a public W3C deleted text: Last Call Working Draft for review by W3C Members and other interested parties. This section describes the status of this document at the time of its publication. It Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced, replaced or obsoleted by other documents at any time. It is inappropriate to deleted text: use W3C Working Drafts as reference material or to cite this document as other than "work work in progress". progress. A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/ .

0. Introduction deleted text:

0.1 Specifying a formal semantics: scope and limitations

RDF is an assertional language intended to be used to express propositions using precise formal vocabularies, particularly those specified using RDFS [ [RDF-VOCABULARY] </a>, RDF-VOCABULARY ], for access and as use over the World Wide Web, and is intended to provide a basic foundation for more advanced assertional languages. languages with a similar purpose. The overall design goals emphasise generality and precision in expressing propositions about any topic, rather than conformity to any particular processing model: see the RDF Concepts document [ RDF-CONCEPTS ] for more discussion.

Exactly what is considered to be the 'meaning' of an assertion in RDF/S RDF or RDFS in some broad sense may depend on many factors, including social conventions, comments in natural language or links to other content-bearing documents. Much of this meaning will be inaccessible to machine processing and is mentioned here only to emphasize that the formal semantics described here in this document is not intended to provide an a full analysis of 'meaning' in this broad sense. sense; that would be a large research topic. The semantics given here restricts itself to a formal notion of meaning which could be characterized as the part that is common to all other accounts of meaning, and can be captured in mechanical inference rules. deleted text: For @@check link@@ <a href="http://www.w3.org/TR/rdf-concepts/#section-Social"> further discussion of notions of meaning in RDF </a> , see <a href="#ref-rdf-concepts"> [RDF-CONCEPTS] </a>

We use This document uses a basic technique called model theory for specifying the semantics of a formal language. Readers unfamiliar with model theory may find the glossary in appendix C B helpful; throughout the text, uses of terms in a technical sense are linked to their glossary definitions. deleted text: <a href="#glossModeltheory" class="termref"> Model theory deleted text: </a> assumes that the language refers to a ' world ', and describes the minimal conditions that a world must satisfy in order to assign an appropriate meaning for every expression in the language. A particular <a href="#glossWorld" class="termref"> world is called an interpretation , so that model theory might be better called 'interpretation theory'. The idea is to provide an abstract, mathematical account of the properties that any such interpretation must have, making as few assumptions as possible about its actual nature or intrinsic structure. structure, thereby retaining as much generality as possible. The chief utility of a formal semantic theory is not to provide any deep analysis of the nature of the things being described by the language or to suggest any particular processing model, but rather to provide a technical way to determine when inference processes are valid , i.e. when they preserve truth. This provides the maximal freedom for implementations while preserving a globally coherent notion of meaning.

Model theory tries to be metaphysically and ontologically neutral. It is typically couched in the language of set theory simply because that is the normal language of mathematics - for example, this semantics assumes that names denote things in a set IR called the ' universe ' - but the use of set-theoretic language here is not supposed to imply that the things in the universe are set-theoretic in nature. Model theory is usually most relevant to implementation via the notion of entailment , described later, which makes it possible to define valid inference rules.

The chief utility of a formal semantic theory is not to provide any deep analysis of the nature of the things being described by the language or to suggest any particular processing model, but rather An alternative way to provide specify a technical way semantics is to deleted text: determine when inference processes are valid, i.e. when they preserve truth. In this document we give two versions of the same semantic theory: directly, and also (in an informative appendix) an a translation from RDF into a formal logic with a model theory already attached, as it were. This 'axiomatic semantics' in the form approach has been suggested and used previously with various alternative versions of the target logical language [ Conen&Klapsing ] [ Marchiori&Saarela ] [ McGuinness&al ]. Such a translation from for RDF and RDFS into another formal language, is also given in the L _base specification [ [LBASE] LBASE which has a pre-defined model-theoretic semantics. ]. The translation technique offers axiomatic semantics style has some advantages for machine processing and may be more readable, so is described here as a convenience. We believe but in the event that both of these descriptions, and also any axiomatic semantics fails to conform to the closure rules model-theoretic semantics described in section 4, are all in exact correspondence, but only this document, the deleted text: directly described model theory deleted text: in sections 1- 3 should be taken as normative.

There are several aspects of meaning in RDF which are ignored by this semantics; in particular, it treats URI references as simple names, ignoring aspects of meaning encoded in particular URI forms [ [RFC 2396] RFC 2396 ] and does not provide any analysis of time-varying data or of changes to URI references. It does not provide any analysis of indexical uses of URI references, for example to mean 'this document'. Some parts of the RDF and RDFS vocabularies are not assigned any formal meaning, and in some cases, notably the reification and container vocabularies, it assigns less meaning than one might expect. These cases are noted in the text and the limitations discussed in more detail. deleted text: RDF is an assertional logic , in which each triple expresses a simple proposition . This imposes a fairly strict monotonic discipline on the language, so that it cannot express closed-world assumptions, local default preferences, and several other commonly used non-monotonic constructs.

Particular uses of RDF, including as a basis for more expressive languages such as DAML DAML+OIL [ DAML ] and OWL [ OWL ], may impose further semantic conditions in addition to those described here, and such extra semantic conditions can also be imposed on the meanings of terms in particular RDF vocabularies. Extensions or dialects of RDF which are obtained by imposing such extra semantic conditions may be referred to as semantic extensions of RDF. Semantic extensions of RDF are constrained in this recommendation using the language keywords MUST , MUST NOT , SHOULD and MAY of [ [RFC 2119] </a>. RFC 2119 ]. Semantic extensions of RDF MUST conform to the semantic conditions for simple and RDF entailment interpretations described in sections 1 and 3.1 of this document. Any name for entailment in a semantic extension SHOULD be indicated by the use of a <a href="#vocabulary_entail"> vocabulary entailment term. The semantic conditions imposed on an RDF semantic extension MUST define a notion of <a href="#vocabulary_entail"> vocabulary entailment which is valid according to the model-theoretic semantics described in the normative parts of this document; except that if the semantic extension is defined on some syntactically restricted subset of RDF graphs, graphs , then the semantic conditions need only apply to this subset. Specifications of such syntactically restricted semantic extensions MUST include a specification of their syntactic conditions which are sufficient to enable software to distinguish unambiguously those RDF graphs to which the extended semantic conditions apply. Applications based on such syntactically restricted semantic extensions MAY treat RDF graphs which do not conform to the required syntactic restrictions as syntax errors.

An example of a semantic extension of RDF is RDF Schema, Schema [ RDF-VOCABULARY ], the semantics of which are defined in later parts of this document. RDF Schema imposes no extra syntactic restrictions.

0.2 Graph syntax Syntax

Any semantic theory must be attached to a syntax. This semantics is defined as a mapping on the <a href="http://www.w3.org/TR/rdf-concepts/#section-Graph-syntax"> abstract syntax of RDF described in the RDF concepts and abstract syntax document [ [RDF-CONCEPTS] </a>. We use RDF-CONCEPTS ]. This document uses the following terminology defined there: <a href="http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref"> uriref URI reference , <a href="http://www.w3.org/TR/rdf-concepts/#section-Graph-Literal"> literal , <a href="http://www.w3.org/TR/rdf-concepts/#section-Literals"> plain literal , <a href="http://www.w3.org/TR/rdf-concepts/#section-Literals"> typed literal , <a href="http://www.w3.org/TR/rdf-concepts/#section-URI-Vocabulary"> XML literal , XML value, node , blank node </a> and <a href="http://www.w3.org/TR/rdf-concepts/#xtocid103646"> , triple </a>. The convention that relates a set of triples to a picture of an and RDF graph can be stated as follows. Draw one oval for each blank node and uriref which occur in either the S or O position in any triple in . Throughout this document we use the set, and one rectangle for each literal, and write each uriref term 'character string' or literal as the label of its shape. Shapes corresponding to blank nodes have no label. Then for each triple <S,P,O>, draw an arrowed line from the shape produced from S 'string' to deleted text: the shape produced from O, and label it with P. Technically, this is a picture of a mathematical structure which can be described as a partially labeled directed pseudograph with unique node labels, but we will simply refer to a set sequence of triples as Unicode characters, and 'language tag' in the sense of RFC 3066, c.f. section 6.5 in [ RDF-CONCEPTS ]. Note that strings in an deleted text: RDF graph . Graphs with isomorphic pictures in this sense are considered to SHOULD be deleted text: identical; this means that we do not distinguish sets of triples which differ only in the identity of their blank nodes. This slight abuse of terminology allows us to simplify the presentation by ignoring questions of re-naming of bound variables. Normal Form C.

This document we will use uses the N-triples N-Triples syntax described in the RDF test cases document [ [RDF-TESTS] RDF-TESTS ] to describe RDF graphs. graphs . This notation uses a nodeID node identifier (nodeID) convention to indicate blank nodes in the triples of a graph. Note that while <a href="http://www.w3.org/TR/rdf-testcases/#bNode"> While node identifiers deleted text: </a> such as '


_:xxx

' serve to identify blank nodes in the surface syntax, these expressions are deleted text: not deleted text: considered to be the label of the graph node they identify; they are not names, and do not occur in the actual graph. In particular, the RDF graphs described by two N-triples N-Triples documents which differ only by re-naming their node identifiers will be understood to describe identical be equivalent . This re-naming convention should be understood as applying only to whole documents, since re-naming the node identifiers in part of a document may result in a document describing a different RDF graphs. graph .

The N-triples N-Triples syntax requires that urirefs URI references be given in full, enclosed in angle brackets. In the interests of brevity, deleted text: we use the imaginary URI scheme 'ex:' is used to provide illustrative examples. To obtain a more realistic view of the normal appearance of the N-triples N-Triples syntax, the reader should imagine this replaced with something like 'http://www.example.org/rdf/mt/artificial-example/'. We will also make extensive use of the Qname '


http://www.example.org/rdf/mt/artificial-example/

'. The QName prefixes


rdf:


rdfs:

and


xsd:

are defined as follows:

Since Qname QName syntax is not legal N-triples N-Triples syntax, and in the interests of brevity and readability, we will examples use the convention whereby a Qname QName is used without surrounding angle brackets to indicate the corresponding uriref URI reference enclosed in angle brackets, eg e.g. the triple


<ex:a>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>


<http://www.w3.org/2000/01/rdf-schema#Property>



<http://www.w3.org/2000/01/rdf-schema#Class>


.

In stating deleted text: rules and giving general semantic conditions we will use conditions, single characters or character sequences without a colon deleted text: to indicate an arbitrary name or name, blank node node, character string and so on. The exact meaning will be specified in a triple. context.

0.3 Graph Definitions

Several definitions will be important in what follows.They are stated together here for reference. An RDF graph , or simply a graph , is a set of RDF triples.

A subgraph of an RDF graph is deleted text: simply a subset of the triples in the graph. We will identify each A triple is identified with the singleton set containing it, so that each triple in a graph is considered to be a subgraph. <a name="defmerg" id="defmerg"> Consider A proper subgraph is a set S of graphs which share no blank nodes. The graph consisting proper subset of deleted text: all the triples in deleted text: all the graphs in S is another graph, which we will call the merge of S. </a> Each of the original graphs is a subgraph of the deleted text: merged graph. deleted text: Notice that when forming a merged graph, two occurrences of a given uriref or literal as nodes in two different graphs become a single node in the union graph (since by definition they are the same uriref or literal), but blank nodes are not 'merged' in this way. If the members of the set S share some blank nodes, then we will define the merge of S to be the merge of a set obtained by replacing blank nodes in some members of S by distinct blank nodes to obtain another set S' of graphs which are isomorphic to those in S. Notice that one does not, in general, obtain the merge of a set of graphs by concatenating their corresponding N-triples documents and constructing the graph described by the merged document, since if some of the documents use the same node identifiers, the merged document will describe a graph in which some of the blank nodes have been 'accidentally' merged. To merge Ntriples documents it is necessary to check if the same nodeID is used in two or more documents, and to replace it with a distinct nodeID in each of them, before merging the documents. Similar cautions apply to merging graphs described by RDF/XML documents which contain nodeIDs, see <a href="#ref-rdf-syntax"> [RDF-SYNTAX] </a>.

<a name="defvocab" id="defvocab"> We will refer to a set of urirefs as a vocabulary . The vocabulary of a graph is the set of urirefs that it contains (either as nodes, on arcs or in typed literals). </a> <a id="defname" name="defname"> </a> A name is a uriref URI reference or a typed literal. A name is from a vocabulary V if it is a URI reference in V or deleted text: is a typed literal containing a uriref an internal type URI reference in V. The names of a graph are all the names name s which occur in the graph. This is These are the deleted text: set of expressions that need to be assigned a meaning by an interpretation . We do not think of plain Plain literals are not classified as names because their interpretation is fixed by the RDF semantic rules. When giving examples, we will sometimes use fixed. Note that a string of characters with no intervening colon to indicate 'some name'. typed literal comprises two name s: itself and its internal type URI reference.

<a name="definst" id="definst"> An A set of name s is referred to as a instance vocabulary . The vocabulary of an RDF graph is, intuitively, a deleted text: similar graph deleted text: in which some blank nodes may have been replaced by urirefs or literals, so that for example "Jocasta married Oedipus" is an instance the set of names of deleted text: "Jocasta married somebody". However, it is technically convenient to also allow blank nodes to be replaced by other blank nodes, so we need to state this rather more precisely. the graph.

This allows blank nodes An instance with respect to a vocabulary V is an instance in which all the second graph to be replaced by names name s in the instance deleted text: (which might cause some nodes to be identified that were previously distinct) but it also allows them to be replaced by other substituted for blank nodes. For example, nodes in the graph: original are name s from V.

<code> _:xxx <ex:b> _:xxx . </code> is an A proper instance of <code> _:xxx <ex:b> _:yyy . </code> In particular, any a graph obtained is an instance in which a blank node has been replaced by replacing all a name or a plain literal, or two blank nodes by in the graph have been mapped into the same node in the instance.

Any instance of a graph in which a blank node is mapped to a new blank nodes node not in the original graph is an instance of the original and also, by inverting the mapping, also has it as an instance, and this process can be iterated so that any 1:1 mapping between blank nodes defines an instance of a graph which has the original graph as an instance. By our convention, Two such isomorphic graphs graphs, each an instance of the other but neither a proper instance, which differ only in the identity of their blank nodes, are considered to be identical. equivalent . We will treat such equivalent graphs as identical; this allows us to ignore some issues which arise from 're-naming' nodeIDs, and is in conformance with the convention that blank nodes have no label. Equivalent graphs are mutual instances with an invertible instance mapping.

<a name="definstvoc" id="definstvoc"> An instance with respect to A merge of a vocabulary V set of RDF graphs is an instance defined as follows. If the graphs in deleted text: which all the names set have no blank nodes in common, then the instance union of the graphs is a merge; if they do share blank nodes, then it is the union of a set of graphs that were substituted for is obtained by replacing the graphs in the set by equivalent graphs that share no blank nodes. This is often described by saying that the blank nodes have been 'standardized apart'. It is easy to see that any two merges are equivalent, so we will refer to the merge, following the convention on equivalent graphs. Using the convention on equivalent graphs and identity, any graph in the original are names from V. set is considered to be a subgraph of the merge.

One does not, in general, obtain the merge of a set of graphs by concatenating their corresponding N-Triples documents and constructing the graph described by the merged document. If some of the documents use the same node identifiers, the merged document will describe a graph in which some of the blank nodes have been 'accidentally' identified. To merge N-Triples documents it is necessary to check if the same nodeID is used in two or more documents, and to replace it with a distinct nodeID in each of them, before merging the documents. Similar cautions apply to merging graphs described by RDF/XML documents which contain nodeIDs, see RDF/XML Syntax Specification (Revised) [ RDF-SYNTAX ].

1. Interpretations deleted text:

1.1 Technical Notes note (Informative)

We do RDF does not impose any logical restrictions on the domains and ranges of properties; in particular, a property may be applied to itself. When classes are introduced in RDFS, we will allow them to they may contain themselves. This Such 'membership loops' might seem to violate the axiom of foundation, one of the axioms of standard (Zermelo-Fraenkel) set theory, deleted text: the axiom of foundation, which forbids infinitely descending chains of membership. However, the semantic model given here distinguishes properties and classes considered as objects from their extensions - the sets of object-value pairs which satisfy the property, or things that are 'in' the class - thereby allowing the extension of a property or class to contain the property or class itself without violating the axiom of foundation. In particular, this use of a class extension mapping allows classes to contain themselves. For example, it is quite OK for (the extension of) a 'universal' class to contain the class itself as a member, a convention that is often adopted at the top of a classification hierarchy. (If an extension contained itself then the axiom would be violated, but that case never arises.) The technique is described more fully in [ [Hayes&Menzel Hayes&Menzel ].

In this respect, RDFS differs from many conventional ontology frameworks such as UML which assume a more structured system hierarchy of 'layers', individuals, sets of individuals, etc., or which draw a sharp distinction between data and meta-data. However, while RDFS does not assume the existence of such structure, it does not prohibit it. RDF allows such membership loops, but it does not mandate their use for all parts of a user vocabulary. If this aspect of RDFS is found worrying, then it is possible to restrict oneself to a subset of RDF graphs which do not contain any such 'loops' of class membership or property application, and still retain application while retaining much of the expressive power of RDFS for many practical purposes. purposes, and semantic extensions may impose syntactic conditions which forbid such looped constructions.

The use of the explicit extension mapping also makes it possible for two properties to have exactly the same values, or two classes to contain the same instances, and still be distinct entities. This means that RDFS classes can be considered to be rather more than simple sets; they can be thought of as 'classifications' or 'concepts' which have a robust notion of identity which goes beyond a simple extensional correspondence. This property of the model theory has significant consequences in more expressive languages built on top of RDF, such as OWL [ OWL </a>, ], which are capable of expressing identity between properties and classes directly. This ' <a href="#glossMonotonic" class="termref"> intensional ' nature of classes and properties is sometimes claimed to be a useful property of a descriptive language, but a full discussion of this issue is beyond the scope of this document.

Notice that the question of whether or not a class contains itself as a member is quite different from the question of whether or not it is a subclass of itself. All classes are subclasses of themselves.

1.2 Urirefs, resources URI references, Resources and literals Literals .

RDF uses two kinds of referring expression, urirefs and literals. We make very simple and basic assumptions about these. Urirefs are treated as logical constants, i.e. as names which denote things (the things are called 'resources', following <a href="#ref-2369"> [RFC 2396] </a>, but no assumptions are made here about the nature of <a href="#glossResource" class="termref"> resources </a> ; we treat 'resource' here as synonymous with 'entity'.) The meaning of a literal is principally determined by its character string: it either refers to the value mapped from the string by the associated datatype, or if no datatype is provided then it refers to the literal itself, which is either a unicode character string or a pair of a string with a language tag. We do This document does not take any position deleted text: here on the way that urirefs URI references may be composed from other expressions, e.g. from relative URIs or Qnames; QNames; the semantics simply assumes that such lexical issues have been resolved in some way that is globally coherent, so that a single uriref URI reference can be taken to have the same meaning wherever it occurs. Similarly, the semantics has no special provision for tracking temporal changes. It assumes, implicitly, that urirefs URI references have the same meaning whenever they occur. To provide an adequate semantics which would be sensitive to temporal changes is a research problem which is beyond the scope of this document.

The semantics does not assume any particular relationship between the denotation of a uriref URI reference and a document or network Web resource which can be obtained retrieved by using that uriref URI reference in an HTTP transfer protocol, or any entity which is considered to be the source of such documents. Such a requirement could be added as a semantic extension, but the formal semantics described here makes no assumptions about any connection between the denotations of urirefs URI references and the uses of those urirefs URI references in other protocols.

The semantics treats all RDF name s as expressions which denote. The things denoted are called 'resources', following [ RFC 2396 ], but no assumptions are made here about the nature of resources ; 'resource' is treated here as synonymous with 'entity', i.e. as a generic term for anything in the universe of discourse.

The different syntactic forms of name s are treated in particular ways. URI references are treated simply as logical constants. Plain literals are considered to denote themselves, so have a fixed meaning. The denotation of a typed literal is the value mapped from its enclosed character string by the datatype associated with its enclosed type. RDF assigns a particular meaning to literals typed with


rdf:XMLLiteral

, described in section 3 .

1.3 Interpretations

The basic intuition of model-theoretic semantics is that asserting a sentence makes a claim about the world : it is another way of saying that the world is, in fact, so arranged as to be an interpretation which makes the sentence true. In other words, an assertion amounts to stating a constraint on the possible ways the world might be. Notice that there is no presumption here that any assertion contains enough information to specify a single unique interpretation. It is usually impossible to assert enough in any language to completely constrain the interpretations to a single possible world, so there is no such thing as 'the' unique interpretation of an RDF interpretation. graph. In general, the larger an RDF graph is - the more it says about the world - then the smaller the set of interpretations that an assertion of the graph allows to be true - the fewer the ways the world could be, while making the asserted graph true of it.

The following definition of an interpretation is couched in mathematical language, but what it amounts to intuitively is that an interpretation provides just enough information about a possible way the world might be - a 'possible world' - in order to fix the truth-value (true or false) of any ground RDF triple. It does this by specifying for each uriref, URI reference, what it is supposed to be a name of; and also, if it is used to indicate a property, what values that property has for each thing in the universe ; and if it is used to indicate a datatype, we assume datatype , that the datatype defines a mapping between lexical forms and datatype values. This is just enough information to fix the truth-value of any ground triple, and hence any ground RDF graph.(We will show how to determine the truth-values of non-ground graph. (Non-ground graphs are considered in the following section.) Notice Note that if deleted text: we left any of this information out, were omitted, it would be possible for some well-formed triple to be left without a determinate value; and also that any other information - such as the exact nature of the things in the universe - would, regardless of its intrinsic interest, be irrelevant to the actual truth-values of any triple.

All interpretations will be relative to a set of urirefs, name s, called the vocabulary of the interpretation; so that one should speak, strictly, of an interpretation of an RDF vocabulary, rather than of RDF itself. Some interpretations may assign special meanings to the symbols in a particular vocabulary. Interpretations which share the special meaning of a particular vocabulary will be named for that vocabulary, so that we will speak of 'rdf-interpretations' , 'rdfs-interpretations', etc.. e.g. ' rdf-interpretation s', ' rdfs-interpretation s', etc. An interpretation with no particular extra conditions on a vocabulary (including the RDF vocabulary itself) will be called a simple interpretation, or simply an interpretation. deleted text: A simple interpretation can be viewed as having an empty vocabulary.

RDF uses several forms of literal. The chief semantic characteristic of literals is that their meaning is largely determined by the form of the string they contain. Plain literals, without an embedded type URI reference, are always interpreted as referring to themselves: either a character string or a pair consisting of a character string and a language tag ; in either case, the character string is referred to as the "literal character string". In the case of typed literals, however, the full specification of the meaning depends on being able to access datatype information which is external to RDF itself; for this reason we postpone a itself. A full discussion of the meaning of typed literals until later sections, is described in section 5 , where deleted text: we introduce a special notion of datatype interpretation. For now, we will assume that each interpretation is introduced. Each interpretation defines a mapping IL from typed literals to their interpretations, and will impose stronger interpretations. Stronger conditions on IL will be defined as the notion of 'interpretation' is extended in later sections. deleted text: Simple literals, without embedded datatypes, are always interpreted as referring to themselves: either a character string or a pair consisting of two character strings, the second of which is a language tag.

The Throughout this document, precise semantic conditions will be set of all possible values of all literals is assumed out in tables which state semantic conditions, tables containing true assertions and valid inference rules, and tables listing syntax, which are distinguished by background color. These tables, taken together, amount to deleted text: be a set called LV. Since formal summary of the set entire semantics. Note that the semantics of deleted text: datatypes is not restricted by RDF syntax, it is impossible to give a sharp definition does not depend on that of LV, but it is required to contain all literal strings, all pairs consisting RDFS. The full semantics of a literal string RDF is defined in sections 1 and a language tag, 3 ; the full semantics of RDFS in sections 1 , 3 and all well-formed canonical XML documents. 4 .

IEXT(x) IEXT(x), called the extension of x, is a set of pairs which identify the arguments for which the property is true, i.e. that is, a binary relational extension, called the <a href="#defexten" class="termref"> extension </a> of x. extension. This trick of distinguishing a relation as an object from its relational extension allows a property to occur in its own extension, as <a href="#technote"> noted </a> earlier. earlier .

The assumption that IR LV is a superset subset of LV IR amounts to saying that literal values are thought of as real entities that 'exist'. This deleted text: assumption may seem controversial, since it amounts to saying that literal values are resources. We note however that However, this does not imply that literals should be identified with urirefs. URI references. Note that LV may contain other items in addition to those listed. There is a technical reason why the range of IL is IR rather than deleted text: being restricted to LV. When deleted text: we consider interpretations deleted text: which take account of datatype information, it is syntactically possible for a typed literal to be internally inconsistent, and deleted text: we will require such badly typed ill-typed literals are required to denote a non -literal value. value, as explained in section 5 .

In the The next sections we give the exact rules for define how an interpretation of a vocabulary determines the truth-values of any RDF graph, by a recursive definition of the denotation - the semantic "value" - of any RDF expression in terms of those of its immediate subexpressions. These apply to all subsequent semantic extensions. RDF has two kinds of denotation: names name s denote things in the universe, and sets of triples denote truth-values.These rules apply to all subsequent semantic extensions. truth-values.

1.4 Denotations of ground graphs Ground Graphs

The denotation of a ground RDF graph in I is given recursively by the following rules, which extend the interpretation mapping I from labels name s to ground graphs. These rules (and extensions of them given later) work by defining the denotation of any piece of RDF syntax E in terms of the denotations of the immediate syntactic constitutents constituents of E, hence allowing the denotation of any piece of RDF to be determined by a kind of syntactic recursion.

In this table, and throughout this document, the equality sign "=" indicates identity.

If the vocabulary of an RDF graph contains urirefs URI references that are not in the vocabulary of an interpretation I - that is, if I simply does not give a semantic value to some name that is used in the graph - then these truth-conditions will always yield the value false for some triple in the graph, and hence for the graph itself. Turned around, this means that any assertion of a graph implicitly asserts that all the names name s in the graph actually refer to something in the world. The final condition implies that an empty graph (an empty set of triples) is trivially true.

Note that the denotation of plain literals is always in LV, and that those of the subject and object of any true triple must be in IR; so any URI reference which occurs in a graph both as a predicate and as a subject or object must denote something in the intersection of IR and IP in any interpretation which satisfies the graph.

As an illustrative example, the following is a small interpretation for the artificial vocabulary {


ex:a,
ex:b,
ex:c

}. We use integers } plus all typed literals with one of these as the type URI. Integers are used to indicate the non-literal 'things' in the universe. This is not meant to imply that deleted text: RDF interpretations should be interpreted as being about arithmetic, but more to emphasize that the exact nature of the things in the universe is irrelevant.(In irrelevant. LV can be any set satisfying the semantic conditions. (In this and subsequent examples deleted text: we use the greater-than and less-than symbols are used in several ways: following mathematical usage to indicate abstract pairs and n-tuples; following Ntriples N-Triples syntax to enclose urirefs, URI references, and also as arrowheads when indicating mappings. We apologize for any confusion.) mappings.)

For example, I(


<ex:a>
<ex:b>
<ex:c>
.

) = true if <I(


ex:a

),I(


ex:c

)> is in IEXT(I(


<ex:b>

)), i.e. if <1,2> is in IEXT(1), which is {<1,2>,<2,1>} and so does contain <1,2> and so I(


<ex:a
<ex:b>
ex:c>

) is true.

The truth of the fourth literal triple is a consequence of the rather idiosyncratic interpretation chosen here for typed literals; literals.

In this kind interpretation IP is a subset of oddity IR; this will be ruled out when we consider datatyped intepretations. typical of RDF semantic interpretations, but is not required.

For example, I(


<ex:a>
<ex:c>
<ex:b>
.

) = true if <I(


ex:a

),I( ), I(


<ex:b>

)>, i.e.<1,1>, is in IEXT(I(


ex:c

)); but I(


ex:c

)=2 and which is not in IP, so IEXT is not defined on 2, so the condition fails and I(


<ex:a>
<ex:c>
<ex:b>
.

) = false.

It also makes all triples containing a plain literal false, since the property extension does not have any pairs containing a character string. plain literal.

To emphasize; this is only one possible interpretation of this vocabulary; there are (infinitely) many others. For example, if deleted text: we modified this interpretation were modified by attaching the property extension to 2 instead of 1, none of the above triples would be true.

This example illustrates that any interpretation which maps any URI reference which occurs in the predicate position of a triple in a graph to something not in IP will make the graph false.

1.5. Blank nodes Nodes as existential assertions Existential Variables

Blank nodes are treated as simply indicating the existence of a thing, without using, or saying anything about, the name of that thing. (This is not the same as assuming that the blank node indicates an 'unknown' uriref; URI reference; for example, it does not assume that there is any uriref URI reference which refers to the thing. The discussion of skolemization Skolemization in the proof appendix A is relevant to this point.)

We now show how an An interpretation can specify the truth-value of a graph containing blank nodes. This will require some definitions, as the theory so far provides no meaning for blank nodes. Suppose I is an interpretation and A is a mapping from some set of blank nodes to the universe IR of I, and define I+A to be an extended interpretation which is like I except that it uses A to give the interpretation of blank nodes. Define blank(E) to be the set of blank nodes in E. Then deleted text: we can extend the above rules can be extended to include the two new cases that are introduced when blank nodes occur in the graph:

Notice that we have this does not changed change the definition of an interpretation; it still consists of the same values IR, IP, IEXT, IS IS, LV and IL. We have It simply extended extends the rules for defining denotations under an interpretation, so that the same interpretation that provides a truth-value for ground graphs also assigns truth-values to graphs with blank nodes, even though it provides no denotation for the blank nodes themselves. Notice also that the blank nodes themselves are perfectly well-defined entities; they differ from other nodes only in not being assigned a denotation by an interpretation, reflecting the intuition that they have no 'global' meaning (i.e. outside the graph in which they occur).

This effectively treats all blank nodes as having the same meaning as existentially quantified variables in the RDF graph in which they occur. However, there is no need to specify the scope of the quantifier within a graph, and no need to use any explicit quantifier syntax.( If we were to apply the semantics directly to N-triples syntax, we would need to indicate the quantifier scope, since in this lexicalization syntax the same node identifier may occur several times corresponding to a single blank node in the graph. The above rule amounts to the convention that would place the quantifiers just outside, or at the outer edge of, the N-triples document corresponding to the graph.) For example, deleted text: with this convention, the graph defined by the following triples is false in the interpretation shown in figure 1:

since if A' maps the blank node to 1 then the first triple is false in I+A', and if it maps it to 2 then the second triple is false.

Note that each of these triples, if thought of as a single graph, would be true in I, but the whole graph is not; and that if a different nodeID were used in the two triples, indicating that the RDF graph had two blank nodes instead of one, then A' could map one node to 2 and the other to 1, and the resulting graph would be true under the interpretation I.

This effectively treats all blank nodes as having the same meaning as existentially quantified variables in the RDF graph in which they occur, and which have the scope of the entire graph. In terms of the N-Triples syntax, this amounts to the convention that would place the quantifiers just outside, or at the outer edge of, the N-Triples document corresponding to the graph. This in turn means that there is a subtle but important distinction in meaning between the operation of forming the union of two graphs and that of forming the merge . The simple union of two graphs corresponds to the conjunction ( 'and' ) of all the triples in the graphs, maintaining the identity of any blank nodes which occur in both graphs. This is appropriate when the information in the graphs comes from a single source, or where one is derived from the other by means of some valid inference process, as for example when applying an inference rule to add a triple to a graph. Merging two graphs treats the blank nodes in each graph as being existentially quantified in that graph , so that no blank node from one graph is allowed to stray into the scope of the other graph's surrounding quantifier. This is appropriate when the graphs come from different sources and there is no justification for assuming that a blank node in one refers to the same entity as any blank node in the other.

2. Simple entailment Entailment between RDF graphs deleted text:

Following conventional terminology, deleted text: we say that I satisfies E if I(E)=true, and deleted text: that a set S of expressions RDF graphs (simply) entails a graph E if every interpretation of the vocabulary of (S union E) which satisfies every member of S also satisfies E. In later sections these notions will be adapted to other classes of interpretations with particular vocabularies, interpretations, but throughout this section 'entailment' should be interpreted as meaning simple entailment.

Entailment is the key idea which connects model-theoretic semantics to real-world applications. As noted earlier, making an assertion amounts to claiming that the world is an interpretation which assigns the value true to the assertion. If A entails B, then any interpretation that makes A true also makes B true, so that an assertion of A already contains the same "meaning" as an assertion of B; we one could say that the meaning of B is somehow contained in, or subsumed by, that of A. If A and B entail each other, then they both "mean" the same thing, in the sense that asserting either of them makes the same claim about the world. The interest of this observation arises most vividly when A and B are different expressions, since then the relation of entailment is exactly the appropriate semantic licence license to justify an application inferring or generating one of them from the other. Through the notions of satisfaction, entailment and validity, formal semantics gives a rigorous definition to a notion of "meaning" that can be related directly to computable methods of determining whether or not meaning is preserved by some transformation on a representation of knowledge.

In this This section we give gives a few basic results about simple entailment and valid inference . Simple entailment can be recognized by relatively simple syntactic comparisons. The two basic forms of simply valid inference in RDF are, in logical terms, the inference from (P and Q) to P, and the inference from (foo baz) foo(baz) to (exists (?x) foo(?x)).

These results apply only to simple entailment, not to the extended notions of entailment introduced in later sections. Proofs, all of which are straightforward, are given in <a href="#prf"> the appendix A , which also describes some other properties of entailment which may be of interest.

Empty Graph Lemma. The empty set of triples is entailed by any graph, and does not entail any graph except itself. [Proof]

The relationship between merging and entailment is simple, and obvious from the definitions:

Merging lemma. The merge of a set S of RDF graphs is entailed by S, and entails every member of S. [Proof]

This means that a set of graphs can be treated as equivalent to its merge, i.e. a single graph, as far as the model theory is concerned. deleted text: In what follows, therefore, we will often not bother to distinguish between a set of graphs and a single graph. This can be used to simplify the terminology somewhat: for example, deleted text: we can paraphrase the definition of S entails E, above, can be paraphrased by saying that S entails E when every interpretation which satisfies S also satisfies E.

The example given in section 1.5 shows that it is not the case, in general, that the simple union of a set of graphs is entailed by the set.

The interpolation lemma completely characterizes simple RDF entailment in syntactic terms. To tell whether a set of RDF graphs entails another, find check that there is some instance of the entailed graph which is a subgraph subset of their the merge and replace names by blank nodes to get of the second. original set of graphs . Of course, there is no need to actually construct the merge. If working backwards from the consequent E , the most an efficient technique would be to treat blank nodes as variables in a process of subgraph-matching, allowing them to bind to 'matching' names name s in the antecedent graph(s) in S, i.e. those which may entail the consequent graph. The interpolation lemma shows that this process is valid, valid , and is also complete if the subgraph-matching algorithm is. The existence of complete subgraph-checking algorithms also shows that RDF entailment is decidable, i.e. there is a terminating algorithm which will determine for any finite set S and any graph E, whether or not S entails E.

Notice however that such Such a variable-binding process would only be appropriate when applied to the conclusion of a proposed entailment. This corresponds to using the document as a goal or a query, in contrast to asserting it, i.e. claiming it to be true. If an RDF document is asserted, then it would be invalid to bind new values to any of its blank nodes, since the resulting graph would not be entailed by the assertion, as explained in the next section. Finally, the following is a trival but important consequence of the definition of entailment: Monotonicity Lemma . Suppose S is a subgraph of S' and S entails E. Then S' entails E. <h3> <a name="Non-entailment" id="Non-entailment"> 2.1 Criteria for non-entailment </a> </h3> In contrast to names, which have a global identity which carries across all graphs, blank nodes should might not be deleted text: identified with other nodes or replaced with urirefs, in order to ensure that the resulting graph is entailed by deleted text: what one starts with. To state this condition precisely, we need to first exclude a counterexample. It is possible for a graph to contain two triples one of which is an instance of the other, for example: <code> <ex:a> <ex:b> _:xxx . </code> <code> <ex:a> <ex:b> <ex:c> . </code> assertion.

Such The interpolation lemma has an internally redundant graph is <a href="#glossEquivalent" class="termref"> equivalent </a> to one of its own instances, since replacing the blank node by <code> <ex:c> </code> would result in a single-triple graph which is immediate consequence a subgraph of the original. To rule out such cases of internal redundancy, <a id="deflean" name="deflean"> we will say that an RDF graph is lean if none of its triples is an instance of any other. </a> Then the above principle is made precise in the following two lemmas concerning criteria criterion for non-entailment:

Anonymity lemma 1. lemma. Suppose E is a lean graph and E' is a proper instance of E. Then E does not entail E'. <a name="Anonlem2" id="Anonlem2"> Anonymity lemma 2. </a> Suppose that E is a <a href="#deflean" class="termref"> lean </a> graph and that E' is like E except that two distinct blank nodes in E have been identified in E'. Then E does not entail E'. This means that there is no valid RDF inference process which can produce an RDF graph in which a single blank node occurs in triples originating from several different graphs. (Of course, such a graph can be constructed, but it will not be <a href="#glossEntail" class="termref"> entailed [Proof] by the original documents. An assertion of such a graph would reflect the addition of new information about identity.)

We emphasise Note again that these results apply this applies only to simple entailment, not to the vocabulary entailment relationships defined in rest of the document.

So far we have considered only the model theory of what might be called the logical form of the RDF graph itself, without imposing any special interpretations on any vocabulary. In the rest of the document we will extend the <a href="#glossModeltheory" class="termref"> model theory </a> to describe the semantic conditions reflecting the intended meanings Several basic properties of entailment follow directly from the <code> rdf: </code> above definitions and <code> rdfs: </code> namespaces. results but are stated here for completeness sake:

Although we will do this in stages, the same general technique Monotonicity Lemma . Suppose S is deleted text: used throughout. First we describe a special vocabulary, i.e. subgraph of S' and S entails E. Then S' entails E. [Proof]

The property of finite expressions always being derivable from a finite set of urirefs which will be given a special meaning; then we give the extra conditions on an interpretation antecedents is called compactness . Semantic theories which capture those meanings; then we restrict the support non-compact notions of deleted text: satisfiability and entailment to apply to these interpretations only. This essentially imposes an a priori restriction on the world being described that it satisfy the extra conditions. The new semantic conditions are automatically assumed to be true; an interpretation which would violate them is simply do not allowed to count as a possible <a href="#glossWorld" class="termref"> world </a>. have corresponding computable inference systems.

Since there are now several distinct notions of interpretation, entailment Compactness Lemma . If S entails E and satisfiability, we use the Qname namespace prefix conventions to identify the various distinctions, eg an rdf-interpretation E is an interpretation satisfying the rdf semantic conditions, rdf-entailment means entailment relative to such interpretations, and so on. We call this general idea a finite graph, then some finite subset S' of S entails E.

vocabulary entailment , i.e. entailment relative to a set of interpretations which satisfy extra semantic conditions on a vocabulary. 2.1 Vocabulary interpretations and vocabulary entailment is more powerful than

Simple interpretations and simple entailment, in entailment capture the sense that a given set semantics of premises entails more consequences. In general, as the vocabulary RDF graphs when no attention is increased and extra semantic conditions imposed, paid to the class particular meaning of <a href="#glossSatisfy" class="termref"> satisfying </a> interpretations is restricted, and hence the corresponding notion any of entailment becomes more powerful. For example, if S simply entails E then it also rdf-entails E, since every rdf-interpretation is also a simple interpretation; but S may rdf-entail E even though it does not simply entail it. Intuitively, a conclusion may depend on some any of the extra assumptions incorporated names in the semantic conditions imposed on the vocabulary. Another way of expressing this is that any restriction on interpretations decreases graph. To obtain the number full meaning of deleted text: possible ways that an deleted text: interpretation might be a counterexample to E's following from S. Simple entailment is the vocabulary entailment of the empty vocabulary. It is therefore the weakest form of RDF entailment, which holds for any vocabulary; graph written using a particular vocabulary, it is usually necessary to add further semantic conditions which attach stronger meanings to particular URI references and typed literals in the entailment graph. Interpretations which depends only are required to satisfy extra semantic conditions on the basic logical form a particular vocabulary will be generically referred to as vocabulary interpretations . Vocabulary entailment means entailment with respect to such vocabulary interpretations. These stronger notions of RDF graphs, without making any further assumptions about interpretation and entailment are indicated by the meaning use of any urirefs. We a namespace prefix, so that we will consider syntactic criteria for recognizing vocabulary entailment refer to rdf-entailment , rdfs-entailment and so on in what follows. In each case, the next section. vocabulary whose meaning is being restricted, and the exact conditions associated with that vocabulary, are spelled out in detail.

<a name="rdfinterp" id="rdfinterp"> 3.1. 3. Interpreting the RDF Interpretations Vocabulary

</h3> The RDF deleted text: imposes some extra semantic conditions on the following (rather small) vocabulary, which we will call rdfRV: rdfV, is a set of URI references in the


rdf:

namespace:

An rdf-interpretation of a vocabulary V is an a simple interpretation I on of (V union rdfV) crdfV) which satisfies the deleted text: following extra conditions: conditions described in the following table for all name s in (V union crdfV ), and all the triples in the subsequent table whose vocabulary is contained in (V union crdfV) . These triples are called the rdf axiomatic triples .

The fourth condition defines the built-in RDF datatype; here 'canonical form' is understood rdfs-interpretation s described in the sense of <a href="#ref-C14N"> [XML-C14N] </a>. For an <a href="http://www.w3.org/TR/rdf-concepts/#section-XMLLiteral"> exact statement section 4 of below assign further semantic conditions (range and domain conditions) to the precise properties used in the RDF vocabulary, and other semantic extensions MAY impose further conditions for attaching language tags so as to XML documents see <a href="#ref-rdf-concepts"> [RDF-CONCEPTS] </a>. further restrict their meanings, provided that such conditions MUST be compatible with the conditions described in this section.

For example, the following rdf-interpretation extends the simple interpretation in figure 1: 1 to the case where V contains rdfV . For simplicity, we ignore XML literals in this example.

IEXT: 1->{<1,2>,<2,1>}, T->{<1,P>,<T,P>} 1

=>

{<1,2>,<2,1>}, T

=>

{<1,P>,<T,P>}

IS:




ex:a



ex:a=>

deleted text: -> 1,




ex:b



ex:b=>

->1, 1,




ex:c



ex:c=>

deleted text: -> 2,




rdf:type



rdf:type=>

->T, T,




rdf:Property



rdf:Property=>

->P, P,




rdf:nil



rdf:nil=>

->1, 1,




rdf:List



rdf:List=>

->P P,


rdf:Statement=>

,
rdf:subject=>

,
rdf:predicate=>

,
rdf:object=>

,
rdf:first=>

,
rdf:rest=>

,
rdf:Seq=>

,
rdf:Bag=>

,
rdf:Alt=>

,
rdf:_1,
rdf:_2,
...
=>

This is not the smallest rdf-interpretation which extends the earlier example, since we one could have made deleted text: I( <code> rdf:Property </code> ) be 2 and IEXT(T) be {<1,2>,<T,2>}, and managed without having P in the universe. In general, a given entity in an interpretation may play several 'roles' at the same time, as long as this can be done without violating any of the required semantic conditions. The above interpretation identifies properties with lists, for example; of course, other interpretations might not make such an identification.

It is important to note that every Every rdf-interpretation is also a simple interpretation.The interpretation. The 'extra' structure does not prevent it acting in the simpler role.

3.1. RDF entailment

S rdf-entails E when every rdf-interpretation of the vocabulary deleted text: contains several other items. Some of these are omitted because they have no formal semantic meaning, or have a meaning S union E which can satisfies every member of S also satisfies E. This follows the wording of the definition of simple entailment in Section 2 , but refers only be described using to rdf-interpretation s instead of all simple interpretations. Rdf-entailment is an example of vocabulary entailment .

It is easy to see that the RDFS vocabulary. lemmas in Section 2 do not all apply to rdf-entailment: for example, the triple

is true in every rdf-interpretation , so is rdf-entailed by the empty graph, contradicting the interpolation lemma for rdf-entailment. Section 7.2 describes exact conditions for detecting RDF entailment.

3.2. Reification, containers Containers , collections Collections and rdf:value

The RDF provides vocabularies semantic conditions impose significant formal constraints on the meaning only of the central RDF vocabulary, so the notions of rdf-entailment and rdf-interpretation apply to the remainder of the vocabulary without further change. This includes vocabulary which are is intended for use in describing containers and bounded collections, and a reification vocabulary to enable an RDF graph to describe, as well as exhibit, triples. Although these vocabularies have reasonably clear informally intended conventional meanings, In this section we do not impose any further formal semantic conditions on them, so the notions of rdf-entailment and rdf-interpretation apply to them without further change. They are discussed here in order to explain both review the intuitive intended meanings intended, of this vocabulary, and deleted text: also to note the some intuitive consequences which are deleted text: not deleted text: supported by the formal model theory . Constraints are imposed on Semantic extensions MAY limit the meanings formal interpretations of these vocabularies deleted text: in semantic extensions. The RDFS assigns range and domain conditions for some of the properties used in this vocabulary.We will refer to the complete set of all rdf urirefs, consisting of the RDF vocabulary and all of the reification, container and collection vocabularies and the uriref <code> rdf:value </code> , as the RDF vocabulary, rdfV. conform to these intended meanings.

The lack omission of a these conditions from the formal semantics deleted text: for these vocabularies does not reflect any technical semantic problems, but rather is a design decision to accomodate variations in existing RDF usage and to make it easier to implement processes to check formal RDF entailment. Since no extra formal semantic conditions are imposed on them, they are not considered For example, implementations may decide to be restricted vocabularies in RDF. In RDFS, however, use special procedural techniques to implement the deleted text: entire RDF vocabulary is considered to be a restricted collection vocabulary.

3.2.1 Reification

Semantic extensions MAY limit the interpretation of these so that a triple of the form

is true in I just when I(aaa) is a token of an RDF triple in some RDF document, and the three properties, when applied to such a denoted triple, have the same values as the respective components of that triple.

This may be illustrated by considering the following two RDF graphs, the first of which consists of a single triple.


_:xxx
rdf:type
rdf:Statement
.


_:xxx
rdf:subject
<ex:a>
.


_:xxx
rdf:predicate
<ex:b>
.


_:xxx
rdf:object
<ex:c>
.

The second graph is called a reification of the triple in the first graph, and the node which is intended to refer to the first triple - the blank node in the second graph - is called, rather confusingly, a reified triple . (This can be a blank node or a uriref.) URI reference.) In the intended interpretation of the reification vocabulary, the second graph would be made true in an interpretation I by interpreting the reified triple to refer to a token of the triple in the first graph in some concrete RDF document, considering that token to be valid RDF syntax, and then using I to interpret the syntactic triple which the token instantiates, so that the subject, predicate and object of that triple are interpreted in the same way in the reification as in the triple described by the reification. This could be stated formally as follows: <x,y> is in IEXT(I(


rdf:subject

)) just when x is a token of an RDF triple of the form

and y is I(aaa); similarly for predicate and object. Notice that the value of the


rdf:subject

property is not the subject uriref URI reference itself but its interpretation, and so this condition involves a two-stage interpretation process: we have one has to interpret the reified node - the subject of the triples in the reification - to refer to another triple, then treat that triple as RDF syntax and apply the interpretation mapping again to get to the referent of its subject. This requires triple tokens to exist as first-class entities in the universe IR of an interpretation. In sum: the meaning of the reification is that a document exists containing a triple token which means whatever the first graph means. We emphasize Note that this way of understanding the reification vocabulary does not interpret reification as a form of quotation. Rather, the reification describes the relationship between a token of a triple and the resources that triple refers to. The reification can be read intuitively as saying "'this piece of RDF talks about these things" rather than "this piece of RDF has this form".

The semantic extension described here requires the reified triple that the reification describes - I(


_:xxx

) in the above example - to be a deleted text: particular deleted text: token or instance deleted text: of a triple in a (real or notional) RDF document, rather than an 'abstract' triple considered as a grammatical form. There could be several such entities which have the same subject, predicate and object properties. Although a graph is defined as a set of triples, several such tokens with the same triple structure might occur in different documents. Thus, it would be meaningful to claim that the blank node in the second graph above does not refer to the triple in the first graph, but to some other triple with the same structure. This particular interpretation of reification was chosen on the basis of use cases where properties such as dates of composition or provenance information have been applied to the reified triple, which are meaningful only when thought of as referring to a particular instance or token of a triple.

Although RDF applications may use reification to refer to triple tokens in RDF documents, the connection between the document and its reification must be maintained by some means external to RDF. the RDF graph syntax. (In the RDF/XML syntax provides no means to 'connect' an RDF described in RDF/XML Syntax Specification (Revised) [ RDF-SYNTAX ], the rdf:ID attribute can be used in the description of a triple to its reification. create a reification of that triple in which the reified triple is a URI constructed from the baseURI of the XML document and the value of rdf:ID as a fragment.) Since an assertion of a reification of a triple does not implicitly assert the triple itself, this means that there are no entailment relationships which hold between a triple and a reification of it. Thus the reification vocabulary has no effective semantic constraints on it, other than those that apply to an RDF interpretation. The chief facts that are worthy of note about RDF reification, in fact, are examples of non-entailments. rdf-interpretation .

A reification of a triple does not entail the triple, and is not entailed by it. (The deleted text: reason for first is clear, since the reification only asserts says that the triple token exists, exists and what it is about, not that it is true. The second non-entailment is a consequence of the fact that asserting a triple does not automatically assert that any triple tokens exist in the universe being described by the triple. For example, the triple might be part of an ontology describing animals, which could be satisfied by an interpretation in which the universe contained only animals.) animals, and in which a reification of it was therefore false.)

Since the relation between triples and reifications of triples in any RDF graph or graphs need not be one-to-one, asserting a property about some entity described by a reification need not entail that the same property holds of another such entity, even if it has the same components. For example,


_:xxx
rdf:type
rdf:Statement
.


_:xxx
rdf:subject
<ex:subject>
.


_:xxx
rdf:predicate
<ex:predicate>
.


_:xxx
rdf:object
<ex:object>
.


_:yyy
rdf:type
rdf:Statement
.


_:yyy
rdf:subject
<ex:subject>
.


_:yyy
rdf:predicate
<ex:predicate>
.


_:yyy
rdf:object
<ex:object>
.


_:xxx
<ex:property>
<ex:foo>
.

3.2.2 RDF containers

RDF provides vocabularies for describing three classes of containers . containers. Containers have a type, and their members can be listed enumerated by using a fixed set of container membership properties . These properties are indexed by integers to provide a way to distinguish the members from each other, but these indices should not necessarily be thought of as defining an ordering of the container itself. itself; some containers are considered to be unordered.

The rdfs RDFS vocabulary, described below, adds a generic membership property which holds regardless of position, and classes containing all the containers and all the membership properties.

One should understand this RDF vocabulary as describing containers, rather than as a vocabulary for constructing them, as would typically be supplied by a programming language. On this view, the actual containers are entities in the semantic universe, and RDF graphs which use the vocabulary simply provide very basic information about these entities, enabling an RDF graph to characterize the container type and give partial information about the members of a container. Since the RDF container vocabulary is so limited, many 'natural' assumptions concerning RDF containers are not formally sanctioned by the RDF model theory . This should not be taken as meaning that these assumptions are false, but only that RDF does not formally entail that they must be true.

There are no special semantic conditions on the container vocabulary: the only 'structure' which RDF presumes its containers to have is what can be inferred from the use of this vocabulary and the general RDF semantic conditions on conditions. In general, this amounts to knowing the rest type of a container, and having a partial enumeration of the RDF vocabulary. items in the container. The intended mode of use is that things of type


rdf:Bag

are considered to be unordered but to allow duplicates; things of type


rdf:Seq

are considered to be ordered, and things of type


rdf:Alt

are considered to represent a collection of alternatives, possibly with a preference ordering. The ordering of items in an ordered container is intended to be indicated by the numerical ordering of the container membership properties. properties, which are assumed to be single-valued . However, these informal interpretations are not reflected in any formal RDF entailments.

RDF does not support any entailments which could arise from re-ordering enumerating the elements of an rdf:Bag.


rdf:Bag

in a different order . For example,

Notice that if this conclusion were valid, valid , then the result of conjoining it to the original graph would also be a valid entailment, which would assert that both elements were in both positions. (This This is a consequence of the fact that RDF is a purely assertional language.) language.

There is no assumption that a property of a container applies to any of the elements of the container, or deleted text: that if a property applies to a container then the property applies to any of the members of the container, or vice versa.

There is no formal requirement that the three container classes are disjoint, so that for example something can be asserted to be both an


rdf:Bag

and an


rdf:Seq

. There is no assumption that containers are gap-free, so that for example

There is no way in RDF to 'close' a container, i.e. to assert that it contains only a fixed number of members. This is a reflection of the fact that it is always consistent to add a triple to a graph asserting a membership property of any container. And finally, there is no built-in assumption that an RDF container has only finitely many members.

3.2.3 RDF collections

RDF provides a vocabulary for describing collections, ie.'list structures' i.e.'list structures', in terms of head-tail links. Collections differ from containers in allowing branching structure and in having an explicit terminator, allowing applications to determine the exact set of items in the collection.

As with containers, no special semantic conditions are imposed on this vocabulary other than the type of nil


rdf:nil

being List.


rdf:List

. It is intended for use typically in a context where a container is described using blank nodes to connect a 'well-formed' sequence of items, each described by three two triples of the form deleted text:




_:c1
rdf:type
rdf:List
.










_:c1
rdf:first
aaa
.


_:c1
rdf:rest
_:c2

where the final item is indicated by the use of


rdf:nil

as the value of the property


rdf:rest

. In a familiar convention,


rdf:nil

can be thought of as the empty collection. Clearly, any Any such graph amounts to an assertion that the collection, and all its sub-collections, exist, collection exists, and since the members of the collection can be determined by inspection, this is often sufficient to enable applications to determine what is meant. Note however that the semantics does not require any collections to exist other than those mentioned explicitly in a graph (and the empty collection). For example, the existence of a collection containing two items does not automatically guarantee that the similar collection with the items permuted also exists: deleted text:




_:c1
rdf:type
rdf:List
.










_:c1
rdf:first
<ex:aaa>
.


_:c1
rdf:rest
_:c2
.






_:c2


rdf:type
rdf:List
.
<br />



rdf:first



<ex:bbb>
.


_:c2
rdf:rest
rdf:nil
.
deleted text: 

<br />


_:c3
deleted text: 

rdf:type
rdf:List
.
<br />
_:c3


rdf:first
<ex:bbb>
.


_:c3
rdf:rest
_:c4
.






_:c4


rdf:type
rdf:List
.
<br />



rdf:first



<ex:aaa>
.


_:c4
rdf:rest
rdf:nil
.
deleted text: 

<br />

Also, RDF imposes no ' wellformedness well-formedness ' conditions on the use of this vocabulary, so that it is possible to write RDF graphs which assert the existence of highly peculiar objects such as lists with forked or non-list tails, or multiple heads:


_:666
deleted text: 

rdf:type
rdf:List
.
<br />
_:666


rdf:first
<ex:aaa>
.


_:666
rdf:first
<ex:bbb>
.


_:666
rdf:rest
<ex:ccc>
.


_:666
rdf:rest
deleted text: 

_:777
.
<br />
_:666
rdf:rest


rdf:nil
.
deleted text: 

<br />

As this example shows, it It is also possible to write a set of triples which underspecify a collection by failing to specify its


rdf:rest

property value.

Semantic extensions MAY place extra syntactic well-formedness restrictions on the use of this vocabulary in order to rule out such graphs, and graphs. They MAY exclude interpretations of the collection vocabulary which violate the convention that the subject of a 'linked' collection of three-triple two-triple items of the form described above, ending with an item ending with


rdf:nil

, denotes a totally ordered sequence whose members are the denotations of the


rdf:first

values of the items, in the order got by tracing the


rdf:rest

properties from the subject to


rdf:nil

. This permits sequences which contain other sequences.

Note that the RDFS semantic conditions, described below, require that any subject of the


rdf:first

property, and any subject or object of the


rdf:rest

property, be of


rdf:type
rdf:List

3.2.4 rdf:value

The intended use for


rdf:value

is explained intuitively in the RDF Primer document [ [RDF-PRIMER] </a>. RDF-PRIMER ]. It is typically used to identify a 'primary' or 'main' value of a property which has several values, or has as its value a complex entity with several facets or properties of its own.

Since the range of possible uses for


rdf:value

is so wide, it is impossible difficult to give a precise deleted text: model-theoretic statement which covers all the intended meanings or use cases. Users are cautioned, therefore, that the use meaning of


rdf:value

deleted text: is somewhat risky, and that it should be treated as a 'blank' piece of RDF syntax whose meaning in any particular case should be defined by the user, and may vary from application to application. application . In practice, the intended meaning is often clear from the context, but may be lost when graphs are merged or when conclusions are inferred.

3.3 4. Interpreting the RDFS interpretations Vocabulary </h3>

RDF Schema [ RDFSchema RDF-VOCABULARY ] extends RDF to include a larger vocabulary rdfsV with more complex semantic constraints:

(




rdfs:comment,



rdfs:comment




rdfs:seeAlso


rdfs:isDefinedBy

and


rdfs:label

are included here because some constraints which apply to their use can be stated using




rdfs:domain,



rdfs:domain




rdfs:range

and


rdfs:subPropertyOf

. Other than this, the formal semantics does not assign them any particular meanings.)

Although not strictly necessary, it is convenient to state the RDFS semantics in terms of a new semantic construct, a ' class ', i.e. a resource which represents a set of things in the universe which all have that class as the value of their


rdf:type

property. Classes are defined to be things of type


rdfs:Class


</code>.
We

, and the set of all classes in an interpretation will assume that there is be called IC . The semantic conditions are stated in terms of a mapping ICEXT (for the Class Extension C lass Ext ension in I) from classes IC to deleted text: their extensions; the first semantic condition set of subsets of IR. The meanings of ICEXT and IC in a rdf-interpretation of the table below amounts to RDFS vocabulary are completely defined by the following definition of this mapping first two conditions in deleted text: terms of the relational extension table of <code> rdf:type </code>: ICEXT(x) = {y | <y,x> is in IEXT(I(


rdf:type

)) }

RDFS semantic condiions, below. Notice that a class may have an empty class extension; that (as noted earlier) two different class entities could have the same class extension; and that deleted text: given the above definition, the class extension of <code> rdfs:Class </code> contains the class <code> rdfs:Class </code>. <a id="rdfsinterpdef" name="rdfsinterpdef"> </a> An rdfs-interpretation of V is an rdf-interpretation I of (V union rdfV crdfV union rdfsV) which satisfies the following semantic conditions and all the triples in the subsequent table, which we will call called the RDFS axiomatic triples . The first condition can be understood as a definition of ICEXT and hence of IC, the set of classes. Since I is an rdf-interpretation, this means that IP = ICEXT(I(


rdf:Property

)) , which contain only name s from (V union crdfV union rdfsV ).

RDFS semantic conditions.

deleted text: </table>

	x is in ICEXT(y) iff if and only if <x,y> is in IEXT(I( `rdf:type` )) IC = ICEXT(I( `rdfs:Class` )) IR = ICEXT(I( `rdfs:Resource` )) LV = ICEXT(I( `rdfs:Literal` )) deleted text: is a subset of LV </p>
	If <x,y> is in IEXT(I( `rdfs:range rdfs:domain` )) and <u,v> is in IEXT(x) then v u is in ICEXT(y)
	If <x,y> is in IEXT(I( `rdfs:domain rdfs:range` )) and <u,v> is in IEXT(x) then u v is in ICEXT(y)
	<x,y> is in IEXT(I( `rdfs:subClassOf rdfs:subPropertyOf` )) deleted text: if and only if x and y are in IC and ICEXT(x) is a subset of ICEXT(y) transitive and reflexive on IP
	If <x,y> is in IEXT(I( `rdfs:subPropertyOf` )) if and only if then x and y are in IP and IEXT(x) is a subset of IEXT(y)
	If x is in ICEXT(I( `rdfs:ContainerMembershipProperty` )) IC then <x,I( `rdfs:member` )> <x, IR> is in IEXT(I( `rdfs:subPropertyOf rdfs:subClassOf` ))
ICEXT(I(	If <x,y> is in IEXT(I( `rdf:XMLLiteral rdfs:subClassOf` )) then x and y are in IC and ICEXT(x) is the set a subset of all canonical XML documents. ICEXT(y)
IC contains:	I( `rdfs:Resource` ), I( `rdf:Property` ), I( `rdfs:Class` ), I( `rdfs:Literal` ), I( `rdfs:Datatype` ), I( `rdf:Seq` ), I( `rdf:Bag` ), I( `rdf:Alt` ), I( `rdfs:Container` ), I( `rdf:List` ), I( `rdfs:ContainerMembershipProperty` ), I( IEXT(I( `rdf:Statement rdfs:subClassOf` ) )) is transitive and reflexive on IC
IP contains:	I( `rdf:type` ), I( `rdfs:domain` ), I( `rdfs:range` ), I( `rdfs:subPropertyOf` ), I( `rdfs:subClassOf` ), I( `rdfs:comment` ), I( `rdfs:label` ), I( `rdf:subject` ), I( `rdf:predicate` ), I( If x is in ICEXT(I( `rdf:object rdfs:ContainerMembershipProperty` ), )) then: < x, I( `rdfs:member` ), I( `rdf:_1` ), I( `rdf:_2` ), `...` , I( `rdf:first` ), I( `rdf:rest` ), I( `rdfs:seeAlso` ), I( )> is in IEXT(I( `rdfs:isDefinedBy rdfs:subPropertyOf` ), I( ))
If x is in ICEXT(I( `rdfs:comment rdfs:Datatype` ), )) and y is in ICEXT(x) then <y, I( `rdfs:label rdfs:Literal` ), I( )> is in IEXT(I( `rdf:value rdf:type` ) ))

RDFS axiomatic triples.

deleted text: </table> deleted text: The truth Since I is an rdf-interpretation , the first condition implies that IP = ICEXT(I(


rdf:Property

)).

These axioms and conditions have some redundancy: for example, all but one of the RDF axiomatic triples could can be stated as conditions on IEXT and ICEXT, but it is convenient to use derived from the truth-of-triples formulation. Similarly, RDFS axiomatic triples and the semantic conditions on IC ICEXT, rdfs:domain and IP rdfs:range. Other triples which must be true in all rdfs-interpretation s include the first table could be stated as axiomatic following:

Some triples with property which are RDFS-valid.




rdfs:subPropertyOf


rdf:type


rdfs:domain


rdf:Property


rdfs:Resource


.
deleted text:

deleted text:


rdfs:subClassOf


rdfs:domain


rdfs:Class


rdfs:domain
rdf:Property


.
deleted text:


rdfs:domain


rdfs:range


rdfs:domain
rdf:Property
.
deleted text:


rdfs:range


rdfs:subPropertyOf


rdfs:domain
rdf:Property
.

rdfs:subClassOf rdfs:domain rdfs:Class .
deleted text:




rdf:subject
rdfs:domain
rdf:Statement
.
<span class="diff-old-a">deleted text: </span>

deleted text:




rdf:predicate
rdfs:domain
rdf:Statement
.
<span class="diff-old-a">deleted text: </span>

deleted text:




rdf:object
rdfs:domain
rdf:Statement
.
<span class="diff-old-a">deleted text: </span>




rdfs:member
rdfs:domain
rdfs:Resource
.




rdf:first
rdfs:domain
rdf:List
.
deleted text:

deleted text:




rdf:rest
rdfs:domain
rdf:List
.
<br />


rdfs:seeAlso
rdfs:domain
rdfs:Resource
.


rdfs:subPropertyOf
rdfs:range
rdf:Property


rdfs:isDefinedBy
rdfs:domain
rdfs:Resource


.
deleted text:


rdfs:subClassOf


rdfs:comment
rdfs:domain
rdfs:Resource
.


rdfs:label
rdfs:domain
rdfs:Resource
.


rdf:value
rdfs:domain
rdfs:Resource
.




rdf:type


rdfs:range
rdfs:Class
.
deleted text:

deleted text:




rdfs:domain
rdfs:range
rdfs:Class
.
<span class="diff-old-a">deleted text: </span>

deleted text:




rdfs:range
rdfs:range
rdfs:Class
.
<span class="diff-old-a">deleted text: </span>


rdf:type


rdfs:subPropertyOf


rdfs:range


rdfs:Class


rdf:Property


.

rdfs:subClassOf rdfs:range rdfs:Class .
rdf:subject rdfs:range rdfs:Resource .
rdf:predicate rdfs:range rdfs:Resource .
rdf:object rdfs:range rdfs:Resource .
rdfs:member rdfs:range rdfs:Resource .
rdf:first rdfs:range rdfs:Resource .
rdf:rest rdfs:range rdf:List .
rdfs:seeAlso rdfs:range rdfs:Resource .
rdfs:isDefinedBy rdfs:range rdfs:Resource .
deleted text:




rdfs:comment
rdfs:range
rdfs:Literal
.
<span class="diff-old-a">deleted text: </span>

deleted text:




rdfs:label
rdfs:range
rdfs:Literal
.
<span class="diff-old-a">deleted text: </span>


rdf:rest


rdf:value


rdfs:range


rdf:List


rdfs:Resource


.
deleted text:

deleted text:




rdf:Alt
rdfs:subClassOf
rdfs:Container
.
<span class="diff-old-a">deleted text: </span>

deleted text:




rdf:Bag
rdfs:subClassOf
rdfs:Container
.
<span class="diff-old-a">deleted text: </span>

deleted text:




rdf:Seq
rdfs:subClassOf
rdfs:Container
.
<span class="diff-old-a">deleted text: </span>

deleted text:




rdfs:ContainerMembershipProperty
rdfs:subClassOf


rdfs:Property


rdf:Property


.
deleted text:

deleted text:




rdfs:isDefinedBy
rdfs:subPropertyOf
rdfs:seeAlso
.
<br />
<br />
<span class="diff-old-a">deleted text: </span>




rdf:XMLLiteral
rdf:type
rdfs:Datatype
.
<span class="diff-old-a">deleted text: </span>




rdf:XMLLiteral
rdfs:subClassOf
rdfs:Literal
.




rdfs:Datatype
rdfs:subClassOf
rdfs:Class
.
deleted text:

deleted text:





<br />
<span class="diff-old-a">deleted text: </span>




rdf:_1
rdf:type
rdfs:ContainerMembershipProperty
.
<span class="diff-old-a">deleted text: </span>





rdf:_1
rdfs:domain
rdfs:Resource
.


rdf:_1
rdfs:range
rdfs:Resource
.





rdf:_2
rdf:type
rdfs:ContainerMembershipProperty
.

rdf:_2 rdfs:domain rdfs:Resource .
rdf:_2 rdfs:range rdfs:Resource .
...




rdfs:Resource


rdf:type
deleted text:

and objects




rdfs:Class


.


rdfs:Class
rdf:type
rdfs:Class
.


rdfs:Literal
rdf:type
rdfs:Class
.


rdf:XMLLiteral
rdf:type
rdfs:Class
.


rdfs:Datatype
rdf:type
rdfs:Class
.


rdf:Seq
rdf:type
rdfs:Class
.


rdf:Bag
rdf:type
rdfs:Class
.


rdf:Alt
rdf:type
rdfs:Class
.


rdfs:Container
rdf:type
rdfs:Class
.


rdf:List
rdf:type
rdfs:Class
.


rdfs:ContainerMembershipProperty
rdf:type
rdfs:Class
.


rdf:Property
rdf:type
rdfs:Class
.


rdf:Statement
rdf:type
rdfs:Class
.




rdfs:domain
rdf:type
rdf:Property
.


rdfs:range
rdf:type
rdf:Property
.


rdfs:subPropertyOf
rdf:type
rdf:Property
.


rdfs:subClassOf
rdf:type
rdf:Property
.


rdfs:member
rdf:type
rdf:Property
.


rdfs:seeAlso
rdf:type
rdf:Property
.


rdfs:isDefinedBy
rdf:type
rdf:Property
.


rdfs:comment
rdf:type
rdf:Property
.


rdfs:label
rdf:type
rdf:Property
.

and


rdfs:Property

respectively.

Since ICEXT(I( rdfs:Resource )) is

Note that datatype s are allowed to have class extensions, i.e. are considered to be classes, in RDFS. As illustrated by the semantic condition on the deleted text: universe, everything has rdfs:Resource as an rdf:type value, and every class is a subclass extension of rdfs:Resource. Such assertions would be redundant, therefore.

Similarly, some domain and range assertions are omitted from rdf:XMLLiteral , the above table; in those cases, members of a datatype class are the domain or range values of the property may be taken to be datatype . This is explained in more detail in section 5 below. The class rdfs:Resource, i.e. rdfs:Literal contains all literal values; however, typed literals whose strings do not conform to the universe; such range and domain assertions lexical requirements of their datatype are essentially vacuous. required to have meanings not in this class. The semantic conditions on rdf-interpretation s imply that ICEXT(I( rdf:XMLLiteral )) contains all XML values of well-typed XML literals.

The semantics given here for conditions on rdfs:range rdf:XMLLiteral and rdfs:domain rdfs:range do not entail taken together make it possible to write a contradictory statement in RDFS, by asserting that deleted text: superclasses of domains or ranges of a property value must deleted text: also be domains in the class rdf:XMLLiteral but applying this property with a value which is an ill-formed XML literal, and ranges of therefore required to not be in that property. class: for example

<ex:a> <ex:p> "<notLegalXML"^^rdf:XMLLiteral . <ex:p> rdfs:range rdf:XMLLiteral .

cannot be true in any rdfs-interpretation; it is rdfs- inconsistent .

4.1 Extensional Semantic Conditions (Informative)

The semantics given above is deliberately chosen to be the weakest 'reasonable' interpretation of the RDFS vocabulary. Semantic extensions MAY strengthen the domain range, domain, subclass and range subproperty semantic conditions to the following: following ' extensional ' versions:

Extensional alternatives for some RDFS semantic conditions.

	<x,y> is in IEXT(I( `rdfs:subClassOf` )) if and only if x and y are in IC and ICEXT(x) is a subset of ICEXT(y)
<x,y> is in IEXT(I( `rdfs:subPropertyOf` )) if and only if x and y are in IP and IEXT(x) is a subset of IEXT(y)
<x,y> is in IEXT(I( `rdfs:range` )) if and only if (if <u,v> is in IEXT(x) then v is in ICEXT(y))
	<x,y> is in IEXT(I( `rdfs:domain` )) if and only if (if <u,v> is in IEXT(x) then u is in ICEXT(y))

This stronger condition will not effect any class-membership entailments on the elements of which would guarantee that the domains subproperty and ranges of the property. The semantics given here was chosen because it is sufficient for all normal uses of these terms subclass properties were transitive and allows some subtleties in class reasoning. reflexive, but would also have further consequences.

Note that datatypes

These stronger conditions would be trivially satisfied when properties are considered identified with property extensions, classes with class extensions, and rdfs:SubClassOf understood to mean subset, and hence would be classes. As illustrated satisfied by an extensional semantics for RDFS. In some ways the semantic condition on extensional versions provide a simpler semantics, but they require more complex inference rules. The 'intensional' semantics described in the class extension main text provides for most common uses of rdf:XMLLiteral, the members subclass and subproperty assertions, and allows for simpler implementations of a datatype class are the values complete set of the datatype. This is explained in more detail RDFS entailment rules, described in section 3.4 below.

We do not attempt to give a pictorial diagram of an rdfs-interpretation. 7.3 .

3.3.1 4.2 A note Note on rdfs:Literal

Although the semantic conditions on rdfs-interpretations rdfs-interpretation s include the intuitively sensible condition that ICEXT(I( rdfs:Literal )) must be a subset of LV , the set LV, there is no way to impose this condition by any RDF assertion or syntactic closure inference rule. This limitation is due to the fact that RDF does not allow literals to occur in the subject position of a triple, so there are severe restrictions on what can be said about literals in RDF. Similarly, while properties may be asserted of the class rdfs:Literal, none of these can be validly transferred to literals themselves.

For example, a triple of the form

<ex:a> rdf:type rdfs:Literal .

is consistent even though ' ex:a ' is a uriref URI reference rather than a literal. What it says is that I( ex:a ) is a literal value, ie that the uriref URI reference ' ex:a ' denotes a literal value. It does not specify exactly which literal value it denotes.

Note that the interpolation lemma guarantees The semantic conditions guarantee that any triple containing a simple literal object entails a similar triple with a bnode blank node as object:

<ex:a> <ex:b> "10" .

entails

<ex:a> <ex:b> _:xxx .

This means that the literal denotes 'something', an entity, which could therefore also be named, at least in principle, by a uriref. URI reference.

4.3 RDFS Entailment

S rdfs-entails E when every rdfs-interpretation of the vocabulary of S union E which satisfies every member of S also satisfies E. This follows the wording of the definition of simple entailment in Section 2 , but refers only to rdfs-interpretation s instead of all simple interpretations. Rdfs-entailment is an example of vocabulary entailment .

Since every rdfs-interpretation is an rdf-interpretation , if S rdfs-entails E then it rdf-entails E; but rdfs-entailment is stronger than rdf-entailment. Even the empty graph has a large number of rdfs-entailments which are not rdf-entailments, for example all triples of the form

xxx rdf:type rdfs:Resource .

are true in all rdfs-interpretation s of any vocabulary containing xxx.

An rdfs-inconsistent graph rdfs-entails any graph, by the definition of entailment; such 'trivial entailments' by an inconsistent set are not usually considered useful inferences to draw in practice, however.

3.4 5. Datatyped interpretations

Interpretations

RDF provides for the use of externally defined datatype s identified by a particular URI reference. In the interests of generality, RDF imposes minimal conditions on a datatype. It also includes a single built-in datatype rdf:XMLLiteral.

This semantics for datatypes is minimal. It makes no provision for associating a datatype with a property so that it applies to all values of the property, and does not provide any way of explicitly asserting that a blank node denotes a particular datatype value. Semantic extensions and future versions of RDF may impose more elaborate datatyping conditions. Semantic extensions may also refer to other kinds of information about a datatype, such as orderings of the value space.

A datatype is an entity characterized by a set of character strings called lexical forms and a mapping from that set to a set of values .deleted text: (The built-in datatype rdf:XMLLiteral, exceptionally , allows pairs in its lexical space.) Exactly how these sets and mapping are defined is a matter external to RDF. Since

Formally, a datatype d is defined by three items:

1. a non-empty set of character strings called the lexical space of d;

2. a non-empty set called the value space of possible datatypes d;

3. a mapping from the lexical space of d to the value space of d, called the lexical-to-value mapping of d.

The lexical-to-value mapping of a datatype d is open-ended, written as L2V(d).

In stating the semantics we deleted text: will assume that deleted text: datatype interpretations are defined relative relativized to a particular set of datatypes, and refer to D-interpretations where D datatypes each of which is identified by a URI reference.

Formally, let D be a set of datatypes, which we will call recognized datatypes. Urirefs which denote recognized datatypes are required to have the same denotation in all D-interpretations, so recognizing pairs consisting of a URI reference and a datatype amounts to fixing such that no URI reference appears twice in the meaning set, so that D can be regarded as a function from a set of URI references to a deleted text: uriref.

The set of recognized datatypes always includes datatypes: call this a datatype map . (The particular URI references must be mentioned explicitly in order to ensure that interpretations conform to any naming conventions imposed by the external authority responsible for defining the datatypes.) Every datatype map is understood to contain < rdf:XMLLiteral and may include , x> where x is the deleted text: XML Schema, part 2 built-in datatypes XML Literal datatype whose lexical and value spaces and lexical-to-value mapping are defined in [XML-SCHEMA2] , which we will refer to as XSD the RDF Concepts and use Abstract Syntax document [ RDF-CONCEPTS ].

The datatype map which also contains the Qname prefix xsd:. In any XSD-interpretation, any uriref set of all pairs of the form < http://www.w3.org/2001/XMLSchema# sss will be understood to denote the , sss >, where sss is a built-in datatype named sss in XML Schema Part 2: Datatypes [ [XML-SCHEMA2] XML-SCHEMA2

We will describe the semantic conditions in terms of a mapping L2V from datatypes to their lexical-to-value mappings; the valid lexical forms of a datatype d constitute the domain of L2V(d), ] and listed in the range of L2V(d) following table , is the set of elements of the referred to here as XSD.

XSD datatypes


xsd:string


xsd:boolean


xsd:decimal


xsd:float


xsd:double


xsd:dateTime


xsd:time


xsd:date


xsd:gYearMonth


xsd:gYear


xsd:gMonthDay


xsd:gDay


xsd:gMonth


xsd:hexBinary


xsd:base64Binary


xsd:anyURI


xsd:normalizedString


xsd:token


xsd:language


xsd:NMTOKEN


xsd:Name


xsd:NCName


xsd:integer


xsd:nonPositiveInteger


xsd:negativeInteger


xsd:long


xsd:int


xsd:short


xsd:byte


xsd:nonNegativeInteger


xsd:unsignedLong


xsd:unsignedInt


xsd:unsignedShort


xsd:unsignedByte


xsd:positiveInteger

The other built-in XML Schema datatypes are unsuitable for various reasons, and SHOULD NOT be used: xsd:duration does not have a well-defined value space (this may be corrected in later revisions of d. Recall that XML Schema datatypes, in which case the set LV is required to include all members of all revised datatype value spaces, so that the range of L2V(d) must would be a subset of LV. suitable for use in RDF datatyping); xsd:QName and xsd:ENTITY require an enclosing XML document context; xsd:ID and xsd:IDREF are for cross references within an XML document; xsd:NOTATION is not intended for direct use; xsd:IDREFS , xsd:ENTITIES and xsd:NMTOKENS are sequence-valued datatypes which do not fit the RDF datatype model.

A If D is a datatype map , a D-interpretation of a graph G is an any rdfs-interpretation I of V, where V contains the vocabulary of G, which satisfies the following extra conditions on all datatypes other than the built-in datatype: for every pair <aaa, x> in D:

General semantic conditions for datatypes.

deleted text: </table> The first condition says ensures that membership in the class


rdfs:Datatype

means the same as being a recognized datatype. Thus, the inclusion of a triple of I interprets the form

<ex:somedatatype> rdf:type rdfs:Datatype .

in an RDF graph can be understood as a claim that ex:somedatatype identifies a recognized datatype. The semantic conditions on rdfs-interpretations have URI reference according to the consequence datatype map provided. Note that this does not prevent other URI references from also denoting the built-in datatype rdf:XMLLiteral is a recognized datatype in all RDFS interpretations, and therefore in all D-interpretations for any D. .

The second condition says ensures that the deleted text: meaning of any typed literal which uses a recognized datatype is URI reference, when used as a class name, refers to the value space of the literal character string under that datatype, datatype , and that all elements of a value space must be literal values.

The third condition ensures that typed literals respect the language tag, if present, is ignored. datatype lexical-to-value mapping. For example, if I is an XSD-interpretation then I("15"^^ xsd:decimal ) must be the number fifteen. Notice that this applies only to datatypes in D; typed literals whose type is not a recognized datatype are treated as before, i.e. as denoting some unknown thing. This means that their meanings can be further restricted by adding a suitable extra datatype to the set of recognized datatypes.

The deleted text: third condition also requires that an 'ill-formed' typed ill-typed literal, deleted text: i.e. one where the literal string is not in the lexical space of the datatype, datatype , not denote any literal value. Intuitively, such a name does not denote any value, but in order to avoid the semantic complexities which arise from empty names, we require the semantics requires such a typed literal to denote an 'arbitrary' non-literal value. Thus for example, if D contains the XML schema datatypes, I is an XSD-interpretation, then all that can be concluded about I("arthur"^^ xsd:decimal ) is that it is deleted text: not in LV, i.e. not in ICEXT(I( rdfs:Literal )). Any graph in which a typed An ill-typed literal denotes a non-literal value is a datatype violation .

The semantic conditions for the built-in datatype rdf:XMLLiteral have been described does not in previous sections; itself constitute an inconsistency, but deleted text: in a datatyped interpretation, in addition, a graph which contains a entails that an ill-typed literal with a non-well-formed XML string has rdf:type rdfs:Literal, or that an illegal language tag, and which is typed with ill-typed XML literal has rdf:type rdf:XMLLiteral is always considered a datatype violation. These semantic conditions are exactly similar , would be inconsistent.

Note that this third condition applies only to datatype s in the above if one defines the lexical space range of rdf:XMLLiteral as D. Typed literals whose type is not in the set of all XML documents and all pairs datatype map of XML documents and language tags, and L2V(I( rdf:XMLLiteral )) the interpretation are treated as XML canonicalization. The possible inclusion of language tags makes this a special case, however: in all other cases, RDF ignores any language tags which occur in typed literals.

before, i.e. as denoting some unknown thing. The deleted text: final condition indicates does not require that deleted text: RDF treats datatypes as classes, i.e. they are assumed to have a class extension, which is required to be the set of items URI reference in the value space of typed literal be the datatype. All same as the members associated URI reference of all such the datatype classes are required ; this allows semantic extensions which can express identity conditions on URI references to be literal values. ICEXT(I( draw appropriate conclusions.

The fourth condition ensures that the class rdf:XMLLiteral rdfs:Datatype )) is contains the set of all well-formed canonical XML documents datatype s used in any satisfying D-interpretation I.

RDF does . Notice that this is a necessary, but not itself impose any identity conditions on elements in value spaces, nor assume any subclass relationships between datatype value classes. Information about such relationships should be obtained from the specifications of a sufficient, condition; it allows the datatypes themselves. class I( rdfs:Datatype ) to contain other datatype s.

The treatment of unknown types provides semantic conditions for rdf-interpretation s impose the correct interpretation on literals typed by 'rdf:XMLLiteral'. However, a trivial proof of D-interpretation recognizes the following lemma: datatype to exist as an entity, rather than simply being a semantic condition imposed on the RDF typed literal syntax. Semantic extensions which can express identity conditions on resources could therefore draw stronger conclusions from D-interpretation s than from rdfs-interpretation s.

Datatype monotonicity lemma. If the datatype s in the datatype map D is a subset of D' and S D-entails E, then S D'-entails E.

It impose disjointness conditions on their value spaces, it is possible for an RDF graph to have no D-interpretation which satisfies it. For example, XML Schema requires that defines the value spaces of xsd:string and xsd:decimal to be disjoint, so it is impossible to construct a XSD-interpretation satisfying the graph

<ex:a> <ex:b> "25"^^xsd:decimal . <ex:b> rdfs:range xsd:string .

This situation could be characterized by saying that the graph is XSD-inconsistent, or more generally as a datatype clash . Note that it is possible to construct a satisfying rdfs-interpretation for this graph, but any such interpretation, when extended to an XSD-interpretation, it would violate the XSD conditions, since the class extensions of I( xsd:decimal ) and I( xsd:string ) would have a nonempty intersection.

Datatype clashes can arise in several other ways. For example, any assertion that something is in both of two disjoint dataype classes:

_:x rdf:type xsd:string . _:x rdf:type xsd:decimal .

or that a property with an 'impossible' range has a value:

<ex:p> rdfs:range xsd:string . <ex:p> rdfs:range xsd:decimal . _:x <ex:p> _:y .

would constitute a datatype clash. A datatype clash may also arise from the use of a particular lexical form, for example:

<ex:a> <ex:p> "2.5"^^xsd:decimal . <ex:p> rdfs:range xsd:integer .

or by the use of an ill-typed lexical form:

<ex:a> <ex:p> "abc"^^xsd:integer . <ex:p> rdfs:range xsd:integer .

Datatype clashes are the only inconsistencies recognized by this model theory . The definition of entailment means ; note however that datatype clashes involving XML literals can arise in RDFS.

If D is a subset of D', then restricting interpretations of a deleted text: D-inconsistent graph D-entails any RDF graph; however, it to D'-interpretations amounts to a semantic extension compared to the same restriction with respect to D. In effect, the extension of the datatype map makes implicit assertions about typed literals, by requiring them to denote entities in the value space of a datatype . The extra semantic constraints associated with the larger datatype map will usually not be appropriate force interpretations to consider such 'trivial' entailments as useful consequences, since make more triples true, but they are not valid rdf- or rdfs- entailments. may also reveal datatype clashes and violations, so that a D-consistent graph could be D'-inconsistent.

This semantics

Say that an RDF graph recognizes a datatype URI reference aaa when the graph rdfs-entails a datatyping triple of the form

aaa rdf:type rdfs:Datatype .

The semantic conditions for datatypes rdfs-interpretation s require the built-in datatype URI reference 'rdf:XMLLiteral' to be recognized.

If every recognized URI reference in a graph is minimal. It makes no provision for associating the name of a known datatype with , then there is a property so natural datatype map DG which pairs each recognized URI reference to that it applies known datatype (and ' rdf:XMLLiteral ' to all values rdf:XMLLiteral ). Any rdfs-interpretation I of that graph then has a corresponding 'natural' DG-interpretation which is like I except that I(aaa) is the property, for example, appropriate datatype and does not provide any way the class extension of explicitly asserting rdfs:Datatype is modified appropriately. Applications MAY require that RDF graphs be interpreted by D-interpretation s where D contains a blank node denotes a particular value under a natural datatype mapping. We expect that semantic extensions and future versions map of RDF will impose more elaborate datatyping conditions. Semantic extensions may also refer the graph. This amounts to other kinds treating datatyping triples as 'declarations' of datatype s by the graph, and making the fourth semantic condition into an 'iff' condition. Note however that a datatyping triple does not in itself provide the information about necessary to check that a datatype, such graph satisfies the other datatype semantic conditions, and it does not formally rule out other interpretations, so that adopting this requirement as orderings of a formal entailment principle would violate the value space. general monotonicity lemma .

4. Vocabulary entailment and closure rules

We will say that S rdf-entails E (S rdfs-entails E, 5.1 D-entailment

S D-entails E) E when every rdf-interpretation (every rdfs-interpretation, every interpretation datatyped with respect to D) D-interpretation of the vocabulary of S union E which satisfies every member of S also satisfies E. This follows the wording of the definition of simple entailment in section 2, Section 2 , but refers only to rdf- , rdfs- or D-interpretations D-interpretation s instead of all simple interpretations. These are examples D-entailment is an example of vocabulary entailment , i.e. entailment relative to .

As noted above, it is possible that a set of interpretations graph which satisfy extra is consistent in one vocabulary becomes inconsistent in a semantic conditions extension defined on a vocabulary.

It is easy to see larger vocabulary, and D-interpretation s allow for inconsistencies in an RDF graph. The definition of vocabulary entailment means that the lemmas an inconsistent graph will entail any graph in section 2 do not hold for the stronger vocabulary entailment. For example, the triple a D-inconsistent graph D-entail s any RDF graph. However, it will usually not be appropriate to consider such 'trivial' entailments as useful consequences, since they may not be valid entailments in a smaller vocabulary.

`rdf:type rdf:type rdf:Property .`
6. Monotonicity of semantic extensions

is true Given a set of RDF graphs, there are various ways in deleted text: every rdf-interpretation, and hence rdf-entailed by the empty graph, which immediately contradicts the interpolation lemma for rdf-entailment.

Rather than develop a separate theory one can 'add' information to it. Any of the syntactic conditions for recognizing entailment for each special vocabulary, we will use a general technique for reducing these broader notions of entailment graphs may have some triples added to simple entailment, it; the set of graphs may be extended by defining extra graphs; or the closure vocabulary of an RDF the graph may be interpreted relative to a stronger notion of vocabulary entailment , i.e. with a larger set of semantic conditions. The basic idea is conditions understood to rewrite be imposed on the semantic conditions interpretations. All of these can be thought of as a set an addition of syntactic inference rules, information, and define the closure to be may make more entailments hold than held before the result change. All of applying those rules to exhaustion. The resulting graphs will contain RDF triples which explicitly state all the special meanings embodied these additions are monotonic , in the extra semantic conditions, in effect axiomatizing them sense that entailments which hold before the addition of information, also hold after it. We can sum up this in a single lemma:

General monotonicity lemma . Suppose that S, S' are sets of RDF itself. A graph rdf-entails (rdfs-entails) another just when its rdf-closure (rdfs-closure) simply entails it. It is not possible to provide such graphs with every member of S a subset of some member of S'. Suppose that Y indicates a deleted text: tight result for D-entailment closures since the relevant semantic conditions require identities which cannot be stated in RDF.

The notion extension of X, S X-entails E, and S and E satisfy any syntactic restrictions of closure used here Y. Then S' Y-entails E.

In particular, if D' is deleted text: purely a formal device to relate two notions datatype map , D a subset of entailment. We do not mean to suggest that closure D' and if S D-entail s E then S also D'-entails E.

7. Entailment rules should (Informative)

The following tables list some inference patterns which capture some of the various forms of vocabulary entailment, and could be used as a computational technique, or that actually generating the full closure would be guide for the best process to use in order design of software to determine vocabulary check RDF graphs for RDF and RDFS entailment.

Closure Implementations may be based on applying the rules correspond forwards, or treating the conclusion as a pattern to implication axioms be recognized in the L _base translation given in consequent of a proposed entailment and searching backwards for an appropriate match with other rule conclusions or the appendix. proposed antecedent. Other strategies are also possible.

The rules are all stated with the form add a triple to a graph when it contains triples conforming to a pattern , and they are all deleted text: 4.1 Rdf-entailment </a> deleted text: and rdf closures (Informative)

The rdf-closure valid of an RDF in the following sense: a graph E is entails (in the appropriate sense listed) any larger graph got that is obtained by adding triples to E according applying the rules to the following (very simple) rules:

1. Add original graph. Notice that applying such a rule to a graph amounts to forming a simple union, rather than a merge , with the following triple (which is true in conclusion, and hence preserves any rdf-interpretation):

rdf:nil rdf:type rdf:List . blank nodes already in the graph.

2. Apply the following These rules deleted text: recursively to generate all legal RDF triples (i.e. until none of use the rules apply following conventions: uuu stands for any URI reference or the graph is unchanged.) Here xxx and yyy stand blank node identifier, vvv for any uriref, bNode URI reference or literal, aaa aaa, bbb, etc., for any uriref. URI reference, and xxx, yyy etc. for any URI reference, blank node identifier or literal.

ICEXT(I( `rdfs:Datatype` )) = if <aaa,x> is in D then I(aaa) = x
deleted text: For any typed literal "sss"^^ddd or "sss"@ttt^^ddd in G, if I(ddd) <aaa,x> is in D then ICEXT(x) is the value space of x and deleted text: 'sss' is a valid lexical form for I(ddd) then IL("sss"^^ddd) = L2V(I(ddd))(sss) subset of LV
For	if <aaa,x> is in D then for any typed literal "sss"^^ddd or "sss"@ttt^^ddd in G, if "sss"^^ddd with I(ddd) = x , if sss is in D and 'sss' is not a valid the lexical form for I(ddd) space of x then IL("sss"^^ddd) IL("sss"^^ddd) = L2V(x)(sss), otherwise IL("sss"^^ddd) is not in LV
If x	if <aaa,x> is in D, D then ICEXT(x) is the value space of L2V(x) and I(aaa) is a subset of ICEXT(I(rdfs:Literal)) in ICEXT(I( `rdfs:Datatype` ))

7.1 Simple Entailment Rules

The interpolation lemma in Section 2 characterizes simple entailment in terms of instances and subgraphs. Being a subgraph requires no explicit formulation as an inference rule on triples, but one can give rules which infer generalizations from instances, for example:

simple entailment rules.

Rule name deleted text: </td>		if If E contains		then add
rdf1	xxx aaa yyy `.`	se1		uuu aaa vvv `deleted text: rdf:type rdf:Property . </code> </td>`
rdf2a		xxx uuu aaa `" _:` yyy nnn `deleted text: "^^rdf:XMLLiteral . </code> </p> where <span class="diff-old-a">deleted text: </span> yyy is a well-formed XML document`	xxx aaa <code> " zzz `"^^rdf:XMLLiteral . _:` where zzz nnn is a well-formed XML document with the same XML canonical form as yyy. blank node identifier allocated to vvv by rule se1 or se2.
rdf2b
se2	xxx	bbb aaa xxx `deleted text: "` yyy `"@` ttt `^^rdf:XMLLiteral . </code> <span class="diff-old-a">deleted text: </span> where yyy is a well-formed XML document and ttt is a language tag </td>`		xxx aaa `"` zzz `"@ _:` ttt nnn aaa xxx `deleted text: ^^rdf:XMLLiteral . </code> </p> <span class="diff-old-a">deleted text: </span>` `where zzz _: nnn is any well-formed XML document such a blank node identifier allocated to bbb by rule se1 or se2.`

The terminology 'allocated to' means that the canonical form blank node must have been created by an earlier application of the XML document yyy with specified rules on the language tag ttt same URI reference or literal, or if there is no such blank node then it must be a 'new' node which does not occur in the graph. This rather complicated condition ensures that the resulting graph, obtained by adding the new blank-node triples, has the original graph as a proper instance and that any such graph will have a subgraph which is the same as one which can be generated by these rules: the canonical form of zzz with language tag ttt.

Notice association between introduced blank nodes and the URI reference or literal that rdf1 immediately generates they replace provides the triple instance mapping. For example, the graph

rdf:type rdf:type rdf:Property <ex:a> <ex:p> <ex:b> . <ex:c> <ex:q> <ex:a> .

which expresses a central semantic property of rdf interpretations.

The following lemma is the basic result on rdf-entailment, and illustrates a general pattern of how to characterize vocabulary entailment syntactically.

could be expanded as follows

RDF entailment lemma . S rdf-entails E if and only if the rdf-closure of the merge of S simply entails E.

The result is rather obvious, but _:x <ex:p> <ex:b> . by se1 using a complete proof new _:x which is given in the appendix allocated to illustrate ex:a <ex:c> <ex:q> _:x . by se2 using the proof method.

The rather awkward statement of rules rdf2a and b is necessary same _:x allocated to ensure that the entailment lemma holds when the conclusion E contains ex:a _:x <ex:p> _:y . by se2 using a non-canonicalized XML literal. In practice, new _:y which is allocated to ex:b

but it would not be sufficient correct to apply a canonicalization operation infer

** _:x <ex:q> <ex:a> . ** by se2 (** since _:x is not allocated to both S and E, taking appropriate account of language tags, and then ignore these rules. ex:c )

4.2 RDFS-entailment and RDFS closures (informative)

RDFS closures require more complex

Applying these rules to reflect the consequences of the more elaborate semantic constraints on the rdfs vocabulary.

The rdfs-closure of an RDF a graph E is the will produce a graph got which is simply entailed by deleted text: adding triples to E according to the RDF closure original. These rules together with the following rules:

1. Add the RDFS axiomatic triples from the table in section 3.3, and will not generate all graphs which have the following triples. There are original graph as an instance, which could include arbitrarily many other blank-node triples all of which are true in every rdfs-interpretation, but they will instantiate back to the original triples. In order to be generated from these by able to generate all such graphs, the closure rules. rules must be modified to generate non-proper instances, for example by allowing new blank nodes to be allocated to existing blank nodes. Appendix A describes such a modification .

7.2 RDF Entailment Rules

RDF entailment rules

Rule Name	if E contains	then add
rdf1	xxx aaa yyy `.`	aaa `rdf:type rdfs:range rdfs:Class rdf:Property .`
rdf2	xxx aaa lll `.` `rdfs:Resource rdf:type rdfs:Class` `where lll is a well-typed XML literal .`	xxx aaa `rdfs:Literal rdf:type rdfs:Class . rdf:Statement rdf:type rdfs:Class . rdf:nil rdf:type rdf:List . rdf:XMLLiteral rdf:type rdfs:Datatype . _:` `rdf:subject rdf:type rdf:Property . rdf:predicate rdf:type rdf:Property . rdf:object rdf:type rdf:Property . nnn . rdf:first rdf:type rdf:Property . _: nnn deleted text: rdf:rest rdf:type rdf:Property rdf:XMLLiteral . deleted text: </code> </p> <p> 2. Add all triples of the following forms. This is an infinite set because the RDF container vocabulary where _:nnn is infinite. However, since none of a blank node identifier allocated to lll by this rule.`

Applying these triples entail any of and the others, it is only necessary, in practice, earlier rules to add a graph produces a graph which is rdf-entailed by the original. Note also that the RDF axiomatic triples which use those container properties which actually occur are valid in all rdf-interpretation s, so these rules can be applied to them as well as to any particular graph or set of graphs triples in deleted text: order to check the rdfs-entailment relation between those graphs. graph.

These rules are rdf:_1 rdf:type rdfs:ContainerMembershipProperty . rdf:_2 rdf:type rdfs:ContainerMembershipProperty .
... complete in the following sense:

3. Apply RDF entailment lemma . S rdf-entails E if and only if there is a graph which can be derived from S plus the following rules recursively to generate all legal RDF axiomatic triples (i.e. until none by the application of the simple entailment rules apply or the graph is unchanged.) Here, xxx, yyy and zzz stand for any uriref, bNode or literal, aaa for any uriref, RDF entailment rules and uuu for any uriref or bNode (but not a literal). which simply entails E. ( Proof in Appendix A)

7.3 RDFS Entailment Rules

RDFS entailment rules.


Rule Name		If E contains:	then add:
rdf1 rdfs1	xxx aaa yyy lll `.` where lll is a plain literal (with or without a language tag).	xxx aaa `_:` nnn `. _:` nnn rdf:type rdf:Property . rdfs:Literal `.` where `_:` nnn is a blank node allocated to lll by this rule.
rdfs2	deleted text: xxx aaa yyy `.` aaa <code> rdfs:domain </code> zzz <code>. </code> xxx aaa yyy `.`	xxx `rdf:type` zzz `.`
rdfs3	deleted text: xxx aaa uuu `.` aaa <code> rdfs:range </code> zzz <code>. </code> xxx aaa uuu `.`	uuu `rdf:type` zzz `.`
rdfs4a	xxx aaa yyy `.`	xxx `rdf:type rdfs:Resource .`
rdfs4b	xxx aaa uuu `.`	uuu `rdf:type rdfs:Resource .`
rdfs5a rdfs5	aaa `rdfs:subPropertyOf` bbb `.` bbb `rdfs:subPropertyOf` ccc `.`	aaa `rdfs:subPropertyOf` ccc `.`
rdfs5b rdfs6	xxx `rdf:type rdf:Property .`	xxx `rdfs:subPropertyOf` xxx `.`
rdfs6 rdfs7	deleted text: xxx aaa yyy `.` aaa <code> rdfs:subPropertyOf </code> bbb <code>. </code> xxx aaa yyy `.`	xxx bbb yyy `.`
rdfs7a rdfs8	xxx `rdf:type rdfs:Class .`	xxx `rdfs:subClassOf rdfs:Resource .`
rdfs7b rdfs9	xxx `rdfs:subClassOf` yyy `.` aaa `rdf:type` xxx `.`	aaa `rdf:type` yyy `.`
rdfs10	xxx `rdf:type rdfs:Class .`	xxx `rdfs:subClassOf` xxx `.`
rdfs8 rdfs11	xxx `rdfs:subClassOf` yyy `.` yyy `rdfs:subClassOf` zzz `.`	xxx `rdfs:subClassOf` zzz `.`
rdfs9 rdfs12	deleted text: xxx <code> <span class="diff-old-a">deleted text: </span> rdfs:subClassOf yyy `.` aaa `rdf:type` xxx `. rdfs:ContainerMembershipProperty .` deleted text: </td> <td> aaa xxx `rdf:type` yyy `. rdfs:subPropertyOf rdfs:member .`
rdfs10 rdfs13	xxx `rdf:type rdfs:ContainerMembershipProperty rdfs:Datatype .`	xxx `rdfs:subPropertyOf rdfs:member rdfs:subClassOf rdfs:Literal .`

The outputs of these rules will often trigger others. For example, these These rules will generate the are complete transitive closures of all subclass and subproperty heirarchies, together with all of in the resulting type information about everything following sense:

RDFS entailment lemma . If S is rdfs-consistent, then S rdfs-entails E if and only if there is a graph which can be inferred derived from S plus the RDF and RDFS axiomatic triples by the application of the simple , RDF and RDFS entailment rules and which simply entails E. ( Proof in Appendix A)

The restriction to rdfs-consistent antecedents is required in order to rule out cases where an rdfs-inconsistent set of graphs rdfs-entails any graph, including graphs which are syntactically unrelated to the antecedent. Those cases are not covered by this lemma. In order to be complete in this case, a member set of rules would need a clear syntactic criterion for recognizing inconsistency, and a rule which allowed the inference of any triple from a graph containing such a contradiction. In the case of RDFS, the classes, appropriate syntactic signal of an inconsistency could be the derivation of a graph containing a subgraph of the following form:

xxx rdfs:subClassOf rdfs:Literal .
bbb rdfs:range xxx .
aaa rdfs:subPropertyOf bbb .
yyy aaa lll .

where lll is an ill-typed XML literal.

The RDFS rules are somewhat redundant. All but one of the RDF axiomatic triples can be derived from the rules rdfs2 and rdfs3 and the RDFS axiomatic triples , for example; and rule rdfs1 subsumes cases of rule se1 where vvv is a plain literal.

The outputs of these rules will often trigger others. These rules will propagate all rdf:type assertions in the graph up the subproperty heirarchy, and subclass heirarchies, re-asserting them for all super-properties. super-properties and superclasses. rdfs1 will generate type assertions for all the property names used in the graph, and rdfs3 together with the first last RDFS axiomatic triple in the above list will add all the types type assertions for all the class names used. Any subproperty or subclass assertion will generate appropriate type assertions for its subject and object via rdfs 2 rdfs2 and 3 rdfs3 and the domain and range assertions in the RDFS axiomatic triple set. The rules will generate all assertions of the form

xxx rdf:type rdfs:Resource .

for every xxx in V, and of the form

xxx rdfs:subClassOf rdfs:Resource .

for every class name; name xxx; and several more 'universal' facts, such as

rdf:Property rdf:type rdfs:Class .

7.3.1 Extensional Entailment Rules

However, it is easy to see that (with the restriction noted of The stronger extensional semantic conditions described in Section 4.1 sanction further entailments which are not covered by the infinite sets to those membership properties RDFS rules. The following table lists some entailment patterns which occur are valid in this stronger semantics. This is not a complete set of rules for the graph) the extensional semantic conditions. Note that none of these rules deleted text: will indeed terminate on any finite RDF graph, since there are rdfs-valid; they apply only finitely many triples to semantic extensions which apply the strengthened extensional semantic conditions described in Section 4.1 . These rules have other consequences, eg that can be formed from rdfs:Resource is a given finite vocabulary.

A similar result applies here as in the case domain and range of rdf-entailment, though it takes considerably more work to prove: every property.

RDFS Entailment Lemma. S rdfs-entails Rules ext5-ext9 follow a graph E if and only if common pattern; they reflect the rdfs-closure of fact that the merge strengthened extensional conditions require domains (and ranges for transitive properties) of S simply entails E.

We note the properties in deleted text: passing that the stronger 'iff' rdfV and rdfsV vocabularies to be as large as possible, so any attempt to restrict them will be subverted by the semantic conditions on conditions. Similar rules apply to superproperties of rdfs:domain rdfs:range and rdfs:range rdfs:domain mentioned . None of these cases are likely to arise in section 3.3 practice.

Some additional inferences which would be captured by removing rules rdfs4a and rdfs4b, and adding valid under the additional rules

rdfs 2a extensional versions of the RDFS semantic conditions. deleted text: </table> and that these would provide a redundant inference path to the conclusions of rdfs 2 and 3.

4.3 7.4 Datatype entailments (Informative) Entailment Rules

In order to capture datatype entailment in terms of assertions and closure entailment rules, the rules need to refer to information supplied by the datatypes datatype s themselves; and to state the rules it is necessary to assume syntactic conditions which can only be checked by consulting the datatype sources. deleted text: Since such questions are beyond the scope of RDF, it is impossible to prove an entailment lemma for datatype closures analogous to those for RDF and RDFS.

Since language tags play no role in the meaning of a typed literal, they can in practice be ignored, and any literal of the form "sss"@ttt^^ddd, where ddd is not rdf:XMLLiteral, treated as identical to the same literal without the language tag, "sss"@ddd. We can capture this convention by special rules which allow language tags to be inserted or removed:

ext1		xxx `rdfs:domain` yyy `.` yyy `rdfs:subClassOf` zzz `.`	xxx `rdfs:domain` zzz `.`
rdfs 3a ext2	xxx `rdfs:range` yyy `.` yyy `rdfs:subClassOf` zzz `.`	xxx `rdfs:range` zzz `.`
rdfs 4a' ext3	xxx aaa `rdfs:domain` yyy . `.` zzz `rdfs:subPropertyOf` xxx `.`	aaa zzz `rdfs:domain` yyy `.`
ext4	xxx `rdfs:range` yyy `.` zzz `rdfs:subPropertyOf` xxx `.`	zzz `rdfs:range` yyy `.`
ext5	`rdf:type` `rdfs:subPropertyOf` zzz `.` zzz `rdfs:domain` yyy `.`	`rdfs:Resource` `rdfs:subClassOf` yyy `.`
ext6	rdfs 4b' `rdfs:` `subClassOf` `rdfs:subPropertyOf` zzz `.` zzz `rdfs:domain` yyy `.`	`rdfs:Class` `rdfs:subClassOf` yyy `.`
ext7	xxx aaa `rdfs:subPropertyOf` `rdfs:subPropertyOf` zzz `.` zzz `rdfs:domain` yyy `.`	`rdf:Property` `rdfs:subClassOf` yyy `.`
ext8	aaa `rdfs:` `subClassOf` `rdfs:subPropertyOf` zzz `.` zzz `rdfs:range rdfs:Resource` yyy `.`	`rdfs:Class` `rdfs:subClassOf` yyy `.`
ext9	`rdfs:subPropertyOf` `rdfs:subPropertyOf` zzz `.` zzz `rdfs:range` yyy `.`	`rdf:Property` `rdfs:subClassOf` yyy `.`

rdfD 0a	aaa ppp "sss"@ttt^^ddd `.`	aaa ppp "sss"^^ddd `.`
rdfD 0b	aaa ppp "sss"^^ddd `.`	aaa ppp "sss"@uuu^^ddd `.`

Here, ttt and uuu are any legal language tags and ddd is anything other than rdf:XMLLiteral. Clearly, these rules together can replace any language tag by any other.We also have a rule applying to all recognized datatypes, which requires their elements to be recognized as elements of rdfs:Literal: deleted text:

rdfD 0c xxx rdf:type rdfs:Datatype . xxx rdfs:subClassOf rdfs:Literal .

For each kind of information which is available about a datatype, we can give datatype , inference rules for information of that kind, kind can be stated, which can be thought of as extending the table of RDFS closure entailment rules. These should be understood as applying to datatypes datatype s other than the built-in datatype, the rules for which are part of the RDF closure RDFS entailment rules. The rules stated below assume that information is available about the datatype denoted by a recognized URI reference, and they use that URI reference to refer to the datatype .

The basic information specifies, for each literal string, whether or not it is a legal lexical form for the dataype. datatype, i.e. one which maps to some value under the lexical-to-value mapping of the datatype . This corresponds to the following rule, for each string sss that is a legal lexical form for the datatype ddd. Here _:xxx is a new blank node, i.e. one that does not appear elsewhere in the graph: denoted by ddd:

rdfD 1

rdfD1

ddd rdf:type rdfs:Datatype .
aaa ppp "sss"^^ddd .

aaa ppp _:xxx .
_:xxx rdf:type ddd .

where _:xxx is a blank node identifier allocated to "sss"^^ddd by this rule.

Suppose it is known that two lexical forms sss and ttt map to the same value under the datatype denoted by ddd; then the following rule applies:

rdfD 2

rdfD2

ddd rdf:type rdfs:Datatype .
aaa ppp "sss"^^ddd .

aaa ppp "ttt"^^ddd .

Suppose it is known that the lexical form sss of the datatype denoted by ddd and the lexical form ttt of the datatype denoted by eee map to the same value. Then the following rule applies:

rdfD 3

rdfD3

ddd rdf:type rdfs:Datatype .
eee rdf:type rdfs:Datatype .
aaa ppp "sss"^^ddd .

aaa ppp "ttt"^^eee .

Suppose that In addition, if it is known that the value space of the datatype denoted by ddd is a subset of that of the datatype eee. Then the following rule applies: denoted by eee, then it would be appropriate to assert that

deleted text:

rdfD 4

ddd <code> deleted text: rdf:type rdfs:Datatype .
eee


rdf:type
rdfs:Datatype
.

ddd




rdfs:subClassOf
</code>
eee
<code>.
</code>

but this needs to be asserted explicitly; it does not follow from the subset relationship alone.

Assuming that the information encoded in these rules is correct, applying these and the earlier rules will produce a graph which is D-entail ed by the original.

The rules rdfD2 and 3 are essentially substitutions by virtue of equations between lexical forms. Such equations may be capable of generating infinitely many conclusions, e.g. it is valid possible to add any number of leading zeros to any numeral and still lexical form for xsd:integer without it ceasing to be a correct lexical form for xsd:integer. To avoid such correct but unhelpful inferences, it is sufficient to restrict rdfD2 to cases which replace a lexical form with the canonical form for the datatype in question, when such a canonical form is defined. In order for the rules not to be complete , omit some valid entailments, however, such canonicalization rules would need to should be applied to the conclusions as well as the antecedents of any proposed entailments, and the corresponding rules of type rdfD3 would need to reflect knowledge of identities between canonical forms of the distinct datatype. datatype .

In particular cases other information might be available, which could be expressed using a particular RDFS vocabulary. Semantic extensions MAY may also define further such datatype-specific meanings.

Note that the rule rdfD 0c allows us These rules allow one to conclude that any well-formed typed literal of a recognized datatype must will denote something in the class rdfs:Literal.

aaa ppp "sss"^^ddd . ddd rdf:type rdfs:Datatype .

aaa ppp _:xxx . _:xxx rdf:type ddd . (by rule rdfD 1) rdfD1 ) ddd rdfs:subClassOf rdfs:Literal . (by rule rdfD 0c) rdfs11 ) _:xxx rdf:type rdfs:Literal . (by rule rdfs9) rdfs9 )

The rule rdfD1 is sufficient to expose some cases of a datatype clash, clash , by a chain of reasoning of the following form:

ppp rdfs:range ddd . aaa ppp "sss"^^eee .

aaa ppp _:xxx . _:xxx rdf:type eee . (by rule rdfD 1) rdfD1 )
_:xxx rdf:type ddd . (by rule rdfs 3) rdfs3 )

It may be useful to incorporate the assumption that any uriref appearing in a typed literal is presumed to be a datatype, which would be captured by the following rule. Note however that this is These rules do not strictly valid, so represents provide a (small) semantic extension.

rdfD -1

aaa ppp "sss"^^ddd .

ddd rdf:type rdfs:Datatype .

Datatype clashes and violations complete set of inference principles for D-entailment, since there may be deleted text: considered to be error conditions. However, we note that such graphs are not strictly ill-formed, and can be used to support valid RDFS entailments D-entailments for particular datatypes which might be meaningful in certain contexts.

Appendix A: Translation into L _base (Informative)

As noted in the introduction, an alternative way to specify RDF interpretations is to give a translation from RDF into a formal logic with a model theory already attached, as it were. This 'axiomatic semantics' approach has been suggested and used previously with various alternative versions depend on idiosyncratic properties of the target logical language [Conen&Klapsing] [Marchiori&Saarela] [McGuinness&al] . Here we use a version of first-order logic which was designed to provide a semantic reference for particular datatypes, such translations from web-based languages, called L _base [LBASE] , which uses a particularly efficient syntax.

To translate an RDF graph into as the semantic reference language L _base, apply size of the following rules to each expression noted. Each rule gives a translation TR [E] value space (eg xsd:boolean has only two elements, so anything established for the expression E, to those two values must be applied recursively. To achieve a translation which reflects a vocabulary entailment, add the axioms specified. Each vocabulary includes all axioms and rules true for preceding vocabularies, so that the RDFS translation of a graph should include the RDF translation as well as all literals with this datatype.) In particular, the RDFS axioms, value space and so on.

This translation uses lexical-to-value mapping of the L _base logical expressions Lbase:String XSD datatype deleted text: and <code> xsd:string Lbase:XMLthing , which are true respectively sanctions the identification of unicode typed literals with plain literals without language tags for all character strings, and anything that is denoted by a piece of well-formed XML syntax; and it introduces some terminology strings which are in order to give a logical account the lexical space of the meanings implicit in datatype, since both of them denote the various literal constructions. The axioms given are sufficient to define Unicode character string which is displayed in the intended meanings of literal; so the vocabulary used.

RDF expression E L _base expression TR [E]

a plain literal "sss" 'sss', with following inference rule is valid in all occurrences of the symbols ',\,(,),<,> prefixed with \

a plain literal "sss"@tag XSD-interpretations. Here, 'sss' indicates any RDF string in the term pair( TR ["sss"], 'tag' ) lexical space of deleted text:

a typed literal "sss"(@tag)^^ddd the term <code> L2V( TR ["sss"], TR [ddd] ) xsd:string

the uriref


rdfs:Resource

xsd 1a	T
a uriref of the form `rdf:_ nnn`	uuu aaa "sss" `.`	`rdf-member(` nnn	uuu aaa "sss"^^ `) xsd:string .`
any other uriref aaa	aaa
a blank node	a variable (one distinct variable per blank node)
xsd 1b
a triple	uuu aaa rdf:type bbb .	TR [bbb] `(` TR [aaa] `)` and `rdfs:Class(` TR [bbb] "sss"^^ `) xsd:string .`
any other triple	uuu aaa bbb ccc .	TR [bbb] `(` TR [aaa], TR [ccc] `) and rdf:Property(` TR [bbb] `) "sss" .`
an RDF graph	The existential closure of the conjunction of the translations of all the triples in

Again, as with the graph.

rules rdfD2 and rdfD3, applications may use a set of RDF graphs The conjunction systematic replacement of the translations one of all these equivalent forms for the graphs.

other rather than apply these rules directly.

`L2V(?y,?x)` is a term denoting the value Appendix A: Proofs of the lexical form ?y under the L2V mapping Lemmas (Informative)

"One of the datatype ?x. Datatype specifications in L _base must include sufficient axioms to define the appropriate values merits of deleted text: L2V. This can be simply a countably infinite set of equations stating the value for each legal lexical string, eg all equations of proof is that it instills a certain doubt as to the form

L2V('345',xsd:decimal)=345,

but other axiomatic theories can be used in some cases.

RDF axioms
result proved." -Bertrand Russell `rdf:type(?x,?y) implies ?y(?x) rdf:Property(rdf:type) rdf:List(rdf:nil) pair(?x,?y)=pair(?u,?v) iff (?x=?u and ?y=?v)` ;; uniqueness for pairs, required by graph syntax rules. `Lbase:XMLThing (?x) implies L2V(?x,rdf:XMLLiteral)=XMLCanonical(?x) (Lbase:XMLThing (?x) and LanguageTag(?y)) implies L2V(pair(?x,?y),rdf:XMLLiteral)=XMLCanonical(withLang(?x,?y))`

The RDF treatment of XML special forms does not lend itself to axiomatic description. The special function XMLCanonical is intended to map well-formed XML strings to their canonical forms. Empty Graph Lemma. The meaning of this can be expressed by a countable empty set of L _base equations, but triples is probably more usefully encoded in practice entailed by an XML canonicalization algorithm. Similarly, the function withLang maps an XML document any graph, and a language tag to the similar document with that language tag attached; again, this would does not entail any graph except itself.

Proof. Let N be deleted text: more usefully specified by an algorithm than by the infinite collection empty set of corresponding axioms, in practice. triples. The predicate LanguageTag semantic conditions on graphs require that N is deleted text: intended to be true deleted text: of syntactically correct XML language tags. Such axioms could be given as a list of atomic assertions, one for each of the valid language tags, and an assertion that all language tags were in I, for any I; so the list.

RDFS axioms

T(?x) rdfs:Class(?y) implies (?y(?x) iff rdf:type(?x,?y)) (rdfs:range(?x,?y) and ?x(?u,?v)) implies ?y(?v) (rdfs:domain(?x,?y) and ?x(?u,?v)) implies ?y(?u) (rdfs:subClassOf(?x ?y) iff (rdfs:Class(?x) and rdfs:Class(?y) and (forall (?u)(?x(?u) implies ?y(?u))) ) (rdfs:subPropertyOf(?x,?y) iff (rdf:Property(?x) and rdf:Property(?y) and (forall (?u ?v)(?x(?u,?v) implies ?y(?u,?v))) ) rdfs:ContainerMembershipProperty(?x) implies rdfs:subPropertyOf(?x,rdfs:member) rdf:XMLLiteral(?x) implies rdfs:Literal(?x) Lbase:String (?y) implies rdfs:Literal(?y)
LanguageTag(?x) implies Lbase:String (?x) ( Lbase:String (?x) and LanguageTag(?y)) implies rdfs:Literal(pair(?x,?y))
rdfs:Datatype(rdf:XMLLiteral) Lbase:NatNumber (?x) implies rdfs:ContainerMembershipProperty(rdf-member(?x)) rdfs:Class(T)
rdfs:Class(rdf:Property)
rdfs:Class(rdfs:Class)
rdfs:Class(rdfs:Datatype)
rdfs:Class(rdf:Seq)
rdfs:Class(rdf:Bag)
rdfs:Class(rdf:Alt)
rdfs:Class(rdfs:Container)
rdfs:Class(rdf:List)
rdfs:Class(rdfs:ContainerMembershipProperty)
rdfs:Class(rdf:Statement)
rdf:Property(rdfs:domain)
rdf:Property(rdfs:range) rdf:Property(rdfs:subClassOf)
rdf:Property(rdfs:subPropertyOf)
rdf:Property(rdfs:comment) rdf:Property(rdf:predicate)
rdf:Property(rdf:subject)
rdf:Property(rdf:object)
rdf:Property(rdf:first) rdf:Property(rdf:rest)
rdf:Property(rdfs:seeAlso)
rdf:Property(rdfs:isDefinedBy)
rdf:Property(rdfs:label) rdf:Property(rdf:value)
;; the rest of first part follows from the axioms are direct transcriptions definition of the RDFS axiomatic triples listed earlier, using the RDF to L _base transcription rules.
rdfs:domain(rdfs:subPropertyOf,rdf:Property) rdfs:domain(rdfs:subClassOf,rdfs:Class) rdfs:domain(rdfs:domain,rdf:Property)
rdfs:domain(rdfs:range,rdf:Property)
rdfs:domain(rdf:subject,rdf:Statement)
rdfs:domain(rdf:predicate,rdf:Statement)
rdfs:domain(rdf:object,rdf:Statement)
rdfs:domain(rdf:first,rdf:List)
rdfs:domain(rdf:rest,rdf:List) rdfs:range(rdfs:subPropertyOf,rdf:Property) rdfs:range(rdfs:subClassOf,rdfs:Class) rdfs:range(rdfs:domain,rdfs:Class) rdfs:range(rdfs:range,rdfs:Class) rdfs:range(rdf:type,rdfs:Class) rdfs:range(rdfs:comment,rdfs:Literal) rdfs:range(rdfs:label,rdfs:Literal) rdfs:range(rdf:rest,rdf:List) rdfs:subClassOf(rdfs:Datatype,rdfs:Literal) rdfs:subClassOf(rdf:Alt,rdfs:Container) rdfs:subClassOf(rdf:Bag,rdfs:Container) rdfs:subClassOf(rdf:Seq, rdfs:Container) rdfs:subClassOf(rdfs:ContainerMembershipProperty,rdf:Property) rdfs:subPropertyOf(rdfs:isDefinedBy,rdfs:seeAlso)

The third and fourth axioms for domain and range can be changed to 'if and only if' as suggested in section 3; these would then have the consequence

rdfs:Property(?x) implies (rdfs:domain(?x,T) and rdfs:range(?x,T))

RDF-D axioms

rdfs:Datatype(?x) implies ( LegalLexicalForm(?y,?x)) iff ?x(L2V(?y,?x)) ) ( rdfs:Datatype(?x) and LegalLexicalForm(?y,?x) and ?x(?y)) implies rdfs:Literal(?y) Lbase:XMLThing (?x) iff LegalLexicalForm(?x,rdf:XMLLiteral)

Here, LegalLexicalForm(?y,?x) is true when ?y entailment. Suppose G is a character string which any nonempty graph and s p o . is a legal lexical for for the datatype ?x. As triple in G, then an interpretation I with L2V, the corresponding axiomatic theory depends on the particular datatype, IEXT(I(p)) = { } does not satisfy G but in the limit can be two countably infinite sets of atomic sentences asserting for each string whether or does satisfy N; so N does not it is a legal form for entail G. QED .

This means that datatype. Usually these will conform to some regular pattern; for example, the lexical forms for the datatype xsd:decimal can be defined by infinitely many axioms most of the form

LegalLexicalForm('345',xsd:decimal) subsequent results are trivial for empty graphs, which is what one would expect.

deleted text:

Appendix B: Proofs of lemmas (informative).

<a name="subglemprf" id="subglemprf"> Subgraph Lemma. A graph entails all its subgraphs. </a> <blockquote> Proof. Obvious, from definitions of subgraph and entailment . If the graph is true in I then for some A, all its triples are true in I+A, so every subset of triples is true in I. QED

Instance Lemma. A graph is entailed by all its instances.

Proof. Suppose I satisfies E' and E' is an instance of E. Then for some mapping A on the blank nodes of E', I+A satisfies every triple in E'. For each blank node b in E, define B(b)=I+A(c), where c is the blank node or name that is substituted for b in E', or c=b if nothing was substituted for it. Then I+B(E)=I+A(E')=true, so I satisfies E. But I was arbitrary; so E' entails E. QED .

Merging lemma. The merge of a set S of RDF graphs is entailed by S, and entails every member of S.

Proof. Obvious, from definitions of entailment and merge. All members of S are true iff if and only if all triples in the merge of S are true. QED .

This means that, as noted in the text, deleted text: we can treat a set of graphs can be treated as a single graph when discussing satisfaction and entailment. We This convention will do this from now on, and refer be adopted in the rest of the appendix, where a reference to an interpretation of a set of graphs, a set of graphs entailing a graph, and so on, meaning should be understood in each case to refer to the merge of the set of graphs, and references to 'graph' in the following can be taken to refer to graphs or to sets of graphs.

For ground graphs, An interpretation I is a subinterpretation of J, written I<<J, when the subgraph lemma can be strengthened to provide simple necessary vocabulary of I is a subset of that of J and sufficient conditions for entailment. there is a mapping k, called a projection mapping , from (IR _I union IP _I ) to (IR _J union IP _J ) which satisfies the following conditions:

Conjunction Lemma. If E if x is ground , in IR _I then k(x) is in IR _J ;

if x is in IP _{I

satisfies

E} then k(x) is in IP _J ;

if and only x is a string or pair of strings then k(x)=x;

if it satisfies every triple x is a URI or literal then J (x) = k(I(x));

if <x,y> is in E. IEXT _I (z) then <k(x),k(y)> is in IEXT _J (k(z)) .

deleted text:

Proof. Obvious, from definition Clearly, << is reflexive and transitive (by composing the projection mappings.) The subinterpretation relation between interpretations is the dual of denotation for ground graphs. QED the entailment relation between sentences, as shown by the following lemma:
deleted text:

deleted text: Plain Subgraph Subinterpretation Lemma. deleted text: If E I << J and E' are ground, then I satisfies E entails E' if and only if E' is a subgraph of then J satisfies E.

Proof. 'If' follows directly from subgraph lemma; 'only if' follows Let k be the projection mapping of I into J. Since I satisfies E there is a mapping A from previous lemma and definition the blank nodes of entailment . E to IR _I such that [I+A] satisfies every triple
s p o .
in E, i.e. <[I+A](s),[I+A](o)> is in IEXT _I (I(p)); hence,
<k([I+A](s)),k([I+A](o))> is in IEXT _J (k(I(p))).

Define the mapping B by B(x)=k(A(x)); then [J+B](x)=k([I+A](x)) for any uriref, literal or blank node x, so the above can be written:
<[J+B](s),[J+B](o)> is in IEXT _J (J(p))
i.e. [J+B] satisfies the triple; so [J+B] satisfies every triple in E, so J satisfies E. QED

To prove The proof of the subsequent lemmas we introduce uses a way of constructing an interpretation of a graph by using the lexical items in the graph itself. (This was Herbrand 's idea.) idea; we here modify it slightly to handle XML literals and rdf:type appropriately.) Given a nonempty graph G, the Herbrand interpretation of G , G, written Herb(G), is the interpretation I defined as follows. The universe IR of I LV is the set of names all required literal values (well-formed XML literals in G, character strings and pairs of character strings and language tags); IR is LV plus all name s and blank nodes which occur in a subject or object position in a triple in G; IP is the set of URI references which occur in the property position of any triple; IS is the identity mapping on the vocabulary of G, IL maps XML documents to their canonical forms, and is otherwise is the identity mapping on all typed literals, literals into themselves, and IEXT is defined by: <s,o> is in IEXT(p) just when there is a triple in the graph of the form s p o deleted text: ., and IP is defined to be the set of urirefs which occur either as arc labels in the graph, or as subjects of triples of the form s rdf:type rdf:Property . deleted text: 

(This follows the standard definition of Herbrand interpretation but has some special features for RDF. The first part of the IP condition ensures that Herb(G) is an interpretation, and the second is a technical requirement for some of the later proofs. The XML condition is needed to make sure that Herbrand interpretations satisfy the built-in datatype rules.)

It is easy to see that Herb(G) is an interpretation which satisfies G. Clearly it satisfies all the ground triples in G; and if A Herb(G)+B, where B is the identity mapping map on blank nodes of in G, deleted text: then Herb(G)+A satisfies the entire graph; every triple in G, by construction, so Herb(G) satisfies G.

Herbrand interpretations interpretation s treat urirefs URI references and deleted text: non-XML typed literals (and blank nodes) in the same way as simple literals, i.e. as denoting their own syntactic forms. Of course this may not be what was intended by the writer of the RDF, but the lemma shows that any graph can be interpreted in this way. This therefore establishes the a useful result:

Satisfaction Lemma. Any RDF graph has a satisfying interpretation. QED

Herbrand interpretations interpretation s have some very useful properties. The Herbrand interpretation of a graph is a 'minimal' interpretation, which is 'just enough' to make the graph true; and so any interpretation which satisfies the graph must in a sense agree with the Herbrand interpretation; interpretation ; and of course any interpretation which does agree with the Herbrand interpretation will satisfy the graph. Taken together and made precise, these observations provide a way to characterize entailment between graphs in terms of Herbrand interpretations. interpretation s.

Herb(G) satisfies G, but only just. Anything that goes beyond what is said by the graph itself is not satisfied by the Herbrand interpretation. This sense of 'going beyond' can be characterized both semantically lemma. I satisfies E if and syntactically. only if Herb( E) << I.

The semantic version refers to subinterpretations and isomorphisms between interpretations. Given two interpretations I and J, say that I is a subinterpretation of J , and write Proof. Write H= Herb(E) .

Suppose I << J, if satisfies E, then the vocabulary of interpretation mapping I is a subset of the vocabulary of J and there is itself defines a projection mapping from IR into JR, IS into JS, IL H into JL IR; for H(a)=a for any name in E, and so I(H(a))=I(a); and <s,o> is in IEXT into JEXT such that any _H (p) just in case the triple s p o . is deleted text: true in J if it is true E; since I satisfies E, <I(s),I(o)> = <I(H(s)),I(H(o))> must be in I; and that IEXT _{I

and
J
are

isomorphic

if
each} (I(p)), i.e. IEXT _I(H) (I(H(p)), which is deleted text: a subinterpretation of the other. Obviously if condition for I to be a projection from H to I; so H<<I.

Now suppose H << J and I I. H satisfies E then J satisfies E, by construction, so deleted text: if I and J are isomorphic then they satisfy satisfies E by the same graphs. subinterpretation lemma. QED

The key property of Herbrand interpretations, proved below, following is that an immediate consequence:

Herbrand entailment lemma . S entails E if and only if Herb( S) satisfies E.

Proof. Suppose S entails E. Herb( S) satisfies S, so Herb( S) satisfies E.

Now suppose Herb( S) satisfies E. If I satisfies E just when Herb(E) S then Herb( S) << I. I; so I satisfies E. But I was arbitrary; so S entails E.
QED

The syntactic version properties of Herbrand interpretations can be described in terms of instances and subgraphs. Say that a graph E' is separable connected from to a graph E if no some instance of E' is a subgraph of E. In particular, a ground graph is separable from connected to E just when it is deleted text: not a subgraph of E, deleted text: and a ground triple is separable connected just in case when it isn't is in the graph. Graphs which are not separable from connected to E are entailed by E, by the subgraph and instance lemmas; but for all others, there is a way to arrange the world so that they are false and E true.

In particular, if E' is separable from not connected to E then Herb(E) Herb( E) does not satisfy E'; for suppose that it did, then for some mapping B from the blank nodes of E' to the blank nodes and vocabulary of E, Herb(E)+B Herb( E)+B satisfies E', which means that for every triple

s p o .

in E', the triple

[Herb(E)+B](s) [ Herb( E)+B](s) p [Herb(E)+B](o) [ Herb( E)+B](o) .

occurs in E, by definition of Herb(E). Herb( E). But the set of these triples is an instance of E', by construction; so E' is not separable from connected to E.

This means that we can state provides an exact correspondence between separability and Herbrand interpretations: interpretation s:

Herbrand separation lemma. Herb(E) Herb( E) satisfies E' if and only if E' is not separable from E. QED

Probably the most useful property of Herbrand interpretations is the following. The version of this lemma for first-order logic, called Herbrand's theorem , is the basis of all the logical completeness connected results.

Herbrand lemma. I satisfies E if and only if Herb(E) << I.

Proof. Suppose I satisfies E. The interpretation mapping I itself defines a projection mapping from Herb(E) into I, and if I satisfies E then I makes true all the triples that Herb(E) makes true, so Herb(E) << I.

Suppose Herb(E) << I. Since Herb(E) satisfies E, there is a mapping A from the blank nodes of E so that I+A satisfies all the triples from E, so I satisfies E

QED

The following is an immediate consequence :

Herbrand entailment lemma . S entails E if and only if Herb(S) satisfies E.

Proof. Suppose S entails E. Herb(S) satisfies S, so Herb(S) satisfies E.

Now suppose Herb(S) satisfies E. If I satisfies S then Herb(S) << I; so I satisfies E. But I was arbitrary; so S entails to E. deleted text:
QED deleted text:

Putting the separation and entailment results together, it is obvious that S entails E if and only if E is not separable from connected to S. This is simply a restatement of the:
Interpolation Lemma. S entails E if and only if a subgraph of S is an instance of E. QED.
This lemma can be used as the basis for several different mechanical processes for checking simple entailment. One way to characterize entailment syntactically is in terms of inference rules which apply to a set S and can be used to derive E just when S entails E. For example, a slight modification of the simple entailment rules described in section 7.1 will suffice, where we allow new blank nodes to be allocated to existing blank nodes as well as to URI references and literals:

extended simple entailment rules.

Rule name If E contains then add

xse1 uuu aaa xxx .
uuu aaa _: nnn .
where _: nnn is a blank node identifier allocated to xxx by rule xse1 or xse2.

xse2 uuu aaa xxx .
_: nnn aaa xxx .
where _: nnn is a blank node identifier allocated to uuu by rule xse1 or xse2.

These rules allow blank nodes to proliferate, producing highly non- lean graphs; they sanction entailments such as

ex:a exp ex:b . ex:a ex:p _:x . by xse1 with _:x allocated to ex:b
ex:a ex:p _:y . by xse1 with _:y allocated to _:x
_:z ex:p _:y . by xse2 with _:z allocated to ex:a
_:u ex:p _:y . by xse2 with _:u allocated to _:z
_:u ex:p _:v . by xse1 with _:v allocated to _:y

It is easy to see that if S is an instance of E then one can derive E from S by applying these rules in a suitable sequence; the rule applications required can be discovered by examination of the instance mapping. So, by the interpolation lemma, S entails E iff one can derive (a graph containing) E from S by the application of these rules. However, it is also clear that applying these rules naively would not result in an efficient search process, since the rules will not terminate and can produce arbitrarily many redundant derivations of equivalent triples.

The general problem of determining simple entailment between arbitrary RDF graphs is decideable but NP-complete. This can be shown by encoding the problem of detecting a subgraph of an arbitrary directed graph as an RDF entailment, using blank nodes to represent the graph (observation due to Jeremy Carroll.)

The following are direct consequences of the interpolation lemma:
Anonymity lemma 1. lemma. Suppose E is a lean graph and E' is deleted text: a proper instance of E. Then E does not entail E'. <blockquote> Proof. Since E' is a proper instance and E is lean , E' is separable from not connected to E. Therefore E does not entail E' QED

deleted text: Anonymity lemma 2. Monotonicity Lemma . Suppose that S is a subgraph of S' and S entails E. Then S' entails E. (Special case of general monotonicity lemma)

Compactness Lemma . If S entails E and E is a lean graph finite graph, then some finite subset S' of S entails E.

Proof. By the interpolation lemma, a subgraph S' of S is an instance of E; so S' is finite, and that E' S' entails E. QED

Although this result is like E except that two distinct blank nodes trivial for simple entailment, it becomes progressively less trivial in more elaborate semantic extensions.

General monotonicity lemma . Suppose that S, S' are sets of RDF graphs with every member of S a subset of some member of S'. Suppose that Y indicates a semantic extension of X, S X-entails E, and S and E have been identified in E'. satisfy any syntactic restrictions of Y. Then E does not entail E'. S' Y-entails E.

Proof. This follows simply by tracing the definitions. Suppose that I is a Y-interpretation of S'; then since Y is a semantic extension of X, I is an X-interpretation; and by the subgraph and merge lemmas, I satisfies S; so I satisfies E.

QED

RDF entailment lemma . S rdf-entails E if and only if there is a graph which can be derived from S plus the RDF axiomatic triples by the application of the simple entailment rules and RDF entailment rules and which simply entails E.

Proof. Proof (Note: the following informative proof is incomplement. A corrected proof is anticipated in a future version of this document.) To show 'if' here is trivial: one has only to check that the RDF entailment rules are rdf-valid, which is left as an exercise for the reader. To establish 'only if' requires more work, however.

If S or E is empty then the result follows trivially; so suppose they are both non-empty.

Define the rdf-V-closure of a graph G, rdfclos(V, G), to be the graph gotten by adding all the RDF axiomatic triples which contain any vocabulary from (V union crdfV) to G and then applying the simple entailment rules and RDF entailment rules in all possible ways until the graph is unchanged. Define the combined vocabulary vocab(S) union vocab(E) to be W. We have will show that rdfclos(W, S) satisfies the conditions of the lemma.

Let H be the Herbrand interpretation of rdfclos(W, S). It is sufficient to show that E' there is separable from an rdf-interpretation H' of W with H'<<H; for in that case since S rdf-entails E then H' satisfies E; and if I is any simple interpretation of W which satisfies rdfclos(S) then H <<I by the Herbrand lemma, so H' <<I, so I satisfies E; so rdfclos(S) simply entails E.
First we assume H' is constructed from H by adjusting the definition of IP and the interpretation of well-typed XML literals and the class extension of rdf:XMLLiteral ; in other respects H' and H are identical (so that for any other URI reference uuu, I _H' (uuu)=I _H (uuu)=uuu.) The intuition behind this construction is that the Herbrand interpretation of literals is replaced by a genuine literal value, which is then projected onto the blank node which was introduced into the closure, and allocated to the literal, by the appropriate existential generalization rule. To be precise, define

IP _H' = the set of nodes which occur in two distinct triples in E. Suppose that E contains rdfclos(W, S) as the triples subject of a triple of the form
x rdf:type rdf:Property .
S1 P1 _:x1 . LV _H' = LV _H plus all XML literal values of well-typed XML literals in W;
S2 P2 _:x2 . IEXT _H' ( rdf:type ) = IEXT _H ( rdf:type ) union {<IL _H' (x), rdf:XMLLiteral >: x a well-typed XML literal in W};
where E' contains and for each well-typed XML literal x in W, define IL _H' (x) to be the subgraph consisting XML value of x.

In other respects H' is defined as H.

To see that H'<<H, define k by mapping XML literal values to their corresponding well-typed XML literals, blank nodes introduced by inference rules to the triples symbols to which they are allocated by the rule, and otherwise the identity mapping.
S1 P1 _:x . To show that k is a projection mapping two cases must be examined in detail.
S2 P2 _:x A URI aaa is in IP _H' just when a triple
aaa rdf:type rdf:Property .
is in rdfclos(W,S) ; so either this triple was in S, or it was introduced by rule rdf1 and S contains a triple x aaa y . ; either way, aaa is in IP _H, so k maps IP _H' to IP _H.
Since E If <x,y> is lean, in IEXT _H' (z) then either it contains no other triples of the form S1 P1 O' is also in IEXT _H (z) or S2 P2 O'. Therefore, this subgraph has no instances else <x,y> = <IL _H' (lll), rdf:XMLLiteral > where lll is a well-formed XML literal in E, so E' W. Suppose lll occurs in W in a triple
xxx aaa lll .
in W; then <xxx, lll> is separable from E. The arguments for the cases in IEXT _H (aaa) , and <xxx, _:nnn> is in IEXT _H' (aaa) and <_:nnn, rdf:XMLLiteral > is in IEXT _H' ( rdf:type ), where the _:nnn is allocated to lll by rule rdf2. By construction, k(IL _H' (lll))=k(_:nnn)=lll and k(aaa)=aaa, k(xxx)=xxx, and k( rdf:XMLLiteral )= rdf:XMLLiteral ; so k is a projection.

Note that this requires that blank nodes introduced by rules are mapped appropriately to their allocated names.

H' satisfies the first two RDF semantic conditions by construction. To see that it satisfies the third, observe that IL _H' (lll)=IL _H (lll)=lll when lll is an ill-typed XML literal, so IL _H' (lll) is not an XML literal value and is not in LV _H', and that since no triple in W can cause a pair <lll, x> to occur in other positions any extension in the Herbrand interpretation, and no entailment rule can impose any such condition, that therefore it will not occur in any extension in H'. So the third RDF semantic condition is satisfied and H' is an RDF interpretation, as required.

QED

RDFS entailment lemma . If S is rdfs-consistent, then S rdfs-entails E if and only if there is a graph which can be derived from S plus the RDF and RDFS axiomatic triples by the application of the simple , RDF and RDFS entailment rules and which simply entails E.

Proof (Outline) (Note: the following informative proof is incomplement. A corrected proof is anticipated in a future version of this document.) Again, to show 'if' it is sufficient to show that the RDFS entailment rules are similar. rdfs-valid, which is again left as an exercise; and again, the empty cases are trivial.
The only remaining case proof of 'only if' is where E similar to that used in the previous lemma, and similar constructions and terminology will be used, except that the RDFS closure, rdfsclos(V,G), is the graph gotten by adding the appropriate RDF and RDFS axiomatic triples to G, and then applying the simple, RDF and RDFS entailment rules until the graph is unchanged. Let H be the Herbrand interpretation of rdfsclos(W,S) and H' be constructed from H as in the previous proof, except that the extension of rdf:type is more complicated:

IEXT _H' (rdf:type) = IEXT _H (rdf:type) union
{<IL _H' (x), rdf:XMLLiteral >: x a well-typed XML literal in W}union
{<IL _H' (x), rdfs:Literal >: x a plain literal in W}union
{<IL _H' (x), y>: x a literal in W and rdfclos(W,S) contains a single triple with graph of the form:

aaa rdfs:subPropertyOf bbb .
bbb rdfs:range zzz .
zzz rdfs:subClassOf y .
www aaa x . } .

H' satisfies the first two blank nodes which RDF semantic conditions by construction. On the RDFS semantic conditions H and H' are identified indistinguishable, and the argument can be made case by case, matching the RDFS semantic conditions with the appropriate entailment rules. The form of the argument is illustrated with two examples.

Consider the first RDFS semantic condition . Suppose <x,y> is in E': IEXT _H ( rdfs:domain ) and <u,v> is in IEXT _H (x); then by the minimality of the Herbrand interpretation , rdfsclos(W,S) must contain triples
_:x1 P _:x2 x rdfs:domain y . u x v .
where E' so by rule rdfs2 , it must also contain the triple

u rdf:type y .

so by the construction of H, IEXT _H ( rdf:type ) contains <u,y>, i.e. u is in ICEXT _H (y).
_:x P _:x In some cases, the rule derivation involves several steps and some of the RDF and RDFS axiomatic triples; for example, to show that H satisfies the seventh RDFS semantic condition

If <x,y> is in IEXT(I( rdfs:subClassOf )) then x and y are in IC and ICEXT(x) is a subset of ICEXT(y)

note that <x,y> is in IEXT _H ( rdfs:subClassOf ) only if rdfsclos(W,S) contains

x rdfs:subClassOf y

and then the following are all in rdfsclos(W,S):

rdfs:subClassOf rdfs:domain rdfs:Class . ( RDFS axiomatic triple )
x rdf:type rdfs:Class . (rule rdfs2 )
rdfs:subClassOf rdfs:range rdfs:Class . ( RDFS axiomatic triple )
y rdf:type rdfs:Class . (rule rdfs3 )

so x and y are both in IC _H ; and that if z is in ICEXT _H (x) then rdfsclos(W,S) must contain a triple

z rdf:type x .

so it must also contain a triple

z rdf:type y . by rule rdfs9

so by the construction of the Herbrand interpretation , <z,y> is in IEXT _H ( rdf:type ), i.e. z is in ICEXT _H (y).
The argument here other RDFS semantic conditions can be checked similarly. The correspondence between rule rdfs3 and the RDFS semantic condition on rdfs:range relies on the extra conditions on H' described above to handle the case where the entity in the object position is similar; there a literal, which is no substitution not covered by the rule itself. In this case, the closure contains assertions which mirror the semantic conditions but are stated in the triples using the blank node allocated to the literal by the appropriate rule: rdf2 for well-typed XML literals, rdfs1 for other typed literals and rule se1 for all other literals. Note that this construction relies on the projection mapping respecting blank node allocation.

To show that H'<<H, define k as in the second graph which can produce previous proof. The argument proceeds similarly to that used in the first graph. previous lemma, using rules rdfs1and se1 to cover the extra cases.
Since E' It remains to show that H' satisfies the third RDF semantic condition. Using the minimality of the Herbrand universe and the definition of k, a survey of the RDFS semantic conditions shows that this condition fails just when the graph constrains an ill-typed XML literal value to be in LV _H', and that by the above construction, rdfsclos(S,W) must be rdfs-inconsistent, so S is separable from E, E does not entail E'. rdfs-inconsistent, contrary to hypothesis: to the condition is satisfied.

QED .

Skolemization is a syntactic transformation routinely used in automatic inference systems in which existential variables are replaced by 'new' functions - function names not used elsewhere - applied to any enclosing universal variables. While not itself strictly a valid operation, skolemization Skolemization adds no new content to an expression, in the sense that a skolemized Skolemized expression has the same entailments as the original expression provided they do not contain the new skolem functions.

In RDF, skolemization Skolemization simplifies to the special case where an existential variable is replaced by a 'new' name, i.e. a uriref URI reference which is guaranteed to not occur anywhere else.(Using else. (Using a literal would not do. Literals are never 'new' in the required sense, since their meaning is fixed.) sense.) To be precise, a skolemization Skolemization of E (with respect to V) is a ground instance of E with respect to a vocabulary V which is disjoint from the vocabulary of E.

The following lemma shows that skolemization Skolemization has the same properties in RDF as it has in conventional logics. Intuitively, this lemma shows that asserting a skolemization Skolemization expresses a similar content to asserting the original graph, in many respects. In effect, it simply gives 'arbitrary' names to the anonymous entities whose existence was asserted by the use of blank nodes. However, care is needed, since these 'arbitrary' names have the same status as any other urirefs URI references once published. Also, skolemization Skolemization would not be an appropriate operation when applied to anything other than the antecendent of an entailment. A skolemization Skolemization of a query would represent a completely different query.

Skolemization Lemma. Suppose sk(E) is a skolemization of E with respect to V. Then sk(E) entails E; and if sk(E) entails F and the vocabulary of F is disjoint from V, then E entails F .

Proof. sk(E) entails E by the interpolation lemma.
Now, suppose that sk(E) entails F where F shares no vocabulary with V; and suppose I is some interpretation satisfying E. Then for some mapping A from the blank nodes of E, I+A satisfies E. Define an interpretation I' of the vocabulary of sk(E) by: IR'=IR, IEXT'=IEXT, I'(x)=I(x) for x in the vocabulary of E, and I'(x)=[I+A](y) for x in V, where y is the blank node in E that is replaced by x in sk(E).Clearly sk(E). Clearly I' satisfies sk(E), so I' satisfies F. But I'(F)=[I+A](F) since the vocabulary of F is disjoint from that of V; so I satisfies F. deleted text: So E entails F. QED .

RDF closure lemma. The Herbrand interpretation of the rdf-closure of E is an rdf-interpretation of E.

Proof. This follows from a comparison of the rdf closure rules with the semantic conditions on an rdf-interpretation . Although the argument is very simple in this case, we give it here in full to illustrate the general technique. Basically, one can 'read off' the semantic conditions from the triples in the closure graph itself, taking into account the minimality of the Herbrand interpretation. We will refer to the rdf-closure of E as rdfclos(E), and for orthographic convenience we refer to Herb(rdfclos(E)) as H in the rest of the proof, and write IP _H to indicate the IP mapping of the interpretation H.

Clearly, H satisfies the triples

rdf:nil rdf:type rdf:List . rdf:type rdf:type rdf:Property .

so IP _H contains rdf:type, which is H( rdf:type ), so it satisfies the first condition. The third condition is then an obvious consequence of the definition of property extensions in Herbrand interpretations.

The second closure rules implies that if rdfclos(E) contains the triple s p o ., then it also contains the triple

p rdf:type rdf:Property .

so by the definition of Herbrand interpretation, HP contains p. This establishes that the 'if' part of the second condition.

To show the 'only if' part, suppose x is in IP _H. Then either x rdf:type rdf:Property. is in rdfclos(E) or s x o. is in rdfclos(E) for certain s and o. In the latter case, the closure rules show that again,

x rdf:type rdf:Property.

is in rdfclos(E). So in all cases, <x, H(rdf:Property)> is in HEXT(H(rdf:type)). QED .

RDF entailment lemma . S rdf-entails E if and only if the rdf-closure of S simply entails E.

Proof. The 'if' case follows from the fact that the rdf closure rules are all rdf-valid, which can be checked case by case; since S rdf-entails rdfclos(S), if rdfclos(S) entails E then S rdf-entails E.

Now suppose S rdf-entails E and I is a simple interpretation of rdfclos(S). Herb(rdfclos(S)) satisfies rdfclos(S) by construction. Since rdfclos(S) contains S, Herb(rdfclos(S)) satisfies S and, by the RDF closure lemma, is an RDF interpretation; so, since S rdf-entails E, Herb(rdfclos(S)) satisfies E. But Herb(rdfclos(S)) << I by the Herbrand lemma; so I satisfies E. But I was arbitrary, so S entails E. QED .

RDFS Closure Lemma. The Herbrand interpretation of the rdfs-closure of E is an rdfs-interpretation of E.

Proof. (Sketch) As in the proof of the RDF closure lemma, this follows from a point-by-point comparison of the rdfs closure rules with the semantic conditions on an rdfs-interpretation , and uses the minimality of the Herbrand interpretation to establish the necessary conditions on the interpretation. A full proof would be long but tedious. We will illustrate the form of the argument by considering some typical cases in detail.

In some cases the clearest way to argue this is to show the converse, by demonstrating that a simple interpretation of rdfs-clos(E) that violates any of the semantic conditions for an rdfs-interpretation of E would thereby make some triple in rdfs-clos(E) false, so could not be the Herbrand interpretation.

For example, if I violates the condition on IEXT(I( rdfs:range )), then there exist x, y, u and v in IR with <x,y> in IEXT(I( rdfs:range )), <u,v> in IEXT(x) but v not in ICEXT(y). Projecting these entities into the Herbrand interpretation with the identity map for blank nodes will identify two triples

aaa rdfs:range bbb .

ccc aaa ddd .

where I(aaa)=x, I(bbb)=y, I(ccc)=u and I(ddd)=v; but I makes the triple

ddd rdf:type bbb .

false, since I(ddd) is not in ICEXT(I(bbb)); and by the closure rule rdfs3, this triple is in rdfsclos(E); arbitrary; so deleted text: I fails to satisfy the rdfs closure.

(sketch) QED .

RDFS Entailment Lemma. S rdfs-entails E deleted text: iff the rdfs-closure of S simply entails E. F.

deleted text:

deleted text: Proof. Exactly similar to proof of RDF entailment lemma. QED . </blockquote>

Appendix C: B: Glossary of terms (informative). Terms (Informative)
Antecedent (n.) In an inference , the expression(s) from which the conclusion is derived. In an entailment relation, the entailer. Also assumption .
Assertion (n.) (i) Any expression which is claimed to be true. (ii) The act of claiming something to be true.
Class (n.) A general concept, category or classification. Something used primarily to classify or categorize other things. Formally, in RDF, a resource of type rdfs:Class with an associated set of resources all of which have the class as a value of the rdf:type property. Classes are often called 'predicates' in the formal logical literature.
(RDF distinguishes class from set, set , although the two are often identified. Distinguishing classes from sets allows RDF more freedom in constructing class heirachies, hierarchies, as explained earlier .)
Complete (adj., of an inference system). (1) Able to detect all entailment s between any two expressions. (2) Able to draw all valid inferences. See Inference . Also used with a qualifier: able to detect entailments or draw all valid inferences in a certain limited form or kind (e.g.between (e.g. between expressions in a certain normal form, or meeting certain syntactic conditions.)
(These definitions are not exactly equivalent, since the first requires that the system has access to the consequent of the entailment, and may be unable to draw 'trivial' inferences such as (p and p) from p. Typically, efficient mechanical inference systems may be complete in the first sense but not necessarily in the second.)

Consequent (n.) In an inference, the expression constructed from the antecedent . In an entailment relation, the entailee. Also conclusion .
Consistent (adj., of an expression) Having an satisfying interpretation ; not internally contradictory. (Also used of an inference system as synonym for Correct .)

Correct (adj., of an inference system). Unable to draw any invalid inferences. inferences, or unable to . See Inference .
Decideable (adj., of an inference system). Able to determine for any pair of expressions, in a finite time with finite resources, whether or not the first entails the second. (Also: adj., of a logic:) Having a decideable inference system which is complete and correct for the semantics of the logic.

(Not all logics can have inference systems which are both complete and decideable, and decideable inference systems may have arbitrarily high computational complexity. The relationships between logical syntax, semantics and complexity of an inference system continue to be the subject of considerable research.)

Entail (v.), entailment (n.). A semantic relationship between expressions which holds whenever the truth of the first guarantees the truth of the second. Equivalently, whenever it is logically impossible for the first expression to be true and the second one false. Equivalently, when any interpretation which satisfies the first also satisfies the second. (Also used between a set of expressions and an expression.)
Equivalent (prep., with to ) True under exactly the same conditions; making identical claims about the world, when asserted. Entails and is entailed by.
Extensional (adj., of a logic) A set-based theory or logic of classes, in which classes are considered to be sets, properties considered to be sets of <object, value> pairs, and so on. A theory which admits no distinction between entities with the same extension. See Intensional .
Formal (adj.) Couched in language sufficiently precise as to enable results to be established using conventional mathematical techniques.
Iff (conj.) Conventional abbreviation for 'if and only if'. Used to express necessary and sufficient conditions.
Inconsistent (adj.), false (adj.) False under all interpretations; impossible to satisfy . Inconsistency (n.), any inconsistent expression or graph.
( Entailment and inconsistency are closely related, since A entails B just when (A and not-B) is inconsistent, c.f. the second definition for entailment . This is the basis of many mechanical inference systems.

Although the definitions of consistency and inconsistency are exact duals, they are computationally dissimilar. It is often harder to detect consistency in all cases than to detect inconsistency in all cases .)

Indexical (adj., of a logic an expression) having a meaning which implicitly refers to the context of use. Examples from English include words like 'here', 'now', 'this'.
Infer ence (n.) An act or process of constructing new expressions from existing expressions, or the result of such an act or process. Inferences corresponding to entailments are described as correct or valid . Inference rule , formal description of a type of inference; inference system , set organized system of inference rules; also, software which generates inferences or checks inferences for validity.
Intensional (adj., of a logic) Not extensional . A logic which allows distinct entities with the same extension.
(The merits and demerits of intensionality have been extensively debated in the philosophical logic literature. Extensional semantic theories are simpler, and conventional semantics for formal logics usually assume an extensional view, but conceptual analysis of ordinary language often suggests that intensional thinking is more natural. Examples often cited are that an extensional logic is obliged to treat all 'empty' extensions as identical, so must identify 'round square' with 'santa clause', and is unable to distinguish concepts that 'accidentally' have the same instances, such as human beings and bipedal hominids without body hair. RDFS model theory The semantics described in this document is basically intensional but has some extensional aspects, most notably in the 'if and only if' conditions in the definitions of rdfs:subClassOf and rdfs:subPropertyOf, which force these properties to take account only of the class and property extensions.) intensional.)
Interpretation ( of ) (n.) A minimal formal description of those aspects of a world which is just sufficient to establish the truth or falsity of any expression of a logic.
(Some logic texts distinguish between a interpretation structure , which is a 'possible world' considered as something independent of any particular vocabulary, and an interpretation mapping from a vocabulary into the structure. The RDF semantics takes the simpler route of merging these into a single concept.)
Logic (n.) A formal language which expresses propositions .
Metaphysical (adj.). Concerned with the true nature of things in some absolute or fundamental sense.
Model Theory (n.) A formal semantic theory which relates expressions to interpretations.
(The name 'model theory' arises from the usage, traditional in logical semantics, in which a satisfying interpretation is called a "model". This usage is often found confusing, however, as it is almost exactly the inverse of the meaning implied by terms like "computational modelling", so we have has been avoided deleted text: it in this document.) <a name="glossMonotonic" id="glossMonotonic"> </a> Monotonic (adj., of a logic or inference system) Satisfying the condition that if S entails E then (S + T) entails E, i.e. adding information to some antecedents cannot invalidate a valid entailment.
(All logics based on a conventional model theory and a standard notion of entailment are monotonic. Monotonic logics have the property that entailments remain valid outside of the context in which they were generated. This is why RDF is designed to be monotonic.)
Nonmonotonic (adj.,of a logic or inference system) Not monotonic . Non-monotonic formalisms have been proposed and used in AI and various applications. Examples of nonmonotonic inferences include default reasoning , where one assumes a 'normal' general truth unless it is contradicted by more particular information (eg birds usually (birds normally fly, but penguins don't fly); negation-by-failure , commonly assumed in logic programming systems, where one concludes, from a failure to prove a proposition, that the proposition is false; and implicit closed-world assumptions , often assumed in database applications, where one concludes from a lack of information about an entity in some corpus that the information is false (e.g. that if someone is not listed in an employee database, that hse he or she is not an employee.)
(The relationship between monotonic and nonmonotonic inferences is often subtle. For example, if a closed-world assumption is made explicit, e.g. by asserting explicitly that the corpus is complete and providing explicit provenance information in the conclusion, then closed-world reasoning is monotonic; it is the implicitness that makes the reasoning nonmonotonic. Nonmonotonic conclusions can be said to be valid only in some kind of 'context', and are liable to be incorrect or misleading when used outside that context. Making the context explicit in the reasoning and visible in the conclusion is a way to map them into a monotonic framework.)
Ontological (adj.) (Philosophy) Concerned with what kinds of things really exist. (Applied) Concerned with the details of a formal description of some topic or domain.
Proposition (n.) Something that has a truth-value; a statement or expression that is true or false.
(Philosophical analyses of language traditionally distinguish propositions from the expressions which are used to state them, but model theory does not require this distinction.)
Reify (v.), reification (n.) To categorize as an object; to describe as an entity. Often used to describe a convention whereby a syntactic expression is treated as a semantic object and itself described using another syntax. In RDF, a reified triple is a description of a triple-token using other RDF triples.
Resource (n.)(as used in RDF)(i) An entity; anything in the universe. (ii) As a class name: the class of everything; the most inclusive category possible.
Satisfy (v.t.), satisfaction ,(n.) satisfying (adj., of an interpretation). To make true. The basic semantic relationship between an interpretation and an expression. X satisfies Y means that if the world conforms to the conditions described by X, then Y must be true.
Semantic (adj.) , semantics (n.). Concerned with the specification of meanings. Often contrasted with syntactic to emphasise emphasize the distinction between expressions and what they denote.
Skolemization (n.) A syntactic transformation in which blank nodes are replaced by 'new' names.
(Although not strictly valid, valid , Skolemization retains the essential meaning of an expression and is often used in mechanical inference systems. The full logical form is more complex. It is named after the logician A. T. Skolem )
Token (n.) A particular physical inscription of a symbol or expression in a document. Usually contrasted with type , the abstract grammatical form of an expression.
Universe (n., also Universe of discourse ) The universal classification, or the set of all things that an interpretation considers to exist. In RDF/S, this is identical to the set of resources.
Use (v.) contrasted with mention ; to use a piece of syntax to denote or refer to something else. The normal way that language is used.
("Whenever, in a sentence, we wish to say something about a certain thing, we have to use, in this sentence, not the thing itself but its name or designation." - Alfred Tarski )
Valid (adj., of an inference or inference process) Corresponding to an entailment , i.e. the conclusion of the inference is entailed by the antecedent of the inference. Also correct .
Well-formed (adj., of an expression). Syntactically legal.
World (n.) (with the: ) (i) The actual world. (with a: )(ii) ) (ii) A way that the actual world might be arranged. (iii) An interpretation (iv) A possible world.
(The metaphysical status of ' possible worlds ' is highly controversial. Fortunately, one does not need to commit oneself to a belief in parallel universes in order to use the concept in its second and third senses, which are sufficient for semantic purposes.)
Appendix D: C: Acknowledgements
This document reflects the joint effort of the members of the RDF Core Working Group . Particular contributions were made by D. Connolly, J. Jeremy Carroll, J. Dan Connolly, Jan Grant, R. V. Guha, G. Graham Klyne, O. Ora Lassilla, B. Brian McBride, S. Sergey Melnick, J. Jos deRoo and P. Patrick Stickler.
The basic idea of using an explicit extension mapping to allow self-application without violating the axiom of foundation was suggested by Christopher Menzel.
Several people found errors in earlier drafts. Peter Patel-Schneider and Herman ter Horst deleted text: suggested improvements to the proofs. Peter Patel-Schneider found several major problems in earlier drafts, and suggested several important technical improvements. 
Patrick Hayes' work on this document was supported in part by DARPA under contract #2507-225-22.

References
Normative
deleted text: [OWL]

Web Ontology Language (OWL) Reference Version 1.0 , Dean, M.,Connolly, D.,van Harmelen, F., Hendler, J.,Horrocks, I., McGuinness, D., Patel-Schneider, P.,Stein, L. (Editors), World Wide Web Consortium Working Draft, 12 November 2002

<a id="ref-rdf-concepts" name="ref-rdf-concepts"> </a> [RDF-CONCEPTS] </dt> <dd> Resource Description Framework (RDF): Concepts and Abstract Syntax , Klyne G., Carroll , G. Klyne, J. (Editors), Carroll, Editors, World Wide Web Consortium, November 2002 (work Consortium Working Draft, work in progress). progress, 10 October 2003. This version of the RDF Concepts and Abstract Syntax is http://www.w3.org/TR/2003/WD-rdf-concepts-20031010/. The latest version of the RDF Concepts and Abstract Syntax is at http://www.w3.org/TR/rdf-concepts/.
[RDF-SYNTAX]
RDF/XML Syntax Specification (Revised) , Beckett D. (Editor), World Wide Web Consortium, November 2002.

Consortium Working Draft, 10 October 2003 (work in progress). This version [RDF-VOCABULARY]

RDF Vocabulary Description Language 1.0: RDF Schema is http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20031010/. The latest version , Brickley D., Guha R.V. (Editors), World Wide Web Consortium, November 2002. is http://www.w3.org/TR/rdf-syntax-grammar/
[RDF-TESTS]
RDF Test Cases , , J. Grant J., Beckett and D. (Editors) Beckett, Editors, World Wide Web Consortium, November 2002. Consortium Working Draft, work in progress, 10 October 2003. This version of the RDF Test Cases is http://www.w3.org/TR/2003/WD-rdf-testcases-20031010/. The latest version of the RDF Test Cases is at http://www.w3.org/TR/rdf-testcases/.
[RDFMS]
Resource Description Framework (RDF) Model and Syntax Specification , , O. Lassila O., Swick and R. R.(Editors), Swick, Editors. World Wide Web Consortium, Consortium. 22 February 1999. This version is http://www.w3.org/TR/1999/REC-rdf-syntax-19990222. The latest version of RDF M&S is available at http://www.w3.org/TR/REC-rdf-syntax.
[RFC 2119]
deleted text: <cite> <a href="http://www.ietf.org/rfc/rfc2119.txt"> RFC 2119 - Key Words words for use in RFCs to Indicate Requirement Levels , S. Bradner, S., IETF. March 1997 1997. This document is http://www.ietf.org/rfc/rfc2119.txt.
[RFC 2396]
RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax Berners-Lee,T., Fielding and Masinter,L., Masinter, L., August 1998
deleted text: [XML-C14N]

Canonical XML , Boyer, J. W3C Recommendation, March 2001.

<a id="ref-xmls" name="ref-xmls"> </a> [XSD] </dt> <dd> <cite> <a href="http://www.w3.org/TR/xmlschema-2/"> XML Schema Part 2: Datatypes </a> </cite>, Biron, P. V., Malhotra, A. (Editors) World Wide Web Consortium Recommendation, 2 May 2001 </dd> </dl> <h2> <a name="nonnormative" id="nonnormative"> Non-Normative </a> </h2> <dl> <dt> [OWL]

Web Ontology Language (OWL) Reference Version 1.0 , Dean, M., Connolly, D., van Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D., Patel-Schneider, P., Stein, L. (Editors), World Wide Web Consortium Working Draft, 12 November 2002

[Conen&Klapsing]
A Logical Interpretation of RDF , Conen, W., Klapsing, R..circulated R..Circulated to RDF Interest Group , August 2000.
[DAML]
Frank van Harmelen, Peter F. Patel-Schneider, Ian Horrocks (editors), Reference Description of the DAML+OIL (March 2001) ontology markup language
[Hayes&Menzel]
A Semantics for the Knowledge Interchange Format , Hayes, P., Menzel, C., Proceedings of 2001 Workshop on the IEEE Standard Upper Ontology , August 2001.
[KIF]
Michael R. Genesereth, Genesereth et. al., Knowledge Interchange Format , 1998 (draft American National Standard).
[Marchiori&Saarela]
Query + Metadata + Logic = Metalog , Marchiori, M., Saarela, J.. J. 1998.
[LBASE]
Lbase: Semantics for Languages of the Semantic Web , Guha, R. V., Hayes, P., November 2002. W3C Note, 10 October 2003.
[McGuinness&al]
DAML+OIL:An Ontology Language for the Semantic Web , McGuinness,D. McGuinness, D. L., Fikes, R., Hendler J. and Stein, L.A., IEEE Intelligent Systems, Vol. 17, No. 5, September/October 2002.
[RDF-PRIMER]
RDF Primer , Manola F., Miller F. Manola, E. (Editors), Miller, Editors, World Wide Web Consortium W3C Working Draft, November 2002. work in progress, 10 October 2003. This version of the RDF Primer is http://www.w3.org/TR/2003/WD-rdf-primer-20031010/. The latest version of the RDF Primer is at http://www.w3.org/TR/rdf-primer/.

[RDF-VOCABULARY]

RDF Vocabulary Description Language 1.0: RDF Schema , D. Brickley, R.V. Guha, Editors, World Wide Web Consortium Working Draft, work in progress, 10 October 2003. This version of the RDF Vocabulary Description Language is http://www.w3.org/TR/2003/WD-rdf-schema-20031010. The latest version of the RDF Vocabulary Description Language is at http://www.w3.org/TR/rdf-schema.

Appendix D: Change Log. (Informative)

Changes since the 5 September 2003 working draft.

The appendix describing the Lbase translation (formerly Appendix A) has been removed, with corresponding minor editoral changes to the text to refer to the Lbase Note. Editorial (wording and notation) changes made to the proof appendix for clarity (following comments by ter Horst ) and also to correct errors found in earlier versions.

Some items (Complete, Decideable) and comments added to the glossary.

The rules in section 7 are no longer considered normative, and a comment has been added to the text concerning implementation strategies. The wording of the text in 7.1 concerning the simple entailment rules has been modified for clarity, in response to email comments by Patel-Schneider , and a pointer added to new text in the Appendix describing and discussing a complete rule set for simple entailment.

Text has been added, with examples, to section 5 to better explain the concept of a datatype clash, following email suggestions by Horrocks and Pan , with corresponding minor wording changes made to section 7. Text has been added to 7.3 after the statement of the RDFS entailment lemma pointing out that it does not apply to inconsistent graphs, with a brief discussion; the proof of the lemma has been rewritten.

Character strings in RDF graphs SHOULD (not MUST) conform to normal form C; (WG decision Oct 3 2003) and the text in section 0.2 has been modified to reflect this.

Several minor errors (typos, broken links, redundant references) have been corrected.

Changes since the 23 January 2003 last call working draft.

1. Editorial.

The following changes do not affect the normative technical content

Many small changes to wording and document organization to improve clarity, remove ambiguities, make definitions clearer, etc. and for conformity with other RDF documents and W3C house style, following review comments by Lech. The definition of 'graph merge' has been rewritten, following review comments by Patel-Schneider and Beckett. The background colors have been changed to avoid red/green confusion and internal links highlighted with background color in the text. Some of the lemmas have been re-stated more economically and the proofs rephrased for clarity. The semantic conditions are now aligned exactly with the vocabularies, so that RDF interpretations exactly constrain the rdf: vocabulary, etc.. Some of the section numbers and titles have been changed to better reflect this realignment. The term 'namespace' has been replaced by 'vocabulary' , cf pfps-21 . The description of reification refers to rdf:ID.

The informative appendices on Lbase and the proof appendix have been extensively rewritten and errors corrected, cf. pfps-02 . Some parallel changes have been made to the Lbase note. The text of the datatypes section been extensively rewritten following technical changes noted below; the older version was ambiguous and contained errors . The XSD datatypes suitable for RDF use are listed explicitly in the text, cf. pfps-01 .

Following email by Patel-Schneider, the possibility of an rdfs-inconsistency has been noted in the text (section 4, end), with an example, a comment added on trivial entailments in section 4.3, and the wording of the rdfs entailment lemma has been restricted to consistent antecedents (section 7.3). This corrects an omission and a consequent error in the text.

2. Technical/editorial.

The following changes do not affect any entailments or test cases.

Lexical and value spaces of datatypes are required to be nonempty, following email comments by Patel-Schneider.

In simple interpretations, IP is no longer required to be a subset of IR in all interpretations.

This does not affect RDF or RDFS interpretations but makes the model theory more conventional and may help with layering future semantic extensions onto RDF. Text has been added to clarify why RDF interpretations are unchanged.

"Vocabulary" is now defined to include typed literals as well as URI references; definition of 'name' changed accordingly.

This is required by the new treatment of datatypes and is more conventional.

The set LV of literal values is no longer considered 'global' but is part of an interpretation.

This is more conventional, makes the semantics easier to state and simplifies the proofs.

RDF lists are no longer required to explicitly give rdf:type rdf:List triples for all sublists. (WG decision recorded http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003May/0199.html ) The wording of the text and examples in section 3.2.3 have been modified to suit.

The definition of rdf-interpretation refers to a 'central' vocabulary.

This avoids a technical awkwardness arising from the infinite container vocabulary.

The reference [RDF_VOCABULARY] is not a normative reference.

(WG decision recorded http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jul/0236 )

3. Substantial.

All the following changes cause changes to some entailments.

1. The treatment of language tags in literals has been simplified. Typed literals, including XML literals, no longer have associated language tags. (WG decision recorded http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003May/0138.html) There are therefore three types of literal: plain without a language tag, plain with a language tag, and typed literals.

XML literals are required to be in canonical form, and to denote entities which are distinct from any character string.(WG decision recorded http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jun/0156.html )

The chief effect of these decisions in this document is that XML literals can be treated uniformly with other typed literals. However, the rdf semantic conditions on rdfs:XMLLiteral are stated without explicit reference to datatypes in order to make it possible for a conforming RDF inference system to avoid full datatyping. The accounts of rdfs:XMLLiteral given for RDF, and for RDF with datatyping, are in exact correspondence. This change is relevant to the last call comments: pfps-02 , pfps-06 , pfps-07 .

2. The treatment of rdfs:subClassOf and rdfs:subPropertyOf has been changed. They are no longer required to satisfy 'iff' semantic conditions, but only to be transitive and reflexive. This decision was taken as a result of the felt need to support simple complete sets of inference rules for RDFS. We are grateful to Herman ter Horst and Peter Patel-Schneider for noticing the complexities which arose from the older conditions, c.f. horst-01 et. seq.. (WG decision recorded http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jul/0025.html )

This has required changes to the RDFS entailment rules table. The older conditions are now explained in informative sections as 'extensional' conditions, and corresponding entailment rules discussed.

3. Plain literals, and literals typed with xsd:string, both denote character strings. (WG decision recorded http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jul/att-0393/rdfcore-2003-07-25-minutes.txt ) The semantics now states explicitly that these are the coextensive in XSD interpretations and describes a corresponding inference rule.

4. The account of datatyped interpretations has been stated relative to a 'datatype map' from URI references to datatypes. This change was introduced after email discussions with Patel-Schneider, cf pfps-08 and pfps-09 et. seq.. The previous treatment was not adequate to support the intended entailments . (WG decision recorded http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003May/0199.html )

5. LV is required to be the class extension of rdfs:Literal in all RDFS interpretations, cf. pfps-06 . This clarifies and rationalizes the treatment of rdfs:Literal and supports the entailments noted in pfps-10 .

6. The rule rdfD4 has been removed: given the change mentioned in 2. above, it was no longer valid. The text notes that it is consistent to assert a subClass relation between datatypes in this case.

RDF Semantics

W3C Working Draft 23 January 10 October 2003

Abstract

Table of Contents

0. Introduction deleted text:

1. Interpretations deleted text:

1.2 Urirefs, resources URI references, Resources and literals Literals .

2. Simple entailment Entailment between RDF graphs deleted text:

vocabulary entailment </i>, i.e. entailment relative to a set of interpretations which satisfy extra semantic conditions on a vocabulary. 2.1 Vocabulary interpretations and vocabulary entailment is more powerful than

<a name="rdfinterp" id="rdfinterp"> 3.1. 3. Interpreting the RDF Interpretations Vocabulary

3.1. RDF entailment

3.2. Reification, containers Containers , collections Collections and rdf:value

3.2.3 RDF collections

3.2.4 rdf:value

3.3 4. Interpreting the RDFS interpretations Vocabulary </h3>

4.1 Extensional Semantic Conditions (Informative)

4.3 RDFS Entailment

3.4 5. Datatyped interpretations

rdf:type rdf:type rdf:Property . 6. Monotonicity of semantic extensions

7. Entailment rules should (Informative)

The rules are all stated with the form add a triple to a graph when it contains triples conforming to a pattern , and they are all deleted text: 4.1 Rdf-entailment </a> <span class="diff-old-a">deleted text: </span> and rdf closures (Informative)

7.1 Simple Entailment Rules

4.2 RDFS-entailment and RDFS closures (informative)

7.2 RDF Entailment Rules

7.3 RDFS Entailment Rules

7.3.1 Extensional Entailment Rules

4.3 7.4 Datatype entailments (Informative) Entailment Rules

Appendix A: Translation into L base (Informative)

L2V(?y,?x) is a term denoting the value Appendix A: Proofs of the lexical form ?y under the L2V mapping Lemmas (Informative)

Appendix B: Proofs of lemmas (informative).

Appendix C: B: Glossary of terms (informative). Terms (Informative)

Appendix D: C: Acknowledgements

Appendix D: Change Log. (Informative)

1. Editorial.

2. Technical/editorial.

3. Substantial.

`rdf:type rdf:type rdf:Property .`
6. Monotonicity of semantic extensions

Appendix A: Translation into L _base (Informative)

`L2V(?y,?x)` is a term denoting the value Appendix A: Proofs of the lexical form ?y under the L2V mapping Lemmas (Informative)