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.
--
You received this message because you are subscribed to the Google Groups
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/opencog/c4e59624-729b-46bd-987d-0575c1992643n%40googlegroups.com.
