Registry: Добавить категорию в набор данных

Спасибо!

~ Предполагая, что это также будет поддерживать метрики (и понимая, что многозначность означает, что набор данных может принадлежать более чем одной категории), я хотел бы добавить ~
~9. данные частного сектора~
~10. данные отслеживания (т. е. повторные отловы или GPS-отслеживание отдельных организмов) ~

[Тим: Спасибо — добавлено выше!]

Вопрос: должны ли 4. метагеномные (эДНК) быть двумя отдельными категориями? Существует большая разница в интерпретации этих данных, хотя они оба «основаны на последовательности» @ManonGros , не могли бы вы прокомментировать?

[Тим отредактировано, чтобы добавить: я разделил их выше, но снова изменю, основываясь на дополнительных комментариях]

Машинное наблюдение похоже на подкатегорию события выборки.

Машинное наблюдение похоже на подкатегорию события выборки.

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

Эта новая категория будет свободным текстом с использованием сервера vocab? Или мы пытаемся определить все категории?

Эта новая категория будет свободным текстом с использованием сервера vocab? Или мы пытаемся определить все категории?

~Не определился, но на данный момент мы предлагаем категории~

Исправлено: теперь я бы предложил сервер словарей, как подробно описано ниже в этой теме.

Здорово! Мне нравится эта идея!

~Только один комментарий:~
~> 4. Метагеномный отдельный организм (т.е. ткань из образца NHM)~
~> 5. ЭДНК окружающей среды (например, образец почвы, вода, бульон из насекомых и т. д.)~

~ Номер 4 не кажется правильным. Что я понимаю, читая «Метагеномный анализ одного организма», так это то, что кто-то взял образец кишечника коровы (например) и секвенировал его, получив множество вхождений для кишечного микробиома. Я думаю, это не идея, не так ли? ~
~ Если вы имеете в виду, что ткани из образца были секвенированы, то я бы написал что-то более похожее на «Секвенирование одного организма». И на самом деле мы могли бы сгруппировать метагеномику с эДНК (часто эДНК — это метагеномика). Итак, в конце концов, я думаю, мы могли бы сделать что-то вроде: ~

~4. Секвенирован отдельный организм (например, ткань из образца NHM)~
~ 5. ЭДНК окружающей среды и/или метагеномика (например, образец почвы, вода, бульон из насекомых и т. д.)~

[Тим: Отредактировано с предложениями, высказанными здесь — спасибо, вы действительно поняли, что я имел в виду!]

Возможно, у @thomasstjerne есть какие-то мысли по этому поводу?

Добавлено обнаружение целевых видов (анализы на основе ПЦР)

Спасибо @timrobertson100 за то, что познакомил меня с веткой, очень интересно. На данный момент я нашел восемь вероятных независимых переменных, которые могут определять тип доказательства/набора данных в GBIF. Мне нужно еще немного помедитировать, прежде чем излагать здесь свои взгляды, и буду рад провести мозговой штурм / доску, если люди будут доступны?

Отслеживаем и это

Привет всем, мне нравится идея сортировки наборов данных и типов доказательств, но я не уверен, что это наиболее привлекательно для пользователей делать это с использованием одного фильтра/словаря (но я получил осуществимость, как выразился Тим). Я нарисовал несколько ментальных карт, но у меня нет времени добавлять сюда картинки, так что просто напишите на ваше усмотрение. Я начал с размышлений, зачем пользователям сортировать наборы данных/типы доказательств? Это быстрый способ включить/исключить типы данных, которые важны для ваших дел, в зависимости от того, как были созданы доказательства и их свойства. Я придумал 8 независимых переменных, которые пересекаются с предложенной категоризацией набора данных и словарем baseOfRecord, который у нас есть сегодня. Обратите внимание, что я думаю, что здесь важна независимая работа, хотя некоторые из комбинаций 1-8 ниже невозможны в реальной жизни.

Я использую расплывчатые слова, чтобы описать свое мышление, это не словарь, который я предлагаю, и есть некоторые неразрешенные совпадения:

1. Статус сохранности свидетельства: только виртуальный или физический: ископаемое, мертвое, живое (зоопарки, культуры, сады, аквариумы). Обратите внимание, что некоторые мысли, такие как янтарь, нелегко разместить, так как из янтаря можно получить ДНК, есть субокаменелости и т. Д.). _Вопрос_: Могу ли я повторно изучить физический материал? Что и где это?
2. Целостность / N видов: Одиночные и целые (например, насекомое, т.е. содержит весь свой генет в одной особи), частичный (образец ткани, лист, плодовое тело) или смешанный образец (обычный в коллекции мхов и лишайников, когда сбор отдельных видов невозможен) : но это не преднамеренный отбор проб, например, как планктон, см. 6). _Вопрос_: Могу ли я изучить полную морфологию, или только некоторые признаки, или только связать музейный образец с последовательностью ДНК?
3. ДНК: не исследовано, секвенирование, ПЦР. Примечание: это что-то среднее между виртуальным и физическим, поскольку продукты ДНК или ПЦР могут храниться в течение длительного времени (физически), но ДНК-доказательство присутствия вида, часто последовательность, представляет собой созданное машиной виртуальное доказательство, мало чем отличающееся от цифрового изображения или звук. _Вопрос_: Могу ли я перепроверить идентификацию, провести филогению, или все, что у меня есть, это название лейбла?
4. Динамические/статические данные. Динамические: отслеживание, временные ряды, отметка-повторный захват. _Вопрос_: можно изучать только процессы или только паттерны?
5. Способ формирования доказательств: обработка литературы, оцифровка коллекции, личные наблюдения, систематическая выборка. _Вопрос_: Можно ли сортировать данные по надежности их генерации?
6. Для выборки данных о событиях, но, возможно, и о событиях: только наличие (усилие по выборке неизвестно/недокументировано), присутствие-отсутствие, изобилие (количественное). _Вопрос_: Какие виды статистического анализа возможны?
7. Способ упаковки данных в GBIF: только метаданные, контрольный список, только вхождения, событие выборки. Может включать фильтр по используемому расширению, особенно. если мы получим больше из них в TDWG. _Вопрос_: Что я получаю при загрузке GBIF, дословно и в интерпретации GBIF?
8. Сообщество, генерирующее данные (возможно, это больше относится к пометке издателей, но может потребоваться фильтрация вхождений и наборов данных по): (группам) отдельных лиц, коллекциям естественной истории, частному сектору, морскому делу, гражданской науке, машине. Некоторые из них не исключают друг друга: это может быть «сборник естественной истории» + «гражданская наука» или «машина». _Вопрос_: Могу ли я изучать тенденции данных в определенном демографическом секторе?

Еще раз, это просто захват незавершенных мыслей; было бы неплохо провести мозговой штурм / провести доску, как будет выглядеть хорошая категоризация. Я думал нарезать его, например, 1, 7 и 13 в исходном посте могут быть одновременно правдой. Если это теги и перекрытие не проблема, то ладно. Но если это строгий фильтр, нам может понадобиться больше, чем просто поле для захвата типов сохранения по сравнению с созданием сообщества по сравнению со способами создания по сравнению с количественными параметрами и т. д. Не стесняйтесь отбрасывать, если это выходит за рамки. Я также не нашел подборку обсуждений BoR, которая здесь частично применима.

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

Например, предположим, что мы просим менеджеров узлов проверить наборы данных с тегом «гражданская наука». Мы хотим:

1. Для них это простой способ увидеть все наборы данных Citizen Science для своего узла.
2. Если менеджер узла заметил, что набор данных помечен ошибочно, мы хотим отследить это, чтобы в следующий раз не помечать его повторно.

Глядя на эту проблему: https://github.com/gbif/portal-feedback/issues/3381 , нам не хватает категории data extracted from taxonomic literature (i.e., Plazi) . Вы правы, я пропустил это!

Спасибо @ManonGros

Глядя на эту проблему: gbif/portal-feedback#3381, мы бы упустили данные, извлеченные из категории таксономической литературы (например, Plazi).

Вот что это было задумано:

Ссылки на материалы (например, таксономические трактовки в литературе)

(Связано с тем, что Плази только что предложил Material citation в качестве дополнения к словарю baseOfRecord в выпусках Darwin Core для общественного обсуждения)

+1 @Dmitry для одного ко многим и с использованием тегов ключевых слов (вместо основной записи 1: 1 в категорию)
+1 @Marie за мысль о том, чтобы позволить персоналу Node курировать категории ->, а также может добавить запрос функции, позволяющий любому аннотировать точку данных / набор с информацией о категории (с сохранением происхождения)

Помните также, что «набор данных» (как в Darwin-Core-archive-dataset) может быть смешанным набором «доказательных записей» (также известных как основные записи, например, события) разных категорий — если категория «тег» предназначен для применения ко всем основным записям в DwC-A

И что денормализация «доказательных записей» (основных записей) означает, что нельзя быть уверенным в том, с каким классом должно быть связано данное свойство, связанное с основной записью.

Мне очень нравится эта идея. Конечно, у ALA есть пользователи, которым нужен очень простой способ выбора групп записей среди поставщиков данных. Группа, от которой я чаще всего слышу эту просьбу, — это кураторы/исследователи, которым «просто» нужны музейные или гербарные образцы.

Несколько предложений:

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

1. Секвенирован один организм (например, ткань из образца NHM)
   Было бы очень полезно иметь дополнительную категорию для образца ткани, независимо от того, были ли получены последовательности или нет.
   Пользователями этой категории могут быть исследователи, ищущие ткани для кредита/деструктивного отбора образцов, которые в настоящее время должны искать BasisOfRecord = образец материала плюс удача для подготовки.

2. Данные частного сектора – вы имеете в виду данные, собранные компаниями, проводящими оценку воздействия на окружающую среду до утверждения проектов разработки/добычи? Если это так, то в Австралии их обычно называют «данными сторонников» (т. е. данными сторонников разработки). Если данные по частному сектору означают что-то еще, возможно, они могут иметь и то, и другое?

Помните также, что «набор данных» (как в Darwin-Core-archive-dataset) может быть смешанным набором «доказательных записей» (также известных как основные записи, например, события) разных категорий — если категория «тег» предназначен для применения ко всем основным записям в DwC-A

Спасибо, @dagenresen. Моя мысль заключалась в том, чтобы попытаться отделить это от проблем класса/базиса записи в Darwin Core, чтобы иметь возможность быстро реагировать на отчеты/потребности пользователей (например, ввести новый тег для наборов данных). Признавая, что могут быть «смешанные» наборы данных, моя интуиция подсказывает, что большинство пользователей оценили бы широкую фильтрацию, например, «исключая записи, происходящие из наборов данных, помеченных как eDNA», даже если там было несколько записей, которые могут представлять некоторый интерес, или для создания отчетов (например, графиков роста) на основе, например, данных, полученных из наборов данных, помеченных как относящиеся к частному сектору. Это кажется разумным, пожалуйста?

очень нравится эта идея

Спасибо, @elywallis - я добавлю ваш вклад в список вверху.

Данные частного сектора – вы имеете в виду данные, собранные компаниями, проводящими оценку воздействия на окружающую среду до утверждения проектов разработки/добычи?

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

Немного не по теме, но, возможно, полезно:

Возможно, это мало кому известно, но GBIF постепенно перемещает подобные словари на наш интегрированный сервер словарей. Это позволит менеджерам данных (например, включая менеджеров узлов @dagendresen ) участвовать в определении концепций. Концепции могут быть иерархическими (например, более точная категоризация личных данных), и как только версия словаря выпущена, она подбирается в конвейерах обработки данных. Это все еще развивается, но LifeStage уже находится в производстве.

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

наборы данных «смешанного мешка»

@ timrobertson100 Я бы (если бы меня спросили) полностью согласился с тем, что лучше всего избегать наборов данных «смешанного пакета» и что «тег» для включения фильтра для _«цели повторного использования»_ был бы очень полезен и приветствуется! И поверьте, мы могли бы хорошо жить с такой функциональностью, не применяя 100% к наборам данных «смешанного пакета» :-)

(кстати, GBIF Норвегия ведет «переговоры» с норвежскими издателями данных о «разбиении» «смешанных» наборов данных на более мелкие наборы данных, которые были бы более однородными)

@timrobertson100 написал:

Немного не по теме, но, возможно, полезно:

Возможно, это мало кому известно, но GBIF постепенно перемещает подобные словари на наш интегрированный сервер словарей. Это позволит менеджерам данных (например, включая менеджеров узлов @dagendresen ) участвовать в определении концепций. Концепции могут быть иерархическими (например, более точная категоризация личных данных), и как только версия словаря выпущена, она подбирается в конвейерах обработки данных. Это все еще развивается, но LifeStage уже находится в производстве.

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

Тим, ты видишь мой? В какой-то момент нам понадобится что-то, доклад от GBIF, вебинар TDWG, об этой работе. Я думаю, что более широкое сообщество найдет очень поучительным то, как мы можем использовать данные, которые у нас есть, для улучшения и понимания данных.