Repository Specification | AllegroGraph 9.0.1
Author: Franz Incorporated

Copyright (c) 2005 - 2026 Franz, Incorporated
Last updated 27 May 2026 at 10:34

# AllegroGraph 9.0.1 Repository Specification

- Documentation Index
  - Release Notes
  - Quick Start
  - SSL/TLS Quick Start
  - Introduction
  - Setup and Configuration
    - Download
    - Server Installation
    - Server Configuration and Control
    - WebView
    - Database Upgrading
    - Managing Users
  - Server Management
    - Performance Tuning
    - Deleting Duplicate Triples
    - Purging Deleted Triples
    - Auditing
    - Managing Users
    - Replication
    - Point-in-Time Recovery
    - Transaction Log Archiving
    - Security Overview
    - Security Implementation
  - Tools
    - agtool
    - Data Loading
    - Data Export
    - Backup and Restore
    - Querying
    - RDFS++
    - Materializer
    - Event Scheduler
    - SHACL
  - Details
    - Triple Indices
    - Freetext Indices
    - Encoded IDs
    - Connection Pooling
    - N-dimensional Geospatial Overview
    - 2-D Geospatial
    - Temporal
    - Social Network
    - JavaScript
    - Datatypes
    - Data Conversion (Rapper)
    - Stored Procedures
    - Triple Attributes
    - Lineparse Format
  - Querying
    - SPARQL documentation summary
    - SPARQL Reference
    - SPIN
    - SPARQL Magic Properties
    - Prolog
  - 3rd-party tools
    - Solr text Indices
    - MongoDB integration
    - TopBraid Composer Plugin
    - Cloudera
  - Client APIs
    - Gruff
    - GraphTalker
    - REST/HTTP interface
    - HTTP reference
    - Javadocs (Sesame and Jena)
    - Python API
    - Lisp Reference
    - JavaScript
  - Tutorials
    - N-dimensional Geospatial
    - SPARQL Tutorial
    - Java Sesame
    - Java Jena
    - Python Sesame
    - Lisp
    - Prolog
    - More...
  - Other
    - Conferences and Seminars
    - Source Code on Github
    - Amazon EC2
    - Copyrights
  - Franz, Inc.

- Introduction
- Ground Store Repo Spec
  - Short Ground Store Repo Spec
  - Concise Ground Store Repo Spec
  - URI Ground Store Repo Spec
- Complex Repository Specification
  - Federation
  - Reasoning
  - Filtering
  - Combinations

Documentation Index

## Introduction

A repository specification (or repo spec for short) provides a way to describe a repository connection, a combination of connections, or connections wrapped with graph filtering or reasoning. This can be used for creating and opening repositories and with many agtools.

A repo spec starts with a ground store that may then be augmented with federation, graph filtering, and reasoning.

## Ground Store Repo Spec

A ground store is a directly or remotely accessed AllegoGraph triple store that is a single repository which is not federated, graph-filtered, and without inferencing.

A ground store address is comprised of the following components:

- repository name
- catalog name (default: root catalog)
- host (default: IPv4 localhost)
- port (default: 10035)
- username and password (required for remote connections)
- scheme (http or https, default: http)

All components are optional with the defaults indicated except for the repo name and the username and password for remote connections.

A ground store repository specification follows one of the following formats:

- `REPO`
- `CATALOG:REPO`
- `[USER:PASSWORD@][[HOST][:[PORT][s]]/][CATALOG:]REPO`
- `http(s):[//[USER:PASSWORD@]HOST[:PORT]][/catalogs/CATALOG]/repositories/REPO`

### Short Ground Store Repo Spec

Format:

    REPO
    or
    CATALOG:REPO

The first and second forms are Short Ground Store Repo Specs. The short forms can be used when all the other default values are acceptable and a username and password are not required. This is the case when AllegroGraph is using the standard port and the connection is being made on the same host as the AllegoGraph server is running on (but note some tools always require a username and password). The default catalog is the root catalog.

Examples (changes from default are in bold):

spec | name | catalog | host | port | user | pw | scheme
--- | --- | --- | --- | --- | --- | --- | ---

`myrepo` | myrepo | root | localhost | 10035 |  |  | http

`mycatalog:myrepo` | myrepo | mycatalog | localhost | 10035 |  |  | http

### Concise Ground Store Repo Spec

Format:

    [USER:PASSWORD@][[HOST][:[PORT][s]]/][CATALOG:]REPO

The third form above is called the Concise Ground Store Repo Spec. It can be used when the first or second forms are not sufficient, such as when AllegoGraph is not running on the default port or is running on a different host. It provides a way of specifying every connection parameter. Every part is optional except the repository name. To describe an https connection the letter `s` is appended to `PORT`. The colon between `HOST` and `PORT` or `s` is required when both `HOST` and `PORT` are provided or when `s` is used without `PORT`. `s` alone (with neither `HOST` or`PORT`) must be preceded by a colon, as in the third example below.

If you happen to have a hostname that looks like a port specification, such as `123` or `123s`, then the concise form will not work and you must use the URI repository specification.

Examples (changes from default are in bold):

spec | name | catalog | host | port | user | pw | scheme
--- | --- | --- | --- | --- | --- | --- | ---

`12345/myrepo` | myrepo | root | localhost | 12345 |  |  | http

`12345s/myrepo` | myrepo | root | localhost | 12345 |  |  | https

`:s/myrepo` | myrepo | root | localhost | 10035 |  |  | https

`remote:12345/myrepo` | myrepo | root | remote | 12345 |  |  | http

`remote:s/myrepo` | myrepo | root | remote | 10035 |  |  | http

`test:xyzzy@12345/myrepo` | myrepo | root | localhost | 12345 | test | xyzzy | http

`test:xyzzy@myhost:12345s/cat:myrepo` | myrepo | cat | myhost | 12345 | test | xyzzy | https

`test:xyzzy@/cat:myrepo` | myrepo | cat | localhost | 10035 | test | xyzzy | http

`test:xyzzy@1234/cat:myrepo` | myrepo | cat | localhost | 1234 | test | xyzzy | http

### URI Ground Store Repo Spec

Format:

    http(s):[//[USER:PASSWORD@]HOST[:PORT]][/catalogs/CATALOG]/repositories/REPO

The fourth form from above, URI Ground Store Repo Spec, can also be used when the first or second forms are insufficient. It serves the same function as the Concise Ground Store Repo Spec but provides a more canonical interface.

Examples (changes from default are in bold):

spec | name | catalog | host | port | user | pw | scheme
--- | --- | --- | --- | --- | --- | --- | ---

`http://myhost/repositories/myrepo` | myrepo | root | myhost | 10035 |  |  | http

`https://test:xyzzy@myhost:12345/catalogs/cat/repositories/repo` | myrepo | cat | myhost | 12345 | test | xyzzy | https

## Complex Repository Specification

A Complex Repository Specification is used to conveniently:

- Address a ground store
- Address a store that has been wrapped with a graph filter or reasoner.
- Address a federation of any combination of the above, including federations of federations.
- Address any combination of the above.

To use a Complex Specification the Ground Specifications are wrapped in angle brackets like: `<GROUND_SPEC>`. Then they are augmented for graph filtering, reasoning, or federation.

### Federation

Stores may be federated by inserting a `+` between two specifications.

Example:

    <repo1>+<http://remote:10035/repositories/repo2>

Here `repo1` is being federated with `http://remote:10035/repositories/repo2`.

### Reasoning

Stores may be setup with reasoning with the following formats:

- `<GROUND_SPEC>[]`
- `<GROUND_SPEC>[REASONER_NAME]`
- `<GROUND_SPEC>[REASONER_NAME#<GRAPH_URI>]`
- `<GROUND_SPEC>[#<GRAPH_URI>]`

Note that in this case the square brackets are part of the spec and do not indicate an optional component. `REASONER_NAME` maybe be either `rdfs++` or `restriction`. `<GRAPH_URI>` is the graph component of all inferred triples. The default is to use the default graph of the specified repository.

The default reasoner is `rdfs++` and is used whenever `REASONER_NAME` is not provided.

Examples:

Spec | Reasoner | Graph
--- | --- | ---

`<repo1>[]` | rdfs++ | default graph

`<repo1>[#<http://franz.com#xyz>]` | rdfs++ | `http://franz.com#xyz`

`<repo1>[rdfs++]` | rdfs++ | default graph

`<repo1>[rdfs++#<http://franz.com#xyz>]` | rdfs++ | `http://franz.com#xyz`

`<repo1>[restriction]` | restriction | default graph

### Filtering

Stores may be setup with graph filtering with the following formats:

- `<GROUND_SPEC>{}`
- `<GROUND_SPEC>{<URI>|null ...}`

Graph filtering is enabled by appending curly brackets. In the brackets is a list of graph filters separated by spaces. Filters are either an angle bracketed URI or the text `null`. Only the triples in the graphs specified by this list are visible in the encapsulated store. `null` is the default graph.

Examples:

Spec | Graphs
--- | ---

`<repo>{}` | (All graphs - no filtering)

`<repo>{ null }` | (default graph)

`<repo>{ <http://franz.com/> }` | `http://franz.com/`

`<repo>{ <bruce> <jimmy> }` | bruce, jimmy

`<repo>{ <bruce> null <jimmy> }` | bruce, (default graph), jimmy

### Combinations

Complex specifications can be combined in any combination. Parenthesis can be used to make groupings.

Examples:

Spec | Explanation
--- | ---

`<repo1>[rdfs++]{<http://franz.com#xyz>}` | Filtering on a reasoning store

`<repo1>{<http://franz.com#xyz>}[rdfs++]` | Reasoning on graph filtered store

`<repo1>+<repo2>[]` | Federation of a ground store and a reasoning store

`(<repo1>+<repo2>)[]` | Reasoning on a federation of repo1 and repo2