Публикация открытых данных — благородное занятие, которое стимулирует исследования, инновации и прозрачность. В то же время заниматься этим бывает утомительно, а пользователи могут делать с вашими данными все, что им угодно. Такая утеря контроля над данными может быть нежелательной, но в некоторых случаях закон обязывает публиковать данные именно под открытой лицензией.
Лучший выход из подобной ситуации — опубликовать формально открытые данные, но сделать так, чтобы они никому не были интересны. Специально для таких сценариев я составил перечень стратегий, которые помогут избежать нежеланного внимания пользователей, заинтересованных в работе с вашими данными.
В основу списка лег мой опыт взаимодействия с источниками открытых данных и обучения студентов дата-инжинирингу, а также уроки, которые я вынес из общения с другими специалистами, работающими с открытыми данными.
1. Выберите запутанную лицензию
Самый простой способ отбить интерес к вашим данным — усложнить понимание того, являются ли они вообще открытыми. Избегайте популярных лицензий открытых данных, имеющих понятное краткое описание (наподобие тех, что публикуются Open Knowledge Foundation). Убедитесь, что лицензию, под которой находятся ваши данные, трудно найти (не используйте в метаданных идентификатор SPDX). По возможности вообще откажитесь от лицензии и ссылайтесь только на условия использования данных и другие подобные документы.
Если избежать использования стандартной лицензии невозможно, то хотя бы попытайтесь найти лицензию на своем языке — по крайней мере, это отпугнет пользователей из других стран.
Бонусные очки за конспирацию получают те, кто публикуется на Kaggle с лицензией «Other (specified in description)» без указания лицензии в описании.
2. Указывайте только метаданные при публикации
Взгляните на эту карту, созданную французской Национальной точкой доступа для данных о транспорте:
Или на проект Datenwaben Томаса Турсикса. Оба проекта привлекают внимание. Они так здорово оформлены, что использованные в них данные хочется позаимствовать для собственного проекта.
Нам нужно добиться противоположного эффекта. Поэтому стремитесь публиковать минимально требуемые метаданные и пишите фактические, скучные описания. Старайтесь любой ценой избегать примеров данных и того, как их использовать. В мире полно ничем не примечательных датасетов — у вас точно будет шанс затеряться в толпе.
2.5 В том же ключе: добавляйте в данные как можно меньше информации
Некоторые платформы, например, Kaggle, автоматически показывают пользователям превью данных, содержащихся в датасете. Например, см. этот датасет по распознаванию мошенничества с кредитными картами.
Встроенные превью данных и краткие описания распределений значений в каждом столбце позволяют легко оценить, подходят ли данные для использования. Чем меньше трудностей для пользователя, тем выше вероятность, что он отнесется к вашим данным с энтузиазмом. Поэтому постарайтесь избегать генерации превью и кратких описаний данных.
3. Сделайте все, чтобы данные было сложнее найти
На самом простом уровне можно подбирать короткие и непонятные названия, а также минимально подробные описания. Это уже усложнит индексирование ваших датасетов поисковыми движками.
Кроме того, можно попробовать скрыть свои данные, просто не распространяя их широко. У порталов открытых данных наподобие govdata.de часто есть качественные функции поиска или даже API, которые можно использовать программно. Разумеется, для вас это будет катастрофой, так что создайте отдельный портал только для себя и публикуйте данные только там.
4. Используйте непопулярные или сложные в применении форматы
Если публиковать данные в удобных форматах наподобие CSV или JSON, придется смириться с угрозой того, что пользователи свободно будут иметь к ним доступ. Можно попробовать публиковаться в формате, требующем коммерческих инструментов, например, в XSL, но сегодня даже такие форматы сможет преобразовать большинство людей. Лучшее решение — найти формат файлов, нечитаемый для машин. Популярный выбор — PDF, особенно если добавить в него наряду с данными дополнительного текста, например, верхних или нижних колонтитулов.
4.5 Экспортируйте данные, отформатированные под людей
При экспорте табличных данных постарайтесь сохранить структуру такой, какой она изначально проектировалась для живых читателей. Оставьте объединенные ячейки, красивые заголовки и сноски. Если вы выполняете экспорт в CSV, то добавьте в файл чисто текстовые метаданные, например, заявления о правах на копирование, чтобы поломать автоматизированный импорт. Если для использования данных пользователям придется выполнять долгий ручной процесс очистки, то они могут отказаться от этой идеи.
5. Убедитесь, что все URL ведут к 404
Если вам абсолютно необходимо выложить свои датасеты на порталы открытых данных, то воспользуйтесь тем, что часто они могут хранить только метаданные и обратные ссылки на ваш источник. Периодически реструктурируйте свой портал данных без настройки правильных редиректов, чтобы первое, что видели нетерпеливые пользователи — это страница 404 (а еще лучше — страница с объяснением, что портал теперь имеет новую структуру и все данные находятся где-то в другом месте). Это разочарует потенциальных пользователей и охладит их интерес.
5.5 Меняйте данные после публикации
Если у вас нет возможности переместить свои данные куда-нибудь еще, попробуйте менять их по тому же URL без какой-либо системы версий и уведомлений. В этом случае пользователи, которые скачивают и просматривают ваши данные, могут впасть в ступор при повторном запуске своего ПО. Если пользователь поймет, что ему нужно постоянно заново скачивать и валидировать ваши данные, скорее всего, он больше не вернется.
6. Разделяйте связанные датасеты
У вас есть датасет, данные которого охватывают множество лет? Прекрасно. Разбейте его на множество отдельных файлов и не связывайте их очевидным образом. Поиск всех датасетов и их объединение — это дополнительная работа для каждого, кому взбредет в голову воспользоваться вашими данными. К счастью для вас, дата-сайентисты ненавидят делать лишнюю работу.
У этого метода есть еще одно преимущество: он позволяет лучше спрятать ценность ваших данных. Скорее всего, пользователь решит, что ваш датасет старый или неполный, и оставит вас в покое. Возьмем для примера этот датасет футбольных данных начиная с 1960 года. Разве вам не хочется сразу узнать, как данные менялись со временем? Представьте, насколько менее удобно было бы это делать, если бы данные публиковались по одному файлу в год. Скорее всего, нашедший данные за 1960 год человек решит, что они старые и давно не обновлялись, а потому пойдет донимать кого-то другого.
Дополнительная цель, к которой стоит стремиться: автоматически распределяйте данные по порталам данных, но оставляйте описание и важный контекст только на собственном веб-сайте. Это позволит усложнить работу с данными и создать иллюзию об их низком качестве.
Работая над этим переводом, я так и не сумел до конца понять замысел автора. Что двигало им при создании статьи? Это попытка написать что-то в духе «Вредных советов» для специалистов по работе с данными? Своего рода анти-гайд, который объясняет, как делать не надо? Или я это себе накрутил, и текст стоит воспринимать как обычное руководство?
Думаю, ответ на этот вопрос зависит от позиции читателя. Какая интерпретация, на ваш взгляд, ближе к истине? Буду рад вашим комментариям.
Комментарии (9)
dmitry78
19.09.2024 12:04"физики продолжают шутить" : как оформить публикацию для экспертного совета" - 4.04 в цифровую эпоху
le2
19.09.2024 12:04+2Госчиновники сделают все чтобы:
нельзя было найти по зарегистрированным изобретениям. Теоретически да, но я после 40 минут поиска в том числе своего изобретения сдался.
навяжут ненужные услуги по печати на бумаге. Например нельзя скачать ГОСТы
нормативные документы будут отсканированы, а если с текстом, то почему-то поиск там не будет работать.
В опенсорсе Корпорация Добра и прочие сделают все чтобы
изменения были в виде одного патча в 200 МБ поверх ванильного ядра.
если git, то это будут один склеенный коммит от робота без описания.
роадмап и вообще над какой проблемой они работают - вам не покажут.
тестовые прогоны будут ссылаться на внешние компоненты, которых вам не дадут.
самый смак - логика программы будет в виде графа, но сам граф вам не предоставят. Распарсивать вам его будет очень больно, потому что он огромен.
отдельная боль - научные публикации. Формально нет никакой лжи, но будет подано так что даже специалист может прийти к неправильным умозаключениям. После потраченых усилий на изучение вы поймете что вас развели.
В датасетах могут быть сфальсифицированные данные, так чтобы, к примеру, человек бы не справился, а робот да, потому что данные нарочно расфокусировали.Vugluskr1
19.09.2024 12:04Именно этим занимается, к примеру, Ермакова, она до сих пор свои исследования выкладывает по паре строчек. И рассказывает что когда полностью опубликует данные о ГМО, все поймут как оно смертельно.
Vugluskr1
19.09.2024 12:04+1Это сделать очень легко. Человечество давно придумали лекарства. Нейролептики. И ваши данные перестанут всех интересовать.
manfredima
19.09.2024 12:04Просто перестаньте выпячивать свои достижения и доходы, чтобы произвести впечатление на окружающих :)
19Zb84
Что бы отбить все желание пользоваться проектом, надо писать его так, что бы он запускался только спустя неделю допиливания напильником (самое частое с чем встречался) .
Сделайте монорепозиторий разбив приложение на кучу библиотек и вносите в них изменения ломающие код. Кроме вас никто не сможет понять, какие версии библиотек дадут рабочий вариант.
ost-vld
в монорепе можно разобраться, только субпроекты и устаревшие версии субрепозиотриев в основном проекте, и еще пару субпроектов не добавить.