Models

This page describes how Stardog reasoning schemas (models) are imported into the Knowledge Catalog and how to query the imported model metadata and graph contents using SPARQL.

Page Contents

1. Overview
2. What Gets Imported
   1. Skipped Databases
   2. Where the Imported Data Lives
3. Data Model
   1. Classes
   2. Properties
   3. IRI Conventions
   4. Diagram
   5. Graph Sharing Across Schemas
4. Opting Out
5. Example SPARQL Queries
   1. List All Imported Databases
   2. List All Schemas for a Database
   3. List the Source Graphs That Compose a Schema
   4. Query the Axioms of a Schema
   5. Find All OWL Classes Defined Across Every Imported Schema
   6. Find Graphs Shared by Multiple Schemas
   7. Locate the Most Recently Refreshed Schema Snapshot
6. See Also

---

Overview

In addition to importing metadata about virtual graphs and data sources, the Knowledge Catalog also imports the reasoning schemas (also known as models) of every eligible database on the server. This is performed by the built-in ModelProvider, which is registered automatically when the catalog database is created.

A reasoning schema in Stardog is a named collection of one or more graphs whose contents describe the data (OWL classes, OWL/RDFS axioms, Stardog Rules, etc.). The ModelProvider walks every database, enumerates its schemas, and copies the contents of every schema graph into the catalog database. This means the schemas of all your databases become queryable from a single place — the catalog database — and can be explored side-by-side with the rest of the catalog metadata.

By default, the ModelProvider runs every eight hours. It can also be triggered on demand:

$ stardog-admin catalog reload tag:stardog:api:catalog:models

What Gets Imported

For each database on the server, the ModelProvider does the following:

1. Lists all reasoning schemas declared on the database.
2. Builds a metadata description for the database, each schema, and each schema graph.
3. Copies the contents of every schema graph into a freshly minted graph in the catalog database.

Skipped Databases

A database is skipped entirely if any of the following holds:

• It is one of the system databases which are automatically created by Stardog itself.
• It is offline.
• Its reasoning.schema.catalog.export.enabled database option is set to false. This option lets administrators opt out specific databases from schema export. It defaults to true and is writable while the database is online.

Where the Imported Data Lives

As of Stardog version 12.1.0, the model import produces two distinct kinds of statements in the catalog database:

1. Metadata statements, all placed in the named graph tag:stardog:api:catalog:ModelsMetadata. These describe the source database, its schemas, and the relationships between schemas and graphs.

2. Copied graph contents, each placed in a freshly generated named graph (one per unique source graph) under the prefix tag:stardog:api:catalog:model_graph:. The original schema graph statements are reinserted with their context (graph) replaced by the new model graph IRI.

This separation makes it possible to query either about models (metadata) or into models (the actual schema axioms).

However, the structure may change in future releases of Stardog.

Data Model

Classes

The following classes are produced into the tag:stardog:api:catalog:ModelsMetadata graph:

Properties

IRI Conventions

Diagram

StardogDatabase "mydb"
        ▲
        │ hasStardogDatabase
        │
      Model  ── rdfs:label ─►  "schemaName"
        │  dct:issued ─►  2026-06-05T00:00:00Z
        │
        │ hasModelGraph (one per graph in the schema)
        ▼
   ModelGraph  ── (graph contents copied here with replaced context) ──►  triples
        │
        │ modelSource
        ▼
   DatabaseGraph  ── hasStardogDatabase ─►  StardogDatabase
        │
        │ hasGraph
        ▼
     Graph (original IRI in source database)

Graph Sharing Across Schemas

A single source graph can belong to multiple schemas. In that case the contents of the graph are still copied only once into a single ModelGraph, and every Model for the schemas it participates in points to the same ModelGraph via hasModelGraph. This avoids duplicating potentially large axiom sets when overlapping schemas are defined.

Opting Out

To prevent the ModelProvider from exporting the schemas of a particular database, set its reasoning.schema.catalog.export.enabled option to false:

$ stardog-admin metadata set -o reasoning.schema.catalog.export.enabled=false mydb

After the next reload, no StardogDatabase, Model, ModelGraph, or DatabaseGraph resources will be present in the catalog for mydb, and any previously imported entries are removed.

Example SPARQL Queries

The following queries are intended to be run against the catalog database. Most of them target the tag:stardog:api:catalog:ModelsMetadata named graph; queries that look at the actual axioms target the per-graph model graphs.

For readability, the examples use the prefix declaration:

PREFIX c: <tag:stardog:api:catalog:>
PREFIX dct: <http://purl.org/dc/terms/>

List All Imported Databases

PREFIX c: <tag:stardog:api:catalog:>
SELECT ?db ?name
FROM c:ModelsMetadata
WHERE {
  ?db a c:StardogDatabase ;
      rdfs:label ?name .
}

List All Schemas for a Database

PREFIX c: <tag:stardog:api:catalog:>
SELECT ?schemaName ?issued
FROM c:ModelsMetadata
WHERE {
  ?db a c:StardogDatabase ;
      rdfs:label "mydb" .
  ?model a c:Model ;
         c:hasStardogDatabase ?db ;
         rdfs:label ?schemaName ;
         dct:issued ?issued .
}

List the Source Graphs That Compose a Schema

PREFIX c: <tag:stardog:api:catalog:>
SELECT ?sourceGraph
FROM c:ModelsMetadata
WHERE {
  ?model a c:Model ;
         rdfs:label "myReasoningSchema" ;
         c:hasStardogDatabase ?db ;
         c:hasModelGraph ?modelGraph .
  ?db rdfs:label "mydb" .
  ?modelGraph c:modelSource ?dbGraph .
  ?dbGraph c:hasGraph ?sourceGraph .
}

Query the Axioms of a Schema

The actual schema triples are stored in the ModelGraph IRIs, not in c:ModelsMetadata. To inspect the axioms of a particular schema, follow hasModelGraph from the model and read the graphs it points to:

PREFIX c: <tag:stardog:api:catalog:>
SELECT ?s ?p ?o ?modelGraph
WHERE {
  GRAPH c:ModelsMetadata {
    ?model a c:Model ;
           rdfs:label "myReasoningSchema" ;
           c:hasStardogDatabase ?db ;
           c:hasModelGraph ?modelGraph .
    ?db rdfs:label "mydb" .
  }
  GRAPH ?modelGraph { ?s ?p ?o }
}

Find All OWL Classes Defined Across Every Imported Schema

PREFIX c: <tag:stardog:api:catalog:>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
SELECT DISTINCT ?class ?db ?schema
WHERE {
  GRAPH c:ModelsMetadata {
    ?model a c:Model ;
           rdfs:label ?schema ;
           c:hasStardogDatabase ?dbIri ;
           c:hasModelGraph ?modelGraph .
    ?dbIri rdfs:label ?db .
  }
  GRAPH ?modelGraph { ?class a owl:Class }
}
ORDER BY ?db ?schema ?class

Find Graphs Shared by Multiple Schemas

Because the ModelProvider deduplicates graph contents, a graph that participates in two or more schemas is represented by a single ModelGraph linked from multiple Model instances:

PREFIX c: <tag:stardog:api:catalog:>
SELECT ?sourceGraph (COUNT(DISTINCT ?model) AS ?schemaCount)
FROM c:ModelsMetadata
WHERE {
  ?model a c:Model ;
         c:hasModelGraph ?modelGraph .
  ?modelGraph c:modelSource ?dbGraph .
  ?dbGraph c:hasGraph ?sourceGraph .
}
GROUP BY ?sourceGraph
HAVING (COUNT(DISTINCT ?model) > 1)

Locate the Most Recently Refreshed Schema Snapshot

PREFIX c: <tag:stardog:api:catalog:>
SELECT ?db ?schema ?issued
FROM c:ModelsMetadata
WHERE {
  ?model a c:Model ;
         rdfs:label ?schema ;
         c:hasStardogDatabase ?dbIri ;
         dct:issued ?issued .
  ?dbIri rdfs:label ?db .
}
ORDER BY DESC(?issued)
LIMIT 1

See Also

• Reasoning — for how reasoning schemas are defined and used by Stardog databases.
• External Catalogs — for importing metadata from third-party catalog systems.

---