Re: Display requirements

From: David R. Karger <>
Date: Mon, 13 Sep 2004 18:42:04 -0400

   Mailing-List: contact; run by ezmlm
   X-No-Archive: yes
   Reply-To: <>
   Date: Wed, 01 Sep 2004 15:51:36 -0400
   From: Stefano Mazzocchi <>
   X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE
           autolearn=ham version=2.63
   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
   X-Keywords: NonJunk
   X-UID: 209

   Chris Bizer wrote:

   [snip 'cause nothing significant to add]

> 10. Additional fixed display elements
> It should be possible to specify additional fixed, data intependent display
> elements like headers and footers, company logo, explanations to certain
> sections, e.g. "This is a list of all projects for which the person is
> currently working".

   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.

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.

> 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"

   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?

   Mixing these concerns is just like repeating the <font> HTML tag mistake
   over again.

> # -----------------------------------------------
> # 2. Use Cases
> # -----------------------------------------------
> Potential use cases for a RDF display ontology.
> 1. Display RDF local data with a text-/graphic- and resource-oriented
> browser
> (like LongWell, Haystack, AnSeB) using one application-specific ontology
> and one
> set of style sheets.
> 2. Display RDF distributed data with a text-/graphic- and resource-oriented
> browser
> (like LongWell, Haystack, AnSeB) using different application-specific
> ontologies and
> multiple sets of style sheets provided by different authors.
> 3. Render RDF data as a text-oriented report (e.g. PDF)
> 4. Render RDF data as a graph (e.g. SVG, like IsaViz)

> 5. Edit an RDF graph
> I'm mostly interested in use case 1 and 2. But it would be nice if
> our ontology would also fit for the other use cases or at least
> would be extensible for the other use cases.
> Maybe we should rule editing out of scope for the first version.

   Agreed, 5 is overkill at this point.


> What do you think about also inviting Damian Steer (
> to this discussion. He might also have
> interesting additional ideas.

   Totally. Damian is fully aware of longwell and might have good input for us.

   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 Mon Sep 13 2004 - 22:42:03 EDT

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