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
|
5 |
Write and submit ICOM article, ComputerWorld InformationWeek,
contact the authors, with Oracle marketing |
Eric, Deirdre, Laura for
content Peter,
Stefan, Patrick for concepts, strategies |
In
Progress |
|
6 |
Translate
Ontolog data into ICOM OO and ICOM RDF |
Peter
Yim (for Ontolog content), Eric (for OO), DERI (for RDF) |
Completed |
|
7 |
Demo and
present ICOM to the “OWL-2 tools and applications” Ontolog panel |
Peter
Yim, Eric, Allan Wu, DERI, Ian Horrocks |
Completed |
|
8 |
Write a
draft specification |
Eric,
Patrick |
In Progress |
|
9 |
Write the
state of the art |
DERI,
(Peter Yim), (Eric) |
In Progress |
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.
·
We defined
FolderContainer to constrain the elements to Folder, i.e. containers that
implement this interface can only contain Folders. It is mandatory for Space to
implement ArtifactContainer. It should be optional for Space to implement
FolderContainer. In some cases an implementation of the Space may hold
artifacts such as Messages or Documents, not just Folders.
7. AOB
The TC Meeting was adjourned.