--- a/rdf-spaces/index.html Fri May 11 10:05:35 2012 -0400
+++ b/rdf-spaces/index.html Fri May 11 14:07:28 2012 -0400
@@ -598,64 +598,79 @@
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>
+ for formal semantics, and probably some references to the old and/or new versions of RDF Semantics.</p>
- <p>The basic declarative meaning of RDF quads is this:</p>
+ <p>The fundamental notion of RDF spaces is that they can contain
+ triples. This is formalized with the relation CT(S, T) which is
+ informally understood to hold for any triple T and space S such that
+ S explicitely contains T.</p>
+
+ <p>The basic declarative meaning (that is, the truth condition) 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>
+ <p>The RDF <a>quad</a> (s, p, o, sp) is true in I if and only if CT(I(sp), triple(s, p, o)).</p>
</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>
+ structural mapping between quadsets and datasets, the truth
+ condition for datasets follows:</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>
+ <p>The RDF <a>dataset</a> (DG, (N1,G1),... (Ni,Gi), ...(Nn,Gn)) is
+ true in I 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)
+ <li>DG is true in I, and</li>
+ <li>For every (Ni,Gi) (1<=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>
+ <li>For every triple T in Gi:
+ <ul>
+ <li>CT(I(Ni),T)</li>
+ </ul>
+ </li>
</ul>
</li>
</ol>
- <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>
-
</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>Some implications of these truth conditions: </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>
+ <ul>
+
+ <li><p>A dataset with no named graphs has the same declarative
+ meaning as its default graph. A quadset with no quads has the
+ same declarative meaning as the RDF graph consisting of the
+ triples in the quadset. </p><p>This fits the intuition that datasets and
+ quadsets are extensions of RDF Graphs and applies to the syntax as
+ well: a Trig document without any named graphs is syntactically
+ and semantically a Turtle document; an N-QUads document without
+ any quads is syntactically and semantically an N-Triples
+ document.</p></li>
+
+ <li>
+ <p>The empty named graphs in a <a>non-quad-equivalent dataset</a>
+ have no effect on its meaning. Replacing such a dataset with its
+ equivalent without the empty named graphs does not change its
+ meaning.</p>
+ </li>
+
+ </ul>
<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
+ semantics, and quads present no fundamentally different issue
+ here. When the world changes state, the truth value of RDF
+ triples or quads might change. This occurs when a triple is put
+ in or taken out of a space, but it also occurs with "normal" RDF
+ when, for instance, someone changes their address and different
+ vcard triples about them become true. 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>.
@@ -680,7 +695,7 @@
<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>
+ href="#folding" class="sectionRef"></a>.</p>
<section>
<h3>N-Quads</h3>
@@ -886,6 +901,7 @@
<div class="issue">
<p>There are several open issues concernting Trig syntax:</p>
<ul>
+ <li>Should we call this something other than Trig, since it's a bit different? Qurtle? Mugr (multi-graph-rdf)? Turtle2? </li>
<li>Are braces around default-graph triples required,
optional, or disallowed? Assuming "optional" for now.</li>
<li>Is the name prefixed by a keyword? If so, is the
@@ -905,10 +921,8 @@
<section> <!-- I don't like what respec does with id=conformance -->
<h2>Conformance</h2>
- <p>@@@ what to say here? Maybe including something like: If a space
- has a URL, and you get a 200 response dereferencing that URL, the
- the response MUST be a serialization of the triples on that space,
- give or take synchronization (caching) issues. </p>
+ <p>@@@ what to say here? What kind of think might conform or not
+ conform to this spec?</p>
</section>
@@ -924,9 +938,16 @@
<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
+ <div class="alert">
+ <p>@@@ Most of this "Detailed Example" section is
older and needs re-writing to be synchronized with changes made in
the Use Cases.</p>
+
+ <p>
+ See the <a
+ href="http://dvcs.w3.org/hg/rdf/raw-file/ee60c6dc8ad4/rdf-spaces/index.html#">May 10 Version</a> for a now-obsolete run-through of the example.
+ </p>
+ </div>
<section id="example-reloads">
@@ -936,371 +957,49 @@
class="sectionRef"></a> ... @@@ </p>
</section>
-
- <section>
- <h3>A Federated Phonebook</h3>
-
- <p>As a first example of how to use spaces, consider an
- organization which has 25 different divisions around the world,
- each with its own system for managing the list of its employees
- and their phone numbers. The parent organization wants to create
- a unified "HQ" directory with all this information. With their HQ
- directory, they will be able to look up an employee's phone number
- without first knowing the employee's division. </p>
-
- <p>They decide to use RDF spaces. Each division is asked to
- publish its phonebook on an internal website, in a W3C-Recommended
- RDF syntax, using <a href="http://www.w3.org/TR/vcard-rdf/">the
- vcard-rdf vocabulary</a>. Each division submits the URL at which
- this file will appear. For example, the uswest division might
- publish the RDF version of its phonebook at
- <tt>http://uswest.internal.example.com/employees.rdf</tt> and the
- Japan division might publish theirs at
- <tt>http://ja.example.com/hr/data/export371</tt>. The URL itself
- doesn't matter, but the division must be able to maintain the
- content served there and HQ must be able to easily fetch the
- content. </p>
-
- <p>The HQ staff assembles this list of 25 feed URLs and puts them
- into the default graph of a SPARQL database, so the database looks
- like this: </p>
-
-<pre> @prefix hq: <<a href="http://example.com/hq-vocab#">http://example.com/hq-vocab#</a>>.
- # default graph
- {
- hq:parentCo hq:division hq:div1, hq:div2, hq:div3, ...
- <<a href="http://uswest.internal.example.com/employees.rdf">http://uswest.internal.example.com/employees.rdf</a>>
- hq:feedFrom hq:div1.
- <<a href="http://ja.example.com/hr/data/export371">http://ja.example.com/hr/data/export371</a>>
- hq:feedFrom hq:div2.
- ...
- }
-</pre>
-<p>Then they write a simple Web client which looks in the database for
-those feed URLs, dereferences them, and parses the RDF. It then puts
-the parse-result into the database in a space whose name is the same as the
-name of the feed. This makes sense, because in this deployment each
-feed is considered to be a space; the name of the feed is the same as
-the name of the space. The HQ client is copying data about the space
-from the division databases to the HQ database, but it's still the
-same information about the same spaces.
-</p>
-
-<p>For performance reasons, the client is designed to use HTTP
-caching information. This will allow it to efficiently re-fetch the
-information only when it has changed. To make this work, the client will need
-to store the value of the "Last-Modified" HTTP header and also store
-(or compute, in some configurations) the value of the "Expires" header.
-</p>
-
-<p>In the end, the database looks something like this:
-</p>
-<pre> @prefix hq: <<a href="http://example.com/hq-vocab#">http://example.com/hq-vocab#</a>>.
- @prefix v: <<a href="http://www.w3.org/2006/vcard/ns#">http://www.w3.org/2006/vcard/ns#</a>>.
- @prefix ht: <<a href="http://example.org/http-vocab#">http://example.org/http-vocab#</a>>.
- <<a href="http://uswest.internal.example.com/employees.rdf">http://uswest.internal.example.com/employees.rdf</a>> {
- # an employee
- [ a v:VCard
- v:fn "John Wayne" ;
- v:email "wayne@uswest.example.com" .
- v:tel [ a v:Work, v:Pref ;
- rdf:value "+213 555 5555" ]
- ]
- # another employee
- ...
- }
- <<a href="http://ja.example.com/hr/data/export371">http://ja.example.com/hr/data/export371</a>> {
- # an employee
- [ a v:VCard
- v:fn "Toshiro Mifune" ;
- v:email "wayne@uswest.example.com" .
- v:tel [ a v:Work, v:Pref ;
- rdf:value "+81 75 555 5555" ]
- ]
- # another employee
- ...
- }
- ... other divisions
- # default graph, with all our metadata
- {
- hq:parentCo hq:division hq:div1, hq:div2, hq:div3, ...
- # stuff we need to know the efficiently keep our copy in sync
- <<a href="http://uswest.internal.example.com/employees.rdf">http://uswest.internal.example.com/employees.rdf</a>>
- hq:feedFrom hq:div1;
- ht:last-modified "2012-03-14T02:22:10"^^xs:datetime;
- ht:expires "2012-04-29T00:15:00"^^xs:datetime.
- <http://ja.example.com/hr/data/export371>
- hq:feedFrom hq:div2;
- ht:last-modified "2012-04-01T22:00:00"^^xs:datetime;
- ht:expires "2012-04-29T00:35:00"^^xs:datetime.
- }
-</pre>
-<p>The URL of each space appears in four different roles in this example:
-</p>
-
-<p>1. It is used as a label for a graph. Here, it says which space the
-triples in that graph are in. That is, the triples about employee
-"John Wayne" are in the space named
-"http://uswest.internal.example.com/employees.rdf". Information about
-what triples are in that space originates in the master database for
-each division, then is copied to the slave database at HQ.
-</p>
-
-<p>2. It is used as the subject of an hq:feedFrom triple. This
-information is manually maintained (or maintained through a corporate
-WebApp) and used to help guide the HQ fetching client. Because in
-this deployment we are equating spaces and feeds, the name of the
-space is also the URL of the feed.
-</p>
-
-<p>3. It is used as the subject of an ht:last-modified triple. The
-information in this triples comes from the HTTP Last-Modified header.
-The meaning of this header in HTTP lines up well with its intuitive
-meaning here: this is the most recent time the set of triples in this
-space changed. (This header can be used during a refresh, with the
-If-Modified-Since headers, to make a client refresh operation very
-simple and fast if the data has not changed.)
-</p>
-
-<p>4. It is used as the subject of an ht:expires triple. This
-information also comes from HTTP headers, although some computation
-may be needed to turn it into the absolute datetime form used here.
-Strictly speaking, what is expiring at that time is this copy of the
-information about the space, not the space itself. This slight
-conflation seems like a useful and unproblematic simplification.
-</p>
-
-<p>Given this design, it is straightforward to write SPARQL queries to
-find the phone number of an employee, no matter what their division.
-It is also easy to find out which space is about to
-expire or has expired and should be refreshed soon.
-</p>
-
-<p>Some alternative designs:
-</p>
-<ul><li> Divisions could push their data, instead of waiting to be polled. That is, the divisions could be given write access to the HQ database and do SPARQL UPDATE operations to their own spaces. This is simpler in some ways but may require more expertise from people in each division. It also requires trusting people in each division or having a SPARQL server that can be configure to grant certain users write access to only certain spaces. This also turns HQ into more of a bottleneck and single-point of failure. With the polling approach, other systems could be given the list of feed URLs and then offer an alternative combined directory, or use the same data for other purposes, without any involvement from the divisions.
-</li></ul>
-<ul><li> The HQ client could fetch or query all the divisions at query time, rather that gathering the data in advance. This might use the <a href="http://www.w3.org/TR/sparql11-federated-query/">SPARQL 1.1 Federated Query</a> features. Which approach is superior will depend on the particulars of the situation, including how large the data is, how often it changes, and the frequency of queries which need data from different divisions. Federated Query would probably not be ideal for the situation described here, but should be considered by people building systems like this.
-</li></ul>
-
- </section>
- <section>
- <h3>Cache Management Using HTTP</h3>
-
- <p class="note">Factor out the Last-Modified and Expires stuff,
- from the previous section, and put it here.</p>
-
- <p class="note">Show that instead of expires like this, it could
- be done with [an Expiration; inDataset <>; atTime ...;
- ofSpace]</p>
-
-
- </section>
-
-
- <section>
- <h3>Keeping Derived Information Separate</h3>
-
- <p>The Federated Phonebook example shows several features of
- spaces, but leaves out a few. In this example we will show the
- use of privately-named spaces and of sharing blank nodes between
- spaces.</p>
-
- <p>The scenario is this: some divisions use only vcard:n to
- provide structured name information (keeping given-name and
- family-name separate), while others use only vcard:fn to provide a
- formatted-name (with both parts combined). The politics of the
- organization make it impractical to tell the divisions to all use
- vcard:n or all use vcard:fn, or both. Meanwhile, several
- different tools are being written to use this employee directory,
- including a WebApp, a command-line app, and apps for several
- different mobile platforms. Does each app have to be written to
- understand both vcard:n and vcard:fn? </p>
-
- <p>HQ decides the solution is for them to run a single process
- (which they call "namefill") to normalize the data, making
- sure that every entry has both vcard:n and vcard:fn data, no
- matter what the division provided. The process is fairly simple;
- after any space is reloaded, a program runs which looks at that
- space and fills in the missing name data. </p>
-
- <p>Because of the tricky politics of the situation, however, HQ
- decides it would be best to keep this "filled in" data separate.
- In some cases their program might not fill in the data properly.
- For example, how can a program tell from the formatted name
- "Hillary Rodham Clinton" that "Rodham Clinton" is the family-name?
- The solution is to keep the output of the program in a separate
- space, so clients (and people trying to debug the system) can tell
- this filled-in data did not come from the division itself. </p>
-
- <p>The result is a dataset like this:
- </p>
-
- <pre class="example">@prefix hq: <http://example.com/hq-vocab#>.
-@prefix v: <http://www.w3.org/2006/vcard/ns#>.
-@prefix ht: <http://example.org/http-vocab#>.
- <http://uswest.internal.example.com/employees.rdf> {
- # an employee
- _:u331 a v:VCard
- v:fn "John Wayne" ;
- v:email "wayne@uswest.example.com" .
- v:tel [ a v:Work, v:Pref ;
- rdf:value "+213 555 5555" ].
- ...
- }
- hq:namefill602 {
- _:u331 v:n [
- v:family-name "Wayne";
- v:given-name "John"
- ]
- }
- ...
- # default graph has metadata
- {
- hq:parentCo hq:division hq:div1, hq:div2, hq:div3, ...
- <http://uswest.internal.example.com/employees.rdf>;
- hq:feedFrom hq:div1;
- hq:namefillSpace hq:namefill602
- ...
- }
-</pre>
-
-<p>In serializing this, we needed to introduce a blank node label
-("_:u331"), because that blank node (representing the employee) occurs
-in two different spaces.
-</p>
-
-<p>The example also shows the creation of a new space name
-(hq:namefill602) for the space filled in by our namefill program. We
-use one new space for each feed, instead of one space for all the
-output of the namefill program, so we have less work to do when a
-single feed space is reloaded.
-</p>
-
-<p>The techniques in this example apply equally well to information that
-is derived as part of logical inference, such as done by an RDFS, OWL,
-or RIF reasoner. In these more general cases, it may be that one
-space can be used for all derived information, or, at the other end of
-the granularity spectrum, that a new space is used for the triples
-derived in each step of the process.
-</p>
-
- </section>
- <section>
- <h3>Archiving Data With Static Spaces</h3>
-
- <p>One more variation on the federated phonebook scenario: what if
- HQ wants to be able to look up old information? For instance,
- what happens when an employee leaves and is no longer listed in a
- division phonebook? It could be nice if the search client could
- report that the employee is gone, rather than leaving people
- wondering it they've made a mistake with the name. </p>
-
- <p>To address this, HQ's data-loading client will not simply
- delete a space before reloading it. Instead, it will first copy
- the data to a new, archival space. After three reloads, the
- database might look something like this: </p>
-
-<pre class="example">@prefix hq: <http://example.com/hq-vocab#>.
-@prefix hqa: <http://example.com/hq/archive/>
-@prefix v: <http://www.w3.org/2006/vcard/ns#>.
-@prefix ht: <http://example.org/http-vocab#>.
-hqa:0001 {
- ... oldest version
-}
-hqa:0002 {
- ... middle version
-}
-<http://uswest.internal.example.com/employees.rdf> {
- ... current version
-}
-# default graph
-{
- hqa:0001 hq:startValidTime ...time... ;
- hq:endValidTime ...time... .
- hqa:0002 hq:startValidTime ...time... ;
- hq:endValidTime ...time... .
- <http://uswest.internal.example.com/employees.rdf>
- hq:snapshot hqa:0001, hqa:0002.
- ....
-}
-</pre>
-
-<p>This model uses static spaces, whose contents are never supposed to
-change. (They are still different from RDF Graphs in that they retain
-their own identity; two static spaces containing the same triples can
-have different metadata.) For each static space, we record the time
-interval for which it was current (its
-<a href="http://en.wikipedia.org/wiki/Valid_time">valid time</a>) and what it is a
-snapshot of.
-</p>
-
-<p>The URL for each static space is generated by incrementing a sequence
-counter. To follow Linked Data principles, HQ should provide RDF
-serializations of the contents of each space in response to
-dereferences of these URLs. (When the state of spaces is
-obtained like this, with separate HTTP responses for each one, a blank
-node appearing on multiple spaces will appear as multiple blank nodes.
-For blank node sharing to work, the dataset which serializes the
-contents of all the relevant spaces must be transmitted or queried as
-a unit.)
-</p>
-
-<p>There is nothing about this architecture that prevents the archival
-data from being modified. The people maintaining the system simply agree
-not to change it. If this is not sufficient, other approaches could
-be designed, such as generating the URL using a cryptographic hash of
-the space contents.
-</p>
-
-<p>Another variant on this design is to put the feed data directly into
-an archival space, instead of having the current data in a the same
-space as the feed.. If the data is likely to grow stale (not be kept
-in sync with the feed master data), this may be a better approach,
-reducing the possibility of people unknowingly using outdated
-information.
-</p>
-
-</section>
</section>
-
- <section class="appendix">
- <h2>Reflection Vocabulary</h2>
-
- <p class="note">This section is entirely novel/experimental at
- this time. Might be better called "FOLDING" and "UNFOLDING".</p>
+ <section class="appendix" id="folding">
+ <h2>Folding</h2>
- <p>This section specifies an RDF vocabulary for conveying datasets
- in RDF Graphs. This is done by describing—in RDF
- triples—the specific structures occuring in a given dataset.
- This technique is sometimes called <dfn>reflection</dfn> or
- <dfn>reification</dfn>. This vocabulary is distinct from the
- 1999/2004 RDF reification vocabulary; we prefer to use the term
- "reflection" to help maintain the separation.</p>
+ <p class="note">This section is experimental.</p>
- <p>This vocabulary allows systems to convey datasets using normal
- triple-based RDF machinery, including RDF/XML, Turtle, and RDFa,
- when necessary. In general, in systems where languages and APIs
- are available which directly support datasets, this vocabulary is
- not useful.</p>
+ <p>This section specifies a mechanism and an RDF vocabulary for
+ conveying <a>quad</a>s/<a>dataset</a>s using ordinary RDF Graphs
+ instead of special syntaxes and/or interfaces. The mechanism is
+ somewhat similar to reflection or reification. The idea is to
+ express each quad using a set of triples using a specialized
+ vocabulary.</p>
- <p>As an example, the quad [ eg:subject eg:predicate eg:object1
- eg:space1 ] can be expressed in Turtle using this vocabulary:</p>
+ <p>Folding allows quads and thus datasets to be conveyed and
+ manipulated using normal triple-based RDF machinery, including
+ RDF/XML, Turtle, and RDFa, but at the cost of some complexity,
+ storage space, and performance. In general, in systems where
+ languages or APIs are available which directly support datasets,
+ folding is neither required nor useful.</p>
+
+ <p>As an example, the dataset
+
+ <pre class="example">
+@prefix : <http://example.org/>.
+:space { eg:subject eg:predicate eg:object }
+ </pre>
+
+ would fold to these triples:
<pre class="example">@prefix : <http://example.org/>.
-:space1 rdf:containsTriple [
+:space rdf:containsTriple [
a rdf:Triple;
rdf:subjectIRI "http://example.org/subject";
rdf:predicateIRI "http://example.org/predicate";
- rdf:objectIRI "http://example.org/object1";</pre>
+ rdf:objectIRI "http://example.org/object";</pre>
<p>The terms in the triple are encoded (turned into literal
strings, in this example), to provide referential opacity. In the
- semantics of quads, it does not follow from [a b c d] and a=aa that
- [aa b c d]. Without this term-encoding, that conclusion <em>would</em>
- follow from the reflection.</p>
+ semantics of quads, it does not follow from (a b c d) and a=aa that
+ (aa b c d). Without this encoding of terms as strings, that
+ conclusion would erroneously follow from the folded quad..</p>
<p>Terms in this vocabulary:</p>
@@ -1355,47 +1054,54 @@
<p>This vocabulary is used in a specific template form, always
matching this SPARQL graph pattern: </p>
- <pre>[] a rdf:Triple;
+ <pre>?sp rdf:containsTriple [
+ a rdf:Triple;
rdf:subjectIRI|rdf:subjectNode ?s;
rdf:predicateIRI ?p;
- rdf:objectIRI|rdf:objectNode|rdf:objectValue ?o;
- rdf:inSpace ?sp</pre>
+ rdf:objectIRI|rdf:objectNode|rdf:objectValue ?o
+]</pre>
<p>This one template uses SPARQL 1.1 property paths, with
alternation using the "|" character. It could also be expressed as
- six different SPARQL 1.0 graph patterns.</p>
+ six different SPARQL 1.0 (non-property-path) graph patterns.</p>
<p>The terms in this vocabulary only have fully-defined meaning
when they occur in the template pattern. When they do, the set of
triples matching the template has the same meaning as the
<a>quad</a> [ ?s ?p ?o ?sp ].</p>
- <p><dfn>Reflecting a dataset</dfn> is the act of completely
+ <p><dfn>Folding a dataset</dfn> is the act of completely
conveying the facts in a dataset in RDF triples, using this
- reflection vocabulary. The procedure is: (1) check for occurances
- of the reflection template in the default graph -- if they occur,
- abort, since reflection is not defined for this dataset; (2) copy
+ vocabulary. The procedure is: (1) check for occurances
+ of the fold template in the default graph -- if they occur,
+ abort, since folding is not defined for this dataset; (2) copy
the triples in the default graph of the input to the output; (3)
for each quad in the input, generate a matching instance of the
- reflection template and put the resulting five triples in the
+ fold template and put the resulting five triples in the
output.</p>
- <p><dfn>Unreflecting a dataset</dfn> is the act of turning an RDF
- graph into a dataset, using this reflection vocabulary. The
+ <p><dfn>Unfolding a dataset</dfn> is the act of turning an RDF
+ graph into a dataset, using this vocabulary. The
procedure is: (1) make a mutable copy of the input graph, (2) for
- each match of the reflection template, add the resulting quad to the
+ each match of the fold template, add the resulting quad to the
output dataset and delete the five triples which matched the
template, (3) copy the remaining triples to the output as the
default graph of the dataset.</p>
- <p>The reflect and unreflect functions are inverses of each other.
- That is, for all datasets D on which reflect is defined, D =
- unreflect(reflect(D)) and for all graphs G, G =
- (reflect(unreflect(G)). The functions are also essentially
- idempotent. If we align their domains and ranges by considering a
- graph to be dataset which has only its default graph, then
- reflect(D) = reflect(reflect(D)) and unreflect(G) =
- unreflect(unreflect(G))</p>
+ <p>The fold and unfold functions are inverses of each other.
+ That is, for all datasets D on which fold is defined, D =
+ unfold(fold(D)) and for all graphs G, G =
+ (fold(unfold(G)).</p>
+
+ <p>The functions cannot be composed with themselves (called
+ recursively), since for each of them the domain and range are
+ disjoint. If we were to implicitely convert graphs to datasets
+ (with the graph as the default graph), then fold(fold(D)) would
+ either be an error (if D had any named graphs) or be the same as
+ fold(D). If we were to define unfold2 as an unfold operating on
+ datasets using their default graphs, unfold2(D) = union(D,
+ unfold(default_graph(D)), then unfold2 would be idempotent:
+ unfold2(D) = unfold2(unfold2(D)).</p>
</section>
@@ -1412,7 +1118,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-11: Rewriting and reorganizing Concepts; some more work on Usecases and Example; removed the Detailed Example since it needs to be so re-written; renamed 'reflection' to 'folding'; reworked the Semanics</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>