Halconia.
Hablemos
Volver al blog

Qué son los grafos de conocimiento aplicados a la fabricación

En este artículo, usamos grafo de conocimiento aplicado a la fabricación como definición de trabajo para una representación de entidades y relaciones con un…

Andrés Naves ·

Qué son los grafos de conocimiento aplicados a la fabricación

En este artículo, usamos grafo de conocimiento aplicado a la fabricación como definición de trabajo para una representación de entidades y relaciones con un significado documentado mediante vocabularios; la explicaremos con RDF, un modelo de datos que permite formular afirmaciones sobre recursos y combinarlas con vocabularios o convenciones que aportan información semántica (RDF Primer).

En nuestro ejemplo hipotético, la máquina M y el componente C serán recursos físicos, y un documento con dos revisiones, D1 y D2, aportará los recursos documentales que relacionaremos mediante triples RDF.

Empieza por la base en nuestro artículo anterior: Por qué integrar conocimiento operativo en sistemas de automatización industrial

¿Qué es un grafo de conocimiento aplicado a la fabricación y cómo representa máquinas, componentes y documentos?

Los triples RDF tienen tres elementos: sujeto, predicado y objeto. El sujeto y el objeto representan los dos recursos relacionados, mientras que el predicado expresa la naturaleza de su relación (RDF Primer).

Nuestro primer triple hipotético es Máquina M — incorpora — Componente C: la máquina es el sujeto, incorpora es el predicado y el componente es el objeto.

El segundo triple hipotético es Componente C — tiene documentación — Revisión D2: el componente es el sujeto, tiene documentación es el predicado y la revisión actual del ejemplo, D2, es el objeto. En este modelo RDF, hemos elegido incorpora y tiene documentación como convenciones locales del ejemplo, no como términos industriales normalizados.

Al visualizar estos triples como grafo, sus sujetos y objetos forman los nodos y sus predicados forman los enlaces: el componente compartido conecta la máquina con la revisión documental.

¿Cómo acordamos identificadores y vocabulario sin confundir una entidad con sus distintas revisiones?

Los IRI son identificadores globales de recursos (RDF Primer). El propietario de un IRI puede documentar qué pretende designar con él; en nuestro ejemplo hipotético, esa especificación distinguiría la máquina, el componente, el documento persistente y cada revisión documental mediante sus respectivos identificadores (RDF Concepts).

Siguiendo la distinción que ilustra PROV-O, en nuestro modelo cada revisión tiene su propio identificador y ambas son formas concretas de un documento persistente con una referencia común (PROV-O).

PROV-O define una revisión como una derivación cuyo resultado es una versión revisada de una entidad original. Aplicamos esa definición mediante prov:wasRevisionOf: la revisión actual es el sujeto de esta relación y la revisión anterior es su objeto (PROV-O).

La propiedad prov:specializationOf relaciona una entidad más específica con otra cuyos aspectos comparte en su totalidad. La aplicamos a cada revisión respecto al documento persistente cuando ambas versiones se modelan como formas más específicas de ese mismo documento, siguiendo la distinción que ilustra PROV-O.

W3C recomienda asignar identificadores a las versiones y a la serie completa de un conjunto de datos; en nuestro ejemplo aplicamos esa separación al documento como decisión de modelado (Data on the Web Best Practices).

Antes de crear identificadores, proponemos buscar otros adecuados que ya existan; si necesitamos crear nuevos, seguiremos los patrones de persistencia de URI recomendados por W3C (Data on the Web Best Practices).

Según W3C, conviene reutilizar términos de vocabularios compartidos, preferiblemente estandarizados, para codificar los datos y los metadatos.

¿Cómo registramos de dónde viene una afirmación sin convertir su procedencia en una garantía de verdad o de permiso de uso?

PROV-O permite construir cadenas de procedencia con entidades y actividades: una actividad puede utilizar unas entidades y generar otras. En nuestro ejemplo, una actividad de consulta utiliza la revisión actual y genera un registro que contiene la afirmación documental sobre el componente (PROV-O).

La actividad se relaciona con la revisión mediante prov:used, mientras que el registro se relaciona con la actividad que lo generó mediante prov:wasGeneratedBy. En nuestro ejemplo, prov:wasDerivedFrom relacionaría el registro con la revisión documental de la que se deriva; PROV-O define la derivación como la transformación de una entidad en otra (PROV-O). Para indicar responsabilidad, prov:wasAssociatedWith asocia la actividad con un agente y prov:wasAttributedTo atribuye la entidad generada a un agente.

En nuestro modelo, estas propiedades describen la generación y atribución del registro como entidad; no hemos modelado la procedencia de cada triple por separado. Tampoco basta con nombrar un grafo: RDF no establece restricciones formales sobre el recurso que ese nombre designa ni sobre su relación con el grafo (RDF Concepts).

Para interpretar el nombre de un grafo como fuente de sus datos, los lectores necesitan una convención adicional, porque RDF no ofrece una forma estándar de transmitir esa suposición semántica (RDF Primer).

La referencia a las fuentes primarias permite investigar la fiabilidad de una fuente derivada, según PROV-O. Además, las inferencias lógicas de RDF parten de triples que el sistema acepta como verdaderos: una conclusión derivada conserva esa dependencia de la información de entrada.

Para revisar el permiso de uso en nuestro piloto, consultaremos la licencia aplicable además de registrar la atribución. W3C recomienda facilitar un enlace o una copia del acuerdo de licencia que regula el uso de los datos. En este ejemplo revisaremos por separado la licencia, las reglas de acceso y la aprobación técnica de una intervención. En nuestro modelo, definimos el predicado documental únicamente para enlazar el componente con una revisión; la vigencia, la aplicabilidad y la aprobación de esa revisión quedan fuera del significado que le hemos asignado.

¿Cómo acotamos un piloto y qué comprobamos antes de ampliarlo?

En este piloto hipotético revisamos la representación de las relaciones y la coherencia semántica de los triples.

Una primera consulta recorrería los triples que relacionan la máquina con el componente y este con la revisión documental, siguiendo sus sujetos, predicados y objetos. Otra seguiría las relaciones de procedencia desde el registro hasta la actividad que lo generó y la entidad que esa actividad utilizó.

Para revisar las versiones, leeríamos la relación prov:wasRevisionOf entre la revisión actual y la anterior, manteniendo separados sus identificadores del correspondiente al documento persistente. La lectura conjunta de esas relaciones debe conservar un significado acordado: el RDF Primer explica que reunir información con una sintaxis común no basta para mantener su coherencia semántica.

Dejamos fuera del alcance de este piloto hipotético la comprobación física del componente instalado, la aplicabilidad de una revisión a una intervención y las condiciones de uso; proponemos tratarlas por separado mediante una revisión de ingeniería y de la licencia aplicable.

Comprobaciones del piloto hipotético

  • Comprobar que las referencias a la misma entidad utilizan el mismo identificador en los conjuntos conectados.
  • Revisar el significado acordado de los triples, además de su sintaxis.
  • Comprobar que el historial explica los cambios entre versiones.
  • Verificar que una aplicación puede procesar la información de procedencia.
  • Comprobar que se facilita la licencia que regula el uso de los datos.
  • Documentar la calidad conocida y los problemas detectados en los metadatos.

Fuentes