WIsdom-AwaRE Computing
 about it 
The aim is both to allow developers (typically domain experts, who are not IT experts) to go beyond their own development capabilities and to speed up the overall development process, joining the benefits of both simplification and reuse.

In the state of art works, people have tried to solve the problem of reusing existing composition knowledge by explicitly tagging or adding semantic description to the composition fragments, which help to match them and apply them in a similar context based upon their semantic similarity.In WIRE, we take a different stance; Unlike other approaches in literature, which typically focus on structural and semantic similarities, we specifically focus on the elicitation of composition knowledge that derives from the expertise of people and that is expressed in the compositions they develop. If, for instance, two components have been used together successfully multiple times, very likely their joint use is both syntactically and semantically meaningful. There is no need to further model complex ontologies or composition rules. In WIRE, we specifically focus on the elicitation and collection of crowd wisdom, i.e., composition knowledge that is derived from the ways other people have solved similar composition problems in the past and that has a significant support in terms of number of times it has been adopted. This means that in order to create knowledge for WIRE, we do not need any expert developer or domain specialist that writes and maintains explicit composition rules or logics; knowledge is instead harvested from how people compose their very own applications, without requiring them to provide additional meta-data or descriptions (which typically doesn't work in practice).

In doing so the challenges we tackle are mainly:

  • Identifying the types of advice that can be given and the conditions under which they can be given: depending on the complexity and expressive power of the composition language, there can be a huge variety of possible advices. Understanding which of them are useful is crucial to limit complexity.
    Discovering computational knowledge: how do we harvest development knowledge from the crowd, that is, from a set of existing compositions? Knowledge may come in a variety of different forms: component or service compatibilities, data mappings, co-occurrence of components, design patterns, evolution operations, and so on.
  • Representing and storing knowledge: once identified, how do we represent and store knowledge in a way that allows easy querying and retrieval for reuse?
  • Searching and retrieving knowledge: given a partial program specification under development, how do we enable the querying of the knowledge space and the identification of the most suitable and useful advice to provide to the developer, in order to really assist him?
  • Reusing knowledge: given an advice for development, how do we (re)use the identified knowledge in the program under development? We need to be able to "weave" it into the partial specification in a way that is correct and executable, so as to provide concrete benefits to the developer.

The high-level architecture of the assisted development environment with which we aim at supporting wisdom-aware development according to the model described in the previous section, is visualized in Figure 1.

Figure 1. Functional architecture of WIRE
People involved:

Soudip Roy Chowdhury, Carlos Rodríguez, Florian Daniel, and Fabio Casati


  • Omelette Project - EU FP7- for demonstrating and verifying the development recommendation algorithms in domain specific, telco-mashup development scenario.
  • HCI group of UNITN - for validating the usability of development recommendation algorithm in End-user development perspective.
To know more about it
Take a look at the Baya demo
where we are
University of Trento
Via Sommarive 5,
38123 Povo,
Trento, Italy
Legal info
®2012 Lifeparticipation
University of Trento
Trento, Italy