Re: Display/Stylesheet Vocabulary for RDF Browsers

From: Stefano Mazzocchi <>
Date: Thu, 23 Sep 2004 09:54:29 -0400

David R. Karger wrote:

> I'm trying to continue to catch up on this discussion.
> Reading this particular mail, I'm hobbled by my weakness at reading
> raw n3. Is there a tool for switching it to e.g. a circles and arrows
> diagram with labels/descriptions in the circles?

Have you tried Emmanuel's IsaViz? I'm sure there is a GSS somewhere for

> However, one particular question does come to mind. Chris vocabulary
> at least appears to build-in the assumption that the target output of
> the display vocabulary is html. I don't know if I'm comfortable with
> this.
> Does it mean I'm going to need a whole different vocabulary to
> produce output for a rich client like Haystack (eg, one that will be
> used to manipulate the data and not just look at it, so needs support
> for rich graphical interaction like drag and drop)?
> I would prefer to factor out the portion of lenses that are "output
> format independent" at least to some extent. For example, which
> properties to display in a lens can clearly be talked about in a
> format independent way. Which properties of a given class can be
> thought of as a "title" for objects of the class can too. Even
> notions of rows and columns in a table seem more general than just
> html.
> As a sound bite, I'd argue for separate ontologies of _what_ to show
> and _how_ to show it.

Very much agreed.

> I also have a sense that e.g. FOAFLenses.n3 is repeating a feature of
> Haystack that I think may have been mistaken, of trying to describe
> the intended output html in RDF, when it is probably a lot easier on
> the developer to define the html in html---e.g., to use some kind of
> scripting with fill-in-the-blanks for rdf values.

Hmmm, I'm not sure here. The 'declarative fallback' nature of lenses
would be trivial to write in a scripted template, but it would be very
hard to reuse it across various ones, so I see value in their existance.

On the other hand, I agree that defining an HTML-like ontology for
presentation is not only reinventing the wheel, but potentially harmful
(given the fact that HTML/XHTML are much easier to write and read than
triples, especially when scripting is intermixed)

I still don't see a real reason (beside golden hammerish) why the
template part of the system should not be something like velocity with
special RDFPath/RDQL querying capabilities on the submodel passed to the

Stefano Mazzocchi
Research Scientist                 Digital Libraries Research Group
Massachusetts Institute of Technology            location: E25-131C
77 Massachusetts Ave                   telephone: +1 (617) 253-1096
Cambridge, MA  02139-4307              email: stefanom at mit . edu
Received on Thu Sep 23 2004 - 13:54:18 EDT

This archive was generated by hypermail 2.3.0 : Thu Aug 09 2012 - 16:39:17 EDT