Метаданные: как сделать локальный поиск наиболее эффективным

Хотя термин intellectual property имеет вполне конкретное значение, в настоящей статье речь пойдет о вещах менее отвлеченных и более приземленных, а именно о свойствах файлов, хранящихся на наших компьютерах. Иногда их называют атрибутами или метаданными – суть от этого не меняется.

Для начала давайте разберемся, почему предлагаемая вниманию читателя тема вообще представляет интерес. Метаданные могут содержать довольно важные сведения – вроде автора, названия, ключевых слов и т. д. На первый взгляд, они дублируют часть информации, которая просто обязана присутствовать в любом документе, однако, несомненно, для них можно найти и лучшее применение. Например, спустя год-другой пометка «Мой доклад на такой-то конференции» может оказаться не менее ценной, чем заголовок «О неотложных мерах по…». То же самое, и даже в еще большей степени, касается ключевых слов – достаточно вспомнить Интернет, где они давно являются неотъемлемой характеристикой Web-страниц.

Не меньше известны метаданные и в локальной среде. Именно они отображаются в Windows на вкладке Summary окна свойств практически любого файла, и, как нетрудно заметить, чаще всего пусты или заполнены бесполезными сведениями. При этом они вполне могли бы стать хорошим подспорьем при упорядочении и поиске информации, поскольку индексировались (для наиболее популярных форматов) еще Indexing Service, стандартным компонентом Windows NT/2000/XP/2003. Впрочем, данная служба, как мы неоднократно отмечали, по разным причинам не снискала широкой популярности. Гораздо удобнее поисковые инструменты, встроенные в приложения Microsoft Office последних версий, но они, к сожалению, не являются универсальными и тоже имеют ряд недостатков.

Именно в Windows Vista будет по-настоящему раскрыт потенциал унифицированных свойств (метаданных) документов

Сегодня, однако, мы наблюдаем возрождение идей и инструментов локального поиска, но, несмотря на обилие соответствующих программных средств (преимущественно бесплатных), обратимся прежде всего к Windows Vista. В ней вместо Indexing Service появится модернизированный поисковый механизм, также основанный на принципах индексирования и подключения внешних фильтров, но более тесно интегрированный с ОС и снабженный рядом дополнительных полезных надстроек. Среди последних в первую очередь интересны «виртуальные» папки – по сути, сохраненные поисковые запросы. Тут-то и раскрывается вся ценность метаданных – благодаря им можно, совершенно не упорядочивая хранилище документов (и других файлов) на физическом уровне, организовать множество его логических представлений (по датам, авторам, содержанию и т. д.) и в дальнейшем пользоваться ими наравне с обычными файловыми структурами.

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

Один из самых очевидных подходов заключается в использовании приложений, с помощью которых и создаются документы. Естественно, для этого они должны поддерживать OLE (или, быть может, какие-то другие технологии автоматизации) – к примеру, это полностью относится к Microsoft Office (см. листинг 1). Преимущества бесспорны: доступ абсолютно ко всем функциям, надлежащая документированность интерфейсов, множество примеров и пр. Однако есть и недостатки – скажем, если данные хранятся на сервере, присутствие там пользовательских приложений неуместно, тем более что их необходимо иметь для всех актуальных форматов. Кроме того, в процессе применения таких мощных и разноплановых приложений, как Word или Excel, нередко возникают нюансы и проблемы, разобраться с которыми довольно сложно.

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

На самом деле концепция метаданных тесно связана с понятием так называемых составных OLE-документов и в определенной мере стандартизирована. В большинстве случаев с ними можно работать программно, достаточно лишь обладать соответствующими знаниями и навыками либо воспользоваться чьими-то готовыми наработками. Сама Microsoft для этого предлагает специальную библиотеку Dsofile, хоть и предназначенную главным образом для демонстрационных целей и имеющую ряд ограничений, однако вполне пригодную во многих ситуациях. При этом ее применение не вызывает затруднений (см. листинг 2) и даже не требует глубокого изучения объектной модели.

Однако следует иметь в виду, что в Dsofile полноценно поддерживаются только документы Microsoft Office, что видно даже по списку доступных свойств (впрочем, в нем присутствуют Author, Title, Keywords, Company и другие, актуальные для задач поиска и обычно содержащиеся в любых составных документах). Для всех остальных форматов предполагается, что метаданные хранятся в так называемых альтернативных потоках – даже если это очевидно не так, как, например, в случае PDF или JPG. Еще хуже, что определенные ограничения имеются даже для самых обычных файлов, вроде TXT и подобных – запись их свойств возможна только в том случае, если поток (его имя практически совпадает с SummaryInformation, но начинается со специального символа и потому оказывается не по зубам большинству стандартных утилит) уже существует.

Таким образом, для работы с простыми файлами нужно придумывать какой-то обходной путь либо усовершенствованный инструмент. Как ни парадоксально, их не так уж и много, а наиболее адекватный нашим задачам – альтернативная командная оболочка 4NT – является коммерческим продуктом и довольно дорог. Зато с его помощью указанная проблема решается всего одной командой:

@Summary[filename.ext, author,MyName].

Поисковые инструменты приложений Microsoft Office способны исследовать стандарные свойства документов

Что касается составных документов не от Microsoft, то для них придется поискать аналоги Dsofile. Они, кстати, не всегда выполнены в виде OLE-серверов, – например, с PDF можно работать посредством утилиты командной строки (ничто не мешает использовать ее в сценариях и командных файлах) PDFTK. Основная конструкция выглядит так:

pdftk 1.pdf update_info new_meta.txt output 2.pdf,

где update_info и output – названия операций, а файл new_meta.txt содержит описание свойств документа следующего вида:

InfoKey: Author

InfoValue: MyName.

Осталось, пожалуй, лишь обратить внимание читателей на то, что в ряде случаев встречаются различные реализации метаданных для одних и тех же типов файлов, причем даже давным-давно считающихся стандартными. Хорошим примером тому является JPEG, в котором, кроме стандартной EXIF-информации, также поддерживаются дополнительные свойства вроде описания, копирайта, ключевых слов и т. д. Общепринятая спецификация для этих метаданных была предложена IPTC (International Press Telecommunications Council), однако Microsoft в Windows XP и другом своем ПО использует собственную – видимо, ради унификации свойств различных документов. Естественно, это вносит некоторую путаницу, поэтому желательно с самого начала определиться, с каким типом информации вы собираетесь работать. Скажем, если речь идет о Windows Vista или поисковых системах Microsoft, то, безусловно, стоит обратиться к оригинальным инструментам. С другой стороны, IPTC поддерживается большим количеством ПО, и достаточно воспользоваться самой простой и бесплатной COM-реализацией (например, www.jsware.net/jsware/scripts.php3#jsiptc).

Set objWord = CreateObject(«Word.Application»)

Set objDoc = objWord.Documents.Open(«filename.doc»)

objDoc.BuiltInDocumentProperties(«Author») = «MyName»

objDoc.BuiltInDocumentProperties(«Keywords») = «word1 word2»

objDoc.Save

objWord.Quit

Set objFile = CreateObject(«DSOFile.OleDocumentProperties»)

objFile.Open(«filename.doc»)

objFile.SummaryProperties.Author = «MyName»

objFile.SummaryProperties.Keywords = «word1 word2»

objFile.Save