Draft Minutes of ICOM TC Meeting, September 16, 2009

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.

icom message