Cohomology of Combinatorial Modules

1. Cohomology of Combinatorial Modules With applications to organisational analysis Andrew Macfarlane Version 26/06/2011

2. Introduction • The PowerPoint “Introduction to Combinatorial Modules” introduces Combinatorial Modules up to the point of the sheaf of Schedules (denoted Sch(A)) • Cohomology is a tool for the analysis sheaves. This is usually done with Čech Cohomology which has been adapted for analysising sheaves of schedules. However… • We first of all motivate the concept of cohomology but looking at the idea of complexity of organisational systems. This gives a new cohomology called Viewpoint Cohomology which is a generalisation of Čech Cohomology.

3. A concept of complexity • Because complexity is an ill-defined subject and one authors can use without actually having a starting measure it seems a good idea to nail down what we are interested in. • The concept of complexity here is called integrative complexity with respect to a viewpoint and a protosheaf.) • A viewpoint is a vocabulary for describing some phenomena. In this case the phenomena will be scenarios (sequences of actions or even schedules). If  is any scenario a viewpoint starts with a set of properties {P1,P2,….,Pn} at least one of which is true for . The rest of the vocabulary, the classes or predicates, is made up of combinations of these Pi. • A protosheaf is a way of selecting and counting the scenarios that belong to a class in this vocabulary. Formally it is very similar to a presheaf. • Integrative complexity is a measure on combinatorial modules but it is not a number. Pure mathematicians often “measure” the complexity of a twisted high dimensional surface (manifold) or an algebraic system by reducing it to set of simply systems, perhaps dimension by dimension. We use this approach here and evaluate the integrative complexity of a system in another mathematical category; one we are quite familiar with and so we can understanding what it is telling us.

4. What a measure of complexity must show. • Let A(S)be the category of combinatorial module representations of a class of systems S. Vis a viewpoint, a vocabulary describing the sequences of actions in S. Then we want a complexity measure E(V,P):A(S ) C where C is some well understood category such as sets, vector spaces or groups such that: • If A1 is a combinatorial sub-module of A2 then there is monomorphism E(V,P):(A1)  E(V,P)(A2) in C. • Furthermore in this case there is a sense in which E(V,P)(A2) can be calculated when we disregard the complexity of A1. • If A1 and A2 are combinatorial modules and A1  A2 is a surjection then there is an epimorphism E(V,P):(A1)  E(V,P)(A2) in C. This gives sense of more or less complexity depending on size. • E(V,P):(A1) is contains no redundant information in the sense it does not repeat relationships among the scenarios. • Here a monomorphism is the category generalisations of a function being 1:1 and into while an epimorphism is the generalisation of a surjective or onto function.

5. Why should we worry? • The first very practical consideration for the information systems or software industry is project management. You cannot estimate project time without some measure of project complexity. The evidence for this is in Capers Jones’ Applied Software Measurement in which he shows how IBM outmanoeuvred its competitors by better software project estimation using function point analysis. • Function point analysis is a good measure of size but not such a good measure of complexity. • All sciences proceed with better and better measures (consider the contentious failure in psychology to find useful measure of personality) • Measures of structure, interrelationships and complexity are difficult but in software engineering we must have them if we are to contribute to social and organisational structures on a crowded planet.

6. Technicalities 1 • We have slid over a complication. If S1 and S2 are systems then there is often no clear way of relating S1 and S2 by a transformation while if A(S1) and A(S2) are the corresponding combinatorial representations then there is a clear way to define an affine and possible logistic map f:A(S1)  A(S2). • However the properties of scenarios of A(S1) have to be translated to properties that apply in A(S2). • This means we must know how to do this and this requires a clear definition of a viewpoint. • We define a viewpoint as a set of properties {P1,P2,….,Pn} together with a subset of expressions of the type Pi0 * Pi1 * …* Pin where i0, i1,..,inis a subset of 1,2,3…n(PowerPoint is rather limited in subscripts of subscripts) • The power of this simple idea comes from the variety of ways it can be interpreted. • The simplest being * is just ^ or conjunction of properties.

7. Varieties of viewpoints • If V is a viewpoint with properties {P1,P2,….,Pn} and predicates (or classes) Pi0 * Pi1 * …* Pin where i0, i1,..in is a subset of 1,2,3…nthen Pi() means Pi is true of at least part of  and (Pi *Pj) () means there is a ’ with Pj(’) that has the relation (Pi *Pj) with . If (Pi *Pj) = (Pi and Pj) this meanswe can find a scenario’ so that Pi and Pj are true of  and ’. • Other than * as “and” the other default relation is as follows: • Pi *Pj is associated witha relationship Rij between scenarios  and ’ such that Rij(,’) implies Pi () and Pj (’) or Pi (’) and Pj(). • A variation of this is (Pi *Pj)()implies that there existsa relationship Rijkand a scenario ’ such that Rijk(,’) implies Pi () and Pj (’) or Pi (’) and Pj(). Here Rijk is one of a finite number of possible relations. We can get back to the previous case by setting Rij = kRijk the disjunction of all the relations Rijk . • A translation from one viewpoint V1 to another V2 is a map v: V1V2 such that v takes properties to properties and is a monoid homomorphism: v(Pi0 * Pi1 * …* Pin) = v(Pi0) * v(Pi1)* …*v (Pin). • The definition of the complexity functor withE(V1,P):(A(S1))  E(V2,P)(A(S2)) in C. requires the possibility of the translation of V1 from a viewpoint in A(S1) to the appropriate viewpoint in A(S2)

8. Viewpoints and business operations • It is the job of a business analyst to document business structures and map out what type of information system would aid in systemisation. • This requires being able to separate business scenarios from each other; hence the properties. • The people who are business experts in one area (aka subject matter or domain experts (SMEs)) know their subject but not the details of other peoples work. They understand business scenarios “locally”: sales and order entry now customers, products and prices; people who know scheduling don’t know details of pricing; people who look after supplies and inventory don’t know the details of any of the other areas; accountants do not know the details of scheduling operations and inventory control and so on. • The business analyst needs to seek out and understand the relationships among the “local knowledge” and the full operations of the organisation. • This means whenever I have a scenario described locally I need to think “with what does this link”. In effect I am going from Pi ((local) ) to (Pi* Pj) looking for ’ that have some relation Rij with  . • The next step is ‘are there further relations Rijk in(Pi* Pj* Pk) linking a ” with ’ and ”. And then (tirelessy!) Pi* Pj* Pk * Pl and onto Pi0 * Pi1 * …* Pin… • As each local scenario  might be identified with a data structure and displays this leads directly to the requirements and design of information systems. It can also lead to protocols of diagnosis and the treatment of illness or defects in machines, planning accountability and so on.

9. Varieties of viewpoints 2 • Complexity will be defined in terms of viewpoints. Different viewpoints give different complexities. What if the viewpoints are inconsistent – what does that mean? In Integrative Complexity and Its Cohomological Representation on this web site the concept of consistency classes of viewpoints is developed. We do not describe it here instead we give an example. • Below we give an example of a viewpoint for a supply chain in which the properties are defined in terms of schedules of supplier groups. Consistent with this is a concept of risk (or probability of a schedules failing). • If risk can be defined as a viewpoint then it can be combined with other viewpoints provided they are both part of the same consistency class. • A consistency class is (roughly) the aggregate of all the formal “languages” that can be used to describe the scenarios of the system. • If segments of scenarios can be rated by risk then a * multiplication of properties defines the interaction of risks. This leads to assigning accumulated risk to relations of scenarios.

10. Counting scenarios: Protosheaves • A system becomes more complex as parts interrelate. If each  represents a sequence or cluster of function points (data structures and screen displays) then a system can have a large number of function points without being complex. If there are few elements in the various relationsPi0 * Pi1 * …* Pin the system is simply a large number of unrelated systems. • However if (Pi0 * Pi1 * …* Pin)() is true of many relations of scenarios we also need to ask are any of these related? • A protosheaf P is a way of counting scenarios. It is a map P:V  Z-mod where Z-mod is the category of modules over the integers (think of expressions n1. 1n2. 2…nk. k wheren1, n2 ,…, nk are natural numbers) and for every relation in Pi0 * Pi1 * …* Pin there a map k: P (Pi0 * Pi1 * … * [Pik]* …* Pin )  P (Pi0 * Pi1 * … * Pik* …* * Pin ). where * [Pik]* means Pik is omitted from the expressionPi0 * Pi1 * …* Pin • The maps k ,j for different k and j compose and obey descent or coherence conditions which means they can work together.

11. Protosheaves 2. • The map : P (Pi)  P (Pi * Pj) takes  to a relation Rij if there exists a ’ such that Rij(, ’) and Pj(’). It does not identify ’ but only that there is an element of P (Pj) that has a mutual relation with . • We write  in P (Pi0 * Pi1 * … * Pin ) if (Pi0*Pi1 * … *Pin )() is true. If fact a little bit more than that as  in P (Pi0 * Pi1 * … *Pin ) means  can take part in a primitive arithmetic in P (Pi0 * Pi1 * … * * Pin ) • In particular it is possible to have equations 71 - 42 = 33. Depending on the system and the scenarios – for example schedules – such equations make perfect sense and exploit the definition of P having values in Z-mod.

12. Structure of Logical Systems • Logical systems are systems with variables x,y,z.. x1,x2,..xn, y1, y2,.. etc which have properties P1, P2,… and various levels of relations Rij, Rijk,…linking respectively 2, 3,..variables. • The theorems of such a system concern the way sets of variables relate to other sets of variables through the relations. • If we collect together all pairs of variables we can ask when given a pair (x,y) “is there is relation between this pair?” However we do not want relations R(x,y) = P1(x)^P2(y) or similar. • A relation R(x,y,z) relates 3 possible properties but it is not a new relation is it is R1(x,y) and R2(y,z) or similar. That is we are only interested in R(x,y,z) if it cannot be derived from R(x,y). In other works we don’t want to count R(x,y,z) if it can be expressed in terms of already defined 2 variable relations. • This suggests we gather together relations that relate 1,2,3.. Variables with 1-relations (properties), 2-relations R(x,y), 3- relations R(x,y,z) and so on and get a sequence R1 R2  R3  …. where Rn  Rn+1 takes n relations in Rn among n+1 variables and composes an (n+1)-relation in Rn+1. If we want the new relations we are only concerned with what is left in Rn+1 that cannot be made from Rn. Denote this residue by Ln. The set of such residues are the significant relations among n variables. • This looks promising but it doesn’t tell us anything about the internal logic of each Ln.

13. Going geometric • In our logical system we think of properties as points, a relation R12(x,y) can be a line between P1(x) and P2(y), R123(x,y,z) is a triangle linking P1(x), P2(y) and P3(z), R1234(x1,x2,x3,x4) is a tetrahedron triangle linking P1(x1), P2(x2), P2(x3) and P4(x4). • If I hold z constant in R123(x,y,z) I have a relation Rz(x,y) giving a “side of the triangle”. • Now we go Algebraic. • Define C1 is the integer module of all properties. This means we can think of 20.P1 + 7.P2 as 20 instances of P1 and 7 instances of P2. Also we allow expressions such as 20.P1 - 7.P3. • What would it mean to say R12(x,y) + R23(y,z) = R13(x,z)? • The best interpretation is that the presence in the system of R12(x,y) and R23(y,z) implies R13(x,z) but also R13(x,z) means there must be R12(x,y) and R23(y,z). In terms of the geometric picture this means R12(x,y) - R13(x,z) + R23(y,z) = 0 looks like going around the triangle. It suggests there might be a R123(x,y,z) that gives the individual “sides” such as R13(x,z) their existence. • In fact a “cyclic” relationship R12(x,y) - R13(x,z) + R23(y,z) = 0 exists if and only if there is a relation R123(x,y,z) to sustain the “cycle”. • This motivates the definition of cohomology (and homology)

14. Cohomology • Let C0 be the direct sum (think product) of P(Pi), C1 the direct sum of all the P(Pi0*Pi1), C2 the direct sum of all the P(Pi0*Pi1*Pi2) and generally Cn=  P(Pi0*Pi1*…*Pin) =  P(Pi0*Pi1*…*Pin) where the product or direct sum is over every sequence i0 < i1 <…<in. • Cnis called the n-th cochain Z -module for the protosheafP. The n denotes the number of * operations. For every n 0 define the coboundary operator n: Cn Cn+1 by n(i0, i1,…, in) = (-1)kikik where the sum is over all ikand eachikis from P(Pi0*Pi1*…*[Pik]*…*Pi(n+1)). • It is always the case that n+1 on = 0. n is always a homomorphism and its image, the n+1 coboundaries are a Z -sub-module , denoted Bn+1 of Cn+1. The kernel of n is the set of (i0, i1,…, in) such that that n(i0, i1,…, in) = 0. These are denoted Zn and are always Z -sub-module of Cn. Because n+1 on = 0 Bn is always a submodule of Zn. This means the residue classes of cocycles relative to coboundaries denoted Zn/Bncan be defined. Finally the n-th cohomology group Hn = Zn/Bn. • And this is one slide the algebraic summary of what we have been talking about.

15. Integrative Complexity = Cohomology • Cohomology gives a complexity functor that satisfies the criteria given in slide 3. • This is not obvious but if you followed up to slide 11 you will see why this is called Integrative complexity. Each cocycle which is new at the n-th stage of creating relations integrates more variables. • The variables that we started with were scenarios but they could be anything that are the variables in a logical system the vocabulary of which is given by a viewpoint. • An example is the Internet. Including hyperlinks it has vast complexity. The Internet as a set of web-services but not counting hyperlinks outside a service, in spite of its huge function point count, has no more Integrative Complexity than its most complex web service.

16. Application to Supply Chains • The cohomology I applied to supply chains, an adaptation of Čech Cohomology, had a clear geometric interpretation. A covering of the supply chain A by sets Sk(a), all the suppliers of a through to the k-th level of suppliers “upstream”. This covering denoted by U is used with a sheaf of schedules P so that the n-th cochain Z -module is defined by Cn= P(Ui0Ui1 …Uin) where each Uik is in U. • We translate this to viewpoint cohomology. • Let P(a,k) be the property: P(a,k)() is true if  is a schedule for Sk(a) in the class P • * is interpreted as “common restriction” so for a schedule  of the class P, (P(a,k)* P(a’,k’))() is true for the common restriction which means (P(a,k)* P(a’,k’))() is true when  is defined for Sk(a)Sk’(a’). • This means the restriction maps (now you know where the name came from) (a’,k’):P(P(a,k))  P (P(a,k)* P(a’,k’)) simply takes the schedule  defined Sk(a) to its restriction on Sk(a)  Sk’(a’). • This extends to the full definition of the Čech Cohomology cochain sequence. The rest is algebra. • This means we have a definition of the integrative complexity of supply chains relative to this supplier covering viewpoint.

17. More on supply chains. • What are the relations among schedules in the viewpoint approach of cohomology. • If P(a,k)((a,k)) and P(a’,k’)((a’,k’)) are true then what is the relation between (a,k) and (a’,k’)? The relation is that they share a sub-schedule defined on the intersection of their domains. • In fact the relation can be anything definable in Sch(A) which is a Z-module. But that is only algebraic relations. For (a,k) and (a’,k’) the only algebraic relations are x.(a,k) = y’.(a’,k’) with x and y integers. • For i(ai,ki) i = 1,2,3..there can be relations xii(ai,ki) = xjj(aj,kj) + xkk(ak,kk) with xi, xj, xkintegers. Similarly relations can be equations xii(ai,ki) + xjj(aj,kj) = xjj(aj,kj) + xll(al,kl) and so on. • Because x.(a,k) is another schedule with the same property these relations are just equations of the form (a,k) = (a’,k’), i(ai,ki) =jj(aj,kj) + k(ak,kk), ii(ai,ki) + jj(aj,kj) = j(aj,kj) +xll(al,kl) etc. and these are the equations that determine cocycles and coboundaries. • Finally, there exist unexplored cohomologies (think analytical perspectives and measures of integrative complexity) defined on the class of viewpoints consistent with the one defined by the properties P(a,k) corresponding to schedules defined on Sk(a). • This is just the start of this subject. Applications require even more technical preparation.