Such as I mentioned in my proposal: https://www.google-melange.com/gsoc/project/details/google/gsoc2015/fernandobac03/5707702298738688 two possible ways for implement GeoSPARQL over marmotta were described.
1. Materialization of Triplets Advantages • Fast GeoSPARQL query Disadvantages • Materialization is a large process • The materialization requires more storage capacity than traditional strategies • Implies native tools, operators handling (postgresql) 2. Native support and query translation In this case, the GeoSPARQL query is translated to spatial operators and executed by native tools (GeoTools). Advantages • Direct comparison • Optimal storage • There is no need to manipulate the native functionality Disadvantages • Slow GeoSPARQL querying After the analysis of both situations, I have decided to work with the "Native Support and Query Translation" The "materialization of triplets" will depend of the amount of information stored at the moment in Marmotta If more information exists, more time will be needed to upload the new data because the spatial relations are analyzed at this time However, with the "Native Support and query translation" the spatial analysis will be executed at the time the query is executed. And no need manipulate the native functionality.
