Draft Minutes of ICOM TC Meeting, September 29, 2010

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

Agenda

1. Roll Call

2. Approve draft minutes from Sept 1 and Sept 15 TC Meetings

http://www.oasis-open.org/apps/org/workgroup/icom/email/archives/201009/msg00004.html

http://www.oasis-open.org/apps/org/workgroup/icom/email/archives/201009/msg00005.html

3. Review the updated draft. Please note two major changes in the draft:

Changed the Document Version Control Model to match the CMIS version control model.

Changed and renamed the Bond to match the CMIS Relationship model.

See: http://www.oasis-open.org/apps/org/workgroup/icom/download.php/39592/icom-spec-draft-01a.doc

4. AOB

The following minutes were summarized from audio recording of 9/29 TC Meeting.

1. The following eligible members were present

Laura Dragan

Patrick Durusau

Eric Chan

2. Approve draft minutes.

The draft minutes were approved.

3. Review the updated draft.

Issue 1:

ICOM class definition includes primary and mixin classes with associated class axioms, such as

A particular class is either a primary class or a mixin class, i.e. it cannot be both.

Inheritance is constrained by:

o a primary class MUST extend from one and only one primary class;

o a primary or mixin class MAY extend from zero or more mixin classes;

o a mixin class MUST NOT extend from a primary class.

An object MUST be an instance of one and only one primary class.

Laura to investigate the implication of these axioms in RDF. Note: it may be possible to express these axioms in OWL 2.

Issue 2:

ICOM defines a mixin class called SpaceItem which represents the type of elements in ICOM Space. SpaceItem is a subclass of Item. Folder is a subclass of SpaceItem. It is optional for an implementation to include arbitrary Artifact (which includes Document or Message) among the SpaceItem. In the ICOM draft specification, we specify that Artifact may optionally extend from SpaceItem, which is expressed as follows:

Artifact extendsFrom

Value: icom:Entity, icom:Item, icom_meta:RelationshipBondable

Optional Value: icom:SpaceItem

SpaceItem constrains the type of elements that can be placed in Space. In an implementation that supports Artifact extending from SpaceItem, documents and messages can be placed directly in space. Typically, the elements of Space are constrained to Folders, such that documents and message are indirectly contained by space through folders.

The same expression is used to define that it is optional for Group to extend from Owner:

Group extendsFrom

Value: icom:Subject, icom_card:Addressable, icom_ac:Accessor

Optional Value: icom_ac:Owner

Patrick provided the following guideline on the definition of optional features as opposed than implementation-defined or implementation-dependent features.

We say that a feature is optional if you leave it out, it is not implemented. An implementation is still compliant with a standard without implementing the optional features. An optional feature is a capability that the core model is defining, so is not implementation-dependent or implementation-defined.

We use implementation-define to mean that a conforming implementation must document what choices it take. For example, ICOM specifies that “The Artifact class MAY include additional property definitions which are implementation-defined.” To achieve interoperability, it is necessary for the implementations to document the additional property definitions.

We use implementation-dependent to mean that everybody does it differently, so ICOM does not specify an implementation. For example, ICOM draft specifies that “The assignment of an objectId is implementation-dependent.” … “Each entity is assigned an internationalized resource identifier (IRI) composed from its objectId. The form of the IRI is implementation-dependent.”

Issue 3:

ICOM version control model closely mirrors CMIS version control model. ICOM versionable artifact is a counterpart of CMIS Document. Besides the Document, Folder, Relationship, and Policy classes in the CMIS domain model, CMIS uses an undefined concept called VersionSeries. ICOM defines the VersionSeries and Version classes.

ICOM extends CMIS version control model with a concept of RepresentativeCopy for versionable artifacts. The representative copy has an object id. When a document is placed under version control (versioned for the first time), the object id of the document becomes the object id of the representative copy of the version series and a new object id is assigned to a new version of the document. When a representative copy is checked out, a new object id is assigned to a new private working copy of the version series. A folder can contain a representative copy, a versioned copy, or a private working copy of an artifact. The content of the representative copy is a copy of the content of the private working copy or the latest versioned copy. In this way a representative copy provides a view of the latest state of a version series.

There are two subclasses of VersionControlMetadata, namely VersionSeries and Version. A representative copy does not represent a specific version. Therefore, the version control metadata of a versionable artifact is a version series object if the version type is a representative copy. The version control metadata is a version object if the version type is a versioned copy or a private working copy.

Issue 4:

ICOM relationship model also closely mirrors CMIS relationship model. A relationship definition object aggregates the relationship objects with a common meaning or facet. For example, applications can create a relationship definition object to represent a facet for “References” that may be derived from the MIME header attribute named “References” in email messages. Applications should create another relationship definition object to represent a facet for “InReplyTo” that may be derived from the MIME header attribute named “InReplyTo.” Applications can include arbitrary type of artifacts for References and InReplyTo relationship objects so that an email can reference documents and discussion posts.

The cardinality of Target property of CMIS Relationship is single. ICOM generalizes by letting the cardinality of Target property of ICOM Relationship be multi. ICOM uses RelationshipBondable mixin to define the type of entities that can be source or target of relationships. Relationship is the only subtype of Entity which is not relationship bondable.

The CMIS property definition metadata, which is mirrored by property definition metadata in ICOM, is used to define properties for primitive data types. These properties do not represent associations among objects (although property data type includes object ids, the object ids are stored by value, not by references). CMIS relationships are meant for representing associations among objects.

4. AOB

Eric identified four standard models, namely LDAP, iCalendar, BPEL4People, and vCard, for ICOM TC members to investigate for representation in (or mapping to) ICOM. ICOM will define the abstract concepts for each of these areas and provide a generic model for each of these areas in extension modules. It is possible that some of the standard models may be represented with sufficient fidelity by the generic models in ICOM extension modules. If more fidelity is needed, an implementation or service provider can extend the abstract concepts to plug in the specialized models into the ICOM framework.

For example, ICOM defines DiscussionContainer and Discussion as abstract concepts among the ICOM space items. ICOM also defines the Forum in an extension module that provides a generic model of DiscussionContainer. Implementations can extend DiscusssionContainer to plug in MailingList or MessageBoard model which more closely represents the discussion threads created with email Listserv http://en.wikipedia.org/wiki/LISTSERV. Please refer to Figures 1 to 5 in http://www.oasis-open.org/apps/org/workgroup/icom/email/archives/201008/msg00011.html.

Note: ICOM versionable artifact is closely mirroring the CMIS Document and version control model. The TC should do further investigation to ensure that ICOM can represent CMIS document and folder.

Participants discussed about designating a principal investigator for each of these areas: tentatively, Eric to investigate mapping a common LDAP directory schema to ICOM community for user and bookable resources, Laura and Deirdre to investigate mapping iCalendar and vCard to ICOM calendar and address book model, and Patrick to investigate mapping OASIS BPEL4People task to ICOM task model. Chancellor Pascale is already investigating how Jive forum can be represented by ICOM forum.

The TC can publish the result of these investigations in journals and news letter to demonstrate the openness of ICOM standard. Eric has asked Robin Cover for help with publications.

The TC Meeting was adjourned.

icom message