# Tanemaki — Notas de diseño: nombres, ciencia, notas y registro de banco *Documento de reflexión previo al modelo de datos formal. Lengua: español (el código irá en inglés).* *Refina y expande la Capa 1 del [PLAN.md](../../PLAN.md) §3.* El objetivo de estas notas es cuadrar una tensión concreta: que la app permita guardar datos ricos (nombre científico, enlaces a Wikipedia, germinación, notas personales, historial de banco) **sin volverse pesada ni difícil de usar**. La respuesta corta es un principio + una distinción de modelado. --- ## 1. Principio rector: simple por defecto, profundidad a demanda **No construir dos apps (un "modo simple" y un "modo avanzado" como mundos separados).** Los modos globales confunden (¿en cuál estoy?, ¿dónde quedó ese campo?) y parten la comunidad de usuarios. En su lugar, **una sola app que parece simple para todo el mundo y revela profundidad cuando se pide** (progressive disclosure). Cómo se traduce: - **El alta en 20 segundos.** Añadir una semilla pide lo mínimo: una **etiqueta** (el nombre que tú usas) y, si quieres, una **foto** y una **cantidad**. Nada más es obligatorio. Alguien puede inventariar su cajón entero a base de nombres y fotos, y ya tiene una app útil. - **"Añadir más…"** despliega, por secciones plegadas, todo lo demás: identificación científica, germinación, procedencia, ubicación de almacén, notas largas, enlaces. Quien no lo toca, no lo ve. - **Preferencia global "mostrar campos avanzados"** (opcional): solo cambia *qué secciones vienen desplegadas por defecto*, nunca esconde funciones ni obliga a nada. Una persona novata nunca ve ruido; quien gestiona un banco lo activa una vez y se acuerda. Regla de oro: **cualquier campo más allá de la etiqueta es opcional y, a poder ser, autorrellenable.** El trabajo lo hace la app, no la persona. --- ## 2. Los nombres (modelo realista, en capas) Cómo nombra la gente de verdad una semilla, de lo más personal a lo más formal: 1. **Etiqueta propia** *(lo único obligatorio)* — texto libre, en tu idioma: "el tomate de la abuela", "judía del huerto de arriba 2024". Es lo que tecleas y lo que ves en la lista. 2. **Nombres comunes / vernáculos** *(opcional, lista)* — "tomate de colgar", "tomàquet de penjar", con idioma/región. Pueden venir del catálogo (§3) o añadirlos tú. Son los que la gente busca. 3. **Variedad / cultivar** *(opcional)* — 'Marmande', 'Cherokee Purple'. **Ojo: para quien guarda semillas, esto suele ser la identidad que más importa**, y NO es el nombre científico. Merece su propio campo. 4. **Nombre científico (especie)** *(opcional)* — *Solanum lycopersicum*. **Nunca se teclea en frío**: autocompletado desde un catálogo ligero empaquetado (§3). Es una etiqueta que la app te ofrece, no un deber. La clave: solo la capa 1 es obligatoria. Las capas 2–4 son opcionales y, en su mayoría, se rellenan solas al vincular con el catálogo. --- ## 3. La "parte científica" y los enlaces, sin peso El truco para tener conocimiento botánico sin embeber una base de datos enorme: **anclar cada especie a un identificador estable y derivar el resto bajo demanda.** - El catálogo ligero empaquetado guarda, por especie, un **Wikidata QID** (p.ej. `Q23501` para el tomate). Con ese único identificador, **cuando hay red**, la app deriva gratis: el enlace a la **Wikipedia en tu idioma**, una foto, el taxón en **GBIF**, sinónimos. **Sin red**, sigues teniendo el nombre común y el científico guardados localmente. La "parte científica" es, por tanto, un dato minúsculo (un QID) que abre todo el conocimiento de la web solo si te interesa mirarlo. - **Notas personales:** un campo de texto libre (markdown) + una **lista de enlaces** (pega cualquier URL: Wikipedia, un hilo de foro, tu blog) + **adjuntos** (fotos, un PDF). Simple y abierto. Aquí caben lo científico, lo enciclopédico y lo personal como añadidos opcionales. - Encaja con los mockups: la ficha de ítem (`07_inventory_item`) ya tiene pestañas **DOCS** y **COMMENTS** → notas, enlaces y adjuntos. Así, "datos científicos / Wikipedia / notas propias" son todo capas opcionales colgadas de un ancla mínima, no un formulario que agobia. --- ## 3-bis. Fuentes de nombres y datos: qué va offline, qué online, con qué licencia La pregunta clave: *¿qué banco de nombres es realista usar, qué se empaqueta (offline) y qué se consulta bajo demanda (online), y qué licencia lo permite?* Porque empaquetar datos ajenos en la app es redistribuirlos, y ahí manda la licencia. ### Lo que SÍ es realista **Empaquetar offline (núcleo, tiene que ser ligero):** un catálogo **curado** de las especies hortícolas relevantes en tu contexto (península / Mediterráneo primero, ampliable), NO una taxonomía entera. Por especie: nombre científico + unos pocos nombres comunes por idioma + **Wikidata QID** + clave GBIF. Son del orden de cientos a pocos miles de especies → caben en pocos MB. Se construye extrayendo de: - **Wikidata** — licencia **CC0** (dominio público): *la mejor base para empaquetar*, porque redistribuir es libre y sin ataduras. Tiene ítems de taxón, nombres vernáculos en muchos idiomas y enlaces a Wikipedia. Cobertura de nombres comunes irregular, pero suficiente para un catálogo curado. **Es nuestro ancla.** - **GBIF Backbone Taxonomy** — licencia **CC-BY 4.0** (solo pide atribución). Nombres científicos y sinónimos autoritativos, con nombres vernáculos, y **dumps descargables** (Darwin Core Archive). Se usa para validar/completar el científico. Atribución en el "Acerca de". Con eso, el **catálogo empaquetado se licencia CC-BY** (Wikidata CC0 + GBIF CC-BY), limpio y redistribuible. **Consultar online (opcional, derivado del QID/clave, siempre cacheado):** - **Wikipedia** en tu idioma (resumen + enlace) y **Wikimedia Commons** (foto) — del QID, gratis. - **GBIF** — ficha del taxón, sinónimos, distribución/mapa. - **Permapeople** — base comunitaria de cultivo (cómo sembrar, asociaciones…), **CC-BY-SA 4.0**, con API (requiere alta y pedir acceso). Útil como *referencia online enlazada*, no para empaquetar (ver abajo). ### Lo que NO es realista (o hay que evitar) - **Empaquetar la taxonomía completa** (GBIF backbone entero = millones de nombres; Wikidata entero): pesado e innecesario. Curar, no volcar. - **PFAF (Plants For A Future):** datos valiosos de plantas útiles, pero **licencia restrictiva** → no empaquetar. - **Dejar que la licencia CC-BY-SA "contamine" el catálogo:** si mezclas datos **share-alike** (Permapeople, Practical Plants) *dentro* del bundle, el catálogo entero queda obligado a CC-BY-SA. No es malo (encaja con el ethos copyleft), pero para mantener el núcleo simple y CC-BY, **trata lo SA como consulta online enlazada**, no como dato embebido. Decisión deliberada, no accidental. - **Esperar que cualquier base autoritativa conozca tus variedades tradicionales / cultivares.** No las tiene, por definición: las landraces no están en catálogos oficiales (y ahí está justo el sentido político, §6 del PLAN). Los catálogos oficiales (registro UE/España, CPVO) son *las variedades registradas* — lo contrario de lo que cuidas. ### Consecuencia de diseño: los nombres de variedad los pone la comunidad El **banco de nombres de especie** (capa 4 de §2) viene de Wikidata/GBIF. Pero la **variedad/cultivar** (capa 3, la que más importa a quien guarda semillas) **la teclea la gente**, no una autoridad. Con el tiempo, los nombres de variedad compartidos entre usuarios de Tanemaki (de forma agregada/opcional) van formando **el propio banco folclórico de nombres de Tanemaki** — descentralizado, vivo, y que ninguna base oficial puede darte. Es coherente con todo el proyecto: la ciencia formal se toma prestada (CC0/CC-BY), pero el conocimiento de las variedades tradicionales es de la red, no de un registro. Nota (posible puente futuro, no ahora): como anclamos a GBIF/Wikidata, ese banco folclórico —taxonomía de variedades y nombres vernáculos— es justo lo que los portales abiertos de biodiversidad (GBIF, atlas ALA) tienen más flojo. Deja la puerta a un export *opt-in* estilo Darwin Core, con guardas estrictas de privacidad. No es fase ni modelo; detalle e intención en [open-decisions.md](open-decisions.md) §C. ### Regla transversal: online siempre opcional Nada del núcleo depende de la red. Offline tienes inventario completo, nombres del catálogo empaquetado, notas y registro de banco. Online solo *enriquece* (Wikipedia, fotos, GBIF, cultivo Permapeople, y más adelante los mapas de la Capa 3) y todo **degrada con elegancia**: si no hay red, simplemente no aparece esa capa extra, sin errores ni bloqueos. --- ## 3-ter. La "varilla": autocompletado asistido Idea clave para que la app sea *amena*: una **varilla** (un botón de "autocompletar / rellenar por mí") que, a partir de lo poco que la persona ha metido —un nombre, una especie vinculada o una foto—, **propone** rellenar el resto: nombres (comunes y científico), **cuidados** (siembra, riego, asociaciones), y **datos de conservación** (cómo secar, años de viabilidad de la semilla, condiciones de guardado). Convierte un formulario en un gesto. Principios (coherentes con todo lo demás): - **Propone, nunca impone.** La varilla rellena *borradores editables*; la persona confirma o corrige. Nunca sobrescribe en silencio ni presenta un dato como verdad absoluta (sobre todo los cuidados, que dependen del clima local). - **Un botón, no un muro.** Encaja con el *progressive disclosure*: es una acción opcional, no más campos que rellenar a mano. - **Degrada con elegancia.** *Offline*: rellena lo que da el catálogo empaquetado (nombres, familia y quizá valores de conservación por defecto por familia/especie). *Online*: enriquece con Wikipedia, GBIF, cultivo de Permapeople, etc. Sin red, la varilla hace menos, pero nunca falla. - **Fuentes y privacidad.** Prioriza datos abiertos (Wikidata/GBIF/Permapeople). Si en el futuro se usa reconocimiento de foto (sugerir especie a partir de una imagen de semilla/planta) o un servicio de IA para resumir cuidados, es **opcional, con consentimiento** (la foto/el nombre solo salen del dispositivo si la persona lo pide) y **sustituible** (nada atado a un proveedor cerrado). - **Datos de conservación** (viabilidad en años, secado, guardado) merecen una pequeña tabla curada por especie/familia, empaquetada y ampliable online — es justo el saber que se está perdiendo y que la app puede ayudar a preservar. Encaje con la arquitectura: la varilla es **de dominio** (`app_seeds`), porque "cuidados" y "conservación" son específicos de semillas; el motor genérico no sabe de eso. Es una de las piezas que más diferencian a Tanemaki de una libreta: reduce a un toque lo que en papel era investigar y copiar a mano. ### ¿Es viable la "varilla mágica" con datos abiertos? Sí Verdad de a pie: **es viable**, y hay un gradiente de dificultad según el dato: - **Nombres, identificación y enciclopedia** (nombre común/científico, sinónimos, foto, resumen): **fácil**. Wikidata (CC0) + GBIF (CC-BY) + Wikipedia/Commons vía el QID. Aquí la varilla brilla. - **Datos de conservación** (viabilidad en años, comportamiento en almacén, secado, peso de semilla, germinación): **viable, y con una joya** — la **Seed Information Database (SID) de Kew**, de **dominio público**, cubre ~52.000 taxones (comportamiento en almacén ~25.000 registros, germinación ~54.000, pesos, constantes de viabilidad) e incluye un **modelo que estima la viabilidad** según años y condiciones. Es a nivel de *especie* (no de tu variedad concreta), pero perfecto como **valor por defecto** que la persona confirma. Justo el saber que se está perdiendo, servido por la varilla. - **Cuidados/cultivo** (siembra, riego, asociaciones): **viable pero más irregular** — Permapeople (CC-BY-SA) y Practical Plants tienen datos, a nivel de especie y con cobertura desigual; por su licencia *share-alike*, mejor **enlazar/consultar online** que empaquetar (§3-bis). Conclusión: la varilla no es magia ni humo — es **agregación de datos abiertos existentes**, anclada al QID de la especie. Lo fácil (nombres, Kew SID de conservación) da ya muchísimo valor; lo irregular (cuidados) se enlaza. Trabajo real: montar el **subconjunto curado empaquetado** para las especies objetivo (Wikidata + GBIF + Kew SID) y enriquecer online el resto. **A pensar más:** el conjunto mínimo de campos de la v1 (probablemente nombres + viabilidad/conservación de Kew SID + siembra), confirmar la vía de acceso/descarga de Kew SID, y si el reconocimiento por foto entra pronto o es fase posterior. ### Fuentes - [Seed Information Database (SID), RBG Kew — dominio público](http://data.kew.org/sid/) · [visión general MSB](https://www.rbgkew.org.uk/msbp/scitech/sidoverview.html) --- ## 4. El registro de banco: variedad / lote / movimiento Esta es la distinción de modelado que hace que **fecha, entrada/salida, año y germinación** —lo que subrayas como importante— caigan en su sitio sin campos sueltos y confusos. Tres niveles: - **Variedad (accession)** — la *identidad*: nombres, especie, cultivar, notas, enlaces. Permanente. Es lo que ves en el inventario. - **Lote (lot / batch)** — una *hornada concreta* que tienes de esa variedad: **año de cosecha**, cantidad, ubicación de almacén, resultado de germinación. Puedes tener **varios lotes de la misma variedad** (el de 2023 y el de 2024) y no mezclarlos. El año vive aquí, que es donde importa (la germinación decae con la edad del lote). - **Movimiento (event)** — el *diario* de un lote: **recibido de** X (fecha), **entregado a** Y (fecha) = *un Plantare*, **sembrado** (fecha), **test de germinación** (fecha, %). Entradas y salidas son, simplemente, tipos de movimiento. Qué te da esta separación, "gratis": - **Entrada/salida, fecha, año, germinación** dejan de ser campos ambiguos: cada uno pertenece a su nivel (año→lote, fechas de intercambio→movimiento, identidad→variedad). - Conecta con la pestaña **HISTORY** del mockup: es la lista de movimientos del ítem. - Conecta con §5-bis: **cada movimiento de salida ES un Plantare**, y la cadena de movimientos entre personas es el **DAG de procedencia** de la variedad. - Habilita el **banco colectivo**: se sabe quién aportó qué lote y cuándo, sin ensuciar la identidad de la variedad. **Germinación como evento** (opcional, avanzado): fecha, tamaño de muestra, nº germinadas, % (calculado), notas. Con el año del lote, permite avisos amables tipo "este lote es de 2019; su germinación puede haber bajado, ¿lo pruebas?". --- ## 5. Qué se ve en "simple" vs. qué revela "avanzado" | Nivel | Campos | Cuándo aparece | |---|---|---| | **Simple (siempre)** | etiqueta, foto, cantidad cualitativa, categoría, ¿se comparte? | alta básica, 20 s | | **Un toque más** (habitual en banco) | año del lote, procedencia (de quién), fecha de entrada | un despliegue | | **Avanzado (a demanda)** | nombre científico + Wikidata/Wikipedia, cultivar, nombres vernáculos múltiples, varios lotes, germinación, ubicación de almacén, notas largas, enlaces, historial completo | secciones plegadas / preferencia | --- ## 6. Riesgo a vigilar (banco colectivo) En un banco colectivo la tentación es **exigir muchos datos** por cada aporte, y eso mata la participación. El diseño debe garantizar que **un aporte mínimo sea siempre válido** (nombre + año + quién lo aporta), y que el resto se rellene *con el tiempo* o *entre varias personas* (colaborativo: alguien añade el nombre científico, otra persona sube una foto, otra registra una germinación). La app acompaña; nunca hace de aduana. --- ## 7. Qué falta decidir antes del modelo formal - ¿El catálogo ligero empaquetado se centra primero en hortícolas de la península (para que el autocompletado sea realista en tu contexto) y se amplía luego? Probablemente sí. - ¿"Cantidad" a nivel de lote con unidades cualitativas por defecto (§3) y precisión opcional? Sí, coherente con lo acordado. - ¿Ubicación de almacén como texto libre o como lista reutilizable ("nevera", "trastero", "banco del pueblo")? Empezar por texto libre con sugerencias. - ¿Un lote puede pertenecer a un banco colectivo *y* a tu inventario personal a la vez? Afecta al modelo de permisos/compartición; decidir al abordar la Capa 2–3.