JavaScript Object Notation for Linked Data es un método basado en JSON para añadir datos estructurados, completando la anotación JSON con elementos de contexto de forma que se puedan entender las relaciones semánticas que le dan sentido.
Plataforma da un soporte inicial sobre sus ontologías, pudiendo recoger o insertar los datos vía API Rest en formato JSON-LD, indicando el contexto deseado. De esta forma, los datos insertados en las ontologías podrán devolverse en formato JSON normal, o con su contexto.
Como Schema.org ofrece una gran gama de esquemas estandarizados para datos estructurados, el soporte actual de plataforma es frente a sus contextos. De esta forma, si desea que una ontología soporte el formato JSON-LD debe marcar el check correspondiente en la creación o edición de la ontología, además de informar su contexto.
En la creación paso a paso, se abrirá un árbol con todas las estructuras que ofrece Schema.org, pudiendo hacer selección múltiple manteniendo pulsada la tecla Ctrl mientras selecciona. Una vez se pulse el botón continuar, se rellenarán los datos de la ontología con las propiedades definidas para ese esquema (https://schema.org/docs/full.html).
La estructura de la ontología se creará con las propiedades definidas para cada clase de Schema.org, de esta forma, si desea incluir las propiedades de Persona a Paciente, será necesario seleccionar las dos, si no sólo se añadirán las correspondientes a Paciente.
Además, es necesario tener en cuenta que el tipo de dato de cada propiedad será String en el caso de ser otra clase del esquema y no ser un tipo de dato simple como string, number, integer, date, boolean, etc. De esta forma, se podrá referenciar al id correspondiente con el dato de otra ontología que cumpla dicho esquema. Por ejemplo, en Schema.org Person tiene un campo address que puede ser de tipo Texto (simple) o de tipo PostalAddress que es otra clase definida en Schema.org. En este caso el esquema de la ontología se formará permitiendo introducir un texto, que podrá ser el identificador de la dirección introducida en bbdd en otra ontología que cumpla el esquema de PostalAddress, teniendo así la relación dirección-persona.
Si necesita que sea un objeto, tendrá que editarlo en esta pantalla y definirlo tras dar al botón de Update Schema.
En el resto de creaciones de ontologías, time series, api rest, etc. el contexto se podrá indicar introduciendo el texto directamente. De esta forma será necesario definirse las propiedades manualmente en la siguiente pantalla.
Si desea editar la ontología una vez creada, debe tener en cuenta que el contexto no se podrá editar, ya que sería necesario cambiar la estructura completa de la ontología. Los cambios que podrá hacer serán añadir o eliminar propiedades, además del resto de cambios propios de la ontología.
Una vez tengamos creada nuestra ontología, pasaremos a crear un API con las operaciones básicas GET y POST. De esta forma, podremos seleccionar desde el swagger generado, o vía Postman por ejemplo, el tipo de dato que enviamos o deseamos recibir.
Si nuestra ontología soporta formato JSON-LD, se podrá insertar datos en dicho formato, al igual que en formato JSON normal, indicándolo siempre en el Request body ("Content-Type: application/ld+json").
En las operaciones de GET, habrá que indicarlo en la respuesta ("accept: application/ld+json").
En el caso en el que la ontología no soporte el formato JSON-LD, el API devolverá un error 406 Not Acceptable.
De esta forma, los datos se devuelven con el formato deseado, indicando el contexto de forma extendida y el tipo de dato usado (@type).
[
{
"http://schema.org/_id": [
{
"http://schema.org/$oid": [
{
"@value": {
"chars": "62061c2ae3cdeb27d2212c31",
"string": "62061c2ae3cdeb27d2212c31",
"valueType": "STRING"
}
}
]
}
],
"@type": [
{
"chars": "http://schema.org/Person",
"string": "http://schema.org/Person",
"valueType": "STRING"
}
],
"http://schema.org/email": [
{
"@value": {
"chars": "info@example.com",
"string": "info@example.com",
"valueType": "STRING"
}
}
],
"http://schema.org/image": [
{
"@id": {
"chars": "janedoe.jpg",
"string": "janedoe.jpg",
"valueType": "STRING"
}
}
],
"http://schema.org/jobTitle": [
{
"@value": {
"chars": "Research Assistant",
"string": "Research Assistant",
"valueType": "STRING"
}
}
],
"http://schema.org/name": [
{
"@value": {
"chars": "Jane Doe",
"string": "Jane Doe",
"valueType": "STRING"
}
}
],
"http://schema.org/contextData": [
{
"http://schema.org/user": [
{
"@value": {
"chars": "administrator",
"string": "administrator",
"valueType": "STRING"
}
}
],
"http://schema.org/timezoneId": [
{
"@value": {
"chars": "UTC",
"string": "UTC",
"valueType": "STRING"
}
}
],
"http://schema.org/timestamp": [
{
"@value": {
"chars": "2022-02-11T08:19:54Z",
"string": "2022-02-11T08:19:54Z",
"valueType": "STRING"
}
}
],
"http://schema.org/timestampMillis": [
{
"@value": {
"integral": true,
"valueType": "NUMBER"
}
}
],
"http://schema.org/source": [
{
"@value": {
"chars": "INTERNAL_ROUTER",
"string": "INTERNAL_ROUTER",
"valueType": "STRING"
}
}
]
}
]
}
]
Mejoras en el soporte JSON-LD
El siguiente paso en el soporte de JSON-LD será poder crear en plataforma nuestro propio diccionario, no dependiendo así de Schema.org.
Para tener nuestras propias definiciones de esquemas, generaremos un nuevo tipo de Data Model donde guardar el esquema en formato JSON-LD. Además, para exponerlo tendremos que crear un API Rest que devuelva el contexto de estos esquemas, alojándolo en /cotrolpanel/json-ld/nombreDelEsquema, por ejemplo.