--- a/drafts/rdf11-mt/Overview.html Wed Jul 03 12:29:00 2013 -0400
+++ b/drafts/rdf11-mt/Overview.html Wed Jul 03 12:29:20 2013 -0400
@@ -1,462 +1,336 @@
+
<!DOCTYPE html>
-<html lang="en" dir="ltr">
-<head>
- <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+<html>
+ <head>
+ <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<title>RDF 1.1 Semantics</title>
-
+ <script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove'></script>
+<script src='https://dvcs.w3.org/hg/rdf/raw-file/default/ReSpec.js/bibref/biblio.js' class='remove'></script>
+ <script class='remove'>
+ var respecConfig = {
+//THis line is chacking on mercurial push. Ignore it. 20130530.1
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "ED",
-
+localBiblio:{
+"HORST04":"Herman J. ter Horst. <cite>Extending the RDFS Entailment Lemma</cite>, in S.A. McIlraith et al. (Eds.), The Semantic Web - ISWC2004, Proceedings of the Third International Semantic Web Conference, Hiroshima, Japan, November 2004, Springer, LNCS 3298, pp. 77-91.",
+
+"HORST05":"Herman J. ter Horst. <cite>Completeness, Decidability and Complexity of Entailment for RDF Schema and a Semantic Extension Involving the OWL Vocabulary</cite>, Journal of Web Semantics 3 (2005) 79-115.",
+
+"RDF11-CONCEPTS": "Richard Cyganiak, David Wood. <cite><a href=\"http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/\">RDF 1.1 Concepts and Abstract Syntax.</a></cite> 15 January 2013. W3C Working Draft (work in progress). URL: <a href=\"http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/\">http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/</a>. The latest edition is available at <a href=\"http://www.w3.org/TR/rdf11-concepts/\">http://www.w3.org/TR/rdf11-concepts/</a>",
+
+"RDF-PLAIN-LITERAL":"Jie Bao, Sandro Hawke, Boris Motik, Peter F. Patel-Schneider, Alex Polleres. <cite><a href=\"http://www.w3.org/TR/rdf-plain-literal/\">rdf:PlainLiteral: A Datatype for RDF Plain Literals (Second Edition)</a></cite> 11 December 2012. W3C Recommendation. URL: <a href=\"http://www.w3.org/TR/rdf-plain-literal/\">http://www.w3.org/TR/rdf-plain-literal/</a>",
+
+"TURTLE-TR":"David Beckett, Tim Berners-Lee, Eric Prud'hommeaux, Gavin Carothers. <cite><a href=\"http://www.w3.org/TR/turtle/\">Turtle; Terse RDF Triple Language</a></cite> 19 February 2013. W3C Candidate Recommendation. URL: <a href=\"http://www.w3.org/TR/turtle/\">http://www.w3.org/TR/turtle/</a>" ,
+
+"ISO24707":"<cite>Information technology — Common Logic (CL): a framework for a family of logic-based languages</cite> 1 October 2007. International Standard ISO/IEC 24707:2007(E). URL: <a href=\"http://standards.iso.org/ittf/PubliclyAvailableStandards/c039175_ISO_IEC_24707_2007%28E%29.zip\"> http://standards.iso.org/ittf/PubliclyAvailableStandards/c039175_ISO_IEC_24707_2007%28E%29.zip</a>" },
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "rdf11-mt",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ // subtitle : "an excellent document",
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2013-04-09",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ copyrightStart: "2004",
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ previousPublishDate: "2013-04-09",
+ previousMaturity: "WD",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+ prevRecShortname: "rdf-mt/",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Patrick J. Hayes", url: "http://www.ihmc.us/groups/phayes/",
+ company: "Florida IHMC", companyURL: "http://www.ihmc.us/index.php" },
+ { name: "Peter F. Patel-Schneider",
+ company: "Nuance Communications", companyURL: "http://www.nuance.com/" },
+
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ //authors: [
+ // { name: "Your Name", url: "http://example.org/",
+ // company: "Your Company", companyURL: "http://example.com/" },
+ //],
+
+ // name of the WG
+ wg: "RDF Working Group",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2011/rdf-wg/",
+
+ // name (without the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-rdf-comments",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "http://www.w3.org/2004/01/pp-impl/46168/status",
+ };
+ </script>
<style type="text/css">
-.semantictable {background-color: #FFFFAA}
-.ruletable {background-color: #DDDDFF}
-.othertable {background-color: #FDFDFD}
+.semantictable {background-color: #FFFFAA; padding:0.5em;}
+.ruletable {background-color: #DDDDFF; padding:0.5em;}
+.othertable {background-color: #FDFDFD; padding:0.5em;}
.tabletitle {font-size: small; font-weight: bolder;}
-.technote {font-size:small; background: #ccccff;}
-.changenote {font-size: small; background: #ffccff;}
-</style>
- <style>/*****************************************************************
- * ReSpec 3 CSS
- * Robin Berjon - http://berjon.com/
- *****************************************************************/
-/* --- INLINES --- */
-em.rfc2119 {
- text-transform: lowercase;
- font-variant: small-caps;
- font-style: normal;
- color: #900;
+.technote {
+ font-size:small;
+ margin: 2em 0em 0em;
+ padding: 1em;
+ border: 2px solid #cff6d9;
+ background: #e2fff0;
}
-h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
-h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
- border: none;
-}
-
-dfn {
+.technote::before {
+ content: "Technical Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
font-weight: bold;
-}
-
-a.internalDFN {
- color: inherit;
- border-bottom: 1px solid #99c;
- text-decoration: none;
-}
-
-a.externalDFN {
- color: inherit;
- border-bottom: 1px dotted #ccc;
- text-decoration: none;
-}
-
-a.bibref {
- text-decoration: none;
-}
-
-cite .bibref {
- font-style: normal;
-}
-
-code {
- color: #ff4500;
+ border: 1px solid #cff6d9;
+ background: #eff;
+ padding: 3px 1em;
}
-/* --- --- */
-ol.algorithm { counter-reset:numsection; list-style-type: none; }
-ol.algorithm li { margin: 0.5em 0; }
-ol.algorithm li:before { font-weight: bold; counter-increment: numsection; content: counters(numsection, ".") ") "; }
-
-/* --- TOC --- */
-.toc a, .tof a {
- text-decoration: none;
-}
-
-a .secno, a .figno {
- color: #000;
-}
-
-ul.tof, ol.tof {
- list-style: none outside none;
-}
-
-.caption {
- margin-top: 0.5em;
- font-style: italic;
-}
-
-/* --- TABLE --- */
-table.simple {
- border-spacing: 0;
- border-collapse: collapse;
- border-bottom: 3px solid #005a9c;
-}
-
-.simple th {
- background: #005a9c;
- color: #fff;
- padding: 3px 5px;
- text-align: left;
-}
-
-.simple th[scope="row"] {
- background: inherit;
- color: inherit;
- border-top: 1px solid #ddd;
+.changenote {
+ font-size:small;
+ margin: 1em 0em 0em;
+ padding: 1em;
+ border: 2px solid #cff6d9;
+ background: #ffddfe;
}
-.simple td {
- padding: 3px 10px;
- border-top: 1px solid #ddd;
-}
-
-.simple tr:nth-child(even) {
- background: #f0f6ff;
-}
-
-/* --- DL --- */
-.section dd > p:first-child {
- margin-top: 0;
-}
-
-.section dd > p:last-child {
- margin-bottom: 0;
-}
-
-.section dd {
- margin-bottom: 1em;
+.changenote::before {
+ content: "Change Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #cff6d9;
+ background: #ffddef;
+ padding: 3px 1em;
}
-.section dl.attrs dd, .section dl.eldef dd {
- margin-bottom: 0;
-}
-</style><style>/* --- ISSUES/NOTES --- */
-div.issue-title, div.note-title {
- padding-right: 1em;
- min-width: 7.5em;
- color: #b9ab2d;
-}
-div.issue-title { color: #e05252; }
-div.note-title { color: #52e052; }
-div.issue-title span, div.note-title span {
- text-transform: uppercase;
-}
-div.note, div.issue {
- margin-top: 1em;
- margin-bottom: 1em;
-}
-.note > p:first-child, .issue > p:first-child { margin-top: 0 }
-.issue, .note {
- padding: .5em;
- border-left-width: .5em;
- border-left-style: solid;
-}
-div.issue, div.note {
+
+.fact {
padding: 0.5em;
margin: 1em 0;
position: relative;
clear: both;
+ background-color: #ffeecc;
+ border: 1px solid black
}
-span.note, span.issue { padding: .1em .5em .15em; }
+</style>
+ </head>
+ <body>
+ <section id='abstract'>
+ <p> This document describes a precise semantics for the Resource Description
+ Framework 1.1 [[RDF11-CONCEPTS]] and RDF Schema [[RDF-SCHEMA]]. It defines a number of distinct entailment regimes and corresponding patterns of entailment. It is part of a suite of documents which comprise the full specification of RDF 1.1.</p>
+ </section>
-.issue {
- border-color: #e05252;
- background: #fbe9e9;
-}
-.note {
- border-color: #52e052;
- background: #e9fbe9;
-}
+<section id='sotd'>
+<p>This is a revision of the 2004 Semantics specification for RDF
+ [[RDF-MT]] and supersedes that document.</p>
+</section>
+
+ <section class='introductory'><h2 id="notes">Notes</h2>
+<p class='changenote'>Notes in this style indicate changes from the 2004 RDF 1.0 semantics.</p>
+<p class='technote'>Notes in this style are technical asides on obscure or recondite matters.</p></section>
+ <section>
+ <h2 id="introduction">Introduction</h2>
+ <p>
+ This document defines a model-theoretic semantics for RDF graphs and the RDF and RDFS vocabularies, providing an exact formal specification of when truth is preserved by transformations of RDF or operations which derive RDF content from other RDF. </p>
+
+ </section>
+<section id="conformance"><p>This specification, <em>RDF 1.1 Semantics</em>, is normative for RDF semantics and the validity of RDF inference processes. It is not normative for many aspects of RDF meaning which are not described or specified by this semantics, including social issues of how IRIs are assigned meanings in use and how the referents of IRIs are related to Web content expressed in other media such as natural language texts. </p></section>
+
+ <section>
+ <h2 id="extensions">Semantic Extensions and Entailment Regimes</h2>
+ <p>RDF is intended for use as a base notation for a variety of extended notations such as OWL [[OWL2-OVERVIEW]] and RIF [[RIF-OVERVIEW]], whose expressions can be encoded as RDF graphs which use a particular vocabulary with a specially defined meaning. Also, particular IRI vocabularies may be given meanings by other specifications or conventions. When such extra meanings are assumed, a given RDF graph may support more extensive entailments than are sanctioned by the basic RDF semantics. In general, the more assumptions that are made about the meanings of IRIs in an RDF graph, the more entailments follow from those assumptions. </p>
+
+<p>A particular such set of semantic assumptions is called a <dfn>semantic extension</dfn>. Each <a>semantic extension</a> defines an <dfn>entailment regime</dfn> of entailments which are valid under that extension. RDFS, described later in this document, is one such <a>semantic extension</a>. We will refer to an entailment regime by names such as <em> RDFS entailment</em>, <em>D-entailment</em>, etc. </p>
+
+<p><a>Semantic extension</a>s MAY impose special syntactic conditions or restrictions upon RDF graphs, such as requiring certain triples to be present, or prohibiting particular combinations of IRIs in triples, and MAY consider RDF graphs which do not conform to these conditions to be errors. For example, RDF statements of the form <br/><br/> <code>ex:a rdfs:subClassOf "Thing"^^xsd:string .</code><br/><br/> are prohibited in the OWL <a>semantic extension</a> based on description logics [[!OWL2-SYNTAX]]. In such cases, basic RDF operations such as taking a subset of triples, or combining RDF graphs, may cause syntax errors in parsers which recognize the extension conditions. None of the <a>semantic extension</a>s normatively defined in this document impose such syntactic restrictions on RDF graphs.</p>
+
+<p>All entailment regimes MUST be <a>monotonic</a> extensions of the simple entailment regime described in the document, in the sense that if A <a>simply entails</a> B then A also entails B under any extended notion of entailment, provided that any syntactic conditions of the extension are also satisfied. Put another way, a <a>semantic extension</a> cannot "cancel" an entailment made by a weaker entailment regime, although it can treat the result as a syntax error.</p>
+ </section>
+
+ <section>
+ <h2 id="notation">Notation and Terminology</h2>
-</style><link href="http://www.w3.org/StyleSheets/TR/W3C-WD"
-rel="stylesheet"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
- <body><div class="head">
- <p>
-
- <a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a>
-
- </p>
- <h1 class="title" id="title">RDF 1.1 Semantics</h1>
-
- <h2 id="w3c-first-public-working-draft-09-april-2013"><abbr title="World Wide Web Consortium">W3C</abbr> First Public Working Draft 09 April 2013</h2>
- <dl>
-
- <dt>This version:</dt>
- <dd><a href="http://www.w3.org/TR/2013/WD-rdf11-mt-20130409/">http://www.w3.org/TR/2013/WD-rdf11-mt-20130409/</a></dd>
- <dt>Latest published version:</dt>
- <dd><a href="http://www.w3.org/TR/rdf11-mt/">http://www.w3.org/TR/rdf11-mt/</a></dd>
-
-
- <dt>Latest editor's draft:</dt>
- <dd><a href="https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html">https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html</a></dd>
-
-
-
-
-
-
- <dt>Latest recommendation:</dt>
- <dd><a href="http://www.w3.org/TR/rdf-mt/">http://www.w3.org/TR/rdf-mt/</a></dd>
-
- <dt>Editors:</dt>
- <dd><a href="http://www.ihmc.us/groups/phayes/">Patrick J. Hayes</a>, <a href="http://www.ihmc.us/index.php">Florida IHMC</a></dd>
-<dd><span>Peter F. Patel-Schneider</span>, <a href="http://www.nuance.com/">Nuance Communications</a></dd>
+ <p>This document uses the following terminology for describing RDF graph syntax, all as defined in the companion RDF Concepts specification [[!RDF11-CONCEPTS]]: <em><a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#dfn-iri">IRI</a></em>, <em><a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#section-triples">RDF triple</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#section-rdf-graph">RDF graph</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#section-triples">subject</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#section-triples" href="http://www.w3.org/TR/rdf11-concepts/#section-triples">predicate</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#section-triples">object</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source">RDF source</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#dfn-node">node</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#dfn-blank-node">blank node</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#dfn-literal">literal</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#graph-isomorphism">isomorphic</a>, and <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#section-dataset">RDF datasets</a>.</em> All the definitions in this document apply unchanged to <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#section-generalized-rdf">generalized RDF triples, graphs, and datasets</a>. </p>
+
+
+<p>The words <dfn>denotes</dfn> and <dfn>refers to</dfn> are used interchangeably as synonyms for the relationship between an IRI or literal and what it refers to in a given interpretation, itself called the <dfn>referent</dfn> or <dfn>denotation</dfn>. IRI meanings may also be determined by other constraints external to the RDF semantics; when we wish to refer to such an externally defined naming relationship, we will use the word <dfn>identify</dfn> and its cognates. For example, the fact that the IRI <code>http://www.w3.org/2001/XMLSchema#decimal</code> is widely used as the name of a datatype described in the XML Schema document [[XMLSCHEMA11-2]] might be described by saying that the IRI <em>identifies</em> that datatype. If an IRI identifies something it may or may not refer to it in a given interpretation, depending on how the semantics is specified. For example, an IRI used as a graph name <a>identify</a>ing a named graph in an <a href="http://www.w3.org/TR/rdf11-concepts/#section-dataset" class="external">RDF dataset</a> may refer to something different from the graph it identifies. </p>
+
+<p>Throughout this document, the equality sign = indicates strict identity. The statement "A = B" means that there is one entity to which both expressions "A" and "B" refer. Angle brackets < x, y > are used to indicate an ordered pair
+ of x and y.</p>
+
+<p>Throughout this document, RDF graphs and other fragments of RDF abstract syntax are written using the notational conventions of the Turtle syntax [[!TURTLE-TR]]. The namespace prefixes <code>rdf:</code> <code>rdfs:</code> and <code>xsd:</code> are used as in [[!RDF11-CONCEPTS]], <a href="http://www.w3.org/TR/rdf11-concepts/#vocabularies">section 1.4</a>. When the exact IRI does not matter, the prefix <code>ex:</code> is used. When stating general rules or conditions we use three-character variables such as aaa, xxx, sss to indicate arbitrary IRIs, literals, or other components of RDF syntax. Some cases are illustrated by node-arc diagrams showing the graph structure directly.</p>
+
+<p>A <dfn>name</dfn> is any IRI or literal. A typed literal contains
+ two <a>name</a>s: itself and its internal type
+ IRI. A <dfn>vocabulary</dfn> is a set of <a>name</a>s.
+</p>
+
+<p>The <dfn>empty graph</dfn> is the empty set of triples. </p>
+<p>A <dfn>subgraph</dfn> of an RDF graph is a subset
+ of the triples in the graph. A triple is identified with the singleton set
+ containing it, so that each triple in a graph is considered to be a subgraph.
+ A <dfn>proper subgraph</dfn> is a proper subset of the triples in the graph. </p>
- </dl>
-
-
-
-
-
- <p class="copyright">
- <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
- 2004-2013
-
- <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
- (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
- <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
- <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), All Rights Reserved.
- <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
- <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
- <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.
- </p>
-
-
- <hr>
-</div>
- <section class="introductory" id="abstract"><h2>Abstract</h2>
- <p> This document describes a precise semantics for the Resource Description
- Framework 1.1 [<cite><a href="#bib-RDF-PRIMER" class="bibref">RDF-PRIMER</a></cite>] and RDF Schema [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>]. It defines a number of distinct entailment regimes and corresponding systems of inference rules. It is part of a suite of documents which comprise the full specification of RDF 1.1.</p>
-<p>This is a revision of the 2004 RDF Semantics specification for RDF
- [<cite><a href="#bib-RDF-MT" class="bibref">RDF-MT</a></cite>] and supersedes that document. </p> </section><section id="sotd" class="introductory"><h2>Status of This Document</h2>
-
-
-
- <p>
- <em>This section describes the status of this document at the time of its publication. Other
- documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision
- of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports
- index</a> at http://www.w3.org/TR/.</em>
- </p>
-
-<p>This is a revision of the 2004 Semantics specification for RDF
- [<cite><a href="#bib-RDF-MT" class="bibref">RDF-MT</a></cite>] and supersedes that document.</p>
-
- <p>
- This document was published by the <a href="http://www.w3.org/2011/rdf-wg/">RDF Working Group</a> as a First Public Working Draft.
-
- This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation.
-
-
- If you wish to make comments regarding this document, please send them to
- <a href="mailto:public-rdf-comments@w3.org">public-rdf-comments@w3.org</a>
- (<a href="mailto:public-rdf-comments-request@w3.org?subject=subscribe">subscribe</a>,
- <a href="http://lists.w3.org/Archives/Public/public-rdf-comments/">archives</a>).
-
-
-
-
- All comments are welcome.
-
-
- </p><p>
- Publication as a First Public Working Draft does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> Membership.
- This is a draft document and may be updated, replaced or obsoleted by other documents at
- any time. It is inappropriate to cite this document as other than work in progress.
- </p>
-
-
- <p>
-
- This document was produced by a group operating under the
- <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
-
-
-
-
- <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/46168/status" rel="disclosure">public list of any patent disclosures</a>
-
- made in connection with the deliverables of the group; that page also includes instructions for
- disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains
- <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the
- information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
- 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
-
-
- </p>
-
-
-
-
-</section><section id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a class="tocxref" href="#introduction-1"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a class="tocxref" href="#semantic-extensions-and-entailment-regimes"><span class="secno">2. </span>Semantic extensions and entailment regimes</a></li><li class="tocline"><a class="tocxref" href="#notation-and-terminology"><span class="secno">3. </span>Notation and terminology</a></li><li class="tocline"><a class="tocxref" href="#simple-interpretations"><span class="secno">4. </span> Simple Interpretations</a></li><li class="tocline"><a class="tocxref" href="#simpleentailment"><span class="secno">5. </span>Simple Entailment</a></li><li class="tocline"><a class="tocxref" href="#skolemization-1"><span class="secno">6. </span>Skolemization</a></li><li class="tocline"><a class="tocxref" href="#literals-and-datatypes"><span class="secno">7. </span>Literals and datatypes</a></li><li class="tocline"><a class="tocxref" href="#D_interpretations"><span class="secno">8. </span>D-interpretations and datatype entailment</a></li><li class="tocline"><a class="tocxref" href="#rdf-d-interpretations-and-rdf-entailment"><span class="secno">9. </span>RDF-D Interpretations and RDF entailment</a></li><li class="tocline"><a class="tocxref" href="#rdfs-interpretations-and-rdfs-entailment"><span class="secno">10. </span>RDFS Interpretations and RDFS entailment</a></li><li class="tocline"><a class="tocxref" href="#monotonicity-of-semantic-extensions"><span class="secno">11. </span>Monotonicity of semantic extensions </a></li><li class="tocline"><a class="tocxref" href="#extensional-rdfs-semantic-conditions-informative"><span class="secno">12. </span>Extensional RDFS Semantic Conditions (Informative)</a></li><li class="tocline"><a class="tocxref" href="#entailment-rules-informative"><span class="secno">13. </span>Entailment Rules (Informative)</a></li><li class="tocline"><a class="tocxref" href="#MTintro"><span class="secno">A. </span>Introduction to model theory (Informative)</a></li><li class="tocline"><a class="tocxref" href="#proofs-of-lemmas-informative"><span class="secno">B. </span>Proofs of Lemmas (Informative)</a></li><li class="tocline"><a class="tocxref" href="#whatnot"><span class="secno">C. </span>What the semantics does not do (Informative)</a></li><li class="tocline"><a class="tocxref" href="#glossary"><span class="secno">D. </span>Glossary of Terms (Informative)</a></li><li class="tocline"><a class="tocxref" href="#acknowledgements"><span class="secno">E. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">F. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#normative-references"><span class="secno">F.1 </span>Normative references</a></li><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">F.2 </span>Informative references</a></li></ul></li></ul></section>
-
-
-
- <section class="introductory"><h2 id="notes">Notes</h2>
-<p class="changenote">Notes in this style indicate changes from the 2004 RDF semantics.</p>
-<p class="technote">Notes in this style are technical asides on obscure or recondite matters.</p></section>
- <section id="introduction-1">
- <!--OddPage--><h2 id="introduction"><span class="secno">1. </span>Introduction</h2>
- <p>
- This document defines a model-theoretic semantics for RDF graphs and the RDF and RDFS vocabularies, providing an exact formal specification of when truth is preserved by transformations of RDF, or operations which derive RDF content from other RDF. Readers who are unfamiliar with model theory can find a brief introduction to the basic ideas and terminology in <a>Appendix A</a>, and may find the informative section 13 useful. </p>
-<p>This specification is normative for RDF <a>formal</a> semantics. However, there are many aspects of RDF meaning which are not covered by this semantics, including social issues of how IRIs are assigned meanings in use, and how the referents of IRIs are related to Web content expressed in other media such as natural language texts. Accounts of such extended notions of meaning will go beyond this specification, but <em title="MUST NOT" class="rfc2119">MUST NOT</em> violate the conditions described here. </p>
- </section>
-
- <section id="semantic-extensions-and-entailment-regimes">
- <!--OddPage--><h2 id="extensions"><span class="secno">2. </span>Semantic extensions and entailment regimes</h2>
- <p>RDF is intended for use as a base notation for a variety of extended notations such as OWL [<cite><a href="#bib-OWL2-OVERVIEW" class="bibref">OWL2-OVERVIEW</a></cite>] and RIF [<cite><a href="#bib-RIF-OVERVIEW" class="bibref">RIF-OVERVIEW</a></cite>], whose expressions can be encoded as RDF graphs which use a particular vocabulary with a specially defined meaning. Also, particular IRI vocabularies may impose user-defined meanings upon the basic RDF meaning rules. When such extra meanings are assumed, a given RDF graph may support more extensive entailments than are sanctioned by the basic RDF semantics. In general, the more assumptions that are made about the meanings of IRIs in an RDF graph, the more valid entailments it has. </p>
-
-<p>A particular such set of semantic assumptions is called a <dfn id="dfn-semantic-extension">semantic extension</dfn>. Each semantic extension defines an <dfn id="dfn-entailment-regime">entailment regime</dfn> of entailments which are valid under that extension. RDFS, described later in this document, is one such semantic extension. We will refer to an entailment regime by names such as <em>rdfs-entailment</em>, <em>D-entailment</em>, etc.. </p>
-
-<p>Semantic extensions <em title="MAY" class="rfc2119">MAY</em> impose special syntactic conditions or restrictions upon RDF graphs, such as requiring certain triples to be present, or prohibiting particular combinations of IRIs in triples, and <em title="MAY" class="rfc2119">MAY</em> consider RDF graphs which do not conform to these conditions to be errors. For example, RDF statements of the form <br>
-<code>:a rdfs:subClassOf owl:Thing .</code><br>
-are prohibited in the OWL-DL [<cite><a href="#bib-OWL2-SYNTAX" class="bibref">OWL2-SYNTAX</a></cite>] semantic extension. In such cases, basic RDF operations such as taking a subset of triples, or merging RDF graphs, may cause syntax errors in parsers which recognize the extension conditions. None of the semantic extensions normatively defined in this document impose syntactic restrictions on RDF graphs.</p>
-
-<p>All entailment regimes <em title="MUST" class="rfc2119">MUST</em> be <a>monotonic</a> extensions of the simple entailment regime described in the next section, in the sense that if A simply entails B then A also entails B under any extended notion of entailment, provided of course that any syntactic conditions of the extension are also satisfied. Put another way, a semantic extension cannot "cancel" an entailment made by a weaker entailment regime, although it can treat the result as a syntax error.</p>
- </section>
-
- <section id="notation-and-terminology">
- <!--OddPage--><h2 id="notation"><span class="secno">3. </span>Notation and terminology</h2>
-
-<div class="issue"><div class="issue-title"><span>Issue 1</span></div><p class="">This section needs cleaning up. Some of the 2004 definitions may no longer be needed. The notions of instance and equivalence may (?) need to be stated more carefully taking bnode scopes into account. Instance mappings should be defined on a whole scope rather than a graph (?). The definitions involving bnode scopes and complete graphs are new. <br><br> Maybe some of the material should be in Concepts. </p></div>
-
- <p>This document uses the terminology //list terms// defined in //Concepts// for describing RDF graph syntax.</p>
-
-<p>Throughout this document, precise semantic conditions will be set out in tables
- which state semantic conditions, tables containing true assertions and <a class="internalDFN" href="#dfn-valid">valid</a> inference rules, and tables listing syntax. These tables, which
- are distinguished by background color, amount
- to a formal summary of the entire semantics.
-</p>
-<p>Throughout this document, the equality sign = indicates
- identity. The statement "A = B" means that there is one entity which both expressions "A" and "B" refer to. Angle brackets < x, y > are used to indicate an ordered pair
- of x and y. RDF graph syntax is indicated using the notational conventions of
- the N-Triples syntax described
- in the Turtle Working Draft [<cite><a href="#bib-TURTLE-TR" class="bibref">TURTLE-TR</a></cite>]
- literal strings are enclosed within double quote marks and attached to a type IRI using a double-caret <code>^^</code>, language tags indicated
- by the use of the <code>@</code> sign, and triples terminate with a 'code dot'
- <code>.</code> . </p>
-<p>In stating general rules or conditions we will use the following conventions:<br>
-sss or ttt indicates a Unicode character string; <br>
-aaa or bbb indicates an IRI<br>
-lll or mmm indicates a literal<br>
-_:xxx or _:yyy indicates a blank node. <br></p>
-
-<p>A <dfn id="dfn-name">name</dfn> is any IRI or literal. A <dfn id="dfn-vocabulary">vocabulary</dfn> is a set of names.
-</p>
-
-
-<p>An <a class="externalDFN">RDF
- graph</a>, or simply a <dfn id="dfn-graph">graph</dfn>, is a set of RDF triples.</p>
-<p>A <dfn id="dfn-subgraph">subgraph</dfn> of an RDF graph is a subset
- of the triples in the graph. A triple is identified with the singleton set
- containing it, so that each triple in a graph is considered to be a subgraph.
- A <dfn id="dfn-proper-subgraph">proper subgraph</dfn> is a proper subset of the triples in the graph. </p>
-
-
-<p>A <dfn id="dfn-ground">ground</dfn> RDF graph is one with no blank
+<p>A <dfn>ground</dfn> RDF graph is one which contains no blank
nodes.</p>
-
-<p>A <dfn id="dfn-name-1">name</dfn> is an IRI or a literal.
- Note that a typed literal comprises
- two <a class="internalDFN" href="#dfn-name-1">name</a>s: itself and its internal type
- IRI. </p>
-<p>A <dfn id="dfn-vocabulary-1">vocabulary</dfn> is a set of <a class="internalDFN" href="#dfn-name-1">name</a>s. The vocabulary of a graph is
- the set of names which occur as the subject, predicate or object of any triple
- in the graph. IRIs which occur only inside typed literals
- are not required to be in the vocabulary of the graph.</p>
<p>Suppose that M is a functional mapping from a set of blank
nodes to some set of literals, blank nodes and IRIs. Any graph obtained
from a graph G by replacing some or all of the blank nodes N in G by M(N) is
- an <dfn id="definst">instance</dfn> of G. Any graph is an instance of itself,
+ an <dfn>instance</dfn> of G. Any graph is an instance of itself,
an instance of an instance of G is an instance of G,
and if H is an instance of G then every triple in H is an instance of at least one triple
in G.</p>
-<p>An <dfn id="dfn-instance-with-respect-to">instance with respect to</dfn> a vocabulary
- V is an <a class="internalDFN" href="#definst">instance</a> in which all the
- <a class="internalDFN" href="#dfn-name-1">name</a>s in the instance that were substituted
- for blank nodes in the original are <a class="internalDFN" href="#dfn-name-1">name</a>s
+<p>An <dfn>instance with respect to</dfn> a vocabulary
+ V is an <a>instance</a> in which all the
+ <a>name</a>s in the instance that were substituted
+ for blank nodes in the original are <a>name</a>s
from V.</p>
-<p>A <dfn id="dfn-proper-instance">proper instance</dfn> of a graph
- is an <a class="internalDFN" href="#definst">instance</a> in which a blank node has been replaced by a name, or two blank
+<p>A <dfn>proper instance</dfn> of a graph
+ is an <a>instance</a> in which a blank node has been replaced by a <a>name</a>, or two blank
nodes in the graph have been mapped into the same node in the instance. </p>
-<p>Any <a class="internalDFN" href="#definst">instance</a> of a graph in which a blank node is mapped to a new blank node
- not in the original graph is an instance of the original and also has it as
- an instance, and this process can be iterated so that any 1:1 mapping between
- blank nodes defines an instance of a graph which has the original graph as an
- instance. Two such graphs, each an instance of the other but neither a proper
- instance, which differ only in the identity of their blank nodes, are considered
- to be <dfn id="dfn-equivalent">equivalent</dfn>. Equivalent graphs are mutual instances with an invertible instance
- mapping. As blank nodes have no particular identity beyond their location in a graph, we will often treat such equivalent graphs as identical.</p>
+<p>Two graphs are <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#graph-isomorphism">isomorphic</a> when each maps into the other by a 1:1 mapping on blank nodes. Isomorphic graphs are mutual instances with an invertible instance
+ mapping. As blank nodes have no particular identity beyond their location in a graph, we will often treat isomorphic graphs as identical.</p>
-<p>Any set of graphs can be treated as a single graph simply by taking the union of the sets of triples. If two or more of the graphs share a blank node it will retain its identity when the union graph is formed. Graphs can share blank nodes only if they are derived from graphs described by documents or surface structures which share a single scope for blank node identifiers.</p>
-<div class="issue"><div class="issue-title"><span>Issue 2</span></div><p class="">The Concepts document does not yet define blank node identifier scopes.</p></div>
+<p >An RDF graph is <dfn>lean</dfn> if it has no instance which is
+ a proper subgraph of itself. Non-lean graphs have internal redundancy
+ and express the same content as their lean subgraphs. For example, the graph</p>
+<p ><code>ex:a ex:p _:x .<br/>
+ _:y ex:p _:x .</code></p>
+<p >is not lean, but</p>
+<p ><code>ex:a ex:p _:x .<br/>
+ _:x ex:p _:x .</code></p>
+<p >is lean. <a>Ground</a> graphs are lean. </p>
-<p>We will refer to this process of forming the union of graphs as <dfn id="dfn-merging">merging</dfn>, and to the union graph as the <dfn id="dfn-merge">merge</dfn> of the original graphs. A merge may be represented by a new document or datastructure, or may be treated as a conceptual entity when processing RDF.</p>
+<section> <h3>Shared blank nodes, unions and merges</h3>
+<p>
+Graphs share blank nodes only if they are derived from graphs
+described by documents or other structures (such as an RDF dataset) that explicitly provide for the sharing of blank nodes between different RDF graphs. Simply downloading a
+web document does not mean that the blank nodes in a resulting RDF
+graph are the same as the blank nodes coming from other downloads of
+the same document or from the same <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source">RDF source</a>.</p>
-<ul><li><p class="changenote"> The 2004 RDF 1.0 specification defined a process of 'standardizing apart' blank nodes to distinguish graph unions from graph merges. Standardizing apart blank node identifiers may still be needed at a concrete syntax level, but is no longer part of the underlying conceptual model of RDF. The earlier terminology is retained to avoid confusion, but now 'merging' simply means 'taking the union' at the graph syntax level. </p>
-</li></ul>
+<p> RDF applications which manipulate concrete syntaxes for RDF which use blank node identifiers should take care to keep track of the identity of the blank nodes they identify. Blank node identifiers often have a local scope, so when RDF from different sources is combined, identifiers may have to be changed in order to avoid accidental conflation of distinct blank nodes.</p>
+<p> For example, two documents may both use the blank node identifier "<code>_:x</code>" to identify a blank node, but unless these documents are in a shared identifier scope or are derived from a common source, the occurrences of "<code>_:x</code>" in one document will identify a different blank node than the one in the graph described by the other document. When graphs are formed by combining RDF from multiple sources, it may be necessary to <dfn>standardize</dfn> apart the blank node identifiers by replacing them by others which do not occur in the other document(s). For example, the two graphs represented by the following texts: </p>
+<p><code>ex:a ex:p _:x . </code><br/><br/>
+<img src="RDF11SemanticsDiagrams/example1.jpg" /></p>
+<p><code>ex:b ex:q _:x . </code><br/><br/>
+<img src="RDF11SemanticsDiagrams/example2.jpg"></p>
+<p>contain four nodes. Their union would therefore also contain four nodes:</p>
+
+<p><img src="RDF11SemanticsDiagrams/example4.jpg"></p>
+
+<p> However, the document formed by simply concatenating these textual surface representations: </p>
+
+<p><code>ex:a ex:p _:x .<br/>
+ex:b ex:q _:x .</code><br/></p>
+
+<p>describes a graph containing three nodes:</p>
+<p><img src="RDF11SemanticsDiagrams/example3.jpg"></p>
+<p> since the two occurrences of the blank node identifier "<code>_:x</code>" occurring in a common identifier scope identify the same blank node. The four-node union of these two graphs is more properly described by a surface form such as:</p>
+<p><code>ex:a ex:p _:x1 .<br/>
+ex:b ex:q _:x2 .</code></p>
+
+<p>in which the blank node identifiers have been <a>standardize</a>d apart to avoid conflating the distinct blank nodes. (The particular blank node identifiers used have no significance, only that they are distinct.) </p>
+
+<p>It is possible for two or more graphs to share a blank node, for example if they are subgraphs of a single larger graph or derived from a common source. In this case, the union of a set of graphs preserves the identity of blank nodes shared between the graphs. In general, the union of a set of RDF graphs accurately represents the same semantic content as the graphs themselves, whether or not they share blank nodes. </p>
+<p>A related operation, called <dfn>merging</dfn>, takes the union after forcing any shared blank nodes, which occur in more than one graph, to be distinct in each graph. The resulting graph is called the <dfn>merge</dfn>. The merge of subgraphs of a graph may be larger than the original graph. For example, the result of merging the two singleton subgraphs of the three-node graph</p>
+
+<p><img src="RDF11SemanticsDiagrams/example3.jpg"></p>
+
+<p>is the four-node graph</p>
+
+<p><img src="RDF11SemanticsDiagrams/example4.jpg"></p>
+
+<p>The union is always an instance of the merge. If graphs have no blank nodes in common, then their merge and union are identical. </p>
-<p>An RDF graph is <dfn id="dfn-lean">lean</dfn> if it has no instance which is
- a proper subgraph of the graph. Non-lean graphs have internal redundancy
- and express the same content as their lean subgraphs. For example, the graph</p>
-<p><code><ex:a> <ex:p> _:x .<br>
- _:y <ex:p> _:x .</code></p>
-<p>is not lean, but</p>
-<p><code><ex:a> <ex:p> _:x .<br>
- _:x <ex:p> _:x .</code></p>
-<p>is lean. </p>
+</section>
-
-
-
+</section>
- </section>
+ <section>
+ <h2 id="simple"> Simple Interpretations</h2>
+
+<p>This section defines the basic notions of interpretation and truth for RDF graphs. All <a>semantic extension</a>s of any vocabulary or higher-level notation encoded in RDF MUST conform to these minimal truth conditions. Other <a>semantic extension</a>s may extend and add to these, but they MUST NOT modify or negate them. For example, because interpretations are mappings which apply to IRIs, a <a>semantic extension</a> cannot interpret different occurrences of a single IRI differently.</p>
- <section id="simple-interpretations">
- <!--OddPage--><h2 id="simple"><span class="secno">4. </span> Simple Interpretations</h2>
-
-<p>A <dfn id="dfn-simple-interpretation">simple interpretation</dfn> I is a structure consisting of:</p>
+<p>The entire semantics applies to <a>RDF graph</a>s, not to <a>RDF source</a>s. An <a>RDF source</a> has a semantic meaning only through the graph that is its value at a given time, or in a given state. Graphs cannot change their semantics with time.</p>
+
+
+<p>A <dfn>simple interpretation</dfn> I is a structure consisting of:</p>
<div class="tabletitle">Definition of a simple interpretation.</div>
<table border="1">
- <tbody><tr>
- <td class="semantictable"><p>1. A non-empty set IR of resources, called the domain or universe
- of I.</p>
- <p>2. <span>A set IP, called the set of properties of I.</span></p>
+ <tr>
+ <td class="semantictable">1. A non-empty set IR of resources, called the domain or universe
+ of I.
+ <p>2. <span >A set IP, called the set of properties of I.</span></p>
<p>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 .</p>
<p>4. A mapping IS from IRIs into (IR union IP)</p>
<p>5. A partial mapping IL from literals into IR </p>
</td>
</tr>
- </tbody></table>
+ </table>
-<ul><li><p class="changenote">The 2004 RDF 1.0 semantics defined interpretations relative to a vocabulary.<br><br>In the 2004 RDF 1.0 semantics, IL was a total, rather than partial, mapping.<br><br> The 2004 RDF 1.0 specification divided literals into 'plain' literals with no type and optional language tags, and typed literals. Usage has shown that it is important that every literal have a type. RDF 1.1 replaces plain literals without language tags by literals typed with the XML Schema <code>string</code> datatype, and introduces the special type <code>rdf:langString</code> for language-tagged strings. The full semantics for typed literals is given in the next section. </p>
+<p class="changenote">The 2004 RDF 1.0 semantics defined interpretations relative to a vocabulary.<br/><br/>In the 2004 RDF 1.0 semantics, IL was a total, rather than partial, mapping.<br/><br/> The 2004 RDF 1.0 specification divided literals into 'plain' literals with no type and optional language tags, and typed literals. Usage has shown that it is important that every literal have a type. RDF 1.1 replaces plain literals without language tags by literals typed with the XML Schema <code>string</code> datatype, and introduces the special type <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-language-tagged-string"><code>rdf:langString</code></a> for language-tagged strings. The full semantics for typed literals is given in the next section. </p>
-</li><li><p class="technote"> Interpretations are required to interpret all names, and are therefore infinite. This simplifies the exposition. However, RDF can be interpreted using finite structures, supporting decidable algorithms. Details are given in Appendix ///. </p>
-</li></ul>
+<p class="technote"> Interpretations are required to interpret all <a>name</a>s, and are therefore infinite. This simplifies the exposition. However, RDF can be interpreted using finite structures, supporting decidable algorithms. Details are given in Appendix B. </p>
+
<p>IEXT(x), called
- the <dfn id="dfn-extension">extension</dfn> of x, is a
+ the <dfn>extension</dfn> of x, is a
set of pairs which identify the arguments for which the property is true,
that is, a binary relational extension.
</p>
-<p>The distinction between IR and IL will become significant below when the semantics of datatypes are defined. IL is allowed to be partial because some literals may fail to have a referent. However, IL is total on language-tagged strings and literals of type <code>xsd:string</code>. </p>
+<p>The distinction between IR and IL will become significant below when the semantics of datatypes are defined. IL is allowed to be partial because some literals may fail to have a referent. </p>
-<ul><li><p class="technote">
-It is conventional to map a relation name to a relational extension directly. This however presumes that the vocabulary is segregated into relation names and individual names, and RDF makes no such assumption. Moreover, RDF allows an IRI to be used as a relation name applied to itself as an argument. Such self-application structures are used in RDFS, for example. The use of the IEXT mapping to distinguish the relation as an object from its relational extension accommodates both of these requirements. It also provides for a more intuitive notion of RDFS 'class' which can be distinguished from its set-theoretic extension.
+<p class="technote">
+It is conventional to map a relation name to a relational extension directly. This however presumes that the vocabulary is segregated into relation names and individual names, and RDF makes no such assumption. Moreover, RDF allows an IRI to be used as a relation name applied to itself as an argument. Such self-application structures are used in RDFS, for example. The use of the IEXT mapping to distinguish the relation as an object from its relational extension accommodates both of these requirements. It also provides for a notion of RDFS 'class' which can be distinguished from its set-theoretic extension. A similar technique is used in the ISO/IEC Common Logic standard [[ISO24707]].
</p>
-</li></ul>
- <p>The denotation of a ground RDF graph in I is then given by the following
- rules</p>
+
+ <p>The denotation of a ground RDF graph in an interpretation I is then given by the following
+ rules, where the interpretation is also treated as a function from expressions (names, triples and graphs) to elements of the universe and truth values:</p>
<div class="tabletitle">Semantic conditions for ground graphs.</div>
@@ -477,7 +351,7 @@
then I(E) = true if </p>
<p>I(p) is in IP and the pair <I(s),I(o)>
is in IEXT(I(p))</p>
- <p>otherwise I(E)= false.</p></td>
+ <p>otherwise I(E) = false.</p></td>
</tr>
<tr>
@@ -488,20 +362,22 @@
</table>
-<p> If IL(E) is undefined for some literal E, then E has no semantic value, so any triple containing it will be false, so any graph containing that triple will also be false.</p>
-<p> The final condition implies that the empty graph (empty set of triples) is always true.</p>
+<p> If IL(E) is undefined for some literal E then E has no semantic value, so any triple containing it will be false, so any graph containing that triple will also be false.</p>
+<p> The final condition implies that the empty graph (the empty set of triples) is always true.</p>
<p>The sets IP and IR may overlap, indeed IP can be a subset of IR. Because of the domain conditions on IEXT, the denotation of the subject and object of any true triple will be in IR; so any IRI which occurs in a graph both as a predicate and as a subject or object will denote something in the intersection of IP and IR.</p>
+<p><a>Semantic extension</a>s may impose further constraints upon interpretation mappings by requiring some IRIs to refer in particular ways. For example, D-interpretations, described below, require some IRIs, understood as <a>identify</a>ing and referring to datatypes, to have a fixed interpretation. </p>
- <h2 id="blank_nodes">Blank Nodes</h2>
+<section>
+ <h3 id="blank_nodes">Blank nodes</h3>
-<p>Blank nodes are treated as simply indicating the existence of a thing, without using an IRI to identify any particular thing. They play a similar role to existentially quantified variables in a conventional logical notation. This is not the same as assuming that the blank node indicates an 'unknown' IRI.
+<p>Blank nodes are treated as simply indicating the existence of a thing, without using an IRI to <a>identify</a> any particular thing. This is not the same as assuming that the blank node indicates an 'unknown' IRI.
</p>
-<p> Suppose I is an interpretation and A is a mapping from a set of blank nodes to the universe IR of I. Define the mapping [I+A] to be I on names, and A on blank nodes on the set: [I+A](x)=I(x) when x is a name and [I+A](x)=A(x) when x is a blank node; and extend this mapping to triples and RDF graphs using the rules given above for ground graphs. </p>
+<p> Suppose I is an interpretation and A is a mapping from a set of blank nodes to the universe IR of I. Define the mapping [I+A] to be I on <a>name</a>s, and A on blank nodes on the set: [I+A](x)=I(x) when x is a <a>name</a> and [I+A](x)=A(x) when x is a blank node; and extend this mapping to triples and RDF graphs using the rules given above for ground graphs. Then the semantic conditions for an RDF graph are:</p>
- <div class="tabletitle">Semantic condition for blank nodes.</div>
+ <div class="tabletitle">Semantic condition for blank nodes.</div>
<table border="1">
<tbody>
@@ -514,194 +390,208 @@
</tbody>
</table>
-<p>Mappings from blank nodes to referents are not part of the definition of an interpretation, since the truth condition refers only to <em>some</em> such mapping. Blank nodes themselves differ from other nodes in not being assigned a denotation by an interpretation, reflecting the intuition that they have no 'global' meaning outside the scope in which they occur.</p>
-
-<h2 id="intuitions">Intuitive summary</h2>
+<p>Mappings from blank nodes to referents are not part of the definition of an interpretation, since the truth condition refers only to <em>some</em> such mapping.
+Blank nodes themselves differ from other nodes in not being assigned
+a denotation by an interpretation, reflecting the intuition that
+they have no 'global' meaning. </p>
-<p>An RDF graph is true exactly when:</p>
-<p>1. the IRIs and literals in subject or object position in the graph all refer to things,</p><p>2. there is some way to interpret all the blank nodes in the scope as referring to things,</p><p>3. the IRIs in property position identify binary relationships,</p><p>4. and, under these interpretations, each triple S P O in the graph asserts that the thing referred to as S, and the thing referred to as O, do in fact stand in the relationship identified by P. </p>
+<section class="informative"><h3>Shared blank nodes (Informative)</h3>
-<p>All semantic extensions of any vocabulary or higher-level notation encoded in RDF <em title="MUST" class="rfc2119">MUST</em> conform to these minimal truth conditions. Other semantic extensions may extend and add to these, but they <em title="MUST NOT" class="rfc2119">MUST NOT</em> over-ride or negate them. </p>
+<p> The semantics for blank nodes are stated in terms of the truth of a graph. However, when two (or more) graphs share a blank node, their meaning is not fully captured by treating them in isolation. For example, consider the overlapping graphs</p>
+<p><img src="RDF11SemanticsDiagrams/example5.jpg"></p>
+<p> and an interpretation I over the universe {Alice, Bob, Monica, Ruth} with:<br/>
+I(<code>ex:Alice</code>)=Alice, I(<code>ex:Bob</code>)=Bob, IEXT(I(<code>ex:hasChild</code>))={<Alice,Monica>,<Bob,Ruth> }<br/></p>
+<p>Each of the inner graphs is true under this interpretation, but the two of them together is not, because the three-node graph says that Alice and Bob have a child together. In order to capture the full meaning of graphs sharing a blank node, it is necessary to consider the union graph containing all the triples which contain the blank node.</p>
+<p class="technote"> RDF graphs can be viewed as conjunctions of simple atomic sentences in first-order logic, where blank nodes are free variables which are understood to be existential. Taking the union of two graphs is then analogous to syntactic conjunction in this syntax. RDF syntax has no explicit variable-binding quantifiers, so the truth conditions for any RDF graph treat the free variables in that graph as existentially quantified in that graph. Taking the union of graphs which share a blank node changes the implied quantifier scopes.
+</p>
- </section>
+</section>
+</section>
+<section class="informative">
+<h3 id="intuitions" class="informative">Intuitive summary (Informative)</h3>
-<section id="simpleentailment"><!--OddPage--><h2><span class="secno">5. </span>Simple Entailment</h2>
-<div class="issue"><div class="issue-title"><span>Issue 3</span></div><p class="">Should the 'explanatory' material in here be moved to the tutorial appendix? </p></div>
-<p>Following standard terminology, we say that I <dfn id="dfn-satisfies">satisfies</dfn> E when I(E)=true, and a set
- S of RDF graphs <dfn id="dfn-simply-entails">simply entails</dfn> a graph E when every interpretation
- which satisfies every member of S also satisfies E. This means that it is always correct to infer E from S, even when one does not know what the names in the vocabulary actually mean. In later sections these notions will be adapted to other classes of interpretations, but throughout this section 'entailment' should be interpreted as meaning simple entailment.
+<p>An RDF graph is true exactly when:</p>
+<p>1. the IRIs and literals in subject or object position in the graph all refer to things,</p><p>2. there is some way to interpret all the blank nodes in the graph as referring to things,</p><p>3. the IRIs in property position refer to binary relationships,</p><p>4. and under these interpretations, each triple S P O in the graph asserts that the thing referred to as S, and the thing referred to as O, do in fact stand in the relationship referred to by P. </p>
+
+</section>
+
+<section id="simpleentailment"><h2>Simple Entailment</h2>
+
+<p>Following standard terminology, we say that I <dfn>satisfies</dfn> E when I(E)=true, that E is <dfn>satisfiable</dfn> when an interpretation exists which satisfies it, (otherwise <dfn>unsatisfiable</dfn>), and that a graph G <dfn>simply entails</dfn> a graph E when every interpretation which satisfies G also satisfies E. </p>
+<p>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.
</p>
+<p class="technote">We do not define a notion of entailment between sets of graphs. To determine whether a set of graphs entails a graph, the graphs in the set must first be combined into one graph, either by taking the union or the merge of the graphs. Unions preserve the common meaning of shared blank nodes, while merging effectively ignores any sharing of blank nodes. Merging the set of graphs produces the same definition of entailment by a set that was defined in the 2004 RDF 1.0 specification.</p>
+
<p><a id="defvalid">Any process which constructs a graph E from
- some other graph(s) S is said to be (simply) <dfn id="dfn-valid">valid</dfn> if S
- simply entails E in every case, otherwise <dfn id="dfn-invalid.">invalid.</dfn></a></p>
-
-<p>The fact that an inference is valid should not be understood as meaning that the inference must be made, or that any process is obliged or required to make the inference; and similarly, the logical invalidity of some RDF transformation or process does not mean that the process is incorrect or prohibited. Nothing in this specification requires or prohibits any particular operations to be applied to RDF graphs. Entailment and validity are concerned solely with establishing the conditions on operations which guarantee the preservation of truth. While logically invalid processes, which do not follow valid entailments, are not prohibited, users should be aware that they may be at risk of introducing falsehoods and errors into otherwise correct RDF data. Nevertheless, particular uses of logically invalid processes may be justified and appropriate for data processing under circumstances where truth can be ensured by other means. </p>
-
-<p>Entailment refers only to the truth of RDF graphs, not to their suitability for any other purpose. It is possible for an RDF graph to be fitted for a given purpose and yet validly entail another graph which is not appropriate for the same purpose. An example is the RDF test cases manifest [<cite><a href="#bib-RDF-TESTCASES" class="bibref">RDF-TESTCASES</a></cite>] which is provided as an RDF document for user convenience. This document lists examples of correct entailments by describing their antecedents and conclusions. Considered as an RDF graph, the manifest validly entails a subgraph which omits the antecedents, and would therefore be incorrect if used as a test case manifest. This is not a violation of the RDF semantic rules, but it shows that the property of <em> "being a correct RDF test case manifest"</em> is not preserved under RDF entailment, and therefore cannot be described as an RDF semantic extension. Such entailment-risky uses of RDF should be restricted to cases, as here, where it is obvious to all parties what the intended special restrictions on entailment are, in contrast with the more normal case of using RDF for the open publication of data on the Web.</p>
+ some other graph S is (simply) <dfn>valid</dfn> if S
+ simply entails E in every case, otherwise <dfn>invalid.</dfn></a></p>
-<h2 id="basic_properties">Some basic properties of simple entailment. </h2>
-<p>The properties described here apply only to simple entailment, not to extended notions
- of entailment introduced in later sections. Proofs
- are given in <a>Appendix B</a>.</p>
+<p>The fact that an inference is valid should not be understood as meaning that any RDF application is obliged or required to make the inference. Similarly, the logical invalidity of some RDF transformation or process does not mean that the process is incorrect or prohibited. Nothing in this specification requires or prohibits any particular operations on RDF graphs or sources. Entailment and validity are concerned solely with establishing the conditions on such operations which guarantee the preservation of truth. While logically invalid processes, which do not follow valid entailments, are not prohibited, users should be aware that they may be at risk of introducing falsehoods into true RDF data. Nevertheless, particular uses of logically invalid processes may be justified and appropriate for data processing under circumstances where truth can be ensured by other means. </p>
-<p>Simple entailment can be recognized by relatively simple syntactic comparisons. The two basic forms of simply valid inference in RDF are, in logical terms, the inference from <code>(P and Q)</code> to <code>P</code>, and the inference from <code>foo(baz)</code> to <code>(exists (x) foo(x) ) </code>. The first corresponds to taking a subgraph of a graph, the second to replacing an IRI or literal with a blank node.</p>
+<p>Entailment refers only to the truth of RDF graphs, not to their suitability for any other purpose. It is possible for an RDF graph to be fitted for a given purpose and yet validly entail another graph which is not appropriate for the same purpose. An example is the RDF test cases manifest [[RDF-TESTCASES]] which is provided as an RDF document for user convenience. This document lists examples of correct entailments by describing their antecedents and conclusions. Considered as an RDF graph, the manifest simply entails a subgraph which omits the antecedents, and would therefore be incorrect if used as a test case manifest. This is not a violation of the RDF semantic rules, but it shows that the property of <em> "being a correct RDF test case manifest"</em> is not preserved under RDF entailment, and therefore cannot be described as an RDF <a>semantic extension</a>. Such entailment-risky uses of RDF should be restricted to cases, as here, where it is obvious to all parties what the intended special restrictions on entailment are, in contrast with the more normal case of using RDF for the open publication of data on the Web.</p>
-<p><strong>Empty Graph Lemma.</strong> The empty set of triples is entailed by
+</section>
+
+<section class="informative">
+
+<h3>Properties of simple entailment (Informative) </h3>
+<p>The properties described here apply only to simple entailment, not to extended notions of entailment introduced in later sections. Proofs are given in Appendix C. </p>
+
+<p class="fact">Every graph is satisfiable.</p>
+
+<p>This does not hold for extended notions of interpretation. For example, a graph containing an <a>ill-typed</a> literal is <a>D-unsatisfiable</a>.</p>
+
+<p>The following <dfn>interpolation</dfn> <strong>lemma</strong> </p>
+
+ <p class="fact">
+ G simply entails a graph E if and only if a subgraph of G is an instance of E.
+</p>
+
+<p> completely characterizes simple entailment in syntactic
+ terms. To detect whether one RDF graph simply entails another, check that
+ there is some instance of the entailed graph which is a subset of the first graph. </p>
+
+<p class="technote">This is clearly decidable, but it is also difficult to determine in general, since one can encode the NP-hard subgraph problem (detecting whether one mathematical graph is a subgraph of another) as detecting simple entailment between RDF graphs. This construction (due to Jeremy Carroll) uses graphs containing many blank nodes, which are unlikely to occur in practice. The complexity of checking simple entailment is reduced by having fewer blank nodes in the conclusion E. When E is a <a>ground</a> graph, it is simply a matter of checking the subset relationship on sets of triples.</p>
+
+<p><a>Interpolation</a> has a number of direct consequences, for example:</p>
+
+<p class="fact"> The <a>empty graph</a> is entailed by
any graph, and does not entail any graph except itself.
<!-- <a href="#emptygraphlemmaprf" class="termref">[Proof]</a> -->
</p>
-<p><a id="subglem"><strong>Subgraph Lemma.</strong></a> A graph
- entails all its subgraphs.
-<!-- <a href="#defsubg" class="termref"> subgraphs</a>. -->
+<p class="fact"> A graph entails all its subgraphs.
<!-- <a href="#subglemprf" class="termref">[Proof]</a> -->
</p>
-<p><a id="instlem"><strong>Instance Lemma.</strong></a> A graph
- is entailed by any of its <a href="#definst" class="termref">instances</a>.
+<p class="fact"> A graph
+ is entailed by any of its <a>instance</a>s.
<!-- <a href="#instlemprf" class="termref"> [Proof]</a> -->
</p>
+<p class="fact"> If
+ E is a <a>lean</a> graph and E' is a <a>proper instance</a> of E, then E does
+ not entail E'.
+</p>
+
+<p class="fact"> If S is a subgraph of S' and S entails E, then S' entails E.
+<!-- <a href="#monotonicitylemmaprf" class="termref"> [Proof]</a> -->
+</p>
+<p class="fact">
+ If S entails a finite graph E, then some finite subset S' of S entails E.
+<!-- <a href="#compactlemmaprf" class="termref"> [Proof]</a> -->
+</p>
+<p>The property just above is called <em>compactness</em> - RDF is compact. As RDF graphs can be infinite, this is sometimes important.</p>
+
+<p class="fact"> If E contains an IRI which does not occur anywhere in S, then S does not entail E.</p>
+
+
+</section>
+</section>
+
+<section class="informative"><h2 id="skolemization">Skolemization (Informative)</h2>
+<p><a class="externaldefinition">Skolemization</a> is a transformation on RDF graphs which eliminates blank nodes by replacing them with "new" IRIs, which means IRIs which are coined for this purpose and are therefore guaranteed to not occur in any other RDF graph (at the time of creation). See <a href="http://www.w3.org/TR/rdf11-concepts/#section-skolemization">Section 3.5</a> of [[!RDF11-CONCEPTS]] for a fuller discussion. </p>
+<p> Suppose G is a graph containing blank nodes and sk is a skolemization mapping from the blank nodes in G to the skolem IRIs which are substituted for them, so that sk(G) is a skolemization of G. Then the semantic relationship between them can be summarized as follows. </p>
+
+<p class="fact"> sk(G) simply entails G (since sk(G) is an instance of G.)</p>
+<p class="fact"> G does not entail sk(G) (since sk(G) contains IRIs not in G.) </p>
+<p class="fact"> For any graph H, if sk(G) entails H then there is a graph H' such that G entails H' and H=sk(H') . </p>
+<p class="fact"> For any graph H which does not contain any of the "new" IRIs introduced into sk(G), sk(G) simply entails H if and only if G simply entails H.
+</p>
-<p>Obviously, the union of a set of graphs entails every member of the set, since they are all subgraphs of the union. However, if two or more graphs in the set share a blank node. then the set may fail to entail the union. For example, consider the graphs</p>
-<p>
-<code>:a :p _:x . </code></p>
-<p>and</p>
-<p>
-<code>:b :p _:x .</code></p>
-<p>Both graphs can be satisfied by an interpretation which does not satisfy their union, e.g. one with <br>IEXT(I(<code>:p</code>)) = {< I(<code>:a</code>),I(<code>:a</code>) >, < I(<code>:b</code>),I(<code>:b</code>) > }. This is because the mapping <code>_:x</code>/I(<code>:a</code>) works for the first graph, and the mapping <code>_:x</code>/I(<code>:b</code>) for the second graph, but there is no mapping which works for the combination. Neither graph is obliged to consider the full set of constraints on the blank node that are represented by their union. </p>
+<p>The second property means that a graph is not logically <a>equivalent</a> to its skolemization. Nevertheless, they are in a strong sense almost interchangeable, as shown the next two properties. The third property means that even when conclusions are drawn from the skolemized graph which do contain the new vocabulary, these will exactly mirror what could have been derived from the original graph with the original blank nodes in place. The replacement of blank nodes by IRIs does not effectively alter what can be validly derived from the graph, other than by giving new names to what were formerly anonymous entities. The fourth property, which is a consequence of the third, clearly shows that in some sense a skolemization of G can "stand in for" G as far as entailments are concerned. Using sk(G) instead of G will not affect any entailments which do not involve the new skolem vocabulary. </p>
-<p>Say that a set S of graphs is <dfn id="dfn-segregated">segregated</dfn> when no two graphs in the set share a blank node.</p>
+</section>
+
+<section><h2 id="datatypes">Literals and datatypes</h2>
+<p class="changenote"> In the 2004 RDF 1.0 specification, datatype D-entailment was defined as a <a>semantic extension</a> of RDFS-entailment. Here it is defined as a direct extension to basic RDF. This is more in conformity with actual usage, where RDF with datatypes is widely used without the RDFS vocabulary. If there is a need to distinguish this from the 2004 RDF 1.0 terminology, the longer phrasing "simple D-entailment" or "simple datatype entailment" should be used rather than "D-entailment". </p>
+
+<p> Datatypes are <a title="identify">identified</a> by IRIs. Interpretations will vary according to which IRIs they recognize as denoting datatypes. We describe this using a parameter D on interpretations. where D is the set of <dfn>recognize</dfn><strong>d</strong> datatype IRIs. We assume that a recognized IRI <a title+"identify">identifies</a> a unique datatype wherever it occurs, and the semantics requires that it refers to this identified datatype. The exact mechanism by which an IRI <a title="identify">identifies</a> a datatype IRI is considered to be external to the semantics. RDF processors which are not able to determine which datatype is identifier by an IRI cannot <a>recognize</a> that IRI, and should treat any literals type with that IRI as unknown names. </p>
+
+<p class="changenote">In the 2004 RDF 1.0 specification, the semantics of datatypes referred to datatype maps. The current treatment subsumes datatype maps into the interpretation mapping on recognized IRIs.</p>
+
+<p>RDF literals and datatypes are fully described in <a href="http://www.w3.org/TR/rdf11-concepts/#section-Datatypes"> Section 5</a> of [[!RDF11-CONCEPTS]]. In summary: RDF literals are either language-tagged strings, or datatyped literals which
+combine a string and an IRI <a>identify</a>ing a datatype. A datatype is understood to define a partial mapping, called the <dfn>lexical-to-value mapping</dfn>, from character strings to values. The function <dfn>L2V</dfn> maps datatypes to their lexical-to-value mapping. A literal with datatype d denotes the value obtained by applying this mapping to the character string sss: L2V(d)(sss). If the lexical-to-value mapping gives no value for the literal string, then the literal has no referent. The <dfn>value space</dfn> of a datatype is the range of the <a>lexical-to-value mapping</a>. Every literal with that type either refers to a value in the value space of the type, or fails to refer at all. An <dfn>ill-typed</dfn> literal is one whose datatype IRI is <a>recognize</a>d, but whose character string is assigned no value by the <a>lexical-to-value mapping</a> for that datatype. </p>
+
+<p> RDF processors are not REQUIRED to <a>recognize</a> any datatype IRIs other than <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-language-tagged-string"><code>rdf:langString</code></a> and <a href="http://www.w3.org/TR/xmlschema11-2/#string"><code>xsd:string</code></a>, but when IRIs listed in <a href="http://www.w3.org/TR/rdf11-concepts/#section-Datatypes">Section 5</a> of [[!RDF11-CONCEPTS]] are <a>recognize</a>d, they MUST be interpreted as described there, and when the IRI <code>rdf:PlainLiteral</code> is <a>recognize</a>d, it MUST be interpreted to refer to the datatype defined in [[!RDF-PLAIN-LITERAL]]. RDF processors MAY recognize other datatype IRIs, but when other datatype IRIs are <a>recognize</a>d, the mapping between a <a>recognize</a>d IRI and the datatype it refers to MUST be specified unambiguously, and MUST be fixed during all RDF transformations or manipulations.</p>
+
+<p>Literals with <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-language-tagged-string"><code>rdf:langString</code></a> as their datatype are an exceptional case which are given a special treatment. The IRI <code>rdf:langString</code> is classified as a datatype IRI, and interpreted to refer to a datatype, even though no L2V mapping is defined for it. The value space of <code>rdf:langString</code> is the set of all pairs of a string with a language tag. The semantics of literals with this as their type are given below. </p>
+
+<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it is not <a>recognize</a>d as referring to a datatype. Literals with such an "unknown" datatype IRI, which is not in the set of <a>recognize</a>d datatypes, SHOULD NOT be treated as errors, although RDF applications MAY issue a warning. Such literals SHOULD be treated like IRIs and assumed to denote some thing in the universe IR. RDF processors which fail to <a>recognize</a> a datatype IRI will not be able to detect some entailments which are visible to one which does. For example, the fact that </p><p><code>ex:a ex:p "20.0000"^^xsd:decimal .</code></p><p>entails </p><p><code>ex:a ex:p "20.0"^^xsd:decimal .</code></p><p>will not be visible to a processor which does not <a>recognize</a> the datatype IRI <code>xsd:decimal</code>.</p>
-<p><a id="mergelem"><strong>Merging lemma.</strong></a> The union
- of a segregated set S of RDF graphs is entailed by S, and entails every member of S.
-<!-- <a href="#mergelemprf" class="termref">[Proof]</a> -->
+<section id="D_interpretations"><h2>D-interpretations</h2>
+<p>Let D be a set of IRIs <a>identify</a>ing datatypes. A <dfn>(simple) D-interpretation</dfn> is a <a>simple interpretation</a> which satisfies the following conditions:</p>
+
+<div class="tabletitle">Semantic conditions for datatyped literals.</div>
+<table border="1">
+ <tbody>
+<tr><td class="semantictable">If <code>rdf:langString</code> is in D, then for every language-tagged string E with lexical form sss and language tag ttt, IL(E)= < sss, ttt' >, where ttt' is ttt converted to lower case using US-ASCII rules </td></tr>
+
+<tr><td class="semantictable">For every other IRI aaa in D, I(aaa) is the datatype identified by aaa, and for every literal "sss"^^aaa, IL("sss"^^aaa) = L2V(I(aaa))(sss)</td></tr>
+</tbody></table>
+
+
+<p>If the literal is <a>ill-typed</a> then the L2V(I(aaa)) mapping has no value, and so the literal cannot denote anything. In this case, any triple containing the literal must be false. Thus, any triple, and hence any graph, containing an <a>ill-typed</a> literal will be <a>D-unsatisfiable</a>, i.e. false in every D-interpretation. This applies only to literals typed with recognized datatype IRIs in D; literals with an unrecognized type IRI are not <a>ill-typed</a> and cannot give rise to a <a>D-unsatisfiable</a> graph. </p>
+
+<p>The built-in RDF datatype <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-language-tagged-string"><code>rdf:langString</code></a> has no <a>ill-typed</a> literals. Any syntactically legal literal with this type will denote a value in every RDF interpretation. The only ill-typed literals of type <a href="http://www.w3.org/TR/xmlschema11-2/#string"><code>xsd:string</code></a> are those containing a Unicode code point which does not match the <a href="http://www.w3.org/TR/xml11/#NT-Char"><em>Char</em> production</a> in [[XML10]]. Such strings cannot be written in an XML-compatible surface syntax.
+
</p>
- <p>This means that a segregated set of graphs can be treated as <a href="#glossEquivalent" class="termref">equivalent</a> to its
- merge, a single graph, as far as the <a href="#glossModeltheory" class="termref">model theory</a> is
- concerned. In general, we will not usually bother to distinguish between a set of graphs and the single graph formed by taking their union. </p>
- <p>The main result for simple entailment is:</p>
-<p><a id="interplemma"><strong>Interpolation Lemma.</strong>
- S entails a graph E if and only if a subgraph of S is an instance of E. </a>
-<!-- <a href="#interplemmaprf" class="termref">[Proof]</a> -->
-</p>
-<p>The interpolation lemma completely characterizes simple entailment in syntactic
- terms. To tell whether a set of RDF graphs simply entails another, check that
- there is some instance of the entailed graph which is a subset of the merge
- of the original set of graphs. </p>
-<p>This is clearly decidable, but it is also theoretically very hard in general, since one can encode the NP-hard subgraph problem (detecting whether one mathematical graph is a subgraph of another) as detecting simple entailment between RDF graphs. (///Refer to Jeremy Carroll.///) </p>
-
-<p><a id="Anonlem1"><strong>Anonymity lemma.</strong></a> Suppose
- E is a <a class="internalDFN" href="#dfn-lean">lean</a> graph and E' is a proper instance of E. Then E does
- not entail E'.
-<!--
-<a href="#Anonlem1prf" class="termref">[Proof]</a>
--->
-</p>
-
-<p><strong><a id="monotonicitylemma"></a>Monotonicity
- Lemma</strong>. Suppose S is a subgraph of S' and S entails E. Then S' entails E.
-<!-- <a href="#monotonicitylemmaprf" class="termref"> [Proof]</a> -->
-</p>
-<p><strong><a id="compactlemma"></a>Compactness Lemma</strong>.
- If S entails E and E is a finite graph, then some finite subset S' of S entails E.
-<!-- <a href="#compactlemmaprf" class="termref"> [Proof]</a> -->
-</p>
-</section>
-<section id="skolemization-1"><!--OddPage--><h2 id="skolemization"><span class="secno">6. </span>Skolemization</h2>
-<p>Skolemization is a transformation on RDF graphs which eliminates blank nodes by replacing them with "new" IRIs, which means IRIs which are coined for this purpose and are therefore guaranteed to not occur in any other RDF graph (at the time of creation). See ///Concepts#/// for a fuller discussion. </p>
-<p> Suppose G is a graph containing blank nodes and sk is a skolemization mapping on the blank nodes in G, so that sk(G) is a skolemization of G. Then the semantic relationship between them can be summarized as follows. </p>
-<p>1. sk(G) simply entails G (by the <a href="#instlem" class="termref">instance lemma</a>, since sk(G) is an instance of G)</p>
-<p>2. G does not entail sk(G).
-<!-- <a href="#skolemizeNentaillemmaprf" class="termref"> [Proof]</a> -->
-</p>
-<p>3. For any graph H, if sk(G) entails H then there is a graph H' such that G entails H' and H=sk(H') .
-<!-- <a href="#skolemizeMainlemmaprf" class="termref"> [Proof]</a> -->
-</p>
-<p>4. For any graph H which does not contain any of the "new" IRIs introduced into sk(G), sk(G) simply entails H if and only if G simply entails H.
-<!-- <a href="#skolemizlemmaprf" class="termref"> [Proof]</a> -->
-</p>
+<p class="changenote"> In the 2004 RDF 1.0 specification, ill-typed literals were required to denote a value in IR, and D-inconsistency could only be recognized by using the RDFS semantics. </p>
-<p>The second property means that a graph is not equivalent to its skolemization, so we cannot simply identify them. Nevertheless, they are in a strong sense almost interchangeable, as the next two properties attest. The third property means that even when conclusions are drawn from the skolemized graph which do contain the new vocabulary, these will exactly mirror what could have been derived from the original graph with the original blank nodes in place. The replacement of blank nodes by IRIs does not effectively alter what can be validly derived from the graph, other than by giving new names to what were formerly anonymous entities. The fourth property, which is a consequence of the third, clearly shows that in some sense a skolemization of G can "stand in for" G as far as entailments are concerned. Using sk(G) instead of G will not affect any entailments which do not involve the new skolem vocabulary. </p>
-
-<p>Skolemization means that it is possible to use RDF without using blank nodes without losing any real expressivity. Opinions differ on the merits of this strategy.</p>
-
-<ul><li><p class="technote">The more general notion of skolemization involving Skolem functions is not used in RDF as there are no universal quantifiers.</p>
-</li></ul>
</section>
-
-<section id="literals-and-datatypes"><!--OddPage--><h2 id="datatypes"><span class="secno">7. </span>Literals and datatypes</h2>
-<ul><li><p class="changenote"> In the 2004 RDF 1.0 specification, datatype D-entailment was defined as a semantic extension of RDFS-entailment. Here it is defined as a direct extension to basic RDF. This is more in conformity with actual usage, where RDF with datatypes is widely used without the RDFS vocabulary. If there is a need to distinguish this from the 2004 RDF 1.0 terminology, the longer phrasing "simple D-entailment" or "simple datatype entailment" should be used rather than "D-entailment". </p>
-</li></ul>
-
-<p>RDF literals and datatypes are fully described in [<cite><a href="#bib-RDF11-CONCEPTS" class="bibref">RDF11-CONCEPTS</a></cite>]. In summary: RDF literals are either language-tagged strings, or datatyped literals which
-combine a string and an IRI identifying a datatype. A datatype is understood to define a partial mapping, called the <dfn id="dfn-lexical-to-value-mapping">lexical-to-value mapping</dfn>, from character strings to values, and the literal refers to the value obtained by applying this mapping to the character string. If the mapping gives no value for the literal string, then the literal has no referent. The <dfn id="dfn-value-space">value space</dfn> of a datatype is the range of the <a class="internalDFN" href="#dfn-lexical-to-value-mapping">lexical-to-value mapping</a>. Every literal with that type either refers to a value in the value space, or fails to refer at all. An <dfn id="dfn-ill-typed">ill-typed</dfn> literal is one whose datatype IRI is recognized, but whose character string is not in the domain of the datatype lexical-to-value mapping. Datatypes are indicated by IRIs.
-</p>
-
-<p> Interpretations will vary according to which IRIs they recognize as denoting datatypes. We describe this using a parameter D on interpretations. where D is a set of IRIs that constitute the recognized datatype IRIs. IRIs listed in <a href="http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/#xsd-datatypes">///Concepts Section 5///</a> <em title="MUST" class="rfc2119">MUST</em> be interpreted as described there, and the IRI <code>rdf:plainLiteral</code> <em title="MUST" class="rfc2119">MUST</em> be interpreted to refer to the datatype defined in [<cite><a href="#bib-RDF-PLAINLITERAL" class="bibref">RDF-PLAINLITERAL</a></cite>]. When other datatypes are used, the mapping between a recognized IRI and the datatype it refers to <em title="MUST" class="rfc2119">MUST</em> be specified unambiguously, and be fixed during all RDF transformations or manipulations.</p>
-
-<p>Language-tagged strings are an exceptional case which are given a special treatment. The IRI <code>rdf:langString</code> is classified as a datatype IRI, and interpreted to refer to a datatype, even though no L2V mapping is defined for it. The value space of <code>rdf:langString</code> is the set of all pairs of a string with a language tag. The semantics of literals with this as their type are given below. (If datatype L2V mappings were defined on pairs of lexical values rather than strings, then the L2V mapping for <code>rdf:langString</code> would be the identity function on pairs of the form < unicode string, language tag >. But as they are not, we simply list this as a special case.)</p>
+<section>
+<h3 id="D_entailment">Datatype entailment</h3>
-<div class="issue"><div class="issue-title"><span>Issue 4</span></div><p class="">This will require alignment with Concepts. rdf:langString may have an L2V mapping which is ignored by the semantics. Concepts currently states that it is not a datatype even though the IRI is a datatype IRI. </p></div>
-
-<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it does not identify a datatype. Literals with an "unknown" datatype IRI which is not in the set of recognized datatypes, are treated like IRI names and assumed to denote some thing in the universe IR. </p>
-
-</section>
+<p>A graph is (simply) <dfn>D-satisfiable</dfn> or <dfn>satisfiable recognizing D</dfn> when it has the value true in some D-interpretation, and a graph S (simply) <dfn>D-entails</dfn> or <dfn>entails recognizing D</dfn> a graph G when every D-interpretation which satisfies S also D-satisfies G.</p>
-<section id="D_interpretations"><!--OddPage--><h2><span class="secno">8. </span>D-interpretations and datatype entailment</h2>
-<p>Let D be a set of IRIs identifying datatypes. A <dfn id="dfn-simple-d-interpretation">(simple) D-interpretation</dfn> is a simple interpretation which satisfies the following conditions:</p>
+<p> Unlike the case with <a>simple interpretation</a>s, it is possible for a graph to have no satisfying D-interpretations, i.e. to be <dfn>D-unsatisfiable</dfn>. RDF processors MAY treat an unsatisfiable graph as signaling an error condition, but this is not required.</p>
-<div class="tabletitle">Semantic conditions for datatyped literals.</div>
-<table class="semantictable" border="1">
- <tbody>
-<tr><td>If <code>rdf:langString</code> is in D, then for every language-tagged string E with lexical form sss and language tag ttt, IL(E)= < sss, ttt > </td></tr>
-<tr><td>For every other IRI aaa in D, and every literal "sss"^^aaa, IL("sss"^^aaa) = L2V(I(aaa))(sss)</td></tr>
-</tbody></table>
+<p> A <a>D-unsatisfiable</a> graph D-entails any graph.</p>
+
+<p class="technote">The fact that an unsatisfiable statement entails any other statement has been known since antiquity. It is called the principle of <em>ex falso quodlibet</em>. It should not be interpreted to mean that it is necessary, or even permissible, to actually draw any conclusion from an inconsistency.</p>
+
+<p>In all of this language, 'D' is being used as a parameter to represent some set of datatype IRIs, and different D sets will yield different notions of satisfiability and entailment. The more datatypes are <a>recognize</a>d, the stronger is the entailment, so that if D ⊂ E and S E-entails G then S must D-entail G. Simple entailment is { }-entailment, i.e. D-entailment when D is the empty set, so if S D-entails G then S simply entails G. </p>
-<p>If the literal is ill-typed then the L2V mapping has no value, and so the literal cannot denote anything. In this case, any triple containing the literal must be false. Thus, any triple, and hence any graph, containing an ill-typed literal will be D-inconsistent, i.e. false in every D-interpretation. This applies only to datatype IRIs in D; literals with "unknown" datatypes are not ill-typed and do not produce a D-inconsistency. </p>
-
-
-<ul><li><p class="changenote"> In the 2004 RDF 1.0 specification, ill-typed literals were required to denote a value in IR, and D-inconsistency could only be recognized by using the RDFS semantics. </p>
-<p></p>
-</li></ul>
-
-<h2 id="D_entailment">Datatype entailment</h2>
-<p>A graph is (simply) <dfn id="dfn-d-satisfiable">D-satisfiable</dfn> when it has the value true in some D-interpretation, and a set S of graphs (simply) <dfn id="dfn-d-entails">D-entails</dfn> a graph G when every D-interpretation which makes S true also D-satisfies G.</p>
-
-<p> Unlike the case with simple interpretations, it is possible for a graph to have no satisfying D-interpretations, i.e. to be <dfn id="dfn-d-unsatisfiable">D-unsatisfiable</dfn>. A D-unsatisfiable graph D-entails any graph. </p>
+<section class="informative"> <h4>Patterns of datatype entailment (Informative)</h4>
+<p>Unlike <a title="simply entails">simple entailment</a>, it is not possible to give a single syntactic criterion to detect all D-entailments, which
+can hold because of particular properties of the lexical-to-value mappings of the <a>recognize</a>d datatypes. For example, if D contains <code>xsd:decimal</code> then </p>
-<p>In all of this language, 'D' is being used as a parameter to represent some set of datatype IRIs, and different D sets will yield different notions of satisfiability and entailment. The more datatypes are recognized, the stronger is the entailment, so that if D ⊂ E and S E-entails G then S must D-entail G. Simple entailment is { }-entailment, i.e. D-entailment when D is the empty set. If S D-entails G then S simply entails G, but not the reverse. </p>
-
-<p>Several of the basic properties of simple entailment are also true for D-entailment, but the <a>interpolation lemma</a> is not true for <a>D-entailment</a>, since D-entailments
-can hold because of particular properties of the lexical-to-value mappings of the recognized datatypes. For example, if D contains <code>xsd:integer</code> then </p>
-
-<p><code>aaa ppp "00025"^^xsd:integer .</code></p>
+<p><code>ex:a ex:p "25.0"^^xsd:decimal .</code></p>
<p>D-entails</p>
-<p><code>aaa ppp "25"^^xsd:integer .</code>
+<p><code>ex:a ex:p "25"^^xsd:decimal .</code>
</p>
-<p>
-</p><p>Ill-typed literals are the only form of simple D-contradiction, but datatypes can give rise to a variety of other contradictions when combined with the <a>RDFS vocabulary</a>, defined later.</p>
+<p>In general, any triple containing a literal with a <a>recognize</a>d datatype IRI D-entails another literal when the lexical strings of the literals map to the same value under the lexical-to-value map of the datatype. If two different datatypes in D map lexical strings to a common value, then a triple containing a literal typed with one datatype may D-entail another triple containing a literal typed with a different datatype. For example, <code>"25"^^xsd:integer</code> and <code>"25.0"^^xsd:decimal</code> have the same value, so the above also D-entails </p>
+
+<p><code>ex:a ex:p "25"^^xsd:integer .</code></p>
+
+<p>when D also contains <code>xsd:integer</code>.
+
+<p>(There is a W3C Note [[SWBP-XSCH-DATATYPES]] containing a long <a href="http://www.w3.org/TR/swbp-xsch-datatypes/#sec-values">discussion</a> of literal values.)</p>
+
+<p><a>ill-typed</a> literals are the only way in which a graph can be simply <a>D-unsatisfiable</a>, but datatypes can give rise to a variety of other unsatisfiable graphs when combined with the RDFS vocabulary, defined later.</p>
+</section>
</section>
-<section id="rdf-d-interpretations-and-rdf-entailment"><!--OddPage--><h2 id="rdf_d_interpretations"><span class="secno">9. </span>RDF-D Interpretations and RDF entailment</h2>
- <p>RDF-D interpretations impose extra semantic conditions on <code>xsd:string</code> and part of the infinite
- set of IRIs in the <code>rdf:</code> namespace.
+</section>
+<section><h2 id="rdf_d_interpretations">RDF Interpretations</h2>
+ <p >RDF interpretations impose extra semantic conditions on <code>xsd:string</code> and part of the infinite
+ set of IRIs with the namespace prefix <code>rdf:</code> .
-</p><p>An <dfn id="dfn-rdf-d-interpretation">rdf-D-interpretation</dfn> I is a D-interpretation where D includes <code>rdf:langString</code> and <code>xsd:string</code>, and which satisfies:</p>
+<p>An <dfn>RDF interpretation</dfn> <strong>recognizing D</strong> is a <a>D-interpretation</a> I where D includes <code>rdf:langString</code> and <code>xsd:string</code>, and which satisfies:</p>
<div class="tabletitle">RDF semantic conditions.</div>
-<table border="1">
+<table border="1">
<tbody>
<tr>
<td class="semantictable"><a id="rdfsemcond1"></a>x is
@@ -715,62 +605,131 @@
<p>and satisfies every triple in the following infinite set:</p>
<div class="tabletitle">RDF axioms.</div>
- <table border="1">
- <tbody><tr>
- <td class="ruletable"><a id="RDF_axiomatic_triples"> </a><code>rdf:type rdf:type rdf:Property .<br>
- rdf:subject rdf:type rdf:Property .<br>
- rdf:predicate rdf:type rdf:Property .<br>
- rdf:object rdf:type rdf:Property .<br>
- rdf:first rdf:type rdf:Property .<br>
- rdf:rest rdf:type rdf:Property .<br>
- rdf:value rdf:type rdf:Property .<br>
- rdf:nil rdf:type rdf:List .<br>
- rdf:_1 rdf:type rdf:Property .<br>
- rdf:_2 rdf:type rdf:Property .<br>
- ... <br>
+ <table border="1">
+ <tr>
+ <td class="ruletable"><a id="RDF_axiomatic_triples"> </a><code>rdf:type rdf:type rdf:Property .<br/>
+ rdf:subject rdf:type rdf:Property .<br/>
+ rdf:predicate rdf:type rdf:Property .<br/>
+ rdf:object rdf:type rdf:Property .<br/>
+ rdf:first rdf:type rdf:Property .<br/>
+ rdf:rest rdf:type rdf:Property .<br/>
+ rdf:value rdf:type rdf:Property .<br/>
+ rdf:nil rdf:type rdf:List .<br/>
+ rdf:_1 rdf:type rdf:Property .<br/>
+ rdf:_2 rdf:type rdf:Property .<br/>
+ ... <br/>
</code>
</td>
</tr>
- </tbody></table>
+ </table>
-<p>No other semantic constraints are imposed upon <a class="internalDFN" href="#dfn-rdf-d-interpretation">rdf-D-interpretation</a>s, so RDF imposes no particular normative meanings on the rest of the RDF vocabulary. Some consequences of this are discussed in <a>Appendix C</a></p>
+<p>RDF imposes no particular normative meanings on the rest of the RDF vocabulary. <a>Appendix D</a> describes the intended uses of some of this vocabulary.</p>
-<p id="rdfinterpdef">An <em>rdf-interpretation</em>, or <em>RDF interpretation</em>, is an rdf-{<code>rdf:langString</code>, <code>xsd:string</code> }-interpretation, i.e. an rdf-D-Interpretation with a minimal set D. The datatypes <code>rdf:langString</code> and <code>xsd:string</code> <em title="MUST" class="rfc2119">MUST</em> be recognized by all RDF interpretations. </p><p>The RDF built-in datatypes <code>rdf:XMLLiteral</code> and <code>rdf:HTML</code> are defined in [<cite><a href="#bib-RDF11-CONCEPTS" class="bibref">RDF11-CONCEPTS</a></cite>]. RDF interpretations are not required to recognize these datatypes. </p>
-
-<h2 id="rdf-entailment"><a id="rdf_entail"></a>RDF entailment</h2>
-
-<p>S <i>rdf-D-entails</i> E when every rdf-D-interpretation which satisfies every
- member of S also satisfies E. </p>
+<p>The datatype IRIs <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-language-tagged-string"><code>rdf:langString</code></a> and <a href="http://www.w3.org/TR/xmlschema11-2/#string"><code>xsd:string</code></a> MUST be <a>recognize</a>d by all RDF interpretations. </p>
-<p>The lemmas for <a href="#simpleentailment">simple entailment</a> do not all apply to rdf-D-entailment:
- for example, all the rdf axioms are true in every <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>, so are rdf-D-entailed by the empty graph,
- contradicting the <a href="#interplemma" class="termref">interpolation lemma</a> for rdf-D-entailment. Section //// gives rules that can be used to detect RDF entailment between RDF graphs. </p>
+<p>Two other datatypes <a href="http://www.w3.org/TR/rdf11-concepts/#section-XMLLiteral"><code>rdf:XMLLiteral</code></a> and <a href="http://www.w3.org/TR/rdf11-concepts/#section-html"><code>rdf:HTML</code></a> are defined in [[!RDF11-CONCEPTS]]. RDF-D interpretations MAY fail to <a>recognize</a> these datatypes. </p>
-<p> The last semantic condition in the above table gives entailments of this form for recognized datatypes: </p>
-<p><code>aaa ppp "123"^^xsd:integer .</code></p>
+<section>
-<p>rdf-{<code>xsd:integer</code>}-entails</p>
+<h3><a id="rdf_entail"></a>RDF entailment</h3>
-<code>aaa ppp _:x . <br> _:x rdf:type xsd:integer .</code>
+<p>S <dfn>RDF entail</dfn><strong>s</strong> E <strong>recognizing D</strong> when every <a>RDF interpretation recognizing D</a> which satisfies S also satisfies E. When D is {<code>rdf:langString</code>, <code>xsd:string</code>} then we simply say S <strong>RDF entails</strong> E. </p>
+
+<p>The properties of <a>simple entailment</a> described earlier do not all apply to <a>RDF entail</a>ment. For example, all the RDF axioms are true in every <a>RDF interpretation</a>, and so are <a>RDF entail</a>ed by the empty graph, contradicting <a>interpolation</a> for RDF entailment. </p>
+
+
+<section class="informative"><h4>Patterns of RDF entailment (Informative)</h4>
+<p> The last semantic condition in the above table gives the following entailment pattern for <a>recognize</a>d datatype IRIs: </p>
+
+<div class="tabletitle">RDF entailment pattern.</div>
+<table border="1" >
+ <tbody>
+ <tr>
+ <th > </th>
+ <th ><strong>if S contains</strong></th>
+ <th ><strong>then S RDF entails, recognizing D</strong></th>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfD1</dfn></td>
+ <td class="othertable"> xxx aaa <code>"</code>sss<code>"^^</code>ddd <code>.</code> <br/>
+ for ddd in D</td>
+ <td class="othertable">xxx aaa _:nnn <code>.</code><br/>
+_:nnn <code>rdf:type</code> ddd <code>.</code></td>
+ </tr>
+
+ </tbody>
+</table>
+<p>Note, this is valid even when the literal is <a>ill-typed</a>, since an unsatisfiable graph entails any triple.</p>
+
+<p>For example,</p>
+<p> <code>ex:a ex:p "123"^^xsd:integer .</code></p>
+
+<p>RDF entails recognizing {<code>xsd:integer</code>}</p>
+
+<code>ex:a ex:p _:x . <br/>
+ _:x rdf:type xsd:integer . </code></p>
+
+<p>In addition, the first RDF semantic condition justifies the following entailment pattern:</p>
+
+<table border="1" >
+ <tbody>
+ <tr>
+ <th > </th>
+ <th ><strong>if S contains</strong></th>
+ <th ><strong>then S RDF entails, recognizing D</strong></th>
+ </tr>
+
+ <tr>
+ <td class="othertable"><dfn>rdfD2</dfn></td>
+ <td class="othertable">xxx aaa yyy <code>.</code></td>
+ <td class="othertable">aaa <code>rdf:type rdf:Property .</code> </td>
+ </tr>
+
+
+ </tbody>
+</table>
+
+
+<p>So that the above example also RDF entails</p><p><code>ex:p rdf:type rdf:Property .</code></p><p> recognizing {<code>xsd:integer</code>}.</p>
+
+
+<p>Some datatypes support idiosyncratic entailment patterns which do not hold for other datatypes. For example, </p>
+
+<p><code> ex:a ex:p "true"^^xsd:boolean . <br/>
+ex:a ex:p "false"^^xsd:boolean .<br/>
+ex:v rdf:type xsd:boolean .</code></p>
+
+together RDF entail</p>
+
+<p><code>ex:a ex:p ex:v .</code></p>
+
+<p> recognizing {<code>xsd:boolean</code>}.</p>
+
+<p>In addition, the semantic conditions on value spaces may produce other unsatisfiable graphs. For example, when D contains <code>xsd:integer</code> and <code>xsd:boolean</code>, then the following is <a>RDF unsatisfiable</a> recognizing D:</p>
+
+<p><code>_:x rdf:type xsd:boolean .<br/>
+_:x rdf:type xsd:integer . </code></p>
</section>
-<section id="rdfs-interpretations-and-rdfs-entailment"><!--OddPage--><h2 id="rdfs_interpretaitons"><span class="secno">10. </span>RDFS Interpretations and RDFS entailment</h2>
-<p>RDF Schema [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>]
- extends RDF to a larger <a id="defRDFSV"></a>vocabulary
+</section>
+</section>
+<section><h2>RDFS Interpretations</h2>
+<p>RDF Schema [[RDF-SCHEMA]]
+ extends RDF to a larger vocabulary
with more complex semantic constraints:</p>
- <div class="c1">
+ <div >
<table border="1">
<tbody>
<tr>
- <td class="othertable"><strong>RDFS vocabulary</strong></td>
+ <td ><dfn>RDFS vocabulary</dfn></td>
</tr>
<tr>
- <td class="othertable"><code>rdfs:domain rdfs:range rdfs:Resource rdfs:Literal
+ <td ><code>rdfs:domain rdfs:range rdfs:Resource rdfs:Literal
rdfs:Datatype rdfs:Class rdfs:subClassOf rdfs:subPropertyOf
rdfs:member rdfs:Container rdfs:ContainerMembershipProperty
rdfs:comment rdfs:seeAlso rdfs:isDefinedBy
@@ -784,11 +743,11 @@
apply to their use can be stated using <code>rdfs:domain</code>,<code> rdfs:range</code>
and <code>rdfs:subPropertyOf</code>. Other than this, the formal semantics does
not constrain their meanings.)</p>
-<p>Although not strictly necessary, it is convenient to state the RDFS semantics
- in terms of a new semantic construct, a <a href="#glossClass" class="termref"><em>class</em></a>, i.e. a resource which represents
- a set of things in the universe which all have that class as the value of their
- <code>rdf:type</code> property. Classes are defined to be things of type <code>rdfs:Class</code>,
- and <span>the set of all classes in an interpretation will be called IC</span>.
+<p>It is convenient to state the RDFS semantics
+ in terms of a new semantic construct, a <dfn>class</dfn>, i.e. a resource which represents
+ a set of things in the universe which all have that class as a value of their
+ <code>rdf:type</code> property. <a>Class</a>es are defined to be things of type <code>rdfs:Class</code>,
+ and the set of all classes in an interpretation will be called IC.
The semantic conditions are stated in terms of a mapping ICEXT (for the <em>C</em>lass
<em>Ext</em>ension in I) from IC to the set of subsets of IR.</p><p> A class may have an
empty class extension. Two different classes can have the same class extension.
@@ -796,13 +755,12 @@
</p>
-<p><a id="rdfsinterpdef"></a> An <i>rdfs-D-interpretation</i> is an <a href="#rdfinterpdef" class="termref">rdf-D-interpretation</a> I
- which satisfies the semantic conditions in the following table, and satisfies all the triples in the subsequent table of <em>RDFS axiomatic triples</em>. As before, an <em>rdfs-interpretation</em>, or <em>RDFS interpretation</em>, is an rdfs-D-interpretation with D= {<code>xsd:string</code>, <code>rdf:langString</code> }.</p>
+<p> An <dfn>RDFS interpretation</dfn> (<strong>recognizing D</strong>) is an <a>RDF interpretation</a> (recognizing D) I
+ which satisfies the semantic conditions in the following table, and all the triples in the subsequent table of RDFS axiomatic triples. </p>
-<div class="issue"><div class="issue-title"><span>Issue 5</span></div><p class="">This table has redundancies. I am inclined to leave them alone, as it takes quite a lot of thought to figure out some of the consequences when we only give non-redundant conditions. </p></div>
<div class="tabletitle">RDFS semantic conditions.</div>
- <table border="1">
- <tbody><tr>
+ <table border="1">
+ <tr>
<td class="semantictable"> <p><a id="rdfssemcond1"></a>ICEXT(y) is defined to be { x : < x,y > is in IEXT(I(<code>rdf:type</code>)) }</p>
<p>IC is defined to be ICEXT(I(<code>rdfs:Class</code>))</p>
@@ -855,17 +813,17 @@
<tr>
<td class="semantictable"><p><a id="rdfssemcond9"></a>If
- x is in ICEXT(I(<code>rdfs:ContainerMembershipProperty</code>)) then:<br>
- < x, I(<code>rdfs:member</code>) > is in IEXT(I(<code>rdfs:subPropertyOf</code>))<br>
- </p></td>
+ x is in ICEXT(I(<code>rdfs:ContainerMembershipProperty</code>)) then:<br/>
+ < x, I(<code>rdfs:member</code>) > is in IEXT(I(<code>rdfs:subPropertyOf</code>))<br/>
+ </td>
</tr>
<tr>
<td class="semantictable"><p><a id="rdfssemcond10"></a>If
- x is in ICEXT(I(<code>rdfs:Datatype</code>)) then <span>< x,
+ x is in ICEXT(I(<code>rdfs:Datatype</code>)) then <span >< x,
I(<code>rdfs:Literal</code>) > is in IEXT(I(<code>rdfs:subClassOf</code>))</span></p></td>
</tr>
- </tbody></table>
+ </table>
<p></p>
@@ -874,233 +832,429 @@
<p><a id="RDFS_axiomatic_triples"> </a>
</p>
<div class="tabletitle">RDFS axiomatic triples.</div>
- <table border="1">
+ <table border="1">
- <tbody><tr>
+ <tr>
- <td class="ruletable"> <code>rdf:type rdfs:domain rdfs:Resource .<br>
- rdfs:domain rdfs:domain rdf:Property .<br>
- rdfs:range rdfs:domain rdf:Property .<br>
- rdfs:subPropertyOf rdfs:domain rdf:Property .<br>
- <a id="axtripleforproof1"></a>rdfs:subClassOf rdfs:domain
- rdfs:Class .<br>
- rdf:subject rdfs:domain rdf:Statement .<br>
- rdf:predicate rdfs:domain rdf:Statement .<br>
- rdf:object rdfs:domain rdf:Statement .<br>
- rdfs:member rdfs:domain rdfs:Resource . <br>
- rdf:first rdfs:domain rdf:List .<br>
- rdf:rest rdfs:domain rdf:List .<br>
- rdfs:seeAlso rdfs:domain rdfs:Resource .<br>
- rdfs:isDefinedBy rdfs:domain rdfs:Resource .<br>
- rdfs:comment rdfs:domain rdfs:Resource .<br>
- rdfs:label rdfs:domain rdfs:Resource .<br>
- rdf:value rdfs:domain rdfs:Resource .<br>
- <br>
- rdf:type rdfs:range rdfs:Class .<br>
- rdfs:domain rdfs:range rdfs:Class .<br>
- rdfs:range rdfs:range rdfs:Class .<br>
- rdfs:subPropertyOf rdfs:range rdf:Property .<br>
- <a id="axtripleforproof2"></a>rdfs:subClassOf rdfs:range
- rdfs:Class .<br>
- rdf:subject rdfs:range rdfs:Resource .<br>
- rdf:predicate rdfs:range rdfs:Resource .<br>
- rdf:object rdfs:range rdfs:Resource .<br>
- rdfs:member rdfs:range rdfs:Resource .<br>
- rdf:first rdfs:range rdfs:Resource .<br>
- rdf:rest rdfs:range rdf:List .<br>
- rdfs:seeAlso rdfs:range rdfs:Resource .<br>
- rdfs:isDefinedBy rdfs:range rdfs:Resource .<br>
- rdfs:comment rdfs:range rdfs:Literal .<br>
- rdfs:label rdfs:range rdfs:Literal .<br>
- rdf:value rdfs:range rdfs:Resource .<br>
- <br>
- rdf:Alt rdfs:subClassOf rdfs:Container .<br>
- rdf:Bag rdfs:subClassOf rdfs:Container .<br>
- rdf:Seq rdfs:subClassOf rdfs:Container .<br>
- rdfs:ContainerMembershipProperty rdfs:subClassOf rdf:Property .<br>
- <br>
- rdfs:isDefinedBy rdfs:subPropertyOf rdfs:seeAlso .<br>
- <br>
+ <td class="ruletable"> <code>rdf:type rdfs:domain rdfs:Resource .<br/>
+ rdfs:domain rdfs:domain rdf:Property .<br/>
+ rdfs:range rdfs:domain rdf:Property .<br/>
+ rdfs:subPropertyOf rdfs:domain rdf:Property .<br/>
+ rdfs:subClassOf rdfs:domain rdfs:Class .<br/>
+ rdf:subject rdfs:domain rdf:Statement .<br/>
+ rdf:predicate rdfs:domain rdf:Statement .<br/>
+ rdf:object rdfs:domain rdf:Statement .<br/>
+ rdfs:member rdfs:domain rdfs:Resource . <br/>
+ rdf:first rdfs:domain rdf:List .<br/>
+ rdf:rest rdfs:domain rdf:List .<br/>
+ rdfs:seeAlso rdfs:domain rdfs:Resource .<br/>
+ rdfs:isDefinedBy rdfs:domain rdfs:Resource .<br/>
+ rdfs:comment rdfs:domain rdfs:Resource .<br/>
+ rdfs:label rdfs:domain rdfs:Resource .<br/>
+ rdf:value rdfs:domain rdfs:Resource .<br/>
+ <br/>
+ rdf:type rdfs:range rdfs:Class .<br/>
+ rdfs:domain rdfs:range rdfs:Class .<br/>
+ rdfs:range rdfs:range rdfs:Class .<br/>
+ rdfs:subPropertyOf rdfs:range rdf:Property .<br/>
+ rdfs:subClassOf rdfs:range rdfs:Class .<br/>
+ rdf:subject rdfs:range rdfs:Resource .<br/>
+ rdf:predicate rdfs:range rdfs:Resource .<br/>
+ rdf:object rdfs:range rdfs:Resource .<br/>
+ rdfs:member rdfs:range rdfs:Resource .<br/>
+ rdf:first rdfs:range rdfs:Resource .<br/>
+ rdf:rest rdfs:range rdf:List .<br/>
+ rdfs:seeAlso rdfs:range rdfs:Resource .<br/>
+ rdfs:isDefinedBy rdfs:range rdfs:Resource .<br/>
+ rdfs:comment rdfs:range rdfs:Literal .<br/>
+ rdfs:label rdfs:range rdfs:Literal .<br/>
+ rdf:value rdfs:range rdfs:Resource .<br/>
+ <br/>
+ rdf:Alt rdfs:subClassOf rdfs:Container .<br/>
+ rdf:Bag rdfs:subClassOf rdfs:Container .<br/>
+ rdf:Seq rdfs:subClassOf rdfs:Container .<br/>
+ rdfs:ContainerMembershipProperty rdfs:subClassOf rdf:Property .<br/>
+ <br/>
+ rdfs:isDefinedBy rdfs:subPropertyOf rdfs:seeAlso .<br/>
+ <br/>
- rdfs:Datatype rdfs:subClassOf rdfs:Class .<br>
- <br>
- rdf:_1 rdf:type rdfs:ContainerMembershipProperty .<br>
- <span>rdf:_1 rdfs:domain rdfs:Resource .<br>
- rdf:_1 rdfs:range rdfs:Resource .</span> <br>
- rdf:_2 rdf:type rdfs:ContainerMembershipProperty .<br>
- rdf:_2 rdfs:domain rdfs:Resource .<br>
- rdf:_2 rdfs:range rdfs:Resource . <br>
- </code>... <br> </td>
+ rdfs:Datatype rdfs:subClassOf rdfs:Class .<br/>
+ <br/>
+ rdf:_1 rdf:type rdfs:ContainerMembershipProperty .<br/>
+ <span >rdf:_1 rdfs:domain rdfs:Resource .<br/>
+ rdf:_1 rdfs:range rdfs:Resource .</span> <br/>
+ rdf:_2 rdf:type rdfs:ContainerMembershipProperty .<br/>
+ rdf:_2 rdfs:domain rdfs:Resource .<br/>
+ rdf:_2 rdfs:range rdfs:Resource . <br/>
+ </code>... <br/> </td>
</tr>
- </tbody></table>
-
-<ul><li><p class="changenote">In the 2004 RDF 1.0 semantics, LV was defined as part of a simple interpretation structure, and the definition given here was a constraint. </p>
-</li></ul>
+ </table>
-<p>Since I is an <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>, the first condition implies that IP
+<p class="changenote">In the 2004 RDF 1.0 semantics, LV was defined as part of a simple interpretation structure, and the definition given here was a constraint. </p>
+
+
+<p>Since I is an <a>RDF interpretation</a>, the first condition implies that IP
= ICEXT(I(<code>rdf:Property</code>)).</p>
- <p>The semantic conditions on rdf-D-interpretations, together with the RDFS conditions on ICEXT, mean that every recognized datatype can be treated as an RDFS class whose extension is the value space of the datatype, and every literal with that datatype either fails to refer (if the literal is ill-typed) or else refers to a value in that class.</p>
-<p>These axioms and conditions have some redundancy. For example, all but one
+ <p>The semantic conditions on <a>RDF interpretation</a>s, together with the RDFS conditions on ICEXT, mean that every <a>recognize</a>d datatype can be treated as a class whose extension is the value space of the datatype, and every literal with that datatype either fails to refer, or refers to a value in that class.</p>
+<p>When using RDFS semantics, the referents of all <a>recognize</a>d datatype IRIs can be considered to be in the <a>class</a> <code>rdfs:Datatype</code>. </p>
+<p>The axioms and conditions listed above have some redundancy. For example, all but one
of the RDF axiomatic triples can be derived from the RDFS axiomatic triples
- and the semantic conditions on ICEXT,<code> rdfs:domain</code> and <code>rdfs:range</code>.
- Other triples which must be true in all <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a>s
- include the following:</p>
+ and the semantic conditions on ICEXT,<code> rdfs:domain</code> and <code>rdfs:range</code>. </p>
+
+<p> Other triples which must be true in all rdfs-interpretations
+ include the following. This is not a complete set.</p>
<div class="tabletitle">Some rdfs-valid triples.</div>
-<table border="1">
- <tbody><tr>
- <td class="ruletable"><code>rdfs:Resource rdf:type rdfs:Class .<br>
- rdfs:Class rdf:type rdfs:Class .<br>
- rdfs:Literal rdf:type rdfs:Class .<br>
- rdf:XMLLiteral rdf:type rdfs:Class .<br>
-rdf:HTML rdf:type rdfs:Class .<br>
- rdfs:Datatype rdf:type rdfs:Class .<br>
- rdf:Seq rdf:type rdfs:Class .<br>
- rdf:Bag rdf:type rdfs:Class .<br>
- rdf:Alt rdf:type rdfs:Class .<br>
- rdfs:Container rdf:type rdfs:Class .<br>
- rdf:List rdf:type rdfs:Class .<br>
- rdfs:ContainerMembershipProperty rdf:type rdfs:Class .<br>
- rdf:Property rdf:type rdfs:Class .<br>
- rdf:Statement rdf:type rdfs:Class .<br>
- <br>
- rdfs:domain rdf:type rdf:Property .<br>
- rdfs:range rdf:type rdf:Property .<br>
- rdfs:subPropertyOf rdf:type rdf:Property .<br>
- rdfs:subClassOf rdf:type rdf:Property .<br>
- rdfs:member rdf:type rdf:Property .<br>
- rdfs:seeAlso rdf:type rdf:Property .<br>
- rdfs:isDefinedBy rdf:type rdf:Property .<br>
- rdfs:comment rdf:type rdf:Property .<br>
- rdfs:label rdf:type rdf:Property .<br>
+<table border="1">
+ <tr>
+ <td class="ruletable"><code>rdfs:Resource rdf:type rdfs:Class .<br/>
+ rdfs:Class rdf:type rdfs:Class .<br/>
+ rdfs:Literal rdf:type rdfs:Class .<br/>
+ rdf:XMLLiteral rdf:type rdfs:Class .<br/>
+rdf:HTML rdf:type rdfs:Class .<br/>
+ rdfs:Datatype rdf:type rdfs:Class .<br/>
+ rdf:Seq rdf:type rdfs:Class .<br/>
+ rdf:Bag rdf:type rdfs:Class .<br/>
+ rdf:Alt rdf:type rdfs:Class .<br/>
+ rdfs:Container rdf:type rdfs:Class .<br/>
+ rdf:List rdf:type rdfs:Class .<br/>
+ rdfs:ContainerMembershipProperty rdf:type rdfs:Class .<br/>
+ rdf:Property rdf:type rdfs:Class .<br/>
+ rdf:Statement rdf:type rdfs:Class .<br/>
+ <br/>
+ rdfs:domain rdf:type rdf:Property .<br/>
+ rdfs:range rdf:type rdf:Property .<br/>
+ rdfs:subPropertyOf rdf:type rdf:Property .<br/>
+ rdfs:subClassOf rdf:type rdf:Property .<br/>
+ rdfs:member rdf:type rdf:Property .<br/>
+ rdfs:seeAlso rdf:type rdf:Property .<br/>
+ rdfs:isDefinedBy rdf:type rdf:Property .<br/>
+ rdfs:comment rdf:type rdf:Property .<br/>
+ rdfs:label rdf:type rdf:Property .<br/>
</code><code></code></td>
</tr>
-</tbody></table>
+</table>
-<p>RDFS does not partition the universe into disjoint categories of classes, properties and individuals. Anything in the universe can be used as a class or as a property, or both, while retaining its status as an individual which may be in classes and have properties. Thus, RDFS permits classes which contain other classes, classes of properties, properties of classes, etc. . As the axiomatic triples above illustrate, it also permits classes which contain themselves and properties which apply to themselves. A property of a class is not necessarily a property of its members, nor vice versa. </p>
-
-<h2 id="rdfs_literal">A note on rdfs:Literal</h2>
-<p>The class <code>rdfs:Literal</code> is not the class of literals, but rather that of literal <em>values</em>. For example, LV does not contain the literal <code>"24"^^xsd:integer</code> (although it might contain the string '<code>"24"^^http://www.w3.org/2001/XMLSchema#integer</code>' ) but it does contain the number twenty-four.</p>
+<p>RDFS does not partition the universe into disjoint categories of classes, properties and individuals. Anything in the universe can be used as a class or as a property, or both, while retaining its status as an individual which may be in classes and have properties. Thus, RDFS permits classes which contain other classes, classes of properties, properties of classes, etc. As the axiomatic triples above illustrate, it also permits classes which contain themselves and properties which apply to themselves. A property of a class is not necessarily a property of its members, nor vice versa. </p>
+<section class="informative">
+<h4>A note on rdfs:Literal (Informative)</h3>
+<p>The class <code>rdfs:Literal</code> is not the class of literals, but rather that of literal values, which may also be referred to by IRIs. For example, LV does not contain the literal <code>"foodle"^^xsd:string</code> but it does contain the string "foodle".</p>
<p>A triple of the form</p>
- <p><code><ex:a> rdf:type rdfs:Literal .</code></p>
+ <p><code>ex:a rdf:type rdfs:Literal .</code></p>
<p>is consistent even though its subject is an IRI rather
than a literal. It says that the IRI '<code>ex:a</code>'
- refers to a literal value, which is quite possible since literal values are things in the universe. Similarly, blank nodes may range over literal values. </p>
+ refers to a literal value, which is quite possible since literal values are things in the universe. Blank nodes may range over literal values, for the same reason. </p>
+</section>
+<section>
-<h2 id="rdfs_entailment">RDFS Entailment</h2>
-<p>S <i>rdfs-D-entails</i> E when every <a href="#rdfsinterpdef" class="termref">rdfs-D-interpretation</a>
- which satisfies every member of S also satisfies E. RDFS entailment is rdfs-{<code>rdf:langString</code>, <code>xsd:string</code> }-entailment, i.e. rdfs-D-entailment with a minimal D. </p>
-<p> Since every <a href="#rdfsinterpdef" class="termref">rdfs-D-interpretation</a> is an <a href="#rdfinterpdef" class="termref">rdf-D-interpretation</a>, if S rdfs-D-entails
- E then S also rdf-D-entails E; but rdfs-entailment is stronger than rdf-entailment.
- Even the empty graph has a large number of rdfs-entailments which are not rdf-entailments,
+<h3 id="rdfs_entailment">RDFS entailment</h3>
+<p>S <dfn>RDFS entails</dfn> E <strong>recognizing D</strong> when every <a>RDFS interpretation</a> recognizing D
+ which satisfies S also satisfies E.</p>
+<p> Since every <a>RDFS interpretation</a> is an <a>RDF interpretation</a>, if S <a>RDFS entails</a>
+ E then S also <a>RDF entail</a>s E; but RDFS entailment is stronger than RDF entailment.
+ Even the empty graph has a large number of RDFS entailments which are not RDF entailments,
for example all triples of the form </p>
-<p> <code>aaa rdf:type rdfs:Resource .</code></p>
-<p>where aaa is an IRI, are true in all <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a>s.</p>
+<p> aaa <code>rdf:type rdfs:Resource .</code></p>
+<p>where aaa is an IRI, are true in all RDFS interpretations.</p>
+<section class="informative"> <h4 id="rdfs_patterns">Patterns of RDFS entailment (Informative)</h4>
+
+<P>RDFS entailment holds for all the following patterns, which correspond closely to the RDFS semantic conditions:</p>
+
+<div class="title">RDFS entailment patterns.</div>
+<table border="1" summary="RDFS-D entailment patterns">
+ <tbody>
+ <tr >
+ <th ></th>
+ <th >If S contains:</th>
+ <th >then S RDFS entails recognizing D:</th>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs1</dfn></td>
+ <td class="othertable">any IRI aaa in D</td>
+ <td class="othertable">aaa <code>rdf:type rdfs:Datatype . </code></td>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs2</dfn></td>
+ <td class="othertable"> aaa <code>rdfs:domain</code> xxx <code>.</code><br />
+ yyy aaa zzz <code>.</code></td>
+ <td class="othertable">yyy <code>rdf:type</code> xxx <code>.</code></td>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs3</dfn></td>
+ <td class="othertable">aaa <code>rdfs:range</code> xxx <code>.</code><br />
+ yyy aaa zzz <code>.</code></td>
+ <td class="othertable">zzz <code>rdf:type</code> xxx <code>.</code></td>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs4a</dfn></td>
+ <td class="othertable">xxx aaa yyy <code>.</code></td>
+ <td class="othertable">xxx <code>rdf:type rdfs:Resource .</code></td>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs4b</dfn></td>
+ <td class="othertable">xxx aaa yyy<code>.</code></td>
+ <td class="othertable">yyy <code>rdf:type rdfs:Resource .</code></td>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs5</dfn></td>
+ <td class="othertable"> xxx <code>rdfs:subPropertyOf</code> yyy <code>.</code><br />
+ yyy <code>rdfs:subPropertyOf</code> zzz <code>.</code></td>
+ <td class="othertable">xxx <code>rdfs:subPropertyOf</code> zzz <code>.</code></td>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs6</dfn></td>
+ <td class="othertable">xxx <code>rdf:type rdf:Property .</code></td>
+ <td class="othertable">xxx <code>rdfs:subPropertyOf</code> xxx <code>.</code></td>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs7</dfn></td>
+ <td class="othertable"> aaa <code>rdfs:subPropertyOf</code> bbb <code>.</code><br />
+ xxx aaa yyy <code>.</code></td>
+ <td class="othertable">xxx bbb yyy <code>.</code></td>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs8</dfn></td>
+ <td class="othertable">xxx <code>rdf:type rdfs:Class .</code></td>
+ <td class="othertable">xxx <code>rdfs:subClassOf rdfs:Resource .</code></td>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs9</dfn></td>
+ <td class="othertable">xxx <code>rdfs:subClassOf</code> yyy <code>.</code><br />
+ zzz <code>rdf:type</code> xxx <code>.</code></td>
+ <td class="othertable">zzz <code>rdf:type</code> yyy <code>.</code></td>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs10</dfn></td>
+ <td class="othertable">xxx <code>rdf:type rdfs:Class .</code></td>
+ <td class="othertable">xxx <code>rdfs:subClassOf</code> xxx <code>.</code></td>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs11</dfn></td>
+ <td class="othertable"> xxx <code>rdfs:subClassOf</code> yyy <code>.</code><br />
+ yyy <code>rdfs:subClassOf</code> zzz <code>.</code></td>
+ <td class="othertable">xxx <code>rdfs:subClassOf</code> zzz <code>.</code></td>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs12</dfn></td>
+ <td class="othertable">xxx <code>rdf:type rdfs:ContainerMembershipProperty .</code></td>
+ <td class="othertable">xxx <code>rdfs:subPropertyOf rdfs:member .</code></td>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>rdfs13</dfn></td>
+ <td class="othertable">xxx <code>rdf:type rdfs:Datatype .</code></td>
+ <td class="othertable">xxx <code>rdfs:subClassOf rdfs:Literal .</code></td>
+ </tr>
+ </tbody>
+</table>
+
+
+<p>RDFS provides for several new ways to be unsatisfiable recognizing D. For example, the following graph is RDFS unsatisfiable recognizing {<code>xsd:integer</code>, <code>xsd:boolean</code>}:</p>
+
+<p><code>ex:p rdfs:domain xsd:boolean .<br/>
+ex:a rdf:type xsd:integer .<br/>
+ex:a ex:p ex:c .</code></p>
+
+</section>
+</section>
+</section>
+<section><h2>RDF Datasets</h2>
+
+<p>An RDF <a href="http://www.w3.org/TR/rdf11-concepts/#section-dataset" class="externalDFN">dataset</a> (see [[!RDF11-CONCEPTS]]) is a finite set of RDF graphs each paired with an IRI or blank node called the <strong>graph name</strong>, plus a <strong>default graph</strong>, without a name. Graphs in a single dataset may share blank nodes. The association of graph name IRIs with graphs is used by SPARQL [[RDF-SPARQL-QUERY]] to allow queries to be directed against particular graphs.</p>
+
+<p>Graph names in a dataset may refer to something other than the graph they are paired with. This allows IRI referring to other kinds of entities, such as persons, to be used in a dataset to <a>identify</a> graphs of information relevant to the entity <a>denote</a>d by the graph name IRI.</p>
+
+<p>When a graph name is used inside RDF triples in a dataset it may or may not refer to the graph it names. The semantics does not require, nor should RDF engines presume, without some external reason to do so, that graph names used in RDF triples refer to the graph they name.</p>
+
+<p>RDF datasets MAY be used to express RDF content. When used in this way, a dataset SHOULD be understood to have at least the same content as its default graph. Note however that replacing the default graph of a dataset by a logically equivalent graph will not in general produce a structurally similar dataset, since it may for example disrupt co-occurrences of blank nodes between the default graph and other graphs in the dataset, which may be important for reasons other than the semantics of the graphs in the dataset.</p>
+
+<p>Other <a>semantic extension</a>s and <a>entailment regime</a>s MAY place further semantic conditions and restrictions on RDF datasets, just as with RDF graphs. One such extension, for example, could set up a modal-like interpretation structure so that entailment between datasets would require RDF graph entailments between the graphs with the same name (adding in empty graphs as required).</p>
+
+
+</section>
+
+<h2>Appendices</h2>
+
+<section class="appendix" class="informative"><h2 id="entailment_rules">Entailment rules (Informative)</h2>
+
+<p>(<em>This section is based on work described more fully in </em>[[HORST04]]<em>, </em>[[HORST05]]<em>, which should be consulted for technical details and proofs.</em>) </p>
+<p> The RDF and RDFS entailment patterns listed in the above tables can be viewed as left-to-right rules which add the entailed conclusion to a graph. These rule sets can be used to check RDF (or RDFS) entailment between graphs S and E, by the following sequence of operations:</p>
+<p>1. Add to S all the RDF (or RDF and RDFS) axiomatic triples except those containing the container membership property IRIs <code>rdf:_1, rdf:_2, ...</code>.<br/>
+2. For every container membership property IRI which occurs in E, add the RDF (or RDF and RDFS) axiomatic triples which contain that IRI.<br/>
+3. Apply the RDF (or RDF and RDFS) inference patterns as rules, adding each conclusion to the graph, to exhaustion; that is, until they generate no new triples. <br/>
+4. Determine if E has an instance which is a subset of the set, i.e. whether the enlarged set simply entails E.</p>
+
+This process is clearly <a>correct</a>, in that if it gives a positive result then indeed S does RDF (RDFS) entail E. It is not, however, <a>complete</a>: there are cases of S entailing E which are not detectable by this process. Examples include:</p>
+
+<table border="1" >
+ <tbody>
+ <tr>
+
+ <th > </th>
+ <th >RDF entails</th>
+ </tr>
+
+ <tr>
+
+ <td class="othertable"><code>ex:a ex:p "string"^^xsd:string .<br/>
+ex:b ex:q "string"^^xsd:string .</code></td>
+ <td class="othertable"><code>ex:a ex:p _:b .<br/>
+ex:b ex:q _:b .<br/>
+_:b rdf:type xsd:string .</code> </td>
+ </tr>
+
+ <tr>
+
+ <th > </th>
+ <th >RDFS entails</th>
+ </tr>
+<tr>
+
+ <td class="othertable"><code>ex:a rdfs:subPropertyOf _:b .<br/>
+_:b rdfs:domain ex:c .<br/>
+ex:d ex:a ex:e .</code></td>
+ <td class="othertable"><code>ex:d rdf:type ex:c .</code> </td>
+ </tr>
+
+ </tbody>
+</table>
+<p> Both of these can be handled by allowing the rules to apply to a generalization of the RDF syntax in which literals may occur in subject position and blank nodes may occur in predicate position. </p>
+
+<!--<p>Define a <dfn>generalized RDF triple</dfn> to be a triple <x, y, z> where x and z can be an IRI, a blank node or a literal, and y can be an IRI or a blank node; and extend this to the rest of RDF, so that a generalized RDF graph is a set of generalized RDF triples. -->
+<p>Consider <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#section-generalized-rdf">generalized RDF triples, graphs, and datasets</a> instead of RDF triples, graphs and datasets (extending the generalization used in [[HORST04]] and following exactly the terms used in [[OWL2-PROFILES]]). The semantics described in this document applies to the generalization without change, so that the notions of interpretation, satisfiability and entailment can be used freely. Then we can replace the first RDF entailment pattern with the simpler and more direct</p>
+
+<div class="tabletitle">G-RDF-D entailment pattern.</div>
+<table border="1" >
+ <tbody>
+ <tr>
+ <th > </th>
+ <th ><strong>if S contains</strong></th>
+ <th ><strong>then S RDF entails, recognizing D</strong></th>
+ </tr>
+ <tr >
+ <td class="othertable"><dfn>GrdfD1</dfn></td>
+ <td class="othertable"> xxx aaa <code>"</code>sss<code>"^^</code>ddd <code>.</code> <br/>
+ for ddd in D</td>
+ <td class="othertable"><code>"</code>sss<code>"^^</code>ddd <code>rdf:type</code> ddd <code>.</code></td>
+ </tr>
+
+ </tbody>
+</table>
+
+<p> which gives the entailments;</p>
+<P><code>ex:a ex:p "string"^^xsd:string .<br/>
+ex:b ex:q "string"^^xsd:string .<br/>
+"string"^^xsd:string rdf:type xsd:string .</code> by <a>GrdfD1</a></p>
+
+which is an instance (in generalized RDF) of the desired conclusion, above.</p>
+<p> The second example can be derived using the RDFS rules:</p>
+<p><code>ex:a rdfs:subPropertyOf _:b .<br/>
+_:b rdfs:domain ex:c .<br/>
+ex:d ex:a ex:e .<br/>
+ex:d _:b ex:c .</code> by <a>rdfs7</a><br/>
+<code>ex:d rdf:type ex:c .</code> by <a>rdfs2</a></p>
+
+<p>Where the entailment patterns have been applied to generalized RDF syntax but yield a final conclusion which is legal RDF. </p>
+
+<p>With the generalized syntax, these rules are complete for both RDF and RDFS entailment. Stated exactly:</p>
+<p>Let S and E be RDF graphs. Define the <dfn>generalized RDF (RDFS) closure</dfn> <strong>of S towards E</strong> to be the set obtained by the following procedure.</p>
+<p>1. Add to S all the RDF (and RDFS) axiomatic triples which do not contain any container membership property IRI.<br/>
+2. For each container membership property IRI which occurs in E, add the RDF (and RDFS) axiomatic triples which contain that IRI.<br/>
+3. If no triples were added in step 2., add the RDF (and RDFS) axiomatic triples which contain <code>rdf:_1</code>. <br/>
+4. Apply the rules <a>GrdfD1</a> and <a>rdfD2</a> (and the rules <a>rdfs1</a> through <a>rdfs13</a>), with D={<code>rdf:langString</code>, <code>xsd:string</code>), to the set in all possible ways, to exhaustion. </p>
+
+<p>Then we have the completeness result:</p>
+<p class="fact">If S is RDF (RDFS) consistent, then S RDF entails (RDFS entails) E just when the <a>generalized RDF (RDFS) closure</a> of S towards E simply entails E.</em> </p>
+
+<p>The closures are finite. The generation process is decidable and of polynomial complexity. Detecting simple entailment is NP-complete in general, but of low polynomial order when E contains no blank nodes. </p>
+
+<p>Every RDF(S) closure, even starting with the empty graph, will contain all RDF(S) tautologies which can be expressed using the vocabulary of the original graph plus the RDF and RDFS vocabularies. In practice there is little utility in re-deriving these, and a subset of the rules can be used to establish most entailments of practical interest. </p>
+
+<p>If it is important to stay within legal RDF syntax, rule <a>rdfD1</a> may be used instead of <a>GrdfD1</a>, and the introduced blank node can be used as a substitute for the literal in subsequent derivations. The resulting set of rules will not however be complete.</p>
+
+<p>As noted earlier, detecting datatype entailment for larger sets of datatype IRIs requires attention to idiosyncratic properties of the particular datatypes.</p>
+
+</section>
+
+<section class="appendix" class="informative"><h2 id="finite_interpretations">Finite interpretations (Informative)</h2>
+<p>To keep the exposition simple, the RDF semantics has been phrased in a way which requires interpretations to be larger than absolutely necessary. For example, all interpretations are required to interpret the whole IRI vocabulary, and the universes of all D-interpretations must contain all possible strings and therefore be infinite. This appendix sketches, without proof, how to re-state the semantics using smaller semantic structures, without changing any entailments. </p>
+
+<p>Basically, it is only necessary for an interpretation structure to interpret the <a>name</a>s actually used in the graphs whose entailment is being considered, and to consider interpretations whose universes are at most as big as the number of names and blank nodes in the graphs. More formally, we can define a <dfn>pre-interpretation</dfn> over a <a>vocabulary</a> V to be a structure I similar to a <a>simple interpretation</a> but with a mapping only from V to its universe IR. Then when determining whether G entails E, consider only pre-interpretations over the finite vocabulary of <a>name</a>s actually used in G union E. The universe of such a pre-interpretation can be restricted to the cardinality N+B+1, where N is the size of the vocabulary and B is the number of blank nodes in the graphs. Any such pre-interpretation may be extended to <a>simple interpretation</a>s, all of which which will give the same truth values for any triples in G or E. Satisfiability, entailment and so on can then be defined with respect to these finite pre-interpretations, and shown to be identical to the ideas defined in the body of the specification.</p>
+
+<p>When considering D-entailment, pre-interpretations may be kept finite by weakening the semantic conditions for datatyped literals so that IR need contain literal values only for literals which actually occur in G or E, and the size of the universe restricted to (N+B)×(D+1), where D is the number of recognized datatypes. (A tighter bound is possible.) For RDF entailment, only the finite part of the RDF vocabulary which includes those container membership properties which actually occur in the graphs need to be interpreted, and the second RDF semantic condition is weakened to apply only to values which are values of literals which actually occur in the vocabulary. For RDFS interpretations, again only that finite part of the infinite container membership property vocabulary which actually occurs in the graphs under consideration needs to be interpreted. In all these cases, a pre-interpretation of the vocabulary of a graph may be extended to a full interpretation of the appropriate type without changing the truth-values of any triples in the graphs.</p>
+
+<p>The whole semantics could be stated in terms of pre-interpretations, yielding the same entailments, and allowing finite RDF graphs to be interpreted in finite structures, if the <em>finite model property</em> is considered important.
+
+</section>
+
+
+<section class="appendix" class="informative"><h2 id="proofs">Proofs of some results (Informative)</h2>
+
+<p class="fact"> The <a>empty graph</a> is entailed by
+ any graph, and does not entail any graph except itself.
+<!-- <a href="#emptygraphlemmaprf" class="termref">[Proof]</a> -->
+</p>
+
+<p>The empty graph is true in all interpretations, so is entailed by any graph. If G contains a triple <a b c>, then any interpretation I with IEXT(I(b))={ } makes G false; so the empty graph does not entail G. QED.</p>
+
+<p class="fact"> A graph entails all its subgraphs.
+<!-- <a href="#subglemprf" class="termref">[Proof]</a> -->
+</p>
+<p>If I satisfies G then it satisfies every triple in G, hence every triple in any subset of G. QED.</p>
+
+<p class="fact"> A graph
+ is entailed by any of its <a>instance</a>s.
+<!-- <a href="#instlemprf" class="termref"> [Proof]</a> -->
+</p>
+<p>Suppose H is an instance of G with the instantiation mapping M, and that I satisfies H. For blank nodes n in G which are not in H define A(n)=I(M(n)); then I+A satisfies G, so I satisfies G. QED.</p>
+
+<p class="fact">Every graph is satisfiable.</p>
+<p>Consider the simple interpretation with universe {x}, IEXT(x)= <x,x > and I(aaa)=x for any IRI aaa. This interpretation satisfies every RDF graph. QED.</p>
+
+<p class="fact">
+ G simply entails a graph E if and only if a subgraph of G is an instance of E.
+</p>
+
+<p>If a subgraph E' of G is an instance of E then G entails E' which entails E, so G entails E. NOw suppose G entails E, and consider the <a>Herbrand interpretation</a> I of G defined as follows. IR contains the <a>name</a>s and blank nodes which occur in the graph, with I(n)=n for each <a>name</a> n; n is in IP and <a, b> in IEXT(n) just when the triple <a n b> is in the graph. (For IRIs which do not occur in the graph, assign them values in IR at random.) I satisfies every triple <s p o> in E; that is, for some mapping A from the blank nodes of E to the vocabulary of G, the triple <[I+A](s) I(p) [I+A](o)> occurs in G. But this is an instance of <s p o> under the instance mapping A; so an instance of E is a subgraph of G. QED.</p>
+
+<p class="fact">if E is lean and E' is a proper instance of E, then E does not entail E'.</p>
+<p>Suppose E entails E', then a subgraph of E is an instance of E', which is a proper instance of E; so a subgraph of E is a proper instance of E, so E is not lean. QED.</p>
+<p class="fact">If E contains an IRI which does not occur in S, then S does not entail E.</p>
+<p>IF S entails E then a subgraph of S is an instance of E, so every IRI in E must occur in that subgraph, so must occur in S. QED.</p>
+
+<p class="fact">For any graph H, if sk(G) entails H there there is a graph H' such that G entails H' and H=sk(H').</p>
+<p>The skolemization mapping sk substitutes a unique new IRI for each blank node, so it is 1:1, so has an inverse. Define ks to be the inverse mapping which replaces each skolem IRI by the blank node it replaced. Since sk(G) entails H, a subgraph of sk(G) is an instance of H, say A(H) for some instance mapping A on the blank nodes in H. Then ks(A(H)) is a subgraph of G; and ks(A(H))=A(ks(H)) since the domains of A and ks are disjoint. So ks(H) has an instance which is a subgraph of G, so is entailed by G; and H=sk(ks(H)). QED.</p>
+
+<p class="fact">For any graph H which does not contain any of the "new" IRIs introduced into sk(G), sk(G) simply entails H if and only if G simply entails H.</p>
+<p>Using the terminology in the previous proof: if H does not contain any skolem IRIs, then H=ks(H). So if sk(G) entails H then G entails ks(H)=H; and if G entails H then sk(G) entails G entails H, so sk(G) entails H. QED.</p>
</section>
-<section id="monotonicity-of-semantic-extensions"><!--OddPage--><h2 id="monotonicity"><span class="secno">11. </span>Monotonicity of semantic extensions </h2>
-<p>Given a set of RDF graphs, there are various ways in which one can 'add' information
- to it. Any of the graphs may have some triples added to it; the set of graphs
- may be extended by extra graphs; or the vocabulary of the graph may be interpreted
- relative to a stronger notion of
-entailment,
-<!-- <a href="#vocabulary_entail" class="termref">vocabulary entailment</a>, -->
- i.e. with a larger set
- of semantic conditions understood to be imposed on the interpretations. All
- of these can be thought of as an addition of information, and may make more
- entailments hold than held before the change. All of these additions are <a href="#glossMonotonic" class="termref"><em>monotonic</em></a>,
- in the sense that entailments which hold before the addition of information,
- also hold after it. We can sum up this in a single lemma:</p>
-<p><strong><a id="GeneralMonotonicityLemma"></a>General monotonicity lemma</strong>. Suppose
- that S, S' are sets of RDF graphs with every member of S a subset
- of some member of S'. Suppose that Y indicates a semantic extension
- of X, S X-entails E, and S and
- E satisfy any syntactic restrictions of Y. Then S' Y-entails E.</p>
-
-<p>In particular, if D' is a set of IRIs identifying datatypes, D a subset of D' and if S <a href="#D_entailment" class="termref"> D-entail</a>s
- E then S also D'-entails E. </p>
-
-</section>
-
-<section id="extensional-rdfs-semantic-conditions-informative" class="informative"><!--OddPage--><h2 id="extensional_rdfs"><span class="secno">12. </span>Extensional RDFS Semantic Conditions (Informative)</h2><p><em>This section is non-normative.</em></p>
-<div class="issue"><div class="issue-title"><span>Issue 6</span></div><p class="">Is this section useful, or is it more likely to be confusing? Editor is inclined to delete it. </p></div>
-<p>The semantics given above is deliberately chosen to be the weakest 'reasonable'
- interpretation of the RDFS vocabulary. Semantic extensions <em title="MAY" class="rfc2119">MAY</em>
- strengthen the range, domain, subclass and subproperty semantic conditions to
- the following '<a class="termref" href="#glossExtensional">extensional</a>'
- versions:</p>
- <div class="tabletitle">Extensional alternatives for some RDFS semantic conditions.</div>
-<table border="1">
- <tbody><tr>
- <td class="semantictable"> <p>< x,y > is in IEXT(I(<code>rdfs:subClassOf</code>))
- if and only if x and y are in IC and ICEXT(x) is a subset of ICEXT(y)</p></td>
- </tr>
- <tr>
- <td class="semantictable"> <p>< x,y > is in IEXT(I(<code>rdfs:subPropertyOf</code>))
- if and only if x and y are in IP and IEXT(x) is a subset of IEXT(y)</p></td>
- </tr>
- <tr>
- <td class="semantictable"> <p><x,y> is in IEXT(I(<code>rdfs:range</code>))
- if and only if (if < u,v > is in IEXT(x) then v is in ICEXT(y))</p></td>
- </tr>
- <tr>
- <td class="semantictable"> <p>< x,y > is in IEXT(I(<code>rdfs:domain</code>))
- if and only if (if <u,v> is in IEXT(x) then u is in ICEXT(y))</p></td>
- </tr>
-</tbody></table>
-<p>which would guarantee that the subproperty and subclass properties were transitive
- and reflexive, and would also have further consequences. </p>
-<ul><li><p class="technote">These stronger conditions would be trivially satisfied when properties are
- identified with property extensions, classes with class extensions, and <code>rdfs:SubClassOf</code>
- understood to mean subset, and hence would be satisfied by an <a href="#glossExtensional" class="termref">extensional</a> semantics
- for RDFS. In some ways the extensional versions provide a simpler semantics,
- but they require more complex inference rules. The <a href="#glossIntensional" class="termref">intensional</a> semantics described
- in the main text provides for most common uses of subclass and subproperty assertions,
- and allows for simpler implementations of a <a href="#glossComplete" class="termref">
- complete</a> set of RDFS entailment rules.
-<!-- , described in <a href="#RDFSRules" class="termref"> ////</a>. -->
-</p>
-</li></ul>
-
-</section>
-
-<section id="entailment-rules-informative" class="informative"><!--OddPage--><h2 id="entailment_rules"><span class="secno">13. </span>Entailment Rules (Informative)</h2><p><em>This section is non-normative.</em></p>
-<div class="issue"><div class="issue-title"><span>Issue 7</span></div><p class=""> The inference rules need to be rewritten using the convention that they apply to a syntactic generalization of RDF that allows literals in subject position. This will take some editorial work to complete but should be easier to understand once it is done. The hard work has already been done by terHorst. <br> <br> I do not plan to reproduce the completeness proofs which were in the RDF 2004 document. They were unreadable, intimidating, buggy and unnecessary. </p></div>
-</section>
+<section class="appendix" class="informative" id="whatnot"><h2 id="non_semantics">RDF reification, containers and collections (Informative)</h2>
-<section class="appendix" id="MTintro"><!--OddPage--><h2 id="model_theory"><span class="secno">A. </span>Introduction to model theory (Informative)</h2>
-///
-</section>
-<section id="proofs-of-lemmas-informative" class="appendix"><!--OddPage--><h2 id="proofs"><span class="secno">B. </span>Proofs of Lemmas (Informative)</h2>
-///interpolation lemma is now slightly less trivial to prove. Check for possible consequences of this.///
-</section>
-<section class="appendix" id="whatnot"><!--OddPage--><h2 id="non_semantics"><span class="secno">C. </span>What the semantics does not do (Informative)</h2>
-
-<div class="issue"><div class="issue-title"><span>Issue 8</span></div><p class="">Something in here about datasets having no specified semantics, and why. Why using a graph name need not refer to the graph.</p></div>
-<h2 id="rdf_vocabulary">The RDF vocabulary</h2>
<p>The RDF semantic conditions do not place formal constraints on the meaning
of much of the RDF vocabulary which is intended for use in describing containers and bounded collections,
- or the reification vocabulary intended to enable an RDF graph to describe RDF triples. In this appendix we briefly review the intended meanings of this vocabulary. </p>
+ or the reification vocabulary intended to enable an RDF graph to describe RDF triples. This appendix briefly reviews the intended meanings of this vocabulary. </p>
<p>The omission of these conditions from the formal semantics is a design decision
to accommodate variations in existing RDF usage and to make it easier to implement
processes to check formal RDF entailment. For example, implementations may decide
to use special procedural techniques to implement the RDF collection vocabulary.</p>
+
+<section>
-<h2 id="reification"><a id="Reif">Reification</a></h2>
+<h3><a id="Reif">Reification</a></h3>
<div class="c1">
- <table border="1">
+ <table border="1">
<tbody>
<tr>
<td class="othertable"><strong>RDF reification vocabulary</strong></td>
@@ -1118,16 +1272,16 @@
<p>Consider an example graph containing a single triple:</p>
- <p><code><ex:a> <ex:b> <ex:c> .</code></p>
-
- <p>and suppose that this graph is identified by the IRI <code>ex:graph1</code>. Exactly how this identification is achieved is external to the RDF model, but it might be by the IRI resolving to a concrete syntax document describing the graph, or by the IRI being the associated name of a named graph in a dataset. Assuming that the IRI can be used to refer to the triple, then the reification vocabulary allows us to describe the first graph in another graph:</p>
+ <p><code>ex:a ex:b ex:c .</code></p>
- <p><code><ex:graph1> rdf:type rdf:Statement .<br>
- <ex:graph1> rdf:subject <ex:a> .<br>
- <ex:graph1> rdf:predicate <ex:b> .<br>
- <ex:graph1> rdf:object <ex:c> .</code></p>
+ <p>and suppose that IRI <code>ex:graph1</code> is used to <a>identify</a> this graph. Exactly how this identification is achieved is external to the RDF model, but it might be by the IRI resolving to a concrete syntax document describing the graph, or by the IRI being the associated name of a named graph in a dataset. Assuming that the IRI can be used to refer to the triple, then the reification vocabulary allows us to describe the first graph in another graph:</p>
- <p>The second graph is called a <i><a href="#glossReify" class="termref"><em>reification</em></a></i> of the triple in the first
+ <p><code>ex:graph1 rdf:type rdf:Statement .<br/>
+ ex:graph1 rdf:subject ex:a .<br/>
+ ex:graph1 rdf:predicate ex:b .<br/>
+ ex:graph1 rdf:object ex:c .</code></p>
+
+ <p>The second graph is called a <dfn>reification</dfn> of the triple in the first
graph.</p>
<p> Reification is not a form of quotation. Rather, the reification describes the
relationship between a token of a triple and the resources that the triple refers
@@ -1136,45 +1290,47 @@
</p>
-<p>Reifications can be written with a blank node as subject, or with an IRI subject which does not identify any concrete realization of a triple, in which case they assert the existence of the described triple. </p>
+<p><a>Reification</a>s can be written with a blank node as subject, or with an IRI subject which does not <a>identify</a> any concrete realization of a triple, in both of which cases they simply assert the existence of the described triple. </p>
- <p>The subject of a reification is intended to refer to a concrete realization of an RDF triple, such as a document in a surface syntax, rather than a triple considered as an abstract object. This supports use cases where properties such as dates of
+ <p>The subject of a <a>reification</a> is intended to refer to a concrete realization of an RDF triple, such as a document in a surface syntax, rather than a triple considered as an abstract object. This supports use cases where properties such as dates of
composition or provenance information are applied to the
reified triple, which are meaningful only when thought of as
referring to a particular instance or token of a triple. </p>
- <p>A reification of a triple does not entail the triple, and is not
+ <p>A <a>reification</a> of a triple does not entail the triple, and is not
entailed by it. The
- reification only says that the triple token exists and what it is about,
+ <a>reification</a> only says that the triple token exists and what it is about,
not that it is true, so it does not entail the triple. On the other hand, asserting a triple does not automatically imply that any
triple tokens exist in the universe being described by the triple.
For example, the triple might be part of an ontology describing
animals, which could be satisfied by an interpretation in which the
- universe contained only animals, and in which a reification of it was therefore
+ universe contained only animals, and in which a <a>reification</a> of it was therefore
false.</p>
- <p>Since the relation between triples and reifications of triples
+ <p>Since the relation between triples and <a>reification</a>s of triples
in any RDF graph or graphs need not be one-to-one, asserting a
- property about some entity described by a reification need not
+ property about some entity described by a <a>reification</a> need not
entail that the same property holds of another such entity, even if
it has the same components. For example,</p>
- <p><code>_:xxx rdf:type rdf:Statement .<br>
- _:xxx rdf:subject <ex:subject> .<br>
- _:xxx rdf:predicate <ex:predicate> .<br>
- _:xxx rdf:object <ex:object> .<br>
- _:yyy rdf:type rdf:Statement .<br>
- _:yyy rdf:subject <ex:subject> .<br>
- _:yyy rdf:predicate <ex:predicate> .<br>
- _:yyy rdf:object <ex:object> .<br>
- _:xxx <ex:property> <ex:foo> .</code></p>
+ <p><code>_:xxx rdf:type rdf:Statement .<br/>
+ _:xxx rdf:subject ex:subject .<br/>
+ _:xxx rdf:predicate ex:predicate .<br/>
+ _:xxx rdf:object ex:object .<br/>
+ _:yyy rdf:type rdf:Statement .<br/>
+ _:yyy rdf:subject ex:subject .<br/>
+ _:yyy rdf:predicate ex:predicate .<br/>
+ _:yyy rdf:object ex:object .<br/>
+ _:xxx ex:property ex:foo .</code></p>
<p>does not entail</p>
- <p><code>_:yyy <ex:property> <ex:foo> .</code></p>
+ <p><code>_:yyy ex:property ex:foo .</code></p>
+</section>
+<section>
-<h2 id="containers">RDF containers</h2>
+<h4 id="containers">RDF containers</h4>
<table border="1">
<tbody>
@@ -1195,20 +1351,19 @@
indices should not necessarily be thought of as defining an
ordering of the container itself; some containers are considered to be unordered.</p>
- <p>The RDFS vocabulary, described below, adds a generic membership
+ <p>The <a>RDFS vocabulary</a> adds a generic membership
property which holds regardless of position, and classes containing
all the containers and all the membership properties.</p>
- <p>One should understand this RDF vocabulary as <em>describing</em>
- containers, rather than as a vocabulary for constructing them, as
- would typically be supplied by a programming language. On this
- view, the actual containers are entities in the semantic universe,
+ <p>One should understand this vocabulary as <em>describing</em>
+ containers, rather than as a tool for constructing them, as
+ would typically be supplied by a programming language. The actual containers are entities in the semantic universe,
and RDF graphs which use the vocabulary simply provide very basic
information about these entities, enabling an RDF graph to
characterize the container type and give partial information about
the members of a container. Since the RDF container vocabulary is
so limited, many 'natural' assumptions concerning RDF containers
- are not formally sanctioned by the RDF <a href="#glossModeltheory" class="termref">model theory</a>. This should not be taken as
+ cannot be formally sanctioned by the RDF formal semantics. This should not be taken as
meaning that these assumptions are false, but only that RDF does
not formally entail that they must be true.</p>
@@ -1223,55 +1378,57 @@
type <code>rdf:Seq</code> are considered to be ordered, and things
of type <code>rdf:Alt</code> are considered to represent a
collection of alternatives, possibly with a preference ordering.
- The ordering of items in an ordered container is intended to be
+ If the container is of an ordered type, then the ordering of items in the container is intended to be
indicated by the numerical ordering of the container membership
properties, which are assumed to be single-valued.
However, these informal interpretations are not reflected in any formal RDF
entailments.</p>
-<p>RDF does not support any entailments which could arise from enumerating
- the elements of an <code>rdf:Bag</code> in a different order. For example,</p>
+<p>The RDF semantics does not support any entailments which could arise from enumerating
+ the elements of an unordered <code>rdf:Bag</code> in a different order. For example,</p>
- <p><code>_:xxx rdf:type rdf:Bag .<br>
- _:xxx rdf:_1 <ex:a> .<br>
- _:xxx rdf:_2 <ex:b> .</code></p>
+ <p><code>_:xxx rdf:type rdf:Bag .<br/>
+ _:xxx rdf:_1 ex:a .<br/>
+ _:xxx rdf:_2 ex:b .</code></p>
<p>does not entail</p>
- <p><code>_:xxx rdf:_1 <ex:b> .<br>
- _:xxx rdf:_2 <ex:a> .</code></p>
+ <p><code>_:xxx rdf:_1 ex:b .<br/>
+ _:xxx rdf:_2 ex:a .</code></p>
- <p>Notice that if this conclusion were <a class="internalDFN" href="#dfn-valid">valid</a>, then the result of
- conjoining it to the original graph would be <a>entailed</a> by the graph, and this would assert that both elements were in both
+ <p>(If this conclusion were <a>valid</a>, then the result of
+ adding it to the original graph would be <a>entailed</a> by the graph, and this would assert that both elements were in both
positions. This is a consequence of the fact that RDF is a purely
- assertional language.</p>
+ assertional language.)</p>
<p>There is no assumption that a property of a container applies to
any of the elements of the container, or vice versa. </p>
<p>There is no formal requirement that
the three container classes are disjoint, so that for example
- it is not a <a>contradiction</a> to assert that something is both an <code>rdf:Bag</code> and an <code>rdf:Seq</code>.
+ it is consistent to assert that something is both an <code>rdf:Bag</code> and an <code>rdf:Seq</code>.
There is no assumption that containers are gap-free, so that for example</p>
- <p><code>_:xxx rdf:type rdf:Seq.<br>
- _:xxx rdf:_1 <ex:a> .<br>
- _:xxx rdf:_3 <ex:c> .</code></p>
+ <p><code>_:xxx rdf:type rdf:Seq.<br/>
+ _:xxx rdf:_1 ex:a .<br/>
+ _:xxx rdf:_3 ex:c .</code></p>
<p>does not entail</p>
<p><code>_:xxx rdf:_2 _:yyy .</code></p>
- <p>There is no way in RDF to 'close' a container, i.e. to assert
- that it contains only a fixed number of members. This is a
+ <p>There is no way in RDF to assert
+ that a container contains only a fixed number of members. This is a
reflection of the fact that it is always consistent to add a triple
to a graph asserting a membership property of any container. And
finally, there is no built-in assumption that an RDF container has
only finitely many members.</p>
+</section>
+<section>
-<h2 id="collections">RDF collections</h2>
+<h4 id="collections">RDF collections</h4>
- <table border="1">
+ <table border="1">
<tbody>
<tr>
<td class="othertable"><strong>RDF Collection Vocabulary</strong></td>
@@ -1293,10 +1450,10 @@
is intended for use typically in a context where a container is described using
blank nodes to connect a 'well-formed' sequence of items, each described by
two triples of the form
-<code><br>
- <br>
- _:c1 rdf:first aaa .<br>
- _:c1 rdf:rest _:c2</code></p>
+<code><br/>
+ <br/>
+ _:c1 rdf:first aaa .<br/>
+ _:c1 rdf:rest _:c2 .</code></p>
<p>where the final item is indicated by the use of <code>rdf:nil</code> as the
@@ -1309,16 +1466,16 @@
For example, the existence of a collection containing two items does not automatically
guarantee that the similar collection with the items permuted also exists:
<code>
-<br><br>
- _:c1 rdf:first <ex:aaa> .<br>
- _:c1 rdf:rest _:c2 .<br>
- <span> _:c2 rdf:first</span> <ex:bbb> .<br>
+<br/><br/>
+ _:c1 rdf:first ex:aaa .<br/>
+ _:c1 rdf:rest _:c2 .<br/>
+ _:c2 rdf:first ex:bbb .<br/>
_:c2 rdf:rest rdf:nil . </code></p>
<p>does not entail</p>
-<p><code>_:c3 rdf:first <ex:bbb> .<br>
- _:c3 rdf:rest _:c4 .<br>
- <span>_:c4 rdf:first</span> <ex:aaa> .<br>
+<p><code>_:c3 rdf:first ex:bbb .<br/>
+ _:c3 rdf:rest _:c4 .<br/>
+ <span >_:c4 rdf:first</span> ex:aaa .<br/>
_:c4 rdf:rest rdf:nil .
</code></p>
@@ -1327,19 +1484,19 @@
the existence of highly peculiar objects such as lists with forked
or non-list tails, or multiple heads:</p>
-<p><code>_:666 rdf:first <ex:aaa> .<br>
- _:666 rdf:first <ex:bbb> .<br>
- _:666 rdf:rest <ex:ccc> .<br>
+<p><code>_:666 rdf:first ex:aaa .<br/>
+ _:666 rdf:first ex:bbb .<br/>
+ _:666 rdf:rest ex:ccc .<br/>
_:666 rdf:rest rdf:nil . </code></p>
-<p>It is also possible to write a set of triples which underspecify a collection
+<p>It is also possible to write a set of triples which under-specify a collection
by failing to specify its <code>rdf:rest</code> property value.</p>
-<p>Semantic extensions <em title="MAY" class="rfc2119">MAY</em>
+<p><a>Semantic extension</a>s may
place extra syntactic well-formedness restrictions on the use of this vocabulary
- in order to rule out such graphs. They <em title="MAY" class="rfc2119">MAY</em>
+ in order to rule out such graphs. They may
exclude interpretations of the collection vocabulary which violate the convention
that the subject of a 'linked' collection of two-triple items of the form described
above, ending with an item ending with <code>rdf:nil</code>, denotes a totally
@@ -1350,312 +1507,25 @@
<p> The RDFS semantic conditions require that any
subject of the <code>rdf:first</code> property, and any subject or object of
the <code>rdf:rest</code> property, be of <code>rdf:type rdf:List</code>. </p>
-
-
-<h3 id="rdf-value"><a id="rdfValue"></a>rdf:value</h3>
-<p>The intended use for <code>rdf:value</code> is <a href="http://www.w3.org/TR/rdf-primer/#rdfvalue">explained
- intuitively</a> in the RDF Primer
- document [<cite><a href="#bib-RDF-PRIMER" class="bibref">RDF-PRIMER</a></cite>]. 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.</p>
-<p>Since the range of possible uses for <code>rdf:value</code> 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 <code>rdf:value</code> may vary from application to application.
- Even when the intended meaning is clear from the context in the original graph document, it may be
- lost when graphs are merged or when conclusions are inferred.</p>
-
</section>
-<section class="appendix" id="glossary"><!--OddPage--><h2><span class="secno">D. </span>Glossary of Terms (Informative)</h2>
- <p><strong><a id="glossAntecedent"></a>Antecedent</strong> (n.) In an <a href="#glossInference" class="termref">inference</a>, the
- expression(s) from which the <a href="#glossConsequent" class="termref">conclusion</a> is derived. In an <a href="#glossEntail" class="termref">entailment</a> relation, the
- entailer. Also <em>assumption</em>.</p>
-
- <p><strong><a id="glossAssertion"></a>Assertion</strong> (n.) (i) Any expression
- which is claimed to be true. (ii) The act of claiming something to
- be true.</p>
-
- <p><strong><a id="glossClass"></a>Class</strong>
- (n.) A general concept, category or classification. Something<a href="#glossResource" class="termref"></a> used primarily to
- classify or categorize other things. Formally, in RDF, a <a href="#glossResource" class="termref">resource</a> of type
- <code>rdfs:Class</code> with an associated set of <a href="#glossResource" class="termref">resources</a> all of which
- have the class as a value of the <code>rdf:type</code> property.
- Classes are often called 'predicates' in the formal logical
- literature.</p>
-
- <p>(RDF distinguishes <em>class</em> from <em>set</em>, although the two are often
- identified. Distinguishing classes from sets allows RDF more
- freedom in constructing class hierarchies.</p>
-<p><strong><a id="glossComplete"></a>Complete</strong> (adj., of an inference system). (1)
- Able to detect all <a href="#glossEntail" class="termref">entailment</a>s between any two expressions.
- (2) Able to draw all <a href="#glossValid" class="termref">valid</a> inferences. See <a href="#glossInference" class="termref"><em>Inference</em></a>. Also used with a qualifier: able to
- detect entailments or draw all <a href="#glossValid" class="termref">valid</a> inferences in a certain limited form or kind (e.g.
- between expressions in a certain normal form, or meeting certain syntactic conditions.)</p>
-<p>(These definitions are not exactly equivalent, since the first requires that
- the system has access to the consequent of the entailment, and may be unable
- to draw 'trivial' inferences such as (p and p) from p. Typically, efficient
- mechanical inference systems may be complete in the first sense but not necessarily
- in the second.) </p>
-
- <p><strong><a id="glossConsequent"></a>Consequent</strong> (n.) In an inference,
- the expression constructed from the <a href="#glossAntecedent" class="termref">antecedent</a>. In an entailment relation, the
- entailee. Also <em>conclusion</em>.</p>
-<p><strong><a id="glossConsistent"></a>Consistent</strong> (adj., of an expression) Having
- a satisfying <a href="#glossInterpretation" class="termref">interpretation</a>; not internally contradictory. (Also used
- of an inference system as synonym for <em>Correct</em>.) </p>
-<p><strong><a id="glossCorrect"></a>Correct</strong> (adj., of an inference system). Unable
- to draw any invalid inferences, or unable to make false claims of entailment. See <em>Inference</em>.</p>
-<p><strong><a id="glossDecidable"></a>Decidable</strong>
- (adj., of an inference system). Able to determine for any pair of expressions,
- in a finite time with finite resources, whether or not the first entails the
- second. (Also: adj., of a logic:) Having a decidable inference system which
- is complete and correct for the semantics of the logic.</p>
-<p>(Not all logics can have inference systems which are both complete and decidable,
- and decidable inference systems may have arbitrarily high computational complexity.
- The relationships between logical syntax, semantics and complexity of an inference
- system continue to be the subject of considerable research.)</p>
-
- <p><strong><a id="glossEntail"></a>Entail</strong> (v.),
- <strong>entailment</strong> (n.). A semantic relationship between
- expressions which holds whenever the truth of the first guarantees
- the truth of the second. Equivalently, whenever it is logically
- impossible for the first expression to be true and the second one
- false. Equivalently, when any <a href="#glossInterpretation" class="termref">interpretation</a> which <a href="#glossSatisfy" class="termref">satisfies</a> the first also satisfies the second.
- (Also used between a set of expressions and an expression.)</p>
-
- <p><strong><a id="glossEquivalent"></a>Equivalent</strong> (prep., with
- <em>to</em>) True under exactly the same conditions; making
- identical claims about the world, when asserted. <a href="#glossEntail" class="termref">Entails</a> and is entailed
- by.</p>
-
- <p><strong><a id="glossExtensional"></a>Extensional</strong> (adj., of a logic) A
- set-based theory or logic of classes, in which classes are
- considered to be sets, properties considered to be sets of
- <object, value> pairs, and so on. A theory which admits no
- distinction between entities with the same extension. See <a href="#glossIntensional" class="termref"><em>Intensional</em></a>.</p>
-
- <p><strong><a id="glossFormal"></a>Formal</strong> (adj.) Couched in language
- sufficiently precise as to enable results to be established using
- conventional mathematical techniques.</p>
-
- <p><strong><a id="glossIff"></a>Iff</strong>
- (conj.) Conventional abbreviation for 'if and only if'. Used to
- express necessary and sufficient conditions.</p>
-<p><a id="glossInconsistent"></a><strong>Inconsistent</strong> (adj.) False under
- all interpretations; impossible to <a href="#glossSatisfy" class="termref">satisfy</a>. <strong>Inconsistency</strong>
- (n.), any inconsistent expression or graph.</p>
-<p>(<a href="#glossEntail" class="termref">Entailment</a> and inconsistency are closely
- related, since A entails B just when (A and not-B) is inconsistent, c.f. the
- second definition for <a href="#glossEntail" class="termref">entailment</a>. This is the basis of many
- mechanical inference systems. </p>
-<p>Although the definitions of <a href="#glossConsistent" class="termref">consistency</a>
- and inconsistency are exact duals, they are computationally dissimilar. It is
- often harder to detect consistency in all cases than to detect inconsistency
- in all cases<a href="#glossEntail" class="termref"></a>.)</p>
-<p><strong><a id="glossIndexical"></a>Indexical</strong> (adj., of an expression) having
- a meaning which implicitly refers to the context of use. Examples from English
- include words like 'here', 'now', 'this'.</p>
-<p><strong><a id="glossInference"></a>Infer</strong><strong>ence</strong> (n.) An act or
- process of constructing new expressions from existing expressions, or the result
- of such an act or process. Inferences corresponding to <a href="#glossEntail" class="termref">entailments</a> are described as <em>correct</em> or <em>valid</em>.
- <strong>Inference rule</strong>, formal description of a type of inference;
- <strong>inference system</strong>, organized system of inference rules; also,
- software which generates inferences or checks inferences for validity.</p>
-
- <p><strong><a id="glossIntensional"></a>Intensional</strong> (adj., of a logic)
- Not <a href="#glossExtensional" class="termref">extensional</a>. A
- logic which allows distinct entities with the same extension.</p>
-
-
-<p>(The merits and demerits of intensionality have been extensively debated in
- the philosophical logic literature. Extensional semantic theories are simpler,
- and conventional semantics for formal logics usually assume an extensional view,
- but conceptual analysis of ordinary language often suggests that intensional
- thinking is more natural. Examples often cited are that an extensional logic
- is obliged to treat all 'empty' extensions as identical, so must identify 'round
- square' with 'santa clause', and is unable to distinguish concepts that 'accidentally'
- have the same instances, such as human beings and bipedal hominids without body
- hair. The semantics described in this document is basically intensional.)</p>
-
- <p><strong><a id="glossInterpretation"></a>Interpretation</strong>
- (<strong>of</strong>) (n.) A minimal formal description of those
- aspects of a <a href="#glossWorld" class="termref">world</a> which
- is just sufficient to establish the truth or falsity of any
- expression of a logic.</p>
-
- <p>(Some logic texts distinguish between an <em>interpretation
- structure</em>, which is a 'possible world' considered as something
- independent of any particular vocabulary, and an <em>interpretation
- mapping</em> from a vocabulary into the structure. The RDF
- semantics takes the simpler route of merging these into a single
- concept.)</p>
-
- <p><strong><a id="glossLogic"></a>Logic</strong>
- (n.) A formal language which expresses <a href="#glossProposition" class="termref">propositions</a>.</p>
-
- <p><a id="glossMetaphysical"></a><strong>Metaphysical</strong> (adj.).
- Concerned with the true nature of things in some absolute or
- fundamental sense.</p>
-
- <p><a id="glossModeltheory"></a><strong>Model Theory</strong> (n.) A
- formal semantic theory which relates expressions to
- interpretations.</p>
-
- <p>(The name 'model theory' arises from the usage, traditional in
- logical semantics, in which a satisfying interpretation is called a
- "model". This usage is often found confusing, however, as it is
- almost exactly the inverse of the meaning implied by terms like
- "computational modelling", so has been avoided in this
- document.)</p>
-
- <p><strong><a id="glossMonotonic"></a>Monotonic</strong> (adj., of a logic or
- inference system) Satisfying the condition that if S entails E then
- (S + T) entails E, i.e. adding information to some antecedents
- cannot invalidate a <a href="#glossValid" class="termref">valid</a> entailment.</p>
-
- <p>(All logics based on a conventional <a href="#glossModeltheory" class="termref">model theory</a> and a standard notion of
- entailment are monotonic. Monotonic logics have the property that
- entailments remain <a href="#glossValid" class="termref">valid</a> outside of the context in which they were
- generated. This is why RDF is designed to be monotonic.)</p>
-
- <p><strong><a id="glossNonmonotonic"></a>Nonmonotonic</strong> (adj.,of a logic
- or inference system) Not <a href="#glossMonotonic" class="termref">monotonic</a>. Non-monotonic formalisms have been
- proposed and used in AI and various applications. Examples of
- nonmonotonic inferences include <em>default reasoning</em>, where
- one assumes a 'normal' general truth unless it is contradicted by
- more particular information (birds normally fly, but penguins
- don't fly); <em>negation-by-failure</em>, commonly assumed in logic
- programming systems, where one concludes, from a failure to prove a
- proposition, that the proposition is false; and <em>implicit
- closed-world assumptions</em>, often assumed in database
- applications, where one concludes from a lack of information about
- an entity in some corpus that the information is false (e.g. that
- if someone is not listed in an employee database, that he or she is not
- an employee.)</p>
-
- <p>(The relationship between monotonic and nonmonotonic inferences
- is often subtle. For example, if a closed-world assumption is made
- explicit, e.g. by asserting explicitly that the corpus is complete
- and providing explicit provenance information in the conclusion,
- then closed-world reasoning is monotonic; it is the implicitness
- that makes the reasoning nonmonotonic. Nonmonotonic conclusions can
- be said to be <a href="#glossValid" class="termref">valid</a> only in some kind of 'context', and are liable
- to be incorrect or misleading when used outside that context.
- Making the context explicit in the reasoning and visible in the
- conclusion is a way to map them into a monotonic framework.)</p>
-
- <p><strong><a id="glossOntological"></a>Ontological</strong> (adj.) (Philosophy)
- Concerned with what kinds of things really exist. (Applied)
- Concerned with the details of a formal description of some topic or
- domain.</p>
-
- <p><strong><a id="glossProposition"></a>Proposition</strong> (n.) Something that
- has a truth-value; a statement or expression that is true or
- false.</p>
-
- <p>(Philosophical analyses of language traditionally distinguish
- propositions from the expressions which are used to state them, but
- model theory does not require this distinction.)</p>
-
- <p><strong><a id="glossReify"></a>Reify</strong>
- (v.), <strong>reification</strong> (n.) To categorize as an object;
- to describe as an entity. Often used to describe a convention
- whereby a syntactic expression is treated as a semantic object and
- itself described using another syntax. In RDF, a reified triple is
- a description of a triple-token using other RDF triples.</p>
-
- <p><strong><a id="glossResource"></a>Resource</strong> (n.)(as used in RDF)(i) An
- entity; anything in the universe. (ii) As a class name: the class
- of everything; the most inclusive category possible.</p>
-
- <p><strong><a id="glossSatisfy"></a>Satisfy</strong> (v.t.),
- <strong>satisfaction</strong>,(n.) <strong>satisfying</strong>
- (adj., of an interpretation). To make true. The basic semantic
- relationship between an interpretation and an expression. X
- satisfies Y means that if <a href="#glossWorld" class="termref">the
- world</a> conforms to the conditions described by X, then Y must be
- true.</p>
-
- <p><strong><a id="glossSemantic"></a>Semantic</strong> (adj.) ,
- <strong>semantics</strong> (n.). Concerned with the specification
- of meanings. Often contrasted with <em>syntactic</em> to emphasize
- the distinction between expressions and what they denote.</p>
-
- <p><a id="glossSkolemization"></a>
-<!-- <a href="#skolemlemprf"> -->
-<strong>Skolemization</strong> (n.) A
- syntactic transformation in which blank nodes are replaced by 'new'
- names.</p>
-
- <p>(Although not strictly <a href="#glossValid" class="termref">valid</a>, Skolemization retains the
- essential meaning of an expression and is often used in mechanical
- inference systems. The full logical form is more complex. It is
- named after the logician <a href="http://www-gap.dcs.st-and.ac.uk/~history/Mathematicians/Skolem.html">
- A. T. Skolem</a>)</p>
-
- <p><a id="glossToken"></a><strong>Token</strong>
- (n.) A particular physical inscription of a symbol or expression in
- a document. Usually contrasted with <em>type</em>, the abstract
- grammatical form of an expression.</p>
-
- <p><strong><a id="glossUniverse"></a>Universe</strong> (n., also <em>Universe of
- discourse</em>) The universal classification, or the set of all
- things that an interpretation considers to exist. In RDF/S, this is
- identical to the set of resources.</p>
-
- <p><strong><a id="glossUse"></a>Use</strong> (v.)
- contrasted with <em>mention</em>; to use a piece of syntax to
- denote or refer to something else. The normal way that language is
- used.</p>
-
- <p>("Whenever, in a sentence, we wish to say something about a
- certain thing, we have to use, in this sentence, not the thing
- itself but its name or designation." - <a href="http://www.philosophypages.com/dy/t.htm">Alfred
- Tarski</a>)</p>
-
- <p><strong><a id="glossValid"></a>Valid</strong>
- (adj., of an inference or inference process) Corresponding to an <a href="#glossEntail" class="termref">entailment</a>, i.e. the
- conclusion of the inference is entailed by the antecedent of the
- inference. Also <em>correct</em>.</p>
-
- <p><dfn id="dfn-well-formed">Well-formed</dfn> (adj., of an
- expression). Syntactically legal.</p>
-
- <p><strong><a id="glossWorld"></a>World</strong>
- (n.) (with <em>the:</em>) (i) The actual world. (with
- <em>a:</em>) (ii) A way that the actual world might be arranged.
- (iii) An <a href="#glossInterpretation" class="termref">interpretation</a> (iv) A possible world.</p>
-
-
-<p>(The metaphysical status of '<a href="http://plato.stanford.edu/entries/actualism/possible-worlds.html">possible
- worlds</a>' is highly controversial. Fortunately, one does not need to commit
- oneself to a belief in parallel universes in order to use the concept in its
- second and third senses, which are sufficient for semantic purposes.)</p>
-
</section>
- <section id="acknowledgements" class="appendix">
- <!--OddPage--><h2 id="acknolwedgements"><span class="secno">E. </span>Acknowledgements</h2>
-<p>The basic idea of using an explicit extension mapping to allow
- self-application without violating the axiom of foundation was
- suggested by Christopher Menzel.</p>
-<p>///Herman ter Horst for rule style, Li Ding for complete graphs, Antoine for no-vocabulary and general input. Others?///</p>
- <p>
- Many thanks to Robin Berjon for making our lives so much easier with his cool tool. You betcha.
- </p>
+
+ <section class='appendix' class="informative">
+ <h2 id="acknowledgements">Acknowledgements</h2>
+
+<p>The basic idea of using an explicit extension mapping to allow self-application without violating the axiom of foundation was
+suggested by Christopher Menzel. The generalized RDF syntax used in Appendix A, and the example showing the need for it, were suggested by Herman ter Horst, who also proved completeness and complexity results for the rule sets. Jeremy Carroll first showed that simple entailment is NP-complete in general. Antoine Zimmerman suggested several simplifications and improvements to the proofs and presentation.</p>
+
+<p>The RDF 1.1 editors acknowledge valuable contributions from Thomas Baker, Dan Brickley, Gavin Carothers, Jeremy Carroll, Pierre-Antoine Champin, Richard Cyganiak, Martin J. Dürst, Alex Hall, Steve Harris, Ivan Herman, Eric Prud'hommeaux, Andy Seaborne, David Wood and Antoine Zimmermann. </p>
+<p>This specification is a product of extended deliberations by <a href="http://www.w3.org/2000/09/dbwg/details?group=46168&public=1">members of the RDF Working Group</a>. It draws upon the earlier specification [[RDF-MT]], whose editor acknowledged valuable inputs from Jeremy Carroll, Dan Connolly, Jan Grant, R. V. Guha, Herman ter Horst, Graham Klyne, Ora Lassilla, Brian McBride, Sergey Melnick, Peter Patel-Schneider, Jos deRoo and Patrick Stickler.
+
+</p>
+
+
+ <p>This document was prepared using the <a href="http://dev.w3.org/2009/dap/ReSpec.js/documentation.html#dfn-respec">ReSpec.js specification writing tool</a> developed by Robin Berjon. </p>
+
</section>
-
-
-<section class="appendix" id="references"><!--OddPage--><h2><span class="secno">F. </span>References</h2><section id="normative-references"><h3><span class="secno">F.1 </span>Normative references</h3><dl class="bibliography"><dt id="bib-RDF-PLAINLITERAL">[RDF-PLAINLITERAL]</dt><dd>Jie Bao; Sandro Hawke; Boris Motik; Peter F. Patel-Schneider; Axel Polleres. <a href="http://www.w3.org/TR/2009/REC-rdf-plain-literal-20091027/"><cite>rdf:PlainLiteral: A Datatype for RDF Plain Literals.</cite></a> 27 October 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-rdf-plain-literal-20091027/">http://www.w3.org/TR/2009/REC-rdf-plain-literal-20091027/</a>
-</dd><dt id="bib-RDF-TESTCASES">[RDF-TESTCASES]</dt><dd>Jan Grant; Dave Beckett. <a href="http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/"><cite>RDF Test Cases.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/">http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/</a>
-</dd><dt id="bib-RDF11-CONCEPTS">[RDF11-CONCEPTS]</dt><dd>Richard Cyganiak; David Wood. <a href="http://www.w3.org/TR/2012/WD-rdf11-concepts-20120605/"><cite>RDF 1.1 Concepts and Abstract Syntax</cite></a> 05 June 2012. W3C Working Draft (work in progress). URL: <a href="http://www.w3.org/TR/2012/WD-rdf11-concepts-20120605/">http://www.w3.org/TR/2012/WD-rdf11-concepts-20120605/</a>
-</dd></dl></section><section id="informative-references"><h3><span class="secno">F.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-OWL2-OVERVIEW">[OWL2-OVERVIEW]</dt><dd>W3C OWL Working Group. <a href="http://www.w3.org/TR/2009/REC-owl2-overview-20091027/"><cite>OWL 2 Web Ontology Language: Overview.</cite></a> 27 October 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-owl2-overview-20091027/">http://www.w3.org/TR/2009/REC-owl2-overview-20091027/</a>
-</dd><dt id="bib-OWL2-SYNTAX">[OWL2-SYNTAX]</dt><dd>Boris Motik; Peter F. Patel-Schneider; Bijan Parsia. <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/"><cite>OWL 2 Web Ontology Language:Structural Specification and Functional-Style Syntax.</cite></a> 27 October 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/">http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/</a>
-</dd><dt id="bib-RDF-MT">[RDF-MT]</dt><dd>Patrick Hayes. <a href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210/"><cite>RDF Semantics.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210/">http://www.w3.org/TR/2004/REC-rdf-mt-20040210/</a>
-</dd><dt id="bib-RDF-PRIMER">[RDF-PRIMER]</dt><dd>Frank Manola; Eric Miller. <a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/"><cite>RDF Primer.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">http://www.w3.org/TR/2004/REC-rdf-primer-20040210/</a>
-</dd><dt id="bib-RDF-SCHEMA">[RDF-SCHEMA]</dt><dd>Dan Brickley; Ramanathan V. Guha. <a href="http://www.w3.org/TR/2004/REC-rdf-schema-20040210/"><cite>RDF Vocabulary Description Language 1.0: RDF Schema.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-schema-20040210/">http://www.w3.org/TR/2004/REC-rdf-schema-20040210/</a>
-</dd><dt id="bib-RIF-OVERVIEW">[RIF-OVERVIEW]</dt><dd>Michael Kifer; Harold Boley. <a href="http://www.w3.org/TR/2010/NOTE-rif-overview-20100622/"><cite>RIF Overview.</cite></a> 22 June 2010. W3C Working Group Note. URL: <a href="http://www.w3.org/TR/2010/NOTE-rif-overview-20100622/">http://www.w3.org/TR/2010/NOTE-rif-overview-20100622/</a>
-</dd><dt id="bib-TURTLE-TR">[TURTLE-TR]</dt><dd>Eric Prud'hommeaux; Gavin Carothers. <a href="http://www.w3.org/TR/2013/CR-turtle-20130219/"><cite>Turtle: Terse Triple Language</cite></a> 19 February 2013. W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/2013/CR-turtle-20130219/">http://www.w3.org/TR/2013/CR-turtle-20130219/</a>
-</dd></dl></section></section></body></html>
+ </body>
+</html>