Оценка авторской мысли

• Какова цель автора?
  • Показать преимущества построения бизнес-систем на основе данных онтологического моделирования. Объяснить, что в основе каждой системы лежат правила, опирающиеся на семантику предметной области.
• На какой вопрос автор пытается дать ответ?
  • Что изменится в области бизнес-систем (особенно в части автоматизации и компьютеризации) с использованием семантической информации при проектировании и реализации? Каким может стать будущее таких систем?
• Какую информацию автор использует в своих умозаключениях?
  • Данные, полученные в ходе консалтинга на многих интеграционных проектах.
• Каковы главные выводы автора?
  • Недостаточное внимание концептуальному проектированию приводит к огромной сложности существующих систем. Если опираться на формальные онтологии и при этом стремиться абстрагировать, то огромное количество реализованных правил можно заменить меньшим числом их обобщенных вариантов.
• Каковы основные концепты и идеи в мышлении автора?
  • Бизнес-правило
  • Онтология
• Из каких предположений исходит автор?
  • Присущую каждой предметной области концептуальную сложность можно формализовать и описать в виде онтологий. Другими словами, семантику (смысл) предметной области можно представить в виде онтологической модели.
• С какой позиции автор рассматривает вопрос?
  • С позиции неудовлетворенности общепринятым толкованием и использованием объектно-ориентированного подхода, а также смещением фокуса в сторону функций (императивный подход), а не данных (декларативный подход) при создании компьютерных систем.
• Если автор прав, то что из этого следует?
  • Системы, построенные на основе проработанных онтологических моделей окажутся способны работать и при поступлении новых, не предусмотренных данных (при условии, что категоризация этих данных будет выполнена корректно). Одинаковая интерпретация семантики разными системами позволит разным системам интегрироваться между собой автоматически, возможно, даже без участия человека.

Основные идеи

• Компьютерные системы слишком жестко автоматизируют бизнес-процессы
• Сложность ПО обусловлена сохранением устаревшей семантики, а значит рефакторинг должен прояснять семантику системы
• Ветки if в коде подразумевают семантические категории
• Все описания ПО детализируют семантическую модель
• приложения как средства снижения информационной энтропии

Конспект

Глава 1. Semantics: A Trillion-Dollar Cottage Industry

Языковые сообщества начинают расходиться (облака смыслов становятся шире, но реже), потому что чаще не придумывают новые слова для своих важных объектов, а перегружают смыслом уже имеющиеся. Это прямо противоречит принципу Open-Closed Principle.

---

Недовольство общепринятым толкованием и использованием объектно-ориентированного подхода привело автора в область семантической работы с данными в БД и к созданию первой model-driven архитектуры.

Крис Партридж заявлял, что неверное понимание объектов мешает точному моделированию. Мне кажется, что чем-то похожим был разочарован и Егор Бугаенко, отсюда его Elegant Objects.

Такое ощущение, что это прямое следствие неплотного облака смыслов для ООП в частности и объектного взгляда на мир в целом.

---

Нас волнует не только смысл / значение / референция символов и моделей в компьютерных системах, но и то, понимают ли это одинаково все клиенты системы.

Мы успешно решили многие технические проблемы в сфере разработки ПО. Но проблемы, связанные с интерпретацией, аргументацией и согласованием смысла в компьютерных системах остаются нерешенными.

Самая крупная причина трудностей интеграции: позднее обнаружение семантических несоответствий.

---

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

Еще одно направление рассмотрения - это исторические события / течения мысли, которые привели к современному состоянию семантики. Выделено появление устной речи, как введение звуковых обозначений для предметов, не находящихся в непосредственной близости / поле зрения, также см. Язык - необходимое условие возникновения разума. Отмечено также появление письменности, как способа передавать информацию людям, не находящимся вблизи как в пространстве, так и во времени. Из более “свежих” феноменов - лингвистика и работы в направлении искусственного интеллекта.

Глава 2. Business Semantics

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

Semantics in Business Systems

Это вопрос даже не столько доверия, сколько согласованности ожиданий и их соответствия реальности. Базовый пример - бартер с прямым указанием (пальцем, буквально) на физические товары, подлежащие обмену. Тут есть скрытая семантика “личного владения” вещами, без которой обмен невозможен, но это не так уж важно. Как только в бартер включаются деньги, они сразу же вносят свою семантику/значение: “Чего это стоит? Подлинные ли это деньги?” и т.п.

Как только мы отходим от физичности продаваемых вещей и начинаем покупать/продавать вещи по описанию, возникают еще большие возможности для расхождения в понимании.

---

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

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

---

Глава 3. The Process Side of Business Systems

Уровень семантики системы складывается из точности и достоверности

Для разных схем взаимодействий между приложениями и пользователями важно понимать, какой уровень семантики поддерживается каждой из сторон взаимодействия. Источник сообщения закладывает в сообщение какой-то смысл, получатель сообщения как-то его интерпретирует.

Всего возможно четыре основных направления взаимодействия, из которых композиционно складываются любые другие возможные комбинации: H2H, H2A, A2H, A2A. Основная комбинация в случае компьютерных приложений: H2A2H, но при этом внутренняя A - это на самом деле сколь угодно длинная цепочка A2A. (H - Human, A - Application).

Интересное замечание о том, что когда-то в будущем мы сможем создавать приложения, используя конечный набор базовых абстракций, а затем приложение само разберется с новыми типами данных, новыми абстракциями и связями между ними. Что-то похожее упоминается и в Два этапа реинжиниринга как пример концептуализации и абстрагирования, речь идет о том, что какой-то базовый набор объектов оказался способен справиться с разными предметными областями.

Глава 4. Terms: Vocabulary, Taxonomy, and Ontology

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

Один из источников непонимания - перегруженные смыслом слова (перегрузка как в “перегрузке методов”). То есть, это слова-омонимы, звучат одинаково, но означают разное. Их вроде бы около 10%, но они приходятся на самые часто используемые слова и вероятнее всего приведут к недопониманию, так как не дают ни малейшего намека на правильную интерпретацию / на то, что получатель сообщения не знает смысла этого слова в этом контексте.

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

Несловесные идентификаторы - создаются для обозначения, например, клиентов или продуктов. Как правило, это несловесные конструкции, часто с использованием цифр. Однако, иногда идентификаторы создаются с намерением облегчить запоминание (мнемонику) или произношение и тогда становятся “словами” в языке.

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

---

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

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

---

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

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

Биологическая классификация в этом смысле является исключением по нескольким причинам:

1. Эволюционное развитие шло от одного “корня”, то есть все видовое многообразие имеет один реальный источник и один механизм формирования.
2. Место конкретного вида в классификации в подавляющем большинстве случаев можно определить однозначно.
3. Неизменный принцип создания подгрупп - это реальные подтипы родительского типа, и это отношение не меняется по мере следования вглубь классификации.

Свойства хорошей таксономии:

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

---

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

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

Отнесение к категории в основном осуществляется по теории прототипов (по крайней мере, в повседневной жизни; это происходит неосознанно), а затем с помощью ряда правил выполняется включение/исключение из категории.

Дисциплина Онтологика - теория прототипов

Категоризация служит для двух основных целей:

1. Вывод информации, недоступной напрямую у объекта, из категории
2. Формулирование новых вопросов об объекте и ответы на них

---

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

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

Статус - это всего лишь ярлык для набора доступных поведений. Эти поведения включают в себя как те, что изменяют статус, так и те, что не приводят к его изменению. Если моделировать статусы в объектно-ориентированной парадигме, то возникают проблемы смены типа объекта в ходе его жизни, а также проблема определения момента требуемой смены типа с помощью правил “дифференциального диагноза”.

---

Вывод:

Для использования в компьютерных системах таких же гибких систем категоризации, как и в лингвистических, нам нужно следующее:

• способность присваивать категорию “по ссылке”, и таким образом определять тип объекта
• способность отсылаться к нескольким категориям одновременно
• способность отказываться от первоначального типа объекта
• способность сохранять свойства, приобретенные на предыдущем состоянии/типе
• наличие поведения отказа от типа или расширения набора типов.

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

---

Глава 5. Data and Object Modeling

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

1. Момент контроля семантики и интерпретации смысла. Составление документа не ограничено никакими семантическими правилами, мы можем написать все, что угодно. Интерпретация будет явно отложенной во времени. В случае с БД интерпретация происходит в момент создания записи и это позволяет наложить семантические ограничения на записываемые данные.
2. Документы не могут быть использованы в компьютерных системах без серьезной работы по структурированию данных. Записи в БД уже структурированы.

Получается, что в компьютерных системах семантика представлена более явно (в частности, за счет использования БД), семантические правила применяются раньше и более строго, плюс к этому программисты могут использовать семантику, определенную на уровне данных.

Вопрос в том, где именно в приложениях зафиксирована эта семантика?

---

С точки зрения данных существует серьезная проблема возможных различий в интерпретации, если пользователей у данных несколько. Как гарантировать одинаковую интерпретацию для каждого следующего клиента? Исторически существует два способа повысить уверенность в единообразии: тщательное тестирование и смещение контроля за семантикой как можно ближе к данным - в БД.

С точки зрения бизнес-логики добавляется еще один вопрос: как убедиться в том, что набор бизнес-правил семантически непротиворечив и полон, то есть не оставляет места для различной интерпретации?

---

Глава 6. Metadata

Метаданные - это данные о данных. Это практически чистая семантика, т.к. метаданные хранят информацию о смысле описываемых данных.

Решение и мета-решение проблемы

Абстрагирование снижает количество второстепенных семантических деталей, а взамен предоставляет точку определения дополнительной семантики (задания смысла?).

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

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

---

Дизайны/проекты, учитывающие метаданные, обычно сводятся к подходу “active repository” - это похоже на словари локализованных строк. Второй популярный подход - зарезервировать часть полей в записях для пользовательских нужд. Но это всего лишь способы передать смысл от человека к человеку (H2H), семантический уровень приложения при этом не повышается.

То есть, распространенные подходы на самом деле не позволяют расширять набор конкретных экземпляров, с которыми работает приложение, потому что не уделяют должное внимание семантике данных и правильному абстрагированию/выделению-типов.

---

Глава 7. Interpreting Meaning

Интерпретация включает следующие шаги (в скобках приведены аналоги в компьютерных системах):

1. Восприятие (любой доступ к информации, получение данных)
2. Первоначальная низкоуровневая классификация восприятия (парсинг полученных данных). Здесь же происходит какая-то группировка входных данных в более крупные и возможно логически связанные блоки данных.
3. Синтез с ранее воспринятыми и классифицированными штуками (отнесение полученных блоков данных к какой-либо схеме или грамматике из заданного “корпуса знаний”)
4. Гипотеза высокоуровневой классификации (решение вроде “у пациента есть валидная страховка). Такая гипотеза всегда так или иначе относит воспринятые штуки к каким-то категориям.
5. Предсказание дальнейших восприятий (предположения о составе других данных, то есть о текущем или будущем состоянии системы)
6. Проверка гипотезы (в основном валидация и реже переоценка исходных предположений, если тесты провалилилсь).

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

---

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

---

Интерпретация документа позволит выяснить:

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

Глава 8. Business Rules and Creating Meaning

Существует четыре основных способа превратить требования в реализацию:

1. Процедурный или императивный. Это обычная последовательная запись операторов и это именно тот код, который будет выполнен в рантайме. Программист задает детальные инструкции, как нужно получить требуемый результат. Вне зависимости от способа организации кода (процедуры, функции или объекты), в конечном итоге именно программист задает порядок выполнения операторов и формирует структуру программы.
2. Декларативный. Программист каким-то образом описывает, что он хочет получить в результате выполнения программы. Затем специальный набор инструментов определит план выполнения и составит процедурный код. Из-за того, что контексты вычислений и сами специнструменты могут отличаться, невозможно предсказать точное содержание (последовательность) процедурного кода.
3. Модельный (model-based). Программист описывает модели, например, модель UI с помощью специализированных объектов. Затем запускается движок, который “выполняет” модели (что-то вроде прогона симуляции). Таким образом, описаны лишь свойства и поведение моделей, но в явном виде не задан ни желаемый конечный результат вычислений, ни процедурный код этих вычислений.
4. Правильный (rule-based) - pun intended :) Правила подозрительно похожи на процедурный подход, потому что записываются в привычной форме if-else. Однако они ближе к декларативному, т.к. не требуют глубоких знаний о структуре программы (в каких местах какие проверки нужно выполнять). Эту работу выполняет движок вычисления бизнес-правил.

---

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

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

1. Термин - базовая единица, соответствует словарному термину.
2. Факт. Выражение с двумя или более терминами. Относится к области типов и метаданных, и потому является “предписывающим” выражением, определяющим возможные отношения и взаимодействия. “Клиент размещает заказ” - это факт с точки зрения бизнес-правил, т.к. речь идет не о конкретном клиенте, заказе или транзакции, речь идет о возможном типе.

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

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

Генеративные правила куда сложнее и интереснее, так как они могут привести к созданию новых “производных” данных. Такие правила могут быть далее классифицированы на:

• правила расчета
• правила категоризации
• правила, запускающие какое-либо поведение
• правила, копирующие или клонирующие данные

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

---

Глава 9. Semantic Elicitation: Uncovering Meaning

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

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

Источники знаний о семантике системы:

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

---

Поиск семантики на разных этапах работы над проектом

• Архитектурное проектирование. Семантика, обнаруженная на этом этапе, обычно выявляет совместно используемые службы, очерчивает границы систем, определяет места “наложения” существующих систем друг на друга.
• Определение масштаба проекта.
• Работа с требованиями. Чуть ли не лучшее время для работы с семантикой, потому что (1) требования будут приходить на языке предметной области и (2) влияние требований на ход проекта и реализацию продукта огромно.
• Концептуальное (логическое) проектирование. Это этап логического разбиения приложения на модули. Это поиск абстракций в данных и процессах, и семантика, обнаруженная здесь, поможет найти правильные абстракции и категории.
• Разработка. Обычно на этом этапе придерживаются ранее созданного проекта, но иногда разработка заходит в тупик и требуется дополнительный семантический анализ.
• Системная интеграция. Важные семантические находки относительно целевых систем.

---

Как искать семантику

Забавная метафора - исходя из опыта работы автор предполагает, что поиск семантики - это на 60% антропология (разговоры с “местными”, видимо, с пользователями/заказчиками) и на 40% - археология (раскопки руин, видимо, исследование легаси-систем).

1. Антропология - подготовить сессию семантического моделирования. Определить время, место, тему и состав участников.
2. Антропология - провести такую сессию. Помогут “вопросы Сократа”, перечисление экземпляров типа (и люди разделятся на splitters vs. lumpers), составление определений, поиск различий, использование базовой онтологии (семантические примитивы), доведение до предела, проверки на полноту и покрытие.
3. Археология - найти данные. Два источника - официальный (БД и данные в системе) и неофициальный (данные на бумажных носителях, не учитываемых в системе). Очень важны аномалии в данных и всяческие “файлопомойки”, куда попадает информация, не вошедшая в регламентированные данные.
4. Археология - анализ метаданных, то есть данных, определяющих текущую семантику системы. Это могут быть требования или ТЗ, описания типов данных, документация по интерфейсам. Собственно, программный код тоже сюда относится, если есть возможность проанализировать принимаемые в коде решения, это нужно сделать (помним, что каждый if может скрывать семантическую вилку).
5. Антропология - выявление семантики в рабочих процессах. В первую очередь внимание стоит уделить длительным бизнес-транзакциям - отношениям, выстроенных вокруг какого-то процесса, например, процесса оптовой продажи или ипотечного кредита, и сконцентрироваться на тех процессах, которые идут в рамках таких транзакций. Нужно рассмотреть как базовый вариант процесса (happy-path), так и возможные варианты: граничные случаи и ошибочные сценарии.

---

Семантические “рамки” - область применимости семантики

• Универсальные законы. Семантические термины или утверждения, которые “всегда верны” должны превратиться в семантические примитивы для данной предметной области.
• Географическое разделение. Некоторые утверждения верны в одной географической области и не верны в другой.
• Отраслевые стандарты и сленг. Многие термины имеют одно значение в одной отрасли и совершенно другое - в другой.
• Корпоративные соглашения
• Личные интерпретации

Семантические примитивы подробно разбираются в работах:

• C. S. Peirce, On A New List of Categories. Proceedings of the American Academy of Arts and Sciences, 1868. http://www.peirce.org/writings/p32.html
• Anna Wierzbicka, Semantic Primes and Universals. Oxford: Oxford University Press, 1996.

Глава 10. Understanding and Communicating Meaning

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

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

Дальше идут перечисления того, что нужно фиксировать для фактов/отношений и правил.

---

Хранить обнаруженную семантику в простом текстовом формате быстро станет крайне неэффективно. Общепринятые стратегии управления большими объемами семантических данных таковы:

• Словари (но тут есть проблема с омонимами и особенно синонимами, т.к. истинных синонимов крайне мало). Рекомендация - оформлять в самостоятельные термины только те концепты, которые по-разному ведут себя в системе.
• База данных. Здесь возможны как минимум четыре способа организации информации:
  • Узлы и связи. Любая запись (термин, факт, правило) - это узел, который может быть связан с любым другим узлом. Гибкий подход, но вся интерпретация / валидация данных ложится на прикладной код
  • ER-модель. Моделируются сущности (таблицы), каждая из которых может иметь множество атрибутов (столбцов) и отношений (пары внешний-первичный ключ, могут быть только бинарными, т.е. с между двумя сущностями).
  • Ассоциативная модель. Связь (ассоциация) между сущностями становится объектом первого класса.
  • Моделирование правил. Сущности, объединенные отношениями, становятся частями правил.
• Системы электронного документооборота, в том случае, если документы могут быть дополнительно размечены и стать частью отношений, выраженных в рабочем процессе.
• CMS могут использоваться для хранения семантической информации за счет перекрестных ссылок, возможностей дополнительной разметки (вроде меток на страницах), переиспользования фрагментов отдельных страниц.
• Системы управления знаниями - полезны в основном из-за возможностей хранения и поиска семантической информации.
• Редакторы онтологий - лучше всего подходят для создания и хранения семантической информации, но обычно недостаточно визуальны.

Графические методы представления семантики/онтологий должны учитывать множество требований, часть их них в книге приведена. Наиболее часто для визуального представления используются Entity-Relations нотация, UML или ORM (Object Role Model).

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

Глава 11. Extensible Markup Language (XML)

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

Даже в тех (очень многочисленных) случаях, когда у нас есть схема данных, системы не знают семантики. Семантику знают люди, которые договорились о значении элементов схемы.

Semantics in Business Systems

Глава 12. Semantic Based Enterprise Application Integration and Systems Integration

Исследование Gartner (к сожалению, без ссылки на источник) показало, что 95% API систем строятся (а значит и включают в себя) на семантике системы (остальные 5% - это инфраструктурные нужды).

Две системы интегрированы между собой, если каждое событие, возникающее в одной из них и потенциально влияющее на принятие решений во второй, всегда отражается во второй системе в “реальном времени бизнеса”.

Semantics in Business Systems

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

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

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

Глава 13. Web Services

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

Использование веб-сервисов в качестве внутренней интеграции (т.е. внутри одной организации) осложняется несколькими особенностями веб-сервисов:

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

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

Semantics in Business Systems

Глава 14. The Semantic Web

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

Глава 15. Getting Started

Наводящие вопросы и конкретные шаги, которые можно предпринять уже сейчас в свете полученных знаний о важности семантики.

---