Content uploaded by Albert Jones

Author content

All content in this area was uploaded by Albert Jones on Jan 04, 2018

Content may be subject to copyright.

15

th

Annual Conference on Systems Engineering Research

Disciplinary Convergence: Implications for

Systems Engineering Research

1

Eds.: Azad M. Madni, Barry Boehm

Daniel A. Erwin, Roger Ghanem; University of Southern California

Marilee J. Wheaton, The Aerospace Corporation

Redondo Beach, CA, March 23-25, 2017

Categorical foundations for system engineering

Spencer Breiner

a

, Eswaran Subrahmanian

a,b

, Albert Jones

b

a

National Institute of Standards and Technology, spencer.breiner@nist.gov

b

Carnegie Mellon University, sub@cmu.edu

Abstract

In this paper we argue that category theory (CT), the mathematical theory of abstract processes, could

provide a concrete formal foundation for the study and practice of systems engineering. To provide some

evidence for this claim, we trace the classic V-model of systems engineering, stopping along the way to (a)

introduce elements of CT and (b) show how these might apply in a variety of systems engineering contexts.

Keywords: Category theory, Foundations of system engineering, Mathematical modeling

Introduction

Systems are becoming more complex, both larger and more interconnected. As computation and

communication in system components goes from novelty to the norm, this only becomes more true. In

particular, we have no generally accepted method for designing, testing and analyzing systems which mix

both physical and computational dynamics. We believe that a new formal foundation is required to model

and study such complex systems.

Existing approaches, typified by the V-model of systems engineering, are more heuristic than formal.

First we conceptualize the system, setting our various requirements and assumptions. Next we refine this

into a functional decomposition which details how our system will meet its goals. In realization, we map

these functions to components of our systems. Finally, we integrate these components into a true system,

testing along the way, before releasing the system for operation.

This says what we need to do, but not how to do it. A formal foundation would supplement this

framework with concrete tools and formal methods for accomplishing each step. Our goal in this paper is

to propose a candidate approach for such a foundation, based on a branch of mathematics called

category theory (CT).

We should mention some prior work associating CT and systems engineering. For example, CT is

listed as a foundational approach in the Systems Engineering Body of Knowledge (SEBOK, [1]), although

there is little detail associated with the entry. More substantively, Arbib & Manes [2] studied applications

of CT in systems control in the 1970's. This work was largely stymied by the unfamiliarity of categorical

ideas and the lack of good tools for implementing them (on which we will have more to say in the

conclusion).

CT is the mathematical theory of abstract processes, and as such it encompasses both physics and

computation. This alone makes it a good candidate for foundational work on modern systems. As we

proceed, we will also argue for other virtues including expressivity, precision, universality and modularity

among others.

To make our argument, we will trace through the classic V-model of systems engineering,

2

demonstrating along the way how CT might apply at each step in the process. We have chosen the V-

model not for validity (it oversimplifies) but merely for familiarity.

In tracing the V, we hope to accomplish two things. First, we aim to demonstrate the range of

categorical methods in order to demonstrate that CT might provide a holistic foundation for systems

engineering. Second, and more important, we hope to introduce systems engineers to the language and

methods of CT, and pique the interest of the systems engineering community to investigate further. Our

hope is that one day soon this paper might serve as the preface to a much deeper study that systems

engineers and category theorists might write together.

1. Conceptualization

The first role for CT in systems engineering is as a precise technical language in which to express and

analyze models of systems information, ranging from theoretical predictions to raw data. The key feature

of CT in this respect is its abstraction. We can form categorical models from graphs, from logical

ontologies, from dynamical systems and more, and we can use categorical language to analyze the

relationships and interactions between these. To get a sense of what this looks like, we will model some

simple system architectures and the relationships between them.

The categorical model for an abstract network is remarkably simple:

(1)

The first thing to observe is that a category contains two types of entities, called objects and arrows.

Intuitively, we think of these as sets and functions, though they are abstract in the model itself. An

instance of the model replaces abstract objects and arrows with concrete sets and functions. It is not hard

to see that any network can be encoded as an instance of N, as in figure 1.

The key difference between categories and directed graphs are the construction principles which allow

us to combine the elements of our models. Foremost among these construction principles is arrow

composition; whenever we are given sequential arrows

→

→ , we can build a new arrow . : → .

Another way to think of this is, when we draw categories as directed graphs, the arrows include paths of

edges as well as individual arcs. We also allow paths of length 0, called identities.

To see why this is useful, consider the following simple model for a hierarchy of depth :

(2)

Here the primary structure is the self-arrow parent:Node→Node, which sends each node to the level

above it in the hierarchy. By composing parent with itself we can trace our way up the hierarchy from

any node.

By itself, this is too flexible. There is nothing to ensure that all nodes are part of the same hierarchy

and, even worse, our ``hierarchy'' might contain loops! We can eliminate these worries by demanding that

the parent map is ``eventually constant'': after repetitions, every node ends up at the same place. This

Fig. 1: Network as an

N

-instance

3

involves two ingredients: a construction and a path equation.

Categorical constructions generalize most set theoretic operations such as unions, intersections and

Cartesian products. The terminal object 1 stands in for a singleton set, and allows us to express the

notion of a constant value root∈Node. The path equation paren

const.root forces the th parent

of any node to equal root, ensuring a single hierarchy with no loops.

A more interesting example is the layered architecture L (figure 2), in which channels must conform to

a hierarchy of layers. Here the path equations constrain where channels may occur, while the + and /

constructions express the fact that channels may form either between layers (Γ) or within a layer (∆).

All of these models are fairly trivial. The main point is that the sorts of class modeling which systems

engineers already do is not too far away from a precise formal language. By carefully modeling our

concepts at the early stages of systems engineering we can express requirements more precisely,

identify misconceptions and inconsistencies, and establish concrete domain-specific languages. Best of

all, we get both intuitive graphical presentations like those found in UML/SysML class diagrams without

sacrificing the semantic precision associated with OWL and other formal approaches to ontology.

CT also goes beyond these existing languages. A functor is a mapping between categories; it sends

object to objects and arrows to (paths of) arrows, without changing the effects of composition. These

maps, along with other constructions like colimits and natural transformations, allows us to explicitly

identify and represent the relationships between individual categorical models, thereby linking them into

larger networks. This allows semantic ontologies to emerge organically from the bottom-up, grounded in

practice, in contrast to ``upper ontology'' approach (e.g., the Basic Formal Ontology [3]), which tries to

impose semantic structure from the top down.

A simple example is the idea that a hierarchy is a special type of network. This fact can be formalized

as a functor :N→H. To define we ask, for each component of N, what plays an analogous role in H?

The translation for Node is clear. In the hierarchy we have one channel for each node, so Channel also

maps to the same object Node. Since each channel maps from a node to its parent, target corresponds

with parent and source with the identity (zero-length path). Putting it all together, we have the functor

depicted in figure 3(a). Similarly, we can identify one hierarchy (of layers L) and two networks (of

channels C and layers L') in the layer architecture, corresponding to the four functors in figure 3(b). We

Fig. 2: Categorical model for layered architectures

Fig. 3: Functors translate between categorical models

4

even have a path equations--. ′--which acknowledges that the network of layers in L is just the

same as the network in H which is constructed from the hierarchy in L.

The stylized models and relationships presented here are fairly trivial, but the general method of

categorical modeling is quite powerful. By varying the constructions we allow ourselves to use, CT

modeling can range in expressiveness from simple equations to full higher-order logic [12]. For more

thorough introductions to categorical modeling, see [23] or [10]. The main thing to remember is that

categorical methods provide tools for expressing and relating our formal models.

2. Decomposition

In the last section we met all the essential elements of category theory--objects and arrows,

composition, identities--except one: the associativity axiom. Given a sequence of three composable

arrows

→

→

→ , we could first compose at and then at , or vice versa. Both should yield the

same result: . . . . . When applied to processes, this axiom is so obvious it is difficult to

express in English:

Doing and then , and then doing

is the same as

doing , and then doing and then .

Because of this, there is no need to keep track of parentheses when we compose arrows.

This allows us to describe complex processes based on only two pieces of information: (i) the

descriptions of simpler subprocesses and (ii) the way they were chained together. Of course, systems

engineers know that complex emergent phenomena may arise from simple subprocesses. This does not

mean that compositional, categorical mathematics does not apply. Instead, it means that the

compositional representations of such systems may require greater complexity than the naïve models we

might produce from scratch. By demanding compositionality from the outset, we are forced to build

interaction into our models from the ground up!

One important step in this direction is to generalize the sorts of composition that we allow. In fact,

there are many different flavors of category theory, each of which supports a different notion of

composition. The plain categories that we met in the last section allow only unary (single-input) processes

and serial composition. Some varieties like groups, which formalize the mathematics of symmetry, restrict

ordinary categories to obtain simpler structures. Others like process categories and operads add in

additional construction principles like parallel composition and multiple input/output. Through these

constructions, categories axiomatize the most fundamental concepts in systems engineering: resources

and processes [7].

Fig. 4: Process decomposition as a string diagram

5

All of these share a common theme of composition and associativity. For groups, this allows us to

describe the way that arbitrary rigid motions can be decomposed into translations and rotations. More

generally, this allows us to express complicated structures in terms of smaller and simpler pieces. It can

also help to show when a chain of complicated operations has a simple and predictable outcome.

Process categories, which are embody the mathematical structure of multi-resource functional

decomposition [7,4]. In the mathematical literature these are often refered to as “traced symmetric

monoidal categories”, but we feel that this nomenclature is too imposing given their simplicity and

importance. One particularly nice feature of these structures is that process categories support a

graphical syntax called string diagrams like the one in figure 4. Completely formal and technically precise,

these diagrams are nevertheless as intuitive and easy-to-read as flow charts.

Where string diagrams represent process flows, another class of structures called operads formalizes

the notion of a parts decomposition [21]. In an operad, the objects are interfaces and the arrows are

“wiring diagrams” which connect a set of small interfaces into one larger component. Here associativity

says that there is only one meaning for the phrase “a system of systems of systems.”

These representations make it easier to talk about relationships across scale. Some or all of the

subprocesses in the figure 4 will have their own process decompositions. The only substantive constraint

on these decompositions is that they have the appropriate input and output strings. This leaves us with

one high-level categorical model P for the entire process and several low-level models Q

for the

individual subprocesses.

To express the relationship between these, we first combine the low-level pieces into a single

aggregate model Q ⨁ Q

. This involves an operation called a colimit which generalizes set-theoretic

unions; building them requires explicitly representing the overlap between different models. Once we

build the aggregate model, we can then define a functor P→Q which essentially pastes copies of the

smaller diagrams Q

into the appropriate bubbles from P. This identifies an explicit model for the total

high-level process P inside the aggregate low-level model Q. Furthermore, we can also allow multiple

decompositions for a given subprocess, providing a framework for modularity and versioning.

3. Realization

During realization we turn our abstract models into concrete realizations. In spirit, the relationship

between these two is analogous to the that between the logician's notions of syntax and semantics.

Roughly speaking, syntax is what we say and semantics is what we mean, or what we are talking about.

Models are like syntax: they describe how a product or system is supposed to work in terms of both

structure (decomposition and component interaction) and behavior (requirement and verification

specifications). Attaching semantics to these models means assigning each syntactic component to some

sort of concrete entity, in a way that mirrors the structure and behavior of the model.

Ultimately these concrete entities will be physical components and functioning source code, but before

we reach that point we must pass through many other, more abstract semantics. These might range from

the formal verification of a critical algorithm to a stochastic model of user behavior, but most have some

flavor of simulation. The motivating example to keep in mind is the simulation of a system in terms of

(discrete, continuous or hybrid) dynamical systems [15].

The key feature of the logician's semantics is compositionality: if we want to determine the truth of a

complex logical formula, it is enough to look at the truth values of its subformulas. This might seem to fail

for a given dynamical system: just because each component of my system is safe in isolation hardly

guarantees safety of the composite system. Doesn't the existence of emergent phenomena mean that the

behavior of a complex system is not determined by the behavior of its components? This

misunderstanding rests on a conflation of two distinct notions of “behavior”.

We can think of system behavior as a path through some high-dimensional state space; component

behavior is the projection of this path onto the subspace of component parameters. The problem is that

component dynamics in isolation trace out different paths than the projected system dynamics would.

This is why component safety in isolation does not entail system safety, even for the same component

metrics. This also means that there is no hope of composing individual component behaviors to derive

system behavior.

6

However dynamical models, the differential equations which generate these paths, are composable:

we can derive the dynamical equations of a system from the dynamics of its components [24]. The

formula for this derivation will, of course, depend on how the components are connected to one another.

Each diagram like the one in Figure 4 generates its own formula. CT structures this relationship, making

the requirements of compositionality explicit through the language of categories and functors.

Logical semantics involves three main elements: (i) a syntactic model to be interpreted, (ii) an

assignment of syntactic elements to semantic objects, and (iii) a satisfaction relation which determines

whether this assignment meets the requirements of the model. However, traditional logic operates in a

fixed context of sets and functions (deterministic semantics), while CT broadens this to allow stochastic

semantics, dynamical semantics and more. Thus categorical semantics adds one further element, (iv) a

universe of semantic entities.

This approach relies on an important though informal distinction in CT between smaller, ``syntactic''

categories and larger, ``semantic'' categories. Syntactic categories are like the architectural models

described from section 1, built directly from graphs (generators), path equations (relations) and

categorical structure (constructions).

Semantic categories instead use some other formalism, like set theory or matrix algebra, to define the

objects and arrows of a category directly. The prototypical example is the category of sets and functions,

denoted Sets, where composition (and hence path equations) is computed explicitly in terms of the rule

. . Many other semantic categories like Graph (graphs and homomorphisms) and Vect

(vector spaces and linear maps) can be constructed from set theoretic entities.

Once we adopt this viewpoint, the relationship between syntax and semantics can be represented as a

functor from one type of category to the other. We have already seen one example of this approach, in

figure 1, where we described a network instance in terms of a pair of functions. This is exactly the same

as a functor N !: we map objects of N to objects of Sets and arrows of N to arrows of Sets (i.e., to

sets and functions).

The satisfaction relation for the semantic interpretation is determined by the preservation of categorical

structure. A good example is the coproduct “+”, used in our model for the layered architecture L (figure 3).

Not all functors L ! are semantically valid, only those which map the abstract coproduct " # $ L to

a concrete coproduct (disjoint union) in Sets. We say that a model of L should preserve coproducts.

Implicit in any categorical model is a minimal set of construction principles required to preserve full

semantics.

Once we recognize that the traditional (logical) interpretations for a model M are the structure-

preserving functors M !, we are in an easy position to generalize to a much wider array of

semantics. We have explicitly identified the necessary structural context (e.g., coproducts) M, so we can

replace Sets by any other category which has these same features. We can use a category Dyn whose

objects are dynamical systems; a functor M %&'provides dynamical semantics. There is a category

Prob whose arrows are probabilistic mappings; a functor M ()*+ describes stochastic semantics for

M. There is a computational category Type where arrows are algorithms; functors M ,&- provide

computational interpretations for M. We can often compose these, for example mapping a model to a

dynamical system, and then mapping this to a computational simulation. Sometimes we can even mix

semantics together, so that in figure 4 we could give dynamical models for Heat and Simmer, a

computational model of Control and a stochastic Measure, and compose these to give a hybrid

dynamical model for the whole system.

4. Integration

The main role of our models in system integration is to collect and manage the tremendous amount of

structured data collected and analyzed during the integration process. This data is necessarily

heterogeneous, multi-scale and dispersed across many models and experts. Categorical models have

several nice features which can support the federation of this data.

First of all, we can regard a finite syntactic category M (like one of the architectural models in section

7

1) as a database schema [14,19,20]. Roughly speaking, the objects are tables and the arrows are foreign

keys. This means that we can use the models already produced during conceptualization and

decomposition to store the data generated during integration. Formally this depends on the functorial

semantics discussed in the previous section; we can think of an instance of the database as a functor

M ! mapping each table to a set of rows. Notice that this approach automatically ties the data that

we produce to our semantic models.

A more significant challenge is the dispersion of data across many engineers using many different

models. In order to build a holistic picture of our system, we need some way of putting models together

and aggregating the data they contain. The CT approach involves a categorical construction called a

colimit, together with an additional twist.

A colimit is a categorical construction that generalizes unions, allowing us to build new objects by

gluing together old ones. For example, any graph can be constructed using colimits by gluing edges

together at nodes. To integrate two objects using a colimit, we first explicitly identify their overlap as a

third object, along with two maps embedding the overlap into each component. Given this data, the

colimit construction then produces a fourth object together with two maps which embed the original

components into the new object. See figure 5(a).

The twist is that, instead of looking at categorical constructions inside our models, now we are

interested in performing colimits with our models. This approach depends on the fact that CT is self-

referential: the methods of CT can be applied to study categories themselves. In particular, there is a

semantic category Cat whose objects are categories and whose arrows are functors. Colimits in this and

related semantic contexts can be used to define model integration. A very simple example is given in

figure 5(b).

In fact, we can form colimits from any number of components, so long as we accurately represent their

overlaps (and overlaps of overlaps, etc.), providing a scheme for wider integrations. However,

representing all those overlaps may be inefficient. Another alternative is to integrate serially, adding in

one new model at a time. CT provides us with a language to state and prove that either approach is valid,

and that the two options will yield equivalent results [25].

As for heterogeneity, CT constructions called sheaves have recently been proposed as ``the canonical

datastructure for sensor integration'' [18]. The main idea is that when different of sensors capture

overlapping information, it must be restricted or transformed before it can be compared. In the simplest

example, to identify overlapping images we must first crop to their common ground (restriction) before

comparing the results. A simplistic algorithm would ask for perfect agreement on the restriction, but a

more sophisticated integration might allow small differences in shading or perspective (transformation).

We can also compare different types of information, so long as we can project them to a common context;

we might match up audio and video by translating both to time series and looking for common patterns.

CT provides the language and spells out the requirements for translating between contexts in this way.

Finally, by mixing colimits with functors, we can connect our models across layers of abstraction [6].

Suppose that H is a model one level of abstraction above that of M and N in figure 5. Both M and N are

Fig. 5: The colimit construction

8

more detailed than H, but each only covers half the range. When we put them together, though, they do

cover the same range: every entity of H can be defined by mixing structures from M and from N.

Formally, this means that we can construct a refinement functor H ./012M3N4O which tells us how to

compute high-level characteristics in terms of low-level ones, helping to trace high-level requirements to

low-level performance.

5. Operation

In operation, systems are never static. Components fail and need to be replaced. New models and

versions require tweaks to existing production and control system. New technology or regulation changes

the environment in which our systems operate. Because of this, it is critical that our models should be

relatively easy to maintain and update. Here again, categorical methods have some nice features which

recommend them.

One significant challenge in updating a model is that we must take existing data attached to the

original model and shift it over to the new one. Thinking of our models as domain-specific languages, we

must translate our data from one language to another. These processes are often messy and ad hoc, but

categorical constructions can help to structure them.

As we mentioned in the last section, a class-type categorical model N like those discussed in section 1

can be translated more-or-less directly into database schemas [14,19,20] where objects are tables and

arrows are foreign keys. An instance of the database is a functor N ! which sends each abstract

table to a concrete set of rows. By generating our data stores directly from models, our data is

automatically tied to its semantics.

We can then use functors to formalize the relationship between old and new models. This will provide

a dictionary to guide our translation. Moreover, expressing the transformations in these terms can help to

organize and explain certain inevitable features of this process.

A good example is the phenomenon of duality between models and data. A meticulous reader will

have noted that, in the discussion of architectural models, we said that “every hierarchy is a special kind

of network”, but then proceded to define a functor NH. The direction has reversed!

The categorical formulation explains this fact: given a functor NH and an instance H !, we

can compose these at H to obtain an instance N !. So every functor between syntactic models

defines a mapping of instances in the opposite direction. We might call this operation model restriction or

projection, and categorically speaking it is simply composition.

While composition allows us to restrict data backwards along a functor, subtler and more significant

constructions called Kan extensions allow us to push data in the same direction as a functor [20]. In many

cases, data demanded by the new model will be unavailable in the old; in others, we may split one

concept into two, or vice versa. In all of these cases, Kan extensions provide explicit instructions for

building a “best approximation” to the old data, subordinate to the new schema.

Remarkably, the same operation of Kan extension can also be used to encode quantification in formal

logic [17] and periodic states in dynamical systems [15]. This points to a critically important aspect of

categorical methods: uniformity. The abstraction of CT allows us to apply the same set of tools to a

remarkably diverse set of problems and circumstances.

This can be problematic for beginners: even simple applications of CT may require learning several

abstract constructions. Why bother, when there are easier solutions to this problem or that? The value of

the CT approach only becomes apparent for more substantive problems, where the same familiar tools

can still be applied.

Another nice property of categorical models is modularity, which is supported by the fact that the

colimit construction is a functor. Suppose, for example, that we extend one of the models in figure 5(a) via

a functor NN. A categorical construction principle for the colimit then guarantees that we can build a

new map ./012M3N4O ./012M3N4 O. This allows us to update domain-specific models locally and

then lift these changes to a global context.

More generally, the category theoretic property of naturality (over the diagram of the colimit) encodes

the restrictions which must be satisfied if updates to multiple components are to be consistent with one

another. Other categorical constructions called fibrations have been useful in formalizing more general

9

bidirectional transformations, where updates may not be consistent with one another [13,9]. In fact, the

elucidation of this concept of naturality was the motivating goal in the original development of CT;

categories and functors were merely the supporting concepts which underpin ``natural transformations''

[11].

Our discussion here has tried to indicate the potential breadth of categorical analysis. In so doing, we

have sacrificed depth in return. There is much more to be said.

Conclusion

One by one, the elements of category theory may not seem so impressive. We already have OWL for

representic semantic information, and good tools for interacting with databases. The UML/SysML

language family allows us to build graphical models and translate them into code stubs for programming.

Modelica and other modeling languages allow us to describe component-based decompositions and link

these to dynamical simulations. R and other software provides tools for statistical modeling.

The real value of CT is that it provides a context in which all of these can interact, and a rigorous

language for defining and analyzing those interactions. Now we have a chance to formalize entire

toolchains and workflows: we can agree on a graphical model, produce from it a semantic (logical) model

and populate it with data from an existing schema. We can use that data to derive a dynamical model,

and transform this into a computational simulation before piping the results to statistical software for

analysis. This entire process can be structured by categorical models.

This indicates why systems engineering offers an ideal test bed for the emerging discipline of applied

category theory. First, there is no avoiding the need to employ formal methods from multiple disciplines.

The details of our system exist at different scales and layers of abstraction. The need to interface

between many groups and researchers generates many demands: precise language to prevent

misunderstanding, intuitive (e.g., graphical) representations for easy communication, and structural

modularity for putting these pieces together.

Today, CT can supply plausible suggestions for meeting all of these requirements and more. However,

much work is required to turn this promise into practice. We can identify at least two important obstacles

which have stymied the growth of applied category theory.

First of these is CT’s learning curve, which is undeniably steep, but has become more gentle in recent

years. New textbooks [16,22] targeted at scientists and undergraduates have made the mathematical

ideas more accessible. New applications in areas like chemistry [7], electrical engineering [5] and

machine learning [8] have broadened the base of examples to more concrete, real-world problems.

A more substantial obstacle is tool support. Today CT can solve many problems at the conceptual

level, but there are few good tools for implementing those solutions. Outside of functional programming

(one of the major successes of CT) most software is academic, and it is neither simple enough nor

powerful enough to address system-scale demands. Addressing this deficiency will require substantial

funding and a concerted effort to bring together mathematicians with domain experts to attack complex,

real-world problems.

Fortunately, this requirement is less daunting than it seems. Because CT generalizes many other

formalisms, we should be able to use existing tools to solve categorically formulated problems. By turning

a category into a logical theory we can use an OWL theorem prover for validation. To analyze the

behavior of a functional model, we can derive a Petri net for simulation. By projecting our categorical

models back into existing formalisms, we can piggyback on existing tools and methods. The results of

these analyses can then be lifted back to the categorical level for a holistic appraisal.

We envision an open, CT-based platform for information modeling and analysis. The platform should

support modules for the various CT constructions (e.g., functors, colimits) and translations (OWL, SQL,

petri nets), which could then be assembled on a case-by-case basis to address specific problems. In the

long run, such a platform would be applicable across many domains, but to get there we first need to drill

down and provide a proof of concept. Systems engineering is the perfect candidate.

10

Disclaimer

Any mention of commercial products within NIST web pages is for information only; it does not imply

recommendation or endorsement by NIST.

References

1. Abran A, Moore JW, Bourque P, Dupuise R, Tripp LL. Software engineering body of knowledge. New York: IEEE Computer Society;

2004.

2. Arbib M, Manes G. Foundations of system theory: decomposable systems. Automatica 1974:10(3),285-302.

3. Arp R, Smith B, Spear AD. Building ontologies with basic formal ontology. Cambridge: MIT Press; 2015.

4. Baez J, Stay M. Physics, topology, logic and computation: a Rosetta Stone. In: Coecke, B editor. New Structures for Physics 2011.

Heidelberg: Springer; p. 95-168.

5. Baez J, Fong B. A compositional framework for passive linear networks. arXiv preprint 2015:1504.05625.

6. Breiner S, Subrahmanian E, Jones A. Categorical models for process planning. Under review: Computers and Industry, 2016.

7. Coecke B, Fritz T, Spekkens RW. A mathematical theory of resources. Information and Computation, 2014: 250:59-86.

8. Culbertson J, Sturtz K. Bayesian machine learning via category theory. arXiv preprint 2013:1312.1445.

9. Diskin Z. Algebraic models for bidirectional model synchronization. In Czarnecki K, et al. editors. International Conference on Model

Driven Engineering Languages and Systems 2008. Springer, p. 21-36.

10. Diskin Z, Maibaum T. Category theory and model-driven engineering: From formal semantics to design patterns and beyond. In

Cretu LG, Dumitriu F, editors. Model-Driven Engineering of Information Systems: Principles, Techniques, and Practice 2014.

Toronto: Apple; p. 173-206.

11. Eilenberg S, Mac Lane S. General theory of natural equivalences. Trans. AMS 1945; 58(2):231-294.

12. Jacobs B. Categorical logic and type theory. New York: Elsevier; 1999.

13. Johnson M, Rosebrugh R, Wood RJ. Lenses, brations and universal translations. Math. Struct. in Comp.Sci. 2012; 22(01):25-42.

14. Johnson M, Rosebrugh R, Wood RJ. Entity-relationship-attribute designs and sketches. Theory and Applications of Categories

2002; 10(3):94-112.

15. Lawvere FW. Taking categories seriously. Revista Colombiana de Matematicas 1986; XX:147-178, 1986.

16. Lawvere FW, Schanuel SH. Conceptual mathematics: a first introduction to categories. Cambridge: Cambridge; 2009.

17. MacLane S, Moerdijk I. Sheaves in geometry and logic: A first introduction to topos theory. New York: Springer Science & Business

Media; 2012.

18. Robinson M. Sheaves are the canonical datastructure for sensor integration. arXiv preprint 2016::1603.01446.

19. Rosebrugh R, Wood RJ. Relational databases and indexed categories. In Seely RAG, editor. Proceedings of the International

Category Theory Meeting 1991 1992. Providence: Canadian Mathematical Society (vol. 13):391-407.

20. Spivak DI. Functorial data migration. Information and Computation 2012; 217:31-51.

21. Spivak DI. The operad of wiring diagrams: Formalizing a graphical language for databases, recursion, and plug-and-play circuits.

arXiv preprint 2013:1305.0297.

22. Spivak DI. Category theory for the sciences. Cambridge: MIT Press; 2014.

23. Spivak DI, Kent RE. Ologs: a categorical framework for knowledge representation. PLoS One 2012; 7(1):e24274.

24. Spivak DI, Vasilakopoulou C, Schultz P. Dynamical systems and sheaves. arXiv preprint 2016:1609.08086.

25. Wisnesky R, Breiner S, Jones A, Spivak DI, Subrahmanian E. Using category theory to facilitate multiple manufacturing service

database integration. J Comput Inf Sci in Eng, In press.