Если не считать объем информации проблемой, то трудности начинаются с необходимости хранить и обрабатывать записи, разнообразие которых постоянно увеличивается и стремится к показателям реального мира.
Рассмотрим проблемы _очень_ сложных схем/моделей данных и использование RDF Storage в качестве варианта решения.
Data Science Weekend 2017. 1С-Битрикс. Чатбот для подсказки ответов на вопросыNewprolab
Александр Сербул, Руководитель направления, 1С-Битрикс. Если вы хотите получить доступ к видео выступления, заполните форму здесь: http://dswknd2017.datascienceweek.com/
This module supported the training on Linked Open Data delivered to the EU Institutions on 30 November 2015 in Brussels. https://joinup.ec.europa.eu/community/ods/news/ods-onsite-training-european-commission
Data Science Weekend 2017. 1С-Битрикс. Чатбот для подсказки ответов на вопросыNewprolab
Александр Сербул, Руководитель направления, 1С-Битрикс. Если вы хотите получить доступ к видео выступления, заполните форму здесь: http://dswknd2017.datascienceweek.com/
This module supported the training on Linked Open Data delivered to the EU Institutions on 30 November 2015 in Brussels. https://joinup.ec.europa.eu/community/ods/news/ods-onsite-training-european-commission
Объем информации не является проблемой, построить большое хранилище уже несложно. Трудности начинаются с необходимости хранить и обрабатывать записи, разнообразие которых постоянно увеличивается и стремится к показателям реального мира (бесконечности). Рассмотрим проблему и пути её решения.
С чего начать внедрение Hadoop в компании / Алексей Еремихин (Badoo)Ontico
+ Обзор внутреннего устройства Hadoop и продуктов вокруг;
+ Как можно использовать для решения (спектр);
+ Как подходить к обоснованности использования даже в небольших проектах;
+ Hadoop в Badoo - история успеха;
+ Hadoop в Badoo - история проблем.
В докладе мы поделимся опытом создания content-based рекомендательной системы для электронной коммерции, работающей на семантическом ядре рунета (десятки миллионов профилей). Расскажем, как организовали централизованный сбор и обработку информации о посещении пользователями более 100 000 сайтов различной направленности на основе Amazon Kinesis. Поделимся опытом многопоточной онлайн-индексации потоков данных в Lucene. Продемонстрируем используемые базовые алгоритмы ранжирования и формирования персональных рекомендаций для посетителей более 20 000 интернет-магазинов.
Поговорим о плюсах и минусах лямбда-архитектур и обоснуем выбранное нами архитектурное решение. Отдельно остановимся на тонкостях технической реализации многопоточных алгоритмов и особенностях обеспечения реального времени - поступившая информация о действиях посетителя практически мгновенно учитывается рекомендательным движком, обеспечивая максимальную конверсию.
Машинное обучение в электронной коммерции - практика использования и подводны...Ontico
РИТ++ 2017, секция ML + IoT + ИБ
Зал Белу-Оризонти, 5 июня, 16:00
Тезисы:
http://ritfest.ru/2017/abstracts/2532.html
Простыми словами расскажем о популярных, эффективных и используемых в нашей компании техниках применения машинного обучения для привлечения и удержания клиентов:
- кластеризации товарного каталога,
- классификации клиентов (готовых перейти на платный тариф, готовых уйти, способных принести прибыль),
- повышении релевантности e-mail-рассылок.
Особое внимание уделим технике использования популярных платформ и библиотек:
- Apache Spark,
- Spark MLlib,
- Hadoop,
- Amazon Kinesns.
Отдельно остановимся на особенностях обработки "больших данных", выборе и разработке параллельных алгоритмов.
Alexandr Serbul "The Rust language for a high-load network service - a quick ...Fwdays
In this talk, we will talk about the evolution of the development of a high-load network cluster for sending push notifications using technologies from Unix / bash and PHP to asynchronous non-blocking multithreaded connections based on Rust / Tokio. Let's talk about the intricacies of Rust development, language features, pitfalls, and ways to quickly learn and use it for web developers with LAMP skills. Let's also talk about Go, Java, and the reasons for our technological decisions.
The talk will be useful for developers wishing to master the latest and popular Rust programming language, functional programming, Haskell ideas with PHP / Python / JavaScript web development experience.
libfpta: в памяти, с персистентностью, быстрее хайпаLeonid Yuriev
Представление "Позитивных таблиц" – нового C/C++ движка, выполняющего до полумиллиона пишущих транзакций в секунду к табличным и key-value данным, и одновременно до миллиона читающих запросов на каждом ядре процессора.
libfpta обеспечивает полностью параллельно выполнение запросов чтения/поиска без блокировок внутри БД и без атомарных операций, а также реализует эффективное хранение multi-value значений. Поэтому интегрально libfpta опережает по производительности и Tarantool и RocksDB. А разница с такими "быстрыми" решениями как Hazelcast или Apache Ignite достигает иногда 10-ти и более раз.
Сегментация и поиск совпадений в бинарном потокеLeonid Yuriev
Дан миллиард файлов неизвестного формата.
Как выявить даже частичные совпадения, если одни файлы могут включать другие полностью или частями?
Как делать это, имея доступ только к потоку байтов без начала и конца?
Рассказ о разработанном подходе (методе) для решения таких задач. Принципиальные отличия в гибкости, в контроле над точностью и достоверностью, независимо от содержания и характера данных. Стоит уточнить:
Речь пойдет о способе сегментирования произвольного потока данных для последующего шинглирования.
При этом основной вопрос в том, как нарезать на вменяемые «шинглы» произвольную последовательность байтов без привязки к каким-либо абсолютным границам.
Объем информации не является проблемой, построить большое хранилище уже несложно. Трудности начинаются с необходимости хранить и обрабатывать записи, разнообразие которых постоянно увеличивается и стремится к показателям реального мира (бесконечности). Рассмотрим проблему и пути её решения.
С чего начать внедрение Hadoop в компании / Алексей Еремихин (Badoo)Ontico
+ Обзор внутреннего устройства Hadoop и продуктов вокруг;
+ Как можно использовать для решения (спектр);
+ Как подходить к обоснованности использования даже в небольших проектах;
+ Hadoop в Badoo - история успеха;
+ Hadoop в Badoo - история проблем.
В докладе мы поделимся опытом создания content-based рекомендательной системы для электронной коммерции, работающей на семантическом ядре рунета (десятки миллионов профилей). Расскажем, как организовали централизованный сбор и обработку информации о посещении пользователями более 100 000 сайтов различной направленности на основе Amazon Kinesis. Поделимся опытом многопоточной онлайн-индексации потоков данных в Lucene. Продемонстрируем используемые базовые алгоритмы ранжирования и формирования персональных рекомендаций для посетителей более 20 000 интернет-магазинов.
Поговорим о плюсах и минусах лямбда-архитектур и обоснуем выбранное нами архитектурное решение. Отдельно остановимся на тонкостях технической реализации многопоточных алгоритмов и особенностях обеспечения реального времени - поступившая информация о действиях посетителя практически мгновенно учитывается рекомендательным движком, обеспечивая максимальную конверсию.
Машинное обучение в электронной коммерции - практика использования и подводны...Ontico
РИТ++ 2017, секция ML + IoT + ИБ
Зал Белу-Оризонти, 5 июня, 16:00
Тезисы:
http://ritfest.ru/2017/abstracts/2532.html
Простыми словами расскажем о популярных, эффективных и используемых в нашей компании техниках применения машинного обучения для привлечения и удержания клиентов:
- кластеризации товарного каталога,
- классификации клиентов (готовых перейти на платный тариф, готовых уйти, способных принести прибыль),
- повышении релевантности e-mail-рассылок.
Особое внимание уделим технике использования популярных платформ и библиотек:
- Apache Spark,
- Spark MLlib,
- Hadoop,
- Amazon Kinesns.
Отдельно остановимся на особенностях обработки "больших данных", выборе и разработке параллельных алгоритмов.
Alexandr Serbul "The Rust language for a high-load network service - a quick ...Fwdays
In this talk, we will talk about the evolution of the development of a high-load network cluster for sending push notifications using technologies from Unix / bash and PHP to asynchronous non-blocking multithreaded connections based on Rust / Tokio. Let's talk about the intricacies of Rust development, language features, pitfalls, and ways to quickly learn and use it for web developers with LAMP skills. Let's also talk about Go, Java, and the reasons for our technological decisions.
The talk will be useful for developers wishing to master the latest and popular Rust programming language, functional programming, Haskell ideas with PHP / Python / JavaScript web development experience.
libfpta: в памяти, с персистентностью, быстрее хайпаLeonid Yuriev
Представление "Позитивных таблиц" – нового C/C++ движка, выполняющего до полумиллиона пишущих транзакций в секунду к табличным и key-value данным, и одновременно до миллиона читающих запросов на каждом ядре процессора.
libfpta обеспечивает полностью параллельно выполнение запросов чтения/поиска без блокировок внутри БД и без атомарных операций, а также реализует эффективное хранение multi-value значений. Поэтому интегрально libfpta опережает по производительности и Tarantool и RocksDB. А разница с такими "быстрыми" решениями как Hazelcast или Apache Ignite достигает иногда 10-ти и более раз.
Сегментация и поиск совпадений в бинарном потокеLeonid Yuriev
Дан миллиард файлов неизвестного формата.
Как выявить даже частичные совпадения, если одни файлы могут включать другие полностью или частями?
Как делать это, имея доступ только к потоку байтов без начала и конца?
Рассказ о разработанном подходе (методе) для решения таких задач. Принципиальные отличия в гибкости, в контроле над точностью и достоверностью, независимо от содержания и характера данных. Стоит уточнить:
Речь пойдет о способе сегментирования произвольного потока данных для последующего шинглирования.
При этом основной вопрос в том, как нарезать на вменяемые «шинглы» произвольную последовательность байтов без привязки к каким-либо абсолютным границам.
Слайды выступления на конференции HighLoad++2015
Lightning Memory-Mapped Database (LMDB) представляет собой интересный, во многом уникальный движок базы данных класса Berkeley DB и Level DB с ребус-подобным исходным кодом.
Будучи относительно малоизвестным, LMDB показывает ЧЕМПИОНСКУЮ производительность по чтению. А наши доработки в libmdbx предлагают ряд компромиссов для достижения невероятной производительности по записи.
http://www.highload.ru/2015/abstracts/1831.html
Кластерный LDAP-сервера для "Больших телекомов".
Слайды доклад с 12-ой Конференции Разработчиков Свободных Программ, 17-18 Октября 2015, г.Калуга
АННОТАЦИЯ
Производственная необходимость и обстоятельства подтолкнули Петер-Сервис использовать OpenLDAP в своих решениях, а затем заставили добиться «от этого кошмара» надёжной работы в нагруженном кластере.
Увы и ах, но общеизвестный проект с открытым исходным кодом и 25-летней историей, лежащий в основе LDAP как технологии, оказался хорошим примером «так делать НЕ надо». Но отступать нам было не с руки...
В результате мы сделали клон исходного проекта и за год получили LDAP-сервер относительно пригодный для промышленной эксплуатации в сфере телекоммуникаций: десятки и сотни миллионов записей, высокие нагрузки, высокая доступность, 24x7.
Lightning Memory-Mapped Database (LMDB) - представляет собой интересный, во многом уникальный, движок базы данных класса Berkeley DB / Level DB. Будучи относительно малоизвестным, LMDB показывает чемпионскую производительность по чтению и предлагает ряд компромиссов для достижения невероятной производительности по записи.
LMDB был создан для использования внутри известного проекта OpenLDAP с открытым исходным кодом. Как разработчик и поставщик решений для «больших телекомов», компания «Петер-Сервис» решила задействовать связку OpenLDAP+LMDB в одном из своих проектов. Это был вход в кротовую нору, всё было как в сказке – чем дальше, тем страшнее...
В результате мы сделали клон/fork исходного проекта и создали высокопроизводительное стабильное решение промышленного масштаба с открытым исходным кодом. Расскажу о внутреннем устройстве LMDB, о выявленных недостатках и наших доработках для их устранения.
Highload++2014: 1Hippeus - zerocopy messaging in the spirit of Sparta!Leonid Yuriev
1Hippeus – инфраструктура обмена сообщениями, ориентированная на предельно эффективное zero-copy & lockfree-взаимодействие через разделяемую память, RDMA, MPI, коммуникации с GPU, сетевыми адаптерами, SDN & NFV, гипервизоры. Это инфраструктурный проект, который станет Open Source уже в первом релизе
Highload++2013: TopGun - архитектура терабитной платформы DPILeonid Yuriev
Презентация с конференции HighLoad-2013 об архитектуре новой DPI платформы Петер-Сервис.
http://www.highload.ru/2013/abstracts/1178.html
Представлен обзор архитектуры многоцелевой DPI-платформы, на основе которой могут строиться как "шпионские" приложения класса СОРМ/PRISM, так и коммерческие системы PCEF/TDF (Traffic Shaping), безопасного Интернета (интеллектуальная фильтрация содержимого), таргетирования рекламы и т. д. К особенностям рассматриваемого решения можно отнести мультитерабитное масштабирование, способ балансировки, обработку "роем" (Swarm Intelligence) и аварийного восстановления (failover) посредством репликации конечных автоматов.
Roadmap:
- offtopic: кому и зачем нужен DPI?
- offtopic: законность и морально-этические вопросы.
- на какую "луну" нужно сесть, что мы хотим сделать?
- распределение трафика за счет использования коммутаторов и MAC rewrite.
- роевой интеллект (Swarm Intellegence) для управления балансировкой и обработкой данных.
- репликация конечных автоматов (виртуальных микромашин).
- распределенное "Табло" как оперативное хранилище с элементами key-value и eventual consistency, lockfree в shared memory.
- транспортный фасад, унифицирующий DPDK, netmap, Infiniband (RDMA), 0mq и zerocopy и lockfree обмен через shared memory.
2. СОДЕРЖАНИЕ ДОКЛАДА
≈ 30 слайдов
1. Иллюстрация проблем на трех примерах.
2. Анализ: в чем причины и что делать?
3. Пара слов о RDF и OWL. Где здесь решение?
4. Критика, мифы и реальные "грабли".
5. Чего не хватает. Нечеткие знания и нечеткая логика.
3. Леонид Юрьев
• 20-25 лет программирую
• системный архитектор в Петер-Сервис R&D
• текущие проекты: TopGun DPI, 1Hippeus
leonid.yuriev@billing.ru
leo@yuriev.ru
4. • решения для крупных операторов связи:
BSS, Telco protocols, BigData, HA & HighLoad
• ≈ 20 лет полного цикла: разработка,
внедрение и сопровождение
• более 100 миллионов абонентов обслуживается
при участи наших систем
• ≈ 900 сотрудников, из них 400 разработчиков,
250 во внедрении и поддержке
• R&D подразделение в Сколково
5. BigData ≈ на ближайшие 40 минут, это когда…
1. данных много
= тяжело унести физически ;)
2. и они разные
= долго описывать структуру формально…
6. Пример №1: ОЦЕНКА РИСКОВ ПО (1)
По контрагенту, поставщику, выявление «однодневок»,
аналитика:
• Источники = ИФНС, ГМЦ Росстата, ЕГРЮЛ, ЕГРИП, Арбитраж,
OpenData, LinkedData, связи из соцсетей...
• Объекты = адреса, юрлица, учредители, судебные решения,
госконтракты, отчетность, упоминания в прессе...
7. Пример №1: ОЦЕНКА РИСКОВ (2)
Структура некоторых источников в цифрах:
• Юрлицо ≈50 полей, ≈5 таблиц
• Баланс субъекта в Роскомстате
≈ перечень полей на 7 страниц
• Реестр ЕМИСС ≈ 4500 результирующих таблиц
8. Пример №1: ОЦЕНКА РИСКОВ (3)
• Автономность ≈ источники данных независимо
спроектированы и продолжают развиваться
• Разнородность ≈ данные гетерогенны, схемы построены
разными методиками
• Зоопарк ≈ разные технологии, инструментальные средства,
форматы и синтаксисы
9. Пример №2: ПРЕДСКАЗАНИЕ ПОКУПОК
Таргетирование рекламы по предпочтениям и
персональному прогнозу покупки:
• Источники = Социальные сети, Ритейлеры, Мобильные
приложения, OpenData...
• Объекты = потребители, предпочтения, покупки, лайки,
открытые события...
10. Пример №3: DLP / СОРМ-3 / PRISM
Родственные технологии, главные различия в масштабе
и детализации:
• Записи = «Растущие» атрибутные деревья с элементами
наследования
• Индексы = Много FK и регулярно возникает желание
персонально индексировать каждый «листик»...
11. ЭФФЕКТ «ГОРИЗОНТА»
• Источники данных = нефиксированный, итеративно
пополняемый список
• Структура данных = нефиксированная,
подвержена итеративному расширению и постоянной эволюции
• Изменения естественны и постоянны, планирование и
оптимизация почти напрасны
Интеграция становится адовой задачей, чем дальше – тем
сложнее. «Горизонт» отдаляется…
12. ТРАДИЦИОННЫЕ ПУТИ РЕШЕНИЯ
И ИХ ПРОБЛЕМЫ
• SQL = много таблиц и NULL-значений, всё плохо…
• Key-Value и SOA = лепим жупел из сервисов, решается часть
проблем с хранилищем…
• Doc-Oriented = schemaless, некая локальность, нужны
индексы, «ручной» привод для 1-2-3, можно выжить…
• Graph-Oriented & RDF-storage = ага, чуть позже…
13. ПОЧЕМУ?
ПРИЧИНЫ (ПАФОСНО)
Информация о действительности обладает структурой, но
неподъемной для формализации, поэтому:
• Упрощаем и искажаем, отображая на возможности технологий
и инструментов, дробим знания между БД, сервисам и app
• Создаем внутренние знания: типы в схеме, ID записей, ID в
справочниках и таксономиях
• Итог = Изменение схемы мега-дорого, итеративное развитие
невозможно, интеграция трудна…
14. НАПРИМЕР, В ИДЕАЛЕ…
1. не отказываться от схемы/модели данных
2. но и не фиксировать
3. позволить постоянно развиваться…
Но как итеративно уточнять формальную модель, одновременно
«не ломая» систему хранения и код сервисов/приложений?
Объектно-ориентированные БД ≈ было,
нет удобных формальных моделей эффективных для реализации,
программисты увлекаются…
15. ТОГДА…
1. Упорядоченность усилий ≈ видение пути к целям
2. Agile ≈ лояльность к изменениям
3. Итеративность ≈ возможность выдавать value на
каждом шаге
16. RDF ≈ СРАВНИВАЯ С…
• key-value = это RDF с переносом «смысла связей»
в логику кода
• doc oriented = в RDF нет документов и локальности,
связи неотделимы от данных
• SQL = RDF похож на доменно-ключевую нормальную
форму (DKNF, 5+)
• graph database = очень близко,
но в RDF у связей нет атрибутов
18. RDF/OWL – WTF (1)
1.
2. маша является персоной
рама является предметом
маша мыла раму
3. Triplestore или RDF storage
≈ утрированно одна таблица, на деле сложнее…
Яндекс://RDF primer
субъект объект
предикат
19. RDF/OWL – WTF (2)
1. RDFS = схема, может врожденно
храниться вместе с данными
2. персона type class. предмет type class.
мыть type property. мыть domain персона.
мыть range предмет.
3. OWL ≈ расширяет RDFS для описания онтологий,
добавляет: отрицания, cardinality, множества
классов, метаданные схемы…
20. RDF/OWL – WTF (3)
1. SPARQL = язык запросов > SQL,
CRUD, графы, XPath, hash, …
2. PREFIX foaf: http://xmlns.com/foaf/0.1/
SELECT ?name (COUNT(?friend) AS ?count)
WHERE {
?person foaf:name ?name .
?person foaf:knows ?friend .
} GROUP BY ?person ?name
3. SPIN ≈ «хранимые процедуры» SPARQL внутри RDF,
включая constraints и rules
21. RDF ≈ ФИШКИ
1. Аскетизм в базисе, только триплеты
2. Онтология и схема вместе с данными
3. Интеграция через URI как схем, так и данных
4. Объектная модель классов с наследованием и
декларацией эквивалентности
5. Рефлексия, встроенный ИИ для оптимизации
6. Подходит для краудсорсинга онтологий
22. RDF ≈ ГДЕ ТУТ РЕШЕНИЕ ?
Препятствия сохраняются, но их легче
преодолевать:
1. Эволюция схемы без ALTER TABLE
2. Внутренние знания не нужны, либо становятся
открытыми
3. Интеграция легка и естественна
23. RDF ≈ КРИТИКА
1. мимо ≈ Онтология верхнего уровня сомнительна
– пусть делают философы ;)
2. мимо ≈ Семантическая паутина нереализуема
– нет необходимости
3. OWL ≈ Сложно, но есть теория
4. SPARQL ≈ Перестарались, но есть алгебра
5. Storage ≈ Нет образца, но есть стандарт
24. RDF ≈ WTF REASONING ?
• Если «Маша мыла раму»,
то следовательно «рама помыта Машей»
• Дескрипционная логика = компромисс между
выразительностью и вычислимостью
• Reasoner = механизм вывода:
- реализуется программно, очень важен алгоритм
- может быть независимым, а не частью хранилища
• Материализация = вывод с сохранением
25. МАТЕРИАЛИЗАЦИЯ ≈ ИНДЕКС ?!
• добавляем триплеты и этим помечаем связанные
элементы
• не обязательно REASONING/OWL,
можно «руками» или через SPARQL
• крутое хранилище может обеспечивать
отслеживание и авто-материализацию
26. RDF ≈ ГРАБЛИ №1
• Хранилище может быть в чем-то наивным:
- без упорядоченных величин (фильтры Блюма)
- что-то из SPARQL выполнять очень медленно
- нет гарантий base level of performance
• Онтологии сложно создавать:
- отдельная область знаний и навыков, методологии
- легко сделать неправильно и понять это в конце
• SPARQL и REASONING:
- слишком много возможностей
- детали могут сильно влиять на скорость
27. RDF ≈ ГРАБЛИ №2
• Попробовали, не получилось:
- изучали сложное
- долго делали
- получилась хрень…
• Почему?
технология = маловероятно
компоненты = возможно
опыт и компетенции = скорее всего
• Причины: плохо с методологиями,
мало опыта, некого спросить, легко ошибиться…
28. RDF+BigData ≈ HR FAILURE
Страшилка о требуемых компетенциях специалиста:
1. не бояться непонятно-сложных задач и нового
2. уметь что-то программировать
3. понимать в устройстве баз данных
4. знать статистику
5. разбираться в машинном обучении
6. быть экспертом в предметной области
7. добавляется: навыки RDF, OWL, SPARQL и SPIN
– пора учиться…
29. RDF ≈ ГДЕ ПРЕДЕЛ ?
• Нечеткие знания:
- неполая информация, предположения
- неточная информация, ошибки изменения
- неоднозначная информация
- недетерминированность процессов и выводов
Птицы летают? А пингвины птицы? Сколько их?
• Модель закрытого мира ≈ плохо
- знания всегда не полные
- события вероятностны (квантовая механика)
- ложь/истина, либо выбрасываем…
30. ОЦЕНКА УПОМИНАНИЙ (1)
• Требуется обработка естественного языка (NLP):
- морфология, ключевые слова и сочетания
- лексико-статический анализ (наивная семантика)
- синтаксический анализ, подлежащее/сказуемое
- ABBYY COMPRENO
• Хранение: RDF не обязательно, PostgreSQL + JSONb,
Mongo…
• Вывод: Много правил/условий, поэтому SPARQL и
REASONING по результатам NLP
31. ОЦЕНКА УПОМИНАНИЙ (2)
• Начало проблем:
- модель языка упрощена, знания о нём не полны
- много неоднозначностей
- точный результат недостижим
• Вывод по дескрипционной логике:
- ложь/истина или выбрасываем
- ошибки накапливаются, результаты искажаются
- монотонность нарушается, обучение не работает
• Чем больше данных и правил, тем хуже ≈ жупел
32. ВРЕМЕННОЕ РЕШЕНИЕ
Квантование:
100% = истина/да
75% ≈ вполне возможно
50% ≈ может быть
25% ≈ маловероятно
0% = ложь/нет
− Тяжелеет описание схемы и правил
− 20-80% результатов стремится к «может быть»
+ Позволяет решить 20-80% задач
33. UNCERTAIN FUZZY RDF
• Сомнительная пушистость :)
- коэффициенты уверенности
- интервальная арифметика
- вероятностный и модифицированный
байесовский подход
- нечеткая логика и множества (fuzzy logic)
- теория очевидностей (Демпстера — Шафера)
• Методики и инструменты
- Fuzzy OWL (онтология для нечеткой логики)
- PR-OWL (онтология с байесовским подходом)
- UMP-ST (моделирование нечетких процессов)
34. КОДА
• RDF = одна из форм записи графов,
может проецироваться на любое хранилище
• Ореолы Triplestore и Graph Database почти
совпадают
• RDFS и OWL = описывают знания, а не ограничивают
их структуру
• Apache Jena прекрасно работает поверх PostgreSQL
35. Спасибо, за внимание!
Леонид Юрьев
• 20-25 лет программирую
• системный архитектор в Петер-Сервис R&D
• текущие проекты: TopGun DPI, 1Hippeus
leonid.yuriev@billing.ru
leo@yuriev.ru
36. ССЫЛКИ
1. RDF Primer
http://yandex.ru/yandsearch?text=rdf+primer
2. Reasoning for Linked Data
http://renaud.delbru.fr/doc/pub/rw-2013.pdf
3. Fuzzy OWL
http://arxiv.org/pdf/1009.3391.pdf
4. Fuzzy logic reasoner
http://gaia.isti.cnr.it/straccia/download/papers/FUZZ08/FUZZ08.pdf
5. Dempster–Shafer OWL
http://arxiv.org/ftp/arxiv/papers/1106/1106.3876.pdf
6. Защита докторской по байесовской OWL
https://www.youtube.com/watch?v=Zl5rmag6BqY