DabbleDB vs. Exhibit
by Bijan Parsia
I’ve recently been playing with DabbleDB vs. Exhibit. A few points of comparison:
DabbleDB is server based and centralized; Exhibit is page/browser based and thus decentralized.
DabbleDB certainly scales better on a number of fronts.
DabbleDB is based on a DBMS. Exhibit has a very lightweight, in memory database.
DabbleDB has an authoring UI. Exhibit, afaict, doesn’t. In DabbleDB the author/reshaping/exploring aspects are all pretty seamless and damn slick.
DabbleDB is “more relational” whereas Exhibit is based on a “graph database”. This is a fuzzy distinction, really.
Neither exports, or is based on, RDF. DabbleDB exports to a wide varient of formats, but seems mostly, deep down, centered on comma separated values. Exhibit works on JSON.
Since DabbleDB exports to JSON, they should be pretty easy to combine. Use Dabble to build and massage the dataset, and use Exhibit to publish.
My scratch assessment is that moving either to RDF seems like it would be hugely painful, and painful exactly at the points of pride for RDF. Put aside RDF/XML, or even Turtle (though, really, Turtle would probably be better than NTriples). The URIs everywhere alone would make so much of this very painful. (You could work around it, esp. since both are Web based which would let you do something with relative URIs.) The lack of true container/record syntax would be pretty damn annoying as well. Let’s not even get started on literals! (Data values are perhaps dominant in (at least) DabbleDB.)
Oh, DabbleDB is written in Smalltalk, woohoo!
Update (from comments
Correction: So, I was wrong that Exhibit, at least, fails to export to RDF (thanks to drewp, Danny, and dfhuynh for the correction). And it’s not like it wouldn’t be pretty easy to export DabbleDB to RDF either. And, as Danny points out (and is implied above), Exhibit claims to be working in an RDFish manner (graph database and all).
And Danny asks: “What kind of applications have you got in mind for either, in which a syntax mapping to/from RDF wouldn’t suffice?”
My point above wasn’t that you couldn’t scrape to RDF, but that neither is built around RDF per se. I.e., why aren’t either of these built around RDF? I know Exhibit is “built around a subset of the RDF data model”, but I’m not sure I believe that. For example, in the Exhibit paper we read:
Some of the Semantic Web faithful might dismiss our contention that Exhibit is a Semantic Web application. Where is the RDF? ... In response, we observe, first, that the RDF is in plain sight: it is the model being instantiated by each exhibit. We have simply chosen to offer a different syntax—other than the standard RDF/XML and more recent N3—for expressing that model. Granted, our syntax cannot express arbitrary RDF. However, we have accepted this limitation in pursuit of a simpler syntax that can be authored by less-skilled users.
Am I a SemWeb faithful so dismissing them? I guess, though my point is not to criticize the choices Exhibit made but to use their choices to highlight what I think are problems with RDF. It would be, of course, insanity to suggest that either exhibit or DabbleDB couldn’t be built on RDF per se, I just believe that it would be more painful, even for experienced RDF nuts, and that the result wouldn’t be all that much better and the Exhibit data model looks more appealing to me for a variety of tasks. For example, it definitely has real structure. (Each item is a record.) While you can ape that in RDF, it’s not actually how RDF works. I suspect that makes a difference.
(This is all impressiony stuff, in the end. But I’m working on collecting some data on Turing Award winners to put together a little site and my first impression is that I’d much rather use Exhibit or DabbleDB than RDF as my working toolkit.)
March 13th, 2007 at 4:02 pm
Thanks for writing this up. I’m a fan and user of exhibit, and just a fan of dabbledb.
I’d like to mention that exhibit has a trivial rdf export, which I’ve never used. Click ‘Copy All’ at the top, pick rdf, and you’ll get some generic RDF/XML where the property names seem to be fragments off the url of the exhibit’s page. That might be decent, but it’s obviously not flexible enough for fancier applications (e.g. where the property names came from multiple RDF sources).
For import, simile also has http://simile.mit.edu/babel/ which I have not checked out yet. It claims to convert RDF/XML to JSON for exhibit. I’m also not sure if you can build the babel call into your exhibit page, which would make it look like the exhibit was pulling live RDF on startup.
March 13th, 2007 at 4:02 pm
Thanks for writing this up. I’m a fan and user of exhibit, and just a fan of dabbledb.
I’d like to mention that exhibit has a trivial rdf export, which I’ve never used. Click ‘Copy All’ at the top, pick rdf, and you’ll get some generic RDF/XML where the property names seem to be fragments off the url of the exhibit’s page. That might be decent, but it’s obviously not flexible enough for fancier applications (e.g. where the property names came from multiple RDF sources).
For import, simile also has http://simile.mit.edu/babel/ which I have not checked out yet. It claims to convert RDF/XML to JSON for exhibit. I’m also not sure if you can build the babel call into your exhibit page, which would make it look like the exhibit was pulling live RDF on startup.
March 13th, 2007 at 4:03 pm
Exhibit does claim to be RDFish – from the paper:
[[
The Exhibit abstract data model is essentially the RDF [7] abstract data model except that property values cannot be assigned value types individually. In this way, the Exhibit data model is a sub-model of the RDF data model, less powerful but sufficient for many simple use cases.
]]
I had to be shown this myself, but if you go to e.g. the Presidents demo, and click “Copy All”, there’s the option of RDF/XML.
What kind of applications have you got in mind for either, in which a syntax mapping to/from RDF wouldn’t suffice?
(Smalltalk, woohoo++)
March 13th, 2007 at 4:03 pm
Exhibit does claim to be RDFish – from the paper:
[[
The Exhibit abstract data model is essentially the RDF [7] abstract data model except that property values cannot be assigned value types individually. In this way, the Exhibit data model is a sub-model of the RDF data model, less powerful but sufficient for many simple use cases.
]]
I had to be shown this myself, but if you go to e.g. the Presidents demo, and click “Copy All”, there’s the option of RDF/XML.
What kind of applications have you got in mind for either, in which a syntax mapping to/from RDF wouldn’t suffice?
(Smalltalk, woohoo++)
March 13th, 2007 at 4:21 pm
Bijan, Exhibit does export to a variety of formats, including RDF/XML, N3, Semantic MediaWiki wikitext, JSON, and even Bibtex. The Copy All button lets you pick your format to export. And this is extensible by any person who uses Exhibit. (Good luck if you want to extend DabbleDB.)
A complimentary service called Babel lets you convert between various formats:
http://simile.mit.edu/babel/
In addition, you can hook Exhibit directly to Google Spreadsheets (and in the future, EditGrid):
http://simile.mit.edu/wiki/Exhibit/How_to_make_…;
March 13th, 2007 at 4:21 pm
Bijan, Exhibit does export to a variety of formats, including RDF/XML, N3, Semantic MediaWiki wikitext, JSON, and even Bibtex. The Copy All button lets you pick your format to export. And this is extensible by any person who uses Exhibit. (Good luck if you want to extend DabbleDB.)
A complimentary service called Babel lets you convert between various formats:
http://simile.mit.edu/babel/
In addition, you can hook Exhibit directly to Google Spreadsheets (and in the future, EditGrid):
http://simile.mit.edu/wiki/Exhibit/How_to_make_…;
March 13th, 2007 at 6:02 pm
Thanks for writing this up. I’m a fan and user of exhibit, and just a fan of dabbledb.
I’d like to mention that exhibit has a trivial rdf export, which I’ve never used. Click ‘Copy All’ at the top, pick rdf, and you’ll get some generic RDF/XML where the property names seem to be fragments off the url of the exhibit’s page. That might be decent, but it’s obviously not flexible enough for fancier applications (e.g. where the property names came from multiple RDF sources).
For import, simile also has http://simile.mit.edu/babel/ which I have not checked out yet. It claims to convert RDF/XML to JSON for exhibit. I’m also not sure if you can build the babel call into your exhibit page, which would make it look like the exhibit was pulling live RDF on startup.
March 13th, 2007 at 6:03 pm
Exhibit does claim to be RDFish – from the paper:
[[
The Exhibit abstract data model is essentially the RDF [7] abstract data model except that property values cannot be assigned value types individually. In this way, the Exhibit data model is a sub-model of the RDF data model, less powerful but sufficient for many simple use cases.
]]
I had to be shown this myself, but if you go to e.g. the Presidents demo, and click “Copy All”, there’s the option of RDF/XML.
What kind of applications have you got in mind for either, in which a syntax mapping to/from RDF wouldn’t suffice?
(Smalltalk, woohoo++)
March 13th, 2007 at 6:21 pm
Bijan, Exhibit does export to a variety of formats, including RDF/XML, N3, Semantic MediaWiki wikitext, JSON, and even Bibtex. The Copy All button lets you pick your format to export. And this is extensible by any person who uses Exhibit. (Good luck if you want to extend DabbleDB.)
A complimentary service called Babel lets you convert between various formats:
http://simile.mit.edu/babel/
In addition, you can hook Exhibit directly to Google Spreadsheets (and in the future, EditGrid):
http://simile.mit.edu/wiki/Exhibit/How_to_make_an_exhibit_from_data_fed_directly_from_a_Google_Spreadsheet
March 14th, 2007 at 2:34 am
Thanks for the comments. I updated the main post with a correction about RDF/XML export.
David, you can extend DabbleDB in a variety of ways (and, really, do you need the translators built in, per se?). In particular, you can create a plugin hosted on your site that DabbleDB will call out to. This is definitely weirder and less flexible than Exhibit, but also seems pretty workable for a class of extensions.
March 14th, 2007 at 2:34 am
Thanks for the comments. I updated the main post with a correction about RDF/XML export.
David, you can extend DabbleDB in a variety of ways (and, really, do you need the translators built in, per se?). In particular, you can create a plugin hosted on your site that DabbleDB will call out to. This is definitely weirder and less flexible than Exhibit, but also seems pretty workable for a class of extensions.
March 14th, 2007 at 3:28 am
Bijan, thanks for pointing out DabbleDB’s plugin architecture. I guess I wasn’t as familiar with it as I thought.
It would be illuminating to do a survey on web sites of SemWeb researchers and see how many actually use RDF in the back-end or in the front-end. As you might have noticed from the paper, 7 out of 140 database researchers use databases for their publication web pages :-) So, I totally agree with you about the pains of RDF.
March 14th, 2007 at 3:28 am
Bijan, thanks for pointing out DabbleDB’s plugin architecture. I guess I wasn’t as familiar with it as I thought.
It would be illuminating to do a survey on web sites of SemWeb researchers and see how many actually use RDF in the back-end or in the front-end. As you might have noticed from the paper, 7 out of 140 database researchers use databases for their publication web pages :-) So, I totally agree with you about the pains of RDF.
March 14th, 2007 at 4:34 am
Thanks for the comments. I updated the main post with a correction about RDF/XML export.
David, you can extend DabbleDB in a variety of ways (and, really, do you need the translators built in, per se?). In particular, you can create a plugin hosted on your site that DabbleDB will call out to. This is definitely weirder and less flexible than Exhibit, but also seems pretty workable for a class of extensions.
March 14th, 2007 at 5:28 am
Bijan, thanks for pointing out DabbleDB’s plugin architecture. I guess I wasn’t as familiar with it as I thought.
It would be illuminating to do a survey on web sites of SemWeb researchers and see how many actually use RDF in the back-end or in the front-end. As you might have noticed from the paper, 7 out of 140 database researchers use databases for their publication web pages :-) So, I totally agree with you about the pains of RDF.
March 14th, 2007 at 6:37 am
dfhuynh, DabbleDB seems to be (still) in rapid change mode, so no worries.
I was able to take the tab delimited output of Exhibit and pop it into DabbleDB with ease. Yay. Tab delim rocks! (though the typing is a bit weird…value typing so one could more easily pass, e.g., dates around would be nice)
I don’t know how illuminating that survey would be. I only recently updated my web page (really set up my web page) at Manchester. My CV is perennially out of date. I hate it when, e.g., ISWC forces me to drum up some metadata for a paper I submit. Hate it!
Yet, I would like high quality Bibtex for every paper I find. Citeseer’s is icky (but I use it!) DBLP is nicer (but has some usability issues…those cite keys).
There are lots of little barriers to doing stuff.
OTOH, I now intend to use Exhibit for my pubs (and other aspects of my home page). I was planning to do something neat with Javascript and the HTML, but why build from scratch?
March 14th, 2007 at 6:37 am
dfhuynh, DabbleDB seems to be (still) in rapid change mode, so no worries.
I was able to take the tab delimited output of Exhibit and pop it into DabbleDB with ease. Yay. Tab delim rocks! (though the typing is a bit weird…value typing so one could more easily pass, e.g., dates around would be nice)
I don’t know how illuminating that survey would be. I only recently updated my web page (really set up my web page) at Manchester. My CV is perennially out of date. I hate it when, e.g., ISWC forces me to drum up some metadata for a paper I submit. Hate it!
Yet, I would like high quality Bibtex for every paper I find. Citeseer’s is icky (but I use it!) DBLP is nicer (but has some usability issues…those cite keys).
There are lots of little barriers to doing stuff.
OTOH, I now intend to use Exhibit for my pubs (and other aspects of my home page). I was planning to do something neat with Javascript and the HTML, but why build from scratch?
March 14th, 2007 at 8:37 am
dfhuynh, DabbleDB seems to be (still) in rapid change mode, so no worries.
I was able to take the tab delimited output of Exhibit and pop it into DabbleDB with ease. Yay. Tab delim rocks! (though the typing is a bit weird…value typing so one could more easily pass, e.g., dates around would be nice)
I don’t know how illuminating that survey would be. I only recently updated my web page (really set up my web page) at Manchester. My CV is perennially out of date. I hate it when, e.g., ISWC forces me to drum up some metadata for a paper I submit. Hate it!
Yet, I would like high quality Bibtex for every paper I find. Citeseer’s is icky (but I use it!) DBLP is nicer (but has some usability issues…those cite keys).
There are lots of little barriers to doing stuff.
OTOH, I now intend to use Exhibit for my pubs (and other aspects of my home page). I was planning to do something neat with Javascript and the HTML, but why build from scratch?
March 17th, 2007 at 7:53 am
I’m not absolutely sure, but Exhibit’s structuring of items as records looks to be ‘aped’ too – that is, if you supply two items with the same id, Exhibit will ‘smoosh’ them together. (Is that what you meant by ‘real structure’?)
As for pulling in live RDF data to an Exhibit, you might be interested in a simple script I wrote to bridge generically between Exhibit and a SPARQL endpoint – it takes a template exhibit json file as input, and outputs an exhibit json file full of data.
(See http://semwebdev.keithalexander.co.uk/blog/post…; )
March 17th, 2007 at 7:53 am
I’m not absolutely sure, but Exhibit’s structuring of items as records looks to be ‘aped’ too – that is, if you supply two items with the same id, Exhibit will ‘smoosh’ them together. (Is that what you meant by ‘real structure’?)
As for pulling in live RDF data to an Exhibit, you might be interested in a simple script I wrote to bridge generically between Exhibit and a SPARQL endpoint – it takes a template exhibit json file as input, and outputs an exhibit json file full of data.
(See http://semwebdev.keithalexander.co.uk/blog/post…; )
March 17th, 2007 at 9:53 am
I’m not absolutely sure, but Exhibit’s structuring of items as records looks to be ‘aped’ too – that is, if you supply two items with the same id, Exhibit will ‘smoosh’ them together. (Is that what you meant by ‘real structure’?)
As for pulling in live RDF data to an Exhibit, you might be interested in a simple script I wrote to bridge generically between Exhibit and a SPARQL endpoint – it takes a template exhibit json file as input, and outputs an exhibit json file full of data.
(See http://semwebdev.keithalexander.co.uk/blog/posts/Exhibit-JSON.html )