On Thu, Mar 15, 2018 at 12:54 AM, Alexey Potapov <[email protected]> wrote:
> >> >>> > You can say: just don't use PM for such queries. >> >> >> Why not? For certain kinds of basic prepositional queries, such as >> taller, closer, larger, next-to, above, behind, is-a-part-of, is related-to >> -- we need a good, effective query system for those, Currently, the pattern >> matcher cannot do many or even most of these, but the engineering needed to >> make it effective is not hard. The needed changes, improvements, >> enhancements are straight-forward. >> > > Man, I don't understand you... Initially, I proposed to consider the > possibility of performing such tweaking, but you started to argue: use > space-server, use SQL, use whatever you want exect PM... I have almost > agreed: OK, we will not touch PM... But now you say: it's not a hard > problem. So, what was all this discussion about?.. > OK, I won't be able to answer email for 48 hours, but in short, I don't understand what you don't understand, then. The pattern matcher does not support human natural-language type prepositional queries. It could, but it would require at least two or three things: a far more sophisticated and advanced space server, and a knowledge representation system for prepositions. The pattern matcher is trying to be agnostic about knowledge representation. It is trying to not impose any predefined knowledge representation system. Concepts like "near" and "far" are knowledge, you have to figure out how to represent them. Once you have done this, the pattern matcher can run queries. When I say SQL, I mean "think of a relational algebra". Formally, relational algebras are model "structures" which have no function signatures and only relation signatures. SQL is meant to be a generic example of a relational algebra is. SQL servers were originally designed to implement relational algebras. There are 3 kinds of "problems" -easy, medium and hard Easy problem: any problem that a team of 5-20 competent programmers can solve in a year or two (or less). Medium problem: any easy problem that requires more money, resources, and executive management, but is solvable by standard engineering practice. Hard problem: creating algorithms that learn, in the AGI sense of "learn". Improving the pattern matcher, adding features to it, etc. is an "easy" problem. Some improvements might take days, or weeks, or months, or years, but none of the improvemnts are technically hard. Ordinary programmers with some general interest in algorithms such as satisfiability, relational algebra, universal algebra, logic, etc. can do it. Most database and compiler people have a pretty good grounding in satisfiability and relational algebras, and stuff of that sort. These skills are available on the job market. Linas. -- cassette tapes - analog TV - film cameras - you -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA343z3-2YBeS%3D_en1vCTb9rkUTySpJkMPBXFoasF-ycfqg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
