--- a/rdf-concepts/index.html Fri Nov 09 10:35:29 2012 +0000
+++ b/rdf-concepts/index.html Fri Nov 09 15:45:18 2012 +0000
@@ -140,6 +140,15 @@
<section id="section-Introduction" class="informative">
<h2>Introduction</h2>
+ <p class="issue">This is a work-in-progress Working Draft. Various open
+ issues are flagged throughout the text with boxes like this. Feedback
+ on these issues is particularly welcome.</p>
+
+ <p class="issue">In some sections, the content is overwhelmed by
+ informative Notes. Are they necessary? Can some be deleted or be moved
+ to other documents? Can some be merged or streamlined? This is
+ <a href="https://www.w3.org/2011/rdf-wg/track/issues/104">ISSUE-104</a>.</p>
+
<p>The <em>Resource Description Framework</em> (RDF) is a framework
for representing information in the Web.</p>
@@ -370,12 +379,17 @@
and explain the fact that graphs merge easily.
This will be added once the Working Group has finalised a design.</p>
- <p class="issue">If RDF Concepts defines graph stores, then they should be mentioned here.</p>
+ <p class="issue">Should this section define the notion of “graph store”?</p>
<p>An <dfn>RDF document</dfn> is a document that encodes an
<a>RDF graph</a> in a <dfn>concrete RDF syntax</dfn>, such as
Turtle [[TURTLE-TR]], RDFa [[RDFA-PRIMER]], RDF/XML [[RDF-SYNTAX-GRAMMAR]],
or N-Triples [[N-TRIPLES]].</p>
+
+ <p class="issue">The Working Group intends to publish a Working Group
+ Note detailing some of its efforts to define a formal semantics for
+ RDF datasets. This is
+ <a href="http://www.w3.org/2011/rdf-wg/track/actions/209">ACTION-209</a>.</p>
</section>
@@ -391,6 +405,14 @@
An account of meaning and entailment in RDF, using the formalism of
model theory, is given in [[RDF-MT]].</p>
+ <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>
+
<div class="issue">
<p>The relationship between this document and RDF Semantics
[[RDF-MT]] is poorly defined and needs to be clarified. A principled
@@ -404,7 +426,6 @@
<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>
@@ -523,18 +544,6 @@
if a <a href="http://tools.ietf.org/html/rfc3986#section-5.1">base IRI
can be established</a> [[RFC3986]].</p>
- <p class="note">Previous versions of RDF used the term
- “<dfn>RDF URI Reference</dfn>” instead of “IRI” and allowed
- additional characters:
- “<code><</code>”, “<code>></code>”,
- “<code>{</code>”, “<code>}</code>”,
- “<code>|</code>”, “<code>\</code>”,
- “<code>^</code>”, “<code>`</code>”,
- ‘<code>“</code>’ (double quote), and “<code> </code>” (space).
- In IRIs, these characters must be percent-encoded as
- described in <a href="http://tools.ietf.org/html/rfc3986#section-2.1">section 2.1</a>
- of [[RFC3986]].</p>
-
<div class="note" id="note-iri-interop">
<p>Interoperability problems can be avoided by minting
only IRIs that are normalized according to
@@ -563,11 +572,6 @@
Form C [[!NFC]]</li>
</ul>
</div>
-
- <p class="issue">In some sections, the content is overwhelmed by
- informative Notes. Are they all necessary? Can they be moved to other
- documents? Can they be merged or streamlined? This is
- <a href="https://www.w3.org/2011/rdf-wg/track/issues/104">ISSUE-104</a>.</p>
</section>
@@ -614,36 +618,19 @@
<a title="language tag">language tags</a> (if any)
compare equal, character by character.</p>
- <p class="note">In earlier versions of RDF, literals with a
- <a>language tag</a> did not have a <a>datatype IRI</a>, and
- <a title="simple literal">simple literals</a> could appear
- directly in the abstract syntax. Simple literals and literals with a
- language tag were collectively known as
- <dfn title="plain literal">plain literals</dfn>.</p>
-
- <p class="note">Literals in which the lexical form begins with a
- composing character (as defined by [[CHARMOD]]) are allowed however they may cause
- interoperability problems, particularly with XML version 1.1 [[XML11]].</p>
+ <p class="note" id="note-composing-character">Literals in which the
+ lexical form begins with a composing character
+ (as defined by [[CHARMOD]])
+ are allowed however they may cause interoperability problems,
+ particularly with XML version 1.1 [[XML11]].</p>
- <p class="note">Earlier versions of RDF permitted tags that
- adhered to the generic tag/subtag syntax of language tags,
- but were not well-formed according to [[!BCP47]]. Such
- language tags do not conform to RDF 1.1.</p>
-
- <p class="note">The <code>xsd:string</code> datatype does not
- permit the <code>#x0</code> character, and implementations may not permit
- control codes in the <code>#x1-#x1F</code> range. Earlier versions of
- RDF allowed these characters in
- <a title="simple literal">simple literals</a>, although they
- could never be serialized in a W3C-recommended concrete syntax.</p>
-
- <p class="note">When using the language tag, care must be
+ <p class="note" id="note-locale">When using the language tag, care must be
taken not to confuse language with locale. The language
tag relates only to human language text. Presentational
issues should
be addressed in end-user applications.</p>
- <p class="note">The case normalization of
+ <p class="note" id="note-langtag-normalization">The case normalization of
language tags is part of
the description of the abstract syntax, and consequently the abstract
behaviour of RDF applications. It does not constrain an
@@ -663,23 +650,22 @@
<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="https://www.w3.org/2011/rdf-wg/track/issues/107">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 <a>RDF graph</a>
+ are drawn from some arbitrary infinite set that fulfils
+ the following conditions:</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
- <a title="literal">literals</a>.
- Otherwise, this set of blank nodes is arbitrary.</p>
+ <ul>
+ <li>It is disjoint from the set of <a title="IRI">IRIs</a> and
+ the set of all <a title="literal">literals</a>.</li>
+ <li>Equality within the set is well-defined
+ (<dfn>blank node equality</dfn>).</li>
+ </ul>
- <p>Given two blank nodes, it is
- possible to determine whether or not they are the same.
- Besides that, RDF makes no reference to any internal structure
- of blank nodes.</p>
+ <p>Allocating a <dfn>fresh blank node</dfn> is the action of drawing
+ a new node from the set of blank nodes.</p>
- <p class="note" id="note-bnode-id">
- <dfn title="blank node identifier">Blank node identifiers</dfn>
+ <div class="note" id="note-bnode-id">
+ <p><dfn title="blank node identifier">Blank node identifiers</dfn>
are local identifiers that are used in some
<a title="concrete RDF syntax">concrete RDF syntaxes</a>
or RDF store implementations.
@@ -690,6 +676,14 @@
on the concrete syntax or implementation. The syntactic restrictions
on blank node identifiers, if any, therefore also depend on
the concrete RDF syntax or implementation.</p>
+
+ <p>Since RDF systems generally refer to
+ <a title="blank node">blank nodes</a> only via such local identifiers,
+ it is necessary to “standardize apart” the blank node identifiers
+ when incorporating data that originates from an external source.
+ This may be done by systematically replacing the blank node identifiers
+ in incoming data with freshly allocated blank node identifiers.</p>
+ </div>
</section>
@@ -794,20 +788,7 @@
Therefore, to maximize interoperability, applications should avoid
ascribing importance to the presence of empty named graphs.</div>
- <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 class="issue">Should this section define operations between RDF datasets, such as merge and equality/equivalence?</p>
-
- <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>
- </div>
-
- <p class="issue">Should “Graph merge” be defined in this spec?
- If not, then the previous note could just as well go. This will be
- decided once a multigraph design has been decided upon.</p>
</section>
@@ -839,7 +820,7 @@
of that value. The mapping can be seen as a function
from the lexical space to the value space.</p>
-<div class="note">
+<div class="note" id="note-datatype-xml-schema">
<p>When the datatype is defined using XML Schema:
</p>
<ul>
@@ -872,7 +853,7 @@
No datatype is formally defined for this IRI because the definition
of <a title="datatype">datatypes</a> does not accommodate
<a title="language tag">language tags</a> in the <a>lexical space</a>.
- The <a>value space</a> associated with the datatype IRI is the set
+ The <a>value space</a> associated with this datatype IRI is the set
of all pairs of strings and language tags.</p>
<p>For example, the XML Schema datatype <code>xsd:boolean</code>,
@@ -1139,8 +1120,8 @@
(e.g., <a href="http://www.w3.org/TR/rdf-syntax-grammar/#parseTypeLiteralPropertyElt"><code>@parseType="literal"</code></a>
in RDF/XML [[RDF-SYNTAX-GRAMMAR]]).</p>
- <p class="note">Not all values of this datatype are compliant
- with XML 1.1 [[XML11]]. If compliance
+ <p class="note" id="note-xml11">Not all values of this datatype
+ are compliant with XML 1.1 [[XML11]]. If compliance
with XML 1.1 is desired, then only those values that are
<a href="http://www.w3.org/TR/xml11/#dt-fullnorm">fully
normalized</a> according to XML 1.1 should be used.</p>
@@ -1212,14 +1193,6 @@
<em>syntactically</em> ill-formed.</li>
</ol>
- <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? This is <a href="https://www.w3.org/2011/rdf-wg/track/issues/109">ISSUE-109</a>.</p>
</section>
@@ -1235,7 +1208,12 @@
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
+ authoritativeness of representations. For example, is it legitimate
+ to content-negotiate between an RDF graph representation and an
+ RDF dataset representation that only contains a default graph?
+ Are the contents of graphs named <code><#xxx></code> an
+ authoritative representation of whatever is identified by
+ <code><#xxx></code>? This is
<a href="https://www.w3.org/2011/rdf-wg/track/issues/105">ISSUE-105</a>.</p>
<p>RDF uses <a title="IRI">IRIs</a>, which may include
@@ -1315,7 +1293,57 @@
<section class="appendix informative" id="changes">
- <h2>Changes from RDF 2004</h2>
+ <h2>Changes between RDF 2004 and RDF 1.1</h2>
+
+ <p class="issue">The Working Group intends to publish a separate
+ Working Group Note entitled
+ <em>RDF 1.1 New Features and Migration Guide</em>. This is
+ <a href="http://www.w3.org/2011/rdf-wg/track/actions/193">ACTION-193</a>.
+ Some or all material in this section may be moved to that document. In the
+ meantime, the <a href="#change-log">Change Log</a> is a good indication
+ as to what else has changed and why.</p>
+
+ <p>This section discusses changes between the
+ <a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/">2004
+ Recommendation of <em>RDF Concepts and Abstract Syntax</em></a> and
+ the RDF 1.1 versions of this specification.</p>
+
+ <p>Previous versions of RDF used the term
+ “<dfn>RDF URI Reference</dfn>” instead of “IRI” and allowed
+ additional characters:
+ “<code><</code>”, “<code>></code>”,
+ “<code>{</code>”, “<code>}</code>”,
+ “<code>|</code>”, “<code>\</code>”,
+ “<code>^</code>”, “<code>`</code>”,
+ ‘<code>“</code>’ (double quote), and “<code> </code>” (space).
+ In IRIs, these characters must be percent-encoded as
+ described in <a href="http://tools.ietf.org/html/rfc3986#section-2.1">section 2.1</a>
+ of [[RFC3986]].</p>
+
+ <p>In earlier versions of RDF, <a title="literal">literals</a>
+ with a <a>language tag</a> did not have a <a>datatype IRI</a>, and
+ <a title="simple literal">simple literals</a> could appear
+ directly in the abstract syntax. Simple literals and literals with a
+ language tag were collectively known as
+ <dfn title="plain literal">plain literals</dfn>.</p>
+
+ <p>Earlier versions of RDF permitted
+ <a title="language tag">language tags</a> that
+ adhered to the generic tag/subtag syntax of language tags,
+ but were not well-formed according to [[!BCP47]]. Such
+ language tags do not conform to RDF 1.1.</p>
+
+ <p>The <code>xsd:string</code> datatype does not
+ permit the <code>#x0</code> character, and implementations may not permit
+ control codes in the <code>#x1-#x1F</code> range. Earlier versions of
+ RDF allowed these characters in
+ <a title="simple literal">simple literals</a>, although they
+ could never be serialized in a W3C-recommended concrete syntax.</p>
+</section>
+
+
+<section class="appendix informative" id="change-log">
+ <h2>Change Log</h2>
<section class="appendix" id="changes-wd3">
@@ -1326,6 +1354,8 @@
<em>RDF 1.1 Concepts and Abstract Syntax</em>.</p>
<ul>
+ <li>2012-11-09: Re-wrote the <a href="#section-blank-nodes">section on Blank Nodes</a>, including a definition of “fresh blank nodes” and an extended Note on standardizing apart blank node IDs</li>
+ <li>2012-11-09: Moved all informative material about changes between RDF 2004 and RDF 1.1 to a <a href="#changes">new appendix</a></li>
<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="http://www.w3.org/2011/rdf-wg/track/issues/94">ISSUE-94</a>)</li>