Skip to content
Reliable Context
Read the paperRequest access

Glossary

Schema alignment

Schema alignment maps fields and relationships across sources while accounting for differences in meaning and scope.

Knowledge fusion

Schema alignment identifies which concepts in different data structures correspond and where they do not. Matching column names is only a first clue. Two fields named status may refer to regulatory approval, recruitment or publication, while differently named fields may express the same concept. Alignment can be exact, conditional, broader, narrower or impossible, depending on definitions and permitted values.

In practice, analysts compare field documentation, sample values, units, temporal rules and source purpose. A mapping may require a transformation or a context condition rather than a simple rename. For example, a country code needs its coding scheme and date to be understood. Mappings should be versioned when source schemas change, so earlier data can still be interpreted correctly.

A defensible fused value requires a defensible mapping. If the meaning of a source field was broadened in translation, a later reviewer cannot know what the value originally asserted. Ontologies supply explicit concepts and relationships; schema alignment relates actual source structures to them; knowledge fusion uses those mappings to compare or combine claims.

Example

A Halden Therapeutics AG (fictional) dataset calls a field site, but its documentation means study location rather than registered office; the fields are not aligned.

Kinds of mismatch

Sources differ in ways that fall into recognisable categories. Naming differences give the same concept different labels, such as sponsor and registrant. Structural differences split or combine fields, such as a single address string against separate street, city and postcode. Granularity differences record the same thing at different levels, such as a country against a city. Semantic differences use the same label for different concepts, such as status meaning legal status in one source and workflow status in another. Value-level differences use different codes, units, calendars or controlled vocabularies for the same concept. Only the first is solved by matching names, and the last two are the ones most likely to produce a wrong merge that looks like a right one.

Automatic matchers combine name similarity, structure, instance values and external dictionaries, and their quality is compared in the yearly Ontology Alignment Evaluation Initiative. The reference text on the subject is the book by Euzenat and Shvaiko, listed below. For vocabularies, the SKOS standard provides mapping properties of graded strength, from exact match to close match to broader and narrower match, which allows a mapping to say how much equivalence is claimed and not only that a link exists.

Documenting a mapping so it can be reviewed

A mapping is a set of claims about two schemas, and each claim should say what is asserted, how strongly, and on what basis. A useful record has, for each source field, the target concept, the transformation applied (unit conversion, code lookup, parsing), the strength of equivalence, the author or tool that proposed it, the reviewer who accepted it and the date. It also records the scope in which the mapping holds: a mapping that is exact for the registry may be only approximate for a scraped directory using the same label.

Mappings are then tested like any other claim set. Use a sample of records with known correct target values, run the mapping, and compare. Test the negative cases as well, for fields that should not map, since false mappings are the costly kind. The article on ontology crosswalk acceptance tests sets out such a test, and the one on ontology term retirement covers what to do to existing mappings when a target term is deprecated.

A worked example

Two sources describe organisations. Source A has a field named type with the values company, university and agency. Source B has a field named category with codes 1 to 9 defined in a separate document. A name-based matcher would link type to category. A reviewer reading the code list finds that code 4 covers both universities and research institutes and that code 7 covers government agencies and non-profits. The mapping from A to B is therefore many-to-one for some values and cannot be reversed. It is recorded with the strength narrower-than for those values and a note that company in A maps to three of B's codes depending on a second field. Without that review, the merged table would have shown categories that neither source had stated.

Related terms and boundaries

Alignment makes comparison possible and sits before data conflict detection: two sources cannot be said to disagree until their fields are known to mean the same thing. It is guided by an ontology where one exists, and it is a precondition of knowledge fusion and data fusion. It is distinct from entity resolution, which aligns the records and not the fields.

Checks a reviewer can run

Ask for the mapping specification with its strength of equivalence for each field. Test a sample of mapped values against known correct targets, including negative cases that should not map. Ask who approved each mapping and when. Ask what happens to existing mappings when a target term is retired.

Common misreadings

  • Mapping fields by label alone.
  • Ignoring units and effective dates.
  • Treating a broader concept as an exact equivalent.

Related terms

Appears in

Further reading on this site

References

Found an error on this page? See corrections for what counts as one, how to report it and the dated log.

Enquiry

Where does "Schema alignment" bear on a decision of yours?

This entry sits under knowledge fusion. If a decision in your organization turns on it, send the entity concerned, the sources you fuse to describe it and who may read which of them. We reply with what a first record would cover.

Open a structured enquiryContact and what happens next

Or write to [email protected] in your own words.