How to Calculate Compatibility with RDFox

Across various industries and business models, companies seek to assess compatibility; for example, in regards to industrial configuration management, terms in contracts, points of a supply chain, buyers and suppliers, and so on.

Whether this process is in relation to assemblies, production or data analysis, it can require checking millions of combinations to assess whether components fit together and if they meet certain requirements. The large volumes of data, complex process and issue of scalability mean that traditional approaches are inefficient.

This article will demonstrate how RDFox can be used to make compatibility solutions correct, with almost unnoticeable iteration times, and operate orders of magnitude times faster than other graph databases. It will use the example of an industrial configuration management solution.

For more details, see our Festo white paper, or follow along with our Configuration Solution webinar:

Traditional configuration solutions

Traditionally, SQL databases can be used to determine compatibility. However, the process is long and requires the creation of tables for each component, joining tables to form bigger tables and bigger tables, and so on. The complete system is then used to assess compatibility

As there could be thousands of components with many different characteristics and no universal schema, this process is extremely complex and tiresome with limited scalability. For a database of tens of thousands of components, this process can take hours.

For businesses with time pressures and restrictions, this imposes a challenge, and could limit competitive viability. Each time a component is added or removed the whole system needs to be updated, resulting in long iterations in the development or modification process.

How to improve configuration management with RDFox

RDFox is a high-performance knowledge graph and semantic reasoner. A knowledge graph is composed of a graph database to store the data and a reasoning layer to interpret and manipulate it. Relational databases like the SQL example above, store data in a strict tabular structure, while graph databases store information as triples, comprised of nodes (data point, i.e. subject or object) and edges (relationships between data points). These structural differences provide significant advantages for use cases which require the calculation of compatibility, as knowledge graphs overcome the flexibility limitations of relational databases, allowing data points to be encoded as richly connected entities.

RDFox is an in-memory solution which makes it extremely fast. The powerful reasoning engine is unmatched in efficiency and reasoning capabilities, and by using rules it can provide flexible, incremental addition and retraction of data, as well as, fast parallel materialisation of new facts.

But what does reasoning mean in the context of a configuration solution?

In this context, reasoning is understanding and applying the logic of how components are assembled to meet customer’s requirements.

The configuration challenge

Build me an assembly that can spin at 2,000rpm and provide 800g-cm of torque

For this example we have created a simple configuration management web application, which allows us to query the database for configuration solutions which provide specific requirements. The results are updated live, and can be seen on the right.

For a database which contains tens of thousands of components, including motors, gears, switches, power supplies and controllers, we need to check millions of potential combinations to determine compatibility. This is done by calculating if the components fit together and to see if they meet each others requirements. Each component has certain requirements and is responsible for certain provisions; for example, if the batteries supply and motors require a compatible amount of voltage.

To begin the process, we map each component’s attributes into the knowledge graph. For this example we have 500 components.

Additionally, we can add an ontology of the components to the graph. This captures component hierarchies and is encoded into the system, providing subclasses and relationships. Using ontologies helps during the process of querying the dataset for the particular configuration solutions, as well as when writing rules.

Once the data for all the components is stored within the knowledge graph, we can use the power of reasoning to establish the compatibility of components. Using rules expressed in Datalog, we can inscribe the logic of component compatibility, easily and correctly, into the system.

Rules allow the constraints for components to be compared with component attributes, resulting in the determination of compatibility and the provision of options for compatibility solutions. The compatible configuration solutions can then be stored in the knowledge graph as new edges (relationships) between nodes (data points, in this case, components).

This is an example of a compatibility rule in Datalog which could lead to the following result:

[?M, :compatibleWith, ?PS]:-
:DCMotor[?M] ,
:DCPowerSupply[?PS] ,
[?PS, :provides, :DCVoltage] ,
[?PS, :providedVoltage, ?pv] ,
[?PS, :providedCurrent, ?pc] ,
[?M, :requires, :DCVoltage] ,
[?M, :requiresVoltage, ?rv] ,
[?M, :requiresCurrent, ?rc] ,
FILTER (?pv = ?rv && ?pc >= ?rc) .

On inspection of this particular rule, it is evident that rules are expressions of logic and datalog provides a clear language to encode the rule. Rules read as an “if… then” statement. For example: The formula to the left of the :- operator is the rule head (the ‘then’ part) and the formula to the right is the rule body (the ‘if’ part).

Intuitively, this rule says, if the power supply provides a DC Voltage, a voltage of a specific amount, and a current of a specific amount, and the motor requires a DC Voltage, a voltage of the same amount, and a current of the same amount, then the two are compatible. This example shows that these two components are compatible with each other based on the requirements and provisions of the components.

This example represents just one configuration sequence. However, the database contains 500 components and numerous chains of compatibility. If all configuration solutions are calculated and materialised into the database, there will be various pathways to a configuration solution, for example:

Web applications can be built and attached to the RDFox console, allowing users to interact with the knowledge graph without having to write SPARQL queries. This has significant benefits for businesses which require individuals throughout the company to access information, correctly and quickly. By typing the search constraints into the ‘Search Parameters’ box on the left, a SPARQL query is triggered, requesting information from the knowledge graph.

Alternatively, rather than using a web application, you can interact with the knowledge graph directly using RDFox’s console. RDFox uses the RDF standard query language SPARQL, which send requests for information to the knowledge graph.

The console above contains the query for a configuration solution using our example database. The query indicates that specific torque and speed requirements were selected. The query fetched 47 answers and executed in 0.702 seconds — blink and it is there!

By using rules, RDFox can compute all compatibilities for configuration solutions ahead of query time. This advanced capability means that queries occur even faster than alternative knowledge graph solutions, resulting in increased efficiency within businesses, as solutions are provided quicker. This has knock on effects for user experience and client satisfaction. Systems which do not use rules would have to determine compatibilities during the query process, resulting in significantly slower results.

How to add or remove new items

In real-world applications, components will be added and removed from the database. This poses a significant constraint on companies who use databases with long iteration periods.

New component data can be imported into RDFox, along with the rules for its compatibility, at any point. As RDFox processes updates incrementally, this can be added without needing a whole system update.

Similarly, to remove a component, you would need to tell RDFox to delete it. Once the component is deleted from the data, all relationships (edges) from the component to other components (nodes), will also be deleted, incrementally.

How to deal with changing constraints

Similar to the process of adding component data, the rules can be updated. This is important for companies and clients who are having to meet constantly changing constraints, such as budget, environment, demand, and so on.

This incremental feature is unique to RDFox, and provides huge benefits, as it allows real time addition or removal of rules and data from applications; for example, when components are no longer manufactured, come in or out of stock or if items are recalled. The ability of RDFox to provide flexibility without compromising the performance, is significant in comparison to alternative compatibility solutions.

The overall picture:

1. Input data and rules

2. RDFox evaluates the rules and materialises new knowledge

3. Rotation solutions are accessed via SPARQL queries, using the RDFox console or web applications built on top of the console.

Knowledge graphs allow absolute flexibility for data modelling as rules can encode domain expertise and are bespoke to suit each company’s needs. This is the very reason why a graph database will always provide a more natural solution to configuration. An interconnected problem requires a tool that can not only handle interconnectivity, but embrace it and capitalise on its strengths, something that a relational database simply cannot do.

The final barrier is one of scale. Relational databases, and even many graph databases, struggle with large datasets, either offering poor performance that results in load or query times that are far too long to be practical, or cutting corners to circumvent this shortfall, crippling the usefulness of any results gained.

This is where RDFox triumphs. Built from the ground up with performance and advanced reasoning in mind, its in-memory approach neutralises these concerns. Its unique academic backing has ensured that it can perform at the very peak of what’s possible. Answers take into account the entire dataset and ensure 100% truth within the data, enriching it with knowledge along the way that provides invaluable insights that others don’t even begin to consider. Despite this massive advantage in analytical power, there’s no sacrifice to performance. In fact, RDFox consistently outperforms alternative graph databases by tens, hundreds, or even thousands of times, bringing analysis closer to real time and making the larger process far more fluid.

To find out more about RDFox head to the Oxford Semantic Technologies blog read about our other applications and use cases, or try RDFox for yourself for free and see what all the fuss is about.