Для тех кто изучает практики обмена данными я напомню про такой инструмент/экосистему как 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