Notice: This Wiki is now read only and edits are no longer 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"
(→FOAF) |
(→UML Class Diagram) |
||
Line 149: | Line 149: | ||
The following diagram has been updated to align with persona.owl version 2.0.101. The grayed out classes are from ontologies other than persona.owl: | The following diagram has been updated to align with persona.owl version 2.0.101. The grayed out classes are from ontologies other than persona.owl: | ||
− | [[Image: | + | [[Image:PDM-UML-class-diagram 2.0.103.png|center]] |
=== Classes === | === Classes === |
Revision as of 22:51, 23 June 2010
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}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
- 1 Introduction
- 2 A natural person is represented as a graph of Person nodes
- 3 Imported Ontologies
- 4 Persona Ontology
- 5 I-Card Ontology (icard.owl)
- 6 See Also
Introduction
The Persona Data Model 2.0 is a model a person's (the user's) personal information. 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:
- All entityIds MUST be URIs
- All entityId values MUST be Linked Data URIs or XRI 3.0 URIs as we expect XRI 3.0 to be defined
- All entityIds within a given context MUST be either (a) relative to a "base" URI of the context or (b) absolute
- Whether or not an entityID is relative or absolute MUST be able to be determined by inspection of its syntax
- Absolute entityIds MAY be globally resolvable
- Globally resolvable entityIds resolve to an entity (resource description) within exactly one context
A natural person is represented as a graph of Person nodes
The user's identity is represented as a directed acyclic graph of Person
class 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 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. 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. Lastly, 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 graph is a logical abstraction. The data behind these nodes may be physically located anywhere on the Internet.
Typically each node in the 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) is shown below. Many details in this diagram will be explained further on:
Kinds of Contexts
There are three special kinds of Contexts: PersonaContexts (showed in the tinted areas above), ProfileContexts and the single root MetaContext.
- 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.
- MetaContext
- 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
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. HDM also defined h:indeterminate
which indicates that it is not known if the two nodes represent different or the same things.
Building on h:relation
PDM uses foaf:knows
to indicate that a person is known by the other person (indicating some level of reciprocated interaction between the parties).
Shown below are two social graph examples. 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.
Imported Ontologies
The PDM 2.0 is defined by these ontologies:
- persona.owl - defined by Higgins
- mapping.owl - defined by Higgins - schema mapping
- r-card.owl - defined by Higgins - relationship card
- i-card.owl - defined by Higgins - IMI information cards
And builds on these ontologies:
- higgins.owl - defined by Higgins (see Higgins Data Model 2.0)
- vCard - the W3c's most recent recommended RDF/OWL representation of the IETF vCard format.
- Geolocation - WGS84 Geo Positioning RDF vocabulary
- FOAF - Friend Of A Friend ontology
- Dublin Core - http://dublincore.org/2008/01/14/dcelements.rdf#
As shown visually here:
Errata:
- r-card & mapping ontologies is missing from the above
Where:
- "p" == Persona Data Model 2.0 (persona.owl, rcard.owl, icard.owl)
- "h" == Higgins Data Model 2.0 (higgins.owl)
- "v" or "vcard" == vCard
- "geo" == WGS84
- "foaf" == FOAF
vCard
PDM is based on the W3C's representation of vCard RDF with a few modifications.
In general Person
nodes can be thought of as VCard instances. However PDM imposes the following additional constraints on the structure of a Person. Instances have:
- 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: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
Attributes used:
- foaf:knows
- foaf:gender
- foaf:thumbnail
- foaf:page
- foaf: homepage
- foaf: weblog
WSG84
Attributes used:
Classes used:
Persona Ontology
UML Class Diagram
The following diagram has been updated to align with persona.owl version 2.0.101. The grayed out classes are from ontologies other than persona.owl:
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:
Which is represented as:
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 cardimage
- 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 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:
ERRATA: The image above needs to be replaced.
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 2.0
- Context Data Model 2.0
- R-Card - details of the Persona Data Model 2.0 relating to r-cards.
- Parallel CardSync and XDI Channels