# 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.
