Skip to main content
Jump to: navigation, search

Persona Data Model 2.0

Revision as of 11:20, 14 July 2009 by Ptrevithick.gmail.com (Talk | contribs) (User Profile)

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Higgins logo 76Wx100H.jpg

Within the RPPS Package are components that persist data objects on behalf of the user. These include user account data, the users set of cards, and other data. Some components use IdAS to persist their data. Others manage their own local data stores "above" IdAS. An attempt to document all of these different kinds of objects and stores would be a major project. Instead of looking backward, this page describes a new, updated data model that we call User Data Model 2.0.

Version

During the Higgins 1.1 development project we will be working on defining the User Data Model 2.0. We will not be able to implement the new model in time for Higgins 1.1, but work will continue thereafter.

Approach

The User Data Model 2.0 defines the patterns and kinds of objects that exist in a running instance of the I-Card Service. The User Data Model 2.0 can be expressed in the still more general Context Data Model 1.1 and that is exactly what this document does. It describes one model in terms of the other. It is assumed here that the reader is familiar with CDM 1.1. All objects in UDM 2.0 are CDM 1.1 Entities, and in this document we use the terms object, resource and Entity and even sometimes node, interchangeably.

Implementation

Since this document is about design, not implementation we make a short implementation note here before we move on. We expect that when it comes time to implement the new User Data Model 2.0 (UDM) that a decision will be made that the I-Card Service, the RPPS Package components, etc. store all data objects in IdAS. IdAS would thus become the "data layer" in the traditional tiered model.

Introduction

The UDM is a model of the user's data. These data are accessed over the net via the I-Card Service and/or the CardSync Service. If these two services are co-resident, both share the same set of user data objects.

Persona Graph

The user's data is represented by a graph of Personas. A Persona is a class of Entity that describes some aspect of the user. Personas can have a large number of attributes, or hardly any.

In UDM the user's data consists of a DAG of Personas all interconnected by higgins:correlation Attribute links. Note: The Persona nodes in this graph may have links to other non-Persona Entity nodes using some other kind of link (other than higgins:correlation) these links are not considered part of the user's Persona Graph.

The Persona Graph is a physically distributed graph of Persona Entity nodes. As you recall from CDM each Entity is stored in Context and these Contexts may be physically located anywhere on the net.

User Profile

From the point of view of these services each user is a separate account, and the user (through the agency of their selector) must authenticate to each of these services in order to access their data. We call these accounts User Profiles. Each user has one User Profile. This User Profile is a Persona node, and is the "root" of the Person Graph.

Each User Profile holds account information including the username of the user, perhaps an email address for password reset, and the authentication materials necessary to authenticate the user (via their selector agent).

Attributes:

  • <describe all attributes of a User Profile> class instance

The User Profile Entity is always stored in a Context over which the user is authoritative. This Context is called the root Context and is typically co-resident with the I-Card Service or nearby, but in any case within the same trust domain.

Cards

Four classes of cards are defined:

  • p-card (as in CardSpace)
  • m-card (as in CardSpace)
  • relationship p-card
  • relationship m-card

See Also

Back to the top