From tables and endpoints to meaning.

The strategy, up front

Integration usually means copying data from A to B and reshaping it in bespoke code that only its author understands. A semantic-model strategy replaces that with a durable, inspectable asset: a set of declarative mappings that say “this table/field means this class/property,” all pointed at one shared ontology. The mappings outlive any single pipeline, and adding a source becomes a bounded, testable task instead of another snowflake ETL job.

This brief is the mapping layer in focus. For the surrounding architecture (federation, serving, entity resolution) see the enterprise knowledge graph strategy; for why an API’s payload must never shape your model, model the domain, not the message.

Everything you need to integrate arrives as one of two shapes, and each resists mapping differently. The target is always the same: the classes, properties and IRIs of the ontology.

Relational sources have a W3C-standard path to RDF, at two levels of ambition.

The recurring patterns

A minimal R2RML map

@prefix rr:     <http://www.w3.org/ns/r2rml#> .
@prefix policy: <https://example.org/ontology/policy/> .

<#PolicyMap> a rr:TriplesMap ;
  rr:logicalTable [ rr:tableName "POLICY" ] ;
  rr:subjectMap [
    rr:template "https://example.org/resource/policy/{POLICY_ID}" ;   # PK -> stable IRI
    rr:class    policy:Policy ] ;
  rr:predicateObjectMap [
    rr:predicate policy:policyNumber ;
    rr:objectMap [ rr:column "POLICY_NO" ] ] ;                        # column -> data property
  rr:predicateObjectMap [
    rr:predicate policy:policyHolder ;
    rr:objectMap [ rr:template "https://example.org/resource/party/{HOLDER_ID}" ] ] .  # FK -> object property

APIs are harder for two independent reasons: there is no queryable schema to push work into, and the payload is a transport shape that tempts you to copy it verbatim.

Four approaches, lightest to heaviest

RML lifting a JSON response — note the domain-shaped target

@prefix rml:   <http://semweb.mmlab.be/ns/rml#> .
@prefix ql:    <http://semweb.mmlab.be/ns/ql#> .
@prefix rr:    <http://www.w3.org/ns/r2rml#> .
@prefix claim: <https://example.org/ontology/claim/> .

<#ClaimFromAPI> a rr:TriplesMap ;
  rml:logicalSource [
    rml:source              "claims-api-response.json" ;
    rml:referenceFormulation ql:JSONPath ;
    rml:iterator            "$.data.claims[*]" ] ;      # one subject per array element
  rr:subjectMap [
    rr:template "https://example.org/resource/claim/{claimId}" ;
    rr:class    claim:Claim ] ;
  rr:predicateObjectMap [
    rr:predicate claim:claimId ;
    rr:objectMap [ rml:reference "claimId" ] ] ;
  rr:predicateObjectMap [
    rr:predicate claim:underPolicy ;
    rr:objectMap [ rr:template "https://example.org/resource/policy/{policy.ref}" ] ] .  # nested field -> domain link

The operational concerns databases don’t have

• No pushdown. You cannot send a filter to most APIs, so you fetch, then filter. That pushes APIs toward materialize-and-cache rather than live virtualization.
• Pagination & rate limits. The adapter must page through results and respect quotas — incremental, resumable, backing off on 429s.
• Auth & secrets. Tokens, refresh, rotation — owned by the adapter, never baked into a mapping file.
• Freshness & caching. Decide a refresh cadence per endpoint; cache responses so a query doesn’t hammer the source.
• Schema drift. APIs version and change. Pin the API version, and let mapping tests catch the day a field moves.

Mapping shapes is only half the job. What turns many sources into one model is agreement on identity and on shared vocabularies.

Two ways to run a mapping. Virtualize: leave the data at source and rewrite incoming SPARQL into the source’s query language on demand. Materialize: run the mapping ahead of time and load the triples into a store. The right choice is per source, and the factors are stable.

The mappings are the most valuable thing this strategy produces. Engineer them accordingly.

• Versioned & modular. One mapping module per source in version control, released on its own clock, each targeting the shared ontology contract — never a sibling’s internals.
• Tested against competency questions. A mapping is done when the questions it must support return correct answers over sample source data. The CQ suite is the acceptance test for integration, not just for the ontology.
• Gated in CI. Validate mapping syntax, run it over a sample, check SHACL conformance on the output, and re-run the CQ regression on every change.
• Lineage-tracked. Register each mapping in the catalog so every ontology term traces back to a column or field — for regulators, and for the engineer chasing a wrong value.
• Clearly owned. Source-facing teams own their mapping module; a central function owns the ontology contract, the IRI policy and the identity crosswalk.

• Phase 0 — foundations. Choose the engines (an R2RML/OBDA engine for databases; an RML processor or adapter framework for APIs), set the IRI-template policy, stand up the CI harness.
• Phase 1 — one of each, end to end. Map one representative database and one representative API to a slice of the ontology. Prove it with competency questions, establish the IRI templates, and make one cross-source identity link.
• Phase 2 — scale & resolve. Onboard more sources, add entity resolution, make the materialize-vs-virtualize call per source, and turn on SHACL conformance and lineage.
• Phase 3 — mapping as a product. Sources become owned mapping data-products with self-service onboarding; add regulator-grade lineage and automated freshness monitoring.

Principal risks & how the strategy absorbs them