Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
exp98
EAV значение- атрибут- объект ?
С трудом представляю. СС, имхо, должнс подразумевать отношения между сучностями.

EAV:
EntityAttributeValue


RDF:
SubjectPredicateObject
25 дек 18, 21:30    [21773374]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
exp98
Member

Откуда:
Сообщений: 1624
Я предполагал это возражение. Если в ЕАВе есть достаточные инструменты семантической обработки атрибутов, тогда что нового предложил апач?
Если и там и там всё самому писать, то какая вообще разница где? Но я уверен, что ЕАВ - имеет сугубо фрмальное сходство,и вообще он даже не каккой-то конкретный формат, а всего лищь концепция, и уж в этой парадигме уж точно всё самому писать. Так, блин, что мешает тогда в оракле строить таблицы с ссылками на себя же, а потом из них "селект - коннект бай левел".
Так что с НГ!
26 дек 18, 17:51    [21774089]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
В RDF-модели Object может указывать (URI) на Subject (вплоть до кольцевых связей). Вспоминаем циклы в графах.
Вобщем для семантического веба это нормально. Object может быть и посто литералом например "String", 5$,
1.2кг, 'e' (символ е).

Все элементы триплета в RDF могут иметь вариативный тип. Грубо говоря вам недостаточно просто считать
строковое значение с Object. Вы должны детектировать тип. URI или литерал.

Тоесть семантика RDF скорее всего более широкая. Кроме того namespaces... мать их так.
27 дек 18, 00:16    [21774407]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Существует еще один вариант RDF с четырьмя элементами.
Это т.н именованный граф.

GraphSubjectPredicateObject


Смысл - тот-же но тройки фактов теперь имеют принадлежность к графу (или подграфу).
Это удобно использовать для нарезки данных еще на некоторые слои.

Кроме того литерал может иметь локализацию указанную явно.
Или несколько литералов. Например

"New-York"@en
"Нью-Йорк"@ru
27 дек 18, 01:43    [21774432]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Еще ссылка по теме. Редактор онтологий. Еще не разбирался.

https://protege.stanford.edu/
27 дек 18, 03:23    [21774441]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
ViPRos
Member

Откуда:
Сообщений: 9516
mayton,

что там, что тут - триплеты, как ты их трактуешь - твое дело
27 дек 18, 11:19    [21774598]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
ViPRos
Member

Откуда:
Сообщений: 9516
ViPRos,

К сообщению приложен файл. Размер - 41Kb
27 дек 18, 11:23    [21774601]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Круть. Но это приложение. А можно взглянуть на его онтологическое описание?
27 дек 18, 13:58    [21774744]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
exp98
Member

Откуда:
Сообщений: 1624
Я помню эту круть, и даже видел декларативное описание, тогда мне понравилось. Только к ней нужен дотнет.
27 дек 18, 14:34    [21774797]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
exp98
Member

Откуда:
Сообщений: 1624
кстати здесь было
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 дек 18, 15:05    [21774863]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
alex55555
Member

Откуда:
Сообщений: 2097
mayton
Еще ссылка по теме. Редактор онтологий. Еще не разбирался.

https://protege.stanford.edu/

Подобных редакторов много, но все с особенностями. Можно привыкнуть, но при большом объёме работ это очень замедляет процесс. Можно выбрать другой редактор, но они весьма и весьма похожи, поэтому чуть что не так как хочется - нигде нету. По сути для масштабной разработки выход один - писать самим. Вот VIPRos как раз сам написал и редактор онтологии и к нему генератор гуя и операций с БД, что в сумме дало мини-ERP, которую он внедрил в своей конторе.
27 дек 18, 20:13    [21775229]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Жаль что он самозобанился.

На выходных планирую взять крупную RDF-базу по предприятиям (в архиве gz порядка 300Мб и в открытом
виде в TTL порядка 3.3Гб).

Взять apache-jena. И прогрузить ее в SDB(PostgreSQL), TDB2(файловое хранилище)
и побенчмаркать время и расходы.

Предыдущий "наивный" запуск загрузки этой базы в Model/GraphMem у меня вызвал OutOfMemoryError при Xmx=1G
на 1% данных. И интересно поразбираться на что так сильно уходит память и посмотреть дамп.

Почему мне важно небольшое количество Xmx?
Ну потому-что AWS-lamdba...

Чуть позже мне понадобиться SparkQL. Но это скорее всего отдельным топиком.
28 дек 18, 10:51    [21775521]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
alex55555
Member

Откуда:
Сообщений: 2097
mayton
И интересно поразбираться на что так сильно уходит память

Куда объектов. Всегда так. Для XML это стандартная проблема - рост в 10-100 раз при загрузке в память. В памяти ведь не строки, а куча ссылок и служебной инфы про объекты. Плюс, конечно же, и строки тоже, но и они с дополнениями.

Эффективный по памяти формат крайне неудобен в работе. Это как всё хранить в одном массиве - в принципе можно, но никто так никогда делать не будет.
28 дек 18, 15:08    [21775829]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
alex55555
mayton
И интересно поразбираться на что так сильно уходит память

Куда объектов. Всегда так. Для XML это стандартная проблема - рост в 10-100 раз при загрузке в память. В памяти ведь не строки, а куча ссылок и служебной инфы про объекты. Плюс, конечно же, и строки тоже, но и они с дополнениями.

Эффективный по памяти формат крайне неудобен в работе. Это как всё хранить в одном массиве - в принципе можно, но никто так никогда делать не будет.

Хочу подчеркнуть что никакого XML на входе не было. Там был TTL. Но не суть. Все равно в памяти
графовая модель.

Вот фрагмен 1-й записи из справочника валют. Он внешне очень похож на базу знаний по организациям.

@prefix tr-common: <http://permid.org/ontology/common/> .
@prefix tr-currency: <http://permid.org/ontology/currency/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

<https://permid.org/1-500204>
        a                            tr-currency:Currency ;
        tr-common:hasPermId          "500204"^^xsd:string ;
        tr-currency:decimalPlaces    "2"^^xsd:decimal ;
        tr-currency:isCurrencyOf     <http://sws.geonames.org/718075> ;
        tr-currency:isISOHistorical  false ;
        tr-currency:isPrimaryCurrencyOf
                <http://sws.geonames.org/718075> ;
        tr-currency:iso4217          "MKD"^^xsd:string ;
        tr-currency:iso4217Numeric   "807"^^xsd:string ;
        skos:prefLabel               "Macedonian Denar" .

Обратите внимание что Македонский динар помимо атрибутов имеет еще и связи с sws.geonames.org
а это главное отличие от EAV. В атрибут-значение вы складываете только литералы а в RDF - связи
на другие узлы знаний. И связи различаются на уровне описания. Тоесть EAV описывает товар (Телевизор)
в магазине техники но он обычно не в состоянии описать то что в состав телевизора входит ... другой
телевизор. Это как-бы вне постановки EAV.
28 дек 18, 22:23    [21776086]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
exp98
Member

Откуда:
Сообщений: 1624
Вот и я о том же - описание сношений. Только этого мало.
Мне досталися на сопровождение фреймворкные взаимосвязанные проекты, в к-рых в частности на каждый бизнес-объект можно создавать типа (обж -- массив_сс_вверх -- массив_сс_вниз -- свойства), с автоматическим обновлением связей на выбор.
Надо ли говорить, что уже 3-х уровневая схема даёт тормоза. Хотя описать можно всё, что угодно, почти. Но скорость как бы пустяки.

По мне так важнее обработка семантики связей. И это самая трудозатратная часть. Предполагаю, что и "жена апача" предлагает всю смысловую реализацию делать с нуля и не предлагает ощутимых полезных инструментиков, хотябына некоторые предметные области. Готовых спецструктур, спецметодов и т.п. Ну то есть пока складывается мнение,что это наворченный парсер распределённой инфы. Но семантический поиск не сводится к уровню парсера. Поисковики используют имитаторы семантики в форме, например LSA и т.п.
Был бы рад ошибиться.
29 дек 18, 11:40    [21776285]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Жена Апача сдохла. Подавилась суффиксом "^^XSD:". Как пофиксить пока не знаю.

Но Eclipse RDF4j хавает нормально. По крайней мере парсер пробегает по всему документу.

Но я пока не нашел поддержки file-storage для графа. А это важно.
29 дек 18, 13:37    [21776386]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Интересно. Если почитать доки по Кроносу http://www.cronos.ru/cronospro.html
то складывается впечатление что тот решает вопросы хранения графовых данных.
13 янв 19, 22:14    [21784281]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 2579
mayton
Интересно. Если почитать доки по Кроносу http://www.cronos.ru/cronospro.html
то складывается впечатление что тот решает вопросы хранения графовых данных.


SQL Server решает, PostgreSQL тоже
30 янв 19, 15:25    [21797908]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Ролг Хупин
mayton
Интересно. Если почитать доки по Кроносу http://www.cronos.ru/cronospro.html
то складывается впечатление что тот решает вопросы хранения графовых данных.


SQL Server решает, PostgreSQL тоже

А можете привести линк где есть анонс или описание этой фичи для MS и PG ?
30 янв 19, 15:27    [21797911]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 2579
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 янв 19, 12:50    [21798687]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Ролг Хупин
mayton
пропущено...

А можете привести линк где есть анонс или описание этой фичи для MS и PG ?


Например, SQL Server 2017
https://www.red-gate.com/simple-talk/sql/sql-development/sql-server-graph-databases-part-1-introduction/

Спасибо. Почитаю.
31 янв 19, 12:56    [21798700]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
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 - это просто метафора.
Структура данных должна хранить вершины и рёбра а не базироваться поверх реляционных сущностей.
Рёбра исходящие из вершины как структура данных должны быть физически кластеризованы. Должны
лежать рядом.

Чтоб эффективно работать с графом - нужен граф.
1 фев 19, 11:12    [21799428]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 2579
mayton
mayton
пропущено...

Спасибо. Почитаю.

Я посмотрел. Я не нашел ничего интересного для работы с графами.
Обычная реляционная модель. Обычный SQL.

Это - тоже самое что и Apache Jena предлагает в качестве адаптера SDB для Oracle/Postfresql. Это я уже проходил.
Работает медленно.

Основной поинт графовых DBMS - это графовая структура данных внутри. Triples/Quads - это просто метафора.
Структура данных должна хранить вершины и рёбра а не базироваться поверх реляционных сущностей.
Рёбра исходящие из вершины как структура данных должны быть физически кластеризованы. Должны
лежать рядом.


Чтоб эффективно работать с графом - нужен граф.


Ну-ну.... полёт необоснованной фантазии
Графы в любом случае должны храниться в физическом файле.
1 фев 19, 12:10    [21799511]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Ролг Хупин
mayton
пропущено...

Я посмотрел. Я не нашел ничего интересного для работы с графами.
Обычная реляционная модель. Обычный SQL.

Это - тоже самое что и Apache Jena предлагает в качестве адаптера SDB для Oracle/Postfresql. Это я уже проходил.
Работает медленно.

Основной поинт графовых DBMS - это графовая структура данных внутри. Triples/Quads - это просто метафора.
Структура данных должна хранить вершины и рёбра а не базироваться поверх реляционных сущностей.
Рёбра исходящие из вершины как структура данных должны быть физически кластеризованы. Должны
лежать рядом.


Чтоб эффективно работать с графом - нужен граф.


Ну-ну.... полёт необоснованной фантазии
Графы в любом случае должны храниться в физическом файле.

Возможно ты не понимаешь как работает поиск в графах.

Для того чтобы он работал быстро. Вершина должна содержать в себе список инцедентрых ребер.

Если ребра "физически" хранятся в разных местах таблицы в БД. То на сборку путей будет потрачено
большое число IOPS.
1 фев 19, 12:33    [21799538]     Ответить | Цитировать Сообщить модератору
 Re: SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 2579
mayton
Ролг Хупин
пропущено...


Ну-ну.... полёт необоснованной фантазии
Графы в любом случае должны храниться в физическом файле.

Возможно ты не понимаешь как работает поиск в графах.

Для того чтобы он работал быстро. Вершина должна содержать в себе список инцедентрых ребер.

Если ребра "физически" хранятся в разных местах таблицы в БД. То на сборку путей будет потрачено
большое число IOPS.


Возможно ты и понимаешь, я не в курсе, допустим.

"Вершина должна содержать в себе список инцедентрых ребер."

Нет, это не обязательно, в базах есть еще и индексы.
7 фев 19, 13:51    [21803482]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Программирование Ответить