Interoperabilidad de datos en SSI (II)

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:

• Notation3 (N3)
• Turtle
• N-Triples
• N-Quads
• RDF/XML
• JSON-LD

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): Podemos extraer las partes comunes de las URIs expuestas y agruparlas en torno a prefijos, dando a lugar el siguiente documento:

@prefix dbpedia: http://dbpedia.org/page/ . 
@prefix dbp: http://dbpedia.org/property/ . 
@prefix dbo: http://dbpedia.org/ontology/ .
@prefix xsd: https://www.w3.org/2001/XMLSchema# .

dbpedia:Nikola_Tesla
    a dbo:Person ; 
    dbp:name "Nikola Tesla" ; 
    dbo:birthDate "1856-07-10"^^xsd:date ;
    dbo:birthPlace dbpedia:Smiljan .

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:

{
    "@id": "dbpedia:Nikola_Tesla",
    "@context": {
        "dbpedia": "http://dbpedia.org/page/",
        "dbp": "http://dbpedia.org/property/",
        "dbo": "http://dbpedia.org/ontology/",
        "xsd": "https://www.w3.org/2001/XMLSchema#"
    },
    "@type": "dbo:Person",
    "dbp:name": "Nikola Tesla",
    "dbo:birthDate": {
        "@value": "1856-07-10",
        "@type": "xsd:date"
    },
    "dbo:birthPlace": "dbpedia:Smiljan"
}

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«:

{
    "@id": "http://foobar.com/Peter",
    "@context": {
        "ex": "http://example.com/ns#",
        "sh": "http://www.w3.org/ns/shacl#",
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "foaf": http://xmlns.com/foaf/0.1/
    },
    "shacl": {
        "@type": "sh:NodeShape",
        "sh:targetClass": {
            "@id": "ex:Person"
        },
        "sh:property": [
            {
                "sh:path": {
                    "@id": "foaf:age"
                },
                "sh:datatype": {
                    "@id": "xsd:integer"
                },
                "sh:maxCount": 1,
                "sh:minCount": 1
            }
        ]
    },
    "ex:Peter": {
        "@type": "ex:Person",
        "foaf:age": 20
    }
}

Conclusiones

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.