Concepts, Concepts, Concepts, ...
Although it seems that users tend to follow an either-or-concept, both are important. As Ron Ross points out, there are a variety of business rules that cannot become described in a decision model. Otherwise, SBVR and the RuleSpeak approach lacks an inherent approach to structuring. As a result, "rule book"-projects with thousands of business rules emerge in practice. In order to master such projects, we need a classification criterion, preferably a top-down criterion.
DMN addresses the structuring problem (among other problems) by describing decisions and breaking them down into sub-decisions and inputs. The result is a decision network that offers us the desired top-down structure. (See our workshop on the BCS website.)
Both have in common that we need to know the concepts used. We have to know what we are talking about. Compare the standard SBVR (semantics of the Business Vocabulary and Rules) of the Object Management Group). We define the "concepts" used. RuleSpeak / SBVR is also used to explain the rules of the (DMN) decision tables.
To understand these documents, a basic understanding of the term "concepts" and of SBVR is an advantage. Ron Ross has dedicated this question to some blog posts. For example. "What's the concept?!" In short, I define "concept" as follows: "A concept is an object through which we communicate about in natural language." What qualities does it have? Which business rules apply to the object? Which requirements must the object fulfill?
This definition makes it clear that the used objects must be classified meaningful.
In the German language "concept" is often used in the sense of "plan, procedure" and "draft". We are closer to another definition: A concept is an object of interest; we speak about it. Whether it's data, software objects, business processes and business process objects, decisions, or anything else.