Design Considerations from Weinberg's "Introduction to General Systems Thinking"

For those of you bored with this topic, you will be happy to know that I am on my last post. For those of you that find this interesting, thanks for sticking with me. :-) (Also, I will suggest that you get a copy of the book and find your own insights and wisdom in it. I certainly did not cover all the details!)

Let me jump into design considerations that Weinberg highlights. These are questions that I ask myself when modeling a system/designing an ontology:

• What notions are within and what are external to our systems? In other words, what are the boundaries of our system?
• How might we partition or decompose our system? When we decompose, how do the parts interact?
• In talking about "interactions", we start to talk about behavior... What is the behavior of the system and its parts? What are the system's and parts' possible states and how are they constructed or achieved?
• What is constant (survival and stable) about the system? What changes? Are there observable causes and effects?
• White box or black box techniques can be used to define and understand behavior. If we use black box, then we are observing and suffer the inadequacies of our observations (as pointed out in my second post on this subject). If we use white box, then we may miss behaviors that are inherent and not of our own construction. A combination of both techniques can provide good insights.
• In understanding behavior, you have to assume that you have incomplete knowledge. This is Weinberg's Diachronic Principle: "If a line of behavior crosses itself, then either: the system is not state determined or we are viewing a projection - an incomplete view."
• And, another, similar principle is the Synchronic Principle: "If two systems occur in the same position in the state space, at the same time, then the space is under dimensioned, that is, the view is incomplete."
• What are the properties or qualities of our systems? How do they change as the system evolves? Are there invariant properties? In particular:
• What properties are used for identity?
• What is "typical" about the system?
• What is "exceptional" (but important) about the system?
• What properties are used to define and control the system?
• What are we missing? (Sometimes we miss important properties or behaviors because we look at things using our "standard" approaches, notations and tools.) Can we look at a system or problem differently in order to gain new insights?
• Weinberg highlights the need to change our methods and approaches when new problems present themselves (especially if our current ways of thinking are not working). He captures his insights in his Used Car Law, and asks "[W]hy do we continue pumping gas into certain antique ways of looking at the world, why do we sometimes expend mammoth efforts to repair them, and why do we sometimes trade them in?"
• Another insight is Weinberg's Principle of Indeterminability: "We cannot with certainty attribute observed constraint either to system or environment." In other words, does our system have only small things in it because that is true or because we only have a net that lets in small things?

Hopefully, some of these questions will help when modeling or observing new systems. Let me know if you have other insights from Systems Thinking or just have other questions that you ask yourself when trying to understand a system or address a new problem.

Andrea

Part 2 on What I Learned from "General Systems Thinking"

Welcome back. I want to continue my overview of Gerald Weinberg's "Introduction to General Systems Thinking". I thought that I could shorten the discussion and fit the rest of the book into one more post. But, the more that I re-read the book, the more that I found to talk about! So, I am going to continue my ramblings and discuss Chapters 3 and 5, building on my previous post.

Chapter 3 is all about "System and Illusion" (that is its title!). It starts by asserting that a "system is a way of looking at the world". Obviously, how we look at something influences what we see. And, after we have looked at something, we can try to write it down/produce a model that describes the thing (describes that piece of the world).

We have lots of ways of looking at the world, and lots of models that reflect our different perspectives. But, these models won't all agree. It is important to remember that even if models don't disagree, each one may be totally valid (since it is defined from a unique perspective). Wow ... how do we do anything with that?

Well, we start by acknowledging that the problem exists and not get into religious wars about why "my model is better than your model" (or substitute the word, "ontology" for "model"). We need to understand the systems/models/ontologies and look at the perspectives behind why and how they were designed. When I have done this in the past, I saw things that I missed because I lacked certain perspectives. I also saw things that I did not need to worry about (at a particular point in time), but felt that I might need later. And, if I did need them later, how would I incorporate them? The last thing that I wanted was to paint myself into a corner.

So, what do we need to consider? Systems in the world of "general systems thinking" are sets of things. The entities in the sets vary by perspective. For an example, consider a candy bar. In a system that is concerned with eating, the candy bar may be broken into chunks of certain size and weight. And, you may be worried about the size of your chunk. But, in a system that is concerned with the chemical components of the candy bar, the size of the pieces doesn't matter at all. The constituent molecules and their combination are everything.

Hall and Fagen in their paper, "Definition of Systems" (1968) state that:

A system is a set of objects together with relationships between the objects and between their attributes.

That sounds a lot like an ontology. But, in defining the objects and their relationships, be careful. Don't be limited by how you write your model. Often, we get tangled up in our notations and limit our thinking to what we can express. For example, we say "I can express xyz with XML, or abc with OWL, or mno with UML. So, that is all that I can do." Indeed, we will always be limited by our notation, but our thinking should not be. This is one of the general cautions or principles that Weinberg highlights:

The Principle of Indifference: Laws should not depend on a particular choice of notation.

Unfortunately, Weinberg later turns around (in Chapter 5) and states that reality is quite different than what we want or what should happen (remember that there will always be exceptions to our laws and principles :-). Reality is never fully perceived, and our abstractions may be flawed since "the limited mental powers of the observers influence the observations that they make". That leads us to another principle:

The Principle of Difference: Laws should not depend on a particular set of symbols, but they usually do.

We get involved in our own symbols and notation. In fact, we may be agreeing on perspective and modeling the same system with the same components as someone else. But, we won't realize it, because we can't see past our notation.

So, let's take a step back and try to look at a system from many perspectives, and understand the semantics independent of the notation. We need to look at the system broadly enough to understand its scope, and then try to "get a minimal view" ("one that lumps together [information that is] ... unnecessarily discriminated"). But, when we simplify (or minimalize), we need to feel that our model is "satisfying", that it conforms to what we know of the world, its past behaviors and our past experiences. Weinberg calls this his "Axiom of Experience".

Buckminster Fuller put it more eloquently, I think ...

When I am working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong.

Andrea

General Systems Thinking, a (classic) book by Gerald Weinberg

Early in my career, I was told to read the book, "An Introduction to General Systems Thinking", by Gerald Weinberg. It was supposed to teach me how to model. So, I dutifully read the book and ended up learning a great deal. Mostly, I learned how to look at problems, solutions and models.

For everyone that does not have time to read the book, or just wants a quick overview .... I would like to summarize the main concepts (what Weinberg calls "laws" and "principles") - especially the ones that have stuck with me through the years. So, here goes.

Let's start by observing the obvious. Systems are complex, and all of our science and technology fall down when faced with the fullness of that complexity. So, we try to simplify. We try to find the least amount of information (smallest number of assumptions or details) that help us define, predict or understand a "system". This works well when we have lots of individuals (or parts) in a system (leading to the "law of large numbers" - that statistical predictions work well when calculated over large populations) or when we have a very small number of individuals (when we can observe them all). We have problems, however, in the world of medium numbers.

Weinberg's Law of Medium Numbers: For medium number systems, we can expect that large fluctuations, irregularities, and discrepancy with any theory will occur more or less frequently ... Translated into our daily experience ... the Law of Medium Numbers becomes Murphy's Law ... Anything that can happen, will happen.

Many systems are typically made up of a medium number of individuals/parts. This means that we can't just average across the behavior of the parts, or look at all the parts independently. Taking the latter approach, we would have to consider all the parts and all their interactions within the system. But, we quickly find an exponential number of things that we have to study! So, we apply reasoning and simplifying assumptions.

Weinberg builds on the work of Kenneth Boulding ("General Systems as a Point of View") and highlights the need to discover "general laws". Typically, we find these laws by generalizing from specific, different disciplines. He examines the roles of analogy, categorization and the concepts of generalization and induction. The key is to find similarities in the individual "laws" of specific disciplines and extrapolate to the general laws. Then we can apply these general laws in new situations to understand them and draw conclusions. Weinberg says:

To be a successful generalist, one must study the art of ignoring data and of seeing only the "mere outlines" of things.

In defining his general laws, Weinberg makes a point of discussing that laws evolve as new information is discovered. But, he also observes that the laws themselves are usually the last things to change (the "Law of the Conservation of Laws" :-). Instead, conditions are added to the laws to account for negative cases. So, a law becomes "x=y unless ..., or if ...". Like the rules of parlay (Code of the Order of the Brethren) from Pirates of the Caribbean, "the code is more what you'd call 'guidelines' than actual rules". Weinberg's laws are meant to be memorable, generally true and 'guidelines'. They can be understood as bits of insight and "stimulants" to thought (i.e., not really "laws").

What are a few of Weinberg's general "laws"?

• Law of Happy Peculiarities - Any general law must have at least two specific applications
• Law of Unhappy Peculiarities - Any general law is bound to have at least two exceptions (or, if you never say anything wrong, then you never say anything)
• Composition Law - The whole is more than the sum of its parts
• Decomposition Law - The part is more than a fraction of the whole

I love Weinberg's "laws" and sense of humor. I noticed that one of my development "rules of thumb" simply follows from Weinberg's Law of Happy Peculiarities ... "You must always have at least 2 use cases. A use case of one always has a solution."

So with that observation, we come to the end of Chapter 2 in Weinberg's book. There are more great discussion points and principles that I want to cover. But, I will leave them to my next post. In the meantime, I will close with some thoughts from the mathematician, Mark Kac (which are mostly also at the end of Chapter 2):

Models are for the most part caricatures of reality, but if they are good, then, like good caricatures, they portray, though perhaps in distorted manner, some of the features of the real world ... The main role of models is not so much to explain and to predict - though ultimately these are the main features of science - as to polarize thinking and to pose sharp questions ... They should not, however, be allowed to multiply indiscriminately without real necessity or real purpose.

Kac implies that there are three activities that involve models - "improving thought processes" (as described in the quote above), "studying special systems" (understanding and translating to the specific from the general) and "creating new laws and refining old" (systems research!).

Amen!

Andrea

Design Thoughts

I was going through some older books that I had stored away, and came across the book, Change By Design, by Tim Brown. The book was published in 2009 and is not particularly earth shattering or deeply enlightening. But, it does contain some nuggets that resonated with me (especially watching less-experienced software engineers try to design a complex system, or (even harder) a good, domain ontology that is somewhat future proof).

There is a valuable quote from the book ...

Design thinking … [matches] human needs with available technical resources within the practical constraints of business.

Seems obvious, right? But there is really much more to this statement than is understood with a cursory reading.

When designing a solution, you have to start with the needs and requirements of your customers (and they are not always realistic). Then, you have your available technologies ... maybe OWL/RDF and triple stores, maybe natural language parsers and libraries, maybe good insights from design patterns that can be reused. Lastly, you have constraints - be they time, money, lack of experienced personnel or any number of other things.

Too often, I see a team focus on what they know, and design some amazing aspect of a project ... but NOT what the customer needs. So, you end up with a partial solution that disappoints your customer, but you are proud of what you accomplished. Then, you decide that the customer or user is unreasonable. I have seen this happen a lot.

So, here are some words of advice ...

• Design the best solution that you can, taking everything into account and being honest where you are stretching beyond your comfort zones.
• Always strive to do incremental development and prototyping.
• Don't be afraid to fail and don't sacrifice the overall design to 1) make everything perfect or 2) focus on what you know. If you do the former, you will never deliver anything. If you do the latter, you will never be able to implement the big picture, because you are ignoring it. Also, you will surprise the customer because you are thinking that you have everything covered, when really, you only have a small aspect of the complete solution covered.

Also, remember that incremental development is just that ... incremental ... nothing in software is ever really perfect or complete. It really comes down to whether it works and whether the customer is happy.

P.S. I have only touched on a few of the points in the Change by Design book. There are lots of good summaries out on the web. One example is the page from the Idea Code Team.

Andrea

More on modular ontologies and tying them together

There is a short email dialog on this topic on the Ontology Summit 2014 mail list. I thought that I would add the reply from Amanda Vizedom as a blog post (to keep everything in one place).

Amanda added:

The style of modularity you mention, with what another summit poster (forgive me for forgetting who at the moment) referred to as 'placeholder' concepts within modules, can be very effective. The most effective technique I've found to date, for some cases.

Two additional points are worth making about how two execute this for maximum effectiveness (they may match what you've done, in fact, but are sometimes missed & so worth calling out for others.

Point 1: lots of annotation on the placeholders. The location & connection of the well-defined concepts to link them to is often being saved for later and possibly for someone else. In order to make sure the right external concept is connected, whatever is known or desired of the underspecifies concept shoud be captured (in the location case, for example, may be that it needs to support enough granularit to be used for location at which a person can be contacted at current time, or must be the kind os location that has a shipping address, or is only intended to be the place of business of the enterprise to which Person is assigned & out of which they operate (e.g., embassy, business office, base, campus). That's often known or easily elicitable without leaving the focus of a specialized module, and can be captured in an annotation for use in finding existing, well defined ontology content and mapping.

Point 2: advantages of modules, as you described are best maintained when the import and mapping are done *not* in the specialized module, but in a "lower" mapping module that inherits the specialized module and the mapping-target ontologies. Spindles of ontologies, which can be more or less intricate, allow for independent development and reuse of specialized modules, with lower mapping and integration modules, with a spindle-bottom that imports all in the spindle and effectivle acts as the integrated query, testing, and application module for all the modules contained in that spindle, providing a simplified and integrated interface to a more complex and highly modular system of ontologies. Meanwhile, specialized modules can be developed with SMEs who don't know, care, or have time to think about the stuff they aren't experts about, like distinguishing kinds location or temporal relations or the weather. Using placeholders and doing your mapping elsewhere may sound like extra work, but considering what it can enable, it can be an incredibly effective approach.

Indeed, the second point is exactly my "integrating" ontology, which imports the target ontologies and does the mapping. As to the first point, that is very much worth highlighting. I err on the side of over-documenting and use various different kinds of notes and annotation. For a good example, take a look at the annotation properties in the FIBO Foundations ontology. It includes comment, description, directSource, keyword, definition, various kinds of notes, and much more.

Another set of annotation properties that I use (which I have not seen documented before, but that I think is valuable for future mapping exercises) are WordNet synset references - as direct references or designating them as hyponyms or hypernyms. (For those not familiar with WordNet, check out this page and a previous blog post.)

Andrea

Creating a modular ontology and then tying the pieces together

In my previous post, I talked about creating small, focused "modules" of cohesive semantic content.  And, since these modules have to be small, they can't (and shouldn't) completely define everything that might be referenced.  Some concepts will be under-specified.  

So, how we tie the modules together in an application?

In a recent project, I used the equivalentClass OWL semantic to do this. For example, in a Person ontology, I defined the Person concept with its relevant properties.  When it came to the Person's Location - that was just an under-specified (i.e., empty) Location class.  I then found a Location ontology, developed by another group, and opted to use that.  Lastly, I defined an "integrating" ontology that imported the Person and Location ontologies, and specified an equivalence between the relevant concepts.  So, PersonNamespace:Location was defined as an equivalentClass to LocationNamespace:Location. Obviously, the application covered up all this for the users, and my triple store (with reasoner) handled the rest.

This approach left me with a lot of flexibility for reuse and ontology evolution, and didn't force imports except in my "integrating" ontology.  And, a different application could bring in its own definition of Location and create its own "integrating" ontology.

But, what happens if you can't find a Location ontology that does everything that you need?  You can still integrate/reuse other work, perhaps defined in your integrating ontology as subclasses of the (under-specified) PersonNamespace:Location concept.

This approach also works well when developing and reusing ontologies across groups.  Different groups may use different names for the same semantic, may need to expand on some concept, or want to incorporate different semantics.  If you have a monolithic ontology, these differences will be impossible to overcome.  But, if you can say things like  "my concept X is equivalent to your concept Y" or "my concept X is a kind of your Y with some additional restrictions" - that is very valuable.  Now you get reuse instead of redefinition.

Andrea