[jira] [Commented] (JENA-1731) Improve Fuseki service endpoint configuration
[
https://issues.apache.org/jira/browse/JENA-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918143#comment-16918143
]
Andy Seaborne commented on JENA-1731:
-
The timeout example is for a SPARQL query. This is the existing way to set a
timeout.
This does not apply to text search directly - but if the query goes over the
limit it will abort the text search when the SPARQL engine gets the chance.
The query exits with a "QueryCancelledException" which Fuseki tries to send
back to the client.
Unfortunately, in HTTP, the response code is sent back first. So it is possible
that the client can get the 200, then the result stream is truncated. Fuseki
writes syntactically illegal results to force an error processing the results.
This is something SPARQL 1.2 CG may address. There are several issues that
touch on this known problem.
To continue this discussion, the users@ list would be a good place.
> Improve Fuseki service endpoint configuration
> -
>
> Key: JENA-1731
> URL: https://issues.apache.org/jira/browse/JENA-1731
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki
>Affects Versions: Jena 3.13.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a follow-on JIRA from JENA-1715.
> A sketch for new configuration description for a service endpoint:
> {noformat}
> <#service> rdf:type fuseki:Service ;
> fuseki:name "/ds" ;
> fuseki:endpoint [
> fuseki:operation fuseki:Query ;
> fuseki:allowedUsers () ;
> fuseki:timeout "1000,1" ;
> fuseki:queryLimit1000;
> arq:unionGraph true;
> ja:context [ ja:cxtName "arq:queryTimeout" ; ja:cxtValue "1000,1"
> ] ;
> ] ;
> fuseki:endpoint [
> fuseki:name "sparql" ; ## becomes "/ds/sparql"
> fuseki:operation fuseki:Query ;
> ...
> ] ;
> fuseki:endpoint [
> fuseki:name "sparql" ;
> fuseki:operation fuseki:Update ;
> ...
> ] ;
> .
> {noformat}
> with the goal of being able to have new operations confiugured into the
> Fuseki endgine, and not the fixed set of operations as is currently with
> {{fuseki;service*}}.
> For example: a "patch" service - POST an [RDF
> Patch|https://afs.github.io/rdf-delta/rdf-patch.html] or have a data
> validation service for SHACL etc.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JENA-1731) Improve Fuseki service endpoint configuration
[
https://issues.apache.org/jira/browse/JENA-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917948#comment-16917948
]
Elie Roux commented on JENA-1731:
-
I don't know how related it is to this ticket, but I'm wondering if there's a
per-endpoint way to tell Fuseki not to run a search thread more than X seconds?
In other words, what exactly does fuseki:timeout do? Does it just stop the
http request or does it stop the TDB query thread? Thanks!
> Improve Fuseki service endpoint configuration
> -
>
> Key: JENA-1731
> URL: https://issues.apache.org/jira/browse/JENA-1731
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki
>Affects Versions: Jena 3.13.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a follow-on JIRA from JENA-1715.
> A sketch for new configuration description for a service endpoint:
> {noformat}
> <#service> rdf:type fuseki:Service ;
> fuseki:name "/ds" ;
> fuseki:endpoint [
> fuseki:operation fuseki:Query ;
> fuseki:allowedUsers () ;
> fuseki:timeout "1000,1" ;
> fuseki:queryLimit1000;
> arq:unionGraph true;
> ja:context [ ja:cxtName "arq:queryTimeout" ; ja:cxtValue "1000,1"
> ] ;
> ] ;
> fuseki:endpoint [
> fuseki:name "sparql" ; ## becomes "/ds/sparql"
> fuseki:operation fuseki:Query ;
> ...
> ] ;
> fuseki:endpoint [
> fuseki:name "sparql" ;
> fuseki:operation fuseki:Update ;
> ...
> ] ;
> .
> {noformat}
> with the goal of being able to have new operations confiugured into the
> Fuseki endgine, and not the fixed set of operations as is currently with
> {{fuseki;service*}}.
> For example: a "patch" service - POST an [RDF
> Patch|https://afs.github.io/rdf-delta/rdf-patch.html] or have a data
> validation service for SHACL etc.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JENA-1731) Improve Fuseki service endpoint configuration
[
https://issues.apache.org/jira/browse/JENA-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917938#comment-16917938
]
Andy Seaborne commented on JENA-1731:
-
[PR #595 |https://github.com/apache/jena/pull/595] covers setting up endpoint
by context but not the additional syntax for easier access:
{{ ja:context [ ja:cxtName "arq:queryTimeout" ; ja:cxtValue "1000,1" ]
;}}
not the convenience form:
{{ fuseki:timeout "1000,1" ;}}
> Improve Fuseki service endpoint configuration
> -
>
> Key: JENA-1731
> URL: https://issues.apache.org/jira/browse/JENA-1731
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki
>Affects Versions: Jena 3.13.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a follow-on JIRA from JENA-1715.
> A sketch for new configuration description for a service endpoint:
> {noformat}
> <#service> rdf:type fuseki:Service ;
> fuseki:name "/ds" ;
> fuseki:endpoint [
> fuseki:operation fuseki:Query ;
> fuseki:allowedUsers () ;
> fuseki:timeout "1000,1" ;
> fuseki:queryLimit1000;
> arq:unionGraph true;
> ja:context [ ja:cxtName "arq:queryTimeout" ; ja:cxtValue "1000,1"
> ] ;
> ] ;
> fuseki:endpoint [
> fuseki:name "sparql" ; ## becomes "/ds/sparql"
> fuseki:operation fuseki:Query ;
> ...
> ] ;
> fuseki:endpoint [
> fuseki:name "sparql" ;
> fuseki:operation fuseki:Update ;
> ...
> ] ;
> .
> {noformat}
> with the goal of being able to have new operations confiugured into the
> Fuseki endgine, and not the fixed set of operations as is currently with
> {{fuseki;service*}}.
> For example: a "patch" service - POST an [RDF
> Patch|https://afs.github.io/rdf-delta/rdf-patch.html] or have a data
> validation service for SHACL etc.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JENA-1743) Provide QueryExecutionBuilder
[
https://issues.apache.org/jira/browse/JENA-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917930#comment-16917930
]
Andy Seaborne commented on JENA-1743:
-
As part of [https://github.com/apache/jena/pull/595].
See [QueryExecutionBuilder
changes|https://github.com/apache/jena/pull/595/files#diff-b1f906a7d7228faae3791856e90ba65d0]
and [QueryExecution
changes|https://github.com/apache/jena/pull/595/files#diff-a01903001d88e090fd1030924a254ae4].
> Provide QueryExecutionBuilder
> -
>
> Key: JENA-1743
> URL: https://issues.apache.org/jira/browse/JENA-1743
> Project: Apache Jena
> Issue Type: Task
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>
> A builder pattern is a better way to create {{QueryExecution}} objects for
> local executions.
> Provide {{QueryExecutionBuilder}}.
> Keep {{QueryExecutionFactory}} and have it use {{QueryExecutionBuilder}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [jena] afs opened a new pull request #595: JENA-1731: Fuseki service configuration
afs opened a new pull request #595: JENA-1731: Fuseki service configuration
URL: https://github.com/apache/jena/pull/595
Documentation draft:
https://gist.github.com/afs/1d4c6584723b72c5e7b892057029a8f4
This became a major refactoring and clean-up of the Fuseki dispatch and
service code. The code was significantly hardwired to the fixed set of standard
services so because it needing changing anyway, this PR reworks the code to be
general, to rename things to a consistent new naming and general clearup. The
old quads/GSP split has gone - quad operations are now an extension of the GSP
operations.
Includes JENA-1743 (QueryExecutionBuilder) and renaming a Context operation
("set" becomes merge") which touches lots of files in jena-arq.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[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=16917894#comment-16917894 ] Timo Homburg commented on JENA-1740: I understand. If the literals are accessed that often it might prove not feasible to store the whole image in the triple store. Considering this, I think the hash value would be a good idea. Would you also recommend this for textual raster data formats such as CoverageJSON or GMLCOV or did you only have raster image formats such as GEOTIFF and the likes in mind? I wonder if the textual formats would provide a similar challenge to the triple store if they were to be cached like the GeoSPARQL WKT literals > 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)
