Graphs with Free Software

Abstract

We present an Open Source base platform for theCoyPu knowledge graph project in the resilience domain. We report on our experiences with several tools which are used to create, maintain, serve, view and explore a modular large-scale knowledge graph, as well as the adaptions that were necessary to enable frictionless interaction from both performance and usability perspectives. For this purpose, several adjustments had to be made. We provide a broad view of diferent programs which are of relevance to this domain. We demonstrate that while it is already possible to achieve good results with free software, there are still several pain points that need to be addressed. Resolution of these issues is often not only a matter of configuration but requires modification of the source code as well.

1. Introduction

Semantic knowledge graphs (KGs) nowadays not only have become a key asset for search engines but are at the centre of numerous applications, for instance, in data analytics, question answering, recommendation systems, and decision support.

Current interest from research communities as well as industries and administration rests on the capability of KGs to capture comprehensive machine-readable knowledge in application scenarios and their strengths in integrating, managing and exploiting information from heterogeneous data sources at scale. One especially interesting application scenario for KGs is crisis and resilience research. Semantic KGs can play a crucial role in increasing transparency of, for instance, economic value chains and in understanding the complex mechanisms of crisis factors at a global level.

Although methodologies and strategies for building knowledge graphs vary based on the specific conditions and requirements of individual use cases, the creation, utilisation, and maintenance of KGs involve several common necessities and corresponding implementation phases. These processes have been discussed for more than twenty years [ 1, 2, 3, 4 ]. While general approaches for KG development and maintenance are proposed, limited guidance regarding the selection of eficient tools for implementing these methodologies is available. CEUR

Knowledge graph engineering must address additional challenges in today’s rapidly evolving landscape. Firstly, contemporary knowledge graphs should adhere to Linked Open Data requirements, such as the FAIR [ 5 ] data principles (Findable, Accessible, Interoperable, and Reusable) and the 5-star Open Data Model.1 These standards ensure that the resulting knowledge graphs can be easily discovered, understood, and integrated with other datasets, promoting data sharing and collaboration across various domains. Secondly, knowledge graph engineering projects often involve teams with diverse backgrounds and expertise levels in ontology authoring. Consequently, the tools used for KG engineering must cater to both ontology experts and domain-specific specialists, facilitating efective real-time collaboration and allowing all team members to contribute meaningfully to the development and maintenance of the knowledge graph.

We aim to create a knowledge graph-based platform for managing and exploring supply chain data. The platform will ofer customised views for scientists, engineers, and decision-makers to foster collaboration and interaction with the knowledge graph. Our goal is to enable users to analyse complex data, make informed decisions, and contribute to a resilient economy.

2. Related work

Recent studies [ 6, 7, 8, 9, 10 ] have shown that there are many diferent approaches for building specific KGs. Limitations are often faced regarding the approaches’ scalability, metadata and ontology management, entity resolution and fusion, incremental updates, and quality assurance [ 11 ].

While certain commercial tools like metaphactorya or the Enterprise Knowledge Graph Platformb claim to ofer comprehensive, all-in-one solutions, free and open-source alternatives often only address specific aspects. Consequently, users seeking to employ free and open-source tools must combine multiple applications and platforms to arrive at a complete knowledge graph platform.

When embarking on the creation of a custom stack for knowledge graph and ontology engineering, a valuable starting point for discovering relevant tools are link collections. Two notable lists in this domain include the Awesome Knowledge Graph2 and the Awesome Semantic Web3 repositories on GitHub. However, it is crucial to be aware that despite being curated, these lists may still sufer from link rot, leading to outdated or non-functional resources. The previously popular list hosted on the W3C website4 is rather outdated, with only 4 out of 21 listed tools still operable at the time of writing in the category of “RDF or OWL browser” (LodViewc, Rhizomer [ 12 ], Structured Data Linter, and VocBench [ 13 ]). Refer to Table 1 for an overview of the tools mentioned in this paper.

1https://5stardata.info/ 2https://github.com/totogo/awesome-knowledge-graph 3https://github.com/semantalytics/awesome-semantic-web 4https://www.w3.org/2001/sw/wiki/Category:RDF_or_OWL_Browser

T-Box

Widoco

View Source

Protégé

OWL RDFS

RDF

Shacl DALICC Apache Jena Fuseki A-Box

Ontodia Linked Data Viewer tarql RPT

3. Solution and other tools

In the following, we will show how we tackle the previous concerns with free and open-source tools. Our solution and the utilised tools are shown inFigure 1.

Ontology authoring. Part of creating knowledge graphs involves creating a schema (ontology) for your data. We used the venerable Protégé [ 14 ] for this purpose. We looked but failed to find other comparable OWL 5 authoring tools. While working on the ontology together with the partners, we found the best working approach to discuss one step of ontology evolution in a group and then designate one person to implement the change. Afterwards, the change could be reviewed on a source code control system. For the latter, it should also be ensured that all engineers are using the same version of Protégé, this will ensure that the textual diference of changes to the ontology is minimal and limited to the actual changes implemented. whenever the ontology files are changed in the Git source code repository on GitLab.6 ult on ‹https://schema.coypu.org/›. We have created a pipeline that updates our documentation 5Web Ontology Language, https://www.w3.org/TR/owl2-overview/ 6Source code for the pipeline script ongitlab.com/coypu-project/coy-ontologyin the supplements folder n o i t a c i f i c e y g o n O

another organization. p Term status S tlo has super-classes

Company c identity militiasc t Simofan Bin et al. CEUR Workshop Proceedings r D IRI: https://schema.coypu.org/global#Customer

CoyPu graph: Not currently in use An organization that sources something needed such as a product or service from IRI: https://schema.coypu.org/global#IdentityMilitias Term status Term rationale

CoyPu graph: In use, distinct subjects: 7977 CoyPu graph: ---USED BUT NOT IN ONTOLOGY--back to ToC or Class ToC

1–13 back to ToC or Class ToC in the ontology, whereas the term “Customer” is contained in the ontology but not (yet) used in the knowledge graph. Calculation of the usage statistics is done using the RDF Processing Toolkit (RPT)g with a set of VoID [ 17 ]-generating SPARQL queries.7

Automated pipelines that run automatically whenever changes to your ontology are committed to a source code control system, require integration with the source code control system. There are two common ways to realise pipelines. One is to use the platform-specific CI/CD pipelines,8 the other is using a Webhook event9 to trigger the start of an external pipeline.

To further increase the quality of our ontology, we have started to implement RDFUnit 1[ 8 ] rules that check the ontology details and version. Another standard with growing adoption is the Shapes Constraint Language (SHACL),10 which might be validated for example using pySHACL [ 19 ] or Jena SHACLh.

Mapping structured data to RDF data.

A big part of our knowledge graph is not our

original creation, but rather the mapping and integration, combination, and refinement of existing data sources. Most of the data sources we used are structured data, for example in XML, GML, JSON, CSV formats or data returned by Web APIs. Other parts of the data were also extracted and semantified from unstructured or semi-structured data like news articles.

Several diferent tools were used by the diferent project partners, for example Tarql i, RPT or Morph-KGC [ 20 ]. Each tool was chosen by the familiarity of the expert user and applicability to the data source that is to be mapped. Tarql for instance is an excellent choice to map CSV to RDF. RPT on the other hand can easily process CSV, JSON, and XML input files as well as web APIs and remote services using SPARQL, and Morph-KGC can map CSV or connect to SQL databases using RML. such functions using either JavaScript or Java annotations1.1 We also tested some commercial web-form based mapping editor, but found it to be rather cumbersome when having to edit and refine the mappings compared to a good old programmers’ text editor.

Further tools used by our partners include Named entity recognition from text using Falcon 2.0 [ 24 ] as well as many custom-written programs.12 For some of these, the Python RDFLibj was a popular choice when producing RDF data.

Dereference and visualise the Graph. In our experience in the CoyPu project, we found it extremely helpful to grasp the Semantic Web concepts when the IRIs are dereferenceable, i.e. you can open the IRIs of your graph entities in the browser. Users and experts alike want to see and understand what is “in” the graph. The classes and properties are dereferenceable through the use of Widoco and publishing the ontology documentation at the same location as the Ontology IRI. To make the data dereferenceable and browseable, tools like Trifid k and LodView can be used. It was easy to start Trifid with the Docker image provided by the authors. However, the default view is a bit bland. There is a great overview of tools presented in [ 25 ], but we found that at the time of writing only LodView and Trifid were still available. 9https://progrium.github.io/blog/2007/05/03/web-hooks-to-revolutionize-the-web/ 11https://docs.oracle.com/javase/6/docs/technotes/guides/language/annotations.html 12https://docs.coypu.org/ExternalRepositories.html

Linked Data Viewer Greece + − ▨ rdf: type ▨ geo: hasGeometry

Leaflet | © OpenStreetMap https://data.coypu.org/country/GRC ▨ : country/GRC/geometry ▨ : country/GRC/geometry/boundary Resolve labels en

Calculate inferences Local Browsing | Explore | Link ▨ rdfs: label

Greece @en

Our solution for IRI dereferencing (see Figure 3) is built on top of the Trifid rendering componentl. Compared to Trifid, we have extended the code for full client-side querying, a map widget for resources with geospatial data, rendering of inverse relations (similar to LodView), source attribution (useful to know which data set the entity is from), lazy pagination for many property values, label resolution and language switching, colour cards for namespaces and optional inferencing. Furthermore, we support browser-based authentication for password-protected graph databases.

To make the graph explorable and the graph-based nature understandable, we have found the Ontodia Graph Explorer (see Figure 4) [ 26 ]. It allows one to interactively add existing entities from the knowledge graph to a drawing area on the screen, and will automatically add the links between entities. It can also show the Ontology schema in a tree fashion and will show a list of instances of the selected ontology class. We refined the graph explorer with a geo-spatial map widget and the possibility to hide obstructive properties. Further, we included meta-data schema and concept schema in the class tree. As a convenience, we have also integrated a link into the Linked Data Viewer which will add the current entity to the graph explorer, and we have made it possible to share created knowledge graph diagrams with other users through custom links.

Country C Russia has country location

External%2FOtherForces, StateForces

E Police Forces of Russia (2000-) F… A Ukraine

Administrative…

has actor

T Tgheinogmetry IRI: https://data.coypu.org/event/acled/8005488/geometry has country location

Attack, Conflict, Event

A Attack - Ukraine - Simferopol IRI: https://data.coypu.org/event/acled/8005488 comment + −

hasGeometry Leaflet | © OpenStreetMap contributors

On 11 May 2021, the Russian Federal Security Service shot dead an Uzbek national in Simferopol district, Crimea, during searches.

Human rights activists condemned police b t lit map13 map widget, it is possible to present and verify the SPARQL results of geospatial data and numeric data easily.

Documentation and Dataset catalogue.

To provide project documentation, we make use of Just the Docsm. The documentation can be written in Markdown in our source control system and is then deployed on ‹https://docs.coypu.org/› using a pipeline. The configuration has been extended with a “Try it!” link on SPARQL queries,14 so that these can be tried out directly on the Jena Fuseki User Interface.

Additionally, a tabular listing of our data catalogue content is published at h‹ttps://datasets. coypu.org/› by automatically executing SPARQL queries on our knowledge graph and rendering the result to Markdown. This is done by feeding the SPARQL CSV output [ 31 ] into csvlookn.

The data catalogue itself is hand-created in RDF/Turtle format and collects all the details about 13https://www.openstreetmap.org, implemented with Leaflet: https://leafletjs.com/ 14https://gitlab.com/coypu-project/skynet/platform-exhibits/-/tree/main/just-the-docs the externally sourced data that is being used in the CoyPu project. This includes licensing information, links to the data source, the target RDF graph where this data set is loaded and a link to the Data Licenses Clearance Center [ 32 ]15 (DALICC) licence where available. We plan to record further meta-data into our catalogue, such as the tools involved in transforming the original data into RDF data.

The DALICC ofers a RESTful web service that supports automated clearance of rights thus supporting the legally secure and time-eficient re-utilisation of third-party data sources . The service is also named DALICC and the source code can be found on GitHub. It is possible to run your own instance of DALICC but some features like the usage of a remote SPARQL endpoint are missing at the moment. We also consider extending the service with a feature that helps to examine the rights and permission of data, derived from multiple datasets (e.g. via SPARQL queries).

Hosting and serving the knowledge graph.

We use Apache Jena [33] Fuseki backed by

Apache Jena TDB2, both combined making a full-fledged SPARQL Endpoint for scripts and programs to work with. Getting started is mostly straightforward, for a simple deployment you can download the Apache Jena Fuseki release and start it (Java is required).

Extensive customisation has been added to our Jena Fuseki. First of all, we configured geospatial16 and Lucene [ 34 ] text index in Fuseki.17 The endpoint for the Graph Store Protoco1l8 was moved from the Fuseki-default to a/data sub-path, to stop inadvertent dumps of the full graph. The endpoint has been access-restricted using Apache Shiro that is included in Fuseki19 (we hope to make it publicly available at a later date).

We identified a performance bottleneck involving SPARQL FROM queries and implemented a FROM-as-GRAPH filter for Jena. Concerning the geospatial data, we added GeoSPARQL functions such as lat, lon (to access the latitude and longitude of a point),centroid and aggUnion (from the upcoming GeoSPARQL 1.1 standard [ 35 ]) and simplifyDp (to simplify a geometry) or lineMerge20 functions, which we have suggested to the Open Geospatial Consortium for consideration. Additionally, the geospatial index was reprogrammed to work on a per-graph level rather than on the whole data set, and we also implemented a Fuseki service to recompute the geo-index of individual graphs at run-timeo. The initial loading time of the index was also heavily improved due to a custom serialisation format. To aid in RDFS21 reasoning and owl:sameAs [ 36 ] resolution, we have implemented two new SPARQL-SERVICE based RDFS and sameAs inferencers. They are also conveniently exposed in our linked data viewer (see Dereference and visualise the Graph). These additional functions are implemented in our JenaXp extension modules for Apache Jena. 16https://jena.apache.org/documentation/geosparql/geosparql-assembler 17https://jena.apache.org/documentation/query/text-query.html#text-dataset-assembler 18https://www.w3.org/TR/sparql11-http-rdf-update/ 19https://jena.apache.org/documentation/fuseki2/fuseki-security.html Server Infrastructure. The knowledge graph and the associated processes cannot conveniently operate on free resources. To deploy our knowledge graph, we have a physical server with 250 GiB main memory, of which the Apache Jena Fuseki server is using 50 GiB. According to one of the Jena maintainers2,2 per TDB2 database approx. 2 GiB heap should be assigned (we have configured 10 databases). We have configured the Java heap space to 32 GiB 23 (after having experimented with smaller values, but those were found insuficient when executing larger CONSTRUCT or UPDATE queries).

The on-disk database files take currently 200 GiB of disk space, which amounts to 700 million (7 ⋅ 108) triples spread across 39 graphs. For the spatial index for GeoSPARQL, 300 MiB of disk space is used for our 4 million (4 ⋅ 106) geometries. The database files are stored on 4 SATA QLC SSDs operating in a software RAID. Fuseki is accessing the database files using memory-mapped I/O. Scanning through the whole index takes 200 seconds and scanning the whole literal table takes 50 minutes.

To create the initial database, we used RPT to convert all the output from our various mapping tools into N-Quads format and then thexloader script included in Fuseki. We did this after testing all the various loaders provided by Fuseki and determining that this script works best for our hardware/configuration. Altogether, it takes 8 hours for our system to convert the source RDF files into a Fuseki TDB2 database. The break-down is as follows: 3h 20m for mapping the data, 4h 20m for loading into TDB2, 1 minute to calculate the statistics for the query optimiser, 7 minutes to calculate the geospatial index for GeoSPARQL queries, 20 minutes to calculate a Lucene index for full-text search on the RDFS labels and just short of 1 minute to reload the database. (All times, sizes, and triple counts are approximate.)24

4. Conclusion

Many free and open-source software components have been created by the community when it comes to knowledge graph serving and preparation. Nevertheless, it can be challenging to set up the individual software components and configure them in the right way to work together. We had to manually configure nearly all of the components, which requires a diverse skill set ranging from Docker, YAML, JSON, and Bash, to SPARQL, JavaScript, and Java.

The remaining pain points are the long loading times and the query performance for more complex SPARQL queries as well as missed automatic optimisations when using the full-text search. Other issues could be improved, such as the per-graph Geo-index, but could be further enhanced for example by implementing a self-updating geo-index.

We gave impulses to heavily optimise the speed of certain specific queries such as the named graph list27 and raised other issues as we met them. Other improvements have been contributed 22https://lists.apache.org/thread/43vo5pdgfy0mst2pl6ppyyf65bwf7yb2 23java -Xmx command line flag 24An initial stumbling block for us was that the server was originally provided to the project with a ZFS RAID-1 iflesystem [ 37 ] on Ubuntu. Despite database-specific tuning 25 we were unable to make it work satisfactorily. The system Input-output load became unbearably high so we had to reinstall the system using the ext426 filesystem. 25https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html 26https://www.kernel.org/doc/Documentation/filesystems/ext4.txt 27https://github.com/apache/jena/pull/1655 directly by us, such as speed-ups for certain path query patterns, geospatial queries, or a whole new bulk SPARQL service and cache implementation. Yet other improvements such as the per-graph geo-index are still work-in-progress in our fork of Apache Jena, or part of our JenaX extension modules for Apache Jena. We plan to upstream our changes if possible, and to provide a docker compose file for easy reproducing of the set-up described in this paper.

Acknowledgments

The authors acknowledge the financial support by the Federal Ministry for Economic Afairs and Energy of Germany in the project Coypu (project number 01MK21007[A-L]).

Commercial metaphactory Enterprise Knowledge Graph Platform TopBraid Composer Authoring

Free software

Authoring franz.com/agraph/tbc BSD-3-Clause Authoring

BSD-2-Clause Mapping+

Apache-2.0 b [ 18 ]+ [ 19 ]+ h+ c+ k+ j+ p+

VocBench Protégé Version 5.6.1 Widoco Version 1.4.17 pyLODE YASGUI GeoYASGUI

Repository / Website Docu.

Docu.

Docu.

Docu.

Docu.

NER

Deref.

Explore Explore Explore Explore Explore Explore

Apache-2.0

GPL-3.0 / BSD-3-Clause

MIT MIT

MIT BSD-2-Clause

Apache-2.0 Apache-2.0

MIT Apache-2.0

MIT BSD-3-Clause Apache-2.0

References

[1] M. Gruninger , Methodology for the design and evaluation of ontologies , in: International Joint Conference on Artificial Intelligence , 1995 .

[2] N. Noy , Ontology development 101: A guide to creating your first ontology , 2001 .

[3] M. C. Suárez-Figueroa , A. Gómez-Pérez , M. Fernández-López , The neon methodology for ontology engineering , in: Ontology Engineering in a Networked World, 2012 .

[4] S. Auer , L. Bühmann , C. Dirschl , O. Erling , M. Hausenblas , R. Isele , J. Lehmann , M. Martin , P. Mendes , B. Nufelen , C. Stadler , S. Tramp , H. Williams , Managing the life-cycle of linked data with the lod2 stack , volume 7650 , 2012 .

[5] M. D. Wilkinson , M. Dumontier , I. J. Aalbersberg , G. Appleton, M. Axton , A. Baak , N. Blomberg , J.-W. Boiten , L. B. da Silva Santos , P. E. Bourne , et al., The fair guiding principles for scientific data management and stewardship , Scientific data 3 ( 2016 ) 1 - 9 .

[6] A. Hur , N. Janjua , M. Ahmed , A survey on state-of-the-art techniques for knowledge graphs construction and challenges ahead , in: 2021 IEEE Fourth International Conference on Artificial Intelligence and Knowledge Engineering (AIKE), IEEE, 2021 , pp. 99 - 103 .

[7] P. Hitzler , A review of the semantic web field , Commun. ACM 64 ( 2021 ) 76 - 83 .

[8] X. Zhu , Z. Li , X. Wang , X. Jiang , P. Sun , X. Wang , Y. Xiao , N. J. Yuan , Multi-Modal Knowledge Graph Construction and Application: A Survey, IEEE Transactions on Knowledge and Data Engineering ( 2022 ) 1 - 20 .

[9] V. Ryen , A. Soylu , D. Roman , Building Semantic Knowledge Graphs from (Semi-)Structured Data: A Review, Future Internet 14 ( 2022 ) 129 .

[10] G. Tamašauskaitė , P. Groth , Defining a Knowledge Graph Development Process Through a Systematic Review , ACM Trans. Softw. Eng. Methodol . 32 ( 2023 ) 27 : 1 - 27 : 40 .

[11] M. Hofer , D. Obraczka , A. Saeedi , H. Köpcke , E. Rahm, Construction of knowledge graphs: State and challenges , Semantic Web ( 2023 ) 1 - 43 .

[12] R. García , J.-M. López-Gil , R. Gil , Rhizomer: Interactive semantic knowledge graphs exploration , SoftwareX 20 ( 2022 ) 101235 .

[13] A. Stellato , M. Fiorelli , A. Turbati , T. Lorenzetti , W. Van Gemert , D. Dechandon , C. LaaboudiSpoiden, A. Gerencsér , A. Waniart , E. Costetchi , et al., Vocbench 3: A collaborative semantic web editor for ontologies, thesauri and lexicons , Semantic Web 11 ( 2020 ) 855 - 881 .

[14] M. A. Musen , The protégé project: a look back and a look forward , AI matters 1 ( 2015 ) 4 - 12 .

[15] D. Garijo , Widoco: a wizard for documenting ontologies , in: The Semantic Web-ISWC 2017 : 16th International Semantic Web Conference, Vienna, Austria, October 21-25 , 2017 , Proceedings, Part II 16 , Springer, 2017 , pp. 94 - 102 .

[16] S. Lohmann , V. Link , E. Marbach , S. Negru , Webvowl: Web-based visualization of ontologies, in: Knowledge Engineering and Knowledge Management: EKAW 2014 Satellite Events, VISUAL, EKM1, and ARCOE-Logic , Linköping, Sweden, November 24-28 , 2014 . Revised Selected Papers. 19 , Springer, 2015 , pp. 154 - 158 .

[17] K. Alexander , R. Cyganiak , M. Hausenblas , J. Zhao , Describing linked datasets, Linked Data on the Web Workshop (LDOW 09) , in conjunction with 18th International World Wide Web Conference (WWW 09) 538 ( 2009 ).

[18] D. Kontokostas , P. Westphal , S. Auer , S. Hellmann , J. Lehmann , R. Cornelissen , Databugger: A test-driven framework for debugging the web of data , in: Proceedings of the Companion Publication of the 23rd International Conference on World Wide Web Companion , WWW Companion ' 14 , International World Wide Web Conferences Steering Committee , 2014 , pp. 115 - 118 .

[19] A. Sommer , N. Car , pySHACL, 2022 . doi: 10 .5281/zenodo.7059600.

[20] J. Arenas-Guerrero , D. Chaves-Fraga , J. Toledo , M. S. Pérez , O. Corcho , Morph-kgc: Scalable knowledge graph materialization with mapping partitions, Semantic Web ( 2022 ).

[21] M. Lefrançois , A. Zimmermann , N. Bakerally , A SPARQL extension for generating RDF from heterogeneous formats , Proc. Extended Semantic Web Conference (ESWC) ( 2017 ).

[22] A. Dimou , M. Vander Sande , P. Colpaert , R. Verborgh , E. Mannens, R. Van de Walle, Rml: A generic language for integrated rdf mappings of heterogeneous data ., Ldow 1184 ( 2014 ).

[23] E. Daga , L. Asprino , P. Mulholland , A. Gangemi , Facade-x: an opinionated approach to sparql anything , Studies on the Semantic Web 53 ( 2021 ) 58 - 73 .

[24] A. Sakor , K. Singh , A. Patel , M.-E. Vidal, Falcon 2.0: An entity and relation linking tool over wikidata , in: Proceedings of the 29th ACM International Conference on Information & Knowledge Management, CIKM '20 , Association for Computing Machinery, New York, NY, USA, 2020 , p. 3141 - 3148 .

[25] B. Regalia , K. Janowicz , G. Mai, Phuzzy. link: A sparql-powered client-sided extensible semantic web browser ., in: VOILA@ ISWC , 2017 , pp. 34 - 44 .

[26] D. Mouromtsev , D. S. Pavlov , Y. Emelyanov , A. V. Morozov , D. S. Razdyakonov , M. Galkin , The simple web-based tool for visualization and sharing of semantic data and ontologies ., in: ISWC (Posters & Demos) , 2015 .

[27] A. Micsik , Z. Tóth , S. Turbucz , Lodmilla: Shared visualization of linked open data , in: Theory and Practice of Digital Libraries-TPDL 2013 Selected Workshops: LCPD 2013 , SUEDL 2013 , DataCur 2013 , Held in Valletta, Malta, September 22-26 , 2013 . Revised Selected Papers 3 , Springer, 2014 , pp. 89 - 100 .

[28] G. Vega-Gorgojo , L. Slaughter , B. M. Von Zernichow , N. Nikolov , D. Roman , Linked data exploration with rdf surveyor , IEEE Access 7 ( 2019 ) 172199 - 172213 .

[29] L. Rietveld , R. Hoekstra , The yasgui family of sparql clients 1, Semantic Web 8 ( 2017 ) 373 - 383 .

[30] W. Beek , E. Folmer , L. Rietveld , J. Walker , Geoyasgui: The geosparql query editor and result set visualizer , The International Archives of Photogrammetry, Remote Sensing and Spatial Information Sciences 42 ( 2017 ) 39 .

[31] A. Seaborne , Sparql 1.1 query results CSV and TSV formats . W3C recommendation , 2013 .

[32] T. Pellegrini , V. Mireles , S. Steyskal , O. Panasiuk , A. Fensel , S. Kirrane, Automated rights clearance using semantic web technologies: The dalicc framework , Semantic Applications: Methodology, Technology, Corporate Use ( 2018 ) 203 - 218 .

[33] J. J. Carroll , I. Dickinson, C. Dollin , D. Reynolds , A. Seaborne , K. Wilkinson , Jena: implementing the semantic web recommendations , in: Proceedings of the 13th international World Wide Web conference on Alternate track papers & posters , 2004 , pp. 74 - 83 .

[34] A. Białecki , R. Muir , G. Ingersoll , L. Imagination, Apache lucene 4 , in: SIGIR 2012 workshop on open source information retrieval, 2012 , p. 17 .

[35] N. J. Car , T. Homburg, Geosparql 1 . 1: Motivations, details and applications of the decadal update to the most important geospatial lod standard , ISPRS International Journal of Geo-Information 11 ( 2022 ) 117 .

[36] B. Motik , Y. Nenov , R. Piro , I. Horrocks , Handling owl:sameAs via rewriting , in: Proceedings of the AAAI Conference on Artificial Intelligence , volume 29 : 1 , 2015 .

[37] J. Bonwick , M. Ahrens , V. Henson , M. Maybee , M. Shellenbaum , The zettabyte file system , in: Proc. of the 2nd Usenix Conference on File and Storage Technologies , volume 215 , 2003 .

[12]+ [26] [27] [28] [29]+ [30] [33]+ github.com/rdflib/pyLODE labs. tib.eu/falcon/falcon2 Apache-2 .0 github.com/AKSW/RDFUnit Apache- 2 .0 github.com/RDFLib/pySHACL Apache- 2 .0 jena.apache.org/documentation/shacl/ MIT github.com/LodLive/LodView Apache- 2 .0 github.com/zazuko/trifid MIT gLiitnhkuebd.-cDomat/aA-VKiSeWwe/r GPL- 3 .0 rhizomik. net LGPL-2 .1+ github.com/zazuko/graph-explorer changes on https://github.com/AKSW/graph-explorer Apache-2 .0 lgoitdhmuibll.aco.smzt/adksid.h -usztaki-hu Apache-2.0 tools.sirius-labs.no/rdfsurveyor github .com/guiveg/rdfsurveyor MIT yasgui.triply.cc MIT github.com/Triply-Dev/ YASGUI.YASR-deprecated/tree/geo