[jira] [Closed] (JENA-2266) convertLatLon swaps coordinates
[
https://issues.apache.org/jira/browse/JENA-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston closed JENA-2266.
---
Resolution: Invalid
> convertLatLon swaps coordinates
> ---
>
> Key: JENA-2266
> URL: https://issues.apache.org/jira/browse/JENA-2266
> Project: Apache Jena
> Issue Type: Bug
> Components: GeoSPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Claus Stadler
>Priority: Major
> Attachments: image-2022-01-30-18-28-56-974.png
>
>
> The correct setting is that longitude corresponds to x-axis and latitude to
> y-axis, but in the code lat is passed for x and lon for y.
> {code:java}
> public class ConvertLatLon {
> public static final Literal toLiteral(double lat, double lon) {
> checkBounds(lat, lon);
> return WKTLiteralFactory.createPoint(lat, lon, SRS_URI.WGS84_CRS);
> }
> }
> {code}
> {code:java}
> public class WKTLiteralFactory {
> public static final Literal createPoint(Double x, Double y, String
> srsURI) {
> String tidyURI = tidySrsURI(srsURI);
> return ResourceFactory.createTypedLiteral(tidyURI + "POINT(" +
> reducePrecision(x) + " " + reducePrecision(y)
> + ")", WKTDatatype.INSTANCE);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (JENA-2266) convertLatLon swaps coordinates
[
https://issues.apache.org/jira/browse/JENA-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484988#comment-17484988
]
Greg Albiston commented on JENA-2266:
-
Sorry, but I'm unclear about your use case and how it relates to GeoSPARQL Jena.
Perhaps this question may be better directed at the {{us...@jena.apache.org}}
mailing list with further detail provided.
> convertLatLon swaps coordinates
> ---
>
> Key: JENA-2266
> URL: https://issues.apache.org/jira/browse/JENA-2266
> Project: Apache Jena
> Issue Type: Bug
> Components: GeoSPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Claus Stadler
>Priority: Major
> Attachments: image-2022-01-30-18-28-56-974.png
>
>
> The correct setting is that longitude corresponds to x-axis and latitude to
> y-axis, but in the code lat is passed for x and lon for y.
> {code:java}
> public class ConvertLatLon {
> public static final Literal toLiteral(double lat, double lon) {
> checkBounds(lat, lon);
> return WKTLiteralFactory.createPoint(lat, lon, SRS_URI.WGS84_CRS);
> }
> }
> {code}
> {code:java}
> public class WKTLiteralFactory {
> public static final Literal createPoint(Double x, Double y, String
> srsURI) {
> String tidyURI = tidySrsURI(srsURI);
> return ResourceFactory.createTypedLiteral(tidyURI + "POINT(" +
> reducePrecision(x) + " " + reducePrecision(y)
> + ")", WKTDatatype.INSTANCE);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (JENA-2266) convertLatLon swaps coordinates
[
https://issues.apache.org/jira/browse/JENA-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484418#comment-17484418
]
Greg Albiston commented on JENA-2266:
-
Longitude is indeed the X axis and latitude is the Y axis. However, the SRS
EPSG 4326 (referenced by {{{}SRS_URI.WGS84_CRS{}}}) used for WGS84 reverses the
axis order when encoding to latitude/longitude. The SRS OGC CRS84 has the axis
order longitude/latitude.
The produced Point literal conforms with the axis order, if it is perhaps
somewhat confusing in the naming of function parameters.
An example of this is provided on page 17 of the GeoSPARQL standard.
!image-2022-01-30-18-28-56-974.png!
> convertLatLon swaps coordinates
> ---
>
> Key: JENA-2266
> URL: https://issues.apache.org/jira/browse/JENA-2266
> Project: Apache Jena
> Issue Type: Bug
> Components: GeoSPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Claus Stadler
>Priority: Major
> Attachments: image-2022-01-30-18-28-56-974.png
>
>
> The correct setting is that longitude corresponds to x-axis and latitude to
> y-axis, but in the code lat is passed for x and lon for y.
> {code:java}
> public class ConvertLatLon {
> public static final Literal toLiteral(double lat, double lon) {
> checkBounds(lat, lon);
> return WKTLiteralFactory.createPoint(lat, lon, SRS_URI.WGS84_CRS);
> }
> }
> {code}
> {code:java}
> public class WKTLiteralFactory {
> public static final Literal createPoint(Double x, Double y, String
> srsURI) {
> String tidyURI = tidySrsURI(srsURI);
> return ResourceFactory.createTypedLiteral(tidyURI + "POINT(" +
> reducePrecision(x) + " " + reducePrecision(y)
> + ")", WKTDatatype.INSTANCE);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (JENA-2266) convertLatLon swaps coordinates
[
https://issues.apache.org/jira/browse/JENA-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston updated JENA-2266:
Attachment: image-2022-01-30-18-28-56-974.png
> convertLatLon swaps coordinates
> ---
>
> Key: JENA-2266
> URL: https://issues.apache.org/jira/browse/JENA-2266
> Project: Apache Jena
> Issue Type: Bug
> Components: GeoSPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Claus Stadler
>Priority: Major
> Attachments: image-2022-01-30-18-28-56-974.png
>
>
> The correct setting is that longitude corresponds to x-axis and latitude to
> y-axis, but in the code lat is passed for x and lon for y.
> {code:java}
> public class ConvertLatLon {
> public static final Literal toLiteral(double lat, double lon) {
> checkBounds(lat, lon);
> return WKTLiteralFactory.createPoint(lat, lon, SRS_URI.WGS84_CRS);
> }
> }
> {code}
> {code:java}
> public class WKTLiteralFactory {
> public static final Literal createPoint(Double x, Double y, String
> srsURI) {
> String tidyURI = tidySrsURI(srsURI);
> return ResourceFactory.createTypedLiteral(tidyURI + "POINT(" +
> reducePrecision(x) + " " + reducePrecision(y)
> + ")", WKTDatatype.INSTANCE);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (JENA-2230) Assembler for GeoSPARQL
[
https://issues.apache.org/jira/browse/JENA-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466110#comment-17466110
]
Greg Albiston commented on JENA-2230:
-
Thank you for adding this in. It is a big step closer to {{fuseki-geosparql}}
not being needed (and possibly the data loading command moving to {{jena-cmd
}}or equivalent).
About GeoSPARQL's handling of update, it is only the spatial index that is a
concern. The rest of the functionality checks the dataset on-demand as part of
the SPARQL query engine's property and filter functions.
When setting up the {{fuseki-geosparql}} application, it wasn't clear, or
documented as far as I could tell, how to hook into update queries to add or
remove geometries to the spatial index. At the time, the JTS library only
offered a read-only (after setup) StrTree and a write QuadTree (with the latter
requiring additional filter checks for validity). Since Fuseki at the time
required a restart when using inferencing with updates, the same approach was
followed for the use of spatial indexes and the StrTree selected.
The JTS spatial indexes have a common interface, so switching to one of the
alternatives should be straightforward and several more have been implemented
since (see {{{}org.apache.jena.geosparql.spatial.SpatialIndex in GeoSPARQL
module and org.locationtech.jts.index [JTS
library|https://locationtech.github.io/jts/javadoc/org/locationtech/jts/index/package-frame.html]{}}}).
It then just comes down to how the SPARQL query engine notifies of update
queries, so these can be passed to the spatial index. The spatial index is
stored in the Dataset Context during setup and provided to the property and
filter functions during querying.
If I can be pointed in the right direction then I can look to resolve updating
the spatial index?
> Assembler for GeoSPARQL
> ---
>
> Key: JENA-2230
> URL: https://issues.apache.org/jira/browse/JENA-2230
> Project: Apache Jena
> Issue Type: New Feature
> Components: GeoSPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 4.4.0
>
>
> An assembler for the GeoSPARQL engine.
> This is for {{jena-geosparql}}, making it a loadable module for Jena and
> usable with any Fuseki server.
> jena-fuseki-geosparql and its command line are unchanged.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (JENA-2136) Reintroduce spatial module
[ https://issues.apache.org/jira/browse/JENA-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17385134#comment-17385134 ] Greg Albiston commented on JENA-2136: - The spatial functions from the jena-spatial module are already supported in jena-geosparql. There are versions available for using lat/lon geo predicates or the GeoSPARQL data structure, so it isn't a requirement to convert datasets to access this functionality. > Reintroduce spatial module > -- > > Key: JENA-2136 > URL: https://issues.apache.org/jira/browse/JENA-2136 > Project: Apache Jena > Issue Type: Wish > Components: Spatial >Reporter: Øyvind Gjesdal >Priority: Minor > > I would like to reintroduce the jena-spatial module for future versions of > Jena. I've begun [a PR|https://github.com/apache/jena/pull/1029] for this but > I'm not sure if it should be in the jena-repo, since jena-geosparql is in use. > We would like to use jena-spatial, while also being able to upgrade our > fuseki servers. We still have internal and external datasets not prepared for > geosparql. > Changes made so far > * Readd code from last working jena-spatial in 3.12 > * Remove dependency for Lucene-spatial (is now part of Lucene spatial > extras, removed in > [https://github.com/apache/lucene/commit/78655239c58a1ed72d6e015dd05a0b355c936999]) > * Upgrade Spatial4j version 0.8 (Two minor versions since last time) > * Readd as main module in pom.xml files > * Comment out spatial Logging initialization in tests (No longer used > library) in tests > The tests for jena-spatial are now running again on > ([https://github.com/OyvindLGjesdal/jena/runs/3114796795?check_suite_focus=true#step:4:3804]) > Is adding it again useful for more users, or is maintaining the module > outside of Apache/jena and adding it to classpath the best option? > We can look at changes for getting tests to pass if the build for > jena-spatial starts failing in the future, and I can also create a PR for > reopening the jena-site documentation. > > https://github.com/apache/jena/pull/1029 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JENA-1996) Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
[
https://issues.apache.org/jira/browse/JENA-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston closed JENA-1996.
---
Fix Version/s: Jena 3.17.0
Resolution: Fixed
> Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
> --
>
> Key: JENA-1996
> URL: https://issues.apache.org/jira/browse/JENA-1996
> Project: Apache Jena
> Issue Type: Bug
>Affects Versions: Jena 3.17.0
>Reporter: Andy Seaborne
> Assignee: Greg Albiston
>Priority: Major
> Fix For: Jena 3.17.0
>
>
> After the recent dependabot updates:
> jts-core 1.16.1 to 1.17.1 works.
> sis from 0.8 to 1.0 causes a test failure.
> org.apache.sis.core:sis-referencing-data:1.0 (scope test)
> org.apache.sis.non-free:sis-embedded-data:1.0 (scope test)
>
> With version 1.0:
> {noformat}
> [INFO] Running
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019
> s <<< FAILURE! - in
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR]
> testGetDefaultWKTCRS(org.apache.jena.geosparql.implementation.registry.SRSRegistryTest)
> Time elapsed: 0.018 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<...CRS", 84, CITATION["[OGC:]WMS"],
> URI["urn:ogc:...> but was:<...CRS", 84, CITATION["[]WMS"], URI["urn:ogc:...>
> at
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest.testGetDefaultWKTCRS(SRSRegistryTest.java:94)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (JENA-1996) Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
[
https://issues.apache.org/jira/browse/JENA-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston reassigned JENA-1996:
---
Assignee: Greg Albiston
> Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
> --
>
> Key: JENA-1996
> URL: https://issues.apache.org/jira/browse/JENA-1996
> Project: Apache Jena
> Issue Type: Bug
>Affects Versions: Jena 3.17.0
>Reporter: Andy Seaborne
> Assignee: Greg Albiston
>Priority: Major
>
> After the recent dependabot updates:
> jts-core 1.16.1 to 1.17.1 works.
> sis from 0.8 to 1.0 causes a test failure.
> org.apache.sis.core:sis-referencing-data:1.0 (scope test)
> org.apache.sis.non-free:sis-embedded-data:1.0 (scope test)
>
> With version 1.0:
> {noformat}
> [INFO] Running
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019
> s <<< FAILURE! - in
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR]
> testGetDefaultWKTCRS(org.apache.jena.geosparql.implementation.registry.SRSRegistryTest)
> Time elapsed: 0.018 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<...CRS", 84, CITATION["[OGC:]WMS"],
> URI["urn:ogc:...> but was:<...CRS", 84, CITATION["[]WMS"], URI["urn:ogc:...>
> at
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest.testGetDefaultWKTCRS(SRSRegistryTest.java:94)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JENA-1996) Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
[
https://issues.apache.org/jira/browse/JENA-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17232336#comment-17232336
]
Greg Albiston commented on JENA-1996:
-
Test has been fixed and is now in `master`.
> Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
> --
>
> Key: JENA-1996
> URL: https://issues.apache.org/jira/browse/JENA-1996
> Project: Apache Jena
> Issue Type: Bug
>Affects Versions: Jena 3.17.0
>Reporter: Andy Seaborne
> Assignee: Greg Albiston
>Priority: Major
>
> After the recent dependabot updates:
> jts-core 1.16.1 to 1.17.1 works.
> sis from 0.8 to 1.0 causes a test failure.
> org.apache.sis.core:sis-referencing-data:1.0 (scope test)
> org.apache.sis.non-free:sis-embedded-data:1.0 (scope test)
>
> With version 1.0:
> {noformat}
> [INFO] Running
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019
> s <<< FAILURE! - in
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR]
> testGetDefaultWKTCRS(org.apache.jena.geosparql.implementation.registry.SRSRegistryTest)
> Time elapsed: 0.018 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<...CRS", 84, CITATION["[OGC:]WMS"],
> URI["urn:ogc:...> but was:<...CRS", 84, CITATION["[]WMS"], URI["urn:ogc:...>
> at
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest.testGetDefaultWKTCRS(SRSRegistryTest.java:94)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JENA-1969) Can't start geosparql fuseki server with -rf and -t
[
https://issues.apache.org/jira/browse/JENA-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17207321#comment-17207321
]
Greg Albiston commented on JENA-1969:
-
The current Spatial Index is immutable once built. It needs to be
re-constructed when new geometries are added. This is consistent with the need
to restart Fuseki when using inferencing to detect new triples.
Adding a TDB2 switch should be straightforward to do.
> Can't start geosparql fuseki server with -rf and -t
> ---
>
> Key: JENA-1969
> URL: https://issues.apache.org/jira/browse/JENA-1969
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki, Spatial, TDB
>Affects Versions: Jena 3.16.0
> Environment: Ubuntu 20.04.1 LTS
> JENA_HOME=/apache-jena-3.17.0-SNAPSHOT
> FUSEKI_HOME=/home/lotico/jena/apache-jena-fuseki-3.17.0-SNAPSHOT
> openjdk version "13.0.3" 2020-04-14
> OpenJDK Runtime Environment (build 13.0.3+3-Ubuntu-1ubuntu2)
> OpenJDK 64-Bit Server VM (build 13.0.3+3-Ubuntu-1ubuntu2, mixed mode)
> Reporter: Marco Neumann
>Assignee: Greg Albiston
>Priority: Major
> Fix For: Jena 3.17.0
>
>
> geosparql fuseki server can't be started with option combination -rf and -t
> as described in the jena fuseki geosparql user documentation
> (https://jena.apache.org/documentation/geosparql/geosparql-fuseki).
> Individually with either option -rf or -t fuseki geosparql starts fine and
> works as expected. Data can be loaded programmatically to tdb once created.
> {noformat}
> java -jar jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar -rf data.ttl -t
> "testDB2"
> WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will
> impact performance.
> [2020-09-25 20:22:39] Main INFO Arguments Received: [-rf, data.ttl,
> -t, testDB2]
> [2020-09-25 20:22:39] DatasetOperations INFO Server Configuration:
> port=3030, datsetName=ds, loopbackOnly=true, updateAllowed=false,
> inference=false, applyDefaultGeometry=false, validateGeometryLiteral=false,
> convertGeoPredicates=false, removeGeoPredicates=false, queryRewrite=true,
> tdbFile=testDB2, fileGraphFormats=[FileGraphFormat{rdfFile=data.ttl,
> graphName=, rdfFormat=Turtle/pretty}], fileGraphDelimiters=[],
> indexEnabled=true, indexSizes=[-1, -1, -1], indexExpiries=[5000, 5000, 5000],
> spatialIndexFile=null, help=false
> [2020-09-25 20:22:39] DatasetOperations INFO TDB Dataset: testDB2
> [2020-09-25 20:22:41] DatasetOperations INFO Reading RDF - Started - File:
> data.ttl, Graph Name: , RDF Format: Turtle/pretty
> [2020-09-25 20:22:41] DatasetOperations INFO Reading RDF - Completed - File:
> data.ttl, Graph Name: , RDF Format: Turtle/pretty
> Exception in thread "main"
> org.apache.jena.tdb.transaction.TDBTransactionException: Not in a transaction
> at
> org.apache.jena.tdb.transaction.DatasetGraphTransaction.get(DatasetGraphTransaction.java:138)
> at
> org.apache.jena.tdb.transaction.DatasetGraphTransaction.get(DatasetGraphTransaction.java:49)
> at
> org.apache.jena.sparql.core.DatasetGraphWrapper.getR(DatasetGraphWrapper.java:103)
> at
> org.apache.jena.sparql.core.DatasetGraphWrapper.isEmpty(DatasetGraphWrapper.java:192)
> at org.apache.jena.sparql.core.DatasetImpl.isEmpty(DatasetImpl.java:247)
> at
> org.apache.jena.fuseki.geosparql.DatasetOperations.setup(DatasetOperations.java:95)
> at org.apache.jena.fuseki.geosparql.Main.main(Main.java:64)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JENA-1969) Can't start geosparql fuseki server with -rf and -t
[
https://issues.apache.org/jira/browse/JENA-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston resolved JENA-1969.
-
Fix Version/s: Jena 3.17.0
Resolution: Fixed
TDB now requires a transaction to check if dataset is empty. Transaction now
added.
> Can't start geosparql fuseki server with -rf and -t
> ---
>
> Key: JENA-1969
> URL: https://issues.apache.org/jira/browse/JENA-1969
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki, Spatial, TDB
>Affects Versions: Jena 3.16.0
> Environment: Ubuntu 20.04.1 LTS
> JENA_HOME=/apache-jena-3.17.0-SNAPSHOT
> FUSEKI_HOME=/home/lotico/jena/apache-jena-fuseki-3.17.0-SNAPSHOT
> openjdk version "13.0.3" 2020-04-14
> OpenJDK Runtime Environment (build 13.0.3+3-Ubuntu-1ubuntu2)
> OpenJDK 64-Bit Server VM (build 13.0.3+3-Ubuntu-1ubuntu2, mixed mode)
> Reporter: Marco Neumann
>Assignee: Greg Albiston
>Priority: Major
> Fix For: Jena 3.17.0
>
>
> geosparql fuseki server can't be started with option combination -rf and -t
> as described in the jena fuseki geosparql user documentation
> (https://jena.apache.org/documentation/geosparql/geosparql-fuseki).
> Individually with either option -rf or -t fuseki geosparql starts fine and
> works as expected. Data can be loaded programmatically to tdb once created.
> {noformat}
> java -jar jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar -rf data.ttl -t
> "testDB2"
> WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will
> impact performance.
> [2020-09-25 20:22:39] Main INFO Arguments Received: [-rf, data.ttl,
> -t, testDB2]
> [2020-09-25 20:22:39] DatasetOperations INFO Server Configuration:
> port=3030, datsetName=ds, loopbackOnly=true, updateAllowed=false,
> inference=false, applyDefaultGeometry=false, validateGeometryLiteral=false,
> convertGeoPredicates=false, removeGeoPredicates=false, queryRewrite=true,
> tdbFile=testDB2, fileGraphFormats=[FileGraphFormat{rdfFile=data.ttl,
> graphName=, rdfFormat=Turtle/pretty}], fileGraphDelimiters=[],
> indexEnabled=true, indexSizes=[-1, -1, -1], indexExpiries=[5000, 5000, 5000],
> spatialIndexFile=null, help=false
> [2020-09-25 20:22:39] DatasetOperations INFO TDB Dataset: testDB2
> [2020-09-25 20:22:41] DatasetOperations INFO Reading RDF - Started - File:
> data.ttl, Graph Name: , RDF Format: Turtle/pretty
> [2020-09-25 20:22:41] DatasetOperations INFO Reading RDF - Completed - File:
> data.ttl, Graph Name: , RDF Format: Turtle/pretty
> Exception in thread "main"
> org.apache.jena.tdb.transaction.TDBTransactionException: Not in a transaction
> at
> org.apache.jena.tdb.transaction.DatasetGraphTransaction.get(DatasetGraphTransaction.java:138)
> at
> org.apache.jena.tdb.transaction.DatasetGraphTransaction.get(DatasetGraphTransaction.java:49)
> at
> org.apache.jena.sparql.core.DatasetGraphWrapper.getR(DatasetGraphWrapper.java:103)
> at
> org.apache.jena.sparql.core.DatasetGraphWrapper.isEmpty(DatasetGraphWrapper.java:192)
> at org.apache.jena.sparql.core.DatasetImpl.isEmpty(DatasetImpl.java:247)
> at
> org.apache.jena.fuseki.geosparql.DatasetOperations.setup(DatasetOperations.java:95)
> at org.apache.jena.fuseki.geosparql.Main.main(Main.java:64)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JENA-1970) GeoSPARQL spatial:nearby geo:lat and geo:long indexing of Literals
[
https://issues.apache.org/jira/browse/JENA-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston resolved JENA-1970.
-
Fix Version/s: Jena 3.17.0
Resolution: Fixed
Double typed literals and untyped literals in double form are now accepted when
converting from latitude and longitude coordinates.
> GeoSPARQL spatial:nearby geo:lat and geo:long indexing of Literals
> --
>
> Key: JENA-1970
> URL: https://issues.apache.org/jira/browse/JENA-1970
> Project: Apache Jena
> Issue Type: New Feature
> Components: Jena
>Affects Versions: Jena 3.16.0
> Environment: any
>Reporter: Marco Neumann
>Assignee: Greg Albiston
>Priority: Minor
> Fix For: Jena 3.17.0
>
>
> PREFIX spatial: <http://jena.apache.org/spatial#>
> the spatial:nearby property function now fails to operate on untyped
> literals. While http://www.w3.org/2003/01/geo/wgs84_pos# mentions decimals in
> the range it is common to find data in the wild that fails to adhere to the
> vocabulary specification. Furthermore functions in the
> http://jena.apache.org/function/spatial# namespace continue to be able to
> process untyped literals. It might be worthwhile to consider to typecast
> literals here in spatial functions for data processed for latitude and
> longitude in the wgs84_pos namespace.
> {noformat}
> Fuseki WARN [1] RC = 500 : Not a number: "53.72833"
> org.apache.jena.sparql.expr.ExprEvalException: Not a number: "53.72833"
> Caused by: org.apache.jena.datatypes.DatatypeFormatException: Not a number:
> "53.72833"
> at
> org.apache.jena.geosparql.spatial.ConvertLatLon.toNodeValue(ConvertLatLon.java:47)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.geosparql.spatial.ConvertLatLon.toNode(ConvertLatLon.java:62)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.geosparql.spatial.property_functions.GenericSpatialPropertyFunction.checkBound(GenericSpatialPropertyFunction.java:132)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.geosparql.spatial.property_functions.GenericSpatialPropertyFunction.search(GenericSpatialPropertyFunction.java:87)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.geosparql.spatial.property_functions.GenericSpatialPropertyFunction.execEvaluated(GenericSpatialPropertyFunction.java:66)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.pfunction.PFuncSimpleAndList.execEvaluated(PFuncSimpleAndList.java:44)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.pfunction.PropertyFunctionEval.exec(PropertyFunctionEval.java:42)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.pfunction.PropertyFunctionBase$RepeatApplyIteratorPF.nextStage(PropertyFunctionBase.java:106)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:108)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.iterator.QueryIterProcedure.hasNextBinding(QueryIterProcedure.java:73)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.main.iterator.QueryIterGraph$QueryIterGraphInner.hasNextBinding(QueryIterGraph.java:121)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.itera
[jira] [Assigned] (JENA-1969) Can't start geosparql fuseki server with -rf and -t
[
https://issues.apache.org/jira/browse/JENA-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston reassigned JENA-1969:
---
Assignee: Greg Albiston
> Can't start geosparql fuseki server with -rf and -t
> ---
>
> Key: JENA-1969
> URL: https://issues.apache.org/jira/browse/JENA-1969
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki, Spatial, TDB
>Affects Versions: Jena 3.16.0
> Environment: Ubuntu 20.04.1 LTS
> JENA_HOME=/apache-jena-3.17.0-SNAPSHOT
> FUSEKI_HOME=/home/lotico/jena/apache-jena-fuseki-3.17.0-SNAPSHOT
> openjdk version "13.0.3" 2020-04-14
> OpenJDK Runtime Environment (build 13.0.3+3-Ubuntu-1ubuntu2)
> OpenJDK 64-Bit Server VM (build 13.0.3+3-Ubuntu-1ubuntu2, mixed mode)
> Reporter: Marco Neumann
>Assignee: Greg Albiston
>Priority: Major
>
> geosparql fuseki server can't be started with option combination -rf and -t
> as described in the jena fuseki geosparql user documentation
> (https://jena.apache.org/documentation/geosparql/geosparql-fuseki).
> Individually with either option -rf or -t fuseki geosparql starts fine and
> works as expected. Data can be loaded programmatically to tdb once created.
> {noformat}
> java -jar jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar -rf data.ttl -t
> "testDB2"
> WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will
> impact performance.
> [2020-09-25 20:22:39] Main INFO Arguments Received: [-rf, data.ttl,
> -t, testDB2]
> [2020-09-25 20:22:39] DatasetOperations INFO Server Configuration:
> port=3030, datsetName=ds, loopbackOnly=true, updateAllowed=false,
> inference=false, applyDefaultGeometry=false, validateGeometryLiteral=false,
> convertGeoPredicates=false, removeGeoPredicates=false, queryRewrite=true,
> tdbFile=testDB2, fileGraphFormats=[FileGraphFormat{rdfFile=data.ttl,
> graphName=, rdfFormat=Turtle/pretty}], fileGraphDelimiters=[],
> indexEnabled=true, indexSizes=[-1, -1, -1], indexExpiries=[5000, 5000, 5000],
> spatialIndexFile=null, help=false
> [2020-09-25 20:22:39] DatasetOperations INFO TDB Dataset: testDB2
> [2020-09-25 20:22:41] DatasetOperations INFO Reading RDF - Started - File:
> data.ttl, Graph Name: , RDF Format: Turtle/pretty
> [2020-09-25 20:22:41] DatasetOperations INFO Reading RDF - Completed - File:
> data.ttl, Graph Name: , RDF Format: Turtle/pretty
> Exception in thread "main"
> org.apache.jena.tdb.transaction.TDBTransactionException: Not in a transaction
> at
> org.apache.jena.tdb.transaction.DatasetGraphTransaction.get(DatasetGraphTransaction.java:138)
> at
> org.apache.jena.tdb.transaction.DatasetGraphTransaction.get(DatasetGraphTransaction.java:49)
> at
> org.apache.jena.sparql.core.DatasetGraphWrapper.getR(DatasetGraphWrapper.java:103)
> at
> org.apache.jena.sparql.core.DatasetGraphWrapper.isEmpty(DatasetGraphWrapper.java:192)
> at org.apache.jena.sparql.core.DatasetImpl.isEmpty(DatasetImpl.java:247)
> at
> org.apache.jena.fuseki.geosparql.DatasetOperations.setup(DatasetOperations.java:95)
> at org.apache.jena.fuseki.geosparql.Main.main(Main.java:64)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (JENA-1970) GeoSPARQL spatial:nearby geo:lat and geo:long indexing of Literals
[
https://issues.apache.org/jira/browse/JENA-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston reassigned JENA-1970:
---
Assignee: Greg Albiston
> GeoSPARQL spatial:nearby geo:lat and geo:long indexing of Literals
> --
>
> Key: JENA-1970
> URL: https://issues.apache.org/jira/browse/JENA-1970
> Project: Apache Jena
> Issue Type: New Feature
> Components: Jena
>Affects Versions: Jena 3.16.0
> Environment: any
>Reporter: Marco Neumann
>Assignee: Greg Albiston
>Priority: Minor
>
> PREFIX spatial: <http://jena.apache.org/spatial#>
> the spatial:nearby property function now fails to operate on untyped
> literals. While http://www.w3.org/2003/01/geo/wgs84_pos# mentions decimals in
> the range it is common to find data in the wild that fails to adhere to the
> vocabulary specification. Furthermore functions in the
> http://jena.apache.org/function/spatial# namespace continue to be able to
> process untyped literals. It might be worthwhile to consider to typecast
> literals here in spatial functions for data processed for latitude and
> longitude in the wgs84_pos namespace.
> {noformat}
> Fuseki WARN [1] RC = 500 : Not a number: "53.72833"
> org.apache.jena.sparql.expr.ExprEvalException: Not a number: "53.72833"
> Caused by: org.apache.jena.datatypes.DatatypeFormatException: Not a number:
> "53.72833"
> at
> org.apache.jena.geosparql.spatial.ConvertLatLon.toNodeValue(ConvertLatLon.java:47)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.geosparql.spatial.ConvertLatLon.toNode(ConvertLatLon.java:62)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.geosparql.spatial.property_functions.GenericSpatialPropertyFunction.checkBound(GenericSpatialPropertyFunction.java:132)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.geosparql.spatial.property_functions.GenericSpatialPropertyFunction.search(GenericSpatialPropertyFunction.java:87)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.geosparql.spatial.property_functions.GenericSpatialPropertyFunction.execEvaluated(GenericSpatialPropertyFunction.java:66)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.pfunction.PFuncSimpleAndList.execEvaluated(PFuncSimpleAndList.java:44)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.pfunction.PropertyFunctionEval.exec(PropertyFunctionEval.java:42)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.pfunction.PropertyFunctionBase$RepeatApplyIteratorPF.nextStage(PropertyFunctionBase.java:106)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:108)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.iterator.QueryIterProcedure.hasNextBinding(QueryIterProcedure.java:73)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.main.iterator.QueryIterGraph$QueryIterGraphInner.hasNextBinding(QueryIterGraph.java:121)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:74)
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
> at
> org.apache.jena.sparql.engine.it
[jira] [Commented] (JENA-1915) spatial:greatCircle appears to be returning wrong answers
[
https://issues.apache.org/jira/browse/JENA-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17135217#comment-17135217
]
Greg Albiston commented on JENA-1915:
-
Hi Bryon,
Thanks for reporting this and the test cases. This has now been fixed on
`master` branch with the test values you provided now being used as unit tests.
There are still the minor discrepancies (less than 300m) which are likely due
to rounding differences.
Thanks again,
Greg
> spatial:greatCircle appears to be returning wrong answers
> -
>
> Key: JENA-1915
> URL: https://issues.apache.org/jira/browse/JENA-1915
> Project: Apache Jena
> Issue Type: Bug
> Components: Spatial
>Affects Versions: Jena 3.13.1
>Reporter: Bryon Jacob
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> the `spatial:greatCircle` function appears broken - sometimes returning
> negative numbers. returning negative numbers can never be correct from a
> distance function - but I've tried to produce something more useful than that
> as a defect report and repro...
> I was trying to "port" some SPARQL queries where I'd written the great circle
> function (Haversine formula) to use the spatial:greatCircle function - which
> means I had a pretty good test case to see where the issue arises. I
> simplified my query down to a repeatable test that demonstrates the issue:
> note that in my original query, I was using a custom jena function to compute
> `radians` - since that function won't be available to you in stock jena to
> try this out, I've precomputed the radians values and put them in the VALUES
> block next to lat/lon pairs. This should be runnable on any stock Jena
> instance with the jena-geosparql functions loaded. Note that for most of the
> distances computed, the two distances agree quite closely - but for the last
> two, the jena function returns a negative number, where the hand-computed
> value is a correct distance between those points
> {code:java}
> PREFIX m: <http://www.w3.org/2005/xpath-functions/math#>
> PREFIX spatial: <http://jena.apache.org/function/spatial#>
> # this is a namespace of custom functions, which won't be available in stock
> Jena - to reproduce
> # this, I've pre-computed the radian values and included them in a VALUES
> block below...
> # PREFIX f: <http://data.world/function/functions#>
> SELECT ?lat1 ?lon1 ?lat2 ?lon2 ?φ1 ?φ2 ?Δφ ?Δλ ?d1 ?d2
> WHERE {
> VALUES (?lat1 ?lon1 ?lat2 ?lon2 ?φ1 ?φ2 ?Δφ ?Δλ) {
> # in my original query, I was computing radians using a custom
> radians function, which won't be available
> # in stock Jena, so to make this reproducible I precomputed the
> radians values needed for the Haversine
> (41.2572 -95.965641.2592 -95.93390.7201 0.7201
> 0. 0.0006)
> (41.2572 -95.965641.2482 -96.072 0.7201 0.7199
> -0.0002 -0.0019)
> (41.2572 -95.965641.5871 -93.626 0.7201 0.7258
> 0.0058 0.0408)
> (41.2572 -95.965651.0472 -113.9998 0.7201 0.8909
> 0.1709 -0.3148)
> (41.2572 -95.965640.7528 -73.98760.7201 0.7113
> -0.0088 0.3836)
> (41.2572 -95.965649.7237 13.3422 0.7201 0.8678
> 0.1478 1.9078)
> (41.2572 -95.9656-33.906518.4175 0.7201
> -0.5918 -1.3119 1.9964)
> (41.2572 -95.9656-33.8646151.20990.7201
> -0.5910 -1.3111 4.3140)
> }
>
> # calculate the "great circle" distance between the two (lat φ, long λ)
> points, in kilometers.
> # these are the function calls in my original query, commented out and
> replaced with VALUES above
> # BIND (f:radians(?lat1) AS ?φ1)
> # BIND (f:radians(?lat2) AS ?φ2)
> # BIND (f:radians(?lat2 - ?lat1) AS ?Δφ)
> # BIND (f:radians(?lon2 - ?lon1) AS ?Δλ)
> BIND (m:sin(?Δφ / 2) * m:sin(?Δφ / 2) + m:cos(?φ1) * m:cos(?φ2) *
> m:sin(?Δλ / 2) * m:sin(?Δλ / 2) AS ?a)
> BIND (2 * m:atan2(m:sqrt(?a), m:sqrt(1 - ?a)) AS ?c)
> BIND (6371 AS ?RadiusOfEarthInKm)
> BIND (?RadiusOfEarthInKm * ?c AS ?d1)
> # call the Jena function for comparison
> BIND(spatial:greatCircle(?lat1, ?lon1, ?lat2, ?lon2,
> <http://www.opengis.net/def/uom/OGC/1.0/kilometre>) AS ?d2)
> }
> {code}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JENA-1818) Bug: CustomCoordinateSequence::setOrdinate missing break statements
[ https://issues.apache.org/jira/browse/JENA-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Albiston resolved JENA-1818. - Fix Version/s: Jena 3.15.0 Resolution: Fixed Break statements added. > Bug: CustomCoordinateSequence::setOrdinate missing break statements > --- > > Key: JENA-1818 > URL: https://issues.apache.org/jira/browse/JENA-1818 > Project: Apache Jena > Issue Type: Bug > Components: Spatial >Affects Versions: Jena 3.13.1 >Reporter: Philipp Neuschwander > Assignee: Greg Albiston >Priority: Major > Fix For: Jena 3.15.0 > > > https://github.com/apache/jena/blob/master/jena-geosparql/src/main/java/org/apache/jena/geosparql/implementation/jts/CustomCoordinateSequence.java#L441 > > There should be "break" statements in that switch. > Currently there is a fallthrough manipulating other axis' values leading to > data corruption. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (JENA-1818) Bug: CustomCoordinateSequence::setOrdinate missing break statements
[ https://issues.apache.org/jira/browse/JENA-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Albiston reassigned JENA-1818: --- Assignee: Greg Albiston > Bug: CustomCoordinateSequence::setOrdinate missing break statements > --- > > Key: JENA-1818 > URL: https://issues.apache.org/jira/browse/JENA-1818 > Project: Apache Jena > Issue Type: Bug > Components: Spatial >Affects Versions: Jena 3.13.1 >Reporter: Philipp Neuschwander > Assignee: Greg Albiston >Priority: Major > > https://github.com/apache/jena/blob/master/jena-geosparql/src/main/java/org/apache/jena/geosparql/implementation/jts/CustomCoordinateSequence.java#L441 > > There should be "break" statements in that switch. > Currently there is a fallthrough manipulating other axis' values leading to > data corruption. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JENA-1820) GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype, malformed lexicalForm
[
https://issues.apache.org/jira/browse/JENA-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston resolved JENA-1820.
-
Fix Version/s: Jena 3.15.0
Resolution: Fixed
LinearRing added to XML construction for Polygon GML shape. Tests updated.
> GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype,
> malformed lexicalForm
> -
>
> Key: JENA-1820
> URL: https://issues.apache.org/jira/browse/JENA-1820
> Project: Apache Jena
> Issue Type: Bug
> Components: Spatial
>Affects Versions: Jena 3.13.1
>Reporter: Philipp Neuschwander
>Assignee: Greg Albiston
>Priority: Major
> Fix For: Jena 3.15.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> GML-Literal of MultiPolygon/Polygon is malformed (generated by GMLWriter).
> Under the gml:exterior and gml:interior node, there should be a linear ring
> that contains the posList. But the posList is generated as a direct child to
> gml:exterior/interior:
> {code:java}
> http://www.opengis.net/ont/gml;
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>0
> 0 10 0 10 10 0 10 0
> 05 5 7 7 7 5 5
> 54 4 4 5 5 5 4
> 4
> {code}
> The missing linearRing leads to NullPointerException when trying to call
> {code:java}
> geometryWrapper.asLiteral(GMLDatatype.INSTANCE)
> {code}
> as the GMLReader (I have no clue why it is called as part of the
> asLiteral-call) tries to access the linearRing and it's posList child.
> Stackstrace:
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extractPosList(GMLReader.java:223)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildLinearRing(GMLReader.java:503)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildPolygon(GMLReader.java:477)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildMultiSurface(GMLReader.java:644)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildGeometry(GMLReader.java:199)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.(GMLReader.java:108)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extract(GMLReader.java:707)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GMLDatatype.read(GMLDatatype.java:84)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieveMemoryIndex(GeometryLiteralIndex.java:77)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieve(GeometryLiteralIndex.java:51)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:57)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:50)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:32)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelImpl.setValue(LiteralLabelImpl.java:217)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelImpl.setLiteralLabel_1(LiteralLabelImpl.java:111)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelImpl.(LiteralLabelImpl.java:100)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelFactory.create(LiteralLabelFactory.java:50)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.NodeFactory.createLiteral(NodeFactory.java:171)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.rdf.model.ResourceFactory$Impl.createTypedLiteral(ResourceFactory.java:313)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.rdf.model.ResourceFactory.createTypedLiteral(ResourceFactory.java:148)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.GeometryWrapper.asLiteral(GeometryWrapper.java:986)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JENA-1820) GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype, malformed lexicalForm
[
https://issues.apache.org/jira/browse/JENA-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17019764#comment-17019764
]
Greg Albiston edited comment on JENA-1820 at 1/20/20 10:56 PM:
---
This has now been fixed in 3.15.0-snapshot. Apologies for any inconvenience.
was (Author: gregalbiston):
This has now been fixed in 3.15-snapshot. Apologies for any inconvenience.
> GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype,
> malformed lexicalForm
> -
>
> Key: JENA-1820
> URL: https://issues.apache.org/jira/browse/JENA-1820
> Project: Apache Jena
> Issue Type: Bug
> Components: Spatial
>Affects Versions: Jena 3.13.1
>Reporter: Philipp Neuschwander
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> GML-Literal of MultiPolygon/Polygon is malformed (generated by GMLWriter).
> Under the gml:exterior and gml:interior node, there should be a linear ring
> that contains the posList. But the posList is generated as a direct child to
> gml:exterior/interior:
> {code:java}
> http://www.opengis.net/ont/gml;
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>0
> 0 10 0 10 10 0 10 0
> 05 5 7 7 7 5 5
> 54 4 4 5 5 5 4
> 4
> {code}
> The missing linearRing leads to NullPointerException when trying to call
> {code:java}
> geometryWrapper.asLiteral(GMLDatatype.INSTANCE)
> {code}
> as the GMLReader (I have no clue why it is called as part of the
> asLiteral-call) tries to access the linearRing and it's posList child.
> Stackstrace:
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extractPosList(GMLReader.java:223)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildLinearRing(GMLReader.java:503)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildPolygon(GMLReader.java:477)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildMultiSurface(GMLReader.java:644)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildGeometry(GMLReader.java:199)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.(GMLReader.java:108)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extract(GMLReader.java:707)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GMLDatatype.read(GMLDatatype.java:84)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieveMemoryIndex(GeometryLiteralIndex.java:77)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieve(GeometryLiteralIndex.java:51)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:57)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:50)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:32)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelImpl.setValue(LiteralLabelImpl.java:217)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelImpl.setLiteralLabel_1(LiteralLabelImpl.java:111)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelImpl.(LiteralLabelImpl.java:100)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelFactory.create(LiteralLabelFactory.java:50)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.NodeFactory.createLiteral(NodeFactory.java:171)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.rdf.model.ResourceFactory$Impl.createTypedLiteral(ResourceFactory.java:313)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.rdf.model.ResourceFactory.createTypedLiteral(ResourceFactory.java:148)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.GeometryWrapper.asLiteral(GeometryWrapper.java:986)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (JENA-1820) GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype, malformed lexicalForm
[
https://issues.apache.org/jira/browse/JENA-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston reassigned JENA-1820:
---
Assignee: Greg Albiston
> GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype,
> malformed lexicalForm
> -
>
> Key: JENA-1820
> URL: https://issues.apache.org/jira/browse/JENA-1820
> Project: Apache Jena
> Issue Type: Bug
> Components: Spatial
>Affects Versions: Jena 3.13.1
>Reporter: Philipp Neuschwander
>Assignee: Greg Albiston
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> GML-Literal of MultiPolygon/Polygon is malformed (generated by GMLWriter).
> Under the gml:exterior and gml:interior node, there should be a linear ring
> that contains the posList. But the posList is generated as a direct child to
> gml:exterior/interior:
> {code:java}
> http://www.opengis.net/ont/gml;
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>0
> 0 10 0 10 10 0 10 0
> 05 5 7 7 7 5 5
> 54 4 4 5 5 5 4
> 4
> {code}
> The missing linearRing leads to NullPointerException when trying to call
> {code:java}
> geometryWrapper.asLiteral(GMLDatatype.INSTANCE)
> {code}
> as the GMLReader (I have no clue why it is called as part of the
> asLiteral-call) tries to access the linearRing and it's posList child.
> Stackstrace:
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extractPosList(GMLReader.java:223)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildLinearRing(GMLReader.java:503)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildPolygon(GMLReader.java:477)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildMultiSurface(GMLReader.java:644)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildGeometry(GMLReader.java:199)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.(GMLReader.java:108)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extract(GMLReader.java:707)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GMLDatatype.read(GMLDatatype.java:84)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieveMemoryIndex(GeometryLiteralIndex.java:77)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieve(GeometryLiteralIndex.java:51)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:57)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:50)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:32)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelImpl.setValue(LiteralLabelImpl.java:217)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelImpl.setLiteralLabel_1(LiteralLabelImpl.java:111)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelImpl.(LiteralLabelImpl.java:100)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelFactory.create(LiteralLabelFactory.java:50)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.NodeFactory.createLiteral(NodeFactory.java:171)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.rdf.model.ResourceFactory$Impl.createTypedLiteral(ResourceFactory.java:313)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.rdf.model.ResourceFactory.createTypedLiteral(ResourceFactory.java:148)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.GeometryWrapper.asLiteral(GeometryWrapper.java:986)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JENA-1820) GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype, malformed lexicalForm
[
https://issues.apache.org/jira/browse/JENA-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17019764#comment-17019764
]
Greg Albiston commented on JENA-1820:
-
This has now been fixed in 3.15-snapshot. Apologies for any inconvenience.
> GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype,
> malformed lexicalForm
> -
>
> Key: JENA-1820
> URL: https://issues.apache.org/jira/browse/JENA-1820
> Project: Apache Jena
> Issue Type: Bug
> Components: Spatial
>Affects Versions: Jena 3.13.1
>Reporter: Philipp Neuschwander
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> GML-Literal of MultiPolygon/Polygon is malformed (generated by GMLWriter).
> Under the gml:exterior and gml:interior node, there should be a linear ring
> that contains the posList. But the posList is generated as a direct child to
> gml:exterior/interior:
> {code:java}
> http://www.opengis.net/ont/gml;
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>0
> 0 10 0 10 10 0 10 0
> 05 5 7 7 7 5 5
> 54 4 4 5 5 5 4
> 4
> {code}
> The missing linearRing leads to NullPointerException when trying to call
> {code:java}
> geometryWrapper.asLiteral(GMLDatatype.INSTANCE)
> {code}
> as the GMLReader (I have no clue why it is called as part of the
> asLiteral-call) tries to access the linearRing and it's posList child.
> Stackstrace:
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extractPosList(GMLReader.java:223)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildLinearRing(GMLReader.java:503)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildPolygon(GMLReader.java:477)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildMultiSurface(GMLReader.java:644)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildGeometry(GMLReader.java:199)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.(GMLReader.java:108)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extract(GMLReader.java:707)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GMLDatatype.read(GMLDatatype.java:84)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieveMemoryIndex(GeometryLiteralIndex.java:77)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieve(GeometryLiteralIndex.java:51)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:57)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:50)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:32)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelImpl.setValue(LiteralLabelImpl.java:217)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelImpl.setLiteralLabel_1(LiteralLabelImpl.java:111)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelImpl.(LiteralLabelImpl.java:100)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.impl.LiteralLabelFactory.create(LiteralLabelFactory.java:50)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.graph.NodeFactory.createLiteral(NodeFactory.java:171)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.rdf.model.ResourceFactory$Impl.createTypedLiteral(ResourceFactory.java:313)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.rdf.model.ResourceFactory.createTypedLiteral(ResourceFactory.java:148)
> ~[jena-core-3.13.1.jar:3.13.1]
> at
> org.apache.jena.geosparql.implementation.GeometryWrapper.asLiteral(GeometryWrapper.java:986)
> ~[jena-geosparql-3.13.1.jar:3.13.1]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Apache Jena GeoSPARQL mentioned in ISPRS Int. J. Geo-Inf. 2019, 8(7)
Thanks for this Marco. Interesting to see it all in action. Apache Jena GeoSPARQL does quite well. I've ran the benchmarking dataset against Jena 3.13.1 for the one query they said didn't give results. It does give results and in a couple of seconds as reported for the other systems so unsure what has happened there. Cheers, Greg On 04/12/2019 14:00, Marco Neumann wrote: FYI here is a new review / comparison that mentions the new Apache Jena GeoSPARQL effort in this recent publication: Assessment and Benchmarking of Spatially Enabled RDF Stores for the Next Generation of Spatial Data Infrastructure by Weiming Huang,Syed Amir Raza,Oleg Mirzov and Lars Harrie ISPRS Int. J. Geo-Inf. 2019, 8(7), 310; https://doi.org/10.3390/ijgi8070310 Enjoy, Marco -- --- Marco Neumann KONA
[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929969#comment-16929969
]
Greg Albiston commented on JENA-1402:
-
There is `java.time.Period`
([https://docs.oracle.com/javase/8/docs/api/java/time/Period.html)] for
differences in dates, perhaps this could replace the `javax.xml.Duration`?
I found this StackOverflow which goes into detail about replacing Gregorian
Calendar with `java.time`.
[https://stackoverflow.com/questions/835889/java-util-date-to-xmlgregoriancalendar]
> Subtracting two xsd:Duration gives incorrect results in SPARQL query
>
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.4.0
> Reporter: Greg Albiston
>Priority: Major
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e.
> the minutes are reduced.
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S" = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S" = "-PT1M7.000S"
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S" = "PT883M0.020S"
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S"
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M1.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT0M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT1H4M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT0M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JENA-1740) Extending Apache Jena with more geospatial functions
[ https://issues.apache.org/jira/browse/JENA-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918396#comment-16918396 ] Greg Albiston commented on JENA-1740: - Ideally the textual data formats would be treated with a similar approach to the GeometryLiterals. It will depend upon how costly they are to deserialise but should be possible to re-use/re-purpose the current caching for them. > Extending Apache Jena with more geospatial functions > > > Key: JENA-1740 > URL: https://issues.apache.org/jira/browse/JENA-1740 > Project: Apache Jena > Issue Type: Improvement >Reporter: Timo Homburg >Priority: Minor > > Hello, > I am the developer of a project which I named postgis-jena > (https://github.com/i3mainz/postgis-jena), originally aimed at extending > JenaARQ with query functions common in databases such as POSTGIS but now > going beyond that approach and also integrating support for raster data > (still WIP). I am building up work being done by Greg Albistons extension > geosparql-jena. > Is this extension of interest for Apache Jena as a plugin or in another > context? -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (JENA-1740) Extending Apache Jena with more geospatial functions
[ https://issues.apache.org/jira/browse/JENA-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917512#comment-16917512 ] Greg Albiston commented on JENA-1740: - Additional contributions to the GeoSPARQL extension can be provided through a pull request against the Apache Jena repo on GitHub. A concern with storing large pieces of data in triplestores is that triples can be accessed repeatedly during a query, e.g unbound variables. This means that performance can suffer if the triple cannot be quickly processed and analysed. When developing the GeoSPARQL, I found that the GeometryLiterals were being accessed and decoded about 7 times when resolving a query, hence the short-term caching that is applied. It may be more prudent to use a hashing function, or similar, and store that as the literal value in the triplestore. This can then be used to look up from a filestore and return/manipulate the raster if required. This might mean having a function that converts the hash literal into a raster literal for return from a query. It would seem that a seperate module is needed that can then depend upon the GeoSPARQL module. Within that module the two (or more) groups of functions can be loaded as required by the user. > Extending Apache Jena with more geospatial functions > > > Key: JENA-1740 > URL: https://issues.apache.org/jira/browse/JENA-1740 > Project: Apache Jena > Issue Type: Improvement >Reporter: Timo Homburg >Priority: Minor > > Hello, > I am the developer of a project which I named postgis-jena > (https://github.com/i3mainz/postgis-jena), originally aimed at extending > JenaARQ with query functions common in databases such as POSTGIS but now > going beyond that approach and also integrating support for raster data > (still WIP). I am building up work being done by Greg Albistons extension > geosparql-jena. > Is this extension of interest for Apache Jena as a plugin or in another > context? -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (JENA-1740) Extending Apache Jena with more geospatial functions
[ https://issues.apache.org/jira/browse/JENA-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913789#comment-16913789 ] Greg Albiston commented on JENA-1740: - Hi Timo, The work from geosparql-jena is now available as a module in Jena. It should be possible to switch the dependency with only the package names needing updating, i.e. `io.github.galbiston.geosparql_jena` to `org.apache.jena.geosparql`. org.apache.jena jena-geosparql 3.12.0 >From what I recall the PostGIS functions in some cases overlap with the >GeoSPARQL functions, which focuses on spatial relations. This is due to both >in part being derived from the Simple Features standard, but where GeoSPARQL >was designed for open system of SPARQL and PostGIS for closed system of SQL. Something that the PostGIS functions also seem to offer is an extensive range of functions to manipulate geospatial data. The raster data functionality mentioned is not considered in GeoSPARQL. Others might be able to answer better whether raster data is ideally suited for encoding in RDF, storing in a triplestore and querying (doesn't raster data get large very quickly while potentially having a lot of similarity between cases?) or whether some cross-reference lookup to another datastore is needed. Hopefully this a useful and accurate enough generalisation of some differences between GeoSPARQL and PostGIS. Thanks, Greg > Extending Apache Jena with more geospatial functions > > > Key: JENA-1740 > URL: https://issues.apache.org/jira/browse/JENA-1740 > Project: Apache Jena > Issue Type: Improvement >Reporter: Timo Homburg >Priority: Minor > > Hello, > I am the developer of a project which I named postgis-jena > (https://github.com/i3mainz/postgis-jena), originally aimed at extending > JenaARQ with query functions common in databases such as POSTGIS but now > going beyond that approach and also integrating support for raster data > (still WIP). I am building up work being done by Greg Albistons extension > geosparql-jena. > Is this extension of interest for Apache Jena as a plugin or in another > context? -- This message was sent by Atlassian Jira (v8.3.2#803003)
Re: Geosparql documentation
Hi Andy, It looks good. There are a few minor formatting issues I've listed below. Thanks, Greg * Getting Started - Maven dependency collapsed. * SPARQL Query Configuration - Example query formatting. * Querying Dataset & Models with SPARQL - Reference to Apache Jena as third party. * Querying Datasets & Models with SPARQL - Example query formatting. * Key Dependencies - Reference to Apache Jena. * Query Rewrite Extension - Query example duplicated. On 30/05/2019 18:41, Andy Seaborne wrote: Greg, I've put some documentation taken from your README files at: http://jena.staging.apache.org/documentation/geosparql/ (draft staging site) so we have something to link to in the announcement message. Is this satisfactory for the announcement? Andy
Re: GeoSPARQL process
Hi, There are a lot of permutations that a GeoSPARQL query could take which can generate different values that may or may not be useful later on. The general strategy is to keep what is generated for a while and if isn't used then drop it. I don't think any of the Cache implementations offer this or a suitable alternative. The expiring-map removes entries that haven't been reused after a period of time. The duration to retain, rate of checking and maximum size can all be set. It is used for three purposes: - The Geometry Wrapper object resulting from de-serialising the Geometry Literals. - The transformed Geometry Wrapper object from changing the spatial reference system. - The result of a spatial relation between two Geometry Literals to avoid re-testing when Query Re-writing is applied. Most of the GeoSPARQL functions are between two Geometry Literals, so one could be needed in the next iteration of the query and the other could be needed later. The first purpose offers the biggest impact on performance as there are additional de-serialising of the Geometry Literal while Jena is processing the query. Complex shages, e.g. polygons, can be very costly to extract. The second purpose offers most benefit when complex shapes need transforming. These transformations may be needed again during this query but not the next. e.g. dataset is in SRS A. Query 1 is a comparison with a set of values in SRS B. Query 2 then is a comparison with a set of values in SRS C. The results from Query 1 are useless and may never be needed again. The third purpose is due to GeoSPARQL allowing query re-writing where the Geometry Literal isn't specified and instead Features and Geometries are used, so a single query could test the same spatial relations upto four times depending on bindings. The expiring-map is allowed to fill up while the query is processing and then drops entries that aren't reused (in batches) or once the query completes. Once it is full, new entries are quickly rejected but space is freed up later from those entries not being re-used. A user with a small dataset can cache everything while a large dataset can choose to constrain it to get some benefit from caching without consuming vast junks of memory. I tried using the Apache Collections 4 LRUMap and it made performance worse once it was filled (at a guess due to "one out, one in" and constant searching). I only found one Java implementation of a time based cache. It seemed excessive to have the whole dependency for one class and it wasn't as flexible as required. Hopefully this clarifies why the expiring-map approach was adopted. Thanks, Greg On 10/04/2019 16:50, ajs6f wrote: Just out of curiosity, Greg, what is the functionality offered by Expiring Map that isn't offered by Jena's already-extant oaj.atlas.lib.Cache implementations? Is it the ability to manually trigger expirations? ajs6f On Apr 9, 2019, at 12:02 PM, Andy Seaborne wrote: [INFO] | \- io.github.galbiston:expiring-map:jar:1.0.2:compile
Re: GeoSPARQL process
Hi, - rdf-tables: This could be taken out if problematic. It is a CSV/TSV to RDF converter to provide another route to load geospatial data and was useful on another project. Given that jena-csv has been deprecated, there might not be the demand for its inclusion. - jdom2: This is only used for GML reading/writing. Could look into replacing with any XML library already used by Jena. Recently found that Apache SIS offers a GML parser so will investigate whether this can be used (would offer more flexibility and maintenance with the GML versions). Thanks, Greg On 10/04/2019 22:15, Andy Seaborne wrote: On 09/04/2019 17:02, Andy Seaborne wrote: Here are the new dependencies: [INFO] | +- org.apache.sis.core:sis-referencing:jar:0.8:compile [INFO] | | +- javax.measure:unit-api:jar:1.0:compile [INFO] | | \- org.opengis:geoapi:jar:3.0.1:compile via the org.apache.sis org.opengis:geoapi https://github.com/opengeospatial/geoapi A form of BSD license. javax.measure:unit-api https://github.com/unitsofmeasurement/unit-api BSD 3-clause. [INFO] | +- org.locationtech.jts:jts-core:jar:1.16.1:compile Eclipse Distribution License 1.0 EDL 1.0 is cat-A Treat like BSD - NOTICE entry when repackage needed. Link to http://www.eclipse.org/org/documents/edl-v10.php is acceptable. (generally, links instead of a copy are now considered acceptable). [INFO] | +- org.jdom:jdom2:jar:2.0.6:compile Modified BSD - it does not appear to be the problematic, old BSD 4-clause. Seems like 3-clause with clause 3 is split in two. Needs more eyes on it. https://issues.apache.org/jira/browse/LEGAL-204 It is the BSD 2-clause license with two extra clauses about name usage. NOTICE entry when repackage needed. https://github.com/hunterhacker/jdom/blob/master/LICENSE.txt [INFO] | \- io.github.galbiston:expiring-map:jar:1.0.2:compile [INFO] +- io.github.galbiston:rdf-tables:jar:1.0.4:compile AL2 :-) [INFO] | +- com.opencsv:opencsv:jar:3.9:runtime https://sourceforge.net/p/opencsv/source/ci/master/tree/LICENSE AL2 [INFO] +- com.beust:jcommander:jar:1.72:compile https://github.com/cbeust/jcommander AL2 Andy On 08/04/2019 17:29, Andy Seaborne wrote: > Added a POM file for jena-fuseki-geosparql to the same gist: > > https://gist.github.com/afs/c6c291812bbc96fe55ac64ecdd1edfe4 > > Had to do some exclusions on rdf-tables. > > Andy >
Re: Towards Jena 3.11.0
Apologies for the delayed reply about the GeoSPARQL module. There hasn't been much feedback. The main of note was around supporting equivalent functionality to jena-spatial (property/filter functions, lat/lon predicates and spatial index), which are now included along with some other useful property/filter functions. I'll get onto moving them to Maven etc. but likely next weekend. Thanks, Greg On 03/04/2019 22:33, Marco Neumann wrote: ok sounds reasonable, so I might be able to move along with jena spatial On Wed, Apr 3, 2019 at 10:28 PM Andy Seaborne wrote: I'm only suggesting removing it from Fuseki, not remove the module. Fuseki merely includes it. Putting it back does not even need repacking: java -cp fuseki-jar:spatial.jar $@ should work - JenaSystem.init will happen and ServiceLoader cause spatial to be available as before. Andy On 03/04/2019 22:11, Marco Neumann wrote: ok Andy, I will prepare for the removal of jena spatial from the jena project. but since I use jena spatial in production it will take a while to switch and I will stay with 3.10 here. what exactly will you do with the code base? just remove the code from the fuseki release and the jena spatial folder in the source? On Wed, Apr 3, 2019 at 9:17 PM Andy Seaborne wrote: We have three major streams outstanding. Have I missed anything? 1/ GeoSPARQL 2/ Prometheus metrics 3/ SurroundQueryParser == GeoSPARQL Greg - apologies for being tardy on this one. It looks in good shape. Did you hear from anyone after the request for feedback? This is two modules: geosparql-jena and geosparql-fuseki A suggestion for how to proceed if you have the time for 3.11.0 is that we include these basically as-is and remove jena-spatial from Fuseki which we have been signalling for a while. Suggestion: jena-geosparql jena-fuseki/jena-fuseki-geospatial and under org.apache.jena.geosparql and org.apache.jena.fuseki.geosparql It would have to be maven. Documentation: This does not have to timed with the release though desirable to have some instructions on the website. Looking the modules, it has its own specialised Fuseki incarnation with command line arguments and also internally a system wide configuration. maybe, later, we might want to merge the Fuseki setup but exactly how and whether separate is better for users due to the specialised nature can wait. Release should get feedback after it is incorporated - "release early, release often". Greg - how does that sound? PMC - having more eyes on this would be helpful. If the timing is OK, we can work on details on the ticket JENA-664 (or email on dev@). == JENA-1691 : Prometheus metrics This is getting there. We have the code worked out, the packaging needs a bit of discussion; importantly it is missing L changes due to BSD-binaries in the combined jars mean some L changes. == JENA-1690 : SurroundQueryParser Looks like this is ready and waiting for someone to merge it. With all that, it looks like some things to sort out. We can wait a bit longer for 3.11.0, or do 3.11.0 fairly soon with whatever is ready, including getting things in and expect to further refine, then advance the timing on 3.12.0. Thoughts? Andy
GeoSPARQL Module
Hello, Just to update on the work for the GeoSPARQL module. I've setup the previous property and filter functions from the jena-spatial module. These can be used with both Lat/Lon geo predicates and the geometry literals of GeoSPARQL. There are also some additional filter functions added for convenience, e.g. convert lat/lon values to geometry literals and calculating distances. A spatial index is used for these functions on a per dataset basis. If the spatial index is available then the GeoSPARQL property functions will use it. The GeoSPARQL property functions will also do a fall back test for geo predicates if no geometry literals are found so there is some accomodation for those wanting to stay with geo predicates, but only a few spatial relations are valid for point-point relations. Methods for converting datasets to GeoSPARQL structure are also included. I've also tried to incorporate Bruno's previous feedback with more consistent ExprEvalExceptions within the functions. I will send out a message on the users mailing list to invite people to test the GitHub project as there was some interest in assisting. What is the process for creating the new module within Jena? Thanks, Greg
[jira] [Closed] (JENA-1661) FunctionBase5: 5 argument abstract class for filter functions.
[ https://issues.apache.org/jira/browse/JENA-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Albiston closed JENA-1661. --- Resolution: Fixed Sorry. Didn't realise this had already been merged. > FunctionBase5: 5 argument abstract class for filter functions. > -- > > Key: JENA-1661 > URL: https://issues.apache.org/jira/browse/JENA-1661 > Project: Apache Jena > Issue Type: Improvement > Reporter: Greg Albiston >Priority: Trivial > > Extended FunctionBase4 for 5 argument case. > Currently, one to four arguments are supported. > A use case is the spatial GeoSPARQL module measuring distance between two > Lat/Lon pairs and a units URI label (i.e. 2 + 2 + 1 arguments). > Pull request created on GitHub for this minor addition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JENA-1661) FunctionBase5: 5 argument abstract class for filter functions.
Greg Albiston created JENA-1661: --- Summary: FunctionBase5: 5 argument abstract class for filter functions. Key: JENA-1661 URL: https://issues.apache.org/jira/browse/JENA-1661 Project: Apache Jena Issue Type: Improvement Reporter: Greg Albiston Extended FunctionBase4 for 5 argument case. Currently, one to four arguments are supported. A use case is the spatial GeoSPARQL module measuring distance between two Lat/Lon pairs and a units URI label (i.e. 2 + 2 + 1 arguments). Pull request created on GitHub for this minor addition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740821#comment-16740821
]
Greg Albiston commented on JENA-1402:
-
I've had a quick look at _NodeValueDuration_ and where it is used in the ARQ
module.
In _XSDFuncOp,_ there are checks to get and set fields (i.e. year, month) which
aren't explicit on the _java.time.Duration_ as it only goes up to days.
Converting days to months and years consistently could be problematic without a
start date for context.
In _CastXSD,_ there are checks against the _xml.Duration_ fields for building
new durations of type _xdt:dayTimeDuration_ or _xdt:yearMonthDuration_ (these
aren't explicit in _java.time.Duration_). Same issue as above in distinguishing
when x days becomes y months.
In _NodeValueOps,_ there are operations using _XMLGregorianCalendar_ for which
_java.time.Duration_ doesn't have methods. _java.time.__LocalTime_ and
_java.time.__OffsetTime_ can be built from parsing the
_XMLGregorianCalendar.toString()_ but need to be selected based on whether
there is a TimeZone offset. _LocalTime/__OffsetTime_ could then be used to
operate on the _java.time.Duration._
So it could be quite difficult to swap to _java.time.Duration_ and retain the
XML Datatype functionality. Perhaps the extra classes or approach Bruno
mentioned might help.
> Subtracting two xsd:Duration gives incorrect results in SPARQL query
>
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.4.0
> Reporter: Greg Albiston
>Priority: Major
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e.
> the minutes are reduced.
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S" = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S" = "-PT1M7.000S"
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S" = "PT883M0.020S"
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S"
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M1.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT0M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT1H4M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT0M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16737062#comment-16737062
]
Greg Albiston commented on JENA-1402:
-
Just to update that the underlying issue in javax.xml is reported as fixed in
JDK12 (JDK-8190835).
[https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190835]
> Subtracting two xsd:Duration gives incorrect results in SPARQL query
>
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.4.0
> Reporter: Greg Albiston
>Priority: Major
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e.
> the minutes are reduced.
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S" = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S" = "-PT1M7.000S"
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S" = "PT883M0.020S"
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S"
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M1.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT0M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT1H4M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT0M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Toward Jena 3.10.0
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 (<http://www.opengis.net/ont/geosparql#>). 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
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 (<http://www.opengis.net/ont/geosparql#>). 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
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 (b
Re: Toward Jena 3.10.0
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.
Re: Toward Jena 3.10.0
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: <http://www.opengis.net/ont/geosparql#>
PREFIX geof: <http://www.opengis.net/def/function/geosparql/>
SELECT ?well
WHERE {
?well <http://www.wikidata.org/entity/P625> ?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 t
Re: Toward Jena 3.10.0
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
[jira] [Commented] (JENA-1644) ParameterizedSparqlString Empty List fix
[ https://issues.apache.org/jira/browse/JENA-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16704632#comment-16704632 ] Greg Albiston commented on JENA-1644: - Pullrequest to fix this issue submitted on GitHub. > ParameterizedSparqlString Empty List fix > > > Key: JENA-1644 > URL: https://issues.apache.org/jira/browse/JENA-1644 > Project: Apache Jena > Issue Type: Bug >Affects Versions: Jena 3.9.0 >Reporter: Greg Albiston >Priority: Minor > > ParameterizedSparqlString throws a StringIndexOutOfBoundsException when empty > list of values is provided. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JENA-1644) ParameterizedSparqlString Empty List fix
[ https://issues.apache.org/jira/browse/JENA-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Albiston updated JENA-1644: Description: ParameterizedSparqlString throws a StringIndexOutOfBoundsException when empty list of values is provided. (was: ParameterizedSparqlString now accepts an empty list of values rather than throwing a StringIndexOutOfBoundsException.) > ParameterizedSparqlString Empty List fix > > > Key: JENA-1644 > URL: https://issues.apache.org/jira/browse/JENA-1644 > Project: Apache Jena > Issue Type: Bug >Affects Versions: Jena 3.9.0 >Reporter: Greg Albiston >Priority: Minor > > ParameterizedSparqlString throws a StringIndexOutOfBoundsException when empty > list of values is provided. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JENA-1644) ParameterizedSparqlString Empty List fix
Greg Albiston created JENA-1644: --- Summary: ParameterizedSparqlString Empty List fix Key: JENA-1644 URL: https://issues.apache.org/jira/browse/JENA-1644 Project: Apache Jena Issue Type: Bug Affects Versions: Jena 3.9.0 Reporter: Greg Albiston ParameterizedSparqlString now accepts an empty list of values rather than throwing a StringIndexOutOfBoundsException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
CMS diff: Jena-related projects and tools
Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/about_jena%2Fcontributions.mdtext Greg Albiston Index: trunk/content/about_jena/contributions.mdtext === --- trunk/content/about_jena/contributions.mdtext (revision 1844793) +++ trunk/content/about_jena/contributions.mdtext (working copy) @@ -31,4 +31,6 @@ Persistence Annotations 4 RDF | Persistence Annotation for RDF (PAR) is a set of annotations and an entity manager that provides JPA like functionality on top of an RDF store while accounting for and exploiting the fundamental differences between graph storage and relational storage. PAR introduces three (3) annotations that map a RDF triple (subject, predicate, object) to a Plain Old Java Object (POJO) using Java's dynamic proxy capabilities. | Apache 2.0 | Claude Warren | [PA4RDF at Sourceforge](https://sourceforge.net/projects/pa4rdf/) JenaSecurity | Security (Permissions) wrapper around Jena RDF implementation. | Apache 2.0 | Claude Warren | [JenaSecurity at GitHub](https://github.com/Claudenw/JenaSecurity) Semantic_Forms | Swiss army knife for data management and social networking. | open source | Jean-Marc Vanel | [Semantic_Forms](https://github.com/jmvanel/semantic_forms) -JDBC 4 SPARQL | JDBC 4 SPARQL is a type 4 JDBC Driver that uses a SPARQL endpoint (or Jena Model) as the data store. Presents graph data as relational data to tools that understand SQL and utilize JDBC| Apache 2.0 (Some components GNU LGPL V3.0) | Claude Warren | [jdbc4sparql at GitHub](https://github.com/Claudenw/jdbc4sparql) \ No newline at end of file +JDBC 4 SPARQL | JDBC 4 SPARQL is a type 4 JDBC Driver that uses a SPARQL endpoint (or Jena Model) as the data store. Presents graph data as relational data to tools that understand SQL and utilize JDBC| Apache 2.0 (Some components GNU LGPL V3.0) | Claude Warren | [jdbc4sparql at GitHub](https://github.com/Claudenw/jdbc4sparql) +GeoSPARQL Jena | Implementation of GeoSPARQL 1.0 standard using Apache Jena for SPARQL query or API. | Apache 2.0 | Greg Albiston and Haozhe Chen | [geosparql-jena at GitHub](https://github.com/galbiston/geosparql-jena) +GeoSPARQL Fuseki | HTTP server application compliant with the GeoSPARQL standard using GeoSPARQL Jena library and Apache Jena Fuseki server | Apache 2.0 | Greg Albiston | [geosparql-fuseki at GitHub](https://github.com/galbiston/geosparql-fuskei) \ No newline at end of file
GeoSPARQL modules Was: Spatial distance in Fuseki
Hello, Previously I made contact about an implementation of the GeoSPARQL standard for Jena. There was a suggestion to make this a standalone project and look into switching across to Apache SIS to ease licencing. These have both been done. The project is now published on GitHub at https://github.com/galbiston/geosparql-jena and has been released to Maven Central today. There is also a project which uses Fuseki's embedded server with the GeoSPARQL features at https://github.com/galbiston/geosparql-fuseki. I've tried to use the Shadow Plugin for Gradle to produce a user-jar based on https://jena.apache.org/documentation/notes/jena-repack.html but haven't been successful. If anyone can provide any advice or guidance on this then I'd appreciate it. Also, being able to utilise the Fuseki GUI with the embedded server, since the application is providing data loading and function setup features, would also be useful to get guidance about. If you have any feedback then please let me know. Thanks, Greg
[jira] [Created] (JENA-1578) SPARQL VALUES for ParameterizedSparqlString
Greg Albiston created JENA-1578: --- Summary: SPARQL VALUES for ParameterizedSparqlString Key: JENA-1578 URL: https://issues.apache.org/jira/browse/JENA-1578 Project: Apache Jena Issue Type: New Feature Components: ARQ Affects Versions: Jena 3.8.0 Reporter: Greg Albiston ParameterizedSparqlString provides an API for substituting variables within SPARQL queries with bound values. It does not support the SPARQL VALUES keyword which allows multiple values to be specified. The VALUES syntax supports multiple values for a single variable, sets of values for multiple variables and multiple sets of values for multiple values. Inquiry on 24/07/18 the mailing list about this feature. Patch is forthcoming. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
RE: CMS diff: TDB Datasets
Hi Andy,
Thanks for the response. Your suggestion worked and the query completed in a
similar time to the union graph approach.
I'd tried moving the filter into the graph clause but not swapping the graph
order.
I added that update on the documentation so if anyone else was having similar
problems it might help.
Do you still want me to create a JIRA for it?
More generally, is there a page/section for tips on query writing to help
optimisation?
I searched but could only find description of TDB's optimisation functionality
and extending query execution. I spent quite a while hunting for tips and
trying different ways to influence the resolution order until I thought I'd try
the union graph.
Thanks,
Greg
-Original Message-
From: Andy Seaborne
Sent: 19 June 2018 13:56
To: dev@jena.apache.org; Greg Albiston
Subject: Re: CMS diff: TDB Datasets
Greg,
Could you create a JIRA ticket for this please? It is something that looks
addressable. The solution proposed (using union graph) is a bit specialised.
Andy
The query may be better if written (but the "..." may be making a
difference.)
GRAPH dataset:SmallB {
?b rdf:type my:BThing.
?b my:hasData ?bData.
FILTER(my:filterFunction2(?bData, "1.0 3.0, 4.0 2.0"^^my:dataLiteral)) }
GRAPH dataset:BigA {
?a rdf:type my:AThing.
?a noa:hasGeometry ?aData.
}
FILTER(my:filterFunction1(?bData, ?aData))
On 19/06/18 10:59, Greg Albiston wrote:
> Clone URL (Committers only):
> https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://j
> ena.apache.org/documentation%2Ftdb%2Fdatasets.mdtext
>
> Greg Albiston
>
> Index: trunk/content/documentation/tdb/datasets.mdtext
> ===
> --- trunk/content/documentation/tdb/datasets.mdtext (revision 1833775)
> +++ trunk/content/documentation/tdb/datasets.mdtext (working copy)
> @@ -51,6 +51,51 @@
> ...
> }
>
> +### Named Graphs & Filters
> +
> +Named graphs provide a convenient way to organise and store your data.
> +However, be aware that in certain situations named graphs can make it
> difficult for the query optimiser.
> +
> +For example, a query with the following structure took 29 minutes to
> complete:
> +
> +SELECT ?b ...
> +WHERE {
> +
> +GRAPH dataset:BigA {
> +?a rdf:type my:AThing.
> +?a noa:hasGeometry ?aData.
> +...
> +}
> +
> +GRAPH dataset:SmallB {
> +?b rdf:type my:BThing.
> +?b my:hasData ?bData.
> +...
> +}
> +
> +FILTER(my:filterFunction1(?bData, ?aData))
> +FILTER(my:filterFunction2(?bData, "1.0 3.0, 4.0
> + 2.0"^^my:dataLiteral) )
> +
> +}
> +
> +The completion duration was reduced to 7 seconds by applying the global
> TDB.symUnionDefaultGraph option (see above) to the dataset and modifying the
> query as follows:
> +
> +SELECT ?b ...
> +WHERE {
> +
> +?a rdf:type my:AThing.
> +?a noa:hasGeometry ?aData.
> +...
> +
> +?b rdf:type my:BThing.
> +?b my:hasData ?bData.
> +...
> +
> +FILTER(my:filterFunction1(?bData, ?aData))
> +FILTER(my:filterFunction2(?bData, "1.0 3.0, 4.0
> + 2.0"^^my:dataLiteral) )
> +
> +}
> +
> ## Special Graph Names
>
> URI | Meaning
>
CMS diff: TDB Datasets
Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Ftdb%2Fdatasets.mdtext
Greg Albiston
Index: trunk/content/documentation/tdb/datasets.mdtext
===
--- trunk/content/documentation/tdb/datasets.mdtext (revision 1833775)
+++ trunk/content/documentation/tdb/datasets.mdtext (working copy)
@@ -51,6 +51,51 @@
...
}
+### Named Graphs & Filters
+
+Named graphs provide a convenient way to organise and store your data.
+However, be aware that in certain situations named graphs can make it
difficult for the query optimiser.
+
+For example, a query with the following structure took 29 minutes to complete:
+
+SELECT ?b ...
+WHERE {
+
+GRAPH dataset:BigA {
+?a rdf:type my:AThing.
+?a noa:hasGeometry ?aData.
+...
+}
+
+GRAPH dataset:SmallB {
+?b rdf:type my:BThing.
+?b my:hasData ?bData.
+...
+}
+
+FILTER(my:filterFunction1(?bData, ?aData))
+FILTER(my:filterFunction2(?bData, "1.0 3.0, 4.0 2.0"^^my:dataLiteral) )
+
+}
+
+The completion duration was reduced to 7 seconds by applying the global
TDB.symUnionDefaultGraph option (see above) to the dataset and modifying the
query as follows:
+
+SELECT ?b ...
+WHERE {
+
+?a rdf:type my:AThing.
+?a noa:hasGeometry ?aData.
+...
+
+?b rdf:type my:BThing.
+?b my:hasData ?bData.
+...
+
+FILTER(my:filterFunction1(?bData, ?aData))
+FILTER(my:filterFunction2(?bData, "1.0 3.0, 4.0 2.0"^^my:dataLiteral) )
+
+}
+
## Special Graph Names
URI | Meaning
[jira] [Commented] (JENA-1521) TDB2 backed Datasets cannot be re-opened.
[
https://issues.apache.org/jira/browse/JENA-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437775#comment-16437775
]
Greg Albiston commented on JENA-1521:
-
Hi Andy,
I understand what your saying about not using it again and the create/destroy
pattern. However, should there not be some way to reverse a closure without an
application restarting? There is no obvious method on the Dataset. What if a
dataset is passed into a third party library which closes it?
Also, how are resources associated with opening the dataset released? For
example, open the dataset, do some work, go away for a long time, come back and
reopen. There might only be a small overhead but a developer may wish to they
are being well behaved and ensuring an in-memory caching is flushed.
>From what you've mentioned the semantics of Datasets are close and can NEVER
>be accessed again but QueryIterators are MUST close after use to avoid wasting
>resources.
It just seems strange,
Greg
> TDB2 backed Datasets cannot be re-opened.
> -
>
> Key: JENA-1521
> URL: https://issues.apache.org/jira/browse/JENA-1521
> Project: Apache Jena
> Issue Type: Bug
> Environment: Apache Jena: 3.7.0
> Java: 1.8_162
>Reporter: Greg Albiston
>Priority: Major
>
> If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed
> and then later re-opened it is reported that the Dataset is closed.
> Opening, closing and re-opening a Dataset with TDBFactory.createDataset()
> causes no issues.
> Example code to reproduce:
> {noformat}
> public void testTDB2OpenClose() {
> System.out.println("TDB2 Open Close");
> try {
> Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
> dataset.begin(ReadWrite.WRITE);
> Model defaultModel = dataset.getDefaultModel();
>
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
> ResourceFactory.createProperty("http://example.org/my#PropA;),
> ResourceFactory.createResource("http://example.org/my#ObjA;));
> dataset.commit();
> dataset.end();
> dataset.close();
> Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
> dataset2.begin(ReadWrite.READ);
> Model readModel = dataset2.getDefaultModel();
> Iterator statements = readModel.listStatements();
> while (statements.hasNext())
> { Statement statement = statements.next(); System.out.println(statement); }
> dataset2.end();
> dataset2.close();
> } catch (Exception ex) \{ System.out.println("Exception: " +
> ex.getMessage()); }
> }
> {noformat}
> {noformat}
> public void testTDB1OpenClose() {
>
> System.out.println("TDB1 Open Close");
> try {
> Dataset dataset = TDBFactory.createDataset("test_tdb1");
> dataset.begin(ReadWrite.WRITE);
> Model defaultModel = dataset.getDefaultModel();
>
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
> ResourceFactory.createProperty("http://example.org/my#PropA;),
> ResourceFactory.createResource("http://example.org/my#ObjA;));
> dataset.commit();
> dataset.end();
> dataset.close();
>
> Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
> dataset2.begin(ReadWrite.READ);
> Model readModel = dataset2.getDefaultModel();
> Iterator statements = readModel.listStatements();
> while (statements.hasNext()) \{ Statement statement = statements.next();
> System.out.println(statement); }
> dataset2.end();
> dataset2.close();
> } catch (Exception ex)
> { System.out.println("Exception: " + ex.getMessage()); }
> }
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JENA-1521) TDB2 backed Datasets cannot be re-opened.
[
https://issues.apache.org/jira/browse/JENA-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston updated JENA-1521:
Environment:
Apache Jena: 3.7.0
Java: 1.8_162
> TDB2 backed Datasets cannot be re-opened.
> -
>
> Key: JENA-1521
> URL: https://issues.apache.org/jira/browse/JENA-1521
> Project: Apache Jena
> Issue Type: Bug
> Environment: Apache Jena: 3.7.0
> Java: 1.8_162
> Reporter: Greg Albiston
>Priority: Major
>
> If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed
> and then later re-opened it is reported that the Dataset is closed.
> Opening, closing and re-opening a Dataset with TDBFactory.createDataset()
> causes no issues.
> Example code to reproduce:
> public void testTDB2OpenClose() {
> System.out.println("TDB2 Open Close");
> try {
> Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
> dataset.begin(ReadWrite.WRITE);
> Model defaultModel = dataset.getDefaultModel();
>
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
> ResourceFactory.createProperty("http://example.org/my#PropA;),
> ResourceFactory.createResource("http://example.org/my#ObjA;));
> dataset.commit();
> dataset.end();
> dataset.close();
> Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
> dataset2.begin(ReadWrite.READ);
> Model readModel = dataset2.getDefaultModel();
> Iterator statements = readModel.listStatements();
> while (statements.hasNext()) {
> Statement statement = statements.next();
> System.out.println(statement);
> }
> dataset2.end();
> dataset2.close();
> } catch (Exception ex) {
> System.out.println("Exception: " + ex.getMessage());
> }
> }
> public void testTDB1OpenClose() {
> System.out.println("TDB1 Open Close");
> try {
> Dataset dataset = TDBFactory.createDataset("test_tdb1");
> dataset.begin(ReadWrite.WRITE);
> Model defaultModel = dataset.getDefaultModel();
>
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
> ResourceFactory.createProperty("http://example.org/my#PropA;),
> ResourceFactory.createResource("http://example.org/my#ObjA;));
> dataset.commit();
> dataset.end();
> dataset.close();
> Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
> dataset2.begin(ReadWrite.READ);
> Model readModel = dataset2.getDefaultModel();
> Iterator statements = readModel.listStatements();
> while (statements.hasNext()) {
> Statement statement = statements.next();
> System.out.println(statement);
> }
> dataset2.end();
> dataset2.close();
> } catch (Exception ex) {
> System.out.println("Exception: " + ex.getMessage());
> }
> }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JENA-1521) TDB2 backed Datasets cannot be re-opened.
Greg Albiston created JENA-1521:
---
Summary: TDB2 backed Datasets cannot be re-opened.
Key: JENA-1521
URL: https://issues.apache.org/jira/browse/JENA-1521
Project: Apache Jena
Issue Type: Bug
Reporter: Greg Albiston
If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed
and then later re-opened it is reported that the Dataset is closed.
Opening, closing and re-opening a Dataset with TDBFactory.createDataset()
causes no issues.
Example code to reproduce:
public void testTDB2OpenClose() {
System.out.println("TDB2 Open Close");
try {
Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
dataset.begin(ReadWrite.WRITE);
Model defaultModel = dataset.getDefaultModel();
defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
ResourceFactory.createProperty("http://example.org/my#PropA;),
ResourceFactory.createResource("http://example.org/my#ObjA;));
dataset.commit();
dataset.end();
dataset.close();
Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
dataset2.begin(ReadWrite.READ);
Model readModel = dataset2.getDefaultModel();
Iterator statements = readModel.listStatements();
while (statements.hasNext()) {
Statement statement = statements.next();
System.out.println(statement);
}
dataset2.end();
dataset2.close();
} catch (Exception ex) {
System.out.println("Exception: " + ex.getMessage());
}
}
public void testTDB1OpenClose() {
System.out.println("TDB1 Open Close");
try {
Dataset dataset = TDBFactory.createDataset("test_tdb1");
dataset.begin(ReadWrite.WRITE);
Model defaultModel = dataset.getDefaultModel();
defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
ResourceFactory.createProperty("http://example.org/my#PropA;),
ResourceFactory.createResource("http://example.org/my#ObjA;));
dataset.commit();
dataset.end();
dataset.close();
Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
dataset2.begin(ReadWrite.READ);
Model readModel = dataset2.getDefaultModel();
Iterator statements = readModel.listStatements();
while (statements.hasNext()) {
Statement statement = statements.next();
System.out.println(statement);
}
dataset2.end();
dataset2.close();
} catch (Exception ex) {
System.out.println("Exception: " + ex.getMessage());
}
}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16242215#comment-16242215
]
Greg Albiston edited comment on JENA-1402 at 11/7/17 3:51 PM:
--
The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_,
_xsd:time_ and _xsd:dateTime_.
I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and
parsed into Jena XSD Typed Literals. I haven't found any problems with
_java.time.Duration_.
The only issue I've found with _java.time.LocalTime_ is that
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"),
when Jena expects them to be preserved. I don't know which is the correct
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1
Part 2:
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]).
It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce
the format.
{code:java}
public static final DateTimeFormatter TIME_FORMATTER =
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");
public static final Literal createLocalTime(LocalTime localTime) {
return
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER),
XSDBaseNumericType.XSDtime);
}
{code}
Usage of the _java.time.Duration_ would suggest replacing
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An
issue here is that _ java.time_ distinguishes between dateTime and time with
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid
_xsd:time_ literals that throw exceptions if parsed through the wrong
_java.time_ object.
Thanks,
Greg
was (Author: gregalbiston):
The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_,
_xsd:time_ and _xsd:dateTime_.
I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and
parsed into Jena XSD Typed Literals. I haven't found any problems with
_java.time.Duration_.
The only issue I've found with _java.time.LocalTime_ is that
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"),
when Jena expects them to be preserved. I don't know which is the correct
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1
Part 2:
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]).
It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce
the format.
{code:java}
public static final DateTimeFormatter TIME_FORMATTER =
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");
public static final Literal createLocalTime(LocalTime localTime) {
return
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER),
XSDBaseNumericType.XSDtime);
}
{code}
Usage of the _java.time.Duration_ would suggest replacing
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An
issue here is that_ java.time_ distinguishes between dateTime and time with
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid
_xsd:time_ literals that throw exceptions if parsed through the wrong
_java.time_ object.
Thanks,
Greg
> Subtracting two xsd:Duration gives incorrect results in SPARQL query
>
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e.
> the minutes are reduced.
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S" = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S" = "-PT1M7.000S"
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S" = "PT
[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16242215#comment-16242215
]
Greg Albiston edited comment on JENA-1402 at 11/7/17 3:51 PM:
--
The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_,
_xsd:time_ and _xsd:dateTime_.
I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and
parsed into Jena XSD Typed Literals. I haven't found any problems with
_java.time.Duration_.
The only issue I've found with _java.time.LocalTime_ is that
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"),
when Jena expects them to be preserved. I don't know which is the correct
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1
Part 2:
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]).
It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce
the format.
{code:java}
public static final DateTimeFormatter TIME_FORMATTER =
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");
public static final Literal createLocalTime(LocalTime localTime) {
return
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER),
XSDBaseNumericType.XSDtime);
}
{code}
Usage of the _java.time.Duration_ would suggest replacing
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An
issue here is that _java.time_ distinguishes between dateTime and time with
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid
_xsd:time_ literals that throw exceptions if parsed through the wrong
_java.time_ object.
Thanks,
Greg
was (Author: gregalbiston):
The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_,
_xsd:time_ and _xsd:dateTime_.
I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and
parsed into Jena XSD Typed Literals. I haven't found any problems with
_java.time.Duration_.
The only issue I've found with _java.time.LocalTime_ is that
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"),
when Jena expects them to be preserved. I don't know which is the correct
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1
Part 2:
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]).
It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce
the format.
{code:java}
public static final DateTimeFormatter TIME_FORMATTER =
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");
public static final Literal createLocalTime(LocalTime localTime) {
return
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER),
XSDBaseNumericType.XSDtime);
}
{code}
Usage of the _java.time.Duration_ would suggest replacing
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An
issue here is that _ java.time_ distinguishes between dateTime and time with
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid
_xsd:time_ literals that throw exceptions if parsed through the wrong
_java.time_ object.
Thanks,
Greg
> Subtracting two xsd:Duration gives incorrect results in SPARQL query
>
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e.
> the minutes are reduced.
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S" = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S" = "-PT1M7.000S"
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S" = "PT
[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16242215#comment-16242215
]
Greg Albiston edited comment on JENA-1402 at 11/7/17 3:49 PM:
--
The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_,
_xsd:time_ and _xsd:dateTime_.
I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and
parsed into Jena XSD Typed Literals. I haven't found any problems with
_java.time.Duration_.
The only issue I've found with _java.time.LocalTime_ is that
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"),
when Jena expects them to be preserved. I don't know which is the correct
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1
Part 2:
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]).
It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce
the format.
{code:java}
public static final DateTimeFormatter TIME_FORMATTER =
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");
public static final Literal createLocalTime(LocalTime localTime) {
return
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER),
XSDBaseNumericType.XSDtime);
}
{code}
Usage of the _java.time.Duration_ would suggest replacing
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An
issue here is that_ java.time_ distinguishes between dateTime and time with
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid
_xsd:time_ literals that throw exceptions if parsed through the wrong
_java.time_ object.
Thanks,
Greg
was (Author: gregalbiston):
The {noformat}java.time{noformat} API is supposed to be ISO-8601 compliant as
are {noformat}xsd:duration{noformat}, {noformat}xsd:time{noformat} and
{noformat}xsd:dateTime{noformat}.
I've used {noformat}java.time.Duration{noformat} and
{noformat}java.time.LocalTime{noformat} in a project and parsed into Jena XSD
Typed Literals. I haven't found any problems with
{noformat}java.time.Duration{noformat}.
The only issue I've found with {noformat}java.time.LocalTime{noformat} is that
{noformat}LocalTime.toString(){noformat} drops zero seconds (i.e. "09:00:00"
becomes "09:00"), when Jena expects them to be preserved. I don't know which is
the correct behaviour for ISO-8601 but the latter seems to be a
{noformat}xsd:time{noformat} requirement (based on 3rd bullet point in
[https://www.w3.org/TR/xmlschema11-2/#partial-implementation]).
It can be worked around with a
{noformat}java.time.format.DateTimeFormatter{noformat} to enforce the format.
{code:java}
public static final DateTimeFormatter TIME_FORMATTER =
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");
public static final Literal createLocalTime(LocalTime localTime) {
return
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER),
XSDBaseNumericType.XSDtime);
}
{code}
Usage of the {noformat}java.time.Duration{noformat} would suggest replacing
{noformat}javax.xml.datatype.XMLGregorianCalendar{noformat} and
{noformat}java.util.Calendar{noformat} in Jena. An issue here is that
{noformat}java.time{noformat} distinguishes between dateTime and time with
timezone ({noformat}java.time.OffsetDateTime{noformat} and
{noformat}java.time.OffsetTime{noformat}) from those without timezones
({noformat}java.time.LocalDateTime{noformat} and
{noformat}java.time.LocalTime{noformat}). XSD does not distinguish and so
"09:00:00" and "09:00:00+00:00" are both valid {noformat}xsd:time{noformat}
literals that throw exceptions if parsed through the wrong
{noformat}java.time{noformat} object.
Thanks,
Greg
> Subtracting two xsd:Duration gives incorrect results in SPARQL query
>
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e.
> the minutes are reduced.
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S" = "PT0M53S" COR
[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16241720#comment-16241720
]
Greg Albiston commented on JENA-1402:
-
The bug in javax.xml.datatype.Duration has been reported to Oracle as Bug ID:
JDK-8190835 [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8190835].
It has been assigned a priority of P4, so is apparently an optional fix for the
next release.
Thanks,
Greg
> Subtracting two xsd:Duration gives incorrect results in SPARQL query
>
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.4.0
> Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e.
> the minutes are reduced.
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S" = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S" = "-PT1M7.000S"
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S" = "PT883M0.020S"
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S"
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M1.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT0M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT1H4M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT0M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211520#comment-16211520
]
Greg Albiston commented on JENA-1402:
-
Hi Andy,
It does look like a bug in javax.xml.datatype.Duration.
Can Jena be switched over to the new JDK8 Time API?
This gives correct results for the two incorrect examples given previously.
The new Java Time should overcome issues in the old API and is compliant with
ISO-8601 used by the XSD dateTime, time and duration datatypes.
[http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html#close]
Thanks,
Greg
{code:java}
import java.time.Duration;
import javax.xml.datatype.DatatypeConfigurationException;
import javax.xml.datatype.DatatypeFactory;
public class ExampleApp {
public static void main(String[] args) {
//Jena result: PT883M0.020S
//Java result: PT53S
Duration dur1 = Duration.parse("PT2M3.123S");
Duration dur2 = Duration.parse("PT1M10.123S");
Duration result = dur1.minus(dur2);
System.out.println(dur1 + " - " + dur2 + " = " + result);
//Jena result: PT1H3883M0.020S
//Java result: PT1H3M53S
dur1 = Duration.parse("PT1H4M3.123S");
dur2 = Duration.parse("PT0M10.123S");
result = dur1.minus(dur2); //gives "PT53S" - correct
System.out.println(dur1 + " - " + dur2 + " = " + result);
//Jena result: PT883M0.020S
//Java result: PT883M0.020S
DatatypeFactory factory = DatatypeFactory.newInstance();
javax.xml.datatype.Duration dt1 = factory.newDuration("PT2M3.123S");
javax.xml.datatype.Duration dt2 = factory.newDuration("PT1M10.123S");
javax.xml.datatype.Duration res1 = dt1.subtract(dt2);
System.out.println(dt1 + " - " + dt2 + " = " + res1);
}
}
{code}
> Subtracting two xsd:Duration gives incorrect results in SPARQL query
>
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e.
> the minutes are reduced.
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S" = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S" = "-PT1M7.000S"
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S" = "PT883M0.020S"
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S"
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M1.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT0M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> ("PT1H4M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
> "PT0M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
CMS diff: ARQ - Writing Property Functions
Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fquery%2Fwriting_propfuncs.mdtext
Greg Albiston
Index: trunk/content/documentation/query/writing_propfuncs.mdtext
===
--- trunk/content/documentation/query/writing_propfuncs.mdtext (revision
1812597)
+++ trunk/content/documentation/query/writing_propfuncs.mdtext (working copy)
@@ -142,4 +142,28 @@
Note that it can make a lot of sense to generate the `Iterator` for
`QueryIterPlainWrapper` by means of
Jena's `ExtendedIterator`. This can allow domain-specific value to be easily
mapped to `Binding` objects in
- a lazy fashion.
\ No newline at end of file
+ a lazy fashion.
+
+**Graph Operations**
+
+Additional operations on the current, or another, Graph can be achieved
through the Execution Context.
+Once retrieved the Graph can be operated upon directly, queried or wrapped in
a Model, if preferred.
+New Triples or Graphs can therefore be created as part of the Property
Function.
+
+ //Retrieve current Graph.
+ Graph graph = execCxt.getActiveGraph();
+
+ //Wrap Graph in a Model.
+ Model model = ModelFactory.createModelForGraph(graph);
+
+ //Retrieve DatasetGraph of current Graph.
+ DatasetGraph datasetGraph = execCxt.getDataset();
+
+ //Retrieve a different Graph in the Dataset.
+ Node otherGraphNode =
NodeFactory.createURI("http://example.org/otherGraph;);
+ Graph otherGraph = datasetGraph.getNamedGraph(otherGraphNode);
+
+ //Create a new Graph in the Dataset, or overwrite an existing Named
Graph.
+ Graph newGraph = ...
+ //Add data to the newGraph as retaining empty Graphs is implementation
dependent.
+ datasetGraph.addGraph(otherGraphNode, newGraph);
\ No newline at end of file
CMS diff: TDB Datasets
Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Ftdb%2Fdatasets.mdtext
Greg Albiston
Index: trunk/content/documentation/tdb/datasets.mdtext
===
--- trunk/content/documentation/tdb/datasets.mdtext (revision 1812597)
+++ trunk/content/documentation/tdb/datasets.mdtext (working copy)
@@ -65,5 +65,22 @@
`urn:x-arq:UnionGraph` using
`Dataset.getNamedModel("urn:x-arq:UnionGraph")` .
+## Dataset Inferencing
+Inferencing on a Model in a Dataset, using the [TDB Java API](java_api.html),
follows the same pattern as an in-memory InfModel.
+The use of [TDB Transactions](tdb_transactions.html) is **strongly**
recommended to avoid data corruption.
+ //Open TDB Dataset
+ String directory = ...
+ Dataset dataset = TDBFactory.createDataset(directory);
+
+ //Retrieve Named Graph from Dataset, or use Default Graph.
+ String graphURI = "http://example.org/myGraph;;
+ Model model = dataset.getNamedModel(graphURI);
+
+ //Create RDFS Inference Model, or use other Reasoner e.g. OWL.
+ InfModel infModel = ModelFactory.createRDFSModel(model);
+
+ ...
+ //Perform operations on infModel.
+ ...
\ No newline at end of file
CMS diff: TDB FAQs
Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Ftdb%2Ffaqs.mdtext
Greg Albiston
Index: trunk/content/documentation/tdb/faqs.mdtext
===
--- trunk/content/documentation/tdb/faqs.mdtext (revision 1812597)
+++ trunk/content/documentation/tdb/faqs.mdtext (working copy)
@@ -102,7 +102,7 @@
TDB uses write-ahead logging so new data is written both to an on-disk journal
and kept in-memory. This is necessary because TDB permits
a single writer and multiple readers at any one time and readers are
guaranteed to always see the state of the database at the time they
-started reading. Therefore until there are no active readers it is not
possible to update the database directly since readers are actively
+started reading. Therefore, until there are no active readers it is not
possible to update the database directly since readers are actively
accessing it hence why a journal is used. The in-memory journal holds some
memory that cannot be freed up until such time as the database
has no active readers/writers and the changes it holds can be safely flushed
to disk.
@@ -110,8 +110,20 @@
eventually causing out of memory errors in Fuseki. You can see if you are
experiencing this issue by examining your database directory, if it
contains a `.jrnl` file that is non-empty then Fuseki/TDB is having to hold
the journal in-memory.
-**However** because this relates to transactional use and the journal is also
stored on disk no data will be lost, by stopping and restarting
-Fuseki the journal will be flushed to disk.
+**However**, because this relates to transactional use and the journal is also
stored on disk no data will be lost, by stopping and restarting
+Fuseki the journal will be flushed to disk. When using the [TDB Java
API](java_api.html), the journal can be flushed by closing any datasets and
releasing the TDB resources.
+
+ Dataset dataset = TDBFactory.createDataset(directory) ;
+ try{
+ ...
+ dataset.begin(ReadWrite.READ) ;
+ // Perform operations
+ dataset.end() ;
+ ...
+ }finally{
+ dataset.close();
+ TDBFactory.release(dataset);
+ }
## Should I use a SSD?
[jira] [Updated] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
[
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Albiston updated JENA-1402:
Description:
There is an issue when subtracting two xsd:durations that include:
* decimal seconds
* non-zero minutes
* second operand has a greater number of seconds than the first operand, i.e.
the minutes are reduced.
The result is a large number of minutes and incorrect seconds.
For example:
Integer, Larger: "PT2M3S" - "PT1M10S" = "PT0M53S" CORRECT
Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S" = "-PT1M7.000S" CORRECT
Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S" = "PT883M0.020S"
INCORRECT
Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S"
INCORRECT
Example SPARQL:
{code:sparql}
SELECT ?res ?op1 ?op2
WHERE{
VALUES (?op1 ?op2) {
("PT2M3S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT1M10S"^^<http://www.w3.org/2001/XMLSchema#duration>)
("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT1M1.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
("PT0M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
("PT1H4M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT0M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
}
BIND(?op1 - ?op2 AS ?res)
}
{code}
was:
There is an issue when subtracting two xsd:durations that include:
* decimal seconds
* non-zero minutes
* second operand has a greater number of seconds than the first operand, i.e.
the minutes are reduced.
The result is a large number of minutes and incorrect seconds.
For example:
Integer, Larger: "PT2M3S" - "PT1M10S" = "PT0M53S" CORRECT
Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S" = "-PT1M7.000S" CORRECT
Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S" = "PT883M0.020S"
INCORRECT
Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S"
INCORRECT
Example SPARQL:
SELECT ?res ?op1 ?op2
WHERE{
VALUES (?op1 ?op2) {
("PT2M3S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT1M10S"^^<http://www.w3.org/2001/XMLSchema#duration>)
("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT1M1.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
("PT0M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
("PT1H4M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT0M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
}
BIND(?op1 - ?op2 AS ?res)
}
> Subtracting two xsd:Duration gives incorrect results in SPARQL query
>
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e.
> the minutes are reduced.
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S" = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S" = "-PT1M7.000S"
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S" = "PT883M0.020S"
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S&
[jira] [Created] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query
Greg Albiston created JENA-1402:
---
Summary: Subtracting two xsd:Duration gives incorrect results in
SPARQL query
Key: JENA-1402
URL: https://issues.apache.org/jira/browse/JENA-1402
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Affects Versions: Jena 3.4.0
Reporter: Greg Albiston
There is an issue when subtracting two xsd:durations that include:
* decimal seconds
* non-zero minutes
* second operand has a greater number of seconds than the first operand, i.e.
the minutes are reduced.
The result is a large number of minutes and incorrect seconds.
For example:
Integer, Larger: "PT2M3S" - "PT1M10S" = "PT0M53S" CORRECT
Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S" = "-PT1M7.000S" CORRECT
Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S" = "PT883M0.020S"
INCORRECT
Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S"
INCORRECT
Example SPARQL:
SELECT ?res ?op1 ?op2
WHERE{
VALUES (?op1 ?op2) {
("PT2M3S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT1M10S"^^<http://www.w3.org/2001/XMLSchema#duration>)
("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT1M1.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
("PT0M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
("PT2M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT1M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
("PT1H4M3.123S"^^<http://www.w3.org/2001/XMLSchema#duration>
"PT0M10.123S"^^<http://www.w3.org/2001/XMLSchema#duration>)
}
BIND(?op1 - ?op2 AS ?res)
}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JENA-1339) Property Function signature for List subjects and List objects.
Greg Albiston created JENA-1339: --- Summary: Property Function signature for List subjects and List objects. Key: JENA-1339 URL: https://issues.apache.org/jira/browse/JENA-1339 Project: Apache Jena Issue Type: Improvement Components: ARQ Affects Versions: Jena 3.3.0 Reporter: Greg Albiston Priority: Minor Fix For: Jena 3.4.0 Attachments: PFuncListAndList.patch An abstract Property Function signature is already defined for single subject and multiple objects but there is no signature for multiple subject and multiple objects. SPIN permits defining property functions (magic properties) with this n:n signature. The patch is a single class PFuncListAndList with formatting based upon the existing PFuncSimpleAndList class. Documentation will need updating at: https://jena.apache.org/documentation/query/writing_propfuncs.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (JENA-1339) Property Function signature for List subjects and List objects.
[ https://issues.apache.org/jira/browse/JENA-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Albiston updated JENA-1339: Attachment: PFuncListAndList.patch > Property Function signature for List subjects and List objects. > --- > > Key: JENA-1339 > URL: https://issues.apache.org/jira/browse/JENA-1339 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ >Affects Versions: Jena 3.3.0 > Reporter: Greg Albiston >Priority: Minor > Labels: easyfix, newbie > Fix For: Jena 3.4.0 > > Attachments: PFuncListAndList.patch > > > An abstract Property Function signature is already defined for single subject > and multiple objects but there is no signature for multiple subject and > multiple objects. > SPIN permits defining property functions (magic properties) with this n:n > signature. > The patch is a single class PFuncListAndList with formatting based upon the > existing PFuncSimpleAndList class. > Documentation will need updating at: > https://jena.apache.org/documentation/query/writing_propfuncs.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
CMS diff: Fuseki: serving RDF data over HTTP
Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fserving_data%2Findex.mdtext Greg Albiston Index: trunk/content/documentation/serving_data/index.mdtext === --- trunk/content/documentation/serving_data/index.mdtext (revision 1603331) +++ trunk/content/documentation/serving_data/index.mdtext (working copy) @@ -1,5 +1,7 @@ Title: Fuseki: serving RDF data over HTTP +Added link to the assembler howto page which provides the actual detail of using the assembler. +It is easy to miss the link to this page on the assembler howto. Fuseki is a SPARQL server. It provides REST-style SPARQL HTTP Update, SPARQL Query, and SPARQL Update using the SPARQL protocol over HTTP. @@ -275,7 +277,7 @@ fuseki-server --desc assembler.ttl /ds Full details of setting up models assembler is given in the -[assembler documentation](/documentation/assembler/). +[assembler documentation](/documentation/assembler/) and [assembler howto](/documentation/assembler/assembler-howto.html). A general dataset is described by: @@ -486,4 +488,3 @@ target/fuseki-version-server.jar See the file `SETUP.txt` for working with Eclipse. -
CMS diff: Reasoners and rule engines: Jena inference support
Clone URL (Committers only): https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Finference%2Findex.mdtext Greg Albiston Index: trunk/content/documentation/inference/index.mdtext === --- trunk/content/documentation/inference/index.mdtext (revision 1603331) +++ trunk/content/documentation/inference/index.mdtext (working copy) @@ -1,5 +1,7 @@ Title: Reasoners and rule engines: Jena inference support +All headings below Rules syntax and structure aren't displaying correctly. +Added two missing /p tags at the end of section which could be causing the problem. pThis section of the documentation describes the current support for inference available within Jena. It includes an outline of the general inference API, together with details of the specific rule engines and configurations for RDFS @@ -1339,7 +1341,7 @@ codeOWLMini/code (case insensitive). /dd /dl - +/p p So an example complete rule file which includes the RDFS rules and defines a single extra rule is: @@ -1348,7 +1350,7 @@ @include lt;RDFSgt;. [rule1: (?f pre:father ?a) (?u pre:brother ?f) -gt; (?u pre:uncle ?a)] - +/p p[a href=#rulesRule index/a] [a href=#indexmain index/a]/p ### a name=RULEforward/aForward chaining engine
