Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Flat Persona vocabulary

Revision as of 17:00, 21 December 2010 by Ptrevithick.gmail.com (Talk | contribs) (Telephone Numbers)

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
Higgins logo 76Wx100H.jpg

A vocabulary that flattens (hides) some of the deep structure of Persona vocabulary. It imports Persona vocabulary.

Files

Introduction

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 the attribute they would like to get, and then calls one of the "getAttribute" APIs, passing this attribute. The getAttribute method sees 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.

Flat Persona vocabulary uses 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 inverses). The Persona Data Model 2.0 includes a vocabulary, mapping.owl, that defines these functions.

Roles

To reduce somewhat the explosion of attributes in this namespace we parameterize the getAttribute APIs using a role[] parameter. This parameter contains one or more role strings as described below. Since a single natural person is represented in PDM as multiple p:Person nodes, the role parameter is used to bias the selection of which source p:Person node(s) will be used to answer a getAttribute() query.

Internal roles

  • 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)

External roles

The get attribute APIs can also be passed external role values to add sensitivity to the interaction context.

Depending on the interaction context a different "source" p:Person node might be more appropriate. 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. Person nodes may carry one or more "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).

External role 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

Attribute URI parameter

To specify one or more roles, we use the URI query parameter "r". For example to request a person's home telephone number we construct:

  fp:phone?r=Home

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:

  • rolePathLiteral (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 for the attribute desired parameter and passing a role parameter of Gaming (i.e. fp:givenName?r=Gaming).

The getAttribute method would invoke the rolePathLiteral 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 (role[], 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 has the required attribute and best matches the roles in the role[] parameter.

In this case it would find the p:Person node that

  • has a complex-valued attribute (aka link) of type v:n (from the vcard vocabulary) whose value is the vcard:Address instance A1
  • has an A1 that has a simple-valued attribute of type v:given-name
  • (and in case there are multiple candidates) is the one whose role(s) best matches the value(s) of role[] (which in this case is the single value Gaming)

The value of this literal attribute is the result of mapping the concept of "given name."

Attributes

Account

  • fp:accountName : rolePathLiteral (role[], foaf:account, foaf:accountName)
  • fp:accountPassword : rolePathLiteral (role[], foaf:account, p:password)
  • fp:accountConfirmPassword : rolePathLiteral (role[], foaf:account, p:password)

Email

  • fp:email : roleEntity (role[], foaf:mbox)

Name

  • fp:honorificPrefix : rolePathLiteral (role[], v:n, v:honorific-prefix)
  • fp:givenName : rolePathLiteral (role[], v:n, v:given-name)
  • fp:additionalName : rolePathLiteral (role[], v:n, v:additional-name)
  • fp:additionalNameInitial : rolePathLiteralInitial (role[], v:n, v:additional-name)
  • fp:familyName : rolePathLiteral (role[], v:n, v:family-name)
  • fp:honorificSuffix : rolePathLiteral (role[], v:n, v:honorific-suffix)
  • fp:mothersMaidenName : roleLiteral (role[], p:mothersMaidenName)
  • fp:familyNameAtBirth : rolePathLiteral (role[], v:n, p:familyNameAtBirth)
  • fp:formattedName : TBD
  • fp:title : rolePathLiteral(role[], v:title)

Address

  • fp:streetAddress : rolePathLiteral (role[], v:adr, v:street-address)
  • fp:extendedAddress : rolePathLiteral (role[], v:adr, v:extended-address)
  • fp:appartmentNumber : appartmentNumber (role[]) - extract from street-address and extended-address
  • fp:buildingName : buildingName (role[]) - extract from street-address and extended-address
  • fp:houseNumber : houseNumber (role[]) - extract from street-address and extended-address
  • fp:buildingNameOrNumber : buildingNameOrNumber (role[]) - extract from street-address and extended-address
  • fp:locality : rolePathLiteral (role[], v:adr, v:locality)
  • fp:district : district (role[]) - extract from locality
  • fp:region : rolePathLiteral (v:adr, v:region)
  • fp:postalCode : rolePathLiteral (role[], v:adr, v:postal-code)
  • fp:4digitExtensionZip : TBD
  • fp:residentFrom : rolePathLiteral (role[], v:adr, h:start)
  • fp:residentFromDay : day (rolePathLiteral (role[], v:adr, h:start))
  • fp:residentFromMonth : month (rolePathLiteral (role[], v:adr, h:start))
  • fp:residentFromYear : year (rolePathLiteral (role[], v:adr, h:start))
  • fp:residentUntil : rolePathLiteral (role[], v:adr, h:end)
  • fp:residentUntilDay : day (rolePathLiteral (role[], v:adr, h:end))
  • fp:residentUntilMonth : month (rolePathLiteral (role[], v:adr, h:end))
  • fp:residentUntilYear : year (rolePathLiteral (role[], v:adr, h:end))

Payment

  • fp:creditCardType : TBD
  • fp:creditCardNumber : rolePathClassLiteral (role[], pay:payment, pay:CreditCard, pay:ccNumber)
  • fp:creditCardExpirationMonth : rolePathClassMonth (role[], pay:payment, pay:CreditCard, pay:ccExpiration)
  • fp:creditCardExpirationYear : rolePathClassYear (role[], pay:payment, pay:CreditCard, pay:ccExpiration)

Telephone

  • fp:phone : rolePathRDFValue (role[], v:tel)
  • fp:workPhone : rolePathClassRDFValue (role[], v:tel, v:Work) - NEW! (temporary hack until roles are implemented)
  • fp:homePhone : rolePathClassRDFValue (role[], v:tel, v:Home) - NEW! (temporary hack until roles are implemented)
  • fp:mobilePhone : rolePathClassRDFValue (role[], v:tel, v:Cell)
  • fp:phoneAreaCode : rolePathAreaCode (role[], v:tel)
  • fp:phoneSeven : rolePathSeven (role[], v:tel)
  • fp:phoneFirstThree : rolePathFirstThree (role[], v:tel)
  • fp:phoneLastFour : rolePathLastFour (role[], v:tel)

Birth-related

  • fp:localityOfBirth : rolePathClassLiteral (role[], v:adr, p:Birth, v:locality)
  • fp:countryOfBirth ;: rolePathClassLiteral (role[], v:adr, p:Birth, v:country)
  • fp:age : roleAge(role[]) - uses v:bday
  • fp:dateOfBirth : roleLiteral (role[], v:bday)
  • fp:dayOfBirth : roleDay (role[], v:bday)
  • fp:monthOfBirth : roleMonth (role[], v:bday)
  • fp:yearOfBirth : roleYear (role[], v:bday)

Geolocation

Relationships

  • fp:gender : roleLiteral (role[], foaf:gender)
  • fp:relationshipStatus : roleLiteral (role[], p:relationshipStatus)
  • fp:numberOfDependents : roleLiteral (role[], p:numberOfDependents)

Work

  • fp:currentEmployerName : currentEmployerName (role[])
  • fp:timeAtCurrentEmployer : timeAtCurrentEmployer (role[])

Identifiers

  • fp:passportNumber : rolePathClassLiteral (role[], idDoc, p:Passport, p:docNumber)
  • fp:nationalInsuranceNumber : roleLiteral (role[], p:nationalInsuranceNumber)

Financial

  • fp:bankSortCode : rolePathClassLiteral (role[], pay:paymentMethod, pay:DirectDebit, pay:bankSortCode)
  • fp:bankAccountNumber : rolePathClassLiteral (role[], pay:paymentMedhod, pay:DirectDebit, pay:bankSortCode)

Property

  • fp:vehicleLicenseNumber?country=c&region=r : vehicleLicenseNumber (role[], c, r)

Interest Topics

  • fp:careers : rolePathClassLiteral (role[], onb:interest, onb:Careers, onb:interested)
  • fp:comedyAndHumor : rolePathClassLiteral (role[], onb:interest, onb:ComedyAndHumor, onb:interested)
  • fp:computersAndTechnology : rolePathClassLiteral (role[], onb:interest, onb:ComputersAndTechnology, onb:interested)
  • fp:fashionAndBeauty : rolePathClassLiteral (role[], onb:interest, onb:FashionAndBeauty, onb:interested)
  • fp:geographicLocations : rolePathClassLiteral (role[], onb:interest, onb:GeographicLocations, onb:interested)

Links

Back to the top