Hypermedia

1
Hypermedia

• The History continued And todays componend based
  OHM

2
From 1994 and on
3
The war

• Domain researchers can explore entirely new sets
  of questions concerning distribution,
  collaboration and integration of different
  structure models without having to implement
  backend (or perhaps even structure server)
  support.
• System researchers can gain whole new audiences
  in which to test designs and implementations.
• The situation seems laden with exciting
  possibilities for the hypermedia field. If
  CB-OHSs are to realize their full potential,
  though, the gap between domain and system
  research must be bridged.

4
A HYPERMEDIA RESEARCH AGENDA
5
Human Layer

• The open structure server layer in CB-OHSs makes
  this an area we can no longer ignore. In the
  past, we have relied nearly exclusively on the
  initial navigational domain observations made by
  Bush.
• Since all hypermedia domain research is based on
  observations of peoples use of structure, the
  hypermedia field as a whole has much experience
  in considering peoples use of structure.

6
Client Interface

• There has been very little consensus on even
  relatively old interface issues such as how
  best to display link endpoints in data. For
  example, even considering only textual data, is
  blue, underlined text really the best way to
  denote a source anchor?
• The possibility of clients that present multiple
  structure models to users simultaneously,
  however, raises issues of consistency of
  presentation. For example, consider the HOSS
  TaxEd, a client of both taxonomic and associative
  structure servers 1221. In this case, it is not
  reasonable to consider presentation of taxonomic
  and associative structures separately since this
  client must present both.

7
Client Layer

• Work regarding integration of third-party
  applications into associative environments has
  noted that there are different levels of
  integration that can be achieved for different
  clients.
• Can some of the effort expended in the
  integration of an application into one domain
  environment be reused in its integration into
  other domain environments?
• Finally, there are a series of issues with regard
  to the recognition and use of advanced backend
  facilities and the automatic distribution of this
  new architecture. What does versioning allow in
  taxonomic hypermedia systems? How can the
  collaborative work support of hypermedia system
  backends be used in a spatial hypermedia system!

8

• The hypermedia field is at an important and
  interesting time in its development. The system
  work that has been done over the last decade has
  reached a level of stability and maturity,
  embodied in the OHSWG adoption of a CB-OHS
  conceptual architecture
• Domain researchers can expect easier construction
  of mom powerful clients and systems for their
  experiments and work.
• System developers can expect a growing number of
  users with diverse requirements to fuel the
  improvement of their work.

9
Definition

• An environment that provides multiple open
  services has three basic requirements.
• Firstly, the environment should be based on an
  open architectural framework.
• Secondly, the provided services should be
  generally available.
• Finally, the provided services should themselves
  be open.

10
The idea

• The overall idea with multiple open services is
  to rethink the way in which services are provided
  to clients. The goal is to split up services into
  components, each of which provides a general,
  scalable, and functionally independent service.
• These services are provided through a common
  interface that allows an open set of desktop
  applications to make use of the services
• Prominent examples of open hypermedia systems
  developed in the past decade include Microcosm,
  DHM, Chimera, HOSS, and HyperDisco. These systems
  have been successful in providing open hypermedia
  middleware services, especially linking, to a
  wide range of desktop applications e.g., MS Word,
  MS Excel, Netscape, MS Internet Explorer, Emacs,
  and FrameMaker.

11
CB-OHM

• HyperDisco is an example of an early CB-OHS that
  provides multiple services. HyperDisco provides
  different types of services to participating
  applications
• Integration. This refers to a service that allows
  integration of existing services
• Interoperability. The interoperability service
  allows HyperDisco to interoperate with other OHSs
  as well as with integrated applications, stores,
  and services.
• Distribution. The distribution service allows
  HyperDisco system components like workspaces,
  tool integrators and integrated applications.
• Navigational hypermedia authoring. This refers to
  a service that allows hypermedia links to be
  created between different documents.
• Navigational hypermedia browsing. This refers to
  a service that allows hypermedia links to be
  traversed.
• Collaboration. The collaboration set of services
  allows users to engage in asynchronous and
  synchronous collaborative work settings when
  creating both documents and structure.
• Versioning. The versioning service allows
  documents registered with HyperDisco to be
  versioned.

12
HyperDisco
13
Why is HyperDisco not an CB-OHS

• Definition
• Open architectural framework.
• General availability
• Open service.
• Orthogonality of open services.
• Generality of open services.
• Scalability of open services.
• 3a Applications should be able to use an open
  service without altering their use of the
  existing services vailable in the environment.
• 3c An open service should provide different
  levels of its services. Applications need not
  integrate advanced levels of a service if only a
  basic level is desired.

14
What should CB-OHM look like
15
The important things to notice

• Services belong to a layer in the architecture
  depending on the type of service they provide
• All services at a layer must comply with the open
  service requirements, hence they must be
  functionally independent, general and scalable.
• Each layer is open to new services as long as the
  requirements for open services are ensured. Thus,
  it is possible to add new types of structure
  services (e.g., argumentation support and
  workflow services) to the set of existing
  structure services.
• Any component can in principle be a client of any
  other component.

16
Construct
17
Construct

• Applications. This category includes desktop
  applications (e.g., Netscape, MS Word, and Emacs)
  that have been integrated (modified, extended, or
  wrapped) to be able to make use of the Construct
  structure services.
• Wrapper services. Allows legacy application and
  middleware services, data stores, etc. to be
  integrated
• Structure services. navigational, spatial,
  taxonomic, argumentation, workflow, and
  collaboration
• Structure stores. Storage and retrieval of
  structure.
• Multiuser and collaboration services.
  Concurrency control, notification control, and
  access control.
• Versioning services. Services that allows
  structural abstractions to be versioned.
• Data stores.
• Infrastructure services. Service discovery,
  naming, and location.
• Development tools. UML Tool. Emacs. Construct
  Service Compiler (CSC). The CSC takes IDL
  specifications as input and generates service
  skeletons in Java.

18
Construct
Vital as a Construct application. Vital anchors
are shown as arrow icons and Construct anchors
are shown as anchor icons attached to the linked
pieces of information.
19
Construct
The initial Construct menu in Emacs before the
list of services is updated.
20
Construct
21
Construct
22
A extensibility classifying framwork
23
A extensibility classifying framwork
24
A extensibility classifying framwork