Я давно не писал про мою любимую тему, семантические типы данных, а, между тем, я активно продолжаю ей заниматься в свободное время, в основном. Создавая 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
Для тех кто не знает что это такое, напомню про мой текст с рассказом того как их применяют и зачем они нужны [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
GitHub
GitHub - apicrafter/metacrafter-registry: Registry of metadata identifier entities like UUID, GUID, person fullname, address and…
Registry of metadata identifier entities like UUID, GUID, person fullname, address and so on. Linked with other sources - apicrafter/metacrafter-registry
Онтология типов данных
Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология 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
Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология 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
Docs
Common Data Model - Common Data Model
Common Data Model is a standardized, modular, and extensible collection of data schemas that Microsoft published to help you build, use, and analyze data.
Я довольно давно не рассказывал про развитие инструментов metacrafter для выявления семантических типов данных и реестра семантических типов данных metacrafter-registry которыми давно занимаюсь.
Изменений там много, в основном в части постепенно улучшения списка типов данных, связанности с базами Schema.org и Wikidata. А есть одно изменение важное именно для инженерии данных - это экспорт реестра в формат бизнес глоссария (Business Glossary) используемого в каталоге данных Datahub.
Для тех кто не знает, бизнес глоссарий, это смысловые характеристики полей данных записываемые в каталогах данных. Не обязательно семантический/смысловой тип поля, но может быть, например, уровень его конфиденциальности, чувствительности данных и так далее.
Datahub - это опенсорсный каталог корпоративных данных [1] созданный некогда в LinkedIn и развиваемый сейчас компанией Acryl. Среди его достоинств есть импорт данных, в том числе, для бизнес глоссария.
И вот для тех кто хочет загрузить туда типы данных из Metacrafter'а теперь это можно сделать воспользовавшись файлом metacrafter.yml [2] из репозитория проекта. Выглядит результат примерно как на вот этом скриншоте.
Следующий шаг в интеграции metacrafter'а в непосредственно процесс загрузки метаданных в Datahub, так чтобы привязку поля к данным можно было бы осуществлять автоматически.
Ссылки:
[1] https://datahubproject.io
[2] https://github.com/apicrafter/metacrafter-registry/tree/main/data/datahub
#opensource #semanticdatatypes #dataengineering #apicrafter #metacrafter
Изменений там много, в основном в части постепенно улучшения списка типов данных, связанности с базами Schema.org и Wikidata. А есть одно изменение важное именно для инженерии данных - это экспорт реестра в формат бизнес глоссария (Business Glossary) используемого в каталоге данных Datahub.
Для тех кто не знает, бизнес глоссарий, это смысловые характеристики полей данных записываемые в каталогах данных. Не обязательно семантический/смысловой тип поля, но может быть, например, уровень его конфиденциальности, чувствительности данных и так далее.
Datahub - это опенсорсный каталог корпоративных данных [1] созданный некогда в LinkedIn и развиваемый сейчас компанией Acryl. Среди его достоинств есть импорт данных, в том числе, для бизнес глоссария.
И вот для тех кто хочет загрузить туда типы данных из Metacrafter'а теперь это можно сделать воспользовавшись файлом metacrafter.yml [2] из репозитория проекта. Выглядит результат примерно как на вот этом скриншоте.
Следующий шаг в интеграции metacrafter'а в непосредственно процесс загрузки метаданных в Datahub, так чтобы привязку поля к данным можно было бы осуществлять автоматически.
Ссылки:
[1] https://datahubproject.io
[2] https://github.com/apicrafter/metacrafter-registry/tree/main/data/datahub
#opensource #semanticdatatypes #dataengineering #apicrafter #metacrafter
Для тех кто интересуется моими регулярными постами про семантические типы данных, я выложил в открытый доступ расширенный набор правил metacrafter-rules [1] для утилиты metacrafter [2].
В расширенном наборе правил присутствуют:
- правила для идентификации интернет кодов, частых идентификаторов и дат
- множество правил для данных специфичных для России/русского языка по идентификации геолокаций, адресов, справочных кодов, разного рода госидентификаторов и так далее.
Всего правил, включая эти, расширенные, 245 из которых 143 идентифицируют по наименованию поля, а 105 по значениям в этом поле/колонке. Ещё 312 правил есть для идентификации дат во всех популярных видах и языках их написания.
Напомню что metacrafter из коробки поддерживает NoSQL и с его помощью можно идентифицировать семантические типы данных в MongoDB, а также файлах JSON, XML, JSONL, BSON. При этом табличные файлы и SQL базы данных также поддерживаются.
Ссылки:
[1] https://github.com/apicrafter/metacrafter-rules
[2] https://github.com/apicrafter/metacrafter
#opensource #datatools #data #semanticdatatypes #understandingdata
В расширенном наборе правил присутствуют:
- правила для идентификации интернет кодов, частых идентификаторов и дат
- множество правил для данных специфичных для России/русского языка по идентификации геолокаций, адресов, справочных кодов, разного рода госидентификаторов и так далее.
Всего правил, включая эти, расширенные, 245 из которых 143 идентифицируют по наименованию поля, а 105 по значениям в этом поле/колонке. Ещё 312 правил есть для идентификации дат во всех популярных видах и языках их написания.
Напомню что metacrafter из коробки поддерживает NoSQL и с его помощью можно идентифицировать семантические типы данных в MongoDB, а также файлах JSON, XML, JSONL, BSON. При этом табличные файлы и SQL базы данных также поддерживаются.
Ссылки:
[1] https://github.com/apicrafter/metacrafter-rules
[2] https://github.com/apicrafter/metacrafter
#opensource #datatools #data #semanticdatatypes #understandingdata
GitHub
GitHub - apicrafter/metacrafter-rules: Rules for metacrafter metadata identification and classfication tool
Rules for metacrafter metadata identification and classfication tool - GitHub - apicrafter/metacrafter-rules: Rules for metacrafter metadata identification and classfication tool
В блоге UBER история о том как они реализовали движок по автоматической категоризации данных DataK9 [1]. Выглядит интересно и очень похоже на то что я делал в опенсорсном продукте Metacrafter [2].
Если пересказать вкратце, то они взяли чуть более 400 тысяч датасетов для анализа, а до этого 1 тысячу датасетов для обучения и ручной разметки людьми и далее натравили созданные людьми правила на оставшиеся датасеты. Правила готовились людьми вручную, но пишут что и ИИ применяли где-то, до конца непонятно где.
Описания правил у них в YAML что тоже очень похоже на Metacrafter
В чём сходства и отличия:
1. В их правилах есть bloom filters и value range, что является хорошей идеей, надо к ней присмотреться.
2. Кроме include patterns они используют ещё и exclude patterns что тоже весьма логично и разумно.
3. Cмешивают типы данных и правила, фактически правила детекции привязывают к типу прямо в YAML файле. В Metacrafter'е это иначе. Типы данных и правила разделены.
4. Не имеют языковых особенностей при идентификации, всё про английский язык.
5. Не используют семантические типы данных. В Metacrafter они вынесены в отдельный реестр [3]
Ключевое, конечно, в среде эксплуатации. DataK9 работает в корп среде с внутренними данными заточенными под AI/ML, а Metacrafter писался под работу с общедоступными данными на разных языках.
Ссылки:
[1] https://www.uber.com/en-DE/blog/auto-categorizing-data-through-ai-ml
[2] https://github.com/apicrafter/metacrafter
[3] https://github.com/apicrafter/metacrafter-registry
#opensource #data #datatools #semanticdatatypes
Если пересказать вкратце, то они взяли чуть более 400 тысяч датасетов для анализа, а до этого 1 тысячу датасетов для обучения и ручной разметки людьми и далее натравили созданные людьми правила на оставшиеся датасеты. Правила готовились людьми вручную, но пишут что и ИИ применяли где-то, до конца непонятно где.
Описания правил у них в YAML что тоже очень похоже на Metacrafter
В чём сходства и отличия:
1. В их правилах есть bloom filters и value range, что является хорошей идеей, надо к ней присмотреться.
2. Кроме include patterns они используют ещё и exclude patterns что тоже весьма логично и разумно.
3. Cмешивают типы данных и правила, фактически правила детекции привязывают к типу прямо в YAML файле. В Metacrafter'е это иначе. Типы данных и правила разделены.
4. Не имеют языковых особенностей при идентификации, всё про английский язык.
5. Не используют семантические типы данных. В Metacrafter они вынесены в отдельный реестр [3]
Ключевое, конечно, в среде эксплуатации. DataK9 работает в корп среде с внутренними данными заточенными под AI/ML, а Metacrafter писался под работу с общедоступными данными на разных языках.
Ссылки:
[1] https://www.uber.com/en-DE/blog/auto-categorizing-data-through-ai-ml
[2] https://github.com/apicrafter/metacrafter
[3] https://github.com/apicrafter/metacrafter-registry
#opensource #data #datatools #semanticdatatypes
В продолжение про категоризацию данных я расскажу о том какое моё видение по развитию Metacrafter'а [1]. Напомню что это опенсорс утилита по идентификации семантических типов данных, категоризации и автодокументирования данных.
1. Это расширение числа семантических (смысловых) типов данных и правил их идентификации. Сейчас есть сотни типов и сотни правил, но далеко не для всех типов данных правила есть и добавлять там много что есть. В особенности когда это касается отраслей: медицина, биохимия, финансовые структуры, нефтянка, и много что другое. Специфики отраслевой немало, правила для них готовятся совсем не быстро.
2. Расширение видов правил идентфикации смысловых типов данных. В первую очередь определение уникальных полей, общих префиксов и других особенностей.
3. Возможно обновление языка управления правилами и добавление и переписать правила для добавления bloom filter, пространств значений для цифр и исключающих фильтров.
4. Перестройка работы metacrafter'а на работу с сервером по умолчанию. Сейчас для работы утилиты командной строки правила каждый раз загружаются и компилируются из файлов с правилами. А это небыстро, дольше чем сама работа категоризатора. Альтернатива в виде prefech и запуска локального сервера и работы через него.
5. Введение режима идентификации неизвестных типов данных. Это когда Metacrafter'у скармливаются датасеты для обучения и по определенным правилам он рекомендует разметить конкретные поля и конкретные типы данных. Это самая сложная и исследовательская задача. Вот её по настоящему интересно решить.
Ну и как не добавить что сейчас создаётся архив датасетов проиндексированных Dateno и по ним как раз идёт тестирование Metacrafter'а и будущая доработка.
Ссылки:
[1] https://github.com/apicrafter/metacrafter
#opensource #data #datatools #semanticdatatypes
1. Это расширение числа семантических (смысловых) типов данных и правил их идентификации. Сейчас есть сотни типов и сотни правил, но далеко не для всех типов данных правила есть и добавлять там много что есть. В особенности когда это касается отраслей: медицина, биохимия, финансовые структуры, нефтянка, и много что другое. Специфики отраслевой немало, правила для них готовятся совсем не быстро.
2. Расширение видов правил идентфикации смысловых типов данных. В первую очередь определение уникальных полей, общих префиксов и других особенностей.
3. Возможно обновление языка управления правилами и добавление и переписать правила для добавления bloom filter, пространств значений для цифр и исключающих фильтров.
4. Перестройка работы metacrafter'а на работу с сервером по умолчанию. Сейчас для работы утилиты командной строки правила каждый раз загружаются и компилируются из файлов с правилами. А это небыстро, дольше чем сама работа категоризатора. Альтернатива в виде prefech и запуска локального сервера и работы через него.
5. Введение режима идентификации неизвестных типов данных. Это когда Metacrafter'у скармливаются датасеты для обучения и по определенным правилам он рекомендует разметить конкретные поля и конкретные типы данных. Это самая сложная и исследовательская задача. Вот её по настоящему интересно решить.
Ну и как не добавить что сейчас создаётся архив датасетов проиндексированных Dateno и по ним как раз идёт тестирование Metacrafter'а и будущая доработка.
Ссылки:
[1] https://github.com/apicrafter/metacrafter
#opensource #data #datatools #semanticdatatypes