It's a whole project with running code:
http://code.google.com/p/linked-data-api/
Richard
On 18/04/2013 11:52, Luca Matteis wrote:
For me it's still a bit unclear where the "Linked Data Platform" API
is defined. Is it a set of strict rules? For example, I've heard it's
a way of matching a triple where a specific URI appears in its subject
or object.
Any links on where this is defined?
On Thu, Apr 18, 2013 at 12:27 PM, Leigh Dodds <[email protected]
<mailto:[email protected]>> wrote:
Hi Hugh,
On Thu, Apr 18, 2013 at 10:56 AM, Hugh Glaser <[email protected]
<mailto:[email protected]>> wrote:
> (Yes, Linked Data API is cool!, and thanks for getting back to
the main subject, although I somehow doubt anyone is expecting to
read anything about it in this thread now :-) )
I'm still hoping we might return to the original topic :)
What this discussion, and in fact most related discussions about
SPARQL as a web service, seems to overlook is that there are several
different issues in play here:
* Whether SPARQL is more accessible to developers than other forms of
web API. For example is the learning curve, harder or easier?
* Whether offering query languages like SPARQL, SQL, YQL, etc is a
sensible option when offering a public API and what kinds of quality
of service can be wrapped around that. Or do other forms of API offer
more options for providing quality of service by trading off power of
query expression?
* Techniques for making SPARQL endpoints scale in scenarios where the
typical query patterns are unknown (which is true of most public
endpoints). Scaling and quality of service considerations for a public
web service and a private enterprise endpoint are different. Not all
of the techniques that people use, e.g. query timeouts or partial
results, are actually standardised so plenty of scope for more
exploration here.
* Whether SPARQL is the only query language we need for RDF, or for
more general graph databases, or whether there are room for other
forms of graph query languages
The Linked Data API was designed to provide a simplified read-only API
that is less expressive than full SPARQL. The goals were to make
something easier to use, but not preclude helping developers towards
using full SPARQL if that's what they wanted. It also fills a
short-fall with most Linked Data publishing approaches, i.e. that
getting lists of things, possibly as a paged list, possibly with some
simple filtering is not easy. We don't need a full graph query
language for that. The Linked Data Platform is looking at that area
too, but its also got a lot more requirements its trying to address.
Cheers,
L.
--
Leigh Dodds
Freelance Technologist
Open Data, Linked Data Geek
t: @ldodds
w: ldodds.com <http://ldodds.com>
e: [email protected] <mailto:[email protected]>
--
*Richard Light*
