Ещё один "мелкий нюанс" с новым реестром отечественного ПО [1] - это "гниение ссылок". Ссылки из старого реестра не открываются в новом заменой домена, а также при формировании ссылок в них указывается не номер программы в реестре, а на технический идентифкатор в базе данных. Вот пример: [2], код программы в реестре ПО 10269, а идентификатор в ссылке 330494 (reestr.digital.gov.ru/reestr/330494/). Такое вообще не редкость и бывает когда разработчики изначально не думают о пользователях. Я знаю десятки сайтов органов власти где подобное происходило неоднократно при замене CMS системы или создании нового сайта госоргана/госучреждения.
Эта проблема есть не только у госорганов. Например, в Великобритании достаточно давно, с 2017 года, обсуждают об создании постоянных ссылок для государственных документов [3] и рассматривают DOI в этом качестве. Казалось бы какая очевидная идея и можно было бы применять не только для цифровых документов, но "почему то", такие инновации внедряются с большим трудом и не только в государстве.
Но есть и примеры постоянных ссылок с момента появления организации. W3C имеет W3C URI Persistence Policy [4] с 1999 года и все опубликованные документы W3C всегда доступны по тем ссылкам что они были размещены.
Впрочем, надо отдать должное коллегам из Минцифры, экспорт в XML из реестра, наконец-то, заработал, что, отчасти снимает проблему устаревания ссылок поскольку в экспортированных данных есть уникальные идентификаторы ПО. Но, счастье было бы полным, если бы экспорт в XML содержал _все_ данные по карточкам ПО, например, сейчас не экспортируются код ОГРН владельца ПО.
Кроме того, я напомню, в данных есть ошибки с реквизитами организаций. Сильно меньше чем в других госреестрах, но доли процента записей (около 10 невалидных кодов ИНН).
В любом случае это лучше чем было, теперь реестр можно подвергать автоматическому анализу, как минимум.
Возвращаясь к изначальной теме, вся проблема с устареванием ссылок в реестрах как раз могла бы решаться через уникальные ссылки основанные на уникальном идентификаторе записи присвоенной приказом, а не техническом номере в базе данных.
В остальном же лучше публиковать данные дампами на дату и создавать раздел "Открытые данные" и у этого есть 2 причины:
1. Так просто напросто удобнее в работе с данными которые меняются со временем. Пример похожей модели - это данные ФИАС где регулярные дампы в XML и DBF и всегда можно их сравнить
2. Некоторыекриворукие разработчики делают экспорт данных динамическим. Когда таким образом экспортируется от 10 до 100 записей проблем не возникает. Когда идёт экспорт всего реестра - это гарантированный способ положить всю систему DDoS атакой. Кешировать данные для экспорта - это, также, подставка для кривых рук. Регулярные (ежесуточные/еженедельные) дампы и API - это правильное решение.
А в целом реестров в стране десятки тысяч, я давно хочу написать что я думаю по тому как они должны быть/могли бы быть организованы уже в виде концептуального документа.
Ссылки:
[1] http://reestr.digital.gov.ru
[2] https://reestr.digital.gov.ru/reestr/330494/
[3] https://github.com/alphagov/open-standards/issues/75
[4] https://www.w3.org/Consortium/Persistence
#opendata #digital #registries
Эта проблема есть не только у госорганов. Например, в Великобритании достаточно давно, с 2017 года, обсуждают об создании постоянных ссылок для государственных документов [3] и рассматривают DOI в этом качестве. Казалось бы какая очевидная идея и можно было бы применять не только для цифровых документов, но "почему то", такие инновации внедряются с большим трудом и не только в государстве.
Но есть и примеры постоянных ссылок с момента появления организации. W3C имеет W3C URI Persistence Policy [4] с 1999 года и все опубликованные документы W3C всегда доступны по тем ссылкам что они были размещены.
Впрочем, надо отдать должное коллегам из Минцифры, экспорт в XML из реестра, наконец-то, заработал, что, отчасти снимает проблему устаревания ссылок поскольку в экспортированных данных есть уникальные идентификаторы ПО. Но, счастье было бы полным, если бы экспорт в XML содержал _все_ данные по карточкам ПО, например, сейчас не экспортируются код ОГРН владельца ПО.
Кроме того, я напомню, в данных есть ошибки с реквизитами организаций. Сильно меньше чем в других госреестрах, но доли процента записей (около 10 невалидных кодов ИНН).
В любом случае это лучше чем было, теперь реестр можно подвергать автоматическому анализу, как минимум.
Возвращаясь к изначальной теме, вся проблема с устареванием ссылок в реестрах как раз могла бы решаться через уникальные ссылки основанные на уникальном идентификаторе записи присвоенной приказом, а не техническом номере в базе данных.
В остальном же лучше публиковать данные дампами на дату и создавать раздел "Открытые данные" и у этого есть 2 причины:
1. Так просто напросто удобнее в работе с данными которые меняются со временем. Пример похожей модели - это данные ФИАС где регулярные дампы в XML и DBF и всегда можно их сравнить
2. Некоторые
А в целом реестров в стране десятки тысяч, я давно хочу написать что я думаю по тому как они должны быть/могли бы быть организованы уже в виде концептуального документа.
Ссылки:
[1] http://reestr.digital.gov.ru
[2] https://reestr.digital.gov.ru/reestr/330494/
[3] https://github.com/alphagov/open-standards/issues/75
[4] https://www.w3.org/Consortium/Persistence
#opendata #digital #registries
GitHub
A standard for persistently identifying documents · Issue #75 · alphagov/open-standards
Create A Challenge I am creating this challenge on behalf of the Data Standards Authority, based on suggestions from the community Title A standard for persistently identifying documents and datase...