Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Модифицированная понятизация: онтологический перевод

Пример разбирательства с терминологией "процессного подхода" в версии сообщества разработки стандартов жизненного цикла и системной инженерии(http://ailev.livejournal.com/631242.html) показала, что обычный менеджер будет не в состоянии разобраться в этой терминологии. "Референсный процессный фреймворк жизненного цикла" -- это понять невозможно.

Нужно выполнить понятизацию (pun intended: это и от "понятия" и от "понятности"). Опыт первых попыток моих занятий понятизацией аж в 1989 году обобщен в http://www.libertarium.ru/libertarium/l_libsb3_3-5. Примерно по этой технике я и двигаюсь. В частности, для создания упомянутого текста про "референсные процессные фреймворки жизненного цикла" был выполнен "референциальный анализ" (но не в виде простого списка, а в виде ConceptMap в CmapTools), после чего этот список был "переведен" (вернее, транслитерирован) в то, что получилось. Сейчас я буду чуть хитрее, чем 20 лет назад, когда писал тексты про "понятизацию", даже не упоминая слово "онтология". Вот сегодняшняя модификация метода:

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

2. Это отображение подразумевает сразу два действия а) перевод с иностранного языка на русский; б) собственно отображение из локального предметного лингвистического контекста в более глобальный. Про перевод с иностранного языка я тут писать ничего не буду, за подробностями вам в ru_translate. А вот про отображение (mapping) из более локальной (в данном случае -- сленга стандартизаторов процессного подхода и системной инженерии) онтологии в более глобальную (например, общеменеджерскую) мы будем тут говорить подробнее. "Более глобальная" -- это отражение факта, что менеджерский сленг тоже вполне себе локален, "человек с улицы" вполне его может не понять. Напомню, что онтологий различают три: локальную (local) тусовки, занимающейся каким-либо предметом), отраслевую (middle, domain) какой-либо отрасли знания типа "управление", "математика", "инжиниринг непрерывных производств" (process plant engeneering), и "высшую" (upper) с небольшим числом понятий типа "все-что-угодно", "отношение", "предмет", "класс", "тип" и т.д.

3. Отображение (mapping) обычно делается в форме таблицы соответствий и основывается на том, что каждый концепт не имеет даже имени, а только лишь уникальный номер. Этот концепт вставляется в иерархию типов какой-либо общепринятой онтологии (ISO 15926, Gellish и т.д.) путем определения отношения <"наш концепт" is a specialization of "уже имеющийся в онтологии тип концепта-обобщения-к-нашему-концепту">. Слово "определение" тут тоже важно -- оно означает, что в графе "определение" нужно написать основной содержательный аспект, по которому происходит специализация. Сам "номерной концепт" затем может быть поименован на разных языках, как иностранных, так и сленгах различных профессиональных тусовок-сообществ. Такой подход позволяет легко разбираться и с синонимами, и с гомонимами. Еще одно достоинство такого подхода в том, что он позволяет затем легко обеспечивать обратный перевод русскоязычного текста в "английский сленговый" той или иной тусовки, что нужно, если мы хотим не только черпать полными ладошками оттуда, но и как-то участвовать в мировой жизни, возвращая собственный опыт туда.

4. Структура статьи Глоссария, которую мы будем использовать, облегчает последующий перевод этой статьи в формат Gellish Table:
а) UID -- уникальный идентификатор концепта (строка, а не число. Хотя чаще всего эта строка состоит только из цифр ;)
б) англоязычный термин и его контекст (и до кучи тут же -- все синонимы и их контексты). Контекст -- это указание на тусовку, которая "так говорит", или документ, который определил термин.
в) "родное" определение, если есть (например, из текста стандарта), комментарий, словоупотребление.
г) предлагаемый русскоязычный термин (и его контекст). Если терминов несколько, то все пары "термин-контекст" плюс комментарий, обосновывающий перевод на русский
д) обобщающий тип для концепта (берется из онтологии) -- номер и основное имя на русском и английском. Признак, по которому произошла специализация концепта из (е) -- это и будет "формальное определение", на русском и английском.
е) всяческие комментарии
ж) учетная информация (например, changelog)

5. Переоформление этой словарной статьи в Gellish Table и накопление терминологических знаний о предметной области в виде таблицы фактов (факт -- это тройка "концепт1-отношение-концепт2" с сопутствующими комментариями) позволяет затем наладить процесс для основной задачи PraxOS -- интеграции самых разных организационных мод и поветрий через отображение (mapping) их понятий с использованием общепромышленной онтологии (например, Gellish).

UPDATE: хотя и немного не так, но работа была выполнена -- http://ailev.livejournal.com/638740.html
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 1 comment