diff --git a/404.html b/404.html index b3f38c107..940efed0b 100644 --- a/404.html +++ b/404.html @@ -6,11 +6,11 @@ Ontop - +
- + diff --git a/assets/js/99.212bf210.js b/assets/js/99.e4d8db46.js similarity index 94% rename from assets/js/99.212bf210.js rename to assets/js/99.e4d8db46.js index 7f9eb9d4a..8287fe1eb 100644 --- a/assets/js/99.212bf210.js +++ b/assets/js/99.e4d8db46.js @@ -1 +1 @@ -(window.webpackJsonp=window.webpackJsonp||[]).push([[99],{476:function(t,a,e){"use strict";e.r(a);var o=e(51),s=Object(o.a)({},(function(){var t=this,a=t.$createElement,e=t._self._c||a;return e("ContentSlotsDistributor",{attrs:{"slot-key":t.$parent.slotKey}},[e("h1",{attrs:{id:"how-to-deploy-your-knowledge-graph-in-a-graph-database-with-ontop"}},[e("a",{staticClass:"header-anchor",attrs:{href:"#how-to-deploy-your-knowledge-graph-in-a-graph-database-with-ontop"}},[t._v("#")]),t._v(" How to deploy your Knowledge Graph in a graph database with Ontop")]),t._v(" "),e("p",[t._v("In this tutorial, we present two ways to materialize your Knowledge Graph using Ontop.")]),t._v(" "),e("h2",{attrs:{id:"how-to-materialize-data-into-a-graph-database-using-ontop"}},[e("a",{staticClass:"header-anchor",attrs:{href:"#how-to-materialize-data-into-a-graph-database-using-ontop"}},[t._v("#")]),t._v(" How to materialize data into a graph database using Ontop")]),t._v(" "),e("ol",[e("li",[e("h3",{attrs:{id:"materialize-in-rdf-files-and-load-into-a-triplestore"}},[e("a",{staticClass:"header-anchor",attrs:{href:"#materialize-in-rdf-files-and-load-into-a-triplestore"}},[t._v("#")]),t._v(" Materialize in RDF files and load into a triplestore")])])]),t._v(" "),e("p",[t._v("For the first solution, you will need the following prerequisites:")]),t._v(" "),e("ul",[e("li",[t._v("Access to a relational database (in our example PostgreSQL)")]),t._v(" "),e("li",[e("RouterLink",{attrs:{to:"/tutorial/glossary/#mapping"}},[t._v("Mapping")]),t._v(" ("),e("RouterLink",{attrs:{to:"/tutorial/glossary/#r2rml"}},[t._v("R2RML")]),t._v(" or "),e("RouterLink",{attrs:{to:"/tutorial/glossary/#obda_mapping_format"}},[t._v("OBDA")]),t._v(" files)")],1),t._v(" "),e("li",[e("a",{attrs:{href:"https://ontop-vkg.org/guide/cli.html#setup-ontop-cli",target:"_blank",rel:"noopener"}},[t._v("Ontop"),e("OutboundLink")],1)])]),t._v(" "),e("p",[t._v("Using the CLI command "),e("em",[t._v("ontop-materialize")]),t._v(" ("),e("a",{attrs:{href:"https://ontop-vkg.org/guide/cli#ontop-materialize",target:"_blank",rel:"noopener"}},[t._v("https://ontop-vkg.org/guide/cli#ontop-materialize"),e("OutboundLink")],1),t._v("), you can "),e("RouterLink",{attrs:{to:"/tutorial/glossary/#materialization"}},[t._v("materialize")]),t._v(" your KG into one or multiple files. For simplicity, we keep the default option and only materialize it into one file.")],1),t._v(" "),e("div",{staticClass:"language-bash extra-class"},[e("pre",{pre:!0,attrs:{class:"language-bash"}},[e("code",[t._v("./ontop materialize -m mapping.ttl -p credentials.properties -f turtle -o materialized-triples.ttl\n")])])]),e("p",[t._v("After running the command, we have all the content of our KG copied to the file "),e("em",[t._v("materialized-triples.ttl")]),t._v(".")]),t._v(" "),e("p",[t._v("Now we load this file in the triplestore of our choice, in this case, we use "),e("a",{attrs:{href:"https://www.ontotext.com/products/graphdb/download/",target:"_blank",rel:"noopener"}},[t._v("GraphDB"),e("OutboundLink")],1),t._v(". This graph database offers "),e("a",{attrs:{href:"https://graphdb.ontotext.com/documentation/10.2/loading-and-updating-data.html",target:"_blank",rel:"noopener"}},[t._v("several ways to load files"),e("OutboundLink")],1),t._v(". Here, since our file is only 200 MB, we go for the simplest option and load it directly from the UI.")]),t._v(" "),e("p",[t._v("Once this is done, we can query this KG using GraphDB.")]),t._v(" "),e("ol",{attrs:{start:"2"}},[e("li",[e("h3",{attrs:{id:"deploy-a-vkg-and-fetch-its-content-from-the-graph-database"}},[e("a",{staticClass:"header-anchor",attrs:{href:"#deploy-a-vkg-and-fetch-its-content-from-the-graph-database"}},[t._v("#")]),t._v(" Deploy a VKG and fetch its content from the graph database")])])]),t._v(" "),e("p",[t._v("For the second solution, we make use of the concept of KG virtualization.")]),t._v(" "),e("p",[t._v("We deploy the KG as a virtual KG first and then query it from the graph database. In this way, you can retrieve the triples and store them locally in the graph database.")]),t._v(" "),e("p",[t._v("Triples are directly streamed to the graph database: no intermediate file storage is involved, making this solution more direct than the previous one.")]),t._v(" "),e("p",[t._v("let’s deploy the KG as a virtual KG using the "),e("em",[t._v("ontop-endpoint")]),t._v(" command:")]),t._v(" "),e("div",{staticClass:"language-bash extra-class"},[e("pre",{pre:!0,attrs:{class:"language-bash"}},[e("code",[t._v("./ontop endpoint -m mapping.ttl -p credentials.properties\n")])])]),e("p",[t._v("Now Ontop is deployed as a "),e("RouterLink",{attrs:{to:"/tutorial/glossary/#sparql_endpoint"}},[t._v("SPARQL endpoint")]),t._v(" available at "),e("a",{attrs:{href:"http://localhost:8080/sparql",target:"_blank",rel:"noopener"}},[t._v("http://localhost:8080/sparql"),e("OutboundLink")],1),t._v(".")],1),t._v(" "),e("p",[t._v("Let’s go now to GraphDB. To fetch and insert all the triples from the VKG exposed by Ontop, we run the following SPARQL INSERT query from GraphDB itself:")]),t._v(" "),e("div",{staticClass:"language-sparql extra-class"},[e("pre",{pre:!0,attrs:{class:"language-sparql"}},[e("code",[e("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INSERT")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("{")]),t._v("\n "),e("span",{pre:!0,attrs:{class:"token variable"}},[t._v("?s")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token variable"}},[t._v("?p")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token variable"}},[t._v("?o")]),t._v("\n"),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("}")]),t._v("\n"),e("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("{")]),t._v("\n "),e("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SERVICE")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token url"}},[e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("<")]),t._v("http://localhost:8080/sparql"),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(">")])]),t._v(" "),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("{")]),t._v("\n "),e("span",{pre:!0,attrs:{class:"token variable"}},[t._v("?s")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token variable"}},[t._v("?p")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token variable"}},[t._v("?o")]),t._v("\n "),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("}")]),t._v("\n"),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("}")]),t._v("\n")])])]),e("p",[t._v("This query materializes the same triples as with the first approach.")]),t._v(" "),e("h2",{attrs:{id:"choosing-the-right-approach-for-your-use-case"}},[e("a",{staticClass:"header-anchor",attrs:{href:"#choosing-the-right-approach-for-your-use-case"}},[t._v("#")]),t._v(" Choosing the Right Approach for Your Use Case")]),t._v(" "),e("p",[t._v("1. "),e("strong",[t._v("Small Dataset, Easy Communication:")]),t._v(" If your dataset isn't large and you can easily set up communication between the Ontop SPARQL endpoint and the graph database, go with solution #2. It avoids dealing with files and intermediate storage.")]),t._v(" "),e("p",[t._v("2. "),e("strong",[t._v("Large Dataset, Efficient Loading:")]),t._v(" For very large datasets, choose the most efficient loading solution supported by the triplestore, even if it requires more effort to set up.")]),t._v(" "),e("p",[t._v("3. "),e("strong",[t._v("Materializing Fragments of the KG:")]),t._v(" Solution #2 allows easy materialization of specific fragments of the Knowledge Graph by adapting the SPARQL query. You can have hybrid KGs with some parts stored in the graph database and the rest kept virtual.")]),t._v(" "),e("p",[t._v("4. "),e("strong",[t._v("Advantage of Keeping Data Virtual:")]),t._v(" Keeping data virtual is great for large volumes of sensor data that constantly update. It's better to keep this part virtual while storing rich contextual information in the graph database.")]),t._v(" "),e("h2",{attrs:{id:"ontology-usage"}},[e("a",{staticClass:"header-anchor",attrs:{href:"#ontology-usage"}},[t._v("#")]),t._v(" Ontology Usage")]),t._v(" "),e("p",[t._v("If you're familiar with Ontop, you might have noticed that we didn't use an ontology in this example. Providing an ontology to Ontop can result in a significantly larger KG due to the reasoning capabilities embedded in Ontop. However, GraphDB also has reasoning capabilities, allowing reasoning to be done later in GraphDB, making materialization simpler and faster. If your graph database doesn't support reasoning, Ontop can handle it.")]),t._v(" "),e("h2",{attrs:{id:"mapping-options"}},[e("a",{staticClass:"header-anchor",attrs:{href:"#mapping-options"}},[t._v("#")]),t._v(" Mapping Options")]),t._v(" "),e("p",[t._v("Ontop supports any R2RML mapping as well as its native format (.obda). You can create these mappings manually or use Ontopic Studio, a no-code environment designed for designing knowledge graphs and managing large mappings.")])])}),[],!1,null,null,null);a.default=s.exports}}]); \ No newline at end of file +(window.webpackJsonp=window.webpackJsonp||[]).push([[99],{476:function(t,a,e){"use strict";e.r(a);var o=e(51),r=Object(o.a)({},(function(){var t=this,a=t.$createElement,e=t._self._c||a;return e("ContentSlotsDistributor",{attrs:{"slot-key":t.$parent.slotKey}},[e("h1",{attrs:{id:"how-to-deploy-your-knowledge-graph-in-a-graph-database-with-ontop"}},[e("a",{staticClass:"header-anchor",attrs:{href:"#how-to-deploy-your-knowledge-graph-in-a-graph-database-with-ontop"}},[t._v("#")]),t._v(" How to deploy your Knowledge Graph in a graph database with Ontop")]),t._v(" "),e("p",[t._v("In this tutorial, we present two ways to materialize your Knowledge Graph using Ontop.")]),t._v(" "),e("h2",{attrs:{id:"how-to-materialize-data-into-a-graph-database-using-ontop"}},[e("a",{staticClass:"header-anchor",attrs:{href:"#how-to-materialize-data-into-a-graph-database-using-ontop"}},[t._v("#")]),t._v(" How to materialize data into a graph database using Ontop")]),t._v(" "),e("ol",[e("li",[e("h3",{attrs:{id:"materialize-in-rdf-files-and-load-into-a-triplestore"}},[e("a",{staticClass:"header-anchor",attrs:{href:"#materialize-in-rdf-files-and-load-into-a-triplestore"}},[t._v("#")]),t._v(" Materialize in RDF files and load into a triplestore")])])]),t._v(" "),e("p",[t._v("For the first solution, you will need the following prerequisites:")]),t._v(" "),e("ul",[e("li",[t._v("Access to a relational database (in our example PostgreSQL)")]),t._v(" "),e("li",[e("RouterLink",{attrs:{to:"/tutorial/glossary/#mapping"}},[t._v("Mapping")]),t._v(" ("),e("RouterLink",{attrs:{to:"/tutorial/glossary/#r2rml"}},[t._v("R2RML")]),t._v(" or "),e("RouterLink",{attrs:{to:"/tutorial/glossary/#obda_mapping_format"}},[t._v("OBDA")]),t._v(" files)")],1),t._v(" "),e("li",[e("a",{attrs:{href:"https://ontop-vkg.org/guide/cli.html#setup-ontop-cli",target:"_blank",rel:"noopener"}},[t._v("Ontop"),e("OutboundLink")],1)])]),t._v(" "),e("p",[t._v("Using the CLI command "),e("em",[t._v("ontop-materialize")]),t._v(" ("),e("a",{attrs:{href:"https://ontop-vkg.org/guide/cli#ontop-materialize",target:"_blank",rel:"noopener"}},[t._v("https://ontop-vkg.org/guide/cli#ontop-materialize"),e("OutboundLink")],1),t._v("), you can "),e("RouterLink",{attrs:{to:"/tutorial/glossary/#materialization"}},[t._v("materialize")]),t._v(" your KG into one or multiple files. For simplicity, we keep the default option and only materialize it into one file.")],1),t._v(" "),e("div",{staticClass:"language-bash extra-class"},[e("pre",{pre:!0,attrs:{class:"language-bash"}},[e("code",[t._v("./ontop materialize -m mapping.ttl -p credentials.properties -f turtle -o materialized-triples.ttl\n")])])]),e("p",[t._v("After running the command, we have all the content of our KG copied to the file "),e("em",[t._v("materialized-triples.ttl")]),t._v(".")]),t._v(" "),e("p",[t._v("Now we load this file in the triplestore of our choice, in this case, we use "),e("a",{attrs:{href:"https://www.ontotext.com/products/graphdb/download/",target:"_blank",rel:"noopener"}},[t._v("GraphDB"),e("OutboundLink")],1),t._v(". This graph database offers "),e("a",{attrs:{href:"https://graphdb.ontotext.com/documentation/10.2/loading-and-updating-data.html",target:"_blank",rel:"noopener"}},[t._v("several ways to load files"),e("OutboundLink")],1),t._v(". Here, since our file is only 200 MB, we go for the simplest option and load it directly from the UI.")]),t._v(" "),e("p",[t._v("Once this is done, we can query this KG using GraphDB.")]),t._v(" "),e("ol",{attrs:{start:"2"}},[e("li",[e("h3",{attrs:{id:"deploy-a-vkg-and-fetch-its-content-from-the-graph-database"}},[e("a",{staticClass:"header-anchor",attrs:{href:"#deploy-a-vkg-and-fetch-its-content-from-the-graph-database"}},[t._v("#")]),t._v(" Deploy a VKG and fetch its content from the graph database")])])]),t._v(" "),e("p",[t._v("For the second solution, we make use of the concept of KG virtualization.")]),t._v(" "),e("p",[t._v("We deploy the KG as a virtual KG first and then query it from the graph database. In this way, you can retrieve the triples and store them locally in the graph database.")]),t._v(" "),e("p",[t._v("Triples are directly streamed to the graph database: no intermediate file storage is involved, making this solution more direct than the previous one.")]),t._v(" "),e("p",[t._v("let’s deploy the KG as a virtual KG using the "),e("em",[t._v("ontop-endpoint")]),t._v(" command:")]),t._v(" "),e("div",{staticClass:"language-bash extra-class"},[e("pre",{pre:!0,attrs:{class:"language-bash"}},[e("code",[t._v("./ontop endpoint -m mapping.ttl -p credentials.properties\n")])])]),e("p",[t._v("Now Ontop is deployed as a "),e("RouterLink",{attrs:{to:"/tutorial/glossary/#sparql_endpoint"}},[t._v("SPARQL endpoint")]),t._v(" available at "),e("a",{attrs:{href:"http://localhost:8080/sparql",target:"_blank",rel:"noopener"}},[t._v("http://localhost:8080/sparql"),e("OutboundLink")],1),t._v(".")],1),t._v(" "),e("p",[t._v("Let’s go now to GraphDB. To fetch and insert all the triples from the VKG exposed by Ontop, we run the following SPARQL INSERT query from GraphDB itself:")]),t._v(" "),e("div",{staticClass:"language-sparql extra-class"},[e("pre",{pre:!0,attrs:{class:"language-sparql"}},[e("code",[e("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INSERT")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("{")]),t._v("\n "),e("span",{pre:!0,attrs:{class:"token variable"}},[t._v("?s")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token variable"}},[t._v("?p")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token variable"}},[t._v("?o")]),t._v("\n"),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("}")]),t._v("\n"),e("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("{")]),t._v("\n "),e("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SERVICE")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token url"}},[e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("<")]),t._v("http://localhost:8080/sparql"),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(">")])]),t._v(" "),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("{")]),t._v("\n "),e("span",{pre:!0,attrs:{class:"token variable"}},[t._v("?s")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token variable"}},[t._v("?p")]),t._v(" "),e("span",{pre:!0,attrs:{class:"token variable"}},[t._v("?o")]),t._v("\n "),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("}")]),t._v("\n"),e("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("}")]),t._v("\n")])])]),e("p",[t._v("This query materializes the same triples as with the first approach.")]),t._v(" "),e("h2",{attrs:{id:"choosing-the-right-approach-for-your-use-case"}},[e("a",{staticClass:"header-anchor",attrs:{href:"#choosing-the-right-approach-for-your-use-case"}},[t._v("#")]),t._v(" Choosing the Right Approach for Your Use Case")]),t._v(" "),e("p",[t._v("1. "),e("strong",[t._v("Small Dataset, Easy Communication:")]),t._v(" If your dataset isn't large and you can easily set up communication between the Ontop SPARQL endpoint and the graph database, go with solution #2. It avoids dealing with files and intermediate storage.")]),t._v(" "),e("p",[t._v("2. "),e("strong",[t._v("Large Dataset, Efficient Loading:")]),t._v(" For very large datasets, choose the most efficient loading solution supported by the triplestore, even if it requires more effort to set up.")]),t._v(" "),e("p",[t._v("3. "),e("strong",[t._v("Materializing Fragments of the KG:")]),t._v(" Solution #2 allows easy materialization of specific fragments of the Knowledge Graph by adapting the SPARQL query. You can have hybrid KGs with some parts stored in the graph database and the rest kept virtual.")]),t._v(" "),e("p",[t._v("4. "),e("strong",[t._v("Advantage of Keeping Data Virtual:")]),t._v(" Keeping data virtual is great for large volumes of sensor data that constantly update. It's better to keep this part virtual while storing rich contextual information in the graph database.")]),t._v(" "),e("h2",{attrs:{id:"ontology-usage"}},[e("a",{staticClass:"header-anchor",attrs:{href:"#ontology-usage"}},[t._v("#")]),t._v(" Ontology Usage")]),t._v(" "),e("p",[t._v("If you're familiar with Ontop, you might have noticed that we didn't use an ontology in this example. Providing an ontology to Ontop can result in a significantly larger KG due to the reasoning capabilities embedded in Ontop. However, GraphDB also has reasoning capabilities, allowing reasoning to be done later in GraphDB, making materialization simpler and faster. If your graph database doesn't support reasoning, Ontop can handle it.")])])}),[],!1,null,null,null);a.default=r.exports}}]); \ No newline at end of file diff --git a/assets/js/app.646b0664.js b/assets/js/app.c5eeae50.js similarity index 92% rename from assets/js/app.646b0664.js rename to assets/js/app.c5eeae50.js index d4461d8a1..51008c7be 100644 --- a/assets/js/app.646b0664.js +++ b/assets/js/app.c5eeae50.js @@ -1,4 +1,4 @@ -(window.webpackJsonp=window.webpackJsonp||[]).push([[0],[]]);!function(t){function e(e){for(var r,a,l=e[0],s=e[1],u=e[2],f=0,p=[];f=0&&Math.floor(e)===e&&isFinite(t)}function d(t){return i(t)&&"function"==typeof t.then&&"function"==typeof t.catch}function h(t){return null==t?"":Array.isArray(t)||c(t)&&t.toString===u?JSON.stringify(t,null,2):String(t)}function v(t){var e=parseFloat(t);return isNaN(e)?t:e}function m(t,e){for(var n=Object.create(null),r=t.split(","),o=0;o-1)return t.splice(n,1)}}var b=Object.prototype.hasOwnProperty;function x(t,e){return b.call(t,e)}function _(t){var e=Object.create(null);return function(n){return e[n]||(e[n]=t(n))}}var w=/-(\w)/g,P=_((function(t){return t.replace(w,(function(t,e){return e?e.toUpperCase():""}))})),k=_((function(t){return t.charAt(0).toUpperCase()+t.slice(1)})),O=/\B([A-Z])/g,S=_((function(t){return t.replace(O,"-$1").toLowerCase()}));var E=Function.prototype.bind?function(t,e){return t.bind(e)}:function(t,e){function n(n){var r=arguments.length;return r?r>1?t.apply(e,arguments):t.call(e,n):t.call(e)}return n._length=t.length,n};function j(t,e){e=e||0;for(var n=t.length-e,r=new Array(n);n--;)r[n]=t[n+e];return r}function A(t,e){for(var n in e)t[n]=e[n];return t}function C(t){for(var e={},n=0;n0,Y=G&&G.indexOf("edge/")>0,X=(G&&G.indexOf("android"),G&&/iphone|ipad|ipod|ios/.test(G)||"ios"===Q),Z=(G&&/chrome\/\d+/.test(G),G&&/phantomjs/.test(G),G&&G.match(/firefox\/(\d+)/)),tt={}.watch,et=!1;if(H)try{var nt={};Object.defineProperty(nt,"passive",{get:function(){et=!0}}),window.addEventListener("test-passive",null,nt)}catch(t){}var rt=function(){return void 0===B&&(B=!H&&!W&&"undefined"!=typeof global&&(global.process&&"server"===global.process.env.VUE_ENV)),B},ot=H&&window.__VUE_DEVTOOLS_GLOBAL_HOOK__;function it(t){return"function"==typeof t&&/native code/.test(t.toString())}var at,lt="undefined"!=typeof Symbol&&it(Symbol)&&"undefined"!=typeof Reflect&&it(Reflect.ownKeys);at="undefined"!=typeof Set&&it(Set)?Set:function(){function t(){this.set=Object.create(null)}return t.prototype.has=function(t){return!0===this.set[t]},t.prototype.add=function(t){this.set[t]=!0},t.prototype.clear=function(){this.set=Object.create(null)},t}();var st=L,ut=0,ct=function(){this.id=ut++,this.subs=[]};ct.prototype.addSub=function(t){this.subs.push(t)},ct.prototype.removeSub=function(t){y(this.subs,t)},ct.prototype.depend=function(){ct.target&&ct.target.addDep(this)},ct.prototype.notify=function(){var t=this.subs.slice();for(var e=0,n=t.length;e-1)if(i&&!x(o,"default"))a=!1;else if(""===a||a===S(t)){var s=zt(String,o.type);(s<0||l0&&(fe((s=t(s,(n||"")+"_"+r))[0])&&fe(c)&&(f[u]=gt(c.text+s[0].text),s.shift()),f.push.apply(f,s)):l(s)?fe(c)?f[u]=gt(c.text+s):""!==s&&f.push(gt(s)):fe(s)&&fe(c)?f[u]=gt(c.text+s.text):(a(e._isVList)&&i(s.tag)&&o(s.key)&&i(n)&&(s.key="__vlist"+n+"_"+r+"__"),f.push(s)));return f}(t):void 0}function fe(t){return i(t)&&i(t.text)&&!1===t.isComment}function pe(t,e){if(t){for(var n=Object.create(null),r=lt?Reflect.ownKeys(t):Object.keys(t),o=0;o0,a=t?!!t.$stable:!i,l=t&&t.$key;if(t){if(t._normalized)return t._normalized;if(a&&n&&n!==r&&l===n.$key&&!i&&!n.$hasNormal)return n;for(var s in o={},t)t[s]&&"$"!==s[0]&&(o[s]=ge(e,s,t[s]))}else o={};for(var u in e)u in o||(o[u]=ye(e,u));return t&&Object.isExtensible(t)&&(t._normalized=o),F(o,"$stable",a),F(o,"$key",l),F(o,"$hasNormal",i),o}function ge(t,e,n){var r=function(){var t=arguments.length?n.apply(null,arguments):n({}),e=(t=t&&"object"==typeof t&&!Array.isArray(t)?[t]:ce(t))&&t[0];return t&&(!e||1===t.length&&e.isComment&&!ve(e))?void 0:t};return n.proxy&&Object.defineProperty(t,e,{get:r,enumerable:!0,configurable:!0}),r}function ye(t,e){return function(){return t[e]}}function be(t,e){var n,r,o,a,l;if(Array.isArray(t)||"string"==typeof t)for(n=new Array(t.length),r=0,o=t.length;rdocument.createEvent("Event").timeStamp&&(un=function(){return cn.now()})}function fn(){var t,e;for(sn=un(),an=!0,en.sort((function(t,e){return t.id-e.id})),ln=0;lnln&&en[n].id>t.id;)n--;en.splice(n+1,0,t)}else en.push(t);on||(on=!0,ne(fn))}}(this)},dn.prototype.run=function(){if(this.active){var t=this.get();if(t!==this.value||s(t)||this.deep){var e=this.value;if(this.value=t,this.user){var n='callback for watcher "'+this.expression+'"';Vt(this.cb,this.vm,[t,e],this.vm,n)}else this.cb.call(this.vm,t,e)}}},dn.prototype.evaluate=function(){this.value=this.get(),this.dirty=!1},dn.prototype.depend=function(){for(var t=this.deps.length;t--;)this.deps[t].depend()},dn.prototype.teardown=function(){if(this.active){this.vm._isBeingDestroyed||y(this.vm._watchers,this);for(var t=this.deps.length;t--;)this.deps[t].removeSub(this);this.active=!1}};var hn={enumerable:!0,configurable:!0,get:L,set:L};function vn(t,e,n){hn.get=function(){return this[e][n]},hn.set=function(t){this[e][n]=t},Object.defineProperty(t,n,hn)}function mn(t){t._watchers=[];var e=t.$options;e.props&&function(t,e){var n=t.$options.propsData||{},r=t._props={},o=t.$options._propKeys=[];t.$parent&&Pt(!1);var i=function(i){o.push(i);var a=Ut(i,e,n,t);St(r,i,a),i in t||vn(t,"_props",i)};for(var a in e)i(a);Pt(!0)}(t,e.props),e.methods&&function(t,e){t.$options.props;for(var n in e)t[n]="function"!=typeof e[n]?L:E(e[n],t)}(t,e.methods),e.data?function(t){var e=t.$options.data;c(e=t._data="function"==typeof e?function(t,e){pt();try{return t.call(e,e)}catch(t){return Bt(t,e,"data()"),{}}finally{dt()}}(e,t):e||{})||(e={});var n=Object.keys(e),r=t.$options.props,o=(t.$options.methods,n.length);for(;o--;){var i=n[o];0,r&&x(r,i)||(a=void 0,36!==(a=(i+"").charCodeAt(0))&&95!==a&&vn(t,"_data",i))}var a;Ot(e,!0)}(t):Ot(t._data={},!0),e.computed&&function(t,e){var n=t._computedWatchers=Object.create(null),r=rt();for(var o in e){var i=e[o],a="function"==typeof i?i:i.get;0,r||(n[o]=new dn(t,a||L,L,gn)),o in t||yn(t,o,i)}}(t,e.computed),e.watch&&e.watch!==tt&&function(t,e){for(var n in e){var r=e[n];if(Array.isArray(r))for(var o=0;o-1:"string"==typeof t?t.split(",").indexOf(e)>-1:!!f(t)&&t.test(e)}function jn(t,e){var n=t.cache,r=t.keys,o=t._vnode;for(var i in n){var a=n[i];if(a){var l=a.name;l&&!e(l)&&An(n,i,r,o)}}}function An(t,e,n,r){var o=t[e];!o||r&&o.tag===r.tag||o.componentInstance.$destroy(),t[e]=null,y(n,e)}!function(t){t.prototype._init=function(t){var e=this;e._uid=wn++,e._isVue=!0,t&&t._isComponent?function(t,e){var n=t.$options=Object.create(t.constructor.options),r=e._parentVnode;n.parent=e.parent,n._parentVnode=r;var o=r.componentOptions;n.propsData=o.propsData,n._parentListeners=o.listeners,n._renderChildren=o.children,n._componentTag=o.tag,e.render&&(n.render=e.render,n.staticRenderFns=e.staticRenderFns)}(e,t):e.$options=Dt(Pn(e.constructor),t||{},e),e._renderProxy=e,e._self=e,function(t){var e=t.$options,n=e.parent;if(n&&!e.abstract){for(;n.$options.abstract&&n.$parent;)n=n.$parent;n.$children.push(t)}t.$parent=n,t.$root=n?n.$root:t,t.$children=[],t.$refs={},t._watcher=null,t._inactive=null,t._directInactive=!1,t._isMounted=!1,t._isDestroyed=!1,t._isBeingDestroyed=!1}(e),function(t){t._events=Object.create(null),t._hasHookEvent=!1;var e=t.$options._parentListeners;e&&Je(t,e)}(e),function(t){t._vnode=null,t._staticTrees=null;var e=t.$options,n=t.$vnode=e._parentVnode,o=n&&n.context;t.$slots=de(e._renderChildren,o),t.$scopedSlots=r,t._c=function(e,n,r,o){return Fe(t,e,n,r,o,!1)},t.$createElement=function(e,n,r,o){return Fe(t,e,n,r,o,!0)};var i=n&&n.data;St(t,"$attrs",i&&i.attrs||r,null,!0),St(t,"$listeners",e._parentListeners||r,null,!0)}(e),tn(e,"beforeCreate"),function(t){var e=pe(t.$options.inject,t);e&&(Pt(!1),Object.keys(e).forEach((function(n){St(t,n,e[n])})),Pt(!0))}(e),mn(e),function(t){var e=t.$options.provide;e&&(t._provided="function"==typeof e?e.call(t):e)}(e),tn(e,"created"),e.$options.el&&e.$mount(e.$options.el)}}(kn),function(t){var e={get:function(){return this._data}},n={get:function(){return this._props}};Object.defineProperty(t.prototype,"$data",e),Object.defineProperty(t.prototype,"$props",n),t.prototype.$set=Et,t.prototype.$delete=jt,t.prototype.$watch=function(t,e,n){if(c(e))return _n(this,t,e,n);(n=n||{}).user=!0;var r=new dn(this,t,e,n);if(n.immediate){var o='callback for immediate watcher "'+r.expression+'"';pt(),Vt(e,this,[r.value],this,o),dt()}return function(){r.teardown()}}}(kn),function(t){var e=/^hook:/;t.prototype.$on=function(t,n){var r=this;if(Array.isArray(t))for(var o=0,i=t.length;o1?j(n):n;for(var r=j(arguments,1),o='event handler for "'+t+'"',i=0,a=n.length;iparseInt(this.max)&&An(t,e[0],e,this._vnode),this.vnodeToCache=null}}},created:function(){this.cache=Object.create(null),this.keys=[]},destroyed:function(){for(var t in this.cache)An(this.cache,t,this.keys)},mounted:function(){var t=this;this.cacheVNode(),this.$watch("include",(function(e){jn(t,(function(t){return En(e,t)}))})),this.$watch("exclude",(function(e){jn(t,(function(t){return!En(e,t)}))}))},updated:function(){this.cacheVNode()},render:function(){var t=this.$slots.default,e=He(t),n=e&&e.componentOptions;if(n){var r=Sn(n),o=this.include,i=this.exclude;if(o&&(!r||!En(o,r))||i&&r&&En(i,r))return e;var a=this.cache,l=this.keys,s=null==e.key?n.Ctor.cid+(n.tag?"::"+n.tag:""):e.key;a[s]?(e.componentInstance=a[s].componentInstance,y(l,s),l.push(s)):(this.vnodeToCache=e,this.keyToCache=s),e.data.keepAlive=!0}return e||t&&t[0]}}};!function(t){var e={get:function(){return q}};Object.defineProperty(t,"config",e),t.util={warn:st,extend:A,mergeOptions:Dt,defineReactive:St},t.set=Et,t.delete=jt,t.nextTick=ne,t.observable=function(t){return Ot(t),t},t.options=Object.create(null),I.forEach((function(e){t.options[e+"s"]=Object.create(null)})),t.options._base=t,A(t.options.components,Ln),function(t){t.use=function(t){var e=this._installedPlugins||(this._installedPlugins=[]);if(e.indexOf(t)>-1)return this;var n=j(arguments,1);return n.unshift(this),"function"==typeof t.install?t.install.apply(t,n):"function"==typeof t&&t.apply(null,n),e.push(t),this}}(t),function(t){t.mixin=function(t){return this.options=Dt(this.options,t),this}}(t),On(t),function(t){I.forEach((function(e){t[e]=function(t,n){return n?("component"===e&&c(n)&&(n.name=n.name||t,n=this.options._base.extend(n)),"directive"===e&&"function"==typeof n&&(n={bind:n,update:n}),this.options[e+"s"][t]=n,n):this.options[e+"s"][t]}}))}(t)}(kn),Object.defineProperty(kn.prototype,"$isServer",{get:rt}),Object.defineProperty(kn.prototype,"$ssrContext",{get:function(){return this.$vnode&&this.$vnode.ssrContext}}),Object.defineProperty(kn,"FunctionalRenderContext",{value:Me}),kn.version="2.6.14";var $n=m("style,class"),Tn=m("input,textarea,option,select,progress"),Mn=m("contenteditable,draggable,spellcheck"),Rn=m("events,caret,typing,plaintext-only"),Dn=m("allowfullscreen,async,autofocus,autoplay,checked,compact,controls,declare,default,defaultchecked,defaultmuted,defaultselected,defer,disabled,enabled,formnovalidate,hidden,indeterminate,inert,ismap,itemscope,loop,multiple,muted,nohref,noresize,noshade,novalidate,nowrap,open,pauseonexit,readonly,required,reversed,scoped,seamless,selected,sortable,truespeed,typemustmatch,visible"),In="http://www.w3.org/1999/xlink",Un=function(t){return":"===t.charAt(5)&&"xlink"===t.slice(0,5)},qn=function(t){return Un(t)?t.slice(6,t.length):""},Nn=function(t){return null==t||!1===t};function Fn(t){for(var e=t.data,n=t,r=t;i(r.componentInstance);)(r=r.componentInstance._vnode)&&r.data&&(e=zn(r.data,e));for(;i(n=n.parent);)n&&n.data&&(e=zn(e,n.data));return function(t,e){if(i(t)||i(e))return Bn(t,Vn(e));return""}(e.staticClass,e.class)}function zn(t,e){return{staticClass:Bn(t.staticClass,e.staticClass),class:i(t.class)?[t.class,e.class]:e.class}}function Bn(t,e){return t?e?t+" "+e:t:e||""}function Vn(t){return Array.isArray(t)?function(t){for(var e,n="",r=0,o=t.length;r-1?dr(t,e,n):Dn(e)?Nn(n)?t.removeAttribute(e):(n="allowfullscreen"===e&&"EMBED"===t.tagName?"true":e,t.setAttribute(e,n)):Mn(e)?t.setAttribute(e,function(t,e){return Nn(e)||"false"===e?"false":"contenteditable"===t&&Rn(e)?e:"true"}(e,n)):Un(e)?Nn(n)?t.removeAttributeNS(In,qn(e)):t.setAttributeNS(In,e,n):dr(t,e,n)}function dr(t,e,n){if(Nn(n))t.removeAttribute(e);else{if(J&&!K&&"TEXTAREA"===t.tagName&&"placeholder"===e&&""!==n&&!t.__ieph){var r=function(e){e.stopImmediatePropagation(),t.removeEventListener("input",r)};t.addEventListener("input",r),t.__ieph=!0}t.setAttribute(e,n)}}var hr={create:fr,update:fr};function vr(t,e){var n=e.elm,r=e.data,a=t.data;if(!(o(r.staticClass)&&o(r.class)&&(o(a)||o(a.staticClass)&&o(a.class)))){var l=Fn(e),s=n._transitionClasses;i(s)&&(l=Bn(l,Vn(s))),l!==n._prevClass&&(n.setAttribute("class",l),n._prevClass=l)}}var mr,gr={create:vr,update:vr};function yr(t,e,n){var r=mr;return function o(){var i=e.apply(null,arguments);null!==i&&_r(t,o,n,r)}}var br=Gt&&!(Z&&Number(Z[1])<=53);function xr(t,e,n,r){if(br){var o=sn,i=e;e=i._wrapper=function(t){if(t.target===t.currentTarget||t.timeStamp>=o||t.timeStamp<=0||t.target.ownerDocument!==document)return i.apply(this,arguments)}}mr.addEventListener(t,e,et?{capture:n,passive:r}:n)}function _r(t,e,n,r){(r||mr).removeEventListener(t,e._wrapper||e,n)}function wr(t,e){if(!o(t.data.on)||!o(e.data.on)){var n=e.data.on||{},r=t.data.on||{};mr=e.elm,function(t){if(i(t.__r)){var e=J?"change":"input";t[e]=[].concat(t.__r,t[e]||[]),delete t.__r}i(t.__c)&&(t.change=[].concat(t.__c,t.change||[]),delete t.__c)}(n),le(n,r,xr,_r,yr,e.context),mr=void 0}}var Pr,kr={create:wr,update:wr};function Or(t,e){if(!o(t.data.domProps)||!o(e.data.domProps)){var n,r,a=e.elm,l=t.data.domProps||{},s=e.data.domProps||{};for(n in i(s.__ob__)&&(s=e.data.domProps=A({},s)),l)n in s||(a[n]="");for(n in s){if(r=s[n],"textContent"===n||"innerHTML"===n){if(e.children&&(e.children.length=0),r===l[n])continue;1===a.childNodes.length&&a.removeChild(a.childNodes[0])}if("value"===n&&"PROGRESS"!==a.tagName){a._value=r;var u=o(r)?"":String(r);Sr(a,u)&&(a.value=u)}else if("innerHTML"===n&&Qn(a.tagName)&&o(a.innerHTML)){(Pr=Pr||document.createElement("div")).innerHTML=""+r+"";for(var c=Pr.firstChild;a.firstChild;)a.removeChild(a.firstChild);for(;c.firstChild;)a.appendChild(c.firstChild)}else if(r!==l[n])try{a[n]=r}catch(t){}}}}function Sr(t,e){return!t.composing&&("OPTION"===t.tagName||function(t,e){var n=!0;try{n=document.activeElement!==t}catch(t){}return n&&t.value!==e}(t,e)||function(t,e){var n=t.value,r=t._vModifiers;if(i(r)){if(r.number)return v(n)!==v(e);if(r.trim)return n.trim()!==e.trim()}return n!==e}(t,e))}var Er={create:Or,update:Or},jr=_((function(t){var e={},n=/:(.+)/;return t.split(/;(?![^(]*\))/g).forEach((function(t){if(t){var r=t.split(n);r.length>1&&(e[r[0].trim()]=r[1].trim())}})),e}));function Ar(t){var e=Cr(t.style);return t.staticStyle?A(t.staticStyle,e):e}function Cr(t){return Array.isArray(t)?C(t):"string"==typeof t?jr(t):t}var Lr,$r=/^--/,Tr=/\s*!important$/,Mr=function(t,e,n){if($r.test(e))t.style.setProperty(e,n);else if(Tr.test(n))t.style.setProperty(S(e),n.replace(Tr,""),"important");else{var r=Dr(e);if(Array.isArray(n))for(var o=0,i=n.length;o-1?e.split(qr).forEach((function(e){return t.classList.add(e)})):t.classList.add(e);else{var n=" "+(t.getAttribute("class")||"")+" ";n.indexOf(" "+e+" ")<0&&t.setAttribute("class",(n+e).trim())}}function Fr(t,e){if(e&&(e=e.trim()))if(t.classList)e.indexOf(" ")>-1?e.split(qr).forEach((function(e){return t.classList.remove(e)})):t.classList.remove(e),t.classList.length||t.removeAttribute("class");else{for(var n=" "+(t.getAttribute("class")||"")+" ",r=" "+e+" ";n.indexOf(r)>=0;)n=n.replace(r," ");(n=n.trim())?t.setAttribute("class",n):t.removeAttribute("class")}}function zr(t){if(t){if("object"==typeof t){var e={};return!1!==t.css&&A(e,Br(t.name||"v")),A(e,t),e}return"string"==typeof t?Br(t):void 0}}var Br=_((function(t){return{enterClass:t+"-enter",enterToClass:t+"-enter-to",enterActiveClass:t+"-enter-active",leaveClass:t+"-leave",leaveToClass:t+"-leave-to",leaveActiveClass:t+"-leave-active"}})),Vr=H&&!K,Hr="transition",Wr="transitionend",Qr="animation",Gr="animationend";Vr&&(void 0===window.ontransitionend&&void 0!==window.onwebkittransitionend&&(Hr="WebkitTransition",Wr="webkitTransitionEnd"),void 0===window.onanimationend&&void 0!==window.onwebkitanimationend&&(Qr="WebkitAnimation",Gr="webkitAnimationEnd"));var Jr=H?window.requestAnimationFrame?window.requestAnimationFrame.bind(window):setTimeout:function(t){return t()};function Kr(t){Jr((function(){Jr(t)}))}function Yr(t,e){var n=t._transitionClasses||(t._transitionClasses=[]);n.indexOf(e)<0&&(n.push(e),Nr(t,e))}function Xr(t,e){t._transitionClasses&&y(t._transitionClasses,e),Fr(t,e)}function Zr(t,e,n){var r=eo(t,e),o=r.type,i=r.timeout,a=r.propCount;if(!o)return n();var l="transition"===o?Wr:Gr,s=0,u=function(){t.removeEventListener(l,c),n()},c=function(e){e.target===t&&++s>=a&&u()};setTimeout((function(){s0&&(n="transition",c=a,f=i.length):"animation"===e?u>0&&(n="animation",c=u,f=s.length):f=(n=(c=Math.max(a,u))>0?a>u?"transition":"animation":null)?"transition"===n?i.length:s.length:0,{type:n,timeout:c,propCount:f,hasTransform:"transition"===n&&to.test(r[Hr+"Property"])}}function no(t,e){for(;t.length1}function so(t,e){!0!==e.data.show&&oo(e)}var uo=function(t){var e,n,r={},s=t.modules,u=t.nodeOps;for(e=0;eh?b(t,o(n[g+1])?null:n[g+1].elm,n,d,g,r):d>g&&_(e,p,h)}(p,m,g,n,c):i(g)?(i(t.text)&&u.setTextContent(p,""),b(p,null,g,0,g.length-1,n)):i(m)?_(m,0,m.length-1):i(t.text)&&u.setTextContent(p,""):t.text!==e.text&&u.setTextContent(p,e.text),i(h)&&i(d=h.hook)&&i(d=d.postpatch)&&d(t,e)}}}function O(t,e,n){if(a(n)&&i(t.parent))t.parent.data.pendingInsert=e;else for(var r=0;r-1,a.selected!==i&&(a.selected=i);else if(M(vo(a),r))return void(t.selectedIndex!==l&&(t.selectedIndex=l));o||(t.selectedIndex=-1)}}function ho(t,e){return e.every((function(e){return!M(e,t)}))}function vo(t){return"_value"in t?t._value:t.value}function mo(t){t.target.composing=!0}function go(t){t.target.composing&&(t.target.composing=!1,yo(t.target,"input"))}function yo(t,e){var n=document.createEvent("HTMLEvents");n.initEvent(e,!0,!0),t.dispatchEvent(n)}function bo(t){return!t.componentInstance||t.data&&t.data.transition?t:bo(t.componentInstance._vnode)}var xo={model:co,show:{bind:function(t,e,n){var r=e.value,o=(n=bo(n)).data&&n.data.transition,i=t.__vOriginalDisplay="none"===t.style.display?"":t.style.display;r&&o?(n.data.show=!0,oo(n,(function(){t.style.display=i}))):t.style.display=r?i:"none"},update:function(t,e,n){var r=e.value;!r!=!e.oldValue&&((n=bo(n)).data&&n.data.transition?(n.data.show=!0,r?oo(n,(function(){t.style.display=t.__vOriginalDisplay})):io(n,(function(){t.style.display="none"}))):t.style.display=r?t.__vOriginalDisplay:"none")},unbind:function(t,e,n,r,o){o||(t.style.display=t.__vOriginalDisplay)}}},_o={name:String,appear:Boolean,css:Boolean,mode:String,type:String,enterClass:String,leaveClass:String,enterToClass:String,leaveToClass:String,enterActiveClass:String,leaveActiveClass:String,appearClass:String,appearActiveClass:String,appearToClass:String,duration:[Number,String,Object]};function wo(t){var e=t&&t.componentOptions;return e&&e.Ctor.options.abstract?wo(He(e.children)):t}function Po(t){var e={},n=t.$options;for(var r in n.propsData)e[r]=t[r];var o=n._parentListeners;for(var i in o)e[P(i)]=o[i];return e}function ko(t,e){if(/\d-keep-alive$/.test(e.tag))return t("keep-alive",{props:e.componentOptions.propsData})}var Oo=function(t){return t.tag||ve(t)},So=function(t){return"show"===t.name},Eo={name:"transition",props:_o,abstract:!0,render:function(t){var e=this,n=this.$slots.default;if(n&&(n=n.filter(Oo)).length){0;var r=this.mode;0;var o=n[0];if(function(t){for(;t=t.parent;)if(t.data.transition)return!0}(this.$vnode))return o;var i=wo(o);if(!i)return o;if(this._leaving)return ko(t,o);var a="__transition-"+this._uid+"-";i.key=null==i.key?i.isComment?a+"comment":a+i.tag:l(i.key)?0===String(i.key).indexOf(a)?i.key:a+i.key:i.key;var s=(i.data||(i.data={})).transition=Po(this),u=this._vnode,c=wo(u);if(i.data.directives&&i.data.directives.some(So)&&(i.data.show=!0),c&&c.data&&!function(t,e){return e.key===t.key&&e.tag===t.tag}(i,c)&&!ve(c)&&(!c.componentInstance||!c.componentInstance._vnode.isComment)){var f=c.data.transition=A({},s);if("out-in"===r)return this._leaving=!0,se(f,"afterLeave",(function(){e._leaving=!1,e.$forceUpdate()})),ko(t,o);if("in-out"===r){if(ve(i))return u;var p,d=function(){p()};se(s,"afterEnter",d),se(s,"enterCancelled",d),se(f,"delayLeave",(function(t){p=t}))}}return o}}},jo=A({tag:String,moveClass:String},_o);function Ao(t){t.elm._moveCb&&t.elm._moveCb(),t.elm._enterCb&&t.elm._enterCb()}function Co(t){t.data.newPos=t.elm.getBoundingClientRect()}function Lo(t){var e=t.data.pos,n=t.data.newPos,r=e.left-n.left,o=e.top-n.top;if(r||o){t.data.moved=!0;var i=t.elm.style;i.transform=i.WebkitTransform="translate("+r+"px,"+o+"px)",i.transitionDuration="0s"}}delete jo.mode;var $o={Transition:Eo,TransitionGroup:{props:jo,beforeMount:function(){var t=this,e=this._update;this._update=function(n,r){var o=Ye(t);t.__patch__(t._vnode,t.kept,!1,!0),t._vnode=t.kept,o(),e.call(t,n,r)}},render:function(t){for(var e=this.tag||this.$vnode.data.tag||"span",n=Object.create(null),r=this.prevChildren=this.children,o=this.$slots.default||[],i=this.children=[],a=Po(this),l=0;l-1?Jn[t]=e.constructor===window.HTMLUnknownElement||e.constructor===window.HTMLElement:Jn[t]=/HTMLUnknownElement/.test(e.toString())},A(kn.options.directives,xo),A(kn.options.components,$o),kn.prototype.__patch__=H?uo:L,kn.prototype.$mount=function(t,e){return function(t,e,n){var r;return t.$el=e,t.$options.render||(t.$options.render=mt),tn(t,"beforeMount"),r=function(){t._update(t._render(),n)},new dn(t,r,L,{before:function(){t._isMounted&&!t._isDestroyed&&tn(t,"beforeUpdate")}},!0),n=!1,null==t.$vnode&&(t._isMounted=!0,tn(t,"mounted")),t}(this,t=t&&H?function(t){if("string"==typeof t){var e=document.querySelector(t);return e||document.createElement("div")}return t}(t):void 0,e)},H&&setTimeout((function(){q.devtools&&ot&&ot.emit("init",kn)}),0),e.default=kn},function(t,e,n){var r=n(3),o=n(28).f,i=n(17),a=n(14),l=n(81),s=n(125),u=n(105);t.exports=function(t,e){var n,c,f,p,d,h=t.target,v=t.global,m=t.stat;if(n=v?r:m?r[h]||l(h,{}):(r[h]||{}).prototype)for(c in e){if(p=e[c],f=t.noTargetGet?(d=o(n,c))&&d.value:n[c],!u(v?c:h+(m?".":"#")+c,t.forced)&&void 0!==f){if(typeof p==typeof f)continue;s(p,f)}(t.sham||f&&f.sham)&&i(p,"sham",!0),a(n,c,p,t)}}},function(t,e){t.exports=function(t){try{return!!t()}catch(t){return!0}}},function(t,e){var n=function(t){return t&&t.Math==Math&&t};t.exports=n("object"==typeof globalThis&&globalThis)||n("object"==typeof window&&window)||n("object"==typeof self&&self)||n("object"==typeof global&&global)||function(){return this}()||Function("return this")()},function(t,e,n){var r=n(3),o=n(55),i=n(8),a=n(56),l=n(82),s=n(119),u=o("wks"),c=r.Symbol,f=s?c:c&&c.withoutSetter||a;t.exports=function(t){return i(u,t)&&(l||"string"==typeof u[t])||(l&&i(c,t)?u[t]=c[t]:u[t]=f("Symbol."+t)),u[t]}},function(t,e){t.exports=function(t){return"object"==typeof t?null!==t:"function"==typeof t}},function(t,e,n){var r=n(5);t.exports=function(t){if(!r(t))throw TypeError(String(t)+" is not an object");return t}},function(t,e,n){var r=n(90),o=n(14),i=n(209);r||o(Object.prototype,"toString",i,{unsafe:!0})},function(t,e,n){var r=n(12),o={}.hasOwnProperty;t.exports=Object.hasOwn||function(t,e){return o.call(r(t),e)}},function(t,e,n){var r=n(2);t.exports=!r((function(){return 7!=Object.defineProperty({},1,{get:function(){return 7}})[1]}))},function(t,e,n){var r=n(9),o=n(120),i=n(6),a=n(57),l=Object.defineProperty;e.f=r?l:function(t,e,n){if(i(t),e=a(e),i(n),o)try{return l(t,e,n)}catch(t){}if("get"in n||"set"in n)throw TypeError("Accessors not supported");return"value"in n&&(t[e]=n.value),t}},function(t,e,n){"use strict";var r=n(139).charAt,o=n(16),i=n(27),a=n(124),l=i.set,s=i.getterFor("String Iterator");a(String,"String",(function(t){l(this,{type:"String Iterator",string:o(t),index:0})}),(function(){var t,e=s(this),n=e.string,o=e.index;return o>=n.length?{value:void 0,done:!0}:(t=r(n,o),e.index+=t.length,{value:t,done:!1})}))},function(t,e,n){var r=n(22);t.exports=function(t){return Object(r(t))}},function(t,e,n){var r=n(60),o=Math.min;t.exports=function(t){return t>0?o(r(t),9007199254740991):0}},function(t,e,n){var r=n(3),o=n(17),i=n(8),a=n(81),l=n(86),s=n(27),u=s.get,c=s.enforce,f=String(String).split("String");(t.exports=function(t,e,n,l){var s,u=!!l&&!!l.unsafe,p=!!l&&!!l.enumerable,d=!!l&&!!l.noTargetGet;"function"==typeof n&&("string"!=typeof e||i(n,"name")||o(n,"name",e),(s=c(n)).source||(s.source=f.join("string"==typeof e?e:""))),t!==r?(u?!d&&t[e]&&(p=!0):delete t[e],p?t[e]=n:o(t,e,n)):p?t[e]=n:a(e,n)})(Function.prototype,"toString",(function(){return"function"==typeof this&&u(this).source||l(this)}))},function(t,e,n){var r=n(3),o=n(140),i=n(118),a=n(17),l=n(4),s=l("iterator"),u=l("toStringTag"),c=i.values;for(var f in o){var p=r[f],d=p&&p.prototype;if(d){if(d[s]!==c)try{a(d,s,c)}catch(t){d[s]=c}if(d[u]||a(d,u,f),o[f])for(var h in i)if(d[h]!==i[h])try{a(d,h,i[h])}catch(t){d[h]=i[h]}}}},function(t,e,n){var r=n(58);t.exports=function(t){if(r(t))throw TypeError("Cannot convert a Symbol value to a string");return String(t)}},function(t,e,n){var r=n(9),o=n(10),i=n(44);t.exports=r?function(t,e,n){return o.f(t,e,i(1,n))}:function(t,e,n){return t[e]=n,t}},function(t,e){var n=Array.isArray;t.exports=n},function(t,e,n){var r=n(39),o=n(22);t.exports=function(t){return r(o(t))}},function(t,e,n){var r=n(3),o=function(t){return"function"==typeof t?t:void 0};t.exports=function(t,e){return arguments.length<2?o(r[t]):r[t]&&r[t][e]}},function(t,e,n){var r=n(152),o="object"==typeof self&&self&&self.Object===Object&&self,i=r||o||Function("return this")();t.exports=i},function(t,e){t.exports=function(t){if(null==t)throw TypeError("Can't call method on "+t);return t}},function(t,e){t.exports=!1},function(t,e){t.exports=function(t){if("function"!=typeof t)throw TypeError(String(t)+" is not a function");return t}},function(t,e,n){var r=n(63),o=n(39),i=n(12),a=n(13),l=n(141),s=[].push,u=function(t){var e=1==t,n=2==t,u=3==t,c=4==t,f=6==t,p=7==t,d=5==t||f;return function(h,v,m,g){for(var y,b,x=i(h),_=o(x),w=r(v,m,3),P=a(_.length),k=0,O=g||l,S=e?O(h,P):n||p?O(h,0):void 0;P>k;k++)if((d||k in _)&&(b=w(y=_[k],k,x),t))if(e)S[k]=b;else if(b)switch(t){case 3:return!0;case 5:return y;case 6:return k;case 2:s.call(S,y)}else switch(t){case 4:return!1;case 7:s.call(S,y)}return f?-1:u||c?c:S}};t.exports={forEach:u(0),map:u(1),filter:u(2),some:u(3),every:u(4),find:u(5),findIndex:u(6),filterReject:u(7)}},function(t,e,n){var r=n(238),o=n(241);t.exports=function(t,e){var n=o(t,e);return r(n)?n:void 0}},function(t,e,n){var r,o,i,a=n(193),l=n(3),s=n(5),u=n(17),c=n(8),f=n(80),p=n(61),d=n(42),h=l.WeakMap;if(a||f.state){var v=f.state||(f.state=new h),m=v.get,g=v.has,y=v.set;r=function(t,e){if(g.call(v,t))throw new TypeError("Object already initialized");return e.facade=t,y.call(v,t,e),e},o=function(t){return m.call(v,t)||{}},i=function(t){return g.call(v,t)}}else{var b=p("state");d[b]=!0,r=function(t,e){if(c(t,b))throw new TypeError("Object already initialized");return e.facade=t,u(t,b,e),e},o=function(t){return c(t,b)?t[b]:{}},i=function(t){return c(t,b)}}t.exports={set:r,get:o,has:i,enforce:function(t){return i(t)?o(t):r(t,{})},getterFor:function(t){return function(e){var n;if(!s(e)||(n=o(e)).type!==t)throw TypeError("Incompatible receiver, "+t+" required");return n}}}},function(t,e,n){var r=n(9),o=n(87),i=n(44),a=n(19),l=n(57),s=n(8),u=n(120),c=Object.getOwnPropertyDescriptor;e.f=r?c:function(t,e){if(t=a(t),e=l(e),u)try{return c(t,e)}catch(t){}if(s(t,e))return i(!o.f.call(t,e),t[e])}},function(t,e){t.exports=function(t){return null!=t&&"object"==typeof t}},function(t,e){var n={}.toString;t.exports=function(t){return n.call(t).slice(8,-1)}},function(t,e,n){var r,o=n(6),i=n(190),a=n(85),l=n(42),s=n(123),u=n(83),c=n(61),f=c("IE_PROTO"),p=function(){},d=function(t){return" + diff --git a/community/contributing/documentation.html b/community/contributing/documentation.html index c270ed62e..aad244ac6 100644 --- a/community/contributing/documentation.html +++ b/community/contributing/documentation.html @@ -6,7 +6,7 @@ Documentation | Ontop - + @@ -49,11 +49,11 @@ # start the local server yarn docs:dev # commit your changes and push them back to Github -

VuePress (opens new window) requires Node.js >= 8.6.

+

VuePress (opens new window) requires Node.js >= 8.6.

←

- + diff --git a/community/contributing/index.html b/community/contributing/index.html index ebb12c8ee..82484d2f5 100644 --- a/community/contributing/index.html +++ b/community/contributing/index.html @@ -6,7 +6,7 @@ How to contribute | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

# How to contribute

Contributions from the community are essential for an open-source project like Ontop and are warmly welcomed.

You can contribute in many differents ways, including:

+ (opens new window)

# How to contribute

Contributions from the community are essential for an open-source project like Ontop and are warmly welcomed.

You can contribute in many differents ways, including:

← →

- + diff --git a/community/contributing/pull-request.html b/community/contributing/pull-request.html index 125d66e39..ff2410df9 100644 --- a/community/contributing/pull-request.html +++ b/community/contributing/pull-request.html @@ -6,7 +6,7 @@ Pull request | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

# Pull request

Contributions to the project are welcome and encouraged. You can propose some Pull Requests (PR) on Github. By making a PR on the Github platform, you declare to agree with the standard "inbound = outbound" licensing practice, as foreseen by the Github terms (opens new window). There is no need anymore for regular contributors to sign a CLA.

If you are thinking about implementing a new feature, feel free to engage a discussion with the team through the mailing list or through another medium.

# Contribution License Agreement (for core developers)

Core developers should sign a Contribution License Agreement (CLA) that allows FUB and the Ontop team to redistribute their work under the terms of the Apache 2.0 license. If the contributor works for an institution that owns the work being contributed by the contributor, then a corporate CLA must be additionally signed. The CLAs are available for download below, once signed please email a scanned copy of them.

+ (opens new window)

# Pull request

Contributions to the project are welcome and encouraged. You can propose some Pull Requests (PR) on Github. By making a PR on the Github platform, you declare to agree with the standard "inbound = outbound" licensing practice, as foreseen by the Github terms (opens new window). There is no need anymore for regular contributors to sign a CLA.

If you are thinking about implementing a new feature, feel free to engage a discussion with the team through the mailing list or through another medium.

# Contribution License Agreement (for core developers)

Core developers should sign a Contribution License Agreement (CLA) that allows FUB and the Ontop team to redistribute their work under the terms of the Apache 2.0 license. If the contributor works for an institution that owns the work being contributed by the contributor, then a corporate CLA must be additionally signed. The CLAs are available for download below, once signed please email a scanned copy of them.

← →

- + diff --git a/community/index.html b/community/index.html index 7e572ae66..d41478a57 100644 --- a/community/index.html +++ b/community/index.html @@ -6,7 +6,7 @@ People | Ontop - + @@ -43,11 +43,11 @@ GitHub (opens new window)

# People

Ontop has been initiated by the eponymous research group at the Free University of Bozen-Bolzano which is still highly involved into the development of the project and into the research around it. Over the years, new members from diverse horizons have joined the project, forming a vibrant international community.

Here we list the people who has been involved in the development of the Ontop project. -For the research side, see the dedicated page.

# Active Core Team Members

The development of Ontop is guided by an international team (reverse lexicographical order).

# Core Team Emeriti

Here we honor some no-longer-active core team members who have made important contributions in the past.

# Contributors

Some members of the Ontop community have so enriched it, that they deserve special mention.

  • Lukas Sundqvist
  • Mindaugas Slusnys
  • Damian Rovara
  • Sergey Pugacs
  • Tomas Kovachev
  • Dag Hovland
  • Manfred Gerstgrasser
  • Uğur Dönmez
  • Timea Bagosi

+For the research side, see the dedicated page.

# Active Core Team Members

The development of Ontop is guided by an international team (reverse lexicographical order).

# Core Team Emeriti

Here we honor some no-longer-active core team members who have made important contributions in the past.

# Contributors

Some members of the Ontop community have so enriched it, that they deserve special mention.

  • Lukas Sundqvist
  • Mindaugas Slusnys
  • Damian Rovara
  • Sergey Pugacs
  • Tomas Kovachev
  • Dag Hovland
  • Manfred Gerstgrasser
  • Uğur Dönmez
  • Timea Bagosi

Organizations →

- + diff --git a/community/organizations.html b/community/organizations.html index 52b400a33..4d5dd18f4 100644 --- a/community/organizations.html +++ b/community/organizations.html @@ -6,7 +6,7 @@ Organizations | Ontop - + @@ -47,7 +47,7 @@ Ontopic provides a no-code mapping editor, Ontopic Studio, (opens new window) and professional services.

# Birkbeck, University of London

The Birkbeck (opens new window) group have been extensively involved in the development of Ontop since 2012. They have worked on the theoretical foundations of the VKG approach, including -query rewriting and optimisation, and contributed to the code base.

+query rewriting and optimisation, and contributed to the code base.

← →

- + diff --git a/community/support.html b/community/support.html index 396a3c772..dbf54c8ad 100644 --- a/community/support.html +++ b/community/support.html @@ -6,7 +6,7 @@ Support | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

# Support

# FAQ

Please visit our pages about Frequently Asked Questions.

# Mailing list (Google group)

We have a mailing list (Google group) (opens new window) for anything related to support, discussion and announcements. Please join for any inquiry.

# Bug tracking system

To see the list of open issues/bugs, visit our GitHub tracker (opens new window)

# Commercial support

Ontopic (opens new window) is offering commercial support for Ontop.

+ (opens new window)

# Support

# FAQ

Please visit our pages about Frequently Asked Questions.

# Mailing list (Google group)

We have a mailing list (Google group) (opens new window) for anything related to support, discussion and announcements. Please join for any inquiry.

# Bug tracking system

To see the list of open issues/bugs, visit our GitHub tracker (opens new window)

# Commercial support

Ontopic (opens new window) is offering commercial support for Ontop.

← →

- + diff --git a/dev/build.html b/dev/build.html index 38f8278cf..8c09f3169 100644 --- a/dev/build.html +++ b/dev/build.html @@ -6,7 +6,7 @@ Build Ontop Bundles | Ontop - + @@ -60,7 +60,7 @@

The command compiles Ontop modules and generates the Ontop bundles distributed on GitHub, whose files are written in two directories.

Under build/distribution/target/:

  • ontop-cli-[ontop-version].zip - libraries/scripts to use ontop from the command line and setup a SPARQL endpoint;

Under protege/distribution/target/:

  • it.unibz.inf.ontop.protege-[ontop-version].jar - plugin for Protégé 5.x installation files (drop it in Protégé’s plugins folder);
  • ontop-protege-bundle-platform-independent-[ontop-version].zip - Protégé 5.x bundled with Ontop plugin and ready to run (just unzip and use the run.sh or run.bat scripts);
  • ontop-protege-bundle-linux-[ontop-version].zip - as above, for Linux;
  • ontop-protege-bundle-os-x-[ontop-version].zip - as above, for Mac OS X;
  • ontop-protege-bundle-win-[ontop-version].zip - as above, for Windows.

Notes:

  • profile activation -Prelease enables the generation of all the Ontop bundles as well as source code and Javadoc JARs needed for publishing on Maven Central (if this profile is omitted, only JAR files for Ontop binaries are created);
  • option -Dmaven.test.skip disables the compiling and execution of unit and integration tests (generally performed at release time) to speed up the process - omit it to enable tests, e.g., for testing changes to source code (note: may also use -DskipTests that disables executing tests, but still compiles them);
  • the build may be performed also by running script build-release.sh (build-release.cmd on Windows), which works also in older Ontop versions (4.0.3 or earlier). In these older versions, the script generates bundles in sub-directories ontop-cli, ontop-protege, and ontop-webapps of directory build/distribution, and also generates bundles for Jetty 9 + RDF4J workbench + Ontop and for Tomcat 8 + RDF4J workbench + Ontop. These bundles have been deprecated in Ontop 4 (opens new window) and completely removed since Ontop 5 (opens new window).

# Build specific bundles

Starting from version 4.1 and further revised in version 5.0.2, we provide Maven profiles to build specific Ontop bundles as quickly as possible (with respect to using the above 'build all' command), which may come in handy when modifying Ontop source code. Specifically:

  • to build the Ontop command line tool only, i.e., ontop-cli-[ontop-version].zip (note: up to version 5.0.1, asset-cli was cli and tests were disabled by default)

    $ mvn -Dmaven.test.skip -Passet-cli

  • to build the Ontop Protégé plugin, i.e., it.unibz.inf.ontop.protege-[ontop-version].jar (profile available since version 5.0.2)

    $ mvn -Dmaven.test.skip -Passet-plugin

  • to build the Ontop Protégé plugin it.unibz.inf.ontop.protege-[ontop-version].jar as well as the ontop-protege-bundle-[platform]-[ontop-version].zip Protégé bundles including it (note: up to version 5.0.1, asset-protege was protege and tests were disabled by default)

    $ mvn -Dmaven.test.skip -Passet-protege
-

The Maven profiles asset-cli, asset-plugin, asset-protege employed in the commands above exclude unneeded artifacts from the build, which is thus faster. These profiles can be arbitrarily combined to produce multiple bundles, e.g., mvn -Passet-cli,asset-protege to generate both command line tool and Protégé bundles (from version 4.1 up to version 5 excluded, it was possible to build the RDF4 workbench + Ontop files by enabling profile webapps, now removed).

# Compiling the Ontop Protégé plugin

Starting from version 5.0.2, it is necessary to enable profile plugin (or a profile depending on it, such as asset-plugin, asset-protege, or release) in order to compile ontop-protege-plugin. Note that commands mvn compile and mvn test will not work with profile plugin (or a depending profile) since compiling/testing ontop-protege-plugin requires building ontop-protege-dependencies:shaded first to relocate Guava via the Maven shade plugin (opens new window), but this happens only during the package lifecycle phase of Maven, i.e., starting from mvn package or later phase. Unfortunately, relocating Guava is needed to avoid conflicts with the older Guava version used in Protégé and cannot be avoided, and doing that before the package phase is not feasible. Therefore, developers should always use mvn package -Pplugin or later phase when working with ontop-protege-plugin, even when just compiling or testing is intended.

# Other useful Maven commands

The following Maven commands can be used to facilitate some build-related development tasks, the involved plugins (e.g., license-maven-plugin) being already configured in Ontop root pom.xml file:

  • mvn license:add-third-party - produces a report file build/distribution/THIRD-PARTY.txt useful to verify the use of Java libraries with compatible licenses
  • mvn org.codehaus.mojo:versions-maven-plugin:display-plugin-updates - check for Maven plugins that can be updated
  • mvn org.codehaus.mojo:versions-maven-plugin:display-dependency-updates - check for dependencies that can be updated
  • mvn dependency:analyze-duplicate - check there are no duplicate dependencies declared in pom.xml files
  • mvn dependency:analyze-dep-mgt - check that dependency versions under centralized <dependencyManagement> sections are not overridden in child pom.xml files
  • mvn dependency:analyze - check for used and undeclared dependencies and for unused and declared dependencies (both situations that should be avoided)
  • mvn com.github.ekryd.sortpom:sortpom-maven-plugin:sort - sorts section of pom.xml files, to improve consistency
  • mvn net.revelc.code.formatter:formatter-maven-plugin:format - auto-formats the pom.xml files, to improve consistency

+

The Maven profiles asset-cli, asset-plugin, asset-protege employed in the commands above exclude unneeded artifacts from the build, which is thus faster. These profiles can be arbitrarily combined to produce multiple bundles, e.g., mvn -Passet-cli,asset-protege to generate both command line tool and Protégé bundles (from version 4.1 up to version 5 excluded, it was possible to build the RDF4 workbench + Ontop files by enabling profile webapps, now removed).

# Compiling the Ontop Protégé plugin

Starting from version 5.0.2, it is necessary to enable profile plugin (or a profile depending on it, such as asset-plugin, asset-protege, or release) in order to compile ontop-protege-plugin. Note that commands mvn compile and mvn test will not work with profile plugin (or a depending profile) since compiling/testing ontop-protege-plugin requires building ontop-protege-dependencies:shaded first to relocate Guava via the Maven shade plugin (opens new window), but this happens only during the package lifecycle phase of Maven, i.e., starting from mvn package or later phase. Unfortunately, relocating Guava is needed to avoid conflicts with the older Guava version used in Protégé and cannot be avoided, and doing that before the package phase is not feasible. Therefore, developers should always use mvn package -Pplugin or later phase when working with ontop-protege-plugin, even when just compiling or testing is intended.

# Other useful Maven commands

The following Maven commands can be used to facilitate some build-related development tasks, the involved plugins (e.g., license-maven-plugin) being already configured in Ontop root pom.xml file:

  • mvn license:add-third-party - produces a report file build/distribution/THIRD-PARTY.txt useful to verify the use of Java libraries with compatible licenses
  • mvn org.codehaus.mojo:versions-maven-plugin:display-plugin-updates - check for Maven plugins that can be updated
  • mvn org.codehaus.mojo:versions-maven-plugin:display-dependency-updates - check for dependencies that can be updated
  • mvn dependency:analyze-duplicate - check there are no duplicate dependencies declared in pom.xml files
  • mvn dependency:analyze-dep-mgt - check that dependency versions under centralized <dependencyManagement> sections are not overridden in child pom.xml files
  • mvn dependency:analyze - check for used and undeclared dependencies and for unused and declared dependencies (both situations that should be avoided)
  • mvn com.github.ekryd.sortpom:sortpom-maven-plugin:sort - sorts section of pom.xml files, to improve consistency
  • mvn net.revelc.code.formatter:formatter-maven-plugin:format - auto-formats the pom.xml files, to improve consistency

← →

- + diff --git a/dev/db-adapter.html b/dev/db-adapter.html index 7bd2f9c39..8600fe6d9 100644 --- a/dev/db-adapter.html +++ b/dev/db-adapter.html @@ -6,7 +6,7 @@ Support a new database system | Ontop - + @@ -239,7 +239,7 @@ }); } } -

+

← →

- + diff --git a/dev/debug-jetty.html b/dev/debug-jetty.html index c9434c27c..290b56f5e 100644 --- a/dev/debug-jetty.html +++ b/dev/debug-jetty.html @@ -6,7 +6,7 @@ Debug Jetty | Ontop - + @@ -43,7 +43,7 @@ GitHub (opens new window)

# Debug Jetty

This page describe debug Jetty with RDF4J workbench plugin in IntelliJ Idea

# Start the Jetty in Debug mode

$ java -Xdebug -agentlib:jdwp=transport=dt_socket,address=9999,server=y,suspend=n -jar start.jar
-

# Linking with IntelliJ

Next we need to link the IntelliJ project with the deployed webapp.

  1. Within IntelliJ, open the project containing the webapp deployed into jetty that you want to debug. SelectRun -> Edit Configurations. Add a new configuration by clicking the "+" icon. Choose Remote. Make sure the port you choose is the same as the one you added in Enable remote debugging.

  2. Next in your webapp you can set a breakpoint within a servlet which when it is tripped will halt the remote jvm's processing thread to await for debugging commands from your IntelliJ instance. To set a breakpoint, simply open the servlet or any other class you want to debug and click left to the line you want to set the breakpoint at (where the red dot is on the next screenshot). The red dot and red background on the line mark the breakpoint.

  3. Accessing that servlet within your browser, pointed at your remote debug configurated jetty-distribution, should transition your IntelliJ instance to the standard debugger view.

# References

  1. http://www.eclipse.org/jetty/documentation/current/enable-remote-debugging.html (opens new window)
  2. http://www.eclipse.org/jetty/documentation/current/debugging-with-intellij.html (opens new window)

+

# Linking with IntelliJ

Next we need to link the IntelliJ project with the deployed webapp.

  1. Within IntelliJ, open the project containing the webapp deployed into jetty that you want to debug. SelectRun -> Edit Configurations. Add a new configuration by clicking the "+" icon. Choose Remote. Make sure the port you choose is the same as the one you added in Enable remote debugging.

  2. Next in your webapp you can set a breakpoint within a servlet which when it is tripped will halt the remote jvm's processing thread to await for debugging commands from your IntelliJ instance. To set a breakpoint, simply open the servlet or any other class you want to debug and click left to the line you want to set the breakpoint at (where the red dot is on the next screenshot). The red dot and red background on the line mark the breakpoint.

  3. Accessing that servlet within your browser, pointed at your remote debug configurated jetty-distribution, should transition your IntelliJ instance to the standard debugger view.

# References

  1. http://www.eclipse.org/jetty/documentation/current/enable-remote-debugging.html (opens new window)
  2. http://www.eclipse.org/jetty/documentation/current/debugging-with-intellij.html (opens new window)

← →

- + diff --git a/dev/debug-protege.html b/dev/debug-protege.html index b4714d7c8..de37a583f 100644 --- a/dev/debug-protege.html +++ b/dev/debug-protege.html @@ -6,7 +6,7 @@ Debug Protégé | Ontop - + @@ -49,7 +49,7 @@

Where:

  • clean package forces a full re-build and may be generally omitted (which defaults to running package) unless you encounter build errors, in which case clean helps ruling out they stem from incremental builds;
  • -Dmaven.test.skip disables compiling and executing unit tests;
  • -Passet-plugin activates the generation of the Ontop Protégé plugin (OSGI bundle with all its dependencies), without including other uneeded artifacts (e.g., full ZIP/tar.gz Protégé bundles, source and Javadoc JARs, etc);
  • -pl protege/distribution -am (optional) tells Maven to only build the Ontop Protégé module located in protege/distribution and all the other Ontop modules it depends on, saving another couple of seconds.

Notes:

  • in Ontop versions 4.1 to 5.0.0 excluded, the command above should be replaced by mvn clean package -Dmaven.test.skip -Pprotege -pl client/protege -am;
  • in Ontop version 4.0.3 or earlier, the command above should be replaced by mvn clean install -pl client/protege -am -DskipTests to compile code and install it in local maven repository, followed by mvn bundle:bundle -pl client/protege to package the plugin.

Once the Ontop Protégé plugin is built, it must be copied to the Protégé plugin directory via

$ cp protege/distribution/target/it.unibz.inf.ontop.protege-[ontop-version].jar Protege-[protege-version]/plugins/

The command above should replace any previous Ontop Protégé plugin in the plugins directory. In any case, make sure that there is only one Protégé plugin in Protege-[protege-version]/plugins/

# Debug in IntelliJ using the Remote debugger

# IntelliJ configuration

Create a remote configuration:

  • select 'Edit configurations', click '+', then select 'Remote'
  • Host: localhost
  • Port: choose a port number (5005 in what follows)

# Protégé run options

Edit the script Protege-[protege-version]/run.sh (on Windows: run.bat), adding the following JVM option (note that parameter suspend is set to y)

-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005

# Run / Debug

Execute Protege-[protege-version]/run.sh (on Windows: run.bat). -Then, from IntelliJ, click on the Debug button (or Shift+F9).

+Then, from IntelliJ, click on the Debug button (or Shift+F9).

← →

- + diff --git a/dev/git.html b/dev/git.html index d055cd57a..42ac9d7fe 100644 --- a/dev/git.html +++ b/dev/git.html @@ -6,7 +6,7 @@ Git workflow | Ontop - + @@ -43,7 +43,7 @@ GitHub (opens new window)

# Git workflow

In the development of Ontop project, we follow the following git-workflow: http://nvie.com/posts/a-successful-git-branching-model/ (opens new window)

A few points:

  • Main development branch: version4. Every commit in this branch is expected to be shipped with the next x.y.0 release.

  • Names of the branches:

    • feature branches: feature/featurename
    • bug fix branches: bugfix/bugname. -
      • If there a corresponding GitHub page, use name bugfix/bugname-issue-number or bugfix/issue-number
    • Maintenance branches for releases: releasing/vx.y (e.g. releasing/v4.0)

  • Use --no-ff option for merging, especially for merging the the feature or bugfix branches to version4

The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.

+

  • If there a corresponding GitHub page, use name bugfix/bugname-issue-number or bugfix/issue-number
  • Maintenance branches for releases: releasing/vx.y (e.g. releasing/v4.0)

  • Use --no-ff option for merging, especially for merging the the feature or bugfix branches to version4

    • The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.

    ← →

    - + diff --git a/dev/index.html b/dev/index.html index 69b51ecf9..3c562b460 100644 --- a/dev/index.html +++ b/dev/index.html @@ -6,7 +6,7 @@ Overview | Ontop - + @@ -43,11 +43,11 @@ GitHub (opens new window)

    # Overview

    The development chapter is targeted to those interested in the development of the Ontop framework.

    # How-tos

    # Internals

    Information about the internals of Ontop

    +

    # Internals

    Information about the internals of Ontop

    Git workflow →

    - + diff --git a/dev/internals/guice.html b/dev/internals/guice.html index f80257c26..5c26cfd6d 100644 --- a/dev/internals/guice.html +++ b/dev/internals/guice.html @@ -6,7 +6,7 @@ Guice Conventions | Ontop - + @@ -79,7 +79,7 @@ public SimpleRDF() { } ... -

    As you see, in the end we reach a constructor without parameters.

    In IntelliJ, the name of the properties file binding a specific interface can also be retrieved through the find usages functionality.

    +

    As you see, in the end we reach a constructor without parameters.

    In IntelliJ, the name of the properties file binding a specific interface can also be retrieved through the find usages functionality.

    ← →

    - + diff --git a/dev/internals/iq.html b/dev/internals/iq.html index 00f5a54ee..81ff3b554 100644 --- a/dev/internals/iq.html +++ b/dev/internals/iq.html @@ -6,7 +6,7 @@ Intermediate Query (IQ) | Ontop - + @@ -74,7 +74,7 @@ as well as complex mapping assertions (which, in most scenarios, contains SQL queries). -This is also why the rule-based internal representation has been progressively abandoned.

    +This is also why the rule-based internal representation has been progressively abandoned.

    ← →

    - + diff --git a/dev/new-release.html b/dev/new-release.html index fdbbe85b3..0037c4afa 100644 --- a/dev/new-release.html +++ b/dev/new-release.html @@ -6,7 +6,7 @@ Make a new release | Ontop - + @@ -70,7 +70,7 @@ # this step is also for triggering the AutoUpdate of Protege plugin $ git checkout master $ git merge v-number # tag -

    # Time for celebration!

    • Send release emails to several mail lists and social media

    +

    # Time for celebration!

    • Send release emails to several mail lists and social media

    ← →

    - + diff --git a/dev/outdated/known-issues.html b/dev/outdated/known-issues.html index 0e732b492..9da09232b 100644 --- a/dev/outdated/known-issues.html +++ b/dev/outdated/known-issues.html @@ -6,7 +6,7 @@ Known issues | Ontop - + @@ -69,11 +69,11 @@ a language tag then the language tag will be parsed out of the lexical value. For example, "abc@en"^^rdf:PlainLiteral would be parsed into a lexical value of 'abc' and a language tag of 'en'. "

    Thus, if one expects such symbols in an object property the best solutions are:

    1. cast the object to string in the mapping
    2. replace the @ in the query with @.

    # Databases and SQL

    • Registered Keywords - when you have a column name that is also a registered DBMS keyword, you should enclose that column name in quotes. Supported common keywords are: cast, do, extract, first, following, last, materialized, nulls, partition, range, row, rows, siblings, value, xml.
    • ORDER BY in H2: in presence of an Union, the last version of H2 (1.4.), it orders both subqueries independently of each other giving wrong results. See SPARQL-compliance test offset-1
    • UNOPTIMIZED SQL OPERATORS/FUNCTIONS: MIN/MAX, CASE, WHEN clause, DATE FUNCTIONS, NESTED SELECTS, MATCHES, RIGHT/FULL/SELF/CARTESIAN JOIN, SUBJOIN, ALL, ANY, UNION, INTERSECT, MINUM and EXCEPT: Unoptimized sql operators will be transformed in view and generate a result.
    • UNSUPPORTED SQL OPERATORS: EXISTS, UNIQUE, TOP
    • REGEX OPERATOR is not supported by MsSQL and DB2, while the other databases handle it differently

    # R2RML mappings

    WARNING

    Are Bnodes supported in the mapping?

    • no support for inverseExpression
    • predicate cannot be uritemplate (column reference or template declaration)
    • object cannot be uritemplate (column reference or template declaration) when predicate is rdf:type
    • no support for bnode in Ontop
    • no support for sqlversion
    • no support for graphMaps (hence context graphs)
    • bnode naming is arbitrary
    • constant type objects are returned as simple literal. Constant-valued term maps are not considered as having a term type, and specifying rr:termType on these term maps has no effect. For example we return "2011-01-04T00:00:00.0" -instead of "2011-01-04T00:00:00.0"^^xsd:dateTime

    The current state of the W3C R2RML compliance tests could be seen [[W3C-R2RML-Compliance| here]]

    # Ontop Bootstrapper

    WARNING

    Are Bnodes supported in the mapping?

    • The BNode syntax generated by Ontop bootstrapper cannot be processed by Ontop
    • Foreign keys on multiple columns are not supported

    +instead of "2011-01-04T00:00:00.0"^^xsd:dateTime

    The current state of the W3C R2RML compliance tests could be seen [[W3C-R2RML-Compliance| here]]

    # Ontop Bootstrapper

    WARNING

    Are Bnodes supported in the mapping?

    • The BNode syntax generated by Ontop bootstrapper cannot be processed by Ontop
    • Foreign keys on multiple columns are not supported

    ←

    - + diff --git a/dev/stats.html b/dev/stats.html index 34b28f202..32dd91062 100644 --- a/dev/stats.html +++ b/dev/stats.html @@ -6,7 +6,7 @@ Statistics | Ontop - + @@ -44,7 +44,7 @@ GitHub (opens new window)

    # Statistics

    # Downloads

    # Github releases

    For all the versions 4.x:

    curl -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/ontop/ontop/releases \
    | jq '[.[] | select((.tag_name | startswith("ontop-4."))) | .assets[] | .download_count ] | add' 
-

    +

    ← →

    - + diff --git a/guide/advanced/caching.html b/guide/advanced/caching.html index 79e6936c5..0c958a60f 100644 --- a/guide/advanced/caching.html +++ b/guide/advanced/caching.html @@ -6,7 +6,7 @@ HTTP caching | Ontop - + @@ -45,7 +45,7 @@ (opens new window)

    # HTTP caching

    Since 4.1.0.

    HTTP caching allows to reduce the load on the SPARQL endpoint and to provide faster responses to clients. It is particularly useful when many clients issue the same queries and data is not updated at a high frequency.

    To enable HTTP caching, add the property ontop.http.cacheControl in the properties file. This will cause the insertion of a Cache-Control (opens new window) HTTP header in successful responses, with the specified value.

    Example

    ontop.http.cacheControl=max-age=60, stale-while-revalidate=20, stale-if-error=300
-

    This entry informs the cache that values can be considered as fresh for 60 seconds. After this period, the cache remains allowed to serve cached results for 20 more seconds while revalidating the requests in the background, or for 300 more seconds in case of error with the upstream server.

    Ontop does not embed a HTTP cache. We recommend setting up a HTTP cache like Varnish (opens new window) or Nginx (opens new window) above the Ontop endpoint.

    # Remarks

    • Most caches (e.g. Nginx but also Web browsers) do not cache POST requests by default. Since most SPARQL queries are sent with the POST method, it is important to turn this option on. This option is safe as Ontop is a read-only system.
    • Consider using the GET method for sending SPARQL queries so as to take advantage from Web browser caches.
    • For an example of configuration for Nginx, see this file (opens new window).

    +

    This entry informs the cache that values can be considered as fresh for 60 seconds. After this period, the cache remains allowed to serve cached results for 20 more seconds while revalidating the requests in the background, or for 300 more seconds in case of error with the upstream server.

    Ontop does not embed a HTTP cache. We recommend setting up a HTTP cache like Varnish (opens new window) or Nginx (opens new window) above the Ontop endpoint.

    # Remarks

    • Most caches (e.g. Nginx but also Web browsers) do not cache POST requests by default. Since most SPARQL queries are sent with the POST method, it is important to turn this option on. This option is safe as Ontop is a read-only system.
    • Consider using the GET method for sending SPARQL queries so as to take advantage from Web browser caches.
    • For an example of configuration for Nginx, see this file (opens new window).

    ← →

    - + diff --git a/guide/advanced/configuration.html b/guide/advanced/configuration.html index ba913932c..075d27c2f 100644 --- a/guide/advanced/configuration.html +++ b/guide/advanced/configuration.html @@ -6,7 +6,7 @@ Configuration keys | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

    # Configuration keys

    Here is a list of the configuration keys which can be set in the properties file.

    + (opens new window)

    # Configuration keys

    Here is a list of the configuration keys which can be set in the properties file.

    ← →

    - + diff --git a/guide/advanced/lenses.html b/guide/advanced/lenses.html index 1bda20381..8c7714de9 100644 --- a/guide/advanced/lenses.html +++ b/guide/advanced/lenses.html @@ -6,7 +6,7 @@ Lenses | Ontop - + @@ -222,7 +222,7 @@
    Key Type Description
    added Array of Strings List of names of non-nullable columns. One String per column

    # IRISafeConstraint

    {
     "added": [String]
 }
-
    Key Type Description
    added Array of Strings List of names of IRI-safe columns. One String per column

    +

    Key Type Description
    added Array of Strings List of names of IRI-safe columns. One String per column

    ← →

    - + diff --git a/guide/advanced/logging.html b/guide/advanced/logging.html index 71c55475e..7eb1aec91 100644 --- a/guide/advanced/logging.html +++ b/guide/advanced/logging.html @@ -6,7 +6,7 @@ Query logging | Ontop - + @@ -92,7 +92,7 @@ ontop.queryLogging.decomposition=false # Sets that merged messages are only inserted when decomposition is disabled ontop.queryLogging.decompositionAndMergingMutuallyExclusive=true -

    +

    ← →

    - + diff --git a/guide/advanced/predefined.html b/guide/advanced/predefined.html index 8de4a1acc..037ddc9e1 100644 --- a/guide/advanced/predefined.html +++ b/guide/advanced/predefined.html @@ -6,7 +6,7 @@ Predefined query endpoint (beta) | Ontop - + @@ -113,7 +113,7 @@ "@type": "LodgingBusiness", "name": "Alpenblick - Gasthaus" } -

    # Entries

    # Top-level key

    Key Type Description
    queries Map of predefined queries Groups predefined queries by id.

    # Query keys

    Key Type Description
    queryType String At the moment, only graph is supported. Corresponds to CONSTRUCT queries.
    name String Name of the predefined query.
    description String Description of the predefined query.
    return404IfEmpty Boolean If true, returns a 404 status code when the result set is empty.
    resultStreaming Boolean If true, uses the chunked transfer encoding.
    parameters Map of parameters Groups parameters by id.
    frame JSON object JSON-LD frame (opens new window)) for shaping the result set when the JSON-LD format is selected.

    # Parameter keys

    Key Type Description
    description String Description of the parameter.
    type String Type of the parameter. Can be iri for an IRI, any XSD datatype like xsd:string with the prefix xsd: or the IRI string of an RDF datatype.
    safeForRandomGeneration Boolean If true, replacing the parameter value by a random value for generating a "reference" reformulated query can be considered as safe. Replacing afterwards the random value but the real parameter value in the reference reformulated query should produce the expected result. Usually, identifiers are safe while languages are not because the columns to consider differ from a language to another.
    required Boolean If true, a value must be given for this parameter in the HTTP request.

    +

    # Entries

    # Top-level key

    Key Type Description
    queries Map of predefined queries Groups predefined queries by id.

    # Query keys

    Key Type Description
    queryType String At the moment, only graph is supported. Corresponds to CONSTRUCT queries.
    name String Name of the predefined query.
    description String Description of the predefined query.
    return404IfEmpty Boolean If true, returns a 404 status code when the result set is empty.
    resultStreaming Boolean If true, uses the chunked transfer encoding.
    parameters Map of parameters Groups parameters by id.
    frame JSON object JSON-LD frame (opens new window)) for shaping the result set when the JSON-LD format is selected.

    # Parameter keys

    Key Type Description
    description String Description of the parameter.
    type String Type of the parameter. Can be iri for an IRI, any XSD datatype like xsd:string with the prefix xsd: or the IRI string of an RDF datatype.
    safeForRandomGeneration Boolean If true, replacing the parameter value by a random value for generating a "reference" reformulated query can be considered as safe. Replacing afterwards the random value but the real parameter value in the reference reformulated query should produce the expected result. Usually, identifiers are safe while languages are not because the columns to consider differ from a language to another.
    required Boolean If true, a value must be given for this parameter in the HTTP request.

    ← →

    - + diff --git a/guide/advanced/views.html b/guide/advanced/views.html index 82f065d3c..f4e926418 100644 --- a/guide/advanced/views.html +++ b/guide/advanced/views.html @@ -6,7 +6,7 @@ Ontop views | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

    # Ontop views

    Ontop views have been renamed lenses. See the new page.

    - + (opens new window)

    # Ontop views

    Ontop views have been renamed lenses. See the new page.

    + diff --git a/guide/cli.html b/guide/cli.html index 4372ad079..7ba3af6d4 100644 --- a/guide/cli.html +++ b/guide/cli.html @@ -6,7 +6,7 @@ Command Line Interface | Ontop - + @@ -464,7 +464,7 @@ "idFactoryType" : "POSTGRESQL" } } -

    +

    ← →

    - + diff --git a/guide/compliance.html b/guide/compliance.html index 3310cac18..b613d3646 100644 --- a/guide/compliance.html +++ b/guide/compliance.html @@ -6,7 +6,7 @@ Standards compliance | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

    # Standards compliance

    # SPARQL 1.1

    Updated for 5.0.0.

    In the following table we present a summary of the compliance of the latest version of Ontop with SPARQL 1.1 (opens new window), where rows correspond to sections of the WC3 recommendation and unsupported features are crossed out. Most of the features are supported, but some are unsupported or only partially supported.

    Section in
    SPARQL 1.1
    		 Features Coverage
    5. Graph Patterns (opens new window) BGP, FILTER 2/2
    6. Including Optional Values (opens new window) OPTIONAL 1/1
    7. Matching Alternatives (opens new window) UNION 1/1
    8. Negation (opens new window) MINUS, FILTER [NOT] EXISTS 1/2
    9. Property Paths (opens new window) PredicatePath, InversePath, ZeroOrMorePath, ... 0
    10. Assignment (opens new window) BIND, VALUES 2/2
    11. Aggregates (opens new window) COUNT, SUM, MIN, MAX, AVG, GROUP_CONCAT, SAMPLE 6/6
    12. Subqueries (opens new window) Subqueries 1/1
    13. RDF Dataset (opens new window) GRAPH, FROM [NAMED] 2/2
    14. Basic Federated Query (opens new window) SERVICE 0
    15. Solution Seqs. & Mods. (opens new window) ORDER BY, SELECT, DISTINCT, REDUCED, OFFSET, LIMIT 6/6
    16. Query Forms (opens new window) SELECT, CONSTRUCT, ASK, DESCRIBE 4/4
    17.4.1. Functional Forms (opens new window) BOUND, IF, COALESCE, EXISTS, NOT EXISTS, || , &&, =, sameTerm, IN, NOT IN 9/11
    17.4.2. Functions on RDF Terms (opens new window) isIRI, isBlank, isLiteral, isNumeric, str, lang, datatype, IRI, BNODE, STRDT, STRLANG, UUID, STRUUID 11/13
    17.4.3. Functions on Strings (opens new window) STRLEN, SUBSTR, UCASE, LCASE, STRSTARTS, STRENDS, CONTAINS, STRBEFORE, STRAFTER, ENCODE_FOR_URI, CONCAT, langMatches, REGEX, REPLACE 14/14
    17.4.4. Functions on Numerics (opens new window) abs, round, ceil, floor, RAND 5/5
    17.4.5. Functions on Dates&Times (opens new window) now, year, month, day, hours, minutes, seconds, timezone, tz 8/9
    17.4.6. Hash Functions (opens new window) MD5, SHA1, SHA256, SHA384, SHA512 5/5
    17.5 XPath Constructor Functions (opens new window) casting 0
    17.6 Extensible Value Testing (opens new window) user defined functions 0

    # Limitations

    • The 5 hash functions and functions REPLACE and REGEX for regular expressions have limited support because they heavily depend on the DBMS: not all DBMSs provide all hash functions, and many DBMSs have their own regex dialects. Currently, the SPARQL regular expressions of REPLACE and REGEX are simply sent to the DBMS.
    • In the implementation of function langMatches, the second argument has to a be a constant: allowing variables will have a negative impact on the performance in our framework.

    # GeoSPARQL 1.0

    Starting from 4.1.0.

    The following table provides a summary of the compliance of the latest version of Ontop with OGC GeoSPARQL 1.0 (opens new window), the standard for representing and querying geospatial linked data. The summary focuses only on the main geospatial functions and properties and unsupported features are crossed out.

    Section in OGC GeoSPARQL 1.0
    		 Features Coverage
    7. Topology Vocabulary Extensions - Properties geo:sfEquals, geo:sfDisjoint, geo:sfIntersects, geo:sfTouches, geo:sfCrosses, geo:sfWithin, geo:sfContains, geo:sfOverlaps, geo:ehEquals, geo:ehDisjoint, geo:ehMeet, geo:ehOverlap, geo:ehCovers, geo:ehCoveredBy, geo:ehInside, geo:ehContains, geo:rcc8eq, geo:rcc8dc, geo:rcc8ec, geo:rcc8po, geo:rcc8tppi, geo:rcc8tpp, geo:rcc8ntpp, geo:rcc8ntppi 0
    8.4. Standard Properties for Geo:Geometry geo:dimension, geo:coordinateDimension, geo:spatialDimension, geo:isEmpty, geo:isSimple, geo:hasSerialization 0
    8.5. WKT Serialization geo:wktLiteral, geo:asWKT 2/2
    8.6. GML Serialization geo:gmlLiteral, geo:asGML 0
    8.7. Non-Topological Query Functions geof:distance, geof:buffer, geof:convexHull , geof:intersection, geof:union, geof:difference geof:symDifference, geof:envelope, geof:boundary, geof:getSRID, 10/10
    9.2. Common Query Functions geof:relate 1/1
    9.3. Topological Simple Features Relation Family Query Functions geof:sfEquals, geof:sfDisjoint, geof:sfIntersects, geof:sfTouches, geof:sfCrosses, geof:sfWithin, geof:sfContains, geof:sfOverlaps 8/8
    9.4. Topological Egenhofer Relation Family Query Functions geof:ehEquals, geof:ehDisjoint, geof:ehMeet, geof:ehOverlap, geof:ehCovers, geof:ehCoveredBy, geof:ehInside, geof:ehContains 8/8
    9.5. Topological RCC8 Relation Family Query Functions geof:rcc8eq, geof:rcc8dc, geof:rcc8ec, geof:rcc8po, geof:rcc8tppi, geof:rcc8tpp, geof:rcc8ntpp, geof:rcc8ntppi 8/8

    Several non-topological query functions use a unit of measure URI which OGC defines under a specific namespace e.g. <http://www.opengis.net/def/uom/OGC/1.0/metre>. The latest version of Ontop currently supports the units metre, radian and degree.

    # R2RML

    Updated for 4.2.0

    The latest version of Ontop is almost fully compliant with the R2RML (opens new window) standard.

    At the moment, it does NOT support:

    For complex SQL queries (e.g. with a GROUP BY) in the mapping, Ontop may not be able to infer the datatype of each column if the option ontop.allowRetrievingBlackBoxViewMetadataFromDB is not enabled (disabled by default). In such a situation, it may not be able to derive the natural RDF datatype (opens new window) of a literal built over a column and may not apply the expected normalization. This can be partially mitigated by expliciting the RDF datatype in the mapping, but normalization would remain unapplied.

    # RDF 1.1

    Ontop complies with RDF 1.1 (opens new window). It types simple literals (from RDF 1.0) as xsd:string and literals with a language tag as rdf:langString.

    # OWL 2 QL

    # RDFS

    # Time functions

    Since 4.2.0.

    These functions use the prefix ofn (http://www.ontotext.com/sparql/functions/) and their documentation can be found here (opens new window). They accept both xsd:date and xsd:dateTime as arguments.

    Ofn Function
    		 Argument 1 Argument 2
    ofn:weeksBetween xsd:date xsd:date
    ofn:weeksBetween xsd:dateTime xsd:dateTime
    ofn:weeksBetween* xsd:date xsd:dateTime
    ofn:weeksBetween* xsd:dateTime xsd:date
    ofn:daysBetween xsd:date xsd:date
    ofn:daysBetween xsd:dateTime xsd:dateTime
    ofn:daysBetween* xsd:date xsd:dateTime
    ofn:daysBetween* xsd:dateTime xsd:date
    ofn:hoursBetween xsd:dateTime xsd:dateTime
    ofn:minutesBetween xsd:dateTime xsd:dateTime
    ofn:secondsBetween xsd:dateTime xsd:dateTime
    ofn:millisBetween xsd:dateTime xsd:dateTime

    Combinations of argument datatypes marked with the symbol * are not supported for queries over the following data sources: Oracle and Microsoft SQL Server.

    + (opens new window)

    # Standards compliance

    # SPARQL 1.1

    Updated for 5.0.0.

    In the following table we present a summary of the compliance of the latest version of Ontop with SPARQL 1.1 (opens new window), where rows correspond to sections of the WC3 recommendation and unsupported features are crossed out. Most of the features are supported, but some are unsupported or only partially supported.

    Section in
    SPARQL 1.1
    		 Features Coverage
    5. Graph Patterns (opens new window) BGP, FILTER 2/2
    6. Including Optional Values (opens new window) OPTIONAL 1/1
    7. Matching Alternatives (opens new window) UNION 1/1
    8. Negation (opens new window) MINUS, FILTER [NOT] EXISTS 1/2
    9. Property Paths (opens new window) PredicatePath, InversePath, ZeroOrMorePath, ... 0
    10. Assignment (opens new window) BIND, VALUES 2/2
    11. Aggregates (opens new window) COUNT, SUM, MIN, MAX, AVG, GROUP_CONCAT, SAMPLE 6/6
    12. Subqueries (opens new window) Subqueries 1/1
    13. RDF Dataset (opens new window) GRAPH, FROM [NAMED] 2/2
    14. Basic Federated Query (opens new window) SERVICE 0
    15. Solution Seqs. & Mods. (opens new window) ORDER BY, SELECT, DISTINCT, REDUCED, OFFSET, LIMIT 6/6
    16. Query Forms (opens new window) SELECT, CONSTRUCT, ASK, DESCRIBE 4/4
    17.4.1. Functional Forms (opens new window) BOUND, IF, COALESCE, EXISTS, NOT EXISTS, || , &&, =, sameTerm, IN, NOT IN 9/11
    17.4.2. Functions on RDF Terms (opens new window) isIRI, isBlank, isLiteral, isNumeric, str, lang, datatype, IRI, BNODE, STRDT, STRLANG, UUID, STRUUID 11/13
    17.4.3. Functions on Strings (opens new window) STRLEN, SUBSTR, UCASE, LCASE, STRSTARTS, STRENDS, CONTAINS, STRBEFORE, STRAFTER, ENCODE_FOR_URI, CONCAT, langMatches, REGEX, REPLACE 14/14
    17.4.4. Functions on Numerics (opens new window) abs, round, ceil, floor, RAND 5/5
    17.4.5. Functions on Dates&Times (opens new window) now, year, month, day, hours, minutes, seconds, timezone, tz 8/9
    17.4.6. Hash Functions (opens new window) MD5, SHA1, SHA256, SHA384, SHA512 5/5
    17.5 XPath Constructor Functions (opens new window) casting 0
    17.6 Extensible Value Testing (opens new window) user defined functions 0

    # Limitations

    • The 5 hash functions and functions REPLACE and REGEX for regular expressions have limited support because they heavily depend on the DBMS: not all DBMSs provide all hash functions, and many DBMSs have their own regex dialects. Currently, the SPARQL regular expressions of REPLACE and REGEX are simply sent to the DBMS.
    • In the implementation of function langMatches, the second argument has to a be a constant: allowing variables will have a negative impact on the performance in our framework.

    # GeoSPARQL 1.0

    Starting from 4.1.0.

    The following table provides a summary of the compliance of the latest version of Ontop with OGC GeoSPARQL 1.0 (opens new window), the standard for representing and querying geospatial linked data. The summary focuses only on the main geospatial functions and properties and unsupported features are crossed out.

    Section in OGC GeoSPARQL 1.0
    		 Features Coverage
    7. Topology Vocabulary Extensions - Properties geo:sfEquals, geo:sfDisjoint, geo:sfIntersects, geo:sfTouches, geo:sfCrosses, geo:sfWithin, geo:sfContains, geo:sfOverlaps, geo:ehEquals, geo:ehDisjoint, geo:ehMeet, geo:ehOverlap, geo:ehCovers, geo:ehCoveredBy, geo:ehInside, geo:ehContains, geo:rcc8eq, geo:rcc8dc, geo:rcc8ec, geo:rcc8po, geo:rcc8tppi, geo:rcc8tpp, geo:rcc8ntpp, geo:rcc8ntppi 0
    8.4. Standard Properties for Geo:Geometry geo:dimension, geo:coordinateDimension, geo:spatialDimension, geo:isEmpty, geo:isSimple, geo:hasSerialization 0
    8.5. WKT Serialization geo:wktLiteral, geo:asWKT 2/2
    8.6. GML Serialization geo:gmlLiteral, geo:asGML 0
    8.7. Non-Topological Query Functions geof:distance, geof:buffer, geof:convexHull , geof:intersection, geof:union, geof:difference geof:symDifference, geof:envelope, geof:boundary, geof:getSRID, 10/10
    9.2. Common Query Functions geof:relate 1/1
    9.3. Topological Simple Features Relation Family Query Functions geof:sfEquals, geof:sfDisjoint, geof:sfIntersects, geof:sfTouches, geof:sfCrosses, geof:sfWithin, geof:sfContains, geof:sfOverlaps 8/8
    9.4. Topological Egenhofer Relation Family Query Functions geof:ehEquals, geof:ehDisjoint, geof:ehMeet, geof:ehOverlap, geof:ehCovers, geof:ehCoveredBy, geof:ehInside, geof:ehContains 8/8
    9.5. Topological RCC8 Relation Family Query Functions geof:rcc8eq, geof:rcc8dc, geof:rcc8ec, geof:rcc8po, geof:rcc8tppi, geof:rcc8tpp, geof:rcc8ntpp, geof:rcc8ntppi 8/8

    Several non-topological query functions use a unit of measure URI which OGC defines under a specific namespace e.g. <http://www.opengis.net/def/uom/OGC/1.0/metre>. The latest version of Ontop currently supports the units metre, radian and degree.

    # R2RML

    Updated for 4.2.0

    The latest version of Ontop is almost fully compliant with the R2RML (opens new window) standard.

    At the moment, it does NOT support:

    For complex SQL queries (e.g. with a GROUP BY) in the mapping, Ontop may not be able to infer the datatype of each column if the option ontop.allowRetrievingBlackBoxViewMetadataFromDB is not enabled (disabled by default). In such a situation, it may not be able to derive the natural RDF datatype (opens new window) of a literal built over a column and may not apply the expected normalization. This can be partially mitigated by expliciting the RDF datatype in the mapping, but normalization would remain unapplied.

    # RDF 1.1

    Ontop complies with RDF 1.1 (opens new window). It types simple literals (from RDF 1.0) as xsd:string and literals with a language tag as rdf:langString.

    # OWL 2 QL

    # RDFS

    # Time functions

    Since 4.2.0.

    These functions use the prefix ofn (http://www.ontotext.com/sparql/functions/) and their documentation can be found here (opens new window). They accept both xsd:date and xsd:dateTime as arguments.

    Ofn Function
    		 Argument 1 Argument 2
    ofn:weeksBetween xsd:date xsd:date
    ofn:weeksBetween xsd:dateTime xsd:dateTime
    ofn:weeksBetween* xsd:date xsd:dateTime
    ofn:weeksBetween* xsd:dateTime xsd:date
    ofn:daysBetween xsd:date xsd:date
    ofn:daysBetween xsd:dateTime xsd:dateTime
    ofn:daysBetween* xsd:date xsd:dateTime
    ofn:daysBetween* xsd:dateTime xsd:date
    ofn:hoursBetween xsd:dateTime xsd:dateTime
    ofn:minutesBetween xsd:dateTime xsd:dateTime
    ofn:secondsBetween xsd:dateTime xsd:dateTime
    ofn:millisBetween xsd:dateTime xsd:dateTime

    Combinations of argument datatypes marked with the symbol * are not supported for queries over the following data sources: Oracle and Microsoft SQL Server.

    ← →

    - + diff --git a/guide/concepts.html b/guide/concepts.html index f7a165918..6bc2492c8 100644 --- a/guide/concepts.html +++ b/guide/concepts.html @@ -6,7 +6,7 @@ Key concepts | Ontop - + @@ -48,7 +48,7 @@ RDF mainly targets data integration applications while property graphs are used for building graph databases.

    In RDF, data is modelled using classes and properties.

    Starting from 3.0, Ontop supports RDF 1.1 (opens new window).

    # SPARQL query

    SPARQL (opens new window) is the standard query language for RDF graphs.

    Ontop is capable of answering SPARQL queries expressed over the VKG. Ontop translates these SPARQL queries into SQL queries, which are then executed over the relational data sources.

    Ontop supports a large fragment of SPARQL 1.1 (opens new window).

    # Mappings

    Mappings specify the correspondence between the data models of the relational data sources and the RDF graph. Ontop supports the R2RML standard mapping language (opens new window) and the Ontop mapping language, which is fully interoperable with R2RML.

    # Ontology

    An ontology specifies the formal relations between the classes and properties used by the RDF graph. It is mainly used for enriching the RDF graph by, for instance, taking account of class hierarchies.

    Ontop supports lightweight ontologies expressed in RDFS (opens new window) or in the slightly more expressive OWL 2 QL (opens new window) fragment of OWL.

    # VKG specification

    VKG specifications are composed of mappings and optionally of ontologies.

    # SPARQL endpoint

    A SPARQL endpoint (opens new window) is a standardized HTTP-based Web API. -It makes the RDF graph queryable by any HTTP client.

    Ontop enables VKG specifications to be deployed as SPARQL endpoints.

    +It makes the RDF graph queryable by any HTTP client.

    Ontop enables VKG specifications to be deployed as SPARQL endpoints.

    ← →

    - + diff --git a/guide/databases/athena.html b/guide/databases/athena.html index 773ae1edf..ca5dc69fb 100644 --- a/guide/databases/athena.html +++ b/guide/databases/athena.html @@ -6,7 +6,7 @@ AWS Athena | Ontop - + @@ -49,7 +49,7 @@ jdbc.driver = com.simba.athena.jdbc.Driver

    # Nested Type Support

    Ontop implements explicit compatibility with the Athena array type ARRAY<T>. When used with the flatten lens, it is able to automatically infer the type of the result column.

    The flatten lens cannot be used on arrays stored as JSON-encoded columns in the database. For such use cases, the column first has to be converted to an array type.

    # Struct Access

    Individual MAP objects can be accessed by SQL expressions in the dialect's default way:

    SELECT my_struct['my_attribute'] FROM ...

    ROW objects, can also be accessed using the [key] operator. Please note, that in this case, key must be an integer index instead of the name of the field:

    SELECT my_struct[1] FROM ...
-

    WARNING

    Accessing object fields using the "dot operator" is not supported. Please use the [] operator instead.

    +

    WARNING

    Accessing object fields using the "dot operator" is not supported. Please use the [] operator instead.

    ← →

    - + diff --git a/guide/databases/bigquery.html b/guide/databases/bigquery.html index 244f769b9..c4748783e 100644 --- a/guide/databases/bigquery.html +++ b/guide/databases/bigquery.html @@ -6,7 +6,7 @@ Google BigQuery | Ontop - + @@ -47,7 +47,7 @@ jdbc.property.OAuthServiceAcctEmail = service.account@dummydomain.com jdbc.property.OAuthPvtKey = paht/to/private/key/file.json jdbc.driver = com.simba.googlebigquery.jdbc.Driver -

    NOTE

    The Google BigQuery JDBC supports different types of authentication methods. The above .property file corresponds to the OAuthType 0: Service Account method, which involves creating a service account for BigQuery and downloading its private key from the web interface. However, any other authentication method can be used with Ontop as well.

    # Nested Type Support

    Ontop implements explicit compatibility with the ARRAY<T> type. When used with the flatten lens, it is able to automatically infer the type of the result column.

    The flatten lens cannot be used on arrays stored as JSON columns in the database. For such use cases, the column first has to be converted to an array type.

    NOTE

    The position counter starts counting at 0 instead of 1 for BigQuery.

    WARNING

    In BigQuery, columns cannot directly be "arrays of arrays". To represent a two-dimensional array, the type ARRAY<STRUCT<ARRAY<T>>> has to be used instead of just ARRAY<ARRAY<T>>

    # Struct Access

    In BigQuery, individual struct objects can be accessed by SQL expressions using the "dot operator" on the struct column. In Ontop, this feature is not currently supported.

    Should any of their elements still be required, then a workaround can be performed by first transforming the struct into a JSON object and then accessing it using JSON functions.

    Example:

    my_struct.my_attribute JSON_VALUE(TO_JSON(my_struct), '$.my_attribute')

    +

    NOTE

    The Google BigQuery JDBC supports different types of authentication methods. The above .property file corresponds to the OAuthType 0: Service Account method, which involves creating a service account for BigQuery and downloading its private key from the web interface. However, any other authentication method can be used with Ontop as well.

    # Nested Type Support

    Ontop implements explicit compatibility with the ARRAY<T> type. When used with the flatten lens, it is able to automatically infer the type of the result column.

    The flatten lens cannot be used on arrays stored as JSON columns in the database. For such use cases, the column first has to be converted to an array type.

    NOTE

    The position counter starts counting at 0 instead of 1 for BigQuery.

    WARNING

    In BigQuery, columns cannot directly be "arrays of arrays". To represent a two-dimensional array, the type ARRAY<STRUCT<ARRAY<T>>> has to be used instead of just ARRAY<ARRAY<T>>

    # Struct Access

    In BigQuery, individual struct objects can be accessed by SQL expressions using the "dot operator" on the struct column. In Ontop, this feature is not currently supported.

    Should any of their elements still be required, then a workaround can be performed by first transforming the struct into a JSON object and then accessing it using JSON functions.

    Example:

    my_struct.my_attribute JSON_VALUE(TO_JSON(my_struct), '$.my_attribute')

    ← →

    - + diff --git a/guide/databases/databricks.html b/guide/databases/databricks.html index 112f9c176..6dc46aa4a 100644 --- a/guide/databases/databricks.html +++ b/guide/databases/databricks.html @@ -6,7 +6,7 @@ Databricks | Ontop - + @@ -51,7 +51,7 @@ jdbc.user = token jdbc.password = private-access-token jdbc.driver=com.simba.spark.jdbc.Driver -

    # Nested Type Support

    Ontop implements explicit compatibility with the SparkSQL array type Array<T>. When used with the flatten lens, it is able to automatically infer the type of the result column.

    Furthermore, the flatten lens can also be used with the JSON-encoded string columns. For these columns, however, Ontop cannot infer the output type of the flattened column.

    # Struct Access

    In SparkSQL, individual struct objects can be accessed by SQL expressions using the "dot operator" on the struct column. In Ontop, this feature is not currently supported.

    Should any of their elements still be required, then a workaround can be performed by first transforming the struct into a JSON object and then accessing it using JSON functions.

    Example:

    my_struct.my_attribute GET_JSON_OBJECT(TO_JSON(my_struct), '$.my_attribute')

    +

    # Nested Type Support

    Ontop implements explicit compatibility with the SparkSQL array type Array<T>. When used with the flatten lens, it is able to automatically infer the type of the result column.

    Furthermore, the flatten lens can also be used with the JSON-encoded string columns. For these columns, however, Ontop cannot infer the output type of the flattened column.

    # Struct Access

    In SparkSQL, individual struct objects can be accessed by SQL expressions using the "dot operator" on the struct column. In Ontop, this feature is not currently supported.

    Should any of their elements still be required, then a workaround can be performed by first transforming the struct into a JSON object and then accessing it using JSON functions.

    Example:

    my_struct.my_attribute GET_JSON_OBJECT(TO_JSON(my_struct), '$.my_attribute')

    ← →

    - + diff --git a/guide/databases/db2.html b/guide/databases/db2.html index 6f3b097a9..01b1c9e5b 100644 --- a/guide/databases/db2.html +++ b/guide/databases/db2.html @@ -6,7 +6,7 @@ DB2 | Ontop - + @@ -46,7 +46,7 @@ jdbc.user = user jdbc.password = password jdbc.driver = com.ibm.db2.jcc.DB2Driver -

    # Nested Type Support

    Nested data types and the flatten lens are not supported for DB2.

    +

    # Nested Type Support

    Nested data types and the flatten lens are not supported for DB2.

    ← →

    - + diff --git a/guide/databases/denodo.html b/guide/databases/denodo.html index ed06876d3..115d3c249 100644 --- a/guide/databases/denodo.html +++ b/guide/databases/denodo.html @@ -6,7 +6,7 @@ Denodo | Ontop - + @@ -46,7 +46,7 @@ jdbc.user = admin jdbc.password = ${denodo.password} jdbc.driver = com.denodo.vdp.jdbc.Driver -

    # Nested Type Support

    Nested data types and the flatten lens are not supported for Denodo.

    +

    # Nested Type Support

    Nested data types and the flatten lens are not supported for Denodo.

    ← →

    - + diff --git a/guide/databases/dremio.html b/guide/databases/dremio.html index ae0a44eb6..3d83f298a 100644 --- a/guide/databases/dremio.html +++ b/guide/databases/dremio.html @@ -6,7 +6,7 @@ Dremio | Ontop - + @@ -53,7 +53,7 @@ jdbc.password = password jdbc.driver = org.apache.arrow.driver.jdbc.ArrowFlightJdbcDriver

    # Nested Type Support

    Ontop implements explicit compatibility with the Dremio array type LIST which can be used with the flatten lens. However, it cannot infer the type of the flattened result column.

    To use a flatten lens on a JSON-encoded array stored in the database, it first has to be converted to a LIST.

    WARNING

    The position argument for flatten lenses cannot be used with Dremio.

    # Struct Access

    Individual struct objects can be accessed by SQL expressions in the dialect's default way:

    SELECT my_struct['my_attribute'] FROM ...
-

    +

    ← →

    - + diff --git a/guide/databases/duckdb.html b/guide/databases/duckdb.html index dfb2decaa..509664cf5 100644 --- a/guide/databases/duckdb.html +++ b/guide/databases/duckdb.html @@ -6,7 +6,7 @@ DuckDB | Ontop - + @@ -45,7 +45,7 @@ (opens new window)

    # DuckDB

    Supported since 5.0.2.

    Through the DuckDB (opens new window) connector, Ontop is able to construct VKGs on DuckDB database files.

    # Limitations & Exceptions

    • DuckDB database files prior to version 1.0 are not guaranteed to be compatible with later versions.
    • Setting a default schema is not supported when connecting to DuckDB.
    • Nested data types are only supported starting from version 0.7 of DuckDB.
    • Accessing struct fields using the "dot operator" is not supported.

    # Database Connection

    The following shows the content of a sample .properties file that can be used to connect Ontop to DuckDB:

    jdbc.url = jdbc:duckdb:path/to/database.db
 jdbc.driver = org.duckdb.DuckDBDriver

    # Nested Type Support

    Ontop implements explicit compatibility with the DuckDB array type T[]. When used with the flatten lens, it is able to automatically infer the type of the result column.

    The flatten lens cannot be used on arrays stored as JSON-encoded columns in the database. For such use cases, the column first has to be converted to an array type.

    NOTE

    Nested data types are only supported starting from version 0.7 of DuckDB.

    # Struct Access

    Individual struct objects can be accessed by SQL expressions in the dialect's default way:

    SELECT my_struct['my_attribute'] FROM ...
-

    WARNING

    Accessing struct fields using the "dot operator" is not supported.

    +

    WARNING

    Accessing struct fields using the "dot operator" is not supported.

    ← →

    - + diff --git a/guide/databases/dynamodb.html b/guide/databases/dynamodb.html index d001a4fb7..e892c40c5 100644 --- a/guide/databases/dynamodb.html +++ b/guide/databases/dynamodb.html @@ -6,7 +6,7 @@ AWS DynamoDB | Ontop - + @@ -47,7 +47,7 @@ jdbc.property.AWSAccessKey = public-access-key jdbc.property.AWSSecretKey = private-access-key jdbc.driver = cdata.jdbc.amazondynamodb.AmazonDynamoDBDriver -

    # Nested Type Support

    Nested data types and the flatten lens are not supported for DynamoDB.

    +

    # Nested Type Support

    Nested data types and the flatten lens are not supported for DynamoDB.

    ← →

    - + diff --git a/guide/databases/generic.html b/guide/databases/generic.html index d8f303d76..2b33cd772 100644 --- a/guide/databases/generic.html +++ b/guide/databases/generic.html @@ -6,7 +6,7 @@ Generic JDBC (not recommended) | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

    # Generic JDBC (not recommended)

    WARNING

    Don't rely on generic JDBC support. It isn't sufficient for any data source.

    Ontop provides a generic implementation, that is used as default for any JDBC. While part of the functionality may work right out of the box with this default implementation, there is no guarantee that Ontop will be able to handle any database setup and SPARQL queries correctly, especially once special limitations and exceptions come into play.

    However, Ontop also provides dialect-specific implementations for a variety of different database management systems and SQL dialects. The following documents describe the process of connecting Ontop to each of them, as well as special points and caveats for specific cases.

    In this section, we provide general information and important points for each of the supported systems.

    NOTE

    If your SQL dialect of interest is not included in this list, it is possible to implement a connector for it, following this guide.

    NOTE

    To use Ontop with any database system, its corresponding JDBC driver is required in the jdbc directory, which is passed to the Ontop instance as described in the setup guide.

    + (opens new window)

    # Generic JDBC (not recommended)

    WARNING

    Don't rely on generic JDBC support. It isn't sufficient for any data source.

    Ontop provides a generic implementation, that is used as default for any JDBC. While part of the functionality may work right out of the box with this default implementation, there is no guarantee that Ontop will be able to handle any database setup and SPARQL queries correctly, especially once special limitations and exceptions come into play.

    However, Ontop also provides dialect-specific implementations for a variety of different database management systems and SQL dialects. The following documents describe the process of connecting Ontop to each of them, as well as special points and caveats for specific cases.

    In this section, we provide general information and important points for each of the supported systems.

    NOTE

    If your SQL dialect of interest is not included in this list, it is possible to implement a connector for it, following this guide.

    NOTE

    To use Ontop with any database system, its corresponding JDBC driver is required in the jdbc directory, which is passed to the Ontop instance as described in the setup guide.

    ← →

    - + diff --git a/guide/databases/h2.html b/guide/databases/h2.html index d84879e63..f150f9853 100644 --- a/guide/databases/h2.html +++ b/guide/databases/h2.html @@ -6,7 +6,7 @@ H2 | Ontop - + @@ -46,7 +46,7 @@ jdbc.user = user jdbc.password = password jdbc.driver = org.h2.Driver -

    # Nested Type Support

    Nested data types and the flatten lens are not supported for H2.

    +

    # Nested Type Support

    Nested data types and the flatten lens are not supported for H2.

    ← →

    - + diff --git a/guide/databases/mariadb.html b/guide/databases/mariadb.html index 401aa1779..dc68efeac 100644 --- a/guide/databases/mariadb.html +++ b/guide/databases/mariadb.html @@ -6,7 +6,7 @@ MariaDB | Ontop - + @@ -46,7 +46,7 @@ jdbc.user = user jdbc.password = password jdbc.driver = org.mariadb.jdbc.Driver -

    # Nested Type Support

    Ontop implements explicit compatibility with the MariaDB type JSON which can be used with the flatten lens. However, it cannot infer the type of the flattened result column.

    In case the flattened column is still a nested structure after the flatten operation is performed (e.g. for arrays of objects), MariaDB's JSON functions (opens new window) can be used to further work with them.

    +

    # Nested Type Support

    Ontop implements explicit compatibility with the MariaDB type JSON which can be used with the flatten lens. However, it cannot infer the type of the flattened result column.

    In case the flattened column is still a nested structure after the flatten operation is performed (e.g. for arrays of objects), MariaDB's JSON functions (opens new window) can be used to further work with them.

    ← →

    - + diff --git a/guide/databases/mssql.html b/guide/databases/mssql.html index 56d13c7e8..a10c1ac33 100644 --- a/guide/databases/mssql.html +++ b/guide/databases/mssql.html @@ -6,7 +6,7 @@ MS SQL Server | Ontop - + @@ -46,7 +46,7 @@ jdbc.user = user jdbc.password = password jdbc.driver = com.microsoft.sqlserver.jdbc.SQLServerDriver -

    # Nested Type Support

    Nested data types are not supported by SQLServer. However, Ontop allows the usage of the flatten lens over string columns that contain JSON-encoded arrays. The output type of the flattened result column cannot be inferred.

    WARNING

    The position argument for flatten lenses cannot be used with SQLServer.

    In case the flattened column is still a nested structure after the flatten operation is performed (e.g. for arrays of objects), SQLServer's JSON functions (opens new window) can be used to further work with them.

    +

    # Nested Type Support

    Nested data types are not supported by SQLServer. However, Ontop allows the usage of the flatten lens over string columns that contain JSON-encoded arrays. The output type of the flattened result column cannot be inferred.

    WARNING

    The position argument for flatten lenses cannot be used with SQLServer.

    In case the flattened column is still a nested structure after the flatten operation is performed (e.g. for arrays of objects), SQLServer's JSON functions (opens new window) can be used to further work with them.

    ← →

    - + diff --git a/guide/databases/mysql.html b/guide/databases/mysql.html index 97b2a4148..c4c8b8520 100644 --- a/guide/databases/mysql.html +++ b/guide/databases/mysql.html @@ -6,7 +6,7 @@ MySQL | Ontop - + @@ -46,7 +46,7 @@ jdbc.user = user jdbc.password = password jdbc.driver = com.mysql.cj.jdbc.Driver -

    # Nested Type Support

    Ontop implements explicit compatibility with the MySQL type JSON which can be used with the flatten lens. However, it cannot infer the type of the flattened result column.

    In case the flattened column is still a nested structure after the flatten operation is performed (e.g. for arrays of objects), MySQL's JSON functions (opens new window) can be used to further work with them.

    WARNING

    Accessing object fields using the "arrow operator" is not supported.

    +

    # Nested Type Support

    Ontop implements explicit compatibility with the MySQL type JSON which can be used with the flatten lens. However, it cannot infer the type of the flattened result column.

    In case the flattened column is still a nested structure after the flatten operation is performed (e.g. for arrays of objects), MySQL's JSON functions (opens new window) can be used to further work with them.

    WARNING

    Accessing object fields using the "arrow operator" is not supported.

    ← →

    - + diff --git a/guide/databases/oracle.html b/guide/databases/oracle.html index a43e35c3a..bbeb1bdee 100644 --- a/guide/databases/oracle.html +++ b/guide/databases/oracle.html @@ -6,7 +6,7 @@ Oracle | Ontop - + @@ -47,7 +47,7 @@ jdbc.password = password jdbc.driver = oracle.jdbc.OracleDriver

    # Nested Type Support

    Ontop does not implement explicit compatibility with nested datatypes in Oracle. -However, Ontop allows the usage of the flatten lens over string columns that contain JSON-encoded arrays. The output type of the flattened result column cannot be inferred.

    To use the flatten lens with Oracle array types, they must first be converted to JSON strings.

    In case the flattened column is still a nested structure after the flatten operation is performed (e.g. for arrays of objects), Oracle's JSON functions (opens new window) can be used to further work with them.

    WARNING

    Accessing object fields using the "dot operator" is not supported. Please use SQL JSON functions instead.

    +However, Ontop allows the usage of the flatten lens over string columns that contain JSON-encoded arrays. The output type of the flattened result column cannot be inferred.

    To use the flatten lens with Oracle array types, they must first be converted to JSON strings.

    In case the flattened column is still a nested structure after the flatten operation is performed (e.g. for arrays of objects), Oracle's JSON functions (opens new window) can be used to further work with them.

    WARNING

    Accessing object fields using the "dot operator" is not supported. Please use SQL JSON functions instead.

    ← →

    - + diff --git a/guide/databases/postgres.html b/guide/databases/postgres.html index 43d27adc4..8eb4fa099 100644 --- a/guide/databases/postgres.html +++ b/guide/databases/postgres.html @@ -6,7 +6,7 @@ PostgreSQL | Ontop - + @@ -46,7 +46,7 @@ jdbc.user = admin jdbc.password = password jdbc.driver = org.postgresql.Driver -

    # Nested Type Support

    Ontop implements explicit compatibility with the PostgreSQL array type T[]. When used with the flatten lens, it is able to automatically infer the type of the result column.

    Furthermore, the flatten lens can also be used with the JSON and JSONB datatypes, which are both recognized by Ontop. For these types, however, Ontop cannot infer the output type of the flattened column.

    # Struct Access

    In PostgreSQL, individual struct objects can be accessed by SQL expressions using the "dot operator" on the struct column. In Ontop, this feature is not currently supported.

    Should any of their elements still be required, then a workaround can be performed by first transforming the struct into a JSON object and then accessing it using JSON functions.

    Example:

    my_struct.my_attribute JSON_EXTRACT_PATH(TO_JSON(my_struct), '$.my_attribute')

    WARNING

    The "arrow operators" used to access JSON objects in PostgreSQL are not supported in Ontop. Please use JSON functions instead.

    +

    # Nested Type Support

    Ontop implements explicit compatibility with the PostgreSQL array type T[]. When used with the flatten lens, it is able to automatically infer the type of the result column.

    Furthermore, the flatten lens can also be used with the JSON and JSONB datatypes, which are both recognized by Ontop. For these types, however, Ontop cannot infer the output type of the flattened column.

    # Struct Access

    In PostgreSQL, individual struct objects can be accessed by SQL expressions using the "dot operator" on the struct column. In Ontop, this feature is not currently supported.

    Should any of their elements still be required, then a workaround can be performed by first transforming the struct into a JSON object and then accessing it using JSON functions.

    Example:

    my_struct.my_attribute JSON_EXTRACT_PATH(TO_JSON(my_struct), '$.my_attribute')

    WARNING

    The "arrow operators" used to access JSON objects in PostgreSQL are not supported in Ontop. Please use JSON functions instead.

    ← →

    - + diff --git a/guide/databases/presto.html b/guide/databases/presto.html index 94a895c07..02881eeba 100644 --- a/guide/databases/presto.html +++ b/guide/databases/presto.html @@ -6,7 +6,7 @@ Presto | Ontop - + @@ -48,7 +48,7 @@ jdbc.password = password jdbc.driver = com.facebook.presto.jdbc.PrestoDriver

    In case Presto is set up without authentication, the jdbc.user and jdbc.password lines can also be left out.

    # Nested Type Support

    Ontop implements explicit compatibility with the Presto array type array(t). When used with the flatten lens, it is able to automatically infer the type of the result column.

    The flatten lens cannot be used on arrays stored as JSON-encoded columns in the database. For such use cases, the column first has to be converted to an array type.

    # Struct Access

    In Presto, individual ROW objects can be accessed by SQL expressions using the "dot operator" on the ROW column. In Ontop, this feature is not currently supported.

    Should any of their elements still be required, then a workaround can be performed by first transforming the struct into a JSON object and then accessing it using JSON functions.

    Example:

    my_row.my_attribute JSON_EXTRACT(CAST(my_struct AS JSON), '$.my_attribute')

    Elements of MAP objects can be accessed using the [] operator, as in

    SELECT my_map['my_attribute'] FROM ...
-

    +

    ← →

    - + diff --git a/guide/databases/redshift.html b/guide/databases/redshift.html index b7505fe54..811eccab2 100644 --- a/guide/databases/redshift.html +++ b/guide/databases/redshift.html @@ -6,7 +6,7 @@ AWS Redshift | Ontop - + @@ -47,7 +47,7 @@ jdbc.property.AccessKeyID = public-access-key jdbc.property.SecretAccessKey = private-access-key jdbc.driver = com.amazon.redshift.jdbc42.Driver -

    NOTE

    The AWS Redshift JDBC supports different types of authentication methods. The above .property file corresponds to authentication with access keys. However, any other authentication method can be used with Ontop as well. In these cases, the corresponding connection properties have to be supplied as jdbc.property.<property-name> instead of the AccessKeyID and SecretAccessKey properties.

    # Nested Type Support

    Ontop implements explicit compatibility with the Redshift type SUPER.

    This type can be used with the flatten lens. However, Ontop is not able to automatically infer the type of the result column.

    # Struct Access

    In Redshift, individual SUPER struct objects can be accessed by SQL expressions using the "dot operator" on the SUPER column. In Ontop, this feature is not currently supported.

    Should any of their elements still be required, then a workaround can be performed by first transforming the struct into a JSON object and then accessing it using JSON functions.

    Example:

    my_struct.my_attribute JSON_EXTRACT_PATH_TEXT(JSON_SERIALIZE(my_struct), 'my_attribute')

    +

    NOTE

    The AWS Redshift JDBC supports different types of authentication methods. The above .property file corresponds to authentication with access keys. However, any other authentication method can be used with Ontop as well. In these cases, the corresponding connection properties have to be supplied as jdbc.property.<property-name> instead of the AccessKeyID and SecretAccessKey properties.

    # Nested Type Support

    Ontop implements explicit compatibility with the Redshift type SUPER.

    This type can be used with the flatten lens. However, Ontop is not able to automatically infer the type of the result column.

    # Struct Access

    In Redshift, individual SUPER struct objects can be accessed by SQL expressions using the "dot operator" on the SUPER column. In Ontop, this feature is not currently supported.

    Should any of their elements still be required, then a workaround can be performed by first transforming the struct into a JSON object and then accessing it using JSON functions.

    Example:

    my_struct.my_attribute JSON_EXTRACT_PATH_TEXT(JSON_SERIALIZE(my_struct), 'my_attribute')

    ← →

    - + diff --git a/guide/databases/snowflake.html b/guide/databases/snowflake.html index 0d7899193..e434cf28b 100644 --- a/guide/databases/snowflake.html +++ b/guide/databases/snowflake.html @@ -6,7 +6,7 @@ Snowflake | Ontop - + @@ -48,7 +48,7 @@ jdbc.password = password jdbc.driver = net.snowflake.client.jdbc.SnowflakeDriver

    # Nested Type Support

    Ontop implements explicit compatibility with the ARRAY type, which can be used with the flatten lens. However, it is not able to automatically infer the type of the resulting column.

    WARNING

    Due to an issue mentioned above, using special characters inside the output and position fields of the flatten lens for Snowflake will fail. Furthermore, these fields will always be case-insensitive.

    # Struct Access

    Individual object fields can be accessed by SQL expressions in the dialect's default way:

    SELECT my_object['my_field'] FROM ...
-

    WARNING

    Accessing object fields using the "colon operator" is not supported. Please use the [] operator instead.

    +

    WARNING

    Accessing object fields using the "colon operator" is not supported. Please use the [] operator instead.

    ← →

    - + diff --git a/guide/databases/spark.html b/guide/databases/spark.html index 94640dc44..2625f02f4 100644 --- a/guide/databases/spark.html +++ b/guide/databases/spark.html @@ -6,7 +6,7 @@ SparkSQL | Ontop - + @@ -47,7 +47,7 @@ jdbc.driver = org.apache.hive.jdbc.HiveDriver jdbc.user = user jdbc.password = password -

    # Nested Type Support

    Ontop implements explicit compatibility with the SparkSQL array type Array<T>. When used with the flatten lens, it is able to automatically infer the type of the result column.

    Furthermore, the flatten lens can also be used with the JSON-encoded string columns. For these columns, however, Ontop cannot infer the output type of the flattened column.

    # Struct Access

    In SparkSQL, individual struct objects can be accessed by SQL expressions using the "dot operator" on the struct column. In Ontop, this feature is not currently supported.

    Should any of their elements still be required, then a workaround can be performed by first transforming the struct into a JSON object and then accessing it using JSON functions.

    Example:

    my_struct.my_attribute GET_JSON_OBJECT(TO_JSON(my_struct), '$.my_attribute')

    +

    # Nested Type Support

    Ontop implements explicit compatibility with the SparkSQL array type Array<T>. When used with the flatten lens, it is able to automatically infer the type of the result column.

    Furthermore, the flatten lens can also be used with the JSON-encoded string columns. For these columns, however, Ontop cannot infer the output type of the flattened column.

    # Struct Access

    In SparkSQL, individual struct objects can be accessed by SQL expressions using the "dot operator" on the struct column. In Ontop, this feature is not currently supported.

    Should any of their elements still be required, then a workaround can be performed by first transforming the struct into a JSON object and then accessing it using JSON functions.

    Example:

    my_struct.my_attribute GET_JSON_OBJECT(TO_JSON(my_struct), '$.my_attribute')

    ← →

    - + diff --git a/guide/databases/trino.html b/guide/databases/trino.html index ea4cac27a..510367382 100644 --- a/guide/databases/trino.html +++ b/guide/databases/trino.html @@ -6,7 +6,7 @@ Trino | Ontop - + @@ -49,7 +49,7 @@ jdbc.driver = io.trino.jdbc.TrinoDriver

    In case Trino is set up without authentication, the jdbc.user and jdbc.password lines can also be left out.

    # Nested Type Support

    Ontop implements explicit compatibility with the Trino array type array(t). When used with the flatten lens, it is able to automatically infer the type of the result column.

    The flatten lens cannot be used on arrays stored as JSON-encoded columns in the database. For such use cases, the column first has to be converted to an array type.

    # Struct Access

    Individual MAP objects can be accessed by SQL expressions in the dialect's default way:

    SELECT my_struct['my_attribute'] FROM ...

    ROW objects, can also be accessed using the [key] operator. Please note, that in this case, key must be an integer index instead of the name of the field:

    SELECT my_struct[1] FROM ...
-

    WARNING

    Accessing object fields using the "dot operator" is not supported. Please use the [] operator instead.

    +

    WARNING

    Accessing object fields using the "dot operator" is not supported. Please use the [] operator instead.

    ← →

    - + diff --git a/guide/db.html b/guide/db.html index 96b0be965..e25ecc6d5 100644 --- a/guide/db.html +++ b/guide/db.html @@ -6,7 +6,7 @@ Data sources | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

    # Data sources

    # PostgreSQL

    DOUBLE-CHECK restrictions

    SIMILAR TO (not parsed by JSQLParser)

    - + (opens new window)

    # Data sources

    # PostgreSQL

    DOUBLE-CHECK restrictions

    SIMILAR TO (not parsed by JSQLParser)

    + diff --git a/guide/getting-started.html b/guide/getting-started.html index ade9b613f..9ff7722c7 100644 --- a/guide/getting-started.html +++ b/guide/getting-started.html @@ -6,7 +6,7 @@ Getting started | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

    # Getting started

    # Tutorial

    If you are new to Ontop and Virtual Knowledge Graphs, we encourage you to have a look at the official tutorial.

    # Using Ontop

    Ontop is distributed under various forms. They can be downloaded on Github (opens new window), Docker Hub (opens new window), Sourceforge (opens new window) and in the Protégé plugin repository.

    # Mapping designer

    For editing and testing your mappings, you can use our plugin of the Protégé ontology editor (opens new window). You can download the latest stable release directly from Protégé. Alternatively, pre-releases can be found on Github (opens new window) and Sourceforge (opens new window).

    # Deployment

    Once your mappings and your ontology are ready, you can deploy your VKG as a SPARQL endpoint. The Ontop endpoint is available both as a CLI command (ontop endpoint) and as a Docker image (opens new window).

    You can also use the Ontop endpoint during development as it embeds a nice YASGUI client (opens new window) and an optional portal (since 4.0-beta-1) containing pre-defined queries.

    # Command Line Interface

    Want to materialize your VKG, convert your mappings into R2RML, bootstrap your mappings or start a SPARQL endpoint? You can use the CLI for that. It can be found on on Github (opens new window) and Sourceforge (opens new window).

    # Former solutions

    Historically, Ontop has been made available under other means that we don't recommend anymore.

    It remains possible to use Ontop as a Java API through RDF4J (opens new window) although we recommend the HTTP SPARQL endpoint as a first option (think of a microservice). Why? Because such a Java API would add many dependencies to your project and constraint you to use certain versions of Java.

    Ontop-rdf4j is available on Maven Central (opens new window).

    # RDF4J workbench (not supported anymore)

    Our first solution for deploying Ontop as SPARQL endpoint has been through the RDF4J workbench. It has several UX issues, mainly because Ontop is working with files (for the mapping and the ontology) while the normal use cases of RDF4J workbench do not. We recommend you use the Ontop endpoint as a first option.

    + (opens new window)

    # Getting started

    # Tutorial

    If you are new to Ontop and Virtual Knowledge Graphs, we encourage you to have a look at the official tutorial.

    # Using Ontop

    Ontop is distributed under various forms. They can be downloaded on Github (opens new window), Docker Hub (opens new window), Sourceforge (opens new window) and in the Protégé plugin repository.

    # Mapping designer

    For editing and testing your mappings, you can use our plugin of the Protégé ontology editor (opens new window). You can download the latest stable release directly from Protégé. Alternatively, pre-releases can be found on Github (opens new window) and Sourceforge (opens new window).

    # Deployment

    Once your mappings and your ontology are ready, you can deploy your VKG as a SPARQL endpoint. The Ontop endpoint is available both as a CLI command (ontop endpoint) and as a Docker image (opens new window).

    You can also use the Ontop endpoint during development as it embeds a nice YASGUI client (opens new window) and an optional portal (since 4.0-beta-1) containing pre-defined queries.

    # Command Line Interface

    Want to materialize your VKG, convert your mappings into R2RML, bootstrap your mappings or start a SPARQL endpoint? You can use the CLI for that. It can be found on on Github (opens new window) and Sourceforge (opens new window).

    # Former solutions

    Historically, Ontop has been made available under other means that we don't recommend anymore.

    It remains possible to use Ontop as a Java API through RDF4J (opens new window) although we recommend the HTTP SPARQL endpoint as a first option (think of a microservice). Why? Because such a Java API would add many dependencies to your project and constraint you to use certain versions of Java.

    Ontop-rdf4j is available on Maven Central (opens new window).

    # RDF4J workbench (not supported anymore)

    Our first solution for deploying Ontop as SPARQL endpoint has been through the RDF4J workbench. It has several UX issues, mainly because Ontop is working with files (for the mapping and the ontology) while the normal use cases of RDF4J workbench do not. We recommend you use the Ontop endpoint as a first option.

    ← →

    - + diff --git a/guide/glossary.html b/guide/glossary.html index 4c3cb7dd8..c358faa44 100644 --- a/guide/glossary.html +++ b/guide/glossary.html @@ -6,7 +6,7 @@ Glossary | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

    # Glossary

    # VKG

    Virtual Knowledge Graph

    # Mapping

    # OBDA

    Ontology-Based Data Access

    # Ontology

    # RDF

    # RDFS

    # SPARQL

    # SPARQL Query

    # SPARQL Endpoint

    # OWL

    # R2RML

    + (opens new window)

    # Glossary

    # VKG

    Virtual Knowledge Graph

    # Mapping

    # OBDA

    Ontology-Based Data Access

    # Ontology

    # RDF

    # RDFS

    # SPARQL

    # SPARQL Query

    # SPARQL Endpoint

    # OWL

    # R2RML

    ← →

    - + diff --git a/guide/index.html b/guide/index.html index 73c4a28e4..f18edf431 100644 --- a/guide/index.html +++ b/guide/index.html @@ -6,7 +6,7 @@ Introduction | Ontop - + @@ -45,11 +45,11 @@ (opens new window)

    # Introduction

    Ontop is a Virtual Knowledge Graph system. It exposes the content of arbitrary relational databases as knowledge graphs. These graphs are virtual, which means that data remains in the data sources instead of being moved to another database.

    Ontop translates SPARQL queries (opens new window) expressed over the knowledge graphs into SQL queries executed by the relational data sources. It relies on R2RML mappings (opens new window) and can take advantage of lightweight ontologies.

    # Versions

    This documentation is for Ontop 3.0 and more recent versions.

    For earlier versions, please refer to our previous Wiki (opens new window).

    Most recent version:

    • Stable: Ontop 5.0.2, released on March 9, 2023.

    See release notes for more details.

    # Main features

    # Organizations

    Ontop is backed by the Free University of Bozen-Bolzano (opens new window) and Ontopic s.r.l. (opens new window). It also receives regular important contributions from University of Bergen (opens new window) and Birkbeck, University of London (opens new window). See the community section for more details.

    # Licenses

    Ontop is available under the Apache 2.0 (opens new window) license.

    All the documentation is licensed under the Creative Commons (Attribution) (opens new window) -license.

    # Social

    You can find us on the following social platforms:

    # Citations

    +license.

    # Social

    You can find us on the following social platforms:

    # Citations

    Key concepts →

    - + diff --git a/guide/materialization.html b/guide/materialization.html index 8f4f4121c..e89d5df97 100644 --- a/guide/materialization.html +++ b/guide/materialization.html @@ -6,7 +6,7 @@ Materialization | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

    # Materialization

    - + (opens new window)

    # Materialization

    + diff --git a/guide/releases.html b/guide/releases.html index e915392fa..941d94db1 100644 --- a/guide/releases.html +++ b/guide/releases.html @@ -6,7 +6,7 @@ Release notes | Ontop - + @@ -277,11 +277,11 @@ (Issues: #58).
  • Fix the exceptions that appeared when loading/saving/reloading ontologies (Issues: #59, #60, #61, #75).
  • Fix problems with several progress dialogs in the GUI (Issues: #50, #87).
  • Fix problems in the 'tuple count' functionality (Issues: #82, -#84).

    • +#84).

    ←

    - + diff --git a/guide/troubleshooting/faq.html b/guide/troubleshooting/faq.html index 74f3bf743..d30f010dd 100644 --- a/guide/troubleshooting/faq.html +++ b/guide/troubleshooting/faq.html @@ -6,7 +6,7 @@ FAQ | Ontop - + @@ -49,7 +49,7 @@ and JDBC Information (opens new window).

    # No "JDBC drivers" tab in the preferences

    You probably can see the following message in the Protégé console:

    org.osgi.framework.BundleException: Activator start error in bundle org.protege.osgi.jdbc.prefs [20].)
 org.protege.osgi.jdbc.RegistryException: java.lang.ClassNotFoundException: org.h2.Driver

    Please go to the Preferences and click on "Reset preferences".

    # Protégé does not show the Ontop tabs

    To see the tabs go to Windows -> tabs -> Ontop Mappings and Ontop SPARQL.

    # RDF4J workbench (not supported anymore)

    # Why RDF4J Workbench refuses to delete some repositories?

    For deleting metadata about a repository, the RDF4J Workbench should be able to create an instance of this repository. However, if the repository configuration is invalid (due to, for instance to bad mapping and ontology files), such an instance cannot be created. -To avoid this situation, the configuration is validated in depth when a new repository is added to the Workbench. However, if the mapping and ontology files are changed afterwards, we offer no protection. One workaround is to create a valid repository with the same name and then to delete it. Another workaround is to delete it from the RDF4J console.

    +To avoid this situation, the configuration is validated in depth when a new repository is added to the Workbench. However, if the mapping and ontology files are changed afterwards, we offer no protection. One workaround is to create a valid repository with the same name and then to delete it. Another workaround is to delete it from the RDF4J console.

    ← →

    - + diff --git a/index.html b/index.html index 2f3bfcd66..7475eab2a 100644 --- a/index.html +++ b/index.html @@ -6,7 +6,7 @@ Ontop - + @@ -51,6 +51,6 @@

    Documentation under CC-BY license | Copyright 2009-present - Free University of Bozen-Bolzano
    - + diff --git a/jobs/index.html b/jobs/index.html index d73089c7e..4540c8d1b 100644 --- a/jobs/index.html +++ b/jobs/index.html @@ -6,7 +6,7 @@ Work with us | Ontop - + @@ -43,7 +43,7 @@ GitHub (opens new window)

    # Work with us

    if you are enthusiastic in the Ontop system and the Virtual Knowledge Graph technology, -there are many opportunities, which range from a small course project, to a complete PhD study, or a full time developer position.

    # Free University of Bozen-Bolzano

    At the In2Data research group (opens new window) at the KBDB group of Free University of Bozen-Bolzano, we are offering:

    If you are interested, please get in touch with Prof. Diego Calvanese (opens new window) or Dr. Guohui Xiao (opens new window).

    # Ontopic

    At the company Ontopic s.r.l. (opens new window), we are offering:

    • Student internship
    • Bachelor/Master thesis
    • Part time or full time developer positions.

    If you are interested, please get in touch with inquiry@ontopic.ai.

    - +there are many opportunities, which range from a small course project, to a complete PhD study, or a full time developer position.

    # Free University of Bozen-Bolzano

    At the In2Data research group (opens new window) at the KBDB group of Free University of Bozen-Bolzano, we are offering:

    If you are interested, please get in touch with Prof. Diego Calvanese (opens new window) or Dr. Guohui Xiao (opens new window).

    # Ontopic

    At the company Ontopic s.r.l. (opens new window), we are offering:

    • Student internship
    • Bachelor/Master thesis
    • Part time or full time developer positions.

    If you are interested, please get in touch with inquiry@ontopic.ai.

    + diff --git a/obda-pages/index.html b/obda-pages/index.html index 793d310f0..6bc1d1c1e 100644 --- a/obda-pages/index.html +++ b/obda-pages/index.html @@ -6,7 +6,7 @@ Vocabularies for Ontology-Based Data Access | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

    # Vocabularies for Ontology-Based Data Access

    Coming soon!

    - + (opens new window)

    # Vocabularies for Ontology-Based Data Access

    Coming soon!

    + diff --git a/research/index.html b/research/index.html index d963c975f..b72bdeb12 100644 --- a/research/index.html +++ b/research/index.html @@ -6,7 +6,7 @@ Research team | Ontop - + @@ -43,11 +43,11 @@ GitHub (opens new window)

    # Research team

    Ontop is a project initiated by Diego Calvanese and Mariano Rodriguez-Muro in 2009 in the KRDB research centre for Knowledge and Data (opens new window) at the Free University of Bolzano (opens new window).

    A decade after, Ontop remains very active, both from a research and a software development point of view.

    # Researchers

    Here we list the people who has been involved in the research side of the Ontop project. -For the development side, see the community page.

    # At the Free University of Bozen-Bolzano (Unibz)

    # International collaborations

    # Alumni researchers from Unibz

    # Projects

    The development and the research around Ontop over the years have been mainly funded by research projects.

    # Past projects

    • Thinking ONtologiES (TONES), EU FET project
    • Optique (opens new window) (Scalable End-User Access to Big Data) FP7 project
    • Ontology-based Data Access to NoSQL Database (OBDAM), Unibz project
    • Ontology-based analysis of temporal and streaming data (OBATS), Unibz project

    # Current projects

    • INODE (opens new window) (data management infrastructures), H2020 EU project
    • High quality Open data Publishing and Enrichment (HOPE), Italian national PRIN (Research Projects of National Relevance)
    • PACMEL (VKG for process mining), CHIST-ERA EU Project
    • IDEE (data integration in the energy sector), FESR Project
    • GeoVKG (geo-spatial VKG), Unibz project
    • High Quality Data Integration with Ontologies (QUADRO), Unibz project

    +For the development side, see the community page.

    # At the Free University of Bozen-Bolzano (Unibz)

    # International collaborations

    # Alumni researchers from Unibz

    # Projects

    The development and the research around Ontop over the years have been mainly funded by research projects.

    # Past projects

    • Thinking ONtologiES (TONES), EU FET project
    • Optique (opens new window) (Scalable End-User Access to Big Data) FP7 project
    • Ontology-based Data Access to NoSQL Database (OBDAM), Unibz project
    • Ontology-based analysis of temporal and streaming data (OBATS), Unibz project

    # Current projects

    • INODE (opens new window) (data management infrastructures), H2020 EU project
    • High quality Open data Publishing and Enrichment (HOPE), Italian national PRIN (Research Projects of National Relevance)
    • PACMEL (VKG for process mining), CHIST-ERA EU Project
    • IDEE (data integration in the energy sector), FESR Project
    • GeoVKG (geo-spatial VKG), Unibz project
    • High Quality Data Integration with Ontologies (QUADRO), Unibz project

    Publications →

    - + diff --git a/research/iq-formal.html b/research/iq-formal.html index 6ac14be45..cf4ee179d 100644 --- a/research/iq-formal.html +++ b/research/iq-formal.html @@ -6,7 +6,7 @@ Formal characterization of IQs | Ontop - + @@ -177,7 +177,7 @@ in that the projection with all selected attributes (and no non-trivial additional operation) is the identity operator, and so is renaming with empty substituion. So in practice, -a construction node may encode one of these operations.

    +a construction node may encode one of these operations.

    ← →

    - + diff --git a/research/notation.html b/research/notation.html index 5594863ad..564479b0d 100644 --- a/research/notation.html +++ b/research/notation.html @@ -6,7 +6,7 @@ Notation | Ontop - + @@ -62,7 +62,7 @@ the projected attributes must be a subset of the attributes of the argument relation. Similarly, the arguments of a union operator must have identical set of attributes (this is not natively the case of the UNION SPARQL operator, -but can be enforced with a straightforward normalization).

    +but can be enforced with a straightforward normalization).

    ← →

    - + diff --git a/research/optimization.html b/research/optimization.html index 705d5845c..0e1bcc828 100644 --- a/research/optimization.html +++ b/research/optimization.html @@ -6,7 +6,7 @@ Intermediate query optimization | Ontop - + @@ -139,11 +139,11 @@ such that ||l1|| = { {y ↦ 2} } and ||r1|| = { {x ↦ 1} }.

    Then ||j1|| = { {x ↦ 1, y ↦ 2} }, and ||n1|| = { {} }.

    But ||l2|| = { {y ↦ 2} } and ||r2|| = { {} } must also hold, therefore ||j2|| = { {y ↦ 2} } and ||n2|| = { {y ↦ 2} }, -such that ||n1|| ≠ ||n2||.

    +such that ||n1|| ≠ ||n2||.

    ←

    - + diff --git a/research/publications.html b/research/publications.html index 00d522ec3..9c2bd68d6 100644 --- a/research/publications.html +++ b/research/publications.html @@ -6,7 +6,7 @@ Publications | Ontop - + @@ -142,7 +142,7 @@ Course. (opens new window) (Roman Kontchakov, Mariano Rodriguez-Muro, Michael Zakharyaschev. Reasoning Web 2013)
  • Ontop: A Tutorial (opens new window) -(Mariano Rodriguez-Muro, Vienna'13)

    • # Master theses

    +(Mariano Rodriguez-Muro, Vienna'13)

    # Master theses

    ← →

    - + diff --git a/research/tutorials/cikm-2018.html b/research/tutorials/cikm-2018.html index f24a967a9..7fec8a6e4 100644 --- a/research/tutorials/cikm-2018.html +++ b/research/tutorials/cikm-2018.html @@ -6,7 +6,7 @@ Ontop - + @@ -60,7 +60,7 @@ tutorial. Similarly, background in Semantic Web standards, such as RDF and SPARQL can be of help, although these notions are an integral part of the tutorial, and are introduced and discussed in -the first part.

    - +the first part.

    + diff --git a/tutorial/api/index.html b/tutorial/api/index.html index 67dba4d58..ec697ffb3 100644 --- a/tutorial/api/index.html +++ b/tutorial/api/index.html @@ -6,7 +6,7 @@ Ontop API | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

    # Ontop API

    Ontop API examples are available at its own repository:

    https://github.com/ontop/ontop-api-examples (opens new window)

    You can import it directly into a Java IDE. IntelliJ is recommended.

    - + (opens new window)

    # Ontop API

    Ontop API examples are available at its own repository:

    https://github.com/ontop/ontop-api-examples (opens new window)

    You can import it directly into a Java IDE. IntelliJ is recommended.

    + diff --git a/tutorial/basic/setup.html b/tutorial/basic/setup.html index 48c5539cd..0d6e63309 100644 --- a/tutorial/basic/setup.html +++ b/tutorial/basic/setup.html @@ -6,7 +6,7 @@ Database and Ontop Setup | Ontop - + @@ -49,7 +49,7 @@ FROM "uni1"."academic" WHERE "position" = 1

    # Ontop-Protégé setup

    Protégé is an open source ontology editor and knowledge management system. Ontop-Protégé is a plugin for designing and testing a VKG specification.

    1. Download the latest Ontop-Protégé bundle for your Operating System (opens new window) and unzip the archive and go into its folder
    2. Run it (run.bat on Windows, run.sh on Mac/Linux)
    3. Register the H2 JDBC driver: go to Preferences -> JDBC Drivers and add an entry with the following information -
      • Description: h2
      • Class Name: org.h2.Driver
      • Driver file (jar): /path/to/h2/bin/h2-1.4.196.jar

    # Programme

    1. Mapping the first data source
    2. Mapping the second data source

    +

    • Description: h2
    • Class Name: org.h2.Driver
    • Driver file (jar): /path/to/h2/bin/h2-1.4.196.jar

    # Programme

    1. Mapping the first data source
    2. Mapping the second data source

    ← →

    - + diff --git a/tutorial/basic/university-1.html b/tutorial/basic/university-1.html index 61eadb95d..00cd31292 100644 --- a/tutorial/basic/university-1.html +++ b/tutorial/basic/university-1.html @@ -6,7 +6,7 @@ First data source: university 1 | Ontop - + @@ -91,7 +91,7 @@ ?teacher a :Teacher . }

    These inference capabilities can be, for a large part, understood as the ability to infer new mappings -from the original mappings and the ontological axioms (e.g. Professor is a sub-class of Teacher). We will discuss it later in this tutorial.

    +from the original mappings and the ontological axioms (e.g. Professor is a sub-class of Teacher). We will discuss it later in this tutorial.

    ← →

    - + diff --git a/tutorial/basic/university-2.html b/tutorial/basic/university-2.html index 699dc3d45..a360109d2 100644 --- a/tutorial/basic/university-2.html +++ b/tutorial/basic/university-2.html @@ -6,7 +6,7 @@ Second data source: university 2 | Ontop - + @@ -70,7 +70,7 @@ FROM "uni2"."person" WHERE "status" = 1

    And so on for the graduate students, postdocs, full professors, associate professors and assistant professors.

    # SPARQL

    We can now run the previous SPARQL queries and observe that the results combine -entries from the two datasets.

    +entries from the two datasets.

    ← →

    - + diff --git a/tutorial/endpoint/endpoint-cli.html b/tutorial/endpoint/endpoint-cli.html index e22d0910e..ae753c430 100644 --- a/tutorial/endpoint/endpoint-cli.html +++ b/tutorial/endpoint/endpoint-cli.html @@ -6,7 +6,7 @@ Setting up an Ontop SPARQL endpoint with Ontop CLI | Ontop - + @@ -54,7 +54,7 @@ --properties=input/university-complete.properties ^ --cors-allowed-origins=http://yasgui.org
    1. Open the web interface of the SPARQL endpoint to try some queries: -http://localhost:8080/ (opens new window)

    +http://localhost:8080/ (opens new window)

    ← →

    - + diff --git a/tutorial/endpoint/endpoint-docker.html b/tutorial/endpoint/endpoint-docker.html index 2f75d5575..f2c1fb3e0 100644 --- a/tutorial/endpoint/endpoint-docker.html +++ b/tutorial/endpoint/endpoint-docker.html @@ -6,7 +6,7 @@ Setting up an Ontop SPARQL endpoint with Docker | Ontop - + @@ -101,7 +101,7 @@ ports: - "8080:8080"

    Now we can simply start it:

    $ docker-compose up
-

    It exposes the following two ports for the browser:

    +

    It exposes the following two ports for the browser:

    ← →

    - + diff --git a/tutorial/endpoint/endpoint-tomcat.html b/tutorial/endpoint/endpoint-tomcat.html index 94fa008ec..2960eac4c 100644 --- a/tutorial/endpoint/endpoint-tomcat.html +++ b/tutorial/endpoint/endpoint-tomcat.html @@ -6,7 +6,7 @@ SPARQL endpoint deployment using Ontop Tomcat/RDF4J bundle | Ontop - + @@ -57,7 +57,7 @@ ?prof a :FullProfessor ; foaf:lastName ?lastName . } ' -
    - +
    + diff --git a/tutorial/endpoint/index.html b/tutorial/endpoint/index.html index e4080681d..de044cdf6 100644 --- a/tutorial/endpoint/index.html +++ b/tutorial/endpoint/index.html @@ -6,7 +6,7 @@ Deploying a SPARQL endpoint | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

    # Deploying a SPARQL endpoint

    To deploy a SPARQL endpoint, we recommend to use the Ontop endpoint from the

    + (opens new window)

    # Deploying a SPARQL endpoint

    To deploy a SPARQL endpoint, we recommend to use the Ontop endpoint from the

    ← →

    - + diff --git a/tutorial/external-tutorials.html b/tutorial/external-tutorials.html index 4fd74ecb4..4dc3c7293 100644 --- a/tutorial/external-tutorials.html +++ b/tutorial/external-tutorials.html @@ -6,7 +6,7 @@ External tutorials | Ontop - + @@ -43,11 +43,11 @@ GitHub (opens new window)

    # External tutorials

    +knowledge graphs with Ontop (opens new window)

    ←

    - + diff --git a/tutorial/federation/denodo/index.html b/tutorial/federation/denodo/index.html index b81eba1fb..104563dee 100644 --- a/tutorial/federation/denodo/index.html +++ b/tutorial/federation/denodo/index.html @@ -6,7 +6,7 @@ Ontop with Denodo | Ontop - + @@ -73,7 +73,7 @@ ?o sosa:resultTime ?t . } LIMIT 100 -

    +

    ← →

    - + diff --git a/tutorial/federation/dremio/index.html b/tutorial/federation/dremio/index.html index e639290e8..1331dce76 100644 --- a/tutorial/federation/dremio/index.html +++ b/tutorial/federation/dremio/index.html @@ -6,7 +6,7 @@ Ontop with Dremio | Ontop - + @@ -95,7 +95,7 @@ ?student foaf:firstName ?firstName . ?student foaf:lastName ?lastName . } -

    +

    ← →

    - + diff --git a/tutorial/federation/index.html b/tutorial/federation/index.html index c9fa70ee3..9f404c26f 100644 --- a/tutorial/federation/index.html +++ b/tutorial/federation/index.html @@ -6,7 +6,7 @@ Federating multiple databases | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

    # Federating multiple databases

    + (opens new window)

    # Federating multiple databases

    ← →

    - + diff --git a/tutorial/federation/teiid/index.html b/tutorial/federation/teiid/index.html index e47d4f408..08150af73 100644 --- a/tutorial/federation/teiid/index.html +++ b/tutorial/federation/teiid/index.html @@ -6,7 +6,7 @@ Ontop with Teiid | Ontop - + @@ -128,7 +128,7 @@

    you can obtain the following certain answers which are generated by extracting and merging the data obatined from uni1 and uni2:

    [x z y e]
 [x/<http://example.org/voc#uni1/course/1602>,z/<http://example.org/voc#uni2/course/1>,y/"Information security",e/<http://example.org/voc#uni2/person/1>]
 [x/<http://example.org/voc#uni1/course/1601>,z/<http://example.org/voc#uni2/course/6>,y/"Intelligent Systems",e/<http://example.org/voc#uni2/person/7>]
-

    +

    ← →

    - + diff --git a/tutorial/index.html b/tutorial/index.html index 9e408a6d6..b800c8cf6 100644 --- a/tutorial/index.html +++ b/tutorial/index.html @@ -6,7 +6,7 @@ Presentation | Ontop - + @@ -44,11 +44,11 @@ GitHub (opens new window)

    # Presentation

    In this tutorial, we will see how to design a Virtual Knowledge Graph (VKG) specification, how to deploy it as a SPARQL endpoint, how to consume it and further more advanced topics.

    # Requirements

    # Clone this repository

    Before start, please clone this repository in order to download all the files

    git clone https://github.com/ontop/ontop-tutorial.git
 cd ontop-tutorial
-

    # Program

    1. Basics of VKG Modeling
    2. Deploying an Ontop SPARQL endpoint
    3. Interacting with an Ontop SPARQL endpoint
    4. Materialization using Ontop
    5. Mapping Engineering
    6. Lenses
    7. Federating multiple databases
    8. External tutorials

    +

    # Program

    1. Basics of VKG Modeling
    2. Deploying an Ontop SPARQL endpoint
    3. Interacting with an Ontop SPARQL endpoint
    4. Materialization using Ontop
    5. Mapping Engineering
    6. Lenses
    7. Federating multiple databases
    8. External tutorials

    Database and Ontop Setup →

    - + diff --git a/tutorial/interact/cli.html b/tutorial/interact/cli.html index d34a2c6dd..1636a1211 100644 --- a/tutorial/interact/cli.html +++ b/tutorial/interact/cli.html @@ -6,7 +6,7 @@ Interact with an Ontop SPARQL Endpoint | Ontop - + @@ -55,7 +55,7 @@ --header 'accept: application/json' \ --header 'content-type: application/sparql-query' \ --data 'PREFIX : <http://example.org/voc#> SELECT DISTINCT ?teacher {?teacher a :Teacher .}' -

    # Using a SPARQL client library

    Alternatively, you may use one of the many SPARQL clients (opens new window) available for many programming and data analysis environments, as we demonstrate next using the SPARQLWrapper library within a Python Jupyter Notebook.

    +

    # Using a SPARQL client library

    Alternatively, you may use one of the many SPARQL clients (opens new window) available for many programming and data analysis environments, as we demonstrate next using the SPARQLWrapper library within a Python Jupyter Notebook.

    ← →

    - + diff --git a/tutorial/interact/jupyter.html b/tutorial/interact/jupyter.html index a042743c6..e099dbe9a 100644 --- a/tutorial/interact/jupyter.html +++ b/tutorial/interact/jupyter.html @@ -6,7 +6,7 @@ Use Jupyter Notebook with an Ontop SPARQL endpoint | Ontop - + @@ -157,7 +157,7 @@ </code></pre> <!--beforeend--></div><!--afterend-->
    lname course_title
    count 17 17
    unique 8 11
    top Smith Linear Algebra
    freq 3 3
    df['course_title'].value_counts().plot(kind='bar')
 
    <matplotlib.axes._subplots.AxesSubplot at 0x11475ebd0>
-

    +

    ← →

    - + diff --git a/tutorial/lenses/basic-lens.html b/tutorial/lenses/basic-lens.html index 094f50d8c..894180c77 100644 --- a/tutorial/lenses/basic-lens.html +++ b/tutorial/lenses/basic-lens.html @@ -6,7 +6,7 @@ Basic Lens | Ontop - + @@ -173,7 +173,7 @@ } ] } -

    Lenses can reference each other! As a further exercise, you can try using this newly created lens as the baseRelation of the managers filter from before. Once that is done, you can query it again - the results should be the same as before.

    NOTE

    We could also have added all of these constraints to the same managers_filter lens from the previous section to achieve the same results. This has the advantage of reducing the work required for the lens setup and reducing the total number of relations accessible by Ontop, but it is less flexible, as we would have to copy all the constraints to the guides_filter and guard_filter lenses as well, resulting in a lot of duplication.

    Generally, the optimal solution depends on the specific scenario.

    +

    Lenses can reference each other! As a further exercise, you can try using this newly created lens as the baseRelation of the managers filter from before. Once that is done, you can query it again - the results should be the same as before.

    NOTE

    We could also have added all of these constraints to the same managers_filter lens from the previous section to achieve the same results. This has the advantage of reducing the work required for the lens setup and reducing the total number of relations accessible by Ontop, but it is less flexible, as we would have to copy all the constraints to the guides_filter and guard_filter lenses as well, resulting in a lot of duplication.

    Generally, the optimal solution depends on the specific scenario.

    ← →

    - + diff --git a/tutorial/lenses/flatten-lens.html b/tutorial/lenses/flatten-lens.html index 0dad63b2c..f113f07fe 100644 --- a/tutorial/lenses/flatten-lens.html +++ b/tutorial/lenses/flatten-lens.html @@ -6,7 +6,7 @@ Flatten Lens | Ontop - + @@ -88,7 +88,7 @@ ?worker :hasTitle ?title . ?worker :preferredTitle ?prefTitle } -

    This should result in a list of all employees, together with their titles and their preferred title.

    # Flattening other types of arrays

    The flatten lens works on all types of arrays, and, depending on the capabilities of the dialect, can infer the output type of the flattened column. As a further exercise, try looking at the table museums.

    column type
    museum_id integer
    name string
    address string
    yearly_income integer
    yearly_spendings integer
    ratings array of floats

    The field ratings is an array of floating point numbers between 1 and 10. Try creating a flatten lens that can unnest this array to populate the datatype property :hasRating! Ontop will be able to automatically detect that the flattened column has the type FLOAT. Keep in mind that we do not necessarily need a "position" column for this use case.

    WARNING

    When arrays in a given dialect are defined as ARRAY<T>, T[], or similarly, Ontop is able to infer the data type of the output column after flattening. However, when this is not the case (either the array was provided as JSON or the array data type of the dialect is simply called ARRAY or similarly), Ontop cannot perform this inference. In those cases, it is suggested to put a basic lens over the flatten lens that explicitly performs a CAST on the output, to allow Ontop to know the column type once again.

    WARNING

    The level of support for the flatten lens depends strongly on the dialect. Please consult the flatten lens documentation page for more info on each supported dialect.

    +

    This should result in a list of all employees, together with their titles and their preferred title.

    # Flattening other types of arrays

    The flatten lens works on all types of arrays, and, depending on the capabilities of the dialect, can infer the output type of the flattened column. As a further exercise, try looking at the table museums.

    column type
    museum_id integer
    name string
    address string
    yearly_income integer
    yearly_spendings integer
    ratings array of floats

    The field ratings is an array of floating point numbers between 1 and 10. Try creating a flatten lens that can unnest this array to populate the datatype property :hasRating! Ontop will be able to automatically detect that the flattened column has the type FLOAT. Keep in mind that we do not necessarily need a "position" column for this use case.

    WARNING

    When arrays in a given dialect are defined as ARRAY<T>, T[], or similarly, Ontop is able to infer the data type of the output column after flattening. However, when this is not the case (either the array was provided as JSON or the array data type of the dialect is simply called ARRAY or similarly), Ontop cannot perform this inference. In those cases, it is suggested to put a basic lens over the flatten lens that explicitly performs a CAST on the output, to allow Ontop to know the column type once again.

    WARNING

    The level of support for the flatten lens depends strongly on the dialect. Please consult the flatten lens documentation page for more info on each supported dialect.

    ← →

    - + diff --git a/tutorial/lenses/index.html b/tutorial/lenses/index.html index 8c70da821..14e7bc4c9 100644 --- a/tutorial/lenses/index.html +++ b/tutorial/lenses/index.html @@ -6,7 +6,7 @@ Using Ontop Lenses | Ontop - + @@ -47,7 +47,7 @@ "relations": [Lens] }

    where each Lens object corresponds to one particular lens, holding a name through which it can be referenced in the mapping and a type which indicates the specific type of the lens. -We can include any number of lenses in this file, and they can reference database relations as well as each other.

    Some more common features of lenses will be discussed in the Basic Lens section.

    In each of these sections, we will construct one mapping file and one lenses file that can be passed to Ontop. To simplify testing, a common template for all mapping files is already included in the tutorial files. You can continue the preparation of the individual mappings from this template.

    +We can include any number of lenses in this file, and they can reference database relations as well as each other.

    Some more common features of lenses will be discussed in the Basic Lens section.

    In each of these sections, we will construct one mapping file and one lenses file that can be passed to Ontop. To simplify testing, a common template for all mapping files is already included in the tutorial files. You can continue the preparation of the individual mappings from this template.

    ← →

    - + diff --git a/tutorial/lenses/join-lens.html b/tutorial/lenses/join-lens.html index fd1b2297f..6bf9d4aa9 100644 --- a/tutorial/lenses/join-lens.html +++ b/tutorial/lenses/join-lens.html @@ -6,7 +6,7 @@ Join Lens | Ontop - + @@ -122,7 +122,7 @@ ?worker :name ?name . ?worker :workAddress ?address . } -

    If everything was prepared correctly, this should result in a list of employee names, together with the address of the museum they work at.

    +

    If everything was prepared correctly, this should result in a list of employee names, together with the address of the museum they work at.

    ← →

    - + diff --git a/tutorial/lenses/setup.html b/tutorial/lenses/setup.html index 4556a993a..7d45f75ec 100644 --- a/tutorial/lenses/setup.html +++ b/tutorial/lenses/setup.html @@ -6,7 +6,7 @@ Database and Ontop Setup | Ontop - + @@ -57,7 +57,7 @@ --properties=input/duckdb.properties ^ --cors-allowed-origins=http://yasgui.org
    1. Open the web interface of the SPARQL endpoint to try some queries: -http://localhost:8080/ (opens new window)

    +http://localhost:8080/ (opens new window)

    ← →

    - + diff --git a/tutorial/lenses/sql-lens.html b/tutorial/lenses/sql-lens.html index 666c81ec2..d73dbc49e 100644 --- a/tutorial/lenses/sql-lens.html +++ b/tutorial/lenses/sql-lens.html @@ -6,7 +6,7 @@ SQL Lens | Ontop - + @@ -81,7 +81,7 @@ } ] } -

    While this will not change the output of the sample query, it may help Ontop optimize its queries in specific instances (see primary key).

    WARNING

    It is advised to be cautious when using SQL lenses. Generally, they should not refer to other lenses if the SQL expression is complex, and they may not be able to infer integrity constraints. For more information, please visit the documentation page of lenses.

    +

    While this will not change the output of the sample query, it may help Ontop optimize its queries in specific instances (see primary key).

    WARNING

    It is advised to be cautious when using SQL lenses. Generally, they should not refer to other lenses if the SQL expression is complex, and they may not be able to infer integrity constraints. For more information, please visit the documentation page of lenses.

    ← →

    - + diff --git a/tutorial/lenses/union-lens.html b/tutorial/lenses/union-lens.html index c9924e476..b52d611ed 100644 --- a/tutorial/lenses/union-lens.html +++ b/tutorial/lenses/union-lens.html @@ -6,7 +6,7 @@ Union Lens | Ontop - + @@ -156,7 +156,7 @@ ?exhibit :exhibitType ?type . ?exhibit :artistName ?artist } -

    we will once again get all earlier results, in addition to all exhibits contained in the art_exhibit table. While the earlier results will have the value None as their artist name, the art_exhibits entries will include the name of their artists.

    As a further exercise, notice how the values of :exhibitType are rather ugly: "art_exhibits", "lenses.historical_exhibits_extended", and "lenses.nature_exhibits_extended". Try adding a new basic lens over the union lens that transforms these into the values "art", "historical", and "nature" instead.

    Hint: Look at the SQL function REPLACE. Could it be used in the expression field of an added column to get rid of the _exhibits, _extended, and lenses. part?

    Notice how the union lens allowed you to perform this operation on all three of its base relations by just defining it once. Without the union lens, you would have required three such basic lenses, one for each table, with the exact same contents.

    +

    we will once again get all earlier results, in addition to all exhibits contained in the art_exhibit table. While the earlier results will have the value None as their artist name, the art_exhibits entries will include the name of their artists.

    As a further exercise, notice how the values of :exhibitType are rather ugly: "art_exhibits", "lenses.historical_exhibits_extended", and "lenses.nature_exhibits_extended". Try adding a new basic lens over the union lens that transforms these into the values "art", "historical", and "nature" instead.

    Hint: Look at the SQL function REPLACE. Could it be used in the expression field of an added column to get rid of the _exhibits, _extended, and lenses. part?

    Notice how the union lens allowed you to perform this operation on all three of its base relations by just defining it once. Without the union lens, you would have required three such basic lenses, one for each table, with the exact same contents.

    ← →

    - + diff --git a/tutorial/mapping/existential.html b/tutorial/mapping/existential.html index 0f762a63d..528e755b0 100644 --- a/tutorial/mapping/existential.html +++ b/tutorial/mapping/existential.html @@ -6,7 +6,7 @@ Bonus: existential reasoning | Ontop - + @@ -52,7 +52,7 @@ SELECT ?x { ?x a :GraduateStudent . } -

    +

    ← →

    - + diff --git a/tutorial/mapping/foreign-keys.html b/tutorial/mapping/foreign-keys.html index e74f9bd25..d27e0d2f2 100644 --- a/tutorial/mapping/foreign-keys.html +++ b/tutorial/mapping/foreign-keys.html @@ -6,7 +6,7 @@ Role of foreign keys | Ontop - + @@ -116,7 +116,7 @@ ?p foaf:firstName ?firstName ; foaf:lastName ?lastName . } -

    +

    ← →

    - + diff --git a/tutorial/mapping/index.html b/tutorial/mapping/index.html index 0296a400a..acc5e1afb 100644 --- a/tutorial/mapping/index.html +++ b/tutorial/mapping/index.html @@ -6,7 +6,7 @@ Second session: Mapping Engineering | Ontop - + @@ -43,7 +43,7 @@ GitHub (opens new window)

    # Second session: Mapping Engineering

    We discuss here some advanced topics related to mappings engineering and the exploitation of -available database constraints, which affect the performance of generated SQL queries:

    1. Role of primary keys
    2. Role of foreign keys
    3. Choice of the IRI templates
    4. Existential reasoning

    +available database constraints, which affect the performance of generated SQL queries:

    1. Role of primary keys
    2. Role of foreign keys
    3. Choice of the IRI templates
    4. Existential reasoning

    ← →

    - + diff --git a/tutorial/mapping/primary-keys.html b/tutorial/mapping/primary-keys.html index aec7d9642..941aa2f2b 100644 --- a/tutorial/mapping/primary-keys.html +++ b/tutorial/mapping/primary-keys.html @@ -6,7 +6,7 @@ Role of primary keys (unique constraints) | Ontop - + @@ -111,7 +111,7 @@ WHERE QVIEW1."s_id" IS NOT NULL AND QVIEW1."first_name" IS NOT NULL AND QVIEW1."last_name" IS NOT NULL -

    As you can see, the self-joins are removed when primary keys are provided and used as joining conditions.

    +

    As you can see, the self-joins are removed when primary keys are provided and used as joining conditions.

    ← →

    - + diff --git a/tutorial/mapping/uri-templates.html b/tutorial/mapping/uri-templates.html index 75a13c240..3181af467 100644 --- a/tutorial/mapping/uri-templates.html +++ b/tutorial/mapping/uri-templates.html @@ -6,7 +6,7 @@ Choice of the IRI templates | Ontop - + @@ -114,7 +114,7 @@

    # Mapping uni2.person-canonical

    • Target:
    :person/{ssn} obda:isCanonicalIRIOf :uni2/person/{pid} .
    • Source:
    SELECT * FROM "uni2"."person"

    With these three mapping assertions and the ones of the first session, Ontop produces the same saturated mapping assertions as in the manual approach. -Query evaluation performance is thus the same (and similarly affected to the additional joins needed to build person IRIs), but the use of canonical IRI templates makes simpler for users to define and adapt mappings.

    +Query evaluation performance is thus the same (and similarly affected to the additional joins needed to build person IRIs), but the use of canonical IRI templates makes simpler for users to define and adapt mappings.

    ← →

    - + diff --git a/tutorial/materialization/materialization.html b/tutorial/materialization/materialization.html index f4d3c07cf..3e0f7f79b 100644 --- a/tutorial/materialization/materialization.html +++ b/tutorial/materialization/materialization.html @@ -6,7 +6,7 @@ How to deploy your Knowledge Graph in a graph database with Ontop | Ontop - + @@ -42,7 +42,7 @@ Work with us GitHub - (opens new window)

    # How to deploy your Knowledge Graph in a graph database with Ontop

    In this tutorial, we present two ways to materialize your Knowledge Graph using Ontop.

    # How to materialize data into a graph database using Ontop

    1. # Materialize in RDF files and load into a triplestore

    For the first solution, you will need the following prerequisites:

    Using the CLI command ontop-materialize (https://ontop-vkg.org/guide/cli#ontop-materialize (opens new window)), you can materialize your KG into one or multiple files. For simplicity, we keep the default option and only materialize it into one file.

    ./ontop materialize -m mapping.ttl -p credentials.properties -f turtle -o materialized-triples.ttl
+     (opens new window)    
     
    # How to deploy your Knowledge Graph in a graph database with Ontop
     
    In this tutorial, we present two ways to materialize your Knowledge Graph using Ontop.
     
    # How to materialize data into a graph database using Ontop
     
    1. # Materialize in RDF files and load into a triplestore
     
    For the first solution, you will need the following prerequisites:
      
    Using the CLI command ontop-materialize (https://ontop-vkg.org/guide/cli#ontop-materialize (opens new window)), you can materialize your KG into one or multiple files. For simplicity, we keep the default option and only materialize it into one file.
     
    ./ontop materialize -m mapping.ttl -p credentials.properties -f turtle -o materialized-triples.ttl
 
    After running the command, we have all the content of our KG copied to the file materialized-triples.ttl.
     
    Now we load this file in the triplestore of our choice, in this case, we use GraphDB (opens new window). This graph database offers several ways to load files (opens new window). Here, since our file is only 200 MB, we go for the simplest option and load it directly from the UI.
     
    Once this is done, we can query this KG using GraphDB.
     
    1. # Deploy a VKG and fetch its content from the graph database
     
    For the second solution, we make use of the concept of KG virtualization.
     
    We deploy the KG as a virtual KG first and then query it from the graph database. In this way, you can retrieve the triples and store them locally in the graph database.
     
    Triples are directly streamed to the graph database: no intermediate file storage is involved, making this solution more direct than the previous one.
     
    let’s deploy the KG as a virtual KG using the ontop-endpoint command:
     
    ./ontop endpoint -m mapping.ttl -p credentials.properties
 
    Now Ontop is deployed as a SPARQL endpoint available at http://localhost:8080/sparql (opens new window).
     
    Let’s go now to GraphDB. To fetch and insert all the triples from the VKG exposed by Ontop, we run the following SPARQL INSERT query from GraphDB itself:
     
    INSERT {
   ?s ?p ?o
@@ -52,7 +52,7 @@
    ?s ?p ?o
   }
 }
-
    This query materializes the same triples as with the first approach.
     
    # Choosing the Right Approach for Your Use Case
     
    1. Small Dataset, Easy Communication: If your dataset isn't large and you can easily set up communication between the Ontop SPARQL endpoint and the graph database, go with solution #2. It avoids dealing with files and intermediate storage.
     
    2. Large Dataset, Efficient Loading: For very large datasets, choose the most efficient loading solution supported by the triplestore, even if it requires more effort to set up.
     
    3. Materializing Fragments of the KG: Solution #2 allows easy materialization of specific fragments of the Knowledge Graph by adapting the SPARQL query. You can have hybrid KGs with some parts stored in the graph database and the rest kept virtual.
     
    4. Advantage of Keeping Data Virtual: Keeping data virtual is great for large volumes of sensor data that constantly update. It's better to keep this part virtual while storing rich contextual information in the graph database.
     
    # Ontology Usage
     
    If you're familiar with Ontop, you might have noticed that we didn't use an ontology in this example. Providing an ontology to Ontop can result in a significantly larger KG due to the reasoning capabilities embedded in Ontop. However, GraphDB also has reasoning capabilities, allowing reasoning to be done later in GraphDB, making materialization simpler and faster. If your graph database doesn't support reasoning, Ontop can handle it.
     
    # Mapping Options
     
    Ontop supports any R2RML mapping as well as its native format (.obda). You can create these mappings manually or use Ontopic Studio, a no-code environment designed for designing knowledge graphs and managing large mappings.
      
    
+

    This query materializes the same triples as with the first approach.

    # Choosing the Right Approach for Your Use Case

    1. Small Dataset, Easy Communication: If your dataset isn't large and you can easily set up communication between the Ontop SPARQL endpoint and the graph database, go with solution #2. It avoids dealing with files and intermediate storage.

    2. Large Dataset, Efficient Loading: For very large datasets, choose the most efficient loading solution supported by the triplestore, even if it requires more effort to set up.

    3. Materializing Fragments of the KG: Solution #2 allows easy materialization of specific fragments of the Knowledge Graph by adapting the SPARQL query. You can have hybrid KGs with some parts stored in the graph database and the rest kept virtual.

    4. Advantage of Keeping Data Virtual: Keeping data virtual is great for large volumes of sensor data that constantly update. It's better to keep this part virtual while storing rich contextual information in the graph database.

    # Ontology Usage

    If you're familiar with Ontop, you might have noticed that we didn't use an ontology in this example. Providing an ontology to Ontop can result in a significantly larger KG due to the reasoning capabilities embedded in Ontop. However, GraphDB also has reasoning capabilities, allowing reasoning to be done later in GraphDB, making materialization simpler and faster. If your graph database doesn't support reasoning, Ontop can handle it.

    ← →

    - +