OK, we will not consider this problem.

2018-03-15 9:14 GMT+03:00 Linas Vepstas <[email protected]>:

>
>
> 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/CABpRrhxgxRX2UN2VOOPawOhD54ZNVDPQq6D2dRRzh_chZLTtEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to