Olivier Bedel

Sébastien Ferré

Olivier Ridoux

Erwan Quesseveur

Exploring a Geographical Dataset with GEOLIS

Geographical data are mainly structured in layers of information. However, this model of organisation is not convenient for navigation inside a dataset, and so limits geographical data exploration to querying. We think information retrieval could be made easier in GIS by the introduction of a navigation based on geographical object properties. For this purpose, we propose a prototype, GEOLIS 1 , which tightly combines querying and navigation in the search process of geographical data. GEOLIS relies on Logical Information Systems (LIS), which are based on Formal Concept Analysis (FCA) and logics. In this paper, we detail data organisation and navigation process in GEOLIS. We also present the results of an experimentation led on a real dataset.

Introduction

For several years the amount of geographical data produced around the world keeps increasing. In the same time, a growing number of heterogenous geographical datasets became available online for watching or downloading through geo-spatial web portals . These portals enable to find specific layers of geographic information from a region of interest and a metadata description. Once you have got the desired layer, Geographical Information Systems (GIS) provide tools to explore and analyse it.

Geographical information is traditionnaly organised in two kinds of layers: raster layers and vector layers. Raster layers correspond to geo-localized images (e.g. satellite images, aerial photographies, digital elevation model) in which each pixel qualifies a portion of space with a unique value (e.g. infra-red radiation, elevation). Vector layers gather geographic objects, called features, which are qualified by a set a thematic attributes and spatially represented 1 This work is funded by a scholarship from Région Bretagne with geometric shapes (points, lines, and polygons) [START_REF] Laurini | Fundamentals of Spatial Information Systems[END_REF]. In the following, we will exclusively focus on information retrieval in vector layers, which by nature lend themselves to symbolic data analysis. Conversely, raster layers are traditionnaly processed using numeric methods which are not adressed here.

While GIS have recently known improvements concerning data storage (spatial databases, geo-spatial servers,...) and data display (webmapping services, globe visualization,...), the principles of information retrieval inside a geographic dataset keep unchanged. In fact, information retrieval in GIS is either querying like in database or browsing a set of layers.

Querying is powerful and expressive, but difficult to use when the goal is not very clear, and out of reach of many users. In GIS, thematic attributes are stored in tables attached to the layers. SQL-like languages are used to query these attributes, and spatial predicates enable to compute spatial relations between reference objects and searched objects, e.g. distance or inclusion. If thematic and spatial queries were used to be built using separated tools, the arrival of spatial function for SQL tends to unify querying interfaces.

Navigation in GIS is rigid and limited. As data are partitioned in predefined layers, users may check or uncheck layers to be explored and then graphically select on the map features or regions of interest. But then, no more navigation based on thematic attributes is possible. If browsing the table of attributes is possible, it does not help anyone in rapidly retrieving a specific information. All the more if the only available actions on the table consist in changing the columns order or sorting rows according to the values of a particular field.

To our point of view, querying, and more generally information retrieval in GIS could be made easier with the introduction of a real navigation among the attributes of geographical features. Our proposal is to assist the user with an incremental search process tightly combining querying and navigation. For this purpose, we have developped a prototype, called GEOLIS, which uses a Logical Information System (LIS) [START_REF] Ferré | An introduction to logical information systems[END_REF] that we have adapted to handle geographical data. LIS provide guidance in the search process by tightly combining querying and navigation in an incremental way. For data organisation and retrieval, LIS rely on Formal Concepts Analysis (FCA) and the expressiveness of logics.

FCA [START_REF] Ganter | Formal Concept Analysis: Mathematical Foundations[END_REF] organises data in a concept lattice. This lattice is a navigation structure that is automatically derived and adapts to changes in data. Concepts are subsets of objects sharing same properties. FCA properties are limited to boolean attributes whereas many documents, and especially geographical features, are described by valued attibutes. This is why in LIS, FCA has been generalized to Logical Concept Analysis (LCA), which allows to describe objects and concepts with logical formulas. This enables to deal with several domains of values in feature descriptions (e.g. integers, strings, coordinates, shapes) and to use patterns in queries (e.g. intervals, regular expressions, areas).

The sequel of the paper is structured as follows. Section 2 presents other uses of logics and FCA to handle geographical data. Section 3 details the organisation of geographical data used in GEOLIS. Section 4 describes the information retrieval process and briefly introduces GEOLIS architecture. Last, Section 5 presents the results of our prototype in the exploration of a real dataset dealing with the spatial distribution of rodents in Sahelo-Sudanian Africa.

FCA and Logics applied to GIS

FCA has not been yet really investigated for the management of geographical information. However [START_REF] Priss | Information Access through Conceptual Structures and GIS[END_REF] show the opportunity of combining conceptual structures and GIS for information access. Even if the final aim of this work is not to handle geographic space but abstract space such as the World Wide Web, it illustrates the representation of geographical information in a conceptual environnement. Another work, even if not directly connected to FCA, [START_REF] Ber | Design and comparison of lattices of topological relations based on galois lattice theory[END_REF] illustrates the use of Galois lattices to represent and reason about topological relations on raster images.

Conversely, logical formalisms have been widely used to formalize spatial relations and especially topological relations [START_REF] Asher | Toward a geometry for common sense: A semantics and a complete axiomatization for mereotopology[END_REF][START_REF] Cohn | Qualitative spatial representation and reasoning techniques[END_REF]. This also includes modal approaches to define the notion of proximity. However these approach are rather qualitative and often not directly useable with real world data. Description logics provide a framework more devoted to information retrieval, and have led to some encouraging attempts to describe the geographical domain. For instance, the VISCO system [START_REF] Wessel | Visual spatial query languages: A semantics using description logic[END_REF] relies on description logics to query a spatial database in a visual way. But if these systems integrate comparison, querying, and even query completion capabilities, conversely to LIS, they do not offer a relevant navigation structure derived from the data. GEOLIS, and more generally LIS, combine a quantitative approach as data are described by expressive logics on concrete domains, and a qualitative approach, derived from the former, through conceptual structures and logical reasoning.

LCA to Organise Geographical Data

As mentioned previously (see Section 1), the layer structure is rigid. It imposes the same description schema for all the features of a layer. Moreover, as layers are considered as atomic objects in almost all GIS operations, working on a subset of geographical features often requires preprocessing and the use of temporary layers. Furthermore, using rows of an attribute table to store the description of geographical features is not convenient for navigation. A model with a thiner granularity would improve flexibility in geographical data handling. This is why with LCA, we propose to center the data model on the objects that are to be retrieved, i.e. the geographical features.

In the GEOLIS data model, each geographical feature is represented by an object and is described by a logical formula. This logical formula corresponds to the conjunction of logical properties derived from the attributes of the feature. A logical property is a valued property composed of the name of an attribute and of a corresponding value. For instance, here is a possible formula for describing an object o representing the French city Rennes: In this example, the conjunction operator AND combines logical properties defined on string values (name and description), on integer values (population), and on geometric representations (geometry). In GEOLIS, such a description is automatically extracted from layers encoded in common geographical data formats. For each feature of a layer, all attribute values are translated into logical properties. So is the geometry of the feature, using a standardized string representation, which enable to reason both on geographic shape and localisation. This way, the same language is used to query about spatial location and thematic attributes. This is a significant point to make information retrieval easier in GIS.

In fact, GEOLIS uses specialized logics (e.g. string logic, integer logic or spatial logic) to define the concrete domain associated with each attribute. Queries take the form of logical formulas, which may include logical properties whose values have been replaced by specific patterns. In addition to conjunction operator, queries may also in-clude disjunction and negation operators OR and NOT. For instance, just consider the following query q: q = population:>=100 000 AND geometry:inside POLYGON(300 000 6 000 000, 400 000 6 000 000,400 000 7 000 000, 300 000 7 000 000, 300 000 6 000 000) Spatial patterns are graphically drawn on a map, and then transcripted into a logical formula. In this example, the set of answers of q include the previously defined object o because the integer value 206 000 is more specific than the pattern >=100 000, and the spatial value POINT(...) is also included in the spatial pattern POLYGON(...).

Specialized logics define a partial ordering ( ) between values and patterns of a concrete domain, e.g. 206 000 >=100 000. Logical properties may also be ordered themselves according to a taxonomy specific to the dataset explored. For instance, the rodent dataset which is fully introduced in Section 5, gives information about biometry, location, phylogeny and date of capture of rodents that have been trapped and observed in the Sahelo-Sudanian stripe. In this dataset (see Figure 1), we have the following relations: sex biometry and age biometry.

GEOLIS to Explore Geographical Data

In GEOLIS, LCA enables navigation through all properties of the geographical features. In LCA, a concept groups together objects sharing a common set of properties, the intent, and can be seen as a query. An edge of the concept lattice is a navigation link from a concept to another, i.e. from a query to another query. In other words, an edge corresponds to a property which is a query increment. In fact, querying consists in being on a particular concept, and navigating consists in reaching a neighbour concept by following an edge of the lattice. However, in LIS, the complete concept lattice is never built. At each step in the search process, the LIS kernel computes only the increments relevant to the current concept, i.e. to the current query. By analogy with the working directory of file systems, we call the current query the working query (wq). Formally, if ext(wq) denotes the features satisfaying wq, GEOLIS will provide all query increments p belonging to: max {x|∅ ⊂ ext(wq AND x) ⊂ ext(wq)}. Following query increments reduces the number of answers, but never leads to dead-ends. Furthermore, only the most general refining increments are provided. As a large amount of query increments may be confusing for navigation, GEOLIS organises them in a navigation tree, according to the taxonomy on properties and to the partial order between values and patterns of properties. The tree is progressively built during the navigation. At the beginning, only the first level is computed.

GEOLIS Interface

The GEOLIS interface, which is shown in Figure 1, is composed of three main parts: the navigation tree placed on the left, the map area filling the center and the right, and the working query box at the bottom.

• The working query box displays the current query in the navigation. It indicates the query describing objects rendered in the map. The query box is editable, so that it is possible to enter manually a new query or to modify the current one.

• • The navigation tree is a visual representation of the partially ordered set of query increments. Query increments are properties shared by at least one feature of wq. Each node of the tree represents a query increment which can be used to change wq (see Figure 1). When a node is expanded, this entails the computation of query increments that refine the increment of this node. Then, the new increments appear as its children in the tree. The root of the tree is ALL, i.e., the most general formula. Nodes under the root correspond to general properties of the taxonomy built over the dataset. Then nodes represent pattern properties or value properties which are the leaves of the tree. Each node of the tree is rendered with an icon, a label, and two numbers.

The label is the formula representing the increment. The style of the label is also informative. Underlined orange labels correspond to formulas shared by all the rodents of wq, whereas blue labels indicate properties that discriminate them. The two numbers indicate a proportion: the count of rodents in wq that the increment leads to, i.e. the support, out of the count total of rodents sharing the formula. Two actions are possible in the tree: (1) collapsing or expanding a node by acting on the icon, (2) updating wq by selecting a label.

Figure 1. The GEOLIS interface. Selected rodents appear as white points on the map. The white rectangle on the map represents the region that has just been selected as a graphical query increment.

During the navigation process, the interface is always maintained coherent. Each action on the working query box, the navigation tree, or the map area entails the update of all the components. Figure 1 illustrates the result of this interaction during the exploration of the rodents dataset. The query focuses on the rodents of families "Muridae" and "Sciuridae", trapped since 2000. So, by editing the working query box and using the OR operator, we restrict navigation to families of interest. In the same way, we limit investigation to rodents captured since 2000, using the pattern annee capture:>=2000. Then, in the navigation tree, we select the increment Age:''Juv'' to keep only young rodents. Notice that we could have the same result by manually editing the working query box anew. Figure 1 shows the state of the interface at this stage of navigation. The map and the navigation tree have been updated, w.r.t. the current query. We have the possibility to reduce the number of rodents by selecting a weight range in the tree, but we choose to focus on the set of rodents in southern Malia. With the logical zoom tool, we draw on the map a rectangular shape enclosing the desired region (see Figure 1). The logical zoom is not a graphical zoom. It will not modify the extents of the map, but it will entail the update of the current query, and consequently of the navigation tree and of the features drawn on the map. The rectangular shape will be translated into a formula based on the geometry property, which will be automatically added to the current query: wq =(Famille:"Muridae" OR Famille:"Sciuridae") AND annee capture:>=2000 AND Age:"Juv" AND geometry:inside POLYGON(-14.056 10.0585, 0.540 10.0585, 0.540 13.393, -14.056 13.393, -14.056 10.0585)

The navigation tree will be reduced, and show only properties and increments concerning rodents of the selected area. Last rodents in the north of the Burkina Faso border will disappear from the map.

GEOLIS Implementation

The GEOLIS prototype results from the coupling of several technologies from LISFS [START_REF] Padioleau | A logic file system[END_REF], web mapping and web domains.

LISFS is a generic implementation of LIS, and is at the same time a genuine Linux file system [START_REF] Padioleau | A logic file system[END_REF]. In LISFS, files and file parts (lines) are objects, paths are queries, directories are navigation places, and subdirectories are the automatically computed query increments. Two kinds of plugins can be used in LISFS: logics and transducers. Logics define the kind of formulas that can be used in object description, and queries. Transducers allow to partially automate the description of objects, depending on the file format. The Geo-graphical Markup Language (GML) proposed by the Open-Geospatial Consortium is the data format we chose to use in GEOLIS. For our purpose, it has the advantages to gather all information in one file whose XML based structure may be rearranged w.r.t. to GML specifications. The GML transducer automatically extracts the spatial description and the thematic properties for each geographical feature o stored in the GML file, and produces a description formula d(o) (as illustrated in Section 3).

LISFS constitutes the kernel of GEOLIS, where the geographical data to be explored is stored. The GEOLIS graphical interface is a web interface. The navigation tree and the working query box have been designed using the server side language PHP. The map area is built with the widely used map generator UMN MapServer, which renders geographical features stored in GML files. Interaction between GEOLIS components is detailled in [START_REF] Bedel | GEOLIS: A logical information system for geographical data[END_REF].

Experimentations

GEOLIS have been tested out with a real dataset qualifying the distribution of rodents in the Sahelo-Sudanian stripe. This dataset results from the merging of several databases provided and maintained by the French Institute for Research and Development (IRD2 ) since 1980 [START_REF] Granjon | Inventaire et caractérisation des espèces de rongeurs sahélo-soudaniens[END_REF]. It aims at determining possible causes affecting the distribution of rodents, but as data comes from local observations, this base is an imperfect sampling of Sahelo-Sudanian stripe. It gathers more than 20 000 features, each one being described with properties about biometry, philogeny, period of capture and localisation.

First experiments highlighted several occurences of anomalous entries resulting from errors in data collecting and merging. In the navigation tree, all values of a properties are listed with their count. This way, we can directly determine the most likely domain of a property ({''F'', ''M''} for Sexe:), and identify synonymous (''m''), uncertain values (''M?'') or mistakes (''49''), in order to correct them.

The unperfectness of the sampling has also been observed during the navigation. For instance, just by looking at the count of rodents under each value of the node pays (i.e. country) in the navigation tree, we noticed that half of information in the base comes from Senegal, while it represents only a small part of the studied area on the map. Having knowledge about data origin could enable to balance future results concerning rodent distribution. So we decided, as a first step, to use GEOLIS to qualify underlying strategies in the sampling of the database. For instance, within the navigation tree, we can restrict navigation to rodents trapped alive, and visualize, at the same time, properties annee capture (i.e. year of capture) and habitat. In only a few operations, we noticed that for rodents captured alive, the diversity of trapping places tightly depends on the period of capture. For instance, 85% of rodents found in savanna were trapped in year 2000, which also corresponds to more than 60% of rodents trapped that year. Less diversity in trapping places could be explained by trapping sessions led to confirm hypotheses implying location criteria.

Conclusion

With the expressiveness of specialized logics and LIS exploration paradigm, GEOLIS enables a tight combination of querying and navigation applied both on thematic and spatial properties of geographical data. Not only information retrieval is improved, but navigation tools also enable to discover underlying properties of the explored dataset. Furthermore, experiments have been successfully conducted with real data expressed in a common GIS data format. In the future, we plan to integrate spatial relations in GEOLIS to improve expressiveness and querying capabilities.

  d(o) = name:''Rennes'' AND population:206 000 AND geometry:POINT(351 869.83 6 789 643.91) AND description:''administrative center of the French region Brittany''

  The map area is a composed component. A main map including fixed background layers (e.g. administrative boundaries, hydrography or satellite image) indicates by white points the location of geographical features satisfying the current query. A legend details symbology of the main map and enables to specify which layers are visible. A keymap locates the boundaries of the main map on a world map. Last, standard map tools are also available: pan, zoom in/out and to full extent. The map area component comes almost unchanged from an existing interface. It has been enhanced with a logical zoom tool, which enables to select rodents directly on the map by drawing a rectangle, i.e. a bounding box, enclosing them. The logical zoom produces graphic query increments that are expressed in queries with the syntax geometry:inside POLYGON(...).

The authors would like to thank M. Laurent Granjon and M. Jean Marc Duplantier from IRD (CBGP UR 22 Montpellier) for their active contribution in the building of the rodents database.


Sébastien Ferré
email: ferre@irisa.fr

Olivier Ridoux
email: ridoux@irisa.fr

Logical Information Systems: from Taxonomies to Logics

Dynamic taxonomies have been proposed as a solution for combining querying and navigation, offering both expressivity and interactivity. Navigation is based on the filtering of a multidimensional taxonomy w.r.t. query answers, which helps users to focus their search. We show that properties that are commonly used only in queries can be integrated in taxonomies, and hence in navigation, by the use of so-called logics. Hand-designed taxonomies and concrete domains (e.g., dates, strings) can be combined so as to form complex taxonomies. For instance, valued attributes can be handled, and different roles between documents and locations can be distinguished. Logical Information Systems (LIS) are characterized by the combination of querying and navigation, and the systematic use of logics.

Introduction

Hierarchies are the most common way to organize and retrieve information. We find them in file systems, but also for emails or bookmarks. These hierarchies mimick physical storage structures (e.g., libraries), and hence entail the same problems: documents can be put in only one place, and there must be a strict order between classification criteria. A typical example is the classification of photos. If photos are classified by date, the whole hierarchy has to be browsed in order to collect all photos with some person or of some type (e.g., landscape, animal). Conversely, if photos are classified by their type, it becomes hard to get all the photos of a given period of time. In fact, no single hierarchy is satisfying because different users have different needs, and even a single user has different needs at different times.

Databases allow for the retrieval of documents according to expressive combinations of properties. For instance, it is possible to quickly retrieve all photos of, say, "any of my children in France or Germany, except those before 2000". However, the benefits of navigation are lost as users are not guided in their search, and must know both the query language and the application vocabulary. User queries may lead to an overflow of answers, or no answer at all.

The need to combine querying and navigation has been long recognized, but most proposals are limited.

• For instance, Semantic File System [START_REF] Gifford | Semantic file systems[END_REF] extends the hierarchical model with virtual directories, which correspond to queries. However, no navigation can occur after querying, and queries apply only to intrinsic attributes, not to hierarchy names.

The problem with many approaches is that they use hierarchies as monodimensional taxonomies, which means documents can be decribed by only one element of the taxonomy.

• On the contrary, Dynamic Taxonomies (DT) [START_REF] Sacco | Dynamic taxonomies: A model for large information bases[END_REF][START_REF] Sacco | Dynamic taxonomy process for browsing and retrieving information in large heterogeneous data bases[END_REF][START_REF] Hearst | Finding the flow in web site search[END_REF] consider multidimensional taxonomies, allowing documents to be associated with multiple elements. For instance, a photo can be given a date, a location, and all persons visible on it. Querying is simply selecting documents having some set of taxonomy elements. Navigation is made possible because only the relevant parts of the taxonomy are shown as a summary of the selected documents. Hence querying and navigation can be combined in a same search, in any order.

• Another approach, based on Formal Concept Analysis (FCA) [START_REF] Ganter | Formal Concept Analysis -Mathematical Foundations[END_REF], also achieves a tight combination of querying and navigation by automatically deriving the navigation structure from the raw description of documents by sets of attributes [START_REF] Godin | Experimental comparison of navigation in a Galois lattice with conventional information retrieval methods[END_REF]. The information retrieval process is similar to DTs, except attributes are not organized in a taxonomy.

In 1999, we started work on Logical Information Systems (LIS) [START_REF] Ferré | A file system based on concept analysis[END_REF][START_REF] Ferré | An introduction to logical information systems[END_REF], aiming at an even tighter integration of querying and navigation. Indeed, in the FCA-based approach, document properties can only be boolean attributes, whereas querying often deals with values and patterns (e.g., intervals, substrings). In dynamic taxonomies such properties can be used in document descriptions and queries, but not in taxonomies, which are the basis for navigation. So, if photo dates are represented by a valued attribute, it is not possible to navigate with time periods. Conversely, if dates and time periods are represented in the taxonomy, arbitrary date intervals cannot be used in queries. Of course, both representations could be used together, duplicating the date as a valued attribute and a taxonomy element. However, this could hardly be considered as a tight combination; and it would be useful to insert new date intervals from user queries into the taxonomy, for future navigation.

This implies that some of the subsumption relations in the taxonomy are better computed, rather than designed by hand. Regarding these relations as entailments suggests to use logics for defining some part of taxonomies. This use of logics is the key contribution of our logical information systems. Logics support both querying and navigation. For instance, the keywords used in queries will progressively enrich a taxonomy over string-valued attributes (e.g., title, comment). Given a hand-designed taxonomy of locations, various roles between objects and locations (e.g., "in", "from") can be distinguished. This can be done without duplication, so that every change in the taxonomy of locations has to be done only once, because computed and hand-designed taxonomies can be composed into complex taxonomies.

Section 2 first defines what is a logic, and how it abstracts over taxonomies. We also present how logics can be composed by logic functors so as to form complex taxonomies. Section 3 defines an information base as a logical context, and some related operations. Then we describe querying and navigation in LIS, and how they relate to dynamic taxonomies. Section 4 gives practical aspects of LIS.

From Taxonomies to Logics

In the context of information retrieval, a taxonomy can be defined as a partially ordered set of elements (E, ≤). These elements are used in both object descriptions and queries, and the ordering ≤ states subsumption relations between elements. An example is the taxonomy of locations, where elements are places, regions, countries, continents, etc. Reading a place as "somewhere in this place", the subsumption between places corresponds to spatial inclusion. For instance, Paris ≤ France, but not Paris ≤ Spain; and both France ≤ Europe and Spain ≤ Europe.

A taxonomy is generally assumed finite, and with an ordering that is extensionally defined, i.e., designed by hand. However, it is easy to conceive partial orderings that are both infinite and intentionally defined.

• The set of all strings, ordered by the "is contained in" relation: "The Jungle Book" ≤ "Jungle".

• The set of intervals on integers, ordered by inclusion: 2007 ≤ 2000..2010 ≤ 2000...

• The set of intervals on dates, ordered by inclusion:

3 sep 2007 ≤ sep 2007 ≤ sep 2007..dec 2007.
In these examples the ordering can be given a mathematical definition, and implemented as a function that takes any 2 elements x and y and returns whether x ≤ y holds. With these intensional taxonomies, it is possible to describe a photo with a free comment (string), a size (integer), and a date. Then it is possible to retrieve photos where some word occurs in the comment, that were taken in some period of time, or whose size is in some interval. For navigation, only a finite subset of the elements are made visible (see Section 3), but the insertion of a new element is automatic because its relation to other elements can be computed. These intentional taxonomies can be seen as logics because (1) the elements are properties over objects, and so can be seen as unary predicates, and (2) the ordering is reflexive and transitive, and so can be seen as an entailment. More precisely, this entailment is called subsumption (noted ) because it does not apply to statements, but to properties over objects, as in description logics [START_REF] Donini | The complexity of concept languages[END_REF].

Definition 1 A logic is a partially ordered set of formulas (L, ), where formulas are used as descriptors on objects and patterns in queries, and the ordering is the subsumption relation between formulas, and can be intentionally defined.

Each logic is implemented as a module that defines an internal representation, a parser and a printer for user interaction, and a subsumption checker. This definition is compatible with hand-designed taxonomies. The taxonomy of locations is the logic whose formulas are location names, and the subsumption relation is the transitive closure of the taxonomy seen as a graph. To summarize, consider that we have the following logics:

• Location: taxonomy of locations, as a logic,

• String: logic of strings and substrings,

• Integer: logic of integers and intervals,

• Date: logic of dates and intervals of dates.

These logics generally correspond to monodimensional taxonomies, while this is not required. For instance, a photo is usually given one location, one date, one size, and one comment. However, we definetely need to combine these logics to form a multidimensional logic, where each object can be given at the same time a location, a date, a size, and possibly several comments. To this purpose we introduced logic functors [START_REF] Ferré | A framework for developing embeddable customized logics[END_REF], i.e., functions from logics to logics. They are implemented as parameterized modules, i.e., functions from modules to modules. One of these logic functors is Sum, and produces the union of 2 logics. Its effect on taxonomies is to put them side by side. Then a common root is added by applying another logic functor Top, whose only effect is to add a top element that subsumes all elements. The logic allowing to describe photos with 4 kinds of properties, as mentioned above, is defined as L1 = Top(Sum(Location, Sum(String,Sum(Integer,Date)))).

In some applications, locations may be used under different roles. For instance we may want to distinguish between where some person lives in, and where she comes from. The composite logic Top(Sum(Location,Location)) is unsatisfying because (1) it duplicates the taxonomy of locations, and (2) elements from the 2 copies cannot be distinguished. Instead we introduce a taxonomy of roles as a logic Role, which contains at least the roles in, from, and a top role any meaning "any role". Then we combine this logic and Location with the logic functor Prod: L2 = Prod(Role,Location).

The elements of L2 are pairs (role, location), and 2 pairs are ordered if the first and second parts are respectively ordered. For instance, a person living in Paris and coming from Spain is described by in Paris and from Spain (to be read "from somewhere in Spain"). The following subsumption relations are verified:

• in Spain in Europe any Europe,

• in Spain any Spain any Europe.

We emphasize the fact that these relations are automatically deduced from the relations between roles on one hand, and between locations on the other hand. If a new location, say Italy, is inserted in the taxonomy of locations, all pairing of a role with Italy become virtually present in L2. The same happens for the insertion of a new role. This results in an expressive logic for describing and querying data, while requiring no additional effort from the information system designer.

The logic L2 can replace the use of Location in logic L1 or, even better, the notion of role can be generalized to all kinds of concrete domain logics, resulting in the logic L3 = Top(Prod(Role,Sum(Location, Sum(String,Sum(Integer,Date))))).

In this logic the elements of the taxonomy, i.e., properties over objects, can be seen as valued attributes over various concrete domains. Additional concrete domains can then easily be added to this logic definition.

Querying and Navigation

Querying and navigating over our logical taxonomies are based on Logical Concept Analysis (LCA), which is a generalization of formal concept analysis that represents properties by logical formulas instead of boolean attributes [START_REF] Ferré | An introduction to logical information systems[END_REF].

In LCA an information base is called a logical context.

Definition 2 (logical context)

A logical context is a triple K = (O, L, D)
, where O is a set of objects (e.g., photos), L is a logic equiped with a subsumption relation and a most general element , and D is a mapping from objects to their description, a set of logical properties.

Object descriptions need only to contain the most specific properties of objects, other properties being implicitely assumed through subsumption. For instance, if a photo is given the property in France, it gets implicitely the property in Europe. This is taken into account in the definition of extent, which defines the set of objects having some property. Definition 3 (extent) Given a logical context K = (O, L, D), the extent of a property x ∈ L is defined as the set of all objects having some descriptor subsumed by x:

extent(x) = {o ∈ O | ∃d ∈ D(o) : d x}.
While this function computes "the objects sharing some property", a dual operation, intent computes "the properties shared by some objects". Definition 4 (intent) Given a logical context K = (O, L, D), the intent of a set of objects E is defined as the set of properties whose extent contains E:

intent(E) = {x ∈ L | E ⊆ extent(x)}.
The notions of extent and intent are the basis of querying and navigation. We now describe how these operations are defined in our software, CAMELIS. Figure 1 shows a screenshot of CAMELIS user interface, which is made of 3 main components:

• at the top, a query field for displaying and editing the current query,

• at the left, a property tree displaying a view on the logical taxonomy,

• at the right, an object list displaying query answers (here photos).

The contents and relationships between these components are described in the following.

Querying

Queries are arbitrary boolean combinations of logical properties. The definition of extent is extended from properties to complex queries in the natural way (under closed world assumption):

extent(Q 1 and Q 2 ) = extent(Q 1 ) ∩ extent(Q 2 ) extent(Q 1 or Q 2 ) = extent(Q 1 ) ∪ extent(Q 2 ) extent(not Q) = O \ extent(Q)
The object list always displays the extent of the current query. Given a context of photos using the logic L3 from Section 2, the complex query event contains "journey" and (in Spain or in Greece) and not date = 2000 retrieves all photos related to some journey taking place somewhere in Spain or in Greece, except those (known to be) taken in 2000. The properties in this query can be used even if they are not visible in the taxonomy. In this case they are automatically inserted and made visible for future navigation. Users also have the possibility to insert new proper-ties, and to modify hand-designed taxonomies, through the user interface.

Navigation

Navigation in CAMELIS follows the same principles as in dynamic taxonomies [START_REF] Sacco | Dynamic taxonomies: A model for large information bases[END_REF], but with refinements coming from the use of logic and concept analysis. The property tree displays a subset of the logical taxonomy, showing only properties that are relevant w.r.t. the current query extent. Definition 5 (support and relevance) Let K = (O, L, D) be a logical context, and E be the current query extent. The support of a property x is defined as |E ∩ extent(x)|. A property x is relevant if its support is strictly positive, or greater than a given threshold.

In the user interface, the support is displayed at the left of each property. This provides an easy way to read histograms, like the number of photos per year, or per european country. If a property x has a support different to 0 and |E|, it can be used to focus the current query Q in 2 opposite ways: Q and x, Q and not x, making negation accessible through navigation. Disjunction is also ac-cessible through navigation by multiple selection of properties: after selecting properties x 1 , ..., x n , the query becomes Q and (x 1 or ... or x n ). These different combinations, and more, which are supported by very few systems, are available through a contextual menu on the property tree.

If a property x has a support equal to |E|, this means that E ⊆ extent(x), i.e., x belongs to the intent of the current extent E. In CAMELIS user interface intent properties are distinguished by their text color (grey in Figure 1). Intent properties cannot be used to focus the query, but we use them to widen it. Suppose that after focusing twice we get the query in France and date = 2007, and we want to widen it w.r.t. location. The back button would first remove the date property, and editing the query field is no longer navigation. Instead we use the intent properties in France and in Europe. If in France is selected, it is removed from the query, which becomes date = 2007. If in Europe is selected, it replaces in France in the query, which becomes in Europe and date = 2007. In both cases the query is made more general, and the corresponding extent is usually larger. In this way a query can be focused and widened w.r.t. any facet (e.g., date, location) in any order.

For efficiency and readability reasons the property tree is initially totally collapsed, and the children of a property are computed on demand, when the user explodes a tree node. This is in contrast with the usual approach in FCA that consists in precomputing the whole navigation structure, the concept lattice (exponential in time and space). The computation of children properties is a function of the current extent and the parent property (selected by the user). Several options are available such as minimum support threshold, and whether to sort children by decreasing support or according to some logical order (e.g., chronological for dates, alphabetical for locations).

Practical Aspects

CAMELIS is available at http://www.irisa.fr/-LIS/ferre/camelis/. It has been used in a number of applications: (a) personal photo collection of more than 5,000 photos described by about 50 properties each, taken among 15,000 properties in total (see Figure 1), (b) thousands of music files with automatic extraction of tags (e.g., artist, album) as logical properties, (c) bibliographic files with thousands of references, (d) libraries of Java methods and Objective Caml functions, whose types are expressed in a complex composite logic.

CAMELIS is implemented in a highly modular way so that it can be quickly adapted to various applications. LIS are also implemented as a genuine Linux file system, LISFS [START_REF] Padioleau | A logic file system[END_REF]. It is therefore visible through existing applications (e.g., text editors, compilers). It has been applied to the management of a whole homedir, and is the basis of a geographical information system, GEOLIS [START_REF] Bedel | GEOLIS: A logical information system for geographical data[END_REF].

Conclusion

We presented Logical Information Systems (LIS). They offer a combination of querying and navigation that is similar to dynamic taxonomies but integrates complex properties such as dates, intervals and strings in navigation, rather than in querying only. This is achieved by defining and composing logics, where a basic logic can be either a classical hand-designed taxonomy or an intentionally defined taxonomy. This makes it possible, for instance, to distinguish different roles w.r.t. locations, and to automatically insert query terms in taxonomies for navigation purposes. A widening navigation mechanism has also been added as a complement to focusing navigation.

Figure 1 .

 1 Figure 1. User interface of CAMELIS, exemplified on a photo collection.


Alexandre Ortiz

Eglantine Husson

Jocelyn Barbarand

Eric Lasseur

Justine Briais

Understanding the thermal history of the North Aquitaine platform: implications on vertical motion and karstification

come   L'archive ouverte pluridisciplinaire

Understanding the thermal history of the North Aquitaine platform: implications on vertical motion and karstification

Alexandre Ortiz *1 , Eglantine Husson 1 , Jocelyn Barbarand 2 , Eric Lasseur 1 , Justine Briais 1 , 1 Bureau de Recherches Géologiques et Minières (BRGM), Orléans, 45100, France 2 Université Paris-Saclay, CNRS, GEOPS, Orsay, 91405, France

The Lower Cretaceous corresponds, in northwestern Europe, to a period of significant extension with the rifting of the Bay of Biscay and its eastern prolongation, the Parentis Basin. This basin has a long history of rifting and several important discontinuities between the uppermost Jurassic and the Albian (at the top of the Jurassic, top of the Barremian and at the Aptian-Albian boundary).

North of this basin i.e. the Aquitaine Platform, the sedimentation is very patchy, the few known Lower Cretaceous deposits suggest continental conditions during this period.

Preliminary work carried out on some deep boreholes located on the Aquitaine platform reconstructed temperatures by thermochronology (apatite fission track on Triassic and Permian samples). The preliminary results show that these samples are not in equilibrium with the current sedimentary thickness taking into account a conventional geothermal gradient (35°/km). All these the samples then show a significant cooling at the end of the Lower Cretaceous consistent with a regional erosion event.

This preliminary work leads us to make two hypothesis:

-The deposition of a Lower Cretaceous sedimentary thickness that was then eroded form the Aptian. This hypothesis is in agreement with study carried out further east (French Massif Central) but not with the first order sedimentary outcropping characterization on the Aquitaine platform. -The high palaeotemperatures recorded are controlled by an increase in the geothermal gradient (a gradient of 50°/km must be considered) during the Upper Jurassic and Lower Cretaceous. This model does not consider the deposition and the erosion of a thick Cretaceous cover. This hypothesis is difficult to explain over such large area without significant crustal thinning. These two-hypothesis lead to very different palaeogeographical situations and to very different vertical displacement. The answer to these questions is a key in order to understand the periods of karstification of the Jurassic carbonate platform and therefore to have a better knowledge of the water reservoir.

We presented in this work the results of an integrated study. The results are based on a combination of field study and the interpretation of subsurface data (boreholes and seismic). A wide range of methods has been applied to this dataset (sedimentology, sequence stratigraphy, well correlation, isotopic and geochemical analysis of carbonate, sand and clay and thermochronology).