3Методическая, организационная и техническая части регламентирующей документации к порядку и форматам публикации, хранения и предоставления доступа к открытым данным
В настоящем разделе приведены методические, организационные и технические положения для регламентирующей документации к порядку и форматам публикации, хранения и предоставления доступа к открытым данным. Регламенты, разработанные на основе этих приложений приведены в Приложениях В и Г.
3.1Схема процессов деятельности по открытию государственных данных
На основе анализа результатов проекта с использованием метода структурного анализа была разработана схема (модель) процессов деятельности по открытию государственных данных. Верхний уровень этой модели представлен на Рисунок 2, а вся модель – в Приложении Б.
Модель разработана в стандарте IDEF0 [http://ru.wikipedia.org, http://www.idef.com/IDEF0.htm]. В ней информационная технология представлена в структурированном формализованном виде как система процессов, связанных по входам и выходам. В соответствии с этим стандартом каждый процесс (подпроцесс, шаг процесса, действие) представляется в виде прямоугольника с названием процесса внутри. В процесс (прямоугольник) сверху, слева и снизу могут входить стрелки, показывающие соответственно управления (управляющих воздействий, ограничений и т.п.), исходные (входные) материалы и информацию, механизмы (исполнители процесса: организации, подразделения, люди, машины, программные модули и т.п.) (Рисунок 1). Стрелок может быть несколько. Из процесса (прямоугольника) с правой стороны должна выходить одна стрелка или более. Она (они) означают результат выполнения процесса (материалы, информацию, ресурсы и т.п.).
Стрелки, выходящие из одних процессов, входят в другие процессы, что показывает взаимодействие процессов.
Процессы декомпозируются на подпроцессы. Подпроцессы изображаются на другой диаграмме (схеме, странице). При этом на диаграмму с подпроцессами перемещаются стрелки, которые входили в родительский процесс и выходили и него.
Рисунок 1 – Основные элементы нотации стандарта IDEF0
Действия, указанные в модели, соответствуют требованиям, приведенным в Техническим задании на выполнение работы.
Эта модель была принята за основу при разработке Регламента по обеспечению свободного доступа к открытым данным и Регламента формирования единого реестра открытых государственных данных в Российской Федерации, а также порядка и формата сбора информации о них от ведомств (регламенты приведены в Приложениях В и Г).
Далее в разделе приведены методические рекомендации, организационные и технические требования, которые следует учитывать при формировании упомянутых выше регламентов.
Рисунок 2 – Модель процессов деятельности по открытию государственных данных (верхний уровень)
3.2Процесс “Публикация государственных данных органами государственной власти”
При описании этого и других процессов некоторые требования повторяются. Такое обстоятельство вызвано тем, что ряд требований относятся к нескольким процессам (подпроцессам), указанным в Техническом задании.
3.2.1Загрузка данных из информационных систем органов государственной власти в среду (портал) публикации данных
Загрузка данных органами государственной власти и подведомственными ему учреждениями должна производиться в соответствии с функциями и полномочиями органа власти.
Загрузка данных органом власти и подведомственными ему учреждениями должна происходить в соответствии с требованиями федерального законодательства.
В случае отнесения органа власти к власти субъектов федерации или муниципальным властям, загрузка данных должна учитывать требования законодательства субъекта федерации и муниципальных нормативно-правовых актов соответственно.
Процесс загрузки открытых данных должен быть должным образом организован и закреплен в формате нормативно-правового акта органа власти.
Должна быть четко определена ответственность лиц ответственных за публикацию открытых данных за актуальность и своевременность загрузки данных.
Процесс загрузки данных должен быть обеспечен с помощью широкого спектра технических средств с учетом возможности загрузки данных с различных операционных систем и веб-обозревателей.
Процесс загрузки данных должен учитывать возможные требования по ограничению определенного типа форматов данных, которые могут быть отмечены как устаревшие и не рекомендуемые к публикации.
При загрузке данных должен осуществляться входной контроль за форматами публикуемых данных.
Характеристики загружаемых наборов данных должны быть описаны в паспорте набора данных (см. ниже).
Целесообразно вместе с набором данных предоставлять инструменты (правила) для проверки его целостности.
При выборе форматов файлов для публикации необходимо исходить из критериев пригодности публикации данных по частоте обновления по отрасли.
По частоте обновления выбор форматов должен производиться между динамическими и редко обновляемыми форматами файлов.
При выборе форматов для публикации данных органы власти должны руководствоваться зарубежной и российской практикой публикации открытых данных, отдавая приоритет свободным форматам, не имеющим патентных, правовых и иных ограничений.
За исключением особых случаев форматы файлов должны предусматривать возможность их просмотра и печати как текста.
Редко обновляемые данные (обновляемые не чаще чем раз месяц) должны публиковаться в машиночитаемых форматах, таких как XML, CSV, KML, XLS, ODS, RDF, DBF.
Данные связанные в общий массив данных должны быть описаны на веб-странице имеющей постоянную ссылку (пермалинк), также постоянная ссылка должна быть у каждого из файлов в данного массива данных.
Запрещается использовать в названии массива данных, его описании и в описании структуры данных слова, оскорбляющие человеческое достоинство, пропагандирующие насилие или экстремизм, разжигающие расовую, национальную или религиозную вражду, а также нецензурную лексику.
Рекомендуется публиковать в формате CSV данные имеющие плоскую табличную форму.
Рекомендуется публиковать сложные иерархические данные в форматах XML.
В случае если размер массивов данных превышает 10 мегабайт, рекомендуется публиковать данные после архивации в форматах ZIP или RAR.
В случае если данные включают информацию об адресе или ином географическом местоположении, рекомендуется добавлять поля широты и долготы для записей, имеющих географическую привязку.
Данные в виде списков учреждений с их адресами рекомендуется также публиковать в формате KML с указанием точных географических координат.
Динамические данные (обновляемые чаще чем еженедельно) должны быть доступны через веб-сервисы и в виде архивных массивов данных.
Архивные массивы данных должны публиковаться не реже чем помесячно с детализацией не позднее прошлого месяца от текущей даты.
Веб-сервисы должны предоставлять данные в форматах XML или JSON, за исключением случаев предоставления ускоспециализированных данных.
В случае необходимости авторизации для доступа к данным через веб-сервис, при описании сервиса должна быть описана процедура получения к нему доступа и контакт ответственной за предоставление доступа персоны.
Доступ к данным через веб-сервис при наличии авторизации должен быть обеспечен со всех возможных программных платформ и языков разработки.
В случае предоставления большого объема данных должен быть обеспечен механизм получения их обновления в виде “дельты”, только измененных данных.
Рекомендуется предоставление веб-сервисов, работающих на базе REST+JSON или SOAP + XML.
Рекомендуется предоставление данных через веб-сервис на получение как отдельных записей, так и их списков и отдельных выборок.
Рекомендуется вместо предоставления файлов через веб-сервисы предоставлять ссылки на их выгрузку по прямым ссылкам.
Рекомендуется предоставлять примеры использования веб-сервиса на различных языках и платформах разработки таких как .NET, Java, Python, RoR и иных.
Выбор отраслевого формата файлов для публикации специализированных (отраслевых) данных находится полностью в ведении органа власти.
При выборе формата для публикации орган власти должен руководствоваться следующими принципами: отсутствия ограничений на коммерческое и некоммерческое использование файлов в данном формате, наличие в открытом доступе инструментов для работы с файлами данного формата, пригодность данного формата для публикации данных в полном объеме.
Отраслевые форматы файлов рекомендуется формировать на основе XML или аналогичных форматов, без использования бинарного представления данных.
До разработки специализированных форматов самостоятельно рекомендуется провести предварительный анализ наличия российских или зарубежных стандартов публикации информации данного типа.
3.2.2Конвертация загружаемых данных в форматы реляционных баз данных и RDF
Конвертация загружаемых данных в форматы реляционных баз данных и RDF должна соответствовать лучшим зарубежным и российским практикам в этой области.
При выборе инструментов конвертации рекомендуется отдавать предпочтение инструментам конвертации с открытым исходным кодом.
Процесс конвертации должен проходить внутренний технологический аудит на предмет проверки сохранения полноты и целостности преобразованных данных и отсутствия искажений.
Процедура конвертации данных должна быть четко определена, равно как и принципы её организации, производится ли она силами сотрудников органа власти или внешним подрядчиком.
При размещении баз данных, полученных в результате конвертации, должно быть обеспечено определение ответственности органа власти при публикации преобразованных данных.
Необходима обязательная валидация RDF данных, полученных в процессе конвертации, посредством существующих технологических инструментов и веб-сервисов, таких как W3C RDF Validator (http://www.w3.org/RDF/Validator/).
3.2.3Внесение изменений в опубликованные наборы данных
Процесс изменения в опубликованные наборы данных должен соответствовать нормативно-правовым документам Российской Федерации.
Регламент внесения изменения в описания массивов данных и непосредственно в данные должен четко определять права и полномочия пользователей, имеющих права на внесение подобных изменений.
Рекомендуется включение следующих ролей: администратор – пользователь с правом внесения любых изменений, редактор – пользователь имеющий право на внесение изменений в рамках полученных прав, например, только в рамках данных конкретного ведомства, читатель – пользователь, имеющий право только на просмотр и выгрузку данных.
Программное обеспечение ведения реестров открытых данных и веб-сайтов для публикации открытых данных должно обеспечивать журналирование всех изменений, вносимых в описание массивов данных, замену ссылок и файлов опубликованных ранее массивов данных.
Журналы изменений должны храниться неограниченное время, без сроков давности и быть доступны техническому персоналу, обеспечивающему публикацию массивов данных.
3.2.4Организация обратной связи от органов государственного управления к службам обеспечения эксплуатации и развития системы публикации государственных данных
Обратная связь от государственных органов, публикующих данные, к службам обеспечения эксплуатации и развития системы публикации государственных данных (в том числе единого портала открытых данных Российской Федерации) должна использоваться для обработки инцидентов, разрешения проблем и сбора информации в интересах развития системы публикации государственных данных.
Обратную связь от государственных органов, публикующих данные, к службам обеспечения эксплуатации и развития системы публикации государственных данных целесообразно организовывать в соответствии с рекомендациями ITIL (Information Technology Infrastructure Library – библиотека инфраструктуры информационных технологий). В первую очередь, должны быть реализованы следующие процессы и службы:
служба Service Desk;
управление конфигурациями;
управление инцидентами;
управление проблемами;
управление изменениями;
управление релизами.
Обратная связь должна быть организована через службу Service Desk веб-сайтов и единого портала открытых данных Российской Федерации. При этом должна быть предусмотрена «горячая линия», обеспечивающая связь по телефонам и электронной почте в рабочее время.
Для организации обратной связи целесообразно использовать Bag Tracker (средства регистрации и отслеживания ошибок).
Органы государственной власти должны разработать регламент по обеспечению обратной связи от органов государственного управления к службам обеспечения эксплуатации и развития системы публикации государственных данных.
|
