Skip to main content
Jump to: navigation, search

Difference between revisions of "Persona Data Model 2.0"

(AppData)
m
 
(425 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}} [[Image:Higgins logo 76Wx100H.jpg|right]]
+
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
  
The Persona Data Model 2.0 (PDM) is builds on [[Higgins Data Model 2.0]] and a number of other models (aka schemas, vocabularies, ontologies). It used by [[Personal Data Store 2.0]] and will likely be used by future Higgins web services.
+
A data model for people and their relationships with other people and businesses. Builds on [[Higgins Data Model 2.0]].
  
 +
== Person entities, attributes, links and contexts  ==
  
 +
A natural, human person is represented as a graph of <code>p:Person</code> [[Entity|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.
  
== Introduction  ==
+
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.
  
The [[Persona Data Model 2.0]] is an ontology about 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). This page provides an informal overview.
+
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.  
  
== A graph of Persona nodes  ==
+
[[Image:Root 2.0.128.png|center]]
  
A person is represented as a graph of <code>p:Persona</code> 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 &amp; 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.
+
All of the Person entities can be reached by traversing links of the following kinds, (although other links may also exist (e.g. <code>foaf:knows</code>, etc.):
  
The graph is a logical abstraction. The data behind these nodes may be physically located anywhere on the Internet.  
+
;<code>h:correlation</code>: A link from an entity representing person A to (i) an entity that also represents person A or (ii) to an interstitial Proxy whose <code>p:resource</code> link points to an entity that also represents person A
 +
;<code>h:relation</code>: 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 <code>p:resource</code> link points to an entity that represents a person other than person A
 +
;<code>h:indeterminate</code>: 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 <code>p:resource</code> link points to an entity that represents a person that may or may not represent person A
 +
;<code>proxy:resource</code>: A link from a Proxy to an entity in another context.
  
Typically each node in the Persona graph is located in its own [[Context]]. The root node lies in a special context (for each user) called the ''root'' context.
+
== Vocabularies ==
  
All of the main persona entities can be reached by traversing links of the following kinds, (although other links may also exist (e.g. <code>p:source</code>, <code>foaf:knows</code>, etc.)):  
+
=== Vocabularies for Describing People ===
 +
Contexts describe their contents (i.e. person entity attributes) using in the [[Persona vocabulary]] which in turn imports the following well known vocabularies (aka ontologies):
 +
* [[VCard vocabulary usage]]
 +
* [[GeoLocation vocabulary usage]]
 +
* [[FOAF vocabulary usage]]
  
*<code>h:correlation</code>
+
...and the following Higgins-defined vocabularies:
*<code>h:relation</code>
+
* [[Context vocabulary]]
*<code>h:indeterminate</code>
+
* [[Proxy vocabulary]]
*<code>p:subCorrelation</code>
+
* [[Higgins Data Model 2.0]]
  
=== p:subCorrelation and Access Control  ===
+
Not imported by the [[Persona vocabulary]] but recommended where relevant to the developer's problem space:
 +
* [[OpenSocial2 vocabulary]] - additional social Person attributes, Messages, Organization etc.
 +
* [[SchemaOrg vocabulary]] - additional attributes for Person, Organization, Place, Event
 +
* [[Payment vocabulary]] - credit cards, products purchased, etc.
 +
* [[Interest vocabulary]] - general interests - subclasses of online-behavior:InterestTopic
 +
* [[I-Card vocabulary]] - OASIS IMI InfoCard cards
 +
* [[Places vocabulary]] - a database of cities, regions, countries
  
PDM adds <code>p:subCorrelation</code>, a specialized (directed) <code>h:correlation</code>. It is a relation between two Personas 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.
+
=== Supporting Vocabularies ===
  
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.
+
The following vocabularies are used to support the PDS application itself:
  
[[Image:Subcorr.png|center]]  
+
* [[Flat Persona vocabulary]] - a flattened, simplified subset useful for querying persona.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)
 +
** [[App-data vocabulary]] - for describing active, JavaScript content that is either stored in a template or fetched from an external service
 +
** [[Mapping vocabulary]] - a set of rules used to map between persona.owl and vocabularies used by external sites and services
 +
* [[Template-meta vocabulary]] - metadata about connection templates; used to create a registry of templates
 +
* [[Event vocabulary]] - for describing attribute changed and attribute disclosure events
  
=== More detailed example graph  ===
+
== Proxies ==
  
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 <code>p:persona</code> 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.
+
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.
  
[[Image:Root 2.0.119.png|center]]
+
To simplify diagrams of the persona data model we can hide card/proxies by using the following shorthands:
  
=== Vocabularies  ===
+
[[Image:Pdm proxy 2.0.108B.png|center]]
  
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.
+
For details about proxies see [[Proxy vocabulary]].
  
=== Linked Contexts ===
+
== Context Issuer/Authority and Access Control ==
 +
As we've described above, contexts contain person entities each of which is comprised of a set of attributes. Each context has an ''issuer'' attribute that indicates whom is authoritative over the entire contents of the context. If the user is named as the ''issuer'' of the context then the access control policy allows the user to edit and update the entire contents of the context as they see fit. Contexts for which the user is the issuer are physically located within the PDS--the ADS to be precise). The access control policy is contained within a special ''control'' context associated with each (regular) context. For more information about control contexts see the section below on supporting 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 <code>p:source</code> link (complex-valued attribute). When the persona nodes in two contexts are linked in this way, this is an example of "linked contexts."
+
== Connection Context Pairs ==
  
These <code>p:source</code> links allow a single ''consuming'' persona node to aggregate one or more other persona nodes (usually of differing <code>p:role</code> 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.
+
A connection is a relationship between the PDS user and an external site/business or a friend's account on their PDS. There are two sides to these relationships, but not in the usual sense of things. One side is the face that the user wishes to present to the other party. The other side is what the other party says about the person. Each "side" is represented as a p:Person entity. Each p:Person entity lives in its own ''connection'' context. Since both p:Person entities are about the same person, the two person entities are interconnected with h:correlation links.  
  
[[Image:Linked contexts 20.109.png|center]]
+
We refer to one of these ''connection'' contexts as the ''definer'' and the other as ''participant''. In every relationship one party is defining the ground rules for the relationship, and the other is consenting to play within these rules. In a person-to-business relationship the user plays the role of participant, and the business plays the role of definer. In a person-to-person relationship the user could play either role.  
  
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.
+
The definer-created template that governs the connection relationship identifies which attributes the definer provide (i.e. is authoritative over) v.s. which attributes it requests from the participant (i.e. the participant is authoritative over). However, the actor playing the definer role writes to the definer context and the actor playing the participant role writes to the participant context. As a consequence, any given attribute (whether definer-authoritative or participant-authoritative) may be written either context; or both.
  
At present these p:source and p:consumer links are used only to link persona entities, not entities in general.
+
If the user is playing the role of participant, the identifier of the person entity in the participant context is "<contextid>#me" by convention (see the Naming Conventions section below for more details). The id of the person entity in the definer context is a ''globally'' unique identifier of the form "<contextid>#localentityid" where localentityid is usually a URI-friendly normalization of the user's username on the external system.  
  
=== Access Control ===
+
At this point an example might be helpful. Let's take the example of a relationship between the user and the New York Times:
  
====Attribute-level Access Control====
+
[[Image:Connection contexts 2.0.107b.png|center]]
The rules governing access to attributes in context C1 are defined in an external "control" context C2 where C2 is an instance of Mapping Context. Mapping Contexts also contain other rules unrelated to access control.
+
  
@@@@to be completed
+
The attributes of the person entity in the ''participant'' context are the set of statements that Alice makes about herself in the context of their relationship with the NYTimes. It is the face or persona that she wishes to present to that business. Examples might include her, first name, last name, email address, home delivery address, etc. Alice can make these statements by directly editing them in the ''participant'' context using her PDS client. However, she could also express the same intent by interacting with the NYTimes website directly. If she did so the NYTimes agent would write the updated values of these attributes into the ''definer'' context.
  
====Persona-level Access Control and Linked Contexts ====
+
The attributes of the Person entity in the ''definer'' context are the 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.
  
In addition to the Attribute-level Access Controls, a user agent has write access to a context if:
+
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.
* 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  ===
+
In the user interface (in the Higgins portal) these twin contexts are integrated together and displayed as a single semi-editable view. We discuss attribute integration further in a separate section below.
  
==== h:relation ====
+
=== Attribute Integration ===
  
[[Higgins Data Model 2.0|HDM]] defines a <code>h:relation</code> complex attribute that is used in PDM to link one <code>Persona</code> node to another where each <code>Persona</code> node represents a different person. No symmetry is implied in this thus the statement (A <code>h:relation</code> B) is akin to saying person A "knows of" person B.  
+
Both the definer and the participant contexts contain p:Person entities with a set of attributes. These two attribute sets are not necessarily disjoint (i.e. there may be N>1 attributes that are common to both p:Persons). The integration algorithm is as follows:
 +
* For attributes that exist only on one or the other (but not both) of the two interlinked persons, take their values from whichever person entity they are found.
 +
* For attributes that exist on both persons, take the values from the person whose containing context's modified date-time is more recent.  
  
Shown below are two social graph examples. One uses <code>foaf:knows</code> links and and (unrelated to this) shows each node in its own context. The other uses <code>h:relation</code> 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 &amp; Family context we see that the user knows two people and that everyone knows one another. The <code>foaf:knows</code> links are shown in both directions although logically this is redundant since <code>foaf:knows</code> is what is a called a symmetric relation.  
+
Let's examine this algorithm using an example of Alice's connection to the NYTimes website. The parameters of this connection were defined by NYTimes, specifically, by a NYTimes-minted ConnectionTemplate. The relationship involves two disjoint sets of attributes: the set of attributes for which the definer is authoritative, and the set for which the participant is authoritative. In this example Alice is authoritative over three: her first name, last name, and email address. The NYTimes is authoritative over one: Alice's subscriber id.
  
Nodes that represent the user are shown in purple. Nodes representing a person other than the user are shown in red.  
+
Alice plays the role of participant. Alice's PDS's connection viewer/editor reads attributes from both contexts, integrates them according to the algorithm above, and displays a UI showing these all four of these attributes. Since Alice is authoritative over first name, last name and email address, these are displayed using editable UI widgets. Since the NYTimes is authoritative over her subscriber id, this is displayed in a non-editable widget. If Alice updates any values of any of the three editable attributes, these updated values are written into the participant context (and the context's 'modified' timestamp is updated). As described in the next paragraph, the definer context may contain updated values for none, some or all of the attributes over which Alice is authoritative. Thus these attributes may ultimately exist in both contexts. Per the integration algorithm, the UI takes the values of the common attributes from the most recently updated context. If the definer context has been more recently updated, then it reads these Alice-authoritative attributes from the definer context and writes them into the participant context.
  
[[Image:Social graph 2.0.102.png|center]]
+
The NYTimes plays the role of definer. We ignore here the technical details (e.g. network protocols, and/or APIs.) of how this data connection works, and just look at the attribute integration logic. The NTYimes has read/write access to the definer context and read access to the participant context. It can also read the modified date-time values of each. The NYTimes is authoritative over the subscriber id value and under no circumstance (either with the PDS or on the NYTimes site) can Alice update or change this value. The NYTimes writes the value of the subscriber id value into the definer context. However, for the other three attributes over which Alice is authoritative, Alice may update their values on the NYTimes site. If she does, the NYTimes writes the updated values of these 3 attributes into the definer context (and its modified value is updated).
  
==== foaf:knows ====
+
== Website Facade Connections ==
  
To indicate that a person A "knows" person B where some level of reciprocated interaction between the parties is implied, we use foaf:knows.  
+
Until the day when businesses natively support bi-directional data connection APIs and open protocols (e.g. perhaps things built on top of OpenID Connect, etc.) we can create a connection another way. The Higgins PDS project includes an optional browser extension (aka HBX) that can fill attributes from the PDS to the site, and scrape data from the web pages of the site into the user's PDS.
  
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."
+
The data model to implement this involves only one half of the participant/definer context pair described in the previous section. In this case we instantiate a single participant context of a special kind called a WebsiteFacade. The template for this website facade includes scripts, mapping rules and sometimes custom JavaScript to allow the HBX to read/write attributes from/to the site and update them in the user's ADS account. In addition to being editable using the PDS web client UI, the HBX can execute JavaScript that edits it. See [[Website Facade Connection Example]] for more details.
  
==== h:indeterminate ====
+
== Supporting Contexts  ==
  
HDM also defines <code>h:indeterminate</code> link attribute on node A to indicates that its value(s) may or may not represent the same thing as is represented by A.
+
Each regular context (e.g. each of the contexts shown above) has the following links:
  
==== Implementation Note ====
+
*0..1 ctxt:template
 +
*0..1 h:control
 +
*1..1 h:vocabulary
  
Consumers of the HDM may traverse <code>h:relation</code>, <code>h:correlation</code> and <code>h:indeterminate</code> attribute links and (despite ignoring all other links) traverse the entire graph of <code>h:Persona</code> nodes.
+
[[Image:Supporting 2.0.117.png|center]]
  
== Persona.owl ==
+
=== Template Context  ===
  
This is the main vocabulary at the heart of the [[Persona Data Model 2.0]]
+
A template context acts as a template for a (non-template) context. It contains information common to all instances instantiated from it. Each non-template context may have up to one associated template context (pointed to by p:template attribute).  
  
=== UML Overview ===
+
''ConnectorTemplates'' are templates that describe and govern the relationship between a user and an external party such as a business or a friends's PDS. A ConnectorTemplate describes:
[[Image:Persona 2.0.108e.png|center]]
+
* The set of attributes that each "end" of the relationship (e.g. participant vs. definer) agree to provide
 +
* Vocabulary/schema mapping rules to transform the "other" party's attributes into and out of the persona data model
 +
* In the case of connections to websites (as opposed to web services or other PDSes) it may include scripts (e.g. JavaScript) to read/write to/from the site
 +
* ''Future'': a legal contract (agred to by both parties) that governs how each party's attributes may be used.  
  
=== Classes===
+
For more information about templates see [[Template vocabulary]].
==== <code>Persona</code> ====
+
  
A contextualized aspect (aka facet) of a person.  
+
''AppTemplates'' are templates for instantiated applets (PDS add-ons) that have read (and potentially write) access to a specific set of attributes within the PDS.
  
*subClassOf <code>h:Person</code>
+
=== Control Context  ===
*subClassOf <code>geo:SpatialThing</code>
+
  
*0..N <code>subCorrelation</code>
+
Each regular context is associated with one "control" context (linked to by h:control). A control context is associated with one regular context. The control context contains meta information including:
*0..N <code>hasAgent</code>
+
*0..N <code>source</code>
+
  
==== <code>Role</code>====
+
*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
  
Abstract concept of a role that a <code>Persona</code> plays.
+
=== Vocabulary Context  ===
  
====<code>Internal</code>====
+
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]]).
Roles that a person may play
+
* subClassOf <code>Role</code>
+
Defined instances:
+
*<code>Work</code>: A work-related role.
+
*<code>Home</code>: Acting in a personal, non-professional capacity.
+
*<code>Buyer</code>: A person who is physically able to receive a bill and pay a bill. This person must be "contactable" to play this role. They must have a v:adr and v:n and optionally other information so that the bill/invoice can be physically delivered to them. Further, they must be able to pay this bill.
+
*<code>Recipient</code>: A person who is physically able to receive a letter, parcel or delivery. This person must be "contactable" to play this role. That is, they must have a v:adr and v:n and optionally other information so that the delivery can be physically routed to them.
+
  
====<code>External</code>====
+
== Social Graphs  ==
Roles defined by the context of your interaction. E.g. an eCommerce website "imposes" an eCommerce role on you, whereas a gaming site imposes broading a gaming role on you.
+
* subClassOf <code>Role</code>
+
Defined instances:
+
*<code>Ecommerce</code>: A role imposed by eCommerce interactions, e.g. with an eCommerce website
+
*<code>Gaming</code>: A role imposed by gaming-related interactions, e.g. with a gaming website like world of warcraft
+
*<code>SocialNetworking</code>: A role imposed by social interactions, e.g. with a social networking site
+
  
==== <code>RootContext</code>====
+
=== h:relation ===
A singleton context that contains the "root" Persona node of the Persona graph.
+
* subClassOf <code>h:Context</code>
+
  
==== <code>ProfileContext</code>====
+
[[Higgins Data Model 2.0|HDM]] defines a <code>h:relation</code> complex attribute that is used in PDM to link one <code>Person</code> node to another where each <code>Person</code> node represents a different person. No symmetry is implied in this thus the statement (A <code>h:relation</code> B) is akin to saying person A "knows of" person B.
* subClassOf <code>h:Context</code>
+
  
A context that stores the following kinds of attributes:
+
Shown below are two social graph examples. One uses <code>foaf:knows</code> links and and (unrelated to this) shows each node in its own context. The other uses <code>h:relation</code> 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 &amp; Family context we see that the user knows two people and that everyone knows one another. The <code>foaf:knows</code> links are shown in both directions although logically this is redundant since <code>foaf:knows</code> is what is a called a symmetric relation.  
# One or more Persona nodes each with RP-specific attributes
+
#* e.g. united.com frequent flyer number and account balance
+
#* <code>foaf:OnlineAccount</code> instance (including p:password)
+
# Persona nodes that have <code>p:source</code> attributes
+
# Disclosure events
+
#* Events that record what attributes have been disclosed to an RP.
+
  
==== <code>MappingContext</code>====
+
Entities that represent the user are shown in purple. Nodes representing a person other than the user are shown in red.  
A special context that doesn't contain any entities (other than the context singleton itself). However it does contain one or more classes that define mapping rules to/from PDM 2.0.  
+
* subClassOf <code>h:Context</code>
+
  
=== Attributes ===
+
[[Image:Social 2.0.107.png|center]]
  
==== <code>eyeColor</code> ====
+
=== foaf:knows ===
  
*domain: <code>Persona</code>
+
To indicate that a person A "knows" person B where some level of reciprocated interaction between the parties is implied, we use foaf:knows.
*value: <code>xsd:string</code> oneOf(green, blue, brown)
+
  
==== <code>hasAgent</code> ====
+
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."
  
A person other than the user to whom some authority to act on the user's behalf has been delegated.
+
=== h:indeterminate ===
  
*domain: <code>p:Persona</code>
+
HDM also defines <code>h:indeterminate</code> link attribute on node A to indicates that its value(s) may or may not represent the same thing as is represented by A.
*value: <code>p:Persona</code>
+
 
+
==== <code>issuer</code>  ====
+
 
+
In the [[Higgins Data Model 2.0]] all Context attributes are optional. However in the [[Persona Data Model 2.0]] we have this requirement:
+
 
+
*All contexts that are made available by a third party (e.g. the government, a bank, etc.) MUST have a <code>p:issuer</code> attribute  
+
*The attribute value is a URI
+
*The URI is either the domain name that is the authority behind the attribute assertions or
+
*The value <code>http://!self</code> - the user has explicitly asserted entities &amp; attributes in this context
+
*The value <code>http://!derived</code> - the active client has derived entities &amp; attributes in this context based on observed behavior and/or assertions made by the user in other contexts
+
 
+
==== <code>neverRememberPassword</code> ====
+
Remember whether or not the person wants password managers to capture the password entered into a login form. Only used in Profile Contexts.
+
 
+
* domain: <code>p:Persona</code>
+
* value: <code>xsd:boolean</code>
+
 
+
==== <code>password </code>  ====
+
The value of the password that a person might enter into a login form. Only used in Profile Contexts
+
* domain: <code>foaf:OnlineAccount</code>
+
* value: <code>xsd:string</code>
+
 
+
==== <code>role</code>  ====
+
A role played by a Persona
+
* domain: <code>Persona</code>
+
* value: <code>Role</code>
+
 
+
==== <code>source</code>  ====
+
Persona node in another context that describes an aspect (usually a role-specific aspect). Both personas may or may not be representations of the same person.
+
+
* domain: <code>p:Persona</code>
+
* value: <code>p:Persona</code>
+
 
+
==== <code>consumer</code>  ====
+
Inverse of <code>p:source</code> link.
+
* domain: <code>p:Persona</code>
+
* value: <code>p:Persona</code> - consumer
+
 
+
==== <code>subCorrelation</code> ====
+
A relation between two Personas 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 larger than the intended audience for the source entity.
+
* domain: <code>Persona</code>
+
* value: <code>Persona</code>
+
 
+
== Vocabularies Imported by persona.owl ==
+
 
+
[[Image:Persona imports v6.png|center]]
+
 
+
=== Higgins-Defined ===
+
 
+
*'''event''': event types. Source is in svn: [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/event.owl event.owl]
+
*'''mapping''': schema mapping rules. Source in svn: [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/mapping.owl mapping.owl]
+
*'''pay''': payment methods. Source in svn: [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/payment.owl payment.owl]
+
*'''app-data''': app-data context definition. Source in svn: [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/app-data.owl app-data.owl]
+
*'''r-card''': relationship card. See [[R-Card]]. Source in svn [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/rcard.owl rcard.owl]
+
*'''i-card''': information card represented in OWL. See [[I-Card]]. Source in svn: [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/icard.owl icard.owl] 
+
*'''h''': [[Higgins Data Model 2.0]]. Source in svn: [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/higgins.owl higgins.owl]
+
 
+
===External===
+
 
+
*v = [http://www.w3.org/TR/vcard-rdf/ vCard]
+
*geo = [http://www.w3.org/2003/01/geo/wgs84_pos WGS84 Geo Positioning]
+
*foaf = [http://xmlns.com/foaf/0.1 Friend Of A Friend ontology]
+
*skos = [http://www.w3.org/2004/02/skos/core SKOS ontology]
+
*spl = [http://spinrdf.org/spl SPL], spin = [http://spinrdf.org/spin SPIN], sp = [http://spinrdf.org/sp SP]
+
*dc = [http://dublincore.org/2008/01/14/dcelements.rdf# Dublin Core]
+
*owl = [http://www.w3.org/TR/owl2-overview/ OWL 2], [http://www.w3.org/TR/rdf-schema/ RDFS], [http://www.w3.org/TR/rdf-syntax-grammar/ RDF]
+
 
+
== vCard  ==
+
Persona imports [http://www.w3.org/TR/vcard-rdf/ vCard], uses most of it as is, but with a few tweaks described below.
+
 
+
=== UML Overview===
+
We show below the aspect of PDM that builds on the vCard ontology. The heart of the PDM model is the p:Persona class. Concepts from vCard are shown in italics. Item in non-italics are defined in persona.owl discussed further on.
+
 
+
[[Image:Vcard 2.0107.png|center]]
+
 
+
===Classes===
+
 
+
 
+
Note: Additional attributes from persona.owl are shown in bold below.
+
 
+
==== v:Address ====
+
 
+
*'''p:addressNote''' *
+
*'''p:start ''' ..1
+
*'''p:end''' ..1
+
*v:address ..1
+
*v:extended-address ..1
+
*v:post-office-box ..1
+
*v:locality ..1
+
*v:region ..1
+
*v:postal-code ..1
+
*v:country-name ..1
+
 
+
====v:Name====
+
* v:honorific-prefix ..1
+
* v:given-name ..1
+
* v:additional-name *
+
* v:family-name ..1
+
* v:honorific-suffix ..1
+
 
+
====v:Organization====
+
* v:organization-name ..1
+
* v:organization-unit ..1
+
 
+
====Other attributes====
+
* v:logo
+
* v:tel
+
 
+
=== Other vCard classes ===
+
 
+
*v:Label (disjoint with v:Tel) - not used (don't yet understand what it is)
+
*v:Tel - not used; we use foaf:phone instead
+
 
+
===Attributes===
+
The following attributes are '''not''' used:
+
* v:street-address - we use the more granular p:street, p:houseName, p:houseNumber, p:apartment instead
+
*v:category
+
*v:class
+
*v:email - we use foaf:mbox instead
+
*v:fn
+
*v:agent - we use hasAgent instead
+
*v:geo - we use geo:location instead
+
*v:key
+
*v:mailer - not sure what this is
+
*v:photo - we use foaf:thumbnail instead
+
*v:prodid
+
*v:rev
+
*v:sort-string
+
*v:sound
+
*v:tz - not sure syntax of range/value
+
*v:uid - we use entityId instead
+
*v:url - we use foaf:page (and sub-attributes) instead
+
 
+
== FOAF  ==
+
 
+
Persona.owl imports [http://xmlns.com/foaf/0.1 FOAF] and uses some of the classes and attributes it defines.
+
 
+
=== UML Overview  ===
+
 
+
We show below the aspect of PDM that builds on the FOAF ontology:
+
 
+
[[Image:Foaf 2.0.113.png|center]]
+
 
+
=== Classes  ===
+
 
+
*foaf:OnlineAccount
+
*foaf:OnlineEcommerceAccount
+
*foaf:OnlineGamingAccount
+
*foaf:OnlineChatAccount
+
*foaf:Document
+
*foaf:PersonalProfileDocument
+
*foaf:Image
+
 
+
=== Attributes  ===
+
 
+
*foaf:account
+
*foaf:accountName
+
*foaf:status
+
*foaf:myersBriggs
+
*foaf:geekcode
+
*foaf:geekcode
+
*foaf:aimChatID
+
*foaf:skypeId
+
*foaf:skypID
+
*foaf icqChatID
+
*foaf:yahooID
+
*foaf:msnChatID
+
*foaf:made
+
*foaf:maker
+
*foaf:mbox
+
*foaf:mbox_sha1sum
+
*foaf:depicts
+
*foaf:depiction
+
*foaf:knows
+
*foaf:gender
+
*foaf:thumbnail
+
*foaf:page
+
*foaf:homepage
+
*foaf:weblog
+
*foaf:openid
+
*foaf:tipjar
+
*foaf:schoolHomepage
+
*foaf:workplaceHomepage
+
*foaf:workInfoHomepage
+
 
+
== WSG84  ==
+
Persona.owl imports [http://www.w3.org/2003/01/geo/wgs84_pos WGS84] and uses some of its classes and attributes.
+
 
+
=== UML Overview===
+
We show below the aspect of PDM that builds on the geospatial ontology:
+
 
+
[[Image:Geo2.0.106.png|center]]
+
 
+
===Classes===
+
 
+
*geo:Point
+
*geo:SpatialThing (a p:Persona is a subclass of geo:SpatialThing)
+
 
+
===Attributes===
+
 
+
*geo:location
+
*geo:lat
+
*geo:long
+
*geo:alt
+
 
+
== SKOS ==
+
 
+
Persona.owl imports the [http://www.w3.org/2004/02/skos/core SKOS] ontology and uses a few of its classes and attributes.
+
 
+
===Classes===
+
 
+
* skos:Concept
+
 
+
===Attributes===
+
* skos:concept
+
* skos:broader
+
 
+
===Concept Scheme (instance)===
+
 
+
Persona.owl includes a concept hierarchy defined using SKOS. This hierarchy can be used by visual editors (e.g. a persona editor) to help organize the UI. Attributes defined in persona.owl include <code>skos:concept</code> annotations to indicate the category of concept the attribute belongs to.
+
 
+
[[Image:Conceptsv5.png|center]]
+
 
+
Which is represented as:
+
 
+
[[Image:Persona-concept-hierarchy.png|center]]
+
 
+
Note: see [[Higgins Data Model 2.0]] for more information on concept schemes.
+
 
+
== event.owl ==
+
A vocabulary to describe events that happen at a specific date and time and that affect either a specific attribute of an entity or all attributes of that entity. Event types include CRUD operations, verification events and disclosure events.
+
 
+
===Overview===
+
[[Image:Event 2.0.107.png|center]]
+
 
+
===Classes===
+
==== <code>Event</code> ====
+
Change event. Abstract superclass. Subclasses describes changes to an attribute "attribute" of some entity "entity" that happened at dateTime "at"
+
* 1..1 at
+
* 1..N entity
+
 
+
==== <code>AttPolicy</code>====
+
An association of an attribute of some entity with a disclosure policy
+
* 1..1 policy
+
* 1..1 attribute
+
* 1..1 entity
+
 
+
==== <code>AttributeChanged</code> ====
+
A class of events wherein a single attribute is changed
+
* subClassOf Event
+
* 1..1 attribute
+
* 1..1 entity
+
 
+
==== <code>Add</code> ====
+
New value "value"(s) was/were added to attribute "attribute" of entity "entity" at dateTime "at"
+
* subClassOf event:AttributeChanged
+
* 1..N value - "new" value(s)
+
 
+
==== <code>Delete</code> ====
+
One, more or all values of attribute "attribute" of entity "entity" was deleted at dateTime "at". Values to be deleted are specified by one or more "oldValue"(s). If all values of attribute "attribute" are to be deleted then the oldValue (attribute) is omitted.
+
* subClassOf event:AttributeChanged
+
* 1..N oldValue
+
 
+
==== <code>Get</code> ====
+
One or more values of attribute "attribute" of entity "entity" was read at dateTime "at"
+
* subClassOf AttributeChanged
+
 
+
==== <code>Modify</code> ====
+
The attribute "attribute" of entity "entity" was modified at datetime "at". The value "oldValue" was replaced with value(s) "newValue"
+
* subClassOf AttributeChanged
+
* 1..1 oldValue
+
* 1..N value
+
 
+
==== <code>Disclosure</code> ====
+
A disclosure of attributes to an external party (e.g. an RP website). Each "entity" points to a context object (h:Context instance)
+
* subClassOf: Event
+
* 1..1 relyingParty
+
* 1..N disclosed
+
 
+
==== <code>Verification</code> ====
+
Verification event performed by the p:issuer of this context. If event:attribute is not present then event:entity(ies) in their entirety have been verified. Else if event:attribute is present then just the attribute mentioned has been verified.
+
* subClassOf Event
+
* 1..1 entity
+
* 0..1 verificationResult
+
 
+
===Attributes===
+
 
+
==== <code>at</code>  ====
+
When this event happened
+
* domain: Event
+
* value: dateTime
+
 
+
==== <code>attribute</code>  ====
+
* value: an attribute
+
 
+
==== <code>disclosed</code>  ====
+
The attribute that has been disclosed/blocked
+
* domain: Disclosure
+
* value: AttPolicy
+
 
+
==== <code>entity</code>  ====
+
The entity that has been verified
+
* domain: Event
+
* value: an entity
+
 
+
==== <code>event</code> ====
+
An event that happened. Used to associate event(s) with some object to which it relates (often an h:Context)
+
* value: Verification
+
 
+
==== <code>oldValue</code>  ====
+
Old value of an attribute
+
* domain: Delete, Modify
+
* value: entity or literal
+
 
+
==== <code>policy</code>  ====
+
* domain: AttPolicy
+
* value: string value one of {"allow", "block"}
+
 
+
==== <code>relyingParty</code>  ====
+
* domain: Disclosure
+
* value: xsd:anyURI
+
 
+
==== <code>value</code>  ====
+
New value(s)
+
* domain: Add, Modify
+
* value: entity or literal
+
 
+
==== <code>verificationResult</code>  ====
+
Result of verification
+
New value(s)
+
* domain: Verification
+
* value: one of {"false" , "indeterminate" , "true"}
+
 
+
== mapping.owl ==
+
@@@TODO
+
 
+
== payment.owl ==
+
 
+
===Overview===
+
[[Image:Payment.png|center]]
+
 
+
=== Classes ===
+
==== <code>PaymentMethod</code> ====
+
 
+
Method of payment including credit cards, paypal, etc.
+
 
+
==== <code>ByBankTransferInAdvance</code>, <code>Cash</code>, <code>CheckInAdvance</code>, <code>COD</code> ====
+
* subclassOf: <code>PaymentMethod</code>
+
 
+
==== <code>CreditCard</code> ====
+
* subclassOf: <code>PaymentMethod</code>
+
*1..1 <code>ccCid</code>
+
*1..1 <code>ccExpiration</code>
+
*1..1 <code>ccNumber</code>
+
 
+
====<code>AMEX</code>, <code>DinersClub</code>, <code>Discover</code>, <code>MasterCard</code>, <code>VISA</code>, <code>DirectDebit</code>, <code>PayPal</code>====
+
* subclassOf: <code>CreditCard</code>
+
 
+
=== Attributes  ===
+
 
+
==== <code>ccCid </code>  ====
+
 
+
*domain: <code>CreditCard</code>
+
*value: <code>xsd:string</code>
+
 
+
==== <code>ccExpiration </code>  ====
+
 
+
*domain: <code>CreditCard</code>
+
*value: <code>xsd:date</code>
+
 
+
==== <code>ccNumber </code>  ====
+
 
+
*domain: <code>CreditCard</code>
+
*value: <code>xsd:string</code>
+
 
+
==== <code>paymentMethod</code>  ====
+
*domain: <code>Persona</code>
+
*value: <code>PaymentMethod</code>
+
 
+
== icard.owl  ==
+
 
+
Information Card (aka i-card) technology is defined by the OASIS IMI TC. It is a standard way to represent a person's digital identities using a card metaphor, XML card formats, and associated SOAP and HTTP network protocols. See also [[I-Card]].
+
 
+
Before we introduce the I-Card classes, remember that in CDM multiple inheritance is allowed: any single entity may be a member of multiple classes simultaneously.
+
 
+
=== UML Overview ===
+
 
+
[[Image:Icard 2.0.103.png|center]]
+
 
+
=== Classes ===
+
 
+
==== <code>I-Card</code>====
+
Abstract class
+
* subclassOf:  <code>h:Context</code>.
+
*1..1 <code>cardId (xsd:string)</code> - a unique identifier for the card
+
*1..1 <code>image</code> - an image bitmap for the background of the card when it is displayed
+
*... others.
+
 
+
====<code>P-Card</code>====
+
An OASIS IMI Personal card
+
* subclassOf: <code>I-Card</code>
+
 
+
====<code>M-Card</code> ====
+
An OASIS IMI Managed card
+
* subclassOf: <code>I-Card</code>
+
 
+
=== P-Card Attributes ===
+
 
+
The attributes that define a personal card are taken directly from the OASIS IMI specification. An example p-card is shown here:
+
 
+
[[Image:Personal-i-card-example.png|center]]
+
 
+
ERRATA: context object entity id should be _ContextSingleton
+
 
+
=== M-Card Attributes ===
+
 
+
Shown below is an example of an instance of an m-card. For simplicity this m-card has only a single supported claim, "LastName". The entity shown in the center of the card is a cache of what is returned by the STS in response to a request for a display token.
+
 
+
[[Image:M-card-explained.png|center]]
+
 
+
Note: There is an error in the above diagram the DisplayTokenEntity should have been modeled in the Persona data model (thus identity:surname would have been transformed into its equivalent in PDM.
+
 
+
 
+
 
+
=== Card Axioms  ===
+
 
+
#For any [[M-Card]]: The ''value'' of any of the above "supported" claims attributes is considered to be a cache of the most recent value of these claims as fetched from the m-card's STS
+
 
+
== rcard.owl ==
+
 
+
Vocabulary to describe [[R-Card]]s (including [[App-Card]]s).
+
 
+
=== UML Overview ===
+
 
+
[[Image:Rcard 2.0.102.png|center]]
+
 
+
=== Classes ===
+
 
+
====<code>R-Card</code>====
+
A Higgins relationship card ([[R-Card]]), which is essentially a profile of an IMI managed or personal i-card.
+
* subClassOf <code>i-card:I-Card</code>
+
* 1..1 <code>resource-udr</code>
+
 
+
====<code>AppCard</code>====
+
An [[App-Card]] is an r-card that supports a Javascript app. It's resource-udr is a reference to a target entity in an AppData context (see app-data.owl). This resource-udr's target entity and its surrounding context are described by the app-data ontology.
+
* subClassOf: R-Card
+
* 0..1 template (URL) - a link to an external "template" context
+
 
+
=== Attributes ===
+
 
+
====<code>resource-udr</code>====
+
Representation of the http://schemas.informationcard.net/@ics/resource-udr/2009-03 claim type.
+
* domain: <code>R-Card</code>
+
* value: <code>xsd:anyURI</code> - [http://www.azigo.com/company/dev/udi/ UDI] resource reference
+
 
+
====<code>template</code>====
+
URL of an RDF file in n3 notation that describes the AppData context that should be instantiated for this AppCard. This file needs to have (i) the context attributes (although not persona attributes) from an AppData context (ii) the list "approved" attributes (within the overall vocabulary/schema) such as is listed in a MappingContext (iii) access control rules to indicate which attributes are user-editable (the balance being editable by the issuer/authority) and (iv) the type of context implementation (so we know which context provider to use).
+
* domain: <code>AppCard</code>
+
* value: <code>xsd:anyURI</code>
+
 
+
=== Personal R-Card Example ===
+
 
+
From a structural point of view, the presence of the resource-udr claim on a [[P-Card]] or an [[M-Card]] makes it be considered an [[R-Card]]. Here is an example of a personal [[R-Card]]:
+
 
+
[[Image:Example-r-pcard-v2.png|center]]
+
 
+
ERRATA: the above image is incorrect for PDM 2.0. As above the card is a context. The entity (in this case referenced by the value of the resource_udr claim) would be a free standing <code>Persona</code> entity (as above) and described in the PDM 1.1 model. Also icf: prefix should be removed along with ...2008... suffix. Also entityid of context object should be _ContextSingleton
+
 
+
=== Managed R-Card  ===
+
 
+
The final type of card is the managed r-card. The presence of the resource-udr claim makes an ordinary [[M-Card]] into an [[R-Card]]. Here is an example of a managed [[R-Card]]:
+
 
+
[[Image:Managed-r-card.png|center]]
+
 
+
ERRATA: The image above needs to be replaced. Card entityid should be _ContextSingleton
+
 
+
== app-data.owl  ==
+
 
+
Provides the classes and attributes to represent the "target" entity pointed to by an app-card as well as the app metadata and parameters for the app itself
+
 
+
===UML Overview===
+
 
+
[[Image:App-data 2.0.100.png|center]]
+
 
+
=== Classes  ===
+
 
+
==== <code>AppDataContext</code> ====
+
 
+
A kind of context holding an AppData instance as well as the entity referenced by the resource-udr of an AppCard
+
 
+
*subClassOf: h:Context
+
*1..1 <code>appData</code>
+
 
+
==== <code>AppData</code>====
+
The information about an app. This information is pointed to by the context holding the target of an app-card's resource-udr.
+
*1..1 <code>appId</code>
+
*1..1 <code>appDescription</code>
+
*1..1 <code>appVersion</code>
+
*0..N <code>appSites</code>
+
*0..N <code>appEntityParam</code>
+
*0..1 <code>appParams</code>
+
*1..1 <code>appAdminURL</code>
+
*1..1 <code>appServiceType</code> - the type of service from which the Javascript is fetched
+
*1..1 <code>appService</code> - the Javascript service URL
+
 
+
==== <code>AppParams</code> ====
+
 
+
An AppParams instance is the value of an AppCard's <code>appParams</code> attribute. It is a set of attributes and values used to initialize the app. Note: these attribute/values are combined with those derived from the AppCard's <code>appEntityParam</code>.
+
 
+
=== AppDataContext Attributes ===
+
 
+
 
+
==== <code>appData</code> ====
+
 
+
The information about an app. This information is pointed to by the context holding the target of an app-card's resource-udr.
+
 
+
*domain: <code>AppDataContext</code>
+
*value: <code>AppData</code>
+
 
+
=== AppData Attributes ===
+
 
+
==== <code>appId</code> ====
+
 
+
Uniquely identifies the app within the "developerId" (i.e. the card issuer) namespace. In other words the combination of the <code>devID</code> and the <code>appId</code> is globally unique. When using Kynetx KNS this is the ruleID with special constraint that this ruleID is globally unique.
+
 
+
*domain: <code>AppData</code>
+
*value: string
+
 
+
==== <code>appDescription</code> ====
+
 
+
A human readable description of the app. Note: If appServer == http(s)://init.kobj.net, then the KNS "describe" API can be used by a context provider implementation to provide this attribute value.
+
 
+
*domain: <code>AppData</code>
+
*value: string
+
 
+
==== <code>appEntityParam</code> ====
+
 
+
The name of an attribute (e.g. <code>p:postal-code</code>) of the "target" entity of the app-card. The value of this named attribute of the target entity is used as a parameter to the app-card's app.
+
 
+
*domain: <code>AppData</code>
+
*value: URI
+
 
+
==== <code>appAdminURL</code> ====
+
The URL of a webapp to load into an active client's "dashboard" (admin) UI.
+
 
+
*domain: <code>AppData</code>
+
* value: xsd:anyURI
+
 
+
==== <code>appEntityParam</code> ====
+
 
+
The value is the (URI) name of an attribute on the AppCard's target entity. This referenced attribute and its value should be used to initialize the app.
+
*domain: <code>AppData</code>
+
*value: URI name of an attribute
+
 
+
==== <code>appParams</code> ====
+
 
+
A set of attributes used to initialize the app.
+
*domain: <code>AppData</code>
+
*value: AppParams
+
 
+
==== <code>appService</code>  ====
+
 
+
The URI giving the endpoint from which the Javascript should be fetched.
+
*domain: <code>AppData</code>
+
*value: URI
+
 
+
==== <code>appServiceType</code>  ====
+
 
+
If value is "kynetx" then the browser extension that will inject the Javascript for this app-card should construct a Kynetx-compatible &lt;script&gt; block and call an initialization URL based on the value of the <code>appService</code> attribute.
+
*domain: <code>AppData</code>
+
*value: string whose value is one of ("kynetx", "higgins").
+
 
+
==== <code>appSites</code> ====
+
  
This is not a list of specific URIs, it is a list of strings to match in the domain name part of a URI. So urn:google would fire on maps.google.com, www.google.com, www.googleismyfavoritesite.com. For Kynetx-powered cards (i.e. if appServer = http[s]://init.kobj.net"), the values of this attribute should be dynamically fetched using the 'dispatch' method at URL: [http://init.kobj.net/js/dispatch/]&lt;appId&gt;.
+
=== Implementation Note ===
*domain: <code>AppData</code>
+
*value: string
+
  
==== <code>appVersion</code> ====
+
Consumers of the HDM may traverse <code>h:relation</code>, <code>h:correlation</code> and <code>h:indeterminate</code> attribute links and (despite ignoring all other links) traverse the entire graph of <code>Person</code> nodes.
  
A human readable version of the app. Note: If appServer == http(s)://init.kobj.net, then the Kynetx KNS "describe" API can be used by a context Provider implementation to provide this attribute value.  
+
== Inbox Context ==
*domain: <code>AppData</code>
+
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.
*value: string
+
  
=== Attributes of contained Persona  ===
+
== Naming Conventions ==
  
==== <code>enabled</code>  ====
+
=== Context Naming ===
  
* domain is the ''target'' entity to which the underlying r-card's resource-udr points. Value is URL of a site that the user has explicitly enabled
+
==== User Context Naming ====
*value: boolean
+
  
==== <code>disabled</code>  ====
+
User contexts inside an ADS are are named according to the following pattern:
  
* domain is the ''target'' entity to which the underlying r-card's resource-udr points. Value is URL of a site that the user has explicitly disabled
+
  <code>http://<servername>/<username>/<context-name></code>
*value: xsd:anyURI
+
  
==== <code>appEnabled</code>  ====
+
If the context is part of a connection context pair then the ''context-name'' uniquely identifies the "other" party in the connection. If the other party is a website then ''context-name'' is the domain name of the site (e.g. "staples.com").
 +
 
 +
Examples wherein servername (PDS/ADS operator) is my.azigo.com:
  
* domain is the ''target'' entity to which the underlying r-card's resource-udr points. If true the Javascript of this card is enabled to run.  
+
  <code>http://my.azigo.com/ptrevithick/awp</code> - anonymous web profile
*value: xsd:anyURI
+
  <code>http://my.azigo.com/ptrevithick/staples.com</code> - paul's profile at staples.com
 +
  <code>http://my.azigo.com/ptrevithick/browsing</code> - browsing history
  
=== Example AppCard and AppData ===
+
==== Reserved Usernames ====
  
Note: Not shown is a r-card:resource-udr link from the AppCard in the upper diagram to the Persona_1 entity in the lower diagram.
+
Any username with 4 or less characters is reserved. Examples of reserved usernames:
 +
* sys
 +
* root
 +
* blog
  
====AppCard====
+
If the username is 4 or less characters this is the id of a system context (see next section)
  
Example of an AppCard context:
+
==== System Context Naming ====
[[Image:App card v3.png|center]]
+
  
Note: missing from the above diagram is the list of supported claims. This list would include the ICF's resource-udr claim type.
+
  <code>http://<servername>/<reserved-username>/<meta-type>/<context-name></code>
  
====AppData====
+
The <meta-type> may be one of these values:
 +
* template
 +
* ontology
 +
* data
  
Example of an AppData context:
+
Example
  
[[Image:Appdata 2.0.109.png|center]]
+
  <code>http://my.azigo.com/sys/template/awp</code> - the template for a user's regular "awp" context
 +
  <code>http://my.azigo.com/sys/ontology/tracker-catalog</code>
 +
  <code>http://my.azigo.com/sys/data/trackers</code>
  
Shown above is an example Embedded AppData context (shown as _ContextSingleton above). Within this context is an entity, Persona_1. The CreditBureauAppData object has a number of attributes described above.  
+
=== Entity Naming ===
 +
The entity representing the user in most contexts has a local name of "me".  
  
Of particular interest is the app-card:appParams attribute whose value is the AppParams_1 object. The AppParams_1 in turn has two app initialization attributes, randomAttribute1 and 2.
+
Example:
 +
  If the contextId is http://my.azigo.com/ptrevithick/awp and the local entityId is "me" then
 +
  the fully qualified entityId is:
 +
  http://my.azigo.com/ptrevithick/awp#me
  
Note: Since "appEnabled" = true attribute/value is not present on Persona_1 its value is assumed to be false and the card is thus disabled at present.
+
== Examples ==
  
The above also shows an example of a event:Verification that happened in 1969. Presumably the entire contents of the context were shared with the credit bureau and the Work_1 address was attempted to be verified with a result of "failed."
+
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 above also shows an example of an event:Disclosure that says that the "v:bday" attribute of the Persona_1 entity has a policy that says that the user "allow"s its disclosure to http://amazon.com.
+
The web profile context might look like this:
  
Errata:
+
[[Image:Webprofile.png|center]]
The Disclosure_1 event is missing an "at" (dateTime) attribute/value.
+
  
== Restrictions on CDM 2.0 EntityIds  ==
+
== Attribute Metadata ==
  
The PDM 2.0 uses a restricted set of the full capabilities of CDM 2.0. The restriction is in the area of [[EntityId]]s. PDM 2.0 adds the following constraints:
+
To construct a data-driven presentation of the contents of contexts whose data is described using the Persona data model, metadata about the attributes within context are needed. See [[View-builder vocabulary#Cascading_Metadata]] for a discussion of where these metadata attributes are stored (i.e. which context) and how metadata attributes are evaluated when mapping rules are involved.
  
All entities:
+
For a given attribute, '''A''', the following metadata attributes (as described in [[Higgins Data Model 2.0#Attribute_Definitions]] (with the exception of ''categories'' which are not used in PDM 2.0)) comprise '''A''''s definition:
#All entityIds MUST be URIs
+
#All entityId values MUST be Linked Data URIs or XRI 2.0 URIs
+
#All entityIds within a given context MUST be either (a) relative to a "base" URI of the context or (b) absolute
+
#Whether or not an entityID is relative or absolute MUST be able to be determined by inspection of its syntax
+
#Absolute entityIds MAY be globally resolvable
+
#Globally resolvable entityIds resolve to an entity (resource description) within exactly one context
+
  
Context objects:
+
; 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 entityId of the context object singleton is "_ContextSingleton"
+
; Example value : The example value is the value of the skos:example attribute. For example "name@domain.com" might be an example of an email value.
 +
; Hover/Tooltip text : The string description of the attribute is the value of the skos:description attribute.
 +
; Type : The type of an attribute is the value of the rdf:type attribute
 +
; Allowed values: The allowed values of an attribute is defined by the value of its rdfs:range metadata attribute. An rdfs:range may be an XML schema datatype such as xsd:nonNegativeInteger or it may be object valued in which the value of the rdfs:range attribute is the name of an entity class. If this class is a subclass of p:DiscreteRange, then the allowed values are the rdfs:label values of all instances/members of the class.
 +
; Cardinality : The min..max (inclusive) cardinality of an attribute is specified using owl:minCardinality and owl:maxCardinality. These two meta attributes are properties of a specific class of entity that is the domain of the attribute, not the attribute's own definition. In other words cardinality is expressed within the context of a class/set of individuals.
 +
; Syntax restrictions : We follow the latest OWL2 convensions. The value of the rdfs:range attribute may be rdfs:Datatypes augmented with owl:withRestrictions that include XML Schema facets (e.g. rdf:langRange xsd:length xsd:maxExclusive xsd:maxInclusive xsd:maxLength xsd:minExclusive xsd:minInclusive xsd:minLength xsd:pattern ) as described [http://www.w3.org/TR/owl2-rdf-based-semantics/#Facet_Names here].
  
== See Also ==
+
We have recently introduced a convention that the context id of metadata attribute M must be the same as the context id of A. If the currie form of A is ''ctxt:attname'' then the currie form of '''M''' must have a prefix (i.e. namespace) of ''ctxt''. For example if the attribute is ''fp:postalCode'' then metadata statements about ''fp:postalCode'' must be in the [[Flat Persona vocabulary]] context (fp being a prefix for this vocabulary) along with the definition of ''fp:postalCode'' itself. See also [[View-builder vocabulary]].
* [[Persona Attribute List]] - a list of all of the attribute concepts that can be represented in PDM
+
* [http://wiki.eclipse.org/images/0/0b/UnderstandingAppCards.pdf] - a developer summary of AppCard implementation issues
+
  
Use cases:
+
== Open Issues ==
 +
# To support connector contexts for which a WebsiteFacade is used for the definer side along with its associated JavaScript, it may be useful to add a "date-time-modified" timestamp to every context. This would allow sync operations via a set of N WebsiteFacade JavaScript programs to be decoupled from (and asynchronous to) real-time edit operations by the user. A more sophisticated approach would involve caching as a set of commands (transactions) the changes made to any context and allowing other contexts (well, their associated JavaScript) to subscribe to these transactions.
  
*[[Data Sharing With Alice And Bob]]
+
[[Category:Higgins 2]]
*[[Activity Streams In Persona]]
+

Latest revision as of 12:00, 15 August 2014

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

A data model for people and their relationships with other people and businesses. Builds on Higgins Data Model 2.0.

Person entities, attributes, links and contexts

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.

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.):

h:correlation
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
h:relation
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
h:indeterminate
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
proxy:resource
A link from a Proxy to an entity in another context.

Vocabularies

Vocabularies for Describing People

Contexts describe their contents (i.e. person entity attributes) using in the Persona vocabulary which in turn imports the following well known vocabularies (aka ontologies):

...and the following Higgins-defined vocabularies:

Not imported by the Persona vocabulary but recommended where relevant to the developer's problem space:

Supporting Vocabularies

The following vocabularies are used to support the PDS application itself:

  • Flat Persona vocabulary - a flattened, simplified subset useful for querying persona.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)
    • App-data vocabulary - for describing active, JavaScript content that is either stored in a template or fetched from an external service
    • Mapping vocabulary - a set of rules used to map between persona.owl and vocabularies used by external sites and services
  • Template-meta vocabulary - metadata about connection templates; used to create a registry of templates
  • Event vocabulary - for describing attribute changed and attribute disclosure events

Proxies

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:

Pdm proxy 2.0.108B.png

For details about proxies see Proxy vocabulary.

Context Issuer/Authority and Access Control

As we've described above, contexts contain person entities each of which is comprised of a set of attributes. Each context has an issuer attribute that indicates whom is authoritative over the entire contents of the context. If the user is named as the issuer of the context then the access control policy allows the user to edit and update the entire contents of the context as they see fit. Contexts for which the user is the issuer are physically located within the PDS--the ADS to be precise). The access control policy is contained within a special control context associated with each (regular) context. For more information about control contexts see the section below on supporting contexts.

Connection Context Pairs

A connection is a relationship between the PDS user and an external site/business or a friend's account on their PDS. There are two sides to these relationships, but not in the usual sense of things. One side is the face that the user wishes to present to the other party. The other side is what the other party says about the person. Each "side" is represented as a p:Person entity. Each p:Person entity lives in its own connection context. Since both p:Person entities are about the same person, the two person entities are interconnected with h:correlation links.

We refer to one of these connection contexts as the definer and the other as participant. In every relationship one party is defining the ground rules for the relationship, and the other is consenting to play within these rules. In a person-to-business relationship the user plays the role of participant, and the business plays the role of definer. In a person-to-person relationship the user could play either role.

The definer-created template that governs the connection relationship identifies which attributes the definer provide (i.e. is authoritative over) v.s. which attributes it requests from the participant (i.e. the participant is authoritative over). However, the actor playing the definer role writes to the definer context and the actor playing the participant role writes to the participant context. As a consequence, any given attribute (whether definer-authoritative or participant-authoritative) may be written either context; or both.

If the user is playing the role of participant, the identifier of the person entity in the participant context is "<contextid>#me" by convention (see the Naming Conventions section below for more details). The id of the person entity in the definer context is a globally unique identifier of the form "<contextid>#localentityid" where localentityid is usually a URI-friendly normalization of the user's username on the external system.

At this point an example might be helpful. Let's take the example of a relationship between the user and the New York Times:

Connection contexts 2.0.107b.png

The attributes of the person entity in the participant context are the set of statements that Alice makes about herself in the context of their relationship with the NYTimes. It is the face or persona that she wishes to present to that business. Examples might include her, first name, last name, email address, home delivery address, etc. Alice can make these statements by directly editing them in the participant context using her PDS client. However, she could also express the same intent by interacting with the NYTimes website directly. If she did so the NYTimes agent would write the updated values of these attributes into the definer context.

The attributes of the Person entity in the definer context are the 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 integrated together and displayed as a single semi-editable view. We discuss attribute integration further in a separate section below.

Attribute Integration

Both the definer and the participant contexts contain p:Person entities with a set of attributes. These two attribute sets are not necessarily disjoint (i.e. there may be N>1 attributes that are common to both p:Persons). The integration algorithm is as follows:

  • For attributes that exist only on one or the other (but not both) of the two interlinked persons, take their values from whichever person entity they are found.
  • For attributes that exist on both persons, take the values from the person whose containing context's modified date-time is more recent.

Let's examine this algorithm using an example of Alice's connection to the NYTimes website. The parameters of this connection were defined by NYTimes, specifically, by a NYTimes-minted ConnectionTemplate. The relationship involves two disjoint sets of attributes: the set of attributes for which the definer is authoritative, and the set for which the participant is authoritative. In this example Alice is authoritative over three: her first name, last name, and email address. The NYTimes is authoritative over one: Alice's subscriber id.

Alice plays the role of participant. Alice's PDS's connection viewer/editor reads attributes from both contexts, integrates them according to the algorithm above, and displays a UI showing these all four of these attributes. Since Alice is authoritative over first name, last name and email address, these are displayed using editable UI widgets. Since the NYTimes is authoritative over her subscriber id, this is displayed in a non-editable widget. If Alice updates any values of any of the three editable attributes, these updated values are written into the participant context (and the context's 'modified' timestamp is updated). As described in the next paragraph, the definer context may contain updated values for none, some or all of the attributes over which Alice is authoritative. Thus these attributes may ultimately exist in both contexts. Per the integration algorithm, the UI takes the values of the common attributes from the most recently updated context. If the definer context has been more recently updated, then it reads these Alice-authoritative attributes from the definer context and writes them into the participant context.

The NYTimes plays the role of definer. We ignore here the technical details (e.g. network protocols, and/or APIs.) of how this data connection works, and just look at the attribute integration logic. The NTYimes has read/write access to the definer context and read access to the participant context. It can also read the modified date-time values of each. The NYTimes is authoritative over the subscriber id value and under no circumstance (either with the PDS or on the NYTimes site) can Alice update or change this value. The NYTimes writes the value of the subscriber id value into the definer context. However, for the other three attributes over which Alice is authoritative, Alice may update their values on the NYTimes site. If she does, the NYTimes writes the updated values of these 3 attributes into the definer context (and its modified value is updated).

Website Facade Connections

Until the day when businesses natively support bi-directional data connection APIs and open protocols (e.g. perhaps things built on top of OpenID Connect, etc.) we can create a connection another way. The Higgins PDS project includes an optional browser extension (aka HBX) that can fill attributes from the PDS to the site, and scrape data from the web pages of the site into the user's PDS.

The data model to implement this involves only one half of the participant/definer context pair described in the previous section. In this case we instantiate a single participant context of a special kind called a WebsiteFacade. The template for this website facade includes scripts, mapping rules and sometimes custom JavaScript to allow the HBX to read/write attributes from/to the site and update them in the user's ADS account. In addition to being editable using the PDS web client UI, the HBX can execute JavaScript that edits it. See Website Facade Connection Example for more details.

Supporting Contexts

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

  • 0..1 ctxt:template
  • 0..1 h:control
  • 1..1 h:vocabulary
Supporting 2.0.117.png

Template Context

A template context acts as a template for a (non-template) context. It contains information common to all instances instantiated from it. Each non-template context may have up to one associated template context (pointed to by p:template attribute).

ConnectorTemplates are templates that describe and govern the relationship between a user and an external party such as a business or a friends's PDS. A ConnectorTemplate describes:

  • The set of attributes that each "end" of the relationship (e.g. participant vs. definer) agree to provide
  • Vocabulary/schema mapping rules to transform the "other" party's attributes into and out of the persona data model
  • In the case of connections to websites (as opposed to web services or other PDSes) it may include scripts (e.g. JavaScript) to read/write to/from the site
  • Future: a legal contract (agred to by both parties) that governs how each party's attributes may be used.

For more information about templates see Template vocabulary.

AppTemplates are templates for instantiated applets (PDS add-ons) that have read (and potentially write) access to a specific set of attributes within the PDS.

Control Context

Each regular context is associated with one "control" context (linked to by h:control). 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).

Social Graphs

h:relation

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

foaf:knows

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

h:indeterminate

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:

  http://<servername>/<username>/<context-name>

If the context is part of a connection context pair then the context-name uniquely identifies the "other" party in the connection. If the other party is a website then context-name is the domain name of the site (e.g. "staples.com").

Examples wherein servername (PDS/ADS operator) 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

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

  http://<servername>/<reserved-username>/<meta-type>/<context-name>

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

  • template
  • ontology
  • data

Example

  http://my.azigo.com/sys/template/awp - the template for a user's regular "awp" context
  http://my.azigo.com/sys/ontology/tracker-catalog
  http://my.azigo.com/sys/data/trackers

Entity Naming

The entity representing the user in most contexts has a local name of "me".

Example:

 If the contextId is http://my.azigo.com/ptrevithick/awp and the local entityId is "me" then
 the fully qualified entityId is:
 http://my.azigo.com/ptrevithick/awp#me

Examples

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:

Webprofile.png

Attribute Metadata

To construct a data-driven presentation of the contents of contexts whose data is described using the Persona data model, metadata about the attributes within context are needed. See View-builder vocabulary#Cascading_Metadata for a discussion of where these metadata attributes are stored (i.e. which context) and how metadata attributes are evaluated when mapping rules are involved.

For a given attribute, A, the following metadata attributes (as described in Higgins Data Model 2.0#Attribute_Definitions (with the exception of categories which are not used in PDM 2.0)) comprise A's definition:

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.
Example value 
The example value is the value of the skos:example attribute. For example "name@domain.com" might be an example of an email value.
Hover/Tooltip text 
The string description of the attribute is the value of the skos:description attribute.
Type 
The type of an attribute is the value of the rdf:type attribute
Allowed values
The allowed values of an attribute is defined by the value of its rdfs:range metadata attribute. An rdfs:range may be an XML schema datatype such as xsd:nonNegativeInteger or it may be object valued in which the value of the rdfs:range attribute is the name of an entity class. If this class is a subclass of p:DiscreteRange, then the allowed values are the rdfs:label values of all instances/members of the class.
Cardinality 
The min..max (inclusive) cardinality of an attribute is specified using owl:minCardinality and owl:maxCardinality. These two meta attributes are properties of a specific class of entity that is the domain of the attribute, not the attribute's own definition. In other words cardinality is expressed within the context of a class/set of individuals.
Syntax restrictions 
We follow the latest OWL2 convensions. The value of the rdfs:range attribute may be rdfs:Datatypes augmented with owl:withRestrictions that include XML Schema facets (e.g. rdf:langRange xsd:length xsd:maxExclusive xsd:maxInclusive xsd:maxLength xsd:minExclusive xsd:minInclusive xsd:minLength xsd:pattern ) as described here.

We have recently introduced a convention that the context id of metadata attribute M must be the same as the context id of A. If the currie form of A is ctxt:attname then the currie form of M must have a prefix (i.e. namespace) of ctxt. For example if the attribute is fp:postalCode then metadata statements about fp:postalCode must be in the Flat Persona vocabulary context (fp being a prefix for this vocabulary) along with the definition of fp:postalCode itself. See also View-builder vocabulary.

Open Issues

  1. To support connector contexts for which a WebsiteFacade is used for the definer side along with its associated JavaScript, it may be useful to add a "date-time-modified" timestamp to every context. This would allow sync operations via a set of N WebsiteFacade JavaScript programs to be decoupled from (and asynchronous to) real-time edit operations by the user. A more sophisticated approach would involve caching as a set of commands (transactions) the changes made to any context and allowing other contexts (well, their associated JavaScript) to subscribe to these transactions.

Back to the top