<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">A Lattice-Based Data Structure for Information Retrieval and Machine Learning</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Dean</forename><surname>Van Der Merwe</surname></persName>
							<affiliation key="aff0">
								<orgName type="institution">University of Pretoria</orgName>
								<address>
									<postCode>0002</postCode>
									<settlement>Pretoria</settlement>
									<country key="ZA">South Africa</country>
								</address>
							</affiliation>
						</author>
						<author role="corresp">
							<persName><forename type="first">D</forename><forename type="middle">G</forename><surname>Kourie</surname></persName>
							<email>dkourie@cs.up.ac.za</email>
							<affiliation key="aff0">
								<orgName type="institution">University of Pretoria</orgName>
								<address>
									<postCode>0002</postCode>
									<settlement>Pretoria</settlement>
									<country key="ZA">South Africa</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">A Lattice-Based Data Structure for Information Retrieval and Machine Learning</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">935A22AA01C48EA50E0A2490C8EC4B65</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-24T00:25+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>A lattice-based data structure, called a compressed lattice, is proposed as a generic data structure. It is closely related to a concept lattice and can be used in applications such as machine learning, information retrieval and document browsing. The data structure, essentially a bipartite graph with an embeddedlattice, combines desirable features of concept lattices in a structure that allows for a flexible mechanism of scaling the size of the embedded-lattice, by means of defined operations that compress and expand the embedded lattice. A compression strategy or criterion is required to guide this process.</p><p>This paper assumes a working knowledge of concept lattices and readers are referred to <ref type="bibr" target="#b0">[1,</ref><ref type="bibr" target="#b3">4]</ref> for a formal introduction.</p><p>Consider a domain of discourse in which each element of a set of entities, Ent = {e 1 , e 2 , …, e j } possesses one or more observable attributes from a set of attributes Attr = {a 1 , a 2 , …, a k }. We refer to entities to as objects, whilst attributes are sometimes referred to as features or descriptors. The triple C = Ent, Attr, I ¡ , where I is a binary relation between Ent and Attr, I ⊆ Ent × Attr, is referred to as a context and denotes this domain of discourse. The binary relation I, also called an incidence relation , identifies the attributes of each entity.</p><p>Consider a set S and arbitrary elements x, y and z in S. A partial ordering relation</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Introduction</head><p>"Knowledge is of two kinds: we know a subject ourselves or we know where we can find information upon it" Samuel Johnson, quoted in Boswell 1791</p><p>The use and application of concept lattices is an area of active and promising research in various fields of study such as information retrieval <ref type="bibr" target="#b1">[2]</ref>, software engineering <ref type="bibr" target="#b11">[11]</ref>, and machine learning <ref type="bibr" target="#b4">[5,</ref><ref type="bibr" target="#b5">6,</ref><ref type="bibr" target="#b10">10]</ref>.</p><p>Here a lattice-based data structure is defined that contains features of both a concept lattice and bipartite graph. The data structure is described in reference to a generic information retrieval problem that is essentially a query operation on a database (section 2). Examples are given of query operations on bipartite graphs and concept lattices. After discussing the merits of both approaches, a compressed lattice is defined as a lattice from which some of the concepts have been removed, subject to a set of so-called compressed lattice properties. An equivalent query on a compressed lattice is also defined. A compressed lattice in essence allows the removal or "compression" of concepts in a concept lattice in such a way that the resulting structure retains the desirable properties of the lattice. It is essentially a bipartite graph with an embedded-lattice. Its properties ensure that removed lattice concepts can be re-instated.</p><p>We end by discussing the implementation and use of these ideas as well as promising (albeit preliminary) results of compressed lattices. We argue that a lattice may contain many concepts that are redundant (due, for example, to noisy data) and that these can be removed via the compressed lattice operations. Examples of other approaches to constrain the lattice size are also briefly mentioned. Finally a number of key questions are posed. These are topics for further research.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">An Information Retrieval (IR) Problem Definition</head><p>¢ on S is one that is reflexive (x ¢ x), antisymmetric (x ¢ y ^ y ¢ x £ x = y) and transitive (x ¢ y ^ y ¢ z £ x ¢ z). The set S in conjunction with an associated partial ordering relation ¢ is called a partially ordered set or poset and is denoted by ¤ S, ¢ ¦¥ . For x, y ∈ S, x ≠ y, x is said to cover y, indicated by y § x when y ¢ x and there is no z ∈ S, z ≠ x, z ≠ y such that y ¢ z and z ¢ x. Some texts refer to x as the parent or predecessor of y. Similarly y is referred to as the child or successor of x.</p><p>One way of visually representing a poset is by means of a directed acyclic graph in which elements of the poset form the nodes and a directed arc is drawn from node y to x iff y § x. This graph is called a Hasse diagram and provides a natural data structure for representing a poset. By convention, instead of showing the direction of arcs explicitly in the Hasse diagram, node x is shown above node y if y § x.</p><p>For this problem domain we define a database D = ¤ S, ¢ ¨¥ related to context C as consisting of a set, S, of concepts which are partially ordered by the relation ¢ . The database is restricted in that the maximal elements are the attributes (Attr) in C and the minimal elements are the objects (Ent) in C. In addition D may contain any number of such intermediate concepts M (i.e. S = Attr ∪ Ent ∪ M) . The upward closure of any concept c, indicated by UpwardClosure(D, c), is the set of concepts greater than or equal to c in terms of the partial ordering. The downward closure is the set of concepts that are less than or equal to c, and is indicated by DownwardClosure(D, c). The extent of a concept is defined as the set of objects in its downward closure. Similarly the intent of a concept is the set of attributes in its upward closure.</p><p>We consider the problem of retrieving a set of objects relevant (in some abstract and as yet undefined way) to a specific query. The query is formulated as a set of attributes in the form Q = {a 1 , a 2 , …., a m } and different query operations can be defined on D. The result of a specific query operation O based on D with respect to query Q is indicated by O (D, Q). A query operation may return any number of concepts from D. For convenience, we place an extra restriction on the query operation: that the operation may return only non-object concepts.</p><p>Notwithstanding the foregoing, we choose to interpret the final results in terms of objects, namely those objects that are in the union of the extents of the concepts returned by the query operation (i.e. the union of a number of possibly intersecting attribute downward closures). As a consequence the results of a query can be interpreted as clusters of objects represented by the concepts returned by the query operation.</p><p>Different query operations may be evaluated in terms of the information retrieval (IR) metrics, precision and recall. Conversely using the same query operation, different databases of the same context can be evaluated against each other in terms of these metrics. Clearly only concepts in a given database can be returned. Therefore it can be expected that a database containing "meaningful" concepts will return concepts that result in high precision and recall values. We argue that a compressed lattice is a versatile data structure to represent various databases of this type and could prove useful in researching information retrieval and machine learning strategies.  The simplest example of a database is that of a bipartite graph (essentially representing the incidence relation) with objects at the bottom, attributes at the top and arcs from each object to all the attributes it possesses in a specific context as illustrated in figure <ref type="figure" target="#fig_0">1</ref>. This simple context, called the living context, is taken from Ganter <ref type="bibr" target="#b1">[2]</ref> and was originally used in an Hungarian educational film.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.1">A Bipartite Database and Query Operation</head><p>Consider O BP (D, Q), a query operation on a bipartite database. For a query Q we define O BP (D, Q) = Q. As an trivial example we see that for Q = {mo, lw} the query O BP (D, Q) would return {mo, lw}, effectively referencing the set of objects {LE, BR, FR, DG, SW, RD}. This can be verified by inspecting the Hasse diagram of the database for DownwardClosure(D, mo) = {LE, BR, FR, DG} and DownwardClosure(D, lw) = {LE, BR, FR, SW, RD}.</p><p>A shortcoming of the bipartite database and of O BP is the fact that the query operation returns a very general set of objects, each of which has any, but not all, of the attributes specified in the query Q. In IR terms the query operation has low precision but high recall. One way of improving the precision is to introduce a new intermediate concept called " mo_lw" that groups all objects that possesses both mo and lw into the database. This concept would be connected via upward-arcs to mo and lw and all objects possessing mo and lw would have upward-arcs to the new concept. In this way, a query operation might be able to use the new concept in arriving at the results of the query.</p><p>Continuing this line of thought, the other end of the spectrum would be to use a concept lattice as the database. This option is discussed in the next section. O Meet (D, Q) is a query operation on a lattice database and is defined as the meet of the attributes of Q in the lattice. For the query Q={mo, lw} the resulting objects are therefore {BR, FR, LE} since the meet of {mo, lw} is concept n7 which has an extent of {BR, FR, LE} (i.e. objects that possesses all of the attributes in Q are returned). Note that it is now possible to obtain a result with a higher precision due to the fact that concepts lower down in the database discern between objects in a more granular way.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.1">A Lattice</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.3">An Adapted Lattice Database and Query Operation</head><p>Assuming that we were looking for all the fish objects in the living context (in this case only BR qualifies) with query Q = {mo, lw}. The lattice-based query operation O Meet has a higher precision and recall than O BP . O Meet has however the disadvantage that it is not tolerant of errors or ambiguity in either the context or formulation of the query terms. Assume, for example, that we are looking for all edible plants in the context and used the query Q={nw, nc, 1lg, 2lg}. O Meet (D, Q) would not return any relevant objects since the meet of Q is not in the database − the meet is the empty concept ∅ of the implied lattice. One strategy that could help in this case and increase the tolerance for errors is to specify a query operation O for a context of n attributes that will return the minimal concepts that have at most k ≤ n attributes, all of which all are in Q. Since the domain of discourse as defined requires that queries only be formulated in terms of concepts already contained in the database we can adopt one of two strategies. The first is to redefine the query operation to examine all concepts and return the appropriate minimal concepts. In this case, the database D is kept the same. A second option is to modify the query operation and the database. For reasons that will become clear, we will pursue the latter option. Fig. <ref type="figure">3</ref>. A database with concepts with an intent of more than three attributes removed Removing all concepts in the lattice in figure <ref type="figure">2</ref> that have more than k = 3 attributes creates the new database in figure <ref type="figure">3</ref>. Where the original lattice concepts have been removed, dashed-arcs indicate successors defined by the partial ordering relation <ref type="foot" target="#foot_0">1</ref> . Note that a subset, L, of the database namely all the concepts except DG, BR, FR, MZ, RD, SW still forms a lattice when the implied universal and empty concept is inserted. This lattice (identified by all the concepts connected with solid arcs) does not correspond to either the Galois or EA-lattice lattice for the given context. A query operation on the database in figure <ref type="figure">3</ref> using L now cannot discern between objects that have more than k attributes in common.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3">Compressed Lattice Definitions</head><p>In this section the database in figure 3 is used as an example of a compressed lattice. We define the set of approximate and exact representatives; the CompressLattice and ExpandLattice operations; and the notion of a compressed lattice. The need for compression strategies for creating a compressed lattice is addressed.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1">Approximate and Exact Representatives</head><p>Repeating the query operation O Meet for Q={nw, nc, 1lg, 2lg} in figure <ref type="figure">3</ref>, we find that there is no meet in the database. A revised query operation on the database as defined below will however solve the problem. Consider the lattice, L, and exclude the empty-and the universal concepts of L from the discussion.</p><p>Let S be the set of all meets of all subsets of Q in L. The set of approximate intent representatives of Q in the lattice L, denoted by AIR(L, Q), is the set of minimal concepts in S <ref type="foot" target="#foot_1">2</ref> .</p><p>Suppose a query operation for Q returns the approximate intent representatives of Q in the lattice embedded in D, i.e. O AIR (D, Q) = AIR(D Embed , Q) where D Embed is the lattice embedded in D . If Q ={nw, nc, 1lg, 2lg} then S = { nw, 2lg, nc, 1lg, n4, n6, BN} and {BN, n6} is the set of minimal elements of S. Thus O AIR returns AIR(L, Q) = {BN, n6} for figure <ref type="figure">3</ref>, assuming D Embed is the lattice, L, identified in section 2.3. This refers to the objects {BN, MZ, RD, SW}.</p><p>Inspecting the intents of the concepts in AIR(L, Q) we see that BN, for example, has attributes in its intent that are not in Q. If we wish to restrict a query operation to find only concepts possessing attributes in Q, then we need to define a related operation on the database, called the exact intent representative operation.</p><p>Let S be the set of all meets of all subsets of Q in L. Let T be that subset of S whose elements have intents that are not subsets of Q. The set of exact intent representatives of Q with respect to a lattice L, denoted by EIR(L, Q), is the set of minimal elements in S -T. If T = ∅ then clearly EIR(L, Q) = AIR(L, Q).</p><p>For Q = {nw, nc, 1lg, 2lg} we saw that AIR(L, Q) = {n6, BN} whilst EIR(L, Q) = {2lg, n6} since T = {BN}. As before, O EIR (D, Q) = EIR( D Embed , Q) = EIR(L, Q) = {2lg, n6}. Thus, in the present example, O EIR (D, Q) references the same set of objects as before, namely {BN, MZ, RD, SW}.</p><p>The O EIR and O AIR operations can be applied to figure <ref type="figure" target="#fig_0">1</ref>, in which the embedded lattice is reduced to the set of attributes. In that case,</p><formula xml:id="formula_0">O BP (D, Q) = O EIR (D, Q) = O AIR (D, Q). If D is a pure lattice, as in figure 2, then O Meet (D, Q) = O EIR (D, Q) for a non- trivial meet(Q).</formula><p>The point is that both the O AIR and O EIR operations are defined in terms of a lattice. and should the lattice be changed as in the example, for figures 1 to 3, the representative sets also change. When Q has a non-trivial meet (i.e. not the universal concept) in the lattice then EIR(D, Q) = AIR(D, Q) = Meet(D, Q). The representative sets of Q were defined to deal with situations when Q has a trivial meet. The operations may be seen as extentions of the meet operation.</p><p>Dual operations for AIR(D,Q) and EIR(D,Q) can be defined as follows. Q is a set of objects and the meet and the minimal operations can be substituted by join and maximal operations in the above definitions respectively. This defines the set of approximate extent representatives , AER(D, Q) and the set of</p><formula xml:id="formula_1">exact extent representatives, EER(D, Q). If Join(D, Q) is non-trivial, Join(D, Q) = AER(D, Q) = EER(D, Q).</formula><p>Finally, it is useful to define a further related set of concepts, namely EIR(D,Q,C). This is the set of exact intent representatives of Q excluding C. It corresponds identically to EIR(D,Q), except that in determining the minimal elements of S above, a designated concept, C, is specifically excluded from consideration. As a result, if C is in EIR(D,Q), then EIR(D,Q,C) contains all the concepts that cover C, instead of C itself. In particular, if C = meet(D,Q), then EIR(D,Q,C) is the set of concepts covering meet(D,Q). The set of exact extent representatives excluding C, EER(D, Q, C) is defined similarly. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2">CompressLattice Operation</head><p>The CompressLattice operation removes a concept y from the embedded-lattice in the lattice-based data structure and replaces the concept with virtual-arcs (indicated as a dashed-arcs). These arcs interconnect all the parent-with all the child concepts of y. Figure <ref type="figure">4</ref> shows an example of a lattice-based structure where all the concepts have been removed by successively using CompressLattice operations. Similarly, figure <ref type="figure">3</ref> can be verified to be the result of successive upward CompressLattice operations on DG, BR, FR, MZ, RD, SW, n10, n11, n12, and finally n13.</p><p>It is important to note that the CompressLattice operation works from a particular direction. In the examples, the lattice was compressed in the upward direction, but the operation is equally valid when compressing the lattice from the top downward (or any combination of the two). The CompressLattice operation creates a data structure that is not a lattice. We call it a compressed lattice. Using parameter names to imply types, the CompressLattice operation is defined as follows in terms of its pre-and post-conditions:</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>CompressLattice(aCompressedLattice, aConcept, aDirection) returns outCompressedLattice</head><p>Pre-condition: aConcept is in aCompressedLattice, it has at least one lattice-arc in aDirection and no lattice-arcs in the opposite direction.</p><p>Post-condition: outCompressedlattice retains all the nodes and arcs of aCompressedLattice, except in the following respects. If aConcept is an attribute or entity concept, then lattice-arcs connecting it to other concepts in aCompressedLattice are replaced by virtual-arcs in outCompressedLattice. Otherwise aConcept and its arcs are not in outCompressedLattice. Instead, virtual-arcs link each of aConcept's parents to each of aConcept's children.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.3">Definition and Properties of Compressed Lattices</head><p>A compressed lattice is a data structure that represents a particular context C = Ent, Attr, I¡ . The data structure consists of a number of concepts that are connected by one of two types of directed arcs:</p><p>lattice-arcs and virtual-arcs. The concepts are partitioned into three sets: the attributes (of the context), the objects (of the context) and any number of intermediate concepts. A compressed lattice contains an embedded-lattice. The embedded-lattice is the set of all concepts complying with one of the following: the concept is an attribute node; or at least one lattice-arc connects to or from the concept. Note that in an embedded lattice, lattice-and/or virtual arcs may be incident on an attribute node.</p><p>The following are compressed lattice properties. They define sufficient conditions for a data structure to be a valid compressed lattice. Note that the conditions listed are not disjoint − they may be related to or imply one another.</p><p>• Poset: The concepts in the compressed lattice form a poset with respect to the partial ordering relation specified by the directed arcs (lattice or virtual) • Context preservation: Attributes and objects in the context are present as concepts.</p><p>Objects contain in their upward closure all their attributes specified in the context, but no other attributes. Similarly attributes contain in their downward closure all their objects specified in the context, but no other objects. • Unconnected objects and attributes : Attributes may have no upward arc and similarly objects may have no downward arcs. • Unique intermediate concepts <ref type="foot" target="#foot_2">3</ref> : No two intermediate concepts may have the same extent or the same intent. This property implies that any intermediate concept has at least two upward and two downward arcs. This does not preclude attributes and objects from having the same extent or intent respectively. Such concepts are represented as different concepts in a compressed lattice. • Empty intent: No concept may have an empty intent (i.e. all objects must possess at least one attribute but some attributes may not have any object possessing the attribute). This limits the contexts for which a valid compressed lattice may be constructed. Although the property is not strictly required, the practical benefits of contexts that do not conform to this requirement are not immediately clear. • Embedded-lattice: The set of all concepts together with the ordering used in the embedded-lattice, constitute a lattice when appropriately connected to the implied universal and the empty lattice concepts. • Meet and join : Consider any set, S, of concepts connected via lattice-arcs. Any subset of S has at most one meet or no meet at all (the lattice property). Similarly any subset of S has at most one join or no join at all. • Intermediate virtual-arcs : Intermediate concepts may not have any virtual-arcs to any other intermediate concepts. Their virtual-arcs must end in an attribute concept or start at an entity concept. • Exact representative connection : Let I(C) be the intent of any concept C in a compressed lattice. Let S Embed and S Full be the sets of exact intent representatives of I(C) excluding C in the embedded lattice and fully elaborated EA-lattice, respectively. Then a lattice arc connects C to each element of S Embed if the element is also in S Full and a virtual arc connects C to every other element of S Embed . A similar property holds for the set of exact extent representatives of E(C) excluding C, where E(C) is the extent of C. These dual properties are critical in ensuring that the closure operations function as expected.</p><p>• Arc duplication: A concept may only have one arc (either lattice or virtual) to any concept that covers it. • Cover: A concept may not have an arc to any other concept to which it is indirectly linked <ref type="foot" target="#foot_3">4</ref> . The definition and properties show that a compressed lattice is essentially a bipartite graph that contains an embedded-lattice. Furthermore the compressed lattice properties ensure a well-defined and unique structure for a given context and a given sequence of compressed lattice operations. A number of operations can be defined on a compressed lattice, but the most important are: • ApproximateRepresentatives and ExactRepresentatives for an intent and extent • CompressLattice and ExpandLattice (described in the next section)</p><p>• Closure and LatticeClosure, where LatticeClosure follows only lattice-arcs when discovering concepts whilst Closure follows any type of arc • InsertNewLatticeObject, i.e. insert a new object into the context and embeddedlattice by using a modified incremental lattice construction algorithm • InsertNewVirtualObject, an alternative to InsertNewLatticeObject that does not use a computationally expensive lattice construction algorithm to update the embedded-lattice. The object is inserted into the compressed lattice by simply creating virtual-arcs to its exact representatives</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.4">ExpandLattice Operation</head><p>A complementary operation to CompressLattice, namely ExpandLattice, can be defined to enlarge the embedded lattice of a compressed lattice. The operation works in a particular direction, starting with a concept that has virtual arcs in that direction.</p><p>In the downward direction starting with concept C, the operation determines what the children of C would be in the fully elaborated ("uncompressed") EA-lattice. To do this requires the determination of the set of exact extent representatives excluding C, of the extent of C. Concepts in this set but not yet in the compressed lattice are inserted into it. C is directly connected to these concepts by lattice-arcs and C's virtual arcs are removed. To comply with compressed lattice and "pure" lattice properties <ref type="foot" target="#foot_4">5</ref> further generation of concepts and/or creation, removal or re-labelling of arcs may be necessary. Similar remarks apply pari passu when expanding a given concept in the upward direction.</p><p>Note that the CompressLattice and ExpandLattice operations are not symmetric in that the one does not reverse the other. In most instances a single CompressLattice operation cannot destroyed the portion of the compressed lattice that an ExpandLattice operation builds. It is however always possible to completely compress a lattice into a bipartite graph or to use ExpandLattice operations to completely rebuild the lattice from a bipartite graph. Our implementation of this latter series of operations indicates that it is computationally more expensive than using a "traditional" incremental lattice construction algorithm to construct a lattice. The context preservation and exact representative connection properties of a compressed lattice play important roles in the ability to rebuild the lattice.</p><p>ExpandLattice is defined below in terms of its pre-and post conditions. Again, parameter names imply their corresponding types.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>ExpandLattice(aCompressedLattice, aConcept, aDirection) returns outCompressedLattice</head><p>Pre-condition: aConcept is a concept in aCompressedLattice that has virtual-arcs in aDirection.</p><p>Post-condition: outCompressedlattice retains all the nodes and arcs of aCompressedLattice, except in the following respects. If aDirection is down (up), then all possible child (parent) concepts of aConcept that would occur in the associated EA lattice are inserted into outCompressedLattice's embedded lattice. Additional concepts are created and arcs are created, removed or relabelled if and only if necessary to maintain compressed lattice (including embeddedlattice) properties.</p><p>As an example of the ExpandLattice operation, consider figure <ref type="figure">4</ref> with the compressed lattices D 0 to D 5 . When starting with D 5 , i.e. the bipartite graph, the following order of ExpandLattice operations will reconstruct D 0 (using to indicate "downward"): D 4 = ExpandLattice(D 5 , c, ); D 2 = ExpandLattice(D 4 , e, ); D 1 = ExpandLattice(D 2 , a, ) and finally D 0 is the result of successive ExpandLattice calls that expand the concepts n1, n2 and n3 in a downward direction. Note that ExpandLattice(D 4 , e, ) does not produce D 3 because D 3 does not contain all of e's children that exist in the underlying and implied full lattice, D 0 .</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.5">Pruning Strategies and Criteria for Creating Compressed Lattices</head><p>Section 2 defined a very specific domain of discourse of which there are three components: the context, the database and the query operation. A compressed lattice is such a database. The separation of the database and query operation as well as the requirement that results only be formulated in terms of non-object concepts actually represented in the database creates an interesting deviation from some traditional information retrieval approaches: the organization of the database co-determines the outcome of the of the query operation in that for a given context the result of a query may be different, depending on the compressed lattice being used to represent the context. The question that arises is thus: "Are there databases derived from compressed lattices that, on average, result in better retrieval for the same context?"</p><p>Limited experimental results (currently unpublished) show that there are indeed better methods of organization. Specifically, it appears that a database consisting of the complete lattice of a given context need not, in general, be the best database. In many instances significantly compressed lattices performed better. Further experimentation is required in order to explore compression strategies and node pruning criteria that lead to optimal performance.</p><p>In general, there are a number of possible compression strategies that seem to deserve such exploration. The most obvious is the one stated above where the lattice is compressed up to a specific level. It is useful to have a pruning strategy combined with a threshold on the embedded-lattice size. The embedded-lattice is then repeatedly compressed until the lattice size is below the threshold. This can be combined with an adapted incremental lattice construction algorithm where the pruning mechanism is invoked after each individual object or batch of objects has been inserted into the compressed lattice. Combinations of the operation InsertNewVirtualObject can also be used. This has the added advantage of limiting the size of the lattice and therefore the time taken to build a compressed lattice.</p><p>Compression strategies that have been preliminarily tested use a combination of the following:</p><p>• Compress concepts with an intent of size smaller than t and larger than u.</p><p>• Compression is based on the number of arcs to child or parent concepts in the lattice. • Compression is based on EP(c), an estimate of prior probability of the concept c.</p><p>EP(c) is the number of objects in the intent of c divided by the total number of concepts in the context. Refer to Oosthuizen <ref type="bibr" target="#b10">[10]</ref> for a discussion and examples • Compress, based on the difference between an estimate of the expected probability ExP(c) <ref type="foot" target="#foot_5">6</ref> and EP(c). This concept property performed the best in most preliminary test results.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Implementation and Discussion of Preliminary Results</head><p>The compressed lattice data structure and associated operations have been implemented and tested in C++. To construct the lattice a new incremental lattice construction algorithm was developed. This algorithm is currently being compared to other documented incremental construction algorithms such as Godin <ref type="bibr" target="#b4">[5]</ref> and Oosthuizen <ref type="bibr" target="#b7">[8]</ref>. Early indications are promising. The algorithm is explicitly relies upon exact representative and approximate representative sets. (The algorithm's main loop has an invariant and terminating condition that is based on these.) It has been extended to operate on compressed lattices by incrementally inserting new objects as well as the required new intermediate concepts into an embedded-lattice whilst maintaining the compressed lattice properties. The potential gain in computational efficiency of having a compressed lattice should be weighed against the advantages of having a larger and more complete set of concepts available in a particular domain. Results however suggest that a compressed lattice may be a useful generic data structure for various IR and machine learning problem domains.</p><p>In Oosthuizen <ref type="bibr" target="#b9">[9,</ref><ref type="bibr" target="#b10">10]</ref> and Kourie and Oosthuizen <ref type="bibr" target="#b6">[7]</ref>, a data structure based on a modified lattice was proposed as a means to reduce the number of concepts in a lattice. That data structure (also called a compressed lattice) was a limited version of the compressed lattice data structure defined above. It did not retain the lattice properties and other desirable properties (e.g. context preservation) of the data structure proposed above. Despite those limitations, improved results in lattice-based machine learning tests were achieved. It was argued that although a structure such as a lattice contains a concept node for every possible combination of objects supported by the data, it seemed to contain many concepts that are not, in some sense, useful or meaningful. Removing them appeared to improve the outcome.</p><p>One application of this idea was to remove concepts in the embedded-lattice that are the meets of statistically independent attributes. Being randomly related, these attributes will to occur in any number of combinations in a given context. As a result, a large number of concepts are generated in a lattice to reflect these random relationships. Indeed, the theoretical limit of the lattice size is for example reached when all attributes in the context are statistically independent <ref type="bibr" target="#b10">[10]</ref>. Such concepts are not really worth learning as rules in a machine learning context and are therefore in some sense not "meaningful".</p><p>The compressed lattice we described here is a more generalised and versatile version of this approach. Alternative methods of reducing concepts are also discussed in <ref type="bibr" target="#b10">[10]</ref>. Godin <ref type="bibr" target="#b4">[5]</ref> on the other hand also proposed ways of reducing concepts in a lattice called a pruned concept lattice. In general a compressed lattice is not directly comparable to a pruned concept lattice but the two concepts can be combined.</p><p>Finally, the scaling of the size of a compressed lattice has an interesting implication in IR contexts. In a lattice the results of a query operation O EIR (D, Q) is the intersection or conjunction of the downward closures of the attributes in Q (i.e. the meet) and can be expressed as in equation 1. In the bipartite graph O EIR (D, Q) is the union of the downward closures of the attributes in Q expressed as in equation 3. By iteratively scaling the lattice the conjunctive expression progressively turns into a disjunctive expression with an intermediate expressions typified by equation 2. For a suitable compression strategy, a proximity based query operation can thus be defined.</p><p>O EIR (D, Q) = a 1 a 2 … a n for a i ∈ Q, provided Meet(Q) is non-trivial (1) O EIR (D, Q) = (a 1,1 a 1,2 … a 1,j ) (a 2,1 a 2,2 … a 2,k ) … (a n,1 a n,2 … a n,x ) for a y,z ∈ Q (</p><p>O EIR (D, Q) = a 1 a 2 … a n for a i ∈ Q</p><p>(3)</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">Conclusion and Areas of Further Research</head><p>We defined a compressed lattice as a generic lattice-based data structure that shows promise in many field of research due to its close resemblance to that of a lattice. A number of critical questions remain:</p><p>• In what areas of application is a compressed lattice beneficial? Specifically: is a compressed lattice more suitable than a Galois lattice in areas where the latter has proven successful? • What compression strategies and criteria should be used and in which areas of application? Specifically, is there a universal compression strategy applicable to many areas of application or is a compression strategy domain specific? • What is the relation of a compressed lattice and associated operations to other fields of research in databases, rough sets, etc given its seeming ability to deal with ambiguity? The authors intend pursuing these and related areas of research. Initial results indicate that the answers to these and other questions hold promise in many applications. In</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head>Fig. 1 .</head><label>1</label><figDesc>Fig. 1. The living context and its associated bipartite graph</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>D 1 =Fig. 4 .</head><label>14</label><figDesc>Fig. 4. A CompressLattice example compressing a lattice to a bipartite graph</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_1"><head>Database and Query Operation</head><label></label><figDesc></figDesc><table><row><cell></cell><cell>{sk}</cell><cell></cell><cell cols="2">{lb}</cell><cell cols="2">{mo}</cell><cell>{ll}</cell><cell></cell><cell>{nw}</cell><cell>{lw}</cell><cell>{2lg}</cell><cell>{nc}</cell><cell>{1lg}</cell></row><row><cell></cell><cell>sk</cell><cell cols="2">lb</cell><cell>mo</cell><cell></cell><cell>ll</cell><cell></cell><cell></cell><cell>nw</cell><cell>lw</cell><cell>2lg</cell><cell>nc</cell><cell>1lg</cell></row><row><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell>{nw,nc}</cell></row><row><cell></cell><cell></cell><cell></cell><cell>n1</cell><cell></cell><cell></cell><cell>n2</cell><cell cols="2">{nw,ll}</cell><cell>n3</cell><cell>{nw,lw}</cell><cell>n4</cell></row><row><cell></cell><cell></cell><cell></cell><cell cols="3">{nw,mo}</cell><cell></cell><cell></cell><cell></cell></row><row><cell></cell><cell cols="3">{nw,mo,</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell></cell><cell>n5</cell><cell></cell><cell>lb}</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell>n6</cell><cell>{nw,nc,1lg}</cell></row><row><cell></cell><cell></cell><cell></cell><cell></cell><cell cols="2">n7</cell><cell cols="2">{nw,mo, lw}</cell><cell>n8</cell><cell>{nw,ll, lw}</cell><cell>n9</cell><cell>{nw,ll,nc}</cell></row><row><cell></cell><cell cols="2">n10 {nw,mo, lb,ll}</cell><cell>n11</cell><cell cols="3">{nw,mo, lb,lw}</cell><cell></cell><cell></cell><cell>n12</cell><cell>{nw,ll, nc,1lg}</cell><cell>n13</cell><cell>{nw,lw, nc,1lg}</cell></row><row><cell>DG</cell><cell>BR</cell><cell></cell><cell></cell><cell>FR</cell><cell></cell><cell></cell><cell>LE</cell><cell cols="2">BN</cell><cell>MZ</cell><cell>RD</cell><cell>SW</cell></row><row><cell cols="8">Fig. 2. An EA-lattice of the living context</cell><cell></cell></row><row><cell cols="10">Figure 2 is a concept lattice for the living context. Note that a modified version of the</cell></row><row><cell cols="10">Galois lattice called an entity-attribute lattice or EA-lattice is used. It has clearly</cell></row><row><cell cols="10">partitioned sets of attributes, objects and intermediate concepts. Consequently it also</cell></row><row><cell cols="10">has a slightly revised ordering relation compared to that of a Galois lattice. The</cell></row><row><cell cols="10">universal-and empty concepts of the lattice have been excluded from the database.</cell></row><row><cell cols="10">(They are, however, implied.) The intents of some of the concepts are shown as a</cell></row><row><cell>guide.</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row></table></figure>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="1" xml:id="foot_0">Note that, for technical reasons, there is a dashed-arc between DG and sk, even though no concept has been removed. This is done to ensure that, by removing all intermediate concepts, a bipartite graph having only dashed arcs can be derived.</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="2" xml:id="foot_1">(x © S is minimal, iff y © S such that y § x.)</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="3" xml:id="foot_2">This is not a property of Galois lattices. For example, the Galois lattice of the living context (not shown here) does not possess this property.</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="4" xml:id="foot_3">Concept x is indirectly linked to concept y iff it has a path via one or more intermediate concepts.</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="5" xml:id="foot_4">The properties labeled above as Embedded-lattice and Meet and join embody the lattice properties to be retained by a compressed lattice.</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="6" xml:id="foot_5">ExP(c) = EP(a 1 ) × EP(a 2 ) × … × EP(a n ) and where a i is an attribute in the intent of c. This estimate assumes that the attributes are independent.</note>
		</body>
		<back>

			<div type="acknowledgement">
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Acknowledgement</head><p>The authors wish to acknowledge the invaluable contribution that Deon Oosthuizen made to this research during his tenure as an associate professor at Pretoria University.</p></div>
			</div>

			<div type="annex">
<div xmlns="http://www.tei-c.org/ns/1.0"><p>addition, the previously mentioned lattice construction algorithm is being evaluated against documented incremental lattice construction algorithms.</p></div>			</div>
			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<monogr>
		<title level="m" type="main">Lattice Theory</title>
		<author>
			<persName><forename type="first">B</forename><surname>Birkhoff</surname></persName>
		</author>
		<imprint>
			<date type="published" when="1973">1973</date>
			<publisher>American Mathematical Society Colloquium Publ</publisher>
			<biblScope unit="volume">25</biblScope>
			<pubPlace>Providence</pubPlace>
		</imprint>
	</monogr>
	<note>revised edition</note>
</biblStruct>

<biblStruct xml:id="b1">
	<analytic>
		<title level="a" type="main">Software for formal concept analysis</title>
		<author>
			<persName><forename type="first">B</forename><surname>Ganter</surname></persName>
		</author>
		<author>
			<persName><forename type="first">K</forename><surname>Rindfrey</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Skorsky</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Classification as a tool of research</title>
				<imprint>
			<publisher>Elsevier Science</publisher>
			<date type="published" when="1986">1986</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<analytic>
		<title level="a" type="main">Information retrieval through hybrid navigation of lattice representations</title>
		<author>
			<persName><forename type="first">C</forename><surname>Carpineto</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Romano</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">International Journal of Human-Computer Studies</title>
		<imprint>
			<biblScope unit="volume">45</biblScope>
			<biblScope unit="page" from="553" to="578" />
			<date type="published" when="1996">1996</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">Formal Concept Analysis</title>
		<author>
			<persName><forename type="first">B</forename><surname>Ganter</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><surname>Wille</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Mathematical Foundations</title>
				<imprint>
			<publisher>Springer-Verlag</publisher>
			<date type="published" when="1999">1999</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">An Incremental Concept Formation Approach for Learning from Databases</title>
		<author>
			<persName><forename type="first">R</forename><surname>Godin</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><surname>Missaoui</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Special Issue on Formal Methods in Databases and Software Engineering</title>
		<imprint>
			<biblScope unit="volume">133</biblScope>
			<biblScope unit="page" from="387" to="419" />
			<date type="published" when="1994">1994</date>
		</imprint>
	</monogr>
	<note>Theoretical Computer Science</note>
</biblStruct>

<biblStruct xml:id="b5">
	<analytic>
		<title level="a" type="main">Incremental structuring of knowledge bases</title>
		<author>
			<persName><forename type="first">R</forename><surname>Godin</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><forename type="middle">W</forename><surname>Mineau</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><surname>Missaoui</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the first International Symposium on Knowledge Retrieval, Use and Storage for Efficiency (KRUSE&apos;95)</title>
				<meeting>the first International Symposium on Knowledge Retrieval, Use and Storage for Efficiency (KRUSE&apos;95)<address><addrLine>Santa Cruz, CA, USA</addrLine></address></meeting>
		<imprint>
			<date type="published" when="1995">1995</date>
			<biblScope unit="page" from="179" to="198" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<analytic>
		<title level="a" type="main">Lattices in machine learning: complexity issues</title>
		<author>
			<persName><forename type="first">G</forename><forename type="middle">D</forename><surname>Dg. Kourie</surname></persName>
		</author>
		<author>
			<persName><surname>Oosthuizen</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Acta Informatica</title>
		<imprint>
			<biblScope unit="volume">35</biblScope>
			<biblScope unit="page" from="269" to="292" />
			<date type="published" when="1998">1998</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b7">
	<analytic>
		<title level="a" type="main">Lattice-based Knowledge D iscovery</title>
		<author>
			<persName><surname>Gd</surname></persName>
		</author>
		<author>
			<persName><surname>Oosthuizen</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of AAAI-91</title>
				<meeting>AAAI-91</meeting>
		<imprint/>
	</monogr>
</biblStruct>

<biblStruct xml:id="b8">
	<monogr>
		<title level="m">Knowledge Discovery in Databases Workshop</title>
				<meeting><address><addrLine>Anaheim</addrLine></address></meeting>
		<imprint>
			<date type="published" when="1991">1991</date>
			<biblScope unit="page" from="221" to="235" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b9">
	<analytic>
		<title level="a" type="main">A Dynamic Indexing Mechanism for Memory-based Reasoning</title>
		<author>
			<persName><surname>Gd</surname></persName>
		</author>
		<author>
			<persName><surname>Oosthuizen</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the international AMSE conference on &quot;intelligent systems</title>
				<meeting>the international AMSE conference on &quot;intelligent systems</meeting>
		<imprint>
			<publisher>SMSE Press</publisher>
			<date type="published" when="1994">1994</date>
			<biblScope unit="page" from="127" to="136" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b10">
	<monogr>
		<title level="m" type="main">The application of concept lattices to machine learning</title>
		<author>
			<persName><surname>Gd</surname></persName>
		</author>
		<author>
			<persName><surname>Oosthuizen</surname></persName>
		</author>
		<idno>94/01</idno>
		<imprint>
			<date type="published" when="1994">1994</date>
		</imprint>
		<respStmt>
			<orgName>Department of Computer Science University of Pretoria</orgName>
		</respStmt>
	</monogr>
	<note type="report_type">Technical Report CSTR</note>
</biblStruct>

<biblStruct xml:id="b11">
	<analytic>
		<title level="a" type="main">Reengineering class hierarchies using concept analysis</title>
		<author>
			<persName><forename type="first">G</forename><surname>Snelting</surname></persName>
		</author>
		<author>
			<persName><forename type="first">F</forename><surname>Tip</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of ACM SIGPLAN/SIGSOFT Symposium on Foundations of Software Engineering</title>
				<meeting>ACM SIGPLAN/SIGSOFT Symposium on Foundations of Software Engineering<address><addrLine>Orlando, FL</addrLine></address></meeting>
		<imprint>
			<date type="published" when="1998">1998</date>
			<biblScope unit="page" from="99" to="110" />
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
