7027
I write about Open Data, Procurement, e-Government, Open Government, Budgets, Privacy and other govtech stuff Chat https://telegram.me/begtinchat Facebook - https://facebook.com/ibegtin Secure contacts ivan@begtin.tech
Закрывается Flibusta [1], независимый библиотечный ресурс, через несколько недель может прекратить свое существование. Причина - рак у его создателя и администратора.
Совершенно точно у книг Flibusta есть множество архивных копий на торрентах, но эти архивные копии не включают обсуждений, материалов форумов, иных текстов с сайтов, не относящихся к книгам.
Кроме того в торрент трекерах книги, или обновлениями за период, или полным дампом, что усложнит чтение тем кому нужна не библиотека целиком, а собственный список для чтения. Имеет смысл сохранить книги которые Вы читаете заранее.
Ссылки:
[1] https://flibusta.is/node/681117
#digitalpreservation #books #flibusta
Помучавшись немного с геоклассификацией объектов, в данном случае наборов данных, и решив эту задачу грубо, я в процессе набросал примерную структуру программного инструмента который помогал бы решать её красиво.
Не знаю когда у меня дойдут руки до того чтобы это сделать и дойдут ли вообще, работы технической, организационной и только как-то ну очень много и это хорошо:) Но если кто-то захочет такое реализовать, то может быть эта схема поможет.
Задача то довольно простая, присвоение цифровым объектам геолокации не по принципу координат или адреса, а в привязке к территории от макрорегиона/группы стран, до конкретного города/территории субрегионального уровня. В Dateno это делается через привязку всего к справочникам UN M49, ISO3166-1 и ISO3166-2. Сложности возникают в том что в каталогах данных где есть геоаннотирование чаще всего нет уникальных кодов территорий и чаще всего названия макрорегионов, к примеру, не гармонизированы.
А потребность в аннотировании есть не только к датасетам, но и ко множеству других объектов: тексты, архивы, документы, изображения и тд.
#thoughts #modelling #geospatial
Вышла бета версия германской статистической системы GENESIS-Online используемой статслужбой страны для публикации индикаторов [1]. В целом удобно, но скорее консервативно чем современно.
Из плюсов:
- есть API
- есть выгрузка в CSV/XLSX
- всё достаточно быстро и удобно
Из минусов:
- документированное API требует регистрации и авторизации, недокументированное... недокументировано
- документированное API сделано предоставляет SOAP интерфейс, непонятно зачем в 2024 году
- нет поддержки SDMX
- нет массовой выгрузки, bulk download
В целом, это скорее даже удивительно насколько статистика ЕС удобнее в работе чем статистика Германии, по крайней мере инструментально.
Ссылки:
[1] https://www-genesis.destatis.de/datenbank/beta
#opendata #statistics #germany #datacatalogs #indicators
Давно пишу по кусочкам лонгрид про природу данных и наборов данных, про то как отличается их восприятие людьми разных профессий и потребностей и как от того где они применяются "плавает" это определение.
Самый простой пример - это всегда ли данные машиночитаемы? К примеру, данные в виде файлов csv, json, xml и тд. всегда можно рассматривать как машиночитаемые, а, к примеру, тексты, видео и изображения нет. Но если собрать тысячи, сотни тысяч текстов или фотографий, то вот, пожалуйста, датасет для обучения в data science. То есть данные не всегда машиночитаемы?
Другой пример, конфигурационные файлы приложений распространённо имеют машиночитаемые форматы как раз те же самые json, xml, yaml и ряд других. Делает ли это их наборами данных? Вообще-то нет, потому что не прослеживается модели их повторного использования.
Может быть именно повторное использование и востребованность тогда является главным критерием определения набора данных? В классических определениях набора данных это, или набор таблиц, или единица измерения информации опубликованной в открытом доступе.
А как рассматривать API? К примеру, в геоданных массово данные доступны не в виде файлов, а в виде API по стандартам OGC или ряду проприетарных. Их принято относить к наборам данных. Но там разные API, к примеру, WFS, WMS без сомнений можно относить к data api (API для доступа к данным), а какие-нибудь WPS уже точно не data api, а процессные API для обработки данных, а WCS что ближе к не API для данных, с помогающих в работе с геоинструментами. Для аудитории специалистов по геоанализу они нужны, но как бы не данные.
В научной среде репозитории данных очень часто совмещены с репозиториями ПО, во всяком случае для репозиториев общего типа. Главная идея тут в том что без ПО, причём конкретной версии, сложно повторить эксперимент/процессы в результате которых были данные получены.
Ещё пример, опять же про не машиночитаемость. С точки зрения архивации данных важно хранить данные в любой форме за условно любой период времени. К примеру, статистический сборник 19го века. Формально не машиночитаем, по факту исследователям статистикам может быть нужен? Безусловно. На многих порталах открытых данных опубликованы тысячи таких сборников как открытые данные. Но они не машиночитаемые. В такой логике к, примеру, Библиотека конгресса США или Национальная электронная библиотека в РФ это тоже каталоги данных? Или источники данных? Даже если они не машиночитаемы?
Всё это возвращает к размышлениям о том что наборы данных - это то о чём можно говорить как об опубликованным со смыслом (publish with the purpose), с пониманием аудитории и хотя бы одного сценария их применения.
В практическом применении это напрямую затрагивает, например, то какие данные индексируют и не индексируют поисковые системы. К примеру, Google Dataset Search не индексирует геоданные, они медленно, то уверенно склоняются к поисковику для исследователей. Научные поисковики вроде OpenAIRE, DataCite или BASE с самого начала декларируют что это не только поиск по данным, а по любым результатам научной деятельности до которых просто дотянутся. Для data science поисковика нет поскольку всего два основных ресурса, Hugging Face и Kaggle.
В Dateno индексируются геоданные (гео API) и порталы индикаторов причём с расширенной трактовкой индикаторов как то что датасетом является индикатор + страна во всех случаях когда можно сделать постоянную ссылку на файл или API. Так делают многие создатели этих порталов с индикаторами уже давно. Но это тоже некая форма интерпретации исходя из потребности и поиска пользователей.
Всё это, отчасти, философский вопрос о том строить ли поисковую систему по данным или поисковую систему для тех кто работает с данными. Разница между двумя этими понятиями весьма существенна. И поэтому она начинается с собственного определения того что такое набор данных
#thoughts #data #datasets
Полезные ссылки про данные, технологии и не только:
- Governing data products using fitness functions [1] полезная статья с определением того что такое Data Product и как ими управлять, в первую очередь с архитектурной точки зрения.
- UIS Data Browser [2] новый каталог данных (статистики) ЮНЕСКО, данных немного, но есть API и массовая выгрузка.
- Why is language documentation still so terrible? [3] гневная статья где автор ругает все языки программирования кроме Rust. Претензий много и я с ним согласен и не только в отношении языков. Хорошую документацию на SDK или open source продукты встретишь нечасто.
- How We Made PostgreSQL Upserts 300x Faster on Compressed Data [4] про оптимизацию загрузки данных в PostgreSQL с помощью TimescaleDB, лично я не видел этот движок в работе, но для каких-то задач он может быть именно тем что нужно
- ImHex [5] шестнадцатеричный редактор с открытым кодом для реверс инжиниринга. На мой взгляд мало что заменит IDA Pro, но для задач не требующих хардкора и когда нет денег вполне себе полезный инструмент.
Ссылки:
[1] https://martinfowler.com/articles/fitness-functions-data-products.html#ArchitecturalCharacteristicsOfADataProduct
[2] https://databrowser.uis.unesco.org/
[3] https://walnut356.github.io/posts/language-documentation/
[4] https://www.timescale.com/blog/how-we-made-postgresql-upserts-300x-faster-on-compressed-data/
[5] https://github.com/WerWolv/ImHex
#opensource #data #datacatalogs #documentation #dbs
В рубрике как это устроено у них Indian Data Portal [1] портал открытых данных созданный Bharti Institute of Public Policy, индийским исследовательским центром в области публичной политики.
Интересен тем что работает на собственном движке поверх каталога открытых данных CKAN. Сами данные хранятся в связанном с ним каталогом данных [2], а основной веб сайт использует API каталога данных для создания дополнительных фильтров при поиске данных, таких как гранулярность, сектор экономики, источник данных, частота обновления.
Данные исследователям доступны после авторизации и, в принципе, именно они являются аудиторией этого портала.
Это пример, использования CKAN как Data Management System (DMS), многие порталы данных в мире создавались по той же модели, когда CKAN используется как хранилище метаданных и данных, а над ним строятся разные интерфейсы.
Ссылки:
[1] https://indiadataportal.com/
[2] https://ckan.indiadataportal.com/
#opendata #datacatalogs #datasets #india
В рубрике больших интересных наборов данных Global Biodiversity Data [1] набор открытых данных по биоразнообразию собранный из нескольких научных работ и опубликованный в каталоге данных Всемирного банка.
Датасет относительно небольшой, около 2.2 ГБ в сжатом виде и содержит георазмеченные сведения по встречаемости различных видов.
О нём в августе писали в блоге Всемирного банка [2] и датасет полезен всем кто хочет изучить животный и растительный мир своей страны. Буквально годится для работы школьников на хакатонах например, но язык только английский.
Ссылки:
[1] https://datacatalog.worldbank.org/search/dataset/0066034/global_biodiversity_data
[2] https://blogs.worldbank.org/en/opendata/a-new-world-bank-database-to-support-a-new-era-in-biodiversity-c
#opendata #datasets #worldbank #biodiversity
В рубрике популярных каталогов данных OpenSDG [1] просто ПО с открытым кодом используемое статистическими службами многих стран для публикации индикаторов устойчивого развития.
Особенность OpenSDG в том что это открытый код [2] профинансированный статслужбами Великобритании и США и разработанный в CODE [3], The Center for Open Data Enterprise.
Из-за простоты и бесплатности его как раз и используют, например, статслужба Армении [4], Конго [5], Великобритании [6] и ещё пара десятков стран и множество городов [7].
OpenSDG нельзя назвать полноценным порталом данных, скорее порталом индикаторов. Причём без стандартизированного API, но со стандартизированной выгрузкой всех индикаторов целиком и некоторым псевдо API для доступа к данным индикаторов.
Ссылки:
[1] https://open-sdg.org
[2] https://github.com/open-sdg/open-sdg
[3] https://www.opendataenterprise.org/
[4] https://sdg.armstat.am
[5] https://odd-dashboard.cd
[6] https://sdgdata.gov.uk
[7] https://open-sdg.org/community
#opendata #datacatalogs #opensdg #statistics
NASA Space Apps Challenge 2024 [1] проходит в этом году по всему миру и включает множество локальных мероприятий, в том числе на постсоветском пространстве, за исключением России, Беларуси, Киргизии и Армении [2]. Почему не проходят в Киргизии я не знаю, удивительно что нет в Армении, чувствую надо было самим организовать, а не думать что кто-то из околокосмической тусовки это сделает.
У НАСА на хакатоне есть набор задач [3], большая часть которых связаны с данными, например, по задаче Landsat Reflectance Data: On the Fly and at Your Fingertips, множество ссылок на открытые данные в KML, Shapefile и других [4].
Для тех кто учится и находится в странах где есть местные события этого глобального хакатона - это отличная возможность потренировать навыки в работе с данными и сделать что-то полезное.
Ссылки:
[1] https://www.spaceappschallenge.org/nasa-space-apps-2024/
[2] https://www.spaceappschallenge.org/nasa-space-apps-2024/2024-local-events/
[3] https://www.spaceappschallenge.org/nasa-space-apps-2024/challenges/
[4] https://www.spaceappschallenge.org/nasa-space-apps-2024/challenges/landsat-reflectance-data-on-the-fly-and-at-your-fingertips/?tab=resources
#opendata #hackathons #space #nasa
В рубрике как это устроено у них, поисковик по биомедицинским датасетам DataMed [1], создан в Университете Калифорнии, Сан Диего, на грант 10 миллионов USD [2] от Национального института здравоохранения США и других грантодающих организаций.
С одной стороны, это действительно поисковик, с 49 проиндексированными репозиториями, 4-мя фасетами и 1.2 миллионами датасетов, а с другой стороны...
Из этих репозиториев топ 4 содержат 1 миллион датасетов, более 83% и, в целом, если пройтись по сайтам этих топ 4 репозиториев: ClinicalTrials, Gene Expression Omnibus, NeuroMorpho, Zenodo то их поиск содержит гораздо больше возможностей.
Кроме того сами особенности индексируемых данных учитываются, как бы сказать, никак.
Не выглядит, конечно, как продукт за 10 миллиона долларов, но даже в таком виде любопытен и потенциально полезен.
И конечно, это не поисковик, а по сути агрегатор репозиториев. Главное отличие поисковика по данным и агрегатора, в том что агрегатор создан быть проиндексированным поисковыми системами и у каждого датасета есть отдельная индексируемая страница. А поисковик не предполагает что его будут индексировать другие поисковики.
Ссылки:
[1] https://datamed.org
[2] https://reporter.nih.gov/project-details/1U24AI117966-01
#opendata #datasets #datasearch #datacatalogs #healthcare #bioinformatics
Обновлённая подборка государственных каталогов открытых API. Последний раз я писал о них полтора года назад за это время список пополнился:
- API.GOUV.FR - каталог API, стандарты и рекомендации Франции
- API.GOVERNMENT.AE - каталог API Объединённых Арабских эмиратов
- API.GOV.UK - каталог государственных API Великобритании
- API.GOV.AU - австралийский государственный стандарт предоставления API и каталог общедоступных API
- DEVELOPER.VIC.GOV.AU - портал для программистов (каталог API) правительства штата Виктория, Австралия
- API.NSW.GOV.AU - портал открытых API Нового Южного Уэльса, Австралия
- PORTAL.API.IPAUSTRALIA.GOV.AU - портал API патентного ведомства Австралии
- DEVELOPER.HEALTH.GOV.AU - B2G (Business To Government) портал API Департамента здравоохранения Австралии
- DEVELOPER.TECH.GOV.SG - портал для разработчиков от Правительства Сингапура, API, документация и тд.
- ESERVICES.MAS.GOV.SG - портал открытых API главного монетарного управления Сингапура (аналог центробанка)
- MYGDX.GOV.MY - каталог API на малазийском государственном портале MyGDX
В реальности каталогов API сильно больше, не везде они сразу бросаются в глаза.
#api #openapi
Яндекс запустили аналог досок Miro в виде продукта Яндекс.Концепт [1], это новость, хорошая, даже не в рамках импортозамещения, а то что MIro в какой-то момент стал неоправданно дорогим продуктом. Я лично какое-то время Miro пользовался, но где-то в 2021 году почти перестал.
Из плюсов:
- есть перенос из Miro, автоматизированный
- практически бесплатное использование на сегодняшний момент
Из минусов:
- функциональности поменьше
- не все доски импортируется, у меня не перенеслись примерно 50%, почти все они это майндмапы вроде того что на картинке.
А чтобы два раза не писать, альтернативы с открытым кодом:
- Jitsu Meet [2] если нужно совмещение с системой звонков
А также:
- https://github.com/toeverything/AFFiNE
- https://github.com/penpot/penpot
- https://github.com/excalidraw/excalidraw
- https://github.com/tldraw/tldraw
P.S. Кстати, системная проблема со всеми продуктами в этой области в отсутствии универсального формата/стандарта. Если выбираешь инструмент, то переносить из него потом очень непросто.
Ссылки:
[1] https://yandex.ru/company/news/01-12-09-2024
[2] https://jitsi.org/jitsi-meet/
#whiteboards #miro #alternatives #opensource
А помните я писал о том что хорошо бы многим продуктам иметь SQL интерфейс для продвинутых пользователей? Вместо API, в дополнение API Так вот всё больше такого появляется. К примеру? Hugging Face совсем недавно добавили SQL консоль.
Внутри там всё на базе DuckDB WASM и выглядит как весьма полезная фича.
К каким сервисам ещё бы очень хотелось иметь SQL консоли?
1. Всё что касается веб аналитики. Чтобы не тягать всё время из API и чтобы не испытывать мучения с их веб интерфейсами.
2. К почте, вот просто к корпоративной почте.
3. К любым другим массовым онлайн сервисам (?)
#sql #datatools #data
Ещё один полезный для чтения текст Open Source is not a Business Model
[1] в сторону продвижения Fair Source [2] как открытие кода с ограничениями не мешающими на нём зарабатывать.
Лично я считаю что Fair Source - это модель вполне имеющая право на существование. Станет популярной - хорошо, не станет - тоже хорошо.
Острота в дискуссиях об открытом коде возникает когда проекты меняют лицензию. Вроде того же Elastic с их прыжками по лицензиям, туда и обратно. Что не отменяет качество самого продукта, отметим.
Ссылки:
[1] https://cra.mr/open-source-is-not-a-business-model
[2] https://fair.io
#opensource #readings #softwaredevelopment
17-18 сентября я буду в Алма-Ата, в Казахстане, какое-то число встреч встреч уже запланировано, если задумаете со мной там пересечься, напишите.
А пока об открытых данных в Казахстане я неоднократно тут писал, в стране довольно контрастная ситуация когда одновременно есть портал данных data.egov.kz который хоть и называется порталом открытых данных, но по факту ничего открытого там нет. И параллельно существует геопортал НИПД где как раз именно открытые данные, но только пространственные и в отличие от data.egov.kz он сделан на типовом ПО GeoNode как раз предназначенном для раскрытия геоданных.
А главная особенность Казахстана в большом числе региональных геопорталов сделанных местными компаниями и, соответственно, на которых слои карт отдаются в каких-то собственных форматах вместо общепринятых.
И отдельно, важная тема, в Казахстане практически нет практики публикации научных данных. Либо эта культура ещё не сформировалась, либо публикация данных идёт только на зарубежных ресурсах
В целом ощущения что данных много, систематизации мало, а проекты вроде data.egov.kz правильнее было бы закрыть или радикально переделать.
#opendata #datasets #datacatalogs #kazakhstan
У меня довольно небольшой телеграм канал у которого чуть более 8 тысяч подписчиков и, честно говоря, я практически не вкладывался в его продвижение чем-либо кроме контента, но мне регулярно пишут с просьбой опубликовать тот или иной материал и несмотря на малость канала, похоже, нужна какая-то публичная политика с вопросами и ответами.
1. Я практически ничего не размещаю в виде коммерческой рекламы. Во первых я с канала ничего не зарабатываю и не планировал, во вторых зачем распугивать аудиторию? Поэтому на любое рекламное размещение у меня запретительный ценник. Проще не спрашивать "на каких условиях".
2. Но если Вы публикуете открытые данные или создаете продукт с открытым кодом по работе с данными и они любопытные, то я обязательно об этом захочу написать.
3. Также как если Вы проводите какое-либо интересное открытое мероприятие, особенно если оно посвящено таким редким темам как архивация цифрового контента. Напомню что про архивацию я также модерирую телеграм канал @ruarxive.
4. Или если Вы сделали интересное исследование на данных и его данные доступны под свободными лицензиями, то это также интересно и я всегда сделаю репост.
5. Я редко пишу про мероприятия где я не участвую, не участвовал или не участвовала infoculture">Инфокультура или Open Data Armenia. Только если оно по каким-то причинам важно мне лично.
6. Я стараюсь писать про все случаи закрытых данных в РФ и не только, они все под хэшем #closeddata и если Вы такие новые факты знаете, я обязательно об этом напишу и упомяну.
7. То же самое в отношении недокументированных API о которых я пишу тут время от времени с оговоркой что публикация этой информации не приводит к каким-либо неприятным последствиям вроде исчезновения этих данных.
8. Время от времени я пишу про big tech, госполитику в области данных и цифры, приватность и тд. И делаю репосты из каналов где упоминают важные события.
9. Во всём остальном действует очень простое правило. К публичному телеграм каналу я отношусь как открытой записной книжке. Фильтр который я задаю себе при любой публикации захочу ли я это перечитать в будущем? Если нет, то и зачем писать?
#thoughts #contentpolicy #blogging
Для тех кто любит применять правильные термины, оказывается ещё в июле 2024 г. вышел словарь CODATA Research Data Management Terminology [1] с подборкой англоязычных терминов по управлению исследовательскими данными.
В принципе то термины там относительно универсальны, но определения даны через призму работу исследователей, поэтому корректно их воспринимать именно в контексте исследовательских данных, принципов FAIR и открытого доступа.
Например, определение открытых данных звучит как:
Data that are accessible, machine-readable, usable, intelligible, and freely shared. Open data can be freely used, re-used, built on, and redistributed by anyone – subject only, at most, to the requirement to attribute and sharealike.[2]
Этот словарь доступен через портал Research Vocabularies Australia [3] агрегатор и поисковик по всем словарям используемым в исследовательских целях в Австралии.
Ссылки:
[1] https://vocabs.ardc.edu.au/viewById/685
[2] http://vocabs.ardc.edu.au/repository/api/lda/codata/codata-research-data-management-terminology/v001/resource?uri=https%3A%2F%2Fterms.codata.org%2Frdmt%2Fopen-data
[3] https://vocabs.ardc.edu.au
#opendata #semanticweb #data #datacatalogs #terms
Прекрасное чтение Watching the Watchdogs: Tracking SEC Inquiries using Geolocation Data [1] в виде научной статьи, но я перескажу простыми словами.
Если вкратце, то группа исследователей:
1) Нашли поставщика данных у которого они закупили данные по всем телефонам с которыми ходили люди в офисе комиссии по ценным бумагам в США (SEC) по своим офисам
2) Идентифицировали сотрудников из общего числа устройств,
3) Сопоставили множество геоданных, вплоть до шейпфайлов штабквартир публичных компаний
4) Определили когда сотрудники SEC приходили в эти офисы
5) Разобрали как SEC проверяет публичные компании и когда эта информация публична
6) Сопоставили проверки с изменениями стоимости ценных бумаг
И вуаля, так и хочется сказать, почему эти гении люди обо всём этом написали научную статью, вместо того чтобы существенно обогатится на полученных данных!
Многое бы бизнес во многих странах отдал бы за отслеживание того куда ходят налоговики, силовики, представители горных национальных республик и ещё много чего.
А статью рекомендую, жаль лишь что они источник данных не указывают.
Ссылки:
[1] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4941708
#dataanalysis #research #privacy #geodata
В рубрике интересных наборов и каталогов данных, источники данных по блокчейну, Web 3
- Blockсhair datasets [1] дампы всех основных криптовалют: Bitcoin, Bitcoin Cash, Zcash, ERC-20, Ethereum, Dogecoin, Litecoin в виде коллекции сжатых TSV файлов
- Bitcoin Blockchain Historical Data [2] датасет на Kaggle адаптированный под data science прямо на платформе, только Bitcoin
- AWS Public Blockchain Data [3] дампы блокчейнов Bitcoin и Ethereum сразу в формате parquet
- Google Cloud Blockchain Analytics [4] данные и интерфейс работы с ними для 24 разных криптовалют на платформе Google Cloud
Ссылки:
[1] https://blockchair.com/dumps
[2] https://www.kaggle.com/datasets/bigquery/bitcoin-blockchain
[3] https://registry.opendata.aws/aws-public-blockchain/
[4] https://cloud.google.com/blockchain-analytics/docs/supported-datasets
#opendata #datasets #data #datacatalogs
Отвлекаясь слегка от чисто технологических тем и чуть переключаясь на социальные аспекты технологий и не только и заодно про социальные рейтинги и то что к ним близко.
Оказывается, после 2016 года, попытки военного переворота в Турции правительство страны активно понижало кредитные/банковские рейтинги диссидентов, членов Движения Гюлена и Курдов.
Банки применяют две процедуры Know Your Customer (KYC) и Customer Due Diligence (CDD) для проверки своих клиентов и эти процедуры исключали многих диссидентов полностью из финансовой системы страны и закрытию их банковских счетов, как бы не про приказу правительства, а потому что банки считают их "опасными лицами причастными к терроризму".
Подробнее можно прочитать в оригинале Weaponizing Financial Systems Erdoğan's Transnational Repression to Muzzle Dissidents Abroad [1].
На мой взгляд слабая часть доклада - это упоминание ИИ и то что ИИ усиливает эти действия автоматически и алгоритмически применяя новые данные, без ручной проверки, рассматривая государственные публикации как легальный источник сведений.
Всё это к вопросу, например, о социальных рейтингах и тому подобному. Именно государства будут основными манипуляторами этих рейтингов.
Ссылки:
[1] https://www.institude.org/report/weaponizing-financial-systems-erdogans-transnational-repression-to-muzzle-dissidents-abroad
#privacy #ai #socialcreditsystems #turkey
В рубрике недокументированных API ещё один пример, реестр НПА Казахстана zan.gov.kz [1]. Хотя на сайте нет документации на это API, но оно существует и все материалы оттуда доступны в машиночитаемой форме.
- http://zan.gov.kz/api/documents/search - пример запроса поиска (требует POST запрос)
- http://zan.gov.kz/api/documents/200655/rus?withHtml=false&page=1&r=1726577683880 - пример запроса получения конкретного документа
Как Вы наверняка уже догадываетесь ни на портале данных Казахстана нет описания этого API и тем более на других ресурсах. Тем временем могу сказать что в одном только Казахстане под сотню недокументированных API, просто потому что разработчикам удобнее делать приложения используя Ajax, динамическую подгрузку контента и тд.
Каталоги API которые делаются в мире - это не такая уж странная штука, это один из способов предоставлять данные разработчикам.
Я завел отдельный тег #undocumentedapi и время от времени буду приводить примеры по разным странам.
Ссылки:
[1] http://zan.gov.kz
#opendata #data #kazakhstan #laws #api #undocumentedapi
Я, кстати, в очередной раз могу сказать что открытые данные - это, в первую очередь, культура и систематизация работы с данными. Так сложилось что я регулярно работаю с большими базами документов порождённых органами власти. Не с отдельными файлами, а прям с копиями банков документов законов и других НПА. И огромная часть этих НПА - это, безусловно, то что должно быть доступно в виде данных, а не в виде отсканированных PDF документов.
Если бы официальные документы все и всеми публиковались бы с приложениями, хотя бы в виде Excel файлов, то доступных данных было бы гораздо больше.
Например из десятков тысяч документов опубликованных органами власти г. Москвы на оф сайте mos.ru, как минимум несколько тысяч - это очень большие таблицы, в сотни и тысячи страниц опубликованные как сканы. Если бы их публиковали иначе, то то же Правительство Москвы могло бы публиковать не несколько сотен, а несколько тысяч наборов данных, потенциально весьма востребованных к тому же.
Это просто пример, он справедлив к отношении практически всех органов власти, особенно крупных стран и территорий.
А я об этом задумался ещё давно в контексте того что поиск по данным может начинаться как поиск по каталогам данных и индексированием того что уже машиночитаемо, а продолжаться охватывая то что ещё не машиночитаемо, но может стать таковым. Чтобы проиндексировать каталог данных, надо сделать этот каталог данных (с).
#opendata #datasets #laws #datacatalogs
В рубрике доступных, но недокументированных открытых данных которые. по хорошему, российское Минэкономразвития должно было бы публиковать на портале открытых данных если бы он был, геоданные инвестиционной карты РФ [1] хотя никак не обозначены и не документированы публично тем не менее доступны через интерфейсы API опенсорс продукта GeoServer который используется внутри этого портала. Разработчики закрыли интерфейс самого геосервера, но закрыть интерфейсы API невозможно без глубокой переделки сайта, поскольку именно с сайта слои автоматически подгружаются. Поэтому и рассказать об этом можно без опасений, API исчезнут только если исчезнет сам портал.
- https://investmapapi.economy.gov.ru/geoserver/ows?service=WMS&version=1.1.1&request=GetCapabilities - WMS 1.1.1
- https://investmapapi.economy.gov.ru/geoserver/ows?service=WMS&version=1.3.0&request=GetCapabilities - WMS 1.3.0
- https://investmapapi.economy.gov.ru/geoserver/ows?service=WFS&version=1.0.0&request=GetCapabilities - WFS 1.0.0
- https://investmapapi.economy.gov.ru/geoserver/ows?service=WFS&version=1.1.0&request=GetCapabilities - WFS 1.1.0
- https://investmapapi.economy.gov.ru/geoserver/ows?service=WFS&version=2.0.0&request=GetCapabilities - WFS 2.0.0
- https://investmapapi.economy.gov.ru/geoserver/ows?service=WCS&version=1.0.0&request=GetCapabilities - WCS 1.0.0
- https://investmapapi.economy.gov.ru/geoserver/ows?service=WCS&version=1.1.0&request=GetCapabilities - WCS 1.1.0
- https://investmapapi.economy.gov.ru/geoserver/ows?service=WCS&version=1.1.1&request=GetCapabilities - WCS 1.1.1
- https://investmapapi.economy.gov.ru/geoserver/ows?service=WCS&version=1.1&request=GetCapabilities - WCS 1.1
- https://investmapapi.economy.gov.ru/geoserver/ows?service=WCS&version=2.0.1&request=GetCapabilities - WCS 2.0.1
- https://investmapapi.economy.gov.ru/geoserver/ows?service=WPS&version=1.0.0&request=GetCapabilities - WPS 1.0.0
- https://investmapapi.economy.gov.ru/geoserver/gwc/service/tms/1.0.0 - TMS. 1.0.0
- https://investmapapi.economy.gov.ru/geoserver/gwc/service/wms?request=GetCapabilities&version=1.1.1&tiled=true - WMTS 1.1.1
- https://investmapapi.economy.gov.ru/geoserver/gwc/service/wmts?REQUEST=GetCapabilities - WMTS 1.0.0
Этот пример не единственный, в России общедоступных инсталляций GeoServer 12 штук, на сегодняшний день. Это немного, но они есть.
Ссылки:
[1] https://invest.gov.ru
#opendata #russia #datasets #geodata #spatial
Про то как публикуют и работают с опубликованными датасетами расскажу про их публикацию по стандарту schema.org.
В Schema.org, наборе стандартов для публикации информации о разных объектах для удобства их индексирования, есть два типа объектов Dataset и DataCatalog. Первый описывает набор данных и включает довольно большое число атрибутов, редко заполненных полностью, но тем не менее. Второй описывает коллекцию наборов данных, как правило это наборы данных одного сайта, реже несколько каталогов данных на одном сайте.
Особенность в том что если объекты типа Dataset ещё более-менее встречаются, то DataCatalog - это безусловная редкость. К примеру, в проекте Web Data Common за 2023 год извлечено менее миллиона (839 тысяч) ссылок на страницы с объектами Dataset и совсем нет объектов типа DataCatalog. Нет не случайно, потому что даже беглая проверка по каталогам данных в Dateno registry показывает что в лучшем случае у каждого тысячного каталога данных есть эта разметка.
А вот разметка Dataset присутствует у многих каталогов, из широко известных, к примеру, Hugging Face и Kaggle. А вот к примеру, на общеевропейском портале data.europa.eu этой разметки нет, а на национальном портале США data.gov она сокращённая и даёт только минимальные атрибуты такие как название и ключевые слова, без детализации прикреплённых ресурсов или лицензий.
При этом в команде Google, полтора года назад упоминали что в их поисковом индексе Google Dataset Search есть 45 миллионов записей с 13 тысяч сайтов. Правда у них охват шире чем у Common Crawl, а также явно кроме объектов Dataset они добавляют в индекс объекты типа DataDownload, они тоже есть в спецификации schema.org и, наконец, Google Dataset Search индексирует датасеты через разметку RDFa, а по ней нет статистики из Common Crawl. В проекте Web Data Commons нет отдельной выгрузки объектов типа Dataset для RDFa.
Основных проблем со Schema.org две.
Первая в том что это добровольная разметка объектов и слишком часто ей размечают коммерческие данные и сервисы рассчитывая на продвижение в поиске Гугла. И действительно там в поиске много "мусора", данных не имеющих ценности, но проиндексированных и доступных для поиска.
Вторая в том что реально интересные каталоги данных Schema.org не поддерживают. Особенно это справедливо в отношении геоданных и геопорталы практически все используют только собственные стандарты публикации данных.
Собственно поэтому в Dateno основная индексация не через краулинг объектов Schema.org, а несколько десятков видов API.
#thoughts #datasearch #dateno
Полезное чтение про данные, технологии и не только:
- The Modern CLI Renaissance [1] о том как инструменты командной строки переживают ренессанс будучи переписанными, в основном, на Rust. Тоже наблюдаю эту картину и что тут скажешь, хорошо что это происходит.
- Nvidia and Oracle team up for Zettascale cluster: Available with up to 131,072 Blackwell GPUs [2] полным ходом гонка ИИ кластеров. Oracle и NVIDIA запускают в начале 2025 г. кластер на 2.4 зетафлопса, сравнивать сложно, это просто много
- Android apps are blocking sideloading and forcing Google Play versions instead [3] Google начали внедрять в андроид функцию установки приложения через Google Play если ты пытаешься поставить его из другого источника. То есть если ты из внешнего магазина загружаешь приложение которое есть в Google Play то тебя обязывают ставить то что в Google Play.
- Google will now link to The Internet Archive to add more context to Search results [4] Google теперь даёт ссылки в результатах поиска на Интернет Архив вместо их собственного кэша, на который они ранее ссылки удалили. Надеюсь они при этом дали денег Интернет Архиву, потому что как бы их не за ддосили.
Ссылки:
[1] https://gabevenberg.com/posts/cli-renaissance/
[2] https://www.tomshardware.com/tech-industry/artificial-intelligence/nvidia-and-oracle-team-up-for-zettascale-cluster-available-with-up-to-131072-blackwell-gpus
[3] https://arstechnica.com/gadgets/2024/09/android-now-allows-apps-to-block-sideloading-and-push-a-google-play-version/
[4] https://9to5google.com/2024/09/11/google-search-internet-archive-wayback-machine/
#software #data #google #android #readings
Давно размышляю о том как в научной среде публикуют данные и насколько всё зависит от научной дисциплины. В разных науках подход, инструменты, культура работы с данными и их доступность существенно отличаются.
Например, особняком идёт всё что касается life sciences особенно в части биоинформатики. Практически все исследования там, или создают данные, или используют и ссылаются на данные, или то и другое. Фактически это огромная связанная инфраструктура через стандарты, идентификаторы, специальные платформы и специализированные платформы и базы данных. Собственный мир развивающийся по собственным правилам.
Второй похожий блок - это науки о Земле включая климатологию, метеорологию, геофизику, науки о морях и океанах. По внутренним ощущениям там не так всё технологизировано, вернее, несколько консервативнее, но также это собственная экосистема.
Особняком данные связанные с ИИ, одна из областей где коммерческих данных может быть больше чем научных. Большая часть из них сконцентрированы в Kaggle и Hugging Face.
И отдельная история - это экономика, социальные науки, гуманитарные науки, госуправление и тд. Там данные если публикуются то скорее рассматриваются как один из результатов научной деятельности. Вот они публикуются, или на тех же ресурсах что и научные статьи, или на специализированных научных порталах общего типа.
Всё это сильно влияет на то как собирать данные, что считать датасетами, объём собираемых данных и так далее.
К примеру, сбор научных данных из репозиториев научных результатов - это, часто, поиск иголки в стоге сена. Не все научные репозитории поддерживают API и фильтрацию результатов по типу содержимого. Из репозиториев на базе DSpace, к примеру, надо вначале извлечь всё, а потом уже процеживать их по множеству критериев чтобы вытащить датасеты. Из 1 миллиона таких научных результатов, то что является датасетами будет 50-60 тысяч записей.
Возникает ситуация когда можно собирать научные данные и в процессе приходится ещё множество метаданных других научных работ и поисковик/поисковый индекс по научным работам получается автоматически. Как бы естественно. Но делать, его, вряд ли осмысленно поскольку таких поисковиков множество.
#thoughts #datasearch #openaccess #opendata
Команда OpenAIRE пишет про партнёрство с лабораторией SCImago [1], командой которая создала несколько продуктов по оценке и рэнкингу научных институций и стран. Кстати, если Вы не видели их рейтинг стран по научным публикациям, то стоит взглянуть [2] и, кстати, картинка о состоянии российской науки, вернее падения её интеграции в мировую и цитируемости. Я это комментировать не буду, уверен что найдутся те кто может объяснить эти процессы лучше меня.
Так вот партнёрство OpenAIRE и SCImago упоминается в контексте исследовательских данных и логично будет если вскоре появятся аналитические и визуальные продукты именно по публикации и доступности научных данных. Это будет любопытно.
Правда, важно всегда помнить что качество метаданных в индексе OpenAIRE не очень высокое, но точно выше чем в DataCite или в китайском ScienceDB.
Ссылки:
[1] https://www.openaire.eu/openaire-and-scimago-lab-unite-to-enhance-scholarly-research-data
[2] https://www.scimagojr.com/countryrank.php
[3] https://www.scimagojr.com/countrysearch.php?country=RU
#opendata #openaccess #openaire #europe #rankings
Симпатичный продукт для тетрадок работы с данными Briefer [1], обещают поддержку Python и SQL, генерацию Data apps, ИИ помощника и построение дашбордов.
Поддерживаются Y Combinator и даже с открытым кодом и ещё интереснее их рассказ о том почему они с открытым кодом и каково это открывать код когда тебя финансируют венчурный фонд [3]. Ожидаемо там про выбор AGPL лицензии.
Ссылки:
[1] https://briefer.cloud/
[2] https://github.com/briefercloud
[3] https://briefer.cloud/blog/posts/launching-briefer-oss/
#opensource #datatools #data
В рубрике интересных каталогов данных малоизвестных за пределами своих отраслей GBIF (Global Biodiversity Information Facility) [1] портал для публикации данных о встреченных видах в рамках исследований биоразнообразия.
Сейчас на портале более 108 тысяч наборов данных о 7.7 миллионах видах и чуть менее 3 миллиардах упоминаний о случаях встречи с ними (occurrences). Помимо информации о видах и датасетах там есть профили стран и можно найти данные даже по очень экзотическим территориям или по известным странам с большой подробностью.
Вот профиль с датасетами и животными Армении [2] и, например, если Вы интересовались есть ли в Армении медведи. Да, есть;) [3]
Почти все материалы в GBIF опубликованы под лицензиями CC-BY и CC0.
Это бесценный источник ресурсов для обучения распознавания изображений животных и их следов.
Ссылки:
[1] https://www.gbif.org
[2] https://www.gbif.org/country/AM/summary
[3] https://www.gbif.org/occurrence/4436343743
#opendata #biodiversity #openaccess
Мысли вслух о индексировании датасетов
Я как то уже писал о том что потратил в своё время немало сил и времени на то чтобы научиться создавать данные из неструктурированных источников. Развивая мысль "всё таблица" в мысль "всё данные". Самое очевидное применение - это сайты к которым пишут многочисленные парсеры, но число сайтов бесконечно, а число парсеров конечно. И писать множество парсеров для каждого сайта не хватит и тысячи жизней.
Можно ли это автоматизировать? Можно ли автоматически понимать разметку страниц и извлекать из них смысл. Самый очевидный путь - это использовать микроформаты и разметку контента через Schema.org и вытаскивать объекты из индекса Common Crawl. Что, кстати, многие и делают для задач обучения ИИ и не только и что имеет свои ограничения из-за невысокого качества этой самой разметки.
Кроме того она используется далеко не всеми. Да чего уж там, огромное число государственных, корпоративных и академических вебсайтов не используют даже базовые инструменты для индексации поисковиками. У них нет файлов robots.txt, отсутствуют sitemaps и ещё много всего.
Когда я ещё возился начальной стадии с каталогами данных, казалось бы довольно типовыми функциями, то столкнулся с этим в полный рост. К примеру, большая часть каталогов данных не поддерживают Schema.org и не индексируются тем же краулером Google не говоря уже об остальных.
Геоданные почти все вообще не попадают в поисковые индексы как датасеты, для них нет разметки, а каталоги геоданных не оперируют метаданными из Schema.org, за редким исключением.
Как собирать метаданные в таких условиях?
По сути стратегия сбора метаданных о датасетах сводится к нескольким моделям:
1. Сбор стандартизированными инструментами через API каталогов данных или дампы каталогов.
Причём этих API может быть несколько. Тот же CKAN, к примеру, поддерживает собственное API и часто имеет дамп экспорта по стандарту DCAT, а у каталогов Dataverse ещё больше вариантов их индексации, с помощью внутреннего API, OAI-PMH, Sword и других вариантов. Это то что делают некоторые поисковики, например, научные или порталы агрегаторы данных, но они используют, как правило, 2-3 стандарта для сбора метаданных.
2. Индивидуализированное извлечение метаданных
В случае крупных каталогов данных написание парсеров исключительно под них и перенос метаданных в поисковый индекс. Это резко отличается от того что делают все остальные поисковики и агрегаторы, кроме тех которые используют большие открытые данные DataCite для каталогизации датасетов получивших DOI.
3. Краулинг + Schema.org
Стандартный механизм используемый Google Dataset Search и не используемый больше почти более нигде. В самом простом сценарии реализуется через поглощение sitemap файлов и последовательное извлечение разметки Schema.org Dataset из веб страниц. С одной стороны, не зависит от используемого в каталоге ПО, с другой стороны всё равно требует ручной верификации.
4. Умный анализ структуры каталога и автоматическое аннотирование датасетов
Это самое сложное и интересное. Как определить структура сайта? Как определить структуру веб страницы на которой размещён набор данных? Это можно делать по типовым шаблонам ссылок с префиксами типовыми для наборов данных, такими как /dataset/ и тд. Ещё один признак - это ссылки на дата файлы .csv, .json, .xml и им подобные, а также ключевые слова в разметке страниц и применение ИИ для понимания этой разметки. Всё вместе это может дать возможность приблизится к умному краулеру с обучением. Где-то с верификацией человеком, а где-то, возможно, даже без неё.
За бортом остаются порталы с собственным нестандартным API через которое рендерятся данные и другие порталы со встроенным AJAX'ом. Такие случаи даже умным краулером не обработать.
Всё это мысли вслух о поиске исходя из показателей количества охваченных каталогов данных и числа проиндексированных наборов данных как приоритетных. А есть и другие показатели качества, востребованности, удобства и не только.
#thoughts