From AMI@Work Communities Wiki

Contents 1 Editor’s Corner 2 Coordinator's Message 3 Collaborative Environment Reference Architecture 3.1 Introduction 3.2 Semantic Infrastructure Layer 3.3 Basic Collaborative Service Layer 3.4 Orchestration Layer: Composite Collaborative Services 3.5 Collaborative Technologies and Tools Layer 3.6 Interface Layer 4 The Evaluation of a Collaborative Environment Reference Architecture 4.1 Introduction 4.2 CERA Evaluation Methodology 4.2.1 Evaluation Participants 4.2.2 Evaluation Results 4.2.3 Evaluation Analysis 4.3 Conclusions 5 Standardisation in the area of CWE: Towards Interoperable Collaboration Services 5.1 Designing the Collaborative Web 5.1.1 User Centred CWE 5.1.2 Interoperable Collaboration Services 5.1.3 Towards the Standardisation for Interoperable Collaboration Services 5.1.4 Motivation for BCS 5.1.5 BCS scenario with Mash-up and Display components 5.2 BCS Specification 5.2.1 List of Basic Collaborative Services 5.2.2 Recommended use of the SIOC properties 5.2.3 Examples of BCS Invocation 5.3 Exchange of Presence and Availability Information 5.3.1 Introduction 5.3.2 Aggregating Presence Information 5.3.3 Presence concepts extensibility 6 Topic Maps for CWE (TM4CWE) 6.1 Introduction 6.2 Requirements and Motivation 6.3 Functionality 6.4 Application Scenario 6.5 Benefits 6.6 Integration 6.7 Conclusion 7 Shaping the Future of ENoLL and AMI Communities 7.1 Introductory message 7.2 Action Plan for 2009 7.3 AMI Communities Family Metaporphosis 7.4 ENoLL and AMI communities Next Events 8 Latest News 8.1 Establish Latin America/EU RTD cooperation in NEM area with SALA+ 9 Up-coming Events 9.1 ICE 2009, Noordwjik, The Netherlands, June 22-24 2009 9.2 FIRE and LIVINGLABS 2009, Luleå, Sweden, July 1-2 2009 9.2.1 Background 9.2.2 FIRE - Future Internet Research 9.2.3 Living Labs 9.3 ECSCW'09, Vienna, Austria, September 7-11 2009 9.4 CSCW 2010, Savannah, Georgia, USA, February 6-10 2010

printable version of Newsletter No 9 (PDF)

[edit] Editor’s Corner

Here is the ECOSPACE Newsletter double issue n°9 and N°10 which is mainly devoted to the Collaborative Environment Reference Architecture (CERA) and the standardisation approach conducted by ECOSPACE through the design of Basic Collaborative Services (BCS) which constitutes the first layer of CERA.

Inside this double issue, you will find articles describing CERA and its evaluation, as well as the latest version of the BCS specification and exchange of presence information and finally a specific tool, named TM4CWE, which is based on the use of Topic Maps and offers an editor and a graphic viewer allowing to browse CWE information provided by different Shared Workspace tools. Last but not least, there is an article about ENoLL and AMI communities' metamorphosis.

In the special issue n°6, a specific demonstration on shared workspaces interworking was presented in order to illustrate how Basic Collaborative Services (BCS) with the SIOC ontology have enabled a transparent access and use of any external shared folders whatever Shared Workspace tool is used (i.e. BSCW, Netweaver, Sharepoint, BC). The original meaning of SIOC is "Semantically-Interlinked Online Communities" where CWEs are considered as specific online communities. ECOSPACE is extending SIOC with the specific CWE needs, hence this extension is named "SIOC4CWE".

Nowadays, BCS could also be used for mashing up data for example from a shared workspace tool where photos have been uploaded and then display those photos into a carousel or other viewing forms such as the ones proposed in PopFly. Another example illustrated in this double issue consists to use BCS for sharing presence information among different collaboration tools.

For the first time in this newsletter, we provide some source code in the BCS Specification and Presence articles in order to address developers hoping they will see a good value proposal in using BCS in their own development of collaboration tools or web applications.

This is considered as a major achievement as it means that everyone will transparently get access to shared objects from his most favourite collaboration tools or collaborative environments whatever are the other collaboration tools used by partners involved in the same project. It will clearly enable users to compose their own collaborative environment. It also opens the door to the development of specific collaboration services without to have to re-invent the wheel each time. All those collaboration services could be shared within the CWE community among developers and users for the benefit of all. The only condition is to have collaboration tool providers adopting BCS and implicitly its related SIOC4CWE. It further explains why the ECOSPACE project is contributing to the OASIS ICOM Technical Committee (TC) whose main goal is to standardise an Integrated Collaboration Object Model (ICOM) and enable Interoperable Collaboration Services. OASIS is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society.

Let's hope the OASIS ICOM TC will be successful enough that developers and users will both adopt a common model enabling Interoperable Collaboration Services.

As usually, this issue is closing with the announcement of up-coming CWE related events such as ICE'2009. Don't miss this unique opportunity to see the latest developments in the areas of Collaborative Environments and Living Labs! The next double issue will include articles reporting about the various workshops at ICE'2009.

We also invite you to regularly have a look at the ECOSPACE Web Pages for the latest developments where you will find available 4 ECOSPACE videos.

See you all at ICE'2009!

[edit] Coordinator's Message

This newsletter is focussing on the ECOSPACE achievements in developing a reference architecture for collaborative working environments. Thus the following articles provide both an overview on the architecture as well as its implementation and application examples. Throughout the ECOSPACE project this architecture as well as the basic services and the protocols for the exchange of information between different collaboration services has been used to develop a number of interoperability scenarios and demonstrations. With the publishing of our basic collaborative services we aim at the dissemination of our approach and we hope that they will be adopted by many other developers.

However, we believe that the opening of CWE services by standardised services is not only beneficial for developers, but also for end users. This is nicely demonstrated by the combination of the basic collaborative services provided by BSCW with the end user mash-up environment Popfly. This combination enables for the first time the rapid development of new collaboration services by the combination of existing services as well as combination of collaboration services with visualisation and user interface elements.

I hope that you will enjoy reading this newsletter and I would appreciate if you would consider the proposed architecture and services as a resource for your own developments. Please feel free to use the code examples provided below for your own developments. If you have further questions, comments or experiences, please feel free to contact me or the respective authors. For a further exchange of our ideas I invite you to participate in our interoperability workshop at the ECSCW conference.

[edit] Collaborative Environment Reference Architecture

with contribution from Kashif Iqbal

[edit] Introduction

This article presents the Collaborative Environment Reference Architecture (CERA) developed within the ECOSPACE project as being a CWE reference architecture that all CWE Integrated Projects were originally due to work on (CoSpaces, ECOSPACE, Laboranova and C@R). Moreover for each layer, the specific ECOSPACE implementation is introduced with the models and technologies which have been adopted in the project as an example of CERA instantiation.

CERA is a layered architecture which consists of the following six layers:

1. Semantic Infrastructure Layer: Represents models, metadata, and rules to be used by all the other layers in order to provide semantics to the entire solution. The core semantic models are the user model, the context model, the content model, and the process model.
2. Basic Collaborative Service Layer: Represents all available Basic Collaborative Services (BCS), which represent collaborative tasks that cannot be divided into smaller parts. The actual composition can be done dynamically at run-time through the interpretation of a schema or statically at compile-time. In the former, a language is necessary to determine the composition of different BCS.
3. Orchestration Layer: Represents all available Composite Collaborative Services (CoCoS), which are sets of BCSs, executed in a defined order to provide value-added collaborative functionality.
4. Collaborative Technologies and Tools Layer: Represents the tools and collaborative technologies that facilitate collaboration.
5. Interface Layer: Represents the user-interface or front-end that is used by eProfessionals to interact with one or more CWE applications.

The Basic Collaborative Service (BCS) layer is the foundational layer that needs to be adopted in order to benefit from CERA, as this guarantees a certain level of interoperability among collaboration tools. The remaining layers are optional, but the more layers that are adopted, the greater the benefit, although complexity is also increased and flexibility is reduced.

[edit] Semantic Infrastructure Layer

Based on the Generic Collaboration Model (see Figure 1), we have identified four core CWE models that provide formal descriptions, reference models and metadata for the CWE domain.

These are the following:

• the User Model, which represents eProfessionals’ characteristics,
• the Process (or Service) Model, which represents a CWE’s functionality,
• the Context Model, which represents features of the dynamic eProfessional environment (e.g. temporal, spatial), and
• the Content Model, which represents metadata about the information stored and processed in a collaborative space.

The combination of the four models forms the CERA semantic infrastructure that permeates all other components of the reference architecture. Each model enables a certain type of functionalities. For example, the Context Model supports contextualisation mechanisms whereas the Content Model is used for annotating informational resources to facilitate discovery and data portability. Although CERA identifies the need for these four models to facilitate CWE interoperability, how these models are implemented, either conceptually or technically, are not specified. In this way, CERA remains technology independent and the decision of which approach to use is left to the CWE architects and developers.

However, in order to illustrate how the CERA semantic models could be instantiated, in the following sections we present how these conceptual reference models have been implemented in the ECOSPACE architecture. As the ECOSPACE architecture is an instantiation of CERA these models are examples (or instances) of how the CERA models would look in a real implementation. The ECOSPACE models were selected based on the requirements of the project and the experience and knowledge of the project partners.

Although all semantic models are described below, we focus on the specification of the ECOSPACE Content Model, as data portability and semantic interoperability between existing CWE platforms are two of the main requirements for the ECOSPACE project. Additionally, content plays an integral role in many of the tools developed as part of this project. Therefore, we briefly outline our approaches to the User, Context, and Process model in the ECOSPACE architecture, and describe in more detail the implementation of the Content model.

The ECOSPACE User Model

In the ECOSPACE architecture, FOAF with Collaborative Vocabulary (CoVoC) extensions is used as the basic eProfessional user model. CoVoC is a vocabulary developed within the project, which extends generic relationship–vocabularies, such as REL-X and RELATIONSHIP . It is used to identify the most prevalent types of acquaintances and social interactions in the collaboration of eProfessionals and, more generally, knowledge workers. The ECOSPACE Process Model

For the ECOSPACE architecture Process model, a semantic, web-service ontology is used, namely the SA-WSDL specification, for adding a semantic layer on top of the Web Service standards stack. In this way a uniform semantic description of CWE functionalities that are available as Web Services may be provided. More details can be found in section Error! Reference source not found..

The ECOSPACE Context Model

The Context Model represents the characteristics that are related to the environment in which the user is placed and may affect the way a collaborative activity of any type is executed. An internal context model has been developed within the ECOSPACE project [9]. Moreover, we are still examining preliminary versions of the Context Models developed elsewhere to try and determine whether and how they could be used in combination with and to enhance the ECOSPACE Context Model, e.g. the results from the InContext project

The ECOSPACE Content Model

From a content perspective, all CWE applications and workspaces are semantic islands, as they use different vocabulary to describe similar information. However, it has been observed that, despite their differences, all these applications explicitly or implicitly model common elements. The objective of the Content Model is to represent these common elements, their underlying structure, and their semantics.

The Content Model plays the role of a mediator or common language between different applications/tools. The goal and main functionality expected from the usage of this model is to semantically interlink CWE applications, thus enabling collaboration and information sharing across distributed and heterogeneous applications/tools.

In ECOSPACE, we use the Semantically Interlinked Online Community (SIOC) ontology as a Content Model, arguing that Shared Workspaces can be perceived as a special type of online communities. SIOC is a framework that aims at connecting online community sites by using semantic web technologies and is currently a W3C submission. The core of SIOC is an RDF vocabulary that contains concepts necessary to categorise information contained in online community sites. There are currently tools available for generating and using SIOC-annotated information. In Figure 2 the main SIOC concepts and properties are presented.

Interesting CWE functionalities become possible with the adoption of a common Content model, e.g. SIOC in our case:

• Users are semantically connected with their multiple user accounts on different sites.
• Items from different CWEs that share the same topic can be semantically interlinked with each other.
• Distributed conversation and blogs are facilitated.
• A virtual container of all sharable objects can become available to a CWE user, irrespective of the CWE platform they use.
• Calendar events can be shared across different CWEs, so that users working on different CWEs are aware of all collaborative events that they are interested in.
• Relevant CWEs could be organised into unified and integrated collaboration communities.

A recommendation of how SIOC is applied to the CWE domain is presented in a following article.

[edit] Basic Collaborative Service Layer

The Basic Service Layer consists of the set of Basic Collaborative Services (BCS), common to all CWEs. It is the foundational layer that needs to be adopted in order to benefit from CERA, as its adoption guarantees a certain level of interoperability. A BCS is defined as a service that supports a simple collaborative task that cannot be further divided into smaller tasks. This atomicity qualifies the BCS as the smallest building block of CERA. Another foundational BCS characteristic is that the BCS distil the base common functionality of any CWE, thus they are instantiated in different forms in each platform.

The services that exist in this layer:

• are implemented by some basic CWE technologies (e.g. e-mail, blogs),
• become available to other application that may combine several basic CWE technologies (e.g. MS Outlook, BSCW video-conferencing).

Each BCS can support several operations of different types but with the same purpose of functionality. A complete list of the originally proposed BCS for CERA is enumerated in Table 1. However, this list has been updated, as described in the 'Basic Collaborative Services' article in this newsletter.

Nbr	BCS name	Nbr	BCS name	Nbr	BCS name	Nbr	BCS name	Nbr	BCS name	Nbr	BCS name
1	Add	2	Accept	3	Get	4	Delete	5	Edit	6	Decline
7	Start	8	End	9	Recover	10	Execute	11	Send	12	Authenticate
13	Notify	14	Check	15	Replace	16	Reply	17	Invite	18	Uninvite
19	Subscribe	20	Unsubscribe	21	Search	22	Copy	23	Lock	24	Unlock
25	Export	26	Store	27	Enter	28	Leave	29	Share	30	Assign
31	Create	32		33		34		35		36

Table 1 - List of BCS Operations

These services have been documented using a template. The example of this template, for the ‘Create’ service is presented below.

 ResourceID Create (platform, technology, operationType, set of pair-value)

The aim of the Create BCS is to support the creation of any type of resource within CWE systems, irrespective of its complexity. This means that the Create BCS can be used for the creation of new blogs, new documents, users, or events. Within CWE systems there is always the need to create resources. However, instead of having a ‘Create’ per each type of resource and each particular nuance of a particular procedure call, careful refactoring was carried out to distil the basic functionality of the Create BCS. The concrete execution of the particular semantics of the Create BCS is determined at runtime according to the parameterisation of the service (what are the inputs provided).

The parameters of the service are as follows: platform indicates the CWE platform, e.g. BSCW; technology indicates the specific CWE technology, e.g. Blog; operationType indicates the operation within that technology, e.g. createBlog, createBlogLogin; and the set of pair-values indicate any other parameters necessary to the function.

Once a resource is created, the service returns the identity of the resource which can later be used to retrieve the resource from the system. The service handles the differences in creating resources between different systems. Within the ECOSPACE project there was a decision to implement the BCS layer of CERA using Web Services technologies. Moreover, as we wanted to add a semantic layer on top of the service descriptions, we used the SA-WSDL specification. The main idea behind SOA is to wrap systems’ functionalities and make them available as independent services with well-defined interfaces that can be called to perform their tasks in a standard way.

Although SOA is not tied to a specific technology, currently the Web Services technology stack (i.e. SOAP, WSDL and UDDI) is commonly used to implement a SOA. The Web Service Description Language (WSDL) specifies an XML format that allows service interfaces to be described along with the details of their bindings to specific protocols. In ECOSPACE, we have chosen WSDL to describe Basic Collaborative Services (BCS), but because WSDL follows the syntactic approach, we need an additional mechanism to extend WSDL with semantic information to automate or semi-automate certain tasks during or before service invocation. These tasks generally include service discovery, service composition, negotiation, filtering of discovered services, service selection based on some criteria, and service invocation.

Semantic Annotations for WSDL and XML Schema (SA-WSDL) defines how to add semantic annotations to various parts of a WSDL document such as input and output message structures, interfaces and operations. For example, SA-WSDL specification defines a way to annotate WSDL interfaces and operations with categorisation information which can be used to discover a Basic Collaborative Service (BCS) stored in the service registry. The annotations on XML-schema types can also be used to discover and compose BCS. The benefits of using SA-WSDL are that SA-WSDL is agnostic to a specific ontology or formalism to annotate the WSDL for the BCS. SA-WSDL provides the flexibility to extend the basic annotation framework according to the needs of various use-cases e.g. modelling of pre-conditions and post-conditions for the BCS.

[edit] Orchestration Layer: Composite Collaborative Services

The Orchestration layer of CERA is built on top of, and is closely linked to, the BCS layer. In the Orchestration layer BCSs are orchestrated together to form Composite Collaborative Services (CoCoS) in a process usually referred to as Service Orchestration. A CoCoS can be defined as a composed set of BCSs that is executed in a predefined sequence to provide more complex, collaborative functionality than the BCS can offer.

Compared to the BCS, in addition to the well-defined service interface (i.e. WSDL in the case of Web Service technologies), CoCoS are associated with a control flow that defines their execution logic and a dataflow that captures the data needed for the process. Moreover CoCoS interactions may span multiple applications and/or organisations, and result in a long-lived, transactional, multi-step process model.

A CoCoS can be specified at a high level by an eProfessional to model a complex collaboration process (e.g. setting up a meeting) as a set of composed functions implemented by a set of individual BCSs. The concrete implementation of the BCS’s functional logic is the responsibility of the CWE developers. At an abstract level, a collaborative process template defines the publicly visible behaviour of some or all of the BCSs involved in the process. At a concrete level, all the necessary details need to be included to make a process template executable e.g. business logic of the process, concrete data and service bindings etc. Additional tasks (e.g. Service discovery) are required to create executable CoCoS from the CoCoS template.

From the implementation perspective within the project and based on the fact that in ECOSPACE, WSDL and SAWSDL are used to describe the BCS and CoCoS, we have chosen a WSDL-compliant orchestration model (i.e. WS-BPEL) for the CoCoS. The role of the WS-BPEL in ECOSPACE has been to enable an eProfessional to describe his collaborative process at both abstract and concrete levels. WS-BPEL is designed to fit naturally with the Web Services stack (i.e. implementation of the BCS layer).

Although, WS-BPEL allows describing abstract as well as concrete processes, an additional mechanism is required to generate an executable process out of an abstract process definition. This mechanism is usually known as Service Orchestration. Service Orchestration may be defined at design time (i.e. static orchestration) or at run time (i.e. dynamic orchestration). In the ECOSPACE project, a hybrid approach is taken to perform Service Orchestration i.e. predefined abstract CoCoS templates are created at design time. The predefined CoCoS templates describe the overall process flow, but do not necessarily bind each process step to a specific basic service invocation. Therefore, we need some additional steps to create an executable CoCoS from an abstract CoCoS template. These steps are highlighted in Figure 3.

The component responsible for Orchestration is known as Orchestration or Composition Engine. The first step in the orchestration process is to process the particular CoCoS template that can fulfil an eProfessional’s collaboration task. Once it is processed, the Composition Engine sends it to an analyzer which analyzes the process template to identify which services are required to execute the process. A service discovery request is made to the matchmaking or discovery engine to discover all the required services to execute the process. The matchmaking or discovery engine implements the matchmaking algorithm based on the service’s pre and post-conditions. Once the list of services is identified, it is then returned to the composition engine, which gives this information to a process-instantiater. The process-instantiater uses XSLT to transform the abstract process definition into an executable process definition using WS-BPEL.

[edit] Collaborative Technologies and Tools Layer

At this layer, tools and technologies that facilitate collaboration can be found. Technologies refer to general application domains with a specific functionality, whereas tools refer to specific applications, which may exploit the functionality of one or more technologies. These tools both consume and make available basic and composite collaborative services, by invoking CoCoS and BCS in lower layers to provide the required functionality. Tools may be designed as either stand-alone applications or components in CWE platforms with broader coverage and scope.

Within the ECOSPACE project, and through analyzing the various functionalities of existing CWE platforms, we identified thirty-four different CWE technologies, which are enumerated in Table 2. More information and documentation for these different tools can be found in the project wiki page .

Nbr	CWE Technology	Nbr	CWE Technology	Nbr	CWE Technology	Nbr	CWE Technology	Nbr	CWE Technology	Nbr	CWE Technology
1	Application Sharing	2	Audio Conference	3	Blog	4	Calendar	5	Chat	6	Context Management
7	Content Management	8	Control Version	9	Database	10	Distribution List	11	E-mail	12	Forum
13	Group Management	14	Instant Messaging	15	News	16	Notification/Alert	17	Phone	18	Polls/Surveys
19	Presence/Availability	20	Resource Management	21	Rights Management	22	Semantic Annotation	23	Shared Workspaces	24	Statistical
25	Collaborative Editing	26	Syndication	27	Task Management	28	Tracking/Localisation	29	User Management	30	Video Conference
31	Voting	32	Whiteboard	33	Wiki	34	Workflow	35		36

Table 2: CWE Technologies

[edit] Interface Layer

Information and technology innovation is becoming more complex and the challenge is achieving a clear design that unburdens the user’s cognitive load making the most efficient use of their time. This is clearly evident with the plethora of tools and possible configurations of a CWE, thus a key user requirement of the interface layer is to provide a personalised environment for every e-professional based on their preferences, work patterns and their current shared work context.

In CERA, the intelligent desktop has been proposed as a CWE interface framework. It is imbued with semantic intelligence that enables the dynamic reconfiguration at run-time, thus adapting to both the work context as it changes and the work pattern of the user. The interface dynamicity may be automated or it may require the approval of the user, depending on the user’s preferences. The conceptual architecture of the CERA intelligent desktop is captured in the schematic diagram of Figure 5. The desktop maintains the profile of the user and builds a history of their behaviours when using CWE. This information is complemented by the monitoring of the current work context that is assessed against the Collaborative Work Patterns defined by the appropriate ontology. The continuous analysis of the four data sources provides the means for the intelligent desktop to assess the best tools and services to support the work undertaken by the user. The result of the analysis is a priority list that the intelligent desktop uses as input for contextual cueing that affects the visual management of the various tools/services based on focus, e.g. what is the immediate task being done, and context, e.g. what is the current CWE, who is part of it, what is the user’s role.

The visualisation based on focus and context takes a similar approach to the fisheye concept of website navigation, where the degree of interest has an impact on the focal display of information/data. With the CERA intelligent desktop, the concept is applied to the tools/services to be used by CERA the current session of the CWE. The fundamental abstraction of the CERA intelligent desktop is the use of a window through which a user may interact to receive the output of the particular service/tool and provide the necessary input.

As such, the area of the desktop can be divided into different areas of interest, which by default are two:

• Primary: This corresponds to the main area where the focus of the user resides and normally corresponds to the window/display of the main tool/service currently being used.
• Secondary: This corresponds to an area of the desktop that does not reside in the focus of the user, but contains the information concerning tools/service of potential relevance to the user.

The actual visual management of the areas depends on the visualisation policy associated to the CERA intelligent desktop, which may be configured by the user offline. The following two examples demonstrate different approaches to the visualisation policy:

• One of the simplest visualisation policies consists of attributing the Primary focal area to the window or display area of the tool/service that the user is currently interacting with. This is supported by a sidebar (Secondary focal area) that contains a tree structure of potential candidates for the primary focal area.

• A more sophisticated approach is to consider the use of two graphical layers, one for the Primary and another for the Secondary, with the former overlapping the latter. The Primary area of interest may correspond to either a single tool/service or a small set of tools/services of relatively similar importance to the user. The Secondary area of interest has large thumbnails of the different tools/services of potential relevance to the user. To distinguish between the levels of relevance, the contextual cues are used to modify the alpha channel of the thumbnails.

• The granularity of areas of interest is configurable, so more areas may be considered, but these may conceptually be regarded as refinements of the Secondary area of interest. For example, one may consider an area of interest as one with the most recently used tools/services and another with the services/tools of potential relevance.

[edit] The Evaluation of a Collaborative Environment Reference Architecture

Presented at Collaborative Web Environment Workshop in 15th International conference on Concurrent Enterprising (ICE 2009), Leiden, The Netherlands, 2009

D.Lee, M.Fradinho, V. Peristeras, and K.Iqbal

[edit] Introduction

Collaborative Working Environments (CWEs) support collaboration between eProfessionals working in a common organisation or on a common project. However, there remain significant challenges for eProfessional attempting to collaborate across teams, organizations and communities. The root of the challenge is the lack of interoperability between different CWE platforms. Although they share major functional overlap, the content is usually expressed in a heterogeneous format that cannot be shared with and understood by other systems. Consequently, eProfessionals adopt the most common denominator for collaboration, which corresponds to file transfer and email, thus not benefiting from the features of the individual CWEs that would otherwise increase productivity.

We believe that establishing a reference architecture is an important step towards achieving functional interoperability between different solutions. A reference architecture (Reed 2002) captures architectural best practices within a particular problem domain, thereby enabling more efficient development whilst promoting both reusability and interoperability. However, it is important to note that a reference architecture is a blueprint for architecture, in that particular software architectures are instantiated based on the reference architecture.

Such a reference architecture for CWEs has been developed within the scope of the Ecospace project (Peristeras et al, 2009). In this paper we adapt an existing evaluation methodology (Oliveira and Pereira 2007) to assess the applicability and reusability of the proposed reference architecture – Collaborative Environment Reference Architecture (CERA). The evaluation process, along with a detailed documentation and analysis of the results are presented here, demonstrating the acceptance of CERA by real-world system-architects, and its potential for being used in the design of collaborative systems.

Further information on CERA can be found in (Peristeras et al, 2009).

[edit] CERA Evaluation Methodology

In order to ascertain the applicability and usability of CERA to facilitate the development of real-world CWE-systems, an extensive evaluation was carried out involving twenty-five CSCW experts from different problem domains (e.g. e-learning, groupware, project management). The chosen evaluation methodology is based on an existing evaluation methodology (Oliveira and Pereira 2007), which is summarized in Table 1.

Table 1 – CERA Evaluation Methodology

Step	Designation	Action
1	Explanation of Evaluation Process	The participant is welcomed and the evaluation process is explained to him/her.
2	Provision of Architecture Documentation	A presentation containing an overview of CERA will be presented to the participant.
3	Identification of Participant’s Profile	The participant completes a questionnaire outlining his/her experience, roles, and general opinions regarding architecture models and design. From this questionnaire, a participant profile is built.
4	Motivation of Architecture	A presentation is made to the participant outlining the motivation and overview of CERA, including the CERA architectural layers and an in-depth look at each layer at a reference and implementation level.
5	Scenario Identification	A range of scenarios for CERA are then presented to the participant.
6	Scenario Revision	Brainstorming is then carried out to verify the existing scenarios and to possibly develop new scenarios.
7	Architecture Discussion	A general discussion regarding CERA is held, so that the participant may clarify any points or tease out ideas concerning the design choices made for CERA.
8	Assessment	The participant completes a questionnaire relating to CWE systems and using CERA as a reference architecture for building CWE systems.
9	Final Assessment	The answers to the questionnaires mentioned in step 8 are analysed. The correlated results of each session are presented in the following sections.

As discussed in the previous section, CERA adopts a layered architectural style with the Semantic Infrastructure Layer and the BCS Layer as the foundational layers. Whilst the foundational layers are the pre-requisite that must be implemented for the adoption of CERA, the architecture designer may choose which of the upper layers to implement, based on their specific requirements. Therefore, it was decided that the evaluation should focus mainly on the foundational layers, while the evaluation of the upper layers was more conceptual and not focused on particular instantiations.

[edit] Evaluation Participants

The execution of the CERA Evaluation Methodology was carried out with two distinctive groups:

• Consortium: this phase consisted of CWE domain experts from the Ecospace project consortium. The evaluation was carried out at selected project meetings. The feedback contributed to the development process, by validating and refining CERA. Of the total 25 experts, a total 14 participants were part of the consortium.
• Community: this phase involved participants from the general CWE community, beyond the consortium, who are recognised as experts in the collaborative solutions albeit from different application domains. They are working with related tools and technologies and are facing similar research challenges. This evaluation was carried out on an individual basis (6 participants) and in a workshop setting (5 participants).

All participants were chosen based on their interests and CWE related experience. They were contacted on an individual basis through emails and personal invitations. Although most participants demonstrated some initial concern due to time requisites (the evaluation process takes on average 2 hours), once engaged, time was no longer an issue with some participants sparing more than 4 hours.

The purpose of the questionnaire in step 3 was to determine the background and predisposition of a participant towards reusability and interoperability. This would provide insight into the analysis of their responses and contributions to both the prioritization of scenarios and the brainstorming session. The importance of this characterization is clearly illustrated in the participants’ disposition towards using third party components. However, when discussing the actual reuse of components from third parties, there is little evidence that this approach is actually adopted. Most of the reasons were mostly rooted in human factors, such as the not-invented-here syndrome and lack of trust in the efficiency of a component developed by another party other than the participant.

[edit] Evaluation Results

The evaluation results are captured in Table 2, which corresponds to the statements captured in the questionnaire corresponding to step 8 of the evaluation methodology. Each participant was requested to provide their input concerning how they agreed with the 13 statements. The final three columns represent the percentage of that group that agreed with the statement.

Table 2 – Evaluation Results

No.	Description (Evaluation Statement)	Consortium %	Community-individual %	Community-workshop %
1	The field of CWE, in terms of system development, experiences a wide proliferation of solutions.	79	100	40
2	There is a lot of overlap in current CWE systems with regards to supported functionality.	79	100	40
3	Interoperability is a challenge in terms of architecture or component interfaces across different CWE environment systems.	79	100	100
4	Although the development process of a CWE system is a costly venture, significant resource expenditure continues to occur for the creation of building blocks that are similar across most CWE solutions.	100	100	100
5	It would be highly desirable to have the option of building or reusing CWE components with well defined functionality originated from different sources.	86	100	100
6	Having a reference architecture would benefit the development of CWE systems.	100	100	100
7	The CERA semantic models, i.e. the content model, the user model and the process model, are essential for a CWE reference architecture.	86	100	100
8	The following layers are the key building blocks for CERA: Basic Collaborative Services, Composite Collaborative Services and Semantic Infrastructure.	50	100	100
9	The layer with basic services used in most CWE systems should correspond to the foundational layer of any CWE system.	100	100	100
10	The original set of presented scenarios is relevant for the reference architecture to support.	100	100	80
11	The original set of scenarios is supported by the presented CWE reference architecture.	85	100	80
12	Would consider adopting CERA in CWE related projects.	73	100	100
13	Would consider modifying their existing system to follow some, if not all, of the guidelines proposed by CERA.	85	66.67	80

[edit] Evaluation Analysis

The majority of the participants shared the opinion that architecture plays a vital role and is essential for the successful outcome of the project. Their opinions reflected their interest in the evaluation of reference architecture (i.e. CERA) and their agreement that a reference architecture would benefit the development of CWE systems.

It is interesting to note that only 40% of the community-workshop group believed that there is a wide proliferation of solutions in the field of CWE, compared to a strong majority in the other evaluation groups. This may indicate that the reach of many CWE systems remain within the CWE-expert domain (statement 1). On a similar issue, it is the CWE-experts (consortium group) who had the lowest agreement with the statement that there is a lot of overlap in current CWE systems with regards to supported functionality (statement 2). This may be attributable to their deep understanding of different systems in the domain and the exact functions they perform. However, it is important to note that some of the experts were developers of commercial CWE systems (e.g. Business Communicator and NetWeaver) and promote their solutions based on functional diversity.

Both community groups consisted of members from a research institute specialising Semantic Web technologies, which justifies their understanding of the importance of semantic models in CERA. This is reflected in statement 7 as both community groups agreed that the CERA semantic models are essential for a CWE reference architecture.

The majority of the participants agreed that the presented scenarios are relevant for the reference architecture to support (statement 11). During the evaluation sessions some new scenarios were proposed, but after detailed discussions participants agreed that they are either already covered by CERA or are beyond the scope of the reference architecture and too tightly coupled to a particular application.

Ultimately, when participants were asked whether or not they would consider adopting CERA in CWE-related projects, they responded positively (statement 12). 100% of the community-individual group participants agreed that they would consider adopting CERA, while 73% of the consortium group and 100% of the community-workshop group answered in the affirmative. This is one of the key outcomes of the evaluation exercise, as it endorses the rationale of creating a reference architecture for the CWE domain. The lower result from the consortium group may be considered unexpected, however whilst the consortium participants have experienced the actual implementation of CERA in their existing CWE systems, the community participants responded from a more conceptual perspective. Within the consortium, CERA has been adopted by four existing commercial CWE systems and multiple collaborative tools (e.g. instant messaging, videoconferencing, document sharing, etc.).

As well as adopting CERA in new CWE-related projects, statement 13 shows the percentage of each participation group that would consider modifying their existing system to follow some, if not all, of the guidelines proposed by CERA. This result demonstrates the further adoption possibilities for CERA into existing legacy systems, as well as into new systems.

[edit] Conclusions

In this article, we have outlined the preparation and process involved in using the nine-step evaluation methodology to evaluate a reference architecture for the CWE domain. We have shown that applying such a methodology to a reference architecture enables:

• a demonstration of the reference architecture to participants first-hand,
• direct discussion about the reference architecture with participants,
• the gathering of feedback about the reference architecture from participants,
• the correlation and analysis of evaluation results at a later date.

As a next step, we want to further improve the methodology based on the feedback we have received from these evaluation sessions. The refined methodology will then be run within the greater CWE community. In particular we want to further improve the scenario identification and scenario revision steps, as participants were sometimes confused with how the scenarios were presented. Therefore, we aim to present the scenarios with more details in order to make them more comprehensible. Another step would be to update the list of scenarios we currently have with the CWE experts in order to make sure that we have the complete list of scenarios for the CWE reference architecture (i.e. CERA).

References

• P. R. Reed, "Reference Architecture: The Best of Best Practices," in IBM DeveloperWorks, 2002.
• V. Peristeras, M. Fradinho, D. Lee, W. Prinz, R. Ruland, K. Iqbal, and S. Decker, "CERA: A Collaborative Environment Reference Architecture for Interoperable CWE Systems," Service Oriented Computing and Applications (SOCA) - Special Issue on Collaboration Services: Methodologies, Architectures, Technologies and Protocols, 2009
• M. Oliveira and J. Pereira, “Extensible Virtual Environment Systems Using System of Systems Engineering Approach”, IEEE Proc. ICAT 2007, Esbjerg, November 2007.

[edit] Standardisation in the area of CWE: Towards Interoperable Collaboration Services

[edit] Designing the Collaborative Web

Right from the beginning, the ECOSPACE vision was introduced as being the integration of semantic and social web (Web 2.0) through a user-centric interoperability approach towards the collaborative web (web 3.0).

In order to achieve this vision, the ECOSPACE project has developed, based on emerging collaboration trends and scenarios, various elements such as a Collaborative Distance Framework (CDF), a Collaborative Environment Reference Architecture (CERA), Basic Collaborative Services (BCS), Composite Collaborative Services (CoCoS), extended SIOC for CWE ontology (SIOC4CWE), Distributed Document Context (D2C), CWE widgets and CWE portal or dashboard.

Further to these above elements, a large set of collaboration tools were developed and existing ones were enhanced for constituting an interoperable collaborative environment. Some of the used concepts have already been contributed to standardisation initiatives (W3C and OASIS ICOM TC).

[edit] User Centred CWE

One of the ECOSPACE main goals was to enable eProfessionals to get access to both, their individual workspace and groups or communities shared workspaces wherever they are, whatever collaboration technologies/tools they use, whenever they need it independently of organisational boundaries.

Users are still looking at collaboration technologies in term of tools like sending emails with attachment for distributing messages and files rather than using instant messaging with links to documents shared on the web according to a project or group context. It is quite obvious to explain the users' motivation for extensively using emails as it is a standardised communication/collaboration technology that one does not need to know in advance whether receivers are using the same email tool. Unfortunately, This is not the case for Instant Messaging (chat) and Shared Workspace tools or Wiki as well as other collaboration technologies as they are not based on a standard allowing interoperability.

The clear benefit of sharing is that shared objects (i.e. messages, documents) are created only once and avoid well-known nightmares like flooded mail boxes with attached files (i.e. photos, videos, presentations) and mixed versions (because of the duplicated files/objects).

Within the ECOSPACE project, one of the objectives was to define the "GSM" (*)of the collaboration tools as a kind of common language that would enable interoperability among these tools at a level where users would not need to know whether others are using the same tool. Hence, it has leaded to the definition and experimentation of Basic Collaboration Services (BCS) as being basic operations that could be applied by different collaboration tools not necessarily belonging to the same category.

The first scenario and demonstration of applied BCS (see a previous article) was built with different Shared Workspace (SW) tools (BSCW, BC, Netweaver). All these tools belong to the same category. In this demonstration scenario, users were able to access objects uploaded into a different SW tool while they were still in their own SW tool and user interface. Demonstrations shown that it is very efficient and there is no more need to duplicate objects, no more need to learn how to use a different SW tool and no more need to remember several usernames and passwords.

The second scenario is about sharing presence information (see the article below) across different collaboration technologies (i.e. Instant Messaging, Web Conferencing, Shared Workspace), hence tools that do not belong to the same category. In this scenario, the online presence of group members is ensured whatever collaboration technologies or tools they are logged in.

Other interesting scenarios could be about sharing group member's profile, group member's context as well as sharing tags, sharing event notifications and so on leading to more translucence especially because collaboration is very much about social intelligence. In these scenarios, one may decide to plug various collaboration technologies and tools through BCS for feeding different collaboration widgets. Furthermore, with a Popfly like mashup editor (see the article below) users could directly create their own collaboration widgets in plugging BCS components with display components or other widget components. It further means that users would be able to compose their own collaborative environment according to their specific contextual needs independently of the specific collaboration technologies and tools used by other group members (i.e. project, community).

BCS as a "standard" needs to be based on an agreed model of collaboration concepts and their related metadata, not on individual data elements such as lines and columns in a relational database management system (RDBMS). Hence, we adopted the SIOC ontology and extended it for supporting specific CWE needs. It also explains the given name "SIOC4CWE". In fact, we selected an ontology rather than a more traditional data model as it brings in more flexibility, contextual information and a good level of mutual understanding.

(*)(well known standard that highly contributed to the success of mobile phones)

[edit] Interoperable Collaboration Services

As mentioned above, Basic Collaboration Services (BCS) are a number of basic operations such as add object(s), get object(s), edit object(s), search object(s), delete object(s) and send to group member(s) where objects could be folders, members or documents. All those object models are described in an appropriate CWE ontology, named SIOC4CWE, which is built-up on the SIOC ontology.

BCS objective is to provide the most appropriate level of interoperability among collaboration tools that enables them to talk together and speak the same language. The idea is, for example, to enable users to share documents without to have to care about which specific online Shared Workspace (SW) tool other group members are using. Up to now, participants of a common project have to use the same SW tool as this kind of interoperability doesn’t exist so far due to the lack of an appropriate standard.

The mass popularity of emailing is certainly due to its simplicity and efficiency; one can easily drop out a message to a distribution list or receive messages without to have to care about the mail server and tool others are using. In fact, there is a standard protocol ensuring interoperability among mail servers and tools. The lack of appropriate standard for Shared Workspace tools may explain why people are still very much relying on email attachment for exchanging documents while it is duplicating files and versioning is soon or later becoming a big issue.

ECOSPACE objective is to propose the standardisation of collaboration objects (i.e. folders, members, groups, documents, tags, blog entries, messages, events, wiki pages, tasks) and their relationships through the creation of a specific CWE ontology illustrated by the "SIOC4CWE" ontology as well as corresponding collaboration services such as the Basic Collaboration Services.

As shown in Figure 1, the BCS layer constitutes the first layer of the Collaborative Environment Reference Architecture.

[edit] Towards the Standardisation for Interoperable Collaboration Services

Regarding the standardisation aspect, a specific technical committee was recently created and launched together with Oracle Beehive at OASIS which is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. The name of this technical committee is OASIS Integrated Collaboration Object Model for Interoperable Collaboration Services (ICOM) TC whose mentioned goal is "Defining a protocol for shared workspaces that supports collaboration activities including unified messages, web conferences, forums, calendars, tasks, wikis, blogs, and social networks".

OASIS sponsor-level members having representatives participating to this technical committee are Cisco System, Knowledge Tree and Oracle. Two research projects funded by the European Commission, ECOSPACE and NEPOMUCK, have representatives participating as well to this ICOM TC.

Participation in the OASIS ICOM TC is open to all interested parties. Commercial and open source providers of specific channel applications including shared workspace, instant messaging, wiki, blog, email, and conferencing will benefit by integrating their components into the ICOM framework. Contact member-services@oasis-open.org for more information on joining the TC. Here is the current list of the OASIS ICOM TC participants:

Person	Organization	Role
Peter Saint-Andre	Cisco Systems, Inc.	Member
Stefan Decker	Digital Enterprise Research Institute (DERI) Galway	Voting Member
Siegfried Handschuh	Digital Enterprise Research Institute (DERI) Galway	Voting Member
Vassilios Peristeras	Digital Enterprise Research Institute (DERI) Galway	Member
Marc Pallot	ESoCE-NET	Voting Member
Philip Arkcoll	KnowledgeTree Inc.	Voting Member
Rafiul Ahad	Oracle Corporation	Voting Member
Eric Chan	Oracle Corporation	Chair
Martin Chapman	Oracle Corporation	Member
Ramesh Vasudevan	Oracle Corporation	Voting Member
Patrick Durusau	Individual	Voting Member

[edit] Motivation for BCS

The open layered architecture designed by ECOSPACE allows breaking the traditional tight coupling between collaborative environments (i.e. content mgmt repositories) and the front-end, which is representing the technology parts that constitute the user interface.

If every repository in use is BCS enabled and if every front-end technology could get meta-data and collaboration objects out of any BCS-enabled repository through a simple semantic enhanced API, it wouldn't matter where shared documents are stored or what front-end technology is in use to get to them in a more "intelligent" way.

Another layer in CERA is named Composite Collaborative Services (CoCoS). In the Composite Collaborative Service (CoCoS) layer, application developers compose new services in assembling Basic Collaboration Services (BCS) for building-up composite functionalities or orchestration of services needed by application users.

For simplifying the creation and editing of CoCoS, a box (each box would represent a BCS and its parameters) editor such as the one used in Popfly would allow lead users to simply compose more complex services (named composite services). This kind of editor allows users to bring and connect several basic components or services together and the editing of their parameters. Beside the BCS and CoCoS layers, this kind of open layered architecture could include CWE Widget Services, CWE Mash-up Services and CWE dashboard that would allow users to compose their own front-end from which they would access and connect all they need in terms of collaboration services (whatever tools are behind those services).

The ultimate goal would be the capability to interconnect or plug needed collaboration features or tools together whatever is the Shared Workspace tool in use for various participants and to show/display collaborative information as expected by each user according to specific needs.

Not only it means that users could freely compose the collaboration services and front end user interface features but more interestingly every new component or service developed and included into the library would automatically become available to all other users whatever tool they are using. The only condition is that collaboration tools should be BCS compliant and adopt the SIOC4CWE ontology.

[edit] BCS scenario with Mash-up and Display components

This section is presenting a scenario where users are willing to directly see photos they have uploaded into an online shared workspace instead of just having a list of filenames that are not necessarily representing properly the content of their photos.

Nowadays, there are available display components that could be used in different context which are applying mash-up principles to get access to data stored into web application repositories. Further to this, there are mash-up editors or composers (i.e. Popfly, Yahoopipes) that allow user to compose the service they wish from available components that are grouped into different categories such as Display, Maps, News & RSS, Social Networks and Tools.

Figure 2 presents the Popfly home page where mashup can be created by users while Figure 3 presents the Yahoo Pipes home page where mashup can also be created in a more or less same composing approach (see Figure 4). In the Figure 2, several red boxes are representing components that could be assembled in plugging a line in between 2 boxes.

One of the available component categories, appearing on left hand side menu in Popfly (see Figure 5), is "Display" where users will find out a list of components for viewing objects such as photos or videos. Available display components are carousel, fader, slideshow, page-turner, photo-flip, photosphere, photo-stack and photo-tiles.

Within this example, a user decided to select the carousel display component for a rotating view of the photos. Now, there is a need to identify the mash-up component that will retrieve the photos first before to be able to display them into a carousel. Again there are several available components depending on the source where photos are located such as Image Scrapper, Image RSS, Gallery RSS, HTML Image and Yahoo Images (see Figure 6). There are other available mash-up components dedicated to other content objects such as video and music.

Finally, the user select the Image Scrapper component in providing the AMI communities URL where to collect images and linked it with the Carousel component where those collected images will be displayed in a rotating view and where it is also possible to click on one image at a time (see Figure 7).

After the experimentation of the Image Scrapper component, the user decided to replace it by the BscwImages component where a folder could be specified in order to collect images or photos (see Figure 8). This component is using BCS for getting access to objects uploaded into the specified folder.

Figure 9 presents the resulting carousel display mode inserted into the BSCW shared workspace banner where photos are shown in a rotating view. It is also possible to select a photo in clicking on it which results into an enlarge view of the selected photo. Figure 10 shows the video screen style presentation which is available in the Carousel component as an actionable switch.

In the first example, the user experimented the Carousel component or function in selecting the Image Scrapper component to catch photos available in wiki pages of the AMI@Work communities for feeding the Carousel component and display them into a rotating view.

In the second example, The user replaced the Image Scrapper component by a newly inserted one which is the BSCW Images component for getting photos that were uploaded into a BSCW shared workspace. Here we assume that the BSCW Images component was previously defined and edited into Popfly before, otherwise it would not appear in the Popfly menu list.

The BSCW Images component is searching and collecting photos, in fact images as being filename.jpg in using the BCS Search operation as specified into the sharedworkspaces.wsdl where WSDL means Web Services Description Language. Then the collected photos are transferred to feed the Carousel component as shown (see Figure 8) by the line linking both the BscwImages and Carousel components.

It is obvious that this kind of Mash-up editor is simple enough for being used by lead users for composing the specific services they need. For sure, in case a specific component does not exist then the users will have to ask a software developer for coding it and inserting it into the library. But the good point is that once it is done, like with the BscwImages component, then it becomes automatically available for other users that wish to use it.

In case a user is willing to do the same for viewing photos that are uploaded into different online shared workspace tools such as BC, Netweaver and Sharepoint then there are three different strategies that could be applied:

• The first one consists to develop a specific Mash-up component for each specific SW tool that will be feeding the Carousel component;
• The second one consists to have only one SW Mash-up component integrating each specific SW code with a parameter indicating which SW tool is going to be addressed;
• The third one relies on "standardising" the SW Mash-up component in introducing the use of BCS for getting content objects' data whatever is the SW tool. In this case all SW tools should be BCS compliant. The use of BCS implies the adoption of the SIOC4CWE ontology as semantically enhanced collaboration object model.

Here is below the code inserted into the banner of the shared workspace:

<iframe style='width:800px; height:375px;' src="http://www.popfly.com/users/396220/BscwImagesCarousel.small?id=1702412&url=http:%2F%2Fwww.cwe-projects.eu%2Fbscw%2Fbscw.cgi" frameborder='no' allowtransparency='true'></iframe>

[edit] BCS Specification

with contributions from ECOSPACE BCS Working Group members

Basic Collaborative Services (BCS) were originally described with a high granularity, with many services and links to the type of resource to be processed in the service explicitly defined (see 'Collaborative Environment Reference Architecture' article). However, the BCS have been updated to describe services at a lower level of granularity. The provision of a constrained set of well-defined services increases the flexibility and applicability of services for many systems and many use-cases. The current set of BCS contains six collaboration services: ADD, SET, GET, SELECT, DELETE and NOTIFY (see the BCS table below). These services can be used for different resource types. The BCS use SIOC to facilitate data interoperability between CWE systems. The specification of the BCS is provided here, along with details of the recommended use of the SIOC data model with the BCS and examples of how the BCS may be invoked.

[edit] List of Basic Collaborative Services

Name	Parameter			Return Value	Description
ADD	URI of target container SIOC resources to be added			URIs of the added resources	Add one or more resources
SET	SIOC resources to be updated			URIs of the updated resources	Set property values in one or more resources
GET		Optional	Default	SIOC resources with requested properties	Retrieve SIOC data of a particular resource
	URIs return_properties depth return_format	yes yes yes yes	home resource predefined 0 xml
SELECT		Optional	Default	SIOC resources with requested properties	Retrieve SIOC data with particular values
	URIs return_properties depth query return_format	yes yes yes yes yes	home resource predefined all all xml
DELETE	URIs			URIs of the deleted resources	Delete one or more resources
NOTIFY	URIs message (plain text)			URIs of the notified users	Notify a user/user group

Table 1: List of Basic Collaborative Services (BCS)

Key to parameters:

• URIs refers to a list of resource identifiers that are identifed by the resource attribute rdf:about.
• SIOC resource refers to teh SIOC representation of a resource. If may be expressed in any RDF format. In ADD or SET it holds the properties of the resource that should be changed. In GET or SELECT it holds the properties that should be retrieved.
• return_properties refers to the list of the properties that should be retrieved using this service.
• depth refers to the depth of the hierarchy that should regarded in the GET or SELECT service. If the depth is zero only that resource will be retrieved/selected.
• return_format specifies the RDF return format. The following values are possible:

xml, pretty-xml	http://www.w3.org/TR/rdf-syntax-grammar/	RDF/XML Syntax
n3	http://www.w3.org/DesignIssues/Notation3	Notation 3
nt	http://www.w3.org/TR/rdf-testcases/#ntriples	N-Triples
turtle	http://www.w3.org/TeamSubmission/turtle/	Turtle - Terse RDF Triple Language
trix	http://swdev.nokia.com/trix/trix.html	RDF Triples in XML
rdfa	http://www.w3.org/2006/07/SWD/RDFa/syntax/	RDFa

• query can be either a SPARQL query or a list of predefined SPARQL expression. The CWE system does not have to support SPARQL queries, enabling the integration of legacy CWE systems that do not represent their internal data as RDF data. However, supporting SPARQL queries will increase the power of the potential queries.

[edit] Recommended use of the SIOC properties

Here are the properties to be used when describing data from a CWE platform are defined. Not all properties must be used. The namespaces in question are as follows:

sioc	http://rdfs.org/sioc/ns#	SIOC Core Ontology
dcterms	http://purl.org/dc/terms/	Dublin Core Metadata Terms
foaf	http://xmlns.com/foaf/0.1/	Friend of a Friend (FOAF) Vocabulary
content	http://purl.org/rss/1.0/modules/content/	RSS 1.0 Content Module
sioc-cwe	to-be-defined

Table 2: Datatype Properties

Datatype Property	Domain	Description
sioc:id	All	Unique identifier of a resource within a CWE system
dcterms:title	All	Plain text title of a resource
dcterms:description	All	Plain text description of a resource
dcterms:created	All	Creation date of a resource in ISO 8601 format
dcterms:modified	All	Modification date of a resource in ISO 8601 format
sioc:content	sioc:Item	Content of an item in plain text
content:encoded	sioc:Item	Content of an item encoded in Base64
dcterms:format	sioc:Item	MIME-type of an item
dcterms:extent	sioc:Item, sioc:Container	Size of a resource
sioc:name	sioc:User	Username of a user in a CWE system
foaf:name	sioc:User	Actual name of a user
foaf:firstName	sioc:User	First name of a user
foaf:surname	sioc:User	Surname of a user
foaf:mbox	sioc:User	Personal mailbox of a user
sioc-cwe:presence	sioc:User	Presence status of a user
sioc:cwe-idletime	sioc:User	Idle-time of a user

Table 3: Object Properties

Object Property	Domain	Range	Description
sioc:container_of	sioc:Container	sioc:Item	Defines the items are contained in this container
sioc:parent_of	sioc:Container	sioc:Container	Defines the containers this container is a parent of
sioc:has_creator	-	sioc:User	Defines the user that has created this resource
sioc:has_modifier	-	sioc:User	Defines the user(s) that have modified this resource

[edit] Examples of BCS Invocation

Invocation of the service ADD. Here the new object is given as SIOC data.

ADD( 'http://www.cwe-projects.eu/bscw/bscw.cgi/1355195', 
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
	xmlns="http://xmlns.com/foaf/0.1/"
	xmlns:dcterms="http://purl.org/dc/terms/"
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:sioc="http://rdfs.org/sioc/ns#">
	<sioc:Item>
		<dcterms:title>D2Cdemoscenario0001.swf</dcterms:title>
		<content:encoded>content in base64</content:encoded>
		<dcterms:description 
			Recorded demonstration ofD2C</p>
			</dcterms:description>
		<dcterms:extent 
			rdf:datatype="http://www.w3.org/2001/XMLSchema#int">
			38994322</dcterms:extent>
		<dcterms:format>
			application/x-shockwave-flash</dcterms:format>
	</sioc:Item>
</rdf:RDF>)

results in the reply

( http://www.cwe-projects.eu/bscw/bscw.cgi/1355195" )

Invocation of the service GET. Here the the retrieved objects are returned as SIOC data.

GET(
	uri=(
		'http://www.cwe-projects.eu/bscw/bscw.cgi/1355195',
		'http://www.cwe-projects.eu/bscw/bscw.cgi/806478'),
	properties=( dcterms:title, dcterms:created )
)

results in the reply

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
	xmlns:dcterms="http://purl.org/dc/terms/"
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:sioc="http://rdfs.org/sioc/ns#">
	<sioc:Item rdf:about=
		"http://www.cwe-projects.eu/bscw/bscw.cgi/1355195">
		<dcterms:title>D2Cdemoscenario0001.swf</dcterms:title>
		<dcterms:created>2008-09-03T08:17:54Z</dcterms:created>
	</sioc:Item>
	<sioc:Container rdf:about=
		"http://www.cwe-projects.eu/bscw/bscw.cgi/806478">
		<dcterms:title>WP4 Files</dcterms:title>
		<dcterms:created>2007-11-08T09:15:51Z</dcterms:created>
	</sioc:Container>
</rdf:RDF>

[edit] Exchange of Presence and Availability Information

with contributions from the ECOSPACE Presence Working Group Members

[edit] Introduction

Exchange of information about users' availability in the context of a CWE is a common need. It particularly appears in distributed collaboration scenarios based on the intensive use of collaborative applications. There are many ways to exchange Presence and Availability information, both proprietary (e.g. in Skype, Facebook) and openly standardised in certain domains (e.g. XMPP). Unfortunately, they are limited to the corresponding domains, and re-use of the corresponding information in new domains is quite difficult. Furthermore, a well known common barrier is the need to support various middleware technologies. One also has to struggle with broad diversity of existing Presence definitions.

In ECOSPACE, we suggest to address the mentioned challenges by means of the Basic Collaborative Services, in particular the GET service. They turned out to be an ideal background technology for exchange of Presence information. The work on Presence information exchange and BCS specification mutually influenced each other. Taking the approach of BCS for Presence communication provides for extensibility and flexibility, allowing e.g. to specify the particular kind of Presence information to be exchanged in each scenario.

ECOSPACE partners work with several systems able to provide Presence information. They range from awareness of generic fact of user’s activity in a working environment to instant communication availability, mobile availability, and to more detailed information on availability context, such as time passed after the last recorded user’s activity in a system. In our collaborative scenarios, one user can maintain accounts in multiple systems.

Partners involved in the ECOSPACE Presence Technical Working Group are:

	Fraunhofer-FIT, Germany		Business Collaborator, United Kingdom		ETRA Group, Spain		SAP AG, Germany
	Department of Telematic Engineering (DIT) – UPM, Spain		University of Murcia, Spain		Jaytown, The Netherlands

[edit] Aggregating Presence Information

A way to aggregate Presence information from different systems is therefore needed to support the scenarios.

Originally, we defined a service "GetPresenceStatus" intended to provide a flexible but simple way to ask a basic question: "What is the presence status of a user in any selected context". Before we explain how that service is embedded in BCS GET overall service, it is instructive to take a closer look at some ideas behind "GetPresenceStatus" itself and their benefits.

First, we had to specify a technology to simplify querying partners’ collaborative environments and systems. In alignment with the general ECOSPACE architecture, we decided to use Web Services. A more involved issue was to reconcile end users needs for Presence Information and CWE developers' preference to minimize development efforts.

One problem is that users have multiple user accounts and different CWEs support different user identification schemes. For example, a project manager may know Email address of a team member and may try to get that user’s availability status based on his Email address. Another team member might be an OpenId supporter and consequently wish to always use the corresponding global OpenId accounts. Making the situation even more complex, several of our systems have their own proprietary user identifications. In ECOSPACE, we extensively use BSCW to support project activities and have to deal with BSCW user IDs.

Admittedly, several approaches to synchronise user databases have been already described in ECOSPACE and global identifications such as OpenId have been recommended. Still, often one has to deal with multiple user IDs (UIDs) and users should be able to avoid the need to take care of which system uses which kind of user identification. Additionally, CWE providers should be able to avoid costly user mappings. They also have different requirements as they may support multiple accounts for each user and/or they may restrict permissions to retrieve presence information in a system-specific way etc.

To solve the above mentioned problem in a simple way, we decided to allow for multiple UIDs to be specified for each user. Such an approach is very flexible. Since specification of multiple UIDs is a possibility and not a requirement, users can still decide which accounts they use with which provider. On the other hand, presence providers can choose the most appropriate strategy to deal with the request. Usually, they would look for the first UID in the list that they can recognise as a known user and use it for the following operations. More involved strategies are also possible. A provider could collect all UIDs for a user and choose the one with most permissions in the provider’s system. Our approach secures the basic functionality, but leaves the freedom to support custom requirements as well.

We use the Basic Collaborative Service (BCS) GET to retrieve presence information. The only requirement for a UID we then have to introduce is that it has to be a valid URI. In particular, users in the context of SIOC4CWE are valid UIDs for presence retrieval. Email addresses are represented by means of the common mailto: prefix. OpenId identification is also a URI. The mentioned requirement prevents possible naming clashes. We recommend that a provider stores mappings from often used UIDs of their clients to the local provider’s UID, possibly together with the presence status information. Also note that sending just one ID for each user generally improves queries performance and used network resources.

To be able to re-use BCS Get Service, we send all UIDs of all requested users as one parameter, technically, an array of strings. We recommend that different accounts for the same user come in a sequence. The following table summarizes the parameters of the BCS GET service used to retrieve Presence information.

Parameter	Type	Comment	Example
uri	ArrayOf_xsd_string		("http://www.cwe-projects.eu/bscw/bscw.cgi/1355195", "mailto:viktor@sap.com", "http://viktor.myopenid.com")
return_format	string	"N3" or "N-Triples" or "RDF/XML"; proprietary formats are also possible but negatively impact interoperability	"N3"
return_properties	ArrayOf_xsd_string	Represents requestor Presence information needs. We recommend using “onlineStatusName” and “inactivityPeriod” or imply their usage if return_properties not specified, cmp. main text
depth	int; 0 by default	usually omitted in the context of Presence Information

A more elaborate explanation is important for the return_properties parameter. We take a simplified approach in comparison to the OPO Online Presence Ontology Specification (http://www.milanstankovic.org/opo/specs/2009/OPO-20090501/).

Our approach is not as flexible but much more compact and also sufficient in most cases. We reuse the terms "onlineStatusName" and "inactivityPeriod" (xsd:duration after ISO 8601) from OPO. Extension of our use of Presence Information to more expressive OPO is straightforward, if necessary.

It follows an example for a service response about the presence of two users. The provider system decides which account (out of possibly several supplied ones) it uses for each user and informs the requestor of that decision in the response, stating the UIDs alongside their presence status.

 @prefix dcterms: <http://purl.org/dc/terms/>.
 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
 @prefix sioc: <http://rdfs.org/sioc/ns#>.

 <http://www.cwe-projects.eu/bscw/bscw.cgi/12345678> 
       dcterms:title "aaa.bbb@fit.fraunhofer.de";
       sioc:onlineStatusName "offline";
       sioc:inactivityPeriod "PT120S".
 <http://www.cwe-projects.eu/bscw/bscw.cgi/123> a sioc:User;
       dcterms:title "name";
       sioc:onlineStatusName "online";
       sioc:inactivityPeriod "PT10S".

For simplicity reasons, we decided to use a selected set of values for onlineStatusName, namely:

• "unknown user",
• "offline",
• "in-conference",
• "away",
• "busy",
• "idle",
• "online".

We mapped the possible statuses of each ECOSPACE system onto that set of statuses. More flexible approaches, such as that of OPO ontology, can be easily adopted later if necessary.

To demonstrate the power of Presence integration we work on a prototype allowing seamless access to different kinds of Presence information in partner systems. This is a collaborative activity bringing together all partners in our Presence Technical Working Group.

[edit] Presence concepts extensibility

Functionality such as requesting users' presence status is common in modern collaborative working environemnts. Unfortunately, it is mostly tightly integrated into users' favorite collaboration software. If one wants to be aware of availability of friends and colleagues who are using different working environments, one gets little support.

The needed information can mostly be retrieved via dedicated programming interfaces, but this is not a suitable option for end users. Even more important, there is no support, if one needs simple means to reuse presence information in more complicated scenarios.

The ECOSPACE architecture together with the proposed BCS specification provide for a way to solve the mentioned problems. Particularly non-professionals can make use of presence information in their special personal context. The idea is to export the presence information through a BCS, namely the GET service. ECOSPACE partners devised a short guideline based on open standards, sufficient to enable agreed, straightforward but powerful presence information exchange.

In view of the fact that we use standardized Web Services, our approach enables us to use mash-up composers to quickly create applications without expert knowledge. In ECOSPACE, we created a mashup that regularly asks partners' servers about the availability of selected users. In particular, the case that one user has accounts in multiple systems is supported. Furthermore, different kinds of availability can be aggregated. In the figure, two of the selected presence-information providers actually represent online status of users working with their mobile devices. Another provider (Post-@) connects to a professional presence and messaging software product, that itself can serve as a gateway to multiple systems. Still another provider (BSCW) exposes information on users' activity in a shared workspace, especially interesting because that kind of presence is conceptually different, if compared with traditional use of instant-messaging applications. The mashup approach allows for extensions that are otherwise tedious to achieve.

In our example, if a presence-information provider supports ECOSPACE BCS, one can generate a Popfly component out of it with a couple of clicks. In our case, you then only have to drag the block on your mashup canvas and the mashup application immediately shows you the presences including the new provider. (Few customizations would be needed to optimize the visual appearance). One could compose even more elaborate tools that pass the presence information to some further processing units. As usually, the mashups can be embedded in external web pages.

[edit] Topic Maps for CWE (TM4CWE)

[edit] Introduction

Topic Maps are sophisticated indexes for dynamic collections of heterogeneous, structured and unstructured information sources. Historically, Topic Maps are derived from the idea of back-of-the-book indexes. But they not only provide a simple accessing structure to information the way indexes do. In addition, the sophisticated Metadata they represent can be detached from the original information, interchanged, and reused. In contrast to the full text search they supply the user with the significant subjects in a specific domain and their relations among each other.

A further advantage of Topic Maps is their inherent subjectivity because they add semantics to data without modifying it. Moreover, one Topic Map may describe several information pools and several Topic Maps may apply to one single information pool. TM4CWE enables the collaborative development of Topic Maps. TM4CWE is a collaborative work environment, which enables the creation, maintenance, and use of ontology-aware repositories based on Topic Maps. In this way the content of Topic Maps can be easily changed and expanded.

TM4CWE is composed of two distinct modules:

• The Browser allows users to simply view and navigate shared information coming from different collaboration tools (i.e. shared workspaces).
• The Editor allows users to personalise their collaboration environment in creating relationships amongst different concepts such as a contextual working structure (i.e. WBS, OBS).

[edit] Requirements and Motivation

TM4CWE fits with the concepts of "People-Centric Visualization" and more generally with the "People-Concepts Networking" (PCN) approach whose objective is to connect people with their working artefacts through concepts or topics (when they are related to an ontology) or even tags (when they are related to a group taxonomy also named tagsonomy).

TM4CWE allows implementing the PCN approach of creating relationships among people (i.e. group members), concepts and related artefacts (i.e. documents, photos, blog entries, wiki pages, tags) and generated events. In this approach users and documents are used as nodes and generated events as edges. All these information are coming from different hub systems. In fact the hub systems are shared workspace platforms such as BSCW, BC and others that are compatible with the SIOC4CWE ontology through the use of Basic Collaborative Services (in short BCS). . The TM4CWE Viewer, which graph view includes a semantically expressive, browsable graph the above relation is displayed as a dynamic picture.

[edit] Functionality

The TM4CWE Editor & Browser is implemented in Java and uses the TM4J Topic Map Engine, which is an open source providing a comprehensive API that allows creating and modifying Topic Map structures stored either in-memory or persistently in a database. The Editor has open modular architecture that allows an easy extension of its functionality. The TM4CWE environment consists of a TM4CWE Editor and TM4CWE Browser.

TM4CWE Editor (see figure 1) provides ontology and metadata engineering capabilities coupled with basic document management facilities.

TM4CWE Editor allows users to manipulate topics, relationships between them, resources, and contexts (represented by themes). The content created by the Editor is fully compliant with the XML Topic Maps (XTM) standard and thus interchangeable and interoperable with any standard XTM tools.

The TM4CWE Browser (see figure 2) provides an animated and zoom-able view with context sensitive features like click-able topics or selective detail views.

[edit] Application Scenario

TM4CWE Browser is connected with hub systems such as BC and BSCW or any other SIOC4CWE enabled shared workspace system. It retrieves and visualises as a graph SIOC4CWE data from various shared workspaces that are processed for specific semantic information.

The resulting data are saved as a topic map (XTM file) and edited in the TM4CWE Editor which allows users to semantically annotate the relationships upon its own scheme in order to personalise his collaborative environment. For example, group members might decide to create concept or tag categories for setting-up a contextual working structure related to projects. Naming folders and tags like WP1, WP2,…., WPn; T1.1, T1.2,… Tn.m allows group members to retrieve the content objects or documents others have uploaded into an online project shared workspace and make the connection in their mind with the project structure.

However, the intelligence behind the Work Breakdown Structure (WBS) is telling that WPn are “workpackages”, Tn.m are “tasks” and Dn.m are deliverables and that a project is composed of “workpackages” and then each workpackage is composed of tasks. For sure, each task is producing one or several deliverables and one or several group members are responsible for these deliverables.

Such a WBS represents the contextual working structure in which group members are evolving and that they should remember permanently. When users are entering into an online project shared workspace, then they should open a WPn folder to find the related task folders where they will find the related deliverables.

TM4CWE Editor allows to create new concepts such as workpackage, task and deliverable and to link them through a relationship such as “is composed of” and implicitly with the various folders according to their respective type. It means that the WBS structure will be then memorised and maintained into their collaborative environment that they will directly use with the TM4CWE Browser for a more intelligent navigation.

This kind of example could be repeated for categorising the maturity level of documents (i.e. preliminary draft, on-going draft, final draft, completed version, accepted version, reviewed version). Furthermore, it is also possible to link group members with the WBS as a kind of Organisational Breakdown Structure (OBS) which would provide even more intelligence to the TM4CWE Browser.

[edit] Benefits

Topic Maps (TM) are an emerging Semantic Web technology, that can be used as a means to organise and retrieve information in repositories in a more efficient and meaningful way.

Exploration on the level of concepts and relationships as well as connection among group members can be used as a navigation and query formulation mechanism fostering semantic exploration and discovery. Such an ontological framework is really useful when coupled with an interactive tool such as TM4CWE Browser for supporting efficient semantic browsing of large information sets based on conceptual knowledge. We proposed a framework for resources that incorporates a meta-layer - semantic layer, based on conceptualisation of the resource subject domain.

Visualisation in the form of a graph helps the user to better understand and analyse information in an easier way. This is particularly important when representing ontological structures, which can be very complicated.

Two main sources of information are used to generate effective visualizations of topic maps:

• Syntactic knowledge based on the topological properties of the topic map.
• Semantic knowledge based on the meaning of the topics and relationships between them captured by the topic map.

Special attention is paid on reducing the size of the information space. The latter is known to be the key to dealing with scaling problems in visualisation and can also make the structure of the collection of data more apparent. This reduction is achieved by developing multi-level filtering techniques to hide nodes and relations.

[edit] Integration

The TM4CWE application is compliant with the ECOSPACE Reference Architecture (see figure 3). The lower level of the architecture comprises a set of basic services. Some of these services are new, while some have been developed in other applications.

Basic services include:

• Topic authoring, to add a new topic to or edit/delete an existing topic in a topic map.
• Relationship type authoring, to add/edit/delete a relationship type in a topic map.
• Visualizing and browsing a topic map.

In the next layer of the architecture, the CoCoS layer, two CoCoSes are included and are used by the TM4CWE application:

• Topic Map Authoring, for creating and updating a topic map.
• Semantic Navigation, for topic map-based exploration of SIOC4CWE data.

[edit] Conclusion

Despite of its advantages, Topic Map based information access is still far from the mainstream. Three additional issues in this context need to be solved:

• Automatic generation interchangeable Topic Maps;
• Collaborative refinement of these generated Topic Maps;
• Easy integration of the generation process and of the Topic Map handling process in the working environment of knowledge workers.

TM4CWE directly addresses these needs. In addition, we have seen that the easy integration of the generated Topic Maps in applications must be significantly simplified. TM4CWE is a prototype which gathers technologies of Topic Map generation and offers interfaces for integration in the users working environment and processes.

[edit] Shaping the Future of ENoLL and AMI Communities

Roberto Santoro

AMI@Work Communities

[edit] Introductory message

Our AMI Family of Communities keeps growing and we have passed the mark of 3300 members. We have accomplished great things, including supporting the Launch of the European Network of Living Labs, which counts 129 members and is now acquiring the legal status of an International Non Profit Association under Belgian law. As you know on the Vernal Equinox of the 20th of March 2009, the first Assembly of the ENoLL Founding Members has taken place in Brussels and has elected a Council and Acting Coordinators for Domain Networks and Living Lab supporting Communities.

The Council is making all its discussions, decisions and actions visible to all AMI communities' members and you can look up the meeting minutes and all information on the evolving ENoLL governance structure here

It has been with the creative spirit of so many individuals like you in our AMI communities that this milestone has been reached. And now it is time for our overall community to reorganize itself, to serve better the Knowledge, Social and Business expectations of all of us. The AMI Communities' Chairs believe that we must create a yet stronger synergy with the Living Lab movement, which promises to become the most important User Centred Open Innovation mechanism in Europe and abroad.

[edit] Action Plan for 2009

During 2009 the ENoLL network will acquire the legal personality by establishing an International Not for Profit Association under Belgian law. The ENoLL AISBL will provide an outstanding set of services to its members and to the Living Lab movement at large.

During 2009 the AMI communities shall be reorganized and several task forces will be activated. In particular for:

1. AMI Governance for fertilizing the ground for KBS assets growth;
2. LLABS ICT infrastructure for multisite collaboration, Network Centric Architecture;
3. LLABS Multidisciplinary research issues for Innovation related emerging disciplines;
4. User Communities interaction across regions for activating 1.000.000 users.

ENoLL Evolving Structure

On the basis of the decisions taken by the General Assembly on the 20th of March 2009, the ENoLL Council is proceeding to identify the services that the new ENOLL AISBL will provide to its members and to the Open System of Living Labs Communities.

These Communities being established include:

• a. ENoLL AISBL the International Association of Living Labs;
• b. LL-Open, the Living Labs Open Innovation Community of interested individuals;
• c. LL-Partner, the Living Labs Partners Network of interested organization;
• d. LL-Policy, the Living Labs Policies & Strategies Group;
• e. LL-Regio, the Living Labs Clustering for Regional and Territorial Development;
• f. LL- Domain Network for Wellbeing, Health, Inclusion;
• g. LL- Domain Network for Energy & Environment;
• h. LL- Domain Network for Media & Creativity.

The motivations declared in the ENoLL 3rd wavers applications have inspired the design of the following proposed "user driven services":

• International visibility, prestige & brand;
• Get connected to new partners;
• Share practices, for-with-by-user methods, business models, IPR and legal…;
• Co-creation of new knowledge on llabs;
• Joint large scale pilots;
• Share users communities at European scale;
• Access European funding;
• Attract business to the region.

As part of its strategic branding initiatives for supporting the establishment and wide adoption of Living Labs, ENoLL will launch a Living Lab Prize, aimed at:

• Connecting Industry with the Living Labs movement, in order to stimulate the creation of new ideas which are beneficial for all the stakeholders (Citizens, Users, Consumers, Industry and Regional Development Agencies);
• Providing added value services to Industry, through the opportunity of testing, validating and evolving the proposed product and/or services in the real life settings provided by the Living Lab.

The Living Lab Prize sponsors would typically be Corporate Industry and or Regional Entities willing to define the "themes for the contest" and sponsor the process of both supporting the creation and real-life evaluation of ideas. The constituency within the involved Living Labs (typically single SMEs, entrepreneurs and/or networked entities) will respond to the prize with proposals. The winner of the Living Labs prize will receive a cash award and the support for up to 6 months service/product development process in the most suitable Living Labs in that specific domain.

In order to fulfil its mission, ENoLL is providing Living Labs related services to the various stakeholders. Services can be classified in 3 different types based on their access cost:

• Open Free Services: available to all members of the ENoLL network (currently 129 members) and to the supporting communities;
  • Enabling Networking: design, improve, maintain, manage the ENOLL collaborative platform for enabling KBS assets accrual - facilitate interaction and sharing through physical and virtual events - transfer of experiences between Living Labs
  • Network Communication: Maintenance of information repositories - Maintaining up-to-date information on ENoLL members, including mailing lists, their projects, project results, and events at the agreed forum/fora (e.g. ENoLL website, AMI Communities, Wiki etc.) - Communication Services, News letters, websites for the ENoLL Communities and to general wide audience (press release, video interview…)

• AISBL Members Services: available to all the members of the ENoLL AISBL association who have paid the membership fee
  • Network Strategic Management: Network coordination, Branding and strategic management, ENoLL representation, establishing alliances, contracting …
  • Policy Linking: influence and link to innovation policy at European, National and Regional level;
  • Assessing Network and Living Labs Performance: definition and operation of a Living Lab Maturity model, suitable for being self administered by all the organisation members of the ENoLL, set up and management of a Living Labs Observatory, based on a Living Labs Policy socio economic effectiveness model, Performance indicators at Network and LLABs level
  • Brokering Knowledge: extract, validate, edit, and publish practices and success stories emerging from individual and networked LLAB innovation actions
  • Network Operations: Administrative Services and Book keeping; Memberships processes ; Office support and point of contact to respond member’s requests and to support ENoLL institutional bodies (Assembly and Council meetings and activities)
  • Training: Induction of new members to acquaint themselves with Community collaborative platform, processes , ground rules and opportunities
  • Catalyzing Opportunities: stimulate, identify, validate projects and funding opportunities for increasing the Living Labs knowledge base - catalyze partnership to create wide scale pilots addressing key societal challenges and prepare the ground for Living Labs Prize. Virtual Team Creation Opportunities for individuals

• On-Demand Services: available on demand, to get support on a specific issue (e.g, to support a specific Living Labs pilot, to conduct benchmarking studies…). Such on demand services will be available upon payment and released through ENoLL Living Lab Service providers (qualified members of ENoLL AISBL).
  • Legal Issues: Identify and address External and Internal Legal Issues for (IPR, individual data protection, liability…), and provide templates for inter LLABS clustering and pilots/projects collaboration
  • Living Labs environment improvement: Support to improve organisational elements (IT, collaboration processes, governance….); Benchmarking
  • Living Labs Pilots: Support to the set-up and operation of a Living Lab pilot, funded by the Industry and Institutional sponsors and suitable for conceptualising, developing, deploying and evolving specific products and services.

ENoLL welcome the continuous growth of the AMI communities and of the Living Labs Open Innovation Community of individuals and intends to support his continued development for the benefit of the ENoLL and the overall Open System of Living Labs Communities.

The AMI family consists of self-organising communities, facilitated since June 2004 by elected leaders. These communities represent potential cross fertilizing technology themes and challenging validation environments with a significant technological, economic and societal impact. The AMI@Work family of communities itself is a real-life collaboration experiment. ’Practice what we preach’. These communities are based on web-based membership registration by interested individuals.

The AMI@Work communities have facilitated the inclusion in the European policy initiative i2010 – A European Information Society for growth and employment – of a European network of Living Labs, as described in the Indicative List of Actions for the i2010 Priority 2, Innovation and Investment in Research : “Developing a European network of Living Labs in the concept of eWork, providing services of large deployment to the industry, bringing technology test-beds into real-life user environments.” (web: europa.eu.int/i2010 : i2010 Extended Impact Assessment, p. 88).

A European network of Living Labs can create a win-win-win Citizens-Private-Public partnership. This co-creation sets users, citizens, in the centre of new innovation and societal experimentation, to create new systems, services, products, business models and societal models. Value creation by multidisciplinary collaboration can link social innovation with technology innovation, creating commons to build upon.

In enterprises, a concurrent engineering approach has enabled functions to collaborate, allowing faster time-to-market or time-to-fulfilment and better ‘hit rates’ for reaching successful products and services. Virtual extended enterprises have widened the concept to concurrent enterprising. Living labs now have the potential to co-create ‘concurrent enterprising on a societal scale’, with faster time-to-fulfilment and better innovation ‘hit rates’ to be enjoyed by citizens, companies and public sector alike. A white paper on Virtual Professional Communities and on Concurrent Innovation is available for download at www.ami-communities.eu home page at the Books and Papers section.

[edit] AMI Communities Family Metaporphosis

The AMI@Work Family of Communities has thrived from a modest network of specialists gathered by several organizations involved in the MOSAIC project to a Europe-wide community of more than 3300 experts in the field of collaborative innovation. Nonetheless, the five main Families’ constructing pillars that have existed since its creation i.e.: self-organisation, independence, human centrism, and its virtual and voluntary character, are to remain as the building blocks of the new structure. However, to express a shift to the new approach, AMI@Work’s name which stood for Ambient Intelligence AT Work changes to Ambient Innovation AT Work.

The new proposed structure of the AMI@Work Family of Communities is intended to facilitate synergy with the Living Lab movement at large and in particular with the organizational structure of the ENoLL based on Innovation Domains Networks. Based on the results of the poll published on the AMI web site, the proposed Vertical Domain Communities are:

• Health/Well-being/Inclusion,
• Energy and Environment,,
• Media/Creativity,
• Engineering, Manufacturing and Logistics,
• Regional and Rural

These vertical domains should be perceived through the context of open collaboration and regional development. In addition to them, 3 horizontal Domain Communities have been identified:

• Living Lab and Open innovation Methodology. User Driven Open Innovation community of individuals, focusing on Methodologies for enabling users to drive as protagonist ICT based service Innovation; This is the Home Community for Living Lab Users and methodology professionals.
• Enabling ICT for Living Lab and Open Innovation. Investigating the next generation of internet and network centric technologies and architectures enabling Ambient Innovation. This covers the Collaboration Environment and the ICT infrastructure for service development and fruition.
• Education for Living Lab and Open Innovation. Learning and teaching, e-learning, virtual learning, pervasive learning. Living Lab Academy (European Master's degree on Living Lab Living Lab Training)

Innovation in this cross-cutting, horizontal Technological and Methodological domains are enablers for any progress in the vertical layers.

The enhanced AMI@Work structure mirrors the aforementioned domains and encompasses the most active Communities from those that have existed so far. The Horizontal Community technology@work merges the current collaboration@work, knowledge@work and mobility@work Communities. The Families embed the Living Labs Open Innovation Community (which, actually, was born and brought up within the ‘old’ AMI structures). The Living Labs Open Innovation Community (LL-Open) has evolves into the new AMI Family of Communities. It is open to all individuals, globally, who are interested in Living Labs and Open Innovation. The open community was launched on 20th November 2006 in Helsinki as part of the Finnish EU Presidency launch event of the European Network of Living Labs, including the Helsinki Manifesto launch.

The community of individuals and the network of Living Labs are facilitated by the CO-LLABS Thematic Network. The earlier members of the LivingLabs@Work and Leadership@Work Special Interest Groups have become members of the Living Labs Open Innovation Community.

The way the Communities are going to operate is to take into account the existing initiatives, e.g. European Technology Platforms (NESSI, eMobility, ARTEMIS, NEM), EFITA, etc., and – through partnering with their selected members and supporting certain areas of interest – pursuing joint actions. A similar collaboration has been achieved with regards to the FP6 projects (mainly IPs supporting the RTD of Collaborative Environments (e.g. COSPACES, ECOSPACE, LABORANOVA, C@R) and FP7, such as COIN IP on Collaboration and Interoperability)

Last but not least, the Family has to align itself to the funding sources that will enable its effective and successful operation. These sources will include primarily: the 7th Framework Programme (including the ICT and Regions of Knowledge Programmes), CIP, and regional funding (mostly from Structural Funds). Close collaboration is planned with selected DGs – mainly: DG Region, DG Infso, and DG Research.

[edit] ENoLL and AMI communities Next Events

In the context of the ICE 2009 conference we are organizing a series of workshops on Living Labs. Do not miss this opportunity. Also take note that the new chairs for the AMI Family will be appointed during the ENoLL Open meeting: ENoLL and AMI Evolving Structures on Wednesday 24th June afternoon.

Living Lab track

Track Chair: Roberto Santoro, ENoLL Acting Council Chair The Living Lab track consists of 5 workshops supporting the development of the Living Labs and its 129 members network.

Day 1 – Monday 22nd June 2009 The ICE Conference first day will feature the presentation of 48 papers in parallel tracks. The presentations will give insight to the latest findings from R&D in CE, Collaborative Working Environments & Living Labs.

Day 2 – Tuesday 23rd

The Living Lab Track will be introduced by a joint session (9h00-10h30):

• Chair and Introduction: Jean-Pierre Euzen, European Commission
• CO-LLABS and ENoLL, Roberto Santoro
• Discover Leiden Living Lab, Jan-Marc Verlinden and Bernhard Katzy
• Dutch Living lab, Martijn Kriens and Veli-Pekka Nitamo
• Living Lab Services, Jens Schumacher
• Getting results from Living labs, Hermann Loeh
• Angelos Ktenas , European Commission: EU Policy on Living Labs

Three workshops will then be conducted in parallel

1. "Living Labs and SME Innovation in European Regions", addressing the set-up of Living Labs pilots at (inter) regional level, the definition of business models for future sustainability of Living Labs and Policies and New instruments to stimulate SME innovation;
2. "Discover Leiden Living Lab", best practice cases from the Leiden Living Lab
3. "Dutch Living Lab Event", Policy supporting Living Labs in The Netherlands

Day 3 – Wednesday 24th Living Lab Track workshops

Three workshops will be conducted in parallel

1. "Living Labs and SME Innovation in European Regions" (second part)
2. "Getting results from Living Labs – Methodology, actual Cases and lessons learnt";
3. "Services for Living Labs", introducing new tools supporting the competitiveness and innovation capability of the actors within the Living Labs.

Day 3 – Wednesday 24th afternoon, specific meetings for the ENoLL Community:

14h00-15h30 : ENoLL Open meeting: ENoLL and AMI Evolving Structures

This ENoLL Open Meeting will discuss the new organizational structure of the Living lab Communities

• LL-OPEN, the Living Labs Open Innovation Community of interested individuals, Roberto Santoro
• LL-POLICY, the Living Labs Policies & Strategies Group, Veli-Pekka Nitamo
• LL-PARTNERS, the Partners Network of interested organization, Bernhard Katzi and Seija Kulkki
• LL-DOMAINS Networks: Energy & Environment, Alvaro Oliveira; Wellbeing, Health, Inclusion, Bidatzi Marin Bastida; Media & Creativity, Philippe Roy; Regio and Territorial, Jesse Marsh

16h00-18h00 : ENoLL Council internal meeting

This Council Meeting is dedicated to the planning of the ENoLL Founding Members Assembly to be held in Lulea, on July 3rd 2009

[edit] Latest News

[edit] Establish Latin America/EU RTD cooperation in NEM area with SALA+

The SALA+ project, aiming at connecting Latin America and Europe through R&D cooperation in the networked electronic media (NEM) area, is offering since fall 2008 a free access on-line database tool enabling potential partner identification. This on-line database is accessible via the link “partner Search” at the top left menu of SALA+ website homepage: http://www.salamas.eu/

whereby any visitor is offered to:

• Freely Register and fulfil its company profile (via on-line questionnaire),
• Dispose and exploit the last updated list (database) of all company profiles registered,
• Make on-line partner search in this database, for identifying all companies meeting required criteria (company status, country/region, RTD domains of interest...)

Therefore any Organisation from both Latin America and Europe having interest to establish such cross-cooperation and launch new R&D projects is taking benefit of this partner search facility providing it is also fully registered.

Through this free service (still in start-up phase), SALA+ is wishing you fruitful collaborations.

[edit] Up-coming Events

[edit] ICE 2009, Noordwjik, The Netherlands, June 22-24 2009

Latest NEWS of ICE 2009 PROGRAMME

Day 1 will feature the presentation of 48 papers in parallel tracks. More than a decade of papers is selected for a Poster presentation. The presentations will give insight to the latest findings from R&D in CE, Collaborative Working Environments & Living Labs.

There will be prominent Keynote Speakers during the 3 days, in particular:

• Bror Salmelin, Policy Adviser to the Director, ICT addressing Societal Challenges Directorate, DG Information Society and Media, presentation title " Participative Innovation in creating User-Centric Service Economy”
• Dr. Erastos Filos, Head of Sector “Intelligent Manufacturing Systems”, DG Information Society and Media
• Dr. Guido Petit, Director of the Alcatel-Lucent Technical Academy, Chief Scientist Office at Alcatel-Lucent Bell Laboratories (Bell Labs), presentation title “From Entrepreneurial Boot Camps to Open Innovation: a journey of leadership in changing times ”
• Drs. Lineke Sneller, Director of IT at Tele2," Compete, Collaborate and Co-exist in Telecommunications "
• Michel Courtois, Director of the Technical and Quality Management Directorate at ESA/ESTEC, presentation title “Concurrent Engineering: mandatory for design and management of complex systems”
• Prof.dr.ir. Elke den Ouden, Manager Product Innovation at Philips, presentation title “Innovation@Philips - Strategies and Developments in Open and End User Driven Innovations”

The sessions’ main tracks on Day 1 are:

• Methods and Tools for Innovation management
• LivingLabs: Cases
• Collaborative Environments and Systems
• Networked Organisations
• Advances in Concurrent Engineering

Day 2 and Day 3 are featuring invited and special sessions as well as workshops, training and demonstrations. Invited and special sessions are dedicated to the presentation of scientific papers while workshops aim to bring together users and experts in interactive sessions for elaborating specific topics (please refer to website for detailed workshops agendas).

Track 1: Living Lab, chair: Roberto Santoro The Living Lab Track will be introduced by a joint session (9h00-10h30):

• Chair and Introduction: Jean-Pierre Euzen, European Commission
• CO-LLABS and ENoLL, Roberto Santoro
• Discover Leiden Living Lab, Jan-Marc Verlinden and Bernhard Katzy
• Dutch Living lab, Martijn Kriens and Veli-Pekka Nitamo
• Living Lab Services, Jens Schumacher
• Getting results from Living labs, Hermann Loeh
• Angelos Ktenas , European Commission: EU Policy on Living Labs

Track 2: IEEE Technology Management Council, chair: Roberto Bierwolf

Track 3: INTEROP - Enterprise Interoperability, chair: Sergio Gusmeroli

Track 4: IMS - Digital Factory, chair: Luca Canetta

Track 5: SatNav Downstream Service Innovation, chair: Martin Haunschild

Track 6: CE Concurrent Engineering, chair: Massimo Bandecci

Track 7: Collaboration, chair: Marc Pallot

Day3, besides all workshops, will propose a visit at Space Expo at ESA, and a Keynote speech of Mr Michel Courtois, director of ESA-Estec NL.

And also a Special ENoLL afternoon session:

14h00-15h30 : ENoLL Open meeting: ENoLL and AMI Evolving Structures This ENoLL Open Meeting will discuss the new organizational structure of the Living lab Communities

• LL-OPEN, the Living Labs Open Innovation Community of interested individuals, Roberto Santoro
• LL-POLICY, the Living Labs Policies & Strategies Group, Veli-Pekka Nitamo
• LL-PARTNERS, the Partners Network of interested organization, Bernhard Katzi and Seija Kulkki
• LL-DOMAINS Networks: Energy & Environment, Alvaro Oliveira; Wellbeing, Health, Inclusion, Bidatzi Marin Bastida; Media & Creativity, Philippe Roy

16h00-18h00 : ENoLL Council internal meeting This Council Meeting is dedicated to the planning of the ENoLL Founding Members Assembly to be held in Lulea, on July 3rd 2009

The "ICE2009 Final Programme" is available for downloading, feel free to disseminate it to your colleagues and contacts that could be interested to join this valuable event.

As a participant, you can enjoy the early bird discount for this enriching three-day conference and workshops if you sign up before 30 April 2009. You can sign up using an all-in-one package, or just for day if you so wish, or you may pick, chose and assemble your own conference pack. And aside of the well-known early bird discount, we also have a tombola this year. For those who indeed sign-up early, there is an additional chance to win a free room upgrade. From all those that register before April 30th 2009, two registrants will be drawn. So this is your chance to have yourself two birds at once.

COIN4LL Workshop (see here for futher detailed information)

 "Unleashing Open Innovation with Enterprise Collaboration & Interoperability Services, the Living Lab Way"

Organisers: ESoCE-Net and ENoLL, TXT e-Solutions, ISOIN and JSI

• Chairs: Marc Pallot, COIN Angel and Alberto Olmo, ISOIN
• Co-Chairs: Sergio Gusmeroli, TXT e-Solutions, Marco Conte, ESoCE-Net and Drago Trebeznik, JSI

Workshop Objective: Discuss and capture feedback and requirements for the COIN platform to offer collaboration services to Living Labs, to make them suitable for Open Innovation and Living labs environments.

Workshop Programme:

• 09:00 – Welcome, workshop objectives and agenda, workshop organisers
• 09:20 - Enterprise Collaboration and Interoperability Services for Open Innovation: The COIN Project, Sergio Gusmeroli, TXT
• 09:40 - Living Labs in Open Innovation: The functional Regions, Marco Conte, ESoCE-NET
• 10:00 - Methodologies for Involving Users into Research & Innovation: The Living Lab Way, Marc Pallot, MPC

• 10:30 – Coffee break
• 11:00 - Living Labs as an Open Innovation Ecosystem: Needs & Requirements for Collaboration Services, invited LL presentations (i.e. Health, Media, Energy, Engineering)
  • eHealth Living Lab Salud, Bidatzi Marin Bastida, IAVANTE Foundation, Malaga
  • ICT Usage Living Labs, Brigitte Trousse & Bernard Senach, INRIA, Sophia Antipolis
  • Quartier Numérique & Greater Paris Living Labs, Julien Valéro, Silicon Sentier, Paris

• 12:30 – Lunch break
• 14:30 – User Centred Collaborative Product Development Services, Alberto Olmo, ISOIN and Drago Trebežnik, Josef Stefan Institute

• 15:30 - Coffee break
• 16:00 – Experimentation of the Ideas Market on COIN Platform Services
• 16:30 – Overview and discussion of the resulting figures
• 17:00 – Conclusion
• 17:30 – End of the workshop

Collaborative Web Environments Workshop

Supported by the ECOSPACE project

As the Web evolves, new and improved ways of collaborating are emerging; in business, in education, and socially. This workshop aims to bring together designers, practitioners and researchers who share an interest in the study and design of Collaborative Web Environments. The list of possible topics is shown below:

• Web architectures and application frameworks
• Design of collaborative systems
• Interoperability of data
• Patterns for collaboration environments and collaborative processes
• Coordination in collaborative environments
• Social network mining in collaborative environments
• Access control in collaborative environments
• Identification of expertise/skill-set in collaborative environments
• Standardisation of basic collaborative services
• Ontologies and vocabularies for collaborative spaces
• Evaluation methodologies for collaborative tools and environments
• Applications based on collaborative Web services
• Social Web applications (virtual communities, community networks etc.)
• Mobile Web applications
• Awareness in collaborative systems
• Visualization of collaborative structures and processes
• Cultural aspects and human factors in collaboration
• Testing and evaluation of collaborative Web environments; experiences from living labs
• Collaboration technologies in industry and business

The half-day workshop will be structured as follows: welcome and introduction of organizers, poster ‘madness’ where participants introduce themselves and briefly advertise their work, coffee break and poster session with mingling to encourage small group discussions, discussions in groups, wrap up. Workshop proceedings will be published online.

We kindly invite you to attend the conference and the CWE workshop, and look forward to seeing you at ICE 2009 this June!

[edit] FIRE and LIVINGLABS 2009, Luleå, Sweden, July 1-2 2009

1-2 July 2009 in Luleå, Sweden starts it's EU Presidency agenda by bringing together scientists, business-people, policy makers and innovators in the area of Future Internet Research and Experimentation (FIRE) and Open Live Laboratories for User-involvement in R&D (Living Labs) - Two areas where the emerging new evolution principles for digital information technology and services are embraced and brought forward.

Go to the FIRE and LIVINGLABS event web-site and check out the updated event programmes (day 1 and 2) and note that the deadline for registration is extended to 24 June 2009.

Get updated on important topics, make new contacts, discuss new opportunities, enjoy the food&entertainment, meet old and new friends and take the opportunity to disucss with our KEY-NOTES:

• Åsa Torstensson, Minister for Communications, Government Offices of Sweden
• Jan Färjh, Vice President and head of Ericsson Research
• Eva Lindencrona, Deputy Director-General, Swedish Governmental Agency for Innovation Systems VINNOVA
• Antti Peltomäki, Deputy Director-General, Information Society and Media, European Commission
• Suzanne Iacono, Science Advisor, National Science Foundation, USA
• Akio Motai, Chairman of R&D Promotion Committee, Yokosuka Research Park, Japan
• Erik Höglund, Vice Chancellor, Luleå University of Technology

... and more ...

Come to Luleå, the beautiful and friendly capital of the County of Norrbotten, the land of the mid-night sun.

[edit] Background

The Internet is much more than a communication system. New and unexpected Internet-enabled applications and services make tremendous use of emerging technologies and at the same time shape new requirements for future ones. At a global level, the Internet is becoming more and more the backbone of modern economy and society, to the point where new generations from industrialized countries cannot even conceive a world without Internet. Due to these multiple interactions, the Internet has become a complex system, a living and evolving entity, where any technological development affecting its future may have multifaceted and even unexpected consequences, at any technological, social or economic level. Therefore, new proposals for Internet architectures, protocols and services should not be limited to paperwork, as they need early experimentation and testing in large-scale environments, even though some of these ideas might be implemented only in the long-term – this is what Future Internet research and experimentation FIRE is about!.

[edit] FIRE - Future Internet Research

FIRE Future Internet Research and Experimentation is an initiative under the ICT theme of EU Framework Programme 7. Projects selected under Call 2 - Objective 1.6 “New Paradigms and Experimental Facilities” are the first step under FP7 towards building FIRE. The initiative has two related dimensions: Building a European Experimental Facility for Future Internet research, and supporting experimentally-driven advanced research, which defines the challenges for and takes advantage of the dynamically evolving facility. The FIREworks is a FP7 Support Action from the FIRE Objective 1.6 that coordinates and supports interworking of testbed activities in Europe and their respective connections outside of Europe, mainly to North America and Far East.

[edit] Living Labs

Living Labs are open innovation environments in real-life settings, in which user-driven innovation is fully integrated within the co-creation process of new services, products and societal infrastructures. In recent years, Living Labs have become a powerful instrument for effectively involving the user at all stages of the research, development and innovation process. Living Lab is normally a very local set-up; an area or a region is establishing a living lab to foster its development and to improve the life of its citizens. However, since Living Lab is about people together for better tomorrow, scaling up the concept and jointly benefiting from the power of co-creation is fundamental for the philosophy to be put in action. Hence the European Network of Living Labs, ENoLL. Despite the idea of Living labs born in US, the network is a European concept, which now after the third wave of ENoLL members grew global and even beyond European borders.

[edit] ECSCW'09, Vienna, Austria, September 7-11 2009

[edit] CSCW 2010, Savannah, Georgia, USA, February 6-10 2010

---

Published by:

ECOSPACE Newsletter is published by: ECOSPACE Consortium

Editorial Coordinator: Marc Pallot, ESoCE-NET

Editorial Board: Wolfgang Prinz, Antonio Marquès, Marc Pallot

ECOSPACE Newsletter is supported by: European Commission FP6-IST-5 35208, ECOSPACE Integrated Project