Abstract: Researchers in the hypermedia field often lament that the World Wide Web does not support many of hypermedia's rich structuring, navigation and annotation features. What would it take for everyday Web applications to be fully hypermedia compliant, now that the basic hypermedia building blocks exist on the Web? The following four capabilities are the most critical for integrating hypermedia support in the Web environment: editable browsers, storing document content and link anchors separately, external linkbases, and displaying link spans, node and link attributes. Individual developers can not decide autonomously on how to resolve many of the outstanding issues. Developers need agreed-upon conventions and tools built upon today's Web standards to fully incorporate hypermedia functionality into everyday applications.Categories and Subject Descriptors: H.5.4. [Information interfaces and presentation] Hypertext/Hypermedia - Architectures
General Terms: standardization, design
Additional Key Words and Phrases: hypertext, hypermedia, World Wide Web, browsers, linkbases, link attributes, hypertext functionality
Researchers in the hypermedia field often lament that the World Wide Web does not support many of hypermedia's rich structuring, navigation and annotation features [Bieber 1997] developed over the last 40 years since Engelbart's NLS system [Engelbart 1968]. Structuring features include semantically typed anchors, links and nodes; attributes and keywords on these; links to and from content spans within any medium; bidirectional links; links recursively to links and to other hypermedia constructs; transclusionsóinclusions providing access to all uses of the same span of content; versioning of hypermedia constructs; landmarks; automatic link propogation; trails and guided tours; and local and global overviews. Navigation features include link traversal; visual feedback upon link arrival; search based on the hypermedia structure (as opposed to content); process enactment through link traversal; backtracking strategies; backjumping; and history mechanisms. Annotation features include comments, bookmarks and reader-authored links with private, workgroup and public access. People can annotate any hypermedia construct, including other annotations recursively.
In fact, standard Web data formats and protocols recently introduced can facilitate many of these. So what is really standing in the way? What would it take for everyday Web applications to be fully hypermedia compliant? Now that the basic hypermedia building blocks exist, hypermedia and WWW researchers must now figure out how to deploy them to create an infrastructure for seamlessly integrating hypermedia techniques into the Web environment and making them pervasive in everyone's daily Web activities.
We believe that the following four capabilities are the most critical for integrating hypermedia support to the Web environment:
Editable browsers is, in part, a human-computer interaction issue; people want to work collaboratively in a single, seamless environment without switching to separate authoring tools. But more fundamentally, hypermedia advocates believe strongly that readers should be able to author at will, with the ability to add links and annotations to any document, and this must take place in the browser as the user reads. (Furthermore, these browsers should support the creation of hypertext constructs such as semantic node and link types and other attributes, trails and guided tours, etc.) Also, browsers should automatically display destination link spans, and metainformation such as semantic types, keywords and other attributes as part of maintaining the user's orientation.
Hypermedia features such as bi-directional linking, personalized links and structural search rely on links as "first class objects" maintained external to documents instead of embedded inside anchors. Furthermore, ubiquitous linking from documents not belonging to the user requires links and anchors be maintained external to documents and only merged as the document is sent for display. This requires external linkbases and anchor points maintained outside documents.
Most pre-Web hypermedia systems [Conklin 1987], as well as the first WWW browser built by Tim Berners-Lee, allowed editing and link traversal. The first widely used Web browser, Mosaic, dropped authoring and established the Web as a hypermedia system viewed for publishing to large audiences. Today's editable browsers (e.g., AOLpress, FrontPage, Netscape Composer, as well as professional site builders such as Adobe GoLive and Macromedia DreamWeaver) make this task somewhat easier, but the Web still is not viewed by most as a personal workspace in the way Microsoft Office is. Furthermore, today's editable browsers do not support collaborative authoring, which few off-web environments do either. But people need this, and the Web can provide the networked infrastructure for collaborative work. Again, some pre-Web hypermedia systems did support collaborative authoring [Streitz 1992, Smith 1991, Conklin 1987].
WebDAV [WebDAV] is an IETF standard extending the HTTP protocol to allow write access to the content of a Web site. This would allow Web applications to be able to read as well as write content on a Web site, and to integrate the navigation and the authoring in the same tool.
WebDAV is strong enough to support complex, multi-authored projects including versioning, link management and referential integrity. Yet the danger is that developers will use WebDAV to build just a generic readable and writeable networked file-system for all kinds of data (including hypermedia data), but not explicitly support hypermedia constructs. This would make it harder to provide sophisticated collaborative hypermedia functionalities such as notification, fine-grained locking, lock-free collaboration, and support for hypermedia transclusions (see for instance [Nelson 1987] and [Wiil 1993]). Developers must be pushed to develop these features.
Unless an HTML document is dynamically generated, anyone without write-access can neither create anchors at a link destination within that document, nor create links leading from that document. Several interesting hypermedia features remain impossible until we can extract link anchors from document content, including bi-directional linking (links activatable at both ends, and thus not providing a preferred direction of navigation) and personalized links (visible to a group of users, rather than all readers of a document).
Two issues arise when separating content and links. The first is the problem of locators, i.e., of unequivocally identifying the exact spot in the document at which link anchors should be attached. Of course, this is extremely media type-dependent; methods to specify a location within ASCII documents, marked-up texts or, say, bitmaps will vary considerably. The second issue is keeping the locators correctly pointing to the right positions when either or both linked documents are being modified asynchronously.
XPointer [XPointer] is an ancillary standard to XML, the new markup language being proposed for the World Wide Web. An XPointer is an elaborate specification of a location within a text or XML document, by way of expressing the steps necessary to get from well-known document elements (e.g., the start, the named elements, the destination of the preceding link) to the required destination in terms of tree-traversal steps, character counting, and other methods. XPointer has yet to be widely accepted. The many reliability and stability problems necessarily not yet dealt with in its proposal, are important issues for Xpointers. Because their sophistication and precision makes them extremely fragile, any element of a possibly complex chain of specifications within an XPointer could be outdated by even the simplest change in the document it refers to.
Davis [Davis 1998] discusses four solutions to automatically resolving this referential integrity of links problem:
No solution is without drawbacks, and yet none is inherently flawed. The appropriateness of each depends on the kind of application and link type. For instance, the precision required in correctly identifying a transcluded portion of a document necessitates the reliability of a full versioning system.
No one developer can decide autonomously on such important decisions for the Web as a whole. Instead additional standards and agreements are necessary for these features to actually work and interoperate.
Once we have a reliable separate addressing mechanism for point-to-point links, how can we actually create external links? How do we express them? How can we store them? How is the browser supposed to know about their existence, so that it can merge and display them with the documents they connect?
In the hypermedia literature, the notion of a linkbase has often appeared (e.g., [Pearl 1989]), especially in Open Hypermedia Systems research systems [OHS, Nürnberg 1998]. Links are stored outside of the documents they refer to, in one or more databases of links that are queried by the browser just before showing the document. This architectural choice is extremely flexible and powerful, making many currently unavailable functionalities possible. For instance, this enables different link sets over the same content for different audiences and tasks [Carr 1998]. Third-party individuals can provide links and create guided tours over documents owned by others. Individuals and groups could maintain their own personal linkbases. In a way, this functionality can be had in the current Web, by creating appropriate framesets with HTML 4.0. Although technically possible, this solution is clearly a sophisticated hack hard to generalise.
The XLink [XLink] standard provides the syntax within XML to express both internal links (similar to the "A" element in HTML) and external links, where both (or all, in case of multi-ended links) of the end-points are stored outside of the documents they refer to and use XPointers to identify their exact location. Thus XLinks can be stored in XML documents (de facto linkbases) that are independent of the documents they actually connect. An additional nice feature of XLinks is that although they are expressed with XML syntax, it is possible to specify links over any kind of document for which an XPointer can be expressed.
What the XLink proposal does not cover is how to use these external links. How do we associate a link document to a content document? How can we provide for additional or alternate link documents to the "official" one? How can we express the fact that independently of what is explicitly expressed, an additional, fixed set of link documents containing the private links of the reader should be added to all visited documents? These problems are similar to and yet more complex than the ones stylesheets present, since they involve multiple link sources and linkbase owners, in a situation much more complex than CSS stylesheets often handle.
Here too, individual developers can not decide autonomously on how to resolve these issues for the full Web environment. More research and agreements are needed for external link bases to become a standard feature of our daily work.
Link anchors represent a target area or scope of the link's underlying relationship within each endpoint node. Traversing a link should show the relationship's scope in the destination node. For example, if the link connects a document with a paragraph contradicting a paragraph in another document, then traversing the link should highlight the contradicting paragraph. The HTML language allows node-to-node, span-to-node, and span-to-span links through the "LINK" element using a single "A" element or a pair of "A" elements. However, because today's browsers scroll to destination points instead of highlighting destination spans, few bother to even mark destination spans in a document.
Attributes include semantic types, keywords and other metainformation and attributesñfor both nodes and links. Browsers should have a mechanism built in to display these automatically, perhaps when the user moves the mouse over an anchor (for link metainformation) or the document title bar (for node metainformation).
The RDF proposal by the W3C [RDF] addresses metainformation within Web documents. RDF can record both node and link metainformation, though proposed standard sets of attributes often only describe node metainformation. Rather than a predefined set of fields and permitted values, RDF provides a general syntax for expressing metainformation, and leaves the task of specifying appropriate sets to further conventions (for instance, the Dublin Core set [DublinCore]). Thus we are two steps away from being able to enjoy node and link attributes on the Web. Once the RDF standard is in place, a standard set of metainformation fields must be agreed upon, and then browsers must support standard ways to add them, display them, and otherwise use them (e.g., in structural search). While the Dublin Core Set seems a likely standard set of node attributes, no proposal has been put forth for an architecture that uses them in Web environments.
Until we do provide a seamless, integrated environment for hypermedia and our own daily activities on the Web, few application developers and users will have the incentive, knowledge and energy required to deploy hypermedia functionality [Bieber 2000, Bieber 1997]. The Web finally has the standard data formats and protocols. We now need to provide the tools and conventions so that every user can benefit from them.
We gratefully acknowledge funding for this line of research by the NASA JOVE faculty fellowship program, by the New Jersey Center for Multimedia Research, by the National Center for Transportation and Industrial Productivity at the New Jersey Institute of Technology (NJIT), by the New Jersey Department of Transportation, and by the New Jersey Commission of Science and Technology, and by Rutgers University.