Is the OGC playing with Linked Data?
Linked Data is about enabling computers to search structured information about “things” over the web. The linking methodology is based on the following Semantic Web principles:
1) Things are uniquely identified using Uniform Resource Identifiers (URIs).
2) Use HTTP (HyperText Transfer Protocol) URIs, to make those things accessible by computer programs.
3) The knowledge of things is expressed using the W3C Resource Description Framework (RDF) and queried via SPARQL.
4) Use relationships to other things when providing information about the things.
This blog provides information about OGC activities related to LinkedData. It will highlight work done by OGC subcommittees, working groups and projects of the Interoperability Program. Finally, it will provide a next step.
Some OGC working groups have advanced content models for sharing geospatial data (e.g. the OGC GML and SensorML Encoding Standards). Such conceptual models are basic and are required for any community that wants to share geospatial content in the Web, Semantic Web or Linked Data Cloud. First come conceptual models, then the RDF representations of those models.
OGC Service standards have evolved in the last few years to provide richer hooks to link “things”. For example the OGC Sensor Web Enablement (SWE) standards enable the following to be represented and linked via URIs: features, sensor types, units, parameters, coordinate reference systems, quality category types, and others.
The OGC working groups that are most concerned with LinkedData are the GeoSemantics Domain Working Group (DGW) and GeoSPARQL Standard Working Group (SWG). The GeoSemantics DWG provides a forum for discussing geospatial semantics requirements, updating the membership on trends related to Geospatial Semantics, and fostering projects to advance solutions.
Figure 1: The GeospatialObject root class
The GeoSPARQL SWG developed the OGC GeoSPARQL – A Geographic Query Language for RDF Data 1.0 standard for representing and querying geospatial data on the Semantic Web. GeoSPARQL defines a vocabulary for representing geospatial data in RDF, and defines an extension to the SPARQL query language for querying geospatial data. It defines an ontology for representing features and their geometries. It provides two classes “Feature” and “Geometry”. Both extend from a root class SpatialObject (Figure 1). Both classes are the hooks for other communities to plug in their own features and geometries, or even to use a simple vocabulary to express linked geometric data (Figure 2).
Figure 2: Vocabulary to express linked geometric data
For an easy read about GeoSPARQL, I recommend the following article "Enabling the geospatial Semantic Web with Parliament and GeoSPARQL".
The OGC Interoperability Program provides a structure for activities related to exploration of semantic interoperability. The candidate OGC service and encoding standards developed and tested in the Interoperability Program are being designed with Semantic Web principles in mind. For example, the OGC Geospatial Semantic Web Interoperability Experiment demonstrated how ontologies from airports, airplanes, rules and features can be linked to extract information about things. This interoperability experiment helped answer such questions as, “Which airports in a specified area of the world are capable of receiving a C-5 cargo plane?”
The OGC Ocean Science Interoperability Experiment provided best practices for encoding semantics using the OGC Sensor Observation Service (SOS) Interface Standard so that sensor concepts (sensor, platform, and parameter) can be easily linked to ontologies.
The 8th and 9th OGC Web Services Testbed activities (OWS-8 and OWS-9) included a Cross Community Interoperability Thread that advanced the use of an RDF knowledge base to disambiguate differences between domain models that were originally presented as a GML application schema. The RDF knowledge base contains the GML concepts from different communities and the semantic disambiguation of those concepts. The knowledge based was wrapped in an implementation of the OGC Web Processing Service (WPS) Interface Standard so that the semantic service could be published and found in catalog services.
When “things” require unique identification and use of URIs, people need to manage those identifiers. In OGC we take this very seriously. An OGC Naming Authority Subcommittee was created as a subcommittee of the OGC Technical Committee in charge of managing the OGC URI namespace and the identifiers of documents, definitions and specific elements (e.g. conformance classes). This allows, for example, the creation of a test and a reference implementation of the URI for the conformance class. The OGC has also installed a Persistent Uniform Resource Locator (PURL) resolver for persistency and maintenance purpose.
OGC is more than playing with Linked Data concepts. The OGC is defining elements of the infrastructure: hooks, standards and procedures to ensure geospatial information can be shared using the latest rich semantic technologies.
What is the next and most obvious "low hanging fruit" step? Well, if there are communities that have geospatial ontologies they should be planning to align their ontologies with GeoSPARQL. One issue, for example, that might otherwise cause those communities trouble is using non-standard ways of encoding geometries. GeoSPARQL encodes geometries as literals. In the case of presenting a polygon, some ontologies may represent each coordinate as an RDF resource, instead of providing the polygon as a string of coordinates (i.e. only one resource). As discussed in the above-mentioned GeoSPARQL paper this increase in verbosity doesn’t add any improvement and further complicates the implementation of existing databases that already know how to interpret geometric strings. GeoSPARQL makes it easy. So, let’s start linking more “things” to GeoSPARQL to geospatially enable the Linked Data Cloud.