Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: Management of user profile information in UbiData
Full Citation
Permanent Link:
 Material Information
Title: Management of user profile information in UbiData
Series Title: Department of Computer and Information Science and Engineering Technical Reports ; TR03-001
Physical Description: Book
Language: English
Creator: Sur, Gargi
Hammer, Joachim
Publisher: Department of Computer and Information Science and Engineering, University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: January, 2003
Copyright Date: 2003
 Record Information
Bibliographic ID: UF00095586
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.


This item has the following downloads:

2003332 ( PDF )

Full Text

CISE Technical Report TR03-001, January 2003

Management of User Profile Information in UbiData

Gargi Sur and Joachim Hammer
Dept. of Computer & Information Science & Engineering
University of Florida
Gainesville, FL 32611-6120


One of the fundamental challenges in the management of converged networks is how to
efficiently represent user profile information. In this technical report we outline the
underlying technical challenges as well as our approach for modeling, storing and
manipulating user profile information in a central profile server. The schema and algorithms
described here have been implemented and installed in the UbiData prototype system.

1 Overview of UbiData
The proliferation of mobile devices has created new challenges for mobile computing research.
For example, users of mobile devices demand constant availability of data and information, which
is typically stored on their workstations, corporate file servers, and other external sources, even
when only limited network bandwidth is available, or when network access is not available.
Moreover, given the growing popularity of portables and personal digital assistants (PDA), mobile
users are requiring access to important data regardless of the form-factor, rendering capabilities
and computing power of the mobile device they are using.
We have identified three related challenges imposed by mobility:
1. Any-time, any-where access to user data, regardless of whether the user is
disconnected, weakly connected via high-latency, low-bandwidth networks, or temporarily
completely disconnected.
2. Device-independent access to data to allow users to switch among different devices,
even while mobile, and have access to the same set of files.
3. Application-independent access to data to allow users to modify portions of documents
and files belonging to classes of related applications (e.g., the ability to modify parts of a
document irrespective of the word-processing application that was used to create the
In response to these challenges, UbiData provides an architecture for sophisticated hoarding
and synchronization techniques to increase the availability of data in presence of user mobility and
disconnection, and to automate the task of maintaining up-to-dateness and consistency of data on
mobile devices. For example, UbiData provides format-independent access to data in mobile
computing environments using our Format-Independent Change Detection and Propagation
(FCDP) algorithms. FCDP is capable of computing the changes that have been made to a
document on one device (e.g., a Microsoft Word document on the user's desktop) and applying
them to a copy with minimal formatting instructions and structure on a different device (e.g., a PDA
incapable of directly manipulating a full MS Word document).
The UbiData dual-middleware architecture is shown in Figure 1. The architecture consists of
the highly available Mobile Data Server (MDS) and the replicated Mobile Environment Manager
(MEM), which is split between the MDS (this part is called the Fixed-MEM) as well as each of the
mobile devices that are used (one or more Mobile-MEMs); hence the term "dual middleware." M-
MEMs and F-MEM are connected through the Internet. Together, M-MEM and F-MEM eliminate

the manual and tedious synchronization of data between the mobile and fixed devices that are
employed by a user.

Mobile Device
Mobile Data Server (MDS)

Mobile-MEM Fixed-MEM

Internet CODA Metadata
File System (XML-DBMS)

Mobile Device O/S

Application COD XML

Figure 1: Conceptual Overview of the UbiData Architecture.

2 User Profile Management in Ubidata

2.1 Motivation
The MDS constitutes the centralized repository for all data relevant to the user. Since Ubidata
aims to automate the entire process of manual data-hoarding and enable ubiquitous data access,
the system needs to determine which files are of importance to the user and keep track of the
replicated file-set on different devices owned by a user. The set of files which are frequently
accessed by a user constitutes his/her working set. The user data files are managed by CODA
and stored in CODA volumes, which forms a part of the mobile file system. The mobile file system
becomes an extension of the user's local disk(s), which may not be able to always hold the entire
contents of the working set. By using the MDS as a repository for the user's working set, we are
not limiting the user to a specific computing platform. Rather, the user may utilize a variety of
devices such as a workstation in the office, a desktop computer at home, laptops, notebooks,
hand-held PCs, among other devices.
On each mobile device, M-MEM monitors the user's data access patterns in order to
automatically determine his/her working set. M-MEM propagates files accesses and any updates
to the F-MEM, which will initiate synchronization procedures with the copy on the MDS. If the data
item is new and does not have a counterpart on the MDS (e.g., the mobile user creates a new file),
or if immediate synchronization is not desired or not possible (e.g., no connection can be
established), updates to the working set are performed upon return to the docking station.
In order to facilitate data access and synchronization, the MDS must maintain profile
information corresponding to each user. The MDS is required to store metadata including
biographical information, the current user working set, the default rules for device capabilities and
the rules and filters for converting data into various formats to support transmittal between different
devices. The metadata repository also contains the links to the actual data files that make up a

user's working set. Currently, the F-MEM includes the Metadata Server software (Xindice) that
manages the metadata for each user.
The remainder of this technical report describes the management of user metadata on the
MDS. For a detailed overview of the architecture and functionality of the other components, please
refer to [1,2].

2.2 Challenges
Accumulating Profile Information: One of the fundamental challenges faced is how to capture
relevant user-profile information and suitably express them using a well-defined schema. The
initial goal of Ubidata was to automate the process of manual data hoarding and automatically
apply format conversions if necessary. However, since the access to profile information and the
distribution of the data files is best specified by the user (in addition to the system defined
parameters); it becomes vital that the user be aware of the sharing of profile information between
the middleware components (F-MEM and M-MEM). Minimal user-intervention may be necessary if
the user wants to override the system defined parameters and specify his/her preferences.
Metadata Description: While designing the schema to integrate the profile information, we
noticed that there are two possible approaches towards describing the meta-information: user-
centric and data-centric. The user-centric approach is more convenient as most of the relevant
information can be correlated to a 'user', such as biographical information, device ownership, file
listing, etc. The data-centric approach provides greater leverage to query/update of profile
information if file-sharing is a very common phenomenon amongst users. If user-centric approach
is used in such a multi-user file access scenario, shared files would result in replicated
components on several user-profiles and tedious query/update rules would be necessary to
achieve proper synchronization between the shared replicas. We have given preference to the
user-centric approach in Ubidata, though there is provision for file-sharing between users.
Considerable research is still required to determine whether a separate data model is more
effective for efficient schema description in collaborative environments.
Query/Update Mechanisms: The infrastructure must have support for querying as well as
applying modifications to the user-profiles. The F-MEM may need to perform searches or apply
merge/join techniques in order to retrieve desired information. The metadata manager may need
distributed query processing capabilities if the meta-data sources are themselves mobile and
distributed in nature.
Synchronization: There is need for well-defined policies for synchronization of updates within the
replicated file-sets. The system may support a push-based architecture which may be overridden
by user-specified pull-based preferences. Currently implicit synchronization semantics have been
implemented in Ubidata but explicit synchronization semantics using user-profiles need to be
specified. The F-MEM must provide transaction support in order to provide large-scale
synchronization and enable access control over the replicated data-sets.

2.3 High-level Description of User Profiles
UbiData collects and stores meta-information for every UbiData user in the form of a User Profile
(UP), which is encoded in XML. XML is used as the representation format as it helps to achieve
device and application independence while making it possible to define the constraints on the
profile information in a flexible manner. Moreover, sophisticated queries can be easily expressed
using XML query languages such as XQuery or XPath.
The UP includes descriptions of the files owned by the user (e.g., how frequently they are
accessed, whether they are shared or not) as well as information about a user's mobile
paraphernalia, for example, a list of devices, their capabilities, etc. In UbiData, users (and their
profiles) are identified by user IDs. When a user joins UbiData, a new profile is created which
contains user information as well as relevant information about the mobile devices) owned by the

user. All of the usage information is subsequently collected by M-MEM and F-MEM whenever the
user accesses a file. UPs are stored in the Metadata Repository on the MDS.
For each user, a list of the most used files constitutes a hoarding list or the current working
set, which represents a conceptual entity rather than an actual list. Files that are "members" of the
hoarding list are specially marked using their file status element. It is important to note that
membership in the hoarding list is predicted based on past user behavior rather than exact
knowledge. The hoarding list is computed by the M-MEM on each mobile host owned by the user.
The M-MEM monitors the user file access pattern and assigns a metric called hybrid priority to
each accessed file. Hybrid priority serves as an indication of the activeness of files. The hoarding
list contains the files with the highest hybrid priority. The hybrid priority is a function of three
variables namely recency, frequency and active period:
Recency is the time interval elapsed since the last access. Since recency can be
expressed by the last modification time or the last access time (both are stored as
parameters in the file list), this field is not mandatory.
Frequency is the number of accesses by the user of a particular file within the active
period. This field is mandatory.
Active period is the time between the first and last access. Since the active period can be
computed using last access/modification time (available as a parameter in the file list),
i.e. as the difference of last access/modification time and creation time, it is not
Ubidata allows sharing of files amongst several users. This lead to two possible file access
Single-user file access
Multi-user file access
In the single-user file access scenario, the files owned by a user can be copied onto several
devices owned by the user. On the other hand, in the multi-user file usage case, several users
belonging to the same group may share some of the same files; furthermore, these files could
again be replicated on various devices owned by these users. The access rights to the files can be
registered using the combination of group-id and file permissions.
Every data file listed in the UP must be uniquely identified. Moreover, since there could be
more than one replica of an existing file, an appropriate naming scheme is needed. The URI
naming mechanism is used to identify each instance of a file on the various mobile hosts, including
the ones not owned by the user. The following example shows the use of URI's to locate files in
Ubidata URI = mfs://hostname/pathname
where hostname = $MobileDataServerRoot $username/$device name
Here, mfs corresponds to the mobile file system protocol that is observed in Ubidata.

3 User Profile Schema
The following description illustrates the organization of the UP. The UP consists of four main
System info
User info
Device list
File list
For each component, the UP maintains a list of parameters containing the specific meta-
information. The parameters and their meaning are described below.

3.1 System Parameters
System parameters specify preference and configuration settings of the middleware such as M-
MEM or F-MEM. For example, rather than using a generic frequency for updating the contents of
the UP or the contents of a file on a mobile device, a user may opt for a higher update frequency.
Meta-information describing system settings is captured by the following two parameters:
state {possible values are: active, inactive}

3.2 User Parameters
User specific information is captured in the following three parameters:

3.3 Device Parameters
All devices owned by the users need to be recorded by the MDS, since they constitute the mobile
file system. Each device has an associated device name, which forms a part of the Ubidata_URI to
specify file locations on mobile devices. Every device list in a UWS consists of a list of devices
owned and each device has following parameters:
device info

3.4 File Parameters
Each file list contains the files that are owned and group-owned (shared) by the user. For each file,
the UWS contains the following information:
file_status {possible values are: in-sync, not-in-sync}

Each replicalist stores information about one or more replicas of the file to which the replica list
belongs. For each replica, the following information is stored:
last modification/access time

A complete DTD describing the structure of the UP is provided in Appendix A. A sample UP
instance document is shown in Appendix B.

4 User Profile Manipulation
The user profiles are contained within the metadata repository and need to be accessed in various
situations, for instance when the M-MEM detects changes in file access patterns or to update the

working set or verify permissions or preferences. When the M-MEM wants to retrieve or update
profile information, it must send a request to the F-MEM. Only the F-MEM is allowed to access and
apply modifications to the user profiles. Hence, the metadata server must provide support for
query/update capabilities for semistructured data. Whenever the F-MEM receives request from the
M-MEM for synchronization updates, it should be able to retrieve and enforce the access control
constraints. The F-MEM should also be able to retrieve information from several user profiles if
certain data files are shared by several users. However, queries over user profile are mostly direct
in nature and do not involve complicated joins over large metadata sets.
Besides retrieving the contents of a specific UP, we can identify three essential update
operations that need to be performed on a UP during its life-time in the MDS: (1) insert a new UP,
(2) delete an existing UP, and (3) modify one or more parameter values for a given UP. All three
update operations must be supported by the XML query/update language as well as the MDS. We
provide some examples for each update operation below using the update semantics for XQuery
as per the latest W3C specification.

4.1 Insert a New User Profile
Scenario: Create a new UP for user 'jhammer' with the following information:
userlD: jhammer
firstname: Joachim
lastname: Hammer
password: XcvgfT35R
devicename: Office PC Dell 8100
device_capabilities: large monitor and medium-size disk
encryption_key: al23yhwqujhqwu

Update syntax:
for $u in /user_profiles



Office PC Dell 8100
large monitor and medium-size

4.2 Delete an Existing User Profile
Scenario: Delete the UP for user 'user3.'

Update syntax:
for $up in /user_profiles/up
where $up//userinfo[@userlD] = "user3"
delete $up

4.3 Modify an Existing User Profile
Scenario 1: Insert a new file called "abc.xml" into the UP for user 'gsur'. The following
information is provided:
filelD: abc.xml
owner: gsur
permission: rwxr-xr-x
creation time: Sat Oct 26 09:06:34 2002
fileversion: 1.0
frequency: 2
replica location: mfs://gsur/Utopia/d:/docs/abc.xml
replica last_modification_time: Sat Oct 26 16:43:20 2002
replica_version: 1.0

Update syntax:
for $up in //up
let $fl = $up/file_list
where $up/user_info[@userlD] = "gsur"

Sat Oct 26 09:06:34 2002

Sat Oct 26 14:32:43 2002

Sat Oct 26 16:43:20 2002

Scenario 2:
User 'jhammer' modifies a file 'scenariol.txt', which is shared by two users of ubidata group. The
modifications are shipped to the MDS. The F-MEM has to update the UP for both users as the
replica information is contained in both profiles. Moreover, since user 'gsur' has not reconnected to
the MDS, the replicas are also out-of-sync. This situation is depicted in Figure 2 below.

Figure 2: Updating user profiles that reference shared data files.

Update syntax:
Update for user 'jhammer'
for $up in //up
let $f = $up//file_list/file[filelD = "mfs://MDS/mnt/diskd/usr/local/ubidata/scenariol.txt"]
where $up/user_info[@userlD] = "jhammer"
replace $f/file_version with 1.1
replace $f/file_status with not-in-sync
replace $f/hybrid_priority/recency with Sun Oct 27 14:32:43 2002
replace $f/hybrid_priority/frequency with 5
for $r in $f//replica[location = "mfs://jhammer/c:/ubidata/scenariol .txt"]
replace $r/modification_time with
Sun Oct27 12:00:23 2002
replace $r/replica_version with 1.1

Update for user 'gsur'
for $up in //up
let $f = $up//file_list/file[filelD = "mfs://MDS/mnt/diskd/usr/local/ubidata/scenario .txt"]
where $up/user_info[@userlD] = "gsur"
replace $f/file_version with 1.1
replace $f/file_status with not-in-sync
replace $f/hybrid_priority/recency with Sun Oct 27 14:32:43 2002
for $r in $f//replica[location = "mfs://jhammer/c:/ubidata/scenariol.txt"]
replace $r/modification_time with Sun Oct 27 12:00:23 2002
replace $r/replica_version with 1.1

5 Conclusion

This report identifies the need for user profile management in Ubidata. It describes a framework for
metadata storage and management using middleware components. It also covers some of the
interesting issues that must be addressed in order to efficiently capture and store user-profile
information in mobile environments. The report also proposes a schema for user profiles and a set
of queries/updates against the schema. Currently efforts are being made to implement update
semantics for semistructured data. These semantics are the prerequisites to transaction
management and synchronization support in the MDS. Further efforts are being made to
streamline the request/reply communication between the middleware components and directly
embed queries on profiles in the communication messages.
While this report is an initial attempt to address profile management issues in mobile
environments, there are ongoing efforts by both Sun and Microsoft towards a standard for network
identity. The 3GPP GUP and the Liberty Alliance standards bodies have specified the high level
requirements for profile management frameworks. The GUPste" initiative [3] specifies a framework
for profile management in converged networks. But considerable research is still needed in the
context of specifying, sharing and managing profile data. There is a need for a common data
model to store and access profile information. Efficient techniques must be developed to achieve
synchronization of user data and profile information in face of challenges posed by mobility and
disconnections in mobile environments. Standardized techniques to deal with these central issues
on profile management with minimal constraints still need to be formulated.

[1] A. Helal, J. Hammer, A. Khusraj, and J. Zhang, "A Three-tier Architecture for Ubiquitous Data
Access", First ACS/IEEE Conference on Computer Systems and Applications, pp. 177-180,
Beirut, Lebanon, 2001.
[2] J. Zhang, A. S. Helal, and J. Hammer, "Ubidata: Ubiquitous Mobile File Service", Eighteenth
ACM Symposium on Applied Computing (SAC 2003), Melbourne, FL, 2003.
[3] A. Sahuguet, R. Hull, D. Lieuwen, and M. Xiong, "Enter Once, Share Everywhere: User
Profile Management in Converged Networks," First Biennial Conference on Innovative Data
Systems Research, Asilomar, CA, 2003.

Appendix A. DTD Describing the Structure of a User Profile

permission CDATA #REQUIRED>

Appendix B. Sample User Profile




Wireless PC Card
3Com 10 Mbps Ethernet

512Mb RAM


Fri Oct 15 09:06:34 2002

Fri Oct 25 11:35:23 2002

Fri Oct 25 10:35:23

Fri Oct 25 11:35:23


Thurs Oct 24 11:36:23

Thurs Oct 24 11:36:23


owner = "gsur" permission = "rwxrwxr-x">
Fri Oct 25 09:06:34 2002

Sat Oct 26 14:32:43 2002

Fri Oct 25 10:35:23

Sat Oct 26 14:32:43


Fri Oct 25 1:00:23


Filename: up-management-v9.doc
Directory: C:\Users\j oachim\Proj ects\UbiData\Profile Management
Template: C:\Documents and Settings\joachim\Application
Data\Microsoft\Templates\Normal. dot
Title: Management of User Profile Data in the UbiData Project

Author: Gargi M. Sur and Joa
Creation Date: 12/27/2002 9:40 AM
Change Number: 45
Last Saved On: 1/27/2003 5:32 PM
Last Saved By: Joachim Hammer
Total Editing Time: 724 Minutes
Last Printed On: 1/27/2003 5:32 PM
As of Last Complete Printing
Number of Pages: 13
Number of Words: 4,083 (approx
Number of Characters: 23,279 (appro

chim Hammer


University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs