Re: Toward Jena 3.10.0

[Andy Seaborne]

On 30/12/2018 13:40, Andy Seaborne wrote:
I'll start on the 3.10.0 build  - it looks like we can include 
jena-maven-tools as well


I spoke too soon. In the complete build, jena-maven-tools still has test 
failures even though it passes when run on its own.


because Bruno has a fix for the build for that. 
  Bruno also wins the "oldest resolved JIRA prize this year" for JENA-57!


The only task outstanding is to update the (c) date to 2019... unless 
there is anything else?


     Andy

Re: Toward Jena 3.10.0

[Andy Seaborne]

I'll start on the 3.10.0 build  - it looks like we can include 
jena-maven-tools as well because Bruno has a fix for the build for that. 
 Bruno also wins the "oldest resolved JIRA prize this year" for JENA-57!


The only task outstanding is to update the (c) date to 2019... unless 
there is anything else?


Andy

JTS Licensing [Re: Toward Jena 3.10.0]

[Andy Seaborne]

It is good to be clear.

As general comment, licensing is not a problem when handled early. It is 
if it is ignored and has to be sorted out after release(s) that gets messy.


http://www.apache.org/legal/resolved.html

Eclipse Distribution License 1.0 is "category A" - it is like an BSD 
license without the advertising clause. We need to add some text to the 
NOTICE.


Eclipse Public License 1.0 is "category B" (it is a weak copyleft 
license) and binaries from such code can be included (i.e. shading) with 
appropriate labelling.


For JTS:

https://github.com/locationtech/jts/blob/master/LICENSES.md

JTS is dual-licensed under:

Eclipse Public License 1.0
Eclipse Distribution License 1.0

with some BSD/3-clause code:
  https://github.com/geotools/geotools/wiki/JTS-ORA-Contribution
  https://github.com/geotools/geotools/wiki/JTS-Shapefile-Contribution

Andy


On 14/12/2018 20:26, Marco Neumann wrote:

Excellent news.


On Fri 14 Dec 2018 at 20:00, Greg Albiston  wrote:


Hi Marco,

The JTS project has been re-licenced last year as Eclipse Publish
License and Eclipse Distribution License, which are Apache compatible
AFAIK.

Thanks,

Greg

On 14/12/2018 19:53, Marco Neumann wrote:

In addition could you or someone with an Apache connection clarify the
situation around the JTS license. I remember that the Lucene project

voted

not to include the JTS dependencies due to its LGPL license. Is that not

an

issue anymore? Is there a different situation for the Jena project?

Re: Toward Jena 3.10.0

[Marco Neumann]

Excellent news.


On Fri 14 Dec 2018 at 20:00, Greg Albiston  wrote:

> Hi Marco,
>
> The JTS project has been re-licenced last year as Eclipse Publish
> License and Eclipse Distribution License, which are Apache compatible
> AFAIK.
>
> Thanks,
>
> Greg
>
> On 14/12/2018 19:53, Marco Neumann wrote:
> > In addition could you or someone with an Apache connection clarify the
> > situation around the JTS license. I remember that the Lucene project
> voted
> > not to include the JTS dependencies due to its LGPL license. Is that not
> an
> > issue anymore? Is there a different situation for the Jena project?
> >
> > On Fri 14 Dec 2018 at 19:17, Greg Albiston  wrote:
> >
> >> Hi,
> >>
> >> I've been looking at the jena-spatial module and Marco's feedback for
> >> transferring the GeoSPARQL-Jena/Fuskei projects into Jena. I've done
> >> some work on providing the jena-spatial property function for backward
> >> compatibility, but using the core elements from GeoSPARQL-Jena.
> >>
> >> This means that both Lat/Lon and Geometry Literal arguments can be used.
> >> It will also support different coordinate reference systems and
> >> serialisations. There is a spatial index in JTS that would be suited to
> >> the jena-spatial property functions and this has been utilised. Some
> >> additional work is needed on transferring/replicating the testing.
> >>
> >> For users to transition, I've added filter functions for converting
> >> Lat/Lon to Geometry Literal in queries and a method for adding
> >> Feature-Geometry-Geometry-Literal relations to a Feature-Lat/Lon
> dataset.
> >>
> >> Also, I checked in the GeoSPARQL-Jena code for the “geo” prefix and
> >> there is only use of the full URI
> >> (). It does exist in the
> >> GeoSPARQL schema document provided by OGC but isn't used in any of the
> >> statements. So the prefix naming choice would seem to sit at the level
> >> of user query and the documentation.
> >>
> >> At the moment all the indexes are using static instances so aren't ideal
> >> for multiple datasets. This is only an actual issue with the query
> >> rewrite and spatial indexes but I'll tidy them all up.
> >>
> >> Looking at the spatial-jena code, it seems the current spatial index is
> >> retrieved from the Dataset's Context but I haven't seen where the
> >> Context is setup and assigned. Does this take place as part of the
> >> Assembler?
> >>
> >> There is some work to do on this so it would be useful for me to delay
> >> the switchover if the release is before New Year.
> >>
> >> Thanks,
> >>
> >> Greg
> >>
> >>
> >> On 13/12/2018 12:13, Marco Neumann wrote:
> >>> I would certainly recommend to keep jena-spatial for now and continue
> >>> testing jena-GeoSPARQL in parallel an upcoming release. Also I am not
> >> sure
> >>> if you can manage to hook GeoSPARQL into 3.10 in a timely fashion for a
> >>> 2018 release. Keep in mind the switch from W3C geo:lat/long to OGC
> >>> WKT:Point will cause some pain to jena users. no need to take away
> >>> jena-spatial at this point.
> >>>
> >>>
> >>> On Thu, Dec 13, 2018 at 12:01 PM Andy Seaborne 
> wrote:
> >>>
>  On 04/12/2018 12:56, Greg Albiston wrote:
> > There is probably a broader question as to how/if these options
> >> should
> > be integrated in with Fuseki, whether it should be a separate
> > application or they should be left out. I think they are useful
> to a
> > user who is looking for a GeoSPARQL solution. Currently,
> > GeoSPARQL-Fuseki is using the main/embedded server so doesn't
> have a
> > GUI etc.
> 
>  The ideal way is to have an assembler for the GeoSPARQL dataset - does
>  that style work here? If it also needs server-wide settings, they can
> be
>  either done on the server level object or done in the GeoSPARQL
> dataset
>  assembler with the caution of what happens if there are 2+ such
> datasets
>  and different settings.
> 
>  Given that, would it be better to not immediately jump to retiring
>  jena-spatial (given that we had a users@ email this week and that's a
>  rare occurrence!).  I'm neutral and wil go with whatever people who
> have
>  better knowledge determine to be the best approach.
> 
> Andy
> 
> 
> 
>
-- 


---
Marco Neumann
KONA

Re: Toward Jena 3.10.0

[Greg Albiston]

Hi Marco,

The JTS project has been re-licenced last year as Eclipse Publish 
License and Eclipse Distribution License, which are Apache compatible AFAIK.


Thanks,

Greg

On 14/12/2018 19:53, Marco Neumann wrote:

In addition could you or someone with an Apache connection clarify the
situation around the JTS license. I remember that the Lucene project voted
not to include the JTS dependencies due to its LGPL license. Is that not an
issue anymore? Is there a different situation for the Jena project?

On Fri 14 Dec 2018 at 19:17, Greg Albiston  wrote:


Hi,

I've been looking at the jena-spatial module and Marco's feedback for
transferring the GeoSPARQL-Jena/Fuskei projects into Jena. I've done
some work on providing the jena-spatial property function for backward
compatibility, but using the core elements from GeoSPARQL-Jena.

This means that both Lat/Lon and Geometry Literal arguments can be used.
It will also support different coordinate reference systems and
serialisations. There is a spatial index in JTS that would be suited to
the jena-spatial property functions and this has been utilised. Some
additional work is needed on transferring/replicating the testing.

For users to transition, I've added filter functions for converting
Lat/Lon to Geometry Literal in queries and a method for adding
Feature-Geometry-Geometry-Literal relations to a Feature-Lat/Lon dataset.

Also, I checked in the GeoSPARQL-Jena code for the “geo” prefix and
there is only use of the full URI
(). It does exist in the
GeoSPARQL schema document provided by OGC but isn't used in any of the
statements. So the prefix naming choice would seem to sit at the level
of user query and the documentation.

At the moment all the indexes are using static instances so aren't ideal
for multiple datasets. This is only an actual issue with the query
rewrite and spatial indexes but I'll tidy them all up.

Looking at the spatial-jena code, it seems the current spatial index is
retrieved from the Dataset's Context but I haven't seen where the
Context is setup and assigned. Does this take place as part of the
Assembler?

There is some work to do on this so it would be useful for me to delay
the switchover if the release is before New Year.

Thanks,

Greg


On 13/12/2018 12:13, Marco Neumann wrote:

I would certainly recommend to keep jena-spatial for now and continue
testing jena-GeoSPARQL in parallel an upcoming release. Also I am not

sure

if you can manage to hook GeoSPARQL into 3.10 in a timely fashion for a
2018 release. Keep in mind the switch from W3C geo:lat/long to OGC
WKT:Point will cause some pain to jena users. no need to take away
jena-spatial at this point.


On Thu, Dec 13, 2018 at 12:01 PM Andy Seaborne  wrote:


On 04/12/2018 12:56, Greg Albiston wrote:
   > There is probably a broader question as to how/if these options

should

   > be integrated in with Fuseki, whether it should be a separate
   > application or they should be left out. I think they are useful to a
   > user who is looking for a GeoSPARQL solution. Currently,
   > GeoSPARQL-Fuseki is using the main/embedded server so doesn't have a
   > GUI etc.

The ideal way is to have an assembler for the GeoSPARQL dataset - does
that style work here? If it also needs server-wide settings, they can be
either done on the server level object or done in the GeoSPARQL dataset
assembler with the caution of what happens if there are 2+ such datasets
and different settings.

Given that, would it be better to not immediately jump to retiring
jena-spatial (given that we had a users@ email this week and that's a
rare occurrence!).  I'm neutral and wil go with whatever people who have
better knowledge determine to be the best approach.

   Andy

Re: Toward Jena 3.10.0

[Marco Neumann]

In addition could you or someone with an Apache connection clarify the
situation around the JTS license. I remember that the Lucene project voted
not to include the JTS dependencies due to its LGPL license. Is that not an
issue anymore? Is there a different situation for the Jena project?

On Fri 14 Dec 2018 at 19:17, Greg Albiston  wrote:

> Hi,
>
> I've been looking at the jena-spatial module and Marco's feedback for
> transferring the GeoSPARQL-Jena/Fuskei projects into Jena. I've done
> some work on providing the jena-spatial property function for backward
> compatibility, but using the core elements from GeoSPARQL-Jena.
>
> This means that both Lat/Lon and Geometry Literal arguments can be used.
> It will also support different coordinate reference systems and
> serialisations. There is a spatial index in JTS that would be suited to
> the jena-spatial property functions and this has been utilised. Some
> additional work is needed on transferring/replicating the testing.
>
> For users to transition, I've added filter functions for converting
> Lat/Lon to Geometry Literal in queries and a method for adding
> Feature-Geometry-Geometry-Literal relations to a Feature-Lat/Lon dataset.
>
> Also, I checked in the GeoSPARQL-Jena code for the “geo” prefix and
> there is only use of the full URI
> (). It does exist in the
> GeoSPARQL schema document provided by OGC but isn't used in any of the
> statements. So the prefix naming choice would seem to sit at the level
> of user query and the documentation.
>
> At the moment all the indexes are using static instances so aren't ideal
> for multiple datasets. This is only an actual issue with the query
> rewrite and spatial indexes but I'll tidy them all up.
>
> Looking at the spatial-jena code, it seems the current spatial index is
> retrieved from the Dataset's Context but I haven't seen where the
> Context is setup and assigned. Does this take place as part of the
> Assembler?
>
> There is some work to do on this so it would be useful for me to delay
> the switchover if the release is before New Year.
>
> Thanks,
>
> Greg
>
>
> On 13/12/2018 12:13, Marco Neumann wrote:
> > I would certainly recommend to keep jena-spatial for now and continue
> > testing jena-GeoSPARQL in parallel an upcoming release. Also I am not
> sure
> > if you can manage to hook GeoSPARQL into 3.10 in a timely fashion for a
> > 2018 release. Keep in mind the switch from W3C geo:lat/long to OGC
> > WKT:Point will cause some pain to jena users. no need to take away
> > jena-spatial at this point.
> >
> >
> > On Thu, Dec 13, 2018 at 12:01 PM Andy Seaborne  wrote:
> >
> >> On 04/12/2018 12:56, Greg Albiston wrote:
> >>   > There is probably a broader question as to how/if these options
> should
> >>   > be integrated in with Fuseki, whether it should be a separate
> >>   > application or they should be left out. I think they are useful to a
> >>   > user who is looking for a GeoSPARQL solution. Currently,
> >>   > GeoSPARQL-Fuseki is using the main/embedded server so doesn't have a
> >>   > GUI etc.
> >>
> >> The ideal way is to have an assembler for the GeoSPARQL dataset - does
> >> that style work here? If it also needs server-wide settings, they can be
> >> either done on the server level object or done in the GeoSPARQL dataset
> >> assembler with the caution of what happens if there are 2+ such datasets
> >> and different settings.
> >>
> >> Given that, would it be better to not immediately jump to retiring
> >> jena-spatial (given that we had a users@ email this week and that's a
> >> rare occurrence!).  I'm neutral and wil go with whatever people who have
> >> better knowledge determine to be the best approach.
> >>
> >>   Andy
> >>
> >>
> >>
>
-- 


---
Marco Neumann
KONA

Re: Toward Jena 3.10.0

[Greg Albiston]

Hi,

I've been looking at the jena-spatial module and Marco's feedback for 
transferring the GeoSPARQL-Jena/Fuskei projects into Jena. I've done 
some work on providing the jena-spatial property function for backward 
compatibility, but using the core elements from GeoSPARQL-Jena.


This means that both Lat/Lon and Geometry Literal arguments can be used. 
It will also support different coordinate reference systems and 
serialisations. There is a spatial index in JTS that would be suited to 
the jena-spatial property functions and this has been utilised. Some 
additional work is needed on transferring/replicating the testing.


For users to transition, I've added filter functions for converting 
Lat/Lon to Geometry Literal in queries and a method for adding 
Feature-Geometry-Geometry-Literal relations to a Feature-Lat/Lon dataset.


Also, I checked in the GeoSPARQL-Jena code for the “geo” prefix and 
there is only use of the full URI 
(). It does exist in the 
GeoSPARQL schema document provided by OGC but isn't used in any of the 
statements. So the prefix naming choice would seem to sit at the level 
of user query and the documentation.


At the moment all the indexes are using static instances so aren't ideal 
for multiple datasets. This is only an actual issue with the query 
rewrite and spatial indexes but I'll tidy them all up.


Looking at the spatial-jena code, it seems the current spatial index is 
retrieved from the Dataset's Context but I haven't seen where the 
Context is setup and assigned. Does this take place as part of the 
Assembler?


There is some work to do on this so it would be useful for me to delay 
the switchover if the release is before New Year.


Thanks,

Greg


On 13/12/2018 12:13, Marco Neumann wrote:

I would certainly recommend to keep jena-spatial for now and continue
testing jena-GeoSPARQL in parallel an upcoming release. Also I am not sure
if you can manage to hook GeoSPARQL into 3.10 in a timely fashion for a
2018 release. Keep in mind the switch from W3C geo:lat/long to OGC
WKT:Point will cause some pain to jena users. no need to take away
jena-spatial at this point.


On Thu, Dec 13, 2018 at 12:01 PM Andy Seaborne  wrote:


On 04/12/2018 12:56, Greg Albiston wrote:
  > There is probably a broader question as to how/if these options should
  > be integrated in with Fuseki, whether it should be a separate
  > application or they should be left out. I think they are useful to a
  > user who is looking for a GeoSPARQL solution. Currently,
  > GeoSPARQL-Fuseki is using the main/embedded server so doesn't have a
  > GUI etc.

The ideal way is to have an assembler for the GeoSPARQL dataset - does
that style work here? If it also needs server-wide settings, they can be
either done on the server level object or done in the GeoSPARQL dataset
assembler with the caution of what happens if there are 2+ such datasets
and different settings.

Given that, would it be better to not immediately jump to retiring
jena-spatial (given that we had a users@ email this week and that's a
rare occurrence!).  I'm neutral and wil go with whatever people who have
better knowledge determine to be the best approach.

  Andy

Re: Toward Jena 3.10.0

[Marco Neumann]

I would certainly recommend to keep jena-spatial for now and continue
testing jena-GeoSPARQL in parallel an upcoming release. Also I am not sure
if you can manage to hook GeoSPARQL into 3.10 in a timely fashion for a
2018 release. Keep in mind the switch from W3C geo:lat/long to OGC
WKT:Point will cause some pain to jena users. no need to take away
jena-spatial at this point.


On Thu, Dec 13, 2018 at 12:01 PM Andy Seaborne  wrote:

>
> On 04/12/2018 12:56, Greg Albiston wrote:
>  > There is probably a broader question as to how/if these options should
>  > be integrated in with Fuseki, whether it should be a separate
>  > application or they should be left out. I think they are useful to a
>  > user who is looking for a GeoSPARQL solution. Currently,
>  > GeoSPARQL-Fuseki is using the main/embedded server so doesn't have a
>  > GUI etc.
>
> The ideal way is to have an assembler for the GeoSPARQL dataset - does
> that style work here? If it also needs server-wide settings, they can be
> either done on the server level object or done in the GeoSPARQL dataset
> assembler with the caution of what happens if there are 2+ such datasets
> and different settings.
>
> Given that, would it be better to not immediately jump to retiring
> jena-spatial (given that we had a users@ email this week and that's a
> rare occurrence!).  I'm neutral and wil go with whatever people who have
> better knowledge determine to be the best approach.
>
>  Andy
>
>
>

-- 


---
Marco Neumann
KONA

Re: Toward Jena 3.10.0

[Andy Seaborne]

On 04/12/2018 12:56, Greg Albiston wrote:
> There is probably a broader question as to how/if these options should
> be integrated in with Fuseki, whether it should be a separate
> application or they should be left out. I think they are useful to a
> user who is looking for a GeoSPARQL solution. Currently,
> GeoSPARQL-Fuseki is using the main/embedded server so doesn't have a
> GUI etc.

The ideal way is to have an assembler for the GeoSPARQL dataset - does 
that style work here? If it also needs server-wide settings, they can be 
either done on the server level object or done in the GeoSPARQL dataset 
assembler with the caution of what happens if there are 2+ such datasets 
and different settings.


Given that, would it be better to not immediately jump to retiring 
jena-spatial (given that we had a users@ email this week and that's a 
rare occurrence!).  I'm neutral and wil go with whatever people who have 
better knowledge determine to be the best approach.


Andy

Re: Toward Jena 3.10.0

[Marco Neumann]

yes I would think so. looking forward to test the incorporated Fuseki
release.

On Mon, Dec 10, 2018 at 8:20 AM Greg Albiston  wrote:

> Hi Marco,
>
> There doesn't seem to be an option on the embedded Fuseki Server API to
> set for this.
> It seems like there is extra configuration done by the Fuseki release
> that isn't present in the API.
>
> If the GeoSPARQL-Fuseki functionality is incorporated into the Fuseki
> release then wouldn't this issue be resolved?
>
> Thanks,
>
> Greg
>
> On 09/12/2018 22:43, Marco Neumann wrote:
> > Greg, I am doing further testing, when issuing queries from OpenLayers
> on a
> > remote machine I am getting a "No Access-Control-Allow-Origin header is
> > present" error in the browser. I don't have that problem with the
> standard
> > fuseki release. I don't see an option in the geosparql fuseki server
> > configuration to enable this with the current release.
> >
> > Access to XMLHttpRequest at '
> >
> http://192.168.0.15:3030/ds/sparql?query=PREFIX%20PREFIX%20rdfs%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%20PREFIX%20geo%3A%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23%3E%20PREFIX%20geosparql%3A%3Chttp%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23%3E%20PREFIX%20geof%3A%3Chttp%3A%2F%2Fwww.opengis.net%2Fdef%2Ffunction%2Fgeosparql%2F%3E%20Select%20*%20WHERE%7B%3Fobject%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fentity%2FP625%3E%20%3Fgeometry%20.%3Fobject%20rdfs%3Alabel%20%3Flabel%20.%20%3Fobject%20geo%3Alat%20%3Flat%20.%20%3Fobject%20geo%3Along%20%3Flon%20.%20FILTER(geof%3AsfWithin(%3Fgeometry%2C%22POLYGON((53.3299984%20-6.199%2C53.3299984%203.8007%2C63.3299984%203.8007%2C63.3299984%20-6.199%2C53.3299984%20-6.199))%22%5E%5Egeosparql%3AwktLiteral))%7D=json
> '
> > from origin 'http://192.168.0.15' has been blocked by CORS policy: No
> > 'Access-Control-Allow-Origin' header is present on the requested
> resource.
> >
> >
> > On Tue, Dec 4, 2018 at 1:29 PM Marco Neumann 
> > wrote:
> >
> >>
> >> On Tue, Dec 4, 2018 at 1:04 PM Greg Albiston 
> wrote:
> >>
> >>> Hi Marco,
> >>>
> >>> 2. The GeoSPARQL-Fuseki application has some options for convenience in
> >>> setting up the Fuseki server. It looks like the two minute delay is
> >>> caused by applying RDFS inferencing to the dataset and then writing the
> >>> results into the datset (i.e. Jena operations). The GeoSPARQL schema
> has
> >>> a class and property hierachy that a user can apply to their dataset
> for
> >>> some of the functionality. The inferencing is applied by default when
> >>> loading a file, but also when connecting to a TDB, in case it hasn't
> >>> been done manually by the user. The other potentially costly operation
> >>> is creating "hasDefaultGeometry" properties, which is switched off by
> >>> default.
> >>>
> >> ah OK that's good to know
> >>
> >>
> >>> The following line should lead to quicker loading the second time.
> >>>
> >>> ./geosparql-fuseki --loopback false --tdb TDB1 --inference
> >>
> >> this looks useful I will check it out tonight
> >>
> >>
> >>> I could change the setup so that file loading applies inferencing by
> >>> default and TDB does not, but I thought picking one would be better for
> >>> consistent behaviour. Always true means less burden for users working
> >>> out why they might have a problem after loading their dataset.
> >>>
> >>> There is probably a broader question as to how/if these options should
> >>> be integrated in with Fuseki, whether it should be a separate
> >>> application or they should be left out. I think they are useful to a
> >>> user who is looking for a GeoSPARQL solution. Currently,
> >>> GeoSPARQL-Fuseki is using the main/embedded server so doesn't have a
> GUI
> >>> etc.
> >>
> >>> 3. I get what you mean about the invalidty of the query now. The
> polygon
> >>> is invalid because it is not closed. However, I'm unclear about how
> >>> these errors and warnings are handled any different to if there was a
> >>> SPARQL syntax error. A Query Parse Exception is thrown with full stack
> >>> trace. The error highlights the specific problem while the warning
> shows
> >>> the context of the error and stack trace. This made it easier to hunt
> >>> down these kinds of problems when they could be coming from a query or
> >>> the dataset. What would you be looking for instead?
> >>>
> >> it would be great if we could tie this closer into query processor and
> >> have the query canceled on a spatial pre processor error like the one
> above
> >> and report something to the user. because  now it seems to hit all wkts
> in
> >> the dataset before finishing up (of course ignoring LIMIT in the sparql
> >> query) while the user waits with no further information to be finally
> >> presented with a an empty results table.
> >>
> >>
> >> Best,
> >> Marco
> >>
> >>
> >>
> >>> Thanks,
> >>>
> >>> Greg
> >>>
> >>> On 04/12/2018 12:01, Marco Neumann wrote:
> 

Re: Toward Jena 3.10.0

[Greg Albiston]

Hi Marco,

There doesn't seem to be an option on the embedded Fuseki Server API to 
set for this.
It seems like there is extra configuration done by the Fuseki release 
that isn't present in the API.


If the GeoSPARQL-Fuseki functionality is incorporated into the Fuseki 
release then wouldn't this issue be resolved?


Thanks,

Greg

On 09/12/2018 22:43, Marco Neumann wrote:

Greg, I am doing further testing, when issuing queries from OpenLayers on a
remote machine I am getting a "No Access-Control-Allow-Origin header is
present" error in the browser. I don't have that problem with the standard
fuseki release. I don't see an option in the geosparql fuseki server
configuration to enable this with the current release.

Access to XMLHttpRequest at '
http://192.168.0.15:3030/ds/sparql?query=PREFIX%20PREFIX%20rdfs%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%20PREFIX%20geo%3A%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23%3E%20PREFIX%20geosparql%3A%3Chttp%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23%3E%20PREFIX%20geof%3A%3Chttp%3A%2F%2Fwww.opengis.net%2Fdef%2Ffunction%2Fgeosparql%2F%3E%20Select%20*%20WHERE%7B%3Fobject%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fentity%2FP625%3E%20%3Fgeometry%20.%3Fobject%20rdfs%3Alabel%20%3Flabel%20.%20%3Fobject%20geo%3Alat%20%3Flat%20.%20%3Fobject%20geo%3Along%20%3Flon%20.%20FILTER(geof%3AsfWithin(%3Fgeometry%2C%22POLYGON((53.3299984%20-6.199%2C53.3299984%203.8007%2C63.3299984%203.8007%2C63.3299984%20-6.199%2C53.3299984%20-6.199))%22%5E%5Egeosparql%3AwktLiteral))%7D=json'
from origin 'http://192.168.0.15' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested resource.


On Tue, Dec 4, 2018 at 1:29 PM Marco Neumann 
wrote:



On Tue, Dec 4, 2018 at 1:04 PM Greg Albiston  wrote:


Hi Marco,

2. The GeoSPARQL-Fuseki application has some options for convenience in
setting up the Fuseki server. It looks like the two minute delay is
caused by applying RDFS inferencing to the dataset and then writing the
results into the datset (i.e. Jena operations). The GeoSPARQL schema has
a class and property hierachy that a user can apply to their dataset for
some of the functionality. The inferencing is applied by default when
loading a file, but also when connecting to a TDB, in case it hasn't
been done manually by the user. The other potentially costly operation
is creating "hasDefaultGeometry" properties, which is switched off by
default.


ah OK that's good to know



The following line should lead to quicker loading the second time.

./geosparql-fuseki --loopback false --tdb TDB1 --inference


this looks useful I will check it out tonight



I could change the setup so that file loading applies inferencing by
default and TDB does not, but I thought picking one would be better for
consistent behaviour. Always true means less burden for users working
out why they might have a problem after loading their dataset.

There is probably a broader question as to how/if these options should
be integrated in with Fuseki, whether it should be a separate
application or they should be left out. I think they are useful to a
user who is looking for a GeoSPARQL solution. Currently,
GeoSPARQL-Fuseki is using the main/embedded server so doesn't have a GUI
etc.



3. I get what you mean about the invalidty of the query now. The polygon
is invalid because it is not closed. However, I'm unclear about how
these errors and warnings are handled any different to if there was a
SPARQL syntax error. A Query Parse Exception is thrown with full stack
trace. The error highlights the specific problem while the warning shows
the context of the error and stack trace. This made it easier to hunt
down these kinds of problems when they could be coming from a query or
the dataset. What would you be looking for instead?


it would be great if we could tie this closer into query processor and
have the query canceled on a spatial pre processor error like the one above
and report something to the user. because  now it seems to hit all wkts in
the dataset before finishing up (of course ignoring LIMIT in the sparql
query) while the user waits with no further information to be finally
presented with a an empty results table.


Best,
Marco




Thanks,

Greg

On 04/12/2018 12:01, Marco Neumann wrote:

comments inline

On Mon, Dec 3, 2018 at 5:14 PM Greg Albiston 

wrote:

Hi Marco,

1. As mentioned this shouldn't be too difficult to support.


indeed not difficult but needs a decision

you could try with the following geonames dataset

all-geonames_lotico.ttl.gz




2. Yes, the indexing, or rather caching, is in-memory, but it is
on-demand. There shouldn't be any delay at start-up beyond what Jena
needs to do. The cost comes during query execution. The key invariant
data produced for solutions is retained for a short period of time (but
can be configured to be 

Re: Toward Jena 3.10.0

[Marco Neumann]

Greg, I am doing further testing, when issuing queries from OpenLayers on a
remote machine I am getting a "No Access-Control-Allow-Origin header is
present" error in the browser. I don't have that problem with the standard
fuseki release. I don't see an option in the geosparql fuseki server
configuration to enable this with the current release.

Access to XMLHttpRequest at '
http://192.168.0.15:3030/ds/sparql?query=PREFIX%20PREFIX%20rdfs%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%20PREFIX%20geo%3A%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23%3E%20PREFIX%20geosparql%3A%3Chttp%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23%3E%20PREFIX%20geof%3A%3Chttp%3A%2F%2Fwww.opengis.net%2Fdef%2Ffunction%2Fgeosparql%2F%3E%20Select%20*%20WHERE%7B%3Fobject%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fentity%2FP625%3E%20%3Fgeometry%20.%3Fobject%20rdfs%3Alabel%20%3Flabel%20.%20%3Fobject%20geo%3Alat%20%3Flat%20.%20%3Fobject%20geo%3Along%20%3Flon%20.%20FILTER(geof%3AsfWithin(%3Fgeometry%2C%22POLYGON((53.3299984%20-6.199%2C53.3299984%203.8007%2C63.3299984%203.8007%2C63.3299984%20-6.199%2C53.3299984%20-6.199))%22%5E%5Egeosparql%3AwktLiteral))%7D=json'
from origin 'http://192.168.0.15' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested resource.


On Tue, Dec 4, 2018 at 1:29 PM Marco Neumann 
wrote:

>
>
> On Tue, Dec 4, 2018 at 1:04 PM Greg Albiston  wrote:
>
>> Hi Marco,
>>
>> 2. The GeoSPARQL-Fuseki application has some options for convenience in
>> setting up the Fuseki server. It looks like the two minute delay is
>> caused by applying RDFS inferencing to the dataset and then writing the
>> results into the datset (i.e. Jena operations). The GeoSPARQL schema has
>> a class and property hierachy that a user can apply to their dataset for
>> some of the functionality. The inferencing is applied by default when
>> loading a file, but also when connecting to a TDB, in case it hasn't
>> been done manually by the user. The other potentially costly operation
>> is creating "hasDefaultGeometry" properties, which is switched off by
>> default.
>>
>
> ah OK that's good to know
>
>
>>
>> The following line should lead to quicker loading the second time.
>>
>> ./geosparql-fuseki --loopback false --tdb TDB1 --inference
>
>
> this looks useful I will check it out tonight
>
>
>>
>> I could change the setup so that file loading applies inferencing by
>> default and TDB does not, but I thought picking one would be better for
>> consistent behaviour. Always true means less burden for users working
>> out why they might have a problem after loading their dataset.
>>
>> There is probably a broader question as to how/if these options should
>> be integrated in with Fuseki, whether it should be a separate
>> application or they should be left out. I think they are useful to a
>> user who is looking for a GeoSPARQL solution. Currently,
>> GeoSPARQL-Fuseki is using the main/embedded server so doesn't have a GUI
>> etc.
>
>
>> 3. I get what you mean about the invalidty of the query now. The polygon
>> is invalid because it is not closed. However, I'm unclear about how
>> these errors and warnings are handled any different to if there was a
>> SPARQL syntax error. A Query Parse Exception is thrown with full stack
>> trace. The error highlights the specific problem while the warning shows
>> the context of the error and stack trace. This made it easier to hunt
>> down these kinds of problems when they could be coming from a query or
>> the dataset. What would you be looking for instead?
>>
>
> it would be great if we could tie this closer into query processor and
> have the query canceled on a spatial pre processor error like the one above
> and report something to the user. because  now it seems to hit all wkts in
> the dataset before finishing up (of course ignoring LIMIT in the sparql
> query) while the user waits with no further information to be finally
> presented with a an empty results table.
>
>
> Best,
> Marco
>
>
>
>>
>> Thanks,
>>
>> Greg
>>
>> On 04/12/2018 12:01, Marco Neumann wrote:
>> > comments inline
>> >
>> > On Mon, Dec 3, 2018 at 5:14 PM Greg Albiston 
>> wrote:
>> >
>> >> Hi Marco,
>> >>
>> >> 1. As mentioned this shouldn't be too difficult to support.
>> >>
>> > indeed not difficult but needs a decision
>> >
>> > you could try with the following geonames dataset
>> >
>> > all-geonames_lotico.ttl.gz
>> >
>> >
>> >
>> >> 2. Yes, the indexing, or rather caching, is in-memory, but it is
>> >> on-demand. There shouldn't be any delay at start-up beyond what Jena
>> >> needs to do. The cost comes during query execution. The key invariant
>> >> data produced for solutions is retained for a short period of time (but
>> >> can be configured to be retained until termination). Some regularly
>> >> re-used info is always kept until termination (e.g. any spatial
>> >> 

Re: Toward Jena 3.10.0

[Marco Neumann]

On Tue, Dec 4, 2018 at 1:04 PM Greg Albiston  wrote:

> Hi Marco,
>
> 2. The GeoSPARQL-Fuseki application has some options for convenience in
> setting up the Fuseki server. It looks like the two minute delay is
> caused by applying RDFS inferencing to the dataset and then writing the
> results into the datset (i.e. Jena operations). The GeoSPARQL schema has
> a class and property hierachy that a user can apply to their dataset for
> some of the functionality. The inferencing is applied by default when
> loading a file, but also when connecting to a TDB, in case it hasn't
> been done manually by the user. The other potentially costly operation
> is creating "hasDefaultGeometry" properties, which is switched off by
> default.
>

ah OK that's good to know


>
> The following line should lead to quicker loading the second time.
>
> ./geosparql-fuseki --loopback false --tdb TDB1 --inference


this looks useful I will check it out tonight


>
> I could change the setup so that file loading applies inferencing by
> default and TDB does not, but I thought picking one would be better for
> consistent behaviour. Always true means less burden for users working
> out why they might have a problem after loading their dataset.
>
> There is probably a broader question as to how/if these options should
> be integrated in with Fuseki, whether it should be a separate
> application or they should be left out. I think they are useful to a
> user who is looking for a GeoSPARQL solution. Currently,
> GeoSPARQL-Fuseki is using the main/embedded server so doesn't have a GUI
> etc.


> 3. I get what you mean about the invalidty of the query now. The polygon
> is invalid because it is not closed. However, I'm unclear about how
> these errors and warnings are handled any different to if there was a
> SPARQL syntax error. A Query Parse Exception is thrown with full stack
> trace. The error highlights the specific problem while the warning shows
> the context of the error and stack trace. This made it easier to hunt
> down these kinds of problems when they could be coming from a query or
> the dataset. What would you be looking for instead?
>

it would be great if we could tie this closer into query processor and have
the query canceled on a spatial pre processor error like the one above and
report something to the user. because  now it seems to hit all wkts in the
dataset before finishing up (of course ignoring LIMIT in the sparql query)
while the user waits with no further information to be finally presented
with a an empty results table.


Best,
Marco



>
> Thanks,
>
> Greg
>
> On 04/12/2018 12:01, Marco Neumann wrote:
> > comments inline
> >
> > On Mon, Dec 3, 2018 at 5:14 PM Greg Albiston  wrote:
> >
> >> Hi Marco,
> >>
> >> 1. As mentioned this shouldn't be too difficult to support.
> >>
> > indeed not difficult but needs a decision
> >
> > you could try with the following geonames dataset
> >
> > all-geonames_lotico.ttl.gz
> >
> >
> >
> >> 2. Yes, the indexing, or rather caching, is in-memory, but it is
> >> on-demand. There shouldn't be any delay at start-up beyond what Jena
> >> needs to do. The cost comes during query execution. The key invariant
> >> data produced for solutions is retained for a short period of time (but
> >> can be configured to be retained until termination). Some regularly
> >> re-used info is always kept until termination (e.g. any spatial
> >> reference system transformation that has been requested).
> >>
> > the following will create and populate the TDB dataset
> >
> > ./geosparql-fuseki --loopback false --rdf_file ./lm.ttl --tdb TDB1
> >
> > I presume this message refers to the creation of the spatial cache /
> index
> >
> > 6:05:46.685 INFO  Applying GeoSPARQL Schema - Started
> > 6:07:44.826 INFO  Applying GeoSPARQL Schema - Completed
> >
> > next time I can call TDB directly
> >
> > ./geosparql-fuseki --loopback false --tdb TDB1
> >
> > 6:08:38.665 INFO  Applying GeoSPARQL Schema - Started
> > 6:10:18.661 INFO  Applying GeoSPARQL Schema - Completed
> >
> > takes approximately 2m for a very small data set. the same fuseki with
> > tdb+jena-spatial restarts almost instantaneously even with reasonably
> large
> > data sets (see geonames).
> >
> >
> >> The main benefit of this is de-serialising geometry literals. The
> >> spatial relations arguments are between a pair of geometry literals, one
> >> of which is likely to be the same in the next solution, so keeping hold
> >> of both means in alot of cases the de-serialisation can be avoided for
> >> one (and possibly both if still retained from a previous set of
> solutions).
> >>
> > might be a good idea to serialize the cache object of de-serialisized
> > geometries to disk to speed up the boot process. maybe Andy could assist
> or
> > even align this with tdb
> >
> >
> >> The aim was to only do work that's needed, not do repeat work and to be
> >> generally quick (i.e. rely on JTS to be optimised for quick solutions
> >> between the geometry 

Re: Toward Jena 3.10.0

[Greg Albiston]

Hi Marco,

2. The GeoSPARQL-Fuseki application has some options for convenience in 
setting up the Fuseki server. It looks like the two minute delay is 
caused by applying RDFS inferencing to the dataset and then writing the 
results into the datset (i.e. Jena operations). The GeoSPARQL schema has 
a class and property hierachy that a user can apply to their dataset for 
some of the functionality. The inferencing is applied by default when 
loading a file, but also when connecting to a TDB, in case it hasn't 
been done manually by the user. The other potentially costly operation 
is creating "hasDefaultGeometry" properties, which is switched off by 
default.


The following line should lead to quicker loading the second time.

./geosparql-fuseki --loopback false --tdb TDB1 --inference false

I could change the setup so that file loading applies inferencing by 
default and TDB does not, but I thought picking one would be better for 
consistent behaviour. Always true means less burden for users working 
out why they might have a problem after loading their dataset.


There is probably a broader question as to how/if these options should 
be integrated in with Fuseki, whether it should be a separate 
application or they should be left out. I think they are useful to a 
user who is looking for a GeoSPARQL solution. Currently, 
GeoSPARQL-Fuseki is using the main/embedded server so doesn't have a GUI 
etc.


3. I get what you mean about the invalidty of the query now. The polygon 
is invalid because it is not closed. However, I'm unclear about how 
these errors and warnings are handled any different to if there was a 
SPARQL syntax error. A Query Parse Exception is thrown with full stack 
trace. The error highlights the specific problem while the warning shows 
the context of the error and stack trace. This made it easier to hunt 
down these kinds of problems when they could be coming from a query or 
the dataset. What would you be looking for instead?


Thanks,

Greg

On 04/12/2018 12:01, Marco Neumann wrote:

comments inline

On Mon, Dec 3, 2018 at 5:14 PM Greg Albiston  wrote:


Hi Marco,

1. As mentioned this shouldn't be too difficult to support.


indeed not difficult but needs a decision

you could try with the following geonames dataset

all-geonames_lotico.ttl.gz




2. Yes, the indexing, or rather caching, is in-memory, but it is
on-demand. There shouldn't be any delay at start-up beyond what Jena
needs to do. The cost comes during query execution. The key invariant
data produced for solutions is retained for a short period of time (but
can be configured to be retained until termination). Some regularly
re-used info is always kept until termination (e.g. any spatial
reference system transformation that has been requested).


the following will create and populate the TDB dataset

./geosparql-fuseki --loopback false --rdf_file ./lm.ttl --tdb TDB1

I presume this message refers to the creation of the spatial cache / index

6:05:46.685 INFO  Applying GeoSPARQL Schema - Started
6:07:44.826 INFO  Applying GeoSPARQL Schema - Completed

next time I can call TDB directly

./geosparql-fuseki --loopback false --tdb TDB1

6:08:38.665 INFO  Applying GeoSPARQL Schema - Started
6:10:18.661 INFO  Applying GeoSPARQL Schema - Completed

takes approximately 2m for a very small data set. the same fuseki with
tdb+jena-spatial restarts almost instantaneously even with reasonably large
data sets (see geonames).



The main benefit of this is de-serialising geometry literals. The
spatial relations arguments are between a pair of geometry literals, one
of which is likely to be the same in the next solution, so keeping hold
of both means in alot of cases the de-serialisation can be avoided for
one (and possibly both if still retained from a previous set of solutions).


might be a good idea to serialize the cache object of de-serialisized
geometries to disk to speed up the boot process. maybe Andy could assist or
even align this with tdb



The aim was to only do work that's needed, not do repeat work and to be
generally quick (i.e. rely on JTS to be optimised for quick solutions
between the geometry pairs and Jena to optimise queries). There are 24
spatial relations and about half a dozen other functions so
pre-computing every combination gets big quickly and produces data that
users might not want/use.

A rough check of most the spatial relations only requires a bounding box
intersection or type check, so negative results can be quickly
discarded.  I looked into caching and storing to file, but there just
wasn't the benefit in my use case. It took longer to load up then
execute than just execute from fresh and cache. Also, the spatial
indexes implemented by JTS aren't designed/suited for the spatial
relations. If there is a use-case that gets more benefit from
pre-computing or storing between programme execution then I'm sure it
can be adapted for, but in the context of GeoSPARQL this approach was
effective.

3. If you 

Re: Toward Jena 3.10.0

[Marco Neumann]

comments inline

On Mon, Dec 3, 2018 at 5:14 PM Greg Albiston  wrote:

> Hi Marco,
>
> 1. As mentioned this shouldn't be too difficult to support.
>

indeed not difficult but needs a decision

you could try with the following geonames dataset

all-geonames_lotico.ttl.gz



>
> 2. Yes, the indexing, or rather caching, is in-memory, but it is
> on-demand. There shouldn't be any delay at start-up beyond what Jena
> needs to do. The cost comes during query execution. The key invariant
> data produced for solutions is retained for a short period of time (but
> can be configured to be retained until termination). Some regularly
> re-used info is always kept until termination (e.g. any spatial
> reference system transformation that has been requested).
>

the following will create and populate the TDB dataset

./geosparql-fuseki --loopback false --rdf_file ./lm.ttl --tdb TDB1

I presume this message refers to the creation of the spatial cache / index

6:05:46.685 INFO  Applying GeoSPARQL Schema - Started
6:07:44.826 INFO  Applying GeoSPARQL Schema - Completed

next time I can call TDB directly

./geosparql-fuseki --loopback false --tdb TDB1

6:08:38.665 INFO  Applying GeoSPARQL Schema - Started
6:10:18.661 INFO  Applying GeoSPARQL Schema - Completed

takes approximately 2m for a very small data set. the same fuseki with
tdb+jena-spatial restarts almost instantaneously even with reasonably large
data sets (see geonames).


> The main benefit of this is de-serialising geometry literals. The
> spatial relations arguments are between a pair of geometry literals, one
> of which is likely to be the same in the next solution, so keeping hold
> of both means in alot of cases the de-serialisation can be avoided for
> one (and possibly both if still retained from a previous set of solutions).
>

might be a good idea to serialize the cache object of de-serialisized
geometries to disk to speed up the boot process. maybe Andy could assist or
even align this with tdb


>
> The aim was to only do work that's needed, not do repeat work and to be
> generally quick (i.e. rely on JTS to be optimised for quick solutions
> between the geometry pairs and Jena to optimise queries). There are 24
> spatial relations and about half a dozen other functions so
> pre-computing every combination gets big quickly and produces data that
> users might not want/use.
>
> A rough check of most the spatial relations only requires a bounding box
> intersection or type check, so negative results can be quickly
> discarded.  I looked into caching and storing to file, but there just
> wasn't the benefit in my use case. It took longer to load up then
> execute than just execute from fresh and cache. Also, the spatial
> indexes implemented by JTS aren't designed/suited for the spatial
> relations. If there is a use-case that gets more benefit from
> pre-computing or storing between programme execution then I'm sure it
> can be adapted for, but in the context of GeoSPARQL this approach was
> effective.
>
> 3. If you could send me the dataset that causes these errors then I'll
> happily have a look into it.
>

you can use this simple list of point geometries here

http://www.lotico.com/lm.ttl.gz

this query will parse and execute

PREFIX geo: 
PREFIX geof: 

SELECT ?well
WHERE {
  ?well  ?geometry .
  FILTER(geof:sfWithin(?geometry,"POLYGON((-10 50,2 50,2 55,-10 55,-10
50))"^^geo:wktLiteral))
} LIMIT 10

this one will parse and fail

PREFIX geo: 
PREFIX geof: 

SELECT ?well
WHERE {
  ?well  ?geometry .
  FILTER(geof:sfWithin(?geometry,"POLYGON((-10 50,2 50,2 55,-10 55,-10
51))"^^geo:wktLiteral))
} LIMIT 10

warn/error messages

6:17:45.887 ERROR Points of LinearRing do not form a closed linestring -
Illegal WKT literal: POLYGON((-10 50,2 50,2 55,-10 55,-10 51))
6:17:45.887 WARN  General exception in (<
http://www.opengis.net/def/function/geosparql/sfWithin> ?geometry
"POLYGON((-10 50,2 50,2 55,-10 55,-10 51))"^^<
http://www.opengis.net/ont/geosparql#wktLiteral>)
org.apache.jena.datatypes.DatatypeFormatException: Points of LinearRing do
not form a closed linestring - Illegal WKT literal: POLYGON((-10 50,2 50,2
55,-10 55,-10 51))
at
io.github.galbiston.geosparql_jena.implementation.datatype.WKTDatatype.parse(WKTDatatype.java:109)
at
io.github.galbiston.geosparql_jena.implementation.GeometryWrapper.extract(GeometryWrapper.java:905)
at
io.github.galbiston.geosparql_jena.implementation.GeometryWrapper.extract(GeometryWrapper.java:834)
at
io.github.galbiston.geosparql_jena.geof.topological.GenericFilterFunction.exec(GenericFilterFunction.java:57)
at
io.github.galbiston.geosparql_jena.geof.topological.GenericFilterFunction.exec(GenericFilterFunction.java:42)
at

Re: Toward Jena 3.10.0

[Greg Albiston]

Hi Marco,

1. As mentioned this shouldn't be too difficult to support.

2. Yes, the indexing, or rather caching, is in-memory, but it is 
on-demand. There shouldn't be any delay at start-up beyond what Jena 
needs to do. The cost comes during query execution. The key invariant 
data produced for solutions is retained for a short period of time (but 
can be configured to be retained until termination). Some regularly 
re-used info is always kept until termination (e.g. any spatial 
reference system transformation that has been requested).


The main benefit of this is de-serialising geometry literals. The 
spatial relations arguments are between a pair of geometry literals, one 
of which is likely to be the same in the next solution, so keeping hold 
of both means in alot of cases the de-serialisation can be avoided for 
one (and possibly both if still retained from a previous set of solutions).


The aim was to only do work that's needed, not do repeat work and to be 
generally quick (i.e. rely on JTS to be optimised for quick solutions 
between the geometry pairs and Jena to optimise queries). There are 24 
spatial relations and about half a dozen other functions so 
pre-computing every combination gets big quickly and produces data that 
users might not want/use.


A rough check of most the spatial relations only requires a bounding box 
intersection or type check, so negative results can be quickly 
discarded.  I looked into caching and storing to file, but there just 
wasn't the benefit in my use case. It took longer to load up then 
execute than just execute from fresh and cache. Also, the spatial 
indexes implemented by JTS aren't designed/suited for the spatial 
relations. If there is a use-case that gets more benefit from 
pre-computing or storing between programme execution then I'm sure it 
can be adapted for, but in the context of GeoSPARQL this approach was 
effective.


3. If you could send me the dataset that causes these errors then I'll 
happily have a look into it.


4. The "geo:" prefix is the one used throughout the GeoSPARQL 
documentation, so has been used for consistency when needed. The code 
doesn't have a dependency on the "geo:" prefix, so there is no 
requirement on the user. It would probably cause more confusion to those 
following GeoSPARQL examples to not use the "geo:" prefix when necessary.


Thanks,

Greg

On 03/12/2018 15:46, Marco Neumann wrote:

Hi Greg, ok let's do it in the dev list first.

1. indeed the picking up of lat/long is a common if not the most common use
case for building a spatial index. last but not least to perform a
proximity search on 2D point geometries. (I know that the ogc recommends a
transformation path with a sparql query to turn lat / long into a WKT
geometry datatypes maybe we could provide this as a convenient option with
the release)

2. as far as I can see the spatial index in geosparql-jena is memory based.
it creates additional load time during server startup. Am I missing
something here, is there a file base spatial index as well?

3. error handling is disruptive. since we are hitting the spatial index
first during query execution I am seeing a number of unpleasant side
effects with syntactically correct sparql but semantically incorrect
spatial queries. e.g.

PREFIX geo: 
PREFIX geof: 

SELECT ?well
WHERE {
?well   ?geometry .
   FILTER(geof:sfWithin(?geometry,"POLYGON((-77 38,-77 0,0 38,0 0,0
0))"^^geo:wktLiteral))
} LIMIT 10

4. The re-use of the geo: prefix really isn't your problem I know but it
will create confusion. Wouldn't geosparql: be a better prefix for this? Is
the OGC now married to this prefix? It used to be
http://www.w3.org/2003/01/geo/wgs84_pos#

and there is more to come...

again thank you for working on this with your team Greg, much appreciated.








On Mon, Dec 3, 2018 at 2:15 PM Greg Albiston  wrote:


Hi Marco,

I've had a look at the doucmentation for Jena Spatial and it would seem
the main data change is the use of the Lat/Lon pairs.
This doesn't comply with the GeoSPARQL standard so support for this
would be a Jena extension.

This could be accomodated by a property function to convert to a WKT
Point literal with WGS84/CRS84 spatial reference.
Users would then be able to use the result in query for any of the
GeoSPARQL functions.

Alternatively, the spatial relations could all have an extra property
function defined, provide the conversion and hand over to the GeoSPARQL
equivalent property function. This wouldn't take long to integrate as
individual spatial relation property functions are very minimal.

The other item that jumps out is the Jena spatial property functions.

spatial:nearby, spatial:withinCircle, spatial:withinBox and
spatial:interesectBox all seem to be variations of Simple Features
spatial relations that are covered by GeoSPARQL. These property
functions can be 

Re: Toward Jena 3.10.0

[Marco Neumann]

Hi Greg, ok let's do it in the dev list first.

1. indeed the picking up of lat/long is a common if not the most common use
case for building a spatial index. last but not least to perform a
proximity search on 2D point geometries. (I know that the ogc recommends a
transformation path with a sparql query to turn lat / long into a WKT
geometry datatypes maybe we could provide this as a convenient option with
the release)

2. as far as I can see the spatial index in geosparql-jena is memory based.
it creates additional load time during server startup. Am I missing
something here, is there a file base spatial index as well?

3. error handling is disruptive. since we are hitting the spatial index
first during query execution I am seeing a number of unpleasant side
effects with syntactically correct sparql but semantically incorrect
spatial queries. e.g.

PREFIX geo: 
PREFIX geof: 

SELECT ?well
WHERE {
   ?well   ?geometry .
  FILTER(geof:sfWithin(?geometry,"POLYGON((-77 38,-77 0,0 38,0 0,0
0))"^^geo:wktLiteral))
} LIMIT 10

4. The re-use of the geo: prefix really isn't your problem I know but it
will create confusion. Wouldn't geosparql: be a better prefix for this? Is
the OGC now married to this prefix? It used to be
http://www.w3.org/2003/01/geo/wgs84_pos#

and there is more to come...

again thank you for working on this with your team Greg, much appreciated.








On Mon, Dec 3, 2018 at 2:15 PM Greg Albiston  wrote:

> Hi Marco,
>
> I've had a look at the doucmentation for Jena Spatial and it would seem
> the main data change is the use of the Lat/Lon pairs.
> This doesn't comply with the GeoSPARQL standard so support for this
> would be a Jena extension.
>
> This could be accomodated by a property function to convert to a WKT
> Point literal with WGS84/CRS84 spatial reference.
> Users would then be able to use the result in query for any of the
> GeoSPARQL functions.
>
> Alternatively, the spatial relations could all have an extra property
> function defined, provide the conversion and hand over to the GeoSPARQL
> equivalent property function. This wouldn't take long to integrate as
> individual spatial relation property functions are very minimal.
>
> The other item that jumps out is the Jena spatial property functions.
>
> spatial:nearby, spatial:withinCircle, spatial:withinBox and
> spatial:interesectBox all seem to be variations of Simple Features
> spatial relations that are covered by GeoSPARQL. These property
> functions can be incorpated for backward compatability but it's whether
> these should just be offered as the current Lat/Lon pairs or expanded to
> accept geometry literals (i.e. WKT, GML etc.)? The latter option
> shouldn't be hard to provide for the same reason as above.
>
> spatial:north, spatial:south, spatial:west and spatial:east are not in
> GeoSPARQL. Again its a question of whether these should be provided more
> generally for WKT, GML geometry literals? There might need to be a bit
> of extra work handling both geographic and planar spatial reference
> systems, as Jean Spatial is only doing a spatial reference system.
>
> I don't think it would be too difficult to support the existing Jena
> Spatial functionality, at least based on the webpage
> (https://jena.apache.org/documentation/query/spatial-query.html), as an
> extension to what is provided by GeoSPARQL.
>
> Is there anything else that you were concerned about?
>
> Thanks,
>
> Greg
>
>
> On 03/12/2018 10:53, Marco Neumann wrote:
> > so I've had a look at this and while I think geosparql-jena is a very
> > welcomed contribution to the jena project I don't think we should rush
> with
> > the retirement of  jena-spatial at this point as Greg's approach will
> > require users to make changes to their existing data.
> >
> > I will engage Greg on us...@jena.apache.org again to clarify a few
> things
> > and hopefully get more people involved in this conversation around
> spatial,
> > geosparql and jena.
> >
> >
> >
> > On Fri, Nov 30, 2018 at 1:23 PM Marco Neumann 
> > wrote:
> >
> >> how quickly can you hook geosparql into the release?
> >>
> >> this would make lucene spatial obsolete in the next release.  has Greg
> >> released performance benchmarks for his implementation? as I said I will
> >> take a look at it over the weekend when time permits.
> >>
> >> On Fri, Nov 30, 2018 at 11:02 AM Andy Seaborne  wrote:
> >>
> >>> We could retire jena-spatial immediately after 3.10.0 - given the
> Lucene
> >>> change that might be smoother, one release with updated dependencies.
> >>>
> >>> If that is the way forward, I think it is (mildly) better to take it
> out
> >>> of the Fuseki/Full build in 3.10.0.
> >>>
> >>>   Andy
> >>>
> >>> On 29/11/2018 17:00, Marco Neumann wrote:
>  I will have to look into that I guess since I am frequent user of
> >>> spatial
>  data.
> 
>  why not go to 

Re: Toward Jena 3.10.0

[Greg Albiston]

Hi Marco,

I've had a look at the doucmentation for Jena Spatial and it would seem 
the main data change is the use of the Lat/Lon pairs.
This doesn't comply with the GeoSPARQL standard so support for this 
would be a Jena extension.


This could be accomodated by a property function to convert to a WKT 
Point literal with WGS84/CRS84 spatial reference.
Users would then be able to use the result in query for any of the 
GeoSPARQL functions.


Alternatively, the spatial relations could all have an extra property 
function defined, provide the conversion and hand over to the GeoSPARQL 
equivalent property function. This wouldn't take long to integrate as 
individual spatial relation property functions are very minimal.


The other item that jumps out is the Jena spatial property functions.

spatial:nearby, spatial:withinCircle, spatial:withinBox and 
spatial:interesectBox all seem to be variations of Simple Features 
spatial relations that are covered by GeoSPARQL. These property 
functions can be incorpated for backward compatability but it's whether 
these should just be offered as the current Lat/Lon pairs or expanded to 
accept geometry literals (i.e. WKT, GML etc.)? The latter option 
shouldn't be hard to provide for the same reason as above.


spatial:north, spatial:south, spatial:west and spatial:east are not in 
GeoSPARQL. Again its a question of whether these should be provided more 
generally for WKT, GML geometry literals? There might need to be a bit 
of extra work handling both geographic and planar spatial reference 
systems, as Jean Spatial is only doing a spatial reference system.


I don't think it would be too difficult to support the existing Jena 
Spatial functionality, at least based on the webpage 
(https://jena.apache.org/documentation/query/spatial-query.html), as an 
extension to what is provided by GeoSPARQL.


Is there anything else that you were concerned about?

Thanks,

Greg


On 03/12/2018 10:53, Marco Neumann wrote:

so I've had a look at this and while I think geosparql-jena is a very
welcomed contribution to the jena project I don't think we should rush with
the retirement of  jena-spatial at this point as Greg's approach will
require users to make changes to their existing data.

I will engage Greg on us...@jena.apache.org again to clarify a few things
and hopefully get more people involved in this conversation around spatial,
geosparql and jena.



On Fri, Nov 30, 2018 at 1:23 PM Marco Neumann 
wrote:


how quickly can you hook geosparql into the release?

this would make lucene spatial obsolete in the next release.  has Greg
released performance benchmarks for his implementation? as I said I will
take a look at it over the weekend when time permits.

On Fri, Nov 30, 2018 at 11:02 AM Andy Seaborne  wrote:


We could retire jena-spatial immediately after 3.10.0 - given the Lucene
change that might be smoother, one release with updated dependencies.

If that is the way forward, I think it is (mildly) better to take it out
of the Fuseki/Full build in 3.10.0.

  Andy

On 29/11/2018 17:00, Marco Neumann wrote:

I will have to look into that I guess since I am frequent user of

spatial

data.

why not go to 7.5? was there an incompatibility?

On Thu 29. Nov 2018 at 16:53, Andy Seaborne  wrote:


Jena 3.1.0 would be around the end of the year. I'd like to make use of
Greg's GeoSPARQL project the "headline" item for the release and to
retire jena-spatial in 3.10.0 as an indication of this.

Because retirement is a new process for the project, I'm sending this
first 3.10.0 message quite early to give us discussion time.

== Retirements

We have talked about this before but not actually done anything. See
separate thread for discussion on retirement process and for the first
modules:

jena-spatial
jena-fuseki1
jena-csv

== Headlines

JENA-664 : GeoSPARQL support

I'd like to make use of Greg's GeoSPARQL project the "headline" item

for

the release and to retire jena-spatial in 3.10.0 as an indication of

this.

JENA-1621 : Lucene upgrade to 7.4
  May need to reload lucene indexes.
(e.g. the lucene index was create originally with Lucene v5.x (prior
Jena 3.3.0). See Lucene upgrade tool.
https://lucene.apache.org/solr/guide/7_4/indexupgrader-tool.html

JENA-1623 : Fuseki security
JENA-1627 : HTTP support
https://issues.apache.org/jira/browse/JENA-1623


http://jena.staging.apache.org/documentation/fuseki2/data-access-control

== JIRA:

31 currently.

https://s.apache.org/jena-3.10.0-jira

== Updates

Only plugins. JENA-1624

surefire : 2.21.0 -> 2.22.1 (+ SUREFIRE-1588)
compiler : 3.7.0 -> 3.8.0
shade: 3.1.0 -> 3.2.0

  Andy



--


---
Marco Neumann
KONA

Re: Toward Jena 3.10.0

[Marco Neumann]

so I've had a look at this and while I think geosparql-jena is a very
welcomed contribution to the jena project I don't think we should rush with
the retirement of  jena-spatial at this point as Greg's approach will
require users to make changes to their existing data.

I will engage Greg on us...@jena.apache.org again to clarify a few things
and hopefully get more people involved in this conversation around spatial,
geosparql and jena.



On Fri, Nov 30, 2018 at 1:23 PM Marco Neumann 
wrote:

> how quickly can you hook geosparql into the release?
>
> this would make lucene spatial obsolete in the next release.  has Greg
> released performance benchmarks for his implementation? as I said I will
> take a look at it over the weekend when time permits.
>
> On Fri, Nov 30, 2018 at 11:02 AM Andy Seaborne  wrote:
>
>> We could retire jena-spatial immediately after 3.10.0 - given the Lucene
>> change that might be smoother, one release with updated dependencies.
>>
>> If that is the way forward, I think it is (mildly) better to take it out
>> of the Fuseki/Full build in 3.10.0.
>>
>>  Andy
>>
>> On 29/11/2018 17:00, Marco Neumann wrote:
>> > I will have to look into that I guess since I am frequent user of
>> spatial
>> > data.
>> >
>> > why not go to 7.5? was there an incompatibility?
>> >
>> > On Thu 29. Nov 2018 at 16:53, Andy Seaborne  wrote:
>> >
>> >> Jena 3.1.0 would be around the end of the year. I'd like to make use of
>> >> Greg's GeoSPARQL project the "headline" item for the release and to
>> >> retire jena-spatial in 3.10.0 as an indication of this.
>> >>
>> >> Because retirement is a new process for the project, I'm sending this
>> >> first 3.10.0 message quite early to give us discussion time.
>> >>
>> >> == Retirements
>> >>
>> >> We have talked about this before but not actually done anything. See
>> >> separate thread for discussion on retirement process and for the first
>> >> modules:
>> >>
>> >> jena-spatial
>> >> jena-fuseki1
>> >> jena-csv
>> >>
>> >> == Headlines
>> >>
>> >> JENA-664 : GeoSPARQL support
>> >>
>> >> I'd like to make use of Greg's GeoSPARQL project the "headline" item
>> for
>> >> the release and to retire jena-spatial in 3.10.0 as an indication of
>> this.
>> >>
>> >> JENA-1621 : Lucene upgrade to 7.4
>> >>  May need to reload lucene indexes.
>> >> (e.g. the lucene index was create originally with Lucene v5.x (prior
>> >> Jena 3.3.0). See Lucene upgrade tool.
>> >> https://lucene.apache.org/solr/guide/7_4/indexupgrader-tool.html
>> >>
>> >> JENA-1623 : Fuseki security
>> >> JENA-1627 : HTTP support
>> >> https://issues.apache.org/jira/browse/JENA-1623
>> >>
>> http://jena.staging.apache.org/documentation/fuseki2/data-access-control
>> >>
>> >> == JIRA:
>> >>
>> >> 31 currently.
>> >>
>> >> https://s.apache.org/jena-3.10.0-jira
>> >>
>> >> == Updates
>> >>
>> >> Only plugins. JENA-1624
>> >>
>> >> surefire : 2.21.0 -> 2.22.1 (+ SUREFIRE-1588)
>> >> compiler : 3.7.0 -> 3.8.0
>> >> shade: 3.1.0 -> 3.2.0
>> >>
>> >>  Andy
>> >>
>>
>
>
> --
>
>
> ---
> Marco Neumann
> KONA
>
>

-- 


---
Marco Neumann
KONA

Re: Toward Jena 3.10.0

[Marco Neumann]

how quickly can you hook geosparql into the release?

this would make lucene spatial obsolete in the next release.  has Greg
released performance benchmarks for his implementation? as I said I will
take a look at it over the weekend when time permits.

On Fri, Nov 30, 2018 at 11:02 AM Andy Seaborne  wrote:

> We could retire jena-spatial immediately after 3.10.0 - given the Lucene
> change that might be smoother, one release with updated dependencies.
>
> If that is the way forward, I think it is (mildly) better to take it out
> of the Fuseki/Full build in 3.10.0.
>
>  Andy
>
> On 29/11/2018 17:00, Marco Neumann wrote:
> > I will have to look into that I guess since I am frequent user of spatial
> > data.
> >
> > why not go to 7.5? was there an incompatibility?
> >
> > On Thu 29. Nov 2018 at 16:53, Andy Seaborne  wrote:
> >
> >> Jena 3.1.0 would be around the end of the year. I'd like to make use of
> >> Greg's GeoSPARQL project the "headline" item for the release and to
> >> retire jena-spatial in 3.10.0 as an indication of this.
> >>
> >> Because retirement is a new process for the project, I'm sending this
> >> first 3.10.0 message quite early to give us discussion time.
> >>
> >> == Retirements
> >>
> >> We have talked about this before but not actually done anything. See
> >> separate thread for discussion on retirement process and for the first
> >> modules:
> >>
> >> jena-spatial
> >> jena-fuseki1
> >> jena-csv
> >>
> >> == Headlines
> >>
> >> JENA-664 : GeoSPARQL support
> >>
> >> I'd like to make use of Greg's GeoSPARQL project the "headline" item for
> >> the release and to retire jena-spatial in 3.10.0 as an indication of
> this.
> >>
> >> JENA-1621 : Lucene upgrade to 7.4
> >>  May need to reload lucene indexes.
> >> (e.g. the lucene index was create originally with Lucene v5.x (prior
> >> Jena 3.3.0). See Lucene upgrade tool.
> >> https://lucene.apache.org/solr/guide/7_4/indexupgrader-tool.html
> >>
> >> JENA-1623 : Fuseki security
> >> JENA-1627 : HTTP support
> >> https://issues.apache.org/jira/browse/JENA-1623
> >>
> http://jena.staging.apache.org/documentation/fuseki2/data-access-control
> >>
> >> == JIRA:
> >>
> >> 31 currently.
> >>
> >> https://s.apache.org/jena-3.10.0-jira
> >>
> >> == Updates
> >>
> >> Only plugins. JENA-1624
> >>
> >> surefire : 2.21.0 -> 2.22.1 (+ SUREFIRE-1588)
> >> compiler : 3.7.0 -> 3.8.0
> >> shade: 3.1.0 -> 3.2.0
> >>
> >>  Andy
> >>
>


-- 


---
Marco Neumann
KONA

Re: Toward Jena 3.10.0

[Andy Seaborne]

We could retire jena-spatial immediately after 3.10.0 - given the Lucene 
change that might be smoother, one release with updated dependencies.


If that is the way forward, I think it is (mildly) better to take it out 
of the Fuseki/Full build in 3.10.0.


Andy

On 29/11/2018 17:00, Marco Neumann wrote:

I will have to look into that I guess since I am frequent user of spatial
data.

why not go to 7.5? was there an incompatibility?

On Thu 29. Nov 2018 at 16:53, Andy Seaborne  wrote:


Jena 3.1.0 would be around the end of the year. I'd like to make use of
Greg's GeoSPARQL project the "headline" item for the release and to
retire jena-spatial in 3.10.0 as an indication of this.

Because retirement is a new process for the project, I'm sending this
first 3.10.0 message quite early to give us discussion time.

== Retirements

We have talked about this before but not actually done anything. See
separate thread for discussion on retirement process and for the first
modules:

jena-spatial
jena-fuseki1
jena-csv

== Headlines

JENA-664 : GeoSPARQL support

I'd like to make use of Greg's GeoSPARQL project the "headline" item for
the release and to retire jena-spatial in 3.10.0 as an indication of this.

JENA-1621 : Lucene upgrade to 7.4
 May need to reload lucene indexes.
(e.g. the lucene index was create originally with Lucene v5.x (prior
Jena 3.3.0). See Lucene upgrade tool.
https://lucene.apache.org/solr/guide/7_4/indexupgrader-tool.html

JENA-1623 : Fuseki security
JENA-1627 : HTTP support
https://issues.apache.org/jira/browse/JENA-1623
http://jena.staging.apache.org/documentation/fuseki2/data-access-control

== JIRA:

31 currently.

https://s.apache.org/jena-3.10.0-jira

== Updates

Only plugins. JENA-1624

surefire : 2.21.0 -> 2.22.1 (+ SUREFIRE-1588)
compiler : 3.7.0 -> 3.8.0
shade: 3.1.0 -> 3.2.0

 Andy

Re: Toward Jena 3.10.0

[ajs6f]

This all makes sense to me. We've had a few nice contributions from various 
non-committer folks; perhaps we could mention them to give some credit? I'd 
like to give a straight Jira link but that kind of search is beyond my -fu. 
Here are some examples:

https://issues.apache.org/jira/browse/JENA-1642
https://issues.apache.org/jira/browse/JENA-1606

ajs6f

> On Nov 29, 2018, at 11:44 AM, Andy Seaborne  wrote:
> 
> Jena 3.1.0 would be around the end of the year. I'd like to make use of 
> Greg's GeoSPARQL project the "headline" item for the release and to retire 
> jena-spatial in 3.10.0 as an indication of this.
> 
> Because retirement is a new process for the project, I'm sending this first 
> 3.10.0 message quite early to give us discussion time.
> 
> == Retirements
> 
> We have talked about this before but not actually done anything. See separate 
> thread for discussion on retirement process and for the first modules:
> 
> jena-spatial
> jena-fuseki1
> jena-csv
> 
> == Headlines
> 
> JENA-664 : GeoSPARQL support
> 
> I'd like to make use of Greg's GeoSPARQL project the "headline" item for the 
> release and to retire jena-spatial in 3.10.0 as an indication of this.
> 
> JENA-1621 : Lucene upgrade to 7.4
>   May need to reload lucene indexes.
> (e.g. the lucene index was create originally with Lucene v5.x (prior Jena 
> 3.3.0). See Lucene upgrade tool.
> https://lucene.apache.org/solr/guide/7_4/indexupgrader-tool.html
> 
> JENA-1623 : Fuseki security
> JENA-1627 : HTTP support
> https://issues.apache.org/jira/browse/JENA-1623
> http://jena.staging.apache.org/documentation/fuseki2/data-access-control
> 
> == JIRA:
> 
> 31 currently.
> 
> https://s.apache.org/jena-3.10.0-jira
> 
> == Updates
> 
> Only plugins. JENA-1624
> 
> surefire : 2.21.0 -> 2.22.1 (+ SUREFIRE-1588)
> compiler : 3.7.0 -> 3.8.0
> shade: 3.1.0 -> 3.2.0
> 
>   Andy

Re: Toward Jena 3.10.0

[Marco Neumann]

I will have to look into that I guess since I am frequent user of spatial
data.

why not go to 7.5? was there an incompatibility?

On Thu 29. Nov 2018 at 16:53, Andy Seaborne  wrote:

> Jena 3.1.0 would be around the end of the year. I'd like to make use of
> Greg's GeoSPARQL project the "headline" item for the release and to
> retire jena-spatial in 3.10.0 as an indication of this.
>
> Because retirement is a new process for the project, I'm sending this
> first 3.10.0 message quite early to give us discussion time.
>
> == Retirements
>
> We have talked about this before but not actually done anything. See
> separate thread for discussion on retirement process and for the first
> modules:
>
> jena-spatial
> jena-fuseki1
> jena-csv
>
> == Headlines
>
> JENA-664 : GeoSPARQL support
>
> I'd like to make use of Greg's GeoSPARQL project the "headline" item for
> the release and to retire jena-spatial in 3.10.0 as an indication of this.
>
> JENA-1621 : Lucene upgrade to 7.4
> May need to reload lucene indexes.
> (e.g. the lucene index was create originally with Lucene v5.x (prior
> Jena 3.3.0). See Lucene upgrade tool.
> https://lucene.apache.org/solr/guide/7_4/indexupgrader-tool.html
>
> JENA-1623 : Fuseki security
> JENA-1627 : HTTP support
> https://issues.apache.org/jira/browse/JENA-1623
> http://jena.staging.apache.org/documentation/fuseki2/data-access-control
>
> == JIRA:
>
> 31 currently.
>
> https://s.apache.org/jena-3.10.0-jira
>
> == Updates
>
> Only plugins. JENA-1624
>
> surefire : 2.21.0 -> 2.22.1 (+ SUREFIRE-1588)
> compiler : 3.7.0 -> 3.8.0
> shade: 3.1.0 -> 3.2.0
>
> Andy
>
-- 


---
Marco Neumann
KONA