--- a/rdf-spaces/index.html Thu May 10 20:03:06 2012 -0400
+++ b/rdf-spaces/index.html Fri May 11 09:37:51 2012 -0400
@@ -130,12 +130,13 @@
<section id="abstract">
<p>This specification introduces the notion of RDF
<a>space</a>s—places to store RDF triples—and defines a
- set of languages for expressing information about them. Examples of
- RDF spaces include: an HTML page with embedded RDFa or microdata, a
- file containing RDF/XML or Turtle data, and a SQL database viewable
- as RDF using R2RML. RDF spaces are a generalization of SPARQL's
- <a>named graph</a>s, providing a standard model with formal
- semantics for systems which manage multiple collections of RDF data. </p>
+ set of mechanisms expressing and manipulating information about
+ them. Examples of RDF spaces include: an HTML page with embedded
+ RDFa or microdata, a file containing RDF/XML or Turtle data, and a
+ SQL database viewable as RDF using R2RML. RDF spaces are a
+ generalization of SPARQL's <a>named graph</a>s, providing a standard
+ model with formal semantics for systems which manage multiple
+ collections of RDF data. </p>
</section>
<section id="sotd">
@@ -155,7 +156,7 @@
<p>The <a href="http://www.w3.org/TR/rdf11-concepts/">Resource
Description Framework (RDF)</a> provides a simple declarative way
- to store and transmit information. It alos provides a trivial but
+ to store and transmit information. It also provides a trivial but
effective way to combine information from multiple sources, with
graph merging. This allows information from different people,
different organizations, different units within an organization,
@@ -163,16 +164,16 @@
and used together, without any special processing or understanding
of the relationships among the providers.</p>
- <p>The basic RDF merge operation may be overly simplistic, though,
- as extra processing and an understanding of the relationships
- among the providers may be useful. This document specifies a way
- to conveniently handle information coming from multiple sources,
- by modeling each one as a separate <em>space</em>, and using RDF to
- express information about these spaces. In addition to this
- important concept, we provide a pair of languages—extensions
- to existing RDF syntaxes— which can be used to store or
- transmit in one document the contents of multiple spaces as well
- as information about them.
+ <p>For some applications, the basic RDF merge operation is overly
+ simplistic, as extra processing and an understanding of the
+ relationships among the providers may be useful. This document
+ specifies a way to conveniently handle information coming from
+ multiple sources, by modeling each one as a separate
+ <em>space</em>, and using RDF to express information about these
+ spaces. In addition to this important concept, we provide a pair
+ of languages—extensions to existing RDF syntaxes—
+ which can be used to store or transmit in one document the
+ contents of multiple spaces as well as information about them.
<p>This approach allows for a variety of use cases (immediately
below) to be addressed in a straightforward manner, as shown in <a
@@ -209,40 +210,72 @@
<p>HQ decides to use RDF with the <a
href="http://www.w3.org/TR/vcard-rdf/">the vcard-rdf
vocabulary</a>. They ask each division to put an up-to-date
- directory somewhere on the Web, and mail carol@hq.example.org the
- URL. They say: "Just tell Carol the username/password if there is
+ directory somewhere on the Web, and mail kelly@hq.example.org the
+ URL. They say: "Just tell Kelly the username/password if there is
one, or make it only available to the IP address of
- dir.hq.example.org." Carol maintains a file which lists the URLs
+ dir.hq.example.org." Kelly maintains a file which lists the URLs
and any username/password combinations she is given.</p>
</blockquote>
<p>For the first iteration of the design of their directory, HQ
- builds a "harvester" which uses Carol's file for input and fetches
- all the listed data feeds. It operates behind a caching Web proxy,
- so that if the divisions set the right HTTP headers (eg Expires and
- Last-Modified) the load on their servers is minimal, even if HQ runs
- the harvester every few minutes.</p>
+ builds a "harvester" which uses Kelly's file for input and fetches
+ the content from each of the provided URLs. It operates behind a
+ caching Web proxy, so that if a division sets the right HTTP headers
+ (eg Expires and Last-Modified) the load on its servers will be
+ minimal, even if HQ runs the harvester every few minutes.</p>
<p>The harvester parses the RDF from each data source and loads it
into an in-memory triplestore, merging each new graph. Once it's
done with all the harvesting, the harvester writes out the merged
- graph into a Turtle file. The file is published (with access
- control) where it can be used by several different clients providing
- directory search services.</p>
+ graph into a <a href="http://www.w3.org/TR/turtle">turtle</a> file.
+ The file is published (with access control) where it can be used by
+ several different clients providing directory search services.</p>
- <p>Although HQ provides a Web-based client, they makes the raw
- merged data available, because the divisions have programmers and HQ
- knows people will want mobile clients, SMS-based clients,
+ <p>Although HQ provides a Web-based client, they makes this raw
+ merged data available. They know people will want many different
+ kinds of clients, include mobile clients, SMS-based clients,
command-line clients on different operating systems, and possibly
even clients that do something more sophisticated than just looking
up a phone numer. By making the raw data available, they empower
- the divisions to supply all these other applications.</p>
+ the divisions to build all these other applications.</p>
- <section>
+ <p>This "version 1" system is functional, but it has several
+ shortcomings stemming from its use of simple graph merging. The
+ following sections each discuss a shortcoming which can potentially
+ be addressed by the proper modeling of RDF <a>space</a>s. Some
+ sections include more scenarios (not involving the Example
+ Foundation's federated phonebook) which illustrate the use case.
+ Each section also links to an appendix where a detailed solution is
+ provided.
+
+ <section id="uc-reloads">
<h2>Minimizing Reloads</h2>
- <p>@@@ just change the parts that changed, allowing for very cheap updates </p>
+ <p>An obvious drawback of version 1 is that for any data change in
+ a division database to show through to the users, the harvester
+ must be re-run, to again fetch and merge all the data. HTTP
+ caching can reduce the load on the division servers, but HQ still
+ needs to parse 25 data feeds, and all the clients need to reload
+ the merged data feed.</p>
+
+ <p>At first, HQ runs the harvester once a day and explains to
+ users that it takes a day for changes to propagate. Users,
+ however, are still confused and unhappy. A user corrects her
+ phone number in the division database, then sees it still wrong
+ in the HQ database. She's not interested in hearing about
+ "propagation delay"; she wants her phone number to be correct.</p>
+
+ <p>Several different technologies are needed to fully provide this
+ feature, but for a start, it would help if the harvester could
+ maintain its state between runs and only replace those parts of
+ the output that had changed. Just storing the merged set of
+ triples is not enough; it needs to store them in such a way that
+ it can replace just the ones coming from a given source.</p>
+
+ <p>For a discussion of how this use case could be addressed, see
+ <a href="#example-reloads" class="sectionRef"></a></p>
+
</section>
<section>
@@ -311,13 +344,10 @@
<section>
<h2>Space</h2>
- <p class="issue">The term "Space" is a placeholder. The final
- term has not yet been selected by the Working Group. Other
- candidates include "G-Box", "(Data) Surface", "(Data) Layer", "Sheet", "(Data) Page". The
- Editors do not consider <a
- href="http://www.w3.org/2011/rdf-wg/meeting/2011-10-12#resolution_1">F2F2
- Resolultion 1</a> still binding, given the degree to which the concept
- and its role has shifted since that meeting.</p>
+ <p class="issue">The term "space" might change. The final
+ terminology has not yet been selected by the Working Group. Other
+ candidates include "g-box", "data space", "graph space", "(data)
+ surface", "(data) layer", "sheet", and "(data) page".</p>
<p>An RDF <dfn>space</dfn> is anything that can reasonably be said
to explicitly contain zero or more RDF triples and has an identity distinct
@@ -367,14 +397,34 @@
well-defined set of triples at any given point in time. For
example: a Web Service which returns RDF data including the
client's IP address, or a site which customizes the data
- presented based on client login cookies. See <a
- href="#hyperspaces">Hyperspaces.</a></li>
+ presented based on client login cookies. Such resources might
+ be called "hyperspaces".</li>
</ul>
</section>
<section>
+ <h2>Quad and Quadset</h2>
+
+ <p>We define an RDF <dfn>quad</dfn> as the 4-tuple
+ (<i>subject</i>, <i>predicate</i>, <i>object</i>,
+ <i>space</i>).</p>
+
+ <p>Informally, a quad should be understood as a statement that the
+ RDF triple (<i>subject</i>, <i>predicate</i>, <i>object</i>) is in
+ the <a>space</a> <i>space</i>.</p>
+
+ <p>We define an RDF <dfn>quadset</dfn> as a set containing (zero
+ or more) RDF Quads and (zero or more) RDF Triples. A quadset is
+ thus an extension to the concept of an RDF Graph (a set containing
+ zero or more RDF triples) to also potentially include statements
+ about triples being in particular spaces.</p>
+
+ </section>
+
+
+ <section>
<h2>Dataset</h2>
<p>A <dfn>dataset</dfn> is defined by <a
@@ -395,10 +445,11 @@
each query is performed against the information in a specific
dataset.</p>
- <p>A dataset is a pure mathematical structure, like an RDF Graph
- or a set of integers, with no identity apart from its contents.
- Two datasets with the same contents are in fact the same dataset,
- and one dataset cannot change over time.</p>
+ <p>Although the term is sometimes used more loosely, a dataset is
+ a pure mathematical structure, like an RDF Graph or a set of
+ integers, with no identity apart from its contents. Two datasets
+ with the same contents are in fact the same dataset, and one
+ dataset cannot change over time.</p>
<p>The word <strong>"default"</strong> in the term "default graph"
refers to the fact that in SPARQL, this is the graph a server uses
@@ -410,6 +461,71 @@
</section>
<section>
+ <h2>Named Graph</h2>
+
+ <p>SPARQL formally defines a <em>named graph</em>
+ following <b>[Carroll]</b>, to be any of the (name, graph) pairs in a
+ <a>dataset</a>.</p>
+
+ <p>In practice, the term is often used to refer to the graph part
+ of those pairs. This is the usage we follow in this document,
+ saying that a graph is a <dfn>named graph</dfn> in some dataset if
+ and only if it appears as the graph part of a (name, graph) pair
+ in that dataset. Note that "named graph" is a relation, not a
+ class: we say that something is a named graph <em>of a
+ dataset</em>, not simply that it is a named graph.</p>
+
+ <p>The term is also sometimes used to refer to the slot part of
+ the (name, slot) pairs in a <a>graph store</a>. For example, the
+ text of <a
+ href="http://www.w3.org/TR/2012/WD-sparql11-update-20120105/">SPARQL
+ 1.1 Update</a> says, "This example copies triples from one named
+ graph to another named graph". For clarity, we avoid calling
+ these "named graphs" and instead call them "named slots" of the
+ graph store.</p>
+
+ </section>
+
+
+ <section>
+ <h2>Quadset/Dataset Relationship</h2>
+
+ <p>A <dfn>quad-equivalent dataset</dfn> is a <a>dataset</a> with
+ no empty named graphs. A <dfn>non-quad-equivalent dataset</dfn>
+ is a dataset in which one or more of its named graphs is empty.
+ Every non-quad-equivalent dataset has a corresponding
+ quad-equivalent dataset formed by removing the (name, graph) pairs
+ where the graph is empty.</p>
+
+ <p><a>Quadset</a>s and quad-equivalent datasets are isomorphic,
+ and given identical declarative semantics in <a href="#semantics"
+ class="sectionRef"></a>. The isomorphism is:</p>
+
+ <ul>
+
+ <li>the triples in the quadset correspond to the triples in default
+ graph of the dataset;</li>
+
+ <li>each quad corresponds to a triple in named graph: the quad (S
+ P O Sp) corresponds to the triple (S P O) in the graph paired
+ with the name Sp.</li>
+
+ </ul>
+
+ <p>The phrasing <dfn>quads in a dataset</dfn> is thus shorthand
+ for: quads in some quadset which is isomorphic to a given dataset.
+ If the dataset is a <a>non-quad-equivalent dataset</a>, then the
+ isomorphism is to the dataset produced by removing all its empty
+ named graphs.</p>
+
+ <p>In order to promote interoperability and flexibility in
+ implementation techniques — to allow datasets and quadsets
+ to be used interchangably — systems which handle datasets
+ SHOULD NOT give significance to empty named graphs.</p>
+
+ </section>
+
+ <section>
<h2>Graph Store</h2>
<p>SPARQL 1.1 Update defines a mutable (time-dependent) structure
@@ -433,99 +549,135 @@
</section>
- <section>
- <h2>Named Graph</h2>
-
- <p>SPARQL formally defines a <dfn>named graph</dfn>,
- following <b>[Carroll]</b>, to be any of the (name, graph) pairs in a
- <a>dataset</a>.</p>
-
- <p>In practice, the term is often used more loosely to refer to
- the graph part of those pairs or to the slot part of the pairs in
- a <a>graph store</a>. For example, the text of <a
- href="http://www.w3.org/TR/2012/WD-sparql11-update-20120105/">SPARQL
- 1.1 Update</a> says, "This example copies triples from one named
- graph to another named graph".</p>
- <div class="note">
-
- <p>For clarity in this document, we call graph store slots
- "spaces", not "named graphs", so we might write: "This example
- copies triples from one of the graph store's spaces to another".
- (@@ should we call them "named spaces" in this context?)</p>
+ <section>
+ <h2>Union and Merge</h2>
- <p>We only use the term "named graph" to refer to the graph part
- of a (name, graph) pair in a dataset. It will always have an
- associated dataset. Like the term "second-place finisher", which
- means little without knowing which competition the second-place
- finish was in, the term "named graph" means little without knowing
- which dataset it is in.</p>
+ <p>RDF graphs are usually combined in one of two ways:</p>
- </div>
+ <ul>
+ <li>The <dfn>union</dfn> of two graphs is the set-union of the set of triples in each graph.</li>
+ <li>The <dfn>merge</dfn> of two graphs is the set-union of the set of triples in each graph, after any blank nodes that occur in both graphs are "renamed apart".</li>
+ </ul>
+
+ <p>This difference is not noticable when graphs are being
+ expressed in an orginary RDF syntax, like RDF/XML, RDFa, or
+ Turtle, because they provide no mechanism for transmitted two
+ graphs which have a blank node in common. The difference can
+ appear, however, in systems and languages which handle datasets or
+ in APIs which allow blank nodes to be shared between graphs.</p>
+
+ <p>We define a <dfn>union dataset</dfn> to be a <a>dataset</a> in
+ which its <a>default graph</a> is the <a>union</a> of all its
+ <a>named graph</a>s. Some systems provide special, simplified
+ handling of union datasets.</p>
+
+ <p>We define a <dfn>merge dataset</dfn> to be a <a>dataset</a> in
+ which its <a>default graph</a> is the <a>merge</a> of all its
+ <a>named graph</a>s.</p>
</section>
- <section>
- <h2>Quad</h2>
-
- <p>We define an RDF <dfn>quad</dfn> as the 4-tuple
- (<i>subject</i>, <i>predicate</i>, <i>object</i>,
- <i>space</i>).</p>
-
- <p>Informally, a quad should be understand as a statement that the
- RDF triple (<i>subject</i>, <i>predicate</i>, <i>object</i>) is in
- the <a>space</a> <i>space</i>.</p>
-
- </section>
-
- <section>
- <h2>Quadset</h2>
-
- <p>We define an RDF <dfn>quadset</dfn> as a set containing (zero or more) RDF Quads and (zero or more) RDF Triples.</p>
-
- <p>Quadsets and <a>dataset</a>s are isomorphic and semantically
- equivalent:</p>
- <ul>
+
+</section>
- <li>the triples in the quadset correspond to the triples in default
- graph of the dataset;</li>
+<section>
+ <h2>Semantics</h2>
- <li>each quad corresponds to a triple in a named graph: the quad (S P
- O Sp) corresponds to the triple (S P O) in the graph with the name
- Sp.</li>
+ <p>This section specifies a declarative semantics for <a>quad</a>s,
+ <a>quadset</a>, and <a>dataset</a>s, allowing them to be used to
+ express knowledge, especially knowledge about spaces. This makes
+ the languages defined in <a href="#syntax"
+ class="sectionRef"></a> suitable for conveying knowledge about
+ spaces and providing a foundation for addressing the challenges
+ described in <a href="#use-cases" class="sectionRef"></a>.</p>
+ <p>@@@ the section needs some revision by someone with a good ear
+ for formal semantics. We probably need to name the "containsTriple"
+ relation.</p>
+
+ <p>The basic declarative meaning of RDF quads is this:</p>
+
+ <div style="padding: 1em; border: 1px solid blue;">
+
+ <p>The RDF <a>quad</a> (s, p, o, sp) is true if and only if:</p>
+ <ol>
+ <li>I(sp) is an RDF <a>space</a>, and</li>
+ <li>The RDF triple (s, p, o) is contained in I(sp)</li>
+ </ol>
+
+ </div>
+
+ <p>The declarative meaning of a quadset is to simply read the
+ quadset as a conjunction of its quads and its triples. Given the
+ structural mapping between quadsets and datasets, it follows
+ that:</p>
+
+ <div style="padding: 1em; border: 1px solid blue;">
+
+ <p>The RDF <a>dataset</a> (DG, (n0,g0),... (ni,gi), ...(nn,gn)) is
+ true if and only if:</p>
+
+ <ol>
+ <li>DG is true according to standard RDF semantics, and</li>
+ <li>For every (ni,gi) (0<=i<=n)
+ <ul>
+ <li>I(ni) is an RDF <a>space</a>, and</li>
+ <li>every triple in gi is constained in I(ni)</li>
</ul>
-
- <p>Datasets and quadsets can thus be used interchangeably, with
- the more appropriate one being use in any particular context.</p>
+ </li>
+ </ol>
- <p class="note">This is not quite true, in that a dataset can
- contain the empty graph, which has no exact correspondence to
- anything in a quadset. In practice, in SPARQL, implementations
- are free to use quadset semantics. @@@ How can we formalize that
- here?</p>
+ <p>The RDF dataset (DG), the dataset with no named graphs, is true
+ if and only if DG is true according to standard RDF semantics.</p>
- </section>
+ </div>
+
+ <p>It follows from these definitions that a (name,graph) pair in a
+ dataset where the graph is the empty graph has no effect on the
+ meaning of the dataset. This matches the SPARQL specifications
+ which note that implementations are free to remove empty named
+ graphs from datasets.</p>
+
+ <p>It also follows that a dataset with no names graphs and a quadset
+ with no quads have the same declarative meaning as the RDF graph
+ which is the default graph of the dataset or the set of triples in
+ the quadset. This makes dataset languages natural extensions of the
+ RDF syntaxes.</p>
+
+ <p class="note">
+ We say nothing here about the fact that the truth value of a quad
+ is likely to change over time. Time is orthogonal to RDF
+ semantics, and quads present no fundamentally different challenge
+ here than vcard, since people change addresses just like triples
+ are added to and removed from spaces. Some approaches to handling
+ change-over-time are discussed in <a href="#example-valid-time"
+ class="sectionRef"></a> and <a href="#example-transaction-time"
+ class="sectionRef"></a>.
+ </p>
+
+ <p class="issue">Do the named graphs in a dataset include all the
+ triples in the spaces with those names, or only some of them? Aka
+ partial-graph or complete-graph semantics. Assuming partial, but
+ maybe we can say something about how things SHOULD be done?</p>
</section>
+
<section id="syntax">
<h2>Dataset Languages</h2>
<p>This section contains specifications of languages for serializing
- datasets. N-Quads documents and Trig documents have identical
- semantics, since they each are just serializations of the datasets
- and therefore follow <a href="#semantics"
+ <a>quad-equivalent dataset</a>s. N-Quads documents and Trig
+ documents have identical semantics, since they each serialize the
+ same structure and follow <a href="#semantics"
class="sectionRef"></a>.</p>
<p>Dataset information may also be conveyed and manipulated using
SPARQL or using RDF triple-based tools and languages as per <a
href="#reflection-vocabulary" class="sectionRef"></a>.</p>
- <p>@@@ Maybe call these quad languages?</p>
-
-
<section>
<h3>N-Quads</h3>
@@ -746,87 +898,6 @@
</section>
</section>
-<section>
- <h2>Semantics</h2>
-
- <p>This section specifies a declarative semantics for <a>quad</a>s,
- <a>quadset</a>, and <a>dataset</a>s, allowing them to be used to
- express knowledge, especially knowledge about spaces. This makes
- the languages defined in <a href="#syntax"
- class="sectionRef"></a> suitable for conveying knowledge about
- spaces and providing a foundation for addressing the challenges
- described in <a href="#use-cases" class="sectionRef"></a>.</p>
-
- <p>@@@ the section needs some revision by someone with a good ear
- for formal semantics.</p>
-
- <p>The basic declarative meaning of RDF quads is this:</p>
-
- <div style="padding: 1em; border: 1px solid blue;">
-
- <p>The RDF <a>quad</a> (s, p, o, sp) is true if and only if:</p>
- <ol>
- <li>I(sp) is an RDF <a>space</a>, and</li>
- <li>The RDF triple (s, p, o) is contained in that space</li>
- </ol>
-
- </div>
-
- <p>The declarative meaning of a quadset is to simply read the
- quadset as a conjunction of its quads and its triples. Given the
- structural mapping between quadsets and datasets, it follows
- that:</p>
-
- <div style="padding: 1em; border: 1px solid blue;">
-
- <p>The RDF <a>dataset</a> (DG, (n0,g0),... (ni,gi), ...(nn,gn)) is
- true if and only if:</p>
-
- <ol>
- <li>DG is true according to standard RDF semantics, and</li>
- <li>For every (ni,gi) (0<=i<=n)
- <ul>
- <li>I(ni) is an RDF <a>space</a>, and</li>
- <li>every triple in gi is in that space</li>
- </ul>
- </li>
- </ol>
-
- </div>
-
- <p>It follows from these definitions that a (name,graph) pair in a
- dataset where the graph is the empty graph has no effect on the
- meaning of the dataset. This matches the SPARQL specifications
- which note that implementations are free to remove empty named
- graphs from datasets.</p>
-
- <p>It also follows that a dataset with no names graphs and a quadset
- with no quads have the same declarative meaning as the RDF graph
- which is the default graph of the dataset or the set of triples in
- the quadset. This makes dataset languages natural extensions of the
- RDF syntaxes.</p>
-
- <p>@@@ define "strip"["narrow"?], "union", "merge", and
- "reflect"[fold?] as functions mapping from datasets to graphs; and
- "unreflect"[unfold?] and "splay"/widen/...? as mapping the other
- directions.</p>
-
- <p class="note">
- We say nothing here about the fact that the truth value of a quad
- is likely to change over time. Time is orthogonal to RDF
- semantics, and quads present no fundamentally different challenge
- here than vcard, since people change addresses just like triples
- are added to and removed from spaces. Some approaches to handling
- change-over-time are discussed in @@@ some use cases
- </p>
-
- <p class="issue">Do the named graphs in a dataset include all the
- triples in the spaces with those names, or only some of them? Aka
- partial-graph or complete-graph semantics. Assuming partial, but
- maybe we can say something about how things SHOULD be done?</p>
-
-</section>
-
<section> <!-- I don't like what respec does with id=conformance -->
<h2>Conformance</h2>
@@ -837,15 +908,30 @@
</section>
-<section class="informative">
+<section class="informative appendix">
+
<h2>Detailed Example</h2>
- <p>@@@ this needs to be updated to just show the results of the
- problems described in the Use Cases section.</p>
+ <p>This section presents a design for using <a>space</a>s in constructing a
+ federated information system. It is intended to help explain and
+ help motivate the designs specified in this document.</p>
- <p>This section presents a design for using spaces in constructing a
- federated information system. It is intended to help explain and
- motivate RDF <a>data space</a>s.</p>
+ <p>The example covers the same federated phonebook scenario used in
+ <a href="#use-cases" class="sectionRef"></a>, with each specific use
+ case having an example here.</p>
+
+ <p class="alert">@@@ Most of this "Detailed Example" section is
+ older and needs re-writing to be synchronized with changes made in
+ the Use Cases.</p>
+
+
+ <section id="example-reloads">
+ <h2>How to Minimize Reloads</h2>
+
+ <p>To address the needs described in <a href="#uc-reloads"
+ class="sectionRef"></a> ... @@@ </p>
+
+ </section>
<section>
<h3>A Federated Phonebook</h3>
@@ -1322,6 +1408,7 @@
<section class="appendix informative" id="changes">
<h2>Changes</h2>
<ul>
+ <li>2012-05-11: Rewriting and reorganizing Concepts; some more work on Usecases and Example.</li>
<li>2012-05-10: Wrote a short intro. Started writing the Use Cases section for real. Added grammar for N-Quads and Trig. Did a first draft of the semantics.</li>
<li>2012-05-09: Renamed "layers" as "spaces"; some word-smithing in Concepts and the Abstract; removed "Turtle in HTML" as a dataset syntax; added some text about trig and nquads; added a note about change-over-time; added an appendix with a reflection vocabulary</li>
<li>2012-05-02: Removed obsolete text from the introduction, removed the section on datasets borrowed from RDF Concepts, and added many entries to Concepts (and renamed it from Terminology).</li>