У меня есть регулярные аналитические задачи которые я решаю и которым сложно обучать других, не потому что нет людей способных к ним, а потому что они нетиповые и требуют опыта довольно длительного в разных областях. Это задачи по data discovery, обнаружению данных и систематизации источников. В каком-то смысле Dateno как поисковик, а до того каталоги каталогов данных появились как отражение этих задач. Потому что данные регулярно необходимо искать, находить, систематизировать и описывать.
Так вот в этих задачах ключевым является то что при всём развитии каталогизации данных за последние пару десятилетий слишком часто приходится сводить информацию из сотен полуструктурированных или неструктурированных источников и в таких задачах Dateno (пока что) мало помогает.
Вот примеры вопросов, выдуманные конечно, но близкие, таких задач.
1. Энергопотребление по странам Ближнего Востока
2. Индикаторы экономического роста и ёмкости рынка по странам Южной Африки
3. Реальная ценовая инфляция в Юго-Восточной Азии
И такого довольно много. В том числе по России, и пост-советским странам.
Первый шаг в таких задачах - это построение модели data stakeholders, определение всех организаций/подразделений/групп владеющими частичной или полной информацией по исследуемой области. Иногда только их составление может занять до недели.
Следующий шаг - это data sources (источники данных) которые практически всегда зависят от списка дата стейкхолдеров и которые могут варьироваться от специальных порталов, до веб сайтов и отчетов международных организаций.
И последний связанный с ним же шаг - это идентификация конкретных баз данных, датасетов и индикаторов с помощью которых можно решить задачу.
Всё это не творчество, а весьма структурированный процесс, результат которого, по сути, идёт в основу ТЗ на дата продукт.
Для открытых данных когда-то делали очень упрощённую модель инвентаризации данных через карты данных. Для корпоративных систем управления данных всё слегка проще по смыслу и сложнее технически, и зачастую упирается в отсутствие адекватной документации и то что внедряющие каталоги данных компании не понимают всей трудоёмкости их наполнения.
Что я могу сказать точно так то что для всех областей data discovery инструментов нехватает. Dateno закрывает некоторые поисковые задачи, но не аналитические. GPT подобные инструменты не помогают в решении поиска данных когда данных нет. Но, возможно, инструменты подспорья аналитика могут быть куда как более структурированными и решать если не типовые задачи, то реализовывать типовые подсказки для их решения.
#thoughts #dateno
Так вот в этих задачах ключевым является то что при всём развитии каталогизации данных за последние пару десятилетий слишком часто приходится сводить информацию из сотен полуструктурированных или неструктурированных источников и в таких задачах Dateno (пока что) мало помогает.
Вот примеры вопросов, выдуманные конечно, но близкие, таких задач.
1. Энергопотребление по странам Ближнего Востока
2. Индикаторы экономического роста и ёмкости рынка по странам Южной Африки
3. Реальная ценовая инфляция в Юго-Восточной Азии
И такого довольно много. В том числе по России, и пост-советским странам.
Первый шаг в таких задачах - это построение модели data stakeholders, определение всех организаций/подразделений/групп владеющими частичной или полной информацией по исследуемой области. Иногда только их составление может занять до недели.
Следующий шаг - это data sources (источники данных) которые практически всегда зависят от списка дата стейкхолдеров и которые могут варьироваться от специальных порталов, до веб сайтов и отчетов международных организаций.
И последний связанный с ним же шаг - это идентификация конкретных баз данных, датасетов и индикаторов с помощью которых можно решить задачу.
Всё это не творчество, а весьма структурированный процесс, результат которого, по сути, идёт в основу ТЗ на дата продукт.
Для открытых данных когда-то делали очень упрощённую модель инвентаризации данных через карты данных. Для корпоративных систем управления данных всё слегка проще по смыслу и сложнее технически, и зачастую упирается в отсутствие адекватной документации и то что внедряющие каталоги данных компании не понимают всей трудоёмкости их наполнения.
Что я могу сказать точно так то что для всех областей data discovery инструментов нехватает. Dateno закрывает некоторые поисковые задачи, но не аналитические. GPT подобные инструменты не помогают в решении поиска данных когда данных нет. Но, возможно, инструменты подспорья аналитика могут быть куда как более структурированными и решать если не типовые задачи, то реализовывать типовые подсказки для их решения.
#thoughts #dateno
К вопросу об AI и больших языковых моделях, я на днях тестировал несколько LLM'ок вопросами в форме "дай мне расходы бюджета города N по по месяцам с января по май 2024 года". И пока ни один из них не дал такого расклада со ссылкой на первоисточник документа бюджета города. Только на новости на сайте мэрии и новостных агентств.
В этом важное ограничение всех этих инструментов - у них нет доступа к огромным базам данных на которых можно строить аналитику. Я вот сомневаюсь что Bloomberg или S&P Global откроют свои базы для OpenAI или чего-то подобного, если только это не будет какое-то стратегическое партнерство. А вот применение ИИ к макропрогнозированию и работе с экономическими данными - это будет реальный прорыв для одних и катастрофа для других.
Поэтому одно из самых интересных направлений которые я вижу - это связывание языковых моделей с очень специальными большими банками данных и создание новых продуктов в этих областях.
А от AI краулеров почти все СМИ и иные контентные сайты начнут стремительно закрываться. И требовать убирать их контент из индексов этих AI моделей. Потому что бизнес модель контентных сайтов через рекламу или подписку скоро начнет стремительно рушится.
#ai #data #thoughts
В этом важное ограничение всех этих инструментов - у них нет доступа к огромным базам данных на которых можно строить аналитику. Я вот сомневаюсь что Bloomberg или S&P Global откроют свои базы для OpenAI или чего-то подобного, если только это не будет какое-то стратегическое партнерство. А вот применение ИИ к макропрогнозированию и работе с экономическими данными - это будет реальный прорыв для одних и катастрофа для других.
Поэтому одно из самых интересных направлений которые я вижу - это связывание языковых моделей с очень специальными большими банками данных и создание новых продуктов в этих областях.
А от AI краулеров почти все СМИ и иные контентные сайты начнут стремительно закрываться. И требовать убирать их контент из индексов этих AI моделей. Потому что бизнес модель контентных сайтов через рекламу или подписку скоро начнет стремительно рушится.
#ai #data #thoughts
В последнее время у меня было несколько разговоров с разными людьми, но все на одну и ту же тему что открытые данные тесно связаны с развитием свобод и демократии и что без них их не существует или становится меньше.
Хотя такая связь и есть, но из того что я много лет наблюдаю не только по РФ, но и по другим странам я вижу гораздо большую связь с устойчивостью государства, экономикой и качеством госуправления, которые, часто, высоки именно в развитых демократиях, но, при этом в демократиях бедных, к примеру, тема открытых данных не развита или на 100% зависит от внешних грантов.
В то время как внутренние инициативы по открытости данных есть в самых разных странах: Китае, Вьетнаме, Катаре, ОАЭ, Казахстане, Таиланде и даже в России в каком-то виде. Это те страны которые, к примеру, по Democracy Matrix [1] относятся к автократиям.
Про каждую страну можно не одну статью написать почему это так, и почему в этих странах, не входящих в ОЭСР или Open Government Partnership есть довольно продвинутые инициативы, законы, порталы и научные проекты про открытые данные и на их основе.
Почему так происходит? Что общего в этих странах?
У меня нет универсального ответа на этот вопрос, но есть несколько гипотез:
1. Вне зависимости от политического руководства страны не оспаривается нигде тезис что работа госаппарата по созданию и распределению общественного блага. По мере роста числа квалифицированных пользователей данными сотрудники госорганов как минимум часть своей работы раскрывают как данные просто потому что требуются дополнительные усилия чтобы эти материалы публиковать неудобным образом (в закрытых немашиночитаемых форматах).
2. Даже в авторитарных странах есть публичная коммуникация государства с гражданами и по мере нарастания госрасходов на информатизацию, раскрытие части данных является ответом на общественные запросы: "Зачем Вы потратили на это столько денег?", "Какая с этого польза гражданам?"
3. Коммуникация с местным и международным цифровым бизнесом, привлечение зарубежных инвесторов, демонстрация открытости рынка. В авторитарных странах чаще на порталах открытых данных речь идёт о коммуникации с бизнесом.
4. Развитие науки, создание проектов с раскрытием открытых научных данных
5. Демонстрация того что "вы называете нас авторитарными, а посмотрите, у нас качество госуправления и открытость повыше вашей"
6. Демонстрация устойчивости государства: "Мы сильные и устойчивые, нам нечего скрывать, наша открытость нас не пугает"
Есть и другие, более специфичные для конкретных стран гипотезы и доводы.
А есть и взгляд с другой стороны. Когда инициативы по открытости закрываются с невнятной коммуникацией ( Россия ) или когда вместо портала открытых данных есть портал закрытых данных только для граждан и с получением не более чем по 100 записей за раз (Казахстан), такие инициативы не говорят об устойчивости гос-ва, они дают только сигналы: "Мы боимся!", "Мы не умеем этим управлять!".
А я ещё не раз напишу с примерами о том как данные публикуют в недемократических государствах.
Ссылки:
[1] https://www.democracymatrix.com/ranking
#opendata #data #thoughts
Хотя такая связь и есть, но из того что я много лет наблюдаю не только по РФ, но и по другим странам я вижу гораздо большую связь с устойчивостью государства, экономикой и качеством госуправления, которые, часто, высоки именно в развитых демократиях, но, при этом в демократиях бедных, к примеру, тема открытых данных не развита или на 100% зависит от внешних грантов.
В то время как внутренние инициативы по открытости данных есть в самых разных странах: Китае, Вьетнаме, Катаре, ОАЭ, Казахстане, Таиланде и даже в России в каком-то виде. Это те страны которые, к примеру, по Democracy Matrix [1] относятся к автократиям.
Про каждую страну можно не одну статью написать почему это так, и почему в этих странах, не входящих в ОЭСР или Open Government Partnership есть довольно продвинутые инициативы, законы, порталы и научные проекты про открытые данные и на их основе.
Почему так происходит? Что общего в этих странах?
У меня нет универсального ответа на этот вопрос, но есть несколько гипотез:
1. Вне зависимости от политического руководства страны не оспаривается нигде тезис что работа госаппарата по созданию и распределению общественного блага. По мере роста числа квалифицированных пользователей данными сотрудники госорганов как минимум часть своей работы раскрывают как данные просто потому что требуются дополнительные усилия чтобы эти материалы публиковать неудобным образом (в закрытых немашиночитаемых форматах).
2. Даже в авторитарных странах есть публичная коммуникация государства с гражданами и по мере нарастания госрасходов на информатизацию, раскрытие части данных является ответом на общественные запросы: "Зачем Вы потратили на это столько денег?", "Какая с этого польза гражданам?"
3. Коммуникация с местным и международным цифровым бизнесом, привлечение зарубежных инвесторов, демонстрация открытости рынка. В авторитарных странах чаще на порталах открытых данных речь идёт о коммуникации с бизнесом.
4. Развитие науки, создание проектов с раскрытием открытых научных данных
5. Демонстрация того что "вы называете нас авторитарными, а посмотрите, у нас качество госуправления и открытость повыше вашей"
6. Демонстрация устойчивости государства: "Мы сильные и устойчивые, нам нечего скрывать, наша открытость нас не пугает"
Есть и другие, более специфичные для конкретных стран гипотезы и доводы.
А есть и взгляд с другой стороны. Когда инициативы по открытости закрываются с невнятной коммуникацией ( Россия ) или когда вместо портала открытых данных есть портал закрытых данных только для граждан и с получением не более чем по 100 записей за раз (Казахстан), такие инициативы не говорят об устойчивости гос-ва, они дают только сигналы: "Мы боимся!", "Мы не умеем этим управлять!".
А я ещё не раз напишу с примерами о том как данные публикуют в недемократических государствах.
Ссылки:
[1] https://www.democracymatrix.com/ranking
#opendata #data #thoughts
К вопросу о каталогах данных, которые я изучаю вот уже много лет, в особенности каталоги общедоступных и открытых данных, чем больше я наблюдаю рынок, экосистему и тд. в том числе относительно больших каталогов данных, тем больше убеждаюсь что весь этот рынок за очень короткое время может перемешать Microsoft или, с меньшей вероятностью, Gitlab, реализовав в Github/Gitlab такое понятие как репозиторий данных.
По сути и так огромное число датасетов публикуют через Git, особенно научные репозитории выкладывают на Github, а на размещённое там уже дают ссылки с какого нибудь Zenodo.
Причём сделать дата репозитории Microsoft может сделать очень дешёвым образом.
1. Добавить атрибут data к репозиториям с данными, чтобы их можно было бы выделить в поиске.
2. Добавить спецификацию в YAML с метаданными датасета/датасетов в этом репозитории. За основу можно взять DCAT.
К счастью или к сожалению, ничего такого они не делают и, как следствие, своего поиска по данным у Microsoft нет. Но если бы сделали то Github было бы проще индексировать с помощью Dateno.
#opendata #datasets #microsoft #github #thoughts
По сути и так огромное число датасетов публикуют через Git, особенно научные репозитории выкладывают на Github, а на размещённое там уже дают ссылки с какого нибудь Zenodo.
Причём сделать дата репозитории Microsoft может сделать очень дешёвым образом.
1. Добавить атрибут data к репозиториям с данными, чтобы их можно было бы выделить в поиске.
2. Добавить спецификацию в YAML с метаданными датасета/датасетов в этом репозитории. За основу можно взять DCAT.
К счастью или к сожалению, ничего такого они не делают и, как следствие, своего поиска по данным у Microsoft нет. Но если бы сделали то Github было бы проще индексировать с помощью Dateno.
#opendata #datasets #microsoft #github #thoughts
Прямо интересное явление последних лет - это восхождение декларативного программирования когда дело касается данных и инфраструктуры в первую очередь. Вместо написания кода, пишутся YAML или TOML файлы и на их основе бегают конвейеры данных, разворачивается инфраструктура, создаются базы данных или API сервера.
Вижу всё больше и больше таких продуктов, особенно в областях devOps, dataOps и в продуктах типа ELT/ETL и других в области современного стека данных. Я и сам в инструментах что создавал или создаю делаю такое же.
Очень скоро работа с данными не потребует знаний даже SQL потому что всё будет в этом самом декларативном программировании. Из известных мне популярных ETL/ELT движков разве что Dagster не на декларативных языках, а по модели data-as-a-code, все написано на Python.
Внутри Dateno тоже используется декларативный сбор данных с помощью движка datacrafter [1] который я изначально делал для совсем других задач по извлечению данных из API и по преобразованию файлов. А также вместе с datacrafter там работает движок apibackuper [2] в котором тоже декларативный язык но в виде конфига для Python. Его, по хорошему, надо переписать для работы с конфигом в YAML и ещё многое поправить.
Достоинство декларативных языков в том что легко генерировать эти конфиги. В Dateno краулер создаёт тысячи конфигов под каждый сайт и запускает сбор данных вызовом datacrafter'а, и уже потом собирает результаты и складывает в базу данных.
Большая часть источников данных там - это API, для каждого из которых свой шаблон и свои правила выгрузки. Иногда довольно непростые, но стандартизованные. И из имеющихся ETL движков только dlt такое может. По сути миграция кода - это преобразование одних YAML файлов в другие, при соблюдении ряда условий конечно, что схожие операции можно воспроизвести в другом движке.
Пока главный недостаток почти всех инструментов такого рода в отсутствии хорошей поддержки NoSQL в целом и MongoDB в частности. Из-за чего и приходится пользоваться собственным стеком инструментов.
Ссылки:
[1] https://github.com/apicrafter/datacrafter/
[2] https://github.com/ruarxive/apibackuper
#opensource #dataengineering #thoughts
Вижу всё больше и больше таких продуктов, особенно в областях devOps, dataOps и в продуктах типа ELT/ETL и других в области современного стека данных. Я и сам в инструментах что создавал или создаю делаю такое же.
Очень скоро работа с данными не потребует знаний даже SQL потому что всё будет в этом самом декларативном программировании. Из известных мне популярных ETL/ELT движков разве что Dagster не на декларативных языках, а по модели data-as-a-code, все написано на Python.
Внутри Dateno тоже используется декларативный сбор данных с помощью движка datacrafter [1] который я изначально делал для совсем других задач по извлечению данных из API и по преобразованию файлов. А также вместе с datacrafter там работает движок apibackuper [2] в котором тоже декларативный язык но в виде конфига для Python. Его, по хорошему, надо переписать для работы с конфигом в YAML и ещё многое поправить.
Достоинство декларативных языков в том что легко генерировать эти конфиги. В Dateno краулер создаёт тысячи конфигов под каждый сайт и запускает сбор данных вызовом datacrafter'а, и уже потом собирает результаты и складывает в базу данных.
Большая часть источников данных там - это API, для каждого из которых свой шаблон и свои правила выгрузки. Иногда довольно непростые, но стандартизованные. И из имеющихся ETL движков только dlt такое может. По сути миграция кода - это преобразование одних YAML файлов в другие, при соблюдении ряда условий конечно, что схожие операции можно воспроизвести в другом движке.
Пока главный недостаток почти всех инструментов такого рода в отсутствии хорошей поддержки NoSQL в целом и MongoDB в частности. Из-за чего и приходится пользоваться собственным стеком инструментов.
Ссылки:
[1] https://github.com/apicrafter/datacrafter/
[2] https://github.com/ruarxive/apibackuper
#opensource #dataengineering #thoughts
GitHub
GitHub - apicrafter/datacrafter: NoSQL extract, transform, load (ETL) toolkit with Python
NoSQL extract, transform, load (ETL) toolkit with Python - apicrafter/datacrafter
По поводу глобального синего экрана смерти из-за ошибки в антивирусе CrowdStrike [1] который поразил авиакомпании и тысячи критических инфраструктурных и просто компаний.
Ключевое тут - это хрупкость человечества и расширение списка мест этой хрупкости.
Но что пока радует так то что рукожопы пока лидируют в угрозе человечеству далеко обгоняя хакеров.
Ссылки:
[1] https://www.forbes.com/sites/kateoflahertyuk/2024/07/19/crowdstrike-windows-outage-what-happened-and-what-to-do-next/
#it #tech #thoughts
Ключевое тут - это хрупкость человечества и расширение списка мест этой хрупкости.
Но что пока радует так то что рукожопы пока лидируют в угрозе человечеству далеко обгоняя хакеров.
Ссылки:
[1] https://www.forbes.com/sites/kateoflahertyuk/2024/07/19/crowdstrike-windows-outage-what-happened-and-what-to-do-next/
#it #tech #thoughts
Поработав в избытке с данными и со смыслом публикации разной статистики, в какой-то момент напишу лонгрид на тему того как хорошо и как плохо публикуют статистику в разных странах и территориях, а пока в виде выжимки накопленные мысли. Поскольку я на эту тему несколько раз уже писал в таком формате, то где-то могу и повторяться:
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
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
Я уже рассказывал про геоклассификацию данных в Dateno и то что существенная фича в поиске - это возможность поиска по городам/регионам, на субрегиональном уровне. Классификация датасетов по субрегионам основана почти полностью на аннотировании каталогов данных и с этой точки зрения это довольно простая задача с понятным решением.
Как оказывается куда менее простой задачей является привязка датасетов к странам и макрорегионам.
Базово привязка эта привязка делается через привязку каталога данных которые, как правило, конкретными странами ограничены. К примеру, если есть национальный портал данных какой-то страны, то и данные почти всегда касаются этой страны. Но это самые простые случаи и в основном про порталы открытых данных и про геопорталы.
Сложности начинаются с научными данными. Большая их часть чёткой геопривязки может не иметь вообще, кроме ну разве что, академического института(-ов) авторов и их местонахождения. Исключение составляют редкие датасеты из наук о земле, лингвистики и ещё ряда научных дисциплин.
Другая сложность возникает со всей статистикой и производными индикаторами. Помимо стат. показателей по странам существует неимоверное число разных групп стран, от простых, до хитровыдуманных. К примеру, группы арабских стран, страны MENA, G20, G7, Андское сообщество, наименее развитые страны, страны без выхода к морю и ещё много какие. Причём, конечно, группы стран пересекаются, но не всегда входят в друг друга.
Внутри Dateno, при этом, для группировки стран используется список макрорегионов из UN M49. Разметить страны по вхождение в эти макрорегионы несложно и внутренний справочник для этого есть. А вот справочника вхождения стран в эти многочисленные группы и их пересечений - нет и его надо составлять де-факто полувручную и нет кого-то кто бы поддерживал такую живую базу данных или программную библиотеку.
Поэтому георазметка реальных мировых статистических данных - это боль, требующая большой ручной работы по привязке к макрорегионам.
Пока что отсутствие привязки каких-то датасетов к странам и макрорегионам не так критичны поскольку другие поисковики даже такого не поддерживают и есть фасеты где разметка куда хуже. К примеру, наличие информации о лицензии есть не более чем у 10% датасетов.
Тем не менее качество фасетов в Dateno влияет на пользовательский опыт и это важная задача для построения максимально достоверного поискового индекса по данным.
#dateno #statistics #indicators #geodata #geo #thoughts
Как оказывается куда менее простой задачей является привязка датасетов к странам и макрорегионам.
Базово привязка эта привязка делается через привязку каталога данных которые, как правило, конкретными странами ограничены. К примеру, если есть национальный портал данных какой-то страны, то и данные почти всегда касаются этой страны. Но это самые простые случаи и в основном про порталы открытых данных и про геопорталы.
Сложности начинаются с научными данными. Большая их часть чёткой геопривязки может не иметь вообще, кроме ну разве что, академического института(-ов) авторов и их местонахождения. Исключение составляют редкие датасеты из наук о земле, лингвистики и ещё ряда научных дисциплин.
Другая сложность возникает со всей статистикой и производными индикаторами. Помимо стат. показателей по странам существует неимоверное число разных групп стран, от простых, до хитровыдуманных. К примеру, группы арабских стран, страны MENA, G20, G7, Андское сообщество, наименее развитые страны, страны без выхода к морю и ещё много какие. Причём, конечно, группы стран пересекаются, но не всегда входят в друг друга.
Внутри Dateno, при этом, для группировки стран используется список макрорегионов из UN M49. Разметить страны по вхождение в эти макрорегионы несложно и внутренний справочник для этого есть. А вот справочника вхождения стран в эти многочисленные группы и их пересечений - нет и его надо составлять де-факто полувручную и нет кого-то кто бы поддерживал такую живую базу данных или программную библиотеку.
Поэтому георазметка реальных мировых статистических данных - это боль, требующая большой ручной работы по привязке к макрорегионам.
Пока что отсутствие привязки каких-то датасетов к странам и макрорегионам не так критичны поскольку другие поисковики даже такого не поддерживают и есть фасеты где разметка куда хуже. К примеру, наличие информации о лицензии есть не более чем у 10% датасетов.
Тем не менее качество фасетов в Dateno влияет на пользовательский опыт и это важная задача для построения максимально достоверного поискового индекса по данным.
#dateno #statistics #indicators #geodata #geo #thoughts
unstats.un.org
UNSD — Methodology
United Nations Statistics Divisin - Methodology
Не так страшны законы как их беззаконное применение (с)
По поводу свежего законопроекта по которому все телеграм каналы/блоггеры 10 тысячники должны регистрироваться в РКН, я так скажу.
Ключевое в том как его будут применять. Во первых, Россия != русский язык, а русский язык != Россия. Русскоязычные телеграм каналы могут вестись где угодно в мире и ориентироваться на теперь уже особенно широкую диаспору. Их авторы могут иметь паспорта Канады, Испании, Израиля, Армении и десятков других стран. Их авторы могут уже вообще не иметь связи с РФ. Так по какому критерию РКН будет и сможет соотносить их с Россией?
По аудитории? Телеграм не даёт её в разбивке по странам. По гражданству владельца ? А откуда бы у них такая инфа? По коду телефонного номера? Так и он может быть не российским. Более того у телеграм канала может быть много админов и много авторов, иногда десятки авторов, тут то как быть?
Ещё важно помнить что телеграм каналы - это не сайты/домены. Заблокировать их нельзя, платформа не позволяет такое.
Поэтому знаете какой самый основной критерий получается ? По размещению рекламы российских юр. лиц и ИП. Это то что может ударить по карману тех русскоязычных телеграм канало владельцев которые зарабатывают на рекламе из РФ и на аудиторию в РФ.
У меня до 10 тысяч подписчиков немало, но желания размещать рекламу как не было так и нет. Выгода от разговора с профессиональной русскоязычной аудиторией разбросанной по всему миру перевешивает рекламные деньги с лихвой.
Поправьте меня если я неправ.
#blogging #thoughts #telegram #regulation
По поводу свежего законопроекта по которому все телеграм каналы/блоггеры 10 тысячники должны регистрироваться в РКН, я так скажу.
Ключевое в том как его будут применять. Во первых, Россия != русский язык, а русский язык != Россия. Русскоязычные телеграм каналы могут вестись где угодно в мире и ориентироваться на теперь уже особенно широкую диаспору. Их авторы могут иметь паспорта Канады, Испании, Израиля, Армении и десятков других стран. Их авторы могут уже вообще не иметь связи с РФ. Так по какому критерию РКН будет и сможет соотносить их с Россией?
По аудитории? Телеграм не даёт её в разбивке по странам. По гражданству владельца ? А откуда бы у них такая инфа? По коду телефонного номера? Так и он может быть не российским. Более того у телеграм канала может быть много админов и много авторов, иногда десятки авторов, тут то как быть?
Ещё важно помнить что телеграм каналы - это не сайты/домены. Заблокировать их нельзя, платформа не позволяет такое.
Поэтому знаете какой самый основной критерий получается ? По размещению рекламы российских юр. лиц и ИП. Это то что может ударить по карману тех русскоязычных телеграм канало владельцев которые зарабатывают на рекламе из РФ и на аудиторию в РФ.
У меня до 10 тысяч подписчиков немало, но желания размещать рекламу как не было так и нет. Выгода от разговора с профессиональной русскоязычной аудиторией разбросанной по всему миру перевешивает рекламные деньги с лихвой.
Поправьте меня если я неправ.
#blogging #thoughts #telegram #regulation
Довольно давно хочу написать гневный пост о том куда катятся современные цифровые продукты и разработка софта в целом, в целом катятся они далеко от пользователя/клиента/потребителя. Причём чем более массовое ПО, тем хуже. Начиная от "распухания" дистрибутивов где совершенно непонятно зачем нужно ставить несколько гигабайт для данного приложения, продолжая непомерным потреблением CPU и оперативной памяти и утечками памяти и постоянной загрузкой CPU у приложений которым просто незачем это делать.
Но важнее всего это всё больший сдвиг почти всех продуктов к подписочной и облачной модели. Всё больше продуктов которые нельзя купить единожды. При том что устроены они так что в постоянном их использовании нет необходимости.
Впрочем всё это потянет на рассуждения не в одном, во многих лонгридах.
А пока же для размышления, ONCE [1] новая-старая бизнес модель которую пропагандируют 37Signals и называют её Post SaaS. Анонсируют подход к распространению их продуктов за фиксированную цену, без подписки, скрытых платежей и тд.
Дословно их принципы звучат так:
- Платите один раз, владейте навсегда.
- Мы пишем код, вы его видите.
- Мы предоставляем вам программное обеспечение, вы размещаете его у себя.
- Просто и понятно, а не корпоративно и раздуто.
- За одну фиксированную цену. Один раз.
Сейчас по такой модели они продают чат Campfile за $299 [2] однократного платежа и раздают бесплатно Writebook [3], ПО для написания онлайн книг.
Что я могу сказать. Если это станет трендом, то многие SaaS стартапы поломаются или переквалифицируются, но точно потеряют сверхдоходы.
Для квалифицированного пользователя, конечно, подходы вроде ONCE или такие как Local-first, гораздо лучше.
Ссылки:
[1] https://once.com/
[2] https://once.com/campfire
[3] https://once.com/writebook
#thoughts #business #software
Но важнее всего это всё больший сдвиг почти всех продуктов к подписочной и облачной модели. Всё больше продуктов которые нельзя купить единожды. При том что устроены они так что в постоянном их использовании нет необходимости.
Впрочем всё это потянет на рассуждения не в одном, во многих лонгридах.
А пока же для размышления, ONCE [1] новая-старая бизнес модель которую пропагандируют 37Signals и называют её Post SaaS. Анонсируют подход к распространению их продуктов за фиксированную цену, без подписки, скрытых платежей и тд.
Дословно их принципы звучат так:
- Платите один раз, владейте навсегда.
- Мы пишем код, вы его видите.
- Мы предоставляем вам программное обеспечение, вы размещаете его у себя.
- Просто и понятно, а не корпоративно и раздуто.
- За одну фиксированную цену. Один раз.
Сейчас по такой модели они продают чат Campfile за $299 [2] однократного платежа и раздают бесплатно Writebook [3], ПО для написания онлайн книг.
Что я могу сказать. Если это станет трендом, то многие SaaS стартапы поломаются или переквалифицируются, но точно потеряют сверхдоходы.
Для квалифицированного пользователя, конечно, подходы вроде ONCE или такие как Local-first, гораздо лучше.
Ссылки:
[1] https://once.com/
[2] https://once.com/campfire
[3] https://once.com/writebook
#thoughts #business #software
ONCE
Introducing ONCE
Once upon a time you owned what you paid for, you controlled what you depended on, and your privacy and security were your own business. We think it’s that time again.