Да, результаты обработки документов кладутся в индекс, поиск по которому осуществляется довольно быстро. Даже если закрыть глаза на вопросы производительности, остаётся вопрос целесообразности: неясно, как такие данные можно применить для значительного повышения качества поиска.
На мой взгляд, гораздо важнее уловить профиль пользователя и угадать его сиюминутную потребность, чем тратить память и процессорное время на полный разбор документов. В качестве подтверждения можно посмотреть тематику пленарных докладов на ведущих конференциях последних лет по информационному поиску: ECIR 2014, ECIR 2015.
Не забывайте про грамотность и закон Парето на примере публики из социальных сетей. Увы, не каждый носитель русского языка способен уловить тонкий смысл комментариев на скриншотах по ссылке. Пожалейте компьютеры: рано или поздно они тоже научатся чувствовать и переживать.
Облака — всего лишь способ предоставления ресурсов. В соседнем комментарии я писал, что процесс такой обработки сложно распараллелить, а значит, горизонтальное масштабирование вряд ли поможет делу.
Я видел демонстрацию машинного перевода при помощи Compreno в 2012 году и перевод новости из (около) семи абзацев длился несколько десятков секунд. Несколько месяцев назад мои коллеги рассматривали Compreno для анализа содержимого документов и по каким-то причинам отказались в сторону более простых решений.
При правильной реализации, время анализа предложения в значительной мере зависит от количества слов в нём, но такие решения всё равно не работают быстро: полный разбор документа тяжело распараллеливается из-за явления кореферентности. Бывают задачи, где время не так критично: системы общения, системы понимания текста, а есть задачи, где каждая миллисекунда на счету.
Эта информация была бы слишком избыточной для поисковиков. Но главная проблема состоит в производительности: Compreno занимается полным разбором каждого предложения, что очень накладно с вычислительной точки зрения. Сегодня применять подобные решения в поисковиках общего назначения выйдет слишком дорого (или долго). У специализированных поисковых машин, при этом, нет нужды в огромной онтологии.
Основное достоинство Amazon S3 и совместимых с ним сервисов заключается в том, что для них сделано очень много готовых и простых в использовании инструментов, в том числе и для создания резервных копий данных. Насколько сложно или неудобно заливать резервные копии напрямую на S3 по сравнению с предложенным решением?
Утверждение в первом содержательном абзаце ничем не обосновано: нет ни обзора существующих работ, ни ссылок на обзорные работы. Автоматизация построения онтологий — чрезвычайно важное (и интересное) направление исследований, но нельзя начинать с нуля. Мне кажется, статью можно улучшить добавлением отдельного раздела про особенности и недостатки существующих решений. В англоязычных работах это называется Related Work.
Апробация тезауруса может выполняться двумя способами. Можно взять какую-нибудь дорожку РОМИП и сравнить результат работы вашего ресурса с известными результатами на этой дорожке. Можно сопоставить ваш ресурс с каким-либо золотым стандартом, но здесь всё сложнее, потому что нужно найти хорошо изученную онтологию по вашей тематике. Ну, есть ещё третий вариант — выполнить экспертную оценку, но это слишком долго и дорого. Обозначенная рубрика arXiv.org — всего лишь неразмеченный набор данных. Как вы собираетесь оценивать по нему свою онтологию?
После слов «планируем отдать эту технологию в open source» пролистал вниз, поставил плюсик и лишь потом вернулся и дочитал. Спасибо!
Остаётся всего один неоднозначный момент.
Изменятся ли условия использования после открытия кода? Анализатор хорошо работает уже сейчас, однако последняя часть пункта 3.2 текущего лицензионного соглашения запрещает любое более-менее практическое применение «Томиты».
Для статей подобного формата существуют специальные журналы, утверждённые ВАК. В том числе по компьютерной лингвистике и обработке естественного языка. Здесь принято писать менее формальным языком.
Можно предложить сколь угодно методов автоматического построения тезаурусов лексических онтологий, но почему в статье нет раздела про апробацию полученного ресурса? Какова актуальность работы? Чем указанный подход лучше ручной разметки или других известных решений?
Эталонным поведением считается поведение Ruby-версии библиотеки, так сложилось исторически. Имеется централизованный репозиторий с правилами, которые должны использоваться всеми портами. Если этого не происходит, то нужно обратиться к автору порта. Если выявляются ошибки в правилах, то мы стараемся исправить их по мере информирования.
Сейчас PHP-версия поддерживается difiso. Надеюсь, он увидит этот вопрос.
У ребят был очень модный сайт и складывалось ощущение, что дела идут замечательно. Их сервис выглядел так, что им хотелось пользоваться. Кто-нибудь знает реальные причины закрытия?
Пожалуйста, не злоупотребляйте Prezi. Проблема заключается в том, что люди пытаются напихать как можно больше плывучих эффектов на каждый слайд. На моей памяти была конференция, где три докладчика подряд решили продемонстрировать свою «креативность» и глубокую творческую натуру. В итоге аудиторию укачало ещё в середине второй презентации, так как каждый видимый пискель был анимирован.
Это такой же инструмент, как PowerPoint и подобные. Везде можно сделать омерзительное зрелище, но Prezi даёт больше возможностей для этого. Помните, что всё в итоге определяется умением человека взаимодействовать с аудиторией, а не выбирать функцию движения спрайтов.
Проблема кривой обучения хорошо обозначена в самом начале статьи. Склад мышления наших людей таков, что они в большинстве своём не привыкли строить решения, основанные на данных. Тема с открытыми, например, государственными данными в России начинает подниматься только сейчас. Пройдёт несколько лет и станет легче (надеюсь).
Безусловно, нет никаких проблем отобразить CSV в RDF напрямую. Это не всегда правильно, так как наверняка найдётся словарь RDF, который уже описывает данную предметную область, и в нём придётся разбираться. В области XML существует аналогичная ситуация с XML Schema. Это вопрос интероперабельности.
Да, концепция Linked Data прекрасна представлением объектов в виде SVO-троек и возможностью рисования запросов по коллекциям таких троек. Однако, на мой скромный взгляд, существует две системных проблемы технологий Linked Data и Semantic Web:
Достаточно резкая кривая обучения. Допустим, программисты хотят просто получить данные. Вместо этого им предоставляется «какой-то SPARQL» и аппарат дескрипционной логики. Если по работе приходится «писать контроллеры», то на столь высокие вещи у людей времени обычно нет.
Нетривиальный способ публикации данных. Хорошо, когда твоя информационная система общается сразу в RDF. А если нет? Обычно люди представляют данные в чём-то ещё: реляционные СУБД, файлы, модные NoSQL-решения. Выгрузка данных в форматах Linked Data вызывает дополнительные накладные расходы.
Когда информационная система изначально построена поверх Linked Data и эти форматы являются для неё родными, то всё чудесно. Практика оказывается, увы, несколько иной.
На мой взгляд, гораздо важнее уловить профиль пользователя и угадать его сиюминутную потребность, чем тратить память и процессорное время на полный разбор документов. В качестве подтверждения можно посмотреть тематику пленарных докладов на ведущих конференциях последних лет по информационному поиску: ECIR 2014, ECIR 2015.
Не забывайте про грамотность и закон Парето на примере публики из социальных сетей. Увы, не каждый носитель русского языка способен уловить тонкий смысл комментариев на скриншотах по ссылке. Пожалейте компьютеры: рано или поздно они тоже научатся чувствовать и переживать.
Облака — всего лишь способ предоставления ресурсов. В соседнем комментарии я писал, что процесс такой обработки сложно распараллелить, а значит, горизонтальное масштабирование вряд ли поможет делу.
При правильной реализации, время анализа предложения в значительной мере зависит от количества слов в нём, но такие решения всё равно не работают быстро: полный разбор документа тяжело распараллеливается из-за явления кореферентности. Бывают задачи, где время не так критично: системы общения, системы понимания текста, а есть задачи, где каждая миллисекунда на счету.
Апробация тезауруса может выполняться двумя способами. Можно взять какую-нибудь дорожку РОМИП и сравнить результат работы вашего ресурса с известными результатами на этой дорожке. Можно сопоставить ваш ресурс с каким-либо золотым стандартом, но здесь всё сложнее, потому что нужно найти хорошо изученную онтологию по вашей тематике. Ну, есть ещё третий вариант — выполнить экспертную оценку, но это слишком долго и дорого. Обозначенная рубрика arXiv.org — всего лишь неразмеченный набор данных. Как вы собираетесь оценивать по нему свою онтологию?
Остаётся всего один неоднозначный момент.
Изменятся ли условия использования после открытия кода? Анализатор хорошо работает уже сейчас, однако последняя часть пункта 3.2 текущего лицензионного соглашения запрещает любое более-менее практическое применение «Томиты».
Можно предложить сколь угодно методов автоматического построения тезаурусов лексических онтологий, но почему в статье нет раздела про апробацию полученного ресурса? Какова актуальность работы? Чем указанный подход лучше ручной разметки или других известных решений?
Эталонным поведением считается поведение Ruby-версии библиотеки, так сложилось исторически. Имеется централизованный репозиторий с правилами, которые должны использоваться всеми портами. Если этого не происходит, то нужно обратиться к автору порта. Если выявляются ошибки в правилах, то мы стараемся исправить их по мере информирования.
Сейчас PHP-версия поддерживается difiso. Надеюсь, он увидит этот вопрос.
Это такой же инструмент, как PowerPoint и подобные. Везде можно сделать омерзительное зрелище, но Prezi даёт больше возможностей для этого. Помните, что всё в итоге определяется умением человека взаимодействовать с аудиторией, а не выбирать функцию движения спрайтов.
Теперь мы поддерживаем несколько официальных портов, список которых представлен на странице организации github.com/petrovich/petrovich.
Безусловно, нет никаких проблем отобразить CSV в RDF напрямую. Это не всегда правильно, так как наверняка найдётся словарь RDF, который уже описывает данную предметную область, и в нём придётся разбираться. В области XML существует аналогичная ситуация с XML Schema. Это вопрос интероперабельности.
Да, концепция Linked Data прекрасна представлением объектов в виде SVO-троек и возможностью рисования запросов по коллекциям таких троек. Однако, на мой скромный взгляд, существует две системных проблемы технологий Linked Data и Semantic Web:
Когда информационная система изначально построена поверх Linked Data и эти форматы являются для неё родными, то всё чудесно. Практика оказывается, увы, несколько иной.