arXiv is now an independent nonprofit! Learn more
License: arXiv.org perpetual non-exclusive license
arXiv:1803.07847v1 [cs.DB] 21 Mar 2018

On-demand Relational Concept Analysis

Alexandre Bazin Affiliation: Le2i, Université Bourgogne Franche-Comté, Dijon, France    Jessie Carbonnel Affiliation: LIRMM, CNRS and Université de Montpellier, Montpellier France    Marianne Huchard Affiliation: LIRMM, CNRS and Université de Montpellier, Montpellier France    Giacomo Kahn Affiliation: LIMOS, Université Clermont Auvergne, Clermont-Ferrand, France
contact@alexandrebazin.com,{jcarbonnel,huchard}@lirmm.fr,giacomo.kahn@isima.fr
Abstract

Formal Concept Analysis and its associated conceptual structures have been used to support exploratory search through conceptual navigation. Relational Concept Analysis (RCA) is an extension of Formal Concept Analysis to process relational datasets. RCA and its multiple interconnected structures represent good candidates to support exploratory search in relational datasets, as they are enabling navigation within a structure as well as between the connected structures. However, building the entire structures does not present an efficient solution to explore a small localised area of the dataset, for instance to retrieve the closest alternatives to a given query. In these cases, generating only a concept and its neighbour concepts at each navigation step appears as a less costly alternative. In this paper, we propose an algorithm to compute a concept and its neighbourhood in extended concept lattices. The concepts are generated directly from the relational context family, and possess both formal and relational attributes. The algorithm takes into account two RCA scaling operators. We illustrate it on an example.

Keywords: 
Relational Concept Analysis, Formal Concept Analysis, On-demand Generation

1 Introduction

Many datasets in thematic areas like environment or product lines comprise databases complying with a relational data model. Typical applications in which we are currently involved concern issues relative to watercourse quality11 1 http://engees-fresqueau.unistra.fr/presentation.php?lang=en (Fresqueau project), the inventory and use of pesticidal, antibacterial and antifungal plants22 2 http://www.cirad.fr/en/news/all-news-items/articles/2017/science/identifying-plants-used-as-natural-pesticides-in-africa-knomana (Knomana project), and the analysis and representation of product lines [4]. In these applications, there is a wide range of question forms, such as classical querying, establishing correlations between descriptions of objects from several categories or case based reasoning. These questions can be addressed by complementary approaches including conceptual classification building, knowledge pattern and rule extraction, or exploratory search [17, 20]. In the Knomana project, for example, one main purpose will be, after the ongoing inventory, to support farmers, their advisors, local entrepreneurs or researchers in selecting plants of immediate interest for agricultural crop protection and animal health. As such users will face large amounts of data, and mainly will formulate general, potentially imprecise, and potentially inaccurate queries without prior knowledge of the data, exploratory search will be a suitable approach in this context.

Previous work [14, 5, 7, 11, 8] has shown that Formal Concept Analysis may be a relevant support for data exploration and we expect Relational Concept Analysis (RCA) to be beneficial as well. Considering RCA for relational dataset exploration brings issues relative to the use of the scaling (logical) operators, the iterative process and the presence of several concept lattices connected via relational attributes. Despite this additional complexity, RCA helps the user to concentrate on the classification of objects of several categories, where the object groups (concepts) are described by intrinsic attributes and by their relations to object groups of other categories. Besides, the relational attributes offer a support to navigate between the object groups of the different categories, while the concept lattices offer a (by-specialisation) navigation between object groups of the same category.

There are several complementary strategies to explore datasets using RCA. One may consist in exhaustively computing concept lattices (and related artefacts like implication rules) at several steps, using several logical operators and considering only some of the object categories and some of the inter-categories relationships. Another strategy, which is followed here, consists in an on-demand computation of a concept and its neighbourhood comprising its upper, lower and relational covers.

The next section presents the main principles of Relational Concept Analysis (Section 2). The on-demand computation of a concept and its neighbourhood is presented in Section 3. Section 4 illustrates the algorithm with the example introduced in Section 2. Related work is exposed in Section 5. We conclude the paper with a few perspectives in Section 6.

2 Relational Concept Analysis

Formal Concept Analysis (FCA) [12] allows to structure a set of objects described by attributes in a canonical structure called a concept lattice. It is based on a formal context K=(𝒪,𝒜,)K=(\mathcal{O},\mathcal{A},\mathcal{I}), where 𝒪\mathcal{O} is the set of objects, 𝒜\mathcal{A} the set of attributes, and \mathcal{I} an incidence relation stating "which objects possess which attributes". From this context, the application of FCA extracts a finite set CKC_{K} of formal concepts (X,Y)(X,Y) such that X={o𝒪|aY,(o,a)}X=\{o\in\mathcal{O}~|~\forall a\in Y,(o,a)\in\mathcal{I}\} is the concept’s extent, and Y={a𝒜|oX,(o,a)}Y=\{a\in\mathcal{A}~|~\forall o\in X,(o,a)\in\mathcal{I}\} is the concept’s intent. The concept lattice is obtained by ordering the concepts of CKC_{K} by the set-inclusion order on their extents. We call an object-concept (resp. attribute-concept) the lowest (resp. the greatest) concept in the lattice possessing an object (resp. an attribute).

Relational Concept Analysis (RCA) [15, 16] is an adaptation of FCA to process relational datasets. A relational dataset is composed of several sorts of objects described by both their own attributes and their relationships with other objects. As input, RCA takes a Relational Context Family (RCF), gathering a set of formal contexts and a set of relational contexts defining links between the objects of different formal contexts.

Definition 1 (Relational Context Family)

A Relational Context Family is a pair (K,R)(\textbf{K},\textbf{R}) such that:
- K={Ki=(𝒪i,𝒜i,i)}\textbf{K}=\{K_{i}=(\mathcal{O}_{i},\mathcal{A}_{i},\mathcal{I}_{i})\} is a set of formal contexts (object-attribute relations)
- R={rk},rk𝒪i×𝒪j\textbf{R}=\{r_{k}\},r_{k}\subseteq\mathcal{O}_{i}\times\mathcal{O}_{j} is a set of relational contexts (object-object relations), with 𝒪i\mathcal{O}_{i} and 𝒪j\mathcal{O}_{j} being sets of objects (respectively of KiK_{i} and KjK_{j}). KiK_{i} is called the source context and KjK_{j} the target context.

The three contexts of Table 1 present an example of RCF (Ks,Rs)(\textbf{K}_{s},\textbf{R}_{s}) taken from the software product line domain. Table 1 (top) displays two formal contexts. The one on the left-hand side presents 5 Data Modelling tools (DM_tools) against 7 attributes representing their compatible operating systems (OS:), and the data models (DM:) the tools may manage. The table on the right-hand side describes 4 DataBase Management Systems (DBMS) according to the data types (DT:) they may handle. Table 1 (bottom) presents a relational context stating which Data Modelling tools support which DataBase Management Systems.

Table 1: (top) Two formal contexts: (left-hand side) Data Modelling tools (DM_tools) and (right-hand side) DataBase Management Systems (DBMS). (bottom) Relational context stating which DM_tools support which DBMS

Ks=\textbf{K}_{s}= DM_tools OS:Windows OS:Mac OS OS:Linux DM:Conceptual DM:Physical DM:Logical DM:ETL Astah x x x x Erwin DM x x x x ER/Studio x x x x x Magic Draw x x x x x x MySQL Workbench x x x x DBMS DT:Enum DT:Set DT:Geometry DT:Spatial DT:Audio DT:Image DT:Video DT:XML DT:JSON DT:Period MySQL x x x Oracle x x x x x PostgreSQL x x x x Teradata x x x x x

Rs=\textbf{R}_{s}= support MySQL Oracle PostgreSQL Teradata Astah x x Erwin DM x x x ER/Studio x x x x Magic Draw x x x MySQL Workbench x

Applying RCA on the contexts of K builds, in a first time, one concept lattice per context (i.e., sort/category of objects), without taking links into account. The two concept lattices associated with Table 1 (top) are presented in Fig. 1.

Figure 1: (left) concept lattice of DM_tools, (right) concept lattice of DBMS

In a second time, RCA introduces links between objects of different lattices depending on the relations expressed in R. These links take the form of relational attributes; they introduce the abstractions (i.e., concepts) from the target context into the source context through a specific relation and a specific scaling operator. In our example, we may introduce the relational attribute support.(C_DBMS_4)\exists~support.(C\_DBMS\_4) to characterise the DM_tools that support at least one DBMS offering Json and XML. More generally, given two formal contexts Ki,KjKK_{i},K_{j}\in\textbf{K} and a relational context r𝒪i×𝒪jr\subseteq\mathcal{O}_{i}\times\mathcal{O}_{j}, the application of RCA extends the set of attributes 𝒜i\mathcal{A}_{i} with a set of relational attributes representing links to the concepts of KjK_{j}. The extended attribute set is denoted 𝒜i+\mathcal{A}_{i}^{+}. Then, the incidence relation i\mathcal{I}_{i} is extended to take into account these new attributes (denoted i+\mathcal{I}_{i}^{+}), by associating them to each object of 𝒪i\mathcal{O}_{i} depending on the relation rr, the concept (denoted CC) involved in the relational attribute and a scaling operator ρ\rho. A relational attribute is thus of the form "ρr.(C)""\rho~r.(C)". In this paper, we focus on two scaling operators: the existential operator (denoted \exists), associating an object oo to the relational attribute r.(C)\exists r.(C) if oo is linked to at least one object of the extent of CC by rr; the universal strict operator (denoted \exists\forall), associating an object oo to r.(C)\exists\forall r.(C) if all the objects linked to oo by rr are included in the extent of CC, and r(o)r(o)\not=\emptyset.

The concept lattice associated with a formal context K+=(𝒪,𝒜+,+)K^{+}=(\mathcal{O},\mathcal{A}^{+},\mathcal{I}^{+}) then structures the objects from 𝒪\mathcal{O} both by their attributes and their relations to other sets of objects through the relational attributes. Fig. 2 presents the extended concept lattice corresponding to the extended formal context DM_tools+, according to the relation support and the existential scaling operator.

Figure 2: Concept lattice of the extended context DM_tools+

In this way, for complex data models including more than one relation, RCA produces a succession of concept lattices, extended at each step by the new abstractions obtained at the previous step. At step 0, the concept lattices in the set L0\textbf{L}_{0} are the ones built from the initial formal contexts from K. At step nn, the formal contexts in the set Kn\textbf{K}_{n} are extended depending on the concepts of the concept lattices in Ln1\textbf{L}_{n-1} and the relations expressed in R.

3 The Exploration Algorithm

In this section, we present an algorithm for taking a step in an exploration. It considers an RCF potentially extended at previous steps, a starting concept CC from a context 𝒦i\mathcal{K}_{i} of the RCF and an exploration strategy which consists in choosing a set of relations of the RCF (with 𝒦i\mathcal{K}_{i} as a source) provided with scaling operators. The objective of one step is to complete the intent corresponding to the extent of CC, as well as compute its upper, lower and relational covers. Meanwhile, the RCF is updated with the relational attributes for a next step.

Redefining Derivation Operators

The explicit knowledge of all the relational attributes of a context requires the computation of all the concepts of the target contexts. However, we cannot afford what amounts to the exhaustive computation of the relational concepts of multiple contexts. We would prefer to manipulate only a minimal number of relational attributes allowing us to derive, on-the-fly, the other relational attributes.

Any object described by an attribute ρr.(X,Y)\rho~r.(X,Y) (instead of ρr.((,,,))\rho~r.((X,Y)) by abuse of notation) is also necessarily described by all the attributes of the form ρr.(X2,Y2)\rho~r.(X_{2},Y_{2}) where Y2YY_{2}\subseteq Y. As such, intents can be represented without loss of information by their relational attributes constructed from attributes-wise maximal concepts. However, a problem arises with such a representation: the set intersection cannot be used to compute the intent of a set of objects anymore. Similarly, if only maximal relational attributes are explicitly present in the context, the extent of a set of attributes cannot be computed through a simple test of set inclusion. To remedy this, we provide three algorithms to use on sets of attributes (both intrinsic and relational) with only the maximal relational attributes given explicitly.

Intersect takes as input two sets of attributes AA and BB represented by their maximal relational attributes. It outputs the set of maximal relational attributes of their intersection. A relational attribute r.(X,Y)\exists r.(X,Y) is in the intersection of AA and BB if and only if there exists two attributes r.(X2,Y2)A\exists r.(X_{2},Y_{2})\in A and r.(X3,Y3)B\exists r.(X_{3},Y_{3})\in B such that XX2X\subseteq X_{2} and XX3X\subseteq X_{3}. The same holds for the \exists\forall scaling operator. As such, intersecting the intents of the concepts in the attributes of AA and BB and keeping the maximal ones results in the maximal relational attributes. It uses Ex (Algorithm 3).

Input: 𝒦i=(𝒪i,𝒜i,i)\mathcal{K}_{i}=(\mathcal{O}_{i},\mathcal{A}_{i},\mathcal{I}_{i}) a formal context, A𝒜iA\subseteq\mathcal{A}_{i} an attribute set, B𝒜iB\subseteq\mathcal{A}_{i} the intent of an object oo
Output: The relational intersection of the attribute set AA and the intent of oo
A2ABA_{2}\leftarrow A\cap B 1
\mathcal{F}\leftarrow\emptyset 2
foreach a1r.(X1,Y1)Ba_{1}\sim\exists r.(X_{1},Y_{1})\in B with r𝒪i×𝒪jr\subseteq\mathcal{O}_{i}\times\mathcal{O}_{j} and 𝒦j=(𝒪j,𝒜j,j)\mathcal{K}_{j}=(\mathcal{O}_{j},\mathcal{A}_{j},\mathcal{I}_{j}) do 3
foreach a2r.(X2,Y2)Aa_{2}\sim\exists r.(X_{2},Y_{2})\in A do 4
 {r.(\mathcal{F}\leftarrow\mathcal{F}\cup\{\exists r.(Ex(𝒦jCLOSE,(\mathcal{K}_{j},IntersectOPEN(𝒦j,Y1,Y2)),(\mathcal{K}_{j},Y_{1},Y_{2})),Intersect(𝒦j,Y1,Y2))}(\mathcal{K}_{j},Y_{1},Y_{2}))\} 5
    A2A2A_{2}\leftarrow A_{2}\cupMax(,𝒜i)(\mathcal{F},\subseteq_{\mathcal{A}_{i}}) 6
\mathcal{F}\leftarrow\emptyset 7
foreach a1r.(X1,Y1)Ba_{1}\sim\exists\forall r.(X_{1},Y_{1})\in B with r𝒪i×𝒪jr\subseteq\mathcal{O}_{i}\times\mathcal{O}_{j} and 𝒦j=(𝒪j,𝒜j,j)\mathcal{K}_{j}=(\mathcal{O}_{j},\mathcal{A}_{j},\mathcal{I}_{j}) do 8
foreach a2r.(X2,Y2)Aa_{2}\sim\exists\forall r.(X_{2},Y_{2})\in A do 9
 {r.(\mathcal{F}\leftarrow\mathcal{F}\cup\{\exists\forall r.(Ex(𝒦jCLOSE(\mathcal{K}_{j},IntersectOPEN(𝒦j,Y1,Y2)),(\mathcal{K}_{j},Y_{1},Y_{2})),Intersect(𝒦j,Y1,Y2))}(\mathcal{K}_{j},Y_{1},Y_{2}))\} 10
    A2A2A_{2}\leftarrow A_{2}\cup\mathcal{F} 11
return A2A_{2}
Algorithm 1 Intersect(𝒦i,A,B)(\mathcal{K}_{i},A,B)

In uses Intersect to compute the intent of a set of objects described by their maximal relational attributes. It starts with the set of all explicitly known attributes and intersects it with the description of each object in the context 𝒦i\mathcal{K}_{i}.

Input: 𝒦i=(𝒪i,𝒜i,i)\mathcal{K}_{i}=(\mathcal{O}_{i},\mathcal{A}_{i},\mathcal{I}_{i}) a formal context, O𝒪iO\subseteq\mathcal{O}_{i} a set of objects
Output: Computes the intent of a set of objects OO
1
A𝒜iA\leftarrow\mathcal{A}_{i} 2
foreach oOo\in O do 3
AA\leftarrowIntersect(A,Intent({o}))(A,Intent(\{o\})) 4
 return A 5
6
Algorithm 2 In(𝒦i,O)(\mathcal{K}_{i},O)

Ex computes the extent of a set of maximal relational attributes A. For each object oo and attribute ρr.(X,Y)A\rho~r.(X,Y)\in A, it checks whether r(o)r(o) and XX intersect in the correct way (depending on the scaling operator).

Input: 𝒦i=(𝒪i,𝒜i,i)\mathcal{K}_{i}=(\mathcal{O}_{i},\mathcal{A}_{i},\mathcal{I}_{i}) a formal context, A𝒜iA\subseteq\mathcal{A}_{i} a set of attributes
Output: Computes the extent of a set of attributes AA
1
O𝒪iO\leftarrow\mathcal{O}_{i} 2
foreach aAa\in A do 3
if ar.(X,Y)a\sim\exists\forall r.(X,Y) then 4
 foreach oOo\in O do 5
    if r(o)Xr(o)\not\subseteq X then 6
       OOoO\leftarrow O\setminus o 7
          else if ar.(X,Y)a\sim\exists r.(X,Y) then 8
 foreach oOo\in O do 9
    if r(o)X=r(o)\cap X=\emptyset then 10
       OOoO\leftarrow O\setminus o 11
          else 12
 foreach oOo\in O do 13
    if (o,a)i(o,a)\not\in\mathcal{I}_{i} then 14
       OOoO\leftarrow O\setminus o 15
          return O 16
17
Algorithm 3 Ex(𝒦i,A)(\mathcal{K}_{i},A)

Computing the Closed Neighbourhood

Now that we have redefined the derivation operators on implicitly known relational contexts, we are able to compute the upper, lower and relational covers of a concept.

The easiest are the relational covers. A concept (X,Y)(X,Y) is a relational cover of a concept (U,V)(U,V) if and only if ρr.(X,Y)\rho~r.(X,Y) is a maximal relational attribute in VV. Upper covers are easy too. Candidates can be generated by adding an object – the set of which we have perfect knowledge of – to the current extent and computing the corresponding concept. The covers are the candidates that have the smallest extent. Computing the lower covers is more challenging. They could be computed by adding attributes to the intent but the full set of relational attributes is only known implicitly. We chose to, instead, remove objects. The lower covers of (X,Y)(X,Y) being the concepts with the maximal extents that are contained in XX and do not contain any of the minimal generators of XX, a simple way to compute them would be to remove minimal transversals of the minimal generators.

Algorithm 4 computes the closed neighbourhood of a concept CC. It takes as input a set of formal contexts K=(𝒦1,,𝒦w)\textbf{K}=(\mathcal{K}_{1},\dots,\mathcal{K}_{w}) of a RCF, a strategy 𝒮={(r,ρ)lj,},\mathcal{S}=\{(r,\rho)_{lj},\dots\}, l,j{1,,w}l,j\in\{1,\dots,w\} and a starting concept CC from a context 𝒦i\mathcal{K}_{i}. The goal is to compute (or complete) the intent corresponding to the extent of CC, as well as its upper, lower and relational covers, in the extended context 𝒦i+\mathcal{K}^{+}_{i}.

For each (r,ρ)ij𝒮(r,\rho)_{ij}\in\mathcal{S} such that r:𝒦i𝒦jr:\mathcal{K}_{i}\mapsto\mathcal{K}_{j}, the first loop (Lines 1 to 4): computes OCjOC_{j} the object-concepts of 𝒦j\mathcal{K}_{j}; then, each object-concept (X,Y)OCj(X,Y)\in OC_{j}, relation rr and scaling operator ρ\rho give rise to a new relational attribute ρr.(X,Y)\rho~r.(X,Y) that is added to the context 𝒦i\mathcal{K}_{i} with GrowContext.

In Line 4, the intent of concept CC is extended with the relational attributes added during the previous loop. The next loop (Lines 4 to 8) computes the relational covers \mathcal{R} of concept CC. For each relational attribute in the intent of CC, the corresponding concept (in the target context) is added to the cover.

In Lines 4 to 11, the lower covers \mathcal{L} of CC are computed by removing from the extent of CC a minimal transversal of the set of minimal generators of CC’s extent.

Finally, the upper covers 𝒰\mathcal{U} of CC are computed in Lines 4 to 14. Candidates are created by adding an object oo to the extent of CC. Only the extent-wise minimal resulting concepts are kept.

Input: K={𝒦1,,𝒦w}\textbf{K}=\{\mathcal{K}_{1},\dots,\mathcal{K}_{w}\}, 𝒮={(r,ρ)lj,},l,j{1,,w}\mathcal{S}=\{(r,\rho)_{lj},\dots\},l,j\in\{1,\dots,w\} a strategy, C=(O,A)C=(O,A) a concept of 𝒦i=(𝒪i,𝒜i,i)\mathcal{K}_{i}=(\mathcal{O}_{i},\mathcal{A}_{i},\mathcal{I}_{i})
Output: C,𝒰,,C,\mathcal{U},\mathcal{R},\mathcal{L} the completed concept CC and its closed relational neighbourhood
1
foreach (r,ρ)ij𝒮(r,\rho)_{ij}\in\mathcal{S} do 2
OCjOC_{j}\leftarrowObjectPoset(𝒦j)(\mathcal{K}_{j}) 3
 4
 foreach o𝒪io\in\mathcal{O}_{i} do 5
 GrowContext(𝒦i,r,ρ,o,OCj)(\mathcal{K}_{i},r,\rho,o,OC_{j}) 6
    7
 8
AA\leftarrowIn(𝒦i,O)(\mathcal{K}_{i},O) 9
\mathcal{R}\leftarrow\emptyset 10
foreach aρr.(X1,Y1)Aa\sim\rho r.(X_{1},Y_{1})\in A do 11
{(X1,Y1)}\mathcal{R}\leftarrow\mathcal{R}\cup\{(X_{1},Y_{1})\} 12
 13
\mathcal{L}\leftarrow\emptyset 14
foreach TminTrans(minGen(O))T\in minTrans(minGen(O)) do 15
{(OT,\mathcal{L}\leftarrow\mathcal{L}\cup\{(O\setminus T,In(𝒦i,OT))}(\mathcal{K}_{i},O\setminus T))\} 16
 17
𝒰\mathcal{U}\leftarrow\emptyset 18
foreach o𝒪iOo\in\mathcal{O}_{i}\setminus O do 19
𝒰𝒰{(\mathcal{U}\leftarrow\mathcal{U}\cup\{(Ex(𝒦iCLOSE,(\mathcal{K}_{i},InOPEN(𝒦i,O{o}))(\mathcal{K}_{i},O\cup\{o\})), In(𝒦i,O{o}))}(\mathcal{K}_{i},O\cup\{o\}))\} 20
 𝒰\mathcal{U}\leftarrowMin(𝒰,𝒪i)(\mathcal{U},\subseteq_{\mathcal{O}_{i}}) 21
22
return C,𝒰,,C,\mathcal{U},\mathcal{R},\mathcal{L} 23
Algorithm 4 RCA(K,𝒮,C,𝒦i)(\textbf{K},\mathcal{S},C,\mathcal{K}_{i})
Input: 𝒦i=(𝒪i,𝒜i,i)\mathcal{K}_{i}=(\mathcal{O}_{i},\mathcal{A}_{i},\mathcal{I}_{i}) a formal context, r𝒪i×𝒪jr\subseteq\mathcal{O}_{i}\times\mathcal{O}_{j} a relational context, ρ\rho a scaling operator, o𝒪io\in\mathcal{O}_{i} an object, OCjOC_{j} the set of object-concepts of 𝒦j=(𝒪j,𝒜j,j)\mathcal{K}_{j}=(\mathcal{O}_{j},\mathcal{A}_{j},\mathcal{I}_{j})
Output: Extends the context 𝒦i\mathcal{K}_{i} and adds the crosses
if ρ==\rho==\exists then 1
foreach (X,Y)OCj(X,Y)\in OC_{j} such that objr(o)\exists obj\in r(o), objXobj\in X do 2
 𝒜i𝒜ir.(X,Y)\mathcal{A}_{i}\leftarrow\mathcal{A}_{i}\cup\exists r.(X,Y) 3
    ii(o,r.(X,Y))\mathcal{I}_{i}\leftarrow\mathcal{I}_{i}\cup(o,\exists r.(X,Y)) 4
    5
if ρ==\rho==\exists\forall then 6
XX\leftarrowIn(𝒦j,r(o))(\mathcal{K}_{j},r(o)) 7
 𝒜i𝒜ir.(CLOSE\mathcal{A}_{i}\leftarrow\mathcal{A}_{i}\cup\exists\forall r.(ExOPEN(𝒦i,X),X)(\mathcal{K}_{i},X),X) 8
 ii(o,r.(\mathcal{I}_{i}\leftarrow\mathcal{I}_{i}\cup(o,\exists\forall r.(ExOPENOPEN(𝒦i,X),X))(\mathcal{K}_{i},X),X)) 9
 
Algorithm 5 GrowContext(𝒦i,r,q,o,OCj)(\mathcal{K}_{i},r,q,o,OC_{j})

4 Example

In this section, we illustrate the defined algorithms. We consider the RCF (Ks,Rs)(\textbf{K}_{s},\textbf{R}_{s}) with Ks={DM_tools,DBMS}\textbf{K}_{s}=\{DM\_tools,DBMS\} and Rs={support}\textbf{R}_{s}=\{support\} as presented in Section 2. We decide to apply the strategy {(support,)}\{(support,\exists)\}.

Let us imagine that a user wants to select a data modelling tool that runs on Windows (OS:Windows) and that handles logical and conceptual data models (DM:Logical and DM:Conceptual). Traditional FCA may compute the formal concept associated with these 3 attributes (i.e., C_DM_tools_5, left-hand side of Fig. 1), and inform the user that 1) the corresponding tools are Erwin DM, Magic Draw and ER/Studio, and that 2) all these tools also handle DM:Physical.

Let us apply our algorithms on this concept to 1) retrieve the supported DBMS (relational cover) and 2) find the closest alternatives to the query (lower and upper covers): RCA(Ks,{(support,)},C_DM_tools_5,DM_tools)\textbf{K}_{s},\{(support,\exists)\},C\_DM\_tools\_5,DM\_tools).

Lines 1 to 4 extend the context of DM_tools with the relational attributes representing the object-concepts of DBMS (support’s target context). In our case, we have only one relation (support,~\exists) visited at Line 1. In Line 2, OCjOC_{j} takes the object-concepts of DBMS , i.e., concepts 1, 2, 3 and 4 from the right-hand side of Fig. 1. Then, the loop on Lines 3 and 4 considers the 5 objects of DM_tools, on which GrowContext is called. Each object oio_{i} of DM_tools is associated to the relational attributes representing the concepts of OCjOC_{j} having in their extents at least one object linked with ojo_{j}.

As support(Astah)={MySQL,Oracle}support(\texttt{Astah})=\{MySQL,Oracle\}, support(C_DBMS_3)\exists support(C\_DBMS\_3) (MySQL object-concept) and support(C_DBMS_2)\exists support(C\_DBMS\_2) (Oracle object-concept) are added to DM_tools and associated to Astah. At the end of Line 4, we obtain the extended context presented in Table 2.

Table 2: Formal context DM_tools extended according to the relation support
DM_tools+

OS:Windows

OS:Mac OS

OS:Linux

DM:Conceptual

DM:Physical

DM:Logical

DM:ETL

{\exists} sup.(C_DBMS_1)

{\exists} sup.(C_DBMS_2)

{\exists} sup.(C_DBMS_3)

{\exists} sup.(C_DBMS_4)

Astah x x x x x x
Erwin DM x x x x x x x x
ER/Studio x x x x x x x x x
Magic Draw x x x x x x x x x
MySQL Workbench x x x x x

Line 5 updates the intent of the input concept to take into account the relational attributes: {\{OS:Windows, DM:Conceptual, DM:Physical, DM:Logical, sup.(C_DBMS_2)\exists sup.(C\_DBMS\_2), sup.(C_DBMS_3)\exists sup.(C\_DBMS\_3), sup.(C_DBMS_4)\exists sup.(C\_DBMS\_4)}). The concepts of DBMS corresponding to the relational attributes of CC (C_DBMS_2C\_DBMS\_2 to 44) form the relational cover of the input concept (lines 6 to 8).

Then, (Lines 9 to 11) we compute the minimal generators of the extent of CC, which are {\{Erwin DM, Magic Draw}\} and {\{ER/Studio, Magic Draw}\}. Their minimal transversals are {Magic Draw}\{\texttt{Magic~Draw}\} and {Erwin DM, ER/Studio}\{\texttt{Erwin~DM, ER/Studio}\}. The two concepts having {Magic Draw}\{\texttt{Magic~Draw}\} and {Erwin DM,ER/Studio}\{\texttt{Erwin~DM,ER/Studio}\} for extent represent the lower cover (respectively C_DM_tools_1C\_DM\_tools\_1 and C_DM_tools_2C\_DM\_tools\_2 in Fig. 2).

Finally, in Lines 12 to 14, we consider the objects of DM_tools that are not in CC’s extent, i.e., MySQL Workbench and Astah. For each one of them, we compute the concept corresponding to their union with CC’s extent, and we obtain the two concepts C_DM_tools_7 and 8 of Fig. 2. They represent the upper cover of CC.

5 Related Work

Lattice structures are among the first structures used as a support for exploratory search [14], and this task has later attracted a lot of attention in Formal Concept Analysis theory [6]. Many works focus on conceptual neighbourhood to present both information related to a query and its closest variants [13, 7, 1]. In this paper, we consider RCA to retrieve the conceptual neighbourhood in interconnected lattices, structuring both intrinsic and relational attributes.

The exponential growth of concept lattices is well-known [12]. As a consequence, the main limitation of FCA-based exploratory search lies in the complexity and computation of the structures [5]. Many solutions have been proposed to reduce the complexity of conceptual navigation. Some authors propose to prune the concept lattice to restrict the explorable dataspace, by computing iceberg concept lattices [21], or by applying constraints to bound the final structure [5]. To ease the navigation, the authors of [18] seek to extract more simplified browsable structures; they first extract a tree from the concept lattice, and then reduce the obtained tree using clustering and fault-tolerance methods. The tool SearchSleuth [7] enables FCA-based exploratory search for web queries, a field where the domain cannot be entirely processed using FCA and concept lattices. To tackle this issue, they generate a new formal context specific to a query at each navigation step. In a previous work [2], we proposed to compute the conceptual neighbourhood of a query in a sub-order of the concept lattice restricted to the attribute- and object-concepts (attribute-object-concept poset), a condensed alternative to concept lattices. At each step, only the conceptual neighbourhood is computed. In the present work, we also generate the conceptual neighbourhood on-the-fly, but this time in interconnected concept lattices.

Mimouni et al. [19] use RCA to structure, query and browse a collection of legal documents. First, they build interconnected lattices representing different types of legal documents referring to each other. Then, their approach allows for the retrieval of the concept corresponding to a user query, and to explore variations of this query by navigation in the neighbour concepts. In their approach, they compute all the lattices during the first step.

Ferré and Hermann [9] propose Query-based Faceted Search and an implementation in the tool SEWELIS, that allows to browse relational datasets in the form of RDF files. Also, Ferré et al. [10] propose RLCA, a relational extension of Logical Formal Analysis, an adaptation of FCA to describe objects by formulas of ad-hoc logics instead of binary attributes. While RCA computes connected yet separate concept lattices, one per sort of objects, RLCA gathers the objects, their descriptions and their relations to other objects in one structure.

6 Conclusion

In this paper, we proposed algorithms to compute the conceptual neighbourhood of a query in connected concept lattices generated with RCA. First, we redefined the traditional FCA derivation operators to take into account relational attributes. Then, we presented a way to compute the relational, upper and lower covers of a given concept in extended lattices, without computing all the structures. Two RCA scaling operators, i.e., existential and universal strict, may be used. We illustrated how the algorithms work on a running example from the domain of software product line engineering.

In the future, we plan to study the properties of the algorithm and to implement it to perform exploratory search in relational datasets. A scalability study on real datasets from the projects Fresqueau and Knomana and from available product descriptions [3] is then envisioned. To this end, we will generate random queries and exploration paths. We also are collecting concrete questions from the Knomana project partners for having real exploration tasks in their domain and qualitatively evaluate the benefits of the approach.

References

  • [1] Alam, M., Le, T.N.N., Napoli, A.: LatViz: A New Practical Tool for Performing Interactive Exploration over Concept Lattices. In: Proc. of the 13th Int. Conf. on Concept Lattices and Their Applications (CLA’16). pp. 9–20 (2016)
  • [2] Bazin, A., Carbonnel, J., Kahn, G.: On-Demand Generation of AOC-Posets: Reducing the Complexity of Conceptual Navigation. In: Proc. of the 23rd Int. Symp. on Foundations of Intelligent Systems (ISMIS’17). pp. 611–621 (2017)
  • [3] Ben Nasr, S., Bécan, G., Acher, M., Bosco, J.F.F., Sannier, N., Baudry, B., Davril, J.M.: Automated Extraction of Product Comparison Matrices From Informal Product Descriptions. J. of Systems and Software 124, 82 – 103 (2017)
  • [4] Carbonnel, J., Huchard, M., Nebut, C.: Analyzing Variability in Product Families through Canonical Feature Diagrams. In: Proc. of the 29th Int. Conf. on Software Engineering & Knowledge Engineering (SEKE’17). pp. 185–190 (2017)
  • [5] Carpineto, C., Romano, G.: Exploiting the Potential of Concept Lattices for Information Retrieval with CREDO. J. of Universal Comp. Sci. 10(8), 985–1013 (2004)
  • [6] Codocedo, V., Napoli, A.: Formal Concept Analysis and Information Retrieval - A Survey. In: Proc. of the 13th Int. Conf. on Formal Concept Analysis (ICFCA’15). pp. 61–77 (2015)
  • [7] Ducrou, J., Eklund, P.W.: SearchSleuth: The Conceptual Neighbourhood of an Web Query. In: Proc. of the 5th Int. Conf. on Concept Lattices and Their Applications (CLA’07). pp. 249–259 (2007)
  • [8] Dunaiski, M., Greene, G.J., Fischer, B.: Exploratory search of academic publication and citation data using interactive tag cloud visualizations. Scientometrics 110(3), 1539–1571 (2017)
  • [9] Ferré, S., Hermann, A.: Reconciling faceted search and query languages for the semantic web. Int. J. of Metadata, Semantics and Ontologies 7(1), 37–54 (2012)
  • [10] Ferré, S., Ridoux, O., Sigonneau, B.: Arbitrary relations in formal concept analysis and logical information systems. In: Proc. of the 13th Int. Conf. on Conceptual Structures (ICCS’05). pp. 166–180. Springer (2005)
  • [11] Ferré, S.: Reconciling Expressivity and Usability in Information Access - From Filesystems to the Semantic Web. Habilitation thesis, Matisse, Univ. Rennes 1 (2014), habilitation à Diriger des Recherches (HDR), defended on November 6th
  • [12] Ganter, B., Wille, R.: Formal Concept Analysis - mathematical foundations. Springer (1999)
  • [13] Godin, R., Gecsei, J., Pichet, C.: Design of a Browsing Interface for Information Retrieval. In: Proc. of the 12th Int. Conf. on Research and Development in Information Retrieval (SIGIR’89). pp. 32–39 (1989)
  • [14] Godin, R., Saunders, E., Gecsei, J.: Lattice model of browsable data spaces. Inf. Sci. 40(2), 89–116 (1986)
  • [15] Hacene, M.R., Huchard, M., Napoli, A., Valtchev, P.: A Proposal for Combining Formal Concept Analysis and Description Logics for Mining Relational Data. In: Proc. of the 5th Int. Conf. on Formal Concept Analysis (ICFCA’07). pp. 51–65 (2007)
  • [16] Huchard, M., Hacene, M.R., Roume, C., Valtchev, P.: Relational concept discovery in structured datasets. Ann. Math. Artif. Intell. 49(1-4), 39–76 (2007)
  • [17] Marchionini, G.: Exploratory search: from finding to understanding. Comm. ACM 49(4), 41–46 (2006)
  • [18] Melo, C.A., Grand, B.L., Aufaure, M.: Browsing Large Concept Lattices through Tree Extraction and Reduction Methods. Int. J. of Intelligent Information Technologies 9(4), 16–34 (2013)
  • [19] Mimouni, N., Nazarenko, A., Salotti, S.: A conceptual approach for relational ir: Application to legal collections. In: Proc. of the 13th Int. Conf. on Formal Concept Analysis (ICFCA’15). pp. 303–318 (2015)
  • [20] Palagi, É., Gandon, F.L., Giboin, A., Troncy, R.: A survey of definitions and models of exploratory search. In: ACM Workshop ESIDA@IUI. pp. 3–8 (2017)
  • [21] Stumme, G., Taouil, R., Bastide, Y., Pasquier, N., Lakhal, L.: Computing iceberg concept lattices with Titanic. Data Knowledge Engineering 42(2), 189–222 (2002)