Draft Minutes of ICOM TC Meeting, September 15, 2010

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

Agenda

1. Roll Call

2. Review the updated draft

3. AOB

1. The following eligible members were present

Deirdre Lee

Laura Dragan

Patrick Durusau

Eric Chan

2. Review the updated draft

Participants reviewed the outline of the draft specification. The outline shows that the classes in the Core model are grouped into main branch, subject branch, scope branch, and artifact branch. Classes in the main branch are top level classes, including Entity. The subclasses of Entity are grouped into three branches. The Core model includes Access Control List and Metadata classes.

Eric pointed out the names of some of the attributes are changed to match the name of attributes in CMIS specification.

Eric requested Deirdre and Laura to review the implication of primary/main class on single inheritance. The RDF representation should observe that a class must not extend from two primary/main classes. For example, a class must not extend from Subject and Artifact classes. This restriction is implicit in some language bindings, for example in Java binding, it is not possible by the syntax of the Java language for a class to extend from Subject and Artifact classes. ICOM compliant representation in RDF must observe this rule for the RDF data to be interchangeable with the Java implementations. The mixin class supports multiple inheritance, but there is no RDF notation to differentiate primary class vs. mixin class. Similarly there is no notation to define an abstract class.

Patrick insisted that the ICOM model should have the fidelity for roundtrip mapping to/from the models in other standards. For example, MIME standard defines two MIME header attributes InReplyTo and References. ICOM represents several attributes from MIME header as first class properties, such as to, cc, bcc, replyTo, From, etc., but has not defined the InReplyTo and References headers as first class properties of ICOM. Participants reviewed the issues involved in representing the InReplyTo and References attributes.

Eric explained that InReplyTo and References attributes are used by the email clients to render the threads. The email ids are generated and assigned by the clients and propagated in the InReplyTo and References attributes. The clients correlate the email ids of the email messages to render the message threads. Sometimes the clients need to build message threads among the messages downloaded from the server and messages in local folders and mbox archives. Since the server’s role is to persist the client supplied email ids with the messages, these two attributes are represented as part of the MimeHeader attribute in UnifiedMessage in ICOM. If we want to represent these two attributes as first class properties in ICOM, the values need to be represented as strings. These unstructured string values deviate from the design of ICOM in other areas where such attributes would contain references to artifacts or unified messages instead of strings. If we were to represent them as references to artifacts, the attributes will contain object ids assigned by the services. The object ids are different from email ids and are not useful for the clients to correlate with email ids of messages in other archives to render the threads.

Patrick pointed out that RevisionOf is a relation between documents that also constitute the conversation threads. Eric argued that other types of artifacts may need similar attributes of different names to represent the threads among artifacts. He is concerned that an attribute like InReplyTo may not be suitable for all types of artifacts, such as Document. Bond or Relationship can be used by the applications to extend the type and name of attributes as needed for different application domains, such as legal, finance, retail, etc.

Laura argued that some of the attributes, such as References, InReplyTo, Revision are fundamental, mundane features of the artifacts that they should be defined as first class properties in ICOM. Relationship/Bond are for less common attributes that the applications may add to the model.

This issue remained open. TC members to study whether Bond/Relationship may be more seamlessly in UML and RDF for representing the threads among all types of artifacts.

Participants studied how to model the elements of ICOM Space. Some service providers may allow arbitrary artifacts to be included among the elements of Space. Other service providers may constrain the elements of Space to include only Folders. To accommodate different capabilities of the service providers, ICOM should define implementation-dependent type for elements of space. We can introduce a mixin class called SpaceItem. ICOM defines that Folder extends from SpaceItem. It is an implementation-dependent option for Artifact to extend from SpaceItem. This implementation-dependent definition is also used in the mixin class Owner. ICOM defines that Actor extends from Owner and defines an implementation-dependent option for Group to extend from Owner.

3. AOB

The TC Meeting is adjourned.

icom message