Timely access to consumable, contextual, and actionable knowledge is crucial for any step in the decision-making process and the key enabler of decision intelligence. However, decision makers and decision support systems are still faced with the everlasting challenge that data relevant to and required for addressing their specific information needs is stored in distributed and database- or application-specific silos.

With metaphactory, we serve customers of various sizes and across multiple industries, but no matter whether we're talking about a clinical trial scoping or a bill of materials use case, customers are looking for solutions to address hybrid information needs. That means that end users usually have questions or information needs that are not limited to one single data source or just RDF graph data, but involve simultaneously dealing with a multitude of data sources, a multitude of data modalities and a multitude of data processing techniques.

In our previous post, we covered the basics of how the Ontotext and metaphacts joint solution based on GraphDB and metaphactory helps customers accelerate their knowledge graph journey and generate value from it in a matter of days.

This post looks at a specific clinical trial scoping example, powered by a knowledge graph that we have built for the EU funded project FROCKG, where both Ontotext and metaphacts are partners. It demonstrates how GraphDB and metaphactory work together and how you can employ the platform's intuitive and out-of-the-box search, visualization and authoring components to empower end users to consume data from your knowledge graph.

You can also listen to our on-demand webinar on the same topic or check out our use case brief.

Publishing FAIR data in the humanities sector

Reference data is a crucial element of data curation in the cultural heritage and humanities sector. Using reference data brings multiple benefits, such as consistent cataloguing, easier lookup and interaction with the data, or compatibility with other data collections that use the same reference data. Overall, the use of reference data can support the publication of FAIR data - data that is findable, accessible, interoperable and reusable.

In museum collection management, for example, various thesauri can be used as reference data to ensure the accurate and consistent cataloguing of items in a controlled manner and according to specific terminologies. Thesauri exist for various areas of expertise. One example is the Getty Art and Architecture Thesaurus® (AAT) which describes the different types of items of art, architecture and material culture, such as "cathedral" as a type of religious building. Authority data has also been published to support the unique identification of specific entities such as persons, organizations, or places, for example, "Cologne cathedral" as a specific instance of the type "cathedral". Such authority data sources include The Integrated Authority File (GND) or the Union List of Artist Names® Online (ULAN) and are specifically important for disambiguating over entities with the same name, e.g., Boston, the town in the UK, and Boston, the city in the USA.

Digital humanities projects often combine several research directions and use materials that cover multiple disciplinary areas. This makes the implementation of reference data difficult, as several reference data sources need to be used to cover all aspects and facets of a project. Moreover, technical access to reference data is inconsistent, with systems using different interfaces and APIs, which makes integration challenging.

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.

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.

This blog post refers to metaphactory components that have been deprecated. Please refer to our blog post on next-gen semantic search for up-to-date-information.

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.

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.

In my previous blog post on building Knowledge Graph-driven, FAIR Data platforms I discussed the importance of data and data-driven decisions, processes and tools in accelerating digital transformation. Knowledge Graphs have revolutionized the way data can be accessed and used, and have helped enterprises overcome the challenges posed by distributed silos where information is available to limited audiences, in heterogeneous formats, and represented according to different models. They have led to great advances in terms of data integration, interoperability and accessibility, and have allowed companies to tap into the full potential of their data assets and transform data into valuable and actionable knowledge.

Raul Palma leads the data analytics and semantics department at the Poznan Supercomputing and Networking Center (PSNC), where he coordinates the R&D activities and the center’s participation in various EU projects around these topics. In this guest post for the metaphacts blog, Raul explains how knowledge graph technology can address data integration challenges in the agri-food sector, showcasing it through a few use cases. He describes how he leveraged metaphactory to build a domain-specific application - FOODIE - that delivers intuitive access to distributed, heterogeneous data sources and allows end users to extract meaningful insights.

FOODIE is an agriculture knowledge hub delivered as a Web application built on top of metaphactory Knowledge Graph platform. The application enables an integrated view and access over multiple datasets which have been collected from various and heterogeneous sources relevant to the agriculture sector, transformed, and published as Linked Data / in a Knowledge Graph.

At metaphacts we help customers leverage knowledge graphs to unlock the value of their data assets and drive digital transformation. We started out with this mission in 2014 and, since then, we've served a multitude of customers in pharma and life sciences, engineering and manufacturing, finance and insurance, as well as digital humanities and cultural heritage.

This blog post will give you an overview of what we have developed in customer projects over the years as our game plan to build a Knowledge Graph-driven, FAIR Data platform and drive digital transformation with data. The post will show you how our product metaphactory can support you every step of the way, and will highlight examples from the life sciences and pharma domains.

Determining compatibility between individual entities is an essential process for many businesses, across various industries and business models; from industrial configuration, supply chain, bill of materials, evaluating terms in contracts, or even for match making apps. The process may sometimes require the user to check hundreds of thousands or millions of possible combinations, to assess whether components fit together, or if components meet specified requirements. Additional factors may also need to be taken into account, for example, regulations or customer budgets. Traditional approaches are inefficient for modern day applications due to the large volumes of data, heterogeneity of data formats, complexity of customer specifications, and concerns over scalability.

The SPARQL default graph is a concept that can confuse even frequent SPARQL users. In this article, we will go over what the default graph actually is, why it seems to be something different in every RDF database, and how you can come to grips with those differences and query with confidence.

We will also address the most common challenges and misconceptions, providing practical guidance on how to navigate these differences, along with insights into how metaphactory tackles these issues. Whether you're working with a single dataset or querying across multiple sources, developing a strong understanding of the default graph will enable you to query with both precision and confidence. Keep reading to learn more!

Our mission at metaphacts has always been to ease the onboarding into the world of enterprise knowledge graphs. With our product metaphactory we provide an end-to-end platform to support that mission and enable our clients in unlocking the value of their data assets. Since we first published metaphactory in 2015, with every new release we have introduced new features and capabilities to enable rich end-user experiences in interacting with knowledge graphs.

Through our blog, we want to continuously share some of the recent developments, examples, best practices and make the power of knowledge graph technologies more accessible for you.

Just today we released metaphactory 3.6, so this is a great opportunity to start this blog with showing you some cool new additions to our product. With our most recent release, we have introduced a series of new components and enhancements that help provide a more intuitive user experience and user interaction. These new components cater to user needs across all platform target user groups: end users, developers focused on building end-user oriented applications, as well as knowledge graph experts.