A Generic SPARQL Adapter for RESTful Web Services
|has title::A Generic SPARQL Adapter for RESTful Web Services|
|Master:||project within::Knowledge Technology and Intelligent Internet Applications|
|Student name:||student name::Tim Molendijk|
|Second reader:||has second reader::Ruud Stegers|
In the recent years we have seen an explosive growth of data available through RESTful web services. Although this data is structured, it usually is not semantically annotated. This fact yields a couple of limitations. First of all the use of RESTful web services is not scalable. Every single service has a different definition and needs a human interpreter in order to utilize it. As a consequence, interoperability -- both between two services as well as between a service and data from another source -- is equally hard to achieve. Less affiliated with the aspect of semantic annotation is the issue of queryability. Due to the informal and unregulated nature of RESTful web services, there is no real standard for how to include data in or exclude data from a requested data set.
Both the scalability and interoperability issues can be solved by annotating web services using common vocabularies such as FOAF, Dublin Core or any other semantic web ontology. Such annotation should be possible in an unobtrusive way, by which we mean that annotation can be applied without having to make adjustments in the existing services. The architecture we are aiming for is one of an adapter which takes in a configuration. The configuration (1) identifies the RESTful web service that should be read from and (2) defines (part of) the semantics behind data from the web service. The two combined allow for an RDF query language to work on the data from the web service. This fact is leveraged by exposing a SPARQL endpoint which provides for a well-known, consistent and standards compliant manner of access. The goal of our research is to prove this idea by conceptualization and development of an adapter prototype. The problem of creating a configuration given a business requirement is left outside the scope of our work.
Existing solutions with similar goals are either lightweight but not service agnostic or service agnostic but very heavy and targeted at many different tasks at once. We see a need for a best of both breeds approach, one which is both service agnostic and at the same time specifically targeted at its one task and can thus be kept relatively lightweight.