Minutes of ICOM TC Meeting, September 16, taken by Eric S. Chan

Agenda

1. Roll Call

2. Approve draft minutes from September 2 TC Meeting

3. Review the OO and RDF model

4. AOB

1. The following eligible members were present

Deirdre Lee

Laura Dragan

Marc Pallot

Rafiul Ahad

Eric Chan

2. Draft minutes from September 2 TC Meeting was approved.

3. Review the draft RDF and UML model

The following notes were transcribed from the audio recording of the TC meeting.

a. Review of the draft RDF model in
http://www.oasis-open.org/apps/org/workgroup/icom/email/archives/200909/msg00005.html.

Deirdre and Laura proposed a naming convention for RDF properties that would
distinguish a property by the class of object to which the property is applied,
i.e. the domain of the property. By using a distinguished property, the range of
the property can be specialized per the domain. The distinguished property name
in RDF is derived from the object-oriented attribute name by appending the
domain name to the OO attribute name. For OO aggregate attributes, the plural
attribute name is converted to singular property name in RDF. The same
cardinality is applied to the OO attribute and the corresponding RDF property.
The prefix "has" is omitted for the data type properties, except for the Boolean
properties which use the prefix "is."

For example, the UML association "parents" is represented by the RDF property
hasParentOfGroup when it is applied to Group, hasParentOfActor when applied to
Actor, and hasParentOfSpace when applied to Space. Similarly, the UML
association "elements" is represented by the RDF properties hasElementOfSpace
and hasElementOfHeterogeneousFolder when applied, respectively, to Space and
HeterogeneousFolder. RDF properties hasParentOf[Domain] and hasElementOf[Domain]
have the same cardinality as the OO aggregate associations "parents" and
"elements." The OO non-aggregate associations such as owner, modifiedBy,
createdBy, etc, are mapped, respectively, to hasOwnerOfEntity,
hasModifiedByOfEntity, hasCreatedByOfEntity properties in RDF. The prefix "has"
is omitted from the RDF properties modifiedOnOfEntity and createdOnOfEntity,
whose ranges are the data type Date. The RDF properties modifiedOnOfEntity and
createdOnOfEntity are mapped, respectively, to the OO data type attributes
modifiedOn and createdOn.

Deirdre and Laura proposed to specify the non-aggregate properties as functional
property (nrl:FunctionalProperty). Laura indicated that a functional property
can have the cardinality of 0 or 1 and, therefore, allow the property to be
optional. For the mandatory non-aggregate properties, we need to impose the
cardinality constraint to exactly one. A question is whether a mandatory
property can be defined as a functional property with the cardinality exactly
one. Eric explained that "owner" is a mandatory property in Beehive object
model; the owner of the entity can always change the ACL of the entity.

Laura mentioned that the RDF model would include the super-property and
sub-property relations among the distinguished properties. Eric suggested that
the property hierarchy should mirror the class hierarchy. For example,
"hasElementOfCalendar is a sub-property of hasElementOfFolder property" to
reflect the relation "Calendar is a subclass of Folder." Similarly,
"hasParentOfSpace, hasParentOfSubject, and hasParentOfArtifact are
sub-properties of hasParentOfEntity property," to reflect "Space, Subject, and
Artifact as subclasses of Entity" (see the UML class diagram in Figure 1 of
http://wiki.oasis-open.org/icom/Categorisation).

Eric explained that ICOM may include concepts represented by UML interfaces
which cannot be directed instantiated, i.e. instances of an UML interface must
be instances of concrete classes that implement the interface. The UML interface
concepts will have counterparts in RDF. However, RDF schema, NRL, or OWL do not
support mechanisms to restrict the RDF counterparts of the UML interfaces to
have only instances that are required to be instances of some concrete class
concepts. Laura suggested that named graphs, defined in
http://www.semanticdesktop.org/ontologies/2007/08/15/nrl/#3._NRL_Named_Graph_Extensions,
may be used to represent the UML interface counterparts in RDF. Eric indicated
that ICOM may also include abstract classes, such as Entity, Scope, Subject, and
Artifact in Figure 1 of http://wiki.oasis-open.org/icom/Categorisation, which
cannot be directly instantiated. NRL named graphs may represent the UML
interfaces but the problem remains at large for representing abstract classes.
What is needed is a common mechanism to represent the RDF counterparts for the
UML interfaces and abstract classes.

Participants also discussed about a comment in Deirdre's message
http://www.oasis-open.org/apps/org/workgroup/icom/email/archives/200909/msg00005.html:
"we propose that NRL is used as opposed to OWL (which addresses similar needs)
because: . inference in OWL is complex and may be unnecessary for our needs, as
was the case in Nepomuk, and OWL has an open world assumption, whereas with the
use of NRL we can adopt a closed world assumption." Eric recommended that it
should still be possible (for anyone who wishes to use OWL) to define the
bindings of ICOM to OWL, as well as NRL or other RDF schema extensions.

b. Review of Beehive's UML model in
http://wiki.oasis-open.org/icom/Categorisation.

Eric started off by highlighting the three major branches of concepts, namely
Subject, Scope, and Artifact branches, in Beehive UML model in Figure 1. The
relationship objects, modeled by Bond in Beehive, do not belong under any one of
the three branches. Bond is a subclass of Entity that can relate entities across
branches of concepts or across scopes of containment. Eric asked participants to
point out the exceptions when they see concepts for ICOM that may not fall
within any of the three branches of concepts.

ICOM OO model will adhere to the single inheritance class hierarchy. This
simplifies the bindings of ICOM to common OO languages such as Java and C#. In
most cases, the UML interfaces (also known as mixed-in types or auxiliary
concepts) can serve the same purpose without employing multiple inheritances.
Eric gave the Accessor, Container, and ArtifactContainer concepts, see Figure 1
of http://wiki.oasis-open.org/icom/Categorisation, as examples of auxiliary
concepts (or mixed-in types) that are represented by UML interfaces, to
represent the union of some concepts from different branches of subclasses of
Entity.

For example, Accessor is a concept which is the union of Group and Actor.
Accessor interface can have only instances which are instances of either Group
or Actor. This way we can define the owner attribute on Entity to hold either a
group or an actor. Thus a group of actors can co-own an entity. According to
Figure 1, Accessor differs from Subject by that Accessor excludes Role. ICOM may
use Accessor as subjects of ACL, thereby excluding Role from discretionary
access control model (DAC). Role can then be used exclusively as subjects of
role-based access control model (RBAC).

Another example is Container interface to represent a concept that includes
Scope from the scope branch and Folder from the artifact branch. Container
carries or enforces the processes specified in terms of workflows and rule-based
policies. It allows one of the subclasses in artifact branch, namely Folder, to
emulate the container behavior typically associated with Scope. Similarly,
ArtifactContainer interface is a concept which is the union of Space from the
scope branch and Folder from the artifact branch. We constrained the parents of
Folder to ArtifactContainer (in RDF, the range for hasParentOfFolder is
specialized to ArtifactContainer) to imply that a folder can be placed directly
in a space or in another folder.

Eric also noted that Parental is an interface concept which allows some
subclasses of Entity, such as email Message, to be parents of other entities
without becoming full-fledged containers. There is a parent-child relationship
between an email message and the attachments (replied-to messages, forwarded
messages, or documents) in the email message. An access control policy can be
defined around the parent-child relationship such that if one can read the email
message, one may also read the attachments.

The top level concept in the UML model is the Identifiable interface.
Identifiable can represent the objects which are not entities but can be
uniquely identified by URI's. These objects exist as parts of some entities and
their lifecycles are dependent on the entities.

Deirdre asked whether the TC is decided on the above concepts primarily derived
from Beehive object model. She mentioned that Ecospace adopts generic
collaboration model that includes sites and different concepts where the
relationships are not exactly defined at the starting point. The above concepts
were basically centered around BOM, so she asked whether the TC was open to
other models for ICOM. Eric responded that the above concepts are proposals from
Oracle as a starting model but the TC is open to reviewing other models to
reconcile with them. Eric is hoping to see counter proposals for the model and
proposals to restructure the starting model to develop a draft ICOM model. There
are rooms for improvements in the starting model to make them more general. If
you have use cases which do not fit in the starting model, then they are good
reasons to improve the model. Eric cautioned against reducing the number of
concepts just to make the model more general but may end up with a
one-size-fit-all model that does not do anything particular.

Eric explained the use-cases or scenarios behind the UML collaboration diagrams
in Figures 2 to 8 in http://wiki.oasis-open.org/icom/Categorisation. The
diagrams describe how the OASIS TC workspace and TC memberships can be defined
using the above model. Figure 2 defines a workspace membership level, using a
space, a group, a role, and a set of actors. The TC membership setup in Figure 3
uses three occurrences of workspace membership level to define three levels of
TC membership, namely member, voting member, and observer. Figure 4 shows that
the UML class schema in Figure 1 can capture the object configuration in Figure
3. The roles and groups attributes in a TC workspace each contains three
elements, one for each level of membership. Figure 4 then shows that the
members, voting members, and observers are subsets of the members of the OASIS
community. The TC workspace is one of the spaces in the OASIS community. Eric
further elaborated that the OASIS Community also have a set of roles and groups,
so one can define OASIS staff or OASIS administrator roles which can have
administrative privileges that carry into the spaces contained by the community,
i.e. there is inheritance of roles form higher level scopes.

Eric pointed to Figure 6 which shows different types of folders. The
heterogeneous folder is an unconstrained folder which can hold any type of
artifacts. It is used as an inbox for the workspace, to receive messages,
invitations, assignments, documents, etc. It is also used as a trash folder to
hold any artifacts deleted from the workspace, including documents, messages,
calendar occurrences, tasks, discussions, contacts, and folders. Other
specialized folders, such as Calendar, TaskList, AddressBook, etc., are
constrained folders. The constraint implies that a Calendar, which only holds
occurrences, cannot hold documents or messages. One may argue that there are
valid use cases to be able to place an agenda document for a meeting in the same
calendar which schedules the meeting. Eric explained that the constraint is
imposed for Calendar to relieve the calendar service providers from having to
manage the documents, messages, and other types of artifacts. The service
providers for other specialized folders may have similar legacy issues
preventing them from managing arbitrary artifacts.

Laura asked how would the property hasElementOfFolder be applied to the
Calendar, which is supposed to override this super-property with
hasElementOfCalendar property. Would this mean that Calendar still holds the
arbitrary artifacts in the range of hasElementOfFolder property? Eric mentioned
that this is not an issue for OO representation where the subclass can override
the type of the attribute in the super-class with a narrower type. Eric will
initiate a discussion thread to review how the distinguished properties from
super-classes are inherited by subclasses in RDF.

Marc asked whether we would need to introduce a specialized folder for Blogs to
provide additional structures such as cloud of tags, which are not readily found
in heterogeneous folders. Eric responded that there is an intention to model the
cloud of tags (and other metadata) for use with general artifacts, and should be
available for the HeterogeneousFolder. In this case, we don't need to introduce
a specialized folder for Blogs. Marc was agreeable.

The UML collaboration diagram in Figure 7 shows specialized folders for a team
workspace. Figure 8 shows how the object configuration in Figure 7 can be
captured by the schema for Space.

Eric identified two open issues: 1. how to represent abstract class and
interface in RDF, 2. how to interpret the distinguished properties inherited
from super-classes in RDF. Eric requested Deirdre and Laura to publish the RDF
model in http://wiki.oasis-open.org/icom/Categorisation.

4. AOB

Deirdre initiated a discussion of how ICOM will support the concepts of Context
and Process. These concepts are part of Ecospace but so far have not been
mentioned in ICOM. Eric agreed that the TC should review how to best model the
Context and Process.

Eric acknowledged that context has not been modeled explicitly by a class of its
own. We were expecting that the contexts would emerge from relationship among
objects, i.e. they are aspects represented by object relationships, such as
message threads, discuss-this bonds, etc. This was why we had been emphasizing
the relationships or bonds for interlinking of objects to enrich the contexts.
Workspaces are persistent contexts for projects. Eric compared the current
approach to Google Wave which provides a container to enrich the contexts. In
Wave you can overlay the conversations through asynchronous messages, instant
messages, and real-time co-editing in one place to enrich the contexts.

The closest we have to the concept of Process are workflows and policies in
Beehive model. The workflows and policies can be attached to a Container. In
facts the concept of Container implies that there are processes in the container
to enforce the lifecycle of objects. For example, when a user uploads a document
into a container, an approval workflow process can be initiated for the
workspace coordinator to approve the document before it becomes accessible to
other members of the workspace. In addition to workflow, we also model Policy
which can be defined in terms of even-condition-action rules.

The meeting was adjourned.