3.1.  Terms and Definitions

3.2.  Abbreviated terms

API

Application Programming Interface

ER

Engineering Report

GIS

Geographic Information System

GLN

Global Location Number

JSON

JavaScript Object Notation

OGC

Open Geospatial Consortium

URI

Uniform Resource Identifier

URL

Uniform Resource Locator

5.1.  Use of Linked Data in Web Search

Structured data is a standardized format for providing information about a page and classifying the page content; for example, on a recipe page, what are the ingredients, the cooking time and temperature, the calories, and so on.

Search engines, like Google, use structured data found on the web to understand the content of the page, as well as to gather information about the web and the world in general. Google Search also uses structured data to enable special search result features and enhancements that help users find the information they are looking for as well as related information.

Google provides documentation describing which properties are required, recommended, or optional for structured data. Most Search structured data uses Clause 5.2 vocabulary, but the Google Search Central documentation is the definitive for Google Search behavior, rather than the schema.org documentation. There are more attributes and objects on schema.org that aren’t required by Google Search, although they may be useful for other services, tools, and platforms. [1]

5.2.  Schema.org

Schema.org is a collaborative community activity with a mission to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond.

Schema.org vocabulary can be used with many different encodings, including RDFa, Microdata and JSON-LD. These vocabularies cover entities, relationships between entities, and actions and can easily be extended through a well-documented extension model. Over 10 million sites use Schema.org to markup their web pages and email messages. Many applications from Google, Microsoft, Pinterest, Yandex, and others already use these vocabularies to power rich, extensible experiences. [2]

For features specifically related to location, schema.org provides a schema type named Place, representing Entities that have a somewhat fixed, physical extension. The schema type includes properties related to describing the location of an entity through different methods, including a property specific for GLN

5.3.  Global Location Number (GLN)

The Global Location Number (GLN) is used to identify locations and legal entities. This unique identifier comprises a GS1 Company Prefix, Location Reference, and Check Digit.

GLNs are used to identify parties to business transactions; functional groups within a company; or real, physical “places” that might ship, receive, process, or hold inventories [3]. Examples include:

• Legal entities: whole companies, subsidiaries or divisions within a company, health system corporations, etc.;

• Functional entities: specific departments within a legal entity, such as an accounting department, purchasing department, hospital pharmacy, etc.;

• Physical locations: manufacturing facilities, distribution centers, warehouses, dock doors, hospital wings, bin locations, retail stores, etc.; and

• Digital locations: an electronic or non-physical address such as an EDI gateway or ERP system.

5.4.  OGC Explorations on Linked Data and Earth Observation (EO)

This ER addresses the merge of three lines of technical research, shown in Figure 1, that have been explored by OGC Pilots and Innovation Initiatives over the past years.

Figure 1 — OGC Explorations on Linked Data and EO

The first line of research was the development of cloud data infrastructures and web services for the publication, usage, and consumption of raw data, analysis ready data (ARD), and decision ready information (DRI) related to earth observation (EO) and disaster response. Testbeds 13 through 15 included a series of tasks related to the development of cloud environments to support EO applications, while work on Testbed-16 used this cloud framework together with the emerging new OGC API Standards to explore the generation of cloud-based EO Analysis Ready Data (ARD) and the development of the Data Access and Processing API (DAPA), simplifying access to environmental and earth observation data.

The OGC Disasters Resilience Pilot worked on the demonstration of the usefulness of standards and SDI architecture within the Disaster community and provided recommendations for future work. Finally, last year, the OGC Earth Observation Application Pilot also explored the architecture that was developed in OGC Testbeds 13 through 15 and developed arrangements and definitions that enabled the deployment and execution of applications on various platforms with minimal adaptations.

The second line of research was the exploration of Linked Data applications in the EO domain. In 2017 OGC released the Earth Observation Dataset Metadata GeoJSON(-LD) Encoding Standard (OGC 17-003r2), describing a GeoJSON and JSON-LD encoding for EO metadata for datasets. Two years later, OGC released a best practices document for EO GeoJSON and JSON-LD (OGC 17-084r1), documenting models for the exchange of information describing EO collections, both within and between different organizations.

The OGC Environmental Linked Features Interoperability Experiment (ELFIE) (OGC 18-097) began exploring the use of Linked Data and JSON-LD within the environmental domain and sampling features. Two years later, the Second ELFIE (OGC 20-067) explored the use of the OGC API — Features APIs with environmental Linked Data, expanded the use of vocabularies from schema.org in the EO domain, identified the need for structured data encoded in JSON-LD, and focused on schema.org and other common ontologies.

Last year, for OGC Testbed-16, an API endpoint was deployed consistent with the emerging OGC API family of standards, oriented to observation data and implementing Linked Data. The API provided access to weather observations and its responses included a JSON-LD 1.1 context that related the JSON values to definitions in the W3C SSN Ontology and the GeoJSON vocabulary so that JSON-LD-aware clients could process the observation data. (OGC 20-016).

Lastly, the third line of research identified was the development of technologies that enhance the use of Linked Data within the community.

On 2012, OGC released the GeoSPARQL Standard (OGC 11-052r4) which defined a vocabulary for representing geospatial data in RDF (Resource Description Framework) and defined an extension to the SPARQL query language for processing geospatial data. OGC worked in partnership with W3C to generate ontologies that now have the potential to support use cases related to disaster response: In 2017 OGC 16-079 defined the Semantic Sensor Network (SSN) Ontology for describing sensors and their observations, which includes a lightweight but self-contained core ontology called SOSA (Sensor, Observation, Sample, and Actuator).

The Spatial Data on the Web Best Practices (OGC 15-107), released on 2017 by OGC and W3C, included specific recommendations to promote the discovery of web pages for spatial things in search engines, including using unique pages for each feature, enhancing the available metadata, using JSON-LD, and adding links to related features. The report provided base concepts for building the OGC API — Features Standard (17-069r3), including Linked Data principles

In 2018, OGC 18-091r2 investigated how the semantics of JSON data can be defined through the use of JSON-LD. The analysis identified a number of issues, potential solutions, recommendations, and best practices. OGC 20-012 took part of this research and investigated the implications of a few JSON Schema conversion rules regarding the ability for mapping JSON data that complies to these rules to RDF using JSON-LD and provided further lessons learned and recommendations.

6.1.  Problem Statement

Disaster management frequently encounters key data sharing challenges that make present solutions more difficult, slower, and less effective than they could be for the following reasons.

• Data, particularly EO data, can be hard to find, complicated to share, difficult to access, and slow (or unable) to be processed into common forms that are suitable for analysis and integration.

• Integration of diverse data sources into end-user information products can, in turn, be both arduous and slow to adapt to the needs of particular disaster situations by users and responders.

• End-user information products in their volume and frequency often overwhelm the connectivity available to responders and relief organizations in impacted regions.

• Local information such as in situ sensor observations, field reports, and volunteered information, are often difficult to collect and even more difficult to incorporate back into provided information products.

• Up-to-date and actionable event information, even when openly available, can be difficult for the affected public to find and stay on top of. [4]

The goal of this Pilot was to explore and advance geospatial standards-based solutions for improving disaster management. The process included developing prototypical components and services that utilize modern cloud architecture and next generation technologies. This will optimize collaborative workflows that are able to rapidly provide scalable provision ARD and DRI products, services, and applications.

The activity will address the following key components of a geospatial information flow for disaster management operations.

• Reduced Time to Discover, Access and Transform Data: Near-real-time cloud-based discovery, processing, and access of analysis ready geospatial data (ARD) from diverse sources.

• Analysis and Decision Ready Services: Analysis, visualization, and collaboration processes enabling generation of situation-appropriate , decision-ready information and indicators (DRI).

• Decision Support: On-demand and event-driven dissemination of DRI to responders, decision makers, and other disaster stakeholders.

• Mobile Devices: Use of offline data containers to work with DRI in the field under connected-disconnected conditions.

• Work the Web: Enhancements to data services to optimize discoverability by mainstream search engines and potential of linked data approaches to improve public awareness. [4]

The main goals of the Disaster Pilot were: to explore and advance geospatial standards-based solutions for improving disaster management by rapid prototyping and experimentation with Web APIs; to develop GeoPackage viewers that effectively support field operations in disaster management situations; to exercise discovery, virtual collaboration, and dynamic integration of data from various sources; and to assess connected-disconnected dissemination.

An additional goal of the Pilot was to understand how structured data can help with search engine optimization [4], which is addressed in this ER. Another ER describes the activities related to the previous objectives. [5]

Within the Disaster Pilot, the specific requirement regarding the use of structured data was the demonstration of how the OGC-API suite can be integrated with JSON-LD and aligned with schema.org to enhance the semantic definition of the OGC- API schemas and give a clear path for OGC-API generated content to be incorporated into web search engine indexes [4].

6.2.  Functional Overview

To fulfill its goals and requirements, this Pilot was organized into a collection of interconnected components, as seen on Figure 2. Each component addressed one or several Pilot requirements. Among these components, the JSON-LD Structured Data Generator (identified as D109) was created to address the goals related to structured data.

Figure 2 — Disaster Pilot Components

The JSON-LD Structured Data Generator would be designed to draw from other Pilot components to generate and publish disaster-oriented web content that incorporates structured data in order to make relevant and up-to-date decision-ready information visible more prominently and specifically in major search engine results. This would include integrating OGC API services that provide such information with JSON-LD and aligning with schema.org in order to give a clear path for API resource content to be fully represented in web search engine indexes [4].

To generate structured data, D109 would access the Registry to look for data sources, then retrieve from those sources either ARD or DRI, followed by structuring the data by making use of schemas found on schema.org and standardized Global Location Numbers (GLNs) from GS1. The search engines would eventually crawl the structured data and offer it to end users for them to find data more easily. The component and data flow is described in Figure 3, and the data generation process is described in [D109-process].

Figure 3 — D109 Data Flow

Figure 4 — D109 Process

7.1.  Status Quo

This section describes the current status regarding the use of structured data related to disaster management. The Disaster Pilot provided information on how GeoSolutions experimented using linked data in relation to disaster relevant datasets for the first time.

Previous work by GeoSolutions with linked data provided the basis for the work carried out for the pilot.

• The development of an extension for CKAN to expose and consume metadata from other catalogs using RDF documents serialized according to the Italian DCAT Application Profile. The Data Catalog Vocabulary (DCAT) is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web. The extension was thus meant to promote the sharing and the standardization of metadata about the public dataset of the Italian public administration.

• The development of the GeoServer Features Templating plug-in, initially developed as a way to serve collections of Features as JSON-LD documents, which then was expanded to became a comprehensive tool to customize features output in a variety of formats (including GeoJSON, HTML, and GML).

7.2.  Technical Architecture

To make it easier for users to search disaster information, it is critical that those publishing the data and those reading the data have a common understanding of the domain, which can be achieved through well-defined semantics that describe precisely how the published data should be interpreted without ambiguities.

GeoSolutions’ approach to this task was to publish structured geospatial data using the JSON-LD format through a GeoServer OGC API — Features implementation. The JSON-LD context was defined based on Schema.org vocabulary.

The process consisted of the following steps.

• Clause 7.2.1: Find the proper web ontologies to map the source dataset to the chosen terms.

• Clause 7.2.2: Produce a JSON-LD output consistent with the datasets and the chosen vocabulary.

• Clause 7.2.3: Have the JSON-LD document in the <head> element of every HTML page.

• Clause 7.2.4: Validate the obtained JSON-LD document to ensure that the chosen terms were correctly mapped to the features’ attributes.

• Clause 7.2.5: Submit the HTML to Google for page indexing.

Two datasets were used.

• Mortality Risk Index (MRI) Dataset: Dataset comprising metrics for mortality risk in the USA, supplied with statistical data about population (age, gender, household, ethnicity, and scholarization) as well as metrics about disease risk factors. Data were georeferenced using a polygonal theme representing Maryland administrative areas.

• Transmission Risk Index (TRI) Dataset: Dataset comprising metrics for COVID transmission risk in Perú in terms of number of cases, deaths, and active cases for various temporal periods. Data were georeferenced using a polygonal theme representing Perú administrative areas.

{
"@context": {
    "schema": "http://schema.org/",
    "FeatureCollection": "http://schemas.opengis.net/wfs/2.0/wfs.xsd",
    "features":
    {
        "@container": "@set",
        "@id": "schema:hasPart"
    },
    "diseaseSpreadStatistics":
    {
        "@id": "schema:diseaseSpreadStatistics",
        "@container": "@index"
    },
    "containedInPlace": "schema:containedInPlace",
    "observedNode": "schema:observedNode",
    "populationType": "schema:populationType",
    "measuredValue": "schema:measuredValue",
    "measuredProperty": "schema:measuredProperty",
    "type": "schema:type",
    "value": "schema:value",
    "variableMeasured": "schema:variableMeasured",
    "identifier": "schema:identifier",
    "name": "schema:name",
    "description": "schema:description",
    "spatialCoverage": "schema:spatialCoverage",
    "area": "schema:additionalProperty",
    "geo": "schema:geo",
    "polygon": "schema:polygon",
    "datePosted": "schema:datePosted",
    "temporalCoverage": "schema:temporalCoverage"
},
"@type":"FeatureCollection",
"features":[
{
"@type":"schema:SpecialAnnouncement",
"identifier": "demo-peru-ppe-20210303.PE030101.2021-03-03",
"name": "COVID transmission risk ABANCAY",
"description": "COVID transmission risk",
"datePosted":"2021-11-24",
"diseaseSpreadStatistics":{
      "daily_cases":{
         "@type":"Observation",
         "observedNode":{
            "@type":"StatisticalPopulation",
            "@id":"#popType",
            "populationType":"Population of Lima"
         },
         "measuredProperty":"Daily Cases",
         "measuredValue":4000
      },
      "daily_deaths":{
         "@type":"Observation",
         "observedNode":{
            "@id":"#popType"
         },
         "measuredProperty":"Daily Deaths",
         "measuredValue":130
       }
     }
   }
 ]
}

7.2.2.  Generating the JSON-LD Output

JSON-LD documents require a context definition which can be inline or referenced. The context defines the vocabulary used to encode the data semantics. Each attribute name is mapped to an Internationalized Resource Identifier or IRI, in this case the schema.org URL, pointing to its semantic definition. As an example, the following code block is the context used for the TRI dataset: zdfg

"@context": {
    "schema": "http://schema.org/",
    "FeatureCollection": "http://schemas.opengis.net/wfs/2.0/wfs.xsd",
    "features":
    {
        "@container": "@set",
        "@id": "schema:hasPart"
    },
    "diseaseSpreadStatistics":
    {
        "@id": "schema:diseaseSpreadStatistics",
        "@container": "@index"
    },
    "containedInPlace": "schema:containedInPlace",
    "observedNode": "schema:observedNode",
    "populationType": "schema:populationType",
    "measuredValue": "schema:measuredValue",
    "measuredProperty": "schema:measuredProperty",
    "type": "schema:type",
    "value": "schema:value",
    "variableMeasured": "schema:variableMeasured",
    "identifier": "schema:identifier",
    "name": "schema:name",
    "description": "schema:description",
    "spatialCoverage": "schema:spatialCoverage",
    "area": "schema:additionalProperty",
    "geo": "schema:geo",
    "polygon": "schema:polygon",
    "datePosted": "schema:datePosted",
    "temporalCoverage": "schema:temporalCoverage"
}

Figure 6

A JSON-LD context must map each property and type used in the JSON-LD document to a valid IRI through the use of a term. A type can be thought of as an ontology definition, e.g., SpecialAnnouncement is a type, to which a JSON object refers to via the @type attribute. A property is a property of a specific ontology which in turn has its own type, e.g., diseaseSpreadStatistics is a property of SpecialAnnouncement and can assume the type Observation among the others.

7.2.2.1.  Preserving Querying Capabilities Through Index Maps

Preserving the querying capability offered by features templating emerged as a functional problem when defining a JSON-LD template to match the datasets with the chosen ontology. Templating those metrics as a JSON array with several JSON objects of type Observation would have eliminated the possibility of querying the data due to missing unique attribute names for each metric encoded as an Observation.

Each metric was ultimately assigned to the property diseaseSpreadStatistics of the type Observation. To do this, index maps were used. An index map allows keys that have no semantic meaning (i.e., that cannot be mapped to any term), but should be preserved in the output, to be used in JSON-LD documents. This is useful when the data being used in the template has multiple source attributes that we want to map to the same property semantic. In this case, many properties were considered semantically equivalent to the diseaseSpreadStatistics property of the SpecialAnnouncement type. Therefore, GeoSolutions used an index map in the @context, where @id references the diseaseSpreadStatistics and the type of the container is set to @index:

"diseaseSpreadStatistics":{
      "@id":"http://schema.org/diseaseSpreadStatistics",
      "@container":"@index"
   },

Figure 7

This definition allows the use of unbounded JSON attributes names in the @context if they are defined inside a diseaseSpreadStatistics object. For example:

"diseaseSpreadStatistics":{
      "daily_cases":{
         "@type":"Observation",
         "observedNode":{
            "@type":"StatisticalPopulation",
            "@id":"#popType",
            "populationType":"Population of Lima"
         },
         "measuredProperty":"Daily Cases",
         "measuredValue":4000
      },
      "daily_deaths":{
         "@type":"Observation",
         "observedNode":{
            "@id":"#popType"
         },
         "measuredProperty":"Daily Deaths",
         "measuredValue":130
      },
    },

Figure 8

In this case, attribute names daily_cases and daily_deaths were not associated with any term in the @context, yet the JSON-LD was valid. This choice also had a functional aspect: by being able to preserve original attribute names through the use of an index map, it was not needed to define the object of type diseaseSpreadStatistics as a JSON Array. By doing this, it was possible to take full advantage of features templating backwards mapping.

7.2.2.2.  Increasing JSON-LD Generation Efficiency Through Features Templates

After the vocabulary has been chosen and the context has been defined, the features need to be served as a JSON-LD document matching the chosen terms.

Features are normally served by GeoServer following the schema found in the datasource itself. In case of a database source, the schema is normally constituted by the definition of the database’s tables. The GeoJSON encoder would then parse the feature to encode the geometry and the ID as top level attributes of a single GeoJSON feature and the rest of the value as attributes of the JSON Object properties.

When dealing with JSON-LD, attribute names and their level of nesting inside the final output are not given in advance by any specification as they depend upon the chosen vocabulary. This causes a JSON-LD document structure to require defining several nested JSON objects and arrays according to the chosen vocabulary. This process must be repeated for every feature, i.e., each metric, which can be time-consuming. To speed this process, GeoSolutions used the GeoServer Features Templating Plugin. The plugin allows users to define a JSON-LD template document where feature properties references can be placed in any JSON structure of choice allowing a fine grained control over the final output through a What You See Is What You Get (WYSWYG) approach (see Figure 9).

Figure 9 — GeoServer Features Templating Plugin Architecture Overview

Features Templating provides a template for a single feature and then applies the template to all the features present in the streams of data being encoded. The templates can be created directly using the GeoServer web user interface.

The Features Templating GeoServer UI allows the user to speed up the process of creating a JSON-LD document by making several operations easy while configuring a template (see Figure 10).

• It provides a Text Editor to write the template.

• It allows template developing while testing with the preview functionality.

• It provides validation over the output produced by the template.

Figure 10 — GeoServer Features Templating Configuration Page

Templates are made up of directives, which dictate the behavior of the template. Directives are used to interpolate, transform, and filter values coming from the data being templated.

Features Templating also provides more advanced directives that are outside the scope of this document. Any other part of the template that is not a directive will be encoded as it is in the final output.

Directives can be of two types.

• Vendor options: Directives that allow output customization outside the scope of a feature. As an example, the JSON-LD @context is provided through an option since it doesn’t affect the encoding of the features, but instead provides a JSON object to be inserted at the beginning of the output.

• Property directives: Directives that allow the manipulation of Feature properties encoding by invoking them in the desired point of the template through the property interpolation directive (e.g., ${propertyName}) and by further processing the property’s value through CQL functions using the CQL directive (e.g., $${strConcat('custome_prefix',propertyName)}).

The following code block is the template created for the TRI dataset explaining the rationale behind it. Given the number of properties present in the example dataset, some repeating parts have been removed from the original template for the sake of clarity. As most metrics share the definitions of @type and observedNode, only a few were left in this example.

{
   "$options":{
      "@context":{
         "schema":"http://schema.org/",
         "FeatureCollection":"http://schemas.opengis.net/wfs/2.0/wfs.xsd",
         "features":{
            "@container":"@set",
            "@id":"schema:hasPart"
         },
         "diseaseSpreadStatistics":{
            "@id":"schema:diseaseSpreadStatistics",
            "@container":"@index"
         },
         "containedInPlace":"schema:containedInPlace",
         "observedNode":"schema:observedNode",
         "populationType":"schema:populationType",
         "measuredValue":"schema:measuredValue",
         "measuredProperty":"schema:measuredProperty",
         "type":"schema:type",
         "value":"schema:value",
         "variableMeasured":"schema:variableMeasured",
         "identifier":"schema:identifier",
         "name":"schema:name",
         "description":"schema:description",
         "spatialCoverage":"schema:spatialCoverage",
         "area":"schema:additionalProperty",
         "geo":"schema:geo",
         "polygon":"schema:polygon",
         "datePosted":"schema:datePosted",
         "temporalCoverage":"schema:temporalCoverage"
      },
      "@type":"FeatureCollection"
   },
   "@type":"schema:SpecialAnnouncement",
   "identifier":"${@id}",
   "name": "$${strConcat('COVID transmission risk ',Geom_Name)}",
   "description": "COVID transmission risk",
   "datePosted":"2021-11-24",
   "diseaseSpreadStatistics":{
      "@type":"schema:Observation",
      "daily_cases":{
         "@type":"schema:Observation",
         "observedNode":{
            "@type":"schema:StatisticalPopulation",
            "@id":"#popType",
            "populationType":"$${strConcat('Population of ', Geom_Name)}"
         },
         "measuredProperty":"Daily Cases",
         "measuredValue":"${Daily_Cases}"
      },
      "daily_deaths":{
         "@type":"schema:Observation",
         "observedNode":{
            "@id":"#popType"
         },
         "measuredProperty":"Daily Deaths",
         "measuredValue":"${Daily_Deaths}"
      },
      "daily_active":{
         "@type":"schema:Observation",
         "observedNode":{
            "@id":"#popType"
         },
         "measuredProperty":"Daily Active Cases",
         "measuredValue":"${Daily_Active}"
      },
      "cum_cases":{
         "@type":"schema:Observation",
         "observedNode":{
            "@id":"#popType"
         },
         "measuredProperty":"Cumulative cases",
         "measuredValue":"${Cum_Cases}"
      },
      [...]
   },
      "spatialCoverage":{
         "@type":"schema:AdministrativeArea",
         "name":"${Geom_Name}",
         "description":"${Geom_Level}",
         "geo":{
            "@type":"schema:GeoShape",
            "polygon":"$${toWKT(geom)}"
         },
         "containedInPlace":{
            "@type":"schema:Place",
            "name":"${ADM2_ES}",
            "containedInPlace":{
               "name":"${ADM1_ES}",
               "containedInPlace":{
                  "name":"${ADM0_ES}"
               }
            },
            [...]
         },
         "area":[
            {
               "@type":"schema:PropertyValue",
               "name":"Total Land Area in Miles",
               "value":"${KM2}"
            }
         ]
   }
}

Figure 11 — TRI Dataset Template

The first element of the template, the $option attribute, is a directive and is defined as a JSON object that contains all the vendor options that will be used to customize the part of the output outside the feature scope. In this case, the vendor options included the JSON object @context and the attribute of the root JSON object @type. The @type attribute value should always be mapped to an IRI found in the reference vocabulary. Furthermore, the @context mapped the term FeatureCollection to the wfs.xsd schema (FeatureCollection":"http://schemas.opengis.net/wfs/2.0/wfs.xsd").

The subsequent parts of the template customize the appearance of each feature in the resulting features array. The @type attribute was defined for each Feature to be of type SpecialAnnouncement (the SpecialAnnouncement term is correctly mapped to an IRI).

Each term used as a property name for each Feature must be correctly referenced in the @context. An exception to this rule is when index maps are used (see above) as index maps do not require mapping the attribute name to an IRI.

In the case of the type SpecialAnnouncement, based on the description provided for each of its properties, the values were then mapped to them in the template using the various directives like in the following examples.

• The name property is simply described as the name of the item. Each Feature as a type SpecialAnnouncement has then been assigned with the name constructed by the String ‘COVID transmission risk’ and the value Geom_Name coming from the source data that refers to the place name.

• The identifier property of SpecialAnnouncement was used to refer to Feature @id.

• The description was assigned with a static value describing the Feature as related to Covid transmission risk data.

• The diseaseSpreadStatistics property has been used to reference the various COVID related metrics in the dataset. Since the object diseaseSpreadStatistics was defined as an index @container in the @context, it was not necessary to map the attributes name to an IRI inside the diseaseSpreadStatistics object.

  • As a property of type Observation, a diseaseSpreadStatistics instance can have, in turn, other properties.

    • observedNode: Described by schema.org as the Statistical population and thus obtained by a String concatenation of ‘Population of’ and the Geom_Name attribute.

    • measuredProperty: Assigned with a static string defining what the measurement is about.

    • measuredValue: The value of the observation taken if the template has been obtained by using a property interpolation directive over the various metrics in the source dataset.

• The property spatialCoverage indicates the place that is the focus of the content of an object of type SpecialAnnouncement.

  • As a property of type AdministrativeArea, spatialCoverage, it has, in turn, several properties.

    • The geo property can contain the geometry theme of the place as a polygon. To map it, a CQL directive was used to transform the geometry to a WKT representation of it through the expression ($${toWKT(geom)}).

    • The containedInPlace property is inherited by the supertype Place and expresses a recursive relation inside it since each containedInPlace is of type Place and can have in turn another containedInPlace property. It has been used to map the source data regarding the administrative units expressed hierarchically through a containment relation. For units hierarchically superior to the one represented by the geometry value, only the property name has been defined since there was no geographic data related to it.

  • AdministrativeArea also has a generic property additionalProperty described as a property-value pair representing an additional characteristic of the entity for which there is no matching property in schema.org. Due the lack of terms in AdministrativeArea for a property related to the metric extension of the geometry, the decision was made to map the term area to the IRI of additionalProperty and use it in the template to provide the value of the Land Area in Miles of the related geometry.

    • additionalProperty is a generic property that should only be used when strictly needed since applications designed to use specific schema.org properties will typically expect such data to be provided using those properties, rather than using the generic property/value mechanism. These means that consumers of the JSON-LD might end up not using it

The same rationale was applied to the Mortality Risk dataset. The metrics were all assigned to the same property/type (variableMeasured with type PropertyValue) and an expression @container:index was again defined in the @context to leverage the index map and preserve query capabilities on the layer. The property contentLocation of type Place, which is inside the spatialCoverage object, was used for the geospatial data.

Mortality risk index dataset GeoServer JSON-LD template:
{
   "$options":{
      "@context":{
         "features":{
            "@container":"@set",
            "@id":"schema:hasPart"
         },
         "Feature":"http://schemas.opengis.net/gml/2.1.2/feature.xsd",
         "schema":"http://schema.org/",
         "containedInPlace":"schema:conatainedInPlace",
         "value":"schema:value",
         "name":"schema:name",
         "about":"schema:about",
         "type":"schema:type",
         "value":"schema:value",
         "variableMeasured": {
            "@id":"schema:variableMeasured",
            "@container":"@index"
         },
         "identifier":"schema:identifier",
         "name":"schema:name",
         "description":"schema:description",
         "spatialCoverage":"schema:spatialCoverage",
         "area":"schema:additionalProperty",
         "geo":"schema:geo",
         "polygon":"schema:polygon",
         "temporalCoverage":"schema:temporalCoverage"
      }
   },
   "@type":[
      "Feature",
      "Dataset"
   ],
   "identifier":"${@id}",
   "about":{
      "@type":"Thing",
      "name":"COVID mortality risk"
   },
   "variableMeasured":{
      "ep_pop":{
         "@type":"PropertyValue",
         "name":"Total population",
         "value":"${E_POP}"
      },
      "ep_male":{
         "@type":"PropertyValue",
         "name":"Percent Male",
         "value":"${EP_Male}"
      }
      [...]
   },
   "contentLocation":{
         "@type":"Place",
         "name":"${Geom_Name}",
         "description":"${Geom_Level}",
         "geo":{
            "@type":"GeoShape",
            "polygon":"$${toWKT(geom)}"
         },
         "containedInPlace":{
            "@type":"Place",
            "name":"${ADM2_ES}",
            "containedInPlace":{
               "name":"${ADM1_ES}",
               "containedInPlace":{
                  "name":"${ADM0_ES}"
               }
            }
         },
         "area":{
            "@type":"PropertyValue",
            "name":"Total Land Area",
            "value":"${Shape_Area}"
         }
      }
   }
}

Figure 12 — MRI Dataset Template

Once the template is correctly configured it must be associated with a particular content negotiation rule which triggers a template on a particular layer based on some condition. The simplest condition is the output format matching, so that a JSON-LD template is applied to a layer only when the requested output format is ld+json while a GeoJSON template will be applied when the output format is geo+json. More complex rules are possible.

Figure 13 — Template Rules Configuration Page

As seen on Figure 13, GeoSolutions configured a rule that triggers the JSON-LD template named demo-peru-ppe-20210303 whenever the requested output format was ld+json. Once it was configured, it was possible to successfully retrieve the demo-peru-ppe-20210303 (TRI dataset) layer as a JSON-LD.

7.2.3.  Injecting the JSON-LD into an HTML Document

Once the JSON-LD content has been generated, it needs to be injected into an HTML output in order to allow Google to consume it[1]. A JSON-LD document needs to be present inside the <head> element of an HTML page inside an element <script type=”application/ld+json”>.

GeoSolutions explored a GeoServer functionality to inject JSON-LD documents into HTML outputs through the creation of HTML templates that output features using a tree-like structure. The GeoServer documentation specifies how to create these templates for them to work together with JSON-LD templates in order to return features in JSON-LD.

As seen on Figure 14, the tag <script type=”application/ld+json”/> is added to allow injecting the JSON-LD representation of the features being templated in the <head>. Each metric is included in this template through a combination of tags <ul> and <li>.

Figure 14 — The HTML Template Configured to Have the JSON-LD Output Injected

Figure 15 — The HTML Document With the ld+json Script Element

The HTML output can be seen in Figure 15. The HTML code block shown below gives a closer look at the script element holding the JSON-LD (the JSON-LD output and the HTML body have been truncated for clarity).

<html>
  <head>
    <script type="application/ld+json">
      {"@context":{"schema":"http://schema.org/","FeatureCollection":"http://schemas.opengis.net/wfs/2.0/wfs.xsd","features":{"@container":"@set","@id":"schema:hasPart"},"diseaseSpreadStatistics":{"@id":"schema:diseaseSpreadStatistics","@container":"@index"},"containedInPlace":"schema:containedInPlace","observedNode":"schema:observedNode","populationType":"schema:populationType","measuredValue":"schema:measuredValue","measuredProperty":"schema:measuredProperty","type":"schema:type","value":"schema:value","variableMeasured":"schema:variableMeasured","identifier":"schema:identifier","name":"schema:name","description":"schema:description","spatialCoverage":"schema:spatialCoverage","area":"schema:additionalProperty","geo":"schema:geo","polygon":"schema:polygon","datePosted":"schema:datePosted","temporalCoverage":"schema:temporalCoverage"},"type":"FeatureCollection","@type":"FeatureCollection","features":[{"@type":"schema:SpecialAnnouncement","identifier":"demo-peru-ppe-20210303.PE030101.2021-03-03","name":"COVID trasmission risk ABANCAY","description":"COVID trasmission risk","datePosted":"2021-11-24","diseaseSpreadStatistics":{"@type":"schema:Observation","daily_cases":{"@type":"schema:Observation","observedNode":{"@type":"schema:StatisticalPopulation","@id":"#popType","populationType":"Population of ABANCAY"},"measuredProperty":"Daily Cases","measuredValue":10.0},"daily_deaths":{"@type":"schema:Observation","observedNode":{"@id":"#popType"},"measuredProperty":"Daily Deaths","measuredValue":0.0} [...]
    </script>
  </head>
  <body>[...]</body>
</html>

Figure 16

7.2.4.  Validating the HTML with the JSON-LD

Validating the webpage and its JSON-LD context can help identify problems with the JSON-LD before publishing the HTML. It consists of verifying that the JSON-LD document is respecting the specification and that every JSON attribute is correctly referenced in the context and thus mapped to an IRI. Two validation tools were examined: Clause 7.2.4.1 and Clause 7.2.4.2.

7.2.4.1.  Google Validator

Google provides a validation tool that identifies which rich result types were found on the page, as well as any errors or suggestions for its structured data. The Google validator checks the @type definition in the JSON-LD document against the one on the schema.org website. The validator raises an error in case a mandatory property of a type is missing, and raises a warning in case an optional property of a type is not defined. The tool is thus useful in understanding if the property and the type are correctly being mapped to an IRI and if any of the mandatory property is missing. The tool distinguishes between the properties that the schema.org @type mandates and the ones that are optional.

During the Pilot, the HTML output generated in the previous step was validated with the Google tool, as seen on Figure 17. The HTML page generated for this Pilot was found to be valid with respect to its JSON-LD embedded output. The validation also returned two warnings for two fields that had not been added to the JSON-LD template despite being present in the SpecialAnnouncement type on schema.org.

Figure 17 — Google JSON-LD Validation

The Validator enables users to preview the search result, which can be seen on Figure 18. This preview is useful in checking if the JSON-LD is used by Google to enable special search results. In this case, probably due to the simplicity of the HTML page used, no special search results were displayed.

Figure 18 — Search Preview

7.2.4.2.  GeoServer Validator

Another validation method used was the one included in the GeoServer Features Templating Plugin. The plugin includes a button on the preview tab which triggers a JSON-LD specific validation that checks that all the properties are correctly referenced in the @context. The validation works by using two JSON-LD algorithms named expansion and compaction. The expansion algorithm is run first and works by removing the @context from the JSON-LD and replacing any property in the JSON-LD with the mapped IRI. The compaction algorithm does the reverse and works by recreating the @context from an expanded JSON-LD document. After the two algorithms are executed, the result is compared with the original JSON-LD, and if any property present in the original JSON-LD is missing, it means that some term was not correctly mapped to an IRI and has been erased during the JSON-LD expansion. The preview tool is then able to inform the user of the name of the properties not correctly referenced by an IRI.

Figure 19 — GeoServer JSON-LD Validation

As seen on Figure 18, the GeoServer validation is limited to verifying that each @type and property in the JSON-LD document is correctly mapped to an IRI in the @context. As such, no validation is done against the type definition available at the matching IRI as the Google validation does. Therefore, the GeoServer validation is mainly meant to have a quick and first assessment on the validity of the JSON-LD document in terms of syntax and correctness of the @context. For a complete semantic validation, a more comprehensive validation tool such as the Google validator is required.

7.2.5.  Submitting the page for Google Indexing

The final step is to publish the web page to make it accessible for the crawlers of search engines. Crawlers automatically go through HTML files and extract from the embedded JSON-LD the data required to feed the indexes that the search engines use to return search results.

In order to submit the page to Google for indexing it was necessary to:

1. go to the Google Search Console, copy and paste the URL pointing to the static HTML page; and

2. choose a verification method among the ones available and verify the submitted HTML.

Figure 20 — Google Search Console

9.1.  Serving Geographic data With JSON-LD

GeoServer OGCAPI — Features proved to be very powerful in providing access to geographic data, since it leverages all the capabilities that GeoServer provides with standard OGC services in the context of resource-centric APIs that take advantage of modern web development practices. As such, it allows an easy switch among different media types with proper content negotiation definition. For this reason, the JSON-LD output format fits well in its context.

The GeoServer Features templating plugin proved to be helpful at allowing users to produce templates on a per format basis. It made it possible to serve a valid JSON-LD output defining and validating a JSON-LD template through its UI. It also proved to be very flexible in providing support for templating various output formats and building simple or complex content negotiation rules. The capability it provides in transforming flat data structures (simple features) to complex nested ones as a JSON-LD has been fundamental.

Some ways to improve the Features Templating plug-in were identified.

• Its UI is text based and the templates can only be generated by direct text editing. It could be improved by providing a UI tool that allows a graphical mapping among source properties and template properties, making the template generation even more easy to use.

• Templates make use of vendor option definitions in order to allow the customization of the content outside of the feature’s scope: the @context itself needs to be provided inside an JSON object $options. It could be improved by removing the necessity of using $options, thus directly writing the template parts that are not mapping feature attributes as they will actually result in the final output, according to a pure what you see is what you get (WYSIWYG) approach.

9.2.  Finding Appropriate Vocabularies

Mapping some of the terms has been more challenging than expected for two main reasons.

• The selected schema.org type seems meaningful for the use case of this Pilot but the type properties don’t semantically overlap completely with the ones found in the test dataset. This has been the case of the TRI dataset layer for which the SpecialAnnouncement type was used.

  The selected schema.org type semantically fits the dataset but the concept it expresses is too generic. This has been the case of the MRI dataset layer for which the more generic type Dataset was chosen.

• Due a lack of schema.org types that have properties of types able to represent geospatial terms, it was necessary to use the FeatureCollection term mapped to an xsd IRI in order to give a @type to the root JSON object.

  Schema.org provides useful geospatial types like Place, AdministrativeArea, and TouristAttraction, that cover various kinds of Geospatial locations. On the other hand, these types are not used as properties in other schema.org types. This causes some problems in the applicability to georeferenced data of various terms.

9.3.  Limitation to Static Pages

Publishing the HTML Feature output posed an additional problem: Google accepts only HTML documents identified by a URL without any additional parameter for indexing . On the contrary, any GetFeature/GetFeatureInfo operation performed on a GeoServer instance must include within the URL several query parameters such as the service, the operation, the featureType being requested, and the output format, to cite few. This forced GeoSolutions to create and publish a static HTML page with the encoded FeatureCollection and the JSON-LD document.

9.4.  Duplicated Data

When GeoServer injects the JSON-LD document inside an HTML output of a feature collection, the feature collection needs to be encoded two times (one to obtain the HTML representation and one for the JSON-LD). This means that the impact over the response time is significant.

Search engines in general need the whole JSON-LD document to be embedded inside the HTML page (see here, for example). If it is provided differently, e.g., as an external ref, they will ignore it.

10.1.  Adding JSON-LD Support to Metadata

Since the HTML publishing process does not support URLs with query strings, any possibility of dynamic filtering of the data being provided in the HTML page was lost. Despite improving the indexability of geographic data, using static HTML pages does not seem feasible since WebGIS are mainly based on dynamic web map content.

OGC API — Features provides a starting point to help solve this issue. Currently, JSON-LD output format is supported only when retrieving the data (the collections items). By expanding this support to the retrieval of metadata, it could be then possible to improve the indexability of GIS websites.

To support this scenario, embedding JSON-LD should be considered to:

• /ogc/features output available as a starting point to navigate the API;

• /ogc/features/collections output where a list of available collections (set of data) is made available; and,

• /ogc/features/collections/{collectionName} output where details about a single collection are provided.

Given that support, any frontend application used to set up a WebGIS could then reference on the home page, the /ogc/features endpoint, to give a starting point for search engines to start the crawling of information about the content of the application.

The link to the OCG-API — Features starting point should not be advertised to the user and could then be provided by the front-end, either as a hidden anchor element or as link inside the JSON-LD document itself, although this last option is not currently support by search engines nor the JSON-LD standard itself.

10.2.  Exploring the use of JSON-LD Provided Externally

One suggestion to overcome the issue of having data duplicated in both the @context and the HTML body would be to have search engines support JSON-LD as an external ref. This cannot be done through the script element since, according to the specification, when using it as a data element (which is the case of JSON-LD) the src attribute needs to be empty. But the same could be achieved by using the link element, e.g.,

<link href="https://here/where/retrieve/jsonld.js" rel="alternate" type="application/ld+json" />

Figure 21

10.3.  Develop Vocabulary Types with Geospatial Properties

Based on the difficulties that emerged during the process of choosing a vocabulary for the JSON-LD example datasets, future developments in schema.org might consider defining terms that better fit the structure of collections of geospatial data served in JSON formats, which normally consist in a root JSON object with an array attribute populated with several feature objects, each one with its own geometry property. In general, it would be useful that in schema.org, types with geospatial properties appear as instances for properties of other terms. This would overcome problems like the one faced with the SpecialAnnounement type.

10.4.  Explore the Usage of GLNs with Linked Data

Future work could see continued and actual use of GS1 GLN to identify disaster related facility and location information that can assist with efficient routes as well as be the key to disaster related facility and location information via GS1 Digital Link. Its combination with Linked Data could boost the discoverability of disaster-related information by enabling the search of such information using GLNs. This type of search could return disaster-related information associated with a specific area or facility identified by a GLN.