Онтология типов данных
Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология 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
Написал большой лонгрид Хорошие и плохие практики публикации данных. Метаданные и форматы файлов про метаданные и то в каких форматах данных их публикуют.
#opendata #metadata #data #datacatalogs
#opendata #metadata #data #datacatalogs
Ivan’s Begtin Newsletter on digital, open and preserved government
Хорошие и плохие практики публикации данных. Метаданные и форматы файлов
«Буду делать хорошо, и не буду — плохо». (Маяковский)