Category: лингвистика

Category was added automatically. Read all entries about "лингвистика".

2019

Выучить онтологию, а потом творить с её помощью

Вот ещё одно исследование по культурно-обусловленной кривизне в картине мира, выучиваемой из больших объёмов текста -- Semantics derived automatically from language corpora necessarily contain human biases, http://arxiv.org/abs/1608.07187. В естественном языке присутствует довольно много остатков древних вариантов онтологии, в текстах они часто встречаются, и из-за этого выученное семантическое пространство оказывается кривоватым. Я в http://ailev.livejournal.com/1281819.html цитировал из этой линии работ Quantifying and Reducing Stereotypes in Word Embeddings https://arxiv.org/abs/1606.06121 и Man is to Computer Programmer as Woman is to Homemaker? Debiasing Word Embeddings, http://arxiv.org/abs/1607.06520.

Если приглядеться, то в этой линии исследований по выявлению и устранению культурно-обусловленных biases можно выделить следующие проблемы:

1. Разница между семантикой и онтологией (семантика -- это про язык, "как говорят". Онтология -- это про мир, "что есть в мире". Если обсуждаются biases, то это сдвиги того "как говорят" по отношению к тому, "что есть в мире"). Тем самым в данной линии работ выходят на различия представлений лингвистических (семантика, про "понятия", "значения") и онтологических (непротиворечивая структура мира, данная в рамках непротиворечивого описания -- обратите внимание на разницу мира и описания!). Многие нам известные лингвисты приходили к выводу, что чисто лингвистических представлений для понимания языка (NLU, natural language understanding) недостаточно, и нужно как-то обращаться к онтологии. Но как именно? Ведь нет более мёртвой вещи, чем жёстко определённая раз и навсегда картина мира -- метафизику ведь не зря критикуют, а онтология это её часть. И без онтологических рассуждений обойтись чисто лингвистическими рассмотрениями всё чаще и чаще не удаётся. Вот, например, очередные попытки скрестить ежа с ужом -- предложение онтотерминологии: http://arxiv.org/abs/1609.05170.

2. Но если мы и хотим выучить из каких-то текстов картину мира, онтологию, а хоть и в виде "семантического пространства" (разные варианты предварительно выучиваемых embeddngs, и не забываем критику Nando de Freitas в http://ailev.livejournal.com/1240509.html -- это именно про "значения", а ведь есть ещё смысл! выучивание значений интересно только как база для определения смысла!), то все проблемы онтологов будут нашими, даже если мы-лингвисты о них не знали. Например, ontology revision (вы можете прихватить какой-то один факт, который приведёт к необходимости переструктурирования всей вашей онтологии). Или одновременное выучивание нескольких онтологий, "исторических" (скажем, "земля плоская") и "современных" ("земля круглая", "земля геоидная"). Или винегрет из онтологий нескольких близких и далёких научных школ (в психологии, например, до сих пор нет хоть какого-то единства по поводу тамошней онтологии -- сравните, например, с физикой или химией).

3. Важность слова shared в определении онтологии: в момент появления нового знания оно не онтология, это просто чьи-то личные мысли. Но по мере того, как знание овладевает массами, оно становится онтологией. Большинство современных подходов предполагают выучивание онтологии у масс, т.е. выучиваются только фолк-онтологии, со всеми их biases, ошибками и суевериями. Онтологическая инженерия понимается часто именно как запечатление этой народной онтологии в формальном языке. Но это не позволяет говорить о прямой онтологической инженерии, применении принципов радикального конструктивизма. Меня этот аспект очень трогает, я ведь и сам радикальный конструктивист, поэтому для меня важны и аспекты эпистемологические, и аспекты деятельностные (http://ailev.livejournal.com/661094.html, http://ailev.livejournal.com/860017.html), с ними тоже нужно разбираться.

4. И ещё хотелось бы напомнить "мою космонтику" http://ailev.livejournal.com/1268678.html, где тоже поднимаются проблемы онтологизирования, моделирования в связи с эволюцией и развитием, так что "выучить онтологию" и расслабиться не получится, всё это нужно как-то переводить на life-long learning. Все эти biases плывут во времени, плывут в разных социумах, обучение на материале учебников будет сильно отличаться от обучения на материале коммунистической прессы или статей в arxiv -- и это всё тоже нужно как-то разводить, застывшие канонические семантические пространства не будут работать, часть возражений от Nando de Freitas из http://ailev.livejournal.com/1240509.html сюда.

Онтологические (и по сопричастности метафизические) проблемы, конечно, будут вылезать не только из работ по human biases, не только из необходимости обеспечивать рассуждения (логический вывод) в понимании естественного языка, не только из связанных с решением инженерных задач работ. Для меня, например, связь текстов-описаний и реального физического мира (например, фотографий -- буквально, "картины мира") это тоже часть выхода на онтологии. Вот, например, https://github.com/paarthneekhara/text-to-image -- Text To Image Synthesis Using Thought Vectors. Посмотрите, какая интересная архитектура, где по описаниям генерируются картинки:

Есть буквы, складывающиеся в слова, которые складываются в мысли (предложения). Эти мысли представляются как находящиеся в семантическом пространстве (значений). Это семантическое пространство отображается как-то на физическое пространство (данное в виде изображений физического мира). Эти соотношения как-то выучиваются. Эпистемология, ответ на вопрос "как узнал": выучил! А дальше в ответ на описание можно выдать целевую картинку мира. Дьявол, но это ведь "творение мира" -- инженерный ход! Текстовое описание необязательно ведь будет совпадать со встреченным в учебной выборке. А сгенерированная по представленному мной тексту-пожеланию-спецификации картинка может считаться моделью физического целевого мира. Так что приведённая на картинке архитектура генерации изображений по текстам в какой-то мере деятельностная, инженерная. Сгенерированное изображение, сгенерированную модель/описание/картину мира можно затем использовать непосредственно для преобразования мира, для творения в прямом (онтологическом, а не лингвистическом) смысле слова.
2019

Плохое понимание плохого понимания компьютеров

Общение с людьми, исповедующими ситуацию в области искусственного интеллекта, лингвистики, работы со знаниями и прочих подобных материй всего навсего трёх-четырехлетней давности (конкретно: до 2012 года) напоминает общение квантового физика со спецами в теории флогистона. Квантовый физик даже не знает, как ответить на обвинение его в том, что нарезка флогистона маленькими порциями (это же главная идея квантовости!) ничего не решит ни в теории, ни в эксперименте. И правда, ведь не решит! Как объяснить людям, что deep learning в лингвистике это не про частотные словари и не про задачи классификации, я не знаю. См. длииинный тред в группе нейронета в фейсбуке, я там ввязался в разговор -- https://www.facebook.com/groups/nevronet/permalink/598668460299479/

Другая крайность -- это демонстрация, что компьютер делает примерно такие же ошибки, как мой тринадцатилетний сын и утверждение "ничерта эти ваши компьютеры не умеют, не понимают они языка!". Ну да, эти компьютеры явно пока не доктора филологии. Но state-of-the-art изменился за последние три года кардинально, и это измеримо. Так, повод для треда в группе нейронета чудесный: на датасете в 1млрд. слов было получено в публикации от 7 февраля 2016г. снижение perplexity до 24.2 -- http://arxiv.org/abs/1602.02410. Хотя сама мера perplexity (грубо: вероятность того, что ваша модель не путает слова в предложениях) вызывает крайнее раздражение у всех её использующих, альтернативу ей трудно придумать: http://nlpers.blogspot.ru/2014/05/perplexity-versus-error-rate-for.html. Снижение perplexity означает, что языковые модели стали точнее. Много, много точнее. И это подтверждается не для крошечного набора текстов, а для набора текстов из миллиарда слов.

Критикующие же все эти новинки лингвистики люди демонстрируют ровно те качества, которые приписывают компьютеру: мало понимают, о чём идёт речь и каков state-of-the-art. Лингвистический флогистон у них, понимаешь, от порезки на маленькие кванты... дальше я уже писал в первом абзаце этого поста.

Мой пойнт в том, что люди и сами несовершенны в коммуникации и понимании текстов, но за компьютером достижения какие-то признают только тогда, когда он победит "чемпиона мира" -- скажем, в мировой олимпиаде переводчиков, или совершит ещё какой-то аналогичный подвиг. А если это будет победа не над чемпионом мира, а чемпионом Европы, то опять будет смачно зафиксировано "отсутствие прогресса в компьютерной лингвистике". И никакие метрики и бенчмарки не будут засчитаны за аргумент. Пичалька.

Ну, что я могу тут сказать? Не всех лингвистических извозчиков возьмут в лингвистические таксисты. А потом и лингвистических таксистов заменят безлюдные сервисы. Очень, очень быстро заменят. Лингвистическая модель учится за неделю и потом быстро копируется. Лингвист учится десять лет, а потом не копируется. Обновления к лингвистической компьютерной модели могут поступать дважды в сутки (над ней могут работать, скажем, полсотни человек full time), а лингвист после студенческих своих лет обновляется крайне медленно и над ним странно представить себе работающих полсотни человек. Впрочем, я тут не только про лингвистов. К остальным это тоже относится.
2019

AINL 2014 -- день первый

Сходил сегодня на конференцию AINL (http://ainlconf.ru/agenda) -- искусственный интеллект и естественный язык. Лингвистики было в количестве, искусственный интеллект пока не детектед. Совсем не детектед, что очень жаль.

Тусовка хвастается значениями метрик F1 для узнавания чего-то в текстах (http://en.wikipedia.org/wiki/F1_score, а "на пальцах" и по-русски, например, http://blog.gramant.ru/2012/06/06/f1-measure/). Узнаётся у каждого что-то своё высокоспецифичное, а значения метрики сегодня у людей типовая выше 0.9, у университетских узкоспециализированных программ 0.8, у коммерческих "унивесальных движков" порядка 0.7. Новички легко выходят на 0.6, а дальше нужно учиться.

Как я понял, опытные лингвисты уже прониклись необходимостью обращения к онтологиям, ибо уже понимают, что без них нельзя нынешние инвалидные лингвистические программы быстро-быстро исключительно глубокими нейронными сетками и прочими "машинными обучениями" доводить до гипервалидных с F1 лучше, чем у усталого и не очень внимательного человека не-лингвиста. В докладе ABBYY отметили, что их технологию сегодня делают человек 30 лингвистов и человек 10 онтологов (хотя тут нужно ещё разобраться, онтология ли там, или по-прежнему "онтолого-лингвистическая сеть"). Но пример ABBYY почти исключительный: онтологи среди лингвистов пока почти не встречаются.

Лингвисты и онтологи сильно различаются. Онтолог говорит о сущностях (окружающего мира, а хоть и об абстрактных сущностях -- "существующем"), лингвист в аналогичных ситуациях -- о "концептах" (которые абстрактны, но явно не существуют в реальном мире -- на "концепте самолёта" не полетишь, а вот на такой сущности реального мира, как "самолёт с серийным №23468835" -- вполне). Студенты-лингвисты бодро поддерживают разговор о поиске отношений часть-целое между словами (уточняя при переспросе, что речь идёт не о том, что одно слово является частью другого, а... -- и тут их речь становится неразборчивой). Лингвисты постарше радостно соглашаются, что нужно бы онтологию, и задумчиво перечисляют фамилии тех, кто этими онтологиями-в-лингвистике занимается.

Я проверил сегодня: в нашем онтологическом редакторе .15926 Editor (freeware, http://techinvestlab.ru/dot15926Editor) команда "import nltk" отличненько работает. Хотя большинство стендовых докладов ориентировались не на NLTK, а на Yandex Tomita Parser (http://api.yandex.ru/tomita/). Но ежели хочется быстро-быстро попробовать всю мощь связки современных технологий обработки текстов и онтологических технологий, то у нас оказывается не самый плохой для этого инструментарий.

Завтра тоже планирую пойти. Завтрашние темы даже поинтересней сегодняшних (обещают много разного рассказать про лингвистическое обеспечение для роботов).
2019

Управление корпоративными глоссариями, тезаурусами, терминологией

1. В чём проблема с терминологией
Проблема проста: в больших организациях разные люди используют разные слова для обозначения одних и тех же вещей, а также одни и те же слова для обозначения разных вещей. Это ведёт к ошибкам. Отдельный сценарий -- это использование каких-то хитрых сокращений, без знания которых тексты вообще невозможно понять. Ещё один сценарий: заграничные клиенты удивляются, когда разные страницы документации (переведённые разными переводчиками) содержат самую разую терминологию. И ещё один сценарий: используемая в документах надзорных органов, в САПР/PLM, в текстовых документах проекта (например, технических заданиях) терминология отличается, и поэтому нельзя проверить эти документы на соответствие друг другу -- как проект-в-САПР/PLM соответствует ТЗ и регулятивам. А вот ещё: документация на оборудование пришла из другой отрасли, там свои терминологические стандарты, и поэтому ещё нужно договориться, какие термины использовать в проектной документации. И таких сценариев -- множество.

2. Как "управлять терминологией"
Как всегда в случае "управления чем-то" (something management), управление тезаурусами (thesaurus management -- обратите внимание, что по-русски обычно тут единственное число переходит во множественное) или управление словарями предприятия (управление корпоративными словарями, enterprise vocabulary managment -- я бы это назвал в терминологии praxos управлением словарями предпринятия, хотя речь тут может быть и о масштабах отрасли -- что больше масштаба предпринятия, но вполне осмысленно для какой-то отраслевой ассоциации или сверхкрупного холдинга), терминологией (terminology management) означает не столько все творческие/инженерные усилия по созданию и употреблению тезаурусов и словарей (тогда бы это были инженерия тезаурусов и инженерия словарей), сколько менеджерскую/логистическую практику по обеспечению управления конфигурацией (нарезку тезауруса или словаря на конфигурационные единицы, постановку под управление конфигурацией и отслеживание изменений конфигурации) и их логистику (последующую доставку по запросу этих конфигурационных единиц словаря или тезауруса в места использования и/или обработки). [Используйте предыдущее предложение, чтобы испытать ваш парсер].

Грубо говоря, "управление тезаурусом и корпоративными словарями" означает по факту установку и эксплуатацию программ по вводу и хранению слов, определений, связей, списков слов и т.д., но никак не включает содержательной (лингвистической) работы. В этом "управлении тезаурусами/словарями" речь идёт о PLM системах для лингвистов, а не САПР для них -- хотя в жизни это всё может быть круто перемешано, как было перемешано в предметной области САПР до выделения из неё концепции PLM. Плывёт и сам концепт, чем именно "управлять" (т.е. управление конфигурацией чего, и логистику чего нужно обеспечивать). Вот, например, типичный пример (буквально второй вопрос в интервью http://poolparty.biz/open-w3c-standards-like-skos-provide-a-great-chance-to-combine-corporate-information-with-internet-based-resources/):
We face very different interpretations of terms like Thesaurus, Ontology, Glossary, Abbreviation list and many more. Thus we decided to talk about a “Glossary for Roche” only and it contains a mixture of data sources. But the technical solution is to manage this variety of data with just one tool for Thesaurus-Management. We start with abbreviation lists and glossaries including many synonyms and will push it into a true Thesaurus in the very near future.
Так что сразу посоветуем педантам не зацикливаться на какой-то "истинной терминологии", а сразу обсуждать суть дела, скрывающуюся за терминами. Конечно, мне самому ближе подход онтологов, которые выделяют линейку словарей (списков слов), глоссариев (список слов с определениями), таксономий (глоссарий, в котором присутствует иерархический классификатор), тезаурусов (таксономия, плюс не слишком большое число отношений, кроме специализации/классификации) и онтологий (богатое множество отношений между понятиями -- например, часть-целое, единицы измерения и т.д.). Поскольку у нас онтологов нетути, то всю эту линейку менеджеры любят называть "справочниками" и "глоссариями", а лингвисты -- "тезаурусами". Так что лингвист напишет ТЗ для "системы управления тезаурусами", а менеджер с большим удовольствием подпишет ТЗ по созданию "системы управления глоссариями", айтишник же с удовольствием займётся "системой управления словарями" (даже не заморачиваясь разницей между vocabulary и dictionary). Мы же будем понимать, что всё это по факту может оказаться одним и тем же.

Конечно, есть и множество других слов, описывающих всё то же самое. Например, "корпоративные словарные сервисы" для "контролируемой терминологии" (https://wiki.nci.nih.gov/display/COREtraining/1030+Introduction+to+Enterprise+Vocabulary+Services+%28EVS%29), при описании которых видим в том числе и тезаурусы, и онтологии, и много чего ещё...

3. Стандарты представления терминологической информации
Стандарты представления словарей/тезаурусов/онтологий, тем не менее, существенно различаются и их поддержка поэтому требует существенно различных реализаций.

Самый простой (намеренно простой, он слово "простой" содержит в своём названии) и распространённый стандарт -- трехлетней давности SKOS, Simple Knowledge Organization System (http://www.w3.org/2004/02/skos/, утверждён в августе 2009г.). Он был разработан как раз с учётом терминологической неразберихи со словарями-таксономиями-тезаурусами, а также попытками приплести сюда и онтологии (http://www.w3.org/TR/skos-reference/):
In the library and information sciences, a long and distinguished heritage is devoted to developing tools for organizing large collections of objects such as books or museum artifacts. These tools are known generally as "knowledge organization systems" (KOS) or sometimes as "controlled structured vocabularies". Several similar yet distinct traditions have emerged over time, each supported by a community of practice and set of agreed standards. Different families of knowledge organization systems, including thesauri, classification schemes, subject heading systems, and taxonomies are widely recognized and applied in both modern and traditional information systems. In practice it can be hard to draw an absolute distinction between thesauri and classification schemes or taxonomies, although some properties can be used to broadly characterize these different families (see e.g., [BS8723-3]). The important point for SKOS is that, in addition to their unique features, each of these families shares much in common, and can often be used in similar ways [SKOS-UCR]. However, there is currently no widely deployed standard for representing these knowledge organization systems as data and exchanging them between computer systems. [и далее говорится, что SKOS как раз и будет таким стандартом]
Другим крайним случаем является "непростой" стандарт представления 4D онтологий ISO 15926 (оцените сложность: http://dot15926.livejournal.com/27293.html), авторы которого всё время подчёркивают его изначальную направленность на создание словарей (vocabulary), и часть 4 которого называется "таксономия". Есть и промежуточный по сложности стандарт OMG SBVR, Semantics of Business Vocabulary and Business Rules (http://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_Rules), в котором 90% посвящено как раз словарям/онтологиям, и только 10% нормам деятельности -- ибо эти нормы формулируются как раз с использованием чётко определенных словарём/онтологией значений. Чуть-чуть сравнения ISO 15926, SKOS и SBVR можно найти в комментах тут: http://levenchuk.com/2009/11/27/vocabularies-in-iso-15926-we-can-use-sbvr/ (ох, как мало три года назад мы ещё понимали в этих семантических паутинах, да и самом ISO 15926...).

Конечно, есть ещё огромное число специфически терминологических международных, национальных и отраслевых стандартов представления глоссариев/словарей, но они по сравнению с упомянутыми ISO 15926, SKOS и SBVR имеют уже больше историческое и надзорное (помянуты в каких-то отраслевых регулятивах) значение, нежели интересны для практических нужд. Все эти допотопные стандарты были сделаны до середины 90-х, когда ещё не было интернета, и важность наличия URI для термина никто ещё не понимал.

4. Какой есть софт для терминологической работы
Софта, как водится, море разливанное -- но, как и в случае любых PLM и САПР, каждая из софтин управления терминологией предполагает связку с вполне определёнными программами лингвистической работы.

Одним из лидеров, например, является PoolParty Thesaurus Manager (http://poolparty.biz/products/poolparty-thesaurus-manager/), который идёт в связке с другими лингвистическими программами. Эта программа хвастается поддержкой SKOS и тесной интеграцией с другими продуктами серии PoolParty. Вышедшая в июне 2012 версия 3.1 (http://poolparty.biz/poolparty-thesaurus-manager-ppt-3-1-0-released/) интегрирована с dbpedia (http://dbpedia.org -- структурированная информация, вытянутая из Википедии), а также поддерживает новенький европейский стандарт метаданных "семантических активов "ADMS (Asset Description Metadata Schema, http://joinup.ec.europa.eu/asset/adms/home). Как и любые PLM, обеспечивающие жизненный цикл терминологии системы вынуждены понимать огромное количество форматов данных вокруг себя, это больше интеграционные решения вокруг системы управления конфигурацией и изменениями.

Чтобы оценить, насколько системы "ручного ведения терминологии" отличаются от автоматизированных (где терминология "экстрагируется" из какого-то корпуса текстов), можно рассмотреть DBpedia -- это база знаний, в которой описано сейчас 3.77 миллиона вещей, из которых 2.35млн. представлено в виде более-менее организованной онтологии. Информация в DBpedia попадает из Википедии через софт "экстрактора" (http://wiki.dbpedia.org/Documentation), а затем раздаётся в разных форматах (http://wiki.dbpedia.org/Architecture?v=14cg). Конечно, есть аналогичные коммерческие решения, типа связки вики Сonfluence и PoolParty PowerTagging (http://poolparty.biz/products/poolparty-powertagging/), причём найденная структурированная терминологическая информация не просто становится доступной "сбоку", но сразу может быть использована для семантического поиска (учёт синонимов), или для обогащения контента (автоматическая простановка тегов). В принципе, можно пробовать завести "корпоративную википедию" и вести её по правилам Википедии, а затем экстрагировать из неё онтологию/тезаурус так же, как это делают в Dbpedia -- но нужно понимать всю громоздкость такого решения.

Вот ещё один знаменитый игрок на рынке корпоративных терминологий: TopBraid Enterprise Vocabulary Net (TopBraid EVN, http://www.topquadrant.com/solutions/ent_vocab_net.html). В отличие от PoolParty упор тут делается не просто на поддержку SKOS, а полномасштабную интеграцию разных глоссариев с разными "входными" моделями данных. Внутри, понятное дело, "родной семантический веб".

Если отойти от внутреннего представления, особо близкого к SKOS, и требовать только "экспорта в SKOS" (SKOS Outside), то тут же появляются разные другие мощные игроки -- вот, например, коммерческий http://www.mondeca.com/Products/ITM/ITM-feature-summary, опенсорный http://www.vocabularyserver.com/ (огромное количество фич, даром что опенсорсный -- pun intended), http://www.dataharmony.com/products/thesaurus_master.html (если кому особо нужна поддержка старинных стандартов работы с тезаурусами -- monoligual ISO 2788, multilingual ISO 5964, а также NISO Z39.19), http://www.semafora-systems.com/en/solutions/semanticxpress/, http://interverbumtech.com/Products/TermWeb.aspx и огромное количество других "веб" и "настольных" приложений, которые легко находятся Гуглём...

Есть и крайний вариант -- наваять что-то своё из какой-нибудь онтологической вики типа http://ontowiki.net или http://www.semantic-mediawiki.org/ (например, так как в LexWiki Distributed Terminology Development Platform -- http://informatics.mayo.edu/vkcdemo/lexwiki1/index.php/Main_Page), или http://www.smwplus.net/index.php/Benefits/terminologists.

Ну, и есть онлайн решения: можно просто купить за десять долларов в месяц (http://www.termwiki.com/About_TermWiki_Pro -- это платный вариант для http://www.termwiki.com), или http://www.termbases.eu/page/view/pricing/, или новенький (с подпиской на бета-версию) http://www.nomigy.ca/en.
2019

Лингвистика в инженерной компании: наш путь

Для чего в инженерных компаниях пытаются использовать лингвистические технологии? Да для самого разного! Так что нам изо всех возможных применений нужно выделить какое-то одно. Я думаю, что стоит заняться извлечением из текстов формальных инженерных моделей, пригодных для обработки в CAD/PLM. Извлечение данных в соответствии с какой-то определенной моделью данных из текстов на естественном языке в лингвистике называется извлечением информации (information extraction), иногда особо выделяя темы добычи из текстов (text mining, оно же -- "раскопки текста", "глубинный анализ текста") и fact extraction (извлечение актуальных фактов, в отличие от извлечения общих знаний и закономерностей). Вот цветастенькие слайды с объяснениями "на пальцах": http://suchanek.name/work/teaching/IE2011a.pdf. Вот более формальный обзор: http://osm.cs.byu.edu/CS652s09/papers/Sarawagi.ieSurvey.pdf. Остальное легко нагуглить, выучив встречающиеся в этих обзорах ключевые слова.

Нам нужно вытаскивать из текстов инженерные модели, которые затем будут обрабатываться в конкретном САПР. Идеально-утопический вариант -- делать это сразу в языке программирования этого САПР, вытаскивая информацию в тамошние типы данных. Но тут сразу две засады:
1. информация всё равно будет храниться в объектной базе данных (часто это даже не база данных САПР, а база данных PLM). Модель данных базы данных CAD/PLM не эквивалентна модели данных языка программирования САПР.
2. одна и та же извлеченная информация может затем использоваться многократно, в самых разных САПР, а храниться в самых разных PLM.

То есть информацию правильно извлекать из текста не сразу в типы языка программирования, использованного в PLM/CAD системе, а либо в модели данных объектной базы данных CAD/PLM (сдаться какому-то вендору САПР с потрохами), либо в модели данных "общесапровского общеинженерного" формата.

Общесапровскую "резиновую" (то есть гарантированно закрывающих любую клиентскую кастомизацию инженерных данных, обрабатываемых CAD/PLM разных вендоров) я знаю только одну модель данных: это ISO 15926. Тем самым извлечение информации из текстов должно производиться в формат ISO 15926, из которого далее хорошо разработанными в тусовке ISO 15926 средствами архитектуры IRING (ISO 15926 outside) мэппиться в модель данных конкретной CAD/PLM системы, а затем уж использоваться внутри языка программирования этой системы в привычных для computer science системе типов языка программирования -- но этот последний вопрос мэппинга из "родной" для конкретной CAD/PLM системы объектной базы данных в типы языка программирования этой системы решается для каждой CAD/PLM системы её разработчиками.

Теперь можно сформулировать наш подход к лингвистике:
1. Нас интересует классическое извлечение онтологии из текста (это традиционная для лингвистов задача, обсуждается во всех учебниках).
2. Нас интересует извлечение не любой ad hoc онтологии (что у лингвистов часто), не онтологии semantic web (что не менее часто), а ISO 15926 онтологии.
3. Мы готовы предложить пошаговую процедуру для этого извлечения онтологии: распознавание паттернов шаблонов ISO 15926 по штучке за раз -- медленно повышая процент распознавания каждого отдельного паттерна, добиваясь роста precision (числа верно распознанных) и recall (числа всех найденных) до величин, сравнимых с ручным распознаванием.

Поскольку в самом ISO 15926 есть много вариантов (семантическая сетка части 2, шаблоны, паттерны шаблонов, OIMs, Gellish-подобные форматы и т.д.), то возможны самые разные варианты технологии -- над этим нужно будет ещё думать. Но в целом предлагается вытаскивать из инженерных текстов паттерны шаблонов ISO 15926 -- постепенно наращивая точность вытаскивания каждого паттерна и число вытаскиваемых паттернов. Дополнительный бонус: стандартный формат вытаскиваемой онтологии позволит сравнивать результаты работы разных лингвистических технологий над одними и теми же текстами. Ещё один бонус: если текст по-настоящему мутен, то его будут плохо понимать и компьютеры, и люди -- и мутные тексты можно будет просить переписать, это будет "машинный контроль качества".

Вытаскиваемые инженерные модели будут использоваться главным образом с использованием деонтической модальности (указаний на долженствование), что соответствует использованию в качестве требований технических заданий, стандартов, регламентов. Если удастся извлечь формальную модель инженерной системы из этих текстов-требований (возможно, эти требования будут разбросаны по многим текстам, явно или неявно ссылающихся друг на друга), то можно будет пробовать найти противоречия или подтвердить непротиворечивость этой модели с моделями, которые содержатся в CAD/PLM. Но это уже следующий шаг: для начала нужно научиться вытаскивать из текстов модели, совместимые с CAD/PLM представлениями, и только потом проводить анализ противоречивости.

Такая постановка задачи вытаскивания из текстов информации, осмысленной для CAD-программ, отличается от задачи вытаскивания из текстов информации, осмысленной для людей (т.е. совместимой с представлениями инженеров, а не предвзято компьютер-ориентированными представлениями программистов CAD/PLM). То есть вытаскиваемое должно верифицироваться не на соответствие теориям когнитивной науки (http://ailev.livejournal.com/1007293.html -- все эти "теории прототипов" и прочие попытки найти адекватные технические/контринтуитивные теории того, как представлено знание в мозгах у инженеров, чтобы затем извлекать из текстов формальные структуры, понятные самим инженерам), а на соответствие моделям данных, которые можно легко засунуть в CAD/PLM системы. И сама "лёгкость" засовывания в CAD/PLM может определяться самыми разными причинами -- например, наличием развитого инструментария мэппинга данных. Ибо CAD/PLM, основанных на теории прототипов, или теории теорий (или основанных любых других теориях представления понятий, которыми занимается когнитивная наука) пока не наблюдается. Сейчас нет CAD/PLM даже с логическим представлением информации, а есть только с объект-атрибутной моделью данных, так что "интеллектуальные изыски" просто некуда будет передать для обработки. Что, конечно, не мешает в фоновом режиме думать на тему о сегодняшней цепочке искажений по выражению человечьих инженерных мыслей средствами моделей данных CAD/PLM, а затем попыткам обрабатывать задокументированные в объектных базах данных инженерные данные средствами современных мультипарадигмальных языков программирования, на которых написаны CAD/PLM.
2019

Корпусная инженерия

В языкознании (так по-старинке у нас кличут linguistics) есть корпусная лингвистика (corpus linguistics): дисциплина, занимающаяся изучением наборов текстов с какими-то предзаданными характеристиками (например, "типичные транскрипты чатов 2004г.", "художественная проза XIX века", "милицейские протоколы лета 1993г.", "современные богослужебные тексты" и т.д.). Фишка в том, что эти наборы текстов тщательно отбирают, затем тщательно размечают (отмечают части речи, иногда делают более-менее полный разбор предложений -- кто во что горазд. Разметка проводится когда машинно, когда вручную, вычищая потом ошибки всем миром), а потом их используют для самых разных исследований и тестирования софта. И поскольку содержание этих корпусов (множественное число от corpus -- corpora) хорошо известно, то становится возможным как обучать и отлаживать алгоритмы работы с текстами на этих корпусах, так и сравнивать их. Про учебные (например, чтобы найти тексты, максимально охватывающие наиболее часто встречающиеся слова в какой-то предметной области -- и потом гарантировать ученикам освоение "словарного минимума") применения пока умолчим, но их тоже множество (обзорчик: http://www.corpus4u.org/forum/upload/forum/2005081523415585.pdf). Также корпусы используются для составления словарей (как в части "какие слова бывают", так и в части "примеры использования"). Ну, и для тестирования вполне определенных алгоритмов (например, алгоритмов сжатия: http://corpus.canterbury.ac.nz/).

Создание корпуса -- очень затратное и тяжёлое дело, больше всего похожее на создание стандарта, и поэтому занимаются созданием корпусов главным образом консорциумы. Пример такого консорциума -- Linguistic Data Consortium (http://www.ldc.upenn.edu/). Вот, например, один из тамошних продуктов: телефонные разговоры на русском (http://www.ldc.upenn.edu/Catalog/CatalogEntry.jsp?catalogId=LDC2006S34), можно купить по сходной цене $1000. И это даже не тексты, а записи речи (.wav-файлы). Так, если вы делаете распознавалку русской речи, то вас могут попросить протестировать её на этих данных. Это очень удобно: результаты будут много более объективны, нежели тестирование на собственных данных, да ещё и можно будет посравнивать с результатами других распознавалок.

Но не всё в мире корпусов так дорого, многое доступно бесплатно.

Вот Национальный корпус русского языка, объемом 364млн. словоупотреблений, плюс еще церковнославянский корпус на 4.7млн. словоупотреблений -- http://ruscorpora.ru/. Конечно, для такого огромного собрания текстов копирайтные проблемы весьма суровы, и статус нашего Национального корпуса пока неопределён. И отдельные корпусы получить сейчас нельзя. Но консорциум для поддержания Национального корпуса русского языка в организационной стадии, и ситуация с бесплатной раздачей его отдельных наборов данных постепенно наладится.

Адаптеры доступа к основным корпусам текстов есть практически во всех лингвистических платформах (frameworks: GATE, UIMA) и библиотеках (NLTK и т.д. -- поглядите, например, как корпуса используются для обучения студентов лингвистике с помощью NLTK: https://sites.google.com/site/naturallanguagetoolkit/book).

Этот же корпусной подход применяется и для кодов, прежде всего программных текстов. Если собрать в одном месте много-много разных текстов программ, то их потом можно долго и плодотворно изучать: http://qualitascorpus.com/pubs/QualitasCorpusAPSEC2010.pdf. Вот, например, попытка изучить "синтаксическую избыточность" кодов на C, C++ и Java с использованием исходных кодов 6000 разных проектов из sourceforge: http://www.utdallas.edu/~mgg110030/publications/papers/fse10.pdf

Основная мысль этого моего поста -- это необходимость собирать инженерные корпуса: технические стандарты, проекты, регламенты работы. И инженерный софт (который никогда не работает в одиночку) исследовать и проверять на этих корпусах, а студентов на этих корпусах учить.

Тут огромное число содержательных проблем, и только маленькая часть из них связана с организационными вопросами, финансированием работ, злобными копирайтами на данные инженерных моделей и проектов (я ведь не имею ввиду коды инженерного софта, меня интересуют тексты и коды, описывающие целевые системы инжиниринговых компаний, а также тексты и коды, описывающие сами компании -- в рамках организационной инженерии).

Так, огромное число инженерных данных существуют только в проприетарных форматах соответствующих САПР (ну, и часть информации доступна в форматах соответствующих PLM). Как хранить: оригинальные файлы? Выгруженную маленькую часть из наличных данных (например, в нейтральных форматах представлении геометрии)? Что делать с дополнениями данных, неизбежных для каждой конкретной организации ("настройки": например, P&ID с настройками, с использованием какой-то определённой системы идентификации) -- ибо без справочных данных невозможно прочесть данные проекта? Что делать, если массово используются ссылки на данные в других информационных системах (каталогах, PLM)? Что делать, ежели часть информации присутствует не в инженерных данных, а в коде софта -- и результирующая информация доступна только на чертежах (куда часть надписей приходит из данных, а часть -- из кода софта)? Что делать, если проект доступен не в одном формате данных, а сразу в десятке (не в том смысле, как "формат .doc и .txt для текстов", а в смысле "формат представления 3D геометрии и формат плана производства работ"-- для разных инженерных специальностей)?

Многие из этих вопросов в том или ином виде существовали и для лингвистических корпусов, и для корпусов исходных кодов софта. Но в случае зоопарка инженерных данных и справочных данных инжиниринговой компании заимствовать эти решения невозможно, разве что если собирать полнотекстовые документы только: регламенты и стандарты. Но в инженерных регламентах и стандартах будут таблицы, картинки, ссылки на элементы картинок и таблиц в тексте -- поэтому и тут придётся что-то придумывать.

Но без стабильных наборов данных -- корпусов -- нельзя отлаживаться, в том числе нельзя сравнивать работу разных программ с этими данными. Это шаг к стандартизации. Да, я знаю про "стандартизацию квадратных колёс" и последующую индустрию производства рельсов, совместимых с этими квадратными колёсами. Но стандартизация даже квадратных колёс обычно ведёт к бурному развитию рынка. Кстати, а почему "лучшие решения" с круглыми колёсами регулярно проигрывают? Почему люди готовы изготавливать рельсы для квадратных колёс, но что им мешает массово изготавливать рельсы для круглых колёс?! Наличие корпусов данных, наглядно демонстрирующих преимущество круглых колёс и рельсов для них перед простыми в изготовлении квадратными и рельсами для них, сильно бы помогло.

Нужны свободные инженерные данные. В количестве. Доступные всем разработчикам инженерного софта. Нужна не только корпусная лингвистика, но и корпусная инженерия.

Чем и займёмся.
2019

Сергей Чебанов о рефренности мира и не только

Сергей Викторович Чебанов (доктор биологических и филологических наук -- что, собственно, и интересно), популярное изложение:
-- о рефрености мира (лекция в Полит.ру, 2009г.) -- http://www.polit.ru/article/2009/11/26/chebanov/
-- о биосемиотике (с Александром Гордоном в передаче «0:30» на НТВ) -- http://ralimurad.narod.ru/lib/gordon/biosemiotica/index.html
-- из истории типологических представлений (статья в "Прикладной и структурной лингвистике", 2008г.) -- http://www.rpri.ru/arshinov/materials/4ebanov/iz%20historii.html
-- диссертация "Логико-семиотические основания классификаций в лингвистике" -- http://www.textreferat.com/referat-7365.html

Тут не удержусь, и процитирую кусочек (http://www.textreferat.com/referat-7365-16.html):
встает вопрос об основаниях классификации классификаций. Следуя идее А.А.Шарова, по способу соотнесения архетипа и таксона можно наметить следующие основания классификации классификаций:

1) Рефлектированность таксономии и мерономии (естественный язык – целевые классификации – классификации как предмет рефлексии);

2) Богатство архетипа (одно-, несколько-, многопараметрические, непараметрические);

3) Содержательность (интенсиональности – экстенсиональности);

4) Уникальность объектов (инвариантные, популятивные, уникальные);

5) Равноценность / неравноценность и природа неравноценности признаков (признаки равноценные онтологически и/или для задачи, неравноценные онтологически и/или для задачи);

6) Признание существования привилегированных классов признаков (индивидуальных и коллективных, актуальных и потенциальных, объекта и среды, временных и вневременных, относимых к состоянию и процессу, разным сторонам организации, к одной или многим сторонам организации);

7) Природа таксонов (классы, размытые множества, множества, армады, популяции);

8) Тип корреспонденции архетипа (иерархические, древовидные, комбинативные);

9) Соотношение таксонов (разбиения, перекрывания, скопления, созвездия);

1О) Исчерпание универсума (целый универсум и его части);

11) Открытие в эмпирии или задание в теории;

12) Близость (как сходство и как порождение одним преобразованием эмпирически данным или теоретически введенным);

13) Язык описания (от математики до поэзии).

Лингвистика обычно "работает" с малорефлектированными, малопараметрическими, достаточно высоко экстенсиональными, популятивными, с онтологически разноценными актуальными признаками, синхронными, объектными, организованными как размытые множества и классы, иерархическими, типа созвездия, частными, открытыми, сходственными группировками с описаниями таксонов, выполненными на естественном языке.

Наиболее интересные группирования в лингвистике отрефлектированные, параметрические, интенсиональные, построены на семантических инвариантах (в смысле Р.Якобсона), с неравноценными признаками, выполнены на формализованном языке.
Восторг.
2019

Проблема перевода для киборгов, компиляции для людей

Для человечьей речи используется слово "перевод" -- при этом лингвистическая традиция уклончива относительно того, является ли порождаемый текст программой (про которую можно говорить в терминах "выполнения" -- вся традиция обсуждения речевых актов -- обещания, просьбы, согласия и отказы, по большому счёту именно про аспект "выполнения". Можно говорить про заход со стороны "нейролингвистического программирования", который вообще про исполнение программ бессознательным. В общем, есть над чем подумать, если задаваться вопросом, что именно за текст переводится), или просто декларациями (которые нужно "понимать", то есть исполнять с ними какие-то действия собственного ума, не порождающие видимых внешних деятельных эффектов).

Для разговора с компьютерами используется слово "компиляция" -- опять же, с многочисленными вариантами (та же "трансляция" это ведь "ихний перевод", как и "наши баксы -- это ведь ихние доллары!").

Если вам нужно перевести или откомпилировать данные (про которые непонятно, как их "исполнять"), то ни "перевести" ни "компилировать" не используется. Говорят только про "мэппинг" (соотнесение одних данных с другими).

Впрочем, и про выполнение тоже много разных слов. Выполнение одних текстов называют "исполнением", других -- "оценкой", третьих -- "выводом", четвертых -- "моделированием", и т.д.


Тут у меня несколько соображений.

1. Онтологизирование, моделирование, программирование, синтез текстов на естественном языке -- это одно.

2. Задача перевода онтологий, моделей, программ и текстов на естественном языке -- это одна и та же задача (а поскольку мы стремительно входим в эпоху мультипарадигмальности, то разные типы "выполнений" нужно признать таковыми, при всём уважении к специализациям типа reasoning или "я просто выполнял приказ"). Есть и множество других похожих задач (например, задача поиска -- это тоже перевод текста вопроса в развернутый текст ответа. Отчёт по базам данных -- перевод текста базы данных и поискового запроса в текст отчёта. Ну, и так далее).

3. Нужно срочно строить онтологию, в терминах которой можно все эти тексты-данные-программы с их исполнениями и переводами можно обсуждать. Меня в нежном программистском детстве учили, что "компиляция -- это такое особое исполнение. Процессор читает текст, и строит в соответствии с этим текстом какой-то другой текст -- выходной, будь то результат традиционного исполнения программы, или результат нетрадиционного исполнения -- откомпилированный входной текст". Такая онтология должна быть основана на лучших известных, контринтуитивных, а не расхожих идеях -- revisionary, а не descriptive (мы ведь ревизионисты, чего и не скрываем -- см. пункт 1 http://ailev.livejournal.com/521610.html, это еще 2007г.. Я, кстати, с тех пор определился -- я ревизионист "справа", конечно. Моя онтология будет радикальной, а в "народную онтологию" я буду мэппить -- и, скорее всего, мэппить в нее уже буду не я, а те самые "критики слева").

Если построить такую общую для разных областей информатики-логики-лингвистики онтологию, то можно пробовать:

а) перенести знания из одних областей в другие. Ибо даже спецы лингвисты и спецы логики по поводу иллокутивности имеют разные представления -- ибо им эта иллокутивность нужна для разного. Вот и нужно договориться как обозначать это разное (выполнение/вычисление в разных смыслах выполнителями/решателями разных видов, перевод с одного языка на другой -- включая "понимание" как перевод с чужого языка на свой собственный с попутным пополнением своего словаря и belief revision, и т.д.). После этого "мэппирования" (перевода, компиляции и т.д.) может появиться идея, как проблемы одной предметной области решать при помощи знаний, найденных в другой предметной области -- несмотря, что формулировки этих проблем и знаний даны в разной терминологии, и сообщества экспертов в этих предметных областях никогда не пересекаются.

б) найти более компактные способы описания многообразия информатики, и за счёт повторноиспользуемости (например, выноса общего для всех этих областей на мета-уровень. Или прописывании операций, которые применимы ко многим типам их операндов) можно резко поднять компактность описания. Алан Кей любит говорить об этом, как "найти тут математику". В других дисциплинах говорят о паттернах, эвристиках, логиках -- неважно, важна цель компактификации знания, чтобы знание принципов освобождало от знания мириадов фактов.

в) учить людей ("компиляции знаний в мозговой код") по времени меньше, а давать знаний больше, как раз за счет компактизации описания многообразия информатики. Я глубоко благодарен Гарегину Карапетовичу Тер-Григорянцу, который когда-то давным-давно в исследовательском ВЦ РГУ учил меня разнообразию вариантов, как можно исполнить одну и ту же программу (макрокомпилировать в машинный код, компилировать традиционно, интерпретировать спецпроцессором именно этого языка -- и т.д., причём всё это на большом стеке языков/выполнителей, включая микропрограммный уровень процессора -- ибо на тогдашних EC ЭВМ уровень микропрограмм был вполне себе еще одним уровнем программирования выполнителя исходной программы), не забывая подсовывать программы с существенной декларативной компонентой и объясняя, что вся эта "декларативность" должна обсуждаться не в связи с текстом программы, а в связи со свойствами ее выполнителя. Мне это до сих пор помогает соображать быстрее в сложных архитектурных ситуациях.

г) переходить от бесплодных споров про "всё должно описываться логическими языками", против "всё должно моделироваться, и потом только будем говорить о коде", против "всё равно естественный язык никто не отменял", против "придётся тяжело вздохнуть и написать программу на универсальном языке программирования", и т.д., к работе с аккуратным представлением мира в виде какого-то текста (программы ли, данных ли, семантической сети ли, набора полнотекстовых документов и данных ли -- это уже будет вопрос второй, и ответом тут может быть -- представлений множество!), с работой над этим текстом множества специализированных выполнителей (опять же -- агентов ли, или просто "спецпроцессоров", или "решателей" -- это вопрос третий). Главное, чтобы не было зацикливания на какой-то моноархитектуре одной из дисциплин, одной терминологии, одной области знаний.

Что мы делаем в этом направлении?

1. регулярно думаем, что уже немало. Пытаемся общаться с командами, представляющими разные парадигмы (например, вот наши попытки общения с computational ontologists -- см. мои мартовские письма в списке рассылки Ontology Summit 2012: http://ontolog.cim3.net/forum/ontology-summit/2012-03/index.html, или разговоры с лингвистами -- http://incose-ru.livejournal.com/32524.html, или разговоры с логиками про "интеракцию" -- http://minski-gaon.livejournal.com/26627.html?thread=362755#t362755 и http://ailev.livejournal.com/915253.html, а последний раз я на заседании логико-философского кружка в ВШЭ, где обсуждалось логическое моделирование текстов был буквально вчера).

2. Разрабатываем методики работы и поддерживающий их софт, отражающий эти идеи общности программистского, моделирующего, онтологического подходов (dot15926 -- это как раз оно). Надеюсь, общность с лингвистическим мы к этому компоту добавим уже в очень скором времени.

3. Пишем такие постинги, как этот -- чтобы в какой-то момент обнаружить, что и слова правильные уже найдены и собраны в одном месте, и объяснение целей нашего поиска сформулировано и записано, и потенциальные партнёры прочли, что-то поняли, и готовы помогать.
2019

Смычка лингвистики и онтологии

Вчера на заседании Русского отделения INCOSE разбирались с технологией автоматического анализа и перевода текстов Compreno фирмы ABBYY -- http://incose-ru.livejournal.com/32524.html.

Докладчики предложили схемку, в которой видно, что в описании ситуации прежде всего приходится разбираться с синтаксисом (лексемами), постепенно обвешивая этот синтаксис какими-то значениями (семантемами), и в конце концов привлекая знания по разделяемой собеседниками мира онтологии. Технология Compreno вплотную уже подошла к необходимости работы с онтологией. А онтологи всё больше и больше приходят к необходимости работы с синтаксисом (вспомним, например, о парсерах VivoMind и CYC). В какой-то момент лингвисты и онтологи обязаны будут встретиться, и использовать работы друг друга. Вот мы вчера по факту и провели такую встречу.

Встреча прошла с использованием материала системной инженерии: необходимости разбираться не просто с текстом-речью, как в традиционной задаче перевод, а с совокупностью текста, формул, таблиц, диаграмм в тексте, чертежей "в бумаге", набора корпуса технических стандартов (с точными определениями терминов -- уж насколько точным могли быть авторы этих определений, не будучи линвистами и онтологами), структурированной информации (проектов в CAD/CAM/CAE и PDM/PLM информационных системах). В этом случае уж точно одним синтаксисом не обойтись, но и одной онтологии не хватает.

Одна из оценок: чтобы настроить Compreno на какую-то новую предметную область (например, жаргон какой-то из инженерных дисциплин со всякими "номинальными диаметрами" и прочими нестандартными словосочетаниями), требуется примерно три месяца и 10 человек. Потом можно парсировать тексты на этом жаргоне, переводить на другие языки и использовать парсированное представление для самых разных других целей -- умного поиска, написания отчетов, ответов на вопросы, составления глоссария и т.д.

Вчера же в рассылке Ontology Summit Мэтью Вест и Джон Сова в очередной (как я понял, минимум третий) раз достигли консенсуса, что "you cannot go from language to ontology without thought in between". Так что и мы будем "думать посредине", заниматься смычкой лингвистики и онтологии. Мы пока еще никуда не опоздали, всё только начинается.
2019

Пандора.ком

Прошёл год, я повторил оплату за Pandora.com -- $36 в год не такая большая цена за удовольствие слушать на 192Kbps. По-прежнему пользуюсь http://anchorfree.com/, ибо по-прежнему Adblock Plus режет его рекламу в FireFox.

Pandora.com только хорошеет: если раньше было еще заметны повторы треков, то сейчас повторов почти нет -- а когда они случаются, то к месту.

Осознал, что в этом году из своей необъятной коллекции сидишек практически ничего не слушал. Файловая коллекция тоже почему-то не была востребована, хотя притрагивался, да. Такое впечатление, что Youtube.com и даже music.yandex.ru и то больше пользовались.

Надо диски выносить, хоть и жалко. Сегодня вот обнаружил и выкинул кучу дисков "Библиотека в кармане" (было такое развлечение десяток лет назад -- сидишки с несколькими тысячами книжек. Сегодня этой радости уже никто и не помнит). Вот и "фонотека на полке" стала таким же анахронизмом -- а еще десять лет назад казалась крутейшим прорывом человеческого интеллекта (для меня, который с детства знал, что в библиотеку даже не ходят, в библиотеке пропадают сутками ввиду невозможности выноса нужных книг из читального зала).

Чудесато живём, и уже привыкли к этому.

Когда я слушаю именно Пандору, я думаю о двух подходах к семантике: один по линии "семантики языков программирования", а второй -- "семейного сходства" по Витгенштейну, теории прототипов и разных семантических моделек из лингвистики (http://en.wikipedia.org/wiki/Semantics). И жестоко страдаю, что двигаюсь сейчас со своими "онтологиями" только по линии классической логики, игнорируя "аналогии" и прочие когнитивные архитектуры. Но нельзя объять необъятного. Поэтому будут слушать Пандору дальше -- и пусть она напоминает мне, что на логике и логическом выводе свет клином не сошелся. Ассоциации и связанные с ними "гениальные находки" и "настоящая поэзия", распознавание образов (смежное с семантической унификацией -- http://en.wikipedia.org/wiki/Semantic_unification) и многофакторный анализ (смежный с таксономиями) тоже важны. Но эта языковая сфера не менее трудна, чем логическая (где, конечно, тоже хватает своих тараканов). Давид Ян на московском TEDx в прошлом году обещал мне, что в 2010 обязательно выйдет "прорывный лингвистический продукт ABBYY", но этого так и не случилось. Но случится, не в этом году, так в следующем (хотя этот перенос года выпуска происходит уже несколько лет подряд -- вот, например, статья про этот NLC 2006г.: http://offline.computerra.ru/2006/654/287107/, а разработка ведется вообще с 1995г.).

Пока же довольствуемся результатами проекта "музыкальный геном" от пандоры.ком.