A GENERAL PURPOSE FiYl=ERTEXT A6STRACT MACHINE

Transcription

1 A GENERAL PURPOSE FiY=ERTEXT A6STRACT MACHNE BRAD CAMPBELL and JOSEPH M. GOODMAN The HAM is a transaction-based server for a hypertext storage system. The seruer is designed to hande mutipe uses in a networked environment. The storage system consists of a coection of contexts, nodes, inks, and attributes that make up a hypertext graph. The versatiity of the HAh4 can be iustrated by showing how Guide buttons, ntermedia webs, and NoteCard FieBoxes can be impemented using its storage mode. The Hypertext Abstract Machine [HAM) is a generapurpose, transaction-based, muti-user server for a hypertext storage system. The HAM is based on the abstract machine Norm Deise and Mayer Schwartz used in their Neptune system deveoped at Tektronix Computer Research Laboratory []. Because the HAM is a ow-eve storage engine, it provides a genera and fexibe mode that can be used in severa different hypertext iappications. For exampe, the HAM, combined with the Neptune user interface, provides a prototype system for a software engineering environment. The HAM stores a of the information it manages in graphs, or databases, on a host machine s fie systems. Graphs are stored in a centraized area and can be accessed in a distributed environment. The HAM typicay communicates with an appication through a byte stream protoco [athough it may aternatey be staticay inked with an appication). The appication may or may not run on the same machine as the HAM. Appications normay communicate with the outside wor d through a common user interface. The interface shoud be window-based and highy interactive to provide a suitabe environment for a hypertext system. Figure shows the typica organization of a system using the HAM. 0198e ACM OOO-0782/88/0700-OS56 $1.50 HAM FEATURES The HAM storage mode is based on five objects: graphs, contexts, nodes, inks, and attributes. The HAM maintains history for these objects, aows seective access through a fitering mechanism, and can aow for access restrictions through a data security mechanism. HAM Objects A graph contains contexts, nodes, inks, and attributes. These objects are organized hierarchicay and carry the foowing descriptions: A graph is the highest eve HAM object. t normay contains a of the information regarding a genera topic, such as the information for a software project. A graph contains one or more contexts. Contexts partition the data within a graph. Contexts can be used to support configurations, private workspaces, and version history trees [6]. Each context has one parent context and zero or more chid contexts. When a graph is created, a root context begins the tree. A context which contains zero or more nodes and inks does not depend on information contained in its parent context. A node contains arbitrary data that can be stored as text or as fixed-ength binary bocks. A node can be cassified as archived, nonarchived, or append-ony. When an archived node is updated, a new version of 556 Comnzunications of the ACM Juy 1988 Voume 31 Number 7

2 the node is created using the new contents. Previous versions of an archived node can be retrieved. When a nonarchived node is updated, the previous contents are repaced by the new contents. When an append-ony node is updated, the new contents are appended to the previous contents. Append-ony nodes are usefu for ogging the actions performed by an appication. A node s contents can be searched for the occurrence of user-specified reguar expressions. The search mechanism aows a versions of a node to be searched. Nodes are reated by inks. A ink defines a reationship between a source node and a destination node and can be foowed in either direction. A cross-context ink reates two nodes in different contexts and is usefu for sharing data between two contexts. The generaity provided by ink attributes aows appication writers to define their own notions of ink types or ink end-point attachment schemes. Attributes can be attached to contexts, nodes, or inks. Attribute vaues can be strings, integers, foating-point numbers, or user-defined types. Attribute/vaue pairs give semantics to HAM objects. They can represent appication-specific properties of objects or contain information that further describes an object. Attributes are aso used in the predicates that are part of the HAM fiters. USER NTERFACE APPLCATON TOOLS FLE HOST SYSTEMS FGURE 1. Generic Hypertext System Architecture Version History The HAM provides an automatic version history mechanism. The version history for a HAM object is updated each time that object is modified. Because each access to an object contains a version time, previous versions of objects can be viewed. The HAM aso provides operations to destroy undesired versions. Fiters The HAM provides a fitering mechanism that aows subsets of HAM objects to be extracted from arge graphs. Fiters aow the user to specify visibiity predicates, which are expressions reating attributes and their vaues. HAM fiters ony return objects that satisfy the predicates. Fiters aso aow the user to specify a version time so that earier versions of a graph can be examined. The HAM fiters the foowing items: Contexts in a graph Nodes in a context Links in a context nstances of a node in specified contexts nstances of a ink in specified contexts A set of nodes and inks in specified contexts based on a specific ink ordering Data Security The HAM provides security for the data contained in a graph through its access contro ist (ACL) mechanism. Attaching an ACL to an object is optiona. An ACL entry consists of a user or group name and a set of permissions. A user is anyone who has access to the graph. A group is a ist of users. The avaiabe permissions are access, annotate, update, and destroy. The permissions associated with an ACL entry are additive. Access permission aows the user or group to view the data associated with the object. Annotate permission aows inks to be attached to a node. Update permission aows the user or group to perform nondestructive updates on an object. Destroy permission aows the destruction of an object. HAM OPERATONS To provide a consistent, simpe interface, HAM operations are grouped into seven categories. Operations within a category behave simiary, regardess of the object on which they operate. Create operations create new HAM objects. A create operation takes object-dependent data and returns an object index and a version time. The object index represents a unique identifier for the newy created object, and the version time denotes the time at which the object was created. Deete operations mark objects as deeted but retain historica information. A deete operation takes an object index and a version time, and returns a new version time. The object index specifies the unique identifier for the object being deeted. The returned version time represents the time the object was deeted. Destroy operations free a space required for an object. The object does not have to be deeted to be destroyed. A destroy operation takes an object index and a version time, and returns a new version time. The object index specifies the unique identifier for the object being destroyed. The returned version time represents the time the object was destroyed. Change operations modify data associated with an existing object. A change operation takes an object index, a version time, and object-dependent data and returns a version time. The object index specifies the unique identifier for the object being modified. The returned version time represents the time the object was modified. ;.- E SPE 1.N SSUE ]uy 1988 Voume 31 Number 7 Communications of the ACM 057

3 i SPECAL SSUE 0 1 a- Get operations retrieve data from existing objects. A get operation takes an object index and a version time, and returns the data that existed at the specified time. The object index specifies a unique identifier for the object from which data is being retrieved. The version time is a time range for the data retrieva. Fiter (and inearize) operations seectivey retrieve information from a graph. A fiter operation takes a predicate, a version time, and a ist of attributes. These operations return a ist of objects that satisfy the predicate and a ist of requested attributes attached to each object. The version time specifies the time at which the fiter is to search for the information. Each fiter operation aso has unique parameters in addition to those aready specified. Specia operations are those that do not fit into any of these categories. They incude functions such as searching for strings in node contents, merging contexts, and managing transactions. EXAMPLE HAM APPLCATONS Because the HAM is a genera-purpose hypertext engine, it can serve many types of hypertext systems. To iustrate this point we wi mode three hypertext structures using the HAM s storage mode: Guide buttons, ntermedia webs, and NoteCards FieBoxes. Guide Buttons Guide is a hypertext product deveoped for the Macintosh by OWL nternationa, nc. of Beevue, Washington [3]. t is a too for writing and reading eectronic documents. Guide uses buttons-specia areas on a screen-to represent inks in a document between the information on the screen and reated information. When a button is seected, by cicking the mouse, Guide foows the ink to dispay the reate d information. Repacement buttons repace the button icon dispayed on the screen with the information associated with that button. nquiries are sets of two or more mutuay excusive repacement buttons. Reference buttons dispay the information associated with the button in a new window. This window remains visibe unti the user returns to the document window. Note buttons dispay information associated with the button in a new window that disappears when the user reeases the mouse button. To mode Guide, the HAM equates a document with a node. The various button reationships are modeed as inks. Link attributes determine which type of button the ink represents. The appication uses these ink attributes to determine which type of window to open when a button is seected. Figure 2 shows an exampe of a note button. The Document Browser contains the text being examined; the icon within the browser represents the note button. The Note Browser contains the note associated with the note button. The Button Attribute Browser s:hows the attributes associated with the ink representing the note button, as we as the vaue of the LinkType attribute. The button type is stored in the ink attribute Link- Type; its vaue is Repacement, nquiry, Reference, or Note. A buttons aso maintain the ink attributes Name and DocumentLocation. Name represents the name associated with the button, and DocumentLocation defines the ocation reative to the beginning of the document where the button was created. The vaue of DocumentLocation corresponds to Guide s ocation of its button icon. Guide considers the information associated with a button to be an atomic entity. Therefore, the other end of the ink representing the button can point to the entire node that contains the button s information. A buttons aso maintain the ink attributes Name and Document- DocumeniLocation FGURE 2. Possibe Representation for a Guide Note Button f a repacement button is part of an inquiry, the vaue of LinkType is set to nquiry. A ink that represents part of an inquiry aso has an attribute named Grouping, which contains the identification of a specia node. This node contains the identification of a inks (repacement buttons) that make up the inquiry. Figure 3 shows the HAM storage mode for an inquiry named Exampe nquiry. The Storage Representation window shows the nodes and inks. invoved in the inquiry. n this exampe, the inks have the same name as their destination nodes. The node Exampe 35.--A Guide is a trademark of OWL nternationa. nc. Macintosh is a trademark of Appe Computer. nc. FGURE 3. nquiry Storage Representation 858 Communications of the ACM ]uy 1988 Voume C Number 7

4 L Th. fhtt Rsfsrenc. MPnua, FGURE 4. Mai Web HAM Appications is the document node. The nodes Guide Buttons, ntermedia Webs, and NoteCards FieBoxes contain the information associated with the repacement buttons that make up the inquiry. The node Exampe nquiry contains the names of the repacement buttons in the inquiry; its contents are shown in the Exampe nquiry browser. The Button Attribute Browser dispays the attributes attached to one of the inks invoved in the inquiry and shows that the vaue of the Grouping attribute is Exampe nquiry. [] ntermedia Webs ntermedia, the system deveoped at the nstitute for Research in nformation and Schoarship at Brown University [2], [7], is one of the newer and more innovative hypertext systems. The basic hypertext concepts in ntermedia are very simiar to those found in the HAM. ntermedia uses the term web to refer to a database that contains both references to a set of documents and the inks associated with those documents [5]. A bock is the piece of a document to which a ink is anchored and can be any egitimate seection in the appication. The attributes provided by the HAM aow the fexibiity to efficienty mode these reationships. To mode an ntermedia web, the HAM represents a web as a coection of nodes and inks. A document is represented as a node. An ntermedia ink is equivaent to a HAM ink. Bocks are determined by using ink attributes to define the anchor seections for both the source and destination ends of each ink. UNX manua pages provide a convenient exampe of how the HAM can mode ntermedia webs. The manua page for the mai command is used to create a sma web of information. UNX is a registered trademark of AT&T Be Laboratories. Excerpts from the UNX Programmer s Manua, Berkeey Distribution. are used for purposes of iustration. ; SPECA D a* SSUE FLES: usrepoomai* -mbox -/.mairc tmprw /usr/ib/ma.hep /usr/ibmai.rc Message post office your od ma fie giving nta ma commands temporary for edtor escape hep fies aystem intazation fie temporary for editing messages SEE ALSO Source Extent Source Offset fmt(), newaases(), aiases(s), maaddr(7), sendma(8) The Ma Reference Manua NAME binmai - send or receive ma among users SYNOPSS /bnma [ + ] [ - ] [ person ]... /bin/mai [ + ] [ 4 ] -f fife Owner Baxnga Updated Juy 20, Q87 Created June 8, 1987 DESCRPTON Note: This is the od version 7 UNX system ma program. The defauft ma command s described n mai(), and ts binary s n the directory usrucb. L Destnaton Offset 122 Destinaton Extent 7 FGURE 5. Defining a Bock ]uy 1988 Voume 31 Number 7 Communications of the ACM 859

5 1 i spzcw 1.w SSUE Each document (manua page) is represented as a HAM node. The web is defined by attaching an attribute named Web to each ink. The vaue of this attribute contains the name of the web to which the ink beon,gs. A ink fiter is appied using the predicate Web = ma to et users view a map of the web. This fiter returns ony those nodes that are part of mai. Figure 4 shows the mai web defined by creating inks :from the mai command to commands in the manua page s SEE ALSO section. To define a bock, the HAM uses the attribute pairs!5ourceoffset/sourceextent and DestinationOffset/ DestinationExtent. A bock is determined by the vaue of the attribute pair attached to the ink. For exampe, the source bock of a ink is represented by the attributes SourceOffset and SourceExtent. The vaues of these attributes are integers that contain the byte offset from the beginning of the node and the ength of the bock. NoteCards FieBoxes NoteCards is a genera-purpose idea-processing hypertext system deveoped at Xerox PARC [4]. NoteCards supports the concept of FieBoxes. Every notecard must be stored in one or more FieBoxes. A FieBc x which is arranged as a directed acycic graph, can contain notecards and other FieBoxes. FieBoxes can be represented in the HAM using nodes, inks, and attributes. Both FieBoxes and notecards are equivaent to nodes. The mode uses a node attribute to determine whether a node is a FieBox or a notecard. Links show which notecards (or FieBoxes) are in a particuar FieBox. Link attributes determine which inks refer to other FieBoxes and notecards. This mode aows nodes to reside in more than one FieBox. The exampe shown in Figure 6 heps to carify the NoteCards FieBox mode. The FieBox named Hypertext 87 contains a of,r:r;r;;jes~~~~~~~~~~~~,~~~~~~~~~~~~~~ ;..;;...:,:;..:.:,.:....: ;.:.....:.:,..>.: :..,:.: :.: >.7...,..,...,.:.::,,:;., 1.. y.: y>y.::.::.::.:..: 1.: Because the Hypertext Abstract Machine is designed as a genera-purpose engine, it can be used as a base engine for other hypertext systems. Exampe HAM Appications 1 :, :;:;.A N#f$cjjfa&.;,.,.,.,. >,.;,.,..,..,.,.;,.,.,. Narne Owner Updated Created NodeType Name Owner Updated Created NodeType ( FieBox 1 FGURE 6. NoteCards Representation Each bock is defined by the offset and extent attri- the FieBoxes and notecards that make up this artice. butes. The offset provides an insertion point for the As shown in the Features NoteCard Attribute bock, and the extent determines the end point of the Browser, the Features node is a FieBox. \Yhen a user bock. browses this node, the NoteCards-ike appication ex- Figure 6 shows the vaue of the SourceOffset and amines the nodetype attribute, determines that the SourceExtent attributes attached to ink BinMai. The node is a FieBox, and opens a new FieBox browser. highighted area shows the bock these attributes The contents of the Features node are inks to a of defin e. the FieBoxes and notecards that it contains. t shoud 660 Communications of the ACM ]uy 1988 Voume 31 Number 7

6 be noted that References is contained in both Fie- Boxes. The Concusion NoteCard Attribute Browser shows that the Concusion node is a NoteCard. When a user browses this node, the appication examines the nodetype attribute, determines that the node is a NoteCard, and opens a NoteCard browser. CONCLUSON Because the Hypertext Abstract Machine is designed as a genera-purpose hypertext engine, it can be used as a base engine for other hypertext systems. Most current hypertext systems emphasize the appication and user interface ayers. Whie these ayers are very important an appropriate storage mode is essentia. We beieve the HAM provides such a mode. Athough the HAM is not a panacea for hypertext data storage probems, it is an important first step. As new hypertext appications are deveoped, we wi earn more about the data representation probems hypertext presents. f a storage mode standard deveops from this work, it may ead to the deveopment of a standard terminoogy and base engine that coud improve immeasuraby the progress of hypertext technoogy. Acknowedgments. We wish to thank Norm Deise and Mayer Schwartz of the Tektronix Computer Research Laboratory for their hepfu comments. We woud aso ike to thank Victor Riey and Lee Thomas for their contributions to the HAM project. Lasty, we woud ike to thank Amy River0 and Rich Davenport for their editing and iustration assistance. ati REFERENCES 1. Dei&, N. and Schwartz. M. Neptune: A hypertext system for CAD appications. n Proceedings ACM SGMCJD 86 (Washington. D.C.. May X-30,1966) Garrett. N., Smith, K., and Meyrowitz. N. ntermedia: ssues, strategies, and tactics in the design of a hypermedia document system. n Proceedings of the Conference on Computer Supported Cooperative Work (Austin. Tex., December ) Guide: Hypertext for the Macintosh Manua. OWL nternationa. nc., Beevue, Wash., Haasz. F.. Moran, T., and Trigg. R. N&Cards in a nutshe. n CH + C Conference Proceedings (Toronto, Ontario. Canada. Apri 5-9, 1967) Meyrowitz, N. ntermedia: The architecture and construction of an object-oriented hypermedia system and appications framework. n OOPSLA 86 Proceedings (Portand. Or.. Sept. 29-Oct , Schwartz. M. and Dei&. N. Contexts-A partitioning concept for hypertext. ACM Trans. on Office nformation Systems 5. 2 (Apri 19871, Yankeovich. N.. Meyrowitz. N.. and van Dam, A. Reading and writing the eectronic book. Computer [Oct. 1965) CR Categories and Subject Descriptors: H.2.6 [Database Management]: Database Machines; H.3.4 [nformation Storage and Retrieva]: Systems and Software; K.6.3 [Management of Computing and nformation Systems]: Software Management Genera Terms: Design, Management Additiona Key Words and Phrases: Abstract machines, hypertext systems Authors Present Addresses: Brad Campbe, CASE Division, Mentor Graphics Corp SW. Creekside Pace, Beaverton, OR 97005; Joseph M. Goodman, Quantitative Technoogy Corp., 6700 S.W. Creekside Pace, Suite D. Beaverton, OR Permission to copy without fee a or part of this materia is granted provided that the copies are not made or distributed for direct commercia advantage, the ACM copyright notice and the tite of the pubication and its date appear. and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise. or to repubish, requires a fee and/or specific permission. D ; SPE 1 SSUE JOURNAL OF THE ASSOCATON FOR COMPUTNG MACHNERY Subscriptions $15,00/year for ACM members; $fs.oo/year for nonmembers. (Members pease incude member #) An exceent source to information on computer theory and research in.. Agorithm & compexity theory Artificia inteigence Combinatorics & graph theory Computer organization & design Systems modeing & anaysis Database theory & structures Distributed computing Forma anguages Computationa modes Numerica anaysis Operating systems and research Programming anguages & reated methodoogy Computationa theory Pubished four times a year (SSN ) Write for an order form and your ACM Pubications Cataog to: Catherine YUnqUe, ACM, 11 West 42nd Street, New York, NY Juy 1988 Voume 31 Number 7 Communications of the ACM 661