Persona Data Model 2.0
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 Attribute Data Service 2.0.
- 1 Introduction
- 2 Vocabularies
- 3 Naming
- 4 See Also
A 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 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 person entities can be reached by traversing links of the following kinds, (although other links may also exist (e.g.
In order to simplify the diagram below we follow a convention whereby the links are drawn between contexts whereas in reality the links are between the main
p:Person objects within each of these contexts. Further, these main person entities may well themselves have complex attributes (i.e. links to other entities). These have also been omitted.
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.
The concept of a linked context involves a consuming person in one context be linked to a source person in another context. This is done by linking the person nodes using an intermediate
SourceLink node. For example in the diagram below the P3 person node in context C3 is linked to P1 in C1 and P2 in C2 via two
SourceLink instances. C3 is considered to be linked to C1 and C2.
These links allow a single consuming person node to aggregate one or more other person nodes from other contexts. This promotes reuse of persons and contexts, and minimizes copying and duplication. For example a "recipient" person 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 contexts (e.g. representing the user's relationship with 100 eCommerce sites) each of these 100 context's main persons can have a link to this shared home person & context, rather than having 100 copies of this person in each of the 100 contexts.
Every source link also has an inverse link
p:consumer link pointing in the opposite direction. For clarity these "back" links are not shown above. Any person with more than one "incoming" p:source link (or, said another way more than one outgoing "p:consumer" link) is essentially a "shared" person. Updating a shared person has the effect of altering the attribute values that will be returned by the contexts that use a shared person as a source.
p:sourceLink..p:source links and
p:consumer links are used only to link person entities, not entities in general.
The purpose of the intermediate
SourceLink entity is to qualify the source linkage. It holds a set of attribute names (selected from the Flat Persona vocabulary) that indicate which attributes the link sources. In the example above P1 is a source for
fp:street-address, while P2 is a source for
Attribute-level Access Control
The rules governing access to attributes in context C1 may be defined within C! or within an external control context C2 (where C2 is an instance of Template Context) or both. The access control policies 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.
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.
Nodes 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
- Persona vocabulary - the main PDM data model
- Flat Persona vocabulary - a flattened, simplified subset useful for querying PDM-based data stores
EntityIds and ContextIds
- All absolute entityId and all contextIds MUST be XRI 2.0 URIs or Linked Data URIs
- An entityId MAY be represented in relative form--relative to the base URI of the containing context. e.g. "foo" is an example of a relative entityid. If http://boo.com# is the ContextId containing "foo" then http://boo.com#foo would be the absolute form
- Whether or not an entityId is relative or absolute MUST be able to be determined by inspection of its syntax
- EntityIds MAY be resolvable
- 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 resolve to entities within contexts other than C
- EntityIds that resolve to a context outside of their containing context MUST be in absolute form
- The entityId of the special object within a context that represents the context itself is, by convention, named "_ContextSingleton"
Here is an example of an absolute EntityId:
The above is comprised of this ContextId:
- http//xri.net is prepended to @mydex to convert XRI into URI form
- @mydex is Mydex's entry in the global "@" registry run by Neustar
- @mydex*ptrevithick is paul's i-name (it is a mydex "community" i-name that cost me nothing as Mydex runs their own registry). We could have substituted "=paul.trevithick" (which Paul would have had to pay for) instead of "@mydex*ptrevithick" as long as Paul had carefully set up the ($context)*(amazon.com) SEP identically at both the =paul.trevithick service and the @mydex*ptrevithick service.
- ($context)*(amazon.com) is the portion that identifies the amazon.com profile context as opposed to some other context on Paul's PDS
The above contextId is concatenated with "//" and this relative EntityId:
- Person_1 is the relative entity id within the context. In reality is more likely some number like a34f38c390b8
Rough notes; a bit long in the tooth: