grakn | Grakn Core : The Knowledge Graph | Graph Database library

It would help to define what you mean by "online" - if it means what I think it does (keeping valid data/queryable data as you load), you should be able to see newly loaded data as soon as a transaction commits.

So, you can load data (https://dev.grakn.ai/docs/query/insert-query), and on commit you can see the committed data, and you can modify data (your link), which can modify committed data.

In general, you want to load data in many transactions, which allows you see in-progress data sets being loaded in an "online" manner.

Grakn 1.8 adds "the ability to export and import date and schema to 1.8 grakn in order to support migration into newer versions of grakn." Grakn release 1.8.1

Hence to copy an entire keyspace you can:

1. Start the grakn server: grakn server start
2. Create a new empty keyspace using the same schema as the original: grakn console -k --f
3. Export data from the original keyspace: grakn server export exported_data.grakn
4. Import the data into the new keyspace: grakn server import exported_data.grakn

The docs relevant to this question are found here: https://dev.grakn.ai/docs/concept-api/overview

Before the Grakn clients version 1.8.0, concepts always retained a connection to the server directly. This enabled users to do calls into the Grakn server using using methods like subs() and keys().

As of >1.8.0, client-side concepts are either Local concepts or Remote concepts:

• Local concepts are simple value objects that retain Id, Label, Type, Value (for attributes) and other state they directly contain. Clients return Local in general from queries and other operations.
• Remote concepts are obtained from Local concepts by passing a transaction to the concept using concept.asRemote(tx). This re-enables them to connect to the server as in the older versions of the grakn clients.

This change was made to ensure users are aware which operations are potentially expensive and require trips over the network, and which are fast and operate on local values only.

I've found creating separate scripts that hold common operations is a good workflow for me. For example, if you have a common schema shared between different keyspaces and different data for those make a schema.gql file and your multiple data.gql files. They can then be glued together with a shell script if typing that in gets tedious.

There are two possible reasons for this:

• JVM is unable to allocate 4G of RAM because it's occupied by something else. However, as you've said only 20% or RAM is used, this is an unlikely reason.
• 32-bit JVM are unable to address more than 4GB of RAM 1, so you should check if it applies to you and reinstall your JVM to be 64-bit if it does.

The answers of a get can be sorted using sort as follows:

Grakn uses Java 8 whereas you have Java 11. You can fix this by installing the JDK for Java 8, you should be able to find it for your system here.

Then, you need to make sure Java 8 can be found. On mac/unix:

In Grakn, these many-to-one connections (where the "many" is dynamic) can be stored as the relation instances themselves.

For example, suppose you have a family with a parent who has some children, but we don't know how many there are, and new children can be added at any time.

Then you would

Grakn assigns an auto-generated id to each instance. Although this id is generated by Grakn solely for internal use, it is indeed possible to find an instance with its Grakn id. To do so, we use the id keyword followed by the id assigned to the instance by Grakn.