Данный документ представляет собой перевод на русский язык Заметки Рабочей Группы W3C от 12 Апреля 2006.
Defining N-ary Relations on the Semantic Web, W3C Working Group Note 12 April 2006,
английский вариант которой является единственным официальным изданием.

Перевод данной заметки на русский язык выполнен специалистом компании Ранат Рабчевским Е.А.
 
Перевод может содержать ошибки и неточности, и мы работаем над его улучшением. 
Все комментарии, касающиеся настоящего перевода, просьба направлять по адресу: evgeny@ranat.ru
Copyright © 2006 Ранат, Все права защищены. Перевод на русский язык.

Определение N-мерных отношений в Семантической Сети

Заметка Рабочей Группы W3C от 12 Апреля 2006

Эта версия:: http://www.w3.org/TR/2006/NOTE-swbp-n-aryRelations-20060412/
Последняя версия:: http://www.w3.org/TR/swbp-n-aryRelations
Предыдущая версия:: http://www.w3.org/TR/2004/WD-swbp-n-aryRelations-20040721/
Авторы:: Natasha Noy, Стэнфордский Университет; Alan Rector, Университет Манчестера
Соавторы:: Pat Hayes, IHMC; Chris Welty, IBM Research
: Также смотри Благодарности.

Аннотация

В языках Семантической Сети, таких как RDF и OWL, свойство являются двойными отношением: оно используется, чтобы связать два концепта или концепт со значением. Однако, в некоторых случаях, естественный и удобный способ представить определенные концепты - это использовать отношения для связи концепта с более чем одним концептом или значением. Эти отношения называются N-мерными отношениями. Например, мы хотим представить свойства отношения, такие как степень нашей уверенности в этом, четкость или сила отношения, релевантность отношения, и так далее. Другой пример показывающий отношения между множеством концептов, таких как покупатель, продавец, и объект, который был куплен, при описании покупки книги. Этот документ представляет N-мерные отношения в RDF и OWL, и обсуждает, что пользователи должны рассматривать, когда выбирают эти модели.

Статус этого документа

Этот секция описывает статус этого документа на момент его публикации. Другие документы могут заменять собой этот документ. Список настоящих W3C публикаций и последняя версия этого технического сообщения могут быть найдены в указателе технических сообщений W3C на http://www.w3.org/TR/.

Этот документ является Заметкой Рабочей Группы, сделанной Рабочей Группой Лучшей Практики и Развертывания Семантической Сети, частью Сообщества Семантической Сети W3C. Это документ - один из набора документов, обеспечивающих введение и обзор моделей разработки онтологий, разработанных Специальной Комиссией Разработки Онтологий и Моделей Рабочей Группы SWBPD.

Что касается публикации этой Заметки Рабочей Группы SWBPD, Рабочая Группа закончила работу над этим документом. Изменения предыдущего Рабочего Проекта собраны в приложении. Комментарии к этому документу могут быть посланы на public-swbp-wg@w3.org, почтовую рассылку с общим архивом. Дальнейшее обсуждение по этому материалу может также быть послано на почтовый список Группы Интересующихся Семантической Сетью, semantic-web@w3.org, также с публичным архивом.

Публикация как Заметка Рабочей Группы не подразумевает одобрения W3C Сообществом. Это черновик документа, и может быть обновлен, перемещен или устареть из-за других документов со временем. Неуместно ссылаться на этот документ, также как и на другие, работа над которыми в процессе.

Этот документ произведен группой, работающей в соответствии с Патентной Политикой W3C от 5 Февраля 2004. Этот документ только информативный. W3C поддерживает публичный список всех объявлений патентов , сделанный в соответствии с подлежащими передаче групп; эта страница также включает инструкции для объявления патентов. Человек, который имеет актуальные информацию по патентам, в которых видит содержание Существенных Требований должен объявить информацию в соответствии с секцией 6 Патентной Политики W3C.

Основные проблемы
Примеры вариантов использования
Представление шаблонов
N-мерные отношения и материализация в RDF
Дополнительные Предпосылки
Ссылки
Изменения
Благодарности

Основные проблемы

В языках Семантической Сети, таких как RDF и OWL, свойства являются двойным отношением: экземпляры свойств связывают два концепта. Часто мы ссылаемся на второй концепт, как на "значение" или оба концепта, как "аргументы" [Смотри замечания к словарю].

Проблема 1: Если экземпляр свойства может связать два концепта, как нам вести дело с ситуациями, где нам нужно описать экземпляры отношений, таких как уверенность, сила, и т.д.?

Проблема 2: Если экземпляр свойства может связать два концепта, как нам представлять отношения между более чем двумя концептами? ("n-мерные отношения")

Проблема 3: Если экземпляр свойства может связать два концепта, как нам представить отношения, в которых один из участников является скорее упорядоченным списком концептов, чем одиночный концепт?

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

Описание данных, используемое в этом документе

Формат данных, используемый в этом документе это TURTLE [TURTLE], используется чтобы детально показать каждый триплет. Черепаха позволяет URI-ям быть сокращенными с префиксами:

@prefix dc:   <http://purl.org/dc/elements/1.1/> .
@prefix :     <http://example.org/book/> .
:book1  dc:title  "Defining N-ary Relations on the Semantic Web" .

Примеры вариантов использования

Несколько общих вариантов использования подпадают под категорию n-мерных отношений. Здесь показаны несколько примеров:

Очень вероятно, что Кристина имеет опухоль в груди. Здесь двойное отношение между персоной Кристина и диагнозом Опухоль_Груди_Кристины и качественное значение вероятности описывает это отношение (очень).
Стив имеет температуру, которая высока, но падает. Концепт Стив имеет два значения двух различных аспектов для отношения имеет_температуру: это величина, которая высокая и тенденция, которая падает.
Джон покупает книгу "Лев Ленни" с books.example.com за $15 в подарок на день рождения. Это отношение, в котором принимают отношение Джон, сущность books.example.com и книга Лев_Ленни. Это отношение имеет другие компоненты, такие как цель (подарок_на_день_рождения) и число ($15).
Полет 3177 Объединенных Авиалиний посещает следующие аэропорты: LAX, DFW, и JFK. Это отношение между концептом полет и тремя городами, которые посещаются, LAX, DFW, JFK. Заметьте, что порядок аэропортов имеет значение, и указывает порядок, в котором рейс посещает эти аэропорты.

Другой способ подумать о вариантах использования - это как они могут возникнуть в процессе эволюции онтологии.

Мы понимаем, что отношения, которые, как мы думали, были двойными, реально, нуждаются в аргументах, сверх того - общий исток варианта использования 1.
Мы понимаем, что двойные свойства всегда шагают вместе, должны быть представлены одним n-мерным отношением - общий исток варианта использования 2.
Сначала, мы понимаем отношение, реально среди нескольких вещей - общий исток варианта использования 3.
Природа отношения, где один или более аргументов качественно являются скорее последовательностью, чем отдельным концептами - вариант использования 4.

Представление шаблонов

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

Свойство P, соотносящее ресурсы A и B

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

Свойство P, соотносящее ресурсы A, В и С

'P' теперь ссылается на экземпляр отношения между 'A', 'B', и 'C'. (Здесь могли быть и другие концепты 'D', 'E', и 'F'. Однако, для простоты, мы покажем большинство вариантов использования, предполагая одиночный дополнительный концепт. Таким же способом мы можем обрабатывать большее количество концептов.)

Одно общее решение этой проблемы (шаблон 1) - это представить отношение, скорее как класс чем свойство. Экземпляры концептов таких классов соответствуют экземплярам свойств. Дополнительные свойства обеспечивают двойные связи для каждого аргумента отношения. Мы можем моделировать примеры 1, 2, и 3 помимо использования этого шаблона. Например, в примере 1 экземпляр нового класса Отношение_Диагноза представлял бы факт того, что Кристине был поставлен диагноз опухоль груди с высокой вероятностью. Аналогично, в примере 3 экземпляр класса Покупка представлял бы факт того, что Джон купил книгу "Лев Ленни" на books.com за $15.

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

Словарь для n-мерных отношений в RDF и OWL

Комиссия планирует выпустить предложенный словарь для описания класса, представляющего n-мерные отношения, и для описания картирования между n-мерными отношениями в RDF и OWL и других языках. Планируется выпустить замечания к этому словарю.

Шаблон 1: Введение нового класса для отношения

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

Онтологически, классы, создаваемые в этом методе, часто называются "рейфированными отношениями" (reified relations). Рейфированные отношения играют важную роль во многих онтологиях³ (например Ontoclean/DOLCE, Sowa, GALEN). Однако, сообщества RDF и Topic Map использовали слово "рейфировать", чтобы обозначить разные вещи (смотри замечания ниже). Таким образом, чтобы избежать конфузов, мы не используем термин "рейфикация" в этом документе.

Вариант Использования 1: дополнительные атрибуты, описывающие отношение

В первом варианте использования, нам необходимо представить дополнительный атрибут, описывающий экземпляр отношения (пример 1, Кристина имеет опухоль груди с высокой вероятностью). Мы создаем концепт, который представляет экземпляр отношения само по себе, со связями субъекта отношения к этому экземпляру и со связями этого экземпляра ко всем участникам, которые представляют дополнительную информацию об этом экземпляре:

pattern 1

Для примера 1, выше (Кристина имеет опухоль груди с высокой вероятностью), концепт Кристина имеет свойство имеет_диагноз, которое имеет другой объект (_:Отношение_Диагноза_1, экземпляр класса Отношение_Диагноза) в качестве этого значения:

Пример диагноза

Концепт _:Отношение_Диагноза_1 здесь представляет одиночный объект, инкапсулирующий оба диагноза (Опухоль_Груди_Кристины, особенный экземпляр Болезнь) и вероятность диагноза (HIGH)³. Это содержит всю информацию, содержащуюся в оригинале 3 аргумента: кто был продиагностирован, какой диагноз, и какова его вероятность. Мы используем пустые узлы в RDF чтобы представить экземпляры отношения.

:Кристина
      a       :Персона ;
      :имеет_диагноз _:Отношение_Диагноза_1 .

:_Отношение_Диагноза_1
      a       :Отношение_Диагноза ;
      :вероятность_отношения :ВЫСОКАЯ;

      :значение_жиагноза :Опухоль_Груди_Кристины .

Каждый из 3 документов в оригинальном n-мерном отношении— кто диагностируется, какой диагноз, и его вероятность—дают повод для правдивых двойных отношений. В этом случае, есть три: имеет_диагноз, значение_диагноза и вероятность_диагноза.⁴

Определения классов для концептов в этом шаблоне выглядит следующим образом:

Классы в примере Диагноза

Дополнительные метки на связях указывают OWL ограничения на свойства. Мы определяем и значение_диагноза, и вероятность_диагноза в качестве функциональных свойств, таким образом требующих, чтобы каждый экземпляр Отношения_Диагноза имел точно одно значение для Болезни и одно значение для Вероятности.

В RDFS, которая не имеет OWL ограничений функциональных свойств, связи представляют ограничение свойств rdfs:range. Например, класс Отношение_Диагноза - это диапазон свойства имеет_диагноз.

Здесь определение класса Отношение_Диагноза в OWL, предполагается, что оба свойства—значение_диагноза и вероятность_диагноза—описаны, как функциональные (мы предоставляем полный код примера на OWL и RDFS ниже):

:Отношение_Диагноза
      a       owl:Class ;
      rdfs:subClassOf

	             [ a       owl:Restriction ;
                owl:someValuesFrom :Болезнь ;
               
	             owl:onProperty :значение_диагноза
              ] ;
      rdfs:subClassOf
      
	                    [ a       owl:Restriction ;
                owl:allValuesFrom :Probability_values ;
  
	                                 owl:onProperty :вероятность_диагноза
              ] .

В определении класса Персона (экземпляром которого является Кристина), мы специфицировали свойство имеет_диагноз с ограничением диапазона - класс Отношение_Диагноза (экземпляром, которого является Отношение_Диагноза_1):

:Персона
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;

	               owl:allValuesFrom :Отношение_Диагноза ;
                owl:onProperty :имеет_диагнозbr>   
	                         ] .

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

RDFS код для этого примера

[RDFS]

OWL код для этого примера

[N3] [RDF/XML]

Вариант использования 2: различные аспекты одного отношения

Мы имеем различные варианты использования в примере 2 выше (Стив имеет температуру, которая высокая, но падает): В примере с диагнозом, многие увидят взаимоотношение, мы представляли как все еще двойное отношение между концептом Кристина и диагнозом Опухоль_Груди_Кристины, который имеет вероятность, ассоциированную с этим. В этом примере отношение между концептом Стив и объектом, представляющем различные аспекты его температуры. В большинстве подразумеваемых интерпретаций, этот экземпляр отношения не может рассматриваться, как экземпляр двойного отношения с дополнительно приложенными атрибутами. Скорее, этот экземпляр отношения, соотносящий Стива и сложный объект, представляющий различные факты о его температуре. Такие случаи часто возникают в течение эволюции онтологии, когда мы понимаем, что два отношения нужно свернуть. Например, первоначально, мы могли иметь два свойства— имеет_уровень_температуры и имеет_тенденцию_температуры—оба связанные в человеческом понимании. Мы могли тогда понять, что реально эти свойства сложно переплетаются, потому что мы должны говорить о "температуре, которая приподнятая, но падает".

Пример температуры для шаблона 1

RDFS и OWL шаблоны, которые выполняют эту интуицию (implement this intuition), однако такие же как и в предыдущем примере. Класс Персона (экземпляром которого является концепт Стив) имеет свойство имеет_температуру, которое имеет в качестве диапазона класс отношения Наблюдение_Температуры. Экземпляры класса Наблюдение_Температуры (такие как _:Наблюдение_Температуры_1 на рисунке) по очереди имеют свойства для значение_температуры и тенденция_температуры.

RDFS код для этого примера

[RDFS]

OWL код для этого примера

[N3] [RDF/XML]

Вариант Использования 3: N-мерное отношение без отмеченного участника

В некоторых случаях, n-мерное взаимоотношение связывает концепты, которые играют различные роли в структуре без каких-либо одиночных концептов, выступающих как субъект или "владелец" отношения, такого как Покупка, в примере 3 выше (Джон покупает "Лев Ленни" на book from books.example.com за $15 в подарок на день рождения). Здесь, отношение явно имеет более чем одного участника, и, во многих контекстах, никто из них не может быть описан просто одним (primary one). В этом случае, мы создаем концепты, чтобы представить экземпляры отношения со связями со всеми участниками:

Вариант использования 3

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

Пример покупки

Покупка_1⁵ является экземпляром концепта класса Покупка, класса представляющего экземпляр отношения:⁶

:Покупка_1
      a       :Покупка ;
      :имеет_покупателя :Джон ;
      :имеет_объект :Лев_Ленни ;

	     :имее_цель :Подарок_на_День_рождения ;
      :имеет_число 15 ;
      :имеет_продавца :books.example.com .

Следующая диаграмма показывает соответствующие классы и свойства. Для задачи примера, мы указываем, что каждая покупка имеет точно одного покупателя (Персона), точно одного продавца (Компания), точно одну сумму и по крайней мере один объект (Объект).

Классы примера с Покупкой

Диаграмма указывает на OWL ограничения. В RDFS стрелки могут рассматриваться как связи rdfs:range.

Класс Покупка описан по правилам OWL (для определения по RDFS смотри RDFS файл ниже):

:Покупка
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;

	               owl:allValuesFrom :Покупка ;
                owl:onProperty :имеет_цель
              ] ;
 
	                   rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:cardinality 1
	                   ;
                owl:onProperty :имеет_покупателя
              ] ;
      
	                   rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:onProperty
	                   :имеет_покупателя ;
                owl:someValuesFrom :Персона
              ] ;
 
	                       rdfs:subClassOf
              [ a       owl:Restriction ;
            
	                          owl:cardinality 1 ;
                owl:onProperty :имеет_продавца
              ]
	                          ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
      
	                                   owl:onProperty :имеет_продавца ;
                owl:someValuesFrom
	                                   :Компания
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:onProperty :имеет_объект
      ;
                owl:someValuesFrom :Объект
              ] .

Заметьте, что представление в OWL следуют из этого шаблона: OWL ограничения по существу являются тройными отношениями между классами, свойствами, и ограничениями значений. В этом случае, экземпляр класса Restriction подобен экземпляру Покупка.

RDFS код для этого примера

[RDFS]

OWL код для этого примера

[N3] [RDF/XML]

Анализ случая, когда вводится новый класс для отношения

В нашем примере, мы не дали выразительных имен для экземпляров свойств или классов, используемых, чтобы представить n-мерные отношения, а простые метки _:Наблюдение_за_Температурой_1, Покупка_1, и т.д. В большинстве случаев, эти концепты не остаются сами по себе, а просто функционируют как дополнительные службы для группировки с другими объектами. Поэтому не предполагается работа с различными именами. Заметьте, что подобный подход принимался в рейфицирующих объявлениях в RDF.
Создание нового класса, чтобы n-мерные отношения ограничивает многие OWL конструкции и создает проблемы поддержки. Проблемы возникают, когда мы хотим иметь локальный диапазон или ограничения кардинальности в некоторых ролях в n-мерном отношении, что зависит kn класса некоторых других ролей. Например, мы бы хотели сказать, что мы покупаем только экземпляры класса Книга в компаниях из категории ПродавецКниг (сравни вариант использования 3). Выражая это ограничение, требуется специальный подкласс класса n-мерного отношения, который представляет комбинацию ограничений. Например, нам потребуется создать класс Покупка_Книги с соответсвующим диапазоном ограничений для свойств продавец (allValuesFrom ПродавецКниг) и объект (allValuesFrom Книга). У нас пропала необходимость строить подробную структуру классов для представления всех возможных комбинаций.
OWL позволяет определения инверсных свойств. Определение инверсных свойств с n-мерными отношениями, использование любых шаблонов, указанных выше, требует больше работы, чем для двойных отношений. Для того чтобы указать инверсное свойство для n-мерного отношения, мы должны указать инверсию для каждого из свойств, участвующих в n-мерном отношении (с характерными ограничениями). Рассмотрим пример, Джон покупает книгу Лев_ленни. Нам может потребоваться иметь экземпляр инверсного отношения, связывающего книгу Лев_Ленни с персоной, которая купила её. Если мы имеем простое двойное отношение Джон покупает Лев_Ленни, описание инверсии просто: мы просто описываем свойство куплен_тем-то как инверсное для покупает:
```
:куплен_тем-то
      a       owl:ObjectProperty ;
      owl:inverseOf :покупает .
```
В отношении покупки, показанном для примера, однако, нам необходимо добавить инверсные отношения между участниками в отношении и самим экземпляром отношения:

Например, определения инверсных отношений для покупателя и объекта покупки, выглядит так:
```
:покупатель_для
      a       owl:ObjectProperty ;
      owl:inverseOf :имеет_покупателя .
:объект_для
      a       owl:ObjectProperty ;
      owl:inverseOf :имеет_объект .
```
В определении класса Персона, мы включаем ограничение allValuesFrom для свойства покупатель_для, чтобы ограничить значения этого свойства для экземпляров класса Покупка:
```
:Персона
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction
    	;
                owl:onProperty :покупатель_для ;
                owl:allValuesFrom :Покупка

    	             ] .
```
Заметьте, что значение инверсного свойства покупатель_для для концепта Джон, например, концепт Покупка_1 скорее чем объект или получатель покупки.

Шаблон 2: Использование списков для аргументов в отношении

Некоторые n-мерные отношения неестественно принадлежат каждому из вариантов использования, указанных выше, но более похожи на список или последовательность аргументов. Пример 4, выше (Полет 3177 Объединенных авиалиний посещает следующие аэропорты: LAX, DFW, и JFK,) попадает под эту категорию. Например, отношение между полетом и аэропортами, которые им посещаются, в порядке прибытия воздушного судна в каждый аэропорт. Это отношение могло бы содержать различное число аргументов, и здесь нет естественного способа представить это набором отдельных свойств, связывающих полет с каждым аэропортом. В некоторых случаях, порядок аргументов очень существенен.

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

Пример графа экземпляров для сегментов полета

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

Мы можем представить онтологию для этого примера на OWL. Заметьте, что использование словаря rdf:List в OWL, подразумевает использование диалекта OWL Full для онтологии (смотри соответствующую секцию OWL руководства для сравнения OWL Full и OWL DL). Следующая онтология на OWL Lite:

Пример графа классов для сегментов полета

:Полет
	a owl:Class .

:последовательность_полета
   a owl:ObjectProperty , owl:FunctionalProperty ;
   rdfs:domain :Полет ;
   rdfs:range :СегментПолета .

 :СегментПолета
    a owl:Class ;
    rdfs:subClassOf owl:Thing ;
    rdfs:subClassOf
         [ a owl:Restriction ;
             
    owl:cardinality "1";
             owl:onProperty :место_назначения
         ] ;

       rdfs:subClassOf
         [ a owl:Restriction ;
             owl:allValuesFrom :Аэропорт ;
             owl:onProperty :место_назначения
          ] .

  :следующий_сегмент
      a owl:ObjectProperty , owl:FunctionalProperty ;
      rdfs:domain :СегментПолета
  ;
      rdfs:range :СегментПолета .


:ПоследнийСегментПолета
   a owl:Class ;
   rdfs:comment "Последний сегмент полета не имеет следующий_сегмент";

      rdfs:subClassOf :СегментПолета ;
   rdfs:subClassOf
        [ a owl:Restriction ;  
            owl:maxCardinality "0";
            owl:onProperty :следующий_сегмент
         ] .

  :Аэропорт
      a owl:Class .

  :место_назначения
      a owl:ObjectProperty , owl:FunctionalProperty ;
      rdfs:domain :СегментПолета .

RDFS код для этого примера

[RDFS]

OWL код для этого примера

[N3] [RDF/XML]

N-мерные отношения и рейфикация в RDF

Может быть естественно понимать RDF рейфикацию как представление n-мерных отношений. Мы не хотим использовать RDF словарь рейфикации, чтобы представить n-мерные отношения, в основном, по следующим причинам. Словарь RDF рейфикации разработан, чтобы говорить об объявлениях—концептов, которые являются экземплярами rdf:Statement. Объявление - это триплет объекта, предикаты, субъекта и рейфикация в RDF, используются чтобы поместить дополнительную информацию к этому триплету. Эта информация может включать исходник информации в триплете, например. В n-мерных отношениях, однако, дополнительные аргументы в отношении, не всегда характеризуют объявление, а скорее предоставляют дополнительную информацию о самом экземпляре отношения. Таким образом, это более естественно говорить о экземплярах отношения диагноза или покупки, чем об объявлении. Во всех вариантах использования, которые мы обсуждаем в заметке, необходимо говорить о экземплярах отношения, а не о объявлениях таких экземпляров.

Дополнительные Предпосылки

Замечание к словарю: Отношения и экземпляры Отношений, Свойства и экземпляры Свойств

Мы обычно понимаем языки семантической сети, как состоящие из триплетов формы "Концепт1-Свойство-Концепт2" (традиционно, это было названо триплетом "объект-атрибут-значение", но мы не хотим использовать этот язык здесь, потому что это конфликтует с использованием RDF).

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

Неименованные экземпляры против именованных в этих шаблонах

Часто в случаях, как вариант использования 1, мы хотим рассматривать два концепта отношения, в котором аргументы эквивалентны. Мы можем захватить эту интуицию (capture this intuition) с помощью использования пустых узлов RDF (то есть, _:отношение_Диагноза), чтобы представить экземпляры отношения. В варианте использования 2, мы хотим рассмотреть вероятность того, что здесь могут быть две отдельные покупки с одинаковыми аргументами. В этом случае, узел должен быть назван, например Покупка_1.

Замечания

"Рейфицированные отношения" играют важную роль или имеют специальный статус в ряде онтологий, например, смотри Sowa, J. Knowledge Representation. Morgan Kaufmann, 1999; Welty, C. and Guarino, N. Supporting ontological analysis of taxonomic relationships. Data and Knowledge Engineering, 39 (1). 51-74.
Для простоты, мы представляем каждую болезнь как концепт. Это решение не всегда может быть подходящим, и мы обращаемся к читателю для (написания) различных замечаний. Аналогично, для простоты, в OWL мы представляем вероятность значений, как класс, который является списком из трех концептов (ВЫСОКАЯ, СРЕДНЯЯ, и НИЗКАЯ):
```
:Значение_вероятности
      a       owl:Class ;
      owl:equivalentClass
              [ a       
    	owl:Class ;
                owl:oneOf (:ВЫСОКАЯ :СРЕДНЯЯ :НИЗКАЯ)
              ] . 
```
Есть другие способы представить распределение значений. Пожалуйста обратитесь к замечаниям по Представлению Особых Значений в OWL [Особые Значения]. В версии RDF Schema, мы представляем их просто, как строки, также для простоты.
RDF имеет свойствоrdf:value, которое подходяще для примеров, таких как пример Диагноза здесь. Пока rdf:value не имеет собственного значения, RDF спецификация одобряет использование этого, как элемента словаря, чтобы идентифицировать "главный" компонент структурированного значения свойства. Поэтому, в нашем примере, мы сделали значение_диагноза подсвойством свойства rdf:value, вместо того, чтобы сделать это прямым экземпляром rdf:Property, чтобы указать, что значение_диагноза действительно является "главным" компонентом диагноза.
Заметьте, что здесь мы скорее используем именованные концепты для экземпляра класса Покупка (Покупка_1), чем неименованный пустой узел. В этом примере, может быть две отдельных покупки с точно такими же аргументами.
Для простоты, мы будем игнорировать факт того, что сумма выражена в $, и будем использовать простое число, как значение для свойства. Для обсуждения, как представлять единицы измерения и величины в OWL, пожалуйста, обращайтесь к различным замечаниям (которые будут написаны)

Ссылки

[Specified Values]: Representing Specified Values in OWL: "value partitions" and "value sets", Alan Rector, Editor, W3C Working Draft, 3 August 2004, http://www.w3.org/TR/swbp-specified-values/ .
[OWL Overview]: OWL Web Ontology Language Overview, Deborah L. McGuinness and Frank van Harmelen, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-features-20040210/ . Latest version available at http://www.w3.org/TR/owl-features/ .
[OWL Guide]: OWL Web Ontology Language Guide, Michael K. Smith, Chris Welty, and Deborah L. McGuinness, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-guide-20040210/ . Latest version available at http://www.w3.org/TR/owl-guide/ .
[OWL Semantics and Abstract Syntax]: OWL Web Ontology Language Semantics and Abstract Syntax, Peter F. Patel-Schneider, Patrick Hayes, and Ian Horrocks, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-semantics-20040210/ . Latest version available at http://www.w3.org/TR/owl-semantics/ .
[RDF Primer]: RDF Primer, Frank Manola and Eric Miller, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-primer-20040210/ . Latest version available at http://www.w3.org/TR/rdf-primer/ .
[RDF Semantics]: RDF Semantics, Pat Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ . Latest version available at http://www.w3.org/TR/rdf-mt/ .
[RDF Vocabulary]: RDF Vocabulary Description Language 1.0: RDF Schema, Dan Brickley and R. V. Guha, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ . Latest version available at http://www.w3.org/TR/rdf-schema/ .
[Turtle]: "Turtle - Terse RDF Triple Language, Dave Beckett.

Изменения

Соединены шаблоны 1 и 2 в один шаблон с разными вариантами использования. Те же варианты использования остаются, но они описываются, как различные варианты использования для одного шаблона.
Удалено рассмотрение моментов обсуждения логической эквивалентности шаблонов 1 и 2 (так как теперь они являются одним шаблоном).
Добавлено больше обсуждения Основных Проблем и Вариантов Использования
Добавлен шаблон 2 (использование rdf:Lists)
Добавлен пример полета
Изменена формулировка "Представление Шаблонов"
Используются пустые узлы для экземпляров отношения в шаблоне 1 и шаблоне 2
Добавлена секция N-мерные отношения и рейфикация в RDF
Добавлена секция Дополнительные Предпосылки
Добавлены ссылки
Изменены некоторые соотношения "отношение" с "экземпляр отношения"
Удалены примеры в абстрактном синтаксисе
Добавлены Благодарности

Благодарности

Авторы хотели бы поблагодарить следующих членов Рабочей Группы за их участие в этом документе: Pat Hayes, Jeremy Carroll, Chris Welty, Michael Uschold, Bernard Vatant. Frank Manola, Ivan Herman, Jamie Lawrence также поучаствовали в работе на документом.

Этот документ - продукт Специальной Комиссии Разработки Онтологий и Шаблонов Рабочей Группы Лучшей Практики и Развертывания Семантической Сети.

Определение N-мерных отношений в Семантической Сети

Заметка Рабочей Группы W3C от 12 Апреля 2006

Аннотация

Статус этого документа

Оглавление

Основные проблемы

Описание данных, используемое в этом документе

Примеры вариантов использования

Представление шаблонов

Словарь для n-мерных отношений в RDF и OWL

Шаблон 1: Введение нового класса для отношения

Вариант Использования 1: дополнительные атрибуты, описывающие отношение

RDFS код для этого примера

OWL код для этого примера

Вариант использования 2: различные аспекты одного отношения

RDFS код для этого примера

OWL код для этого примера

Вариант Использования 3: N-мерное отношение без отмеченного участника

RDFS код для этого примера

OWL код для этого примера

Анализ случая, когда вводится новый класс для отношения

Шаблон 2: Использование списков для аргументов в отношении

RDFS код для этого примера

OWL код для этого примера

N-мерные отношения и рейфикация в RDF

Дополнительные Предпосылки

Замечание к словарю: Отношения и экземпляры Отношений, Свойства и экземпляры Свойств

Неименованные экземпляры против именованных в этих шаблонах

Замечания

Ссылки

Изменения

Благодарности