EU PROJECT NETWORKING SESSION @ ESWC2013. May 28, 2013. Montpellier, France.
http://2013.eswc-conferences.org/program/eu-project-networking
CALL FOR EU PROJECT NETWORKING
The EU project networking track of the ESWC2013 will provide an opportunity for
* Knowledge sharing among EU projects
*
(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 :-) )
Thanks Barry.
Thanks, Luca for adding the examples to the page.
Is there any reason why you don't provide a predicate
Hi Hugh,
On Thu, Apr 18, 2013 at 10:56 AM, Hugh Glaser h...@ecs.soton.ac.uk 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
Someone starts a thread (in this case Luca and his Restpark), about something
they would like to get some feedback on.
In the very first reply, an issue arises that is at best tangential to the
thread subject, but (in my opinion) has no direct bearing on it:
issues around SPARQL scales? and
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
Hi Leigh
The problem is that it's really easy to write sparql queries that are
inefficient when you don't know the data [1] and even when you do the
flexibility of sparql means that people can easily end-up writing complex
hard to process queries.
What we've found in the Open Phacts project is
Completely agree Hugh, lets make sure we stick to the thread.
Gio
On Thu, Apr 18, 2013 at 11:41 AM, Hugh Glaser h...@ecs.soton.ac.uk wrote:
Someone starts a thread (in this case Luca and his Restpark), about something
they would like to get some feedback on.
In the very first reply, an issue
Hi Luc,
We use the Linked Data API at : http://code.google.com/p/linked-data-api/
and it's php implementation puelia: http://code.google.com/p/puelia-php/
There's also a java implementation.
The linked data platform is another thing: see http://www.w3.org/TR/ldp/
Thanks
Paul
On Thu, Apr 18,
Hi Paul,
On Thu, Apr 18, 2013 at 11:54 AM, Paul Groth p.t.gr...@vu.nl wrote:
Hi Leigh
The problem is that it's really easy to write sparql queries that are
inefficient when you don't know the data [1] and even when you do the
flexibility of sparql means that people can easily end-up writing
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
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
On 4/18/13 6:41 AM, Hugh Glaser wrote:
Someone starts a thread (in this case Luca and his Restpark), about something
they would like to get some feedback on.
In the very first reply, an issue arises that is at best tangential to the
thread subject, but (in my opinion) has no direct bearing on
On 4/18/13 6:27 AM, Leigh Dodds wrote:
Hi Hugh,
On Thu, Apr 18, 2013 at 10:56 AM, Hugh Glaser h...@ecs.soton.ac.uk 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
On 18/04/13 11:56, Paul Groth wrote:
There's also a java implementation.
ELDA:
http://code.google.com/p/elda/
Andy
Hi,
On Thu, Apr 18, 2013 at 12:01 PM, Luca Matteis lmatt...@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.
Hi Luca,
Sure you could implement this over a regular database... but you get
benefits of using SPARQL and RDF, namely, the flexibility of the data
model.
You want to change your schema and more data you just bang it in the triple
store and modify your query a bit. No need to change your schema
On 4/18/13 6:54 AM, Paul Groth wrote:
Hi Leigh
The problem is that it's really easy to write sparql queries that are
inefficient when you don't know the data [1] and even when you do the
flexibility of sparql means that people can easily end-up writing
complex hard to process queries.
What
i think there's yet another point overlooked :
what we are trying to do is to create barrier free means of
communication on data level in a globalized world. this effort requires
a common language.
my personal view is that providing simplier subsets of such a language
(an api) only leads to the
On 18 Apr 2013, at 12:10, Paul Groth p.t.gr...@vu.nl
wrote:
Hi Luca,
Sure you could implement this over a regular database... but you get benefits
of using SPARQL and RDF, namely, the flexibility of the data model.
You want to change your schema and more data you just bang it in the
Hi,
On Thu, Apr 18, 2013 at 12:21 PM, Jürgen Jakobitsch SWC
j.jakobit...@semantic-web.at wrote:
i think there's yet another point overlooked :
what we are trying to do is to create barrier free means of
communication on data level in a globalized world. this effort requires
a common
How about the fact that SPARQL is very complex to implement on top of
existing storage solutions? You need to use a proper triple store (RDF
database such as Virtuoso), and be sure it implements all of SPARQL
features correctly.
Having a lightweight alternative to SPARQL which developers could
Greetings,
I haven't been following the original thread, so I'm responding just to
Jürgen's point here.
On 2013 Apr 18, at 12:21, Jürgen Jakobitsch SWC wrote:
i do not really understand where this the developer can't sparql, so
let's provide something similar (easier) - idea comes from.
Hi All,
Managing a public SPARQL endpoint has some difficulties in comparison to
managing a simpler REST api.
Instead of counting api calls or external bandwidth use we need to look at
internal IO and CPU usage as well.
Many of the current public SPARQL endpoints limit all their users to
On 4/18/13 7:44 AM, Leigh Dodds wrote:
But I bet you learnt it in stages using a pedagogical approach that
guided you towards the basic building blocks first. And I expect there
were other reasons -- network effects -- why learning English was
worth up-front effort. We're not there with SPARQL.
On 4/18/13 7:46 AM, Luca Matteis wrote:
How about the fact that SPARQL is very complex to implement on top of
existing storage solutions? You need to use a proper triple store (RDF
database such as Virtuoso), and be sure it implements all of SPARQL
features correctly.
What does that mean?
Having a lightweight alternative to SPARQL which developers could
implement themselves on top of their existing storage solution (MySQL,
MongoDB, etc.) using the language they want (PHP, Java, Node.js), would
lower the entry barrier for Semantic Web data understanding and
retrieval.
you might be
On 4/18/13 7:48 AM, Norman Gray wrote:
Greetings,
I haven't been following the original thread, so I'm responding just to
Jürgen's point here.
On 2013 Apr 18, at 12:21, Jürgen Jakobitsch SWC wrote:
i do not really understand where this the developer can't sparql, so
let's provide something
On 4/18/13 7:53 AM, Jerven Bolleman wrote:
Hi All,
Managing a public SPARQL endpoint has some difficulties in comparison to
managing a simpler REST api.
Instead of counting api calls or external bandwidth use we need to look at
internal IO and CPU usage as well.
Many of the current public
Hi,
I think that some caching with a minimum of query rewriting would get read of
90% of the select{?s ?p ?o} where {?s?p ?o} queries.
From a user perspective, I would rather have a clear result code upfront
telling me: your query is to heavy, not enough resources and so on, than
partial
Hi,
my personal view is that providing simplier subsets of such a
language (an api) only leads to the fact that nobody will learn the
language (see pocket calculators,...)
This totally depends on the use case. Simpler subsets may not be
powerful enough for use cases, and I guess people will
Hi All,
On Apr 18, 2013, at 3:23 PM, Andrea Splendiani wrote:
Hi,
I think that some caching with a minimum of query rewriting would get read of
90% of the select{?s ?p ?o} where {?s?p ?o} queries.
We have some caching on the uniprot side. But as all queries are nearly unique
result caching
Guys, it's also about making things simpler. Sure SPARQL works and it's a
great things to have. But we (Semantic Web community) should thrive for
simplicity. And for this matter REST is simpler than SPARQL - that's just
the way it is.
On Thu, Apr 18, 2013 at 4:21 PM, Mark Baker dist...@acm.org
REST is simpler than SPARQL
I have difficulty taking you seriously: SPARQL Graph Store Protocol is a
great deal simpler and more RESTful than what you propose and the
difference between that and something actually RESTful is complicated.
Sorry, I have every sympathy for what Hugh said, but
On 18/04/2013 15:35, Jürgen Jakobitsch SWC wrote:
I think the problem is that many people (especially web developers) have
not yet realized that SPARQL *IS* already a REST API
May I rephrase? SPARQL is already at least as close to a subset of REST
principles as 90% of what the Web calls
Hi Mark,
GET /projects?partners=frextrafields=funding HTTP/1.0
Granted, this covers one set of use cases. I guess this boils down to
the discussion of when we will see the SPARQL killer app.
So can treat RDF data as a data cube (i.e. multi dimensional data; even
without any special vocab).
On 17/04/13 15:08, Luca Matteis wrote:
I have realized that Restpark might be duplication of an idea that is
already the Linked Data Platform itself.
Just a very basic question: with Linked Data how do I find all of the
instances within DBpedia (for example) of type
On 4/18/13 9:23 AM, Andrea Splendiani wrote:
Hi,
I think that some caching with a minimum of query rewriting would get read of
90% of the select{?s ?p ?o} where {?s?p ?o} queries.
Sorta.
Client queries are inherently unpredictable. That's always been the
case, and that predates SPARQL.
On 4/18/13 10:21 AM, Mark Baker wrote:
On Thu, Apr 18, 2013 at 9:46 AM, Claus Stadler
cstad...@informatik.uni-leipzig.de wrote:
For example:
Show me projects, corresponding partners in France and their amount of
funding. Whats missing in SemMap is just adding UI elements that add
sorting and
This parameterised pre-stored (and approved) query idea has come up a
few times.
My favourite name for it is Talis' 'SPARQL Stored Procedure' (though
it's by far from a perfect analogy, it's catchy).
The version I pushed in 'Linked Open Services' research, and which the
BBC use in
On 4/18/13 10:31 AM, Barry Norton wrote:
REST is simpler than SPARQL
I have difficulty taking you seriously: SPARQL Graph Store Protocol is
a great deal simpler and more RESTful than what you propose and the
difference between that and something actually RESTful is complicated.
Sorry, I
On 4/18/13 10:41 AM, Barry Norton wrote:
On 18/04/2013 15:35, Jürgen Jakobitsch SWC wrote:
I think the problem is that many people (especially web developers) have
not yet realized that SPARQL *IS* already a REST API
May I rephrase? SPARQL is already at least as close to a subset of
REST
On Thu, Apr 18, 2013 at 7:53 AM, Jerven Bolleman jerven.bolle...@isb-sib.ch
wrote:
Last but not least how can we avoid that users need to run SELECT
(COUNT(DISTINT(?s) as ?sc} WHERE {?s ?p ?o} and friends.
I am interested in why queries like this are not optimized. Seems to me
that this
On Thu, Apr 18, 2013 at 10:41 AM, Barry Norton
barry.nor...@ontotext.com wrote:
On 18/04/2013 15:35, Jürgen Jakobitsch SWC wrote:
I think the problem is that many people (especially web developers) have
not yet realized that SPARQL *IS* already a REST API
May I rephrase? SPARQL is already
On Thu, Apr 18, 2013 at 11:31 AM, Barry Norton barry.nor...@ontotext.comwrote:
This parameterised pre-stored (and approved) query idea has come up a few
times.
My favourite name for it is Talis' 'SPARQL Stored Procedure' (though it's
by far from a perfect analogy, it's catchy).
The
Hi,
On Thu, Apr 18, 2013 at 4:23 PM, Alan Ruttenberg
alanruttenb...@gmail.com wrote:
Luca,
In the past I have suggested a simple way to create simple restful services
based on SPARQL. This could easily be implemented as an extension to your
beginning of restpark.
The idea is to have the
45 matches
Mail list logo
