- From: Ivan Mikhailov <imikhailov@openlinksw.com>
- Date: Sat, 14 Mar 2009 11:39:07 +0600
- To: Steve Harris <steve.harris@garlik.com>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
> >> I don't think I agree that optimization and implementation effort > >> (which is > >> a direct consequence of the complexity introduced by more > >> expressive query > >> forms such as sub-selects) should *not* be a factor. > > > > I'd say even more. > > > > Optimization and implementation effort must be ignored as decision > > factor, "must" in its ultimate, RFC 2119 meaning. > > I'm not sure I agree. Implementation effort is certainly relevant, > there is no point try to specify a feature that not enough people will > implement to make it to rec. Optimisation effort is a different matter. For Virtuoso, the implementation of RDF storage + SPARQL + most of extensions proposed for SPARQL 2.0 + mapping relational sources to RDF plus support of RDF-specific data types in SQL run-time engine took 2 years of 2 developers, grand total. That's twice cheaper than XML + XSLT + XQuery. It's hard to say that XSLT/XQuery is so complicated that it repelled developers, so why should I worry about "internal complexity" of RDF+SPARQL if the feature is so inexpensive? Looking from a different angle, SPARQL with all proposed extensions is no more complicated than SQL. Current implementations of SQL are numerous enough to confirm that the complexity is not a blocking issue. That's funny, my incompetence improves the accuracy of my estimate. I've never looked at RDF before this SPARQL work, I had "C" in databases, most of my CV is about power plant equipment and CAD and other sorts of engineering. I'm definitely the worst case. Nevertheless, the "extended SPARQL" implementation was affordable for me. Should I expect troubles for database / knowledge base professionals? Best Regards, Ivan Mikhailov OpenLink Software http://virtuoso.openlinksw.com
Received on Saturday, 14 March 2009 05:39:45 UTC