Extend Your knowledge graph by mapping many-to-many relationship tables to object properties
This is the fifth article in the series on useful mapping patterns to build a knowledge graph. Following our previous article, where we explained how to map data properties from table columns, here we present another fundamental mapping pattern: mapping many-to-many relationship tables to an object property. Now that we are approaching object properties, we can finally see how to link entities together.
The pattern: Mapping a many-to-many relationship table to an object property
Mapping a table to an object property is a fundamental pattern when building a knowledge graph. The pattern links two entities (a subject and object) together through a property. As in the previous post, we will map the data from Microsoft’s AdventureWorks sample database to classes and properties from schema.org.
Let’s say we have a relational database containing data about bike parts and components. We know that products are sold by particular businesses, as in the image below: a bike fork is for instance sold by the vendor Bike24.
Using the schema.org vocabulary, we can represent this information in a knowledge graph, knowing that the bike fork instance of the class schema:Product has as seller the vendor instance Bike24 of the class schema:LocalBusiness.
We have a table for products like bike parts, a table for vendors, and an additional table that stores which product is sold by which businesses. This additional table on products and vendors has a primary key composed of two parts: one that is a foreign key to the table for bike parts and one that is a foreign key to the table for vendors. The novel mapping pattern will allow us to add a seller object property between entities that are instances of the class Product and instances of the class LocalBusiness. That way, we will link the bike fork to, among others, the vendor Bike24.
Preparing the knowledge graph
In our AdventureWorks database, the table production.product contains data about available products. We previously created the lens lenses.production.product, and we used it to bring instances of the class Product to the knowledge graph and describe them with data properties. Let’s now do the same for the vendors. The table purchasing.vendor contains companies from which the products are purchased and we create from the table the lens lenses.purchasing.vendor. The lens lenses.purchasing.vendor has as primary key the column businessentityid. We are interested also in the column name with the actual name of the vendor.
When exploring schema.org, we see it contains a class well suited to represent the values stored in our vendor lens schema:LocalBusiness. This class represents physical businesses, including vendors of bicycle parts.
We map the lens lenses.purchasing.vendor to the class schema:LocalBusiness with the same procedure we have seen in our first article on mapping a table to a class.
We make use of the primary key businesspartnerid to identify each row and map these rows to entities belonging to the class schema:LocalBusiness.
Ontopic Studio directly suggests a template for generating the instances in our knowledge graph using this column. Obtain our new template data:purchasing-vendor/{businessentityid}, we just have to select the class schema:LocalBusiness among the classes provided by schema.org. We further extend our knowledge graph by adding the data property schema:name to these entities by mapping the column name in lenses.purchasing.vendor following the same process as described in our previous article on mapping table to data properties.
This will result in the following mapping:
Using the object property to link entities
The table we consider to map to the object property is purchasing.productvendor, the many-to-many relationship table associating vendors with the products they sell. The table has two foreign keys: one from the column businessentityid to the column with the same name in the table purchasing.vendor, and another from the column productid to the homonymous column in the table production.product.
The ontology also contains the property schema:seller that can be used to link a product entity to an entity that sells it. The new mapping pattern captures how lenses.purchasing.productvendor is mapped to the object property schema:seller, using the two columns productid and businessentityid to construct respectively the subject and the object of the triple.
In Ontopic Studio, when mapping the lens lenses.purchasing.productvendor we reuse the template data:production-product/{productid} for the subject, we select schema:seller as property, and we reuse the template data:purchasing-vendor/{businessentityid} for the object.
The resulting mapping entry is the following:
No SQL query was needed, like with the previous mapping patterns.
We can test the mapping by making a query that shows the content of the knowledge graph. We can obtain the IRIs of the products and their vendors, as well as their respective names.
Final remarks on mapping a table to an object property
The presented pattern has also been introduced in the book Designing and Building Enterprise Knowledge Graphs. Authors Juan Sequeda and Ora Lassila call it a many-to-many relationship.
A similar pattern has been presented in the article Mapping Patterns for Virtual Knowledge Graphs by Diego Calvanese et al., where it is called the Schema/Relationship pattern.
In Ontopic Studio object properties are simple to create and edit since we can reuse the already created IRI templates to identify the entities. You can avoid misspellings and manual effort and no SQL query is required.
Using this pattern, we start to see the graph taking shape with links appearing between entities, i.e. edges appearing between nodes. As usual, designing the mapping in Ontopic Studio guarantees the mapping is compatible both with the materialization and the virtualization setting. The fact that the graph can be kept virtual allows you to evaluate your graph modeling immediately and visualize the changes executed in the next modeling iteration.
In the next article, we will extend our knowledge graph using another helpful design pattern: mapping a sub-class depending on the value in a given column.
Have you ever worked with a mapping editor before? If you would like to try Ontopic Studio, just register for demo access or book a meeting.
Get a demo access of Ontopic Studio
Ready to do mapping with a no-code approach? Let us help you. Get a demo access:
