В рубрике о нас пишут, о нашем исследовании приватности мобильных приложений написали:
- Эксперты оценили долю американских трекеров в RuStore РБК
- «Инфокультура» исследовала приватность мобильных приложений в RuStore Роскомсвобода
- Почти 90% приложений в RuStore имеют встроенный иностранный трекер Runet.News
- В приложениях российского магазина RuStore нашли зарубежные модули слежки Ferra
а также ещё пара десятков СМИ и телеграм каналов.
Не менее важно кто ничего о нём не написал: CNews, Коммерсант, Ведомости и ещё ряд изданий. Как говорится, Бог простит, а я запишу (с) ;)
Это не последнее наше исследование, будут и другие и не только про мобильные приложения.
#research #privacy #mobileapps
- Эксперты оценили долю американских трекеров в RuStore РБК
- «Инфокультура» исследовала приватность мобильных приложений в RuStore Роскомсвобода
- Почти 90% приложений в RuStore имеют встроенный иностранный трекер Runet.News
- В приложениях российского магазина RuStore нашли зарубежные модули слежки Ferra
а также ещё пара десятков СМИ и телеграм каналов.
Не менее важно кто ничего о нём не написал: CNews, Коммерсант, Ведомости и ещё ряд изданий. Как говорится, Бог простит, а я запишу (с) ;)
Это не последнее наше исследование, будут и другие и не только про мобильные приложения.
#research #privacy #mobileapps
РБК
Эксперты оценили долю американских трекеров в RuStore
Почти 90% приложений из магазина RuStore используют иностранные трекеры — они могут собирать как техошибки, так и данные пользователей. Создатель маркетплейса — холдинг VK подчеркивает: на безопасность данных это не влияет
У Postman вышел их ежегодный обзор 2022 State of the API Report [1] составленный через опрос разработчиков пользующихся их платформой и схожий с исследованиями JetBrains.
Исследование полезное, много графиков, большая выборка, много чего любопытного. Конечно, с оговоркой что они делают акценты там где их собственный продукт посильнее, а некоторые темы вроде предпочтений по корпоративной интеграции или языки разработки охватывают мало или недостаточно.
Полезно будет, в первую очередь, тем кто выбирает приоритеты в изучении новых технологий.
Ссылки:
[1] https://www.postman.com/state-of-api/how-to-share-the-report/
#api #studies #research #postman
Исследование полезное, много графиков, большая выборка, много чего любопытного. Конечно, с оговоркой что они делают акценты там где их собственный продукт посильнее, а некоторые темы вроде предпочтений по корпоративной интеграции или языки разработки охватывают мало или недостаточно.
Полезно будет, в первую очередь, тем кто выбирает приоритеты в изучении новых технологий.
Ссылки:
[1] https://www.postman.com/state-of-api/how-to-share-the-report/
#api #studies #research #postman
Онтология типов данных
Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология 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] http://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://yangx.top/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] http://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://yangx.top/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.
The Open Data Canvas–Analyzing Value Creation from Open Data [1] научная статья за авторством Yingyng Gao и Marijn Janssen посвящённая созданию аналога канвы для бизнес модели, но для проектов на открытых данных. Авторы неплохо поработали над структурой канвы, с научной точки зрения интересны полезна их логика рассуждения, с практической - это структура запуска проекта на открытых данных. Составление таких канв проектов полезно когда ты проектируешь новый проект, или в процессе обучения, или, не в меньшей степени, на хакатонах и конкурсах, когда участники вначале проектируют то что они хотят сделать.
В статье примеры канвы по COVID-19 Dashboard, в целом отражающей действительности.
Со своей колокольни я вижу то чего в такой канве не хватает - это устойчивости (sustainability). В канве бизнес-модели этого нет потому что предполагается что бизнес приносит деньги, а если он не приносит, то это не бизнес. Иначе говоря, бизнес модель всегда предполагает наличие кэш флоу если не от клиентов, то от инвесторов.
В случае с любыми некоммерческими проектами, такими как проекты на открытых данных, кэш флоу может не быть. То что указано в Costs может быть как постоянным, частью деятельности чего-то, как COVID-19 Dashboard часть деятельности института Джона Хопкинса, так и может быть и, чаще, является потребностью в поиске финансирования/смены структуры продукта и проекта.
Как бы то ни было этот шаблон канвы вполне пригоден и полезен в работе. Осталось его только красиво оформить, поместить во что-нибудь вроде Miro и похожие инструменты.
Ссылки:
[1] https://dl.acm.org/doi/pdf/10.1145/3511102
#opendata #canvas #businessmodel #research
В статье примеры канвы по COVID-19 Dashboard, в целом отражающей действительности.
Со своей колокольни я вижу то чего в такой канве не хватает - это устойчивости (sustainability). В канве бизнес-модели этого нет потому что предполагается что бизнес приносит деньги, а если он не приносит, то это не бизнес. Иначе говоря, бизнес модель всегда предполагает наличие кэш флоу если не от клиентов, то от инвесторов.
В случае с любыми некоммерческими проектами, такими как проекты на открытых данных, кэш флоу может не быть. То что указано в Costs может быть как постоянным, частью деятельности чего-то, как COVID-19 Dashboard часть деятельности института Джона Хопкинса, так и может быть и, чаще, является потребностью в поиске финансирования/смены структуры продукта и проекта.
Как бы то ни было этот шаблон канвы вполне пригоден и полезен в работе. Осталось его только красиво оформить, поместить во что-нибудь вроде Miro и похожие инструменты.
Ссылки:
[1] https://dl.acm.org/doi/pdf/10.1145/3511102
#opendata #canvas #businessmodel #research