Detection of Related Semantic Datasets Based on Frequent Subgraph Mining
•Als PPTX, PDF herunterladen•
0 gefällt mir•410 views
This document proposes a method to detect related semantic datasets based on frequent subgraph mining. The method extracts the most frequent subgraphs from RDF graphs using the SUBDUE algorithm. These subgraphs are then matched across datasets to identify potential links. The method is evaluated against gold standard links and baselines, showing precise but limited recall. Future work to improve recall is discussed, such as using string similarity techniques.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Ähnlich wie Detection of Related Semantic Datasets Based on Frequent Subgraph Mining
Ähnlich wie Detection of Related Semantic Datasets Based on Frequent Subgraph Mining (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Detection of Related Semantic Datasets Based on Frequent Subgraph Mining
- 1. Detection of Related Semantic Datasets Based on Frequent Subgraph Mining Mikel Emaldi1, Oscar Corcho2, and Diego López-de-Ipiña1 1 Deusto Institute of Technology - DeustoTech, University of Deusto, Bilbao, Spain {m.emaldi,dipina}@deusto.es 2 Ontology Engineering Group, Departamento de Inteligencia Artificial, Facultad de Informática, Universidad Politécnica de Madrid, Spain ocorcho@fi.upm.es
- 2. Table of Contents 1. Introduction 2. State of the Art 3. Proposed solution 4. Evaluation 5. Conclusions 6. Current & Future Work 2
- 3. May, 2007 Evolution of the LOD Cloud 3
- 4. August, 2014 Evolution of the LOD Cloud 4
- 5. Introduction • The LOD Cloud has grown enormously. • Difficulties when… • … exploring data provided by different datasets. • … selecting from which dataset we want to browse data. • … trying to avoid overlapping existing data. • … finding other datasets for interlinking our dataset. 5
- 6. My New Dataset Linking Framework ● Silk ● Limes ● ... Links The problem of selecting linking sources ? 6
- 7. State of the Art I • Nikolov, A., d’Aquin, M.: Identifying relevant sources for data linking using a Semantic Web index. In: Proceedings of the Linked Data on the Web workshop in conjunction with the 20th international World Wide Web conference. vol. 813 (2011). • Extract literals from rdfs:label, foaf:name or dc:title properties and search them in Sig.ma, grouping the results by source dataset. • More results a source has, more chances to be linked with the original dataset. 7
- 8. State of the Art II • Leme, L.A.P.P., Lopes, G.R., Nunes, B.P., Casanova, M.A., Dietze, S.: Identifying candidate datasets for data interlinking. In: Proceedings of the 13th International Conference on Web Engineering. pp. 354– 366. Springer (2013) • Naive Bayes classifier for establishing a ranking of related datasets based on correlations among them for reducing the search space. • These correlations are based on existing links. 8
- 9. State of the Art III • Lopes, G.R., Leme, L.A.P.P., Nunes, B.P., Casanova, M.A., Dietze, S.: Recommending tripleset interlinking through a social network approach. In: Proceedings of the 14 th international conference on Web Information Systems Engineering. pp. 149–161. Springer (2013) • They use already existing links for establishing new links among datasets. 9
- 10. Proposed Solution I • Our goals: • Do not use literals because they are a scarce resource. • Do not use already existing links • Trying to solve the cold start problem. 10
- 11. Proposed Solution II • A solution based on the graph structure of the datasets. • Hypothesis: Given a set of datasets from the Semantic Web, candidate datasets to be interlinked can be found through the comparison of their structures. 11
- 12. But... ...some datasets are incredibly large!!! 12
- 13. Proposed Solution III http://datahub.io/dataset/nytimes-linked-open-data triples > 345,000 http://datahub.io/dataset/rkb-explorer-acm triples > 12,000,000 http://datahub.io/dataset/rkb-explorer-dblp triples > 24,000,000 13
- 14. Proposed Solution IV • Extract the most frequent subgraph from each graph. • Summarizing the graph. • Easing the matching task among graphs. • Subgraphs are smaller. • The FSM task only has to be launched once per graph (until the graph is modified). 14
- 15. Proposed Solution - Frequent Subgraph Mining I • Main objective: to extract the most frequent subgraphs from a single graph or a set of graphs. • According to the state of the art [1], four characteristics define a FSM tool: • Single graphs vs. transactions: ability for extracting the most frequent subgraphs from a single graph or from a set of graphs. • Directed graphs: ability for dealing with directed graphs. • Labeled vertices and/or edges: ability for dealing with graphs including labels in their vertices and/or edges. 15
- 16. Proposed Solution - Frequent Subgraph Mining II Solution Single Graph / Transactions Directed Graphs Labeled Vertex Labeled Edges Subdue Single Graph ✔ ✔ ✔ AGM Transactions ✔ ✔ ✔ FSG Transactions ✖ ✔ ✔ DP Mine Transactions ✔ ✔ ✔ MoFA Transactions ✖ ✔ ✖ gSpan Transactions ✖ ✔ ✔ FFSM Transactions ✖ ✔ ✔ GREW Single Graph ✖ ✔ ✔ Gaston Single Graph ✖ ✔ ✔ gApprox Transactions ✖ ✖ ✖ (h/v)Sigram Single Graph ✖ ✔ ✔ 16
- 17. Proposed Solution - SUBDUE • SUBDUE defines the most frequent subgraph as the subgraph that once replaced by a single node, most compresses the original graph. • G → original graph and S → candidate subgraph: • Where: 17
- 18. Proposed Solution - From RDF to SUBDUE • Some transformations in the RDF graphs before applying FSM. • Transformation I: replacing URIs from subjects by the rdf:type of each resource. • Transformation II: removal of external links. 18
- 19. Proposed Solution - From RDF to SUBDUE II 19
- 20. Proposed Solution - From RDF to SUBDUE III 20
- 21. Proposed Solution - Most frequent subgraph extraction & matching • Application of SUBDUE for extracting most frequent subgraphs. • Application of SUBDUE’s Graph Matcher (gm) tool for matching extracted subgraphs. • Computes the cost of transforming one subgraph on another subgraph. • Cost of all transformations = 1. 21
- 22. Evaluation • Efficacy of the system. • Gold Standard. • Baselines. • Results. 22
- 23. Evaluation - Gold Standard • Two different sources: • Already existing links extracted from the DataHub through the property links:<target_dataset_id>. • Some obvious links do not exist!! • Survey different researchers on Semantic Web and Linked Data. • They evaluate pairs of dataset determining the possibility of establishing links between them. • Each pair has been evaluated by almost three researchers. 23
- 24. The survey arises a new problem… 24Too many combinations!!!
- 25. Evaluation - Gold Standard - Survey • Reduction of the search space inspired by [2]: • Reduction from 7,038 evaluations to 594. • Agreement according to Fleiss’ Kappa: 41% → Moderate agreement (according to Landis & Coch). 25
- 26. 26 Survey
- 27. Evaluation - Baselines Three baselines: Baseline #1: common ontologies. As more common ontologies have two datasets, more chances to establish links between them. Baseline #2: ontology ranking. As more common ontologies with similar usage have two datasets, more chances to establish links between them. Baseline #3: common triples. As more common triples (predicate and object) two datasets have, more chances to establish links between them. 27
- 28. Evaluation - Results I 28
- 29. Evaluation - Results III • Possible over-fitting of Baseline #1. • As can be seen in http://apps.morelab.deusto.es/iesd2015/datasets.csv, many of used datasets are from RKB Explorer. • Same ontologies, same model, etc. • Many datasets from the LOD Cloud are offline: • No RDF dump. • No SPARQL endpoint. • A cleaning is needed!! 29
- 30. Conclusions & Future Work • Precise recommendations, but improvable recall. • Recommendations done are OK, but they are not enough. • Future work: • String similarity techniques. • Recall improved ≳ [0.10, 0.30] • Include generated recommendations into the workflow. 30
- 31. Detection of Related Semantic Datasets Based on Frequent Subgraph Mining Mikel Emaldi1, Oscar Corcho2, and Diego López-de-Ipiña1 1 Deusto Institute of Technology - DeustoTech, University of Deusto, Bilbao, Spain {m.emaldi,dipina}@deusto.es 2 Ontology Engineering Group, Departamento de Inteligencia Artificial, Facultad de Informática, Universidad Politécnica de Madrid, Spain ocorcho@fi.upm.es
- 32. Credits Images: http://lod-cloud.net/ https://www.flickr.com/photos/ramv/10057168055 Bibliography: [1] Jiang, C., Coenen, F., Zito, M.: A survey of frequent subgraph mining algorithms. The Knowledge Engineering Review 28(1), 75–105 (2013). [2] Fetahu, B., Dietze, S., Nunes, B.P., Casanova, M.A., Taibi, D., Nejdl, W.: A scalable approach for efficiently generating structured dataset topic profiles. In: The Semantic Web: Trends and Challenges, pp. 519–534. Springer (2014). [3] LANDIS, J. R. y KOCH, G. G. The measurement of observer agreement for cate- gorical data. biometrics, pa ́ginas 159–174, 1977. 91 32
Hinweis der Redaktion
- Good afternoon. My name is Mikel Emaldi, from University of Deusto in Bilbao, and I’m going to present our work named “Detection of Related Semantic Dataset Based on Frequent Subgraph Mining”.
- This is the script of this presentation; as can you see is a very typical script.
- At first I’m going to introduce the problem that we have tried to solve through this work. As you know his is the first snapshot of the Linked Open Data Cloud at its early years. As can be seen there were few datasets, and it could be explored with the naked eye; you didn’t need much help to understand the datasets in this version of the LOD Cloud.
- But, since 2007 the LOD Cloud has grown, it has grown enormously, and we hope that it is going to grow more and more. Today, you need some help to explore the whole cloud; you can’t look for desired datasets with the naked eye, it’s harder to search for some data inside this cloud.
- As I have said, the actual size of the cloud is a problem when we want to explore data provided by different datasets; or when we have to select from which dataset we want to browse this data; or if we are trying to avoid an overlapping of our new data with already existing data; or, and this is the focus of our work, when you want to find some datasets related to yours for interlinking your datasets with these other datasets already existing in the LOD Cloud.
- This is a representation of the problem: you have created a new dataset, and you want to link your dataset with other, using a linking framework like Silk, Limes, or whatever system you want; and now, exploring the LOD Cloud is very hard. It’s going to take you a lot of time and efforts.
- There are few works, at our best knowledge, that deals with this problem. One of them is this work by Andriy Nikolov. In this work they take a graph and they extract literals from some properties of this graph, for example rdfs:label, foaf:name or dc:title and they make a search of these literals in Sig.ma. After that, they group the results given by Sig.ma by the source of each result. The source that has more results, has more chances to be linked with the original dataset.
- Another work is the one from Luiz André Paes Leme. I this work they use a Naive Bayes classifier for establishing a ranking of related datasets based on correlations among them for reducing the search space.
- The last one that we have found is the work by Giseli Rabello Lopez. In this work, basically and explaining it quickly, they use already existing links for establishing new links among datasets.
- After analyzing the state of the art, we wanted to propose an alternative solution; an alternative without using literals, and without using already existing links, as the previously shown works do. And, why? In the of literals, because they are a scarce resource; usually literals are not long enough to do a complex analysis; you can find a lot of n-grams (for example name “Mikel, surname “Emaldi”) but you can’t usually find long text in this literal properties of the RDF graphs. And why didn’t we want to avoid the already existing links? Because, maybe, not in the LOD Cloud, but in another scenario, we may have to deal with a set of datasets without any links. And if there are no links, we can’t apply a solution based on already existing links. We have try to solve the cold start problem.
- And finally, we have think about a solution based on the graph structure of the datasets. Our main hypotheses is that a set of datasets from the Semantic Web, candidate datasets to be interlinked can be found through the comparison of their structures. Our idea was that, analyzing the structure of the graphs we could find some similarities among them, and some clues indicating that these graphs could be interlinked in some way.
- But, this solution raises a big problem: some datasets are too large to make a direct comparison among their structure.
- For example…. A direct match is impossible because the graphs formed by these datasets are too large.
- For dealing with this problem, we have proposed to extract the most frequent subgraph from each graph. This way, we can summarize the graph, easing the matching task among these graphs, because the subgraphs are smaller and you can match them easily. Well but, you maybe are wondering about, “well the frequent subgraph matching task is computationally expensive, you have to process the same big graphs”. But, the frequent subgraph mining task only has to be launched once per graph, and the extracted subgraph is valid for matching with all the new graphs introduced in the LOD Cloud.
- Some basic hints, about the frequent subgraph mining. It’s a technique widely used in biology and chemistry; and it consists on extracting the most frequent subgraphs from a single graph or from a set of graphs. According to the state of the art, there are four characteristics which define different FSM tools: Some tools extract most frequent subgraphs from a single graph and other tools are developed for extracting most frequent subgraphs from a set of different and independent graphs. On the other hand, there are tools that can not deal with directed graphs; dealing with directed graphs is computationally more expensive. And at last, some tools can not deal with graphs which contains labels in theirs vertices or edges.
- According to the RDF model, the graphs are directed, and they have labels in their vertices and edges. For this reason, among all the tools that we have analysed the only candidates to be used in this work are SUBDUE and DPMine. But, because our proposed solution deals with single graphs, we have chosen SUBDUE for extracting the most frequent subgraphs.
- SUBDUE works this way: it defines the most frequent subgraph as the subgraph that once replaced by a single node, compresses most the original graph. This formula shows the total compression rate, where size(G) is the size of the whole graph; size(S) the size of the candidate subgraph that it is being evaluated, and size(G|S) is the size of the original graph if the candidate subgraph is replace by a single node.
- Returning to our solution, before applying SUBDUE to RDF graphs, some transformations have been done to these graphs. The first transformation consists on replacing the URIs from resource’s subject by their rdf:type properties. We have decided to do this because as each resource in a Linked Dataset has its own an unique URI, these nodes never could be form part of a most frequent subgraphs; because there are as many URIs as resources are in the graph. For example, given this example, and its graph representation [CHANGE SLIDE] The second transformation concerns to external links included in a graphs. Despite we know that these external links could provide useful information for fulfilling our task, we have discarded them for two reasons: the first is that in addition to the computational cost that would include these external links, the cost and the time expended by retrieving them through the net has to be added to the total cost of processing a graph. The second reason is that one of our goals was to trying to solve the cold start problem, and we have preferred to work on an sceneario without external links.
- … we can see how the original graph has been transformed into a new graph, but describing it in more generic way. In the original graph we can see that it is describing Tim Berners Lee his publication “The Semantic Web”, and in the transformed graph we can see that it is describing a person an one of its publications. [GO BACK].
- Here we can see the result of the exaple graph without the external links.
- The next step is to apply SUBDUE for extracting the most frequent subgraphs. Here you can see an example of a SUBDUE file: each vertex has a unique ID and immediately the edges have to be defined. These files, because the size of some graphs, are split in chunks, and analysed incrementally; this is a feature of SUBDUE. Once the most frequent subgraphs are extracted, these subgraphs are matched with SUBDUE’s Graph Matcher tool. This tools performs a very simple matching; it consist on computing the cost of transforming one subgraph in another subgraph. In this case, also, the transformation cost of all operations (creation, modification and deletion of a vertex or an edge) have the same cost. At last, the similarity ratio between datasets is calculated.
- Once our solution has been explained, it’s time to show the evaluation results. At this evaluation we have developed a gold standard and a set of baselines for evaluating our work.
- For developing the Gold Standard, two sources have been used. The first one is the profile of each dataset in the DataHub. One of the requirements to be in the LOD Cloud is the description of the links that a dataset has. Through its API we have retrieve these links to establish wich datasets are linked together. But, there was a problem: some obvious links do not exist; maybe because the publisher of the dataset did’t review his or hers dataset for looking for new related datasets, we don’t know. But this issue produced a lot of false positives in our system. For solving this issue, a survey have been done to sifferent researcher on Semantic Web and Linked Data. These researchers have been surveyed about the possibility of establishing links among different pair of datasets.
- But, again, the same problem. There were a lot of combinations to be evaluated by these researchers. The truth is that we have not used all datasets from the LOD Cloud to evaluate our system, but there were a lot of combinations at all.
- For solving this problem, based on another work, we have try to reduce the set of links to be evaluated. We have applied the evidence depicted in this figure: we asume that if two datasets share common links to another datasets, they could be linked. Ok, here we can see that datasets A, B, C and D share links with datasets I, F, E, H and G, so that, we can conclude that there are high chances to establish links among these datasets. Applying this method we have reduced the number of evaluations from more than 7,000 to around 600 evaluations. Once the survey has been done, an agreement of 41% have been achieved that it is a moderate agreement according to [3]. Maybe a more agreement could be achieved with a more exhaust definition of the question. Some surveyed researched declare that sometimes they have doubts about some pair of datasets because they thought that they were thinking about very complex relationships between these datasets.
- Here you can see the survey, its a very simple web page in which the title and a description of the dataset, along with an example resource an its DataHub URL (if the want more information) can be seen.
- .These baselines are simple solutions to the proposed problem which allow measuring how better is our solution. The first baseline is based on the assumption that if more shared ontologies two datasets have more similarities are between them and more chances to be interlinked they have. This concept is represented through THIS score, beign N1 and N2 the set of ontologies from Dataset1 and Dataset2, respectively. The second baseline computes the similarity between a pair of datasets based in ontologies used to describe them but it also takes into account the ranking of usage of each ontlogy. This usage is computed through the sum of the properties and classes of an ontology used in a dataset. The similarity between rankings is computed through the Kendall’s Tau, where Tau1 and Tau2 are the rankings and n is the size of the rankings. According to Kendalls Tau, if the ith element and jth element of the ranking is the same element, K returns 0; if not returns 1. At last, the third baseline assumes that as more common triples two datasets have, we have more chances to establish links between them. In this baseline the subjects of resource’s has been removed, because according to Linked Data paradigmn they are unique.
- Here the results of the evaluation are shown. As can be see, the precision of the proposed solution is high enough to consider this solution as a valid solution, but, on the other hand, the recall shows that we have to work harder for improving these results.
- Well, regarding to the good recall obtained by the first Baseline [SHOW RESULT], there is a possible over-fitting of the results. One reason of this over-fitting could be the high number of datasets belonging to RKB Explorer used in the evaluation. These datasets use the same ontologies, the same model, etc. When we have try to make a more heterogeneous, we have found many datasets from the LOD Cloud offline, without RDF dump and without SPARQL endpoint. For this reason, we think that it could be interesting to perform some dataset cleaning over the LOD Cloud. Well, but this is only a trouble that we had along this work and I think that it could be interesting to comment here.
- At last, and concluding this presentation, we can say that this work is able to get precise recommendations when recommending candidate datasets to be linked, but more work have to be done to improve the recall. In the future (or better, in the actual work), we are applying string similarity techniques for finding similarities among datasets described by different ontologies. As spoiler, we can say that the recall is slightly improved between a 10 and 30%, depending on the threshold. Another improvement that we want to do is about becoming the matching process iterative, including the recommendations done into the workflow.
- That’s all, thank you for your attention.