graphDB | database abstraction layer that behaves as a graph database | Database library

Don't know about a specific python library for this, but you can use the repository statements endpoint to upload your data.

Something like this seems to work:

Answer found here: https://community.neo4j.com/t/database-offline-and-will-not-restart/27914/5

The index issue seems to have disappeared as part of this solution. For some reason the neo4j system account no longer had access to write to the log files or anything else in the data folder. This was resolved using:

When you call iterate() it returns a GraphTraversal and you can then call toStream() on that, but it will always be empty. You should omit the iterate() if you intend to return values to your Stream. In short, simply do values().toStream().

Without too much additional detail it is hard to provide exact modeling advice , but in general one of the advantages of using a graph databases is that edges are first class citizens and allow for properties on edges. A common use case for this would be something like PERSON - purchases -> Product where you might have a purchase_date on the purchases edge to represent the date of the purchase, as someone might buy the same thing multiple times.

I am not sure what exactly you mean by that a vast majority of GraphDB data be derived data as you can use graphs to derive and infer data/relationships based on the connections but they do fully support storing data in them as well.

Given that its in memory, what happens when it goes down? - Amazon Neptune (and most other DBS) use a buffer cache to store some data in memory, but that data is also persisted to disk, so if the instance goes down, there is no problem with recovering it from the durable storage.

An additional question, is it common practice to expose the gremlin API directly to users, or should there always be a GraphQL (or other) API in front of it? - Just as with any database, I would not recommend exposing the Gremlin API directly to consumers, as doing so comes with a whole host of potential security risks. Generally, the underlying data store of any application should be transparent to the users. They should be interacting with an interface like REST/GraphQL that is designed to answer business related questions and not really know or care that there is a graph database backing those requests.

The RDFS ruleset is required for the specific example and dataset. You could absolutely use it with empty ruleset if needed.

The functionality is useful if you want to filter out specific property chains. For examle:

The issue comes from an update in the base image. From a few weeks adopt switched to alpine 3.14 which has some issues with older container runtime (runc). The issue can be seen in the release notes: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0

Updating your Docker will fix the issue. However, if you don't wish to update your Docker, there's a workaround.

Some additional info: The cause of the issue is that for some reason containers running in older docker versions and alpine 3.14 seem to have issues with the test flag "-x" so an if [ -x /opt/java/openjdk/bin/java ] returns false, although java is there and is executable.

You can workaround this for now by

1. Pull the GraphDB distribution
2. Unzip it
3. Open "setvars.in.sh" in the bin folder
4. Find and remove the if block around line 32

if [ ! -x "$JAVA" ]; then echo "Could not find any executable java binary. Please install java in your PATH or set JAVA_HOME" exit 1 fi

1. Zip it again and provide it in the Dockerfile without pulling it from maven.ontotext.com

Passing it to the Dockerfile is done with 'ADD' You can check the GraphDB free version's Dockerfile for a reference on how to pass the zip file to the Dockerfile https://github.com/Ontotext-AD/graphdb-docker/blob/master/free-edition/Dockerfile

You need to explicitly flush the NamedTemporaryFile before anything else tries to use it through a different handle (e.g. by receiving the name and opening it). Add:

IN_HAS_NEXT means, that the engine is evaluating the solutions from the binding set iterator (hasNext()). In simple words this is the "where" part of the update query which prepares the results before commit. It might seems stuck if there are many returned results. If you are still experiencing problem with this query you can send an email, describing the problem, to graphdb-support@ontotext.com