1. Design Spaces for Link and Structure Versioning Jim Whitehead U.C. Santa Cruz ejw@soe.ucsc.edu www.soe.ucsc.edu/~ejw/

2. Hypertext Versioning  Hypertext versioning is concerned with storing, retrieving, and navigating prior states of hypertext linked complex information artifacts  High value use cases: ³Software engineering: Capture relationships in project documents & source code during development. Aids traceability, understanding, maintenance. ³Document management: Capture relationships in large collections of evolving documents. ³Legal: Laws, regulations, tax codes change yearly, and are very inter-related. Need to access versions at time of infraction. ³Archival: Record the evolution of hypertexts for historical & audit purposes. Web way-back machines.  Hypertext use is limited due to absence of systematically organized knowledge about hypertext versioning.

3. Design Spaces  Many different hypertext versioning systems have been created ³Hypermedia Version Control Framework, CoVer, VerSE, HyperPro, HyperProp, HyperDisco, HyperForm, Rhythm, Palimpsest, VTML, Xanadu  Begs the question ³How can we characterize and compare their approaches to hypertext versioning in a consistent way?  Approach: systems exist at points in multiple design spaces ³Containment ³Persistent Representation of Revision History ³Link Versioning ³Structure Versioning

4. Containment Design Space

5. Containment  Containment is common in our daily lives ³Backpacks, purses, bags, boxes, suitcases, etc. ³Items are physically contained (inclusion containment)  Computers can replicate objects easily, at low cost ³Dramatically increases value of referential containment ŸPoint to object instead of including object  Containment is the most common relationship in the data models of hypertext versioning systems ³Links, versioned objects, workspaces, compound documents, user-defined collections … all are containers  To understand the relationships between entities in a hypertext versioning system, you must understand containment.

6. Basic Static Containment  Container: a set of persistently stored objects  Aspects of containment model: ³Abstract properties ŸMathematic set properties independent of a specific computer representation ŸContainment: object belongs to one set (single) or many (multiple) ŸMembership: each object can belong to a set once (single), or many (multiple) times ŸOrdering: persistently ordered, unordered, indexed, grouped ³Containment type ŸHow the linkage between container and contained object is represented within a computer ŸReferential – a pointer to another object ŸInclusion – contained object is a sub-part of container object

7. Containment Types  Inclusion: item is physically part of container  Referential containment types: ³Describes identifier storage ŸOn container ŸOn object ŸOn container and object ŸFirst-class containment relationship A new container is introduced, and storage is delegated to it. ŸHybrid First-class container plus one other

8. Three-layer model of containers containercontained entity contains container contained entity Contains – single containment, single membership, unordered, inclusion * Example #1: Inclusion Abstract Relationship Layer Explicit Relationship Layer container contained entity * * Example #2: Referential Contains – multiple containment, single membership, ordered, containment relationship on container * = has identifier Concrete Representation Layer File with a linked list of content chunks Container data item uses linked list of identifiers of member data items data item id1 data item id2 data item id3 container id0 id1id2id3

9. Data Modeling Using Containment  Semantic data modeling (enhanced entity-relationship) is modeling method ³Focus is on static, not behavioral aspects ³Entities are system abstractions ³Relationships used in models: ŸContainment ŸInheritance ³Focus is on containment relationships ŸInheritance is secondary, used to reduce clutter

10. Dexter Multiple containment, single membership, unordered, identifier on container Single containment, single membership, unordered, inclusion Single containment, single membership, ordered, inclusion anchorcontentattribute component presentation specification link endpoint specification direction presentation specification composite 1 N2N2 1 11 1 M1 N 1 N M N 1 Inheritance M 1 1 1 1 1 N M

11. WebDAV Data Model Single containment, single membership, unordered, inclusion Single containment, single membership, ordered, inclusion Inheritance Multiple containment, single membership, unordered, identifier on container resourcecollection bodyproperty HTML link 1 M N 1 1 1 M 1 1 M N M

12. Neptune/Hypertext Abstract Machine Single containment, single membership, unordered, identifier on container, delete removes all contained items Single containment, single membership, unordered, inclusion Multiple containment, single membership, ordered, identifier on container entity link attribute graph context node Relationships that affect all entities: 1 2 N 1 1 1 1 M M M M 1 N N

13. Revision History Design Space

14. Design Space Goal  Design space goal: ³Characterize different approaches for representing the revision history of any kind of versioned entity ³Describe versioning of documents, anchors, composites, etc.

15. Approaches for Persistent Representation of a Revision History  Versioned object –A container object, the versioned object, referentially contains individual link revision objects –Used by: HyperPro, CoVer, VerSE, HyperProp, HyperForm, HyperDisco, Hypermedia Version Control Framework  Within-object versioning –A container object inclusively contains all revisions –Choices: granularity of changes & settable attributes –Used by: RCS, SCCS, Palimpsest, VTML  Predecessor/Successor relationships only –All revision objects are stored in a central object pool –Unversioned predecessor/successor relationship objects represent link revision history –Used by: Xanadu, PCTE 123 versioned object 123 123

16. Link Versioning Design Space

17.  Design space is separated into approaches for independent and dependent links  Independent: link is a separate object from linked objects  Dependent: link is contained within object ³Hence, versioning of link depends on versioning of document Versioning Links

18. Independent Link Versioning  Versioned object ³A container object, the versioned object, referentially contains individual link revision objects (+) Can create link collections to capture structure (+) Can create collections of documents and links (-) Need many system objects to represent link revision history  Within-object versioning ³A single object includes within it all link revisions ³Further choices: change granularity, per-change attributes (+) One object records all link revisions (+) Can perform fine-grain versioning of textual link metadata, such as an annotation (-) Must include entire history object in composites, instead of a single revision (-) Fine-grain versioning can be complex 123123 versioned object

19. Independent Link Versioning (2)  Predecessor and successor relationships only ³All revision objects are stored in a central object pool ³Unversioned predecessor/successor relationship objects represent link revision history (+) No container object needed to represent versioned object (+) Can represent link revision histories that span control boundaries (-) Expensive to evaluate revision selection queries 123

20. Dependent Link Versioning  Link embedded within object contents, or,  Link embedded within subsidiary object metadata (metadata that is versioned at same time as object contents) (+) Simplicity: a revision of object is a revision of link too (+) Consistency: when object is deleted, all links are deleted (-) Cannot independently version links (-) Cannot version structure separate from linked objects  Link embedded in independently versioned metadata (+) Links can be versioned separate from object contents (+) Consistency: when object is deleted, all links are deleted (-) Adds significant complexity, since each metadata item is versioned

21. Structure Versioning Design Space

22. Versioning Structure  Link structure: a set of links ³The structure is the graph created by a set of links  Essence of versioning structure: ³A collection object holds the set of links ³The collection object is versioned ³It is possible to version structure without versioned links

23. Structure Versioning Design Space  Axes of design space: ³What does container hold ŸLinks (mandatory), objects representing works, anchors ŸDepends on abstractions in system data model ³Versioning design space for container and contained items (links, objects, anchors, …) ŸUnversioned (not container), versioned object, within-object ³Containment design space for all container/contained item pairs: ŸCollection revision  contained item (revision) ŸLink (revision)  contained item (revision) (anchor or object) ŸAnchor (revision)  object (revision) ŸContainment type has most influence ³Revision selection rule ŸStored on container ŸStored on containment relationship (in relationship, in identifier)

24. Completeness Criteria  Two criteria determine if a point in the structure versioning design space is complete: ³Symbolic rendition criterion ŸFrom information in the structure container, can the contents of works, anchors, and links be retrieved? ŸMust be sufficient information to create a symbolic rendition (a view) of each work ŸIncludes rendering anchors or link endpoints ³Link traversal criterion ŸFrom information in the structure container, can a link traversal be performed? ŸMust be sufficient information to perform a link traversal from an anchor ŸIf no anchors are present in data model, must be sufficient information to traverse a link from depiction of link endpoint

25. Example 1: Versioned Structure with Unversioned Links

26. Versioned Structure with Unversioned Links (1)  Abstractions present: collection, object, link (no anchors)  Collection holds: links, versioned object  Versioning choices: ³Collection is versioned, using versioned object approach ³Link is unversioned ³Works are versioned, using versioned object approach  Containment design choices: ³Collection  link, versioned object ŸReferential: multiple containment, single membership, unordered, identifier on container (collection) ³Link  versioned object ŸReferential: multiple containment, single membership, ordered, identifier on container (link)  Revision selection rule: ³Stored on collection, selects object revision from versioned object

27. Versioned Structure with Unversioned Links (2) versioned collection Link (unversioned) versioned object object revision collection revision (RSR) Referential, Multiple containment, single membership, unordered, identifier on container Referential, Multiple containment, single membership, ordered, identifier on container

28. Versioned Structure with Unversioned Links (3)  Revision selection rule on collection selects, for links, a revision within a versioned object  Revision chosen by link can change without changing link object  Reverting to previous container version reverts link endpoints  Approach used by HyperPro [Østerbye 92] & HyperProp [Soares et al. 99] 1 A 23 1 B 2 L C,1 1 A 2 3 1 B 2 L C,2 4 3 Revision selection: latest revision, time  t 1 Revision selection: latest revision, time  t 2 t1t1 t2t2

29. Example 2: Versioned Structure with Versioned Links

30. Versioned Structure with Versioned Links (1)  Abstractions present: collection, object, link (no anchors)  Collection holds: link revision, object revision  Versioning choices: ³Collection, link, works are versioned, using versioned object approach  Containment design choices: ³Collection  link revision, object revision ŸReferential: multiple containment, single membership, unordered, identifier on container (collection) ³Link  object revision ŸReferential: multiple containment, single membership, ordered, identifier on container (link)  Revision selection rule: ³Stored on collection, affects collection  link, object revisions

31. Versioned Structure with Versioned Links (2) versioned collection link revision versioned link object revision collection revision (RSR) Multiple containment, single membership, ordered, identifier on container, dynamic via RSR Multiple containment, single membership, ordered, identifier on container versioned object 1 A 231 B 2 L,2 C,1 Revision Selection Rules RSR1, RSR2: latest, time  t 0 RSR3, RSR6: latest, time  t 1 RSR4, RSR5, RSR 7: latest, time  t 2 t2t2 A,2 B,2 L 12 (RSR1) (RSR3) (RSR6) (RSR5) (RSR2)(RSR4) (RSR7) (RSR)

32. Contributions

33.  Parameterization of possible choices involved in design spaces for: ³Containment ³Persistent storage of revision histories ³Versioning links ³Versioning structure  Containment model ³Recognition that containment is foundational for hypertext versioning ŸOpens the door to view configuration management and hypertext versioning systems as systems of containment relationships  Structure versioning design space ³Builds upon design spaces for containment, persistent storage of revision histories, and link versioning ³Allows “apples-to-apples” comparison of structure versioning approaches  Characterization of where existing hypertext versioning systems fit in the design space

34. Further Reading  “An Analysis of the Hypertext Versioning Domain”, E. James Whitehead, Jr., Ph.D. Dissertation, U.C. Irvine, 2000. ³http://www.ics.uci.edu/~ejw/papers/whitehead_diss.pdf  Come see my poster this afternoon: ³“A Common Hypertext Versioning Scenario” ³Goodies that didn’t fit in the conference paper…