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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

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


Subject: XRI TC note about OASIS Integrated Collaboration Object Model for Interoperable Collaboration (ICOM) TC


FYI - this proposed new TC lists three explicit relationships to other OASIS
TCs and the XRI TC is one of them. Quoting from section 2a:

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

In reading the charter, I think may also have a nice synergy with the XDI
TC.

=Drummond 

-----Original Message-----
From: Mary McRae [mailto:marypmcrae@gmail.com] On Behalf Of Mary McRae
Sent: Monday, January 05, 2009 10:14 AM
To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org
Subject: [members] Proposed Charter for OASIS Integrated Collaboration
Object Model for Interoperable Collaboration (ICOM) TC

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

 


---------------------------------------------------------------------

This email list is used solely by OASIS for official consortium
communications.

Opt-out requests may be sent to member-services@oasis-open.org, however, all
members are strongly encouraged to maintain a subscription to this list.




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