Business Glossary Field Mapping: A Practical Guide
Business glossary field mapping shows when a glossary and register suffice, when to add an ontology, and how to document and test source-field relationships.
Data stewards and developers often agree on a business term while source systems still use different fields and meanings. A field-mapping register connects that term to the actual table, column, transformation, exceptions, and owner. Use the register to decide when a glossary is enough and when formal relationships or validation rules add value.
Key takeaways
Choose the artifact by its job:
- Define terms in a scoped glossary so people share the intended meaning.
- Connect terms to real fields with a mapping register for source tables and columns.
- Preserve different meanings as conditional, partial, or separate mappings.
- Use an ontology when applications need formal relationships and reasoning.
- Make reviewed mappings available to agents when the workflow needs agent retrieval.
Do I need a glossary, a field-mapping register, or an ontology?
Choose the artifact by the question you need it to answer. A glossary explains what a business term means; a mapping register identifies which source fields carry that meaning and under which conditions; a formal ontology represents concepts and their relationships in a form software can interpret.
A controlled vocabulary can be a useful starting point for the glossary. The W3C SKOS Recommendation provides labels such as preferred and alternative terms, along with hierarchical relations for broader and narrower concepts and associative relations for related concepts. Those features help teams represent synonyms and concept links without turning every term definition into a formal rule about how the world must work.
An ontology adds formal structure when software needs to use relationships as rules. In the W3C OWL 2 overview, OWL 2 ontologies have formally defined meaning and provide classes, properties, individuals, and data values. Reasoners can use that formal meaning to answer questions such as whether a class is consistent or whether one class falls under another. Choose this path when those capabilities solve a real task, such as consistency analysis or deriving classifications under the selected formal semantics. Required-field and business-rule checks need explicit validation rules; OWL reasoning is not ordinary closed-world field validation.
A field register remains useful alongside either choice. A glossary can settle that “customer” means the organization buying a service, for example, while the register shows that a CRM account column, an ERP order-party field, and a billing identifier each match that term only within a defined process or scope.
What belongs in one term-to-field mapping record?
Create one record for each source field and shared term relationship. Include enough context for another developer or steward to reproduce the decision and distinguish it from a similar-looking field.
| Record field | What to capture |
|---|---|
| Shared term and definition | The approved business label and the scope the definition covers |
| Source location | System, dataset or table, field or column, and schema version |
| Source meaning | The field's documented meaning, including allowed values or grain where relevant |
| Mapping relationship | Direct, conditional, partial, related, or distinct, with a short reason |
| Rule or transformation | Filters, joins, code translations, normalization, or derivation needed to use the field |
| Evidence and stewardship | Source documentation or example record, review date, accountable owner, and status |
A data dictionary explains a dataset’s variable names and values. As a proposed worksheet entry, record the definition, data type, allowed values, and source owner for customer_id. A cross-system mapping adds a second question: how does that particular field relate to an approved shared term and to fields in other systems?
Keep the mapping close to its evidence. The W3C PROV-O specification models provenance through entities, activities, and agents: source data and mapping versions can be treated as entities, a transformation as an activity, and a responsible owner or process as an agent. Its derivation relationships can connect an output to the entity it came from, which gives teams a practical model for tracing a transformed value back to an input.
How should I map fields when names or meanings differ?
Map by meaning and scope rather than by column-name similarity. Use a relationship label that tells the next user whether values transfer directly, need a condition, represent only part of the shared concept, or should remain distinct.
The following is a hypothetical mapping scenario. It assumes the business has defined “business party” broadly, while keeping the operational roles separate; actual field meanings must be confirmed from each source system's schema.
| Source field | Candidate shared term | Relationship | Use condition or rule |
|---|---|---|---|
CRM Account | Business party; customer organization | Conditional | Use as a customer organization only for account records classified as customers; exclude prospects and partners |
ERP Sold-to Party | Business party; ordering party | Role-specific | Preserve the order-level role; connect to the customer organization only when the party identifier and business rule confirm the match |
Billing Customer Number | Business party; billing identifier (confirm meaning from schema) | Schema-dependent | In this hypothetical, confirm from the actual schema whether the field identifies the bill-to party, the payer, or another billing role. Bill-to party and payer are separate roles; do not treat them as equivalent without evidence |
The shared parent concept gives systems a point of comparison, while each mapped field retains its role. If the same organization buys and pays, an approved entity link may connect the roles. If a parent company places an order for a subsidiary, preserve the distinction in the mapping rather than forcing both source fields into one “customer” field.
Document transformations as executable logic or precise steps. In the W3C R2RML code-to-IRI example, an SQL view computes an IRI from a database value, and SQL CASE is convenient for that purpose. For a business register, the same practical principle is to capture the input, condition, and output, such as “when country_code is US, convert state abbreviations to the approved region code.” Mark this as a transformation, not a direct equivalence.
For each transformation or join, document units, currency and timezone where applicable, null handling, expected cardinality, and whether join keys are unique.
How do I test and maintain a mapping before reuse?
Review the mapping in order, using representative data and the people who own the business meaning. Keep source freshness and business approval as separate checks: an updated table schema calls for remapping review, while a changed business definition calls for steward approval.
- Trace the source: Confirm the current system, dataset, field, definition, data type, and schema version. Link the record to the source documentation or an approved sample.
- Test the meaning: Ask the domain owner what the field means in a real workflow. Compare values from ordinary records and edge cases, such as prospects, subsidiaries, refunds, or multiple bill-to parties.
- Exercise the rule: Run the documented filter, join, or transformation on representative records. Check that the result matches the target term's scope and that exceptions remain visible. Verify join-key uniqueness and expected cardinality: a semantically plausible join can still duplicate rows and inflate totals.
- Record coverage and exceptions: Mark unmapped values, partial matches, and unresolved cases. Record a test date, sample scope, result, and reviewer so another team can assess how current the evidence is.
- Review changes: Revisit the mapping when a source field, transformation, business definition, or downstream use changes. Assign an owner to update its status and version before other teams rely on the changed relationship.
As a practical recommendation, record the tested dataset or mapping version, the metric or rule applied, and the result. For example, a completeness check can report the share of records with a usable customer identifier, while a separate reconciliation check can report whether mapped party identifiers resolve to an approved entity record.
A mapping is ready for reuse when its term and scope are approved, the source location and version are traceable, transformations are repeatable, and a named owner can review changes. Keep unresolved exceptions in the record with their status so downstream teams can handle them deliberately.
Where can an agent-facing team keep documented mappings?
Store mappings where reviewers can maintain them and authorized consumers can find them. Give each mapping a stable ID, source ID and revision, effective date, positive example, counterexample, unresolved exceptions, and proposed, approved, or rejected status. Preserve prior decisions when meaning changes, then retest downstream joins and answers.
Keep source evidence restricted to audiences authorized to access it, and ensure any synthesized definitions respect the permissions on the underlying information.
Choose a catalog or governed documentation space when people mainly need to search and approve records. Consider a versioned knowledge store when agents also need to retrieve mappings.
AKB is one option for that agent-facing use. It supports documents with revision history, tables, files, and explicit relations, so teams can keep mapping records alongside related concepts when that fits their knowledge workflow. The AKB product overview groups documents, tables, and files under one address scheme. This makes AKB a possible home for a documented mapping register; the team still defines and governs the mapping decisions.
Agents can read and write through AKB’s akb_put, akb_search, akb_browse, and akb_relations tools. Individual developers can use an agent-facing knowledge store for mappings shared across project work; enterprise knowledge teams can organize approved terms and source relationships for broader retrieval. AKB core is a read/write knowledge store; teams should treat external review, curation, and refresh as separate operating processes.
When is a register enough, and when should I add an ontology?
Use a glossary and mapping register when the practical need is shared wording, traceable source fields, and explicit conditions for using them. Expand the model when the application needs formal inference; add explicit validation when it needs required-field or business-rule checks. These are separate decisions.
- Choose a glossary when teams need consistent definitions, preferred labels, synonyms, and a small set of concept relationships.
- Add a field-mapping register when each source system represents a shared term differently or a field applies only within a given role, process, or population.
- Use a semantic layer or metric store when teams need a named, reusable business measurement; DataHub’s metric model distinguishes a metric’s semantic-model upstream fields from their lineage to physical columns.
- Use an ontology when software must interpret formal classes and properties or reason over relationships to support a defined application.
- Combine the artifacts when the work needs all three layers: terms for people, mappings for source alignment, and formal semantics for machine reasoning.
Start with one high-value term, such as customer organization or active contract, and map it across a small number of source systems. Test its scope with real examples, record exceptions, and let those findings show whether a glossary and register answer the task or whether formal ontology capabilities add needed value.
Connect the term to a reproducible field record
Use a glossary for approved meanings, a mapping register for source fields and conditions, and an ontology only when formal relationships or reasoning are needed. Keep each mapping reproducible by recording its source and version, relationship, transformation, exceptions, owner, and review date.
Related background: A Shared Business Vocabulary Without a Full Ontology Project
FAQ
What is an example of a data dictionary?
For example, a data dictionary entry for invoice_date could read: “Date the invoice was issued; date format; one value per invoice.” That entry describes the field in its dataset; a term-to-field mapping connects it to a shared term and records how its meaning differs across systems.
Read the AKB documentation
Review the documented knowledge and integration workflows for your AKB deployment.
