La capa que falta entre los estándares de patrimonio y los datos de patrimonio

patrimonio culturalla edad tiene cointegral estándares para describir qué son las cosas. Lo que ha sido más difícil de conseguir es cómo utilizarlos eficazmente para que los datos alcancen su máximo potencial, incluyendo encontrarlos, acceder a ellos y (re)utilizarlos, especialmente dentro de consultas y análisis automáticos. Lo que ha faltado hasta ahora es La capa inferior: la que permite que el software verifique un archivo real, lo entienda y lo transmita. Así es como el proyecto HERITALISE construyó esa capa. aprovechando el enfoque de bloques de construcción OGC, es decir, la definición, el almacenamiento y la documentación de pequeñas piezas modulares de especificaciones, lo que facilita la validación, el cumplimiento de estándares y la escalabilidad ((véase más adelante). Los resultados se publican as bloques-patrimonio, un registro público de 27 bloques de construcción reutilizables. Tel método asistido por IAd detrás de él se transfiere a cualquier dominio. 

Cómo leer esta publicación. El texto principal está dirigido a quienes diseñan o especifican sistemas de datos. Los recuadros con sangría titulados «En pocas palabras» explican lo mismo, pero sin utilizar jerga técnica, para profesionales del patrimonio cultural que priorizan el resultado sobre los aspectos técnicos. Ambas opciones son válidas por separado.

Empieza con una habitación en Venaria.

La Reggia di Venaria, cerca de Turín, es uno de los sitios piloto del proyecto HERITALISE y el primero en presentar un conjunto detallado de requisitos de documentación. Tomemos como ejemplo una sola sala: la Galleria Grande, la gran galería de Filippo Juvarra. Un equipo de documentación debe registrar la galería, el edificio que la alberga, el sitio al que pertenece dicho edificio, el estado de sus superficies, los escaneos láser y la fotogrametría utilizados para capturarla, y quién realizó todo esto, cuándo y con qué instrumento.

Pregunta qué estándares usar y el campo te dará una buena respuesta bien establecida. Describe los objetos, lugares, actores y eventos con CIDOC-CRM, el modelo de referencia conceptual ISO en el que la comunidad ha convergido y que sustenta el trabajo europeo actual, como la Ontología del Gemelo Digital del Patrimonio que respalda la Nube Colaborativa Europea para el Patrimonio Cultural. Registra quién hizo qué, desde qué y con qué instrumento, usando PROV-O. Coloca las cosas en el espacio con GeoJSON. Usa SOSA/SSN para lecturas de sensores, DCAT para metadatos de conjuntos de datos, EDM si los registros deben llegar eventualmente a Europeana. 

Esa es solo la mitad de la imagen, porque la galería también es un edificio ubicado en un paisaje. En el momento en que la documentación incluye el lado 3D y el levantamiento, se aplica una segunda familia de estándares: IFC para el modelo BIM del edificio en sí, CityGML y LandInfra para el contexto urbano y paisajístico circundante, INSPIRE para todo aquello que deba ajustarse a los datos geoespaciales europeos. La documentación del patrimonio se sitúa precisamente en la frontera entre el mundo semántico y el mundo geoespacial y BIM, y es en esa frontera donde reside la mayor parte de la dificultad práctica. 

Cada uno de esos estándares es la respuesta correcta a la pregunta para la que fue creado. Lo que ninguno de ellos proporciona, por diseño, es lo siguiente: un modelo de datos real para su caso de uso. Alguien todavía tiene que decidir qué contiene un registro de esta galería, cómo se ve una evaluación de estado como un conjunto de campos, cómo se relaciona una habitación con el edificio que la rodea y con el escaneo que la capturó, y luego vincular cada una de esas decisiones con el término estándar que representa, en un formato que el software pueda procesar. Un modelo de referencia conceptual le indica cómo pensar sobre la información patrimonial. Deliberadamente, no realiza ese modelado por usted, y no puede indicarle al software que falta el enlace al sitio principal.

Así pues , cada proyecto realiza su propio modelado, y cada uno lo hace de forma diferente. Por eso, a menudo se obtienen conjuntos de datos que afirman seguir los mismos estándares, pero que aun así no pueden utilizarse conjuntamente. Este artículo trata precisamente de realizar ese modelado una sola vez, de forma transparente, y publicarlo en un formato que permita al software procesarlo.

En pocas palabras. En el ámbito del patrimonio cultural, existe un consenso general sobre cómo abordar la información. Hay modelos consolidados y reconocidos internacionalmente para objetos, lugares, personas, eventos, edificios y datos 3D. Sin embargo, ninguno de ellos ofrece una solución práctica: qué información debe incluirse exactamente en un registro sobre esta sala, en un formato legible por ordenador. Cada proyecto lo resuelve por sí mismo, razón por la cual dos equipos pueden seguir fielmente los mismos estándares y aun así ser incapaces de leer los archivos del otro. Nosotros realizamos ese trabajo una vez, para el patrimonio cultural, y lo publicamos para que cualquiera pudiera utilizarlo.

Qué es un bloque de construcción

Un bloque de construcción OGC es una especificación pequeña y autónoma, o una parte reutilizable de una. Cada bloque es un modelo de datos para un tipo de cosa, y se agrupa en un solo paquete bajo un nombre estable como ogc.heritage.building :

• a Esquema: los campos exactos que tiene un registro válido, en un formulario que el software comprueba automáticamente; 

• a mapeo semántico: para cada campo, el término estándar que representa, ya sea que se trate de "forma parte de" de CIDOC-CRM detrás de un Sitio principal El campo o PROV-O "fue generado por" detrás del escaneo que produjo un modelo, que es lo que permite convertir un archivo de datos simple en un grafo de conocimiento; 

• reglas de validación Para ese gráfico, detectar los errores que una revisión campo por campo no puede ver; 

• documentación en lenguaje ordinario; 

• ejemplos trabajados, probado automáticamente cada vez que cambia el bloque; 

• donde sea útil, conversiones prefabricadas a otras especificaciones. 

Un registro es una colección publicada y mantenida de dichos bloques. OGC Blocks es el marco para construirlos, y ya existen registros públicos para muchos dominios de propósito general.

Los bloques se componen, y este es el mecanismo sobre el que se sustenta todo lo demás. La forma más evidente es el perfilado : se toma otro bloque completo y luego se restringe o extiende, sin redefinirlo ni bifurcarlo. La forma menos evidente es más importante. Un bloque no se limita a un único padre. Puede heredar de varios a la vez, componer partes de otros, restringir lo que hereda y ofrecer la opción de elegir entre padres alternativos, todo en una sola definición. Los perfiles se construyen combinando estas técnicas, no especializándose en una única línea de descendencia.

Eso es lo que mantiene un modelo de datos del tamaño adecuado. Los estándares generales se escriben para una amplia aplicabilidad, por lo que adoptar uno directamente tiende a resultar en especificaciones excesivas e insuficientes a la vez: incluye términos y opciones que no tienen nada que ver con sus datos, sin poder expresar la única distinción que su caso de uso requiere. Y con frecuencia, ningún estándar por sí solo es lo suficientemente completo, independientemente de las modificaciones que se le hagan. La combinación permite descartar lo que no aplica, agregar los detalles precisos y tomar prestado de una segunda o tercera especificación donde la primera se detiene. Los datos escritos en uno de nuestros bloques siguen siendo válidos en todos los bloques en los que se basa, hasta el nivel superior. La siguiente sección muestra cómo se ve esto en una sala real. 

En conjunto, eso cubre las tres cosas que los pilotos realmente necesitaban: 

• Describir. Todos los implicados, desde el conservador que introduce los registros hasta el desarrollador que crea herramientas a partir de ellos, trabajan a partir de una definición precisa de los datos. 

• Validar. El esquema detecta los errores estructurales; las reglas del grafo detectan los errores significativos, como una relación faltante o un objeto tipificado incorrectamente. 

• Transformar. En dos niveles. Las asignaciones semánticas de un bloque (las propias, más todo lo heredado de los bloques en los que se basa) transforman un registro simple del sistema de un socio en un grafo consultable y enlazable, listo para la agregación al estilo Europeana. Además, los bloques pueden publicar conversiones: conversiones listas para usar a otros bloques y especificaciones, que se incluyen con el bloque para que nadie posterior tenga que reimplementarlas. 

En pocas palabras, un bloque de construcción es una especificación pequeña para un tipo de información: qué debe contener un registro sobre un edificio, una habitación o un estudio, qué significa cada parte y cómo distinguir un registro correcto de uno incompleto. Se encuentra en una dirección web fija, por lo que el software puede procesar cada parte sin necesidad de que una persona la lea e interprete. Los bloques se complementan entre sí y pueden combinarse: un edificio histórico es un bien patrimonial con algunas adiciones, y el registro de un escaneo 3D puede cumplir con los estándares de patrimonio, procedencia y cartografía simultáneamente, en lugar de obligar a elegir uno u otro.

La respuesta para la Galleria Grande

Con eso en mente, la pregunta "¿cómo estructuramos esto?" tiene una respuesta concreta: 

lugar (CIDOC-CRM E53 Lugar, perfila el bloque de características geoespaciales estándar)
  └── sitio patrimonial (sitio CIDOC-CRM E27) → la Reggia di Venaria
        └── edificio (CIDOC-CRM E22 Objeto creado por el hombre, alineación IFC)
              └── espacio arquitectónico (CIDOC-CRM E22, IFC IfcSpace) → la Galleria Grande 

Cada nivel añade únicamente las novedades de ese nivel y hereda el resto. El bloque `building` añade un enlace a su sitio principal y hereda todo lo demás, incluido el campo `url` mapeado a la URL de acceso de DCAT, del bloque `heritage-object` superior. Las alineaciones IFC que incorporan `building` y `architect-space` permiten que un registro de esta cadena se distribuya entre el catálogo patrimonial y el modelo BIM de la misma sala sin necesidad de una traducción personalizada en cada caso.

Ahora agregue el escaneo láser de una bahía de esa galería, y la combinación de varios estándares comienza a justificar su utilidad. Un escaneo es tres cosas a la vez: algo con un historial de procedencia, algo ubicado en el espacio y algo con un significado patrimonial. Ningún estándar abarca los tres, por lo que la característica de representación digital los combina. Hereda la entidad de PROV-O para la procedencia. Para la ubicación, ofrece la opción entre una característica GeoJSON (JSON-FG) y una característica topográfica , dependiendo de si el registro contiene su propia geometría o apunta a la de otra persona. Su anclaje CIDOC-CRM se encuentra en la capa semántica. Luego agrega sus propias propiedades y restringe el identificador heredado para requerir una URI real. Un registro, tres especificaciones satisfechas a la vez, ninguna de ellas bifurcada, y el registro sigue siendo una instancia válida de cada una.

La elección de la geometría es lo interesante. El escaneo de la bahía cubre exactamente la zona que se inspeccionó, por lo que, en lugar de repetir ese polígono dentro del registro del levantamiento, este apunta a la geometría del espacio arquitectónico por referencia. Ambos no pueden separarse posteriormente, ya que solo existe una copia. Se trata de vínculos explícitos y legibles por máquina entre modelos de datos, no de una declaración de compatibilidad en un documento. 

La misma cadena describe Villa Portelli, una residencia del siglo XIX en Malta y el otro sitio piloto del proyecto: los mismos cuatro niveles, un edificio diferente en un país diferente, sin necesidad de un nuevo esquema. Una definición, dos proyectos piloto, dos ejemplos prácticos. Esta reutilización en sitios no relacionados es la ventaja práctica de vincular los bloques a las clases de CIDOC-CRM en lugar de al vocabulario que cada sitio utilice localmente. 

En pocas palabras. Cuatro especificaciones anidadas: un lugar, un sitio patrimonial, un edificio en él y una habitación dentro del edificio. Al describir la habitación, se obtiene automáticamente toda la información ya acordada sobre el edificio, el sitio y el lugar donde se encuentra. Estas mismas cuatro especificaciones se aplican a un palacio real barroco en Italia y a una casa del siglo XIX en Malta, que es precisamente lo que se busca: dos equipos documentando elementos muy diferentes, de forma que un tercero pueda leerlos. Y dado que cada registro es también un objeto geoespacial propiamente dicho, un estudio de una habitación puede simplemente señalar su contorno en lugar de llevar una segunda copia que alguien tendría que actualizar posteriormente.

La auditoría que precedió a cualquier redacción

La primera decisión importante fue sobre qué no escribir. Ya existen registros publicados y mantenidos para la mayoría de las capas genéricas:

Lo que nadie publica es la capa donde el patrimonio es genuinamente específico: CIDOC-CRM y EDM aplicados a objetos, lugares, actores y eventos del patrimonio físico, así como a sus representaciones digitales, coexistiendo con los estándares geoespaciales y BIM en lugar de ignorarlos. Esa laguna es la verdadera contribución del registro. Todo lo creado en bblocks-heritage se ancla a una clase CIDOC-CRM, CRMdig, CRMsci o EDM y compone las importaciones anteriores en lugar de duplicarlas. La representación digital se construye componiendo el bloque de procedencia importado, no reinventando los campos de procedencia.

Vale la pena realizar esta auditoría de “lo que existe, en contraposición a lo que realmente falta” con detenimiento y documentarla. Es la diferencia entre un registro que amplía la cobertura y uno que añade ruido a un panorama normativo ya saturado. 

La auditoría incluso truncó un caso de uso completo. Un caso de uso de HERITALISE se centra en observaciones y mediciones en sitios patrimoniales: lecturas de sensores, simple y llanamente. Al someter sus requisitos a la misma búsqueda cruzada de registros, todos coincidieron con los bloques SOSA/SensorThings existentes, y el número correcto de nuevos bloques a crear resultó ser cero. Un método que puede afirmar con seguridad que «no se necesita nada nuevo» cumple su función a la perfección. El costoso fallo en este ámbito reside en el registro que reinventa las observaciones de sensores con vocabulario patrimonial añadido. 

En pocas palabras. Antes de escribir nada, comprobamos qué ya existía. La procedencia, los vocabularios, los catálogos de conjuntos de datos y las lecturas de sensores son problemas resueltos con respuestas publicadas y actualizadas, así que los reutilizamos en lugar de crear otra variante con sabor a legado. Para uno de los casos de uso del proyecto, la conclusión honesta fue que no se necesitaba nada nuevo. Saber cuándo no inventar algo es tan valioso como inventarlo.

Cuatro movimientos, repetidos por piloto

El método en sí es lo suficientemente breve como para describirlo completamente: 

1. Registrar los requisitos en un formato tabular coherente. Las necesidades de cada piloto se presentaban en forma de tabla, con una fila por cada dato requerido. Solo eso ya permitía enumerarlas y rastrearlas, aunque el contenido de cada celda seguía siendo principalmente prosa de formato libre escrita por expertos en la materia, en lugar de por autores de esquemas.
2. Primero, adapte la documentación a los estándares; después, escriba los esquemas. Antes de que existiera un único esquema, cada requisito tenía una asignación documentada a lo que realmente lo cubría: una propiedad CIDOC-CRM, una relación PROV, una clase de observación de sensor, un concepto IFC. Esa asignación es prosa con justificación, independiente de cualquier identificador de bloque, y sigue siendo el registro autorizado de por qué Cada bloque tiene el aspecto que tiene. Los requisitos que ya estaban cubiertos por un bloque existente o un registro importado solo necesitaban un ejemplo, no un nuevo esquema. Varios de los requisitos de Venaria relacionados con el jardín se resolvieron de esa manera.
3. Elabore el texto bloque a bloque, siguiendo una lista de verificación fija. Verifique si el elemento ya existe y puede reutilizarse; escriba el esquema; asigne cada campo a su término CIDOC-CRM, PROV, EDM o IFC; escriba las reglas de validación del gráfico; escriba una descripción en lenguaje sencillo; y escriba al menos dos ejemplos basados ​​en datos piloto reales, uno con el estilo de Venaria y otro con el estilo de Malta, si es posible. Dos ejemplos por bloque no son un adorno. Los ejemplos basados ​​en datos piloto son la evidencia concreta de que un bloque realmente cumple con el requisito que afirma cumplir.
4. Validar antes de continuar. Cada ejemplo se verifica automáticamente de tres maneras: comparándolo con el esquema, mediante la conversión a un grafo y, una vez convertido, con las reglas del grafo. Un bloque no se considera terminado hasta que todas estas verificaciones se hayan superado. Decidimos no generar bloques en masa para su validación final. Varios problemas sutiles solo surgieron durante la validación, y detectarlos bloque por bloque resultó mucho más económico que resolverlos en muchos a la vez.

Esa última regla demostró su valía rápidamente. Un análisis de estándares anterior que heredamos incluía reglas de validación escritas a mano, generadas por un asistente de IA diferente, que nunca se ejecutaron. Lo utilizamos como referencia inicial, no como verdad absoluta, y no lo implementamos sin someterlo a las verificaciones pertinentes. «Generado por IA» y «generado y verificado por IA» no son lo mismo. 

En pocas palabras. Anota lo que necesitas, línea por línea. Averigua qué estándar existente cubre cada línea antes de diseñar nada. Luego, construye una pieza a la vez y comprueba que cada una funciona con ejemplos reales de un sitio web real antes de empezar con la siguiente. Nada se acepta solo porque parezca plausible, incluyendo cualquier cosa producida por una IA.

La parte en la que la IA se gana su lugar

Utilizamos Claude Code para la creación del código: leer los requisitos, escribir los esquemas y las asignaciones semánticas, ejecutar la validación e iterar ante los fallos. Su buen funcionamiento, y la baja intervención humana que demostró, se deben a que el asistente no partía de cero. Pudo aprovechar un conjunto sustancial de recursos, herramientas y servicios cuyo propósito es precisamente apoyar a un asistente de IA en este tipo de tareas. Gran parte de esto ya existía antes de HERITALISE. La creación de este registro lo mejoró y subsanó deficiencias que solo se hacen evidentes una vez que un método se implementa de principio a fin en un dominio real, lo que lo convierte en un resultado de esta historia, al igual que el propio registro.

Habilidades, no conjeturas. Una Habilidad de Agente es un conjunto empaquetado de instrucciones y material de referencia que un asistente de IA carga cuando se encuentra con una tarea de un tipo determinado: en efecto, la experiencia escrita de alguien que ya ha realizado el trabajo, en un formato que el asistente puede utilizar cuando lo necesite. Creamos y mantenemos OGC LLM Skills , un repositorio público de estas habilidades para el trabajo con OGC Blocks. Una habilidad cubre la creación de bloques; otra cubre la parte posterior, validando los datos con respecto a los bloques publicados y convirtiéndolos en un gráfico. Junto con ellas, un servicio de búsqueda permite al asistente examinar cada registro publicado, por palabra clave y por significado, antes de que se escriba algo nuevo. Esto es lo que convirtió juicios como «no reinventar la procedencia» y «el caso de uso de observaciones no necesita nada nuevo en absoluto» en comprobaciones rápidas y fiables en lugar de búsquedas manuales de especificaciones.

Una memoria de trabajo que perdura más allá de la sesión. Un archivo de plan dinámico registraba el alcance, el estado, el orden de autoría, las dependencias entre bloques y, lo más valioso, un registro continuo de las pequeñas lecciones aprendidas durante la validación. Individualmente, estas lecciones son insignificantes. En conjunto, marcan la diferencia entre que el vigésimo quinto bloque supere la validación sin problemas y que cada bloque vuelva a activar el mismo cable que el primero detectó. Cada lección se aprendió ejecutando las comprobaciones reales y leyendo el error real, para luego anotarlo en el lugar donde se encontraría en la siguiente sesión. Las habilidades y el archivo de plan permitieron que ese conocimiento se acumulara en todo el registro en lugar de desvanecerse al finalizar cada sesión.

En pocas palabras, no se le pidió al asistente de IA que improvisara. Se le proporcionó información documentada sobre este tipo de trabajo, un servicio de búsqueda para que pudiera consultar la información existente antes de proponer nada, y un cuaderno que actualizaba constantemente para que la lección aprendida el lunes siguiera vigente el viernes. Esta combinación es la razón por la que el trabajo es lo suficientemente fiable como para publicarlo, y además es público, por lo que el próximo proyecto tampoco parte de cero.

¿Qué hay en el registro hoy?

Todo lo publicado y validado, bajo el ogc.heritage. prefijo. objeto patrimonial, lugar y actor transportar las entidades principales. sitio patrimonial, edificio y espacio arquitectónico son la cadena que ha estado siguiendo esta publicación. conjunto de datos de la encuesta y evaluación de la condición cubrir el trabajo realizado en un sitio, historia oral y declaración histórica Las cosas que se dicen sobre él y los envolventes de características hacen que cualquiera de ellos sea un objeto geoespacial de primera clase. El resto, de umbral de monitorización a ruta, están en el registro. 

Cada bloque se basa en los estándares que utiliza, generalmente CIDOC-CRM, CRMdig, CRMsci, PROV-O o EDM, y muchos de ellos en varios a la vez. Cada bloque tiene un esquema validado, un mapeo semántico, reglas de validación de grafos donde introduce sus propias restricciones y al menos dos ejemplos, la mayoría basados ​​directamente en datos piloto de Venaria o Malta. Puede consultarlos todos en ogcincubator.github.io/bblocks-heritage.

Esta no es una receta exclusiva de tradición.

Si tu problema se plantea como “Tengo un caso de uso y algunos datos, y necesito modelarlo, validarlo, asignarlo a algo (especialmente semántica) y posiblemente transformarlo”, el mismo camino se aplica independientemente del dominio: 

• Un ejemplo práctico a escala real.: bloques-patrimonio (fuente), cadenas de perfiles, reglas de validación, ejemplos y todo lo demás. 

• Las habilidades, listas para instalar: Habilidades del programa OGC LLM (fuentePublica las funcionalidades de creación y consumo, listas para que usted o su asistente las instalen. Funciona con claude.ai, Claude Code y la API de Claude. 

• El marco: el Documentación de OGC Blocks Explica el procedimiento y cómo crear tu propio registro. 

El método en pocas palabras: auditar lo que ya existe antes de modelar nada, asignar los requisitos a los estándares antes de asignarlos a los esquemas, modelar y validar una pieza a la vez con datos reales, y documentar cada lección no obvia para que solo cueste una vez. Es un ciclo iterativo, no una especificación entregada de una sola vez. Un asistente de IA con las habilidades de dominio adecuadas agiliza ese ciclo, lo que hace que iterar con este nivel de detalle sea asequible. No reemplaza el ciclo. 

Para HERITALISE, este proceso transformó los requisitos de prosa de sitios patrimoniales reales en un modelo de datos público: 27 bloques, cada uno basado en estándares en los que la comunidad ya confía, con su propia validación y semántica, y diseñado para integrar los aspectos geoespaciales y BIM en lugar de ignorarlos. Los recursos, herramientas y servicios que lo hicieron posible (las habilidades, el servicio de búsqueda, el método en sí) están publicados, probados en un dominio real y a la espera del siguiente.