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

Соглашение по терминологии

Чтобы понять, как относиться к свободе использования разных вариантов терминов, нам важно различить такие группы людей, как речевые сообщества (speech communities) и сообщества значений (semantic comunities). Это различение подсказывает нам стандарт Semantics of Business Vocabulary and Rules (OMG SBVR, http://www.omg.org/spec/SBVR/).

Людей в речевом сообществе объединяет естественный язык (английский, немецкий и т.д.) и словарь этого языка — в инженерии это чаще всего термины из словарика определений какого-то стандарта, предпочитаемого теми или иными инженерами (ГОСТ 34.320-96, ISO/IEC/IEEE 15288 и т.д.). Поскольку разных инженеров (инженеров-строителей, инженеров-программистов, биоинженеров и т.д.) много, а ещё есть менеджеры, юристы, кадровики — то речевых сообществ даже для одного естественного языка множество, предпочитаемых ими словарей терминов из разных стандартов много, и достичь однозначного соглашения по терминологии заведомо не удастся.

Сообщество значений (semantic commuinty) — это множество людей, которые одинаково понимают какие-то окружающие предметы и явления. Например, они все понимают существование автомобилей и не путают автомобиль с трёхколесным велосипедом и газонокосилкой.

semantic_speech_communities

Когда мы говорим о терминологии (выборе слов для обозначения понятий), мы обсуждаем именно значения терминов, их семантику. Семантика связана с общими для разных ситуаций и обозначаемыми какими-то символами (хоть словом из языка, хоть каким-то сочетанием цифр) значениями, поэтому мы переводим semantic community как “сообщество значений”.

Не нужно путать “значение” со “смыслом”. Смысл определяется конктерной ситуацией, он связан с прагматикой, а не семантикой — семантика про внеситуационную связь символов с их значением, а прагматика про понимание конкретных ситуаций в деятельности. Брошенная перчатка в некоторых ситуациях имеет смысл просто брошенной перчатки, а в некоторых ситуациях имеет смысл вызова на дуэль.

Использование каких-то определённых терминов (термин — это всегда слово, а то, что этим словом обозначается, обычно называется понятием, concept) для определённых понятий определяет принадлежность к речевому сообществу. Речевое сообщество всегда подсообщество для сообщества значений. Никогда не видевшие автомобиля люди племени мумба-юмба или маленькие дети не входят в комьюнити значений для автомобиля. Если я сейчас начну рассказывать про зергов с протоссами как они объединяются против терранов, то знающие StarCraft II люди меня поймут (они и будут сообществом значений), а не знающие — не поймут, на каком бы я языке об этом не говорил, какими бы я терминами для этого не пользовался.

Раньше компьютер в России назывался ЭВМ (электронно-вычислительная машина), а теперь — компьютер. Значение не поменялось, поменялась речь — поменялся термин, слово-обозначение.
Системные инженеры мира представляют из себя сообщество значений (semantic community), но все они разделены на разные речевые сообщества — и каждое из этих сообществ использует свою терминологию системной инженерии.

Есть разные отношения к терминологии:
  • Терминологический фашизм (когда только один термин объявляется правильным, а все остальные — неправильными. Ср. “Grammar nazi” — http://lurkmore.to/Grammar_nazi). Есть много самых разных его вариантов — безусловные требования не только к единственности используемого термина (отсутствия синонимов для термина), но и соответствия его каким-то определённым уже принятым стандартам (определённым ГОСТам, например, а не учебникам или другим ГОСТам), обязательности использования отечественного корня в слове (“мокроступы” вместо “галош”), приверженность определённым соглашениям (“галоши”, но никак не “калоши”).
  • Терминологический пофигизм (когда на слова вообще не обращают внимания) — могут просто указать, как в математике, в начале текста, что “T — это будет то-то”, и этого достаточно — никаких “заведомо правильных вариантов” или ссылок на авторитетные источники. Более того, если значение слова меняется по ходу разговора, то это часто вообще не отслеживается, речь “не строга”.
  • Строгость значений с разрешением синонимии разных терминов, обозначающих эти значения. Очень долго договариваются о том, что именно имеется ввиду (какое понятие), а затем используются любые слова-термины для указания на оговорённое понятие — то есть вполне допускается использование терминов, предпочитаемых разными профессиональными сообществами (которые часто являются и речевыми сообществами — разные профессии имеют разные термины для одного и того же: “программное средство” сообщества разработчиков-любителей ГОСТов будет “приложением” для сейлзов иностранного софта, терминология может существенно отличаться не только для разных профессий, но и для разных подпрофессий одной профессии). Более того, можно и не пользоваться точными терминами, если будет понятно значение. Так, при обсуждении автомобиля вполне можно обозвать его “самобеглой тележкой”, и это не будет преступлением, если адресат сообщения поймёт, о чём речь.
В нашей книжке будет использоваться именно строгость значений с синонимией обозначений-терминов. Назови хоть горшком, хоть используй пять терминов из пяти разных стандартов на трёх языках — но договорись о том, какое именно понятие/concept/значение ты тут имеешь ввиду: должны понять не термин, а что ты под этим термином подразумеваешь.

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

Критика такого подхода понятна: “как вы можете учить людей, когда одно и то же обозначаете разными словами? Вы должны выбрать один термин, и затем использовать в книге для обозначения какого-то понятия только его! Так всегда делают в учебниках!”. Ответ на эту критику прост: в жизни вы вряд ли встретите понятия, которые обозначаются тем же термином, который будет таким образом дан в книжке. Поэтому книжка будет вас тренировать: обращать внимание на то, что она вас учит не новым словам, не даёт терминологию, а даёт знания о понятиях и их связях — под какими бы словами-терминами эти понятия ни скрывались.

Наука традиционно порождала новые термины (обозначения для каких-то понятий-значений) двумя способами:
  • Бралось обычное (“бытовое”) слово, и нагружалось специальным (“научным”) значением. “Работа” в физике — это отнюдь не работа в бытовом значении этого слова. Это самый частый способ, но он легко приводит к путанице со словами из бытовой речи.
  • Чтобы сделать речь точнее, термином делалось слово, для которого в бытовой речи не было известных значений. Для этого бралось обычное для иностранного языка, но необычное для родного языка иноязычное слово (чаще всего — с греческим или латинским корнем), и уже оно нагружалось специальным терминологическим значением. В русском языке прихватываемым словом может быть и английское бытовое слово, а не латинское или греческое — в русском-то оно не нагружено бытовыми значениями!
У нас в книжке термины выбраны (в том числе при переводе иноязычного текста — стандарта, методики, учебника и т.д.) по понятности их употребления в деятельности: кто поймёт это слово, из какого он речевого сообщества? Как пользователь создаваемой терминологии отнесётся к чуждому для него жаргону “экспертов” из другого речевого сообщества?

Вот пример из проекта “Архимейт по-русски”, в котором переводилась на русский язык терминология стандарта Opengroup ArchiMate 2.0 (http://ailev.livejournal.com/988360.html). Окончательные решения по оплате проектов информатизации на основании архитектурных документов айтишников принимает директор-не-айтишник. Архитектурные диаграммы составляются айтишниками соместно с неайтишниками, ибо неайтишники принимают решение о том, что в их деятельности поддержится или изменится в ходе проекта информатизации. Это означает, что мы должны в переводе использовать слова/термины, понятные неайтишным языковым сообществам, а айтишники как речевое сообщество пусть приспособятся! Так, software application стало “программой” (а не “приложением”), а business actor — “люди” (а не “бизнес-агенты” или “акторы”, которых по незнанию можно и с программой перепутать).

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

Примерно так же мы перевели semantic community: для специалистов из речевого сообщества лингвистов или даже айтишников привычней бы звучало “семантическое сообщество”, но мы попытались дать шанс что-то понять и неспециалистам из других речевых сообществ.
С другой стороны, мы используем тут жаргонное слово “айтишник”, а не “программист” — ибо нас заботит не только речь и привычные её термины, но и семантика, подразумеваемые терминами значения понятий: программист много уже айтишника — администратор базы данных, модельер данных, системный администратор, IT-архитектор, электронщик не программист, но айтишники. И да, можно было бы слово “айтишник” заменить словом “компьютерщик” — кому-то это было бы понятней. С учётом всего этого мы могли бы написать программист/айтишник/компьютерщик — чтобы никому не было обидно и было бы понятней, какое значение всех этих терминов мы имеем ввиду.

Если какой-то термин, для которого легко ошибиться в его значении, уже закрепился в языке какой-то узкой профессиональной группы (например, “управление” для governance), то в данном курсе будут использоваться вариант, который ведёт к меньшему числу ошибок понимания (например, governance как “подконтрольность”), и никакие “словари” и “стандарты” тут не указ. Если какой-то “процессный стандарт” (например, ISO 15288) под словом process имеет ввиду “практику” (в традиционном смысле стандартов ситуационной инженерии методов), то в данном курсе это будет “практика”, а не “процесс” (ибо характерной для процессов никакой особой развёртки во времени в этом “процессе” из ISO 15288 нет, там перечисляются именно “практики жизненного цикла”. Если вы попали в речевое сообщество “процессного подхода”, смело используйте слово “процесс” вместо слова “практика” — но знайте, что при этом вы теряете информацию по различению процессов и практик и речь ваша будет время от времени вызывать недоумение).

Очень часто за одним и тем же термином закреплено множество разных значений, так что уточнить значение даже очень распространённого термина никогда не бывает лишним. Например, Andries van Renssen (со стр. 79 тут: http://repository.tudelft.nl/assets/uuid:de26132b-6f03-41b9-b882-c74b7e34a07d/its_renssen_20050914.pdf) выделил следующие часто используемые значения для термина “функция” (function):
  • Подтип активности (поведения) -- процесса или события,
  • какой-то сущности в определенной роли или сделанной для определенной роли,
  • самой роли сущности, обычно это роль физической вещи, которую эта вещь играет в активности (поведении), [играемая роль и сущность, играющая роль — это разное! Роль Гамлета, сущность Пупкин]
  • указания на связь, например корреляция между какими-то аспектами: “ежели высота растёт, то давление падает”,
  • математическое отношение между числовыми объектами, определяющее их соотнесение/mapping.
Вот ещё пример — что подразумевается под отношением “мета”? При обсуждении одного из языков моделирования данных (MOF, meta-objec facility) было найдено, что слово “мета” (meta) используется обычно в шести разных значениях, выражая шесть разных типов отношений (слайд 8 в подробной презентации http://jtc1sc32.org/doc/N1751-1800/32N1764-WG2-Tutorial-OnMOF-forSC32.ppt):
  • Экземпляризация (тип -- экземпляр)
  • Группирование (тип-подтип), оно же категории (философские, а не из теории категорий! — термин “категория” любим самыми разными речевыми сообществами, и обозначает в них разное!)
  • Описание (описание -- всё что угодно)
  • Применение/стереотип (шаблон -- воплощение)
  • Основа-вариант (основная модель -- кастомизированная)
  • Выражение (абстрактный синтаксис -- выражение)
Не обращайте внимания на выбранные конкретные слова, никогда они не являются истинной в последней инстанции. Каждый раз пытайтесь понять, о чем идёт речь — какое значение слова имелось ввиду в каждом конкретном случае.

Использование терминов из стандартов не гарантирует однозначности, использование не-терминов не гарантирует многозначности говоримого. "Косил косой косой косой" -- ведь всё понятно, не правда ли?

В нашей книжке нет попытки делать точные определения и выбрать правильные термины. Есть попытка передать понимание наиболее важных понятий и предложить разные слова, которыми их можно обозначать. На вопрос “сколько будет дважды два” будут приниматься ответы и IV, и 4, и “четыре”, и four. Но не нужно обольщаться: ответы “горшок”, 5, “per aspera ad astra” приниматься не будут.
* * *
Это я потихоньку переписываю книжку по системноинженерному мышлению (её текущий июньский 2014 г. вариант лежит тут: http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking--TechInvestLab_2014.pdf). Понимать бы ещё, зачем я трачу на это время, вместо того, чтобы сразу переписывать текст по-английски.
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

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

В языкознании (так по-старинке у нас кличут 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

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

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

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

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

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


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

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г.).

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

В глоссарий системной инженерии

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

Артефакт (artifact) -- что-то (оборудование, знаковые системы, сервисы или обрабатываемые материалы), что сделано в ходе выполнения проекта или процесса. Из артефактов особо выделяют продукты (продукт -- артефакт, который произведен, измерим, и может быть либо конечным объектом сам по себе, либо объектом-компонентом. Product -- an artifact that is produced, is quantifiable, and can be either an end item in itself or a component item. PMBOK® Guide, v.4. Есть множество аналогичных определений и для процессного управления: продукт работы -- артефакт, ассоциирующийся с выполнением процесса, ISO/IEC 15504-1:2004 Информационные технологии -- Оценка процессов -- Часть 1: Концепции и словарь, 3.55. work product. -- an artifact associated with the execution of a process (ISO/IEC 15504-1:2004 Information technology -- Process assessment -- Part 1: Concepts and vocabulary, 3.55). Очень важно отметить, что есть артефакты, продуктами не являющиеся: они производятся для того, чтобы смочь произвести продукты, но никак не входят в состав комплекта поставки. Это руководства, планы, протоколы испытаний, модели и т.д. Иногда никакого различия между продуктами и прочими артефактами не делают, и в тексте тогда не остается слова артефакт вообще: продуктами называется все то, что сделано, независимо от конечного назначения.

Впрочем, так подробно с иностранными цитированиями для сверки, наверное, не нужно. Поэтому дальше буду писать по-русски. С цитированиями, наверное, это будет в следующем году, ежели начнем переводить стандарт Глоссария системной инженерии (а пока прошу всех сюда: http://pascal.computer.org/sev_display/index.action).

Валидация -- это определение того, насколько система соответствует требованиям заинтересованных сторон. В ISO 15288:2008 различают требования заинтересованных сторон (что хотят заинтересованные стороны от системы, в этот момент еще не определена, какова же будет система. Например, "хотим быстро перемещаться между точками А и Б") и требования к системе (иногда также называемые "определение системы", systems definition -- определение границ системы, еще без того, чтобы определить логическую архитектуру системы. Например, "система будет -- самолет с вертикальным взлетом"). Эти разные виды требований нельзя путать:
-- требования заинтересованных сторон порождаются в результате выполнения практики выявления требований заинтересованных сторон и их выполнение проверяется в ходе применения практики валидации.
-- требования к системе порождаются в результате выполнения практики анализа требований и их выполнение проверяется в ходе применения практики верификации.
Верификацию и валидацию вместе (напомним, тематическое объединение практик называют "дисциплиной") иногда называют квалификацией Практики определения требований заинтересованных сторон и анализ требований вместе называют дисциплиной инженерии требований.
Описанные соответствия практик иллюстрируют V-диаграммой (от названия буквы V, на левой дисциплину инженерии требований, а на правой практики квалификации. В V-диаграмму иногда включают еще и такое рассмотрение: соответствие архитектурному описанию проверяется в ходе применения практики интеграции. Поэтому иногда архитектурное описание тоже относят к виду требований ("требования архитектуры").

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

Верификация -- проверка системы на соответствие требованиям к системе. Подробности см. в "валидация".

Мета-модель -- набор понятий и связей между ними, в терминах которых строится модель системы, другими словами "модель модели". Мета-модели стали популярны в системной инженерии. Например, есть ряд стандартов, определяющих метамодели для моделей, строящихся в ходе инженерии жизненного цикла проекта:
-- метамодель инженерии программного и системного процесса OMG SPEM 2.0 -- Software and Systems Process Engineering Metamodel. Нужно учесть, что "программный процесс" и "системный процесс" являются синонимами процессов жизненного цикла проекта),
-- программная инженерия -- метамодель для разработки методологий ISO/IEC 24744:2007 Software Engineering -- Metamodel for Development Methodologies. Опять же, методология в этом стандарте определяется как набор методов, а из применения методов создается процесс (развертка применений методов во времени), который воплощается в жизнь в ходе жизненного цикла проекта.

Жизненный цикл проекта -- тот отрезок полного жизненного цикла системы (от замысла до исчезновения системы), который попадает во временнЫе рамки проекта.

Описатель -- по словарю синонимов: атрибут, свойство, характеристика, спецификатор, классификатор. Русско-английский словарь дает переводы: attribute, declarative, descriptor, handle, qualifier, specificator. Например, описатели (attributes) практики согласно ISO/IEC TR 24774 -- это название, назначение, результаты и состав (мероприятия и дела).

Проект -- планируемые и выполняемые согласно планам и контролируемые работы, проходящие на каком-то участке жизненного цикла конкретной системы. Проекту соответствует особая группа описаний, хорошо приспособленная для планирования ресурсов (логистики, определения потоков материалов, работ, финансов) и управленческого контроля. Другая группа описаний, которая меньше приспособлена для планирования ресурсов и потоков материалов и финансов -- это процессная (с другой стороны, в процессной группе описаний хорошо описывается типовая часть множества однотипных проектов, а также сам процесс преобразования материалов путем выполнения над ними отдельных операций). Проектные и процессные описания объединяются в рамках описаний жизненного цикла, в которых признается важность и тех и других. Тем не менее, чтобы подчеркнуть внимание системной инженерии не только к технологической (правильная последовательность операций, каждая из которых заключается из применения метода в правильный момент жизненного цикла системы) группе описаний, но и к управленческой (вопросы планирования ресурсов, контроль хода работ и т.д.) группе описаний, в ISO 15288:2008 говорится: "в настоящем Стандарте в качестве контекста для описания практик, связанных с планированием, исполнением, оценкой и контролем, выбран проект". А вот управленцы качества для всего того же выбирают "процесс": их много меньше волнует "уложиться в график и в бюджет", и много больше волнует "все сделать по правильным технологиям в правильной последовательности, чтобы получить правильный результат". Классическое определение проекта из американского PMI PMBoK вряд ли интересно в силу уже полной замыленности. Приведем для разнообразия не менее важное и распространенное, но в силу языковых и страновых особенностей чуть менее известное определение проекта из японского стандарта управления проектами P2M (обязательного, например, для всех финансируемых японским правительством инженерных проектов --http://www.pmprofy.ru/files/756/p2m.pdf): Понятие "Проект" означает работу по созданию ценности, базирующуюся на отдельной миссии, которая выполняется в определенное или согласованное время и с ограничениями, включающими ресурсы и внешние обстоятельства (A project refers to a value creation undertaking based on a specific mission, which is completed in a given or agreed time frame and under constraints, including resources and external circumstances).

Типовой -- ср. "дома типового проекта", "типовой договор", "типовой устав", "типовые правила" и прочие специфические русскоязычные сочетания. В английском языке тут используется reference -- reference design будет "типовой проект", reference process framework -- типовой набор практик. Обычно слово "типовой" означает, что будет проводиться какая-то адаптация по месту, так что не рекомендуем переводить reference как "эталонный", что также означает общий образец, но не указывает на возможность этот образец менять в соответствии с требованиями момента.

Требование -- очень многозначное понятие, омоним.
1. какая-то возможность или условие, которое необходимо пользователю для решения своей задачи;
2. какая-то возможность, которую необходимо иметь системе, или условие, которому она должна удовлетворить для того, чтобы соответствовать соглашению, стандарту, спецификации или другой формально приложимой документированной норме, идущей от какого-то заинтересованного лица;
3. описание, соответствующее 1. или 2.
Определение из проекта стандарта инженерии требований ISO 29148 повторяет определение из IEEE 12200-2005 (перештампованному затем как ISO 26702:2007): требование -- это утверждение, которое указывает на эксплуатационные, функциональные или проектные характеристики или ограничения, каковые однозначны, проверяемы или измеряемы, и необходимы для приемки (потребителями или согласно наставлениям службы обеспечения качества) продукта или процесса (requirement: A statement that identifies a product or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability (by consumers or internal quality assurance guidelines).
Требований огромное число видов: требования заинтересованных сторон, требования к системе, требования проекта, функциональные и нефункциональные требования, интерфейсные требования, нетехнические требования и т.д. Требования бывают одиночными, а также собираются в совокупности -- спецификации. Есть многочисленные требования к тому, каковы должны быть требования, и что с ними нужно делать. Получением требований занимается дисциплина инженерии требований, а проверкой выполнения требований -- дисциплина квалификации.

Форма жизненного цикла -- определяемый по согласованию инженеров и менеджеров способ получения необходимых функций системы (ISO 15288 относит определение формы жизненного цикла к менеджерской группе описаний ЖЦ):
-- последовательная, когда сразу все функции системы получаются после выполнения всей последовательности стадий замысла, разработки и изготовления системы.
-- инкрементальная, когда функции системы постепенно порциями (инкрементами) добавляются с каждой новой версией системы, пока система не выйдет на заранее оговоренный полный набор функций. Это означает, что стадия ввода в эксплуатацию повторяется для каждой версии системы.
-- эволюционная, это аналогично инкрементальной форме жизненного цикла, только при выпуске первых версий нет понимания, какой будет окончательный набор функций системы.
Форма жизненного цикла как термин вводится в проекте ISO 24748-1: "Организации по-разному применяют стадии для реализации различных деловых стратегий и стратегий снижения рисков. Одновременное или, в редких случаях, даже в другом порядке применение стадий приводит к формам жизненного цикла с ясно различающимися характеристиками. Часто применяются последовательная, инкрементальная и эволюционная формы жизненного цикла. Кроме того, может быть выработано подходящее сочетание данных форм". Смысл сказанного раскрывается подробнее в ISO 19760, но про то же самое говорится "подходы (approaches) к жизненному циклу": Организационная группа описаний иллюстрирует последовательный, инкрементальный и эволюционный подходы. ... Как альтернатива, может быть выработан подходящий смешанный подход, включающий элементы данных подходов". Далее в разделе 7.2 приводятся более-менее подробные описания того, как проходит жизненный цикл при последовательной, инкрементальной и эволюционной его форме (в терминологии "подход к жизненному циклу").
* * *
Тут я бы написал, что мне самому очень хотелось бы считать, что термин "форма жизненного цикла" не занят (и раскопки в интернете, скорее это подтверждают, чем опровергают), и я бы с удовольствием вернулся от определения этой формы "по стандартам" (особенно с учетом того, что в ISO 15288 этот термин вообще не встречается) к данному мной еще в мае 2009г. определению: http://ailev.livejournal.com/688971.html. Возможно, я бы дал сейчас и такое определение: "форма жизненного цикла -- это то, что отображается на горбатой диаграмме как разметка на оси времени". То есть "форма жизненного цикла -- это разметка стадий и контрольных точек/пересмотров выделения ресурсов жизненного цикла во времени".

Но тут я бы наступил пока на горло собственной песне и подумал еще (в том числе и потому, что есть и такая традиция понимания самого термина "жизненный цикл", в котором он всегда не конкретный, а типовой, а конкретны лишь соответствующие его каким-то периодам проекты. И с этим нужно еще разобраться: там "жизненным циклом" или "описанием/моделью жизненного цикла" называется как раз то, что я хотел бы назвать "формой" (стадии, контрольные точки, пересмотры выделения ресурсов, состояние системы к концу стадии, отстраиваясь от технической группы описаний -- мероприятий по применению главным образом технических практик в те или иные моменты времени. Я хочу одномерную горбатую диаграмму, в которой нет измерения дисциплин, а указана только стадийность -- и такая диаграмма как раз и характеризовала бы "форму". Но ISO 15288 норовит именно это назвать описанием (model) жизненного цикла, игнорируя тот факт, что в практике описывания жизненного цикла требуется описывать и дисциплины, и их применения в нужные моменты времени, и описывать (вернее, выбирать) форму жизненного цикла. Можно было бы отказаться от термина "форма ЖЦ" вообще и говорить о типах/видах (или даже моделях, отчаянно вляпываясь в омонимию типа "модель автомобиля масштаба 1:9" и "автомобиль ВАЗ модели 2109"), а то и "подходах", как это предлагает ISO 19760. Нужно разобраться, но я думаю, что это целесообразно делать только в рамках общего разбирательства с описаниями жизненного цикла, которые должны будут отражать и форму, и "подходы", и все-все-все про эти жизненный циклы. А это описание жизненного цикла, очевидно, нужно рассматривать с точки зрения его использования разными заинтересованными сторонами. Это использование происходит в рамках ситуативной инженерии методов, которая без упоминания этого термина хорошо описана в самом стандарте -- сам стандарт адаптируется, с ним совместно используются другие стандарты с типовыми наборами практик для разных типов систем, затем выбирается необходимое описание/форма жизненного цикла и эти практики расписываются (путем обеспечения всех необходимых инструкций) для применения в конкретных периодах этого жизненного цикла.

Так что ждем-с набора опыта моделирования ЖЦ, эксперименты в самом разгаре.

Для самых любопытных приведу еще один термин:

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

Разбирательство с тем, "форма разработки" это, или "подход к разработке" или еще что -- тоже после окончания какого-то разбирательства с моделированием ЖЦ. То есть к середине декабря.