[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [icom] Draft Minutes of ICOM TC Meeting, July 22, 2009
|
Forwarding Deirdre’s comments. From: Lee, Deirdre
[mailto:Deirdre.Lee@deri.org] 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
and sioc: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 From: Eric Chan
[mailto:eric-s.chan@oracle.com] 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]