John F. Sowa wrote:
> Kingsley,
>
> Those kinds of benchmarks have been kicked around for over 30 years,
> and they are just as meaningless today as they ever were.
>
> KI> I really think that when we talk about data integration and the
> > prowess of RDF, OWL, and what can be achieved re. reasoning etc..
> > Best we point to actual data available on the Web.
> >
> > Links:
> >
> > http://www4.wiwiss.fu-berlin.de/bizer/BerlinSPARQLBenchmark/
> > -- SPARQL Benchmark with RDBMS to RDF component
>
> The first point is that there is *zero* logical difference among
> a table-oriented database, a graph-oriented database, a row-oriented
> DB, a column-oriented DB, a DB indexed on various combinations of
> rows or columns, a DB indexed on more complex patterns including
> arbitrary graph structures, etc., etc.
>
> All of those DBs can store exactly the same facts, but with widely
> different performance for various kinds of applications. And there
> are many different kinds of people with widely different needs
> to know about how the DB happens to be organized:
>
> 1. At one extreme are the end users who need answers without having
> to worry about (or even think about) the DB organization.
>
> 2. At the other extreme are the system developers who design the
> access methods underlying the DB. They have an enormous range
> of options, design choices, and optimization techniques that
> have been explored and implemented in an enormous range of
> variations over the past 40 years.
>
> 3. In between, are many software designers, developers, and
> users with varying degrees of knowledge about such issues
> and varying degrees of need to choose among them.
>
> As Tony Hoare, Don Knuth, and many others have emphasized,
> "Premature optimization is the root of all evil."
>
> The decision to force a one-size-fits-all DB organization
> and a query language that is prematurely optimized for
> that organization was *profoundly* foolish.
>
> At VivoMind, we are delighted to see our competitors use SPARQL
> and triple stores, because we can "wipe the floor with them."
>
> John Sowa
>
>
> _________________________________________________________________
> 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
> To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>
>
>
John, (01)
My response is about a single point: you can have a multi-model DBMS
engine. One capable of being optimized for scenarios specific to a given
model. In this case Graph vs Relational. I think we actually agree on
the concept of multi-model DBMS engines, as opposed to one model fits
all, right? (02)
The benchmark reference was/is solely about the above. Beyond that it is
naturally skewed towards what an RDBMS handles best "Close World" where
logical schema is optimized accordingly. Of course, if this benchmark
was truly "Open World" where the essential rule is: schema last since
anything goes but basic shape is E-A-V model (or 3-tuples / triples),
the native RDF stores would have run rings around the DBMS and
Virtuoso's numbers would simply look better under its Native RDF Engine
column relative to its RDF Views over RDBMs (which is just about SPARQL
to SQL and some optimizer tricks under the covers). (03)
-- (04)
Regards, (05)
Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software Web: http://www.openlinksw.com (06)
_________________________________________________________________
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
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (07)
|