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.

This building is a good analogy for the state of software development.

When building endemes by hand you are making decisions, so this form of building is a creative action. Endemes systemetize the construction of information, so endeme building can systemetize creativity.

ADVANTAGES
———-
Not to make light of these disadvantages because they are significant, why do I like them?
1. Endeme sets can play well with each other and a great variety of
information can be stored as endemes
– Things of different types can be compared and even related.
– It breaks down the walls that strict logic creates between similar data structures
2. It is oriented toward storing information much more than data
THEREFORE: Endemes contain a tiny piece of intelligence/information in a theoretically scalable form
– they might be used to build an artificial brain
3. Folk programming keeps creating codes. Endemes allow us to manage them.
4. There are ‘no wrong answers’ in a properly built endeme set.
This means endemes can be used for fault tolerant genetic algorithms,
and graceful degradation in systems.

DISADVANTAGES
————-
The main problem with the endeme information structure is that
1. it welds multiple fields into a less machine-accessable format which means:
– it can’t be directly used as an index
– you have to ‘pack’ it when you want to create one
– you have to ‘unpack’ it when you want to get at the information back out.
also
2. Data is lost when you move it from a numeric to a relative strength format.
3. You have to build an interpreter to make sense of it
4. You have to cram fields together until you can cover everything in scope in 22 characteristics or less

– Endemes are not for precise data: The obstacles mean that endemes are not for everything. For eaxample if you want to store temperature, you might not want to use an endeme for the data, although you might want to use it for the field.

• Advocate: sell/promote
• Benefit: help/improve
• Create: Build/Develop/Construct
• Decision: Decision Making/Choice/Action
• Effect: Event/Result/Output/end/finish
• Future: planning/prediction
• Govern: manage/handle/guide/control
• Hurt: damage/problem/hazard
• Individualize: Customize/User preference
• Joined: Relationships/interaction
• Keep: settle/fix/be
• Location: physical world
• Modify: change/alter
• Negate X: avoidance/nullification/Negation
• Optimize: Balancing/Resources
• Presentation: Present/Format/Arrange/Layout
• Quanta/data: Data/text/numbers/bits/files/documents/measurements/values
• Receive: Get
• Send: Put/publish
• Technology: Integration/Technology/Interfaces/UIs
• Understand: Learning/Understanding/Knowledge building
• View: Vision/Recognition/spotting/finding/searching/detection

• Attention management: email, social media, texting, collaboration, advertising – a system that will manage these based on user attention desires.
• Automated invention: come up with invention ideas using an automated system.
• Capital expenditure allocation: build an application to identify where capital need to be expended, which areas, which technologies, which capabilities are needed.
• Compassion profiling: find where each employee belongs in an organization based on talent, skill, and attitude.
• Complex dynamic line of business transaction management: build information model(s) to cover the various workflows that a business may need to use in the future and use the models to control all workflow in an application.
• Complex inventory flow management: build information model(s) to cover the various states that a piece of inventory could be in.
• Complex page level security management: build an information model and use it on each page, for each data ‘section’, for each user/customer, and for each resource/function.
• Data finder / deep web search engine: build a web search engine based on information models. Select as a niche, sites that cover statistical information, databases, large text files, data files, the deep web etc.
• Extract legacy application value for migration: extract information from a legacy application for use in developing replacement apps. Build information models embedded in the logic of the legacy application.
• Fill holes in a team talent set: identifying gaps in a team’s talent set by identifying each member’s talent, skill, and attitude and using this to prioritize task assignments, and using this to identify what is missing for hiring purposes, and identifying how well each candidate fills those gaps.
• Finding the right talent: build an application for hiring – identify talent through word-level resume analysis, blog analysis, social media analysis, forum postings. Build a dictionary of word to talent translations.
• Global niche economics: project collaboration, attention management, information model collaboration, cloud existence, production, design, distribution, customer involvement, parts and software, micro-finance, attention scoping.
• Glomming database types: database model simplification, type concentration, type centralization, to get the biggest bang for the buck, identify the core complex states.
• HL7 Auto-version: Build an application that can work with any version of HL7 without having to do much application rework.
• Hyper-science: build an application to convert scientific concepts into information form, then use this to do attention management with the scientific community.
• Implicit geometry: a technology to compete with and collaborate with polygons, fuzzy information for content, recognition for interactions, generators for display, models for shaping.
• Individualized marketing documents: generating individually targeted marketing documentation based on 1)customer input, 2)customer search patterns, 3)customer purchasing patterns.
• Internal organization information finder: Characterize each document in an organization using information model(s). Use these to find information, coalesce information, find information gaps.
• Knowledge based CMS: build a CMS system which provides metadata as part of its knowledge base.
• Mergers and acquisitions: what functionality is duplicated and what functionality needs to be or can be extracted for use.
• Simplify AI: Simplify AI heuristics through recognition of fuzzy states.
• Software capability inventory: identifying which software capabilities you already have and which you need.
• User aligned data entry: Build user interfaces that can handle 0nf entries.
• Using the results of data mining: Scrape the results of BI, data mining, and data analytics into an active information models. Then use them to power applications.
• Venture capital allocation: which projects deserve more support and which less.

• Allocation: Balancing/distribution/Balancing/resource allocation
• Building AI: Knowledge representation/AI/Data–>Information–>Ontologies->AI.
• Context/metadata: Metadata/Context/Richer metadata.
• Defined data: characterized data/data context/semantic data/soft coded context.
• Evolving systems: Evolution/Genetic Algorithms/Genetic algorithms.
• Fuzzy information: Anti-aliasing data and information.
• Generators: Creation/Creating new things programmatically.
• Handling 0nf: automation/Conflated information handling (0NF).
• Importance/order: Ordering/Importance management/Prioritization.
• Judgment: Action/decision/function/Decision automation.
• Knowledge/Information: Core information functionality above the level of data.
• Languages: Natural language/sub-natural languages.
• Mutual languages for users/humans/computers, HCI creative partnering.
• Networking: Mutual languages for data networking.
• Overlooked possibilities: Thorough coverage/Overlooked possibility identification.
• Information proxies: Information data equivalent/Proxy creation and analysis.
• Query/search: Filtering/search/matching/Filtering, searching, and matching.
• Recognition: Viewing/recognizing/profiles, signature/pattern recognition.
• State management: Status/State/Situation information, complex state management
• Type assimilation: Kinds/bits/assimilating database complexity.
• Using the results of data mining/information persistence/Information storage.
• Viewing systems: Condensing data/sparse data or information UIs.

Software developers hit a glass ceiling because software development itself has hit a glass ceiling. Software development has failed to figure out how to work with information directly inside a computer program. Instead, we work with data rather than information. We have left the information work to the BI, data analytics, data mining, knowledge representation world. This world works with data after the fact to extract information from it.

What if programmers could work with information inside a program? before the fact. The next level of development could be to work with information as well as data inside a program. The glass ceiling is that we generally can not work with information. An entire new industry development effort needs to get started developing tools and techniques for doing this. I am doing my little bit to break through this glass ceiling at my blog. I also provide libraries for the techniques so far developed. But we need much more than a few techniques that one software developer can create, God willing. We need an industry push to break through the glass ceiling and build the entire information level of software development. Let’s get started!

Here are examples at each level to handle a user-customer relationship:

1. Level 1 – RDB: A join table:
   ——————
   user customers
2. Level 2 – OO: A few classes depending on use and need:
   ——————————————–
   a user table with a customer objects list or a customer id’s list depending
   a customer class
   a user class
   a ‘client’ data structure that contains both objects (references to them)
   a user-customer relationship class
3. Level 3 – IOP: Three endeme sets defining user-customer fields:
   —————————————————–
   a UserIdentity set
   a CustomerIdentity set
   A relationship set
4. Level 4 – KR: Two nodes and a relationship edge:
   ————————————–
   customer node
   user node
   relationship edge

Native Organization Schemes

• Level 1 – RDB – relations
• Level 2 – OO  – hierarchies
• Level 3 – IOP – matching/(or memberships?)
• Level 4 – KR  – graphs

For matching, each piece of data is part of whatever it matches well. For membership, each piece of data is part of multiple things.

The First Three Organization Schemes Are Implemented Through Four Types of Tables:

• data tables   – usually have a large number of rows focused on data
• lookup tables – usually have a smaller amounts of rows focused on data [OO]
• endeme tables – usually have a small number of rows focused on ‘type’ [IOP]
• join tables   – plumbing used to connect data tables to tables in a n to n relationship [RDB]

Given the needs of various part of a project, work with one or more of these for different purposes.

Resulting in These Structures:

• hierarchy – oo is especially good with these [like lookup tables]
• join      – uniquely relational              [join tables]
• search    – generally information oriented   [endeme tables and endeme structures
• data      – everyone works with data to some extent
• graphs    – above the level of database tables?

Then adding two more types of tables:

• Endeme implementation tables – endemes
• Graph implementation tables – knowledge representation

Gellish?

These two new groups of tables implement endeme and knowledge representation structures (information structures) in a database. They generally set somewhat apart within the database in their own little engines.