Communication with SSS services requires the use of JSON-LD format. JSON-LD can be used to express resources and relations between them (so called Linked Data concept).
Excerpt from https://www.w3.org/TR/json-ld/#introduction:
JSON-LD is a lightweight syntax to serialize Linked Data in JSON [RFC4627]. Its design allows existing JSON to be interpreted as Linked Data with minimal changes. JSON-LD is primarily intended to be a way to use Linked Data in Web-based programming environments, to build interoperable Web services, and to store Linked Data in JSON-based storage engines. Since JSON-LD is 100% compatible with JSON, the large number of JSON parsers and libraries available today can be reused. In addition to all the features JSON provides, JSON-LD introduces: •A universal identifier mechanism for JSON objects via the use of IRIs, •A way to disambiguate keys shared among different JSON documents by mapping them to IRIs via a context, •A mechanism in which a value in a JSON object may refer to a JSON object on a different site on the Web, •the ability to annotate strings with their language, •A way to associate data-types with values such as dates and times, •And a facility to express one or more directed graphs, such as a social network, in a single document. |
Note: •Every JSON-LD document is technically a plain JSON document, but not every JSON document is a JSON-LD document. JSON-LD adds some constraints on how it should look and how it should be processed. •Multiple JSON-LD documents may represent exactly the same information. If JSON-LD document is received from external system it should be always pre-processed (re-compacted) before use. |
Warning: For Fines application: to be compliant with FNMS specification, the caller must use accept and content-type HTTP header fields to use JSON format in request and response |
JSON-LD documents contain:
•Resources, identified with an @id, that are linked together in JSON-LD hypermedia links
•Resources have their own attributes/properties, that may be scalar values (string, data, numbers, boolean...), tables of those, objects (without identifiers) and arrays of objects. Objects include other properties.
•JSON-LD document represents graph built from objects and properties. Technically, properties are represented by JSON keys, nodes are represented by JSON values. Properties (JSON keys) must be defined as IRIs or as blank node identifiers.
IRIs are only used to uniquely identify things and they should be never parsed. The structure of an IRI can change at times without notice. |
Every node has its type defined implicitly or explicitly (through the "@type" property). This type is defined by an IRI and usually can be dereferenced to see detailed schema definition (e.g., https://schema.org/Person).
JSON-LD supports internal representation, But schema.org and schema.parkeon.com do support inheriting from such internal representation and request to specify inheritance from Classes. StreetSmart BO has chosen a default mapping to use JSON-LD internal representation:
•sc:Text refers to string
•sc:Boolean refers to boolean
•sc:Integer refers to integer
•sc:Number refers to number
In consequence, aliases contained in JSON-LD context (server side) should NOT refer these classes.
For example: even if https://schema.org/unitText is defined as sc:Text, server-side context will only contain an alias on a name but no @type element.
Every node has its identifier defined explicitly (through “@id” property). This identifier (IRI) can be dereferenced and is, therefore, an URI.
Note: •There is no requirement that a node must declare all fields defined in the related schema (and usually this is not the case) •Node content is not limited to fields defined in the schema. Other fields can be added as long as they don't collide with defined ones. |
