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"

(WSG84)
(Imported Ontologies)
Line 209: Line 209:
  
 
Higgins ontologies:  
 
Higgins ontologies:  
*mapping = mapping.owl - defined by Higgins - schema mapping  
+
*mapping = [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/mapping.owl] - schema mapping rules
*pay = payment.owl - defined by Higgins
+
*pay = [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/payment.owl]
*r-card = rcard.owl - defined by Higgins [[R-Card]]
+
*r-card = [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/rcard.owl rcard.owl] - [[R-Card]]s
*i-card = icard.owl - defined by Higgins - IMI information cards
+
*i-card = [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/icard.owl icard.owl] - IMI information cards
*h = higgins.owl: [[Higgins Data Model 2.0]]
+
*h = [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/higgins.owl higgins.owl] - [[Higgins Data Model 2.0]]
  
 
External ontologies:
 
External ontologies:

Revision as of 15:36, 25 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).

Contents

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 Persona nodes

The user's identity is represented as a graph of p:Persona 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 Persona 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 persona 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 Personas in different contexts that are asserted to be representing the same person 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:Persona node are enumerated, the potentially hundreds of links to p:Persona entities that live in <code>p:PersonaContext</code>s can be differentiated by inspection from the handful of of links to p:Persona 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 Persona instance. This Persona 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 Persona's attributes are common across multiple kinds of interactions related to one's employment.
ProfileContext
A context that contains a Persona instance. This Persona represents a specific profile (set of attributes) used with ONE external person or website/organization.
RootContext
A singleton context that contains the "root" Persona node of the Persona 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 Persona 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:Persona nodes.

Persona.owl

UML Overview

PDM-UML-class-diagram persona 2.0.105.png

Classes

Persona

A contextualized aspect (aka facet) of a person.

  • 0..N role
  • 0..N subCorrelation
  • 0..N hasAgent

Contactable

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

  • subClassOf Persona
  • 0..N pay:paymentMethod

Role

Abstract concept of a role that a p:Persona plays. These concrete subclasses are defined:

  • Work: A work-related role.
  • Home: Acting in a personal, non-professional capacity.
  • Buyer: A person who is physically able to receive a bill and pay a bill. This person must be "contactable" to play this role. They must have a v:adr and v:n and optionally other information so that the bill/invoice can be physically delivered to them. Further, they must be able to pay this bill.
  • Receiver: A person who is physically able to receive a letter, parcel or delivery. This person must be "contactable" to play this role. That is, they must have a v:adr and v:n and optionally other information so that the delivery can be physically routed to them.

DataRanges

  • telephoneURI: a telephone number in tel: URI syntax

Attributes

eyeColor

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

subCorrelation

A relation between two Personas in different contexts that are asserted to be representing the same person 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 larger than the intended audience for the source entity.

  • class: Persona
  • value: Persona

role

A role that this person plays. Multiple values are allowed: e.g. p:Home and p:Buyer indicates that this person is playing the role of both (a) themself in their home/family/personal life and (b) the person who will receive credit card bills and pay them.

  • class: Persona
  • value: Role

hasAgent

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

  • value: Contactable

Persona.owl concepts only used in ProfileContexts

UML Overview

PDM-UML-class-diagram profile context 2.0.104.png

Classes

Account

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

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

Attributes

account

Account information required for authentication.

  • class: p:Persona
  • value: p:Account
neverRememberPassword
  • class: p:Persona
  • value: xsd:boolean
password
  • class: p:Account
  • value: xsd:string
username
  • class: p:Account
  • value: xsd:string

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.

Imported Ontologies

The PDM 2.0 is defined persona.owl and the ontologies it build on. At the heart of the PDM model is the p:Persona 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.

Persona-imports 2.0.105.png

Higgins ontologies:

External ontologies:

vCard

Persona imports vCard, uses most of it as is, but with a few tweaks described below.

UML Overview

We show below the aspect of PDM that builds on the vCard ontology. The heart of the PDM model is the p:Persona 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. Concepts from vCard are shown in italics. Item in non-italics are defined in persona.owl discussed further on.

PDM-UML-class-diagram vcard 2.0.104.png

Classes

Persona

Persona instances have these attributes from vCard:

  • TODO

Contactable

Contactable instances have these attributes from vCard:

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

Other 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 as is used in vCard

Attributes

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

FOAF

Persona.owl imports FOAF and uses some of the attributes it defines.

UML Overview

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

PDM-UML-class-diagram FOAF 2.0.104.png

Attributes

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

WSG84

Persona.owl imports WGS84 and uses some of its classes and attributes.

UML Overview

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

PDM-UML-class-diagram geospatial 2.0.104.png

Classes

Attributes

higgins.owl

Contexts

TODO write introductory text here.

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

payment.owl

Overview

Payment.png

Classes

PaymentMethod

Method of payment including credit cards, paypal, etc.

ByBankTransferInAdvance

  • subclassOf: PaymentMethod

Cash

  • subclassOf: PaymentMethod

CheckInAdvance

  • subclassOf: PaymentMethod

COD

  • subclassOf: PaymentMethod

CreditCard

  • subclassOf: PaymentMethod
  • 1..1 ccCid
  • 1..1 ccExpiration
  • 1..1 ccNumber

AMEX

  • subclassOf: CreditCard

DinersClub

  • subclassOf: CreditCard

Discover

  • subclassOf: CreditCard

MasterCard

  • subclassOf: CreditCard

VISA

  • subclassOf: CreditCard

DirectDebit

  • subclassOf: PaymentMethod

PayPal

  • subclassOf: PaymentMethod

Simple Attributes

ccCid

  • class: CreditCard
  • value: xsd:string

ccExpiration

  • class: CreditCard
  • value: xsd:date

ccNumber

  • class: CreditCard
  • value: xsd:string

Complex Attributes

paymentMethod

  • class: Persona
  • value: PaymentMethod

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.

Classes

I-Card

Abstract class

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

P-Card

An OASIS IMI Personal card

  • subclassOf: I-Card

M-Card

An OASIS IMI Managed card

  • subclassOf: I-Card

P-Card Attributes

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 Attributes

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.

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

rcard.owl

R-Card ontology.

Classes

R-Card

  • subClassOf i-card:I-Card
  • 1..1 resource-udr

Attributes

resource-udr

Representation of the http://schemas.informationcard.net/@ics/resource-udr/2009-03 claim type.

  • class: R-Card
  • value: xsd:anyURI - UDI reference

Personal R-Card Example

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 Persona entity (as above) and described in the PDM 1.1 model. Also icf: prefix should be removed along with ...2008... suffix.

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.

Proposed Extensions

Use Cases

See Also

Back to the top