Проверка идеи по созданию открытых данных общественными силами

Есть одна идея которую лично я считаю что просто необходимо подтвердить или опровергнуть экспериментально.

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

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

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

Что я хочу сделать.

В качестве эксперимента я готов выделить из личных средств 5-10 тысяч рублей на 1 месяц на разработку парсеров. Сумма небольшая, но это именно что эксперимент, это проверка идеи.  А если всё получится, то суммы потом будут больше.

Однако я хочу не просто заказать работы  на стороне, а с соблюсти следующие условия:

1. Код парсера должен быть доступен всем желающим с открытым исходным кодом под лицензией допускающей коммерческое и некоммерческое использование. Предпочтительные лицензии — BSD, MPL, Apache License и т.д. Соответственно без проприетарного кода и без GPL. Код автор публикует в сети сам или присылает мне и я публикую на специальном сайте или OpenGovData.ru

2. Предпочтительные языки разработки по убыванию — Python, Ruby, PHP. Другие скриптовые возможны, но менее предпочтительны. Языки предусматривающие компиляцию кода вроде C, C++, Java  точно не рассматриваются.

3. Форматы выходных данных могут быть — CSV, XML, JSON. Соответственно CSV предпочтителен для всех плоских списков, для более сложных структур нужны данные в XML и JSON.

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

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

Простые массивы

Сложные массивы

  • Сведения о доходах сотрудников РосГраницы — http://www.rosgranitsa.ru/about/income . Несколько .DOC документов с таблицами.
  • Реестр недобросовестных поставщиков — http://rnp.fas.gov.ru/
  • Реестр лицензий на осуществление деятельности по организации и проведению азартных игр в букмекерских конторах — http://www.nalog.ru/html/docs/reestr_buk.doc . Файл MS Word со сложными, но унифицированными таблицами.
  • Сводная налоговая отчетность — http://www.nalog.ru/document.php?id=27443&topic=stat_otch. Очень много многостраничных XLS файлов.

Плюс, прошу Вас предлагать те что Вам интересны. Список можно найти тут — http://www.opengovdata.ru/sources/

В итоге для каждого массива должно быть:

— скрипт по его конвертации;

— данные в машиночитаемом формате

— короткое описание README с описанием зависимостей скрипта и полей данных

И вот тут, то мы приходим к главному вопросу КАК именно это всё это я хочу осуществить.

Вначале — мои цели:

1. Преобразовать как можно большее число массивов в машиночитаемый вид.

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

3. Преобразовать в первую очередь наиболее востребованную гражданами информацию.
И вот теперь собственно мои вопросы по результатам размышлений о вышенаписанном.  Меня волнует следующее — в какой форме лучше всего организовать процесс.

Рассмотрим варианты:

  • Призовой конкурс. Для каждого массива данных устанавливается сумма за его преобразование в машиночитаемый вид. Первый кто прислал или опубликовал результат — получает эту сумму. Если больше одного человека пишут скрипт — второму идёт поощрительная сумма.
  • Редукцион. Указывается максимальная цена, сроки и ожидаемые результаты, от потенциальных исполнителей получаются предложения сделать за меньшие или эти деньги. Побеждает тот предлагает наименьшую цену. Но у нас же не госзаказ, нам нужна соревновательность.

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

—-

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

1. В какой форме лучше всего организовать процесс?

2. Какие существующие массивы данных Вам бы _очень_ хотелось увидеть машиночитаемыми и включить в список выше?

3. Если Вы разработчик, было бы Вам интересно в таком мероприятии поучаствовать?

Идеи, предложения, дискуссии и распространение всячески приветствуются.

UPDATE: Первые результаты обсуждения идеи тут — http://ivan.begtin.name/2010/08/25/idearesults/

Результаты преобразований тут — http://opengovdataru.pbworks.com/%D0%9A%D0%B0%D0%BA-%D0%BF%D0%BE%D0%BC%D0%BE%D1%87%D1%8C-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D1%83

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

About This Author

  • http://roman.yankovsky.me/ Roman Yankovsky

    Я бы мог написать какой-нибудь парсер, но честно говоря, не вижу применения этим получаемым машиночитаемым данным. Можете в пример какой-нибудь use case привести?

  • Ashrub

    php исключи из списка, не стоит на него силы тратить, хотя по большому счёту там язык должен мало участвовать — сами парсеры должны быть на xpath и/или xslt, а скрипт лишь должен применять их к исходным даным (возможно подогнанным к xml с помощью tidy)
    worldmind.livejournal.com

    • http://ivan.begtin.name Ivan Begtin

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

      Насчёт Xpath, по большй части, согласен — его использование удобно. Насчёт xslt, у меня лично есть сомнения. В условиях существования легче читаемых альтернатив вроде парсеров на python или ruby он не кажется особенно полезным.

      • http://worldmind.livejournal.com/ worldmind

        Да парсеры на всём можно писать, только писанное на php с большой вероятностью будет сложнее сопровождать, по хорошему надо опираться на xpath, а регулярные выражения в крайнем случае использовать т.к. xpath читабельнее
        Вот пример с xpath, даже без написания скрипта т.е. можно сказать что это уже в какой-то мере машиночитаемые даные
        скачал http://www.rossvyaz.ru/docs/num/ABC-3x.html
        сконвертил в xhtml
        tidy -asxhtml -i -raw -wrap 140 -o ABC-3x.xhtml ABC-3x.html
        сконвертил в uft8
        cat ABC-3x.xhtml | iconv -f cp1251 -t utf8 > abc-3x.xhtml
        делаю запрос на первую строку с данными
        xpath -e '/html/body/table/tr[2]/td/text()' abc-3x.xhtml

        — NODE —
        301
        — NODE —
        2100000
        — NODE —
        2109999
        — NODE —
        10000
        — NODE —
        АСВТ(Москва)
        — NODE —.
        Улан — Удэ |Республика Бурятия

        вот они данные, по сути этот алгоритм надо оформить в виде python скрипта, зациклить или допилить сам xpath и готовы данные, а кто шарит в xslt (я давно ничего не делал, лень вспоминать) может сразу исходный xhtml документ в csv конвернуть

        • http://ivan.begtin.name Ivan Begtin

          По этому массиву мне уже прислали 2 парсера — на Python и на Ruby так что здесь вопрос уже решённый.

  • http://twitter.com/f1ashr Flashr Topbot

    В целом идея заманчивая, ведь надо с чего-то начинать. Даже сервисы расписаний типа туту начинали свою жизнь с того, что парсили страницы вокзалов. Я хоть и разработчик и пишу регексы для парсинга страниц весьма быстро, но делаю все это на .Net и выкладываю по типу blogsapi.codeplex.com . По теме отмечу, что мало одного парсинга, нужно еще и иметь возможность тестинга, изменился ли формат страницы или нет. Также глупо тредование по формату выходных данных, если данные преобразованы в логическую форму, то этого достаточно, чтобы потом настроить DataContract на любой формат.

    • http://ivan.begtin.name Ivan Begtin

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

  • Sergey

    для Выписка из реестра плана нумерации Россвязи http://github.com/skojin/rossvyaz_register_parser

    • http://ivan.begtin.name Ivan Begtin

      Сергей, большое спасибо!

  • 13DaGGeR

    работаю программистом на php. то что неудобно писать на нем парсер — бред людей, которые мало понимают в вэб вообще. php является очень распространенным языком, следовательно найти человека, который напишит или прочтет код на php гораздо проще, чем оного на Ruby.
    у нас есть тест для программистов, которые приходят на работу — написать парсер =) . если будут кандидаты, дам им вашу идею.
    а вам пока советую найти преподавателей вышеуказанных языков в вузах. им ничего не стоит дать задание для студентов как скажем курсовик или на зачет. всем польза.

    • http://ivan.begtin.name Ivan Begtin

      Спасибо, прекрасная идея и насчёт тестовых заданий при трудоустройстве и насчёт преподавателей. В OpenGovData.ru очень много накопилось источников данных пока ещё не преобразованных и для которых сравнительно несложно написать парсеры.

  • ne

    а требований к формату результата нет?. ну типа «допустимы перекрёстные ссылки», «запрещено дублирование данных» и т.п..

    • http://ivan.begtin.name Ivan Begtin

      Пока ещё нет, полагаю наиболее правильным их выработать в обсуждении.

      • ne

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

  • Alex Kapranoff

    Взялся за недобросовестных поставщиков.

  • Viktor Mireyev
    • http://ivan.begtin.name Ivan Begtin

      Круто, спасибо!

  • Andrey

    >Языки предусматривающие компиляцию кода вроде C, C++, Java точно не рассматриваются

    Не понятно, чем Java не устраивает. И при чем здесь компиляция вообще?

  • http://twitter.com/Valery35 Valery Hronusov

    По Java не согласен.
    Запустить машину на сервере нет проблем.
    И про JWT не забудем, да и Java самый популярный в мире язык.
    Про SOAP, SDMX тоже не забудем.
    Про API.
    Про RDF
    Про W3C стандарты как базу.

  • http://twitter.com/CatalogLoader Catalog Loader

    имеется универсальный парсер — поддерживающий структуры,

    вот сайт программы: http://cost-effective.ru

Яндекс.Метрика