Иван Бегтин

Продолжая тему сжатия документов используя форматы OOXML и OpenDocument на сей раз подробнее остановлюсь на OpenDocument и затрону тему преобразования существующих форматов MS Office в формат OpenDocument и сравнение с преобразованием аналогичной выборки в OOXML с помощью b2xtranslator.

Для оценки сжимания документов использовалась выборка из 566 файлов в формате MS Word 2000/XP/2003 (.doc) из архивов Енота Поискуна суммарным объёмом в 70 745 088 байт, а то есть около 70 мегабайт. Эта выборка отличается от выборки из прошлого исследования, так как при анализе результатов преобразования в OOXML с помощью b2xtranslator оказалось что много файлов Excel преобразовались с ошибками (как я и упоминал b2xtraslator всё ещё очень сырой продукт) и для эталонной выборки была взята выборка из документов MS Word.  Впрочем и здесь полагаться на результаты преобразования с помощью b2xtranslator на 100%  нельзя так как он иногда портит файлы (а иногда виснет, но для этого эксперимента файлы где он вис не учитывались).

Для OpenDocument сжатие проводилось в два шага:

1. Преобразование документа в OpenDocument с помощью OpenOffice

2. Дожатие документа различными способами – пережатие контейнера, чистка мусора, сжатие картинок и так далее.

Аналогично для OOXML были два шага:

1. Преобразование документа в OOXML (WordML) с помощью b2xtranslator

2. Дожатие документа пережатием контейнера и сжатием картинок.

Особенность эксперимента в том что картинок то было совсем немного – практически небыло вовсе, отсюда главное что показывал эксперимент – это сжатие и дожатие текстовых структурированных документов.

Первый шаг

При преобразовании документов из .doc в OpenDocument их итоговый объём без пережатия составил 20 511 664 байт или 28,99% от начального объёма.

При преобразовании документов из .doc в OOXML их итоговый объём без пережатия составил 11 266 825 байт или 15,93% от начального объёма

Можно обратить внимание что документы OOXML существенно меньше что, в общем-то, выглядит несколько странно учитывая что данные там одной природы – текстовой. Можно, конечно, предположить что OOXML лучше поддаётся сжатию, но в реальности ситуация более прозаична. О ней я упоминал раньше и опишу далее.

Дожатие OpenDocument

Если в первой части эксперимента оказалось что OOXML создаваемые b2xtranslator меньше чем документы создаваемые при конвертации посредством OpenOffice, то во второй части мы посмотрим насколько они поддаются дожатию.

Для документов OpenDocument к каждому из них применялись следующие способы уменьшения их размера:

1.  Удаление thumbnail и прочего “мусора’ оставляемого OpenOffice’ом

2. Пережатие изображений (если они есть)

3. Пережатие ZIP-контейнера

После всех этих операций итоговый объём документов составил 10 231 845 мегабайт или 14,46% от начального объёма.

Можно обратить внимание что документы OpenDocument после дожатия уменьшились вдвое и это показатель того насколько неэффективно OpenOffice сохраняет документы.

Дожатие OOXML

Для документов OOXML сосздаваемых b2xtranslator применялись те же оптимизационные способы что и в прошлом эксперименте:

1.  Пережатие изображений (если они есть)

2. Пережатие ZIP-контейнера

Необходимость в чистке мусора отсутствовала поскольку b2xtranslator выдаёт максимально “чистый файл”, без ненужной для отображения и работы информации.

Итоговый объём документов после дожатия составил 10 937 971 мегабайт или 15,46% от начального объёма

Резюме

По результатам экспериментов можно сказать что OpenDocument ничуть не хуже чем OOXML пригоден для архивного хранения документов. Разница в  1% в пользу OpenDocument по результатам сравнения дожатых документов не столь существенна чтобы говорить о серьёзном преимуществе, но говорить о том что документы OOXML получаются значительно меньше чем OpenDocument будет некорректно.

В то же время, несмотря на положительные результаты сравнения форматов, основной проблемой использования OpenDocument можно назвать OpenOffice. В частности, значительная разница между недожатыми документами OpenDocument и OOXML состоит в том что OpenOffice всегда закладывает в файлы OpenDocument изображение thumbnail и довольно плохо сжимает ZIP-контейнер. В итоге, преобразование документов для архивного хранения в OpenDocument нужно осуществлять без использования OpenOffice, но для этого всё ещё нет подходящих инструментов или же дожимать  созданные в OpenOffice файлы до приемлимого объёма.

P.S. В последнии дни мой основной блог из-за смены хостинга и обновления до Wordpress 2.8 работал с перебоями, но зеркало на Livejournal должно работать всегда. Найти его можно тут – ivbeg.livejournal.com.

Originally published at Иван Бегтин. You can comment here or there.

В продолжение темы сжатия документов используя новые форматы OOXML и OpenDocument перейду к конкретным цифрам, по возможности, нейтрально по отношению к любому из форматов.

Для начала приведу цифры по преобразованию документов в случае OpenXML – в одном из следующих постов попробую описать ту же процедуру для OpenDocument. Попробую, поскольку создание стенда для OpenDocument сложнее, но возможно.

Для начала как и что проверялось.

Проверялись 4 датасета документов из архива Енота Поискуна:

• 318 документов OpenDocument (.odt) – 14 482 368 байт
• 620 документов OOXML (.docx и .xlsx) – 24 451 860 байт
• 419 документов MS Office 2000/XP/2003 (.doc, .xls) – 58 669 568 байт
• 39 документов MS Powerpoint  2000/XP/2003 (.ppt) – 74 423 296 байт

Датасеты не подбирались специально, был просто общий архив документов, а далее документы разного типа были сгруппированы. Отдельно отмечу что архив документов не синтетический, а такой какими документы встречаются в “дикой природе”, в данном случае размещаются госзаказчиками на сайтах закупок.

Причем с датасетами проверялось следующее:

• для документов OOXML и OpenDocument проверялась пригодность для “дожатия” документов. Техника которую я ранее описывал в заметке практическое сжатие электронных документов.
• для документов MS Office проверялось их сжатие после преобразование в OpenXML с последующим “дожатием”.

Проверка “дожатия” документов

Дожатие документов проводилось по принципу пережатия ZIP контейнера улучшенным deflate алгоритмом (см. статью выше) и пережатием изображений в документах алгоритмами без потери качества.

Для датасета документов OpenDocument документы были дожаты до совокупного объёма в 12 364 803 байт или, иначе, до 85,37% от начального объёма.

Для датасета документов OOXML документы были дожаты до совокупного объёма в 17 113 886 байт или, иначе, до 70% от начального объёма.

Итого можно заметить что документы OOXML сжимаются лучше. Но это не единственное что их отличает, кроме того документы OOXML в среднем меньше чем документы OpenDocument.

Для датасета OpenDocument средний размер документа  равен: 14 482 368 / 318 = 45 562 байт до дожатия и 12 364 803 / 318 =38 883 байт после дожатия.

Для датасета OOXML средний размер документа дожатия равен: 24 451 860 / 620 = 39 438 байт до дожатия и 17 113 886 /620 = 27 603 байт после дожатия.

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

В чем особенность, например, формата OpenDocument и работы OpenOffice?

Если распаковать любой ODT документ и заглянуть в его внутренности то там можно обнаружить:

• папку Thumbnails содержащую файл thumbnail.png размером от 900 байт до 10 000 байт, в среднем же около 5400 байт
• папку Configurations2 содержащую ряд (обычно) пустых поддиректорий и конфигурацию OpenOffice
• файл двоичный файл layout-cache размером от 18 до 881 байта (по тем данным что есть) или, в среднем, 121 байт
• а также перечисление всех этих файлов в файле META-INF/manifest.xml

Обо всей этой информации можно сказать с уверенностью лишь одно – к содержанию документа она отношения не имеет. Это “полезный мусор” и некоторые удобства при работе в виде thumbnail’а, но не более.

Проверять вычистку ODT документов автоматически задача довольно трудоёмкая, поэтому произвольным образом была сделана проверка “дожатия” на примере одного документа размером в 30 836 байт в оригинальном виде и в 30 328 байт в “дожатом виде” (пережат контейнер и картинки). В итоге после удаления Thumbnails, Configurations2, layout-cache и чистки манифеста файла, и последующего сжатия в контейнер размер документа составил 18 007 байт, или 58% от оригинального файла. Что гораздо лучше чем просто сжатие документов OpenDocument и лучше даже чем сжатие OOXML. Итого, за счёт ряда ухищрений и доработки OpenOffice, в том что касается долгосрочного хранения докуменов и небольшого их объёма OpenDocument не уступит OOXML.

Сжатие докуметов MS Office преобразованием в OpenXML

Впрочем задача дожимать документы возникает сравнительно редко, чаще возникает вопрос выигрыша при переводе документов из устаревших форматов в новые. Но инструментов преобразования документов немного – фактически для перевода офисных документов в OpenDocument мало вариантов кроме как воспользоваться API OpenOffice, а для перевода документов в OOXML есть варианты в виде API MS Office и B2XTranslator (http://b2xtranslator.sourceforge.net/) – бесплатный движок на работающий на .NET и Mono.

В данном случае тестирование проводилось именно с помощью B2xtranslator которые более чем другие способы заточен под потоковое преобразование документов.

С его помощью два датасета – датасет документов MS Office (.doc, .xls) и датасет презентаций MS Powerpoint были преобразованы в формат OpenXML, а далее уже имеющимся у меня движком “дожаты” в части ZIP контейнера и изображений.

В итоге получились следующие результаты.

Преобразованием в OpenXML датасет документов MS Office (.doc, .xls) был уменьшен до 16,78% от начального объёма (от 58 669 568 байт до 9 848 436 байт), а то есть в 6 раз.

После дожатия документов их объём составил 9 401 414 байт или 16,02%. Можно обратить внимание что дожатие документов принесло всего около 0,76% выигрыша объёма и связано это с несколькими факторами:

• файлы .doc и .xls из выборки почти не содержали изображений
• b2xtranslator использует более эффективный Deflate алгоритм для создания ZIP файлов и дожатие помогает несильно.

Преобразованием в OpenXML датасет презентаций MS Powerpoint был уменьшен до 84% от начального объёма (от 74 423 296 байт до 62 634 326 байт), а то есть на 15%.

После дожатия документов их объём составил 55 137 124 байт или 74%.

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

При этом, сжатие презентаций может быть существенно улучшено при использовании дожатия с потерями, например, преобразованием векторной графики и внедренных OLE объектов картинок Adobe Photoshop и Corel Draw в растровые изображения.

Неохваченное и нюансы

1. Неохваченным осталось преобразование документов из форматов MS Office в OpenDocument, но для того чтобы его организовать на поток надо соответствующим образом собирать стенд с OpenOffice’ом. Если кто-нибудь хочет это проделать самостоятельно – могу передать все вышеперечисленные датасеты для экспериментов.

2. b2xtranslator всё ещё ОЧЕНЬ сырой продукт. Несмотря на то что разработчики в нём очень оперативно реагируют на каждый отправленный им баг (а я им отправил уже с 5 штук), тем не менее в некоторых случаях он производит нечитаемые OpenXML документы, а в некоторых просто виснет.

3. Преобразование документов, разумеется, фатально с точки зрения эталонности документов, наличия у них ЭЦП и так далее. Преобразованный документ по объёму существенно отличается от оригинала.

Зачем всё это нужно?

Когда файлов сравнительно немного, то их сжатие и преобразование нужно нечасто. Чаще всего уменьшить размер презентации чтобы отправить по почте или же уменьшить размеры документов когда сайт хостится на платном хостинге и дешевле пережать документы за сутки чем докупать лишнее дисковое пространство и каждый месяц за него платить.

В моём случае вопрос упирается в то что документов накопилось уже несколько сотен тысяч и в общей совокупности это более 48 гигабайт.

С одной стороны это немного, но с другой стороны когда для хранения документов используется Amazon S3, это оказывается более чем актуально.

<td style="height: 12.75pt; width: 48pt;" width="64" height="17" align="right">
</td> <td style="height: 12.75pt; width: 48pt;" width="64" height="17" align="right"></td> <td style="height: 12.75pt; width: 48pt;" width="64" height="17" align="right"></td>

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

В блогосфере посвящённой тематике государства и электронного государства в частности появился ещё один интересный блог за авторством Сергея Купцова, заместителя директора НИИ «Восход». Ранее я упоминал про статью с его интервью в журнале Финанс, а сегодня нашёл его блог в ЖЖ.

Помимо того что Сергей пишет про ОГИЦ, который сам по себе является интересной и большой темой, хочу здесь важно и другое.

Фактически, в России сейчас есть большой дефицит блогов, сообществ и иных способов донесения информации с возможностью обратной связи о государственных проектах в области ИТ, информационного и не только, а  некогда активное сообщество aeg_dev уже практически неактивное.  Поэтому появление блогов людей занимающихся в России тематикой e-Gov лично я считаю хорошей новостью.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

По началу я планировал написать то же в виде статьи, но постоянно сталкиваюсь с проблемой – куда же можно направлять такие заметки на публикацию? Пока ограничиваюсь публикацией в своем блоге.

Буквально совсем недавно мне довелось принять участие в семинаре посвященном 8-ФЗ “Об обеспечении доступа к информации о деятельности государственных органов и органов местного самоуправления” и подготавливаемому МинЭкономРазвития постановлению правительства на эту же тему.

Доклады там были более чем интересными, а учитывая что присутствовали непосредственно разработчики  постановления (http://e-centr.ane.ru/), то их разъяснения отдельных его положений были весьма обстоятельными и интересными.   Не скрою что узнал много нового, а предложения по публикации всех документов с ЭЦП были даже радикальнее чем известные мне и используемые способы контроля за доступностью документов.

В принципе, там было многое что можно назвать более чем здравым, например,  лично я впервые узнал что существует не-экспертная методика анализа государственных сайтов, а на основе анкеты с перечнем проверки. Лично я очень надеюсь что она появится в вскоре в онлайне, что, конечно, будет зависеть от МинЭкономРазвития которое и было заказчиком этих работ.

Я же хочу предложить взглянуть на проблему с другой стороны.  Сколь бы ни была маштабной и серьёзной работа по анализу госсайтов и доступности информации, все сайты она не сможет охватить ни в коем случае. Государственных сайтов около десятка тысяч, а может и больше. Из них тех что попадают под 8-ФЗ и грядующее постановление – несколько тысяч. При всём желании МинЭкономРазвития провести анализ всех будет невозможно – невозможно физически, технически и финансово.

Здравый смысл

Более того, и в законе, и в постановлении, очень многое отдано на откуп здравому смыслу. Проблема в том что здравый смысл для гражданина в том чтобы получить информацию в как можно более удобной форме, а для многих чиновников в том чтобы соблюсти закон и только. Причём формальное соблюдение закона с точки зрения чиновника может быть исполнено здравого смысла, даже не с только с точки зрения сокрытия информации, сколько с точки зрения нежелания или невозможности систематизировать и реорганизовавывать собственную работу. Например, для соблюдения многих положений закона и постановления по срокам размещения информации ВСЕМ ведомствам придётся принимать регламенты размещения информации на официальных сайтах и, практически наверняка, внедрять системы документооборота.

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

Социальная и экспертная составляющая

В области госинформации и открытости государства в России есть уже два существенных и важных проекта с сильной обратной связью от пользователей.

Один из них – это блог президента и последующая его трансляция в Livejournal. После того как он появился блог буквально завалили комментариями, причём многие из них, вообще говоря, к деятельности президента отношения не имеют. К примеру, вопрсы экономики и торговли относятся к ведению правительству которое подотчетно премьеру, но вопросы про ЭКЛЗ или пенсии задают президенту потому как задавать их напрямую более некому! Я думаю что примеры реакции президента на отдельные обращения можно пособирать в СМИ – там они есть.

Второй пример – концепция здравоохранения МинЗдравСоцРазвития ( http://www.zdravo2020.ru ) и её продолжающееся открытое обсуждение. На мой взгляд, учитывая число комментариев – 2268 и предложений – 584, проект оказался более чем успешный.

В случае блога президента многие воспринимают его как чуть ли не прямой канал для связи на “самый верх”, а случае концепции здравоохранения – это возможность экспертам значительно упростить собственную работу собирая мнения сообщества.

Но главное что в обоих случаях – это возможность открытого обсуждения. Его отличие от обращений, писем и звонков в ведомства в том что открытость создаёт кумулятивный эффект. Когда комментарии открыты и общедоступны и их число превышает некий порог, то их просто невозможно игнорировать полностью поскольку тема начинает выходить в СМИ и доводится вышестоящими чиновниками до нижестоящих. Это если говорить о выгоде гражданина от такой модели обсуждения.

Вопрос – а в чём выгода чиновника/госучреждения? Главная выгода в исповедовании золотого принципа “Если нельзя бороться с явлением, необходимо его возглавить“. Граждане в любом случпе будут обсуждать, критиковать, осуждать (а где-то и хвалить) госорганы. Осуждение и критика помноженные на закрытость госоргана и отказ от комментирования и обсуждения чего-либо – стремительно возрастают поскольку очень часто раздражает не столько само явление сколько отсутствие реакции или её неадекватность на обсуждение этого явления.

Социальная составляющая для госсайтов

В ситцации когда объёмы наблюдений колосальны, здравый смысл относителен и уже есть примеры успешного использования коллективного знания – эта тема буквально “просится” к социализации.

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

Вопрос в том как поддержать активность граждан и как обеспечить результативность этой обратной связи. Лично я вижу для этого следующие механизмы:

1. Необходимо обеспечить не просто сбор комментариев и предложений от граждан но и периодический их анализ и публикацию принятых мер. Например, в виде ежемесячного отчета с указанием предложения и какие действия по нему были сделаны регулирующим органом – МинЭкономРазвития или же самим органом власти или госучреждением ещё до принятий мер регулятором.

2. Должно быть нечто вроде рейтинга активностей граждан и, возможно, организаций где бы указывалось сколь много предложений пользователь сделал и сколь многие из них были приняты к рассмотрению.

3. Должна быть возможность модерации которая бы включала и группировку комментариев пользователей по группам – “Здравый смысл”, “Удобство использования”, “Доступность информации”, “Соблюдение законодательства” и так далее.

4. Пользователи должны иметь возможность голосовать за чужие предложения и должна быть возможность их просмотра по числу голосов а-ля Digg

5. Необходимо обеспечить размещение на каждом сайте госоргана ссылки, а ещё лучше баннера, на профиль этого сайта в системе сбора предложений.

Оценки и результаты

Внедрив и поставив на рельсы описанный выше подход можно будет говорить об открытости того или иного госсайта принципиально иначе. Кроме экспертных и аналитических метрик, появятся ещё и метрики социальные демонстрирующие:

• суммы положительных и отрицательных оценок сайтам госорганов;
• число предложений и их критичность для каждого сайта и госоргана;
• адекватность восприятия критики госорганами – по числу исправлений и изменений сделанных по результатам предложений;

Альтернативы?

Если честно, то никаких действенных альтернатив кроме вовлечения граждан в процесс анализа госсайтов я не вижу. Экспертная работа по обработке мнений граждан будет огромной и серьёзной, но эффект от открытости будет будет большим чем только экспертная работа.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

К вопросу о создании сайтов за государственный счет, приведу техническое задание администрации Обамы на создание Recovery.gov.

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

RAT Board Solicitation

Ссылка на документ: http://www.scribd.com/doc/16515421/RAT-Board-Solicitation

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

• XML Редактор Serna скоро станет OpenSource впрочем его уже сейчас можно скачать и попробовать для различных задач.
• Появилась бесплатная версия редактора онтологий Top Braid Composer – http://www.topquadrant.com/products/TB_free_download.html . Для тех кто интересуется Semantic Web – это может быть интересным.
• Должен признать что Windows 7 – объективно лучше Висты в разы. С Вистой на борту мой нетбук мог проработать от батареи не более 2-х часов, даже в экономных режимах, с W7 – работает по 4 часа. Плюс значительно шустрее.
• Google Wave – это определённо интересная штука, онлайн коллаборации вообще очень интересная тема, но я лично пока не могу понять её практическую применимость. Но ещё более интересен Wave Protocol и опубликованные спецификации.
• Bing конечно выглядит и ищет лучше чем live.com, но в отличии от Гугла не ищет по новым форматам для офиса – ищем по filetype:docx и видим что результатов нет. Я так думаю что это непорядок. Вообще Гугл в плане индексирования разноформатных данных куда полнее. Он не только docx и xlsx’ы индексирует, но и DBF файлы.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

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

Сейчас же я опишу как увидеть скрытые метаданные без использования специального ПО.

Для начала немного о самих метаданных.

Метаданные можно разделить на два типа: метаданные документов и метаданные связанных объектов.

Метаданные которые также называют свойства документов (document properties) – это набор данных идентифицирующий автора кем был создан документ, его организацию, кем он редактировался последним и так далее. Многие поля добавляют системы документооборота, но чаще присутствуют лишь те что добавляются программами из поставки MS Office.

Метаданные связанных объектов – это те данные которые присутствуют внутри мультимедиа файлов. Например, Adobe Photoshop сохраняет xmpmeta, в создаваемых им TIF и JPG файлах, в JPG файлах фотографий часто не удаляют данные EXIF – в результате можно узнать когда фотография была произведена, плюс много разного о том как каким фотоаппаратом она снималась и тому подобного.

Чаще всего метаданные связанных объектов менее злободневны чем метаданные документов – поскольку неперсонифицированы, но всех задач и ситуаций где они могут понадобится предусмотреть нельзя поэтому упоминаю их всех.

Итак как получить метаданные из документов MS Office.

1. Необходимо открыть документ в MS Office 2007 или выше (например в 2010 Technical Preview) и пересохранить его в один из форматов OpenXML. То есть файл .doc надо сохранить в .docx, файл .xls в .xlsx, файл .ppt в .pptx и так далее.

2. Итоговый файл необходимо переименовать в аналогичный с расширением .zip.

3. Полученный ZIP файл распаковываем с помощью любого любимого ZIP архиватора в отдельную директорию. На Windows платформе я пользуюсь 7-Zip’ом, но тут без особой разницы что использовать.

4. Заглянем в итоговую директорию после распаковки. В зависимости от типа документа, состав папок там будет отличаться. Для файла .pptx будет присутствовать папка ppt,  для .docx папка word, для .xlsx папка xl.  Нам нужно именно в эту папку, заходим туда и ищем папку embeddings.

5. В папке embeddings будут файлы с названиями “oleObjectNN.bin” где NN – это номер объекта. Наличие этих файлов означает что в документе содержались контейнеры с метаданными в виде OLE объектов (в качестве отступления для людей далёких от ИТ.  OLE объекты – это те данные которые вы вставляете через команды “Вставить” или Insert в офисных программах. Таблица, документ или график – это всё OLE объекты). Все файлы .bin необходимо переименовать в .xls. Здесь необходимо оговорится – большинство .bin файлов на самом деле не будут файлами Excel, но для нашей задачи это не имеет значения поскольку все OLE объекты имеют схожую структуру и то как показывать из них метаданные, программы решают не по расширению файла, по фактическому содержимому вне зависимости от того что это за файлы – таблицы Excel, диаграммы Visio или документы Word

5. Теперь когда у нас в папке есть файлы для просмотра для каждого из них мы щелкаем правой кнопкой мыши в Эксплорере, открываем его свойства и смотрим в подробнее.  Во многих случаях Вы там ничего не увидите, поскольку это может быть OLE объект MSGraph.Chart который метаданных не содержит (или мы просто пока не знаем как их извлечь), но в случаях когда были вставлены диаграммы Visio, таблицы Excel и так далее – мы сможем увидеть фактические свойства вложенных документов, узнать кто их автор и так далее.

Нюансы:

1. Всё вышеперечисленное работает только в случае сложных документов, под которые подпадают большинство презентаций со вставленными таблицами, но простые документы содержащие только текст.

2. В случае новых форматов OpenXML ситуация немногим лучше. При вставке одного офисного документа в другой они сохраняются не как бинарные образы OLE объектов, а как файлы OpenXML. Например, после вставки документа Excel, он оказывается в папке embeddings в формате xlsx. Метаданные из него, конечно, никуда не исчезают и при чистке главного контейнера не удаляются.

3. Возможно схожая ситуация с WordPad’ом, хотя он и слишком прост чтобы работать со сложными структурами. Это требует проверки.

4. Можно ли вышеперечисленное повторить в OpenOffice? Очень может быть – правда насколько я знаю OpenOffice проводит преобразования OLE объектов для их переносимости, но опять же всё требует проверки.

Как этого избежать?

1. Анонимизировав себя в  MS Office удалив информацию о себе как об авторе или же заменив её на заведомо нерелевантную, например, “Мустава Рукоплясова” с организацией ООО “Сиреневый кузнечик”. В зависимости от Вашей фантазии и серьёзности читающих документы.

2. Вычищая метаданные из каждого из документов который вкладывается друг в друга. Это означает что нельзя просто вставить Excel файл в презентацию. Надо вначале его заполнить, потом сохранить, удалить из него все метаданные и лишь потом вставлять через Cut & Paste.

3. Заменять объекты на их упрощённые формы. Вместо таблицы Excel, вставить в презентацию просто таблицу, вместо диаграммы Visio – её изображение и так далее.

P.S.

И, заодно, для тех кто интересуются – свою деятельность по извлечению и анализу данных я переношу сейчас в DPLabs (http://www.dplabs.ru) где эта и другие мои заметки будут оформлены в виде статей.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

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

Касательно же темы “опечаток” приведу ссылки на последние публикации по этой теме:

• Пресс релиз ФАС - ФАС России: использование латинских букв в русских наименованиях при размещении информации о заказе незаконно
• Коммерсант – В контракты вкрались лукавые буквы
• Slon.ru – ФАС преподала урок русского языка плюс мои комментарии

Я лишь надеюсь что ФАС не просто займутся проверками, но  законодательно закрепят требования к раскрытию информации о госзакупках со всеми подробностями, нюансами и возможностью общественного контроля.

Originally published at Иван Бегтин. You can comment here or there.

Мне в последнее время задают много вопросов для чего OpenGovData.ru был создан и, если ответить вкратце, то как основа для будущего data.gov.ru которого, пока ещё, не существует, но как я надеюсь рано или поздно он появится.

Соответственно, принципы именно этого проекта в том все данные представляются открыто, бесплатно и машиночитаемо. Подробнее можно прочитать в принципы открытия данных государством .

При этом сам проект OpenGovData прибыли или выгоды точно не может принести, его задача в другом - предоставить данные для построения социальных и коммерческих машапов, интернет сервисов которые бы в итоге предоставляли аналитику по этим даных, показывали бы их в привязке к ГИС (Google Maps или Яндекс.Карты) и так далее.

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

Изначально я планировал что к концу мая появится часть системы где были бы видны уже подготовленные данные, сейчас эти сроки приходится сдвинуть на конец июня/июль, я не ожидал что мои посты по госзакупкам вызовут такой резонанс так что много времени ушло только на дачву комментариев по теме. Но точно могу сказать что данные обязательно появятся.

В дальнейшем сейчас одной из ключевых задач я вижу конкретизацию требований к раскрываемой информации и детализации принципов раскрытия.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

В последнии дни несколько раз сталкивался с различными, в том числе в новых форматах файлами. К тому же была потребность в преобразовании нескольких сотен документов и презентаций  из .doc, .ppt в OpenDocument и OOXML.

Не в последнюю очередь чтобы оценить экономию места при полном преобразовании своих архивов для долгосрочного хранения.

Далее некоторые наблюдения:

• файлов в формате XPS (XML Paper Specification) в Рунете всё ещё единицы. Впрочем подозреваю что скоро их станет много, учитывая что в Windows 7 и Vista есть XPS принтер. Под Linux’ом его поддерживает Okular и GhostXPS . В то же время хранить в XPS оказывается выгодно только если нужен формат для замены PDF и документ нужен только для просмотра. Причём с некоторых точек зрения XPS даже удобнее PDF поскольку работать с ZIP структурой проще чем разбирать PDF файлы. Интересно где Adobe с их PDFXML форматом?
• то какой из форматов оптимальнее для хранения документов - это более чем дискуссионный вопрос. Например для презентаций получается что уровень сжатия лучше у каждого из форматов - ODT и PPTX через раз. А вот для документов и файлов таблиц состоящих только из текстов, обычно, OOXML сжимает данные лучше, что особенно заметно на небольших документах до 100 килобайт. Но! всё сильно зависит от того как документы создавать и в какой программе.
• существенная специфика OOXML в том что XML файлы созданные в нём поддаются гораздо лучшем сжатию чем для OpenDocument.
• как ни странно, WordPad для Windows 7 генерирует более малые ODT файлы чем OpenDocument. Но секрет раскрывается достаточно просто - OpenOffice по умолчанию в каждый ODT файлы закладывает thumbnail (картинку для предпросмотра в PNG). Как отключить это я так и не нашёл.
• на самом деле всё гораздо сложнее чем разница в форматах. Что OpenOffice, что MS Office разных версий сохраняют файлы в данных форматах в разной степени “недожатости” и по структуре и по способу использования форматов. Например, открыть документ в MS Office, сохранить его в DOCX, потом открыть его в WordPad и снова сохранить в DOCX, то, заглянув внутрь структуры, можно убедится что файлы XML файлы стилей и содержимого существенно отличаются при незаметности для конечного пользователя.
• ни старый офис (MS Office 2003), ни новый (MS Office 2007) и плагины к ним не удаляют всех метаданных, некоторые из них, я полагаю они и не могут удалить. Например, xmpmeta в файлах подготовленных в фотошопе. Персональной информации там немного, но некоторую информацию можно извлечь, например, даты создания картинок. Впрочем, если покопаться глубже, то можно найти и более интересную информацию, но автоматически, увы, это сделать сложно. Подробнее как-нибудь в другой раз.

Как резюме моё личное мнение, для долгосрочного хранения офисных документов в случае кейса - “храним долго, используем редко, экономим место” нужно использовать не OpenDocument и не OOXML, а делать свой формат.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Анализ данных

• Picalo - инструмент выявления аномалий и анализа данных, с открытым кодом на Python. Главный плюс - возможность использовать его Python API. Только на английском.
• Deductor - один из немногих отечественных OLAP инструментов. Коммерческий. Стоимость студии до 29 000 рублей
• Tableau - феноменальный продукт по возможностям и стоимости. Один из лучших в части визуализации и демонстрации на презентациях, но цена в $5000 кусается.
• Weka 3 - применяется, в основном, для научных и исследовательских задач по классификации
• Rapidminer - настольный продукт для data mining, есть коммерческий, есть open source.
• LispMiner - академический продукт для анализа данных
• R Project - язык программирования R. Набирающий популярность на западе и интегрируемый с массой других продуктов и языков программирования.
• Omniscope - коммерческий продукт похожий на Tableau. Также позволяет удобную визуализацию
• QLickView - ещё один коммерческий продукт по анализу и визуализации
• Tibco Sportfire - ещё один аналитический продукт, на сей раз от Tibco. По цене чуть меньше Tableau - около $4700.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

В журнале Финанс вышла интересная статья Сергея Купцова Политика против технологий где коротко и очень точно изложены проблемы в появлении государственных услуг на ОГИЦ (Общероссийский Государственный Информационный Центр) и услуг вообще.

Как и во многих случаях развития e-Gov в России, все основные проблемы организационные и проистекают от того что государственных ведомства  с трудом договариваются между собой.

Как сейчас Минкомсвязи и тем более Росинформтехнологии, могут влиять на ФНС, МВД, ФТС или МЭР? Связисты в состоянии лишь предложить сервис.
В постановлении № 931 прописано, что министерства и ведомства обязаны подключаться к ОГИЦ. Но не подключаются. И это вопрос не технологический, а политический.

Так оно и есть,  что ФАИТ, что Минсвязи не могут приказать и заставить другим ведомствам подключаться в ОГИЦ. Так как те находятся в подчинении у правительства (а силовые органы власти у Президента) и могут регулироваться только постановлениями и указами, но и только.

Пассивно себя ведут те, у кого все в порядке, есть хороший информационно-вычислительный центр, и они сами предоставляют услуги. Например, Росстат владеет собственной информацией и зарабатывает на ней деньги. Им невыгодно выходить во внешнюю среду. Хотя Росстат должен пуб ликовать эти данные на портале.

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

Спасибо Екатерине Аксеновой - gov-gov.ru за ссылку.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Поскольку тема всё ещё актуальна и интересна, ряд вопросов раскрою подробнее, заодно напишу про то, что не попало непосредственно в СМИ.

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

Доказать умысел подобных действий крайне сложно и решить задачу находимости информации можно лишь за счёт автоматизированной модерации.

2. В файлах что я привёл не 1000 закупок, а поменьше поскольку там указывается по отдельному слову, а не по отдельной закупке. Впрочем подобных закупок много и я сделал выборку за короткий промежуток времени - несколько последних месяцев и только по zakupki.gov.ru

3. Автоматическая проверка орфорграфии и исправление - это не решение. Не решение по нескольким причинам. Во первых прежде чем что-либо автоматизировать необходимо убедится что слова будут исправляться именно корректно, а не заменятся одни похожие на другие. Во вторых сложные опечатки вроде “Закупка хлебной руки” вместо “Закупка хлебной муки” выявляться таким образом не будет. В третьих есть случаи когда слова могут состоять из смешения русских и английских букв, а также цифр. Чаще всего это названия деталей и некоторых станков/машин.

Поэтому здесь вопрос не автоматизма, а автоматизации. Необходим человек проводящий модерацию закупки до её опубликования и подтверждающий что вся информация введена верно и допускающий или не допускающий её к публикации. Подчеркну - модератор никаких изменений внести не имеет право, только отклонить или разрешить публикацию.

Также необходимы действия по автоматизированной проверки корректности закупки при публикации представителем заказчика.

При этом последовательность действий должна быть следующей:

- представитель заказчика подготавливает закупку и направляет на публикацию

- система автоматически проверяет закупку на предмет наиболее очевидных ошибок и на дополнительном экране запрашивает уточнение и исправление информации.

- после исправления информации представитель заказчика направляет закупку на публикацию

- модератор по уведомлению или из списка открывает закупку и проверяет корректность её заполнения

- в случае некорректного заполнения он отклоняет её от публикации со своими комментариями которые не публикуются, а идут только заказчику.

- в случае корректного хаполнения модератор разрешает публикацию.

- ФИО, номер или код модератора, а также дата модерации присутствуют в отдельном блоке описания закупки и доступны в публичном описании закупки.

При этом многие действия могут быть существенно автоматизированы, например, в виде кнопки “Проверить” на рабочем месте модератора, выполняющей проверки и подствечивающей ошибки автоматически. Подчеркну ещё раз - полный автомат тут не получится.

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

4. В Газете.Ру (http://www.gazeta.ru/business/2009/06/06/3207676.shtml) на тему подобных искажений высказался Михаил Евраев, начальник управления ФАС России.  Так вот такие явления надо не выявлять, а не допускать включая контроль в процесс размещения государственного заказа. Это не сложно изменить программное обеспечение официального сайта (сайтов) таким образом чтобы о подобных закупках автоматически уведомлялись представители ФАС. И в принципе не так уж сложно встроить обеспечения контроля в процесс - достаточно, на начальном этапе, посадить несколько человек которые бы проверяли ВСЕ несостоявшиеся закупки (с одним участником выбранным по итогам) начиная с определённой цены, например, 20 миллионов и далее тщательно их проверять.

5. Следующей проблемой после сокрытия информации, идёт проблема неудобства её предоставления. Выкладка конкурсной документации в виде сканов, PDF файлов закрытых для копирования, в новых форматах вроде XPS (формат файлов направляемых на печать в Vista и Windows 7) и так далее.

6. Электронная цифровая подпись и ведение публичных журналов изменений позволяют отследить кто-же публикует информацию и в каком виде. В качестве примера могу привести сайт tender.mos.ru и ещё десяток региональных сайтов закупок которые обеспечивают данную возможность. В принципе, через официальные сайты предоставляется информация о миллиардах рублей и недоступность информации может приводить к миллионам убытков. Да, да, конечно “деньги то государственные”, но только их маштаб требует принципиально иных процедур учета всех операций. Фактически программное решение должно изначально строиться на изначельном недоверии к любому имеющему к ней доступ - будь то представитель заказчика, представитель оператора,  разработка продукта или регулирующего органа.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

• OpenLibrary.org - экспорт в JSON всех авторов и изданий.
• SocData.com - коллекция датасетов собираемых сообществом. Социальные данные
• ILSP Greek Corpus - корпус греческого языка
• European Climate Assesment - датасеты с данными по климату в Европе с ежедневным пополнением
• SuperComputer Event Logs - датасеты логов событий на суперкомпьюетерах SNL за 2004 и 2005 годы

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Может быть интересно для тех кто исследует социальные сети и вообще интересуется большими массивами данных - проект StackOverflow выложил в общий доступ датасет на 200 мегабайт сжатых 7Zip с коллекцией вопросов, участников, комментариев и результатов оценки.

Основная идея: Мы получаем данные от сообщества, мы возвращаем данные сообществу.

Для справки. StackOverflow - это одно из Q&A сообществ нацеленное на разработчиков ПО.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Вокруг темы возник существенный ажиотаж у меня только сегодня уже несколько изданий запросили комментарии.

Должен сказать что подобного внимания к теме я не ожидал, тем более что это был просто самый заметный пример - причём изначально найденный не мной, а  я лично увидел его на одном из форумов посвящённым госзакупкам. Его я привёл только для наглядности, самое же интересное можете посмотреть аттачем к этому посту.

Здесь приведены закупки где выявлены чередования русских и латинских букв в словах. Алгоритм не идеально точен, поэтому иногда попадаются слова где английские буквы чередуются со спецсимволами, но их не так уж много.

Структура файлов:
- слово
- название закупки
- ссылка на zakupki.gov.ru

В ZIP архиве HTML файл где русские и английские буквы подсвечены - русские зеленым, английские красным.
ruslat_pur.zip
ruslat_pur.xls

Я думаю что вопрос повышения грамотности госслужащих стоит как нельзя остро.
А многие кто задавал мне вопросы сколько же таких закупок - могут найти ответ на этот вопрос здесь.

UPDATE: Продолжение с комментариями тут

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Для тех кому тема интересна, на Slon.ru вышла заметка с моими комментариями - http://slon.ru/articles/46692/

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Собираюсь на iCamp.  В этом году уже буду точно и не один

И вот неожиданно узнал что их два:

• http://icamp2009.ru - на теплоходе
• http://2009.icamp.ru - в Этномире

Вопрос: кто куда собирается и какой порекомендуете?

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.

Помните я пару лет назад писал вредные советы при создании государственных сайтов?

Так вот было бы совсем смешно, не будь они правдой.

Теперь туда можно смело  добавить ещё один - искажение текста для его ненаходимости.

Пример: на право заключения государственного k0нтраkтa нa пр0д0лжeниe рeк0нcтрукции 0бъekтa “Рek0нcтрукция пр0изв0дствa тубeркулин0в для диaгн0cтиkи бakтeри0з0в у жив0тных”

Это вполне себе официальная закупка по адресу http://www.zakupki.gov.ru/Tender/ViewPurchase.aspx?PurchaseId=302551

Русские буквы “к” заменены на английскую”k” и русские буквы “о” заменены на цифру ноль “0″.

Это к вопросу о различных “нюансах” проведения торгов, о которых ни законодатели, ни регулирующие органы и не задумываются. А в самом деле, как это решать? Принудительной проверкой орфографией? Обязательной модерацией закупок до публикации? Иначе?

И ведь это ещё самый заметный пример, есть масса случаев где просто опечатки или же русские буквы могут быть заменены на латинские схожей формы - o, a, e, x, c.

UPDATE: А здесь можно прочитать продолжение и увидеть список подобных заказов.

Кросспост из Иван Бегтин. Комментарии можно оставлять здесь или здесь.