OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

Messages By Date: members message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Call for Participation: OASIS ICOM


To:  OASIS members & interested parties

   A new OASIS technical committee is being formed. The OASIS Integrated
Collaboration Object Model for Interoperable Collaboration Services (ICOM)
Technical Committee has been proposed by the members of OASIS listed below.
The TC name, statement of purpose, scope, list of deliverables, audience,
and language specified in the proposal will constitute the TC's official
charter. Submissions of technology for consideration by the TC, and the
beginning of technical discussions, may occur no sooner than the TC's first
meeting.

   The eligibility requirements for becoming a participant in the TC at the
first meeting (see details below) are:

   (a) you must be an employee of an OASIS member organization or an
individual member of OASIS, and
   (b) you must join the Technical Committee, which members may do by using
the "Join this TC" button on the TC's public page at [a].

   To be considered a voting member at the first meeting, you must:
   (a) join the Technical Committee at least 15/7 days prior to the first
meeting; and
   (b) you must attend the first meeting of the TC, at the time and date
fixed below.

Of course, participants also may join the TC at a later time. OASIS and the
TC welcomes all interested parties.

   Non-OASIS members who wish to participate may contact us about joining
OASIS [b]. In addition, the public may access the information resources
maintained for each TC: a mail list archive, document repository and public
comments facility, which will be linked from the TC's public home page at
[a].

   Please feel free to forward this announcement to any other appropriate
lists. OASIS is an open standards organization; we encourage your
participation.

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

[a] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=icom  
[b] See http://www.oasis-open.org/join/

CALL FOR PARTICIPATION
OASIS Integrated Collaboration Object Model for Interoperable Collaboration
Services (ICOM) TC

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 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 
   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
Sponsor: Oracle


c. On-going schedule

Weekly 60 Minute teleconferences sponsored by Oracle or other member of the
TC.
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
Jeff Mischkinsky, Oracle, jeff.mischkinsky@oracle.com
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) Version 1.0, January 12, 2009, Created for OASIS
ICOM TC, will be a contribution from Oracle Corporation (see [1]), along
with Beehive Release 1.4 Collaboration Service Interface (CSI) 
Java docs (see [2]).

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: Terry M. Olkin, Eric S. Chan,
Rafiul Ahad, 
Oracle Corporation, January 12, 2009. 
http://www.oracle.com/technology/products/beehive/pdf/beehiveobjectmodel_ico
m.pdf

[2] Collaboration Service Interface (CSI) Java docs, Beehive Release 1.4. 
http://www.oracle.com/technology/products/beehive/icom/beehivecsi.html.

[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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]