change abstract; add preliminary section on Change Over Time; add many issue boxes to outline work necessary to reach LC
authorRichard Cyganiak <>
Wed, 07 Nov 2012 17:11:50 +0000
changeset 532 eef9efce51fc
parent 531 e72877b6b6a1
child 533 4bc24842b656
change abstract; add preliminary section on Change Over Time; add many issue boxes to outline work necessary to reach LC
--- a/rdf-concepts/index.html	Tue Nov 06 21:23:01 2012 +0000
+++ b/rdf-concepts/index.html	Wed Nov 07 17:11:50 2012 +0000
@@ -123,11 +123,17 @@
 <section id="abstract">
     <p>The Resource Description Framework (RDF) is a framework for
     representing information in the Web.</p>
-    <p>RDF Concepts and Abstract Syntax defines an abstract syntax
-    on which RDF is based, and which serves to link its concrete
-    syntax to its formal semantics. It also includes discussion of
-    key concepts, datatyping, character normalization
-    and handling of IRIs.</p>
+    <p>RDF 1.1 Concepts and Abstract Syntax defines an abstract syntax
+    (a data model) which serves to link all RDF-based languages and
+    specifications. The abstract syntax has two key data structures:
+    RDF graphs are sets of subject-predicate-object triples,
+    where the elements may be IRIs, blank nodes, or datatyped literals. They
+    are used to express descriptions of resources. RDF datasets comprise
+    a default graph and zero or more named graphs, and are used to to
+    express metadata about RDF graphs, and to organize data by context.
+    This document also introduces key concepts and terminology, and discusses
+    datatyping and the handling of fragment identifiers in IRIs within
+    RDF graphs.</p>
@@ -157,10 +163,21 @@
       model-theoretic semantics for RDF</a> [[RDF-MT]].</li>
+    <p class="issue">The Working Group is considering to highlight
+    the kind of
+    <a href="">rdf:List</a>
+    structure generated by Turtle's list shorthand as “well-formed lists”
+    in one of its documents, with this document being a candidate.
+    This is
+    <a href="">ISSUE-102</a>.</p>
 <section id="data-model">
     <h3>Graph-based Data Model</h3>
+    <p class="issue">The Introduction is becoming long. But it has also been
+    suggested that some of the informative explanations would benefit from
+    examples. Split all these subsections out into a new Overview section?</p>
     <p>The core structure of the abstract syntax is a collection of
     <a title="RDF triple">triples</a>, each consisting of a <a>subject</a>,
     a <a>predicate</a> and an <a>object</a>. A set of such triples is called
@@ -314,6 +331,36 @@
     is presumed or demonstrated then the truth of <em>B</em> can be inferred.
     An account of meaning and entailment in RDF, using the formalism of
     model theory, is given in [[RDF-MT]].</p>
+    <div class="issue">
+    <p>The relationship between this document and RDF Semantics
+    [[RDF-MT]] is poorly defined and needs to be clarified. A principled
+    decision is necessary on what exactly the “interface” between Concepts
+    and Semantics is. What notions should be defined in what spec? What notions
+    should Concepts import from Semantics (if any)? Does conformance to
+    Concepts depend on conformance to Semantics?</p>
+    <p>Content in this document that perhaps should be in Semantics:</p>
+    <ul>
+      <li>There is a <a href="#note-comparing-literals">Note on comparing literals</a> that makes a rather oblique reference to semantic notions of comparison.</li>
+      <li>There are scattered references to <a>IRI equality</a> and <a>literal equality</a> throughout the text, but nothing on blank node equality or graph equality. The latter concepts would enter RDF Semantics territory. (<a>Graph isomorphism</a> is defined and is a syntactic notion).</li>
+      <li>There is a <a href="#note-merge-blank-nodes">Note on graph merging</a>, a notion that is defined only in RDF Semantics.</li>
+    </ul>
+    <p>Semantics-related content that should perhaps be in Concepts:</p>
+    <ul>
+      <li>Definition of Graph Merge</li>
+      <li>Definition of Lean Graphs</li>
+      <li>Import (via reference to Semantics) of notions of equivalence, entailment, inconsistency between RDF graphs (at least informatively)</li>
+      <li>At least an informative definition of “entailment regime”?</li>
+      <li>Informative entailment rules?</li>
+    </ul>
+    <p>This is <a href="">ISSUE-106</a>.</p>
+    </div>
@@ -329,9 +376,42 @@
     <a>RDF graph</a> in a <dfn>concrete RDF syntax</dfn>, such as
     or N-Triples [[N-TRIPLES]].</p>
-    <p class="issue">Can the difference between data model and
-    serialization be hammered home more clearly?</p>
+<section id="change-over-time">
+    <h2>RDF and Change Over Time</h2>
+    <p class="issue">This sub-section is a rough draft and needs further editorial attention.</p>
+    <p>The RDF data model does not deal with time; it is <em>atemporal</em>.
+    RDF graphs (and RDF datasets) can be considered static snapshots.
+    There is no built-in notion of temporal validity or change.</p>
+    <p>However, RDF can be used to express information about events
+    and about temporal aspects of other entities,
+    given appropriate vocabulary terms.</p>
+    <p>While this is not explicitly captured in the data model or its
+    formal semantics, intuitively speaking, change is handled like this:</p>
+    <ul>
+      <li>New IRIs can be introduced (<dfn title="minting">minted</dfn>)
+      to refer to new entities</li>
+      <li>Once minted, IRIs don't change their referents</li>
+      <li>Literals never change their values</li>
+      <li>Some properties may change over time; that is,
+      a relationship between two resources that holds at one time
+      may not hold at another time</li>
+      <li>Some g-boxes may change their contents over time;
+      that is, they may contain different RDF graphs at different times</li>
+      <li>Some g-boxes may be immutable snapshots of another g-box,
+      archiving its state at some point in time</li>
+    </ul>
+    <p class="issue">“G-box” is a placeholder term.</p>
+    <p class="issue">If RDF Concepts defines graph stores, then they should be mentioned here.</p>
@@ -575,6 +655,10 @@
 <section id="section-blank-nodes">
     <h2>Blank Nodes</h2>
+    <p class="issue">A re-wording of this section has been proposed. This is <a href="">ISSUE-107</a>.</p>
+    <p class="issue">Should this section talk about the scope of blank nodes, and about the concept of a “fresh” blank node?</p>
     <p>The <dfn title="blank node">blank nodes</dfn> in an RDF graph 
     are drawn from an infinite set. This set is disjoint from the set
     of all <a title="IRI">IRIs</a> and the set of all
@@ -675,6 +759,9 @@
 <section id="section-dataset">
     <h2>RDF Datasets</h2>
+    <p class="issue">This section is a draft and requires more editorial
+    attention.</p>
     <p>The RDF data model expresses information as
     <a title="RDF graph">RDF graphs</a> consisting of
     <a title="triple">triples</a> with subject, predicate and object.
@@ -699,34 +786,13 @@
     Therefore, to maximize interoperability, applications should avoid
     ascribing importance to the presence of empty named graphs.</div>
-    <div class="issue">
-        <p>The Working Group will standardize a model and semantics for
-        multiple graphs and graphs stores. The
-        <a href="">charter</a> notes:</p>
-        <blockquote>The RDF Community has used the
-        term “named graphs” for a number of years in various settings,
-        but this term is ambiguous, and often refers to what could rather
-        be referred as quoted graphs, graph literals, IRIs for graphs,
-        knowledge bases, graph stores, etc. The term “Support for Multiple
-        Graphs and Graph Stores” is used as a neutral term in this charter;
-        this term is not and should not be considered as definitive.
-        The Working Group will have to define the right term(s).</blockquote>
+    <p class="issue">Should this section define the notion of “g-box” and “graph store”? If not, should they be informatively defined in the introductory part?
+    </p>
-        <p>Progress on the design for this feature is tracked under multiple
-        issues:</p>
+    <p class="issue">Should this section define operations between RDF datasets, such as merge and equality/equivalence?</p>
-        <ul>
-            <li><a href="">ISSUE-14: What is a named graph and what should we call it?</a></li>
-            <li><a href="">ISSUE-15: What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc</a></li>
-            <li><a href="">ISSUE-17: How are RDF datasets to be merged?</a></li>
-            <li><a href="">ISSUE-22: Does multigraph syntax need to support empty graphs?</a></li>
-            <li><a href="">ISSUE-32: Can we identify both g-boxes and g-snaps?</a></li>
-        </ul>
-        <p>The design presented here should be considered a preliminary proposal. It is based on RDF Datasets as <a href="">defined in SPARQL 1.1</a>.</p>
-    </div>
-    <p class="note">When RDF graphs are merged, their blank nodes must be kept
+    <p class="note" id="note-merge-blank-nodes">When RDF graphs are merged,
+    their blank nodes must be kept
     distinct if meaning is to be preserved; this may call for re-allocation of
     blank node identifiers.</p>
@@ -984,7 +1050,6 @@
         <li>Return <code>domfrag.<a href="">normalize</a>()</code></li>
-    </dl>
     <p class="note" id="note-html-context">Any language annotation
     (<code>lang="…"</code>) or
@@ -1139,14 +1204,15 @@
     <em>syntactically</em> ill-formed.</li>
-    <p class="note">In application contexts, comparing the
-    <a title="literal value">values of literals</a> is usually
+    <p class="note" id="note-comparing-lilterals">In application contexts,
+    comparing the <a title="literal value">values of literals</a> is usually
     more helpful than comparing their syntactic forms
     (<a>literal equality</a>).
     Similarly, for comparing <a title="RDF graph">RDF graphs</a>,
     semantic notions of <a>entailment</a> are usually more helpful
     than syntactic <a>graph isomorphism</a>.</p>
+    <p class="issue">What does it mean when a literal is ill-typed or when something is not in the datatype map? What should an implementation do? Should authors avoid generating such graphs? Should consumers reject it? Is an implementation that rejects ill-formed xsd:dates conforming?</p>
@@ -1156,6 +1222,14 @@
 <section id="section-fragID" class="informative">
     <h2>Fragment Identifiers</h2>
+    <p class="issue">This section addresses the use of fragment IRIs
+    in concrete syntaxes for <a title="RDF graph">RDF graphs</a>, but not 
+    for <a title="RDF dataset">RDF datasets</a>. Going beyond the questions
+    of pure fragment identifiers, the introduction of RDF datasets raises
+    additional questions related to content negotiation and the
+    authoritativeness of representations. This is
+    <a href="">ISSUE-105</a>.</p>
     <p>RDF uses <a title="IRI">IRIs</a>, which may include
     <dfn>fragment identifiers</dfn>, as resource identifiers.
     The semantics of fragment identifiers are
@@ -1208,7 +1282,7 @@
     <p>The RDF 1.1 editors acknowledge valuable contributions from
-    Thomas Baker, Dan Brickley, Gavin Carothers, Jeremy Carroll,
+    Thomas Baker, Dan Brickley, Gavin Carothers, Jeremy Carroll, Dan Connolly, 
     John Cowan, Martin J. Dürst, Alex Hall, Steve Harris, Pat Hayes,
     Ivan Herman, Peter F. Patel-Schneider, Addison Phillips,
     Eric Prud'hommeaux, Andy Seaborne, Leif Halvard Silli,
@@ -1226,8 +1300,9 @@
     and RDF Schema edited by Dan Brickley and R. V. Guha.</p>
     <p>This specification is a product of extended deliberations by the
+    <a href="">members of the RDF Working Group</a> and the
     <a href="">members
-    of the RDFcore Working Group and the Schema Working Group</a>.</p>
+    of the earlier RDFcore and Schema Working Groups</a>.</p>
@@ -1243,6 +1318,8 @@
   <em>RDF 1.1 Concepts and Abstract Syntax</em>.</p>
+    <li>2012-11-07: Add <a href="#change-over-time">new informative section on Change Over Time</a></li>
+    <li>2012-11-07: New <a href="#abstract">abstract</a>, based on comments from Dan Connolly</li>
     <li>2012-11-06: Tweak definition of <a title="literal">literals</a> to avoid apparent contradiction (<a href="">ISSUE-94</a>)</li>
     <li>2012-11-06: Add a <a href="#note-custom-datatypes">note</a> on the use of OWL2 custom datatypes and simple user-defined XML Schema datatypes (<a href="">ISSUE-96</a>)</li>
     <li>2012-11-06: Add a <a href="#note-empty-named-graphs">note on empty named graphs</a> (<a href="">ISSUE-22</a>)</li>