Как стать автором
Обновить

Комментарии 17

Вовремя преподнесенный материал!
Как раз диссертация связана с использованием семантики. Пожалуй такой инструмент сэкономит мне время.
О. Я как раз поднимал вопрос форматирования откровенного содержания… Ты можешь предложить какой-то вариант определения порнографии через триплеты? :)
Эта область содержит слишком много иносказательного материла. Все зависит от предметной области, в которой исполняется запрос. А значит по умолчанию должна использоваться область не включающая ХХХ, получиться такая естественна фильтрация.
Если кто-то будет использовать чистый поиск, всегда будет и такой которому нужен грязный (одно лишь xxx) =) Хотя идея неплохая
Грязный поиск есть и сейчас ;)
Так что тут будет просто четкая дифференциация, без диффузии грязного поиска в чистый.
Если только кто-либо опишет порнографию семантически (это кстати хорошая и прибыльная бизнес идея).
Семантика сделает результат поиска чище за счет того, что пользователь выбирает конкретную ветку графа с информацией — если взрослых материалов в ней нету, то и как результат оно не появится.
Сейчас это можно сделать с помощью фасетного поиска или/и принудительной категоризации запроса.
То есть прямо сказать -ага, вот мой запрос относится к домашним питомцам.

Более реальный на сейчас вариант — это фильтрация контента с помощью семантики. В нескольких онтологиях нужно описать характерный признаки из разных областей (от описания фотографии до описания характерных черт порно-доменов) и далее механизм на любом языке для, собственно, самой фильтрации.

Семантика удобна тем, что правила и поведение может задавать специалист без программистких скилов (например в Protégé), а реализация фльтра ограничевается определенным набором «фичей», которые пишет команда программистов.
Мухи отдельно, котлеты отдельно.
Плохая привычка сначала открывать линк, а потом смотреть что написано
(не безопасно для работы)
предполагаю какой это будет тормоз…
Да, это действительно проблема и даже, скорее, вызов.
С моих позиций, это задача уровня полета человека на Луну или выход в космос — там тоже были вызовы.

Да, сейчас triplestore хранилище создаются на базе релятивной базы, что не способствует производительности.
Есть специализированные хранилища, наподобие AllegroGraph — быстрые и ёмкие, но даже они имеют потолок. Мне страшно представить какой реальный объем семантических (или мета-данных) имеет средний руки бизнес процесс, а реакция должна быть достаточно быстрой. Для любого бизнеса скорость — это преимущество.
А тут целый ворох проблем: коммуникация, обновление, объемы, запросы… Брр-р-р.
Инновации одним словом.

нужно что-то более производительное на реальных бизнес-процессах,
слой модели/логики должен быть реализован на Си/С++
а РНР надо рассматривать как слой представления/отображения информации
Я думал, что никогда не промахнусь мимо комментария…
Однако вот
У нас php много задач решает, в том числе и плотная работа с хранилищем. Не могу сказать, что супер быстро на больших данных — архитектура хранилища над хранилищем дает о себе знать. С «честной» базой триплетов по скорости не должно проигрывать SQL субд.
мне кажется, что это довольно голословное утверждение. Хотя бы потому, что за реляционные СУБД ускоряют последние 40 лет куча конкурирующих серьёзных корпораций, а RDF-хранилища точит лет пять три околоакадемических компании
Это очевидный логический вывод.
Любое «виртуальное хранилище» над хранилищем будет уступать по производительности специализированному. Хотя бы потому, что реализацию можно оптимизировать на самом низком уровне (дисковые операции, память, алгоритмы).
Да, и я не верю, что 40 летний опыт нельзя реюзнуть :-)

За пруфом далеко ходить не надо: последние 25 лет различные ORM создают над реляционной бд объектно-ориентированное хранилище. И вдруг NoSQL оказывается «великим прорывом», а как же иначе — хранилище-то специализированное. Есть, правда, открытые вопросы с сортировками, агрегацией.

Вы же видели ссылку на заявленно-большу и производительную семантик СУБД в комментарии — оно специализированное, и не должно уступать по скорости любому другому специализированному.
Речь идет о порядках, а не microseconds.
Семантический поиск имеет место быть в своей нише на линейке времени развития технопрогресса как, например, патефон, который непременно потом уступит место магнитофону, а тот СиДи-плейеру.
Стоит ли развивать патефон, то есть, семантическую сеть, когда мы ожидаем приход смыслового поиска? Наверное, стоит, если он даёт хоть какой-то результат по сравнению с предыдущим достижением, тем более, что технологий осмысленной обработки текстов пока ещё нет в товарно-рыночном виде, готовом к употреблению, хотя разработки в области создания эвристико-смысловой технологии ведутся вовсю. Например, ТЭСОТ «Онтолоджи».
У истоков развития любой технологии стоит человеческая хотелка, от фоногрофа Эдисона до патефона лет 50 эта ниша была занята идеей одного человека и старанием тысяч и тысяч, и только потом пришел магнитофон, cd и т.д.
Я ковыряюсь в семантике, мне интересно.

PS
Я запнулся на фразе ТЭСОТ «Онтолоджи»
ТЭСОТ — Технология Эвристико-Смысловой Обработки Текстов
«Онтолоджи» — фирма? проект? человек? кунг-фу?
ТЭСОТ «Онтолоджи» — это продолжение проекта АОТ (машинный перевод и обработка текста) компании «Диалинг».
Мы тоже развивали в 1998-2002 годах разные виды «семантических технологий» — от «семантических сетей» до «семантических процессоров», пройдя и «нейронно-семантические подобия». Их ремейк сегодня использует ABBYY в своей технологии «Compreno».
Нужный этап, но возможности таких технологий не удовлетворяют сегодняшние запросы рынка.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории