Styling RDF Graphs with GSS

December 3, 2003

Emmanuel Pietriga


RDF models describe web resources using subject-predicate-object triples. Combined together, these triples form a graph structure, which cannot be easily conveyed by textual syntaxes such as RDF/XML, Notation 3 or N-Triple because of their one-dimensional nature.

Visual editors such as IsaViz and RDF Author represent models as editable node-link diagrams, making the graph structure easier to understand compared to textual serializations. However, visual representations are not fully satisfying and have their own problems: diagrams can quickly become big and over-cluttered, and some editing tasks can be more difficult to achieve when dealing with a visual representation of the model. The first version of IsaViz offered partial solutions to these problems, such as a zoomable user interface combined with enhanced navigation capabilities. Those are, ultimately, insufficient, and additional solutions are needed to take advantage of the properties associated with visual representations, in order to offer better and easier-to-understand diagrams.

One such solution is GSS (Graph Style Sheets), an RDF vocabulary for describing rule-based style sheets used to modify the visual representation of RDF models represented as node-link diagrams. Possible modifications include changing the visual aspect of nodes and links (color, shape or icon, font, etc.), but also hiding parts of the graph or changing the layout of some elements. For instance, the example developed in this article will allow us to change the visual representation of a model from what is shown in figure 1 to what is shown in figure 2 with only a few rules.

Picture of rec-history.rdf represented in IsaViz
Figure 1: Standard representation of rec-history.rdf (SVG version)
Picture of rec-history.rdf represented in IsaViz with a GSS style sheet
Figure 2: Styled representation of rec-history.rdf (SVG version)

The GSS Language

GSS is a stylesheet language for styling RDF models represented as node-link diagrams. It is itself an RDF vocabulary and draws many of its instructions from existing W3C Recommendations, namely, CSS and SVG. GSS features a cascading mechanism; its transformation model is loosely based on that of XSLT.

A graph stylesheet is made of a set of rules. The left-hand side of a rule is called the selector, while the right-hand side is called the styling instruction set. Given the set of rules defined in a stylesheet (or several cascading stylesheets), the program in charge of styling RDF models (called a GSS engine) walks the entire graph, including resources, literals, and properties, and evaluates relevant rules on them. If the selector of a rule matches the current node (or arc) in the graph, the corresponding set of styling instructions is applied to the node or arc.

Conflicts between rules matching the same node or arc are resolved, first, by giving higher priority to rules in the stylesheet applied last, and, second, to the most specific selector if both are in the same stylesheet (this is close to the notion of longest match found in XPath/XSLT).

Working Example

The purpose of this article is not to provide a definition of all GSS's features but rather to introduce the language by illustrating its use on a simple RDF model. The reader interested in reading a thorough description of the language can refer to the GSS User Manual.

Our example model is part of the W3C project for automating the publication of technical reports and describes the history of documents on the Recommendation track. Most resources in this model are technical documents published by W3C at the various stages of the Recommendation track. The RDF sample below is an excerpt of the XSLT Recommendation's history. The various versions are linked by obsoletes properties. They also have a Dublin Core date property, and they are typed according to their status: Working Draft (WD), Proposed Recommendation (PR), Candidate Recommendation (CR) or Recommendation (REC). That is all there is to it. Figure 3 shows a visual representation of this sample.

<REC rdf:about=""


  <doc:obsoletes rdf:resource="" />


<PR rdf:about=""


  <doc:obsoletes rdf:resource="" />


<WD rdf:about=""

   dc:date="1999-08-13" />

Picture of a subgraph extracted from rec-history.rdf
Figure 3: Excerpt of rec-history.rdf (SVG version)

This subgraph, representative of the whole model's structure, is simple and easy to understand. However, understanding and navigating in the full model (shown in figure 1) becomes much more difficult. Several representation issues arise, such as the "spaghetti" effect commonly associated with visualization of graphs (note that the GraphViz layout library does already a good job at minimizing this effect). In order to make this model easier to understand, we are now going to design a GSS stylesheet that will produce the graph shown in figure 2 when applied to rec-history.rdf. This style sheet will hide Dublin Core date properties, as well as all rdf:type information. However, since this information is important, we are going to represent it with color, a visual variable that has not been used much in the standard representation.

Let's begin by declaring the required styling instructions.


<rdf:Description rdf:ID="RECStyle"



<rdf:Description rdf:ID="PRStyle"



<rdf:Description rdf:ID="WDStyle"





As we said earlier, GSS is itself an RDF application. A GSS stylesheet is, therefore, structured as an RDF model and can be specified using any RDF serialization syntax. In this code sample, we defined three styles (the full stylesheet declares more) using CSS-inspired properties gss:fill and gss:stroke. These styles will later be used to change the color of nodes representing documents depending on their type. Note that we could have chosen visual dimensions other than color to reflect a document's status, like the node's shape or the stroke used to paint its border. Most of the GSS properties come from CSS or SVG and accept all values defined by the CSS 2 and SVG 1.0 Recommendations.

We are now going to create GSS selectors that will select documents on the Recommendation track based on their type. We are showing only one of them below, as they all look pretty much the same.



  <gss:subjectOfStatement rdf:parseType="Resource">

    <gss:predicate rdf:resource=""/>

    <gss:object rdf:parseType="Resource">

      <gss:value rdf:resource=""/>



  <gss:style rdf:resource="#PRStyle"/>




This selector selects nodes in the RDF model that have an rdf:type property whose value is, that is to say, documents which have reached the Proposed Recommendation maturity level. Note that the last property, gss:style, is used to associate styling instructions with selectors. Styling instructions like gss:fill are not declared directly in selectors; they are declared in style nodes such as PRStyle which are the ones associated with selectors. Thus, an unlimited number of selectors can use the same style node, and several style nodes can be associated with the same selector.

The selector associated with the PRStyle declaration forms a full rule, which selects Proposed Recommendation nodes and assigns them stroke and fill colors. Therefore, we no longer need to display rdf:type arcs as they would be redundant. The code sample below is a rule that selects rdf:type properties and specifies that they should not be displayed.



  <gss:uriEquals rdf:resource=""/>

  <gss:display rdf:resource=""/>




In a similar manner we hide Dublin Core date properties (this information will no longer be available in the styled representation):



  <gss:uriEquals rdf:resource=""/>

  <gss:display rdf:resource=""/>




The stylesheet is now complete. Applying it to the excerpt in figure 3 gives the result shown in figure 4. Applied to the full model (figure 2), the stylesheet produces a more readable representation of the graph, in which it is much easier to identify the maturity level of a given document and its relationships to other documents.

Picture of the excerpt from figure 3 rendered with our style sheet
Figure 4: Same model as in figure 3 rendered with our style sheet (SVG version)


In this article, we have seen how to make the representation of a relatively complex RDF model easier to understand by declaring simple styling and visibility instructions to be applied to selected resources and properties. But this is only a subset of what GSS can do. The language lets you change the shape (including bitmap icons) of nodes in the graph, change font attributes or stroke properties, and group some or all properties associated with a resource in a table and sort them. It is also possible to create much more complex selectors using expressions inspired by the RDF reification mechanism. Other selection expressions let you select resources and properties by namespace, and literals based on their datatype and value. All these features are described in detail in the GSS User Manual.

GSS stylesheets can be authored using any RDF syntax, but because current RDF syntaxes are not very user friendly, this can quickly become cumbersome. This is especially true when considering selectors which tend to be verbose (GSS would greatly benefit from an XPath-inspired RDFPath language). Although they can be edited by hand, GSS style sheets are meant to be generated automatically by software programs or by users through graphical front-ends. IsaViz 2.0 offers one such front end, called GSS Editor, which lets you create stylesheets without writing a single line of RDF. Thanks to GSS Editor, complex style sheets like the GSS Style Sheet for FOAF can be edited easily and can significantly enhance the representation of RDF models, as this comparison of both standard and styled representations of the same model shows.

GSS stylesheets should make it possible to enhance the representation of complex models that use many different vocabularies. Indeed GSS stylesheets can be combined together with ease thanks to the cascading mechanism and the RDF language's capability to merge models. What we need now are stylesheets for all widely-used vocabularies.


I would like to thank the W3C which welcomed me in Boston and funded this work in collaboration with INRIA and Xerox Research Centre Europe. I would also like to offer special thanks to all Semantic Web Advanced Development team members, as well as to my Ph.D advisers, Vincent Quint and Jean-Yves Vion-Dury, who gave me a lot of guidance over the last four years.