Things aren’t difficult to do, but until they’re done, and regularly, advocating SPARQL-as-query-solution is dangerous and probably not the best way to do it.

I implemented it 2 years ago for RDQL in Jena exactly like Rich suggest. Took me one day. CrSchmidt, your example is not very good as it can be easily avoided by kindergarden style triple reordering. The real lame-ness of SPARQL starts when you do graph origin questions in combination with optional joins, groups and fulltext stuff. then you can restart julie instantly.

But these things will be solved, the standard is very good and its optimisable, database guys have been doing this for years. Good to write about sparql anyhow.

In general, triple patterns should be resolved in order of ‘completeness’ — ‘check’ patterns (those with no variables) should always be run first, as they can short-cut the query. The remaining patterns should be refined in order to produce as few matches as possible (which, all else being equal, means running 1-var, then 2-var, then 3-var matches in that order). It would perhaps be beneficial to allow smart optimisation under normal circumstances, with user-specified optimisation for cases where you can take more time.

I think you’re quite right that SPARQL is not a data access panacea. (I’d also like to see a comparison with paths, which are a common use-case.)

John Barstow has a short entry about why he thinks that the relational database will lose ground to RDF based…

The biggest reason I advise against SPARQL (without due consideration) is that so many aspects of data modelling are ignored if you simply use SPARQL. If you have a good model, you really don’t *need* to use it for the most part. I’ll explain this a bit more:

If I have a SPARQL query to populate my variables, I’m probably going to use a specific query, a la:

SELECT ?nick, ?name WHERE { ?p foaf:nick ?nick; foaf:name ?name. }

Now, if someone adds an additional property to ?p, I won’t know about it. I think if someone uses a non-SPARQL solution — iterating over triples fetch from a data store, rather than just fetching the specific triples — they’ll be more likely to be aware of those triples and able to do something with them. And once you’re iterating over a set of results that simple, there’s actually more work in the building up of a query than there is otherwise!

I do believe SPARQL has some great uses, but I just don’t want people to keep thinking that SPARQL makes things easier for implementors. I suppose it’s possible that it’s just me, but other than some easier syntax, SPARQL queries don’t make things much easier. Cleaner, shorter code wise, possibly. Easier, not in my opinion.

I think for developing, once you build a good model, SPARQL isn’t going to help you out much. If you can get a unique identifier that you know ahead of time, then you can easily iterate over the statements in the model attached to that key - and you don’t have to mess with the speed of SPARQL, nor do you have to worry that some additional data that got snuck in is going to get in your way.

My main concern is just with marketing right now though. Something that for most people is going to *look* significantly slower for no discernable reason (people are used to SQL, where you can’t really give it a query that it won’t optimize) is going to make pushing SPARQL or anything else much more difficult in the long run.

But having said all that, I’ll throw in some more caveats next time I’ve got the cheerleader’s poms-poms

However, in the short term, telling people “Just use SPARQL” as a pancea is misleading, and I think leads more to hinder the efforts of those people trying to encourage using RDF as a database. The real answer is to evaluate the tools to find which best meets your needs as far as performance and other needs goes. (If you need to store it in MySQL, you’re limited by certain constraints, if you can’t use BDB for some reason, etc.) However, no matter what, it is probably better to have people at least look at how the underlying triplestores are implementing these queries before using it as a solution. Currently, I’m not aware of any public implementations that have advertised high speeds and reliability in the way neccesary for SPARQL to come out as a solution for many of the use cases it’s proposed for, imho.

Of course, some people may have contradictory evidence. Leigh mentioned his 200 megatriple store, Swoogle I’m sure has a lot more than the 10 megatriple dump they shared, but I don’t know if they’re using SPARQL at all in the backend. Thus far, I haven’t seen a single case where someone has specifically stated that they are using a SPARQL-based query engine at the core of an application.

One other approach is to turn SPARQL queries into SQL ones over an underlying relational store, and then you can benefit from the years^wdecades of work in that field. This is already starting to be demonstrated and coming together by various people (Jena, 3store, rdfstore, algae) and I’d expect to see more public demonstrations of this in a few months.

Finally, the SQL schema for storing RDF can be a lot better than the example given above, fixed limit URI lengths considered,er, harmful There are papers in the literature.

I’ve often had to reimplement standard functions (such as type, which is supposed to return all rdf:Resources of a given rdf:type) to take advantage of datastore specific mechanics.

I think the main problem is that most current RDF datastores map the RDF data model to RDBMS as 3 - 4 column tables (w/ slight variations with each implementation). See Redland’s MySQL schema (this may be dated) and 4RDFs (below).

CREATE TABLE ftrdf_%s_statement (
    subject       varchar(150) not NULL,
    predicate     varchar(150) not NULL,
    object        text,
    statementUri  varchar(45) not NULL,
    domain        text,
    otype         varchar(5) not NULL,
    INDEX %s_stmt_spd_index (subject(100),predicate(100),domain(50)),
    INDEX %s_stmt_pod_index (predicate(100),object(50),domain(50)),
    INDEX %s_stmt_d_index (domain(10))) TYPE=InnoDB

This simply does not scale due to the redundancy or repeating resources URI’s for each statement made about them as well as relying *completely* on the underlying indexing capabilities to locate statements by parts.

I believe Oracles approach will solve what amounts to an ‘engineering’ problem in the standard way RDF datastores implement ontop of RDBMS. Primarily, it stores RDF URI’s once only. This is almost half the scalability issue alone. RDF datastores will always have a ceiling (much lower than its predecessor database systems), but the current implementations have that ceiling much lower than is feasible for solving ‘real world’ problems. It shifts the emphasis to the how sophisticated the queries are and how the query optimizers execute such queries. It will be the same with *all* RDF querying languages until the datastore implementations catch up.