Frequently Asked Questions

General

Ontology Implementation

Timbr offers a visual ontology modeler as well as a SQL DDL editor to easily model the ontology. timbr allows to conveniently generate concepts from the database schema, data catalogs or through importing existing OWL ontologies.

Timbr offers a visual data mapper to manually or semi-automatically select tables and columns from the database, as well as the option for coders to conveniently use SQL DDL statements. timbr can filter, clean and transfer the data that is been mapped to the ontology. No need for ETL operations.

timbr supports applying rules to concepts to classify the data or embed business logic in the ontology.
For Example:
Adult: Person where age > 21
ExpensiveProduct: Product where price > 1000.

timbr implements the Semantic Web in SQL. For this reason there’s a correspondence between OWL ontologies and SQL ontologies that is used by timbr to make the transformation. One example of such a process is timbr DBpedia.

Yes, timbr is transparent to the SQL user and uses the same dialect and syntax as the underlying database. You can add hints and use all the underlying database functionality.

timbr allows creating virtual PKs for concepts (used as unique identifiers), and FK to PKs in the ontology (used as relationships between concepts). As long as the ontology author maps the physical tables PKs to the ontology PKs, client join will follow these declarations. In the ontology, you can create relationships between concepts using FK statements. In each relationship, you specify the properties in the ontology that represent the relationship (used for the JOIN).

Yes, timbr is accessible in JDBC/ODBC and the ontology can be created programmatically using timbr SQL DDL statements:

CREATE CONCEPT (extension of CREATE TABLE statement)

CREATE MAPPING (extension of CREATE VIEW statement)

In many cases, we build small scripts to generate parts of the ontology programmatically.

The ontology definition is in SQL DDL statements and it is stored in timbr’s internal metadata DB.

You can access the ontology definitions using timbr system tables: SYS_CONCEPTS, SYS_RELATIONSHIPS, SYS_PROPERTIES, SYS_ONTOLOGY, SYS_MAPPINGS, etc.

No, any change to the ontology is immediately reflected to all the users. This means no downtime.

We plan to support GIT-like behavior, so ontologies can be deployed in a similar way to code.

Load More

Connectivity

Ontology Implementation

Timbr offers a visual ontology modeler as well as a SQL DDL editor to easily model the ontology. timbr allows to conveniently generate concepts from the database schema, data catalogs or through importing existing OWL ontologies.

Timbr offers a visual data mapper to manually or semi-automatically select tables and columns from the database, as well as the option for coders to conveniently use SQL DDL statements. timbr can filter, clean and transfer the data that is been mapped to the ontology. No need for ETL operations.

timbr supports applying rules to concepts to classify the data or embed business logic in the ontology.
For Example:
Adult: Person where age > 21
ExpensiveProduct: Product where price > 1000.

timbr implements the Semantic Web in SQL. For this reason there’s a correspondence between OWL ontologies and SQL ontologies that is used by timbr to make the transformation. One example of such a process is timbr DBpedia.

Yes, timbr is transparent to the SQL user and uses the same dialect and syntax as the underlying database. You can add hints and use all the underlying database functionality.

timbr allows creating virtual PKs for concepts (used as unique identifiers), and FK to PKs in the ontology (used as relationships between concepts). As long as the ontology author maps the physical tables PKs to the ontology PKs, client join will follow these declarations. In the ontology, you can create relationships between concepts using FK statements. In each relationship, you specify the properties in the ontology that represent the relationship (used for the JOIN).

Yes, timbr is accessible in JDBC/ODBC and the ontology can be created programmatically using timbr SQL DDL statements:

CREATE CONCEPT (extension of CREATE TABLE statement)

CREATE MAPPING (extension of CREATE VIEW statement)

In many cases, we build small scripts to generate parts of the ontology programmatically.

The ontology definition is in SQL DDL statements and it is stored in timbr’s internal metadata DB.

You can access the ontology definitions using timbr system tables: SYS_CONCEPTS, SYS_RELATIONSHIPS, SYS_PROPERTIES, SYS_ONTOLOGY, SYS_MAPPINGS, etc.

No, any change to the ontology is immediately reflected to all the users. This means no downtime.

We plan to support GIT-like behavior, so ontologies can be deployed in a similar way to code.

Load More

Ontology Implementation

Ontology Implementation

Timbr offers a visual ontology modeler as well as a SQL DDL editor to easily model the ontology. timbr allows to conveniently generate concepts from the database schema, data catalogs or through importing existing OWL ontologies.

Timbr offers a visual data mapper to manually or semi-automatically select tables and columns from the database, as well as the option for coders to conveniently use SQL DDL statements. timbr can filter, clean and transfer the data that is been mapped to the ontology. No need for ETL operations.

timbr supports applying rules to concepts to classify the data or embed business logic in the ontology.
For Example:
Adult: Person where age > 21
ExpensiveProduct: Product where price > 1000.

timbr implements the Semantic Web in SQL. For this reason there’s a correspondence between OWL ontologies and SQL ontologies that is used by timbr to make the transformation. One example of such a process is timbr DBpedia.

Yes, timbr is transparent to the SQL user and uses the same dialect and syntax as the underlying database. You can add hints and use all the underlying database functionality.

timbr allows creating virtual PKs for concepts (used as unique identifiers), and FK to PKs in the ontology (used as relationships between concepts). As long as the ontology author maps the physical tables PKs to the ontology PKs, client join will follow these declarations. In the ontology, you can create relationships between concepts using FK statements. In each relationship, you specify the properties in the ontology that represent the relationship (used for the JOIN).

Yes, timbr is accessible in JDBC/ODBC and the ontology can be created programmatically using timbr SQL DDL statements:

CREATE CONCEPT (extension of CREATE TABLE statement)

CREATE MAPPING (extension of CREATE VIEW statement)

In many cases, we build small scripts to generate parts of the ontology programmatically.

The ontology definition is in SQL DDL statements and it is stored in timbr’s internal metadata DB.

You can access the ontology definitions using timbr system tables: SYS_CONCEPTS, SYS_RELATIONSHIPS, SYS_PROPERTIES, SYS_ONTOLOGY, SYS_MAPPINGS, etc.

No, any change to the ontology is immediately reflected to all the users. This means no downtime.

We plan to support GIT-like behavior, so ontologies can be deployed in a similar way to code.

Load More

Performance

Ontology Implementation

Timbr offers a visual ontology modeler as well as a SQL DDL editor to easily model the ontology. timbr allows to conveniently generate concepts from the database schema, data catalogs or through importing existing OWL ontologies.

Timbr offers a visual data mapper to manually or semi-automatically select tables and columns from the database, as well as the option for coders to conveniently use SQL DDL statements. timbr can filter, clean and transfer the data that is been mapped to the ontology. No need for ETL operations.

timbr supports applying rules to concepts to classify the data or embed business logic in the ontology.
For Example:
Adult: Person where age > 21
ExpensiveProduct: Product where price > 1000.

timbr implements the Semantic Web in SQL. For this reason there’s a correspondence between OWL ontologies and SQL ontologies that is used by timbr to make the transformation. One example of such a process is timbr DBpedia.

Yes, timbr is transparent to the SQL user and uses the same dialect and syntax as the underlying database. You can add hints and use all the underlying database functionality.

timbr allows creating virtual PKs for concepts (used as unique identifiers), and FK to PKs in the ontology (used as relationships between concepts). As long as the ontology author maps the physical tables PKs to the ontology PKs, client join will follow these declarations. In the ontology, you can create relationships between concepts using FK statements. In each relationship, you specify the properties in the ontology that represent the relationship (used for the JOIN).

Yes, timbr is accessible in JDBC/ODBC and the ontology can be created programmatically using timbr SQL DDL statements:

CREATE CONCEPT (extension of CREATE TABLE statement)

CREATE MAPPING (extension of CREATE VIEW statement)

In many cases, we build small scripts to generate parts of the ontology programmatically.

The ontology definition is in SQL DDL statements and it is stored in timbr’s internal metadata DB.

You can access the ontology definitions using timbr system tables: SYS_CONCEPTS, SYS_RELATIONSHIPS, SYS_PROPERTIES, SYS_ONTOLOGY, SYS_MAPPINGS, etc.

No, any change to the ontology is immediately reflected to all the users. This means no downtime.

We plan to support GIT-like behavior, so ontologies can be deployed in a similar way to code.

Load More

Ontology Implementation

Timbr offers a visual ontology modeler as well as a SQL DDL editor to easily model the ontology. timbr allows to conveniently generate concepts from the database schema, data catalogs or through importing existing OWL ontologies.

Timbr offers a visual data mapper to manually or semi-automatically select tables and columns from the database, as well as the option for coders to conveniently use SQL DDL statements. timbr can filter, clean and transfer the data that is been mapped to the ontology. No need for ETL operations.

timbr supports applying rules to concepts to classify the data or embed business logic in the ontology.
For Example:
Adult: Person where age > 21
ExpensiveProduct: Product where price > 1000.

timbr implements the Semantic Web in SQL. For this reason there’s a correspondence between OWL ontologies and SQL ontologies that is used by timbr to make the transformation. One example of such a process is timbr DBpedia.

Yes, timbr is transparent to the SQL user and uses the same dialect and syntax as the underlying database. You can add hints and use all the underlying database functionality.

timbr allows creating virtual PKs for concepts (used as unique identifiers), and FK to PKs in the ontology (used as relationships between concepts). As long as the ontology author maps the physical tables PKs to the ontology PKs, client join will follow these declarations. In the ontology, you can create relationships between concepts using FK statements. In each relationship, you specify the properties in the ontology that represent the relationship (used for the JOIN).

Yes, timbr is accessible in JDBC/ODBC and the ontology can be created programmatically using timbr SQL DDL statements:

CREATE CONCEPT (extension of CREATE TABLE statement)

CREATE MAPPING (extension of CREATE VIEW statement)

In many cases, we build small scripts to generate parts of the ontology programmatically.

The ontology definition is in SQL DDL statements and it is stored in timbr’s internal metadata DB.

You can access the ontology definitions using timbr system tables: SYS_CONCEPTS, SYS_RELATIONSHIPS, SYS_PROPERTIES, SYS_ONTOLOGY, SYS_MAPPINGS, etc.

No, any change to the ontology is immediately reflected to all the users. This means no downtime.

We plan to support GIT-like behavior, so ontologies can be deployed in a similar way to code.

Load More