Copyright © 2015 Open Geospatial Consortium.
35 Since the SOA definition is independent of the technical architecture of the services it
encompasses all RESTHTTP applications. ROA can be seen as a term to describe that part of a SOA implemented following the guidelines stated above. That is, ROA is less
general than SOA since it is not independent of the technical architecture of the services. The term ROA is often used to emphasize that such an architecture in based on HTTP
objects that respond to one or more of the standard HTTP methods. Why? Because SOA has been traditionally focused on interfaces and when people talk about interfaces they
tend to use terms like “method”, “operation”, etc. which are strongly related to the RPC- style. Thus, to avoid misunderstandings the term ROA is used to make clear that we are
talking about REST-style architectures.
12.3 Possible approaches to semantic enablement
During the testbed, we identified three different approaches for the semantic enablement of the OGC Services.
12.3.1 Extension of existing services protocol
Existing OGC services can be extended to support Linked Data representation as long as the services are RESTful. For example, SensorThing provides a RESTful API to access
observations and sensor information. It is relatively easy to extend the API by adding an additional RDF representation for each resource endpoint without breaking the existing
APIs. If the JSON model of the service is compatible with the ontology representing the data model, it is possible to use JSON-LD by adding a JSON-LD context to existing
JSON response. This allows clients to consume JSON-LD document and convert the information to RDF representation for further processing.
12.3.2 Wrapper approach
A large numbers of Web applications have started to make their data available on the Web through Web APIs. Examples of data sources providing such APIs include Social
Media APIs Twitter, YouTube, Flickr, OGC Services such as WFS, WMS, WCS, SOS,. Different APIs provide diverse query and retrieval interfaces and return results using a
number of different formats such as XML, JSON or ATOM. This leads to three general limitations of Web APIs:
their content cannot be crawled by search engines Web APIs cannot be accessed using generic data browsers
Mashups are implemented against a fixed number of data sources and cannot take advantage of new data sources that appear on the Web.
These limitations can be overcome by implementing Linked Data wrappers around APIs. In general, Linked Data wrappers do the following:
36
Copyright © 2015 Open Geospatial Consortium.
They assign HTTP URIs to the non-information resources about which the API provides data.
When one of these URIs is dereferenced asking for applicationrdf+xml, the wrapper rewrites the clients request into a request against the underlying API.
The results of the API request are transformed to RDF and sent back to the client. This approach has been used to semantic enabled Social Media APIs by using a semantic
wrapper around APIs. We also use this approach for semantically enabled WFS-G by transforming GeoSPARQL queries to OGC filter queries on the fly and converting the
GML response to Linked Data representation.
12.3.3 New RESTful Service API
