Проект:Таксономия/Использование latin vs. parent и rang

Работая с этим шаблоном заметил одну вещь — заявление о простом изменение классификации не соответствует действительности. Для рассмотрения возьмём гипотетическую (но очень) возможную ситуацию. Сейчас в семействе Зонтичные описано что-то около 37 родов из более 300 и около 120 видов из, примерно, 3500. При этом семейство никак не делится на подсемейства и трибы, но в викивидах и у немцев de:Doldenblütler такое деление присутствует. В связи с этим возникает маленький нюанс — при изменении систематики семейства придётся править не только шаблоны родов (коих сейчас около 37), но и такое же количество статей о родах. При этом мы дважды указываем старший таксон и ранг данного таксона — в статье о таксоне и в шаблоне данного таксона. Решить эту ситуацию можно отказом от использования полей parent и rang и использованием только поля latin для таксонов ВЫШЕ вида, а для статьей о видах и более мелких рангах применять существующую систему. --GreenZmiy 05:17, 3 июня 2010 (UTC)[ответить]

P.S. При этом очень пригодится система категоризации в виде системы классификации данного царства, т.к. позволит быстро и просто выбрать все подтаксоны какого-либо таксона. --GreenZmiy 05:17, 3 июня 2010 (UTC)[ответить]

• Да, это предложение вполне выполнимо, для этого необходимо провести некоторые косметические изменения. Затем пройтись ботом и вычистить лишние параметры. Еще можно дополнить таксономические шаблоны номенклатурными цитатами не только для монотипных таксонов, но и для любых, и выводить эти сведения в карточку организма. Хотя, возможно это уже лишнее. --Chan 08:31, 3 июня 2010 (UTC)[ответить]

• Тогда может начать с того, что убрать викификацию ранга описываемого таксона (см. Овсяница, Белена) и, по возможности, добавить взятие названия ранга из шаблона. --GreenZmiy 12:48, 5 июня 2010 (UTC)[ответить]

• Убрал проверку присутствия какого либо значения у параметра rang. Теперь, параметры parent и rang можно не использовать, если существует таксономический шаблон, с названием указанным в параметре latin. Единственный косметический недостаток — название последнего ранга ссылается на своё латинское название и не выделено полужирным шрифтом, в отличии от оформления при использовании параметров parent и rang. „Грим накладывать“ будем? Chan 02:42, 6 июня 2010 (UTC)[ответить]

• К предыдущему сообщению есть маленькое дополнение: параметр rang всё таки надо заполнять, если используется параметр typus. Когда параметр rang пуст, или не соответствует значениям предусмотренным для типового вида или рода, тогда раздел озаглавливается строкой «Типовой представитель». --Chan 05:59, 7 июня 2010 (UTC)[ответить]

При вызове таксономических шаблонов через параметр latin текущий ранг показывается ссылкой (см. статью о роде Овсяница). --GreenZmiy 08:01, 4 декабря 2009 (UTC) P.S. Можен и название ранга брать из шаблона, а не задавать через параметр rang?[ответить]

Я уже не помню с какой целью был реализован вызов таксономического шаблона через latin (наверное для отладки). Если такой вызов имеет смысл, то действительно его стоит доработать, но я смогу заняться этим не скоро. Обдумайте пока все за и против по доработке такого режима.--Chan 06:12, 5 декабря 2009 (UTC)[ответить]

Действительно нужно избавится от параметров parent и rang, и использовать только latin. Если хотите, могу со временем этим заняться. S.J. 00:59, 9 июня 2010 (UTC)[ответить]

Пока нет полной уверенности в целесообразности полного отказа от параметров parent и rang. Дело в том, что существует огромное количество видов (и большое количество статей о них), у которых рассмотрение младших таксонов (и создание статей о них) не имеет смысла. Сейчас, для таких статей нет необходимости создавать таксономический шаблон, достаточно используя параметры parent и rang обращаться к вышестоящему таксону (точнее его таксошаблону). Полный отказ от этих параметров потребует существенного увеличения таксономических шаблонов, при этом дополнительно создаваемые таксошаблоны будут вызываться только одной статьёй (что не есть хорошо). Chan 01:33, 9 июня 2010 (UTC)[ответить]

Я так же не уверен, что необходим полный отказ от параметра parent. Шаблон рода будет вызываться минимум три раза (монотипные роды я не рассматриваю), а вот видой, в большинстве случаев, будет вызван только один раз. --GreenZmiy 02:07, 9 июня 2010 (UTC)[ответить]

у которых рассмотрение младших таксонов (и создание статей о них) не имеет смысла - можете дать примеры таких статей ? S.J. 11:44, 10 июня 2010 (UTC)[ответить]

Легко!

1. Осока Бигелоу
2. Осока Буека
3. Осока Буксбаума
4. Осока Буханана
5. Осока Дэвелла
6. Осока Ильина
7. Осока Кабанова
8. Осока Кобомуги
9. Осока Микели
10. Осока Отрубы
11. Осока аргунская
12. Осока безжилковая
13. Осока белая
14. Осока береговая
15. Осока бледноватая
16. Осока блошиная
17. Осока богемская

...

и мн. др., полный список см. Виды рода Осока. --Chan 02:46, 11 июня 2010 (UTC)[ответить]

И что тут является младшим таксоном. Я вижу, что есть статьи как о младших таксонах, типа Осока Кабанова, так и ранга на один выше Осока,и на два Осоковые. Что же тут лишнего ? Разве тут что-то пропущено ? S.J. 05:46, 11 июня 2010 (UTC)[ответить]

Мы явно друг друга не понимаем. Попробую сначала. В списке приведена малая часть видов рода Осока. Вид — это основной ранг, один из ключевых в таксономии. Но систематики зачастую оперируют рангами ниже вида (младшими) — subsp., var. и другими, которые в своём большинстве не могут стать самостоятельным объектом для рассмотрения в Википедии и которые в обиходном языке называют разновидностями. Конечно, могут быть и исключения, например Сахарная свёкла, но чаще таксоны рангом ниже вида не заслуживают отдельной статьи, а в энтомологии, даже, рангом ниже рода (См. Википедия:Биологические статьи#Значимость). Таким образом, наиболее вероятно, что разновидности осок ни когда не будут описаны в отдельных статьях Википедии, а видов осок несколько сотен. Если отказаться от параметров parent и rang то для каждой статьи о виде осоки придётся создать таксономический шаблон, и эти шаблоны будут созданы только для обеспечения единственной статьи о виде. Сейчас всё множество статей о видах осок использует единственный таксономический шаблон {{Carex}}.

Я старался излагать просто, но если не понятно, спрашивайте. --Chan 07:28, 11 июня 2010 (UTC)[ответить]

Это-то как раз понятно. Но я не вижу связи с обсуждаемым. То, что каких-то статей про младшие ранги и не будет - это никак не влияет, что нужно сделать шаблоны высших рангов, т.к. хотя бы с десяток статей младшего ранга будут - так же как и с осокой. S.J. 22:36, 11 июня 2010 (UTC)[ответить]

Ну, или Вы пример дали как раз не подходящий .. S.J. 22:38, 11 июня 2010 (UTC)[ответить]

Возьмём конкретный пример Осока богемская (Carex bohemica). В Таксоне для построения иерархии используется параметр parent, который вызывает таксошаблон {{Carex}}. Если отказаться от использования параметра parent, Таксон будет вызывать таксошаблон {{Carex bohemica}}. Но нет смысла создавать {{Carex bohemica}}, лучше не отказываться от parent и не плодить объекты без которых можно прекрасно обойтись. Это вопрос идеологии, не технический.--Chan 01:09, 12 июня 2010 (UTC)[ответить]

Ок, теперь понятно .. будем думать. S.J. 01:14, 12 июня 2010 (UTC)[ответить]

Теперь приведу контр-доводы за использование только параметра latin и исключение из употребления параметра parent. Одна из главных задач шаблона Таксона, это достижение единства классификации во всех статьях о таксонах. Использование параметра latin стопроцентно отвечает этому требованию, вся систематика берётся из цепочки таксошаблонов, которая начинается с таксона, указанного в параметре latin. Использование параметра parent допускает некоторые вольности, из-за чего в отдельных статьях некоторые таксоны (особенно неосновных рангов) могут упускаться. Обычная ситуация: в статье о виде параметр parent указывает на род, вызывая соответствующий таксошаблон, от которого разворачивается цепочка род-триба-семейство-и т.д. В статье об указанном роде также задействован parent, но который указывает не на трибу, а на семейство. Расхождения минимальны, всего на один ранг. Я не знаю, стоит ли на это обращать внимание, но если подходить принципиально... Второе, если использовать только параметр latin, то для каждой статьи о таксоне будет создан таксономический шаблон, который будет именован научным латинским названием и классифицирован (категоризирован) в соответствии едиными правилами, заложенными в работу шаблона, что исключит ляпы (человеческие ошибки). Надобность в ручной категоризации статей о таксонах отпадёт окончательно. А это есть гуд:)) Вот теперь хотелось бы оценить, что чего стоит. Что важнее? Полнота и точность, или неуловимая экономия виртуального пространства + уменьшение трудозатрат при создании меньшего количества таксономических шаблонов? --Chan 14:55, 14 июня 2010 (UTC)[ответить]

• Ну на счет экономии думайте - нужно порядка 200.000 статей шаблонов из одной строчки. Мне например не жалко :) ... что касается трудозатрат - то это все можно делать ботом - т.к. если уже указан параметр parent то перейти на latin - это дело техники, в случаях обсуждавшихся выше (про Осоку). Ну, а там где ошибки (непоследовательность для упражднения промежуточных рангов) изначально - надо исправлять по любому. S.J. 15:22, 14 июня 2010 (UTC)[ответить]
  • Цифра 200.000 статей как получилась? Сейчас имеется всего около 15.000 статей об организмах. Перейти — не совсем дело техники. При существовании различных вариантов, боту надо будет принимать решение какой вариант верный. В целом я не против полного перехода на latin, но для участников, ничего не знающих и не желающих знать о шаблонах, необходимо средство создания таксошаблонов нажатием одной кнопки. --Chan 01:38, 15 июня 2010 (UTC)[ответить]
    • Это я мыслю масштабами Викивидов :) Тогда о чем тут обсуждать - тьфу ты мелочь какая :) Если серьезно - то хранение в массиве устраняет проблемы количества ... S.J. 23:12, 17 июня 2010 (UTC)[ответить]

Пока на уровне идеи, но принципиальных проблем с реализацией быть не должно. Проблема в том, что сейчас в таксо-шаблоне всего одна строчка. При новом формате можно работать с массивом строк. Помните я говорил, что {{TaxInfo}} - является по сути структурой данных. Так вот можно реализовать нечто вроде массива {{TaxArray}}. И тогда в одном шаблоне скажем можно хранить сотню другую таксо-шаблонов. При этом сам шаблон будет списком (т.е. иметь самостоятельную ценность, с разметкой близкой к табличной - только внутри шаблона) , и его может по прежнему использовать {{Таксон}}. При этом все виды будут в одном таксо-шаблоне, все отряды в другом, все классы в третьем и т.д. Таким образом, мы снимаем противоречие имеющиеся в разделе выше - создаем специальным образом отформатированный список и имеем все нужные таксо-шаблоны для классификации и используем только одну статью, или десяток при 1000 видов (алфавитный указатель). Быстро реализовать тут уже не берусь ... но ряд тестов после окончания внедрения новой структуры можно провести. S.J. 11:22, 16 июня 2010 (UTC)[ответить]

Пример массива {{Список:Carex}} - формируется ботом на основании текущих данных из карточки таксон. По сути мог бы быть заменой Виды рода Осока

С оформлением надеюсь поможете :)

Шаблон {{Array}} обеспечивает произвольный доступ к массиву (по сути аналог хэш-таблицы), например,

{{Список:Carex|1|Carex duriuscula}} - {{Список:Carex|2|Carex duriuscula}} 

если есть желание можно перейти на формат

{{Список:Carex|parent|Carex duriuscula}} - {{Список:Carex|latin|Carex duriuscula}}

дает

Шаблон:Список:Carex Шаблон:Список:Carex

Таким образом, можно ботом сформировать списки нижних таксонов, научить работать со списками {{TaxRecursion}} - и спокойно использовать только latin. Кроме того, если кому-то в дальнейшем не нравится работать со такими списками, то периодически запуская можно пополнять список, а в разрыве будет работать старая технология через parent (но это на всякий случай - лучше вообще убрать parent из Таксона). S.J. 22:44, 17 июня 2010 (UTC)[ответить]

Готов {{RecursionExt}}, позволяет рекурсивно ходить по таксо-шаблонам, даже если он хранится в режиме массива. Вызов

{{RecursionExt|5|Список:Carex|1|Carex firma}}

дает

Шаблон:RecursionExt

т.е. пятый уровень от Carex firma, хранимый в массиве Список:Carex.

• Пойду формировать на основании страниц включающих {{Таксон}}, все списки. Интересно сколько получится списков из ≈2000 страниц с шаблоном {{Таксон}} S.J. 19:55, 18 июня 2010 (UTC)[ответить]

Я думал о хранении массивов таксошаблонов, но совсем в другом ключе — о массивах ортогональных вашим. Идея весьма сырая, но в копилку закинуть можно. Мне кажется, основная проблема таксонавигации — ограничение по глубине вложенности и ресурсоёмкость. Если мы имеем шаблон {{Delphinium}}, то что нам мешает собрать всю цепочку следующих за ним шаблонов на подстранице/подшаблоне {{Delphinium/Path}}. И так для всех таксошаблонов, хотя для всех вовсе не обязательно. Работа тупая, для бота в самый раз. Самое сложное, это организовать своевременное обновление нижележащих подшаблонов, если в каком либо появятся изменения. Для этого надо научиться ходить по таксошаблонам сверху вниз по иерархии. Зато при выводе классификации обращаясь к какому либо таксошаблону мы проверяем, есть ли подшаблон с окончанием /Path, при наличии выводим его и перескакиваем с последнего в списке на parent последнего. Дополнительно в подшаблоне, можно хранит сведения о его актуальности и о сестринских таксошаблонах. Внимание! Речь не о всех шаблонах одного ранга, а только о родных сёстрах.

Для наглядности я собрал такой подтаксошаблон, но формат его может быть совсем иным. Идею стоит/нужно развивать? --Chan 15:00, 17 июня 2010 (UTC)[ответить]

К сожалению, такой набор данных не годится для хранения в одном месте. Если по научному :) то не обеспечивается третья нормальная форма, т.к. это дерево, если по проще - то приводит к многократному дублированию. Собственно поэтому плох шаблон {{Taxobox}} с технической точки зрения, и это ощущается пользователями. В этом направлении нам идти не нужно, иначе потеряется сам смысл {{Таксон}}. S.J. 23:07, 17 июня 2010 (UTC)[ответить]

Приведённый выше список {{Delphinium/Path}}, это только эскиз, формат которого конечно должен быть иным, и он приводится к третьей нормальной форме очень просто, не сложнее чем собирается. Смысл шаблона не теряется, если с шаблонами типа {{Delphinium/Path}} пользователь не взаимодействует на прямую, а они используются только как оснастка комплекса средств обеспечения таксономической навигации. --Chan 05:05, 18 июня 2010 (UTC) (я не программист, но про третью нормальную форму и триггеры знаю)[ответить]

С другой стороны, желание конечно понятно - и если бы у нас был сервер базы данных, то это был бы неплохой механизм кэширования данных, с обновлением по триггеру (не загрузил? я просто не знаю вы программист или нет ? ) но у нас не это ... бот в этом месте плохая замена - если мы не можем обеспечить это стабильно в любое время - то нету смысла нагружать шаблоны которые это отображают - т.к. им придется работать с двумя вариантами в момент наличия полного списка с ним, как только что-то сменилось (что-то же у нас не возможности зафиксировать) по старому, пока бот не пройдет. S.J. 23:07, 17 июня 2010 (UTC)[ответить]

Да, я сразу говорил, что это слабое место. Думаю, вы правы, средств обеспечить стабильное и своевременное обновление данных у нас здесь нет. --Chan 05:05, 18 июня 2010 (UTC)[ответить]

Но, на Викивидах таксономическая навигация это один из ключевых моментов. Можно сказать, хребет всего проекта. Вот там раскрутиться на подобную роскошь можно. Было бы желание.--Chan 08:51, 18 июня 2010 (UTC)[ответить]

Но в какой нибудь мере, это можно комбинировать с подходом выше. Представим в идеальном случае у нас фрагмент дерева, разбит по рангам - т.е. дерево хранится в скажем 20 статьях, список классов, отрядов, семейств, родов, видов. Теперь у нас дерево не однородное, может быть вырождено. Например монотипные ранги, или имеющие всего 2-3 подузла, в которых опять же немного узлов. Так вот такие вырожденные деревья имеет смысл хранить в одном списке-массиве ... и тогда решится вопрос с иерархией частично, на промежутке вырожденного дерева. Но это работа не для бота - сильно уж интеллектуально (не очень, но все же лучше чтобы решение принимал человек) ... Но скажу сразу - это все же отдаленное будущие .. хотя вполне подъемное. S.J. 23:07, 17 июня 2010 (UTC)[ответить]

В подход №1 мне надо ещё вникнуть. Намечаются некоторые вопросы/предложения, но их надо ещё формулировать. --Chan 05:05, 18 июня 2010 (UTC)[ответить]