Stardog Logo

Stardog is an enterprise data unification platform. Stardog’s semantic graphs, data modeling, and deep reasoning make it fast and easy to unify data without writing code. See Enterprise Data Unification for more details.

What’s New in Stardog 4.2

Check out the Quick Start Guide to get Stardog installed and running in five easy steps.


Stardog 4.2 (29 September 2016) supports the RDF graph data model; SPARQL query language; property graph model and Gremlin graph traversal language; HTTP and SNARL protocols for remote access and control; OWL 2 and user-defined rules for inference and data analytics; virtual graphs; geospatial query answering; and programmatic interaction via several languages and network interfaces.

Stardog is made with skill, taste, and a point of view in DC, Boston, Madison, Moscow, and Heidelberg. 🌟🐶

To learn more about where we’ve been and where we’re headed, consult the RELEASE NOTES and milestones.

Downloading & Support

Download Stardog to get started. The Stardog support forum is the place to report bugs, ask questions, etc. Stardog developers may be found on Gitter chat, too.


There are several open source components of Stardog; feel free to submit pull requests: stardog-docs, stardog.js, stardog-groovy, stardog-spring, stardog.rb, and stardog-clj. Many thanks to Stardog customers, users, contributors, testers, etc. You know who you are, and so do we. Thank you![1] You can also help by editing these docs on Github if you spot a problem.

Enterprise Premium Support

Customers of Stardog’s Enterprise Premium Support have access to the following capabilities and services. Enterprise Premium Support is available as of Stardog 3 release. Email for details.

Real-time Support

Get access to the core Stardog development team in real-time via voice or chat. Let us help you get the most from Stardog, 24/7. Our core team has more semantic graph application and tool development experience than any other team on the planet. Other vendors shunt you off to inexperienced level one techs. We’ve never done that and never will.

Private Maven Repositories

See Using Maven for details; this includes a per-customer, private Maven repository, CDN-powered, for 24/7 builds, updates, and feature releases.

We’re also tying Maven and Docker together, providing private Docker repositories for customers, which allows us to build out clusters, custom configurations, best practices, and devops tips-and-tricks into custom Docker images…​so that you don’t have to.

Private Docker Repositories

Docker-based deliverables not only shortens your development and devops cycles but keeps you up-to-date with the latest-greatest versions of Stardog, including security fixes, performance hot fixes, and deployment best practices and configurations.

Priority Bug Fixes

With Maven and Docker in place, we’ve got a software delivery mechanism ready to push priority bug fixes into your enterprise as soon as they’re ready. We’ve averaged one Stardog release every two weeks since 2012. Enterprise Premium Support customers can now take advantage of our development pace in a controlled fashion.

Priority Feature Releases

We hate holding new features in a feature branch, especially for mundane business reasons; we want to release new stuff as soon as possible to our customers. With Enterprise Premium Support, we can maintain a disruptive pace of innovation without disrupting you.

Quick Start Guide


It just doesn’t get any easier than this: Stardog runs on Java 8. Stardog runs best on, but does not require, a 64-bit JVM that supports sun.misc.Unsafe.


We optimize Stardog out-of-the-box for ease and simplicity. You should take additional steps to secure it before production deployment. It’s easy and it’s smart, so just do it. In case that’s not blunt enough:

Stardog ships with an insecure but usable default setting: the super user is admin and the admin password is "admin". This is fine until it isn’t, at which point you should read the Security section.

Upgrading to Stardog 4

If you are upgrading to Stardog 4 from any previous version, please see Stardog 4 in SNARL Migration Guide for details about auto-migrating pre-4.0 indexes.

Linux and OSX

  1. Tell Stardog where its home directory (where databases and other files will be stored) is

    $ export STARDOG_HOME=/data/stardog

    If you’re using some weird Unix shell that doesn’t create environment variables in this way, adjust accordingly. If STARDOG_HOME isn’t defined, Stardog will use the Java user.dir property value.

    You should consider the upgrade process when setting STARDOG_HOME for production or other serious usage. In particular, you probably don’t want to set the directory where you install Stardog as STARDOG_HOME as that makes upgrading less easy. Set STARDOG_HOME to some other location.
  2. Copy the stardog-license-key.bin into the right place:

    $ cp stardog-license-key.bin $STARDOG_HOME

    Of course stardog-license-key.bin has to be readable by the Stardog process.

    Stardog won’t run without a valid stardog-license-key.bin in STARDOG_HOME.

  3. Start the Stardog server. By default the server will expose SNARL and HTTP interfaces on port 5820.[2]

    $ ./stardog-admin server start
  4. Create a database with an input file:

    $ ./stardog-admin db create -n myDB data.ttl
  5. Query the database:

    $ ./stardog query myDB "SELECT DISTINCT ?s WHERE { ?s ?p ?o } LIMIT 10"

    You can use the Web Console to search or query the new database you created by visiting http://localhost:5820/myDB in your browser.

Now go have a drink: you’ve earned it.


Windows…​really? Okay, but don’t blame us if this hurts…​The following steps are carried out using the Windows command prompt which you can find under Start ▸ Programs ▸ Accessories ▸ Command Prompts or Start ▸ Run ▸ cmd.

First, tell Stardog where its home directory (where databases and other files will be stored) is:

> set STARDOG_HOME=C:\data\stardog

Second, copy the stardog-license-key.bin into the right place:

> COPY /B stardog-license-key.bin %STARDOG_HOME%

The /B is required to perform a binary copy or the license file may get corrupted. Of course stardog-license-key.bin has to be readable by the Stardog process. Finally, Stardog won’t run without a valid stardog-license-key.bin in STARDOG_HOME.

Third, start the Stardog server. By default the server will expose SNARL and HTTP interfaces on port 5820.[3]

> stardog-admin.bat server start

This will start the server in the current command prompt, you should leave this window open and open a new command prompt window to continue.

Fourth, create a database with some input file:

> stardog-admin.bat db create -n myDB data.ttl

Fifth, query the database:

> stardog.bat query myDB "SELECT DISTINCT ?s WHERE { ?s ?p ?o } LIMIT 10"

You can use the Web Console to search or query the new database you created by hitting http://localhost:5820/myDB in your browser.

You should drink the whole bottle, brave Windows user!

Using Stardog

Stardog supports SPARQL, the W3C standard for querying RDF graphs, as well as a range of other capabilities, including updating, versioning exporting, searching, obfuscating, and browsing graph data.


Stardog supports SPARQL 1.1 and also the OWL 2 Direct Semantics entailment regime.

To execute a SPARQL query against a Stardog database, use the query subcommand with a query string, a query file, or the name of a stored query:

$ stardog query myDb "select * where { ?s ?p ?o }"

Detailed information on using the query command in Stardog can be found on its man page. See Managing Stored Queries section for configuration, usage, and details of stored queries.


SPARQL’s DESCRIBE keyword is deliberately underspecified. In Stardog a DESCRIBE <theResource> query retrieves the predicates and objects for all the triples for which <theResource> is the subject. There are, of course, about seventeen thousand other ways to implement DESCRIBE; we’ve implemented four or five of them and may expose them to users in a future release of Stardog based on user feedback and requests.

Query Functions

Stardog supports all of the functions in SPARQL, as well as some others from XPath and SWRL. Any of these functions can be used in queries or rules. Some functions appear in multiple namespaces, but all of the namespaces will work.

See SPARQL Query Functions for the complete list.

Federated Queries

In Stardog 3.0 we added support for the SERVICE keyword[4] which allows users to query distributed RDF via SPARQL-compliant data sources. You can use this to federate queries between several Stardog database or Stardog and other public endpoints.

Stardog doesn’t support variables for the service URL (SERVICE ?serviceURL).

Stardog ships with a default Service implementation which uses SPARQL Protocol to send the service fragment to the remote endpoint and retrieve the results. Any endpoint that conforms to the SPARQL protocol can be used.

The Stardog SPARQL endpoint is http://<server>:<port>/{db}/query.

HTTP Authentication

Stardog requires authentication. If the endpoint you’re referencing with the SERVICE keyword requires HTTP authentication, credentials are stored in a password file called services.sdpass located in STARDOG_HOME directory. The default Service implementation assumes HTTP BASIC authentication; for services that use DIGEST auth, or a different authentication mechanism altogether, you’ll need to implement a custom Service implementation.

Querying RDBMS via Virtual Graphs

Sometimes enterprise information belongs to or in a Stardog graph but for various reasons the upstream or canonical data source should not be disturbed, consolidated, or decommissioned. In those (and other) cases it makes sense to use Stardog’s R2RML[5] mapping feature to create virtual graphs, that is, mappings between a Stardog graph and external data sources such that Stardog will query the external data sources—​by rewriting SPARQL to SQL automatically—​as if they were actually materialized in Stardog.

See the [Virtual Graphs] chapter for configuration and usage.

Querying Geospatial Data

This works more or less like any SPARQL query, as long as the right geospatial vocabulary is used in the data.

See the Geospatial Query chapter for configuration and usage.


Stardog supports graph traversals via Gremlin Console and TinkerPop 3 APIs. You can write Gremlin traversals against TP3 APIs in many different languages. But the easiest way to use Gremlin with Stardog is via the Gremin Console.


There are many ways to update the data in a Stardog database; two of the most commonly used methods are the CLI and SPARQL Update queries, each of which are discussed below.


SPARQL 1.1 Update can be used to insert RDF into or delete RDF from a Stardog database using SPARQL query forms INSERT and DELETE, respectively.

PREFIX dc: <>
PREFIX ns: <>
{ GRAPH <http://example/bookStore> { <http://example/book1>  ns:price  42 } }

An example of deleting RDF:

PREFIX dc: <>

  <http://example/book2> dc:title "David Copperfield" ;
                         dc:creator "Edmund Wells" .

Or they can be combined with WHERE clauses:

PREFIX foaf:  <>

WITH <http://example/addresses>
DELETE { ?person foaf:givenName 'Bill' }
INSERT { ?person foaf:givenName 'William' }
  { ?person foaf:givenName 'Bill' }
Per the SPARQL Update spec, Stardog treats Update queries as implicitly transactional and atomic. Since Stardog does not support nested transactions, it will not (currently) support an Update query in an open transaction.[6]

Adding Data with the CLI

As of Stardog 4.2, the most efficient way to load data into Stardog is at database creation time. See the Creating a Database section for bulk loading data at database creation time. To add data to an existing Stardog database, use the add command:

$ stardog data add myDatabase 1.rdf 2.rdf 3.rdf

The optional arguments are -f (or --format) to specify the RDF serialization type of the files to be loaded; if you specify the wrong type, add will fail. If you don’t specify a type, Stardog will try to determine the type on its own based on the file extension. For example, the files that have names ending with '.ttl' will be parsed with Turtle syntax. If you specify a type, then all the files being loaded must of that same type.

If you want to add data to a named graph, specify it via the --named-graph or -g options.

Removing Data with the CLI

To remove data, use remove with the following input(s):

  1. one Named Graph, or

  2. one or more files containing RDF (in some recognized serialization format, i.e., RDF/XML, Turtle, Trig), or

  3. one Named Graph and one or more RDF files.

For example,

$ stardog data remove -g http://foo myDatabase

will remove the named graph http://foo and all its triples from myDatabase.

$ stardog data remove myDatabase 1.rdf

will remove the triples in 1.rdf from (the default graph of) myDatabase.

$ stardog data remove -g http://foo -f TURTLE myDatabase 2.rdf 3.rdf

will remove the triples in the Turtle files 2.rdf and 3.rdf from the named graph http://foo of myDatabase.

How Stardog Handles RDF Parsing

RDF parsing in Stardog is strict: it requires typed RDF literals to match their explicit datatypes, URIs to be well-formed, etc. In some cases, strict parsing isn’t ideal—it may be disabled using the strict.parsing configuration option.

However, even with strict parsing disabled, Stardog’s RDF parser may encounter parse errors from which it cannot recover. And loading data in lax mode may lead to unexpected SPARQL query results. For example, malformed literals ("2.5"^^xsd:int) used in filter evaluation may lead to undesired results.


Stardog supports graph change management capability that lets users track changes between revisions of a Stardog database, add comments and other metadata to the revisions, extract diffs between those revisions, tag revisions with labels, and query over the revision history of the database using SPARQL.

For a more complete tutorial on using Stardog versioning, see the stardog-examples repo.

Versioning support for a database is disabled by default but can be enabled at any time by setting the configuration option versioning.enabled to true. For example, you can create a database with versioning support as follows:

$ stardog-admin db create -o versioning.enabled=true -n myDb

This option can also be set after database creation using the stardog-admin metadata set command.

The following examples give a very brief overview of this capability; see the Man Pages for all the details.

Committing Changes

Commit a new version by adding and removing triples specified in files. Different from the data add/remove commands, commit allows one to add and remove triples in one commit and to associate a commit message.

To commit changes:

$ stardog vcs commit --add add_file1.ttl add_file2.ttl --remove remove_file.ttl -m "This is an example commit" myDb

It is also possible to run an update query with a commit message:

Removals are performed before additions and queries are executed last.
$ stardog vcs commit --query update.sparql -m "This is another commit" myDb

If the database is updated through the regular data add, data remove, or query commands when versioning is enabled, a corresponding version will be created but the commit message will be empty.

Viewing Revisions

To see all revisions (commits) in a database:

$ stardog vcs list myDb
$ stardog vcs list --committer userName myDb

The output can be tweaked using --after, --before, and --committer.

Reverting Revisions

You can revert specific revisions, ranges, etc.

$ stardog vcs revert myDb
$ stardog vcs revert myDb de44369d-cc7b-4244-a3fb-3f6e271420b0

Viewing Diffs

You can also see the differences between revisions; by default, between the head version and its previous versions or the changes in a specific commit, respectively:

$ stardog vcs diff myDb
$ stardog vcs diff myDb de44369d-cc7b-4244-a3fb-3f6e271420b0
Diffs are represented as SPARQL Update queries so that they may be used as a kind of graph patch.

Using Tags

You can also create, drop, list tags, i.e., named revisions:

$ stardog vcs tag --list myDb

Querying the Revision History

The revision history of the database is represented as RDF using an extended version of the W3C PROV vocabulary and can be queried using SPARQL.[7] The following query retrieves all the versions:

SELECT ?author ?msg ?date {
  ?v a vcs:Version ;
     rdfs:comment ?msg ;
     prov:wasAttributedTo / rdfs:label ?author ;
     prov:generatedAtTime ?date

You can execute versioning queries using the vcs query command:

$ stardog vcs query myDb versioning-query.sparql

Queries executed by vcs query only query the versioning history and automatically recognizes the vcs and prov namespaces. If you would like to query the current state of the database along with the version history then you can run a regular query using a special versioning SERVICE. The following query finds the instances of foaf:Person class that has been modified in the last 24 hours:

PREFIX prov: <>
PREFIX vcs: <tag:stardog:api:versioning:>

  ?x a foaf:Person

  SERVICE vcs:service {
    ?v a vcs:Version;
       prov:generatedAtTime ?date;
       vcs:updates/(vcs:additions|vcs:removals) ?update
    GRAPH ?update {
      ?x ?p ?o
    FILTER (NOW() - ?date < 'PT24H'^^xsd:dayTimeDuration)

You can run this query using the regular query command:

$ stardog query myDb versioning-mixed-query.sparql

Note that, in this query the namespaces vcs and prov have been declared explicitly in the query. If you register these namespaces to your database then you can omit these declarations.

For more details about the Stardog versioning representation, see the stardog-examples repo.


To export data from a Stardog database back to RDF, export is used by specifying

  1. the name of the database to export

  2. optionally, the URIs of the named graphs to export if you wish to export specific named graphs only. Keywords DEFAULT and ALL can be used as values of the --named-graph parameter to export the default graph and all graphs, respectively

  3. the export format: N-TRIPLES, RDF/XML, TURTLE, TRIG. The default is N-TRIPLES. TRIG must be used when exporting the entire database if the database contains triples inside named graphs

  4. a file to export to

For example,

$ stardog data export --format TURTLE myDatabase myDatabase_output.ttl

$ stardog data export --named-graph myDatabase myDatabase_output.nt


Stardog includes an RDF-aware semantic search capability: it will index RDF literals and supports information retrieval-style queries over indexed data. See Managing Search for more details.

Searching with the Command Line

First, check out the search man page:

$ stardog help query search

Okay, now let’s do a search over the O’Reilly book catalog in RDF for everything mentioning "html":

$ stardog query search -q "html" -l 10 catalog

The results?

| Index | Score |                        Hit                        |
| 1     | 6.422 | |
| 2     | 6.422 | |
| 3     | 6.422 | |
| 4     | 6.422 | |
| 5     | 6.422 | |
| 6     | 6.422 | |
| 7     | 6.422 | |
| 8     | 6.422 | |
| 9     | 6.422 | |
| 10    | 6.422 | |

See Full-Text Search for more details.


When sharing sensitive RDF data with others, you might want to (selectively) obfuscate it so that sensitive bits are not present, but non-sensitive bits remain. For example, this feature can be used to submit Stardog bug reports using sensitive data.

Data obfuscation works much the same way as the export command and supports the same set of arguments:

$ stardog data obfuscate myDatabase obfDatabase.ttl

By default, all URIs, bnodes, and string literals in the database will be obfuscated using the SHA256 message digest algorithm. Non-string typed literals (numbers, dates, etc.) are left unchanged as well as URIs from built-in namespaces (RDF, RDFS, and OWL). It’s possible to customize obfuscation by providing a configuration file.

$ stardog data obfuscate --config obfConfig.ttl myDatabase  obfDatabase.ttl

The configuration specifies which URIs and strings will be obfuscated by defining inclusion and exclusion filters. See the example configuration file in the stardog-examples Github repo.

Once the data is obfuscated, queries written against the original data will no longer work. Stardog provides query obfuscation capability, too, so that queries can be executed against the obfuscated data. If a custom configuration file is used to obfuscate the data, then the same configuration should be used for obfuscating the queries as well:

$ stardog query obfuscate --config obfConfig.ttl myDatabase myQuery.sparql > obfQuery.ttl


The Stardog Web Console is a responsive web app for the Stardog Server and for every Stardog database that makes administration and interaction with data quick and easy; you can access it at http://foo:5820 where foo is the name of the machine where Stardog is running.

A Screenshot Tour…​

Seriously, this is a lot more fun if you just download the damn thing and hit it with a browser!