This paper presents a server-side tool for constructing graph representations from a Linked Data for network analysis. The main features for the tool are: 1) Support to read data from a SPARQL endpoint, 2) easy adaptation to virtually any dataset and data model, and 3) easy usage in web portals for data analysis. The tool is in use. Visualizing a network provides new insights about its structure and the underlying data [10,9]. A network can be built from Linked Data (LD) publication using SPARQL [3], where extraction patterns [1] allow a researcher to extract various types of connections (links, edges ) between the nodes. Many portals in the domain of Digital Humanities use network visualizations for data analysis, such as Six Degrees of Francis Bacon3, Linked Jazz4, and the co-citation graph and correspondent network in ePistolarium5. LodLive6 allows the user to browse individual triples of a LD database. For front-end visualizations there are libraries such as Cytoscape.js7, D3.js8, Sigma9, and 3D Force-Directed Graph10 for rendering a network in 3D using WebGL. An overview of the evolution of LD visualization is presented in [8].
This paper introduces an online service, Sparql2GraphServer, for constructing
networks based on LD knowledge graphs. The tool facilitates constructing either
1) an egocentric network [
Backend Process The queries to the SPARQL endpoint are performed in the server side, and the process consists of three sequential steps. Firstly, a query for the network links is performed as a sequence of breadth-first searches until a desired amount of links is achieved. Secondly, the graph is constrained so that if the number of links exceeds the limit, the nodes having the lowest degrees are removed. This aims to retrieving more dense connections, e.g., a higher triadic closure between nodes of higher centrality measures, instead of start-shaped structures around a few central nodes. This pruning also aims to retrieving a more clustered graph structure to ease, e.g., the visual analysis. The constraining is optional and adjusting the query parameters allow for querying for an unfiltered graph, too. Finally, the node metadata is queried calculating simultaneously the predefined network statistics, e.g., the network diameter, average degree, and the total number of edges, nodes, and connected components.
The API query parameters are shown in Table 1; the queries are of the form https://example.org/query?links=""&nodes=""&limit=""&id="". Example queries using Wikidata are shown in Tables 2 and 3. The link query requests for teacher-student relationships starting from the sources nodes. In the query, the placeholder <ID> is replaced with a list of source set nodes, initially containing only the ego given with the query parameter id. The link weight is defined as the count of common occupations, fields of work, and academic memberships between two nodes.
Server Response The JSON-formatted server response is depicted in Table 4. The result field elements contains two arrays for edges and nodes. The API adds the data fields defined in the result clauses in the corresponding SPARQL queries to the result. The node data contains metrics like degree, in_degree, pagerank, and distance, e.g., the shortest path length from ego. Finally, the element metrics contains, e.g., network diameter, average degree, and the numbers of nodes, edges, and connected components for the entire network. The response format described is compatible with Cytoscape.js, a library for network visualization in a web portal. Furthermore, the application also supports the GraphML13 format.
Visualization in a Front-End Portal The API response can directly be an input for a Cytoscape.js component in a portal. Fig. 1 depicts a network 11 https://seco.cs.aalto.fi/projects/yo-matrikkelit/en/ 12 https://seco.cs.aalto.fi/projects/rrl/ 13 http://graphml.graphdrawing.org/ PARAMETER endpoint prefixes links nodes id limit format optimize DESCRIPTION
ego url for an egocentric network
TYPE required required required optional, default "" optional, default None optional, default 1000
} ?source ?rel ?target # links by common occupations, fields
of work, or memberships OPTIONAL {
VALUES ?prop
{ wdt:P101 wdt:P463 wdt:P106 } ?source ?prop ?link . ?target ? prop ?link } } GROUP BY ?source ?target ?label {’elements’: { ’edges’: [ {’data’: {’source’:
’www.wikidata.org/entity/Q9047’, ’target’:
’www.wikidata.org/entity/Q76510’,
’label’: ’doctoral student’,
’weight’: 7}
}, {’data’: ... }, ... ],
’nodes’: [
{’data’: {’id’:
’www.wikidata.org/entity/Q9047’,
’name’:’Gottfried Wilhelm Leibniz’,
’distance’: 0, ’degree’: 5, ’
degree_weighted’: 22,
’in_degree’: 0, ’out_degree’:5,
’in_degree_weighted’: 0,
’out_degree_weighted’:22,
’pagerank’: 0.01214}
}, {’data’: ... }, ... ] },
’metrics’:
{’average_degree’: 2.48,
’diameter’: 10,
’number_connected_components’: 1,
’number_of_edges’: 62,
’number_of_nodes’: 50},
’directed’: True
}
visualization based on the example result in Table 4. The node and edge labels
are extracted from the query results while the visual appearance is configured
in the front-side application code. Here the node color on a red-blue palette is
based on the path distance from the center node, the node sizes are based on the
out-degree, and the edge strengths on the count of common occupations, fields
of work, and academic memberships between two nodes as defined in the query
for edges (Table 2).
The tool Sparql2GraphServer is based on Flask14, microframework application
written in Python 3.8 using modules NetworkX 2.415 [
Integration to Sampo-UI Framework The Sparql2Network API is integrated
to the Sampo-UI Framework [
Evaluation Performing several SPARQL queries to the database might have longer request times, especially in cases of smaller extracted networks. An alternative would be using a single query empowered with, e.g., property paths or nested selection blocks. However, that approach is not guaranteed to perform in feasible time in a more complex case and would require customizing the queries for each specific database. The chosen solution to have a pair of simple and quick queries appears to be more efficient. A custom SPARQL query can adapt to cases 14 https://flask.palletsprojects.com/en/2.0.x/ 15 https://networkx.org/ 16 https://numpy.org/ 17 https://rdflib.readthedocs.io 18 https://rdflib.dev/sparqlwrapper/ 19 https://github.com/SemanticComputing/Sparql2GraphServer 20 https://akatemiasampo.fi/en/people/page/p21762/connections 21 https://akatemiasampo.fi/en/people/faceted-search/network where the linking property is not explicitly provided but reasoned from the data, e.g., a connection between two people who have lived in the same location at the same time.
Acknowledgements This work was funded by the Academy of Finland project SEMPARL, the EU project InTaVia22, and is related to the EU COST action Nexus Linguarum23. CSC – IT Center for Science provided computational resources for the work. Discussions with Mikko Kivelä, Javier Ureña-Carrion, Minna Tamper, and Esko Ikkala are acknowledged.