Skip to main content
Jump to: navigation, search

Persona Data Model 2.0

Revision as of 02:18, 2 November 2010 by (Talk | contribs) (Vocabularies)

Higgins logo 76Wx100H.jpg

The Persona Data Model 2.0 is a vocabulary for describing 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). It used by Personal Data Service 2.0.


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.


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


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


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


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."


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.


Restrictions on EntityIds

The Persona Data Model 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 2.0 URIs
  3. For entityIds that resolve to their containing context the the entityId MAY be represented in "relative" form that is relative to the base URI of the containing context. (e.g. "foo" is an example of a relative entityid. If is the contextId containing "foo" then would be the absolute form)
  4. Whether or not an entityID is relative or absolute MUST be able to be determined by inspection of its syntax


  1. EntityIds MAY be resolvable
  2. A resolveable entityId resolves to exactly one entity. This entity is called the authoritative entity (resource description).
    • Note: although the following capability is not yet used by Higgins code, it is possible that for any given context, C, there may exist both entityId references that resolve to entities within C as well as entityId references that (authoritatively) resolve to entities within contexts other than C
  3. EntityIds that resolve to a context outside of their containing context MUST be in absolute form

Context objects:

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

See Also

Rough notes; a bit long in the tooth:

Back to the top