OASIS ICOM TC: Proposed Charter

1. Normative Information

1a. Name

OASIS Integrated Collaboration Object Model for Interoperable Collaboration Services (ICOM) Technical Committee

1b. Statement of Purpose

Organizations need to integrate their collaboration services with business applications in order to enable contextual collaboration within an end-to-end business process, such as customer relationship management, procurement, performance, and project management, to improve business efficiencies. Typically these organizations have incrementally deployed a mix of disjoint collaboration tools. As a result, these organizations face technical obstacles and high costs in their quests to integrate these disjoint tools and the data each tool produces. To solve this problem, various collaboration vendors have attempted to unify their platforms in order to build a single collaboration environment which provides full range of collaboration activities. However, these vendor specific platforms still lack a standard model, interface, and protocol to support contextual collaboration within business processes. Without a standard collaboration model that can provide a complete range of collaboration activities, customers, ISVs, and integrators face a difficult challenge to build contextual collaboration environments using service components from multiple vendors.

To remain competitive in the global knowledge communities and market places, the organizations need to enable tomorrow's information workers to collaborate across organizational boundaries with external parties that may be using different collaboration platforms. There will be increasing demands not only for the interoperability of collaboration service components within each integrated collaboration environment but also for interoperability amongst the integrated collaboration environments in the global network communities. Given the large number of components involved in a complete and integrated collaboration environment, we need an integrated object model to eliminate impedances and promote seamless and natural transitions between components. A standard integrated and complete collaboration model is essential also for tools developers, business applications developers, and Web 2.0 applications developers to write to the industry standard model, API, and protocol to interoperate with integrated collaboration environments across different communities.

The purpose of the Integrated Collaboration Object Model for Interoperable Collaboration Services Technical Committee is to specify the normative standards for collaboration objects, along with their attributes, relationships, constraints, and behavior, in an integrated and interoperable collaboration environment. ICOM specification will include the non-normative guidelines (providing architectures or use-case scenarios) for a new workspace-oriented protocol for shared workspaces that supports a full range of collaboration activities, including unified messages, web conferences, forums, presence, calendars, tasks, wikis, blogs, social networks, etc.

ICOM specification can be used as the basis for defining bindings to various languages (Java, C#, WSDL, RDF/OWL). ICOM specification can also provide a framework to render a suite of new and existing protocols, including WebDav, CalDav, IMAP, SMTP, XMPP, etc., protocols, to work as if they are parts of a contiguous protocol.

This work will be carried out through continued refinement and extension of the following contributions [details] by the initial co-proposers:

• Oracle Beehive Object Model (BOM) [1]
• Oracle Beehive Release 1.4 Collaboration Service Interface (CSI) Java docs [2]
• DERI Semantically-Interlinked Online Communities (SIOC) [3]
• NEPOMUK Semantic Layered Architecture (SLA) [4]
• Ecospace Reference Architecture: Basic Collaborative Services (BCS) [8]

Other contributions and changes to the above contributions will be accepted for consideration without any prejudice or restrictions and evaluated based on the technical merit in so far as they conform to this charter. OASIS members with extensive experience and knowledge in these areas are particularly invited to participate.

1c. Scope

The Beehive Object Model (BOM) [1] will be contributed to the TC as the basis for the data model for the integrated collaboration object model.

Beehive Release 1.4 Collaboration Service Interface (CSI) Java docs [2] will be contributed to the TC as the basis for the behavior and operations on the objects of the integrated collaboration object model.

SIOC [3] and NEPOMUK [4] will be contributed to the TC as the basis for refining, enriching, and extending the data model for the integrated collaboration object model.

The Ecospace Reference Architecture for Basic Collaborative Services (BCS) [8] will be contributed to the TC as the basis for refining, enriching, and extending the behavior and operations on the objects of the integrated collaboration object model, and for binding the integrated collaboration object model to the collaboration services.

The scope of the TC's work is to continue further refinement, extension, and finalization of the Input Documents to produce as output specifications, in the language neutral UML 2.0 representation, that standardize the classes, attributes, relationships, constraints, and methods of the areas described below:

1. A data model for the set of objects in the integrated collaboration (IC) environment. A single IC environment can include:

   1. communication artifacts (such as email, instant message, telephony, RSS)
   2. teamwork artifacts (such as project and meeting workspaces, discussion forums, real-time conferences, presence, activities, subscriptions, wikis, and blogs)
   3. content artifacts (such as text and multi-media contents, contextual connections, taxonomies, folksonomies, tags, recommendations, social bookmarking, saved searches)
   4. coordination artifacts (such as address books, calendars, tasks) etc.

2. Describe the persistent identification of the IC objects to support permanent references to the objects that may migrate amongst interoperable IC repositories.

3. Describe the characteristics of the objects in terms of classes, interfaces, attributes, and relationships to other objects.

4. Describe the operations on the objects in the integrated collaboration (IC) environment. The operations include methods to create, delete, move, copy, send, post, version, subscribe, etc., on objects.

5. Describe the service interfaces, including methods and method signatures, which support controller aspects of the IC platform and operations on the IC objects.

6. Describe a minimal unified access control model for the IC objects and operations.

7. Describe the extensibility of the objects by application defined object schema and attribute definitions.

8. Describe the expansiveness of the IC model to span multiple IC platforms from one or more vendors.

9. Describe the openness of the IC model for interoperability across multiple IC platforms from one or more vendors.

10. Describe the viability of the IC model to define the interoperability protocol for developing composite collaboration services for shared workspaces.

Upwards Compatibility

There are no formal requirements for upwards compatibility from the input documents to this TC. This is to ensure that the TC has maximum freedom of action in defining the OASIS standard. However it is recognized that there will be early implementations in the marketplace based upon these input documents and careful consideration must be applied to any change of feature/function that would cause incompatibilities in the OASIS standard at:

• Source Code level
• Compiled Object Code
• UML 2.0 model definitions

At minimum, known enhancements to the input documents that will cause compatibility issues with early implementations in the marketplace will be provided in the specification offering migration guidance.

Test Suite

The definition of Test Suites will be deferred to a different standards effort, which may be done in another TC after the bindings of ICOM to concrete languages and protocols are defined by separate TCs.

Out of Scope

The following is a non-exhaustive list. It is provided only for the sake of clarity.

The TC will not define a mapping of the functions and elements described in the specifications to any programming language, to any particular middleware, nor to specific network transports.

The following items are specifically out of scope of the work of the TC:

1. Details of specific bindings to a programming language or representation. These are handled through separate TCs.

2. Details of specific bindings to the over-the-wire protocols and networks. These are handled through separate TCs.

3. Details of specific transformations and compatibility with existing standards such as WebDav, CalDav, IMAP, SMTP, XMPP, LDAP, etc. These are handled through separate TCs.

4. Details of specific applications of the access control models, including RBAC, DAC, MAC, and label security. These are handled through separate TCs.

1d. Deliverables

The TC has the following deliverable:

An Integrated Collaboration Object Model for Interoperable Collaboration Services (ICOM) Specification and associated UML 2.0 model. The TC will also produce the non-normative matter (which may include models, architectures, and guidelines) for the interoperability protocols to facilitate composite collaboration services for shared workspaces. A Committee Specification is scheduled for completion within eighteen (18) months of the first TC meeting.

Exit Criteria

The TC shall define concrete exit criteria that include at least two independent offerings that implement and are compliant with all normative portions of specifications and demonstrate interoperability and portability as appropriate. Note that these are minimums and that the TC is free to set more stringent criteria.

Maintenance

Once the TC has completed work on a deliverable and it has become an OASIS standard, the TC will enter "maintenance mode" for the deliverable.

The purpose of maintenance mode is to provide minor revisions to previously adopted deliverables to clarify ambiguities, inconsistencies and obvious errors. Maintenance mode is not intended to enhance a deliverable or extend its functionality.

The TC will collect issues raised against the deliverables and periodically process those issues. Issues that request or require new or enhanced functionality shall be marked as enhancement requests and set aside. Issues that result in the clarification or correction of the deliverables shall be processed. The TC shall maintain a list of these adopted clarifications and shall periodically create a new minor revision of the deliverables including these updates.

Periodically, but at least once a year, the TC shall produce and vote upon a new minor revision of the deliverables.

1e. IPR Mode

The TC will operate under the RF on Limited Terms mode under the OASIS IPR Policy.

1f. Anticipated Audience

The anticipated audience for this work includes:

• Vendors offering products designed to support applications using the IC platform
• Vendors offering applications that mashup IC objects from one or more IC repositories and services in the Internet
• Other specification authors that need the IC object model as a reference model
• Software architects and programmers, who design, write, integrate, and deploy applications using the IC object model
• End users implementing solutions that require interoperable, mashup solutions using continuity of references to IC objects that may migrate amongst IC environments, potentially across sites or enterprises for business, social, or technical reasons

1g. Language

The TC shall conduct its proceedings in English.

2. Non-Normative Information Regarding the Startup of the Technical Committee

2a. Related and Similar Work

The ICOM specifications are intended to encompass and improve on a range of models which are part of existing standards and technologies. The existing standards and technologies were developed independently and have created the impedances between the component solutions. New solutions based on ICOM specifications will offer seamless transitions between different functional components and enable the applications that mashup model of different component areas from different interoperable IC providers.

Other existing standards and technologies such as WebDav, CalDav, JSR 170 JCA, IMAP, SMTP, XMPP, etc., can also have relationships to ICOM. The ICOM anticipates interoperability with new or existing applications built on existing protocols and standards by providing mappings and transformations to the existing standards.

The ICOM TC is related to the standards and technologies developed by the OASIS Extensible Resource Identifier (XRI) TC. XRI technology enables the persistent identification of ICOM objects (including enterprises, people, groups, and artifacts) across enterprises, sites, repositories, and applications.

The ICOM TC is related to the standards and technologies developed by the OASIS WS-BPEL Extension for People (BPEL4People) TC. ICOM technology can extend the human tasks, activities, contexts, attachments, and interactions aspects of the Business Process Execution Language.

The ICOM TC is related to the OASIS Content Management Interoperability Services (CMIS) TC. ICOM TC can use CMIS as one of the language or protocol bindings.

Liaisons will be established with other OASIS Technical Committees as determined appropriate by the members of the Technical Committee as work proceeds.

W3C will monitor the OASIS ICOM working group and determine future steps based on the results.

2b. First Meeting

Proposed date, time, and location of first TC meeting:

Date: March 3, 2009
Time: 1:00 PM EST
Duration: 2 hours
Mode: Teleconference
Telephone: Dial-in TBD, along with e-Meeting facilities
Sponsor: Oracle

2c. Ongoing Schedule

Weekly 60 Minute teleconferences sponsored by TBD. Time TBD by the TC.

It is anticipated that the committee will meet face-to-face once every quarter at a date and venue to be decided by the TC, but with a commitment to hold meetings in different regions of the world so as to share the effort of travel.

2d. TC Supporters

The following eligible individuals are in support of this proposal:

• Rafiul Ahad, Oracle, rafiul.ahad@oracle.com
• Eric S. Chan, Oracle, eric-s.chan@oracle.com
• Martin Chapman, Oracle, martin.chapman@oracle.com
• Stefan Decker, DERI, Stefan.decker@deri.org
• Siegfried Handschuh, DERI, Siegfried.handschuh@deri.org
• Tony McCormack, Nortel, tmccorm@nortel.com
• Jeff Mischkinsky, Oracle, jeff.mischkinsky@oracle.com
• Mark Pallot, mpallot@esoce.net
• Wolfgang Prinz, wolfgang.prinz@fit.fraunhofer.de
• Sven Ruby, DERI, sven.ruby@deri.org

2e. TC Convenor

Martin Chapman, Oracle, martin.chapman@oracle.com

2f. OASIS Member Section

Name of Member Section with which this TC is Affiliated:

This TC is standalone and not Affiliated with existing Member Sections.

2g. Anticipated Contributions

Beehive Object Model (BOM) as of August 2008 will be a contribution from Oracle Corporation (see [1]), along with Beehive Release 1.4 Collaboration Service Interface (CSI) Java docs (see [2]), plus any work performed by Oracle Beehive Organization between August 2008 and the start of the work of the ICOM TC.

DERI Semantically-Interlinked Online Communities (SIOC) (see [3]) and NEPOMUK Semantic Layered Architecture (SLA) (see [4]) will be contributions from DERI.

ECOSPACE Composite Collaborative Services (CoCoS) (see [5]), ECOSPACE Distributed Document Context (D2C) (see [6]), ECOSPACE Extended SIOC (see [7]), and ECOSPACE Reference Architecture Basic Collaborative Services (BCS) (see [8]) will be contributions from ECOSPACE.

2h. Draft FAQ Document

[Intentionally left empty.]

2i. Specification Working Title

Proposed working title:

Integrated Collaboration Object Model (ICOM) for Interoperable Collaboration Services Specification

References

[1] Beehive Object Model (BOM), Editors: Olkin, T.M. and Chan, E.S., Oracle Corporation, August 31, 2008.

[2] Collaboration Service Interface (CSI) Java docs, Beehive Release 1.4.

[3] http://sioc-project.org/

[4] http://www.semanticdesktop.org/ontologies/

[5] http://www.ami-communities.eu/wiki/ECOSPACE_Newsletter_No_4#Composite_Collaborative_Services_.28CoCoS.29

[6] http://www.ami-communities.eu/wiki/ECOSPACE_Newsletter_No_6#Distributed_Document_Context_.28D2C.29

[7] http://www.ami-communities.eu/wiki/ECOSPACE_Newsletter_No_6#Towards_Shared_Workspace_Interoperability

[8] Ecospace Reference Architecture: Basic Collaborative Services, Version 1.0, Edited by ECOSPACE consortium, September 2008.

Sources

• TC-Announce List
• Members List
• OASIS Charter Discuss List

This copy provides linking, formatting, and minor typographical corrections.

Prepared by Robin Cover for The XML Cover Pages archive. See details in the Cover Pages news story: "Oracle Beehive Object Model Proposed for Standardization in OASIS ICOM TC."