[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [icom] Draft Minutes of ICOM TC Meeting, Aug 18, 2010
Correction: I need to revise the statement
below from agenda item 6. FolderContainer does not constrain the elements to
Folder. In order to allow Space to contain any artifact, not just folders, we
need to change the type of elements attribute in Space.
HeterogeneousFolder implements FolderContainer,
which does not constrain it from holding any type of artifacts. Thanks, Eric From: Eric Chan Minutes of ICOM TC Meeting, Aug
18, taken by Eric S. Chan 1. Roll Call 2. Approve draft minutes from Aug 4 TC Meeting
http://www.oasis-open.org/apps/org/workgroup/icom/email/archives/201008/msg00004.html
3. Status update of milestones 4. Review of discussion forum and mailing list model 5. Nominate a person to
investigate the mappings from ICOM Forum to Jive 6. Discuss how to specify the
mandatory and optional features of ICOM. 7. AOB 1. The following eligible members
were present Laura Dragan Deirdre Lee Peter Yim Patrick Durusau Eric Chan 2. Approve draft minutes from Aug
4 TC Meeting Approved. 3. Status update of milestones
For milestone
task #5. Eric will contact Robin Cover about writing a new Cover report to
replace the one at http://xml.coverpages.org/ni2009-01-07-a.html.
ICOM TC to supply the source material to Robin. Eric’s task to draft an
article for publication in other magazines is delayed. Laura
proposed to use wiki and assign part of the model to participants and write in
the wiki / oasis style doc the normative model - each concept with definition
and description of relations to other concepts. Patrick
and Eric to produce a draft doc as originally planned (task #8) before other
contributors add their assigned parts to the doc. Related
to task #9, Eric suggested to nominate a person to investigate the mappings
between ICOM and Jive. (see item 5 below). Will continue to look for sources of
other technologies. 4. Review of discussion forum and
mailing list model With regard to model adjustments,
participants commented. Laura
suggested to define properties that are optional for classes. This reduces the
number of classes. For example, merge UnifiedMessage with Message.
UnifiedMessage can represent discussion, email, instant message, etc. The CC
and BCC properties are optional, so when they do not apply to instant message,
they can be omitted for instant message. Eric’s responded it works
naturally for RDF model but does not work naturally for UML model. Laura voiced
more independence between RDF and UML model of ICOM. Peter
Yim comments include applying speech act. The model is currently
implementation/technology driven. Speech act can free the model from
implementation aspects. What
kind of speech act [1] or document act [2] are they? For example, are they one
of conversation, shared storage, shared view (wiki, web conference). [1]
cf. Austin, Searle, Flores & Winograd’s works;
see aso: http://en.wikipedia.org/wiki/Illocutionary_act
[2]
cf. Barry Smith’s work
Peter’s other comments include difficulties due to the unstructured text
and unstructured collaboration, and the real world is not hierarchical.
Patrick commented about adjustment to the model can be driven by data analysis,
such as advocated by Deirdre and Laura. He reiterated importance of roundtrip
mapping without loss of information. Eric
commented that ICOM is more or less an integration ontology that ties together
the technology driven concepts, such as InstantMessage, UnifiedMessage
including email, voice, fax, MailingListMessage, BlogPost, WikiPage, Document,
etc. A conversation (in reference to speech act) can include artifacts from
multiple channels/protocols/technologies such as XMPP, SMTP, Twitter, CMIS
repository, conference transcript, and whatever is defined in the ICOM space.
The framework ties things together (into conversations, with the contexts,
along task/project activities, what you would) using the generic concepts. The
generic concepts are primarily represented by UML interfaces and abstract
classes. The type of the attributes in the framework classes are primarily of
generic concepts. Implementation/technology concepts are mostly specialized
classes which can be separated into extension modules. The following discussion
highlighted his approach: Introduce
the concept of Discussion, which goes with DiscussionContainer, to provide a
generic model of “threaded conversations.” Both DiscussionContainer
and Discussion are UML interfaces. He also adjusted the type of elements in
ArtifactContainer to an interface called Element. Previously the type of
elements was the abstract class Artifact. This is a framework defined entirely
of UML interfaces. The two key features here are aggregation
(DiscussionContainer aggregates the Discussion elements by topic) and threading
(InReplyTo property represents the threads). Figure
1 Generic model of threaded conversations (Normative) One
implementation of the Discussion model is specified as an extension module
using two specialized concepts Forum and Topic that offer moderated
conversation threads and hierarchical sub-forums and topics (see Figure 2).
This model can support any type of discussion artifacts: notice that we use
Discussion (interface) instead of DiscussionMessage (implementation class) as
elements of Topic. Discussion can include DiscussionMessage,
MailingListMessage, or other types that may be introduced through extension
modules. Figure
2 Generic Model of Forum and Topic can support any type of discussion artifacts
(it is defined in an extension module) The Forum and Topic module provides
the DiscussionMessage (see Figure 3), which is a minimal implementation of the
Discussion. The DiscussionMessage is a component of the Forum and Topic module,
although Forum and Topic can contain other implementations of Discussion. Figure
3 DiscussionMessage is a minimal implementation of Discussion (it is part of
the Forum and Topic extension module) The
DiscussionContainer and Discussion can be implemented in another way using
MailingList and MailingListMessage as shown in Figure 4. The MailingList does
not offer the hierarchical structures provided by Forum, sub-Forum, and Topic.
MailingList and MailingListMessage are part of another extension module
separated from the Forum and Topic extension module. Figure
4 Another extension module that implements MailingList (non-normative) An
example implementation of MailingListMessage shown below can be described and
clearly stated as non-normative. Figure
5 An implementation of MailingListMessage (non-normative) 5. Nominate a person to
investigate the mappings from ICOM Forum to Jive. Chancellor
Pascale expressed interest and the TC nominated him as primary investigator for
this area. Chance
should also investigate mappings of ICOM to other concepts in Jive (see the API
docs below) 6. Discuss how to specify the
mandatory and optional features of ICOM. The
following two adjustments to the core model are necessary to avoid over
specification of the model. ·
We defined Owner as
a generic concept in the framework. The type of owner attribute in Entity is
Owner, which is more generic than User. It is mandatory for User to subclass
Owner. It should be optional for Group to subclass Owner.
7. AOB The TC Meeting was adjourned. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]