Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Persona Data Model 2.0"

(vCard)
(vCard)
Line 124: Line 124:
  
 
We show below the aspect of PDM that builds on the vCard ontology. The heart of the PDM model is the p:Person class and its subclass p:Contactable. A contactable is a person that has one v:Address, one v:Name an optional v:Organization--in other words a person that is physically reachable to accept a delivery or pay a bill.
 
We show below the aspect of PDM that builds on the vCard ontology. The heart of the PDM model is the p:Person class and its subclass p:Contactable. A contactable is a person that has one v:Address, one v:Name an optional v:Organization--in other words a person that is physically reachable to accept a delivery or pay a bill.
 +
 +
We show in italics concepts from vCard. As you can see we added one new v:Tel subclass, <code>DayTime</code>.
  
 
[[Image:PDM-UML-class-diagram vcard 2.0.104.png|center]]
 
[[Image:PDM-UML-class-diagram vcard 2.0.104.png|center]]
Line 129: Line 131:
 
We use W3C's representation of vCard RDF with a few modifications.  
 
We use W3C's representation of vCard RDF with a few modifications.  
  
In general <code>Person</code> nodes can be thought of as VCard instances. However PDM imposes the following additional constraints on the structure of a Person. Instances have:
+
In general <code>Person</code>s can be thought of as vCard instances. We have defined a subclass of Person called Contactable that adds the following constraints:
 
+
*0..1 v:n
+
*0..1 v:adr
+
*0..1 v:org
+
 
+
We have defined a sub-class of Person called Contactable that adds the following constraints. Instances have:  
+
  
 
*1..1 v:n  
 
*1..1 v:n  

Revision as of 17:37, 24 July 2010

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
Higgins logo 76Wx100H.jpg

This data model is based on Higgins Data Model 2.0. It used by Personal Data Store 2.0 (i.e. Attribute Service 2.0 and IdAS Proxy Service 2.0) and will likely be used by future Higgins web services (e.g. future versions of I-Card Service 2.0).

Introduction

The Persona_Data_Model_2.0 is a concrete ontology for an individual's personal data. It is based on the Higgins Data Model 2.0 which is in turn based on Context Data Model 2.0 (aka CDM 2.0).

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

A graph of Person nodes

The user's identity is represented as a graph of p:Person class Entity nodes (vertices) interconnected by 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 graph.

The graph is a logical abstraction. The data behind these nodes may be physically located anywhere on the Internet.

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

All of the main "person" entities can be reached by traversing links of the following kinds, (although in addition other links may also exist (e.g. foaf:knows, etc.)):

  • h:correlation
  • h:relation
  • h:indeterminate
  • p:subCorrelation

p:subCorrelation and Access Control

PDM adds p:subCorrelation, a specialized (directed) h:correlation. It is a relation between two entities in different contexts that are asserted to be representing the same thing (person, group, object or concept) and such that the value entity is used in a broader scope (with generally more relaxed access control policies). The size of the intended "audience" for the value entity is typically larger than the intended audience for the source entity. It is a non-symmetric attribute of an entity. The value of this attribute is another entity.

SubCorrelation allows us to construct a directed graph of entities radiating out from the root node. The root node's attributes are the most privileged information about a person. Below is an example of a directed graph. We have displayed a reasonable "default" access control policy for each "level" (i.e. number of hops from the root) of the graph.

Subcorr.png

More detailed example graph

A more detailed example graph (showing only p:subCorrelation links) is shown below. Many details in this diagram will be explained further on:

PDM 2.0.110.png

profile/personaSubCorrelation

For performance reasons, the PDM has added the following link types (sub-attributes of p:subCorrelation): p:personaSubCorrelation and p:profileSubCorrelation. When the links from the root p:Person node are enumerated, the potentially hundreds of links to p:Person<code> entities that live in <code>p:PersonaContexts can be differentiated by inspection from the handful of of links to p:Person entities that live in p:ProfileContexts.

Kinds of Contexts

There are three special kinds of Contexts: PersonaContexts (showed in the tinted areas above), ProfileContexts and the single root RootContext.

PersonaContext
A context containing a Person instance. This Person represents a broad role that a person plays in interacting with multiple other people, websites/organizations. Typical examples of PersonaContexts would be Work, Home & Friends, Citizen, Health and Anonymous. For example, the Work Person's attributes are common across multiple kinds of interactions related to one's employment.
ProfileContext
A context that contains a Person instance. This Person represents a specific profile (set of attributes) used with ONE external person or website/organization.
RootContext
A singleton context that contains the "root" Person node of the Person graph.

Schemas

In the above example all of the contexts except one express their contents using the Persona data model (shown as red "P"s above). The exception is the managed i-card from Equifax which uses attribute (aka claim) URIs defined by the OASIS IMI TC and by the ICF's (Information Card Foundation) schema working group.

Social Graphs

h:relation

HDM defines a h:relation complex attribute that is used in PDM to link one Person node to another where each Person node represents a different person. No symmetry is implied in this thus the statement (A h:relation B) is akin to saying person A "knows of" person B.

Shown below are two social graph examples that use h:relation. In the Work context we see that the user knows three colleagues but doesn't know how they know one another. In the Home & Friends context we see that the user knows three people and that two of these are mutually known to one another.

Nodes that represent the user are shown in purple. Nodes that represent a person other than the user are shown in red.

Social graph 2.0.100.png

foaf:knows

To indicate that a person A "knows" person B where some level of reciprocated interaction between the parties is implied, we use foaf:knows.

Since foaf:knows is a broader concept than h:relation, foaf:knows is not a sub-attribute of h:relation. Thus if we had the statement "A h:relation B" then we might later add a second statement "A foaf:knows B" to add the stronger, broader (and symmetric) concept of "knowing."

h:indeterminate

HDM also defines h:indeterminate link attribute on node A to indicates that its value(s) may or may not represent the same thing as is represented by A. This is useful as a temporary link that will hopefully in the future be replaced with a h:correlation link or an h:relation link.

Implementation Note

Consumers of the HDM may traverse h:relation, h:correlation and h:indeterminate attribute links and (despite ignoring all other links) traverse the entire graph of h:Person nodes.

Imported Ontologies

The PDM 2.0 is defined persona.owl and the ontologies it imports:

Persona-imports 2.0.105.png

Where:

  • mapping.owl - defined by Higgins - schema mapping
  • r-card.owl - defined by Higgins - relationship card
  • i-card.owl - defined by Higgins - IMI information cards

At the heart of the PDM model is the p:Person class and related attributes. In the following sections we describe the concepts that have been adopted by PDM that have been defined in vCard, FOAF and other ontologies.

vCard

We show below the aspect of PDM that builds on the vCard ontology. The heart of the PDM model is the p:Person class and its subclass p:Contactable. A contactable is a person that has one v:Address, one v:Name an optional v:Organization--in other words a person that is physically reachable to accept a delivery or pay a bill.

We show in italics concepts from vCard. As you can see we added one new v:Tel subclass, DayTime.

PDM-UML-class-diagram vcard 2.0.104.png

We use W3C's representation of vCard RDF with a few modifications.

In general Persons can be thought of as vCard instances. We have defined a subclass of Person called Contactable that adds the following constraints:

  • 1..1 v:n
  • 1..1 v:addr

The following attributes are not used:

  • v:category
  • v:class
  • v:fn
  • v:agent - we use hasAgent instead
  • v:geo - we use geo:location instead
  • v:key
  • v:mailer - not sure what this is
  • v:photo - we use foaf:thumbnail instead
  • v:prodid
  • v:rev
  • v:sort-string
  • v:sound
  • v:tz - not sure syntax of range/value
  • v:uid - we use entityId instead
  • v:url - we use foaf:page (and sub-attributes) instead

Use of vCard classes:

  • v:Label (disjoint with v:Tel) - not used (don't yet understand what it is)
  • v:Tel rdf:value is a Telephone URI instead of a string

FOAF

We show below the aspect of PDM that builds on the FOAF ontology:

PDM-UML-class-diagram FOAF 2.0.104.png

Attributes used:

  • foaf:knows
  • foaf:gender
  • foaf:thumbnail
  • foaf:page
    • foaf: homepage
    • foaf: weblog

WSG84

We show below the aspect of PDM that builds on the geospatial ontology:

PDM-UML-class-diagram geospatial 2.0.104.png

Attributes used:

Classes used:

Persona Ontology

UML Class Diagram

The following diagram has been updated to align with persona.owl version 2.0.103. The grayed out classes are from ontologies other than persona.owl:

PDM-UML-class-diagram 2.0.103.png

Classes

Account

Account identifier; may also contain credentials. Used for authentication.

  • 0..1 p:password
  • 1..1 p:username

Contactable

A Person that can be reached either for payment or for receipt of a letter or bill. Subclass of Person

  • 1..1 vcard:n
  • 1..1 vcard:adr
  • 0..1 receivableAdr
  • 0..1 vcard:org

PaymentMethod

Method of payment including credit cards, paypal, etc.

Person

A contextualized aspect (aka facet) of a person.

  • 0..1 account
  • 0..1 daytimePhone
  • 0..1 neverRememberPassword
  • 0..1 v:bday
  • 0..1 foaf:gender

Usually has one or more of the following attributes (some of which are sub-Attributes of h:correlation) whose values are instances of class Contactable:

  • billing
  • home
  • receiving
  • receivingHome
  • work

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

ccCid

  • class: CreditCard
  • value: xsd:string

ccExpiration

  • class: CreditCard
  • value: xsd:date

ccNumber

  • class: CreditCard
  • value: xsd:string

eyeColor

  • class: Person
  • value: xsd:string oneOf(green, blue, brown)

neverRememberPassword

  • class: Persona
  • value: xsd:boolean

password

  • class: p:Account
  • value: xsd:string

username

  • class: p:Account
  • value: xsd:string

Complex Attributes

account

Account information required for authentication. value: Account

billing

Billing person. A person capable of receiving and paying bills.

  • value: Contactable

knows

A person known by this person (indicating some level of reciprocated interaction between the parties).

  • value: Person

hasAgent

A person other than the user to whom some authority to act on the user's behalf has been delegated.

  • value: Contactable

paymentMethod

Payment method.

  • value: PaymentMethod)

receiving

The receiving party (p:Person) may or may not be you.

  • value: Contactable

receivingHome

The receiving party Person<code> is the user and the node value is one of the user's homes.

  • subAttributeOf: <code>p:home
  • subAttributeOf: p:receiving

Contexts

Issuer Attribute

In the Higgins Data Model 2.0 all Context attributes are optional. However in the 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:issuer attribute
  • The attribute value is a URI
  • The URI is either the domain name that is the authority behind the attribute assertions or
  • The value http://!self - the user has explicitly asserted entities & attributes in this context
  • The value http://!derived - the active client has derived entities & attributes in this context based on observed behavior and/or assertions made by the user in other contexts

Concept Scheme

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

Conceptsv5.png

Which is represented as:

Persona-concept-hierarchy.png

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

Proposed Extensions

Use Cases

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:

Personal-i-card-example.png

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.

M-card-explained.png

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:

Example-r-pcard-v2.png

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 Person 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:

Managed-r-card.png

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

Back to the top