A Multilingual University Research Data Platform: Architecture, Key Modules, and Cloud Deployment

1. Introduction: A University Split by Language, and a Data Platform That Must Handle Both Split and Merge

In 1834, a public research university was founded in Brussels, in a country with two official languages. Around 1970, a domestic dispute over the language of instruction led it to split into two separate teaching entities: one teaches mainly in French, the other mainly in Dutch. Both still share the name “Free University.” Each, however, is an independent legal and academic institution.

Together, the two cover philosophy and literature, law, social sciences, political and economic sciences, psychology and education, the natural sciences, engineering, and medicine. They also run several teaching and research centers. Both institutions are highly international, with international students making up about 30% of enrollment. Their motto, “Conquering darkness with knowledge,” reflects a strong commitment to academic freedom. Since the university was founded, its alumni have included four Nobel laureates. Among them is François Englert, a theoretical physicist who won the 2013 Nobel Prize in Physics. He is one of the theoretical proposers of the Higgs mechanism. That school of theoretical physics grew out of long-standing work in theoretical physics at the predecessor of the entity that later split off as the Dutch-speaking one. The institution has also ranked among the global top 200 in major world university rankings.

That is the institutional background. What does it have to do with software engineers?

When an institution splits and reorganizes, the change leaves a lasting “language fault line” and “identity ambiguity” in its data:

• One name, two entities. Two independent organizations share one brand. If the master data is even slightly ambiguous, headcount, publications, and project statistics get mixed up.
• Two languages of instruction. French and Dutch coexist. A query for “quantum mechanics” returns nothing when the matching papers are titled in French or Dutch. Keyword search often finds zero results.
• Internationalization. International co-authors are spread across the globe, and data moving across borders raises compliance requirements.
• Multiple faculties. Eight faculties and several research centers follow different data formats, classification schemes, and access boundaries.

The platform’s goal is therefore four “unifications,” while holding two bottom lines.

Four unifications:

• Unified identity. The same person, institution, or research output has exactly one identifier, regardless of name, language, or spelling.
• Unified language. Users can query in any supported language and receive results written in another.
• Unified metrics. Metric definitions are versioned, and results can be recomputed and audited.
• Unified entry point. Search, graphs, analytics, and reports are all served through consistent interfaces.

Two bottom lines: compliance for personal data, and stable, observable services.

The rest of this article takes the “multilingual university research data platform” (hereafter the “research data platform”) as its subject. It starts from the platform’s data characteristics and then covers architecture design, key modules, cloud deployment, and an implementation roadmap.

2. Data Characteristics and Core Challenges

For a platform like this, the hardest problems are usually not in the algorithms themselves. They are “built-in defects” that already exist before data is ingested. From the scenario above, four data characteristics and five core challenges emerge.

2.1 Four data characteristics

Characteristic	Typical examples	Impact on the platform
Multilingual	French and Dutch texts coexist in teaching materials, publications, and official documents. English is the common language of academia. International students bring more languages.	Retrieval recall and statistical analysis tend to show “language bias.”
Multi-entity	Two independent entities share one brand. Research centers sit under individual faculties. Boundaries with affiliated teaching hospitals and external partner organizations are unclear.	Inconsistent master data directly leads to inconsistent metrics.
Multi-source and heterogeneous	HR, academic affairs, research, and finance systems; publication and patent metadata; datasets and instrument output; web pages and official documents	Formats, update frequencies, and data quality vary widely. Unified ingestion and validation are required.
Highly sensitive	Student grades, employee contracts, unpublished review materials, research collaboration agreements	Requires data classification, least-privilege access, and end-to-end auditing.

2.2 Five core challenges

1. Identity ambiguity. A single institution may appear under its full name, an abbreviation, a French spelling, and a Dutch spelling. The institution fields in bibliographic databases are often incomplete as well. Without disambiguation, research output is misattributed between the two entities.
2. The cross-lingual gap. Users ask about “kwantummechanica” in Dutch, while many papers are published in French. A keyword index alone effectively gives up more than half of the corpus.
3. Blurred disciplinary boundaries. The same topic uses different terminology in physics, engineering, and medicine. Cross-disciplinary search therefore needs both a disciplinary ontology and a terminology mapping.
4. Metric trustworthiness. Results such as international rankings, discipline assessments, and research performance scores are quoted and cross-checked repeatedly. Without transparent definitions and reproducible calculations, the conclusions will not convince anyone.
5. Balancing compliance and efficiency. Research data needs to be shared for collaboration. At the same time, it is subject to personal data protection rules and data localization requirements. Access control must default to strict and open up only on demand, without making everyday access burdensome.

3. Overall Architecture

The research data platform uses a layered architecture of “five layers plus two cross-cutting concerns.” Standardized interfaces decouple the layers, so each one can evolve independently.

┌──────────────────────────────────────────────────────────┐
│ Application   Scholar profiles | Search portal |           │
│               Collaboration analytics |                    │
│               Discipline assessment | Open data APIs        │
├──────────────────────────────────────────────────────────┤
│ Service       Unified search | Graph query |               │
│               Metric computation | API gateway             │
├──────────────────────────────────────────────────────────┤
│ Compute       Language ID | Cleaning & dedup | Translation │
│               | Entity extraction | Relation extraction      │
│               | Metric computation                         │
│               (Containerized batch / stream processing,    │
│                driven by job schedulers and message queues)│
├──────────────────────────────────────────────────────────┤
│ Storage       Object storage (source documents / datasets) │
│               | Relational & columnar stores | Search index │
│               | Vector index | Graph store | Cache          │
├──────────────────────────────────────────────────────────┤
│ Ingestion     Database change capture | Batch file import  │
│               | API subscriptions | Manual backfill        │
└──────────────────────────────────────────────────────────┘
   Cross-cutting: Security & compliance (authentication,     │
   authorization, audit) | Ops observability (logs,          │
   monitoring, alerting, cost)

The design follows five principles:

• Separate compute from storage. Object storage holds source documents and large files, while compute resources are provisioned on demand and released when done.
• Decouple through messaging. The ingestion layer only writes changes to a message queue, and downstream consumers process them independently. A backlog in one stage does not affect upstream stages.
• Process data in layers. Raw data, detailed records, and aggregate metrics are built up step by step. Metric computation depends only on the detail layer.
• Unify master data. Every entity is linked through a globally unique identifier, and names and aliases exist only as attributes.
• Shift security left. Permission checks run on both the ingestion and query sides instead of relying only on the frontend.

4. Key Module Design and Implementation

4.1 Unified Entity Model: Giving “Two Names” Back Their Own Identities

The master data objects for university data typically include:

• Entities: the two teaching entities, faculties, and research centers
• People
• External organizations
• Disciplines
• Research outputs: publications, patents, and datasets
• Projects

The key to the model is separating “brand” from “legal entity”:

• brand: the shared public name, such as “Free University.”
• legal_entity: each independent teaching entity, marked as entity_f (the French-speaking entity) or entity_n (the Dutch-speaking entity).
• Every output and person record must be attached to exactly one legal_entity.

All the ways a single entity is written (full name, abbreviation, and French and Dutch spellings) go into an alias table. Each entry records the language, the contexts in which it is used, and how trustworthy the source is. At query time, the alias table automatically expands search terms. At reporting time, records are aggregated by primary key. Together, these two mechanisms prevent “same-name merging” at the source.

Metric definitions also need a time dimension that is easy to overlook. Before 1970, there was only one unified institution. When reporting historical data across that boundary, should the unified institution be treated as a separate entity, or should the figures be converted to the post-split basis? The platform should state this explicitly in its metric definitions rather than leaving users to guess.

The implementation can borrow the idea of a bitemporal model from database practice:

• valid_from / valid_to: the period during which the fact itself was true.
• recorded_at: when the fact entered the platform, used to trace data correction history.

Combined, they can reconstruct historical facts while keeping every metric traceable and auditable.

-- Entity and alias model (illustrative)
CREATE TABLE legal_entity (
    entity_id   VARCHAR(32) PRIMARY KEY,
    brand_id    VARCHAR(32) NOT NULL,              -- Shared brand
    primary_lang CHAR(2)    NOT NULL,              -- Main teaching language: fr / nl
    valid_from  DATE        NOT NULL,              -- When the fact becomes valid (bitemporal)
    valid_to    DATE,                              -- NULL means still valid today
    recorded_at TIMESTAMP   NOT NULL
);
CREATE TABLE entity_alias (
    alias_id   BIGINT PRIMARY KEY,
    entity_id  VARCHAR(32) NOT NULL REFERENCES legal_entity(entity_id),
    alias_text VARCHAR(256) NOT NULL,
    alias_lang CHAR(2),                            -- Language of the alias
    source     VARCHAR(32)  NOT NULL,              -- Source: official / literature database / manual backfill
    confidence DECIMAL(4,3) NOT NULL               -- Confidence, used to rank retrieval expansion
);

4.2 Multilingual Processing Pipeline: Making Every Language Understandable

The multilingual processing pipeline runs in four stages: language identification, text normalization, translation, and terminology alignment. Each stage stores its output together with a confidence score, so later steps can route content according to quality.

1. Language identification. For texts long enough, n-gram statistics of characters and words achieve high accuracy. Short texts such as paper titles, author names, and institution abbreviations are often ambiguous. These need weighted decisions that also take metadata such as the source system and faculty into account. Text whose language cannot be determined reliably should not be discarded. Instead, it should fall back to the multilingual retrieval path.
2. Text normalization. Each language has its own special characters and casing rules. In Dutch, for example, “IJ” counts as a single letter in some contexts. French keeps diacritics because they distinguish word meanings. The normalization process should preserve the original text and generate a separate normalized field instead of editing the source in place.
3. Translation with terminology constraints. Translation runs in two stages: dictionary constraints plus statistical quality assessment. In the first stage, the translation engine produces candidate translations. In the second, discipline names, institution names, and job titles in the controlled terminology list are forcibly replaced with approved translations. Automatic evaluation metrics and confidence scores then filter out low-quality translations. Low-confidence translations are used only to improve retrieval recall and are never shown directly to users. On user-facing pages, high-value content should be published only after human review.
4. Language routing. The query side also starts with language identification. It then chooses exact monolingual search, cross-lingual search, or multilingual semantic search.

# Illustrative code: language identification, constrained translation, and query routing
# (pseudocode; interface names exist only to express the logic)
def detect_lang(text: str, meta: dict) -> tuple[str, float]:
    """Identify language from text statistics and source metadata; returns (language, confidence)."""
    scores = {"fr": ngram_lang_score(text, "fr"), "nl": ngram_lang_score(text, "nl")}
    # Prior information such as source system and faculty acts as a weak signal
    prior = meta.get("source_lang_prior", {})
    for lang in scores:
        scores[lang] *= prior.get(lang, 1.0)
    lang = max(scores, key=scores.get)
    total = sum(scores.values())
    return lang, scores[lang] / total
def translate_with_terms(text: str, src: str, tgt: str, terms: list) -> dict:
    """Translate first, then constrain terminology with the controlled term list;
    low-confidence output is for retrieval use only."""
    hyp, conf = translation_engine.translate(text, src_lang=src, tgt_lang=tgt)
    for term in terms:                       # Term-constrained replacement for cross-lingual consistency
        hyp = apply_term_constraint(hyp, term)
    return {"text": hyp, "confidence": conf, "displayable": conf >= 0.85}
def route_query(query: str) -> dict:
    """Query language routing: decide which retrieval strategy to use"""
    lang, conf = detect_lang(query, {})
    if conf >= 0.9:
        return {"mode": "monolingual", "lang": lang}      # Exact monolingual search
    if conf >= 0.6:
        return {"mode": "cross_lingual", "src": lang}     # Translate, then search + vector recall
    return {"mode": "multilingual", "src": None}          # Multilingual semantic search fallback

4.3 Cross-Lingual Retrieval: Combining Three Strategies

There are three common approaches to cross-lingual retrieval, and each has its limits:

• Query translation, then search. The system searches the index for the user’s language. Latency is low and the behavior is easy to control, but results depend on translation quality. New words and technical terms are easily mistranslated.
• Translate all documents, then index. Translation runs offline and the retrieval logic stays simple. However, compute costs are high, and translation errors become permanently embedded in the index.
• Multilingual semantic vector search. Queries and documents are mapped into the same semantic space, which naturally supports cross-lingual matching. It is weaker at exact matching of word forms, abbreviations, and identifiers.

A more robust approach is hybrid retrieval plus reranking:

1. Keyword channel: uses language-appropriate tokenization and stemming, so proper nouns and identifiers are matched exactly.
2. Vector channel: recalls results that are semantically close but worded differently.
3. Result fusion: merges the two channels with weighted Reciprocal Rank Fusion (RRF).
4. Reranking: a reranking model produces the final order, taking publication date, source authority, and user permissions into account.

def hybrid_search(query: str, tenant: str, top_k: int = 50) -> list:
    plan = route_query(query)
    results = []
    if plan["mode"] == "monolingual":
        results.append(keyword_search(query, lang=plan["lang"], tenant=tenant, top_k=top_k))
    else:
        q_vec = embed(query)                                  # Multilingual embedding
        results.append(vector_search(q_vec, tenant=tenant, top_k=top_k))
        if plan["mode"] == "cross_lingual":
            # Translate the query and expand with synonyms to improve keyword recall
            for lang in ("fr", "nl", "en"):
                t = translate_with_terms(query, plan["src"], lang, load_terms("research"))
                if t["confidence"] >= 0.6:
                    results.append(keyword_search(t["text"], lang=lang, tenant=tenant, top_k=top_k))
    merged = reciprocal_rank_fusion(results)                  # Fuse multiple channels by reciprocal rank
    return rerank(query, merged)[:top_k]

In implementation, the search index and the vector index can be deployed separately for each document set and scaled independently. The retrieval service orchestrates the whole query flow and caches results for hot queries to reduce the latency caused by repeated computation.

4.4 Discipline Ontology and Research Knowledge Graph: Connecting Research Outputs

Answering questions such as “Which joint work exists between the two entities in a given discipline?” or “What has a research center produced in recent years?” requires more than an inverted index. It requires a research knowledge graph.

1. Ontology modeling. Entity types include people, institutions, disciplines, outputs, projects, patents, and datasets. Relationship types include employment, affiliation, publication, collaboration, citation, funding, and output. The discipline ontology should use multiple levels (“broad category → first-level discipline → research direction”). It should also be mapped to mainstream international discipline classification standards to make data exchange easier.
2. Entity extraction. Institution names, author names, discipline keywords, and project relationships are extracted from paper metadata, project applications, and annual reports. They are then normalized to global identifiers using the alias table.
3. Quality feedback loop. Extraction results carry confidence scores, and low-confidence results go into a human review queue. Review decisions flow back as training samples and rules, steadily improving extraction quality.
4. Permissions that follow the graph. Every edge in the graph inherits the sensitivity classification of its source data. Queries filter by the user’s entity and role, so users “see the graph but not the data they are not entitled to.”

def co_authorship_between(entity_a: str, entity_b: str, since: str) -> dict:
    """Measure co-authorship strength between two entities (illustrative; entity IDs and function names are custom identifiers)"""
    papers = graph.query("""
        MATCH (p:Publication)-[:AUTHORED_BY]->(a:Person)-[:AFFILIATED_WITH]->(e:Entity)
        WHERE e.id IN [$a, $b] AND p.pub_date >= $since
        RETURN p, e.id AS entity
    """, a=entity_a, b=entity_b, since=since)
    by_paper = group_by(papers, key=lambda r: r["p"].id)
    joint = {pid: {r["entity"] for r in rows} for pid, rows in by_paper.items()}
    joint_papers = [pid for pid, ents in joint.items() if ents == {entity_a, entity_b}]
    return {
        "joint_paper_count": len(joint_papers),
        "paper_ids": joint_papers,
        "note": "Authors with dual affiliation may be counted twice; deduplicate by author-institution relationships",
    }

4.5 Rankings and Performance Metrics: Making Every Number Reproducible

Universities are highly sensitive to rankings and assessment results, so metric computation must meet three requirements:

• Versioned definitions. Every change to a definition creates a new version that records the reason for the change and its effective date.
• Result snapshots. Every computation saves the input data version, the definition version, and the output, so historical numbers can be reproduced at any time.
• Traceable attribution. Any aggregate number can be drilled down to the underlying records and data sources.

-- Metric computation example: highly cited papers per entity for a given year,
-- with the definition version recorded
INSERT INTO metric_snapshot (metric_code, metric_version, period, entity_id, value, input_version, computed_at)
SELECT 'highly_cited_papers', 'v2.1', '2024', e.entity_id,
       COUNT(DISTINCT p.paper_id),
       (SELECT max(batch_id) FROM ingest_batch),          -- Input data version
       CURRENT_TIMESTAMP
FROM publication p
JOIN person_affiliation pa ON pa.person_id = p.first_author_id
JOIN legal_entity e        ON e.entity_id = pa.entity_id
WHERE p.pub_year = 2024
  AND p.citation_rank_pct <= 0.01                          -- Global top 1% by citations
  AND pa.valid_from <= DATE '2024-12-31'
  AND (pa.valid_to IS NULL OR pa.valid_to >= DATE '2024-01-01')
GROUP BY e.entity_id;

Thresholds such as “highly cited” and “top 1%” come from a specific evaluation system. The platform should therefore make them configurable parameters and show their source and definition on each metric’s detail page. This keeps one evaluation system’s results from being treated as the only standard.

4.6 Compliance for International Data: Strict by Default, Open on Demand

With about 30% international students, the platform naturally holds a large amount of cross-border personal data. Compliance design can follow common industry practice and become part of everyday development:

• Data classification. Data is divided into four levels: public, internal, sensitive, and personal data. Each level has its own storage location, encryption method, and access policy.
• Minimization and purpose limitation. Only collect fields the business needs. Each use requires separate authorization, and data collected for admissions cannot be reused for other purposes.
• Regionalized storage. Personal data should be kept in storage and compute resources within an agreed region first. A compliance assessment must be completed before any cross-border transfer.
• Permission model. A hybrid role-based and attribute-based model decides access scope. It combines the user’s entity affiliation, project role, and the data’s sensitivity level.
• End-to-end auditing. Every access is logged with who accessed which data, when, and under what conditions. Logs are retained for the period regulators require.

For personal data protection requirements in the EU, such as the GDPR, the platform also needs workflows for data subject rights requests, including access, rectification, and erasure. It should provide the corresponding APIs and a closed-loop ticketing process.

5. Cloud Deployment: Building the Platform on General-Purpose Cloud Capabilities

The architecture above does not depend on a specific technology stack. It can be built from general-purpose cloud capabilities:

• Object storage: stores paper full texts, experimental datasets, and backups. Data is tiered by access frequency, and lifecycle policies help control costs.
• Container platform: runs batch jobs and online services for language identification, translation, and extraction. It scales automatically with queue length.
• Message queue: receives change events from the ingestion layer, decoupling downstream consumers and absorbing traffic peaks.
• Logging, monitoring, and alerting services: collect runtime metrics and audit logs in one place. Alerts are configured on thresholds such as job failure rates and query latency.
• Search and vector databases, graph database: support hybrid retrieval and graph queries.

If you use comparable Baidu AI Cloud products, Baidu AIHC (the Baidu AI Heterogeneous Computing Platform) can host multilingual identification and translation workloads. Baidu’s experience in machine translation and knowledge graphs can support them. The Qianfan MaaS or private inference platform can strengthen cross-lingual retrieval and research Q&A. Actual choices should follow the capability descriptions and quotas in the official documentation. This article makes no assumptions about interface details.

There are three main ways to optimize costs:

1. Hot/cold tiering: move source documents and historical snapshots to infrequent-access or archive storage.
2. Elastic compute: run batch translation and index building during off-peak hours.
3. Query caching: cache results for frequent searches and metric queries.

6. Data Quality Evaluation: Let the Metrics Decide

A platform is not finished when it goes live. It needs a set of measurable metrics for ongoing acceptance testing and tuning.

Metric	Definition	Suggested target	Collection method
Language identification accuracy	Correctly identified items ÷ sampled items	≥ 98% for long texts, ≥ 90% for short texts	Regular spot checks against a human-labeled set
Entity alignment precision / recall	Share of records merged (or kept separate) correctly	Precision ≥ 98%	Human review of sample records
Cross-lingual retrieval recall	Share of relevant results retrieved	≥ 85%	Multilingual evaluation set
Terminology consistency in translation	Share of controlled terms translated correctly	≥ 95%	Automatic comparison against the term list
Metric recomputation consistency	Share of recomputed results that match historical snapshots	100%	Scheduled regression jobs
Query P95 latency	Latency within which 95% of queries return	≤ 500 ms	Monitoring and alerting platform

Entity alignment precision deserves priority. Merging two distinct entities by mistake is more harmful than missing a merge, because it corrupts every downstream metric. Evaluation sets should be sampled across languages, text lengths, and source systems. This avoids the illusion of strong overall numbers masking poor performance in individual languages.

7. Implementation Roadmap and Risk Mitigation

Phase	Suggested duration	Core tasks	Acceptance criteria
Phase 1: Foundations	1–2 months	Master data model, unified ingestion, language identification, monolingual search	Core entities fully covered; monolingual search works
Phase 2: Cross-lingual capability	2–3 months	Controlled term list, constrained translation, hybrid retrieval and reranking	Cross-lingual retrieval recall meets target
Phase 3: Analytics and governance	2–3 months	Knowledge graph, metric engine, permissions and audit, international compliance	Metrics reproducible; audit logs complete

Main risks and how to address them:

• Name ambiguity: run a full entity alignment cleanup before launch. Fix the aliases first, then build the indexes.
• Translation quality: set a confidence threshold for machine translations. Low-confidence content is used only for recall and never shown to users.
• Definition changes: route every metric change through a review process and keep snapshots of previous versions. This prevents historical data from “silently changing.”
• Data security: hold regular access reviews and audits for anomalous access. Revoke access promptly when staff leave or change roles.

8. Conclusion

A university divided by language still shares one name through knowledge. Likewise, a research data platform should be able to tell “who is who” and help users of different languages find the same knowledge. Achieving this requires three things:

• a clear master data model;
• an explainable cross-lingual retrieval pipeline;
• a reproducible metric computation system.

On top of these, elastic support from general-purpose cloud capabilities, the appropriate use of Baidu AI Cloud services, and security and compliance designed into every stage let universities turn seemingly difficult characteristics such as multilingualism, multiple entities, and internationalization into real competitive advantages. In that way, “Conquering darkness with knowledge” holds true in the university’s data world as well.