[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes of ICOM TC Meeting, May 19, 2010
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]