Searching with metaphactory - An Overview


Dmitry Pavlov



Reading time: 6 - 12 minutes

Searching your Knowledge Graph with metaphactory

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.

metaphactory Semantic Search Framework

The metaphactory platform comes with an innovative semantic search framework where searches are built using individual Web components, as depicted in the screenshot below:

  1. The semantic search component (semantic-search) works as a wrapper defining the parameters for search. A search profile must be defined in this component. Search profiles contain definitions for search categories (i.e., classes) and relations (i.e., properties) available for search in the knowledge graph.
  2. Within the semantic search, a search definition component (or query builder) must be defined. This will depend on the search type being configured, e.g., a structured search component or a keyword-type search component.
  3. The result visualization component (semantic-search-result-holder) provides a wide number of options to display customized search results, e.g., interactive tables, charts, maps, graphs, etc.
  4. The optional faceted filtering component (semantic-search-facet) enables users to refine their search using facets.

metaphactory Semantic Search Framework

All metaphactory components were designed to address specific information needs and by plugging in the right components can build targeted solutions for your users. Search components exploit the model (or ontology) of the knowledge graph to disambiguate results by class / concept and to connect data through relations between entities.

Integration with the faceted filtering component

The faceted filtering component works with all search components in the metaphactory semantic search framework. Facets are additional contextual filters that appear as part of results visualization and which allow the end user to refine the results without changing the initial query. Facets are computed based on the result set, showing only those relations and literal values that results carry. Facets are defined by an application engineer by pointing to specific properties in the underlying data model.

Result visualization options

Like the semantic search components, result visualizations are driven by the underlying data and model. The result visualization can be configured for all search components in the metaphactory semantic search framework to match specific user needs. Options for result visualizations include, but are not limited to:

  • Interactive tables
  • Static tables
  • Charts
  • Visual graphs
  • Maps
  • Carousels
  • Trees
  • Timelines

Search Definition Components in metaphactory

1. Keyword search component

metaphactory's keyword search component comes with a pre-configured search definition component (depicted as component 2 in the screenshot above) and only requires the selection and configuration of a result visualization component (component 3) and, if desired, the integration and configuration of the faceted filtering component (component 4). The keyword search component matches the query against any literal in the index, but can be configured to restrict matches to certain labels of entities in the knowledge graph. metaphactory uses an internal service (the Lookup Service) as an abstraction over the full-text indexes and central indexes (e.g., Elasticsearch or Solr) of each graph database connected.

Let’s have a look at a concrete example on our Wikidata demo system. In the short video below we are typing in "alzheimer" and get results rendered into cards, using the semantic-table visualization component.

Watch video on YouTube »

One important thing to note is that if your keyword appears often in entity labels in the knowledge graph, you might be overwhelmed by the number of results. In this example we provide additional disambiguation by adding supplementary information, such as type or description, to the result cards. For more details on configuring this component, have a look at the documentation here »

To give this search a try and experience it live, have a look at our example on the Wikidata demo system »

2. Keyword search featuring type-based disambiguation

This keyword search component featuring type-based disambiguation delivers additional flexibility in addressing hybrid information needs. It supports simplified interaction with the data by allowing end users to combine keyword searches with type-based queries. Results can be visualized and explored flexibly and in context, with end users able to specify which properties should be visualized based on their relevance and the users' personal needs.

The structure and experience of the search interface, including the disambiguation and contextualization of search results, is again driven by the underlying ontology of the knowledge graph, in particular its classes and their relationships.

A search can be initiated by entering keywords, or simply by selecting a type to show all instances of that class. In the example depicted in the short video below, we are investigating the connection between the ap2a2 gene and Alzheimer's disease so we start typing "ap2a.." and see that this keyword renders matches in two categories: Gene and Protein. The result visualization also shows us how many matches were found in each category. We select Gene as our target domain and then we further contextualize the interactive results table by bringing in extra columns: We first add the relationship between the genes in the table and taxa and look at which genes are found in which taxa, and then we look at the diseases which are associated with these genes. We can then explore a particular gene in detail by opening its Knowledge Panel on the right.

Watch video on YouTube »

To configure this component you will need to list all classes/concepts which should be available for selection. For more details on configuring this component, have a look at the documentation here »

To interact with this component on your own and experience it live, have a look at our example on the Wikidata demo system »

To learn more about this specific component, you can also have a look at this past blog post »

3. Structured search

The structured search component can be viewed as a visual query builder which combines the expressiveness of knowledge graphs with an intuitive end-user interface. Since it allows users to utilize the knowledge graph model to construct their query piece by piece in a declarative manner, this component is extremely relevant for domain expert users who are familiar with the relevant concepts and relations in their domain and need to express complex queries that yield precise results, but who lack expertise in building SPARQL queries.

With structured search, you first choose the target concept you are looking for and then add constraints on relations and additional concepts. In our structured search example below, we choose Medication as the target concept. We are looking for medication to treat the condition dementia and, at the same time, these drugs must also be helpful with all diseases related to the AP2A2 gene. As a result we want to see all those drugs paired with the medical conditions they treat.

Watch video on YouTube »

The structured search component is very powerful but it does require some initial configuration. Specifically, you will need to:

  • List all classes/concepts which should be available for selection;
  • List the relations between classes which should be available for selection, including their domain and range classes;
  • Define custom query options, like tree selector or map selector as alternatives to the keyword search option.

For more details on configuring this component, have a look at the documentation here »

To interact with this component on your own and experience it live, have a look at our example on the Wikidata demo system »

4. Constant search

The constant search component is usually applied to specific and recurring user needs, for example "Show me the list of all running projects in the company" or "Show me the people in the company who have free capacity". For this, we are using a constant query which will have a potentially changing result set as the data evolves and new data is added.

For our Life Sciences domain example on Wikidata, we are assuming the role of a researcher who wants to know the total number of deaths caused by Alzheimer's disease per country. We are also interested in the life expectancy per country for Alzheimer's patients. Since new data on Alzheimer’s casualties may be published every day, we want to create a dashboard with a pre-defined search query and configuration that will return the most up-to-date results whenever accessed. For this we use the constant search component in metaphactory, additionally equipped with facets, and we use a map and an interactive table to visualize the results.

To end users, this dashboard will look like this:

Watch video on YouTube »

All you need to do to configure this search component is provide a SPARQL query. For more details on configuring this component, have a look at the documentation here »

To interact with this component on your own and experience it live, have a look at our example on the Wikidata demo system »

5. Form-based search

The form-based search component works on a parameterized SPARQL query where the parameters can be defined by the end user through the form fields.

In our Life Sciences example on Wikidata, we are, once again, a researcher, and this time we are interested in scientific papers around Alzheimer's disease published in our country within a certain timeframe. So in the implementation of our example we present two main parameters: disease picker constructed with a tree selector and a field for selecting one or several countries. Here, the faceted filtering component delivers means of further filtering results down to a specific author or time period.

Watch video on YouTube »

The configuration of this component requires an application engineer to define the fields of the form by providing a query to the data that fetches values for the end user to choose from. Additionally, the results table must be configured to be populated with values of properties that are best suited for the specific use case. For more details on configuring this component, have a look at the documentation here »

To interact with this component on your own and experience it live, have a look at our example on the Wikidata demo system »

Simple search component for embedded lookups

The simple search component serves the same goal as the keyword search component: it allows the user to type one or more keywords and quickly receive answers to their keyword-based queries. However, unlike the keyword search component, it is a separate component which is not part of the metaphactory semantic search framework and, therefore, does not include the flexible result visualization options or the option to integrate facets.

With the simple search component, results are visualized in a dropdown list directly below the search box. The auto-suggestion feature delivered with this component refines the list of options as the user is typing. Additional disambiguation is possible by customizing how individual results are visualized to display the type, e.g., a description or an image next to the label. By clicking on a certain result in the list, the user is redirected to a dedicated page for the selected resource.

Because it operates as a lookup and the result visualization occupies very little screen space, it is ideal for scenarios where results should be displayed in place as part of a more complex dashboard or UI and without affecting the dashboard's layout.

Let's have a look at a concrete example on our Wikidata demo system. In the short video below we are typing in "alzheimer".

Watch video on YouTube »

To configure the component, the following need to be defined:

  1. The search query exploiting the lookup service. Here, the default settings can be used or they can be modified to influence the results (e.g., to search only on certain properties, return only resources of a certain type, limit the number of results, etc.).
  2. The visualization template for the result entries (e.g., one template applied to each individual result) to select the relevant properties.

For more details on configuring this component, have a look at the documentation here »

To interact with this component on your own and experience it live, have a look at our example on the Wikidata demo system »

Summing it up

To help you select the right component to address your (or your users') information needs we have also prepared a comparison matrix that evaluates the metaphactory search components along the following criteria:

  • the amount of configuration they require;
  • the level of complexity in providing a search query;
  • the level of control users have over the underlying queries;
  • the options for refining search results available for each component; and
  • their composability.

That's cool! How can I try metaphactory?

The Life Sciences examples described in this blog post, together with many others, are available on our live Wikidata demo system, so feel free to try these examples or maybe start your own searches.

To try out these search components with your own data and test out their configuration you can get started with metaphactory using our 14-day free trial. And, of course, don’t hesitate to reach out if you want to learn more about implementing metaphactory.

Make sure to also subscribe to our newsletter or use the RSS feed to stay tuned to further developments at metaphacts.

Irina Schmidt

Irina is an international marketing and communications expert with over 10 years of experience in the areas of product marketing, online and digital marketing, public relations and customer success. She loves working at the crossroads where technology and business meet and is passionate about targeted marketing solutions that resonate with customers and solve real-world problems.

Dmitry Pavlov

As Director of Customer Success at metaphacts, Dmitry is responsible for making sure that our clients have a positive and rewarding experience with metaphactory and he drives many customer-oriented product improvement initiatives to make this experience even smoother.