- From: Leigh Dodds <leigh@ldodds.com>
- Date: Thu, 18 Apr 2013 12:10:11 +0100
- To: Luca Matteis <lmatteis@gmail.com>
- Cc: Paul Groth <p.t.groth@vu.nl>, Hugh Glaser <hg@ecs.soton.ac.uk>, Barry Norton <barry.norton@ontotext.com>, "public-lod@w3.org> <public-lod@w3.org" <public-lod@w3.org>
Hi, On Thu, Apr 18, 2013 at 12:01 PM, Luca Matteis <lmatteis@gmail.com> wrote: > Thanks Paul, > > That is exactly what my point was entirely about. Many service don't expose > their SQL interface, so why should Linked Data? > > Regarding this Linked Data API, it seems to still require a SPARQL endpoint. > In fact it states that it is a proxy for SPARQL. Would it simply be possible > to implement this API without SPARQL on top of a regular database that > contains triples? While the specification talks about mapping to a SPARQL endpoint the processing model would potentially allow you to use different backends. Servicing a Linked Data API request involves several steps: 1. Mapping the request to a query (currently a SPARQL SELECT) to identify the list of resources of interest 2. Mapping the request to a query (currently a SPARQL CONSTRUCT) to produce a description of each item on the list 3. Serialising the results Broadly speaking you could swap out steps 1 & 2. For example you could map the first step to a search query that produces a list of results from a search engine, or a SQL query that extracts the resources from a database. You could map the second step to requests to a document database that fetches pre-existing descriptions of each item. The API supports a number of filtering and sorting options, which will add some complexity to both stages, but I don't think there's any show stoppers in there. Cheers, L. -- Leigh Dodds Freelance Technologist Open Data, Linked Data Geek t: @ldodds w: ldodds.com e: leigh@ldodds.com
Received on Thursday, 18 April 2013 11:10:38 UTC