Information Programming Unifies Business Goals and Technology Domains

Information programming doesn’t just integrate systems, it unifies systems. It can unify business goals with technology domains in software as it is developed. It can be used to unify technology domains. It can do this using endemes. Endemes can embed business goals in software, and can ride on top of conventional object oriented development.

  1. Business goals can be information modeled using endeme sets. Then the endeme sets can be implemented in a program.
  2. Knowledge representation and artificial intelligence can be built on top of an endeme layer.
  3. The endeme layer is then implemented in data technology domains such as object oriented programming and relational database storage.
  4. User interface development and networking are built using endeme empowered knowledge representation.
  5. Business people then use the user interfaces built using this approach and business goals are unified with the programs that are built.

Level 4 Issues

Programming won’t really be complete until we push our software development technology up to level 4.

Level 4 issues:

  • workflow
  • layout
  • ontological meaning/context

The reason we have so much trouble with workflow and layout is that we haven’t built level 4 yet.

build level 3 toward level 4?

                                          | | |
Level 4   UI -------+--+ layout  workflow | | | +-- networks
                    |  |    |         |   | | | |
          reports --+-------+----+----+---+---+-+-- database
                    |  |         |          | | |   integration
Level 3             |  |      endemes ------+ | |
                    |  |         |            | |
                    |  |   +-----+-----+------+ |
                    |  |   |           |        |
Level 2             | objects                   |
                    |    |                      |
Level 1                        data

Wisdom is a Computational Creativity Function

Wisdom is a Computational Creativity Function. The computer has to create what it is going to do by applying its understanding gained through artificial intelligence.

An Example:

  • Data: (Raw) Red,, v2.0
  • Information: (Meaning) South facing traffic light on corner of Pitt and George Streets has turned red.
  • Knowledge: (Context) The traffic light I am driving towards has turned red.
  • Wisdom: (Applied) I better stop the car!

The Example Converted to Levels:

0.    Raw      Data
1.    Stored   Data
2. -> Meaning  Data types and objects and hard defined structural interpretation
3. -> Meaning  Information with structural (and conceptual?) context as meaning
4. -> Meaning  knowledge representation with relational context to user
5. -> Context  knowledge and what various outcomes and actions mean
6. -> Applied  wisdom – stop the car!
Level 6 is computational creativity. The computer has to create an action.

Context and meaning are both built up through multiple levels rather than just being at one level each.

Endemes Allow a Computer to Understand Information Better.

Endemes Allow a Computer to Understand Information Better. They will allow you to write programs that understand information. I was recently reading the Wikipedia page on web 3.0. It has a cool diagram showing the information layers of Web 3.0. The Semantic Web Stack:


Web 3.0

To be clear, web 3.0 will use the following technologies to help a computer understand information:

  • OWL – ontologies
  • RIF – rules
  • RMD – key value pairs
  • RMDS – taxonomies

But this is not enough.

Ontologies tell what something means as related to other things. But the things need an initial meaning to transfer meaning to what they are related to. Taxonomies tell what something means in terms of hierarchies, i.e what something is part of
information base on what group something is in, useful but hierarchies don’t tell the computer enough (my intuition says). Key value pairs allow the building of ‘classes’ with ‘members’ and they say what they are made of but still not enough somehow and members tend to be very rigid and hard coded. Rules are useful but tend to focus on what to do with the information/its processing rather than the information itself.

The 3.0 Information Component set has:

a piece of information:
- what it's related to
- what it's part of
- what it's made of
- what to do with it

This still does not really tell you anything about what it means.

A Fifth Information Component Can Address Information Directly

Endemes allow you to include another thing to your informationn collection above.
Endemes allow you to say something about it’s importance The concepts meaningful and important and closely related. So adding endemes we have:

a piece of information
- what it's related to   - ontologies
- what it's part of      - categorization/taxonomies
- what it's made of      - constitution
- what to do with it
- what is its importance - characterization

The ‘what is its importance’ here not only includes a measure of its importance but a qualitative measures of the importance of concepts that it consists of or is defined with. You see endemes provide a set of concepts and the relative importance of each condept in defining a piece of information they define its improtance in qualitative terms rather than quantitative. When you do an endeme query on a list of items defined by endemes then you do get the importance of each of the items based on the query

A Possible Sixth Component of Information is Outcome

You can perhaps add another information component to the mix by addition an item for the future. A concept like ‘courage’ includes  a future part. Courage has to do with taking on things that could hurt me or that might not turn out. This brings in a predictive ramification, creative possibility, planning, strategy, goal, desire, emotion, time aspect
It may be only be relevant within a simulation or context.

This possible new information component relies on:
1. outcomes and goals(desired outcomes)
2. context – related to rules above
3. actions – related to strategy above.
For information, we only really need the outcomes list. The rest of the items get into a whole ‘nother ball of wax.



Building a Sparse Grid Through Attention Management

I have seen grids in UIs that have dozens of columns, and the user has to scroll right a page or two to see all of the items.

We can build UI grids that show only the columns a user wants or needs to see. Columns could be added and removed in the grid as desired by the user. We could build an attention management endeme or two to indicate which columns to show. Each column would have an endeme and a user would have an endeme to identify which columns they want to see. Using endeme matching the desired columns would be shown. The organization could also have an endeme identifying which columns are important in the business situation for each grid. In addition, columns with data changes, unusual values or critical values could be moved into those columns shown. Users could add and remove columns, changing their attention management endeme if they so desire when they do this.

The advantage of this is increased productivity by the user because their attention is managed toward what they need to see, i.e. cost savings. Another advantage of this is that many more columns could be included as possibilities in a grid. Instead of having a few dozen, the grid could handle a few hundred columns. More data when managed thorugh attention management endemes means a user that is smarter in their decisions resulting from seeing the data, i.e. cost savings and added business opportunity.

The DRY Principle and Information


In software development, DRY stands for Don’t Repeat Yourself. Conventionally this principle gets implemented by frameworks like ASP.NET MVC and Ruby on Rails by having a single source for column/field names, either the database or a class.

Framework Challenges

The challenge with these systems is to manage the sources. This requires high integration, and makes it very difficult for these frameworks to play with others. They are also very solidly based in a data oriented approach, meaning that they institutionalize hard coded context. With hard coded fields even when there is only one source for each, framework APIs become inflexible.

An Information Based DRY Framework

An information approach would treat each field as something to be processed and characterized rather than just as a field name and a type and other hard coded attributes. Information could provide flexible relationships between fields, flexibly created new fields, and control for the source of the field names, labels, types, and parsers.

Interacting with Another Framework

An endemized English vocabulary could be used to come up with an automatic signature for each of the columns in a database, each of the fields in entity framework, and each of the members of various data classes. These could be glommed. I have an endemized signature vocabulary for about 5000 words already available. Adding synonyms and two word definitions, and including another 1000 very common database column words could push this to 10000. Relationships could be identified from class memberships, operations and stored procedures. In this way an endemized framework could interact with MVC and Ruby on Rails without a lot of code written (once this framework was written).

An API to Anything

A further DRYing of code could happen by making the endemized framework a source. Once the framework above works, then this step becomes simple. And the endemized information framework can be a conduit to the other sources. We can build an API for interacting with the endemized framework giving other systems access to fields and rich metadata about fields in apps and databases. Endemizing provides flexible metadata, so there could also be an API to adapt the generalized framework to specific sources.

Every Diagram Has its Use, Here is an Overview of Software Development Diagrams

I have gone and looked at the various software development diagrams available on Wikipedia. I have focused on the graphs (nodes and connections). The natural level for graphs is level 4 (knowledge representation and ontologies). However level 4 has a broader scope than just (K.R. and O.). Here is what I was able to suss out.

Level 4 – High Level Information Programming – Knowledge Representation

Level 4 proper diagrams mostly have to do with relationships.

  • Anchor modeling
  • Concept map
  • Conceptual graph
  • Conceptual model
  • Concept-oriented model
  • Context diagrams
  • Data flow diagram – this diagram has a long and storied history, As level 4 develops, I expect to see this diagram rise in importance again.
  • Domain model
  • Information flow diagram
  • Information model
  • Object model
  • Object-role modeling
  • Semantic network
  • Semantic Web
  • Top Level Ontology

Some level 4 proper diagrams are based more on hierarchies than relationships. Of course a hierarchy is a kind of relationship.

  • Argument map
  • Cladistics
  • Document Object Model

Level 4 for Other levels

Here are some level 4 diagrams that apply to other levels:

  • 4(5) Fuzzy cognitive map
  • 4(3) Nets within Nets
  • 4(3) Specification and Description Language
  • 4(3) Composite Structure Diagram (UML)
  • 4(2) Abstract syntax tree
  • 4(2) Class diagram (UML)
  • 4(2) LePUS3
  • 4(2) Tree structure
  • 4(1) Entity–relationship model
  • 4(1) Hierarchical database model
  • 4(1) Network model

Diagrams for Other Levels

Here are diagrams that apply directly to other levels, although one could
certainly build systems at level 4 that would process these.

Level 1 – Data Storage and Relational Databases

Level 1 isn’t really very diagrammatic. It mostly relies on grids. The diagrams that apply best seem to be level 4 diagrams that manage level 1 such as entity relationship diagrams.

  • Jackson structured programming
  • Symbol table

Level 2 – Data and Object Oriented Programming

Many of these diagrams have to do with various sorts of process flow.

  • Algebraic Petri net
  • Behavior tree
  • Business process mapping
  • Business process model
  • Control flow diagram
  • Decision tree
  • Directed acyclic graph
  • DRAKON diagram
  • Dynamic model
  • Enhanced Transition Schematic
  • Event-driven process chain
  • Finite-state machine
  • Flowchart
  • Flow process chart
  • Function model
  • Interaction overview diagram (UML)
  • Petri net
  • Sequence diagram (UML)
  • State diagram (UML)
  • State Machine
  • Use Case Diagram (UML)

Level 3 – Low Level Information Programming

I have had a lot of trouble trying to find any diagrams that apply to level 3.
These are the closest, but they are very thin gruel.

  • Activity diagram (UML)
  • Composite structure diagram
  • Business logic
  • Component diagram (UML)

Level 5 – Artificial Intelligence

Knowledge representation is a substrate for artificial intelligence. I expected to find more of these. Perhaps as level 4 develops there will be more in the future.

  • C-K theory
  • Extended Enterprise Modeling Language

Level 6 – Computational Creativity

Computational Creativity is a severely underdeveloped level. I didn’t expect to find anything, but here is one that may make sense.

  • Mind map