Ontology-Based Search Engine

TL;DR

I built the backend for an ontology-based academic search engine during a research internship at Universidad de Antioquia. The system used Neo4j to model semantic relationships between academic entities, with Python-based REST APIs providing query access. It replaced keyword-only search with graph traversal that understood conceptual connections between papers, authors, and research topics.

Problem

Academic information retrieval at the university level was limited to keyword-based search across disconnected databases. Researchers could not find papers by conceptual relationships – for example, “papers that extend the methodology used in paper X” or “authors working on similar topics to Y.” The research group needed a prototype that could demonstrate how ontology-driven search could improve discovery in an academic context.

Role and scope

I was the backend developer on a team of three researchers. My responsibilities covered the entire backend architecture: database schema design, API implementation, query optimization, and integration with the frontend (handled by another team member). The project ran for approximately one year as a research internship.

Constraints

• Research budget: No cloud infrastructure; everything ran on university lab servers.
• Data complexity: Academic ontologies involve deeply nested relationships that are expensive to query efficiently.
• Evolving requirements: The ontology model changed as the research team refined their understanding of the domain – the backend had to accommodate schema changes with minimal rewrite.
• Team size: Three people covering research, ontology design, backend, and frontend meant everyone wore multiple hats.

Architecture and decisions

I chose Neo4j for the database layer because graph databases map naturally to the problem of semantic relationships. The key decision was to model academic entities (papers, authors, topics, institutions, journals) as nodes and their relationships (authorship, citation, topical affinity) as edges with typed properties.

The backend followed a layered architecture:

• Database layer: Neo4j with Cypher query language for graph traversal
• Service layer: Python business logic orchestrating complex multi-hop queries
• API layer: REST endpoints returning structured JSON responses
• Integration layer: Data ingestion pipelines for loading academic metadata

I opted for Python over alternatives like Java or Node.js because the research team was most productive in Python and Neo4j’s Python driver offered excellent Cypher support.

Implementation

The implementation proceeded in three phases:

Phase 1 – Schema design and data loading. I designed the graph schema to represent the ontology the research team had developed. The academic metadata was cleaned and transformed into node/edge representations, then loaded into Neo4j via batch Cypher queries.

Phase 2 – Query development. The most challenging part was designing Cypher queries that could traverse the graph efficiently for common search patterns. I optimized variable-length path queries and used Neo4j’s indexing to keep response times under acceptable thresholds.

Phase 3 – REST API. I built a Python REST API layer using [Details to be added] that exposed the search functionality through clean endpoints. Each endpoint accepted query parameters and returned structured results from the graph traversal.

Reliability, security, and evaluation

The system was a research prototype, not a production deployment. Security considerations were minimal since it ran on an internal university network with restricted access. Performance testing focused on query response times for various graph depths and branching factors. [Details to be added on specific evaluation metrics.]

Result

The research team was able to demonstrate semantic search capabilities that went beyond keyword matching. The ontology-based approach showed promise for academic information retrieval, and the backend architecture provided a foundation for further research into graph-based search systems. The work contributed to the research group’s ongoing exploration of semantic technologies in academic contexts.

Trade-offs and lessons

• Neo4j vs. relational: Graph databases excel at traversing relationships, but operations that are trivial in SQL (aggregations, complex filters) become more involved in Cypher. For a hybrid system, a combination of both might be ideal.
• Python performance: Python was productive for prototyping but would not scale to production loads without significant optimization or a compiled language for hot paths.
• Schema flexibility: The graph model’s schema flexibility was a double-edged sword – it allowed rapid iteration but made it harder to enforce data consistency without application-level validation.
• Team communication: Translating academic ontology concepts into database schema required constant back-and-forth with the research team. Embedding a domain expert in the development process would have reduced rework.