Ontology Modeling in Timbr

Modeling concepts of an ontology means describing data in a way easily understandable to all users, using a common language to refer to any unit of information. The ontology in Timbr becomes the data model, the concepts act as virtual tables with semantic relationships to automatically JOIN or UNION the data. Concepts also have a motion of inheritence to sub-concepts, forming an hierarchy of abstract and granular business concepts.

Timbr's Ontology Modeler provides a visual interface and a SQL DDL editor to easily model concepts, relationships, and properties that represents a business case.

---

Modeling Example

In this example we show how relational tables (ER model) map to an ontology in Timbr.
In our example we have 5 tables:

- Persons table with 3 columns: Id (primary key), Name, Age.

• Students table with 2 columns: Student_id (primary key and foreign key to person id), Registration_date
• Professors table with 2 columns: Professor_id (primary key and foreign key to person id), Research_area
• Class table with 3 columns: Professor_id (foreign key to professor id), Subject, Class_id (primary key)
• Enrollment table with 2 columns: Student_id (foreign key to student_id), Class_id (foreign key to class_id)

With Timbr we can model an ontology on top of those tables:

- Person concept with 3 properties: Id, Name, Age.

• Student concept inherits from Person with 4 properties: 3 inherited from Person and Registration_date
• Professor concept inherits from Person with 4 properties: 3 inherited from Person and Research_area
• Class concept with 3 properties: Professor_id, Subject, Class_id

We can also define the following relationships:

- Student is Enrolled_in a class (enrollment table is used a reference-table)

• Class has a professor (using professor_id to reference Professor concept)

---

Timbr Ontology Schemas

Timbr creates five virtual schemas to represent the ontology in a relational way:

• timbr schema: Intrinsic definition - explicit ontology/relational mapping.
• etimbr schema: Exhaustive definition - timbr schema with implicitly derived properties of all sub-concepts.
• dtimbr schema: Dereferenced definition - timbr schema with the semantic relationships defined for all concepts.
• vtimbr schema: A schema that exposes views saved in a given ontology.
• gtimbr schema: A schema to run Graph Algorithms on the ontology concepts.

The gtimbr schema is additional and is not included in the basic Timbr license.

---

timbr Schema

The Intrinsic schema of the ontology allows you to query concepts as tables and properties as columns.
The Timbr ontology starts with concept Thing as the root-base concept.

Everything (concept "Thing") in the ontology has two default properties:

entity_id: this is the unique instance id.
In RDF this is the unique subject URI.
In Relational modeling this is the primary key.

entity_type: this is the type (or types) of the instance.
In RDF this is the type of rdf:type.
In Relational modeling this is the type of the entity.

---

etimbr Schema

The Exhaustive schema extends timbr schema and allows you to query derived properties of a concept.
This allows you to query high-level concepts with opportunistic columns and reflection.

In our example, Person concept in the etimbr schema contains all the derived properties:

This also means that concept Thing in etimbr schema contains all the ontology properties:

This allows you to query anything with any properties.

For example: Anything with a name that starts with T

SELECT entity_id, entity_type, name FROM etimbr.thing where name like 'T%'

---

dtimbr Schema

The Dereferenced schema extends etimbr schema and allows you to traverse the ontology as a graph. You can view and query all the relationships between concepts without the need to explicitly write joins.

In our example, Student concept in the dtimbr schema contains his relationships as properties:

We see the relationship between concept Student and concept Class as a property `Enrolled_in`.

We can also see the reverse relationship direction with properties that start with ~.
In the following example we see the Class concept in the dtimbr schema:

We see the relationship between concept Class and concept Professor as a property `Professor`.
We see the reverse relationship between concept Class and concept Student as a property `~Enrolled_in.Student`.

In the following example we see the Professor concept in the dtimbr schema:

We see the reverse relationship between concept Professor and concept Class as a property `~Professor.Class`.

Timbr automatically joins concepts based on the path you select.
You can also continue traversing to other concepts by using `.`

For example: Give me all the professors that teach Student Sam

SELECT `Enrolled_in.Professor.Name` from dtimbr.student where name = 'Sam'

In this example, we traverse from concept Student to concept Class to concept Professor

---

vtimbr Schema

The view schema exposes all the views created on top of a given ontology. You can view and query all the views using the vtimbr schema just like any other virtual table in Timbr. Views can be created using the timbr, etimbr, and dtimbr schemas, leveraging the inference and relationships of each within the view itself. Views in Timbr can also be created using the physical tables of the connected data source.

---

Timbr Concepts

Timbr's Ontology Explorer enables users to create, edit, explore, and query concepts that are mapped to the underlying data sources and represent business entities or metrics. Concepts can be modeled in various ways (as can be seen in the examples below), most of which include hierarchies. The hierarchies express levels of abstraction for an entity where the upper level concepts are more general and abstract and the lower you go through the hierarchy, you get more granular and specific classifications of the upper concepts. The trick to validate if a concept is indeed a sub-concept of another concept is to check if the Is-A relation is applicable. When the sub-concept Is-A upper concept, then the hierarchy is correct, and their inheritance of properties and relationships is valid. In cases where the sub-concept does not apply to the Is-A upper concept (semantically), then the hierarchy is semantically wrong.

For example, Adult Is-A Person, therefore, any property and relationship of the Person concept also applies to the Adult concept. You can still create unique properties or relationships for the Adult concept that do not necessarily apply to the Person concept, for example, a driver_license_number property that is not applicable to every Person, only to those who are Adults.

In order for the data to be filtered correctly to the sub-concepts from their upper concepts, defining the concepts' business logic (filter conditions) must be set as shown in the examples below.

There are two methods to create concepts in Timbr. For those who prefer to code, concepts can be created using SQL statements which can be found below. Otherwise, concepts can be created in a visual manner following a few steps without the use of code.

---

Creating Concepts Visually

Concepts can be created no-code in the Ontology Explorer or by using SQL statements in the SQL Editor or from any other SQL endpoint.

In these examples, you’ll find guided explanations demonstrating how to create concepts visually using the Ontology Explorer.

---

CREATING PERSON CONCEPT Visually in the Ontology Explorer:

Assuming the Concept we'd like to create is Person, which will inherit and be created from the root concept of the Ontology named thing.

1. In the Ontology Explorer, Right click on the concept thing and choose + Child concept.

2. Give the concept a name as well as an optional description as to what the concept contains.

3. Add properties to the concept to represent the meta-data of the concept, the same way that column names represent data in a table.

Properties can be added in the three following ways:

• Set Properties - Choose relevant properties from the list of properties that already exist in the knowledge graph from the dropdown menu.

• Create New Properties - Create a new property from scratch, being either a regular property or changing the toggle for a multi-value property, then giving the property a name and data type, and choosing whether the new property should act as the concepts Primary Key or Entity Label.

Take note

If you choose to create a multi-value property, you will be required to create a multi-value mapping in order to map data to the property.

• Import - Import properties directly from a dataset.

Once Import is clicked a window will appear asking to enter the Datasource, Schema and Table where are properties we'd like to import to our knowledge graph concept are currently at. The properties can also be added using SQL by switching to SQL on the top right toggle.

When the Datasource, Schema and Table are entered, the columns from the chosen table will appear and will be ready to be imported as properties of the concept. Any properties can be removed if we aren't interested in them. We can also edit the property names to give a better semantic meaning to the properties, or change the type of a property in case the original column type in the table doesn't fit our needs. In these cases, Timbr will automatically apply a CAST function on the original table column and correct the data type according to the type we choose in the model.

Once we are done editing the properties and are satisfied with them, Import Columns is clicked on the bottom right, in order to import the properties to the concept.

Edit properties

At any point we can easily edit our properties by clicking the wrench symbol next to the property we'd like to edit, we'll make our changes and save them.

4. Choose a Primary Key and Entity Labels for the concept.

   The Primary Key in Timbr which is a virtual primary key, acts as a unique identifier for the concept. This primary key ensures that there are no duplications in the data. Please note, that without a Primary Key data can't be mapped to the concept.

   The Entity Labels in Timbr is the textual representation of the concept and determines how the concepts data will appear when exploring the concept as a graph.

5. On the bottom right, click on Add New Concept to finalize the concept creation.

CREATING ADULT CONCEPT Visually with Business Logic in the Ontology Explorer:

Assuming the Concept we'd like to create with Business Logic is Adult, which will inherit and be created from its parent concept in the Ontology named Person.

When a concept is created from a parent concept in the Ontology, the child concept inherits all its properties and realtionships from its parent concept.

1. In the Ontology Explorer, right click on the concept Person, hover over Create and select Child concept.

2. Give the concept a name as well as an optional description as to what the concept contains.

3. As the properties, relationships, primary key and entity labels of the concept inherit from the parent concept Person, go ahead and skip straight to defining the concepts business logic by clicking on the Logic tab. Please note that adding additional properties and relationships unique to the concept can also be added if desired.

4. Choose a concept in this case person as that will be the concept, we apply our conditions on for concept adult.

5. Click on Add Filter and define the logic for the concept.

6. Assuming you would like to define the busniess logic stating that adults are individuals 18 years or older, choose the property age is equal or greater than the value 18.

Notice that there is no limit to the number of business logic filters you can add to a concept. If you would like to add more filters, you can simply click on the plus to the right of each logic and choose if the logic being added should be an AND or OR statement. To the right of each concept, you can also delete a filter by clicking on the Trash can logo.

In addition to the visual dropdowns for defining the logic of the concept, you can click on the toggle to the left of each logic filter and choose to define the logic manually, doing so using SQL by clicking on Edit in popover which will now appear on the right of the selected logic.

7. When you've finished defining the concepts logic, on the bottom right, click on Add New Concept to finalize the concept creation.

---

Creating Concepts using SQL

Concepts can be created no-code in the Ontology Explorer or by using SQL statements in the SQL Editor or from any other SQL endpoint.

In these examples, you’ll find guided explanations demonstrating how to create concepts using SQL statements, including inheritance, rule-based concepts, and the different relationship types.

In the SQL Editor, after choosing the relavent knowledge graph, enter your SQL create concept statement.

CREATE Person Concept:

-- CREATE Person:
CREATE CONCEPT Person (id string, first_name string, last_name string, age integer, birth_country string,
    PRIMARY KEY (id),
    LABEL (first_name, last_name)
) INHERITS (thing)
DESCRIPTION 'Information about an individual person: name, age, phone number and city';

CREATE Adult Concept:

-- CREATE ADULT:
CREATE CONCEPT ADULT inherits (person) DESCRIPTION 'Information about individual adults: name, age, phone number and city' FROM timbr.person where age >= 18;

Example of an Adult concept that inherits from a person concept:

-- CREATE Person CONCEPT
CREATE CONCEPT Person (id string, name string, primary key(id), label(name))

-- CREATE Adult CONCEPT (with additional property of a driver license)
CREATE CONCEPT Adult (driver_license string) inherits (person)

Example of an Adult concept that inherits from a person concept with a filter on age >= 18:

-- CREATE person CONCEPT
CREATE CONCEPT person (id string, name string, age integer, primary key(id), label(name))

-- (LOGIC) CREATE adult CONCEPT filters person CONCEPT
CREATE CONCEPT adult
INHERITS (person)
FROM timbr.person
WHERE age >= 18

---

Creating Sub-Concepts and Extending the Data Model

Concepts can be modeled in various ways, most of which include hierarchies. There are two main approaches for creating a hierarchy - top-down modeling and bottom-up modeling. The main difference depends on the data sources and which tables are mapped to the concepts.

When we have one table with all the information, the data is usually mapped to the upper-level concept and the entire hierarchy below it can be a set of classifications of the upper concept (while applying filters in each level to distinct the data from the one big table). On the other hand, when the data is scattered among different tables that refer to the same entity, the different tables would be mapped to the lower-level concepts and the upper-level concept will serve to UNION all the data to give a holistic and abstract view of the data.

Top-Down Modeling

Top-down modeling is where the upper-level concept contains the data mapping, and the sub-concepts inherit that data by applying filter conditions. Aside from the data inherited via the filter conditions and business logic, all the properties and relationships are also inherited from the upper concepts to their sub-concepts.

Bottom-up modeling

Bottom-up modeling means that the sub-concepts in a hierarchy will contain the data mappings, while the upper-level concept will be an abstract concept that was created to UNION the data from its sub-concepts and answer questions that disregard the unique information from each sub-concept, providing a unified representation of the data coming from all sub-concepts as if it were a single table. In order to query the abstract concept and receive the desired data, the relevant properties (shared among the sub-concepts) must be added to the upper concept.

---

Sub-Concept Modeling Examples

Top-down Modeling Example

Assuming the model we’re working with has just two concepts, Customer and Order. The customer concept is mapped to a table of customers while the order concept is mapped to a table with all the data regarding the different orders placed by the customers.

In this example we would like to create a sub-concept of customers classifying it by a specific type of customers, for example VIP customers, so that we can then query the VIP customers concept and only get filtered results about VIP customers. To do that, we can easily right-click on the customer concept and click to create a sub-concept. At this point the sub-concept inherits all the properties and relationships of the upper concept (customers) including its data mapping.

The only thing left to do is to add a logical rule specifying the filter condition to exclude all customers besides VIP customers. To do that we only need to click on the Logic tab in the create concept window and apply the filter either with the UI or using SQL statements which allow you to define more complex conditions.

---

Bottom-up Modeling Example

In this example we’ll describe a scenario where we have data from different sources regarding the same business entity. The model we’re working with in this example has just two concepts, Facebook ads & Google ads, and for the sake of the example, represent data about advertising campaigns as if it were coming from these two advertising platforms.

The chosen platforms used in this example are for demonstration purposes only. We could have just as easily called these concepts Twitter ads and LinkedIn ads or use any other business entity from any domain. In this example, each concept is mapped to the relevant table (regardless of if they are stored in the same database – for more information see Timbr virtualization) and both share some properties (table columns) that have the same semantic meaning, for example – campaign_id , campaign_name, ctr, impressions, etc.

To add an upper concept and create a hierarchy, we’ll create a new concept and only give it a name – ads.

After saving the concept, we will edit each concept (Facebook ads & Google ads) and change the hierarchy of both to inherit from the new ads concept instead of thing (the default top concept where all level-1 concepts inherit from).

After changing the hierarchy, we will edit the ads concept and click on the properties drop-down to choose all the shared properties among his sub-concepts. When done, we will select a primary key that is also shared among the sub-concepts. We also suggest to select an entity label that is shared among them.

When finished, we can query the ads concept and get the information from both Facebook ads and Google ads in a single result set without specifying any UNION statement as if the combined data was mapped to the ads concept.

important

Any new property we will add to the ads concept, will be immediately inherited by the sub-concepts. In this modeling method the data mapping to the properties occurs in the sub-concepts, so adding a new property that doesn’t already exist in the sub-concepts below, will result in NULL values when querying the ads concept, unless we edit the existing data mapping and match a new column or calculation/function to the new property.

inherited relationships

Just like in a top-down modeling hierarchy, relationships are also inherited by the sub-concepts, so any relationships we will add to the ads concept will also exist in his sub-concepts and can later be utilized in the queries.

---

Creating Relationships

Semantic relationships in Timbr represent relationships between two concepts that express a specific type of relationship. The relationships are matched based on the property of each concept.

Timbr enables various relationships such as One-to-Many, Many-to-Many, and Transitive relationships. Users can combine Transitive relationships with one of the two options.

In the following examples, you’ll find a guided explanation demonstrating the creation of relationships between two concepts visually in the Ontology Explorer and using SQL statements in the SQL Editor.

Creating a Relationship between concept Person and concept Country in the Ontology Explorer:

Assuming we'd like to create a relationship connecting Concept Person to concept country.

1. In the Ontology Explorer, Right click on the concept Person and select Edit concept.

2. In the edit concept window that appears, click on the Relationships tab.

3. Click on + New Relationship to define the new realtionship. Notice that Timbr offers suggestions below to automatically create relationships based on the different entities in the knowledge graph.

4. In the window that appears, notice that Timbr enables users to create different types of relationships, whether it be one-to-many relationships, many to many, or even transitive relationships. Once the realtionship type is chosen, give the realtionship a direct name describing the context of this direct relationship between a Person and a Country. Next name the inverse relationship, looking back from concept Country to concept Person.

5. Choose the target concept to connect to, in this example Country.

6. Match properties on which this relationship will be based on, matching a property from Person to match with a property from Country.

7. On the bottom right, click on Save to save the relationship created, and click on Save changes to save the changes made in the edit concept window.

SQL Example of a Person concept with id and city properties and a foreign key to the Country concept:

-- CREATE Country CONCEPT
CREATE CONCEPT Country (id string, name string, city string, primary key(id), label(name))

-- CREATE Person CONCEPT
CREATE CONCEPT Person (id string, city string,
    constraint livesInCity foreign key (city) references city(id))

Timbr CREATE Many-to-Many Relationship Syntax

-- CREATE many-to-many relationship from calls concept to person concept through device concept
    CREATE OR REPLACE MAPPING `map_call_called_with_device` (
        CONSTRAINT `called_with_device` 
            FOREIGN KEY (`person_id`) 
            REFERENCES `person`(`person_id`), 
        CONSTRAINT `got_called_by_device` 
            FOREIGN KEY (`device_id`) 
            REFERENCES `call`(`device_id`)
    ) AS 
        SELECT `device_id` AS `device_id`, 
            `person_id` AS `person_id` 
        FROM `calls`.`devices`;

Timbr CREATE Multi-Value Relationship Syntax

-- CREATE multi-value relationship using person CONCEPT
CREATE OR REPLACE MAPPING `map_person_device` (`device_id` BIGINT, 
    FOREIGN KEY (`person_id`) 
    REFERENCES `person`(`person_id`)
) AS 
    SELECT `person_id` AS `person_id`, 
        `device_id` AS `device_id` 
    FROM `calls`.`devices`

Timbr CREATE CONCEPT With Transitive Relationship Syntax

CREATE OR REPLACE CONCEPT `<concept_name>` (`<property_name>` <property_type>,  
    PRIMARY KEY(`<property_name>`),  
    LABEL(`<property_name>`), 
    CONSTRAINT `<relationship_name>` 
        FOREIGN KEY (`<property_name>`) 
        REFERENCES `target_concept` (`<target_concept_property>`) 
        INVERSEOF `<inverse_relationship_name>`  
        TRANSITIVE (<transitive_depth>)  
) INHERITS (`<inherits_from_concept>`) 
DESCRIPTION '<concept_description>'; 

---

Creating Mappings Visually

Mappings are used to define a path between the physical tables to the virtual ontology concepts, properties (in case of a Multi-Value property), or relationships (in case of a Many-to-Many relationship).

A table or multiple tables can be mapped to a concept or multiple concepts based on data structure and requirements.

There are three different types of mappings a user can create in Timbr. Each mapping type correspond to a different element in the ontology. The available mapping types are:

1. Concept Mapping - A mapping from a datasource, or a number of datasources to a concept in the ontology
2. Many-to-many relationship mapping - A mapping from a datasource to a many-to-many relationship defined in the ontology
3. Multi-value property mapping - A mapping from a datasource to a multi-value property defined in the ontology.

---

Creating Concept Mapping Visually

In these examples you’ll find a guided explanation demonstrating the creation of a mapping to a concept visually in Timbr’s Ontology Explorer.

Assuming we'd like to create a mapping to the concept Person in the Ontology Explorer. Mappings can also be performed in Timbr's Data Mapper component.

1. In the Ontology Explorer, right click on the concept Person and select Mappings.

2. In the window that appears on the top right click on Map data.

3. Timbr will now offer users to create a Concept Mapping, Many To Many and Multi Value mappings. In this example select the Concept Mapping.

4. Select the Datasource and Schema where the data is stored. Once chosen the tables of the schema will appear on the right. Notice that Timbr notifies you regarding which tables have already been mapped, and which tables have not yet been mapped. In addition, on the top right, users can choose the Mapping method and decide whether to continue mapping Visually, or perhaps to map using SQL. In this example the mapping will follow the Visual method.

5. Choose the desired table you wish to map to the concept. In this case the people table to the Person concept.

6. Match the column names from the datasource to the concept properties. The matching can be done either manually choosing the properties one by one, where Timbr will perform automatic CAST suggestions when the property type is different from the column type, or instead the matching can be done automatically by Timbr by clicking on Add all suggestions on the top right of the screen. If matching is done automatically, it's worth checking to see that all the matches have been matched as intended.

At this stage before saving and creating the mapping, users can decide to click on filters in case they want to clean or apply rules on the original data that's being mapped.

7. When matching and cleaning of the data is complete, on the bottom right, click on Create mapping to save and create the new mapping.

---

Creating Many-to-Many Relationship Mapping Visually

Many-to-many relationships represent a relationship between two concepts using an intermediary table to connect them. This relationship is usually used when one data value from one table, for example - Imagine you have two concepts: customer and product, each one has mapping to different tables in your data. Conceptually, a customer can buy more than one product, and a product can be bought by different customers. You also have another table named customers_products which represents which customers purchased which products, this table is not mapped to any concept in the knowledge graph.

So in Timbr we can create a many-to-many relationship in the customer concept named purchased to the target concept product. If we look at it from the product concept perspective, the relationship can be defined as purchased_by when the target concept is customer. After we defined the relationship in the Ontology Explorer or in SQL, we can use the customers_products table as the mapping between the customer and purchased concepts as defined by the relationships of purchased andpurchased_by.

In the example below, you’ll find a guided explanation of creating a Many-to-Many relationship visually in Timbr’s Ontology Explorer.

Assuming we have already created a Many-To-Many Relationship between concept Person and concept Device, and we'd like to create a Many-To-Many mapping to the relationship in the Ontology Explorer.

This Mapping can also be performed in Timbr's Data Mapper component.

1. In the Ontology Explorer, right click on the concept Person and select Mappings.

2. In the window that appears on the top right click on Map data.

3. Timbr will now offer users to create a Concept Mapping, Many To Many and Multi Value mappings. In this example select the Many To Many Mapping.

4. In the window that appears, select the concept from which the relationship is coming from, in this case, concept Person. Next, select the Many To Many Relationship that was created earlier, and finally, click Next on the bottom right of the window.

5. In the window that appears, you can edit the Direct and Inverse realtionship names, as well as the name of the Many To Many Relationship. Below that, you can see the source concept that the relationship was built on, in this case Concept Person.

6. In the same window under the Target Schema and Table section, choose the Datasource, Schema and Table that contains the data that you want to map to your Many To Many Relationship, which will connect concepts Person and Device.

7. Next, match your source concepts property to the equivalent column in the table you chose, in this case matching property phone number with the column phone number. Now do the same for your target concept Device below, matching Person Id with the chosen table column Person Id. When done click Save to save the mapping.

Before saving the mapping

Notice that at this stage before saving the mapping, if you want, you can add additional properties to the relationship on the bottom of the screen.

---

Creating Multi-Value Property Mapping Visually

A property can be defined as a Multi-Value property. Multi-value properties have more than one data value representing that property, for example – email address. If we had a concept named customer and that concept had a property named email representing email addresses, we could set that property as a multi-value property since conceptually, a customer can have multiple email addresses.

Defining a mapping is required for Multi-Value Properties

Creating and mapping a multi-value property are two separate actions.

In the example above you will need to have a table with at least 2 columns, one representing the identifier of a customer (like a primary key or foreign key), and one representing the values for the email addresses

In the example below, you’ll find a guided explanation showing how to visually create a multi-value property mapping in Timbr’s Ontology Explorer.

Assuming we have already created a multi-value property for concept Person named role, and we'd like to create a multi-value mapping to that property in the Ontology Explorer.

This Mapping can also be performed in Timbr's Data Mapper component.

1. In the Ontology Explorer, right click on the concept Person and select Mappings.

2. In the window that appears on the top right click on Map data.

3. Timbr will now offer users to create a Concept Mapping, Many To Many and Multi Value mappings. In this example select the Multi Value.

4. In the window that appears, select the concept which contains the multi value property, in this case, concept Person. Next, select the multi value property mapping assigned to the property you intend to map to. Finally, click Next on the bottom right of the window.

5. In the window that appears, under the Target Schema and Table section, choose the Datasource, Schema and Table that contains the data that you want to map to your multi-value property.

6. Next, match your source concepts property to the equivalent column in the table you chose, in this case matching property person_id with the column person_id.

7. Finally, import the the multi-value property you are intrested in mapping to. When done click Save to save the mapping.

---

Creating Mappings using SQL

Mappings are used to define a path between the physical tables to the virtual ontology concepts, properties (in case of a Multi-Value property), or relationships (in case of a Many-to-Many relationship). A table or multiple tables can be mapped to a concept or multiple concepts based on data structure and requirements.

In these examples, you’ll find a guided explanation demonstrating the creation of a mapping to a concept using SQL statements in Timbr’s SQL Editor.

Either in the SQL Editor or by changing the mapping method to SQL in the ontolgy explorer, choose the relavent knowledge graph and enter your SQL create mapping statement.

Timbr CREATE MAPPING Syntax in SQL

CREATE OR REPLACE MAPPING <mapping_name>
INTO (<target_concept>) [USING <datasource_name>] [WITHOUT PARSING]
AS <mapping_query>

<> - Mandatory

[] - Optional

Optional arguements in create mapping

The USING <datasource_name> optional arguement in the SQL statement refer to which datasource will the mapping run in

If the WITHOUT PARSING optional arguement is set, then Timbr will not parse the SQL statement of the mapping and it will push it down to the datasource as-is.

Example Timbr CREATE MAPPING Example in SQL

CREATE MAPPING map_person 
INTO (person) USING mysql
AS 
    SELECT person_id as id, 
        firstname as first_name, 
        lastname as last_name,
        age as age, 
        birth_country as birth_country 
    FROM mydatabase.persons_table

---

Drop Mapping

Drop mapping is performed when users would like to drop a mapping having it deleted from the knowldge graph.

Assuming we'd like to drop the mapping of the concept Person in the ontology Explorer.

1. In the Ontology Explorer, right click on the concept Person and select Mappings.

2. In the window that appears on the right side next to the mapping you intend to drop click on the Trash can logo to drop the mapping.

3. In the warning message that appears, Click Confirm to confirm the dropping of the mapping. Once clicked the mapping will no longer exist in the knowledge graph.

Timbr DROP MAPPING Syntax in SQL

DROP MAPPING <mapping_name>

Drop Concept

Drop concept is performed when users would like to drop a concept altogether.

Assuming we'd like to drop the concept Person in the ontology Explorer.

Notice that a concept can't be droped if it has children concepts inheriting from it.

1. In the Ontology Explorer, right click on the concept Person and select Delete.

2. In the warning message that appears, Click to Confirm the dropping of the concept. Once clicked the concept will no longer exist in the knowledge graph.

Timbr DROP CONCEPT Syntax

DROP CONCEPT <concept_name>

---