Комментарии 9
Думаю, добавление условий и связей превратит эту технологию в SQL.
Хотя, именно этот метод был бы удобен для тех, кому привычнее консоль.
Хотя, именно этот метод был бы удобен для тех, кому привычнее консоль.
Занимался реализацией подобного проекта (интеграция нескольких ИС + MDM на основе RDF-хранилища). Т.к. множество аспектов не стандартизовано, а подводные камни каждый обходит по-своему, хотелось бы узнать подробнее о деталях реализации, если Вас не затруднит.
1. Каким образом организовано разграничение привилегий для различных сервисов (на уровне частей онтологии/на уровне веб-сервиса)?
2. Как разрешаются конфликты репликации (в трёх различных ИС различные значения заданного поля сущности)?
3. Как ведётся версионирование данных (RDF Refine, Talis changeset, RDFSync и т.д.)? Как решались проблемы с производительностью?
1. Каким образом организовано разграничение привилегий для различных сервисов (на уровне частей онтологии/на уровне веб-сервиса)?
2. Как разрешаются конфликты репликации (в трёх различных ИС различные значения заданного поля сущности)?
3. Как ведётся версионирование данных (RDF Refine, Talis changeset, RDFSync и т.д.)? Как решались проблемы с производительностью?
Спасибо за интерес к посту! Отвечаю.
1. Обоими способами. Каждая клиентская система обладает только той частью общей онтологии, которая ей нужна. Плюс на сервере есть настройки прав доступа — в визуальном интерфейсе администратор может настроить, какие элементы онтологии будут доступны каким системам (на чтение и на запись). Есть функция выгрузки онтологии с сервера на клиент: сервер передает клиенту часть общей онтологии, отфильтрованную в соответствии с правами доступа.
2. По идее, такие ситуации должны предупреждаться настройкой прав, но если, скажем, две системы имеют право изменять одно и тоже свойство, к примеру телефон клиента, и делают это одновременно — «победит» та, чье сообщение будет позже доставлено серверу. Ее версия значения и будет распространена всем системам.
3. До версионирования пока не добрались, хотя проблема очень актуальна. Производительностью как раз сейчас занимаемся, много что оптимизируем под нее. Надеюсь в ближайшее время написать статью на эту тему.
1. Обоими способами. Каждая клиентская система обладает только той частью общей онтологии, которая ей нужна. Плюс на сервере есть настройки прав доступа — в визуальном интерфейсе администратор может настроить, какие элементы онтологии будут доступны каким системам (на чтение и на запись). Есть функция выгрузки онтологии с сервера на клиент: сервер передает клиенту часть общей онтологии, отфильтрованную в соответствии с правами доступа.
2. По идее, такие ситуации должны предупреждаться настройкой прав, но если, скажем, две системы имеют право изменять одно и тоже свойство, к примеру телефон клиента, и делают это одновременно — «победит» та, чье сообщение будет позже доставлено серверу. Ее версия значения и будет распространена всем системам.
3. До версионирования пока не добрались, хотя проблема очень актуальна. Производительностью как раз сейчас занимаемся, много что оптимизируем под нее. Надеюсь в ближайшее время написать статью на эту тему.
Планы написать статью про производительность накрылись, или ещё теплятся? Очень интересно!
Версионирование тоже интересно!
Версионирование тоже интересно!
Проблему версионирования решили в рамках другой разработки, скоро доложим на KESW 2014.
По производительности делали кое-какой бенчмарк в прошлом году.
В личку могу поделиться результатами.
По производительности делали кое-какой бенчмарк в прошлом году.
В личку могу поделиться результатами.
1. А в сообщениях идет набор триплетов или один триплет?
2. Атрибуты сообщения тоже закодированы в RDF? (дата создания/исходящая система)
3. Табличные данные вы также передаете или уровнем Data Integration?
2. Атрибуты сообщения тоже закодированы в RDF? (дата создания/исходящая система)
3. Табличные данные вы также передаете или уровнем Data Integration?
1. Набор триплетов. Буквально сегодня выложил статью об определении оптимального количества информационных объектов и триплетов в пакете
2. Исходящая система определяется в процессе авторизации, дата создания тоже автоматически фиксируется сервером. Но некоторые атрибуты сообщения все же попадают в само сообщение.
3. Пока также передаем, но имеется насущная необходимость разработать режим передачи табличных данных (прежде всего, для первоначальной синхронизации систем) — этим сейчас занимаемся.
2. Исходящая система определяется в процессе авторизации, дата создания тоже автоматически фиксируется сервером. Но некоторые атрибуты сообщения все же попадают в само сообщение.
3. Пока также передаем, но имеется насущная необходимость разработать режим передачи табличных данных (прежде всего, для первоначальной синхронизации систем) — этим сейчас занимаемся.
Если вы еще не слышали, советую посмотреть на то, как семантический веб используется в интеграции данных в разных около-промышленных областях — у них там есть международный страндарт ISO 15926 для интеграции данных, и в нем описываются технологии Semantic Web.
Русскоязычное сообщество пользователей стандарта — .15926. Уже даже есть русскоязычный софт для работы с интеграцией данных, все на Semantic Web технологиях, опять же.
Русскоязычное сообщество пользователей стандарта — .15926. Уже даже есть русскоязычный софт для работы с интеграцией данных, все на Semantic Web технологиях, опять же.
Я знаком с этим стандартом, и являюсь читателем этого сообщества. Тут все далеко не так просто, и на тему отношения нашего подхода и ISO 15926 я также писал отдельную статью. Кстати, в том самом сообществе хватает «критики», а точнее, не совсем разумного противопоставления Semantic Web и ISO 15926. С одной стороны, понятно, что стандарт представляет собой более высокоуровневый подход, с другой — я уверен, что во многих практических применениях наш подход намного рациональнее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Технологии Semantic Web для интеграции информационных систем