Substitutions and similarities used in the knowledge graph
foobaring foobaring
Hi. I hope you all doing good. I’m really glad that you people advanced a lot in this topic.
I saw your presentations talking about, link grammars, symbolic representations, and about using similarities and substitutions.
I’ll try to be very concise. In short my statement is that with similarities and substitutions you can have solutions of previously unsolved problems. In other words, generate new knowledge using previous related knowledge.
I apologize in advance for my lack of proper technical terms. But, if the idea get through, that will be enough for me. I hope my explanation is understandable.
The following is a graph composed by sub-graphs, the nodes are linked by the equal ‘=’ relation, which goes in both directions in case there is no more links, by default is left to right. The nodes can be single values or sets.
For briefness and explain-ability I will use this notation instead of an actual graph (image).
About my notations:
- [v1, v2] is a set,
- '=' is the relation,
- Every line can be seen as a sub-graph.
- I will use // to add a comment for explanation
- A ‘query’ is a new node that has no similarity relation in the graph and therefore the algorithm needs to be used
The initial state of the graph and a case of a query and the result:
Alice = programmer
Bob = engineer
Mary = designer
John = programmer
Rose = engineer
Joe = designer
[engineer, job] = [model, system]
[programmer, job] = [develop, system]
[designer, job] = [design, UI]
Alice = available
Bob = available
Mary = available
Alice = [available, programmer]
Bob = [available, engineer]
Mary = [available, designer]
// initially available, but later relations are updated to working
John = working
Rose = working
Joe = working
R1 = name
R2 = name
solution = [
[[available, engineer], [engineer, job]],
[[available, programmer], [programmer, job]],
[[available, designer], [designer, job]]
]
[new, request] = [unsolved, request]
[request, name] = request
[solution, name] = solution
[resolve, request] = work
work = [solution, for, request]
// if we have a [unsolved, request] we want to [resolve, request]
// this is a simplification. It could have more meaning if we add more details to this relation
[unsolved, request] = [resolve, request]
// the query is [Medical, report, system]
[new, request] = [Medical, report, system] // the query is linked to be equal to a [new, request]
[Medical, report, system] = [request, R1] // generated [request, R1] to identify the query
[request, R1] = [unsolved, request] // given that [unsolved, request] = [new, request]
[request, R1] = [request, name] // given that R1 = name
[request, R1] = request
[request, R1] = [resolve, request] // given that: [unsolved, request] = [request, R1]
[resolve, [request, R1]] = work // given that: request = [request, R1]
// here [solution, R1] can be generated by a stored procedure for simplicity, and in this case is used to
// identify the node that will be the actual solution
[solution, for, [request, R1]] = [solution, R1] // given that: work = [resolve, request], and work = [solution, for, request]
[solution, R1] = [solution, name]
[solution, R1] = solution
// final state, here the replacement for the node ‘solution’ is used to produce the final relation
[solution, R1] = [[Rose, [model, system]], [John, [develop, system]], [Joe, [design, UI]]]
// For the next part, to do a new query I will do the following to avoid ambiguity
[request, R1] != [new, request] // this can be resolve in multiple ways, in this case I’ll go with this
At this point I will do a new query to illustrate how with substitutions we can generate a new knowledge, given the previous state of graph.
[new, request] = [Hotel, management, system] // new query is [Hotel, management, system]
[Hotel, management, system] = [request, R2] // generate a identification node
[request, R2] = [request, name] // given that: R2 = name
[request, name] = [request, R1] // we have this relation, then
[request, R2] = [request, R1] // therefore
[request, R2] = [solution, R1] // is the current most similar, but
[request, R2] is not similar enough to [solution, R1] because:
If we take into account the full sequence of substitutions we will notice that
[Hotel, management, system] is not equal to [Medical, report, system]
We can do better, if we use 'solution' instead of [solution, R1]:
[solution, R1] = solution
[request, R2] = solution // given the previous relation
[request, R2] = [
[[available, engineer], [engineer, job]],
[[available, programmer], [programmer, job]],
[[available, designer], [designer, job]]
]
[request, R2] = [
[Bob, [model, system]],
[Alice, [develop, system]],
[Mary, [design, UI]]
]
// final output
[solution, R2] = [
[Bob, [model, system]],
[Alice, [develop, system]],
[Mary, [design, UI]]
]
This example is not really that interesting, and looking at the result it seems pretty obvious. But the key here is that is generalizable, and is just substitutions.
This substitution mechanism can be applied to multiple cases to solve any kind of situations, given that it has enough previous knowledge. Is like applying a formula, step by step. Every step is guided by a previously known relation. This mechanism should be the algorithm applied directly to the graph, so that is the process with which the graph change from one state to the next state.
About the type system: I personally think that is not needed. I think that the type information is implicit in the data stored in the graph, for example: designer is a type, joe is an instance of designer. If is needed we can create the following relation: designer = type. To be more explicit.
Thanks again for your time, and for the great work you are doing. I hope I am being useful.