Data transformation from diverse formats to semantic data is a major challenge that is being addressed by commercial products available in the market to some extent. However, the transformation process still requires considerable e ort from users. Knowledge creation, which is one of the major steps in knowledge graph (KG) maintenance, needs existing data transformation from various formats to RDF (Resource Description Framework) data. Current data transformation approaches are either manual or through mappings. This work presents a semantic data transformation approach for knowledge creation that is semi-automatic requiring minimum possible input from users and does so with machine learning and natural language processing techniques.
With the emergence of the Semantic Web and Linked Open Data more and more
applications over the past decades have been developed to exploit semantic data.
Nevertheless, the vast majority of content published on the Web is not
represented in RDF and thus requires a transformation before being published. These
data integration issues are very common when working with data sources on the
web. There are several solutions to transform data into semantic data, most of
them being based on mapping solutions which can accurately generate semantic
data by writing scripts. But the writing of these mappings requires considerable
e ort from the share of quali ed users which makes each transformation time
consuming. They often require a speci c mapping language and the de nition of
rules for each data source which makes it time consuming and prone to human
error. Some solutions try to alleviate the expertise part by extending SPARQL
like SPARQL Generate [
To ease the creation of knowledge graphs from non-semantic data, we propose an approach combining natural language processing (NLP) and machine learning to allow for a more automatized transformation of data. 2
Over the past few years, more and more governments have started publishing their data for use by the public. These Open Data initiatives are done at every level of governments, from single cities to nationwide programs, and involve many di erent types of data. One of these is geographical data, often in the form of addresses and geographical locations of all sorts of places, such as named places, landmarks, residential buildings, or businesses. This data allows users to develop a variety of useful applications, with notable examples creating non-proprietary maps of the world such as OpenStreetMap, MapBox and others.
But currently the vast majority of data being published is not available as
linked data, OpenStreetMap(OSM) created the OSMOnto [
When a user wants to transform tabular data, the application lets her create entity types by selecting the columns she wants to see in the entity type. Here, an entity type is a table containing a number of columns that will be matched with a class from the ontologies known by the application. The columns under the entity type will be matched to properties associated with the class. That way when generating the RDF document, each row in the entity type's table will generate an instance of the class that matched the entity type and the values in this row's column will be used to generate the properties associated with that instance. The matching is performed between properties and columns. The average score for the matching between columns from a table and properties related to a class is then used as the score for the matching between the class and the table. 3.3
The NLP module matches properties and columns. It relies on Word2Vec [
The NLP module is essential to our process as it is the only one of our modules that can run without data from previous matchings made by the user. This allows us to make predictions on new data. Figure 2 shows how the NLP module scores the match between property 'thoroughfare' and a column named 'StreetName'. In our implementation we chose to use word embeddings trained on Google News articles3. When working on a speci c domain it may be bene cial to train word embeddings on domain speci c documents to ensure the recognition of some words and to prevent the semantics from common parlance from diluting the meaning of words in the domain. 3.4
The string module works by using predicates to establish the pro le of the strings in the name and in the content of attributes, each predicate tests a speci city of the string. For example does the string have numbers? special characters? less than X tokens? starts with the pre x X? It is with dozens of such predicates that we can determine a set of labels to represent a string. Each positive predicate generates a label. These labels are known by the module who assigns them weights from the strings that have previously matched each property. Figure 3 shows an example of some predicates that are generated for the shown data.
During its initialization phase, the module retrieves data from previous sessions, and measures the prevalence of each label for each property and compares it to the prevalence of that label in all of the other classes to determine the weight to give it. In general, the more a label is present in the strings of its property and the less it is present in the other properties, the greater its weight will be. A label that would be present in all strings would therefore indicate nothing and will have a weight of zero. From the best results of these modules
on each attribute of the entity, we determine a degree of certainty for the correspondence with this class. The class with the best certainty is kept and the properties which correspond best to its attributes are also preserved. These results are presented to the user who can change the results by choosing the class and properties herself if the results do not suit him. The numeric module uses the same mechanics as the string module but analyses the content of columns as integers, oats and doubles instead of simple strings. The predicates built by this module focus on the essential aspects of the numbers present in the column. For instance, the presence of negative values, oating values, and the range of values present in the column are signi cant information that help us make a clear distinction between concepts like a postal code and a latitude. The nal score for the matching between a property and a column is calculated by adding up the scores of the 3 modules. The score of the NLP module is divided by two in this step. This does not impact its performance in cases with no previous data as it is the only active module in these cases. This is done because we think the numeric and string modules make better matchings individually but the NLP module can still help break ties in ambiguous cases. 4
In this section, we present a preliminary evaluation of our solution. We are comparing our results to a well-established semantic data integration tool. 4.1
In this experimentation, our goal is to create RDF data from textual documents. We are considering location4and geo5ontologies. We will use these ontologies to represent addresses using their house street name(locn:thoroughfare), number (locn:poBox), full address (locn:fullAddress), postal code (locn:postalCode) and city name (locn:postalName). The geo ontology will be used to represent geographical points by using their longitude and latitude (geo:long, geo:lat).
We will translate data from four di erent open data projects from di erent countries. The "Base Adresse Nationale" (BAN6), a national project from the French government, and open data projects from Montreal7, Austin8and London9. We cleaned the data before translating it by separating the geographical information to form a "Geographical" table and an "Address" table and ignored data that we would not translate, like ids, keys and metadata from the original databases. The largest case was BAN, where only 7 of the original 20 columns were relevant for our ontologies. 4.2
Karma [
Since our objective is to automate the translation process, we measure the quality of our matching by counting the number of user interactions necessary to create linked data from a table. We increment the counter of user interactions when the proposed matching is incorrect. We count matching a property and a literal as "Assign Property" and matching between a property and a class as "Assign Relationship". Both Karma and our solution start the evaluation with no previous matches to learn from and the matchings expected are the same for both solutions.
Figure 4 details user interactions that were counted when translating data from the di erent sources into linked data. We reach an average of 0.45 user actions per column using our approach, compared to Karma's 0.68. We notice
9 https://www.w3.org/2003/01/geo/ 9 https://adresse.data.gouv.fr/donnees-nationales 9 https://donnees.montreal.ca/ville-de-montreal 9 https://data.austintexas.gov/Locations-and-Maps/ 9 https://opendata.london.ca/ that out of the 7 properties that we were matching with the data, 3 were found solely based on NLP in the rst dataset. 5
Most solutions for ontology matching and mapping are either mapping languages or transformation software. In both cases, they are oriented towards expert users like ontology experts. Karma stood out as it was trying to be accessible to anyone with an understanding of their data and their ontology with a semi-automated approach. We based the core of our approach on predicates inspired from their approach and expanded it by introducing NLP, the addition of NLP allows us to suggest mappings on properties and classes that have not been matched before. This was not possible with Karma as it needed data from previous matchings made by the user for a property before suggesting it in new matchings. The other addition we made to karma's process was to split predicates on content between string based predicates and numerical predicates. 6
We have proposed an approach to semi-automatically match non-semantic data with ontologies by using machine learning and NLP techniques to create knowledge graphs. We have demonstrated that combining di erent approaches, in particular NLP and string matching, improve the quality of our matchings. The quality of our matchings depends directly on the quality of the data we are matching and the quality of the data from the previous sessions. Data attributes using real life vocabulary can be directly used to suggest matchings with our NLP approaches whereas truncated words, acronyms are unusable. The more we use each ontology, the better the quality of our matchings.
Even though our process shows good results, it could be improved by extending its NLP approaches. In our evaluation several sources had their schemas in di erent languages which complicated the task of our NLP module as Word2vec must have seen the exact word being matched to give an answer. If we translated the names in the data's schema in a separate phase or if the NLP module was capable of doing it automatically, its results should improve signi cantly. The combination of the di erent modules itself could be improved by adjusting the weight of the di erent scores based on how accurate their predictions were for a given property in previous sessions. The model that we train will be made reusable and able to learn during sessions in future works, this will improve the quality of our matchings during the sessions themselves. In this paper our focus was on the quality of the matchings, this focus however came at a cost when it comes to memory consumption and processing power, work will be needed to optimize our approaches to handle larger amounts of data. The full integration of the graphical user interface and the extension of its functionalities will be essential. We are working towards the development of a full application.