[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Draft Minutes of ICOM TC Meeting, June 2, 2010
|
I have attached a UML class
diagram that highlights the two properties assignedScope and personalSpace discussed
in the meeting minutes. I also highlighted the property teamSpace for Group. Regards, Eric From: Eric Chan Minutes of ICOM TC Meeting, June
2, taken by Eric S. Chan Agenda 1. Roll Call 2. Approve draft minutes from May 12, 19, and 26 TC
Meetings 3. Mapping between ICOM and SIOC+FOAF ontologies 4. ICOM use cases for the workshop 5. AOB 1. The following eligible members
were present Deirdre Lee Laura Dragan Patrick Durusau Marc Pallot Eric Chan 2. Approve draft minutes from May 12, 19, and 26 TC
Meetings Draft minutes were approved. 3. Mapping between ICOM and SIOC+FOAF ontologies a.
We will document Entity, scope, subject, artifact,
folder as abstract in RDF. In UML diagram abstract classes are depicted in
italic. Interface are marked by stereotype <<interface>>. b.
There are 10 or so concepts, such as addressable,
contact, participant, user, external person, that sounds similar to each other.
Deirdre and Laura suspect there may be redundancies of concepts. To eliminate
redundant concepts, they proposed to apply raw data to analyze the concepts. Participants reviewed the following
instance data: Role and Group are created in
scopes (created in scope). Community is a scope so can contain roles and
groups. Note that hasRole [of Scope] and
hasParent [of Role] are inverse properties. OASIS-Community
hasRole
OASIS-Staff-Role OASIS-Staff-Role
hasParent
OASIS-Community Need to define a new property
called hasAssignedScope for Role. OASIS-Staff-Role
hasAssignedScope OASIS-Community Note that hasSpace [of Community]
is inverse property of hasParent [of Space] OASIS-Community
hasSpace
OASIS-ICOM-TC-Space OASIS-ICOM-TC-Space
hasParent
OASIS-Community OASIS-Community
hasSpace
OASIS-CMIS-TC-Space OASIS-CMIS-TC-Space
hasParent
OASIS-Community OASIS-ICOM-TC-Space and
OASIS-CMIS-TC-Space are nested scopes in OASIS-Community. It makes sense
to have some inheritance axioms such that roles assigned to a scope are also
assigned to nested scopes, i.e. we can derive the following triples. OASIS-Staff-Role
hasAssignedScope OASIS-ICOM-TC-Space OASIS-Staff-Role
hasAssignedScope OASIS-CMIS-TC-Space Note that hasAssignedScope [of
Role] is not inverse property of hasRole [of Scope]. This way,
“OASIS-ICOM-TC-Space hasRole OASIS-Staff-Role” is not necessarily
true; OASIS-ICOM-TC-Space is not parent of OASIS-Staff-Role. c.
Before the meeting Eric sent out the UML model
introducing a new ExternalPerson concept, which maps to FOAF Person who
don’t have accounts for the site. FOAF person with user accounts for the
site are mapped to User in the ICOM site. Participants reviewed the need for
ExternalPerson concept. Eric pointed out that the ICOM service
providers need to differentiate User from ExternalPerson. For the User, the
ICOM service providers need to provision the personal space to manage the
default inbox folder, calendar, task list, etc., for email delivery, email
archiving, meeting invites, free-busy schedules, task assignments, etc. For
ExternalPerson, the ICOM service providers need to relay the messages, meeting
invites, task assignments, etc., to their home sites. Various alternative model of
ExternalPerson was discussed. We may use the same User concept with a Boolean
or AccountType property in the User for the system to determine whether the
user’s email are delivered to personal space inbox or relayed to an
external site. One key consideration is that it
should be seamless to reclassify an ExternalPerson to a User. The artifacts and
activities associated with the ExternalPerson should pass on to the User. Eric
pointed out that class change is possible in RDF model, but is a difficult
transformation in OO representation. A Boolean or AccountType property of User
can make it easier to reclassify an ExternalPerson to a User. Note: After the meeting Eric
recalled another reason for defining ExternalPerson as disjoint from User. User
has a property hasPersonalSpace, i.e. restrict the domain of hasPersonalSpace
property to User. If ExternalPerson is disjoint from User, hasPersonalSpace
property is not applicable to ExternalPerson. This implies that messages for
ExternalPerson must be relayed to an external site. ExternalPerson is different from
Contact. ExternalPerson is created in Community and visible in the directories.
Contact is an artifact in AddressBook, which is at least two levels below the
community. ExternalPerson can facilitate integration with presence service
gateways, through which User of a site can exchange presence status with
ExternalPerson, whose presence is managed by an external site. 4. ICOM use cases for the workshop Deirdre and Laura will prepare the
visual models for SemTech poster. Eric to print the poster. 5. AOB |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
