Difference between revisions of "Persona Data Model 2.0"

Revision as of 19:54, 12 May 2010

Introduction

The Persona Data Model 2.0 is a model a person's personal information. It is based on the Higgins Data Model 2.0 which is in turn based on Context Data Model 2.0. The person in question is referred to in the following as the user.

The Persona graph

The user's data is represented as a directed acyclic graph of Entity nodes (vertices) interconnected by h:correlation links (edges). Each node represents a different facet of the user. Each node is an entity (i.e. a set of attributes & values). These attributes may be simple literals (e.g. the user's first name) or they may be other entities. These latter complex attributes are rendered a as links (edges) to other nodes, but these edges and nodes are not considered part of the persona graph.

As defined in the Higgins Data Model 2.0 h:correlation link is statement made by some human observer that the source and target of this link are believed to be alternative representations of the same real world person or object. A single, natural person would be represented by different nodes in different contexts. This linkage does not presume that the entire set of attributes across these nodes, if they were brought together and combined, is necessarily logically consistent. Further, the entity source (domain) of the h:correlation relation is often within a more privacy-privileged context than the target (range) of the link. Thus the directed nature of the link is important.

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. 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 graph is a logical abstraction. The data behind these nodes may be physically located anywhere on the Internet.

Typically each node in the persona graph is located in its own Context. The root node lies in a special context (for each user) called the meta context.

An example graph (showing only h:correlation links):

Personas and correlations

The nodes in the meta context represent personal information about the user that is relevant across multiple interaction contexts. 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 persona entities in the meta context represent personas or roles of a person that are consistent across multiple narrower contexts. For example a regular (non-Persona) entity might represent Alice as an eBay seller in an eBay context. By contrast, a cross-contextual (or meta-contextual) persona entity that represents Alice across multiple contexts would live in Alice's 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.

Restrictions on CDM 2.0 EntityIds

The PDM 2.0 uses a restricted set of the full capabilities of CDM 2.0. The restriction is in the area of EntityIds. PDM 2.0 adds the following constraints:

1. All entityIds MUST be URIs
2. All entityId values MUST be Linked Data URIs or XRI 3.0 URIs as we expect XRI 3.0 to be defined
3. All entityIds within a given context MUST be either (a) relative to a "base" URI of the context or (b) absolute
4. Whether or not an entityID is relative or absolute MUST be able to be determined by inspection of its syntax
5. Absolute entityIds MAY be globally resolvable
6. Globally resolvable entityIds resolve to an entity (resource description) within exactly one context

Component Ontologies

The PDM 2.0 is defined by these ontologies:

• persona - defined by Higgins
• i-card - defined by Higgins

And builds on these ontologies:

• higgins (h) - defined by Higgins (see Higgins Data Model 2.0)
• vCard - the W3c's most recent recommended RDF/OWL representation of the IETF vCard format.
  • PDM 2.0 makes one tweak: telephone numbers are encoded using the tel: URI scheme instead of as strings.
  • Note: PDM 2.0 Persona nodes are not explicitly typed as instances of the VCard class, but this is logically inferred.
• FOAF - friend of a friend ontology

As shown visually here:

Where:

• "p" == Persona Data Model 2.0 (persona.owl, rcard.owl, icard.owl)
• "h" == Higgins Data Model 2.0 (higgins.owl)

Persona Ontology

UML Class Diagram

Classes

• Account: Account 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

• 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

PaymentMethod subclasses:

• ByBankTransferInAdvance
• Cash
• CheckinAdvance
• COD
• CreditCard
  • 1..1 ccCid
  • 1..1 ccExpiration
  • 1..1 ccNumber
• DirectDebit
• PayPal

CreditCard subclasses:

• AMEX
• DinersClub
• Discover
• MasterCard
• VISA

DataRanges

• telephoneURI: a telephone number in tel: URI syntax

Simple Attributes

• authority (xsd:string): The authority that operates the containing context. E.g. the issuer of security tokens about entities in this context.
• ccCid (xsd:string):
• ccExpiration (xsd:date):
• ccNumber (xsd:string):
• eyeColor (xsd:string) oneOf(green, blue, brown):
• password (xsd:string):
• personaDisplayLabel (xsd:string):
• username (xsd:string):

Complex Attributes

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

Contexts

Required Context Attributes

In the Higgins Data Model 1.1 all Context attributes are optional. However in Persona Data Model 2.0 we have this requirement:

• All contexts that are made available by a third party (e.g. the government, a bank, etc.) MUST 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.

If this attribute is not present this indicates that the context contains self-asserted information (information directly asserted by the user). If it is present its value is the name of the domain that is the authority that manages the entities in this context. In reality the situation is much more complex. An authority (e.g. the gmail.com domain) 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.

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.

Proposed Extensions

• Persona Account History

Use Cases

• Data Sharing With Alice And Bob
• Activity Streams In Persona

I-Card Ontology (icard.owl)

Information Card (aka i-card) technology is defined by the OASIS IMI TC. It is a standard way to represent a person's digital identities using a card metaphor, XML card formats, and associated SOAP and HTTP network protocols. See also I-Card.

Before we introduce the I-Card classes, 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 that is a subclass of h:Context. This captures the common attributes across the sub-classes defined below. These common attributes include:

• cardId (xsd:string) - a unique identifier for the card
• image - an image bitmap for the background of the card when it is displayed
• ... and many others.

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

• P-Card - an OASIS IMI Personal card
• M-Card - an OASIS IMI Managed card

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

• Personal relationship card (aka r-card)
• Managed r-card

P-Card

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

M-Card

An IMI managed card is represented by the M-Card class, a sub-class of the Context class.

Shown below is an example of an instance of an m-card. For simplicity this m-card has only a single supported claim, "LastName". The entity shown in the center of the card is a cache of what is returned by the STS in response to a request for a display token.

Note: There is an error in the above diagram the DisplayTokenEntity should have been modeled in the Persona data model (thus identity:surname would have been transformed into its equivalent in PDM.

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:

ERRATA: the above image is incorrect for PDM 2.0. As above the card is a context. The entity (in this case referenced by the value of the resource_udr claim) would be a free standing Persona entity (as above) and described in the PDM 1.1 model.

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:

ERRATA: The image above needs to be replaced.

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

See Also

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