# Coming From Protégé
# Introduction
Many people have their first experience with knowledge graph virtualization using the Ontop plugin in Protégé (opens new window). Protégé is probably the most popular open source ontology editor and Ontop (opens new window) has been available as a plugin for many years and still serves its purpose very well.
When coming from Protégé, it's good to be aware of some important differences of the two applications, in order to avoid typical pitfalls when starting with Studio.
# 1) You Shall Not Write SQL
You do not need to write SQL queries when using Ontopic Studiuo. Never. Well, almost never. For the Protégé Ontop plugin, people typically write a SQL query as the target for the mapping entry. In many cases, this is a simple query, as simple as SELECT * FROM my_table. A typical example can be found in the mappings of the Ontop tutorial (opens new window):
In Ontopic Studio you rely on lenses for that, which serve very much the same purpose as the SQL statements in the Protégé plugin. The analogon of SELECT * FROM my_table is a direct lens, which can be created with a simple click, as described in the Ontopic Studio tutorial (opens new window). You can then add transformations to columns, drop columns, add calculated columns, filter rows and much more.
If you want to work on joined tables, again, resist the urge to write a SQL query. We have a specific lens for that, too. Select the lenses you want to join and then hit the “Create join lense" button.
Only for very specific cases, you will have to use SQL lenses.
Why should you prefer direct and join lenses over SQL lenses?
a) You can reuse the lens very easily for many mappings
b) Ontop and Ontopic Studio can analyze direct join lenses, so that they can safely apply many optimizations, not exploitable otherwise. SQL lenses are often "opaque" to Ontop and Ontopic Studio and many optimization opportunities are therefore missed
c) SQL lenses might be specific for a SQL dialect of a single vendor, whereas direct and join lenses are portable between different databases
d) Ontopic Studio provides a lot of guidance writing the lens, reducing the risk of mistypings and are therefore simpler to use
# 2) Reuse lenses extensively
In Protégé it’s pretty common to rewrite the same SQL statement for different mapping entries. Reasons for that might be the small text areas, so that adding too many mapping entries at once to the same target makes them difficult to read.
In Ontopic Studio, mapping entries related to a lens are shown in a list and there is hardly any reason to create more then one lens for the same table.
This makes it much easier to understand which mapping entry belongs to which table. It also saves a lot of time, since mapping the column of a table to the ontology becomes really straightforward.
# Conclusion
Taking into account the two tips above, you’ll be able to build highly scalable knowledge graphs with hundreds of mappings, which can also be easily managed in a team.