Object Exchange Model Research Articles

Representing and querying histories of semistructured databases using multidimensional OEM

Multidimensional semistructured data (MSSD) are semistructured data that present different facets under different contexts. Context represents alternative worlds, and is expressed by assigning values to a set of user-defined variables called dimensions. The notion of context has been incorporated in the object exchange model (OEM), and the extended model is called Multidimensional OEM (MOEM), a graph model for MSSD. In this paper, we explain in detail how MOEM can represent the history of an OEM database. We discuss how MOEM properties are applied in the case of representing OEM histories, and show that temporal OEM snapshots can be obtained from MOEM. We present a system that implements the proposed ideas, and we use an example scenario to demonstrate how an underlying MOEM database accommodates changes in an OEM database. Furthermore, we show that MOEM is capable to model changes occurring not only in OEM databases, but in Multidimensional OEM databases as well. The use of multidimensional query language (MQL), a query language for MSSD, is proposed for querying the history of OEM databases and MOEM databases.

Modelling the history of semi-structured geographical entities

Geographical entities are characterized by rather complex structures. They involve space and thematic information, which is subject to change in time, while history should be maintained. On the other hand, these structures may be irregular (i.e. they do not necessarily conform to a fixed schema), because associated data is usually collected based on different specifications and multiple resolutions. Hence, the representation of geographical entities in traditional data models, such as the relational or object-oriented, is not always feasible. In this respect, this paper investigates the use of semi-structured data (SSD) models—an innovative approach recently developed in Information Technology—for modelling dynamic geographical entities. A framework for the representation of geographic entities in Object Exchange Model (OEM), a popular model for semi-structured data, is introduced. Additionally, it is shown how useful information can be extracted from such a representation using the LOREL query language for SSD. A simplified case study in the application domain of cadastre involving SSD is examined closely.

Representation of Generalized Map Series Using Semi-Structured Data Models

Large cartographic organizations worldwide produce generalized map series (GMS) in order to meet various user requirements. A GMS consists of maps of the same geographic region at different scales. Most of these maps currently are designed in a digital environment, and recently some of them have been distributed through the web. One important issue is the appropriate modeling and handling of cartographic entities composing individual maps in a GMS. Since these entities have rather complex descriptions and may be provided by various agencies, they usually do not conform to a fixed schema (i.e., they do not have a common structure). Hence, their representation in traditional data models, such as the relational or object-oriented, is not always feasible. This paper investigates the use of semi-structured data (SSD) models—an innovative approach recently developed in Information Technology for representing and handling entities in a GMS. Specifically, the Object Exchange Model (OEM), a popular database model for SSD, has been adopted to represent a GMS. How useful information can be extracted from such a representation using the LOREL query language—a popular language for SSD—is also shown.

An approach for the extensional integration of data sources with heterogeneous representation formats

In this paper we propose an approach for the extensional integration of data sources with heterogeneous representation formats. The proposed approach is based on the exploitation of a new model, called E-SDR-Network, for representing and handling, at the extensional level, heterogeneous data sources, ranging from databases to XML documents, object exchange model graphs and other semi-structured data. Due to the specific features of E-SDR-Network, the proposed extensional integration methodology is capable of: (i) easily handling null or unknown values, (ii) producing consistent query answers from possibly inconsistent data and (iii) reconstructing, at the extensional level, the content of each data source involved in the integration task. Finally, we show that E-SDR-Network and the proposed extensional integration algorithm are the counterpart, at the extensional level, of the SDR-Network conceptual model and the associated intensional integration algorithm, already proposed in the literature. Therefore, in the whole, we obtain a complete approach consisting of two components performing synergically both the intensional and the extensional integration of data sources having heterogeneous data representation formats.

Extracting schema from an OEM database

While the schema-less feature of the OEM (Object Exchange Model) gives flexibility in representing semi-structured data, it brings difficulty in formulating database queries. Extracting schema from an OEM database then becomes an important research topic. This paper presents a new approach to this topic with the following features. (1) In addition to representing the nested label structure of an OEM database, the proposed OEM schema keeps up-to-date information about instance objects of the database. The object-level information is useful in speeding up query evaluation. (2) The OEM schema is explicitly represented as a label-set, which is easy to construct and update. (3) The OEM schema of a database is statically built and dynamically updated. The time complexity of building the OEM schema is linear in the size of the OEM database. (4) The approach is applicable to a wide range of areas where the underlying schema is much smaller than the database itself (e.g. data warehouses that are made from a set of heterogeneous databases).

Template-based wrappers in the TSIMMIS system

In order to access information from a variety of heterogeneous information sources, one has to be able to translate queries and data from one data model into another. This functionality is provided by so-called (source) wrappers [4,8] which convert queries into one or more commands/queries understandable by the underlying source and transform the native results into a format understood by the application. As part of the TSIMMIS project [1, 6] we have developed hard-coded wrappers for a variety of sources (e.g., Sybase DBMS, WWW pages, etc.) including legacy systems (Folio). However, anyone who has built a wrapper before can attest that a lot of effort goes into developing and writing such a wrapper. In situations where it is important or desirable to gain access to new sources quickly, this is a major drawback. Furthermore, we have also observed that only a relatively small part of the code deals with the specific access details of the source. The rest of the code is either common among wrappers or implements query and data transformation that could be expressed in a high level, declarative fashion. Based on these observations, we have developed a wrapper implementation toolkit [7] for quickly building wrappers. The toolkit contains a library for commonly used functions, such as for receiving queries from the application and packaging results. It also contains a facility for translating queries into source-specific commands, and for translating results into a model useful to the application. The philosophy behind our “template-based” translation methodology is as follows. The wrapper implementor specifies a set of templates (rules) written in a high level declarative language that describe the queries accepted by the wrapper as well as the objects that it returns. If an application query matches a template, an implementor-provided action associated with the template is executed to provide the native query for the underlying source 1 . When the source returns the result of the query, the wrapper transforms the answer which is represented in the data model of the source into a representation that is used by the application. Using this toolkit one can quickly design a simple wrapper with a few templates that cover some of the desired functionality, probably the one that is most urgently needed. However, templates can be added gradually as more functionality is required later on. Another important use of wrappers is in extending the query capabilities of a source. For instance, some sources may not be capable of answering queries that have multiple predicates. In such cases, it is necessary to pose a native query to such a source using only predicates that the source is capable of handling. The rest of the predicates are automatically separated from the user query and form a filter query . When the wrapper receives the results, a post-processing engine applies the filter query. This engine supports a set of built-in predicates based on the comparison operators =,≠,<,>, etc. In addition, the engine supports more complex predicates that can be specified as part of the filter query. The postprocessing engine is common to wrappers of all sources and is part of the wrapper toolkit. Note that because of postprocessing, the wrapper can handle a much larger class of queries than those that exactly match the templates it has been given. Figure 1 shows an overview of the wrapper architecture as it is currently implemented in our TSIMMIS testbed. Shaded components are provided by the toolkit, the white component is source-specific and must be generated by the implementor. The driver component controls the translation process and invokes the following services: the parser which parses the templates, the native schema, as well as the incoming queries into internal data structures, the matcher which matches a query against the set of templates and creates a filter query for postprocessing if necessary, the native component which submits the generated action string to the source, and extracts the data from the native result using the information given in the source schema, and the engine , which transforms and packages the result and applies a postprocessing filter if one has been created by the matcher. We now describe the sequence of events that occur at the wrapper during the translation of a query and its result using an example from our prototype system. The queries are formulated using a rule-based language called MSL that has been developed as a template specification and query language for the TSIMMIS project. Data is represented using our Object Exchange Model (OEM). We will briefly describe MSL and OEM in the next section. Details on MSL can be found in [5], a full introduction to OEM is given in [1].