У Jordan Tigani, основателя компании Mother Duck стоящей за СУБД DuckDB замечательный текст Big Data is Dead [1] который, трам-пам-пам, как вы догадались, о том что Big Data это уже давно мёртвый хайп. Не он первый и не он последний об этом говорит, но никогда не лишний раз напомнить.

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

Ссылки։
[1] https://motherduck.com/blog/big-data-is-dead/

#data #readings

В рубрике интересных открытых проектов на открытых данных, французский проект Inventaire [1] для коллаборативного ведения списков собственных книг и возможности делиться информацией с друзьями, коллегами и тд., в том числе запоминая кому и когда какие книжки ты отдавал или у кого ты их брал.

Особенность проекта в том что книжки сопоставляются с записями в Wikidata, а также данные проекта доступны в виде дампов [2] и API [3]

У проекта открытый код [4], его автор давний контрибьютор в Wikidata, а этот проект развивает с 2015 года.

Как и у всех подобных проектов, главные вопрос в экономической модели. Его создатель изначально делал проект на чистом энтузиазме, с 2019 года создал НКО в форме некоммерческой ассоциации и получил небольшие гранты от нидерландского фонда NLNet.

Ссылки:
[1] https://inventaire.io
[2] https://data.inventaire.io/
[3] https://api.inventaire.io/#/Entities
[4] https://github.com/inventaire/inventaire
[5] https://wiki.inventaire.io/wiki/Economic_model

#opendata #data #wikidata

Microsoft презентовали обновлённую поисковую систему Bing с встроенным чат-ботом на базе OpenAI [1] и множеством других связанных новаций, в том числе встраиванием ИИ в ранжирование в поисковой системе.

Изменит ли это нашу реальность больше чем ChatGPT ? Похоже нет, ChatGPT уже достаточно всех вдохновил и напугал.

А вот Microsoft может получить существенную долю поискового рынка для Bing.

Ссылки:
[1] https://blogs.microsoft.com/blog/2023/02/07/reinventing-search-with-a-new-ai-powered-microsoft-bing-and-edge-your-copilot-for-the-web/

#ai #microsoft #search

Ещё одна любопытная альтернатива формату файлов parquet - это lance [1]. Обещают 100-кратное ускорение при произвольном доступе, совместимость с Apache Arrow и DuckDB. Создатели позиционируют это как альтернативу Parquet, Iceberg и Delta.

По формату есть дизайн гайд [2], презентация [3]. В общем и целом посмотреть на него будет любопытно, как минимум.

Остаётся, правда, вопрос с объёмом хранения, потому что опций сжатия нет, а если данные не сжаты, то хранение их будет дороже чем parquet.

Ссылки։
[1] https://github.com/eto-ai/lance
[2] https://eto-ai.github.io/lance/format.html
[3] https://docs.google.com/presentation/d/1a4nAiQAkPDBtOfXFpPg7lbeDAxcNDVKgoUkw3cUs2rE/edit#slide=id.p

#datatools #opensource

Интересное мероприятие Software Source Code as documentary heritage организованное ЮНЕСКО совместно с французским некоммерческим проектом Software Heritage о сохранении исходного кода.
Там много интересных докладов, например, об организации хранения петабайтов в человеческом ДНК и о том сжатии огромных объёмов открытого кода.
Но важнее то что открытый код рассматривается как часть культурного/цифрового наследия человечества.

https://webcast.unesco.org/events/2023-02-07-software-heritage/

#opensource #opendata #software

Я сегодня потратил какое-то время и посмотрел видео вначале встречи Президента РФ, а потом главы Пр-ва РФ с молодыми учёными и в обоих случаях речь шла про доступ учёных к данным. Понятно что на таких встречах все вопросы и выступления заранее готовятся, фильтруются и доходят в каком-то ограниченном объёме. Но без весьма серьёзного сожаления слышать всё это было невозможно. Состояние науки в РФ достаточно давно оказывается в состоянии когда Минобрнауки или РАН не имеют возможности/ресурсов/потенции/мотивации к тому чтобы научная информационная инфраструктура существовала и развивалась. Отсюда и запросы, вроде жалобы на отсутствие доступа к данным судовых измерений, к примеру.

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

А я расскажу о проблемах в странах где открытость исследований, наоборот, ставится во главу угла. В США сейчас у учёных развернулась дискуссия среди астрономов по поводу свежей темы госполитики по максимально оперативному раскрытию исследований на деньги налогоплательщиков. В частности, работа телескопов вроде Хаббл - это тоже расходы налогоплательщиков и, казалось бы, это очень хорошо что данные будут раскрываться сразу. Справедливо даже и может значительно ускорять научные работы большого числа учёных. А с другой стороны, многие астрономы активно пользовались тем что ранее материалы публиковались с 6 месячной задержкой и благодаря этому у них был эксклюзивный материал для научной статьи. А если публиковать сразу то другие узнают над чем ты работаешь. Так может и пропасть интерес к здоровой конкуренции. Об этом весьма подробно вышла статья What's the fairest way to share cosmic views from Hubble and James Webb telescopes? [1]

Но это, повторюсь, проблема другого рода. Это проблема как раз конфликта сложившихся общественных отношений, индивидуальной мотивации и требований государства по открытости. В данном случае государство в США выступает не ограничителем открытости, а, наоборот, принуждает к ней.

А применительно к отсутствию данных для исследователей в России, я напомню мою июльскую заметку Открытость как признак жизни [2]. Когда открытость не обеспечивается - это синоним обезжизнивания отрасли, либо в виду отсутствия кооперации между участниками, либо симуляции деятельности.

Ссылки:
[1] https://www.npr.org/2023/02/07/1154840710/whats-the-fairest-way-to-share-cosmic-views-from-hubble-and-james-webb-telescope
[2] https://begtin.substack.com/p/26

#opendata #openaccess #openscience

В рубрике как это устроено у них, проекты по систематизации доступа к данным и госсервисам для разработчиков в мире. Я несколько раз писал о таких проектах, но не грех и напомнить.

- API.GOUV.FR - каталог API, стандарты и рекомендации Франции
- API.GOVERNMENT.AE - каталог API Объединённых Арабских эмиратов
- API.GOV.UK - каталог государственных API Великобритании
- API.GOV.AU - австралийский государственный стандарт предоставления API и каталог общедоступных API
- DEVELOPER.VIC.GOV.AU - портал для программистов (каталог API) правительства штата Виктория, Австралия
- DEVELOPER.TECH.GOV.SG - портал для разработчиков от Правительства Сингапура, API, документация и тд.

Общедоступные API создаются на тех же принципах что и порталы открытых данных, в их основе восприятие ИТ компаний и ИТ специалистов как отдельной аудитории для коммуникации. Признание самого факта что государства создают продукты не только для конечных потребителей, но и развивают внутренний рынок ИТ продуктов и сервисов, предоставляют данные аналитикам и журналистам.

#opengov #government #api #opendata

Я регулярно рассказываю про порталы данных и другие госпроекты по открытости в странах мира. Можно уже создать такую отдельную регулярную рубрику и в этот раз про портал открытых данных Республики Киргизия data.gov.kg

Портал создан в 2019 году и содержит 646 наборов данных включающих 1167 файлов общим объёмом около 570Мб. Более всего наборов данных опубликовано статистическим комитетом, а наибольший набор данных это - Сведения по рецептам по Дополнительной программе ОМС, в общей сложности 229МБ.

Из плюсов։
- портал существует (это уже редкость для многих стран, например, в Армении его нет)
- есть несколько любопытных наборов данных
- портал работает на CKAN и предоставляет стандартизованное API

Из минусов։
- портал уже несколько лет заброшен, новые данные на нём почти не публикуют, последнее небольшое обновление в середине 2022 г.
- данных мало, даже только на сайте статкомитета Киргизии опубликовано более 10 тысяч Excel файлов статпоказателей
- геоданные полностью отсутствуют, хотя эти данные доступны на других государственных геопорталах
- информация о продуктах на базе этого портала не собирается, новости не публикуются, есть ощущение что ничего не происходит
- машиночитаемых форматов практически нет, работы над переводом Excel файлов хотя бы в CSV не наблюдается

Общее итоговое ощущение что портал "висит в воздухе", без потребителей, мотивации госорганов к раскрытию данных, методик его работы, ответственных и тд. И всё это за довольно короткий срок, буквально в 3 года.

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

#opendata #kyrgyzstan #dataportals

В продолжение анализа про портал открытых данных Кыргызстана я в форме большого лонгрида написал в рассылку заметку "Что не так с порталом открытых данных Узбекистана?"․ Лонгрид получился потому что и сам портал казался больше, анализ его должен был быть куда более кропотливым.

Продублирую тут итоги.

Выводы очень неутешительны. 6623 набора данных в итоге оказываются всего лишь 40 мегабайтами данных, а фактическое число наборов данных оказывается искусственно раздутым. Мониторинг наборов данных выполняет даже не декоративную, а скорее манипулятивную функцию не давая реальной картины, но показывая обновлёнными данные которые совершенно точно не обновлялись. Даже портал открытых данных Киргизии, при всего лишь 646 наборах данных в Excel оказывается больше по объёму, не говоря уже о многих других порталах открытых данных других стран.

#opendata #uzbekistan #dataportals #government

В рубрике интересных наборов данных, сайт День сурка (Groundhog-Day.com) [1] где собрана база из 74 животных предсказателей длинной зимы или ранней весны, включая 43 сурка.

Сделано явно с большой любовью к животным и к данным, потому что у сайта есть открытое API [2] с информацией о всех животных, их местонахождении и предсказаниях.

Ссылки:
[1] https://groundhog-day.com
[2] https://groundhog-day.com/api

#opendata #api

В блоге Стивена Вольфрама, создателя Wolfram Alpha и Wolfram Mathematica появился интересный текст What Is ChatGPT Doing … and Why Does It Work? [1] с тщательным разбором того как работает ChatGPT и множеством подробностей. Текст не очень сложный, но очень длинный, объясняющий как работают нейросети, хотя, на мой взгляд здесь ситуация примерно как с работой мозга. Можно объяснить как работает один нейрон и гораздо сложнее когда их миллиарды. Текст будет очень интересен тем кто хочет понять как сложные вещи работают изнутри.

Там же, чуть ранее, другой текст со сравнением Wolfram Alpha и ChatGPT [2] описывающий, на самом деле, что ChatGPT можно сильно улучшить с помощью computational language используемый в Wolfram Alpha.

Я лично много лет смотрю с интересом на Wolfram Alpha и периодически думал как найти практическое применение этому продукту/сервису, за пределами обучения/образования, но ничего такого не удаётся.

Можно уже сказать что проблема Wolfram Alpha в том что это, как и все остальные продукты Стивена Вольфрама, продукт замкнутый на собственную экосистему. Свой язык, своя среда разработки, свой аналог электронных тетрадок (notebook), своё API, не очень хорошо документированное. Да, есть ядро Wolfram language для Jupyter Notebook [3], но не то чтобы оно было очень популярным и разработка его не ведётся уже давно.

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

Иначе говоря, моё сугубо личное мнение, что сколь бы ни был велик начальный задел за Wolfram Alpha, продукт всё более отстаёт от уже сделанного и от потенциала того что создаётся на базе языковых моделей.

Ссылки:
[1] https://writings.stephenwolfram.com/2023/02/what-is-chatgpt-doing-and-why-does-it-work/
[2] https://writings.stephenwolfram.com/2023/01/wolframalpha-as-the-way-to-bring-computational-knowledge-superpowers-to-chatgpt/
[3] https://github.com/WolframResearch/WolframLanguageForJupyter

#opensource #chatgpt #wolframalpha

Я ранее рассказывал про разные эксперименты в обработке данных, например, про обработку данных в 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

В рубрике интересных наборов данных 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

Я тут было подумал написать свежий текст о том что не так с госинформатизацией и с "Гостехом-в-вакууме" как одним из явлений этой же природы в России. Чуть менее чем год назад я тезисно об этом писал [1] и один из тезисов был то что в России много лет информатизация государства шла по пути технологической унитаризации. Это такое, в каком-то смысле уникальное российское явление о котором я писал ещё в 2011 году, но почти все мои тексты того времени куда подевались. Его суть в том что такое обилие глобальных федеральных государственных информационных систем (далее - ФГИС), совершенно монструозных по масштабу, потраченным деньгам и функциям, всё это следствие неявно обозначенной стратегии "поджирания полномочий" федеральными властями в отношении региональных и муниципальных властей.

ФГИС с которыми были и сейчас обязаны работать регионы и муниципалитеты чаще всего создавались по пограничной зоне ответственности федеральной и региональной власти, но, при этом под федеральным органом органом власти осуществляющим регулирование. Так создавалась единая система в сфере закупок, так создаётся единая система в сфере торгов , так создана ЕГР ЗАГС, Электронная школа и ещё многое другое. Только Москва всегда была исключением и московские чиновники ещё давно, при Лужкове, единственные на моей памяти говорили про то что некоторые федеральные законы не соответствуют Конституции РФ.

Такую централизацию всегда можно преподносить как благо, как возможность получить гарантированный сервис не зависящий от региона. Это федеральные власти и делали всё это время. Такие ФГИС закреплялись надолго федеральными законами и выдачей субсидий на информатизацию из федерального бюджета. Обычно происходило выведение из эксплуатации региональной информационной системы, например, системы закупок и переход региональных и муниципальных чиновников на ФГИС.

Часто, те кто писали про коррупцию при создании таких ФГИС не вполне понимали природу самого этого явления. То что при их создании коррупция может быть, да кто бы сомневался. Но важнее что их предназначение было изначально в централизации власти.

И власть это данные и данные это власть. Централизация данных в ФГИСах привела к тому что многие региональные власти не обладают полнотой доступа к собственным данным. Кое-где, например, в тех же госзакупках изначально вопрос открытости данных был необходим именно для доступа регионов. По этой же причине эти данные всё ещё сложно до конца закрыть, как бы кое-кто кое-где этого бы ни хотел. Но многие другие централизованно собираемые данные региональным властям доступны ограничено. Федеральная власть ведёт себя как некоторые корпорации и некоторые страны, это называется цифровой колонизацией и стратегией "данные приходят, данные не выходят".
Поэтому и странные фантазии некоторых не-российских политиков про сепаратизм в Российских регионах очень оторван от реальности, цифровая инфраструктура выстраивалась так чтобы эта вероятность была минимальной, а цена запредельной.

Из-за монструозности этих ФГИСов и тем что за каждой из них стоит, как правило, очень крупный системный интегратор и государственный интересант(-ы)/бенефициар(-ы), приводят к тому что они формируют, костяк цифровой системы госуправления, со всеми её плюсами и минусами. Любую из этих систем очень сложно убрать, сложно обслуживать. Любая из них, при неработоспособности, создаёт существенные проблемы для системы госуправления, граждан и/или бизнеса, потому что на них заворачивали большую часть сервисов и функций госорганов. И даже их модернизация, а уж тем более импортозамещение, это очень непростая задача. И по деньгам, и по мотивации интеграторов, и по рискам простоя и тд.

Далее вместо того чтобы писать длинный абзац того к чему всё это идёт, я задам лишь один, возможно, риторический вопрос. И вот где во всём этом место Гостеху?

Ссылки:
[1] https://publielectoral.lat/begtin/3600

#government #govtech #itmarket

Slack начал (продолжил?) отключать сообщества связанные с Россией. Сегодня прислал уведомление о принудительном закрытии сообщества opendatarussia.slack.com только по той причине что оно было зарегистрировано на адрес электронной почты в зоне .ru

Что тут сказать, хорошо ещё что сообщество оказалось заброшенным и большая часть общения перешла ещё давно в @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