Hi Eric,
It seems I can’t email the mailing list, could you forward this for me please.
Thanks,
Deirdre
From: Lee, Deirdre
Sent: 31 July 2009 19:11
To: 'Eric Chan'; icom@lists.oasis-open.org
Subject: RE: [icom] Draft Minutes of ICOM TC Meeting, July 22, 2009
Hi Eric & all,
Regarding what we were discussing at the last TC meeting:
a.
The Semantic Web and Linked Data concept depends on the reuse of concepts and ontologies. If we were to define a new ontology for ICOM, we would lose the benefits of interoperability with existing data. I agree that SIOC and FOAF don’t cover all of the concepts that we need to define, and also that there are overlapping concepts/properties in the models. However, I believe it would be beneficial to facilitate data reuse and interoperability to classify ICOM concepts as sub-concepts of existing concepts whenever possible. SIOC was defined for a specific purpose (social online communities), as was FOAF, the Nepomuk ontologies, and BOM. For ICOM, we can include those concepts for each of the areas that we want to address, to create a more encompassing ontology for the collaboration domain. We already have a rich set of ontologies, whose elements can provide the building blocks for the ICOM ontology.
b.
This issue was discussed with the SIOC developers. dcterms:hasPart is not really used. sioc:has_container andsioc:has_parent are used to define two different relationships; that between a container and a container, and that between a container and an item. In online communities the sioc:has_container property between a container and an item is more commonly used (forums & posts). Therefore having a specific property for this relationship is valuable if, for example, an item is being queried. No additional reasoning is required to determine if an object is an item or a container. This level of detail may or may not be required in the ICOM ontology. I agree that it would probably make sense in ICOM to have a general ‘icom:item/artifact’ concept, that is a super concept of a container and an item.
c.
Regarding multi-containment, by default there are no restrictions in RDF regarding the number of property values for any property. This is due to the ‘open-world’ approach of ontology modeling. Therefore a specific container may have many values for the icom:has_parent property, i.e. may have many parents.
I hope provides a little food for thought before the next meeting J Have a nice weekend.
Deirdre
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.
a.
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.
b.
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.
c.
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.
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.38/2274 - Release Date: 07/31/09 05:58:00