Chapter 4

Spatiotemporal Knowledge Representation in AROM-ST

4.1. Introduction

Arising from frame languages [MIN 75], close to description logics [BAA 03] and ontological languages [MCG 04], object-oriented knowledge representation systems (also known as OOKRS) [DUC 98, NAP 04] describe, organize, and store knowledge by relying on the general principles of the object paradigm (notions of class, instance, specialization hierarchy). They have various inference mechanisms (inheritance, procedural attachment, filtering, classification) that allow them to clarify the knowledge and fill in any missing pieces.

Among the various OOKRS, AROM (an acronym for “Allier Relations et Objets pour Modéliser” (Ally Relations and Objects to Model) [PAG 00]) is distinctive due to its two core complementary representation structures – classes and associations, like the entities used in UML class diagrams. Another particularity of AROM is the presence of an algebraic modeling language (AML). AMLs (AMPL¹, LINGO²) offer to represent equation, constraint, or query systems due to a formalism close to notations generally used in mathematics.

In AROM, the AML allows us to build algebraic expressions integrating the base types, managed by the system, and their associated operators, which considerably increases the system's expressiveness, defined as its description power in knowledge expression.

Indeed, these algebraic expressions allow us not only to formulate queries on an AROM knowledge base, but also to introduce into the model the value of an attribute at the definition creation stage, as well as to introduce constraints involving one or more attributes.

Moreover, since the AROM's type module is expandable, we can enrich the AML with new types and new operators. This enabled us to expand AROM and add spatiotemporal operators, and use it as a modeling and data management tool for applications with spatiotemporal data. AROM-ST thus allowed us to fill certain expressiveness shortcomings of the classical geographical information system (GIS) and database management system (DBMS); it is also an interesting alternative to conceptual modeling tools, such as MADS [SPA 07] and PERCEPTORY [BÉD 04], whose expressiveness is limited by an approach based on pictograms, and whose usability is also limited by code generation approach. In fact, AROM-ST has proved itself, and is used as a modeling and data management tool for the spatiotemporal information system generator GENGHIS [MOI 08] (see Chapter 5).

This chapter presents AROM-ST, the spatiotemporal extension to AROM. AROM-ST is a spatiotemporal knowledge representation tool dedicated to modeling and data management for spatiotemporal applications.

The chapter is divided up as follows: section 4.2 presents AROM-ST's qualities that led us to suggest a time extension. Section 4.3 gives details of the characteristics of the AROM-ST extension. Section 4.4 showcases two AROM-ST extensions designed for the semantic Web: AROM-OWL and ONTOAST. Section 4.5 provides an insight into the software architecture behind the AROM platform. Section 4.6 describes the AROM-ST user community. Finally, section 4.7 concludes the chapter, and sketches a few future development directions for AROM-ST.

4.2. From AROM to AROM-ST

4.2.1. AROM in context: a knowledge representation tool

Among the different knowledge representation paradigms, object-oriented knowledge representation (OOKR) allows us to model knowledge relative to a specific application domain by relying on representation entities called “objects”. Among these objects, we usually separate “classes” and “instances” (except for “prototype” languages for which these entities are merged). A class translates a concept, a family of individuals, providing a set of properties or “attributes” that characterize them. An instance represents an individual. An attribute is described by a name and a set of “facets”.

The OOKRS are distinguishable by the facets they offer. The “typed facets” are essential because they specify the type and set (called “domain”) of the attribute's possible values, or in the case of a multivalued attribute, the number of possible values. An attribute's type can be defined among those (integer, boolean, string, etc.) present in the programming language used for implementation. It can be elaborated from builders (such as set-of and list-of). It can also refer to a class present in the knowledge base. In that case, the attribute models the oriented relation of an ordinary binary relation established between the attribute class and the domain class designated by the type. “Inference facets” describe a way to obtain an attribute's value when the latter is not present. Default value, procedural attachment (which calls up a method), filtering (the attribute's value is the result of a query), and value passing (which assigns an attribute another attribute's value) are the major inference mechanisms designated by OOKRS facets. The “reflex facets” allow us to implement an action before or after accessing, modifying, adding, or deleting a value. Finally, secondary facets enable, for example, the association of an HTML description to an attribute.

Within a knowledge base, classes are organized in a specialization hierarchy that is shaped either as a tree or as a graph. Specialization is a partial order relation where each description of a class attribute is of the following: (1) the same as the description of this same attribute in the superclass, (2) has a type which is a subtype of the description of this same attribute in the superclass, and (3) corresponds to the definition of a new attribute. Indeed, class instances are instances of its superclass, specialization is equal to set inclusion. An inheritance mechanism adds itself to the specialization hierarchies, allowing us to factorize this information. These hierarchies are also the support for a core inference mechanism in OOKR: classification. It is of two types:

– “Instance classification”, which aims to “bring down” an instance from its attachment class to its more specialized subclasses, by activating, if needed, the inference mechanisms required to determine missing attribute values.

– “Class classification”, which determines the insertion position(s) of a class in the specialization hierarchy by looking for the more specialized superclasses and the more general subclasses.

Beyond type verifications related to any assignment of a value to an attribute, some OOKRS integrate consistency maintenance mechanisms that aim to disseminate the consequences of any change to an object of the knowledge base to adjacent objects.

4.2.2. Originalities

AROM [PAG 00] is a knowledge representation system in line with other OOKRS. It takes up their main principles: distinction between classes and instances, class specialization in an inheritance hierarchy, and presence of typed and inference facets. However, it is distinguishable from its predecessors in its way of representing relations between objects: AROM forbids the use of relational attributes (attributes typed by a class) and forces the modeling of relations between objects in an explicit manner, due to a second entity: association. An AROM-ST association is a named entity representing a set of n-tuple objects (n ≥ 2) which it links. It is described by its roles (connection between the association and one of the linked classes) and by a set of variables (identical to UML attributes) defining properties related to the n-tuples. An inheritance of the roles, variables, and faces is possible between associations due to a specialization hierarchy similar to the class specialization hierarchy.

AROM's AML aims to define and manipulate the algebraic expressions contained in constants, variables, and operators of any type managed by AROM. By integrating the identifiers for classes, associations, objects (class instances), and tuples (association instances), these expressions allow us to question and use the entities defined in a knowledge base.

4.2.3. Why a spatiotemporal extension?

4.2.3.1. Existence

One of the solutions aiming to avoid the inconveniences of DBMS related to the integration of time and space comes from the conceptual modeling field [BÉD 04, SPA 07]. The emergence of conceptual modeling tools offers an interesting possibility to spatiotemporal data application designers. Indeed, the joint use of conceptual modeling tools with DBMS can ease designer's work in such applications and reduce the development time of these applications. The use of modeling tools also allows us to make up for certain shortcomings in terms of expressiveness at the DBMS level. For example, the MADS tool [SPA 07] allows us to express spatiotemporal constraints on object relations that are transformed by a code generator into integrity constraints at the level of the target DBMS.

MADS has revealed itself to be a very exhaustive and homogeneous representation model. The topological and time relation management through associations brings something extra to the table compared to other approaches, and associating generation with transition means we can model certain dynamic aspects of reality. The spatial and temporal pictograms are explicit enough, which allows for a relatively easy use without needing much prior programming knowledge.

PERCEPTORY [BÉD 04] offers a conceptual solution to the issue of multiple representations, with the possibility of describing three-dimensional spatial objects. However, it suffers from a lack of spatial, temporal, and causal notions at an association level. On this point, PERCEPTORY is less powerful than MADS. The pictogram multiplication (along lines, columns, accolades, spaces, etc.) forces spatiotemporal information system designers to a certain learning curve.

In spite of the improvements brought to relational DBMS with conceptual modeling tools, there are still two main disadvantages. First of all, the expressiveness of the pictogram modeling approach reaches its limits very quickly when expressing integrity constraints. MADS is the only tool that allows us to express space and time constraints, but these constraints apply only to association (and not to classes) and there is a very limited choice. Moreover, the easy use aspect of the code generation approach reaches its limits as soon as users wish to apply modifications or changes to their application. They must either regenerate the data diagram (which implies redoing the data acquisition work), or modify the DBMS diagrams by hand, and in that case, we lose the benefits of the conceptual approach. Owing to its expandable AML, AROM can avoid these pitfalls. Therefore, the idea of using it to design and implement applications with spatiotemporal information seemed obvious to us.

4.2.3.2. AROM's contribution

Parent et al. [PAR 99] list a series of evaluation criteria for spatiotemporal application design tools. Among expected qualities for a good conceptual modeling tool for spatiotemporal information systems (STIS from now on), the following are to be taken into account:

• – simplicity;
• – conceptualization seen as the direct match between real objects and model entities;
• – language's expressive power, in terms of the integration of object types, association types, specialization relations, aggregation, multivalued attributes, integrity constraints, etc.;
• – visual convention use for modeling;
• – understandability;
• – orthogonality between the spatial dimension and the time dimension;
• – formal definitions.

By reviewing all the criteria, we realize that for the most part they are all linked to modeling in general, and that the AROM language satisfies them all except for the orthogonality between space and time, since in its basic version, AROM offers neither representations nor processes dedicated to time or space.

Indeed, AROM's language, based on a modeling approach similar to UML's, offers a generic, simple, and accessible representation language. This simplicity is due to an abstraction process of the modeling approach, since the number of typed entities used for the modeling was rather limited. Accessibility is due in part to the similarity between the concepts of the object paradigm and our perception of the concepts and objects in real life; and, on the other hand, to the notoriety of UML language in the digital world.

The expressiveness of the AROM language is due to the fact that it allies object-oriented modeling concepts with the power of an AML. It allows us to create simple models that can be enriched by a wide variety of integrity constraints: typing, field, multiplicity, and cardinality constraints to which integrity constraints described with AML equations can be added. AROM's AML is, in its basic version, similar to OCL [UML 03] and has an equivalent expressiveness [MOI 07].

The AROM language has a visual design language, based on a graphical representation similar to UML's class diagrams. To guarantee the solidity of AROM and the mechanisms it must welcome, its representation language has been provided with denotational semantics based on an abstract syntax of AROM.

These arguments led us to the conclusion that AROM is a favored tool for object and spatiotemporal relation modeling due to classes, associations, and the AML; it could thus be a very interesting solution. However, space and time management were not one of the goals of the system's designers. We have explored the possibility to expand AROM with concepts linked to time and space. There are two possible solutions:

• – use the system with its current representation possibility and implant complex abstract data types (ADTs) (polygon, polyline, etc.) such as associations of system base types (for example, points and real number pairs);
• – extend the AROM model to introduce the concepts and spatiotemporal types.

AROM has already been used as a design and data management tool for spatiotemporal information systems [BIS 04, MOK 04]. However, previous solutions, based on the use of an ADT, had certain inconveniences linked to the complexity of the time and space data.

ADTs can indeed be created by using the system's modeling possibility They are then represented as classes covering various attributes of base type or, if necessary, as various classes linked by associations. Using this approach, it is theoretically possible to infinitely expand the base types of AROM. This simple and rather efficient solution has however many disadvantages.

From a modeling point of view, ADTs introduce a “pollution” of knowledge bases by introducing “low-level” modeling entities that complicate the model. The need to model and explicitly manipulate ADTs on which the field representation is built, distances the user from its first modeling preoccupations and forces him/her to mix concepts belonging to the modeled field with concepts linked to ADTs. In conclusion, given the advantages of a solution based on the extension of the AROM metamodel and its type system, we have favored it in our approach. In the following section, we will first present the AROM-ST metamodel before detailing the type system extension.

4.3. AROM-ST

4.3.1. Metamodel

The AROM-ST metamodel allows us to model independently the dimensions of space and time. The term “independently” here means that the spatial and non-spatial objects must behave in the same way versus time, and, reciprocally, time and non-time objects must behave in the same way versus space. This independence allows, for example, ascendant compatibility of data models: an AROM knowledge base is compatible with the AROM-ST language (and model).

The introduction of temporality and spatiality at a class level is carried out by adding attributes (see Figure 4.1).

Classes situated at the top of the hierarchy represent modeling entities already present in AROM-ST (Object, Attribute, and Link classes in Figure 4.1). The spatiotemporal entities extend them by adding space and/or time attributes:

– To change a non-spatial object (Object class in Figure 4.1) into a spatial object (Spatial Object class), we only need to add a space (type) attribute (Spatial Attribute class) that represents its spatial extent.

– To change an atemporal object (sustainable) into a temporal object (Temporal Object class), we must add a time (type) attribute (Temporal Attribute class) that represents its lifespan.

Figure 4.1. The AROM-ST metamodel

When a spatiotemporal object (Spatiotemporal Object class) has both a temporal attribute and a spatial attribute, it inherits the behavior of both the spatial and temporal objects.

Adding spatial attributes creates no conceptual difficulty: the spatial objects can be one-time objects, linear objects, surface objects, or complex objects, depending on the concrete type of the spatial attribute that represents their extent. To take into account spatial objects to which various representations of the spatial extent are associated, we have created, in the AROM-ST model, a dedicated class, the Multirepresentation Object class.

To take into account the display of maps with various scales [PAR 99], we chose to integrate into the AROM-ST model the ability to store various geometries for the same object. Indeed, the multiscale display creates a series of cartographic generalization issues; the same geographical objects must be represented at various scales with different levels of detail:

• – For large scales, the geographical objects must be represented with more geometric details.
• – For small scales, the fine geometrical details are not visible, but, given that the number of simultaneously visible geographical objects becomes important, it affects application performances.

Thus, it is necessary to simplify even more the geometry of geographical objects as we lower the display scale. Unfortunately, due to its complexity, the cartography generalization process cannot be automatically carried out when the query is launched. The only efficient solution to this issue is to allow for the storage of various geometries for the same geographical object.

4.3.2. Objects and time relationships

The temporal dimension can be assessed according to two aspects for real-world objects:

• – The existence of the objects itself, which determines their creation/destruction cycle. The temporal aspect is then placed at the level of the object.
• – The evolution of the objects during their lifetime, which determines their change of state. In that case, the temporal aspect is placed at the level of the attributes.

AROM-ST's temporal model manages these two aspects.

It is important to note the difference between the existence of the objects in the real world and the existence of the objects in the system. A temporal knowledge base has a historical dimension, meaning that it keeps all the past objects. At the end of the lifecycle of a temporal object, the system records only the fact that the object is not valid anymore, but it is not physically deleted from the knowledge base. The temporal objects that are no longer valid can thus be questioned through historical queries.

The introduction of temporality at the level of AROM classes allows us to express the lifecycle of real-world objects. From a conceptual point of view, when it comes to lifecycles, we can consider four kinds of objects: sustainable objects, objects with a limited lifespan, objects with a one-time existence, and recurring objects.

Atemporal objects have no lifespan. These objects can be represented by AROM standard class type. We should note that even if these objects have no temporal dimension at the level of their lifecycle, they can have attributes that may vary in time.

Limited lifespan objects are objects that have their lifecycle (creation/destruction) recorded in the database. These objects are kept at the level of the knowledge base even after their destruction and can thus be questioned due to queries. The classes that represent this type of object have an Interval Lifespan attribute that indicates the object's lifespan.

Figure 4.2. Temporal objects and attributes in AROM-ST

One-time objects make up events (phenomena that can be natural, social, etc.) that require, due to their importance, to be modeled as such in the knowledge base. Their representation on the time axis is a point. The classes that represent this type of object have an Instant type attribute.

Recurring objects are objects whose creation/destruction cycle can be taken up more than once, processes or phenomena that appear and disappear within a certain periodicity. The classes that represent this type of object have a CompositeTime type attribute (set of moments or temporal intervals).

Atemporal associations are associations linking atemporal objects. Introducing temporality in the system creates two types of associations: lifespan associations and historical associations.

Lifespan temporal associations describe a relation to the real world that exists as long as the objects involved coexist. For example, it is possible to model a neighborhood situation between two buildings through an association. This association has meaning only during the period in which the two buildings exist; the destruction of a building leads to the destruction of the association. Such an association can link various object classes, among which at least one must be temporal. The lifespan of this type of association cannot go beyond the temporal interval which is a result of the intersection of intervals that represent the lifespans of the objects making up the association. This means that the objects participating in the link must all be valid (existing) for the link to be valid.

The second type of association with a time component described a link that starts when all the associated objects exist, and that persists even after the disappearance of one or more objects creating it. This type of association has a historical dimension. Relations that have a “cause–effect” type of component must be represented by this kind of association.

For example, an association describing the neighborhood relation between two persons is valid only for a limited time, as long as the persons coexist and live in neighboring apartments.

However, an association describing a “cause–effect” type of relation, such as a father–son relation, is a historical type of association. The blood relationship between the two people starts when the son is born and remains true even if one or both persons have ceased to exist in the real world (and are no longer valid within the knowledge base).

In AROM-ST, it is possible to manage the evolution of objects over time, to represent time varying objects (TimeVaryingAttribute class in Figure 4.3). To that end, we must draw a line between time varying attributes, which are any type of attribute whose value changes over time, and temporal attributes (TemporalAttribute class in Figure 4.3), which have a fixed value of temporal type (Instant, Interval, MultiInstant, or MultiInterval).

Figure 4.3. Representation of attributes with discrete and continuous variations

Time varying attributes can be put into two categories, depending on the type of change they incur:

• – attributes whose time variation happens continuously and whose measured value validity is limited to the measuring moment (ContinuousAttribute class in Figure 4.3);
• – attributes that incur discrete changes in increments (DiscreteAttribute class in Figure 4.3). They keep the same value during a certain time, but change sharply in value. In that case, the value validity period is described by a temporal interval.

One specific case is that of continuous variation attribute subject to interpolation. From a conceptual point of view, it is unnecessary to overload the model by creating a new type of attribute. However, at the level of implementation, there are more performing storing methods for this type of attribute.

From these measured values, it is possible to extract a function to calculate the value of the attribute versus time, and then to store its parameters. At the time of the query, the value of the attribute is calculated versus time. Storing such attributes is possible in AROM-ST through objects equipped with AML expressions to calculate interpolations. Thus, it is only a more efficient method in case the number of attribute values is too high (real-time systems, for example).

The objects become temporal (or, respectively, spatial) as soon as we add temporal attributes (or, respectively, spatial attributes). A temporal object must have at least one temporal attribute that represents its lifespan. A spatial object must have at least one spatial (geometrical) attribute that gives its geographical representation. Spatial attributes can have geometrical representations for one or more cartographic scales.

4.3.3. Space and time types

AROM-ST's spatial types (see Figure 4.4) are in line with the Open Geospatial Consortium (OGC) [OGC 08] specifications. According to this norm, the necessary and sufficient set of types to represent spatial objects is made of the following simple geometrical types: Point, Polyline, Polygon. The Line and LinearRing types are defined by applying constraints to the Polyline type.

Figure 4.4. AROM-ST's geometrical model, in line with OGC specifications

From these simple types, complex (compound) geometrical types can be defined as seen in Figure 4.4: Multipoint (a cloud of points), MultiLine (a set of polylines), and MultiArea (a set of polygons). The simple temporal types in AROM are the Instant type and the Interval type. Compound types making a series of instants or intervals are the MultiInstant and MultiInterval types (see Figure 4.5).

Figure 4.5. Data temporal type structures

The available AML operators for spatial and temporal types are divided into three categories: topology operators, set operators, and measure operators. They can be used to carry out quantitative spatiotemporal reasonings (set operators and measure operators) or qualitative reasonings (topology operators). We will detail them in section 4.4 about qualitative and quantitative spatial reasonings.

4.3.4. Spatial modeling example with AROM

To illustrate the different aspects of AROM modeling, we are studying a simple example (see Figure 4.6) that allows us to represent the territorial unit hierarchy in a knowledge base dedicated to natural risks.

Figure 4.6. Example of a model designed through the AROM's interactive modeling editor (IME)

A territorial unit (see class Territorial_Unit) can be of two kinds in our example: department or town. The Department class inherits from the Territorial_Unit class but its geometrical attribute contour is redefined by the addition of an AML definition facet that enables us to calculate the geometry of the department by merging the geometry of the outlines of the towns creating it (see the textual format of the base in Table 4.1).

It is interesting to also note that in AROM-ST we can represent n-number of associations between classes (see association result in Figure 4.6).

The territorial units can be affected by different types of natural risk events (class Event in Figure 4.6). The affects association is specialized by the touches association and the addition of a new variable (see the damages variable in Table 4.1). The roles of the association are also specialized, the tu role sees its field restrained to towns, and the ev role sees its field restrained to floods.

Table 4.1. Textual format of the knowledge base presented in Figure 4.6

The association contains describes the composition relation that exists between a department and various towns. The multiplicity constraints are seen on the roles (sup role with a multiple of 0 or 1, 0 taking into account the case of a higher level territorial unit, which is not the part of other territorial units), and the inf role, which is a multiplicity of 1 to n).

Some modeling details are visible only at the textual format of the knowledge base (see Table 4.1).

In Table 4.1, we can see that the Territorial_Unit class is described by an area variable, which itself is described by a documentation facet and a unit facet representing the measure unit of this area. We can also note the use of integrity constraints on associations to avoid any data input or update error. A constraint on the area value of the territorial units (see the contains association in Table 4.1) allows us to specify that the constituent territorial units cannot have a larger area than the area of their respective constituent units.

We can also note the use of spatiotemporal constraints. A simple spatial constraint enables us to specify the fact that a flood's trajectory that touches a town must intersect the outline of the town. A more complex spatiotemporal constraint allows us to specify that, for a storm to be considered as the cause of a flood, the beginning of the storm must be before the beginning of the flood, and that the storm must have affected the hydrographic basin of the river in which the flood happens. This type of complex spatiotemporal constraint cannot be expressed in “classical” conceptual modeling approaches; we have to express here constraints of mist (spatial and temporal) natures on elements linked by two associations, one ternary and one binary.

4.4. From AROM-OWL to ONTOAST

In more recent work [MIR 07b], we have studied opening AROM to the semantic Web, by trying to bring it closer to OWL-DL [MCG 04], the standard ontological representation language. This comparative study was carried out along three axes: (1) representation, (2) typing, and (3) inferences. After coming to the conclusion that there was an imbalance between AROM-ST and OWL-DL on a description power level, we suggested an extension to its metamodel to close this gap [MIR 07b]. The new metamodel, called AROM-ONTO, integrates new representation structures that bring AROM much closer to OWL-DL. Finally, we positioned AROM in terms of typing and inference versus OWL-DL, by noticing and claiming a certain amount of complementarity.

Thus, with AROM-ONTO, from now on, we can access inferences offered in description logics (which can be carried out by using reasoners such as PELLET³ and RACERPRO⁴) but it is also possible to enrich the owl-dl ontologies through AROM-ST reasonings that complement those offers by OWL-compatible reasoners. To benefit inference capacities offered by AROM-ONTO, the ontological knowledge must be translated into AROM's own formalism. To this end, we have built a translator based on XSLT rules that allow us to import an OWL-DL ontology into AROM-ONTO.

AROM-ONTO represents the base from which we have built a spatial and temporal reasoner able to use OWL-DL ontology, called ONTOAST (after ONTOlogy in AROM-ST) and which is a bridge between the GIS field and the semantic Web. ONTOAST is an AROM-ST extension that covers the spatial and temporal operators managed by AROM-ST as well as the core modifications caused by AROM-ONTO to ensure OWL-DL compatibility. While AROM-ONTO guarantees general compatibility between AROM and OWL-DL's ontological languages, ONTOAST offers the expansion of the OWL AROM-ONTO translators so that they take into account the spatial and temporal descriptions made using GeoRSS-simple and OWL-time ontologies. Thus, the spatial and temporal reasoning offered by ONTOAST can be used to exploit spatial and temporal descriptions defined by OWL-DL ontologies, as long as there is a translation toward and from ONTOAST.

ONTOAST integrates a predefined spatial model that manages a set of qualitative spatial links. These are qualified as topological, distance, or direction links and their respective semantics are defined in [MIR 07a]. By relying on the use of AROM's AML [PAG 01] and on a set of qualitative spatial link deduction rules from other existing qualitative links and digital data [MIR 07a], ONTOAST also manages all Allen's temporal links [ALL 83] (before, after, starts/started-by, finishes/finished-by, during/contains, equals, meets/met-by, overlaps/overlapped-by). The goal is to answer spatial and temporal queries on “the fly” by combining qualitative reasoning and quantitative reasoning without having precalculated and stored in the ontological base all the possible spatial links between the entities.

4.5. Architecture

Knowledge representation in AROM is implemented through an environment created in the JAVA language. In its current version (AROM 2) [PAG 01], AROM is the implementation of a knowledge representation model: it covers representation in a shape of digital objects of AROM's model entities. AROM 2's API is the JAVA programming interface of this system. Above the core, the AROM 2 platform offers a certain number of libraries for knowledge base use, each of which is built on the AROM 2 API and offers its own API. Among the different modules offers, we can mention AROM CLASSIF, an API for object and propagation tuple classification [CHA 03], AROM QUERY for query definition in an AROM base, and the XAROM API for AROM base interfacing with XML format (Figure 4.7).

Figure 4.7. AROM platform architecture

The AROM system itself is designed in a modular manner, each module being in charge of a specific function in the system. The memory management module ensures memory access to the AROM instances, the type module defines all the recognized types in an AROM base and the possible operations that can be carried out on these types [CAP 98], and the algebraic interpretation module ensures AML equation interpretation in AROM. Each module communicates with the other modules only through a clearly separated internal API. It is thus possible to modify the AROM platform by changing the implementation of a module for another implementation. This possibility has, for example, been used in the GENOSTAR⁵ [DUR 03] system that is dedicated to the exploratory analysis of genomic sequences. Since GENOSTAR uses the AROM system for knowledge bases that involve a great number of instances, a specific memory management module allows us to optimize the memory use of the JAVA virtual machine. A persistence mechanism ensures the upload and download of the instances from the disc to the memory. In the same way, a specific type of module integrating genomic specific types is used in this application.

The AROM 2 system configuration happens transparently (through resource files) for the AROM applications. Indeed, AROM 2's API is made of only JAVA interfaces and “fabrication” classes; the AROM's application code never refers to the system's implementation classes. It is thus possible to carry out without modification the same code with different implementations of the AROM system. This new configurable and modular architecture, as well as these new library, is the difference between AROM 2 and the previous version, the semantics themselves have not changed.

4.6. Community

The AROM-ST user community is mostly linked to the need to model data in fields such as bioinformatics and geomatics. AROM uses for bioinformatics mostly take advantage of AROM's classifying abilities. The use of AROM-ST in geomatics, for natural risk modeling or complex system modeling, take advantage of all AROM-ST's innovative characteristics: classification, spatiotemporal types, and constraints expressed in AML.

To illustrate our argument, we would like to take for example the use of AROM-ST for an application called SIHREN dedicated to raising awareness of natural risks and preventing them. The idea underpinning it is to make the modeling steps easier for applications dedicated to natural risks, by providing designers with a generic model devoted to natural risks. This model allows non-specialists (urban area risk planners, hydrologists, etc.) to model their data related to natural risks in a relatively easy manner, by specializing a high-level “natural risk” model (see Figure 4.8).

Figure 4.8. Data model for avalanche risks as specialization of the generic model devoted to natural risks

This high-level model is based on AROM-ST's spatiotemporal modeling abilities. Once the modeling of the data is finished, the designers have the possibility of visualizing their data in a spatiotemporal interface by importing their data model into the GENGHIS application [MOI 08].

4.7. Conclusions and prospects

In this chapter, we have presented AROM-ST, an OOKRS. AROM combines oriented modeling simplicity with the expressive richness of an AML to offer a modeling and spatiotemporal data management solution that is completely declarative, relatively easy to use, and very expressive.

In fact, AROM-ST has proved itself not only as an independent spatiotemporal data modeling tool, but also as a spatiotemporal data management and modeling tool integrated into the spatiotemporal application generation platform GENGHIS (see Chapter 5).

Future developments for AROM-ST will focus on the problematics linked to the semantic Web. The idea behind this is to bring AROM-ST closer to OWL and to use AROM-ST's spatiotemporal reasoning abilities to fill the gaps left by OWL in the spatiotemporal reasoning field.

4.8. Bibliography

[ALL 83] ALLEN J. F., “Maintaining knowledge about temporal intervals”, Communication of the ACM, vol. 26, pp. 832–843, 1983.

[BAA 03] BAADER F., CALVANESE D., MCGUINNESS D., NARDI D., PATEL-SCHNEIDER P. (eds), The Description Logic Handbook: Theory, Implementation and Applications, Cambridge University Press, Cambridge, United Kingdom, 2003.

[BÉD 04] BÉDARD Y., LARRIVÉE S., PROULX M.-J., NADEAU M., “Modeling geospatial databases with plug-ins for visual languages: a pragmatic approach and the impacts of 16 years of research and experimentations on perceptory”, COMOGIS Workshops ER2004, LNCS 3289, Shangai, China, pp. 17–30, 2004.

[BIS 04] BISSLER T., Conception et développement d'une plateforme générique pour les Systèmes d'Information Spatio-Temporelle pour la gestion des Risques Naturels, mémoire d'ingénieur, CNAM Grenoble, 2004.

[CAP 98] CAPPONI C., “Un système de types pour la représentation des connaissances par objets”, Revue d'Intelligence Artificielle, vol. 12, no. 3, pp. 309–344, 1998.

[CHA 03] CHABALIER J., FICHANT G., CAPPONI C., “La classification récursive en AROM: Application à l'identification de systèmes biologiques”, RSTI, L'Objet, vol. 9, nos. 1'2, pp. 167–181, 2003.

[DUC 98] DUCOURNAU R., EUZENAT J., MASINI G., NAPOLI A., (eds), Langages et modèles à objets – Etat des recherches et perspectives, Collection Didactique D-019, INRIA, Le Chesnay, 1998.

[DUR 03] DURAND P., MÉDIGUE C., MORGAT A., VANDENBROUCK Y., VIARI A., RECHENMANN F., “Integration of data and methods for genome analysis”, Current Opinion in Drug Discovery and Development, vol. 6, no. 3, pp. 346–352, 2003.

[MCG 04] MCGUINNESS D.L., VAN HARMELEN F., OWL Web Ontology Language – Overview, W3C Recommendation, World Wide Web Consortium, 2004, http://www.w3.org/TR/owl-features/.

[MIN 75] MINSKY M., “A framework for representing knowledge”, Reading in Knowledge Representation, McGraw-Hill, New York, pp. 245–262, 1975.

[MIR 07a] MIRON A., CAPPONI C., GENSEL J., VILLANOVA-OLIVER M., ZIéBELIN D., GENOUD P., “Rapprocher AROM de OWL”, Langages et Modèles à Objets, Toulouse, France, 2007.

[MIR 07b] MIRON A., GENSEL J., VILLANOVA-OLIVER M., MARTIN H., “Towards the geo-spatial querying of the semantic web with ONTOAST”, 7th International Symposium on Web and Wireless GIS (W2GIS 2007), Cardiff, UK, 2007.

[MOI 07] MOISUC B., CAPPONI C., GENOUD P., GENSEL J., ZIÉBELIN D., “Modélisation algébrique et représentation de connaissances par objets en AROM”, Langages et Modèles à Objets, Toulouse, France, 2007.

[MOI 08] MOISUC B., GENSEL J., MARTIN H., “Conception de systèmes d'information spatio-temporelle adaptatifs avec ASTIS”, Numéro spécial de la Revue Nouvelle des Technologies de l'Information, Cépaduès, RNTI E-13, pp. 63–78, 2008.

[MOK 04] MOKRANE A., LAOUAMRI O., DRAY G., PONCELET P., “Modélisation spatio-temporelle des connaissances d'un système d'information géographique”, Proceedings of SETIT'04 International Conference, Sousse, Tunisia, 2004.

[NAP 04] NAPOLI A., CARRÉ B., DUCOURNAU R., EUZENAT J., RECHENMANN F., “Objets et représentation, un couple en devenir”, RSTI L'objet, vol. 10, no. 4, pp. 61–81, 2004.

[OGC 08] Open Geospatial Consortium, OGC Reference Model, 2008, http://www.opengeospatial.org/standards/.

[PAG 00] PAGE M., GENSEL J., CAPPONI C., BRULEY C., GENOUD P., ZIÉBELIN D., “Representation de connaissances au moyen de classes et d'associations: le système AROM”, Actes de la conférence LMO 2000, Montréal, Canada, Hermès-Lavoisier, pp. 91–106, January 2000.

[PAG 01] PAGE M., GENSEL J., CAPPONI C., BRULEY C., GENOUD P., ZIÉBELIN D., BARDOU D., DUPIERRIS V., “Anew approach in object-based knowledge representation: the AROM system”, Engineering of Intelligent Systems, LNCS 2070, Springer, Berlin, pp. 113–118, 2001.

[PAR 99] PARENT C., SPACCAPIETRA S., ZIMÁNYI E., “Spatio-temporal conceptual models: data structures + space + time”, Proceedings of the 7th ACM Symposium on Advances in GIS, Kansas City, Kansas, USA, 1999.

[SPA 07] SPACCAPIETRA S., PARENT C., ZIMÁNYI E., “Spatio-temporal and multi-representation modeling: a contribution to active conceptual modeling”, Active Conceptual Modeling for Learning, LNCS 4512, Springer, pp. 194–205, 2007.

[UML 03] Object Management Group, UML 2.0 OCL Specification, Object Constraint Language, 2003, http://www.omg.org/.