1 / 38

Dexter Model and Devise Hypermedia

Dexter Model and Devise Hypermedia. Hypermedia system design applying the Dexter Model Special Issue introduction by Kaj Grønbæk & Randy Trigg The Dexter Hypertext Reference Model Fransk Halasz & Mayer Schwartz (Edited by Kaj Grønbæk & Randy Trigg)

dunaway
Download Presentation

Dexter Model and Devise Hypermedia

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Dexter Model and Devise Hypermedia • Hypermedia system design applying the Dexter Model • Special Issue introduction by Kaj Grønbæk & Randy Trigg • The Dexter Hypertext Reference Model • Fransk Halasz & Mayer Schwartz (Edited by Kaj Grønbæk & Randy Trigg) • Design Issues for a Dexter-Based Hypermedia System • Kaj Grønbæk & Randy Trigg From Communications of the ACM. Special issue on Dexter based hypermedia, February 1994.

  2. The Dexter meetings Organizers: John Leggett and Jan Walker Participants included: Rob Akscyn, Doug Engelbart, Steve Feiner, Mark Frisse, Frank Halasz, Don McCracken, Norm Meyrowitz, Tim Oren, Amy Pearl, Catherine Plaisant, Mayer Schwartz, Karen Smith, Randall Trigg, Bill Weiland. Systems represented included: Augment, Concordia/Document Examiner, IGD, FRESS, Intermedia, HyperCard, Hyperties, KMS/ZOG, Neptune/HAM, NoteCards, the Sun Link Service, Textnet. The meetings included: • October 1988, Dexter Inn, Sunapee, New Hampshire • March 1989, “Chain-o-lakes,” southeastern Texas • April 1990, Cannon Beach, Oregon • July 1990, Zen Retreat Center, Green Gulch, California

  3. Dexter issues Longstanding hypermedia issues taken up by Dexter: • unifying the notions of node and link • augmenting link-based networks with other structures • integrating hypermedia with existing environments and content editors • representing and enforcing different data models and run-time behavior • storing properties of node presentations • interchanging hypertexts across systems And even defining what counts as hypertext / hypermedia.

  4. Dexter Layers - conceptual (Halasz, 1990)

  5. Dexter Layers - pictorial (Halasz, 1990)

  6. Overview of Dexter terminology Storage Layer Runtime Layer Within-Component Layer Hypertext Component Base Component Atomic Component Link Component Specifier Composite Component Anchor Presentation Specification Session ? Instantiation LinkMarker

  7. Component Link Atom Composite Dexter Components (1)

  8. AtomComponent Attributes PSpec Id, Value Anchors Id, Value LinkComponent Attributes PSpec Anchors Id, Value Content (BaseComp) Content Data or Content (BaseComp) ContentsDescr Specifier Comp. Spec. Anchor: Dir: PSpec CompositeComponent Specifier Attributes Comp. Spec. PSpec Anchor: Id, Value Anchors Dir: Id, Value PSpec Id, Value Specifier Comp. Spec. Anchor: Dir: Content (BaseComp) PSpec Data or ContentsDescr Dexter Components (2) Resolves to Resolves to Resolves to .....

  9. <H2>Conference pointers </H2> <UL> <LI>Info about <A HREF = "http://cpsr.org/cpsr/conferences/pdc94">PDC '94.</A> .... </UL> WWW/HTML: id val id val Anchors: Dexters approach to linking inside document contents • Many hypermedia systems use embedded addresses and go-to. NLS/Augment, KMS, HyperCard, World Wide Web, ... • Some hypermedia systems use ‘anchors’ stored apart from the content. • Intermedia, DHM, Microcosm, Multicard, PROXHY, MacWeb, ABC, WEBSs, ... Advance Program: Participatory Design Conference (PDC'94) October 27-28, Chapel Hill, NC, USA PDC'94 is sponsored by Computer Professionals for Social Responsibility (CPSR) and in cooperation with ACM SIGCHI. Anchor objects:

  10. Use of Presentation Specifications

  11. At least two specifiers per link(Halasz & Schwartz, 1990, p. 106-107)

  12. Behavior of DeleteComponent(Halasz & Schwartz, 1990, p. 115)

  13. Dexter composites

  14. STORAGE layer functions

  15. RUNTIME layer operations

  16. A simple Dexter Interchange Format

  17. Dexter - needs for clarifications and extensions • Dangling links: We believe not only in allowing dangling links, but in actively supporting them in a variety of situations. • Link directionality: Are the direction attributes TO, FROM, BIDIRECT, NONE adequate? Which senses of link directionality are they meant to cover? • Anchors. Is one anchor type sufficient? What do specifiers point at for "whole-component-links"? Are anchors shared between links? • Components: How do we connect components to their contents in an integrated hypermedia system that doesn't "own" all material? • Composites: Dexter composites only model the internal structure of data objects. But composites should also be used to model structures built from components (e.g. tabletops, browsers, query results)! • CSCW: Dexter is silent regarding multiuser aspects and distribution. • Multimedia and time: Nor does Dexter handle temporal issues.

  18. DEVISE Hypermedia (DHM): Open hypermedia based on Dexter Implements an object oriented design with: • generic classes for all the Dexter concepts • classes organized in an extensible and tailorable framework for hypermedia development Immediate benefits from the Dexter model: • Separation between Storage (persistent) and Runtime (transient) • Bi-directional links • Multi-headed (n-ary) links • A basic notion of Composites • An interchange format

  19. Open Hypermedia Protocol implemented on top of platform dependent communication facilities • DDE/OLE2 • AppleEvent • Sockets • Object distribution Communication with hypermedia database using object distribution mechanisms DEVISE Hypermedia architecture User's desktop Application Layer ApplicationB Application A (Within Component Layer) Browser CommunicationProtocol Communication Layer Application Interfaces Hypermedia Service Runtime Layer Runtime Classes Storage Layer Storage Classes (Conceptual) (Physical) Hypermedia database (server)

  20. The object oriented DHM Framework STOR RUN COMM APPL Arbitrary (closed, semi-open, or fully open) editors for data objects Comm SessionComm InstComm LinkMarkerComm ... Hypertext Component Anchor Specifier Session Instantiation LinkMarker

  21. Storage Layer example (Components)

  22. Dangling links Four reasonable and foreseeable dangling situations: 1. deleted endpoint component, 2. deleted endpoint anchor, 3. unavailable data objects in endpoint component, 4. invalid anchor value due to editing outside the hypermedia. Intentionally incomplete links (open for later addition of endpoints) should also be supported.

  23. Leaving dangling links when deleting components

  24. Options when following a link with a dangling endpoint

  25. Following an incomplete link

  26. Different notions of link directionality Semantic direction: Ordering implied by the semantic relationship between the connected components. Example: A “supports” link connecting two components is “read” in a certain direction: the argument in A “supports” the claim in B. Creation direction: The order in which the link endpoints were created. Usually the first endpoint created is considered the source of the link, while the last is considered the destination. Traversal direction: How the link can be traversed. Examples: WWW links can only be traversed from source to destination. NoteCards links can be traversed in both directions, although the interface style is different. DHM links can be traversed symmetrically in both directions. What about multi-headed links?

  27. Link Directionality in DHM

  28. Component Anchor WholeComponentAnchor MarkedAnchor UnmarkedAnchor TextComponent DrawComponent MovieComponent PositionAnchor KeywordAnchor IntervalAnchor IdAnchor Anchors in a Dexter-based hypermedia • Locating an unmarked anchor in the contents of a component requires computation. • Marked anchors are located by their linkMarkers. • Anchors are reused if possible, e.g. there is only one Whole-component anchor per component.

  29. Integration and component contents Example: An internal drawing editor that stores drawings as part of the component in the OODB. Component contents are either embedded or stored externally. Example: A video component whose video data object is stored in a separate file.

  30. Component Component Info Info Attributes Attributes Presentation Presentation Anchors Anchors Specification Specification Component Contents Component Contents BCCompositeComponent CompositeComponent DHM general composites

  31. Uses of Composites • Data objects with internal structure • e.g. video • Hierarchical structure • by reference • by inclusion • Browsers and Queries • virtual • computed • Paths • GuidedTour • TableTop • History • data structure: e.g. changes to components, anchors • behavior: e.g. list of recent components visited, ...

  32. Example of a virtual link composite

  33. Browser interfaces

  34. Representing paths • GuidedTours and TableTops (Trigg 1988) • descended from Bush’s notion of trails • TableTop • Captures a configuration of component presentations on the screen • Opens and closes the configuration as a unit • Can be computed or built manually • GuidedTour • A (branching) sequence of TableTops • Behavior includes, for example, the ‘Next’ operation which closes current TableTop and opens the next in the sequence • Feedback is given to show which part of the tour has been visited These concepts can be implemented by means of composites, but it raises a need for Pspecs on composite “pointers.”

  35. DHM GuidedTour and TableTop

  36. DHM for Mac/UNIX DHM for Macintosh DHM for WWW DHM for UNIX Portable Dexter based hypermedia framework Single user Persistent store Multi-user OODB Variants of DEVISE Hypermedia (DHM) Network version evaluated at GBL spring 95 Single user version used in workshops at Great Belt Link Ltd. (and Grundfos) Multi user version in use by EuroCODE partners Multi user prototype - demo at Hypertext ‘93 Paper and demo at Hypertext ‘97 DHM for Windows/NT/95 Development is based on the Scandinavian Mjølner BETA environment

  37. User's workstation User's workstation ApplicationB ApplicationB Application A Application A Browser Browser ODHP ODHP Application Interfaces Application Interfaces Hypermedia Service Process Hypermedia Service Process Runtime Classes Runtime Classes Storage Classes Storage Classes Server Host Document server (Storage Classes) Document server (Storage Classes) HypermediaDataBase server HypermediaDataBase server Application Layer Multiuser client/server architecture based on the Dexter model (Within Component Layer) Communication Layer Runtime Layer LayerStorage (Conceptual) (Physical)

  38. Procedure handbooks CAD drawings Non-conformance reports Change requests Photos Progress reports Mail/FAX Supervision Action/ Done-lister Spreadsheets Internal Notes Video ARTEMIS plans Personalnotes Quality documentation Pilot use at Great Belt Link Ltd.

More Related