[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [icom] Draft Minutes of ICOM TC Meeting, July 22, 2009
Deidre, thanks for the
stimulating discussions. Here are my replies to your comments. a. [Deidre wrote] 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. [Eric] Most of the existing
ontologies are defined either for object-oriented model or RDF model. It is an
opportunity for the ICOM TC to define a new model that maps naturally and
simultaneously to object-oriented and RDF representations. ICOM can enhance the
interoperability between object-oriented and RDF programming models. Another
equally important objective for the ICOM TC is to define an upper ontology that
explicitly integrates and promotes interoperability among existing ontologies.
The existing data can be transformed into ICOM ontology to integrate with data
from other sources. The ICOM TC can emphasize object-oriented and RDF models
mapping, data integration, and interoperability. It is for the TC to define the
ICOM concepts to easily or directly map to concepts in SIOC, FOAF, BOM,
Nepomuk, etc. --- b. [Deidre wrote] 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. [Eric] We may need to define a
super concept for container and item for ICOM to be compatible with
object-oriented model. I believe SIOC ontology was primarily defined for RDF
model and since properties are first-class constructs in RDF, SIOC did not need
a super concept for container and item. --- c. [Deidre wrote] 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. [Eric] We should define the
properties to work simultaneously for both RDF and object-oriented models. RDF
lets us use the same property in any number of triples that assign multiplicity
of property values to an object, but such a property may not be represented
directly in object-oriented model. On the other hand, we may define the
property explicitly as a collection to be represented directly in
object-oriented and RDF models. Furthermore, we may explicitly specify whether
the collection in a property is an open set or closed set, which are applicable
to both object-oriented and RDF models. We should choose the representations
that work concomitantly for object-oriented and RDF models. Regards, Eric From: Eric Chan 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]