--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/rdf-mt/index.html Tue Feb 12 10:43:03 2013 -0600
@@ -0,0 +1,2088 @@
+
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+
+<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator"
+ content="HTML Tidy for Linux/x86 (vers 1st March 2002), see www.w3.org" />
+
+ <title>RDF Semantics Editors draft, not for publication</title>
+ <meta http-equiv="Content-Type"
+ content="text/html; charset=utf-8" />
+ <meta name="cvsid"
+ content="$Id: Overview.html,v 1.9 2004/02/10 15:29:28 sandro Exp $" />
+<style type="text/css">
+/*<![CDATA[*/
+code {font-family: monospace }
+ a.termref:visited, a.termref:link {font-family: sans-serif;
+ font-style: normal;
+ color: black;
+ text-decoration: none }
+a.termref:link:hover {background-color: #ffffaa }
+.RFC2119 { font-size: small; font-weight: bolder; }
+.oldstuff {color: red; background-color: #DDFFDD }
+.newstuff { }
+.newerstuff { }
+.changetable {background-color: #FFCCFF}
+.semantictable {background-color: #FFFFAA}
+.notetable {background-color: #BBBBFF}
+.ruletable {background-color: #FAFAFF}
+.othertable {background-color: #FDFDFD}
+.greyout {background-color: #CCCCCC}
+ /*]]>*/
+ </style>
+
+
+ <style type="text/css">
+/*****************************************************************
+ * ReSpec CSS
+ * Robin Berjon (robin at berjon dot com)
+ * v0.05 - 2009-07-31
+ *****************************************************************/
+
+
+/* --- INLINES --- */
+em.rfc2119 {
+ text-transform: lowercase;
+ font-variant: small-caps;
+ font-style: normal;
+ color: #900;
+}
+
+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 {
+ font-weight: bold;
+}
+
+a.internalDFN {
+ color: inherit;
+ border-bottom: 1px solid #99c;
+ text-decoration: none;
+}
+
+a.externalDFN {
+ color: inherit;
+ border-bottom: medium dotted #ccc;
+ text-decoration: none;
+}
+
+a.bibref {
+ text-decoration: none;
+}
+
+code {
+ color: #ff4500;
+}
+
+
+/* --- WEB IDL --- */
+pre.idl {
+ border-top: 1px solid #90b8de;
+ border-bottom: 1px solid #90b8de;
+ padding: 1em;
+ line-height: 120%;
+}
+
+pre.idl::before {
+ content: "WebIDL";
+ display: block;
+ width: 150px;
+ background: #90b8de;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+.idlType {
+ color: #ff4500;
+ font-weight: bold;
+ text-decoration: none;
+}
+
+/*.idlModule*/
+/*.idlModuleID*/
+/*.idlInterface*/
+.idlInterfaceID {
+ font-weight: bold;
+ color: #005a9c;
+}
+
+.idlSuperclass {
+ font-style: italic;
+ color: #005a9c;
+}
+
+/*.idlAttribute*/
+.idlAttrType, .idlFieldType {
+ color: #005a9c;
+}
+.idlAttrName, .idlFieldName {
+ color: #ff4500;
+}
+.idlAttrName a, .idlFieldName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlMethod*/
+.idlMethType {
+ color: #005a9c;
+}
+.idlMethName {
+ color: #ff4500;
+}
+.idlMethName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlParam*/
+.idlParamType {
+ color: #005a9c;
+}
+.idlParamName {
+ font-style: italic;
+}
+
+.extAttr {
+ color: #666;
+}
+
+/*.idlConst*/
+.idlConstType {
+ color: #005a9c;
+}
+.idlConstName {
+ color: #ff4500;
+}
+.idlConstName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlException*/
+.idlExceptionID {
+ font-weight: bold;
+ color: #c00;
+}
+
+.idlTypedefID, .idlTypedefType {
+ color: #005a9c;
+}
+
+.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
+ color: #c00;
+ font-weight: normal;
+}
+
+.excName a {
+ font-family: monospace;
+}
+
+.idlRaises a.idlType, .excName a.idlType {
+ border-bottom: 1px dotted #c00;
+}
+
+.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
+ width: 45px;
+ text-align: center;
+}
+.excGetSetTrue, .prmNullTrue, .prmOptTrue { color: #0c0; }
+.excGetSetFalse, .prmNullFalse, .prmOptFalse { color: #c00; }
+
+.idlImplements a {
+ font-weight: bold;
+}
+
+dl.attributes, dl.methods, dl.constants, dl.fields {
+ margin-left: 2em;
+}
+
+.attributes dt, .methods dt, .constants dt, .fields dt {
+ font-weight: normal;
+}
+
+.attributes dt code, .methods dt code, .constants dt code, .fields dt code {
+ font-weight: bold;
+ color: #000;
+ font-family: monospace;
+}
+
+.attributes dt code, .fields dt code {
+ background: #ffffd2;
+}
+
+.attributes dt .idlAttrType code, .fields dt .idlFieldType code {
+ color: #005a9c;
+ background: transparent;
+ font-family: inherit;
+ font-weight: normal;
+ font-style: italic;
+}
+
+.methods dt code {
+ background: #d9e6f8;
+}
+
+.constants dt code {
+ background: #ddffd2;
+}
+
+.attributes dd, .methods dd, .constants dd, .fields dd {
+ margin-bottom: 1em;
+}
+
+table.parameters, table.exceptions {
+ border-spacing: 0;
+ border-collapse: collapse;
+ margin: 0.5em 0;
+ width: 100%;
+}
+table.parameters { border-bottom: 1px solid #90b8de; }
+table.exceptions { border-bottom: 1px solid #deb890; }
+
+.parameters th, .exceptions th {
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+ font-family: initial;
+ font-weight: normal;
+ text-shadow: #666 1px 1px 0;
+}
+.parameters th { background: #90b8de; }
+.exceptions th { background: #deb890; }
+
+.parameters td, .exceptions td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+ vertical-align: top;
+}
+
+.parameters tr:first-child td, .exceptions tr:first-child td {
+ border-top: none;
+}
+
+.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
+ width: 100px;
+}
+
+.parameters td.prmType {
+ width: 120px;
+}
+
+table.exceptions table {
+ border-spacing: 0;
+ border-collapse: collapse;
+ width: 100%;
+}
+
+/* --- TOC --- */
+.toc a {
+ text-decoration: none;
+}
+
+a .secno {
+ color: #000;
+}
+
+/* --- 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;
+}
+
+.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;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+ margin-bottom: 0;
+}
+
+/* --- EXAMPLES --- */
+pre.example {
+ border-top: 1px solid #ff4500;
+ border-bottom: 1px solid #ff4500;
+ padding: 1em;
+ margin-top: 1em;
+}
+
+pre.example::before {
+ content: "Example";
+ display: block;
+ width: 150px;
+ background: #ff4500;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+/* --- EDITORIAL NOTES --- */
+.issue {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #ffc;
+}
+
+.issue::before {
+ content: "Issue";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+.note {
+ margin: 1em 0em 0em;
+ padding: 1em;
+ border: 2px solid #cff6d9;
+ background: #e2fff0;
+}
+
+.note::before {
+ content: "Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #cff6d9;
+ background: #fff;
+ padding: 3px 1em;
+}
+.technote {
+ margin: 1em 0em 0em;
+ padding: 1em;
+ border: 1px solid #F00;
+ background: #ccccff;
+}
+
+.technote::before {
+ content: "Technical Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #F00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+.changenote {
+ margin: 1em 0em 0em;
+ padding: 1em;
+ border: 1px solid #f00;
+ background: #ffccff;
+}
+
+.changenote::before {
+ content: "Change Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+/* --- Best Practices --- */
+div.practice {
+ border: solid #bebebe 1px;
+ margin: 2em 1em 1em 2em;
+}
+
+span.practicelab {
+ margin: 1.5em 0.5em 1em 1em;
+ font-weight: bold;
+ font-style: italic;
+}
+
+span.practicelab { background: #dfffff; }
+
+span.practicelab {
+ position: relative;
+ padding: 0 0.5em;
+ top: -1.5em;
+}
+
+p.practicedesc {
+ margin: 1.5em 0.5em 1em 1em;
+}
+
+@media screen {
+ p.practicedesc {
+ position: relative;
+ top: -2em;
+ padding: 0;
+ margin: 1.5em 0.5em -1em 1em;
+ }
+}
+
+/* --- SYNTAX HIGHLIGHTING --- */
+pre.sh_sourceCode {
+ background-color: white;
+ color: black;
+ font-style: normal;
+ font-weight: normal;
+}
+
+pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; } /* language keywords */
+pre.sh_sourceCode .sh_type { color: #666; } /* basic types */
+pre.sh_sourceCode .sh_usertype { color: teal; } /* user defined types */
+pre.sh_sourceCode .sh_string { color: red; font-family: monospace; } /* strings and chars */
+pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; } /* regular expressions */
+pre.sh_sourceCode .sh_specialchar { color: #ffc0cb; font-family: monospace; } /* e.g., \n, \t, \\ */
+pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; } /* comments */
+pre.sh_sourceCode .sh_number { color: purple; } /* literal numbers */
+pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; } /* e.g., #include, import */
+pre.sh_sourceCode .sh_symbol { color: blue; } /* e.g., *, + */
+pre.sh_sourceCode .sh_function { color: black; font-weight: bold; } /* function calls and declarations */
+pre.sh_sourceCode .sh_cbracket { color: red; } /* block brackets (e.g., {, }) */
+pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; } /* TODO and FIXME */
+
+/* Predefined variables and functions (for instance glsl) */
+pre.sh_sourceCode .sh_predef_var { color: #00008B; }
+pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }
+
+/* for OOP */
+pre.sh_sourceCode .sh_classname { color: teal; }
+
+/* line numbers (not yet implemented) */
+pre.sh_sourceCode .sh_linenum { display: none; }
+
+/* Internet related */
+pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }
+
+/* for ChangeLog and Log files */
+pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
+pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
+pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }
+
+/* for Prolog, Perl... */
+pre.sh_sourceCode .sh_variable { color: #006400; }
+
+/* for LaTeX */
+pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
+pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
+pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
+pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
+pre.sh_sourceCode .sh_argument { color: #006400; }
+pre.sh_sourceCode .sh_optionalargument { color: purple; }
+pre.sh_sourceCode .sh_math { color: orange; }
+pre.sh_sourceCode .sh_bibtex { color: blue; }
+
+/* for diffs */
+pre.sh_sourceCode .sh_oldfile { color: orange; }
+pre.sh_sourceCode .sh_newfile { color: #006400; }
+pre.sh_sourceCode .sh_difflines { color: blue; }
+
+/* for css */
+pre.sh_sourceCode .sh_selector { color: purple; }
+pre.sh_sourceCode .sh_property { color: blue; }
+pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }
+
+/* other */
+pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
+pre.sh_sourceCode .sh_paren { color: red; }
+pre.sh_sourceCode .sh_attribute { color: #006400; }
+
+</style>
+
+ <link rel="stylesheet" type="text/css"
+ href="http://www.w3.org/StyleSheets/TR/W3C-REC" />
+
+</head>
+
+
+ <body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="./RDF 1.1 Concepts and Abstract Syntax_files/w3c_home" alt="W3C"></a></p>
+<h1 property="dcterms:title" class="title" id="title">RDF 1.1 Semantics</h1>
+<h2 property="dcterms:issued" datatype="xsd:dateTime" content="2013-02-11T00:00:00+0000" id="w3c-working-draft-15-january-2013"><acronym title="World Wide Web Consortium">W3C</acronym> Working Draft 11 February 2013</h2><dl><dt>This version:</dt><dd><a href=""></a></dd><dt>Latest published version:</dt><dd><a href=""></a></dd><dt>Latest editor's draft:</dt><dd><a href=""></a></dd>
+<dt>Previous version:</dt><dd><a rel="dcterms:replaces" href=""></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 rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a rel="foaf:homepage" property="foaf:name" content="Patrick Hayes" href="http://www.ihmc.us/groups/phayes/">Patrick Hayes</a>, <a rel="foaf:workplaceHomepage" href="http://www.ihmc.us/index.php">Florida IHMC</a></span>
+</dd>
+<dd rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a rel="foaf:homepage" property="foaf:name" content="Peter F. Patel-Schneider" href="////">Peter F. Patel-Schneider</a>, <a rel="foaf:workplaceHomepage" href="////">////</a></span>
+</dd>
+
+<dd rel="bibo:editor" inlist=""><span typeof="foaf:Person"><span property="foaf:name">David Wood</span>, <a rel="foaf:workplaceHomepage" href="http://3roundstones.com/">3 Round Stones </a>(Series Editor)</span>
+</dd>
+<dt>Previous editors:</dt><dd><span><span>Patrick Hayes</span>, IHMC</span>
+</dd>
+<dd><span><span>Brian McBride</span>, Hewlett Packard Labs (RDF 2004 Series Editor)</span>
+</dd>
+</dl><p class="copyright"><a rel="license" href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2004-2013 <span rel="dcterms:publisher"><span typeof="foaf:Organization"><a rel="foaf:homepage" property="foaf:name" content="World Wide Web Consortium" href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup></span></span> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <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>
+
+
+<p class=issue>Open issues are marked by comments in this format.<br /> A great deal of boilerplate and HTML markup is missing from this draft, which should be read solely for content. It also probalby has quite a few typos. <br/> An effort has been made to keep the text shorter and less didactic in tone than the 2004 Semantics document, following the style of the draft Concepts document. <br />Comments are appreciated. </p>
+<p class=changenote>Significant differences between this specification and the 2004 RDF 1.0 specification are noted in this format.</p>
+<p class=technote>Technical or pedantic notes which explain arcane or side issues, of interest only to some readers, are noted in this format. </p>
+<p></p>
+<p class="issue"> The 2004 semantics document contains a lot of material which is devoted to explaining material, such as most of the RDF vocabulary, which is <em>not</em> covered by the formal model theory, and also various warnings and cautions about the limits of truth-based semantics. Much of this has been retained in the present text. It would be a lot shorter and less verbose if all this were omitted, or possibly put into a separate Appendix or a separate section. Any comments on this idea? </p>
+
+ <h2 id="abstract">Abstract</h2>
+<p>This is a specification of a precise semantics for the Resource Description
+ Framework (RDF) and RDF Schema (RDFS) and defines a number of distinct entailment regimes. ///A companion document///A later section/// gives inference rules corresponding the various entailment regimes defined here.</p>
+
+<h2><a name="prelim" id="prelim">Introduction</a> </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 unfamiliar with model theory may find the informative sections /// useful, which re-state the semantic conditions in terms of axioms and inference rules. Readers who are unfamiliar with model theory can also find a brief introduction to the basic ideas and terminology in Appendix ////.</p>
+<p>This specification is normative for RDF <a href="#glossFormal"
+ class="termref">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 <strong class="RFC2119">MUST NOT</strong> violate the conditions described here. </p>
+
+<h2>Semantic extensions and entailment regimes </h2>
+
+<p><a id="DefSemanticExtension" name="DefSemanticExtension"></a>RDF is intended for use as a base notation for a variety of extended notations such as OWL and RIF, whose expressions can be encoded as RDF graphs which use a particular vocabulary with a specially described meaning. In addition, 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 IRI meanings, the larger the set of valid entailments. </p>
+
+<p>A particular such set of semantic assumptions is called an <em>RDF semantic extension</em>. Each semantic extension defines an <em>entailment regime</em> 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 phrases such as rdfs-entailment, owl-entailment. All entailment regimes <strong class="RFC2119">MUST</strong> be <em>monotonic</em> extensions of the simple entailment regime described in the next section, in the sense that if A simply entails B then A must also entail B under any extended notion of entailment. Put another way, a semantic extension cannot "cancel" an entailment made by a weaker entailment regime.</p>
+
+<h1>Notation and terminology</h1>
+
+<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 href="#glossValid"
+ class="termref">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 the expressions "A" and "B" name the same entity. 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 <a
+ href="http://www.w3.org/TR/rdf-testcases/#ntriples">N-Triples</a> syntax described
+ in the RDF test cases document [<cite><a href="#ref-rdf-tests">RDF-TESTS</a></cite>] <a class="changetable">///is this the best reference now?///</a>
+ literal strings are enclosed within double quote marks, language tags indicated
+ by the use of the <code>@</code> sign, and triples terminate with a 'code dot'
+ <code>.</code> . </p>
+
+<p class=issue> Need more on the aaa and sss conventions. and the abbreviated Ntriples notation. </p>
+
+<p>A <em>name</em> is any IRI or literal. A <em>vocabulary</em> is a set of names.
+<p class=issue>The definition in Concepts seems to be narrower than this. </p>
+
+
+
+<h2><a id="sinterp" name="sinterp"> Simple Interpretations</a> </h2>
+
+
+
+<p>A simple interpretation I of a vocabulary V is a structure consisting of:</p>
+
+<div class="title">Definition of a simple interpretation.</div>
+<table border="1" summary="definition of a simple interpretation">
+ <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>
+ <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 in V into (IR union IP)</p>
+ <p>5. A partial mapping IL from literals in V into IR.</p>
+ </td>
+ </tr>
+ </table>
+
+<p class=changenote>In the 2004 RDF 1.0 semantics, LV was not a partial mapping.</p>
+<p>IEXT(x), called
+ the <a href="#defexten" class="termref"><i>extension</i></a> 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 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>
+
+ <p>The denotation of a ground RDF graph in I is then given by the following
+ rules</p>
+
+
+ <div class="title">Semantic conditions for ground graphs.</div>
+ <table cellpadding="5" border="2" summary="semantic conditions for RDF graphs">
+ <tbody>
+<tr>
+<td class="semantictable">if E is a <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-language-tagged-string" class="termref">language-tagged string</a> with type <code>rdf:langString</code>, a lexical form sss and a tag ttt, then IL(E) = < sss , ttt ></td>
+ </tr>
+<tr>
+<td class="semantictable">if E is a literal with type <code>xsd:string</code> and a lexical form sss, then IL(E) = sss </td>
+ </tr>
+
+ <tr>
+ <td class="semantictable">if E is a literal in V then I(E) = IL(E)</td>
+ </tr>
+
+ <tr>
+ <td class="semantictable">if E is an IRI in V then I(E) = IS(E)</td>
+ </tr>
+
+ <tr>
+ <td class="semantictable"><p>if E is a ground triple s p o<code>.</code>
+ then I(E) = true if </p>
+ <p>s, p and o are in V, <span >I(p) is in IP and the pair </span> <I(s),I(o)>
+ is in IEXT(I(p))</p>
+ <p>otherwise I(E)= false.</p></td>
+ </tr>
+
+ <tr>
+ <td class="semantictable">if E is a ground RDF graph then I(E) = false if I(E') =
+ false for some triple E' in E, otherwise I(E) =true.</td>
+ </tr>
+ </tbody>
+ </table>
+
+<p>The first two conditions fix the denotations of simple string literals with and without language tags.</p>
+
+<p class="changenote"> <em>Change note.</em> 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. We include both of these cases in the basic graph semantics to maintain conformity to the 2004 RDF 1.0 specifications. None of these literals can be ill-typed, so their presence does not affect any entailments. </p>
+<p>If an interpretation does not give a semantic value
+ to a <a href="#defname" class="termref">name</a> in the graph then these truth-conditions will always yield the value false for some triple
+ in the graph, and hence for the graph itself. Turned around, this means that in order for a graph to be true, all the IRI and literal nodes in it must refer to something in the world being described. </p>
+<p> The final condition implies that an empty graph (an empty set of triples) is trivially 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 must be in IR; so any IRI which occurs in a graph both as a predicate and as a subject or object must denote something in the intersection of IP and IR.</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>
+
+<p class="issue">Since 'plain' literals now have the type xsd:string, it seems we we must incorporate this datatype into the basic definition of RDF graph. Any objections to this? </p>
+<p class="issue"> rdf:langString is a "type", but is it a datatype? This will matter in RDFS where we are faced with the potential axiom (rdf:langString rdf:type rdfs:Datatype). </p>
+
+ <h3><a name="unlabel" id="unlabel">1.5. Blank Nodes</a></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>
+
+<p>The semantics of blank nodes is defined as a condition on all RDF triples in a single blank node <em>scope</em>. Note that all blank nodes in an RDF graph must be in a single scope, but that a scope might extend beyond a single graph. For example, a TriG document ///ref/// defines a blank node scope which extends over all graphs in the dataset described by the document.</p>
+
+<p class="issue">The Concepts document does not yet define blank node scopes.</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 names. </p>
+
+ <div class="title">Semantic condition for blank nodes.</div>
+ <table cellpadding="5" border="2" summary="Semantic conditions for blank nodes">
+ <tbody>
+ <tr>
+
+ <td class="semantictable">If E is a blank node and A(E) is defined then
+ [I+A](E) = A(E)</td>
+ </tr>
+
+ <tr>
+ <td class="semantictable">If E is an RDF graph then I(E) = true if [I+A'](E) =
+ true for some mapping A' from the set of blank nodes in the scope of E to IR, otherwise
+ I(E)= false.</td>
+ </tr>
+ </tbody>
+ </table>
+<p class="termref">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 (i.e. outside the scope in which they occur).</p>
+
+
+<h3>Intuitive summary</h3>
+
+<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 actual things,</p><p> 2. string literals and language-tagged strings refer to their own lexical forms, </p><p>3. there is some way to interpret all the blank nodes in the scope as referring to actual things,</p><p>4. the IRIs in property position identify binary relationships,</p><p>5. 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>
+
+<p>All semantic extensions of any vocabulary or higher-level notation encoded in RDF <a class="RFC2119">MUST</a> conform to these minimal truth conditions. Other semantic extensions may extend and add to these, but they <a class="RFC2119">MUST NOT</a> over-ride or negate them. </p>
+
+<h3>Merging Graphs</h3>
+
+<p> <a id="defmerge" name="defmerge"></a>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 graphs are in the same scope, then the same blank node might occur in more than one of them, and will retain its identity when the union graph is formed. If the graphs in a set are from different scopes they cannot share blank nodes, so if they are represented by a notation which uses blank node identifiers then care must be taken to change the identifiers to avoid name clashes between blank node identifiers used in graphs from different scopes. Once this is done − that is, when graphs from different scopes do not use the same blank node identifier − then the union graph can be formed by taking the union of the triples in the various graphs in S. We will refer to this process of forming the union of graphs as <em>merging</em>, and to the union graph as the <em>merge</em> of the original graphs. </p>
+
+<p class="changenote"> The 2004 RDF 1.0 specification did not define a notion of blank node scope, so allowed the (irrational) possibility of two graphs 'accidentally' sharing a blank node. It was therefore obliged to define a process of 'standardizing apart' blank nodes, and to distinguish graph unions from graph merges. Requiring each RDF graph to be in a single blank node scope simplifies the basic syntax and renders this distinction unnecessary. Standardizing apart may still be needed at a concrete syntax level, but is not 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>
+
+<h3>Simple Entailment</h3>
+
+<p>Following standard terminology, we say that I <a
+ id="defsatis" name="defsatis"></a><i>satisfies</i> E when I(E)=true, and a set
+ S of RDF graphs <a id="defentail"
+ name="defentail"></a><em>(simply)</em> <a href="#glossEntail"
+ class="termref"><em>entails</em></a> <span >a graph</span> 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>
+
+ <p><a id="defvalid" name="defvalid">Any process which constructs a graph E from some other graph(s) S is said to be <em>(simply) valid</em> if S simply entails E </a><span >in every case</span>, otherwise <em>invalid.</em> </p>
+
+<p>Being an invalid process does not mean that the conclusion is false, and being <a href="#glossValid" class="termref">valid</a> does not guarantee truth. However, validity represents the best guarantee that any assertional language can offer: if given true inputs, it will never draw a false conclusion from them. 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. Nothing in this specification mandates 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. Invalid processes are not prohibited, but 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 //ref// 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, this 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>
+
+<h3>Some basic properties of simple entailment. </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 <a href="#prf" class="termref">appendix ///</a>.</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><strong>Empty Graph Lemma.</strong> The empty set of triples is entailed by
+ any graph, and does not entail any graph except itself. <a href="#emptygraphlemmaprf" class="termref">[Proof]</a></p>
+<p><a name="subglem" id="subglem"><strong>Subgraph Lemma.</strong></a> A graph
+ entails all its <a
+ href="#defsubg" class="termref">subgraphs</a>. <a href="#subglemprf" class="termref">[Proof]</a></p>
+<p><a name="instlem" id="instlem"><strong>Instance Lemma.</strong></a> A graph
+ is entailed by any of its <a
+ href="#definst" class="termref">instances</a>.<a href="#instlemprf" class="termref"> [Proof]</a></p>
+<p >The relationship between merging and entailment is simple,
+ and obvious from the definitions:</p>
+<p><a name="mergelem" id="mergelem"><strong>Merging lemma.</strong></a> The merge
+ of a set S of RDF graphs is entailed by S, and entails every member of S. <a href="#mergelemprf" class="termref">[Proof]</a></p>
+
+ <p>This means that a 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 merging them. </p>
+ <p>The main result for simple entailment is:</p>
+<p><a name="interplemma" 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 name="Anonlem1" id="Anonlem1"><strong>Anonymity lemma.</strong></a> Suppose
+ E is a <a href="#deflean"
+ class="termref">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 name="monotonicitylemma" 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 name="compactlemma" 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>
+
+
+
+<h3>Skolemization</h3>
+
+<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>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>
+
+<p class=technote>The more general notion of skolemization involving Skolem functions is not used in RDF as there are no universal quantifiers.</p>
+<h3><a name="vocabulary_entail" id="vocabulary_entail"></a><span > Vocabulary interpretations and vocabulary entailment</span></h3>
+<p >Simple interpretations and simple entailment capture the semantics of RDF
+ graphs when no attention is paid to the particular meaning of any of the names
+ in the graph. To obtain the full meaning of an RDF graph written using a particular
+ vocabulary, it is usually necessary to add further semantic conditions which
+ attach stronger meanings to particular IRIs and typed literals in
+ the graph. Interpretations which are required to satisfy extra semantic conditions
+ on a particular vocabulary are generically referred to as <em>vocabulary
+ interpretations</em>. Vocabulary entailment means entailment with respect to
+ such vocabulary interpretations. These stronger notions of interpretation and
+ entailment are indicated by the use of a prefix, so that we will refer
+ to <em>D-entailment</em>, <em>rdf-entailment</em>, <em>rdfs-entailment</em> and so on.
+ </p>
+
+
+<p></p>
+
+
+
+
+<h3>Literals and datatypes</h3>
+
+<p class="changenote"> In the 2004 RDF 1.0 specification, datatypes were as an extension to RDFS and 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>
+
+<p>RDF literals are either language-tagged literals, whose semantics is already specified, or datatyped literals which
+combine a string and an IRI which is intended to identify a datatype. A datatype is understood to define a partial mapping from character strings to values, and the literal then refers to the value obtained by applying the datatype mapping to the character string. If this mapping gives no value for the literal string, then the literal also has no value.</p>
+
+<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it does not identify a known datatype. Interpretations will vary according to how many IRIs they recognize as denoting datatypes, so we will refer to a set D of <em>recognized datatype IRIs</em> and treat this as a parameter on interpretations, and hence upon entailments. Literals with an "unknown" datatype, that is, with a 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>
+
+<p class="changenote"> In the 2004 RDF 1.0 specification, D was defined as a datatype mapping from IRIs to datatypes, rather than simply as a set of IRIs. </p>
+
+<p> A literal whose datatype IRI is recognized, but whose character string is not in the domain of the datatype mapping, is called <em>ill-typed</em>.</p>
+
+<p>The semantics of datatypes assumes that datatype IRIs denote things called datatypes in the universe, and that every recognized datatype d has a corresponding lexical-to-value mapping L2V(d) from character strings to semantic values. For example,</p><p> L2V(<code>http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#decimal</code>)('24') </p><p> is the number twenty-four. The lexical-to-value mapping is defined by the specification of the datatype, externally to RDF.</p>
+
+<h3>D-interpretations</h3>
+
+<p>Let D be a set of IRIs identifying recognized datatypes. A <em>(simple) D-interpretation</em> of V is a simple interpretation (V union D) which satisfies the following conditions:</p>
+
+<div class="title">Semantic conditions for datatyped literals.</div>
+<table border="1" class="semantictable" summary="datatype semantic condition">
+ <tbody>
+<tr>
+<tr><td>For every IRI aaa in D, I(aaa) is the datatype conventionally identified by aaa.</td></tr><tr>
+ <td>For every IRI aaa in D, and every datatyped literal "sss"^^aaa in V, IL("sss"^^aaa) = L2V(I(aaa))(sss)</td></tr></tbody></table></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. will be 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>
+
+<p>The set of all values of datatype mappings − that is, the intersection of IR with the union of the ranges of L2V(I(aaa)) for aaa in D − is called the set LV of <em>literal values</em>. LV is a subset of IR but its extent depends upon the set D. Note that an IRI may also denote a value in LV, and blank nodes may range over values in LV.
+
+
+<p class="changenote"> In the 2004 RDF 1.0 specification, ill-typed literals were required to denote a value in IR, but excluded from LV. </p>
+<p></p>
+
+<p class="technote"> These conditions do not require the universe of every interpretation to contain all possible literal values. D-interpretations can be finite.</p>
+
+<h3>Datatype entailment</h3>
+
+<p>Datatype entailment is a form of vocabulary entailment. </p><p>Satisfaction and entailment are defined exactly as before, but restricted to D-interpretations. A graph is <em>(simply) D-satisfiable </em>when it has the value true in some D-interpretation, and a set S of graphs <em>(simply) D-entails </em>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 <em>D-unsatisfiable</em>. A D-unsatisfiable graph D-entails any graph. </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 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 href="#interplemma" class="termref">interpolation lemma</a> is not true for D-entailment, since D-entailments
+can hold because of particular properties of the lexical-to-value mappings of the recognized datatypes. For example, if D contains <code>xsd:number</code>, then </p>
+
+<p><code>aaa ppp "00025"^^xsd:number .</code></p>
+
+<p>D-entails</p>
+
+<p><code>aaa ppp "25"^^xsd:number .</code>
+</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 RDFS vocabulary, defined later.</p>
+
+
+<h3><a name="RDFINTERP" id="RDFINTERP">3.1 RDF Interpretations</a></h3>
+
+ <p ><a name="defRDFV" id="defRDFV"></a>The <em>RDF vocabulary, </em>rdfV, is an infinite
+ set of IRIs in the <code>rdf:</code> namespace:</p>
+
+
+
+ <table border="1" summary="rdf vocabulary">
+ <tbody>
+ <tr>
+ <td class="othertable"><strong>RDF vocabulary</strong></td>
+ </tr>
+
+ <tr>
+
+ <td class="othertable"> <code>rdf:type</code> <code>rdf:Property
+ rdf:XMLLiteral rdf:HTML rdf:nil rdf:List rdf:Statement rdf:subject rdf:predicate
+ rdf:object rdf:first rdf:rest rdf:Seq rdf:Bag rdf:Alt rdf:value rdf:_1 rdf:_2
+ ... </code></td>
+ </tr>
+ </tbody>
+ </table>
+ <p>The RDF built-in datatypes <code>rdf:XMLLiteral</code> and <code>rdf:HTML</code> are defined in ///RDF Concepts///. RDF interpretations are required to recognize these datatypes. The truth conditions on RDF graphs mean that the datatypes <code>rdf:langString</code> and <code>xsd:string</code> are effectively recognized also. </p>
+
+<p> <a id="rdfinterpdef" name="rdfinterpdef"></a>An <i>RDF-interpretation</i>
+ of a vocabulary V is a {<code>rdf:XMLLiteral</code> , <code>rdf:HTML</code> , <code>rdf:langString</code>, <code>xsd:string</code>}-interpretation I <span >of (V union rdfV)
+ which satisfies:</p>
+<div class="title">RDF semantic condition.</div>
+<table border="1" summary="RDF semantic condition">
+ <tbody>
+ <tr>
+ <td class="semantictable"><a name="rdfsemcond1" id="rdfsemcond1"></a>x is
+ in IP if and only if <x, I(<code>rdf:Property</code>)> is in IEXT(I(<code>rdf:type</code>))</td>
+ </tr>
+
+ </tbody>
+</table>
+ <p>and satisfies all the following triples:</p>
+ <div class="title">RDF axioms.</div>
+
+ <table border="1" summary="RDF axiomatic triples">
+ <tr>
+ <td class="ruletable"><a name="RDF_axiomatic_triples" 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>
+
+ </code></td>
+ </tr>
+ </table>
+
+<p> </p>
+
+<h3><a name="rdf_entail" id="rdf_entail"></a>RDF entailment</h3>
+
+<p>S <i>rdf-entails</i> E when every rdf-interpretation which satisfies every
+ member of S also satisfies E. </p>
+
+<p>It is easy to see that the lemmas in <a href="#entail" > Section 2</a> do not all apply to rdf-entailment:
+ for example, all the rdf axioms are true in every <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>, so are rdf-entailed by the empty graph,
+ contradicting the <a href="#interplemma" class="termref">interpolation lemma</a> for rdf-entailment. </p>
+
+<p class="technote"> Since rdfV is infinite, there are no finite RDF interpretations. In practice, it is sufficient to restrict the RDF axioms to a finite subset which only contains the membership properties which actually occur in the graph vocabulary, but this is complicated to describe exactly. ///This is weak. </p>
+<p class="issue"> Ideally we should define rdf-satisfaction so that it allows finite models. Every way of doing this investigated so far has been either too complicated or unclear in its formal properties. Work continues on finding a more elegant solution, but the account given here is a fall-back.</p>
+
+<h3><a name="ReifAndCont" id="ReifAndCont"> Reification, Containers, Collections and rdf:value</a></h3>
+
+<p class="issue">Should this section, which is informative at best, simply be omitted? It is not really part of the definition of the model theory, more a kind of essay about stuff that is not in the model theory.</p>
+
+<dt>
+<dd class="greyout">
+<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 section we briefly review 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>
+
+<h4><a name="Reif" id="Reif">3.3.1 Reification</a></h4>
+
+ <div class="c1">
+ <table border="1" summary="reification vocabulary">
+ <tbody>
+ <tr>
+ <td class="othertable"><strong>RDF reification vocabulary</strong></td>
+ </tr>
+ <tr>
+ <td class="othertable"><code>rdf:Statement rdf:subject rdf:predicate
+ rdf:object</code></td>
+ </tr>
+ </tbody>
+ </table>
+ </div>
+
+ <p>The intended meaning of this vocabulary is to allow an RDF graph to act as metadata describing other RDF triples. </p>
+
+
+ <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: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 <i><a href="#glossReify"
+ class="termref"><em>reification</em></a></i> 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
+ to. The value of the <code>rdf:subject</code> property is not the
+ subject IRI itself but the thing it denotes, and similarly for <code>rdf:predicate</code> and <code>rdf:object</code>. For example, if the referent of <code>ex:a</code> is Mount Everest, then the subject of the reified triple is also the mountain, not the IRI which refers to it.
+
+</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>The subject of a reification is intended to refer to a concrete realization of an RDF triple, such as a document in a surface syntax, rather than a triple considered as an abstract object. This supports use cases where properties such as dates of
+ composition or provenance information are applied to the
+ reified triple, which are meaningful only when thought of as
+ referring to a particular instance or token of a triple. </p>
+
+ <p>A reification of a triple does not entail the triple, and is not
+ entailed by it. The
+ reification only says that the triple token exists and what it is about,
+ not that it is true, so it does not entail the triple. On the other hand, asserting a triple does not automatically imply that any
+ triple tokens exist in the universe being described by the triple.
+ For example, the triple might be part of an ontology describing
+ animals, which could be satisfied by an interpretation in which the
+ universe contained only animals, and in which a reification of it was therefore
+ false.</p>
+
+ <p>Since the relation between triples and reifications of triples
+ in any RDF graph or graphs need not be one-to-one, asserting a
+ property about some entity described by a reification need not
+ entail that the same property holds of another such entity, even if
+ it has the same components. For example,</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>
+
+
+<h4><a name="Containers" id="Containers">3.3.2 RDF containers</a></h4>
+
+ <table border="1" summary="container vocabulary">
+ <tbody>
+ <tr>
+ <td class="othertable"><strong>RDF Container Vocabulary</strong></td>
+ </tr>
+ <tr>
+ <td class="othertable"><code>rdf:Seq rdf:Bag rdf:Alt rdf:_1 rdf:_2
+ ...</code></td>
+ </tr>
+ </tbody>
+ </table>
+ <p>RDF provides vocabularies for describing three classes of
+ containers. Containers have a type, and their members can
+ be enumerated by using a fixed set of <em>container membership
+ properties</em>. These properties are indexed by integers to
+ provide a way to distinguish the members from each other, but these
+ indices should not necessarily be thought of as defining an
+ ordering of the container itself; some containers are considered to be unordered.</p>
+
+ <p>The RDFS vocabulary, described below, adds a generic membership
+ property which holds regardless of position, and classes containing
+ all the containers and all the membership properties.</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,
+ 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
+ meaning that these assumptions are false, but only that RDF does
+ not formally entail that they must be true.</p>
+
+ <p>There are no special semantic conditions on the container
+ vocabulary: the only 'structure' which RDF presumes its containers
+ to have is what can be inferred from the use of this vocabulary and
+ the <span >general RDF</span> semantic conditions. <span >In
+ general, this amounts to knowing the type of a container, and having a partial
+ enumeration
+ of the items in the container.</span> The intended mode of use is that things
+ of type <code>rdf:Bag</code>
+ are considered to be unordered but to allow duplicates; things of
+ 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
+ indicated by the numerical ordering of the container membership
+ properties, <span >which are assumed to be single-valued</span>.
+ 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><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>Notice that if this conclusion were <a href="#glossValid"
+ class="termref">valid</a>, then the result of
+ conjoining it to the original graph would also be a <a href="#glossValid"
+ class="termref">valid</a>
+ entailment, which would assert that both elements were in both
+ positions. This is a consequence of the fact that RDF is a purely
+ 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
+ something can be asserted to be 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>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
+ 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>
+
+
+<h4><a name="collections" id="collections"></a>3.3.3 RDF collections</h4>
+
+ <table border="1" summary="collection vocabulary">
+ <tbody>
+ <tr>
+ <td class="othertable"><strong>RDF Collection Vocabulary</strong></td>
+ </tr>
+ <tr>
+ <td class="othertable"><code>rdf:List rdf:first rdf:rest rdf:nil</code></td>
+ </tr>
+ </tbody>
+ </table>
+ <p>RDF provides a vocabulary for describing collections, i.e.'list
+ structures', in terms of head-tail links. Collections differ from
+ containers in allowing branching structure and in having an
+ explicit terminator, allowing applications to determine the exact
+ set of items in the collection.</p>
+
+
+<p>As with containers, no special semantic conditions are imposed on this vocabulary
+ other than the type of <code>rdf:nil</code> being <code>rdf:List</code>. It
+ is intended for use typically in a context where a container is described using
+ blank nodes to connect a 'well-formed' sequence of items, each described by
+ two triples of the form<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
+ value of the property <code>rdf:rest</code>. In a familiar convention, <code>rdf:nil</code>
+ can be thought of as the empty collection. Any such graph amounts to an assertion
+ that the collection exists, and since the members of the collection can be determined
+ by inspection, this is often sufficient to enable applications to determine
+ what is meant. The semantics does not require any collections
+ to exist other than those mentioned explicitly in a graph (and the empty collection).
+ For example, the existence of a collection containing two items does not automatically
+ guarantee that the similar collection with the items permuted also exists:<code><br />
+ <br />
+ _:c1 rdf:first <ex:aaa> .<br />
+ _:c1 rdf:rest _:c2 .<br />
+ <span > _:c2 rdf:first</span> <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 />
+ _:c4 rdf:rest rdf:nil .
+ </code></p>
+
+ <p>Also, RDF imposes no '<a href="#glossWellformed"
+ class="termref">well-formedness</a>' conditions on the use of this
+ vocabulary, so that it is possible to write RDF graphs which assert
+ the existence of highly peculiar objects such as lists with forked
+ or non-list tails, or multiple heads:</p>
+
+<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
+ by failing to specify its <code>rdf:rest</code> property value.</p>
+
+
+<p>Semantic extensions <strong title="MAY in RFC 2119 context" class="RFC2119">MAY</strong>
+ place extra syntactic well-formedness restrictions on the use of this vocabulary
+ in order to rule out such graphs. They <strong title="MAY in RFC 2119 context" class="RFC2119">MAY</strong>
+ 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
+ ordered sequence whose members are the denotations of the <code>rdf:first</code>
+ values of the items, in the order got by tracing the <code>rdf:rest</code> properties
+ from the subject to <code>rdf:nil</code>. This permits sequences which contain
+ other sequences.</p>
+<p The RDFS semantic conditions, described below, 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>
+
+
+<h4><a name="rdfValue" id="rdfValue"></a>3.3.4 rdf:value</h4>
+<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="#ref-rdf-primer">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 <span >the
+ meaning of <code>rdf:value</code> may vary from application to application</span>.
+ In practice, the intended meaning is often clear from the context, but may be
+ lost when graphs are merged or when conclusions are inferred.</p>
+
+</dd>
+</dt>
+
+
+<h2><a name="rdfs_interp" id="rdfs_interp">4. Interpreting the RDFS Vocabulary</a></h2>
+
+
+<h3><a name="RDFSINTERP" id="RDFSINTERP">4.1 RDFS Interpretations</a></h3>
+
+<p>RDF Schema [<cite><a href="#ref-rdf-vocabulary">RDF-VOCABULARY</a></cite>]
+ extends RDF to include a larger <a id="defRDFSV" name="defRDFSV"></a>vocabulary
+ rdfsV with more complex semantic constraints:</p>
+
+ <div class="c1">
+ <table border="1" summary="RDFS vocabulary">
+ <tbody>
+ <tr>
+ <td class="othertable"><strong>RDFS vocabulary</strong></td>
+ </tr>
+
+ <tr>
+ <td class="othertable"><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
+ rdfs:label</code></td>
+ </tr>
+ </tbody>
+ </table>
+ </div>
+<p>(<code>rdfs:comment</code>,<code> rdfs:seeAlso</code>, <code>rdfs:isDefinedBy</code>
+ and <code>rdfs:label</code> are included here because some constraints which
+ 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>.
+ 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. The meanings of
+ ICEXT and IC in a <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>
+ of the RDFS vocabulary are completely defined by the first two conditions in
+ the table of RDFS semantic conditions, below. A class may have an
+ empty class extension. Two different class entities could have the same class extension.
+ The class extension of <code>rdfs:Class</code> contains the class <code>rdfs:Class</code>.
+</p>
+
+<p class="technote">The term "class" used here should be distinguished from the usage of "class" in object-oriented programming and modelling. There is no notion of a class "owning" anything (such as a method) in RDFS. An RDF class is simply a way to classify things into a named category. </p>
+
+<p><a id="rdfsinterpdef" name="rdfsinterpdef"></a> An <i>rdfs-interpretation</i> of V is an <a href="#rdfinterpdef" class="termref">rdf-interpretation</a> I
+ <span >of (V union rdfV union rdfsV) which satisfies the semantic conditions in the following table, and satisfies all the triples in the subsequent table of <em>RDFS axiomatic triples</em>.</p>
+
+<div class="title">RDFS semantic conditions.</div>
+ <table border="1">
+ <tr>
+
+ <td class="semantictable"> <p><a name="rdfssemcond1" 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>
+ <p>ICEXT(I(<code>rdfs:Resource</code>)) = IR</p>
+ <p >ICEXT(I(<code>rdfs:Literal</code>)) = LV</p></td>
+ </tr>
+ <tr>
+
+ <td class="semantictable"> <p><a name="rdfssemcond2" id="rdfssemcond2"></a>If
+ < x,y > is in IEXT(I(<code>rdfs:domain</code>)) and < u,v > is
+ in IEXT(x) then u is in ICEXT(y)</p></td>
+ </tr>
+ <tr>
+
+ <td class="semantictable"> <p><a name="rdfssemcond3" id="rdfssemcond3"></a>If
+ < x,y > is in IEXT(I(<code>rdfs:range</code>)) and < u,v > is
+ in IEXT(x) then v is in ICEXT(y)</p></td>
+ </tr>
+ <tr>
+
+ <td class="semantictable"><p><a name="rdfssemcond4" id="rdfssemcond4"></a>IEXT(I(<code>rdfs:subPropertyOf</code>))
+ is transitive and reflexive on IP</p></td>
+ </tr>
+ <tr>
+
+ <td class="semantictable"> <p><a name="rdfssemcond5" id="rdfssemcond5"></a>If
+ <x,y> is in IEXT(I(<code>rdfs:subPropertyOf</code>)) then x and
+ y are in IP and IEXT(x) is a subset of IEXT(y)</p></td>
+ </tr>
+ <tr>
+
+ <td class="semantictable"><p><a name="rdfssemcond6" id="rdfssemcond6"></a>If
+ x is in IC then < x, I(<code>rdfs:Resource</code>) > is in IEXT(I(<code>rdfs:subClassOf</code>))</p></td>
+ </tr>
+ <tr>
+
+ <td class="semantictable"><p><a name="rdfssemcond8" id="rdfssemcond8"></a>IEXT(I(<code>rdfs:subClassOf</code>))
+ is transitive and reflexive on IC</p></td>
+ </tr>
+
+ <td class="semantictable"> <p><a name="rdfssemcond7" id="rdfssemcond7"></a>If
+ < x,y > is in IEXT(I(<code>rdfs:subClassOf</code>)) then x and y are
+ in IC and ICEXT(x) is a subset of ICEXT(y)</p></td>
+ </tr>
+ <tr>
+
+
+ <tr>
+ <td class="semantictable"><p><a name="rdfssemcond9" 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>
+ </tr>
+ <tr>
+
+ <td class="semantictable"><p><a name="rdfssemcond10" id="rdfssemcond10"></a>If
+ 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>
+ </table>
+<p></p>
+<p></p>
+<p class="technote"> Several of the conditions in the above table can be understood as inference rules on RDF triples. For example,
+ the fifth condition could be stated as the rule: <em>if <code>xxx rdfs:domain yyy .</code> and <code>uuu xxx vvv .</code> then <code>uuu rdf:type yyy .</code></em>. However, this would not guarantee that un-named elements of the universe would satisfy these basic semantic conditions, which is necessary to ensure that these inference patterns are correct even when blank nodes are present. That is why the conditions are stated here in semantic terms directly, rather than as inference-rule patterns. Complete systems of such rules are given in ////.</p>
+
+
+
+ <p><a id="RDFS_axiomatic_triples" name="RDFS_axiomatic_triples"> </a>
+ </p>
+ <div class="title">RDFS axiomatic triples.</div>
+ <table border="1" summary="RDFS axioms">
+
+ <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 name="axtripleforproof1" 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 name="axtripleforproof2" 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 />
+ rdf:XMLLiteral rdf:type rdfs:Datatype .<br />
+ rdf:XMLLiteral rdfs:subClassOf rdfs:Literal . <br />
+ rdf:HTML rdf:type rdfs:Datatype .<br />
+ rdf:HTML rdfs:subClassOf rdfs:Literal . <br />
+ xsd:string rdf:type rdfs:Datatype .<br />
+ xsd:string rdfs:subClassOf rdfs:Literal . <br />
+ rdf:langString rdf:type rdfs:Datatype .<br />
+ rdf:langString rdfs:subClassOf rdfs:Literal . <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> </td>
+ </tr>
+
+ </table>
+<p><span >Since I is an <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>, the first condition implies that IP
+ = ICEXT(I(<code>rdf:Property</code>)).</span></p>
+
+<p class="issue">Is rdf:langString an rdfs:Datatype? </p>
+
+<p>These axioms and conditions have some redundancy. For example, all but one
+ of the RDF axiomatic triples can be derived from the RDFS axiomatic triples
+ and the semantic conditions on ICEXT,<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>
+ <div class="title">Some rdfs-valid triples.</div>
+<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>
+</table>
+
+<p class="technote">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>
+<p><br />
+ RDFS allows <a href="#defDatatype" class="termref">datatype</a>s to
+ have class extensions, so they are considered to be classes. The members of a datatype class are the datatype values which are in the range of the datatype L2V mapping: ICEXT(I(ddd)) = { x : x = L2V(I(ddd))(sss) } for some string sss, when ddd is a recognized datatype IRI.
+
+</p>
+<h3><a name="ExtensionalDomRang" id="ExtensionalDomRang"></a>4.2 Extensional Semantic
+ Conditions (Informative)</h3>
+<p>The semantics given above is deliberately chosen to be the weakest 'reasonable'
+ interpretation of the RDFS vocabulary. Semantic extensions <strong title="MAY in RFC 2119 context" class="RFC2119">MAY</strong>
+ strengthen the range, domain, subclass and subproperty semantic conditions to
+ the following '<a class="termref" href="#glossExtensional">extensional</a>'
+ versions:</p>
+ <div class="title">Extensional alternatives for some RDFS semantic conditions.</div>
+<table summary="range and domain extension conditions" border="1">
+ <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>
+</table>
+<p>which would guarantee that the subproperty and subclass properties were transitive
+ and reflexive, and would also have further consequences. </p>
+<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>
+<h3><a name="literalnote" id="literalnote">4.3 A Note on rdfs:Literal</a> </h3>
+
+ <p>The class <code>rdfs:Literal</code> is not the class of literals, but rather that of literal <em>values</em>. For example, if the vocabulary contains the literal <code>"24"^^xsd:number</code>, then LV does not contain this literal (although it may contain the string '<code>"24"^^http://www.w3.org/2001/XMLSchema#number</code>' ) but it does contain the number twenty-four.</p>
+
+ <p>A triple of the form</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. It does not, of course, specify exactly which
+ literal value it refers to. Similarly, blank nodes may range over literal values. </p>
+
+
+<h3><a name="rdfs_entailment" id="rdfs_entailment"></a>4.4 RDFS Entailment</h3>
+<p>S <i>rdfs-entails</i> E when every <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a>
+ which satisfies every member of S also satisfies E. This follows the wording
+ of the definition of <a href="#defentail" class="termref">simple entailment</a>
+ in <a href="#entail" class="termref"> Section 2</a>, but refers only to <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a>s
+ instead of all simple interpretations. <span >Rdfs-entailment is an example
+ of <a href="#vocabulary_entail" class="termref">vocabulary entailment</a>.</span>
+</p>
+<p> Since every <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a> is an <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>, if S rdfs-entails
+ E then it rdf-entails E; but rdfs-entailment is stronger than rdf-entailment.
+ Even the empty graph has a large number of rdfs-entailments which are not rdf-entailments,
+ for example all triples of the form </p>
+<p> <code>xxx rdf:type rdfs:Resource .</code></p>
+<p>are true in all <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a>s
+ of any vocabulary containing the IRI <code>xxx</code>.</p>
+
+
+<h3><a name="RDFSdtype_interp" id="RDFSdtype_interp">RDFS with datatypes</a></h3>
+
+ <p >As noted above, it is
+ possible that a graph which is consistent in one vocabulary becomes inconsistent
+ in a semantic extension defined on a larger vocabulary, and <a href="#defDinterp" class="termref">D-interpretation</a>s
+ allow for inconsistencies in an RDF graph. The definition of <a href="#vocabulary_entail" class="termref">vocabulary entailment</a>
+ means that an inconsistent graph will entail <em>any</em> graph in the stronger
+ vocabulary entailment. For example, a D-inconsistent graph <a href="#D_entailment" class="termref"> D-entail</a>s any RDF
+ graph. However, it will usually not be appropriate to consider such 'trivial'
+ entailments as useful consequences, since they may not be <a href="#glossValid"
+ class="termref">valid</a> entailments in a smaller vocabulary. </p>
+<h2><a name="MonSemExt" id="MonSemExt"></a>6. 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 <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 name="GeneralMonotonicityLemma" 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 <a href="#defDatatypeMap" class="termref">datatype map</a>, 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>
+
+<h2><span ><a name="rules" id="rules"></a></span> Entailment
+ rules (Informative)</h2>
+
+<p class="issue"> 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. <br/> <br /><strong>Should this be a separate document? Should it be an appendix to this document?</strong> <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>
+
+<h2><a name="prf" id="prf">Appendix: Proofs of Lemmas (Informative)</a></h2>
+
+<h2><a name="tutorial" id="tutorial">Appendix: Idiot's Guide to model theory (Informative)</h2>
+
+
+<h2><a name="gloss" id="gloss"></a>Appendix: Glossary of Terms (Informative)</h2>
+
+<p class="issue">This whole glossary should probably be made part of the Idiot's Guide. </p>
+
+ <p><strong><a name="glossAntecedent"
+ 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 name="glossAssertion"
+ 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 name="glossClass" 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, as <a
+ href="#technote">explained earlier</a>.)</p>
+<p><strong><a name="glossComplete"
+ 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 name="glossConsequent"
+ 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 name="glossConsistent"
+ 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 name="glossCorrect"
+ 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 name="glossDecideable" id="glossDecideable"></a>Decideable</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 decideable 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 decideable,
+ and decideable inference systems may have arbitrarily high computational complexity.
+ The relationships between logical syntax, semantics and complexity of an inference
+ system continue to be the subject of considerable research.)</p>
+
+ <p><strong><a name="glossEntail"
+ 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 name="glossEquivalent"
+ 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 name="glossExtensional"
+ 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 name="glossFormal"
+ 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 name="glossIff" id="glossIff"></a>Iff</strong>
+ (conj.) Conventional abbreviation for 'if and only if'. Used to
+ express necessary and sufficient conditions.</p>
+<p><a name="glossInconsistent"
+ 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 name="glossIndexical"
+ 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 name="glossInference"
+ 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 name="glossIntensional"
+ 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 name="glossInterpretation"
+ 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 a <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 name="glossLogic" id="glossLogic"></a>Logic</strong>
+ (n.) A formal language which expresses <a href="#glossProposition"
+ class="termref">propositions</a>.</p>
+
+ <p><a name="glossMetaphysical"
+ id="glossMetaphysical"></a><strong>Metaphysical</strong> (adj.).
+ Concerned with the true nature of things in some absolute or
+ fundamental sense.</p>
+
+ <p><a name="glossModeltheory"
+ 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 name="glossMonotonic"
+ 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 name="glossNonmonotonic"
+ 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 name="glossOntological"
+ 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 name="glossProposition"
+ 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 name="glossReify" 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 name="glossResource"
+ 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 name="glossSatisfy"
+ 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 name="glossSemantic"
+ 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 name="glossSkolemization" id="glossSkolemization"></a><a
+ href="#skolemlemprf"><strong>Skolemization</strong></a> (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 name="glossToken" 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 name="glossUniverse"
+ 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 name="glossUse" 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 name="glossValid" 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><a name="glossWellformed"
+ id="glossWellformed"></a><strong>Well-formed</strong> (adj., of an
+ expression). Syntactically legal.</p>
+
+ <p><strong><a name="glossWorld" 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>
+
+
+<h2><a name="ack" id="ack"></a>Appendix C: Acknowledgements</h2>
+<p>This document reflects the joint effort of the members of the <a
+ href="http://www.w3.org/2001/sw/RDFCore/">RDF Core Working Group</a>. Particular
+ contributions were made by Jeremy Carroll, Dan Connolly, Jan Grant, R. V. Guha,
+ Graham Klyne, Ora Lassilla, Brian McBride, Sergey Melnick, Jos deRoo and Patrick
+ Stickler. </p>
+
+ <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>Peter Patel-Schneider and Herman ter Horst found several major problems in
+ earlier drafts, and suggested several important technical improvements.</p>
+<p>Patrick Hayes' work on this document was supported in part by DARPA under contract
+ #2507-225-22. </p>
+<h2><a name="refs" id="refs">References</a></h2>
+<h2><a name="normative" id="normative">Normative</a></h2>
+
+
+<dl>
+
+ <dt><a id="ref-rdf-concepts"
+ name="ref-rdf-concepts"></a>[RDF-CONCEPTS]</dt>
+<dd><cite><a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/">Resource Description Framework (RDF): Concepts and Abstract Syntax</a></cite>, Graham Klyne and Jeremy J. Carroll, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ . <a href="http://www.w3.org/TR/rdf-concepts/">Latest version</a> available at http://www.w3.org/TR/rdf-concepts/ .</dd>
+
+
+ <dt><a id="ref-rdf-syntax"
+ name="ref-rdf-syntax"></a>[RDF-SYNTAX]</dt>
+<dd><cite><a href="http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/">RDF/XML Syntax Specification (Revised)</a></cite>, Dave Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ . <a href="http://www.w3.org/TR/rdf-syntax-grammar/">Latest version</a> available at http://www.w3.org/TR/rdf-syntax-grammar/ .</dd>
+
+ <dt><a id="ref-rdf-tests"
+ name="ref-rdf-tests"></a>[RDF-TESTS]</dt>
+<dd><cite><a href="http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/">RDF Test Cases</a></cite>, Jan Grant and Dave Beckett, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/ . <a href="http://www.w3.org/TR/rdf-testcases/">Latest version</a> available at http://www.w3.org/TR/rdf-testcases/ .</dd>
+
+
+ <dt><a name="ref-rdfms" id="ref-rdfms"></a>[RDFMS]</dt>
+ <dd> <cite><a href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/">Resource
+ Description Framework (RDF) Model and Syntax Specification</a></cite> , O.
+ Lassila and R. Swick, Editors. World Wide Web Consortium. 22 February 1999.
+ This version is http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/. The <a href="http://www.w3.org/TR/REC-rdf-syntax/">latest
+ version of RDF M&S</a> is available at http://www.w3.org/TR/REC-rdf-syntax/.
+ </dd>
+ <dt><a id="ref-2119" name="ref-2119"></a>[RFC 2119]</dt>
+ <dd> <cite><a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119 - Key words
+ for use in RFCs to Indicate Requirement Levels</a></cite> , S. Bradner, IETF.
+ March 1997. This document is http://www.ietf.org/rfc/rfc2119.txt. </dd>
+ <dt><a name="ref-2369" id="ref-2369"></a>[RFC 2396]</dt>
+ <dd><cite><a href="http://www.isi.edu/in-notes/rfc2396.txt">RFC 2396 - Uniform
+ Resource Identifiers (URI): Generic Syntax</a></cite> Berners-Lee,T., Fielding
+ and Masinter, L., August 1998</dd>
+ <dt><a id="ref-xmls" name="ref-xmls"></a>[XSD]</dt>
+ <dd><cite><a href="http://www.w3.org/TR/xmlschema-2/">XML Schema Part 2: Datatypes</a></cite>,
+ Biron, P. V., Malhotra, A. (Editors) World Wide Web Consortium Recommendation,
+ 2 May 2001</dd>
+</dl>
+
+ <h2><a name="nonnormative" id="nonnormative">Non-Normative</a></h2>
+<dl>
+<dt><a name="ref-owl" id="ref-owl"></a>[OWL]</dt>
+<dd><cite><a href="http://www.w3.org/TR/2004/REC-owl-ref-20040210/">OWL Web Ontology Language Reference</a></cite>, Mike Dean and Guus Schreiber, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-ref-20040210/ . <a href="http://www.w3.org/TR/owl-ref/">Latest version</a> available at http://www.w3.org/TR/owl-ref/ .</dd>
+
+ <dt><a id="ref-ConKla"
+ name="ref-ConKla"></a>[Conen&Klapsing]</dt>
+ <dd><cite><a
+ href="http://nestroy.wi-inf.uni-essen.de/rdf/logical_interpretation/index.html">
+ A Logical Interpretation of RDF</a></cite>, Conen, W., Klapsing, R..Circulated
+ to <a
+ href="http://lists.w3.org/Archives/Public/www-rdf-interest/2000Aug/0122.html">
+ RDF Interest Group</a>, August 2000.</dd>
+ <dt><a name="ref-daml" id="ref-daml">[DAML]</a></dt>
+ <dd>Frank van Harmelen, Peter F. Patel-Schneider, Ian Horrocks (editors), <a
+ href="http://www.daml.org/2001/03/reference.html"><em>Reference Description
+ of the DAML+OIL (March 2001) ontology markup language</em></a></dd>
+ <dt><a id="ref-HayMen"
+ name="ref-HayMen"></a>[Hayes&Menzel]</dt>
+ <dd><cite><a
+ href="http://reliant.teknowledge.com/IJCAI01/HayesMenzel-SKIF-IJCAI2001.pdf">
+ A Semantics for the Knowledge Interchange Format</a></cite>, Hayes, P., Menzel,
+ C., Proceedings of 2001 <a
+ href="http://reliant.teknowledge.com/IJCAI01/">Workshop on the IEEE Standard
+ Upper Ontology</a>, August 2001.</dd>
+ <dt><a name="ref-KIF" id="ref-KIF">[KIF]</a></dt>
+ <dd>Michael R. Genesereth et. al., <a
+ href="http://logic.stanford.edu/kif/dpans.html"><em>Knowledge Interchange
+ Format</em></a>, 1998 (draft American National Standard).</dd>
+ <dt><a id="ref-MarSaa"
+ name="ref-MarSaa"></a>[Marchiori&Saarela]</dt>
+ <dd><cite><a
+ href="http://www.w3.org/TandS/QL/QL98/pp/metalog.html">Query + Metadata
+ + Logic = Metalog</a></cite>, Marchiori, M., Saarela, J. 1998.</dd>
+ <dt><a id="ref-Lbase" name="ref-Lbase"></a>[LBASE]</dt>
+ <dd><cite><a href="http://www.w3.org/TR/2003/NOTE-lbase-20031010/">Lbase: Semantics
+ for Languages of the Semantic Web</a></cite>, Guha, R. V., Hayes, P., W3C
+ Note, 10 October 2003.</dd>
+ <dt><a id="ref-daml-axiomat"
+ name="ref-daml-axiomat"></a>[McGuinness&al]</dt>
+ <dd><cite><a
+ href="http://www.ksl.stanford.edu/people/dlm/papers/daml-oil-ieee-abstract.html">
+ DAML+OIL:An Ontology Language for the Semantic Web</a></cite>, McGuinness,
+ D. L., Fikes, R., Hendler J. and Stein, L.A., IEEE Intelligent Systems, Vol.
+ 17, No. 5, September/October 2002.</dd>
+
+
+ <dt><a id="ref-rdf-primer" name="ref-rdf-primer">[RDF-PRIMER]</a>
+ </dt>
+<dd><cite><a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">RDF Primer</a></cite>, Frank Manola and Eric Miller, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-primer-20040210/ . <a href="http://www.w3.org/TR/rdf-primer/">Latest version</a> available at http://www.w3.org/TR/rdf-primer/ .</dd>
+
+
+
+ <dt><a id="ref-rdf-vocabulary"
+ name="ref-rdf-vocabulary"></a>[RDF-VOCABULARY]</dt>
+
+<dd><cite><a href="http://www.w3.org/TR/2004/REC-rdf-schema-20040210/">RDF Vocabulary Description Language 1.0: RDF Schema</a></cite>, Dan Brickley and R. V. Guha, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ . <a href="http://www.w3.org/TR/rdf-schema/">Latest version</a> available at http://www.w3.org/TR/rdf-schema/ .</dd>
+
+
+ </dl>
+ <hr />
+
+
+<h2><a id="changes" name="changes"></a><a name="change" id="change"></a>Appendix D: Change Log. (Informative)</h2>
+<p><strong>Changes since the <a href="http://www.w3.org/TR/2003/PR-rdf-mt-20031215/">15 December 2003 Proposed Recommendation</a>.</strong></p>
+<p>An error in the wording of the RDFS entailment lemma in appendix A was corrected.
+ Some typos in the glossary and main text were corrected.</p>
+<p>After considering <a href="http://lists.w3.org/Archives/Public/www-rdf-comments/2003OctDec/0233.html">comments
+ by ter Horst</a>, the definition of D-interpretation has been modified so as
+ to apply to an extended vocabulary including the datatype names. </p>
+<p>Older entries in the change log were removed. They can be found in <a href="http://www.w3.org/TR/2003/PR-rdf-mt-20031215/#change">the previous version.</a></p>
+
+<hr />
+
+<div class="metadata">
+ <p><a href="metadata.rdf"><img
+ src="http://www.w3.org/RDF/icons/rdf_metadata_button.40"
+ alt="RDF/XML Metadata" /></a></p>
+ <p>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-xhtml10"
+ alt="Valid XHTML 1.0!" height="31" width="88" /></a>
+ </p>
+ <p>
+ <a href="http://jigsaw.w3.org/css-validator/">
+ <img style="border:0;width:88px;height:31px"
+ src="http://jigsaw.w3.org/css-validator/images/vcss"
+ alt="Valid CSS!"/>
+ </a>
+</p>
+ </div>
+ </body>
+</html>
+