Skip to main content
Jump to: navigation, search

Difference between revisions of "Persona Data Model 2.0"

(Mirror Contexts)
Line 107: Line 107:
In order to bootstrap sharing, each PDS user has an inbox context that is globally append-able. This allows users to append invites to other users. See the [[Data Sharing With Alice And Bob]] scenario.
In order to bootstrap sharing, each PDS user has an inbox context that is globally append-able. This allows users to append invites to other users. See the [[Data Sharing With Alice And Bob]] scenario.
== Vocabularies ==
Contexts may describe their contents in any vocabulary they wish so long as it builds on the [[Persona vocabulary]]. In the person graph example above all of the contexts except one describe 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.
* [[Persona vocabulary]] - the main PDM data model that all contexts must use or build on
* [[Flat Persona vocabulary]] - a flattened, simplified subset useful for querying person.owl-based data stores
* [[View-builder vocabulary]] - describes how to hierarchically organize a context for presentation
* [[Mapping vocabulary]] - rules to map between persona.owl and other vocabularies
* [[Template vocabulary]] - for describing "template" contexts for "regular" contexts
* [[I-Card vocabulary]] - describes OASIS IMI InfoCard cards
* [[App-data vocabulary]] - describes the contexts of app-cards
== Naming Conventions ==
== Naming Conventions ==

Revision as of 10:50, 22 August 2011

Higgins logo 76Wx100H.jpg

A data model that extends the very abstract Higgins Data Model 1.0 to include concrete attributes to model people and their relationships with other people and businesses.

Person graph

A natural, human person is represented as a graph of p:Person entities (nodes, or vertices) interconnected by links (edges). Each node represents a different facet of the user (person). Each of these facets is held in a separate (graph) container called a Context shown below as a round cornered rectangle.

Each Person node is a set of attributes and values. These attributes may be simple literals (e.g. the user's first name) or they may be other entities (which we call complex attributes). These latter attributes are shown in diagrams a as links to other nodes.

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.

Root 2.0.128.png


All of the Person entities can be reached by traversing links of the following kinds, (although other links may also exist (e.g. foaf:knows, etc.):

A link from an entity representing person A to (i) an entity that also represents person A or (ii) to an interstitial Proxy whose p:resource link points to an entity that also represents person A
A link from an entity representing person A to (i) an entity that represents a person other than person A or (ii) to an interstitial Proxy whose p:resource link points to an entity that represents a person other than person A
A link from an entity representing person A to (i) an entity that represents a person that may or may not represent person A or (ii) to an interstitial Proxy whose p:resource link points to an entity that represents a person that may or may not represent person A
A link from a Proxy to an entity in another context.


A Proxy is an object that contains a link (proxy:resource) to an entity (usually a Person) in another context. A proxy allows lazy loading (e.g. by user interfaces) of the entity to which it points. The UI code can rapidly load cards and display them visually. Loading of the resource's context can be delayed and/or happen in a background process.

To simplify diagrams of the persona data model we can hide card/proxies by using the following shorthands:

Proxy 2.0.106.png

For details about proxies see Proxy vocabulary.

Mirror Contexts

Regular contexts contain a person entity with an associated set of logically related attributes. As we've seen above a user might have a root context with, say, NYTimes and Facebook child contexts linked to it. Let's take the NYTimes context. This context's person node and attributes could be thought of as a set of statements that the user wishes to make about themselves in the context of their relationship with the NYTimes. It is the face or persona that they wish to manifest. Essentially this is what the user says about themselves in the context of this relationship. But the NYTimes is also a party to this relationship and they may also have some things to say about the user from their point of view. They might, for example state the user's subscriber id and their home address for home delivery of the printed form of the newspaper. These statements are also represented as a person node with attributes, but these statements live in a mirror context. As shown below the two Person entities are bi-directionally linked with h:correlation links.

Mirror 2.0.101.png

The access control policy of the left-hand context allows Alice to read and write attributes, and the NYTimes to read them. The access control policy of the right-hand context allows Alice to read attributes, and the NYTimes to read and write them.

In the user interface (in the Higgins portal) these mirror contexts are combined together and displayed as a single card. The attributes taken from the left-hand context are editable in the card editor. The attributes taken from the right-hand context are read only.

In the above example the NYTimes is clearly an autonomous entity making its own statements about Alice. Ideally the NYTimes would run a Higgins (or compatible) PDS and directly manage the data storage for, and the network interfaces to the context on the right. Of course in most cases a Higgins-compatible endpoint exposing the right-hand context doesn't exist. To handle these more common cases, we still model the relationship using the two contexts, but we add a data connector process that "speaks" to the external service using whatever native protocols and methods are possible. The data connector reads and writes data into the right-hand context. These connectors could run either in the Higgins browser extension (in JavaScript) or on the Higgins PDS server (in Java).

Supporting Contexts

Each regular context (e.g. each of the contexts shown above) has the following links:

  • 0..1 p:template
  • 0..1 p:control
  • 1..1 h:vocabulary
Supporting 2.0.116.png

Template Context

Each regular context may have up to one associated template context (pointed to by p:template attribute). This template context may be shared by multiple regular contexts.

TemplateContext 2.0.101.png

A template context (see Template vocabulary) may contain one or more of the following:

  • view information that describes how to logically organize a presentation interface for the associated regular context
  • A p:Person subclass that has a set of mapping rules written in the Mapping vocabulary
  • Information about how to dynamically create the associated regular context

Control Context

Each regular context is associated with one "control" context (linked to by h:context). A control context is associated with one regular context. The control context contains meta information including:

  • date-time when the regular context was created and modified
  • access control lists:
    • list of parties (currently PDS account ids) that may read the regular context
    • list of parties that may write the regular context
    • list of parties that may append to the regular context

Vocabulary Context

Each regular context has an h:vocabulary link to a context holding the vocabulary it uses to describe its contents. Multiple regular contexts may the same vocabulary context. The value of this link is usually a reference to the context holding persona.owl (see Persona vocabulary).

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

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

Social 2.0.107.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.

Inbox Context

In order to bootstrap sharing, each PDS user has an inbox context that is globally append-able. This allows users to append invites to other users. See the Data Sharing With Alice And Bob scenario.

Naming Conventions

Context Naming

User Context Naming

User contexts inside an ADS are are named according to the following pattern:


Examples wherein servername is - anonymous web profile - paul's profile at - browsing history

Reserved Usernames

Any username with 4 or less characters is reserved. Examples of reserved usernames:

  • sys
  • root
  • blog

If the username is 4 or less characters this is the id of a system context (see next section)

System Context Naming


The <meta-type> may be one of these values:

  • template
  • ontology
  • data

Example - the template for a user's regular "awp" context

Entity Naming

The root entity in most contexts has a local name of "me".



Imagine a root context containing a p:Person entity locally named "me". This root node could have h:correlation links pointing to the root "me" entities in two contexts, a web profile context, and a alice-staples context.

The web profile context might look like this:


The staples context (the profile of the user at might look like this:


Viewing & Editing Contexts

This section discusses how present (e.g. in a user interface) the contents of a context that is represented using the Persona vocabulary. To construct a data-driven presentation metadata about the attributes of the context is needed. These metadata attributes may live in a number of places. Metadata attributes may:

  • Be attributes of the attribute's class definition (rdf:Property)
  • Be attributes of the an entity class (e.g. persona:Person, vcard:Address)

Further, these metadata attribute statements may be stored either one or the other (or both) places:

  • The context that holds the Persona vocabulary or one of the vocabularies that it imports
  • The template context that holds information to help build a presentation of contexts (see the View-builder vocabulary)

Note: the fact that the metadata may be stored in more than one context has an implication that the lookup APIs should search across ALL contexts for these statements.

Here are some of those metadata attributes:

UI widget label 
This is stored in an internationalized string value of the skos:prefLabel metadata attribute. An example of a UI label might be the string "Zipcode" for the person's postal-code attribute.
The min..max number of values of the attribute. This is an attribute of the class of the entity (e.g. persona:Person, vcard:Address). Min=0 and Max=1 is an example of an attribute that has one optional value.
Example value 
The example value is the value of the skos:example attribute. For example "" might be an example of an example value.
Hover text 
The string description of the attribute is the value of the skos:description attribute.
The type of an attribute is the value of the rdf:type attribute
Allowed values 
For literal-valued attributes an enumerated list of values is provided. This is represented as attributes of the attribute's rdf:range attribute. For example for eye-color the allowed attribute values might be "blue", "green" and "brown".
Syntax restrictions 


Rough notes; a bit long in the tooth:

Back to the top