Connect meanings across contexts

Work within the established boundaries

OPDA’s six property bounded contexts are Finance and Banking, Conveyancing, Estate Agency, Surveying and Valuation, Property Data Services, and Property Technology. These boundaries are established inputs for this development phase. A teaching exercise does not rediscover them from form ownership, repository folders or software deployments.

The DBT Smart Data group supplies scheme-level meaning; it is not a seventh property bounded context. The Interoperability Working Group owns the small common boundary and agreements between contexts, without taking over each context’s internal definitions. A later boundary change would need its own governance decision.

One semantic home identifies responsibility for a resource’s definition. Several contexts may consume it. An externally governed term retains its external home. Shared use alone is not a reason to move a resource into the common boundary: that requires an agreed identity criterion, stable exchange meaning and the appropriate review.

Keep definition authority separate from accountable stewardship, subject matter and discovery provenance. A surveying term can be about a financial risk; an editor may be accountable for its record; the evidence may have been found in a lender’s document. None of those facts silently transfers ownership of the definition.

Two records, two commitments

The strategic record identifies the map projection, participants, relationship kind and any permitted side-specific patterns. Its question is how contexts relate in that projection. The term-mapping record identifies the subject and object terms, the selected SKOS predicate, their source systems and the evidence for the correspondence. Its question is how those particular meanings correspond.

ODR-0064 joins them through an applicableMapping link to an individual sssom:Mapping. It does not link only to a whole mapping set. A set may contain correspondences for several context pairs; membership in the same set cannot establish that every mapping applies at this seam.

The endpoint terms’ source identifiers name vocabularies or identifier systems. The contexts’ authority over those systems must be explicit. Do not infer it from URL prefixes, a context label in a file name or which team uploaded the mapping. Namespace-based systems have additional structured namespace metadata; not every identifier system is namespace-based.

A mapping’s subject/object order is independent of upstream/downstream direction. Reversing a DDD arrow must not silently reverse a broader/narrower term correspondence. The applicability test accepts either endpoint assignment when the two contexts govern the corresponding source systems, while preserving what the mapping itself says.

Let the kind determine the shape of the relationship

In the selected local profile, Partnership and Shared Kernel are symmetric relationships between two distinct participants. Separate Ways is a symmetric, explicit non-integration decision. Customer/Supplier and Upstream/Downstream are directed: they distinguish the upstream and downstream contexts. A symmetric agreement must not acquire an arbitrary “upstream” just to fit an arrow template.

Directed relationships can carry compatible side patterns. Published Language and Open Host Service are upstream options. Anti-Corruption Layer and Conformist are mutually exclusive downstream options, not mandatory additions to every relationship. Here an anti-corruption layer concerns protecting the downstream model’s meaning through translation; it is not a cybersecurity claim or an instruction to deploy a particular service.

Some combinations are deliberately narrower in the adopted OPDA profile than DDD terminology in general. Customer/Supplier with Conformist or Open Host Service violates this profile; Customer/Supplier with Anti-Corruption Layer receives a review warning. Teach those as local validation rules, not universal laws of organisational collaboration.

The same pair can have more than one named relationship when the records express distinct strategic facts. Equal endpoints do not make records duplicates. Conversely, two opposed directed records are not a substitute for one symmetric relationship; reciprocal directions merit review.

Every answer is relative to one map

A map is a named active projection with an AS-IS or TO-BE state. A relationship belongs to exactly one such map. Every used endpoint is explicitly internal or external relative to that map. Missing classification means unknown, not internal. Neither a named graph nor an organisation’s hostname supplies that meaning.

Consider a current-state map and a proposed target-state map. The target introduces a new directed connection. A query over both without map scope can report the proposed connection as current, or stitch a path together using one edge from each projection. Every individual edge may be valid while the resulting answer is false for both maps.

The adopted reachability contract therefore first builds an ephemeral graph from the chosen map’s directed endpoint arcs, then evaluates reachability within that graph. It returns distinct results and excludes the seed even through a cycle. The answer indicates candidate downstream influence in the model, not demonstrated runtime impact on an application.

Not recorded, excluded and Separate Ways are different

No relationship in the data can mean the map is incomplete. An explicit map-wide exclusion says a relationship kind is excluded in that projection and requires evidence for that exact assertion. Separate Ways records a positive decision between a named pair. Zero rows cannot establish either of the latter conclusions.

A Separate Ways record has no direction, side patterns, applicable mappings or missing-mapping coverage obligation. A map-wide exclusion can be checked against its member relationships for contradiction. Evidence attached somewhere on the map is insufficient: the selected RDF 1.2 reifier must identify the specific excluded-kind statement and its supporting source.