Display requirements

From: Ryan Lee <ryanlee_at_w3.org>
Date: Tue, 31 Aug 2004 16:04:40 -0400

Chris Bizer, Stefano, and I have been discussing an ontology for
displaying RDF with an eye on implementing one for use in Longwell. One
of our recent side objectives for SIMILE was to also use a common
display ontology in Longwell and Haystack and hopefully generate broader
community support for it.

As it turns out, Chris and I had both drafted vocabularies, which seem
pretty similar at a glance, so we're going to proceed by first
exchanging requirements and use cases. I'd already started to write a
little bit on my work. Here's an excerpt of the requirements I thought
up on what the vocabulary should cover (characteristics of the
vocabulary should include simplicity and ease of reuse):

Class-Instance Oriented

There are several ways to present a triple-based graph; this display
vocabulary is oriented about using an instance of a glass as the basic
building block of the user-agent's actual display. For instance, a
dataset with one person's FOAF records would probably use each
foaf:Person as a discrete unit in displaying the entire dataset.


There can be an overbundance of data that is not useful to users in a
dataset. The ontology must provide a way to filter out extraneous or
user-irrelevant data for presentation. Mechanisms that work on
explicitly showing or explicitly hiding specific resources should be

Relational Specification

The form of a triple - particularly the predicate portion of a triple -
may be better expressed in ways other than a plain text label, such as a
node-and-arc or containment layout. Terms for expressing different
relationships for particular predicates should be provided.


Certain types of data are better represented graphically or in some
manner other than plain text, and certain classes of data are better
summarized by using something other than its label or title. Mechanisms
for specifying alternate expressions of a triple, perhaps by
substituting graphics or the like, should be provided.


The scope of action for certain mechanisms should be applicable at the
broadest level, for every resource in a dataset, and the most specific
level, for specific subject - property - object combinations. These
mechanisms include filtering, relational specification, and representation.


The order of information can be instrumental in conveying its content.
Mechanisms for sorting predicates and objects in a layout-independent
manner should be provided.

Handling bNodes

Blank nodes (or bNodes, or anonymous nodes) are not identified by a URI;
some closure for a graph including bNodes is often necessary. Mechanisms
for artificial closure conditions or actual closure should be provided.

Not Presentational

The vocabulary does not deal with the specifics of presentation; i.e.,
coloring or margins. This is handled better by the specific user-agent,
and technologies already exist for handling such details. For instance,
an XHTML rendering of RDF using the display vocabulary could use CSS to
handle color coordination and certain layout issues.

Translation Hooks

The vocabulary should be mostly independent of output syntax, so
XHTML+CSS, SVG, or plain text could be derived from the same RDF and
configuration, if someone wrote the code for their desired output format.

Ryan Lee                 ryanlee_at_w3.org
W3C Research Engineer    +1.617.253.5327
Received on Tue Aug 31 2004 - 20:04:41 EDT

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