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:

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:

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 orPORT) 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

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:

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:

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:

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