Draft Minutes of ICOM TC Meeting, September 2, 2009

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

Agenda

1. Roll Call

2. Approve draft minutes from August 19 TC Meeting

3. Review the minimal model of community, workspace, folder, artifact, and other high-level concepts for representation in RDF

4. AOB

1. The following eligible members were present

Deirdre Lee

Laura Dragan

Marc Pallot

Patrick Durusau

Rafiul Ahad

Eric Chan

2. Draft minutes from August 19 TC Meeting was approved.

3. Review the minimal model of community, workspace, folder, artifact, and other high-level concepts for representation in RDF

Laura provided the URL for Nepomuk Representational Language (NRL) which defines some RDF schema extensions (see http://www.semanticdesktop.org/ontologies/2007/08/15/nrl/). NRL is an upper ontology for Nepomuk that is meant for defining several ontologies in different domains. For ICOM to provide more direct mapping between OO and RDF representations, we need richer schema extension for RDF. Laura and Eric discussed about how NRL may be leveraged for ICOM.

Before the meeting, Eric sent out the UML diagram of high-level concepts for ICOM. This diagram was created from Java classes with annotations using Borland Together Architect. This format has an advantage in that you can edit the Java classes directly, even if you don’t have the modeling tool.

Eric proposed to define an isomorphic representation of this UML model in RDF. In the model, Community has two attributes actors and workspaces, which are plural names. How can these two properties be represented in RDF without changing the names. In RDF, one can use the same property actor to add multiple actors to a community. However this property has singular name, i.e. OO attribute actors become RDF property actor. On the other hand, Artifact has two attributes modifiedBy and createdBy, which should always have the cardinality of 0 or 1. These attributes have singular names in OO. How do we specify in RDF that there is no more than one occurrence of the properties modifiedBy and createdBy for an artifact.

Laura pointed out that Actor and Community have many-to-many relationship, but the UML diagram showed the cardinality 1 on Community. Eric answered that was a misrepresentation in the diagram, the cardinality should be one or more (Eric would correct the diagram and send out a new version). Eric later found out the cardinality 1 was put there because of a bug in the UML tool.

Marc questioned what was meant by Actor. Eric responded that actor is broader than user, can include agent. It lets us define subclasses of Actor, such as User. Marc suggested to rename the attribute actors to members on Community, but keep the class name as Actor.

Eric prompted whether there were issues with the name Organization, whether we need a broader notion. Marc pointed out that Community can be within an organization, across organizations, and across enterprises. Marc also pointed out that we need to represent individuals who are not employees of the organization. In the diagram, organization is hierarchical, and enterprise is a root of the hierarchy. Deidre asked whether we can reduce the model for mapping to RDF. Rafiul suggested to remove Organization and Enterprise form the initial model.

We would maintain that an actor can be member of one or more parent communities, and a community or workspace can be part of one or more parent communities. The proposed UML model includes constraints on the parent attributes. For group and role, getParent is constrained to Scope, whereas for actor, getParent is constrained to Community. Since the parent of an actor is constrained to community, one cannot create actors under workspaces. Since the parent of a group or role is constrained to scope, which includes workspace, one can create groups and roles under a workspace, making workspaces self-contained with groups and roles for defining access control policies. Similarly, the parent of a folder is constrained to artifact container, which can be workspace or folder.

Rafiul mentioned the purpose of scope, in particular, which has to do with security. There is inheritance of roles from ancestor scopes. If you are administrator of the community above a workspace, you can be an administrator of the workspace as well.

Marc asked whether there are textual descriptions of these concepts. Eric replied that the descriptions were there in the document Oracle contributed to ICOM TC (see http://www.oasis-open.org/apps/org/workgroup/icom/download.php/31833/BeehiveObjectModel_ICOM.pdf). Eric would pull out the definitions from that document to combine the text descriptions with the UML model in the Wiki page at http://wiki.oasis-open.org/icom/Categorisation. Eric would also provide the use cases, examples of how to represent a project, define members, assign membership roles, create project folders, etc., using this model.

Marc considered how the access control policies shall be supported by the model. Rafiul and Eric offered to share Beehive’s experience of using basic discretionary access control lists, for read, write, create, delete on entities, to define access control policies for high-level operations such as invite members to a community or to a meeting. Invitation of participants can be defined using access rights on the group, role, actor objects for community or on the calendar objects for meeting.

Eric would send out an updated UML model, Java classes, textual definition of concepts, and use cases, via http://wiki.oasis-open.org/icom/Categorisation.

4. AOB

The meeting was adjourned.

icom message