Serialization

Currently, the library outputs JSON-LD corresponding the the compacted format. Since version 0.10.0, it is possible to select whether the output will contain @context or whether the serializer will use full IRIs as attributes of the JSON object. The two corresponding classes are:

• cz.cvut.kbss.jsonld.serialization.CompactedJsonLdSerializer
• cz.cvut.kbss.jsonld.serialization.ContextBuildingJsonLdSerializer

Data properties are serialized as attribute values, object properties are serialized as embedded objects. If an instance is referenced in multiple places, only the first occurrence is written as a full JSON object, other occurrences are serialized as IRIs of the instance.

Context-based Serialization

Serialization with context is more favorable with respect to legacy clients that may not support JSON-LD. In that case, the output is a regular JSON with an additional @context attribute that the client may safely ignore.

Several configuration options are available for context-based serializer.

Serialization of Individuals as String

By default, an individual (value of an attribute of type URI/URL/String or an enum constant mapped to an individual) is serialized as an object with a single attribute - @id as follows:

{
  "@context": {
    "reference": "http://purl.org/dc/terms/references"
  },
  "reference": {
    "@id": "http://example.org/A"
  }
}

However, the serializeIndividualsUsingExpandedDefinition parameter can be used to tell JB4JSON-LD to serialize such references as plain string with an expanded term definition in the context. The output looks as follows:

{
  "@context": {
    "reference": {
      "@id": "http://purl.org/dc/terms/references",
      "@type": "@id"
    }
  },
  "reference": "http://example.org/A"
}

Literals

Literal values (int, boolean, double, date etc.) are always serialized as JSON-LD typed literals, i.e., they are always serialized as JSON objects with @type and @value. If the context-based serializer is used, the type is specified in term definition in the context, for example,

{
  "@context": {
    "intValue": {
      "@id": "http://krizik.felk.cvut.cz/ontologies/jb4jsonld/intValue",
      "@type": "http://www.w3.org/2001/XMLSchema#int"
    }
  },
  "intValue": 1234
}

There is one important point to note: the JSON-LD specification (and most other JSON-LD documentation) shows the value part of typed values as a JSON string. This is more aligned with how RDF views literals - having a datatype and a lexical part.

At the same time, the specification does not forbid using native JSON types like boolean and number as a value in typed values. JB4JSON-LD uses this approach and when possible, uses native JSON types for literal values in order to simplify integration with JavaScript. Were it to use the string-based approach, all literal values would be strings and the application would have to examine the datatypes to determine if it can/should transform the value to a native type. This can be seen in the example above, where the value of the intValue is a JSON number instead of a JSON string.

For more details, see Bug #81 and my SO question regarding this issue.

Deserialization will work with string-valued typed values as long as they can be parsed as the target type.