Comments 7
Интересно. У нас была такая же проблема, но мы не решаем вопрос добавления авторицации к запросам на обновление и удаление, так как наша система используется не как первичный каталог данных, а как точка сбора информации из многих внутренних систем. Аутентификация и процессы работы с данными происходят не у нас.
Таким образом мы только забираем данные из подключённых систем (с помощью SDShare: sdshare.org/ ) и доверяем запросам на обновление и удаление от клиентов.
А так как напрямую никто с нашим endpoint тоже не говорит (наружу мы показываем данные только как SDShare потоки, очень похожие на Atom feed c RDF/XML или n3 в теле поста), то прокси нам был не нужен, мы зашиваем наши проверки авторизации в SPARQL, который генерирует списки документов и содержание документов.
Ясно, интересно.
У нас тоже кое-какие данные поступают снаружи, от других систем; поэтому и понадобилось делать контроль на уровне triple store, а не в пользовательском интерфейсе редактора данных. Каждая внешняя система имеет свой пользовательский аккаунт, который разрешает ей вносить изменения только в определенную часть данных — так страхуемся от чужих багов, или злоумышленников с доступом к сторонней системе. Тут все внутри компании, и весьма строго по политике безопасности.

SDShare, насколько я помню, реплицирует данные между несколькими хранилищами в виде, по сути, файлов RDF. У нас не совсем такая ситуация, поскольку данные в семантической форме присутствуют пока только в одной точке — в самом MDM. Для остальных систем MDM выглядит как сервис, т.е. все данные он никогда никому не отдает — только по частям, и чаще всего — в ответ на запрос (или, наоборот, в активном режиме — по подписке).

Кстати, с репликацией и де-факто кластеризацией Triple Store мы тоже наплясались, но это тема, которую я пока не готов раскрывать. Там у нас распределенная архитектура, т.е. сам Triple Store живет на нескольких серверах, хотя снаружи выглядит как одна целостная система.

Проект, где идет в чистом виде сбор информации со сторонних источников, у нас тоже был: http://energopravda.ru
Там, конечно, все проще. Роботы разбирают разные источники, и льют контент в общую базу.

Про уч записи из многих систем: Да, мы тоже собираем такую информацию. Особенно полезно её использовать потом для single sign on (так как можно установить owl:sameAs между записями в разных системах) и для экспорта в поисковую машину.

Да, строго говоря, SDShare создан для синхронизации хранилищ троек, но в нашем случае мы пишем адаптеры от внешних систем в RDF, которые позволяют нам представить, например, Active Directory или БД как хранилище троек.

Я правильно понимаю, что Вы как правило используете TDB как хранилище троек, так как пользуетесь Fuseki? Я понимаю что всегда можно начать говорить с другим endpoint, но всегда есть нюансы. Любопытно потому, что мы обычно используем Virtuosо, но он нас не очень устраивает порой.
Да, всегда TDB как хранилище (Jena). Смотрели на Oracle еще. Пока остаемся в рамках Open Source решения, в связи с требованиями большинства проектов.
Забавно, но вот именно сейчас я пытаюсь понять подходит ли нам Exadata 12c в качестве хранилища.
Тут не знаком с предметом, к сожалению. 11g смотрел в качестве Triple store — работает, но нам не подошел, т.к. нужен Open Source.
Only those users with full accounts are able to leave comments. Log in, please.