[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Wiki page for proposed high-level ICOM concepts
Hello all, I have added new contents to the
wiki page(http://wiki.oasis-open.org/icom/Categorisation)
for definitions of high-level concepts, including community, space, scope, actor,
artifact, etc. I also updated the UML model (removed organization,
enterprise, and cardinality 1 error) and included some use cases for workspace
membership. I would be adding more use cases involving folders, calendars, task
lists, conferences, for workspaces. Please check the wiki page occasionally for
updates. Regards, Eric From: Eric Chan Minutes of ICOM TC Meeting, September 2, taken by Eric S.
Chan Agenda 1. Roll Call 2. Approve draft minutes from August 19 TC Meeting 3. Review the minimal model of community, workspace, folder,
artifact, and other high-level concepts for representation in RDF 4. AOB 1. The following eligible members were present Deirdre Lee Laura Dragan Marc Pallot Patrick Durusau Rafiul Ahad Eric Chan 2. Draft minutes from August 19 TC Meeting was approved. 3. Review the minimal model of community, workspace, folder,
artifact, and other high-level concepts for representation in RDF Laura provided the URL for Nepomuk Representational Language
(NRL) which defines some RDF schema extensions (see http://www.semanticdesktop.org/ontologies/2007/08/15/nrl/).
NRL is an upper ontology for Nepomuk that is meant for defining several
ontologies in different domains. For ICOM to provide more direct mapping
between OO and RDF representations, we need richer schema extension for RDF.
Laura and Eric discussed about how NRL may be leveraged for ICOM. Before the meeting, Eric sent out the UML diagram of
high-level concepts for ICOM. This diagram was created from Java classes with
annotations using Borland Together Architect. This format has an advantage in
that you can edit the Java classes directly, even if you don’t have the
modeling tool. Eric proposed to define an isomorphic representation of this
UML model in RDF. In the model, Community has two attributes actors and
workspaces, which are plural names. How can these two properties be represented
in RDF without changing the names. In RDF, one can use the same property actor
to add multiple actors to a community. However this property has singular name,
i.e. OO attribute actors become RDF property actor. On the other hand, Artifact
has two attributes modifiedBy and createdBy, which should always have the
cardinality of 0 or 1. These attributes have singular names in OO. How do we
specify in RDF that there is no more than one occurrence of the properties
modifiedBy and createdBy for an artifact. Laura pointed out that Actor and Community have many-to-many
relationship, but the UML diagram showed the cardinality 1 on Community. Eric
answered that was a misrepresentation in the diagram, the cardinality should be
one or more (Eric would correct the diagram and send out a new version). Eric
later found out the cardinality 1 was put there because of a bug in the UML
tool. Marc questioned what was meant by Actor. Eric responded that
actor is broader than user, can include agent. It lets us define subclasses of
Actor, such as User. Marc suggested to rename the attribute actors to members
on Community, but keep the class name as Actor. Eric prompted whether there were issues with the name
Organization, whether we need a broader notion. Marc pointed out that Community
can be within an organization, across organizations, and across enterprises.
Marc also pointed out that we need to represent individuals who are not
employees of the organization. In the diagram, organization is hierarchical,
and enterprise is a root of the hierarchy. Deidre asked whether we can reduce
the model for mapping to RDF. Rafiul suggested to remove Organization and
Enterprise form the initial model. We would maintain that an actor can be member of one or more
parent communities, and a community or workspace can be part of one or more
parent communities. The proposed UML model includes constraints on the parent
attributes. For group and role, getParent is constrained to Scope, whereas for
actor, getParent is constrained to Community. Since the parent of an actor is
constrained to community, one cannot create actors under workspaces. Since the
parent of a group or role is constrained to scope, which includes workspace,
one can create groups and roles under a workspace, making workspaces
self-contained with groups and roles for defining access control policies.
Similarly, the parent of a folder is constrained to artifact container, which
can be workspace or folder. Rafiul mentioned the purpose of scope, in particular, which
has to do with security. There is inheritance of roles from ancestor scopes. If
you are administrator of the community above a workspace, you can be an
administrator of the workspace as well. Marc asked whether there are textual descriptions of these
concepts. Eric replied that the descriptions were there in the document Oracle
contributed to ICOM TC (see http://www.oasis-open.org/apps/org/workgroup/icom/download.php/31833/BeehiveObjectModel_ICOM.pdf).
Eric would pull out the definitions from that document to combine the text
descriptions with the UML model in the Wiki page at http://wiki.oasis-open.org/icom/Categorisation.
Eric would also provide the use cases, examples of how to represent a project,
define members, assign membership roles, create project folders, etc., using
this model. Marc considered how the access control policies shall be
supported by the model. Rafiul and Eric offered to share Beehive’s
experience of using basic discretionary access control lists, for read, write,
create, delete on entities, to define access control policies for high-level
operations such as invite members to a community or to a meeting. Invitation of
participants can be defined using access rights on the group, role, actor
objects for community or on the calendar objects for meeting. Eric would send out an updated UML model, Java classes,
textual definition of concepts, and use cases, via http://wiki.oasis-open.org/icom/Categorisation.
4. AOB The meeting was adjourned. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]