Where is the (tree-displayable) data?

Grazr [1] is a very nice little in-browser UI for hierarchical
navigation of data on the Web. It's not hard to imagine it being a
very useful tool for browsing information on the Semantic Web. The UI
isn't actually all that far from TimBL's Tabulator [2]. But the
question is (as asked by Adam Green in offlist email, paraphrased) :
where is the data?

Grazr currently works with the OPML and RSS formats. OPML is a format
for link/text hierarchies, RSS in this context is a simple structural
wrapper around HTML content. Both feature a little bit of metadata. In
Grazr, OPML provides the navigable trees, links or RSS 2.0 content
form the leaf nodes. (These formats suffer from various technical
flaws, and carry considerable political baggage but that's not really
relevant here).

The way Adam posed the question implied that Grazr might be modified
to support SemWeb material. So what data is available online which
could be usefully navigated in such a tool? In general I imagine
cross-site nav could come from rdf:seeAlso's. Leaf nodes could as now
be linked HTML pages or literals intended for human consumption:
dc:description and the like. But there must surely be a lot more
domain-specific material around which would work here: one that
springs to mind is following foaf:knows paths from person to person.
(Note TimBL's "Backward and Forward links in RDF just as important"
[3])

Elsewhere I've suggested (heh, slightly controversially* [4]) that it
would be low-cost for Semantic Web systems to output data in
simplistic quasi-XML formats like RSS and OPML, to take advantage of
existing tools like Grazr and the numerous feed readers. Mountain and
Mohammed, take the SemWeb to where a lot of UI-building is happening.
Collateral salvage being that another dev community gets exposed to
SemWeb tech. (I believe RSS/Atom aggregators have huge potential as
SemWeb UIs, but that's a story for another day ;-)

But even if you avoid these particular formats like the plague, their
general shape may show a useful way of approaching the problem of the
impedance mismatch between RDF data and most user interfaces. OPML and
RSS are very limited in what they can express, it's all oriented to
human-readable content for a start (rather than data in general). But
the constraints of these formats match the constraints of an awful lot
of tools out there. So if you figure out suitable ways to squash
RDF/OWL data down to these formats (or something similar but better
spec'd - the XOXO microformat is nearby [5]), that's 95% of the
solution for exploiting any labelled-hierarchy style UI.

Feed "grazing" is a nice analogy - maybe the RDF processing/flattening
is "chewing the cud".

Cheers,
Danny.

* I was tempted to rattle cages a little harder, it wouldn't take that
much effort to set up a fairly generic online bridging service. Read
the RDF at a given URI into a model, use SPARQL+XSLT to expose it as
OPML & RSS, with any embedded URIs (of other RDF sources) prefixed to
make them query parameters, so any GETs (from the OPML/RSS tool) will
be filtered through the service. But if I exposed Shelley's carefully
crafted RDF as OPML, I'd probably be wise to get a new identity, and I
don't want to mint a new URI so soon after giving myself one...

[1] http://www.grazr.com/
[2] http://www.w3.org/2005/ajar/Help.html
[3] http://dig.csail.mit.edu/breadcrumbs/node/72
[4] http://weblog.burningbird.net/2006/03/18/think-of-the-children/
[5] http://microformats.org/wiki/xoxo


--

http://dannyayers.com

Received on Friday, 24 March 2006 13:13:17 UTC