- From: Dave Beckett <dave.beckett@bristol.ac.uk>
- Date: Tue, 29 Jul 2003 11:07:10 +0100
- To: www-archive@w3.org
- Message-Id: <20030729110710.04249314.dave.beckett@bristol.ac.uk>
A copy of http://www.ihmc.us/users/phayes/RDF_Semant_Edit_Weak.html
Last-Modified: Tue, 29 Jul 2003 04:23:35 GMT
converted to unix line endings, for archiving.
Dave
The difference between that and the copy I reviewed at
http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-mt-20030117/
is as follows
(after tidy | lynx -dump -nolinks for each document then diff -u)
--- nnn.txt 2003-07-29 10:45:30.000000000 +0100
+++ sss.txt 2003-07-29 10:45:35.000000000 +0100
@@ -1,9 +1,7 @@
W3C
-RDF Semantics
-
-@@Editors Draft with Weak RDFS conditions and rules July 15
+RDF Semantics Editors Draft July 27
@@Based on Last Call Draft at:
http://www.w3.org/TR/2003/WD-rdf-mt-20030123/
@@ -25,185 +23,6 @@
liability, trademark, document use and software licensing rules apply.
_________________________________________________________________
- Change List since Last Call.
-
- 15 July. A note added in section 1.3 to the draw attention to the fact
- that RDF semantics does not depend on RDFS semantics. Minor edits of
- internal links, punctuation.
-
- 11 July. Lbase reference updated to refer to the W3C note. Comment
- added regarding the translation described in the note.
-
- 7+8 July. Value and lexical spaces of a datatype are now required to
- be non-empty; added in light of comment by Peter:
- http://lists.w3.org/Archives/Public/www-rdf-comments/2003AprJun/0276.h
- tml. and suggestion by Patrick. Additional condition added to Lbase
- translation to capture this condition. (The entailment rules already
- implicitly assumed it in rule rdfD1)
-
- 4 July. Several small corrections made to text following review
- comments from Jeremy (thanks, Jeremy). In particular, the XML literal
- terminology is now correct and links to Concepts brought up to date,
- cf.
- http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jun/0109.html.
- There is now an anchor #XSDtable for the table of kosher XSD datatypes
- and the discussion of the non-kosher ones. Most of the changes
- suggested in
- http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jun/0110.html
- have been made.
-
- This version of the semantics document follows a decision by the RDF
- core WG to weaken the normative semantic conditions on subclass and
- subproperty (as well as domain and range) so as to provide for a
- simpler and more intuitive complete set of RDFS inference rules. We
- have retained transitivity and reflexivity in order to provide a more
- intuitive semantics. The entailment rules have been divided into a
- normative set corresponding to this simplified semantics, together
- with a statement and (appendix B) proof of a completeness result; and
- an informative table of some of the extra entailments which would be
- sanctioned by strengthened semantic conditions. Corresponding changes
- have been made to the Lbase axioms in the appendix.
-
- Other (minor) changes to this version are that the definition of
- 'vocabulary' has been changed to allow a vocabulary to contain typed
- literals as well as URIrefs (this change should have been made when IL
- was included as part of the interpretation, but the need was only
- noted clearly when the proofs were written out in full) and the RDF
- and RDFS completness lemmas have been re-stated so as not to mention
- closures; this is a small stylistic improvment and does not change the
- essential content. A number of additional internal reference links
- have been added throughout the text.
-
- This version of the document is now in final form and at the time of
- writing (1 July 2003) reflects the latest decisions of the WG. It also
- passes the W3C validators.
-
- -------
-
- In section 3.2 a note of clarification has been added:"Semantic
- extensions MAY limit the formal interpretations of these vocabularies
- to conform to these intended meanings." which amplifies the full
- implications of 'semantic extension'.
-
- Email correspondence has revealed that the useage of 'string' in the
- text can be misunderstood. Text has been added here and here to
- clarify the sense of 'string' and 'character string' used in the text,
- and to state explicitly the agnostic stance of the semantics as to
- whether or not strings, XML documents and xsd:strings are equivalent.
- Recent email traffic has suggested that these additions may be
- controversial; if this is changed then the wording of part of the
- Lbase datatype description should also be changed slightly.
-
- June 18th: The wordings for XML literal and the links to the concepts
- document have been brought uptodate. Minor wording changes have also
- been done to bring the text more aligned with Concepts, eg 'equal' ->
- 'equivalent'.
-
- Apart from the change noted, and corresponding editorial changes to
- the text, significant changes since the last call document are as
- follows.
-
- 1. Following WG decisions, the treatment of XML literals has been
- simplified; they are now required to be in canonical form and
- therefore to denote their own literal string, similarly to plain
- literals. XML literals do not contain language tags, and so in
- datatyped interpretations rdf:XMLLiteral is treated exactly uniformly
- with other datatypes.
-
- The semantic conditions on literals have now been rewritten and some
- of the conditions moved back from D-interpretations to rdf and
- rdfs-interpretations. Anything that can be said using entirely the
- vocabulary in the RDF namespace, or which arises as part of the RDF
- syntax - including XML literals - is now part of the RDF semantics,
- and similarly for RDFS. The extra semantic conditions for
- D-interpretations are now only those which require access to datatype
- information external to RDFS, the class rdfs:Literal is now identified
- with the set of all literal values in all interpretations, plus:
-
- Expository change arising from comment pfps-08. This has been re-done
- somewhat as a result of email correspondence. The situation now is
- somewhat subtle. The actual condiions are stated as part of the rdf
- and rdfs semantics simply as conditions on XML literals considered as
- a syntactic category. This is what the comment was concerned with.
- Now, however, in D-interpretations, the 'built-in datatype' is
- introduced explicitly as an entity, and some text added here to
- clarify the importance of this for OWL-type reasoners. This allows
- non-datatype-savvy engines to use the XML syntax and also allows more
- sophisticated reasoners to build on D-interpretations.
-
- Section 3.4 (datatyped interpretations) has been extensively rewritten
- and the formal development modified. D-interpretations are defined
- relative to a mapping from URIrefs to datatypes (rather than to a set
- of datatypes.) These changes do not affect any terminology used in
- other parts of the document or any other documents, but provide a
- mathematically more precise account of relationship betwen
- interpretations and external datatypes, and provide (I believe) a
- better interface for the OWL semantics. The former statement of the
- datatype monotonicity lemma was mistaken, and has been re-stated as a
- more general monotonicity lemma.
-
- The datatypes included in the datatype mapping XSD have been listed
- explicitly and reasons given for the omission of the others. This
- table and text was taken from
- http://www-db.research.bell-labs.com/user/pfps/owl/semantics/syntax.ht
- ml#owl_built_in_datatypes, with permission; it originates in
- http://lists.w3.org/Archives/Public/www-archive/2002Nov/att-0092/02-in
- dex.
-
- Text has been added to help clarify the distinction between merging
- graphs and forming a union, and the relationship between this
- distinction and standardizing apart blank node IDs. The matter is
- somewhat delicate and apparently has been misunderstood.
-
- Expository change arising from email correspondence. The wording of
- section 3.2.2 RDF containers has been rephrased in several places to
- avoid giving a misleading impression of the relationship between a bag
- and its RDF description. See emails in thread starting at
-
- http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0179.h
- tml.
-
- Following WG discussion of comment timbl-02, a comment has been added
- to clarify the distinction between reification and quoting.
-
- Following a suggestion by Graham Klyne, some conditions on IP have
- been moved to the RDF semantics from the RDFS semantics. Small changes
- to the wording of the first paragraphs of section 3.2 have been done
- to match, and figure 2 re-drawn.
-
- Also the term 'isomorphic' applied to RDF graphs has been removed,
- also suggested by Graham.
-
- Following a WG decision, the text of section 3.2.3 has been revised so
- that triples of the form ...rdf:type rdf:List . are not mentioned in
- the examples. A sentence noting the RDFS domain and range conditions
- on the collection vocabulary has been added.
-
- The definitions of the RDF and rdfs-interpretations now refers to a
- 'core' RDF vocabulary. This avoids the technical awkwardness arising
- from the infinite RDF container vocabulary. No entailments are
- affected by this change.
-
- The Lbase translations in the appendix have been brought up-to-date
- and the datatype section rewritten.
-
- The definition of "lean" graph (section 0.3) has been modified
- (strengthened) following an email from Peter, and the definition of
- "proper instance" modified to take account of the case where two
- bnodes are identified.
-
- The definition of IP and the main truth-condition on triples in the
- simple interpretation case have been slightly modified so that IP is
- not required to be a subset of IR. This does not affect any of the
- RDF(S) semantics, since IP is required to be a subset of IR for any
- property with a rdf:type, but it does allow some flexibility for RDF
- embedding of 'layered' languages or UML-style uses of RDF syntax, and
- is in conformity with recent work on the SCL semantics. No RDF or RDFS
- entailments are affected by this change.
-
-
- _________________________________________________________________
-
Abstract
This is a specification of a precise semantics for the Resource
@@ -253,12 +72,13 @@
0.2 Graph Syntax
0.3 Graph Definitions
1. Interpretations
- 1.1 Technical Notes
- 1.2 Urirefs, Resources and Literals
+ 1.1 Technical Note (Informative)
+ 1.2 URI references, Resources and Literals
1.3 Interpretations
1.4 Denotations of Ground Graphs
1.5 Blank nodes as Existential variables
2. Simple Entailment between RDF graphs
+ 2.1 Vocabulary interpretations and vocabulary entailment
3. Interpreting the RDF vocabulary
3.1. RDF Entailment
3.2 Reification, Containers, Collections and rdf:value
@@ -279,11 +99,12 @@
7.3 RDFS Entailment Rules
7.3.1 Extensional Entailment Rules (Informative)
7.4 Datatype Entailment Rules
- Appendix A. Translation into Lbase
- Appendix B. Proofs of lemmas
- Appendix C. Glossary
+ Appendix A. Translation into Lbase (Informative)
+ Appendix B. Proofs of lemmas (Informative)
+ Appendix C. Glossary (Informative)
Appendix D. Acknowledgements
References
+ Appendix E. Change Log (Informative)
0. Introduction
@@ -329,8 +150,7 @@
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 which allows RDF to
- be used to transmit content.
+ 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
@@ -343,17 +163,15 @@
inference rules.
This document gives two versions of the same semantic theory:
- directly, and also (in an informative appendix) an 'axiomatic
- semantics' in the form of a translation from RDF and RDFS into another
- formal language, L[base] [LBASE] which has a pre-defined
+ normatively in the text, and also (informatively, in appendix A) an
+ 'axiomatic semantics' in the form of a translation from RDF and RDFS
+ into another formal language, L[base] [LBASE] which has a pre-defined
model-theoretic semantics. The translation technique offers some
- advantages for machine processing and may be more readable, so is
- described here as a convenience. The editor believes that both of
- these descriptions are in exact correspondence, but in the event that
- any discrepancies are found, only the directly described model theory
- in the body of the document should be taken as normative.The document
- also describes complete sets of inference rules corresponding to the
- semantics decribed in the text.
+ advantages and may be more readable, so is described here as a
+ convenience. The axiomatic semantic description differs slightly from
+ the normative model theory in the body of the text, as noted in the
+ appendix. The document also describes complete sets of inference rules
+ corresponding to the semantics decribed in the text.
There are several aspects of meaning in RDF which are ignored by this
semantics; in particular, it treats URI references as simple names,
@@ -372,7 +190,7 @@
constructs.
Particular uses of RDF, including as a basis for more expressive
- languages such as DAML [DAML] and OWL [OWL], may impose further
+ languages such as 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
@@ -406,7 +224,7 @@
Any semantic theory must be attached to a syntax. This semantics is
defined as a mapping on the abstract syntax of RDF described in the
RDF concepts and abstract syntax document [RDF-CONCEPTS]. This
- document uses the following terminology defined there: URIref,
+ document uses the following terminology defined there: URI reference,
literal, plain literal, typed literal, XML literal, XML data
corresponding to, node, blank node, triple and RDF graph.
@@ -418,14 +236,14 @@
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 documents which differ only by
- re-naming their node identifiers will be understood to be equal . 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 graph.
-
- The N-Triples syntax requires that URIrefs be given in full, enclosed
- in angle brackets. In the interests of brevity, the imaginary URI
- scheme 'ex:' is used to provide illustrative examples. To obtain a
+ re-naming their node identifiers will be understood to 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 graph.
+
+ The N-Triples syntax requires that URI references be given in full,
+ enclosed in angle brackets. In the interests of brevity, 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 syntax,
the reader should imagine this replaced with something like
'http://www.example.org/rdf/mt/artificial-example/'. The QName
@@ -440,7 +258,8 @@
Since QName syntax is not legal N-Triples syntax, and in the interests
of brevity and readability, examples use the convention whereby a
QName is used without surrounding angle brackets to indicate the
- corresponding URIref enclosed in angle brackets, e.g. the triple
+ corresponding URI reference enclosed in angle brackets, e.g. the
+ triple
<ex:a> rdf:type rdfs:Class .
@@ -465,21 +284,22 @@
A ground RDF graph is one with no blank nodes.
- A name is a URIref or a typed literal. Plain literals are not
- classified as names because their interpretation is fixed by the RDF
- semantic rules. A name is from a vocabulary V if it is in V or is a
- typed literal containing a URIref in V. The names of a graph are all
- the names which occur in the graph. This is the set of expressions
- that need to be assigned a meaning by an interpretation. Note that a
- typed literal contains two names: itself and its internal type URIref.
+ A name is a URI reference or a typed literal. A name is from a
+ vocabulary V if it is a URI reference in V or a typed literal
+ containing an internal type URI reference in V. The names of a graph
+ are all the names which occur in the graph. These are the expressions
+ that need to be assigned a meaning by an interpretation. Plain
+ literals are not classified as names because their interpretation is
+ fixed. Note that a typed literal comprises two names: itself and its
+ internal type URI reference.
A set of names is referred to as a vocabulary. The vocabulary of a
graph is the set of names of the graph.
Suppose that M is a mapping from a set of blank nodes to some set of
- literals, blank nodes and URIrefs; 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
+ literals, blank nodes and 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.
@@ -488,10 +308,9 @@
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 is
- mapped to a name or to some other blank node in the graph, so that in
- the instance a blank node has been replaced by a name or two blank
- nodes in the graph have been identified. An instance is proper just
+ 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. An instance is proper just
when the instance mapping M is not invertible.
Any instance of a graph in which a blank node is mapped to a new blank
@@ -501,11 +320,11 @@
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.
- We will treat equivalent graphs as identical; this slight abuse of
- terminology 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.
+ 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.
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
@@ -516,20 +335,20 @@
is not lean, but
- <ex:a> <ex:p> _:x.
+ <ex:a> <ex:p> _:x .
_:x <ex:p> _:x .
is lean.
- Consider a set S of graphs which share no blank nodes. The graph
- consisting of all the triples in all the graphs in S is another graph,
- called the merge of S. Each of the original graphs is a subgraph of
- the merged graph. If the members of the set S share some blank nodes,
- then the merge of S is defined 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 equivalent to those in S in
- the above sense. Note that a merge differs in this respect from a
- simple union of the graphs.
+ The merge of a set of RDF graphs is defined as follows. If the graphs
+ in the set have no blank nodes in common, then the merge is the union
+ of the graphs; if they do share blank nodes, then it is the union of a
+ set of graphs which is 1:1 with the original set of graphs, each of
+ which is equivalent in the above sense to one graph in the original
+ set, and which share no blank nodes. This is often described by saying
+ that the blank nodes have been 'standardized apart'. Using the
+ convention on equivalent graphs and identity, any graph in the
+ original 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
@@ -540,12 +359,12 @@
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 the RDF syntax specification
- [RDF-SYNTAX].
+ documents which contain nodeIDs, see RDF/XML Syntax Specification
+ (Revised) [RDF-SYNTAX].
1. Interpretations
- 1.1 Technical Notes
+ 1.1 Technical note (Informative)
RDF does not impose any logical restrictions on the domains and ranges
of properties; in particular, a property may be applied to itself.
@@ -597,51 +416,47 @@
a member is quite different from the question of whether or not it is
a subclass of itself. All classes are subclasses of themselves.
- 1.2 Urirefs, Resources and Literals.
+ 1.2 URI references, Resources and Literals.
- This document does not take any position on the way that URIrefs may
- be composed from other expressions, e.g. from relative URIs or QNames;
- the semantics simply assumes that such lexical issues have been
- resolved in some way that is globally coherent, so that a single
- URIref 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 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.
+ This document does not take any position on the way that URI
+ references may be composed from other expressions, e.g. from relative
+ URIs or QNames; the semantics simply assumes that such lexical issues
+ have been resolved in some way that is globally coherent, so that a
+ single 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 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 and a document or Web resource which can be
- retrieved by using that URIref 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 and the uses of those URIrefs in
- other protocols.
+ denotation of a URI reference and a document or Web resource which can
+ be retrieved by using that 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 URI references and the uses of
+ those URI references in other protocols.
The semantics treats all RDF names 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'.
+ treated here as synonymous with 'entity', i.e. as a generic term for
+ anything in the universe of discourse.
- Throughout this document we use the term "character string" or
- "string" to refer to a sequence of Unicode characters in Normal Form
- C, c.f. section 6.5 in [RDF-CONCEPTS]. The use of the XML Schema
- datatype xsd:string described in section 3.4 allows an RDF graph to
- refer to entities called 'strings'. The semantics described here is
- deliberately agnostic on the question of whether or not the values of
- xsd:string are identical to character strings.
+ Throughout this document we use the term 'character string' or
+ 'string' to refer to a sequence of Unicode characters in Normal Form
+ C, c.f. section 6.5 in [RDF-CONCEPTS].
The different syntactic forms of names are treated in particular ways.
- Urirefs are treated simply as logical constants. Simple literals are
- considered to denote themselves, so have a fixed meaning. The
+ 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, which denote exclusive Canonical XML [XML-C14N],
- hereafter called "XML data", described by the literal string: see the
- RDF concepts and abstract syntax document [RDF-CONCEPTS] for exact
- details.
+ rdf:XMLLiteral, which denote exclusive Canonical XML [XML-C14N]
+ described by the literal string: see RDF: Concepts and Abstract Syntax
+ [RDF-CONCEPTS] for exact details.
1.3 Interpretations
@@ -665,41 +480,42 @@
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, 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, 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.
- (Non-ground graphs are considered in the following section.) Note that
- if any of this information 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.
+ specifying for each 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, 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. (Non-ground graphs are considered in the following section.)
+ Note that if any of this information 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, called the
+ All interpretations will be relative to a set of names, 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, e.g.
- 'rdf-interpretations', 'rdfs-interpretations', etc.. An interpretation
+ 'rdf-interpretations', 'rdfs-interpretations', 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.
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
- URIref, are always interpreted as referring to themselves: either a
+ 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 tags. 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. A full discussion of the
- meaning of typed literals is postponed until later sections, where a
- special notion of datatype interpretation is introduced. Each
- interpretation defines a mapping IL from typed literals to their
+ 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. A full
+ discussion of the meaning of typed literals is described in section 5
+ , where a special notion of datatype interpretation is introduced.
+ Each interpretation defines a mapping IL from typed literals to their
interpretations. Stronger conditions on IL will be defined as the
notion of 'interpretation' is extended in later sections.
@@ -709,9 +525,11 @@
are distinguished by background color. These tables, taken together,
amount to a formal summary of the entire semantics. Note that the
semantics of RDF does not depend on that of RDFS. The full semantics
- of RDF is defined in sections 1 and 3; the full semantics of RDFS in
+ of RDF is defined in sections 1 and 3 ; the full semantics of RDFS in
sections 1, 3 and 4.
+ Definition of a simple interpretation.
+
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
@@ -722,13 +540,13 @@
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 URIrefs in V into (IR union IP)
+ 4. A mapping IS from URI references in V into (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 literal character strings and all pairs
- consisting of a literal character string and a language tag.
+ which contains at least all character strings and all pairs consisting
+ of a character string and a language tag.
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
@@ -739,13 +557,13 @@
The assumption that LV is a subset of IR amounts to saying that
literal values are thought of as real entities that 'exist'. This
amounts to saying that literal values are resources. However, this
- does not imply that literals should be identified with URIrefs. 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 restricted to
- LV. When interpretations take account of datatype information, it is
- syntactically possible for a typed literal to be internally
- inconsistent, and such badly typed literals are required to denote a
- non-literal value.
+ does not imply that literals should be identified with 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
+ restricted to LV. When interpretations take account of datatype
+ information, it is syntactically possible for a typed literal to be
+ internally inconsistent, and such badly typed literals are required to
+ denote a non-literal value.
The next sections define how an interpretation of a vocabulary
determines the truth-values of any RDF graph, by a recursive
@@ -758,49 +576,60 @@
1.4 Denotations of Ground Graphs
The denotation of a ground RDF graph in I is given recursively by the
- following rules, which extend the interpretation mapping I from labels
+ following rules, which extend the interpretation mapping I from names
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 constituents of E, hence
allowing the denotation of any piece of RDF to be determined by a kind
of syntactic recursion.
+ Semantic conditions for ground graphs.
+
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 then I(E) = IL(E)
- if E is a URIref then I(E) = IS(E)
- if E is a triple s p o . then I(E) = true if I(p) is in IP and
- <I(s),I(o)> is in IEXT(I(p)), otherwise I(E)= false.
+ if E is a URI reference then I(E) = IS(E)
+
+ if E is a triple s p o . then I(E) = true if
+
+ s, p and o are in V, I(p) is in IP and <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.
- 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 URIref which occurs both as a predicate and as a subject or object
- in any triple must denote something in the intersection of IR and IP.
+ If the vocabulary of an RDF graph contains 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 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.
- If the vocabulary of an RDF graph contains URIrefs 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 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}. Integers are used to
+ for the artificial vocabulary {ex:a, ex:b, ex:c} 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 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 this and subsequent examples the
- greater-than and less-than symbols are used in several ways: following
- mathematical usage to indicate abstract pairs and n-tuples; following
- N-Triples syntax to enclose URIrefs, and also as arrowheads when
+ in the universe is irrelevant. LV can be any set satisfying the
+ semantic conditions. (In this and subsequent examples the greater-than
+ and less-than symbols are used in several ways: following mathematical
+ usage to indicate abstract pairs and n-tuples; following N-Triples
+ syntax to enclose URI references, and also as arrowheads when
indicating mappings.)
- IR = LV union{1, 2}; IP={1}
+ IR = LV union{1, 2}
+
+ IP={1}
IEXT: 1=>{<1,2>,<2,1>}
@@ -829,8 +658,7 @@
is true.
The truth of the fourth triple is a consequence of the rather
- idiosyncratic interpretation chosen here for typed literals; this kind
- of oddity will be ruled out in in datyped interpretations.
+ idiosyncratic interpretation chosen here for typed literals.
In this interpretation IP is a subset of IR; this will be typical of
RDF semantic interpretations, but is not required.
@@ -851,26 +679,25 @@
<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.
+ property extension does not have any pairs containing a plain literal.
To emphasize; this is only one possible interpretation of this
vocabulary; there are (infinitely) many others. For example, if 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 the fact that any interpretation of a graph
- which maps any URIref in predicate position to something not in IP
- will make the graph false.
+ This example illustrates that any interpretation which maps any URI
+ reference which occurs in the predicate position of a triple in a
+ graph to something not in IP will make the graph false.
1.5. Blank Nodes as Existential Variables
Blank nodes are treated as simply indicating the existence of a thing,
without using, or saying anything about, the name of that thing. (This
is not the same as assuming that the blank node indicates an 'unknown'
- URIref; for example, it does not assume that there is any URIref which
- refers to the thing. The discussion of Skolemization in the proof
- appendix is relevant to this point.)
+ URI reference; for example, it does not assume that there is any URI
+ reference which refers to the thing. The discussion of Skolemization
+ in appendix B is relevant to this point.)
An interpretation can specify the truth-value of a graph containing
blank nodes. This will require some definitions, as the theory so far
@@ -882,6 +709,8 @@
rules can be extended to include the two new cases that are introduced
when blank nodes occur in the graph:
+ Semantic conditions for blank nodes.
+
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.
@@ -929,18 +758,19 @@
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 each graph as defining an existential
- closure, 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.
+ graph. Merging two graphs treats the blank nodes in each graph as
+ being existentially quantified in that graph, so that no blank node
+ from one graph is allowed to stray into the scope of the other graph's
+ surrounding quantifier. This is appropriate when the graphs come from
+ different sources and there is no justification for assuming that a
+ blank node in one refers to the same entity as any blank node in the
+ other.
2. Simple Entailment between RDF graphs
Following conventional terminology, I satisfies E if I(E)=true, and a
- set S of (simply) entails a graph E if every interpretation of the
- vocabulary of S union E which satisfies every member of S also
+ set S of 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, but throughout this section 'entailment'
should be interpreted as meaning simple entailment.
@@ -980,9 +810,9 @@
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 the appendix, which also
- describes some other properties of entailment which may be of
- interest.
+ which are straightforward, are given in appendix B. Proofs of lemmas,
+ which also describes some other properties of entailment which may be
+ of interest.
Subgraph Lemma. A graph entails all its subgraphs.
@@ -1017,9 +847,9 @@
there is no need to actually construct the merge. If working backwards
from the consequent E, an efficient technique would be to treat blank
nodes as variables in a process of subgraph-matching, allowing them to
- bind to 'matching' names and literals 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, and is also complete if the
+ bind to 'matching' names 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, 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
@@ -1055,15 +885,33 @@
Compactness Lemma. If S entails E and E is a finite graph, then some
finite subset S' of S entails E.
+ 2.1 Vocabulary interpretations and vocabulary entailment
+
+ Simple interpretations and simple entailment capture the semantics of
+ RDF graphs when no attention is paid to the particular meaning of any
+ of any of the names in the graph. To obtain the full meaning of an RDF
+ 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 graph.
+ Interpretations which are required to satisfy extra semantic
+ conditions on 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 interpretation and entailment are indicated by the use of a
+ namespace prefix, so that we will refer to rdf-entailment,
+ rdfs-entailment and so on in what follows. In each case, the
+ vocabulary whose meaning is being restricted, and the exact conditions
+ associated with that vocabulary, are spelled out in detail.
3. Interpreting the RDF Vocabulary
- The RDF vocabulary, rdfV, is a set of URIrefs in the rdf: namespace:
+ The RDF vocabulary, rdfV, is a set of URI references in the rdf:
+ namespace:
RDF vocabulary
rdf:type rdf:Property rdf:XMLLiteral rdf:nil rdf:List rdf:Statement
rdf:subject rdf:predicate rdf:object rdf:first rdf:rest rdf:Seq
- rdf:Bag rdf:Alt rdf:_1 rdf:_2 ...
+ 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 core RDF
@@ -1072,40 +920,50 @@
rdf-interpretations 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
+ 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; any character string which is not well-typed will be called
- ill-typed. The corresponding value, i.e. the Canonical XML data
+ string. The corresponding value, i.e. the Canonical XML data
corresponding to a well-typed XML literal, will be called the XML
- value of the literal. This terminology is deliberately agnostic as to
- whether or not XML data is considered to be identical to a character
- string; note however that the XML data values corresponding to
- well-typed XML literals are in precise 1:1 correspondence with the XML
- literal strings of such literals.
+ 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 rdf-interpretation of a vocabulary V is a simple interpretation I
- of V union crdfV which satisfies the extra conditions described in the
- following table for all names 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.
+ of (V union crdfV) which satisfies the extra conditions described in
+ the following table for all names 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.
+
+ RDF semantic conditions.
x is in IP if and only if <x, I(rdf:Property)> is in IEXT(I(rdf:type))
- If xxx is a well-typed XML literal string in V, then
+ If "xxx"^^rdf:XMLLiteral is in V and xxx is a well-typed XML literal
+ string, then
IL("xxx"^^rdf:XMLLiteral) is the XML data corresponding to xxx;
IL("xxx"^^rdf:XMLLiteral) is in LV;
IEXT(I(rdf:type)) contains <IL("xxx"^^rdf:XMLLiteral),
I(rdf:XMLLiteral)>
- If xxx is an ill-typed XML literal in V, then
+ If "xxx"^^rdf:XMLLiteral is in V and xxx is not a well-typed XML
+ literal string, then
IL("xxx"^^rdf:XMLLiteral) is not in LV;
IEXT(I(rdf:type)) does not contain <IL("xxx"^^rdf:XMLLiteral),
I(rdf:XMLLiteral)>.
- RDF axiomatic triples:
+ The first condition could be regarded as defining 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
+ requires that ill-typed XML literals denote something other than a
+ literal value: this will be the standard way of handling ill-formed
+ typed literals.
+
+ RDF axiomatic triples.
rdf:type rdf:type rdf:Property .
rdf:subject rdf:type rdf:Property .
@@ -1119,16 +977,7 @@
...
rdf:nil rdf:type rdf:List .
- The first condition could be regarded as defining 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
- requires that ill-typed XML literals denote something other than a
- literal value: this will be the standard way of handling ill-formed
- typed literals.
-
- rdfs-interpretations described in section 3.3 below assign further
+ The rdfs-interpretations described in section 4 below assign further
semantic conditions (range and domain conditions) to the properties
used in the RDF vocabulary, and other semantic extensions MAY impose
further conditions so as to further restrict their meanings, provided
@@ -1139,7 +988,9 @@
interpretation in figure 1 to the case where V contains rdfV. For
simplicity, we ignore XML literals in this example.
- IR = LV union {1, 2, T , P}; IP = {1, T}
+ IR = LV union {1, 2, T , P}
+
+ IP = {1, T}
IEXT: 1=>{<1,2>,<2,1>}, T=>{<1,P>,<T,P>}
@@ -1169,7 +1020,8 @@
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 rdf-interpretations instead of all simple
- interpretations.
+ interpretations. Rdf-entailment is an example of vocabulary
+ entailment.
It is easy to see that the lemmas in Section 2 do not all apply to
rdf-entailment: for example, the triple
@@ -1230,7 +1082,7 @@
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.) In the
+ reified triple. (This can be a blank node or a 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
@@ -1245,11 +1097,11 @@
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 itself but
- its interpretation, and so this condition involves a two-stage
- interpretation process: 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
+ value of the rdf:subject property is not the subject URI reference
+ itself but its interpretation, and so this condition involves a
+ two-stage interpretation process: 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
@@ -1471,25 +1323,23 @@
This permits sequences which contain other sequences.
Note that the RDFS semantic conditions, described below, require that
- any subject of rdf:first, and any subject or object of rdf:rest, be of
- rdf:type rdf:List.
+ any subject of the rdf:first property, and any subject or object of
+ the rdf:rest property, be of rdf:type rdf:List.
3.2.4 rdf:value
The intended use for rdf:value is explained intuitively in the RDF
- primer [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, the editor
- is unable to give a precise statement which covers all the intended
- meanings or use cases. Users are cautioned, therefore, that the use of
- rdf:value 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. In practice, the intended meaning is often clear from the
- context, but may be lost when graphs are merged or when conclusions
- are inferred.
+ 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. In
+ practice, the intended meaning is often clear from the context, but
+ may be lost when graphs are merged or when conclusions are inferred.
4. Interpreting the RDFS Vocabulary
@@ -1517,15 +1367,18 @@
stated in terms of a mapping ICEXT (for the Class Extension in I) from
IC to the set of subsets of IR. The meanings of ICEXT and IC in a
rdf-interpretation of the RDFS vocabulary are completely defined by
- the first two conditions in the table 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 the class
- extension of rdfs:Class contains the class rdfs:Class.
+ the first two conditions in the table of 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 the class extension of rdfs:Class contains the
+ class rdfs:Class.
- An rdfs-interpretation of V is an rdf-interpretation I of V union
- crdfV union rdfsV which satisfies the following semantic conditions
+ An rdfs-interpretation of V is an rdf-interpretation I of (V union
+ crdfV union rdfsV) which satisfies the following semantic conditions
and all the triples in the subsequent table, called the RDFS axiomatic
- triples, which contain only names from V union crdfV union rdfsV.
+ triples, which contain only names from (V union crdfV union rdfsV).
+
+ RDFS semantic conditions.
x is in ICEXT(y) if and only if <x,y> is in IEXT(I(rdf:type))
@@ -1540,22 +1393,26 @@
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, IR> is in IEXT(I(rdfs:subClassOf))
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)
+
IEXT(I(rdfs:subClassOf)) is transitive and reflexive on IC
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)) and y is in ICEXT(x) then <y, LV>
is in IEXT(I(rdf:type))
- RDFS axiomatic triples:
+ RDFS axiomatic triples.
rdf:type rdfs:domain rdfs:Resource .
rdfs:domain rdfs:domain rdf:Property .
@@ -1614,6 +1471,8 @@
rdfs:range. Other triples which must be true in all
rdfs-interpretations include the following:
+ Some triples which are RDFS-valid.
+
rdfs:Resource rdf:type rdfs:Class .
rdfs:Class rdf:type rdfs:Class .
rdfs:Literal rdf:type rdfs:Class .
@@ -1655,6 +1514,8 @@
extensions MAY strengthen the range, domain, subclass and subproperty
semantic conditions to the following 'extensional' versions:
+ Extensional alternatives for some RDFS semantic conditions.
+
<x,y> is in IEXT(I(rdfs:subClassOf)) if and only if x and y are in IC
and ICEXT(x) is a subset of ICEXT(y)
@@ -1697,10 +1558,10 @@
<ex:a> rdf:type rdfs:Literal .
- is consistent even though 'ex:a' is a URIref rather than a literal.
- What it says is that I(ex:a) is a literal value, ie that the URIref
- 'ex:a' denotes a literal value. It does not specify exactly which
- literal value it denotes.
+ is consistent even though 'ex:a' is a URI reference rather than a
+ literal. What it says is that I(ex:a) is a literal value, ie that the
+ URI reference 'ex:a' denotes a literal value. It does not specify
+ exactly which literal value it denotes.
The semantic conditions guarantee that any triple containing a simple
literal object entails a similar triple with a blank node as object:
@@ -1712,7 +1573,7 @@
<ex:a> <ex:b> _:xxx .
This means that the literal denotes an entity, which could therefore
- also be named, at least in principle, by a URIref.
+ also be named, at least in principle, by a URI reference.
4.3 RDFS Entailment
@@ -1720,7 +1581,8 @@
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-interpretations instead of all simple
- interpretations.
+ interpretations. Rdf-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
@@ -1736,9 +1598,9 @@
5. Datatyped Interpretations
RDF provides for the use of externally defined datatypes identified by
- a particular URIref. In the interests of generality, RDF imposes
- minimal conditions on a datatype. It also includes a single built-in
- datatype rdf:XMLLiteral.
+ 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
@@ -1756,28 +1618,32 @@
Formally, a datatype d is defined by three items:
- 1. A nonempty set of character strings called the lexical space of d
+ 1. a non-empty set of character strings called the lexical space of d;
+
+ 2. a non-empty set called the value space of d;
- 2. A nonempty set called the value space of d
+ 3. a mapping from the lexical space of d to the value space of d,
+ called the lexical-to-value mapping of d.
- 3. A mapping L2V(d) 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 written as L2V(d).
In stating the semantics we assume that interpretations are
relativized to a particular set of datatypes each of which is
- identified by a URIref.
+ identified by a URI reference.
- Formally, let D be a set of pairs consisting of a URIref and a
- datatype such that no URIref appears twice in the set, so that D can
- be regarded as a function from a set of URIrefs to a set of datatypes:
- call this a datatype map. (The particular URIrefs 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, x> where x is the built-in XML Literal datatype whose
- lexical and value spaces and lexical-to-value mapping are defined in
- the RDF concepts and abstract syntax document [RDF-CONCEPTS]. The
- datatype map which also contains the set of all pairs of the form
+ Formally, let D be a set of pairs consisting of a URI reference and a
+ datatype such that no URI reference appears twice in the set, so that
+ D can be regarded as a function from a set of URI references to a set
+ of 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, x> where x is the built-in XML
+ Literal datatype whose lexical and value spaces and lexical-to-value
+ mapping are defined in the RDF Concepts and Abstract Syntax document
+ [RDF-CONCEPTS].
+
+ The datatype map which also contains the set of all pairs of the form
<http://www.w3.org/2001/XMLSchema#sss, sss>, where sss is a built-in
datatype named sss in XML Schema Part 2: Datatypes [XML-SCHEMA2] and
listed in the following table, is referred to here as XSD.
@@ -1808,22 +1674,24 @@
which satisfies the following extra conditions for every pair <aaa, x>
in D:
+ General semantic conditions for datatypes.
+
if <aaa,x> is in D then I(aaa) = x
if <aaa,x> is in D then ICEXT(x) is the value space of x and is a
subset of LV
if <aaa,x> is in D then for any typed literal "sss"^^ddd with I(ddd) =
x ,
- ifsss is in the lexical space of x then IL("sss"^^ddd) =
+ if sss is in the lexical space of x then IL("sss"^^ddd) =
L2V(x)(sss), otherwise IL("sss"^^ddd) is not in LV
if <aaa,x> is in D then I(aaa) is in ICEXT(I(rdfs:Datatype))
- The first condition ensures that I interprets the URIref according to
- the datatype map provided. Note that this does not prevent other
- URIrefs from also denoting the datatype.
-
- The second condition ensures that the datatype URIref, when used as a
- class name, refers to the value space of the datatype, and that all
- elements of a value space must be literal values.
+ The first condition ensures that I interprets the URI reference
+ according to the datatype map provided. Note that this does not
+ prevent other URI references from also denoting the datatype.
+
+ The second condition ensures that the datatype URI reference, when
+ used as a class name, refers to the value space of the datatype, and
+ that all elements of a value space must be literal values.
The third condition ensures that typed literals respect the datatype
lexical-to-value mapping. For example, if I is an XSD-interpretation
@@ -1835,17 +1703,18 @@
the semantics requires such a typed literal to denote an 'arbitrary'
non-literal value. Thus for example, if I is an XSD-interpretation,
then all that can be concluded about I("arthur"^^xsd:decimal) is that
- it is not in ICEXT(I(rdfs:Literal)). An ill-typed literal does not in
- itself constitute an inconsistency, but a graph which entails that an
- ill-typed literal has rdf:type rfds:Literal would be inconsistent.
+ it is not in LV, i.e. not in ICEXT(I(rdfs:Literal)). An ill-typed
+ literal does not in itself constitute an inconsistency, but a graph
+ which entails that an ill-typed literal has rdf:type rdfs:Literal
+ would be inconsistent.
Note that this third condition applies only to datatypes in the range
of D. Typed literals whose type is not in the datatype map of the
interpretation are treated as before, i.e. as denoting some unknown
- thing. The condition does not require that the URIref in the typed
- literal be the same as the associated URIref of the datatype; this
- allows semantic extensions which can express identity conditions on
- URIrefs to draw appropriate conclusions.
+ thing. The condition does not require that the URI reference in the
+ typed literal be the same as the associated URI reference of the
+ datatype; this allows semantic extensions which can express identity
+ conditions on URI references to draw appropriate conclusions.
The fourth condition ensures that the class rdfs:Datatype contains the
datatypes used in any satisfying D-interpretation. Notice that this is
@@ -1876,9 +1745,9 @@
extensions of I(xsd:decimal) and I(xsd:string) would have a nonempty
intersection.
- Datatype clashes and assertions that ill-typed literals are of type
- rdfs:Literal are the only inconsistencies recognized by this model
- theory.
+ The only inconsistencies recognized by this model theory are datatype
+ clashes and assertions that ill-typed literals are of type
+ rdfs:Literal.
If D is a subset of D', then restricting interpretations of a graph to
D'-interpretations amounts to a semantic extension compared to the
@@ -1890,18 +1759,18 @@
also reveal datatype clashes and violations, so that a D-consistent
graph could be D'-inconsistent.
- Say that an RDF graph recognizes a datatype URIref aaa when the graph
- rdfs-entails a datatyping triple of the form
+ Say that an RDF graph recognizes a datatype URI reference aaa when the
+ graph rdfs-entails a datatyping triple of the form
aaa rdf:type rdfs:Datatype .
The semantic conditions for rdfs-interpretations require the built-in
- datatype URIref 'rdf:XMLLiteral' to be recognized.
+ datatype URI reference 'rdf:XMLLiteral' to be recognized.
- If every recognized URIref in a graph is the name of a known datatype,
- then there is a natural datatype map DG which pairs each recognized
- URIref to that known datatype (and 'rdf:XMLliteral' to
- rdf:XMLliteral). Any rdfs-interpretation I of that graph then has a
+ If every recognized URI reference in a graph is the name of a known
+ datatype, then there is a natural datatype map DG which pairs each
+ recognized URI reference to that known datatype (and 'rdf:XMLliteral'
+ to rdf:XMLliteral). Any rdfs-interpretation I of that graph then has a
corresponding 'natural' DG-interpretation which is like I except that
I(aaa) is the appropriate datatype and the class extension of
rdfs:Datatype is modified appropriately. Applications MAY require that
@@ -1921,7 +1790,7 @@
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 D-interpretations instead of all simple
- interpretations.
+ interpretations. D-entailment is an example of vocabulary entailment.
As noted above, it is possible that a graph which is consistent in one
vocabulary becomes inconsistent in a semantic extension defined on a
@@ -1967,37 +1836,40 @@
rather than a merge, with the conclusion, and hence preserves any
blank nodes already in the graph.
- These rules all use the following conventions: uuu stands for any
- URIref or blank node, vvv for any URIref or literal, aaa, bbb, etc.,
- for any URIref, and xxx, yyy etc. for any URIref, blank node or
- literal.
+ These rules all use the following conventions: uuu stands for any URI
+ reference or blank node identifier, vvv for any URI reference or
+ literal, aaa, bbb, etc., for any URI reference, and xxx, yyy etc. for
+ any URI reference, blank node identifier or literal.
7.1 Simple Entailment Rules
- The instance lemma in Section 2 can be stated as an inference rule on
- triples.
+ The instance lemma in Section 2 can be stated as inference rules on
+ triples:
+
+ simple entailment rules.
Rule name If E contains then add
se1 uuu aaa vvv .
uuu aaa _:nnn .
- where _:nnn is a blank node allocated to vvv by rule se1 or se2.
+ where _:nnn is a blank node identifier allocated to vvv by rule se1 or
+ se2.
se2 bbb aaa xxx .
_:nnn aaa xxx .
- where _:nnn is a blank node allocated to bbb by rule se1 or se2.
+ where _:nnn is a blank node identifier allocated to bbb by rule se1 or
+ se2.
The terminology 'allocated to' means that the blank node must have
been created by an earlier application of the specified rules on the
- same URIref or literal bbb or vvv, 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
- association between introduced blank nodes and the URIref or literal
- that they replace provides the instance mapping. For example, the
- graph
+ 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 association
+ between introduced blank nodes and the URI reference or literal that
+ they replace provides the instance mapping. For example, the graph
<ex:a> <ex:p> <ex:b> .
<ex:c> <ex:q> <ex:a> .
@@ -2014,10 +1886,11 @@
ex:c )
These rules could be stated as a rule which takes as input any
- subgraph of triples all containing a given URIref or literal in the
- subject or object position, and adding a copy of this whole subgraph
- with the URIref or literal replaced by a single 'new' blank node. Such
- a formulation would not require the 'allocation' terminology.
+ subgraph of triples all containing a given URI reference or literal in
+ the subject or object position, and adding a copy of this whole
+ subgraph with the URI reference or literal replaced by a single 'new'
+ blank node. Such a formulation would not require the 'allocation'
+ terminology.
Applying these rules to a graph will produce a graph which is simply
entailed by the original. These rules will not generate all graphs
@@ -2029,6 +1902,8 @@
7.2 RDF Entailment Rules
+ RDF entailment rules
+
Rule Name if E contains then add
rdf1 xxx aaa yyy . aaa rdf:type rdf:Property .
rdf2
@@ -2039,7 +1914,7 @@
xxx aaa _:nnn .
_:nnn rdf:type rdf:XMLLiteral .
- where _:nnn is a blank node allocated to lll by this rule.
+ where _:nnn is a blank node identifier allocated to lll by this rule.
Applying these and the earlier rules to a graph produces a graph which
is rdf-entailed by the original. Note also that the RDF axiomatic
@@ -2050,11 +1925,13 @@
RDF entailment lemma. S rdf-entails E if and only if there is a graph
which can be derived from S plus the RDF axiomatic triples by the
- application of the simple and RDF entailment rules and which simply
- entails E. (Proof in Appendix B)
+ application of the simple entailment rules and RDF entailment rules
+ and which simply entails E. (Proof in Appendix B)
7.3 RDFS Entailment Rules
+ RDFS entailment rules.
+
Rule Name If E contains: then add:
rdfs1
@@ -2115,8 +1992,8 @@
triples by the application of the simple, RDF and RDFS entailment
rules and which simply entails E. (Proof in Appendix B)
- These rules are somewhat redundant. All but one of the RDF axiomatic
- triples can be derived from the rules rdfs2 and 3 and the RDFS
+ These rules are somewhat redundant. All but one of the RDFaxiomatic
+ 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.
@@ -2127,7 +2004,7 @@
names used in the graph, and rdfs3 together with the last RDFS
axiomatic triple will add all 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 and 3 and the
+ type assertions for its subject and object via rdfs2 and rdfs3 and the
domain and range assertions in the RDFS axiomatic triple set. The
rules will generate all assertions of the form
@@ -2141,7 +2018,7 @@
rdf:Property rdf:type rdfs:Class .
- 7.3.1 Extensional Entailment Rules
+ 7.3.1 Extensional Entailment Rules (Informative)
The stronger extensional semantic conditions described in Section 4.1
sanction further entailments which are not covered by the RDFS rules.
@@ -2161,6 +2038,9 @@
to superproperties of rdfs:range and rdfs:domain. None of these cases
are likely to arise in practice.
+ Some additional inferences which would be valid under the extensional
+ versions of the RDFS semantic conditions.
+
ext1
xxx rdfs:domain yyy .
@@ -2195,23 +2075,23 @@
7.4 Datatype Entailment Rules
In order to capture datatype entailment in terms of assertions and
- closure rules, the rules need to refer to information supplied by the
- datatypes themselves; and to state the rules it is necessary to assume
- syntactic conditions which can only be checked by consulting the
- datatype sources.
+ entailment rules, the rules need to refer to information supplied by
+ the datatypes themselves; and to state the rules it is necessary to
+ assume syntactic conditions which can only be checked by consulting
+ the datatype sources.
For each kind of information which is available about a datatype,
inference rules for information of that kind can be stated, which can
- be thought of as extending the table of RDFS closure rules. These
+ be thought of as extending the table of RDFS entailment rules. These
should be understood as applying to datatypes other than the built-in
- datatype, the rules for which are part of the RDFS closure rules. The
- rules stated below assume that information is available about the
- datatype denoted by a recognized URIref, and they use that URIref to
- refer to the datatype.
+ datatype, the rules for which are part of the RDFS entailment rules.
+ The rules stated below assume that information is available about the
+ datatype denoted by a recognized URI reference, and they use that URI
+ reference to refer to the datatype.
The basic information specifies, for each literal string, whether or
- not it is a legal lexical form for the dataype, i.e. one which maps to
- some value under the lexical-to-value mapping of the datatype. This
+ not it is a legal lexical form for the 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 denoted by ddd:
@@ -2223,7 +2103,8 @@
aaa ppp _:xxx .
_:xxx rdf:type ddd .
- where _:xxx is a blank node allocated to "sss"^^ddd by this rule.
+ where _:xxx is a blank node identifier allocated to "sss"^^ddd by this
+ rule.
Suppose it is known that two lexical forms sss and ttt map to the same
value under the datatype denoted by ddd; then the following rule
@@ -2298,16 +2179,30 @@
aaa ppp _:xxx .
_:xxx rdf:type eee . (by rule rdfD 1)
- _:xxx rdf:type ddd . (by rule rdfs 3)
+ _:xxx rdf:type ddd . (by rule rdfs3)
These rules do not provide a complete set of inference principles for
D-entailment, since there may be valid D-entailments for particular
datatypes which depend on idiosyncratic properties of the particular
datatypes, such as the size of the value space (eg xsd:boolean has
only two elements, so anything established for those two values must
- be true for all literals with this datatype.)
+ be true for all literals with this datatype.) In particular, the value
+ space and lexical-to-value mapping of the XSD datatype xsd:string
+ sanctions the identification of typed literals with plain literals
+ without language tags for all character strings which are in the
+ lexical space of the datatype, since both of them denote the Unicode
+ character string which is displayed in the literal; so the following
+ inference rule is valid in all XSD-interpretations. Here, 'sss'
+ indicates any string of characters in the lexical space of xsd:string.
+
+ xsd 1a uuu aaa "sss". uuu aaa "sss"^^xsd:string .
+ xsd 1b uuu aaa "sss"^^xsd:string . uuu aaa "sss".
+
+ Again, as with the rules rdfD2 and rdfD3, applications may use a
+ systematic replacement of one of these equivalent forms for the other
+ rather than apply these rules directly.
-Appendix A: Translation into L[base]
+Appendix A: Translation into L[base]. (Informative)
As noted in the introduction, an alternative way to specify
rdf-interpretations is to give a translation from RDF into a formal
@@ -2325,36 +2220,42 @@
To translate an RDF graph into L[base], apply the following rules to
each expression noted. Each rule gives a translation TR[E] for the
expression E, to be applied recursively. To achieve a translation
- which reflects a vocabulary entailment, add the axioms specified. Each
- vocabulary includes all axioms and rules for preceding vocabularies,
- so that the RDFS translation of a graph should include the RDF
- translation as well as the RDF and RDFS axioms, and so on. (Note, the
- document [LBASE], written earlier, contains a description of a
- different translation for illustrative purposes. The translation given
- here is more accurate.)
-
- This translation uses the L[base] logical expressions Lbase:String and
- Lbase:NatNumber, which are true respectively of Unicode character
- strings, and natural numbers, and it introduces some terminology in
- order to give a logical account of the meanings implicit in the
- various literal constructions. The built-in datatype rdf:XMLLiteral is
- treated uniformly with the other datatypes, later. The RDFS axioms use
- a predicate LanguageTag which is supposed to be true of all and only
- the strings which are legal XML language tags; the axioms would need
- to be supplemented by a suitable way of determining the truth of
- instances of this predicate in order to be used to check RDF literal
- syntax adequately.
+ which reflects a vocabulary entailment, add the axioms specified;
+ except that the RDF translation does not deal with XML typed literals,
+ which are handled as a datatype in this translation, for simplicity.
+ Each vocabulary includes all axioms and rules for preceding
+ vocabularies, so that the RDFS translation of a graph should include
+ the RDF translation as well as the RDF and RDFS axioms, and so on.
+ (Note, the document [LBASE], written earlier, contains a description
+ of a different translation for illustrative purposes. The translation
+ given here is more accurate.)
+
+ This translation uses the L[base] special names String and NatNumber,
+ which are true respectively of Unicode character strings and natural
+ numbers, and it introduces some terminology in order to give a logical
+ account of the meanings implicit in the various literal constructions.
+ Note that special names are not URI references. The built-in datatype
+ rdf:XMLLiteral is treated uniformly with the other datatypes, later,
+ so that the RDF translation given here is strictly incomplete as it
+ stands. The RDFS axioms use a predicate LanguageTag which is supposed
+ to be true of all and only the strings which are legal XML language
+ tags; the axioms would need to be supplemented by a suitable way of
+ determining the truth of instances of this predicate in order to be
+ used to check RDF literal syntax adequately.
+
+ Note, these translation rules ignore issues of character escaping in
+ encoding character strings in literals: an implementation based on
+ these rules might need to use more care with strings containing the
+ characters ' and \. .
CAPTION: L[base] translation rules
RDF expression E L[base] expression TR[E]
- a character string sss sss , with all occurrences of the symbols
- ',\,(,),<,> prefixed with \
- a plain literal "sss" 'TR[sss]'
- a plain literal "sss"@ttt the term pair('TR[sss]','ttt')
- a typed literal "sss"^^ddd the term LiteralValueOf('TR[sss]','ddd')
- a URIref of the form rdf:_nnn rdf-member(nnn)
- any other URIref aaa aaa
+ a plain literal "sss" 'sss'
+ a plain literal "sss"@ttt the term pair('sss','ttt')
+ a typed literal "sss"^^ddd the term LiteralValueOf('sss',TR[ddd])
+ a URI reference of the form rdf:_nnn rdf-member(nnn)
+ any other URI reference aaa aaa
a blank node a variable (one distinct variable per blank node)
a triple
aaa rdf:type bbb . TR[bbb](TR[aaa]) and rdfs:Class(TR[bbb])
@@ -2379,7 +2280,7 @@
rdf:Property(rdf:value)
rdf:List(rdf:nil)
- Lbase:NatNumber(?x) implies rdf:Property(rdf-member(?x))
+ NatNumber(?x) implies rdf:Property(rdf-member(?x))
pair(?x,?y)=pair(?u,?v) iff (?x=?u and ?y=?v) ;; uniqueness for pairs,
required by graph syntax rules.
@@ -2420,14 +2321,13 @@
rdf:XMLLiteral(?x) implies rdfs:Literal(?x)
- Lbase:String(?y) implies rdfs:Literal(?y)
+ String(?y) implies rdfs:Literal(?y)
- (Lbase:String(?x) and LanguageTag(?y)) implies
- rdfs:Literal(pair(?x,?y))
+ (String(?x) and LanguageTag(?y)) implies rdfs:Literal(pair(?x,?y))
rdfs:Datatype(?x) implies (?x(?y) implies rdfs:Literal(?y) )
- Lbase:NatNumber(?x) implies
+ NatNumber(?x) implies
(rdfs:ContainerMembershipProperty(rdf-member(?x)) and
rdfs:domain(rdf-member(?x),rdfs:Resource) and
rdfs:range(rdf-member(?x), rdfs:Resource) )
@@ -2503,6 +2403,7 @@
following axioms:
rdfs:range(?x,?y) iff ( ?x(?u,?v)) implies ?y(?v) )
+
rdfs:domain(?x,?y) iff ( ?x(?u,?v)) implies ?y(?u) )
rdfs:subClassOf(?x ?y) iff
@@ -2530,7 +2431,7 @@
falsity of the appropriate ground atoms.
A datatype theory for the datatype map {<ddd, datatype>} (where ddd is
- a URIref) is the set containing the axiom
+ a URI reference) is the set containing the axiom
rdfs:Datatype(ddd)
@@ -2564,12 +2465,11 @@
more conventional notations.
In some cases, a datatype theory can be summarized in a finite number
- of axioms. For example, if one believes that elements of xsd:string
- are the same strings that occur in untyped RDF literals, then the
- datatype theory could be summarized by a single axiom:
+ of axioms. For example, the datatype theory for xsd:string can be
+ stated by a single axiom:
- (Lbase:string(?x) iff xsd:string(?x) ) and
- LiteralValueOf(?x,xsd:string) = ?x
+ (String(?x) iff xsd:string(?x) ) and (String(?x) implies
+ LiteralValueOf(?x,xsd:string) = ?x )
CAPTION:
RDF Datatyped Literal axioms
@@ -2584,12 +2484,12 @@
Further information about subclass relationships between value spaces
of datatypes can be expressed in L[base] directly in terms of
- rdfs:subClassOf, or equivalently by using the datatype URIrefs as
- property names.
+ rdfs:subClassOf, or equivalently by using the datatype URI references
+ as property names.
-Appendix B: Proofs of Lemmas
+Appendix B: Proofs of Lemmas (Informative)
"One of the merits of a proof is that it instills a certain doubt as
to the result proved." -Bertrand Russell
@@ -2633,8 +2533,9 @@
literal values (well-formed XML literals in V, character strings and
pairs of character strings and language tags); IR is LV plus all names
and blank nodes which occur in a subject or object position in a
- triple in G; IP is the set of URIrefs which occur in the property
- position of any triple in G or as the subject of a triple of the form
+ triple in G; IP is the set of URI references which occur in the
+ property position of any triple in G or as the subject of a triple of
+ the form
s rdf:type rdf:Property .; IS is the identity mapping on V, IL maps
all typed literals into themselves, and IEXT is defined by: <s,o> is
in IEXT(p) just when there is a triple in the graph of the form s p o
@@ -2647,11 +2548,11 @@
identity mapping on blank nodes of G, then Herb(G)+A satisfies the
entire graph; so Herb(G) satisfies G.
- Herbrand interpretations treat URIrefs and typed literals in the same
- way as simple literals, i.e. as denoting their own syntactic forms. Of
- course this may not be what was intended by the writer of the RDF, but
- the lemma shows that any graph can be interpreted in this way. This
- therefore establishes a useful result:
+ Herbrand interpretations treat URI references and typed literals in
+ the same way as simple literals, i.e. as denoting their own syntactic
+ forms. Of course this may not be what was intended by the writer of
+ the RDF, but the lemma shows that any graph can be interpreted in this
+ way. This therefore establishes a useful result:
Satisfaction Lemma. Any RDF graph has a satisfying interpretation. QED
@@ -2777,8 +2678,8 @@
RDF entailment lemma. S rdf-entails E if and only if there is a graph
which can be derived from S plus the RDF axiomatic triples by the
- application of the simple and RDF entailment rules and which simply
- entails E.
+ application of the simple entailment rules and RDF entailment rules
+ and which simply entails E.
Proof. To show 'if' here is trivial: one has only to check that the
RDF entailment rules are rdf-valid, which is left as an exercise
@@ -2787,10 +2688,10 @@
Define the rdf-V-closure of a graph G, rdfclos(V, G), to be the
graph gotten by adding all the RDF axiomatic triples which contain
any vocabulary from (V union crdfV) to G and then applying the
- simple and RDF entailment rules in all possible ways until the
- graph is unchanged. Define the combined vocabulary vocab(S) union
- vocab(E) to be W. We will show that rdfclos(W, S) satisfies the
- conditions of the lemma.
+ simple entailment rules and RDF entailment rules in all possible
+ ways until the graph is unchanged. Define the combined vocabulary
+ vocab(S) union vocab(E) to be W. We will show that rdfclos(W, S)
+ satisfies the conditions of the lemma.
Let H be the Herbrand interpretation of rdfclos(W, S). It is
sufficient to show that there is an rdf-interpretation H' of W with
@@ -2801,8 +2702,8 @@
H' is constructed from H by adjusting the interpretation of
well-typed XML literals and the class extension of rdf:XMLLiteral;
- in other respects H' and H are identical (so that for any other
- URIref uuu, I[H'](uuu)=I[H](uuu)=uuu.) To be precise, for each
+ in other respects H' and H are identical (so that for any other URI
+ reference uuu, I[H'](uuu)=I[H](uuu)=uuu.) To be precise, for each
well-typed XML literal x in W, define H'(x) to be the XML value of
x; and let IEXT[H'](rdf:type) = IEXT[H](rdf:type) union {<I[H'](x),
rdf:XMLLiteral>: x a well-typed XML literal in W}. H' differs from
@@ -2848,8 +2749,8 @@
closure, rdfsclos(V,G), is the graph gotten by adding the
appropriate RDF and RDFS axiomatic triples to G, and then applying
the simple, RDF and RDFS entailment rules until the graph is
- unchanged. Let H be the Herbrand intepretation of rdfsclos(W,S) and
- H' be constructed from H as in the previous proof, except that
+ unchanged. Let H be the Herbrand interpretation of rdfsclos(W,S)
+ and H' be constructed from H as in the previous proof, except that
IEXT[H'](rdf:type) = IEXT[H](rdf:type) union {<I[H'](x),
rdf:XMLLiteral>: x a well-typed XML literal in W}union {<I[H'](x),
@@ -2857,7 +2758,7 @@
The projection mapping which establishes that H'<<H is extended in
the obvious way and rule rdfs1 shows that the truth of triples is
- preserved under the projection.(This technique for using blank
+ preserved under the projection. (This technique for using blank
nodes as 'surrogates' for literals is a general one; it depends on
the blank node first introduced by the existential rule being
uniquely mappable from the term to which it is allocated.)
@@ -2869,8 +2770,8 @@
indistinguishable.
This is done by simply matching the RDFS semantic conditions with
- the appropriate closure rules. We will illustrate the form of the
- argument with two examples.
+ the appropriate entailment rules. We will illustrate the form of
+ the argument with two examples.
Consider the first semantic condition. Suppose <x,y> is in
IEXT[H](rdfs:domain) and <u,v> is in IEXT[H](x); then by the
@@ -2889,7 +2790,7 @@
In some cases, the rule derivation involves several steps and some
of the RDF and RDFS axiomatic triples; for example, to show that H
- satisfies the condition
+ satisfies the seventh semantic condition
If <x,y> is in IEXT(I(rdfs:subClassOf)) then x and y are in IC and
ICEXT(x) is a subset of ICEXT(y)
@@ -2932,12 +2833,12 @@
the new skolem functions.
In RDF, Skolemization simplifies to the special case where an
- existential variable is replaced by a 'new' name, i.e. a URIref which
- is guaranteed to not occur anywhere else. (Using a literal would not
- do. Literals are never 'new' in the required sense, since their
- meaning is fixed.) To be precise, a Skolemization of E (with respect
- to V) is a ground instance of E with respect to a vocabulary V which
- is disjoint from the vocabulary of E.
+ existential variable is replaced by a 'new' name, i.e. a URI reference
+ which is guaranteed to not occur anywhere else. (Using a literal would
+ not do. Literals are never 'new' in the required sense.) To be
+ precise, a Skolemization of E (with respect to V) is a ground instance
+ of E with respect to a vocabulary V which is disjoint from the
+ vocabulary of E.
The following lemma shows that Skolemization has the same properties
in RDF as it has in conventional logics. Intuitively, this lemma shows
@@ -2945,11 +2846,11 @@
asserting the original graph, in many respects. In effect, it simply
gives 'arbitrary' names to the anonymous entities whose existence was
asserted by the use of blank nodes. However, care is needed, since
- these 'arbitrary' names have the same status as any other URIrefs once
- published. Also, Skolemization would not be an appropriate operation
- when applied to anything other than the antecendent of an entailment.
- A Skolemization of a query would represent a completely different
- query.
+ these 'arbitrary' names have the same status as any other URI
+ references once published. Also, Skolemization would not be an
+ appropriate operation when applied to anything other than the
+ antecendent of an entailment. A Skolemization of a query would
+ represent a completely different query.
Skolemization Lemma. Suppose sk(E) is a skolemization of E with
respect to V. Then sk(E) entails E; and if sk(E) entails F and the
@@ -3051,11 +2952,8 @@
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 here is
- basically intensional but has some extensional aspects, most notably
- in the 'if and only if' conditions in the definitions of
- rdfs:subClassOf and rdfs:subPropertyOf, which force these properties
- to take account only of the class and property extensions.)
+ 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
@@ -3205,38 +3103,42 @@
Normative
- [OWL]
- Web Ontology Language (OWL) Reference Version 1.0, Dean, M.,
- Connolly, D., van Harmelen, F., Hendler, J., Horrocks, I.,
- McGuinness, D., Patel-Schneider, P., Stein, L. (Editors), World
- Wide Web Consortium Working Draft, 12 November 2002
-
[RDF-CONCEPTS]
Resource Description Framework (RDF): Concepts and Abstract
- Syntax, Klyne G., Carroll J. (Editors), World Wide Web
- Consortium, November 2002 (work in progress).
+ Syntax , G. Klyne, J. Carroll, Editors, World Wide Web
+ Consortium Last Call Working Draft, work in progress, 28 July
+ 2003. This version of the RDF Concepts and Abstract Syntax is
+ http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/.
+ The latest version of the RDF Concepts and Abstract Syntax is
+ at http://www.w3.org/TR/rdf-concepts/.
[RDF-SYNTAX]
RDF/XML Syntax Specification (Revised), Beckett D. (Editor),
- World Wide Web Consortium, November 2002.
-
- [RDF-VOCABULARY]
- RDF Vocabulary Description Language 1.0: RDF Schema, Brickley
- D., Guha R.V. (Editors), World Wide Web Consortium, November
- 2002.
+ World Wide Web Consortium Working Draft, 23 January 2003 (work
+ in progress). This version is
+ http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/. The
+ latest version is http://www.w3.org/TR/rdf-syntax-grammar/
[RDF-TESTS]
- RDF Test Cases, Grant J., Beckett D. (Editors) World Wide Web
- Consortium, November 2002.
+ RDF Test Cases , J. Grant and D. Beckett, Editors, World Wide
+ Web Consortium Last Call Working Draft, work in progress, 23
+ January 2003. This version of the RDF Test Cases is
+ http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-testcases-20030117/
+ . The latest version of the RDF Test Cases is at
+ http://www.w3.org/TR/rdf-testcases/.
[RDFMS]
Resource Description Framework (RDF) Model and Syntax
- Specification, Lassila O., Swick R. R. (Editors), World Wide
- Web Consortium, 22 February 1999.
+ Specification , O. Lassila and R. Swick, Editors. World Wide
+ Web Consortium. 22 February 1999. This version is
+ http://www.w3.org/TR/1999/REC-rdf-syntax-19990222. The latest
+ version of RDF M&S is available at
+ http://www.w3.org/TR/REC-rdf-syntax.
[RFC 2119]
- RFC 2119 - Key Words for use in RFCs to Indicate Requirement
- Levels Bradner, S., March 1997
+ RFC 2119 - Key words for use in RFCs to Indicate Requirement
+ Levels , S. Bradner, IETF. March 1997. This document is
+ http://www.ietf.org/rfc/rfc2119.txt.
[RFC 2396]
RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax
@@ -3244,14 +3146,14 @@
[XML 1.0]
Extensible Markup Language (XML) 1.0 (Second Edition) , Bray,
- T.,Paoli, J.,Sperberg-McQueen, C. M., Maler, E. W3C Working
+ T., Paoli, J., Sperberg-McQueen, C. M., Maler, E. W3C Working
Draft, 14 August 2000
[XML-C14N]
Exclusive XML Canonicalization Version 1.0, Boyer, J., Eastlake
3rd, D.E., Reagle, J., Authors/Editors. W3C Recommendation.
- World Wide Web Consortium, 18 July 2002.
- This version of Exclusive XML Canonicalization is
+ World Wide Web Consortium, 18 July 2002. This version of
+ Exclusive XML Canonicalization is
http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718. The latest
version of Canonical XML is at
http://www.w3.org/TR/xml-exc-c14n.
@@ -3262,6 +3164,12 @@
Non-Normative
+ [OWL]
+ Web Ontology Language (OWL) Reference Version 1.0, Dean, M.,
+ Connolly, D., van Harmelen, F., Hendler, J., Horrocks, I.,
+ McGuinness, D., Patel-Schneider, P., Stein, L. (Editors), World
+ Wide Web Consortium Working Draft, 12 November 2002
+
[Conen&Klapsing]
A Logical Interpretation of RDF, Conen, W., Klapsing,
R..Circulated to RDF Interest Group, August 2000.
@@ -3277,8 +3185,8 @@
Upper Ontology, August 2001.
[KIF]
- Michael R. Genesereth, Knowledge Interchange Format, 1998
- (draft American National Standard).
+ Michael R. Genesereth et. al., Knowledge Interchange Format,
+ 1998 (draft American National Standard).
[Marchiori&Saarela]
Query + Metadata + Logic = Metalog, Marchiori, M., Saarela, J.
@@ -3294,13 +3202,153 @@
Systems, Vol. 17, No. 5, September/October 2002.
[RDF-PRIMER]
- RDF Primer, Manola F., Miller E. (Editors), World Wide Web
- Consortium W3C Working Draft, November 2002.
-
+ RDF Primer, F. Manola, E. Miller, Editors, World Wide Web
+ Consortium W3C Working Draft, work in progress, 26 April 2002.
+ This version of the RDF Primer is
+ http://www.w3.org/TR/2002/WD-rdf-primer-20020426/. The latest
+ version of the RDF Primer is at
+ http://www.w3.org/TR/rdf-primer/.
+ [RDF-VOCABULARY]
+ RDF Vocabulary Description Language 1.0: RDF Schema , D.
+ Brickley, R.V. Guha, Editors, World Wide Web Consortium Last
+ Call Working Draft, work in progress, 23 January 2003. This
+ version of the RDF Vocabulary Description Language is
+ http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-schema-20030117.
+ The latest version of the RDF Vocabulary Description Language
+ is at http://www.w3.org/TR/rdf-schema.
_________________________________________________________________
+Appendix E: Change Log. (Informative)
+ Recent changes to the text (in the last few days) are highlighted in
+ red.
+
+ Changes since the 23 January 2003 last call working draft.
+
+ Editorial.
+
+ The following changes do not effect the technical content
+
+ Many small changes to wording and document organization to improve
+ clarity, remove ambiguities, make definitions clearer, etc. and for
+ conformity with other RDF documents and W3C house style, following
+ review comments by Lech. The definition of 'graph merge' has been
+ rewritten, following review comments by Patel-Schneider and Beckett.
+ The background colors have been changed to avoid red/green confusion
+ and internal links highlighted with background color in the text. Some
+ of the lemmas have been re-stated more economically. The semantic
+ conditions are now aligned exactly with the vocabularies, so that RDF
+ interpretations exactly constrain the rdf: vocabulary, etc.. Some of
+ the section numbers and titles have been changed to better reflect
+ this realignment. The term 'namespace' has been replaced by
+ 'vocabulary' , cf pfps-21
+
+ The informative appendices on Lbase and the proof appendix have been
+ extensively rewritten and errors corrected, cf. pfps-02. The text of
+ the datatypes section been extensively rewritten following technical
+ changes noted below; the older version was ambiguous and underdefined.
+ The XSD datatypes suitable for RDF use are listed explicitly in the
+ text, cf. pfps-01.
+
+ Technical/editorial.
+
+ The following changes do not affect any entailments or test cases.
+
+ Lexical and value spaces of datatypes are required to be nonempty,
+ following email comments by Patel-Schneider.
+
+ In simple interpretations, IP is no longer required to be a subset of
+ IR in all interpretations.
+ This does not affect RDF or RDFS interpretations but makes the
+ model theory more conventional and may help with layering
+ future semantic extensions onto RDF. Text has been added to
+ clarify why RDF interpretations are unchanged.
+
+ "Vocabulary" is now defined to include typed literals as well as URI
+ references; definition of 'name' changed accordingly.
+ This is required by the new treatment of datatypes and is more
+ conventional.
+
+ The set LV of literal values is no longer considered 'global' but is
+ part of an interpretation.
+ This is more conventional and makes the semantics easier to
+ state and simplifies the proofs. LV is required to be the class
+ extension of rdfs:Literal in all RDFS interpretations, cf.
+ pfps-06. This clarifies and rationalizes a source of confusion
+ noted in pfps-10.
+
+ The account of datatyped interpretations has been stated relative to a
+ 'datatype map' from URI references to datatypes.
+ This was adopted after email discussions with Patel-Schneider,
+ cf pfps-08 and pfps-09 et. seq.. The older, simpler, treatment
+ was not adequate for compatibility with OWL. (WG decision
+ recorded
+ http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003May/0199
+ .html)
+
+ The definition of rdf-interpretation refers to a 'core' vocabulary.
+ This avoids a technical awkwardness arising from the infinite
+ container vocabulary.
+
+ The reference [RDF_VOCABULARY] is not a normative reference.
+ (WG decision recorded
+ http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jul/0236
+ )
+
+
+ Substantial.
+
+ All the following changes cause changes to some entailments, and all
+ reflect WG decisions.
+
+ 1. The treatment of language tags in literals has been simplified.
+ Typed literals, including XML literals, no longer have associated
+ language tags. (WG decision recorded
+ http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003May/0138.html)
+ There are therefore three types of literal: plain without a language
+ tag, plain with a language tag, and typed literals.
+
+ XML literals are required to be in canonical form, and to denote
+ entities which are distinct from any character string.(WG decision
+ recorded
+ http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jun/0156.html)
+
+ The chief effect of these decisions in this document is that XML
+ literals can be treated uniformly with other typed literals. However,
+ the rdf semantic conditions on rdfs:XMLLiteral are stated without
+ explicit reference to datatypes in order to make it possible for a
+ conforming RDF inference system to avoid full datatyping. The accounts
+ of rdfs:XMLLiteral given for RDF, and for RDF with datatyping, are in
+ exact correspondence. This change is relevant to the last call
+ comments: pfps-02, pfps-06, pfps-07.
+
+ 2. The treatment of rdfs:subClassOf and rdfs:subPropertyOf has been
+ changed. They are no longer required to satisfy 'iff' semantic
+ conditions, but only to be transitive and reflexive. This decision was
+ taken as a result of the felt need to support simple complete sets of
+ inference rules for RDFS. We are grateful to Herman ter Horst and
+ Patel-Schneider for noticing the complexities which arose from the
+ older conditions, c.f. horst-01 et. seq.. (WG decision recorded
+ http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jul/0025.html)
+
+ This has required changes to the RDFS entailment rules table. The
+ older conditions are now explained in informative sections as
+ 'extensional' conditions, and corresponding entailment rules
+ discussed.
+
+ 3. Plain literals, and literals typed with xsd:string, both denote
+ character strings. (WG decision recorded @@ 7/25/2003 Too recently to
+ give a link) The semantics now states explicitly that these are the
+ coextensive in XSD interpretations and describes a corresponding
+ inference rule.
+
+ 4. RDF lists are no longer required to explicitly give rdf:type
+ rdf:List triples for all sublists. (WG decision recorded
+ http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003May/0199.html)
+ The wording of the text and examples in section 3.2.3 have been
+ modified to suit.
+ _________________________________________________________________
RDF/XML Metadata
Attachments
- text/html attachment: semantics-2003-07-29.html
Received on Tuesday, 29 July 2003 06:09:18 UTC