Draft Minutes of ICOM TC Meeting, July 22, 2009

Minutes of ICOM TC Meeting, July 22, taken by Eric S. Chan

Agenda:

1. Roll Call

2. Approve draft minutes from June 10, 24, and July 8 TC Meetings

3. Draft model of ICOM community, workspace, and containment

4. AOB

1. The following eligible members were present

Patrick Durusau

Deirdre Lee

Laura Dragan

Philip Arkcoll

Rafiul Ahad

Eric Chan

2. Draft minutes from June 10, 24, and July 8 TC Meetings were approved.

3. There were three areas of technical discussions for model of Community, Workspace, and containment.

The first area of discussion has implications for why ICOM should define a new contiguous ontology rather than import existing ontologies such as SIOC, FOAF, Dublin Core, BOM, etc. ICOM represents the convergence of content, communication, coordination, and social networking under the collaboration domain. SIOC core ontology is generic, however it relegates to the SIOC Type Module to define the communication concepts such as MailMessage, InstantMessage, and WikiArticle, which are specializations of sioc:Post. From a different perspective, BOM defines Message, InstantMessage, and DiscussionMessage as specializations of bom:Artifact, which also includes Document and WikiPage. In SIOC ontology sioc:Post is a subclass of sioc:Item and foaf:Document. This makes foaf:Document an abstract concept corresponding to bom:Artifact, but bom:Artifact includes bom:Document as a specialization. To give another example, if ICOM were to import FOAF and vCard, we would be spending some time reconciling the overlaps between these two ontologies. Rather than importing the existing ontologies and having to reconcile the different intentions of the imported ontologies, Eric argues that it will be more seamless to define a new contiguous ontology for ICOM. The new ICOM ontology can represent an upper ontology to integrate the existing ontologies.

The second area of discussion relates OO and RDF models. SIOC defines three different properties for hierarchical relationships. It uses dcterms:hasPart (from Dublin Core namespace) to relate community with space, sioc:has_parent to relate container with sub-container, and sioc:has_container to relate container with item. In contrast, BOM defines a polymorphic property bom:parent of bom:entity to relate parent entity with entity. Parent entity can be a Community, Workspace, Folder, etc. Participants discussed why SIOC needs three specialized properties, namely hasPart, has_parent, and has_container. Deidre suggested that one reason maybe for specifying the domain and range of the specialized properties. Deidre and Laura offered to investigate whether it would be feasible to represent these three sioc properties with one RDF property called icom:has_parent, perhaps by introducing the superclasses to unite the domains and ranges.

In an object-oriented language like Java, a subclass may override the type of an inherited attribute with a compatible type. For example, if the Entity class defines the parent attribute to refer to an Entity, the Workspace class can override the inherited parent attribute to refer to a Community, as long as Community is subclass of Entity. Similar the Document class can override the inherited parent attribute to refer to a Folder. The following notations describe the parent attribute getters overriding the return type of the getters in superclasses.

Entity.getParent() -> Entity

Workspace.getParent() -> Community

Document.getParent() -> Folder

Override of the inherited attribute may not work in some cases. For example, BOM defines a class “ArtifactContainer ::= Workspace | Folder” for the notation “Folder.getParent() -> ArtifactContainer” to specify that a folder can be placed only in a workspace or folder. However in the Java binding of this model, the Folder class cannot define the parent attribute to refer to ArtifactContainer, because ArtifactContainer is a Java interface that is not compatible with the parent attribute Folder inherits from its superclass, i.e. ArtifactContainer is not subclass of Entity.

The third area of discussion is about modeling multi-containment. To allow an entity to be placed in multiple parent containers, we need to define the parent attribute to refer to a set of entities. Effectively, the notations become:

Entity.getParent() -> Set<Entity>

Workspace.getParent() -> Set<Community>

Document.getParent() -> Set<Folder>

Folder.getParent() -> Set<ArtifactContainer>.

We may explicitly model the parent attribute to aggregate a complete set of containers that affect the access control policy for the entity. In RDF, such a closed collection is represented by rdf:List. However to support multi-containment across online communities or sites, we need to define a query for the containers of the entity. The query result can be represented by rdf:Bag to imply that there is no way to close this bag, i.e. there is no guarantee that "these are all the containers of the entity." For OO schema, we may specify the containers of the entity in terms of a JPQL or OCL query. For RDF ontology, we may specify the containers of the entity in terms of a SPARQL query.

4. AOB

Eric will contact Marc and Peter to get their feedbacks about these technical discussions.

The meeting was adjourned.

icom message