Thinking Clearly .

In the spirit of my post on DabbleDB and Exhibit, here’s another somewhat arbitrary match up in the newborn category “puerile comparisons”.

XFN (“XHTML Friends Network”) is not obviously pronoucable, where as FOAF leaps trippingly off the tongue.

XFN is a microformat; FOAF is an RDF vocabulary.

XFN is parasitic on/integrted with HTML; FOAF generally isn’t (though you can probably do stuff with RDFa nowadays).

Both seem like minomers: XFN isn’t especially XHTML oriented or limited. FOAF doesn’t have any specific vocabulary for describing friends.

FOAF represents all sorts of information about a person (i.e., subsumes a lot of vCard functionality); XFN is just about relationships (with either half of the relationship left implicit).

I only really noticed XFN because my HTML editor of experimentation (the Nvu family) has nice support on it. So when I put in a link to a person’s homepage, I’m inclined to add a little XFN. I don’t maintain a FOAF file.

Hmm. I wonder why the FOAF empire hasn’t tried to absorb the XFN conceptual structure.

A slick Exhibit template for FOAF data that actually gave me a nice looking and flexible homepage might well tempt me.

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.)