Hi, > > The main problem comes with the decision we took [2] about materializing > the geometries in PostgreSQL to benefit from PostGIS features. So now we > have a new version of the kiwi schema (5) adding a new column to the node > stable (only for postgres). > > My initial goal was to keep fully optional the GeoSPARQL support, because > my idea was that whoever doesn't need GeoSparql, he would keep using schema > v4 transparently; adding kiwi-geosparql as dependency would update the > database and add runtime support. But... it has revealed more complicated > that I initially thought, because: > > * Requires a extension point to new KiWi Nodes > * New code is also required to dynamically customize the SQL mnapping of > each new ValueType > * It also requires some added checks in many places (e.g., testing) > > Now that I have a draft how that implementation could look like, I have a > question: how much complexity this would introduce? Ok, we make easier the > task to the users (they don't need to install PostGIS if they do not want > to use it [3]). But what would happen when for example we need to extend > the schema for whatever new feature?; how do we keep for 'branches' of it? > > So in the end I'm questioning myself if it's actually worth to make the > GeoSPARQL support optional in KiWi. What do other people think? > > [1] https <https://github.com/apache/marmotta/tree/MARMOTTA-584>:// <https://github.com/apache/marmotta/tree/MARMOTTA-584>github.com <https://github.com/apache/marmotta/tree/MARMOTTA-584>/apache/ <https://github.com/apache/marmotta/tree/MARMOTTA-584>marmotta <https://github.com/apache/marmotta/tree/MARMOTTA-584>/tree/MARMOTTA-584 <https://github.com/apache/marmotta/tree/MARMOTTA-584> > [2] http:// <http://www.slideshare.net/wikier/geospatial-querying-in-apache-marmotta-apachecon-big-data-europe-2015/10> www.slideshare.net <http://www.slideshare.net/wikier/geospatial-querying-in-apache-marmotta-apachecon-big-data-europe-2015/10> / <http://www.slideshare.net/wikier/geospatial-querying-in-apache-marmotta-apachecon-big-data-europe-2015/10> wikier <http://www.slideshare.net/wikier/geospatial-querying-in-apache-marmotta-apachecon-big-data-europe-2015/10> / <http://www.slideshare.net/wikier/geospatial-querying-in-apache-marmotta-apachecon-big-data-europe-2015/10> geospatial-querying-in-apache-marmotta-apachecon-big-data-europe-2015 <http://www.slideshare.net/wikier/geospatial-querying-in-apache-marmotta-apachecon-big-data-europe-2015/10> /10 <http://www.slideshare.net/wikier/geospatial-querying-in-apache-marmotta-apachecon-big-data-europe-2015/10> > [3] http:// <http://marmotta.staging.apache.org/kiwi/geosparql.html> marmotta.staging.apache.org <http://marmotta.staging.apache.org/kiwi/geosparql.html>/kiwi/ <http://marmotta.staging.apache.org/kiwi/geosparql.html>geosparql.html <http://marmotta.staging.apache.org/kiwi/geosparql.html> >
I think GeoSPARQL support must be optional, because its gonna be annoying to any person who wants to use MARMOTTA (they have to install PostGIS). In any case people who wants to use GeoSPARQL is because they know the standard for representation or querying. And about the schema if there is a new feature we have to update these changes for GeoSPARQL module then they could update in runtime. Sorry for my late answer. Cheers, Xavier Sumba.
