Merge pull request #132 from LD4/section_6

Section 6 - Merge in Dave's changes

docs/0.1/index.md

@@ -877,7 +877,19 @@ For each change create a separate [Entity Change Activity](#entity-change-activi
 ## 6. Consuming Entity Change Sets
 {: #consuming-entity-change-sets}
 
-### 6.1 Example consuming Library of Congress Activity Stream
+Activity streams are inherently temporal constructs, and as such, the order of presentation in a stream may be _forward_ (i.e. the starting point
+in the stream reflects its oldest elements and consuming the stream involves newer and newer elements) or it may be _reverse_ (i.e. the starting
+point in the stream reflects its most recent elements and consuming the stream involves older and older elements). Likewise, the content of a given page in the stream may be _immutable_ (i.e. once published the content of a given page never changes) or it may be _mutable_ (i.e. the content of a given page can be updated and can differ from release to release). This specification espouses
+no preference of either approach. Rather example approaches to each are presented below.
+
+| | Forward | Reverse |
+| --- | --- | --- |
+| **Mutable** | **Mutable Forward** Pages can be updated, and the content of a given page can differ by release. Older pages appear earlier in the stream than newer pages. | **Mutable Reverse** Pages can be updated, and the content of a given page can differ by release. Older pages appear later in the stream than newer pages. |
+| **Immutable** | **Immutable Forward** Once published, pages never change. Older pages appear earlier in the stream than newer pages. | **Immutable Reverse** Once published, pages never change. Older pages appear later in the stream than newer pages. |
+
+Of these four possibilities, we describe _mutable reverse_, of which the Library of Congress is an example, and _immutable forward_, of which Getty is an example. Regarding the remaining two possibilities, _mutable forward_, while feasible, requires the entire stream to be processed at each release, as there is no way of establishing where in the stream a change might occur. _Immutable reverse_ is inherently infeasible, as it requires that new content appear first, but on a page that cannot be changed.
+
+### 6.1 Consuming a _mutable reverse_ stream (e.g. Library of Congress)
 
 _CAUTION: This section is under construction. This section may or may not be removed from the final draft, in lieu of, a section that is a general example._
 
@@ -952,6 +964,39 @@ LOOP
 end
 ```
 
+### 6.2 Consuming an _immutable forward_ stream (e.g. Getty)
+
+Characteristics:
+* an entity will appear in the activity stream one or more times
+* the first page of the stream has the oldest activities
+* activities on a page are listed from oldest to newest
+* the date of an activity is the time of that given modification
+
+Assumptions:
+* the consumer fully processes all activities appearing in a given page in the stream
+* the consumer maintains a persistent reference to the last page processed in the stream (last_page)
+
+Pseudocode:
+```
+go to the activity stream
+current = activity.last_page
+
+while (current.next != null)
+  for each activity in current
+    process activity by type
+  end
+end
+```
+
+### 6.3 Discussion
+
+The Library of Congress mutable reverse approach is inherently the most compact, as any given entity appears in the stream exactly once, at its most recent
+point of modification. However, this is accomplished by completely regenerating the activity stream in its entirety whenever new content is
+made available. The Getty immutable forward approach yields pages that are immutable - once issued a page will never be altered - with new content
+appearing incrementally on new pages attached to the end of the pages comprising the stream. Any given entity may appear multiple times in the
+stream, reflecting the number of modifications it has undergone over its life, and each appearance need only update the entity rather than
+provide a complete representation.
+
 ## Acknowledgements
 
 We are grateful to all participants in the LD4 [Best Practices for Authoritative Data Working Group](https://wiki.lyrasis.org/x/pgFrD), within which this specification was created. [E. Lynette Rayle](https://orcid.org/0000-0001-7707-3572) (formerly at Cornell University) led the initial development of this specification. [Jim Hahn](https://orcid.org/0000-0001-7924-5294) (University of Pennsylvania Libraries), [Kirk Hess](https://orcid.org/0000-0002-9559-6649) (OCLC R&D), [Anna Lionetti](https://orcid.org/0000-0001-6157-8808) (Casalini Libri), [Tiziana Possemato](https://orcid.org/0000-0002-7184-4070) (Casalini Libri), and [Erik Radio](https://orcid.org/0000-0003-0734-1978) (University of Colorado Boulder) also contributed to this work.