Rules and Concepts

Simples

A Simple does not have a name; it simply holds just a value, or an object. The associated Part that points to a specific Simple defines its meaning within that particular context. For instance, a Simple containing the word "Stone" may refer to the natural rock material, an imperial weight unit, or a person's surname. In Nest, all are stored as the same object at the Simple level.
When storing data, the Simple should contain the single object intended for storage. During querying, the Simple holds a set of objects along with their individual comparison types that must be met in the query.
Custom type value objects are required to implement IComparable.
After executing a query, the Simple contains the resulting data, which can be retrieved using the method GetMatches(): IEnumerable. All Simples involved in the query gets the same length of result vectors. A given index in each result vectors contains the data of one and the same query hit instance. E.g. one vector contains the films and another the corresponding release years.
Multiple Simples may include permutations of matches if it is unclear which Simple should contain a particular hit.
Circularly connected Parts are permitted. For example, a person's friends may refer back to the person as a friend of theirs.

A part has one or several other parts, or just a single Simple.
A part just has a name as its only attribute.
The user can set the Part as its primary key if it together with its associated Simple fetch a unique parent Part. This increases querying speed.

The property State of a Part can have one of the following ConnectionStates :

Unhandled - the fresh state before any querying or storing.
Owned - in the cases the part has been stored in the current scope.
QueriedNoHit - there were no hits after executing a query.
QueriedUniqueHit - the query yielded one unique hit.
QueriedMultipleHits - the query yielded multiple hits.
QueriedMultipleSameHits - the query yielded multiple hits but all are the same.

The full network of parent-child connections are used in a query - inclusive multiple parents if existing.
By adding a queried structure to another parent - and then stored, the part added will be duplicated.

Unlike querying, storing of a part only stores children to all grand children etc. in direct line(s) of descent even though the structure contains many parents (for example used in a previous query).
If a Part is describing a concept that consists of other sub concepts it is important to store each sub-concept separately before adding them to the higher level concept. E.g. do not store an order (high level concept) with its customer data (one sub-concept), its shipping items (one sub-concept), and store (one sub-concept) in one go. Instead store the customer, its items, and the store separately first in order to pick up and reuse already existing concepts. Then add them all to the order and store that.
Adding an Owned part does not create a duplication of the part when storing.