CSA3080: Adaptive Hypertext Systems I

1. CSA3080:Adaptive Hypertext Systems I Lecture 7:Formal Models of HypertextDexter Hypertext Reference Model Dr. Christopher Staff Department of Computer Science & AI University of Malta 1 of 18 cstaff@cs.um.edu.mt

2. Aims and Objectives • Adaptive Hypertext Systems are built using hypertext navigation support and information is inter-linked, hypertext style • Most AHSs are deployed over the Web, but the Web isn’t a particularly good example of a hypertext… • So what are the properties and characteristics of “good” hypertexts? 2 of 18 cstaff@cs.um.edu.mt

3. Aims and Objectives of Hypertext • ‘Well, by “hypertext” I mean non-sequential writing--text that branches and allows choices to the reader, best read on an interactive screen’ Ted Nelson, 1987. Literary Machines, Edition 87.1. • “Hypertext is text which is not constrained to be linear. Hypertext is text which contains links to other texts.” http://www.w3.org/WhatIs.html • References: • http://www.google.com/search?q=define:Hypertext 3 of 18 cstaff@cs.um.edu.mt

4. Hypertext 1988 and beyond • The WWW was first launched in 1991, but only gained popularity in 1993 • The Hypertext community came to a head in 1990 to iron out many inconsistencies and incompatibilities in terminology • Many models of hypertext were also proposed, based on petri-nets, sets, etc. • The most popular model is based on graph theory 4 of 18 cstaff@cs.um.edu.mt

5. Dexter Hypertext Reference Model • Why a formal model? • “The goal of the model is to provide a principled basis for comparing systems as well as for developing interchange and interoperability standards” [Halasz94] • DHRM has been implemented as Amsterdam, CMIFed, AHAM, DeVise/WebVise, RHYTHM (Bologna)… • References: • Halasz, F. and Schwartz, M. 1994. The Dexter Hypertext Reference Model, in Communications of the ACM, 37(2), February, 1994, 30-39. 5 of 18 cstaff@cs.um.edu.mt

6. DHRM Fundamentals • DHRM separates the representation of documents (nodes) from the linking of nodes and the navigation through hyperspace [Halasz94] 6 of 18 cstaff@cs.um.edu.mt

7. DHRM Fundamentals 7 of 18 cstaff@cs.um.edu.mt

8. DHRM Fundamentals • Components • DHRM components are the equivalent of nodes, andare represented in the Storage Layer • Nodes were called frames, cards, documents, and articles • Even today, on the Web a node is referred to as a document or more commonly, a page • DHRM doesn’t really care about what happens within a component, only how the hypertext network interfaces with the component 8 of 18 cstaff@cs.um.edu.mt

9. DHRM Fundamentals • Anchors • References to locations or items within documents • Components can be composites, hierarchical combinations of atomic components (DAG) • Anchors can be the source or destination of links • Anchors can be entire components, or spans (segments of a component) 9 of 18 cstaff@cs.um.edu.mt

10. DHRM Fundamentals • More about anchors… • Anchors have two parts • Anchor ID (used by Storage Layer) • Anchor Value (used by Within-Component Layer) • The anchor value can be a region within a component, and the value is sensible only to the application responsible for editing/accessing the component • Anchors are unique: <componentID, anchorID> 10 of 18 cstaff@cs.um.edu.mt

11. DHRM Fundamentals • Links • Links are represented in the Storage Layer • Specify a source anchor, a destination anchor, and a direction that specifies how the link can be traversed • Links can also be the destinations for other links • Links, therefore, are totally separate from the components that contain them 11 of 18 cstaff@cs.um.edu.mt

12. DHRM Fundamentals • Presentation Layer • A hypertext isn’t much good if you cannot manipulate it and navigate through it • From the Presentation Layer users can access, view, and manipulate the hypertext 12 of 18 cstaff@cs.um.edu.mt

13. DHRM Fundamentals • All components (including links) have presentationspecifications • The Presentation Layer can also impose presentation specifications on the accessed links and components to capture user preferences, for instance 13 of 18 cstaff@cs.um.edu.mt

14. Referring to components • Components have unique identifiers (UIDs) and component specifications • Component specifications are essential, because a user may be able to describe a component without knowing its UID • Components may be identified from their description using a resolver function, and then retrieved using an accessor function 14 of 18 cstaff@cs.um.edu.mt

15. DHRM Fundamentals [Halasz94] 15 of 18 cstaff@cs.um.edu.mt

16. DHRM Fundamentals • More about links • Links are first class objects • Links are created by combining a component specification, anchor ID, direction, and presentation information into a specifier • Direction can be FROM, TO, BIDIRECT, NONE • A link is a sequence of two or more specifiers, at least one of which must be TO or BIDIRECT 16 of 18 cstaff@cs.um.edu.mt

17. Conclusion • Interesting features of DHRM • Links are separate from documents containing them • Anybody can be an author (link creator) • Search capability is built into hypertext model (resolver function) • Presentation specifications can change behaviour of component when displayed • Links “know” their origin and destination • Components can be composite • Dangling links are not allowed (supposedly!) 17 of 18 cstaff@cs.um.edu.mt

18. Conclusion • DHRM was defined in 1990 • Most existing hypertext systems were small scale, catering for individuals and small workgroups • The Internet (using TCP/IP) had existed for 7 years • The WWW did not yet exist… 18 of 18 cstaff@cs.um.edu.mt