[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes of ICOM TC Meeting, September 16, 2009
Minutes of ICOM TC Meeting, September 16, taken by Eric S.
Chan Agenda 1. Roll Call 2. Approve draft minutes from September 2 TC Meeting 3. Review the OO and RDF model 4. AOB 1. The following eligible members were present Deirdre Lee Laura Dragan Marc Pallot Rafiul Ahad Eric Chan 2. Draft minutes from September 2 TC Meeting was approved. 3. Review the draft RDF and UML model The following notes were transcribed from the audio
recording of the TC meeting. a. Review
of the draft RDF model in http://www.oasis-open.org/apps/org/workgroup/icom/email/archives/200909/msg00005.html. Deirdre and Laura proposed a naming convention for RDF
properties that would distinguish a property by the class of object to which
the property is applied, i.e. the domain of the property. By using a distinguished
property, the range of the property can be specialized per the domain. The
distinguished property name in RDF is derived from the object-oriented
attribute name by appending the domain name to the OO attribute name. For OO
aggregate attributes, the plural attribute name is converted to singular
property name in RDF. The same cardinality is applied to the OO attribute and
the corresponding RDF property. The prefix “has” is omitted for the
data type properties, except for the Boolean properties which use the prefix
“is.” For example, the UML association “parents” is
represented by the RDF property hasParentOfGroup when it is applied to Group,
hasParentOfActor when applied to Actor, and hasParentOfSpace when applied to
Space. Similarly, the UML association “elements” is represented by
the RDF properties hasElementOfSpace and hasElementOfHeterogeneousFolder when
applied, respectively, to Space and HeterogeneousFolder. RDF properties
hasParentOf[Domain] and hasElementOf[Domain] have the same cardinality as the
OO aggregate associations “parents” and “elements.” The
OO non-aggregate associations such as owner, modifiedBy, createdBy, etc, are
mapped, respectively, to hasOwnerOfEntity, hasModifiedByOfEntity,
hasCreatedByOfEntity properties in RDF. The prefix “has” is omitted
from the RDF properties modifiedOnOfEntity and createdOnOfEntity, whose ranges
are the data type Date. The RDF properties modifiedOnOfEntity and
createdOnOfEntity are mapped, respectively, to the OO data type attributes modifiedOn
and createdOn. Deirdre and Laura proposed to specify the non-aggregate
properties as functional property (nrl:FunctionalProperty). Laura indicated that a functional property can
have the cardinality of 0 or 1 and, therefore, allow the property to be
optional. For the mandatory non-aggregate properties, we need to impose the
cardinality constraint to exactly one. A question is whether a mandatory
property can be defined as a functional property with the cardinality exactly
one. Eric explained that “owner” is a mandatory property in Beehive
object model; the owner of the entity can always change the ACL of the entity. Laura mentioned that the RDF model would include the
super-property and sub-property relations among the distinguished properties. Eric
suggested that the property hierarchy should mirror the class hierarchy. For
example, “hasElementOfCalendar is a sub-property of hasElementOfFolder
property” to reflect the relation “Calendar is a subclass of Folder.”
Similarly, “hasParentOfSpace, hasParentOfSubject, and hasParentOfArtifact
are sub-properties of hasParentOfEntity property,” to reflect “Space,
Subject, and Artifact as subclasses of Entity” (see the UML class diagram
in Figure 1 of http://wiki.oasis-open.org/icom/Categorisation). Eric explained that ICOM may include concepts represented by
UML interfaces which cannot be directed instantiated, i.e. instances of an UML
interface must be instances of concrete classes that implement the interface. The
UML interface concepts will have counterparts in RDF. However, RDF schema, NRL,
or OWL do not support mechanisms to restrict the RDF counterparts of the UML
interfaces to have only instances that are required to be instances of some
concrete class concepts. Laura suggested that named graphs, defined in http://www.semanticdesktop.org/ontologies/2007/08/15/nrl/#3._NRL_Named_Graph_Extensions,
may be used to represent the UML interface counterparts in RDF. Eric indicated
that ICOM may also include abstract classes, such as Entity, Scope, Subject, and
Artifact in Figure 1 of http://wiki.oasis-open.org/icom/Categorisation,
which cannot be directly instantiated. NRL named graphs may represent the UML
interfaces but the problem remains at large for representing abstract classes. What
is needed is a common mechanism to represent the RDF counterparts for the UML
interfaces and abstract classes. Participants also discussed about a comment in Deirdre’s
message http://www.oasis-open.org/apps/org/workgroup/icom/email/archives/200909/msg00005.html:
“we propose that NRL is used as opposed to OWL (which addresses similar
needs) because: … inference in OWL is complex and may be
unnecessary for our needs, as was the case in Nepomuk, and OWL has an open
world assumption, whereas with the use of NRL we can adopt a closed world
assumption.” Eric recommended that it should still be possible (for
anyone who wishes to use OWL) to define the bindings of ICOM to OWL, as well as
NRL or other RDF schema extensions. b. Review
of Beehive’s UML model in http://wiki.oasis-open.org/icom/Categorisation. Eric started off by highlighting the three major branches of
concepts, namely Subject, Scope, and Artifact branches, in Beehive UML model in
Figure 1. The relationship objects, modeled by Bond in Beehive, do not belong
under any one of the three branches. Bond is a subclass of Entity that can relate
entities across branches of concepts or across scopes of containment. Eric
asked participants to point out the exceptions when they see concepts for ICOM that
may not fall within any of the three branches of concepts. ICOM OO model will adhere to the single inheritance class
hierarchy. This simplifies the bindings of ICOM to common OO languages such as Java
and C#. In most cases, the UML interfaces (also known as mixed-in types or
auxiliary concepts) can serve the same purpose without employing multiple
inheritances. Eric gave the Accessor, Container, and ArtifactContainer concepts,
see Figure 1 of http://wiki.oasis-open.org/icom/Categorisation,
as examples of auxiliary concepts (or mixed-in types) that are represented by
UML interfaces, to represent the union of some concepts from different branches
of subclasses of Entity. For example, Accessor is a concept which is the union of
Group and Actor. Accessor interface can have only instances which are instances
of either Group or Actor. This way we can define the owner attribute on Entity to
hold either a group or an actor. Thus a group of actors can co-own an entity. According
to Figure 1, Accessor differs from Subject by that Accessor excludes Role. ICOM
may use Accessor as subjects of ACL, thereby excluding Role from discretionary
access control model (DAC). Role can then be used exclusively as subjects of
role-based access control model (RBAC). Another example is Container interface to represent a
concept that includes Scope from the scope branch and Folder from the artifact
branch. Container carries or enforces the processes specified in terms of workflows
and rule-based policies. It allows one of the subclasses in artifact branch,
namely Folder, to emulate the container behavior typically associated with
Scope. Similarly, ArtifactContainer interface is a concept which is the union
of Space from the scope branch and Folder from the artifact branch. We constrained
the parents of Folder to ArtifactContainer (in RDF, the range for
hasParentOfFolder is specialized to ArtifactContainer) to imply that a folder
can be placed directly in a space or in another folder. Eric also noted that Parental is an interface concept which
allows some subclasses of Entity, such as email Message, to be parents of other
entities without becoming full-fledged containers. There is a parent-child
relationship between an email message and the attachments (replied-to messages,
forwarded messages, or documents) in the email message. An access control
policy can be defined around the parent-child relationship such that if one can
read the email message, one may also read the attachments. The top level concept in the UML model is the Identifiable
interface. Identifiable can represent the objects which are not entities but
can be uniquely identified by URI’s. These objects exist as parts of some
entities and their lifecycles are dependent on the entities. Deirdre asked whether the TC is decided on the above
concepts primarily derived from Beehive object model. She mentioned that
Ecospace adopts generic collaboration model that includes sites and different
concepts where the relationships are not exactly defined at the starting point.
The above concepts were basically centered around BOM, so she asked whether the
TC was open to other models for ICOM. Eric responded that the above concepts
are proposals from Oracle as a starting model but the TC is open to reviewing
other models to reconcile with them. Eric is hoping to see counter proposals
for the model and proposals to restructure the starting model to develop a draft
ICOM model. There are rooms for improvements in the starting model to make them
more general. If you have use cases which do not fit in the starting model,
then they are good reasons to improve the model. Eric cautioned against
reducing the number of concepts just to make the model more general but may end
up with a one-size-fit-all model that does not do anything particular. Eric explained the use-cases or scenarios behind the UML
collaboration diagrams in Figures 2 to 8 in http://wiki.oasis-open.org/icom/Categorisation.
The diagrams describe how the OASIS TC workspace and TC memberships can be
defined using the above model. Figure 2 defines a workspace membership level,
using a space, a group, a role, and a set of actors. The TC membership setup in
Figure 3 uses three occurrences of workspace membership level to define three
levels of TC membership, namely member, voting member, and observer. Figure 4
shows that the UML class schema in Figure 1 can capture the object
configuration in Figure 3. The roles and groups attributes in a TC workspace each
contains three elements, one for each level of membership. Figure 4 then shows
that the members, voting members, and observers are subsets of the members of
the OASIS community. The TC workspace is one of the spaces in the OASIS
community. Eric further elaborated that the OASIS Community also have a set of
roles and groups, so one can define OASIS staff or OASIS administrator roles
which can have administrative privileges that carry into the spaces contained
by the community, i.e. there is inheritance of roles form higher level scopes. Eric pointed to Figure 6 which shows different types of
folders. The heterogeneous folder is an unconstrained folder which can hold any
type of artifacts. It is used as an inbox for the workspace, to receive messages,
invitations, assignments, documents, etc. It is also used as a trash folder to
hold any artifacts deleted from the workspace, including documents, messages, calendar
occurrences, tasks, discussions, contacts, and folders. Other specialized
folders, such as Calendar, TaskList, AddressBook, etc., are constrained
folders. The constraint implies that a Calendar, which only holds occurrences,
cannot hold documents or messages. One may argue that there are valid use cases
to be able to place an agenda document for a meeting in the same calendar which
schedules the meeting. Eric explained that the constraint is imposed for
Calendar to relieve the calendar service providers from having to manage the
documents, messages, and other types of artifacts. The service providers for
other specialized folders may have similar legacy issues preventing them from managing
arbitrary artifacts. Laura asked how would the property hasElementOfFolder be
applied to the Calendar, which is supposed to override this super-property with
hasElementOfCalendar property. Would this mean that Calendar still holds the arbitrary
artifacts in the range of hasElementOfFolder property? Eric mentioned that this
is not an issue for OO representation where the subclass can override the type
of the attribute in the super-class with a narrower type. Eric will initiate a
discussion thread to review how the distinguished properties from super-classes
are inherited by subclasses in RDF. Marc asked whether we would need to introduce a specialized
folder for Blogs to provide additional structures such as cloud of tags, which are
not readily found in heterogeneous folders. Eric responded that there is an
intention to model the cloud of tags (and other metadata) for use with general
artifacts, and should be available for the HeterogeneousFolder. In this case, we
don’t need to introduce a specialized folder for Blogs. Marc was agreeable. The UML collaboration diagram in Figure 7 shows specialized
folders for a team workspace. Figure 8 shows how the object configuration in
Figure 7 can be captured by the schema for Space. Eric identified two open issues: 1. how to represent
abstract class and interface in RDF, 2. how to interpret the distinguished properties
inherited from super-classes in RDF. Eric requested Deirdre and Laura to
publish the RDF model in http://wiki.oasis-open.org/icom/Categorisation. 4. AOB Deirdre initiated a discussion of how ICOM will support the
concepts of Context and Process. These concepts are part of Ecospace but so far
have not been mentioned in ICOM. Eric agreed that the TC should review how to
best model the Context and Process. Eric acknowledged that context has not been modeled explicitly
by a class of its own. We were expecting that the contexts would emerge from
relationship among objects, i.e. they are aspects represented by object
relationships, such as message threads, discuss-this bonds, etc. This was why
we had been emphasizing the relationships or bonds for interlinking of objects
to enrich the contexts. Workspaces are persistent contexts for projects. Eric
compared the current approach to Google Wave which provides a container to
enrich the contexts. In Wave you can overlay the conversations through asynchronous
messages, instant messages, and real-time co-editing in one place to enrich the
contexts. The closest we have to the concept of Process are workflows
and policies in Beehive model. The workflows and policies can be attached to a Container.
In facts the concept of Container implies that there are processes in the container
to enforce the lifecycle of objects. For example, when a user uploads a
document into a container, an approval workflow process can be initiated for the
workspace coordinator to approve the document before it becomes accessible to
other members of the workspace. In addition to workflow, we also model Policy
which can be defined in terms of even-condition-action rules. The meeting was adjourned. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]