Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Flat Persona vocabulary"
(→Misc) |
(→Names) |
||
Line 66: | Line 66: | ||
* fp:email : literal (''role[], foaf:mbox'') | * fp:email : literal (''role[], foaf:mbox'') | ||
− | === | + | === Name === |
− | *fp:honorificPrefix : | + | *fp:honorificPrefix : pathLiteral (''role[], v:n, v:honorific-prefix'') |
*fp:givenName : pathLiteral (''role[], v:n, v:given-name'') | *fp:givenName : pathLiteral (''role[], v:n, v:given-name'') | ||
*fp:additionalName : pathLiteral (''role[], v:n, v:additional-name'') | *fp:additionalName : pathLiteral (''role[], v:n, v:additional-name'') | ||
Line 78: | Line 78: | ||
*fp:formattedName : TBD | *fp:formattedName : TBD | ||
*fp:title : pathLiteral(''role[], v:title'') | *fp:title : pathLiteral(''role[], v:title'') | ||
+ | |||
+ | === Address === | ||
+ | |||
+ | *fp:streetAddress : pathLiteral (''role[], v:adr, v:street-address'') | ||
+ | *fp:extendedAddress : pathLiteral (''role[], v:adr, v:extended-address'') | ||
+ | *fp:locality : pathLiteral (''role[], v:adr, v:locality'') | ||
+ | *fp:region : pathLiteral (''role[], v:adr, v:region'') | ||
+ | *fp:postalCode : pathLiteral (''role[], v:adr, v:postal-code'') | ||
+ | *fp:4digitExtensionZip : TBD | ||
+ | *fp:startAtAddress : pathLiteral (''role[], v:adr, h:start'') | ||
+ | *fp:endAtAddress : pathLiteral (''role[], v:adr, h:end'') | ||
+ | |||
+ | === Payment === | ||
+ | *fp: | ||
=== Telephone Numbers === | === Telephone Numbers === |
Revision as of 13:44, 11 November 2010
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}A vocabulary that flattens (hides) some of the deep structure of Persona vocabulary. It imports Persona vocabulary.
Contents
Files
- SVN source: fp.owl.
Introduction
Getting the whole world to commit to a single, rich ontology will never happen. So 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.
The purpose of the Flat Persona vocabulary is to shield developers from having to understand the deeper structure of the PDM. For example, the developer simply chooses from this vocabulary which attribute they would like to get and then calls one of the "getAttribute" APIs passing this attribute. The getAttribute method, notices that the attribute is in the flat persona namespace, looks up the associated rule and uses this rule to traverse the PDM structure to retrieve the desired attribute value
Parameterization
Since completely flattening out the attribute namespace would result in an explosion of attribute names, we parameterize using role and rp-role parameters.
role
We introduce a role parameter. Defined values are:
- Recipient - often called "shipping" (e.g. a "shipping address")
- Home - attributes about the user's home life, (e.g. house where they live, or home telephone number)
- Recipient, Home - a combination of the above
- Work - information about the person's work life
- Buyer - information about a person in their role as a buyer (e.g. a "billing" address)
- DayTime - information about a person that is relevant during the day time (e.g. a daytime phone number)
rp-role
Mapping rules are used within what we call an rp-role 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 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).
We introduce a <rp-role> parameter. Defined values include:
- Ecommerce - an interaction within an eCommerce context
- Gaming - an interaction with a gaming context
- SocialNetworking - an interaction within a social networking or chat context
- ..other instances of class "External" (a subclass of "Role") within the Persona vocabulary
An Example: Given Name
In the flat persona vocabulary we define the attribute:
-
fp:givenName
The flat persona vocabulary associates this attribute with the following mapping rule:
-
pathLiteral (role[], v:n, v:given-name)
If the developer wanted to retrieve the value of the user's given name as that user would use in interactions with gaming websites they would call one of the getAttribute APIs passing the value of fp:givenName?r=Gaming
where the "r" parameter's value specifies the Gaming rp-role.
The getAttribute method would invoke the pathLiteral
function. This function traverses a path (or in rare cases a set of paths) through a PDM graph. Its name is a hint as to how it operates. This function takes three arguments (list-of-roles, v:n, v:given-name). It starts at the root of the p:Person graph (i.e. the RootMe
node) and searches breadth-first following p:subCorrelation
links for the p:Person node that best matches the roles in the list-of-roles parameter and that has the required attribute.
The pathLiteral
function will start at the root RootMe node and breadth-first find the p:Person node whose role(s) best match the value(s) of role[] which in this case is the single value Gaming and that has 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."
Attributes
Account
- foaf:accountName : pathLiteral (role[], foaf:account, foaf:accountName)
- fp:accountPassword : pathLiteral (role[], foaf:account, p:password)
- fp:accountConfirmPassword : pathLiteral (role[], foaf:account, p:password)
- fp:email : literal (role[], foaf:mbox)
Name
- fp:honorificPrefix : pathLiteral (role[], v:n, v:honorific-prefix)
- fp:givenName : pathLiteral (role[], v:n, v:given-name)
- fp:additionalName : pathLiteral (role[], v:n, v:additional-name)
- fp:additionalNameInitial : pathLiteralInitial (role[], v:n, v:additional-name)
- fp:familyName : pathLiteral (role[], v:n, v:family-name)
- fp:honorificSuffix : pathLiteral (role[], v:n, v:honorific-suffix)
- fp:mothersMaidenName : literal (role[], p:mothersMaidenName)
- fp:familyNameAtBirth : pathLiteral (role[], v:n, p:familyNameAtBirth)
- fp:formattedName : TBD
- fp:title : pathLiteral(role[], v:title)
Address
- fp:streetAddress : pathLiteral (role[], v:adr, v:street-address)
- fp:extendedAddress : pathLiteral (role[], v:adr, v:extended-address)
- fp:locality : pathLiteral (role[], v:adr, v:locality)
- fp:region : pathLiteral (role[], v:adr, v:region)
- fp:postalCode : pathLiteral (role[], v:adr, v:postal-code)
- fp:4digitExtensionZip : TBD
- fp:startAtAddress : pathLiteral (role[], v:adr, h:start)
- fp:endAtAddress : pathLiteral (role[], v:adr, h:end)
Payment
- fp:
Telephone Numbers
- fp:phone : pathRDFValue (roles[], v:tel)
- fp:mobilePhone : pathClassRDFValue ([roles[], v:tel, v:Cell)
- fp:localityOfBirth : pathClassLiteral (role[], v:adr, p:Birth, v:locality)
- fp:countryOfBirth : pathClassLiteral (role[], v:adr, p:Birth, v:country)
- fp:age : age(role[]) - uses v:bday
- fp:dateOfBirth : literal(role[], v:bday)
- fp:dayOfBirth : day(role[], v:bday)
- fp:monthOfBirth : month(role[], v:bday)
- fp:yearOfBirth : year(role[], v:bday)
Misc
- fp:relationshipStatus : literal (role[], osoc:relationshipStatus)
- fp:numberOfDependents : literal (role[], p:numberOfDependents)
- fp:familyNameAtBirth : pathClassLiteral (role[], v:adr, p:Birth, v:family-name)
- fp:passportNumber : pathClassLiteral (role[], idDoc, p:Passport, p:docNumber)
- fp:currentEmployerName : currentEmployerName(role[])
- fp:bankSortCode : pathClassLiteral (role[], pay:paymentMethod, pay:DirectDebit, pay:bankSortCode)
- fp:bankAccountNumber : pathClassLiteral (role[], pay:paymentMedhod, pay:DirectDebit, pay:bankSortCode)
- fp:timeAtCurrentEmployer : timeAtCurrentEmployer (role[])
- fp:vehicleLicenseNumber : pathClassLiteral (role[], idDoc, p:VehicleLicense, p:docNumber)
- fp:nationalInsuranceNumber : literal (role[], p:nationalInsuranceNumber)