- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 17 Apr 2013 18:44:07 -0400
- To: public-lod@w3.org
- Message-ID: <516F25B7.7080506@openlinksw.com>
On 4/17/13 3:35 PM, Michael Brunnbauer wrote: > Hello Kingsley, > > On Wed, Apr 17, 2013 at 02:58:18PM -0400, Kingsley Idehen wrote: >> This is all about scalability ultimately being out of the hands of >> SPARQL and placed back into the hands of computing resources (which >> includes: the SPARQL processor, host operating system memory, and >> hardware components such as CPU, disk, interconnects etc..). > But those resources only scale by adding more computers. If the problem > cannot be effectively parallelized, you are lost at some point. Yes, but what is it that cannot be effectively parallelized in the context of a useful SPARQL query? For example, given a corpus of 50 billion+ 3-tuple based relations, is disambiguating patterns such as "China", "New York", "Paris Hilton" , "Database", "Gene" , "Protein" useful enough to demonstrate the concept of "anytime queries" that leverages a share-nothing cluster, key compression, vectorized query processing, and an expanding query timeout? Live links from a live instance (note the footer for resource utilization and query timing etc..): 1. http://bit.ly/11et1s8 -- New York 2. http://bit.ly/1747mFc -- Protein 3. http://bit.ly/14x0Edj -- Gene 4. http://bit.ly/11isrs6 -- Database 5. http://bit.ly/11xnzQT -- Paris 6. http://bit.ly/12SIvWc -- China > Or did you > prove that NC = P (Seehttp://en.wikipedia.org/wiki/P-complete) ? > > Regards, > > Michael Brunnbauer > > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web:http://www.openlinksw.com Personal Weblog:http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile:https://plus.google.com/112399767740508618350/about LinkedIn Profile:http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 17 April 2013 22:44:29 UTC