Abstract
This document describes a precise semantics for the Resource Description
Framework 1.1 [RDF-PRIMER] and RDF Schema [RDF-SCHEMA]. It defines a number of distinct entailment regimes and corresponding systems of inference rules. It is part of a suite of documents which comprise the full specification of RDF 1.1.
This is a revision of the 2004 RDF Semantics specification for RDF
[RDF-MT] and supersedes that document.
Status of This Document
This section describes the status of this document at the time of its publication. Other
documents may supersede this document. A list of current W3C publications and the latest revision
of this technical report can be found in the W3C technical reports
index at http://www.w3.org/TR/.
This is a revision of the 2004 Semantics specification for RDF
[RDF-MT] and supersedes that document.
This document was published by the RDF Working Group as a First Public Working Draft.
This document is intended to become a W3C Recommendation.
If you wish to make comments regarding this document, please send them to
public-rdf-comments@w3.org
(subscribe,
archives).
All comments are welcome.
Publication as a First Public Working Draft does not imply endorsement by the W3C Membership.
This is a draft document and may be updated, replaced or obsoleted by other documents at
any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the
5 February 2004 W3C Patent Policy.
W3C maintains a public list of any patent disclosures
made in connection with the deliverables of the group; that page also includes instructions for
disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains
Essential Claim(s) must disclose the
information in accordance with section
6 of the W3C Patent Policy.
Notes
Notes in this style indicate changes from the 2004 RDF semantics.
Notes in this style are technical asides on obscure or recondite matters.
1. Introduction
This document defines a model-theoretic semantics for RDF graphs and the RDF and RDFS vocabularies, providing an exact formal specification of when truth is preserved by transformations of RDF, or operations which derive RDF content from other RDF. Readers who are unfamiliar with model theory can find a brief introduction to the basic ideas and terminology in Appendix A, and may find the informative section 13 useful.
This specification is normative for RDF formal semantics. However, there are many aspects of RDF meaning which are not covered by this semantics, including social issues of how IRIs are assigned meanings in use, and how the referents of IRIs are related to Web content expressed in other media such as natural language texts. Accounts of such extended notions of meaning will go beyond this specification, but MUST NOT violate the conditions described here.
2. Semantic extensions and entailment regimes
RDF is intended for use as a base notation for a variety of extended notations such as OWL [OWL2-OVERVIEW] and RIF [RIF-OVERVIEW], whose expressions can be encoded as RDF graphs which use a particular vocabulary with a specially defined meaning. Also, particular IRI vocabularies may impose user-defined meanings upon the basic RDF meaning rules. When such extra meanings are assumed, a given RDF graph may support more extensive entailments than are sanctioned by the basic RDF semantics. In general, the more assumptions that are made about the meanings of IRIs in an RDF graph, the more valid entailments it has.
A particular such set of semantic assumptions is called a semantic extension. Each semantic extension defines an entailment regime of entailments which are valid under that extension. RDFS, described later in this document, is one such semantic extension. We will refer to an entailment regime by names such as rdfs-entailment, D-entailment, etc..
Semantic extensions MAY impose special syntactic conditions or restrictions upon RDF graphs, such as requiring certain triples to be present, or prohibiting particular combinations of IRIs in triples, and MAY consider RDF graphs which do not conform to these conditions to be errors. For example, RDF statements of the form
:a rdfs:subClassOf owl:Thing .
are prohibited in the OWL-DL [OWL2-SYNTAX] semantic extension. In such cases, basic RDF operations such as taking a subset of triples, or merging RDF graphs, may cause syntax errors in parsers which recognize the extension conditions. None of the semantic extensions normatively defined in this document impose syntactic restrictions on RDF graphs.
All entailment regimes MUST be monotonic extensions of the simple entailment regime described in the next section, in the sense that if A simply entails B then A also entails B under any extended notion of entailment, provided of course that any syntactic conditions of the extension are also satisfied. Put another way, a semantic extension cannot "cancel" an entailment made by a weaker entailment regime, although it can treat the result as a syntax error.
3. Notation and terminology
Issue 1
This section needs cleaning up. Some of the 2004 definitions may no longer be needed. The notions of instance and equivalence may (?) need to be stated more carefully taking bnode scopes into account. Instance mappings should be defined on a whole scope rather than a graph (?). The definitions involving bnode scopes and complete graphs are new.
Maybe some of the material should be in Concepts.
This document uses the terminology //list terms// defined in //Concepts// for describing RDF graph syntax.
Throughout this document, precise semantic conditions will be set out in tables
which state semantic conditions, tables containing true assertions and valid inference rules, and tables listing syntax. These tables, which
are distinguished by background color, amount
to a formal summary of the entire semantics.
Throughout this document, the equality sign = indicates
identity. The statement "A = B" means that there is one entity which both expressions "A" and "B" refer to. Angle brackets < x, y > are used to indicate an ordered pair
of x and y. RDF graph syntax is indicated using the notational conventions of
the N-Triples syntax described
in the Turtle Working Draft [TURTLE-TR]
literal strings are enclosed within double quote marks and attached to a type IRI using a double-caret ^^, language tags indicated
by the use of the @ sign, and triples terminate with a 'code dot'
. .
In stating general rules or conditions we will use the following conventions:
sss or ttt indicates a Unicode character string;
aaa or bbb indicates an IRI
lll or mmm indicates a literal
_:xxx or _:yyy indicates a blank node.
A name is any IRI or literal. A vocabulary is a set of names.
An RDF
graph, or simply a graph, is a set of RDF triples.
A subgraph of an RDF graph is a subset
of the triples in the graph. A triple is identified with the singleton set
containing it, so that each triple in a graph is considered to be a subgraph.
A proper subgraph is a proper subset of the triples in the graph.
A ground RDF graph is one with no blank
nodes.
A name is an IRI or a literal.
Note that a typed literal comprises
two names: itself and its internal type
IRI.
A vocabulary is a set of names. The vocabulary of a graph is
the set of names which occur as the subject, predicate or object of any triple
in the graph. IRIs which occur only inside typed literals
are not required to be in the vocabulary of the graph.
Suppose that M is a functional mapping from a set of blank
nodes to some set of literals, blank nodes and IRIs. 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. 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 at least one triple
in G.
An instance with respect to a vocabulary
V is an instance in which all the
names in the instance that were substituted
for blank nodes in the original are names
from V.
A proper instance of a graph
is an instance in which a blank node has been replaced by a name, or two blank
nodes 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 node
not in the original graph is an instance of the original and 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. Two such 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 equivalent. Equivalent graphs are mutual instances with an invertible instance
mapping. As blank nodes have no particular identity beyond their location in a graph, we will often treat such equivalent graphs as identical.
Any set of graphs can be treated as a single graph simply by taking the union of the sets of triples. If two or more of the graphs share a blank node it will retain its identity when the union graph is formed. Graphs can share blank nodes only if they are derived from graphs described by documents or surface structures which share a single scope for blank node identifiers.
Issue 2
The Concepts document does not yet define blank node identifier scopes.
We will refer to this process of forming the union of graphs as merging, and to the union graph as the merge of the original graphs. A merge may be represented by a new document or datastructure, or may be treated as a conceptual entity when processing RDF.
The 2004 RDF 1.0 specification defined a process of 'standardizing apart' blank nodes to distinguish graph unions from graph merges. Standardizing apart blank node identifiers may still be needed at a concrete syntax level, but is no longer part of the underlying conceptual model of RDF. The earlier terminology is retained to avoid confusion, but now 'merging' simply means 'taking the union' at the graph syntax level.
An RDF graph is lean if it has no instance which is
a proper subgraph of the graph. 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 lean, but
<ex:a> <ex:p> _:x .
_:x <ex:p> _:x .
is lean.
4. Simple Interpretations
A simple interpretation I is a structure consisting of:
Definition of a simple interpretation.
1. A non-empty set IR of resources, called the domain or universe
of I.
2. A set IP, called the set of 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 IRIs into (IR union IP)
5. A partial mapping IL from literals into IR
|
The 2004 RDF 1.0 semantics defined interpretations relative to a vocabulary.
In the 2004 RDF 1.0 semantics, IL was a total, rather than partial, mapping.
The 2004 RDF 1.0 specification divided literals into 'plain' literals with no type and optional language tags, and typed literals. Usage has shown that it is important that every literal have a type. RDF 1.1 replaces plain literals without language tags by literals typed with the XML Schema string datatype, and introduces the special type rdf:langString for language-tagged strings. The full semantics for typed literals is given in the next section.
Interpretations are required to interpret all names, and are therefore infinite. This simplifies the exposition. However, RDF can be interpreted using finite structures, supporting decidable algorithms. Details are given in Appendix ///.
IEXT(x), called
the extension of x, is a
set of pairs which identify the arguments for which the property is true,
that is, a binary relational extension.
The distinction between IR and IL will become significant below when the semantics of datatypes are defined. IL is allowed to be partial because some literals may fail to have a referent. However, IL is total on language-tagged strings and literals of type xsd:string.
It is conventional to map a relation name to a relational extension directly. This however presumes that the vocabulary is segregated into relation names and individual names, and RDF makes no such assumption. Moreover, RDF allows an IRI to be used as a relation name applied to itself as an argument. Such self-application structures are used in RDFS, for example. The use of the IEXT mapping to distinguish the relation as an object from its relational extension accommodates both of these requirements. It also provides for a more intuitive notion of RDFS 'class' which can be distinguished from its set-theoretic extension.
The denotation of a ground RDF graph in I is then given by the following
rules
Semantic conditions for ground graphs.
| if E is a literal then I(E) = IL(E) |
| if E is an IRI then I(E) = IS(E) |
if E is a ground triple s p o.
then I(E) = true if
I(p) is in IP and the pair <I(s),I(o)>
is in 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 IL(E) is undefined for some literal E, then E has no semantic value, so any triple containing it will be false, so any graph containing that triple will also be false.
The final condition implies that the empty graph (empty set of triples) is always true.
The sets IP and IR may overlap, indeed IP can be a subset of IR. Because of the domain conditions on IEXT, the denotation of the subject and object of any true triple will be in IR; so any IRI which occurs in a graph both as a predicate and as a subject or object will denote something in the intersection of IP and IR.
Blank Nodes
Blank nodes are treated as simply indicating the existence of a thing, without using an IRI to identify any particular thing. They play a similar role to existentially quantified variables in a conventional logical notation. This is not the same as assuming that the blank node indicates an 'unknown' IRI.
Suppose I is an interpretation and A is a mapping from a set of blank nodes to the universe IR of I. Define the mapping [I+A] to be I on names, and A on blank nodes on the set: [I+A](x)=I(x) when x is a name and [I+A](x)=A(x) when x is a blank node; and extend this mapping to triples and RDF graphs using the rules given above for ground graphs.
Semantic condition for blank nodes.
| If E is an RDF graph then I(E) = true if [I+A](E) =
true for some mapping A from the set of blank nodes in E to IR, otherwise
I(E)= false. |
Mappings from blank nodes to referents are not part of the definition of an interpretation, since the truth condition refers only to some such mapping. Blank nodes themselves differ from other nodes in not being assigned a denotation by an interpretation, reflecting the intuition that they have no 'global' meaning outside the scope in which they occur.
Intuitive summary
An RDF graph is true exactly when:
1. the IRIs and literals in subject or object position in the graph all refer to things,
2. there is some way to interpret all the blank nodes in the scope as referring to things,
3. the IRIs in property position identify binary relationships,
4. and, under these interpretations, each triple S P O in the graph asserts that the thing referred to as S, and the thing referred to as O, do in fact stand in the relationship identified by P.
All semantic extensions of any vocabulary or higher-level notation encoded in RDF MUST conform to these minimal truth conditions. Other semantic extensions may extend and add to these, but they MUST NOT over-ride or negate them.
5. Simple Entailment
Issue 3
Should the 'explanatory' material in here be moved to the tutorial appendix?
Following standard terminology, we say that I satisfies E when I(E)=true, and a set
S of RDF graphs simply entails a graph E when every interpretation
which satisfies every member of S also satisfies E. This means that it is always correct to infer E from S, even when one does not know what the names in the vocabulary actually mean. In later sections these notions will be adapted to other classes of interpretations, but throughout this section 'entailment' should be interpreted as meaning simple entailment.
Any process which constructs a graph E from
some other graph(s) S is said to be (simply) valid if S
simply entails E in every case, otherwise invalid.
The fact that an inference is valid should not be understood as meaning that the inference must be made, or that any process is obliged or required to make the inference; and similarly, the logical invalidity of some RDF transformation or process does not mean that the process is incorrect or prohibited. Nothing in this specification requires or prohibits any particular operations to be applied to RDF graphs. Entailment and validity are concerned solely with establishing the conditions on operations which guarantee the preservation of truth. While logically invalid processes, which do not follow valid entailments, are not prohibited, users should be aware that they may be at risk of introducing falsehoods and errors into otherwise correct RDF data. Nevertheless, particular uses of logically invalid processes may be justified and appropriate for data processing under circumstances where truth can be ensured by other means.
Entailment refers only to the truth of RDF graphs, not to their suitability for any other purpose. It is possible for an RDF graph to be fitted for a given purpose and yet validly entail another graph which is not appropriate for the same purpose. An example is the RDF test cases manifest [RDF-TESTCASES] which is provided as an RDF document for user convenience. This document lists examples of correct entailments by describing their antecedents and conclusions. Considered as an RDF graph, the manifest validly entails a subgraph which omits the antecedents, and would therefore be incorrect if used as a test case manifest. This is not a violation of the RDF semantic rules, but it shows that the property of "being a correct RDF test case manifest" is not preserved under RDF entailment, and therefore cannot be described as an RDF semantic extension. Such entailment-risky uses of RDF should be restricted to cases, as here, where it is obvious to all parties what the intended special restrictions on entailment are, in contrast with the more normal case of using RDF for the open publication of data on the Web.
Some basic properties of simple entailment.
The properties described here apply only to simple entailment, not to extended notions
of entailment introduced in later sections. Proofs
are given in Appendix B.
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) to (exists (x) foo(x) ) . The first corresponds to taking a subgraph of a graph, the second to replacing an IRI or literal with a blank node.
Empty Graph Lemma. The empty set of triples is entailed by
any graph, and does not entail any graph except itself.
Subgraph Lemma. A graph
entails all its subgraphs.
Instance Lemma. A graph
is entailed by any of its instances.
Obviously, the union of a set of graphs entails every member of the set, since they are all subgraphs of the union. However, if two or more graphs in the set share a blank node. then the set may fail to entail the union. For example, consider the graphs
:a :p _:x .
and
:b :p _:x .
Both graphs can be satisfied by an interpretation which does not satisfy their union, e.g. one with
IEXT(I(:p)) = {< I(:a),I(:a) >, < I(:b),I(:b) > }. This is because the mapping _:x/I(:a) works for the first graph, and the mapping _:x/I(:b) for the second graph, but there is no mapping which works for the combination. Neither graph is obliged to consider the full set of constraints on the blank node that are represented by their union.
Say that a set S of graphs is segregated when no two graphs in the set share a blank node.
Merging lemma. The union
of a segregated set S of RDF graphs is entailed by S, and entails every member of S.
This means that a segregated set of graphs can be treated as equivalent to its
merge, a single graph, as far as the model theory is
concerned. In general, we will not usually bother to distinguish between a set of graphs and the single graph formed by taking their union.
The main result for simple entailment is:
Interpolation Lemma.
S entails a graph E if and only if a subgraph of S is an instance of E.
The interpolation lemma completely characterizes simple entailment in syntactic
terms. To tell whether a set of RDF graphs simply entails another, check that
there is some instance of the entailed graph which is a subset of the merge
of the original set of graphs.
This is clearly decidable, but it is also theoretically very hard in general, since one can encode the NP-hard subgraph problem (detecting whether one mathematical graph is a subgraph of another) as detecting simple entailment between RDF graphs. (///Refer to Jeremy Carroll.///)
Anonymity lemma. Suppose
E is a lean graph and E' is a proper instance of E. Then E does
not entail E'.
Monotonicity
Lemma. Suppose S is a subgraph of S' and S entails E. Then S' entails E.
Compactness Lemma.
If S entails E and E is a finite graph, then some finite subset S' of S entails E.
6. Skolemization
Skolemization is a transformation on RDF graphs which eliminates blank nodes by replacing them with "new" IRIs, which means IRIs which are coined for this purpose and are therefore guaranteed to not occur in any other RDF graph (at the time of creation). See ///Concepts#/// for a fuller discussion.
Suppose G is a graph containing blank nodes and sk is a skolemization mapping on the blank nodes in G, so that sk(G) is a skolemization of G. Then the semantic relationship between them can be summarized as follows.
1. sk(G) simply entails G (by the instance lemma, since sk(G) is an instance of G)
2. G does not entail sk(G).
3. For any graph H, if sk(G) entails H then there is a graph H' such that G entails H' and H=sk(H') .
4. For any graph H which does not contain any of the "new" IRIs introduced into sk(G), sk(G) simply entails H if and only if G simply entails H.
The second property means that a graph is not equivalent to its skolemization, so we cannot simply identify them. Nevertheless, they are in a strong sense almost interchangeable, as the next two properties attest. The third property means that even when conclusions are drawn from the skolemized graph which do contain the new vocabulary, these will exactly mirror what could have been derived from the original graph with the original blank nodes in place. The replacement of blank nodes by IRIs does not effectively alter what can be validly derived from the graph, other than by giving new names to what were formerly anonymous entities. The fourth property, which is a consequence of the third, clearly shows that in some sense a skolemization of G can "stand in for" G as far as entailments are concerned. Using sk(G) instead of G will not affect any entailments which do not involve the new skolem vocabulary.
Skolemization means that it is possible to use RDF without using blank nodes without losing any real expressivity. Opinions differ on the merits of this strategy.
7. Literals and datatypes
In the 2004 RDF 1.0 specification, datatype D-entailment was defined as a semantic extension of RDFS-entailment. Here it is defined as a direct extension to basic RDF. This is more in conformity with actual usage, where RDF with datatypes is widely used without the RDFS vocabulary. If there is a need to distinguish this from the 2004 RDF 1.0 terminology, the longer phrasing "simple D-entailment" or "simple datatype entailment" should be used rather than "D-entailment".
RDF literals and datatypes are fully described in [RDF11-CONCEPTS]. In summary: RDF literals are either language-tagged strings, or datatyped literals which
combine a string and an IRI identifying a datatype. A datatype is understood to define a partial mapping, called the lexical-to-value mapping, from character strings to values, and the literal refers to the value obtained by applying this mapping to the character string. If the mapping gives no value for the literal string, then the literal has no referent. The value space of a datatype is the range of the lexical-to-value mapping. Every literal with that type either refers to a value in the value space, or fails to refer at all. An ill-typed literal is one whose datatype IRI is recognized, but whose character string is not in the domain of the datatype lexical-to-value mapping. Datatypes are indicated by IRIs.
Interpretations will vary according to which IRIs they recognize as denoting datatypes. We describe this using a parameter D on interpretations. where D is a set of IRIs that constitute the recognized datatype IRIs. IRIs listed in ///Concepts Section 5/// MUST be interpreted as described there, and the IRI rdf:plainLiteral MUST be interpreted to refer to the datatype defined in [RDF-PLAINLITERAL]. When other datatypes are used, the mapping between a recognized IRI and the datatype it refers to MUST be specified unambiguously, and be fixed during all RDF transformations or manipulations.
Language-tagged strings are an exceptional case which are given a special treatment. The IRI rdf:langString is classified as a datatype IRI, and interpreted to refer to a datatype, even though no L2V mapping is defined for it. The value space of rdf:langString is the set of all pairs of a string with a language tag. The semantics of literals with this as their type are given below. (If datatype L2V mappings were defined on pairs of lexical values rather than strings, then the L2V mapping for rdf:langString would be the identity function on pairs of the form < unicode string, language tag >. But as they are not, we simply list this as a special case.)
Issue 4
This will require alignment with Concepts. rdf:langString may have an L2V mapping which is ignored by the semantics. Concepts currently states that it is not a datatype even though the IRI is a datatype IRI.
RDF literal syntax allows any IRI to be used in a typed literal, even when it does not identify a datatype. Literals with an "unknown" datatype IRI which is not in the set of recognized datatypes, are treated like IRI names and assumed to denote some thing in the universe IR.
8. D-interpretations and datatype entailment
Let D be a set of IRIs identifying datatypes. A (simple) D-interpretation is a simple interpretation which satisfies the following conditions:
Semantic conditions for datatyped literals.
If rdf:langString is in D, then for every language-tagged string E with lexical form sss and language tag ttt, IL(E)= < sss, ttt > |
| For every other IRI aaa in D, and every literal "sss"^^aaa, IL("sss"^^aaa) = L2V(I(aaa))(sss) |
If the literal is ill-typed then the L2V mapping has no value, and so the literal cannot denote anything. In this case, any triple containing the literal must be false. Thus, any triple, and hence any graph, containing an ill-typed literal will be D-inconsistent, i.e. false in every D-interpretation. This applies only to datatype IRIs in D; literals with "unknown" datatypes are not ill-typed and do not produce a D-inconsistency.
Datatype entailment
A graph is (simply) D-satisfiable when it has the value true in some D-interpretation, and a set S of graphs (simply) D-entails a graph G when every D-interpretation which makes S true also D-satisfies G.
Unlike the case with simple interpretations, it is possible for a graph to have no satisfying D-interpretations, i.e. to be D-unsatisfiable. A D-unsatisfiable graph D-entails any graph.
In all of this language, 'D' is being used as a parameter to represent some set of datatype IRIs, and different D sets will yield different notions of satisfiability and entailment. The more datatypes are recognized, the stronger is the entailment, so that if D ⊂ E and S E-entails G then S must D-entail G. Simple entailment is { }-entailment, i.e. D-entailment when D is the empty set. If S D-entails G then S simply entails G, but not the reverse.
Several of the basic properties of simple entailment are also true for D-entailment, but the interpolation lemma is not true for D-entailment, since D-entailments
can hold because of particular properties of the lexical-to-value mappings of the recognized datatypes. For example, if D contains xsd:integer then
aaa ppp "00025"^^xsd:integer .
D-entails
aaa ppp "25"^^xsd:integer .
Ill-typed literals are the only form of simple D-contradiction, but datatypes can give rise to a variety of other contradictions when combined with the RDFS vocabulary, defined later.
9. RDF-D Interpretations and RDF entailment
RDF-D interpretations impose extra semantic conditions on xsd:string and part of the infinite
set of IRIs in the rdf: namespace.
An rdf-D-interpretation I is a D-interpretation where D includes rdf:langString and xsd:string, and which satisfies:
RDF semantic conditions.
and satisfies every triple in the following infinite set:
RDF axioms.
rdf:type rdf:type rdf:Property .
rdf:subject rdf:type rdf:Property .
rdf:predicate rdf:type rdf:Property .
rdf:object rdf:type rdf:Property .
rdf:first rdf:type rdf:Property .
rdf:rest rdf:type rdf:Property .
rdf:value rdf:type rdf:Property .
rdf:nil rdf:type rdf:List .
rdf:_1 rdf:type rdf:Property .
rdf:_2 rdf:type rdf:Property .
...
|
No other semantic constraints are imposed upon rdf-D-interpretations, so RDF imposes no particular normative meanings on the rest of the RDF vocabulary. Some consequences of this are discussed in Appendix C
An rdf-interpretation, or RDF interpretation, is an rdf-{rdf:langString, xsd:string }-interpretation, i.e. an rdf-D-Interpretation with a minimal set D. The datatypes rdf:langString and xsd:string MUST be recognized by all RDF interpretations.
The RDF built-in datatypes rdf:XMLLiteral and rdf:HTML are defined in [RDF11-CONCEPTS]. RDF interpretations are not required to recognize these datatypes.
RDF entailment
S rdf-D-entails E when every rdf-D-interpretation which satisfies every
member of S also satisfies E.
The lemmas for simple entailment do not all apply to rdf-D-entailment:
for example, all the rdf axioms are true in every rdf-interpretation, so are rdf-D-entailed by the empty graph,
contradicting the interpolation lemma for rdf-D-entailment. Section //// gives rules that can be used to detect RDF entailment between RDF graphs.
The last semantic condition in the above table gives entailments of this form for recognized datatypes:
aaa ppp "123"^^xsd:integer .
rdf-{xsd:integer}-entails
aaa ppp _:x .
_:x rdf:type xsd:integer .
10. RDFS Interpretations and RDFS entailment
RDF Schema [RDF-SCHEMA]
extends RDF to a larger vocabulary
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 rdfs:isDefinedBy
rdfs:label |
(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:range
and rdfs:subPropertyOf. Other than this, the formal semantics does
not constrain their 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,
and the set of all classes in an interpretation will be called IC.
The semantic conditions are stated in terms of a mapping ICEXT (for the Class
Extension in I) from IC to the set of subsets of IR.
A class may have an
empty class extension. Two different classes can have the same class extension.
The class extension of rdfs:Class contains the class rdfs:Class.
An rdfs-D-interpretation is an rdf-D-interpretation I
which satisfies the semantic conditions in the following table, and satisfies all the triples in the subsequent table of RDFS axiomatic triples. As before, an rdfs-interpretation, or RDFS interpretation, is an rdfs-D-interpretation with D= {xsd:string, rdf:langString }.
Issue 5
This table has redundancies. I am inclined to leave them alone, as it takes quite a lot of thought to figure out some of the consequences when we only give non-redundant conditions.
RDFS semantic conditions.
| ICEXT(y) is defined to be { x : < x,y > is in IEXT(I(rdf:type)) }
IC is defined to be ICEXT(I(rdfs:Class))
LV is defined to be ICEXT(I(rdfs:Literal))
ICEXT(I(rdfs:Resource)) = IR
ICEXT(I(rdf:langString)) is the set {I(E) : E a language-tagged string }
for every other IRI aaa in D, ICEXT(I(aaa)) is the value space of I(aaa)
for every IRI aaa in D, I(aaa) is in ICEXT(I(rdfs:Datatype))
|
| If
< x,y > is in IEXT(I(rdfs:domain)) and < u,v > is
in IEXT(x) then u is in ICEXT(y) |
| If
< x,y > is in IEXT(I(rdfs:range)) and < u,v > is
in IEXT(x) then v is in ICEXT(y) |
IEXT(I(rdfs:subPropertyOf))
is transitive and reflexive on IP |
| If
<x,y> is in IEXT(I(rdfs:subPropertyOf)) then x and
y are in IP and IEXT(x) is a subset of IEXT(y) |
If
x is in IC then < x, I(rdfs:Resource) > is in IEXT(I(rdfs:subClassOf)) |
IEXT(I(rdfs:subClassOf))
is transitive and reflexive on IC |
| If
< x,y > is in IEXT(I(rdfs:subClassOf)) then x and y are
in IC and ICEXT(x) is a subset of ICEXT(y) |
If
x is in ICEXT(I(rdfs:ContainerMembershipProperty)) then:
< x, I(rdfs:member) > is in IEXT(I(rdfs:subPropertyOf))
|
If
x is in ICEXT(I(rdfs:Datatype)) then < x,
I(rdfs:Literal) > is in IEXT(I(rdfs:subClassOf)) |
RDFS axiomatic triples.
rdf:type rdfs:domain rdfs:Resource .
rdfs:domain rdfs:domain rdf:Property .
rdfs:range rdfs:domain rdf:Property .
rdfs:subPropertyOf rdfs:domain rdf:Property .
rdfs:subClassOf rdfs:domain
rdfs:Class .
rdf:subject rdfs:domain rdf:Statement .
rdf:predicate rdfs:domain rdf:Statement .
rdf:object rdfs:domain rdf:Statement .
rdfs:member rdfs:domain rdfs:Resource .
rdf:first rdfs:domain rdf:List .
rdf:rest rdfs:domain rdf:List .
rdfs:seeAlso rdfs:domain rdfs:Resource .
rdfs:isDefinedBy rdfs:domain rdfs:Resource .
rdfs:comment rdfs:domain rdfs:Resource .
rdfs:label rdfs:domain rdfs:Resource .
rdf:value rdfs:domain rdfs:Resource .
rdf:type rdfs:range rdfs:Class .
rdfs:domain rdfs:range rdfs:Class .
rdfs:range rdfs:range rdfs:Class .
rdfs:subPropertyOf rdfs:range 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 .
rdfs:comment rdfs:range rdfs:Literal .
rdfs:label rdfs:range rdfs:Literal .
rdf:value rdfs:range rdfs:Resource .
rdf:Alt rdfs:subClassOf rdfs:Container .
rdf:Bag rdfs:subClassOf rdfs:Container .
rdf:Seq rdfs:subClassOf rdfs:Container .
rdfs:ContainerMembershipProperty rdfs:subClassOf rdf:Property .
rdfs:isDefinedBy rdfs:subPropertyOf rdfs:seeAlso .
rdfs:Datatype rdfs:subClassOf rdfs:Class .
rdf:_1 rdf:type rdfs:ContainerMembershipProperty .
rdf:_1 rdfs:domain rdfs:Resource .
rdf:_1 rdfs:range rdfs:Resource .
rdf:_2 rdf:type rdfs:ContainerMembershipProperty .
rdf:_2 rdfs:domain rdfs:Resource .
rdf:_2 rdfs:range rdfs:Resource .
...
|
Since I is an rdf-interpretation, the first condition implies that IP
= ICEXT(I(rdf:Property)).
The semantic conditions on rdf-D-interpretations, together with the RDFS conditions on ICEXT, mean that every recognized datatype can be treated as an RDFS class whose extension is the value space of the datatype, and every literal with that datatype either fails to refer (if the literal is ill-typed) or else refers to a value in that class.
These axioms and conditions have some redundancy. For example, all but one
of the RDF axiomatic triples can be derived from the RDFS axiomatic triples
and the semantic conditions on ICEXT, rdfs:domain and rdfs:range.
Other triples which must be true in all rdfs-interpretations
include the following:
Some rdfs-valid triples.
rdfs:Resource rdf:type rdfs:Class .
rdfs:Class rdf:type rdfs:Class .
rdfs:Literal rdf:type rdfs:Class .
rdf:XMLLiteral rdf:type rdfs:Class .
rdf:HTML rdf:type rdfs:Class .
rdfs:Datatype rdf:type rdfs:Class .
rdf:Seq rdf:type rdfs:Class .
rdf:Bag rdf:type rdfs:Class .
rdf:Alt rdf:type rdfs:Class .
rdfs:Container rdf:type rdfs:Class .
rdf:List rdf:type rdfs:Class .
rdfs:ContainerMembershipProperty rdf:type rdfs:Class .
rdf:Property rdf:type rdfs:Class .
rdf:Statement rdf:type rdfs:Class .
rdfs:domain rdf:type rdf:Property .
rdfs:range rdf:type rdf:Property .
rdfs:subPropertyOf rdf:type rdf:Property .
rdfs:subClassOf rdf:type rdf:Property .
rdfs:member rdf:type rdf:Property .
rdfs:seeAlso rdf:type rdf:Property .
rdfs:isDefinedBy rdf:type rdf:Property .
rdfs:comment rdf:type rdf:Property .
rdfs:label rdf:type rdf:Property .
|
RDFS does not partition the universe into disjoint categories of classes, properties and individuals. Anything in the universe can be used as a class or as a property, or both, while retaining its status as an individual which may be in classes and have properties. Thus, RDFS permits classes which contain other classes, classes of properties, properties of classes, etc. . As the axiomatic triples above illustrate, it also permits classes which contain themselves and properties which apply to themselves. A property of a class is not necessarily a property of its members, nor vice versa.
A note on rdfs:Literal
The class rdfs:Literal is not the class of literals, but rather that of literal values. For example, LV does not contain the literal "24"^^xsd:integer (although it might contain the string '"24"^^http://www.w3.org/2001/XMLSchema#integer' ) but it does contain the number twenty-four.
A triple of the form
<ex:a> rdf:type rdfs:Literal .
is consistent even though its subject is an IRI rather
than a literal. It says that the IRI 'ex:a'
refers to a literal value, which is quite possible since literal values are things in the universe. Similarly, blank nodes may range over literal values.
RDFS Entailment
S rdfs-D-entails E when every rdfs-D-interpretation
which satisfies every member of S also satisfies E. RDFS entailment is rdfs-{rdf:langString, xsd:string }-entailment, i.e. rdfs-D-entailment with a minimal D.
Since every rdfs-D-interpretation is an rdf-D-interpretation, if S rdfs-D-entails
E then S also rdf-D-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
aaa rdf:type rdfs:Resource .
where aaa is an IRI, are true in all rdfs-interpretations.
11. Monotonicity of semantic extensions
Given a set of RDF graphs, there are various ways in which one can 'add' information
to it. Any of the graphs may have some triples added to it; the set of graphs
may be extended by extra graphs; or the vocabulary of the graph may be interpreted
relative to a stronger notion of
entailment,
i.e. with a larger set
of semantic conditions understood to be imposed on the interpretations. All
of these can be thought of as an addition of information, and may make more
entailments hold than held before the change. All of these additions are monotonic,
in the sense that entailments which hold before the addition of information,
also hold after it. We can sum up this in a single lemma:
General monotonicity lemma. Suppose
that S, S' are sets of RDF graphs with every member of S a subset
of some member of S'. Suppose that Y indicates a semantic extension
of X, S X-entails E, and S and
E satisfy any syntactic restrictions of Y. Then S' Y-entails E.
In particular, if D' is a set of IRIs identifying datatypes, D a subset of D' and if S D-entails
E then S also D'-entails E.
A. Introduction to model theory (Informative)
///
C. What the semantics does not do (Informative)
Issue 8
Something in here about datasets having no specified semantics, and why. Why using a graph name need not refer to the graph.
The RDF vocabulary
The RDF semantic conditions do not place formal constraints on the meaning
of much of the RDF vocabulary which is intended for use in describing containers and bounded collections,
or the reification vocabulary intended to enable an RDF graph to describe RDF triples. In this appendix we briefly review the intended meanings of this vocabulary.
The omission of these conditions from the formal semantics is a design decision
to accommodate variations in existing RDF usage and to make it easier to implement
processes to check formal RDF entailment. For example, implementations may decide
to use special procedural techniques to implement the RDF collection vocabulary.
| RDF reification vocabulary |
rdf:Statement rdf:subject rdf:predicate
rdf:object |
The intended meaning of this vocabulary is to allow an RDF graph to act as metadata describing other RDF triples.
Consider an example graph containing a single triple:
<ex:a> <ex:b> <ex:c> .
and suppose that this graph is identified by the IRI ex:graph1. Exactly how this identification is achieved is external to the RDF model, but it might be by the IRI resolving to a concrete syntax document describing the graph, or by the IRI being the associated name of a named graph in a dataset. Assuming that the IRI can be used to refer to the triple, then the reification vocabulary allows us to describe the first graph in another graph:
<ex:graph1> rdf:type rdf:Statement .
<ex:graph1> rdf:subject <ex:a> .
<ex:graph1> rdf:predicate <ex:b> .
<ex:graph1> rdf:object <ex:c> .
The second graph is called a reification of the triple in the first
graph.
Reification is not a form of quotation. Rather, the reification describes the
relationship between a token of a triple and the resources that the triple refers
to. The value of the rdf:subject property is not the
subject IRI itself but the thing it denotes, and similarly for rdf:predicate and rdf:object. For example, if the referent of ex:a is Mount Everest, then the subject of the reified triple is also the mountain, not the IRI which refers to it.
Reifications can be written with a blank node as subject, or with an IRI subject which does not identify any concrete realization of a triple, in which case they assert the existence of the described triple.
The subject of a reification is intended to refer to a concrete realization of an RDF triple, such as a document in a surface syntax, rather than a triple considered as an abstract object. This supports use cases where properties such as dates of
composition or provenance information are applied to the
reified triple, which are meaningful only when thought of as
referring to a particular instance or token of a triple.
A reification of a triple does not entail the triple, and is not
entailed by it. The
reification only says that the triple token exists and what it is about,
not that it is true, so it does not entail the triple. On the other hand, asserting a triple does not automatically imply 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, 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 containers
| RDF Container Vocabulary |
rdf:Seq rdf:Bag rdf:Alt rdf:_1 rdf:_2
... |
RDF provides vocabularies for describing three classes of
containers. Containers have a type, and their members can
be 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; some containers are considered to be unordered.
The RDFS vocabulary, described below, adds a generic membership
property which holds regardless of position, and classes containing
all the containers and all the membership properties.
One should understand this RDF vocabulary as describing
containers, rather than as a vocabulary for constructing them, as
would typically be supplied by a programming language. On this
view, the actual containers are entities in the semantic universe,
and RDF graphs which use the vocabulary simply provide very basic
information about these entities, enabling an RDF graph to
characterize the container type and give partial information about
the members of a container. Since the RDF container vocabulary is
so limited, many 'natural' assumptions concerning RDF containers
are not formally sanctioned by the RDF model theory. This should not be taken as
meaning that these assumptions are false, but only that RDF does
not formally entail that they must be true.
There are no special semantic conditions on the container
vocabulary: the only 'structure' which RDF presumes its containers
to have is what can be inferred from the use of this vocabulary and
the general RDF semantic conditions. This amounts to knowing the type of a container, and having a partial
enumeration
of the 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, 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 enumerating
the elements of an 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, then the result of
conjoining it to the original graph would be entailed by the graph, and this would assert that both elements were in both
positions. This is a consequence of the fact that RDF is a purely
assertional language.
There is no assumption that a property of a container applies to
any of the elements of the container, or vice versa.
There is no formal requirement that
the three container classes are disjoint, so that for example
it is not a contradiction to assert that something is 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 collections
| RDF Collection Vocabulary |
rdf:List rdf:first rdf:rest rdf:nil |
RDF provides a vocabulary for describing collections, i.e.'list
structures', in terms of head-tail links. Collections differ from
containers in allowing branching structure and in having an
explicit terminator, allowing applications to determine the exact
set of items in the collection.
As with containers, no special semantic conditions are imposed on this vocabulary
other than the type of rdf:nil being 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
two triples of the form
_: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. Any such graph amounts to an assertion
that the 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. 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:
_:c1 rdf:first <ex:aaa> .
_:c1 rdf:rest _:c2 .
_:c2 rdf:first <ex:bbb> .
_:c2 rdf:rest rdf:nil .
does not entail
_:c3 rdf:first <ex:bbb> .
_:c3 rdf:rest _:c4 .
_:c4 rdf:first <ex:aaa> .
_:c4 rdf:rest rdf:nil .
Also, RDF imposes no '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 rdf:first <ex:aaa> .
_:666 rdf:first <ex:bbb> .
_:666 rdf:rest <ex:ccc> .
_:666 rdf:rest rdf:nil .
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. They MAY
exclude interpretations of the collection vocabulary which violate the convention
that the subject of a 'linked' collection of 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.
The RDFS semantic conditions 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.
rdf:value
The intended use for rdf:value is explained
intuitively in the RDF Primer
document [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 difficult to give a precise statement which covers all the intended meanings
or use cases. Users are cautioned, therefore, that the
meaning of rdf:value may vary from application to application.
Even when the intended meaning is clear from the context in the original graph document, it may be
lost when graphs are merged or when conclusions are inferred.
D. Glossary of Terms (Informative)
Antecedent (n.) In an inference, the
expression(s) from which the conclusion is derived. In an entailment relation, the
entailer. Also assumption.
Assertion (n.) (i) Any expression
which is claimed to be true. (ii) The act of claiming something to
be true.
Class
(n.) A general concept, category or classification. Something used primarily to
classify or categorize other things. Formally, in RDF, a resource of type
rdfs:Class with an associated set of resources all of which
have the class as a value of the rdf:type property.
Classes are often called 'predicates' in the formal logical
literature.
(RDF distinguishes class from set, although the two are often
identified. Distinguishing classes from sets allows RDF more
freedom in constructing class hierarchies.
Complete (adj., of an inference system). (1)
Able to detect all entailments between any two expressions.
(2) Able to draw all valid inferences. See Inference. Also used with a qualifier: able to
detect entailments or draw all valid inferences in a certain limited form or kind (e.g.
between expressions in a certain normal form, or meeting certain syntactic conditions.)
(These definitions are not exactly equivalent, since the first requires that
the system has access to the consequent of the entailment, and may be unable
to draw 'trivial' inferences such as (p and p) from p. Typically, efficient
mechanical inference systems may be complete in the first sense but not necessarily
in the second.)
Consequent (n.) In an inference,
the expression constructed from the antecedent. In an entailment relation, the
entailee. Also conclusion.
Consistent (adj., of an expression) Having
a satisfying interpretation; not internally contradictory. (Also used
of an inference system as synonym for Correct.)
Correct (adj., of an inference system). Unable
to draw any invalid inferences, or unable to make false claims of entailment. See Inference.
Decidable
(adj., of an inference system). Able to determine for any pair of expressions,
in a finite time with finite resources, whether or not the first entails the
second. (Also: adj., of a logic:) Having a decidable inference system which
is complete and correct for the semantics of the logic.
(Not all logics can have inference systems which are both complete and decidable,
and decidable inference systems may have arbitrarily high computational complexity.
The relationships between logical syntax, semantics and complexity of an inference
system continue to be the subject of considerable research.)
Entail (v.),
entailment (n.). A semantic relationship between
expressions which holds whenever the truth of the first guarantees
the truth of the second. Equivalently, whenever it is logically
impossible for the first expression to be true and the second one
false. Equivalently, when any interpretation which satisfies the first also satisfies the second.
(Also used between a set of expressions and an expression.)
Equivalent (prep., with
to) True under exactly the same conditions; making
identical claims about the world, when asserted. Entails and is entailed
by.
Extensional (adj., of a logic) A
set-based theory or logic of classes, in which classes are
considered to be sets, properties considered to be sets of
<object, value> pairs, and so on. A theory which admits no
distinction between entities with the same extension. See Intensional.
Formal (adj.) Couched in language
sufficiently precise as to enable results to be established using
conventional mathematical techniques.
Iff
(conj.) Conventional abbreviation for 'if and only if'. Used to
express necessary and sufficient conditions.
Inconsistent (adj.) False under
all interpretations; impossible to satisfy. Inconsistency
(n.), any inconsistent expression or graph.
(Entailment and inconsistency are closely
related, since A entails B just when (A and not-B) is inconsistent, c.f. the
second definition for entailment. This is the basis of many
mechanical inference systems.
Although the definitions of consistency
and inconsistency are exact duals, they are computationally dissimilar. It is
often harder to detect consistency in all cases than to detect inconsistency
in all cases.)
Indexical (adj., of an expression) having
a meaning which implicitly refers to the context of use. Examples from English
include words like 'here', 'now', 'this'.
Inference (n.) An act or
process of constructing new expressions from existing expressions, or the result
of such an act or process. Inferences corresponding to entailments are described as correct or valid.
Inference rule, formal description of a type of inference;
inference system, organized system of inference rules; also,
software which generates inferences or checks inferences for validity.
Intensional (adj., of a logic)
Not extensional. A
logic which allows distinct entities with the same extension.
(The merits and demerits of intensionality have been extensively debated in
the philosophical logic literature. Extensional semantic theories are simpler,
and conventional semantics for formal logics usually assume an extensional view,
but conceptual analysis of ordinary language often suggests that intensional
thinking is more natural. Examples often cited are that an extensional logic
is obliged to treat all 'empty' extensions as identical, so must identify 'round
square' with 'santa clause', and is unable to distinguish concepts that 'accidentally'
have the same instances, such as human beings and bipedal hominids without body
hair. The semantics described in this document is basically intensional.)
Interpretation
(of) (n.) A minimal formal description of those
aspects of a world which
is just sufficient to establish the truth or falsity of any
expression of a logic.
(Some logic texts distinguish between an interpretation
structure, which is a 'possible world' considered as something
independent of any particular vocabulary, and an interpretation
mapping from a vocabulary into the structure. The RDF
semantics takes the simpler route of merging these into a single
concept.)
Logic
(n.) A formal language which expresses propositions.
Metaphysical (adj.).
Concerned with the true nature of things in some absolute or
fundamental sense.
Model Theory (n.) A
formal semantic theory which relates expressions to
interpretations.
(The name 'model theory' arises from the usage, traditional in
logical semantics, in which a satisfying interpretation is called a
"model". This usage is often found confusing, however, as it is
almost exactly the inverse of the meaning implied by terms like
"computational modelling", so has been avoided in this
document.)
Monotonic (adj., of a logic or
inference system) Satisfying the condition that if S entails E then
(S + T) entails E, i.e. adding information to some antecedents
cannot invalidate a valid entailment.
(All logics based on a conventional model theory and a standard notion of
entailment are monotonic. Monotonic logics have the property that
entailments remain valid outside of the context in which they were
generated. This is why RDF is designed to be monotonic.)
Nonmonotonic (adj.,of a logic
or inference system) Not monotonic. Non-monotonic formalisms have been
proposed and used in AI and various applications. Examples of
nonmonotonic inferences include default reasoning, where
one assumes a 'normal' general truth unless it is contradicted by
more particular information (birds normally fly, but penguins
don't fly); negation-by-failure, commonly assumed in logic
programming systems, where one concludes, from a failure to prove a
proposition, that the proposition is false; and implicit
closed-world assumptions, often assumed in database
applications, where one concludes from a lack of information about
an entity in some corpus that the information is false (e.g. that
if someone is not listed in an employee database, that he or she is not
an employee.)
(The relationship between monotonic and nonmonotonic inferences
is often subtle. For example, if a closed-world assumption is made
explicit, e.g. by asserting explicitly that the corpus is complete
and providing explicit provenance information in the conclusion,
then closed-world reasoning is monotonic; it is the implicitness
that makes the reasoning nonmonotonic. Nonmonotonic conclusions can
be said to be valid only in some kind of 'context', and are liable
to be incorrect or misleading when used outside that context.
Making the context explicit in the reasoning and visible in the
conclusion is a way to map them into a monotonic framework.)
Ontological (adj.) (Philosophy)
Concerned with what kinds of things really exist. (Applied)
Concerned with the details of a formal description of some topic or
domain.
Proposition (n.) Something that
has a truth-value; a statement or expression that is true or
false.
(Philosophical analyses of language traditionally distinguish
propositions from the expressions which are used to state them, but
model theory does not require this distinction.)
Reify
(v.), reification (n.) To categorize as an object;
to describe as an entity. Often used to describe a convention
whereby a syntactic expression is treated as a semantic object and
itself described using another syntax. In RDF, a reified triple is
a description of a triple-token using other RDF triples.
Resource (n.)(as used in RDF)(i) An
entity; anything in the universe. (ii) As a class name: the class
of everything; the most inclusive category possible.
Satisfy (v.t.),
satisfaction,(n.) satisfying
(adj., of an interpretation). To make true. The basic semantic
relationship between an interpretation and an expression. X
satisfies Y means that if the
world conforms to the conditions described by X, then Y must be
true.
Semantic (adj.) ,
semantics (n.). Concerned with the specification
of meanings. Often contrasted with syntactic to emphasize
the distinction between expressions and what they denote.
Skolemization (n.) A
syntactic transformation in which blank nodes are replaced by 'new'
names.
(Although not strictly valid, Skolemization retains the
essential meaning of an expression and is often used in mechanical
inference systems. The full logical form is more complex. It is
named after the logician
A. T. Skolem)
Token
(n.) A particular physical inscription of a symbol or expression in
a document. Usually contrasted with type, the abstract
grammatical form of an expression.
Universe (n., also Universe of
discourse) The universal classification, or the set of all
things that an interpretation considers to exist. In RDF/S, this is
identical to the set of resources.
Use (v.)
contrasted with mention; to use a piece of syntax to
denote or refer to something else. The normal way that language is
used.
("Whenever, in a sentence, we wish to say something about a
certain thing, we have to use, in this sentence, not the thing
itself but its name or designation." - Alfred
Tarski)
Valid
(adj., of an inference or inference process) Corresponding to an entailment, i.e. the
conclusion of the inference is entailed by the antecedent of the
inference. Also correct.
Well-formed (adj., of an
expression). Syntactically legal.
World
(n.) (with the:) (i) The actual world. (with
a:) (ii) A way that the actual world might be arranged.
(iii) An interpretation (iv) A possible world.
(The metaphysical status of 'possible
worlds' is highly controversial. Fortunately, one does not need to commit
oneself to a belief in parallel universes in order to use the concept in its
second and third senses, which are sufficient for semantic purposes.)
E. Acknowledgements
The basic idea of using an explicit extension mapping to allow
self-application without violating the axiom of foundation was
suggested by Christopher Menzel.
///Herman ter Horst for rule style, Li Ding for complete graphs, Antoine for no-vocabulary and general input. Others?///
Many thanks to Robin Berjon for making our lives so much easier with his cool tool. You betcha.