Draft Minutes of ICOM TC Meeting, October 28, 2009

Minutes of ICOM TC Meeting, October 28, taken by Eric S. Chan

Agenda

1. Roll Call

2. Approve draft minutes from September 16, 30, and October 14 TC Meetings

3. Discuss the ballot for draft model of ICOM

4. AOB

1. The following eligible members were present

Laura Dragan

Deirdre Lee

Peter Saint-Andre

Patrick Durusau

Rafiul Ahad

Eric Chan

2. Approve draft minutes from September 16, 30, and October 14 TC Meetings

The draft minutes were approved.

3. Discuss the ballot for draft model of ICOM

Peter expressed concern about a ballot to approve the draft model at this early stage. One of his concerns was that the ballot may give the wrong impression of ICOM framework becoming fixed by the ballot. Participants at the meeting agreed that the ICOM framework should be allowed to evolve freely to accommodate additional use cases. Inputs from any new TC members may influence how ICOM framework evolves. Participants were agreeable for the TC to adopt the working draft model based on the proposals in http://wiki.oasis-open.org/icom/Categorisation without a ballot. Eric would create a new wiki page http://wiki.oasis-open.org/icom/DraftModel to distill the concepts and model to represent the working draft model in ICOM namespace. The participants may continue to use http://wiki.oasis-open.org/icom/Categorisation to combine the concepts from different namespaces, such as Beehive, SIOC, Ecospace, etc.

4. AOB

Participants reviewed the UML diagram in Figure 1 of http://wiki.oasis-open.org/icom/Categorisation. Eric explained that the UML model for ICOM would adhere to single inheritance class hierarchy but may include UML interfaces (which is a kind of classifier) to represent the “auxiliary” concepts. Interfaces in ICOM can cause complications for binding ICOM to XML schema. Nevertheless, Eric argued that the interfaces improved the versatility of the model. Eric gave Accessor interface as an example to support this point in the following scenario.

The model for Entity includes an attribute to represent the owner of the entity. The type of this attribute can be Subject or Actor. If we were to use Subject as the type for owner attribute, then Role and Group can be owners of the entities. There is a desire to allow a group of actors to co-own an entity. It makes the model more versatile. On the other hand ownership is a concept akin to discretionary access control (DAC) policies but orthogonal to role-base access control (RBAC) policies. We define Accessor as an UML interface to represent the union of Group and Actor which can be owners of entities and also be subjects of ACL in DAC model. Potentially, we may define another interface DistributionList to represent the union of Role and Group, which can be part of an operation to distribute a message to the members of a role or group. UML interfaces afford the flexibility to define the concepts to optimize the versatility of the ICOM model.

Deirdre argued that the TC should not have to decide upfront whether a concept is an interface or a class. Eric agreed that interfaces were needed only for UML model. RDF supports multiple inheritances so all concepts will be modeled as classes in RDF. In addition, the classification and subsumption relations can be derived as entailments in RDF, allowing more fluidity for the RDF model. In contrast the classification and subsumption relations must be specified in the UML model, which is consequently more rigid and schema driven. There will be interplay of both UML and RDF modeling methodologies influencing the isomorphic representations of ICOM draft model.

Eric would update the UML diagram in Figure 1 to introduce a new interface called FolderContainer, which is a specialization of ArtifactContainer.

The meeting was adjourned.

icom message