External Catalogs

This page discusses importing and using metadata from external catalog systems.

Page Contents

1. Overview
   1. External Credentials
      1. Adding a credential
      2. Listing existing stored credentials
2. Databricks Unity Catalog
   1. Configuration
   2. Data Model
3. Collibra
   1. Configuration
   2. Data Model
4. Microsoft Purview
   1. Configuration
   2. Exporting Stardog Metadata
   3. Data Model
5. Microsoft Purview v2
   1. Registering an Entra ID application
   2. Configuration
   3. Choosing what is imported
   4. Querying the imported metadata
   5. Exporting Stardog Metadata
   6. Data Model
   7. Migrating from the Purview provider
6. JDBC
   1. Configuration
   2. Data Model
7. Atlan
   1. Configuration
   2. Exporting Stardog Metadata
   3. Data Model

---

Overview

The Knowledge Catalog can import metadata from external catalog systems to enable a single unified semantic layer over multiple catalogs.

Where two providers read the same external system, or two data sources point at the same database server, the catalog holds the most recent import rather than both. Use one provider for each system you connect: one per Purview account, per Collibra or Atlan account, per Databricks workspace, per database server. Several providers of the same kind are fine when each one reads a different account, workspace or server.

A provider clears everything it imported before it fetches again, so a run that fails partway leaves nothing behind rather than the previous import. This includes a run that a provider stops at the start because of a configuration error. Metadata from that provider is missing from the catalog until a run succeeds. An export that fails does not have this effect, because the import is already stored by then.

A scheduled run that fails also takes the provider off the scheduler, so it does not run again at its scheduled time. A failed export counts as a failed run, even though the import before it was stored. stardog-admin catalog status does not show this: the job is still listed, with a Scheduled time in the past. Running stardog-admin catalog reload puts the provider back on its schedule, and so does restarting the server.

After you change a provider’s configuration, run stardog-admin catalog reload for that provider. The catalog checks for providers that were added or removed, but not for changes to one it has already loaded. Until the reload, or a server restart, the provider keeps running with its previous configuration, including its previous schedule, although stardog-admin catalog status shows the new one.

External Credentials

Metadata providers that call external REST APIs cannot use Data Sources to hold credentials. The Catalog provides CLI commands to store encrypted usernames and passwords in the catalog credential store. A token is returned that is used in provider configurations. The token is exchanged for the stored credentials during server processing.

The catalog credential store is a user configurable location for storing credential strings. The stored strings can be configured to be stored as keyless or encryption key hashes.

The following options can be used to override the defaults.

By default the credential store expectes a DER encoded RSA key pair located in the Stardog home directory. The keys need to be named catalog.priv and catalog.pub.

The following example uses openssl to generate an RSA key pair:

• Create an RSA PEM encoded file

  openssl genrsa -out catalog.pem 2048
  

• Extract the private key as a DER encoded file

  openssl pkcs8 -topk8 -nocrypt -in catalog.pem -outform der -out catalog.priv
  

• Extract the public key as a DER encoded file

  openssl pkey -in catalog.pem -pubout -outform der -out catalog.pub
  

To add credentials to the store use the CLI administrator commands catalog credentials-add and catalog credentials-list.

Adding a credential

In the following example a username my_user_name is added along with the corresponding password. The returned UUID 04bee4c7-26cc-4c97-b817-dbb3298fa842 is the value that is the used in the access_key property for the metadata provider using these credentials.

$ stardog-admin catalog credentials-add
Username: my_user_name
Password: 
Description (optional): My External System Credentials

04bee4c7-26cc-4c97-b817-dbb3298fa842

Listing existing stored credentials

In the following example the account credentials that were added are now listed. Only the UUID and the user provided description are retrieved. There is no way to retrieve the original credential values. The credential values can only be retrived by the catalog server once they are stored.

$ stardog-admin catalog credentials-list

Catalog Stored Credentials
+--------------------------------------+--------------------------------+
|              Access Key              |          Description           |
+--------------------------------------+--------------------------------+
| 04bee4c7-26cc-4c97-b817-dbb3298fa842 | My External System Credentials |
+--------------------------------------+--------------------------------+

Databricks Unity Catalog

The Knowledge Catalog can be configured to import Unity Catalog metadata using a Databricks account. You can configure the import to occur on a customizable schedule. Databricks Unity metadata is written to the Stardog Catalog, where it can be queried in conjunction with your Stardog databases.

Configuration

To import Databricks Unity Catalog metadata, you insert a DatabricksProvider configuration into the Knowledge Catalog’s stardog:catalog:providers named graph. The configuration describes how Databricks can be accessed and how often the Knowledge Catalog should refresh the metadata.

insert data {
    graph stardog:catalog:providers 
    { 
        <urn:myDBricksProvider> a <tag:stardog:api:catalog:DatabricksProvider> ;
            <tag:stardog:api:catalog:provider:dataSource> <DATA_SOURCE_HERE> ;
            <tag:stardog:api:catalog:provider:schedule> "SCHEDULE_HERE"  .
    }
} 

This table details the property values that need to be set for configuring a Databricks metadata provider.

After the configuration is inserted, a job is automatically created to run on the specified schedule. The job will import Databricks Unity metadata and load a general data model for viewing the metadata in Explorer.

Data Model

This table contains the classes used for modeling the Databricks metadata. Prefix bricks is namespace tag:stardog:api:catalog:databricks:.

Collibra

The Knowledge Catalog can be configured to import data from a Collibra Data Intelligence Cloud account. Collibra is a data catalog product that collects business glossary, data governance, lineage and compliance metadata.

Configuration

The configuration for a Collibra provider requires that Collibra credentials be stored in the catalog credential store. See storing credentials for details.

Collibra Data Intelligence Cloud uses HTTP Basic Auth with a username and password for authentication. Add your account username and password to the catalog credential store and use the returned access key to configure the Collibra provider.

insert data {
    graph stardog:catalog:providers 
    { 
        <urn:collibra> a <tag:stardog:api:catalog:CollibraProvider> ;
            <tag:stardog:api:catalog:provider:accessKey> "ACCESS_KEY_HERE" ;
            <tag:stardog:api:catalog:provider:serverAddress> "CLOUD_URL_HERE" ;  
            <tag:stardog:api:catalog:provider:schedule> "SCHEDULE_HERE"  .
    }
} 

This table details the property values that need to be set for configuring a Collibra metadata provider.

Data Model

This table contains the classes used for modeling the Collibra metadata. Prefix collibra is namespace tag:stardog:api:catalog:collibra:.

Microsoft Purview

The Knowledge Catalog can be configured to both import data from an Microsoft Purview application running on Azure and export Stardog catalog data back into it. Purview is Microsoft’s data governance, cataloging and protection product.

This provider is deprecated and will be removed in a future release. It reads the Purview Data Map only. New connections should use Microsoft Purview v2, which reads the Data Map and the Unified Catalog. See Migrating from the Purview provider. Stardog logs a warning at startup for every configured provider of this type.

Configuration

The configuration for a Purview provider requires that Purview credentials be stored in the catalog credential store. See storing credentials for details.

Microsoft Purview on Azure uses the OAuth client_credentials grant type for authorization. Add your Azure client id and application client secret to the catalog credential store and use the returned access key to configure the Purview provider.

insert data {
    graph stardog:catalog:providers 
    { 
        <urn:purview> a <tag:stardog:api:catalog:PurviewProvider> ;
            <tag:stardog:api:catalog:provider:accessKey> "ACCESS_KEY_HERE" ;
            <tag:stardog:api:catalog:provider:serverAddress> "CLOUD_URL_HERE" ;  
            <tag:stardog:api:catalog:provider:tenantId> "AZURE_TENTANT_ID_HERE" ;  
            <tag:stardog:api:catalog:provider:schedule> "SCHEDULE_HERE"  .
    }
} 

This table details the property values that need to be set for configuring a Purview metadata provider.

Exporting Stardog Metadata

The Purview provider exports data source metadata into the configured Purview server. There is no extra configuration required to export Stardog metadata. When the provider’s scheduled job is run the export will automatically occur after the import is completed.

The following Purview asset types are added for the Stardog data source metadata:

After the scheduled provider job has run you can log into your Purview account and view the Stardog metadata. It is located in a custom stardogcatalog collection.

Data Model

This table contains the classes used for modeling the Purview metadata. Prefix purview is namespace tag:stardog:api:catalog:purview: and the atlas prefix is namespace tag:stardog:api:catalog:atlas:.

Microsoft Purview v2

The Knowledge Catalog can be configured to both import metadata from the current Microsoft Purview and export Stardog catalog data back into it. Purview holds metadata on two planes, and this provider reads both.

The Unified Catalog is served from the tenant level endpoint only, so a provider pointed at a classic account host imports the Data Map alone.

Use this provider for new Purview connections. The Microsoft Purview provider described above reads the Data Map only and is deprecated. See Migrating from the Purview provider.

Registering an Entra ID application

Stardog connects to Purview as a Microsoft Entra ID application, using the OAuth client_credentials grant.

1. In Microsoft Entra ID, register an application. Record its Application (client) ID, and the Directory (tenant) ID of the directory it belongs to.
2. On that application, create a client secret and record its Value, not its Secret ID. Entra shows the Value once.
3. In Purview, grant the application Data Map roles on each collection to be imported, or on the root collection to cover all of them. Importing needs Data readers, to read assets, and Data source admins, because the import lists the account’s registered data sources through Purview’s scan API.
4. Exporting needs two roles beyond those: Data curators, to register the Stardog asset types and write entities, and Collection admins, because the provider re-asserts its collection on every run rather than only when creating it. Export is on by default. If you skip this step, set exportMetadata to false: otherwise every export fails, and the first scheduled run that fails takes the provider off the scheduler.
5. To import the Unified Catalog, add the application to Global Catalog Readers in Purview’s Unified Catalog settings. This is a tenant-level role, separate from the Data Map collection roles above, so those do not grant it. Without it the Unified Catalog calls are refused and only the Data Map is imported.

Configuration

The configuration for a Purview v2 provider requires that Purview credentials be stored in the catalog credential store. See storing credentials for details.

Add your Entra application client id and secret to the catalog credential store as a client credential:

$ stardog-admin catalog credentials-add --client-id APPLICATION_CLIENT_ID --client-secret SECRET --label purview

04bee4c7-26cc-4c97-b817-dbb3298fa842

The UUID it returns is the access key used below. Pass both options. Without them the command prompts for a username and password, which a Purview provider cannot use: the credential is stored, and the provider then fails to load. Nothing imports, and the Stardog server log records Failed to load catalog metadata provider for it, with Missing client id or secret as the cause.

insert data {
    graph stardog:catalog:providers 
    { 
        <urn:purview_v2> a <tag:stardog:api:catalog:PurviewV2Provider> ;
            <tag:stardog:api:catalog:provider:accessKey> "ACCESS_KEY_HERE" ;
            <tag:stardog:api:catalog:provider:tenantId> "AZURE_TENANT_ID_HERE" ;  
            <tag:stardog:api:catalog:provider:schedule> "SCHEDULE_HERE"  .
    }
} 

Run that update against the catalog database, for example with stardog query catalog '<the update above>' or by saving it to a file and running stardog query catalog provider.sparql.

This table details the property values that can be set for configuring a Purview v2 metadata provider. Only the type, access key and tenant id are required.

serverAddress chooses the endpoint, and with it how much is imported. Leaving it out, or setting it to api.purview-service.microsoft.com, reads both planes. Setting it to a classic account host such as my-account.purview.azure.com reads the Data Map alone. The provider and the API versions it calls are the same either way.

A classic account host serves no Unified Catalog, so governanceDomain, dataProductScope and unifiedCatalogReadWidth have no effect there. A governanceDomain configured against such a host is reported in the Stardog server log.

Choosing what is imported

By default every collection and every governance domain the account exposes is imported, and a data product is imported when its status is Published. Three properties narrow that.

insert data {
    graph stardog:catalog:providers 
    { 
        <urn:purview_v2> a <tag:stardog:api:catalog:PurviewV2Provider> ;
            <tag:stardog:api:catalog:provider:accessKey> "ACCESS_KEY_HERE" ;
            <tag:stardog:api:catalog:provider:tenantId> "AZURE_TENANT_ID_HERE" ;  
            <tag:stardog:api:catalog:provider:collections> "xk3p9q,m2v7rt" ;
            <tag:stardog:api:catalog:provider:governanceDomain> "Finance" ;
            <tag:stardog:api:catalog:provider:dataProductScope> "Published,Draft" ;
            <tag:stardog:api:catalog:provider:schedule> "SCHEDULE_HERE"  .
    }
} 

Names are matched without regard to case, and space around the commas is ignored.

collections takes each collection’s reference name, not the name the Purview portal shows. For a collection created in the portal, the reference name is a code Purview generates, such as xk3p9q. The root collection’s reference name is the account name. To find the reference names, run an import without collections. Each collection’s IRI then ends with its reference name:

prefix purview: <tag:stardog:api:catalog:purview:>

select ?collection ?name {
    graph purview:AZURE_TENANT_ID {
        ?collection a purview:Collection ;
                    rdfs:label ?name .
    }
}

governanceDomain takes domain names as the Purview portal shows them. It imports only the domains it names, not their child domains, so name each child domain you want as well.

The run stops before anything is imported in two cases:

• a dataProductScope value that is not a product status;
• a governanceDomain none of whose names matches a domain the application can read. An application with reader access cannot see unpublished domains, so naming one stops the run, with a message saying the name matches no governance domain.

Because a run starts by removing the provider’s previous import, a run that stops leaves no metadata from this provider in the catalog.

Any other name that matches nothing is ignored, and the Stardog server log names it along with the names the account does have. A collections value that matches no collection imports no Data Map metadata, leaving only the Unified Catalog.

dataProductScope can only narrow what the application is already allowed to see. A Global Catalog Readers application sees published content only, so setting it to include Draft imports nothing until the application also holds a curation role on the domain, such as Data steward.

The Unified Catalog answers some questions one object at a time: the assets a data product offers, the columns a critical data element governs, and the key results of an objective. On an account with hundreds of data products those reads dominate the import, and running them concurrently shortens it substantially. Setting unifiedCatalogReadWidth to a value between 5 and 8 is a reasonable starting point for such an account.

unifiedCatalogReadWidth is the number of concurrent requests to your Purview account. Raise it gradually, and keep Purview’s rate limits in mind if the account is shared with other workloads.

Querying the imported metadata

Metadata imported to Stardog is found in a graph named for the Purview account it came from. A provider on the default endpoint writes into a graph named for the Entra tenant, tag:stardog:api:catalog:purview:AZURE_TENANT_ID, because that endpoint is the same host for every tenant. The tenant id in that name is lowercase, whatever case tenantId is configured in. A provider on a classic account host writes into a graph named for that host, tag:stardog:api:catalog:my-account.purview.azure.com.

This query returns the graph of each Purview account the catalog holds, alongside the host it was read from:

prefix purview: <tag:stardog:api:catalog:purview:>

select ?graph ?host ?tenant {
    graph ?graph {
        ?dataset a purview:Purview ;
                 rdfs:label ?host .
        optional { ?dataset purview:tenantId ?tenant }
    }
}

A newly registered provider is picked up within a few minutes and imports on its own; stardog-admin catalog reload urn:purview_v2 starts that first import immediately, and stardog-admin catalog remove urn:purview_v2 removes the provider and drops the graph it imported, deleting that metadata. On a Stardog installation that was upgraded rather than newly created, run stardog-admin catalog reload-model as well, or the Unified Catalog classes below will be missing from the catalog’s schema.

The data products of each governance domain, with their status:

prefix purview: <tag:stardog:api:catalog:purview:>

select ?domain ?product ?status {
    graph purview:AZURE_TENANT_ID
    {
        ?d a purview:BusinessDomain ;
           rdfs:label ?domain ;
           purview:hasDataProduct ?p .
        ?p rdfs:label ?product ;
           purview:status ?status .
    }
}

The tables and columns behind a data product, which is how a governed business concept reaches the physical data implementing it:

prefix purview: <tag:stardog:api:catalog:purview:>

select ?product ?asset ?column {
    graph purview:AZURE_TENANT_ID
    {
        ?p a purview:DataProduct ;
           rdfs:label ?product ;
           purview:hasDataAsset ?da .
        ?da purview:backedByEntity ?a .
        ?a rdfs:label ?asset .
        optional { ?da purview:hasColumn ?c . ?c rdfs:label ?column }
    }
}

A critical data element reaches its columns differently. purview:governsColumn goes straight from the element to a Data Map purview:Asset, with no data asset and no purview:hasColumn step:

prefix purview: <tag:stardog:api:catalog:purview:>

select ?element ?column {
    graph purview:AZURE_TENANT_ID
    {
        ?cde a purview:CriticalDataElement ;
             rdfs:label ?element ;
             purview:governsColumn ?a .
        optional { ?a rdfs:label ?column }
    }
}

The governed asset may sit outside the collections this import read, in which case it carries only its type. Keep the label pattern in optional, or every element whose asset was not read drops out of the results.

A link can point at an object the import did not read: an asset in a collection you excluded, a governance object in a domain you excluded, or a draft object, which Purview leaves out of the lists the import reads. Stardog keeps the link and creates the object at the other end, so the link leads somewhere. That object carries a name and qualified name where Purview supplies them, and only its type where it does not, so a count of imported objects can include placeholders.

Descriptions from the Unified Catalog keep the rich-text markup Purview stores them with, for example "<div>Revenue after returns and discount<br></div>".

Each run that succeeds replaces what the previous run imported. If the Unified Catalog cannot be read, the Data Map metadata is still imported and the failure is recorded as a warning in the Stardog server log.

Exporting Stardog Metadata

The Purview v2 provider exports data source metadata into the configured Purview account. When the provider’s scheduled job is run the export occurs automatically after the import is completed. Set exportMetadata to false for an account Stardog may only read.

Everything exported goes into a single collection named Stardog Knowledge Catalog, which the provider creates on its first run. The following asset types are registered in the account and used for the Stardog data source metadata:

Containment between them is written as Purview composition relationships, so deleting an exported data source in Purview removes the databases, schemas, tables and columns beneath it.

Entities are matched on their qualified name, so a later run updates what Purview already holds rather than creating a second copy. Anything a Purview user has attached to an exported asset, such as a glossary term or a classification, stays attached across runs.

linkTemplate sets what that qualified name is. It is a URL pattern with an {id} placeholder, replaced with the identifier of the resource being exported, and is typically a Stardog Explorer URL so that an exported asset in Purview links back to the same asset in Stardog.

<tag:stardog:api:catalog:linkTemplate> "https://STARDOG_HOST/explorer/#/graph?db=catalog&query=%60{id}%60" ;

Without a template the qualified name is the Stardog identifier on its own, which is still unique but is not a link a Purview user can follow.

The qualified name is the identity Purview matches on. Adding or changing linkTemplate after the first export changes the identity of every exported entity, so the next run writes a fresh set and leaves the previous entities behind. Settle the template before the first export.

The export never deletes. A data source removed from Stardog leaves its exported entities in Purview until someone removes them.

Data Model

These tables contain the classes used for modeling the Purview metadata. Prefix purview is namespace tag:stardog:api:catalog:purview:.

Data Map plane:

Unified Catalog plane:

Migrating from the Purview provider

There is no automatic migration. You add a v2 provider next to the v1 provider, compare what each imports, and remove the v1 provider yourself.

Leave serverAddress out of the v2 provider, which is the default. The v2 provider then writes to a graph of its own, named after your Entra tenant, and the v1 provider keeps writing to its graph, named after the classic account host. The two do not touch each other, so you can run both while you compare them.

Do not set serverAddress to the classic account host the v1 provider reads. Both providers would write to the same graph, and each reload empties that graph before writing, so they would erase each other’s metadata on every run.

To add a v2 provider:

1. Run stardog-admin catalog reload-model to load the Unified Catalog classes. The model is loaded when the catalog database is created and is not updated on upgrade, so an existing catalog still holds the old one. The reload replaces the schema graph, so back up the catalog database first. See catalog reload-model and Reloading the Catalog Model.
2. Register a v2 provider with the same Entra application and access key. Leave serverAddress out to import both planes.
3. Give the application read access to the governance domains you want. Unified Catalog roles are separate from Data Map collection roles.
4. Wait for the first import, or run stardog-admin catalog reload urn:purview_v2 to start it now, then check what it imported.
5. Remove the v1 provider when you are satisfied.

The v1 provider exported concepts as stardog_concept entities. The v2 provider records a column’s concept as the concept attribute of the column instead. The export never deletes, so stardog_concept entities written by v1 stay in Purview until someone removes them.

The Data Map classes and properties are unchanged, so a query that matches by class or property still works against the v2 graph. The IRIs do change. The graph and every node in it are named after the provider’s dataset, which for v1 is the classic account host and for v2 is your Entra tenant: a collection, asset or term whose IRI began tag:stardog:api:catalog:purview-stardog.purview.azure.com: now begins tag:stardog:api:catalog: followed by your tenant id. Update any query that names a graph or a specific node.

JDBC

The Knowledge Catalog can be configured to use a JDBC driver to import database metadata into the Knowledge Catalog. Any JDBC-compliant driver should work. Be sure to first add the JAR file to the classpath of the Stardog server.

Configuration

The configuration for a JDBC provider requires that credentials be stored in the catalog credential store. See storing credentials for details.

Currently, the JDBC provider expects a username and password for authentication. Add your database username and password to the catalog credential store and use the returned access key to configure the JDBC provider. When the provider import job is run, the standard jdbc.username and jdbc.password properties will be injected to the JDBC connection string.

insert data {
    graph stardog:catalog:providers 
    { 
        <urn:jdbcProvider> a <tag:stardog:api:catalog:JdbcProvider> ;
            <tag:stardog:api:catalog:provider:accessKey> "ACCESS_KEY_HERE" ;
            <tag:stardog:api:catalog:provider:jdbcDriver> "DRIVER_CLASSNAME_HERE" ;  
            <tag:stardog:api:catalog:provider:jdbcURL> "JDBC_CONNECTION_STRING_HERE" ;  
            <tag:stardog:api:catalog:provider:schedule> "SCHEDULE_HERE"  .
    }
} 

This table details the property values that need to be set for configuring a JDBC metadata provider.

Data Model

This table contains the classes used for modeling the Purview metadata. Prefix jdbc is namespace tag:stardog:api:catalog:jdbc: and the catalog prefix is namespace tag:stardog:api:catalog:.

Atlan

The Knowledge Catalog can be configured to import data from Atlan. Atlan is a data catalog platform that provides active metadata management, business glossaries, column-level lineage and search capability.

Configuration

The configuration for an Atlan provider requires that Atlan credentials be stored in the catalog credential store. See storing credentials for details.

Atlan uses an Atlan API token for authentication. For that token to have access to Atlan assets the token needs to be linked to an Atlan Persona that has the required data policies allowing metadata read access. For more information of Atlan policies click here.

If you have an Atlan API token you can add it to the catalog credential store using the CLI or HTTP API as shown below.

curl -u admin:admin --location 'http://localhost:5820/admin/catalog/credentials' \
--header 'Content-Type: application/json' \
--data '{
    "token": "$ATLAN_TOKEN",
    "label": "Atlan API Token"
}'

Once you have a Stardog catalog access key, use it to configure an Atlan metadata provider as shown.

insert data {
    graph stardog:catalog:providers 
    { 
        <urn:atlan> a <tag:stardog:api:catalog:AtlanProvider> ;
            <tag:stardog:api:catalog:provider:accessKey> "ACCESS_KEY_HERE" ;
            <tag:stardog:api:catalog:provider:serverAddress> "CLOUD_URL_HERE" ;  
            <tag:stardog:api:catalog:provider:schedule> "SCHEDULE_HERE"  .
    }
} 

This table details the property values that need to be set for configuring an Atlan metadata provider.

The Atlan API token will need to be associated with at least one persona with metadata policies in order to be able to import any entitiy data. See here for more details.

By default, the Atlan asset types Table, Column, View, Schema, Connection, Database, Purpose are imported into Stardog. If you want to customize the list you can use the <tag:stardog:api:catalog:provider:entityType> predicate. In the following example only table and column entities will be imported.

graph stardog:catalog:providers
{
    <urn:atlan> a <tag:stardog:api:catalog:AtlanProvider> ;
        <tag:stardog:api:catalog:provider:accessKey> "ACCESS_KEY_HERE" ;
        <tag:stardog:api:catalog:provider:serverAddress> "CLOUD_URL_HERE" ;
        <tag:stardog:api:catalog:provider:entityType> "Table" ;
        <tag:stardog:api:catalog:provider:entityType> "Column" ;
        <tag:stardog:api:catalog:provider:schedule> "0 0 3/23 ? * * *" .
}

Metadata imported to Stardog will be found in a graph named for the Atlan serverAddress.

select * {
    graph <tag:stardog:api:catalog:your_domain.atlan.com>
    {
        ?s ?p ?o .
    }
}

Exporting Stardog Metadata

The Atlan provider exports data source metadata into the configured Atlan server. There is no extra configuration required to export Stardog metadata. When the provider’s scheduled job is run the export will automatically occur after the import is completed.

Assets imported into Atlan are added to a Stardog Knowledge Catalog purpose. By default, only the account attached to the API key will have access to those entities details. An administrator will need to attach data policies to the Stardog Knowledge Catalog purpose to allow additional user access.

Datasource metadata from Stardog can be found in Atlan under the corresponding asset type.

The following Atlan asset types are used for the Stardog data source metadata:

After the scheduled provider job has run you can log into your Atlan account and view the Stardog metadata. Stardog metadata is tagged with an Atlan Stardog tag which in turn is attached to a Stardog Knowledge Catalog purpose. You can use the tag and purpose to search and filter for Stardog assets in Atlan.

Data Model

The data model for Atlan assets is dynamic in that each entity type from Atlan is imported and mapped to a generated OWL class. Atlan entity properties are mapped to OWL object properties and OWL datatype properties. Atlan entities are prefixed with the namespace tag:stardog:api:catalog:atlan:.

---