Apache Jena

What this endpoint does

An Apache Jena endpoint identifies a named graph where Semogram can materialize ontology facts in a Fuseki dataset. Supported ontology/SPARQL operations can query that stored data. This is an ontology store rather than a generic source of table rows.

Like all data endpoints, it belongs to a workspace and can be referenced by projects in that workspace, subject to permissions. Saving it configures access; it does not start ingestion.

Directions and supported operations

This is a Materialization endpoint, with writes and readback through the fact_materializer capability and ontology_fact_store contract. Ontology materialization sends facts from Semogram to the configured Fuseki named graph; supported ontology/SPARQL reads retrieve those facts and their evidence.

It is not a generic source_stream or write destination for arbitrary tabular records. The installation selects the Fuseki service/dataset and authentication. The endpoint selects the graph URI and entity IRI prefix. The database identity needs both query and update access for a complete materialize/readback test. Saving the endpoint creates no project ontology binding and materializes no facts.

Plugin used

This endpoint uses the Apache Jena ontology fact-store capability. Installation steps for this example are included below. The Apache Jena installation guide provides optional further detail. Connection details and credentials stay on the installation; the endpoint selects a particular target through that installed capability.

What you need

A Semogram account with workspace access and permission to manage endpoints
An existing matching installation, or the connection details to create one using the steps below
Have access to a Fuseki dataset with the required read/update privileges. Choose a dedicated test graph and stable entity IRI prefix. A project ontology binding is needed for the materialization test

Example setup

We choose facts as the endpoint name and ontology as its namespace. The example graphUri identifies the named graph; baseIri is the prefix used to form entity identifiers. These example.com IRIs are illustrative identifiers, not service URLs to connect to. Choose IRIs for your own ontology; the Fuseki service URL belongs on the installation.

Install and configure the plugin

Open Plugins in this workspace and select Explore.
Find Apache Jena, inspect its publisher/version and select its ontology fact-store capability.
Name the installation and fill its connection settings using your actual external-system details.
Save and run the supported connection check. Fix any reported error before creating the endpoint.

Example installation configuration:

Open workspace Plugins → Explore, choose the matching capability and fill its installation settings. Enter values in the labeled controls rather than pasting the whole JSON object.

UI field	Example value
Endpoint	`https://YOUR_FUSEKI_HOST`
Dataset	`YOUR_DATASET`
User	`YOUR_USER`
Password	`YOUR_PASSWORD`

Nested labels above identify the containing group. Lists use the form’s list controls; open-ended objects use its object editor. Labels and available options follow the installed version’s contract. Enter credentials in the protected fields and review the selected installation before saving.

In the platform assistant or your connected MCP assistant, ask:

Assistant prompt

Install the plugin described on this page in this workspace. Discover its catalog entry, select the matching capability and propose the installation using the connection settings shown here. Ask me to enter credentials in protected installation fields. Show the selected plugin/version, capability and non-secret settings before saving.

Replace placeholders with real accessible resources. The assistant prepares the operation; inspect its proposed inputs and result.

Use plugin_catalog_list / plugin_catalog_get to obtain the discovery ID and matching capability class (reads, writes or factStores). Call plugin_installation_create with the arguments below through an authenticated MCP connection. The workspace comes from that connection. Enter credentials through an authorized protected configuration path; do not send real secrets as conversational prompt text.

MCP request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "plugin_installation_create",
    "arguments": {
      "capabilityClass": "<MATCHING_CAPABILITY_CLASS>",
      "discoveryId": "<DISCOVERY_ID_FROM_CATALOG>",
      "name": "<INSTALLATION_NAME>",
      "config": {
        "endpoint": "https://YOUR_FUSEKI_HOST",
        "dataset": "YOUR_DATASET",
        "user": "YOUR_USER",
        "password": "YOUR_PASSWORD"
      },
      "idempotencyKey": "<UNIQUE_KEY_FOR_THIS_INSTALLATION>"
    }
  }
}

This operation has no standalone public /api/v1 plugin-installation/catalog route in the current implementation. Use the UI or MCP methods shown here.

Replace every YOUR_… value. Enter credentials only in protected installation configuration. The configuration above is separate from the endpoint target below; selecting a target does not create or authenticate the connection.

Prepare the store

Create or select a Fuseki dataset using your deployment's administration tools and grant the configured user read/update access. Use a dedicated test graph. The graph and base IRI below are identifiers, not the Fuseki HTTP endpoint.

To verify materialization, select a project, define one ontology entity with a known identifier, bind this endpoint as its fact store and run a small materialization through the supported ontology flow. Inspect that entity through a supported query and its returned evidence. Use a test graph so this write does not mix with production facts.

Use the assistant

Open Data Endpoints → New data endpoint in the workspace. Describe your actual target and choose a name for the endpoint. For the example above, you could ask:

Create a ontology store endpoint named facts in namespace ontology.
Use our installed Apache Jena ontology fact-store capability with contract ontology_fact_store
and set these target fields:
Type: jena_ontology_fact_store
Graph uri: https://example.com/graphs/facts
Base iri: https://example.com/ontology/
Review the proposed connection and target before saving.

Replace example values with your own. Give the assistant the installed connection reference; keep credentials in protected installation settings.

Configure manually

Choose Edit manually, select the matching installed capability and configure:

Field	Value
Name	`facts`
Namespace	`ontology`
Role	`ontology_store`
Contract	`ontology_fact_store`

Open workspace Data Endpoints → New data endpoint → Edit manually, choose the direction and installed capability described in this example, then fill the target fields. Enter values in the labeled controls rather than pasting the whole JSON object.

UI field	Example value
Type	`jena_ontology_fact_store`
Graph uri	`https://example.com/graphs/facts`
Base iri	`https://example.com/ontology/`

Nested labels above identify the containing group. Lists use the form’s list controls; open-ended objects use its object editor. Labels and available options follow the installed version’s contract. Review the endpoint name, direction, capability and selected target before saving.

In the platform assistant or your connected MCP assistant, ask:

Assistant prompt

Create the endpoint described on this page using these settings:
name: <ENDPOINT_NAME_FROM_THIS_EXAMPLE>
namespace: <ENDPOINT_NAMESPACE_FROM_THIS_EXAMPLE>
role: ontology_store
contractKind: ontology_fact_store
target / type: jena_ontology_fact_store
target / graphUri: https://example.com/graphs/facts
target / baseIri: https://example.com/ontology/
pluginCapabilityInstallationId: <INSTALLED_CAPABILITY_UUID>
Use the actual installed capability and the endpoint name/namespace selected in this example. Show the proposed direction, connection and target before saving. Keep credentials on the installation.

Replace placeholders with real accessible resources. The assistant prepares the operation; inspect its proposed inputs and result.

Use a workspace API key with endpoints:write. Set SEMOGRAM_API_KEY in your shell; replace resource placeholders with real IDs. This is an HTTP resource request, not an MCP JSON-RPC message.

HTTP API request

curl --request POST "https://platform.semogram.com/api/v1/data-endpoints" \
  --header "Authorization: Bearer ${SEMOGRAM_API_KEY}" \
  --header "Idempotency-Key: <UNIQUE_KEY_FOR_THIS_ENDPOINT>" \
  --header "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{
  "name": "<ENDPOINT_NAME_FROM_THIS_EXAMPLE>",
  "namespace": "<ENDPOINT_NAMESPACE_FROM_THIS_EXAMPLE>",
  "role": "ontology_store",
  "contractKind": "ontology_fact_store",
  "target": {
    "type": "jena_ontology_fact_store",
    "graphUri": "https://example.com/graphs/facts",
    "baseIri": "https://example.com/ontology/"
  },
  "pluginCapabilityInstallationId": "<INSTALLED_CAPABILITY_UUID>"
}
JSON

Call source_create with the arguments below through an authenticated workspace MCP connection. Replace the name/namespace placeholders with the labels chosen in this example and use the actual installed capability UUID. Set the role/contract to the direction described here; the workspace is resolved from the connection. This configures an endpoint and does not execute a read or write.

MCP request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "source_create",
    "arguments": {
      "name": "<ENDPOINT_NAME_FROM_THIS_EXAMPLE>",
      "namespace": "<ENDPOINT_NAMESPACE_FROM_THIS_EXAMPLE>",
      "role": "ontology_store",
      "contractKind": "ontology_fact_store",
      "target": {
        "type": "jena_ontology_fact_store",
        "graphUri": "https://example.com/graphs/facts",
        "baseIri": "https://example.com/ontology/"
      },
      "pluginCapabilityInstallationId": "<INSTALLED_CAPABILITY_UUID>",
      "idempotencyKey": "<UNIQUE_KEY_FOR_THIS_ENDPOINT>"
    }
  }
}

Use the ontology fact-store target rather than a source-table selector. Add a useful description, owner and expected freshness. Save in the workspace. Inspect the installed version’s contract before adding optional settings.

Verify the endpoint

Materialize a known fact through a project ontology binding. Read it back through a supported ontology/SPARQL query and compare entity IRIs and evidence. This is not a generic source preview.

Check connectivity, target validity and actual data separately. Saving does not import records or schedule execution.

Materialize and read back a known example

Use an isolated project and the dedicated store target configured above. This is a write test, followed by an ontology read; a connection check alone cannot verify either.

Prepare this CSV fixture and upload it as a managed dataset in the same workspace:

order_id,total
1,120.00
2,75.50

In the test project's ontology, define an Order entity with identifier order_id and numeric property total. Map the uploaded source's order_id and total columns to that entity. Review the inferred types and identity before saving.
Bind the endpoint created on this page as the project's ontology fact store. Its capability must be the fact materializer, not a raw read or destination writer. Confirm the configured schema/prefix or graph is dedicated to this test.
Run a bounded ontology materialization using only the two fixture rows. Inspect the run for successful storage, rejected facts and identity/type errors.
Query the materialized Order entities through the project's supported ontology query flow. Expect exactly the two fixture identifiers, totals 120.00 and 75.50, and evidence identifying the input records/run. Inspect the external store as well when your database/service tools permit it.
Read access and materialization access can fail independently. If a write fails, inspect the run and existing stored facts before repeating it. Do not assume materialization is generic append, table replacement or a whole-run transaction.

The uploaded dataset, ontology definition, mapping and binding are separate resources created in these steps. Saving this endpoint does not create them. Credentials remain on the installation; ontology mappings define the facts, and the endpoint defines where they are stored.

What this endpoint does

Directions and supported operations

Plugin used

What you need

Example setup

Install and configure the plugin

Prepare the store

Use the assistant

Configure manually

Verify the endpoint

Materialize and read back a known example

Manage the endpoint

FAQ

Why does verification fail?

Can another project use it?

What comes after verification?

On this page