that dramatically simplifies application development methods, allowing major, high performance, secure, internet enabled applications to be created -

• incrementally - you can ‘grow-as-you-go’,
• without an upfront detailed specification,
• without physical file design,
• and mostly without any program change or recompilation.

Development is done using a standard browser over the Internet. As the ERROS graphical Standard Operating Interface (SOI) generates HTML and JavaScript on the fly, at run time, the applications created work immediately over the Internet. There is no stored HTML. No Content Management System is required.

All ERROS data and application definitions are stored in the unique ERROS Ontology rather than in program code. The ERROS Ontology is part of the patented NoSQL ERROS Connectionist Database (CDb). The ERROS CDb is defined in the integrated ERROS Ontology which is part of the CDb. In other words,

the ERROS Connectionist Database (CDb) is defined by itself.

The CDb also stores all the user data that has been defined in the Ontology.

It is obvious that, when human beings learn a new concept, their brains are not shut down, redesigned, reprogrammed, tested and restarted – clearly, they learn on the fly, although the mechanism for this may not be understood. This simple insight suggested that, if the database structure and much of the program logic were defined in the database, rather than in program code, then updating the database would allow applications to be changed on the fly and enable genuinely incremental development without the need to shut down the application. This was the inspiration for the CDb. As a result,

ERROS enables advanced, rapid, incremental Application Development without Software Development.

Application development and maintenance is achieved by updating the Ontology using SOI and the ERROS Database Handler (DbH). Developers use the natural language terminology of their business or institution and no programming or special syntax is required. The DbH interprets the stored definitions at very high speed and passes them and the user data that they define to SOI for display or printing or generating XML. ERROS incremental application development is dramatically more productive than other development methods. In addition, ERROS Application Development is largely self documenting. Users can get what they want when they want it and maintenance backlogs are eliminated.

The CDb was designed to be able to handle billions of records with very rapid response times that do not noticeably deteriorate as data volumes grow.

All ERROS applications can handle Big Data..

ERROS is not a 4GL and does not generate any program code apart from HTML and JavaScript for SOI, as stated above. There are no compiled ERROS applications and the concept of compiled, inflexible applications has gone. Major collaborative applications can be created without any program changes.

ERROS is an innovative, productive, simple to use alternative to the iteratively developed, rigid applications defined in program code. ERROS is a complete development and operational environment that includes its own, unique, ERROS Connectionist Database (CDb) and its own graphical user interface (SOI).

ERROS was developed to allow the incremental creation of robust, scalable, enterprise level, multi-user applications that are equally suitable for commerce and the humanities.

With traditional application development methods, data are put in tables and the rules that govern that data are coded in programs. These separatist worlds of data and programs have to be kept in synchronisation, at best a fragile process. ERROS is the first computer environment in which the database definitions, the application definitions and the user data are totally integrated, stored in the unique ERROS Connectionist database (CDb). This might be compared to the structure of the DNA string in which both sides are related but independent and are interconnected to form one integrated whole.

Vital Features of ERROS

Because the innovative ERROS CDb is unique, the description below of the main features of ERROS may introduce concepts with which you are not familiar and which therefore may seem complex. In practice, they are very simple and only four main programs are required to provide all the features of ERROS described below.

The ERROS Connectionist Database

The name is based on the ability of the ERROS Connectionist Database to associate or relate any data through myriad connections, in which capability it apparently has some similarity to the brain. These connections can be temporal – date and time dependent.

All metadata and user data are stored in the ERROS Universal Data Structure in the ERROS CDb. This is a semantic network that allows immediate navigation of bi-directional connections in either direction at the same very high speed without using joins. Without using a query language, users can browse through the database, traversing links and crossing entity type boundaries, as their security allows. They can retrace their steps and take a different route through the connnections, finding data of which they were unaware.

ERROS is equally suitable for applications that require rigid control of data entry, such as transaction processing (OLTP).

ERROS runs under the IBM i operating system on the IBM Power Systems platform which also suppports AIX, Unix and Windows. Probably the most secure and robust server available today, IBM i has single level storage, an integrated storage management system and its own integrated DB/2 database. The ERROS CDb sits on top of DB/2 but does not use any of its relational features. Developers of ERROS applications do not have to be involved with memory management. All ERROS applications are automatically persistent. The ERROS SOI supports browsers, PCL 5 printers and IBM 5250 terminals.

The Self-defining ERROS Ontology

All data and application definitions (the metadata) are stored in the ERROS Ontology. Data is defined in terms of entity types, attributes and connections (relationships). Only two entity types are required for this - "Entity Type" and "Attribute". These are both defined in the entity type "Entity Type". All attributes, such as "name", are defined once in the entity type "Attribute". When an entity type is created that needs the attribute "name", it is connected to the attribute "name" stored in the entity type "Attribute" and it automatically inherits the properties of the attribute "name", such as the data type. Any of these properties can be overridden. There might be hundreds or even thousands of entity types with the attribute "name" in a major application. The same method is used for all attributes for all entity types. Each entity type has a list of all its attributes. Clicking on an attribute in such a list will show all entity types that have that attribute. Clicking on one of the entity types will provide access to a list of all the attributes for that entity type. No query language is required.

The ERROS Ontology also stores the definitions of valid connections.

Users can also create their own ontologies, on any subject or domain.

Database Design

No upfront physical database design is required nor is it possible. Although developers are unaware of its existence, it is the ERROS DbH that determines where data is to be stored. The ERROS CDb structure ensures that all data is stored in the very efficient ERROS Universal Data Model, suitable for any type of application or any type of query. There is no need to normalise data, as with Relational Databases, and there is no concept of Primary or Foreign keys. Neither developers nor users know the location of data. Performance is consistly very fast for all applications, even with very large data volumes.

Entity Types

Entities can belong to multiple entity types, thus eliminating redundant data. Entities inherit the attribute definitions of the entity type in which they are being viewed. Data in all ERROS applications is automatically integrated. No new files or folders are created when new entity types are defined.

Attributes

Each entity type can have an enormous number of separately defined attributes. Whereas, in document databases, these definitions are stored at the entity level in every entity for every attribute that has data, in the ERROS CDb these are defined just once, at the entity type level, ensuring consistency across all entities, much reducing data entry time, saving space and improving performance. Every attribute iteration is stored as a separate record. The absence of any records in an attribute means that there is no data in that attribute for the selected entity. Null values are not required, with considerable further performance benefits and reduced storage requirements. Attributes can have multiple fields.

New attributes can be added to any entity type at any time, whilst the CDb is in use. Attributes can store links to connected records in the CDb. Attributes can be repeating, allowing almost limitless, many-to-many connections. Attributes can store unlimited text. Attributes can store URLs for accessing digital media, including Google maps, and the files retrieved are automatically integrated by SOI in the ERROS application web pages. Attributes can also store URLs for links to other web sites.

ERROS Applications

ERROS Applications are filters that provide access to parts of the user data and control security.

"ERROS Application" is also an entity type defined in the ERROS Ontology. It has the attribute "name" and many others.

ERROS applications are given a name, and this is connected to the entity types required in the application. Each entity type is connected to those attributes defined for the entity type that are needed in the application. These connections are stored in ERROS application menus. Menus can be nested.

When a new attribute is added to an entity type, applications that provide access to that entity type are not affected unless the new attribute is added to a menu for the entity type in the application. Without using a query, developers can see which entity types are available, subject to security, in each application and they can also see the applications in which any entity type is available.

Connections

All ERROS connections are bi-directional - for instance, Joe Smith's employer is the ABC Company and the ABC Company's employees include Joe Smith.

This ERROS Semantic Network Diagram ilustrates how the connection between a business and its employees is defined in the ERROS Ontology.

The entity type "Business" has an attribute "employee(s)". This is a connection with the entity type "Individual". This has an attribute "employer(s)" which is a connection with the entity type "Business". The attributes "employee(s)" and "employer(s)" are the inverse of each other. It is this structure that enables bi-directional navigation of connections. Connections are always bi-directional. One side of a connection cannot exist without the other. It only takes four simple steps to create a connection definition in ERROS.

Graph databases do not support bi-directional relationships. Two uni-directional connections have to be created separately, taking unnecessary time. If one of these is deleted, the other will remain.

When a user wishes to create a connection, ERROS will only allow him or her to select a record in the related entity type - validity checking is automatic and cannot be overridden. Connections can be with other connections. Navigating all connections in either direction always takes the same constant, almost zero second time, irrespective of the type of entity or the size of the database.

In most ERROS applications, many attributes will be connections - for instance, "Addresses" will be an entity type, storing all addresses. These will be related to attributes of customers, etc., such as "postal address", "delivery address" and "billing address". To learn who is at an address, users can access the entity type "Addresses", enter a post or zip code or an address, and ERROS will immediately display the people and/or companies at that address in alphabetic sequence, without the need to search the whole customer table. Clicking on a name at an address will result in a display of data relating to that person or company, such as type of business, telephone number, website URL, etc. If you double click on an email address, ERROS will automatically start up your email application to allow you to send an email to that address. If you double click on a telephone number, ERROS will immediately start your VOIP application and call the number.

Attributes such as "job function", "business type", "images" etc., would all be connections to entity types with similar names. If you wish to find the contact details for all businesses that are car manufacturers, select that term from the entity type "business type" and ERROS will show a list of all the car manufacturers recorded in your ERROS CDb. This can be done by typing -

.Type of business/car manufacturer/names include

(the full stop or period at the beginning will cause SOI to instruct the DbH to look for the entity type "type of business" in the application's indexed "Fast Path" menu containing all entity type names)

Key-value Database

All metadata and user data records are automatically indexed using the unique, patented ERROS 17-part binary key field so that the CDb is also a key-value database, allowing direct access to any attribute value without any searching.

An ERROS algorithm, also part of the ERROS patent, compresses names of entity types, attributes, applications, contacts, products, titles, etc. up to 64 characters long, in two stages, to just four bytes whilst retaining alphabetic sequence. Spaces are allowed between words of all names, including those in the metadata - "Customer name" can be used rather than "Customer_name" or "CustomerName". Upper and lower case letters can be used as appropriate. There is no requirement to use only uppercase letters for the names of connections as in graph databases such as Neo4j. Long names, of infinite length, can be associated with short names.

The parts of the keyfield can be considered in two groups. The CBd is a contextual database and all data is stored in its context. The first group includes entity type, entity and attribute which together comprise the context of the data that is stored in attribute iterations - for instance

Customer, ABC Company, employees (all compressed)

might be the first group.

The second group includes the compressed identifier of the attribute iteration(s) such as

Smith,Joe (in compressed form).

This means that all employees of the ABC Company will be stored together, sequenced as last name(s), first name(s). They can be displayed as first name(s), last name(s).

Indices

All attribute iterations are indexed so that they are stored and can be retrieved in name, or number, or date, or date and time sequence without using a query language. They can be dual indexed so that, for instance, employees can be accessed and displayed in name or employee number sequence without any search or sorting of records being required. All records are accessed by key. No pointers or direct addresses are used.

Surrogates

When any record is created (apart from text records without headsrs), whether meta data or user data, an additional surrogate record is created with a unique record identifier. This value, which is not visible to users, cannot be changed. Data can be stored about any connection or hierarchy in a surrogate record and accessed automatically from either side of a connection without needing to navigate to it. The surrogate record has its own datatype.

Lower level data, including connections. can be added.

Multiple Identifiers

Synonyms allow records to be accessed with multiple identifiers.

Multidimensional Data

The CDb supports very complex multidimensional data structures, including massive, nested levels of hierarchy. "Children" can have multiple "parents" which can be of different entity types. The CDb handles sets, groups, classes, sub-classes, assemblies, sub-assemblies, glossaries, thesauri, taxonomies and ontologies.

Triggers

ERROS has an inbuilt, high performance, trigger mechanism that avoids the need for separate trigger programs.

Text in ERROS

Any attribute in any entity type can be defined as a text attribute. There is no limit to the amount of text.

ERROS has its own text markup language - the ERROS Output Description Language (ODL). ERROS text is not intended as a substitute for word processing packages such as Word.

ERROS text can be stored as paragraphs, with paragraph header records and associated text. The header records are indexed. Changing the sequence of paragraph header records will change the sequence of the text. This can be displayed without the header records.

ERROS Exit Programs

ERROS "exit" programs can be created to access data on other systems and pass the data to ERROS for display with the SOI. Exit programs can import or export data from or to other systems. They can also be used for creating special mathematical routines.

Very few exit programs are generally required, even for large collaborative applications. Users can have their own versions of exit programs.

Exit programs are called dynamically and, when a new one is created, the main ERROS programs do not need recompiling.

Multiple Data Views

There can be multiple views of data to suit different needs. SOI can concatenate the data stored in multiple selected attributes from multiple selected entities, including data from related entity types so that they are displayed as rows in a table. The attributes selected and the sequence in which they are retrieved can be varied for alternative views and in different applications. When displaying multiple attribute iterations together, attribute names can be supressed from the display or printed report.

John Doe, 23 Acacia Avenue, London

is much easier to read than, say,

First_name: "John", last_name: "Doe", street: "23 Acacia Avenue", city: "London"

ERROS Collaborative Applications

ERROS applications can be collaborative, used by operators from many companies. The ERROS Connectionist Database allows "public" data to be available to all users with adequate authority and "private" data which is only accessible by operators of the company owning that data. SOI allows public and private data to be displayed together as though they are part of the same record.

There can be "private" ontologies.

Each company or institution using an ERROS collaborative application can have their own web portal into the appplication, with their own home page, banner, logo, etc.

Default Menus

ERROS application menu records, stored in the CDb, determine which entity types are accessible in each application, which attributes are available for each entity type in that application and the action(s) that can be undertaken for each attribute in each entity type. Nested menus allow complex procedures to be defined in the database. Menus also define boundaries for transaction processing, and enable constraint processing and ensure referential integrity.

Menus define the views of the data, including the contents of rows. They allow the concatenation of multiple attribute values from multiple entity types, including images, to be displayed together in the same row.

All menu records are indexed, just like all user data attribute iterations. If you wish to know John Doe's address, you can type

.person/doe john/address

and, even if the entity type person has very many attributes, as the CDb is a key-value database, ERROS will only access the menu record for address. In Graph Databases, all edges for a node (roughly equivalent to attributes in an ERROS menu) have to be read and scanned for "address" which adversely affects performance.

Access to the data in any node in the CDb is always through a menu record. This means that, for every attribute or cell for an entity type in every application, there is a menu record that controls the way that it is processed and presented. The menu records control the action to be taken when there is only one attribute iteration or when one has been selected, e.g. update, or navigate to the next link in the network. This provides extraordinary flexibility and different menus can be used for the same attribute in different parts of the same application or in other applications. Default values are normally used in menu records so that creating them is very simple most of the time.

There can be both public and private user menus within an application. ERROS applications can be set up to look for a user version of a menu, but, if not found, to access the public version. This facility allows complex collaborative applications to be created, and, using user menus, modifications can be made for a particular ERROS user company without the need to change the original package. Menus can be nested, with an unlimited number of levels.

Procedures

A user could type a request to retrieve John Doe's address as shown above. However, stored procedure menus can be created that would automatically display the most commonly required data about any entity type, such as person. If this contained, say, name, email address, telephone number(s), postal address, employer's name and employer's telephone number, then typing just

.person/doe john/

would be all that is required to extract this basic data about John Doe. Typing

.person/doe john !and smith sue

would result in the data about both John Doe and Sue Smith being retrieved. Further data about either John or Sue can be found by clicking on the record required. Somewhat surprsingly, in Graph databases, you cannot click on the relevant node, you have to re-enter the name.

Procedure menus, with backtracking, stored in the CDb, can control how ERROS accesses data in other parts of the CDb.

Procedure menus are also used to define the records to be accessed, added, changed, etc. in transaction processing.

Functional Menus

As explained earlier, when a data record has been read, ERROS will always look for a default menu record that relates to the context of the data record. However, there can also be functional menus – menus that are selected depending on the function just applied to a data record. Thus, if a new record is added, it is possible to define that ERROS must subsequently access an "add" menu so that, for instance, when adding an order line on a sales order, an ERROS procedure, defined in the "add" menu although invisible to the operator, can update the order header, allocate stock, etc., as part of a transaction. Commitment control boundaries are set in the menu records.

There can also be “change”, “delete” and other menus. An “inquiry” menu can be used to control the types of query that can be made, etc. A "print" menu can define the layout of printed reports. These functional menus can be used to undertake tasks that in a traditional system might be done by trigger programs whereas in ERROS there are no trigger programs and no new programming is generally required. If a functional menu has not been defined, a default menu will be used.

Node Control

As stated earlier, access to the data in a node is always via a menu record. Menu records define the type of data in the node, the security level required by an operator to read, create, update, delete (in ERROS records can be tagged as deleted but remain in the CDb, although hidden), remove, etc., whether a special "exit" program is to be called to proccess the data in the node, how attribute iterations are to be indexed (e.g. by name, number, date etc.), how any records in the node are to be processed or the action to be taken if there is no data in the attribute (e.g. back track or add a record), how the data in the node is to be presented, and the action to be taken if the operator clicks on a record in the node (e.g. if the data is a connection, navigate to the connected record).

Security can be set for each node.

Most of the time, default values are used.

The ability to control processing in each node without requiring any programming is an extremely powerful feature that is only availabble in ERROS.

The ERROS Audit Trail

The ERROS audit trail records all metadata and user data changes for every attribute iteration and includes a timestamp, a transaction number and the identity of the operator that made the change. All changes are journalled (logged) and changes to both metadata and user data can be rolled back by a security officer.

High Availabillity

An ERROS high availability option allows multiple local or remote duplicate servers anywhere in the world to maintain up-to-date copies of all metadata and user data.

High Performance

All ERROS applications are persistent, totally scalable and have very rapid response times, even with massive data volumes. They can handle concurrency, relational integrity, and transaction processing and are equally suitable for commerce and the humanities.

Demonstrations of both Document (MongoDB) and Graph (Neo4j databases suggest that these are much slower than ERROS, even when they are being operated by a single user and there are very few records in their databases.

ERROS High Security

ERROS applications have extremely high security. This is defined in the CDb and can be at the attribute level. It is in addition to the security provided by DB/2.

Higher level security can be set on any metadata or user data record for access, update, delete (i.e. tag as deleted and hide.), or remove. There are five levels of security in the Cb2. If higher level security is set for, say, read on a metadata or user data record, then that record will only be accessible by users with a higher level of security. For others, it will just disapear.

All changes to security are recorded in the audit trail.

The CDb metadata and use data can be encrypted.

As already stated, the ERROS CDb is a NoSQL database. Because its 17 part keyfield is binary, and defined in DB/2 as a single field, SQL and standard utilities cannot access the CDb and therefore cannot perform unauthorised updates to the CDb, providing further security. The CDb can only be updated in the secure environment of an ERROS application.

For further details, click here.

Rapid Development

ERROS is a totally new approach to developing major computing systems and allows development with a speed and ease that is beyond the wildest dreams of many experienced system developers. It is very suitable for creating application packages. These can easily be modified to suit any user without changing the main package.

Object-oriented

The ERROS NoSQL database uses OO based artificial intelligence techniques and is totally object-oriented but developers do not need to understand the meaning of this. No object-oriented software is required. The ERROS Connectionist Database (CDb) is unique. There is no other. It is also a wide column store database. It is not a document or graph database.

Simplicity

A large number of the advanced features of the ERROS CDb are outlined above and these may seem complex. However, as stated earlier, only four main ERROS programs are used to achieve all of these and together these total under 75,000 lines of source code. One of the four is a default exit program, and for many complex applications, this will be the only one required, even for collaborative applications. By most standards, 75,000 lines is very small, yet they are all that are required to provide the ERROS Database Handler, the ERROS Connectionist Database, the ERROS Ontology, the development environment for creating applications, the operational environment and the ERROS Graphical Interface. ERROS can also create large typeset printed documents with data extracted from the ERROS CDb.

Proof of Concept

ERROS and its CDb were developed as a means of building a very complex collaborative incremental application creation system that could then be used as a means of incrementally developing the ERROS application STIPPLE - System for Tabulating and Indexing People, their Possessions, Life and Everything.

STIPPLE is a unique and most powerful research tool for the fine and applied arts and for the humanities. It is an advanced system for cataloguing collections and archives of any size and for recording history. STIPPLE combines any number of collections of diverse object types from multiple institutions, in one central system, creating integrated catalogues raisonné and union catalogues. Thus fine and applied art history is integrated with economic, social, political, military, family and local history, and with archaeology, geology etc. STIPPLE can handle enormous volumes of data and images, accessed and updated by large numbers of concurrent users, with very rapid response times.

STIPPLE integrates the data from all disciplines. It can also be used to compare multiple images from many sources, even when they are stored on diverse servers.

The default exit program was the only one required for STIPPLE. STIPPLE is a well tested, valid proof of the concepts of ERROS.

Visualisation

Developers have always liked a visual representation of the structure and flow of data in a computer application. A lot of thought and work has gone into providing this and, in recent years, Graph Databases have been developed as a means of combining visual representation with database development. But, in really complex applications with large numbers of entity types, with some of these having perhaps hundreds of attributes, the majority of which are many-to-many connections, it isn't obvious how a Graph Database would cope, even though they have impressive ways of moving visually through the database structure. The biggest problem is that they are trying to present complex multidimensional structures in two dimensional form, and for large databases this cannot work. In addition, a graph would have to show that some entities belong to multiple entity types which may have different attributes and also that there can be "public" and "private" versions of attributes.

The remarkable human brain copes pretty well without any image of the structure of its data. In addition, it never occurs to most people that we don't have such an image. Clearly, we don't need it.

Since we cannot visualise very complex data structures, ERROS allows each node to be defined and tested separately. The ERROS Ontolgy provides a controlled vocabulary and all the definitions are automatically integrated. The result can be a massive structure that is far too complex to be considered as a whole at an instant of time - as in the real world.

ERROS Semantic Network Diagrams can be used to provide a representation of a single connection, but STIPPLE was developed without them (it would require thousands!).

When defining connections in ERROS, developers only have to consider the name of the related or connected entity type and the name of the attribute for that entity type that will store the inverse relationship.

ERROS Graphical Standard Operator Interface (SOI)

ERROS provides a standard user interface, suitable for intense all day users and irregular casual users, for all application development and for operating all the applications created, including line of business, transaction processing, etc. This is the ERROS Graphical Standard Operator Interface (SOI).

Considerable thought and experience has gone into the design and evolution of SOI. This is the most productive and intuitive interface that we have been able to create. Having a standard interface ensures total consistency in the look and method of operation of all applications, ensuring high productivity from operators. SOI also relieves developers of the burdensome task of creating their own interface so that they deliver new and changed solutions to their users much more quickly and cheaply than would otherwise be the case. No command line is generally used.

The interfaces seen for Document and Graph Databases require many more keystrokes, and cannot be described as intuitive. The Cypher query language used for Neo4J is quite complex for casual users and, because you cannot click on any node visible on the screen, other than to move the graph, you are continually re-entering the same data.

ERROS does not use cookies.

Paradigm Shift

ERROS is a total paradigm shift in modern application development methods so cannot easily be compared with traditional development methods. The concepts of ERROS have been patented.

Total Cost of Ownership

The total cost of ownership of ERROS applications, for development, maintenance and operation, is much reduced compared with traditional methods based on software development and relational databases.

ERROS in Operation

These videos demonstrate building a simple ERROS applicaton, then testing it and extending it whilst it is live.

• Extending the ERROS Business Model
• Creating the ERROS Application and authorising it
• Testiing the application and extending it whilst it is live