OASIS Open

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

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 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.

The TC will be provided with an input the Beehive Object Model (BOM) [1] as the basis for the data model for the integrated collaboration object model.

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

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

The TC will be provided with an input the Ecospace Reference Architecture for Basic Collaborative Services (BCS) [8] 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 e-mail, 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), and
   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.

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 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.

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

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.

The TC shall conduct its proceedings in English.