Persona Data Model 2.0
The Persona Data Model 2.0 is used by Attribute Data Service 2.0.
- 1 Person graph
- 2 Supporting Contexts
- 3 Representing Social Graphs
- 4 Vocabularies
- 5 Naming Conventions
- 6 Examples
- 7 Viewing & Editing Contexts
- 8 Links
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.
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.
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 entities 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.
Each regular context may have up to one associated template context (pointed to by p:template attribute). This 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
- template information about how to dynamically create the associated regular context
Each regular context is associated with up to one "control" context (linked to by h:context) that contains meta information such as:
- access control policy (e.g. read, write, append) for named external parties trying to access the regular context
- when the regular context was created and modified
Each regular context may be associated with up to one "twin" context (linked to by p:twin) that contains information about the person that is written to by one or more "other" parties in the interaction context. Its associated control context has access control policies that allow this/these other parties to write to this context. In a sense this context contains "what they say about you", whereas the regular context is roughly "what you say about you."
Sharing Inbox Context
In order to bootstrap sharing, each user needs to have a sharing_inbox context that is globally append-able. This allows users to append invites to other user's.
It is used in the [Data_Sharing_With_Alice_And_Bob] scenario.
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.
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
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 - for describing 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
Infocard related vocabularies:
- I-Card vocabulary - OASIS IMI InfoCards
- R-Card vocabulary - Higgins relationship cards (InfoCard extension)
- App-data vocabulary - Higgins app cards (r-card extension)
User Context Naming
User contexts inside an ADS are are named according to the following pattern:
If <meta-type> is missing this implies that this is the id of a "regular" user context, else <meta-type> may be one of these values:
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/staples.com/twin- what staples says about paul
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
Rough notes; a bit long in the tooth: