Learn English – Non-technical word or phrase to describe a data “query”

You should call them a pattern. Tell them I said so.

Edit

Apparently my drive-by downvoter didn’t care for “tell ’em I said so”. However, I quite assure you that it is germane, and indeed, a proper reference.

In particular, I said so in the Glossary of Programming Perl [O’Reilly Media], in its 2^nd, 3^rd, 4^th editions published respectively in 1995, 2000, and 2012:

pattern: A template used in pattern matching.

pattern matching: Taking a pattern, usually a regular expression, and trying the pattern various ways on a string to see whether there’s any way to make it fit. Often used to pick interesting tidbits out of a file.

regex: See regular expression.

regular expression: A single entity with various interpretations, like an elephant. To a computer scientist, it’s a grammar for a little language in which some strings are legal and others aren’t. To normal people, it’s a pattern you can use to find what you’re looking for when it varies from case to case. Perl’s regular expressions are far from regular in the theoretical sense, but in regular use they work quite well. Here’s a regular expression: /Oh s.*t./. This will match strings like “Oh say can you see by the dawn's early light” and “Oh sit!”. See Chapter 5.

The referenced Chapter 5 is titled “Pattern Matching”. It is not titled “Regular Expressions”. There are several reasons for that. One is that it is a mouthful. Another, as alluded to in the glossary entries above, is that in formal computational theory, a regular expression is an expression that describes a particular type of formal language: a regular one. And what “regular” means is quite specialized.

But before we can get into that, understand that even “language” here means a specific, technical thing that is not what users of regular English mean by “language”. It means “a possibly infinite set of strings”.

Moreover, a regular language is a language (that is, a set of strings) that can be parsed without requiring any auxiliary space proportionate to the size of the input set. Another way of saying it is that if the language is regular, then it is one that can be parsed using a deterministic finite automaton, or DFA for short.

In theory, there are formal requirements for determining whether a language is regular or not. You can read the link for how to do so, because lamentably enough, I cannot use TeX for the equations needed here in the ELU StackExchange site.

Examples of languages that cannot be parsed by a DFA include such things as palindromes and nested parentheses. Formally put, even something so simple as aⁿbⁿ cannot be solved (parsed) by a DFA, where that means n repetitions of some string a followed by that same n repetitions of some other string b.

However, format definitions and formal theory aside, the patterns used by modern programming languages and tools can often enough indeed match such things. Indeed, as soon as write a pattern as simple as (a+).*\1, you have violated the rules for what a DFA can solve, because you just required unbounded auxiliary storage to solve the back reference.

So theory gets in the way of practice here. The practice is that regular users (for the regular sense of regular, not the irregular one) continue to use in their daily language (here for the first time in this article at last meaning the regular thing most people mean by “language”) the term “regular expressions” long after those patterns had ceased to be such.

Plus no matter how you define it, a “regular expression” is a mouthful. It’s six syllables, and neither word means what people think it means. Both “regex” and “pattern” address the length concern, but only “pattern” alone addresses the formal concern.

It is for these reasons, amongst others, that I prefer the term “pattern”. Indeed, all told, the term “regular expression” occurs only 197 times in the 4th Edition of Programming Perl, while “pattern” occurs 541 times. Furthermore, “regex” occurs 156 times. Replacing the shorter terms with the longer one would not only have been technically inaccurate, it would have required more tree-killing and back-breaking madness, and I might have had to resort to a different binding technology, as the book is already at risk of being bigger than a breadbox.

And that is why I said, “tell them I said so”. I really did say so, and from an actual position of authority on the matter. The laconic response that my downvoter seems to have confused for cavalier flippancy was nothing more, nor one whit less, than genuine compassion for the reader. I was being compassionate in my brevity. Apparently compassion is not here universally valued—nor, by some, brevity; and so, with this brief edit, do I set both such matters aright..

Or you can just tell ’em I said so. Your choice.

One phrase that's gaining widespread adoption is black swan or black swan event. This refers to unlikely but potentially catastrophic events, especially ones where the risk is under appreciated. From Wikipedia:

The black swan theory or theory of black swan events is a metaphor that describes an event that comes as a surprise, has a major effect, and is often inappropriately rationalized after the fact with the benefit of hindsight.

… the "black swan theory" refers only to unexpected events of large magnitude and consequence and their dominant role in history. Such events, considered extreme outliers, collectively play vastly larger roles than regular occurrences
…
Black swan events were introduced by Nassim Nicholas Taleb in his 2001 book Fooled By Randomness, which concerned financial events. His 2007 book The Black Swan extended the metaphor to events outside of financial markets. Taleb regards almost all major scientific discoveries, historical events, and artistic accomplishments as "black swans"—undirected and unpredicted. He gives the rise of the Internet, the personal computer, World War I, dissolution of the Soviet Union, and the September 2001 attacks as examples of black swan events.

In the comments above, @RegDwighт suggests the acronyms MCA and DBA, which stand for the synonymous maximum credible accident and design basis accident, refer to unlikely events that are expected to occur frequently enough that engineers must design around them.

Recent events clearly illustrate the difference between a black swan and an MCA.

The tsunami far exceeded the MCA determined by the nuclear regulator, setting the stage for the black swan meltdown at Fukushima.

EDIT: Opened answer up to community wiki, since I don't want to have to accept my own answer.