# Graph Stylesheets (GSS) in IsaViz

## Table of Contents

1. Introduction
2. Selectors
3. Styling Instructions
4. Visibility
5. Layout Instructions
6. Rule Priority and Cascading
7. Graphical Front End in IsaViz
8. Bibliography

## 1. Introduction

Graph Stylesheets are a way to associate style to node-edge representations of RDF models, but also to hide part of the graph and to offer alternative layouts for some elements. This means that based on some selectors (detailed later), it is possible to assign color, stroke width or font style to specific nodes and edges in the graph. It is also possible to hide selected nodes and edges, or to lay them out (along with the node at the other end of the edge) in a table form in order to group them in a region of the visualized space.

Graph Stylesheets are themselves expressed in RDF and define their own vocabulary in a namespace with the following URI:

http://www.w3.org/2001/11/IsaViz/graphstylesheets#

which will be bound to prefix gss: in the remainder of this document.

A graph stylesheet is made of a set of rules which select resources, properties and literals in an RDF model and assign styling attributes to the graphical entities that represent them in IsaViz (nodes and edges of the node-arc diagram). The left-hand side of a rule is called the selector, while the right-hand style is called the styling instruction set.

## 2. Selectors

There are three types of selectors : resource selectors, literal selectors, and property selectors, which each accept different properties describing the constraints that the stylesheet designer wants to express on the entities to select. The selector itself is represented by a b-node (or anonymous node), and must declare a specific rdf:type property.

### 2.1 Resource Selectors

A resource selector must declare an rdf:type property whose value is class gss:Resource. The following properties can be attached to the selector:

- gss:uriEquals specifies an equality constraint on the URI of the resource to select.
- gss:uriStartsWith specifies that the URI of the resource(s) to select must begin with the provided URI fragment. This is tipically useful to select all resources belonging to the same namespace.
- gss:subjectOfStatement specifies constraints on the predicate and the object of a statement whose subject is the resource to select. A use case of this is to select resources which have a specific property, like rdf:type, associated with a specific value.
- gss:objectOfStatement specifies constraints on the subject and the predicate of a statement whose object is the resource to select. A use case of this is to select non-typed resources which are values of a specific property type.

gss:subjectOfStatement and gss:objectOfStatement are described in detail later.

Figure 1 shows an example of a selector for resource http://claribole.net

Figure 1: Selecting resource http://claribole.net (SVG version)

Figure 2 shows an example of a selector for resources whose URI belongs to the Dublin Core namespace.

Figure 2: Selecting resources in the Dublin Core namespace (SVG version)

All these properties can be combined to create complex selectors. The set of properties associated with a given selector is interpreted as a conjunction of constraints on the resource(s) to select. As a consequence, gss:uriEquals and gss:uriStartsWith cannot appear together and can only appear once. They can however be combined with one or more gss:subjectOfStatement and objectOfStatement properties.

Note: a resource selectors which does not express any constraint will select all resources in the model. However, it still needs to declare an rdf:type property whose value is class gss:Resource.

### 2.2 Property Selectors

A property selector must declare an rdf:type property whose value is class gss:Property. The following properties can be attached to the selector:

- gss:uriEquals specifies an equality constraint on the URI of the property to select.
- gss:uriStartsWith specifies that the URI of the property(-ies) to select must begin with the provided URI fragment. This is tipically useful to select all properties belonging to the same namespace.
- gss:predicateOfStatement specifies constraints on the subject and the object of the statement whose predicate is the property to select.

Figure 3 shows an example of a selector for rdf:type properties.

Figure 3: Selecting rdf:type properties (SVG version)

Figure 4 shows an example of a selector for properties in the RDFS namespace

Figure 4: Selecting properties in the RDFS namespace (SVG version)

As for resource selectors, gss:uriEquals and gss:uriStartsWith cannot appear together and can only appear once in property selectors. A property being the predicate of exactly one statement, which has exactly one subject and one object, there is at most one gss:predicateOfStatement property attached to a property selector. Again, the set of properties associated with a given selector is interpreted as a conjunction of constraints on the property(-ies) to select.

### 2.3 Literal Selectors

A literal selector must declare an rdf:type property whose value is class gss:Literal. The following properties can be attached to the selector:

- gss:value specifies an equality constraint on the value of the literal(s) to select.
- gss:datatype specifies a constraint on the datatype of the literal(s) to select must.
- gss:objectOfStatement specifies constraints on the subject and the predicate of a statement whose object is the literal to select. A use case of this is to select non-typed resources which are values of a specific property type.

Figure 5 shows an example of a selector for literals typed as xsd:int and whose value is equal to 10.

Figure 5: Selecting integer literals equal to 10 (SVG version)

Figure 6 shows an example of a selector for all plain literals.

Figure 6: Selecting all plain literals (SVG version)

gss:value and gss:datatype can only appear once in a given selector. A literal being the object of exactly one statement, at most one gss:objectOfStatement property can be attached to a literal selector. The set of properties associated with a given selector is interpreted as a conjunction of constraints on the literal(s) to select.

### 2.4 Complex constraints

As mentioned earlier, it is possible to express complex contraints on the type and value of nodes and properties attached to the entity(-ies) that should be selected. This is achieved through the use of gss:subjectOfStatement, gss:objectOfStatement and gss:predicateOfStatement.

### Subject of Statement

gss:subjectOfStatement can be used only to select resources. It is used to specify constraints on the predicate and the object of a statement whose subject is the resource to select. gss:subjectOfStatement points to a b-node representing the statement itself. It is then possible to attach the following properties to this node:

- gss:predicate specifies a constraint on the property type of the statement.
- gss:object points to another b-node, representing the object of the statement, to which the following properties can be attached:
  - gss:class specifies a constraint on the statement's object type in case the object is a resource (the object should declare an rdf:type property whose value is equal to the one specified in the constraint).
  - gss:datatype specifies a constraint on the statement's object datatype in case the object is a literal (the object should declare an rdf:type property whose value is equal to the one specified in the constraint). Note that a special value gss:PlainLiterals is used to select plain (untyped) literals.
  - gss:value specifies an equality constraint on the statement's object URI or literal value, depending on the nature of this node (a resource or a literal).

Figure 7-a shows an example of a selector for resources declaring an rdf:type property with value rss:channel.

Figure 7-a: Selecting all resources typed as rss:channel (SVG version)

Note that the above example selects only resources which have a property rdf:type whose value is rss:channel. They do not select resources which have a property rdf:type whose value is not rss:channel but which also have another property (different from rdf:type) whose value is rss:channel. In order to specify such a constraint, two different gss:subjectOfStatement properties need to be specified for the selector, as shown in Figure 7-b. This selector would select resources declaring an rdf:type property with value rss:channel, but also, for instance, resources that declare an rdf:type property with value rss:item and another property rdfs:label with value rss:channel, as it meets the constraints as expressed in example 7-b.

Figure 7-b: Selecting all resources declaring an rdf:type property and having a property whose value is rss:channel (SVG version)

Figure 8 shows a more complex example. It selects all resources in the http://www.w3.org domain, which declare a dc:title property (title value is not constrained) and a dc:creator property whose value must be "Emmanuel Pietriga".

Figure 8: Selecting all plain literals (SVG version)

### Object of Statement

gss:objectOfStatement works similarly to gss:subjectOfStatement. It can be used to select resources or literals, by specifying constraints on the predicate and the subject of a statement whose object is the resource or literal to select. gss:objectOfStatement points to a b-node representing the statement itself. It is then possible to attach the following properties to this node:

- gss:predicate specifies a constraint on the property type of the statement.
- gss:subject points to another b-node, representing the subject of the statement, to which the following properties can be attached (recall that the subject of a statement is always a resource):
  - gss:class specifies a constraint on the statement's subject type (the subject should declare an rdf:type property whose value is equal to the one specified in the constraint).
  - gss:value specifies an equality constraint on the statement's subject URI.

Figure 9 gives an example of selector for literals which must be the object of a p3p:imageWidth statement whose subject must be a resource with a URI equal to http://claribole.net/2003/03/centralpark-4.jpg and belonging to class p3p:Image (the subject must declare a property rdf:type whose value is class p3p:Image)

Figure 9: Selecting the literal object of a p3p:imageWidth statement whose subject is a p3p:Image with a specific URI (SVG version)

Figure 10 refines the previous selector by constraining the value and datatype of the literal to be selected.

Figure 10: Adding constraints on the literal's value and datatype (SVG version)

### Predicate of Statement

gss:predicateOfStatement can be used to select properties and uses the same constructs as defined earlier. It is used to specify constraints on the subject and the object of a statement whose predicate is the property to select. gss:predicateOfStatement points to a b-node representing the statement itself. It is then possible to attach the following properties to this node:

- gss:subject points to another b-node, representing the subject of the statement, to which the following properties can be attached (recall that the subject of a statement is always a resource):
  - gss:class specifies a constraint on the statement's subject type (the subject should declare an rdf:type property whose value is equal to the one specified in the constraint).
  - gss:value specifies an equality constraint on the statement's subject URI.
- gss:object points to another b-node, representing the object of the statement, to which the following properties can be attached:
  - gss:class specifies a constraint on the statement's object type in case the object is a resource (the object should declare an rdf:type property whose value is equal to the one specified in the constraint).
  - gss:datatype specifies a constraint on the statement's object datatype in case the object is a literal (the object should declare an rdf:type property whose value is equal to the one specified in the constraint). Note that a special value gss:PlainLiterals is used to select plain (untyped) literals.
  - gss:value specifies an equality constraint on the statement's object URI or literal value, depending on the nature of this node (a resource or a literal).

Figure 11 gives a simple example selecting all properties describing resource http://claribole.net

Figure 11: Selecting all properties describing resource http://claribole.net (SVG version)

Figure 12 builds upon the previous example and adds a constraint on the class of the statement's object.

Figure 12: Selecting all properties describing resource http://claribole.net with a value of class p3p:Image (SVG version)

## 3. Styling Instructions

We have seen in the previous section how to select resources, properties and literals. We are now going to see how to associate styling attributes to selectors in order to have full styling rules.

First, it is important to note that styling properties are not directly associated with selector nodes. Instead, one or more styling properties can be attached to a style node, which is itself pointed at by one or more selectors using the gss:style property, thus enabling the reuse of already defined styles. As shown in figure 13, a selector can also make use of more than one style node.

Figure 13: Sharing styling instructions between selectors (SVG version)

Since they are visually represented by different kinds of graphical objects (basically nodes and edges), different styling properties can be associated with resources, literals and properties. We are first going to take a look at the core styling properties which can be applied to all of them.

### Core Styling Properties

The core styling properties can be applied to resources, literals and properties. Most of them are inspired from CSS and accept the same values as defined by the CSS 2 Specification. In all the following examples, we use very simple selectors for the sake of clarity ; any selector, no matter its complexity, can of course be associated with style nodes.

#### Stroke Color

The stroke color corresponds to the node's border color for resources and literals and to the edge's color for properties. As figure 14 shows, it is specified using the gss:stroke property and can take any CSS2 color value such as:

- black (all color keyword names defined in the SVG 1.0 Recommendation are allowed)
- rgb(123,43,255)
- rgb(50%,60%,70%)
- #FB0
- #43FFA6

Figure 14: Stylesheet for changing the stroke color width of all resource nodes (SVG version)

#### Stroke Width

The stroke width corresponds to the node's border width for resources and literals and to the edge's thickness for properties. As figure 14 shows, it is specified using the gss:stroke-width property and takes any positive numerical value. The only length unit supported for now is pixels ('px', which can be ommited). Figure 15a shows the standard representation of a simple RDF model in IsaViz ; figure 15b shows the same model, this time applying the stylesheet defined in figure 14.

Figure 15a: Model without stylesheet (SVG version) | Figure 15b: Model with stylesheet (SVG version)

#### Font

As shown in figure 16, it is possible to change several properties of the font used to render the text labels associated with the nodes and edges. Four properties are supported and accept the same values as defined by the CSS 2 Specification:

- font-family is used to change the font family used to render the text. Examples of font families are Arial, Courier or Times. Generic CSS font families (serif, sans-serif, monospace, cursive, fantasy) are not yet supported. The current implementation does not accept a list of font families, but only a single family. Support for these two features (generic font families and list of families) should be added soon.
- font-size is used to change the font size used to render the text. The value must be a positive integer in points ('pt', which can be ommited).
- font-weight is used to change the font weight of the text. Almost all CSS values are allowed: normal, bold, 100, 200, 300, 400, 500, 600, 700, 800, 900, except bolder and lighter which make no sense in the context of GSS. Note that most fonts do not offer so many alternatives and that some values might not be available. Normal, which corresponds to 400 and bold, which corresponds to 700 are usually available.
- font-style is used to change the font style of the text. Three values are allowed: normal, italic, oblique. Note that in many cases italic and oblique will look the same.

Figure 16: Stylesheet for changing the font properties of resources, literals and properties (SVG version)

Figure 17a shows a model with the default font used for all labels. Figure 17b shows the same model displayed using the stylesheet from figure 16.

Figure 17a: Model without stylesheet (SVG version)

Figure 17b: Model with stylesheet (SVG version)

### Additional Styling Properties for Resources and Literals

In addition to the core styling properties, GSS features two other properties that can only be applied to the nodes of the graphs (i.e. to resources and literals).

#### Fill Color

As shown in figure 18, the fill color corresponds to the node's interior color. It is specified using the gss:fill property and, as gss:stroke, can take any CSS2 color value. Note that it is possible to assign a style defining one or both of these properties (among others) to property selectors. They will simply be silently ignored in that case.

Figure 18: Stylesheet defining a stroke color and a fill color for resources in the http://www.w3.org/ domain (SVG version)

Figure 19 gives an example of model rendered using the stylesheet from figure 18.

Figure 19: Application of the stylesheet from figure 18 to a model (SVG version)

#### Node Shape

It is possible to change the shape of resource and literal nodes using the gss:shape property. The user can choose to use predefined shapes, by setting one of the following resources as the value of this property:

- gss:Ellipse which is the default shape for resources,
- gss:Rectangle which is the default shape for literals,

or one of the following, knowing that in each case the node's width is not adjusted to fit the entire label, but remains approximately equal to the node's height:

- gss:Circle
- gss:Diamond
- gss:Octagon
- gss:TriangleNorth (triangle pointing upward)
- gss:TriangleSouth (triangle pointing downward)
- gss:TriangleEast (triangle pointing to the right)
- gss:TriangleWest (triangle pointing to the left)

Figure 20a shows a stylesheet assigning a triangular shape to all literals typed as integers. Figure 20b gives an example of a model rendered using this stylesheet.

Figure 20a: Assigning a triangular shape to all literals typed as integers (SVG version)

Figure 20b: Literals typed as integers represented as triangles (SVG version)

Aside from predefined shapes, it is also possible to define custom shapes, following the Glyph model described in [1], [2] and [3]. Basically, as shown in figures 21 and 22, this model represents a shape as a list of normalized float numbers (between 0.0 and 1.0) which each represent the distance from the center of the shape's bounding circle to a vertex (0.0 means that the vertex coincides with the center of the bounding circle, 1.0 means that the vertex is on the bounding circle). The angle between each vertex is constant and equal to 2*Pi/N where N represents the number of vertices. In GSS, a shape represented using this model is encoded in a literal value which consists of a list of normalized floats between square brackets plus an optional float number representing the orientation of the shape (considered equal to 0 is not specified). The shape's value in figure 21 corresponds to the shape in figure 22. As we will see later, IsaViz provides a graphical front end for specifying Graphical Stylesheets, so that users do not have to author GSS directly in RDF (although this is still possible). This front end makes use of the ZVTM Glyph Factory widget (provided by the ZVTM graphical toolkit upon which IsaViz relies) to allow the user to specify custom shapes by direct manipulation. Figure 23 gives an example of model rendered using the stylesheet from figure 21.

Figure 21: Assigning a custom shape to all literals typed as integers (SVG version)

Figure 22: ZVTM Glyph Factory

Figure 23: Custom shape for literals typed as integers (SVG version)

Note: as for gss:Circle and other shapes, the width of custom shapes is not adjusted to fit the entire label. If the label is too wide to fit inside the shape, it crosses the shape' boundary. However, the shape and the label remained centered w.r.t each other. This means that custom shapes (and shapes that follow this rule) are best suited to small literal values. When displaying long URIs or long literal values, it is better to use ellipses or rectangles.

## 4. Visibility

Aside from styling instructions, GSS also features properties to hide selected resources, properties and literals. Visibility properties are attached directly to selectors, not to style nodes. There are two visibility properties, inspired by CSS:

- gss:Visibility can take the value gss:Visible or gss:Hidden,
- gss:Display can take the value gss:None.

Although everything is visible by default, gss:Visibility=visible is interesting if you want to show something that is being hidden by a stylesheet applied prior to the one you are defining (we will see in section 5 that, as CSS stylesheets, GSS stylesheets can be cascaded).

gss:Visibility=gss:Hidden and gss:Display=gss:None both hide the entities they select. The difference between the two is that gss:Visibility=gss:Hidden hides entities after the layout process has occured, whereas gss:Display=gss:None hides them before computing the graph layout. This means that in the first case the layout is not impacted by the fact that some entities are hidden (hidden entities occupy space, even though they are not visible), whereas in the second case the layout is changed (hidden entities are not taken into account in the layout computation, resulting in a more compact graph). The following figures illustrate this difference.

Initial Representation (nothing hidden) | (SVG version)
(SVG version) visibility=hidden | (SVG version)
(SVG version) display=none | (SVG version)

## 5. Layout Instructions

@@section not yet written

## 6. Rule Priority and Cascading

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 (the more a rule is specific, the higher its weight). If the weights are the same, there is no guarantee on which rule will be selected.

## 7. Graphical Front End in IsaViz

GSS Stylesheets in IsaViz are managed through the Stylesheets tab of the Definitions window shown in figure 23. In this window, the user can load any number of stylesheets located on their computer or available publicly on the Web. The sequence of application of these stylesheets is oriented downward. This means that in the example of figure 23, coloring.gss will be applied first, then datehiding.gss and finally dateshowing.gss. As stated earlier, in case of conflict between rules belonging to different stylesheets, the rule in the stylesheet applied last prevails.

Figure 24: Managing Stylesheets in IsaViz

The position of stylesheets into the sequence can be changed by selecting the stylesheet of interest and then using the two arrows located at the far left of the panel. Stylesheets can also be removed from the list. For now, stylesheets have to be created by directly editing the RDF model representing the stylesheet using the GSS vocabulary. However, a full graphical front-end is under development, which will allow users to specify styling rules by direct manipulation of visual entities, without having to write a single line of RDF. This front-end will be available as a standalone application and through IsaViz by clicking on the Edit Selected Stylesheet button.

Stylesheets are automatically applied to models imported through any command of the File/Import menu. It is also possible to apply the sequence of stylesheets manually using the Apply Stylesheets button.

## Bibliography

[1] Jean-Yves Vion-Dury and Francois Pacull, A structured Interactive Workspace for a Visual Configuration Language, Proceedings of Visual Languages '97, pp132-139, 1997, Capri, Italy

[2] Jean-Yves Vion-Dury, Un générateur de composants pour le traitement des langages visuels et textuels, Université Joseph Fourier - Grenoble 1 (PhD thesis), 1999, Domaine Universitaire, Saint Martin d'Hères, France

[3] E. Pietriga, Environnements et langages de programmation visuels pour le traitement de documents structurés, Institut National Polytechnique de Grenoble (PhD thesis), Novembre 2002, Grenoble, France

| Emmanuel Pietriga Last modified: Tue Apr 22 15:55:21 Eastern Daylight Time 2003