--- a/rdf-mt/index.html Tue Mar 12 17:22:36 2013 -0700
+++ b/rdf-mt/index.html Tue Mar 12 21:51:54 2013 -0500
@@ -1,597 +1,140 @@
-
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">
-<!-- saved from url=(0053)http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/ -->
-<html dir="ltr" about="" property="dcterms:language" content="en" xmlns="http://www.w3.org/1999/xhtml" prefix="bibo: http://purl.org/ontology/bibo/" typeof="bibo:Document"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
-
- <title>RDF 1.1 Semantics Editors Draft</title>
- <style type="text/css">
-.figure { text-align: center; }
-.figure a[href]:hover { background: transparent; }
-table td, table th { border: 1px solid #ddd; padding: 0.2em 0.5em; }
- </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 3em 0em;
- padding: 1em;
- border: 1px solid #F00;
- background: #ccccff;
-}
+<!DOCTYPE html>
+<html>
+ <head>
+ <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
+ <title>RDF 1.1 Semantics</title>
+
+ <script src='../ReSpec.js/js/respec.js' class='remove'></script>
+ <script class='remove'>
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "ED",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ //shortName: "xxx-xxx",
-.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;
- }
-}
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ // subtitle : "an excellent document",
-/* --- 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; }
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2009-08-06",
-/* 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; }
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ copyrightStart: "2004",
-/* 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; }
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ // previousPublishDate: "1977-03-15",
+ // previousMaturity: "WD",
-/* 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; }
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html",
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+prevRecShortname: "rdf-mt",
-a.termref:visited, a.termref:link {font-family: sans-serif;
- font-style: normal;
- color: black;
- text-decoration: none }
-.RFC2119 { font-size: small; font-weight: bolder; }
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Patrick J. Hayes", url: "http://www.ihmc.us/groups/phayes/",
+ company: "Florida IHMC", companyURL: "http://www.ihmc.us/index.php" },
+ { name: "Peter F. Patel-Schneider",
+ company: "Nuance Communications", companyURL: "http://www.nuance.com/" },
+ { name: "David Wood",
+ company: "3 Round Stones", companyURL: "http://3roundstones.com/",
+note: "Series Editor", },
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ //authors: [
+ // { name: "Your Name", url: "http://example.org/",
+ // company: "Your Company", companyURL: "http://example.com/" },
+ //],
+
+ // name of the WG
+ wg: "RDF Working Group",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2011/rdf-wg/",
+
+ // name (without the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-rdf-comments",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "",
+ };
+ </script>
+<style type="text/css">
.semantictable {background-color: #FFFFAA}
.ruletable {background-color: #DDDDFF}
.othertable {background-color: #FDFDFD}
-
-
+.tabletitle {font-size: small; font-weight: bolder;}
+.technote {font-size:small; background: #ccccff;}
+.changenote {font-size: small; background: #ffccff;}
</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/"></a></p>
-<h1 property="dcterms:title" class="title" id="title">RDF 1.1 Semantics</h1>
-<h2 property="dcterms:issued" datatype="xsd:dateTime" content="2013-03-08T00:00:00+0000" id="w3c-working-draft-7-March-2013"> Editor's Working Draft 8 March 2013</h2><dl><dt>This version:</dt><dd><a href="https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html">https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html</a></dd><dt>Latest 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="http://www.nuance.com/">Nuance Communications</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>
-
+ </head>
+ <body>
+ <section id='abstract'>
+ <p> This document describes a precise semantics for the Resource Description
+ Framework 1.1 [[!]] and RDF Schema [[!RDF-SCHEMA]]. It defines a number of distinct entailment regimes and corresponding systems of inference rules. It is part of a suite of documents which comprise the full specification of RDF 1.1.</p>
+<p>This is a revision of the 2004 RDF Semantics specification for RDF [[!RDF-MT]] and supersedes that document. </p> </section>
+ <section class='introductory'><h2>Notes</h2>
+<p class='changenote'>Notes in this style indicate changes from the 2004 RDF semantics.</p>
+<p class='technote'>Notes in this style are technical asides on obscure or recondite matters.</p></section>
+ <section>
+ <h2>Introduction</h2>
+ <p>
+ This document defines a model-theoretic semantics for RDF graphs and the RDF and RDFS vocabularies, providing an exact formal specification of when truth is preserved by transformations of RDF, or operations which derive RDF content from other RDF. Readers who are unfamiliar with model theory can find a brief introduction to the basic ideas and terminology in <a>Appendix A</a>, and may find the informative section 13 useful. </p>
+<p>This specification is normative for RDF <a>formal</a> semantics. However, there are many aspects of RDF meaning which are not covered by this semantics, including social issues of how IRIs are assigned meanings in use, and how the referents of IRIs are related to Web content expressed in other media such as natural language texts. Accounts of such extended notions of meaning will go beyond this specification, but MUST NOT violate the conditions described here. </p>
+ </section>
+
+ <section>
+ <h2>Semantic extensions and entailment regimes</h2>
+ <p>RDF is intended for use as a base notation for a variety of extended notations such as OWL [[OWL-GUIDE]] and RIF [[RIF-OVERVIEW]], whose expressions can be encoded as RDF graphs which use a particular vocabulary with a specially defined meaning. Also, particular IRI vocabularies may impose user-defined meanings upon the basic RDF meaning rules. When such extra meanings are assumed, a given RDF graph may support more extensive entailments than are sanctioned by the basic RDF semantics. In general, the more assumptions that are made about the meanings of IRIs in an RDF graph, the more valid entailments it has. </p>
-<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>
-
-
- <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>A particular such set of semantic assumptions is called a <dfn>semantic extension</dfn>. Each semantic extension defines an <dfn>entailment regime</dfn> of entailments which are valid under that extension. RDFS, described later in this document, is one such semantic extension. We will refer to an entailment regime by names such as <em>rdfs-entailment</em>, <em>D-entailment</em>, etc.. </p>
-<p>This document defines a model-theoretic semantics for RDF graphs and the RDF and RDFS vocabularies, providing an exact formal specification of when truth is preserved by transformations of RDF, or operations which derive RDF content from other RDF. Readers who are unfamiliar with model theory can find a brief introduction to the basic ideas and terminology in Appendix ////, and may find the informative section //// useful. </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 //ref// and RIF //ref//, whose expressions can be encoded as RDF graphs which use a particular vocabulary with a specially defined 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 the meanings of IRIs in an RDF graph, the more valid entailments it has. </p>
+<p>Semantic extensions MAY impose special syntactic conditions or restrictions upon RDF graphs, such as requiring certain triples to be present, or prohibiting particular combinations of IRIs in triples, and MAY consider RDF graphs which do not conform to these conditions to be errors. For example, RDF statements of the form <br />
+<code>:a rdfs:subClassOf owl:Thing .</code><br />
+are prohibited in the OWL-DL [[OWL-REF]] semantic extension. In such cases, basic RDF operations such as taking a subset of triples, or merging RDF graphs, may cause syntax errors in parsers which recognize the extension conditions. None of the semantic extensions normatively defined in this document impose syntactic restrictions on RDF graphs.</p>
-<p>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 names such as <em>rdfs-entailment</em>, <em>owl-entailment</em>, etc.. </p>
+<p>All entailment regimes MUST be <a>monotonic</a> extensions of the simple entailment regime described in the next section, in the sense that if A simply entails B then A also entails B under any extended notion of entailment, provided of course that any syntactic conditions of the extension are also satisfied. Put another way, a semantic extension cannot "cancel" an entailment made by a weaker entailment regime, although it can treat the result as a syntax error.</p>
+ </section>
-<p>Semantic extensions <strong class="RFC2119">MAY</strong> impose special syntactic conditions or restrictions upon RDF graphs, such as requiring certain triples to be present, or prohibiting particular combinations of IRIs in triples, and <strong class="RFC2119">MAY</strong> consider RDF graphs which do not conform to these conditions to be errors. For example, RDF statements of the form <br />
-<code>:a rdfs:subClassOf owl:Thing .</code><br />
-are prohibited in the OWL-DL semantic extension. In such cases, basic RDF operations such as taking a subset of triples, or merging RDF graphs, may cause syntax errors in parsers which recognize the extension conditions.</p><p> None of the semantic extensions normatively defined in this document impose syntactic restrictions on RDF graphs.</p>
+ <section>
+ <h2>Notation and terminology</h2>
-<p>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, provided of course that any syntactic conditions of the extension are also satisfied. Put another way, a semantic extension cannot "cancel" an entailment made by a weaker entailment regime, although it can treat the result as a syntax error.</p>
+<p class="issue">This section needs cleaning up. Some of the 2004 definitions may no longer be needed. The notions of instance and equivalence may (?) need to be stated more carefully taking bnode scopes into account. Instance mappings should be defined on a whole scope rather than a graph (?). The definitions involving bnode scopes and complete graphs are new. <br/><br/> Maybe some of the material should be in Concepts. </p>
-<h1>Notation and terminology</h1>
-
-<p>This document uses the terminology ///list terms/// defined in //Concepts// for describing RDF graph syntax.</p>
+ <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
+ which state semantic conditions, tables containing true assertions and <a>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
+ identity. The statement "A = B" means that there is one entity which both expressions "A" and "B" refer to. Angle brackets < x, y > are used to indicate an ordered pair
of x and y. RDF graph syntax is indicated using the notational conventions of
the <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
+ in the RDF test cases document [[!RDF-TESTCASES]]
+ literal strings are enclosed within double quote marks and attached to a type IRI using a double-caret <code>^^</code>, language tags indicated
by the use of the <code>@</code> sign, and triples terminate with a 'code dot'
<code>.</code> . </p>
<p>In stating general rules or conditions we will use the following conventions:<br />
@@ -600,92 +143,85 @@
lll or mmm indicates a literal<br />
_:xxx or _:yyy indicates a blank node. <br /></p>
-<p class=issue> Need more on 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>A <dfn>name</dfn> is any IRI or literal. A <dfn>vocabulary</dfn> is a set of names.
</p>
-<p class="issue">This rest of this section is lifted almost verbatim from the 2004 document. Some of these definitions may not be needed. This will be cleaned up in a final edit.<br/><br/>
-The notions of instance and equivalence may (?) need to be stated more carefully taking bnode scopes into account. Instance mappings should be defined on a whole scope rather than a graph?.
-<p><a name="defgraph" id="defgraph">An <span > <a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-rdf-graph"><em>RDF
- graph</em></a></span>, or simply a <em>graph</em>, is a set of RDF triples.</a></p>
-<p><a name="defsubg" id="defsubg">A <i>subgraph</i> of an RDF graph is a subset
- of the triples in the graph.</a> A triple is identified with the singleton set
+<p>An <a class="externalDFN">RDF
+ graph</a>, or simply a <dfn>graph</dfn>, is a set of RDF triples.</p>
+<p>A <dfn>subgraph</dfn> of an RDF graph is a subset
+ of the triples in the graph. A triple is identified with the singleton set
containing it, so that each triple in a graph is considered to be a subgraph.
- A <em>proper</em> subgraph is a proper subset of the triples in the graph. </p>
+ A <dfn>proper subgraph</dfn> is a proper subset of the triples in the graph. </p>
-<p><a name="defgd" id="defgd">A <em>ground</em> RDF graph is one with no blank
- nodes.</a></p>
+<p>A <def>ground</def> RDF graph is one with no blank
+ nodes.</p>
-<p><a name="defname" id="defname">A <em>name</em> is an IRI or a literal.</a>
+<p>A <dfn>name</dfn> is an IRI or a literal.
Note that a typed literal comprises
- two <a href="#defname" class="termref">name</a>s: itself and its internal type
+ two <a>name</a>s: itself and its internal type
IRI. </p>
-<p><a name="defvocab" id="defvocab"></a> A set of <a href="#defname" class="termref">name</a>s
- is referred to as a <i>vocabulary</i>. The vocabulary <em>of</em> a graph is
+<p>A <dfn>vocabulary</dfn> is a set of <a>name</a>s. The <def>vocabulary of</def> a graph is
the set of names which occur as the subject, predicate or object of any triple
in the graph. IRIs which occur only inside typed literals
are not required to be in the vocabulary of the graph.</p>
-<p><a name="definst" id="definst"> Suppose that M is a functional mapping from a set of blank
+<p>Suppose that M is a functional mapping from a set of blank
nodes to some set of literals, blank nodes and IRIs. Any graph obtained
from a graph G by replacing some or all of the blank nodes N in G by M(N) is
- an <em>instance</em> of G.</a> Any graph is an instance of itself,
+ an <dfn>instance</dfn> of G. Any graph is an instance of itself,
an instance of an instance of G is an instance of G,
- and if H is an instance of G then every triple in H is an instance of some triple
+ and if H is an instance of G then every triple in H is an instance of at least one triple
in G.</p>
-<p><a name="definstvoc" id="definstvoc">An instance <i>with respect to a vocabulary</i>
- V </a>is an <a href="#definst" class="termref">instance</a> in which all the
- <a href="#defname" class="termref">name</a>s in the instance that were substituted
- for blank nodes in the original are <a href="#defname" class="termref">name</a>s
+<p>An <dfn>instance with respect to</dfn> a vocabulary
+ V </a>is an <a>instance</a> in which all the
+ <a>name</a>s in the instance that were substituted
+ for blank nodes in the original are <a>name</a>s
from V.</p>
-<p><a name="defpropinst" id="defpropinst">A <i>proper</i> instance</a> of a graph
- is an instance in which a blank node has been replaced by a name, or two blank
+<p>A <dfn>proper instance</dfn> of a graph
+ is an <a>instance</a> in which a blank node has been replaced by a name, or two blank
nodes in the graph have been mapped into the same node in the instance. </p>
-<p >Any instance of a graph in which a blank node is mapped to a new blank node
+<p >Any <a>instance</a> of a graph in which a blank node is mapped to a new blank node
not in the original graph is an instance of the original and also has it as
an instance, and this process can be iterated so that any 1:1 mapping between
blank nodes defines an instance of a graph which has the original graph as an
instance. Two such graphs, each an instance of the other but neither a proper
instance, which differ only in the identity of their blank nodes, are considered
- to be <a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-graph-equality">equivalent</a>.
- We will often treat such equivalent graphs as identical. Equivalent graphs are mutual instances with an invertible instance
- mapping.</p>
-<p ><span ><a id="deflean"
- name="deflean">An RDF graph is <em>lean</em> if it has no instance which is
- a proper subgraph of the graph.</a> Non-lean graphs have internal redundancy
+ to be <dfn>equivalent</dfn>. Equivalent graphs are mutual instances with an invertible instance
+ mapping. As blank nodes have no particular identity beyond their location in a graph, we treat such equivalent graphs as identical.</p>
+<p >An RDF graph is <dfn>lean</dfn> if it has no instance which is
+ a proper subgraph of the graph. Non-lean graphs have internal redundancy
and express the same content as their lean subgraphs. For example, the graph</span></p>
<p ><code><ex:a> <ex:p> _:x .<br />
_:y <ex:p> _:x .</code></p>
-<p >is not <a
- href="#deflean" class="termref">lean</a>, but</p>
+<p >is not lean, but</p>
<p ><code><ex:a> <ex:p> _:x .<br />
_:x <ex:p> _:x .</code></p>
-<p >is <a
- href="#deflean" class="termref">lean</a>. </p>
-
-<p>Blank nodes in RDF graphs are restricted to a single <em>scope</em> of blank node identifiers. Each blank node can occur in only one scope. The same blank node identifier used in a several scopes identifies a different blank node in each scope in which it occurs. Scopes are defined by the surface syntax used to encode RDF. For example, in RDF/XML and NTriples, the scope is defined by the document. In TriG, a syntax for RDF datastores, the scope is the entire datastore. Two graphs not in the same scope do not share any blank nodes.</p>
+<p >is lean. </p>
-<p>The set of all triples in a given scope is an RDF graph, called a <em>scoped graph</em>. (The scoped graph may be an abstraction, e.g. for a dataset it is the set of all triples which occur in any graph in the dataset, which may not be represented explicitly in the dataset itself.) Every RDF graph must be a subgraph of a scoped graph. </p>
+<p>Blank nodes in RDF graphs are restricted to a single <a class="externalDFN">scope</a> of blank node identifiers. Each blank node can occur in only one scope. The same blank node identifier used in a several scopes identifies a different blank node in each scope in which it occurs. Scope boundaries are defined by the surface syntax used to encode RDF. For example, in RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and NTriples [[!RDF-TESTCASES]], the scope is defined by the document. In TriG, [[a trig reference]] a syntax for RDF datastores, the scope is the entire datastore. Two graphs not in the same scope do not share any blank nodes.</p>
-<p>An RDF graph is <em>complete</em> when, for every blank node in the graph, the graph contains all triples in the scoped graph which contain that blank node. That is, for every blank node in the scope, the graph either does not contain the blank node, or else it contains all triples in the scoped graph which contain that blank node. Scoped graphs and ground graphs are always complete. Incomplete graphs may fail to give enough information to reconstruct the information contained in their union.</p>
+<p>The set of all triples in a given scope is an RDF graph, called a <dfn>scoped graph</dfn>. (The scoped graph may be an abstraction, e.g. for a dataset it is the set of all triples which occur in any graph in the dataset, which might not be represented explicitly in the dataset itself.) Every RDF graph must be a subgraph of a scoped graph. </p>
-<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 of the 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, and treating this as the scoped graph of a single blank node scope. 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. (We may describe this as "making a copy" of the triples in the original graphs, when the new scope is distinct from the scopes containing the original graphs.)</p>
+<p>An RDF graph is <dfn>complete</dfn> when, for every blank node in the graph, the graph contains all triples in the scoped graph which contain that blank node. That is, for every blank node in the scope, the graph either does not contain the blank node, or else it contains all triples in the scoped graph which contain that blank node. Scoped graphs and ground graphs are always complete. Non-complete graphs may fail to give enough information to reconstruct the information contained in their union.</p>
-<p class="changenote"> The 2004 RDF 1.0 specification did not define a notion of blank node scope, so allowed the 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 blank node identifiers 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. Since 2004, in subsequent practice, the term "RDF graph" is widely used to mean what is here defined as a scoped graph. </p>
+<p>Any set of graphs can be treated as a single graph simply by taking the union of the sets of triples. If two or more of the graphs 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 should 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, and treating this as the scoped graph of a single blank node scope. We will refer to this process of forming the union of graphs as <dfn>merging</dfn>, and to the union graph as the <dfn>merge</dfn> of the original graphs. </p>
+
+<ul><li><p class="changenote"> The 2004 RDF 1.0 specification did not define a notion of blank node scope, so allowed the 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 blank node identifiers 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. Since 2004, in subsequent practice, the term "RDF graph" is widely used to mean what is here defined as a scoped graph. </p>
+</li></ul>
<p class="issue">The Concepts document does not yet define blank node scopes.</p>
-<h2><a id="sinterp" name="sinterp"> Simple Interpretations</a> </h2>
-
+ </section>
+ <section>
+ <h2> Simple Interpretations</h2>
+
+<p>A <dfn>simple interpretation</dfn> I is a structure consisting of:</p>
-<p>A simple interpretation I is a structure consisting of:</p>
-
-<div class="title">Definition of a simple interpretation.</div>
+<div class="tabletitle">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
@@ -699,27 +235,29 @@
</tr>
</table>
-<p class="changenote">The 2004 RDF 1.0 semantics defined interpretations relative to a vocabulary.</br></br>In the 2004 RDF 1.0 semantics, IL was a total, rather than partial, mapping.</br></br> The 2004 RDF 1.0 specification divided literals into 'plain' literals with no type and optional language tags, and typed literals. Usage has shown that it is important that every literal have a type. RDF 1.1 replaces plain literals without language tags by literals typed with the XML Schema <code>string</code> datatype, and introduces the special type <code>rdf:langString</code> for language-tagged strings. The full semantics for typed literals is given in the next section. </p>
-<p class="technote"> Interpretations are required to interpret all names, and are therefore infinite. This simplifies the exposition. However, RDF can be interpreted using finite structures, supporting decideable algorithms. Details are given in Appendix///. </p>
+<ul><li><p class="changenote">The 2004 RDF 1.0 semantics defined interpretations relative to a vocabulary.<br/><br/>In the 2004 RDF 1.0 semantics, IL was a total, rather than partial, mapping.<br/><br/> The 2004 RDF 1.0 specification divided literals into 'plain' literals with no type and optional language tags, and typed literals. Usage has shown that it is important that every literal have a type. RDF 1.1 replaces plain literals without language tags by literals typed with the XML Schema <code>string</code> datatype, and introduces the special type <code>rdf:langString</code> for language-tagged strings. The full semantics for typed literals is given in the next section. </p>
+
+</li><li><p class="technote"> Interpretations are required to interpret all names, and are therefore infinite. This simplifies the exposition. However, RDF can be interpreted using finite structures, supporting decidable algorithms. Details are given in Appendix ///. </p>
+</li></ul>
<p>IEXT(x), called
- the <a href="#defexten" class="termref"><i>extension</i></a> of x, is a
+ the <dfn>extension</dfn> of x, is a
set of pairs which identify the arguments for which the property is true,
that is, a binary relational extension.
</p>
<p>The distinction between IR and IL will become significant below when the semantics of datatypes are defined. IL is allowed to be partial because some literals may fail to have a referent. However, IL is total on language-tagged strings and literals of type <code>xsd:string</code>. </p>
-<p class="technote">
+<ul><li><p class="technote">
It is conventional to map a relation name to a relational extension directly. This however presumes that the vocabulary is segregated into relation names and individual names, and RDF makes no such assumption. Moreover, RDF allows an IRI to be used as a relation name applied to itself as an argument. Such self-application structures are used in RDFS, for example. The use of the IEXT mapping to distinguish the relation as an object from its relational extension accommodates both of these requirements. It also provides for a more intuitive notion of RDFS 'class' which can be distinguished from its set-theoretic extension.
</p>
-
+</li></ul>
<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>
+ <div class="tabletitle">Semantic conditions for ground graphs.</div>
<table cellpadding="5" border="2" summary="semantic conditions for RDF graphs">
<tbody>
@@ -748,24 +286,24 @@
</table>
-<p> If IL(E) is undefined for some literal E, then E has no semantic value, so any triple containing it must be false, so any graph containing that triple must also be false.</p>
+<p> If IL(E) is undefined for some literal E, then E has no semantic value, so any triple containing it will be false, so any graph containing that triple will also be false.</p>
<p> The final condition implies that the empty graph (empty set of triples) is always true.</p>
-<p>The sets IP and IR may overlap, indeed IP can be a subset of IR. Because of the domain conditions on IEXT, the denotation of the subject and object of any true triple 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 sets IP and IR may overlap, indeed IP can be a subset of IR. Because of the domain conditions on IEXT, the denotation of the subject and object of any true triple will be in IR; so any IRI which occurs in a graph both as a predicate and as a subject or object will denote something in the intersection of IP and IR.</p>
- <h3><a name="unlabel" id="unlabel">1.5. Blank Nodes</a></h3>
+ <h3>Blank Nodes</h3>
<p>Blank nodes are treated as simply indicating the existence of a thing, without using an IRI to identify any particular thing. They play a similar role to existentially quantified variables in a conventional logical notation. This is not the same as assuming that the blank node indicates an 'unknown' IRI.
</p>
-<p>The semantics of blank nodes is defined as a condition on all RDF triples in a single blank node scope. 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. Two graphs not in the same blank node scope do not share any blank nodes.</p>
+<p>The semantics of blank nodes is defined as a condition on all RDF triples in a single blank node scope. All blank nodes in an RDF graph must be in a single scope, but a scope might extend beyond a single graph. Two graphs not in the same blank node scope do not share any blank nodes.</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 ground graphs. </p>
- <div class="title">Semantic condition for blank nodes.</div>
+ <div class="tabletitle">Semantic condition for blank nodes.</div>
<table cellpadding="5" border="2" summary="Semantic conditions for blank nodes">
<tbody>
@@ -777,38 +315,36 @@
</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>
+<p>Mappings from blank nodes to referents are not part of the definition of an interpretation, since the truth condition refers only to <em>some</em> such mapping. Blank nodes themselves differ from other nodes in not being assigned a denotation by an interpretation, reflecting the intuition that they have no 'global' meaning outside the scope in which they occur.</p>
<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 things,</p><p>2. there is some way to interpret all the blank nodes in the scope as referring to things,</p><p>3. the IRIs in property position identify binary relationships,</p><p>4. and, under these interpretations, each triple S P O in the graph asserts that the thing referred to as S, and the thing referred to as O, do in fact stand in the relationship identified by P. </p>
-<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>
+<p>All semantic extensions of any vocabulary or higher-level notation encoded in RDF MUST conform to these minimal truth conditions. Other semantic extensions may extend and add to these, but they MUST NOT over-ride or negate them. </p>
-<h3>Simple Entailment</h3>
+ </section>
+<section><h2>Simple Entailment</h2>
<p class="issue">Should the 'explanatory' material in here be moved to the tutorial appendix? </p>
-<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
+<p>Following standard terminology, we say that I <dfn>satisfies</dfn> E when I(E)=true, and a set
+ S of RDF graphs <dfn>simply entails</dfn> a graph E when every interpretation
which satisfies every member of S also satisfies E. This means that it is always correct to infer E from S, even when one does not know what the names in the vocabulary actually mean. In later sections these notions will be adapted to other classes of interpretations, but throughout this section 'entailment' should be interpreted as meaning simple entailment.
</p>
- <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><a id="defvalid" name="defvalid">Any process which constructs a graph E from some other graph(s) S is said to be (simply) <dfn>valid</dfn> if S simply entails E in every case, otherwise <dfn>invalid.</dfn> </p>
-<p>The fact that an inference is valid should not be understood as meaning that the inference must be made, or that any process is obliged or required to make the inference; and similarly, the logical invalidity of some RDF transformation or process does not mean that the process is incorrect or prohibited. Nothing in this specification requires or prohibits any particular operations to be applied to RDF graphs. Entailment and validity are concerned solely with establishing the conditions on operations which guarantee the preservation of truth. While logically invalid processes which do not follow valid entailments are not prohibited, users should be aware that they may be at risk of introducing falsehoods and errors into otherwise correct RDF data. Nevertheless, particular uses of logically invalid processes may be justified and appropriate for data processing under circumstances where truth can be ensured by other means. </p>
+<p>The fact that an inference is valid should not be understood as meaning that the inference must be made, or that any process is obliged or required to make the inference; and similarly, the logical invalidity of some RDF transformation or process does not mean that the process is incorrect or prohibited. Nothing in this specification requires or prohibits any particular operations to be applied to RDF graphs. Entailment and validity are concerned solely with establishing the conditions on operations which guarantee the preservation of truth. While logically invalid processes, which do not follow valid entailments, are not prohibited, users should be aware that they may be at risk of introducing falsehoods and errors into otherwise correct RDF data. Nevertheless, particular uses of logically invalid processes may be justified and appropriate for data processing under circumstances where truth can be ensured by other means. </p>
-<p>Entailment refers only to the truth of RDF graphs, not to their suitability for any other purpose. It is possible for an RDF graph to be fitted for a given purpose and yet validly entail another graph which is not appropriate for the same purpose. An example is the RDF test cases manifest //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, the manifest validly entails a subgraph which omits the antecedents, and would therefore be incorrect if used as a test case manifest. This is not a violation of the RDF semantic rules, but it shows that the property of <em> "being a correct RDF test case manifest"</em> is not preserved under RDF entailment, and therefore cannot be described as an RDF semantic extension. Such entailment-risky uses of RDF should be restricted to cases, as here, where it is obvious to all parties what the intended special restrictions on entailment are, in contrast with the more normal case of using RDF for the open publication of data on the Web.</p>
+<p>Entailment refers only to the truth of RDF graphs, not to their suitability for any other purpose. It is possible for an RDF graph to be fitted for a given purpose and yet validly entail another graph which is not appropriate for the same purpose. An example is the RDF test cases manifest [[!RDF-TESTCASES]] which is provided as an RDF document for user convenience. This document lists examples of correct entailments by describing their antecedents and conclusions. Considered as an RDF graph, the manifest 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>
+ are given in <a>Appendix B</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>
@@ -846,8 +382,7 @@
<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
+ E is a <a>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
@@ -856,10 +391,10 @@
<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>
+</section>
-<h3>Skolemization</h3>
-
+<section><h2>Skolemization</h2>
<p>Skolemization is a transformation on RDF graphs which eliminates blank nodes by replacing them with "new" IRIs, which means IRIs which are coined for this purpose and are therefore guaranteed to not occur in any other RDF graph (at the time of creation). See ///Concepts#/// for a fuller discussion. </p>
<p> Suppose G is a graph containing blank nodes and sk is a skolemization mapping on the blank nodes in G, so that sk(G) is a skolemization of G. Then the semantic relationship between them can be summarized as follows. </p>
@@ -872,53 +407,33 @@
<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>
+<ul><li><p class=technote>The more general notion of skolemization involving Skolem functions is not used in RDF as there are no universal quantifiers.</p>
+</li></ul>
-
-<p></p>
-
-
-
+</section>
-<h3>Literals and datatypes</h3>
-
-<p class="changenote"> In the 2004 RDF 1.0 specification, datatype D-entailment was defined as a semantic extension of RDFS-entailment. Here it is defined as a direct extension to basic RDF. This is more in conformity with actual usage, where RDF with datatypes is widely used without the RDFS vocabulary. If there is a need to distinguish this from the 2004 RDF 1.0 terminology, the longer phrasing "simple D-entailment" or "simple datatype entailment" should be used rather than "D-entailment". </p>
+<section><h2>Literals and datatypes</h2>
+<ul><li><p class="changenote"> In the 2004 RDF 1.0 specification, datatype D-entailment was defined as a semantic extension of RDFS-entailment. Here it is defined as a direct extension to basic RDF. This is more in conformity with actual usage, where RDF with datatypes is widely used without the RDFS vocabulary. If there is a need to distinguish this from the 2004 RDF 1.0 terminology, the longer phrasing "simple D-entailment" or "simple datatype entailment" should be used rather than "D-entailment". </p>
+</li></ul>
-
-<p>RDF literals and datatypes are fully described in ///Concepts///. In summary: RDF literals are either language-tagged strings, or datatyped literals which
-combine a string and an IRI identifying a datatype. A datatype is understood to define a partial mapping, the <em>lexical-to-value mapping</em>, from character strings to values, and the literal refers to the value obtained by applying this mapping to the character string. If the mapping gives no value for the literal string, then the literal has no referent. The <em> value space</em> of a datatype is the range of the lexical-to-value mapping. Every literal with that type either refers to a value in the value space, or fails to refer at all. A literal whose datatype IRI is recognized, but whose character string is not in the domain of the datatype lexical-to-value mapping, is called <em>ill-typed</em>.
-Datatypes are indicated by IRIs.
+<p>RDF literals and datatypes are fully described in [[!Concepts]]. In summary: RDF literals are either language-tagged strings, or datatyped literals which
+combine a string and an IRI identifying a datatype. A datatype is understood to define a partial mapping, called the <dfn>lexical-to-value mapping</dfn>, from character strings to values, and the literal refers to the value obtained by applying this mapping to the character string. If the mapping gives no value for the literal string, then the literal has no referent. The <dfn>value space</dfn> of a datatype is the range of the <a>lexical-to-value mapping</a>. Every literal with that type either refers to a value in the value space, or fails to refer at all. An <dfn>ill-typed</dfn> literal is one whose datatype IRI is recognized, but whose character string is not in the domain of the datatype lexical-to-value mapping. Datatypes are indicated by IRIs.
</p>
-<p> Interpretations will vary according to which IRIs they recognize as denoting datatypes. We describe this using a parameter D on interpretations. where D is a set of IRIs that constitute the recognized datatype IRIs. IRIs listed in <a href="http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/#xsd-datatypes">///Concepts Section 5///</a> <strong class="RFC2119">MUST</strong> be interpreted as described there, and the IRI <code>rdf:plainLiteral</code> <strong class="RFC2119">MUST</strong> be interpreted to refer to the datatype defined in <a href="www.w3.org/TR/rdf-plain-literal/">///PlainLiteral///</a>. When other datatypes are used, the mapping between a recognized IRI and the datatype it refers to <strong class="RFC2119">MUST</strong> be specified unambiguously, and be fixed during all RDF transformations or manipulations.</p> </p>
+<p> Interpretations will vary according to which IRIs they recognize as denoting datatypes. We describe this using a parameter D on interpretations. where D is a set of IRIs that constitute the recognized datatype IRIs. IRIs listed in <a href="http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/#xsd-datatypes">///Concepts Section 5///</a> MUST be interpreted as described there, and the IRI <code>rdf:plainLiteral</code> MUST be interpreted to refer to the datatype defined in <a href="www.w3.org/TR/rdf-plain-literal/">///PlainLiteral///</a>. When other datatypes are used, the mapping between a recognized IRI and the datatype it refers to MUST be specified unambiguously, and be fixed during all RDF transformations or manipulations.</p>
-<p>Language-tagged strings are an exceptional case which are given a special treatment. The IRI <code>rdf:langString</code> is classified as a datatype IRI, and interpreted to refer to a datatype, even though no L2V mapping is defined for it. The value space of <code>rdf:langString</code> is the set of all pairs of a string with a language tag. The semantics of literals with this as their type are given below. (If datatype L2V mappings were defined on pairs of lexical values rather than strings, then the L2V mapping for <code>rdf:langString</code> would be the identity function on pairs of the form < unicode string, language tag >. But as they are not, we simply list this as a special case.)</p>
+<p>Language-tagged strings are an exceptional case which are given a special treatment. The IRI <code>rdf:langString</code> is classified as a datatype IRI, and interpreted to refer to a datatype, even though no L2V mapping is defined for it. The value space of <code>rdf:langString</code> is the set of all pairs of a string with a language tag. The semantics of literals with this as their type are given below. (If datatype L2V mappings were defined on pairs of lexical values rather than strings, then the L2V mapping for <code>rdf:langString</code> would be the identity function on pairs of the form < unicode string, language tag >. But as they are not, we simply list this as a special case.)</p>
<p class="issue">This will require alignment with Concepts. rdf:langString may have an L2V mapping which is ignored by the semantics. Concepts currently states that it is not a datatype even though the IRI is a datatype IRI. </p>
<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it does not identify a datatype. Literals with an "unknown" datatype IRI which is not in the set of recognized datatypes, are treated like IRI names and assumed to denote some thing in the universe IR. </p>
-
-
+</section>
-<h3>D-interpretations</h3>
+<section><h2>D-interpretations and datatype entailment</h2>
+<p>Let D be a set of IRIs identifying datatypes. A <dfn>(simple) D-interpretation</dfn> is a simple interpretation which satisfies the following conditions:</p>
-<p>Let D be a set of IRIs identifying datatypes. A <em>(simple) D-interpretation</em> is a simple interpretation which satisfies the following conditions:</p>
-
-<div class="title">Semantic conditions for datatyped literals.</div>
+<div class="tabletitle">Semantic conditions for datatyped literals.</div>
<table border="1" class="semantictable" summary="datatype semantic condition">
<tbody>
<tr><td>If <code>rdf:langString</code> is in D, then for every language-tagged string E with lexical form sss and language tag ttt, IL(E)= < sss, ttt > </td></tr>
@@ -927,20 +442,21 @@
<p>If the literal is ill-typed then the L2V mapping has no value, and so the literal cannot denote anything. In this case, any triple containing the literal must be false. Thus, any triple, and hence any graph, containing an ill-typed literal will be D-inconsistent, i.e. false in every D-interpretation. This applies only to datatype IRIs in D; literals with "unknown" datatypes are not ill-typed and do not produce a D-inconsistency. </p>
-<br/>
-<p class="changenote"> In the 2004 RDF 1.0 specification, ill-typed literals were required to denote a value in IR, and D-inconsistency could only be recognized by using the RDFS semantics. </p>
+
+<ul><li><p class="changenote"> In the 2004 RDF 1.0 specification, ill-typed literals were required to denote a value in IR, and D-inconsistency could only be recognized by using the RDFS semantics. </p>
<p></p>
-
+</li></ul>
<h3>Datatype entailment</h3>
-<p>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>A graph is (simply) <dfn>D-satisfiable</dfn> when it has the value true in some D-interpretation, and a set S of graphs (simply) <dfn>D-entails</dfn> a graph G when every D-interpretation which makes S true also D-satisfies G.</p>
+
+<p> Unlike the case with simple interpretations, it is possible for a graph to have no satisfying D-interpretations, i.e. to be <dfn>D-unsatisfiable</dfn>. 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 { }-entailment, i.e. D-entailment when D is the empty set. If S D-entails G then S simply entails G, but not the reverse. </p>
-<p>Several of the basic properties of simple entailment are also true for D-entailment, but the <a href="#interplemma" class="termref">interpolation lemma</a> is not true for D-entailment, since D-entailments
+<p>Several of the basic properties of simple entailment are also true for D-entailment, but the <a>interpolation lemma</a> is not true for <a>D-entailment</a>, since D-entailments
can hold because of particular properties of the lexical-to-value mappings of the recognized datatypes. For example, if D contains <code>xsd:integer</code> then </p>
<p><code>aaa ppp "00025"^^xsd:integer .</code></p>
@@ -950,17 +466,16 @@
<p><code>aaa ppp "25"^^xsd:integer .</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>
+<p>Ill-typed literals are the only form of simple D-contradiction, but datatypes can give rise to a variety of other contradictions when combined with the <a>RDFS vocabulary</a>, defined later.</p>
-<h3><a name="RDFINTERP" id="RDFINTERP">3.1 RDF-D Interpretations</a></h3>
-
- <p ><a name="defRDFV" id="defRDFV"></a>RDF-D interpretations impose extra semantic conditions on <code>xsd:string</code> and part of the infinite
+</section>
+<section><h2>RDF-D Interpretations and RDF entailment</h2>
+ <p >RDF-D interpretations impose extra semantic conditions on <code>xsd:string</code> and part of the infinite
set of IRIs in the <code>rdf:</code> namespace.
-<p> <a id="rdfinterpdef" name="rdfinterpdef"></a>An <i>rdf-D-interpretation</i>
- I is a D-interpretation where D includes <code>rdf:langString</code> and <code>xsd:string</code>, and which satisfies:</p>
-<div class="title">RDF semantic conditions.</div>
+<p>An <dfn>rdf-D-interpretation</dfn> I is a D-interpretation where D includes <code>rdf:langString</code> and <code>xsd:string</code>, and which satisfies:</p>
+<div class="tabletitle">RDF semantic conditions.</div>
<table border="1" summary="RDF semantic condition">
<tbody>
<tr>
@@ -973,7 +488,7 @@
</tbody>
</table>
<p>and satisfies every triple in the following infinite set:</p>
- <div class="title">RDF axioms.</div>
+ <div class="tabletitle">RDF axioms.</div>
<table border="1" summary="RDF axiomatic triples">
<tr>
@@ -994,10 +509,10 @@
</tr>
</table>
-<p>No other semantic constraints are imposed upon rdf-D-interpretations, so RDF imposes no particular normative meanings on the rest of the RDF vocabulary. Some consequences of this are discussed in Appendix ///</p>
+<p>No other semantic constraints are imposed upon <a>rdf-D-interpretation</a>s, so RDF imposes no particular normative meanings on the rest of the RDF vocabulary. Some consequences of this are discussed in <a>Appendix C</a></p>
-<p>An <em>rdf-interpretation</em>, or <em>RDF interpretation</em>, is an rdf-{<code>rdf:langString</code>, <code>xsd:string</code> }-interpretation, i.e. an rdf-D-Interpretation with a minimal set D. The datatypes <code>rdf:langString</code> and <code>xsd:string</code> must be recognized by all RDF interpretations. </p><p>The RDF built-in datatypes <code>rdf:XMLLiteral</code> and <code>rdf:HTML</code> are defined in ///RDF Concepts///. RDF interpretations are not required to recognize these datatypes. </p>
+<p>An <em>rdf-interpretation</em>, or <em>RDF interpretation</em>, is an rdf-{<code>rdf:langString</code>, <code>xsd:string</code> }-interpretation, i.e. an rdf-D-Interpretation with a minimal set D. The datatypes <code>rdf:langString</code> and <code>xsd:string</code> MUST be recognized by all RDF interpretations. </p><p>The RDF built-in datatypes <code>rdf:XMLLiteral</code> and <code>rdf:HTML</code> are defined in ///RDF Concepts///. RDF interpretations are not required to recognize these datatypes. </p>
<h3><a name="rdf_entail" id="rdf_entail"></a>RDF entailment</h3>
@@ -1018,13 +533,8 @@
</p>
-
-
-<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>
-
+</section>
+<section><h2>RDFS Interpretations and RDFS entailment</h2>
<p>RDF Schema [<cite><a href="#ref-rdf-vocabulary">RDF-VOCABULARY</a></cite>]
extends RDF to a larger <a id="defRDFSV" name="defRDFSV"></a>vocabulary
with more complex semantic constraints:</p>
@@ -1068,7 +578,7 @@
which satisfies the semantic conditions in the following table, and satisfies all the triples in the subsequent table of <em>RDFS axiomatic triples</em>. As before, an <em>rdfs-interpretation</em>, or <em>RDFS interpretation</em>, is an rdfs-D-interpretation with D= {<code>xsd:string</code>, <code>rdf:langString</code> }.</p>
<p class="issue">This table has redundancies. I am inclined to leave them alone, as it takes quite a lot of thought to figure out some of the consequences when we only give non-redundant conditions. </p>
-<div class="title">RDFS semantic conditions.</div>
+<div class="tabletitle">RDFS semantic conditions.</div>
<table border="1">
<tr>
@@ -1142,7 +652,7 @@
<p><a id="RDFS_axiomatic_triples" name="RDFS_axiomatic_triples"> </a>
</p>
- <div class="title">RDFS axiomatic triples.</div>
+ <div class="tabletitle">RDFS axiomatic triples.</div>
<table border="1" summary="RDFS axioms">
<tr>
@@ -1205,7 +715,8 @@
</table>
-<p class="changenote">In the 2004 RDF 1.0 semantics, LV was defined as part of a simple interpretation structure, and the definition given here was a constraint. </p>
+<ul><li><p class="changenote">In the 2004 RDF 1.0 semantics, LV was defined as part of a simple interpretation structure, and the definition given here was a constraint. </p>
+</li></ul>
<p>Since I is an <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>, the first condition implies that IP
= ICEXT(I(<code>rdf:Property</code>)).</p>
@@ -1215,7 +726,7 @@
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>
+ <div class="tabletitle">Some rdfs-valid triples.</div>
<table border="1">
<tr>
<td class="ruletable"><code>rdfs:Resource rdf:type rdfs:Class .<br />
@@ -1246,19 +757,62 @@
</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>
-<br />
-
+<p>RDFS does not partition the universe into disjoint categories of classes, properties and individuals. Anything in the universe can be used as a class or as a property, or both, while retaining its status as an individual which may be in classes and have properties. Thus, RDFS permits classes which contain other classes, classes of properties, properties of classes, etc. . As the axiomatic triples above illustrate, it also permits classes which contain themselves and properties which apply to themselves. A property of a class is not necessarily a property of its members, nor vice versa. </p>
-<h3><a name="ExtensionalDomRang" id="ExtensionalDomRang"></a>4.2 Extensional Semantic
- Conditions (Informative)</h3>
+<h3>A note on rdfs:Literal</h3>
+<p>The class <code>rdfs:Literal</code> is not the class of literals, but rather that of literal <em>values</em>. For example, LV does not contain the literal <code>"24"^^xsd:integer</code> (although it might contain the string '<code>"24"^^http://www.w3.org/2001/XMLSchema#integer</code>' ) but it does contain the number twenty-four.</p>
+
+ <p>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. Similarly, blank nodes may range over literal values. </p>
+
+<h3>RDFS Entailment</h3>
+<p>S <i>rdfs-D-entails</i> E when every <a href="#rdfsinterpdef" class="termref">rdfs-D-interpretation</a>
+ which satisfies every member of S also satisfies E. RDFS entailment is rdfs-{<code>rdf:langString</code>, <code>xsd:string</code> }-entailment, i.e. rdfs-D-entailment with a minimal D. </p>
+<p> Since every <a href="#rdfsinterpdef" class="termref">rdfs-D-interpretation</a> is an <a href="#rdfinterpdef" class="termref">rdf-D-interpretation</a>, if S rdfs-D-entails
+ E then S also rdf-D-entails E; but rdfs-entailment is stronger than rdf-entailment.
+ Even the empty graph has a large number of rdfs-entailments which are not rdf-entailments,
+ for example all triples of the form </p>
+<p> <code>aaa rdf:type rdfs:Resource .</code></p>
+<p>where aaa is an IRI, are true in all <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a>s.</p>
+
+
+
+
+</section>
+<section><h2>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>
+
+</section>
+
+<section class="informative"><h2>Extensional RDFS Semantic Conditions (Informative)</h2>
<p class="issue">Is this section useful, or is it more likely to be confusing? Editor is inclined to delete it. </p>
<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>
+ interpretation of the RDFS vocabulary. Semantic extensions MAY
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>
+ <div class="tabletitle">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>))
@@ -1279,7 +833,7 @@
</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
+<ul><li><p class="technote">These stronger conditions would be trivially satisfied when properties are
identified with property extensions, classes with class extensions, and <code>rdfs:SubClassOf</code>
understood to mean subset, and hence would be satisfied by an <a href="#glossExtensional" class="termref">extensional</a> semantics
for RDFS. In some ways the extensional versions provide a simpler semantics,
@@ -1287,66 +841,26 @@
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, LV does not contain the literal <code>"24"^^xsd:integer</code> (although it may contain the string '<code>"24"^^http://www.w3.org/2001/XMLSchema#integer</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. 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-D-entails</i> E when every <a href="#rdfsinterpdef" class="termref">rdfs-D-interpretation</a>
- which satisfies every member of S also satisfies E. RDFS entailment is rdfs-{<code>rdf:langString</code>, <code>xsd:string</code> }-entailment, i.e. rdfs-D-entailment with a minimal D. </p>
-<p> Since every <a href="#rdfsinterpdef" class="termref">rdfs-D-interpretation</a> is an <a href="#rdfinterpdef" class="termref">rdf-D-interpretation</a>, if S rdfs-D-entails
- E then S also rdf-D-entails E; but rdfs-entailment is stronger than rdf-entailment.
- Even the empty graph has a large number of rdfs-entailments which are not rdf-entailments,
- for example all triples of the form </p>
-<p> <code>aaa rdf:type rdfs:Resource .</code></p>
-<p>where aaa is an IRI, are true in all <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a>s.</p>
+</li><ul>
-
-<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>
+</section>
-<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="tutorial" id="tutorial"/>Appendix: Introduction to model theory (Informative)</h2>
-
-<h2><a name="prf" id="prf"/>Appendix: Proofs of Lemmas (Informative)</h2>
-
-<h2><a name="notdo" id="notdo" />Appendix: What the semantics does not do (Informative) </h2>
+<section class="informative"><h2>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. The hard work has already been done by terHorst. <br/> <br/> I do not plan to reproduce the completeness proofs which were in the RDF 2004 document. They were unreadable, intimidating, buggy and unnecessary. </p>
-<h3><a name="ReifAndCont" id="ReifAndCont"> Reification, Containers, Collections and rdf:value</a></h3>
+</section>
-<dt>
-<dd class="greyout">
+<section class="appendix" id="MTintro"><h2>Introduction to model theory (Informative)</h2>
+///
+</section>
+<section class="appendix" id="proofs"><h2>Proofs of Lemmas (Informative)</h2>
+///interpolation lemma is now slightly less trivial to prove. Check for possible consequences of this.///
+</section>
+<section class="appendix" id="whatnot"><h2>What the semantics does not do (Informative)</h2>
+
+<p class="issue">Something in here about datasets having no specified semantics, and why. Why using a graph name need not refer to the graph.</p>
+<h3>The RDF vocabulary</h3>
<p>The RDF semantic conditions do not place formal constraints on the meaning
of much of the RDF vocabulary which is intended for use in describing containers and bounded collections,
or the reification vocabulary intended to enable an RDF graph to describe RDF triples. In this appendix we briefly review the intended meanings of this vocabulary. </p>
@@ -1357,7 +871,7 @@
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>
+<h3><a name="Reif" id="Reif">Reification</a></h3>
<div class="c1">
<table border="1" summary="reification vocabulary">
@@ -1435,7 +949,7 @@
<p><code>_:yyy <ex:property> <ex:foo> .</code></p>
-<h4><a name="Containers" id="Containers">3.3.2 RDF containers</a></h4>
+<h4><a name="Containers" id="Containers">RDF containers</a></h4>
<table border="1" summary="container vocabulary">
<tbody>
@@ -1477,10 +991,9 @@
<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
+ the general RDF semantic conditions. This amounts to knowing the type of a container, and having a partial
enumeration
- of the items in the container.</span> The intended mode of use is that things
+ of the items in the container. 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
@@ -1488,7 +1001,7 @@
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>.
+ properties, which are assumed to be single-valued.
However, these informal interpretations are not reflected in any formal RDF
entailments.</p>
@@ -1505,11 +1018,8 @@
<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
+ <p>Notice that if this conclusion were <a>valid</a>, then the result of
+ conjoining it to the original graph would be <a>entailed</a> by the graph, and this would assert that both elements were in both
positions. This is a consequence of the fact that RDF is a purely
assertional language.</p>
@@ -1517,7 +1027,7 @@
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>.
+ it is not a <a>contradiction</a> to assert that something is both an <code>rdf:Bag</code> and an <code>rdf:Seq</code>.
There is no assumption that containers are gap-free, so that for example</p>
<p><code>_:xxx rdf:type rdf:Seq.<br />
_:xxx rdf:_1 <ex:a> .<br />
@@ -1535,7 +1045,7 @@
only finitely many members.</p>
-<h4><a name="collections" id="collections"></a>3.3.3 RDF collections</h4>
+<h4><a name="collections" id="collections"></a>RDF collections</h4>
<table border="1" summary="collection vocabulary">
<tbody>
@@ -1558,7 +1068,8 @@
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 />
+ two triples of the form
+<code><br />
<br />
_:c1 rdf:first aaa .<br />
_:c1 rdf:rest _:c2</code></p>
@@ -1572,8 +1083,9 @@
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 />
+ 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 />
@@ -1602,9 +1114,9 @@
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>
+<p>Semantic extensions MAY
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>
+ in order to rule out such graphs. They MAY
exclude interpretations of the collection vocabulary which violate the convention
that the subject of a 'linked' collection of two-triple items of the form described
above, ending with an item ending with <code>rdf:nil</code>, denotes a totally
@@ -1617,27 +1129,23 @@
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>
+<h3><a name="rdfValue" id="rdfValue"></a>rdf:value</h3>
<p>The intended use for <code>rdf:value</code> is <a href="http://www.w3.org/TR/rdf-primer/#rdfvalue">explained
intuitively</a> in the RDF Primer
- document [<cite><a href="#ref-rdf-primer">RDF-PRIMER</a></cite>]. It is typically
+ document [[!RDF-PRIMER]]. It is typically
used to identify a 'primary' or 'main' value of a property which has several
values, or has as its value a complex entity with several facets or properties
of its own.</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
+ or use cases. Users are cautioned, therefore, that 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
+ Even when the intended meaning is clear from the context in the original graph document, it may be
lost when graphs are merged or when conclusions are inferred.</p>
-</dd>
-</dt>
-
-
-<h2><a name="gloss" id="gloss"/>Appendix: Glossary of Terms (Informative)</h2>
-
- <p><strong><a name="glossAntecedent"
+</section>
+<section class="appendix" id="glossary"><h2>Glossary of Terms (Informative)</h2>
+ <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"
@@ -1663,8 +1171,7 @@
<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>
+ freedom in constructing class hierarchies.</p>
<p><strong><a name="glossComplete"
id="glossComplete"></a>Complete</strong> (adj., of an inference system). (1)
Able to detect all <a
@@ -1694,13 +1201,13 @@
<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>
+<p><strong><a name="glossDecidable" id="glossDecidable"></a>Decidable</strong>
(adj., of an inference system). Able to determine for any pair of expressions,
in a finite time with finite resources, whether or not the first entails the
- second. (Also: adj., of a logic:) Having a decideable inference system which
+ second. (Also: adj., of a logic:) Having a decidable inference system which
is complete and correct for the semantics of the logic.</p>
-<p>(Not all logics can have inference systems which are both complete and decideable,
- and decideable inference systems may have arbitrarily high computational complexity.
+<p>(Not all logics can have inference systems which are both complete and decidable,
+ and decidable inference systems may have arbitrarily high computational complexity.
The relationships between logical syntax, semantics and complexity of an inference
system continue to be the subject of considerable research.)</p>
@@ -1791,7 +1298,7 @@
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
+ <p>(Some logic texts distinguish between an <em>interpretation
structure</em>, which is a 'possible world' considered as something
independent of any particular vocabulary, and an <em>interpretation
mapping</em> from a vocabulary into the structure. The RDF
@@ -1945,8 +1452,7 @@
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
+ <p><dfn>Well-formed</dfn> (adj., of an
expression). Syntactically legal.</p>
<p><strong><a name="glossWorld" id="glossWorld"></a>World</strong>
@@ -1962,155 +1468,18 @@
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 class="issue">From here on is left over from the 2004 document and needs rewriting.</p>
-<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>
+</section>
- <p>The basic idea of using an explicit extension mapping to allow
+ <section class='appendix'>
+ <h2>Acknowledgements</h2>
+<p>The basic idea of using an explicit extension mapping to allow
self-application without violating the axiom of foundation was
suggested by Christopher Menzel.</p>
-<p>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>
+<p>///Herman ter Horst for rule style, Li Ding for complete graphs, Antoine for no-vocabulary and general input. Others?///</p>
+ <p>
+ Many thanks to Robin Berjon for making our lives so much easier with his cool tool. You betcha.
+ </p>
+ </section>
</body>
</html>
-