Потеря информации при сохранении строк базы данных в граф и RDF?

Question

Предположим, у меня есть строки данных, полученных из таблиц реляционных баз данных (возможно, путем объединения таблиц). Каждая строка имеет несколько столбцов (таких как A, B, C, D ..), и следующие строки - это то, что у меня есть.

А1, В1, С1, D1,

А1, В2, С1, D1,

А1, В2, С1, D2,

Если бы я нарисовать сетевой график среди лиц, я может сохранить информацию в RDF путем создания нескольких троек, таких как

А1 В1 connectsTo

В1 connectsTo С1

С1 connectsTo D1

А1 connectsTo В2

В2 connectsTo С1

С1 connectsTo D2 (и в противоположном направлении, а)

Таким образом, в двунаправленной графике они будут

A1 - B1 - C1 - D1

'----- B2 ---' '--- D2

Проблема в этом подходе заключается в том, что я ввел двусмысленность, потому что, посмотрев на приведенный выше график, я также могу получить соединение между A1 - B1 - C1 - D2, которое у меня не было в оригинале строк. Мой первый вопрос - В общем, это то, что происходит при сохранении строк базы данных в сетевом графике (или я что-то не так?)

Чтобы сохранить исходную информацию, я мог бы объединить четыре объекта в каждом строка в bnode, но я обеспокоен тем, что это даст мне такую ​​же гибкость (и производительность) при создании графических соединений, как и раньше. Возможно, мне нужно будет просто захватить все соединения между As и Bs или другими комбинациями подмножеств позже. И это будет не так эффективно, как раньше, потому что вам нужно будет хранить дублируемую информацию в разных bnodes.

So мой второй вопрос: - Каков наилучший способ хранения строк в RDF, но при этом сохраняйте гибкость и производительность? Я просмотрел рекомендации WWW.org по отображению RDF в RDF (http://www.w3.org/TR/r2rml/, а также http://www.w3.org/TR/rdb-direct-mapping/), но, похоже, мне пришлось бы группировать данные под одним и тем же идентификатором строки, чтобы сохранить данные. Это единственный способ?

Спасибо.

Answer 1

В ваших рядах содержатся n-арные отношения (с n = 4). Таким образом, у вас есть четыре вещи, которые находятся в некотором отношении друг к другу. RDF основан на двоичных отношениях (n = 2), поэтому вы можете только выразить, что две вещи находятся в отношениях друг с другом. Чтобы представить n-арные отношения в RDF, вам всегда нужно ввести дополнительный узел и подключить к нему n элементов. W3C имеет длинный список лучших практик по этой теме: Defining N-ary Relations on the Semantic Web.

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

Answer 2

Ваше заявление, что вы хотите, чтобы «C1 connects To D1» выглядело странно. Я не буду говорить, что это неправильно, потому что ваш пример настолько абстрагирован, не дает никаких намеков на то, что ваши данные.

В большинстве сред данных sql/rdb имеется первичный ключ (или составной ключ), который идентифицирует строку. Без него «почти» невозможно обновить строку после того, как вы ее удалили. Я говорю «почти», потому что базы данных, которые могут это сделать, имеют «скрытый» столбец, который однозначно идентифицирует строку (например, postgres oid).

Понятно, что строка в базе данных соответствует теме (первичный ключ карты для объекта), а столбец соответствует предикату. Фактическое значение данных затем соответствует объекту в тройке. Добавьте свой uri в пространство имен и от вас.

Для затянувшегося примера сопоставления вашего отношения к троек вы можете посмотреть d2rq-language. Если мое предположение имеет место (у вас есть первичный ключ), то ваша производительность должна быть прекрасной, и вы можете использовать SPARQL или простые тройки, чтобы получить ваши данные достаточно эффективно. Если предположение неверно, вы можете пойти с bnodes или даже с «тройными» тройками, которые вы описали, но в вашем примере недостаточно информации, чтобы дать хорошее руководство.

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