У нашей команды первое расширение! Ищем активного армяноязычного координатора сообщества и партнерств в Ереване на частичную занятость. Верим, что подходящий нам человек где-то совсем рядом, так что подавайтесь сами и отправляйте знакомым, которые подходят под описание.

Вакансия целиком: https://opendata.am/2024/07/20/job-opening-community-and-partnerships-coordinator/.

Поработав в избытке с данными и со смыслом публикации разной статистики, в какой-то момент напишу лонгрид на тему того как хорошо и как плохо публикуют статистику в разных странах и территориях, а пока в виде выжимки накопленные мысли. Поскольку я на эту тему несколько раз уже писал в таком формате, то где-то могу и повторяться:
1. Унификация. Хорошо опубликованные статистические данные практически всегда хорошо унифицированы. У них есть так называется code lists, стандартизированные справочники территорий, видов деятельности и тд. Они унифицированы в единые форматы и с ними можно работать унифицированным образом с любым индикатором. Можно сказать что почти во всех развитых странах базы индикаторов доступны таким вот унифицированным образом. В современных национальных системах управления статпоказателями такая унификация почти всегда увязана на внедрение стандарта SMDX от 2 до 3 версии.
2. Массовая выгрузка. На английском языке она звучит как bulk download, возможность выкачать базу индикаторов целиком с минимальным объёмом усилий. Может выглядеть как 1-2 zip файла со всем содержимым, так делают в FAO, или тысячи csv/csv.gz файлов по одному по каждому индикатору, со всем содержимым индикатора и каталогом ссылок на все файлы. Так делают в Евростате и ILO.
3. Универсальный поиск. Статистические продукты бывают разные, иногда в разных информационных системах, в разных форматах, включая архивные статсборники. Универсальный поиск позволяет искать по ним всем. Начиная с интерактивных таблиц и заканчивая архивными материалами и даёт возможность найти нужные данные в нужном формате за заданный период.
4. Открытые данные по умолчанию. Практика альтернативная возможности массовой выгрузки когда статистические показатели с самого начала публикуются на стандартизированном портале открытых данных с уже имеющимся API этого портала и доступны для выгрузки через это стандартное API. Например, так делают в ЦБ Бразилии с дата порталом на базе CKAN и в Катаре с их госпорталом открытых данных на базе OpenDataSoft
5. Экспорт данных и доступ через API. Не просто экспорт в Excel, а как минимум выбор из 5-6 форматов начиная от самых простых вроде csv, продолжая форматами для Stata и других продуктов, автогенерацией кода для Python или R и наличию SDK к хотя бы паре популярных языков разработки для доступа к данным. У многих европейских порталов статданных есть неофициальные SDK, в других вроде статданных Гонконга автоматически генерируется код на Python на страницах интерактивных таблиц.
6. Технологичность. Тут можно было бы добавить и соответствие лучшим дата-инженерным практикам. Это включает: доступность данных в форматах parquet, документация к API по стандарту OpenAPI, общедоступные примеры работы через Postman или аналоги, общая документация в стиле технологических проектов с интерактивными примерами, а не в форме отчетности подрядчика по контракту в PDF. Технологичность - это про доступ и про документацию, как ни странно, но это самое актуальное для статданных.

#opendata #api #statistics #thoughts

Статистическая служба Малайзии внедряет AI Helper [1] в сайт для разработчиков прилагаемый к их порталу статистических данных. На простые вопросы вполне эффективно отвечает и даже умеет генерировать код для языков разработки которых нет в примерах на сайте. На сайте сейчас все примеры на Python и R, но можно получить код для Java сделав такой запрос к AI Helper'у.

В данном случае применение ИИ гос-вом самое что ни на есть безобидное.

Ссылки:
[1] https://developer.data.gov.my/#using-the-ai-helper

#opendata #ai #statistics #malaysia

В рубрике закрытых данных в РФ Департамент транспорта Москвы ограничил доступ к реестру легковых такси [1], он доступен только с заполнение ГРЗ и вводом каптчи.

Ранее реестр такси был доступен в виде таблицы на сайте мэрии Москвы mos.ru

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

Причём произошло это примерно год назад.

Правда ещё есть реестр такси Московской области объединённый с реестром такси Москвы [2], но формально он реестром такси Москвы не является.

Что первично, раскрытие данных или приватность? В РФ до недавних пор было первое, в ЕС приватность чаще на первом месте.


Ссылки:
[1] https://transport.mos.ru/auto/reestr_taxi
[2] https://mtdi.mosreg.ru/taxi-cars

#opendata #closedata #taxi #moscow #moscowregion #privacy

А вот и появился настоящий, а не выдуманный "убийца Google", а заодно и других поисковых систем и, возможно, Perplexity - это SearchGPT [1], продукт который OpenAI тестирует пока на 10 тысячах пользователей.

Поломает это, правда, не только бизнес модель поиска Гугла, но и Яндекса, и потенциально столкнётся с сильным раздражением владельцев контента.

Впрочем застать при этой жизни падение монополии Google на поиск - это было бы любопытно.

Ссылки:
[1] https://www.theverge.com/2024/7/25/24205701/openai-searchgpt-ai-search-engine-google-perplexity-rival

#ai #openai #searchgpt #google #search

На HuggingFace смешное приложение по генерации "бесконечных датасетов" [1]. Нет, сами датасеты оно не создаёт, пока что, только описания и разметку как будто они созданы.

Ссылки:
[1] https://huggingface.co/spaces/infinite-dataset-hub/infinite-dataset-hub

#ai #funny #humor #datasets

Я уже рассказывал про геоклассификацию данных в Dateno и то что существенная фича в поиске - это возможность поиска по городам/регионам, на субрегиональном уровне. Классификация датасетов по субрегионам основана почти полностью на аннотировании каталогов данных и с этой точки зрения это довольно простая задача с понятным решением.

Как оказывается куда менее простой задачей является привязка датасетов к странам и макрорегионам.

Базово привязка эта привязка делается через привязку каталога данных которые, как правило, конкретными странами ограничены. К примеру, если есть национальный портал данных какой-то страны, то и данные почти всегда касаются этой страны. Но это самые простые случаи и в основном про порталы открытых данных и про геопорталы.

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

Другая сложность возникает со всей статистикой и производными индикаторами. Помимо стат. показателей по странам существует неимоверное число разных групп стран, от простых, до хитровыдуманных. К примеру, группы арабских стран, страны MENA, G20, G7, Андское сообщество, наименее развитые страны, страны без выхода к морю и ещё много какие. Причём, конечно, группы стран пересекаются, но не всегда входят в друг друга.

Внутри Dateno, при этом, для группировки стран используется список макрорегионов из UN M49. Разметить страны по вхождение в эти макрорегионы несложно и внутренний справочник для этого есть. А вот справочника вхождения стран в эти многочисленные группы и их пересечений - нет и его надо составлять де-факто полувручную и нет кого-то кто бы поддерживал такую живую базу данных или программную библиотеку.

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

Пока что отсутствие привязки каких-то датасетов к странам и макрорегионам не так критичны поскольку другие поисковики даже такого не поддерживают и есть фасеты где разметка куда хуже. К примеру, наличие информации о лицензии есть не более чем у 10% датасетов.

Тем не менее качество фасетов в Dateno влияет на пользовательский опыт и это важная задача для построения максимально достоверного поискового индекса по данным.

#dateno #statistics #indicators #geodata #geo #thoughts

Полезная статья о которой хочется написать отдельно Deliver Your Data as a Product, But Not as an Application [1], она требует авторизации на Medium. но почитать её стоит.

Основная идея в том что данные - это продукт, но этот продукт не приложение. Иначе говоря если Ваша бизнес модель построена на предоставлении данных, то надо помнить что именно данные, являются продуктом и не надо смешивать их с кодом.

Собственно в статье отсылка к хорошо известной книге Principles of Data-Oriented Programming [2] и следующим принципам:
- Отделяйте код (поведение) от данных;
- Рассматривайте данные как неизменные (immutable)
- Отделяйте схемы/структуры данных от их представления
- Представляйте данные с помощью простых структур данных

Статья написана с прицелом на OOP разработчиков которые хотели бы понять отличия программирования с данными и без.

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

В случае с данными оно разделяется на 2+ сервиса API. Первый сервис API для бизнес логики/кода, второй для данных, как правило Data API отдающее JSON или Protocol Buffers. Реальные системы могут иметь больше вариаций по разделению и компонентам, но бизнес логика и доступ к данным разделять стоит всегда.

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

И это, конечно, относится не только к данным статистики.

Ссылки:
[1] https://towardsdatascience.com/deliver-your-data-as-a-product-but-not-as-an-application-99c4af23c0fb
[2] https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.html

#itarchitecture #datasaproduct #data #api

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

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

Рассмотрим пример, вот есть рейтинг стран по "силе паспортов" [1] в нём есть список лидеров стран и сам он построен предельно просто, по баллам по числу стран к которым есть безвизовый доступ у владельца паспорта.

Полезен ли этот рейтинг реально? Только одним, что пр-ва стран соревнуются кто больше. Но для пользователя нет.

Что мы знаем про страны и про то как туда уезжают/приезжают? То что страны не одинаковы по территории и экономике. То что поездки в страны можно разделить на экономические, туристические и долгосрочные и наверняка ещё много всего.

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

Второй подход. Берём классификацию мирового банка по уровням доходов стран [2] и добавляем коэффициенты для каждого уровня. Самый простой подход в том чтобы дать коэффициент в 1 для стран Low Income, 4 для Lower-middle Income, 7 для Upper-middle Income и 10 для High Income. Эти коэффициенты примерно соответствуют градации в доходах при классификации стран МирБанком.

А потом скрестим это с индексом "силы паспорта". Будет такой True Passport Index. Потому что он будет показывать реальную силу паспорта по доступу к цивилизации. От текущего рейтинга он будет отличаться очень сильно в середине списка, а самые "слабые" и самые "сильные" паспорта почти наверняка останутся на своих позициях.

Это лишь один наглядный пример, по той же логике можно многие какие рейтинги переделать и нормализовать.

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

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

Ссылки:
[1] https://en.wikipedia.org/wiki/Henley_Passport_Index
[2] https://blogs.worldbank.org/en/opendata/new-world-bank-group-country-classifications-income-level-fy24

#ratings #datajournalism #ideas

Свежий симпатичный поисковик по смыслам слов semantic grep [1] использует Word2Vec для выборки связанных по смыслу слов и уже их ищет по тексту.

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

Если подумать то такую штуку можно было бы сделать с языковой моделью внутри или более сложными алгоритмами чем просто модель Word2Vec.

Лично я большой любитель командной строки и инструментов работы в ней, хороших поисковиков по текстовым файлам всегда нехватает (и всегда много!)

Ссылки:
[1] https://github.com/arunsupe/semantic-grep

#opensource #ai #commandline #tools #data

Не так страшны законы как их беззаконное применение (с)
По поводу свежего законопроекта по которому все телеграм каналы/блоггеры 10 тысячники должны регистрироваться в РКН, я так скажу.

Ключевое в том как его будут применять. Во первых, Россия != русский язык, а русский язык != Россия. Русскоязычные телеграм каналы могут вестись где угодно в мире и ориентироваться на теперь уже особенно широкую диаспору. Их авторы могут иметь паспорта Канады, Испании, Израиля, Армении и десятков других стран. Их авторы могут уже вообще не иметь связи с РФ. Так по какому критерию РКН будет и сможет соотносить их с Россией?

По аудитории? Телеграм не даёт её в разбивке по странам. По гражданству владельца ? А откуда бы у них такая инфа? По коду телефонного номера? Так и он может быть не российским. Более того у телеграм канала может быть много админов и много авторов, иногда десятки авторов, тут то как быть?

Ещё важно помнить что телеграм каналы - это не сайты/домены. Заблокировать их нельзя, платформа не позволяет такое.

Поэтому знаете какой самый основной критерий получается ? По размещению рекламы российских юр. лиц и ИП. Это то что может ударить по карману тех русскоязычных телеграм канало владельцев которые зарабатывают на рекламе из РФ и на аудиторию в РФ.

У меня до 10 тысяч подписчиков немало, но желания размещать рекламу как не было так и нет. Выгода от разговора с профессиональной русскоязычной аудиторией разбросанной по всему миру перевешивает рекламные деньги с лихвой.

Поправьте меня если я неправ.

#blogging #thoughts #telegram #regulation