This paper describes a semi-automatic process for the semantic annotation of institutional non-RDF spatial datasets and their integration into an incrementally populated knowledge base. The knowledge base can serve as the organizational Spatial Knowledge Infrastructure which can be exploited for data querying and further integration purposes. The highlights of the process are the inclusion of analytical capabilities that produce annotation recommendations based on existing semantic knowledge for minimizing the user involvement during the semantification process, the dynamic and incremental building of the underlying schema based on the spatial datasets at hand, and the adoption of the RDF* model for maintaining triple-level metadata. This work is undertaken for the case of the University of the Aegean; however, the solution is generic and can be easily adapted by other organizations as well.
possibility for achieving semantic interoperability between spatial data that could potentially
unlock advanced capabilities for institutional data exploitation. A possible solution could be
the conversion of the (dispersed across the various sources) spatial datasets to a common data
representation format, such as the RDF, for the semantic representation and annotation of the
data and their metadata, and their publication to the web according to the linked data principles.
Such a process will provide additional capabilities for querying, integration and reasoning
among the institutional spatial data as well as with the entire Linked Open Cloud (LOD). As
[
Towards the goal of tabular data transformation to RDF, W3C outlines some approaches. On
one hand, the Direct Mapping Recommendation [
This paper describes the design and implementation of a semantification process that recommends annotations of spatial datasets based on existing semantic knowledge. The process acts like a semi-automated wizard, thus, it minimizes the human efort for semantification, while allowing users to intervene by defining alternative conversion options, such as the use of custom classes and predicates. The converted RDF graph, which consists of schema, feature and metadata triples, is fed in a knowledge base, which is the main knowledge source of the process. By this way, the process allows the interactive, dynamic and incremental building of organizational Spatial Knowledge Infrastructures (SKI) [8]. The process is designed to handle a variety of spatial dataset formats and to manage both geometric and thematic attributes. A highlight of the process is the generation of triple-level metadata according to the RDF* model [9], that allows the enrichment of feature triples with useful provenance information. The process is applied on spatial datasets maintained by the University of the Aegean, Greece. However, the solution is generic and can be easily adapted by organizations that manage spatial data and want to build their own SKI. The paper concludes with a discussion on the initial results and pointers for future work.
candidate primary keys is formed by integer and string columns that contain distinct not null values. String columns that contain large-length values are discarded from the list of candidate primary keys, since they usually provide additional verbal information about the geographic features. The analyzer then selects the most appropriate primary key column by giving priority to the candidate string columns. If no candidate columns are found, then no primary key column is selected. Second, the analyzer searches for columns with values that can be used later for assigning labels to features (using the rdfs:label predicate). The list of the candidate label columns is formed by string columns that contain small-length values. In addition, the analyzer tries to detect the language for each candidate label column. Third, the analyzer search for columns that will be blocked, i.e. not converted to RDF. The blocked columns list is formed by the label columns (because they are already annotated), by columns that may refer to foreign keys and by user-defined/selected columns. Possible foreign keys columns empirically set to be integer columns that contain not distinct values.
For the next step, the process annotates spatial data with suitable schema resources, extracted from an existing knowledge base. First, it tries to guess the type (class) of the spatial data by comparing the textual and semantic similarity between the spatial dataset name and existing classes in the knowledge base. For the textual comparison it applies the Levenshtein similarity and for the semantic the WordNet WuPalmer index. Classes that are similar above a certain threshold are ranked and the top-one is recommended to be used as the class for the spatial dataset. In case that no recommendations are generated, the user has the option to select another class from the knowledge base or to create a new class. In the latter case, the class will be added to the knowledge base and the user is opted to additionally provide a characteristic label and a description for the new class. The same procedure is applied to annotate the columns that will be converted (except for the label columns) with suitable predicates from the knowledge base. That is, the module searches for existing predicates with similar names to the column name and recommends them to the user. The user can keep the default recommendation, select an alternative predicate from the knowledge base or create a new predicate. In the latter case, the user is opted to provide a label and a description for the new predicate.
Finally, the spatial dataset is converted to RDF, containing triples about schema, features and metadata. Schema triples contain the definition of new classes and predicates that may have been created during the annotation step. Their URI is formed by the default base URI, the term “ontology” and the resource (class or predicate) name as depicted in Fig. 2a.
Feature triples contain the descriptions of spatial features. Specifically, each feature is assigned with a URI, formed by the default base URI, the term ‘resource’, the class name and the primary key value (Fig. 2b). If no primary key was found during the analysis step, a serial number is used. A feature (entity URI) is declared to be member (with the rdf:type predicate) of the annotated class and of the GeoSPARQL Feature class. Accordingly, the feature is associated with its labels using the rdfs:label predicate. For each of the rest columns, the feature is associated with the respective cell values using the annotated predicates. The feature’s geometry is represented according to the GeoSPARQL vocabulary in the WKT serialization, which additionally embeds the CRS code of the geometry. If the geometry is not projected in WGS 84, the geometry is reprojected to WGS 84 and is also represented according to the GeoSPARQL vocabulary. Finally, if the geographic feature is point, then the geometry is also represented according to the W3C Basic Geo vocabulary (long and lat predicates).
Metadata triples contain the dataset-level metadata that were extracted during the parsing step. Each converted spatial dataset is assigned with a URI formed by the base URI, the term metadata and a randomly generated ID (Fig. 2c). Each dataset entity is declared to be member of a SpatialDataset class and is associated with its metadata (e.g., dataset name, publisher, creation date, spatial extent) using fixed predicates from the Dublin Core vocabulary.
The converter associate feature triples with the spatial dataset entity URI from which they originate. By this way, the knowledge base maintains triple-level metadata, allowing users to gain knowledge such as who created a piece of information and when. To this end, the RDF* model is used with the following syntax: for each feature triple a new RDF* triple is created that in the subject position appears the triple itself, enclosed in ‘« »’, in the predicate position the ‘dc:source’ and in the object position the spatial dataset URI (Fig. 3).
The output of the process are files in RDF / RDF* serializations that can be directly imported in the selected knowledge base.
The semantification API is implemented in Java. The GeoTools and JTS libraries are used for spatial dataset parsing and geometric transformations and the Apache Jena framework is used for RDF modelling and for sending SPARQL queries to the knowledge base, which is selected to be a Fuseki instance. On top of the semantification API, three applications, which share the same functionality but serve diferent system requirements, were developed: a) a desktop command-line, b) a desktop GUI and c) a web application. Screenshots of the web application are depicted in Figure 4. The applications provide user-friendly interfaces and target users with at least an elementary knowledge about semantic web concepts and about the content of the underlying knowledge base. The applications provide default recommendations for each step of the process, however they allow users to intervene by editing dataset metadata, selecting diferent primary key, label and blocked columns and annotating with alternative classes and predicates. Moreover, users have access to generic process customization options such as, setting the URL of the default knowledge base, the base URI for annotation, the default output RDF serialization (e.g., RDF/XML, Turtle), and the CRS and spatial vocabulary (e.g., GeoSPARQL) that will be used for the geometric attributes transformation.
The semantification process was tested by converting more than a hundred spatial datasets to RDF and loading them to an initially empty knowledge base. The datasets are maintained by the University of the Aegean and stored in various institutional databases, SDIs and local computers. Since the current version of the applications support only shapefiles, the datasets were first converted to the shapefile format. Their thematic coverage span in several categories, including administrative units (prefectures, municipalities, etc), statistical indicators (population, GDP, etc), natural environment (rivers, volcanos, etc), natural phenomena (floods, earthquakes, etc), infrastructure (airports, hospitals, etc) and facilities (museums, schools, etc). Fig. 5 shows the semantification result for a ‘ports’ shapefile. Above is depicted the attribute table of the shapefile. Below is depicted the output, consisted of schema (lines 9-12), spatial dataset metadata (lines 15-23), feature (line 26-38) and RDF* triples (lines 40-44). For brevity, only the conversion for the Herakleion port and a subset of the RDF* triples are depicted.
This paper described a semantification process for spatial datasets. Its main features are the provision of easy-to-use tools that semi-automatically build incrementally a semantic knowledge base and the adoption of the RDF* model for providing triple-level metadata. The design and implementation of the process are still in progress, thus, next we summarize our so far experience and we outline the roadmap for the further development. An initial assessment of the process indicates that the design of the semi-automatic semantification wizard is intuitive and allows the completion of the process easily and in short time even by non-experts on semantic web. In particular, the annotation recommendations help users, without strong familiarity with the knowledge base content, to quickly determine the suitable classes and properties. Moreover, the process guarantees the instant population of the knowledge base with well-formed RDF that is ready to use. In the future, we plan to undertake more detailed experiments in order to evaluate the overall performance of the semantification process and its ability to populate high-quality semantic content.
As long as we are dealing with more spatial datasets, we will encounter with unseen disparities
that will be valuable input for designing more sophisticated rules for the dataset analysis and
the annotation steps of the process. For example, we may incorporate rules that better detect
primary and foreign key columns, block duplicate columns or identify specific-content columns
(e.g., telephones, emails) in order to annotate them with standard predicates from well-known
ontologies. Also, as long as the knowledge base is populating with data, it will become ‘smarter’
regarding the semantic annotation recommendations. In this respect, we plan to improve
recommendations by additionally employing instance-based methods that will recommend
classes and predicates based on the textual, semantic and spatial similarity. In addition, the
possibility of integrating APIs of third-party semantic web search engines (e.g., Linked Open
Vocabularies [10], GeoLOD [
This research was funded by the Research e-Infrastructure [e- Aegean R&D Network], which is implemented within the framework of the “Regional Excellence” Action of the Operational Program “Competitiveness, Entrepreneurship and Innovation”. The action was co-funded by the European Regional Development Fund (ERDF) and the Greek State [Partnership and Cooperation Agreement 2014–2020]. EDBT/ICDT 2014 Joint Conference (EDBT/ICDT 2014), Athens, Greece, March 28, 2014, volume 1133 of CEUR Workshop Proceedings, CEUR-WS.org, 2014, pp. 275–278. [7] C. Prudhomme, T. Homburg, J. Ponciano, F. Boochs, C. Cruz, A. Roxin, Interpretation and automatic integration of geospatial data into the semantic web, Computing 102 (2020) 365–391. [8] I. Ivánová, J. Siao Him Fa, D. A. McMeekin, L. M. Arnold, R. Deakin, M. Wilson, From spatial data to spatial knowledge infrastructure: A proposed architecture, Transactions in GIS 24 (2020) 1526–1558. [9] O. Hartig, P.-A. Champin, Metadata for rdf statements: The rdf-star approach, 2021.
URL: http://www.lotico.com/index.php/Metadata_for_RDF_Statements:_The_RDF-star_ Approach. [10] P.-Y. Vandenbussche, G. Atemezing, M. Poveda-Villalón, B. Vatant, Linked open vocabularies (lov): A gateway to reusable semantic vocabularies on the web., Semantic Web 8 (2017) 437–452. URL: http://dblp.uni-trier.de/db/journals/semweb/semweb8.html# VandenbusscheAP17.
Figure 5: Semantification result