На пути к 4D или вперед в недалекое прошлое?

Наталья Кеберле

В продолжение темы, поднятой в заметке «На пути к 4G»… (Щербак)

Действительно, в «пироге языков Semantic Web», куда входит OWL ( и даже его версия OWL 1.1) все языки статичны. В них нет поддержки концепций пространства и времени на уровне логических конструкций языка. Пока разработчик может рассчитывать на «ручную» обработку и заполнение тегов rdf:comment (если онтология описана только в RDF Schema) или тегов owl:priorVersion, owl:versionInfo, owl:backwardCompatibleWith, owl:incompatibleWith, которые W3C зарезервировала на будущее.

Попробуем выяснить, насколько далеко от нас это будущее.

Оставим в стороне вопрос представления пространства в онтологии (это будет основой для другой заметки) и обратимся к представлению оси времени.

В 2004 году Jerry Hobbs & Feng Pan сформулировали онтологию времени для OWL. В 2006 году она была принята в качестве черновика в W3C (WD-owl-time-20060927). Определения в онтологии сгруппированы в два пространства имен: time (http://www.w3.org/2006/time)для основных временных сущностей и отношений между ними, и tzont (http://www.w3.org/2006/timezone) – для определения временных зон.

Как же можно использовать OWL-time? Именно для описания конкретных временных структур, или проще – конкретных размещений значимых точек/интервалов времени на оси времени, календарных дат, дней недели. С помощью OWL-time дата и время, день недели и номер месяца становятся «осмысленными» для машинной обработки.

Harry Chen (time.html и позже code.html) добавил в Jena набор rdf-ориентированных правил для обработки аксиом из теории временных отношений James Allen и создал rdf-ориентированную темпоральную машину вывода, которой под силу вывести длительность интервала времени, принадлежность момента времени интервалу, преобразовать значение момента времени с учетом временной зоны.

Что нельзя сделать в этой машине вывода: выявить под-интервалы; выявить точки внутри интервала, явно не определенные в конкретной временной структуре; нет понятия «бесконечно давно», или «в бесконечном будущем».

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

Итак, суммируем: OWLtime подходит как средство представления конкретных дат на оси времени в виде, пригодном для вывода отношений между этими датами.

Теперь представим, что онтология хранится в некотором rdfstore. Действительно, применить стандартные системы управления версиями вроде cvs не удастся без дополнительных усилий. Но, оказывается, есть средства работы с временем/датой с в rdf store. Если хранилище организовано на базе реляционной СУБД, то хорошо известный язык TSQL2 (Temporal SQL), который отчасти поддерживается в Oracle 10g, дает возможность прямых запросов о времени жизни конкретной записи (в нашем случае, rdf-трипла), и хотя бы таким способом обработать ситуации с временной компонентой.

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

Попыток создать (хотя бы на бумаге) язык онтологий, в котором будут присутствовать элементы временной логики (те же конструкции «раньше\позже») было уже несколько. Основная проблема возникает в поддержке такого языка машиной вывода.

Пожалуй, первой попыткой реализовать OWL с метрическим временем является язык OWL-MeT (owl-met), который снабжается машиной вывода на основе Pellet, для проверки выполнимости утверждений с временными контекстами.

Даже при тех ограничениях, которые накладывают на OWL-MeT требования разрешимости, язык позволяет определять овремененные концепты.

Например, если мы знаем об объекте, что:

Сейчас человек — студент университета;

Студентом ему быть несколько моментов времени (лет);

Непосредственно перед поступлением он был абитуриентом;

Закончив университет, он станет выпускником пожизненно,

то в OWL-MeT «Студент» будет определяться так (нотация упрощена, чтобы убрать несущественные детали):

<TClass ID=»Абитуриент»/>

<TClass ID=»Выпускник»/>

<TClass ID=»Студент»>

<equivalentClass>

<intersectionOf>

<TRestriction>

<somepast resource=»#Абитуриент»>

</TRestriction>

<TRestriction>

<allfuture>

<TClass>

<unionOf>

<TClass about=»#Студент»/>

<TClass about=»#Выпускник»/>

</unionOf>

</TClass>

</allfuture>

</TRestriction>

</intersectionOf>

</equivalentClass>

</TClass>

(больше примеров на синтаксис см. OWL-MeT-examples)

Соответственно, все экземпляры абитуриентов, которые потом побыли студентами и стали выпускниками составят модель для такого концепта.

Возможно, следуя в этом направлении (пополнения OWL разными логиками, в т.ч. логиками для рассуждений о пространстве), мы, наконец, придем к желанным 4D онтологиям. Это – дело уже недалекого будущего!


Понравилась статья? Поделитесь с друзьями!


7 Responses to На пути к 4D или вперед в недалекое прошлое?

  1. YepAll:

    Таак.. Всё не так просто как я предпологал..

  2. К сожалению все очень не просто… но радует, что в этой теме работает много людей, которые поделятся информацией с читателями shcherbak.net 😉

  3. Виктор:

    Было бы интересно узнать поподробнее

  4. ng:

    При некоторых органичениях можно смоделировать привязку к оси времени стандартными средствами .
    Допустим, у нас есть только обычный OWL, есть исторические данные о людях, живших в разные века, и нам интересно знать, как в разные века понимали, что такое «СчастливыйОтец».
    Строго говоря, нужно получить по каждому веку «список» счастливых отцов.
    В каждом веке для такого понятия можно сформулировать набор определений. Уточнять, как именно наши предки понимали счастье отца я не буду, мнений много, но понятно, что по-разному в разное время.
    Чтобы отличать разные наборы определений, заводим такие вспомогательные концепты: для 21-ого века используют концепт «СчастливыйОтецВ21веке», в 20м — «…В20веке» и т.д., и присваиваем каждому концепту набор соответствующих определений.
    Дальше создаем класс «МоментВремени» и перечисляем все начала веков, которые нас интересуют.
    Дальше определяем собственно века — для каждого века задавая интервалы времени, и получая классы «21век», «20век» и т.д.
    Наконец, определяем окончательно: «СчастливыйОтецВ21веке» equivalent «СчастливыйОтецВ21веке» intersection «21век»
    Проверяя модель, получим искомый список.
    Когда же проверим модель для
    «СчастливыйОтец» equivalent «…в21веке» union «…в20веке» union …,
    узнаем всех счастливых отцов.

    Такое решение предложено было на OWLED 2008

    OWL-time сюда хорошо подойдет.

  5. Ввод штампа времени (time stamp) или «момента времени» это подход к определению времени в онтологиях логичный и даже достаточно удобный…но в результате имеем громозкое решение и что-то мне кажется весьма неэффективное… Имхо 😉

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

    будет ли конкретно это экспонента надо бы еще проверить, но то что объемы таблиц будут расти очень быстро — это однозначно ❗ Представьте себе частоту дискретизации состояния объекта в 1 секунду. Пусть среднее число килобайт памяти занимаемой экземпляром объекта — 20, то делая копию объекта даже раз в секунду мы имеем 20×60=1200кб… что скажем честно многовато!

    Кроме того, возникает вопрос, что считать текущим состоянием объекта? И где та грань, которая отделает объект «сейчас» от объекта «потом»?…

    Мне, в частности, больше нравиться подходы к представлению состояний объектов («во времени»), которые реализованы в системах контроля версий типа SVN.
    😀

  6. ng:

    да, решение супергромоздкое, даже не ИМХО, даже при условии использования быстрого триплстора. Оптимизировать можно в процессе «вычисления», но тоже алгоритмы еще придумать надо.

  7. vamakin:

    Добрый день!
    На сколько описанное в статье состояние 4d онтологий соответствует сегодняшнему и какие из нерешенных задач наиболее актуальны? Просто, выбираю тему для диссертации, и эта область кажется наиболее интересной и перспективной.
    P.S. про форум знаю, но регистрация закрыта.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


Ответить с помощью ВКонтакте: