Свежий апдейт по проекту metacrafter.

Обновился реестр семантических типов данных metacrafter-registry [1], теперь там появился раздел инструментов [2] со списком, пока, из 9 инструментов и того какие семантические типы данных они поддерживают.

Список неполный потому что есть инструменты вроде Microsoft Presidio [3] которые по факту поддерживают ещё и многие типы данных которые пока в этот реестр не входят, но их систематизация хотя бы начата. Каждый инструмент описывается в виде yaml файла с описанием, например, yaml файл metacrafter'а.

Сейчас metacrafter с базовыми правилами распознает 48 семантических типов данных [4], а как веб сервис поддерживает 118 семантических типов [5].

На самом деле, конечно, если говорить про ширину охвата, то можно упростить распознавание сведя все численные типы к одному семантическому типу. Например, так сделано в Google Data Studio, а можно наоборот усложинить добавив множество градаций и подтипов. Как это сделано в Metabase где есть отдельные типы данных "Creation Date", "Updated Date" и тд.


Ссылки:
[1] https://registry.apicrafter.io/
[2] https://registry.apicrafter.io/tool
[3] https://registry.apicrafter.io/tool/presidio
[4] https://github.com/apicrafter/metacrafter-registry/blob/main/data/tools/detectors/metacrafter.yaml
[5] https://github.com/apicrafter/metacrafter-registry/tree/main/data/tools
[4] https://registry.apicrafter.io/tool/metacrafter
[5] https://registry.apicrafter.io/tool/metacrafterpro

#opensource #datatools #apicrafter #metadata #pii

Написал сегодня очередной текст в рассылку, на сей раз чуть подробнее рассказал о том как применяется и для чего делается утилита metacrafter [1] выявляющая семантические типы данных.

Если кратко, то это:
- выявление персональных данных
- улучшение data discovery
- автоматическое документирование

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

Ссылки:
[1] https://begtin.substack.com/p/28

#metadata #metacrafter #datatools #data #opensource

Полезные материалы по управлению метаданными и каталогами данных

Open source продукты
- Amundsen [1] создан внутри Lyft
- OpenMetadata [2] пытаются создавать стандарт
- Datahub [3] создан в LinkedIn, передан в Acryl Data
- Metacat [4] создан в Netflix
- Apache Atlas [5] передан в Apache Foundation
- Marquez [6] передан в Linux Foundation
- Whale [7] не обновлялся около года

Обзоры
- Top 7 Data Catalog Tools in 2022 [8] обзор от Hevo Data облачных, открытых и корпоративных каталогов

Видео и выступления на русском языке
- Data-docs — как найти данные о данных — Олег Харатов, Авито [9]
- Как мы строим Metadata Managemen — Юлия Кошелева и Энрика Матвейчук, Тинькофф [10]
- Под капотом каталога данных — Анастасия Ожигина, Тинькофф [11]

Видео на английском языке
- Data Catalog for data discovery and metadata management [12] от Google и про Google Data Catalog
- Amundsen: A Data Discovery Platform From Lyft | Lyft [13] видео 2019 года, про раннюю стадию создания Amunsen

Ссылки:
[1] https://www.amundsen.io/
[2] https://open-metadata.org/
[3] https://datahubproject.io/
[4] https://github.com/Netflix/metacat
[5] https://atlas.apache.org
[6] https://marquezproject.ai/
[7] https://github.com/hyperqueryhq/whale
[8] https://hevodata.com/learn/data-catalog-tools/
[9] https://www.youtube.com/watch?v=Cr1DDmhoLKI
[10] https://www.youtube.com/watch?v=3xuNp5L_ikU
[11] https://www.youtube.com/watch?v=puH3uBNoDXk
[12] https://www.youtube.com/watch?v=eUKqXZDXj78
[13] https://www.youtube.com/watch?v=EOCYw0yf63k

#datacatalogs #data #metadata #datatools

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

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

Так вот, здесь про пользу государственных порталов открытых данных вроде российского data.gov.ru, британского data.gov.uk и др. Польза эта в многообразии. Например, по data.gov.ru я обучаю распознавалку семантических типов данных.

Для тех кто интересуется как это работает, в репозитории metacrafter-datacatalogs-raw собраны метаданные с разных порталов и опубликован результат распознавания семантических типов данных по data.gov.ru. Желающие могут скачать нефильтрованный результат распознаваний в файле datagovru_semantictypes.jsonl.xz

В цифрах:
- 18+ тысяч обработанных наборов данных
- 198 660 полей полей структурированных файлах
- 66 921 полей у которых автоматически определен семантический тип (примерно 34%)
- наиболее успешно идентифицируются: уникальные идентификаторы, булевые значения, наименования, ФИО, дата и время, номер телефона, url, год и тд
- самые частые ошибки в полях когда название поля используется как булевое значение, а не как содержащие сущность. Например, если поле называется "passport", а не "hasPassport" и по факту является словарем в значениях "имеется" и "отсутствует"
- распознавание можно улучшить зная контекст, источник данных, дополнительные метаданные и тд., но это какое-то дополнительное направление исследований, скорее научное чем практическое.

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

Но даже для такой задачи есть ключевая проблема - это качество данных. Я не просто так пишу про то что госданные, в целом, это мусор.
Вот лишь несколько характеристик именно низкого качества данных:
- CSV файлы публикуются в разных кодировках и с разными разделителями (это, отчасти, преодолимо)
- CSV файлы очень часто публикуются без заголовков, например, многие данные из ХМАО (это реальная проблема)
- многие расширения файлов не соответствуют содержанию. CSV или ZIP вместо XML, HTML вместо CSV и так далее
- многие ссылки на файлы на других сайтах давно протухли, например, ссылки на сайт fstrf.ru давно ведут на какой-то левый сайт.
- вместо настоящих XML файлов с данными публикуются файлы разметки. Я об этом писал ранее, это вообще напоминает какой-то подлог
- многие CSV файлы это кривой экспорт из Excel с многострочтными заголовками и строками ИТОГО нарушающими разбор файла
- огромное число файлов просто пустые

Делать полную оценку причин и проблем с качеством открытых гос данных долго, я пишу о том насколько они влияют на возможность их автоматизированного анализа. Собственно по причинам выше и из 26+ тысяч наборов данных удалось обработать около 18+ тысяч и среди обработанных есть ошибки связанные с неверными заголовками у CSV файлов.

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

Но всё постепенно меняется и я про качество данных расскажу ещё не раз.

#opendata #datasets #metadata #metacrafter #apicrafter

Я давно не писал про мою любимую тему, семантические типы данных, а, между тем, я активно продолжаю ей заниматься в свободное время, в основном. Создавая metacrafter-registry [1] [2], реестр существующих семантических типов данных и регулярных выражений для их идентификации.

Для тех кто не знает что это такое, напомню про мой текст с рассказом того как их применяют и зачем они нужны [3], если кратко то для автоматизации визуализации, анализа, навигации и обработки данных.

Реестр вырос уже до 284 типов данных сгруппированных по 26 категориям и в привязке к 11 странам. Более всего страновых идентификаторов по России - более 70 (ИНН, СНИЛС, КЛАДР и все остальные), но по мере обработки порталов данных и других источников растет список и по другим странам.

Самые главные изменения в том что многие типы данных теперь имеют привязку к Wikidata и Schema.org. Какие-то ещё можно привязать, но, к сожалению не все. Wikidata почти не покрывает персональные идентификаторы, зато включает сотни идентификаторов литературных источников почти нигде "в диком виде" не встречающиеся.

Реестр всё лучше перелинкован, синхронизован с используемыми инструментами и понемногу включает и регулярные выражения для идентификации типов данных. Часть их уже перенесена в утилиту metacrafter [4] для идентификации семантических типов данных, а часть будет перенесена постепенно позже.

Ссылки:
[1] https://registry.apicrafter.io/
[2] https://github.com/apicrafter/metacrafter-registry
[3] https://medium.com/@ibegtin/semantic-data-types-systematic-approach-and-types-registry-a2c2a60a467b
[4] https://github.com/apicrafter/metacrafter

#opensource #data #datatools #metadata #semanticdatatypes

Онтология типов данных

Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология OntoDT [1] ещё 2016 года, но сайт с ним уже недоступен, и сама онтология кое-где ещё доступна как RDF/OWL [2]. Основной автор Panče Panov явно переключился на более прикладные исследования [3]

В качестве других примеров։
- онтология EDAM [4] в биоинформатике, с акцентом на особенности анализа и майнинга данных в этой области
- CDM (Common Data Model) [5] не-формальная онтологии от Microsoft привязанная с акцентом на продажах, пользователях, маркетинге и тд.
- онтология типов данных при ответах на вопросы по геоаналитике [6] прошлогоднее исследование с акцентом на геоданные.

Есть, также, какое-то количество других научных и не только научных публикаций на эту тему, но в целом их довольно мало. Они чаще всего происходят в контексте задач по анализу данных и его автоматизации. Самое развитое идёт в сторону автоматизации создания и аннотирование моделей для ИИ. Проект D3M (Data-Driven Discovery of Models) [7] от DARPA в США. Я не так давно писал о нём и порождённых им стартапах. [8]

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

Ещё какое-то время назад в СУБД на родном уровне поддерживались только самые базовые типы данных։ INT, FLOAT, STRING/VARCHAR, BLOB и тд. с небольшими вариациями. Сейчас, современные СУБД, поддерживают многочисленные дополнительные типы данных, перешедших из смысловых (семантических) в базовые типы. Пример: ip-адреса и mac-адреса уже достаточно давно имеющиеся в некоторых СУБД [9] и недавно добавляемые в другие [10].

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

Мои ощущения что на этом процесс не остановится. Например, меня удивляет что всё ещё нет СУБД общего типа с отдельными типами данных под хэши (SHA1, SHA256 и др.).

Многие составные идентификаторы и коды классификаторов сейчас в СУБД хранятся как строки, при том что часто они нужны в декомпозированной форме и, в итоге, создаётся избыточность разбирая этот код на части. Пример в России: Вы можете хранить код КЛАДР как есть, а можете разделить его на подэлементы и осуществлять поиск по ним когда это необходимо.

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

Ссылки:
[1] https://fairsharing.org/FAIRsharing.ydnwd9
[2] https://kt.ijs.si/panovp/OntoDM/archive/OntoDT.owl
[3] https://orcid.org/0000-0002-7685-9140
[4] https://edamontology.org/page
[5] https://docs.microsoft.com/en-us/common-data-model/
[6] https://digitalcommons.library.umaine.edu/josis/vol2020/iss20/2/
[7] https://datadrivendiscovery.org
[8] https://t.iss.one/begtin/3926
[9] https://www.postgresql.org/docs/current/datatype-net-types.html
[10] https://mariadb.com/kb/en/inet4/

#data #rdbms #research #metadata #semanticdatatypes

Вышла версия 1.0 корпоративного каталога данных Open Metadata [1] с открытым кодом. Продукт интересный, даёт уйму интересных возможностей для тех кто делает свои корпоративные каталоги данных и систематизирует внутренние ресурсы в виде данных. Я давно к нему присматриваюсь и, хотя пока ещё не смотрел версию 1.0, обязательно посмотрю. В том числе они заявляют автоматическое выявлении персональных данных (Auto PII Classification), а я продолжаю заниматься небольшим продуктом по идентификации семантических типов данных и персональные данные туда тоже входят.

Но даже до того как я посмотрю версию 1.0 я могу сказать то чего в Open Metadata точно до сих пор нет - это поддержка NoSQL во всех формах. Нет поддержки, ни Redis, ни MongoDB, ни ArangoDB, ни JSON объектов внутри NewSQL баз данных. А это значит что если у вас только SQL архитектура и инфраструктура, то это инструмент, возможно, подходящий. А если, например, кроме SQL у вас ещё и базы MongoDB для хранения, Elastic для поискового индекса, Redis для сессий пользователей и ещё что-нибудь экзотическое и какое-нибудь legacy, то нужно искать другие инструменты.

Конечно, команда Open Metadata действует как стартап и делают хорошо какую-то узкую область, но одновременно они заложили архитектурное ограничение восприятия каталогизируемых объектов как таблиц. Преодолеть им его теперь очень сложно, нужно будет переписать много кода и поломать совместимость с уже написанными расширениями.


Ссылки:
[1] https://blog.open-metadata.org/openmetadata-1-0-release-beb34762d916

#opensource #datacatalogs #metadata

В качестве регулярного напоминания, если Вы ищите данные по России и постсоветским странам, то в каталоге каталогов данных DataCatalogs.ru [1] они как раз собраны.

В проекте сейчас 322 каталога данных, из которых 294 по России, ещё 28 по Казахстану, Кыргызстану, Узбекистану, Армении и тд.

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

Этот проект был одним из источников для создаваемого сейчас Common Data Index [2] реестра каталогов данных по всему миру, где их уже более 2000+ тысяч и о котором я, также, регулярно пишу.

Ссылки:
[1] https://www.datacatalogs.ru/
[2] https://github.com/commondataio/dataportals-registry

#opendata #datacatalogs #dataportals #metadata

Теперь уже 7055 каталогов данных в реестре каталогов данных registry.commondata.io из которых как минимум 5393 потенциально индексируемых в поиск. Много это или мало? Много. В dataportals.org всего 598 порталов, в Datashades.info 530 инсталляций CKAN, в re3data.org 3125 порталов научных данных.

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

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

Вот чего не хватает так это простой системы метрик которую можно было бы пристыковать к базе данных в виде СУБД или в виде CSV/NDJSON файла.

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

#opendata #datatools #metadata #datacatalogs #commondataindex

Написал большой лонгрид Хорошие и плохие практики публикации данных. Метаданные и форматы файлов про метаданные и то в каких форматах данных их публикуют.

#opendata #metadata #data #datacatalogs