HyperPATH/O2: Integrating hypermedia systems with object-oriented database systems

Amann, Bernd; Christophides, Vassilis; Scholl, Micheł

doi:10.1007/3-540-57234-1_74

Cited by 4 publications

(3 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The overall system architecture is shown in Figure 5. Figure 5: Multicard / O Architecture In a first step, we have connected Multicard with O¡ by using the C++ programming interface of O¡ (Amann, Christophides, and Scholl 1993). This integration provides a clean separation of the hypertext structure (storage layer) stored in an O¡ database from the node contents (within-component layer) manipulated by Multicard compliant editors (MCEditor, Emacs, Go, etc.…”

Section: Methodsmentioning

confidence: 99%

Schema-based authoring and querying of large hypertexts

Amann¹,

Scholl²,

Rizk³

1995

International Journal of Human-Computer Studies

View full text Add to dashboard Cite

Section: Methodsmentioning

confidence: 99%

Schema-based authoring and querying of large hypertexts

Amann¹,

Scholl²,

Rizk³

1995

International Journal of Human-Computer Studies

View full text Add to dashboard Cite

“…E.g., HyperPath/O2 (Amann et al 1993) and MultiCard/O2 are built on top the OODBMS O2. HyperPath/ O2 and MultiCard/O2 utilize O2 only as the persistent depository of their so called hypermedia basic classes.…”

Section: Related Workmentioning

confidence: 99%

“…This approach was adequate for certain applications and for research, but did not exploit existing solutions from other areas, and could not serve as the basis of future integrated information systems. This was soon recognized, and with regard to the storage layer, either database management systems (DBMSs) were used, like in HyperBase (Schütt and Streitz 1990) or HyperPath/O2 (Amann et al 1993), or special-purpose storage managers were developed, like HAM (Campell and Goodman 1988) or Hyperform (Wiil and Leggett 1992). The disadvantage of the second approach is that many of the standard DBMS functionalities needed for persistent storage and sharing of data, like transaction management or declarative access, have either to be re-implemented, e.g., concurrency control, or are not available at all, e.g., declarative query languages.…”

Section: Introductionmentioning

confidence: 99%

Flexible Design and Efficient Implementation of a Hypermedia Document Database System by Tailoring Semantic Relationships

Wäsch

Aberer

1997

Database Applications Semantics

View full text Add to dashboard Cite

In this paper we present the design concepts and data modeling approach that was used to define a general application framework for storing hypermedia documents in the object-oriented database management system VODAK. We exploit the capabilities of the VODAK data model to introduce new hypermedia modeling primitives at the meta level. We show that representing the hypermedia semantics within the DBMS in this way is clearly advantageous for efficiency of the design and implementation of hypermedia document storage engines. As an example, we give a concrete realization of a DBMS-based hypermedia engine for the SEPIA hypermedia authoring system developed at GMD-IPSI. With this example we show that the data model extensions provided are flexible enough to represent also complex semantic hypermedia concepts, that the development cycle of a hypermedia engine can become extremely fast and that the resulting implementation has adequate performance for interactive applications.

show abstract

Designing and integrating user interfaces of geographic database applications

Voisard

1994

Proceedings of the Workshop on Advanced Visual Interfaces - AVI '94

View full text Add to dashboard Cite

In this paper, we investigate the problem of designing graphical geographic database user interfaces (GDUls) and of integrating them into a database management system (DBMS). Geographic applications may vary widely but they all have common aspects due to the spatial component of their data: Geographic data are not standard data and they require appropriate tools for (i) editing them (i.e., display and modify) and (ii) querying them. The conceptual problems encountered in designing GDUIs are partly due to the merger of two independent fields, geographic DBMSs on the one hand, and graphical user interfaces (GUIs) on the other hand. Although these areas have evolved considerably during the past ten years, only little effort has been made to understand the problems of connecting them in order to efficiently manipulate geographic dat.a on a display. This issue raises the general problem of coupling a DBMS with specialized modules (in particular, the problem of strong vs. weak integration), and more generally of the role of a DBMS in a specific application. After giving the functionalities that a GDUI should provide, we study the possible conceptual integrations between a GUI and a DBMS. Finally, a map editing model as well as a general and modular GDUI architecture are presented.

show abstract

HyperPATH/O2: Integrating hypermedia systems with object-oriented database systems

Cited by 4 publications

References 13 publications

Schema-based authoring and querying of large hypertexts

Schema-based authoring and querying of large hypertexts

Flexible Design and Efficient Implementation of a Hypermedia Document Database System by Tailoring Semantic Relationships

Designing and integrating user interfaces of geographic database applications

Contact Info

Product

Resources

About