short pitch for the Concept Graph app

The Concept Graph and the Grapevine are proposed solutions to the problems of data representation and curation, respectively, for the decentralized web. This essay provides an overview of the Concept Graph as a standalone app, without making any reference or appeal to the Grapevine or decentralization. It is tailored to an audience familiar with object oriented programming as well as graph databases such as neo4j.

Questions

1. Does an app like the one described below already exist?

2. If so, what is it? (Tell me because I want to use it!!)

3. If not, would you like to see one built?

4. If yes to seeing one built, thoughts on the best way to build it? (open source, proprietary?)

I welcome feedback, input and ideas!

Abstract

Data is broken down into files, as granular as possible, with each file represented as a node in a graph. Graph structure is provided by specially defined paths called class threads which allow organization of data into concepts. Three methods are proposed for connections between concepts. Two methods of integration are achieved using class threads, one of which is reminiscent of class inheritance in OOP. Horizontal integration is achieved in a manner that does not have a clear counterpart in OOP. (Is this a fair statement?) The resulting concept graph facilitates the visualization, appreciation and manipulation of relationships between concepts.

Graph database structure

Nodes are files of any type. Structure to the graph is imposed using a directed path called a class thread (Fig 1). Its purpose is to connect a specific instance of a thing to the abstract idea of the Thing. Three edge types will be employed in the path definition: class thread initiation (green arrow, required); propagation (grey arrows, optional); and termination (black arrow, required).

The simplest class thread consists of only two edges, an initiation followed by a termination:

Fig 1: Nodes represent any chunk of data, regardless of physical form (e.g. computer file, piece of paper, patch of neurons) or format (often objects but can be anything).

Propagation edges allow incorporation of subset nodes into the thread. There can be any number of propagation edges, with one depicted below in Fig 2:

Fig 2: Any number of subset nodes may be added to class threads, distal to the superset node and proximal to the class instance.

Various node types are seen to arise naturally, including the class origin, superset, subset, and instance node types, but these are not strictly speaking part of the definition of a class thread, which is defined in full by its three edge types. Class threads can be detected using straightforward path search algorithms (as cypher queries for neo4j).

The union of all class threads emanating from a single origin (green circle) defines a concept. Behold, the abstract concept of a Dog:

Fig 3: The concept of a Dog.

Constraint nodes (purple square, Fig 4) are nodes whose files contain formatting information. They can be directly connected (purple arrow) to a class thread at any node except for the class instance. Most commonly there will be one connected to the class origin, as in Fig 4:

Fig 4: constraint: a node that asserts structure to the class instance via a full or partial description of its format.

If a class thread contains one or more associated constraint nodes, the instance at the end of that thread is expected to validate against the formatting rules recorded in the constraints. As an example, the constraint node (purple box) in Fig 5 is a JSON schema, and all 3 downstream instances (red-bordered circles) must validate against it.

Fig 5: The depicted file for the class instance (object, right) validates correctly against the JSON schema of the constraint node (object, left) because it has two top level properties, name and breed, both of which are strings, as required.

In addition to validation of existing instances, the constraint node can also be used to create new instances. In this manner, a concept is similar to a class in OOP, with the constraint node playing a role analogous to that of the class variables and methods. (Is this a fair statement?)

When the constraint node is an object (which is frequently but not necessarily always the case), the constraint node can be decomposed into constituent properties. Property trees can be of any arbitrary depth and complexity. A simple one is shown in Fig 6:

Fig 6: Constraints (purple box) that take the form of objects can be decomposed into properties (orange diamonds) and organized into trees of arbitrary depth and complexity.

In Fig 7, we see that data from one concept (the list of Dog Breeds) can be used as part of the definition (or construction) of an individual property (orange diamond) of a different concept (Dog). We call this horizontal integration of concepts.

Fig 7: Dog Breeds is a superset node with two downstream instances, stored as an array. The blue arrow triggers transcription of that array from the superset file (left) to the property file (right). In this way, updates to one concept will become automatically reflected in the horizontally integrated concept.

In this manner, property nodes of any type (not just string but also array, object, etc) can be constrained by data derived from other concepts via horizontal integration.

Using the above tools, three categories of integrations can be employed to weave concepts together vertically as well as horizontally to form the concept graph.

Fig 8: Three types of integrations are depicted, two vertical and one horizontal.

Final note: Every node in a concept graph is required to be an instance of at least one concept.

Overview of app functionality

The app I desire would have two main capabilities:

• The user can modify and explore the graph database, with sophisticated visualization tools that neo4j would be great at.

• The app would have an extensive collection of scripts to monitor and extract information encoded topologically and update node files accordingly, as in the example of Fig 7.

Market

Customers may be programmers as well as the average user. Conceptualization of any piece of software (in whole or in part) may be useful as a novel method to organize data for any application. Regular users may also find the concept graph to be an intuitively appealing method of organizing, viewing and sharing concepts and ideas.