|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Привет. По статусу. В современных технологиях БД семантические сети - из малоизвестных. Особенно в части литературы. Намного больше спецификаций чем каких-либо материалов о смыслах и мотивации. Поэтому я поднимаю тему как некий вопросник. 1. Каковы перспективы AWS:Neptune ? Пока цена его эксплуатации слишком дорога для кастомеров и они отказываются от него погоняв в тестовых enviromnents и поглазев на выписки из счета. Возможно причина в том что это In-Memory-Ddbms? Было-бы неплохо поискать бесплатную альтерноативу AWS:Neptune (пускай даже дисковую) и подняв в EC2 instance обеспечить тот-же Rest-овский интерфейс предложить более дешевое решение (на обсуждение) пускай даже более медленное по TPS. 2. GraphDb ? Что это за продукт? Его демонстрационная версия работает у меня локально как веб-приложение. Каковы цели его создания? Возможности? Как он конкурирует с AWS:Neptune? Какие есть у него ограничения? 3. Apache Jena . SDF. Я потратил несколько безсонных ночей анализируя возможность намапить семантическую БД на реляционную. В документах Jena это направление считается не-перспективным и его рекомендуют оставить в пользу более быстрых. Но для меня направление реляционок кажется пока привлекательным. Это некая большая гетерогенность в AWS где можно поднимать легко Maria/Postgres и относительно недорого (дешевле чем Neptune). Добавте пару слов кто вкурсе. Зачем в SDF три layouts: LayoutTripleNodesHash, LayoutSimple, LayoutTripleNodesIndex ? Под-направления TDB/TDB2. Планирую на днях их развернуть и разобраться. Если у кого есть инфа - делитесь. В данном дискурсе вопросы перформанса пока вообще не стоят. Заказчик ничего не озвучивает и не дает NFR. Предположительно нагрузки не будет. Нужны только принципиальные возможности. Предполагается хранить - репозитарий. Транзакции будут не поисковые а - точечные. 4. SparQL или Gremlin ? Поверхностно посмотрел уроки. SparQL на примере GraphDB. Мне как старому SQL-щику SParQL понравился. Он хотя-бы выделен в некий доменный язык. С другой стороны Gremlin похож на JavaScript но запросы на создание графов выглядят в нем ужасно. Не понимаю пока мотивации. Кто юзал оба - варианта - велкам. Кидайте 5 копеек. 5. Triple/Quad . Именованные графы. Зачем? Какова цель их создания? Какие RDF-форматы сериализации наиболее удобны? какие использовали вы? Мне эстетически понравился turtle, на нем в частности я откатывал учебные tutorials. 6. Прочие графовые Dbms и библиотеки (Guava .e.t.c) я в прошлом году имел наглость поднять где-то их сравнительный анализ но незакочил. Сейчас могу снова вернуться но уже в других смыслах а именно - семантический веб. Мне не нужен граф как таковой и алгоритмы потоков в сетях и разрезы. Мне нужна формальная близость к спекам RDF и модель хранения пригодная к запросам SparQL. Keywords: GraphT JUNG Guava Apache Commons Graph GRPH 7. EclipseRDF4j против Apache Jena. Это 2 API для работы с RDF однако Eclipse рекомендован Amazon в туториалах как основной API для Neptune. Jena с моей точки зрения более привлекательна как старт опен-сорц решений. Вобщем тоже поделитесь опытом их использования. 8. Визуализация RDF. P.S. Я прошу прощения за свое многословие. Возможно я форкну дочерние топики если какая-то тема найдет отклик. Но пока вот так. Сумбурно. P.P.S. Основной поинт - отказ от системы AWS:Neptune в пользу Open-SOurce решений но цена развертывания такого решения в облаке AWS не должна быть дороже Нептуна. Линки по теме Jena https://jena.apache.org AWS https://aws.amazon.com/ GraphDb http://graphdb.ontotext.com/ Rdfj4 http://rdf4j.org/ SparQL https://www.w3.org/TR/sparql11-overview/ RDF concepts https://www.w3.org/TR/rdf11-concepts/ Литература по теме: 1. Learning SPARQL: Querying and Updating with SPARQL 1.1 2. Practical RDF (если вы знаете больше и полезных - докидывайте) Вышеуказанные книги я не читал пока но заказал в бумажном варианте. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2018, 22:16 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonНамного больше спецификаций чем каких-либо материалов о смыслах и мотивации. Здесь как и во всех оторвавшихся от вас науках - напридумали массу всего, а вы не знакомы с промежуточными результатами. Без промежуточной базы нет возможности понять смысл того, что сидит сверху. Поэтому займитесь чем-нибудь простым, то есть сваяйте свою сеть, поймите, зачем она вам на самом деле нужна, а для этого именно по тем проблемам, которые для вас актуальны, ищите поясняющий материал. А если пойдёте "сверху", то есть от готовых продуктов, то будете изучать то, что нужно им , а не вам. А им нужны просто ваши деньги. Поэтому они предлагают вам купить производительный сервис исполнения некоторых алгоритмов на очень больших графах. Но конкретно вам производительность и большие графы просто не нужны , но вы уже пошли по их пути и готовы им платить. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2018, 14:27 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Извините, что вклинился. За ссылки мерси в баку. "бе зс онных ночей" -- пара слов по этому поводу, возможно лишних. Сеть, граф с циклами нужно отображать на модель сети, реализованную средствами РБД (если уж РБД). Надеюсь речь идёт не о том, чтобы непосредственно "распланарить" данные графа в таблицу - это сумасшедший дом, там 100500 дублирований для боле-мене густой сети. Одна только поддержка обновлений достанет. Нечто аналогичное в простейшем виде (отображение на модель сети с дальнейшими попытками визуализации) я пробовал лет 15-18 лет назад собственными силами. Что одному было неподъёмно, так это именно варианты визуализации хотелок. С отображением же - достаточно ОК. Как пример "поделочности" - аннотировать бессловарным способом замапленный (автоматически) текст, и варьируя степень краткости. Впрочем как поисковая работа, оказалось не хуже аннотации в ворде тех лет. У меня связка таблиц была 2-х уровневой. Поэтому моё мнение, что для нормальной работы с семантикой адекватно железо с ассоциативным доступом к памяти, т.е. доступ по значению. Всё же желаю успехов с заказчиком! интересно будет увидеть некоторые результаты ... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2018, 14:31 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
alex55555, мы не знаем, чем мотивировался мэйтон, зато ваш комментарий можно адресовать любому юзеру заимствованных технологий. В частности, зачем программистам изучать фреймворки, стандарты Си Явы ... зачем изучать API виндовса ?.. это всё быдлокодерство, этим что ль исчерпываются интересы прогеров? Извините за оффтоп. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2018, 14:38 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Похоже, что тема затронула только меня, а конкретики от меня никакой)) По-прежнему не читал, только пробежался по нек. ссылкам. SparQL по общей схеме запроса понравился тем, что, если не вдаваться в подробности, то секции выглядят логичными, а схема - обёрткой вокруг SQL-SELECT. Мои полкопейки к слоям в RDF, может прольёт капельку на возможные смыслы и источники мотивации. Я провожу параллели со своими наработками. Предыстория, краткая: В 90-х начинался Косультант+. Наряду с юр.базой предлагался некий продукт "технология работы с инвертированными БД". Это название (наряду с ценами/зарплатами тех лет) позднее непосредственно сыграло роль в занятии, о к-ром я выше написал. Я не знал, что тогда рожают RDF, поэтому моя архитектура была 2-х слойной, и конечно инет-распределённость я не рассматривал. Тем не менее "семантик вэб" уже обсуждался и в рунете. Потом уже я связывался с Консу-том,где мне рассказали, что уже не продают, а сама технология непосредственно используется в их СУБД для быстрого поиска и связанных зак/актов. Т.е. у них был не семантический поиск, а типа "гипертекст наизнанку". Ну,для строгих связей оно наверное и правильно. По сути БД представляла собой индексированный текст, т.е. индексный файл ссылок на файл, содержащий ключевые сочетания буковк (возможно, организованные иерархически). Это моя вольная интерпретация их технологии, отдалённо к-рую воплощал я. Но здесь 2 слоя, Мэйтон спрашивавет о 3-х. На основе изложенного я фантазирую в нулевом приближении, что якобы - слойХЭш - ИД триплетов, - слойИндекс - иерархи-ски организованный слой ссылкок на триплеты, - слойСимпл - не уверен, возможно это аналог обычной "псевдотекстовой" таблицы. В зачатках моей технологии в такой таблице я хранил "тексты", состоявшие из ссылок верхнего уровня, к-рые интерпретировались на основе индексных таблиц. В инд-х таблицах использовалась единственная, но боле-мене общая модель сети. В RDF, судя по ссылкам ниже, слойХэш включает отношения, а отношения как и сами сущности могут интерпретироваться с предметной т.зр. В моей версии отношения сидели в индексноых таблицах, интерпретация же непосредственно выполнялась мною самим в "ad hoc"-запросах и прогах. Ну и мне было не до спецязыка - обычный SQL, я практиволся под конкретный круг задач. эквивалент в СвистиПедии: RDF "субъект - предикат - объект" называется триплетом визуализация хотелок / интерпретация под хотелки = "Для выражения семантики требуются словари (англ. vocabularies), таксономии (англ. taxonomies) и онтологии (англ. ontologies) и наличие в рассматриваемом графе связей с ними." вдруг подскажет: jena.apache.org/documentation/sdb/database_layouts.html На русском: Графовая база данных Толкование dic.academic.ru/dic.nsf/ruwiki/1738292 SPARQL Толкование dic.academic.ru/dic.nsf/ruwiki/102698 dic.academic.ru: Общая схема SPARQL-запроса выглядит так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2018, 17:51 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
exp98ваш комментарий можно адресовать любому юзеру заимствованных технологий. Если юзер сразу бросается писать enterprise-решение на Java предварительно не познакомившись как следует с plain Java, то да, ему можно адресовать мои слова. Но если бы была хорошая подготовка по основам, тогда использование библиотек enterprise-решений не составило бы труда. Хотя время на изучение решений пришлось бы тратить в любом случае, но во втором изучение было бы эффективным, а в первом - случайным с огромными перепадами эффективности при столкновении с незнакомой концепцией.. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2018, 17:55 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
alex55555, я снова оффтоп( Это возможно было в тепличных условиях СССР, а если сейчас, то в студенчестве. А не когда уже завтра дедлайн для принятия решения. И не в условиях звериного лица нашего олигархата, когда работник д.б. и швец, и жнец, и на дуде игрец. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2018, 18:07 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
exp98Всё же желаю успехов с заказчиком! интересно будет увидеть некоторые результаты ... Я вряд-ли смогу вам что-то конкретное рассказать. Мой контракт не подразумевает рассказов. Но по технологиям которые доступны в книгах и ссылках мы можем спокойно общаться. Последние пару книг которые я привел в 1-м посту я заказал. Я к сожалению болею букинизмом и не могу воспринимать электронную литературу. Такой-вот косяк. Тоесть я конечно ее читаю. Забит весь телефон с Гугл-Драйвом. Но уровень восприятия какой-то другой. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 01:35 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
exp98На основе изложенного я фантазирую в нулевом приближении, что якобы - слойХЭш - ИД триплетов, - слойИндекс - иерархи-ски организованный слой ссылкок на триплеты, - слойСимпл - не уверен, возможно это аналог обычной "псевдотекстовой" таблицы. В зачатках моей технологии в такой таблице я хранил "тексты", состоявшие из ссылок верхнего уровня, к-рые интерпретировались на основе индексных таблиц. В инд-х таблицах использовалась единственная, но боле-мене общая модель сети. В RDF, судя по ссылкам ниже, слойХэш включает отношения, а отношения как и сами сущности могут интерпретироваться с предметной т.зр. В моей версии отношения сидели в индексноых таблицах, интерпретация же непосредственно выполнялась мною самим в "ad hoc"-запросах и прогах. Ну и мне было не до спецязыка - обычный SQL, я практиволся под конкретный круг задач. Я пока разбирался с SDB/Jena - дебажил некоторые вызовы в БД в части DDL. И заметил что создается такая схема. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 01:55 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Simple насколько я понимаю просто отображает список namespaces на одну табличку а триплеты - на другую. Прочие модели отказываются от триплетов и нормализуют их (вместо varchar вводят integer). Схема к сожалению не создавала констрейнтов связности и поэтому приходится догадываться. Квадры тоже нормализуются. И вводится табличка Nodes. В двух варимантах с ключом ID+Hash и с ключом Hash. Hash в данном случае - тоже PK. Как это использовать - непонятно но возможно смысл - в большей консолидации данных вокруг "вершины графа" или subject. Или в более удобном полнотекстовом поиске. Я в ближайшее время попробую прогрузить мою учебную RDF-схему во все 3 варианта Layouts и посмотреть средствами простого SQL как легли данные внутри. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 02:04 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
exp98эквивалент в СвистиПедии: RDF "субъект - предикат - объект" называется триплетом визуализация хотелок / интерпретация под хотелки = "Для выражения семантики требуются словари (англ. vocabularies), таксономии (англ. taxonomies) и онтологии (англ. ontologies) и наличие в рассматриваемом графе связей с ними." Вот таксономия и онтология совершенно меня ошеломляет своим неуместным (более гуманитарно-философским) смыслом в данном техническом топике. Я здесь скопи-пащу с вики определения для удобства. Таксоно́мия (от др.-греч. τάξις — строй, порядок и νόμος — закон) — учение о принципах и практике классификации и систематизации[1] сложноорганизованных иерархически соотносящихся сущностей[2]. Принципы таксономии применяются во многих научных областях знаний, для упорядочивания объектов географии, геологии, языкознания, этнографии и всего многообразия органического мира[2]. Онтоло́гия (новолат. ontologia от др.-греч. ὄν, род. п. ὄντος — сущее, то, что существует + λόγος — учение, наука) — учение о сущем[1]; учение о бытии как таковом; раздел философии, изучающий фундаментальные принципы бытия, его наиболее общие сущности и категории[2], структуру и закономерности[3]. Философское учение об общих категориях и закономерностях бытия, существующее в единстве с теорией познания и логикой[4]. Для полного комплекта здесь не хватает черной магии. И что скажите без таких определений нельзя было обойтись? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 02:16 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
exp98Общая схема SPARQL-запроса выглядит так: ............ Я успел уже какое-то время поиграться с GraphDb и запросами и получить некое поверхностное суждение об этом языке. И меня далее как старого базейщика конечно-же заинтересовала тема оптимизации перформанса. Возможно такие сверх умные системы не ставят своей задачей микросекундный отклик и даже более того - не ставят секундный... но заведомо упеждая свои собственные будущие вопросы в разработке AWS:Neptune спешу спросить. Какие методы оптимизации возможны в графо-ориентированных DBMS ? Даст бох мне это не пригодится но если кастомер захоче что-то эдакое вроде отчота из терабайтной БД то хотелось-бы знать и понимать принципы и направления в которых двигаться. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 02:21 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonДля полного комплекта здесь не хватает черной магии. И что скажите без таких определений нельзя было обойтись? Ха-ха, а помнится я критиковал наукообразность в программизме, не в теоретическом, правда. Из поверхностной пробежки лично я считаю их уместными. Япользуюсь такой интерпретацией: Таксономия - написано же, иерархия, метрики и т.п. - всё, связанное с измерениями. Онтология - в даном контексте по сути - зависимость от времени, временнЫе ряды, т.е. сведения, меняющиеся в динамике, как синоним - происхождение, эволюция. Вэб-страницы ведь могут же меняться, переноситься, исчезать ... Их оба постоянно использовали в контексте семантик вэб. В том же контексте ещё можно было услышать "пересматриваемая логика". Частично она по факту учитывается всеми в системах, использующих СУБД или хранилища - данныемогут меняться, исчезать, меняться их качественная оценка, как следствие - принятие рашений и т.п. Насчёт созданных схем, конкретно кажется, что hash BIGINT есть FK на hash BIGINT PRIMARY KEY А вот что такое кводы, я не знаю, м.б. действительно некие кластеры/группы триплетов. И наверное надо понять, как здесь время учитывается и в какое послед-сти. М.б. оно в Id SERIAL PRIMARY KEY ? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 13:21 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonДля полного комплекта здесь не хватает черной магии. И что скажите без таких определений нельзя было обойтись? Они старались в общем виде дать, применимое ко всему и сразу, поэтому получилось ни о чём. Для софта обычно онтология есть граф с ограничениями, а таксономия есть дерево, показывающее некие смысловые глубины предметной области за счет наследования. То есть понятия в применении к конкретной области сильно видоизменяются. Хотя увидеть похожесть с общим определением, наверное, возможно. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 15:26 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Apache Jena включает в себя список неких предопределённых namespaces которые по всей видимости описывают т.н. таксономию в некоторой предметной области. Пример. Код: sql 1. 2. 3. 4. 5. 6. 7.
Насколько я разобрался foaf (friend-of-a-friend) определяет связи в социуме. Кто какие таксономии юзал и в каких задачах. Кто создавал свои. Какие были интересные решения. Best practices. Особо меня интересует все что выложено в open-source и доступно к повторному использованию в проектах. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2018, 01:17 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonApache Jena включает в себя... Это просто список стандартов, в соответствии с которыми йена манипулирует своими данными. То есть может читать owl, может rdf, может туда экспортировать, конвертировать между ними и т.д. Это не таксономия и не онтология. Смысл всем этим манипуляциям придаёт разработчик, а укладывает он свой смысл в некое описание, которое может быть и owl и rdf и xsd и ... То есть это всё просто форматы данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2018, 14:48 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
alex55555maytonApache Jena включает в себя... Это просто список стандартов, в соответствии с которыми йена манипулирует своими данными. То есть может читать owl, может rdf, может туда экспортировать, конвертировать между ними и т.д. Это не таксономия и не онтология. Смысл всем этим манипуляциям придаёт разработчик, а укладывает он свой смысл в некое описание, которое может быть и owl и rdf и xsd и ... То есть это всё просто форматы данных. Вы немножко не в теме. "форматы данных" - это неудачное слово. Форматы - это Turtle/JSON-LD/RDF-XML. Способ сериализации RDF. А то что я перечислил выше это prefixes/namespaces и их назначение не синтаксическое а структурное. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2018, 01:12 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonДля полного комплекта здесь не хватает черной магии. И что скажите без таких определений нельзя было обойтись? Еще добавлю. Более удачное определение онтологии. Взято из видеолекции о семантическом вебе. Онтологии - это специальные хранилища знаний которые могут читаться или пониматься людьми и компьютерами, отчуждаться от разработчика и посторно использоваться. Онтология и инфо-технологиях - обычно иерархическая система понятий и терминов (структура, модель) некоторой предметной области. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2018, 01:48 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
mayton"форматы данных" - это неудачное слово. Форматы - это Turtle/JSON-LD/RDF-XML. Способ сериализации RDF. Вот что пишут в этой Йене: авторJena aims to provide a consistent programming interface for ontology application development, independent of which ontology language you are using in your programs Здесь consistent programming interface - это Йена. А independent of which ontology language you are using - это формат, в котором онтология хранится, от RDFS (weakest) до OWL (strongest). Слабо-сильные здесь в смысле больше/меньше фич поддерживается. А то, что началась эта Йена с поддержки только RDF не говорит ни о чём. Просто далее расширили и углУбили. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2018, 14:42 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Хм. Забавно. Английски артикль "a" имеет семантику rdf:type. Тоесть если к примеру есть утверждение что Код: sql 1. 2. 3. 4.
То это равносильно. По крайней мере для парсеров turtle из Apache Jena. Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2018, 01:22 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonХм. Забавно. Английски артикль "a" имеет семантику rdf:type. Происхождение артикля - от one ХХХ , то есть некий представитель абстрактного типа ХХХ. Бэтман является экземпляром некоего абстрактного супергероя - Batman is a superhero. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2018, 14:30 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonБолее удачное определение онтологии Онтологии - это специальные хранилища знаний ... Онтология в инфо-технологиях - (структура, модель) некоторой предметной области. Принимаю, не успел выразить мысль про "картину мира". Меняющуюся во времени - важная добавка имхо. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2018, 20:58 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Интересно. Существует ли формула перехода от Семантической Сети к EAV ? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2018, 00:08 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
EAV значение- атрибут- объект ? С трудом представляю. СС, имхо, должнс подразумевать отношения между сучностями. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2018, 15:02 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonИнтересно. Существует ли формула перехода от Семантической Сети к EAV ? Это примерно как задать вопрос, а существует ли формула для перехода от функции к её интегралу? Да, существует, но для всех функций разная. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2018, 20:14 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
exp98EAV значение- атрибут- объект ? С трудом представляю. СС, имхо, должнс подразумевать отношения между сучностями. EAV: EntityAttributeValue RDF: SubjectPredicateObject ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2018, 21:30 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Я предполагал это возражение. Если в ЕАВе есть достаточные инструменты семантической обработки атрибутов, тогда что нового предложил апач? Если и там и там всё самому писать, то какая вообще разница где? Но я уверен, что ЕАВ - имеет сугубо фрмальное сходство,и вообще он даже не каккой-то конкретный формат, а всего лищь концепция, и уж в этой парадигме уж точно всё самому писать. Так, блин, что мешает тогда в оракле строить таблицы с ссылками на себя же, а потом из них "селект - коннект бай левел". Так что с НГ! ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2018, 17:51 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
В RDF-модели Object может указывать (URI) на Subject (вплоть до кольцевых связей). Вспоминаем циклы в графах. Вобщем для семантического веба это нормально. Object может быть и посто литералом например "String", 5$, 1.2кг, 'e' (символ е). Все элементы триплета в RDF могут иметь вариативный тип. Грубо говоря вам недостаточно просто считать строковое значение с Object. Вы должны детектировать тип. URI или литерал. Тоесть семантика RDF скорее всего более широкая. Кроме того namespaces... мать их так. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2018, 00:16 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Существует еще один вариант RDF с четырьмя элементами. Это т.н именованный граф. GraphSubjectPredicateObject Смысл - тот-же но тройки фактов теперь имеют принадлежность к графу (или подграфу). Это удобно использовать для нарезки данных еще на некоторые слои. Кроме того литерал может иметь локализацию указанную явно. Или несколько литералов. Например "New-York"@en "Нью-Йорк"@ru ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2018, 01:43 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2018, 03:23 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
mayton, что там, что тут - триплеты, как ты их трактуешь - твое дело ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2018, 11:19 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
ViPRos, ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2018, 11:23 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Круть. Но это приложение. А можно взглянуть на его онтологическое описание? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2018, 13:58 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Я помню эту круть, и даже видел декларативное описание, тогда мне понравилось. Только к ней нужен дотнет. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2018, 14:34 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
кстати здесь было sql.ru/forum/1211980-1/kakim-fw-vy-sozdayote-gui-v-brauzerah-dlya-desktopov?hl= sql.ru/forum/1211980-4/kakim-fw-vy-sozdayote-gui-v-brauzerah-dlya-desktopov ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2018, 15:05 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonЕще ссылка по теме. Редактор онтологий. Еще не разбирался. https://protege.stanford.edu/ Подобных редакторов много, но все с особенностями. Можно привыкнуть, но при большом объёме работ это очень замедляет процесс. Можно выбрать другой редактор, но они весьма и весьма похожи, поэтому чуть что не так как хочется - нигде нету. По сути для масштабной разработки выход один - писать самим. Вот VIPRos как раз сам написал и редактор онтологии и к нему генератор гуя и операций с БД, что в сумме дало мини-ERP, которую он внедрил в своей конторе. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2018, 20:13 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Жаль что он самозобанился. На выходных планирую взять крупную RDF-базу по предприятиям (в архиве gz порядка 300Мб и в открытом виде в TTL порядка 3.3Гб). Взять apache-jena. И прогрузить ее в SDB(PostgreSQL), TDB2(файловое хранилище) и побенчмаркать время и расходы. Предыдущий "наивный" запуск загрузки этой базы в Model/GraphMem у меня вызвал OutOfMemoryError при Xmx=1G на 1% данных. И интересно поразбираться на что так сильно уходит память и посмотреть дамп. Почему мне важно небольшое количество Xmx? Ну потому-что AWS-lamdba... Чуть позже мне понадобиться SparkQL. Но это скорее всего отдельным топиком. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2018, 10:51 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonИ интересно поразбираться на что так сильно уходит память Куда объектов. Всегда так. Для XML это стандартная проблема - рост в 10-100 раз при загрузке в память. В памяти ведь не строки, а куча ссылок и служебной инфы про объекты. Плюс, конечно же, и строки тоже, но и они с дополнениями. Эффективный по памяти формат крайне неудобен в работе. Это как всё хранить в одном массиве - в принципе можно, но никто так никогда делать не будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2018, 15:08 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
alex55555maytonИ интересно поразбираться на что так сильно уходит память Куда объектов. Всегда так. Для XML это стандартная проблема - рост в 10-100 раз при загрузке в память. В памяти ведь не строки, а куча ссылок и служебной инфы про объекты. Плюс, конечно же, и строки тоже, но и они с дополнениями. Эффективный по памяти формат крайне неудобен в работе. Это как всё хранить в одном массиве - в принципе можно, но никто так никогда делать не будет. Хочу подчеркнуть что никакого XML на входе не было. Там был TTL. Но не суть. Все равно в памяти графовая модель. Вот фрагмен 1-й записи из справочника валют. Он внешне очень похож на базу знаний по организациям. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Обратите внимание что Македонский динар помимо атрибутов имеет еще и связи с sws.geonames.org а это главное отличие от EAV. В атрибут-значение вы складываете только литералы а в RDF - связи на другие узлы знаний. И связи различаются на уровне описания. Тоесть EAV описывает товар (Телевизор) в магазине техники но он обычно не в состоянии описать то что в состав телевизора входит ... другой телевизор. Это как-бы вне постановки EAV. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2018, 22:23 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Вот и я о том же - описание сношений. Только этого мало. Мне досталися на сопровождение фреймворкные взаимосвязанные проекты, в к-рых в частности на каждый бизнес-объект можно создавать типа (обж -- массив_сс_вверх -- массив_сс_вниз -- свойства), с автоматическим обновлением связей на выбор. Надо ли говорить, что уже 3-х уровневая схема даёт тормоза. Хотя описать можно всё, что угодно, почти. Но скорость как бы пустяки. По мне так важнее обработка семантики связей. И это самая трудозатратная часть. Предполагаю, что и "жена апача" предлагает всю смысловую реализацию делать с нуля и не предлагает ощутимых полезных инструментиков, хотябына некоторые предметные области. Готовых спецструктур, спецметодов и т.п. Ну то есть пока складывается мнение,что это наворченный парсер распределённой инфы. Но семантический поиск не сводится к уровню парсера. Поисковики используют имитаторы семантики в форме, например LSA и т.п. Был бы рад ошибиться. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2018, 11:40 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Жена Апача сдохла. Подавилась суффиксом "^^XSD:". Как пофиксить пока не знаю. Но Eclipse RDF4j хавает нормально. По крайней мере парсер пробегает по всему документу. Но я пока не нашел поддержки file-storage для графа. А это важно. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2018, 13:37 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Интересно. Если почитать доки по Кроносу http://www.cronos.ru/cronospro.html то складывается впечатление что тот решает вопросы хранения графовых данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2019, 22:14 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonИнтересно. Если почитать доки по Кроносу http://www.cronos.ru/cronospro.html то складывается впечатление что тот решает вопросы хранения графовых данных. SQL Server решает, PostgreSQL тоже ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2019, 15:25 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Ролг ХупинmaytonИнтересно. Если почитать доки по Кроносу http://www.cronos.ru/cronospro.html то складывается впечатление что тот решает вопросы хранения графовых данных. SQL Server решает, PostgreSQL тоже А можете привести линк где есть анонс или описание этой фичи для MS и PG ? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2019, 15:27 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonРолг Хупинпропущено... SQL Server решает, PostgreSQL тоже А можете привести линк где есть анонс или описание этой фичи для MS и PG ? Например, SQL Server 2017 https://www.red-gate.com/simple-talk/sql/sql-development/sql-server-graph-databases-part-1-introduction/ ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2019, 12:50 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Ролг Хупинmaytonпропущено... А можете привести линк где есть анонс или описание этой фичи для MS и PG ? Например, SQL Server 2017 https://www.red-gate.com/simple-talk/sql/sql-development/sql-server-graph-databases-part-1-introduction/ Спасибо. Почитаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2019, 12:56 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonРолг Хупинпропущено... Например, SQL Server 2017 https://www.red-gate.com/simple-talk/sql/sql-development/sql-server-graph-databases-part-1-introduction/ Спасибо. Почитаю. Я посмотрел. Я не нашел ничего интересного для работы с графами. Обычная реляционная модель. Обычный SQL. Это - тоже самое что и Apache Jena предлагает в качестве адаптера SDB для Oracle/Postfresql. Это я уже проходил. Работает медленно. Основной поинт графовых DBMS - это графовая структура данных внутри. Triples/Quads - это просто метафора. Структура данных должна хранить вершины и рёбра а не базироваться поверх реляционных сущностей. Рёбра исходящие из вершины как структура данных должны быть физически кластеризованы. Должны лежать рядом. Чтоб эффективно работать с графом - нужен граф. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2019, 11:12 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonmaytonпропущено... Спасибо. Почитаю. Я посмотрел. Я не нашел ничего интересного для работы с графами. Обычная реляционная модель. Обычный SQL. Это - тоже самое что и Apache Jena предлагает в качестве адаптера SDB для Oracle/Postfresql. Это я уже проходил. Работает медленно. Основной поинт графовых DBMS - это графовая структура данных внутри. Triples/Quads - это просто метафора. Структура данных должна хранить вершины и рёбра а не базироваться поверх реляционных сущностей. Рёбра исходящие из вершины как структура данных должны быть физически кластеризованы. Должны лежать рядом. Чтоб эффективно работать с графом - нужен граф. Ну-ну.... полёт необоснованной фантазии Графы в любом случае должны храниться в физическом файле. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2019, 12:10 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Ролг Хупинmaytonпропущено... Я посмотрел. Я не нашел ничего интересного для работы с графами. Обычная реляционная модель. Обычный SQL. Это - тоже самое что и Apache Jena предлагает в качестве адаптера SDB для Oracle/Postfresql. Это я уже проходил. Работает медленно. Основной поинт графовых DBMS - это графовая структура данных внутри. Triples/Quads - это просто метафора. Структура данных должна хранить вершины и рёбра а не базироваться поверх реляционных сущностей. Рёбра исходящие из вершины как структура данных должны быть физически кластеризованы. Должны лежать рядом. Чтоб эффективно работать с графом - нужен граф. Ну-ну.... полёт необоснованной фантазии Графы в любом случае должны храниться в физическом файле. Возможно ты не понимаешь как работает поиск в графах. Для того чтобы он работал быстро. Вершина должна содержать в себе список инцедентрых ребер. Если ребра "физически" хранятся в разных местах таблицы в БД. То на сборку путей будет потрачено большое число IOPS. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2019, 12:33 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonРолг Хупинпропущено... Ну-ну.... полёт необоснованной фантазии Графы в любом случае должны храниться в физическом файле. Возможно ты не понимаешь как работает поиск в графах. Для того чтобы он работал быстро. Вершина должна содержать в себе список инцедентрых ребер. Если ребра "физически" хранятся в разных местах таблицы в БД. То на сборку путей будет потрачено большое число IOPS. Возможно ты и понимаешь, я не в курсе, допустим. "Вершина должна содержать в себе список инцедентрых ребер." Нет, это не обязательно, в базах есть еще и индексы. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2019, 13:51 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
Ролг Хупинmaytonпропущено... Возможно ты не понимаешь как работает поиск в графах. Для того чтобы он работал быстро. Вершина должна содержать в себе список инцедентрых ребер. Если ребра "физически" хранятся в разных местах таблицы в БД. То на сборку путей будет потрачено большое число IOPS. Возможно ты и понимаешь, я не в курсе, допустим. "Вершина должна содержать в себе список инцедентрых ребер." Нет, это не обязательно, в базах есть еще и индексы. Индексы не решают всех проблем. К примеру кластеризация данных вокруг поисковых ключей. Это немаловажно когда у тебя таблица перевалила за 10-100 Гб. Как работает Нептун с большим объемом - пока я не знаю. Судя по конфигурации он - In-Memory но это коробочное решение для поиска в графах. А если есть заказ на такие решения то очевидно что преимущества Нептуна должны быть. По поводу хранения графовых данных в реляционках. Apache Jena содержит в себе адаптеры для этого (SDB). И я их собираюсь подвергнуть бенчарку. Технически - я знаю как. Единсвенное что я пока не определеилися это какую взять базу знаний. И какие к ней писать запросы. Типичный запрос к такой базе может выглядеть как - найти всех людей (Persons) которые связывают тебя с Королевой Англии. (К примеру). ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2019, 14:04 |
|
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
|
|||
---|---|---|---|
#18+
maytonРолг Хупинпропущено... Возможно ты и понимаешь, я не в курсе, допустим. "Вершина должна содержать в себе список инцедентрых ребер." Нет, это не обязательно, в базах есть еще и индексы. Индексы не решают всех проблем. К примеру кластеризация данных вокруг поисковых ключей. Это немаловажно когда у тебя таблица перевалила за 10-100 Гб. Как работает Нептун с большим объемом - пока я не знаю. Судя по конфигурации он - In-Memory но это коробочное решение для поиска в графах. А если есть заказ на такие решения то очевидно что преимущества Нептуна должны быть. По поводу хранения графовых данных в реляционках. Apache Jena содержит в себе адаптеры для этого (SDB). И я их собираюсь подвергнуть бенчарку. Технически - я знаю как. Единсвенное что я пока не определеилися это какую взять базу знаний. И какие к ней писать запросы. Типичный запрос к такой базе может выглядеть как - найти всех людей (Persons) которые связывают тебя с Королевой Англии. (К примеру). Да, задача интересная сама по себе, отпишись потом, если будет возможность. Я имел в виду, что индексы могут быть сложной структуры, как например, для хранения дуг к вершине. Я не в курсе как устроено все внутри OrientDB, но там утверждается, что база и реляционная, и графовая ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2019, 18:26 |
|
|
start [/forum/topic.php?all=1&fid=16&tid=1339993]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
130ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
79ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 271ms |
0 / 0 |