Persona Data Model 2.0
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.
- 1 Person entities, attributes, links and contexts
- 2 Vocabularies
- 3 Proxies
- 4 Connector Contexts
- 5 Supporting Contexts
- 6 Social Graphs
- 7 Inbox Context
- 8 Naming Conventions
- 9 Examples
- 10 Viewing & Editing Contexts
- 11 Links
- 12 Open Issues
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 entity 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 as links to other entity 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.
All of the Person entities can be reached by traversing links of the following kinds, (although other links may also exist (e.g.
- 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:resourcelink 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:resourcelink 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:resourcelink 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.
Contexts describe their contents (i.e. entities and attributes) either in the Persona vocabulary or in a vocabulary that builds on (i.e. imports) the Persona vocabulary. The Persona vocabulary is itself built on several sub-vocabularies, some are existing RDF/OWL vocabularies (e.g. vCard, FOAF, etc.) and others are Higgins-defined.
The Persona Data Model 2.0 also includes these "supporting" vocabularies:
- Flat Persona vocabulary - a flattened, simplified subset useful for querying person.owl-based data stores
- Template vocabulary - for describing template contexts that are instantiated as regular contexts. Also uses these vocabularies:
- View-builder vocabulary - for describing how to hierarchically organize the contents of a context for presentation (e.g. in a UI)
- Mapping vocabulary - a set of rules used to map between persona.owl and vocabularies used by external sites and services
- I-Card vocabulary - for describing OASIS IMI InfoCard cards
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:
For details about proxies see Proxy vocabulary.
As we've described above, regular contexts contain a person entity with an associated set of logically related attributes. These contexts are physically located with the PDS (the attribute data service to be precise), and hold attributes/values that the PDS owner/user can edit and update as they see fit. In other words the owner/user is authoritative over the values of these attributes.
Contexts are also used to create connections to external site and services. In this case there is a relationship between the user's PDS and the external party. There is a set of attributes that describes the entire PDS-to-external-party relationship. One party is authoritative over some of the attributes, and the other party the rest of them.
We describe these bi-directional data sharing relationships using two inter-linked contexts, we refer to one as Definer and the other as Participant. Let's take the example of a relationship with the New York Times. We represent this relationship using a connector context pair:
The attributes of the Person entity in the Participant context could be thought of as a set of statements that Alice wishes to make about herself in the context of their relationship with the NYTimes. It is the face or persona that she wishes to manifest. Examples might include her, first name, last name, email address, home delivery address, etc. The attributes of the Person entity in the Definer context could be thought of as a set of statements that the NTimes wishes to make about Alice in the context of that user's relationship with the NYTimes. Examples might include Alice's subscriber id. These two Person entities are bi-directionally linked with h:correlation links.
The access control policy of the Participant context allows Alice to read and write attributes, and the NYTimes to read them. The access control policy of the Definer context allows Alice to read attributes, and the NYTimes to read and write them.
In the user interface (in the Higgins portal) these twin contexts are combined together and displayed as a single semi-editable view. The attributes taken from the me context are editable in the editor. The attributes taken from the other context are read-only.
Both the definer and the participant contexts contain a single p:Person entity with a set of attributes. These two attribute sets are not necessarily disjoint (i.e. there may be 0..N attributes that are common to both p:Persons). We consider two integration cases. Let's assume that Alice has created a connection to the SONY site. The parameters of this connection were defined by SONY, specifically, by a SONY-minted ConnectorTemplate. We now consider this relationship from each side.
Alice plays the role of participant. Alice's PDS's connection viewer/editor displays a partially editable UI showing these attributes. The UI reads attributes from both the participant and the definer context. The attributes sourced from the participant context are displayed using editable widgets. The attributes sourced from the definer context are displayed using non-editable widgets. For common attributes, the value is taken from the participant context and the value in the definer context is ignored. (These common, ignored attributes may exist in the definer context for sync-related implementation reasons.). Alice's editor write attributes (only) into the participant context. (Note: no attribute change propagation to other contexts is involved here).
SONY play the role of definer. We ignore here the technical details (e.g. network protocols, and/or APIs.) of how this data connection actually works, and just look at the attribute integration logic. SONY reads the values of all attributes in Alice's participant context. If any of these attributes are common to its definer context, it considers that the values of the attributes in Alice's participant context are authoritative, and thus for our purposes here, the values of these same attributes in the definer context are ignored. SONY writes the latest values of attributes over which it is authoritative into the definer context.
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
A template context acts as a template for a regular context. It contains information common to all instances instantiated from it. Each regular context may have up to one associated template context (pointed to by p:template attribute).
A template context may contain one or more of the following:
- view information that describes how to logically organize a presentation interface for the associated context
- A p:Person subclass that has a set of mapping rules described using the Mapping vocabulary
- Information about how to dynamically create the associated regular context
For more information about templates see Template vocabulary.
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
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).
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.
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.
Consumers of the HDM may traverse
h:indeterminate attribute links and (despite ignoring all other links) traverse the entire graph of
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.
User Context Naming
User contexts inside an ADS are are named according to the following pattern:
Examples wherein servername is my.azigo.com:
http://my.azigo.com/ptrevithick/awp- anonymous web profile
http://my.azigo.com/ptrevithick/staples.com- paul's profile at staples.com
http://my.azigo.com/ptrevithick/browsing- browsing history
Any username with 4 or less characters is reserved. Examples of reserved usernames:
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:
http://my.azigo.com/sys/template/awp- the template for a user's regular "awp" context
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 staples.com) 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 "firstname.lastname@example.org" 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