Este segundo artículo es una continuación del anterior Interoperabilidad de datos en SSI (I), y en esta ocasión nos centraremos en la forma y sintaxis con la que estructuramos los datos enlazados en nuestros sistemas.
Para ello, veremos las diversas notaciones o serializaciones que existen para representar los datos en RDF, así como las estrategias para mejorar la legibilidad de estos por personas. Finalmente pondremos en valor un enfoque para validar los datos en RDF en base a un esquema, lo que permitirá comprobar la adecuación de los datos gestionados en las aplicaciones que hagan uso de Certix Identity.
Homogeneizando los datos: Notaciones y espacios de nombres
A la hora de registrar conjuntos de datos en RDF, existen diversas serializaciones entre las que podemos elegir. Cada una de ellas tiene una sintaxis particular, generando una amplia variedad de formatos y verbosidad de las representaciones. La traducción de documentos en diferentes serializaciones no debería incurrir en una pérdida de información.
Entre las serializaciones más habituales encontramos:
Estas serializaciones permiten la persistencia de los datos en ficheros o «triplestores» (almacenes de datos en RDF), de forma que puedan ser registrados, recuperados y consultados por aplicaciones desarrolladas a tales efectos.
A menudo, para aumentar la legibilidad de los datos en las diversas serializaciones, se recurre a simplificar las URIs utilizando para ello «namespaces» o espacios de nombres. La idea principal es sustituir los prefijos o raíces comunes de las URIs presentes en una serie de tripletas por un término más corto y fácil de usar.
Por ejemplo, si tenemos el siguiente documento en Turtle (una de las notaciones más simples para RDF):
Nota: El namespace http://www.w3.org/1999/02/22-rdf-syntax-ns# suele representarse mediante el prefijo «rdf«, y la combinación resultante de «rdf:type» posee un alias que permite expresarlo como «a«.
Este segundo documento simplifica el contenido, haciéndolo más compacto y fácil de compartir. Al ser la sustitución de términos reversible, podemos volver a generar el documento original de forma sencilla, y gracias a la resolución de las URIs hacer entendible el contenido a través de la desreferenciación de términos.
JSON-LD, la serialización de RDF para la Web
Una de las sintaxis para RDF más recientes y con mayor potencial de adopción es JSON-LD. Inicialmente diseñado para que los desarrolladores pudieran intercambiar información de forma sencilla a través de la web de forma interoperable, su especificación ha evolucionado de forma que permite la semantización de los datos al igual que sus notaciones homólogas.
Como su propio nombre indica, JSON-LD se basa en el estándar de JSON, aprovechando sus principales ventajas:
Su sintaxis es simple, facilitando lecturas y escrituras.
Es trivial trabajar con JSON en la mayoría de lenguajes de programación modernos, existiendo numerosas librerías para su procesamiento.
Es un formato nativo en la Web, ideal para el intercambio de información.
Las características principales que diferencian un documento JSON-LD son:
Uso de palabras reservadas en las claves que comienzan por el carácter «@«
Provisión de un identificador único para cada documento a través de la propiedad «@id«
Especificación de los vocabularios empleados utilizando los decoradores «@context» o «@vocab«
Los valores textuales pueden llevar asociado el lenguaje en el que están expresados (language strings)
Se pueden representar más tipos de datos a los nativos de JSON
Permite el uso nativo de listas y objetos como valores de una propiedad
Si recuperamos la descripción de Nikola Tesla en la sintaxis de Turtle, podemos generar el documento JSON-LD equivalente con el siguiente resultado:
Este documento cumple al 100% con la sintaxis de JSON, y puede ser procesado como tal. No obstante, existen librerías especializadas en la gestión de JSON-LD para diferentes lenguajes de programación.
Estas librerías permiten aplicar los algoritmos de procesado de la especificación (compactación, expansión, allanado y enmarcado) a los documentos, de forma que se aprovecha el potencial semántico embebido en los datos.
Integrando RDF y SSI: Uso de JSON-LD en la comunicación entre agentes
La comunidad de Hyperledger Aries (el framework Open Source que empleamos en nuestra solución de Certix Identity), especifica en el RFC 0047 su apuesta por el uso de JSON-LD en la definición de un DIDComm, es decir, en el protocolo de intercambio de mensajes entre agentes del sistema.
Su objetivo es asegurar que la estructura de un DIDComm es compartida por las entidades involucradas, controlando el versionado del protocolo utilizado y acordando una serie de campos que necesitan estar presentes en la comunicación.
Sin embargo, no se hace ninguna referencia a la necesidad de añadir descripciones semánticas a dichos mensajes. Simplemente se reserva un namespace (https://didcomm.org/) para relacionar los conceptos reflejados en el mensaje, sin que la URI pueda ser desreferenciada para consultar su definición.
Actualmente, nuestra apuesta se basa en utilizar JSON-LD no solo para definir la estructura de los mensajes (el continente), si no para marcar el contenido del mensaje en sí, es decir, su payload.
Así, la aplicación que recibe el mensaje tiene toda la información necesaria para su comprensión, lo que le permite procesarlo de una forma más inteligente, facilitando la interoperabilidad de la información a la vez que mejora su utilidad.
Verificando la estructura de los datos a través del esquema
Con el contenido de los mensajes anotado semánticamente y haciendo uso de las buenas prácticas de la comunidad, podemos mejorar sensiblemente la gestión de estos datos, permitiendo que las aplicaciones que hagan uso de los mismos los exploten de formas innovadoras.
No obstante, en entornos en los que se desee controlar el contenido de los mensajes para que sigan un modelo de datos determinado (abierto, pero bien estructurado), nos encontramos con uno de los eslabones más débiles de Linked Data. Es fácil que un documento sintácticamente correcto no haga un buen uso de las definiciones ontológicas que utiliza.
Los recursos destinados a solucionar esta situación han sido tradicionalmente escasos, pero actualmente contamos con varias propuestas viables.
De forma similar a cómo JSON-schema provee de una documentación formal para validar una estructura de datos en JSON, existen alternativas para definir estos esquemas sobre documentos RDF.
Una de estas propuestas es SHACL (Shapes Constraint Language), una especificación de la W3C que describe un lenguaje que tiene por objetivo validar documentos RDF en base a una serie de condiciones.
Para ello, se define una forma o esquema que define la forma que los datos tienen que adoptar para satisfacerla, pudiendo especificar la obligatoriedad de que ciertas propiedades estén presentes, el tipo de datos que los valores pueden tomar, restricciones en el número máximo y mínimo de elementos descritos, etc.
Al ser un documento RDF más, éste puede serializarse en cualquiera de los formatos vistos anteriormente. Incluso podemos adoptar la misma estrategia y generar un documento JSON-LD.
De hecho, nuestra propuesta actual se basa en adjuntar la definición del esquema junto a los datos en un mismo documento JSON-LD. Para ello, añadimos una propiedad extra al documento cuyo valor será la definición de la forma, y a la hora de procesar el documento se extrae dicho esquema para validar los datos contra ellos.
Un ejemplo, podría ser la verificación del siguiente documento, el cual sigue los datos expresados en la propiedad «shacl«:
En estos dos artículos hemos visto como las iniciativas de Self Sovereign Identity pueden beneficiarse de las ideas de la Web Semántica, haciendo que los usuarios no solo recuperen el control de sus datos sino que además los preparen para que estos sean comprensibles e interoperables.
La inclusión de anotaciones RDF en el contenido de los mensajes permiten que estos sean entendibles por las aplicaciones receptoras, de forma que se universaliza su utilidad de forma transparente para todos los actores del sistema.
Los conceptos presentados han sido resumidos y simplificados con la intención de servir como un primer acercamiento a las tecnologías que forman parte de Certix Identity. Si estás interesado en profundizar en algún aspecto, o tienes dudas/sugerencias sobre lo expuesto, no dudes en dejarnos un comentario o ponerte en contacto con nosotros.
Utilizamos cookies de propias y de terceros para recoger información sobre el uso de nuestro sitio web. Al hacer clic en "Aceptar", acepta el uso de TODAS las cookies. Política de cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duración
Descripción
cookielawinfo-checbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.