- From: adasal <adam.saltiel@gmail.com>
- Date: Tue, 23 Nov 2010 10:46:13 +0000
- To: Stephen Williams <sdw@lig.net>, Melvin Carvalho <melvincarvalho@gmail.com>, ProjectParadigm-ICT-Program <metadataportals@yahoo.com>, Leo Sauermann <leo.sauermann@gnowsis.com>, SWIG <semantic-web@w3.org>, Juan Sequeda <juanfederico@gmail.com>
Hi Stephen I will look at the reference and come back to you. I understand you to be indicating that the triple store back end in the Berlin benchmarks is a naïve implementation. Have I understood? If so could you elaborate? Are there OS alternatives? Without reading through again I thought it was Jena backed by Postgres. I thought Jena was acting as an ORM autocreating the table schema. As I say I don't have info in front of me. Every bit of knowledge here is a valuable nugget at the moment. Thanks. Adam On 22/11/2010, Stephen Williams <sdw@lig.net> wrote: > On 11/22/10 2:01 PM, adasal wrote: >> On 22 November 2010 18:19, Stephen Williams <sdw@lig.net >> <mailto:sdw@lig.net>> wrote: >> >> Getting the enabling technology and paradigms right is a prerequisite >> for such a solution, but they are not sufficient. >> Jumping beyond our current plateau is going to take more than the >> simple application veneer that were enough for most >> generations of solutions. Too many people are constrained to thinking >> in the language of existing software elements. This >> shows even with techies by the slow adoption of triplestores / SPARQL >> / et al vs. RDBMS systems, which are clearly deficient. >> >> >> They are not in the least obviously deficient. They are extremely >> efficient and timely in what they deliver. Triple store returns >> results in slow motion compared to RDBS. Look at the Berlin benchmarks. > > Not all applications are performance intensive. Sometimes, the worst > bottlenecks are development, evolution, flexibility, and > maintenance. RDBMS is a poor model for many things, with current > applications force fitting models into it. In the March Berlin > benchmark [1], if you look at the D2R SPARQL->RDBMS mapping, you can see one > solution to having an efficient SPARQL database. It's > not the model that is bad, it is the naive implementation. We are certainly > going to find multiple solutions to data clustering > that will provide high performance. Another thing to keep in mind is that > the market moved from hierarchical databases to > relational even though there was a performance loss. > >> Notice what project inspired those benchmarks. >> Where is this plateau I am jumping beyond? I'm not sure I have reached it >> yet. >> This is the language of a convinced evangelist. But it isn't a convincing >> rational argument. >> >> Adam > [1] > http://www4.wiwiss.fu-berlin.de/bizer/BerlinSPARQLBenchmark/results/index.html > > Stephen > -- > Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com LinkedIn: > http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX > V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet > Resume: http://sdw.st/gres Personal: http://sdw.st > facebook.com/sdwlig twitter.com/scienteer > -- Sent from my mobile device
Received on Tuesday, 23 November 2010 10:46:48 UTC