Towards Discovering Conceptual Models behind Web Sites

Towards Discovering Conceptual Models behind Web Sites Inma Hernández, Carlos R. Rivero, David Ruiz, and Rafael Corchuelo University of Sevilla, Spain {inmahernandez,carlosrivero,druiz,corchu}@us.es Abstract. Deep Web sites expose data from a database, whose conceptual model remains hidden. Having access to that model is mandatory to perform several tasks, such as integrating different web sites; extracting information from the web unsupervisedly; or creating ontologies. In this paper, we propose a technique to discover the conceptual model behind a web site in the Deep Web, using a statistical approach to discover relationships between entities. Our proposal is unsupervised, not requiring the user to have expert knowledge; and it does not focus on a single view on the database, instead it integrates all views containing entities and relationships that are exposed in the web site. Keywords: URL Patterns, Conceptual Models, Model Discovery. 1 Introduction The Deep Web comprises a number of web sites that expose data stored in a back-end database, publishing them in a friendly format [8]. Entry points to these web sites are submittable query forms, which return as a response a number of web pages that are generated by filling a template with data [4,11]. The data that fill each template is the result of executing a view over the back-end database [2]. Since query forms are the unique entry points to the Deep Web, the different views that provide the data to fill each template are not accessible. Therefore, the conceptual model of the database, which comprises a number of entities and a number of relationships amongst these entities, remains hidden. Having access to the conceptual model of a web site is mandatory to perform several tasks, such as integrating different (semantic or non-semantic) web sites [2,14,15], extracting information from the web without supervision [1,7,11], or creating ontologies by means of query forms [16]. As a consequence, there are many proposals in the literature that deal with discovering conceptual models behind web sites [1,2,4,5,6,9,10,11,12,13,16]. Some of these proposals deal with models composed solely of entities, without taking Supported by the European Commission (FEDER), the Spanish and the Andalusian R&D&I programmes (grants TIN2007-64119, P07-TIC-2602, P08-TIC4100, TIN2008-04718-E, TIN2010-21744, TIN2010-09809-E, TIN2010-10811-E, and TIN2010-09988-E). the relationships between them into account [4,5,6,10,12,13]. Other proposals discover models with entities and relationships [2,16], but they are supervised and require the intervention of the user, providing expert knowledge about each web site. Finally, the rest of the proposals focus on a single template, discovering only one view of the model [1,9,11]. In this paper, we propose a technique to discover the conceptual model behind a web site in the Deep Web. The model our technique is able to discover from each web site does not represent the complete, hidden conceptual model of the backend database, but the union of the views over that conceptual model, composed of those entities and relationships that are exposed in the web site. Our technique takes a set of URL patterns as input, each of which represents an entity in a particular web site. It follows a statistical approach to detect relationships between those entities. Our hypothesis is that each relationship is materialised in HTML links that go from pages of one class to pages of another class, so an XPath pattern targeting those links is created to represent each relationship. The URL patterns that support our technique can be either handmade by the user, or automatically built by any of the former proposals [3,6,10,13]. Our proposal presents some advantages: it creates a conceptual model consisting not only of entities, but also of relationships between those entities; it is not supervised, which saves the user a significant amount of time in labelling training sets, and does not require the user to have expert knowledge; and it integrates different views from the different templates in the site. Moreover, our proposal discovers all the possible anonymous relationships in the model, and we leave the user the task of labelling those relationships with an appropriate name and selecting those relationships that are useful for his or her model. Therefore, the set of relationships we automatically discover can be used as a first approach to the model, which can be refined by an expert data modeller, with a significant reduction in time investment [17]. The rest of this article is organised as follows: Section 2 reports on the related work on web site modelling; Section 3 defines our proposal to discover relationships in web sites; Section 4 shows the validation of our technique, using a well-known academical web site; finally, Section 5 lists some of the conclusions drawn from the research and concludes the article. 2 Related Work There are many proposals related to web site modelling in the literature. Some of these proposals deal with models composed solely of entities [4,5,6,10,12,13], while others deal with more complex models including entities and relationships between those entities [1,2,9,11,16] Models including only entities are usually discovered by web page clustering proposals, which unsupervisedly classify the pages in the web site. This clustering is based in features either from the page content or its structure [17], which implies that the page must be downloaded beforehand [5,12], or from URL features, which prevents having to download it [4,6,10,13]. In the latter case, the result is a collection of URL patterns representing each class. All the former proposals discover models of web sites that are exclusively composed of entities, but none of them discovers relationships amongst those entities. Other proposals deal with models composed of both entities and the relationships amongst those entities. These proposals are usually focused on web information extraction, since extractors require such a model, that can be either provided by the user (supervised proposals) [2,16], or automatically inferred after analysing the pages of the web site (unsupervised proposals) [1,9,11]. On one hand, supervised proposals rely on the user to define the model. Tao et al. [16] analysed the problem of learning ontologies from web sites. Their proposal, FOCIH, consists of providing the user with a wizard-like application to design the model, and annotate pages from the web site according to that model. From that annotations, FOCIH infers an ontology, composed of concepts and relationship between the concepts. Atzeni et al. [2] proposed the Araneus Data Model, which defines a user-generated model for each web site that describes the different views of the schema of the web site, including the different entities and relationships. Supervised proposals require the user to have both the expert knowledge about each site to model it, and the expertise in data modelling to create a good model from scratch. On the other hand, unsupervised proposals infer a model from the analysis of the web site. Kayed et al.[11] proposed FivaTech, a technique to discover the model behind a template, by analysing the DOM tree of a reduced set of web pages generated from that schema. Crescenzi and Mecca[9] proposed RoadRunner, an information extractor which automatically discovers the model behind one template in a web site, and uses this model to extract information. Finally, Arasu and Garcia-Molina [1] proposed EXALG, an information extractor based on grammar inference. The former proposals only discover the model behind one single template in the site, although web sites are usually composed of several templates, one for each type of information it offers. Therefore, each template allows discovering one different view on the back-end database, and all views should be integrated to infer a single conceptual model. 3Proposal Our technique takes a set of URL patterns that describe all classes of information offered in a web site as input, and discovers relationships between the classes. In the following subsections, we first introduce a running example, then we define some concepts that support our technique, and finally we describe the technique. 3.1 Running Example: Microsoft Academic Search Microsoft Academic Search (from now onwards, MsAcademic) is an scholarly web site that offers different classes of information about academic publications (authors, papers, publishing hosts, such as journals or conferences, and research keywords, amongst others). Also, relationships between these classes of information are offered as well, e.g., author pages include a list of papers written by that author, and also a list of papers that cite this author. Furthermore, for each of the former papers, they offer the list of co-authors, the host it was published in, as well as the citations of the paper. For the sake of simplicity, in this paper we focus on classes Paper,Author, Journal,Conference and Citation, and the relationships amongst them. An analysis of the MsAcademic site by the pattern building proposal in [10] yields the following URL patterns: –p1=http, academic.research.microsoft.com, Publication, ,, –p2=http, academic.research.microsoft.com, Author, ,, –p3=http, academic.research.microsoft.com, Journal, , –p4=http, academic.research.microsoft.com, Conference, , –p5=http, academic.research.microsoft.com, Detail, eT, 1, sT, 5, id,  For example, pattern p4matches all URLs in MsAcademic containing information about conferences (e.g., URL http://academic.research.microsoft.com/ Conference/195/er contains information about the ER conference). 3.2 Preliminaries Definition 1 (Tokenisation). Let sbe a string, we define τ(s)= s1,s 2,...,s nas the sequence of tokens that is obtained after tokenising s. Note that this definition is applicable to both URLs and XPath locators. Definition 2 (Pattern). We define a pattern as a sequence of tokens, such that some of the tokens are literals, whereas others are wildcards. We denote a pattern pas p=t1,t 2,...,t m. We distinguish between URL patterns and XPath patterns. The latter are class-dependent, since XPath expressions are calculated in the context of a given page of a certain class c. We represent patterns by means of a subset of regular expressions that includes only literals and wildcard expressions. A wildcard is represented with symbol , and it represents any sequence of characters, excluding token separators defined for a particular tokenisation. Next, we define the problem of finding a match of a given pattern in another string. Definition 3 (Pattern Matching). Let pbe a pattern p=p1,p 2,...,p l, andsbeasequenceoftokenss=s1,s 2,...,s l, both of length l. We define that s matches p, and we denote it as s∼piff each token in p is either a wildcard, or it is equal to the correspondent token in s. Note that pcan be either a URL or XPath pattern, and that both URLs and XPath expressions are strings, hence we can apply the matching predicate on both URLs and XPaths. Let P={p1,p 2,...,p n}be a set of URL patterns obtained from website W. Each of those patterns, according to the labels assigned by the user, corresponds to some class, e.g., pattern p1corresponds to class Paper,patternp2corresponds to class Author,andsoon. Definition 4 (Class-Pattern Correspondence). Let Cbe the set of classes of information offered by a website W,andPbe the collection of URL patterns obtained from W. We define the injective function Φ:C→P, which assigns to each class in Cthe different patterns from Pthat have been labelled as corresponding to that class by the user. For example, after obtaining URL patterns p1,p2,p3,p4and p5in MsAcademic, we assign a label to each pattern, e.g., stating that Φ(Paper)=p1,Φ(Author)= p2,Φ(Journal)=p3,Φ(Conference)=p4and Φ(Citation)=p5. Definition 5 (Detail Page Set). Let Cbe the set of classes of information offered by a website W. We define the set of detail pages of any class c∈C,and we denote it by Dcas the set of pages in Wcontaining information of type c. Note that the Dcof a class cis composed of those pages whose URLs match the patterns that have been labelled by the user as corresponding to that page. Definition 6 (Locator). Let wbe a web page, and u∈wbe a URL. We define the locator of URL uin w, and we denote it by XPath(u, w)as the XPath expression that points at the position of uin w. We use a tree notation to represent tokenisations of XPath expressions based on the PATRICIA trees (XPathTree), which allows representing large collections of strings efficiently and compactly. Every node in an XPathTree is an XPathTreeNode, defined by a label ni, and it refers to a token tj.Notethat each path from the tree root to a leaf represents a single XPath. An example of a tree containing XPath expressions is presented in Figure 1a. For the sake of readability, each token in each node is preceded by the character that separates it from the previous token. 3.3 Relationships Discovery We base the discovery of relationships between two classes on the detection of HTML links in pages of one class whose target is a page of another class. We extract the XPath locators of those links, and we apply a statistical-based technique to estimate the variability of each token in each locator. Then, we abstract the tokens with a high variability (again, using a statistical criterion), creating XPath patterns. Finally, each XPath pattern represents a particular relationship between the former classes. There is an abstract relationship between two classes aand b, if there are links to pages of class bin most pages of class a. However, more than one type of relationship may exist between any given pair of classes aand b. For example, pages of class Author in MsAcademic contain both a list of publications, which include coauthors of the publication, and a list of citations, which includes authors that cited this author, as shown in Figure 2. Therefore, there are two different types of relationships in this model between class Author and itself: 1) isCoauthorOf and 2) cites. n 1 , //div n 2 , [@id n 3 ,='ctl00_divCenter '] n 4 , /div n 55 , [6] n 56 , /ul n 7 , /li n 6 , /ul n 5 , [5] n 9 , /div n 24 , /div n 31 ,/div n 39 , /div n 38 , [4]n 30 ,[3]n 23 , [2]n 8 , [1] n 10 , [2] n 25 , [2] n 32 ,[2] n 40 , [2] n 11 , /a n 12 , [1] n 26 , /a n 27 , [1] n 33 , /a n 34 , [1] n 41 , /a n 42 , [1] n 13 , [2] n 14 , [3] n 35 ,[2] n 43 , [2] n 44 , [3] n 45 , [4] n 59 , /div n 68 , /div n 76 , /div n 84 , /div n 83 , [4]n 75 , [3] n 67 , [2] n 58 , [1] n 60 , [2] n 69 , [2] n 77 , [2] n 85 , [2] n 61 , /a n 62 , [1] n 78 , /a n 79 , [1] n 86 , /a n 87 , [1] n 63 , [2] n 64 , [3] n 80 , [2] n 88 , [2] n 57 , /li n 46 , [5] n 48 , [2] n 49 , /a n 47 , /div n 90 , [5] n 92 , [2] n 93 , /a n 91 , /div n 20 , [9] n 21 , [10] n 22 , [11] n 28 , [2] n 29 , [3] n 36 ,[3] n 37 ,[4] n 50 , [1] n 51 , [2] n 52 , [3] n 53 , [4] n 54 , [5] n 65 , [4] n 66 , [5] n 71 , [1] n 72 , [2] n 73 , [3] n 74 , [4] n 70 , /a n 81 , [3] n 82 , [4]  n 94 , [1] n 95 , [2] n 96 , [3]  n 89 , [2] (a) XPathTree containing the XPaths of URLs of class Author in pages of class Author ŶŽĚĞ ƚŽŬĞŶ ɏ s;ŶŝͿ Ŷϭϭ Ă ΂ϭϭϯϯ΃ ϰϲϮ ŶϮϲ Ă ΂ϯϰϯ΃ Ϭϱϴ Ŷϯϯ Ă ΂ϰϯϯ΃ Ϭϱϴ Ŷϰϭ Ă ΂Ϯϰϭ΃ ϭϱϯ Ŷϰϵ Ă ΂ϭϱϮ΃ ϮϬϴ Ŷϲϭ Ă ΂ϰϱϱ΃ Ϭϱϴ ŶϳϬ Ă ΂ϰϯϰ΃ Ϭϱϴ Ŷϳϴ Ă ΂ϯϰϯ΃ Ϭϱϴ Ŷϴϲ Ă ΂ϯϯϮ΃ Ϭϱϴ Ŷϵϯ Ă ΂ϰϱϴ΃ ϮϬϴ (b) Vfunction values n 1 , //div n 2 , [@id n 3 ,='ctl00_divCenter '] n 4 , /div n 55 , [6] n 56 , /ul n 7 , /li n 6 , /ul n 5 , [5] n 9 , /div n 24 , /div n 31 , /div n 39 , /div n 38 , [4] n 30 , [3] n 23 , [2] n 8 , [1] n 10 , [2] n 25 , [2] n 32 , [2] n 40 , [2] n 11 , /a w 1 , [] n 26 , /a w 2 , [] n 33 , /a w 3 , [] n 41 , /a w 4 , [] n 59 , /div n 68 , /div n 76 , /div n 84 , /div n 83 , [4] n 75 , [3] n 67 , [2] n 58 , [1] n 60 , [2] n 69 , [2] n 77 , [2] n 85 , [2] n 61 , /a w 6 , [] n 78 , /a w 8 , [] n 86 , /a w 9 , [] n 57 , /li n 46 , [5] n 48 , [2] n 49 , /a n 47 , /div n 90 , [5] n 92 , [2] n 93 , /a n 91 , /div w 5 , [] w 7 , [] n 70 , /a w 10 , [] (c) XPathTree, after compression Fig. 1. Representation of the technique, which compresses an XPathTree by abstracting children of nodes with a high variability Using only URL patterns, we are not able to discern between these different types of relationships, since all URLs match the same pattern, regardless of the type of relationship they represent. Therefore, other features must be extracted from the URLs to classify them according to their role. We assume that links whose URL matches the same URL patterns may appear in different locations in the page, but all links representing the same relationship appear in similar locations. Therefore, we use the XPath of the different links, which denotes their location in the page. We apply a technique to build patterns for those XPath, which starts by tokenising all XPath locators and inserting all their tokens in order in an XPathTree. Then, we use some criterion to discern tokens that must be abstracted (replaced by a wildcard), based on the concept of variability of a token. Coauthors Citing authors Fig. 2. Detail page of class Author The variability of a token refers to how spread the numbers of tokens that follow that token in different XPath locators in different pages of the same class (i.e., the different numbers of children of the node representing that token in each page) are. Since we do not analyse all pages of a site, but only a representative sample, we estimate the variability by means of the following definition. Definition 7 (Variability Estimator:). Let Dcbe a set of detail pages of class c,xan XPath expression and nibe a tree node referring a token t, we define the variability estimator of node ni, and we denote it as V(n)as the standard deviation of the numbers of children of node niin the different pages of Dc. Based on these variability estimators, we define a process to generate XPath patterns. For each node niin the XPathTree, we check if its variability estimator is significatively high, and in that case, all its children nodes have their token replaced with a wildcard, and the subtrees rooted at them are merged. Contrarily, children of nodes with a low variability are probably part of a pattern, so they are not abstracted, but kept as literals. Our technique to mine relationships between classes aand bconsists of two steps: XPathTree building and XPathTree compressing. In the first step, we extract all URLs matching pattern Φ(b)in pages from Da, and we calculate an XPath locator for each of them. XPath locators are tokenised, and each token is inserted in an XPathTree as a node with a variability estimator. An example of an XPathTree built using this technique is presented in Figure 1a. It contains XPath expressions of URLs matching Φ(Author)in the running example, extracted from detail pages of class Author. In the second step, we apply a compressing algorithm that performs a depthfirst traversal on the XPathTree, and for each visited node, uses its variability estimator to discern nodes with a variability higher than a given parameter θ>0. Those nodes have their token abstracted into a wildcard (). As an example, nodes with variability higher than 0.5are presented in Figure 1b. After the whole tree has been traversed and processed, each of the resulting tree branches represents a different pattern. Furthermore, each pattern refers to a different type of relationship between classes aand b.Asanexample,inFigure1c we show the example tree containing XPath expressions of links between class Author and itself, after processing all its nodes. The tree contains ten branches, which correspond to ten XPath patterns. At the end of this process, for each pair of classes aand b, we have obtained a set of XPath patterns, that represent the different relationships between them. These relationships are anonymous, and it is left to the user the task of labelling them with an appropiate name. Moreover, we have identified all the possible relationships, but some of them might be duplicated (i.e., we discover a relationship between aand b, which is the same as another relationship between band a). Therefore, the user has the opportunity to select the relationships that are most suitable for his or her model, discarding the rest. Therefore, although we are indeed automatically discovering the relationships between entities, the user still has the complete control over the final model. As an example, consider the former patterns discovered in Figure 1c. The first five patterns correspond to links to authors that co-author, respectively, the five most recent papers of an author. Meanwhile, patterns sixth to tenth correspond to links to authors of, respectively, the five most recent papers that cite the author. Therefore, the five first patterns correspond to a particular relationship between class Author and itself(isCoauthorOf), while the five last patterns correspond to a different relationship (cites). 4 Validation We present an experiment to validate our technique. Microsoft Academic Search was analysed to discover the conceptual model behind it, by means of two steps: in the first step, we discovered the entities in the model, using the URL patterns obtained with the technique described in [10]; in the second step we discovered the relationships between these entities, with the former URL patterns as input, and using the technique described in this paper. We show the relationships discovered for this site in Figure 3a, using a UML class diagram. After the intervention from the user, a possible model obtained from the former relationships is presented in Figure 3b. For example, relationships r3,r4,r5,r6and r7, represent respectively the co-authors of the most recent paper of an author, the co-authors of the second most recent paper, and so on. The user analyses these relationships and decides that all these relationships are actually the same, and labels it isCoauthorOf. Using our technique, it is also possible to infer hierarchical relationships between classes, by identifying classes that share a common group of relationship with other classes. For example, in the former example model for MsAcademic, classes Journal and Conference both share exactly the same types of relationships (Journal is related to Paper by means of r23 and r24, to Author by means of r1 and r2 and to Citations by means of r19 and r20. Similarly, Conference 000000000000000000000000000000000000000000000000000000000 0 000000000000000000000000000000000000000000000000000 00000 0 000000000000000000000000000000000000000000000000000 00000 0 000000000000000000000000000000000000000000000000000 00000 000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000 Author 000000000000000000000000000000000000000000000000000000000 0 000000000000000000000000000000000000000000000000000 00000 0 000000000000000000000000000000000000000000000000000 00000 0 000000000000000000000000000000000000000000000000000 00000 0 000000000000000000000000000000000000000000000000000 00000 000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 Paper 0000000000000000000000000000000000000000000000000000000000 0 0000000000000000000000000000000000000000000000000000 00000 0 0000000000000000000000000000000000000000000000000000 00000 0 0000000000000000000000000000000000000000000000000000 00000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 Journal 00000000000000000000000000000000000000000000000000000000000000 0 00000000000000000000000000000000000000000000000000000000 00000 0 00000000000000000000000000000000000000000000000000000000 00000 0 00000000000000000000000000000000000000000000000000000000 00000 00000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000 Conference 000000000000000000000000000000000000000000000000000000000 0 000000000000000000000000000000000000000000000000000 00000 0 000000000000000000000000000000000000000000000000000 00000 0 000000000000000000000000000000000000000000000000000 00000 000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 Citation r3, r4, r5, r6, r7 r 8, r9, r10, r 11, r 12 r16 r15 r14 r13 r1 r2 r23 r24 r22 r21 r18 r25 r17 r19 r27 r28 r29 r26 r20 (a) Relationships for MsAcademic 000000000000000000000000000000000000000000000000000000000 0 000000000000000000000000000000000000000000000000000 00000 0 000000000000000000000000000000000000000000000000000 00000 0 000000000000000000000000000000000000000000000000000 00000 000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 Author 0000000000000000000000000000000000000000000000000000000000 0 0000000000000000000000000000000000000000000000000000 00000 0 0000000000000000000000000000000000000000000000000000 00000 0 0000000000000000000000000000000000000000000000000000 00000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 Paper 0000000000000000000000000000000000000000000000000000000000 0 0000000000000000000000000000000000000000000000000000 00000 0 0000000000000000000000000000000000000000000000000000 00000 0 0000000000000000000000000000000000000000000000000000 00000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 Journal 000000000000000000000000000000000000000000000000000000000000000 0 000000000000000000000000000000000000000000000000000000000 00000 0 000000000000000000000000000000000000000000000000000000000 00000 0 000000000000000000000000000000000000000000000000000000000 00000 0 000000000000000000000000000000000000000000000000000000000 00000 000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000 Conference 0000000000000000000000000000000000000000000000000000000000 0 0000000000000000000000000000000000000000000000000000 00000 0 0000000000000000000000000000000000000000000000000000 00000 0 0000000000000000000000000000000000000000000000000000 00000 0 0000000000000000000000000000000000000000000000000000 00000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000 Citation isCoauthorOf cites authorsCiting writes / isWrittenBy publ ishesI n / i ncludesPubl icat ionFrom publ ishedI n / i ncl udes cites publi shedI n / i ncl udes has / r efer ences cites / hasCitations c i tes / has Citati ons publ ishesI n / i ncludesPubl icat ionFrom (b) Model for MsAcademic Fig. 3. Model discovered for the validation site is related to the same set of classes, with two relationships with each class). Therefore, our technique proposes the user the generalisation of Journal and Conference into another class, and lets the user name it (e.g., Host). 5 Conclusions In this paper, we present a technique to discover the conceptual model behind a web site in the Deep Web. Using a set of URL patterns as input, we use a statistical approach to discover all the different relationships between those entities. These relationships can be later analysed by the user, who is responsible for labelling them appropriately, and selecting those relationships that are useful for his or her particular model. We validate our proposal using a well-known academical web site, Microsoft Academic Search. Other proposals have dealt with the problem of discovering the model behind a web site. Some of them discover models composed only of entities, neglecting the discovery of relationships, which we deal with. Others are supervised, which require expert knowledge from the user, while our technique is completely unsupervised. Finally, other proposals discover only one view of the conceptual model, which corresponds to a particular template; contrarily, we discover a