Выравнивание двух онтологий с помощью адаптера

Немного упрощая, у меня есть онтология предметной области (D), выраженная в OWL, которая описывает устройства, их возможности, конфигурации. Также для каждого вендора хотелось бы иметь специфичную для вендора онтологию (V), которая была бы связана с доменной. Вопрос, как выровнять D и V? Возможно ли оставить V как можно ближе к условиям поставщика или просто создать подкласс классов D для V (и, возможно, сделать то же самое для свойств данных и свойств объектов)? Идея в том, что приложение использует онтологию D для запросов, а механизмы вывода максимально скрывают специфику вендора.

Первый вариант кажется более логичным (ведь семантическая технология — это взаимосвязь), но я могу предвидеть некоторые несовпадения в некоторых типах данных. Например, один поставщик может выражать уровень заряда батареи в процентах, другой использует такие слова, как высокий, средний, низкий. Я не уверен, как привести такие данные к общему знаменателю с помощью OWL. Там могут быть даже более сложные случаи, требующие применения регулярных выражений и любого сценария вуду, который обычно выполняется. (Также интересна деталь, следует ли использовать свойства данных напрямую или добавить еще один уровень косвенности, «оборачивая» свойства данных свойствами объекта и концепциями для каждого свойства данных, чтобы быть более подготовленным к математике типов).

Другими словами, похоже, что входные данные должны быть предварительно обработаны перед входом в экосистему RDF... Или, может быть, есть другие возможности?

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


person Roman Susi    schedule 01.05.2015    source источник
comment
Это, вероятно, не дубликат, но, вероятно, слишком широко, поскольку существует столько же подходов к этому, сколько и онтологий. Я думаю, что общее, что вы обнаружите, это то, что связующая онтология будет импортировать как D, так и V и будет содержать аксиомы, связывающие классы, свойства, индивидуумы и т. д. из них.   -  person Joshua Taylor    schedule 02.05.2015
comment
С точки зрения того, кто отвечает, это может быть слишком широко, но как тот, кто спрашивает, может знать это, не спрашивая. Спасибо за ответ ниже!   -  person Roman Susi    schedule 02.05.2015


Ответы (1)


В общем, вы бы соединили две онтологии, создав новую онтологию, O, которая импортирует как D, так и V и определяет набор аксиом, связывающих классы и свойства внутри них.

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

На самом деле это тот случай, который вы могли бы обработать в OWL. Например, предположим, что у V1 есть свойство объекта hasPowerLevel, которое связывает Battery с одним из индивидуумов High, Medium. > и Низкий. Предположим, что V2 имеет свойство типа данных hasPercentageRemaining, которое связывает PowerCell с целым числом в диапазоне [1100]. Сначала вы должны определить взаимосвязь между Battery и PowerCell. Это может быть что-то из следующего, например, или что-то совсем другое. Это будет зависеть от конкретной семантики классов.

Аккумулятор PowerCell
Аккумулятор PowerCell
Аккумулятор PowerCell
Аккумулятор PowerCell hasPowerSource-1

Тогда вам придется связать свойства. Это может быть в духе

(hasPowerLevel value High) (hasPercentageRemaining some integer[>= 66])
(hasPowerLevel value Medium) (hasPercentageRemaining some integer[‹= 66, >= 33])
(имеет значение Low PowerLevel) (hasPercentageRemaining какое-то целое число[‹= 33])

Это всего лишь один пример, но он показывает, что в OWL действительно можно сделать многое из этого «связывания». hasPowerLevel

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

Эти аспекты типа данных OWL (например, то, как мы указали диапазоны целых чисел) также могут обрабатывать ограничения регулярных выражений. Тем не менее, это правда, что часто может быть проще выполнить некоторое количество промежуточных соединений, прежде чем объединять все в OWL. Здесь могут быть полезны правила SWRL, а также перенос вещей на уровень RDF и выполнение некоторой обработки на основе правил с помощью SPARQL или SPIN.

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

person Joshua Taylor    schedule 02.05.2015
comment
Спасибо, это ответ на вопрос. Один непонятный момент: какое-то количество промежуточных подключений. Означает ли это, что данные добавляются в хранилище RDF более или менее как в некоторый контекст области ввода, а затем обрабатываются SWRL/SPARQL/SPARUL или даже каким-то внешним скриптом путем добавления/обновления троек в соответствии с онтологией V1bis, которая связана с D на O (на самом деле O1, потому что могут быть V2, V3, ...)? - person Roman Susi; 02.05.2015