Conceptual modeling Sep-Oct 2019 summary

September and October 2019 were occupied with my project to develop an approach to conceptual modeling. This post is a rough summary of the state of my research from this sprint.

Purpose

Part of my evolving approach to modeling is to match the situation being studied to one or more conceptual frameworks. My initial goal for this sprint was to determine the framework implied in Munzner’s account of data visualization. But my mind insisted on exploration mode, so I ended up looking into other topics as well, some more directly related to visualization and others less.

Findings

Project scope

To make sure I had my overall project properly delineated, I had two questions:
- What topics counted as modeling? For example, should I include creative thinking and problem solving, since those are involved in the modeling process?
- What academic and professional fields should I use as sources? I want to draw insights from a wide range, but I don’t want to spend time on fields that don’t focus on disciplined modeling.
On the topics question, I concluded the ones I questioned had some overlap with modeling, but I shouldn’t make a complete study of them as part of this project, because substantial amounts of the subject matter wouldn’t be relevant.
On the source fields question, I decided to focus on the fields in this sprint and later expand in two directions.
- For creating frameworks, the natural fields would be math, computer science, and systems theory.
- For learning process, the fields are probably business, social science research, problem solving, intelligence analysis, visual intelligence, intuition research, and the scientific method.
- I also made a big list of all the fields that felt relevant to give me a somewhat organized future reference for this question.

Data visualization

Munzner, Tamara. Visualization Analysis and Design. A.K. Peters Visualization Series. Boca Raton: CRC Press, Taylor & Francis Group, 2015.

I’ve read about 30% of the material from various parts of the book, but I think it’s enough to get the gist. Most of the book seems to be about working out the details of the “how” question (see below).
Munzner’s goal is to define a set of criteria for designing and evaluating visualizations.
She divides her approach into three areas: what kind of data is being visualized, why it needs to be visualized, and how it should be visualized.
What
- My take is that all the dataset types are based on tables (or maybe networks or dictionaries): discrete items and attributes, though some datasets ultimately represent continuous data.
- There are kinds of information this framework would be a stretch for, such as narratives.
- The data types understandably focus on spatial data.
Why
- What to look for in the data partly depends on the tasks.
- What to look for is described by math, mainly statistical methods, graph theory, and geometry.
How
- The book is good for expanding my visual repertoire in an ordered way. For example:
  - Visualizations can contain composite glyph objects. Thus, diagrams don’t have to be simple.
  - Visualizations are made up of marks (visual objects with various numbers of spatial dimensions) and channels (the marks’ visual attributes, which have traits that make them suitable for encoding particular kinds of data attributes).
- Certain visuals do have semantic meaning (the expressiveness principle), such as lines on a graph indicating trends (so you wouldn’t want to connect unrelated points with a line).
- “Eyes beat memory” is a key insight even beyond her application of it to animation. I think a major reason visualizations are so helpful for thinking is that they unburden the viewer’s memory by keeping certain information in view.

Model-driven software engineering

Brambilla, Marco, Jordi Cabot, and Manuel Wimmer. Model-Driven Software Engineering in Practice. Second edition. Synthesis Lectures on Software Engineering 4. San Rafael, Calif.: Morgan & Claypool Publishers, 2017.

Martin Fowler identifies three modes of use for the software modeling language UML: sketch, blueprint, and programming language.
- Sketch uses UML as an informal thinking tool and lets the code diverge from the diagrams over time.
- Blueprint uses the diagrams as a set of requirements for the code.
- Programming language treats the diagrams themselves as executable code.
- Brambilla et al focus on the blueprint and programming language modes. That is, MDSE models are oriented toward executable software, even if they’re not directly executable. In contrast, the sketch mode belongs to a category that Brambilla et al call model-based engineering (as opposed to model-driven), and it’s outside the scope of their book.
Major players that Brambilla et al cover:
- The Object Management Group (OMG) with the Unified Modeling Language (UML) and related languages (together known as Model-Driven Architecture, or MDA).
- The Eclipse Foundation with the Eclipse Modeling Framework.
MDSE models are very formal and abstract and often very detailed.
MDSE’s technology gets organized into layers of abstraction: models that describe systems and metamodels that describe modeling languages. OMG’s MDA framework is comprised of four of these layers.
Modeling languages have syntaxes. The concrete syntax represents a model. The abstract syntax represents the metamodel.
Syntaxes can be graphical or textual.
Models are manipulated via transformations, which produce other models or code.
OMG has a specification for representing RDF technologies.

Graphic facilitation

Agerbeck, Brandy. The Idea Shapers: The Power of Putting Your Thinking into Your Own Hands. [s.l.] Loosetooth.com Library, 2016.

Margulies, Nancy, and Christine Valenza. Visual Thinking: Tools for Mapping Your Ideas. Norwalk, CT: Crown House Pub. Co, 2005.

Sibbet, David. Visual Meetings: How Graphics, Sticky Notes & Idea Mapping Can Transform Group Productivity. Hoboken, N.J.: John Wiley & Sons, 2010.

I’ve read all of Sibbet, about 40% of Agerbeck, and 30% of Margulies and Valenza.
Agerbeck identifies four uses for drawing:
- Representing. Traditional art fits here.
- Thinking. This fits the uses of sketchnoting that The Idea Shapers covers. Generally speaking, the sketch mode of software modeling also fits here.
- Communicating. Slide presentations fit here. Parts of software modeling also fit here: blueprint mode (communicating to programmers) and programming language mode (communicating to the computer).
- Facilitating. Graphic facilitation fits here.
Graphic facilitation contributes insights on the process of modeling.
Graphic recordings mostly function as reminders, whether during a session or after it.
Visualization aids thinking.
A visual process can greatly engage a team.
Drawing by hand has its own meaning, so it shouldn’t necessarily be replaced by computer graphics.
Graphic facilitators pay attention to visual structure in addition to depicting concepts, making use of templates for the large- and small-scale structure of their drawings.
Certain structures enable a flexible, exploratory process more than others.
Abstract diagrams are like the skeleton of the model, and pictorial ones are like the flesh. For example, the border of any depicted object (a cloud, a building, an animal) can function as a containing line, and in addition to grouping and isolating content, the object will evoke meanings related to its subject matter.
Drawings can range from literal to metaphorical.
Building a visual vocabulary (like mental clip art) lets you draw fast.

Semantics

Saeed, John I. Semantics. Fourth edition. Introducing Linguistics 2. Chichester, West Sussex [England] ; Malden, MA: Wiley Blackwell, 2016.

My goal was to learn how semantics researchers analyze words and sentences to get an idea of the fundamental concepts they recognize. These concepts could be used to build frameworks.
Some of these approaches compete to be full explanations of meaning, but I think they all offer tools for understanding aspects of meaning.
A survey of the book’s pointers to semantic primitives:
- Word meaning:
  - Lexical relations, including lexical field, homonymy, polysemy, synonymy, antonymy, hyponymy, meronymy, member-collection, and portion-mass.
  - Core vocabulary and universal semantic primes.
- Sentence relations and truth: Logic brings a lot of concepts with it that would inform a fundamental conceptual framework, such as entailment, contradiction, presupposition, and tautology.
- Sentence situations: Situation type (static, dynamic), tense, aspect (completed, ongoing), modality (level of certainty, level of permission), mood (e.g., indicative, subjunctive), and evidentiality (attitude toward information source).
- Sentence participants:
  - Thematic roles: agent, patient, theme, experiencer, beneficiary, instrument, location, goal, source, stimulus.
  - Voice: active, passive, middle. As with the other categories, these voices bring other concepts along, such as the concepts of scene, figure, and ground and animacy hierarchies.
  - Classifiers and noun classes: These morphological constructs encode categories like shape, possession, and gender.
- Meaning components: Semantic components, with accounts by several researchers:
  - Katz on semantic markers and distinguishers.
  - Talmy on motion verbs.
  - Jackendoff on conceptual semantics.
  - Pustejovsky’s extended conceptual semantics.
- Speech as action: Types of speech acts.
- Cognitive semantics: Image schemas (e.g., container, path, force), metonymy relations.
Concepts related to models and modeling:
- Context and inference: Deixis, discourse, background knowledge, mutual knowledge, information structure, conversational implicature, lexical pragmatics.
- Formal semantics: More concepts from logic, specifically predicate logic, which formal semantics translates English into. This type of analysis is explicit about modeling. Montague’s approach is actually called model-theoretical semantics. Similar approaches are situation semantics and discourse representation theory. Formal semantics covers both sentence and word meaning.
- Cognitive semantics: Radial categories, Conceptual Metaphor Theory, mental spaces, Cognitive Grammar, Construction Grammar.

Field interactions

Software models tend to be more detailed and consistent than models in business and other social and creative fields, so software and other STEM modeling can contribute rigor.
Fields outside of STEM can contribute insights into the process of modeling. Software modeling discussions tend to skip straight to the model’s features and representation.
The needs of software models overlap with the needs of other fields, but software models also have features that aren’t well suited to others or aren’t relevant to them, so the modeling languages would need to be adapted. I’m looking for a database like OWL more than a behavioral system like the MOF seems to be. The behavioral aspects I’ve seen of MOF would come into play if I were making a modeling IDE.

Issues

Separating the MDSE abstraction layers is a challenge.
What features does a modeling language need, as opposed to other formal languages, such as specifications meant for validation, grammars for parsing, or mathematical notation?
It’s hard to know what layout I’ll need when I start a sketchnote.

Future directions

Create a simple tool that ties together various existing modeling tools so I can learn by experiment.
- Attempto
- Protege
- EMF
- NLTK
- Logic programming
Express informal diagrams in formal terms.
Practice sketchnoting.
Catalog basic attributes.
Express existing questions from my method in formal terms.
Compare my questions to those from graphic facilitation.
Create instructional documents on these formal languages.
Expand to educational comics and technical illustration.
Expand to knowledge representation.
Create visual representations for sentence semantics.
Map out the semantic approaches in detail.
Try various textual notations for modeling, such as Human-Usable Textual Notation, KM3, and Emfatic.
Finish cataloging data visualization information.
Experiment with creating a new basic textual notation and modeling tool, if it seems helpful.
Begin relearning math.
Learn relevant areas of basic computer science.