August 31st, 2012

2019

К архитектуре систем поддержки терминологических данных

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

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

Главным получателем сервиса являются проектировщики, технологи, закупщики и прочие профессионалы жизненного цикла сложной инженерной системы. Им нужно выверять по глоссарию взаимопонимание -- прежде всего между собой, а затем со специалистами надзоров. Эти проектировщики работают в рамках крупных проектов. Им вполне достаточно иметь глоссарий проекта, и их мечта -- сделать cut/paste ими самими собранного глоссария их текущего проекта в следующий, "поднастроить" немножко неизбежные изменения в терминах и забыть о терминологической проблеме до следующего проекта. Да, они согласны получить централизованно какой-то глоссарий в качестве первой версии для их первого проекта, но дальше они не хотели бы ни от кого зависеть в своём словотворчестве. Один проект -- один глоссарий, один менеджер проекта -- одна цепочка копирований глоссария из инженерного проекта в инженерный проект. При разногласиях спрашивать не своих начальников (что им соседние проекты? только морока), и не отраслевые ассоциации (да кто они вообще такие?!), а надзорные органы (если им есть дело до каких-то разногласий -- а если нет, то продавливать своё решение, принятое ad hoc).

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

Широкая публика, переводчики, научные эксперименты по компьютерной лингвистике в порядке управления справочными данными (http://ailev.livejournal.com/1021613.html) и т.д. -- это маргинальное, а не основное использование, и поэтому вряд ли будет идти первой строчкой в аргументах по внедрению системы поддержки глоссариев. Исследовательские работы, типа поддержка корпусной лингвистики (с последующим переходом к корпусной инженерии -- http://ailev.livejournal.com/1009201.html) вообще вряд ли будут учтены, качество лингвистических справочных данных будет волновать не столько производственников "от САПРа" или "закупщиков от ERP", сколько... даже не знаю кого.

Кстати, это видно и по кучерявости моделей данных для словарной работы: ISO 15926 уделяет огромное внимание административному аспекту терминологической работы и федерирование словарей, SKOS нацелен на публичный доступ к центрально администрируемому ресурсу, а специфические терминологические стандарты переводчиков вообще имеют очень куцую модель данных. Первым делом, первым делом -- самолёты, ну а девушки-переводчицы и прочие лингвисты -- потом.

Терминологические ресурсы -- это прежде всего стандарты. Поэтому можно предположить, что архитектурно информационная система управления терминологией может быть устроена аналогично системе стандартизации в её лучших практиках "стандарты как базы данных": несколько уровней авторитетности, и fast track между ними, это не столько "система", сколько "система систем". Централизовано в такой системе только говорение о ней, а также стандарты федерирования (обмена данными жизненного цикла терминов и их коллекций). Тем самым архитектурна федеративна: она состоит из отдельных библиотек справочных данных (которые совсем необязательно именно "терминологические" в чисто лингвистическом значении этого слова -- достаточно вспомнить такие справочные данные, как "словари", стандартизирующие закупки материалов и оборудования, типа ISO 22745 и прочие стандарты производства-в-большом из http://ailev.livejournal.com/851977.html). Эта федеративность обязательно должна быть поддержана не только информационными системами, но и административными практиками по взаимодействию центров администрирования, в том числе административными практиками fast track (передача ведения словарной информации из библиотеки более низкого уровня в случае невозражений администраторов библиотеки более высокого уровня -- например, передача разработанных в ходе ведения какого-то проекта терминов для ведения их в глоссарии компании, или передача из глоссария одной компании каких-то терминов для их ведения в рамках отраслевой ассоциации).

В технической реализации можно лишь опять помянуть ISO 15926. Его Часть 5, определяющая ведение базы данных в качестве стандарта, легла в основу ISO TC184/SC4 : Procedure for development and maintenance of reference data in database format. Конечно, это "международный стандарт", т.е. самая тяжёлая изо всех возможных реализация процедуры стандартизации. Но это хороший способ задуматься, с какого сорта практиками придётся столкнуться занимающимися унификацией терминологии людям, и какого сорта софт должен будет эти практики поддержать. Понятное дело, что ISO 15926 также вполне описывает федеративную реализацию самих справочных данных, а также поможет организовать обмен не только данными по 3D геометрии и P&ID технологическими схемамами непрерывного производства, но и обмен терминологическими ресурсами между информационными системами. Но даже если не использовать ISO 15926, придётся чётко дать ответ на вопрос, как вписать терминологическую базу и разные прикладные интерфейсы к ней в рамках "единого информационного пространства" (что понимают под этим словом местные айтишники?), "корпоративной шины предприятия", "системы поддержки нормативно-справочной информации", серверов MDM и прочей имеющейся инфраструктуры "информационных брокеров" и "корпоративных справочников".

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

Тем самым большинство систем управления терминологией "уровня предприятия" (ряд которых я привёл в предыдущем постинге http://ailev.livejournal.com/1020976.html) нужно оценивать на предмет вписываемости их в конкретное программное окружение, используемое в проекте, и на предмет поддержания функции центрального "межпроектного" или "межкорпоративного" репозитория терминологии. Не исключено, что дело закончится "зоопарком" таких систем, в разных проектах, и на разных уровнях унификации терминологических знаний/централизации в операционной деятельности.

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

Я тут совсем опускаю возможное появление "унификаторов терминологии" по линии "управленцев качеством/службы регламентации процессов". Такое часто бывает, но кто ж им даст?! Их терминологические системы не будут интегрированы в основные CAD/PLM системы, и будут автономно поддерживаться "сбоку от жизни". Часто они говорят о "бизнес-правилах" (http://ailev.livejournal.com/693597.html) и необходимости словарей для их точного формулирования (помним про OMG SBVR http://www.omg.org/spec/SBVR/). Ну, это больше характерно для банков, страховых и прочих компаний с "потребительским/розничным бизнесом", оттуда медленно ползёт в инженерные компании. Есть ли исполяемые business rules в BPM-движках вашей инжиниринговой компании? Вопрос этот, задаваемый на русском языке, риторический. Так что я не буду развивать эту линию, но на английском языке про это довольно много написано.