Where does the name “OWLIM” (the former GraphDB name) come from?

The name originally came from the term “OWL In Memory” and was fitting for what later became OWLIM-Lite. However, OWLIM-SE used a transactional, index-based file-storage layer where “In Memory” was no longer appropriate. Nevertheless, the name stuck and it was rarely asked where it came from.

What kind of SPARQL compliance is supported?

All GraphDB editions support:

See also SPARQL compliance.

Is GraphBD Jena-compatible?

Yes, GraphBD is compatible with Jena 2.7.3 with a built-in adapter. For more information, see Using GraphDB with Jena.

What are the advantages of using solid-state drives as opposed to hard-disk drives?

We recommend using enterprise grade SSDs whenever possible as they provide a significantly faster database performance compared to hard-disk drives.

Unlike relational databases, a semantic database needs to compute the inferred closure for inserted and deleted statements. This involves making highly unpredictable joins using statements anywhere in its indices. Despite utilising paging structures as best as possible, a large number of disk seeks can be expected and SSDs perform far better than HDDs in such a task.

How to find out the exact version number of GraphDB?

The major/minor version and patch number are part of the GraphDB distribution .zip file name. They can also be seen at the bottom of the GraphDB Workbench home page, together with the RDF4J, Connectors, and Plugin API’s versions.

A second option is to run the graphdb -v startup script command if you are running GraphDB as a standalone server (without Workbench). It will also return the build number of the distribution.

Another option is to run the following DESCRIBE query in the Workbench SPARQL editor:

DESCRIBE <http://www.ontotext.com/SYSINFO> FROM <http://www.ontotext.com/SYSINFO>

It returns pseudo-triples providing information on various GraphDB states, including the number of triples (total and explicit), storage space (used and free), commits (total and whether there are any active ones), the repository signature, and the build number of the software.

How to retrieve repository configurations?

To see what configuration data is stored in a GraphDB repository, go to Repositories and use Download repository configuration as Turtle icon


Then you could open the result file named repositoryname-config.ttl

Why can’t I use my custom rule file (.pie) - an exception occurred?

To use custom rule files, GraphDB must be running in a JVM that has access to the Java compiler. The easiest way to do this is to use the Java runtime from a Java Development Kit (JDK).

How to speed up a slow repository with enabled security when each request includes HTTP basic authentication?

Every HTTP authentication request takes significant time due to the bcrypt algorithm which encrypts the clear text password to match with the hash in $GDB_HOME/work/workbench/settings.js.

The best solution is to do one-time authentication and keep the JWT string. JWT has a much lower overhead.

  1. Login and generate the authorization

curl -X POST -I 'http://localhost:7200/rest/login/admin' -H 'X-GraphDB-Password: root'
  1. Pass the returned JWT key

curl -H 'Authorization: GDB eyJ1c2VybmFtZSI6ImFkbWluIiwiYXV0aGVudGljYXRlZEF0IjoxNTU3OTIzNTkxNDA0fQ==.OwSkajbUoHHsQGfwvaCxbb1f7bn0PJUeL4VbGEmNcWY=' http://localhost:7200/repositories/SYSTEM/size

The JWT token expires every 30 days.

To change the encryption algorithm from bcrypt to SHA-256 supported by the older GDB version, update the password token in $GDB_HOME/work/workbench/settings.js with the encrypted value of: password{user}

echo root{admin} | sha256sum

    "admin": {
    "username": "admin",
    "password": "9ca992309ea8a83c7e3af185e645f7d56dce169310a65f67d4708f9b023fb297",
    "grantedAuthorities": [
    "appSettings": {
        "DEFAULT_SAMEAS": true,
        "DEFAULT_INFERENCE": true,
        "EXECUTE_COUNT": true,
        "IGNORE_SHARED_QUERIES": false
    "dateCreated": 1557904143163
What does it mean when an IRI starts with urn:rdf4j:triple:?

When RDF* embedded triples are serialized in formats (both RDF and query results) that do not support RDF*, they are serialized as special IRIs starting with urn:rdf4j:triple: followed by Base64 URL-safe encoding of the N-Triples serialization of the triple. This is controlled by a boolean writer setting, and is ON by default. The setting is ignored by writers that support RDF* natively.

Such special IRIs are converted back to triples on parsing. This is controlled by a boolean parser setting, and is ON by default. It is respected by all parsers, including those with native RDF* support.

See RDF* and SPARQL*.