## 1 Introduction  
Models represent concepts by capturing the ideas, observations, notions, theories, insights, and intents that people conceive of and wish to express and communicate to others [1]. A Conceptual model uses the syntax and semantics of a modeling language to describe concepts. A popular example for concept modeling depicts [PERSON]'s observation and conception of gravity in the falling of an apple from a tree, and the ensuing formulation of [PERSON]'s Theory of Gravity. Models represent scientific concepts, as projections of theories on phenomena; they describe and abstract phenomena, while relying on theories that may be hypothetical or partially validated [2]. Likewise, models represent engineered, man-made systems in their current or future state [3]. Models also inform concepts: we can enrich our concept, perception, and subject matter understanding by capturing, manipulating, contextualizing, composing, and analyzing modeled concepts and aspects. Conceptual models play a central and growingly more critical role in complex systems engineering, development and operation. Models are supposed to capture and represent various relations and interactions, which are fundamental for comprehending solutions, designs, or operational processes. Models are also important for facilitating stakeholder communication and discussion. The concept-model duo is therefore a binary self-enhancing system. Model-Based systems engineering (MBSE) is the formalized application of models in systems engineering [4]. MBSE facilitates the digital transformation of systems engineering: generating and communicating digitally-encoded and interchangeable systems engineering deliverables up and down the value chain [5]. Digital systems engineering (DSE) increases the dependency on MBSE, which gradually evolves from a model-focused practice to a value-focused approach and to a critical asset for systems engineering in digital enterprises [6; 7; 8; 9]. Generating stakeholder value out of model-based platforms is a primary expected outcome of DSE. Transforming system models into analyzable and reusable artifacts, decision-supporting information, and machine-generated insight is therefore a critical contribution to enterprise-wide DSE. A DSE ecosystem architecture defined in [10] specifies modeling, infrastructure, data services, simulation, testing, analysis, and repositories (MIDSTAR\({}_{1}\)) as primary DSE services. Management tools, interoperability services, digital representations, systems, things, auditing, and reporting services (MIDSTAR\({}_{2}\)) are regarded as primary interfaces. We shall refer collectively to such results or artifacts following model processing or analysis as _views_ of those models. Model-based views abstract, highlight, or pivot specific aspects, and become increasingly more important as models grow bigger and more complicated. Observing, reasoning about, processing, analyzing, and deciding according to such views results in ongoing concept revisions [11]. The self-enhancing concept-model-view triangular cycle extends the concept-model duo. However, the potential combination of modeling languages (MLs), models, and views explodes: if every model were to be represented by every necessary view, the number of mappings would be a product of the number of models \(M\) by the number of views \(V\), i.e., \(M\cdot V\). In the absence of dynamic and robust model-to-view transforms, concept understanding is shaped by ML-bound views. A generic representation (GR) across a wide variety of models that MLs could map into, and views could map out of, can make a difference. Graph data structures (GDS) can serve as GRs [12; 13; 14; 15]. A GDS is simple, robust, scalable, and amenable to both relational and graph-theoretic algorithms. Graph and GDS are not completely interchangeable concepts: A graph is a visual representation of a subset of the GDS, and a GDS is a logical data structure that represents relations, which can be illustrated in graphs.