Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SPARQL Protocol for RDF

w3.org

Post reply on HN
Print view View original

21–30 of 53 posts

Re: SPARQL Protocol for RDF

#21

Post by nl »

mindcrime wrote: post #19
rspeer wrote: post #10

Earlier quoted context omitted.

What were your triple stores running on? A database, right? Do your SPARQL queries turn into anything within orders of magnitude of an efficiently indexed SQL query when they get to the database?

Triple-stores can, but don't necessarily, layer on top of SQL databases. Jena has (had?) a triple-store engine that used JDBC to store the triples in a traditional relational database, but it's been deprecated for years in favor of a specialized engine designed specifically for storing RDF. I can't speak for other triple-stores as Jena is what we use, but I can say that comparing SPARQL queries against Jena TDB to SQ…

comparing SPARQL queries against Jena TDB to SQL queries on MySQL or Postgres is like comparing apples and kangaroos.

In the sense that apples rot and Kangraroos are amazing animals which can do just about anything?

Because otherwise the comparison seems completely apt.

Jena works for RDF data. But the OP is correct in their broader point that RDF is rarely a good choice and SPARQL is a pretty horrible solution for querying it.

Note that the reply someone is about to write ("But RDF is a generalized self descriptive data model") means it is intended to solve the exact problem that a RDBMS+SQL solves. And if you add the "standardized fields" thing it also matches the REST interface+RDBMS+SQL comparison the OP made.

Re: SPARQL Protocol for RDF

#22

Post by linkmotif »

handojin wrote: post #12
linkmotif wrote: post #9

Earlier quoted context omitted.

GraphQL, though, is a bit of a lie nomenclature-wise. As I've experienced it, it's got nothing much to do with graphs, at least not in the sense that SPARQL deals with triples that form a graph. In this department I am really interested in TinkerPop [0]. I would love, some day, to spend some more time with triple stores, RDF and semantic technologies. [0] http://tinkerpop.apache.org/docs/current/reference/

You might really enjoy datomic (www.datomic.com). Everything is stored as entity attribute value time and you query with a dialect of datalog. You can check out www.learndatalogtoday.org to get a flavor.

Prolog and datalog ae really high on my list. Thanks for the reminder!

Datomic, though... wish there was an OSS version or CE or something.

Re: SPARQL Protocol for RDF

#23

Post by lemmsjid »

rspeer wrote: post #10
lemmsjid wrote: post #7

Earlier quoted context omitted.

I'm confused. Isn't SPARQL a query language for RDF? I've used SPARQL extensively against triple stores. It's quite handy and pretty easy to pick up once you grok how RDF is structured. I wouldn't even compare it with the concept of RESTful APIs--they're attacking two different problems.

What were your triple stores running on? A database, right? Do your SPARQL queries turn into anything within orders of magnitude of an efficiently indexed SQL query when they get to the database?

I think we're thinking of different use cases and therefore talking past one another. My SPARQL usage was not using an rdbms under the covers and was explicitly using RDF data. Querying triple data in SQL would be quite clumsy except in the simplest usages, hence the existence of SPARQL. I have seen the libraries that can run SPARQL against an rdbms (for example the 3 or 4 column indexed table that would represent triples or quads). I would imagine performance would be an issue there--but for me rdf has mainly been around aggregating and exploring data, if I need to scale to massive queries per second I'd use something else.

Re: SPARQL Protocol for RDF

#24

Post by barakm »

ghukill wrote: post #6

Are there queries that SPARQL can perform over a triplestore that cannot be done with SQL over normalized data? Perhaps not. But data normalization to that end is a moving target, while a bag of subject-predicate-object statements are quite doable. This, I believe, is a uniquely powerful characteristic of linked data / graph query languages and protocols. To that end, agree with the comment above that GraphQL is migh…

+1 Insightful. In fact, there's research toward showing the two are equivalent in possibility space of what can be represented/queried (https://arxiv.org/abs/1102.1889)

But yes, linked data and graphs are super powerful once the data is triplified. Suddenly you have an abstraction above the contents of your data into the 'shape' of your data.

SPARQL and RDF aren't going away, but they're the academic thing that I and others are trying to make useful. GraphQL is scratching the surface, but it's super exciting that it's scratching at all, imo.

(Disclosure: Founded CayleyGraph, supporting the open source https://github.com/cayleygraph/cayley, which I maintain and mostly wrote)

Re: SPARQL Protocol for RDF

#25

Post by dnt404-1 »

Anybody can share some light on companies that uses semantic web technologies? Currently at university have a semantic web class but I am finding it difficult where the use case are to create value for business or startup.

Re: SPARQL Protocol for RDF

#26

Post by tannhaeuser »

dnt404-1 wrote: post #25

Anybody can share some light on companies that uses semantic web technologies? Currently at university have a semantic web class but I am finding it difficult where the use case are to create value for business or startup.

Facebook Open Graph crawlers use RDF in HTML head-meta elements conveying data about authors of web pages.

Similarly, Google Corporate Contacts extracts RDF from web pages (but can also use JSON microdata).

W3C's newly published open social standard is based on RDF (as JSON-LD) I believe.

RDF and SPARQL has lots of uses in libraries and bibliographic apps such as citation managers, as well as in publication of open data, in particular medical and bio informatics data.

Dublin Core (as RDF) is frequently used for standard document metadata, for example in PDF.

Re: SPARQL Protocol for RDF

#27

Post by dragonwriter »

rspeer wrote: post #2

SPARQL is what happens when you try to define an API for doing everything, from abstract principles, and end up with an API that does nothing. It wraps your database in a worse database with a worse query language. It makes simple queries into kilobyte-long GET query strings that get morasses of XML-namespace nonsense as a response, or more likely, a server timeout. While the W3C was screwing around with SPARQL, ever…

> It wraps your database in a worse database with a worse query language.

SPARQL doesn't necessarily wrap a database with a different underlying query language. And it's a much better query language than SQL for RDF data.

> It makes simple queries into kilobyte-long GET query strings

Don't do that. I mean, seriously, the protocol supports queries with GET, but it also supports t o different mechanisms for querying over POST.

> that get morasses of XML-namespace nonsense as a response

SPARQL does not mandate XML responses (for graph responses, it doesn't specify a non-XML serialization, but still on requires RDF/XML or a semantically equivalent structure. For other responses, there are defined JASON, XML, and CSV/TSV formats.

> While the W3C was screwing around with SPARQL, everyone else came up with JSON-based REST APIs.

SPARQL's defined API is more REST than most of those.

> They work well.

Not for the purpose SPARQL is aimed at, which is—admittedly—not a particularly common use case, and certainly not what your typical web service needs.

Re: SPARQL Protocol for RDF

#28

Post by dragonwriter »

rspeer wrote: post #10
lemmsjid wrote: post #7

Earlier quoted context omitted.

I'm confused. Isn't SPARQL a query language for RDF? I've used SPARQL extensively against triple stores. It's quite handy and pretty easy to pick up once you grok how RDF is structured. I wouldn't even compare it with the concept of RESTful APIs--they're attacking two different problems.

What were your triple stores running on? A database, right? Do your SPARQL queries turn into anything within orders of magnitude of an efficiently indexed SQL query when they get to the database?

> Do your SPARQL queries turn into anything within orders of magnitude of an efficiently indexed SQL query when they get to the database?

Probably more efficient, if it's an RDF- (or EAV) oriented datastore underneath, and merely similarly efficient if it's actually layered on top of SQL.

Re: SPARQL Protocol for RDF

#29

Post by dragonwriter »

nl wrote: post #21
mindcrime wrote: post #19

Earlier quoted context omitted.

Triple-stores can, but don't necessarily, layer on top of SQL databases. Jena has (had?) a triple-store engine that used JDBC to store the triples in a traditional relational database, but it's been deprecated for years in favor of a specialized engine designed specifically for storing RDF. I can't speak for other triple-stores as Jena is what we use, but I can say that comparing SPARQL queries against Jena TDB to SQ…

comparing SPARQL queries against Jena TDB to SQL queries on MySQL or Postgres is like comparing apples and kangaroos. In the sense that apples rot and Kangraroos are amazing animals which can do just about anything? Because otherwise the comparison seems completely apt. Jena works for RDF data. But the OP is correct in their broader point that RDF is rarely a good choice and SPARQL is a pretty horrible solution for q…

> But the OP is correct in their broader point that RDF is rarely a good choice and SPARQL is a pretty horrible solution for querying it.

SPARQL is an excellent choice for querying RDF data (SQL is usable but awkward for querying EAV structured data).

> Note that the reply someone is about to write ("But RDF is a generalized self descriptive data model") means it is intended to solve the exact problem that a RDBMS+SQL solves.

RDF/EAV is more graph than relational structured. It doesn't solve the exact same problem.

Re: SPARQL Protocol for RDF

#30

Post by dragonwriter »

rspeer wrote: post #13
hcarvalhoalves wrote: post #11

Earlier quoted context omitted.

Comparing SPARQL to REST doesn't make sense. RDF is a different beast.

The linked article is describing a world where you encode SPARQL in HTTP query parameters and get back RDF+XML. It really is attempting to be an API for querying everything, but querying nothing well. You can write reasonable REST APIs for RDF. You can even formalize it with JSON-LD if you care to.

> You can write reasonable REST APIs for RDF.

The specification for SPARQL over HTTP is a reasonable REST API for RDF. (Though it highlights the need for a safe HTTP method like GET but with a request body, and overloads POST for queries for that purpose in addition to the god-awful query-string GET encoding.)

It's not JSON-for-all-the-things, but JSON is a stupid way of encoding a general-purpose query language. It does support JSON (among other encodings) for responses, though.

Post reply on HN