Я давно не писал про мою любимую тему, семантические типы данных, а, между тем, я активно продолжаю ей заниматься в свободное время, в основном. Создавая 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.
This media is not supported in your browser
VIEW IN TELEGRAM
Вышла версия 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
Но даже до того как я посмотрю версию 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
В проекте сейчас 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
Самое сложное - это собирать описания всех записей, а для этого нужны метрики качества. Для любого дата проекта нужны метрики качества и автоматизация их улучшения.
Вот в данном случае это референсная база данных, не транзакционная, а справочная для любых других проектов по систематизации данных. Полнота метаданных имеет значение и поэтому метрики именно про эту полноту: есть ли какое-то поле, ненулевое ли оно и так далее.
Вот чего не хватает так это простой системы метрик которую можно было бы пристыковать к базе данных в виде СУБД или в виде CSV/NDJSON файла.
Существующие движки оценки и мониторинга качества данных не подходят. Какие существуют альтернативы кроме как изобретать свой велосипед?
#opendata #datatools #metadata #datacatalogs #commondataindex