A Link Server For Integrating the Web with Third Party Applications

Helen Ashman, Information Technology Division, Defence Science Technology Organisation, P.O. Box 1500, Salisbury, SA 5108, Australia. Phone +61 8 259 7007 Email: hla@itd.dsto.gov.au

Greg Chase, Information Technology Division, Defence Science Technology Organisation, P.O. Box 1500, Salisbury, SA 5108, Australia. Phone +61 8 259 5383 Email: grc@itd.dsto.gov.au

Michael Dalwood, Information Technology Division, Defence Science Technology Organisation, P.O. Box 1500, Salisbury, SA 5108, Australia

Scott Davis, Information Technology Division, Defence Science Technology Organisation, P.O. Box 1500, Salisbury, SA 5108, Australia. Phone +61 8 259 6306 Email: sbd@itd.dsto.gov.au

Janet Verbyla, Department of Computer Science, Flinders University of South Australia, G.P.O. Box 2100, Adelaide, SA 5001, Australia. Phone +61 8 201 3638 Email: janet@cs.flinders.edu.au Home Page: Janet Verbyla [HREF 2]

Introduction

Definitions of what constitutes an open hypermedia management system have been made by many people. The following have been selected as they capture the key ideas [KONSTANZ94].

• A system which does not impose any mark-up upon the data, which would then prevent the data being accessible to other processes that do not belong to the system.
• A system which can integrate any tool. Data produced by tools that are not part of the hypermedia system may be used without adding anything extra to the data and without compromising the continued use of the data outside the system.
• A system in which data and processes may be distributed across a network, and across hardware platforms.
• A system in which it is easy to add new functionality. i.e. new program modules can be simply inserted to achieve new functionality.

Rationale

As a result of using the Functional Model, three things have been achieved. Firstly, linking can be fully dynamic so both the source determination and destination determinations can be computed at the time they are required. Secondly, the link endpoint specifications and link computation specifications can be stored external to the documents, avoiding the marking up of documents and permitting link specifications to be used globally. Finally, the interoperability of the Functional Model allows the use of third-party computation and viewing applications and their associated well established information sources. This latter feature means that the Functional Model link server can access WWW with a Mosaic browser thus making the Web part of our system.

The Functional Model can be used to address difficulties inherent in the underlying hypermedia model of existing hypermedia systems, including the WWW:

• Link decay - The specification of destination addresses well in advance of an actual use increases the likelihood of the specification becoming invalid.
• Exclusion of legacy systems - Some types of information are well supported by specialist applications with specialised computational and display functionality. It is not necessarily possible or desirable to build such functionality into WWW browsers.
• Few linkable information formats - Links can only operate out of HTML-compliant documents, although they can link into a variety of information formats (filters to convert documents to HTML are slow). Links to non HTML-compliant documents are usually to open the whole document, not necessarily to open it at a particular point, although local display engines can override this.
• Read-only media - A Read-only document cannot be freely converted to another representation and certainly cannot be edited to introduce links out of it.
• Copyright documents - For legal and ethical reasons, copyrighted materials cannot be either converted to another format or be edited to introduce links, unless express permission (usually expensive) is given by the copyright owners.
• No Private links - Because the links are embedded in the document, anyone who can read the document can and must have access to the links. There can only be one set of links for a single document. The exception is for private annotations, as provided by Mosaic 2.4, which are not embedded in the document.
• Global link functionality - Certain types of links that could be globally available such as a dictionary link cannot sensibly be supported with the WWW model since every link source has to be individually tagged with its associated destination, or the computation to create these links must be embedded in every document.
• No link tailorability - It is not possible for readers to use their own links on a WWW document. With the exception of a user's private annotations, all links are those supplied with the document by the document author.
• Addressing limitations - Addressing of link destinations supported by Web browsers is usually on a whole-document basis. "Span addressing" (i.e. addressing and retrieval of sections of things instead of the whole thing) [NELSON88] is not uniformly implemented even though the markup language can support it. A more difficult problem is that the use of markup to demarcate spans means that it is not possible to create and use any number of arbitrarily-defined spans over a document. In contrast, externalised link endpoint specification methodologies do permit this. Nelson's tumbler arithmetic [NELSON88], was the first such method proposed for externalised endpoint specifications, which has now become prevalent among the recent hypermedia systems [DAVIS94] [AV93]. Mosaic 2.4 uses an externalised link endpoint specification to support the facility for private annotations.
• Hyperquerying - While one focus of recent WWW developments has been the investigation of search (query) engines for the Web, the WWW link model does not lend itself to the synergism of querying and browsing that is acknowledged as being mandatory for effective large-scale information systems [HALASZ88] [VERBYLA93]. For instance, the results of a query cannot be linked into the document currently being displayed without recourse to editing the source document.

This project is developing a protocol for open hypermedia to be used to implement dynamic linking in an open and distributed fashion. In the next section an implementation is described which uses the Functional Model to avoid the problems inherent in the model of current HMSs.

Implementation Details

Client connection is handled by a registrar daemon (an event activated process which sleeps at other times). Upon receiving a request and agreeing to the connection, the registrar spawns off a link server for that client. This means each client is connected to its own server avoiding potential bottlenecks due to high-consumption users. Once connection has been achieved it is maintained for the session.

Central to the user end is a "Chooser" which lists choices of possible links; any subsequent requests to the server go through the Chooser. The Chooser organises for a suitable viewer to be started to display any requested documents. It is envisaged that the viewers for a document will be native to the source of the information. For instance, it will use a WWW browser for HTML document viewing and MS Excel for viewing Excel spreadsheets.

If a user asks for the links available from a anchor in a node, a request is sent to the link server via the Chooser. The Chooser acts as the gate keeper to the communications channel. Information included in such a request is passed in a tag-value list. The tags used vary according to what type of node was selecting from. For instance, a selection in a text node may generate values such as URL, selection offset and selection content, while a selection in a video node may generate the values URL and selection time. These values are used as parameters to the evaluation of link_type source predicates. The link server then organises for evaluations to be done by suitable computation agents. Any available link types are then passed back to the Chooser which offers the user the choice of link_types based on their descriptions.

A user selection from the Chooser results in a request being sent to the server, asking for computation of possible destinations. Allowable destinations using the particular link specification and selected anchor will be computed and the Chooser will display these possibilites. Following user selection of a particular destination from these possiblities the Chooser will organise the destinations display. This may mean starting a new viewer or changing what an already running viewer is displaying.

Viewers

We have demonstrated this principle using the Mosaic 2.4 browser. Contradicting the supposition that a system that integrates third-party applications must possess a published interface [DAVIS94], it was demonstrated that a HMS could provide links to a third-party application which did not necessarily provide information about its data structures. Of course, the onus is then on the local HMS to be able to make use of the eavesdropped information. For a frequently used non-cooperative third-party application, the configurability of the link specifications allows link types to be defined expressly for the purpose of making use of information acquired from the cut buffer.

Alternatively, minor source code modifications allow Mosaic to actively participate in this process so that external links to be created from structured data such as titles or graphics. It is a trivial matter to add menu items to a Mosaic browser so that the link server can be queried to see if a selected item is the source of any links.

The viewers currently in use with the HMS in Flinders University and DSTO are a map display application, text and TIFF image viewer and Mosaic. Other viewers planned are a news feed classifier and a movie viewer.

Conclusion

The use of Mosaic as a third party viewer application with this HMS has been successful. Future versions of Mosaic promise a Common Client Interface (CCI) which defines a protocol for communications between Mosaic and external applications. The use of CCI will enable the level of cooperation between Mosaic and our HMS to be raised. For instance the HMS will be able to request a new URL.

In the future other third party applications both related and unrelated to hypermedia will be added to the system.

References

[DAVIS94]
H.C. Davis, S. Knight and W. Hall, Light Hypermedia Link Services: A Study of Third Party Application, Proceedings of the European Conference on Hypermedia Technologies 1994 (ECHT'94), ACM (1994), pp 41-50.

[HALASZ88]
F. Halasz, Reflections on NoteCards: Seven Issues for the Next Generation of Hypermedia Systems, CACM 31(7), July 1988, pp 836-852.

[KONSTANZ94] Proceedings of Workshop on Open Hypertext Systems, Universitat Konstanz, May 1994.

[NELSON88]
T.H. Nelson, Managing Immense Storage, BYTE 13(1), January 1988, pp 225-238.

[VERBYLA93]
J.L.M. Verbyla, Hyperquerying: Taking querying into Hyperspace, Proceedings of the 4th Australian Conference on Information Systems, University of Queensland, September 1993, pp 335-344.

Hypertext References

[AV93]
H.L. Ashman and J.L.M. Verbyla, Externalising Hypermedia Structures with the Functional Model of the Link , Proceedings of Online Information '93, London U.K., Learned Information, 1993, pp 291-301.

HREF 1

http://www.cs.flinders.edu.au/people/Tim_Cawley.html

HREF 2

http://www.cs.flinders.edu.au/people/JLMVerbyla

Copyright