Re: RDF Display Vocabulary

From: Chris Bizer <>
Date: Mon, 13 Sep 2004 21:28:12 +0200

Hi Emmanuel and all,

great that you are joining the discussion :-)

> First some general thoughts:
> - I like the idea of lenses, and I would like (as a user of this vocab)
> to be able to combine several lenses on a given (class of) resource(s),
> especially considering that a cascading mechanism is considered.

I clearly see the advantage of a cascading mechanism for display styles, but
I think that cascading lenses are getting complicated for the user. What you
are basically saying using a lens is: Display these properties in this
order. When joining lenses from different levels you are getting a problem
with the ordering. As Ryan already said against one of my earlier proposals:
"Combining views seems like it might be visually confusing tactic" and I
agree with him. It is definitively useful to provide some drill-down
functionality, but maybe we should think of mechanisms to relate complete
lenses, rather than of mechanisms to join lenses. See below.

> This
> could be managed at a fine-grain level, conflicts between lenses being
> resolved through well-known mechanisms (e.g. by computing the weight
> associated with the different lenses ; that's what I do with GSS rules,
> and it is being used in CSS, XPath+XSLT).
I agree for the styling vocab, but disagree for the content selection layer,
especially when you are thinking of using alternative lenses provided by
different authors/sources.

> > I was thinking the other night that even if not editable, the
> > "dynamicity" of the presentation layer might be out of scope, but very
> > important from a usability point of view.
> >

I think the question how dynamic the display is and which options are given
to the user should depend on the specific browser implementation. Some might
give plenty of options based on all lenses/styles they are finding somewhere
on the Web. Others won't give any options and just render the data using a
given set of lenses/styles. We should keep this in mind and stay general
enough when writing the vocabs.

> > For example: say I consider some properties primary and some others
> > secondary and I would like to present them in a "click and show/click
> > and hide" way (this is the usability model, the actual presentation is
> > another concern), where does this fit?
> This is definitely important IMHO. Dynamic features like this can make
> the representation much more easy to understand. Without going as far as
> having a generic scripting language, the language could provide some
> abstract (high-level) concepts such as layers. The stylesheet writer
> would just specify on what layer a predicate should appear, and the user
> could then select what layer(s) he wants to see.

I think this fits perfectly with the idea of lenses. The stylesheet/lens
writer could specify one lens "FOAF person overview" and another lens "FOAF
person details" which would include more predicates. He could then relate
both lenses using for example

ex:overviewLens disp:moreDetailedLens ex:detailsLens

A browser could decide if he likes to use one or the other or provide
drill-down functionality for the user.

> > 2. Filtering
> > >
> > > There can be an overbundance of data that is not useful to users in
> > > 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
> > > provided.
> > >
> >
> > Yes, and we should also deal with the case of different filters for one
> > class.
> > People might want to display different aspects of a resource, e.g.
> only the
> > work related information about a person or information concerning
> > activities. The different filters could interactively be chosen in the
> > browser
> > (Haystack lenses) or set in the browser configuration. We should also
> think
> > about different people providing filters for the same class.
> Filtering is obviously very important, but another related issue is how
> you will be able to convey/encode some data in a more user-friendly
> One basic example is removing rdf:type information for resources, but
> changing those resources' appearance (e.g. the GSS stylesheet for foaf
> [1] removes rdf:type statements pointing to foaf:Person and changes the
> subjects' appearance from a std resource - green ellipse - to a bitmap
> icon representing a man ; it does the same thing for foaf:Organization,
> etc., and this greatly improves the graph's readability).
> [1]
> From what I've understood of the two proposals, this seems to be
> achievable, right (e.g. using dsp:AsSubstitution) ?

It is definitively in Ryan's proposal, and we definitively need this

> > 3. 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.
> > >
> >
> > Yes.
> Definitely. The default behaviour of GSS is to show relationships as
> nodes and arcs. But some (or all) properties associated with a given
> resource can be grouped in a table (and sorted). Another alternative
> would be to embed this table in the subject resource's "node" (right
> now, it is outside the subject, with an unnamed link between the subject
> and the resource). Being able to actually nest table inside one another
> would be nice too (it could also be interesting to apply semantic
> zooming here, in the context of a ZUI, e.g. to provide basic info about
> an object at high altitude and provide the user with more info when
> going down).

Again. This should be defined on the content selection layer, as I think by
relating different lenses.

> > 5. Granularity
> > >
> > > The scope of action for certain mechanisms should be applicable at
> > > broadest level, for every resource in a dataset, and the most
> > > level, for specific subject - property - object combinations. These
> > > mechanisms include filtering, relational specification, and
> > representation.
> > >
> >
> > Yes, didn't think about this yet. Which will mean that we end up with
> > cascading RDF style sheets (CRSS :-)
> GSS offers a cascading mechanism, and I think this is a good thing to
> have here too, one use case being people who want to override some style
> settings made in a stylesheet applied upward (e.g. to increase
> font-size). Conflict management between rules in GSS is as follows:
> "As CSS, GSS supports the cascading of stylesheets. In case of conflict
> between two rules belonging to different stylesheets, the rule in the
> stylesheet applied last prevails. In case of conflict between two rules
> belonging to the same stylesheet, the styling engine computes a weight
> for the conflicting rules and selects the one with the heaviest weight
> (a more specific rule will have a higher weight). If the weights are the
> same, there is no guarantee on which rule will be selected." So this is
> XSLT/XPath-like.
> One thing I have failed to evaluate from my quick look at the two
> proposals is how expressive and easy-to-use are the selector languages,
> i.e. the languages used to express constraints on resources and
> properties the styling rules should be evaluated against. GSS offers a
> fairly powerful selection language, but which has a major drawback: it
> is difficult to understand and program with (not mentioning verbose).
> This is probably partly due to the fact that it is expressed in RDF (all
> GSS is RDF-based, with styling instruction values taken from CSS and
> SVG). Some time ago, the idea of an XPath-like RDFPath language was
> discussed on, and several proposals have been
> made. I intend to study those starting next month, as I would like to
> rely on a more programmer-friendly selection mechanism for my next
> attempt at styling RDF.

An XPath-like selector language sounds really interesting. I will also have
a look.
I think our stylesheet and content-selection language should be RDF-based,
but we surely can include other languages for certain tasks, as we are
already doing with CSS and hooks.

> > # -----------------------------------------------
> > # 2. Use Cases
> > # -----------------------------------------------
> > (like LongWell, Haystack, AnSeB) using different
> > ontologies and
> > multiple sets of style sheets provided by different authors.
> A good and clearly-defined cascading mechanism might do part of the job
> here, with one stylesheet for each vocabulary. This clearly does not
> cover all the needs however...

Hmm, maybe somebody should explain me the idea of the cascading mechanism on
the content-selection layer again. It seams I don't get it. I see how I can
use one stylesheet per vocabulary for expressing pure style information like
foaf:depict should be displayed as a picture not as text. But on the
content-selection layer I don't understand how different predicate orders
are joined. I also think that lenses should be allowed to combine terms from
different vocabularies, e.g. for handling missing values: If foaf:name is
missing, use rdfs:label.

Maybe it is useful to sum up my current understanding of the status of the
discussion and people can protest where I'm wrong or where they are having a
different understanding.

We are having:

A stylesheet language which:
1. is used for saying: Its a good idea to display foaf.depict as an image
and a good idea to display foaf:name as text. Or this triple should be
substituted by a specific graphic.
2. we use classic CSS for defining the display details like font-size ...
3. the css code is linked using hooks
4. the stylesheet language provides cascading mechanisms, so I can say:
General rule "Display all properties as text", but display foaf:dipict as an
5. as selector language we might use RDFpath

A content selection language which:
1. is used for grouping properties to lenses
2. order the properties
3. define alternative properties for missing values
4. define necessary bNode closures e.g. foaf:knows
5. might include terms for relating different lenses e.g. moreDetailedLens

Different browsers that use these languages
1. will render different output ranging from RDF documents over SVGs to
interactive websites.
2. decide which styles/lenses they are using and to which degree they leave
the decision to the user, e.g. drill-down functionality or Mozilla like
stylesheet switching.
3. Ignore terms in stylesheets that they don't understand, e.g. from
different future style vocabs.
4. Some browsers might only use information from a fixed RDF store and a
fixed set of stylesheets/lenses, others might search the web for additional
information and additional stylesheets/lenses.

Another question which came to my mind when looking at Haystack again: How
do tables and thinks like photoalbums fit in our content-selection/style
separation. It seam that you need a mixture of selection and style to
define a table. Any ideas here?


> Emmanuel
> --
> Emmanuel Pietriga (
Received on Mon Sep 13 2004 - 19:22:58 EDT

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