Can the same word produce several structural terms?

Yes. Different contexts produce different pairs, and a representation may retain more than one path context.

Does a structural term have to use the full root-to-word path?

The context scheme can vary. The source model discusses paths and context-term pairs; implementations must state which paths they retain.

Does it solve synonym matching?

Not by itself. It adds structural context to vocabulary terms, rather than automatically equating different words.

AI Glossary / Retrieval and knowledge systems / Intermediate

Structural term

Definition

A structural term, in the XML retrieval model used here, is a pair consisting of a vocabulary term and its structural context. The context is a path of document elements ending at that term. It lets a search system distinguish the same word appearing in different document roles.

What it means

An ordinary word-based index can record that Lee occurs in a report. A structural term can additionally record whether Lee occurs under author, title or another element. That distinction matters when a user wants reports written by Lee rather than reports merely mentioning Lee.

The term has a specific meaning in this retrieval model. It is not simply an XML tag, a grammatical word category or every possible subtree of a document. The source model treats paths ending in one vocabulary term as a manageable compromise between plain words and much richer structural features.

A useful representation therefore preserves both content and context. Neither the word alone nor the element path alone fully expresses the intended feature.

How it works

A parser identifies the document's element structure and tokenizes text into vocabulary terms. For a chosen context representation, it creates pairs such as <report/author, lee>. Another occurrence of lee under report/title produces a different structural term.

These pairs can become dimensions in a vector representation or keys associated with postings. A structured query is represented similarly. Exact context matching distinguishes roles strictly; relaxed matching may allow additional intermediate elements while giving closer structural matches more weight.

The context policy affects the number of features and the amount of evidence available for each. Full paths make fine distinctions but can fragment statistics. Shorter contexts merge more occurrences and may lose meaningful differences. Schema mappings may also be needed when different sources use different names for the same role.

Three practical examples

An archive search distinguishes a person's name in the author element from the same name in a report title.
A product search distinguishes a color word in a specification field from that word in an unrelated description.
A structured document search gives different treatment to a term in a section heading and the same term in a citation.

Think of it this way

Think of an address label attached to a word. The word says what the token is, and the address says where it belongs in the document's organization.

The analogy is limited: a structural address does not automatically establish the meaning of a field across every source. Two buildings can use the same room label differently, just as two schemas can use the same element name for different concepts.

Worked example

The same words, different roles

Consider two invented reports using lowercase tokens. Report A has author = Lee and title = River. Report B has author = River and title = Lee. Each document contains exactly the same two words, so a simple presence-based bag of words cannot distinguish their roles.

Using only the full contexts specified here, A has <report/author, lee> and <report/title, river>. B has <report/author, river> and <report/title, lee>. The combined feature vocabulary therefore contains four distinct structural terms.

A query asking for author Lee matches A's author feature and not B's title feature under exact context matching. If a third source places Lee at report/metadata/author, a rule allowing an intervening metadata element may also recognize that match. Such relaxation must be declared; it does not follow from plain word equality. The example is a feature-matching exercise, not a complete ranking formula.

Illustrative case study

The fictional MapleArchive team receives reports from two departments. One department stores the document author directly below report, while the other adds a metadata wrapper. A strict full-path index separates the corresponding occurrences.

The team introduces a reviewed context mapping so searches for authors can cover both structures. It keeps title occurrences separate, since merging every appearance of a name would reintroduce the original role confusion. It also checks whether query explanations show which field supplied the match.

The case illustrates the balance between structural precision and tolerance of harmless schema differences. It reports no actual retrieval improvement or universal mapping rule.

Common misconceptions and mistakes

A structural term is just the word. It also includes the specified structural context.
Every lexicalized subtree is a structural term in this model. The chosen structural terms are paths ending in a single vocabulary term.
More detailed paths always improve search. Greater specificity can create sparse statistics and mismatches across equivalent source structures.

Business use

Structural terms can improve field-sensitive search when the location of a word carries meaning. They are useful in XML collections and provide a conceptual foundation for other forms of structured content retrieval.

Choose contexts according to the questions users need to ask. Keep authorship, title, body content and references distinct where those distinctions affect relevance. Test equivalent schemas and deliberately confusing cases, not just identical field names. When computing term statistics, specify whether counts apply to whole documents, elements or context-term pairs. The resulting weights should reflect the representation actually used by the search system.

Check your understanding

Are <report/author, chen> and <report/title, chen> the same structural term?

Answer: No. The vocabulary term is the same, but the contexts differ. Treating them separately preserves the distinction between authorship and title content.

Related terms

Schema heterogeneity
XML retrieval
structural context
vocabulary term
lexicalised subtree
vector space model
fielded search
context resemblance

Learn next

Read XML retrieval and schema heterogeneity. Create a small document tree and list context-term pairs under two policies: full paths and immediate-parent contexts. Note which distinctions each policy preserves.

Schema heterogeneity

Sources

Christopher Manning, Prabhakar Raghavan and Hinrich Schutze, Introduction to Information Retrieval, A vector space model for XML retrieval: https://nlp.stanford.edu/IR-book/html/htmledition/a-vector-space-model-for-xml-retrieval-1.html

The authors' precise context-term definition and distinction from general lexicalised subtrees were read. The two-report representation and third-source variation are original. This entry retains the source-specific XML retrieval meaning rather than treating structural term as a universal label across all AI methods.

Previous: Structural similarity (SSIM) Next: Structural time series model