To OASIS Members:
A draft TC charter has been submitted to establish the OASIS Integrated
Collaboration Object Model for Interoperable Collaboration Services (ICOM)
Technical Committee (below). In accordance with the OASIS TC Process Policy
section 2.2:
(http://www.oasis-open.org/committees/process-2008-06-19.php#formation) the
proposed charter is hereby submitted for comment. The comment period shall
remain open until 11:45 pm ET on 19 January 2009.
OASIS maintains a mailing list for the purpose of submitting comments on
proposed charters. Any OASIS member may post to this list by sending email
to:
mailto:oasis-charter-discuss@lists.oasis-open.org. All messages will be
publicly archived at:
http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who
wish to receive emails must join the group by selecting "join group" on the
group home page:
http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/.
Employees of organizational members do not require primary representative
approval to subscribe to the oasis-charter-discuss e-mail.
A telephone conference will be held among the Convener, the OASIS TC
Administrator, and those proposers who wish to attend within four days of
the close of the comment period. The announcement and call-in information
will be noted on the OASIS Charter Discuss Group Calendar.
We encourage member comment and ask that you note the name of the proposed
TC ([ICOM]) in the subject line of your email message.
Regards,
Mary
---------------------------------------------------
Mary P McRae
Director, Technical Committee Administration
OASIS: Advancing open standards for the information society
email: mary.mcrae@oasis-open.org
web: www.oasis-open.org
phone: 1.603.232.9090
===========
PROPOSED CHARTER FOR REVIEW AND COMMENT
OASIS Integrated Collaboration Object Model for Interoperable Collaboration
Services (ICOM) Technical Committee
1. Normative Information
a. Name
OASIS Integrated Collaboration Object Model for Interoperable Collaboration
Services (ICOM) Technical Committee
b. 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 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.
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
a. communication artifacts (such as e-mail, instant message, telephony,
RSS),
b. teamwork artifacts (such as project and meeting workspaces, discussion
forums, real-time conferences, presence, activities, subscriptions, wikis,
and
blogs),
c. content artifacts (such as text and multi-media contents, contextual
connections, taxonomies, folksonomies, tags, recommendations, social
bookmarking,
saved searches), and
d. 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.
d. 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
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.
e. IPR Mode
The TC will operate under the RF on Limited Terms mode under the OASIS IPR
Policy.
f. 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.
g. Language
The TC shall conduct its proceedings in English.
2. Non-normative information regarding the startup of the TC
a. 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.
b. Proposed date, time, and location of first TC meeting
Date: March 3, 2009
Time: 1:00 PM EDT
Duration: 2 hours
Mode: Teleconference
Telephone: Dial-in TBD, along with e-Meeting facilities
Sponsor: Oracle
c. On-going 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.
d. 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
e. Convener:
Martin Chapman, Oracle, martin.chapman@oracle.com
f. Name of Member Section to which this TC is Affiliated
This TC is standalone and not Affiliated with existing Member Sections.
g. 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.
h. Draft FAQ Document
Intentionally left empty.
i. 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_Collab
orative_Services_.28CoCoS.29
[6]
http://www.ami-communities.eu/wiki/ECOSPACE_Newsletter_No_6#Distributed_Docu
ment_Context_.28D2C.29
[7]
http://www.ami-communities.eu/wiki/ECOSPACE_Newsletter_No_6#Towards_Shared_W
orkspace_Interoperability
[8] Ecospace Reference Architecture: Basic Collaborative Services, Version
1.0,
Edited by ECOSPACE consortium, September 2008