Design Spaces for Link and Structure Versioning

1. Design Spaces for Link and Structure Versioning Jim Whitehead U.C. Santa Cruzejw@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. data item data item data item id3 id2 id1 Three-layer model of containers Abstract Relationship Layer contains container contained entity Explicit Relationship Layer * = has identifier Example #2: Referential Example #1: Inclusion * contained entity contained entity * * container container Contains – single containment, single membership, unordered, inclusion Contains – multiple containment, single membership, ordered, containment relationship on container Concrete Representation Layer Container data item uses linked list of identifiers of member data items File with a linked list of content chunks container id0 id1 id2 id3

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 N composite M M N link component 1 1 1 1 1 1 N 1 M 1 N2 N endpoint specification anchor content attribute presentation specification M 1 1 1 1 1 presentation specification direction Single containment, single membership, unordered, inclusion Inheritance Multiple containment, single membership, unordered, identifier on container Single containment, single membership, ordered, inclusion

11. WebDAV Data Model N resource collection M M N 1 1 1 1 M property body 1 M 1 HTML link Single containment, single membership, unordered, inclusion Inheritance Multiple containment, single membership, unordered, identifier on container Single containment, single membership, ordered, inclusion

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

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. 1 2 3 1 2 3 1 2 3 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 versioned object versioned object

16. Link Versioning Design Space

17. Versioning Links • 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

18. 1 2 3 1 2 3 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 versioned object versioned object

19. 1 2 3 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

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 collection revision (RSR) versioned object Link (unversioned) object revision 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] C,1 A C,2 A 1 2 3 3 4 1 2 L L Revision selection: latest revision, time  t2 Revision selection: latest revision, time  t1 B B 1 2 1 2 3 t1 t2

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. 1 1 1 2 2 2 3 Versioned Structure with Versioned Links (2) versioned collection A collection revision (RSR1) (RSR6) (RSR3) C,1 L (RSR) A,2 (RSR) (RSR) versioned object versioned link (RSR5) L,2 (RSR2) (RSR4) object revision link revision B,2 t2 (RSR7) B Multiple containment, single membership, ordered, identifier on container, dynamic via RSR Revision Selection RulesRSR1, RSR2: latest, time  t0RSR3, RSR6: latest, time  t1RSR4, RSR5, RSR 7: latest, time  t2 Multiple containment, single membership, ordered, identifier on container

32. Contributions

33. Contributions • 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…