Benjamin Van Ryseghem
email: benjamin.van_ryseghem@inria.fr

Stéphane Ducasse
email: stephane.ducasse@inria.fr

Johan Fabry
email: jfabry@dcc.uchile.cl

A Framework for the Specification and Reuse of UIs and their Models

Implementing UIs is often a tedious task. To address this, UI Builders have been proposed to support the description of widgets, their location, and their logic. A missing aspect of UI Builders is however the ability to reuse and compose widget logic. In our experience, this leads to a significant amount of duplication in UI code. To address this issue, we built Spec: a UIBuilder for Pharo with a focus on reuse. With Spec, widget properties are defined declaratively and attached to specific classes known as composable classes. A composable class defines its own widget description as well as the model-widget bridge and widget interaction logic. This paper presents Spec, showing how it enables seamless reuse of widgets and how these can be customized. After presenting Spec and its implementation, we discuss how its use in Pharo 2.0 has cut in half the amount of lines of code of six of its tools, mostly through reuse. This shows that Spec meets its goals of allowing reuse and composition of widget logic.

Introduction

Building user interfaces is a notoriously time-consuming task. To help developers in their tasks, several approaches have been proposed previously. The basic principle of decoupling the model from its view: MVC [START_REF] Krasner | A cookbook for using the model-view-controller user interface paradigm in smalltalk-80[END_REF] was first proposed in Smalltalk-80. This principle was later evolved to Model View Presenter (MVP) [START_REF] Potel | Mvp: Model-view-presenter. the taligent programming model for c++ and java[END_REF] by the Taligent project. In MVP, the presenter assumes part of the functionality of the controller and is the sole responsible for coordinating how the UI manipulates the underlying model. The view is Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. IWST '12 August 28th, 2012, Gent, Belgium. Copyright c 2012 ACM [to be supplied]. . . $10.00 now also responsible for handling UI events, which used to be the controller's responsibility.

Orthogonally to these concepts, UI builders were developed as tools to facilitate the design and building of UIs. The goals of UI builders are often twofold: firstly to support the description of widgets (location, size, color) and their logic, and secondly the composition and reuse of existing component logic. VisualWorks [START_REF] Howard | The Smalltalk Developer's Guide to VisualWorks[END_REF][START_REF]Parcplace systems, objectworks reference guide, smalltalk-80[END_REF] was a pioneer of this approach. Its builder is based on application classes that glue widgets and domain objects together, based on a literal description of widget properties.

Important issues with UI builders stem from the fact that their working is often based on direct code generation from the UIBuilder visual pane. As a first consequence the simple fact of reloading a UI description in the builder for editing, arguably a common occurrence, is already a complicated process. This complication arises because the UI description code has to be interpreted differently from a normal execution, since the normal execution opens the UI for use. Secondly, there is still the challenge of reusing widgets and their interaction logic. In our experience with Pharo, the use of UI builders there has led to a significant amount of code duplication which can be avoided. For example, the Senders/Implementors tool shows a list of methods and displays their source code. Pharo also provides the VersionBrowser, which displays methods as a list and their source code. Furthermore the ProtocolBrowser displays all the methods of a class and their source code. These three tools are mostly duplicated code, essentially implementing three times the same behavior and the same UI, with some superficial differences. In our opinion this code duplication arises because the widgets are not generic enough to be reused while also being able to be adapted to cope with (subtle) variations.

To address the above issues, two underlying design choices need to be taken: (1) how do we define UI descriptions and (2) how do we compose the logic of UIs. We assert that there is a need for a declarative way to specify UIs that also allows for seamless composition and reuse of the UI declaration and logic. In line with this assertion we have de-veloped Spec, a UI builder for Pharo, and we present it in this article.

With Spec, widget properties are defined declaratively and attached to specific classes known as composable classes. These composable classes also act as presenters by defining the bridge to the underlying model, in addition to the widget interaction logic. Spec reuse includes these presenters, i.e. Spec allows for the reuse of widget logic and their composition as well as their connection to the underlying model. This support for reuse is not only novel but we also consider it the most important contribution of Spec, as its use removed a high amount of code duplication in Pharo 2.0.

This paper is structured as follows: We next detail the issues that emerge from the current UI builder approach. This is followed, in Section 3, by an introduction of Spec that builds a number of UIs highlighting reuse. In Section 5, we provide a more formal description of the different elements used in the example, and Section 4 gives an overview of the more salient points of its implementation. Spec is currently used in Pharo, and we talk about this in Section 6. Related work is discussed in Section 7, and Section 8 concludes.

UI Builder Challenges

A UI builder is a tool used to generate user interfaces. Such builders help the developers by providing a framework for UI construction on top of the UI libraries provided by the language. They may also provide a UI for graphically building a UI. Put differently, a UI builder is not necessarily a tool with a UI although it may provide a UI to interactively place widgets on a canvas.

To be able to help the developers in creating UIs, UI builders usually provide support for:

• the description of widgets (color, size, visual effect, specific behavior,...)

• the description of their placement

• the definition of the widget behavior, e.g., how it reacts to certain events.

However in our experience the above is not enough. This is because developing UIs is not only about widget generation, but also about the reuse of the logic between widgets. As Pharo maintainers we have seen that most of the UIs of the tools present in Pharo were written from scratch. This even if a lot of tools are essentially manipulating the same objects and rendering them more or less the same way. This lack of reuse makes the system harder to maintain and slows down enhancements to the UIs of these tools. To address these problems, UI builders should also support the reuse of widget logic and composition. We have seen that the logic of one widget is often based on the wiring of the logic of adjacent or nested widgets. Hence being able to compose and reuse existing behavior is central to be able to build new widgets.

The goal of reusability however brings a new problem. Indeed, if the widgets must be reusable it means that on one hand the widgets must be generic enough to be used in different scenarios and on the other hand they should be parametrizable enough to fit these new scenarios.

To enable the reuse in the process of building and maintaining the UIs of Pharo, we have built Spec. Spec is a new UI builder whose goal is to support UI interface building and seamless reuse of widgets. Spec is based on two core ideas: first the declarative specification of the visual behavior of widgets and their logic, and second inherent composability of widgets, based on explicit variation points.

Figure 1 shows the principles of Spec: a UI is built from composed widgets that are glued together using ports and whose visual characteristics are defined using a declarative specification that are reused over composition.

Spec by Example

In this section we introduce Spec and its key points by showing an example of the typical use of Spec. Note that we only focus here on the logic of the building process, the discussion of a graphical tool to compose widgets based on Spec is out of the scope of the paper.

The example we develop in this section starts with showing how basic widgets are composed to build a simple UI and continues with illustrating how these composed widgets can be reused and adapted to build more substantial UIs. In total we build three UIs: a Method List that shows a collection of methods, in Section 3.1, a Method Browser that reuses the list and adds a pane showing the source code of the method, in Section 3.2, and lastly a Class Browser, reusing and adapting the Method Browser, in Section 3.3.

Methods List

In this section, we present how to build a method list in five steps:

1. the creation of the class; 2. the implementation of the initialize process; 3. the implementation of the getters; 4. the specification of a layout; 5. the window title.

We will now present these four steps in more detail.

Class Creation. First we need to create a class named MethodsList.

ComposableModel subclass: #MethodsList instanceVariableNames: 'list' classVariableNames: '' poolDictionaries: '' category: 'IWST12-Spec'

Here we can see two things:

• the superclass is ComposableModel: this class is the root of the Spec UI model hierarchy.

• the instance variable list: an instance variable needs to be defined for holding the UI model that will represent our methods list.

Initialization. Second, the initialization. The initialization of a UI can be done in three different methods:

1. initializeWidgets: to set the instance variables which hold sub models and their associated widgets and to configure these sub UI models;

2. initializePresenter: to wire sub UI models together;

3. initialize: to initialize remaining state of the UI.

In this example, only the widget instantiation has to be done in the initializeModels method of the MethodsList class, such that it sets the list instance variable to contain a List-ComposableModel with its associated list UI element.

MethodsList>>initializeWidgets

self instantiateModels: { #list -> #ListComposableModel }.

The code above shows how the model for the list is instantiated, in a declarative fashion. The method instantiate-Models: allows one to provide a collection of associations where the key is the instance variable name and the value is a UI model class. Hence the code above creates a new instance of ListComposableModel (and its associated list UI element) and stores it in the instance variable list.

Accessors. Third the accessor to the instance variable has to be implemented, such that the Spec infrastructure can obtain this list instance when required.

MethodsList>>getList ^list

Layout Specification. Fourth we specify a layout: the object that is used to describe and represent the layout of the UI elements. This is done by implementing a method that returns it on the class side of the UI model. For our example, we implement MethodsList class»myFirstSpec on the class side of MethodsList as follows:

MethodsList class>>myFirstSpec <spec: #default> ^SpecLayout composed add: #getList; yourself.

Since multiple layouts per UI model can be present, there is a mechanism to set the layout to use by default. There are two ways to define the default specification to be used:

1. pragma: all specifications are tagged with a pragma <spec:> allowing the spec infrastructure to correctly retrieve the corresponding method. In addition, the keyword default can be used in the pragma to specify that this layout has to be used by default.

2. method name: if there is no <spec: #default> tag, the method named defaultSpec is used.

The code above uses a pragma and simply returns the layout object for this UI. Sending the message composed to the SpecLayout class yields a composed layout, which allows one to compose the different models that are part of Spec. To this composed layout, the add: message is sent, adding the argument to the layout. In this case we provide the symbol getList, the selector of the getter of the model we want to include into the methods list. Note that, in general, this argument may be a SpecLayout as well, allowing for the reuse of high level composed models, as we shall show later.

Executing the following snippet displays the generated widget embedded in a window using the above, default, specification. It produces the window.

MethodsList new openWithSpec.

To populate the list, the message items: has to be sent to the instance variable list with a collection of items to be shown as argument. In our example this would be a collection of methods, e.g., the methods of the class Object as shown below:

(MethodsList new openWithSpec; yourself) getList items: Object methods
By default, the method printString is sent to each item to produce the string used to display the item in the list. Often the default behavior displays to much information, or is not accurate enough. To address this, a block can be used to specify how to generate the display string. This is achieved by sending the message displayBlock: to the list widget. The following code provides an example of how to specify a display block in the initializeWidgets method such that the displayed string follows the form class name»selector. When the window is opened, each item is displayed as shown in Figure 2. The code above returns the selector of the selected method, or the string 'Methods List' if no item is selected.

In order to update the title each time the selected item of the list has changed, we must relate the selection action in the methods list to the updating of the window title. This hence needs to be implemented in the initializePresenter method, and is as follows:

MethodsList>>initializePresenter list whenSelectedItemChanged: [ self updateTitle ].
The code of the method states that the title of the window should be updated when the selected item in the list changes. In Figure 3 we show the result of these changes: a window where the title is the selector of the selected item.

Public API. This completes the construction of the UI model. However if we want this UI model to be reused and Those methods will be used in the following section when defining its public API, which is used in our last example (In Section 3.3).

Methods Browser

To show how Spec allows for the reuse of existing models, the next step of our example builds a message browser which reuses the method list we just constructed. We will follow the same five steps as previously:

1. the creation of the class;

2. the implementation of the initialize method;

3. the implementation of the getters;

4. the specification of a layout;

5. the window title.

These steps will now be presented in more details.

Class Creation. First we define a class, this time named

MethodsBrowser.

ComposableModel subclass: #MethodsBrowser instanceVariableNames: 'methodsList text' classVariableNames: '' poolDictionaries: '' category: 'IWST12-Spec'

The class has two instance variables:

• methodsList: the list for displaying the methods. It will be an instance of the MethodsList class we defined in Section 3.1, i.e., we reuse the methods list we defined previously.

• text: the text zone used to display the source code. It will be an instance of TextModel.

Initialization. Second, in the initialize process, we have to instantiate the value for each instance variable.

MethodsBrowser>>initializeWidgets self instantiateModels: { #methodsList -> #MethodsList. #text -> #TextModel }
The above code shows that a model that is being instantiated can be a standard class of Spec as well as any UI model class that has been defined using Spec. This is the key feature that allows for seamless reuse of models in Spec.

Next, we specify the overall behavior of the UI, linking the two widgets together. When an item from the list is selected, the text area should display its source code. The initializePresenter method above specifies the overall behavior of the UI. It links the list to the text field by stating that when a item in the list is selected the text of the text zone is set to:

• an empty string if no item is selected

• the source code of the selected item otherwise.

Accessors. Third we implement the getters needed by the layout.

MethodsBrowser>>methodsList ^methodsList

MethodsBrowser>>text ^text

Layout Specification. Fourth we specify a presentation, by defining a method at the class side.

MethodsBrowser class>>spec <spec: #default> ^SpecLayout composed add: #methodsList origin: 0@0 corner: 1@0.5; add: #text origin: 0@0.5 corner: 1@1; yourself

In addition of showing that the reuse of a Spec model is transparent with regard to the layout, the above method also shows that a position can be specified for each sub-model.

Here, methodsList will be displayed in the top-most half of the generated widget while text will be displayed in the bottom-most half of the generated widget.

The following snippet opens the widget and populates the list with the methods of Object: Window Title. When an item is selected the title is not updated as it used to be in MethodsList. This is addressed by implementing a title method, and slightly modifying the initializePresenter method as follows: This gives us a dynamic title, as shown in Figure 5. Public API. Recall that to have a reusable model, we need to define its public API. We will reuse this model in our last example, therefore below we show the methods of the public API for our MethodsBrowser. As these are straightforward we do not discuss them in more detail. Note that the methods we invoke here are part of the public API we defined at the end of section 3.1.

Conclusion.

This concludes the construction of our methods browser. In the construction of this browser we have shown how we can straightforwardly reuse existing models and how a selection in one widget can be used to update the display in another widget, effectively linking widgets together.

Classes Browser

The last example we provide shows how to parametrize the reuse of models, and how a UI communicates with the underlying model. We do this by illustrating how to build a simple class browser that reuses the MethodsBrowser. Being able to deeply parametrize models allows for extended reuse possibilities of the models since they can be more generic.

The five construction steps essentially are still the same, therefore we first only show a overview of the browser construction process. We will instead focus on how the reuse of user interface specifications can be parametrized. Second we modify the behavior of the reused UI model, and third modify the layout of the reused models. Fourth and last we show how to connect the browser to the class structure, i.e. to its model.

Basic Reuse. The class for the browser is called Classes-Browser and it has two instance variables: classes for the list of classes, and methodsBrowser for the list of methods and the text zone, i.e. the methods browser we constructed above. The layout specification below shows how the two are laid out.

ClassesBrowser class>>defaultSpec <spec> ^SpecLayout composed add: #classes origin: 0@0 corner: 0.5@1; add: #methodsBrowser origin: 0.5@0 corner: 1@1; yourself.

For brevity, we omit the methods that set the title, the accessors and the initialization methods that instantiate the widgets and link them together. The below snippet pops up the window shown in Figure 6 and populates it with all the classes of the system. In our example, when a class is selected in the classes browser, its methods are displayed. But they are displayed following the form class name »selector, where the class name is redundant as it is already given by the list selection. Also, the title shown is not correct: it displays the default title, 'Untitled window', even when items in the method list are selected. To perform these two parametrizations, we modify the initialization methods of ClassesBrowser to override the behavior specified in MethodsBrowser. The modifications consist in adding one line to the method, as shown below. Recall that these methods we are calling are part of the API we defined at the end of Section 3.2.

The default behavior of Spec is to ignore the window title logic of reused models, hence the presence of the default title. The last line above configures the reused method browser to update the title on a list (de)selection, using the title method defined in the classes browser. We therefore also have to implement ClassesBrowser»title. The following implementation inspects the selection of method browser to return the appropriate value. It returns 'Classes Browser' if nothing is selected, or the selected class name if only a class is selected, or class name »selector if both a class and a method are selected. As shown in Figure 7, the methods are now displayed using only their selector and the title follows the form class name »selector, since a method is selected.

Layout Specification. The current layout of the Classes-Browser view is somewhat unusual. The classic layout for such a tool is to have the two lists in a row in the top-most half and the text zone in the bottom-most half. To do this, a new layout is provided by implementing a new spec method, and set as the default spec: add: #classes origin: 0@0 corner: 0.5@0.5; add: #(methodsBrowser methodsList) origin: 0.5@0 corner: 1@0.5; add: #(methodsBrowser text) origin: 0@0.5 corner: 1@1; yourself

In the above code, instead of using the methodsBrowser layout we define precisely how we want the sub-widgets to be rendered. The result is the widget shown in Figure 8: a classes browser with the two lists in the upper part and the text zone in the lower part. Connecting the UI to the Underlying Model. As is, the UI we built is disconnected from the model it is representing: after we pass it an initial list of classes we are not able to modify it, e.g., by editing methods, and it is not aware of any modifications made to its model by other browsers. We now show how to connect the UI to the underlying model, by specifying menu actions to enable the former, and subscribing to announcements to implement the latter. As this behavior belongs in the methods browser, we specify it there, and it will automatically also be present in the classes browser.

The text widget present in the methods browser provides for a standard code editing menu, where we can specify the action to take whenever the code is saved or accepted. This is performed by providing an accept block, as illustrated below: The code obtains the text field from the methods browser and specified that the code, contained in the text parameter should be compiled. (We do not include the compilation code as it is not pertinent to this discussion.)

Lastly, to have the browser to react to changes in the underlying class structure, we use the system announcements mechanism to refresh its contents when needed. We rely on the fact that when such changes occur, the system raises an announcement, and subscribe to these announcements, for example using the code below the browser becomes aware of methods being added, adding them to the list of methods shown. The methodAdded: method first keeps a copy of the text being shown in the text field, as it may contain edits that have not been saved. It then obtains the selected item in the methods list, and adds the new method to the list. As the change in list items may change the selection in the list, it then sets the selected item to the previously stored value. Lastly, it sets the text being shown in the text field to the value stored in the first step.

MethodsBrowser>>initializePresenter

Conclusion.

This concludes the construction of our last example: a methods browser. In this section we have seen how it is possible to parametrize both the behavior and layout of UI models that are being reused. This allows for more generic models to be reused and customized further when needed, increasing their reuse possibility. We have also shown how to connect the user interface to an underlying model, yielding a fully functional UI.

The Implementation of Spec

The implementation of Spec is based on two pillars: the presence of a SpecLayout and the use of value holders. The SpecLayout is used to describe how the graphical elements are positioned inside the generated UI, by using either basic widgets or by reusing composed widgets. The value holders are used to store the variation points of the model and to react precisely to one of these changes. This way the UI updates are less frequent and more precise, and hence faster.

To avoid any ambiguities in this text due to issues with terminology, we first define three terms briefly, since these typically have overloaded meanings.

UI Element: an interactive graphical element displayed as part of the Graphical User Interface.

UI Model: an object that contains the state and behavior of one or several UI elements.

Widget: the union of a UI Element and its UI model.

In this section we will discuss these two points in more detail, firstly talking about SpecLayout and secondly discussing the value holders.

SpecLayout and its Interpreter

The SpecLayout describes and represents the layout of the UI elements in Spec. More details about how to manipulate SpecLayout objets will be provided in Section 3.1. A Spec interpreter is used to build a UI widget from this layout. To have a static structure which can be easily used by the interpreter, the SpecLayout object is converted to an array before it is passed to the interpreter.

We have only seen here the composed layout, consisting of an aggregation of different Spec widgets. However there are additional kinds of layouts provided: one kind for each type of widget. This allows one to attach specific behavior to each spec type, e.g.,, the class of the UI element specific to this kind of layout. The array representation of a spec has as first element an identifier of its type.

By using a spec type, default behavior can be defined and shared among all the widgets. It means the all the widgets produced by a defined spec type can be changed by modifying the spec type itself. Types also allow the creation of a data structure representing the tree of sub-widgets and to use a visitor pattern to build tools on top of specs, e.g., like a UI builder.

The remainder of the array representation of a spec can be seen as a stack: each time a selector is read, as many arguments as needed by the selector are popped and analyzed. The spec interpreter iterates over a SpecLayout array and builds each part of the widget by recursively interpreting each element.

A SpecLayout allows one to specify where to position a widgets sub-widgets, and also allows one to position the subwidgets of sub-widgets. This provides a way to reuse generic widgets while being able to customize them sufficiently to make them conform to a new usage scenario.

Value Holder

A value holder is a simple object which wraps a value and raises an announcement when this value is changed. Thanks to this mechanism we can use value holders as wrappers around model values and make the UI react at specific changes to the model. As such, we provide an event based structure that allows one to react to only to value change of interest.

The above means that, for example, the selection index of a list is stored in a value holder. When a new item is selected, the index changes, and the corresponding value holder raises an announcement. The basic widgets of Spec provide as part of their API event registration methods, which allow a userdefined object to react to this change if needed.

Moreover, having a value holder for each model data allows one to update the UI only for the data which has changed, without having to examine this change to establish its relevance as the DependencyTransformer in Vi-sualWorks. This is in contrast to classical MVC [START_REF] Krasner | A cookbook for using the model-view-controller user interface paradigm in smalltalk-80[END_REF] and MVP [START_REF] Potel | Mvp: Model-view-presenter. the taligent programming model for c++ and java[END_REF]. Here, when the observable object has changed, it sends an update: message to all observer objects with the changed value as argument. Then in the update: method, the observer has to examine the argument is to react in accordance with the change. In Spec, the observer registers to each observables' value holder it is interested in, and for each value holder specifies a method to invoke when the value holder is changed. Hence the examination of the updated value is no longer necessary and the dispatch to the appropriate update logic is done naturally without any switch case.

In addition, since the whole event flow is controlled and propagated through value holders, we can ensure that there is no event loops due to circular events sends.

Note that since every object can register to a value holder changes, this means that a model can register itself to any of it sub-widgets value holders, or any sub-widgets sub-widgets value holder. Thanks to this, a model can add new behavior for its sub-widgets. This provides a way to reuse generic widgets while being able to parametrize them enough to make them correspond to a new scenario.

The spec of Spec

In this section we summarize the specification of the public APIs of the relevant building blocks for a user of Spec: the basic widgets and SpecLayout.

Models public API

To build a UI the user combines basic UI models and existing Spec models as required. For Spec there is however no distinction between these two, as basic UI models are reified as Spec models. Put differently, these basic UI models are Spec models that simply wrap the widgets that are provided by the GUI framework.

Due to lack of space, we do not provide a complete specification of the public API of all models provided by Spec (11 models, in total 228 methods). The complete API for all models is provided as part of a tech report about Spec [START_REF] Van Ryseghem | [END_REF]. We restrict ourselves here to the public API methods of Selector Result displayBlock:

set the block used to produce the string for displaying items items:

set the contents of the list resetSelection unselect selected items selectedItem return the last selected item whenSelectedItemChanged: set the block performed when the selected item changed set the block to perform when the pending text is accepted (saved) text:

set the text of the widget to the value provided as argument whenTextIsAccepted: set a block to perform when the text is accepted whenTextChanged: set a block to perform when the text has changed Table 2. TextModel public API the basic models used in this paper: ListComposableModel, shown in Table 1, and TextModel, shown in Table 2.

SpecLayout

A SpecLayout is an object used to describe the layout of the UI elements of a widget.

The SpecLayout class provides a small API (only 8 methods), shown in table 3. The add methods cover the bulk of the use cases: adding elements to the layout. Indeed, as we will see in Section 3 they are the only methods used when the layout is a composed layout.

The remaining two send methods are required to be able to interact with basic widgets. Since the Spec reification of basic UI models provides a bridge between Spec and a graphical library, the class of the UI element nor its API can be predicted. Hence we need to be able to send any message to those classes through the SpecLayout. To allow for this, the SpecLayout provides for the send methods, which enable performing any selector with the corresponding arguments. Thanks to these methods we ensure that a bridge can be built between Spec and any graphical library.

As an example use of the send:withArguments: method, the following code is the implementation of TextModel class»defaultSpec, which defines the binding between Spec and the Morphic UI framework for the TextModel widget. (Due to the low-level nature of this code we do not explain its functionality in detail.)

defaultSpec

Spec in Pharo

Spec has been introduced in Pharo 2.0 with the goal to be used for rewriting all the tools. For now, six different widgets have been implemented:

1. MessageBrowser: a tool made for browsing messages (similar to the MethodsBrowser made in section 3.2); 2. Senders/Implementers: a tool to browse the senders or the implementors of a given selector;

3. ProtocolBrowser: a tool to browse all the methods that a given class can understand;

4. VersionBrowser: a tool used to browse the different versions of a provided method;

5. ChangeSorter: a tool made for managing the changes of the system; 6. DualChangeSorter: a second tool for managing changes, with focus on the transfer from one change sorter to another.

As a testament to the possibilities of reuse the Message-Browser is used for the Senders/Implementors, and the Pro-tocolBrowser. Moreover the DualChangeSorter is made of two ChangeSorter linked together and specialized to add functionality involving the interactions between the two change sorters.

Selector

Result add:

add the object provided as argument. This object can be the selector of a getter to an instance variable storing a ComposableModel or another layout. add:origin:corner: add the object provided as argument and specify its position as fractions. add:origin:corner:offsetOrigin:offsetCorner: add the object provided as argument and specify its position as fractions and offsets. add:withSpec: add the model provided as first argument using the selector provided as second argument for retrieving the spec. The first argument can be the selector of a method that returns a Composable-Model or a collection of such selectors. add:withSpec:origin:corner: add the model provided as first argument using the selector provided as second argument for retrieving the spec. and specify its position as fractions. add:withSpec:origin:corner:offsetOrigin:offsetCorner: add the model provided as first argument using the selector provided as second argument for retrieving the spec. and specify its position as fractions and offsets. send:

send the message with selector specified as first argument to the underlying widget send:withArguments: send the message with selector specified as first argument and arguments specified as second argument to the underlying widget.

Table 3. SpecLayout public API Table 4 shows the difference in the number of lines of code (LOC) used to implement those tools before the use of Spec (Pharo 1.4) and after (Pharo 2.0). The purpose of this table is to emphasize the reduction of code duplication. The table follows the form:

• in the first column the name of the tool which is being compared;

• in the second column the name of the class used to implement this tool in Pharo 1.4 and the number of LOC used to implement it;

• in the third column the name of the class used to implement this tool in Pharo 2.0 and the number of LOC used to implement it;

• the ratio in LOC reduction.

We will now explain the difference for each line in more details.

MessageBrowser. MessageSet is used in Pharo 1.4 to browse a collection of method references. MessageBrowser from Pharo 2.0 covers all the functionalities of MessageSet and even add new features like a topological sort or a update mechanism and the support for methods in addition of method references. Yet MessageBrowser is still smaller because thanks to widget reuse, some data of the UI itself is managed by widgets that are being reused, e.g., index selection management. But when summing up both applications, the Spec implementation is smaller even while covering all the original functionalities. This is for two reasons: firstly because checking ubiquitously for being part of a dual change sorter is expensive in term of lines of code. Secondly for the same reason than for the use of MessageBrowser, relocating UI element management to a sub-widget allows the reusing code to be concise.

Conclusion.

In this section we have seen how the reuse provided by Spec is used in Pharo and how this reuse can reduced the number of lines of code (and the code duplication) by almost half. This confirms our assertion that there is a need for a declarative way to specify UIs that also allows for seamless composition and reuse of the UI declaration and logic. Moreover this shows that Spec is an effective tool to address this need. As a consequence of this observation, rewriting all the tools using Spec is a goal for the next version of Pharo.

Related Work

Spec is inspired by the VisualWorks [START_REF] Parcplace-Digitalk | VisualWorks cookbook[END_REF][11] UI framework, and like it is based on static specifications i.e. the SpecLayout instances at class side. In VisualWorks all the specifications are performed in terms of low level widgets which means that no composed widget can be reused. In contrast, Spec allows the reuse of high level widgets and as a result, the specifications are simpler. Thanks to this fact the UIs can be composed of smaller widgets that make the system more modular and easier to maintain.

Spec also follows the lead of Glamour [START_REF] Bunge | Scripting browsers with glamour[END_REF] in favoring an event-based flow through the widgets. However, Spec can be used for every kinds of UI while Glamour is restricted to browsers. Spec widgets also explicitly declare a public API instead of heavily relying on blocks, as Glamour does.

For the UI generation part, Spec is different from tools like NetBeans [START_REF]Netbeans ide[END_REF] or WindowBuilder [START_REF]Windowbuilder user guide[END_REF] in the sense that they both only provide graphical tools for generating user interfaces while Spec is based on a text based description of the UI. Furthermore, where NetBeans and WindowBuilder generate java code, Spec uses an object and relies on this object for describing the user interface. Instead NetBeans or WindowBuilder use an XML file or parse Java source code. The disadvantage of this is that if the XML file is edited by hand or if some parts of the generated Java code is refactored these tools are not always able to handle these changes.

In addition of the UI code Spec also provides a framework for the model behavior when NetBeans or WindowBuilder only provide UI elements generation source code. Indeed, Spec can be used to define (and reuse) the logic links between widgets where NetBeans or WindowBuilder can only be used to generate UI elements.

XUL [START_REF]XUL -MDN[END_REF] is an XML based language used for describing and reuse widgets through overlays. While a group of widgets can be reused, unlike Spec XUL doesn't allow for locally changing the inner logical links. SWUL [START_REF] De Groot | Implementation of the java-swul language: a domain-specific language for the swing api embedded in java[END_REF] is a DSL based on the strategy transformation framework that proposes a more declarative syntax for expressing widgets description in Swing. SWUL behaves like XUL in the sense of not being able to locally redefine the behavior of a subwidget.

Conclusion

In this paper we presented Spec, a UI builder whose goal is to support UI interface building and seamless reuse of widgets. Spec is based on two core ideas: first the declarative specification of the visual behavior of widgets and their logic, and second inherent composability of widgets, based on explicit variation points.

In our experience maintaining Pharo, we have seen that there is a nontrivial amount of code duplication in UI code which can be avoided and that the logic of one widget is often based on the wiring of the logic of adjacent or nested widgets. Hence being able to compose and reuse existing behavior is central to be able to build new widgets.

We have shown how Spec can be used, by providing three example UIs that highlight the reuse and parametrization features of Spec. This was followed by a more formal specification of the APIs used in the example and an overview of the most relevant points of the implementation. We then showed how Spec enabled a 57% of code reduction in the reimplementation of six UIs of Pharo, thanks to a high amount of reuse of widgets.

The latter shows that Spec provides ample support for reuse of widgets and is an appropriate tool to address the problem of code duplication in UI code. As a consequence it will be the standard UI builder for Pharo 2.0 and all UI tools in Pharo will be rewritten using Spec.

Figure 1 .

 1 Figure 1. Spec principles

  MethodsList>>initializeWidgetsself instantiateModels: { #list -> #ListComposableModel }. list displayBlock: [:method || name | name := method methodClass name. name, '>>#', method selector ].

Figure 2 .

 2 Figure 2. The methods list with a specific display

Figure 3 .

 3 Figure 3. The methods list with a dynamic title

  MethodsBrowser>>initializePresenter methodsList whenSelectedItemChanged: [:method | text text: (method ifNil: [ '' ] ifNotNil: [ method sourceCode ]) ]

(

  Figure4shows the result of executing the above code.

Figure 4 .

 4 Figure 4. The methods browser

Figure 5 .

 5 Figure 5. The methods browser with the dynamic title back

Figure 6 .

 6 Figure 6. Classes browser

  ClassesBrowser>>initializeWidgets "... omitting code for behavior shown previously ..." methodsBrowser displayBlock: [:method | method selector ]. ClassesBrowser>>initializePresenter "... omitting code for behavior shown previously ..." methodsBrowser whenSelectedItemChanged: [ self updateTitle ].

  'Classes Browser' ] ifNotNil: [:class | methodsBrowser selectedItem ifNil: [ class name ] ifNotNil: [:method | class name, '>> #', method selector ]].

Figure 7 .

 7 Figure 7. Classes browser with methods displayed using their selector

Figure 8 .

 8 Figure 8. Classes browser with a classic layout

Figure 9 .

 9 Figure 9. The three levels of layers composing the ClassesBrowser UI

  MethodsBrowser>>initializePresenter "... omitting code for behavior shown previously ..." self text acceptBlock: [ :text :notifier | ... compile the text ... ].

Table 1 .

 1 ListComposableModel public API

	Selector	Result
	accept	force the text zone to accept the pending text
	acceptBlock:

Table 4 .

 4 Comparison between tools in Pharo 1.4 and Pharo 2.0 ChangeSorter. The two tools have been grouped since the implementation in Pharo 1.4 moved the logic of the Du-alChangeSorter into the ChangeSorter class. ChangeSorter instances are aware of belonging to a DualChangeSorter or not and act accordingly. In Pharo 2.0 the ChangeSorterApplication class is smaller than the ChangeSorter class because it only knows about itself. It doesn't contain any information about being part of a DualChangeSorterApplication or not. This is because the DualChangeSorterApplication class knows how to reuse ChangeSorterApplication and what logic to add, and as a result is bigger than the DualChangeSorter class.

	Senders/Implementers. FlatMessageListBrowser is used
	in Pharo 1.4 to browse the senders or implementers of a
	selector. In Pharo 2.0 we have decided to reuse Message-
	Browser since senders and implementers are also a collec-
	tion of method references. MessageBrowser already covers
	all the FlatMessageListBrowser functionalities, and more-
	over adds the topological sort and the update mechanism as
	well. Only a trivial modification needed to be made to Mes-
	sageBrowser. Hence the Senders/Implementers browser is
	actually a MessageBrowser, where we implemented the re-
	quired API to open the corresponding list of messages. This
	explains why the number of line for this tool in Pharo 2.0 is
	so small.
	ProtocolBrowser. ProtocolBrowser is used in Pharo 1.4 to
	browse all the methods that the provided class can under-
	stand. Again, MessageBrowser covers all the features of Pro-
	tocolBrowser and still adds the topological sort and the up-
	date mechanism. As above, MessageBrowser is reused, by
	adding the logic specific to the ProtocolBrowser. These 20
	LOC are the algorithm to collect the relevant methods.
	VersionBrowser. NewVersionBrowser provides a new tool
	in Pharo 2.0 that covers all the functionality of the previ-
	ous tool. Implemented as its own class, it reuses Message-
	Browser for the UI and beyond that only contains version
	retrieval methods and UI specialization methods. This leads
	to a low number of LOC.

Acknowledgments

This work was performed in the context of the INRIA Associated Team PLOMO (2012).

Availability

Spec is part as standard of Pharo 2.0 and is also available in Pharo 1.4, its Metacello configuration is called Con-figurationOfSpec and is available from SqueakSource3 (http: //ss3.gemstone.com/).


Corentin Follenfant

Olivier Corby

Fabien Gandon

David Trastour

RDF Modelling and SPARQL Processing of SQL Abstract Syntax Trees

Keywords: query modelling, query languages, query graphs, abstract syntax trees, Linked Enterprise Data

published or not. The documents may come   L'archive ouverte pluridisciplinaire

Introduction

The vast amounts of data federated into organisations' data warehouses are usually analyzed through a variety of dynamic documents authored with business intelligence (BI) tools. Consumption of such documents is accessible to business users as the data is organized into graphs, charts or pivot tables. However, their authoring remains limited to users with technical skills, as it often involves query editing. A broad range of information retrieval (IR) systems have proved useful in assisting users by suggesting them similar documents or queries for reuse, but they depend on consistent, i.e. human-authored and thus sparse metadata. The sole formal common ground shared by documents from differents tools is their SQL or derivatives (e.g. MDX) queries.

We consider these SQL queries as metadata that IR systems can leverage with two desirable features: search and modification. Query search can be used to find queries that target a specific rowset or apply given transformations onto it, by looking at both queries content and structure. For instance, one can look for SQL queries that perform an aggregation of Order Price over Customers. A search engine shall address several problems to find queries that match this pattern. First, it must identify the query atoms that refer to Order Price and Customers, likely columns from an Orders table, and align their different occurrences (e.g. aliases). Second, it must consider the position of these atoms with respect to the scope of given operators, in this case an aggregation function and a GROUP BY clause. Finally, it has to look for all the operators considered as aggregate functions, i.e. it needs rich typing of the query structure. Query modification is another IR approach which attempts to edit a query in order to have it yield more results (relaxation), less results (restriction), different results (shift), or equivalent results with better performance (rewriting). As it involves editing the target query, the modification approach requires a read/write meta-querying language. It can be used to search for similar queries that do not exactly match the initialy provided query pattern.

In this paper we present an approach where we annotate BI documents with their SQL queries. We represent SQL queries with their abstract syntax trees (ASTs) as RDF graphs, which allow 1) to type the tree nodes accordingly to the SQL construction they represent, 2) to identify queries with the URI of a named graph containing the graph of their AST, and 3) to annotate queries with contextual metadata, e.g. the documents that trigger them. We then present SPARQL queries that can be used against a repository of such SQL queries modelled in RDF, i.e. to perform meta-querying according to the desirable features earlier described.

The remainder of this paper is organized as follows: in section 2 we present related works that frame ours. Section 3 then details the framework for modelling SQL queries with RDF graphs, and outlines a vocabulary that captures basic SQL ASTs. We then detail SPARQL queries usable for convenient search and modification of SQL queries expressed with our model, with preliminary examples shown in section 4, before concluding and giving perspectives in section 5.

Related Work

The task of authoring BI documents can be made easier by IR systems that take into account metadata about their queries [START_REF] Priebe | Towards integrative enterprise knowledge portals[END_REF], which Priebe and Pernul call query context. However, this refers to "elements", i.e. business entities shown as a result of the query execution, rather than the fine-grained query structure underlying the document.

Modelling and storing queries to enable meta-querying has been investigated in both RDF and relational formalisms, but to the best of our knowledge no approach relates them in either way. In the relational world SQL queries can be broken down into XML trees, thus requiring additional XML querying operators to be added to SQL meta-queries [START_REF] Van Den Bussche | Towards practical meta-querying[END_REF]. SnipSuggest [START_REF] Khoussainova | SnipSuggest: Context-Aware Autocompletion for SQL[END_REF] aims at user assistance through query autocompletion mechanisms. It maintains a query repository in relational tables where query metadata are stored as features, where we consider the whole query AST. Relational query rewriting has been approached from a graph perspective by decomposing queries into atomic subgoals to be connected [START_REF] Konstantinidis | Scalable Query Rewriting: A Graph-Based Approach[END_REF]. The main query modelling contribution in the semantic web world lies in the SPIN vocabulary [START_REF] Knublauch | SPIN -SPARQL Syntax[END_REF], which allow SPARQL queries to be represented in RDF.

Ferré proposed to represent ASTs of generic mathematical expressions as Prolog terms, which are easily mapped in RDF. He focuses on search and navigational features provided through an extension of LISQL [START_REF] Ferré | Extension du langage de requêtes LISQL pour la représentation et l'exploration d'expressions mathématiques en RDF[END_REF]. While we merely extend this model to capture SQL queries ASTs, we process them with standard SPARQL 1.1.

Besides query modelling, works aimed at connecting relational and semantic web applications have rather focused on translating data and queries from one formalism to the other, e.g. from relational to RDF with the R2RML standard currently developed by W3C [START_REF] Das | R2RML: RDB to RDF Mapping Language[END_REF], and vice versa.

Query Modelling and Semantic Web Graphs

The same way SPIN captures SPARQL queries into RDF [START_REF] Knublauch | SPIN -SPARQL Syntax[END_REF], we want to capture SQL queries in RDF. SQL queries can be represented with abstract syntax trees, when looking at all the constructs of a query as expressions in prefix notation. Thus, a set of queries can be represented with an RDF graph by appropriately minting URIs for shared SQL identifiers [START_REF] Das | R2RML: RDB to RDF Mapping Language[END_REF]. We model the syntactic structure of the trees, and RDF allow to further annotate them with additional metadata or link them together. For example, references to cryptic column names that abound in enterprise software can be annotated with the concepts or attributes types they represent.

The rationale for capturing SQL ASTs in RDF is the following: all the constructs are composed of typed blank nodes that represent operators and operands, in a broad sense. Operators include SQL clauses, mathematical terms, logical predicates or functions. Whatever the arity of an operator, its operands are represented as rdf:List collections (closed containers). The arguments are attached to the typed node with the argument property. Operands themselves can be atoms or further operators. Atoms are either constants with a rdf:value property, or SQL objects with a sql:identifier property, and have no list of arguments. The RDFS vocabulary used to type the nodes of ASTs according to this is outlined in figure 1. To keep the diagram concise we omit leaf subclasses that denote proper functions (mainly aggregates sum, average, min/max), logical predicates and mathematical operators. We use an arbitrary namespace with the sql: prefix.

This extract is limited to the selection subset of the data manipulation language (DML), but can be extended to capture other DML as well as data description language statements. Listing 1 shows an example SQL query retrieving the total amount of orders per customer which were placed in Q3. This query matches the search pattern described in section 1. Listing 2: Q1 modelled in RDF/Turtle

Preliminary Evaluation: SPARQL Meta-Querying

Meta-querying is defined as querying a database containing queries. In the previous section we proposed a model to represent such a query database as RDF graphs. We now investigate the use of a native RDF query language, SPARQL 1.1, to access these graphs while keeping in mind the search and modification features presented in section 1. The following meta-querying scenarios apply:

1. finding a query knowing its (partial) structure; 2. finding queries targeting known base tables; 3. finding similar queries to a query being built; 4. completing a query structure given frequent structure patterns; 5. iteratively modifying queries e.g. to relax constraints.

Items 1, 2 and 3 can be categorized as read-only meta-querying, while items 4 and 5 involve writing query modifications. We look at these two approaches in the following subsections.

Query Search

Meta-querying scenarios that involve finding SQL queries similar to a given query, query template or query part can be reduced to authoring an appropriate SPARQL SELECT query. As our ASTs are modelled using RDF closed lists, retrieving one of its node by specifying some of its content is not sufficient: we have to specify the whole list by extension. For instance, finding SQL queries that perform a sum of an unknown column over Customers can be done with the SPARQL query S1.

1 SELECT ?q WHERE { 2 ?q a sql:Query ;

3 sql:argument ( 4 [ sql:argument ([] [ a sql:Sum ] ) ] 5 [] [] 6
[ a sql:GroupBy ; 7 sql:argument ( 8[ a sql:Column ; sql:identifier "Customer"] ) ] ) . }

Listing 3: SPARQL Query S1

However, this meta-query suffers silence, i.e. it will not return true positives that do not exactly have the three clauses (lines 4 and 5) preceding the GROUP BY one, neither those where the sum function is not located on the second position of the select clause (line 3). We therefore use the SPARQL 1.1 property paths to recursively explore lists and look for specific SQL query parts, while releasing the constraints on irrelevant parts of the graph pattern. This leads to the query S2, which releases the writing constraint on terms position.

1 SELECT ?q WHERE { 2 ?q a sql:Query ; Finally, we leverage RDFS entailment of the model described in section 3, in order to take properties and classes subsumption into account. The query S3 generalises S2 by looking for all aggregation functions instead of the specific sum, and reduces verbosity by replacing list explorations property paths with sql:tree+.

1 SELECT ?q WHERE { 2 ?q a sql:Query ;

Query Modification

When a query yields insufficient or no results one might want to approximate it, i.e. to modify it in order to improve any combination of precision, recall or performance. For instance, relaxing the graph pattern constraints of a SPARQL query in order to make the homomorphism less restrictive [START_REF] Hurtado | Query Relaxation in RDF[END_REF]. Examples of query relaxation for SPARQL include replacing literal with variables, relaxing FILTER clauses with respect to values ranges, moving graph patterns to OPTIONAL clauses, or generalizing types with RDFS supertypes. Modification is also useful for comparison, when a syntactic similarity cannot be established between two queries, a search engine can apply rewriting rules in order to esablish semantic similarity. While most exploration or navigation languages cannot perform rewriting as they are by design limited to read-only operations, this can be done in SPARQL 1.1 with CONSTRUCT queries. We perform SQL query modification while only manipulating SPARQL queries, as described in the following approach. Given the target graph T of an SQL query Q modelled in RDF, we run a SPARQL CONSTRUCT query against T in order to produce the RDF graph M of the modified version Q of Q. When serialized in Turtle [START_REF] Beckett | Turtle -Terse RDF Triple Language[END_REF], M can be directly reused as a SPARQL query graph pattern in a SELECT query to search for Q into an arbitrary RDF store. This can be summarized in the scenario shown in listing 6. It is possible to apply iteratively as many CONSTRUCT queries as required, for instance until the result set R provides a required amount of answers. This approach is natively implemented in the Corese/KGRAM 3.11 RDF toolkit [START_REF] Corby | The KGRAM Abstract Machine for Knowledge Graph Querying[END_REF], as its engine uses the same abstraction for both RDF and query graphs: one can cast the result set object of a CONSTRUCT query and use it as a graph pattern for a programmatically generated SELECT query.

Conclusion & Perspectives

Dynamic documents populated by SQL queries are predominant in enterprise environments. Understanding these queries can improve IR systems that deal with these documents, and create a common metadata layer among heterogeneous documents. We introduced an approach to represent SQL queries with RDF graphs, providing an RDFS vocabulary that can capture SQL query statements. We presented initial SPARQL 1.1 queries that allow to search the queries by looking at their content and structure, and a generic query modification technique that can serve a query search engine. Finally, our approach can be considered as a way to produce linked enterprise data over repositories of disparate dynamic documents that only share SQL queries, thus providing linked query data to supplement proprietary metadata.

Future work will involve practical problems investigation. In particular, URI minting for relational databases objects should provide a basis to connect ASTs of queries that share references to identical tables and columns. Second, the query modification problem brings many challenges that depend on the list-based tree modelling. We will further evaluate whether SPARQL 1.1 provides the necessary constructs to perform ad-hoc tree manipulation while keeping queries concise and intuitive. In particular, we plan to compare the use of CONSTRUCT with the SPARQL Update clauses INSERT and DELETE. Tree manipulation operations of interest include tree pruning, subtree addition and moving, connection. On the use case perspective, we are implementing a proof of concept that analyzes documents repositories and builds the RDF graphs representing their SQL queries with intermediary ASTs. We will use these as target graphs to evaluate the SPARQL meta-queries that compute similarity measures, and to formally define equivalence relations that define the notion of query similarity in the context of BI documents. Finally, we plan to extend or refactor the query model in order to evaluate the approach with other languages that produce ASTs, such as multidimensional expressions (MDX).

1

  Fig. 1: Outline of SQL AST vocabulary

3

 3 sql:tree+ [ a sql:GroupBy ; 4 sql:tree+ [ a sql:Column ; sql:identifier "Customer"] ] ; 5 sql:tree+ [ a sql:Select ; sql:tree+ [a sql:AggregationFunction] ] . } Listing 5: SPARQL Query S3

1

  let T // initial SQL query 2 let GP = eval( CONSTRUCT { M } WHERE { T } ) // modify T according to M 3 R = eval ( SELECT * WHERE { GP } ) // search for M query pattern Listing 6: Query Modification in SPARQL

Table (

 (

		[ a sql:Column ; sql:identifier "OrderQuarter" ]
	15	[ a sql:Constant ; rdf:value "Q3" ] ) ] ) ]
	16	[ a sql:GroupBy ;
	17	sql:argument (
	18	[ a sql:Column ; sql:identifier "Customer"] ) ] ) .
		Orders)	Predicate(=)	Column(Customer)
		Column(OrderPrice)	Column(OrderQuarter)	Constant(Q3)
	1 [] a sql:Query ;
	2 sql:argument (
	3	[ a sql:Select ;
	4	sql:argument (
	5	[ a sql:Column ; sql:identifier "Customer" ]
	6	[ a sql:Sum ; sql:argument (
	7	[ a sql:Column ; sql:identifier "OrderPrice" ] ) ] ) ]
	8	[ a sql:From ;
	9	sql:argument (
	10	[ a sql:Table ; sql:identifier "Orders"] ) ]
	11	[ a sql:Where ;
	12	sql:argument (
	13	[ a sql:Equals ; sql:argument (

Fig.

2

: AST for Q1 current operator, whether there are atoms, subexpressions, scalar or aggregate functions, or subqueries. Listing 2 presents the query Q1 modelled in RDF, by applying the process earlier described. The types sql:Sum and sql:Equals are respectively subclasses of sql:Function and sql:Predicate; while the types representing clauses are subclasses of sql:Clause.


Corentin Follenfant

David Trastour

Olivier Corby

A Model for Assisting Business Users along Analytical Processes

Keywords: business intelligence, content-based recommendation, analytical layers, usage semantics

User-centric business intelligence aims at empowering analysts who interact with complex tools, by allowing them to perform accurate data manipulations and analysis without necessarily requiring IT expertise and knowledge of underlying data specifications. Recommender systems contribute to easing their tasks but most of them operate inside walled gardens and cannot assist properly the user throughout his BI workflow. In this paper we introduce a lightweight vocabulary intended to capture fragments of analytical workflows as multidimensional data transformations, within a Semantic Web framework. We utilize this model for calculating content-based recommendations.

Introduction

Traditional Business Intelligence (BI) platforms provide tools that are designed to cover a wide range of operations in a data-driven decision making workflow. The prerequisites steps concern data extraction, cleansing and integration. On top of them come what we call analytical processes: it includes querying, analysis and visual data consumption. These operations often require various technical competencies, for instance SQL expertise and a good understanding of underlying relational models. Since the current businesses landscapes rarely allow users to maintain both technical and analytical profiles, this hinders the decision makers' capacity to leverage the tools at their full potential without requiring extensive assistance from IT departments.

A common approach to tackle this problem is by providing contextual assistance through recommender systems in order to suggest items such as datasets, business entities, queries or visualizations, depending on the current step of the user into his analytical process. Although those systems start to work beyond the legacy U ser × Item space and integrate broader contextual information [START_REF] Adomavicius | Toward the Next Generation of Recommender Systems: A Survey of the State-of-the-Art and Possible Extensions[END_REF], they can hardly be applied on the whole analytical process as items become heterogeneous and implicit rating functions complex.

In this paper we propose an information model based on Semantic Web technologies, designed to capture semantics of sequential transformations applied on multidimensional data structures. We describe a content-based recommendation use case of this model, where items' granularity vary from business entities to analytical processes aspects, and their utility is computed by arbitrary functions over their usage statistics.

Context

BI systems architecture can be split in three layers: first, raw data mainly comes from operational systems where it is stored into heterogeneous databases. Secondly, Extract, Transform, Load (ETL) and integration processes federate those sources into data warehouses. Combined with metadata management components, they expose data through a (hyper)cube model of business entities named after users' familiar terminology: measures (factual data, e.g. Revenue) that can be driven by dimensions (dimensional data, e.g. Country, Year, Store). Thirdly, analytical processes of end user applications such as reporting tools begin by querying the data warehouse layer to retrieve multidimensional data, before applying transformations and visualizations as the user authors his report.

Number of efforts are devoted to making these tools more usable and accessible by involving recommender systems for specific steps of analytical processes. This goes from querying the data warehouse [START_REF] Chatzopoulou | Query Recommendations for Interactive Database Exploration[END_REF][START_REF] Khoussainova | SnipSuggest: Context-aware Autocompletion for SQL[END_REF], to higher-level workflows such as exploration [START_REF] Marcel | A Survey of Query Recommendation Techniques for Datawarehouse Exploration[END_REF][START_REF] Jerbi | Applying Recommendation Technology in OLAP Systems[END_REF]. Assisting users throughout the analytical process requires a common metamodel to capture multidimensional operations.

An Information Model to Capture Usage Semantics

The RDF Data Cube vocabulary introduced by Cyganiak et al. 3 is mainly intended to enable the publication of statistics, and thus provides a metamodel for multidimensional datasets. In order to enable high level description of analytical processes that can be performed within reporting tools, we extend the vocabulary4 as presented in figure 1. Processes are split into sequences of multidimensional data transformations that are derived from users' interactions with the report design tool. Each transformation corresponds to a mda:AnalysisLayer subclass instance. Like a web service in the OWL-S 5 fashion, it consumes and exposes interfaces of multidimensional data structures described by qb:DataStructureDefinition individuals Fig. 1: Multidimensional Analysis extension outline through mda:inputStructure and mda:outputStructure properties. Transformations can thus be interchanged and reused for describing different snippets (reports elements) that share layers of the analytical process. These layers are connected together through sets of bindings, assemblies, that plug the multidimensional structures atoms, business entities represented by qb:ComponentSpecification individuals.

Experiments

Aiming at providing assistance and reuse capabilities to business users who consume reports and have authoring expectations, we leverage our model to compute content-based recommendations. We ran a snippet crawler against a repository of BI reports in order to harvest snippets' underlying analysis sequences and populate an RDF graph with generated triples. The source is an internal repository storing 645 reports used to perform analysis on 101 data warehouse models. A total of 8121 snippets were extracted, all of them being split into up to five layers of transformations over business entities.

Usage statistics measures are extracted from this graph and then used to feed utility functions of a recommender system, for which we identified two granularities of recommendations. First, basic top-k SPARQL queries can suggest business entities that are likely to complete a ProjectionLayer, that is adding dimensions or measures to a snippet's axis. As opposed to this horizontal recommendation, the vertical one aims at recommending entire layers in the analytical process in order to assist a user into reusing relevant transformations or visualizations that can be applied on top of a query. To do so, we compute item similiarity measures for AnalyticalLayer individuals that are not already connected together through assemblies. The similarity measure strategy is adapted from the Levenshtein distance implemented in the iSPARQL extension [START_REF] Kiefer | The Fundamentals of iSPARQL: A Virtual Triple Approach for Similarity-Based Semantic Web Tasks[END_REF].

Conclusion & Future Work

We introduced an approach to reuse-oriented analytical processes modelling with Semantic Web technologies, which captures the different steps of analysis as multidimensional structures transformations. The first use case concerns BI reporting applications, for which we exemplified our model by triplifying a repository of reports snippets. The graph data resulting from this initial experiment can be queried for basic usage statistics or content similarity measures with simple SPARQL aggregates or iSPARQL statements.

Areas of research that we expect will require further investigation include the formal definition of matching criteria between layers of analytical processes, and its implementation as a specific similarity strategy for analytical layers' RDF resources in iSPARQL; and mechanisms to capture or infer the provenance of the data surfacing into end user visualizations [START_REF] Reisser | Utilizing Semantic Web Technologies for Efficient Data Lineage and Impact Analyses in Data Warehouse Environments[END_REF]. Finally, we will check the model's genericity by using crawlers for BI applications besides reporting tools, such as dashboarding or exploration ones. This will enable representing analytical processes composed of transformations and data derived from different environments, for instance statistical data published with respect to RDF Data Cube vocabulary and external to the data warehouses.

http://publishing-statistical-data.googlecode.com/svn/trunk/specs/src/main/html/cube.html

The RDFS classes and properties of our extension use the mda: prefix, for MultiDimensional Analysis. The qb: prefix refers to Data Cube vocabulary.

[START_REF] Kiefer | The Fundamentals of iSPARQL: A Virtual Triple Approach for Similarity-Based Semantic Web Tasks[END_REF] http://www.ai.sri.com/daml/services/owl-s/1.2/overview/