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. As a technical basis, 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-based constructs. In this demo we will show some of our latest results in the production of Linked Open Services and the applications in which they can be taken up.
In [
Associated with the last principle, there is an optional fourth one: 4. When wrapping non-LOS services, extend the (lifted, if non-RDF) message to make explicit the implicit knowledge it contains, and use Linked Data vocabularies and SPARQL CONSTRUCT queries to derive the constructed knowledge.
In our demo we present LOS implementations, applications and first results towards the use of Linked Open Services in processes and service compositions. In Linked Open Services, we see an approach to linked data mash-ups with real world side-effects. It is in the nature of the work, and the call to which we respond, that this will be of ‘late breaking nature’. We have already taken forward particularly the challenge of geospatial services; both in the development of novel services according to these principles, and in wrapping existing services from http://www.geonames.org.1 1 http://www.linkedopenservices.org/services/geo/
J J J J J J J – J J J J J J J J J J J J J J J J J J J – J J J J J J J X X X X X X X – X X X X X X X X X X X X X X X X X X X X – X X X X – – X X – – – – – – – – – – – – – – – – – – – – – – – – – – – – R – – – – – – – While geonames.org is rightly regarded as one of the key components of the Linked Data cloud (cf. www.linkeddata.org), for the services that offer functionality over this data the use of semantics is much less encouraging, as shown in Figure 1. In fact, while all but one service are capable of using JSON (marked with a ‘J’), rapidly replacing XML (‘X’) as the de facto language for service communication, only one is currently enabled to directly communicate RDF (‘R’).
A number of Linked Open Services are therefore dedicated to re-exposing these services in a form where they can communicate RDF. In order to do so we employ a library we have developed, and will demonstrate, named JSON2RDF. The point of this library is not to directly produce usable RDF, but rather to automatically produce some kind of RDF that can then be transformed into a useful form simply using SPARQL CONSTRUCT queries, as per Principle 4. [ json2rdf:weatherObservations [ json2rdf:clouds "few clouds" ; json2rdf:windDirection "20"ˆˆxsd:short ; json2rdf:ICAO airports:CYOW ; json2rdf:lng "41.7"ˆˆxsd:double ; json2rdf:temperature "35" ; ... CONSTRUCT { [ met:weatherObservation [ weather:hasStationID ?icao ; ...
wgs84:long ?longitude ; wgs84:lat ?altitude ; ... ] ] . } WHERE { [ json2rdf:weatherObservations _:a ] .
_:b json2rdf:ICAO ?icao ;
json2rdf:lng ?longitude ; json2rdf:lat ?latitude ; ... }
In our work with geospatial services we have also capitalised on the cross-fertilisation of Linked Data and RESTful service principles followed in Linked Open Services. Not only is the vocabulary for the airports that are used in weather reporting in geonames services missing, but the chance to view service calls as operations against the concerned resources, rather than as disembodied ‘RPC calls’, is missing. In response, Linked Open Services have been provided that openly manage spatial resources, such as those in the geonames dataset, and airports have been included so that the ‘weatherICAO’ service (where ICAO is a code identifying airports) is offered as an HTTP POST operation against a URI version of the ICAO code. The demo will also show how REST frameworks like JAX-RS can be used in developing such services in combination with semantic technologies. 3
In the demo we demonstrate our latest work on service development in the context of
Linked Open Services [