Sistema de hipertexto y publicación en mi web

En /hacer (lista antigua de cosas por hacer) ya publiqué mucha información con mucho nivel de detalle. Así experimenté con los nuevos problemas: demasiada información, difícil moverse, cuesta saber qué secciones están anticuadas, difícil tener visión general de dónde está la información, enlaces difíciles entre secciones profundas, URLs difíciles, etc. Y sobre todo veo que los navegadores WWW actuales no son muy buenos para explorar mucha información así.

Ver https://www.danielclemente.com/hacer/org.html#esquemado-interactivo-al

• antes, org le daba a cada sección un ID aleatorio y distinto cada vez, y quedaban URLs con trozo de fragmento como #org1642d64, distinto cada vez
• necesito que los enlaces sean estables
• lo arreglé: ahora muestro un hash entendible, y que será estable si reexporto. Por ejemplo: https://www.danielclemente.com/hacer/emacs.html#avisar-antes-de
• lo hice mediante: https://www.danielclemente.com/emacs/confi.html#org-exportar-mejores

Tengo dos colecciones de información:

• artículos enteros escritos de principio a fin para ser publicados y para ser leídos. Consistentes y con línea narrativa
• una maraña de notas e información donde quizás hay partes interesante, pero otras no. Y están pensadas como referencia (para mí), pero no se „leen“ de principio a fin como un libro tradicional. Están incompletas y pueden cambiar

Ahora estoy combinando casi todo en un solo hipertexto (mediante org-mode). Quiero seguir usando este único sistema pero he de decidir cómo separar entre los dos tipos de escritos, y si los exporto al mismo sitio o a sitios distintos. ¿Creo una sección especial en mi web para las notas desorganizadas?

Decisión esencial: ¿Publico esbozos? ¿Paso a „pensar en público“? ¿Quiero pasar a tomar notas públicas, en vez de notas privadas?

Y algo distinto: estoy experimentando también el grabar una propiedad (GRADO_DE_DEFINICIÓN: A=mucho, B=medio, C=poco) en algunas secciones para decir si tiene un tema claro vs. si no está afinada aún. No sé si esto es lo mismo que lo de „artículos vs. notitas“ recién descrito; me parece que no.

No todo lo que escribo va a acabar publicado. Por ejemplo, en mis notas (org-mode) sobre Emacs, tengo:

• notas para mí (en varios idiomas o mezcla), cosas que estoy aprendiendo, dudas, fragmentos de correos de otras personas, … No quiero publicarlo. Además quiero libertad para tomar mis notas privadas, incluso usando palabras inventadas y otros símbolos que sólo uso yo (ẽ, ∴, …)
• lo ya aprendido hasta ahora, problemas por resolver, problemas resueltos, artículos, … Esto sí es publicable y lo puedo retocar para que sea legible

Opciones:

• todo empieza siendo privado, y yo marco lo publicable con una etiqueta. Creo que irá bien hacerlo así. Quizás tengo que dar muchas etiquetas, pero las puedo dar a un grupo entero de secciones
• todo empieza siendo público, y las partes privadas las escondo (por ejemplo dentro de una sección COMMENT) dentro de una de las cabeceras publicables. Es difícil
• tengo cada información o fichero por duplicado, ejemplo: ~/repoweb/hacer/emacs.org para las cosas de Emacs públicas y ~/wiki/emacs.org para las cosas de Emacs privadas. Es como lo hago ahora (2023) y es muy incómodo porque repito información: por ejemplo describo fallos en una y en la otra

Ahora en mi red de notas (mediante org-mode) mezclo informacion pública y privada. Necesito un sistema de exportación…:

• … que recorra mi árbol de información y decida qué notas toca exportar y cuáles no. Quizás lo invoco una sola vez („exporta todo“ o „exporta todo lo que toca“) o quizás apuntando a una sección concreta que quiero exportar
• … y que decida el fichero de destino para cada sección. En otra sección aquí describo las dificultades de hacer eso.

En mis notas tengo secciones de nivel 10 o más (subsubsubsubsubsubsubsubsubseccción), y a veces una de esas subsubsubsubsubsubsubsubsubseccciones resulta contener un artículo entero, largo, interesante y publicable. Para mí esto no es ningún problema, porque org-mode es bueno y me permite el acceso a cualquier parte de mi árbol rápidamente. Pero si lo exporto a HTML, he de transformar algunas cabeceras a páginas independientes, porque la gente espera que un artículo empiece en una sección de nivel 1, no de nivel 10. Y porque no quiero que un tema eclipse a otro (imagínate si en esta página sobre hipertexto, que lista unos 20 puntos, uno de esos puntos se expande 30 páginas mientras que el resto son 4 párrafos cada uno).

El cómo un autor puede dividir un escrito en secciones… es un arte. No hay que hacer demasiadas secciones de ningún tipo (capítulos, anexos, partes, secciones, subsecciones …). Tampoco hay que hacer muy pocas. Hay que intentar que las secciones tengan parecida cantidad de información. Hay que evitar secciones cortísimas (por ejemplo con sólo una frase).

No sé si puedo hacer el cortar+agrupar en secciones automáticamente (llamémosle inteligencia artificial, que está de moda). De momento me parece que me toca a mí marcar qué cosas (qué cabeceras) se han de exportar como una página propia y qué cabeceras van a quedar publicadas como hijas de otra cabecera (en la misma página).

Ejemplo:

• cab1
  • cab11
    • cab111
    • cab122
      • cab1221
      • cab1222
    • cab123
  • cab12
    • cab121
    • cab122
  • cab13
• cab2

En el ejemplo anterior, imaginemos que cab11, cab121, cab2 requieren estar en página propia/independiente. Las cabeceras hijas de ésas quedarán es la página de una de esas 3 cabeceras padres (se requiere renumeración: por ejemplo cab111 ahora ya no es una sección de nivel 3 sino de nivel 2). Las cabeceras no elegidas o hijas-de-elegidas no se exportarán.

Otro ejemplo más complejo: cab1 y cab12 (sí, una sección hija) han de estar en página independiente. Quiere decir que el artículo cab1 ocupa varias páginas (¿dos?), ya que una de sus secciones merece página propia. Ha de haber enlaces entre secciones para ir de una sección a otra, y lo que antes era enlace entre secciones ahora es enlace entre ficheros. Es complicado. Quizás además el hecho de poner cab12 en páquina aparte hace que cab11 y cab13 también tengan que estar en página aparte.

No sé bien cómo implementar todo esto en org-mode. Ideas:

• automáticamente (no sé cómo). ¿Ya hay algo montado? ¿en org?
• etiquetar las cabeceras que yo quiero en página aparte, mediante una etiqueta. ¿Y luego implementar mucho código para la traducción de enlaces?
• exportar todo a HTML y dejar que otro programa como https://en.wikipedia.org/wiki/HTMLDOC lo parta en páginas. He hecho cosas así al usar https://www.latex2html.org/
• hacer un programa que a partir de un gran .org (un solo árbol) produzca muchos pequeños .org, cada uno será una página independente. Luego se puede exportar cada uno de org→HTML de forma tradicional
• tomar ideas de cĉómo lo hacen en otros medios (imprenta, diarios, …)

¡Acepto ideas para hacer esta monopaginización de org! (convertir cada sección org a 1 página cuando toca).

Ahora:

• escribo un artículo en ~/wiki/unfichero.org
• cuando lo publico, va a ~/repoweb/undirectorio/unfichero.html

Si quiero usar una imagen a.png, ¿dónde la guardo? De momento hago algo feíllo: temporalmente la pongo en ~/repoweb/undirectorio/a.png, y dentro de ~/wiki/unfichero.org me refiero a la imagen sin decir ruta, sólo diciendo a.png. Esta referencia no va cuando estoy en ~/wiki/ (porque no hay ~/wiki/a.png), pero si exporto el artículo ya irá y la veré.

Esto es feo porque he de tener muchas imágenes sueltas (para cada artículo no publicado) en directorios de ~/repoweb. Las imágenes ahí no están en control de versiones (porque son de artículos aún no publicados/finales) y estorban.

No quiero poner las imágenes en ~/wiki/ porque ocuparían mucho (~/wiki/ es para notas en texto).

Puedo poner las imágenes en un tercer directorio. Entonces podría hacer algo así como: que se copien al directorio de destino, cuando se exporta el .org. Creo que org-mode ya ofrece estas cosas pero no las he usado aún. Si esto va, aún he de comprobar que los enlaces a imágenes se han traducido bien.

Quizás puedo encontrar un sistema de referencias que vaya en todos lados. Quizás puedo guardar imágenes en un servidor ajeno (o en otro usuario) y hacer un tipo de enlace especial que las tome de ahí.

Lo mismo aplica a sonido, vídeo, ficheros .txt, etcétera de artículos aún no acabados.

org-mode permite adjuntar ficheros a cada cabecera (org-attach), pero siempre me ha resultado algo incómodo. Quizás puedo aprender a usarlo. Aún necesitaría aprender o implementar lo de la „copia al exportar“.

Quiero que añadir una pequeña imagen a un párrafo sea tan fácil como añadir unas palabras. Ahora es un trastorno. Me iría bien algún sistema en que las imágenes se describen como texto (ejemplo protocolo data:) pero ocuparían mucho.

He creado https://www.danielclemente.com/mapa/ Ahí hay una tabla con el título y sección de cada artículo en mi web, y con otros datos (tamaño, fecha, idioma, …).

Es mejorable (acepto ideas) pero la tabla está.

En https://www.danielclemente.com/mapa/ he hecho un diagrama donde se ve de un vistazo cuáles son las secciones grandes.

Aún así, acepto mejoras.

Ahora en org-mode uso una etiqueta cable para cada cabecera publicable. Luego con un programa recopilo esas cabeceras y compruebo que tienen propiedades EXPORT_TITLE y EXPORT_FILE_NAME.

También extraigo título, sección etc. e incluso meto toda la información en la tabla que uso en https://www.danielclemente.com/mapa/ (busca el estruweb.py ahí, hace eso, con AÑADE_NO_PUBLICADAS = True). Con eso puedo añadir a ese gráfico de bolas todas las secciones no publicadas. Sin embargo no lo uso mucho, porque requiere pasos manuales, porque la visualización no es muy cómoda, y porque no me ayuda a elegir cuál es el siguiente artículo a publicar.

¿Alguien quiere ver esta lista de artículos a publicar? ¿Debería publicarla? Acepto ideas. Si quieres te doy ejemplos de cosas que tengo a medio escribir.

Creo que tengo el sistema éste que buscaba, pero no me es muy útil.

Se supone que yo soy experto en estas cosas, pero me siguen siendo difíciles.

¿Cuántos niveles de URL quiero? Ideas:

• 0: cada artículo va en página aparte, ejemplo: https://www.danielclemente.com/consumo/ es pequeño artículo sobre consumo eléctrico
• 1: podría tener algo como https://www.danielclemente.com/aparatos/consumo.html o https://www.danielclemente.com/aparatos/consumo/
• muchos: podría tener algo como https://www.danielclemente.com/aprendizaje/ingeniería/gestión-de-energía/consumo-eléctrico/aparatos/medidor-de-energía.html. Eso se corresponde a cómo lo tengo organizado en mis notas. La traducción me sería más fácil

¿Cuáles han de ser las categorías raíz? (Los temas de mi web). Uso algunas categorías en https://www.danielclemente.com/mapa/ (lenguaje+lógica, personal, servidores, mi web, aparatos, programas, WWW) pero son pocas, y no se corresponden a las que yo uso internamente en mis notas (que son algo así como: idiomas, descanso, empresa, fútil, trabajo para otros, aprendizaje, mi web).

¿Cómo varío la URL al hacer traducciones? (Ver más sobre traducciones abajo). Ideas:

• sufijo de idioma obligatorio: https://www.danielclemente.com/aparatos/consumo.es.html, https://www.danielclemente.com/aparatos/consumo.en.html etc.
• marcar uno como principal (https://www.danielclemente.com/aparatos/consumo.html), y los otros no: https://www.danielclemente.com/aparatos/consumo.en.html
• el idioma en 1r nivel. https://www.danielclemente.com/es/aparatos/consumo.html, https://www.danielclemente.com/en/aparatos/consumo.html
• diferentes nombres. https://www.danielclemente.com/aparatos/consumo.html y https://www.danielclemente.com/aparatos/consumption.html (¿o traduciendo todos los trozos?)
• misma URL (https://www.danielclemente.com/aparatos/consumo.html), y luego traducida desde dentro por sistemas raros JS

¿Es aceptable una URL difícil de teclear como, …/idiomas/ruso/verbos/поехать.html?

¿Cómo combinar una URL muy precisa (https://www.danielclemente.com/aprendizaje/ingeniería/gestión-de-energía/consumo-eléctrico/aparatos/medidor-de-energía.html) con otras imprecisas? (https://www.danielclemente.com/servidor/).

¿Poner listado de directorios en cada escalón de URL larga? (como https://www.danielclemente.com/aprendizaje/ingeniería/gestión-de-energía/consumo-eléctrico/aparatos/medidor-de-energía.html). ¿Me basta con estos listados para ofrecer navegación?

¿Qué hacer cuando una URL cambia radicalmente? (desde la raíz), ejemplo en https://www.danielclemente.com/aprendizaje/ingeniería/gestión-de-energía/consumo-eléctrico/aparatos/medidor-de-energía.html un día cambio /aprendizaje/ por /notas/; el resto sigue igual, pero la URL ya está rota e inencontrable.

He buscado ejemplos de páginas que hagan bien la gestión de URLs (e idiomas) y no he encontrado…

Tengo bastante más de 150 mil cabeceras en mis notas. No quiero tener que dar una URL a cada una. Tras un poco de trabajo, he hecho una función que le da una URL automática a cada una, basándose en los títulos principales de las cabeceras padres principales. Es algo largo de explicar.

Estoy solucionado cosas como:

• conflictos cuando dos secciones caerían en misma URL
• velocidad
• quitar caracteres de idiomas demasiado exóticos y otros caracteres invisibles
• añadir más texto cuando casualmente he quitado todos los caracteres (por ejemplo tengo cabeceras escritas en ruso, y si quito todo lo cirílico, se queda en nada)

Aún no lo he acabado. Y aún no he solucionado cosas como:

• qué hacer cuando las URLs cambian. No quiero que cambiar una sola letra de un padre me rompa el enlace
• decidir qué cosas irán realmente a un fichero .html y qué cosas serán una sección interna dentro de otro .html (ver arriba lo de la monopaginización)
• qué hacer cuando la URL resultante es larga. Por ejemplo, me quedó una en que la ruta ocupa 1450 letras. Es de una sección muy imbricada (nivel 10 o así)
• cómo combinar todo esto con el enfoque intencionado en el que yo decido qué URLs quiero en mi web

Aunque lo acabe, no sé si lo usaré pues aún he de decidir los puntos anteriores, por ejemplo uno de los primeros mencionados: ¿exporto maraña de notitas, o sólo artículos acabadas?

Cuando estoy escribiendo un artículo con org-mode y quiero enlazar a otra sección de mi web, tengo cuatro opciones:

1. uso un enlace a ID, como bb40159b-d93e-42fb-859b-4f34a309e563. Muy cómodo con org: una tecla lo autogenera, otra tecla lo inserta
2. tecleo una ruta relativa, pues sé en qué HTML quedará el artículo al publicarlo, y sé dónde está el HTML de destino. Por tanto creo el enlace a ../servidor/index.html
3. tecleo una URL completa, como https://www.danielclemente.com/libera/sl.html
4. mediante tecla org (C-u C-c C-l) enlazo al fichero HTML que hay en mi disco duro (no en el servidor), por ejemplo ~/repoweb/hacer/index.html y luego ruego en vano a org para que lo traduzca a una URL válida en remoto

Sobre estos métodos:

1. Los IDs sólo funcionan si org luego sabe encontrar el camino entre secciones. A veces org no la encuentra y el enlace queda roto. Lo bueno de esto es que puedo moverme por el árbol org-mode muy fácilmente. Tengo ya decenas de miles de enlaces así.
2. Usar una ruta relativa va bien mientras pruebo en local, porque puedo seguir enlaces y funcionan. Pero he de pensar bastante (¿dónde estará la página HTML?). Y no puedo seguir los enlaces mientras navego por org; de hecho org no conoce esos ficheros HTML que menciono.
3. Teclear la URL completa es molesto y hace bastante incómodo trabajar en local (porque los enlaces apuntan a Internet). Pero garantiza que la URL quedará donde toca.
4. Puede funcionar. Probablemente puedo configurar org-mode para que me traduzca ~/repoweb/ a https://ww.danielclemente.com/ automáticamente al exportar (no he buscado cómo aún). Pero esto no cubre los otros tipos de enlace que quiero hacer como los de enlaces por ID.

Busco algo más bien basado en el 1r método: cómodo para mí, y donde org (u otra herramienta) haga el trabajo de saber cómo traducir cada enlace.

Debería publicar algo sobre este tema, porque me fascina y he construido varias visualizaciones durante años, y además no encuentro nada parecido ya hecho.

Lo que busco es crear una imagen 2D que muestre un puntito o zona para cada tema del mundo (sea concreto, sea abstracto. Todos), o en mi caso para cada artículo y nota que tengo en mi web. Temas cercanos han de estar cerca. No han de taparse los puntos. Han de llenar bastante el espacio. El cómo construirlo queda libre. Probablemente queda como un mapa del mundo (2D, o 3D proyectado) pero con temas en vez de pueblos/continentes/… Quizás hace falta el hacer zoom.

Tengo:

• https://www.danielclemente.com/mapa/ (el grafo pelotudo), ya lo hace pero no es cómodo. Muestra un nodo por artículo, los agrupa por temas, muestra el tamaño y la importancia y la fecha de caducidad
• he escrito programas para hacer una visualización parecida en un grafo en coordenadas polares (circular, 360º) que mide el tema y el nivel de detalle del tema (ej. „indonesio“ es más específico que „idiomas“). Funciona, pero tuve que pasarme horas codificando una lista de temas, mediante un libro de códigos usados en biblioteconomía. Aún no es escalable
• he hecho gráficos más complejos, que tampoco escalan, porque hay demasiada información. Por ejemplo hice uno para mostrar el movimiento por temas, con animaciones. Ya es difícil representar un recorrido por el espaciotiempo, pero ¡más difícil es un recorrido por el espaciotiempo semántico! Adjunto demo de ejemplo concreto: aún en 2023 sigo escribiendo un artículo largo sobre un viaje que hice en 2015 para aprender idiomas; hice este grafo para ver el movimiento temático que ocurre desde el inicio del artículo hasta el final. Necesito más tiempo para acabar ésa y otras nuevas ideas
• he probado varias curvas que cubren el espacio, como la curva de Hilbert. Con una de éstas sólo necesito 1 eje (una línea de temas). Pero no he encontrado ninguna curva que quede bien
• he estado buscando los ejes con los que clasificar los temas del mundo. Por ejemplo una métrica es „ciencia vs. sociedad“, otra „antigüedad del tema en el mundo“, otra simplemente „cuánto me interesa“, otra „especificidad“. Pongo una métrica en cada eje. Quizás las métricas útiles son más de 2, así que he probado también con varios ejes arbitrarios y luego reduciendo la dimensionalidad (análisis de componentes principales, buscando correlaciones (ejemplo), etc.). Aún no he encontrado ejes muy buenos, pero creo que puedo valerme de los chapuceros que he creado, pues toda clasificación es subjetiva. He clasificado manualmente unos 100 temas en esos ejes, pero no quiero 100.000. Planeo entrenar una red neuronal (no humana) para ayudarme a clasificar temas
• he probado algunos algoritmos de grafos (como: ajuste de redes topográficas), para intentar hacer eso de mantener temas cercanos cerca unos de otros. O sea empezar con una red de nodos aleatoria, y luego mediante una función „distancia entre temas“ ir ajustando la distancia de todos con todos
• quiero hacer alguna simulación física (estilo https://www.danielclemente.com/mapa/, que usa gravedad), por ejemplo con crecimiento de células, o burbujas, o arena cayendo, para generar un mapa global de temas a partir de fórmulas locales (como la similitud entre 2 temas). No he encontrado simuladores fácilmente programables de estos modelos físicos

Supongo que el siguiente paso es crearme un espacio (una imagen de tamaño fijo, quizás 2D) en que yo pueda clasificar ¿a mano? ¿o por gravedad? lo que ahora tengo en https://www.danielclemente.com/mapa/ (que está definido en estructura Python en estruweb.py). He de decidir el soporte: puede ser una analogía de una casa, una habitación con estanterías, un laberinto, un mapa con continentes y océanos, … Algo fácil de entender por mí y por visitantes. Y de recordar. Entonces yo colocaré cada tema (a mano) en una posición concreta de ese „espacio análogo“. Luego lo automatizaré.

Si has entendido algo de esto o crees que no estoy loco, me puedes escribir e intercambiamos ideas… Antes de que mi cordura se vaya por un recorrido por el espaciotiempo semántico …

Con todo lo anterior podría publicar las notas que tengo (más de 150.000 cabeceras). Algunas de ellas son artículos largos (algunos ya publicados en mi web).

Cuando lo tenga, podré mover todo lo de https://www.danielclemente.com/hacer/ hacia mi maraña de notas, y publicarlo con el mismo sistema. Ahora esa sección (/hacer/) usa otro sistema en que cada página requiere su propio fichero .org, y no he implementado todo lo que quiero (partir en paginitas, etc.). Es incómodo y por eso no lo actualizo.

Si encuentro formas de unir ambas secciones, puedo empezar antes. De hecho creo que podría. Pero: tengo mis notas de emacs en mi fichero ~/wiki/emacs.org privado, y luego tengo el ~/repoweb/hacer/emacs.org publicable. Si los mezclo a un solo fichero, quedará mezclado lo privado y la publicable, y necesitaré un sistema un poco más potente que el actual, para poder tomar ciertas cabeceras sí y otras no, y publicar sólo las que tocan.

Hacer este paso puede ser una buena forma de practicar las demás cosas, y a domar/dominar/domesticar/domeñar org.

Tengo información interesante en: cabeceras dentro de fichero org-mode (cada fichero tiene miles de cabeceras), correos que he mandado, otros ficheros sueltos en mi disco duro. He hecho un programa que lista y desglosa y combina todas esas fuentes; en febrero 2023 eso resulta en aproximadamente medio millón de cosas que contienen información (permíteme introducir una palabra que puedo crear en esperanto pero no en español: „informero“. informo+ero: „elemento/componente/partícula de la información“). El número 500k parece alto pero no lo es pues los „informeros“ son pequeños: son cada nota (algunas de 1 línea), cada fichero, cada correo…

Mi programa publicabilidad.py clasifica los „informeros“ automáticamente en varios grupos: „no interesante“, „privado (no publicable)“, „definitivamente publicable“, „por evaluar“, „ya publicado“, „repetido“, … En marzo 2023, este programa aún está en construcción y quedan unos 353k elementos por autoclasificar, la mayoría correos (además creo que está indexando mal los correos: indexa los recibidos; sin embargo los que contienen material que puedo publicar en mi web son los enviados por mí).

Además tengo que hacer una forma buena de exportar esta información. Ahora es una hoja de cálculo, pero si me hace falta la puedo mostrar de otra forma o hacer una estadística de lo publicado+publicable.

Obviamente tengo que tener sistema de publicar una maraña de notas (ver secciones anteriores) si quiero añadir decenas de miles de notitas.

A veces me cuesta elegir lo siguiente a publicar, y en vez de enfocarme en 1 cosa, avanzo en 4 ó 5 a la vez, y voy muy lento. Tengo que decidir cómo mejorarlo. Ideas separadas:

• seguir avanzando en todo, pero dedicarle mucho más tiempo a mi web. (Esto cuando pueda quitarme de encima algunas preocupaciones como el dinero…)
• al azar o con buen juicio, comprometerme a algo y no cambiarlo
• otra persona puede revisar propuestas y ayudarme a decidir lo siguiente a publicar
• me creo unos criterios y un orden. Por ejemplo: „tema X es más urgente que tema Y“, „artículos cortos ganan frente a artículos largos“ etc.
• el programa mencionado en sección anterior (para listar cosas publicables) me las puede dar ya ordenadas

Esto es complejo. Una página multiidioma requiere bastantes decisiones y trabajo extra. He visto pocos que lo hagan bien, y no he visto ninguna página que haga algo cercano a lo que imagino y sueño. De todas formas, en mi web aspiro a menos; sólo quiero poder tener algunos artículos en varios idiomas, fáciles de mantener, y sin lío de enlaces.

Varios enfoques para traducir un HTML:

• acabar de escribir algo, copiar+pegar el fichero y traducir la copia
• escribir un fichero que contiene todas las traducciones juntas (con el programa dislines que creé) y a partir de eso generar la versión en cada idioma. Lo he usado por ejemplo aquí

Pero ahora que uso org-mode, el problema trae filosofía. org-mode me proporciona una jerarquía de información (en árbol con enlaces. Casi un grafo). Nuevas preguntas:

• ¿Cómo incorporar las variantes por idioma? ¿Hago una doble jerarquía, en que cada nodo está varias veces (una por idioma)? ¿O puedo compartir la misma jerarquía (ontología) entre idiomas?
• ¿Cómo asegurarme de que si hago un cambio en una versión, también cambio su traducción?
• Si quiero traducir una sección padre, ¿me fuerzo eso a traducir todos los hijos? (dependen de esa sección padre)
• Si desde lenguaje L de sección A quiero enlazar a sección B, ¿puedo simplemente apuntar a B (como es natural) o estoy forzado a decir que estoy apuntando a „la versión en lenguaje L, de B“?
• ¿Qué pasa si desde „sección A en lenguaje L“ enlazo a una sección B que no está disponible en lenguaje L? ¿Qué pasa si no estaba disponible en el momento de publicar, pero empieza a estarlo más adelante?
• ¿Qué hacer con secciones comunes? Por ejemplo, un artículo tiene una subsección con imágenes; al traducirlo hay que reescribir las secciones con texto, pero no habría que duplicar la subsección que no necesita variaciones (la de imágenes). Hay que usar transclusión
• ¿Cómo incluir el código de idioma en la URL? (Ver sección anterior sobre esquema de URLs)
• Imaginemos que en este artículo (en español, unas 20 secciones) sólo una de esas 20 secciones está traducida (a 3 idiomas). ¿Cómo ha de ser la interfaz interactiva que permita ver eso, conmutar idiomas, y manejar los idiomas no entendidos?

Todo esto es complicado y no he visto a nadie profundizar en la gestión de idiomas en ontologías. El tema me interesa más que al resto del mundo, y busco aprender más. Sé que hay libros (acepto recomendaciones) pero no le he dedicado tiempo a leerlos. En momentos de ingenuidad he estado incluso buscando a ver si hay películas sobre ontologías (mala suerte… no encontré). Si alguien se apunta a rodar una serie o película sobre ontologías o enciclopedias o sistemas de hipertexto, me apunto… Drama, comedia, terror, lo que sea.

He empezado a crear un programa, org-dislines, para poder mantener traducciones de nodos org-moe manteniendo una única jerarquía (y una única red de enlaces). He probado muchas formas de representar el contenido. Aún no he empezado la exportación. Traduzco cada párrafo, pero lo más difícil es cómo traducir los títulos de las secciones, y las URLs.

El sistema a desarrollar ha de proveer: una forma de representar la información; código para exportar a HTML; integración del idioma en esquema de URLs; procedimientos de trabajo para reeditar la información.

FECHA_DE_CREACIÓN: [2022-12-30 Fri]
FECHA_DE_ÚLTIMO_CAMBIO: [2023-03-15 Wed]
FECHA_DE_CADUCIDAD: -
FECHA_DE_REVISIÓN_DE_FECHAS: [2023-03-18 Sat]

No me muevo mucho por fechas. Mi web no es un diario indexado por fecha (o sea lo que llaman „blog“), pero sí que quiero anotar la fecha en cada artículo.

Sí que diferencio entre artículos perennes (no caducan) y artículos temporáneos (donde importa la fecha en que se crearon, o importa la fecha en la que caducan).

Además, a veces me interesa describir varias fechas: la de inicio (o escritura del contenido principal), la de acabado (del contenido principal), la de última actualización (para que se vea que aún mantengo la información). Por eso en algunas páginas he usado fórmulas extrañas como: Empezado: 25.m6.2006. Acabado el 2008 y retocado hasta el 01.m01.2017. Eso es mucho más preciso que decir © 2017. Ó 2006-2017.

Cuando escribo artículos a mano, puedo añadir y actualizar fechas a mano. Pero si quiero exportar una maraña de notas (ej.), cada sección (cada trocito de información) tiene que estar datada automáticamente (o manualmente pero con ayuda). Para eso tengo que extraer las fechas (escritura de contenido principal, última actualización) de cada cabecera org. No tengo hecho nada así.

Además en algún caso he de añadir una pancarta que diga „este artículo está muy caducado“. Ya he creado el concepto de „caducidad“ en la tabla de secciones, pero también me iría bien para la maraña de notas.

He de decidir cómo añadir estas fechas a cada exportación. Ahora uso alguna triquiñuela de org como {{{time(%e.m%m.%Y)}}}

Como experimento, he probado a añadir a esta sección unas fechas, añadidas manualmente como propiedades org que luego son exportadas. Aún es bastante trabajo manual, y org no lo exporta muy bien: por ejemplo, me gustaría poder transformar de YYYY-MM-DD a sólo el año; poder acceder a estos números desde JavaScript para poder resaltar secciones; hacer interactiva la forma en que muestro la tablita con los años.

Quiero quitarme el miedo a hacer cambios de estructar. En mis notas org hago muchos cambios de estructura, del estilo:

• „creé un fichero llamado Árabe.org para mis notas de árabe. Pero ya tengo uno Lingvo.org para mis notas de idiomas. Voy a mover el fichero ese entero para que sea una sección dentro de Lingvo.org“
• „este tema está clasificado dentro de 'servidores', pero ha de estar dentro de 'servidores web'“
• o mucho más sencillo: „esta sección, en vez de llamarse 'pasatiempos', ha de llamarse 'juegos de ingenio'“

En cualquier caso, no quiero que esto rompa la estructura de directorios y los HTML. Pero si estoy decidiendo automáticamente qué URL usar para exportar cada sección, entonces es inevitable que va a haber cambios y conflictos. Entonces me pregunto:

• todo lo que enlazaba a la versión vieja, ¿cómo lo encuentro? ¿Lo he de actualizar? Sé encontrarlo, pero si va a ser mucho trabajo manual, me desmotiva
• ¿he de colocar redirecciones en cada sitio antiguo, para que lleven al nuevo? Supongo que sí. ¿Cómo las genero? (HTML, nginx, …). ¿He de hacerlo a mano y con cuidado y tecleando todo cada vez que esto pasa?
• en caso de que algún enlace se pierda y un visitante llegue a un 404, ¿cómo buscar el lugar correcto de la información? ¿Cómo puedo proveer un mapa de los URLs del sitio? ¿He de ofrecer un buscador?

¿Quiero alojar comentarios a los artículos que escribo? Prefiero no cargarme con este trabajo. Ya he alojado comentarios durante muchos años en mi página (un libro de visitas y comentarios al pie de una sección), y la mayoría estaban fuera de tema o eran preguntas técnicas más aptas para un foro. No me importa el espam o los ataques personales (eso es fácil de evitar o soportar), pero el „fuera de tema“ indica que quizás falta un foro donde hablar de más temas.

Tengo que pensar en cómo poner otra vez un libro de visitas.

También he pensado en crear un foro donde discutir y comentar sobre lo que hay en mi web. Algo como foro.danielclemente.com. Pero me parece muy egocéntrico. ¿Un foro para discutir sobre… mí? ¿Sólo sobre lo que he escrito? ¿O sobre otros temas cercanos con mi página? Yo soy bastante egocéntrico, pero me parece un poco excesivo y vanidoso mantener una comunidad asociada a mí en particular. Creo que la comunidad necesita otro nombre y sitio y ser más abierta.

He preguntado a mucha gente qué opinan sobre esta idea. Me han dicho que para evitar malentendidos debería decir que no es para discutir sobre mí o mi opinión, sino sobre los proyectos de mi página, y para dudas sobre ellos. Pero yo no puedo controlar el cómo la gente usa tal foro.

A la vez he ido siguiendo la pista a varias personas que han montado un foro en su página para discutir sobre temas personales. Veo que al cabo de pocos años acaban quitándolos, no sé porqué. Si conoces experiencias positivas, sugiéreme algo.

Otra idea es poner comentarios al final de cada página. ¿Hay forma de hacerlo fácilmente? (Y respetuosamente. Sin requerir JavaScript, ni registro, ni servir anuncios de terceros). Yo me he hecho mi propio sistema pero es válido para una sección sólo. Y era bastante trabajo controlar las discusiones ahí (la gente intentaba empezar discusiones grandes, pero no es lugar para eso. Mejor un foro normal).

Ahora hago algo chapucero: muchas de las secciones tienen su propio fichero CSS (sólo para esa sección), donde he de definir todo, incluso color de fondo.

Nunca intento mantener un diseño consistente en toda la página, y no me importa ser inconsistente. Pero he de decidir al menos cómo evitar el trabajo de tener que estar arreglando las mismas cosas muchas veces por CSS. Por ejemplo, quizás con org-mode puedo hacer que cada sección reúse un CSS compartido y que además incorpore unas pocas reglas CSS.

Si necesito un fichero CSS para cada sección, tengo el mismo problema que con los ficheros binarios (¿dónde lo guardo mientras una sección está sin publicar?). Ver sección anterior correspondiente.