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.

Software Development is Missing its Third Level

Like the Pirelli Tire building missing its third story, software development missing its third level will hit a development ceiling.

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

Decision Making and Computational Creativity

When I think about where automated/computer decision making exists in this stack, it is in level 6 – computational creativity. You see, level 5 – artificial intelligence analyzes the world around it, and level 6 synthesizes things from its understanding. One of the things that can be synthesized is decisions. Level1&2:data. Level3&4:information. Level5&6:understanding. Level7&8:reproduction.

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 and Disadvantages of Endemes

Endemes are useful for some things and not others.

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.

Semantic Data Layer for Programming

Semantic data semantic layer for software development
could software development become easier if we could build a data semantic layer on top of databases?
what if we could build a data semantic layer on top of logical constructs?
not just reports but a data semantic layer adjusted for the terms that programmers want to see
not just the terms that businesses want to see
this could be an object member semantic layer

Action Verbs to Think Up Level 3 Project Ideas

This list covers action verbs to think about information in order to create new project ideas. Note that ‘negate’ gets used with other action verbs like ‘hurt’; note that these verbs may be combined.

• 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

Projects that Can Do Using Information Early

Some example projects that could be built using Level 3:

• 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.

Examples of information when used inside an application

Here are some examples of capabilities that using information provides for a program when used inside an application:

• 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.

Breaking Through the Glass Ceiling in Software Development

This is in response to a question asked on Fora Is there a “ceiling” in software engineering? Why?

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!

Each Level Has its Own Native Structure

I will start with an example.

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.

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?

                                       ontologies
                                          | | |
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, 192.234.235.245, 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.

 

 

The Third Dimension in Programming

You can think of level 3 as adding a third dimension to programming. The first dimension is database, the second dimension is object orientation. The third dimension is information orientation. As with the analogy, the third dimension allows you to cover much more ‘space’ with less code. 10x10x10 is 1000, whereas 20×20 is only 400.

Adding the third dimension in programming allows generic programming where we would have done ad hoc programming before. This is why having the right tool helps. It allows generic programming rather than ad hoc programming. Ad hoc programming is programming on a case by case basis rather than generic programming which is using a consistent approach. Ad hoc programming uses different structures for the same thing. Generic programming provides the same structure (or perhaps a few generic structures) for the same thing.

This is they key to why adding a third dimension reduces programming cost. It makes some ad hoc things into standardized things.

We Need to Use Tracebacks in Some Kinds of Programs

Trace-backs are highly useful for computational creativity programming. In order to debug and build on something created, you need to know how the system did it.
Are trace-backs useful for information programming too? You see sometimes the business rules result in the user not being allowed to do something or something simply not happening. Telling them why could be useful.

One of the problems with using .NET DataRows the way they are generally used is that you lose some of the context, i.e. you lose some of the trace-back.

EndemeFields (semantically defined data) can include tracebacks as long as the traceback can be properly applied to the field. This would usually be result fields. This is a .NET implementation detail.

Creativity HCI

Human computer communication through creativity: Endemes provide an excellent way to merge user desired characteristics and randomness (aritificial creativity). An endeme is a permuted list of characteristics that can be combined in any way and in any order. If the computer comes up with some of them and the user comes up with some of them, then they merge well.

Happy medium: Endemes are designed to be simple enough for a computer to understand, and abstract enough for a person to understand and to be useful for a person.

Support Creativity: Endemes support creativity of the user.

Exposing an endeme: An endeme can be exposed to the user even if it is fairly technical because endemes deal with information and users think in terms of information.

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.

GUIDs are For Many Uses

GUIDs are for
– information
– networking
– security

Design Endeme Sets to Model Information

How to Design Endeme Sets

Designed to Combine: Each characteristic in an endeme should be designed to combine with any of the others resulting in a large number of possible emergent properties as they combine.

I sometimes takes years: It sometimes takes years to develop a good endeme set. It has to be both compact in its length and perfect in its application and excellent in its ability to combine its elements. By perfect, I mean its combinations cover what it needs to cover and its combinations do not generate bunches of ‘invalid’ results.

You have to start abstracting: Once you have gone beyond 22 items.

To test an endeme set: you can test/develop an endeme set by thinking of something it should describe and seeing if the endeme set can produce an endeme covering it.

What about two endeme sets?: Sometimes you will need more than one endeme set to describe something, but at least one of them has to be really good and essentially capture the essence of the thing being described. Creating two at the same time to work together or to parcel out the domain space does not work well. Focus on one until you have it well done, then go and make another if there is more domain space to cover. For one thing, it’s hard to do functions for situations if you have multiple endeme sets completing a situation.

An Inner Platform is a Good Thing?

In figuring out how to work with information inside a computer program, I am working toward building an inner platform. The thing I have to watch out for is an anti-pattern called the “Inner Platform Effect”. The inner platform effect often starts out with a generic database that gets added to and enhanced until it becomes a replica (usually a poor and incomplete one) of one of the systems that it is built on top of. Most often the kinds of inner platforms built are replications of relational databases and operating systems.

It is possible to build an inner platform that replicates the capabilities and organization of a relational database. It is possible to build an inner platform that replicates the capabilities and organization of an operating system. It is possible to build an inner platform that replicates the capabilities  and organization of an object oriented software development system.

In data oriented software development the inner platform effect is an anti-pattern. The Inner Platform Effect – “The Inner-Platform Effect is a result of designing a system to be so customizable that it ends becoming a poor replica of the platform it was designed with.” This “customization” of this dynamic inner-platform becomes so complicated that only a programmer (and not the end user) is able to modify it.

Three things tend to lead to the creation of an inner platform

• Users want something that they can modify themselves without having to have a programmer involved.
• Programmers want to build something very generic because they do not know what precise needs their user have.
• Programmers may realize deep down that the way forward in software development is to build a level above the level they are currently working. This may be the real reason programmers keep building them and suffering the consequences. Without information structures and theory, you simply can not build an inner platform that has added more capability than a database or object oriented approach. Any or all of these may be in play.
• Programmers look at repetitive field handling code and think to themselves that there must be a way of abstracting it. You see (to oversimplify the situation) each column in a table ends up being a member in a class. A whole bunch of members tend to look the same, get set, changed and erased and displayed the same way, and the thinking is that there really should be a generic abstracted way to handle them.

Avoid the Inner Platform Effect

When you are building an inner platform there are some things you can do to avoid the inner platform effect:

1. Do something the underlying platform cannot do or can do very poorly. This is my goal – to build an inner platform that works with information as well as data.
   Working with information is something that a database or an object oriented programming can barely do if at all. Usually when someone attempts to use one of these technologies for information, they end up with a snarl of excessively complex, nearly unmaintainable code.
   – Endemes provide work-with-able information about the items in the ‘inner platform’. Information about the items is what inner platforms are normally missing.
2. For simple information: avoid objects and attributes in the endeme tables. have only endeme strings, labels and ids
   • have the endeme id’s in the tables (objects) directly
   • the endeme is the value
3. for endemized attributes/data:
   avoid objects in the endeme tables, each endeme for the data is its attribute
   – the endeme is the attribute, the endeme’s value is the data, the label is the name of the attribute
4. for endemeized objects: This would be a generic database and full inner platform.
   I don’t know how to avoid building an inner platform here. I need much more experience working with 1,2,ad 3. above before I can hope to work with endemized
   objects without suffering the inner platform effect. The trick is, that in order to get this experience, I need to build a bunch of inner platforms, have them die their expected gory death due to the inner platform effect, and eventually figure out how to build a true information programming platform that does not suffer this.
   need to use level 4, can not do this properly until level 3 is well understood
   this would build an actual inner platform.
   – endeme lists would avoid the problem of not using the database for some of its excellent features.
   this is because the database would need to support custom indexes, (since information has no order) and functions and triggers to power those indexes, (since the database does these very well)
5. Level 4 programming will be based on an inner platform. We need to build an inner platform for level 4 information programming. This will allow us to use knowledge representation in programming. Note to self: look to see if there are any successful knowledge representation inner platforms out there. OWL comes to mind.
6. AI programming will be based on the knowledge representation programming and is possible once an inner platform is built for level 4 programming. The inner model has a column for id, key/field, and value.

More thoughts on avoiding the inner platform effect

• how do I avoid the inner platform effect?
  • keep the inner platform really sparse in features
  • do a hybrid system
  • have columns for id(must have), field(in only its information format), and value(must have)
    • access by information, not ‘table’ and ‘key’
    • but an endeme list has endemes with labels, access by information, the endeme makes it different
    • have no search attributes, put these in regular table columns
  • don’t let a user modify it, only for programmers
  • build a solid infrastructure to hide the implementation details
  • implement in really slow steps, taking years and learning how to do each step well before moving on to the next one
• how do I use the RDB for what it’s good for?
• the question is what can I do with information?

Building a Successful Inner Platform

The inner platform effect is an intuition by programmers that we need to build a level above the data levels. However without the information oriented programming theory to base it on, inner platforms just generally only implement things that already exist. Thus they usually fail to build a level above data levels.

I want to take the inner platform above both the database, the OS and the object oriented program level. The challenge is to have the inner platform reach out to the rel platform it replaces to use the performance facilities of the real platform below. The inability of an inner platform to do this is the most common downfall for the inner platform.

An inner platform for a database:

• table
• column
• row
• relation
• pk
• value

An inner platform for object orientation/xml/json:

• class
• member
• object
• type
• collection

An inner platform for an operating system:

• path
• folder
• filename
• parent
• child

Generic Data Models

– object     attribute     value

From C2: Definitely not an anti-pattern, and it can often greatly simplify table design for some corner scenarios. Apart from giving rapid prototyping benefits it also helps with handling ‘jagged’ data. Instead of introducing null columns using GenericDataModel enables us to save only relevant data thereby actually decreasing complexity. Reporting and manual labor against the table can be handled via views as mentioned above. not

Entity–attribute–value model

•     The entity: the item being described.
•     The attribute or parameter: typically implemented as a foreign key into a table of attribute definitions. The attribute definitions table might contain the following columns: an attribute ID, attribute name, description, data type, and columns assisting input validation, e.g., maximum string length and regular expression, set of permissible values, etc.
•     The value of the attribute.

From Wikipedia: As noted above, EAV modeling makes sense for categories of data, such as
 – clinical findings, where attributes are numerous and sparse.
Where these conditions do not hold, standard relational modeling (i.e., one column per attribute) is preferable; using EAV does not mean abandoning common sense or principles of good relational design. In clinical record systems, the subschemas dealing with patient demographics and billing are typically modeled conventionally. (While most vendor database schemas are proprietary, VistA, the system used throughout the United States Department of Veterans Affairs (VA) medical system, known as the Veterans Health Administration (VHA),[1] is open-source and its schema is readily inspectable, though it uses a MUMPS database engine rather than a relational database.)

We Need an Inner Platform for Information

We need an inner platform because the db and the language do not provide what we need and we need a platform that will.
the problem is based on members