\documentclass[10pt,conference]{IEEEtran}
\usepackage{amsmath,amssymb,amsfonts,amsthm}
\usepackage{algorithmic}
\usepackage{graphicx}
\usepackage{textcomp}
\usepackage{xcolor}
\usepackage{listings}
\usepackage{hyperref}
\usepackage{cite}

% Code listings configuration
\lstset{
    basicstyle=\ttfamily\small,
    language=Python,
    breaklines=true,
    frame=single,
    captionpos=b,
    numbers=left,
    numberstyle=\tiny\color{gray},
    keywordstyle=\color{blue},
    commentstyle=\color{green!50!black},
    stringstyle=\color{red},
}

\newtheorem{definition}{Definition}

\begin{document}

\title{The Three-Pillar Taxonomy:\\A Compositional Architecture for Data Manipulation Systems}

\author{\IEEEauthorblockN{Alexander Towell}
\IEEEauthorblockA{\textit{Southern Illinois University} \\
\textit{Department of Computer Science}\\
Edwardsville, IL, USA \\
lex@metafunctor.com, atowell@siue.edu}}

\maketitle

\begin{abstract}
We present the \textit{three-pillar taxonomy}, a novel organizational principle for data manipulation systems that decomposes operations into three orthogonal concerns: \textit{Depth} (addressing and extraction), \textit{Truth} (boolean logic and validation), and \textit{Shape} (transformation and modification). Unlike existing approaches that conflate these concerns within monolithic languages, our taxonomy provides clean separation that enables predictable composition while maintaining formal algebraic properties. We formalize each pillar's mathematical foundations, showing how operations lift homomorphically from documents to collections. The taxonomy, implemented in dotsuite (an open-source Python ecosystem), offers both theoretical rigor and practical benefits: composable operations following the Unix philosophy, progressive learning paths from simple to sophisticated tools, and algebraic properties enabling optimization. We argue that this separation of concerns represents a fundamental design pattern for data manipulation systems, providing a blueprint that balances mathematical elegance with usability.
\end{abstract}

\begin{IEEEkeywords}
data manipulation, software architecture, domain-specific languages, functional programming, compositionality
\end{IEEEkeywords}

\section{Introduction}

Data manipulation systems face a fundamental tension between expressive power and conceptual clarity. SQL provides relational algebra but struggles with nested structures. JSONPath offers path-based addressing but lacks compositional logic. Functional programming languages provide mathematical rigor but often at the cost of accessibility. We propose that this tension arises from the conflation of orthogonal concerns within monolithic systems.

This paper presents the \textit{three-pillar taxonomy}, a novel architectural pattern that decomposes data manipulation into three fundamental concerns: \textbf{Depth} (where is the data?), \textbf{Truth} (is this assertion valid?), and \textbf{Shape} (how should data be transformed?). This taxonomy emerged from the development of dotsuite, a Python ecosystem for manipulating nested data structures, but represents a general organizing principle applicable to any data manipulation system.

The key insight is that by cleanly separating these concerns, we achieve several desirable properties simultaneously:
\begin{itemize}
    \item \textbf{Compositionality}: Operations compose predictably through well-defined interfaces
    \item \textbf{Mathematical soundness}: Each pillar maintains algebraic properties that ensure correctness
    \item \textbf{Pedagogical clarity}: Users can master concepts progressively without cognitive overload
    \item \textbf{Implementation simplicity}: Each tool can be ``stolen'' -- simple enough to copy rather than import
\end{itemize}

\section{The Three-Pillar Architecture}

\subsection{The Depth Pillar: Addressing and Extraction}

The Depth pillar answers the fundamental question: ``Where is the data?'' It provides mechanisms for navigating and extracting values from nested structures.

\textbf{Formal Definition}: Let $\mathcal{D}$ be the space of documents, $\mathcal{P}$ be the set of paths, and $\mathcal{V}$ be the universe of values. The Depth pillar implements:

\begin{definition}[Path Algebra]
The path algebra $(\mathcal{P}, \cdot, \epsilon)$ forms a monoid where:
\begin{itemize}
    \item $\cdot : \mathcal{P} \times \mathcal{P} \rightarrow \mathcal{P}$ is path concatenation
    \item $\epsilon$ is the empty path (identity element)
    \item $(p_1 \cdot p_2) \cdot p_3 = p_1 \cdot (p_2 \cdot p_3)$ (associativity)
\end{itemize}
\end{definition}

\begin{definition}[Addressing Function]
The addressing function $addr: \mathcal{D} \times \mathcal{P} \rightarrow \mathcal{P}(\mathcal{V} \cup \{\bot\})$ maps document-path pairs to sets of values, where:
\begin{itemize}
    \item Exact paths: $addr(d, p) = \{v\}$ or $\{\bot\}$
    \item Wildcards: $addr(d, p_1 \cdot * \cdot p_2) = \bigcup_{k \in keys(d')} addr(d'[k], p_2)$
    \item Predicates: $addr(d, p[?\phi]) = \{v \in addr(d, p) \mid \phi(v) = \top\}$
\end{itemize}
\end{definition}

\textbf{Implementation Spectrum}: The pillar provides tools ranging from simple (\texttt{dotget} for exact paths) to sophisticated (\texttt{dotpath} engine with JSONPath compatibility), demonstrating that complexity can be introduced gradually without invalidating simpler tools.

\subsection{The Truth Pillar: Logic and Validation}

The Truth pillar answers: ``Is this assertion true?'' It implements a boolean algebra that operates on documents and lifts homomorphically to collections, preserving logical structure across scales.

\textbf{Mathematical Foundation}: The pillar implements a boolean algebra $(B, \land, \lor, \neg, \top, \bot)$ where predicates form an abstract syntax tree. The crucial property is the homomorphic lifting:

\begin{equation}
filter(S, p_1 \land p_2) = filter(S, p_1) \cap filter(S, p_2)
\end{equation}

This ensures that logical operations on predicates correspond directly to set operations on results, enabling both lazy evaluation and query optimization.

\textbf{Compositional Logic}: The \texttt{dotquery} tool provides a declarative DSL that compiles to the predicate algebra, supporting arbitrary boolean combinations of atomic predicates. The syntax deliberately mirrors natural language (``any equals role admin'') to reduce cognitive load.

\subsection{The Shape Pillar: Transformation and Modification}

The Shape pillar answers: ``How should the data be transformed?'' It treats transformations as endofunctors on document spaces, with composition forming a monoid structure that ensures predictable chaining.

\textbf{Mathematical Foundation}: Transformations form the category $\mathcal{T}$ where:
\begin{itemize}
    \item Objects are document spaces
    \item Morphisms are pure functions $f: D \rightarrow D'$
    \item Composition is function composition with identity
\end{itemize}

The monoid $(T, \circ, id)$ ensures that transformation pipelines can be optimized through algebraic rewriting while preserving semantics.

\textbf{Immutability Principle}: All transformations return modified copies, never mutating originals. This enables safe concurrent operations and predictable composition.

\section{From Documents to Collections}

The three-pillar taxonomy naturally lifts from single documents to collections through functorial mappings that preserve structure:

\subsection{Homomorphic Lifting}

Each pillar operation lifts to collections while preserving its essential properties:
\begin{itemize}
    \item \textbf{Depth}: $map(extract_p, S)$ extracts path $p$ from each document
    \item \textbf{Truth}: $filter(\phi, S)$ selects documents satisfying predicate $\phi$
    \item \textbf{Shape}: $map(transform_f, S)$ applies transformation $f$ to each document
\end{itemize}

The homomorphism ensures that operations can be freely reordered for optimization without changing semantics.

\subsection{Relational Algebra}

The \texttt{dotrelate} tool demonstrates how the taxonomy extends to multi-collection operations. Joins are expressed as:

\begin{equation}
\begin{split}
join(S_1, S_2, k_1, k_2) = \{merge(d_1, d_2) \mid \\
d_1 \in S_1, d_2 \in S_2, get(d_1, k_1) = get(d_2, k_2)\}
\end{split}
\end{equation}

This leverages the Depth pillar for key extraction and the Shape pillar for document merging, showing how pillars compose to enable complex operations.

\section{The Unix Philosophy Applied to Data Structures}

The three-pillar taxonomy embodies the Unix philosophy -- ``do one thing well'' -- applied to data manipulation:

\subsection{Composable Tools}

Each tool has a single, clear responsibility and composes through standard interfaces (JSON in, JSON out). This enables pipeline construction:

\begin{lstlisting}[language=bash]
cat data.json | dotstar "users.*.email" | \
  dotquery "contains gmail" | \
  dotmod "set verified true"
\end{lstlisting}

\subsection{The ``Steal This Code'' Principle}

Many tools are deliberately simple enough to copy rather than import. For example, \texttt{dotget} is essentially:

\begin{lstlisting}[language=Python]
def get(data, path, default=None):
    for segment in path.split('.'):
        data = data.get(segment, default)
        if data is default: return default
    return data
\end{lstlisting}

This philosophy acknowledges that sometimes a dependency is more costly than duplication, especially for foundational operations.

\section{Pedagogical Value: Progressive Enhancement}

The taxonomy supports a natural learning progression:

\begin{enumerate}
    \item \textbf{Novice}: Master single-pillar tools (\texttt{dotget}, \texttt{dotexists}, \texttt{dotmod})
    \item \textbf{Intermediate}: Combine pillars (\texttt{dotstar} + \texttt{dotquery})
    \item \textbf{Advanced}: Use compositional engines (\texttt{dotpath}, \texttt{dotpipe})
    \item \textbf{Expert}: Extend the system with custom predicates and reducers
\end{enumerate}

This progression ensures that users are never overwhelmed, while experts retain full power. Crucially, simple tools never become obsolete -- a \texttt{dotget} call remains the right choice for known paths.

\section{Design Rationale and Expected Benefits}

The three-pillar taxonomy is motivated by well-established software engineering principles. We discuss the expected benefits based on these foundations.

\subsection{Compositionality Benefits}

By decomposing operations into orthogonal concerns, the taxonomy enables:
\begin{itemize}
    \item \textbf{Reusable primitives}: Each atomic operation (e.g., path extraction, predicate evaluation) can be composed into arbitrarily complex pipelines
    \item \textbf{Linear complexity growth}: Adding new capabilities extends a single pillar without affecting others, avoiding the combinatorial explosion seen in monolithic systems
    \item \textbf{Testability}: Each pillar can be tested in isolation with clear contracts
\end{itemize}

\subsection{Cognitive Load Considerations}

The Unix philosophy of ``do one thing well'' has proven effective for reducing cognitive load in command-line tools. We apply this principle to data manipulation:
\begin{itemize}
    \item \textbf{Progressive disclosure}: Users learn simple tools first (\texttt{dotget}, \texttt{dotexists}) before advancing to compositional engines
    \item \textbf{Predictable interfaces}: Each tool has a single responsibility, making behavior easier to reason about
    \item \textbf{Natural mental model}: The three questions (Where? True? Transform?) map to intuitive problem-solving steps
\end{itemize}

\subsection{Performance Characteristics}

The compositional approach introduces some overhead but enables optimizations:
\begin{itemize}
    \item \textbf{Lazy evaluation}: Collection operations can stream results without materializing intermediate collections
    \item \textbf{Algebraic optimization}: The homomorphic structure allows reordering and fusion of operations
    \item \textbf{Simplicity trade-off}: For simple operations, the overhead of composition is negligible; complex pipelines benefit from the algebraic structure
\end{itemize}

\section{Related Work}

\subsection{Path-Based Query Languages}

\textbf{JSONPath} \cite{goessner2007} pioneered path-based addressing for JSON but lacks compositional logic and transformation capabilities. Our Depth pillar extends JSONPath while maintaining compatibility through the \texttt{dotpath} engine.

\textbf{XPath/XQuery} \cite{berglund2007} provides powerful XML manipulation with FLWOR expressions but tightly couples querying and transformation, making it difficult to reason about individual operations in isolation.

\textbf{jq} \cite{dolan2013} offers a complete JSON manipulation language but combines all three concerns (addressing, logic, transformation) in a single DSL. While powerful, this monolithic approach creates a steep learning curve and limits reusability of sub-operations.

\subsection{Relational and Functional Approaches}

\textbf{SQL} \cite{codd1970} provides relational algebra with clear mathematical foundations but struggles with nested structures. The conflation of selection (WHERE) and projection (SELECT) demonstrates the same concern-mixing our taxonomy addresses.

\textbf{LINQ} \cite{meijer2006} introduces composable query operators for .NET collections, sharing our compositional philosophy. However, LINQ requires a host language and doesn't cleanly separate our three concerns.

\textbf{Apache Spark DataFrames} \cite{armbrust2015} provides distributed data manipulation with lazy evaluation. While powerful for big data, the API combines transformation and selection without clear conceptual boundaries.

\subsection{Theoretical Foundations}

\textbf{Functional Programming} approaches in languages like Haskell provide strong compositionality through category theory \cite{bird1997}. Our approach achieves similar compositional properties through simpler algebraic structures, avoiding the complexity of advanced type systems.

\textbf{Datalog} \cite{ceri1989} offers declarative logic programming for data queries. Our Truth pillar shares the logical foundation but extends it with homomorphic lifting to collections.

\section{Limitations and Future Work}

While the three-pillar taxonomy provides clear benefits, we acknowledge several limitations:

\begin{itemize}
    \item \textbf{Overhead for Simple Tasks}: For trivial operations, the decomposition may introduce unnecessary complexity compared to direct manipulation.
    \item \textbf{Performance Trade-offs}: The compositional approach can prevent certain whole-program optimizations that monolithic systems achieve.
    \item \textbf{Domain Specificity}: The taxonomy is optimized for tree-structured data; graph databases and time-series data may require different organizational principles.
    \item \textbf{Learning Curve}: While individual tools are simple, understanding optimal composition patterns requires experience.
\end{itemize}

Future work includes:
\begin{itemize}
    \item Extending the taxonomy to streaming and real-time data processing
    \item Developing formal verification tools for pillar compositions
    \item Investigating automatic optimization of pillar pipelines through program synthesis
    \item Applying the taxonomy to other domains (e.g., configuration management, schema evolution)
\end{itemize}

\section{Implementation and Availability}

The three-pillar taxonomy is implemented in \textbf{dotsuite}, an open-source Python ecosystem available at:

\begin{center}
\url{https://github.com/queelius/dotsuite}
\end{center}

The implementation includes 15 tools across four pillars:
\begin{itemize}
    \item \textbf{Depth} (4 tools): \texttt{dotget}, \texttt{dotstar}, \texttt{dotselect}, \texttt{dotpath}
    \item \textbf{Truth} (5 tools): \texttt{dotexists}, \texttt{dotequals}, \texttt{dotany}, \texttt{dotall}, \texttt{dotquery}
    \item \textbf{Shape} (4 tools): \texttt{dotmod}, \texttt{dotbatch}, \texttt{dotpipe}, \texttt{dotpluck}
    \item \textbf{Collections} (2 tools): \texttt{dotfilter}, \texttt{dotrelate}
\end{itemize}

All tools are available both as Python APIs and command-line utilities, following the Unix philosophy of composable pipelines. The repository includes comprehensive documentation and a test suite covering all functionality.

\section{Conclusion}

The three-pillar taxonomy provides a principled decomposition of data manipulation concerns that balances mathematical rigor with practical usability. Our key contributions are:

\begin{enumerate}
    \item \textbf{A novel organizational principle} that cleanly separates addressing (Depth), logic (Truth), and transformation (Shape) concerns in data manipulation systems.
    \item \textbf{Formal mathematical foundations} showing how each pillar maintains algebraic properties that ensure compositional correctness.
    \item \textbf{Design principles} grounded in the Unix philosophy and functional programming that enable composability, testability, and progressive learning.
    \item \textbf{A concrete implementation} (dotsuite) demonstrating the taxonomy's practical viability as an open-source Python ecosystem with 15 composable tools.
\end{enumerate}

The three-pillar taxonomy demonstrates that complex data manipulation need not require complex tools. By respecting the natural structure of the problem domain and maintaining clean separation of concerns, we can build systems that are simultaneously powerful, predictable, and pedagogical. We believe this represents a general design pattern applicable beyond our specific implementation, offering guidance for the next generation of data manipulation systems.

\section*{Acknowledgments}

We thank the Unix philosophy pioneers for demonstrating that simplicity and composability are not at odds with power, and the functional programming community for showing that practical tools can have solid mathematical foundations.

\begin{thebibliography}{10}

\bibitem{codd1970}
E.F. Codd,
``A Relational Model of Data for Large Shared Data Banks,''
\textit{Communications of the ACM},
vol. 13, no. 6, pp. 377--387, 1970.

\bibitem{dolan2013}
S. Dolan,
``jq: Command-line JSON processor,''
[Online]. Available: https://stedolan.github.io/jq/. 2013.

\bibitem{goessner2007}
S. Goessner,
``JSONPath - XPath for JSON,''
[Online]. Available: https://goessner.net/articles/JsonPath/. 2007.

\bibitem{armbrust2015}
M. Armbrust et al.,
``Spark SQL: Relational Data Processing in Spark,''
\textit{Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data},
pp. 1383--1394, 2015.

\bibitem{berglund2007}
A. Berglund et al.,
``XML Path Language (XPath) 2.0,''
W3C Recommendation, 2007.

\bibitem{bird1997}
R. Bird and O. de Moor,
\textit{Algebra of Programming}.
Upper Saddle River, NJ: Prentice Hall, 1997.

\bibitem{ceri1989}
S. Ceri, G. Gottlob, and L. Tanca,
``What you always wanted to know about Datalog (and never dared to ask),''
\textit{IEEE Transactions on Knowledge and Data Engineering},
vol. 1, no. 1, pp. 146--166, 1989.

\bibitem{kernighan1984}
B.W. Kernighan and R. Pike,
\textit{The Unix Programming Environment}.
Englewood Cliffs, NJ: Prentice Hall, 1984.

\bibitem{mcilroy1978}
M.D. McIlroy, E.N. Pinson, and B.A. Tague,
``Unix Time-Sharing System: Foreword,''
\textit{The Bell System Technical Journal},
vol. 57, no. 6, pp. 1899--1904, 1978.

\bibitem{meijer2006}
E. Meijer, B. Beckman, and G. Bierman,
``LINQ: Reconciling Object, Relations and XML in the .NET Framework,''
\textit{Proceedings of the 2006 ACM SIGMOD International Conference on Management of Data},
pp. 706--706, 2006.

\bibitem{pierce2002}
B.C. Pierce,
\textit{Types and Programming Languages}.
Cambridge, MA: MIT Press, 2002.

\bibitem{wadler1989}
P. Wadler,
``Theorems for free!''
\textit{Proceedings of the Fourth International Conference on Functional Programming Languages and Computer Architecture},
pp. 347--359, 1989.

\end{thebibliography}

\end{document}