Skip to main content
Jump to: navigation, search

Difference between revisions of "Persona Data Model 2.0"

(Higgins-defined)
(icard.owl)
Line 495: Line 495:
  
  
 
== 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.
 
 
=== UML Overview ===
 
 
[[Image:Icard 2.0.103.png|center]]
 
 
=== Classes ===
 
 
==== <code>I-Card</code>====
 
Abstract class
 
* subclassOf:  <code>h:Context</code>.
 
*1..1 <code>cardId (xsd:string)</code> - a unique identifier for the card
 
*1..1 <code>image</code> - an image bitmap for the background of the card when it is displayed
 
*... others.
 
 
====<code>P-Card</code>====
 
An OASIS IMI Personal card
 
* subclassOf: <code>I-Card</code>
 
 
====<code>M-Card</code> ====
 
An OASIS IMI Managed card
 
* subclassOf: <code>I-Card</code>
 
 
=== 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:
 
 
[[Image:Personal-i-card-example.png|center]]
 
 
ERRATA: context object entity id should be _ContextSingleton
 
 
=== 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.
 
 
[[Image:M-card-explained.png|center]]
 
 
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.
 
 
 
 
=== 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
 
  
  

Revision as of 22:42, 13 October 2010

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

The Persona Data Model 2.0 (PDM) is builds on Higgins Data Model 2.0 and a number of other models (aka schemas, vocabularies, ontologies). It used by Personal Data Store 2.0 and will likely be used by future Higgins web services.


Introduction

The Persona Data Model 2.0 is an ontology about people. 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). This page provides an informal overview.

A graph of Person nodes

A person 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 (person). 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 persona entities can be reached by traversing links of the following kinds, (although other links may also exist (e.g. p:source, 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 Persons 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 is shown below. In order to simplify the above diagram we follow a convention whereby the links are drawn between contexts whereas in reality the links are between the main p:persona objects within each of these contexts. Further, these main persona entities may well themselves have complex attributes (i.e. links to other entities). These have also been omitted.

Root 2.0.119.png

Vocabularies

In the above example all of the contexts except one express their contents using the Persona Data Model (vocabulary) (shown as purple "PDM"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.

Linked Contexts

A "consuming" persona in one context (e.g. the profile context shown below) may be linked to a "source" persona in another context. This is done by linking the personas with a p:source link (complex-valued attribute). When the persona nodes in two contexts are linked in this way, this is an example of "linked contexts."

These p:source links allow a single consuming persona node to aggregate one or more other persona nodes (usually of differing p:role values) from other contexts. This promotes reuse of personas and contexts and minimizes copying and duplication. For example a "recipient" persona in one context might hold a name, address and phone number that correspond to a physical address, say the person's home. If the user uses this home address in 100 Profile Contexts (e.g. 100 eCommerce websites) each of these 100 context's main personas can have a p:source link to this shared home persona & context, rather than having 100 copies of this persona in each of the 100 contexts.

Linked contexts 20.109.png

Every p:source link also has an inverse link p:consumer pointing in the opposite direction. For clarity these "back" links are not shown above. Any persona with more than one "incoming" p:source link (or, said another way more than one outgoing "p:consumer" link) is essentially a "shared" persona. Updating a shared persona has the effect of altering the attribute values that will be returned by the contexts that use a shared persona as a source.

At present these p:source and p:consumer links are used only to link persona entities, not entities in general.

Access Control

Attribute-level Access Control

The rules governing access to attributes in context C1 are defined in an external control context C2 where C2 is an instance of Template Context. The access control policies in C2 are defined using the Higgins data model's access control vocabulary.

Note: This C2 template context may also contain other rules and definitions unrelated to access control.

Person-level Access Control and Linked Contexts

In addition to the Attribute-level Access Controls, a user agent has write access to a context if:

  • the user agent is the issuer of the context (i.e. it created the context in the first place)
  • the persona to be edited is not linked to by "p:source" links from any personas in contexts whose issuer is other than the user agent

Representing 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. One uses foaf:knows links and and (unrelated to this) shows each node in its own context. The other uses h:relation links and (unrelated) shows all persona nodes in a single context. In the Work context we see that the user knows three colleagues but doesn't know how they know one another. In the Home & Family context we see that the user knows two people and that everyone knows one another. The foaf:knows links are shown in both directions although logically this is redundant since foaf:knows is what is a called a symmetric relation.

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

Social graph 2.0.102.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.

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 Person nodes.

Persona.owl

This is the main vocabulary at the heart of the Persona Data Model 2.0

UML Overview

Persona 2.0.109.png

Classes

Person

A contextualized aspect (aka facet) of a person.

  • 0..N subCorrelation
  • 0..N hasAgent
  • 0..N source

Role

Abstract concept of a role that a Person plays.

Internal

Roles that a person may play

  • subClassOf Role

Defined instances:

  • 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.
  • Recipient: 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.

External

Roles defined by the context of your interaction. E.g. an eCommerce website "imposes" an eCommerce role on you, whereas a gaming site imposes broading a gaming role on you.

  • subClassOf Role

Defined instances:

  • Ecommerce: A role imposed by eCommerce interactions, e.g. with an eCommerce website
  • Gaming: A role imposed by gaming-related interactions, e.g. with a gaming website like world of warcraft
  • SocialNetworking: A role imposed by social interactions, e.g. with a social networking site

RootContext

A singleton context that contains the "root" Person node of the Person graph.

  • subClassOf h:Context

ProfileContext

  • subClassOf h:Context

A context that stores the following kinds of attributes:

  1. One or more p:Person nodes each with RP-specific attributes
    • e.g. united.com frequent flyer number and account balance
    • foaf:OnlineAccount instance (including p:password)
  2. p:Person nodes that have p:source attributes
  3. Disclosure events
    • Events that record what attributes have been disclosed to an RP.


Attributes

hasAgent

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

  • domain: p:Person
  • value: p:Person

issuer

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

neverRememberPassword

Remember whether or not the person wants password managers to capture the password entered into a login form. Only used in Profile Contexts.

  • domain: p:Person
  • value: xsd:boolean

password

The value of the password that a person might enter into a login form. Only used in Profile Contexts

  • domain: foaf:OnlineAccount
  • value: xsd:string

role

A role played by a Person

  • domain: Person
  • value: Role

source

Person node in another context that describes an aspect (usually a role-specific aspect). Both p:Persons may or may not be representations of the same person.

  • domain: p:Person
  • value: p:Person

consumer

Inverse of p:source link.

  • domain: p:Person
  • value: p:Person - consumer

subCorrelation

A relation between two p:Person nodes 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.

  • domain: Person
  • value: Person

Vocabularies Imported by persona.owl

Persona-imports.png

Higgins-defined

External

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:Person class. Concepts from vCard are shown in italics. Item in non-italics are defined in persona.owl discussed further on.

Vcard 2.0.109b.png

Classes

Note: Additional attributes from persona.owl are shown in bold below.

v:Address

  • p:addressNote *
  • p:start ..1
  • p:end ..1
  • v:address ..1
  • v:extended-address ..1
  • v:post-office-box ..1
  • v:locality ..1
  • v:region ..1
  • v:postal-code ..1
  • v:country-name ..1

v:Name

  • v:honorific-prefix ..1
  • v:given-name ..1
  • v:additional-name *
  • v:family-name ..1
  • v:honorific-suffix ..1

v:Organization

  • v:organization-name ..1
  • v:organization-unit ..1

Other attributes

  • v:logo
  • v:tel

Other vCard classes

  • v:Label (disjoint with v:Tel) - not used (don't yet understand what it is)
  • v:Tel - not used; we use foaf:phone instead

Attributes

The following attributes are not used:

  • v:street-address - we use the more granular p:street, p:houseName, p:houseNumber, p:apartment instead
  • v:category
  • v:class
  • v:email - we use foaf:mbox instead
  • 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 classes and attributes it defines.

UML Overview

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

Foaf 2.0.114.png

Classes

  • foaf:OnlineAccount
  • foaf:OnlineEcommerceAccount
  • foaf:OnlineGamingAccount
  • foaf:OnlineChatAccount
  • foaf:Document
  • foaf:PersonalProfileDocument
  • foaf:Image

Attributes

  • foaf:account
  • foaf:accountName
  • foaf:status
  • foaf:myersBriggs
  • foaf:geekcode
  • foaf:geekcode
  • foaf:aimChatID
  • foaf:skypeId
  • foaf:skypID
  • foaf icqChatID
  • foaf:yahooID
  • foaf:msnChatID
  • foaf:made
  • foaf:maker
  • foaf:mbox
  • foaf:mbox_sha1sum
  • foaf:depicts
  • foaf:depiction
  • foaf:knows
  • foaf:gender
  • foaf:thumbnail
  • foaf:page
  • foaf:homepage
  • foaf:weblog
  • foaf:openid
  • foaf:tipjar
  • foaf:schoolHomepage
  • foaf:workplaceHomepage
  • foaf:workInfoHomepage


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:

Geolocation 2.0.109b.png

Classes

Attributes

SKOS

Persona.owl imports the SKOS ontology and uses a few of its classes and attributes.

Classes

  • skos:Concept

Attributes

  • skos:concept
  • skos:broader

Concept Scheme (instance)

Persona.owl includes a concept hierarchy defined using SKOS. This hierarchy can be used by visual editors (e.g. a persona editor) to help organize the UI. Attributes defined in persona.owl include skos:concept annotations to indicate the category of concept the attribute belongs to.

Conceptsv5.png

Which is represented as:

Persona-concept-hierarchy.png

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


mapping.owl

A context holding vocabulary mapping rules.

UML Overview

Mapping 2.0.100.png

Classes

@@@TODO

Attributes

@@@TODO

template.owl

Vocabulary that describes a Template Context. Contains several kinds of "control" information necessary to instantiate and control (e.g. provide access control policies) for regular context instances.

UML Overview

Template 2.0.100.png

Classes

TemplateContext

Template context. Contains several kinds of "control" information necessary to instantiate and control (e.g. provide access control policies) for regular context instances.

  • 0..1 app-data:appData - provides a "template" for the AppData object within a dynamically created AppDataContext
  • 1..1 authNMaterials - part of the metadata necessary to dynamically generate an XRDS service endpoint block within an XRDS
  • 1..1 contextType - part of the metadata necessary to dynamically generate an XRDS service endpoint block within an XRDS
  • 0..N mapping:attributeMap - if present provides RP-to-PDM (and back) vocabulary transformation rules
  • 1..1 templateRole - the default role that persona nodes should inherit when dynamically created with contexts controlled by on this template
  • 0..1 udiMetadata - part of the metadata necessary to dynamically generate an XRDS service endpoint block within an XRDS
  • 1..N used - a list of 1..N attributes that are actually used in contexts controlled by this template context
  • 0..N userUpdateable - a list of 0..N attributes that the user (or user agent) is allowed to modify, delete or add to

UDIMetadata

A set of attribute/values that, taken together, are considered the "Metadata" for the XRDS service endpoint. See http://www.azigo.com/udi/udi-resolution.html#anchor3 for an example.

Attributes

authNMaterialsType

Type of authentication materials required to open this context.

contextType

The type of context endpoint to instantiate from this template. This corresponds to the value of the <Type> element in XRDS resolution (see http://www.azigo.com/udi/udi-resolution.html).

  • domain: TemplateContext
  • value: string, one of {"$context$sparql" , "$context$xdi"}

templateRole

The type of context endpoint to instantiate from this template. This corresponds to the value of the <Type> element in XRDS resolution (see http://www.azigo.com/udi/udi-resolution.html).

  • domain: TemplateContext
  • value: persona:Role

Example

Here is a sample TemplateContext. It contains all of the metadata necessary to dynamically create the UDI service endpoint shown in this sample XRDS discovery document.

 :AppData_1
     rdf:type app-data:AppData ;
     app-data:appDescription
             "A wonderful app"^^xsd:string ;
     app-data:appId "1024"^^xsd:string ;
     app-data:appService "http://kynetx.com/appServer"^^xsd:anyURI ;
     app-data:appServiceType
             "kynetx"^^xsd:string ;
     app-data:appVersion "2.4"^^xsd:string .
 
 :_ContextSingleton
     rdf:type template:TemplateContext ;
     template:authNMaterialsType
             "urn:udi:authnmaterials:1.0:usernamePassword"^^xsd:string ;
     template:contextType
             "$context$xdi"^^xsd:string ;
     template:udiMetadata UDIMetadata_1 ;
     template:used <http://www.w3.org/2006/vcard/ns#bday> , <http://www.w3.org/2006/vcard/ns#postal-code> ;
     template:userUpdateable
             <http://www.w3.org/2006/vcard/ns#bday> ;
     app-data:appData :AppData_1 ;
     higgins:vocabulary <http://www.eclipse.org/higgins/ontologies/2010/6/persona> .
 
 :address
     rdf:type owl:DatatypeProperty ;
     rdfs:domain template:UDIMetadata ;
     rdfs:range xsd:string .
 
 :connectionType
     rdf:type owl:DatatypeProperty ;
     rdfs:domain template:UDIMetadata ;
     rdfs:range xsd:string .
 
 :UDIMetadata_1
     rdf:type template:UDIMetadata ;
     :address "ldap://ldap.company.net:389"^^xsd:string ;
     :connectionType "LDAP"^^xsd:string .

Or visually:

Template example v2.png

Notes:

  1. userUpdateable attribute not shown above
  2. vocabulary attribute not shown above



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

  1. All entityIds MUST be URIs
  2. All entityId values MUST be Linked Data URIs or XRI 2.0 URIs
  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

Context objects:

  1. The entityId of the context object singleton is "_ContextSingleton"

See Also

  • Persona Attribute List - a list of all of the attribute concepts that can be represented in PDM
  • [1] - a developer summary of AppCard implementation issues

Use cases:

Back to the top