On a previous article reviewing the book “On Intelligence”, I was mentioning something I found fascinating; the 3-dimensional encoding nature of fundamental sensing such as:
sound: amplitude, frequency and duration color: luminosity, hue and saturation pain: intensity, location and spread
I saw this Quora discussion regarding the definition of Ontology about the following paper from Parsa Mirhaji presenting an event driven model in semantic context that could also be encoded in triple store.
If you’ve already stumbled upon semantic web and all its ontological weirdness, you’ve probably come across the concept of RDF triplestore, or Turtle for intimates, which allows you to encode your data using a global schema made of 3 elements:
The subject, the predicate and the object.
This allows you to encode natural language proposition easily. For instance, the sentence “Daddy has a red car” makes Daddy the subject, has the predicate and a red car being the object. As a general rule of thumb, everything coming after the predicate will be considered the object. The subject and object could be contextually interchangeable, which allows deep linking. Also multiple predicate can apply to a subject, even if the object is the same.
“I have a bass guitar” and “I play a bass guitar” are 2 different propositions seeded which have only a different predicate, and it would be more natural (in natural language) to express a reference within the same sentence such as “I play the bass guitar that I have” (although you’ll notice that I inferred the bass guitar is the same, it is a bit of a shortcut)
If I had the idea to convert my “simple” triplestore to a SQL table; I could say the complexity of this triplet relationship is
Also, subject and object should be foreign keys pointing to the same table as I and a guitar bass could both be subject or object depending on the context.
If converted to a graph database, a predicate would therefore be a hyperedge, a subject would be a inbound node and an object would be an outbound node. That leaves us with a hypergraph. This is why some, like Grakn, adopted this model. Although, their solution is schemaful so they enforce a structure a priori (which completely contrasts with my expectations regarding Serf that requires an environment to be schemaless and prototype-based, therefore I’ll default to a property graph database, but the guys are nice)
Getting back to the initial picture that triggered this post; I found really interesting to further, or alter, the traditional schema subject-predicate-object to a schema:
subject – event – observation
It seems that, in the first case, we are working with purely descriptive (although really flexible) case while this other schema allows us to work on an action/event base. That is catchy as I couldn’t resist apply my relativism: “Oh well, it’s context-based” and to consider that there should be a bunch of other triplet schemas to be used as fundamental ways of encoding.
Making the parallel with the sensing approach; such as pain and its triplet location-intensity-spread, could I also say that it’s fundamentally just vectors that could be expressed by the peculiar structure of pyramidal neurons?
Those neurons are the largest from the different varieties in the brain and their soma is shaped quite like a pyramid (hence their name) with basal dendrites (input wires) starting usually with 3 primary dendrites (up to 5 in rarer cases). It’s a bit like if 3 input trees met to a single input wire (apical dendrite) in order to produce a single output wire (axon).
Of course, it is just conjecture, but the triplet approach of any fundamental information, based on perception or cognition, is really tempting and sexy as it works so well.
Although, if pyramidal neurons are everywhere in the brain, what their location and what they’re connected to really makes a huge difference in their behavior.
And this is why I started to nurture, in a corner of my mind, the idea that we could add a contextual field to pick the right schema. This would act as a first field, as a group in graph representation probably, or just another foreign key in a SQL storage, that selects what the 2 last fields would be about.
In summary, a quadruple store would extend any triplet such as:
Context – <SourceSubject> – <TypeOfRelation> – <TargetSubject>
Where the context solves the other fields type. At least, this idea has been written down and will keep evolving until satisfaction.