Draft Minutes of ICOM TC Meeting, September 1, 2010

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

Agenda

1. Roll Call

2. Approve draft minutes from Aug 18 TC Meeting

http://www.oasis-open.org/apps/org/workgroup/icom/email/archives/201008/msg00011.html

3. Review of draft specification

4. Discuss JPA prototype framework. The source code is now available for sharing among TC members.

5. Review compatibility of ICOM Forum with Jive Forum.

6. AOB

1. The following eligible members were present

Laura Dragan

Chancellor Pascale

Patrick Durusau

Peter Yim

Eric Chan

2. Approve draft minutes from Aug 18 TC Meeting

Approved.

3. Review draft specification

The ICOM specification is based on the grammar used in CMIS specification. The ICOM specification includes class definition and property definition, similar to the class and property definitions of Document, Folder, Policy, and Relationship in CMIS specification. We try to make ICOM compatible with CMIS.

The metadata model of ICOM includes PropertyDefinition, PropertyType, and PropertyChoiceType which are based on the grammar used to define the ICOM classes and properties. It is reflective.

ICOM includes folder and document artifacts which can be based on of CMIS Folder and Document. ICOM also has Relationship (also known as Bond) which can based on CMIS Relationship. However ICOM classes for Scopes (Community and Space) and Subjects (Role, Group, Actor) do not have corresponding base types in CMIS. The Scope and Subject are considered extensions beyond the CMIS domain.

The ICOM draft specification includes changes to the model in the ICOM wiki page to conform to CMIS class definition grammar. For example, we renamed “isAggregate” to “cardinality” in PropertyDefinition.

The draft begins with the definition of classes in Core model followed by the definition of classes in extension modules. The properties defined in the draft specification are amenable to representation in RDF. All property names are defined in singular form in the draft. If the cardinality is multi, we will have to rename the property to plural form for UML and OO representations. The RDF property name can be in singular form as defined in the draft.

Participants reviewed the following features in the draft specification.

Instances of Entity differ from other objects by that each entity can have an ACL to control access to the entity. There are objects in ICOM, such as Content, MultiContent, and SimpleContent which are not entities and do not support ACL. Access to these embedded objects are controlled by the ACL of the parent entity.

There are property definitions of a class which specify that the properties are read-only and are not required for the applications to supply the values during the create or update operations. For example the parent attribute of Entity is read-only and not required. This is because the parent attribute is set by the service provider as part of an operation to add an entity to a container or to move an entity from one container to another container. The application cannot simply change the parent attribute.

We renamed a few classes in the draft specification. We renamed Container to Extent so that we can rename ArtifactContainer to Container. The auxiliary concept called Element, which was introduced in the previous TC Meeting, is renamed to Item. As a result we have the Container and Item classes in the draft specification that directly map to the concepts of Container and Item in SIOC ontology.

The auxiliary classes in previous versions are redefined as mixin classes in the draft specification. A mixin class defines attributes that can be inherited by classes extending from it (allowing multiple inheritance). The UML interfaces are classifiers but they don’t define attributes to be inherited by subclasses (or implementing classes). In java binding, the attributes of mixin will be mapped to getters and setters in the Java interfaces.

Patrick is reviewing how to disambiguate the roles of Service Provider (system) and Applications (client) as used in the specification.

4. Discuss JPA prototype framework. The source code is now available for sharing among TC members.

Eric announced that the JPA prototype source code for ICOM is available and can be provided to TC members for joint development. This JPA prototype can be part of a proposal to initiate a JSR for Java binding.

Peter announced, with regard to IPR issues for incubating the open sources, the upcoming open ontology (OOR-IPR) mini-series at Ontolog

see: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository_IPR/Discussion.

5. Review compatibility of ICOM Forum with Jive Forum.

Chancellor updated the Jive Forum model at http://wiki.oasis-open.org/icom/JiveForumMapping, where he described the mapping of

· Jive Forum to ICOM Forum,

· Jive ForumThread to ICOM Topic,

· Jive ForumMessage to ICOM DiscussionMessage, and

· Jive Attachment to ICOM Content.

Chancellor will investigate the use of ForumCategory to reflect the hierarchy of ICOM Forum.

6. AOB

Eric discussed with Robin Cover about publishing an article to explain the ICOM TC’s process to define the “open and generic model.” Robin requested material that supports the ICOM TC’s efforts to define the ”open and generic model,” for example how ICOM model is developed to support round-trip mapping to the models from other standards as well as commercial and open source services providers.

The TC Meeting was adjourned.

icom message