W3C home > Mailing lists > Public > public-semweb-ui@w3.org > March 2006

Re: Where is the (tree-displayable) data?

From: Shelley Powers <shelleyp@burningbird.net>
Date: Fri, 24 Mar 2006 10:45:46 -0600
Message-ID: <4424223A.3000103@burningbird.net>
To: Danny Ayers <danny.ayers@gmail.com>
CC: Semantic Web <semantic-web@w3.org>, public-semweb-ui@w3.org, Adam Green <adam@darwinianweb.com>

Danny Ayers wrote:
> 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])

The question becomes: why? Grazr is another built to flip tool weakly
copying the Flickr dropping of the final 'e' in a hope of capturing at
least a tiny bit of the patina of one of the few successful "web 2.0"

Hierarchical data. Anyone remember when relational databases were
sparkly new, and the big database design of the time was hierarchical
databases? Or some network databases, but hierarchical -- man that was
the big thing. The reaction to relational databases at the time was a)
they were too hard to understand and b) they were too esoteric--the
brain child of academics.

Where would we be today if the relational db folks had spent time
showing how we could contort the relational db model so it could
act...just...like...the hierarchical ones.

Danny, you know I'm teasing you (in case anyone wonders, I'm godmother
to one of Danny's cats and he's on my top ten list of people I've met
weblogging that I admire most). But I think I'd rather issue a reverse
challenge -- demonstrate how you can't use OPML and RSS 2.0 to
accomplish what you can with RDF. Barrels and fish come to mind, but
there you go.

> 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.
See above: think squashing relational to hierarchy, throw in use of
COBOL as compared to C++, Java, PHP, Python, and Ruby for good measure.

> Feed "grazing" is a nice analogy - maybe the RDF processing/flattening
> is "chewing the cud".
We talked chewing cud once before. Ever looked deep into the eyes of a
cow in the field chewing its cud? You wouldn't have any hesitation about
eating beef afterwards.

All of this reminds me of a song...what is it...what is it...

Of course!



Received on Friday, 24 March 2006 16:46:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:51 UTC