Hi there - and welcome to the metaphacts Blog! We're really excited to see our blog system go live and we thought we'd give you a brief introduction into our aims for this blog, the benefits you can extract from it and best practices for interacting with the system. » Continue reading
Finding paths in a graph is a well defined space in mathematics and computer science. The Seven Bridges of Königsberg problem from 1736 - which asked to devise a roundtrip through the city of Königsberg in Prussia while crossing each bridge in the city only once - is one of the most famous real world problems and resulted in the foundations of today's graph theory.
While the term pathfinding might often be associated with finding the shortest path (for example, in a geographical context or in computer networks), the seven bridges problem is a good example showing that the shortest path is not necessarily the optimal or desired path for a given problem or information need.
Although they are graph databases, semantic graph databases lacked native support for pathfinding algorithms for a time (with a few exceptions). This was initially mainly due to the slightly different focus on data integration and a very expressive and standardized query language, SPARQL. SPARQL itself is a graph pattern matching language, which may naturally come with some trade-offs (e.g., in terms of index design, query optimization and computing cost) when applied to other use cases such as pathfinding.
With matured technology, evolution of standards and increased availability of computing resources, nowadays, most RDF databases natively support pathfinding algorithms. Most recently, our partner Ontotext released GraphDB 9.9 featuring sophisticated pathfinding algorithms which are fully compliant with and accessible through standard SPARQL 1.1 service extensions. See [1] and [2].
Following our mission, we have taken up the challenge to enable business users and domain experts to utilize this functionality without having knowledge about SPARQL or the particulars of pathfinding algorithms. When designing metaphactory's new visual pathfinding interface - released just last week with metaphactory 4.3, we focused on two primary usage scenarios:
Written by Sebastian Schmidt on . Posted in Use Cases
(Reading time: 5 - 10 minutes)
This article was co-written by Todor Primov (Ontotext).
Large enterprises have identified knowledge graphs as a solid foundation for making data FAIR and unlocking the value of their data assets. Data fabrics built on FAIR data drive digital transformation initiatives that put companies ahead of the competition.
But while the benefits of knowledge graphs have become clear, the road to their implementation has often been long and complex, and success has relied on the involvement of seasoned knowledge graph experts.
This blog post goes through the basics of the joint solution delivered by Ontotext and metaphacts to speed up this journey.
Many enterprises have identified Knowledge Graphs as the foundation for unlocking the value of their data assets, easing knowledge discovery and surfacing previously unknown insights and relations in their data. But while the benefits of Knowledge Graphs have become clear, the road to implementation has often been long and complex. Success in making these benefits tangible to the actual business users who interact with and rely on this data on a daily basis has required the involvement of seasoned knowledge graph experts.
In this blog post, we provide an introduction into metaphactory's intuitive and interactive wizards which support application engineers in quickly and visually setting up and configuring search and authoring interfaces that cater to specific end-user information needs. The wizards (introduced recently with the metaphactory 4.2 release
) are one of the pillars of metaphactory's low-code approach for building knowledge graph applications. They allow application engineers to focus entirely on translating end-user information needs into intuitive, model-driven interfaces without getting caught up in the technical details of the semantic technologies stack.
Extracting meaningful and actionable insights from data is only possible if data is easily and intuitively accessible to and searchable for users. But as data accumulates, finding the right bit of information becomes challenging.
Knowledge Graphs have proven extremely powerful in surfacing previously unknown insights and relations in the data. They enable unprecedented query expressiveness and allow to make all instance data and its related metadata searchable, accessible and shareable.
metaphactory is an excellent example of leveraging Knowledge Graphs to bring together information distributed across siloed sources and departments, ultimately empowering end users to unlock the value of data, especially when it comes to search.
This blog post provides an overview of the metaphactory search components. To make the experience as concrete as possible, we provide examples using the most prominent publicly available knowledge graph: Wikidata. For that purpose, we are hosting an instance of our metaphactory platform on top of Wikidata for you to experience. The specific implementations described in this post are based on examples from the Life Sciences domain, but can be adjusted to match information needs across other usage scenarios or verticals.
Written by Jeen Broekstra on . Posted in RDF / SPARQL
(Reading time: 7 - 13 minutes)
In any Knowledge Graph-based project, keeping track of where data comes from is important. When you know the source of your facts or assertions, you can contextualize those facts: how relevant is assertion X to my current research, is it from a source that I personally trust, and if I have two conflicting views how can I decide which source to go with? Apart from issues of trust and confidence, tracking the source also can serve more mundane goals, such as knowledge graph maintenance: source X has published a new edition of their data set, so we need to replace the relevant data in our own Knowledge Graph, and so on.
Keeping track of the source of data is often referred to as provenance. In this blog post, we will look at provenance tracking in RDF Knowledge Graphs using the Wikidata dataset as an example, and we will look at how RDF-star and SPARQL-star, two new community efforts to extend the RDF model, can make this task easier.
