Copyright © 2015 Open Geospatial Consortium.
7 Another alternative approach is to define the classes in UML and map them to
JSON-LD data types declarations. The next subclauses in this ER explore these three possibilities. Please note that
GeoJSON already defines classes in a document another less structured alternative even if it does not provide an structured way of doing this such as schemas or UML. There is a
long tradition to impose data models to geospatial information. For example, the INSPIRE directive for the creation of European SDI provides a list of datasets that need
to be available at the European level classified in three Annexes. For each dataset e.g Cadastral parcels from Annex I, Land Cover from Annex II, and Energy resources from
Annex III a data model encoded in UML, Feature Catalogue and GML has been provided and agreed to in a thematic working group. Being able to define classes and
complex data types in a JSON encoding for features seems almost unavoidable.
5.2 JSON schema
A JSON schema is a document that defines the structure of JSON data. The Internet media type is applicationschema+json. JSON Schema defines what JSON keys are
expected and the type of data values for a given application. JSON Schema is intended for semantic validation and documentation of data models. JSON schema acts in a similar
way to XSD for a XML file. Indeed, some applications such us XML Validator Buddy are able to combine a JSON file with its corresponding JSON schema to test and validate
if the content of the JSON file corresponds to the expected data model. Unfortunately, the level of control that JSON Schema provides is not as strict as XML Schema. The main
problem lies in the fact that JSON objects are considered extendable by default. This means that adding attributes not specified in the schema does not give you an error. This
prevents detecting object or attribute names with typos that are confused with extended elements except if they are declared as mandatory. Another difference is that JSON
attributes are not supposed to have order so the order of the attributes of an object cannot be validated. In many cases this is not a problem since most of the data models used in
the OGC do not depend on the other properties even if the XML “tradition” has imposed this unnecessary description.
NOTE: The fact that XML “sequence” imposes an order makes more complicated the validation of an Atom or a KML files by design, both formats have their properties unsorted. This resulted in the use of
RelaxNG and XSD 1.1 languages respectively for validating them or to use the “choice” alternative to “sequence” as suggested by others.
If we suppose that all rivers share the same data model, the previous JSON instance example, can be validated against a JSON Schema like this:
{ schema: http:json-schema.orgdraft-04schema,
title: JSON minimal example, description: Schema for the minimal example that is a
river, type: object,
required: [ River ], items: {
8
Copyright © 2015 Open Geospatial Consortium.
title: Minimal River, type: object,
required: [ name ], properties: {
name: { type: string
}, length: {
type: number, minimum: 0,
uom: km },
discharge: { type: number,
minimum: 0, uom: m3s
}, source: {
type: string },
mouth: { type: string
}, country: {
type: string },
bridges: { type: array,
items: { type: string
} }
} }
}
An interesting thing about JSON Schema is that it is also written in JSON but using a predefined data model. This makes JSON Schema automatically extendable. We are
using this property to extend the properties describing some of the attributes of the river already adding in the example a key uom that allows us to specify the units of measure
of the numeric values of the length and discharge attributes. This could be useful for better defining feature types.
Recommendation 1: Consider extending JSON schema to fully describe the properties of a feature type, including units in alphanumeric properties and CRS in the geometric attributes instead of
