Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE REQUEST] Add GeoSPARQL support on arq and tdbquery #1953

Open
bioinfornatics opened this issue Jul 10, 2023 · 5 comments
Open

[FEATURE REQUEST] Add GeoSPARQL support on arq and tdbquery #1953

bioinfornatics opened this issue Jul 10, 2023 · 5 comments
Labels
enhancement Incrementally add new feature

Comments

@bioinfornatics
Copy link

bioinfornatics commented Jul 10, 2023

Version

4.8

Feature

Dear Jena team,
To my understanding fuseki is compiled with GeoSPARQL but not Arq and tdbquery

Is it possible to add this feature to these tools ?

Thanks

Are you interested in contributing a solution yourself?

None

@bioinfornatics bioinfornatics added the enhancement Incrementally add new feature label Jul 10, 2023
@rvesse
Copy link
Member

rvesse commented Jul 10, 2023

I believe that most of the CLI tools are present in the Fuseki JAR distribution but it's non-obvious in that it requires knowing the package and classname of the tool you want to run e.g.

$ java -cp fuseki-server.jar tdb.tdbquery --help   
tdbquery --loc=<path> --query=<query>

@afs
Copy link
Member

afs commented Jul 10, 2023

Is the request to include the scripts in the Fuseki download?

@LorenzBuehmann
Copy link
Contributor

LorenzBuehmann commented Jul 11, 2023

I'm pretty sure that GeoSPARQL isn't part of the default Fuseki distribution yet, only the text index is there as an extension. I think I mentioned it some time ago hidden in some other issues, but forgot to keep track of it:

https://github.com/apache/jena/blob/main/jena-fuseki2/jena-fuseki-server/pom.xml

Regarding the confusion, the TO wants to use GeoSPARQL features with tdbquery, but this doesn't work at the moment. Adding a jena-geosparql Uber Jar to the classpath or use tdbquery from the Fuseki fulljar (once jena-geosparql has been added!) will at least make the functions and datatypes being registered and work:

java -cp /tmp/jena-fuseki-fulljar-4.9.0.jar tdb2.tdbquery --loc /tmp/tdb2 '

PREFIX geo:  <http://www.opengis.net/ont/geosparql#>
PREFIX geof: <http://www.opengis.net/def/function/geosparql/>
PREFIX uom: <http://www.opengis.net/def/uom/OGC/1.0/>

SELECT * {
BIND("POINT(1.0 1.0)"^^geo:wktLiteral AS ?p1)
BIND("POINT(2.0 2.0)"^^geo:wktLiteral AS ?p2)
BIND(geof:distance(?p1, ?p2, uom:radian) AS ?d)
}'
07:53:56 WARN  system          :: The “SIS_DATA” environment variable is not set.
------------------------------------------------------------------------------------
| p1                               | p2                               | d          |
====================================================================================
| "POINT(1.0 1.0)"^^geo:wktLiteral | "POINT(2.0 2.0)"^^geo:wktLiteral | 0.024683e0 |
------------------------------------------------------------------------------------

What does not work is probably using a GeosparqlDataset in an assembler file because from what I remember when looking at the code some time ago, tdbquery only considers a TDBDataset?

So my guess once you added a full jar of jena-geosparql (needs Maven shade plugin), the GeoSPARQL functions will work because they are registered via service loader, but the spatial index I guess won't as this is part of the GeosparqlDataset which registers the index to the query context on initialization.

@afs
Copy link
Member

afs commented Jul 11, 2023

I'm pretty sure that GeoSPARQL isn't part of the default Fuseki distribution yet,

There is jena-fuseki-geosparql, a build of Fuseki with jena-geosparql. It has different command line options which is one factor that stops common integration.

If the dataset is coming from an assembler, the extension mechanism FusekiAutoModule could be used.

That can also include a command line entry point that either (1) generates an assembler for later use (2) writes an assembler that is picked up by the module (3) or creates a datastructure with the details that the module picks up (preference - the latter so in-memory, no disk use at all works.).

tdbquery only considers a TDBDataset?

Yes.

Assembling needs a starting point in the case of more than one description in a file. tdbquery is doing that based on type. The sparql command can take a configuration with any single dataset setup. A feature is needed to specific the starting point of building the dataset.


GeoSPARQL is sufficient different in its feature set and needs that there needs to be a community around it to maintain and evolve the GeoSPARQL support.

See also: #1344 which has several suggestions but hasn't come to a clear consensus on direction.

@SimonBin
Copy link
Contributor

(by the way my colleague @Aklakan has built a tool around Apache Jena which you could use if you want to: rpt integrate -e tdb2 --loc=yourtdb2 --geoindex --out-format text/plain yourquery.rq)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Incrementally add new feature
Projects
None yet
Development

No branches or pull requests

5 participants