Design Spaces for Link and Structure Versioning

Jim WhiteheadU.C. Santa Cruzejw@soe.ucsc.edu

www.soe.ucsc.edu/~ejw/

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.

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

Containment Design Space

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.

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

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

Three-layer model of containers

container

contained 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 LayerFile 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

id0id1 id2 id3

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

Dexter

Multiple containment, single membership, unordered, identifier on container

Single containment, single membership, unordered, inclusion

Single containment, single membership, ordered, inclusion

anchor content

attribute

component

presentation specification

link

endpoint specification

direction

presentation specification

composite

1

N2

1

1 1

1

M 1

N

1

N

M

N

1

Inheritance

M

1

1

1

1

1

N

M

WebDAV Data Model

Single containment, single membership, unordered, inclusion

Single containment, single membership, ordered, inclusion

Inheritance

Multiple containment, single membership, unordered, identifier on container

resource

collection

body

property

HTML link

1

M

N1

1

1

M

1

1

M

N

M

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

MM

1

N N

Revision History Design Space

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.

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

1 2 3

versioned object

1 2 3

versioned object

1 2 3

Link Versioning

Design Space

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

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

1 2 3

1 2 3

versioned object

versioned object

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

1 2 3

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

Structure Versioning Design

Space

Versioning Structure

Link structure: a set of linksThe structure is the graph created by a set of

links

Essence of versioning structure:A collection object holds the set of linksThe collection object is versionedIt is possible to version structure without

versioned links

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)

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

Example 1:Versioned Structure

with Unversioned Links

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

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

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]

1A

2 3

1B

2

L

C,1 1

A2 3

1B

2

L

C,24

3

Revision selection: latest revision, time t1

Revision selection: latest revision, time t2t

1

t2

Example 2: Versioned Structure with Versioned Links

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

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 RSRMultiple containment, single membership, ordered, identifier on container

versioned object

1A

2 3

1B

2

L,2

C,1

Revision Selection RulesRSR1, RSR2: latest, time t0

RSR3, RSR6: latest, time t1

RSR4, RSR5, RSR 7: latest, time t2

t2

A,2

B,2

L1 2

(RSR1) (RSR3) (RSR6)

(RSR5)

(RSR2) (RSR4)

(RSR7)

(RSR)(RSR)

Contributions

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

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…