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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
23 matches
Mail list logo
