Комментарии 7
Интересно. У нас была такая же проблема, но мы не решаем вопрос добавления авторицации к запросам на обновление и удаление, так как наша система используется не как первичный каталог данных, а как точка сбора информации из многих внутренних систем. Аутентификация и процессы работы с данными происходят не у нас.
Таким образом мы только забираем данные из подключённых систем (с помощью SDShare: sdshare.org/ ) и доверяем запросам на обновление и удаление от клиентов.
Таким образом мы только забираем данные из подключённых систем (с помощью SDShare: sdshare.org/ ) и доверяем запросам на обновление и удаление от клиентов.
+1
А так как напрямую никто с нашим endpoint тоже не говорит (наружу мы показываем данные только как SDShare потоки, очень похожие на Atom feed c RDF/XML или n3 в теле поста), то прокси нам был не нужен, мы зашиваем наши проверки авторизации в SPARQL, который генерирует списки документов и содержание документов.
0
Ясно, интересно.
У нас тоже кое-какие данные поступают снаружи, от других систем; поэтому и понадобилось делать контроль на уровне triple store, а не в пользовательском интерфейсе редактора данных. Каждая внешняя система имеет свой пользовательский аккаунт, который разрешает ей вносить изменения только в определенную часть данных — так страхуемся от чужих багов, или злоумышленников с доступом к сторонней системе. Тут все внутри компании, и весьма строго по политике безопасности.
SDShare, насколько я помню, реплицирует данные между несколькими хранилищами в виде, по сути, файлов RDF. У нас не совсем такая ситуация, поскольку данные в семантической форме присутствуют пока только в одной точке — в самом MDM. Для остальных систем MDM выглядит как сервис, т.е. все данные он никогда никому не отдает — только по частям, и чаще всего — в ответ на запрос (или, наоборот, в активном режиме — по подписке).
Кстати, с репликацией и де-факто кластеризацией Triple Store мы тоже наплясались, но это тема, которую я пока не готов раскрывать. Там у нас распределенная архитектура, т.е. сам Triple Store живет на нескольких серверах, хотя снаружи выглядит как одна целостная система.
Проект, где идет в чистом виде сбор информации со сторонних источников, у нас тоже был: http://energopravda.ru
Там, конечно, все проще. Роботы разбирают разные источники, и льют контент в общую базу.
У нас тоже кое-какие данные поступают снаружи, от других систем; поэтому и понадобилось делать контроль на уровне triple store, а не в пользовательском интерфейсе редактора данных. Каждая внешняя система имеет свой пользовательский аккаунт, который разрешает ей вносить изменения только в определенную часть данных — так страхуемся от чужих багов, или злоумышленников с доступом к сторонней системе. Тут все внутри компании, и весьма строго по политике безопасности.
SDShare, насколько я помню, реплицирует данные между несколькими хранилищами в виде, по сути, файлов RDF. У нас не совсем такая ситуация, поскольку данные в семантической форме присутствуют пока только в одной точке — в самом MDM. Для остальных систем MDM выглядит как сервис, т.е. все данные он никогда никому не отдает — только по частям, и чаще всего — в ответ на запрос (или, наоборот, в активном режиме — по подписке).
Кстати, с репликацией и де-факто кластеризацией Triple Store мы тоже наплясались, но это тема, которую я пока не готов раскрывать. Там у нас распределенная архитектура, т.е. сам Triple Store живет на нескольких серверах, хотя снаружи выглядит как одна целостная система.
Проект, где идет в чистом виде сбор информации со сторонних источников, у нас тоже был: http://energopravda.ru
Там, конечно, все проще. Роботы разбирают разные источники, и льют контент в общую базу.
+1
Про уч записи из многих систем: Да, мы тоже собираем такую информацию. Особенно полезно её использовать потом для single sign on (так как можно установить owl:sameAs между записями в разных системах) и для экспорта в поисковую машину.
Да, строго говоря, SDShare создан для синхронизации хранилищ троек, но в нашем случае мы пишем адаптеры от внешних систем в RDF, которые позволяют нам представить, например, Active Directory или БД как хранилище троек.
Я правильно понимаю, что Вы как правило используете TDB как хранилище троек, так как пользуетесь Fuseki? Я понимаю что всегда можно начать говорить с другим endpoint, но всегда есть нюансы. Любопытно потому, что мы обычно используем Virtuosо, но он нас не очень устраивает порой.
Да, строго говоря, SDShare создан для синхронизации хранилищ троек, но в нашем случае мы пишем адаптеры от внешних систем в RDF, которые позволяют нам представить, например, Active Directory или БД как хранилище троек.
Я правильно понимаю, что Вы как правило используете TDB как хранилище троек, так как пользуетесь Fuseki? Я понимаю что всегда можно начать говорить с другим endpoint, но всегда есть нюансы. Любопытно потому, что мы обычно используем Virtuosо, но он нас не очень устраивает порой.
0
Да, всегда TDB как хранилище (Jena). Смотрели на Oracle еще. Пока остаемся в рамках Open Source решения, в связи с требованиями большинства проектов.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Триггеры, права доступа и версионность в точке доступа SPARQL