Комментарии 45
— каково значение sin(x)?
— где-то между 0 и 1 :)
это к тому, что в принципе можно получить недоопределённую семантику исходя из свойств sin
Значит, аналогия совсем хороша :)

Глагол «разбил» ни при каких условиях не совпадёт с «бегал» или «красный». У него тоже есть область допустимых значений.
да, действительно.
утро не лучшее время для математики :)
непонятно, почему тема уплыла в перевод с русского на английский.

а также формат описания семантики,
что значит
«foo BAR() baz»?
что значит «foo/bar»
почему в первом случае слева русские слова, а во втором — наоборот.
ОК, отвечу тут, если кому ещё будет непонятно:

— Тема уплыла по следующей философской причине. Мы говорим о смысле слова, о семантике. Как формально определить смысл? Объяснить одно слово через другое? Или как-либо ещё? Простейшее «понимание» смысла выражается в умении подобрать эквивалент на другом языке (тогда смысловое объяснение слова — это просто его перевод).

— Первый пример — это Ru -> En, второй — En -> Ru. Вероятно, следовало объяснить явно.

foo BAR() baz: foo — тип, BAR() — само слово (со списком возможных зависимых слов), baz — перевод.

a/b/c — класс (он же тип) слова, записанный в виде полного пути от базового класса a до наиболее конкретного класса c.
Спасибо за инересные статьи.

«иерархия объектов для конкретного синтактико-семантического анализатора зависит от двух тесно связанных вещей: (а) поставленной задачи; (б) картины мира анализируемого языка.»

А разве «картина мира», т.е. предметная область описываемых некоторым языком сущностей, не одна и та же для всех языков?
Не может оказаться так, что в долгосрочном плане такой подход «классификация в рамках языкового поля» просто увеличит объем работ в разы, но по сути бОльшая часть работ будет повторяться для всех языков?
Я не говорю, что языковая картина радикально отличается для разных языков. Естественно, существенные части иерархии будут пересекаться. Мы все живём в одном мире, у нас есть солнце, звёзды, картошка, корова и так далее.

Но есть и важные различия, о которых, в принципе, говорилось.
Например, «на»-места и «в»-места. Мы едем в город Тампере, а финн едет «на» город Тампере. Так как же быть, в какой класс включать?
По-русски можно «играть» в игру, а можно играть на музыкальном инструменте. По-фински нельзя «играть» на музыкальном инструменте, зато можно «звонить» — как по телефону. А по-русски «звонить» на инструменте нельзя…
В обсуждении первой части упоминался проект «интерсемантика». Подпадает ли этот проект под «универсальные классификации всего и вся» в Вашей статье?
Честно говоря, я не знаком с этим проектом в деталях. Но как бы то ни было, идеи «всеобщей классификации» витают в воздухе, и в том или ином виде воплощаются.

Штука в том, что цели у них, видимо, другие. Полагаю, что в «универсальной семантике» никто не будет классифицировать город по критерию «в-город» или «на-город» — это внутриязыковые игры.

Для ИИ на внеязыковом уровне это может быть полезно, но при разборе предложений конкретного языка без такой специфической инфы не обойтись.
В случае интерсемантики цели такие: «Основа идеи — перейти в технических системах от побуквенного кодирования слов текста к единому международному цифровому кодированию семантического значения, которое несёт каждое слово текста»

Я сам про этот проект узнал только из обсуждения вашей первой статьи. Упоминул потому что похоже на один мой старый проект, так что действительно «идеи… витают в воздухе».

Что касается конкретного применения для решения задачи машинного перевода, то тут, насколько я понимаю, на сегодняшний день преобладет использование в прикладных проектах именно подхода «классификация в рамках языкового поля». Т.е строится семантически обоснованные отображения типа RU->EN, EN->RU, RU->DE и т.д. Для каждой пары языков по 2 отображения.

Если отображать не один язык в другой а в некий универсальный семантический классификатор RU->UNI, UNI->RU, т.е. для каждого языка по 2 отображения.

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

Это я к тому, что напрасно Вы так скептически настроены к универсальному подходу. В каждом подходе свои плюсы и минусы.
Этот подход понятен, и широко используется в компиляторах языков программирования. Многие фриварные компиляторы (GNAT, например) не заморачивается генерацией машинного кода, вместо этого текст на исходном языке (в данном случае на Аде) транслируется в эквивалент на С, а далее вызывается GCC.

То есть выгоды его абсолютно очевидны. Мой скепсис связан не с непониманием выгод, а с неверием в принципиальную возможность создания «универсального классификатора» применительно к задаче перевода.

Как говорил Сепир, «Миры, в которых живут различные общества, — это разные миры, а вовсе не один и тот же мир с различными навешанными на него ярлыками».
Нуууу… вот смотрите, докажем теорему «существует принципиальная возможность создания универсального классификатора»: обозначим каждое уникальное семантическое значение (смысл) X некоторым уникальным числом x. Поскольку множество семантических значений ограничено, мы справимся с этим делом в ограниченное время :)
С этим сложно спорить. Есть семантическая единица «корова», и на неё можно навесить идентификатор, согласен.

Есть ситуации посложнее. Например, семантическая единица «разбивать»: в английском понимании нужно 10 идентификаторов, соответствующих различным «разбиваниям». В других языках будут другие деления — где-то на 5, а где-то на 20. Стало быть, надо перечислять все логические единицы, которые хотя бы в теории могут описываться разными словами — в любом земном языке.

А хуже всего то, что придётся всё равно создавать отдельную систему для данного языка, которая решает специфические для языка проблемы. В универсальном классификаторе для всех языков не может быть информации о том, что мы едем «на Кипр», но «в Москву». Стало быть, эта информация (на/в) должна храниться где-то в другом месте. И так для каждого слова :)
>Есть ситуации посложнее.

Так в вашем примере слово «разбивать» это же не семантическая (смысловая) единица. Это слово многозначное, т.е. одно слово обозначает несколько разных семантических единиц. А решать проблему неоднозначных слов придется по любому, какой бы метод Вы не выбрали, потому что когда делается перевод RU->EN, нужно:
1. понять смысл(!) слова на языке RU (т.е. отобразить слово в его смысл)
2. подобрать подходящее по смыслу(!) слово в языке EN (т.е. отобразить смысл в обозначающее его слово )
а в обеих шагах 1 и 2 могут встретиться многозначные слова.

Кстати тут видно насколько проще работать с «универсальным классификатором», ведь при отображении RU->UNI, UNI->RU по крайней мере со стороны UNI имеется однозначность. А в случае RU->EN, EN->RU неоднозначность может возникать с обеих сторон и отображение получается «много значений ко многим значениям», что значительно сложнее.

А сущностей в любом языке одинаковое количество. Иначе как бы люди вообще могли общаться :)

>А хуже всего то, что придётся всё равно создавать отдельную систему для данного языка

Ну почему же хуже всего? Отдельную систему для каждого языка придется создавать по-любому. Только в «универсальном» случае правила создавать проще. Т.е у вас в грамматике вместо

RU->EN: РАЗБИВАТЬ(субъект, объект: посуда) to break

будет написано, например:

RU->UNI: РАЗБИВАТЬ(субъект, объект: посуда) 356748 (и тут уже никакая неоднозначность невозможна)

Ага! А вот теперь попробуйте непредвзято определить количество смыслов в слове «разбить» :))
По-моему, задача эта ну очень сложна — то есть формально да, её можно «потянуть», но на практике… очень тяжко.

Вот смотрите, известно, что в эскимосских языках есть порядка 20 слов для обозначения снега. Это понятно, вся жизнь у них на снегу проходит. В русском это всё упирается в «снег». Внимание, вопрос: каким титаном мысли надо быть, чтобы заблаговременно в «универсальном семантическом словаре» описать 20 сущностей для снега? И так во всём…

А вот с примером «разбивать» вы слегка хитрите: что такое разбивать(субъект, объект: посуда)? Какая такая «посуда» — это класс из универсального или русского классификатора? Если второе, получается, что для русского всё равно создаётся своя классификация, «параллельная» универсальной.
Нет, я не хитрю.
Я просто взял Ваш пример где в некоторой грамматике (для меня в данном случае совершенно не важно в какой) описывается отображение одного русского слова (РАЗБИВАТЬ) в английское слово (break). Я взял Ваш пример и вместо отображения в английское слово, отобразил в универсаьлный код 356748, который (предположим) обозначает «разбивать, разломать на части, ударом превратить целое в набор обломков и т.п.» Под кодом 356748 однозначно понимается некое действие, которое в разных языках будет обозначено разными словами, но если Вы или англичанин увидите как разбивают чашку, то оба поймете о чем речь и в следующий раз можете прямо сказать друг другу «356748 78968» [=разбить чашку] при этом вы поймете друг друга однозначно:)

А оценить количество смыслов в слове «разбить» несложно — в толковом словаре они перечислены.
Нет, погодите, вы переводите не русское слово «разбивать» в 356748, вы переводите «разбивать» именно в контексте «разбивать посуду».

А откуда парсер знает, что в фразе «разбить чашку» слово «чашка» относится к посуде? Он должен либо лезть в гипотетический универсальный классификатор (напомню, разработанный титанами мысли, знающими, что за «снегом» скрывается 20 семантических едениц), либо в классификатор для русского.

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

Да и если бы эскимосы и вправду обнаружили 20 разных сущностей, скрытых для нас под словом «снег», например типы снега отличались бы химическим составом примесей, я не вижу в этом совсем никакой проблемы — новые сущности добавляются в классификатор и все.

Вы представляете дело так, что универсальный классификатор создать сложнее русского классификатора. Но почему? Нам нужно где-то раздобыть информацию что «чашка — это посуда», верно? Разве есть принципиальная разница, будет эта информация сохранена на русском в виде, например «чашка < — посуда» или в универсальном виде «78968 < — 1095524»?

Зато в универсальном виде это нужно сдалать один раз для всех языков, и парсер уже сможет пользоваться этой информацией. Конечно останутся особенности конкретных языков, но бОльшая часть работы уже будет содержаться в универсальном классификаторе, а парсеру останется позаботиться только об особенностях именно этого языка, не отвлекаясь на общие факты.
1) не-не-не, в том и дело, что это не синонимы, это действительно разный снег, который мы бы стали называть разными атрибутами: снег такой, снег сякой… вы же не будете говорить, что синий и голубой — это один цвет лишь на том основании, что в английском есть только слово blue?

2) Ага, значит, чашка — посуда — это для универсального классификатора! А теперь смотрите:
ПОЕХАЛ НА (объект: на-место) // Украина, Кипр, дача, острова
ПОЕХАЛ В (объект: в-место) // Москва, Япония, гостиница

Возникает вопрос: у класса «место» есть два подкласса: «в-место» и «на-место». И эта особенность ТОЛЬКО русского языка. Значит, придётся писать какие-то подклассы, специфичные для данного языка.

В общем, с моей стороны резюме такое: я в принципе не утверждаю невозможность такого классификатора. Просто считаю долгом перечислить его проблемы, которые, как мне кажется, сильно портят жизнь, и мне кажется, что работать над ним (а далее и С ним) будет весьма непросто, хотя ничего невозможного и вправду нет.
1) прекрасно, если есть разница между этими 20 словами по существу, то в русском эта разница будет передаваться просто уточняющими прилагательными скорее всего (типа «талый снег») вот и на уровне УК достаточно действовать так же, тут я соглашусь с мнением Oknavrin.

2) А зачем УК знать об этих особенностях русского языка? Эти особенности должен знать транслятор универсального кода в русский язык и обратный транслятор русского в универсальный код. Это как раз то о чем я писал — особенности конкретных языков. А УК будет просто знать что объект переместился в какое-то место. А уже при трансляции с/на русский эти особенности «в/на» будут учитываться. Так что имеем более менее четкое распределение обязанностей.

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

про синий и голубой. очень просто, делаем так:

объявляем цвет en:blue[as en:color] общим классом для двух русских классов ru: синий[as en:color] иru: голубой[as en:color].

здесь en:blue[as en:color] — это обозначение конкретного смысла слова синий, а не само слово.
смыслы в разных языках могут быть и более сложно соответствовать друг другу, есть понятие, «сужение смысла» и «расширение смысла».
тем не менее, если в базе присутствуют элементарные смыслы, то «семантическая свёртка» + оптимальная «семантическая развёртка»
дадут подходящее для данного языка слово или выражение.
уточню ещё раз мои термины.
семантическая свёртка = преобразование языкоспецифичного понятия в общее понятие + набор атрибутов.
семантическая развёртка = одно или более преобразование общего понятия в более специфическое понятие, с учётом атрибутов.
лексические функции Мельчука — весьма частный вид такого преобразования:
свойство, главное слово <---> эквивалентная по смыслу фраза,
а весьма часто,
свойство, главное слово <---> определительное слово + главное слово
НЛО прилетело и опубликовало эту надпись здесь
имхо, миры, в которых живут различные общества — это давно уже разные диалекты одного общего языка. а база везде одинакова, т.к. везде описывается один и тот же мир, и большинство аспектов описания совпадает. ведь идёт стремительтельная взаимная ассимиляция языков.
поэтому, для совпадающих аспектов, можно взять некий общий язык.
понятия пронумеровать UUID-шниками или ещё как :)
(кстати, см. ниже мой коммент про синий/голубой.)

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

и так далее.
это действие назовём «семантическая свёртка». я думаю, кто-нибудь его уже так называет, и вы мне мою терминологическую самодеятельность простите :)
идеи-то витали ещё 50 лет назад :)
но если тогда не хватало сил и мощностей, то щас-то всего хватает!

или нет?

у меня вот вопрос такой:

как определить, правильно ли описано понятие в базе или нет, без человеческой помощи?
как определить, выбрал ли компьютер оптимальный перевод предложения?
вообще, как тестировать подобную систему?
у меня сложилось мнение, что почти все проекты в данной области загибаются от неправильной оценки объёма работы, переизбытка ручной работы и отсутствия контроля качества.
и это происходит даже при наличии Wikipedia и толковых словарей.
в чём же дело?
Честно говоря, я не думаю, что проблема в силах и в мощностях. Скорее, штука в том, что раньше пытались «rush through» — получить как можно быстрее конечный результат, в то время как базовые проблемы (морфология, синтаксис) оставались дырявыми.

Если мы даже в сегодняшнем дне посмотрим вперёд, то увидим, что в задачах «конечного уровня» (машинный перевод, например) по-прежнему всё туго. Потому что кроме синтактико-семантического анализа существует «commonsense reasoning», до которого ещё очень далеко.

Ой, не дописал. Любимый пример глупости машинного перевода. Если с английского перевести на русский и обратно фразу «the spirit is willing but the flesh is weak», получается «the vodka is good but the meat is rotten». Таким же образова, «out of sight, out of mind» превращается в «blind idiot».

И для сегодняшних систем это проблема.
и как же человек решает данную проблему табличной глупости компьютера? :)
и как её решит человек, не знакомый с данными фразеологизмами? :)
Плохо решает :)

Но это лишь анекдот, можно придумать более существенные примеры. В данном случае я бы сказал, что фразеологизмы — это часть словаря, они должны описываться в явном виде.
под «силой и мощностью» я понимаю в том числе и память.
даже базу данных морфологии на 640кб памяти не уместить.
что уж говорить о гораздо более крупной синтактикосемантической.
вот и пёрли напролом.

а что можешь прокомментировать про контроль качества и ручную работу?
По поводу памяти — как бы да, но тогда и не на РС ориентировались, в дело шли «большие машины».

По поводу прочего — совершенно согласен. В принципе, я думаю, что здесь нужны ресурсы, а «серебряной пули нет».

Вот есть же, скажем, Google Street View. Никто не пытается «статистически аппроксимировать» улицы — ребята поставили задачу объехать весь мар на машине и на велосипеде, и объезжают. И не каньючат, что работы много.

С языком, конечно, всё трудно, но невозможных вещей нет. Просто никто толком не знает, что именно нужно делать — как описывать, в какой форме и так далее… Да и, повторюсь, не любой лингвист способен мыслить как Мельчук.
Думаю, что в ближайшие полгода я напишу целую статью про Word Sense Disambiguation, потому что здесь к сожалению, практически ни слова не рассказано об этой теме. :(
Странно слышать — именно про WSD (не-статистический, естественно) эта часть и написана. В первом же примере я объясняю как disambiguate слово «разбивать», разве нет?
Да, как вариант.
Надо сказать, что как раз в disambiguation статистика, насколько я понимаю, может как раз неплохо работать. Понятно, что одна трактовка слова встречается чаще в одних контекстах, а другая — в других.

Но всё равно без синтаксического анализа придумать хороший алгоритм трудно. Например, что такое «контекст»? Для языка со свободным порядком слов контекст могут формировать слова, достаточно удалённые друг от друга. Да и в английском между соседними словами можно вляпать какой-нибудь причастный оборот.
Но вами написано очень мало. :(
Я пытался дополнить статью на Википедии, и там всё равно слишком мало информации… буду продолжать, значит. Я считаю, если мы в чём-то разобрались, то нужно помочь следующим поколениям разобраться со всем этим быстрее. :)
Такая вот мысль)
не очень понятно, что значит «древовидная» и «недревовидная» иерархия в данном случае.
Т.е. к вопросу о косе у нас есть
«Девушка с черной косой»
color/general черный black

«Девушка с черной и местами русой косой»
color|human русый fair

«Девушка с черной и металлической косой»
color/tool металлический metallic

За счет введения некоторое «общего» узла на определенном уровне иерархии мы обходим множественное ветвление «наверх».
Либо что-то здесь непонятно
Я думаю о ситуации множественного наследования… скажем так, если сейчас мне удастся придумать хороший пример, это будет удар по древовидной структуре, а я такого удара и сам не вижу пока :) Поэтому пример так себе качества:

Допустим, есть класс «мебель». Оттуда я разделяю на подклассы «металлическая» и «деревянная». А теперь в каждом подклассе будет «кухонная мебель» (соответственно, деревянная/кухонная и металлическая/кухонная).

Теперь если мне нужна кухонная мебель (неважно, деревянная или металлическая), у меня проблема: нет общего подкласса «кухонная мебель». Придётся перечислять оба подкласса явным образом.

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

Всё это решается определёнными костылями, вопрос лишь в накоплении критической массы проблем, которая может сломать эту систему.
а в чём польза дерева?
в существующих общих онтологиях типа Cyc реализуют множественное наследование.
и по-моему, правильно делают.
пример я, кажется, уже приводил?
скажем, класс из середины иерархии: sw.opencyc.org/2009/04/07/concept/en/TransportationDevice
а вот лист: sw.opencyc.org/concept/Mx4rve1ZXZwpEbGdrcN5Y29ycA
или вот достаточно высокоуровневый тип: sw.opencyc.org/concept/Mx4rvVinb5wpEbGdrcN5Y29ycA

вообще, было бы замечательно, если бы ты ознакомлся поподробнее с имеющимися разработками на данную тему и тоже включил их в свои заметки.
впрочем, могу и я попробовать изобразить какую-нибудь статью на данную тему, или даже несколько.
скажем, давайте, я про opencyc напишу.
расскажите мне только, какие темы поднять. да и если кто карму поднимет для целей написания статьи, возражать не буду :)
а пока покомментирую тут, расскажу, как проблемы, поднятые в комментариях, решаются в других онтологиях.
Про Cyc я в курсе :) сам об этом писать не буду — с удовольствием уступлю эту честь тебе :)

В целом комментарий такой — ничего принципиально нового вид онтологии сюда не внесёт. Неважно, СУС это или то дерево, которое я описываю. Плюс дерева — исключительно в простоте и удобстве — в ООП тоже все советуют начать с дерева, и переходить на более сложные структуры лишь тогда, когда припрёт.
да, кстати, ещё бывают связи разного типа.
наиболее общими бывают связи вида is-a («instance of») и kind-of («subclass of»).
см. WordNet, см. OWL

так что никаких древовидных структур!
только семантическая сеть!

en.wikipedia.org/wiki/Semantic_network,
ru.wikipedia.org/wiki/Семантическая_сеть,
en.wikipedia.org/wiki/WordNet,
ru.wikipedia.org/wiki/Тезаурус
Вот, вот тут могу поспорить — вдогонку…

У меня есть ощущение, что для задачи синтактико-семантического анализа дерева достаточно. То есть я понимаю теоретическую важность сетевых структур — понятно, что можно строить графы общего вида, есть ещё такая штука как «фреймы» и так далее.

Но если для разбора хватает дерева, зачем же огород городить? Надо использовать самое простое, что работает. Мой пример с кухонной мебелью — надуманный, я не уверен, что такие проблемы реально возникнут.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.