Linked Open Services are a principled attempt to guide the creation and exposure of online services, in order to enable productive use of, and contribution to, Linked Data. They communicate RDF directly, via HTTP-based interaction, and their contribution to the consumer's knowledge, in terms of Linked Data, is described using SPARQL. To achieve this they bring together, and extend, the principles of Linked Data and of REST. In this paper we focus on the development of Linked Open Services for the geospatial domain and explain how they overcome the short-comings of existing services over the geonames dataset, a core part of the Linked Open Data Cloud.
1. Describe services as LOD prosumers with input and output descriptions as SPARQL graph patterns. 2. Communicate RDF by RESTful content negotiation. 3. Communicate and describe the knowledge contribution resulting from service interaction, including implicit knowledge relating input, output and service provider.
SPARQL CONSTRUCT queries.
Perhaps the most important important vocabulary for geospatial information is the
encoding of the coordinate system of the 1984 World Geodetic System, WGS84 [
In order to support location-based weather reports as Linked Open Services, we therefore work with a standards-based (RDFS) adaptation to the existing DAML METAR ontology, convert (JSON-based) METAR reports into RDF using the classes and properties defined, and then recreate Linked Data resources for ICAO-identified airports, minting new URIs based on these codes. As well as referring to these resources in weather requests from ad hoc locations, also encoded using the WGS84 vocabulary, we attach airport-specific requests to the resources themselves in RESTful style, demonstrating the natural fit of the full scope of RESTful services (beyond GET methods) and Linked Data. In the following Section 2 explains how the conversion fits over the existing geonames service as a Linked Open Service wrapper, Section 3 explains how the resource-based services operate alongside standard Linked Data principles. Finally, we conclude in Section 4. 2
Currently XML and JSON (plus, perhaps, YAML) are the predominant syntaxes for the exchange of dynamic information on the Web in general, including specifically, which is unfortunate, for a significant number of services over the Linked (Open) Data Cloud. We point out, for example, that all but one of the 36 GeoNames services, including METAR-based weather services, do not support RDF (most support JSON, with XML in close second). In order to expose such non-RDF Web services as LOS, it is necessary to transform from RDF to the expected data format of the service implementation, and to map the output of the service back into RDF. In the case of the procedure-oriented GeoNames Weather services (nearby to point, and within bounding box), the invocation is triggered by an HTTP POST request, and the result data is serialized as either a JSON Array or an XML document. Our LOS versions of these weather services are available at http://www.linkedopenservices.org/services/geonames/weather/, where the LOS-specific input and output descriptions are given as exemplified below. Input (bounding box version): [a wgs84:Point; wgs84:lat ?north; wgs84:long ?west] [a wgs84:Point; wgs84:lat ?south; wgs84:long ?east] 2 http://www.w3.org/2003/01/geo/ 3 http://www.daml.org/ontologies/241 4 http://www.csd.abdn.ac.uk/research/AgentCities/WeatherAgent/weather-ont.daml Output: [ metar:weatherObservation [ weather:hasStationID ?icao ; wgs84:lat ?lat ; wgs84:long ?lng ; wgs84:alt ?alt ; metar:datetime ?dateTime ; metar:observation ?observation ; weather:hasVisibilityEvent ?clouds ; weather:hasWindEvent [weather:windDirection ?windDirection],
[weather:windSpeedKnots ?windSpeed] ; weather:hasTemperatureEvent [a weather:CurrentTemperature ; weather:celsiusTemperature ?temperature], [a weather:CurrentDewPoint ; weather:celsiusTemperature ?dewPoint], [weather:humidityPercent ?humidity] ; weather:hasWeatherEvent ?condition ; weather:hasPressureEvent [metar:hectoPascal ?pressure ] ] ]
In the simplest case the transformation consists of applying the generic ‘JSON2RDF’ library5 (which creates no real semantics, but puts the data into graph form so it can be queried), followed by a SPARQL CONSTRUCT query (into instances in existing vocabularies) in order to automatically create a useful RDF model. As well as using existing standard predicates to give semantics to the output data in itself, the query is enabled to create links between input and output data, encoding knowledge that is normally only implicit in service interaction (“this is the weather nearest to the point...”), and the machinery may also encode provenance information (“according to an invocation of [service X] at [time Y]”.
The query has a head equal to the output pattern of the LOS, and is hence an explicit specification of how to transform the internal json2rdf data into an RDF graph that provides the promised knowledge contribution of the service. For the particular case of our LOS! GeoNames Weather service we introduced an additional intermediate step that lifts the string values of, for example, json2rdf:clouds to a URL of the enhanced METAR ontology (metar:FewClouds). 6 Among the extensions we have made there are internationalised labels for the different weather conditions, extended beyond those offered by the geonames services. 3
The services in the previous section return lists of airport-based weather stations (identified by ‘ICAO’ codes) with the most recent weather observation, according to their proximity to some transient geographical input. Geonames also, however, offers a service ‘weatherIcao’ that returns the weather for a given METAR station. Unfortunately neither does geonames give a Linked Data style resolvable URI for these stations, nor does the previous attempt to form Linked Data from them7 seem still to exist. At the LOS community website we have therefore decided to adopt a resource-oriented (i.e., truly RESTful) approach to METAR stations as spatial resources. The collection http://www.linkedopenservices.org/services/geo/SpatialResources/point/ has been expanded to include the current METAR lists. 5 http://www.linkedopenservices.org/wiki/index.php/JSON2RDF 6 The ontology at http://www.linkedopenservice.org/ns/METAR is an extension to the DAML ontology discussed above. 7 See: http://lists.xml.org/archives/xml-dev/199907/msg00415.html
Output:
For ICAO (we have also minted URIs for IATA, International Air Transport Association, codes) more than 50 000 triples have been created of the following pattern: _:airport rdf:type point:ICAO ; wgs84:lat ?lat ; wgs84:long ?long ; wgs84:alt ?alt ; rdf:label ?label
OPTIONAL {_:airport owl:sameAs ?iata . ?iata a point:IATA}
The most important consequence of the exposure of these resources for LOS, however, is that they are the basis for supporting a resource-oriented version of the weather service, which can be invoked simply by GETting from corresponding URIs of the form: http://www.linkedopenservices.org/services/geo/SpatialResources/point/{ex}/weather
This returns RDF of a similar scheme to that presented in the last section. 4
In this paper we have motivated and introduced the principles guiding the creation of Linked Open Services and their application to geospatial data. We have illustrated how simple wrappers can be formed from existing procedure-oriented services and furthermore how a resource-oriented service can optimally combine the principles of REST and of Linked Data. In both cases RDF is available, via HTTP content negotation, for direct communication and SPARQL graph patterns are used to describe the required input, and the expected output, capturing the full knowledge contribution of service execution.
A LOS wrapper specifies not only what graph patterns a service consumes and produces, respectively, but also how the input RDF is ‘lowered’ to the expected data format of the service, respectively how the output of the service is ‘lifted’ back to RDF by means of a SPARQL CONSTRUCT with a head equal to the output pattern. We have already produced a helpful library, JSON2RDF, to aid this wrapping process.
Acknowledgement: The work is supported by the EU projects SOA4All and SEALS.