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

Используя наше воображение, представим “контекстно-независимую” последовательность шагов для извлечения информации из “контекстно-несвязанных” (context-unbound source) данных.

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

При этом об организации данных в базе мы знаем только следующее:

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

Итак, для составления запроса нам требуется знать все использованные алфавиты. Нам также известны все языки, которые использованы для записи информации. Предполагается, что мы можем интерпретировать фразы каждого из языков в некотором глобальном контексте: в общем случае это либо контекст естественного языка (например, русского), либо контекст языка некоторой предметной области, описанной на естественном языке (например, системы строительных норм и правил принятых в РФ), либо контекст формального языка. В первом случае мы предполагаем, что нам известен (доступен) весь контекст, который существует в естественном языке, включая и СНиПы. Во втором случае нам известен только некоторый специальный контекст, например, система понятий и терминов СНиП и контексты, необходимые для его интерпретации. Мы предполагаем, что указанный глобальный контекс известен и автору информации, и читателю информации до такой степени, что одна и таже фраза будет ими интерпретирована (понята) одинаково (можно сказать, что автор сообщения и его получатель будут иметь эквивалентную интерпретацию фразы).

В этом случае логика построения запроса может быть такая:

1. Запросить из базы данных все имеющиеся классы сущностей.
2. Из полученного списка типов, выбрать такой класс, который по человекочитаемому описанию соответствует искомому - “учебный план”.
3. Выбрать все сущности класса “учебный план”.
4. Для всех найденных сущностей “учебный план” запросить имена всех имеющихся признаков.
5. Из полученного списка имен признаков на основе человекочитаемого описания признаков выбрать такие признаки, которые содержат информацию о годе введения, об уровне образования и о профиле учебного плана.
6. Для всех сущностей “учебный план”, таких что “год введения” = “2021” и “уровень образования” = “среднее образование”, вывести значение признака “профиль учебного плана”.

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

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

    PREFIX : <https://semantics.lipers24.ru/schema/>
    PREFIX онтология: <https://semantics.lipers24.ru/онтология/>
    PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

    SELECT ?учебныйПлан ?профиль WHERE {
        GRAPH ?g {
            ?учебныйПлан rdf:type онтология:учебныйПлан;
                        :уровеньОбразования <https://semantics.lipers24.ru/ресурсы/уровниОбразования#СО>;
                        :годВведения "2021";
                        :профильУчебногоПлана ?профиль
        }
    }

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

Шаг вперед

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