имхо, миры, в которых живут различные общества — это давно уже разные диалекты одного общего языка. а база везде одинакова, т.к. везде описывается один и тот же мир, и большинство аспектов описания совпадает. ведь идёт стремительтельная взаимная ассимиляция языков.
поэтому, для совпадающих аспектов, можно взять некий общий язык.
понятия пронумеровать UUID-шниками или ещё как :)
(кстати, см. ниже мой коммент про синий/голубой.)
а значит, осталось определиться только с языком описания особенностей языков. очевидно, что эту роль может взять на себя инвертированный иллюстрированный толковый словарь:
чтобы из описания модели мира и смысла предложения, можно было подобрать наиболее удачный термин.
скажем:
(мулат, женщина) => мулатка.
(учитель, женщина) => учительница.
жена генерала, оскорбительное => генеральша.
генерал, оскорбительное => генерал-неумеха.
и так далее.
это действие назовём «семантическая свёртка». я думаю, кто-нибудь его уже так называет, и вы мне мою терминологическую самодеятельность простите :)
вообще, было бы замечательно, если бы ты ознакомлся поподробнее с имеющимися разработками на данную тему и тоже включил их в свои заметки.
впрочем, могу и я попробовать изобразить какую-нибудь статью на данную тему, или даже несколько.
скажем, давайте, я про opencyc напишу.
расскажите мне только, какие темы поднять. да и если кто карму поднимет для целей написания статьи, возражать не буду :)
а пока покомментирую тут, расскажу, как проблемы, поднятые в комментариях, решаются в других онтологиях.
увы, в админке джанго накоплено огромное количество фич.
как и в любом большом проекте, понемногу накапливаются неудобства.
но эти фичи есть, они есть сразу, они работают.
пока не лезешь сильно глубоко, соотношение фич к неудобствам у Django Admin великолепное.
то же самое касается Django Forms, Django urlconf, Django middleware, django.contrib.auth, django 3rd party plugins, и прочих вещей…
а если самому всё постоянно делать идеально, то и жизни не хватит!
и вообще, мне лично интересно именно быстрое прототипирование на Django, мне нравятся быстрые и легко масштабируемые базы данных. поэтому у меня недюжинный интерес к этой теме.
а что касается поддержки Django,
то, во-первых, есть django-couchdb, из которого можно черпать вдохновение,
во-вторых, товарищи любители NoSQL для Django замышляют более удобные классы для поддержки нереляционных баз данных (в django-dev последние сообщения на эту тему тут и здесь),
а в-третьих, Alex Gaynor провёл большую работу, связанную с освобождением кода Django от хардкоженного SQL для m2m: Commit 11710 и необходимую для поддержки множества разных баз данных в Django (Commit 11952).
Спасибо тебе огромное за models!
А интересно ли тебе заняться интеграцией Pyrant в обратную сторону, с Django Admin Interface?
Увы, база данных без GUI / WebUI для меня не достаточно удобна в использовании…
если коротко, то с помощью data mining можно делать следующее:
— предсказание морфологии слова
— автоматическое создание базы морфологических признаков
— предсказание синтаксической роли слов
— автоматическое создание базы синтаксических признаков
короче, при наличие большой базы, все задачи составления лингвистической информации можно сложить на компьютер.
decision trees употреблено здесь как одна из часто используемых технологий data mining.
этот метод (или его альтернативы) можно использовать для всех перечисленных выше действиях, так как они сводятся к задачам автоматического построения и использования классификаций.
кстати, именно этим я хотел бы заняться для русского языка через несколько месяцев.
также меня интересует автоматическое создание базы транскрипций, аналогичной CMUDICT, для разных естественных языков.
>Я, к сожалению, слабо верю в эти проекты, потому что факты — это хорошо, но их явно недостаточно.
Я предлагаю не рассматривать Cyc как самостоятельное полноценное решение проблемы слабого AI. Он создавался как самодостаточная база данных для вывода фактов на основе других фактов и предоставляемой ему внешней информации.
ну, я, наоборот, представляю чётко, как описать такую систему правил и логического вывода. более того, для некоторых задач в Cyc уже сформирована подобная система логического вывода, и Cyc способен решать такие задачи.
проблема, на мой взгляд, совершенно в другом.
1) как обойтись без объяснения компьютеру, что имеется в виду под «пошёл в 8 утра в школу» и «вернулся в 14 часов дня». скажем, как компьютер поймёт, что всё происходит в один день? человек решает данную задачу, основываясь на том, что ему дано достаточное количество данных.
2) как обойтись без объяснения компьютеру подобных правил вывода, работы с интервалами, логического вывода на основе ограничений, возможно, даже потребуется что-то типа моделирования ситуации в виртуальном мире.
если данные проблемы не рассматривать, то система должна работать примерно следующим образом: на основании входных данных и ограничений формируется задача (М пошёл в школу в 8 утра, М вернулся в 14 дня, где был М в 11 дня, ответ к задаче существует, данных для решения достаточно). constraint solver её решит.
подобным образом уже решаются даже текстовые геометрические задачи.
нет, тут вы не совсем правы.
в основном используются алгоритмы массового извлечения Common Sense из текстов.
просто большинство подобных проектов своей задачей ставит сверх-высокую степень очистки знаний, поэтому знания накапливаются достаточно медленно.
— в OpenCyc всего 47,000 concepts and 306,000 facts (http://en.wikipedia.org/wiki/Cyc),
— в основанном на нём Umbel — 20,000 subject concepts and relationships distilled from OpenCyc, a further 1.5 million named entities are mapped to that structure,
— в DBPedia — 2.9 million things,
— во FreeBase — десятки миллионов табличных фактов.
Итого, знаний о вещах уже больше, чем у отдельных людей :), но всё ещё меньше, чем у человечества в целом. Кроме этого, ещё есть менее структурированные базы данных второго порядка (wikipedia, энциклопедии итп).
Мало только знаний в базах данных логических правил вывода. Вот эту информацию абсолютно непонятно как заполнять автоматически.
кроме того, я подозреваю, что альтернативы семантическим подходам парсинга текстов просто нет. огромную неоднозначность понимания текста без базы знаний устранить невозможно.
>Человеку проще правда еще тем что у него есть жизненный опыт помогающий извлечь смысл из текста, программам такого пока не дано.
Почему же, OpenCYC и некоторые другие базы данных как раз занимаются этим «жизненным опытом», под названием Common Sense.
Например, там есть данные такого плана «в доме человека обычно есть мебель»,
«фрукт — съедобное», «фрукт — объект физического мира, разные фрукты не пересекают друг друга» (SpatiallyDisjointObjectType), итп.
или вот вам, например, транспортное средство: sw.opencyc.org/2009/04/07/concept/en/TransportationDevice
или дом: sw.opencyc.org/2008/06/10/concept/en/HumanResidence
>я уже спрашивал про такие языки — как парсить, если субъект/объект обозначается инфиксами и флексиями глагола.
ну, тут, как мне кажется, всё просто. многие флексии или правила разбиения заранее известны (а иначе как люди друг друга понимают?).
разбиваем по ним слово и получаем обычный нормальный язык :)
(((бить всё-время/так-сильно) себя) не)
Семантика эксплуатируется, насколько это вообще возможно. цитата: «I believe that the human mental lexicon caches morphological rules in the projected word forms paired with their semantics, and invokes these rules only when comprehending a new or uncommon combination.» т.е., синтаксис и словарь используются для определения типологии предложения и заполнения слотов вспомогательными словами (в русской терминологии, «валентностей»).
Хотелось бы услышать мнение об этом специалиста, потому что мне не хватает общелингвистических знаний, чтобы разбираться в этих ACT-R, Double-R Theory и LSA ( lsa.colorado.edu/whatis.html ).
P.S. собственно, все эту ветку комментариев по хорошему переместить бы в часть 5, там они будут гораздо более в тему.
>Как он будет клеить эти слова между собой и на каком основании?..
на основании значений слов и их связей из common-sense онтологии, лежащей в основе.
т.е., не важно, как называются грамматические категории этих слов, важен смысл, который можно из этих слов получить.
а кто-нибудь может прокомментировать проект TexAI?
в основе Fluid Construction Grammar, (...) Walter Kintsch’s Construction/Integration theory of reading comprehension, modified to operate incrementally, and cross fertilized with John Anderson’s ideas about memory retrieval through spreading activation.
Вероятно, нужен универсальный принцип.
Для быстрого перемножения в уме чаще всего используется метод Трахтенберга:
с конца в начало вычисляются единицы, потом десятки, потом сотни. и т.д.
33*44 = 3*4 + (3*4+4*3)*10 + (3*4)*100 = 1200 + 240 + 12 = 1452
Но возможно Клей дополнил это каким-нибудь минимальным усовершенствованием и обозвал своим методом. Например, какое-нибудь вынесение мелких дополнительных множителей за скобки:
4*11*33 =2*(2*(11*33)) = 2*2*363 = 2*726 = 1452
или частичным применением метода Трахтенберга:
44*33 = 44*30+44*3 = 1320 + 132 = 1452
Вообще, разным людям считать подручнее разными способами. Зависит от имеющихся вспомогательных навыков.
«Clay's method is best explained on paper. Suffice it to say you multiply the digits on the right, cross-multiply and add the digits in the center, then multiply the digits on the left. „
Метод Трахтенберга в чистом виде. Для меня ближе в данном примере частичный метод, так как складываю двухзначные числа я чуть медленнее, а привычное американцам “dozen» – дюжина, существенно упрощающего умножение в данном случае, и операции с ним, русскому уму непривычны.
В любом случае, мужик тупо зарабатывает деньги на интересе простых американцев, прочитавших новость и заинтересовавшихся.
поэтому, для совпадающих аспектов, можно взять некий общий язык.
понятия пронумеровать UUID-шниками или ещё как :)
(кстати, см. ниже мой коммент про синий/голубой.)
а значит, осталось определиться только с языком описания особенностей языков. очевидно, что эту роль может взять на себя инвертированный иллюстрированный толковый словарь:
чтобы из описания модели мира и смысла предложения, можно было подобрать наиболее удачный термин.
скажем:
(мулат, женщина) => мулатка.
(учитель, женщина) => учительница.
жена генерала, оскорбительное => генеральша.
генерал, оскорбительное => генерал-неумеха.
и так далее.
это действие назовём «семантическая свёртка». я думаю, кто-нибудь его уже так называет, и вы мне мою терминологическую самодеятельность простите :)
в существующих общих онтологиях типа Cyc реализуют множественное наследование.
и по-моему, правильно делают.
пример я, кажется, уже приводил?
скажем, класс из середины иерархии: sw.opencyc.org/2009/04/07/concept/en/TransportationDevice
а вот лист: sw.opencyc.org/concept/Mx4rve1ZXZwpEbGdrcN5Y29ycA
или вот достаточно высокоуровневый тип: sw.opencyc.org/concept/Mx4rvVinb5wpEbGdrcN5Y29ycA
вообще, было бы замечательно, если бы ты ознакомлся поподробнее с имеющимися разработками на данную тему и тоже включил их в свои заметки.
впрочем, могу и я попробовать изобразить какую-нибудь статью на данную тему, или даже несколько.
скажем, давайте, я про opencyc напишу.
расскажите мне только, какие темы поднять. да и если кто карму поднимет для целей написания статьи, возражать не буду :)
а пока покомментирую тут, расскажу, как проблемы, поднятые в комментариях, решаются в других онтологиях.
как и в любом большом проекте, понемногу накапливаются неудобства.
но эти фичи есть, они есть сразу, они работают.
пока не лезешь сильно глубоко, соотношение фич к неудобствам у Django Admin великолепное.
то же самое касается Django Forms, Django urlconf, Django middleware, django.contrib.auth, django 3rd party plugins, и прочих вещей…
а если самому всё постоянно делать идеально, то и жизни не хватит!
и вообще, мне лично интересно именно быстрое прототипирование на Django, мне нравятся быстрые и легко масштабируемые базы данных. поэтому у меня недюжинный интерес к этой теме.
а что касается поддержки Django,
то, во-первых, есть django-couchdb, из которого можно черпать вдохновение,
во-вторых, товарищи любители NoSQL для Django замышляют более удобные классы для поддержки нереляционных баз данных (в django-dev последние сообщения на эту тему тут и здесь),
а в-третьих, Alex Gaynor провёл большую работу, связанную с освобождением кода Django от хардкоженного SQL для m2m: Commit 11710 и необходимую для поддержки множества разных баз данных в Django (Commit 11952).
А интересно ли тебе заняться интеграцией Pyrant в обратную сторону, с Django Admin Interface?
Увы, база данных без GUI / WebUI для меня не достаточно удобна в использовании…
— предсказание морфологии слова
— автоматическое создание базы морфологических признаков
— предсказание синтаксической роли слов
— автоматическое создание базы синтаксических признаков
короче, при наличие большой базы, все задачи составления лингвистической информации можно сложить на компьютер.
decision trees употреблено здесь как одна из часто используемых технологий data mining.
этот метод (или его альтернативы) можно использовать для всех перечисленных выше действиях, так как они сводятся к задачам автоматического построения и использования классификаций.
кстати, именно этим я хотел бы заняться для русского языка через несколько месяцев.
также меня интересует автоматическое создание базы транскрипций, аналогичной CMUDICT, для разных естественных языков.
www.texai.org/blog/?p=294 и www.texai.org/blog/?p=79
Я предлагаю не рассматривать Cyc как самостоятельное полноценное решение проблемы слабого AI. Он создавался как самодостаточная база данных для вывода фактов на основе других фактов и предоставляемой ему внешней информации.
проблема, на мой взгляд, совершенно в другом.
1) как обойтись без объяснения компьютеру, что имеется в виду под «пошёл в 8 утра в школу» и «вернулся в 14 часов дня». скажем, как компьютер поймёт, что всё происходит в один день? человек решает данную задачу, основываясь на том, что ему дано достаточное количество данных.
2) как обойтись без объяснения компьютеру подобных правил вывода, работы с интервалами, логического вывода на основе ограничений, возможно, даже потребуется что-то типа моделирования ситуации в виртуальном мире.
если данные проблемы не рассматривать, то система должна работать примерно следующим образом: на основании входных данных и ограничений формируется задача (М пошёл в школу в 8 утра, М вернулся в 14 дня, где был М в 11 дня, ответ к задаче существует, данных для решения достаточно). constraint solver её решит.
подобным образом уже решаются даже текстовые геометрические задачи.
в основном используются алгоритмы массового извлечения Common Sense из текстов.
просто большинство подобных проектов своей задачей ставит сверх-высокую степень очистки знаний, поэтому знания накапливаются достаточно медленно.
— в OpenCyc всего 47,000 concepts and 306,000 facts (http://en.wikipedia.org/wiki/Cyc),
— в основанном на нём Umbel — 20,000 subject concepts and relationships distilled from OpenCyc, a further 1.5 million named entities are mapped to that structure,
— в DBPedia — 2.9 million things,
— во FreeBase — десятки миллионов табличных фактов.
Итого, знаний о вещах уже больше, чем у отдельных людей :), но всё ещё меньше, чем у человечества в целом. Кроме этого, ещё есть менее структурированные базы данных второго порядка (wikipedia, энциклопедии итп).
Мало только знаний в базах данных логических правил вывода. Вот эту информацию абсолютно непонятно как заполнять автоматически.
кроме того, я подозреваю, что альтернативы семантическим подходам парсинга текстов просто нет. огромную неоднозначность понимания текста без базы знаний устранить невозможно.
скажем, en.wikipedia.org/wiki/Decision_tree_learning
и других технологий Data mining.
Почему же, OpenCYC и некоторые другие базы данных как раз занимаются этим «жизненным опытом», под названием Common Sense.
Например, там есть данные такого плана «в доме человека обычно есть мебель»,
«фрукт — съедобное», «фрукт — объект физического мира, разные фрукты не пересекают друг друга» (SpatiallyDisjointObjectType), итп.
или вот вам, например, транспортное средство: sw.opencyc.org/2009/04/07/concept/en/TransportationDevice
или дом:
sw.opencyc.org/2008/06/10/concept/en/HumanResidence
ну, тут, как мне кажется, всё просто. многие флексии или правила разбиения заранее известны (а иначе как люди друг друга понимают?).
разбиваем по ним слово и получаем обычный нормальный язык :)
(((бить всё-время/так-сильно) себя) не)
ссылки: www.texai.org/blog/?p=78
и www.texai.org/blog/?page_id=37
автор основывается на достаточно сложной модели типологии предложений под названием Double R Theory ( www.doublertheory.com/, www.doublertheory.com/OntologyGoldStandard.pps ), на которой базируется используемая Fluid Construction Grammar. Про длинные связи: www.doublertheory.com/LongDistanceDependencies.pps
Хотелось бы услышать мнение об этом специалиста, потому что мне не хватает общелингвистических знаний, чтобы разбираться в этих ACT-R, Double-R Theory и LSA ( lsa.colorado.edu/whatis.html ).
P.S. собственно, все эту ветку комментариев по хорошему переместить бы в часть 5, там они будут гораздо более в тему.
на основании значений слов и их связей из common-sense онтологии, лежащей в основе.
т.е., не важно, как называются грамматические категории этих слов, важен смысл, который можно из этих слов получить.
вот презенташка, где на страницах 6-8 достаточно подробно разбирается подход.
texai.org/papers/agi-09-poster1.PPT
в основе Fluid Construction Grammar, (...) Walter Kintsch’s Construction/Integration theory of reading comprehension, modified to operate incrementally, and cross fertilized with John Anderson’s ideas about memory retrieval through spreading activation.
Для быстрого перемножения в уме чаще всего используется метод Трахтенберга:
с конца в начало вычисляются единицы, потом десятки, потом сотни. и т.д.
33*44 = 3*4 + (3*4+4*3)*10 + (3*4)*100 = 1200 + 240 + 12 = 1452
ru.wikipedia.org/wiki/Метод_Трахтенберга
Но возможно Клей дополнил это каким-нибудь минимальным усовершенствованием и обозвал своим методом. Например, какое-нибудь вынесение мелких дополнительных множителей за скобки:
4*11*33 =2*(2*(11*33)) = 2*2*363 = 2*726 = 1452
или частичным применением метода Трахтенберга:
44*33 = 44*30+44*3 = 1320 + 132 = 1452
Вообще, разным людям считать подручнее разными способами. Зависит от имеющихся вспомогательных навыков.
В гугловской базе патентов я этот патент не нашёл.
Но из askville.amazon.com/math-wiz-Albert-Clay/AnswerViewer.do?requestId=57163987:
«Clay's method is best explained on paper. Suffice it to say you multiply the digits on the right, cross-multiply and add the digits in the center, then multiply the digits on the left. „
Метод Трахтенберга в чистом виде. Для меня ближе в данном примере частичный метод, так как складываю двухзначные числа я чуть медленнее, а привычное американцам “dozen» – дюжина, существенно упрощающего умножение в данном случае, и операции с ним, русскому уму непривычны.
В любом случае, мужик тупо зарабатывает деньги на интересе простых американцев, прочитавших новость и заинтересовавшихся.