Does querying always involve AI?

No. Ordinary database queries are widespread; symbolic AI adds knowledge representation or inference where appropriate.

Can a query return a fact that was never stored directly?

Yes, if supported inference derives it from stored facts and rules.

Does no match mean the statement is false?

Not automatically. It may mean the relevant evidence is absent, the query is too restrictive, or the system uses a particular completeness assumption.

AI Glossary / Graphs and symbolic AI / Intermediate

Querying

Definition

Querying is the process of asking a data source or knowledge system a precisely expressed question and obtaining results according to its rules. In symbolic AI, a query can ask whether a statement follows from a knowledge base or which values make a statement follow. The result depends on both the stored knowledge and the reasoning supported.

What it means

A knowledge base may contain facts about documents, people, and review relationships. Querying turns that representation into usable answers: which documents has Bo reviewed, or which documents meet a specified condition? Variables stand for the values being requested. An answer binds those variables to particular objects.
A query is different from adding or changing a fact. It also differs from merely finding text that contains the same words. A structured question can require several relationships to hold together. Some systems match explicitly stored records; others also derive consequences using rules. Understanding that distinction prevents an apparently empty result from being mistaken for a complete account of reality.

How it works

The system parses a query, checks its vocabulary, and determines what operations are needed. It may look up facts, join relationships through shared variables, apply filters, or invoke inference. A knowledge-base interface can return substitutions that make the requested sentence entailed by the knowledge base.
The requested output matters. A yes/no query, a list of matching objects, and a count of relationship matches answer different questions. Query languages also define their treatment of duplicates, missing values, and ordering. For example, SPARQL matches patterns in RDF data and supports result forms and modifiers. Its exact behavior should be read from its specification rather than inferred from the everyday meaning of a question.

Three practical examples

An editorial dashboard can request document identifiers that have at least one recorded reviewer, then display distinct documents.
A maintenance knowledge base can answer which components satisfy a rule combining inspection evidence and component type.
A research assistant can query a graph for publications linked to both a selected author and a selected topic, preserving the shared publication identifier.

Think of it this way

Think of asking a librarian to complete a form with separate columns for a book and its author. The form specifies what counts as an answer, while the catalog supplies evidence. The analogy is limited because a formal query has explicit variable, inference, and result rules; it cannot automatically rely on a librarian's unstated understanding of your intention.

Worked example

Consider an invented knowledge base containing Reviewed(d1, Ada), Reviewed(d1, Bo), and Reviewed(d2, Bo). These are three distinct review relationships. It also contains the rule that Reviewed(x, y) implies Ready(x). Here Ready is a deliberately narrow demonstration label meaning that a review relationship exists, not that a real publication is approved.
The query Reviewed(x, Bo) has two bindings for x: d1 and d2. The query Reviewed(d1, y) has two bindings for y: Ada and Bo. Asking for both variables returns three pairs: (d1, Ada), (d1, Bo), and (d2, Bo).
Applying the rule establishes Ready(d1) and Ready(d2). A query engine that supports this rule can return both documents even if Ready facts were not separately stored. A matching-only engine without that inference will need the derived facts materialized or an equivalent query over Reviewed.
Counting review relationships gives three, while counting distinct reviewed documents gives two. That difference is not an error: the units differ. If no fact mentions d3, the knowledge base has no demonstrated review for it. Under an open-world interpretation, this does not establish that d3 has never been reviewed. Data completeness and the chosen semantics determine what stronger conclusion is justified.

Illustrative case study

Fictional case: Fern Catalogue launches a dashboard labeled “Reviewed documents.” Its first version counts returned reviewer-document pairs, so one document with two reviewers contributes twice. The team changes the measure to count distinct document identifiers and adds a separate measure for review relationships.
It also documents that Ready is a local rule-derived status and does not mean final approval. Test records include multiple reviewers, missing records, and a document whose review was withdrawn in a newer data snapshot. This fictional example illustrates query design and interpretation; it does not report measured business results or a production deployment.

Common misconceptions and mistakes

Do not assume a natural-language request has only one structured interpretation. “Documents reviewed by every editor” differs from “documents reviewed by any editor.” Do not join records only by display names when identifiers distinguish different people or versions.
Avoid interpreting an empty answer as a universal negative without a completeness assumption. Likewise, a limited result page is not necessarily the full answer set. Query correctness cannot repair incorrect facts, stale snapshots, or a rule that expresses the wrong business requirement. A generated query should be inspected and tested against cases where plausible interpretations produce different answers.

Business use

Businesses use querying to make stored relationships operational: locating evidence, building dashboards, and checking conditions before work proceeds. Define the intended unit of an answer, the relevant time or version, and the permitted data scope before judging success.
Useful evaluation includes answer correctness, completeness for the specified dataset, explanation of derived results, and performance at realistic volumes. When an AI assistant translates a request into a query, retain the structured query and the data context so reviewers can understand how the answer was obtained.

Check your understanding

In the worked example, how many answers does Reviewed(x, y) return, and how many distinct documents do they represent?

Answer: Three reviewer-document pairs representing two distinct documents. Changing the projection or counting unit changes what the result measures.

Related terms

Knowledge base
First-order logic
Entailment
Question answering
variable binding
SPARQL
query optimization
open-world assumption

Learn next

Add Reviewed(d2, Ada), then repeat the pair count and distinct-document count. They become four and two. Next ask for documents reviewed by both Ada and Bo: both d1 and d2 qualify. Compare that conjunction with a query asking for either reviewer.

Sources

Sources: Russell and Norvig, AIMA Chapter 8 lecture slides, knowledge-base interaction and substitutions: https://aima.cs.berkeley.edu/slides-pdf/chapter08.pdf . W3C, SPARQL 1.1 Query Language, introduction, simple queries, and result conventions: https://www.w3.org/TR/sparql11-query/ .

Previous: Query understanding Next: Question answering