First Contact with the Graph: The Exploration Cold Start in Knowledge Systems

Search boxes look innocent.

They sit there politely, waiting for the user to type something useful. In ordinary software, this feels reasonable. In a document repository, a customer support portal, or a product catalogue, the user usually arrives with at least a rough idea: a name, a keyword, a complaint, a document type, a half-remembered phrase.

Knowledge Graphs are less forgiving.

A user opening an unfamiliar Knowledge Graph for the first time may not know what entities exist, what relationships are represented, what vocabulary the ontology uses, what kinds of questions are meaningful, or whether the thing they are curious about is central, peripheral, or absent. The interface still asks them to begin. Search, filter, browse, query. Very democratic. Also slightly absurd.

That is the problem named in The Initial Exploration Problem in Knowledge Graph Exploration by Claire McNamara, Lucy Hederman, and Declan O’Sullivan.¹ The paper does not offer another query builder, visualization widget, or “now with natural language” interface. Its sharper contribution is to isolate a moment that many Knowledge Graph systems quietly mishandle: first contact, before the user has a goal, a query, or a mental model of the graph.

For business teams building enterprise Knowledge Graphs, semantic data platforms, data catalogues, compliance knowledge bases, or Retrieval-Augmented Generation systems, this matters because adoption often fails earlier than technical teams assume. The issue may not be answer quality. It may not even be retrieval quality. The user may never reach the point where those qualities can be tested.

The system is waiting for a question. The user is waiting to discover what questions are possible. Everyone waits. Excellent productivity.

The failure happens before search begins

The paper defines the Initial Exploration Problem, or IEP, as a temporally bounded, pre-goal state experienced by lay users at first contact with an unfamiliar, complex Knowledge Graph. “Temporally bounded” is doing real work here. The authors are not describing every difficulty in Knowledge Graph use. They are describing the opening condition: the moment before meaningful exploration can start.

That distinction is easy to miss because most Knowledge Graph usability discussions begin one step too late.

Search assumes the user can articulate a term. Faceted browsing assumes the user understands the semantic categories. Graph navigation assumes the user has an anchor node. Natural-language question answering assumes the user knows what to ask. Visual query builders assume the user can recognize useful classes and relationships. These are not useless tools. They are often very useful after orientation has happened.

The IEP asks what happens before that.

The authors position the problem against several familiar ideas from information behaviour and human-computer interaction: exploratory search, sensemaking, information foraging, anomalous states of knowledge, onboarding, and cognitive load theory. The key difference is temporal and epistemic. Exploratory search still assumes the user can start somewhere. Sensemaking usually assumes at least an implicit task. Information foraging assumes some “information scent.” Belkin’s Anomalous State of Knowledge assumes the user can perceive a gap in their knowledge.

IEP comes earlier. The user does not merely lack an answer. They may lack the ability to form the first useful question.

This is why the search box is such a poor metaphor for first contact with a complex graph. It gives the user freedom, but not orientation. Freedom without orientation is not empowerment. It is a blank page with better branding.

Three barriers converge at the same moment

The paper characterizes IEP through three interdependent barriers: scope uncertainty, ontology opacity, and query incapacity. The important point is not that these barriers are individually new. Knowledge Graph researchers and interface designers have long known that lay users struggle with technical query languages, dense ontologies, and complex graph structures. The paper’s contribution is to show that these problems converge at a specific moment and reinforce one another.

Scope uncertainty: the user does not know what the graph contains

Scope uncertainty is the “where do I begin?” problem. The user cannot gauge the breadth of the Knowledge Graph, the kinds of entities it includes, the relationships it represents, or the questions it can support.

This is not the same as information overload. Information overload happens when the user sees too much. Scope uncertainty happens when the user cannot even form a useful picture of what is available.

A large Knowledge Graph may contain millions or billions of triples. That scale is impressive in a funding proposal. At first contact, it can be cognitively useless. More triples do not automatically create more entry points. They may simply create a larger dark room.

In enterprise settings, this appears when a compliance officer, analyst, researcher, or operations manager is given access to a “semantic knowledge platform” and quietly returns to spreadsheets. Not because the graph has no value, but because the first step is too expensive.

Ontology opacity: the structure is meaningful, but not to the user yet

Knowledge Graphs are valuable because they impose semantic structure. Entities, properties, classes, and relationships make data interoperable and machine-readable. That same structure can be opaque to non-specialists.

An ontology may be elegant from the perspective of semantic engineering and hostile from the perspective of first contact. A domain expert might understand the business reality but not the graph’s representation of it. A historian may understand historical events but not CIDOC CRM. A clinician may understand a disease registry but not the ontology connecting cases, symptoms, interventions, and sites.

The problem is not that ontologies are bad. That would be a cheap conclusion, and cheap conclusions have a suspiciously high market share. The problem is that ontological structure is not automatically cognitive structure. A graph can be formally meaningful while remaining psychologically unreadable.

Query incapacity: hiding SPARQL does not solve the earlier problem

SPARQL is a well-known barrier for lay users. Many systems therefore try to hide SPARQL behind visual query builders, controlled natural language, or LLM-based natural-language interfaces. That helps with syntax. It does not necessarily help with orientation.

The paper’s correction is simple and important: natural-language querying solves the problem of expressing a question, not the problem of knowing what question to ask.

This is especially relevant now that LLM interfaces are being attached to almost every knowledge system with the quiet desperation of a product roadmap in Q4. An LLM can translate natural language into SPARQL. It can make query construction less painful. It can even generate candidate questions if designed to do so. But if the interface only waits for the user’s question, the same cold-start problem remains, now with a friendlier text box.

The bottleneck has moved. It has not disappeared.

Existing interface primitives solve later-stage problems

One of the paper’s strongest moves is to analyze Knowledge Graph interfaces at the level of interaction primitives rather than surface features. Instead of asking whether a system looks like search, browsing, visualization, or natural-language Q&A, the authors ask: what must the user already know for this interaction to work?

That question exposes the temporal mismatch.

These primitives are not failures. They are temporally misplaced when used as first-contact mechanisms.

A faceted browser can be excellent once the user knows which facets matter. A graph visualization can be powerful once the user can interpret the node and edge types. A natural-language interface can be useful once the user has a question. But at epistemic zero, these tools place the burden of orientation back on the user.

This is why “better UI” is too vague as a diagnosis. The issue is not merely visual polish, responsiveness, or layout. The deeper issue is that the interface starts in the wrong phase of the user journey.

The paper’s mechanism can be summarized like this:

Most systems over-serve the third stage and under-serve the first. This is common in technical products: builders design for the user they wish they had.

Scope revelation is the missing design primitive

The paper’s most useful business-facing concept is “scope revelation.” The authors argue that Knowledge Graph interfaces lack a dominant interaction primitive whose job is to reveal what the graph contains before requiring user specification.

That phrase matters: before requiring user specification.

A scope-revealing primitive should not require the user to provide a query, interpret ontology terms, or choose a technically meaningful starting point. Its job is to create a conceptual foothold. It helps the user form intent rather than merely respond to intent.

The paper gives examples such as curated natural-language questions and answers, semantic preview panels, and guided entity anchors. These are not just decorative onboarding elements. They are mechanisms for exposing the answerable space of the graph.

A conventional interface says:

Tell me what you want.

A scope-revealing interface says:

Here are the kinds of things this graph knows, the kinds of relationships it represents, and a few meaningful ways to begin.

That inversion is the practical heart of the paper.

For a digital humanities graph, this might mean showing representative people, places, events, and document trails that illustrate the graph’s historical coverage. For a healthcare registry graph, it might mean previewing the types of patient cohorts, conditions, treatments, institutions, and cross-registry links that can be explored. For an enterprise procurement graph, it might mean surfacing example questions about suppliers, contracts, risk events, regions, and dependencies before asking the user to search.

The design target is not a tutorial about buttons. It is a preview of the knowledge space.

The paper is conceptual, not empirical, and that affects how to use it

This paper does not run a user study showing that scope revelation increases adoption by a specific percentage. It does not benchmark one interface against another. It does not provide click-through statistics, completion times, or controlled experiments comparing search-first and scope-first designs.

That is not a flaw, but it is a boundary.

The contribution is conceptual and diagnostic. The paper names a recurring first-contact problem, links it to existing theory, characterizes its components, and uses the framing to critique common Knowledge Graph interface paradigms. It gives designers and researchers a sharper vocabulary for a problem that otherwise gets diluted into generic “usability.”

For business readers, the correct interpretation is not:

This paper proves that adding curated questions will increase ROI.

The more accurate interpretation is:

This paper explains why many Knowledge Graph interfaces may fail before normal usability or retrieval metrics even become meaningful, and it suggests what design capabilities should be tested next.

That difference matters. Conceptual papers are dangerous when treated as proof and useful when treated as lenses. This one is a lens.

The business value is orientation, not another query layer

Enterprise Knowledge Graph projects often justify themselves through integration, compliance, discoverability, explainability, and AI readiness. These are valid goals. But they tend to be measured from the system side: how many sources integrated, how many entities resolved, how many relationships encoded, how much reasoning supported.

IEP shifts attention to the first human contact with that structure.

If a domain expert cannot understand what the graph can do, the graph becomes an elite backend for technical specialists. That may still have value, but it is a narrower value than most enterprise AI strategies advertise. The business promise of Knowledge Graphs usually depends on cross-functional use: analysts, managers, researchers, auditors, compliance teams, and operational staff being able to explore connected knowledge without becoming ontology engineers in their spare time. Most people already have hobbies.

This creates three practical implications.

First, Knowledge Graph interfaces need a first-contact layer distinct from the expert interaction layer. The opening screen should not be a simplified version of the query system. It should be a scope-revealing environment.

Second, LLMs should be used not only as query translators but as orientation engines. A useful assistant should be able to say, “This graph can help you explore these five classes of questions,” grounded in the actual schema and data distribution. Otherwise, it is just a more charming doorman to the same locked building.

Third, evaluation should include first-step success. Can a new user identify a meaningful path within two minutes? Can they explain what the graph contains? Can they choose an entry question without external training? Can they distinguish central coverage from peripheral coverage? These are not vanity UX metrics. They are adoption prerequisites.

The quiet lesson is that interface design is temporal architecture. The same user needs different primitives at different moments. First contact is not mature exploration with fewer features. It is a different cognitive state.

RAG systems have the same cold-start problem in cheaper clothing

Although the paper focuses on Knowledge Graph exploration, the argument travels well to modern RAG systems and enterprise AI assistants.

Many RAG interfaces behave like search boxes with better prose. They wait for the user to ask a question over a document collection, policy library, ticket archive, or internal knowledge base. But users often do not know what the system has indexed, what content is reliable, what time period is covered, what terminology is used, or which questions the system can answer well.

That is scope uncertainty.

The underlying schema may not be an ontology in the formal RDF sense, but there is still a representational structure: metadata, document types, permissions, embeddings, chunking strategies, knowledge categories, entity extraction, and retrieval policies. Users do not see that structure, but it shapes what answers are possible.

That is ontology opacity’s less formal cousin.

And even if the interface accepts natural language, users still need to formulate a useful question.

That is query incapacity in a softer outfit.

This is where the paper becomes strategically useful beyond Semantic Web research. It suggests that “chat with your data” products need scope revelation just as much as Knowledge Graph browsers do. A blank chat box is not automatically human-centered. Sometimes it is just a command line wearing a cardigan.

A better enterprise AI assistant might begin by showing:

• the major knowledge areas it can answer from;
• the document sets or graph regions currently available;
• example questions grounded in actual data;
• known blind spots or missing coverage;
• representative entities, cases, processes, or relationships;
• suggested exploration paths for different roles.

This does not replace retrieval quality. It makes retrieval quality reachable.

A useful framework for redesigning first contact

The paper’s ideas can be translated into a practical design checklist. Not a generic checklist for “good UX,” but a first-contact checklist for complex knowledge systems.

The most important row is temporal mismatch. Many systems contain helpful features, but present them in an order that assumes the user has already crossed the bridge. IEP says: design the bridge.

What this paper does not settle

The paper is careful about its own limits. It presents a conceptual framing rather than a validated empirical model. That means several practical questions remain open.

We do not yet know which scope-revealing primitives work best for which domains. Curated questions may work well in a historical archive but poorly in a fast-changing operational graph unless they are continuously refreshed. Semantic preview panels may help expert analysts but overwhelm casual users if they become miniature ontology diagrams. Guided entity anchors may be useful when representative entities exist, but misleading when the graph’s value lies in long-tail relationships.

There is also a governance problem. Scope revelation must be accurate. If the interface advertises questions the graph cannot answer, it creates false confidence. If it hides important blind spots, it becomes marketing rather than orientation. In regulated domains, that distinction is not cosmetic.

Finally, “lay user” is not one category. A clinician, a historian, a compliance officer, and a procurement manager may all be non-technical with respect to RDF and SPARQL, but they bring very different domain knowledge. Effective scope revelation probably needs role-sensitive design. Not personalization theater, but actual sensitivity to what the user can already understand.

These are not reasons to ignore the paper. They are reasons to test its design implications carefully.

The first query is a product problem

The Initial Exploration Problem is valuable because it names something product teams often experience but rarely isolate. A Knowledge Graph can be technically rich, semantically elegant, and strategically important while still failing at the first human encounter.

That failure is not always loud. Users may not complain that the system lacks scope revelation. They will say it is confusing, too technical, not useful, or “maybe I’ll look at it later.” Later, in enterprise software, is a beautiful place where adoption goes to die.

The paper’s main lesson is that first contact deserves its own design primitive. Not search. Not filtering. Not graph navigation. Not natural-language querying. Scope revelation.

Before users can explore, they need to know what kind of world they have entered.

Before they can ask better questions, they need to discover what questions the system can support.

Before the Knowledge Graph can become business infrastructure, it has to survive the first thirty seconds of human confusion.

That is not a small UX detail. It is the entrance fee for usefulness.

Cognaptus: Automate the Present, Incubate the Future.