Draft Minutes of ICOM TC Meeting, May 19, 2010

[Eric Chan <eric.s.chan@oracle.com>]

Minutes of ICOM TC Meeting, May 19, taken by Eric S. Chan

 

1. Roll Call

2. Approve draft minutes from May 12 TC Meeting

3. ICOM RDF model for SemTech 2010

4. ICOM use cases for the workshop

5. AOB

 

1.       The following eligible members were present

 

Laura Dragan

Patrick Durusau

Eric Chan

 

2.  Approve draft minutes from May 12 TC Meeting

 

Deferred.

 

3. ICOM RDF model for SemTech 2010

 

·         Eric reminded that the SemTech presentation slides were due by May 24. Laura, Deirdre, and Eric will coordinate to finalize the presentation slides for submission. Eric  to provide the model for Calendar, TaskList, and Conference.

 

·         We need to document the usage of the OWL domain restriction to define the properties (instead of introducing the distinguished property names, such as hasAssignedRoleOfActor).

 

·         Participants reviewed the assigned group/role and member actor/group properties.

 

o   hasAssignedRole [of Actor]  is-inverse-of hasMemberActor [of Role]

o   hasAssignedRole [of Group] is-inverse-of hasMemberGroup [of Role]

 

o   hasAssignedGroup [of Actor] is-inverse-of hasMemberActor [of Group]

o   hasAssignedGroup [of Group] is-inverse-of hasMemberGroup [of Group]

 

Also

 

o   hasParent [of Role] is-inverse-of hasRole [of Scope]

o   hasParent [of Group] is-inverse-of hasGroup [of Scope]

o   hasParent [of Actor] is-inverse-of hasActor [of Community]

 

These inverse property axioms imply that the super-group cannot be the parent of the sub-group. We don’t want to define Group as a parent of Actor, and for the same reasoning, we don’t define a super Group as a parent of another Group. Parent of Actor must be Community. Parent of Group or Role must be Scope.

 

·         Laura asked if she were to classify a set of persons in a department, between Community or Group in ICOM, which concept should be used? Eric suggested that the department be represented by an instance of Community to provide the directory for that department (borrowing the concepts from LDAP) and also to provision the personal and team spaces for the persons in the department to collaborate.

 

If we need to define access control policies, then we can define an instance of Group, with the persons form the community as member actors of the group. The group can be used as subjects of the access control entry in ACL. Group is Addressable, i.e. can have email and IM addresses, so the same group can be used as email distribution list or presence buddy list. ICOM Group unifies the concepts of access control groups, distribution lists, and presence buddy lists.

 

Both Community and Group are addressable, however we can define a subtle distinction between Community and Group. For example, Community address need not be a distribution list. When we send an email to a community, the email is delivered to the default inbox of the community. In contrast, Group is a distribution list so that an email sent to the group address is distributed to the members of the group.

 

4. ICOM use cases for the workshop

 

Eric apologized for not getting the ICOM draft specifications (following the OASIS templates) ready for the workshop. The TC was preoccupied with the development of the models and use cases. Patrick commented that the models and use cases are beneficial when drafting the specifications, so the current focus and efforts on the technical developments is appropriate.

 

5. AOB

 

The TC Meeting was adjourned.