RDF Mapping (RML)

RML uses a declarative approach, where developers specify what the target RDF structure should be, not how to procedurally create it. Rules are defined in a separate mapping document (often Turtle or JSON-LD) that acts as a blueprint, decoupling the transformation logic from the source data. This makes mappings:

• Portable and reusable across different data instances.
• Maintainable, as changes are made in one central document.
• Predictable, enabling validation and reasoning over the mapping logic itself.

A core extension beyond R2RML is RML's ability to map data from non-relational sources. While R2RML only works with SQL databases, RML processors can connect to and iterate over:

• Structured files: CSV, TSV.
• Semi-structured files: JSON, XML.
• APIs: Data retrieved via HTTP requests.

This is achieved through Logical Sources, which abstract the data access method. A single mapping can even join data across these heterogeneous sources (e.g., linking a CSV row to a JSON object from an API).

RML defines how to generate each part of an RDF triple using Term Maps:

• Subject Maps: Create the subject IRI or blank node for a resource.
• Predicate Maps: Define the property (predicate) IRI.
• Object Maps: Generate the object, which can be an IRI, blank node, or literal value.

To perform complex transformations during mapping, RML integrates with the FnO (Function Ontology). This allows the execution of built-in or custom functions within mapping rules, such as string concatenation, date formatting, or mathematical operations, to derive new values directly.

RML supports the creation of relationships between resources through Referencing Object Maps. This is crucial for building a connected graph, not just a flat list of entities. It allows the object of one triple to be the subject of another, defined in a separate mapping rule.

For relational or nested data, RML enables joins using the rr:joinCondition property. This allows a mapping rule to reference data from a different logical source or a nested element by specifying matching keys, effectively performing a graph-like link operation during the mapping process.

RML is a community-driven, open specification maintained by the RML Community. It is formally defined as an ontology (the RML ontology), making the mapping rules themselves machine-readable RDF data. This standardization ensures:

• Interoperability between different RML processor implementations (e.g., SDM-RDFizer, CARML).
• Extensibility, as the ontology-based model allows for custom extensions, such as the RML+ rules for more complex data transformations or the integration with domain-specific function libraries.

RML is a foundational component in Semantic ETL and Knowledge Graph Population pipelines. It typically operates in the Transform phase, sitting between data extraction and loading into a triplestore. An RML mapping document is executed by an RML Processor, which reads the source data, applies the rules, and outputs valid RDF (e.g., N-Triples). This output can then be validated, reasoned over, and loaded. Its role is critical for automating the creation of high-quality, instance-level data (ABox) that conforms to a target ontology (TBox).

RML is used to map data from legacy relational databases and mainframe systems into a modern knowledge graph without altering the source systems. This involves:

• Defining triples maps that map database tables and columns to RDF classes and properties.
• Using RML views or SQL queries as logical sources to perform joins and transformations at the mapping level.
• Generating globally unique IRIs for each entity, enabling linkage with other datasets. This creates a semantic abstraction layer over CRUD-based systems, making their data queryable via SPARQL and integrable with modern applications.

RML processors can parse JSON, XML, CSV, and Parquet files to extract structured facts. This is critical for integrating application logs, API responses, and data exports.

• JSON & XML: Use JSONPath and XPath within RML's referenceFormulation to navigate nested structures and arrays.
• CSV/TSV: Map column headers directly to RDF predicates, often using the file's header row to generate term maps dynamically.
• The mapping defines how to construct subject IRIs from composite keys (e.g., {customer_id}-{order_date}) and how to handle repeated elements as multiple triples. This transforms document-oriented data into interconnected graph nodes, ready for semantic querying.

Organizations use RML to convert dimensional models (star/snowflake schemas) in a data warehouse into a rich, semantically typed knowledge graph.

• Fact and dimension tables are mapped to interconnected RDF resources, preserving business context often lost in flat tables.
• Slowly Changing Dimensions (SCD) can be mapped to temporal RDF using reification or standard temporal vocabularies.
• Complex ETL transformation logic (business rules, calculated fields) is encoded within the RML mapping rules using functions (FnO). This exposes aggregated, business-ready data as a graph, enabling complex graph analytics and path-based queries not possible in SQL.

RML mappings can be applied to real-time data streams (e.g., Kafka, Kinesis) for continuous knowledge graph population.

• A stream processor (e.g., Kafka Connect with an RML SMT) applies the mapping to each message, outputting RDF triples.
• This supports event-driven architectures where business events (new customer, completed transaction) instantly update the graph.
• Mappings must handle incremental updates and deletions, often using named graphs to version streamed data. This creates a live knowledge graph that reflects the current state of operational systems, powering real-time decision support.

RML is used in data harmonization pipelines to prepare datasets for entity linking. While RML itself does not perform matching, it standardizes data for downstream resolution tools.

• Different source schemas for 'Customer' are mapped to a unified target ontology (e.g., schema:Person, org:Organization).
• Data values are normalized (e.g., phone number formatting, address cleansing) using RML functions during the mapping process.
• The output is a consistent RDF graph where entities from different sources share the same class and property types, enabling efficient similarity computation and link discovery with tools like Silk or LIMES.

RML generates rich, queryable metadata (a knowledge graph about data) by mapping technical metadata from databases, APIs, and files.

• Source system schemas, column descriptions, data types, and lineage information are mapped to vocabularies like DCAT, VoID, or PROV-O.
• This creates a semantic data catalog where users can SPARQL-query for data assets based on meaning, not just names.
• The mappings themselves can be described in RDF using the RML ontology, making the integration pipeline self-documenting and part of the enterprise knowledge graph.

Semantic ETL is a data integration methodology that applies semantic technologies—like ontologies and RDF mapping languages—to transform heterogeneous data into a knowledge graph with explicit, machine-interpretable meaning. Unlike traditional ETL, which focuses on format and structure, semantic ETL prioritizes the preservation of semantic relationships and the creation of linked data.

• Core Difference: Transforms data into RDF triples based on a formal ontology, rather than into relational tables.
• Key Components: Involves an ontology (TBox) to define concepts and an RML mapper to generate instance data (ABox).
• Goal: Produces a knowledge graph ready for logical inference and semantic querying, not just analytics.

Knowledge graph population is the specific process of extracting, transforming, and loading instance data—known as ABox assertions—from source systems into the structure defined by an ontology (TBox). RML is a primary tool for this process.

• Input: Raw source data (CSV, JSON, SQL) and a target ontology (e.g., in OWL).
• Process: An RML engine executes mapping rules to generate RDF triples that instantiate the ontology's classes and properties.
• Output: A populated knowledge graph where entities are uniquely identified (via URIs) and semantically connected, enabling complex querying and reasoning.

Ontology mapping is the process of defining semantic relationships—such as equivalence (owl:sameAs) or subsumption (rdfs:subClassOf)—between the concepts and properties of two or more distinct ontologies. While RML maps data to an ontology, ontology mapping aligns ontologies to each other.

• Purpose: Enables interoperability and data integration across different knowledge graphs or domains.
• Common Techniques: Uses declarative languages like SPARQL CONSTRUCT or dedicated frameworks to assert cross-ontology relationships.
• Relation to RML: Often a prerequisite or parallel activity; RML rules may reference terms from multiple aligned ontologies to create a unified graph.

Data harmonization is the overarching process of standardizing data from disparate sources by resolving syntactic (format), structural (schema), and semantic (meaning) differences to create a unified, consistent dataset. RML is a tool for the semantic layer of this process.

• Syntactic: Converting CSV dates to ISO 8601 format.
• Structural: Aligning a nested JSON object to a flat relational schema.
• Semantic: Using RML to map a source field "cust_name" to the ontology property foaf:name, resolving vocabulary conflicts.

In data pipeline orchestration, a Directed Acyclic Graph (DAG) is a finite directed graph with no cycles used to represent a workflow where tasks are nodes and dependencies are edges. An RML-based transformation pipeline is typically orchestrated as a DAG.

• Nodes: Individual tasks like data extraction, RML mapping execution, validation, and graph loading.
• Edges: Dependencies (e.g., mapping cannot start until extraction is complete).
• Orchestrators: Tools like Apache Airflow or Prefect use DAGs to schedule, monitor, and manage the execution of complex RML workflows, ensuring reliability and reproducibility.

A data contract is a formal agreement between data producers and consumers that specifies the schema, semantics, quality, and service-level expectations for a data product. In a semantic pipeline, RML mapping documents can serve as executable technical specifications within a broader data contract.

• Schema: The target ontology (OWL/RDFS) that defines allowed classes and properties.
• Semantics: The RML rules themselves, which define the exact transformation logic.
• Governance: Contracts ensure that changes to source data schemas or the ontology are communicated and that RML maps are versioned and tested accordingly, preventing pipeline breaks.