Save a Model as RDF/TTL

erwin Data Modeler (erwin DM) lets you export your models as RDF (Resource Description Framework) and Turtle (TTL). This capability adds business meaning to your existing data models so that knowledge graphs, semantic tools, governance platforms, and AI agents can use them directly.

Traditionally, erwin DM captures database structure: tables, columns, keys, data types, and relationships. It exports that structure as an .erwin model, SQL DDL, or XML. With RDF/TTL export, the same model becomes a semantic asset. Each foreign key becomes a named, business-meaningful relationship instead of a plain reference.

Why Use RDF/TTL Export

RDF/TTL export extends traditional data modeling by adding semantic context that supports governance, interoperability, and AI use cases.

Traditional Data Modeling

Data Modeling with RDF/TTL

Database design

Database design plus business knowledge

SQL generation

Knowledge graph generation

Used by database administrators

Used by database administrators, governance teams, and AI agents

Foreign keys

Semantic relationships

Human-readable models

Machine-understandable context

When you use RDF/TTL export, you get these benefits:

  • Existing data models become a foundation for enterprise knowledge graphs.

  • Business definitions and relationships are reused by semantic tools instead of being recreated manually.

  • AI agents gain structured context about entities such as Customer, Product, Order, and Store, which improves the accuracy of generated answers and reduces incorrect answers.

  • Integration with governance platforms and semantic technologies is easier because RDF/TTL is an open standard.

  • Your organization can build graph-based applications while continuing to use erwin DM as the primary modeling environment.

Export a Model as RDF/TTL

To export a model as RDF/TTL:

  1. Open a model and select Save As from the File menu.
    The Save As window appears.
  2. On the Save As window, enter a name for the file in the File name field and select one of the following options from the Save as type drop-down.

    • RDF/TTL Ontology Files (*.ttl): Files that define the structure, vocabulary, and semantics of a domain. They contain classes along with properties and relationships derived from the model.

    • RDF/TTL Constraint Files (*.ttl): Files that define validation rules that RDF data must comply. They represent sample or reference data.

    TTL file options available in the Save As dialog

  3. Select Save.

The export generates a standards-based TTL file that any RDF-compliant tool can read.

To use the model, import the exported TTL file into your target semantic platform. Because the output follows standard RDF/TTL specifications, no proprietary connectors are required, making it easy to move and reuse the model across RDF-compliant tools and environments.

The following scenarios show how AI agents and semantic tools use exported RDF/TTL to solve real enterprise problems. Each scenario includes two approaches:

  • An AI-agent-driven approach, where an AI agent parses the exported RDF/TTL and performs additional reasoning or automation.

  • A direct ingestion approach, where semantic tooling or CI pipelines consume the exported RDF/TTL without an intermediate AI agent.

Scenario A: Enterprise Data Catalog Onboarding

Consider a scenario when your organization needs to onboard model semantics into an enterprise data catalog or knowledge graph.

Problem: Data governance teams struggle to ingest ER model semantics into RDF-based catalog and knowledge graph tools because model metadata is trapped in proprietary structures that aren't directly consumable by semantic tooling.

Solution: You export the model as an RDF/TTL Ontology File. The exported file includes classes and datatype properties that represent your model's entities and attributes, so the semantics can be ingested directly by semantic tooling or parsed by an AI agent for further enrichment.

Approach 1: AI Agent Enrichment

In this approach, an AI agent parses the exported RDF/TTL Ontology File and enriches your enterprise catalog automatically.

  1. The architect uses erwin DM to export the model as .ttl and provides it to the AI agent.
  2. The AI agent parses the exported classes and properties.
  3. The AI agent links business glossary terms to the parsed classes and properties, and flags any gaps it finds.
  4. The catalog is automatically enriched with the linked terms and flagged gaps.

Example output:

	erm:Customer a owl:Class ;
			rdfs:label "Customer" .

Approach 2: Direct Ingestion by Semantic Tooling

In this approach, semantic tooling ingests the exported RDF/TTL Ontology File directly, without an AI agent as an intermediary.

To get the an RDF/TTL Ontology File, follow these steps:

  1. Select a model in erwin DM.
  2. Save the model as an RDF/TTL Ontology File.
  3. Review the output. It includes an owl:Class entry for each entity and an owl:DatatypeProperty entry for each attribute.

Then, your catalog pipeline ingests the TTL file and automatically links terms to your enterprise ontology. Your governance team queries lineage and definitions across systems using RDF and SPARQL workflows.

Example output:

	erm:customer_address a owl:DatatypeProperty ;
			rdfs:domain erm:Customer ;
		rdfs:range xsd:string.

Scenario B: Pre-Deployment Contract Validation

Consider a scenario when your team needs to validate data contracts, such as required fields and cardinality, before deploying a model-backed schema.

Problem: Teams deploying JSON, OpenAPI, or BigQuery-backed models often miss requiredness and cardinality constraints, which causes runtime validation failures after deployment.

Solution: You export the model using constraint mode and generate the RDF/TTL Constraint File. Constraint mode converts attribute metadata, such as required fields, minimum and maximum item counts, and nullability, into shape-style TTL constraints so that constraints can be validated before release.

Approach 1: AI Agent Generated Validation Tests

In this approach, an AI agent reads the semantic constraints in the exported RDF/TTL Constraint File and generates validation tests for your CI pipeline.

  1. Export the model as an RDF/TTL Constraint File.
  2. The AI agent extracts required fields and data types from the exported constraints.
  3. The AI agent generates positive and negative test payloads based on the extracted constraints.
  4. Your CI pipeline validates the contracts using the generated payloads before release.

Example output:

	erm:OrderShape a sh:NodeShape ;
			sh:targetClass erm:Order.

Approach 2: Direct Constraint Ingestion in CI

In this approach, your CI pipeline ingests the generated shape constraints directly, without an AI agent generating the test payloads.

  1. Model a BigQuery, OpenAPI, or similar entity that includes array fields and required fields.
  2. Save the model as an RDF/TTL Constraint File.
  3. Review the generated TTL. It encodes cardinality and datatype constraints as sh:minCount, sh:maxCount, and datatype statements.
  4. Your CI step validates sample payloads against the generated shapes before deployment.

Constraint mode is intended for pre-deployment validation. Review generated shapes against your actual schema requirements before you rely on them in a production CI pipeline.