I've reloaded the GND dataset at http://zbw.eu/beta/sparql/gnd/query with
4.5.0-SNAPSHOT. The sources were a 133G .nt.gz file, plus several small .ttl
files with ontology etc. I loaded the large one with tdb2.xloader, and
immediately after that the smaller ones with tdb2.tdbloader (see
On 21/02/2022 08:27, Neubert, Joachim wrote:
I've reloaded the GND dataset at http://zbw.eu/beta/sparql/gnd/query with
4.5.0-SNAPSHOT. The sources were a 133G .nt.gz file, plus several small .ttl
files with ontology etc. I loaded the large one with tdb2.xloader, and
immediately after that
I have a vague memory of running into this issue in the past, Lorenz. The
wikidata RDF serialization does not conform strictly to the OGC GeoSPARQL
data model nor do the geospatial access methods of the blazegraph extension
attempt to exhibit any of the standards compliant features. That's
Hi,
we can use this as an complementary thread for the ongoing "loading
Wikidata" threads, this time with focus on the geospatial part.
Joachim already did the same for the text index and it works as
expected, though still loading time could be improved.
For the geospatial index things
On 21/02/2022 09:07, Lorenz Buehmann wrote:
Any experience or comments so far?
Using SubsystemLifecycle, could make the conversions by
GeoSPARQLOperations.convertGeoPredicates
extensible.
Andy
But having coordinate location (P625), located on astronomical body
(P376) as
This mail of yesterday didn't get through - here again.
The data of the broken load is temporarily linked from
http://134.245.93.72/beta/tmp.
I've now invoked
/opt/jena/bin/tdb2.tdbloader --loader=parallel
--loc=/zbw/var/lib/fuseki/databases/temp ../var/gnd/2021-11/src/GND.utf8.ttl.gz
