# JSON Schemas with Semantic Annotations Supporting Data Translation
## 4 Proposed Annotation Mechanisms for JSON Schemas
### JSON Schema with Complement Data Values  
When two heterogeneous systems interact through JSON messages, the consumer not only has to understand the provider messages, which can be supported by the proposed semantic annotations, but also has to receive all of the required information. However, when these systems are not custom-built, the transmitted information may be insufficient. For example, when integrating a legacy temperature device (the provider system), which sends JSON messages only with temperature values and units, is required, a consumer system needs to know not only the temperature value but also the location of that temperature sensor. Besides receiving all of the required information, the consumer needs to understand the provider's data values syntax. For example, a consumer expects to receive, as temperature units, a string with the value \"Cel\" (Celsius) or \"Fahr\" (Fahrenheit), but the provider uses a different syntax (\"C\" or \"F\"). To address the presented interoperability issues, in this paper, an annotation mechanism is also proposed to add complement data to JSON Schemas similar to the existing one [5] for XML Schema, enabling interactions between heterogeneous systems. We extend JSON Schemas with A3 ST attribute names. A3 ST is a proposal for adding complement data values to an existing XML Schema [4] that was extended in [5]. This information can be useful for facilitating compatibility between heterogeneous systems, broadening the range of systems/devices that can communicate with each other. The proposal for inserting such annotations on a JSON Schema is by creating an a3 st array at the JSON Schema root level, which will have as properties the following objects:  
* for adding complement data;
* Property \"property\" is the semantic annotation of the OWL datatype property to be inserted;
* Property \"value\" is the value of the property attribute;
* \"**map-data-ind\"** for mapping a concrete syntax which is used by a certain provider or consumer;Property \"individual\" identifies the individual of a concept;
* Property \"mid-id\" defines an id for each element, it is a reference attribute;
* Keyword \"mid-ref\" makes a reference for the \"map-data-ind\" element with the matching \"mid-id\". A complete annotated schema for the instance in Listing 1, which is from a provider device, is shown in Listing 4. As exemplified before, the provider device only sends a temperature value and a string with the temperature units, whereas let us assume that a consumer system also needs location values as well as to understand the syntax of the units. Focusing on the temperature unit property, assuming that the provider sends a string with the value \"Cel\" (Celsius) or \"Fah\" (Fahrenheit) but the consumer expects a \"C\" or \"F\", two things are needed: an annotation that relates the output syntax with the ontology meaning and a reference from the property to that annotation. As proposed, this annotation is a \"map-data-ind\" since it maps the syntax according to its ontology meaning. In lines 5 and 12 of Listing 4, two possible outcomes are shown (these could be as many as needed). The items of lines 5 and 12 have a property called \"a3 st:mid-id\", of which the purpose is to be referenced later; have a property called \"a3 st:individual\" pointing to the ontology individual, bringing a known term for all systems; and have a property called \"a3 st:node-value\" which is the string that can be expected from the current system. While having an annotation describing the meaning of a string output, it needs to be related to the property that will send this value. In line 42, the keyword \"mid-ref\" points to every possible outcome of that property (\"units\"). All of the links exist to interpret as many pre-set strings as the system might have. Regarding the location that is required by the consumer but not provided by the provider, the creation of an object is proposed to add complement data to the schema: \"data-property-value\".