ReSQL.ru
     
powered by simpleCommunicator - 2.0.50     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
25 сообщений из 53, страница 2 из 3
  2  все
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39753105
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
exp98EAV значение- атрибут- объект ?
С трудом представляю. СС, имхо, должнс подразумевать отношения между сучностями.
EAV:
EntityAttributeValue

RDF:
SubjectPredicateObject
...
Рейтинг: 0 / 0
25.12.2018, 21:30
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39753564
exp98
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
exp98
Участник
Я предполагал это возражение. Если в ЕАВе есть достаточные инструменты семантической обработки атрибутов, тогда что нового предложил апач?
Если и там и там всё самому писать, то какая вообще разница где? Но я уверен, что ЕАВ - имеет сугубо фрмальное сходство,и вообще он даже не каккой-то конкретный формат, а всего лищь концепция, и уж в этой парадигме уж точно всё самому писать. Так, блин, что мешает тогда в оракле строить таблицы с ссылками на себя же, а потом из них "селект - коннект бай левел".
Так что с НГ!
...
Рейтинг: 0 / 0
26.12.2018, 17:51
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39753715
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
В RDF-модели Object может указывать (URI) на Subject (вплоть до кольцевых связей). Вспоминаем циклы в графах.
Вобщем для семантического веба это нормально. Object может быть и посто литералом например "String", 5$,
1.2кг, 'e' (символ е).

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

Тоесть семантика RDF скорее всего более широкая. Кроме того namespaces... мать их так.
...
Рейтинг: 0 / 0
27.12.2018, 00:16
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39753723
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Существует еще один вариант RDF с четырьмя элементами.
Это т.н именованный граф.

GraphSubjectPredicateObject

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

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

"New-York"@en
"Нью-Йорк"@ru
...
Рейтинг: 0 / 0
27.12.2018, 01:43
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39753727
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Еще ссылка по теме. Редактор онтологий. Еще не разбирался.

https://protege.stanford.edu/
...
Рейтинг: 0 / 0
27.12.2018, 03:23
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39753815
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
mayton,

что там, что тут - триплеты, как ты их трактуешь - твое дело
...
Рейтинг: 0 / 0
27.12.2018, 11:19
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39753817
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
ViPRos,
...
Рейтинг: 0 / 0
27.12.2018, 11:23
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39753903
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Круть. Но это приложение. А можно взглянуть на его онтологическое описание?
...
Рейтинг: 0 / 0
27.12.2018, 13:58
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39753926
exp98
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
exp98
Участник
Я помню эту круть, и даже видел декларативное описание, тогда мне понравилось. Только к ней нужен дотнет.
...
Рейтинг: 0 / 0
27.12.2018, 14:34
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39753962
exp98
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
exp98
Участник
кстати здесь было
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
...
Рейтинг: 0 / 0
27.12.2018, 15:05
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39754191
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex55555
Участник
maytonЕще ссылка по теме. Редактор онтологий. Еще не разбирался.

https://protege.stanford.edu/
Подобных редакторов много, но все с особенностями. Можно привыкнуть, но при большом объёме работ это очень замедляет процесс. Можно выбрать другой редактор, но они весьма и весьма похожи, поэтому чуть что не так как хочется - нигде нету. По сути для масштабной разработки выход один - писать самим. Вот VIPRos как раз сам написал и редактор онтологии и к нему генератор гуя и операций с БД, что в сумме дало мини-ERP, которую он внедрил в своей конторе.
...
Рейтинг: 0 / 0
27.12.2018, 20:13
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39754402
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Жаль что он самозобанился.

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

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

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

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

Чуть позже мне понадобиться SparkQL. Но это скорее всего отдельным топиком.
...
Рейтинг: 0 / 0
28.12.2018, 10:51
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39754596
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex55555
Участник
maytonИ интересно поразбираться на что так сильно уходит память
Куда объектов. Всегда так. Для XML это стандартная проблема - рост в 10-100 раз при загрузке в память. В памяти ведь не строки, а куча ссылок и служебной инфы про объекты. Плюс, конечно же, и строки тоже, но и они с дополнениями.

Эффективный по памяти формат крайне неудобен в работе. Это как всё хранить в одном массиве - в принципе можно, но никто так никогда делать не будет.
...
Рейтинг: 0 / 0
28.12.2018, 15:08
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39754731
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
alex55555maytonИ интересно поразбираться на что так сильно уходит память
Куда объектов. Всегда так. Для XML это стандартная проблема - рост в 10-100 раз при загрузке в память. В памяти ведь не строки, а куча ссылок и служебной инфы про объекты. Плюс, конечно же, и строки тоже, но и они с дополнениями.

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

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

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
@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.
...
Рейтинг: 0 / 0
28.12.2018, 22:23
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39754847
exp98
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
exp98
Участник
Вот и я о том же - описание сношений. Только этого мало.
Мне досталися на сопровождение фреймворкные взаимосвязанные проекты, в к-рых в частности на каждый бизнес-объект можно создавать типа (обж -- массив_сс_вверх -- массив_сс_вниз -- свойства), с автоматическим обновлением связей на выбор.
Надо ли говорить, что уже 3-х уровневая схема даёт тормоза. Хотя описать можно всё, что угодно, почти. Но скорость как бы пустяки.

По мне так важнее обработка семантики связей. И это самая трудозатратная часть. Предполагаю, что и "жена апача" предлагает всю смысловую реализацию делать с нуля и не предлагает ощутимых полезных инструментиков, хотябына некоторые предметные области. Готовых спецструктур, спецметодов и т.п. Ну то есть пока складывается мнение,что это наворченный парсер распределённой инфы. Но семантический поиск не сводится к уровню парсера. Поисковики используют имитаторы семантики в форме, например LSA и т.п.
Был бы рад ошибиться.
...
Рейтинг: 0 / 0
29.12.2018, 11:40
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39754923
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Жена Апача сдохла. Подавилась суффиксом "^^XSD:". Как пофиксить пока не знаю.

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

Но я пока не нашел поддержки file-storage для графа. А это важно.
...
Рейтинг: 0 / 0
29.12.2018, 13:37
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39759088
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Интересно. Если почитать доки по Кроносу http://www.cronos.ru/cronospro.html
то складывается впечатление что тот решает вопросы хранения графовых данных.
...
Рейтинг: 0 / 0
13.01.2019, 22:14
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39767104
Ролг Хупин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ролг Хупин
Участник
maytonИнтересно. Если почитать доки по Кроносу http://www.cronos.ru/cronospro.html
то складывается впечатление что тот решает вопросы хранения графовых данных.

SQL Server решает, PostgreSQL тоже
...
Рейтинг: 0 / 0
30.01.2019, 15:25
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39767106
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Ролг ХупинmaytonИнтересно. Если почитать доки по Кроносу http://www.cronos.ru/cronospro.html
то складывается впечатление что тот решает вопросы хранения графовых данных.

SQL Server решает, PostgreSQL тоже
А можете привести линк где есть анонс или описание этой фичи для MS и PG ?
...
Рейтинг: 0 / 0
30.01.2019, 15:27
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39767541
Ролг Хупин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ролг Хупин
Участник
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/
...
Рейтинг: 0 / 0
31.01.2019, 12:50
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39767551
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Ролг Хупинmaytonпропущено...

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

Например, SQL Server 2017
https://www.red-gate.com/simple-talk/sql/sql-development/sql-server-graph-databases-part-1-introduction/
Спасибо. Почитаю.
...
Рейтинг: 0 / 0
31.01.2019, 12:56
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39767991
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
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 - это просто метафора.
Структура данных должна хранить вершины и рёбра а не базироваться поверх реляционных сущностей.
Рёбра исходящие из вершины как структура данных должны быть физически кластеризованы. Должны
лежать рядом.

Чтоб эффективно работать с графом - нужен граф.
...
Рейтинг: 0 / 0
01.02.2019, 11:12
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39768051
Ролг Хупин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ролг Хупин
Участник
maytonmaytonпропущено...

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

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

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

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

Ну-ну.... полёт необоснованной фантазии
Графы в любом случае должны храниться в физическом файле.
...
Рейтинг: 0 / 0
01.02.2019, 12:10
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39768073
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Ролг Хупинmaytonпропущено...

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

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

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

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

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

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

Если ребра "физически" хранятся в разных местах таблицы в БД. То на сборку путей будет потрачено
большое число IOPS.
...
Рейтинг: 0 / 0
01.02.2019, 12:33
| Ответить | Цитировать | Написать  
SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
    #39770655
Ролг Хупин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ролг Хупин
Участник
maytonРолг Хупинпропущено...


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

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

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

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

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

Нет, это не обязательно, в базах есть еще и индексы.
...
Рейтинг: 0 / 0
07.02.2019, 13:51
| Ответить | Цитировать | Написать  
25 сообщений из 53, страница 2 из 3
  2  все
Форумы / Программирование [игнор отключен] [закрыт для гостей] / SParQL :: RDF :: технологии семантического поиска :: AWS:Neptune
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=16&msg=39754731&tid=1339993]:
 0ms
get settings:
 8ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 126ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 59ms
get tp. blocked users:
 1ms
others: 239ms
total:  465ms
созд. / загр.: 465ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]