Publicación de Sitio Web desde WebDAV (OpenLink)

Sitio Web desde WebDAV

Usa esta skill para tomar un sitio estático ya generado HTML/CSS/JS — la salida de un pipeline RDF-Turtle + SHACL + Jinja2 como sites/openlink/rdf/build.py — y publicarlo en una raíz WebDAV de Virtuoso con una ruta pública mapeada. El modelo de contenido del sitio (ontología, formas SHACL, ordenación) se crea y valida antes de esta skill; el trabajo de esta skill comienza en "aquí hay una carpeta generated/ con HTML terminado, publícalo en vivo".

Esto es deliberadamente más limitado que weblog-from-webdav u osdi-inclusion-engine: esas skills renderizan contenido en vivo en cada solicitud (enumeración de colecciones WebDAV dentro de un VSP personalizado, o una capa XSLT compartida que envuelve HTML obtenido de WebDAV). El contenido de esta skill ya está completamente renderizado antes de llegar; publicarlo es un simple PUT WebDAV más un VHOST_DEFINE para archivos estáticos, sin ejecución VSP ni consulta SPARQL en vivo involucradas. Consulta references/webdav-website-engine-gate.md para saber por qué se tomó esa decisión y cuándo cambiaría.

Barrera Crítica — Un Archivo Local No es una Finalización Válida

Cuando el usuario solicite publicar, desplegar o "poner en vivo" un sitio generado, una descripción de lo que sucedería, o una afirmación de que los archivos existen localmente, no es una finalización válida a menos que el usuario solicite explícitamente solo una verificación local/previa. El entregable predeterminado es:

• un sitio publicado y verificado en vivo: la ruta de destino devuelve el mismo contenido que la salida local generated/, o
• un paquete desplegable completo: generated/*.html, los assets/ del sitio (site.css, theme.js), un templates/deploy-website-route.sql con rutas sustituidas, y un archivo README/notas de ejecución — con scripts/validate_generated_website_bundle.py pasando correctamente.

Lee references/webdav-website-engine-gate.md antes de reclamar cualquiera de los dos. Si no hay credenciales de despliegue (WebDAV y/o isql), detente en el paquete desplegable y di claramente que la publicación en vivo está bloqueada por falta de acceso autenticado — no describas un éxito hipotético.

Primeras decisiones

Establece estos puntos antes de publicar cualquier cosa:

• Directorio fuente del pipeline (ej. {LLM_ROOT}/Claude Generated/sites/openlink/) y si rdf/build.py debe ejecutarse (o re-ejecutarse) primero, o si generated/ ya está actualizado.
• Colección DAV de destino, ej. /DAV/home/kidehen/sites/openlink/.
• Ruta pública, ej. https://linkeddata.uriburner.com/sites/openlink/.
• Modo de identidad: nombre de usuario/contraseña SQL, isql WebID-TLS, WebID-TLS con delegación, nombre de usuario/contraseña WebDAV, WebDAV mTLS, o WebDAV mTLS con On-Behalf-Of.
• Si es un bootstrap de ruta por primera vez (requiere isql + deploy-website-route.sql) o una republicación solo de contenido de una ruta existente (solo publicación WebDAV, según el límite de alcance de references/webdav-publish-mode.md — nunca toca la configuración de rutas).

Flujo de trabajo

1. Confirma que la salida generated/ fuente está actualizada: si se solicita (re)construir, ejecuta el propio rdf/validate_shacl.py del pipeline y luego rdf/build.py sin cambios — esta skill no reimplementa ni evita esa validación. Consulta references/rdf-content-mode.md.
2. Antes de escribir cualquier cosa, busca en memoria/trabajo anterior validate_generated_weblog_bundle, VHOST_DEFINE, DAV_RES_UPLOAD_STRSES_INT, website-from-webdav; reutiliza soluciones probadas en lugar de redescubrirlas.
3. Determina si la ruta de destino ya existe (consulta DB.DBA.HTTP_PATH y WS.WS.SYS_DAV_RES para la ruta de destino mediante isql). Si no, haz bootstrap: parchea templates/deploy-website-route.sql con la ruta/ruta/título DAV reales, luego ejecútalo con isql. Consulta references/isql-route-mode.md.
4. Valida el paquete con scripts/validate_generated_website_bundle.py antes de cualquier publicación. Esto es bloqueante.
5. Publica mediante WebDAV usando scripts/publish_static_bundle.py — hace PUT de generated/*.html y assets/* recursivamente, verifica cada escritura con un GET/PROPFIND posterior de comparación. Consulta references/webdav-publish-mode.md.
6. Verifica: obtén la ruta en vivo, confirma que los bytes servidos coinciden con el archivo generated/ local (permitiendo solo diferencias de espacios en blanco/orden de atributos, misma tolerancia que usa la verificación de Fase 1 del pipeline), confirma que assets/site.css/theme.js se cargan con los tipos MIME correctos.
7. Informa exactamente lo que sucedió: ruta bootstrap o reutilizada, archivos publicados con sus rutas DAV, resultado de verificación — o, si faltaban credenciales, la ubicación del paquete desplegable y la declaración explícita de que la publicación en vivo no ocurrió.

Referencias de modo

• Para bootstrap de ruta y sintaxis isql TLS/WebID, lee references/isql-route-mode.md.
• Para publicación WebDAV y su límite de alcance, lee references/webdav-publish-mode.md.
• Para el límite del pipeline (qué hace y qué no toca esta skill en rdf/), lee references/rdf-content-mode.md.
• Para saber por qué no se eligió renderizado SPARQL/VSP en vivo, lee references/webdav-website-engine-gate.md.
• Para operaciones invocables por agente, lee references/opal-tool-mode.md — no implementado en v1; documentado como punto de extensión.

Barreras prácticas

• Nunca ejecutes la validación SHACL de rdf/build.py con advertencias suprimidas o atajos tipo --skip-validate; una barrera fallida significa que el contenido no está listo para publicar, no un obstáculo que sortear.
• DB.DBA.DAV_RES_UPLOAD_STRSES_INT (si se usa para cualquier paso que no sea de archivo estático) necesita un flujo string_output() poblado mediante http(content, stream), no una cadena simple.
• Evita $1, $2 y tokens similares en cualquier SQL cargado mediante isql; pueden activar sustitución de macros.
• Un VHOST_DEFINE para archivos estáticos usa is_dav=>1, is_brws=>0, def_page=>'index.html' — no configures def_page=>'index.vsp' a menos que exista genuinamente un punto de entrada VSP; un def_page que apunta a un recurso VSP inexistente sirve fuente cruda o un 404, no el sitio.
• Elimina cualquier VHOST_DEFINE previo conflictivo para el mismo host/ruta antes de redefinirlo, igual que el patrón de eliminar-y-redefinir ruta de weblog-from-webdav.
• Trata la identidad con certificado y el principal delegado como hechos separados: -X/--cert identifica al agente que llama, -W/On-Behalf-Of identifica al principal WebID cuyos derechos ACL deben evaluarse.
• Nunca escribas credenciales en la skill, SQL generado, registros o archivos confirmados.
• Las subidas y eliminaciones remotas siguen el mismo orden HTTP → WebDAV → iSQL y patrón PKCS#12 principal (howto/remote-webdav-upload.ttl, howto/remote-resource-removal.ttl, pasos 215–216 de Prefs). Las escrituras/eliminaciones de URIBurner van al puerto 5443. Reporta GET :5443 y GET público 443 por separado después de PUT; después de DELETE, verifica la URL nombrada por el usuario, variantes de barra, GET :5443 y el listado de carpetas antes de reclamar eliminación.

Salida segura de errores de ISQL en Virtuoso

Cada vez que este flujo de trabajo invoque el cliente nativo isql de Virtuoso de OpenLink, pasa la opción de cliente simple COMMAND_TEXT_ON_ERROR=OFF, por ejemplo isql {host}:{port} {user} {password} COMMAND_TEXT_ON_ERROR=OFF {script.sql}. Colócala antes de la entrada SQL, argumentos de script o -i. OFF se asigna al valor interno 0 del cliente y evita que el cliente añada el comando fallido completo a la salida de error. El cliente acepta OFF/ON; el literal 0 es rechazado. No uses -u para esta configuración (-u llena el array de argumentos U). Esto no oculta secretos de diagnósticos del servidor, historial del shell o argumentos de proceso, así que mantén las credenciales fuera del texto SQL y los registros. No apliques esta opción específica de Virtuoso a clientes isql de unixODBC/iODBC.