ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] [SMW-devel] [News] Google, Microsoft, Facebook And O

To: ontolog-forum@xxxxxxxxxxxxxxxx
From: John F Sowa <sowa@xxxxxxxxxxx>
Date: Sat, 13 Oct 2012 09:53:32 -0400
Message-id: <5079725C.3030606@xxxxxxxxxxx>
On 10/12/2012 1:15 PM, Michael Brunnbauer wrote:
> The query language may not be the problem. Performance and difficulty
> of modeling data are.    (01)

Yes.  But interoperability is much more than the following:    (02)

> SQL is supported. There are products that offer SQL views over
> triple stores.    (03)

Those products don't support any of Tim's three main requirements.
Instead of diversity, they assume that everything has been mapped
to triples.  There are trillions of dollars of legacy software in
the world that will continue to be used for another 20 to 40 years.    (04)

> And my point about triples vs. n-tuples was that the user would be able to
> choose between tradeoffs with n-tuples. I think we both agree that it would be
> nice if the Semantic Web stack would offer more choices. But ranting about
> missing choices is much easier than implementing them.    (05)

I'm not asking the W3C to implement anything.  My primary complaint is
that the DAML project destroyed diversity.  Instead of heterogeneity,
they require everything to be shoe-horned into triples and described
in OWL.  The W3C can support Tim's vision by declaring that SWeLL is
the logical foundation and it will accept data in any format whatever.    (06)

> No wonder [Stonebraker's VoltDB] is so fast if all the data is in RAM
> and - let me quote from the document - "You are also discouraged
> from doing SUM operations".    (07)

Three points:    (08)

  1. Every DB of any kind -- including VoltDB -- does all processing
     in RAM and keeps all persistent data on disks.    (09)

  2. VoltDB achieves greater speed by doing more processing in RAM,
     by doing more operations in parallel, and by eliminating most
     of the constraints that block parallelism.    (010)

  3. The SUM operation is supported, but it slows things down because
     it forces all the parallel operations to converge to a single
     thread for that step.  In many cases, it's possible to defer
     the single-thread operations to the final stage.    (011)

For Stonebraker's original paper about the approach and a more recent
update, see the following:    (012)

http://static.cs.brown.edu/courses/cs227/papers/newsql/hstore-endofera.pdf
The end of an architectural era:  It's time for a complete rewrite    (013)

http://cacm.acm.org/blogs/blog-cacm/50678-the-nosql-discussion-has-nothing-to-do-with-sql/fulltext
The NoSQL discussion has nothing to do with SQL    (014)

And by the way, Stonebraker was never a fan of SQL.  His original
design for an RDB was Ingres.  Its native language is QUEL, which
is much cleaner than SQL:    (015)

    http://downloads.actian.com/download/quel.pdf
    Ingres 2006, QUEL reference guide    (016)

Stonebraker called SQL Intergalactic Dataspeak, but he implemented
it because he had to.  I like QUEL much better than SQL, but that's
a syntactic preference.  The main point is that the SW must
interoperate with Intergalactic Dataspeak.    (017)

John    (018)

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (019)

<Prev in Thread] Current Thread [Next in Thread>