Ivan Begtin
7.98K subscribers
1.8K photos
3 videos
101 files
4.51K links
I write about Open Data, Data Engineering, Government, Privacy, Digital Preservation and other gov related and tech stuff.

Founder of Dateno https://dateno.io

Telegram @ibegtin
Facebook - https://facebook.com/ibegtin
Secure contacts ivan@begtin.tech
Download Telegram
Как я писал ранее, одно из направлений развития в инженерии данных и DataOps - это упаковка и доставка данных в виде контейнеров [1]. Наиболее активно развивающейся спецификацией для открытых данных является Frictionless Data [2], однако история про контейнеры с данными имеет куда более глубокие корни и направление "упаковки данных" давно существуют в научной среде.

ResearchObject [3] - это проект и набор спецификаций по описанию и упаковке данных в научной среде с ориентацией на воспроизведение результатов исследований. Наиболее актуальная спецификация RO-Crate [4] использует описание метаданных в формате связанных данных для описания как происхождения данных так и описания каждого включённого файла.

Одна из областей в которой давно уже активно идёт и используется стандартизация - это биоинформатика. Набор стандартов COMBINE (COmputational Modeling in BIology NEtwork) [5] включает как их моделирование, так и контейнеры для обмена данными и их преобразование, например, в контейнеры ResearchObject.

К другим спецификациям можно отнести Big data bag [6] объединяющие ResearchObject и спецификацию архивации данных BagIt [7].

У этой же инициативы есть ещё одно отражение, репозитории кода являются также результатами исследований и Mozilla Science Lab запустили инициативу Code as Research Object [8]

Другой заметный стандарт - это ReproZip [9], стандарт контейнер по упаковке данных и спецификации по воспроизведению исследований. Разрабатывается в инженерном подразделении New York University и основная его цель в том чтобы избежать замыкания в экосистеме одного вендора (да, в науке это повсеместно).

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

Ссылки:
[1] https://t.me/begtin/1925
[2] https://frictionlessdata.io
[3] http://www.researchobject.org/
[4] https://researchobject.github.io/ro-crate/1.0/
[5] http://co.mbine.org/
[6] https://github.com/fair-research/bdbag
[7] https://datatracker.ietf.org/doc/rfc8493/
[8] https://mozillascience.github.io/code-research-object/
[9] https://www.reprozip.org/

#opendata #data #standards
Government Digital Service в Великобритании опубликовали серию стандартов по работе с государственными данными и API [1] и отдельно открытые стандарты по описанию метаданных для наборов данных и табличных файлов и описания самих табличных файлов [2]. Большая часть рекомендаций касается использования стандарта Dublin Core для ведения метаданных, стандарта OpenAPI для проектирования и документирования API.

Все они связаны с появлением Open Standards Board [3] состоящем из знаковых лиц с большим опытом работы с данными,в том числе за пределами Великобритании [4], можно сказать что это реформа в области стандартизации работы с данными в госсекторе. Кроме того есть ряд рассматриваемых сейчас стандартов обмена информацией [5]. Можно обратить внимание что при написании стандартов прямо указывается что аудитория их использования - это data scientist'ы и те кто публикуют госданные [6]. А также много интересных идей и обсуждений непосредственно в Github репозитории открытых стандартов [7] включая стандартизацию печати документов, наличия у каждого госдокумента уникального идентификатора и так далее.

Лично я не могу не отметить лаконичность описания каждого стандарта, формата, рекомендации. Это совершенно несопоставимо с чтением всего что касается стандартизации на международном уровне или у нас в стране (да и ещё много где).

Ссылки:
[1] https://www.gov.uk/guidance/gds-api-technical-and-data-standards
[2] https://www.gov.uk/government/publications/recommended-open-standards-for-government
[3] https://www.gov.uk/guidance/choosing-open-standards-for-government
[4] https://www.gov.uk/government/groups/open-standards-board
[5] https://www.gov.uk/government/publications/open-standards-for-government
[6] https://www.gov.uk/government/publications/open-standards-for-government/country-codes
[7] https://github.com/alphagov/open-standards/issues

#data #standards
Я давно планировал написать про проблемы стандартизации работы с данными, она не так заметна в узкосфокусированных областях, но становится более чем актуальной когда много разных, часто малоуправляемых, источников данных публикующих данные о схожих объектах в разных форматах.

Прежде чем продолжить надо дать два определения:

стандарты метаданных - это способы описания хранимых наборов данных и иных цифровых объектов (digital assets). Они используются для того чтобы максимально полно хранить сведения о происхождении данных, первоисточнике, частоте обновления, форматах и иной сопутствующей информации которая необходима при обработке этих данных. Эти стандарты используются при каталогизации данных.

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

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

Подробнее в посте на Substack https://begtin.substack.com/p/11

#data #standards #regulation
Обновилась документация, появился новый портал с документацией [1], по проекту Frictionless Data. Теперь там довольно удобно собраны примеры, описания и руководства по работе с этим фреймворком. Лично я уделяю ему столько внимания потому что на сегодняшний день - это одна из наиболее продуманных инициатив с открытым кодом по стандартизации наборов данных.

Альтернативы ему, или коммерческие, с централизованными реестрами/репозиториями такими как QRI, или узкоспециализированные под академическую работу - RO-CRATE или под архивацию цифровых объектов такие как BagIt.

Но, конечно, есть и множество альтернатив: DataCrate [2], BioCompute [3], стандарты RDA [4], стандарты Force11 [5], CodeMeta [6] и многочисленные стандарты публикации данных и метаданных используемые на национальном уровне и в рамках отдельных отраслей (биоинформатика, лингвистика и тд).

Впрочем большая часть стандартов, всё же, про научную сферу, а Frictionless Data про общепринятую. Ещё год-два и публиковать данные в виде "голого" CSV или XML файла будет неприличным. Упакованные данные куда ценнее и пригоднее к работе.

Ссылки:
[1] https://framework.frictionlessdata.io
[2] https://github.com/UTS-eResearch/datacrate
[3] https://github.com/biocompute-objects/BCO_Specification
[4] https://rd-alliance.org/
[5] https://www.force11.org/
[6] https://codemeta.github.io/

#opendata #data #standards
Первый в мире стандарт по алгоритмической прозрачности принят правительством Великобритании [1]. В описании Algorithmic Transparency Standard [2] присутствует технический стандарт заполнения сведений об алгоритмических системах [3], а также шаблон и руководство по заполнению [4]

Стандарт был разработан в CDDO, The Cabinet Office’s Central Digital and Data Office, службе созданной в апреле 2021 года с фокусом на цифровые продукты и данные.

Здесь важно напомнить что в Великобритании уже существуют Национальная стратегия данных [5] и Национальная стратегия ИИ [6], а работа по созданию этого стандарта предварялась несколькими исследованиями и анализом применения ИИ и регулирования ИИ в других странах.

Ссылки:
[1] https://www.gov.uk/government/news/uk-government-publishes-pioneering-standard-for-algorithmic-transparency
[2] https://www.gov.uk/government/collections/algorithmic-transparency-standard
[3] https://www.gov.uk/government/publications/algorithmic-transparency-data-standard
[4] https://www.gov.uk/guidance/provide-information-on-how-you-use-algorithmic-tools-to-support-decisions-pilot-version
[5] https://www.gov.uk/government/publications/uk-national-data-strategy/national-data-strategy
[6] https://www.gov.uk/government/publications/national-ai-strategy/national-ai-strategy-html-version

#ai #policy #standards #uk
Для тех кто изучает практики обмена данными я напомню про такой инструмент/экосистему как Frictionless Data [1]. Это проект Open Knowledge Foundation по стандартизации обмена данными, в первую очередь табличными.

Проект большой и, что самое главное, начавшийся со стандартов [2] и постепенно, неспешно, охватывающий разные области применения. Особенно в научной-академической среде [3] где сейчас его внедряют в исследовательских репозиториях.

Ссылки:
[1] https://frictionlessdata.io
[2] https://frictionlessdata.io/standards/

#opendata #data #standards
Весьма интересный Block Protocol [1] стандарт/протокол про интеграцию между данными и интерактивными элементами. Позволяют через данные и схемы стыковать таблицы, загрузки файлов, отображение карточек персон и так далее по заранее готовым шаблонам. Большая работа и интересная идея, стоит отслеживать его развитие. За стандартом находится команда Hash.ai [2] стартапа по созданию "Github'а для симуляций", также любопытный продукт. Немного за пределами моих интересов, но их подход к учёту и систематизации данных очень любопытен.

Ссылки:
[1] https://blockprotocol.org
[2] https://hash.ai

#protocols #standards #data
Возвращаясь к теме обнаружения данных (data discovery) то более всего она актуальна когда у компании/организации очень много разных систем и данных и есть потребность ответить себе на вопрос как узнать что и где хранится. Я ещё в допандемийное время много читал лекций про карты данных систематизацию источников данных, в первую очередь, в органах власти и госучреждениях. Но в основном я рассказывал про нетехнические методы, а есть и вполне технические, и разного рода ПО и сервисы каталогизации данных - это именно про такое.

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

А есть и гораздо более системные масштабные проекты и это Egeria [1], продукт с открытым кодом от The Linux Foundation, в котором сложно найти удобный UI, зато есть дотошнейшее описание более 800 понятий который относятся. Например, то о чём я ранее рассказывал как "semantic types" (cемантические типы данных), там определено как Glossary Terms [2] и приведена их структура, значительно сложнее чем в большинстве коммерчески доступных сервисах.

В целом Egeria - это такой сверх-систематизированный заход на понимание природы корпоративных данных, процессов, людей, групп, подразделений, правил и инструментов и ещё всего остального связанного с данными в корпоративной среде.

По моим ощущениям всё скорее движется к систематизации стандартов OpenMetadata [3] и OpenLineage [4] или появлением нового стандарта, потому что OpenMetadata слишком ассоциировано с одноименным продуктом, а OpenLineage даёт чрезмерную вариативность, очень упрощён.

Ссылки:
[1] https://egeria-project.org/
[2] https://egeria-project.org/types/3/0330-Terms/
[3] https://docs.open-metadata.org/openmetadata/schemas/entities
[4] https://openlineage.io/

#datadiscovery #opendata #data #datatools #standards
Новости стандартизации, в W3C официально принят и опубликован стандарт Decentralized Identifiers (DIDs) v1.0 [1] в котором описана структура и логика присвоения постоянных идентификаторов объектов находящихся в децентрализованных реестрах.

Фактически - это стандарт для создания аналогов DOI, Handle и других подобных идентификаторов, но на основе Blockchain'а. Идея и область применения весьма интересные, одна из областей где децентрализованные технологии оправданы. Этот стандарт долгое время был черновиком и за этой время появилось более 100 идентификаторов/протоколов/спецификаций на его основе [2]․ Многие, но не все, из них относятся явно к крипте.

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

Ссылки:
[1] https://www.w3.org/TR/2022/REC-did-core-20220719/
[2] https://www.w3.org/TR/did-spec-registries/

#standards #blockchain #w3c #identifiers
В рубрике как это работает у них, небольшой обзор проектов по работе с данными в биоинформатике. Небольшой потому что сама эта тема огромна, а публикуемые данные значительно превосходят любой портал открытых государственных данных.

Я сделаю акцент не на обработки больших наборов данных, а на проектах по повышению понимания данных и их систематизации.

Bioschemas

Многие знают про существование Schema.org как совместной инициативы поисковиков Google, Microsoft, Yahoo и Yandex для создания реестра для разметки именованных объектов. Bioschemas [1] - это расширение Schema.org объектами относящимся к химическим веществам, генам, таксонам, молекулам и другим данным важным для исследователей. Создание проекта финансируется Евросоюзом в рамках программы ELIXIR [2]. Проект идет уже более 5 лет [3] и его основная цель в том чтобы метаданные в каталогах и репозиториях данных связанных с науками о жизни были бы стандартизированы и удобны для работы.

Data Discovery Engine

Помимо структурированного описания объектов и понятий в каталогах данных важна ещё и возможность поиска по этому структурированному описанию. Data Discovery Engine [4] - это проект с руководствами по описанию метаданных и по их сбору из существующих каталогов данных таких как CD2H, N3C, Outbreak.info и NIAID Data Portal. Сейчас там агрегируются наборы данных (Datasets) и программные инструменты (Computational Tools), а в основе профили объектов определённые в Schema.org

FAIRSharing

Помимо Bioschemas в мире существуют сотни других стандартов публикации метаданных, как в науках о жизни, так и в других науках. FAIRSharing [5] - это один из крупнейших в мире каталогов таких стандартов в реестре которого собраны руководства, схемы, описания идентификаторов, рекомендации и тд. для данных публикуемых исследователями.


Ссылки:
[1] https://bioschemas.org
[2] https://www.elixir-europe.org/about-us/how-funded/eu-projects/excelerate
[3] https://docs.google.com/document/d/1vfRIT7Jk-RixpA7-_8vWLpXgFuYi2rjecx2wn04E2x0/edit#heading=h.7p6phpp9ttsf
[4] https://discovery.biothings.io/
[5] https://fairsharing.org

#opendata #openscience #openaccess #standards #data
Google решили пристыдить Apple создав специальный сайт Get the message [1] для кампании по внедрению протокола/стандарта RCS [2] для передачи текстовых сообщений.

RCS - это, действительно, стандарт и, действительно, Apple его не поддерживает, только тут важно помнить что RCS в отличие от iMessage не поддерживает опции end-to-end шифрования (шифрования точка-точка) [3] и подвержено "законному перехвату". В Google, активно промоутирующих RCS, не могут этого не знать. Поэтому открытые стандарты - это хорошо, но открытые небезопасные стандарты по умолчанию - это ничего хорошего.

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


Ссылки:
[1] https://www.android.com/get-the-message/
[2] https://www.gsma.com/futurenetworks/rcs/
[3] https://indianexpress.com/article/technology/social/google-new-chat-service-wont-be-secure-like-imessage-and-whatsapp-amnesty-international-5147050/

#standards #google #apple #messaging #rcs #privacy
Тем временем, буквально недавно, в июле, появилось предложение по изменению в стандарт HTTP добавлением типа запроса QUERY для запросов в базы данных [1] [2] нечто что имеет самое непосредственное отношение к современным базам данных, индексированию веб сайтов и работе большого числа веб ресурсов.

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

У меня лично нет уверенности в строгой необходимости такого изменения. Запросы в HTTP ещё давно проектировались по модели CRUD (GET, POST, DELETE, PUT и PATCH), а аналога SELECT никогда небыло. Большая часть REST API и запросов Ajax работают на базе GET или POST запросов.

Будет ли эффективен запрос QUERY? Хочется увидеть референсную реализацию и тестирование производительности.

Ссылки:
[1] https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
[2] https://horovits.medium.com/http-s-new-method-for-data-apis-http-query-1ff71e6f73f3

#data #standards
К вопросу о проектах по замене SQL на другие языки запросов, а есть и другой путь, создания спецификации описывающей все известные операции по работе с данными и работе SQL поверх неё и использования конверсии из её описания в SQL запросы.

Такой проект есть, он называется Substrait [1]. Его автор сооснователь проектов Apache Calcite, Apache Arrow, Apache Drill и ряда стартапов таких как Sundesk и Dreamio.

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

Уже есть много референсных реализаций спецификации для Ibis, Dpyr, Apache Calcite, Trino и Spark.

Для тех кто не сталкивался с этими продуктами - все они представляют уровни абстракции для работы с данными. Например, Ibis в Python [3] даёт возможность делать SQL запросы без SQL. Удобно для тех кто любит Python way для работы с данными.

Substrait выглядит весьма перспективно, если вендоры в этом направлении потянутся, то может стать глобальной спецификацией и даже стандартом.

Ссылки:
[1] https://substrait.io/
[2] https://docs.google.com/presentation/d/1HQReIM6uB1Dli_yXfELOJWAE6KsvXAoUmHLlTYZ8laA/edit#slide=id.g1476627d6f9_0_213
[3] https://ibis-project.org

#standards #data #bigdata #dataengineering
Свежий стандарт по публикации результатов научной деятельности в открытом доступе Cross Domain Interoperability Framework (CDIF): Discovery Module [1] создан в рамках проекта WorldFAIR [2] и охватывает самые разнообразные объекты, но, что важнее, он описывает их публикацию используя schema.org что существенно повышает их находимость для поисковиков, в первую очередь, Google, но не только. Существенная часть стандарта про публикацию наборов данных, с отсылками в другим стандартам, включая DCAT, DataCite, ISO19115, EML, FGDC CSDGM, CERIF и DDI. Странно разве что отсутствие упоминания OAI-PHM. Как бы то ни было, потенциально это новый стандарт, который может быть вскоре одобрен в ЕС.

Ссылки:
[1] https://zenodo.org/records/10252564
[2] https://worldfair-project.eu/2023/12/05/cross-domain-interoperability-framework-cdif-discovery-module-v01-draft-for-public-consultation/

#opendata #datastandards #eu #standards #data #openaccess
Вышел стандарт DCAT-AP 3.0 по публикации каталогов открытых данных. Это официальный стандарт Евросоюза по публикации данных и он основан на стандарте DCAT 3.0 от W3C.

Изменений там немало, но и не критично. DCAT давно используется всеми основными разработчиками общедоступных каталогов данных и геоданных.

Его отдельные ревизии есть в ЕС, в США, в отдельных европейских странах и ещё в ряде стран мира.

В Армении, если появится государственный портал открытых данных, он тоже будет с поддержкой DCAT. Если не появится, то мы добавим поддержку в Open Data Armenia

В РФ стандарт DCAT ни в какой версии не применялся. В начале инициатив по открытости Минэк РФ придумал свои "методические рекомендации" с раскрытием метаданных в виде CSV файлов. Чтобы облегчить краулинг данных на портал data.gov.ru. Рекомендации эти применяют до сих пор, хотя они и морально и технически устарели, а data.gov.ru более не существует.

Пока же добавлю что DCAT поддерживается в Dateno при индексации каталогов и, в частности, метаданные из порталов на базе ArcGIS Hub собираются именно в формате DCAT.

#opendata #data #standards
В рубрике как это устроено у них новый каталог открытых данных Словакии data.slovensko.sk заменил предыдущий портал data.gov.sk (более недоступен). Новый портал переписали на CSharp и его код доступен [1]. Из его особенностей - это ориентация на SPARQL, доступность возможности работы со SPARQL эндпоинтом, а также то что краулит из 12 каталогов открытых данных страны и подлерживает каталоги датасетов по стандартам DCAT-AP, SPARQL и CKAN API.

Выглядит любопытно, но эта картина была бы неполной если бы:
1. Разработчики не поломали бы все ссылки на data.gov.sk которые были в европейском data.europe.eu где новый портал даже не зарегистрирован, а старый уже недоступен и ссылки "протухли"
2. Нет общедоступной документации API нового каталога
3. Нет экспорта DCAT AP или CKAN API у нового каталога.

В целом очень неаккуратно. Про SPARQL я скажу так, у него и Semantic Web есть очень много сторонников в европейских проектах за госсчёт, но к современной дата инженерии он имеет смутное отношение. Вообще никакого, если честно. Экспорт данных в Parquet, удобное REST API и, может быть, даже GraphQL эндпоинт куда важнее.

Ссылки:
[1] https://github.com/slovak-egov/nkod-portal

#opendata #slovakia #eu #standards #data #datasets
Вышла вторая версия стандарта Data Package [1] ранее он назывался Frictionless Data. Полезен он будет всем кто публикует табличные CSV файлы которые с его помощью очень хорошо описываются. Это большой плюс, особенно для тех кто не является дата инженерами или аналитиками, а рядовыми учёными, пользователям и тд.

Это же и минус. Лично я вспоминаю что мало какие интересные данные публиковал за последние годы именно в CSV. В основном же это были JSON lines файлы или parquet. А стандарт пока CSV ориентированный, что не отменяет его полезности если с CSV Вы работаете и активно. Или если пользователи готовят всё ещё данные в Excel, а надо бы что-то получше.

Так что ругаю я зря, а хвалю не зря. Стандарт надо использовать и развивать спектр поддерживающих его инструментов.

Ссылки:
[1] https://datapackage.org

#opensource #standards #opendata #data #okfn