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.
Difference between revisions of "Persona Data Model 2.0"
(→The meta context's graph of persona nodes) |
|||
| Line 5: | Line 5: | ||
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. | 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. | ||
| − | === The meta context's graph | + | === The meta context's and the Persona graph === |
| − | + | The user's data is represented as a directed acyclic graph of [[Entity]] nodes interconnected by <code>higgins:correlation</code> links. The root of this graph (as well as possibly some other nodes) lies in a special context (for each user) called the ''meta'' context. By convention entities in this meta context are of class <code>Persona</code> and all have a <code>persona:personaLabel</code> attribute. Note: Nodes may also have links to other entities using link types other than <code>higgins:correlation</code>, however, these links are ''not'' considered part of the Persona graph. The Persona graph is ''distributed''since the entity nodes may live in [[Context]]s that may be physically located anywhere on the Internet. | |
| − | + | An example graph: | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
[[Image:Alice-meta-graph-v3.png|center]] | [[Image:Alice-meta-graph-v3.png|center]] | ||
| − | There are seven nodes in the Persona graph | + | There are seven nodes in the Persona graph. 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 <code> | + | The semantics of the <code>h:correlation</code> link are important. As defined in the [[Higgins Data Model 1.1]] it is statement that, to a human observer, the source and target of this link are considered to be alternative representations of the same real world person or object. A single, natural person would be represented by different entity 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. |
=== Personas and correlations === | === Personas and correlations === | ||
Revision as of 17:51, 30 March 2010
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
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.
The meta context's and the Persona graph
The user's data is represented as a directed acyclic graph of Entity nodes interconnected by higgins:correlation links. The root of this graph (as well as possibly some other nodes) lies in a special context (for each user) called the meta context. By convention entities in this meta context are of class Persona and all have a persona:personaLabel attribute. Note: Nodes may also have links to other entities using link types other than higgins:correlation, however, these links are not considered part of the Persona graph. The Persona graph is distributedsince the entity nodes may live in Contexts that may be physically located anywhere on the Internet.
An example graph:
There are seven nodes in the Persona graph. 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 h:correlation link are important. As defined in the Higgins Data Model 1.1 it is statement that, to a human observer, the source and target of this link are considered to be alternative representations of the same real world person or object. A single, natural person would be represented by different entity 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.
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 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.
Component Ontologies
The PDM 1.1 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 1.1)
- vcard - RDF/OWL representation of well known vcard format
- foaf - friend of a friend ontology
As shown visually here:
Where:
- "p" == Persona Data Model 1.1 (persona.owl, rcard.owl, icard.owl)
- "h" == Higgins Data Model 1.1 (higgins.owl)
Persona Ontology
UML Class Diagram
Classes
Account: Account identifier; may also contain credentialsContactable: A Persona that can be reached either for payment or for receipt of a letter or bill. Subclass ofPersona- 1..1
vcard:n - 1..1
vcard:adr - 0..1
receivableAdr - 0..1
vcard:org
- 1..1
PaymentMethod
Persona: A contextualized aspect of a person.- 0..1
account - 0..1
daytimePhone - 1..1
personaDisplayLabel - 0..1
vcard:n
- 0..1
ReceivableAddress: vCard Address with no P.O. box. Subclass of vcard:Address
PaymentMethod subclasses:
ByBankTransferInAdvanceCashCheckinAdvanceCODCreditCard- 1..1
ccCid - 1..1
ccExpiration - 1..1
ccNumber
- 1..1
DirectDebitPayPal
CreditCard subclasses:
AMEXDinersClubDiscoverMasterCardVISA
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 ofAccountbilling (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 1.1 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:authorityattribute 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.
I-Card Ontology
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. This captures the common attributes across the sub-classes defined below. These common attributes include:
cardId (xsd:string)- a unique identifier for the cardimage- 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
Any Persona-class entity may be one (or two) of these 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
- 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 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