Creating a Bonding Charge Flow Json schema?

This is ambitious but it would be how to specify all properties of Mathis' charge flow in json?
I'm thinking specifically of charge flow directions and strengths.
If two elements are brought to "bond" how to specify the most granular properties to allow bonding?

If this could be done, we could then drop it into a "MongoDB" json friendly database and then use Apache Drill to query the details.
Ideally, each element could present "bonding" properties with other elements according to charge flow strength and charge flow direction.
Capturing specific configurations due to "pressures" is the goal. With this in place a "conversion" tool could be built for regular Molecule syntax and Miles' charge field syntax (https://en.wikipedia.org/wiki/Chemical_file_format#SMILES). I'm just thinking a json friendly database could a solution like MongoDB.

This should be calculated from our existing element data. I propose that we define a schema that allows easy SQL queries to determine bonding potential. I can then work on calculating data from the element definitions to populate it and you can use it however you want to by adding data in manually. Eventually, the 2 should meet in the middle and I may be able to use your manually entered data as a test against my calculated data.

In order to get more familiar with these non-relational databases, I have made a quick attempt to convert our element JSON definitions into a more database friendly structure. It seemed to me that the SQL was going to be a bit complex but I don't see how to reduce that complexity while also making a structure that does not define the same data over and over again.

For an example of data redundancy, our current JSON definitions specify a complete element within 1 object. This is exactly what you want in your Javascript code. However, a lot of that data is duplicated among elements and even within a single element. Take a Neon atom which has 5 proton stacks containing 2 protons and 2 neutrons each. That is 5 instances of the same thing and each is defined explicitly. That is not how you want to store your data because it is a waste of space.

So I defined a schema with 2 'tables' (for want of a better word): ProtonStack and Element. The ProtonStack table stores the data for all stacks so it would contain a series of { protons=2, neutrons=2, electrons=2, attach1=..., attach2=... } type entities. So this table stores every possible proton stack that could be used in an element structure. The Element table stores the actual element definitions which are a collection of properties, such as name, symbol, atomicNumber, etc, and a collection of links to the ProtonStack table for each level (core, pillars, caps, carousel, hooks).

The main problem I had with it was that each level of an element, actually each position within a level (north, south, etc), requires a join to the ProtonStack table and there are potentially 15 of them in a single element. This could probably be abstracted by creating a View of these tables that presents the data as we currently define it (which I would need anyway in order to use the database as my source of element data in AV, etc). I am finding it difficult to find the sweet spot between reduced data redundancy and simple(ish) SQL.

Even that schema contains redundant data because a lot of elements build on the noble structures. I could add a link in the Element table that points to another element in the Element table as the base of this element. This would allow an atom like Calcium to specify Neon as its base and then Calcium just declares the proton stacks that are not a part of Neon. I like this for reduced storage and ease of building elements but it does have its own problems. For instance, when you start to deal with isotopes you often need to vary the number of neutrons in the core stacks so this type of model would need a lot of isotopes of any element that was used as a base. Not insurmountable, just a complexity that needs to be acknowledged. The main problem I have with this approach is that it does not lend itself well to SQL queries. It is fairly easy to deal with in an application, where it would be put into a single coherent structure, but complicates SQL that operates directly on the data. Again, a View may be able to help in this regard.

So this would create 2 databases: ElementDB and BondingDB. ElementDB is used to create BondingDB which I would then use to create MolecularDB. This database would store molecules in a reduced structure. That is, is does not store the complete element definitions but refers to them in some way. I'm not sure exactly how that will work at this stage as the elements may need to change in some way when they are part of a molecule and I am sure there will be other fine details that make it difficult.

Are these 3 separate databases? They certainly could be put together into 1 and operate happily. While the BondingDB could be used as a separate database, I think the MolecularDB could benefit from linking back to the Element table in ElementDB. It also may be beneficial to store references to the BondingDB tables that were used to determine that bond. So maybe they should be thought of as a stack of databases. ElementDB is self-contained, BondingDB sits on top of that and MolecularDB sits on top of BondingDB.

So how would we go about defining the BondingDB schema? There are 6 possible bonding locations: north, south, east, west, front and back. Each bonding location has 2 charge strengths associated with it which is basically a generalisation of the number of proton stacks in between that bonding location and the core of the element. The first value is the charge emission from that location and the other is the maximum charge intake for it. These are closely related and we may be able to generalise them into a single value. There is also the through-charge value that plays a part in bonding as well. This is used to exclude a bond. The charge emission/intake is used first to determine if a bond is possible and then the though-charge is checked to make sure that each element can handle the amount coming from/going to the other.

As a rough guide, here is the start of a BOND table in a more traditional Table and Column format:

BOND
{
  ID: positive integer (ahh, another database system without sequences, I'll have to develop one)
  ELEMENT_ID: link to ElementDB.Element.ID
  LOCATION: 'N', 'S', 'E', 'W', 'F' or 'B' (this would be a lookup table in a traditional DB)
  CHARGE_EMISSION: N
  CHARGE_INTAKE: N
  CHARGE_THROUGH: N
}

That is my current thoughts on it. They may change over time but I think it is a decent start. Would that work with your own ideas, Cr6?

Those are good thoughts Nevyn - especially the BondingDB and Molecule DB. It looks easier to maintain and keep consistent for updates.

Thanks for the input.

I was looking at these Force Field projects for a good starting sample (GROMACS) to leverage traditional chemistry object libraries for rapid converting.  

https://en.wikipedia.org/wiki/Force_field_%28chemistry%29

Indeed, the SQL-data side might need highly denormalized tables for each Slot-level-position along with applicable inline functions for the various iterative processes. Often times with SQL-tables, especially sparse tables, one can statically create nearly all possible renditions of somethings like the 9-core structure of an Neon base-atom then up to the 19 slots via NULL or missing placeholders.

UFF, a Full Periodic Table Force Field for Molecular Mechanics and Molecular Dynamics Simulations
http://www.wag.caltech.edu/publications/sup/pdf/275.pdf

Okay, I've been able to load the Cr6 json into MongoDB. I'm using RoboMongo as the GUI.

" />

Came across this recently.  X3D is a JSON library for 3-D notation. Looks like a work in progress but still another library for rendering interactive 3-D objects.

One of these could fit in a fast  No-SQL database pretty easily. Mathis' style objects could be just a long string of JSON.

http://www.x3dom.org/examples/
http://www.web3d.org/x3d/content/examples/X3dResources.html
https://savage.nps.edu/X3D-Edit/
http://examples.x3dom.org/editor/component_editor/

http://www.web3d.org/x3d/why-use-x3d

Also these NIST DLMF Math libraries look pretty cool though apparently still in beta:

http://dlmf.nist.gov/
http://dlmf.nist.gov/help/vrml/#S2


Why Use X3D

Extensible (X3D) Graphics logoMany reasons make X3D Graphics a great choice for publishing your Web content.

Free and open

   Open source and commercial tools are both widely available
   Many free resources, and all results are royalty free - authors own their models!
   Numerous resources, examples, tooltips, tools, and documentation sources
   International standard that lasts for years and decades

Modern graphics, animation and interaction

   3D geometry can be bundled directly with animation and user interaction
   Scenes can run on many platforms, from mobile platforms to caves
   Scenes also run on any operating systems, accessible to any programming language
   Addresses all needs for display of Geospatial 3D graphics
   Provide interactive and immersive 3D experience to build highly detailed synthetic spaces
   Efficient compressed binary encodings provide smaller file sizes with high performance

Web Interoperability

   Excellent compatibility with HTML5 and other Web Standards including XML Security
   X3D 4.0: Complete HTML5 Integration (X3DOM - see flyer below)
   Models have archival stability that stand the test of time
   Supports Virtual Reality Modeling Language (VRML97 and ClassicVRML) encodings.
   XML-based .x3d encoding has numerous validation and quality assurance (QA) tests
   Interoperable with other standards, also between applications and platforms