Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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.

Para ello, es necesario marcar el check que indica que soporta JSON-LD en la creación o edición de la ontología, además de informar su contexto. En este caso el esquema utilizado forma parte del diccionario de Schema.org en el cual se encuentra todo tipo de datos (types) que pueden utilizarse.

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á crear el esquema de la ontología a partir del contexto seleccionado, pudiendo seleccionar los campos que necesitamos de cada clase.

Para ello, los campos cuyo tipo de dato sea otra clase del esquema, y no un tipo de dato simple como texto, numérico, etc., se guardarán referenciándolos con ids para así tener la relación con el dato de la 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.

En primer lugar, el soporte que se va a dar es con Schema.org, ya que ofrece una gran base de datos de esquemas estandarizados, ofreciendo un gran diccionario que comprende muchos tipos de datos, además de las propiedades subordinadas a cada tipo. Una vez tengamos dicho soporte, el siguiente paso será poder crear en plataforma nuestro propio diccionario.

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.

  • No labels