Please have a look at the exciting things we are doing with our new approach to data.
Why is data frozen, locked into tables with classes defined for every object? In Integrator, you don't define classes; labels define data objects, and the contents of the labels are stored as data in the same structure. When label names = metadata, and metadata is treated just like data, you can find it, change it, augment it and use it to retrieve its data.
With Integrator you interact directly with the data, without using middleware, so your development process is fast, flexible, and accurate. Integrator's GUI displays all aspects of the project on one screen: the structure of the database, metadata, data, and algorithms. Links between data and algorithms show as arrows. You can modify or add new objects, extending the reach of the database, without programming. Programmers can alter algorithms and see the results on screen immediately.
Software code is a series of lines in a file, so Integrator treats each line of code as a data object. It parses the code and assigns the operator type to each line and respects all the branches. The stored code is converted to a Drakon flow chart, displaying all links and dependencies. At runtime, an algorithm retrieves the lines of code and assembles an executable. CodeView (Basic) shows how we make this work as a plug-in for an IDE.
Integrator excels in merging existing databases; Database Reverse converts any existing database in its unique data schema, and then imports the data to populate the structure. One can join or unify data from a second or third database. Look at the Clinvar gene database.
We did more with data in the Blockmaker application for Minecraft. Blockmaker shows how efficient Integrator is; producing this app should have required buying Minecraft instruction manuals and months of coding and testing. With Integrator, it took a few weeks, including the time to tweak the appearance of the app.
How does this work? The data structure becomes a recursive, extensible hierarchy. Sibling objects share labels; child objects also share labels, but each stays with its parent. The structure is relational, without foreign keys. Every datum appears once, as a single data value, so the structure is always fully normalized. The form is a directed acyclic graph, where any given node may have multiple children and/or parents. A company has employees, which are also persons, so an employee node points to the person node with the person data.
Changes made to objects propagate to all instances of the object, without compiling, so you just keep working. Each datum, including labels, is stored only once and appears where needed by links to this value; change the data labels as you like, to natural or other languages, without programming; change them wherever they appear and the algorithm changes the stored value. Want to link lists of labels for an ontology? Import them automatically, and any previous links are preserved. Want to guide use of an ontology? Lists of child and parent names come up automatically, based on your specifications. Want to change the appearance of your GUI? Display parameters such as hide/show, color, font, position are also stored as data, in the Properties on every object. Display becomes dynamic: every display parameter can be computed, with a place for the code right on the parameter object.
Since an algorithm generates the GUI from the Data Model directly, it works on any screen or in the browser; the correct parameters for output are stored as data - yes, this is a theme. The Clinvar database we show here is running in a browser, but the data is stored in JSON format on the Cloud. It took an hour to set up, and no one wrote HTML. You can see the process on the video below.
Integrator works. The program is still in the alpha stage. It requires additional development to implement additional functions, and improve the look and feel of the GUI. We welcome investment and collaboration to complete the software and introduce it to the world.