Иван Бегтин

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

Так получилось что в течении буквально нескольких дней я практически одно за другим, вначале прочитал статью Леонида Костюкова «Нормальная жизнь» и посмотрел экранизацию романа Германа Гессе «Степной Волк». Причём ранее этот роман я как-то всё упускал из внимания, слышал много, а вот прочитать или посмотреть спектакль или кино не удавалось.

А тут одно наложилось на другое, причём диаметрально противоположное. «Степной волк» – о стремлении подняться над обыденностью и мещанством, а «Нормальная жизнь» – это взгляд на окружающую действительность как раз с точки зрения нормальности обыденной и повседневной жизни.

Скажу честно меня это натолкнуло на довольно серьёзные размышления, поскольку по всему что я наблюдаю последние лет 5 не покидает чувство что нормальной жизни то и нет или очень мало.

По общественным критериям у меня и самого жизнь не вполне обыденна:

1. Я провожу за компьютером до 6 часов в сутки.

2. Не смотрю телевизор уже 2 года.

3. Не читаю газет кроме онлайновых.

4. Пишу про всяческие государственные темы у себя в блоге.

5. Давно уже не обладаю привязанностью к вещам за пределами создания необходимого рабочего комфорта.

Всяческие хобби, отдых друзья – это отдельно.

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

А что для Вас нормальная жизнь?

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

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

В то же время это «живые данные» имеют массу специфики, при их сборе, подготовке, обработке и так далее. Приведу ряд соображений и размышлений для примера:

1. Для простых данных в виде плоских таблиц можно использовать различные SQL-базы с внешней обвязкой метаданными.  Но, случаи когда используются только простые таблицы редки, чаще всего данные обладают иерархией и вложенностью. Эту иерархию и вложенность можно привести к SQL сильно увеличив число таблиц, или же использовать NoSQL подход брать за основу CouchDb, MongoDb или их аналоги или семантические triple-store.

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

3. На самом деле обработка большого объёма разноформатной информации это ещё и до сих пор не решённая исследовательская задача. Большинство же практических систем, например, поисковых, либо нормализуют источники информации и получаемые данные, либо резко ограничивают их число и связывают информацию в этих источниках вручную. Например, поисковики вроде Google или Yahoo нормализуют весь веб к веб-страницам, а в WolfRam Alpha используется большое число массивов данных вручную нормализованных, в основном, по формам выдачи результатов. Задачу же автоматической или автоматизированной интеграции тысяч и десятков тысяч источников информации решить было бы очень интересно, но лично я понимаю всю её объективную сложность.

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

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

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

• ShoeBoxed – небольшой стартап с хитрым ноу-хау. Вы отправляете им в конверте свои счета и визитки, а они с помощью специальных сканеров и алгоритмов все это оцифровывают, распознают и предоставляют Вам через веб интерфейс. Задумка более чем интересная, я как раз не так давно задумывался об автоматизации распознавания кассовых чеков
• URLClassifier – сервис тематической классификации веб страниц. Явно использует словари и классификация у него двухуровневая, но! сама идея правильная и весьма полезная. Предоставляют API
• Feedity – ещё один сервис по преобразованию HTML в RSS, на сей раз полуавтомат. Анализирует страницу и предлагает варианты. Скиур (моё творение) мне нравится больше, но «пусть растут 100 цветов», пригодятся все.
• ColourLovers – огромная база цветов, паттернов и палитр. Проектов таких много, но эти дают ещё и API.

Идеи

• Если в поездах метро между стеклами вагонов поместить полупрозрачные экраны на которые можно было бы во время движения поездов  транслировать рекламу, то рекламодатели получили бы аудиторию в несколько миллионов человек ежемесячно.
• Классификация по ключевым словам в названиях, моделях телефонов и их стоимости помноженное на накопленные статистические данные по демографии может позволить, с некоторой вероятностью, определять средний возраст людей присутствующих на заданной территории используя BlueTooth. Зачем? Например, рекламный таргетинг
• Чтобы обеспечить контроль хоть как-то близкий к тотальному, то далеко ходить не надо – достаточно МВД потребовать от всех охранных агенств и вневедомственной охраны ведения электронных журналов учета посетителей. Так чтобы номера паспортов и ФИО вносились не в журнал, а в базы данных синхронизировались с центральной. Разумеется этого никогда не будет.
• Карты покрытия сотовыми операторами «наоборот». На них показывается где в городе (или местности) есть места где Вам гарантированно не смогут дозвониться. Для тех кто увлекается кратковременным дауншифтингом сервис будет незаменимым.

В последнии дни несколько раз сталкивался с различными, в том числе в новых форматах файлами. К тому же была потребность в преобразовании нескольких сотен документов и презентаций  из .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, а делать свой формат.

Ранее я упоминал про недавнее исследование из Яндекса – Автоматическая классификация веб сайтов (в PDF) и что лично я несогласен с подходом использующим классификацию по ключевым словам.  Главное – это то что у Яндекса как и других поисковых систем, на самом деле, куда больше информации о сайтах, пользователях и их взаимодействии чем просто страницы и ключевые слова. Этой информации столь много – что принцип «больше данных, проще алгоритмы» должен подходить здесь на 100% и я опишу несколько вариантов классификации сайтов построенных именно на таких данных.

1. Классификация по аудитории

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

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

Таким образом как раз у Яндекса есть возможность определения тематики сайта по аудитории.

Ограничения этого подхода в том что для отслеживания аудитории необходим свой счетчик (или рекламный блок) на анализируемом сайте.

2. Классификация по карте объектов сайта

Карта объектов – это совокупность смысловых и структурных объектов (обладающих собственным значением или связанными со смысловыми понятиями элементов сайта).

Приведу несколько примеров элементов объектной разметки:

- новостная лента как частный случай списка включающего даты, который является частным случаем списка в принципе

- табличные данные

- навигационное меню сайта

- счетчики

- рекламные блоки

плюс множество других объектов.

Каждый объект обладает собственными свойствами, отношениями к другим объектам и, в некоторых случаях, веб ресурсам.

При классификации сайта, из карты объектов извлекаются необходимые для классификации характеристики и уже на их основе работает алгоритм классификации.

На основе упрощённой версии именно такого подхода работает мой алгоритм определения коммерциализованности сайта.

Лично я считаю именно этот подход наиболее переспективным.

3. Классификация по входящим и исходящим ссылкам

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

4. Классификация по интересам владельцев сайтов

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

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

5. Классификация по социальным закладкам

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

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

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

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

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

OpenGovData.ru продолжит наполняться данными, как я и обещал до конца мая будет обновление разделов.

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

Просуммирую собственные размышления:

• большая часть инструментов работы с большими массивами информации написаны на Java. То же самое можно сказать про инструменты работы с semantic web. Может быть это именно мне попадались подобные, но думаю что действительно пока инструментов в Java больше.
• Язык R (R Language) впечатляет удобством и всё более идёи в массы, например, лично мне нравится возможность вызова его через код Python посредством rPy (http://rpy.sourceforge.net/).  Один лишь недостаток – язык под GPL и использовать его в коммерческих продуктах не получится. Но коммерческие продукты – это не всё и я уже знаю несколько примеров (вне России) где R используют внутри компаний или же как аутсорсинг услуг.
• большая часть задач по визуализации решается теми или иными плагинами для Excel, а также непосредственно возможностями Excel’я особенно версии 2007. Единственной более менее серьёзной заменой ему я знаю Tableau цена которого нереально выше – минимум $999 за персональную лицензию.
• весьма примечателен выбор графика в JuiceAnalytics там можно подобрать график под свои нужды и сразу скачать его под Excel или Powerpoint.
• а вот в для веб пока ничего более простого и удобного чем Amcharts (http://www.amcharts.com/) мне найти не удалось. При очень небольшой цене – весьма удобный и гибкий инструмент. Впрочем есть и бесплатные варианты вроде OpenFlashChart, бесплатной версии FusionCharts и Yahoo ASTRA Flash Components.
• есть целый ряд тем по обработке данных отодвинутых от наиболее продвинутых инструментов. Например, есть пробел с извлечением метаданных из различного рода файлов – фактически, за исключением самых популярных форматов,  в остальном под каждый формат свои библиотеки и инструменты зачастую только с закрытым исходным кодом или даже полное отсутствие описания формата. Правда относительно форматов файлов и их пакетной обработки надо отметить что у разных форматов разная судьба – если изображения, видео, музыку и различного рода текстовые файлы часто подвергают пакетной обработке, то для остального рода файлов знание их форматов ограничено узкой областью использующих их продуктов, антивирусов и разного рода security and forensic Software. Определённо можно свести эти темы воедино, вопрос в том лишь дорос ли рынок до такого объединения и будет ли это востребованно именно сейчас.
• Hadoop + HBase или альтернативы в виде Hypertable позволяют выходить на уровень BigData и работать с данными уже на принципиально ином уровне.  В англоязычном Интернете уже развиваются курсы по Hadoop, Hadoop Boot Camp и масса энтузиастов в России всё упирается в небольшие объёмы общедоступных массивов данных и ограниченностью предприятий/организаций заинтересованных в работе с большими объёмами.
• тема которая не относится к работе с данными напрямую, но важна с точки зрения их потребления, предоставления конечным пользователям – это формы предоставления информации. Её можно начинать от динамических контролов в веб и на десктопе которые бы подстараивались под вкладываемые в них данные в зависимости от объёма, продолжать автоматизированным и автоматическим подбором типов графиков под анализируемые данные и развивать к другим не менее интересным направлениям. Всё это в совокупности некий «мостик» между работой с данными, в том числе и BigData, и юзабилити. И пока я не вижу как иначе эти темы связать.
• продолжаю присматриваться к GreenPlum, пока на уровне понимания кейсов для чего может пригодится.
• то что крупные игроки вроде Microsoft, Google, Amazon начинают не просто работать с большими объёмами данных, но и предоставлять общедоступные данные всем желающим – это очень хороший сигнал. Хотя и каждый из них играет в свою игру, тем не менее появление лоббистов в этой области даёт шанс что они начнут взаимодействовать непосредственно с государственными органами для раскрытия информации. К сожалению, не российскими госудраственными органами.
• у меня накопилось порядка 200 гигабайт различных датасетов, при том что приходится себя ограничивать в скачке некоторых чтобы не забивать канал и потому как надо ещё и эти «переварить».

Из размышлений над тем что делать с накопившимися у меня наработками – медленно, но верно выпал Социоранк - сервис тематического рейтингования пользователей в соц. сетях. На данный момент пользователей ЖЖ. 

Как я ни рассматривал куда его можно пристроить к другим своим проектам – получается что он выпадает из всех тем которыми я сейчас занимаюсь и развивать его будет означать жертвовать чем-либо ещё.

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

Что в проект входит:

• домен sociorank.ru;
• веб интерфейс и база рассчитанных рейтингов;
• подсистема/модуль сбора и обработки информации о рейтингах, расчётов рейтингов, расчёты кластеров сообществ и влиятия сообществ друг на друга;
• если нужны – соображения по дальнейшему развитию проекта.

Если есть интерес – пишите на ibegtin@gmail.com – сколько готовы за него отдать и чего собираетесь с ним делать.

Соответственно, сам я от темы рейтингования в социальных сетях отдаляюсь ибо есть более интересные проекты.

UPD: Некоторые подробности

Проект полностью написан на Django/MySQL и состоит из двух модулей/подсистем. 

Отдельно идёт подсистема веб-сайта которая отдаёт веб страницы и предоставляет API.

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

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

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

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

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

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

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

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

Например,  полгода назад, ища сайты по госзакупкам и объективно оценивая длительность поиска я с помощью небольшого автоматического скрипта искал такие сайты автоматически. Сейчас я знаю что большая часть работы которая шла в Еноте Поискуне по разбору веб страниц может быть доведена до автоматики на 90%. А то есть задача направленного индексирования с последующей структуризацией данных, может решаться без необходимости в разработке отдельных парсеров под каждый сайт, может решаться лишь с самым минимальным участием человека или же вообще без его участия.  

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

Прежде чем продолжить рассуждения, а что же такое данные с нечеткой структурой? Начну с примера.

При преобразовании HTML в RSS, как, например, это происходит в Скиуре, очень часта ситуация когда структура данных меняется. Это может быть из-за того что немного подкрутили верстку или, к примеру, у новости появилась метка которая при обучении на данных сайта не встречалась, но была с самого начала предусмотрена, например, «новое» или ещё что-либо не являющееся сменой CMS или реорганизацией структуры сайта, но затрагивающее HTML структуру ленты новостей.

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

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

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

В случае новостной информации – это довольно просто и даже очень просто, поскольку структура транслируемых новостей давно уже определена в спецификациях RSS/ATOM, и то при распознавании достаточно 10% от специфицированных полей.  Кроме того отслеживание структурных аномалий для частного случая – это однократная и решаемая задача. Поиск решения для новостной информации закодированной в HTML у меня занял пару месяцев – в основном на анализ и систематизацию структуры данных в источниках. 

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

К вопросу о том зачем всё это нужно? Это нужно, поскольку сейчас процесс организации данных в Linked Data и иных связанных машиночитаемых формах – весьма долгосрочен. В каждом случае – это связано с долгим ожиданием когда владелец/контролёр источника данных решит представлять его в более удобной форме. При том что есть множество энтузиастов которые могут оцифровать тот или иной срез данных – как, например, статистические данные США или России, в машиночитаемую форму – тем не менее систематизация источников данных позволит обеспечить доступность данных на потоковой основе. 

Или, говоря иначе, ненужно ждать пока государство начнёт отдавать данные в RDF или же общедоступные данные станут доступными в виде микроформатов или тех или иных срезов – необходимо создавать механизмы и программные продукты автоматизирующие процесс преобразования данных из Legacy форм в формы пригодные к последующей интеграции. 

Всё это к вопрос о том как лично я вижу data.gov.ru  примерно через пару лет, разумеется, в случае его появления.