Semistructured Integration, Mediators & Ontologies

01 · Setup

Semistructured data & graph models

Semistructured data has some structure, but it is not as prescriptive, regular, or complete as in a traditional DBMS. Web pages (HTML), XML documents and various cloud/NoSQL models are the everyday examples — and they are all different, so they do not lend themselves to easy integration.

The unifying representation is a graph (or tree): labelled nodes, labelled arcs, or both. An XML document maps naturally onto such a graph, where the irregularity shows plainly — one <model> node has a rank, another does not. A well-organised graph-based model the course names is OEM (the Object Exchange Model), used internally by the mediator we meet next.

<producer>
  <mn-name>Mercury</mn-name>
  <year>1999</year>
  <model>
    <mo-name>Sable LT</mo-name>
    <front-rating>3.84</front-rating>
    <side-rating>2.14</side-rating>
    <rank>9</rank>
  </model>
</producer>

The goal is to integrate, query and compare data of different structures — including semistructured data — as if it were all structured, building an overall representation progressively as new sources are discovered.

“As if it were all structured” means an actual translation, and that translation is the graded first step of the semistructured Part II. Click through the document and watch each element land in the relational schema:

02 · Architecture

Mediators & the TSIMMIS pattern

Across genuinely different data models, plain GAV/LAV mappings are no longer sufficient: the middleware needs a mediator. Mediation (Wiederhold’s term) bundles the processing to make interfaces work, the knowledge structures that drive data-to-information transformations, and any intermediate storage — and each domain needs its own mediator designed to understand that domain’s semantics.

The general architecture is a separation of concerns: the mediator deals with source distribution (which source holds what, how to combine), while each wrapper deals with source heterogeneity and autonomy. A common language runs between them, and each source’s wrapper exports that source’s schema, data and query-processing capabilities.

03 · The exercise

Integrating a semistructured source

The lecture’s worked case integrates a relational source with an XML one. The relational source is ordinary tables (SHOW, CASTMEMBER, CAST, AGENT, ROLE, CASTROLE); the XML source is described by a DTD:

<!ELEMENT TvShowsDB (TvShow*)>
<!ELEMENT TvShow (Anchor+, Schedule)>
<!ELEMENT Schedule (Day+)>
<!ELEMENT Day (Guest+)>
<!ATTLIST TvShow Title CDATA #REQUIRED Edition CDATA #REQUIRED Duration CDATA #REQUIRED>
<!ATTLIST Anchor Name CDATA #REQUIRED EngagementFee CDATA #REQUIRED AgentPhoneContact CDATA #IMPLIED>
<!ATTLIST Day Date CDATA #REQUIRED Special (0|1) "0">
<!ATTLIST Guest Name CDATA #REQUIRED EngagementFee CDATA #REQUIRED Address CDATA #IMPLIED>

Here is a full semistructured exercise to work end to end — an XML (DTD) patent source integrated with a relational one, with the relational translation, conflict table, GAV mapping and rewriting:

04 · Exam-hot

Wrappers for web & semistructured sources

A wrapper converts queries into commands the specific source understands (and may extend a source’s query capability — e.g. carrying instructions to solve currency or measure-unit conflicts), then converts the results back into the application’s format. For structured sources (relational ↔ object-oriented) this is easy; for unstructured data it is hard.

For web pages, the wrapper does information extraction: source format is plain text with HTML tags (no semantics), target format is a relational table / XML / JSON (which adds structure, i.e. semantics). It is a software module running an extraction step whose rules exploit the marking tags — much easier when the page’s structure is itself derived from a database.

05 · Semantics

Ontologies, RDF & Linked Data

To recognise data semantics — not just structure — integration reaches for ontologies. An ontology is a formal, shared specification of a conceptualization: a controlled vocabulary of terms and their inter-relationships (synonymy, homonymy, hyponymy, IS_A, PART_OF, plus designer-defined domain relations). In that sense an ER schema or class diagram is a kind of ontology — with one caution: an ER schema has no values, whereas an ontology also carries instances.

On the Web, ontologies power the Semantic Web (Berners-Lee): giving information explicit meaning so machines can process and integrate it. The layering the exam may probe:

• XML — surface syntax for structured documents, but imposes no semantic constraints.
• RDF — a data model of triples subject–predicate–object (node → edge → node/literal), serialisable in XML (or Turtle).
• RDF Schema — vocabulary for classes and properties with generalization hierarchies.
• OWL — richer still (class disjointness, cardinality, equality, property characteristics); three sublanguages OWL Lite / DL / Full.

Triples chain, and that is the whole reason a triple store is a graph rather than a three-column table:

Ontologies support integration in two ways: as a semantic aid to schema/instance conflict resolution (via ontology matching — similarity that respects meaning, not just string shape), or instead of a global schema — source ontologies are extracted from the sources and mapped to a domain ontology used directly for querying. Matching must survive mismatches at the language level (syntax, available constructs) and the ontology level (scope, coverage/granularity, modelling paradigm, encoding, homonymy/synonymy). The key subtlety when ontologies meet databases is the Closed-World Assumption (a DB tuple not present is false) versus the Open-World Assumption an ontology makes — the same soundness/completeness tension from the GAV/LAV chapter, now semantic.