Статьи » Статьи о Linux

Что такое Nepomuk?


Что за чудесный, но таинственный NEPOMUK, упоминаемый при каждом новом выпуске KDE? Нет, не католический святой Иоанн Непомук из чешского города Непомуки, а NEPOMUK (Networked Environment for Personalized, Ontologybased Management of Unified Knowledge). Если говорить коротко, то это средство для работы с метаданными. Но теперь – обо всем по порядку...

В чем идея?

У вас есть разные данные: музыка, видео, тексты и так далее, но компьютер, грубо говоря, не представляет себе, что это за данные. Сам по себе он не отличит одного певца или жанр песни от другого. Файл для компьютера – как непонятный монолит из «Космической одиссеи 2001» – предмет, о котором известно лишь, что он существует. Компьютеру нужны знания, сведения о предмете. Сведения, по которым предмет можно определить тем или иным способом. Эти сведения и называются метаданными.

Приставка «мета» означает тут – «о себе», то есть «данные, сведения о себе». Например, есть какая-то песня. Как узнать, что за группа ее поет и в каком жанре? Достаточно посмотреть метаданные, хранящиеся в теге файла (разумеется, если теги заполнены). В случае с фильмом возникает вопрос, где можно взять метаданные о нем. Надо полагать, что в какой-то сетевой базе или из комментария, назначенного фильму самим пользователем. И вполне логично организовать все это через некое общее средство доступа. Это позволит не «таскать» с каждой программой библиотеки чтения-записи тегов, не лезть вручную в imdb.com за сведениями о фильме. А еще, например, добавлять заметки к любому файлу или каталогу, чтобы потом можно было быстро найти файл по заметке. Не говоря уже о том, что-бы быстро найти файл по содержащемуся в нем слову. Быстро – это значит не проверять при каждом поисковом запросе тексты всех файлов, а выдавать итог поиска сразу, т.е. на основе заранее созданной поисковой базы.

Именно для таких вещей и придумано средство под названием NEPOMUK. Оно имеет два воплощения. Одно – на C++, для среды KDE 4 (http://nepomuk.kde.org), а второе – для платформы Java (http://dev.nepomuk.semanticdesktop.org). Впрочем, внедрение обоих еще не зашло так далеко, как хотели бы разработчики, но об этом – позже.

Использование Nepomuk

Для начала проиллюстрирую на конкретном примере, на что способен NEPOMUK сейчас – в среде KDE. Чтобы включить механизм NEPOMUK, нужно зайти в «Настройка рабочего стола → Дополнительно → Поиск в рабочей среде» (System settings → Advanced → Desktop search) и поставить там галочки напротив пунктов «Включить службу Nepomuk» и «Включить поисковую систему Strigi». Рядом, на вкладке «Дополнительные параметры», можно выбрать каталоги, которые Strigi будет индексировать, то есть составлять на их основе базу данных, извлекая оные из тех метаданных файлов, форматы которых она понимает.

Strigi (http://strigi.sourceforge.net) – это поисковый движок в виде процесса-демона. Он находится в оперативной памяти и сканирует файлы, стараясь «не напрягать» при этом систему. Strigi работает с архивами, пакетами, файлами форматов ODT, PDF, MP3, а также обычными текстовыми файлами. Демон Strigi, «заточенный» под KDE, действует весьма разумно – например, приостанавливает индексацию, если ноутбук работает от батареи или в домашнем каталоге закончилось место. Слежение за изменениями в файловой системе происходит через службу KDE KDirWatch.

После включения NEPOMUK (конечно же, предварительно должны быть установлены соответствующие пакеты) Strigi сразу начнет индексирование файлов, а в Dolphin на панели сведений о файле появятся функции «Добавить комментарий» и «Изменить метки». Эти метки и комментарии попадают в поле зрения NEPOMUK и помогают при поиске. Поисковое поле ввода над панелью сведений служит для обращения к NEPOMUK.

На рисунке красным цветом отмечены и поисковое поле, и функции добавления комментариев и меток. В показанном примере я хочу найти все файлы со словом «нирвана», а Dolphin выдает мне их список.

nepomuk

Я не говорю, что сразу выдает – поиск отнюдь не мгновенный, но гораздо быстрее, чем обычный поиск файлов по содержимому. Вместо строки поиска можно использовать протокол «nepomuksearch» в адресной строке Konqueror или Dolphin. Например, вот так:

nepomuksearch:/нирвана

Есть и другой способ использования NEPOMUK. Поместите на рабочий стол или куда-нибудь еще плазма-виджет Task Management (на момент написания статьи он был совсем новым, так что локализация еще отсутствовала) (см. рис. 2). Нажав на нем кнопку New Task (вторая по счету), создаем новую задачу. Допустим, дадим ей имя «Статья». Теперь можно через окно Tasktop (открывается нажатием на первой, безымянной кнопке виджета) задать связи между задачей и такими вещами, как контакты, файлы, адреса электронной почты и веб-страницы. Правда, с последними я так толком и не разобрался: при попытке связать веб-страницу из Tasktop появляется пустое окно с двумя кнопками («ОК» и «Отмена») – очень познавательно!

nepomuk

Зато в Konqueror, в меню Сервис, есть пункт Associate the current page to a task (связать текущую страницу с задачей) и список созданных вами задач; при этом страница попадает в раздел связей «Файлы». Еще в «Сервисе» вы найдете функцию Annotate – она позволяет добавить к странице какое-нибудь примечание, которое будет «видно» через NEPOMUK.

Кроме того, в меню File, в окне «Сохранить как» появляется кнопка Semantic View, позволяющая уже при сохранении страницы задать связи между нею и задачами. Такое управление связями очень важно при работе над большим проектом, будь то книга или фильм. Как это происходит без NEPOMUK? Человек начинает стаскивать разные файлы в один или несколько тематических каталогов, заводит текстовый файл для ссылок и фактически копирует, размножает одни и те же данные. С NEPOMUK же файлы и прочие виды данных остаются на своих местах, а между ними задаются связи: вручную и автоматически.

В том же Tasktop при добавлении файла возникает окно открытия файла с кнопкой Semantic view, вызывающей вот такое окно (отличное от того, что появляется при сохранении файла) (см. рис. 3). Итак, еще одно окно для поиска средствами NEPOMUK. Не могу сказать, чтобы в имеющейся у меня версии KDE оно было интуитивно понятно. Например, предполагаю, что в поисковом текстовом поле должно быть поле поиска текста через NEPOMUK. Однако такой поиск не работает. На одном из снимков экрана того же окна, но в сети, я увидел еще список выбора кодировки – не знаю, был ли список в ранней версии окна, или появится в будущем.

В настоящее время пользовательский интерфейс к NEPOMUK оставляет желать лучшего. Это касается и стабильности работы, и удобства. Ведь NEPOMUK призван упрощать поиск вместо усложнения, а вот так, с ходу, парой щелчков мыши, с интерфейсом к NEPOMUK разобраться не получится. Предполагаешь одно – не работает или срабатывает иначе, чем следуя логике.

nepomuk

Внедрение и перспективы Nepomuk

Не так все радужно и с внедрением NEPOMUK в программы среды KDE. Я, признаться, очень заинтересовался, прочитав в одном материале про NEPOMUK, что вот как здорово: делаете примечания к тексту в PDF-файле, а потом находите их через NEPOMUK. И начал следить за перепиской между (теперь уже бывшим?) главой проекта Okular и Оливером Хайдбюхелем (Oliver Heidbuchel), приславшим патч для поддержки NEPOMUK. Опуская подробности, диалог в вольном пересказе примерно таков:

– Вот патч для внедрения в Okular виджета работы с NEPOMUK. Скриншот прилагается к коду. Есть некоторые трудности с масштабированием виджета, но Питер (ведущий проекта Dolphin) работает над этим.
– Я не уверен, что нам это действительно нужно... Не вижу, чем это лучше, чем окно «Файл → Свойства». Хорошо, что вы научились посылать патчи, теперь попробуйте убедить нас использовать их.

Чуть позже, диалог уже между разработчиками. Один другого спрашивает: «Ну что, разобрался с этим патчем?» Ответ: «Нет, все собираюсь его покрутить». Еще позже – Оливер снова любопытствует о патче. А ему отвечают, что сейчас заморожены все нововведения (до выпуска KDE 4.4), так что сделайте себе заметку в календаре на февраль, чтобы напомнить нам о патче. Но с выходом KDE 4.4 ничего не изменилось. Теперь разработчики ждут, пока kdelibs для KDE 4.5 появится виджет KMetaDataWidget. И вообще, судя по переписке разработчиков с автором патча, разработчики не хотят ничего добавлять «извне» и тянут время.

Тем временем подобный или этот же патч лежит в недрах репозитория Linux-дистрибутива Mandriva, и его планируют применить в релизе 2010.1. Что тут скажешь? Народ хочет, народ делает, а upstream-разработчики отвечают на конкретные предложения: «Ok, didn't know that i'm a bit behind in all that sematic-y stuff», – ключевая фраза здесь переводится примерно как «Я немного не в курсе всех этих семантических штуковин».

В общем, существует как бы два уровня бытия NEPOMUK: радужные мечты и суровая действительность. В мечтах разработчиков – содержимое виджетов рабочего стола будет меняться в зависимости от текущей «задачи» (термин в рамках NEPOMUK). Переключаете задачу – на рабочем столе появляется свой набор файлов, связанных с задачей, а также контактов и тому подобного. В суровой действительности внедрение NEPOMUK идет с большим скрипом. Взять, к примеру, Amarok. Казалось бы, NEPOMUK/Strigi тоже умеет индексировать музыкальные файлы – причем, как и Amarok, с помощью библиотеки чтения тегов Taglib. И что же? В исходниках Amarok уже есть код, где коллекция ведется через NEPOMUK, а не прежними средствами, однако этот код отключен. Разработчики ждут, когда части NEMOPUK, написанные на Java, будут воплощены в более быстром коде на C++. Сами же разработчики Amarok отмечают, что Java-компоненты NEMOPUK не такие уж медлительные, чтоб нельзя было пользоваться. Но ждут...

Ждут и во многих других проектах, а ведь чем больше и активнее NEPOMUK начнут использовать, тем скорее сам NEPOMUK обретет стабильность и обрастет нужными другим разработчикам возможностями.

Что же мешает? Интерфейс API у NEPOMUK довольно продуманный. Кто бы отказался просто так от удобных функций работы с тегами, комментариями и тому подобным? Тогда что же? «Тормозные» Java-части. О чем именно идет речь? Для представления данных NEPOMUK использует движок Soprano (Qt/C++). Для чтения-записи данных Soprano задействует бэкэнды. И вот для собственно хранения данных RDF (данные описательного вида, «субъект – предикат – объект»; например, «Прыг-скок» – «исполняет» – «Егор Летов») Soprano задействует движок Sesame2, написанный на Java. Это и есть, по мнению некоторых программистов, узкое место NEPOMUK. Существует второй RDF-бэкэнд, Redland, написанный уже на старом добром (а главное – быстром) Си – это Redland (http://librdf.org). Redland тоже используется в NEPOMUK – даже при наличии Sesame2. Наконец, третий бэкэнд – Virtuoso, аналог, альтернатива Sesame2. Virtuoso разрабатывается компанией OpenLink и имеет «открытую» версию (http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main).

И есть еще один минус NEPOMUK – относительная «прожорливость» в плане потребления памяти. С Sesame2 в роли бэкэнда он занимает в оперативной памяти около 130 Мб (с Virtuoso – около 80). Для современного компьютера это не так много, но для старой машины или для нетбука – уже те числа, когда пользователь задумывается, не отключить ли столь «тяжелый» сервис.

Впрочем, NEPOMUK – технология «на вырост», никто сейчас не собирается запускать его на мобильных телефонах, а ко времени широкого применения NEPOMUK его теперешняя «прожорливость» либо будет считаться нормой, либо будут какие-то новые, более скромные бэкэнды.

Петр Семилетов (tea@list.ru)
Электронное приложение «Open Source»
Рейтинг

В этом разделе

Добавить комментарий

Естественный спутник земли ?