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

Form Filling

Revision as of 22:21, 6 September 2010 by Ptrevithick.gmail.com (Talk | contribs) (Recipient Context)

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

Introduction

This document describes how the Persona Data Model 2.0 can be used to support a Javascript form filling application (app-card) making API calls into the PDS Client of an active client. We will illustrate by walking through the following scenario rom a cold start (i.e. a clean install of a browser-integrated active client):

  1. Alice points her browser at staples.com and proceeds to try to buy a stapler. She eventually arrives at a checkout page
  2. Alice fills in the form and submits it
  3. Active client builds context data structures from what it has observed
  4. Alice points her browser at bestbuy.com and proceeds to buy a new CD
  5. Active client attempts to assist Alice in filling the form from data captured during her visit to staples.com
  6. Alice edits/corrects form elements and submits it
  7. Active client builds persona structures from what it has observed

Data structures at start

At the start only the root context shown here exists:

 :_ContextSingleton
     rdf:type persona:RootContext .
 
 :RootMe
     rdf:type persona:Persona .

Step 1

Alice eventually ends up at this form:

Staples.com checkout.png

The form filling Javascript will make a getExAttributes() call into the PDS Client API (of the active client) passing (among other parameters) the above form's submit URL.

This causes the PDS Client to

  • Find and load the mapping context whose name matches the domain of the site (e.g. staples.com) and find within it the HTMLForm subclass whose name matches the normalized form submit URL. For example the staples.com ontology includes a subclass that has the mapping rules to map staples-specific HTML form elements into the PDM.
  • Determine the "source" contexts necessary to satisfy the mapping rules. Note: most mapping rules use "generic" roles (e.g. "Recipient") while some may use the "local" role --that means that a ProfileContext of whose name (contextId) matches the website should be used. These "local" rules have the effect of storing site-specific information (account un/pw, local frequent flyer data).
  • if there is ambiguity (@@@@ explain) then either getSuggestions() or the selector UI may be used to disambiguate (@@@@ elaborate)

Root Context

The root context is unchanged.

Staples.com mapping context

We assume that the staple.com mapping context exists and is loaded. In addition to the _ContextSingleton it defines a subclass of HTMLForm called "Office-supplies-StaplesCheckoutFlow":

Staples-com mapping v2.png

Notes

  1. The "Office-supplies-StaplescheckoutFlow" class name should be named "Staples.com-office-supplies-StaplesCheckoutFlow"
  2. The spin:rule attributes of the Staples.com-office-supplies-StaplesCheckoutFlow class have been omitted above.

The context object is of type p:MappingContext but it is also tagged as being of external role type "p:Ecommerce"

 :_ContextSingleton
     a       persona:Ecommerce , persona:MappingContext .

Step 2

Step 2: Alice fills in the form and submits it

Step 3

The Form Filler program calls setAttributes() and records the values Alice entered. These data are mapped into the PDM by mapping rules defined by the staples.com mapping context described above. The net result is the creation of new contexts:

  • a generic context of p:role p:Buyer
  • a generic context of p:role p:Recipient
  • an RP-specific context of type p:ProfileContext

Root Context

The RootMe gains two new p:subCorrelation links. The first points to the "Persona_1" node in the Buyer context. The other points to the "Persona_1" node in the Recipient context.

Staples-com step 4.png

Note: some details omitted above.

Alice's Staples.com ProfileContext

This context describes Alice-specific RP-specific attributes.

 :Account_1
     rdf:type foaf:OnlineEcommerceAccount ;
     p:password "*******"^^xsd:string ;
     foaf:accountName "alice@gmail.com"^^xsd:string .
 
 :Persona_1
     rdf:type p:Persona ;
     foaf:account :Account_1 .
 
 :_ContextSingleton
     rdf:type p:ProfileContext .

Visually:

Profilecontext.png

Buyer Context

Here are the contents of the Buyer context:

 :Address_1
     rdf:type vcard:Address ;
     rdfs:label "Address_1"^^xsd:string ;
     vcard:extended-address
             "Suite 1000"^^xsd:string ;
     vcard:locality "Peoria"^^xsd:string ;
     vcard:postal-code "61604"^^xsd:string ;
     vcard:region "IL"^^xsd:string ;
     vcard:street-address
             "123 S Main Street"^^xsd:string .
 
 :Name_1
     rdf:type vcard:Name ;
     vcard:family-name "Jones"^^xsd:string ;
     vcard:given-name "Alice"^^xsd:string .
 
 :Persona_1
     rdf:type p:Persona ;
     vcard:adr :Address_1 ;
     vcard:n :Name_1 ;
     p:role p:Ecommerce , p:Buyer ;
     vcard:tel :Voice_1 .
 
 :Voice_1
     rdf:type vcard:Voice ;
     rdf:value "tel:+358-555-1234567" .

Recipient Context

Here are the contents of the Recipient context:

 :Address_1
     rdf:type v:Address ;
     v:locality "Wellesley Hills"^^xsd:string ;
     v:postal-code "02481"^^xsd:string ;
     v:region "MA"^^xsd:string ;
     v:street-address "30 Washington Street"^^xsd:string .
 
 :Name_1
     rdf:type v:Name ;
     v:family-name "Jones"^^xsd:string ;
     v:given-name "Alice"^^xsd:string .
 
 :Persona_1
     rdf:type p:Persona ;
     v:adr   :Address_1 ;
     v:n     :Name_1 ;
     p:role p:Ecommerce, p:Recipient ;
     v:tel   :Tel_1 .
 
 :Tel_1
     rdf:type v:Tel ;
     p:password "tel:+358-555-1234567"^^xsd:string .

Step 4

Alice points her browser at bestbuy.com and proceeds to buy a new CD.

Step 5

Active client attempts to assist Alice in filling the form from data captured during her visit to staples.com

When Alice reaches the checkout page, the Form Filler program attempts to auto-fill the checkout data. It does so by calling getExAttributes(). The PDS Client implementation of getExAttributes() then does the following:

(1) Load the bestbuy.com MappingContext

Fetches the context whose contextId is algorithmically derived from "bestbuy.com" (the RP parameter from getExAttributes()) from the PDS service.

(2) Determines the set of required source contexts

We examine the mapping rule for each of the attributes requested in getExAttributes. Each rule and its associated parameters provides matching criteria to find one or more suitable source contexts.

Different mapping rules have different parameters. Let's consider the mapping rule rolePathLiteral. It has the following parameters:

  • Role parameter.
    • Role of Ecommerce. Determined by looking up the external role value in the bestbuy.com Mapping Context
    • Role of "p:Buyer"
  • Path parameter matches "vcard:adr"
  • Literal parameter matches "vcard:street-address".

In this example rule, we'd search for a context that has a p:Role of "Ecommerce" and a p:Role of "Buyer". Which of course would match this context from above:

 :_ContextSingleton
    a       persona:Ecommerce, persona:Buyer ;

Of course other mapping rules might require other source contexts.

There are also "local" matching rules. Rules wherein the role to match is set to a special value "!local". This kind of rule uses as its source a p:ProfileContext-type context whose roleName matches the domain of the RP (e.g. staples.com).

(3) Return attribute values and record diclosure

If all rules haven an unambiguous source context then all rules can be evaluated and all values returned. On the other hand...

If more than one context matches as the source for a rule, then getExAttributes, being conservative, returns nil as the attribute value of that rule. The "client" app (e.g. the Javascript of an app-card) can either make a second call requesting values for attributes whose values had been returned as nil or (if it is a very privileged app) it can call the promiscuous getSuggestions() method for a single attribute and get back ALL of the possible values of that attribute.

Just prior to returning attribute values getExAttributes() makes an audit entry for this disclosure of attributes. It adds a Disclosure-type event to the alice-staples.com ProfileContext. Here is the result:

 :Account_1
     rdf:type foaf:OnlineEcommerceAccount ;
     p:password "*******"^^xsd:string ;
     foaf:accountName "alice@gmail.com"^^xsd:string .
 
 :Disclosure_1
     rdf:type event:Disclosure ;
     event:at "1979-01-01T00:00:15"^^xsd:dateTime ;
     event:entity recipient:_ContextSingleton , :_ContextSingleton , buyer:_ContextSingleton .
 
 :Persona_1
     rdf:type p:Persona ;
     foaf:account :Account_1 .
 
 :_ContextSingleton
     rdf:type p:Dynamic , p:ProfileContext ;
     event:event :Disclosure_1 ;
     p:roleName "Staples.com-office-supplies-StaplesCheckoutFlow"^^xsd:string .

Visually:

Disclosure event.png

Back to the top