Hi everybody,

for those who have been following the development in the MARMOTTA-584
branch [1]. Based on Francisco's contribution in GSoC, I've been focusing
on the integration of this new feature in KiWi. And there are some aspect
I'd like to discuss with the community.

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://github.com/apache/marmotta/tree/MARMOTTA-584
[2]
http://www.slideshare.net/wikier/geospatial-querying-in-apache-marmotta-apachecon-big-data-europe-2015/10
[3] http://marmotta.staging.apache.org/kiwi/geosparql.html

-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: [email protected]
w: http://redlink.co

Reply via email to