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
having to repeat them in each instance. Target: OWS Common
Copyright © 2015 Open Geospatial Consortium.
9 Unfortunatelly, JSON schema is a IETF draft that expired in August 2013 and the future
of the specification is uncertain. Fortunatelly there is still some activity in the blogs associated with the project even if one of the authors has recently blogged that he was
forced to abandon the project due to lack of time.
Recommendation 2: Consider the possibility that OGC assists the IETF team in moving the JSON Schema forward.
Target: Architecture.DWG and OWS Common
Recommendation 3: Consider the possibility that OGC defines specific types for OGCSIO geometry types.
Target: Architecture.DWG and OWS Common NOTE: Most of the examples provided here have been validated syntactically and semantically using a
windows application XML Validator Buddy. I appreciate the discussions with the developers of the product and some fast bug fixing or even fast adding of new functionalities.
5.3 JSON-LD
JSON-LD is a lightweight format initially designed for Linked Data this is the “why” in the LD acronym. JSON-LD is based on JSON and provides a way to help JSON data to
interoperate at Web-scale. The goal was to require as little effort as possible from developers to transform their existing JSON to JSON-LD. By defining the concept of a
context provides additional mappings from JSON to an RDF model. In practice, since there is an automatic way to go from JSON-LD to an RDF encoding, JSON-LD is
considered also an encoding for RDF a proof of this is that many programs that deal with RDF accept JSON-LD as input formant in addition to RDFXML, turtle, n3, nq, etc. The
“context” links object properties in a JSON document to concepts in an ontology. A “context” can be embedded directly in a JSON-LD document or written into a separate
file and then referenced it from several other JSON files.
In practice JSON-LD can serve other purposes. JSON-LD can also help in the validation of a document. The reason is that it connects JSON variables to their definition in the
semantic world using “id” but also declaring data types using “type”. By connecting to a reestablished ontology, indirectly adds the idea of a namespace. This
way, classes and its corresponding properties are defined by the ontology.
NOTE: JSON does not provide a mechanism for namespaces. There are some efforts to include them but some developers are worried to mimic XML too much reintroducing the complexity that JSON is avoiding.
Unfortunately, JSON-LD does not provide any object definition a way to define which properties correspond to which objects, because this is supposed to be provided by the
ontology itself. This means that objects and properties are defined in a “flat” list.
The following example incorporates “context” to the previous JSON river example. Note the capacity to define each object and property using a URI and to define the type of
some of the objects in the absence of the “type”, a string data type is supposed.
{ context: {
10
Copyright © 2015 Open Geospatial Consortium.
xsd: http:www.w3.org2001XMLSchema, uom: http:www.opengis.netdefuom,
River: http:www.opengis.uab.catRiver, name: http:schema.orgname,
length: { id: http:schema.orgdistance,
type: xsd:float, uom: km
}, discharge: {
id: http:www.opengis.uab.catriverdischarge, type: xsd:float,
uom: m3s },
source: http:www.opengis.uab.catriverSource, mouth: http:www.opengis.uab.catriverMouth,
country: http:schema.orgnationality, bridges: http:www.opengis.uab.catriverBridge
}, River:
{ name: mississipi,
length: 3734, discharge: 16790,
source: Lake Itasca, mouth: Gulf of Mexico,
country: United States of America, bridges: [Eads Bridge, Chain of Rocks Bridge]
} }
Again, a part of using id and type, the property “uom” is included making use of the JSON-LD extensibility.
