Draft Minutes of ICOM TC Meeting, November 25, 2009

Minutes of ICOM TC Meeting, November 25, taken by Eric S. Chan

Agenda

1. Roll Call

2. Approve draft minutes from October 28 and November 11 TC Meetings

3. Review and feedback for

a. New content for the front ICOM wiki front page: http://wiki.oasis-open.org/icom.

b. ICOM RDF model in Figure 4b of http://wiki.oasis-open.org/icom.

c. Entity metadata model in Figure 11 of http://wiki.oasis-open.org/icom/Categorisation.

4. AOB

1. The following eligible members were present

Deirdre Lee

Laura Dragan

Patrick Durusau

Rafiul Ahad

Eric Chan

2. Approve draft minutes October 28 and November 11 TC Meetings

Draft minutes were approved.

3. Review and feedback of ICOM

a. New content for the front ICOM wiki page: http://wiki.oasis-open.org/icom.

Eric announced a new content in the ICOM wiki front page. ICOM TC members are welcomed to contribute to this wiki page. The same content from the ICOM front page appeared in ECOSPACE Newsletter: http://www.ami-communities.eu/wiki/ECOSPACE_Newsletter_No_11#Towards_Interoperable_Collaboration_Services.

b. ICOM RDF model in Figure 4b of http://wiki.oasis-open.org/icom.

Participants reviewed the discrepancies between the RDF model in Figure 4b and the UML model. We need to update the RDF model to be isomorphic to the UML model. The RDF model is missing the Subject as super class of Group, Role, and Actor. Also some property names are not post-fixed by the domain name. For example, the property hasWorkspace should be renamed to hasWorkspaceOfCommunity. Similarly, there are some properties that should be renamed to hasActorOfCommuntiy, hasGroupOfScope, hasRoleOfScope, hasParentOfEntity, createdByOfEntity, modifiedByOfEntity, etc. Some of these properties can be concrete properties, for example, createdByOfEntity and modifiedByOfEntity can be applied to Document, Folder, Group, etc., without introducing createdByOfDocument, createdByOfFolder, etc. The RDF class Workspace needs to be renamed to Space.

c. Entity metadata model in Figure 11 of http://wiki.oasis-open.org/icom/Categorisation.

RDF model can be derived from the UML model of metadata in Figure 11 by following the same UML to RDF mapping rules. The Category from the metadata model can be defined as instances 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 on entities. Entity can have additional facets besides the facets or classes defined by ICOM. Examples of Categories are FunctionalSpecification, DesignSpecification, TestSpecification, etc., which classify the technical documents. Deirdre and Laura believed that ICOM Category can be modeled as RDF or OWL class and such generalization would suit the semantic web technologies.

In UML class diagram an association between two classes can have instances which are known as links connecting the specific pairs of objects. Link objects can hold attributes regarding the two specific objects. When UML model is realized in an implementation language like Java, it is too costly to represent the every association in the class diagrams by link objects. The associations are represented by Java objects’ member variables to reference other objects. To represent the associations between the metadata and entities, we propose to model the associations by CategoryApplication, TagApplication, BondEntityRelation, etc. classes, which can have instances to hold the attributions for specific instances of associations between the metadata and the entities.

Deirdre asked about an example for the usage of TagApplication in the metadata model. Eric gave the following example. A user can define a customer tag called “General Electric” and apply the same tag on three different artifacts. The relations between the “GE” tag and each of the three artifacts are represented by three TagApplication objects. The user can add attributes “Problem Report,”, “Problem Logs,” and “Problem Resolution,” etc., to describe how the tag relates to each artifact.

4. AOB

Deirdre posted a list of issues about the ICOM draft before the TC meeting. The participants discussed the issues as reported below:

a. “A Scope has Groups; A Community is a Scope; Therefore a Community has Groups; A Community has members; How do members relate to Groups?”

Participants reviewed the UML diagram in Figure 4 of http://wiki.oasis-open.org/icom to address this issue. Eric explained that the UML 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 Community 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 Community can represent the features similar to the LDAP containers or nodes.

The second concept to be represented is the Membership of actors in the communities or spaces within the communities. Eric emphasized that the membership concept cannot be represented by a single attribute or class. Membership concepts are defined using access control policies on the nested scopes (of communities or spaces) and sub-containers within the scopes. The access control policies are defined in terms of the elements from the directory, including group, role, and actor.

Deirdre’s question involved the community having an attribute called members which can hold only actors. Would this mean that members of the community cannot be defined in terms of groups and roles? To this question Eric responded that the attribute called members does not represent the membership in the community. It is a containment relationship between the community and actors in the community for Directory lookup. To avoid confusion, Eric proposed to rename the attribute to “actors” instead of “members.” Community inherits the two other attributes “groups” and “roles” from the super class Scope. Scope represents the common behavior of the Community and Space, because a space can hold the groups and roles that are applicable only to the space. Eric referred to the OASIS community and ICOM workspace scenarios in figures 5 to 8 of http://wiki.oasis-open.org/icom. The ICOM 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. On the other hand, the individual actors who participate in the ICOM TC workspace must be looked up from 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.

b. “What is the difference between a Parental and a Container? Is Parental redundant?”

The Parental is represented by an interface in Figure 4 of http://wiki.oasis-open.org/icom. The Parental appears to be redundant in the UML diagram because it has only one subclass called Container and other concepts in the diagram, such as Scope and Folder, extend from the Container. Eric explained that there are a few concepts in ICOM (not included in the top level diagram) that are Parental but not Container. For example, a UnifiedMessage 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 UnifiedMessage and attachments is different from the relation between a container and elements of the container. For example, the elements of the container can have their own ACL to override the ACL of the container. On the other hand, attachments to 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. We don’t want to overload different special parent-child relationships on the generic container-child relationships. Hence, UnifiedMessage and Document are not modeled as Container.

c. “Why is a HeterogeneousFolder included in the High-Level Concepts diagram? Why not then include AddressBook, Calendar, etc.?”

HeterogeneousFolder is included in the top-level UML diagram in order to define the reciprocal parent-child relations represented by the “parents” and “elements” attributes. The folders and space defines the elements attribute. All entities define the “parents” attribute. A pair of “parent” and “element” properties define the bi-directional association between a container and a child entity. However, these two properties are asymmetric. For example, a Contact is an element of the AddressBook while an Occurrence is an element of the Calendar. The parent of a Contact or an Occurrence can be ArtifactContainer, which includes HeterogeneousFolder. The asymmetric 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 placed in the HeterogeneousFolder representing a trash folder. On the other hand, the elements of AddressBook must be Contact, i.e. AddressBook is a constrained folder to contain Contacts and not other types of artifacts. An Occurrence can be added to a Calendar and simultaneously delivered into the Inbox represented by a HeterogeneousFolder. Calendar, on the other hand, is constrained to contain only Occurrences.

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

d. “At the design time there are two possible choices for the type of the owner attribute for Entity, namely: Subject; Actor. But an Actor is a Subject, no?"

If we defined the “owner” attribute of Entity to hold Subject, then Role can be owner of the entities. It is useful to allow Group and Actor to own entities. Role is used in RBAC policies which do not assume ownership. To reserve Role for use with pure RBAC model, we try to exclude Role from owning entities. Hence we introduced a new concept called Accessor and define “owner” attribute to hold Accessor.

e. “Should there be a direct link between an Entity and an Actor, createdBy and modifiedBy.”

The attributes createdBy and modifiedBy are defined on Entity although the associations are not depicted by graphical links in the UML diagram.

f. Should we abolish use of interfaces at this level, only have concepts?

Interfaces in UML model are just a mean to avoid using multiple inheritances from super classes. The differentiation of interface vs. class is completely transparent in RDF model where every concept is a class and multiple inheritance can be used without conflicts.

g. In the use case in Figure 5, it shows a Role assigned to a Group. How is this modeled in our High-Level Concepts diagram

The link predicates in Figure 5 should be read from left to right or from top to bottom. So one should read that a group is assigned to a role. In the same sense, a group contains 0 or more actors; a space contains a group and a role.

The meeting was adjourned.

icom message