OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

icom message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Draft Minutes of ICOM TC Meeting, May 26, 2010


Minutes of ICOM TC Meeting, May 26, taken by Eric S. Chan

 

1. Roll Call

2. Approve draft minutes from May 12 TC Meeting

3. To reconcile ICOM with FOAF ontology (http://www.foaf-project.org/, http://xmlns.com/foaf/spec/)

4. Discuss ICOM use cases for the workshop

5. AOB

 

1. The following eligible members were present

 

Deirdre Lee

Scott Convoy

Eric Chan

 

2.  Approve draft minutes from May 12 TC Meeting

 

Deferred.

 

3. To reconcile ICOM with FOAF ontology (http://www.foaf-project.org/, http://xmlns.com/foaf/spec/)

 

Eric accepted the action item to propose a mapping of FOAF concepts to ICOM concepts. We should keep in mind that FOAF ontology can represent a federation of sites (i.e. for a third-party to federate the user accounts and addresses of a person across multiple sites) whereas ICOM ontology can represent the constituents of a site (i.e. for the site administrators to define the access control policies, scoping of policies, and the responsibility and accountability of subjects in a site).

 

Below are Eric’s proposals, some of which were alluded to during the TC Meeting.

 

a)      ICOM includes the concept of Actor of a site. An ICOM Actor is a FOAF Person who has one or more user accounts for the site in question. In other words, the ICOM actors of a site are a subset of the FOAF persons in a federation of sites. We can define the ICOM Person, which is similar to FOAF Person. We can also define the ICOM ExternalPerson of a site to complement the ICOM Actor. The ICOM Person is the union of the two disjoint sets: Actor and ExternalPerson. External persons are FOAF persons who don’t have user accounts for the site in question.

 

b)      A FOAF Agent can have ID’s such as skypeID, msnChatID, icqChatID, yahooChatID, aimChatID, and jabberID. These are addresses that can be represented by URI’s. The different types of ID’s can be represented by URI schemes, for example “xmpp:”, “skype:”, “msn:”, “icq:”, “yahoo:”, “aim:”, “jabber:”, etc.  The mbox property of FOAF Agent can also be represented by the URI for “mailto:” scheme. ICOM defines the concept of Addressable to represent the entities that possess one or more URI addresses.  The ICOM Actor, Group, ExternalPerson, and BookableResource shall be subclasses of Addressable, so that they can possess the FOAF ID’s and mbox properties.

 

c)       An ICOM Actor can have a personal space and the default inbox in the personal space to receive the messages sent to any of the addresses of the actor. Thus ICOM ontology extends the FOAF ontology by associating the folders to receive the messages sent to the FOAF ID’s and mbox.

 

d)      We can introduce ICOM Agency to represent the FOAF Organization (a subclass of FOAF Agent) which is not a Person. The organizations, such as DERI, Oracle, Cisco, OASIS, can each be represented by an ICOM Agency. ICOM Agency is a subclass in the ICOM Subject branch.

 

e)      DERI can be also represented by an instance of ICOM Community. The DERI community can hold the default space and inbox for messages sent to DERI agency. Furthermore, this DERI community can be a container of employees and students spaces as well as project spaces.  The ICOM Community and Space are subclasses of Addressable.

 

f)       The proposals d) and e) imply that an organization such as DERI or Oracle can each be represented by two individuals, one individual is of type ICOM Agency and another individual is of type ICOM Community. The DERI agency is a subject (one which as an mbox address) whereas DERI community is a container (one which has a space and inbox to hold the messages delivered to DERI’s mbox address).

 

g)      We can introduce a separate concept called PhysicalLocation to represent the physical addresses, such as street addresses, P.O. boxes, and GPS locations. We will not represent the physical addresses by URI’s. URI’s will represent the Internet addresses such as the FOAF ID’s and mbox.

 

h)      ICOM Group can represent the FOAF Group.

 

i)        ICOM Artifact can represent the FOAF Document. The foaf:PersonalProfileDocument can be represented by artifacts in the actor’s personal space. The Person’s workplaceHomepage can refer to the profile document of a community representing the person’s organization.

 

4. Discuss ICOM use cases for the workshop

 

Deirdre accepted an action item to generate the raw data to use for modeling and analysis of ICOM. Eric suggested that the mapping between ICOM and FOAF can be a use case (for the workshop).

 

5. AOB

 

Eric welcomed Scott Convoy to the ICOM TC. Scott joined ICOM TC as a member. Scott heard about ICOM TC from the CMIS TC where he is an active member.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]