Difference between revisions of "Persona Attribute List"

Revision as of 09:42, 29 October 2010

This page lists the attributes that can be described by the PDM. This page will aid developers creating schema mapping tranformations into and out from the PDM.

TODO

• The tables are incomplete at present.

Introduction

Since getting the world's developers to commit to a single, rich ontology will never happen, the next best thing is to define a rich, fine-grained internal ontology (as we have done in Persona Data Model 2.0 (PDM)) and then define mapping rules between it an vocabularies that exist in the wild.

We define mapping functions that get values of attributes in PDM object graphs. The inverse of these functions can set these values (although not all functions have inverse functions). One of the sub-parts of PDM is an ontology to describe these mapping functions. It is called mapping.owl and is described briefly on the main PDM page.

Mapping in or out of another vocabulary can be thought of as involving two steps. First a human needs to look at an attribute in some target vocabulary T classify it as some concept C. The rows in the tables on this page describe the mapping from C to entities and attribute instances in a concrete instance of the PDM model.

The application of mapping rules is considered to occur within what we call an "external context." Since a single person is represented in PDM as multiple p:person nodes (facets) when trying to map "given-name" we need to understand the broad, overall containing context of the interaction. Depending on the context a person might answer differently. For example if the context was a virtual world like Second Life, the person's given name is almost always not their "real world" given name. Persona nodes in PDM carry a number of "role" tags that indicate appropriateness/use in one of these overall contexts. (We're using the word context generically here, we are not referring to Higgins Contexts).

The external context is represented as "RP" in the tables below. The actual values of RP would be one of the instances of "External" Role pre-defined in PDM (specifically persona.owl). These include Ecommerce, Gaming, SocialNetworking, etc.

An Example: Given Name

If in vocabulary T we saw a term that we'd classify as a person's given name, then we'd first search for a row by that name in one of the tables on this page. We'd then lookup the function and arguments on that row. The function traverses a path (or in rare cases a set of paths) through a PDM graph. In the case of given name we'd find the following matching row:

The function to be applied called rolePathLiteral. Its name is a hint as to how it operates. This function takes three arguments (rp-role, v:n, v:given-name). The rolePathLiteral starts at the root of the Persona graph (the RootMe node) and breadth-first following p:subCorrelation links searches for the first p:person node that is tagged with a role that matches the role of the external context.

Let's assume that the value of rp-role (the external context) is "eCommerce". The rolePathLiteral function will start at the root RootMe node and breadth-first find the first p:Person node that has a matching role value of "eCommerce". If none are found then the first p:Person found that matches the rest of the criteria we're about to explain, will be used. In this example and in all others the role argument (usually Arg1) is used to disambiguate between multiple alternatives that otherwise match the rest of the criteria. The more role tags that match, the better the quality of the match.

The rest of the criteria are that the person node must have a "path" (we're done with "role" we're now onto "path"), that is, a complex-valued attribute (aka link) of type v:n (from the vcard vocabulary). Further, it must have a simple-valued attribute of type v:given-name. The value of this literal attribute is the result of mapping the human concept of "given name."

Parameterization

To reduce redundancy in the following tables, we use the following parameterization scheme:

The <Type> may be one of:

• Shipping
• Home
• Shipping, Home
• Work
• Billing
• DayTime
• nil

And to retrieve the correct type for each of the above, set the <Role> (respectively):

• Recipient
• Home
• Recipient, Home
• Work
• Buyer
• DayTime
• nil

Account

Experimental, alternative format from the tables below...

• fp:accountUsername = rolePathLiteral (rp-role, foaf:account, foaf:accountName)
• fp:accountPassword = rolePathLiteral (rp-role, foaf:account, p:password)
• fp:accountConfirmPassword = rolePathLiteral (rp-role, foaf:account, p:password)
• fp:accountEmail = roleObject (rp-role, foaf:mbox)
• fp:accountEmail = roleObject (rp-role, foaf:mbox)

Account

Names

The beginnings of an alternative format from the table below:

• fp:honorificPrefix?r={rp-role}&r={role} = rolePathLiteralInitial ([rp-role,<role>], v:n, v:honorific-prefix)
• fp:givenName?r={rp-role}&r={role} = rolePathLiteral ([rp-role,<role>], v:n, v:given-name)
• fp:additionalNames?r={rp-role}&r={role} = rolePathLiteral ([rp-role,<role>], v:n, v:additional-name)
• fp:additionalNamesInitial?r={rp-role}&r={role} = rolePathLiteralInitial ([rp-role,<role>], v:n, v:additional-name)
• fp:familyName?r={rp-role}&r={role} = rolePathLiteralInitial ([rp-role,<role>], v:n, v:family-name)
• fp:honorificSuffix?rr={rp-role}&={role} = rolePathLiteralInitial ([rp-role,<role>], v:n, v:honorific-suffix)
• fp:formattedName?r={rp-role}&r={role} = TBD

Names

Addresses

Note: rolePathAddress() is a function that concatenates: apartment + (houseNumber or houseName) + house + street

Birthday

Payment Related

Telephone Numbers

GeoLocation

Misc