Differences

This shows you the differences between two versions of the page.

--- uf:proximities [2009/11/18 13:46] – moving elisag
+++ uf:proximities [2009/11/30 16:42] (current) – proper dharnie
@@ Line 1: / Line 1: @@
-===== Proximity =====
+===== Characteristic Function =====
-Proximity is a filter object that contains a “function” that determine whether or not a user is proximate. There are several predefined functions:
+A characteristic function is a filter object that contains a “function” that determine whether or not a user is proximate. There are several predefined functions:
-  * isNearby: physical proximity
+  * isNearby: encodes physical proximity
   * isFriend: static encoding of friendship relationships
   * doesProfileMatch: tests an attribute of a user’s profile, form ATTR OP VAL, where ATTR is e.g. age, name, gender, hobbies,
@@ Line 9: / Line 9: @@
 Other functions can be defined as combinations of existing functions by means or combinators: and, or, not.
-Proximities translate these events into addUser / removeUser events to be processed by flocks. To process these events, flocks register themselves on their dependent proximity.
+Characteristic functions translate these events into addUser / removeUser events to be processed by flocks. To process these events, flocks register themselves on their dependent characteristic function.
+===== Example =====
+Programmers can make customised characteristic functions. In order to aid the programmer in this tasks we have defined some auxiliary functions and constructors. In the code shown bellow we make a characteristic function that maps the domain of persons onto the set of people who are both female and friends in the proximity. The first step in the code is to create the female proximity. This is constructed by making a profile function. The first parameter is the flockr and the second is a lambda which expects a profile. This lambda must return a boolean value and indicates that the matched profile is in the proximity or not. In this case we check that the sex of the profile is female. The second function is a predefined one and only passes friends that are in the neighbourhood. The last step is to combine the two defined function's into one. As we only want to show those friends in the neighbourhood who are female we combine them by making use of a and operator.
-As a first implementation of the RETE-network, maybe we can start from the oo matching that Tom implemented, so that Proximity functions are templates. For example:
+<code>
+def femaleProximity := makeDoesProfileMatchProximity(flockr1 , { |profile| profile.sex == "FEMALE" });
+def friendProximity := makeIsFriendProximity(flockr1);
+def friendAndFemaleProximity := makeAndProximity(femaleProximity, friendProximity);
+</code>
+===== Implementation =====
+An ad hoc RETE-network. Events are triggered by:
+  * discovery: ''joined(uid,flockr)'' / ''left(uid,flockr)''
+  * profile changes: ''changed(uid,flockr,updatedProfile)''
+  * friend changes: ''friendAdded(uid,flockr)'' / ''friendRemoved(uid,flockr)''
+These events are received by the local flockr user object and propagated to all local proximities. Characteristic functions translate these events into addUser / removeUser events to be processed by flocks. To process these events, flocks register themselves on their dependent function.
+{{:uf:proximity.jpg?507x374|:RETE-network design diagram}}
+Alternative implementation of the RETE-network, maybe we can start from the oo matching that Tom implemented, so that Proximity functions are templates. For example:
 <code>
@@ Line 28: / Line 48: @@
-It appears that some proximities are mandatory, e.g. a composite proximity requires at least the isFriend / isNearby / wasNearby proximity functions. The doesProfileMatch proximty is optional. So we have the following constraints on proximities:
+===== Open Issues =====
+It appears that some characteristic functions are mandatory, e.g. a composite function requires at least the isFriend / isNearby / wasNearby built-in functions. The doesProfileMatch function is optional. So we have the following constraints on characteristic functions:
   * does it make sense to combine isNearby and wasNearby? I think isNearby supersedes wasNearby
   * isFriend can be combined with isNearby or wasNearby
   * there must be at least one of isFriend / isNearby / wasNearby
-  * there can be 0 or more doesProfileMatch proximities
+  * there can be 0 or more doesProfileMatch functions
-===== Example =====
-Programmers can make customised proximity functions. In order to aid the programmer in this tasks we have defined some auxiliary functions and constructors. In the code shown bellow we make a proximity function that maps the domain of persons onto the set of people who are both female and friends in the proximity. The first step in the code is to create the female proximity. This is constructed by making a profile proximity. The first parameter is the flockr and the second is a lambda which expects a profile. This lambda must return a boolean value and indicates that the matched profile is in the proximity or not. In this case we check that the sex of the profile is female. The second proximity is a predefined one and only passes friends that are in the neighbourhood. The last step is to combine the two defined proximity's into one. As we only want to show those friends in the neighbourhood who are female we combine them by making use of a and proximity.
-<code>
-def femaleProximity := makeDoesProfileMatchProximity(flockr1 , { |profile| profile.sex == "FEMALE" });
-def friendProximity := makeIsFriendProximity(flockr1);
-def friendAndFemaleProximity := makeAndProximity(femaleProximity, friendProximity);
-</code>
-==== Implementation ====
-An ad hoc RETE-network. Events are triggered by:
-  * discovery: ''joined(uid,flockr)'' / ''left(uid,flockr)''
-  * profile changes: ''changed(uid,flockr,updatedProfile)''
-  * friend changes: ''friendAdded(uid,flockr)'' / ''friendRemoved(uid,flockr)''
-These events are received by the local flockr user object and propagated to all local proximities. Proximities translate these events into addUser / removeUser events to be processed by flocks. To process these events, flocks register themselves on their dependent proximity.
-{{:uf:proximity.jpg?507x374|:uf:proximity.jpg}}