Difference between revisions of "Persona Data Model 2.0"

Revision as of 11:07, 28 November 2009

This data model is based on Higgins Data Model 1.1 and will be used by future Higgins 1.X web services (e.g. future versions of I-Card Service 1.1).

Version

During the Higgins 1.1 development project we will be working on defining Persona Data Model 1.1.

Background

Within the RPPS Package are components that persist data objects on behalf of the user. These include I-Card Registry, and others (not counting temporary caches). These include user account data, the users set of cards, and other data. Some components use IdAS 1.1 Package to persist their data. Others manage their own local data stores "above" IdAS. The overall data model has never been documented in one place and it didn't have a name. As of now we are calling it the Persona Data Model 1.0 (PDM 1.0).

PDM 1.0 has evolved over the past few years as we've piled on more and more requirements. At this point, we need to evolve it still further, but before we do so, we'd like to document the new model, Persona Data Model 1.1, so that it can be peer reviewed, combed through and made as self-consistent, simple and powerful as possible. The new model will have more generality and be easier to implement than what we have today.

Implementation

Since this document is about design rather than implementation, we will only make a short implementation note here before we move on: We expect that when it comes time to implement the new Persona model 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 Persona Data Model 1.1 is a model a person's personal information. It is based on the Higgins Data Model 1.1. The person in question is referred to in the following as the user.

A graph of Entities

In PDM 1.1 the user's data is represented by a directed acyclic graph of Entities interconnected by higgins:correlation links. The root of this graph (and some other nodes) is in the "meta" context. By convention Entities in this meta context are of class Persona and all have a persona:personaLabel attribute.

The nodes in this graph may also have links to other entities using some other kind of link other than higgins:correlation. However, these links are not considered part of the user's Persona Graph.

Since the entities in the user's data graph may live in disparate contexts and these contexts may be managed in different locations, the data graph is logically distributed. since each Entity is stored in Contexts that may be physically located anywhere on the net.

Here's an example graph:

There are seven nodes in the Persona graph connected by h:correlation links. We follow a convention that the name of the containing context follows the "ex:" and precedes the "-". Thus "ex:Meta-Alice_at_Home" is Persona node in the "Meta" context. For clarity the attributes of the nodes have been omitted.

The semantics of the higgins:correlation links are important to understand. The "h:" prefix tells you that this attribute is defined in higgins.owl and is thus a concept defined in the Higgins Data Model 1.1 (HDM). Nevertheless, we remind the reader here of the basic idea. The overall knowledge domain of HDM is digital identity. In the digital realm, rather than a monolithic object, it is most useful to model identity as a set of linked, multiple partial identities each of which holds a set of attributes. As you can hopefully see, this is exactly what a Persona graph is.

User Accounts

From the point of view of the Higgins I-Card Service or CardSync Service 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. Each user account holds a meta context, and may hold other contexts a as well. The user is considered authoritative over the contents of the meta context.

Personas and correlations

The persona nodes in the meta context represent personal information about the user that is relevant across multiple interaction contexts. The h:correlation links emanating from persona nodes in the meta context to entities in different contexts express the concept that these referenced entities are contextualized, partial manifestations of the user. For example, to represent what Alice says about herself in the context of shopping at Amazon.com we use an entity with attributes in the amazon context. To represent what Alice says about herself in the context of buying a ticket on orbitz.com we use another entity. And to represent that these two entities are both about what to Alice is the same person, we use a persona node pointing with correlation links to each of these two respective entities.

The semantics of a correlation link is closer to association than aggregation. It is about equivalence as it would be seen by a human observer. Alice, for example, would understand that the two entities are described above are about her. Yet the semantics of h:correlation isn't necessarily strictly logical. The ontologies in the two contexts may be such that each of the two representations cannot be merged and remain logically consistent. For this reason higgins does not use owl:sameAs which does imply this ability to directly merge representations.

The persona nodes can be used to represent broad, reuseable roles (e.g Alice at Home or Alice at Work); i.e. roles that can be used fairly consistently across multiple contexts. For example Alice might interact with many websites using her Work persona role. In this way the "Home" and "Work" personas above can be thought of as reusable, or cross-contextual. This is in contrast to regular entities that live in narrower contexts. For example a regular (non-Persona) entity can represent Alice as an eBay seller. The cross-contextual (or meta-contextual) Persona nodes live in the meta Context.

In the example above Alice has three personas below the root. One is about the "work" Alice, one is about the "home" Alice and the third doesn't fall neatly within either of those two classifications. The vCard schema has attributes that describe both work and home roles, so Alice's vCard isn't "under" the home or work personas.

UML Class Diagram

Imported Ontologies

To avoid reinvention, PDM (shown as "p") is based on these existing ontologies:

Where:

• "h" == Higgins Data Model 1.1 (higgins.owl)
• "rcard" and "icard" are considered parts of PDM, but split out into separate files.

General Purpose Classes and Attributes

This section provides a quick overview of the non i-card-related classes and attributes.

Classes

• Account: Acount identifier; may also contain credentials
• Contactable: A Persona that can be reached either for payment or for receipt of a letter or bill. Subclass of Persona
  • 1..1 vcard:n
  • 1..1 vcard:adr
  • 0..1 receivableAdr
  • 0..1 vcard:org
• PaymentMethod
• PaymentMethod
• Persona: A contextualized aspect of a person.
  • 0..1 account
  • 0..1 daytimePhone
  • 1..1 personaDisplayLabel
  • 0..1 vcard:n
• ReceivableAddress: vCard Address with no P.O. box. Subclass of vcard:Address

DataRanges

• telephoneURI: a telephone number in tel: URI syntax

Simple Attributes

• authority: The authority that operates the containing context. May be the issuer of security tokens about entities in this context.
• ccCid
• ccExpirations
• ccNumber
• eyeColor
• password
• personaDisplayLabel
• username

Complex Attributes

• account: Value is an instance of Account
• billing: Billing persona. A persona capable of receiving and paying bills. Value is a Contactable.
• knows: A person known by this person (indicating some level of reciprocated interaction between the parties). Value must be a Persona
• otherPhone: An alternative telephone number. Value must be a telephoneURI
• paymentMethod: Payment method. Value must be a Contactable
• receivableAdr
• receiving

Concept Scheme

The attributes defined in the PDM have attribute annotations that specify where the attribute lies within the following concept scheme:

Which is represented as:

Note: see Higgins Data Model 1.1 for more information on concept schemes.

I-Cards

Before we introduce the I-Card classes, please remember that in CDM multiple inheritance is allowed: any single entity may be a member of multiple classes simultaneously. In this section we leverage this characteristic.

First we define an abstract class called I-Card. This captures the common attributes across the four sub-classes defined below. These common attributes include:

• cardId - a unique identifier for the card
• image - an image bitmap for the background of the card when it is displayed
• ... and several others.

These two sub-classes of I-Card are defined:

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

And finally by adding a special attribute either of the above can become an R-Card. The following classes are inferred by the presence of the resource-udr attribute on their respective "base" classes:

• personal r-card
• managed r-card

Although, it is redundant the the inference just mentioned, we also provide an explicit R-Card class. A personal r-card would be a subclass of both the R-Card class and the P-Card class. A managed r-card would be a subclass of both the R-Card class and the M-Card class. All R-Cards MUST be a subclass of R-Card (and either P-Card or M-Card).

Any Persona-class entity may be one (or two) of these four classes of cards, perhaps in addition to also being an instance of yet other classes.

P-Card

The attributes that define a personal P-Card are taken directly from the OASIS IMI specification. An example p-card is shown here:

M-Card

Here is an example of an IMI managed card:

Personal R-Card

From a structural point of view, the presence of the resource-udr claim on a P-Card or an M-Card makes it be considered an R-Card. Here is an example of a personal R-Card:

As you can see the resource-udr attribute/claim value MAY point to itself or MAY point to some other entity.

Managed R-Card

The final type of card is the managed r-card. The presence of the resource-udr claim makes an ordinary M-Card into an R-Card. Here is an example of a managed R-Card:

More about R-Cards

For more details about R-Cards see R-Card.

Card Axioms

1. For any M-Card: The value of any of the above "supported" claims attributes is considered to be a cache of the most recent value of these claims as fetched from the m-card's STS

Contexts

Required Context Attributes

In the Higgins Data Model 1.1 all Context attributes are optional. However in Persona Data Model 1.1 we have these requirements:

• All Contexts that are made available by a third party (e.g. the government, a bank, etc.) have a p:authority attribute whose value is the domain name of that third party. If the context is self-asserted (even if it is made available by a so-called "fourth party") then this attribute MUST not be present. Nil means that the context contains self-asserted information (information directly asserted by the user). A domain name indicates the authority that manages the entities in this context. In reality the situation is much more complex. An authority (e.g. gmail.com) manages entities that are a person's contact list, yet the person is the one who typed in the values. R-Cards allow attribute-level access control to a single entity, and the user may well be allowed to edit and update some attributes of an entity. Nevertheless, it is useful to have a single context-level authority attribute string that can differentiate between a person's entry in gmail vs. their profile in facebook.com or some enterprise directory.

See Also

• Higgins Data Model 1.1
• Context Data Model 1.1
• R-Card - details of the Persona Data Model 1.1 relating to r-cards.
• Parallel CardSync and XDI Channels