Copyright © © 2003 W3C ® ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark , document use and software licensing rules apply.
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).
<h2 id="status">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/.
This is a W3C Last Call Working Draft of the RDF Core Working Group and has been produced as part of the W3C Semantic Web Activity ( Activity Statement ).
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. </p> <p> In conformance with W3C policy requirements, known patent and IPR constraints associated with this Working Draft are detailed on the RDF Core Working Group Patent Disclosure page.
Comments on this document are invited and should be sent to the public mailing list www-rdf-comments@w3.org . An archive of comments is available at http://lists.w3.org/Archives/Public/www-rdf-comments/ .
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
0.1
Specifying
a
formal
semantics:
scope
and
limitations
0.2
Graph
Syntax
0.3
Graph
Definitions
1.
Interpretations
1.1
Technical
notes
Note
(Informative)
1.2
Urirefs,
resources
URI
references,
Resources
and
literals
Literals
1.3
Interpretations
1.4
Denotations
of
ground
graphs
Ground
Graphs
1.5
Blank
nodes
as
existential
assertions
Existential
variables
2.
Simple
entailment
Entailment
between
RDF
graphs
<a href="#Non-entailment">
2.1
Criteria
for
non-entailment
Vocabulary
interpretations
and
vocabulary
entailment
3.
Interpreting
the
RDF(S)
RDF
vocabulary
<a href="#rdfinterp">
3.1
3.1.
RDF
interpretations
Entailment
3.2
Reification,
containers,
collections
Containers,
Collections
and
rdf:value
3.2.1
Reification
3.2.2
RDF
containers
Containers
3.2.3
RDF
collections
Collections
3.2.4
rdf:value
deleted text:
3.3
4.
Interpreting
the
RDFS
Interpretations
Vocabulary
4.1
Extensional
Semantic
Conditions
(Informative)
3.3.1
4.2
A
note
Note
on
rdfs:Literal
4.3
RDFS
Entailment
3.4
5.
Datatyped
interpretations
Interpretations
<a href="#VocabEntailment">
4.
Vocabulary
entailment
and
closure
rules
5.1
D-Entailment
<a href="#rdf_entail">
4.1.
Rdf-entailment
and
rdf
closures(informative)
6.
Monotonicity
of
Semantic
Extensions
<a href="#rdfs_entail">
4.2.
Rdfs-entailment
and
rdfs
closures(informative)
7.
Entailment
Rules
(Informative)
7.1
Simple
Entailment
Rules
7.2
RDF
Entailment
Rules
7.3
RDFS
Entailment
Rules
<a href="#dtype_entail">
4.3
Datatyped
entailments
(informative)
7.3.1
Extensional
Entailment
Rules
<a href="#Lbase">
Appendix
A.
Translation
into
Lbase(informative)
7.4
Datatype
Entailment
Rules
Appendix
B.
A.
Proofs
of
lemmas
(Informative)
Appendix
C.
Glossary.
B.
Glossary
(Informative)
Appendix
D.
C.
Acknowledgements
References
Appendix
D.
Change
Log
(Informative)
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. </p> <p> 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: </p> <p> 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.
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>. </p> <p> 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: <em> RDF graph </em>. 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.
<p> In this
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:
<em>
not
deleted text:
</em>
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:
Prefix
rdf:
namespace
URI:
http://www.w3.org/1999/02/22-rdf-syntax-ns#
Prefix
rdfs:
namespace
URI:
http://www.w3.org/2000/01/rdf-schema#
Prefix
xsd:
namespace
URI:
http://www.w3.org/2001/XMLSchema#
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>
rdf:type
rdfs:Property
rdfs:Class
.
should be read as an abbreviation for the N-triples N-Triples syntax
<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.
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. </p> <p> <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 <i> merge </i> 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. </p> <p> 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>.
An A ground RDF graph will be said to be <i> ground </i> if it has is one with no blank nodes.
<a name="defvocab" id="defvocab"> We will refer to a set of urirefs as a <i> vocabulary </i>. 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 </i> 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.
Suppose that M is a mapping from a set of blank nodes to some set of literals, blank nodes and urirefs; URI references; then any graph obtained from a graph G by replacing some or all of the blank nodes N in G by M(N) is an instance of G. Note that any graph is an instance of itself, an instance of an instance of G is an instance of G, and if H is an instance of G then every triple in H is an instance of some triple in G.
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> </p> <p> is an A proper instance of </p> <p> <code> _:xxx <ex:b> _:yyy . </code> </p> <p> 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.
<p><a name="defpropinst" id="defpropinst"> A <i> proper </i> instance of a An RDF graph is an lean if it has no instance deleted text: in which at least one blank node has been replaced by is a name. proper subgraph of the graph. The above example Non-lean graphs have internal redundancy and express the same content as their lean subgraphs. For example, the graph
<ex:a>
<ex:p>
_:x
.
_:y
<ex:p>
_:x
.
is not a proper instance. lean , but
<ex:a>
<ex:p>
_:x
.
_:x
<ex:p>
_:x
.
is lean .
<a name="definstvoc" id="definstvoc"> An instance <i> with respect to A merge of a vocabulary </i> 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 ].
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.
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. </p> <p> 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
.
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 .
A simple interpretation I of a vocabulary V is defined by: 1. A non-empty set IR of resources, called the domain or universe of I, which is a superset of LV. I. 2. A distinguished subset IP set IP, called the set of IR. properties of I. 3. A mapping IEXT from IP into the powerset of IR x IR i.e. the set of sets of pairs <x,y> with x and y in IR . 4. A mapping IS from URI references in V into IR (IR union IP) 5. A mapping IL from typed literals in V into IR. 6. A distinguished subset LV of IR, called the set of literal values, which contains at least all character strings and all pairs consisting of a character string and a language tag . |
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"> <i> extension </i> </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. </p> <p> 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.
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.
<div class="c1"> <table cellpadding="5" border="1" summary="rule">In this table, and throughout this document, the equality sign "=" indicates identity.
if E is a plain literal "aaa" then I(E) = aaa |
if E is a plain literal "aaa"@ttt then I(E) = <aaa, ttt> |
if E is a typed literal than from V then I(E) = IL(E) |
if E is a uriref URI reference in V then I(E) = IS(E) |
if
E
is
a
ground
triple
s
p
o
.
s, p and o are in V, I(p) is in IP and <I(s),I(o)> is in IEXT(I(p)), IEXT(I(p)) otherwise I(E)= false. |
if E is a ground RDF graph then I(E) = false if I(E') = false for some triple E' in E, otherwise I(E) =true. |
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.)
IR = LV union{1, 2}; 2}
IP={1}
IEXT:
1->{<1,2>,<2,1>}
1
=>
{<1,2>,<2,1>}
IS:
ex:a
ex:a=>
->1,
1,
ex:b
ex:b=>
->1,
1,
ex:c
ex:c=>
->2
2
IL:
any
typed
literal
->
=>
2
<img src="RDF_MT_figure1.jpg" alt="A drawing of the domains and mappings described in the text" width="495" height="390" />
Figure
1
:
An
example
of
an
interpretation.
Note,
this
is
not
a
picture
of
an
RDF
graph.
The
figure
does
not
show
the
infinite
number
of
members
of
LV.
This interpretation makes these triples true:
<ex:a>
<ex:b>
<ex:c>
.
<ex:c>
<ex:a>
<ex:a>
.
<ex:c>
<ex:b>
<ex:a>
.
<ex:a>
<ex:b>
"whatever"^^<ex:b>
.
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.
It makes these triples false:
<ex:a>
<ex:c>
<ex:b>
.
<ex:a>
<ex:b>
<ex:b>
.
<ex:c>
<ex:a>
<ex:c>
.
<ex:a>
<ex:b>
"whatever"
.
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.
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:
<div class="c1"> <table cellpadding="5" border="1" summary="rule">If E is a blank node then [I+A](E) = A(E) |
If E is an RDF graph then I(E) = true if [I+A'](E) = true for some mapping A' from blank(E) to IR, otherwise I(E)= false. |
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 <i> would </i> 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.) </p> <p> For example, deleted text: with this convention, the graph defined by the following triples is false in the interpretation shown in figure 1:
_:xxx
<ex:a>
<ex:b>
.
<ex:c>
<ex:b>
_:xxx
.
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.
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.
Any process which constructs a graph E from some other graph(s) S is said to be (simply) valid if S entails E, E in every case , otherwise invalid. deleted text: </a> Note that being an invalid process does not mean that the conclusion is false, and being valid does not guarantee truth. However, validity represents the best guarantee that any assertional language can offer: if given true inputs, it will never draw a false conclusion from them.
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]
Subgraph Lemma. A graph entails all its <a href="#defsubg"> subgraphs . [Proof] .
Instance Lemma. A graph is entailed by any of its <a href="#definst"> instances . [Proof]
<p>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 main result for simple RDF inference is:
Interpolation Lemma. S entails a graph E if and only if a subgraph of deleted text: the merge of S is an instance of E. [Proof]
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. </p> <p> Finally, the following is a trival but important consequence of the definition of entailment: </p> <p> <strong> Monotonicity Lemma </strong>. Suppose S is a subgraph of S' and S entails E. Then S' entails E. </p> <h3> <a name="Non-entailment" id="Non-entailment"> 2.1 Criteria for non-entailment </a> </h3> <p> 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: </p> <p> <code> <ex:a> <ex:b> _:xxx . </code> </p> <p> <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 <i> lean </i> 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'. </p> <p> <a name="Anonlem2" id="Anonlem2"> <strong> Anonymity lemma 2. </strong> </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'. </p> <p> 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.
deleted text: <h2> <a name="InterpVocab" id="InterpVocab"> 3. Interpreting the RDF(S) vocabulary </a> </h2>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 <i> a priori </i> 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 <i> a finite graph, then some finite subset S' of S entails E.
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. </p> <p> Another way of expressing this is that any restriction on interpretations <i> decreases </i> graph. To obtain the number full meaning of deleted text: possible ways that an deleted text: interpretation might be a <i> counterexample </i> to E's following from S. </p> <p> 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. </p> <p> 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.
<h3>
</h3>
<p>
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:
RDF vocabulary |
rdf:type
rdf:Property
rdf:XMLLiteral
rdf:nil
rdf:List
rdf:XMLLiteral
rdf:Statement
rdf:subject
rdf:predicate
rdf:object
rdf:first
rdf:rest
rdf:Seq
rdf:Bag
rdf:Alt
rdf:_1
rdf:_2
...
rdf:value
|
The
subset
of
rdfV
consisting
of
the
first
3
items
in
the
above
list,
{
rdf:type
rdf:Property
rdf:XMLLiteral
}
is
called
the
central
RDF
vocabulary
,
crdfV.
rdf-interpretation
s
impose
extra
semantic
conditions
on
crdfV
and
on
typed
literals
with
the
type
rdf:XMLLiteral
,
which
is
referred
to
as
the
RDF
built-in
datatype.
This
datatype
is
fully
described
in
the
RDF
Concepts
and
Abstract
Syntax
document
[
RDF-CONCEPTS
].
Any
character
string
sss
which
satisfies
the
conditions
for
being
in
the
lexical
space
of
rdf:XMLLiteral
will
be
called
a
well-typed
XML
literal
string
.
The
corresponding
value
will
be
called
the
XML
value
of
the
literal.
Note
that
the
XML
values
of
well-typed
XML
literals
are
in
precise
1:1
correspondence
with
the
XML
literal
strings
of
such
literals,
but
are
not
themselves
character
strings
.An
XML
literal
whose
literal
string
is
well-typed
will
be
called
a
well-typed
XML
literal
;
other
XML
literals
will
be
called
ill-typed
.
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 .
<div class="c1"> <table width="80%" border="1" summary="rule">
The
first
condition
forces
every
rdf
interpretation
to
contain
a
thing
denoted
by
rdf:type;
which
will
be
used
as
a
property
to
associate
'type'
values
with
resources.
The
second
condition
could
be
regarded
as
deleted text:
<i>
defining
deleted text:
</i>
IP
to
be
the
set
of
resources
in
the
universe
of
the
interpretation
which
have
the
value
I(
rdf:Property
)
of
the
property
I(
rdf:type
).
Such
subsets
of
the
universe
will
be
central
in
interpretations
of
RDFS.
Note
that
this
condition
requires
IP
to
be
a
subset
of
IR.
The
third
condition
says
requires
that
the
empty
list
object
is
classified
as
being
ill-typed
XML
literals
denote
something
other
than
a
list:
literal
value:
this
is
the
only
formal
condition
will
be
the
standard
way
of
handling
ill-formed
typed
literals.
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.
IR = LV union {1, 2, T , P}; P}
IP = {1, T}
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=>
P
,
rdf:subject=>
1
,
rdf:predicate=>
1
,
rdf:object=>
1
,
rdf:first=>
1
,
rdf:rest=>
1
,
rdf:Seq=>
P
,
rdf:Bag=>
P
,
rdf:Alt=>
P
,
rdf:_1,
rdf:_2,
...
=>
1
Figure
2
:
An
deleted text:
example
of
an
rdf-interpretation.
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.
<p> TheS 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
rdf:type
rdf:type
rdf:Property
.
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.
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: <em> not deleted text: </em> 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 <em> RDF vocabulary, </em> 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.
RDF reification vocabulary |
rdf:Statement
rdf:subject
rdf:predicate
rdf:object
|
Semantic extensions MAY limit the interpretation of these so that a triple of the form
aaa
rdf:type
rdf:Statement
.
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.
<ex:a>
<ex:b>
<ex:c>
.
and
_: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
aaa bbb ccc .
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.
</p>
<p>
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:
<i>
particular
deleted text:
</i>
<em>
token
or
instance
deleted text:
</em>
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>
.
does not entail
_:yyy
<ex:property>
<ex:foo>
.
RDF Container Vocabulary |
rdf:Seq
rdf:Bag
rdf:Alt
rdf:_1
rdf:_2
...
|
RDF provides vocabularies for describing three classes of <em> containers </em>. 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.
deleted text: <div class="c1"> <table width="60%" border="1" summary="container vocabulary"> <tbody> <tr> <td> <strong> RDF Container Vocabulary </strong> </td> </tr> <tr> <td> <code> rdf:Seq rdf:Bag rdf:Alt rdf:_1 rdf:_2 ... </code> </td> </tr> </tbody> </table> </div>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,
_:xxx
rdf:type
rdf:Bag
.
_:xxx
rdf:_1
<ex:a>
.
_:xxx
rdf:_2
<ex:b>
.
does not entail
_:xxx
rdf:_1
<ex:b>
.
_:xxx
rdf:_2
<ex:a>
.
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
_:xxx
rdf:type
rdf:Seq.
_:xxx
rdf:_1
<ex:a>
.
_:xxx
rdf:_3
<ex:c>
.
does not entail
_:xxx
rdf:_2
_:yyy
.
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.
RDF Collection Vocabulary |
rdf:List
rdf:first
rdf:rest
rdf:nil
|
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.
deleted text: <div class="c1"> <table width="60%" border="1" summary="container vocabulary"> <tbody> <tr> <td> <strong> RDF Collection Vocabulary </strong> </td> </tr> <tr> <td> <code> rdf:List rdf:first rdf:rest rdf:nil </code> </td> </tr> </tbody> </table> </div>
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:
</p>
<p>
_: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:
</p>
<p>
_: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 />
does not entail
_: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
.
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.
RDF Schema [ RDFSchema RDF-VOCABULARY ] extends RDF to include a larger vocabulary rdfsV with more complex semantic constraints:
RDFS vocabulary |
rdfs:domain
rdfs:range
rdfs:Resource
rdfs:Literal
rdfs:Datatype
rdfs:Class
rdfs:subClassOf
rdfs:subPropertyOf
rdfs:member
rdfs:Container
rdfs:ContainerMembershipProperty
rdfs:comment
rdfs:seeAlso
deleted text:
</code>,
<code>
rdfs:isDefinedBy
rdfs:label
|
(
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>:
</p>
<p>
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>.
</p>
<p>
<a id="rdfsinterpdef" name="rdfsinterpdef">
</a>
An
<i>
rdfs-interpretation
</i>
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
).
x
is
in
ICEXT(y)
iff
if
and
only
if
<x,y>
is
in
IEXT(I(
IC
=
ICEXT(I(
IR
=
ICEXT(I(
LV
=
ICEXT(I(
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If
<x,y>
is
in
IEXT(I(
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If
<x,y>
is
in
IEXT(I(
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<x,y>
is
in
IEXT(I(
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If
<x,y>
is
in
IEXT(I(
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If
x
is
in
ICEXT(I(
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ICEXT(I( |
If
<x,y>
is
in
IEXT(I(
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
IC contains: |
I(
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
IP contains: |
I(
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If
x
is
in
ICEXT(I(
|
|
rdfs:subPropertyOf
rdf:type
rdfs:domain
rdf:Property
rdfs:Resource
.
deleted text:
<br />
<span class="diff-old-a">deleted text: </span>
rdfs:subClassOf
rdfs:domain
rdfs:Class
rdfs:domain
rdf:Property
.
deleted text:
<br />
rdfs:domain
rdfs:range
rdfs:domain
rdf:Property
.
deleted text:
<br />
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>
<br />
<span class="diff-old-a">deleted text: </span>
rdf:predicate
rdfs:domain
rdf:Statement
.
<span class="diff-old-a">deleted text: </span>
<br />
<span class="diff-old-a">deleted text: </span>
rdf:object
rdfs:domain
rdf:Statement
.
<span class="diff-old-a">deleted text: </span>
<br />
rdfs:member
rdfs:domain
rdfs:Resource
.
<br />
<span class="diff-old-a">deleted text: </span>
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:
<br />
rdfs:subClassOf
rdfs:comment
rdfs:domain
rdfs:Resource
.
<br />
<span class="diff-old-a">deleted text: </span>
rdfs:domain
rdfs:range
rdfs:Class
.
<span class="diff-old-a">deleted text: </span>
<br />
<span class="diff-old-a">deleted text: </span>
rdfs:range
rdfs:range
rdfs:Class
.
<span class="diff-old-a">deleted text: </span>
<br />
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>
<br />
<span class="diff-old-a">deleted text: </span>
rdfs:label
rdfs:range
rdfs:Literal
.
<span class="diff-old-a">deleted text: </span>
<br />
rdf:rest
rdf:value
rdfs:range
rdf:List
rdfs:Resource
.
deleted text:
<br />
<br />
<span class="diff-old-a">deleted text: </span>
rdf:Alt
rdfs:subClassOf
rdfs:Container
.
<span class="diff-old-a">deleted text: </span>
<br />
<span class="diff-old-a">deleted text: </span>
rdf:Bag
rdfs:subClassOf
rdfs:Container
.
<span class="diff-old-a">deleted text: </span>
<br />
<span class="diff-old-a">deleted text: </span>
rdf:Seq
rdfs:subClassOf
rdfs:Container
.
<span class="diff-old-a">deleted text: </span>
<br />
<span class="diff-old-a">deleted text: </span>
rdfs:ContainerMembershipProperty
rdfs:subClassOf
rdfs:Property
rdf:Property
.
deleted text:
<br />
<br />
<span class="diff-old-a">deleted text: </span>
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>
<br />
rdf:XMLLiteral
rdfs:subClassOf
rdfs:Literal
.
<br />
<span class="diff-old-a">deleted text: </span>
<br />
<span class="diff-old-a">deleted text: </span>
rdf:_1
rdf:type
rdfs:ContainerMembershipProperty
.
<span class="diff-old-a">deleted text: </span>
<br />
rdf:_1
rdfs:domain
rdfs:Resource
.
rdf:_2 rdfs:domain rdfs:Resource . rdf:_2 rdfs:range rdfs:Resource . ... |
rdfs:Resource
rdf:type
deleted text:
and
objects
rdfs:Class
.
and
rdfs:Property
respectively.
Since
ICEXT(I(
|
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 .
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:
<x,y>
is
in
IEXT(I(
|
|
<x,y>
is
in
IEXT(I(
|
|
<x,y>
is
in
IEXT(I(
| |
<x,y>
is
in
IEXT(I(
|
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 .
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.
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.
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 <span class="diff-old-a">deleted text: </span> 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:
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 RulesThe 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.
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
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
by
se2
using
the
proof
method.
<ex:c>
<ex:q>
_:x
.
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
by
se2
using
a
non-canonicalized
XML
literal.
In
practice,
new
_:x
<ex:p>
_:y
.
_: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
)
RDFS closures require more complex
Applying these rules to reflect the consequences of the more elaborate semantic constraints on the rdfs vocabulary.
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 .
Rule Name | if E contains | then add |
rdf1 |
xxx
aaa
yyy
.
|
aaa
rdf:type
rdfs:range
rdfs:Class
rdf:Property
.
|
rdf2 |
xxx
aaa
lll
|
xxx
aaa
|
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)
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
where
| ||
rdfs2 | deleted text:
xxx
aaa
yyy
|
xxx
rdf:type
zzz
.
| ||
rdfs3 | deleted text:
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
|
aaa
rdfs:subPropertyOf
ccc
.
| ||
rdfs5b rdfs6 |
xxx
rdf:type
rdf:Property
.
|
xxx
rdfs:subPropertyOf
xxx
.
| ||
rdfs6 rdfs7 | deleted text:
xxx
aaa
yyy
|
xxx
bbb
yyy
.
| ||
rdfs7a rdfs8 |
xxx
|
xxx
rdfs:subClassOf
rdfs:Resource
.
| ||
rdfs7b rdfs9 |
xxx
|
aaa
rdf:type
yyy
.
|
||
rdfs10 |
xxx
rdf:type
rdfs:Class
.
|
xxx
rdfs:subClassOf
xxx
.
| ||
rdfs8 rdfs11 |
xxx
|
xxx
rdfs:subClassOf
zzz
.
| ||
rdfs9 rdfs12 | deleted text:
xxx
<code>
<span class="diff-old-a">deleted text: </span>
rdfs:subClassOf
yyy
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
.
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.
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.
rdfs
2a
extensional
versions
of
the
RDFS
semantic
conditions.
Here,
ttt
and
uuu
are
any
legal
language
tags
and
ddd
is
anything
other
than
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:
|