Testbed-12 Semantic Portrayal, Registry and Mediation Engineering Report

The SRIM ontology in Testbed 12 used Dublin Core Metatada Terms. Future work to enhance SRIM is to map it with ISO 19115. Request for changes to improve the current standard ISO 19115 might also be required to better align with Linked Data. ISO 19115 should provide better use of controlled vocabularies, linked data friendly identifiers, and a better service description that enables automated access to services.

In Testbed 12 , the Semantic Registry harvested information from a federation of CSW services to exercise the Semantic Registry Information Model (RIM) and the REST API. Future work could include improving the efficiency of the harvesting process by investigating the publish/subscribe protocol and versioning management of the register items in the Semantic Registry as they change over time.

With the deployment of the Semantic Web and Linked Open Data, data sources have multiplied, as well as, the machine-processable controlled vocabularies that structure and constrain the interpretations of these data. These controlled vocabularies can be ontologies (RDF Schema, OWL), codelists, taxonomies, thesauri (SKOS) sometimes augmented with additional rules (SPARQL/SPIN rules, SWRL, RIF) ,and constraints (SHACL).

Vocabulary directories exist (e.g. LOV), but there is an ever-increasing demand for environments that simplify searching, editing and collaborative contributions to the vocabularies by non-experts of the Semantic Web. This creates a tension between very rich formalisms and a need to democratize participation in the life cycle of controlled vocabularies.

Vocabularies are most likely to be adopted and shared if they are made available easily. Nevertheless, despite successes in the use of SKOS for encoding vocabularies, current standards provide only low-level interfaces to vocabulary data. For example, many vocabularies are published as an RDF document for download. However, if the vocabulary is large, then the download will be commensurately large; if the user only wants to retrieve a single vocabulary term or select a few terms, this option requires processing on the client side. Alternatively, access to vocabularies is often provided at a SPARQL endpoint. SPARQL is the generic RDF query language. While it is powerful, it is also considered a low-level language similar to the relational database query language SQL and normally is only used by database administrators.

Some SKOS vocabularies are published via other HTTP interfaces. However, each implementation uses different protocols and supports a varied set of features (e.g. content-negotiation provided by the GEMET REST interface and NERC Data Grid’s Vocabulary Server SOAP interface). In some cases, one or both of human-readable formats and machine-readable formats are not available. Thus, discovery and access across vocabulary endpoints becomes challenging and ad-hoc.

There is a clear opportunity to design an API to match the SKOS and OWL vocabularies, taking advantage of the fact that most modern vocabulary content is structured using SKOS and OWL classes and predicates. This API can then be used as the basis for various higher-level vocabulary applications (NLP applications, Concept Recommender,Semantic Enricher,etc.) that can be used to enrich for example ISO 19115 metadata and other OGC services using controlled vocabularies in their metadata.

The Testbed 11 and 12 had explored the high-level description of ontologies and schemas to support semantic mediation. Future work can include investigation of the kind of metadata needed to enable search on controlled vocabularies by defining an ontology that addresses the following aspects:

Based on this ontology, we propose to define a standard REST API to search and access vocabulary metadata and their terms using best practices in REST API (hypermedia driven for example).

The Semantic Registry Information Model (SRIM), developed during Testbed 12, is defined as a superset of W3C DCAT standard and encoded as an OWL ontology. However, the OWL does not capture some of the semantic integrity constraints that are necessary to validate the instance information encoded using the SRIM ontology profiles. This is not an isolated problem. The DCAT ontology, for example, defines a set of classes and properties and reuses a large number of external vocabularies such as Dublin Core, but does not provide any restrictions in the ontology. Users have to read the profile documents such as DCAT-AP or GeoDCAT-AP to know which and how properties should be applied for a given class (mandatory, recommended or optional). For example, a Dataset could have only one title per language, or contact information should have either a person name, organization name or position name, and either email or telephone number. These kind of restrictions cannot be captured with OWL, and until now it required human interpretation to implement the constraints in code.

To fill these gaps, the emerging W3C standard called Shape Constraint Language (SHACL) provides a powerful framework to define the "shape" of the graph data and the ability to define complex integrity constraints using well-defined constraints constructs defined in RDF and SPARQL/Javascript constraints. SHACL is not a replacement of RDFS/OWL, but a complementary technology that is not only very expressive but also highly extensible. While RDFS and OWL are used to define vocabularies terms (classes/properties) and their hierarchies (subclasses, subproperties), as well as the nature of the classes and properties (union, intersection, complement of classes, transitive, inverse, symmetric properties, etc.), SHACL is more appropriate to capture the property constraints (cardinality, valid values or shape values and interdependencies between them) and capable of accommodating multiple profiles by providing different shapes for the same ontology. The SHACL vocabulary is not only defined in RDF itself, but the same macro mechanisms can be used by anyone to define new high-level language elements and publish them on the web. This means that SHACL will not only lead to the reuse of data schemas but also to domain-specific constraint languages. Furthermore, SHACL can be used in conjunction with a variety of languages beside SPARQL, including JavaScript. Complex validation constraints can be expressed in JavaScript so that they can be evaluated client-side. In addition, SHACL can be used to generate validation reports for quality control with potentially suggestions to fix validation errors. Overall, SHACL is a future-proof schema language designed for the Web of Data.While SHACL is not yet a standard, there are already existing implementations using it (e.g. Topbraid) .

Future work could include investigation of the use of SHACL shapes to define application profiles, generation and data entry, data validation, and quality control of linked data information.

During the Testbed 11, it was introduced the portrayal ontology that focused on point-based symbology (icons for Emergency Management). Testbed 12 extended this work by providing a richer symbolizer and graphics ontology that can accommodate line and area-based symbols along with graphic attributes applicable to these symbols. Future work could extend the ontology to accommodate more complex symbology including composite symbols and symbol templates. The extended ontology will help describe more advanced symbology standards such as the family of MIL2525 symbols.

This Testbed managed to render symbol legend based on their definition, however more work is needed to develop rendering a SVG map based on the portrayal ontology. Future work can lay out the foundation to express styles that have at least the same expressiveness as SLDs. The proposed work can extend the portrayal ontology to represent composite symbols and symbol templates. Related future work can include investigation of other renderer outputs such as JSON encoding of the portrayal information, so they can be handled on the client side in HTML5 Canvas or other rendering libraries such as D3.js. Other renderers may also investigate SLD production from the RDF descriptors and investigate how unsupported features from the portrayal ontology can be supported in less expressive graphic languages than SVG, such as KML.

Current Catalog solutions are highly dependent upon the metadata model employed for the service and data descriptions. Many of today’s service instances and data holdings are based on an ISO 19115 metadata model using XML as the exchange format. These solutions are very document-centric due to the nature of XML Document Object Model (DOM) that are used to populate these catalogs. This is often a challenge when information need to be integrated and be linked together, as it often requires to use complex protocols (XLink, CSW GetRecords operations) to circumvent the lack of global unique identifier system in XML document. This often leads to significant overhead to query across multiple documents and difficulties in reusing and linking information.

Linked Data provides a solution as information are modeled as a Directed Labeled Graph. The nodes of the graph (called resources) and edges (called properties) are identified with globally unique resource identifiers (URIs) which are assigned to a unique meaning (defined in ontologies). While best practices require to have resolvable resource URIs in Linked Data, in practice it is often not the case. Linked Data from different namespaces are usually aggregated in catalogs to facilitate search and discovery and get easy access to these resource descriptions.

The W3C has released the DCAT recommendation in early 2014. “DCAT is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web. By using DCAT to describe datasets in data catalogs, publishers increase discoverability and enable applications easily to consume metadata from multiple catalogs. It further enables decentralized publishing of catalogs and facilitates federated dataset search across sites.” (W3C). Thus, DCAT defines a standard way to publish machine-readable metadata about a dataset. It does not make any assumptions about the format of the datasets described in a catalog.

Since then, a number of profiles of DCAT have been created and adopted such as DCAT-AP, GeoDCAT-AP, ADMS and Project Open Data (POD), mostly focused on Dataset description. There is no well-established profile that either generalize or specialize DCAT to describe services, schemas, schema mapping, vocabularies and portrayal information. The Linked Data Query Language SPARQL and its geospatial extension GeoSPARQL are now well-established standards to query Linked Data representation with geospatial information. The SPARQL query Protocol provides a partial answer to access DCAT-related data but it is not sufficient and sometimes too complex to manage and access catalog information through a REST API. CKAN API, an open-source software powering many Open Data Portal have provided recently a plugin to export data in DCAT format. As there is more and more data published in DCAT format in the community, there is a need to have a simple and standardized REST API to manage and access Linked Data describing assets managed by catalogs/registries.

Furthermore, there are many clients that access web services from web browser using protocol based on JSON written in Javascript. The direct use of RDF formats such as RDF/XML, N3, Turtle has proved that they are not easily exploitable by these clients. The new W3C standard JSON-LD is designed to address this gap. It provides the ability to describe Linked Data in JSON and vice versa by leveraging the JSON-LD Context.

The use of REST API in the web community has been widely successfull because it aligns well with web principles and enables rapid integration to build web-based application. A number of effort related to Linked Data and REST API have been conducted such as Linked Data Platform 1.0 (LDP). Recent trends in the industry see the emergence of Hypermedia formats (HAL, Hydra, Collection+JSON, Siren) to support data REST API with hypermedia controls. This introduces a level of decoupling between server and client ecosystem that could enable future evolution of APIs without breaking client ecosystem. The challenge of this testbed is to find out how REST, Hypermedia API, Linked Data representation and APIs, JSON-LD can be combined together to meet the requirements of the service.

During the OGC Testbed 11, Image Matters LLC developed the first iteration of the Semantic Mediation Service, demonstrating the transformation of Homeland Security Working Group (HSWG) Incident Ontology to the Canadian Emergency Management Symbology (EMS) Ontology, using a rule engine. The engine was based on the Semantic Mediation Ontology and SPARQL Extension ontology expressing rules and functions of transformations between two semantic models (expressed as ontologies). The transformation from a source ontology to target ontology is called Alignment in the Semantic mediation Ontology.

While semantic transformation in the Testbed 11 was demonstrated on Linked Data representation, there is a large number of messages or documents in the current OGC standards that are based on XML representation. Their structures and syntaxes are defined with XML Schemas (GML, ISO 19139, CSGDM, NMIS). The messages often need to be converted to other XML representation based on another XML schema, typically using XSL Transformations but also by scripts. There is a need to search and discover schema definitions and existing schema mappings and finding optimal transformation paths between two schemas and perform these transformations on demand. The current OGC standards do not provide standard profile to represent schemas and schema mappings in existing OGC Catalog Services. Similary, there is no ontology or DCAT profile capable to describe semantically Schema and Schema Mappings.

There is no existing REST service that enables the search and discovery of schemas and schema mapping, performs validation, calculate optimal transformation paths and perform transformation od message from a schema to another.

The current OGC standards related to Portrayal (Style Layer Descriptor and Symbol Encoding) are based on XML schemas technologies. Styles definition, rules, symbolizers and graphics are defined XML document and do not provide global reusable identifier that allow the reusability and linking of portrayal information to emerge a "web of portrayal information". The standard ISO 19117 that describe portrayal information define an abstract model is mostly designed to be implemented in code but is less adequate to be used a descriptive model.

During the testbed 11, an initial set of portrayal ontologies were defined to describe semantically styles, portrayal rules, point-based symbols and graphics. The information were made accessible through a specialized REST API to be accessible by a WPS to produce SLD documents. The ontologies were limited only on point-based graphic symbols (based on PNG and True type font). The ontology was not able to model line, text and area based symbols and more advanced graphic objects and properties.

A number of attempts have been done in previous testbeds (OWS-8) to represent portrayal information in OGC catalog, but no standard profile has been defined so far and none of them has used a semantic-based approach.

There is a need to manage portrayal information in a catalog that can be related other information such as feature types, layers and taxonomies. This information can be searched and used to perform map portrayal using symbologies from different communities. The initial implementation of the Semantic Portrayal Service in the OGC Testbed 11 did not provide rendering endpoint for the symbology.

The following were the initial four general RFP requirements on the DCAT as a REST service implementation.

From these initial high-level requirements, we derived and added the following ones:

The following items describes the requirements for the Semantic Mediation Service:

The following items describes the requirements for the Semantic Mediation Service

The initial requirements of the testbed was to implement a DCAT REST Service that enables the access to DCAT Dataset information. However it quickly emerged that the integration of ISO 19139, NMIS, Services, Schema, Schema Mapping and Portrayal information in the service was not possible using DCAT alone, as DCAT is mostly focused on Dataset description. More generalization was needed to accommodate the different types of information objects in the future (for example Map, Layer, Vocabulary, Sensor).

The closest standard that provides an extensible framework to represent different business objects is the Electronic Business eXtensible Markup Language (ebXML) Registry Information Model (ebRIM). The ebXML registry describes objects that reside in a repository for storage and safekeeping. The information model does not deal with the actual content of the repository. All elements of the information model represent metadata (data type and data relationships) about the content stored in the repository. Such information is used to facilitate ebXML-based Business-to-Business partnerships and transactions. The registry information model provides a high-level schema for the ebXML registry. The ebRIM model has a lot overlapping constructs with the ones defined in RDF and OWL. However we found out that the definition of the classes and properties in ebRIM were often not well aligned with well-established ontologies (with the exception of Dublin Core Terms) and the best practices in the Linked Data community. ebRIM introduces a lot of verbosity to describe simple graph structure thus making very hard to build queries that naturally matches the graph structure. The Linked Data model and the standard SPARQL query language provides a more modern, decentralized approach that lowers the bar of integration and learning curve of manipulating graph-oriented data structure and seems a better match to favor reusability and linkage of information.

By analyzing the ebRIM Model and the ISO 19135 standard, we decided to create a superset of DCAT that support different types of registry items. We borrowed the notion of registers and items from both standards. The proposed solution is a new service called Semantic Registry Service that manages items described semantically and can perform semantic enrichment to better enable search and discovery for information.

The focus of Semantic Mediation Service for this testbed was to focus on transformation of XML document expressed in XML schema using transformation based on XSLT. One of the requirement was to define a ebRIM profile to represent Schema and Schema Mapping served by aebRIM CSW implementation and integrate it with the Semantic Registry. A review of the existing standards to represent schemas and schema mappings in a registry was conducted. Only DCAT and ADMS were found relevant but no profile were defined to accommodate the specificities of schemas and schema mappings such as source and target schema in a mapping. A review of the ebRIM model in CSW was also performed and concluded that an extension was needed to represent schema and schema mapping information in the ebRIM model.

Instead of defining a separate service that manages the schema and schema mapping separately, we decided to extend the core Semantic Registry Information Model by creating a profile to represent them semantically. The benefit of this approach is to test how well the core model can be extended and how well the Semantic Registry REST API can be reused to accomodate different domain models and convenience service APIs. We decided to implement the Semantic Mediation Service as convenience service on top of the Semantic Registy that performs validation and transformation between schemas (including finding a chain of transformation between two schemas). The Semantic Mediation Service would delegate the CRUD operations for schemas, schemas mappings to entirely to the Semantic Registry. We also decided to use a REST API that provide hypermedia controls with JSON-LD representation to lower the bar of integration with web clients, as well as getting Linked Data representation (RDF/XML, Turtle) to describe schemas and schema mappings for machine to machine support.

The focus of Semantic Portrayal Service for this testbed was on storing and accessing portrayal information managed by the semantic registry to support symbology mediation and rendering. Instead of defining a separate service that manages the portrayal information separately, we decided to extend the core Semantic Registry Information Model by creating a profile to represent this information semantically. The benefit of this approach is to test how well the core model can be extended and how well the Semantic Registry REST API can be reused to accommodate different domain models. We decided to implement the Semantic Portrayal Service as convenience service on top of the Semantic Registry that performs portrayal information search and rendering. The Semantic Portrayal Service would delegate the Creation/Update/Delete operations for portrayal information entirely to the Semantic Registry. We also decided to use a REST API that provide hypermedia controls with JSON-LD representation to lower the bar of integration with web clients, as well as getting Linked Data representation (RDF/XML, Turtle) to describe portrayal information for machine to machine support.

To facilitate the integration of clients with the Semantic Mediation Service, we recommended the use of REST API supporting the encoding of the SRIM Schema Application profile in Linked Data format using RDF/XML, Turtle, N-Triples and JSON-LD. We also recommended to accomodate Level 2 (Resources with HTTP Verbs) and Level 3 (Hypermedia-driven) of the Richardson Maturity Model. We choose the Level 3 Hypermedia-driven API using the Hypermedia Application Language (HAL+JSON), which is gaining in popularity in the REST community. To favor reusability of functionalities, all the CRUD operations of the schemas and schema mappings were implemented by the Semantic Registry. The Semantic Mediation Service was build a convenience service on top of the Semantic Registry to provide search capabilities, validation, transformation path calculation and actual transformation of document based on the path calculated from the schema mappings managed by the registry.

To align better with current rendering engine implementation and current descriptive standard for Portrayal (SE, SLD), we decided to align the portrayal ontology closer to the OGC Symbol Encoding (SE)and SVG. We developed the Graphics and Symbolizer ontologies that are closely with these standards, but provide mechanism to support future extensions for more complex stlying scenarios.

The Semantic Portrayal REST Service delegates the CRUD operations on portrayal information to the Semantic Registry which implements the SRIM Portrayal Profile. The Semantic Portrayal Service implements a REST API Level 2 and Level 3 on Richardson Maturity Model. We implemented the Level 3 Hypermedia-driven API using the Hypermedia Application Language (HAL+JSON), which is gaining in popularity in the REST community. The Semantic Portrayal Service should be a convenience service build on top of the Semantic Registry containing Portrayal information by providing search capabilities and rendering points for rendering symbol glyphs for legend and map rendering of geospatial data.

DCAT is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web. By using DCAT to describe datasets in data catalogs, publishers increase discoverability and enable their applications to easily consume metadata from multiple catalogs. It further enables decentralized publishing of catalogs and facilitates federated dataset search across sites. Aggregated DCAT metadata can serve as a manifest file to facilitate digital preservation.

The DCAT Application profile for data portals in Europe (DCAT-AP) is a specification based on the Data Catalogue vocabulary (DCAT) for describing public sector datasets in Europe. Its basic use case is to enable cross-data portal search for data sets and to allow public sector data to be easily searchable across borders and sectors. This can be achieved by the exchange of descriptions of datasets among data portals.

In February 2015, the ISA² programme of the European Commission has started an activity to revise the DCAT-AP, based on experience gained since its development in 2013. The outcome of this effort was the publication of DCAT-AP 1.1.

The European Data Portal is implementing the DCAT-AP as the common vocabulary for harmonizing descriptions of over 258,000 datasets harvested from 67 data portals from 34 countries. The DCAT-AP is used in the Open Data Support service initiated by the European Commission with the purpose of realizing the vision of European data portals.

GeoDCAT-AP is defined as an extension of DCAT-AP for describing geospatial datasets, dataset series, and services. It provides an RDF syntax binding for the union of metadata elements defined in the core profile of ISO 19115:2003 and those defined in the framework of the INSPIRE Directive. Its basic use case is to make spatial datasets, data series, and services searchable on general data portals, thereby making geospatial information better searchable across borders and sectors. This can be achieved by the exchange of descriptions of datasets among data portals.

ADMS is a profile of DCAT that is used to describe semantic assets (or just 'Assets'). These assets are defined as highly reusable metadata (e.g. xml schemata, generic data models) and reference data (e.g. code lists, taxonomies, dictionaries, vocabularies) that are used for eGovernment system development.

The ADMS model is intended to facilitate federation and co-operation. Like DCAT, ADMS has the concepts of a repository (catalog), assets within the repository that are often conceptual in nature, and accessible realizations of those assets, known as distributions. An asset may have zero or multiple distributions. As an example, a W3C namespace document can be considered to be a Semantic Asset that is typically available in multiple distributions, one or more machine processable versions and one in HTML for human consumption. An asset without any distributions is effectively a concept with no tangible realization, such as a planned output of a working group that has not yet been drafted.

ADMS is an RDF vocabulary with an RDF schema available at its namespace http://www.w3.org/ns/adms . The original ADMS specification published by the European Commission [ADMS1] includes an XML schema that also defines all of the controlled vocabularies and cardinality constraints associated with the original document.

Project Open Data provides the implementation guide and associated resources for the Federal Executive Order on open data and data management, M-13-13 “Managing Information as an Asset,” which includes the standardized metadata schema that all CFO Act agencies are required to use to publish their enterprise data inventories.

The Project Open Data Metadata Schema is a JSON-based implementation of the W3C DCAT vocabulary. This standard is currently implemented by multiple data catalog platforms as well as state and local governments.

Typically, POD documents are often published in Web Accessible Folder (WOF) and harvested by catalogs such as data.gov. The intent of POD is to lower the bar of complexity neededto represent data information by providing guidelines and recommended metadata. This enables a better search and discovery for datasets within the US goverment.

The standard ISO 19115 defines the schema required for describing geographic information and services that is encoded in XML format. It provides information about the identification, the extent, the quality, the spatial and temporal aspects, the content, the spatial reference, the portrayal, distribution, and other properties of digital geographic data and services. The standard ISO 19115 is applicable to:

ISO 19115-1 defines:

Though ISO 19115-1 is applicable to digital data and services, its principles can be extended to many other types of resources such as maps, charts, and textual documents as well as non-geographic data. Certain conditional metadata elements might not apply to these other forms of data.

ISO 19139 defines the XML-based implementation for ISO 19115. ISO 19115-1:2014 [ISO19115-1] has superseded ISO 19115:2003. At the date of publication of this document, the XML-based implementation of ISO 19115-1:2014 (namely, ISO 19115-3), was finalised but not yet officially released.

This International Standard specifies the procedures to establish, maintain, and publish registers of unique, unambiguous and permanent identifiers and meanings that are define items of geographic information. In order to accomplish this purpose, the standard specifies elements of information that are necessary to provide identification and meaning to the registered items and to manage the registration of these items.

SHACL is an RDF vocabulary for describing RDF graph structures. These graph structures are captured as "shapes", which correspond to nodes in RDF graphs. These shapes identify predicates and their associated cardinalities, and datatypes. Additional constraints can be associated with shapes using SPARQL or other languages which complement SHACL. SHACL shapes can be used to communicate data structures associated with a process or interface, to generate or validate data, or to drive user interfaces.

Most applications that share data do so using prescribed data structures. While RDFS and OWL enable one to make logical assertions about the objects in some domain, SHACL (Shapes Constraint Language) describes data structures. Features of SHACL include:

One of the primary functions of the Semantic Registry is to support search and discovery on a large variety of items using a unified API. The Semantic Registry was tested to handle different item types including Datasets, Services, Schemas, Schema Mappings, as well as Portrayal information such as Symbols, and Portrayal Rules, and Feature Type Styles. To integrate the different encoding standards of this information, including ISO 19139, NMIS, ebRIM Schema Profile, and DCAT, a number of semantic mappers were implemented. These semantic mappers link each standard to the adequate SRIM profiles, and are used by harvesters to extract information from various sources of information.

We found out that a Linked Data encoding (DCAT) of information is easier to integrate than XML encoding because the latter requires code to explicily define the mapping between the syntactic and semantic encoding. The XML encoding of information based on XML schema tends to be more unforgiving when validating data. Another advantage of using a Linked Data approach is that it favors reusability of information that can be created and managed in a decentralized way using a common encoding framework.

One of the biggest challenges when importing data into the system is the validation of the data. The RDF model provides a powerful framework to express any property of a resource by using vocabularies from different ontologies, and it can accomodate easily to partial/incomplete information. However, this flexibility causes difficulties when attempting to validate the data. Due to the limited time for this testbed, we decided to postpone the exploration of SHACL to address this issue for the next testbed. SHACL can provide a powerful way to validate data, define the shape of graph to be processed by the service.

This section summarizes the list of issues found when mapping ISO 19139 to a semantic representation with data coming from a variety of CSW sources (including data.gov and Geoplatform.gov). Some of these issues come from malformed metadata and ambiguities in the ISO 19115 standards, while others come from a lack of policies from agencies that publish metadata. These issues impede interoperability and integration of information in addition to search and discovery. The usage of Linked Data instead of XML encoding will address many of these problems, but not the ones related to policies.

The Semantic Registry Service was designed to manage multiple registers that are capable of containing item classes from different application profiles. To support the testbed 12, we implemented three different registers:

These registers were populated by a harvester service which is integrated with the Semantic Registry Service and accessible by a hypermedia-driven REST API. The harvester service was designed to be extensible and to support multiple types of data sources, including documents extracted from a resolvable URL (Project Open Data, DCAT , ISO 19139, FDGC CSGDM documents), and advanced web services such as CSW, CKAN, Web Accessible Folder, and ESRI Web services. These plugins called harvester types describe the list of parameter descriptors needed by the harvester. An instance of a harvester type is called a harvester source and provides binding of the parameters to values. A harvester source can be triggered for harvesting manually or a given schedule, and the harvester results are returned with statistics (number of harvested objects successfully imported, number of failures) as well as the list of item identifiers. Due to limited time for implementation, only synchronous calls to harvesters are supported. Future development will handle asynchronous harvesting with on demand status reports.

The items managed by the service are stored in a NoSQL store, and are indexed and managed in a RDF store to support graph analytics and SPARQL queries.

The initial objective of the testbed was to provide a DCAT REST API, which focused on the search and discovery of dcat:Datasets. However, promoting the DCAT model to the superset SRIM model also necessitated a promotion of the REST API to manage registers and harvester types and sources, and to handle more general items, including Portrayal items, Schema and Schema Mapping items.

A review of existing implementations that use DCAT datasets showed that the only consensus in how to access the information through a REST API, was the use of a SPARQL query protocol. Using an OGC filter was not considered adequate enough for complex queries of RDF data, as SPARQL provided a more compact and standardized way to query linked data. One of the main considerations when designing the REST API for the Semantic Registry was to make it accessible for web clients, which primarily operate in JSON, and to bridge the gap between linked data and JSON, the Semantic Registry uses the W3C JSON-LD. The use of JSON-LD context allows the conversion of RDF models to JSON representations and vice versa. Another objective of the API was to provide a degree of separation between the server and client implementation, to allow the API to evolve in the future without breaking client ecosystems. To achieve this, the Semantic Registry uses Hypermedia Links which provide a powerful mechanism to decouple clients and servers. This corresponds to the Level 3 REST API on the Richardson Maturity Model.

To implement a Level 3 REST API, we adopted the IETF standard candidate Hypermedia Application Language (HAL), a popular standard candidate which is widely used by JSON hypermedia REST APIs.

We also acknowledge that many web frameworks (such as AngularJS) are designed for Level 2 APIs and construct URLs on the client side to access the different states of a web application. To accomodate these frameworks, we decided to also implement a Level 2 REST API by providing well-defined URL patterns to access the artifacts of the service (registers, items,harvesters types, harvester sources) and a unique identifier for each artifact. The responses of Level 2 are identifical to those of Level 3, except for the exclusion of the hypermedia links to other states. The REST API endpoints URL pattern documented in Appendix D are considered informative only not normative.

In addition to the Level 2 and Level 3 REST APIs that will mostly be used by web clients, we added support for Linked Data API that will mainly be used by machines. Each REST endpoint of the Semantic Registry Service also supports a Linked Data output in RDF/XML, Turtle and N-Triples formats.

Furthermore, each Register endpoint also provides a GeoSPARQL endpoint that permits advanced SPARQL queries on the Linked Data representation of the items managed by each register.

To evaluate interoperability aspects in multi-catalog type environments, the testbed considered a number of solutions. Each solution involved various types of catalogue services, for example, CSW featuring ISO based metadata and OpenSearch, other CSW offering a SOAP binding, and support for DCAT using RDF.

Several architectural solutions could be used to establish a multi-catalogue environment, and four key architectural solutions were identified by the Testbed. The identified solutions differ in a variety of ways, including the entry point for client applications and the computational balance between the client application and the services.

The first solution for a multi-catalogue environment includes a client application that can query the various catalogue services directly. This requires the client application to prepare appropriate queries for each catalogue service and to collate the search results when they are returned by the services.

The second solution involves the selection of one of the catalogue services to initiate a distributed search. In this case, the client application only needs to prepare queries to send to the cascading catalogue service. Upon receiving a request from the client, the cascading catalogue service then adapts the request to forward to other catalogue services and returns responses from the other services, as well as results from its own catalogue.

The third solution involves the harvesting of metadata from one or more source catalogue services into a single target catalogue service. Harvesting is ideally conducted at a scheduled time and not when a query is received from the client. The client application can then query the target catalogue service to discover resources published by both the source and target catalogue services.

The fourth solution involves the replication of metadata between a federation of catalogue services. Replication would ideally be conducted at a scheduled time and not when a query is received from the client. The client application can then query any catalogue service to discover resources published by any catalogue service.

For this tesbed, the integration with the OGC Catalog Services was accomplished by using a Harvester Service.

A number of clients were successfully integrated with the Semantic Registry, as illustrated by the following figure:

To perform the integration of the Galdos Schema Registry with the Semantic Registry, two harvester types were defined in the Semantic Registry:

Both harvester types were used to defined two harvester sources to the Galdos Schema Registry instance to convert the ebRIM profile to its semantic representation in Semantic Registry (thus can be query by its REST API or SPARQL endpoint). The following figure shows the configuration of the Schema Harvester in the Semantic Registry Client.

The request filter constrains the namespace names of both the source and target schemas. The response includes a tuple (conveyed by the rim:RegistryObjectList element) that contains the matching schema mapping and an implementation (a Script or a Service object). In this case it’s a Script (media type: "application/xslt+xml") resource that can be downloaded from the registry using the URI given by wrs:repositoryItemRef/@xlink:href (a link to the repository item).

The conversion to the JSON-LD representation of the SchemaMapping is represented below.

In addition to the harvesting of the ebRIM Schema Registry, we populated the registry with additional schemas with more details attributes using RDF encoding and JSON-LD representation (using the Semantic Registry REST API to post items).

The Semantic Mediation Service was build as convenience REST API that uses the Semantic Registry to search and discover schemas and schema mappings, but provides additional functionalities such as schema validation and schema transformation.

The REST API of the Semantic Mediation Registry was designed on the same criteria than the Semantic Registry REST API. It supports Level 2 and Level 3 REST API. The Level 3 is implemented with HAL. The payload of the REST API is using JSON that can be converted to Linked Data using a JSON-LD context referred at the entry point of the service. The REST API provides endpoints to search schemas and schema mappings, perform validation and transformation between two schemas. The detailed description of the REST API can be found in Appendix E.

This Specification defines Symbology Encoding, an XML language for styling information that can be applied to digital Feature and Coverage data. This document is together with the Styled Layer Descriptor Profile for the Web Map Service Implementation Specification the direct follow-up of Styled Layer Descriptor Implementation Specification 1.0.0. The old specification document was split up into two documents to allow the parts that are not specific to WMS to be reused by other service specifications.

The OpenGIS® Styled Layer Descriptor (SLD) Profile of the OpenGIS® Web Map Service (WMS) Encoding Standard [http://www.opengeospatial.org/standards/wms] defines an encoding that extends the WMS standard to allow user-defined symbolization and coloring of geographic feature and coverage data. SLD addresses the need for users and software to be able to control the visual portrayal of the geospatial data. The ability to define styling rules requires a styling language that the client and server can both understand. The OpenGIS® Symbology Encoding Standard (SE) provides this language, while the SLD profile of WMS enables application of SE to WMS layers using extensions of WMS operations. Additionally, SLD defines an operation for standardized access to legend symbols.

SVG has been in development since 1999 by a group of companies within the W3C after the competing standards Precision Graphics Markup Language (PGML, developed from Adobe’s PostScript) and Vector Markup Language (VML, developed from Microsoft’s RTF) were submitted to W3C in 1998. SVG drew on experience from the designs of both those formats. SVG allows three types of graphic objects: vector graphics, raster graphics, and text. Graphical objects, including PNG and JPEG raster images, can be grouped, styled, transformed, and composited into previously rendered objects.

ISO 19117:2012 specifies a conceptual schema for describing symbols, portrayal functions that map geospatial features to symbols, and the collection of symbols and portrayal functions into portrayal catalogues. This conceptual schema can be used in the design of portrayal systems. It allows feature data to be separate from portrayal data, permitting data to be portrayed in a dataset independent manner.

KML is an XML language focused on geographic visualization, including annotation of maps and images. Geographic visualization includes not only the presentation of graphical data on the globe, but also the control of the user’s navigation in the sense of where to go and where to look.

From this perspective, KML is complementary to most of the key existing OGC standards including GML (Geography Markup Language), WFS (Web Feature Service) and WMS (Web Map Service). Currently, KML 2.2 utilizes certain geometry elements derived from GML 2.1.2. These elements include point, line string, linear ring, and polygon.

During this testbed, we extended the Style Microtheory designed during the testbed 11 to accomodate contextual information such as the scale range of application of a portrayal and better modeling schema used by the style rules by leveraging the work done for the semantic mediation and schema registry.

The previous Style ontology developed in Testbed 11 uses specialized properties (sparqlCondition, rifCondition,ogcFiterCondition). For this testbed, we modified the ontology to provide an extensible mechanism to express constraint in any language (which is more aligned with the CSW approach). We introduce the concept of style:Constraint. We also added introduce the minScaleDenominator and maxScaleDenominator as property of the RuleCondition,as they are common properties for style.

The details of the style microtheory are described in the Appendix C.

The Symbology Microtheory is an ontology that defines the conceptual model for defining SymbolSet and Symbol. A Symbol provides a graphic representation that denotes a concept (typically a feature type with specific properties). For this testbed, we extended the Symbol Microtheory designed during the testbed 11 to accomodate text, line, and area based symbol components and formalized binding between data properties (geometry) and graphic properties. The notion of Symbol is missing in the OGC SE standard as symbolizers are directly related to a FeatureTypeStyle. Introducing this intermediary Symbol Concept favors reusability of the symbols between different FeatureTypeStyle but also linking symbols to other concepts such as SymbolSet, concepts that they denote, allowing better search and mediation of symbols between different domains.

Due to the lack of time, we only address symbols that are not parameterizable (except their binding to geometry property). Future extension may address this requirement by introducing subclass of Symbol, such as SymbolTemplate (as introduced in ISO 19117).

The Symbolizer ontology defines a set of symbolizers (also called renderers) that defines instructions for rendering data to graphic representation. The ontology is built on top of the Graphic Ontology which defines graphic objects and properties. Symbolizers are referred by symbol:Symbol to describe how conceptual symbol are rendered into graphics. The details of the ontology is described in Appendix C. This section describes an overview of the microtheory, examples and rationale of some of the design decisions.

The OGC Symbology Encoding defines a number of symbolizers that uses SVG parameters defines a key value pair. While this mechanism provides extensibility by accomodate future key value pairs, there is no schema allowing to know which keys are valid for a given symbolizer. We decided to move away from the approach used in the previous testbed 11, based on the ISO 19117 model which introduces symbol definition, symbol components and graphics. We found out that the ISO 19117 was not adequate to represented as semantic descriptive model. The ISO 19117 is more geared toward an implementation which can use function to calculate positioning of symbol components. We decided to align out model more toward main stream map renderer and descriptive standards such as SVG. === Symbolizer Hierarchy

The top concept of the Symbolizer ontology is Symbolizer. A Symbolizer describes how a feature is to appear on a map. The Symbolizer describes not just the shape that should appear but also how visual variables are defined using graphical properties such as color and opacity. A Symbolizer is obtained by specifying one of subclass of Symbolizer and then supplying parameters to override its default behavior. The hierarchy of symbolizer is illustrated in the following figure.

Note that the hierarchy uses similar terminology than the OGC SE specification, except that it introduces an additional class called CompositeSymbolizer that defines a composition of symbolizers applied in a given order and using a composition operation (default is source over). This version of the ontology mostly focused on rendering of feature (vector) data, and is not addressing in depth the Raster Symbolizer, which is introduced as a placeholder for future extension. Other extensions of symbolizer may be defined down the road for more specialized use-cases such as complex symbologies that are difficult to express with graphic descriptors (example MIL 2525 symbology).

To facilitate the integration of geospatial assets (such as datasets, services, portrayal information, schemas, maps, layers), semantic metadata plays a central role in facilitating the discovery and the assessment of fitness of use of these resources for a specific mission. There are a number of standards, formats, and APIs that provide metadata, but in order to perform efficient search we need to convert this information into a unified, machine-readable semantic representation that enables the discovery of relevant resources to satisfy the mission of the end user. As an understanding of the kind of metadata information being searched is needed to perform a better and smarter search, we need a model that accommodates extensions over time without breaking the proposed architecture.

A number of metadata standards have been reviewed, including the W3C standard DCAT, DCAT-AP, GeoDCAT-AP, ADMS, Project Open Data 1.1, Dublin Core, ISO 19115, and ISO 19119 to identify the common and relevant metadata information needed for search and discovery, but also to identify the gaps to address the requirements to describe dataset, service, portrayal information, schema and schema mapping. It quickly emerged that the DCAT standard and its different application profiles were data-centric and insufficient to describe metadata for portrayal information,schemas and services. The goal of this effort was not to define a new standard, but to leverage existing standards to define an application profile of DCAT that could accomodate the schema, service, and portrayal information needed for discovery and filling the gaps by introducing additional properties and fields, all while preserving backward compatibility with existing standards.

This analysis resulted in a new application profile of DCAT called the Semantic Registry Information Model (SRIM) Core Model, referred to later in the document as SRIM Core. SRIM Core is defined as a superset of DCAT and its existing application profiles (DCAT-AP, GeoDCAT-AP, ADMS), and it introduces a superclass of dcat:Dataset called srim:Item. The ontology draws from multiple well-established standards such as W3C, DCAT, Project Open Data 1.1, DCAT-AP, GeoDCAT-AP, VCard, Dublin Core, and PAV, but also addresses some gaps in the standards, such as descriptions of web services (for example OGC WMS, WFS), richer description for geospatial data, additional metadata to model schema, schema mapping, and portrayal information in order to enable better semantic search of resources that fit the mission of the users. The ontology draws also on the geospatial metadata standard ISO 19115. SRIM enables the integration of different metadata providers (CSW, CKAN, POD WAF, WMS, WCS) by providing a common core vocabulary to describe resources (data, services, vocabularies, map, layers, schemas, etc) and accommodate the specificities of each source by leveraging the built-in extensibility mechanism in OWL. The integration is done through the use of a semantic bridge that maps the syntactic metadata (JSON, XML based) to a semantic representation based on the SRIM model. The SRIM Core model has been extended by introducing the SRIM application profile to represent other kinds of geospatial assets such as schemas and portrayal information (see section for Semantic Mediation and Semantic Portrayal Service).

The purpose of SRIM Core is to define a common interchange metadata format for geospatial portals. In order to achieve this, SRIM defines a set of classes and properties, grouped into mandatory, recommended, and optional. Such classes and properties correspond to information on register items and registers that are shared by many data portals, aiding interoperability. Although SRIM is designed to be independent from its actual implementation, RDF [RDF] and Linked Data [LDBOOK] are the reference technologies used to perform the modeling and preserve the semantic fidelity of the conceptual model. However, to facilitate a wide adoption, we provide an encoding based on JSON, which could be converted transparently back to a semantic model using a JSON-LD context. The JSON has been closely aligned with the Project Open Data metadata schema 1.1 standard. However, to accommodate some of the requirements needed by the Semantic Registry Service, we extended, and sometimes modified, the model when needed.

The following part of SRIM Core shows how DCAT is related to the srim:Item. Note the model introduces the first class concept of srim:Service, which inherits from dcat:Distribution and srim:Item, so that we can have a rich description of services that can be leveraged by an agent for the discovery of services and better access to services.

The following sections describe the details of every class in the model.

A Register is a curated collection of metadata about items stored in a repository (registry) used to enable search and discovery of resources. This class is used as a container to exchange registers of resources between registries. The Register is made accessible through a Registry Service.

Rationale: The items are usually organized in catalogs (a synonym of registers). To favor reusability of the registry service for multiple purpose, catalogs can be specialized for a specific register item type (datasets, services, layers, maps, features, vocabularies, etc..) and conform to a specific application profile, or be organized for a specific domain or organization.

A RegisterEntry provides a description of an Item entry in the Register. The register entry is used to capture provenance information and the status of the register item within the register. This is mostly a supporting class that is used for the administration of the resources within the registry.

Rationale: The Register Entry is a concept needed only for an administrative purpose to manage and understand the lifecycle of the register items. This object is not typically used by end users searching for data (that is why the RegisterEntry is made optional in our model). The Register entry corresponds to the CatalogRecord in DCAT.

An ItemClass represents a class of item that can be managed by the registry service. Examples of item classes are datasets, maps, layers, services, vocabularies, styles, and application schemas. Each Item must be associated with one ItemClass. The Registry Service should provide the list of item classes that are supported, and a register can manage one or more item classes.

Rationale: In order to validate the type of item submitted to the register, we need to classify the register items according to a well-known domain class. The ItemClass corresponds to an ontology class in the RDF world.

A register Item (also known as register Resource) is the top class of the item hierarchy. It is a subclass of rdfs:Resource. It represents any information entities or services that can be registered in a register.

Rationale: The Item is a generalization of the DCAT Dataset concept. It contains all the common medadata and tradecraft information about any resource of interest for the end-user that needs to be found through a common API.

An Activity holds the URI of the source that generated a register entry.

Rationale: Provides provenance information about where the entry came from.

To represent address information, we use the well-known ontology VCard.

Rationale: We need a way to describe address information that is based on a well-known standard, so person/organization in charge of resources can be contacted or located.

An entity that is associated with Registers and/or Resources. If the Agent is an organization, the use of the Organization ontology is recommended.

Rationale: Defining a standard way to represent agents helps to create hub of information around organizations and people.

Registered resources are attributed to one or more responsibility parties playing different Attribution roles (contact point,publisher, rights holder, processor…).

Rationale: Needed to understand the role of each contributor of a resources. Provide an extensible mechanism to accommodate new roles.

A Concept can be viewed as an idea or notion; a unit of thought. However, what constitutes a unit of thought is subjective, and this definition is meant to be suggestive, rather than restrictive.

Rationale: The use of controlled vocabularies helps to organize information at the conceptual level and enable semantic inferencing and classification of information that helps the end-user to find the relevant information that fits better his needs.

A concept scheme (e.g. controlled vocabulary) in which the Concept is defined. A concept scheme can be viewed as an aggregation of one or more SKOS concepts. Semantic relationships (links) between those concepts may also be viewed as part of a concept scheme.

Rationale: The use of controlled vocabularies helps to organize information at the conceptual level and enable semantic inferencing and classification of information that helps the end-user to find the relevant information that fits better his needs.

The Document class represents those things which are, broadly conceived, 'documents'. The foaf:Image class is a sub-class of Document, since all images are documents. Document needs to be identified by a resolvable URL on the web.

Rationale: We need a way to describe documents to understand their role in the ecosystem of items managed in the registry.

To represent email information, we use the well-known ontology VCard.

Rationale: We need a way to describe email information that is based on a well-known standard, so the person/organization in charge of a resource can be contacted or located.

GeographicExtent describes the spatial extent of domain of application of an item and is standardized in WGS 84 Lat/Long coordinate system.

Rationale: There is no consensus and common vocabulary to describe spatial in the community. GML Envelope was proposed by it is too cumbersome to process. We introduce four separates fields for each bound (west, east, north and south) that removes any ambiguity and make it easy to query in any spatial index.

An Identifier provides a mechanism to uniquely identify a resource using a given codespace and defined by an authority.

Rationale: The support of identifiers helps to find items based on some well-know identification systems (ISBN for example).

A Link contains information about a resource that is related to an Item or another entity and that can be found on the Internet.

Rationale: A Link is useful as a container for a rdfs:Resource that can store the relationship of a link to its parent item as well as information about what is on the other side of the URL.

Location represents a place that is related to the item stored in the register. Each location should a geographic extent expressed in WGS84 to enable spatial search in consistent way. We use dct:Location as the base class for Location.

Rationale: Essential for spatial scoping of data. Location should be referred as much as possible with resolvable URI that points to a controlled vocabulary of place names (Gazetteer). This allows spatial reasoning using place part-of relationships. We try to keep the definition of Location to a bare minimum. More complex geometry can be added down the road. We may use W3c Location ontology to extend the model.

An OpeningHoursSpecification describes the hours that a business or other organization is open during the week. It is based in the well-known GoodRelations vocabulary.

Rationale: Having a standard way to capture the opening hours of a business or organization helps understand when it is best to visit or otherwise contact said business or organization.

An Organization represents a collection of people organized together into a community or other social, commercial or political structure. The group has some common purpose or reason for existence which goes beyond the set of people belonging to it and can act as an Agent. Organizations are often decomposable into hierarchical structures. An Organization is a specialization of an Agent. It is strongly advised that the Organization provides a URL that is shareable and stable according to the best practices of Linked Data.

Rationale: Defining a standard way to represent organizations helps to create hub of information around organizations.

A PeriodOfTime denotes the temporal scope of a register item. We use dct:PeriodOfTime as the base class, and a time period has startDate and/or endDate. If they are the same, they represent a temporal instant (point in time). A PeriodOfTime can also refer to a URI that can be resolvable and is defined by a well-known taxonomy of periods of time.

Rationale: Essential for temporal scoping of data.

To represent phone information, we use the well-known ontology VCard.

Rationale: We need a way to describe phone information that is based on a well-known standard, so the person/organization in charge of a resource can be contacted or located.

A project for which data was generated or collected. Uses the well-known foaf:Project ontology.

Rationale: Provides a way to store the project for which the metadata in the register item was generated.

Statement containing a provenance statement about the origin of a register item. Based on the well-known DCTerms provenance statement (dct:ProvenanceStatement).

Rationale: Provides a way to store free-form provenance information.

A Release contains information detailing a specific version of an item.

Rationale: In order to keep track of versioning in sufficient detail, we need to have a class that stores version information such as version number and release notes.

A statement about the intellectual property rights (IPR) held in or over a resource, a legal document giving official permission to do something with a resource, or a statement about access rights.

Rationale: Important legal information protecting intellectual properties.

A Standard provides a basis for comparison; a reference point against which other things can be evaluated.

Rationale: This is an important concept that is used to understand how register items conforms to standards.

To represent contact information, we use the well-known ontology VCard.

Rationale: We need a way to describe contact information that is based on a well-known standard, so person/organization in charge of resources can be contacted to perform corrections or status information when necessary.

A Dataset is a collection of data, published or curated by a single agent and available for access or download in one or more formats.

Rationale: A register item may be a dataset, in which case it is necessary to store information about the dataset and the data inside it.

A Distribution is piece of data or metadata than can be accessed via a URL and is relevant to a Dataset.

Rationale: If a register item is a dataset, it is necessary to store information about the data inside it.

A FileFormat stores information about a file format and is defined by the well-known DCTerms (Dublin Core) vocabulary.

Rationale: Distributions are often stored as a downloadable file, and it is important to keep track of what format each file is in.

A Web Service is a service offered by an electronic device to another electronic device, communicating with each other via the World Wide Web. In a web service, web technology such as the HTTP, originally designed for human-to-machine communication, is utilized for machine-to-machine communication, more specifically for transferring machine readable file formats such as XML and JSON. Service has all the properties of both a Distribution and an Item.

Rationale: An important aspect of the registry model is to support a service description that can be accessed automatically by machines. We want a core minimal set of properties that enables this automation.

An APIDocument describes a web accessible document that describes the API of the service. Rationale: To be able to automate the access to a service that is not adhering to a well-known standard (such OGC WMS, ArcREST), we need a mechanism to point out to human and machine processable API document such as (RAML, Swagger, HAL Profile, ALPS profile).

A Schema in this context is a specific format used to represent information. Schema extends dcat:Dataset.

Rationale: Because the same data can be represented in a number of different ways, we want to be able to determine what schema is being used and convert from one schema to another.

A SchemaMapping is a mapping used to convert a piece of data from one schema to another. SchemaMapping extends dcat:Dataset.

Rationale: Because there is a need to transform data from one scheme to another, it is useful to be able to keep track of the schemas being mapped between.

A SchemaLanguage is the language that a schema is written in. SchemaLanguage extends skos:Concept.

Rationale: It is important to keep track of what language a schema is written in so that the dataset using that schema can later be processed.

A SchemaMappingLanguage is the language that defines a schema mapping. SchemaMappingLanguage extends skos:Concept.

Rationale: It is important to keep track of what language is being used to transform a dataset from one schema to another.

A SchemaRelease is a single release (version) of a schema. SchemaRelease extends srim:Release.

Rationale: It is necessary to keep track of past releases of a schema in case backwards compatability is needed.

The Style concept is the central concept of the Style ontology. It associates symbol sets with portrayal rule sets, which define the mapping of feature types to symbols. The Style also captures descriptive metadata and tradecraft information such as the audience for the style, scope of application and field of application.The following table summarizes the properties of the Style class.

A FeatureTypeStyle is a style that is applied for a specific feature:FeatureType. FeatureTypeStyle inherits all properties from Style.

The following example shows the definition of the EMS Style with audience information organized as a hierarchy.

A CoverageStyle is a style that is applied for a Coverage. CoverageStyle inherits all properties from Style. This concept is introduced as a placeholder for future extension.

A portrayal rule set describes a function set which maps the feature types of a feature catalog to a symbol. It is composed of one or more portrayal rules, which in turn maps an individual feature type to a symbol. The table below provides a summary of the PortrayalRuleSet.

The following is a sample of the PortrayalRuleSet defined for the EMS Style.

A PortrayalRule defines a rule that associates a feature type (feature:FeatureType) to a symbol (symbol:Symbol) satisfying a certain condition (PortrayalRuleCondition) in a given context (PortrayalContext). The Table below summarizes its properties.

The listing below shows an example of PortrayalRule for Windchill. The PortrayalRule applied on the ems:EMSIncident featureType and associates the EMS symbol for Windchill defined by the URL: http://www.opengis.net/testbed/11/cci/ems/symbols#ems.incident.temperature.windChill-symbol

The RuleCondition defines the condition in which a portrayal rule applies for a given feature. The RuleCondition can be encoded using multiple encodings. The Table below summarizes the properties of PortrayalRuleCondition.

To provide an extensible mechanism to express constraints for the condition, we modified the previous ontology in Testbed 11, which uses specialized properties (sparqlCondition, rifCondition,ogcFiterCondition)

The following example demonstrates the encoding of the portrayal rule condition for the Portrayal rule for the symbol Windchill. The condition applies on the feature property ems:incidentType. If the value of this property is equals to http://www.opengis.net/taxonomy/ems#ems.incident.temperature.windChill then the rule is applicable.

The rule is expressed in three different encodings: OGC Filter, SPARQL and RIF.

The SPARQL query is formulated as a ASK query which returns a boolean value. The variable ?this is bound to the current instance of featureType that is being tested.

The equivalent RIF condition is expressed as:

The Constraints expressed in SPARQL and RIF can be used by a semantic portrayal rule engine that consumes feature data represented as Linked Data (recommendation for next testbed). We foresee that the portrayal catalog containing these rules can be extended with a rendering service that will apply the rules on a set of linked data compatible with the style and generates the portrayal rendering to a number of target formats (SVG, KML etc..). We suggest we experiment this capability in the next testbed.

To perform the bridge between the Linked Data representation of the FeatureType and GML representation we annotated the FeatureType and FeatureProperty with the attribute gmlName to indicate what is the mapping between the conceptual definition and the GML syntactic definition based on XML schema.

The following example shows the feature type definition for EMSIncident with the gmlName annotations.

The following example shows the feature type definition for HSWGIncident with the gmlName annotations.

In some instance, rules needs to be executed in a given order with support of fallback rules.The PortrayalRuleList defines a ordered list of RuleItem instances. The PortrayalRuleList is implemented by an rdf:List.

The RuleItem defines a placeholder referring indirectly to a portrayal rule. However it can also provides a reference to fallback portrayal rules (elseRule) if the rule is not applicable. The RuleItem is used when the order of application of the rules is important. The RuleItem are used as element of PortrayalRuleList.

SymbolSet collects symbols into sets of symbols that are used together. Symbols can be shared among symbol sets. A Symbol set can be equated with legend of a map. The Table below summarizes the SymbolSet properties.

The following example shows a sample of the EMS SymbolSet.

A Symbol is the type used to define symbol classes. Symbols are collected into symbol sets. A symbol has one machine readable identifier. It is described by a title, description and can refer to a formal specification document. A symbol can denote a concept defined in a SKOS taxonomy. The table below summarizes the Symbol properties.

The following listing shows the encoding in Turtle for the WindChill symbol belonging to the EMS SymbolSet.

Symbolizer is the top class of all the symbolizer and provides properties that are inherited by all subclasses.

A PointSymbolizer is defined as a Symbolizer that is used to draw a “graphic” at a point. If the geometry associated with the PointSymbolizer is not a point, such as a line, polygon, raster, a representative point of the geometry (typically centroid) should be used.