Я ранее рассказывал про разные эксперименты в обработке данных, например, про обработку данных в NoSQL базах данных и про экспериментальную библиотеку mongorefine [1].
Когда-то из других экспериментов у меня получилась библиотека по автоматизации извлечения новостей из HTML newsworker [2]. Я её почти не обновлял несколько лет, но это и не требовалось.
А вот про один эксперимент, к я практически не рассказывал, это попытка ответить на вопрос - можно ли работать с HTML как с SQL? Так чтобы не делать запросы через язык запросов xpath или API библиотек парсинга. Но после нескольких прикидок стало очевидно что усилий потребуется много, фактически надо сделать SQL движок с нуля и решить вопрос с тем как данные преобразовать из иерархических в плоскую таблицу.
Зачем вообще это было нужно? В задаче по извлечению новостей которую я решал в библиотеке newsworker одной из внутренних задач была кластеризация тегов. Метод который я использовал для кластеризации предполагал сбор о каждом теге дополнительных данных, которых нет в содержании HTML страницы. Это данные о позиции тега внутри родительского тега и о глубине тега относительно корневого тега. В целом это решалось относительно просто за счёт того что в библиотеке newsworker кластеризация шла по тегам отмеченным как содержащие даты, а таких на веб страницах редко более 100.
Тем не менее той задачей всё это не ограничивалось и идея с тем что можно работать с HTML как данными меня не покидала. В другом эксперименте я попробовал преобразовывать HTML в плоский Pandas DataFrame. Всё таки DataFrame - это почти как SQL, а может и лучше и удобнее. Как при этом решить перевод иерархических данных в плоские? Собираем все атрибуты тегов, разворачиваем их в колонки и для всех тегов заполняем таблицу где если атрибута нет то у него нулевое значение в ячейке.
С точки зрения удобства технического анализа - это очень удобно. Плоская таблица, можно делать запросы простым образом, они обрабатываются быстрее. С точки зрения эффективности работы с памятью - это, конечно, не так хорошо. Размер DataFrame от 7 до 21 раза превышает объём оригинальной веб-страницы. Конечно это именно из-за большого числа пустых колонок в получающейся таблице. Собственно поэтому я код этого эксперимента так и не опубликовал, раздумывая над тем как можно, или придумать другой способ делать быстрые запросы к дереву тегов, или как сжимать пространство атрибутов к тегам с сохранением эффективности запросов.
Наверное, в какой-то момент когда у меня будет больше свободного времени и готовность дописать документацию я смогу показать что получается.
Но в целом я хотел рассказать про этот эксперимент как иллюстрацию подхода к созданию чего-то нового по принципу "А давайте возьмём вот это с нестандартным интерфейсом и приделаем один из стандартных?". Идей для такого множество, какие-то совершенно некоммерческие, другие могут иметь разные формы применения.
Например։
- работа с почтовыми ящиками как с SQL или NoSQL базами данных. Есть несколько продуктов превращающих IMAP/POP3 ящики в REST API, что тоже даёт возможности для интеграции в Modern Data Stack, но можно ещё больше
- универсальные API для работы с любыми документами разметки. Из того что есть в открытом коде к этому более всего приближается unstructured [3], дающий одинаковые инструменты для разбора PDF, DOCX, HTML и электронных писем.
И ещё очень многое упрощающее интеграцию того что можно отнести к унаследованным протоколам, форматам и стандартам работы к тем что лучше интегрируются с новыми продуктами.
Ссылки։
[1] https://medium.com/@ibegtin/nosql-data-wrangling-50b5a2898a83
[2] https://github.com/ivbeg/newsworker
[3] https://github.com/Unstructured-IO/unstructured
#datatools #opensource #experiments
Когда-то из других экспериментов у меня получилась библиотека по автоматизации извлечения новостей из HTML newsworker [2]. Я её почти не обновлял несколько лет, но это и не требовалось.
А вот про один эксперимент, к я практически не рассказывал, это попытка ответить на вопрос - можно ли работать с HTML как с SQL? Так чтобы не делать запросы через язык запросов xpath или API библиотек парсинга. Но после нескольких прикидок стало очевидно что усилий потребуется много, фактически надо сделать SQL движок с нуля и решить вопрос с тем как данные преобразовать из иерархических в плоскую таблицу.
Зачем вообще это было нужно? В задаче по извлечению новостей которую я решал в библиотеке newsworker одной из внутренних задач была кластеризация тегов. Метод который я использовал для кластеризации предполагал сбор о каждом теге дополнительных данных, которых нет в содержании HTML страницы. Это данные о позиции тега внутри родительского тега и о глубине тега относительно корневого тега. В целом это решалось относительно просто за счёт того что в библиотеке newsworker кластеризация шла по тегам отмеченным как содержащие даты, а таких на веб страницах редко более 100.
Тем не менее той задачей всё это не ограничивалось и идея с тем что можно работать с HTML как данными меня не покидала. В другом эксперименте я попробовал преобразовывать HTML в плоский Pandas DataFrame. Всё таки DataFrame - это почти как SQL, а может и лучше и удобнее. Как при этом решить перевод иерархических данных в плоские? Собираем все атрибуты тегов, разворачиваем их в колонки и для всех тегов заполняем таблицу где если атрибута нет то у него нулевое значение в ячейке.
С точки зрения удобства технического анализа - это очень удобно. Плоская таблица, можно делать запросы простым образом, они обрабатываются быстрее. С точки зрения эффективности работы с памятью - это, конечно, не так хорошо. Размер DataFrame от 7 до 21 раза превышает объём оригинальной веб-страницы. Конечно это именно из-за большого числа пустых колонок в получающейся таблице. Собственно поэтому я код этого эксперимента так и не опубликовал, раздумывая над тем как можно, или придумать другой способ делать быстрые запросы к дереву тегов, или как сжимать пространство атрибутов к тегам с сохранением эффективности запросов.
Наверное, в какой-то момент когда у меня будет больше свободного времени и готовность дописать документацию я смогу показать что получается.
Но в целом я хотел рассказать про этот эксперимент как иллюстрацию подхода к созданию чего-то нового по принципу "А давайте возьмём вот это с нестандартным интерфейсом и приделаем один из стандартных?". Идей для такого множество, какие-то совершенно некоммерческие, другие могут иметь разные формы применения.
Например։
- работа с почтовыми ящиками как с SQL или NoSQL базами данных. Есть несколько продуктов превращающих IMAP/POP3 ящики в REST API, что тоже даёт возможности для интеграции в Modern Data Stack, но можно ещё больше
- универсальные API для работы с любыми документами разметки. Из того что есть в открытом коде к этому более всего приближается unstructured [3], дающий одинаковые инструменты для разбора PDF, DOCX, HTML и электронных писем.
И ещё очень многое упрощающее интеграцию того что можно отнести к унаследованным протоколам, форматам и стандартам работы к тем что лучше интегрируются с новыми продуктами.
Ссылки։
[1] https://medium.com/@ibegtin/nosql-data-wrangling-50b5a2898a83
[2] https://github.com/ivbeg/newsworker
[3] https://github.com/Unstructured-IO/unstructured
#datatools #opensource #experiments
Medium
MongoDB
For a long time, I would like to write about NoSQL data wrangling.
В рубрике интересных наборов данных Software mentions - это большой набор данных всех упоминаний программных продуктов в научных статьях и литературе по биомедицине. В репозитории представлен код которым собирался этот набор данных [1] и сам набор данных также доступен [2]. В нём, в общей сложности, 1,12 миллион упоминаний программных продуктов извлеченных из 2,4 миллионов научных статей извлеченных из NIH PMC-OA Commercial subset, 481 упоминание программных продуктов из NIH PMC-OA Non-Commercial subset и 934 тысячи упоминаний программных продуктов из 4 миллионов статей в NIH Publishers Collection. Это всё около 4Гб в сжатом виде.
Поэтому если кратко, то это большой набор данных, дающий, как минимум, возможность оценить популярность инструментов и языков разработки используемых специалистами в области биоинформатики. Удивительно что пока никто не визуализировал эти данных, скорее всего просто мало кто знает о существовании этого набора данных.
Создание набора данных профинансировал фонд Chan-Zukerberg Initiative, который стоит упомянуть отдельно как один из крупнейших в мире фондов поддерживающий открытую науку и открытые инструменты для учёных в частности [3]. Это, в принципе, из тех инициатив которые являются другой гранью биг теха. С одной стороны, Facebook, одна из компаний построенных исключительно на недружелюбной слежке за пользователями, а с другой Цукерберг создал и развивает не имитационную, а самую настоящую некоммерческую инициативу без каких-либо "камней за пазухой".
У многих биг тех компаний и их основателей похожий подход. Да, в каких-то вопросах их репутация может быть крайне плохой, а в других наоборот обвинить не в чем. Мир совсем не чёрно белый.
Ссылки։
[1] https://github.com/chanzuckerberg/software-mentions
[2] https://doi.org/10.5061/dryad.6wwpzgn2c
[3] https://tech.chanzuckerberg.com/scitech/
#openaccess #openscience #scitech #datasets #data #opendata
Поэтому если кратко, то это большой набор данных, дающий, как минимум, возможность оценить популярность инструментов и языков разработки используемых специалистами в области биоинформатики. Удивительно что пока никто не визуализировал эти данных, скорее всего просто мало кто знает о существовании этого набора данных.
Создание набора данных профинансировал фонд Chan-Zukerberg Initiative, который стоит упомянуть отдельно как один из крупнейших в мире фондов поддерживающий открытую науку и открытые инструменты для учёных в частности [3]. Это, в принципе, из тех инициатив которые являются другой гранью биг теха. С одной стороны, Facebook, одна из компаний построенных исключительно на недружелюбной слежке за пользователями, а с другой Цукерберг создал и развивает не имитационную, а самую настоящую некоммерческую инициативу без каких-либо "камней за пазухой".
У многих биг тех компаний и их основателей похожий подход. Да, в каких-то вопросах их репутация может быть крайне плохой, а в других наоборот обвинить не в чем. Мир совсем не чёрно белый.
Ссылки։
[1] https://github.com/chanzuckerberg/software-mentions
[2] https://doi.org/10.5061/dryad.6wwpzgn2c
[3] https://tech.chanzuckerberg.com/scitech/
#openaccess #openscience #scitech #datasets #data #opendata
GitHub
GitHub - chanzuckerberg/software-mentions
Contribute to chanzuckerberg/software-mentions development by creating an account on GitHub.
Я тут было подумал написать свежий текст о том что не так с госинформатизацией и с "Гостехом-в-вакууме" как одним из явлений этой же природы в России. Чуть менее чем год назад я тезисно об этом писал [1] и один из тезисов был то что в России много лет информатизация государства шла по пути технологической унитаризации. Это такое, в каком-то смысле уникальное российское явление о котором я писал ещё в 2011 году, но почти все мои тексты того времени куда подевались. Его суть в том что такое обилие глобальных федеральных государственных информационных систем (далее - ФГИС), совершенно монструозных по масштабу, потраченным деньгам и функциям, всё это следствие неявно обозначенной стратегии "поджирания полномочий" федеральными властями в отношении региональных и муниципальных властей.
ФГИС с которыми были и сейчас обязаны работать регионы и муниципалитеты чаще всего создавались по пограничной зоне ответственности федеральной и региональной власти, но, при этом под федеральным органом органом власти осуществляющим регулирование. Так создавалась единая система в сфере закупок, так создаётся единая система в сфере торгов , так создана ЕГР ЗАГС, Электронная школа и ещё многое другое. Только Москва всегда была исключением и московские чиновники ещё давно, при Лужкове, единственные на моей памяти говорили про то что некоторые федеральные законы не соответствуют Конституции РФ.
Такую централизацию всегда можно преподносить как благо, как возможность получить гарантированный сервис не зависящий от региона. Это федеральные власти и делали всё это время. Такие ФГИС закреплялись надолго федеральными законами и выдачей субсидий на информатизацию из федерального бюджета. Обычно происходило выведение из эксплуатации региональной информационной системы, например, системы закупок и переход региональных и муниципальных чиновников на ФГИС.
Часто, те кто писали про коррупцию при создании таких ФГИС не вполне понимали природу самого этого явления. То что при их создании коррупция может быть, да кто бы сомневался. Но важнее что их предназначение было изначально в централизации власти.
И власть это данные и данные это власть. Централизация данных в ФГИСах привела к тому что многие региональные власти не обладают полнотой доступа к собственным данным. Кое-где, например, в тех же госзакупках изначально вопрос открытости данных был необходим именно для доступа регионов. По этой же причине эти данные всё ещё сложно до конца закрыть, как бы кое-кто кое-где этого бы ни хотел. Но многие другие централизованно собираемые данные региональным властям доступны ограничено. Федеральная власть ведёт себя как некоторые корпорации и некоторые страны, это называется цифровой колонизацией и стратегией "данные приходят, данные не выходят".
Поэтому и странные фантазии некоторых не-российских политиков про сепаратизм в Российских регионах очень оторван от реальности, цифровая инфраструктура выстраивалась так чтобы эта вероятность была минимальной, а цена запредельной.
Из-за монструозности этих ФГИСов и тем что за каждой из них стоит, как правило, очень крупный системный интегратор и государственный интересант(-ы)/бенефициар(-ы), приводят к тому что они формируют, костяк цифровой системы госуправления, со всеми её плюсами и минусами. Любую из этих систем очень сложно убрать, сложно обслуживать. Любая из них, при неработоспособности, создаёт существенные проблемы для системы госуправления, граждан и/или бизнеса, потому что на них заворачивали большую часть сервисов и функций госорганов. И даже их модернизация, а уж тем более импортозамещение, это очень непростая задача. И по деньгам, и по мотивации интеграторов, и по рискам простоя и тд.
Далее вместо того чтобы писать длинный абзац того к чему всё это идёт, я задам лишь один, возможно, риторический вопрос. И вот где во всём этом место Гостеху?
Ссылки:
[1] https://t.me/begtin/3600
#government #govtech #itmarket
ФГИС с которыми были и сейчас обязаны работать регионы и муниципалитеты чаще всего создавались по пограничной зоне ответственности федеральной и региональной власти, но, при этом под федеральным органом органом власти осуществляющим регулирование. Так создавалась единая система в сфере закупок, так создаётся единая система в сфере торгов , так создана ЕГР ЗАГС, Электронная школа и ещё многое другое. Только Москва всегда была исключением и московские чиновники ещё давно, при Лужкове, единственные на моей памяти говорили про то что некоторые федеральные законы не соответствуют Конституции РФ.
Такую централизацию всегда можно преподносить как благо, как возможность получить гарантированный сервис не зависящий от региона. Это федеральные власти и делали всё это время. Такие ФГИС закреплялись надолго федеральными законами и выдачей субсидий на информатизацию из федерального бюджета. Обычно происходило выведение из эксплуатации региональной информационной системы, например, системы закупок и переход региональных и муниципальных чиновников на ФГИС.
Часто, те кто писали про коррупцию при создании таких ФГИС не вполне понимали природу самого этого явления. То что при их создании коррупция может быть, да кто бы сомневался. Но важнее что их предназначение было изначально в централизации власти.
И власть это данные и данные это власть. Централизация данных в ФГИСах привела к тому что многие региональные власти не обладают полнотой доступа к собственным данным. Кое-где, например, в тех же госзакупках изначально вопрос открытости данных был необходим именно для доступа регионов. По этой же причине эти данные всё ещё сложно до конца закрыть, как бы кое-кто кое-где этого бы ни хотел. Но многие другие централизованно собираемые данные региональным властям доступны ограничено. Федеральная власть ведёт себя как некоторые корпорации и некоторые страны, это называется цифровой колонизацией и стратегией "данные приходят, данные не выходят".
Поэтому и странные фантазии некоторых не-российских политиков про сепаратизм в Российских регионах очень оторван от реальности, цифровая инфраструктура выстраивалась так чтобы эта вероятность была минимальной, а цена запредельной.
Из-за монструозности этих ФГИСов и тем что за каждой из них стоит, как правило, очень крупный системный интегратор и государственный интересант(-ы)/бенефициар(-ы), приводят к тому что они формируют, костяк цифровой системы госуправления, со всеми её плюсами и минусами. Любую из этих систем очень сложно убрать, сложно обслуживать. Любая из них, при неработоспособности, создаёт существенные проблемы для системы госуправления, граждан и/или бизнеса, потому что на них заворачивали большую часть сервисов и функций госорганов. И даже их модернизация, а уж тем более импортозамещение, это очень непростая задача. И по деньгам, и по мотивации интеграторов, и по рискам простоя и тд.
Далее вместо того чтобы писать длинный абзац того к чему всё это идёт, я задам лишь один, возможно, риторический вопрос. И вот где во всём этом место Гостеху?
Ссылки:
[1] https://t.me/begtin/3600
#government #govtech #itmarket
Telegram
Ivan Begtin
По итогам просмотра многих тех материалов ГосТех'а что были в открытом доступе я, пожалуй, могу сформулировать ряд конкретных проблем связанных не только с ним самим, но скорее с тем кто ставит/должен ставить задачи той команде которая им занимается:
- отсутствие…
- отсутствие…
Slack начал (продолжил?) отключать сообщества связанные с Россией. Сегодня прислал уведомление о принудительном закрытии сообщества opendatarussia.slack.com только по той причине что оно было зарегистрировано на адрес электронной почты в зоне .ru
Что тут сказать, хорошо ещё что сообщество оказалось заброшенным и большая часть общения перешла ещё давно в @opendatarussiachat, но в целом всё это конечно мне напоминает историю с тем как для некоммерческих проектов мы использовали французский хостинг Scaleway, а в апреле 2022 они с недельным предупреждением "оплатите или удалим" с пометкой "но мы то знаем что Вы не можете оплатить", просто удалили все наши ресурсы. Хорошо что у нас были резервные копии и такой сценарий просчитывался, но выглядело мягко говоря так себе.
До сих пор мы не все наши некоммерческие проекты @infoculture восстановили поскольку многие из них были в режиме сопровождения уже много лет, а доп ресурсов на них уже не найти.
Также и здесь Slack приравнивает email адреса в зоне .ru к юрисдикции в России и оперирует не санкционными списками, а просто блокировкой всего что с Россией связано.
#opendata #sanctions #slack
Что тут сказать, хорошо ещё что сообщество оказалось заброшенным и большая часть общения перешла ещё давно в @opendatarussiachat, но в целом всё это конечно мне напоминает историю с тем как для некоммерческих проектов мы использовали французский хостинг Scaleway, а в апреле 2022 они с недельным предупреждением "оплатите или удалим" с пометкой "но мы то знаем что Вы не можете оплатить", просто удалили все наши ресурсы. Хорошо что у нас были резервные копии и такой сценарий просчитывался, но выглядело мягко говоря так себе.
До сих пор мы не все наши некоммерческие проекты @infoculture восстановили поскольку многие из них были в режиме сопровождения уже много лет, а доп ресурсов на них уже не найти.
Также и здесь Slack приравнивает email адреса в зоне .ru к юрисдикции в России и оперирует не санкционными списками, а просто блокировкой всего что с Россией связано.
#opendata #sanctions #slack
Rath, свежий инструмент по визуализации данных [1] как альтернатива Tableau, но с открытым кодом. Может оказаться интересной находкой для тех кто вынужден/хочет/планирует мигрировать с проприетарных настольных BI инструментов. Возможностей у него явно поменьше, я, пока его не проверял на собственных больших коллекциях данных, но всё таки открытый код под AGPL лицензией. Разработчики Kanaries [2] явно делают его под венчурное финансирование их облачного продукта и предоставляют открытую и бесплатную версию параллельно.
Ссылки:
[1] https://github.com/Kanaries/Rath
[2] https://kanaries.net/
#opensource #datatools #dataviz #datapreparation #dataanalysis
Ссылки:
[1] https://github.com/Kanaries/Rath
[2] https://kanaries.net/
#opensource #datatools #dataviz #datapreparation #dataanalysis
Свежие новости открытых данных в России - Росимущество удалило все наборы открытых данных со своего сайта. Раздел с открытыми данными более недоступен [1], а ссылки на него с других страниц убраны.
Непонятно когда точно это произошло, потому что в веб-архиве последний раз страница сохранялась 5 февраля 2022 года, а я лично архивировал эти данные в июле 2021 года.
Общий объём публикуемых там данных был около 1ГБ в форме XML файлов 24 наборов данных.
Много это или мало? По сравнению с объёмом данных внутри систем Росимущества - это мало, а по сравнению со многими органами власти - это много. Но теперь нет и этого.
Ссылки։
[1] https://rosim.gov.ru/opendata
#closeddata #russia #government
Непонятно когда точно это произошло, потому что в веб-архиве последний раз страница сохранялась 5 февраля 2022 года, а я лично архивировал эти данные в июле 2021 года.
Общий объём публикуемых там данных был около 1ГБ в форме XML файлов 24 наборов данных.
Много это или мало? По сравнению с объёмом данных внутри систем Росимущества - это мало, а по сравнению со многими органами власти - это много. Но теперь нет и этого.
Ссылки։
[1] https://rosim.gov.ru/opendata
#closeddata #russia #government
Появились первые отчёты о прозрачности [1] корпораций подписавших Европейский Кодекс практик против дезинформации (The Code of Practice on Disinformation) [2].
А это такие компании как Microsoft, Google, Meta, Adobe, Twitter, TikTok и ещё многие другие.
Отчеты, разные по качеству. Короткий отчет от Twitter, к примеру, и подобные отчеты от Google и Microsoft.
Конечно, добровольность кодекса и этих отчетов не означает что отчетам можно безусловно доверять, но хотя бы они показывают какие компании отнеслись серьёзно к этому упражнению, а для каких даже это оказалось сложно.
Кстати, на примере этого кодекса можно не могу не вернуться к вопросу об отечественном кодексе ИИ и его функциональной бесполезности. Если к кодексу ничего не стоит присоединиться и его выполнение никак не мониторится, то и цена ему невелика. В этом смысле европейский кодекс нагляднее, к нему присоединяются только те кто хотя бы готов на регулярной основе добровольно раскрывать информацию о конкретных действиях.
Ссылки:
[1] https://disinfocode.eu/reports-archive/?years=2023
[2] https://disinfocode.eu/introduction-to-the-code/
#privacy #ethics #disinformation #europe #bigtech
А это такие компании как Microsoft, Google, Meta, Adobe, Twitter, TikTok и ещё многие другие.
Отчеты, разные по качеству. Короткий отчет от Twitter, к примеру, и подобные отчеты от Google и Microsoft.
Конечно, добровольность кодекса и этих отчетов не означает что отчетам можно безусловно доверять, но хотя бы они показывают какие компании отнеслись серьёзно к этому упражнению, а для каких даже это оказалось сложно.
Кстати, на примере этого кодекса можно не могу не вернуться к вопросу об отечественном кодексе ИИ и его функциональной бесполезности. Если к кодексу ничего не стоит присоединиться и его выполнение никак не мониторится, то и цена ему невелика. В этом смысле европейский кодекс нагляднее, к нему присоединяются только те кто хотя бы готов на регулярной основе добровольно раскрывать информацию о конкретных действиях.
Ссылки:
[1] https://disinfocode.eu/reports-archive/?years=2023
[2] https://disinfocode.eu/introduction-to-the-code/
#privacy #ethics #disinformation #europe #bigtech
This media is not supported in your browser
VIEW IN TELEGRAM
Весьма любопытная штука trustfall инструмент и язык запросов чтобы делать запросы к, условно, к чему угодно и в комбинациях чего угодно։ базы данных, API, CSV, JSON и тд.
С открытым кодом и с выступлением автора на ту же тему "How to Query (Almost) Everything" [2]
Всё, конечно, не так просто и нужно писать адаптеры для каждого источника данных. Но сам подход автора весьма интересен, для полного счастья не хватает только более подробной спецификации языка запросов, а не только примеров.
Написано на Rust, с интегрированной интеграцией с Python при каждой сборке. Распространяется под Apache лицензией.
Ссылки։
[1] https://github.com/obi1kenobi/trustfall
[2] https://www.hytradboi.com/2022/how-to-query-almost-everything
#datatools #data #opensource
С открытым кодом и с выступлением автора на ту же тему "How to Query (Almost) Everything" [2]
Всё, конечно, не так просто и нужно писать адаптеры для каждого источника данных. Но сам подход автора весьма интересен, для полного счастья не хватает только более подробной спецификации языка запросов, а не только примеров.
Написано на Rust, с интегрированной интеграцией с Python при каждой сборке. Распространяется под Apache лицензией.
Ссылки։
[1] https://github.com/obi1kenobi/trustfall
[2] https://www.hytradboi.com/2022/how-to-query-almost-everything
#datatools #data #opensource
Свежий доклад ОЭСР по инновациям в государстве на 2023 год [1], большой подробный документ со множеством примеров описывающих тренды на 2023 год.
Тренд и тенденции там не то чтобы очевидные, но ожидаемые։
- Тенденция 1: Новые формы подотчетности для новой эры правительства
Алгоритмическая подотчетность
Новые аспекты прозрачности
Институционализация инновационной подотчетности
- Тенденция 2: Новые подходы к уходу
Переориентация (эко)систем ухода
Сочувствие и забота для поддержания психического здоровья
Новые технологии, революционизирующие здравоохранение
- Тенденция 3: Новые методы сохранения самобытности и укрепления равенства
Почитание обществ коренных народов и местных культур
Создание благоприятных условий для семей и общин
Борьба с созданием неполного класса "гиг-экономики"
- Тенденция 4: Новые способы вовлечения граждан и жителей
Децентрализация государственной власти
Перевоплощение сообществ, физически и виртуально
А также четыре вторичных тренда։
- Трансформация государственного управления.
- Новые основы для молодежи и справедливость в отношениях между поколениями.
- Ускорение пути к чистому нулю.
- Укрепление и использование экосистем GovTech.
Там реально много текста, я его дочитал ещё не до конца, но вот несколько тезисов могу сформулировать уже сейчас։
1. Явный тренд на усиление госрегулирования применения ИИ, как в государственных задачах, так и в частных. Тренд явный, проявляющийся во всех развитых странах. Активно закрепляется законодательно. Всё это подаётся примерами по многим странам больших факапов сделанных алгоритмическими системами.
2. Если случится чудо и Россия снова когда-либо сможет подать заявку на участие в ОЭСР, то внезапно(!) окажется что российский Гостех от мирового GovTech отличается как небо и земля. В материалах ОЭСР / GovTech - это экосистема, в которой правительства сотрудничают со стартапами, МСП и другими участниками, использующими интеллектуальные данные, цифровые технологии и инновационные методы. Методологии для предоставления продуктов и услуг для решения общественных проблем. Они предлагают
новые формы государственно-частного партнерства для освоения цифровых инноваций и анализа данных с целью повышения эффективности, результативности и прозрачности предоставления государственных услуг. / [2]. И все примеры докладе описывают GovTech как стартапы создающие инновационные решения для госорганов.
3. Отдельная тема - инкубаторы подотчетности, это специальные проекты по прокачке граждан в борьбе с коррупцией. Тоже часть государственных инициатив в ряде стран.
4. Много примеров проектов развития культурных инициатив через открытость знаний, кода и данных. Многие из них такие что просто "бери и воспроизводи"․
И там ещё много всего, я до конца пока ещё дочитываю, определённо через какое-то время напишу про некоторые интересные примеры оттуда по работе с данными и не только.
Ссылки։
[1] https://oecd-opsi.org/publications/trends-2023/
[2] http://scioteca.caf.com/handle/123456789/1580
#government #opendata #openness #opengov #oecd #govtech
Тренд и тенденции там не то чтобы очевидные, но ожидаемые։
- Тенденция 1: Новые формы подотчетности для новой эры правительства
Алгоритмическая подотчетность
Новые аспекты прозрачности
Институционализация инновационной подотчетности
- Тенденция 2: Новые подходы к уходу
Переориентация (эко)систем ухода
Сочувствие и забота для поддержания психического здоровья
Новые технологии, революционизирующие здравоохранение
- Тенденция 3: Новые методы сохранения самобытности и укрепления равенства
Почитание обществ коренных народов и местных культур
Создание благоприятных условий для семей и общин
Борьба с созданием неполного класса "гиг-экономики"
- Тенденция 4: Новые способы вовлечения граждан и жителей
Децентрализация государственной власти
Перевоплощение сообществ, физически и виртуально
А также четыре вторичных тренда։
- Трансформация государственного управления.
- Новые основы для молодежи и справедливость в отношениях между поколениями.
- Ускорение пути к чистому нулю.
- Укрепление и использование экосистем GovTech.
Там реально много текста, я его дочитал ещё не до конца, но вот несколько тезисов могу сформулировать уже сейчас։
1. Явный тренд на усиление госрегулирования применения ИИ, как в государственных задачах, так и в частных. Тренд явный, проявляющийся во всех развитых странах. Активно закрепляется законодательно. Всё это подаётся примерами по многим странам больших факапов сделанных алгоритмическими системами.
2. Если случится чудо и Россия снова когда-либо сможет подать заявку на участие в ОЭСР, то внезапно(!) окажется что российский Гостех от мирового GovTech отличается как небо и земля. В материалах ОЭСР / GovTech - это экосистема, в которой правительства сотрудничают со стартапами, МСП и другими участниками, использующими интеллектуальные данные, цифровые технологии и инновационные методы. Методологии для предоставления продуктов и услуг для решения общественных проблем. Они предлагают
новые формы государственно-частного партнерства для освоения цифровых инноваций и анализа данных с целью повышения эффективности, результативности и прозрачности предоставления государственных услуг. / [2]. И все примеры докладе описывают GovTech как стартапы создающие инновационные решения для госорганов.
3. Отдельная тема - инкубаторы подотчетности, это специальные проекты по прокачке граждан в борьбе с коррупцией. Тоже часть государственных инициатив в ряде стран.
4. Много примеров проектов развития культурных инициатив через открытость знаний, кода и данных. Многие из них такие что просто "бери и воспроизводи"․
И там ещё много всего, я до конца пока ещё дочитываю, определённо через какое-то время напишу про некоторые интересные примеры оттуда по работе с данными и не только.
Ссылки։
[1] https://oecd-opsi.org/publications/trends-2023/
[2] http://scioteca.caf.com/handle/123456789/1580
#government #opendata #openness #opengov #oecd #govtech
Observatory of Public Sector Innovation
Global Trends in Government Innovation 2023 - Observatory of Public Sector Innovation
In the face of what has increasingly been referred to as an ongoing “permacrisis”, governments must cope with and respond to emerging threats while already grappling with longstanding issues such as climate change, digital disruption and low levels of trust.…
Свежий обзор европейских зарплат специалистов по данным - аналитики, дата-сайентисты и дата-инженеры на 2023 год [1] на оснований 500 объявлений о работе для специалистов в Европе.
Любопытные выводы։
1. Зарплаты в Берлине ниже чем в Лондоне или Дублине и в Германии, в принципе, зарплаты ниже.
2.Крупные бигтех компании в Европе платят больше других
3. Разница в средней годовой зарплате джунов ($70k) и миддлов ($83k) не так уже велика. Хотя лично меня удивляют такие зарплаты джунов в Европе, в России, к примеру, они резко отличаются. Конкуренция и квалификация у джунов невелика сейчас из-за безумного числа плохих ИТ курсов.
Ссылки։
[1] https://www.synq.io/blog/europe-data-salary-benchmark-2023
#europe #itmarket
Любопытные выводы։
1. Зарплаты в Берлине ниже чем в Лондоне или Дублине и в Германии, в принципе, зарплаты ниже.
2.Крупные бигтех компании в Европе платят больше других
3. Разница в средней годовой зарплате джунов ($70k) и миддлов ($83k) не так уже велика. Хотя лично меня удивляют такие зарплаты джунов в Европе, в России, к примеру, они резко отличаются. Конкуренция и квалификация у джунов невелика сейчас из-за безумного числа плохих ИТ курсов.
Ссылки։
[1] https://www.synq.io/blog/europe-data-salary-benchmark-2023
#europe #itmarket
Когда я регулярно рассказываю о том как устроены порталы открытых данных в мире и раскрытие данных в принципе, то регулярно пишу о том что многие из этих проектов находятся в весьма запущенном состоянии или изначально создавались скорее как имитация для международных рейтингов чем полноценной работы. В некоторых случаях, как, например, в Казахстане портал открытых данных [1] таковым в принципе не является поскольку для доступа к данным необходим ИИН и авторизация через местный сервис гарантированной идентификации человека. Иначе говоря, ни открытости, ни машиночитаемости тут полноценной нет.
Значит ли это что открытых данных нет? Скажем так, нет данных которое бы правительство РК по своей инициативе, целенаправленно, с диалогом с обществом, публиковало бы под свободными лицензиями. Но это не значит что общедоступные данные органов власти не публикуются в машиночитаемом виде. Конечно же, как и в большинстве развитых и развивающихся, но не беднейших стран, данные публикуются. Чаще больше и удобнее чем на портале открытых данных.
Например։
- открытое API системы государственной статистики ТАЛДАУ [2]. Это API к базе статистических показателей, в документации указано что данные возвращаются в XML, по факту в XML и JSON и также присутствуют недокументированные точки доступа к API. Не требует авторизации
- недокументированное API на сайте Правительства РК www.gov.kz. Я писал о нём ранее [3], там есть и REST API, и точка подключения Graphql. Также не требует авторизации, позволяет получать все материалы с сайта в машиночитаемом формате
- многочисленные сервисы геопорталов на базе ArcGIS, например, gis.geology.gov.kz [4] и ещё многих других
Я большого секрета не открою сказав что у информационных систем министерств в РК открытых API не меньше чем, к примеру, в России. При желании и небольших усилиях можно хоть самостоятельно сделать аналог портала открытых данных страны с большим объёмом данных и большей открытостью (да просто без авторизации!).
Создатели порталов открытых данных внутри гос-ва не всегда понимают что по сути каждый такой портал - это систематизация уже имеющегося. Это организационно-техническая задача по систематизации существующих государственных дата-продуктов. Иногда, да, она сопряжена с задачей по оцифровке данных и переводу неструктурированной информации в машиночитаемую форму, но даже просто взять и систематизировать имеющиеся данные органов власти опубликованные и общедоступные - это самое простое и очевидное.
Но, конечно, не снижая доступности данных, наоборот повышая их находимость. Лучшие примеры такого подхода сейчас есть в Австралии, Франции, США и многих европейских странах.
Казахстан - это лишь как пример одной из наиболее технологически развитых стран на пост-советском пространстве. Похожая ситуация повсеместна, технологии меняются, разработчики делают API, открывают данные отдельных информационных систем потому что так просто _значительно удобнее_ работать с технически квалифицированными потребителями.
Ссылки:
[1] https://data.gov.kz
[2] https://taldau.stat.gov.kz/ru/Api/Dev
[3] https://t.me/begtin/4380
[4] https://gis.geology.gov.kz/arcgis/rest/services
#opendata #opengov #kazakhstan #government
Значит ли это что открытых данных нет? Скажем так, нет данных которое бы правительство РК по своей инициативе, целенаправленно, с диалогом с обществом, публиковало бы под свободными лицензиями. Но это не значит что общедоступные данные органов власти не публикуются в машиночитаемом виде. Конечно же, как и в большинстве развитых и развивающихся, но не беднейших стран, данные публикуются. Чаще больше и удобнее чем на портале открытых данных.
Например։
- открытое API системы государственной статистики ТАЛДАУ [2]. Это API к базе статистических показателей, в документации указано что данные возвращаются в XML, по факту в XML и JSON и также присутствуют недокументированные точки доступа к API. Не требует авторизации
- недокументированное API на сайте Правительства РК www.gov.kz. Я писал о нём ранее [3], там есть и REST API, и точка подключения Graphql. Также не требует авторизации, позволяет получать все материалы с сайта в машиночитаемом формате
- многочисленные сервисы геопорталов на базе ArcGIS, например, gis.geology.gov.kz [4] и ещё многих других
Я большого секрета не открою сказав что у информационных систем министерств в РК открытых API не меньше чем, к примеру, в России. При желании и небольших усилиях можно хоть самостоятельно сделать аналог портала открытых данных страны с большим объёмом данных и большей открытостью (да просто без авторизации!).
Создатели порталов открытых данных внутри гос-ва не всегда понимают что по сути каждый такой портал - это систематизация уже имеющегося. Это организационно-техническая задача по систематизации существующих государственных дата-продуктов. Иногда, да, она сопряжена с задачей по оцифровке данных и переводу неструктурированной информации в машиночитаемую форму, но даже просто взять и систематизировать имеющиеся данные органов власти опубликованные и общедоступные - это самое простое и очевидное.
Но, конечно, не снижая доступности данных, наоборот повышая их находимость. Лучшие примеры такого подхода сейчас есть в Австралии, Франции, США и многих европейских странах.
Казахстан - это лишь как пример одной из наиболее технологически развитых стран на пост-советском пространстве. Похожая ситуация повсеместна, технологии меняются, разработчики делают API, открывают данные отдельных информационных систем потому что так просто _значительно удобнее_ работать с технически квалифицированными потребителями.
Ссылки:
[1] https://data.gov.kz
[2] https://taldau.stat.gov.kz/ru/Api/Dev
[3] https://t.me/begtin/4380
[4] https://gis.geology.gov.kz/arcgis/rest/services
#opendata #opengov #kazakhstan #government
Telegram
Ivan Begtin
Я регулярно писал о том что в России много открытых и общедоступных данных гос-ва через открытые API, нигде не документированные, но существующие [1]. Но это, конечно же, не только российская специфика и очень многие сайты создаются по архитектуре Jamstack…
Я тут из-за вынужденной паузы в работе, слегка приболел, и увлёкся чтением художественной литературы. Так что прочитал выложенные на днях
Методрекомендации Минцифры по управлению данными ГИСов на Гостех (оригинальное название звучит совсем вычурно). Чтение оказалось скорее бульварным чем художественным. Для концептуального документа в нём нет ни одного пояснения почему, зачем, и как авторы этих рекомендаций к ним пришли. Не говоря уже о том что базовые принципы управления данными совершенно точно отделены от всей инициативы под названием ГосТех. А для практического документа там нет привязки к инструментам которые на сегодняшний день в ГосТехе и вообще в Минцифре есть. Иначе говоря уровень абстракции там такой что, ни смысловой, ни практической пользы нет. Отдельная история с иерархией управления данными, по этим метод рекомендациям в каждом органе власти должен быть директор по данным который со всей своей командой в иерархии должен подчиняться Управлению данными Минцифры. Довольно экзотическая модель управления, она должна понравится Минцифре и что-то я не представляю как она может понравится ФОИВам и другим органам власти.
Я лично очень рад что сам не принимал участие в "экспертном обсуждении" вот этого вот, потому что за всё время разговоров вокруг Гостеха в РФ я не увидел ни одного вменяемого документа.
Сам документ этих методрекомендаций, если кто-то их ещё не видел, я выложил в чат.
#data #government #regulation
Методрекомендации Минцифры по управлению данными ГИСов на Гостех (оригинальное название звучит совсем вычурно). Чтение оказалось скорее бульварным чем художественным. Для концептуального документа в нём нет ни одного пояснения почему, зачем, и как авторы этих рекомендаций к ним пришли. Не говоря уже о том что базовые принципы управления данными совершенно точно отделены от всей инициативы под названием ГосТех. А для практического документа там нет привязки к инструментам которые на сегодняшний день в ГосТехе и вообще в Минцифре есть. Иначе говоря уровень абстракции там такой что, ни смысловой, ни практической пользы нет. Отдельная история с иерархией управления данными, по этим метод рекомендациям в каждом органе власти должен быть директор по данным который со всей своей командой в иерархии должен подчиняться Управлению данными Минцифры. Довольно экзотическая модель управления, она должна понравится Минцифре и что-то я не представляю как она может понравится ФОИВам и другим органам власти.
Я лично очень рад что сам не принимал участие в "экспертном обсуждении" вот этого вот, потому что за всё время разговоров вокруг Гостеха в РФ я не увидел ни одного вменяемого документа.
Сам документ этих методрекомендаций, если кто-то их ещё не видел, я выложил в чат.
#data #government #regulation
Forwarded from Инфокультура
Присоединяйтесь ко Дню открытых данных 2023!
4 марта 2023 года состоится ежегодный День открытых данных — онлайн!
Приглашаем разработчиков, ИТ-специалистов, дата-журналистов, гражданских активистов и других участников российского движения открытости. Некоторые темы выступлений:
— Как искать данные с помощью каталогов данных. Проект datacatalogs.ru.
— Если быть точным в 2022 году: доступны ли данные по социальным проблемам.
— Мастер-класс «Визуализация открытых геоданных Москвы для медиа и соцсетей».
— Мастер-класс «Как мы визуализируем гео-данные в "билайне": от кейсов к практике».
Слушайте доклады, принимайте участие в мастер-классах и становитесь частью движения, создавая и продвигая открытые данные в своей деятельности!
Программа мероприятия и регистрация уже доступны по ссылке: https://opendataday.ru/msk
#ODD2023 #OpenDataDay #OpenData
4 марта 2023 года состоится ежегодный День открытых данных — онлайн!
Приглашаем разработчиков, ИТ-специалистов, дата-журналистов, гражданских активистов и других участников российского движения открытости. Некоторые темы выступлений:
— Как искать данные с помощью каталогов данных. Проект datacatalogs.ru.
— Если быть точным в 2022 году: доступны ли данные по социальным проблемам.
— Мастер-класс «Визуализация открытых геоданных Москвы для медиа и соцсетей».
— Мастер-класс «Как мы визуализируем гео-данные в "билайне": от кейсов к практике».
Слушайте доклады, принимайте участие в мастер-классах и становитесь частью движения, создавая и продвигая открытые данные в своей деятельности!
Программа мероприятия и регистрация уже доступны по ссылке: https://opendataday.ru/msk
#ODD2023 #OpenDataDay #OpenData
opendataday.ru
День открытых данных 2024
Присоединяйтесь к нам, чтобы отметить силу открытых данных и их потенциал для позитивных изменений в мире! #OpenDataDay #ODD2023 #BetterTogetherThanAlone
Можно дискутировать остались ли в России открытые данные или нет. Многие, включая меня, считают что открытость сейчас под большим вопросом, другие удивляются что вообще хоть какие-то данные доступны.
Тем временем у федерального портала открытых данных data.gov.ru просрочен сертификат. Удивительно ли это ? Нет, Минэкономразвития РФ довольно сильно запустило портал, сейчас он забит бесконечным объёмом микро-файлов. Но тут важнее то что на портал просто забили, даже не отслеживая протухание сертификата.
Впрочем это не единственная проблема с этим сайтом. Например, поломался экспорт реестра наборов данных [1].
Впрочем, как я уже говорил ранее, даже если сертификат исправят и экспорт данных вылечат, фундаментальной проблемы плохой работы этого портала это не решит.
Ссылки:
[1] https://data.gov.ru/opendata/export/csv
#opendata #russia #government #opengov #closeddata
Тем временем у федерального портала открытых данных data.gov.ru просрочен сертификат. Удивительно ли это ? Нет, Минэкономразвития РФ довольно сильно запустило портал, сейчас он забит бесконечным объёмом микро-файлов. Но тут важнее то что на портал просто забили, даже не отслеживая протухание сертификата.
Впрочем это не единственная проблема с этим сайтом. Например, поломался экспорт реестра наборов данных [1].
Впрочем, как я уже говорил ранее, даже если сертификат исправят и экспорт данных вылечат, фундаментальной проблемы плохой работы этого портала это не решит.
Ссылки:
[1] https://data.gov.ru/opendata/export/csv
#opendata #russia #government #opengov #closeddata
Недавно я писал про подход к переосмыслению работы с любыми унаследованными продуктами/протоколами как "всё SQL" [1]. Иногда такой подход осуществлять сложно, иногда очевидно, а вот подборка примеров когда это работает и работает успешно․
- textql [2] - утилита и библиотека на Go по работе с файлами CSV и TSV так словно это SQL таблицы. Поддерживает практически полностью синтаксис SELECT запросов.
- gitql [3] - инструмент на Go для работы с Git как с базой данных SQL. Поддерживает все хранимые в Git объекты, лог и работает в режиме только для чтения.
- q - Text as Data [4] - инструмент работы с CSV и TSV как с SQL, но написанный на Python. Также поддерживает сразу множество sqlite баз данных.
- dockersql [5] - база контейнеров для Docker как SQL, тоже на Go написано, не обновлялось уже 9 лет, но как proof-of-concept интересно. Работает поверх API Docker'а
- Yahoo! Query Language (YQL) [6] универсальный SQL-подобный язык запросов к API и CSV, RSS и другим файлам. На сайте Yahoo! его более нет, осталась только страница в Википедии и рассеянные по интернету примеры
Наверняка есть и больше примеров. В некоторых случаях это оказывается совершенно оправдано, textql, к примеру, удобный инструмент для тех кто работает с CSV файлами часто и сложным образом. Можно ли через призму этого сделать инструменты SQL для IMAP4 или SQL для FTP или SQL для файловой системы (уже есть, кстати) и иначе? Конечно возможно!
Ссылки։
[1] https://t.me/begtin/4613
[2] https://github.com/dinedal/textql
[3] https://github.com/filhodanuvem/gitql
[4] https://github.com/harelba/q
[5] https://github.com/crosbymichael/dockersql
[6] https://en.wikipedia.org/wiki/Yahoo!_Query_Language
#opensource #datatools #queryengines #sql
- textql [2] - утилита и библиотека на Go по работе с файлами CSV и TSV так словно это SQL таблицы. Поддерживает практически полностью синтаксис SELECT запросов.
- gitql [3] - инструмент на Go для работы с Git как с базой данных SQL. Поддерживает все хранимые в Git объекты, лог и работает в режиме только для чтения.
- q - Text as Data [4] - инструмент работы с CSV и TSV как с SQL, но написанный на Python. Также поддерживает сразу множество sqlite баз данных.
- dockersql [5] - база контейнеров для Docker как SQL, тоже на Go написано, не обновлялось уже 9 лет, но как proof-of-concept интересно. Работает поверх API Docker'а
- Yahoo! Query Language (YQL) [6] универсальный SQL-подобный язык запросов к API и CSV, RSS и другим файлам. На сайте Yahoo! его более нет, осталась только страница в Википедии и рассеянные по интернету примеры
Наверняка есть и больше примеров. В некоторых случаях это оказывается совершенно оправдано, textql, к примеру, удобный инструмент для тех кто работает с CSV файлами часто и сложным образом. Можно ли через призму этого сделать инструменты SQL для IMAP4 или SQL для FTP или SQL для файловой системы (уже есть, кстати) и иначе? Конечно возможно!
Ссылки։
[1] https://t.me/begtin/4613
[2] https://github.com/dinedal/textql
[3] https://github.com/filhodanuvem/gitql
[4] https://github.com/harelba/q
[5] https://github.com/crosbymichael/dockersql
[6] https://en.wikipedia.org/wiki/Yahoo!_Query_Language
#opensource #datatools #queryengines #sql
Telegram
Ivan Begtin
Я ранее рассказывал про разные эксперименты в обработке данных, например, про обработку данных в NoSQL базах данных и про экспериментальную библиотеку mongorefine [1].
Когда-то из других экспериментов у меня получилась библиотека по автоматизации извлечения…
Когда-то из других экспериментов у меня получилась библиотека по автоматизации извлечения…
В рубрике интересных открытых проектов Civitai [1] сообщество в котором пользователи делятся предобученными моделями для Stable Diffusion по генерации изображений самого разного типа։ людей, природы, предметов и многого другого.
Жанров много, но, что неудивительно, более всего моделей по генерации самой разнообразной эротики (на примеры ссылки давать не буду), что подталкивает к мысли что самое перспективное направление развития генеративного ИИ сейчас будет персонализированные услуги генерации изображений и видео для индустрии эротики и порнографии.
Впрочем, более невинного применения этому тоже немало и примеров подобного также немало.
Всего более 11 тысяч моделей, пока каждой из которых есть примеры изображений и файлы данных самой модели.
Проект с открытым кодом [2] и открытым API [3]
Ссылки։
[1] https://civitai.com
[2] https://github.com/civitai/civitai
[3] https://github.com/civitai/civitai/wiki/REST-API-Reference
#opendata #openapi #opensource #ai #generativeai
Жанров много, но, что неудивительно, более всего моделей по генерации самой разнообразной эротики (на примеры ссылки давать не буду), что подталкивает к мысли что самое перспективное направление развития генеративного ИИ сейчас будет персонализированные услуги генерации изображений и видео для индустрии эротики и порнографии.
Впрочем, более невинного применения этому тоже немало и примеров подобного также немало.
Всего более 11 тысяч моделей, пока каждой из которых есть примеры изображений и файлы данных самой модели.
Проект с открытым кодом [2] и открытым API [3]
Ссылки։
[1] https://civitai.com
[2] https://github.com/civitai/civitai
[3] https://github.com/civitai/civitai/wiki/REST-API-Reference
#opendata #openapi #opensource #ai #generativeai
Свежая схема THE 2023 MAD (MACHINE LEARNING, ARTIFICIAL INTELLIGENCE & DATA) LANDSCAPE [1] в виде PDF файла и в интерактивном режиме. Выглядит любопытно, особенно интерактивная версия [2] поскольку в ней есть ссылки и дополнительная информация о продуктах.
При этом, скажу честно, я лично уже порядком устал смотреть на такие картинки, они пухнут год от года, реальной картины не дают, а скорее создают некий визуальный антураж структуре рынка.
Можно ли делать похожее по смыслу, но приятнее визуально? вот в чём вопрос.
Ссылки։
[1] https://mattturck.com/mad2023/
[2] https://mad.firstmarkcap.com/
#datamarket #datatools #dataproducts #visual
При этом, скажу честно, я лично уже порядком устал смотреть на такие картинки, они пухнут год от года, реальной картины не дают, а скорее создают некий визуальный антураж структуре рынка.
Можно ли делать похожее по смыслу, но приятнее визуально? вот в чём вопрос.
Ссылки։
[1] https://mattturck.com/mad2023/
[2] https://mad.firstmarkcap.com/
#datamarket #datatools #dataproducts #visual
В рубрике как это работает у них портал открытых данных Шанхая (Китай) data.sa.gov.cn [1]. Я ранее уже рассказывал об открытых данных в Китае, но не рассказывал именно про этот портал.
Первая особенность портала в большом объёме данных. На нём опубликовано 4490 наборов данных. Это довольно много даже для национальных порталов открытых данных, а тут портал только города. Впрочем города с 25 миллионами населения, что немало.
Почти все данные публикуются в форме данных для структурированного хранилища и экспортируются сразу в форматах XML, XLS, JSON, CSV и RDF. По поводу RDF сразу те же сомнения что с порталом открытых данных Узбекистана, никакой привязки к онтологиям нет - это, конечно, минус.
Плюс - объём данных и частота обновления. 929 наборов данных предоставляются через API и обновляются ежесуточно.
Для полноты картины осталось посмотреть на их инструкции для разработчиков.
Ссылки:
[1] https://data.sh.gov.cn
[2] https://t.me/begtin/4470
#opendata #dataportals #china #shanghai
Первая особенность портала в большом объёме данных. На нём опубликовано 4490 наборов данных. Это довольно много даже для национальных порталов открытых данных, а тут портал только города. Впрочем города с 25 миллионами населения, что немало.
Почти все данные публикуются в форме данных для структурированного хранилища и экспортируются сразу в форматах XML, XLS, JSON, CSV и RDF. По поводу RDF сразу те же сомнения что с порталом открытых данных Узбекистана, никакой привязки к онтологиям нет - это, конечно, минус.
Плюс - объём данных и частота обновления. 929 наборов данных предоставляются через API и обновляются ежесуточно.
Для полноты картины осталось посмотреть на их инструкции для разработчиков.
Ссылки:
[1] https://data.sh.gov.cn
[2] https://t.me/begtin/4470
#opendata #dataportals #china #shanghai