Re: Display requirements

From: David R. Karger <>
Date: Tue, 14 Sep 2004 01:43:04 -0400

   Mailing-List: contact; run by ezmlm
   X-No-Archive: yes
   Reply-To: <>
   Date: Mon, 13 Sep 2004 21:52:56 -0400
   From: Stefano Mazzocchi <>
   X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
   X-SpamBouncer: 2.0 beta (8/20/04)
   X-SBNote: Bulk Email (From_Daemon/Listserv/Resent/Precedence)
   X-SBRule: From domain matches first external Received domain
   X-SBScore: 0 (Spam Threshold: 20) (Block Threshold: 5)
   X-SBClass: Bulk


   thanks for following up on this.

   David R. Karger wrote:

> hold it! This is where I have a problem: I think you want a template
> language for RDF in RDF.
> What I would like to have is a declarative visual ontology but
> definately *NOT* a procedural template language since there are already
> so many out there.
> The fact is that foaf:person cannot be visualized because there is no
> visual information (therefore, you cannot decide how to present this).
> You said "cascading RDF stylesheets" and that hits the nail on the head,
> but when you say "you must also have the company logo", that freaks me out.
> one thing is to have "content" in the CSS level (very useful in :before
> and :after CSS selectors), because, for example, "Warning: " before a
> <warning>...</warning> element is style, not content.
> But a company logo, a header, a footer, they are al content, not style
> and content should be dealt with a template language, not a stylesheet
> language and I really think that writing a template language in RDF that
> would be abstracted from the actual presentation markup would be
> *waaaaay* abusive (and would reinvent half a dozen wheels)
> We did it this way in haystack (using rdf to specify layouts in
> rows/columns, sized of regions, etc). It may have been a mistake.
> It's very powerful (let's user customize the views by using
> view-views) but as you say, it reinvents many wheels.

   I wouldn't call it a "mistake" per-se, but I am concerned (being the
   goal of this project to come up with something that average programmers,
   not hard-core semweb geeks, should be able to use, adopt and customize)
   about the "abuse" of RDF for things where hierarchical markup is
   normally used (and with great success and lots of followers) for that

   In terms of "optimal and immediate adoption", I feel that using an RDF
   template language would be a serious drawback, if not a mistake.

I pretty much agree. In fact, "RDF template language" is something of
a contradiction in terms. Really, a "template" should look a lot like
the target output (cf my previous note on scripting---or something
like server side includes). And Wysiwyg seems really the right
approach for a displya language. Indeed one of the biggest problems
we encountered was that it was very hard to read/understand our rdf

On the other hand, I could imagine, in various ways, using RDF to
_annotate_ the templates with more information about how they should
be filled in or applied...

   In terms of "optimal solution and technology", I honestly have no idea.

> We also consider it important for a view to be able to invoke
> arbitrary code---ie, we don't assume that all presentation of data can
> be done using the standard widgets, and we want a view to be able to
> include its own special-purpose widgets, such as a graph-layout
> widget, and invoke them at the right time.

   Hmmm, interesting point, but I wonder if it really applies at this
   level. I mean, in the "what" description, obviously this doesn't
   apply... but in the "how" description, well, the ability to invoque
   arbitrary code is strongly influenced by the media against which we want
   to render.

   This could be interpreted as a serious issue with a cross-media RDF
   publishing system, or simply as a known deficiency of some rendering
   media (for example, PDF which cannot invoke applets, for example).

PDF also tends to display only things "in" the document, edited by the
author. RDF tends more often to lead the reader along a chain of
relationships to some unexpected resource, which we are going to need
to (somehow) display.

   At the same time, I think that this is a serious concern and it is
   should be indeed possible for the presentation layer to have pluggable
   widgets, but I'm scared about the complexity of the conceptualization of
   such visualizing layer.

> > 11. Handling of Missing Values
> >
> > It should be possible to specify alternatives for missing values e.g.
> > display foaf:firstname and foaf:last name if foaf:name is missing. Or
> > display dc:title if rdfs:label is missing.
> Again, same thing: conditionals are not part of style because
> conditionals are procedural not declarative.
> right. if, after all the equivalences have been worked out, there is
> no appropriate value, then hatstack shows "null"

   why "null" instead of nothing at all? [just curious, "null" seems to be
   pretty problematic in usability terms, as many people would find it

probably right, but it's easier on the developers :)

> It is not up to the 'display ontology' to indicate "what" information
> should be there, but "how" the information present should be displayed.
> this is a little blurry (see my last post). eg, a lot of haystack
> lenses are "property set lenses" which just give a list of the
> properties of the object to show; they are then shown using a
> relatively generic presentation. Is this lens deciding what or how?

   I would say "what" if they contain just a list of properties and a mix
   of "what and how" if they contain both the list of properties and, for
   example, the font size to show them or their box-nesting hierarchy.

   In that case, I would be pleased if we could come up with a way to
   cleanly separate the two.

   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 Tue Sep 14 2004 - 05:43:03 EDT

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