This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a commit to branch asf-staging in repository https://gitbox.apache.org/repos/asf/jena-site.git
The following commit(s) were added to refs/heads/asf-staging by this push: new 3353f59 Staged site from geosparql (6f16600bf15b853d31aadf61950ed551b8d920c6) 3353f59 is described below commit 3353f59cd486128adff5b7d4f43e37af127b6684 Author: jenkins <bui...@apache.org> AuthorDate: Mon Dec 27 19:55:37 2021 +0000 Staged site from geosparql (6f16600bf15b853d31aadf61950ed551b8d920c6) --- .../geosparql/geosparql-assembler.html} | 214 +++++----- .../documentation/geosparql/geosparql-fuseki.html | 91 +++-- content/documentation/geosparql/index.html | 445 +++++++++++++-------- content/documentation/index.xml | 32 +- .../data/{owlDemoData.xml => owlDemoData.rdf} | 0 .../data/{owlDemoSchema.xml => owlDemoSchema.rdf} | 0 content/documentation/inference/index.html | 42 +- content/documentation/query/text-query.html | 3 +- content/documentation/query/writing_propfuncs.html | 8 +- content/download/index.html | 30 +- content/index.xml | 32 +- content/sitemap.xml | 21 +- 12 files changed, 525 insertions(+), 393 deletions(-) diff --git a/content/download/index.html b/content/documentation/geosparql/geosparql-assembler.html similarity index 60% copy from content/download/index.html copy to content/documentation/geosparql/geosparql-assembler.html index 024d5ab..eea5bb4 100644 --- a/content/download/index.html +++ b/content/documentation/geosparql/geosparql-assembler.html @@ -3,7 +3,7 @@ <head> - <title>Apache Jena - Apache Jena Releases</title> + <title>Apache Jena - GeoSPARQL Assembler</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> @@ -119,7 +119,7 @@ </ul> </li> - <li id="edit"><a href="https://github.com/apache/jena-site/edit/main/source/download/__index.md" title="Edit this page on GitHub"><span class="glyphicon glyphicon-pencil"></span> Edit this page</a></li> + <li id="edit"><a href="https://github.com/apache/jena-site/edit/main/source/documentation/geosparql/geosparql-assembler.md" title="Edit this page on GitHub"><span class="glyphicon glyphicon-pencil"></span> Edit this page</a></li> </ul> </div> </div> @@ -136,9 +136,6 @@ - - - <ol class="breadcrumb"> @@ -149,7 +146,23 @@ - <li class="active">DOWNLOAD</li> + <li><a href='/documentation'>DOCUMENTATION</a></li> + + + + + + + + <li><a href='/documentation/geosparql'>GEOSPARQL</a></li> + + + + + + + + <li class="active">GEOSPARQL ASSEMBLER</li> @@ -161,128 +174,83 @@ </div> - <h1 class="title">Apache Jena Releases</h1> + <h1 class="title">GeoSPARQL Assembler</h1> - <p>Apache Jena is packaged as downloads which contain the most commonly used portions of the systems:</p> -<ul> -<li><strong>apache-jena</strong> – contains the APIs, SPARQL engine, the TDB native RDF database and command line tools</li> -<li><strong>apache-jena-fuseki</strong> – the Jena SPARQL server</li> -</ul> -<p>Jena4 requires Java 11.</p> -<p>Jena jars are <a href="maven.html">available from Maven</a>.</p> -<p>You may <a href="https://www.apache.org/info/verification.html">verify the authenticity of artifacts</a> below by using the <a href="https://downloads.apache.org/jena/KEYS">PGP KEYS</a> file.</p> -<h3 id="apache-jena-distributions">Apache Jena Distributions</h3> -<p>The binary distribution of Fuseki (this includes both the standalone and -WAR file packaging):</p> -<table> -<thead> -<tr> -<th>Jena Fuseki</th> -<th align="center">SHA512</th> -<th align="center">Signature</th> -</tr> -</thead> -<tbody> -<tr> -<td><a href="[preferred]jena/binaries/apache-jena-fuseki-4.2.0.tar.gz">apache-jena-fuseki-4.2.0.tar.gz</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-fuseki-4.2.0.tar.gz.sha512">SHA512</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-fuseki-4.2.0.tar.gz.asc">PGP</a></td> -</tr> -<tr> -<td><a href="[preferred]jena/binaries/apache-jena-fuseki-4.2.0.zip">apache-jena-fuseki-4.2.0.zip</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-fuseki-4.2.0.zip.sha512">SHA512</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-fuseki-4.2.0.zip.asc">PGP</a></td> -</tr> -</tbody> -</table> -<p> </p> -Source release: this forms the official release of Apache Jena. All binaries artifacts and maven binaries correspond to this source. -<table> -<thead> -<tr> -<th>Apache Jena Release</th> -<th align="center">SHA512</th> -<th align="center">Signature</th> -</tr> -</thead> -<tbody> -<tr> -<td><a href="[preferred]jena/source/jena-4.2.0-source-release.zip">jena-4.2.0-source-release.zip</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/source/jena-4.2.0-source-release.zip.sha512">SHA512</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/source/jena-4.2.0-source-release.zip.asc">PGP</a></td> -</tr> -</tbody> -</table> -<p> </p> -The binary distribution of libraries contains the APIs, SPARQL engine, the TDB native RDF database and a variety of command line scripts and tools for working with these systems. -<table> -<thead> -<tr> -<th>Jena libraries</th> -<th align="center">SHA512</th> -<th align="center">Signature</th> -</tr> -</thead> -<tbody> -<tr> -<td><a href="[preferred]jena/binaries/apache-jena-4.2.0.tar.gz">apache-jena-4.2.0.tar.gz</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-4.2.0.tar.gz.sha512">SHA512</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-4.2.0.tar.gz.asc">PGP</a></td> -</tr> -<tr> -<td><a href="[preferred]jena/binaries/apache-jena-4.2.0.zip">apache-jena-4.2.0.zip</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-4.2.0.zip.sha512">SHA512</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-4.2.0.zip.asc">PGP</a></td> -</tr> -</tbody> -</table> -<h3 id="individual-modules">Individual Modules</h3> -<p>Apache Jena publishes a range of modules beyond those included in the binary distributions (code for all modules may be found in the source distribution).</p> -<p>Individual modules may be obtained using a dependency manager which can talk to Maven repositories, some modules are only available via Maven.</p> -<h4 id="maven">Maven</h4> -<p>See “<a href="maven.html">Using Jena with Apache Maven</a>” for full details.</p> + <p>Details of the GeoSPARQL support are proivded on the <a href="index">GeoSPARQL page</a>.</p> +<p>The assembler for GeoSPARQL support is part of the <code>jena-geosparql</code> artifact and +miost be on the Fuseki server classpath.</p> <pre><code><dependency> - <groupId>org.apache.jena</groupId> - <artifactId>apache-jena-libs</artifactId> - <type>pom</type> - <version>X.Y.Z</version> + <groupId>org.apache.jena</groupId> + <artifactId>jena-geosparql</artifactId> + <version>...</version> </dependency> </code></pre> -<h4 id="source-code">Source code</h4> -<p>The development codebase is available from git.</p> -<p><a href="https://gitbox.apache.org/repos/asf?p=jena.git">https://gitbox.apache.org/repos/asf?p=jena.git</a></p> -<p>This is also available on github:</p> -<p><a href="https://github.com/apache/jena">https://github.com/apache/jena</a></p> -<h4 id="previous-releases">Previous releases</h4> -<p>While previous releases are available, we strongly recommend that wherever -possible users use the latest official Apache releases of Jena in -preference to using any older versions of Jena.</p> -<p>Previous Apache Jena releases can be found in the Apache archive area -at <a href="https://archive.apache.org/dist/jena/">https://archive.apache.org/dist/jena</a>.</p> -<h2 id="download-mirrors">Download Mirrors</h2> -<p>[if-any logo] -<a href="[link]"> - <img align="right" src="[logo]" border="0" /> -</a>[end] -The currently selected mirror is <b>[preferred]</b>. If you encounter a problem with this mirror, please select another mirror. If all -mirrors are failing, there are <i>backup</i> mirrors (at the end of the mirrors list) that should be available.</p> -<form action="[location]" method="get" id="SelectMirror"> -Other mirrors: <select name="Preferred"> -[if-any http] - [for http]<option value="[http]">[http]</option>[end] -[end] -<p>[if-any ftp] -[for ftp]<option value="[ftp]">[ftp]</option>[end] -[end] -[if-any backup] -[for backup]<option value="[backup]">[backup] -(backup)</option>[end] -[end] -</select> -<input type="submit" value="Change" /></p> -</form> -<p>You may also consult the <a href="https://www.apache.org/mirrors/">complete list of mirrors</a></p> +<p>or download the binary from the +<a href="https://repo1.maven.org/maven2/org/apache/jena/jena-geosparql/">Maven central repository org/apache/jena/jena-geosparql</a></p> +<p>The GeoSPARQL assembler can be used in a Fuseki configuration file.</p> +<p>This example is of a read-only</p> +<pre><code>PREFIX fuseki: <http://jena.apache.org/fuseki#> +PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> +PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> +PREFIX tdb2: <http://jena.apache.org/2016/tdb#> + +PREFIX ja: <http://jena.hpl.hp.com/2005/11/Assembler#> +PREFIX geosparql: <http://jena.apache.org/geosparql#> + +<#service> rdf:type fuseki:Service; + fuseki:name "geo"; + fuseki:endpoint [ fuseki:operation fuseki:query; ] ; + fuseki:dataset <#geo_ds> . + +<#geo_ds> rdf:type geosparql:geosparqlDataset ; + geosparql:spatialIndexFile "DB/spatial.index"; + geosparql:dataset <#baseDataset> ; + . + +<#baseDataset> rdf:type tdb2:DatasetTDB2 ; + tdb2:location "DB/" ; + . +</code></pre><p>It is possible to run with a data file loaded into memory and +an spatial in-memory index:</p> +<pre><code>PREFIX fuseki: <http://jena.apache.org/fuseki#> +PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> +PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> + +PREFIX ja: <http://jena.hpl.hp.com/2005/11/Assembler#> +PREFIX geosparql: <http://jena.apache.org/geosparql#> +<#service> rdf:type fuseki:Service; + fuseki:name "ds"; + fuseki:endpoint [ fuseki:operation fuseki:query; ] ; + fuseki:dataset <#geo_ds> . + +# In-memory data and index. + +<#geo_ds> rdf:type geosparql:geosparqlDataset ; + geosparql:dataset <#baseDataset> . + +<#baseDataset> rdf:type ja:MemoryDataset ; + ja:data <file:geosparql_data.ttl> ; + . +</code></pre><p>The full assembler properties with the default settings is:</p> +<pre><code><#geo_ds> rdf:type geosparql:geosparqlDataset ; + # Build in-memory is absent. + geosparql:spatialIndexFile "spatial.index"; + + ## Default settings. See documentation for meanings. + geosparql:inference true ; + geosparql:queryRewrite true ; + geosparql:indexEnabled true ; + geosparql:applyDefaultGeometry false ; + + # 3 item lists: [Geometry Literal, Geometry Transform, Query Rewrite] + geosparql:indexSizes "-1,-1,-1" ; # Default - unlimited. + geosparql:indexExpires "5000,5000,5000" ; # Default - time in milliseconds. + + ## Required setting - data over which GeoSPARQL is applied. + geosparql:dataset <#baseDataset> ; + . +</code></pre> </div> </div> diff --git a/content/documentation/geosparql/geosparql-fuseki.html b/content/documentation/geosparql/geosparql-fuseki.html index 5d18b31..0c78f12 100644 --- a/content/documentation/geosparql/geosparql-fuseki.html +++ b/content/documentation/geosparql/geosparql-fuseki.html @@ -176,48 +176,71 @@ </div> <h1 class="title">GeoSPARQL Fuseki</h1> - <p>This application provides a HTTP server compliant with the GeoSPARQL standard. -It uses the embedded server Fuseki and provides additional parameters for dataset loading.</p> -<p>The project uses the GeoSPARQL implementation from the <a href="index">GeoSPARQL Jena module</a>, which includes a range of functions in addition to those from the GeoSPARQL standard.</p> -<p>Currently, <strong>there is no GUI interface</strong> as provided in the Fuseki distribution.</p> -<p>The intended usage is to specify a TDB folder (either TDB1 or TDB2, created if required) for persistent storage of the dataset. File loading, inferencing and data conversion operations can also be specified to load and manipulate data into the dataset. When the server is restarted these conversion operations are not required again (as they have been stored in the dataset) unless there are relevant changes. The TDB dataset can also be prepared and manipulated programatically using the [...] -<p>Updates can be made to the dataset while the Fuseki server is running. However, these changes will not be applied to inferencing and spatial indexes until the server restarts (any default or specified spatial index file must not exists to trigger building). This is due to the current implementation of RDFS inferencing in Jena (and is required in any Fuseki server with inferencing) and the selected spatial index.</p> -<p>A subset of the EPSG spatial/coordinate reference systems are included by default from the Apache SIS project (<a href="http://sis.apache.org">http://sis.apache.org</a>). -The full EPSG dataset is not distributed due to the EPSG terms of use being incompatible with the Apache Licence. -Several options are available to include the EPSG dataset by setting the <code>SIS_DATA</code> environment variable (<a href="http://sis.apache.org/epsg.html)">http://sis.apache.org/epsg.html)</a>.</p> -<p>It is expected that at least one Geometry Literal or Geo Predicate is present in a dataset (otherwise a standard Fuseki server can be used). -A spatial index is created and new data cannot be added to the index once built. -The spatial index can optionally be stored for future usage and needs to removed from a TDB folder if the index is to rebuilt.</p> -<h2 id="clarifications-on-geosparql">Clarifications on GeoSPARQL</h2> -<h3 id="geographic-markup-language-gml">Geographic Markup Language (GML)</h3> -<p>GeoSPARQL refers to the Geographic Markup Language (GML) as one format for <code>GeometryLiterals</code>. This does not mean that GML is part of the GeoSPARQL standard. Instead a subset of geometry encodings from the GML standards are permitted (specifically the <code>GML 2.0 Simple Features Profile (10-100r3)</code> is supported by GeoSPARQL Jena). The expected encoding of data is in RDF triples and can be loaded from any RDF file format supported by Apache Jena. Conversion of GML to [...] -<h3 id="geo-predicates-latlon">Geo Predicates Lat/Lon</h3> -<p>Historically, geopsatial data has frequently been encoded as Latitude/Longitude coordinates in the WGS84 coordinate reference system. The GeoSPARQL standard specifically chooses not to adopt this approach and instead uses the more versatile <code>GeomtryLiteral</code>, which permits multiple encoding formats that support multiple coordinate reference systems and geometry shapes. Therefore, Lat/Lon Geo Predicates are not part of the GeoSPARQL standard. However, GeoSPARQL Jena provides [...] -<ul> -<li> -<ol> -<li>Conversion of Geo Predicates to the GeoSPARQL data structure (encoding the Lat/Lon as a Point geometry).</li> -</ol> -</li> -<li> -<ol start="2"> -<li>Spatial extension which provides property and filter functions accepting Lat/Lon arguments.</li> -</ol> -</li> -</ul> -<p>The Spatial extension functions (documented in the <a href="index">GeoSPARQL Jena module</a>) support triples in either GeoSPARQL data structure or Geo Predicates. Therefore, converting a dataset to GeoSPARQL will not lose functionality. By converting to the GeoSPARQL data structure, datasets can include a broader range of geospatial data.</p> -<h2 id="getting-started">Getting Started</h2> + <p>This application provides a HTTP server compliant with the GeoSPARQL standard.</p> +<p>GEoSPARQL can also be ingtegrated with Fuseki using the +<a href="#fuseki-assembler">GeoSPARQL assembler</a> with a general Fuseki server.</p> +<h2 id="jena-fuseki-geosparql"><code>jena-fuseki-geosparql</code></h2> <p>GeoSPARQL Fuseki can be accessed as an embedded server using Maven etc. from Maven Central or run from the command line. SPARQL queries directly on Jena Datasets and Models can be done using -the <a href="index">GeoSPARQL Jena module</a>.</p> +the <a href="index.html">GeoSPARQL Jena module</a>.</p> <pre><code><dependency> <groupId>org.apache.jena</groupId> - <artifactId>fuseki-geosparql</artifactId> + <artifactId>jena-fuseki-geosparql</artifactId> <version>...</version> </dependency> </code></pre> <p>or download the binary from the -<a href="http://central.maven.org/maven2/org/apache/jena/jena-fuseki-geosparql/">Maven central repository org/apache/jena/jena-fuseki-geosparql</a></p> +<a href="https://repo1.maven.org/maven2/org/apache/jena/jena-fuseki-geosparql/">Maven central repository org/apache/jena/jena-fuseki-geosparql</a></p> +<p>This uses the embedded server Fuseki and provides additional parameters for dataset loading.</p> +<p>The project uses the GeoSPARQL implementation from the <a href="index.html">GeoSPARQL Jena module</a>, which includes a range of functions in addition to those from the GeoSPARQL standard.</p> +<p>Currently, there is no GUI interface as provided with this server.</p> +<p>The intended usage is to specify a TDB folder (either TDB1 or TDB2, created if +required) for persistent storage of the dataset. File loading, inferencing and +data conversion operations can also be specified to load and manipulate data +into the dataset. When the server is restarted these conversion operations are +not required again (as they have been stored in the dataset) unless there are +relevant changes. The TDB dataset can also be prepared and manipulated +programatically using the Jena API.</p> +<p>Updates can be made to the dataset while the Fuseki server is running. However, +these changes will not be applied to inferencing and spatial indexes until the +server restarts (any default or specified spatial index file must not exists to +trigger building). This is due to the current implementation of RDFS inferencing +in Jena (and is required in any Fuseki server with inferencing) and the selected +spatial index.</p> +<p>A subset of the EPSG spatial/coordinate reference systems are included by +default from the Apache SIS project (<a href="http://sis.apache.org">http://sis.apache.org</a>). The full EPSG +dataset is not distributed due to the EPSG terms of use being incompatible with +the Apache Licence. Several options are available to include the EPSG dataset +by setting the <code>SIS_DATA</code> environment variable +(<a href="http://sis.apache.org/epsg.html)">http://sis.apache.org/epsg.html)</a>.</p> +<p>It is expected that at least one Geometry Literal or Geo Predicate is present in +a dataset (otherwise a standard Fuseki server can be used). A spatial index is +created and new data cannot be added to the index once built. The spatial index +can optionally be stored for future usage and needs to removed from a TDB folder +if the index is to rebuilt.</p> +<h2 id="clarifications-on-geosparql">Clarifications on GeoSPARQL</h2> +<h3 id="geographic-markup-language-gml">Geographic Markup Language (GML)</h3> +<p>GeoSPARQL refers to the Geographic Markup Language (GML) as one format for +<code>GeometryLiterals</code>. This does not mean that GML is part of the GeoSPARQL +standard. Instead a subset of geometry encodings from the GML standards are +permitted (specifically the <code>GML 2.0 Simple Features Profile (10-100r3)</code> is +supported by GeoSPARQL Jena). The expected encoding of data is in RDF triples +and can be loaded from any RDF file format supported by Apache Jena. Conversion +of GML to RDF is out of scope of the GeoSPARQL standard and Apache Jena.</p> +<h3 id="geo-predicates-latlon">Geo Predicates Lat/Lon</h3> +<p>Historically, geopsatial data has frequently been encoded as Latitude/Longitude +coordinates in the WGS84 coordinate reference system. The GeoSPARQL standard +specifically chooses not to adopt this approach and instead uses the more +versatile <code>GeomtryLiteral</code>, which permits multiple encoding formats that support +multiple coordinate reference systems and geometry shapes. Therefore, Lat/Lon +Geo Predicates are not part of the GeoSPARQL standard. However, GeoSPARQL Jena +provides two methods to support users with geo predicates in their geospatial +data.</p> +<ol> +<li>Conversion of Geo Predicates to the GeoSPARQL data structure (encoding the Lat/Lon as a Point geometry).</li> +<li>Spatial extension which provides property and filter functions accepting Lat/Lon arguments.</li> +</ol> +<p>The Spatial extension functions (documented in the <a href="index">GeoSPARQL Jena module</a>) support triples in either GeoSPARQL data structure or Geo Predicates. Therefore, converting a dataset to GeoSPARQL will not lose functionality. By converting to the GeoSPARQL data structure, datasets can include a broader range of geospatial data.</p> <h3 id="command-line">Command Line</h3> <p>Run from the command line and send queries over HTTP.</p> <p><code>java -jar jena-fuseki-geosparql-VER.jar ARGS</code></p> diff --git a/content/documentation/geosparql/index.html b/content/documentation/geosparql/index.html index 277c831..e020a9b 100644 --- a/content/documentation/geosparql/index.html +++ b/content/documentation/geosparql/index.html @@ -172,10 +172,23 @@ <h1 class="title">Apache Jena GeoSPARQL</h1> <p>An implementation of GeoSPARQL 1.0 standard for SPARQL query or API.</p> -<p>An <a href="geosparql-fuseki">integration with Fuseki</a> is available but attention should be paid to the contents of this page to understand supported features.</p> +<p>Integration with Fuseki is provided either by using the +<a href="geosparql-assembler.html">GeoSPARQL assembler</a> or using the self-contained original +<a href="geosparql-fuseki.html">jena-fuseki-geosparql</a>. In either case, this page +describes the GeoSPARQL supported features.</p> +<h2 id="getting-started">Getting Started</h2> +<p>GeoSPARQL Jena can be accessed as a library using Maven etc. from Maven Central.</p> +<pre><code><dependency> + <groupId>org.apache.jena</groupId> + <artifactId>jena-geosparql</artifactId> + <version>...</version> +</dependency> +</code></pre> <h2 id="features">Features</h2> -<p>This implementation follows the 11-052r4 OGC GeoSPARQL standard (<a href="https://www.ogc.org/standards/geosparql">https://www.ogc.org/standards/geosparql</a>). -The implementation is pure Java and does not require any set-up or configuration of any third party relational databases and geospatial extensions.</p> +<p>This implementation follows the 11-052r4 OGC GeoSPARQL standard +(<a href="https://www.ogc.org/standards/geosparql">https://www.ogc.org/standards/geosparql</a>). The implementation is pure Java +and does not require any set-up or configuration of any third party relational +databases and geospatial extensions.</p> <p>It implements the six Conformance Classes described in the GeoSPARQL document:</p> <ul> <li>Core</li> @@ -185,42 +198,49 @@ The implementation is pure Java and does not require any set-up or configuration <li>RDFS Entailment Extension</li> <li>Query Rewrite Extension</li> </ul> -<p>The WKT (as described in 11-052r4) and GML 2.0 Simple Features Profile (10-100r3) serialisations are supported. -Additional serialisations can be implemented by extending the -<code>org.apache.jena.geosparql.implementation.datatype.GeometryDatatype</code> -and registering with Jena’s <code>org.apache.jena.datatypes.TypeMapper</code>.</p> +<p>The WKT (as described in 11-052r4) and GML 2.0 Simple Features Profile +(10-100r3) serialisations are supported. Additional serialisations can be +implemented by extending the +<code>org.apache.jena.geosparql.implementation.datatype.GeometryDatatype</code> and +registering with Jena’s <code>org.apache.jena.datatypes.TypeMapper</code>.</p> <p>All three spatial relation families are supported: <em>Simple Feature</em>, <em>Egenhofer</em> and <em>RCC8</em>.</p> -<p>Indexing and caching of spatial objects and relations is performed <em>on-demand</em> during query execution. -Therefore, set-up delays should be minimal. Spatial indexing is available based on the <em>STRtree</em> from the JTS library. The <em>STRtree</em> is readonly once built and contributions of a <em>QuadTree</em> implementation are welcome.</p> -<p>Benchmarking of the implementation against Strabon and Parliament has found it to be comparable or quicker. -The benchmarking used was the Geographical query and dataset (<a href="http://geographica.di.uoa.gr/">http://geographica.di.uoa.gr/</a>).</p> +<p>Indexing and caching of spatial objects and relations is performed <em>on-demand</em> +during query execution. Therefore, set-up delays should be minimal. Spatial +indexing is available based on the <em>STRtree</em> from the JTS library. The <em>STRtree</em> +is readonly once built and contributions of a <em>QuadTree</em> implementation are +welcome.</p> +<p>Benchmarking of the implementation against Strabon and Parliament has found it +to be comparable or quicker. The benchmarking used was the Geographical query +and dataset (<a href="http://geographica.di.uoa.gr/">http://geographica.di.uoa.gr/</a>).</p> <h2 id="additional-features">Additional Features</h2> <p>The following additional features are also provided:</p> <ul> <li>Geometry properties are automatically calculated and do not need to be asserted in the dataset.</li> -<li>Conversion between EPSG spatial/coordinate reference systems is applied automatically. Therefore, mixed datasets or querying can be applied. This is reliance upon local installation of Apache SIS EPSG dataset, see <strong>Key Dependencies</strong>.</li> -<li>Units of measure are automatically converted to the appropriate units for the coordinate reference system.</li> -<li>Geometry, transformation and spatial relation results are stored in persistent and configurable time-limited caches to improve response times and reduce recalculations.</li> -<li>Dataset conversion between serialisations and spatial/coordinate reference systems. Tabular data can also be loaded, see RDF Tables project (<a href="https://github.com/galbiston/rdf-tables">https://github.com/galbiston/rdf-tables</a>).</li> +<li>Conversion between EPSG spatial/coordinate reference systems is applied +automatically. Therefore, mixed datasets or querying can be applied. This is +reliance upon local installation of Apache SIS EPSG dataset, see <strong>Key +Dependencies</strong>.</li> +<li>Units of measure are automatically converted to the appropriate units for the +coordinate reference system.</li> +<li>Geometry, transformation and spatial relation results are stored in persistent +and configurable time-limited caches to improve response times and reduce +recalculations.</li> +<li>Dataset conversion between serialisations and spatial/coordinate reference +systems. Tabular data can also be loaded, see RDF Tables project +(<a href="https://github.com/galbiston/rdf-tables">https://github.com/galbiston/rdf-tables</a>).</li> <li>Functions to test Geometry properties directly on Geometry Literals have been included for convenience.</li> </ul> -<h2 id="getting-started">Getting Started</h2> -<p>GeoSPARQL Jena can be accessed as a library using Maven etc. from Maven Central.</p> -<pre><code><dependency> - <groupId>org.apache.jena</groupId> - <artifactId>jena-geosparql</artifactId> - <version>...</version> -</dependency> -</code></pre> -<p>A HTTP server (SPARQL endpoint) using is available - for details, see the <a href="geosparql-fuseki">Geosparql Fuseki documentation</a>.</p> <h3 id="sparql-query-configuration">SPARQL Query Configuration</h3> -<p>Using the library for SPARQL querying requires one line of code. -All indexing and caching is performed during query execution and so there should be minimal delay during initialisation. -This will register the Property Functions with ARQ query engine and configures the <em>indexes</em> used for time-limited caching.</p> +<p>Using the library for SPARQL querying requires one line of code. All indexing +and caching is performed during query execution and so there should be minimal +delay during initialisation. This will register the Property Functions with ARQ +query engine and configures the <em>indexes</em> used for time-limited caching.</p> <p>There are three <em>indexes</em> which can be configured independently or switched off. -These <em>indexes</em> retain data that may be required again when a query is being executed but may not be required between different queries. -Therefore, the memory usage will grow during query execution and then recede as data is not re-used. -All the <em>indexes</em> support concurrency and can be set to a maximum size or allowed to increase capacity as required.</p> +These <em>indexes</em> retain data that may be required again when a query is being +executed but may not be required between different queries. Therefore, the +memory usage will grow during query execution and then recede as data is not +re-used. All the <em>indexes</em> support concurrency and can be set to a maximum size +or allowed to increase capacity as required.</p> <ul> <li><em>Geometry Literal</em>: Geometry objects following de-serialisation from <code>Geometry Literal</code>.</li> <li><em>Geometry Transform</em>: Geometry objects resulting from coordinate transformations between spatial reference systems.</li> @@ -249,8 +269,9 @@ The <em>indexes</em> can be configured by size, retention duration and frequency </li> </ul> <p>A variety of configuration methods are provided in -<code>org.apache.jena.geosparql.configuration.GeoSPARQLConfig</code>. -Caching of frequently used but small quantity data is also applied in several <em>registries</em>, e.g. coordinate reference systems and mathematical transformations.</p> +<code>org.apache.jena.geosparql.configuration.GeoSPARQLConfig</code>. Caching of +frequently used but small quantity data is also applied in several <em>registries</em>, +e.g. coordinate reference systems and mathematical transformations.</p> <p>Example GeoSPARQL query:</p> <pre><code>PREFIX geo: <http://www.opengis.net/ont/geosparql#> @@ -272,19 +293,23 @@ try (QueryExecution qe = QueryExecution.create(query, model)) { ResultSetFormatter.outputAsTSV(rs); } </code></pre> -<p>If your dataset needs to be separate from your application and accessed over HTTP then you probably need -the <a href="geosparql-fuseki">GeoSPARQL Fuseki project</a>. -The GeoSPARQL functionality needs to be setup in the application or Fuseki server where the dataset is located.</p> -<p>It is <strong>recommended</strong> that <code>hasDefaultGeometry</code> properties are included in the dataset to access all functionality. -It is <strong>necessary</strong> that <code>SpatialObject</code> classes are asserted or inferred (i.e. a reasoner with the GeoSPARQL schema is applied) in the dataset. -Methods to prepare a dataset can be found in <code>org.apache.jena.geosparql.configuration.GeoSPARQLOperations</code>.</p> -<h3 id="api">API</h3> -<p>The library can be used as an API in Java. -The main class to handle geometries and their spatial relations is the <code>GeometryWrapper</code>. -This can be obtained by parsing the string representation of a geometry using the appropriate datatype (e.g. WKT or GML). -Alternatively, a Literal can be extracted automatically using the <code>GeometryWrapper.extract()</code> method and registered datatypes. -The <code>GeometryWrapperFactory</code> can be used to directly construct a <code>GeometryWrapper</code>. -There is overlap between spatial relation families so repeated methods are not specified.</p> +<p>If your dataset needs to be separate from your application and accessed over +HTTP then you probably need the <a href="geosparql-assembler">GeoSPARQL Assembler</a> to +integrate with Fuseki. The GeoSPARQL functionality needs to be setup in the +application or Fuseki server where the dataset is located.</p> +<p>It is <strong>recommended</strong> that <code>hasDefaultGeometry</code> properties are included in the +dataset to access all functionality. It is <strong>necessary</strong> that <code>SpatialObject</code> +classes are asserted or inferred (i.e. a reasoner with the GeoSPARQL schema is +applied) in the dataset. Methods to prepare a dataset can be found in +<code>org.apache.jena.geosparql.configuration.GeoSPARQLOperations</code>.</p> +<h3 id="api-the-library-can-be-used-as-an-api-in-java--the-main-class-to-handle">API The library can be used as an API in Java. The main class to handle</h3> +<p>geometries and their spatial relations is the <code>GeometryWrapper</code>. This can be +obtained by parsing the string representation of a geometry using the +appropriate datatype (e.g. WKT or GML). Alternatively, a Literal can be +extracted automatically using the <code>GeometryWrapper.extract()</code> method and +registered datatypes. The <code>GeometryWrapperFactory</code> can be used to directly +construct a <code>GeometryWrapper</code>. There is overlap between spatial relation +families so repeated methods are not specified.</p> <ul> <li> <p>Parse a <code>Geometry Literal</code>: <code>GeometryWrapper geometryWrapper = WKTDatatype.INSTANCE.parse("POINT(1 1)");</code></p> @@ -314,18 +339,26 @@ There is overlap between spatial relation families so repeated methods are not s <p>The GeoSPARQL standard specifies that WKT Geometry Literals without an SRS URI are defaulted to CRS84 <code>http://www.opengis.net/def/crs/OGC/1.3/CRS84</code>.</p> <h2 id="key-dependencies">Key Dependencies</h2> <h3 id="geosparql">GeoSPARQL</h3> -<p>The OGC GeoSPARQL standard supports representing and querying geospatial data on the Semantic Web. -GeoSPARQL defines a vocabulary for representing geospatial data in RDF, and it defines an extension to the SPARQL query language for processing geospatial data. -In addition, GeoSPARQL is designed to accommodate systems based on qualitative spatial reasoning and systems based on quantitative spatial computations.</p> -<p>The GeoSPARQL standard is based upon the OGC Simple Features standard (<a href="http://www.opengeospatial.org/standards/sfa">http://www.opengeospatial.org/standards/sfa</a>) used in relational databases. +<p>The OGC GeoSPARQL standard supports representing and querying geospatial data on +the Semantic Web. GeoSPARQL defines a vocabulary for representing geospatial +data in RDF, and it defines an extension to the SPARQL query language for +processing geospatial data. In addition, GeoSPARQL is designed to accommodate +systems based on qualitative spatial reasoning and systems based on quantitative +spatial computations.</p> +<p>The GeoSPARQL standard is based upon the OGC Simple Features standard +(<a href="http://www.opengeospatial.org/standards/sfa">http://www.opengeospatial.org/standards/sfa</a>) used in relational databases. Modifications and enhancements have been made for usage with RDF and SPARQL. -The Simple Features standard, and by extension GeoSPARQL, simplify calculations to Euclidean planer geometry. -Therefore, datasets using a geographic spatial/coordinate reference system, which are based on latitude and longitude on an ellipsoid, e.g. WGS84, will have minor error introduced. -This error has been deemed acceptable due to the simplification in calculation it offers.</p> +The Simple Features standard, and by extension GeoSPARQL, simplify calculations +to Euclidean planer geometry. Therefore, datasets using a geographic +spatial/coordinate reference system, which are based on latitude and longitude +on an ellipsoid, e.g. WGS84, will have minor error introduced. This error has +been deemed acceptable due to the simplification in calculation it offers.</p> <h3 id="apache-sissis_data-environment-variable">Apache SIS/SIS_DATA Environment Variable</h3> -<p>Apache Spatial Information System (SIS) is a free software, Java language library for developing geospatial applications. -SIS provides data structures for geographic features and associated meta-data along with methods to manipulate those data structures. -The library is an implementation of GeoAPI 3.0 interfaces and can be used for desktop or server applications.</p> +<p>Apache Spatial Information System (SIS) is a free software, Java language +library for developing geospatial applications. SIS provides data structures +for geographic features and associated meta-data along with methods to +manipulate those data structures. The library is an implementation of GeoAPI +3.0 interfaces and can be used for desktop or server applications.</p> <p>A subset of the EPSG spatial/coordinate reference systems are included by default. The full EPSG dataset is not distributed due to the EPSG terms of use being incompatible with the Apache Licence. Several options are available to include the EPSG dataset by setting the <code>SIS_DATA</code> environment variable (<a href="http://sis.apache.org/epsg.html">http://sis.apache.org/epsg.html</a>).</p> @@ -338,26 +371,39 @@ implementation "org.apache.sis.non-free:sis-embedded-data:$sisVersion" <h2 id="note">Note</h2> <p>The following are implementation points that may be useful during usage.</p> <h3 id="geosparql-schema">GeoSPARQL Schema</h3> -<p>An RDF/XML schema has been published for the GeoSPARQL v1.0 standard (v1.0.1 - <a href="http://schemas.opengis.net/geosparql/1.0/geosparql_vocab_all.rdf">http://schemas.opengis.net/geosparql/1.0/geosparql_vocab_all.rdf</a>). -This can be applied to Jena Models (see <a href="/documentation/inference/">the inference documentation</a>) to provide RDFS and OWL inferencing on a GeoSPARQL conforming dataset. -However, the published schema does not conform with the standard.</p> -<p>The property <code>hasDefaultGeometry</code> is missing from the schema and instead the <code>defaultGeometry</code> property is stated.</p> -<p>This prevents RDFS inferencing being performed correctly and has been reported to the OGC Standards Tracker. -A corrected version of the schema is available in the <code>Resources</code> folder.</p> +<p>An RDF/XML schema has been published for the GeoSPARQL v1.0 standard (v1.0.1 - +<a href="http://schemas.opengis.net/geosparql/1.0/geosparql_vocab_all.rdf">http://schemas.opengis.net/geosparql/1.0/geosparql_vocab_all.rdf</a>). This can +be applied to Jena Models (see <a href="/documentation/inference/">the inference +documentation</a>) to provide RDFS and OWL inferencing +on a GeoSPARQL conforming dataset. However, the published schema does not +conform with the standard.</p> +<p>The property <code>hasDefaultGeometry</code> is missing from the schema and instead the +<code>defaultGeometry</code> property is stated.</p> +<p>This prevents RDFS inferencing being performed correctly and has been reported +to the OGC Standards Tracker. A corrected version of the schema is available in +the <code>Resources</code> folder.</p> <h3 id="spatial-relations">Spatial Relations</h3> -<p>The GeoSPARQL and Simple Features standard both define the DE-9IM intersection patterns for the three spatial relation families. -However, these patterns are not always consistent with the patterns stated by the JTS library for certain relations.</p> -<p>For example, GeoSPARQL/Simple Features use <code>TFFFTFFFT</code> <em>equals</em> relations in <em>Simple Feature</em>, <em>Egenhofer</em> and <em>RCC8</em>. -However, this does not yield the usually expected result when comparing a pair of point geometries. -The Simple Features standard states that the boundary of a point is empty. -Therefore, the boundary intersection of two points would also be empty so give a negative comparison result.</p> -<p>JTS, and other libraries, use the alternative intersection pattern of <code>T*F**FFF*</code>. -This is a combination of the <em>within</em> and <em>contains</em> relations and yields the expected results for all geometry types.</p> -<p>The spatial relations utilised by JTS have been implemented as the extension <code>spatial:equals</code> filter and property functions. -A user can also supply their own DE-9IM intersection patterns by using the <code>geof:relate</code> filter function.</p> +<p>The GeoSPARQL and Simple Features standard both define the DE-9IM intersection +patterns for the three spatial relation families. However, these patterns are +not always consistent with the patterns stated by the JTS library for certain +relations.</p> +<p>For example, GeoSPARQL/Simple Features use <code>TFFFTFFFT</code> <em>equals</em> relations in +<em>Simple Feature</em>, <em>Egenhofer</em> and <em>RCC8</em>. However, this does not yield the +usually expected result when comparing a pair of point geometries. The Simple +Features standard states that the boundary of a point is empty. Therefore, the +boundary intersection of two points would also be empty so give a negative +comparison result.</p> +<p>JTS, and other libraries, use the alternative intersection pattern of +<code>T*F**FFF*</code>. This is a combination of the <em>within</em> and <em>contains</em> relations and +yields the expected results for all geometry types.</p> +<p>The spatial relations utilised by JTS have been implemented as the extension +<code>spatial:equals</code> filter and property functions. A user can also supply their +own DE-9IM intersection patterns by using the <code>geof:relate</code> filter function.</p> <h3 id="spatial-relations-and-geometry-shapestypes">Spatial Relations and Geometry Shapes/Types</h3> -<p>The spatial relations for the three spatial families do not apply to all combinations of the geometry shapes (<code>Point</code>, <code>LineString</code>, <code>Polygon</code>) and their collections (<code>MultiPoint</code>, <code>MultiLineString</code>, <code>MultiPolygon</code>). -Therefore, some queries may not produce all the results that may initially be expected.</p> +<p>The spatial relations for the three spatial families do not apply to all +combinations of the geometry shapes (<code>Point</code>, <code>LineString</code>, <code>Polygon</code>) and their +collections (<code>MultiPoint</code>, <code>MultiLineString</code>, <code>MultiPolygon</code>). Therefore, some +queries may not produce all the results that may initially be expected.</p> <p>Some examples are:</p> <ul> <li>In some relations there may only be results when a collection of shapes is being used, e.g. two multi-points can overlap but two points cannot.</li> @@ -366,8 +412,9 @@ Therefore, some queries may not produce all the results that may initially be ex </ul> <p>Refer to pages 8-10 of 11-052r4 GeoSPARQL standard for more details.</p> <h3 id="equals-relations">Equals Relations</h3> -<p>The three equals relations (<em>sfEquals</em>, <em>ehEquals</em> and <em>rccEquals</em>) use spatial equality and not lexical equality. -Therefore, some comparisons using these relations may not be as expected.</p> +<p>The three equals relations (<em>sfEquals</em>, <em>ehEquals</em> and <em>rccEquals</em>) use spatial +equality and not lexical equality. Therefore, some comparisons using these +relations may not be as expected.</p> <p>The JTS description of <em>sfEquals</em> is:</p> <ul> <li>True if two geometries have at least one point in common and no point of either geometry lies in the exterior of the other geometry.</li> @@ -376,10 +423,11 @@ Therefore, some comparisons using these relations may not be as expected.</p> Shapes which differ in the number of points but have the same geometry are equal and will return true.</p> <p>e.g. <code>LINESTRING (0 0, 0 10)</code> and <code>LINESTRING (0 0, 0 5, 0 10)</code> are spatially equal.</p> <h3 id="query-rewrite-extension">Query Rewrite Extension</h3> -<p>The Query Rewrite Extension provides for simpler querying syntax. -<code>Feature</code> and <code>Geometry</code> can be used in spatial relations without needing the relations to be asserted in the dataset. -This also means the <code>Geometry Literal</code> does not need to be specified in the query. -In the case of <code>Features</code> this requires the <code>hasDefaultGeometry</code> property to be used in the dataset.</p> +<p>The Query Rewrite Extension provides for simpler querying syntax. <code>Feature</code> and +<code>Geometry</code> can be used in spatial relations without needing the relations to be +asserted in the dataset. This also means the <code>Geometry Literal</code> does not need +to be specified in the query. In the case of <code>Features</code> this requires the +<code>hasDefaultGeometry</code> property to be used in the dataset.</p> <p>This means the query:</p> <pre><code> ?subj geo:hasDefaultGeometry ?subjGeom . ?subjGeom geo:hasSerialization ?subjLit . @@ -392,24 +440,38 @@ In the case of <code>Features</code> this requires the <code>hasDefaultGeometry< <p>becomes:</p> <pre><code> ?subj geo:sfContains ?obj . </code></pre> -<p>Methods are available to apply the <code>hasDefaultGeometry</code> property to every <code>Geometry</code> with a single <code>hasGeometry</code> -property, see <code>org.apache.jena.geosparql.configuration.GeoSPARQLOperations</code>.</p> -<p>Depending upon the spatial relation, queries may include the specified <code>Feature</code> and <code>Geometry</code> in the results. -e.g. FeatureA is bound in a query on a dataset only containing FeatureA and GeometryA. The results FeatureA and GeometryA are returned rather than no results. -Therefore, filtering using <code>FILTER(!sameTerm(?subj, ?obj))</code> etc. may be needed in some cases. -The query rewrite functionality can be switched off in the library configuration, see <code>org.apache.jena.geosparql.configuration.GeoSPARQLConfig</code>.</p> -<p>Each dataset is assigned a Query Rewrite Index to store the results of previous tests. -There is the potential that relations are tested multiple times in a query (i.e. <em>Feature-Feature</em>, <em>Feature-Geometry</em>, <em>Geometry-Geometry</em>, <em>Geometry-Feature</em>). -Therefore, it is useful to retain the results for at least a short period of time.</p> -<p>Iterating through all combinations of spatial relations for a dataset containing <em>n</em> Geometry Literals will produce 27<em>n</em>^2 true/false results (asserting the true result statements in a dataset would be a subset). -Control is given on a dataset basis to allow choice in when and how storage of rewrite results is applied, e.g. store all found results on a small dataset but on demand for a large dataset.</p> -<p>This index can be configured on a global and individual dataset basis for the maximum size and duration until unused items are removed. -Query rewriting can be switched on independently of the indexes, i.e. query rewriting can be performed but an index is configured to not store the result.</p> +<p>Methods are available to apply the <code>hasDefaultGeometry</code> property to every +<code>Geometry</code> with a single <code>hasGeometry</code> property, see +<code>org.apache.jena.geosparql.configuration.GeoSPARQLOperations</code>.</p> +<p>Depending upon the spatial relation, queries may include the specified <code>Feature</code> +and <code>Geometry</code> in the results. e.g. FeatureA is bound in a query on a dataset +only containing FeatureA and GeometryA. The results FeatureA and GeometryA are +returned rather than no results. Therefore, filtering using +<code>FILTER(!sameTerm(?subj, ?obj))</code> etc. may be needed in some cases. The query +rewrite functionality can be switched off in the library configuration, see +<code>org.apache.jena.geosparql.configuration.GeoSPARQLConfig</code>.</p> +<p>Each dataset is assigned a Query Rewrite Index to store the results of previous +tests. There is the potential that relations are tested multiple times in a +query (i.e. <em>Feature-Feature</em>, <em>Feature-Geometry</em>, <em>Geometry-Geometry</em>, +<em>Geometry-Feature</em>). Therefore, it is useful to retain the results for at least +a short period of time.</p> +<p>Iterating through all combinations of spatial relations for a dataset containing +<em>n</em> Geometry Literals will produce 27<em>n</em>^2 true/false results (asserting the +true result statements in a dataset would be a subset). Control is given on a +dataset basis to allow choice in when and how storage of rewrite results is +applied, e.g. store all found results on a small dataset but on demand for a +large dataset.</p> +<p>This index can be configured on a global and individual dataset basis for the +maximum size and duration until unused items are removed. Query rewriting can +be switched on independently of the indexes, i.e. query rewriting can be +performed but an index is configured to not store the result.</p> <h3 id="dataset-conversion">Dataset Conversion</h3> -<p>Methods to convert datasets between serialisations and spatial/coordinate reference systems are available in: +<p>Methods to convert datasets between serialisations and spatial/coordinate +reference systems are available in: <code>org.apache.jena.geosparql..configuration.GeoSPARQLOperations</code></p> -<p>The following list shows some of the operations that can be performed. -Once these operations have been performed they can be serialised to file or stored in a Jena TDB to remove the need to reprocess.</p> +<p>The following list shows some of the operations that can be performed. Once +these operations have been performed they can be serialised to file or stored in +a Jena TDB to remove the need to reprocess.</p> <ul> <li> <p>Load a Jena Model from file: <code>Model dataModel = RDFDataMgr.loadModel("data.ttl");</code></p> @@ -436,22 +498,33 @@ Once these operations have been performed they can be serialised to file or stor <p>Create Spatial Index for a Model within a Dataset for spatial querying: <code>Dataset dataset = SpatialIndex.wrapModel(model);</code></p> </li> </ul> -<p>Other operations are available and can be applied to a Dataset containing multiple Models and in some cases files and folders. -These operations do <strong>not</strong> configure and setup the GeoSPARQL functions or indexes that are required for querying.</p> +<p>Other operations are available and can be applied to a Dataset containing +multiple Models and in some cases files and folders. These operations do +<strong>not</strong> configure and setup the GeoSPARQL functions or indexes that are required +for querying.</p> <h3 id="spatial-index">Spatial Index</h3> -<p>A Spatial Index can be created to improve searching of a dataset. -The Spatial Index is expected to be unique to the dataset and should not be shared between datasets. -Once built the Spatial Index cannot have additional items added to it.</p> -<p>A Spatial Index is required for the <code>jena-spatial</code> property functions and is optional for the GeoSPARQL spatial relations. -Only a single SRS can be used for a Spatial Index and it is recommended that datasets are converted to a single SRS, see <code>GeoSPARQLOperations</code>.</p> -<p>Setting up a Spatial Index can be done through <code>org.apache.jena.geosparql.configuration.GeoSPARQLConfig</code>. -Additional methods for building, loading and saving Spatial Indexes are provided in <code>org.apache.jena.geosparql.spatial.SpatialIndex</code>.</p> +<p>A Spatial Index can be created to improve searching of a dataset. The Spatial +Index is expected to be unique to the dataset and should not be shared between +datasets. Once built the Spatial Index cannot have additional items added to +it.</p> +<p>A Spatial Index is required for the <code>jena-spatial</code> property functions and is +optional for the GeoSPARQL spatial relations. Only a single SRS can be used for +a Spatial Index and it is recommended that datasets are converted to a single +SRS, see <code>GeoSPARQLOperations</code>.</p> +<p>Setting up a Spatial Index can be done through +<code>org.apache.jena.geosparql.configuration.GeoSPARQLConfig</code>. Additional methods +for building, loading and saving Spatial Indexes are provided in +<code>org.apache.jena.geosparql.spatial.SpatialIndex</code>.</p> <h3 id="units-uri">Units URI</h3> -<p>Spatial/coordinate reference systems use a variety of measuring systems for defining distances. -These can be specified using a URI identifier, as either URL or URN, with conversion undertaken automatically as required. -It should be noted that there is error inherent in spatial reference systems and some variation in values may occur between different systems.</p> -<p>The following table gives some examples of units that are supported (additional units can be added to the <code>UnitsRegistry</code> using the <code>javax.measure.Unit</code> API. -These URI are all in the namespace <code>http://www.opengis.net/def/uom/OGC/1.0/</code> and here use the prefix <code>units</code>.</p> +<p>Spatial/coordinate reference systems use a variety of measuring systems for +defining distances. These can be specified using a URI identifier, as either +URL or URN, with conversion undertaken automatically as required. It should be +noted that there is error inherent in spatial reference systems and some +variation in values may occur between different systems.</p> +<p>The following table gives some examples of units that are supported (additional +units can be added to the <code>UnitsRegistry</code> using the <code>javax.measure.Unit</code> API. +These URI are all in the namespace <code>http://www.opengis.net/def/uom/OGC/1.0/</code> and +here use the prefix <code>units</code>.</p> <table> <thead> <tr> @@ -482,14 +555,27 @@ These URI are all in the namespace <code>http://www.opengis.net/def/uom/OGC/1.0/ </tr> </tbody> </table> -<p>Full listing of default Units can be found in <code>org.apache.jena.geosparql.implementation.vocabulary.Unit_URI</code>.</p> +<p>Full listing of default Units can be found in +<code>org.apache.jena.geosparql.implementation.vocabulary.Unit_URI</code>.</p> <h2 id="geography-markup-language-support-gml">Geography Markup Language Support (GML)</h2> -<p>The supported GML profile is GML 2.0 Simple Features Profile (10-100r3), which is a profile of GML 3.2.1 (07-036r1). -The profile restricts the geometry shapes permitted in GML 3.2.1 to a subset, see 10-100r3 page 22. -The profile supports Points, LineString and Polygon shapes used in WKT. There are also additional shape serialisations available in the profile that do not exist in WKT or JTS to provide simplified representations which would otherwise use LineStrings or Polygons. -Curves can be described by LineStringSegment, Arc, Circle and CircleByCenterPoint. Surfaces can be formed similarly to Polygons or using Curves. -These additional shapes can be read as part of a dataset or query but will not be produced if the SRS of the shape is transformed, instead a LineString or Polygon representation will be produced.</p> -<p>Details of the GML structure for these shapes can be found in the <a href="http://www.datypic.com/sc/niem21/s-geometryPrimitives.xsd.html">geometryPrimitives.xsd</a>, <a href="http://www.datypic.com/sc/niem21/s-geometryBasic0d1d.xsd.html">geometryBasic0d1d.xsd</a>, <a href="http://www.datypic.com/sc/niem21/s-geometryBasic2d.xsd.html">geometryBasic2d.xsd</a> and <a href="http://www.datypic.com/sc/niem21/s-geometryAggregates.xsd.html">geometryAggregates.xsd</a> schemas.</p> +<p>The supported GML profile is GML 2.0 Simple Features Profile (10-100r3), which +is a profile of GML 3.2.1 (07-036r1). The profile restricts the geometry shapes +permitted in GML 3.2.1 to a subset, see 10-100r3 page 22. The profile supports +Points, LineString and Polygon shapes used in WKT. There are also additional +shape serialisations available in the profile that do not exist in WKT or JTS to +provide simplified representations which would otherwise use LineStrings or +Polygons. Curves can be described by LineStringSegment, Arc, Circle and +CircleByCenterPoint. Surfaces can be formed similarly to Polygons or using +Curves. These additional shapes can be read as part of a dataset or query but +will not be produced if the SRS of the shape is transformed, instead a +LineString or Polygon representation will be produced.</p> +<p>Details of the GML structure for these shapes can be found in the +<a href="http://www.datypic.com/sc/niem21/s-geometryPrimitives.xsd.html">geometryPrimitives.xsd</a>, +<a href="http://www.datypic.com/sc/niem21/s-geometryBasic0d1d.xsd.html">geometryBasic0d1d.xsd</a>, +<a href="http://www.datypic.com/sc/niem21/s-geometryBasic2d.xsd.html">geometryBasic2d.xsd</a> +and +<a href="http://www.datypic.com/sc/niem21/s-geometryAggregates.xsd.html">geometryAggregates.xsd</a> +schemas.</p> <p>The labelling of collections is as follows:</p> <table> <thead> @@ -518,14 +604,23 @@ These additional shapes can be read as part of a dataset or query but will not b </tbody> </table> <h2 id="apache-jena-spatial-functionswgs84-geo-predicates">Apache Jena Spatial Functions/WGS84 Geo Predicates</h2> -<p>The <code>jena-spatial</code> module contains several SPARQL functions for querying datasets using the WGS84 Geo predicates for latitude (<code>http://www.w3.org/2003/01/geo/wgs84_pos#lat</code>) and longitude (<code>http://www.w3.org/2003/01/geo/wgs84_pos#long</code>). -These <code>jena-spatial</code> functions are supported for both Geo predicates and Geometry Literals, i.e. a GeoSPARQL dataset. -Additional SPARQL filter functions have been provided to convert Geo predicate properties into WKT strings and calculate Great Circle and Euclidean distances. -The <code>jena-spatial</code>functions require setting up a Spatial Index for the target Dataset, e.g. <code>GeoSPARQLConfig.setupSpatialIndex(dataset);</code>, see Spatial Index section.</p> +<p>The <code>jena-spatial</code> module contains several SPARQL functions for querying +datasets using the WGS84 Geo predicates for latitude +(<code>http://www.w3.org/2003/01/geo/wgs84_pos#lat</code>) and longitude +(<code>http://www.w3.org/2003/01/geo/wgs84_pos#long</code>). These <code>jena-spatial</code> +functions are supported for both Geo predicates and Geometry Literals, i.e. a +GeoSPARQL dataset. Additional SPARQL filter functions have been provided to +convert Geo predicate properties into WKT strings and calculate Great Circle and +Euclidean distances. The <code>jena-spatial</code>functions require setting up a Spatial +Index for the target Dataset, +e.g. <code>GeoSPARQLConfig.setupSpatialIndex(dataset);</code>, see Spatial Index section.</p> <h3 id="supported-features">Supported Features</h3> -<p>The Geo predicate form of spatial representation is restricted to only ‘Point’ shapes in the WGS84 spatial/coordinate reference system. -The Geo predicates are properties of the <code>Feature</code> and do not use the properties and structure of the GeoSPARQL standard, including Geometry Literals. -Methods are available to convert datasets from Geo predicates to GeoSPARQL structure, see: <code>org.apache.jena.geosparql.configuration.GeoSPARQLOperations</code></p> +<p>The Geo predicate form of spatial representation is restricted to only ‘Point’ +shapes in the WGS84 spatial/coordinate reference system. The Geo predicates are +properties of the <code>Feature</code> and do not use the properties and structure of the +GeoSPARQL standard, including Geometry Literals. Methods are available to +convert datasets from Geo predicates to GeoSPARQL structure, see: +<code>org.apache.jena.geosparql.configuration.GeoSPARQLOperations</code></p> <p>The spatial relations and query re-writing of GeoSPARQL outlined previously has been implemented for Geo predicates. However, only certain spatial relations are valid for <code>Point</code> to <code>Point</code> relationships. Refer to pages 8-10 of 11-052r4 GeoSPARQL standard for more details.</p> @@ -537,18 +632,25 @@ Refer to pages 8-10 of 11-052r4 GeoSPARQL standard for more details.</p> BIND("POLYGON((...))"^^<http://www.opengis.net/ont/geosparql#wktLiteral> AS ?box) . FILTER(geof:sfContains(?box, ?point)) </code></pre> -<p>Alternatively, utilising more shapes, relations and spatial reference systems can be achieved by converting the dataset to the GeoSPARQL structure.</p> +<p>Alternatively, utilising more shapes, relations and spatial reference systems +can be achieved by converting the dataset to the GeoSPARQL structure.</p> <pre><code> ?subj geo:hasGeometry ?geom . ?geom geo:hasSerialization ?geomLit . #Coordinate order is Lon/Lat without stated SRS URI. BIND("POLYGON((...))"^^<http://www.opengis.net/ont/geosparql#wktLiteral> AS ?box) . FILTER(geof:sfContains(?box, ?geomLit)) </code></pre> -<p>Datasets can contain both Geo predicates and Geometry Literals without interference. -However, a dataset containing both types will only examine those <code>Features</code> which have Geometry Literals for spatial relations, i.e. the check for Geo predicates is a fallback when Geometry Literals aren’t found. -Therefore, it is <strong>not</strong> recommended to insert new Geo predicate properties after a dataset has been converted to GeoSPARQL structure (unless corresponding Geometry and Geometry Literals are included).</p> +<p>Datasets can contain both Geo predicates and Geometry Literals without +interference. However, a dataset containing both types will only examine those +<code>Features</code> which have Geometry Literals for spatial relations, i.e. the check +for Geo predicates is a fallback when Geometry Literals aren’t found. +Therefore, it is <strong>not</strong> recommended to insert new Geo predicate properties +after a dataset has been converted to GeoSPARQL structure (unless corresponding +Geometry and Geometry Literals are included).</p> <h3 id="filter-functions">Filter Functions</h3> -<p>These filter functions are available in the <code>http://jena.apache.org/function/spatial#</code> namespace and here use the prefix <code>spatialF</code>.</p> +<p>These filter functions are available in the +<code>http://jena.apache.org/function/spatial#</code> namespace and here use the prefix +<code>spatialF</code>.</p> <table> <thead> <tr> @@ -620,13 +722,20 @@ Therefore, it is <strong>not</strong> recommended to insert new Geo predicate pr </tbody> </table> <h3 id="property-functions">Property Functions</h3> -<p>These property functions are available in the <code>http://jena.apache.org/spatial#</code> namespace and here use the prefix <code>spatial</code>. -This is the same namespace as the <code>jena-spatial</code> functions utilise and these form direct replacements. -The subject <code>Feature</code> may be bound, to test the pattern is true, or unbound, to find all cases the pattern is true. -These property functions require a <code>Spatial Index</code> to be setup for the dataset.</p> -<p>The optional <em>?limit</em> parameter restricts the number of results returned. The default value is -1 which returns all results. No guarantee is given for ordering of results. -The optional <em>?unitsURI</em> parameter specifies the units of a distance. The default value is kilometres through the string or resource <code>http://www.opengis.net/def/uom/OGC/1.0/kilometre</code>.</p> -<p>The <code>spatial:equals</code> property function behaves the same way as the main GeoSPARQL property functions. Either, both or neither of the subject and object can be bound. A <code>Spatial Index</code> is <strong>not</strong> required for the dataset with the <code>spatial:equals</code> property function.</p> +<p>These property functions are available in the <code>http://jena.apache.org/spatial#</code> +namespace and here use the prefix <code>spatial</code>. This is the same namespace as the +<code>jena-spatial</code> functions utilise and these form direct replacements. The +subject <code>Feature</code> may be bound, to test the pattern is true, or unbound, to find +all cases the pattern is true. These property functions require a <code>Spatial Index</code> to be setup for the dataset.</p> +<p>The optional <em>?limit</em> parameter restricts the number of results returned. The +default value is -1 which returns all results. No guarantee is given for +ordering of results. The optional <em>?unitsURI</em> parameter specifies the units of +a distance. The default value is kilometres through the string or resource +<code>http://www.opengis.net/def/uom/OGC/1.0/kilometre</code>.</p> +<p>The <code>spatial:equals</code> property function behaves the same way as the main +GeoSPARQL property functions. Either, both or neither of the subject and object +can be bound. A <code>Spatial Index</code> is <strong>not</strong> required for the dataset with the +<code>spatial:equals</code> property function.</p> <table> <thead> <tr> @@ -673,10 +782,13 @@ The optional <em>?unitsURI</em> parameter specifies the units of a distance. The </tr> </tbody> </table> -<p>The Cardinal Functions find all <code>Features</code> that are present in the specified direction. -In Geographic spatial reference systems (SRS), e.g. WGS84 and CRS84, the East/West directions wrap around. -Therefore, a search is made from the shape’s edge for up to half the range of the SRS (i.e. 180 degrees in WGS84) and will continue across the East/West boundary if necessary. -In other SRS, e.g. Projected onto a flat plane, the East/West check is made from the shape’s edge to the farthest limit of the SRS range, i.e. there is no wrap around.</p> +<p>The Cardinal Functions find all <code>Features</code> that are present in the specified +direction. In Geographic spatial reference systems (SRS), e.g. WGS84 and CRS84, +the East/West directions wrap around. Therefore, a search is made from the +shape’s edge for up to half the range of the SRS (i.e. 180 degrees in WGS84) and +will continue across the East/West boundary if necessary. In other SRS, +e.g. Projected onto a flat plane, the East/West check is made from the shape’s +edge to the farthest limit of the SRS range, i.e. there is no wrap around.</p> <table> <thead> <tr> @@ -720,11 +832,14 @@ In other SRS, e.g. Projected onto a flat plane, the East/West check is made from </tbody> </table> <h2 id="geometry-property-filter-functions">Geometry Property Filter Functions</h2> -<p>The GeoSPARQL standard provides a set of properties related to geometries, see Section 8.4. -These are applied on the Geometry resource and are automatically determined if not asserted in the data. -However, it may be necessary to retrieve the properties of a Geometry Literal directly without an associated Geometry resource. -Filter functions to do this have been included as part of the <code>http://www.opengis.net/def/function/geosparql/</code> namespace as a minor variation to the GeoSPARQL standard. -The relevant functions using the <code>geof</code> prefix are:</p> +<p>The GeoSPARQL standard provides a set of properties related to geometries, see +Section 8.4. These are applied on the Geometry resource and are automatically +determined if not asserted in the data. However, it may be necessary to +retrieve the properties of a Geometry Literal directly without an associated +Geometry resource. Filter functions to do this have been included as part of +the <code>http://www.opengis.net/def/function/geosparql/</code> namespace as a minor +variation to the GeoSPARQL standard. The relevant functions using the <code>geof</code> +prefix are:</p> <table> <thead> <tr> @@ -759,8 +874,11 @@ The relevant functions using the <code>geof</code> prefix are:</p> </tr> </tbody> </table> -<p>A dataset that follows the GeoSPARQL Feature-Geometry-GeometryLiteral can have simpler SPARQL queries without needing to use these functions by taking advantage of the Query Rewriting functionality. -The <code>geof:isValid</code> filter function and <code>geo:isValid</code> property for a Geometry resource are not part of the GeoSPARQL standard but have been included as a minor variation.</p> +<p>A dataset that follows the GeoSPARQL Feature-Geometry-GeometryLiteral can have +simpler SPARQL queries without needing to use these functions by taking +advantage of the Query Rewriting functionality. The <code>geof:isValid</code> filter +function and <code>geo:isValid</code> property for a Geometry resource are not part of the +GeoSPARQL standard but have been included as a minor variation.</p> <h2 id="future-work">Future Work</h2> <ul> <li>Implementing GeoJSON as a <code>GeometryLiteral</code> serialisation (<a href="https://tools.ietf.org/html/rfc7946">https://tools.ietf.org/html/rfc7946</a>).</li> @@ -773,9 +891,11 @@ The <code>geof:isValid</code> filter function and <code>geo:isValid</code> prope <li>Taha Osman</li> </ul> <h2 id="why-use-this-implementation">Why Use This Implementation?</h2> -<p>There are several implementations of the GeoSPARQL standard. -The conformance and completeness of these implementations is difficult to ascertain and varies between features.</p> -<p>However, the following may be of interest when considering whether to use this implementation based on reviewing several alternatives.</p> +<p>There are several implementations of the GeoSPARQL standard. The conformance +and completeness of these implementations is difficult to ascertain and varies +between features.</p> +<p>However, the following may be of interest when considering whether to use this +implementation based on reviewing several alternatives.</p> <table> <thead> <tr> @@ -786,30 +906,19 @@ The conformance and completeness of these implementations is difficult to ascert <tbody> <tr> <td>Implements all six components of the GeoSPARQL standard.</td> -<td>Generally partially implement the Geometry Topology and Geometry Extensions. Do not implement the Query Rewrite Extension.</td> -</tr> -<tr> -<td>Pure Java and does not require a supporting relational database. Configuration requires a single line of code (although Apache SIS may need some setting up, see above).</td> -<td>Require setting up a database, configuring a geospatial extension and setting environment variables.</td> -</tr> -<tr> -<td>Uses Jena, which conforms to the W3C standards for RDF and SPARQL. New versions of the standards will quickly feed through.</td> -<td>Not fully RDF and SPARQL compliant, e.g. RDFS/OWL inferencing or SPARQL syntax. Adding your own schema may not produce inferences.</td> -</tr> -<tr> -<td>Automatically determines geometry properties and handles mixed cases of units or coordinate reference systems. The GeoSPARQL standard suggests this approach but does not require it.</td> -<td>Tend to produce errors or no results in these situations.</td> -</tr> -<tr> -<td>Performs indexing and caching on-demand which reduces set-up time and only performs calculations that are required.</td> -<td>Perform indexing in the data loading phase and initialisation phase, which can lead to lengthy delays (even on relatively small datasets).</td> +<td>Generally partially implement the Geometry Topology and Geometry Extensions. Do not implement the Query Rewrite</td> </tr> <tr> -<td>Uses JTS which does not truncate coordinate precision and applies spatial equality.</td> -<td>May truncate coordinate precision and apply lexical equality, which is quicker but does not comply with the GeoSPARQL standard.</td> +<td>Extension.</td> +<td></td> </tr> </tbody> </table> +<p>Pure Java and does not require a supporting relational database. Configuration requires a single line of code (although Apache SIS may need some setting up, see above).|Require setting up a database, configuring a geospatial extension and setting environment variables. +Uses Jena, which conforms to the W3C standards for RDF and SPARQL. New versions of the standards will quickly feed through.|Not fully RDF and SPARQL compliant, e.g. RDFS/OWL inferencing or SPARQL syntax. Adding your own schema may not produce inferences. +Automatically determines geometry properties and handles mixed cases of units or coordinate reference systems. The GeoSPARQL standard suggests this approach but does not require it.|Tend to produce errors or no results in these situations. +Performs indexing and caching on-demand which reduces set-up time and only performs calculations that are required.|Perform indexing in the data loading phase and initialisation phase, which can lead to lengthy delays (even on relatively small datasets). +Uses JTS which does not truncate coordinate precision and applies spatial equality.|May truncate coordinate precision and apply lexical equality, which is quicker but does not comply with the GeoSPARQL standard.</p> </div> diff --git a/content/documentation/index.xml b/content/documentation/index.xml index 0931068..bdb869f 100644 --- a/content/documentation/index.xml +++ b/content/documentation/index.xml @@ -123,9 +123,9 @@ Fuseki comes in in two forms, a single system &ldquo;webapp&rdquo;, comb <guid>https://jena.apache.org/documentation/geosparql/</guid> <description>An implementation of GeoSPARQL 1.0 standard for SPARQL query or API. -An integration with Fuseki is available but attention should be paid to the contents of this page to understand supported features. -Features This implementation follows the 11-052r4 OGC GeoSPARQL standard (https://www.ogc.org/standards/geosparql). The implementation is pure Java and does not require any set-up or configuration of any third party relational databases and geospatial extensions. -It implements the six Conformance Classes described in the GeoSPARQL document:</description> +Integration with Fuseki is provided either by using the GeoSPARQL assembler or using the self-contained original jena-fuseki-geosparql. In either case, this page describes the GeoSPARQL supported features. +Getting Started GeoSPARQL Jena can be accessed as a library using Maven etc. from Maven Central. +&lt;dependency&gt; &lt;groupId&gt;org.apache.jena&lt;/groupId&gt; &lt;artifactId&gt;jena-geosparql&lt;/artifactId&gt; &lt;version&gt;...&lt;/version&gt; &lt;/dependency&gt; Features This implementation follows the 11-052r4 OGC GeoSPARQL standard (https://www.ogc.org/standards/geosparql). The implementation is pure Java and does not require any set-up or configuration of any third party relational databases and geospatial ex [...] </item> <item> @@ -863,15 +863,29 @@ The relevant SPARQL standards are: </item> <item> + <title>GeoSPARQL Assembler</title> + <link>https://jena.apache.org/documentation/geosparql/geosparql-assembler.html</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://jena.apache.org/documentation/geosparql/geosparql-assembler.html</guid> + <description>Details of the GeoSPARQL support are proivded on the GeoSPARQL page. +The assembler for GeoSPARQL support is part of the jena-geosparql artifact and miost be on the Fuseki server classpath. +&lt;dependency&gt; &lt;groupId&gt;org.apache.jena&lt;/groupId&gt; &lt;artifactId&gt;jena-geosparql&lt;/artifactId&gt; &lt;version&gt;...&lt;/version&gt; &lt;/dependency&gt; or download the binary from the Maven central repository org/apache/jena/jena-geosparql +The GeoSPARQL assembler can be used in a Fuseki configuration file. +This example is of a read-only +PREFIX fuseki: &lt;http://jena.apache.org/fuseki#&gt; PREFIX rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; PREFIX rdfs: &lt;http://www.</description> + </item> + + <item> <title>GeoSPARQL Fuseki</title> <link>https://jena.apache.org/documentation/geosparql/geosparql-fuseki.html</link> <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://jena.apache.org/documentation/geosparql/geosparql-fuseki.html</guid> - <description>This application provides a HTTP server compliant with the GeoSPARQL standard. It uses the embedded server Fuseki and provides additional parameters for dataset loading. -The project uses the GeoSPARQL implementation from the GeoSPARQL Jena module, which includes a range of functions in addition to those from the GeoSPARQL standard. -Currently, there is no GUI interface as provided in the Fuseki distribution. -The intended usage is to specify a TDB folder (either TDB1 or TDB2, created if required) for persistent storage of the dataset.</description> + <description>This application provides a HTTP server compliant with the GeoSPARQL standard. +GEoSPARQL can also be ingtegrated with Fuseki using the GeoSPARQL assembler with a general Fuseki server. +jena-fuseki-geosparql GeoSPARQL Fuseki can be accessed as an embedded server using Maven etc. from Maven Central or run from the command line. SPARQL queries directly on Jena Datasets and Models can be done using the GeoSPARQL Jena module. +&lt;dependency&gt; &lt;groupId&gt;org.apache.jena&lt;/groupId&gt; &lt;artifactId&gt;jena-fuseki-geosparql&lt;/artifactId&gt; &lt;version&gt;...&lt;/version&gt; &lt;/dependency&gt; or download the binary from the Maven central repository org/apache/jena/jena-fuseki-geosparql</description> </item> <item> @@ -967,8 +981,8 @@ Throughout this document, the prefix eye: stands for the URL http://jena.</descr <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://jena.apache.org/documentation/query/text-query.html</guid> - <description>This extension to ARQ combines SPARQL and full text search via Lucene. ElasticSearch It gives applications the ability to perform indexed full text searches within SPARQL queries. Here is a version compatibility table: - Jena Lucene Solr ElasticSearch upto 3.2.0 5.x or 6.x 5.x or 6.x not supported 3.3.0 - 3.9.0 6.4.x not supported 5.</description> + <description>This extension to ARQ combines SPARQL and full text search via Lucene. It gives applications the ability to perform indexed full text searches within SPARQL queries. Here is a version compatibility table: + Jena Lucene Solr ElasticSearch upto 3.2.0 5.x or 6.x 5.x or 6.x not supported 3.3.0 - 3.9.0 6.4.x not supported 5.2.2 - 5.</description> </item> <item> diff --git a/content/documentation/inference/data/owlDemoData.xml b/content/documentation/inference/data/owlDemoData.rdf similarity index 100% rename from content/documentation/inference/data/owlDemoData.xml rename to content/documentation/inference/data/owlDemoData.rdf diff --git a/content/documentation/inference/data/owlDemoSchema.xml b/content/documentation/inference/data/owlDemoSchema.rdf similarity index 100% rename from content/documentation/inference/data/owlDemoSchema.xml rename to content/documentation/inference/data/owlDemoSchema.rdf diff --git a/content/documentation/inference/index.html b/content/documentation/inference/index.html index 5bac8bf..3cb6a28 100644 --- a/content/documentation/inference/index.html +++ b/content/documentation/inference/index.html @@ -745,27 +745,27 @@ Reasoner reasoner = RDFSRuleReasonerFactory.theInstance()Create(config); <p>As a complete worked example let us create a simple RDFS schema, some instance data and use an instance of the RDFS reasoner to query the two.</p> <p>We shall use a trivial schema:</p> -<pre><code> <rdf:Description rdf:about="&amp;eg;mum"> - <rdfs:subPropertyOf rdf:resource="&amp;eg;parent"/> +<pre><code> <rdf:Description rdf:about="eg:mum"> + <rdfs:subPropertyOf rdf:resource="eg:parent"/> </rdf:Description> - <rdf:Description rdf:about="&amp;eg;parent"> - <rdfs:range rdf:resource="&amp;eg;Person"/> - <rdfs:domain rdf:resource="&amp;eg;Person"/> + <rdf:Description rdf:about="eg:parent"> + <rdfs:range rdf:resource="eg:Person"/> + <rdfs:domain rdf:resource="eg:Person"/> </rdf:Description> - <rdf:Description rdf:about="&amp;eg;age"> - <rdfs:range rdf:resource="&amp;xsd;integer" /> + <rdf:Description rdf:about="eg:age"> + <rdfs:range rdf:resource="xsd:integer" /> </rdf:Description> </code></pre> <p>This defines a property <code>parent</code> from <code>Person</code> to <code>Person</code>, a sub-property <code>mum</code> of <code>parent</code> and an integer-valued property <code>age</code>.</p> <p>We shall also use the even simpler instance file:</p> -<pre><code> &lt;Teenager rdf:about="&amp;eg;colin"> - &lt;mum rdf:resource="&amp;eg;rosy" /> - &lt;age>13&lt;/age> - &lt;/Teenager> +<pre><code> <Teenager rdf:about="eg:colin"> + <mum rdf:resource="eg:rosy" /> + <age>13</age> + </Teenager> </code></pre> <p> Which defines a <code>Teenager</code> called <code>colin</code> who has a <code>mum</code> @@ -1154,8 +1154,8 @@ configuration still leaves something to be desired and will the subject of futur <p>[<a href="#owl">OWL Index</a>] [<a href="#index">Main Index</a>]</p> <h3 id="OWLexamples">OWL Example</h3> <p>As an example of using the OWL inference support, consider the sample schema - and data file in the data directory - <a href="data/owlDemoSchema.xml">owlDemoSchema.xml</a> - and <a href="data/owlDemoData.xml">owlDemoData.xml</a>. </p> + and data file in the data directory - <a href="data/owlDemoSchema.rdf">owlDemoSchema.rdf</a> + and <a href="data/owlDemoData.rdf">owlDemoData.rdf</a>. </p> <p>The schema file shows a simple, artificial ontology concerning computers which defines a GamingComputer as a Computer which includes at least one bundle of type GameBundle and a component with the value gamingGraphics. </p> @@ -1164,7 +1164,7 @@ configuration still leaves something to be desired and will the subject of futur and "<code>bigName42</code>".</p> <p>We can create an instance of the OWL reasoner, specialized to the demo schema and then apply that to the demo data to obtain an inference model, as follows:</p> -<pre><code>Model schema = RDFDataMgr.loadModel("file:data/owlDemoSchema.owl"); +<pre><code>Model schema = RDFDataMgr.loadModel("file:data/owlDemoSchema.rdf"); Model data = RDFDataMgr.loadModel("file:data/owlDemoData.rdf"); Reasoner reasoner = ReasonerRegistry.getOWLReasoner(); reasoner = reasoner.bindSchema(schema); @@ -1465,10 +1465,10 @@ URL for a rule file use one of the keywords So an example complete rule file which includes the RDFS rules and defines a single extra rule is: <pre><code># Example rule file -@prefix pre: &lt;http://jena.hpl.hp.com/prefix#&gt;. -@include &lt;RDFS&gt;. +@prefix pre: <http://jena.hpl.hp.com/prefix#>. +@include <RDFS>. -[rule1: (?f pre:father ?a) (?u pre:brother ?f) -&gt; (?u pre:uncle ?a)] +[rule1: (?f pre:father ?a) (?u pre:brother ?f) -> (?u pre:uncle ?a)] </code></pre> </p> <p>[<a href="#rules">Rule Index</a>] [<a href="#index">Main Index</a>]</p> @@ -1566,7 +1566,7 @@ triple(s1, p1, o1) :- triple(sb1, pb1, ob1), ... can exploit all of the results of the subgoals involved in previous queries. In essence we build up a closure of the data set in response to successive queries. The <code>reset()</code> operation on the inference model will force these tabled - results to be discarded, thus saving memory and the expense of response time + results to be discarded, thus saving memory at the expense of response time for future queries.</p> <p>When the inference Model is updated by adding or removing statements all tabled results are discarded by an internal <code>reset()</code> and the next query @@ -1724,7 +1724,7 @@ Reasoner reasoner = new GenericRuleReasoner(rules);</pre> <p>Each primitive can optionally be used in either the rule body, the rule head or both. If used in the rule body then as well as binding variables (and any procedural side-effects like printing) the primitive can act as a test - if - it returns false the rule will not match. Primitives using in the rule head + it returns false the rule will not match. Primitives used in the rule head are only used for their side effects.</p> <p>The set of builtin primitives available at the time writing are:</p> <table width="90%" border="1" cellspacing="0" cellpadding="0"> @@ -2079,7 +2079,7 @@ InfModel inf = ModelFactory.createInfModel(reasoner, data); computing all possible answers when an application might only want a few.]</p> <p> A simple example of this is that the <em>interesting</em> bits of RDFS - can be captured by enabled TransitiveClosureCaching and including just the + can be captured by enabling TransitiveClosureCaching and including just the four core rules:</p> <pre> [rdfs2: (?x ?p ?y), (?p rdfs:domain ?c) -> (?x rdf:type ?c)] @@ -2098,7 +2098,7 @@ InfModel inf = ModelFactory.createInfModel(reasoner, data); <p>Validation rules take the general form:</p> <pre>(?v rb:validation on()) ... -> [ (?X rb:violation error('summary', 'description', args)) <- ...) ] .</pre> -<p>First the validate call with "switch on" validation by insert an +<p>The validation calls can be "switched on" by inserting an additional triple into the graph of the form:</p> <pre>_:anon rb:validation on() .</pre> <p>This makes it possible to build rules, such as the template above, which are diff --git a/content/documentation/query/text-query.html b/content/documentation/query/text-query.html index cdbfb86..bf6de5d 100644 --- a/content/documentation/query/text-query.html +++ b/content/documentation/query/text-query.html @@ -178,7 +178,6 @@ <p>This extension to ARQ combines SPARQL and full text search via <a href="https://lucene.apache.org">Lucene</a>. -<a href="https://www.elastic.co">ElasticSearch</a> It gives applications the ability to perform indexed full text searches within SPARQL queries. Here is a version compatibility table:</p> <table> @@ -216,7 +215,7 @@ searches within SPARQL queries. Here is a version compatibility table:</p> <td>6.8.6</td> </tr> <tr> -<td>4.0.0</td> +<td>4.0.0 - current</td> <td>8.8.x</td> <td>not supported</td> <td>not supported</td> diff --git a/content/documentation/query/writing_propfuncs.html b/content/documentation/query/writing_propfuncs.html index 40c6395..e93099a 100644 --- a/content/documentation/query/writing_propfuncs.html +++ b/content/documentation/query/writing_propfuncs.html @@ -226,13 +226,13 @@ of data.</p> <a href="/documentation/javadoc/arq/org/apache/jena/sparql/pfunction/PropertyFunctionFactory.html"><code>org.apache.jena.sparql.pfunction.PropertyFunctionFactory</code></a> (shown later), you can register a function as follows:</p> <pre><code>final PropertyFunctionRegistry reg = PropertyFunctionRegistry.chooseRegistry(ARQ.getContext()); -reg.put("urn:ex:fn#example", new ExamplePropertyFunctionFactory); +reg.put("urn:ex:fn#example", new ExamplePropertyFunctionFactory()); PropertyFunctionRegistry.set(ARQ.getContext(), reg); </code></pre> <p>The only difference between global and dataset-specific registration is where the <code>Context</code> object comes from:</p> -<pre><code>final Dataset ds = DatasetFactory.createMem(); +<pre><code>final Dataset ds = DatasetFactory.createGeneral(); final PropertyFunctionRegistry reg = PropertyFunctionRegistry.chooseRegistry(ds.getContext()); -reg.put("urn:ex:fn#example", new ExamplePropertyFunctionFactory); +reg.put("urn:ex:fn#example", new ExamplePropertyFunctionFactory()); PropertyFunctionRegistry.set(ds.getContext(), reg); </code></pre> <p>Note that @@ -249,7 +249,7 @@ regardless of their arguments we could do so as follows:</p> return new PFuncSimple() { @Override - public QueryIterator execEvaluated(final Binding parent, final Node subject, final Node predicate, final Node object, final ExecutionContext execCxt) + public QueryIterator execEvaluated(final Binding parent, final Node subject, final Node predicate, final Node object, final ExecutionContext execCtx) { return QueryIterNullIterator.create(execCtx); } diff --git a/content/download/index.html b/content/download/index.html index 024d5ab..528c856 100644 --- a/content/download/index.html +++ b/content/download/index.html @@ -184,14 +184,14 @@ WAR file packaging):</p> </thead> <tbody> <tr> -<td><a href="[preferred]jena/binaries/apache-jena-fuseki-4.2.0.tar.gz">apache-jena-fuseki-4.2.0.tar.gz</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-fuseki-4.2.0.tar.gz.sha512">SHA512</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-fuseki-4.2.0.tar.gz.asc">PGP</a></td> +<td><a href="[preferred]jena/binaries/apache-jena-fuseki-4.3.2.tar.gz">apache-jena-fuseki-4.3.2.tar.gz</a></td> +<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-fuseki-4.3.2.tar.gz.sha512">SHA512</a></td> +<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-fuseki-4.3.2.tar.gz.asc">PGP</a></td> </tr> <tr> -<td><a href="[preferred]jena/binaries/apache-jena-fuseki-4.2.0.zip">apache-jena-fuseki-4.2.0.zip</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-fuseki-4.2.0.zip.sha512">SHA512</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-fuseki-4.2.0.zip.asc">PGP</a></td> +<td><a href="[preferred]jena/binaries/apache-jena-fuseki-4.3.2.zip">apache-jena-fuseki-4.3.2.zip</a></td> +<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-fuseki-4.3.2.zip.sha512">SHA512</a></td> +<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-fuseki-4.3.2.zip.asc">PGP</a></td> </tr> </tbody> </table> @@ -207,9 +207,9 @@ Source release: this forms the official release of Apache Jena. All binaries art </thead> <tbody> <tr> -<td><a href="[preferred]jena/source/jena-4.2.0-source-release.zip">jena-4.2.0-source-release.zip</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/source/jena-4.2.0-source-release.zip.sha512">SHA512</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/source/jena-4.2.0-source-release.zip.asc">PGP</a></td> +<td><a href="[preferred]jena/source/jena-4.3.2-source-release.zip">jena-4.3.2-source-release.zip</a></td> +<td align="center"><a href="https://downloads.apache.org/jena/source/jena-4.3.2-source-release.zip.sha512">SHA512</a></td> +<td align="center"><a href="https://downloads.apache.org/jena/source/jena-4.3.2-source-release.zip.asc">PGP</a></td> </tr> </tbody> </table> @@ -225,14 +225,14 @@ The binary distribution of libraries contains the APIs, SPARQL engine, the TDB n </thead> <tbody> <tr> -<td><a href="[preferred]jena/binaries/apache-jena-4.2.0.tar.gz">apache-jena-4.2.0.tar.gz</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-4.2.0.tar.gz.sha512">SHA512</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-4.2.0.tar.gz.asc">PGP</a></td> +<td><a href="[preferred]jena/binaries/apache-jena-4.3.2.tar.gz">apache-jena-4.3.2.tar.gz</a></td> +<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-4.3.2.tar.gz.sha512">SHA512</a></td> +<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-4.3.2.tar.gz.asc">PGP</a></td> </tr> <tr> -<td><a href="[preferred]jena/binaries/apache-jena-4.2.0.zip">apache-jena-4.2.0.zip</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-4.2.0.zip.sha512">SHA512</a></td> -<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-4.2.0.zip.asc">PGP</a></td> +<td><a href="[preferred]jena/binaries/apache-jena-4.3.2.zip">apache-jena-4.3.2.zip</a></td> +<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-4.3.2.zip.sha512">SHA512</a></td> +<td align="center"><a href="https://downloads.apache.org/jena/binaries/apache-jena-4.3.2.zip.asc">PGP</a></td> </tr> </tbody> </table> diff --git a/content/index.xml b/content/index.xml index 4f64064..576be46 100644 --- a/content/index.xml +++ b/content/index.xml @@ -143,9 +143,9 @@ Fuseki comes in in two forms, a single system &ldquo;webapp&rdquo;, comb <guid>https://jena.apache.org/documentation/geosparql/</guid> <description>An implementation of GeoSPARQL 1.0 standard for SPARQL query or API. -An integration with Fuseki is available but attention should be paid to the contents of this page to understand supported features. -Features This implementation follows the 11-052r4 OGC GeoSPARQL standard (https://www.ogc.org/standards/geosparql). The implementation is pure Java and does not require any set-up or configuration of any third party relational databases and geospatial extensions. -It implements the six Conformance Classes described in the GeoSPARQL document:</description> +Integration with Fuseki is provided either by using the GeoSPARQL assembler or using the self-contained original jena-fuseki-geosparql. In either case, this page describes the GeoSPARQL supported features. +Getting Started GeoSPARQL Jena can be accessed as a library using Maven etc. from Maven Central. +&lt;dependency&gt; &lt;groupId&gt;org.apache.jena&lt;/groupId&gt; &lt;artifactId&gt;jena-geosparql&lt;/artifactId&gt; &lt;version&gt;...&lt;/version&gt; &lt;/dependency&gt; Features This implementation follows the 11-052r4 OGC GeoSPARQL standard (https://www.ogc.org/standards/geosparql). The implementation is pure Java and does not require any set-up or configuration of any third party relational databases and geospatial ex [...] </item> <item> @@ -915,15 +915,29 @@ The relevant SPARQL standards are: </item> <item> + <title>GeoSPARQL Assembler</title> + <link>https://jena.apache.org/documentation/geosparql/geosparql-assembler.html</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://jena.apache.org/documentation/geosparql/geosparql-assembler.html</guid> + <description>Details of the GeoSPARQL support are proivded on the GeoSPARQL page. +The assembler for GeoSPARQL support is part of the jena-geosparql artifact and miost be on the Fuseki server classpath. +&lt;dependency&gt; &lt;groupId&gt;org.apache.jena&lt;/groupId&gt; &lt;artifactId&gt;jena-geosparql&lt;/artifactId&gt; &lt;version&gt;...&lt;/version&gt; &lt;/dependency&gt; or download the binary from the Maven central repository org/apache/jena/jena-geosparql +The GeoSPARQL assembler can be used in a Fuseki configuration file. +This example is of a read-only +PREFIX fuseki: &lt;http://jena.apache.org/fuseki#&gt; PREFIX rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; PREFIX rdfs: &lt;http://www.</description> + </item> + + <item> <title>GeoSPARQL Fuseki</title> <link>https://jena.apache.org/documentation/geosparql/geosparql-fuseki.html</link> <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://jena.apache.org/documentation/geosparql/geosparql-fuseki.html</guid> - <description>This application provides a HTTP server compliant with the GeoSPARQL standard. It uses the embedded server Fuseki and provides additional parameters for dataset loading. -The project uses the GeoSPARQL implementation from the GeoSPARQL Jena module, which includes a range of functions in addition to those from the GeoSPARQL standard. -Currently, there is no GUI interface as provided in the Fuseki distribution. -The intended usage is to specify a TDB folder (either TDB1 or TDB2, created if required) for persistent storage of the dataset.</description> + <description>This application provides a HTTP server compliant with the GeoSPARQL standard. +GEoSPARQL can also be ingtegrated with Fuseki using the GeoSPARQL assembler with a general Fuseki server. +jena-fuseki-geosparql GeoSPARQL Fuseki can be accessed as an embedded server using Maven etc. from Maven Central or run from the command line. SPARQL queries directly on Jena Datasets and Models can be done using the GeoSPARQL Jena module. +&lt;dependency&gt; &lt;groupId&gt;org.apache.jena&lt;/groupId&gt; &lt;artifactId&gt;jena-fuseki-geosparql&lt;/artifactId&gt; &lt;version&gt;...&lt;/version&gt; &lt;/dependency&gt; or download the binary from the Maven central repository org/apache/jena/jena-fuseki-geosparql</description> </item> <item> @@ -1061,8 +1075,8 @@ Throughout this document, the prefix eye: stands for the URL http://jena.</descr <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://jena.apache.org/documentation/query/text-query.html</guid> - <description>This extension to ARQ combines SPARQL and full text search via Lucene. ElasticSearch It gives applications the ability to perform indexed full text searches within SPARQL queries. Here is a version compatibility table: - Jena Lucene Solr ElasticSearch upto 3.2.0 5.x or 6.x 5.x or 6.x not supported 3.3.0 - 3.9.0 6.4.x not supported 5.</description> + <description>This extension to ARQ combines SPARQL and full text search via Lucene. It gives applications the ability to perform indexed full text searches within SPARQL queries. Here is a version compatibility table: + Jena Lucene Solr ElasticSearch upto 3.2.0 5.x or 6.x 5.x or 6.x not supported 3.3.0 - 3.9.0 6.4.x not supported 5.2.2 - 5.</description> </item> <item> diff --git a/content/sitemap.xml b/content/sitemap.xml index 54c16be..18b91f1 100644 --- a/content/sitemap.xml +++ b/content/sitemap.xml @@ -74,7 +74,7 @@ <url> <loc>https://jena.apache.org/documentation/geosparql/</loc> - <lastmod>2021-11-05T16:04:36+00:00</lastmod> + <lastmod>2021-12-27T19:32:13+00:00</lastmod> </url> <url> @@ -89,7 +89,7 @@ <url> <loc>https://jena.apache.org/download/</loc> - <lastmod>2021-11-01T08:15:56+00:00</lastmod> + <lastmod>2021-12-18T13:39:19+00:00</lastmod> </url> <url> @@ -244,7 +244,7 @@ <url> <loc>https://jena.apache.org/documentation/query/writing_propfuncs.html</loc> - <lastmod>2021-09-26T09:53:50+01:00</lastmod> + <lastmod>2021-12-09T12:42:21-05:00</lastmod> </url> <url> @@ -324,12 +324,12 @@ <url> <loc>https://jena.apache.org/documentation.html</loc> - <lastmod>2021-12-05T23:14:11+00:00</lastmod> + <lastmod>2021-12-27T19:32:13+00:00</lastmod> </url> <url> <loc>https://jena.apache.org/download.html</loc> - <lastmod>2021-11-01T08:15:56+00:00</lastmod> + <lastmod>2021-12-18T13:39:19+00:00</lastmod> </url> <url> @@ -438,8 +438,13 @@ </url> <url> + <loc>https://jena.apache.org/documentation/geosparql/geosparql-assembler.html</loc> + <lastmod>2021-12-27T19:32:13+00:00</lastmod> + </url> + + <url> <loc>https://jena.apache.org/documentation/geosparql/geosparql-fuseki.html</loc> - <lastmod>2021-11-05T16:04:36+00:00</lastmod> + <lastmod>2021-12-27T19:32:13+00:00</lastmod> </url> <url> @@ -519,7 +524,7 @@ <url> <loc>https://jena.apache.org/documentation/query/text-query.html</loc> - <lastmod>2021-02-19T15:39:55+13:00</lastmod> + <lastmod>2021-12-09T14:39:47+00:00</lastmod> </url> <url> @@ -689,7 +694,7 @@ <url> <loc>https://jena.apache.org/documentation/inference/</loc> - <lastmod>2021-04-19T17:12:45+01:00</lastmod> + <lastmod>2021-11-30T09:38:00-07:00</lastmod> </url> <url>