Difference between revisions of "Form Filling"

Revision as of 14:27, 30 August 2010

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:

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.

http://wiki.eclipse.org/Persona_Data_Model_2.0#event.owl

• 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 roleName matches the website should be used. These "local" rules store site-specific information (account un/pw, local frequent flyer data, and in the future may hold "override" values
• 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":

Notes

1. The "Office-supplise-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 two new contexts. One is a Buyer-class context. The other is a Recipient-class context.

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.

Note: some details omitted above.

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 persona:Persona ;
     vcard:adr :Address_1 ;
     vcard:n :Name_1 ;
     vcard:tel :Voice_1 .
 
 :Voice_1
     rdf:type vcard:Voice ;
     rdf:value "tel:+358-555-1234567" .
 
 :_ContextSingleton
     a       p:Ecommerce , p:Buyer .

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 ;
     v:tel   :Tel_1 .
 
 :Tel_1
     rdf:type v:Tel ;
     p:password "tel:+358-555-1234567"^^xsd:string . 
 
 :_ContextSingleton
     a       p:Ecommerce , p:Recipient .

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() first attempts to load the bestbuy.com mapping context. The mapping rules require "source" contexts (and their contained personas) to use to fill in the values.

Different mapping rules match one different parameters. Let's consider for example one specific rolePathLiteral rule with the following parameters:

• Its role parameter matches:
  • The "external" role of bestbuy.com (which by lookup from bestbuy.com mapping context can be found to be "Ecommerce")
  • An "internal" role of "p:Buyer"
  • A dynamic role (p:Dynamic) whose roleName is Bestbuy.com-site-olspage.jsp-id-pcat17010-type-page-_DARGS--site-en_US-checkout-fragments-olschkentershippingaddressform.jsp (the form submit URL of the bestbuy form we're on).
• Its path parameter matches "vcard:adr"
• Its literal parameter matches "vcard:street-address".

Since we've never been to bestbuy.com before the mapping rule will not be able to find a match for the dynamic role mentioned above. So although an ideal (i.e. maximally specific) a good match would find the Buyer context that was created in Step 3 above whose context object is:

 :_ContextSingleton
    a       persona:Ecommerce , persona:Dynamic , persona:Buyer ;
    persona:roleName "Staples.com-office-supplies-StaplesCheckoutFlow"^^xsd:string .