NOTE: This wiki is provided by the OASIS standards consortium as a collaborative tool for members of the OASIS Integrated Collaboration Object Model (ICOM) Technical Committee, who are permited to post to these pages. As this is an official workspace of the TC, the OASIS IPR Policy and other OASIS rules apply to its use. To learn more about the work of the TC, send a comment, or join this effort, visit the OASIS ICOM TC homepage.

Wiki pages are transient documents, so intermediate edits may not be saved. TC members should move all permanent work and stable artifacts to the TC's document repository, where the archival work product of the TC also can be viewed by the public.

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

1.0 Introduction

OASIS Integrated Collaboration Object Model (ICOM) Technical Committee was chartered on March 3, 2009 to specify the normative standards for collaboration objects, along with the classes, attributes, relationships, constraints, and behavior, for a broad range of collaboration activities in an integrated and interoperable collaboration environment. Cisco Systems, DERI, ESoCE-NET, KnowledgeTree, and Oracle Corporation are OASIS members who have representatives serving on this TC.

The ICOM specifications will 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 had created the impedances between the components across standard and technology boundaries. The ICOM TC envisages that the new solutions based on ICOM specifications will offer seamless transitions between different functional components to enable the applications that mash up the model of different component areas from different interoperable service providers.

2.0 Motivations

Organizations have incrementally deployed a mix of disjoint collaboration tools, and over the years, the increasingly fragmented tools begin to erode the productivity. The fragmented collaboration tools are usually technology driven tools that require constant context switching for the users to perform a single task. They generate incomplete threads of conversations when users communicate through multiple channels.

The silos of tool repositories prevent the users from relating, aggregating, and reasoning about diverse types of collaboration artifacts by project, task, metadata, or any relevant context. The data silos also prevent uniform relevance rankings of search results from the isolated repositories. The proliferation of web 2.0 content silos also weakens corporate governance. As a result, the organizations are faced with the technical obstacles and high costs in their quests to integrate these disjoint tools and the silos of data each tool produces.

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

Projects to integrate the silos of repositories encountered the soaring costs or technical barriers. To solve the fragmentation problem, various collaboration vendors have attempted to unify their platforms in order to build a single collaboration environment which provides the 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, independent software vendors, and system integrators face a difficult challenge to build contextual collaboration environments using service components from multiple vendors.

3.0 The ICOM Vision

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.

Inspired by Vannevar Bush, Doug Engelbart, and Tim Berners-Lee's progressive visions towards the global network of knowledge to augment the human intellect, the ICOM standards and technologies shall thrive to supplement the network of collaboration entities (see Figure 1) in the global network of knowledge. Network of Entities.jpg

Figure 1 - Network of collaboration entities.

Through the ICOM standards and technologies, the users shall experience seamless transitions among the diverse collaboration activities. The developers can incorporate the role-aware and task-driven collaboration to the contexts of the enterprise business applications, enterprise workplace portals, custom composite applications, and semantic technology enabled applications.

Figure 2 - ICOM for consolidating workspace applications.

The system integrators can use ICOM as a canonical data model for integration of interoperable collaboration services (see Figure 2). In an even larger scale, ICOM can be part of any canonical enterprise business objects model on Enterprise Service Bus (ESB) for enterprise applications integration (see Figure 3). The enterprise architects can apply the workspace-centric design patterns to join the business processes and collaboration activities, by provisioning separate workspaces to represent the durable contexts for project management, service requests, factory orders, workflows, etc. Enterprise business objects, knowledge articles, messages, discussion forums, chat rooms, real-time conferences, presence, etc., will be accessible from the same workspace. Business applications can initiate real-time collaboration from the contexts of business process workflows, and vice versa, collaboration workplace portals can initiate the business processes such as customer service requests, order fulfillment workflows, etc., from email messages, instant messages, or forum discussions.

Figure 3 - ICOM for integrating collaboration objects with business objects in enterprise workplace portal.

4.0 The ICOM Structure

ICOM is extensible and includes diverse classes of objects for:

ICOM facilitates common policy enforcement of heterogeneous contents coupled with an extended common infrastructure, such as identity management, access control, governance and record management, business rules and processes, and business intelligence. The user experience will improve with task or project oriented organization of disparate types of contents, complete conversation threads through multi-channel, multi-modal communication artifacts, classification, tagging, meta-data associations, activity streams, faceted search and relational navigation, unified search and relevance ranking, and alert subscriptions across a broad range of heterogeneous contents and collaboration activities.

5.0 Concomitant Representation of ICOM in UML and RDF

ICOM will be defined concomitantly in the Unified Modeling Language (UML) and Resource Description Framework (RDF). From the outset we let the interplay of both UML and RDF modeling methodologies to influence the features of the ICOM for concomitant representations in UML and RDF. When we describe the features in the ICOM UML model or ICOM RDF model, and since the two models are concomitant representations of ICOM, ideally the descriptions should in essence reflect the features of the ICOM. The concomitant model enables direct transformations between the two representations.

In RDF modeling methodology, the classification and subsumption relations can be derived as entailments, allowing more fluidity for the RDF model. In contrast the classification and subsumption relations must be specified in the UML model which is consequently more rigid and schema driven. To close this gap, ICOM includes two metadata concepts called Category and Bond, which are defined as extensions of RDF Class and RDFS Statement in RDF model of ICOM, and provide the extensibility of classes and properties for UML model of ICOM. Any custom RDF classes that do not map to classes specified by ICOM shall be represented by Category objects in UML model. Likewise, the RDF properties that do not map to the known properties in ICOM specification, which include parentOf, elementOf, createdByOf, senderOf, and receiverOf properties to name a few, shall be represented by Bond objects in UML model.

Multiple inheritances can create ambiguities in UML model, so ICOM UML model adheres to the single inheritance class hierarchy. Single inheritance class hierarchy can be augmented with the auxiliary classifiers represented by UML interfaces. UML interfaces are a kind of classifiers that cannot be directly instantiated (i.e. instances of an interface must be instances of concrete classes that realize the interface). Single inheritance class hierarchy augmented with the auxiliary classifiers simplifies the bindings of ICOM UML model to common object-oriented (OO) languages such as Java, C#, Objective-C, C++, etc., but can cause complications for binding ICOM to XML schema for REST and SOAP protocols. Nevertheless, the auxiliary classifiers improve the versatility of the model. The differentiation of class vs. interface in the UML model is transparent in the RDF model, where every concept is a class and multiple inheritances can be used without conflicts.

The ICOM UML model includes UML interfaces, such as Parental, Container, Accessor, and Owner, which cannot be directly instantiated, i.e. instances of an UML interface must be instances of concrete classes that implement the interface. ICOM UML model also includes abstract classes, such as Entity, Scope, Subject, and Artifact, which cannot be directly instantiated. The UML interfaces and abstract classes have counterpart classes in RDF model. However, RDF schema, NRL, or OWL do not support mechanisms to restrict the RDF counterpart classes for the UML interfaces and abstract classes to have only instances that are required to be instances of some concrete class concepts.

The ICOM TC is evaluating an RDF schema extension to declare certain RDF classes as abstract class to emulate the notions of abstract class and interface in UML. An analogous RDF schema extension is also evaluated for declaring certain RDF properties as abstract property.

Transformations between ICOM UML Model and RDF Model

ICOM TC has proposed a naming convention for UML aggregate attributes: the plural attribute name is converted to singular property name in RDF. The same cardinality is applied to the UML attribute and the corresponding RDF property.

The prefix "has" is omitted for the RDF data type properties, except for the Boolean properties which use the prefix "is." For example, the UML association "parents" is represented by the RDF property "hasParent." Similarly, the UML association "elements" is represented by the RDF properties "hasElement."

RDF properties "hasParent" and "hasElement" have the same cardinality as the UML aggregate associations "parents" and "elements".

The UML non-aggregate associations such as owner, modifiedBy, createdBy, etc, are mapped, respectively, to "hasOwner," "hasModifiedBy," "hasCreatedBy" properties in RDF. The prefix "has" is omitted from the RDF properties "modifiedOn" and "createdOn," whose ranges are the data type Date. The RDF properties "modifiedOn" and "createdOn" are mapped, respectively, to the UML data type attributes modifiedOn and createdOn.

The ICOM TC is also proposing to specify the non-aggregate RDF properties as functional property (nrl:FunctionalProperty). A functional property can have the cardinality of 0 or 1 and, therefore, allow the property to be optional. For the mandatory non-aggregate properties, the cardinality constraint is exactly one.

Using domain restriction, the "hasElement" property of Calendar can be restricted to the valid range for calendar elements. Similarly, the elements of AddressBook can be restricted to the range of address book elements.

6.0 The ICOM High-Level Concepts

The UML class diagram in Figure 4 and RDF diagram in Figure 8 depict the high-level "core" concepts of ICOM. Virtually all ICOM objects are entities which are assigned universal resource identifiers (URI). An entity's mandatory URI is immutable but name is mutable. Access to every entity is controlled through access control policy. The owner can be either a single actor or a group. The actor that creates the entity is represented by the creator attribute which cannot be changed. Each entity has zero or more meta-data associated with it.

There are three major branches in the object model, namely:

They are represented by three subclasses of Entity.

Scope Branch

Subject Branch

Artifact Branch

Auxiliary Concepts

In the UML diagram of Figure 4, the classes in each of the three major branches of concepts, namely Subject, Scope, and Artifact branches, are identified by matching colors. High-Level Core Concepts.jpg

Figure 4 - UML class diagram for ICOM high-level concepts. Model of Core Concepts.png

Figure 5 - RDF diagram for ICOM high-level concepts.

Rationale for Auxiliary Concepts

The high-level ICOM model in Figure 4 includes a few auxiliary concepts (which are represented by UML interfaces to avoid multiple inheritances). The auxiliary concepts afford the flexibility at the design time for optimizing the versatility of ICOM. We shall illustrate the rationale for auxiliary concepts by examples.

One example involves the auxiliary concept called Accessor, which includes Group and Actor but excludes Role. ICOM supports both Discretionary Access Control (DAC) and Role-Base Access Control (RBAC) policies. DAC policy is composed of Access Control List (ACL), which are triples of the form <Actor-1 hasWriteAccess Container-A>. We have a concept called Subject that includes Role, Group, and Actor, which can be the subjects of access control policy statements. However, we want to exclude Role from the subjects of ACL in DAC model so that Role can be used exclusively as subjects of RBAC model. By restricting the subjects of ACL to Accessor as shown in Figure 6, we exclude Role among the subjects of the ACL in DAC model. Control List.jpg

Figure 6 - Subject, privilege, object triples in an access control list.

Ownership is another important concept for DAC policy in ICOM. At the design time there are two possible choices for the type of the owner attribute for Entity, namely:

If we were to use Subject as the type for owner attribute, then Role and Group can be owners of the entities. It is desirable to allow a group of actors to co-own an entity to make the model more versatile. On the other hand ownership is a concept akin to DAC policy but orthogonal to RBAC policy. Hence we refine the auxiliary concept of Owner as a specialization of Accessor and use it as the type for owner attribute of Entity:

Potentially, we may define another auxiliary concept DistributionList to represent the union of Role and Group, which can be part of an operation to distribute a message to the members of a role or group. Figure 7 shows how the auxiliary concepts (represented by UML interfaces in UML model) are typically defined as the union of other classifiers. List.jpg

Figure 7 - Auxiliary concepts typically represent the union of classifiers.

As we refine ICOM, we find more auxiliary concepts to improve the versatility of the model. Parental and Container are two other auxiliary concepts. The parental concept avoids overloading two aspects of parent-child relationships on the generic container-child relationships as illustrated below.

Container Specializes Parental

In the ICOM UML model in Figure 4, Parental appears to be redundant because it has only one subclass called Container and other concepts shown in the diagram, such as Scope and Folder, extend from Container. There are a few concepts in ICOM (not shown in the high-level diagram) that are Parental but not Container.

A unified message can be a parent of the attachments, including forwarded message, replied to message, or document. A document can be also a parent of parts of the document. The parent-child relation between a unified message and attachments is different from the relation between a container and elements of the container: the elements of the container can have their own ACL to override the ACL of the container; on the other hand, attachments in the unified message always share the same ACL with the parent message, such that if a user can read the message, he or she can also read the attachments in the message.

To avoid overloading different special parent-child relationships on the generic container-child relationships, we defined Parental as a more abstract concept than Container. UnifiedMessage and Document are modeled as Parental instead of Container. Space and Folder are defined as specializations of Container.

Directory and Membership Concepts

The model for Scope, Community, Space, Role, Group, and Actor are designed to represent two somewhat orthogonal concepts.

The first concept to be represented is the Directory for organizing the Role, Group, and Actor instances in some hierarchical structure. Like in LDAP repository, all objects representing people, group of people, and role of people can be placed in a common location to be looked up and referenced by every user of the system. The LDAP distinguished names are derived from the container hierarchy, such as "dc=oasis-org,ou=people" and "dc=oasis-org,dc=icom,ou=group." ICOM model for hierarchy of scopes can represent the features similar to the LDAP containers. Scope defines the attributes "groups" and "roles" to hold these resources as directory entries. Community defines the attribute "actors" to hold the actors as directory entries. Community and Space inherits the "groups" and "roles" attributes from Scope. Space can hold the groups and roles that are only applicable within the space. Access control policies can be defined in terms of the subjects from the directory (see the UML class diagram for access control list in Figure 6).

The second concept to be represented is the Membership of actors in the communities or spaces within the communities. The membership concept cannot be represented by a single attribute or class. Membership concepts are defined using access control policies in the nested scopes (of communities or spaces) and sub-containers within the scopes. Concept.jpg

Figure 8 - A membership concept defined by groups, roles, and access control policies.

As a hypothetical example, we define a membership in a project to mean that an individual can post discussions to the forum in the project space, but may not necessarily update any content in the space. We further assume that there are active participants who may modify any content in the space. The UML collaboration diagram in Figure 8 shows how such a membership concept can be configured by access control. The "participants" and "viewers" groups in conjunction with the access control policy serve as the template for this hypothetical membership concept. Once the membership concept is defined, the individuals can be added to the groups. In the configuration in Figure 8, both userA and userB are members of the project space. UserA is a member of the group which has read/write access to the whole space and so can actively participant in the project space. UserB is a viewing member who has read/write access in the forum but only read access in the space. Thus userB is a viewer who may only post discussions in the forum. The "participants" and "viewers" groups can be created in the project space if they are applicable only to this space.

Parent-Child Inverse Relations

Owl:InverseOf allows one property to be obtained from another property by changing its direction, i.e. inverting it. For example, the property parentOf can be defined as the inverse property of childOf.

There are parent and child relations between the scopes and the subjects, through the "groups," "roles," and "actors" attributes in the scope and the "parents" attribute in the subject. The following OWL property axioms are valid among the parent-child relations between the scopes and the subjects.

Similarly, there are parent and child relations between the artifact containers, which include space and folder, and the artifacts, through the "elements" attribute in the artifact containers and the "parents" attribute in the artifacts. The following property axiom is valid among the parent-child relations between the artifact containers and the artifacts.

HeterogeneousFolder and Space share a common behavior for holding other sub-folders. This commonality is represented by FolderContainer concept. The parent of all types of folders must be FolderContainer, implying that a folder, such as a Calendar, TaskList, and AddressBook, can be placed in a Space or HeterogeneousFolder.

Heterogeneous and homogeneous folders

HeterogeneousFolder is part of the high-level core concepts of ICOM to represent the inbox, outbox, trash, and document folders. It can contain any type of artifacts and sub-folders. ICOM employs different types of homogeneous folders, such as Calendar, AddressBook, Forum, etc., that are constrained to hold certain types of artifacts.

For example, Calendar is constrained to hold only Occurrence.

Occurrence on the other hand can be placed in Calendar or HeterogeneousFolder.

This relation allows an occurrence to appear in the inbox when the occurrence is added to a calendar or moved to the trash when the occurrence is deleted from a calendar. Since

we have

Similarly, the elements of AddressBook must be Contact, i.e. AddressBook is a constrained folder to contain Contacts and not other types of artifacts.

The parent of a Contact can be ArtifactContainer, which includes HeterogeneousFolder.

This relation implies that a Contact can be placed in an AddressBook or in a HeterogeneousFolder. When a contact is deleted from the AddressBook, it can be moved to the trash folder. Since

we have

7.0 Use Cases for High-Level Core Concepts of ICOM

The following UML composite structure diagrams depict the internal structures of the community and space, including the interaction among the roles, groups, actors, and folders within a scope. A composite structure diagram can include classes, instances, and collaboration diagrams.

UML collaboration diagram, enclosed by an ellipse in the composite structure diagram, may depict the object configurations in which objects jointly define a behavior, such as in Figure 9 which describes how a role, a group, and a set of actors form a workspace participation level, and in Figure 10 which describes how to setup the three levels of workspace membership.

UML collaboration diagram may directly represent an instance of a class by describing the structure of collaborating roles of components in the class. This is the case in Figure 11 which depicts the TC workspace as an instance of Space, and in Figure 12 which depicts the OASIS community as an instance of Community. (Please refer to Section 9.4. of Unified Modeling Language: Superstructure at OMG UML Specification OMG UML Spec to see the notation used in UML composite structure diagrams). Participation Level.jpg

Figure 9 - Collaboration diagram describing a workspace participation level.

Figure 9 depicts the collaboration of a role, a group, and a set of actors defining a TC participation level. This collaboration is used subsequently in Figure 10 to define the three levels of TC membership. Membership Setup.jpg

Figure 10 - Collaboration diagram describing the three levels of membership in a TC workspace.

There are three levels of membership in a TC, namely member, voting member, and observer. Figure 10 shows how these three levels are defined by three separate groups and the corresponding roles in a workspace. The TC membership setup defines three sets of actors. It is necessary to express constraints among the three sets of actors, such as the voting members are a subset of the members, and the observers are mutually exclusive to the members.

UML collaboration diagram in Figure 11 describes the internal structures of an instance of Space used for OASIS TC workspace. The ICOM TC workspace is represented by a space in the OASIS community. The members, voting members, and observers of ICOM TC are applicable only to the activities in the ICOM TC workspace so it is appropriate to create the TC membership roles and groups in the TC workspace. Most of the parts, including space, roles, and groups and excluding actors, of the collaboration diagram in Figure 11 fit in the class schema of Space shown in Figure 12. The individual actors who participate in the ICOM TC workspace belong to the OASIS community and fits in the class schema of Community in Figure 14. Workspace.jpg

Figure 11 - Collaboration diagram of TC workspace, constructed from Space. and Subjects.jpg

Figure 12 - Class schema of Space that supports TC workspace.

The OASIS community depicted by the UML collaboration diagram in Figure 13 includes one instance of the TC workspace for ICOM TC working group. The members and observers of the ICOM TC are drawn from the actors of the OASIS community. OASIS community can provide the OASIS staffs or OASIS administrators groups or roles which can be applied to the spaces within the OASIS community. One can see how various parts of the collaboration diagram in Figure 13 fit in the class schema of Community shown in Figure 14. Community.jpg

Figure 13 - Collaboration diagram of OASIS community. and Actors.jpg

Figure 14 - Class schema of Community that supports OASIS community.

8.0 Containers in Space

The elements of a space are folders. ICOM defines the following types of folders:

Figure 15 - Class diagram for several types of folders.

Figure 15 shows different types of folders. The heterogeneous folder is an unconstrained folder which can hold any type of artifacts. It is used as an inbox for the space, to receive messages, invitations, assignments, documents, etc. It is also used as a trash folder to hold any artifacts deleted from the space, including documents, messages, calendar occurrences, tasks, discussions, contacts, and folders. Other specialized folders, such as Calendar, TaskList, AddressBook, etc., are constrained folders.

The constraint implies that a Calendar, which only holds occurrences, cannot hold documents or messages. One may argue that there are valid use cases to be able to place an agenda document for a meeting in the same calendar which schedules the meeting. The constraint is imposed for Calendar to relieve the calendar service providers from having to manage the documents, messages, and other types of artifacts. The service providers for other specialized folders may have similar legacy issues preventing them from managing arbitrary artifacts. Folders Configuration.jpg

Figure 16 - Collaboration diagram depicting a configuration of folders for team collaboration.

UML collaboration diagram in Figure 16 shows how to configure a team workspace by designating special folders for different collaboration activities. This collaboration diagram is compacted in Figure 17 that describes the internal parts of a team workspace. The folders of the team workspace in Figure 17 fit in the class schema of Space shown in Figure 18. Workspace.jpg

Figure 17 - Collaboration diagram of team workspace. and Folders.jpg

Figure 18 - Class schema of Space that supports team workspace.

9.0 Entity Metadata

The entity metadata includes Marker and Bond. Marker is used to group together or classify the entities by a common criterion. Bond is used to relate a set of entities by a predicate. Both Marker and Bond are important extensibility features of ICOM.

Metadata Concepts


Marker can be flat or hierarchical. Flat markers are modeled by Tag and hierarchical markers are modeled by Category. A tag represents a keyword that is directly attached to an entity for the purpose of labeling the entity. A category is used to classify an entity under a structured taxonomy. In some cases when the user applies a marker to an entity, the marker application should be private such that only the user who applies the marker can browse or locate the entity through the marker. This is especially the case when the markers are created by a user and visible only to the user who created them.


The association in Unified Modeling Language (UML) is a counterpart to the relationship in Entity-Relationship Model (ERM). The extensibility for relationships is a common metadata facility that lets the users to define arbitrary relationships among the entities. Bond is the name of an ICOM concept that works like the "Relationship" in ERM or the "Association" in UML. In RDF parlance, a bond is a predicate that relates a set of entities to one entity, which is the subject of the bond. The bond schema represents the type of the bond, such as "Discuss this," "Follow-up," and "Related material."

Usage of Bond vs. Marker

It is helpful to think of Bond as predicates and Tag as keywords when choosing which one to use. As predicates, bonds are sometimes more appropriate than tags for relating the entities to the contexts. For example, a single tag can be associated with any number of artifacts. Even though the user can create new tags as needed to mark the artifacts for a context, doing so will dilute the tags and reduce the utility of tags. Instead of using tags, the user should first define a bond class to represent the predicates such as the "related material for a customer service request." For each incidence of the customer service request, the user can create a bond to relate any number of artifacts, such as the problem reports, customer email correspondence, logs, problem resolution, knowledge articles, etc., by the service request identification.

Mapping between UML Model and RDF Model of Metadata

Several components of the UML model in Figure 19 are superfluous for RDF model.

RDF model defines Category as a subclass of rdf:Class and Bond as a subclass of rdfs:Statement. Metadata.jpg

Figure 19 - Entity metadata.

UML Links: Category Application, Tag Application, and Bond Entity Relation

In UML model an association between two classes can have instances which are known as links connecting the specific pairs of objects. When the UML model is realized in an implementation language like Java, C#, or Objective-C, it can be too costly to represent every association in the model explicitly by link objects. By convention, all associations in ICOM UML model can be represented by member variables in the object to efficiently reference the associated objects. In cases where the associations should be realized by the link objects, such as for the entity metadata, we explicitly model the links by special classes in UML model.

The UML model of entity metadata in Figure 19 describes how a category, tag, or bond can be linked with multiple entities. When the same metadata is linked to multiple entities, each link between the metadata and an entity should be represented by a link object to hold the attributions specific to the linked entity. ICOM UML model employs CategoryApplication, TagApplication, and BondEntityRelation to represent, respectively, the links from category, tag, and bond objects to entities. Bond Schema.jpg

Figure 20 - Property definition represents domain and range of each property in Category and Bond.

Concomitant Model for Category

In RDF model, Category can be defined as a subclass of rdf:Class or owl:Class. Categories represent the extensible classes that can be derived by Description Logic. New class hierarchies can be dynamically defined and applied to entities as additional facets besides the facets or concepts specified by ICOM. Examples of categories are "Functional Specification," "Design Specification," and "Test Specification," which classify the technical documents.

Since Category is a subclass of rdf:Class or owl:Class, an RDF Category object can be used to declare the domain or range of RDF properties. As a counterpart to the RDFS vocabulary for specifying the domain and range of an RDF property, we introduce the PropertyDefinition's in the UML model of Category. In UML model, CategoryApplication object contains the properties whose domain is represented by the Category object, i.e. the category implicitly specifies the domain of the property while the type in the property definition specifies the range of the property.

Concomitant Model for Bond

In RDF model, Bond can be defined as a subclass of rdfs:Statement. RDF includes rdfs:Statement, the reification vocabulary, to recast a set of RDF triples in an n-ary relation as a resource that has the properties rdf:subject, rdf:predicate, and rdf:object, and any additional properties, including the attribution, annotation, and provenance information. For the isomorphic UML model of Bond, we define the attributes subject, predicate, and objects as shown in Figure 21.

Figure 21 - Class schema of Bond to represent n-ary relations.

As a counterpart to the RDFS vocabulary for specifying the domain and range of rdf:Property, we introduce BondSchema and PropertyDefinition in UML model to specify the domain and range of the properties represented by the bonds. For example, the BondSchema for "Related material" bond can contain two property definitions to specify the types of the "subject" and "objects" attributes of the bond. The types of the "subject" and "objects" attributes in UML model can represent, respectively, the domain and range of "hasRelatedMaterial" property in RDF model. The property definition for the "objects" attribute specifies that the attribute is an aggregate.

The mapping from UML model to RDF model for Bond includes:

When transforming from RDF representation to UML representation of ICOM, the mapping rules for Bond include:

The reification statements serve as the conceptual framework for isomorphic mapping of Bond objects between UML and RDF representations. We note that it is often not necessary to materialize the reification statements since the primary objective should be to translate the bond entity relations to the RDF triples rather than to the reification of the triples.

10.0 Use Cases for Category and Bond

Let's take the groups and membership scenario in Figure 22 as a case study, which involves hierarchy of projects, subprojects, work packages, and tasks represented by ICOM Space. The hierarchical structuring of spaces is just one of many possible structures needed for diverse use cases. ICOM supports arbitrary, flexible structures not only among the spaces but also among containers and a mix of entities.

First we observe that ICOM communities are hierarchical although spaces themselves are not hierarchical. Since each community can contain a set of spaces, spaces can belong in different levels of hierarchy.

In the scenario in Figure 22, the top level is a project, which is divided into subprojects. Each subproject can be divided into work packages, which in turn can be divided into tasks. Each of these project units is supported by an ICOM space containing several folders. Project tasks are assignable to groups. Conceptually, the smallest units of participation in the project units are groups of individuals rather than individuals who may be supplied by multiple organizations. The organizational hierarchies are determined independently of the project unit hierarchies. Each organization can independently assign individuals to the groups that it contributes to the project units.

The scenario illustrates the use of Category to classify spaces and folders by the taxonomy of project units and the use of Bond for hierarchical structuring of spaces and folders to represent the division of projects into subprojects, work packages, and tasks. ICOM TC Groups and Membership Use Case.jpg

Figure 22 - Groups and membership in the hierarchy of project units.

Using Category to Represent the Taxonomy

Figure 23 depicts the categories representing the taxonomy of project units. Figure 24 illustrates the extensibility of ICOM Category to classify the spaces and heterogeneous folders by the concepts from the project taxonomy, such as "Project Unit," "Main Project," "Work Package," and "Project Task" which are not part of the ICOM specification proper. Taxonomy.jpg

Figure 23 - Categories representing the taxonomy of projects. Classification.jpg

Figure 24 - Classification of project spaces and folders by project taxonomy.

Using Bond to Represent the Predicates

UML model of Bond represents n-ary relationships among a set of n entities. Note that Bond has an attribute called "subject" to distinguish one of the n entities and the "objects" attribute to hold n-1 BondEntityRelation objects (see Figure 25).

Figure 25 - Collaboration diagram of Bond representing n-ary relationships.

We use bonds to represent the division of a project unit into subunits. To represent the division of a project unit into subunits, the "subject" attribute of Bond can distinguish the project unit that is being divided, while the n-1 tuple of BondEntityRelation's can represent the subunits of the project unit.

The following examples show how the triples comprising the n-ary relations can be recast by reification statements. In Figure 26, we defined the project hierarchy in RDF using RDF properties "hasSubUnit" to relate the project unit with the subunits. The RDF triples comprising an n-ary relation associate the same subject and property with n-1 objects. For example, the tertiary relation "Project-SubUnit(Project, SP1, SP2)" between a project and two subprojects is represented by two triples <Project hasSubUnit SP1> and <Project hasSubUnit SP2> that associate the subject "Project" and property "hasSubUnit" with the objects SP1 and SP2. Model of Project Spaces.jpg

Figure 26 - RDF model of project hierarchy.

Triples for the tertiary relation "Project-SubUnit(Project, SP1, SP2)" are

These triples can be reified by the following RDF resource "Project-SubUnit":

ICOM can specify a naming convention for assigning a name to the reification resource, for example one possible naming convention is to concatenate the names of the subject "Project" and predicate "hasSubUnit" to get "Project-SubUnit", stripping off "has" and "is" from the predicate.

In Figure 27, the RDF model from Figure 26 is extended with the reification statements. The reification statements "Project-SubUnit" and "SP1-SubUnit" are instances of Bond. In ICOM, Bond is defined as a subclass of Entity. In RDF representation, Bond is defined as a subclass of rdf:Statement as well as a subclass of Entity. Reification Model of Project Spaces.jpg

Figure 27 - Extending the RDF model with reification statements.

UML collaboration diagram in Figure 28 depicts how one bond is used to divide Project into two subprojects (SP1, SP2) and another bond is used to subdivide SP1 into three work packages (WP1, WP2, WP3). Work Packages.jpg

Figure 28 - Collaboration diagram of project hierarchy.

The RDF reification statement can add the annotation, provenance, and attribution information. For example, in the following reification of the "hasSubUnit" property on the "Project" space, the "Project-SubUnit" is a subject that has provenance information "stipulatedBy" and "stipulatedOn" about the "hasSubUnit" property on the "Project" space.

Provenance properties in the RDF reification, besides the rdf:type, rdf:subject, rdf:predicate, and rdf:object properties of the "reification quad," can be represented by an extensible set of properties in the bond object in the UML model. The range of the provenance property can be specified by the type in the PropertyDefinition, however the domain of the properties are implicitly specified by the bond schema, i.e. the type of the bond subject. For example, the "Project-SubUnit" bond can contain two additional properties for "stipulatedBy" and "stipulatedOn." The property definitions for "stipulatedBy" and "stipulatedOn" in the bond schema for "Project-SubUnit" can specify "Project-Plan" for the range of "stipulatedBy" property and Date for the range of "stipulatedOn" property.

11.0 Artifact Modules

Figure 15 shows a variety of containers in the ICOM space to support various collaboration activities. The heterogeneous folder stands out as a high-level concept of ICOM space to serve as the "universal" inbox, outbox, trash, and public/published container for any types of artifacts in the space. Several types of artifacts, including Documents and Messages, do not need specialized containers. However, specialized types of artifacts such as Occurrences, Tasks, Contacts, Topics, Discussion Messages, and Conference Transcripts need specialized containers to provide additional structures for the artifacts. ICOM includes Calendar, Task List, Address Book, Forum, and Conference containers that provide the structures and also designate the collaboration activities. These artifacts can be mixed with Documents and Messages in the heterogeneous folders. The specialized containers and artifacts are defined as modules in ICOM. In this section we describe the most common modules.

A document is a versionable artifact that can contain single or composite contents for any assortment of media types. Versionable is an auxiliary concept that defines the attributes for version control. A versionable artifact represents a specific "frozen version" of an artifact. It holds a version node that contains the version number, label, and description. The container of the versionable artifact holds a constant URI whose representative version varies depending on the individual actor and environment. When the representative version varies, the artifact’s version number, label, description, and content will vary. Starting from the representative version under the container, the actor can get to the version history and traverse the artifact version nodes. Each artifact version node holds the specific “fozen version” of the artifact.

Figure 29. Versionable Document Model.

A message is a unit of conversation. It holds a simple content or multipart message contents in the Content attribute. It includes the sender. The deliveredTime attribute holds the time when the message is delivered to a given recipient. The sent time of the message is represented by the user’s created-on time of the artifact. The name attribute holds the subject or title of the message.

A unified message is a special type of message delivered electronically over a computer, voice, fax, and other networks. A unified message can be one of these types. Email is a type of message that is delivered electronically over a computer network. Voice is a type of message that contains a voice or audio stream. Fax is a type of message that contains an image transmitted via phone lines using the fax protocol. Message.jpg

Figure 30. Unified Message Model.

A content contains the data for a document or message. The content, multi-content , simple content, and online content form a composite design pattern.

A multi-content instance represents the multi-parts of a message or document. It is a composite content that can contain a list of simple or composite contents.

A simple content holds a single piece of data. The media type is an official RFC2046 type. Content encoding specifies the RFC2616 content encoding applied to the content. Character encoding specifies the RFC2616 character set of the content (a missing value means that the content should be treated as binary or raw). Content language specifies the RFC2616 content language for the content (a missing value means non-natural language content).

An online content holds the online artifact attached to a message or invitation. The online artifact must be rendered as a URL when the message or invitation is delivered to external recipients.

Figure 31. Content Model.

A forum is a folder that contains sub-forums, topics, and announcements. A topic represents a conversation among forum members; it is structured as a collection of discussions messages. The discussions semantics may impose the topic messages to be sorted in chronological order or threaded by reply. An announcement is a special topic for messages that are valid for a specified period of time, depending on the activated and expire on times.

Figure 32. Discussion Forum Model.

An address book is a folder that contains contacts, which can include bookmarks to addressable entities in the directories, addresses, and other personal entries. Address books may contain sub-books (chapters) that can be used to hierarchically organize the contacts. A person contact is an entry in the address book that contains the contact information for a person. It can be used to bookmark a person in the community. Alternatively, it can hold all the attributes about a person without bookmarking a person in the community.

Figure 33. Address Book Model.

A calendar is a folder that contains occurrence series and occurrences. When an organizer creates a calendar event, occurrence series and occurrences are delivered to one or more participants. An occurrence series is a collection of occurrences associated with the same event. The attributes of the occurrence series are used as default values when occurrences are created by expanding the recurrence rules. An occurrence instance represents some kind of event that occurs in a participant's calendar, such as a meeting, a day event, etc. If an occurrence is part of a recurring event, it and related occurrences are part of the same occurrence series.

Figure 34. Calendar Model.

A task list is a container of tasks. When an organizer creates a todo for the task list, tasks are assigned to one or more participants. The assignee can manipulate the task assigned to him or her, such as changing the task status and completion date.

Figure 35. Task List Model.

A participant is an association object (UML link) between an artifact representing a collaboration activity and an actor, group of actors, external contact, space, or bookable resource that participates in the activity.

Figure 36. Participant Model.

12.0 Subjects: Group, Role, Actor

A group is addressable and is an accessor which can own entities. It contains two sets of member actors and member groups. It can be assigned to roles or other groups (cycles are not allowed in the group hierarchies). A role is a named set of privileges. An actor is an entity that can act on the system. Actors and groups assigned to a role are held by the memberActors and memberGroups attributes of the role.

Figure 37. Group, Role, and Actor Model. and Group Spaces.jpg

Figure 38. Associating Group, Role, and Actor with Scopes.

13.0 Prototyping Framework for ICOM

ICOM standards will include the objects and operations on the objects, which constitute the model and control components of the model-view-control architectures. In one realization, the model component of ICOM standards can be represented as plain-old-Java-objects (POJO) while the control component can be defined in some service definition languages such as EJB session beans or WSDL. The TC envisions that by explicitly specifying the model (providing a rich vocabulary of nouns), most of the operations to compose the high-level collaboration interactions can be satisfied by create, retrieve, update, and delete (CRUD) operations. There would be need for a few special operations (verbs). Some of the special operations include send operation for messages, version control operations for artifacts, join operation for real-time conferences, operations to extract reusable templates from an object configuration (i.e. clone a space template from an active space), etc. ICOM's noun-oriented model is amenable to implementation by RDF ontology, OWL, rule-based applications, and REST API.

Figure 39. The prototyping framework for ICOM.

The TC is evaluating a prototyping framework to validate the ICOM specifications that can be subsequently extended into a reference implementation. One proposed prototype is to represent the model as POJO in conjunction with the Java Persistence API (JPA) programming model to support the CRUD operations. One possible design for this JPA framework is as shown in Figure 39. The JPA framework relies on byte code injection into the POJO methods to support JPA programming model that includes lazy or eager loading, attribute change tracking, transactions, and attaching/detaching objects from managed environment. Java Persistence Query Language (JPQL) can be used to define queries for POJO model.

About Wiki

Interesting starting points:

How to use this site

A Wiki is a collaborative site, anyone can contribute and share:

To learn more about what a WikiWikiWeb is, read about WhyWikiWorks and the WikiNature. Also, consult the HelpMiscellaneous/FrequentlyAskedQuestions page.

This wiki is powered by MoinMoin.

OldFrontPage (last edited 2010-07-07 14:03:52 by laura.dragan)