stringtranslate.com

Discusión de plantilla:Taxonbar

{{ Taxonbar }} (editar discusión historial enlaces # /subpages /doc  /doc edit /sbox  /sbox diff /test )

Taxonbar para móviles

Este tema ha aparecido en varias ocasiones, la más reciente en WT:Automated_taxobox_system#Automatic links tospecies, commons, data . Taxonbar usa Navbox y por alguna razón está deshabilitado en dispositivos móviles. Todo lo que se usa class="navbox"se elimina del lado del servidor, aunque los estilos de plantilla aún están en la página.

El año pasado hice algunos experimentos sobre salidas alternativas para la información de taxonbar, omitiendo Navbox y también usando taxonbar para generar enlaces de sitio. Restauré estas opciones en Module:Taxonbar/sandbox y coloqué los ejemplos en User:Jts1882/taxonbar . Estaba tratando de averiguar qué funciona en dispositivos móviles y qué no y, sorprendentemente, todas las opciones contraíbles funcionaron. Más sorprendente aún fue que las taxonbars funcionaron (desde entonces he visto que la documentación de taxonbar y los casos de prueba muestran taxonbars en dispositivos móviles). Navbox solo está bloqueado en el espacio principal, no en la plantilla del espacio de usuario.

De todos modos, el motivo de este tema es que he creado un prototipo de salida en estilo Navbox que funciona en dispositivos móviles:



Para probarlo en un dispositivo móvil, puedes copiar el código anterior y obtener una vista previa en la página Indian_flying_frog .

No estoy seguro de si esto debería implementarse. Hay una razón por la que Navbox está bloqueado y esto podría considerarse un intento de eludir una política de Wikipedia. Mi sospecha es que los grandes Navboxes anidados son el problema y una tabla pequeña y simple como la de taxonbar no causa los mismos problemas. —  Jts1882  |  discusión 12:25, 25 de abril de 2024 (UTC) [ responder ]  

¡Se ve bien! ¿A quién podemos preguntar sobre el posible problema de política? - UtherSRG (discusión) 12:44 25 abr 2024 (UTC) [ responder ]
No estoy seguro.
He investigado un poco y he encontrado T124168. Las principales objeciones son que utilizan tablas HTML anidadas de gran tamaño, que supuestamente no se muestran tan bien en dispositivos móviles, y tienen tamaños de descarga grandes. Mi versión móvil utiliza una tabla con dos columnas, por lo que probablemente no sea el tipo de cuadro de navegación que provocó la prohibición.
Una mejor solución es crear una <div>salida basada en la base. El problema aquí es alinear la columna de la izquierda sin usar un ancho fijo y colocar los elementos flotantes correctamente. Encontré un método más ordenado display:gridque implementé usando templatestyles.
  • Barra de taxones compatible con dispositivos móviles (usando cuadrícula y divs):{{Taxonbar/sandbox|from=Q11847339|from2=Q593398|format=grid-taxonbar}}
Pterosaurio
Pterosaurio khare
  • Barra de taxones estándar para comparación:{{Taxonbar|from=Q11847339|from2=Q593398}}
Un problema aquí es la compatibilidad con versiones anteriores. Grid es compatible con todos los navegadores, pero no sé por cuánto tiempo. Wikipedia quiere que todo siga siendo compatible con el ábaco, excepto Vector-2022, al que se le permite romper todo.
De todos modos, creo que he visto suficiente para pensar que podemos convertir la barra de taxones en una solución que no sea navbox y que se pueda ver en dispositivos móviles. —  Jts1882  |  discusión 16:57, 25 de abril de 2024 (UTC) [ responder ]  

El uso del "tipo nomenclatural de" está mal visto

@ Jts1882 y Tom.Reding : (o cualquiera...) Me están diciendo en mi charla en WD que nuestro uso del tipo de nomenclatura (Q116044186) es incorrecto. No estoy seguro de si están diciendo que deberíamos usar el tipo de nomenclatura (Q116538381) o hacer otra cosa. ¿Pueden intervenir y ayudar a aclarar esto? - UtherSRG (discusión) 16:44 30 abr 2024 (UTC) [ responder ]

@ UtherSRG : , si bien no estoy seguro exactamente de qué es un elemento de etiqueta de propiedad inversa (Q65932995) o cómo se debe utilizar, observo que es un elemento de Wikidata (Q), no una propiedad de Wikidata (P). Una relación inversa que entiendo mejor es producto natural de taxón (P1582) y este taxón es fuente de (P1672); ambas son propiedades. d:User:ChristianKl/Out of scope use of labels muestra 196 instancias de "tipo nomenclatural de", y hay 200 páginas vinculadas al elemento; una es su página de discusión, una es la página Fuera de alcance de ChristianKL y un tipo taxonómico (P427). Eso deja una página de taxón que no está en la página Fuera de alcance (¿y presumiblemente está "dentro del alcance"?) pero no sé cuál es. De las instancias de Q116044186 que he revisado, no he encontrado ninguna que no haya sido agregada por usted.
No estoy seguro de lo que intentas lograr. Si se trata de permitir que las barras de taxones recojan automáticamente varios elementos de Wikidata relacionados con la monotipia, aún existe el problema que mencioné en un hilo ahora archivado sobre géneros monotípicos donde la especie tipo es un sinónimo de la única especie aceptada. Esa es una situación poco común, pero sucede.
El taxón monotípico (Q310890) es problemático; el hecho de que un taxón sea monotípico o no puede variar entre diferentes puntos de vista taxonómicos. Se supone que Wikidata representa los diferentes puntos de vista taxonómicos por igual.
No estoy seguro de que sea realmente factible que las barras de taxones recojan varios elementos de Wikidata relacionados con la monotipia. Plantdrew ( discusión ) 19:18 30 abr 2024 (UTC) [ responder ]
El trabajo que realicé fue en apoyo de la codificación de taxonbar existente, con el fin de ayudar a categorizar el uso de manera adecuada, por lo tanto, para determinar si los QID que se proporcionan al taxonbar son un emparejamiento monotípico. Lo hice siguiendo el consejo de Jts1882 (si no recuerdo mal) cuando pregunté sobre trabajar para resolver algunos de los problemas en Category:Taxonbar cleanup y Category:Taxobox cleanup . Si lo que estoy haciendo no es la solución correcta, ¿cuál es? Y el taxonbar necesitará que se cambie su código para adaptarse. - UtherSRG (discusión) 23:57, 30 de abril de 2024 (UTC) [ responder ]
Si mal no recuerdo, sugerí que podríamos usar la especie tipo para obtener la especie hija de un género monotípico y Tom.Reding lo implementó. Al observar el código, recupera el tipo taxonómico (P427) para géneros monotípicos y verifica si es un taxón monotípico (Q310890) o un taxón fósil monotípico (Q47487597), en cuyo caso se acepta. No veo un uso del tipo nomenclatural (Q116044186) o del tipo nomenclatural (Q116538381), por lo que no entiendo de qué se trata el problema. —  Jts1882  |  discusión 06:51, 1 de mayo de 2024 (UTC) [ responder ]  
No creo que comprobar la monotipia de una especie tipo putativa sea el enfoque correcto para comprobar la validez. El tipo no necesita ser monotípico. No estoy seguro de qué comprobar, ya que los ejemplos de tipo taxonómico (P427) incluyen un espécimen tipo. Tal vez sea mejor comprobar que el elemento sea un nombre de taxón y que tenga el género monotípico como padre. —  Jts1882  |  discusión 08:46, 1 de mayo de 2024 (UTC) [ responder ]  
Nadie respondió a esto, pero creo que comprobar que el género monotípico tiene un tipo taxonómico (P427) que es un nombre de taxón y tiene un progenitor que coincide con el género monotípico detectará algunas especies de géneros monotípicos. No lo hará cuando haya nuevas combinaciones. —  Jts1882  |  discusión 13:35, 3 de mayo de 2024 (UTC) [ responder ]  
@ Tom.Reding : Esta es mi sugerencia. —  Jts1882  |  discusión 14:23, 3 de mayo de 2024 (UTC) [ responder ]  
Volviendo a la publicación de Plantdrew anterior, estoy de acuerdo en que no deberíamos usar un taxón monotípico (Q310890) para determinar si un taxón es monotípico o no, debido a la neutralidad de Wikidata en cuanto a las opiniones taxonómicas. Los agrupadores, como PoWO para helechos, tendrán muchos menos taxones monotípicos que los separadores. Tenemos que decidir de una forma u otra por el título del artículo y el taxobox, pero Wikidata no lo hace y no debería hacerlo. Peter coxhead ( discusión ) 07:07 1 may 2024 (UTC) [ responder ]
El taxonbar está buscando tratamientos alternativos, por lo que esto podría no ser un problema. —  Jts1882  |  discusión 08:46, 1 de mayo de 2024 (UTC) [ responder ]  
Esto se refiere a cómo completar estas categorías de seguimiento:
Pero quizás no tenemos las categorías de seguimiento adecuadas. He estado asumiendo que las tenemos, ya que esto se configuró por una razón, pero no sé si las tenemos. Dado el desequilibrio de la población de las categorías, probablemente no las tengamos. Jts1882 tienes razón en tu evaluación de que no estamos usando los campos "nomenclaturales" en WD... pero nuestra discusión fue que necesitábamos un método para anotar ambos lados de la relación monotípica padre-hijo, pero luego no se implementó, si no recuerdo mal, a pesar de que ya había estado actualizando WD con él. No recuerdo en qué página de discusión archivada se discutió, pero el pasado es el pasado y debemos mirar hacia el futuro.
Si no queremos rastrear la monotipia, entonces simplemente eliminemos estas cuatro categorías, eliminemos el código que las llena y desharé los ~200 usos de "tipo de nomenclatura de" en WD que agregué.
Suponiendo, entonces, que queremos rastrear "algo" sobre la monotipia, ¿qué hacemos? Necesitamos una manera de detectar una monotipia, y necesitamos determinar si los QID que tenemos a mano se alinean con esa monotipia. Por un lado, tenemos uno o más QID listados en la taxonbar. ¿La información en Wikidata para estos QID indica que tenemos una monotipia, y la colección de QID en la taxonbar incluye tanto el padre como el hijo de la monotipia? Por otro lado, actualmente no tenemos manera de indicar en la taxonbar que tenemos una monotipia a priori . Esto puede ser algo que queremos abordar.
Para abordar directamente el problema de Peter Coxhead , si bien tiene razón desde la perspectiva del artículo y el taxobox , no creo que sea un problema desde el punto de vista de la taxobarra . Tenemos que elegir una única taxonomía para el artículo y el taxobox , pero la taxobarra puede incluir múltiples combinaciones y, por lo tanto, ser neutral en cuanto a las opiniones taxonómicas. Esto nos permite utilizar por completo la variedad de taxonomías registradas en Wikidata.
Sea como fuere, continuemos con el supuesto y las categorías de seguimiento existentes dadas, y determinemos el algoritmo correcto para completarlas, y qué campos/propiedades de WD usar para hacer esto, sin afectar a WD.
Recorrer en bucle la colección QID
  • Si el QID (padre) indica que es monotípico (taxón monotípico o taxón fósil monotípico) (y si aún no hemos comprobado este QID a partir de la relación hijo->padre)
    • Si el tipo taxonómico del padre (hijo) indica que es el tipo del padre (¿cómo? ¿el sujeto tiene rol -> tipo nomenclatural -> padre? ¿Algo más/nuevo?)
      • Tenemos una monotipia confirmada padre->hijo
      • Si el niño no está en nuestra colección actual, agregue la categoría "niño faltante" (o sea audaz y agregue al niño a nuestra colección y agregue la categoría "niño agregado automáticamente") [A]
  • Si QID (hijo) indica que es el tipo de algún padre (¿ve cómo? arriba) (y si aún no hemos verificado este QID desde la relación padre->hijo)
    • Si el padre indica que es monotípico (taxón monotípico o taxón fósil monotípico)
      • Tenemos una monotipia confirmada hijo<-padre
      • Si el padre no está en nuestra colección actual, agregue la categoría "padre faltante" (o sea audaz y agregue al hijo a nuestra colección y agregue la categoría "padre agregado automáticamente") [B]
En cuanto a la pregunta "cómo", si "tipo nomenclatural de" no es la forma correcta, ¿qué podemos usar? ¿Cambiar de tipo nomenclatural de (Q116044186) a tipo nomenclatural (Q116538381)? ¿Agregar una nueva propiedad que sea la inversa del tipo taxonómico (P427)? ¿Algo más? Creo que necesitamos la opinión de alguien familiarizado con las expectativas del lado de WD como d:User:ChristianKl (y le he informado que estamos teniendo esta discusión y le he pedido que le eche un vistazo aquí).
Si queremos indicar a priori que tenemos una monotipia, sugiero agregar nuevos campos a la barra de taxones de alguna manera como esta: |monotypic_parentN=xy |monotypic_childN=xdonde N es un número (podemos tener múltiples taxones monotípicos en un artículo, por lo que N número de relaciones padre/hijo) y x indica qué fromNcampo cumple esta función. Por ejemplo: {{Taxonbar|from1=Q123|from2=Q456|monotypic_parent1=1|monotypic_child1=2}}indicaría que from1 y from2 forman una monotipia, donde from1 es el padre y from2 es el hijo.
Teniendo en cuenta lo anterior, también sugeriría lo siguiente:
  1. El algoritmo anterior, al detectar que existe una monotipia en WD, pero no tenemos ninguna indicación a priori , agrega una (nueva) categoría "campos de monotipia faltantes para emparejamiento monotípico". [C] Esto puede ser además de un padre/hijo faltante, si nos falta un QID en la barra de taxones.
  2. El algoritmo anterior, cuando no detecta una monotipia en WD, pero tenemos una indicación a priori , agrega la (nueva) categoría "la monotipia necesita un elemento Wikidata adicional".
Finalmente, ¿qué pasa con el conjunto de categorías con el que empecé? Ahora estoy seguro de que no es el mejor conjunto y que podemos hacerlo mejor. No creo que nos interesen específicamente los géneros monotípicos, sino que nos interesen los taxones monotípicos en general. (Sí, juego de palabras intencionado con "específicamente" y "en general"). ¿Por qué querríamos hacer un seguimiento de los géneros monotípicos y no de otros taxones monotípicos? Si utilizamos los diversos cambios que sugiero en esta publicación, creo que el siguiente es un mejor conjunto de categorías de seguimiento:
  • Categoría:Taxonbars de padre monotípico sin hijo monotípico o Categoría:Taxonbars con hijo monotípico añadido automáticamente (uno u otro de [A])
  • Categoría:Taxonbars de hijo monotípico sin padre o Categoría:Taxonbars con hijo de taxón monotípico agregado automáticamente (uno u otro de [B])
  • Categoría:Taxonbars sin campos de monotipia (de [C])
  • Categoría:Páginas de taxones que requieren un elemento monotípico de Wikidata (de [D])
Si analizamos la Categoría:Limpieza de barras taxonómicas y cómo se ordenan las subcategorías, diría que [A] y [B] serían de tipo "T", [C] de tipo "M" y [D] de tipo "E". También creo que debemos revisar las subcategorías restantes de la Categoría:Limpieza de barras taxonómicas para ver si las necesitamos o no y si están ordenadas correctamente, pero ese es un tema para otra discusión. - UtherSRG (discusión) 12:09 1 may 2024 (UTC) [ responder ]
El mayor obstáculo es pasar de padre -> hijo en Wikidata. Si el tipo taxonómico (P427) no es apropiado para este propósito, entonces deberíamos intentar resucitar d:Wikidata:Property proposal/child monotypic taxon de hace 6 años. Obviamente, existe una necesidad para ello, o algo parecido. Si eso no se puede/no se quiere hacer, entonces probablemente deberíamos abandonar este esfuerzo de encontrar/rastrear monotipos. Creo que es en el mejor interés de Wikidata y todas las Wikipedias que exista tal propiedad, y sería tonto/perezoso no tenerla.    ~  Tom.Reding ( discusión ⋅ dgaf )   14:24, 1 de mayo de 2024 (UTC) [ responder ]
El tipo taxonómico (P427) no es apropiado para este propósito. Para Psilurus , el tipo es Psilurus nardoides , que es un sinónimo de la única especie aceptada, Psilurus incurvus . Otro problema es que según el ICZN: "Recomendación 67B. Cita de especies tipo. El nombre de una especie tipo debe citarse por su binomio original" (los botánicos también lo hacen). El ICZN da el ejemplo de Astacus marinus como el tipo de Homarus , que es lo que muestra el artículo de Wikipedia. Pero Wikipedia es inconsistente al seguir esa práctica. No he prestado suficiente atención a las declaraciones de especies tipo de Wikidata para saber si Wikidata es consistente, pero sospecho que no lo es. El tipo que es un sinónimo es una situación poco común. El tipo que es un binomio original es más común. Plantdrew ( discusión ) 16:33, 1 de mayo de 2024 (UTC) [ responder ]
Hrm. Este es un muy buen punto. Si a eso le sumamos el punto de Tom anterior sobre el intento anterior de una propiedad de "taxón monotípico hijo", creo que debemos comenzar con un nuevo par de propiedades, aunque podría ser posible resucitar la propuesta y agregar una propiedad de "taxón monotípico padre". Hrm... - UtherSRG (discusión) 16:52 1 may 2024 (UTC) [ responder ]
No es la primera vez que planteo un problema. Tenemos un montón de discusiones y luego no pasa nada, y me pongo a trabajar en otro tema porque las cosas quedaron en el aire. No quiero repetir eso. Entonces... ¿vamos a hacer algo aquí? - UtherSRG (discusión) 13:09 3 may 2024 (UTC) [ responder ]
Si no queremos seguir adelante con la búsqueda de una forma de rastrear la monotipia, entonces eliminemos ese seguimiento de la barra de taxones y eliminemos esas cuatro categorías. - UtherSRG (discusión) 13:11 3 may 2024 (UTC) [ responder ]
He retomado una sugerencia que hice antes y que fue ignorada (o descartada como basura). Creo que podría captar algunas especies de géneros monotípicos. —  Jts1882  |  discusión 13:37, 3 de mayo de 2024 (UTC) [ responder ]  
Plantdrew rechazó esa idea, porque el tipo taxonómico de una especie puede no pertenecer al género, si la especie se traslada de un género a otro nuevo. (Aunque apuesto a que la mayoría de las veces se utiliza la nueva combinación en el campo P427 cuando no debería ser así). - UtherSRG (discusión) 14:22 3 may 2024 (UTC) [ responder ]
¿Cuál es esa sugerencia y cómo se compara con las posibles propiedades de Wikidata de "taxón monotípico hijo" + "taxón monotípico padre"? Admito que no he estado siguiendo completamente todas las discusiones...    ~  Tom.Reding ( discusión ⋅ dgaf ) 
(Usaste tres tildes... así que respondiste manualmente) Respondió bastante arriba para sugerir usar P427 de una manera diferente. verificar que el género monotípico tiene un tipo taxonómico (P427) que es un nombre de taxón y tiene un padre que coincide con el género monotípico detectará algunas especies de géneros monotípicos. No lo hará cuando haya nuevas combinaciones. - UtherSRG (discusión) 14:23 3 may 2024 (UTC) [ responder ]
Sí, se detectarán algunas, pero no las suficientes para detectar todas. Esto solo debería detectar monotipos en los que una especie recién descrita y su género se describen al mismo tiempo, no cuando se describe un género nuevo a partir de una especie antigua. Necesitamos una solución para ambos tipos. - UtherSRG (discusión) 14:25 3 may 2024 (UTC) [ responder ]
Mi prueba para el taxón original garantizaría que el género coincida. —  Jts1882  |  discusión 14:53, 3 de mayo de 2024 (UTC) [ responder ]  
¿Estamos todos de acuerdo en que d:Wikidata:Property proposal/child monotypic taxon debería volver a enviarse, junto con un d:Wikidata:Property proposal/parent monotypic taxon que se está redactando? Me gustaría ver una muestra de apoyo contundente antes de que se vuelvan a enviar.    ~  Tom.Reding ( discusión ⋅ dgaf )   14:29 3 may 2024 (UTC) [ responder ]
Para los taxones que son a la vez hijos y padres en una monotipia (por ejemplo, una familia que tiene una sola especie), ¿se utilizarían ambas propiedades? - UtherSRG (discusión) 14:31 3 may 2024 (UTC) [ responder ]
Sí, el género debería tener ambos, lo que haría muy fácil subir o bajar en la línea del monotipo.    ~  Tom.Reding ( discusión ⋅ dgaf )   14:39 3 may 2024 (UTC) [ responder ]
Genial. Entonces sí, estoy a favor de volver a enviar y de que se redacte la propiedad principal. Deberían enviarse juntos para que se puedan discutir como un par. Creo que entonces podríamos argumentar que tanto el taxón monotípico (Q310890) como el equivalente fósil pueden ser archivados por no ser relevantes y todos los usos reemplazados por simplemente "taxón". UtherSRG (discusión) 14:45 3 may 2024 (UTC) [ responder ]
El taxón monotípico (Q310890) no es una propiedad, por lo que su funcionalidad es diferente y aún así útil, p. ej., instancia de (P31) -> taxón monotípico (Q310890). Su descripción se modificaría para permitir su uso en padres o hijos, en lugar de solo en padres.    ~  Tom.Reding ( discusión ⋅ dgaf )   15:02 3 may 2024 (UTC) [ responder ]
Lo estaba usando de esa manera y me criticaron duramente por hacerlo. No lo aceptarán. - UtherSRG (discusión) 16:06 3 may 2024 (UTC) [ responder ]
¿Puedes incluir un enlace a esa/esas discusiones? Hay 10.749 instancias de (P31) -> taxón monotípico (Q310890), por lo que, a menos que hayas incluido la mayoría de ellas, ese es definitivamente uno de los casos de uso válidos. De todas formas, esto es algo que se debe discutir después de las propuestas.    ~  Tom.Reding ( discusión ⋅ dgaf )   15:08, 4 de mayo de 2024 (UTC) [ responder ]
Me criticaron por usar un taxón monotípico (Q310890) en especies de padres monotípicos, primero en la discusión de un artículo, luego en su tablero AN. - UtherSRG (discusión) 17:23 4 may 2024 (UTC) [ responder ]
Permítanme explicar lo que entiendo que se está proponiendo. La propiedad de taxón monotípico hijo se agregaría a los elementos de taxón monotípico y especificaría el taxón hijo único (es decir, es un "taxón hijo de la propiedad de taxón monotípico"). La propiedad de taxón monotípico padre se agregaría al elemento de taxón hijo único para indicar que el padre es monotípico. Tal vez debería diseñarse para que sea un calificador del taxón padre, es decir, una "propiedad de es monotípico". Alternativamente, un taxón padre podría calificarse con una instancia de (P31) con el taxón monotípico (Q310890) utilizando propiedades existentes (si esto está permitido). —  Jts1882  |  discusión 16:10, 3 de mayo de 2024 (UTC) [ responder ]  
Las propiedades "taxón monotípico padre" y "taxón monotípico hijo" en este caso significan "tiene taxón monotípico padre" y "tiene taxón monotípico hijo" (a diferencia de "ES taxón monotípico padre/hijo"), de acuerdo con el uso de la propiedad de taxón padre (P171) existente.
Usaré el ejemplo de Uther, ya que cubre todas las permutaciones, donde una familia monotípica tiene una especie singular. El elemento de la familia tendría la propiedad "taxón monotípico hijo" apuntando al género. El género tendría "taxón monotípico padre" apuntando a la familia, y tendría "taxón monotípico hijo" apuntando a la especie. Y la especie tendría "taxón monotípico padre" apuntando al género.    ~  Tom.Reding ( discusión ⋅ dgaf )   15:08 4 may 2024 (UTC) [ responder ]
@ Jts1882 : ¿Qué opinas?    ~  Tom.Reding ( discusión ⋅ dgaf )   14:44 9 may 2024 (UTC) [ responder ]
Vale la pena intentarlo. Si bien una propiedad de taxón hijo sería una valiosa adición, eso es imposible mientras los elementos de Wikdata sean híbridos de taxón y nombre de taxón. El mismo elemento se usa a menudo para diferentes circunscripciones del nombre del taxón con diferentes conjuntos de hijos (por ejemplo, consulte giraffe (Q15083)). Sin embargo, los taxones monotípicos no sufren el mismo problema; si el taxón es monotípico, el taxón hijo es fijo (incluso si el nombre puede cambiar). Y una propiedad correspondiente para la relación padre-hijo también tiene sentido, aunque permitir la instancia de taxón monotípico como calificador en el taxón padre es una alternativa. —  Jts1882  |  discusión 14:58, 9 de mayo de 2024 (UTC) [ responder ]  

@ Jts1882 : Sigo preocupado por la neutralidad de Wikidata en materia de taxonomía. Solo para tomar un ejemplo en el que he estado trabajando recientemente, según algunas fuentes, Chrysogonum es monotípico con una especie, Chrysogonum virginianum , como decía esta versión del artículo. Pero otras fuentes tienen de 1 a 3 especies norteamericanas y en el caso de PoWO otras 4 especies malgaches. El elemento de Wikidata debería permitir que el nombre del taxón se declare tanto monotípico según las fuentes dadas como no monotípico según otras, así como permite que un nombre de taxón tenga múltiples taxones parentales. Peter coxhead ( discusión ) 10:24, 10 de mayo de 2024 (UTC) [ responder ]

@ Peter coxhead : Si la propiedad "taxón X monotípico" tuviera tanto un subcampo de "referencias" (es decir, apoyo para esta taxonomía) como un subcampo de "refutado por" (es decir, apoyo para una taxonomía no monotípica), ¿eso aliviaría sus preocupaciones? (Podemos discutir sobre los nombres de los subcampos, pero el concepto es lo que espero que se alinee con usted). - UtherSRG (discusión) 13:04, 10 de mayo de 2024 (UTC):Una alternativa a eso es agregar una tercera propiedad a nuestra propuesta: "taxón hijo". Para los taxones que son los padres en una monotipia, usarían "taxón hijo monotípico". Para los taxones que son los padres en una politipia, usarían "taxón hijo" con múltiples hijos. Para los taxones que se enumeran a veces como un padre monotípico y, a veces, como un padre politípico, usarían ambos. (De la misma manera, los taxones hijos usarían "taxón padre" si tienen taxones hermanos, "taxón padre monotípico" si no tienen taxones hermanos, y ambos si están incluidos en taxonomías mono- y politípicas conflictivas). - UtherSRG (discusión) 13:10 10 may 2024 (UTC) [ responder ]
@ UtherSRG : Definitivamente, se necesitaría un subcampo de referencias (como los hay para otras propiedades); el negativo no es necesario porque está implícito en la referencia para cualquier alternativa. Pero la cuestión entonces es si es posible utilizar la información aquí, en taxonbars, etc., porque sería necesario saber qué alternativa estamos siguiendo. (Es paralelo a la objeción que surge cuando de vez en cuando se propone que utilicemos Wikidata en lugar de plantillas de taxonomía. Las plantillas de taxonomía tienen que formar árboles; las instancias de taxón de Wikidata, no).
También vale la pena señalar que intentar rastrear la monotipia plantea problemas de mantenimiento. En mi experiencia aquí, los géneros monotípicos regularmente se vuelven no monotípicos. Por ejemplo, Mexerion , que noté anteriormente, se dice que en esta versión es monotípico, pero según Tropicos Nesom agregó otra especie en 2023. Entonces, dado que Mexerion stolonatum es un nombre de taxón válido, necesita un elemento de taxón en Wikidata, lo que requeriría un cambio a Mexerion (Q6825725) si esto incluyera taxones secundarios. No estoy seguro de si un bot podría lidiar con esto debido a la complejidad de las vistas múltiples:
  • Lista mundial de compuestas 2014, flora mundial en línea en este momento: Mexerion es monotípica
  • PoWO en este momento: Mexerion tiene 2 spp.
  • Trópicos en la actualidad: Mexerion tiene 3 especies (según Nesom (2023))
Peter coxhead ( discusión ) 07:02 11 may 2024 (UTC) [ responder ]

Sinónimos y enlaces lingüísticos

En algunas ediciones recientes de Gerbe's vole ‎ , moví el enlace en-lang del elemento de sinónimos de Wikidata al elemento de Wikidata que coincide con el mejor nombre científico actual para esta especie. Sin embargo, la gran mayoría de las wikis de otros idiomas están listadas en ese sinónimo. Hacer esto elimina todos esos enlaces de idioma de nuestro artículo. Sé que esto no es un problema con la barra taxonómica en sí, pero me topé con él al actualizar los campos de la barra taxonómica. ¿Dónde puedo plantear este problema para que personas con más conocimientos que yo puedan elaborar una solución (que puede o no involucrar el código del módulo de la barra taxonómica)?

Mis ideas sobre lo que creo que debería ser la solución deberían ser algo similar a cómo la barra de taxones decide qué taxones mostrar: la barra lateral debería revisar de arriba a abajo los posibles indicadores de sinónimos del elemento de Wikidata para reunir todos los posibles enlaces de idiomas. (Por ejemplo, si el elemento de Wikidata tiene un campo "basiónimo", debería incluir los enlaces de idiomas de ese elemento en la lista de enlaces para mostrar). - UtherSRG (discusión) 11:35, 15 de agosto de 2024 (UTC) [ responder ]

El topillo de Gerbe es un caso muy inusual. Microtus pyrenaicus / Arvicola pyrenaicus está catalogado como nomen dubium en ITIS y MSW3, y la UICN tiene una nota que dice que hay un debate sobre si pyrenaicus o gerbei es el nombre apropiado (la página de la UICN indica MDD como fuente taxonómica a mayo de 2022 y utiliza la ortografía gerbii , por lo que aparentemente MDD ha cambiado en los últimos dos años). pyrenaicus claramente tiene prioridad si no es un nomen dubium.
Sin duda, se trata más de un problema de Wikidata que de un problema de Taxonbar. El procedimiento de Wikidata ha sido el de tener todos los enlaces entre idiomas en un único elemento y, hasta donde yo sé, no ha habido más debates sobre cómo manejar las cosas desde que Wikidata comenzó a permitir enlaces a redirecciones.
El caso más típico de enlaces interwiki a diferentes nombres científicos es cuando las distintas ediciones de Wikipedia tratan las mismas especies en géneros diferentes. Las diferencias en la forma en que las ediciones de Wikipedia agrupan o dividen las especies no se gestionan bien poniendo todos los enlaces en un único elemento, y no creo que sea una práctica habitual en Wikidata. Las diferencias en el epíteto de especie que se utiliza para lo que es claramente el mismo taxón no es un escenario lo suficientemente común como para que espere que Wikidata tenga un procedimiento bien desarrollado para tratarlo.
He vinculado el elemento de Wikidata para Microtus gerbei a la redirección Microtus gerbei . Esto permite que las personas que leen ediciones de Wikipedia que no están en inglés puedan acceder al artículo en inglés. Si bien las Wikipedias en inglés no siempre son los artículos mejor desarrollados en cualquier idioma, a menudo lo son. Sospecho que más personas que están leyendo un artículo de Wikipedia querrán pasar de una versión que no está en inglés a la versión en inglés que las que querrán pasar de una versión en inglés a una versión que no está en inglés. Plantdrew ( discusión ) 15:48, 15 de agosto de 2024 (UTC) [ responder ]
El tema no es el ratón de Gerbe, sino cómo conseguir que los enlaces interwiki de un sinónimo aparezcan en el sideboard del artículo. El género Astur ha resucitado y artículos como Gavilán negro ya no tienen enlaces interwiki, incluidas especies y bienes comunes, en el sideboard, porque el antiguo elemento de taxones de Wikidata los tiene y no es apropiado moverlos al nuevo elemento de Wikidata hasta que se actualicen todos esos sitios de otros idiomas y sitios hermanos. Y sí, sé que no es un problema de taxonbar. Ya lo dije: Sé que no es un problema de taxonbar en sí , pero eso no significa que no encuentre a algunas de las personas adecuadas aquí para pensar en una solución, o que me indiquen un lugar mejor. El ratón de Gerbe no fue la primera vez que ocurrió, solo fue donde pensé por primera vez en plantear el tema. Astur no será la última vez que ocurra. Aunque estoy de acuerdo en que, en general, el artículo en inglés es el mejor escrito, no siempre es así, y las categorías de especies y comunes son incomparables. Como mínimo, esto debería solucionarse de alguna manera para incluir la información de especies y CC en el sideboard, y la solución también debería proporcionar una solución en otro idioma. - UtherSRG (discusión) 12:09, 23 de agosto de 2024 (UTC) [ responder ]
@ UtherSRG : hasta donde sé, los editores no pueden acceder ni modificar la barra lateral izquierda, por lo que tendrías que plantear un problema a nivel de MediaWiki. Sin embargo, dudo que tenga sentido hacer un cambio para recopilar enlaces de idiomas a sinónimos de taxones . Tal vez a todas las redirecciones, ahora que Wikidata permite conexiones a redirecciones. Peter coxhead ( discusión ) 06:35, 24 de agosto de 2024 (UTC) [ responder ]
Debería ser posible cambiar la barra lateral usando un script, pero esto sería opcional y no estaría disponible para todos.
Varias especies de Tachyspiza tendrán el mismo problema (por ejemplo, el gavilán de Levante ). O MediaWiki cambia el requisito de una relación uno a uno para los enlaces de sitio o Wikidata cambia su taxonomía y permite más de un nombre de taxón para un "taxón" como el gavilán de Levante. —  Jts1882 | discusión 13:47, 24 de agosto de 2024 (UTC) [ responder ]  
El problema de Wikidata sigue siendo el descrito en user:Peter coxhead/Wikidata issues#Confusión entre taxones y nombres de taxones , es decir, que para configurar enlaces de sitio de la forma que desea UtherSRG es necesario modelar taxones en lugar de nombres de taxones. Sospecho que esto no es posible dentro de Wikidata manteniendo al mismo tiempo la neutralidad requerida entre las diferentes opiniones taxonómicas cuando estas son adoptadas por wikis de diferentes idiomas. Ciertamente, nadie ha demostrado aún cómo hacerlo.
Si nuestro artículo está conectado en Wikidata a una redirección en la wiki de otro idioma, sería fácil para el software de MediaWiki mostrar un enlace a esa redirección o incluso al artículo de destino, en lugar de ignorar las redirecciones como ocurre ahora. Esto no resolvería por completo el problema porque la wiki del otro idioma puede no tener una redirección a la que conectarse a través de Wikidata, pero ayudaría. Peter coxhead ( discusión ) 20:36 24 ago 2024 (UTC) [ responder ]
El problema es que los elementos de Wikidata no se corresponden completamente con los taxones o los nombres de los taxones, sino que son más bien híbridos. El nombre de un taxón no se puede utilizar más de una vez para diferentes tratamientos, lo que sería el caso si cada elemento se ocupara de un taxón. Sin embargo, los nombres de los taxones no tienen relaciones padre-hijo ni distribuciones ni estados de conservación.
¿Qué se hace cuando un pájaro como el bulbul de cabeza negra se trata actualmente con tres nombres científicos diferentes por diferentes: Brachypodius atriceps [Birdlife], Brachypodius melanocephalos [IOC] y ' Microtarsus melanocephalos [BOW/eBird]. El tratamiento estándar ha sido tener diferentes elementos en los nombres de taxón con declaraciones de sinónimos apropiadas, y estos diferentes elementos fueron recogidos por {{ taxonbar }} . En este caso (y otros dos) alguien ha fusionado los elementos de Wikidata para los dos primeros nombres (en Brachypodius atriceps (Q28873180) e hizo de Brachypodius melanocephalos (Q98069319) una redirección) y le da al elemento dos nombres de taxón. Esta sería la forma de tratar el elemento como un taxón y resolver el problema del enlace de sitio. Sin embargo, aparece un error “Esta propiedad debe contener un único “mejor” valor con el mismo conjunto de calificadores para estas propiedades”, aunque no podemos elegir un nombre preferido ya que actualmente los tres son utilizados por diferentes autoridades.
He revertido la fusión, ya que este tratamiento estropea la barra de taxones, que se ha diseñado para funcionar con los tratamientos de Wikidata. Se realizaron fusiones similares para el pájaro carpintero de cabeza gris (Pájaro carpintero de cabeza gris (Q39277), fusionado con el pájaro carpintero de cabeza gris (Q26937878)) y el papamoscas azul pálido (Pájaro carpintero azul pálido (Q73925), fusionado con Niltava unicolor (Q15233019)).
Otro pájaro problemático es el Bulbul de carúnculas azules , que tiene dos elementos Wikidata: uno en el nombre científico (wdq|Q98069651}} y otro en el nombre común (Bulbul de carúnculas azules (Q2927920)). Los enlaces de sitio están divididos entre los dos (15 al nombre común y 6 al nombre científico). Esto sin duda debería fusionarse, pero plantea un problema sobre los títulos de los elementos Wikidata. Como los elementos Wikidata solo pueden tener un nombre de taxón preferido (que solo se puede usar para un elemento), creo que un elemento que es una instancia de taxón siempre debe etiquetarse con el nombre científico, con los nombres comunes en la sección también conocido como. —  Jts1882 | discusión 12:22, 26 de agosto de 2024 (UTC) [ responder ]