В рубрике стартапов на данных и связанных с данными
- CloudQuery [1] сервис инвентаризации облачных активов. Это когда у вас серверов и других сервисов много, а управлять ими уже сложно ну или надо хотя бы знать где что находится. Также есть в открытом коде [2]. Подняли $15M инвестиций 22 июня [3]
- Avo [4] система управления аналитикой и прослеживаемостью пользователей. Подняли $5M в 5 раундов, последний раунд в сентябре 2020 г. Дают удобный интерфейс для отслеживания каждого пользователя и с интеграцией с RudderStack, Segment, Posthog и другими инструментами.
- Y42 [5] платформа управления данными с претензией на полный цикл охвата: интеграция, моделирование, визуализация и оркестрация. Всего подняли 33.9M в 2 раунда. Последний раунд в октябре 2021 г.
- Castor [6], стартап по каталогизации данных, получил инвестиций в объёме $23.5M в начале июня [7]. В основном делают акцент на большей понимаемости данных, удобном интерфейсе каталога и тд.
- Immuta [8] разработчики платформы по защите данных с функциями обнаружения чувствительных данных подняли раунд E на $100M [9] инвестиций. Это корпоративный каталог с акцентом на интеграцию со всеми крупнейшими облачными базами данных Snowflake, RedShift, BigQuery и тд. Общий объём привлеченных ими инвестиций $276M
Ссылки:
[1] https://www.cloudquery.io/
[2] https://github.com/cloudquery/cloudquery
[3] https://www.cloudquery.io/blog/cloudquery-raises-15m-series-a
[4] https://www.avo.app/
[5] https://www.y42.com/
[6] https://www.castordoc.com/
[7] https://techcrunch.com/2022/06/07/castor-a-data-catalog-startup-nabs-23-5m-to-expand-its-platform/
[8] https://www.immuta.com
[9] https://www.immuta.com/articles/series-e-funding-announcement/
#startups #data #itmarket
- CloudQuery [1] сервис инвентаризации облачных активов. Это когда у вас серверов и других сервисов много, а управлять ими уже сложно ну или надо хотя бы знать где что находится. Также есть в открытом коде [2]. Подняли $15M инвестиций 22 июня [3]
- Avo [4] система управления аналитикой и прослеживаемостью пользователей. Подняли $5M в 5 раундов, последний раунд в сентябре 2020 г. Дают удобный интерфейс для отслеживания каждого пользователя и с интеграцией с RudderStack, Segment, Posthog и другими инструментами.
- Y42 [5] платформа управления данными с претензией на полный цикл охвата: интеграция, моделирование, визуализация и оркестрация. Всего подняли 33.9M в 2 раунда. Последний раунд в октябре 2021 г.
- Castor [6], стартап по каталогизации данных, получил инвестиций в объёме $23.5M в начале июня [7]. В основном делают акцент на большей понимаемости данных, удобном интерфейсе каталога и тд.
- Immuta [8] разработчики платформы по защите данных с функциями обнаружения чувствительных данных подняли раунд E на $100M [9] инвестиций. Это корпоративный каталог с акцентом на интеграцию со всеми крупнейшими облачными базами данных Snowflake, RedShift, BigQuery и тд. Общий объём привлеченных ими инвестиций $276M
Ссылки:
[1] https://www.cloudquery.io/
[2] https://github.com/cloudquery/cloudquery
[3] https://www.cloudquery.io/blog/cloudquery-raises-15m-series-a
[4] https://www.avo.app/
[5] https://www.y42.com/
[6] https://www.castordoc.com/
[7] https://techcrunch.com/2022/06/07/castor-a-data-catalog-startup-nabs-23-5m-to-expand-its-platform/
[8] https://www.immuta.com
[9] https://www.immuta.com/articles/series-e-funding-announcement/
#startups #data #itmarket
www.cloudquery.io
Data Fabric for Cloud and Security Teams | CloudQuery
Load data from any source to any destination, transform and visualize. Based on our popular open source project. Self-host or run it in our cloud.
В качестве регулярного напоминания проект по созданию каталога каталогов данных DataCatalogs [1] созданный командой @infoculture.
В нем собрано описание 263 каталогов данных всех типов и категорий: открытых, закрытых, государственных, общественных, частных и тд., сгруппированных по 115 темам.
Этот сайт создан поверх базы в Airtable которую мы ведем в Инфокультуре и можно предложить туда каталог данных через форму на сайте [2].
У Airtable есть большие достоинства в удобстве моделирования и ведения базы данных вручную, но минусы в проприетарности и невозможности простого построения веб-интерфейса открытыми решениями.
Из незавершённого:
- нет экспорта каталога в открытые данные и выкладкой на сайте или в Github. Проще всего через Github Actions скорее всего
- нет автоматизированного пополнения Awesome Opendata Russia [3], списка ссылок на порталы и ресурсы по открытым данным в России.
Если есть идеи и предложения по развитию этого каталога каталогов, присылайте нам, возьмём в работу.
Ссылки:
[1] https://datacatalogs.ru
[2] https://www.datacatalogs.ru/add-resource
[3] https://github.com/infoculture/awesome-opendata-rus
#opendata #russia #datasets #datacatalogs
В нем собрано описание 263 каталогов данных всех типов и категорий: открытых, закрытых, государственных, общественных, частных и тд., сгруппированных по 115 темам.
Этот сайт создан поверх базы в Airtable которую мы ведем в Инфокультуре и можно предложить туда каталог данных через форму на сайте [2].
У Airtable есть большие достоинства в удобстве моделирования и ведения базы данных вручную, но минусы в проприетарности и невозможности простого построения веб-интерфейса открытыми решениями.
Из незавершённого:
- нет экспорта каталога в открытые данные и выкладкой на сайте или в Github. Проще всего через Github Actions скорее всего
- нет автоматизированного пополнения Awesome Opendata Russia [3], списка ссылок на порталы и ресурсы по открытым данным в России.
Если есть идеи и предложения по развитию этого каталога каталогов, присылайте нам, возьмём в работу.
Ссылки:
[1] https://datacatalogs.ru
[2] https://www.datacatalogs.ru/add-resource
[3] https://github.com/infoculture/awesome-opendata-rus
#opendata #russia #datasets #datacatalogs
YaLM 100B [1] GPT-подобная нейросеть для обработки и создания текста. Доступна под лицензией Apache 2.0 и вчера выложена командой Яндекса на Github.
Авторы заявляют 100 миллиардов параметров, отсюда 100B в названии, и то что модель создавалась на основе 1.7 ТБ текстов и рассчитывалась 65 дней на кластере из 800 видеокарт A100.
Подробнее в статье в Medium [2] и на Habr [3].
Ссылки:
[1] https://github.com/yandex/YaLM-100B
[2] https://medium.com/yandex/yandex-publishes-yalm-100b-its-the-largest-gpt-like-neural-network-in-open-source-d1df53d0e9a6
[3] https://habr.com/ru/company/yandex/blog/672396/
#datasets #gpt #neuralnetworks #ai
Авторы заявляют 100 миллиардов параметров, отсюда 100B в названии, и то что модель создавалась на основе 1.7 ТБ текстов и рассчитывалась 65 дней на кластере из 800 видеокарт A100.
Подробнее в статье в Medium [2] и на Habr [3].
Ссылки:
[1] https://github.com/yandex/YaLM-100B
[2] https://medium.com/yandex/yandex-publishes-yalm-100b-its-the-largest-gpt-like-neural-network-in-open-source-d1df53d0e9a6
[3] https://habr.com/ru/company/yandex/blog/672396/
#datasets #gpt #neuralnetworks #ai
GitHub
GitHub - yandex/YaLM-100B: Pretrained language model with 100B parameters
Pretrained language model with 100B parameters. Contribute to yandex/YaLM-100B development by creating an account on GitHub.
Forwarded from Национальный цифровой архив
Продолжается кампания по архивации российских сайтов СМИ, медиа и культурных инициатив
Веб-архивы сайтов доступны для скачивания в формате WARC и открываются в приложении ReplayWeb.page.
Сведения о планах архивации и сохраненных ресурсах доступны в открытой таблице.
Если вы знаете, какой сайт может стать утерянным, сообщите нам об этом с помощью специальной формы.
В это же время в Великобритании в национальной библиотеке проходит выставка «Breaking the News», для которой используются сохраненные новости из веб-архива Великобритании (UKWA). Коллекция «Новости» в UKWA содержит веб-архивы более 2700 новостных сайтов. Туда входят крупные национальные новостные издания — BBC, Guardian, Daily Mail и т.д. Помимо этого собираются веб-архивы тысячи местных новостных сайтов, посвященных жизни отдельных городов и деревень.
Большинство архивов можно просмотреть только в читальных залах библиотек Великобритании, однако есть и те, которые доступны для просмотра онлайн, например, веб-архив сайта Brixton Blog.
Веб-архивы сайтов доступны для скачивания в формате WARC и открываются в приложении ReplayWeb.page.
Сведения о планах архивации и сохраненных ресурсах доступны в открытой таблице.
Если вы знаете, какой сайт может стать утерянным, сообщите нам об этом с помощью специальной формы.
В это же время в Великобритании в национальной библиотеке проходит выставка «Breaking the News», для которой используются сохраненные новости из веб-архива Великобритании (UKWA). Коллекция «Новости» в UKWA содержит веб-архивы более 2700 новостных сайтов. Туда входят крупные национальные новостные издания — BBC, Guardian, Daily Mail и т.д. Помимо этого собираются веб-архивы тысячи местных новостных сайтов, посвященных жизни отдельных городов и деревень.
Большинство архивов можно просмотреть только в читальных залах библиотек Великобритании, однако есть и те, которые доступны для просмотра онлайн, например, веб-архив сайта Brixton Blog.
Мало кто думает об архивации чего-бы то ни было как потеряв какие-то очень важные данные или файлы. Личное осознание значимости бэкапов - это часто последствия личного же травматического опыта.
Практические механизмы применяемые в корпоративной среде - это, чаще всего, разного рода инструменты входящие в состав операционной системы. А для СУБД - это чаще генерация дампов баз данных специфичных для конкретной СУБД.
Когда речь заходит об архивации на системном уровне то возникает вопрос стандартов и универсальных спецификаций. А их и то оказывается не так много. У библиотеки Конгресса США есть коллекция форматов рассматриваемых для архивации табличных данных/баз данных [1]․
Почти все они - это форматы обмена данными, такие как XML, JSON, CSV, HDF, CDF, XLS и тд. Рекомендуемыми форматами для данных при этом являются CSV/TSV и SQLite [2].
А вот в Швейцарии разработали и приняли ещё в 2013 году стандарт SIARD, его описание также есть в библиотеке Конгресса [3]. Этот стандарт описывает унифицированный экспорт баз данных не только с точки зрения данных, но и всех связанных объектов, понятий, артефактов и метаданных. Стандарт не самый древний, но ограниченный с самого начала такими СУБД как Oracle, Microsoft SQL Server, MySQL, IBM DB2, Microsoft Access. Тут не то что NoSQL нет, но и нет поддержки облачных СУБД, нет многих популярных баз данных и не только. А сам стандарт с 2015 года практически не развивался.
Что характерно, других универсальных стандартов экспорта/импорта СУБД не существует. Что иногда кажется странным, поскольку в ИТ очень любят разрабатывать собственные спецификации. Например, в Modern Data Stack уже есть множество стандартов описания метаданных в СУБД таких как OpenMetadata [4] и OpenLineage [5] которые довольно сильно пересекаются с SIARD в части метаданных описывающих данные, но не заходят в область непосредственно сохранения контента.
Вопрос о том как сохранять унаследованные данные после закрытия проектов по прежнему открытый. Всё что я могу вспомнить даже в довольно крупных организациях - это положенные на сетевое хранилище дампы с кратким описанием содержания.
Ссылки:
[1] https://www.loc.gov/preservation/digital/formats/fdd/dataset_fdd.shtml
[2] https://www.loc.gov/preservation/resources/rfs/data.html
[3] https://www.loc.gov/preservation/digital/formats/fdd/fdd000426.shtml
[4] https://docs.open-metadata.org/metadata-standard/schemas
[5] https://github.com/OpenLineage/OpenLineage
#databases #digitalpreservation
Практические механизмы применяемые в корпоративной среде - это, чаще всего, разного рода инструменты входящие в состав операционной системы. А для СУБД - это чаще генерация дампов баз данных специфичных для конкретной СУБД.
Когда речь заходит об архивации на системном уровне то возникает вопрос стандартов и универсальных спецификаций. А их и то оказывается не так много. У библиотеки Конгресса США есть коллекция форматов рассматриваемых для архивации табличных данных/баз данных [1]․
Почти все они - это форматы обмена данными, такие как XML, JSON, CSV, HDF, CDF, XLS и тд. Рекомендуемыми форматами для данных при этом являются CSV/TSV и SQLite [2].
А вот в Швейцарии разработали и приняли ещё в 2013 году стандарт SIARD, его описание также есть в библиотеке Конгресса [3]. Этот стандарт описывает унифицированный экспорт баз данных не только с точки зрения данных, но и всех связанных объектов, понятий, артефактов и метаданных. Стандарт не самый древний, но ограниченный с самого начала такими СУБД как Oracle, Microsoft SQL Server, MySQL, IBM DB2, Microsoft Access. Тут не то что NoSQL нет, но и нет поддержки облачных СУБД, нет многих популярных баз данных и не только. А сам стандарт с 2015 года практически не развивался.
Что характерно, других универсальных стандартов экспорта/импорта СУБД не существует. Что иногда кажется странным, поскольку в ИТ очень любят разрабатывать собственные спецификации. Например, в Modern Data Stack уже есть множество стандартов описания метаданных в СУБД таких как OpenMetadata [4] и OpenLineage [5] которые довольно сильно пересекаются с SIARD в части метаданных описывающих данные, но не заходят в область непосредственно сохранения контента.
Вопрос о том как сохранять унаследованные данные после закрытия проектов по прежнему открытый. Всё что я могу вспомнить даже в довольно крупных организациях - это положенные на сетевое хранилище дампы с кратким описанием содержания.
Ссылки:
[1] https://www.loc.gov/preservation/digital/formats/fdd/dataset_fdd.shtml
[2] https://www.loc.gov/preservation/resources/rfs/data.html
[3] https://www.loc.gov/preservation/digital/formats/fdd/fdd000426.shtml
[4] https://docs.open-metadata.org/metadata-standard/schemas
[5] https://github.com/OpenLineage/OpenLineage
#databases #digitalpreservation
www.loc.gov
Format Descriptions for Dataset Formats
Browse an alphabetical list of format descriptions for digital formats used for datasets (e.g., scientific or numeric datasets). The format descriptions provide specific information about individual formats and their characteristics.
В рубрике интересных наборов данных, VizNet [1], четыре корпуса данных Plotly, ManyEyes, Webtables, Open data portal, собранных из этих источников. По сути VizNet содержит большой срез данных высокого качества из открытого доступа и позволяет проводить исследования по визуализации, анализу, аннотированию и машинному обучению на данных.
Проект создан внутри MIT Media Labs и, например, используется в системе Sherlock [2] для идентификации семантических типов данных.
Ссылки:
[1] https://github.com/mitmedialab/viznet
[2] https://github.com/mitmedialab/sherlock-project
#opendata #datasets
Проект создан внутри MIT Media Labs и, например, используется в системе Sherlock [2] для идентификации семантических типов данных.
Ссылки:
[1] https://github.com/mitmedialab/viznet
[2] https://github.com/mitmedialab/sherlock-project
#opendata #datasets
GitHub
GitHub - mitmedialab/viznet: VizNet is a repository providing real-world datasets that enable, among other things, (re)running…
VizNet is a repository providing real-world datasets that enable, among other things, (re)running empirical studies with higher ecological validity - mitmedialab/viznet
Postman опубликовали обновление API Platform Landscape [1] с перечнем продуктов и трендов в мире API.
Ключевые тезисы оттуда:
1. Компании переходят к модели API-first
2. Гибридная архитектура и многооблачность
3. API как продукт
4. Взрывной рост продуктов API Gateway
5. Всё больше протоколов для API в активном использовании.
6. Всё больший сдвиг в сторону безопасности доступа к API.
Не все согласятся что экосистема API существует автономна, например, для меня это скорее часть экосистемы работы с данными, а Postman показывают её с выгодной для них стороны там где они лидеры, но, тем не менее, в части описанного, тренды изложены верно и сам обзор полезен.
Ссылки:
[1] https://blog.postman.com/2022-api-platform-landscape-trends-and-challenges/
#api
Ключевые тезисы оттуда:
1. Компании переходят к модели API-first
2. Гибридная архитектура и многооблачность
3. API как продукт
4. Взрывной рост продуктов API Gateway
5. Всё больше протоколов для API в активном использовании.
6. Всё больший сдвиг в сторону безопасности доступа к API.
Не все согласятся что экосистема API существует автономна, например, для меня это скорее часть экосистемы работы с данными, а Postman показывают её с выгодной для них стороны там где они лидеры, но, тем не менее, в части описанного, тренды изложены верно и сам обзор полезен.
Ссылки:
[1] https://blog.postman.com/2022-api-platform-landscape-trends-and-challenges/
#api
Из важного, Microsoft серьёзно пересматривают подход к этике ИИ, о чём пишут у себя в блоге [1], а также анонсируют вторую версию стандарта ответственного ИИ [2].
В контексте этого стандарта они закрыли для доступа их API распознавания лиц и эмоций [3] и это, также, весьма важный шаг саморегулирования ответственности корпораций.
И здесь я не могу не кинуть камень в огород российского кодекса этики ИИ [4] и важной разнице между ним и то в каком направлении сейчас движутся международные корпорации вроде Microsoft.
В российском кодексе этики ИИ явно декларируется требование соответствия законам, тем самым ставя компании которые имеют компетенции в этой области заведомо ниже законодателей у которых гарантированно компетенций в разы, если не на порядок меньше.
В стандарте Microsoft и иных подобных документах декларируется позиция корпорации которая и предполагается как будущая основа для законов.
Поэтому стандарт Microsoft будет иметь влияние на нашу с Вами жизнь, а российский кодекс этики ИИ не будет.
Ссылки:
[1] https://blogs.microsoft.com/on-the-issues/2022/06/21/microsofts-framework-for-building-ai-systems-responsibly/
[2] https://blogs.microsoft.com/wp-content/uploads/prod/sites/5/2022/06/Microsoft-Responsible-AI-Standard-v2-General-Requirements-3.pdf
[3] https://www.theverge.com/2022/6/21/23177016/microsoft-retires-emotion-recognition-azure-ai-tool-api
[4] https://bit.ly/3nfk7Lz
#ai #dataethics #aiethics #microsoft
В контексте этого стандарта они закрыли для доступа их API распознавания лиц и эмоций [3] и это, также, весьма важный шаг саморегулирования ответственности корпораций.
И здесь я не могу не кинуть камень в огород российского кодекса этики ИИ [4] и важной разнице между ним и то в каком направлении сейчас движутся международные корпорации вроде Microsoft.
В российском кодексе этики ИИ явно декларируется требование соответствия законам, тем самым ставя компании которые имеют компетенции в этой области заведомо ниже законодателей у которых гарантированно компетенций в разы, если не на порядок меньше.
В стандарте Microsoft и иных подобных документах декларируется позиция корпорации которая и предполагается как будущая основа для законов.
Поэтому стандарт Microsoft будет иметь влияние на нашу с Вами жизнь, а российский кодекс этики ИИ не будет.
Ссылки:
[1] https://blogs.microsoft.com/on-the-issues/2022/06/21/microsofts-framework-for-building-ai-systems-responsibly/
[2] https://blogs.microsoft.com/wp-content/uploads/prod/sites/5/2022/06/Microsoft-Responsible-AI-Standard-v2-General-Requirements-3.pdf
[3] https://www.theverge.com/2022/6/21/23177016/microsoft-retires-emotion-recognition-azure-ai-tool-api
[4] https://bit.ly/3nfk7Lz
#ai #dataethics #aiethics #microsoft
Microsoft On the Issues
Microsoft’s framework for building AI systems responsibly
Today we are sharing publicly Microsoft’s Responsible AI Standard, a framework to guide how we build AI systems. It is an important step in our journey to develop better, more trustworthy AI. We are releasing our latest Responsible AI Standard to share what…
Полезное чтение о методике JTBD (jobs-to-be-done) для дата-команд [1]
В тексте фокус на ключевых задачах дата команд, в основном в контексте средних-крупных компаний, тем не менее справедливо в любом контексте.
Если Вы работаете в команде работающей с данными как с продуктом - это текст точно про Вашу работу.
Ссылки:
[1] https://locallyoptimistic.com/post/building-more-effective-data-teams-using-the-jtbd-framework/
#readings #data #datateams
В тексте фокус на ключевых задачах дата команд, в основном в контексте средних-крупных компаний, тем не менее справедливо в любом контексте.
Если Вы работаете в команде работающей с данными как с продуктом - это текст точно про Вашу работу.
Ссылки:
[1] https://locallyoptimistic.com/post/building-more-effective-data-teams-using-the-jtbd-framework/
#readings #data #datateams
Мало кто знает что многие файлы с данными находятся не на порталах открытых данных, не в поисковиках вроде Google Dataset Search или DataCite, а на крупнейших хостингах кода таких как Github.
Поисковая система Github'а поддерживает запросы с указанием части названия файла, простым поиском можно найти десятки миллионов файлов в форматах .json, .csv, .xml, .sqlite.
Пример запроса filename:.csv [1] конечно, надо помнить что у Github'а нет сбора метаданных как в других поисковиках, но, при этом, объём хранимых данных количественно превосходит все остальные источники вместе взятые. Хотя и по объёму, наверное, меньше чем реестр открытых данных Amazon.
Как бы то ни было - это бесценный исследовательский материал, полезный всем кто изучает то какие данные существуют и из чего они состоят.
Также у Github'а много других, расширенных опций для поиска [2] которыми, на удивление, многие редко пользуются
Ссылки:
[1] https://github.com/search?q=filename%3A.csv&type=code
[2] https://github.com/search/advanced
#opendata #github #opensource
Поисковая система Github'а поддерживает запросы с указанием части названия файла, простым поиском можно найти десятки миллионов файлов в форматах .json, .csv, .xml, .sqlite.
Пример запроса filename:.csv [1] конечно, надо помнить что у Github'а нет сбора метаданных как в других поисковиках, но, при этом, объём хранимых данных количественно превосходит все остальные источники вместе взятые. Хотя и по объёму, наверное, меньше чем реестр открытых данных Amazon.
Как бы то ни было - это бесценный исследовательский материал, полезный всем кто изучает то какие данные существуют и из чего они состоят.
Также у Github'а много других, расширенных опций для поиска [2] которыми, на удивление, многие редко пользуются
Ссылки:
[1] https://github.com/search?q=filename%3A.csv&type=code
[2] https://github.com/search/advanced
#opendata #github #opensource
Кажется я ещё ни разу об этом не писал, о том как сопоставить метрики качества данных используемые в Modern Data Stack и в порталах открытых данных. Во многом там разные подходы, я писал о разнице между разными типами каталогов в большом тексте на Medium.
В блоге Towards Data Science полезный текст от Prukalpa, сооснователя стартапа Atlan, про методику 5WH1
5WH1 - это список вопросов по качеству данных на которые нужны ответы: What, Why, Where, Who, When, and How.
Или, по русски։ Что, Почему, Где, Кто, Когда и Как
В целом - это перечень метаданных которые должны собираться о данных для понимания того как данные устроены и что с ними делать. В корпоративном мире применение этой методики или подобных - это нечто безусловно актуальное и важное, особенно при работе многих команд. В мире открытых данных всё несколько иначе. Данные в виде файлов, их владельцы уже часто недоступны и много исторических данных по которым мало метаданных в принципе.
Тем не менее, наиболее продуманный стандарт мониторинга качества метаданных - это европейский MQA (Metadata Quality Assurance). Но критерии там иные: Findability, Accessibility, Interoperabilty, Contextuality, Reusability.
Перечень метаданных собираемых в рамках агрегации описаний по стандарту DCAT-AP для открытых данных даже больше, но и качество данных многократно ниже.
Подробнее и со ссылками в моей заметке на Medium на английском [1]
Ссылки:
[1] https://medium.com/@ibegtin/data-catalogs-part-3-metadata-quality-observation-c49be890f6ff
#opendata #metadata #dataquality
В блоге Towards Data Science полезный текст от Prukalpa, сооснователя стартапа Atlan, про методику 5WH1
5WH1 - это список вопросов по качеству данных на которые нужны ответы: What, Why, Where, Who, When, and How.
Или, по русски։ Что, Почему, Где, Кто, Когда и Как
В целом - это перечень метаданных которые должны собираться о данных для понимания того как данные устроены и что с ними делать. В корпоративном мире применение этой методики или подобных - это нечто безусловно актуальное и важное, особенно при работе многих команд. В мире открытых данных всё несколько иначе. Данные в виде файлов, их владельцы уже часто недоступны и много исторических данных по которым мало метаданных в принципе.
Тем не менее, наиболее продуманный стандарт мониторинга качества метаданных - это европейский MQA (Metadata Quality Assurance). Но критерии там иные: Findability, Accessibility, Interoperabilty, Contextuality, Reusability.
Перечень метаданных собираемых в рамках агрегации описаний по стандарту DCAT-AP для открытых данных даже больше, но и качество данных многократно ниже.
Подробнее и со ссылками в моей заметке на Medium на английском [1]
Ссылки:
[1] https://medium.com/@ibegtin/data-catalogs-part-3-metadata-quality-observation-c49be890f6ff
#opendata #metadata #dataquality
В рубрике больших наборов данных GitTables [1], огромная коллекция CSV файлов собранных с Github методом поиска о котором я ранее писал совсем недавно [2] и преобразованных в формат Parquet.
Авторы - исследователи из The INtelligent Data Engineering Lab [3] и MIT Media Lab в Университете Амстердама, довольно известная команда учёных работавших над темой семантических типов данных и понимания данных. Они разрабатывали такие инструменты как Sherlock, Sato, AdaTyper и тд по идентификации типов данных. Инструменты скорее академические чем практические, но небесполезные.
GitTables - это интересная идея по сбору данных, с оговоркой что авторы продекларировали сбор и аннотирование данных с массой допущений, ключевое из которых в том что CSV файлы обычно содержат заголовки в первой строке и в том что данные в Github'е хорошо диверсифицированы.
К сожалению, из-за двух этих предположений, этот набор данных скорее годится для проверки алгоритмов контроля качества данных, а не исследований иным способам анализа данных.
Даже краткий анализ показывает что файлы там с разными разделителями, кодировками, многие вообще не CSV, а многие проистекают из всего лишь нескольких репозиториев создавая значительное искажение.
Зато для проверки инструментов на способность импортировать данные из любого источника - этот набор данных очень даже подходит.
Ссылки:
[1] https://gittables.github.io/
[2] https://t.me/begtin/3994
[3] https://indelab.org/
#opendata #datasets
Авторы - исследователи из The INtelligent Data Engineering Lab [3] и MIT Media Lab в Университете Амстердама, довольно известная команда учёных работавших над темой семантических типов данных и понимания данных. Они разрабатывали такие инструменты как Sherlock, Sato, AdaTyper и тд по идентификации типов данных. Инструменты скорее академические чем практические, но небесполезные.
GitTables - это интересная идея по сбору данных, с оговоркой что авторы продекларировали сбор и аннотирование данных с массой допущений, ключевое из которых в том что CSV файлы обычно содержат заголовки в первой строке и в том что данные в Github'е хорошо диверсифицированы.
К сожалению, из-за двух этих предположений, этот набор данных скорее годится для проверки алгоритмов контроля качества данных, а не исследований иным способам анализа данных.
Даже краткий анализ показывает что файлы там с разными разделителями, кодировками, многие вообще не CSV, а многие проистекают из всего лишь нескольких репозиториев создавая значительное искажение.
Зато для проверки инструментов на способность импортировать данные из любого источника - этот набор данных очень даже подходит.
Ссылки:
[1] https://gittables.github.io/
[2] https://t.me/begtin/3994
[3] https://indelab.org/
#opendata #datasets
GitTables
Home
Полезное чтение про данные, для разнообразия свежие статьи про открытость данных
- Ethics of Open Data за авторством N. Weber, Brandon T. Locke [1] о этике открытости данных, в каких случаях открытость может наносить вред (подсказка - нарушение приватности) и как это решается. Полезное, хотя и очень неполный перечень кейсов рассмотрен.
- How open is open? A study of two Irish open government data websites [2] обзор двух ирландских сайтов с открытыми данными за авторством 3-х исследователей из Саудовской Аравии (!) опубликованное в журнале Вопросы государственного и муниципального управления НИУ ВШЭ. Очень необычная комбинация. Статья скорее любопытная, чем интересная.
- The role of open data in transforming the society to Society 5.0: a resource or a tool for SDG-compliant Smart Living? [3] о том как с помощью открытых данных достигать общества 5.0 и SDG. Фактически это про доступность данных о качестве жизни
- Open Data: A Stepchild in e-Estonia’s Data Management Strategy? [4] по факту критика Эстонской госполитики по открытию данных под видом предложений по её улучшению.
- A Review of Open Research Data Policies and Practices in China [5] обзор политики открытости научных данных в Китае, много примеров, ссылок на порталы и публикации. Если кратко - то открытость исследований активно в Китае развивается, проектов много и они весьма велики. Например, Science DB [6] - это более 5 миллионов открытых наборов данных.
Ссылки:
[1] https://arxiv.org/pdf/2205.10402.pdf
[2] https://vgmu.hse.ru/en/2022--5/606167949.html
[3] https://arxiv.org/pdf/2206.11784.pdf
[4] https://www.sciendo.com/article/10.2478/bjes-2022-0006
[5] https://pdfs.semanticscholar.org/935c/1f6d25b282e53474b1ac55579a135a6ea95f.pdf
[6] https://www.scidb.cn/en
#opendata #data #readings
- Ethics of Open Data за авторством N. Weber, Brandon T. Locke [1] о этике открытости данных, в каких случаях открытость может наносить вред (подсказка - нарушение приватности) и как это решается. Полезное, хотя и очень неполный перечень кейсов рассмотрен.
- How open is open? A study of two Irish open government data websites [2] обзор двух ирландских сайтов с открытыми данными за авторством 3-х исследователей из Саудовской Аравии (!) опубликованное в журнале Вопросы государственного и муниципального управления НИУ ВШЭ. Очень необычная комбинация. Статья скорее любопытная, чем интересная.
- The role of open data in transforming the society to Society 5.0: a resource or a tool for SDG-compliant Smart Living? [3] о том как с помощью открытых данных достигать общества 5.0 и SDG. Фактически это про доступность данных о качестве жизни
- Open Data: A Stepchild in e-Estonia’s Data Management Strategy? [4] по факту критика Эстонской госполитики по открытию данных под видом предложений по её улучшению.
- A Review of Open Research Data Policies and Practices in China [5] обзор политики открытости научных данных в Китае, много примеров, ссылок на порталы и публикации. Если кратко - то открытость исследований активно в Китае развивается, проектов много и они весьма велики. Например, Science DB [6] - это более 5 миллионов открытых наборов данных.
Ссылки:
[1] https://arxiv.org/pdf/2205.10402.pdf
[2] https://vgmu.hse.ru/en/2022--5/606167949.html
[3] https://arxiv.org/pdf/2206.11784.pdf
[4] https://www.sciendo.com/article/10.2478/bjes-2022-0006
[5] https://pdfs.semanticscholar.org/935c/1f6d25b282e53474b1ac55579a135a6ea95f.pdf
[6] https://www.scidb.cn/en
#opendata #data #readings
Sciendo
Open Data: A Stepchild in e-Estonia’s Data Management Strategy?
Abstract
The availability of open data has increased dramatically, partly in reaction to several types of government agencies publishing their raw data. Access to and use of open data is not only essential for the development of public policy and delivery…
The availability of open data has increased dramatically, partly in reaction to several types of government agencies publishing their raw data. Access to and use of open data is not only essential for the development of public policy and delivery…
State of data engineering 2022 [1] обзор инженерии данных в 2022 г. от LakeFS. На мой взгляд составители так сильно поленились, в отличие от других отчетов в стиле state of они просто написали текст с описанием текущих продуктов. При этом, не сравнили с прошлым годом, не использовали опрос пользователей/клиентов, не обосновали почему сделали акцент на этих, а не на других технологиях.
Картинка симпатичная, текст по полезности далек от совершенства. Особенно если сравнить с другими технологическими масштабными исследованиями от Postman и Jetbrains.
Тем не менее что-то полезное и здесь можно найти.
Ссылки:
[1] https://lakefs.io/the-state-of-data-engineering-2022/
#dataengineering
Картинка симпатичная, текст по полезности далек от совершенства. Особенно если сравнить с другими технологическими масштабными исследованиями от Postman и Jetbrains.
Тем не менее что-то полезное и здесь можно найти.
Ссылки:
[1] https://lakefs.io/the-state-of-data-engineering-2022/
#dataengineering
Большой тренд который нельзя уже давно игнорировать - это миграция новаций в базах данных в облако. В лучшем случае, при этом, есть опенсорсная версия того же продукта который можно развернуть локально, в худшем случае инновации делаются сразу в облаке и только в облаке.
Например, DataStax, стартап с продуктом Astra DB на базе Apache Cassandra [1]. Для тех кто не помнит, Apache Cassandra - это такая NoSQL база данных с хорошей масштабируемостью. Не такая удобная, ИМХО, из коробки как MongoDB, но гораздо лучше масштабируется горизонтально.
Особенность Apache Cassandra в языке CQL, очень похожем на SQL. Он, с одной стороны, довольно привычен, но с другой не так удобен для работы со схематичными объектами. И вот DataStax в Astra DB [2] добавили почти MongoDB совместимое Document API. Это возможность работы с режиме CRUD.
В общем удобная и полезная возможность. Но, существующая только в облачном виде. Даже Enterprise версия тоже облачная. Этого, в последнее время всё больше, появление cloud-only продуктов. С одной стороны они дают возможность крайне высокой скорости развертывания и управляемости инфраструктуры, а с другой, зависимость от облачных сервисов становится огромной. Впрочем это не только про этот продукт, а про многочисленные другие также.
Ссылки:
[1] https://www.datastax.com/products/datastax-astra
[2] https://docs.datastax.com/en/astra/docs/develop/dev-with-doc.html
#data #startups
Например, DataStax, стартап с продуктом Astra DB на базе Apache Cassandra [1]. Для тех кто не помнит, Apache Cassandra - это такая NoSQL база данных с хорошей масштабируемостью. Не такая удобная, ИМХО, из коробки как MongoDB, но гораздо лучше масштабируется горизонтально.
Особенность Apache Cassandra в языке CQL, очень похожем на SQL. Он, с одной стороны, довольно привычен, но с другой не так удобен для работы со схематичными объектами. И вот DataStax в Astra DB [2] добавили почти MongoDB совместимое Document API. Это возможность работы с режиме CRUD.
В общем удобная и полезная возможность. Но, существующая только в облачном виде. Даже Enterprise версия тоже облачная. Этого, в последнее время всё больше, появление cloud-only продуктов. С одной стороны они дают возможность крайне высокой скорости развертывания и управляемости инфраструктуры, а с другой, зависимость от облачных сервисов становится огромной. Впрочем это не только про этот продукт, а про многочисленные другие также.
Ссылки:
[1] https://www.datastax.com/products/datastax-astra
[2] https://docs.datastax.com/en/astra/docs/develop/dev-with-doc.html
#data #startups
DataStax
Astra DB for Generative AI App Creation & Development | DataStax
Reduce app development time and start scaling without limits. Use Astra DB to create real-time GenAI apps. Start using Astra DB for vector search today!
Я люблю коллекционировать разные термины и сочетания касающиеся данных, благо комбинации выдумывают самые разнообразные, у меня даже словарик есть примерно на 200 терминов включая такие экзотические как data pollution, data liquidity и data laborers. Давно не встречал новых терминов и вот пополнение.
data stations - станции данных. Термин придуманный в DANS, голландским исследовательским центром работающим над инфраструктурой раскрытия научных данных.
Термин - это по сути аналог dataverse (data universe), тематическая коллекция и правила сбора данных используемое в одноименном продукте сделанном командой Гарварда.
Возвращаясь к DANS, например, такая станция данных по археологии [1] у них сейчас оформлена одной из первых.
В моём понимании - это, скорее грантоориентированное дробление, так чтобы по отдельности брать гранты на развитие каждой станции по отдельности.
Ссылки:
[1] https://dans.knaw.nl/en/data-stations/archaeology/
#opendata #openresearchdata #openaccess #data
data stations - станции данных. Термин придуманный в DANS, голландским исследовательским центром работающим над инфраструктурой раскрытия научных данных.
Термин - это по сути аналог dataverse (data universe), тематическая коллекция и правила сбора данных используемое в одноименном продукте сделанном командой Гарварда.
Возвращаясь к DANS, например, такая станция данных по археологии [1] у них сейчас оформлена одной из первых.
В моём понимании - это, скорее грантоориентированное дробление, так чтобы по отдельности брать гранты на развитие каждой станции по отдельности.
Ссылки:
[1] https://dans.knaw.nl/en/data-stations/archaeology/
#opendata #openresearchdata #openaccess #data