ECOSPACE Newsletter No 6
From AMI@Work Communities Wiki
Contents |
printable version of Newsletter No 6 (PDF)
[edit] Editor’s Corner
Following the first special issue of the ECOSPACE Newsletter which was dedicated to the topic of Living Lab, here is the second special issue dedicated to the topic of interoperability within Collaborative Environments. ECOSPACE project is very active in the Open Collaborative Architecture Working Group (OCA WG) where other Collaborative Environments Integrated Projects (IP)are also involved, such as Collaboration@Rural, CoSpaces, ECOSPACE, and LABORANOVA. OCA is a forum where researchers and engineers from involved IP and STREPS projects discuss, share and compare Collaborative Environment platforms, in order to elaborate architecture and design recommendations.
Recently, an OCA workshop took place during a specific track dedicated to Collaborative Environments hosted by the ICE'2008 conference in Lisbon, from 23 to 25 June 2008. At this workshop, the OCA-WG chair token was passed to the ECOSPACE project. Further to this, a specific demonstration on shared workspaces interworking was organised by the ECOSPACE project in order to show how Composite Collaborative Services (CoCoS) with the SIOC semantic layer (original meaning is Semantically-Interlinked Online Communities but nowadays ECOSPACE is extending it as networking objects with people forming groups and communities as a kind of social communication protocol) have enabled the use of external shared folders almost as simple as using internal folders. This is a major achievement as it means that tomorrow everyone will get access to external shared folders from his favourite shared workspace tool or collaborative environment whatever are the other external shared workspace tools used by collaboration partners.
Consequently, inside this special issue you will find several articles related to this topic of interoperability within Collaborative Environments. A first article is introducing another related major issue about sharing objects which is named "Distributed Document Context". The following article is presenting the implementation of shared workspaces interworking based on the demonstration involving BSCW and Business Collaborator as shared workspace tools. A third article is introducing SIOC and the role of a semantic layer within the interoperability context.
Last but not least, there is also an article reporting about the ICE'2008 conference and the CWE track where about 40 scientific papers were presented by all IP and STREP projects focusing on collaborative environments during various dedicated sessions. It is simply demonstrating how much knowledge on this topic is already developed by this vibrant research community and available as all those papers, beside the fact that they have been publised into the ICE'2008 conference proceedings (about an impressive 1200 pages this year), will be available for free on the related website
As usually, this issue is closing with an announcement of up-coming relevant events such as ICT'2008, to be held in Lyon during the French EU presidency, from 25 to 27 November 2008, where stands and networking sessions devoted to both Collaborative Environments and Living Labs have been submitted. Don't miss this unique opportunity to see the latest developments in the areas of Collaborative Environments Interoperability and Living Labs!
See you all at the ICT'08 conference in Lyon!
[edit] Coordinator's Message
We all know the problem of learning and managing different applications for different communication and cooperation patterns. It becomes even worse when we need to learn a new cooperation system for each new cooperation process in which we are involved.
Imagine that your organization is using MS-Sharepoint as its cooperation platform and that you start a joint project with another organization that is using BSCW. What are your choices? You can try to convince your IT-department to create accounts for your external cooperation partners, or can start to learn how to use BSCW. But what actually will happen is that you use email to manage your cooperation project.
Wouldn’t it be more efficient if you could continue using MS-Sharepoint and if your partners could continue using BSCW, while both systems are able to interoperate and to exchange data? Within Ecospace we are developing a reference architecture and communication protocols that enable such a scenario. Within this issue you’ll learn about SIOC which enables us to exchange information between different shared workspace platforms such as BSCW, Business Collaborator, VE-Forum, and SAP Netweaver.
An interoperability demonstration between BSCW and Business Collaborator shared workspace platforms was presented at the ICE 2008 conference in June.
During the recent months, ECOSPACE has been participating to the following events:
- 20.-23. May 2008, COOP 2008 - 8th International Conference on the Design of Cooperative Systems, Carry-le-Rouet, France
- 23.-25. June 2008, ICE'2008, Lisbon, Portugal
- 4.-5. July 2008, Berlin Research Methods Festival, Berlin, Germany
ECOSPACE has (co-)organised / supported the following events:
- 23.-25. June 2008, CWE 2008, Lisbon, Portugal
- 24. June 2008, Collaborative Web Environments Special Session, Lisbon, Portugal
- 25. June 2008, ECOSPACE Interoperability Demonstrations Demo Session, Lisbon, Portugal
[edit] Distributed Document Context (D2C)
[edit] Introduction
One of the foundations of cooperative work is the exchange of documents and files between groups or cooperation-partners. Email, Instant-Messaging, Document Management Systems and Shared Workspaces are just a few of manifold methods and tools for file exchange between two or more persons. Cooperation requires the transfer of files (e.g. by email) between two or more systems. Every transfer of a document implies almost the complete loss of context- and meta-information, such as history-data that is bound to the document and cannot be reconstructed automatically by the remote cooperation-partner. Regardless of the former metadata and context of a document, each time a document crosses a system-border (e.g. a cooperative document management system) it leads to the consequence that a new document-context has to be established by the receiving cooperation partner. With focus on cooperative working environments (CWE), the following will introduce a concept of a general architecture for a persistent binding between distributed contexts, the related metadata and documents in cooperative working-scenarios.
[edit] Concept of a Distributed Document Context
The conceptual design of our approach requires analyzing the main components of a distributed document context, which are documents on the one hand side and systems that provide information about these documents on the other. Questions like how a persistent binding of a document to a dynamic context can be achieved and how a dynamic context can be constructed and represent in an applicable way, have to be considered and discussed. The following section will introduce the concept of a distributed document-context. Besides a general discussion how to bind metadata to a particular document, an extensible system for context-retrieval will be introduced.
[edit] Bind Metadata to Document
An analysis of potential approaches that enable a persistent relation between context (metadata) and documents yields to three different and general methods that are summarized in the following list:
- a) Outside-Metadata. The document is described from outside. Common file-systems like NTFS, HFS+, etc. fit into this category, because the metadata is stored outside the document and is strongly connected to the underlying file-system. This strong connection will decouple file and metadata immediately after leaving the system-boundary.
- b) Wrapped-Metadata. The document is wrapped by a metadata-layer. Archive-based file-types becoming more popular (like Office Open XML [1] or OpenDocument [2]) and allow the arrangement of different data and files inside a single archive. Regardless of the underlying system, the usage of archives enables a strong linkage between metadata and document.
- c) Inside-Metadata. The document contains all metadata inside the own file-structure. This approach integrates all metadata as own part of a particular file and requires for every file-type (especially binary ones) an own procedure for storing this information at a special point inside the file.
The requirement for a system-independent document-context requires the availability of metadata at all times and all places. Further it is necessary to standardize the metadata for a wide adoption and usage of the context information. As a general requirement the ECOSPACE-Project is a good environment to standardize metadata that is provided by systems and the assembled context-information of a document.
In respect to those requirements, an analysis of the above mentioned methods yield to a mixed approach that uses outside- and inside-metadata in a special way(*) . Instead of providing all related metadata in the document itself, a document will just store a reference (inside-metadata) to a service that provides detailed context-information (outside-metadata). In relation to our concept, the inside-metadata is represented by a ContextTag and the outside-metadata as a ContextScope.
(*) Although wrapped-metadata is comparable to the approach of inside-metadata, the overall-usage of archive-filetypes is (up to now) to little in respect to the usage of flat file-types and therefore considered as secondary issue.
[edit] Context Tag
To enable the document-context in a document, the file is marked with a ContextTag. A ContextTag is an XML-Structure that is integrated inside a file. This XML-Structure will give information about the following things:
- 1. A single document-id. This id represents a unique identifier to avoid ambiguous context in a single document.
- 2. One or more ContextScopes. A ContextScope points to a particular context of a document. The concept of ContextScope will be discussed in detail later.
The usage of the ContextTag outlines the mixed approach of inside- and outside metadata mentioned above. In contrast to the XMP-Approach [3] where all metadata is written directly into the file, only a minimal set of information will be integrated. This ContextTag (a set of references) points to different contexts and decouples the metadata from the document, without breaking the relation.
[edit] Context Scope
A ContextTag inside a document points to one or more ContextScopes. These scopes consist of different systems that are able to provide a valid context of a given document-id. These systems are divided into 1st and 2nd Level ContextProvider and provide different types of contexts. "Document Management Systems", like the BSCW-System [4] provides a 1st level context (see green block, Figure 2), because context information about Users, Concepts, Resources and States, are usual available in such systems. 2nd level ContextProvider extend the base-context (see yellow block, Figure 2), by enriching the information of the initial context.
In the ECOSPACE-Project especially systems like Post-@ extend the user-context by providing real-time information about availability and presence of other user in a cooperative-working- environment.
A ContextTag inside a document can address multiple ContextScopes that are autonomous to each other. Thus a document can have two or more different contexts at once, without affecting each other. The ContextBroker, as the key element in the context-system, is the link between a ContextScope and a consumer-application like an office-plug-in that queries for author-information. The broker manages the retrieval of single context-information and offers representations in form of webservices and user-interfaces of a special context. Both ContextBroker and ContextScope are aware of each other, so that on the one hand side, the broker is able to identify the systems that are part of the scope and on the other side each system is able to identify what context it belongs to.
Especially the last point is of particular importance, since a 1st level ContextProvider will initiate the integration of the ContextTag into the document. Fig. 2 discusses the scenario of uploading a document to a "document management system" such as BSCW. The formal procedure is to check, whether the document is already part of the ContextScope or not. This is achieved either by submitting the whole document to the ContextBroker or, based on the system-capabilities to examine a document, just by submitting the document-id. The ContextBroker will verify a ContextTag, returns available context-information and if provided the newly tagged document. Based on the information of the ContextBroker any ContextProvider can bind system- and metadata to the corresponding document and/or document-id. A ContextProvider like BSCW needs to make webservices available to enable the retrieval of metadata by submitting the unique document-id. The storage of the metadata is controlled by the service/provider itself and can be implemented freely. In the case of BSCW, the always available event-list of a document can act as repository for metadata. A scenario of the context-broker usage can be found here <link to screencast>
[edit] Functionalities
This section outline some of the currently developed functionalities of the D2C-Architecture.
[edit] Context-based Messaging
The ContextBroker is the connector between the document on the one side and different systems, which provide information of this document on the other side. Based on this role of a mediator between document and system the ContextBroker is able to collect information about the involvement of a user to a certain context or more specific to a certain document. This information can be used for several purposes, which will be described here. A new functionality of the D2C-System is the context-based messaging service, which allows a member of a context to contact related persons of a context directly without specifying who has to receive a certain message. The list of recipients is determined by the frequency of access or involvement of persons to a document or a set of documents, which relieves the sending person from organizing the context manually. Currently the system recognizes email as the main messaging platform, but other forms of communication like instant-messaging will be considered, too. In order to keep a persistent connection between the sending context and the email, the messaging service adds a custom header to the email, which provides the URL of the original context.
Based on this information it is possible to create custom filters in email-clients sorting incoming messages by context. To support the user in retrieving the related context we developed a special Plug-In for Microsoft Outlook which is able to scan the header information of an email and provide – if available - a direct access to the related context. The general concept in Fig. 3 shows the identification and contact of all involved users, Fig. 2 shows a screenshot of the new developed Plug-In for context-recognition. This Plug-In detects the tag inside the email-header and offers more context-related functions to the user. Currently the users can inspect the context, by clicking at the context-button inside the email-frame (see bottom-right).
[edit] Retrieval of Related Persons and Documents
The ContextBroker is closely related to the user-management service of a remote-system like BSCW and tracks all events related to a given object (e.g. a document) which is a part of a certain context. Based on this information the ContextBroker is able to give new users information about the related context, he or she is part of without an active interaction in this context. Fig. 3 shows the splash page, after a user has provided the login-credentials. This splash-page gives information about two different kinds of contexts. The above list gives information about the actively created contexts of the user and act as a quick reference to access the specific context.
The list below provides information about context where the currently logged in user has an involvement, based on accessed documents of the remote-system. In the particular case in Fig. 3 the user logged in user “vonrueden” is the active-creator of the “Deliverable 4.5” Context and additionally involved in the Context “Deliverable for M24”. The ContextBroker can reason this information by comparing the access of documents by user “vonrueden” and the available contexts which reference these documents. In the example “Deliverable for M24” references a document of the context “Deliverable 4.5”, which was accessed by user “vonrueden”.
This reasoning enables a logged in user to retrieve related context and related users with similar working-contexts, which implies the possibility in finding related documents to the current working-situation.
[edit] Conclusion
There are a few approaches that are related to our concept. Adobes Extensible Metadata Platform (XMP) [3] has a strong relation to the approach of integrating metadata inside a document. The light-weighted approach in our concept enables the use of one document that relates to multiple contexts without having (non-intended) interrelations. Although the "Graffiti-Framework" rather addresses a strong connection between a file-system and a layer for distributed metadata, there are similarities to our approach, since they use the checksum of files to identify and relate it to distributed metadata-repositories [5].
We believe that the presented concept outlines a new approach for distributed document-contexts that can bind a context persistent to a document, without a static relation to this information. Moreover the context-information is part of a whole scope and is therefore an assembly of dynamic and variable systems that provide specialized context-information for a particular document within a cooperative working environment.
[edit] References
1. Ngo, Tom. OFFICE OPEN XML OVERVIEW. [Online] [Cited: March 13, 2007.] http://www.ecma-international.org/news/TC45_current_work/OpenXML White Paper.pdf.
2. OASIS. OASIS Open Office Specification. [Online] Feburary 1, 2007. [Cited: March 14, 2007.] http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html.
3. Adobe XMP: Adding intelligence to media. [Online] [Cited: March 13, 2007.] http://www.adobe.com/products/xmp/overview.html.
4. Appelt, Wolfgang. WWW Based Collaboration with the BSCW System. Lecture Notes in Computer Science. SOFSEM'99, Milovy, Czech Republic : Springer, 1999, pp. 66-78.
5. Bobb, Nikhil, Eads, Damian and Storer, Mark W. et al. Proceedings of the 7th International Workshop on Distributed Data and Structures (WDAS 2006),. January 2006.
[edit] Towards Shared Workspace Interoperability
[edit] Introduction
Nowadays, almost everyone use shared workspaces for sharing a wide range of objects from simple photos and images up to more complex documents. Such Shared Workspace (SW) platforms support a wide variety of collaboration functionalities such as document management, versioning, project blogging, shared todo lists or calendars just to cite a few. In many organisations SW platforms providing these functionalities like MS-Sharepoint, BSCW, Business Collaborator, or Netweaver are already successfully implemented.
However, cooperation processes occur not only within a single organisation but more and more between various organisations that are involved in common projects. In this kind of situation a strategy of using a single SW platform cannot be applied for the following reasons:
- Cooperating organisations have already different shared workspace technologies in use. Furthermore, it often happens that different departments or divisions within a single big organisation use different shared workspace platforms.
- Access policies or licenses restrictions make it impossible to open the local shared workspace platform to external users.
- Partners are unable to agree on which SW platform to select.
- Users are reluctant to learn another SW platform while they have already one in use.
For users who are involved in several cross-organisational cooperation projects, this strategy of using one SW platform per project would imply that they have to learn as many different cooperation platforms as selected by the projects they are involved in. However, users are absolutely not motivated to invest much time in learning different tools that provide almost the same services, as they feel like wasting their time. This kind of particular situation is explaining why often users turn back to the most simple cooperation tool they know the best such as email attachment to "share" a document (though, in this case it is more about "sending a document" than really "sharing a document"). For sure, as the emailing protocol is a standard it gives the freedom to organisations and users to select the email server and client they prefer which is a very good illustration of the power of standardisation.
Consequently, it would be really great if SW platforms could have a good level of interoperability enabling users to access posted objects on other SW platforms from their own SW client whatever is the SW server.
[edit] Shared workspace interoperability
Many cooperation processes such as inter-organisational projects can be supported by the provision of a SW platform that enables involved participants to create a single project space for sharing project documents, blogs, calendars or todo lists. Interoperability between SW platforms is addressed by the ECOSPACE CWE reference architecture. The most important components in this CWE reference architecture are the identification of basic services for each collaboration service and the definition of an exchange/communication protocol enabling the representation and interpretation of the workspace object meta-data from different SW platforms. Based on these developments, an interoperability framework for SW platform has been developed that applies the below described approach.
Each SW application implements standardised basic services enabling:
- Access (read/write) to workspace objects,
- Retrieval of the workspace organisation (i.e. the folder structure) and user information;
- Exchange of objects' meta-data through the use of the SIOC format (see the following article for a detailled explanation about SIOC).
According to this interoperability approach, each SW service is now offering the same web services to access and modify objects' meta-data. Access to this information is provided by new interface components in each shared workspace user interface. These components provide access to the workspaces of remote systems in a transparent way and in the same look and feel as if they were local workspaces while they are external.
The following use case is an illustration of interoperability among 3 diferent Shared Workspace platforms (BSCW, Business Collaborator and SharePoint).
Three companies (see Figure 1) are starting a joint project and they wish to use their own available SW platform (BSCW, Business Collaborator or SharePoint) for both their own developed objects and joint developed objects. Company A uses BSCW, company B uses Business Collaborator and Company C uses SharePoint. In a first step, each company creates a project workspace in their own SW platform. Afterwards, they reciprocally invite participants from the cooperating organisations as external users to their own project workspace. Finally, they exchange the web service address (the access path to their local workspace). The way this access path is used in the respective SW platform depends on the local implementation. The implementation for BSCW is described below.
A user in BSCW creates a new folder which is a "shadow" folder type by providing the access path to the external folder, located into another SW platform, as well as the authentication information to access the remote SW platform. This shadow folder is created as a "sub-folder" of the local project workspace which is the "top" folder. When a user opens this shadow folder then a special background color indicates that the information provided in this folder is not stored into the local SW platform but accessed from a remote SW server. Furthermore, the shadow folder provides the same look and feel that users are used to have on their own SW platform. It means that users can access the external objects information that are actually stored into another SW platform in a very transparent way without to have to learn other SW platforms.
Obviously the functionalities offered by this shadow folder type are limited to the necessary set of services required to access and modify objects. In this implementation example, the current limitation is that other advanced fonctionalities provided by some SW platforms (i.e. rating, annotating, tagging) cannot be used. Therefore, future work will address this issue by the development of a more advanced protocol that enables also the exchange of service capabilities between the different SW platforms.
[edit] An open reference architecture as a means to widgetise your application
Current CWE solutions are very often still monolithic entities as they provide, for example, a user interface that can be adapted to the user’s needs but that cannot be completely reconfigured or re-assembled by the user. This is in contrast to the self-service and customisation mentality of the users who are used to configure their working environment by downloading and installing the appropriate tools (at least in their private setting).
With the aim of ECOSPACE to enable interoperability through the design of a CWE reference architecture, including the definition of basic cooperation services, we can open the door towards an individually configurable CWE. This is achieved by realising a set of visualisation and interaction widgets to support basic collaboration services. It means that users can configure their CWE by the selection of those collaboration services that are most appropriate for their specific tasks. This motivation has lead to the development of a set of CWE widgets that correspond to basic collaboration services.
Figure 2 is presenting, in the top part, a screenshot of BSCW user interface and in the bottom part an example of a widget based application which is a portal page in iGoogle that includes different widgets for basic collaborative services. The green arrows in this figure are illustrating the feed pipes from BSCW type of information to the various widgets.
A user becomes involved in a new activity (i.e. joint project). For this activity he creates a new portal page using iGoogle or Netvibes. In a next step, he drags and drops the most appropriate widgets into the portal page to support the required visualisation and interaction functionalities that he will need, such as widgets for (as shown in Figure 2):
- Looking at the project calendar;
- Browsing the project workspace structure;
- Searching documents;
- Being informed about generated events;
- Being informed about specific participant activities through RSS flow;
Using that portal page and CWE widgets any project participant can personalise his private activity space and information visualusation to support his collaborative activities in accessing different services of the Shared Workspace platform (in this case BSCW). For sure those CWE widgets could be feeded by other SW platforms (i.e. Business Collaborator, SharePoint, NetWeaver) assuming they have a compatible meta-data format and Web-Services API. Even, one can think about universal CWE widgets having their feed pipes in a neutral format like using the SIOC format where SW platforms publish their meta-data (i.e. using RSS flow mechanism) and widgets which have subscribed to the specific RSS flow then receive the associated meta-data.
[edit] CWE Interoperability demonstration
[edit] CWE Interoperability Architecture
The CWE Interoperability Architecture provides a middleware that enables multiple, independent CWE platforms and third-party applications to share and correlate data, based on SIOC.
The CWE Interoperability Architecture. Firstly CWE data is exported as SIOC data. Then the SIOC data is imported by other CWEs or by third-party applications. Finally the SIOC data is utilized accordingly.
The CWE Interoperability Architecture based on SIOC necessitate 4 elements (see Figure 3):
- Concept Mapping: The first stage of translating proprietary CWE data into SIOC RDF data involves mapping concepts that exist in a specific CWE domain to concepts in the SIOC ontology.
- SIOC Exporter: Based on the conceptual mappings, SIOC exporters translate platform-specific data into SIOC RDF data.
- Workspace Synchronization Web Service: The workspace synchronization web service exposes the content of a CWE workspace as SIOC data to external systems. CWE items, such as documents and folders, may be accessed, added, deleted, renamed, or replaced remotely via these services.
- SIOC Importer/Viewer: Importing remote SIOC data into a CWE allows a user to view data from a remote SIOC RDF source as if it was a local folder in the CWE. The SIOC Importer/Viewer reverts the SIOC data into CWE platform-specific data, based on the conceptual mappings.
[edit] Shared Workspaces InterWorking
The scope of this CWE interoperability demonstration, which was lively presented during the ICE'2008 conference, is restricted to interoperability among 2 different SW platforms: Basic Services for Cooperative Work (in short BSCW) and Business Collaborator (in short BC). The demonstration was entitled "Shared Workspaces InterWorking" to make sure the audience will understand the scope of the interoperability scenario which is the following:
Two Companies have been contracted to produce a brochure, entitled 'European Cities', consisting into a promotional brochure about interesting site seeing activities over Europe. Companies are, on the one hand, Turners Photography Studio, which is a photography studio where employes use the BC platform and on the other hand Baker Publication Design, which is a publication design studio specialised in designing brochures where employes use the BSCW platform.
The photographers of Turners travel to Prague, Valencia, Rome, and Paris, taking photos and uploading them to a BC folder as they go. This BC Folder is connected as a "Shadow" Folder to the BCSW platform of Baker. Via the Shadow Folder, Baker's publisher can access the photos and incorporate them immediately into the brochure. For a final review, the brochure is uploaded to a BSCW folder, which is connected as a "Semantic" Folder in Turners BC platform where photographers may view the finished prototype of the brochure.
Note: In reading the above text, one may notice that external or remote folders residing on another SW platform are named differently in BSCW, as being "Shadow" Folders, than in BC, as being "Semantic" Folders. For sure there are plenty of other possible names like "foreign" folders or "external" folders in order to make more explicit that this type of folder is residing on other SW platforms than the one in use internally.
Both Turners and Baker's teams have created a project space named "European Cities" on their respective SW platform as shown in Figure 4 (top screenshot is illustrating BC user interface and bottom one is illustrating BSCW user interface). Turners participants have created 3 folders within this project space, the one named "Turners Photos" is a shared folder, the one named "unused photos" is a private folder and the third one named "Baker's Brochure" is a semantic folder (meaning that it is a foreign folder) pointing to Baker's BSCW platform where the real folder reside.
Baker's participants are invited into the shared folder "Turners Photos" as members in order to let them access content information. Figure 4 is illustrating this link through a magenta arrow from the BC shared folder to the BSCW shadow folder (corresponding folder icon is yellow coloured). It means that when Baker's participants will open this shadow folder then they will see the content of the shared folder "Turners Photos" residing on BC.
Baker's participants have created 3 folders as well within their own project space residing on BSCW. The first one named "Baker's Brochure" is a shared folder, the second one named "text input" is a private folder while the third one named "Turners Photos" is a shadow folder (meaning that it is a foreign folder) pointing to Turners' BC platform where the real folder reside.
Turners' participants are invited into the shared folder "Baker's Brochure" as members in order to let them access content information. Figure 4 is illustrating this link through a dark blue arrow from the BSCW shared folder to the BC semantic folder (corresponding folder icon is including a blue triple image). It means that when Turners' participants will open this semantic folder then they will see the content of the shared folder "Baker's Brochure" residing on BSCW.
Figure 5 is presenting, on his top part, the content of the shared folder "Baker's Brochure" residing on BSCW and on his bottom part the resulting virtual content of the corresponding semantic folder residing on BC. The big arrow in between is explaining that all objects' metadata (i.e. object type, object name, size, creation date, events, creator) are transfered from BSCW to BC through a specific web service which use the SIOC format.
Figure 6 is presenting, on his top part, the content of the shared folder "Turners' Photo" residing on BC and on his bottom part the resulting virtual content of the corresponding shadow folder residing on BSCW. The big arrow in between is the reverse situation as all objects' metadata (i.e. object type, object name, size, creation date, events, creator) are transfered from BC to BSCW through a specific web service which use the SIOC format.
It means that Turners' participants can open and browse a foreign BSCW folder without to have to learn how to use BSCW as they are using their normal BC user interface. For sure it is exactely the reverse situation when Baker's participants are opening and browsing a foreign BC folder, which means that they don't need to learn how to use BC. In conclusion, one may state that it is as simple as opening and reading an email on your favourite emailing client while this email was sent by someone using not necessarily the same emailing tool.
This example could be extended with a third partner using another SW platform such as NetWeaver or SharePoint. This third partner could be in charge to provide short videos of different site seeing experiences that are uploaded into a specific shared folder on their SW platform. Consequently, there will be not anymore one foreign folder for each partner but two or another scenario is that one partner is in charge of the final integration and only this one will need to have two foreign folders where to get access to photos and short videos.
[edit] SIOC, the Social Communication Protocol
[edit] Introduction
The main driver for the development of CWE platforms, such as BSCW, BC, SAP NetWeaver, Microsoft SharePoint, VEA, and Lotus Notes, has been the need for interoperability amongst a large number of independent applications that were originally designed to support specific business tasks, e.g. project and document management applications, calendars, forums, mailing lists, etc. With the introduction of CWE platforms, these interoperability problems were adequately addressed internally. However, at the inter-organisational level, problems remain. CWE platforms remain informational silos as they are legacy and isolated systems that cannot communicate with the rest of the world. From an organisational perspective, this creates insurmountable barriers to the exchange of information with peer organisations, while from the perspective of the single user, it creates a situation whereby information that may exist in separate platforms cannot be combined and must be collected and processed manually.
Take the case of an e-professional (e.g. an engineer, lawyer, or researcher) who works concurrently on a number of projects that are supported by different CWE platforms. (S)he may wish to find a comprehensive list of all documents that have been uploaded during the past week in the projects that (s)he is involved in. Or (s)he may need to identify resources on all platforms that are categorised under a common theme. In ECOSPACE, it is proposed to use the SIOC ontology to address this interoperability problem. SIOC has been developed to semantically interlink online community sites, such as blogs, forums and mailing lists. Due to the similarities between online community sites and CWEs, and the similar integration issues experienced by both communities, the SIOC ontology has been adopted in the ECOSPACE project to provide the basis for multi-platform integration and to allow cross-project querying to semantically-interlinked information.
[edit] What is SIOC?
The SIOC initiative (Semantically-Interlinked Online Communities) is aimed at connecting online community sites, such as blogs, forums, wikis, and mailing lists. It consists of the SIOC ontology, an open-standard machine readable format for expressing the information contained both explicitly and implicitly in internet discussion methods; SIOC tools for leveraging SIOC data, e.g. metadata exporters, and storage and browsing systems; and the SIOC community, an expanding network of people using SIOC.
The ontology is expressed in RDF and consists of the SIOC Core ontology (consisting of 11 concepts and 53 properties) and two ontology modules: SIOC Types and SIOC Services. The SIOC Core ontology defines the main concepts and properties required to describe information from online communities on the Semantic Web. The main terms in the SIOC Core ontology are shown in Figure 1.
[edit] Use of SIOC in ECOSPACE
Within the ECOSPACE project, SIOC is used in two ways: i. CWE platform-specific data exported as SIOC data ii. SIOC data imported by a third-party application or a CWE and internally viewed as host data
[edit] CWE platform-specific data exported as SIOC data
In order to interoperate with outside systems, a CWE must present its data in a semantically interpretable format. The SIOC ontology can be used to describe CWE data generically. The first stage of translating proprietary CWE data into SIOC RDF data involves mapping concepts that exist in a specific CWE domain to concepts in the SIOC ontology (e.g. user, post, and document). Then, based on these conceptual mappings, SIOC exporters are developed to annotate the internal CWE data and export it as SIOC RDF data. Table 1 shows a sample of concept mappings from BSCW concepts and BC concepts to SIOC concepts. The SIOC Types module is used to define more specific subclasses of the SIOC Core concepts, which are necessary to fully capture all CWE concepts. The Semantic Web advocates the reuse of existing ontologies and vocabularies, leading to better data interoperability. The SIOC ontology follows this practice by reusing concepts from existing ontologies, such as the FOAF and Annotea vocabularies.
Namespace:
Using conceptual mapping, both BSCW and BC have developed SIOC exporters to export their platform-specific data as SIOC RDF data. These exporters allow remote websites, applications, or other CWEs to request data via HTTP. Alternatively, the exported SIOC RDF data may be made available to the outside world via a web service. BSCW has developed a web service, which exposes the contents of a BSCW folder as SIOC data. This data can be accessed by invoking an operation in the web service. Also, documents may be added and documents and folders deleted from the CWE via the web service. The WSDL file is available here. ECOSPACE partners such as BC, SAP, and VEA plan to implement a web service, similar to that of BSCW.
[edit] SIOC data imported by a third-party application or a CWE
The exported data, expressed in terms of the SIOC ontology concepts, may be merged and correlated with SIOC data originating in another CWE platform. Data correlation may be accomplished by developing a third-party application, which imports and processes the SIOC data from multiple CWE platforms and uses it according to the application’s desired functionality. An example of this is the SIOC4CWE Explorer, which has been developed by DERI for navigating and querying aggregated SIOC data from heterogeneous CWEs in a unified way (Ning et al, 2007). This provides the user with a single interface to query all the projects (s)he participates in regardless of the project platform. Figure 2 displays a screenshot of the SIOC4CWE Explorer.
Another option for correlating exported data involves a CWE platform importing SIOC data from other CWE platforms directly and integrating it with the CWE’s own data, so that the user views the ‘virtual’ data as ‘local’ data. BC has developed a SIOC Viewer plug-in, which enables a user within the BC platform to browse data from a remote SIOC RDF source, e.g. another CWE platform. The remote data is presented in such a way that it appears to the user that (s)he is browsing a native folder in BC. Figure 3 shows a snapshot of a BC workspace. Semantic folders (imported folders) are distinguished from regular folders by the following icon: BSCW plans to develop a similar SIOC Viewer plug-in to that developed by BC, which will show the content of a remote-workspace inside BSCW.
[edit] Future Work
Following on from the successful usage of SIOC in the ECOSPACE project, the existing work will be extended to facilitate seamless interoperation between all CWE platform providers. Other possible application areas for using SIOC within ECOSPACE will be explored. DERI is currently investigating how widgets may be used to enhance the current adoption of SIOC within ECOSPACE. It plans to provide prototypical widgets based on the functionality provided by the SIOC4CWE Explorer, which will be compatible with the Cyntelix Beamway widget platform, and thus with other widgets in the ECOSPACE project.
[edit] References
- Ning, K., et al. (2007), "A SIOC Enabled Explorer of Shared Workspaces". Workshop on Web 2.0 / Computer Supported Co-operative Work in conjunction with ECSCW 2007. Limerick, Ireland.
[edit] Past Events
[edit] ICE'2008 Lisbon, Portugal, June 23-25 2008, "A New Wave of Innovation in Collaborative Networks"
This year, the 14th ICE Conference was hosted by UNINOVA in Costa da Caparica, Lisbon’s most famous beach area. ICE'2008 was chaired by Ricardo Goncalves, UNINOVA and co-chaired by Marc Pallot and Roberto Bierwolf. It is now becoming a tradition that the conference chair is supported by the previous year's conference chair and that the next year's conference chair starts to learn the process and contribute to it.
An impressive line-up of speakers has been brought together and interactive sessions and workshops benefited of attendees participation. There was still plenty of time for people networking and making new friends during the various social events. In fact that is what Concurrent Enterprising is about! and social events make the whole experience even more enjoyable. In case you have missed this opportunity to join us and enjoy ICE 2008 then book in advance for ICE'2009 which will be held in the Netherlands.
The main theme of the conference was "A New wave of innovation in Collaborative Networks" which has been illustrated by several keynote speakers along the three days. The main idea behind this theme is that, nowadays, the information society is becoming a reality with low cost broadband networks, extended by mobile or wireless networks, allowing seamless connection and use of applications and services (i2010: Annual Information Society Report 2007).
With the in-coming new services, an emerging challenge of collaborative innovation between new types of individual and organizational users who are relying more and more on ICT services and products. The rise of user-created content is opening further perspectives for a more creative and innovative Information Society, in the same way that users exploited open source software and standardization to develop new collaborative processes.
This move is supported by emerging technological trends such as the migration towards very high-speed networks, ubiquitous wireless technologies, web2.0, the Internet of Things, Grids, web-based services, integration of web services in mash-up user interfaces, user-created content and social networking as well as web3.0 integrating the social web and semantic web together into a more collaborative web. These trends will affect both business and working environments, providing new industrial opportunities and new solutions for eBusiness and employment, in a single information space.
For a new wave of innovation, grand challenges highlight new user collaborations, new organisational forms, crossdomain dimensions of interoperability, interoperability technologies being accessible to all organizations and users and the need to take into account the concerns of many small developers and users scattered across Europe and the world. ICE’2008 brought together leading researchers and practitioners from around the world to present their latest findings from research and share practical cases from industry. Authors, workshop and tutorial organizers and participants in general, are largely contributed to the shaping of the debate, in the scope of a new wave of innovation in collaborative networks and a single information space and therefore to the success of the conference.
Regarding the conference programme this year, traditionaly, the first day was organised into five parallel tracks of twelve papers presented into three sequential 1.5 hour sessions for each track from 11H00 to 17H30. Furthermore, several papers were selected for a Poster presentation during the breaks. Papers' presentations provided an insight to the latest findings from R&D in CE, Collaborative Environments, Interoperability & Living Labs.
The opening session started with a warm welcome from the local organiser, UNINOVA and a keynote presentation on MANUFUTURE European Technology Platform by Prof. José Mendonça, INESC Porto, followed by a second keynote presentation on web2.0 and CSCW by Prof. Wolfgang Prinz, Fraunhofer FIT, Collaboration systems research department at Fraunhofer-FIT.
The sessions’ topics were:
- Advances in Concurrent Engineering
- Collaborative Systems
- Collaborative Practice
- Competency Management
- Defining performance indicators for cross-enterprise processes
- Innovation and Living Labs
- Knowledge Engineering and Training
- Networked and Virtual Enterprises
- Product Data and Life-Cycle Management
- Product Data and Services in Concurrent Enterprising
- Training and Education in Concurrent Enterprising
A social event was organised in the evening which started by a boat cruise from costa da Caparica to Lisbon with Portuguese wine tasting on the Tagus river. The boat trip was followed by a Lisbon guided tour sightseeing for discovering the heart of Lisbon, main monuments, views and its culture. Finally participants have enjoyed a dinner at the most typical "arraial" Portuguese style, like a true Portuguese, eating sardinhas, pão com chouriço, bacalhau assado e vinho and accompanied by
the "Banda do Cavalinho".
Day 2 and Day 3 were featuring invited and special sessions as well as workshops, training and demonstrations. Invited and special sessions were dedicated to the presentation of scientific papers while workshops aimed to bring together users and experts in interactive sessions for elaborating on specific topics.
Two Keynote Speakers were closing Day 2:
- Claudio Boer, Chairman of IMS – Intelligent Manufacturing System, Director of ICIMSI
- Angelos Ktenas, Senior Policy Coordinator, Information Society and Media DG, European Commission
The traditional ICE Gala dinner on Tuesday evening started by a visit to the top of the Cristo Rei monument with splendid views over the Tagus river and Lisbon area followed by a cocktail sunset and Gala dinner, provided by the municipality of Almada, concluded by sharing the ICE birthday cake and fireworks!
A keynote Speech was given during the Gala Dinner by Randall Wright, Massachusetts Institute of Technology, MIT Industrial Liaison Program.
Two Keynote Speakers were introducing Day 3:
- Terrence Fernando, Scientific Director of the Think Lab and Director of the Future Workspaces Research Centre (tbc)
- Cristina Martinez, Information Society and Media DG, European Commission
The Collaborative Working Environments (CWE) 2008 event, organised by the ECOSPACE project in collaboration with all CWE projects, was held as a dedicated track during the three days of the ICE'2008 conference.
CWE'08 was gathering together all CWE projects and was featuring sessions with the presentation of about 40 scientific papers, workshops, training and demonstrations.
CWE'08 was also featuring several sessions and workshops dedicated to Living Labs. One of them was organised as an interesting Living Labs feedback report from all CWE IP projects in terms of current status, lessons learned, gaps and research challenges.
The "CWE08 Track Description" is in the AMI wiki pages where special sessions,workshops and demonstrations have a more detailled description.
Here is the link to the full 3 days programme
CWE projects involved in the CWE track:
All scientific papers presented during ICE'08 are available for free in the online ICE'08 conference proceedings
Other ICE conference proceedings
[edit] Up-coming Events
[edit] CSCW'08, San Diego, California, USA, November 8-12 2008
[edit] ICT'08, Lyon, France, November 25-27 2008
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
